Commit graph

717 commits

Author SHA1 Message Date
Rusty Russell
90ab5ee941 module_param: make bool parameters really bool (drivers & misc)
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>
2012-01-13 09:32:20 +10:30
Linus Torvalds
32aaeffbd4 Merge branch 'modsplit-Oct31_2011' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux
* '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
2011-11-06 19:44:47 -08:00
Paul Gortmaker
823467e5fc drivers/firewire: Add export.h for EXPORT_SYMBOL to core-iso.c
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>
2011-10-31 19:31:46 -04:00
Clemens Ladisch
a572e688cf firewire: ohci: fix isochronous DMA synchronization
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>
2011-10-18 12:32:39 +02:00
Clemens Ladisch
32eaeae177 firewire: ohci: work around selfID junk due to wrong gap count
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>
2011-10-18 12:32:39 +02:00
Stephan Gatzka
a74477db91 firewire: net: Use posted writes
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>
2011-10-09 17:00:18 +02:00
Stefan Richter
4ec4a67aa1 firewire: use clamp and min3 macros
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>
2011-10-09 17:00:18 +02:00
Stefan Richter
b810e4ae11 firewire: ohci: optimize TSB41BA3D detection
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>
2011-10-09 17:00:17 +02:00
Stefan Richter
28897fb73c firewire: ohci: TSB41BA3D support tweaks
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>
2011-10-09 17:00:17 +02:00
Stephan Gatzka
25935ebebd firewire: ohci: Add support for TSB41BA3D phy
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>
2011-09-16 22:30:28 +02:00
Stephan Gatzka
2d7a36e233 firewire: ohci: Move code from the bus reset tasklet into a workqueue
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>
2011-09-16 22:30:28 +02:00
Stefan Richter
32ce38f403 firewire: sbp2: fold two functions into one
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>
2011-09-16 22:23:56 +02:00
Stefan Richter
b2af07b684 firewire: sbp2: move some code to more sensible places
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>
2011-09-16 22:23:56 +02:00
Stefan Richter
6ff8147d07 firewire: sbp2: remove obsolete reference counting
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>
2011-09-16 22:23:56 +02:00
Ming Lei
f39aa30d77 firewire: ohci: add no MSI quirk for O2Micro controller
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>
2011-09-16 22:22:10 +02:00
Linus Torvalds
219f358e0b Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: sbp2: fix panic after rmmod with slow targets
2011-08-27 09:32:08 -07:00
Chris Boot
0278ccd9d5 firewire: sbp2: fix panic after rmmod with slow targets
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>
2011-08-23 00:44:35 +02:00
Linus Torvalds
3210d190dc Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: core: handle ack_busy when fetching the Config ROM
2011-08-21 18:13:19 -07:00
Linus Torvalds
6f02bfc404 Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* '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
2011-08-15 08:40:49 -07:00
Stefan Richter
aaff12039f firewire: core: handle ack_busy when fetching the Config ROM
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>
2011-08-13 13:53:30 +02:00
Stefan Richter
a01e836087 firewire: ohci: fix DMA unmapping in an error path
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>
2011-08-12 15:30:08 +02:00
Stefan Richter
9c1176b6a2 firewire: cdev: fix 32 bit userland on 64 bit kernel compat corner cases
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>
2011-08-12 15:30:08 +02:00
Arun Sharma
60063497a9 atomic: use <linux/atomic.h>
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>
2011-07-26 16:49:47 -07:00
Linus Torvalds
441c196e84 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: document the sysfs ABIs
  firewire: cdev: ABI documentation enhancements
  firewire: cdev: prevent race between first get_info ioctl and bus reset event queuing
  firewire: cdev: return -ENOTTY for unimplemented ioctls, not -EINVAL
  firewire: ohci: skip soft reset retries after card ejection
  firewire: ohci: fix PHY reg access after card ejection
  firewire: ohci: add a comment on PHY reg access serialization
  firewire: ohci: reduce potential context_stop latency
  firewire: ohci: remove superfluous posted write flushes
  firewire: net: replacing deprecated __attribute__((packed)) with __packed
2011-07-22 14:49:48 -07:00
Stefan Richter
93b37905f7 firewire: cdev: prevent race between first get_info ioctl and bus reset event queuing
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>
2011-07-16 07:24:32 +02:00
Stefan Richter
d873d79423 firewire: cdev: return -ENOTTY for unimplemented ioctls, not -EINVAL
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>
2011-07-16 07:24:31 +02:00
David S. Miller
6a7ebdf2fd Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:
	net/bluetooth/l2cap_core.c
