It is wrong to set skb->ip_summed to CHECKSUM_UNNECESSARY unless
the device has already checked it.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull trivial branch from Jiri Kosina:
"Usual stuff -- comment/printk typo fixes, documentation updates, dead
code elimination."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits)
HOWTO: fix double words typo
x86 mtrr: fix comment typo in mtrr_bp_init
propagate name change to comments in kernel source
doc: Update the name of profiling based on sysfs
treewide: Fix typos in various drivers
treewide: Fix typos in various Kconfig
wireless: mwifiex: Fix typo in wireless/mwifiex driver
messages: i2o: Fix typo in messages/i2o
scripts/kernel-doc: check that non-void fcts describe their return value
Kernel-doc: Convention: Use a "Return" section to describe return values
radeon: Fix typo and copy/paste error in comments
doc: Remove unnecessary declarations from Documentation/accounting/getdelays.c
various: Fix spelling of "asynchronous" in comments.
Fix misspellings of "whether" in comments.
eisa: Fix spelling of "asynchronous".
various: Fix spelling of "registered" in comments.
doc: fix quite a few typos within Documentation
target: iscsi: fix comment typos in target/iscsi drivers
treewide: fix typo of "suport" in various comments and Kconfig
treewide: fix typo of "suppport" in various comments
...
Here's the large driver core updates for 3.8-rc1.
The biggest thing here is the various __dev* marking removals. This is
going to be a pain for the merge with different subsystem trees, I know,
but all of the patches included here have been ACKed by their various
subsystem maintainers, as they wanted them to go through here.
If this is too much of a pain, I can pull all of them out of this tree
and just send you one with the other fixes/updates and then, after
3.8-rc1 is out, do the rest of the removals to ensure we catch them all,
it's up to you. The merges should all be trivial, and Stephen has been
doing them all in linux-next for a few weeks now quite easily.
Other than the __dev* marking removals, there's nothing major here, some
firmware loading updates and other minor things in the driver core.
All of these have (much to Stephen's annoyance), been in linux-next for
a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEABECAAYFAlDHkPkACgkQMUfUDdst+ykaWgCfW7AM30cv0nzoVO08ax6KjlG1
KVYAn3z/KYazvp4B6LMvrW9y0G34Wmad
=yvVr
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg Kroah-Hartman:
"Here's the large driver core updates for 3.8-rc1.
The biggest thing here is the various __dev* marking removals. This
is going to be a pain for the merge with different subsystem trees, I
know, but all of the patches included here have been ACKed by their
various subsystem maintainers, as they wanted them to go through here.
If this is too much of a pain, I can pull all of them out of this tree
and just send you one with the other fixes/updates and then, after
3.8-rc1 is out, do the rest of the removals to ensure we catch them
all, it's up to you. The merges should all be trivial, and Stephen
has been doing them all in linux-next for a few weeks now quite
easily.
Other than the __dev* marking removals, there's nothing major here,
some firmware loading updates and other minor things in the driver
core.
All of these have (much to Stephen's annoyance), been in linux-next
for a while.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"
Fixed up trivial conflicts in drivers/gpio/gpio-{em,stmpe}.c due to gpio
update.
* tag 'driver-core-3.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (93 commits)
modpost.c: Stop checking __dev* section mismatches
init.h: Remove __dev* sections from the kernel
acpi: remove use of __devinit
PCI: Remove __dev* markings
PCI: Always build setup-bus when PCI is enabled
PCI: Move pci_uevent into pci-driver.c
PCI: Remove CONFIG_HOTPLUG ifdefs
unicore32/PCI: Remove CONFIG_HOTPLUG ifdefs
sh/PCI: Remove CONFIG_HOTPLUG ifdefs
powerpc/PCI: Remove CONFIG_HOTPLUG ifdefs
mips/PCI: Remove CONFIG_HOTPLUG ifdefs
microblaze/PCI: Remove CONFIG_HOTPLUG ifdefs
dma: remove use of __devinit
dma: remove use of __devexit_p
firewire: remove use of __devinitdata
firewire: remove use of __devinit
leds: remove use of __devexit
leds: remove use of __devinit
leds: remove use of __devexit_p
mmc: remove use of __devexit
...
The variable card is initialized but never used
otherwise, so remove the unused variable.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This patch fixes both the transmit and receive portion of sending
fragmented mutlicast and broadcast packets.
The transmit section was broken because the offset for INTFRAG and
LASTFRAG packets were just miscalculated by IEEE1394_GASP_HDR_SIZE (which
was reserved with skb_push() in fwnet_send_packet).
The receive section was broken because in fwnet_incoming_packet is a call
to fwnet_peer_find_by_node_id(). Called with generation == -1 it will
not find a peer and the partial datagrams are associated to a peer.
[Stefan R: The fix to use context->card->generation is not perfect.
It relies on the IR tasklet which processes packets from the prior bus
generation to run before the self-ID-complete worklet which sets the
current card generation. Alas, there is no simple way of a race-free
implementation. Let's do it this way for now.]
Signed-off-by: Stephan Gatzka <stephan.gatzka@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The commits
3c6bdaeab4 "[SCSI] Add a report opcode helper"
5db44863b6 "[SCSI] sd: Implement support for WRITE SAME"
introduced in-kernel uses of the mentioned commands but cautiously
blacklisted them for any IEEE 1394 (SBP-2/3) targets and some other
transports.
I looked through a range of SBP devices and found that the blacklist
flags can be removed:
The kernel never attempts these commands if the device's INQUIRY
data claim a SCSI revision of less than 0x05. This is the case with
all SBP devices that I checked, except for three more recent devices
which claimed a revision of 0x05 i.e. conformance with SPC-3 (two
devices based on the OXUF936QSE chip but having different firmwares,
one based on OXUF934DSB.)
I tried "sg_opcodes" from sg3_utils on several older and newer devices
and did not encounter any apparent firmware bugs with it. All devices
returned Illegal Request/ Invalid command operation code and carried on.
I furthermore tried "sg_write_same -U" on the OXUF934DSB device with the
same result. Alas I did not have a TRIM enabled SSD available for these
tests. All of the bridges were correctly identified by the kernel as
"fully provisioned", CD-ROM devices aside.
The kernel won't issue WRITE SAME to fully provisioned devices, nor
would it attempt REPORT SUPPORTED OPERATION CODES or WRITE SAME with
UNMAP bit on devices which do not claim conformance to SPC-3 or later.
Hence let's remove the no_report_opcodes and no_write_same blacklist
flags so that these commands can be used on newer targets with
respective capabilities. I guess the Linux sbp-target could be such a
target.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
CONFIG_HOTPLUG is going away as an option so __devinitdata is no
longer needed.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CONFIG_HOTPLUG is going away as an option so __devinit is no longer
needed.
Signed-off-by: Bill Pemberton <wfp5p@virginia.edu>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
"Asynchronous" is misspelled in some comments. No code changes.
Signed-off-by: Adam Buchbinder <adam.buchbinder@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Implement support for WRITE SAME(10) and WRITE SAME(16) in the SCSI disk
driver.
- We set the default maximum to 0xFFFF because there are several
devices out there that only support two-byte block counts even with
WRITE SAME(16). We only enable transfers bigger than 0xFFFF if the
device explicitly reports MAXIMUM WRITE SAME LENGTH in the BLOCK
LIMITS VPD.
- max_write_same_blocks can be overriden per-device basis in sysfs.
- The UNMAP discovery heuristics remain unchanged but the discard
limits are tweaked to match the "real" WRITE SAME commands.
- In the error handling logic we now distinguish between WRITE SAME
with and without UNMAP set.
The discovery process heuristics are:
- If the device reports a SCSI level of SPC-3 or greater we'll issue
READ SUPPORTED OPERATION CODES to find out whether WRITE SAME(16) is
supported. If that's the case we will use it.
- If the device supports the block limits VPD and reports a MAXIMUM
WRITE SAME LENGTH bigger than 0xFFFF we will use WRITE SAME(16).
- Otherwise we will use WRITE SAME(10) unless the target LBA is beyond
0xFFFFFFFF or the block count exceeds 0xFFFF.
- no_write_same is set for ATA, FireWire and USB.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
The REPORT SUPPORTED OPERATION CODES command can be used to query
whether a given opcode is supported by a device. Add a helper function
that allows us to look up commands.
We only issue RSOC if the device reports compliance with SPC-3 or
later. But to err on the side of caution we disable the command for ATA,
FireWire and USB.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Fix two bugs of the /dev/fw* character device concerning the
FW_CDEV_IOC_GET_INFO ioctl with nonzero fw_cdev_get_info.bus_reset.
(Practically all /dev/fw* clients issue this ioctl right after opening
the device.)
Both bugs are caused by sizeof(struct fw_cdev_event_bus_reset) being 36
without natural alignment and 40 with natural alignment.
1) Memory corruption, affecting i386 userland on amd64 kernel:
Userland reserves a 36 bytes large buffer, kernel writes 40 bytes.
This has been first found and reported against libraw1394 if
compiled with gcc 4.7 which happens to order libraw1394's stack such
that the bug became visible as data corruption.
2) Information leak, affecting all kernel architectures except i386:
4 bytes of random kernel stack data were leaked to userspace.
Hence limit the respective copy_to_user() to the 32-bit aligned size of
struct fw_cdev_event_bus_reset.
Reported-by: Simon Kirby <sim@hostway.ca>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: stable@kernel.org
Follow up on commit c285f6ff6787 "firewire: remove global lock around
address handlers, convert to RCU":
- address_handler_lock no longer serializes the address handler, only
its function to serialize updates to the list of handlers remains.
Rename the lock to address_handler_list_lock.
- Callers of fw_core_remove_address_handler() must be able to sleep.
Comment on this in the API documentation.
- The counterpart fw_core_add_address_handler() is by nature something
which is used in process context. Replace spin_lock_bh() by
spin_lock() in fw_core_add_address_handler() and in
fw_core_remove_address_handler(), and document that process context
is now required for fw_core_add_address_handler().
- Extend the documentation of fw_address_callback_t.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Upper-layer handlers for inbound requests were called with a spinlock
held by firewire-core. Calling into upper layers with a lower layer
lock held is generally a bad idea.
What's more, since commit ea102d0ec4 "firewire: core: convert AR-req
handler lock from _irqsave to _bh", a caller of fw_send_request() i.e.
initiator of outbound request could no longer do that while having
interrupts disabled, if the local node was addressed by that request.
In order to make all this more flexible, convert the management of
address ranges and handlers from a global lock around readers and
writers to RCU (and a remaining global lock for writers). As a minor
side effect, handling of inbound requests at different cards and of
local requests is now no longer serialized. (There is still per-card
serialization of remote requests since firewire-ohci uses a single DMA
tasklet for inbound request events.)
In other words, address handlers are now called in an RCU read-side
critical section instead of from within a spin_lock_bh serialized
section.
(Changelog rewritten by Stefan R.)
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
In case of a self constructed selfID packet this patch correctly
determines the information if the TSB41BA3D phy initiated a bus reset.
Signed-off-by: Stephan Gatzka <stephan.gatzka@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Send the GUIDs of newly registered controllers and devices
to the /dev/random driver to help seed its pools.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
- A new sysfs attribute to tell local and remote nodes apart.
Useful to set special permissions/ ownership of local nodes'
/dev/fw*, to start daemons on them (for diagnostics, management,
AV targets, VersaPHY initiator or targets...), to pick up their
GUID to use it as GUID of an SBP2 target instance, and of course
for informational purposes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJQFPvkAAoJEHnzb7JUXXnQ1qkP/Akky4rnp2jtAi0f97FrrVIX
D5kf4buehiOY0NN5NupbP2ABVLG9pq6aiH0FqaUjLE/t5g0xTKUaWwIy1ybr9rNT
luN2xrAqkkA49jVtTIlE1sSn9tt7E8dRbmiggCrci2S0K0FTuG2V3EXCaACEojQQ
vPzW4Hm+PWlQRUItBYBRbMlZrxqkBAIBY+u0I8rTWMv4nwMchHzT6CeZ510fe4tA
plr3UDsbToqBRxkEIQ6E5IJe0XDP+hwcaaKwRR0v2zaZU/Xy0pJK1ZoiUJUEOmIA
c2YmbWvYQJjGawm3SFHxN+OjhrOEi4gTgwhgJ88K3MK6tCk+edB1eML+F59gYwR4
FATnNYUnAQBrcIfayxIct7aTVqmlFdtp9un0YfqQrcr9yVTHPG2RD6jc5sYW9sYG
7+Pmdkp1EzPBpgPM8/BwsffEwvDtFjkmQqru6J/nVuyTfDZnUTwncndY0iChVR2F
kVcgZicZzYK34yER+yUGcFjEEnlSuQZ/l0CXB6r4t5KHrDc3os4gHnYOFgDnppvk
nXLKyADeIyvQpDhsZlyLOwtsoYQbhqlmTc17yukW+wrgXZet8Uh4qE1Q1UW2Mm1y
OsRCO/0uNU4eg7IAWHL7+mCHGG15CWpmj1Xp6+apj9fRTXi6tcI5/M+U6yz3Nkfw
ChV+ObvejQmBQadE1g81
=8e6I
-----END PGP SIGNATURE-----
Merge tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire updates from Stefan Richter:
- Small fixes and optimizations.
- A new sysfs attribute to tell local and remote nodes apart.
Useful to set special permissions/ ownership of local nodes'
/dev/fw*, to start daemons on them (for diagnostics, management,
AV targets, VersaPHY initiator or targets...), to pick up their
GUID to use it as GUID of an SBP2 target instance, and of course
for informational purposes.
* tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: core: document is_local sysfs attribute
firewire: core: add is_local sysfs device attribute
firewire: ohci: initialize multiChanMode bits after reset
firewire: core: fix multichannel IR with buffers larger than 2 GB
firewire: ohci: sanity-check MMIO resource
firewire: ohci: lazy bus time initialization
firewire: core: allocate the low memory region
firewire: core: make address handler length 64 bits
Making this information available in sysfs allows to differentiate
between controllers in the local and remote Linux PCs, and thus is
useful for servers that are started with udev rules.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
OHCI 1.1 says:
| Since the value of this bit is undefined after reset in all IR
| contexts, software shall initialize this bit to zero in all contexts
| whether or not active to maintain the exclusive nature of this bit.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
With a 32-bit i, computing i<<PAGE_SHIFT might result in
an overflow and in an eventual sign-extension.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
pci_request_region() does not fail on resources that have not been
allocated by the BIOS or by the kernel, so to avoid accessing
registers that are not there, we have to check for this explicitly.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The Bus_Time CSR is virtually never used, so we can avoid burning CPU in
interrupt context for 1 or 3 IsochronousCycleTimer accesses every minute
by not tracking the bus time until the CSR is actually accessed for the
first time.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Prevent userspace applications from allocating low memory address
ranges. Otherwise, if some application happens to allocate such
a range and intends for a remote node to access it, and if that node
also implements SBP-2 (which will become more likely with the upcoming
SBP-2 target support), these accesses would be routed by the physical
DMA unit to some wrong memory address.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
- Fix mismatch between DMA mapping direction (was wrong) and DMA synchronization
direction (was correct) of isochronous reception buffers of userspace drivers
if vma-mapped for R/W access. For example, libdc1394 was affected.
- more consistent retry stategy in device discovery/ rediscovery, and improved
failure diagnostics
- various small cleanups, e.g. use SCSI layer's DMA mapping API in firewire-sbp2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iQIcBAABAgAGBQJPvoOWAAoJEHnzb7JUXXnQpG4P/j4u9kU+MDegDrRsAzZBdP+6
in2FW8opUzSXZyLSzU/JYcO7P0luEEdLIE65fkaVRbP1x6m7aAjgaAO/0zbqZQPD
QVyIAOPa8zcbEIi1cEnI75KU/AMyQpMk/eU9Et4FrbQszgyFvJNe+hS+MocMooPt
vukqmWJuIPfH/G3FsX0eQWEXS7GktkYxmLJM/k6z4JpngAVmelM/Ce45VFg7tbN+
IeV5N7+FF4zKmwgiKIpkw5tSO6If7mjoQQVH/Q8DiHJDhFlDUrKR9/TvaJesVtEg
5n97BbfvXc8mu6EE8lbl1ats2R1I00JDpMylHPt4J6G1XDjb1/GvqSjXYXwPT77J
O4xZwqT4C5JKnG9h2a4npf6PgDHBbMnUK9cDBxfA5ZPkTeZmGXWuP05zYJqeNJm9
UrEusEjzEEspVWFqxOD+2/YLF/0rxqA/P1C7Luuw7Y9nIcCt3VskuW6iebYuf5Dk
yNoykYVph8zDJE+Am7jtsgNCPfd4TomFttjMcc/0EVqNa1iVO/AuLlvYv+Ab75oU
BpOUEg8Pq9nQeya3XjM585R0rF4PG5wsVrBe2ZzJ+cqNe6JH264/YuBgFv1bkUg3
UtHNIG633KAk71P1jl7PeuvAQksLnCYak2JOviZ/oB79Yamoxifhcm4mNkwTeCv7
paRqDNAzoaThqvqx723E
=fulr
-----END PGP SIGNATURE-----
Merge tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull IEEE 1394 (FireWire) subsystem updates from Stefan Richter:
- Fix mismatch between DMA mapping direction (was wrong) and DMA
synchronization direction (was correct) of isochronous reception
buffers of userspace drivers if vma-mapped for R/W access. For
example, libdc1394 was affected.
- more consistent retry stategy in device discovery/ rediscovery, and
improved failure diagnostics
- various small cleanups, e.g. use SCSI layer's DMA mapping API in
firewire-sbp2
* tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: sbp2: document the absence of alignment requirements
firewire: sbp2: remove superfluous blk_queue_max_segment_size() call
firewire: sbp2: use scsi_dma_(un)map
firewire: sbp2: give correct DMA device to scsi framework
firewire: core: fw_device_refresh(): clean up error handling
firewire: core: log config rom reading errors
firewire: core: log error in case of failed bus manager lock
firewire: move rcode_string() to core
firewire: core: improve reread_config_rom() interface
firewire: core: wait for inaccessible devices after bus reset
firewire: ohci: omit spinlock IRQ flags where possible
firewire: ohci: correct signedness of a local variable
firewire: core: fix DMA mapping direction
firewire: use module_pci_driver
The SBP-2/3 specifications do not require any alignment of data
buffers; only their own data structures need to be quadlet-aligned
[SR: or octlet-aligned].
Fix the comments to reflect this, but leave the actual alignment at
32 bits to avoid theoretical problems with target implementations
that might handle this incorrectly.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The SCSI framework automatically initializes the block queue's segment
size with the DMA device's segment size.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Use the scsi_dma_map/scsi_dma_unmap helper to simplify the code
a little.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The sbp2 driver does DMA not on the unit but on the card device.
The driver worked even with the wrong device because at the moment, it
happens to reimplement the DMA functions of the SCSI framework.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
When writing a firewire driver that doesn't deal with struct fw_device
objects (e.g. it only publishes FireWire units and doesn't subscribe to
them), you likely need to keep referenced to struct fw_card objects so
that you can send messages to other nodes. This patch moves
fw_card_put(), fw_card_get() and fw_card_release() into the public
include/linux/firewire.h header instead of drivers/firewire/core.h, and
adds EXPORT_SYMBOL_GPL(fw_card_release).
The firewire-sbp-target module requires these so it can keep a reference
to the fw_card object in order that it can fetch ORBs to execute and
read/write related data and status information.
Signed-off-by: Chris Boot <bootc@bootc.net>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Sometimes it's useful to know the FireWire speed of the request that has
just come in to a fw_address_handler callback. As struct fw_request is
opaque we can't peek inside to get the speed out of the struct fw_packet
that's just inside. For example, the SBP-2 spec says:
"The speed at which the block write request to the MANAGEMENT_AGENT
register is received shall determine the speed used by the target for
all subsequent requests to read the initiator’s configuration ROM, fetch
ORB’s from initiator memory or store status at the initiator’s
status_FIFO. Command block ORB’s separately specify the speed for
requests addressed to the data buffer or page table."
[ ANSI T10/1155D Revision 4 page 53/54 ]
Signed-off-by: Chris Boot <bootc@bootc.net>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
In fw_device_init() and fw_device_refresh(), if a call to
read_cofig_rom() fails, the operation is retried a few times, with
these retries being controlled by the MAX_RETRIES and RETRY_DELAY
symbols.
fw_device_refresh() also reads part of the config rom by calling
reread_config_rom(). Any errors from this call resulted in retries
with MAX_RETRIES/2 and RETRY_DELAY/2.
There is no reason to require that a device that has initiated a bus
reset must react faster to read requests than a device that has just
been plugged in. Furthermore, if the config rom has changed, any
errors from the following read_config_rom() call are then handled
with the normal retry count and delay.
Remove this inconsistency by always using the normal retry count and
delay. (This also makes the two error handlers identical and allows
merging them.)
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If reading or refreshing a config rom fails, also log the actual error
that caused it to fail.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If the lock access to the bus manager register fails, also log the
actual error that caused it to fail.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
There is nothing audio-specific about the rcode_string() helper, so move
it from snd-firewire-lib into firewire-core to allow other code to use it.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (fixed sound/firewire/cmp.c)
The return value of reread_config_rom() was a mixture of two pieces of
information: whether the function succeeded, and whether the config rom
had changed.
To clarify the semantics, and to allow returning the actual error code,
split the second information into a new output parameter.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
When reread_config_rom() encountered a config rom that was marked as not
yet accessible, that device would be treated as "gone". This would mean
that that device would effectively vanish until the next bus reset.
The correct way to handle this situation is the same as in
read_config_rom(), to treat this like other errors and to retry the read
later, when the (possibly changed) config rom is available. The device
is marked "gone" only if it continues to return zero values after these
retries.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
bus_reset_work() is only called from workqueue thread context.
ohci_set_config_rom() and ohci_allocate_iso_context() perform GFP_KERNEL
memory allocations, therefore they must be called with interrupts
enabled.
Hence these functions may disable and enable local IRQs without having
to track IRQ state.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Seen with recent libdc1394: If a client mmap()s the buffer of an
isochronous reception buffer with PROT_READ|PROT_WRITE instead of just
PROT_READ, firewire-core sets the wrong DMA mapping direction during
buffer initialization.
The fix is to split fw_iso_buffer_init() into allocation and DMA mapping
and to perform the latter after both buffer and DMA context were
allocated. Buffer allocation and context allocation may happen in any
order, but we need the context type (reception or transmission) in order
to set the DMA direction of the buffer.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This patch converts the drivers in drivers/firewire/* to use module_pci_driver()
macro which makes the code smaller and a bit simpler.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Remove all #inclusions of asm/system.h preparatory to splitting and killing
it. Performed with the following command:
perl -p -i -e 's!^#\s*include\s*<asm/system[.]h>.*\n!!' `grep -Irl '^#\s*include\s*<asm/system[.]h>' *`
Signed-off-by: David Howells <dhowells@redhat.com>
- Some SBP-2 initiator fixes, side product from ongoing work on a target.
- Reintroduction of an isochronous I/O feature of the older ieee1394 driver
stack (flush buffer completions); it was evidently rarely used but not
actually unused. Matching libraw1394 code is already available.
- Be sure to prefix all kernel log messages with device name or card name,
and other logging related cleanups.
- Misc other small cleanups, among them a small API change that affects
sound/firewire/ too.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
iQIcBAABAgAGBQJPa5I1AAoJEHnzb7JUXXnQvUoQAMl9PhUk5ZFhWp0AOnQ4uLhI
lEfRnUp94kGBdazBhxM9wtAwZRAeXUev/JyxwymMKSG40dMTbuxqRcs71v6a+ifd
VqNctL0yUncrOw/92l+TG2t/hWttB4u+dTKYX2U5yza42+uUHWMZb7MzmV+qVYc8
H+NR71WLQM4wkWdX8LBxmdeAOm0X635cjKsC/5FX9dws7q1ebSoxs4q4iIaGR7W8
ETWx5lh/UVyR7c9T+VIr0jfQWdsm2IcmHr/+nldlesePZ1gRjIEi69ErEnGxTkGe
NLPwt9lWuFXgWWHBON7C/rLmBA+NSys9lbvRAsPXrb3GpOKlde81c7U7Kr/kmEkh
hB9oM2Qh0A/7sglvIZiDUP565lqOAbXSJzziG3+0XgOP2zsxukm5gSecF8qM8tHY
IDwN05R9+nc26NA5TOfaRWx08n9SqTxq4V326oz9WMuK4bosCEfg4dvMwyMK/V3i
AyipAl2YYIG/2JURMFcGSKbw33dBw3mRsS8XG3MXwzagUMw/8tSyZKQIwF9qO4si
69QV7+CJoEfbJiLJMZJnKrRjfU+ZVRNA/xFuHUmhpmvYIbN8iJVGpGZABfXBUcH0
c1+qX9zE4NEAUEylbgn5raYSY6otF51O8QJzQOn2HRddBQSDpEwhkOGVfZ7zcSLH
sjAOn9qLIMHnrxUXxBDP
=oWbr
-----END PGP SIGNATURE-----
Merge tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull IEEE 1394 (FireWire) subsystem updates post v3.3 from Stefan Richter:
- Some SBP-2 initiator fixes, side product from ongoing work on a target.
- Reintroduction of an isochronous I/O feature of the older ieee1394 driver
stack (flush buffer completions); it was evidently rarely used but not
actually unused. Matching libraw1394 code is already available.
- Be sure to prefix all kernel log messages with device name or card name,
and other logging related cleanups.
- Misc other small cleanups, among them a small API change that affects
sound/firewire/ too. Clemens Ladisch is aware of it.
* tag 'firewire-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394: (26 commits)
firewire: allow explicit flushing of iso packet completions
firewire: prevent dropping of completed iso packet header data
firewire: ohci: factor out iso completion flushing code
firewire: ohci: simplify iso header pointer arithmetic
firewire: ohci: optimize control bit checks
firewire: ohci: remove unused excess_bytes field
firewire: ohci: copy_iso_headers(): make comment match the code
firewire: cdev: fix IR multichannel event documentation
firewire: ohci: fix too-early completion of IR multichannel buffers
firewire: ohci: move runtime debug facility out of #ifdef
firewire: tone down some diagnostic log messages
firewire: sbp2: replace a GFP_ATOMIC allocation
firewire: sbp2: Fix SCSI sense data mangling
firewire: sbp2: Ignore SBP-2 targets on the local node
firewire: sbp2: Take into account Unit_Unique_ID
firewire: nosy: Use the macro DMA_BIT_MASK().
firewire: core: convert AR-req handler lock from _irqsave to _bh
firewire: core: fix race at address_handler unregistration
firewire: core: remove obsolete comment
firewire: core: prefix log messages with card name
...
Extend the kernel and userspace APIs to allow reporting all currently
completed isochronous packets, even if the next interrupt packet has not
yet been reached. This is required to determine the status of the
packets at the end of a paused or stopped stream, and useful for more
precise synchronization of audio streams.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The buffer for the header data of completed iso packets has a fixed
size, so it is possible to configure a stream with a big interval
between interrupt packets or with big headers so that this buffer would
overflow. Previously, ohci.c would drop any data that would not fit,
but this could make unsuspecting applications believe that fewer than
the actual number of packets have completed.
Instead of dropping data, add calls to flush_iso_completion() so that
there are as many events as needed to report all of the data.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
In preparation for the following patches that add more flushing, move
the code for flushing accumulated header data into a common function.
The timestamp of the last completed packed is passed through the context
structure instead of a function parameter to allow accessing this value
later outside of the handle_i?_packet functions.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
When storing the header data of completed iso packets, we effectively
treat the buffers as arrays of quadlets. Actually declaring the
pointers as u32* avoids repetitive pointer arithmetic, removes the
unhelpfully named "i" variables, and thus makes the code clearer.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Doing the endian conversion on the constant instead of the memory
field allows the compiler to do the conversion at compile time.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Commit 6498ba04ae (remove unused dualbuffer IR code) overlooked
a field in struct iso_context.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The comment incorrectly talked about one little-endian quadlet, while
there are actually two. Furthermore, the endianness of the remaining
headers depends on whatever protocol is used, so don't mention them.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
handle_ir_buffer_fill() assumed that a completed descriptor would be
indicated by a non-zero transfer_status (as in most other descriptors).
However, this field is written by the controller as soon as (the end of)
the first packet has been written into the buffer. As a consequence, if
we happen to run into such a descriptor when the interrupt handler is
executed after such a packet has completed, the descriptor would be
taken out of the list of active descriptors as soon as the buffer had
been partially filled, so the event for the buffer being completely
filled would never be sent.
To fix this, handle descriptors only when they have been completely
filled, i.e., when res_count == 0. (This also matches the condition
that is reported by the controller with an interrupt.)
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: 2.6.36+ <stable@vger.kernel.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
CONFIG_FIREWIRE_OHCI_DEBUG could have been exposed to kernel tweakers
if CONFIG_EXPERT was set. But in hindsight, this stuff is far too
useful to omit it. So get rid of two #else branches that are only
going to bitrot otherwise.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
sbp2_send_management_orb() is called by sbp2_login, sbp2_reconnect, and
sbp2_remove, all which are able to sleep during memory allocations.
Actually, sbp2_send_management_orb() itself is a sleeping function.
Login and remove could allocate with GFP_KERNEL but reconnect needs
GFP_NOIO to ensure progress in low memory situations.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
SCSI sense data in SBP-2/3 is carried in an unusual format that means we
have to un-mangle it on our end before we pass it to the SCSI subsystem.
Currently our un-mangling code doesn't quite follow the SBP-2 standard
in that we always assume Current and never Deferred error types, we
never set the VALID bit, and we mishandle the FILEMARK, EOM and ILI
bits.
This patch fixes the sense un-mangling to correctly handle those and
follow the spec.
Signed-off-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The firewire-sbp2 module tries to login to an SBP-2/3 target even when
it is running on the local node, which fails because of the inability to
fetch data from DMA mapped regions using firewire transactions on the
local node. It also doesn't make much sense to have the initiator and
target on the same node, so this patch prevents this behaviour.
Signed-off-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changed the comment)
If the target's unit directory contains a Unit_Unique_ID entry, we
should use that as the target's GUID for identification purposes. The
SBP-2 standards document says:
"Although the node unique ID (EUI-64) present in the bus information
block is sufficient to uniquely identify nodes attached to Serial Bus,
it is insufficient to identify a target when a vendor implements a
device with multiple Serial Bus node connections. In this case initiator
software requires information by which a particular target may be
uniquely identified, regardless of the Serial Bus access path used."
[ IEEE T10 P1155D Revision 4, Section 7.6 (page 51) ] and
[ IEEE T10 P1467D Revision 5, Section 7.9 (page 74) ]
Signed-off-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Use the macro DMA_BIT_MASK instead of the constant 0xffffffff
Signed-off-by: Santosh Nayak <santoshprasadnayak@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
fw_core_handle_request() is called by the low-level driver in tasklet
context or process context, and fw_core_add/remove_address_handler() is
called by mid- or high-level code in process context. So convert
address_handler_lock accesses from those which disable local IRQs to
ones which just disable local softIRQs.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Fix the following unlikely but possible race:
CPU 1 CPU 2
------------------------------------------------------------------------
AR-request tasklet
lookup handler
unregister handler
free handler->callback_data or handler
call handler->callback
The application which registered the handler has no way to stop nodes
sending new requests to their address range, hence cannot prevent this
race.
Fix it simply by extending the address_handler_lock-protected region
from only around the lookup to around both lookup and call. We only
need to do so in the exclusive region handler; the FCP region handler
already holds the lock around the handler->callback call.
Alas this removes the current ability to execute the callback in
parallel on different CPUs if it was called for different FireWire cards
at the same time. (For a single card, the handler is already
serialized.) If this loss of a rather obscure feature is not tolerable,
a more complex fix would be required: Add a handler reference counter;
wait in fw_core_remove_address_handler() for this conter to become zero.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Target-like applications or peer-to-peer-like applications require the
global address handler registration which we have right now, or a per-
card registration. And node lookup, while it would be nice to have,
would be impossible in the brief time between self-ID-complete event and
completion of firewire-core's topology scanning.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Associate all log messages from firewire-core with the respective card
because some people have more than one card. E.g.
firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0
firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0
firewire_core: created device fw0: GUID 0814438400000389, S800
firewire_core: phy config: new root=ffc1, gap_count=5
firewire_core: created device fw1: GUID 0814438400000388, S800
firewire_core: created device fw2: GUID 0001d202e06800d1, S800
turns into
firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0
firewire_ohci 0000:05:00.0: added OHCI v1.10 device as card 1, 8 IR + 8 IT contexts, quirks 0x0
firewire_core 0000:04:00.0: created device fw0: GUID 0814438400000389, S800
firewire_core 0000:04:00.0: phy config: new root=ffc1, gap_count=5
firewire_core 0000:05:00.0: created device fw1: GUID 0814438400000388, S800
firewire_core 0000:04:00.0: created device fw2: GUID 0001d202e06800d1, S800
This increases the module size slightly; to keep this in check, turn the
former printk wrapper macros into functions. Their implementation is
largely copied from driver core's dev_printk counterparts.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Change the log line prefix from "firewire_net: " to "net firewire0: "
etc. for the case that several RFC 2734 interfaces are being used in the
same machine.
Note, the netdev_printk API is not very useful to firewire-net.
netdev_notice(net, "abc\n") would result in irritating messages like
"firewire_ohci 0000:0a:00.0: firewire0: abc". Nor would a dev_printk on
the fw_unit.device to which firewire-net is being bound be useful,
because there are generally multiple ones of those per interface (from
all RFC 2734 peers on the bus, the local node being only one of them).
In the initialization message of each interface, log the PCI device
name of the card which is parent of the netdevice instead of the GUID
of the peer which was semi-randomly used to establish the netdevice.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
On second thought, there is little reason to have driver name differ
from module name. Therefore, change
/sys/bus/firewire/drivers/net
/sys/bus/firewire/devices/fw0.0/driver -> [...]/net
/sys/module/firewire_net/drivers/firewire:net
to
/sys/bus/firewire/drivers/firewire_net
/sys/bus/firewire/devices/fw0.0/driver -> [...]/firewire_net
/sys/module/firewire_net/drivers/firewire:firewire_net
It is redundant but consistent with firewire-sbp2's recently changed
driver name.
I don't see this anywhere used, so it should not matter either way.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Commit eba9ebaaa2 "firewire: sbp2: use dev_printk API" changed
messages from e.g.
firewire_sbp2: fw3.0: logged in to LUN 0000 (0 retries)
to
sbp2 fw3.0: logged in to LUN 0000 (0 retries)
because the driver calls itself as "sbp2" when registering with driver
core and with SCSI core. This is of course confusing, so switch to the
name "firewire_sbp2" for driver core in order to match what lsmod and
/sys/module/ show. So we are back to
firewire_sbp2 fw3.0: logged in to LUN 0000 (0 retries)
in the kernel log.
This also changes
/sys/bus/firewire/drivers/sbp2
/sys/bus/firewire/devices/fw3.0/driver -> [...]/sbp2
/sys/module/firewire_sbp2/drivers/firewire:sbp2
to
/sys/bus/firewire/drivers/firewire_sbp2
/sys/bus/firewire/devices/fw3.0/driver -> [...]/firewire_sbp2
/sys/module/firewire_sbp2/drivers/firewire:firewire_sbp2
but "cat /sys/class/scsi_host/host27/proc_name" stays "sbp2" just in
case that proc_name is used by any userland.
The transport detection in lsscsi is not affected. (Tested with lsscsi
version 0.25.) Udev's /dev/disk/by-id and by-path symlinks are not
affected either.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The PCIe device
FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd FireWire Host Controller
[1180:e832] (prog-if 10 [OHCI])
is unable to access attached FireWire devices when MSI is enabled but
works if MSI is disabled.
http://www.mail-archive.com/alsa-user@lists.sourceforge.net/msg28251.html
Hence add the "disable MSI" quirks flag for this device, or in fact for
safety and simplicity for all current (R5U230, R5U231, R5U240) and
future Ricoh PCIe 1394 controllers.
Reported-by: Stefan Thomas <kontrapunktstefan@googlemail.com>
Cc: 2.6.36+ <stable@vger.kernel.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The Audigy's SB1394 controller is actually from Texas Instruments
and has the same bus reset packet generation bug, so it needs the
same quirk entry.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: 2.6.36+ <stable@vger.kernel.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
fw_unit device drivers invariably need to talk to the fw_unit's parent
(an fw_device) and grandparent (an fw_card). firewire-core already
maintains an fw_card reference for the entire lifetime of an fw_device.
Likewise, let firewire-core maintain an fw_device reference for the
entire lifetime of an fw_unit so that fw_unit drivers don't have to.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.
It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux: (230 commits)
Revert "tracing: Include module.h in define_trace.h"
irq: don't put module.h into irq.h for tracking irqgen modules.
bluetooth: macroize two small inlines to avoid module.h
ip_vs.h: fix implicit use of module_get/module_put from module.h
nf_conntrack.h: fix up fallout from implicit moduleparam.h presence
include: replace linux/module.h with "struct module" wherever possible
include: convert various register fcns to macros to avoid include chaining
crypto.h: remove unused crypto_tfm_alg_modname() inline
uwb.h: fix implicit use of asm/page.h for PAGE_SIZE
pm_runtime.h: explicitly requires notifier.h
linux/dmaengine.h: fix implicit use of bitmap.h and asm/page.h
miscdevice.h: fix up implicit use of lists and types
stop_machine.h: fix implicit use of smp.h for smp_processor_id
of: fix implicit use of errno.h in include/linux/of.h
of_platform.h: delete needless include <linux/module.h>
acpi: remove module.h include from platform/aclinux.h
miscdevice.h: delete unnecessary inclusion of module.h
device_cgroup.h: delete needless include <linux/module.h>
net: sch_generic remove redundant use of <linux/module.h>
net: inet_timewait_sock doesnt need <linux/module.h>
...
Fix up trivial conflicts (other header files, and removal of the ab3550 mfd driver) in
- drivers/media/dvb/frontends/dibx000_common.c
- drivers/media/video/{mt9m111.c,ov6650.c}
- drivers/mfd/ab3550-core.c
- include/linux/dmaengine.h
Ensure that the EXPORT_SYMBOL macros are present for when we clean up
the "module.h" is everywhere situation, to prevent build failures.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Add the dma_sync_single_* calls necessary to ensure proper cache
synchronization for isochronous data buffers on non-coherent
architectures.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If a device's firmware initiates a bus reset by setting the IBR bit in
PHY register 1 without resetting the gap count field to 63 (and without
having sent a PHY configuration packet beforehand), the gap count of
this node will remain at the old value after the bus reset and thus be
inconsistent with the gap count on all other nodes.
The bus manager is supposed to detect the inconsistent gap count values
in the self ID packets and correct them by issuing another bus reset.
However, if the buggy device happens to be the cycle master, and if it
sends a cycle start packet immediately after the bus reset (which is
likely after a long bus reset), then the time between the end of the
selfID phase and the start of the cycle start packet will be based on
the too-small gap count value, so this gap will be too short to be
detected as a subaction gap by the other nodes. This means that the
cycle start packet will be assumed to be self ID data, and will be
stored after the actual self ID quadlets in the self ID buffer.
This garbage in the self ID buffer made firewire-core ignore all of the
self ID data, and thus prevented the Linux bus manager from correcting
the problem. Furthermore, because the bus reset handling was aborted
completely, asynchronous transfers would be no longer handled correctly,
and fw_run_transaction() would hang until the next bus reset.
To fix this, make the detection of inconsistent self IDs more
discriminating: If the invalid data in the self ID buffer looks like
a cycle start packet, we can assume that the previous data in the buffer
is correctly received self ID information, and process it normally.
(We inspect only the first quadlet of the cycle start packet, because
this value is different enough from any valid self ID quadlet, and many
controllers do not store the cycle start packet in five quadlets because
they expect self ID data to have an even number of quadlets.)
This bug has been observed when a bus-powered DesktopKonnekt6 is
switched off with its power button.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Change memory region to ohci "middle address space". This effectively
reduces the number of packets by 50%.
[Stefan R.:] This eliminates 1394 ack packets and improved throughput
by a few percent in some tests with an S400a connection with and without
gap count optimization. Since firewire-net taxes the AR-req DMA unit of
a FireWire controller much more than firewire-sbp2 (which uses the
middle address space with PCI posted writes too), this commit also
changes a related error printk into a ratelimited one as a precaution.
Side note: The IPv4-over-1394 drivers of Mac OS X 10.4, Windows XP SP3,
and the Thesycon 1394 bus driver for Windows all use the middle address
space too.
Signed-off-by: Stephan Gatzka <stephan@gatzka.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Use kernel.h's convenience macros. Also omit a printk that should never
happen and won't matter much if it ever happened.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Takes less source code and machine code, and less runtime with PHYs
other than TSB41BA3D (e.g. TSB81BA3 with device ID 0x831304 which takes
one instead of six read_paged_phy_reg now).
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Fix: phy_reg_mutex must be held over the write/read_phy_reg pair which
gets PHY port status.
Only print to the log when a TSB41BA3D was found. By far most TSB82AA2
cards have a TSB81BA3, and firewire-ohci can keep quiet about that.
Shorten some strings and comments. Change some whitespace.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This patch implements a work around for the Texas Instruments PHY
TSB41BA3D. This phy has a bug at least in combination with the TI LLCs
TSB82AA2B and TSB12LV26. The selfid coming from the locally connected
phy is not propagated into the selfid buffer of the OHCI (see
http://www.ti.com/litv/pdf/sllz059 for details). The main idea is to
construct the selfid ourselves.
Signed-off-by: Stephan Gatzka <stephan@gatzka.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Code inside bus_reset_work may now sleep. This is a prerequisite to
support a phy from Texas Instruments cleanly. The patch to support this
phy will be submitted later.
Signed-off-by: Stephan Gatzka <stephan@gatzka.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
sbp2_release_target() is folded into its primary user, sbp2_remove().
The only other caller, a failure path in sbp2_probe(), now uses
sbp2_remove(). This adds unnecessary cancel_delayed_work_sync() calls
to that failure path but results in less code and text.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Implement sbp2_queue_work(), which is now a very simple accessor to one
of the struct sbp2_logical_unit members, right after the definition of
struct sbp2_logical_unit.
Put the sbp2_reconnect() implementation right after the sbp2_login()
implementation. They are both part of the SBP-2 access protocol.
Implement the driver methods sbp2_probe(), spp2_update(), sbp2_remove()
in this order, reflecting the lifetime of an SBP-2 target.
Place the sbp2_release_target() implementation right next to
sbp2_remove() which is its primary user, and after sbp2_probe() which is
the counterpart to sbp2_release_target().
There are no changes to the implementations here, or at least not meant
to be.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Since commit 0278ccd9d5 "firewire: sbp2:
fix panic after rmmod with slow targets", the lifetime of an sbp2_target
instance does no longer extent past the return of sbp2_remove().
Therefore it is no longer necessary to call fw_unit_get/put() and
fw_device_get/put() in sbp2_probe/remove().
Furthermore, said commit also ensures that lu->work is not going to be
executed or requeued at a time when the sbp2_target is no longer in use.
Hence there is no need for sbp2_target reference counting for lu->work.
Other concurrent contexts:
- Processes which access the sysfs of the SCSI host device or of one
of its subdevices are safe because these interfaces are all removed
by scsi_remove_device/host() in sbp2_release_target().
- SBP-2 command block ORB transactions are finished when
scsi_remove_device() in sbp2_release_target() returns.
- SBP-2 management ORB transactions are finished when
cancel_delayed_work_sync(&lu->work) before sbp2_release_target()
returns.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801719 .
An O2Micro PCI Express FireWire controller,
"FireWire (IEEE 1394) [0c00]: O2 Micro, Inc. Device [1217:11f7] (rev 05)"
which is a combination device together with an SDHCI controller and some
sort of storage controller, misses SBP-2 status writes from an attached
FireWire HDD. This problem goes away if MSI is disabled for this
FireWire controller.
The device reportedly does not require QUIRK_CYCLE_TIMER.
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (amended changelog)
Cc: <stable@kernel.org>
If firewire-sbp2 starts a login to a target that doesn't complete ORBs
in a timely manner (and has to retry the login), and the module is
removed before the operation times out, you end up with a null-pointer
dereference and a kernel panic.
[SR: This happens because sbp2_target_get/put() do not maintain
module references. scsi_device_get/put() do, but at occasions like
Chris describes one, nobody holds a reference to an SBP-2 sdev.]
This patch cancels pending work for each unit in sbp2_remove(), which
hopefully means there are no extra references around that prevent us
from unloading. This fixes my crash.
Signed-off-by: Chris Boot <bootc@bootc.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
firewire: ohci: fix DMA unmapping in an error path
firewire: cdev: fix 32 bit userland on 64 bit kernel compat corner cases
Some older Panasonic made camcorders (Panasonic AG-EZ30 and NV-DX110,
Grundig Scenos DLC 2000) reject requests with ack_busy_X if a request is
sent immediately after they sent a response to a prior transaction.
This causes firewire-core to fail probing of the camcorder with "giving
up on config rom for node id ...". Consequently, programs like kino or
dvgrab are unaware of the presence of a camcorder.
Such transaction failures happen also with the ieee1394 driver stack
(of the 2.4...2.6 kernel series until 2.6.36 inclusive) but with a lower
likelihood, such that kino or dvgrab are generally able to use these
camcorders via the older driver stack. The cause for firewire-ohci's or
firewire-core's worse behavior is not yet known. Gap count optimization
in firewire-core is not the cause. Perhaps the slightly higher latency
of transaction completion in the older stack plays a role. (ieee1394:
AR-resp DMA context tasklet -> packet completion ktread -> user process;
firewire-core: tasklet -> user process.)
This change introduces retries and delays after ack_busy_X into
firewire-core's Config ROM reader, such that at least firewire-core's
probing and /dev/fw* creation are successful. This still leaves the
problem that userland processes are facing transaction failures.
gscanbus's built-in retry routines deal with them successfully, but
neither kino's nor dvgrab's do ever succeed.
But at least DV capture with "dvgrab -noavc -card 0" works now. Live
video preview in kino works too, but not actual capture.
One way to prevent Configuration ROM reading failures in application
programs is to modify libraw1394 to synthesize read responses by means
of firewire-core's Configuration ROM cache. This would only leave
CMP and FCP transaction failures as a potential problem source for
applications.
Reported-and-tested-by: Thomas Seilund <tps@netmaster.dk>
Reported-and-tested-by: René Fritz <rene@colorcube.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If request_irq failed, we would pass wrong arguments to
dma_free_coherent. https://bugzilla.redhat.com/show_bug.cgi?id=728185
Reported-by: Mads Kiilerich
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Clemens points out that we need to use compat_ptr() in order to safely
cast from u64 to addresses of a 32-bit usermode client.
Before, our conversion went wrong
- in practice if the client cast from pointer to integer such that
sign-extension happened, (libraw1394 and libdc1394 at least were not
doing that, IOW were not affected)
or
- in theory on s390 (which doesn't have FireWire though) and on the
tile architecture, regardless of what the client does.
The bug would usually be observed as the initial get_info ioctl failing
with "Bad address" (EFAULT).
Reported-by: Carl Karsten <carl@personnelware.com>
Reported-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This allows us to move duplicated code in <asm/atomic.h>
(atomic_inc_not_zero() for now) to <linux/atomic.h>
Signed-off-by: Arun Sharma <asharma@fb.com>
Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO
ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events
to be read(2) by the client. The get_info ioctl is practically always
issued right away after open, hence this condition only occurs if the
client opens during a bus reset, especially during a rapid series of bus
resets.
The problem with this condition is twofold:
- These bus reset events carry the (as yet undocumented) @closure
value of 0. But it is not the kernel's place to choose closures;
they are privat to the client. E.g., this 0 value forced from the
kernel makes it unsafe for clients to dereference it as a pointer to
a closure object without NULL pointer check.
- It is impossible for clients to determine the relative order of bus
reset events from get_info ioctl(2) versus those from read(2),
except in one way: By comparison of closure values. Again, such a
procedure imposes complexity on clients and reduces freedom in use
of the bus reset closure.
So, change the ABI to suppress queuing of bus reset events before the
first FW_CDEV_IOC_GET_INFO ioctl was issued by the client.
Note, this ABI change cannot be version-controlled. The kernel cannot
distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO
ioctl.
We will try to back-merge this change into currently maintained stable/
longterm series, and we only document the new behaviour. The old
behavior is now considered a kernel bug, which it basically is.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
On Jun 27 Linus Torvalds wrote:
> The correct error code for "I don't understand this ioctl" is ENOTTY.
> The naming may be odd, but you should think of that error value as a
> "unrecognized ioctl number, you're feeding me random numbers that I
> don't understand and I assume for historical reasons that you tried to
> do some tty operation on me".
[...]
> The EINVAL thing goes way back, and is a disaster. It predates Linux
> itself, as far as I can tell. You'll find lots of man-pages that have
> this line in it:
>
> EINVAL Request or argp is not valid.
>
> and it shows up in POSIX etc. And sadly, it generally shows up
> _before_ the line that says
>
> ENOTTY The specified request does not apply to the kind of object
> that the descriptor d references.
>
> so a lot of people get to the EINVAL, and never even notice the ENOTTY.
[...]
> At least glibc (and hopefully other C libraries) use a _string_ that
> makes much more sense: strerror(ENOTTY) is "Inappropriate ioctl for
> device"
So let's correct this in the <linux/firewire-cdev.h> ABI while it is
still young, relative to distributor adoption.
Side note: We return -ENOTTY not only on _IOC_TYPE or _IOC_NR mismatch,
but also on _IOC_SIZE mismatch. An ioctl with an unsupported size of
argument structure can be seen as an unsupported version of that ioctl.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
When firewire-ohci is bound to a Pinnacle MovieBoard, eventually a
"Register access failure" is logged and an interrupt storm or a kernel
panic happens. https://bugzilla.kernel.org/show_bug.cgi?id=36622
Until this is sorted out (if that is going to succeed at all), let's
just prevent firewire-ohci from touching these devices.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
YOSHIFUJI Hideaki / 吉藤英明