libraw1394 v2.0.0...v2.0.5 takes FW_CDEV_VERSION from an externally
installed header file and uses it to declare its own implementation
level in FW_CDEV_IOC_GET_INFO. This is wrong; it should set the real
version for which it was actually written.
If we add features to the kernel ABI that require the kernel to check
a client's implementation level, we can not trust the client version if
it was set from FW_CDEV_VERSION.
Hence freeze FW_CDEV_VERSION at the current value (no damage has been
done yet), clearly document FW_CDEV_VERSION as a dummy version and what
clients are expected to do with fw_cdev_get_info.version, and use a new
defined constant (which is not placed into the exported header file) as
kernel implementation level.
Note, in order to check in client program source code which features are
present in an externally installed linux/firewire-cdev.h, use
preprocessor directives like
#ifdef FW_CDEV_IOC_ALLOCATE_ISO_RESOURCE
or
#ifdef FW_CDEV_EVENT_ISO_RESOURCE_ALLOCATED
instead of a check of FW_CDEV_VERSION.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If a request comes in to an address range managed by a userspace driver
i.e. <linux/firewire-cdev.h> client, the card instance of request and
response may differ from the card instance of the client device.
Therefore we need to take a reference of the card until the response was
sent.
I thought about putting the reference counting into core-transaction.c,
but the various high-level drivers besides cdev clients (firewire-net,
firewire-sbp2, firedtv) use the card pointer in their fw_address_handler
address_callback method only to look up devices of which they already
hold the necessary references. So this seems to be a specific
firewire-cdev issue which is better addressed locally.
We do not need the reference
- in case of FCP_REQUEST or FCP_RESPONSE requests because then the
firewire-core will send the split transaction response for us
already in the context of the request handler,
- if it is the same card as the client device's because we hold a
card reference indirectly via teh client->device reference.
To keep things simple, we take the reference nevertheless.
Jay Fenlason wrote:
> there's no way for the core to tell cdev "this card is gone,
> kill any inbound transactions on it", while cdev holds the transaction
> open until userspace issues a SEND_RESPONSE ioctl, which may be a very,
> very long time. But when it does, it calls fw_send_response(), which
> will dereference the card...
>
> So how unhappy are we about userspace potentially holding a fw_card
> open forever?
While termination of inbound transcations at card removal could be
implemented, it is IMO not worth the effort. Currently, the effect of
holding a reference of a card that has been removed is to block the
process that called the pci_remove of the card. This is
- either a user process ran by root. Root can find and kill processes
that have /dev/fw* open, if desired.
- a kernel thread (which one?) in case of hot removal of a PCCard or
ExpressCard.
The latter case could be a problem indeed. firewire-core's card
shutdown and card release should probably be improved not to block in
shutdown, just to defer freeing of memory until release.
This is not a new problem though; the same already always happens with
the client->device->card without the need of inbound transactions or
other special conditions involved, other than the client not closing the
file.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
My box has two firewire cards in it: card0 and card1.
My application opens /dev/fw0 (card 0) and allocates an address space.
The core makes the address space available on both cards.
Along comes the remote device, which sends a READ_QUADLET_REQUEST to
card1. The request gets passed up to my application, which calls
ioctl_send_response().
ioctl_send_response() then calls fw_send_response() with card0,
because that's the card it's bound to.
Card0's driver drops the response, because it isn't part of
a transaction that it has outstanding.
So in core-cdev: handle_request(), we need to stash the
card of the inbound request in the struct inbound_transaction_resource and
use that card to send the response to.
The hard part will be refcounting the card correctly
so it can't get deallocated while we hold a pointer to it.
Here's a trivial patch, which does not do the card refcounting, but at
least demonstrates what the problem is.
Note that we can't depend on the fact that the core-cdev:client
structure holds a card open, because in this case the card it holds
open is not the card the request came in on.
..and there's no way for the core to tell cdev "this card is gone,
kill any inbound transactions on it", while cdev holds the transaction
open until userspace issues a SEND_RESPONSE ioctl, which may be a very,
very long time. But when it does, it calls fw_send_response(), which
will dereference the card...
So how unhappy are we about userspace potentially holding a fw_card
open forever?
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Reference counting to be addressed in a separate change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (whitespace)
Protect the client's iso context pointer against a race that can happen
when more than one creation call is executed at the same time.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
void (*fw_address_callback_t)(..., int speed, ...) is the speed that a
remote node chose to transmit a request to us. In case of split
transactions, firewire-core will transmit the response at that speed.
Upper layer drivers on the other hand (firewire-net, -sbp2, firedtv, and
userspace drivers) cannot do anything useful with that speed datum,
except log it for debug purposes. But data that is merely potentially
(not even actually) used for debug purposes does not belong into the API.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
All of the fields of the iso_interrupt_event instance are overwritten
right after it was allocated.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
which caused gcc 4.6 to warn about
variable 'destination' set but not used.
Since the hardware ensures that we receive only response packets with
proper destination node ID (in a given bus generation), we have no use
for destination here in the core as well as in upper layers.
(This is different with request packets. There we pass destination node
ID to upper layers because they may for example need to check whether
this was an unicast or broadcast request.)
Reported-and-Tested-By: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Rather than "read a Control and Status Registers (CSR) Architecture
register" I prefer to say "read a Control and Status Register".
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
All of these CSRs have the same read/ write/ aynthing-else handling,
except for CSR_PRIORITY_BUDGET which might not be implemented.
The CSR_CYCLE_TIME read handler implementation accepted 4-byte-sized
block write requests before this change but this is just silly; the
register is only required to support quadlet read and write requests
like the other r/w CSR core and Serial-Bus-dependent registers.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Push the maintenance of STATE_CLEAR/SET.abdicate down into the card
driver. This way, the read/write_csr_reg driver method works uniformly
across all CSR offsets.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
by feature variables in the fw_card struct. The hook appeared to be an
unnecessary abstraction in the card driver interface.
Cleaner would be to pass those feature flags as arguments to
fw_card_initialize() or fw_card_add(), but the FairnessControl register
is in the SCLK domain and may therefore not be accessible while Link
Power Status is off, i.e. before the card->driver->enable call from
fw_card_add().
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
In case of fw_card_bm_work()'s lock request, the present sizeof
expression is going to be wrong if somebody changes the fw_card's DMA
scratch buffer's size in the future.
In case of quadlet write requests, sizeof(u32) is just silly; it's 4.
In case of SBP-2 ORB pointer write requests, 8 is arguably quicker to
understand as the correct and only possible value than
sizeof(some_datum).
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Add a comment on which of the conflicting NODE_IDS specifications we
implement. Reduce a comment on rather irrelevant register bits that can
all be looked up in the spec (or from now on in the code history).
Directly include the required indirectly included bug.h.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
As part of the bus manager responsibilities, make sure that the cycle
master sends cycle start packets. This is needed when the old bus
manager disabled the cycle master's cmstr bit and there are iso-capable
nodes on the new bus.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
On OHCI 1.1 controllers, let the hardware allocate the broadcast channel
automatically. This removes a theoretical race condition directly after
a bus reset where it could be possible to read the channel allocation
register with channel 31 still being unallocated.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Implement the abdicate bit, which is required for bus manager
capable nodes and tested by the Base 1394 Test Suite.
Finally, something to do at a command reset! :-)
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Implement the cmstr bit, which is required for cycle master capable
nodes and tested for by the Base 1394 Test Suite.
This bit allows the bus master to disable cycle start packets; there are
bus master implementations that actually do this.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Implement the MAIN_UTILITY register, which is utterly optional
but useful as a safe target for diagnostic read/write/broadcast
transactions.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
If supported by the OHCI controller, implement the PRIORITY_BUDGET
register, which is required for nodes that can use asynchronous
priority arbitration.
To allow the core to determine what features the lowlevel device
supports, add a new card driver callback.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Implement the BUS_TIME register, which is required for cycle master
capable nodes and tested for by the Base 1393 Test Suite. Even when
there is not yet bus master initialization support, this register allows
us to work together with other bus masters.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
The specification requires that CYCLE_TIME is writable so that it can be
initialized, so we better implement it.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Implement the SPLIT_TIMEOUT registers. Besides being required by the
spec, this is desirable for some IIDC devices and necessary for many
audio devices to be able to increase the timeout from userspace.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
The NODE_IDS register, and especially its bus_id field, is quite
useless because 1394.1 requires that the bus_id field always stays
0x3ff. However, the 1394 specification requires this register on all
transaction capable nodes, and the Base 1394 Test Suite tests for it,
so we better implement it.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
To prepare for the following additions of more OHCI-implemented CSR
registers, replace the get_cycle_time driver callback with a generic
CSR register callback.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
The state registers are zero and read-only in this implementation, so
they are not of much use. However, the specification requires that they
are present for transaction capable nodes, and the Base 1394 Test Suite
tests for them, so we better implement them.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
When the candidate bus manager fails to do the lock request with which
it tries to become bus manager, it assumes that the current IRM is not
actually IRM capable and forces itself to become root. However, if that
lock request failed because the local node itself was not able to send
it, then we cannot blame the current IRM and should not steal its
rootness.
In this case, RCODE_SEND_ERROR is likely to indicate a temporary error
condition such as exhausted tlabels or low memory, so we better try
again later.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Most PHY chips, when idle, can complete a register access in the time
needed for two or three PCI read transactions; bigger delays occur only
when data is currently being moved over the link/PHY interface. So if
we busy-wait a few times when waiting for the register access to finish,
it is likely that we can finish without having to sleep.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Add a check that the data length in the SEND_RESPONSE ioctl is correct.
Incidentally, this also fixes the previously wrong response length of
software-handled lock requests.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This patch adds support for message-signaled interrupts.
Any native PCI-Express OHCI controller should support MSI, but most are
just PCI cores behind a PCI-E/PCI bridge. The only chips that are known
to claim to support MSI are the Lucent/Agere/LSI FW643 and the VIA
VT6315, none of which I have been able to test.
Due to the high level of trust I have in the competence of these and any
future chip makers, I thought it a good idea to add a disable-MSI quirk.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Tested Agere FW643 rev 07 [11c1:5901] and JMicron JMB381 [197b:2380].
Added a quirks list entry for JMB38X since it kept its count of MSI
events consistently at zero.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
On 26 Apr 2010, Clemens Ladisch wrote:
> In theory, none of the interrupts should occur before the link is
> enabled. In practice, I'd rather make sure to not set the master
> interrupt enable bit until we have installed the interrupt handler.
and proposed to move OHCI1394_masterIntEnable out of the present
reg_write() into a new one before the HCControl.linkEnable reg_write().
Why not defer setting /all/ of the bits until right before linkEnable?
Reviewed-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Per IEEE 1394 clause 8.4.2.3, a contender for the IRM role shall check
whether the current IRM complies to 1394a-2000 or later. If not force a
compliant node (e.g. itself) to become IRM. This was implemented in the
older ieee1394 driver but not yet in firewire-core.
An older Sony camcorder (Sony DCR-TRV25) which implements 1394-1995 IRM
but neither 1394a-2000 IRM nor BM was now found to cause an
interoperability bug:
- Camcorder becomes root node when plugged in, hence gets IRM role.
- firewire-core successfully contends for BM role, proceeds to perform
gap count optimization and resets the bus.
- Sony camcorder ignores presence of a BM (against the spec, this is
a firmware bug), performs its idea of gap count optimization and
resets the bus.
- Preceding two steps are repeated endlessly, bus never settles,
regular I/O is practically impossible.
http://thread.gmane.org/gmane.linux.kernel.firewire.user/3913
This is an interoperability regression from the old to the new drivers.
Fix it indirectly by adding the 1394a IRM check. The spec suggests
three and a half methods to determine 1394a compliance of a remote IRM;
we choose the method of testing the Config_ROM.Bus_Info.generation
field. This is data that firewire-core should have readily available at
this point, i.e. does not require extra I/O.
Reported-by: Clemens Ladisch <clemens@ladisch.de> (missing 1394a check)
Reported-by: H. S. <hs.samix@gmail.com> (issue with Sony DCR-TRV25)
Tested-by: H. S. <hs.samix@gmail.com>
Cc: <stable@kernel.org> # .32.x and newer
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
ieee1394: schedule for removal
firewire: core: use separate timeout for each transaction
firewire: core: Fix tlabel exhaustion problem
firewire: core: make transaction label allocation more robust
firewire: core: clean up config ROM related defined constants
ieee1394: mark char device files as not seekable
firewire: cdev: mark char device files as not seekable
firewire: ohci: cleanups and fix for nonstandard build without debug facility
firewire: ohci: wait for PHY register accesses to complete
firewire: ohci: fix up configuration of TI chips
firewire: ohci: enable 1394a enhancements
firewire: ohci: do not clear PHY interrupt status inadvertently
firewire: ohci: add a function for reading PHY registers
Trivial conflicts in Documentation/feature-removal-schedule.txt
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (44 commits)
vlynq: make whole Kconfig-menu dependant on architecture
add descriptive comment for TIF_MEMDIE task flag declaration.
EEPROM: max6875: Header file cleanup
EEPROM: 93cx6: Header file cleanup
EEPROM: Header file cleanup
agp: use NULL instead of 0 when pointer is needed
rtc-v3020: make bitfield unsigned
PCI: make bitfield unsigned
jbd2: use NULL instead of 0 when pointer is needed
cciss: fix shadows sparse warning
doc: inode uses a mutex instead of a semaphore.
uml: i386: Avoid redefinition of NR_syscalls
fix "seperate" typos in comments
cocbalt_lcdfb: correct sections
doc: Change urls for sparse
Powerpc: wii: Fix typo in comment
i2o: cleanup some exit paths
Documentation/: it's -> its where appropriate
UML: Fix compiler warning due to missing task_struct declaration
UML: add kernel.h include to signal.c
...
Using a single timeout for all transaction that need to be flushed does
not work if the submission of new transactions can defer the timeout
indefinitely into the future. We need to have timeouts that do not
change due to other transactions; the simplest way to do this is with a
separate timer for each transaction.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (+ one lockdep annotation)
fw_core_handle_response() was not properly clearing tlabel_mask. This
was resulting in premature tlabel exhaustion.
Signed-off-by: Peter Hurley <phurley@charter.net>
This fixes an omission in 2.6.31-rc1 commit 1e626fdc "firewire: core:
use more outbound tlabels" which prevented to really use 64 instead of
32 transaction labels, as soon as split transactions occurred that had
their AR-resp tasklet run after the AT-req tasklet.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
firewire: ohci: wait for local CSR lock access to finish
firewire: ohci: prevent aliasing of locally handled register addresses
firewire: core: fw_iso_resource_manage: return -EBUSY when out of resources
firewire: core: fix retries calculation in iso manage_channel()
firewire: cdev: fix cut+paste mistake in disclaimer
If one request is so long-lived that it does not get a response before
the following 63 requests, its bit in tlabel_mask is still set when the
next request tries to allocate a transaction label for that number. In
this state, while the first request is not completed or timed out, no
new requests can be submitted.
To fix this, skip over any label still in use, and do not error out
unless we have entirely run out of labels.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Clemens Ladisch pointed out that
- BIB_IMC is not named like the field is called in the standard,
- readers of the code may get worried about the magic 0x0c0083c0,
- a CSR_NODE_CAPABILITIES key is there in the header but not put to
good use.
So let's rename BIB_IMC, add a defined constant for Node_Capabilities
and a comment which reassures people that somebody thought about it and
they don't have to (or if they still do, tell them where they have to
look for confirmation), and prune our incomplete and arbitrary set of
defined constants of CSR key IDs. And there is a nother magic number,
that of Bus_Information_Block.Bus_Name, to be defined and commented.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Add a loop to wait for the controller to finish a locally-initiated CSR
lock operation. Google shows some occurrences of the "swap not done
yet" message which might indicate that some OHCI controllers are not
fast enough to do the lock/swap in the time needed for one PCI access.
This also correctly handles the case where the lock operation did not
finish, instead of silently returning an uninitialized value.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
We must compute the offset from the CSR register base with the
full 48 address bits to prevent matching with addresses whose
lower 32 bits happen to be equal with one of the specially
handled registers.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Returning -EIO for all errors would not allow clients to determine if
the resource allocation process itself failed, or if the resources are
not available. (The latter information is needed by CMP to synchronize
restoring of overlayed connections after a bus reset.)
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If there is a permanent error condition when communicating with the IRM,
after the sixth error, the retry variable will be decremented to -1.
If, in this case, the bits in channels_mask are not yet exhausted, the
next channel is retried 2^32 times.
To fix this, check that retry is never decremented beyond zero.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The <linux/firewire-cdev.h> character device file ABI (i.e. /dev/fw*
character device file interface) does not make any use of lseek(),
pread(), pwrite() (or any kind of write() at all).
Use nonseekable_open() and, redundantly, set file_operations.llseek to
no_llseek to remove any doubt whether the BKL-grabbing default_llseek
handler is used. (Also shuffle file_operations initialization according
to the order of handler definitions.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
1) Clean up two function names: The ohci_ prefix is only used in names
of fw_card_driver hooks. There were two unnecessary exceptions.
2) Replace empty macros by empty inline functions so that call parameter
type checking is available in #ifndef'd builds.
3) CONFIG_FIREWIRE_OHCI_DEBUG is currently a hidden kconfig variable,
hence is not going to be switched off by anybody. Still, it can be
switched off but then compilation will fail in ohci_enable() at the
expression param_debug & OHCI_PARAM_DEBUG_BUSRESETS. Add the necessary
definitions in the nonstandard case.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Rather than having the arbitrary msleep(2) pause, let read_phy_reg()
loop until the link--phy access was finished.
Factor write_phy_reg() out of ohci_update_phy_reg() and of
read_paged_phy_reg() and let it loop too until the link--phy access was
finished.
Like in the older ohci1394 driver, a timeout of 100 milliseconds is
chosen. Unlike the old driver, we sleep instead of busy-wait in each
waiting loop iteration. Instead of a loop, the waiting could probably
also be implemented interrupt driven, but why bother. It would require
up and running interrupt handling before the link was fully configured
and enabled.
Also modify functions a bit: Error return and value return can be
combined in read_phy_reg() since the domain of values is only u8.
Likewise in read_paged_phy_reg().
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
On TI chips (OHCI-Lynx and later), enable link enhancements features
that TI recommends to be used. None of these are required for proper
operation, but they are safe and nice to have.
In theory, these bits should have been set by default, but in practice,
some BIOS/EEPROM writers apparently do not read the datasheet, or get
spooked by names like "unfair".
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The OHCI spec says that, if the programPhyEnable bit is set, the driver
is responsible for configuring the IEEE1394a enhancements within the PHY
and the link consistently. So do this.
Also add a quirk to allow disabling these enhancements; this is needed
for the TSB12LV22 where ack accelerations are buggy (erratum b).
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The interrupt status bits in PHY register 5 are cleared by writing a one
bit. To avoid clearing them unadvertently, do not write them back when
they were read as set, but only when they have been explicitly requested
to be set.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Move the register reading code from ohci_update_phy_reg() into
a function which can be used separately.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
A userspace client got to see uninitialized stack-allocated memory if it
specified an _IOC_READ type of ioctl and an argument size larger than
expected by firewire-core's ioctl handlers (but not larger than the
core's union ioctl_arg).
Fix this by clearing the requested buffer size to zero, but only at _IOR
ioctls. This way, there is almost no runtime penalty to legitimate
ioctls. The only legitimate _IOR is FW_CDEV_IOC_GET_CYCLE_TIMER with 12
or 16 bytes to memset.
[Another way to fix this would be strict checking of argument size (and
possibly direction) vs. command number. However, we then need a lookup
table, and we need to allow for slight size deviations in case of 32bit
userland on 64bit kernel.]
Reported-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The definition of struct fw_cdev_iso_packet seems to imply that the
header_length must be quadlet-aligned, and in fact, specifying an
unaligned header has never really worked when using multiple packet
structures, because the position of the next control word is computed by
rounding the header_length _down_, so the last one to three bytes of the
header would overlap the next control word.
To avoid this problem, check that the header length is properly aligned.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
In receive contexts, reject packets with header_length==0. This would
be an instruction to queue zero packets which would not make sense.
This prevents a division by zero in the OHCI driver.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
firewire: core: align driver match with modalias
firewire: core: fix Model_ID in modalias
firewire: ohci: add cycle timer quirk for the TI TSB12LV22
firewire: core: fw_iso_resource_manage: fix error handling
The driver match strategy was:
- Match vendor/model/specifier/version of the unit directory.
- If that was a miss, match vendor from the root directory and
model/specifier/version of the unit directory.
This was inconsistent with how the modalias string was constructed
until recently (take vendor/model from root directory and specifier/
version from unit directory). It was also inconsistent with how it is
done since the parent commit:
- Use vendor/model/specifier/version of the unit directory if possible,
- fall back to one or more of vendor/model/specifier/version from the
root directory depending on which ones are not present at the unit
directory.
Fix this inconsistency by sharing the ROM scanner function between
modalias printer function and driver match function.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The modalias string of devices that represent units on a FireWire node
did not show Module_ID entries within unit directories. This was
because firewire-core searched only the root directory of the
configuration ROM for a Model_ID entry.
We now search first the root directory, then the unit directory. IOW
honor a unit directory's Model_ID if present, otherwise fall back to the
root directory's model ID (if present).
Furthermore, apply the same change to Vendor_ID. This had the same
issue but it was less apparent because most devices provide Vendor_ID
only in the root directory.
And finally, also use this strategy for the remaining two IDs in the
modalias, Specifier_ID and Version. It does not actually make sense to
look for them elsewhere than in the unit directory because they are
mandatory there. However, a uniform search order simplifies the
implementation and has no adverse affect in practice.
Side notes:
- The older counterpart of this, nodemgr.c of ieee1394, looked for
Vendor_ID first in the root directory, then in the unit directory,
and for Model_ID only in the unit directory.
- There is a single mainline driver which requires Vendor_ID and
Model_ID --- the firedtv driver. This one worked because FireDTVs
provide Vendor_ID in the root directory and Model_ID identically in
root directory and unit directory.
- Apart from firedtv, there are currently no drivers known to me
(including userspace drivers) that look at the Vendor_ID or Model_ID
of the modalias.
Reported-by: Maciej Żenczykowski <zenczykowski@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Among the many entries in the TSB12LV22 errata list (TI literature
number SLLS312) is the following:
PCI Slave reads of the Cycle Timer register may occasionally get an
incorrect value.
Software may be able to validate value by reading the register
multiple times rapidly and evaluating for a reasonable difference.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de> (untested)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (added #define)
If the bandwidth allocation fails, the error must be returned in
*channel regardless of whether the channel allocation succeeded.
Checking for c >= 0 is not correct if no channel allocation was
requested, in which case this part of the code is reached with
c == -EINVAL.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
In the future, we are going to be changing the lock type for struct
device (once we get the lockdep infrastructure properly worked out) To
make that changeover easier, and to possibly burry the lock in a
different part of struct device, let's create some functions to lock and
unlock a device so that no out-of-core code needs to be changed in the
future.
This patch creates the device_lock/unlock/trylock() functions, and
converts all in-tree users to them.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Len Brown <len.brown@intel.com>
Cc: Magnus Damm <damm@igel.co.jp>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Alex Chiang <achiang@hp.com>
Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Patterson <andrew.patterson@hp.com>
Cc: Yu Zhao <yu.zhao@intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: CHENG Renquan <rqcheng@smu.edu.sg>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: Frans Pop <elendil@planet.nl>
Cc: David Vrabel <david.vrabel@csr.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: (23 commits)
firewire: ohci: extend initialization log message
firewire: ohci: fix IR/IT context mask mixup
firewire: ohci: add module parameter to activate quirk fixes
firewire: ohci: use an ID table for quirks detection
firewire: ohci: reorder struct fw_ohci for better cache efficiency
firewire: ohci: remove unused dualbuffer IR code
firewire: core: combine a bit of repeated code
firewire: core: change type of a data buffer
firewire: cdev: increment ABI version number
firewire: cdev: add more flexible cycle timer ioctl
firewire: core: rename an internal function
firewire: core: fix an information leak
firewire: core: increase stack size of config ROM reader
firewire: core: don't fail device creation in case of too large config ROM blocks
firewire: core: fix "giving up on config rom" with Panasonic AG-DV2500
firewire: remove incomplete Bus_Time CSR support
firewire: get_cycle_timer optimization and cleanup
firewire: ohci: enable cycle timer fix on ALi and NEC controllers
firewire: ohci: work around cycle timer bugs on VIA controllers
firewire: make PCI device id constant
...
The block layer calling convention is blk_queue_<limit name>.
blk_queue_max_sectors predates this practice, leading to some confusion.
Rename the function to appropriately reflect that its intended use is to
set max_hw_sectors.
Also introduce a temporary wrapper for backwards compability. This can
be removed after the merge window is closed.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
by the number of available isochronous DMA contexts and active quirks
which is occasionally useful information.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This bug was present in firewire-ohci since day one: The number of
available isochronous receive DMA contexts was mixed up with that of
available isochronous transmit DMA contexts.
This is harmless on a few chips which offer the same number of contexts
in both directions, but most chips nowadays implement only the standard
minimum of 4 IR contexts, but 8 IT contexts. If a user attempted to run
a lot of IR contexts at once, results with more than four were therefore
unpredictable. I suppose the controller would simply refuse to start
DMA of any unimplemented context.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This way, we can advise users of precompiled kernel packages to test
existing quirk fixes on chips which have not been listed yet, without
them having to build a kernel from source.
Note, to use this feature on a machine with more than one controller,
steps like these are necessary:
# lspci | grep 1394
# ls /sys/bus/pci/drivers/firewire_ohci/
# echo -n "0000:03:02.0" > /sys/bus/pci/drivers/firewire_ohci/unbind
# echo 2 > /sys/module/firewire_ohci/parameters/quirks
# echo -n "0000:03:02.0" > /sys/bus/pci/drivers/firewire_ohci/bind
# echo 0 > /sys/module/firewire_ohci/parameters/quirks
The parameter can also be used to switch off quirk flags that were
hardwired into firewire-ohci's quirks table. Simply specify a non-zero
quirks value but without any known flags, e.g. 0x100.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
We don't have a lot of quirks to take into account (especially since
dual-buffer IR is out of the picture), but still, a table-based approach
is more organized than a series of if () clauses.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The config_rom struct members are only accessed during relatively
infrequent self-ID-complete interrupts and only if the local config ROM
was changed, while the ar_, at_, ir_, it_ members are used very
frequently during I/O. Hence move the config_rom members further down.
More importantly, make the huge self_id_buffer member the last one; this
is only accessed in self-ID-complete interrupts.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This code was no longer used since 2.6.33, "firewire: ohci: always use
packet-per-buffer mode for isochronous reception" commit 090699c0. If
anybody needs this code in the future for special purposes, it can be
brought back in. But it must not be re-enabled by default; drivers
(kernelspace or userspace drivers) should only get this mode if they
explicitly request it.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
from array of char to union of structs. I already used a union to size
the buffer which holds ioctl arguments; more consequent is to define it
as an instance of this union in the first place.
Also rename several local variables from "request" to "a"(rgument) since
the term request can be mistaken to mean a transaction subaction, e.g.
an instance of struct fw_request.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The system time from CLOCK_REALTIME is not monotonic, hence problematic
for the main user of the FW_CDEV_IOC_GET_CYCLE_TIMER ioctl. This issue
exists in its successor ABI, i.e. raw1394, too.
http://subversion.ffado.org/ticket/242
We now offer an alternative ioctl which lets the caller choose between
CLOCK_REALTIME, CLOCK_MONOTONIC, and CLOCK_MONOTONIC_RAW as source of
the local time, very similar to the clock_gettime libc function. The
format of the local time return value matches that of clock_gettime
(seconds and nanoseconds, instead of a single microseconds value from
the existing ioctl).
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If a device exposes a sparsely populated configuration ROM,
firewire-core's sysfs interface and character device file interface
showed random data in the gaps between config ROM blocks. Fix this by
zero-initialization of the config ROM reader's scratch buffer.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The stack size of 16 was artificially chosen and may be too small in
extreme cases. A device won't be accessible then.
Since it doesn't really matter to the slab allocator whether we ask for
1088 bytes or 2048 bytes of scratch memory, just allocate 2048 bytes for
the sum of temporary config ROM image and stack, and we will never ever
overflow the stack (because there simply can't be more stack items than
ROM entries).
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
It never happened yet, but better safe than sorry: If a device's config
ROM contains a block which overlaps the boundary at 0xfffff00007ff, just
ignore that one block instead of refusing to add the device
representation. That way, upper layers (kernelspace or userspace
drivers) might still be able to use the device to some degree.
That's better than total inaccessibility of the device. Worse, the core
would have logged only a generic "giving up on config rom" message which
could only be debugged by feeding a firewire-ohci debug logging session
through a config ROM interpreter, IOW would likely remain undiagnosed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The Panasonic AG-DV2500 tape deck contains an invalid entry in its
configuration ROM root directory: A leaf pointer with the undefined key
ID 0 and an offset that points way out of the standard config ROM area.
This caused firewire-core to dismiss the device with the generic log
message "giving up on config rom for node id...", after which it was of
course impossible to access the tape deck with dvgrab or any other
program. https://bugzilla.redhat.com/show_bug.cgi?id=449252#c29
The fix is to simply ignore this invalid ROM entry and proceed to read
the valid rest of the ROM. There is a catch though: When the kernel
later iterates over the ROM, it would be nasty having to check again for
such too large ROM offsets. Therefore we manipulate the defective or
unsupported ROM entry to become a harmless immediate entry that won't
have any side effects later (an entry with the value 0x00000000).
Reported-by: George Chriss
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The current implementation of Bus_Time read access was buggy since it
did not ensure that Bus_Time.second_count_hi and second_count_lo came
from the same 128 seconds period.
Reported-by: Håkan Johansson <f96hajo@chalmers.se>
Instead of a fix, remove Bus_Time register support altogether. The spec
requires all cycle master capable nodes to implement this (all Linux
nodes are cycle master capable) while it also says that it "may" be
initialized by the bus manager or by the IRM standing in for a bus
manager. (Neither Linux' firewire-core nor ieee1394 nodemgr implement
this.)
Since we cannot rely on Bus_Time having been initialized by a bus
manager, it is better to return an error instead of a nonsensical value
on a read request to Bus_Time.
Alternatively, we could fix the Bus_Time read integrity bug _and_
implement (a) cycle master's write support of the register as well as
(b) bus manager's Bus_Time initialization service, i.e. preservation of
the Bus_Time when the cycle master node of a bus changes. However, that
would be quite some code for a feature that is unreliable to begin with
and very likely unused in practice.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
ohci: Break out of the retry loop if too many attempts were necessary.
This may theoretically happen if the chip is fatally defective or if the
get_cycle_timer ioctl was performed after a CardBus controller was
ejected.
Also micro-optimize the loop by re-using the last two register reads in
the next iteration, remove a questionable inline keyword, and shuffle a
comment around.
core: ioctl_get_cycle_timer() is always called with interrupts on,
therefore local_irq_save() can be replaced by local_irq_disable().
Disabled local IRQs imply disabled preemption, hence preempt_disable()
can be removed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Discussed in "read_cycle_timer backwards for sub-cycle 0000, 0001",
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13704
Known bad controllers:
ALi M5271, listed by lspci as M5253 [10b9:5253]
NEC OrangeLink [1033:00cd] (rev 03)
NEC uPD72874 [1033:00f2] (rev 01)
VIA VT6306 [1106:3044] (rev 46)
VIA VT6308P, listed by lspci as rev c0
Reported-by: Pieter Palmers <pieterp@joow.be>
Reported-by: Håkan Johansson <f96hajo@chalmers.se>
Reported-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
VIA controllers sometimes return an inconsistent value when reading the
isochronous cycle timer register. To work around this, read the
register multiple times and add consistency checks.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reported-by: Pieter Palmers <pieterp@joow.be>
Reported-by: Håkan Johansson <f96hajo@chalmers.se>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
In isochronous transmit DMA descriptors, link the skip address pointer
back to the descriptor itself. When a cycle is lost, the controller
will send the packet in the next cycle, instead of terminating the
entire DMA program.
There are two reasons for this:
* This behaviour is compatible with the old IEEE1394 stack. Old
applications would not expect the DMA program to stop in this case.
* Since the OHCI driver does not report any uncompleted packets, the
context would stop silently; clients would not have any chance to
detect and handle this error without a watchdog timer.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Pieter Palmers notes:
"The reason I added this retry behavior to the old stack is because some
cards now and then fail to send a packet (e.g. the o2micro card in my
dell laptop). I couldn't figure out why exactly this happens, my best
guess is that the card cannot fetch the payload data on time. This
happens much more frequently when sending large packets, which leads me
to suspect that there are some contention issues with the DMA that fills
the transmit FIFO.
In the old stack it was a pretty critical issue as it resulted in a
freeze of the userspace application.
The omission of a packet doesn't necessarily have to be an issue. E.g.
in IEC61883 streams the DBC field can be used to detect discontinuities
in the stream. So as long as the other side doesn't bail when no
[packet] is present in a cycle, there is not really a problem.
I'm not convinced though that retrying is the proper solution, but it is
simple and effective for what it had to do. And I think there are no
reasons not to do it this way. Userspace can still detect this by
checking the cycle the descriptor was sent in."
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, comment)
In the transmit path of firewire-net (IPv4 over 1394), the following
race condition may occur:
- The networking soft IRQ inserts a datagram into the 1394 async
request transmit DMA.
- The 1394 async transmit completion tasklet runs to finish cleaning
up (unlink datagram from list of pending ones, release skb and
outbound 1394 transaction object) --- before the networking soft IRQ
had a chance to proceed and add the datagram to the list of pending
datagrams.
This caused a panic in the 1394 async transmit completion tasklet when
it dereferenced unitialized list heads:
http://bugzilla.kernel.org/show_bug.cgi?id=15077
The fix is to add checks in the tx soft IRQ and in the tasklet to
determine which of these two is the last referrer to the transaction
object. Then handle the cleanup of the object by the last referrer
rather than assuming that the tasklet is always the last one.
There is another similar race: Between said tasklet and fwnet_close,
i.e. at ifdown. However, that race is much less likely to occur in
practice and shall be fixed in a separate update.
Reported-by: Илья Басин <basinilya@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Unsurprisingly, Texas Instruments TSB43AB23 exhibits the same behaviour
as TSB43AB22/A in dual buffer IR DMA mode: If descriptors are located
at physical addresses above the 31 bit address range (2 GB), the
controller will overwrite random memory. With luck, this merely
prevents video reception. With only a little less luck, the machine
crashes.
We use the same workaround here as with TSB43AB22/A: Switch off the
dual buffer capability flag and use packet-per-buffer IR DMA instead.
Another possible workaround would be to limit the coherent DMA mask to
31 bits.
In Linux 2.6.33, this change serves effectively only as documentation
since dual buffer mode is not used for any controller anymore. But
somebody might want to re-enable it in the future to make use of
features of dual buffer DMA that are not available in packet-per-buffer
mode.
In Linux 2.6.32 and older, this update is vital for anyone with this
controller, more than 2 GB RAM, a 64 bit kernel, and FireWire video or
audio applications.
We have at least four reports:
http://bugzilla.kernel.org/show_bug.cgi?id=13808http://marc.info/?l=linux1394-user&m=126154279004083https://bugzilla.redhat.com/show_bug.cgi?id=552142http://marc.info/?l=linux1394-user&m=126432246128386
Reported-by: Paul Johnson
Reported-by: Ronneil Camara
Reported-by: G Zornetzer
Reported-by: Mark Thompson
Cc: stable@kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Commit db5d247a "firewire: fix use of multiple AV/C devices, allow
multiple FCP listeners" introduced a regression into 2.6.33-rc3:
The core freed payloads of incoming requests to FCP_Request or
FCP_Response before a userspace driver accessed them.
We need to copy such payloads for each registered userspace client
and free the copies according to the lifetime rules of non-FCP client
request resources.
(This could possibly be optimized by reference counts instead of
copies.)
The presently only kernelspace driver which listens for FCP requests,
firedtv, was not affected because it already copies FCP frames into an
own buffer before returning to firewire-core's FCP handler dispatcher.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Presently, firewire-core only checks whether descriptors that are to be
added by userspace drivers to the local node's config ROM do not exceed
a size of 256 quadlets. However, the sum of the bare minimum ROM plus
all descriptors (from firewire-core, from firewire-net, from userspace)
must not exceed 256 quadlets.
Otherwise, the bounds of a statically allocated buffer will be
overwritten. If the kernel survives that, firewire-core will
subsequently be unable to parse the local node's config ROM.
(Note, userspace drivers can add descriptors only through device files
of local nodes. These are usually only accessible by root, unlike
device files of remote nodes which may be accessible to lesser
privileged users.)
Therefore add a test which takes the actual present and required ROM
size into account for all descriptors of kernelspace and userspace
drivers.
Cc: stable@kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The id_table field of the struct pci_driver is constant in <linux/pci.h>
so it is worth to make pci_table also constant. Found with Coccinelle.
Signed-off-by: Márton Németh <nm127@freemail.hu>
Cc: Julia Lawall <julia@diku.dk>
Cc: cocci@diku.dk
Signed-off-by: Stefan Richter stefanr@s5r6.in-berlin.de> (changelog)
Several config ROM related functions only peek at the ROM cache; mark
their arguments as const pointers. Ditto fw_device.config_rom and
fw_unit.directory, as the memory behind them is meant to be write-once.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Update the Kconfig help texts of both stacks to encourage a general move
from the older to the newer drivers. However, do not label ieee1394 as
"Obsolete" yet, as the newer drivers have not been deployed as default
stack in the majority of Linux distributions yet, and those who start
doing so now may still want to install the old drivers as fallback for
unforeseen issues.
Since Linux 2.6.32, FireWire audio devices can be driven by the newer
firewire driver stack too, hence remove an outdated comment about audio
devices. Also remove comments about library versions since the 2nd
generation of libraw1394 and libdc1394 is now in common use; details on
library versions can be read at the wiki link from the help texts.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The core (sysfs attributes), the firedtv driver, and possible future
drivers all read strings from some configuration ROM directory. Factor
out the generic code from show_text_leaf() into a new helper function,
modified slightly to handle arbitrary buffer sizes.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This is a minimal change meant for the short term: Never set the
ohci->use_dualbuffer flag to true.
There are two reasons to do so:
- Packet-per-buffer mode and dual-buffer mode do not behave the same
under certain circumstances, notably if several packets are covered
by a single fw_cdev_iso_packet descriptor.
http://marc.info/?l=linux1394-devel&m=124965653718313
Therefore the driver stack should not silently choose one or the
other mode but should leave the choice to the high-level driver
(regardless if kernel driver or userspace driver). Or simply always
only offer packet-per-buffer mode, since a considerable number of
controllers, even current ones, does not offer dual-buffer support.
- Even under circumstances where packet-per-buffer mode and
dual-buffer mode behave exactly the same --- notably when used
through libraw1394, libdc1394, as well as the current two kernel
drivers which use isochronous reception (firewire-net and firedtv)
--- we are still faced with the problem that several OHCI 1.1
controllers have bugs in dual-buffer mode. Although it looks like
we have identified most of those buggy controllers by now, we
cannot be quite sure about that.
So, use packet-per-buffer by default from now on. This change should
be followed up by a more complete solution: Either extend the
in-kernel API and the userspace ABI by a choice between the two IR modes
or remove all dual-buffer related code from firewire-ohci.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If copy_from_user in an FW_CDEV_IOC_SEND_RESPONSE ioctl failed, the
fw_request pointed to by the inbound_transaction_resource is no
longer referenced and needs to be freed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Control of more than one AV/C device at once --- e.g. camcorders, tape
decks, audio devices, TV tuners --- failed or worked only unreliably,
depending on driver implementation. This affected kernelspace and
userspace drivers alike and was caused by firewire-core's inability to
accept multiple registrations of FCP listeners.
The fix allows multiple address handlers to be registered for the FCP
command and response registers. When a request for these registers is
received, all handlers are invoked, and the Firewire response is
generated by the core and not by any handler.
The cdev API does not change, i.e., userspace is still expected to send
a response for FCP requests; this response is silently ignored.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, rebased, whitespace)
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
firewire: ohci: handle receive packets with a data length of zero
