My recently added test for a device being local in fw-cdev.c got it
slightly wrong: Comparisons of node IDs are only valid if the
generation is current, which I forgot to check. Normally, serialization
by card->lock takes care of this, but a device in FW_DEVICE_GONE state
will necessarily have a wrong generation and invalid node_id.
The "is it local?" check is made 100% correct and simpler now by means
of a struct fw_device flag which is set at fw_device creation.
Besides the fw-cdev site which was to be fixed, there is another site
which can make use of the new flag, and an RFC-2734 driver will benefit
from it too.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Beat Michel Liechti <bml303@gmail.com>
Tuning was broken on FireDTV S2 (and presumably FloppyDTV S2) because a
wrong opcode was sent. The box only gave "not implemented" responses.
Changing the opcode to _TUNE_QPSK2 fixes this for good.
Cc: stable@kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Eliminate
drivers/media/dvb/firewire/firedtv-avc.c: In function 'debug_fcp':
drivers/media/dvb/firewire/firedtv-avc.c:156: warning: format '%d' expects type 'int', but argument 5 has type 'size_t'
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cache the test result of whether a device implements BROADCAST_CHANNEL.
This minimizes traffic on the bus after each bus reset. A majority of
devices does not implement BROADCAST_CHANNEL.
Remove busy retries; just rely on the hardware to retry requests to busy
responders. Remove unnecessary log messages.
Rename the flag is_irm to broadcast_channel_allocated to better reflect
its meaning. Reset the flag earlier in fw_core_handle_bus_reset.
Pass the generation down as a call parameter; that way generation can't
be newer than card->broadcast_channel_allocated and device->node_id.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Per IEEE 1394 clause 8.4.2.5, bus manager capable nodes which are not
incumbent shall wait at least 125ms before trying to establish
themselves as bus manager.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This changes the as yet unreleased FW_CDEV_IOC_SEND_STREAM_PACKET ioctl
to generate an fw_cdev_event_response event just like the other two
ioctls for asynchronous request transmission do. This way, clients get
feedback on successful or unsuccessful transmission.
This also adds input validation for length, tag, channel, sy, speed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This changes the ioctl() return value of FW_CDEV_IOC_SEND_REQUEST and of
the as yet unreleased FW_CDEV_IOC_SEND_BROADCAST_REQUEST. They used to
return
sizeof(struct fw_cdev_send_request *) + data_length
which is obviously a failed attempt to emulate the return value of
raw1394's respective interface which uses write() instead of ioctl().
However, the first summand, as size of a kernel pointer, is entirely
meaningless to clients and the second summand is already known to
clients. And the result does not resemble raw1394's write() return
code anyway.
So simplify it to a constant non-negative value, i.e. 0. The only
dangers here would be that future client implementations check for error
by ret != 0 instead of ret < 0 when running on top of an old kernel; or
that current clients interpret ret = 0 or more as failure. But both are
hypothetical cases which don't justify to return irritating values.
While we touch this code, also remove "& 0x1f" from tcode in the call of
fw_send_request. The tcode cannot be bigger than 0x1f at this point.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The bus reset handler concurrently frees client->device->node. Use
device->node_id instead. This is equivalent to device->node->node_id
while device->generation is current.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The access permissions and ownership or ACL of /dev/fw* character device
files will typically be set based on the device type of the respective
nodes, as obtained by firewire-core from descriptors in the device's
configuration ROM. An example policy is to deny write permission by
default but grant write permission to files of AV/C video and audio
devices and IIDC video devices.
The FW_CDEV_IOC_ADD_DESCRIPTOR ioctl could be used to partly subvert
such a policy: Find a device file with relaxed permissions, use the
ioctl to add a descriptor with AV/C marker to the local node's ROM, thus
gain access to the local node's character device file. (This is only
possible if there are udev scripts installed which actively relax
permissions for known device types and if there is a device of such a
type connected.)
Accessibility of the local node's device file is relevant to host
security if the host contains two or more IEEE 1394 link layer
controllers which are plugged into a single bus.
Therefore change the ABI to deny FW_CDEV_IOC_ADD_DESCRIPTOR if the file
belongs to a remote node. (This change has no impact on known
implementers of the ABI: None of them uses the ioctl yet.)
Also clarify the documentation: The ioctl affects all local nodes, not
just one local node.
Cc: stable@kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The as yet unreleased FW_CDEV_IOC_GET_SPEED ioctl puts only a single
integer into the parameter buffer. We can use ioctl()'s return value
instead.
(Also: Some whitespace change in firewire-cdev.h.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This patch adds the ISO broadcast channel support that is required of a
1394a IRM. In specific, if the local device the IRM, it allocates ISO
channel 31 and sets the broadcast channel register of all devices on the
local bus to BROADCAST_CHANNEL_INITIAL | BROADCAST_CHANNEL_VALID to indicate
that channel 31 can be use for broadcast messages.
One minor complication is that on startup the local device may become IRM
before all the devices on the bus have been enumerated by the stack. Therefore
we have to keep a "the local device is IRM" flag and possibly set the
broadcast channel register of new devices at enumeration time.
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Allow userspace and other firewire drivers (fw-ipv4 I'm looking at
you!) to send Asynchronous Transmit Streams as described in 7.8.3 of
release 1.1 of the 1394 Open Host Controller Interface Specification.
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (tweaks)
Standardize on if (err)
handle_error;
and if (ret < 0)
handle_error;
Don't call a variable err if we store values in it which mean success.
Also, offset some return statements by a blank line since this how we do
it in drivers/firewire.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
reread_bus_info_block() only gets to see devices whose config_rom_length
is at least 6 (ROM header, bus info block, root directory header).
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The kernel API documentation says that queue_delayed_work() returns 0
(only) if the work was already queued. The return codes of
schedule_delayed_work() are not documented but the same.
In init_iso_resource(), the work has never been queued yet, hence we
can assume schedule_delayed_work() to be a guaranteed success there.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Some fixes:
- Remove stale documentation.
- Fix a != vs. == thinko that got in the way of channel management.
- Try bandwidth deallocation even if channel deallocation failed.
A simplification:
- fw_cdev_allocate_iso_resource.channels is now ordered like
libdc1394's dc1394_iso_allocate_channel() channels_allowed
argument.
By the way, I looked closer at cards from NEC, TI, and VIA, and noticed
that they all don't implement IEEE 1394a behaviour which is meant to
deviate from IEEE 1212's notion of lock compare-swap. This means that
we have to do two lock transactions instead of one in many cases where
one transaction would already succeed on a fully 1394a compliant IRM.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Stefan Richter
Beat Michel Liechti
Tobias Klauser
Jay Fenlason