2011-07-14 07:56:40 -07:00
David S. Miller
e69dd336ee net: Push protocol type directly down to header_ops->cache()
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-07-13 02:29:59 -07:00
Stefan Richter
7f7e37115a firewire: ohci: do not bind to Pinnacle cards, avert panic
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>
2011-07-10 12:53:27 +02:00
Stefan Richter
9f426173e5 firewire: ohci: skip soft reset retries after card ejection
The software reset in firewire-ohci's pci_remove does not have a great
prospect of success if the card was already physically removed at this
point.  So let's skip the 500 ms that were spent in retries here.

Also, replace a defined constant by its open-coded value.  This is not a
constant from a specification but an arbitrarily chosen retry limit.  It
was only used in this single place.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2011-07-09 17:12:09 +02:00
Stefan Richter
215fa444c2 firewire: ohci: fix PHY reg access after card ejection
Detect and handle ejection of FireWire CardBus cards in PHY register
accesses:

  - The last attempt of firewire-core to reset the bus during shutdown
    caused a spurious "firewire_ohci: failed to write phy reg" error
    message in the log.  Skip this message as well as the prior retry
    loop that needlessly took 100 milliseconds.

  - In the unlikely case that a PHY register was read right after card
    ejection, a bogus value was obtained and possibly acted upon.
    Instead, fail the read attempt.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2011-07-09 17:12:08 +02:00
Stefan Richter
b14c369d87 firewire: ohci: add a comment on PHY reg access serialization
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2011-07-09 17:12:08 +02:00
Stefan Richter
9ef28ccd59 firewire: ohci: reduce potential context_stop latency
Stopping an isochronous reception DMA context takes two loop iterations
in context_stop on several controllers (JMicron, NEC, VIA).  But there
is no extra delay necessary between these two reg_read trials; the MMIO
reads themselves are slow enough.  Hence bring back the behavior from
before commit dd6254e5c0 "firewire: ohci:
remove superfluous posted write flushes" on these controllers by means
of an "if (i)" condition.

Isochronous context stop is performed in preemptible contexts (and only
rarely), hence this change is of little impact.  (Besides, Agere and TI
controllers always, or almost always, have the context stopped already
at the first ContextControl read.)

More important is asynchronous transmit context stop, which is performed
while local interrupts are disabled (on the two AT DMAs in
bus_reset_tasklet, i.e. after a self-ID-complete event).  In my
experience with several controllers, tested with a usermode AT-request
transmitter as well as with FTP transmission over firewire-net, the AT
contexts were luckily already stopped at the first ContextControl read,
i.e. never required another MMIO read let alone mdelay.  A possible
explanation for this is that the controllers which I tested perhaps stop
AT DMA before they perform the self-ID reception DMA.

But we cannot be sure about that and should keep the interrupts-disabled
busy loop as short as possible.  Hence, query the ContextControl
register in 1000 udelay(10) intervals instead of 10 udelay(1000)
intervals.  I understand from an estimation by Clemens Ladisch that
stopping a busy DMA context should take microseconds or at worst tens of
microseconds, not milliseconds.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2011-07-09 17:12:07 +02:00
Clemens Ladisch
dd6254e5c0 firewire: ohci: remove superfluous posted write flushes
The call to flush_writes() in context_stop() is superfluous because
another register read is done immediately afterwards.

The call to flush_writes() in ar_context_run() does not need to be done
individually for each AR context, so move it to ohci_enable().  This
also makes ohci_enable() clearer because it no longer depends on a side
effect of ar_context_run() to flush its own register writes.

Finally, the setting of a context's wake bit does not need to be flushed
because neither the driver logic nor the API require the CPU to wait for
this action.  This removes the last MMIO reads from the packet queueing
code paths.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2011-06-02 13:58:33 +02:00
August Lilleaas
bf337b15c2 firewire: net: replacing deprecated __attribute__((packed)) with __packed
Fixing a deprecation, replacing __attribute__((packed)) with __packed.
It was deprecated for portability, specifically to avoid GCC specific
code.  See commit 82ddcb0405.

Signed-off-by: August Lilleaas <august@augustl.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (added include compiler.h)
2011-06-02 13:58:33 +02:00
Stefan Richter
105e53f863 firewire: sbp2: parallelize login, reconnect, logout
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 <stefanr@s5r6.in-berlin.de>
2011-05-10 22:53:46 +02:00
Stefan Richter
81bf52d862 firewire: sbp2: octlet AT payloads can be stack-allocated
We do not need slab allocations for ORB pointer write transactions
anymore in order to satisfy streaming DMA mapping constraints, thanks to
commit da28947e7e "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 <stefanr@s5r6.in-berlin.de>
2011-05-10 22:53:46 +02:00
Stefan Richter
b75ca5ea8e firewire: sbp2: omit Scsi_Host lock from queuecommand
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 <stefanr@s5r6.in-berlin.de>
2011-05-10 22:53:45 +02:00
Stefan Richter
6ea9e7bbfc firewire: core: use non-reentrant workqueue with rescuer
firewire-core manages the following types of work items:

