linux-stable.git/drivers/firewire, branch v3.0.22

firewire: ohci: disable MSI on Ricoh controllers

2012-02-13T19:06:06+00:00

commit 320cfa6ce0b3dc794fedfa4bae54c0f65077234d upstream.

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 
Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman

firewire: ohci: add reset packet quirk for SB Audigy

2012-02-13T19:06:06+00:00

commit d1bb399ad03c11e792f6dea198d3b1e23061f094 upstream.

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 
Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman

firewire: sbp2: fix panic after rmmod with slow targets

2011-10-25T05:10:16+00:00

commit 0278ccd9d53e07c4e699432b2fed9de6c56f506c upstream.

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 
Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman

firewire: ohci: add no MSI quirk for O2Micro controller

2011-10-03T18:40:33+00:00

commit f39aa30d7741f40ad964341e9243dbbd7f8ff057 upstream.

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 
Signed-off-by: Stefan Richter 
Signed-off-by: Greg Kroah-Hartman

firewire: cdev: prevent race between first get_info ioctl and bus reset event queuing

2011-08-05T04:58:34+00:00

commit 93b37905f70083d6143f5f4dba0a45cc64379a62 upstream.

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 
Cc:

firewire: cdev: return -ENOTTY for unimplemented ioctls, not -EINVAL

2011-08-05T04:58:34+00:00

commit d873d794235efa590ab3c94d5ee22bb1fab19ac4 upstream.

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  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 
Signed-off-by: Greg Kroah-Hartman

firewire: ohci: do not bind to Pinnacle cards, avert panic

2011-07-10T10:53:27+00:00

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 
Cc:

firewire: sbp2: parallelize login, reconnect, logout

2011-05-10T20:53:46+00:00

The struct sbp2_logical_unit.work items can all be executed in parallel
but are not reentrant.  Furthermore, reconnect or re-login work must be
executed in a WQ_MEM_RECLAIM workqueue.

Hence replace the old single-threaded firewire-sbp2 workqueue by a
concurrency-managed but non-reentrant workqueue with rescuer.
firewire-core already maintains one, hence use this one.

In earlier versions of this change, I observed occasional failures of
parallel INQUIRY to an Initio INIC-2430 FireWire 800 to dual IDE bridge.
More testing indicates that parallel INQUIRY is not actually a problem,
but too quick successions of logout and login + INQUIRY, e.g. a quick
sequence of cable plugout and plugin, can result in failed INQUIRY.
This does not seem to be something that should or could be addressed by
serialization.

Another dual-LU device to which I currently have access to, an
OXUF924DSB FireWire 800 to dual SATA bridge with firmware from MacPower,
has been successfully tested with this too.

This change is beneficial to environments with two or more FireWire
storage devices, especially if they are located on the same bus.
Management tasks that should be performed as soon and as quickly as
possible, especially reconnect, are no longer held up by tasks on other
devices that may take a long time, especially login with INQUIRY and sd
or sr driver probe.

Signed-off-by: Stefan Richter

firewire: sbp2: octlet AT payloads can be stack-allocated

2011-05-10T20:53:46+00:00

We do not need slab allocations for ORB pointer write transactions
anymore in order to satisfy streaming DMA mapping constraints, thanks to
commit da28947e7e36 "firewire: ohci: avoid separate DMA mapping for
small AT payloads".

(Besides, the slab-allocated buffers that firewire-sbp2 used to provide
for 8-byte write requests were still not fully portable since they
shared a cacheline with unrelated CPU-accessed data.)

Signed-off-by: Stefan Richter

firewire: sbp2: omit Scsi_Host lock from queuecommand

2011-05-10T20:53:45+00:00

firewire-sbp2 already takes care for internal serialization where
required (ORB list accesses), and it does not use cmd->serial_number
internally.  Hence it is safe to not grab the shost lock around
queuecommand.

While we are at housekeeping, drop a redundant struct member:
sbp2_command_orb.done is set once in a hot path and dereferenced once in
a hot path.  We can as well dereference sbp2_command_orb.cmd->scsi_done
instead.

Signed-off-by: Stefan Richter