fw_card.br_work:
  - resets the bus on a card and possibly sends a PHY packet before that
  - does not sleep for long or not at all
  - is scheduled via fw_schedule_bus_reset() by
      - firewire-ohci's pci_probe method
      - firewire-ohci's set_config_rom method, called by kernelspace
        protocol drivers and userspace drivers which add/remove
	Configuration ROM descriptors
      - userspace drivers which use the bus reset ioctl
      - itself if the last reset happened less than 2 seconds ago

fw_card.bm_work:
  - performs bus management duties
  - usually does not (but may in corner cases) sleep for long
  - is scheduled via fw_schedule_bm_work() by
      - firewire-ohci's self-ID-complete IRQ handler tasklet
      - firewire-core's fw_device.work instances whenever the root node
        device was (successfully or unsuccessfully) discovered,
	refreshed, or rediscovered
      - itself in case of resource allocation failures or in order to
        obey the 125ms bus manager arbitration interval

fw_device.work:
  - performs node probe, update, shutdown, revival, removal; including
    kernel driver probe, update, shutdown and bus reset notification to
    userspace drivers
  - usually sleeps moderately long, in corner cases very long
  - is scheduled by
      - firewire-ohci's self-ID-complete IRQ handler tasklet via the
        core's fw_node_event
      - firewire-ohci's pci_remove method via core's fw_destroy_nodes/
        fw_node_event
      - itself during retries, e.g. while a node is powering up

iso_resource.work:
  - accesses registers at the Isochronous Resource Manager node
  - usually does not (but may in corner cases) sleep for long
  - is scheduled via schedule_iso_resource() by
      - the owning userspace driver at addition and removal of the
        resource
      - firewire-core's fw_device.work instances after bus reset
      - itself in case of resource allocation if necessary to obey the
        1000ms reallocation period after bus reset

fw_card.br_work instances should not, and instances of the others must
not, be executed in parallel by multiple CPUs -- but were not protected
against that.  Hence allocate a non-reentrant workqueue for them.

fw_device.work may be used in the memory reclaim path in case of SBP-2
device updates.  Hence we need a workqueue with rescuer and cannot use
system_nrt_wq.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Reviewed-by: Tejun Heo <tj@kernel.org>
2011-05-10 22:53:45 +02:00
Clemens Ladisch
13882a82ee firewire: optimize iso queueing by setting wake only after the last packet
When queueing iso packets, the run time is dominated by the two
MMIO accesses that set the DMA context's wake bit.  Because most
drivers submit packets in batches, we can save much time by
removing all but the last wakeup.

The internal kernel API is changed to require a call to
fw_iso_context_queue_flush() after a batch of queued packets.
The user space API does not change, so one call to
FW_CDEV_IOC_QUEUE_ISO must specify multiple packets to take
advantage of this optimization.

In my measurements, this patch reduces the time needed to queue
fifty skip packets from userspace to one sixth on a 2.5 GHz CPU,
or to one third at 800 MHz.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2011-05-10 22:53:45 +02:00
Stefan Richter
f30e6d3e41 firewire: octlet AT payloads can be stack-allocated
We do not need slab allocations anymore in order to satisfy
streaming DMA mapping constraints, thanks to commit da28947e7e
"firewire: ohci: avoid separate DMA mapping for small AT payloads".

(Besides, the slab-allocated buffers that firewire-core, firewire-sbp2,
and firedtv used to provide for 8-byte write and lock requests were
still not fully portable since they crossed cacheline boundaries or
shared a cacheline with unrelated CPU-accessed data.  snd-firewire-lib
got this aspect right by using an extra kmalloc/ kfree just for the
8-byte transaction buffer.)

This change replaces kmalloc'ed lock transaction scratch buffers in
firewire-core, firedtv, and snd-firewire-lib by local stack allocations.
Perhaps the most notable result of the change is simpler locking because
there is no need to serialize usages of preallocated per-device buffers
anymore.  Also, allocations and deallocations are simpler.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
2011-05-10 22:53:44 +02:00
Stefan Richter
020abf03cd Merge tag 'v2.6.39-rc7'
in order to pull in changes in drivers/media/dvb/firewire/ and
sound/firewire/.
2011-05-10 22:50:41 +02:00
Linus Torvalds
8db72a7d72 Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: Fix for broken configrom updates in quick succession
2011-05-04 14:21:39 -07:00
B.J. Buchalter
2e053a27d9 firewire: Fix for broken configrom updates in quick succession
Current implementation of ohci_set_config_rom() uses a deferred
bus reset via fw_schedule_bus_reset(). If clients add multiple
unit descriptors to the config_rom in quick succession, the
deferred bus reset may not have fired before succeeding update
requests have come in. This can lead to an incorrect partial
update of the config_rom for both addition and removal of
config_rom descriptors, as the ohci_set_config_rom() routine
will return -EBUSY if a previous pending update has not been
completed yet; the requested update just gets dropped on the floor.

This patch recognizes that the "in-flight" update can be modified
until it has been processed by the bus-reset, and the locking
in the bus_reset_tasklet ensures that the update is done atomically
with respect to modifications made by ohci_set_config_rom(). The
-EBUSY error case is simply removed.

[Stefan R:  The bug always existed at least theoretically.  But it
became easy to trigger since 2.6.36 commit 02d37bed18 "firewire: core:
integrate software-forced bus resets with bus management" which
introduced long mandatory delays between janitorial bus resets.]

Signed-off-by: Benjamin Buchalter <bj@mhlabs.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (trivial style changes)
Cc: <stable@kernel.org> # 2.6.36.y and newer
2011-05-02 22:55:22 +02:00
Clemens Ladisch
0ff8fbc617 firewire: ohci: optimize find_branch_descriptor()
When z==2, the condition "key == 2" is superfluous because it cannot
occur without "b == 3", as a descriptor with b!=3 and key==2 would be
an OUTPUT_MORE_IMMEDIATE descriptor which cannot be used alone.

Also remove magic numbers and needless computations on the b field.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2011-04-19 20:00:11 +02:00
Clemens Ladisch
da28947e7e firewire: ohci: avoid separate DMA mapping for small AT payloads
For AT packet payloads of up to eight bytes, we have enough unused space
in the DMA descriptors list so that we can put a copy of the payload
there and thus avoid having to create a separate streaming DMA mapping
for the payload buffer.

In a CPU-bound microbenchmark that just sends 8-byte packets, bandwidth
was measured to increase by 5.7 %, from 1009 KB/s to 1067 KB/s.  In
practice, the only performance-sensitive usage of small asynchronous
packets is the SBP-2 driver's write to the ORB_POINTER register during
SCSI command submission.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2011-04-19 20:00:11 +02:00
Clemens Ladisch
ecf8328e59 firewire: ohci: do not start DMA contexts before link is enabled
OHCI 1.1 5.7.3 not only forbids enabling or starting any DMA contexts
before the linkEnable bit is set, but also explicitly warns of undefined
behaviour if this order is violated.

Don't violate it then.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2011-04-19 20:00:10 +02:00
Lucas De Marchi
25985edced Fix common misspellings
Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-31 11:26:23 -03:00
Linus Torvalds
c3ca48f062 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: core: ignore link-active bit of new nodes, fix device recognition
  firewire: sbp2: revert obsolete 'fix stall with "Unsolicited response"'
  firewire: core: increase default SPLIT_TIMEOUT value
  firewire: ohci: Misleading kfree in ohci.c::pci_probe/remove
  firewire: ohci: omit IntEvent.busReset check rom AT queueing
  firewire: ohci: prevent starting of iso contexts with empty queue
  firewire: ohci: prevent iso completion callbacks after context stop
  firewire: core: rename some variables
  firewire: nosy: should work on Power Mac G4 PCI too
  firewire: core: fix card->reset_jiffies overflow
  firewire: cdev: remove unneeded reference
  firewire: cdev: always wait for outbound transactions to complete
  firewire: cdev: remove unneeded idr_find() from complete_transaction()
  firewire: ohci: log dead DMA contexts
2011-03-21 10:05:22 -07:00
Stefan Richter
115881d395 firewire: core: ignore link-active bit of new nodes, fix device recognition
Like the older ieee1394 core driver, firewire-core skipped scanning of
any new node whose PHY sent a self ID without "link active" bit.  If a
device had this bit off mistakenly, it meant that it was inaccessible to
kernel drivers with the old IEEE 1394 driver stack but could still be
accessed by userspace drivers through the raw1394 interface.

But with firewire-core, userspace drivers don't get to see such buggy
devices anymore.  This is effectively a driver regression since this
device bug is otherwise harmless.

We now attempt to scan all devices, even repeaters that don't have a
link or powered-down devices that have everything but their PHY shut
down when plugged in.  This results in futile repeated scanning attempts
in case of such devices that really don't have an active link, but this
doesn't hurt since recent workqueue infrastructure lets us run more
concurrent scanning jobs than we can shake a stick at.

This should fix accessibility of Focusrite Saffire PRO 26 I/O:
http://sourceforge.net/mailarchive/forum.php?thread_name=20110314215622.5c751bb0%40stein&forum_name=ffado-user

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2011-03-20 16:45:25 +01:00