On many Linux installations, the dv1394 driver will be auto-loaded
whenever an AV/C device (e.g. camcorder or audio device) is plugged in.
An irritating message would then appear in the kernel log.
Defer this message to until a dv1394 character device file is actually
used by a program. Also include the program name in the message and
update the message slightly.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
ieee1394: sbp2: add workarounds for 2nd and 3rd generation iPods
firewire: sbp2: add workarounds for 2nd and 3rd generation iPods
firewire: sbp2: fix DMA mapping leak on the failure path
firewire: sbp2: define some magic numbers as macros
firewire: sbp2: fix payload limit at S1600 and S3200
ieee1394: sbp2: don't assume zero model_id or firmware_revision if there is none
ieee1394: sbp2: fix payload limit at S1600 and S3200
ieee1394: sbp2: update a help string
ieee1394: support for speeds greater than S800
firewire: core: optimize card shutdown
ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others
firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others
firewire: ohci: change "context_stop: still active" log message
firewire: keep highlevel drivers attached during brief connection loss
firewire: unnecessary BM delay after generation rollover
firewire: insist on successive self ID complete events
as per https://bugs.launchpad.net/bugs/294391. These got one sample of
each iPod generation going. However there still occurred I/O stalls
with the 3rd generation iPod which remain undiagnosed at the time of
this writing.
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This makes sbp2 behave more like firewire-sbp2 which reports 0xff000000
as immediate value if there are no unit directory entries for model_id
or firmware_revision.
It does not reduce matches with the currently existing quirks table; the
only zero entry there is for a device which actually does have a zero
model_id. It only changes how model_id and firmware_revision are logged
if they are missing.
Other functionally unrelated changes: The model_id member of quirks
list entries is renamed to model; the value (but not the effect) of
SBP2_ROM_VALUE_WILDCARD is changed. Now this part of the source is
identical with firewire-sbp2 for easier maintenance.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
1394-2008 clause 16.3.4.1 (1394b-2002 clause 16.3.1.1) defines tighter
limits than 1394-2008 clause 6.2.2.3 (1394a-2000 clause 6.2.2.3).
Our previously too large limit doesn't matter though if the controller
reports its max_receive correctly.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The hard-wired configuration of the top speed (until now S800) was
unnecessary, remove it.
If the local link layer controller supports S1600 or S3200, we now
assume this speed for all present 1394b PHYs (except if they are
behind 1394a repeaters) until nodemgr figured out the actual speed
while fetching the config ROM.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Camcorders have a tendency to fail read requests to their config ROM and
write request to their FCP command register with ack_busy_X. This has
become a problem with newer kernels and especially Panasonic camcorders,
causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently
logs "send oops"; kino reports loss of AV/C control. I suspect that
lower CPU scheduling latencies in newer kernels made this issue more
prominent now.
According to
https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103
this can be fixed by configuring the FireWire controller for more
hardware retries for request transmission; these retries are evidently
more successful than libavc1394's own retry loop (typically 3 tries on
top of hardware retries).
Presumably the same issue has been reported at
https://bugzilla.redhat.com/show_bug.cgi?id=449252 and
https://bugzilla.redhat.com/show_bug.cgi?id=477279 .
Tested-by: Mathias Beilstein
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Use the network_device_stats field in network_device.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Last_rx is now done if needed inside bonding.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Convert to net_device_ops.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
After annotating the frame structs, this was left:
drivers/ieee1394/dv1394.c:2113:23: warning: invalid assignment: |=
drivers/ieee1394/dv1394.c:2113:23: left side has type restricted __le32
drivers/ieee1394/dv1394.c:2113:23: right side has type int
drivers/ieee1394/dv1394.c:2121:24: warning: invalid assignment: &=
drivers/ieee1394/dv1394.c:2121:24: left side has type restricted __le32
drivers/ieee1394/dv1394.c:2121:24: right side has type int
drivers/ieee1394/dv1394.c:2123:24: warning: invalid assignment: |=
drivers/ieee1394/dv1394.c:2123:24: left side has type restricted __le32
drivers/ieee1394/dv1394.c:2123:24: right side has type int
Which looks like a real bug on a big-endian arch as it would set/clear
the wrong bit.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Bill Fink writes:
I finally got a chance to test the patch on my kernel, and live DV
viewing using xine still worked fine. Although I admit to being
mystified how it works both before and after the patch, since the
cpu_to_le32() calls that were added should result in byte swapping on
PPC that wasn't being done before. I guess that either the code paths
involved aren't actually being triggered by my xine DV viewing, or
there's some fortuitous palindromic setting of bits.
Tested-by: Bill Fink <billfink@mindspring.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Mostly annotations of ether_type as a be16.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Two access functions get_max_rom and set_hw_config_rom are
changed to take __be32 as well. Only bus_info_data was
ever passed in so this is OK. All other uses of bus_info_data
treated it as a be32 value already.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
bus_info_block was treated as a be32 everywhere, annotate
as such. Removes plenty of sparse warnings.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
It is already known that buggy firmwares exist which report a bogus
link_spd in their config ROM bus info block. We now got the first
report of a bogus max_rom too (Freecom FireWire Hard Drive 1TB,
http://bugzilla.kernel.org/show_bug.cgi?id=12206).
I suspect other OSs only use quadlet reads to fetch the config ROM,
otherwise the firmware authors would have noticed their mistake.
Hence limit ieee1394's config ROM fetching routine to quadlets as the
safe minimum regardless of what the bus info block says.
This will potentially slow the bus reset handling by nodemgr somewhat
down. But most existing devices support only quadlet reads anyway,
hence there will often be no actual difference to before this change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Move the definition out of nodemgr.h and use it in csr.c/pcilynx.c
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
On my HP 2510p I get the following in dmesg during near the end of most
resumes from suspend to RAM:
irq 19: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Not tainted 2.6.28-rc7 #67
Call Trace:
<IRQ> [<ffffffffa00ee9e1>] ? ohci_irq_handler+0x60/0x7e9 [ohci1394]
[<ffffffff8026aa4d>] __report_bad_irq+0x38/0x87
[<ffffffff8026abaa>] note_interrupt+0x10e/0x174
[<ffffffff8026b262>] handle_fasteoi_irq+0xa7/0xd1
[<ffffffff8020eb87>] do_IRQ+0x73/0xe4
[<ffffffff8020c626>] ret_from_intr+0x0/0xa
<EOI> [<ffffffffa0012606>] ? acpi_idle_enter_bm+0x26b/0x2b2 [processor]
[<ffffffffa00125fc>] ? acpi_idle_enter_bm+0x261/0x2b2 [processor]
[<ffffffff8024f30f>] ? notifier_call_chain+0x33/0x5b
[<ffffffff803b9c64>] ? cpuidle_idle_call+0x8c/0xc4
[<ffffffff8020b312>] ? cpu_idle+0x4a/0x9a
[<ffffffff8042c5c8>] ? rest_init+0x5c/0x5e
handlers:
[<ffffffffa00ee981>] (ohci_irq_handler+0x0/0x7e9 [ohci1394])
Disabling IRQ #19
There also seems to be an interrupt storm during suspend/resume when this
happens:
19: 99968 33 IO-APIC-fasteoi ohci1394
This patch gets rid of both issues and makes the resume as a whole
significantly faster.
Signed-off-by: Frans Pop <elendil@planet.nl>
As was pointed out in http://lkml.org/lkml/2008/12/6/127, this does not
fix the cause of the interrupt storm. However, since the source of the
interrupts could not be determined yet, we make the system at least more
usable with this change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
According to http://bugzilla.kernel.org/show_bug.cgi?id=12206, Freecom
FireWire Hard Drive 1TB reports max_rom=2 but returns garbage if block
read requests are used to read the config ROM. Force max_rom=0 to limit
them to quadlet read requests.
Reported-by: Christian Mueller <cm1@mumac.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The firewire nodemanager function "nodemgr_host_thread" contains a loop
that calls try_to_freeze near the top of the loop, but then delays for
up to 3.25 seconds (plus time to do work) before getting back to the top
of the loop. When starting a cycle post-boot, this doesn't seem to bite,
but it is causing a noticeable delay at boot time, when freezing
processes prior to starting to read the image.
The following patch adds invocation of try_to_freeze to the subloops
that are used in the body of this function. With these additions, the
time to freeze when starting to resume at boot time is virtually zero.
I'm no expert on firewire, and so don't know that we shouldn't check
the return value and jump back to the top of the loop or such like after
being frozen, but I submit it for your consideration.
Signed-off-by: Nigel Cunningham <nigel@tuxonice.net>
The delay until nodemgr freezes was up to 0.25s (plus time for node
probes) in Linux 2.6.27 and older and up to 3.25s (plus ~) since Linux
2.6.28-rc1, hence much more noticeable.
try_to_freeze() without any jump is correct. The surrounding code in
the respective loops will catch whether another bus reset happens during
the freeze and handle it.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
An intermediate transition from _RUNNING to _IN_SHUTDOWN could have been
missed by the former code.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If there is more than one FireWire controller present, dummy_zero_addr
and dummy_max_addr were added multiple times to different lists, thus
corrupting the lists. Fix this by allocating them dynamically per host
instead of just once globally.
(Perhaps a better address space allocation algorithm could rid us of the
two dummy address spaces.)
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=10129 .
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Add another model ID of a broken firmware to prevent early I/O errors
by acesses at the end of the disk. Reported at linux1394-user,
http://marc.info/?t=122670842900002
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
As it is, all instances of ->release() for files that have ->fasync()
need to remember to evict file from fasync lists; forgetting that
creates a hole and we actually have a bunch that *does* forget.
So let's keep our lives simple - let __fput() check FASYNC in
file->f_flags and call ->fasync() there if it's been set. And lose that
crap in ->release() instances - leaving it there is still valid, but we
don't have to bother anymore.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix a possible though highly unlikely deadlock:
Thread A: Thread B:
- acquire mmap_sem - dv1394_ioctl/read/write()
- dv1394_mmap() - acquire video->mtx
- acquire video->mtx - copy_to/from_user(), possible page fault:
acquire mmap_sem
The simplest fix is to use mutex_trylock() instead of mutex_lock() in
dv1394_mmap(). This changes the behavior under contention in a way
which is visible to userspace clients. However, my guess is that no
clients exist which use mmap vs. ioctl/read/write on the dv1394
character device file interface in concurrent threads.
Reported-by: Johannes Weiner <hannes@saeurebad.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Regression in 2.6.28-rc1: When I added the new state_mutex which
prevents corruption of raw1394's internal state when accessed by
multithreaded client applications, the following possible though
highly unlikely deadlock slipped in:
Thread A: Thread B:
- acquire mmap_sem - raw1394_write() or raw1394_ioctl()
- raw1394_mmap() - acquire state_mutex
- acquire state_mutex - copy_to/from_user(), possible page fault:
acquire mmap_sem
The simplest fix is to use mutex_trylock() instead of mutex_lock() in
raw1394_mmap(). This changes the behavior under contention in a way
which is visible to userspace clients. However, since multithreaded
access was entirely buggy before state_mutex was added and libraw1394's
documentation advised application programmers to use a handle only in a
single thread, this change in behaviour should not be an issue in
practice at all.
Since we have to use mutex_trylock() in raw1394_mmap() regardless
whether /dev/raw1394 was opened with O_NONBLOCK or not, we now use
mutex_trylock() unconditionally everywhere for state_mutex, just to have
consistent behavior.
Reported-by: Johannes Weiner <hannes@saeurebad.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
firewire: Add more documentation to firewire-cdev.h
firewire: fix ioctl() return code
firewire: fix setting tag and sy in iso transmission
firewire: fw-sbp2: fix another small generation access bug
firewire: fw-sbp2: enforce s/g segment size limit
firewire: fw_send_request_sync()
ieee1394: survive a few seconds connection loss
ieee1394: nodemgr clean up class iterators
ieee1394: dv1394, video1394: remove unnecessary expressions
ieee1394: raw1394: make write() thread-safe
ieee1394: raw1394: narrow down the state_mutex protected region
ieee1394: raw1394: replace BKL by local mutex, make ioctl() and mmap() thread-safe
ieee1394: sbp2: enforce s/g segment size limit
ieee1394: sbp2: check for DMA mapping failures
ieee1394: sbp2: stricter dma_sync
ieee1394: Use DIV_ROUND_UP
Now that device_create() has been audited, rename things back to the
original call to be sane.
Cc: Ben Collins <ben.collins@ubuntu.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are situations when nodes vanish from the bus and come back in
quickly thereafter:
- When certain bus-powered hubs are plugged in,
- when certain disk enclosures are switched from self-power to bus
power or vice versa and break the daisy chain during the transition,
- when the user plugs a cable out and quickly plugs it back in, e.g.
to reorder a daisy chain (works on Mac OS X if done quickly enough),
- when certain hubs temporarily malfunction during high bus traffic.
The ieee1394 driver's nodemgr already contained a function to set
vanished nodes aside into "limbo"; i.e. they wouldn't actually be
deleted right away. (In fact, only unloading the driver or writing into
an obscure sysfs attribute would delete them eventually.) If nodes
reappeared later, they would be resurrected out of limbo.
Moving nodes into and out of limbo was accompanied with calling the
.suspend() and .resume() driver methods of the drivers which were bound
to a respective node's unit directories. Not only is this somewhat
strange due to the intended use of these driver methods for power
management, also the sbp2 driver in particular does not implement
.suspend() and .resume(). Hence sbp2 would be disconnected from devices
in situations as listed above.
We now:
- leave drivers bound when nodes go into limbo,
- call the drivers' .update() when nodes come out of limbo,
- automatically delete in-limbo nodes 3 seconds after the last
bus reset and bus rescan.
- Because of the automatic removal, the now obsolete bus attribute
/sys/bus/ieee1394/destroy_node is removed.
This especially lets sbp2 survive brief disconnections. You can for
example yank a disk's cable and plug it back in while reading the
respective disk with dd, but dd will happily continue as if nothing
happened.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Remove useless pointer type casts.
Remove unnecessary hi->host indirection where only host is used.
Remove an unnecessary WARN_ON.
Change a few names.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
init->channel and v.buffer are unsigned and tests for < 0 therefore
always false. gcc knows this and eliminates the code, but anyway...
Reported by Roel Kluin.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Application programs should use a libraw1394 handle only in a single
thread. The raw1394 driver was apparently relying on this, because it
did nothing to protect its fi->state variable from corruption due to
concurrent accesses.
We now serialize the fi->state accesses. This affects the write() path.
We re-use the state_mutex which was introduced to protect fi->iso_state
accesses in the ioctl() path. These paths and accesses are independent
of each other, hence separate mutexes could be used. But I don't see
much benefit in that.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Refactor the ioctl dispatcher in order to move a fraction of it out of
the section which is serialized by fi->state_mutex. This is not so much
about performance but more about self-documentation: The mutex_lock()/
mutex_unlock() calls are now closer to the data accesses which the mutex
protects, i.e. to the iso_state switch.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This removes the last usage of the Big Kernel Lock from the ieee1394
stack, i.e. from raw1394's (unlocked_)ioctl and compat_ioctl.
The ioctl()s don't need to take the BKL, but they need to be serialized
per struct file *. In particular, accesses to ->iso_state need to be
serial. We simply use a blocking mutex for this purpose because
libraw1394 does not use O_NONBLOCK. In practice, there is no lock
contention anyway because most if not all libraw1394 clients use a
libraw1394 handle only in a single thread.
mmap() also accesses ->iso_state. Until now this was unprotected
against concurrent changes by ioctls. Fix this bug while we are at it.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
1. We don't need to round the SBP-2 segment size limit down to a
multiple of 4 kB (0xffff -> 0xf000). It is only necessary to
ensure quadlet alignment (0xffff -> 0xfffc).
2. Use dma_set_max_seg_size() to tell the DMA mapping infrastructure
and the block IO layer about the restriction. This way we can
remove the size checks and segment splitting in the queuecommand
path.
This assumes that no other code in the ieee1394 stack uses
dma_map_sg() with conflicting requirements. It furthermore assumes
that the controller device's platform actually allows us to set the
segment size to our liking. Assert the latter with a BUG_ON().
3. Also use blk_queue_max_segment_size() to tell the block IO layer
about it. It cannot know it because our scsi_add_host() does not
point to the FireWire controller's device.
We can also uniformly use dma_map_sg() for the single segment case just
like for the multi segment case, to further simplify the code.
Also clean up how the page table is converted to big endian.
Thanks to Grant Grundler and FUJITA Tomonori for advice.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Two dma_sync_single_for_cpu() were called in the wrong place.
Luckily they were merely for DMA_TO_DEVICE, hence nobody noticed.
Also reorder the matching dma_sync_single_for_device() a little bit
so that they reside in the same functions as their counterparts.
This also avoids syncing the s/g table for requests which don't use it.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
sbp2 was too quick to report .update() to the ieee1394 core as failed.
(Logged as "Failed to reconnect to sbp2 device!".) The core would then
unbind sbp2 from the device.
This is not justified if the .update() failed because another bus reset
happened. We check this and tell the ieee1394 that .update() succeeded,
and the core will call sbp2's .update() for the new bus reset as well.
This improves reconnection/re-login especially on buses with several
disks as they may issue bus resets in close succession when they come
online.
Tested by Damien Benoist.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
nodemgr_node_probe checked for generation increments too late and
therefore prematurely reported nodes as "suspended".
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=11349. Reported and
tested by Damien Benoist.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Regression since commit 73cf60232e,
"ieee1394: use class iteration api": The two loops for (1.) driver
updates and (2.) driver probes were replaced by a single loop with
bogus needs_probe checks. Hence updates and probes were now intermixed,
and especially sbp2 updates (reconnects) held up longer than necessary.
While we fix it, change the needs_probe flag to bool type for clarity.
Tested by Damien Benoist.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit
boundary. For example:
u64 val = PAGE_ALIGN(size);
always returns a value < 4GB even if size is greater than 4GB.
The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for
example):
#define PAGE_SHIFT 12
#define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
#define PAGE_MASK (~(PAGE_SIZE-1))
...
#define PAGE_ALIGN(addr) (((addr)+PAGE_SIZE-1)&PAGE_MASK)
The "~" is performed on a 32-bit value, so everything in "and" with
PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary.
Using the ALIGN() macro seems to be the right way, because it uses
typeof(addr) for the mask.
Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in
include/linux/mm.h.
See also lkml discussion: http://lkml.org/lkml/2008/6/11/237
[akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c]
[akpm@linux-foundation.org: fix v850]
[akpm@linux-foundation.org: fix powerpc]
[akpm@linux-foundation.org: fix arm]
[akpm@linux-foundation.org: fix mips]
[akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c]
[akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c]
[akpm@linux-foundation.org: fix powerpc]
Signed-off-by: Andrea Righi <righi.andrea@gmail.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This mirrors the functionality that driver_find_device has as well.
We add a start variable, and all callers of the function are fixed up at
the same time.
The block layer will be using this new functionality in a follow-on
patch.
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This mirrors the functionality that driver_for_each_device has as well.
We add a start variable, and all callers of the function are fixed up at
the same time.
The block layer will be using this new functionality in a follow-on
patch.
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
device_create() is race-prone, so use the race-free
device_create_drvdata() instead as device_create() is going away.
Cc: Ben Collins <ben.collins@ubuntu.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'sbp2-spindown' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
ieee1394: sbp2: spin disks down on suspend and shutdown
firewire: fw-sbp2: spin disks down on suspend and shutdown
ieee1394: sbp2: fix spindown for PL-3507 and TSB42AA9 firmwares
firewire: fw-sbp2: fix spindown for PL-3507 and TSB42AA9 firmwares
scsi: sd: optionally set power condition in START STOP UNIT
Currently, core files do not contain the mmapped memory of the video1394
or dv1394 devices, which contain the actual video input, making it
impossible to analyse the cause of abnormal program termination for
image analysis or (de)compression software. Fix that.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Also affects users of the rawiso ioctl API of raw1394.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Actually in this case wrap the function for now.
Signed-off-by: Alan Cox <alan@redhat.com>
Added raw1394_compat_ioctl hunk.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This prepares video1394 for removal of the BKL (big kernel lock):
It allows video1394_open() to be called while video1394_init_module()
is still in progress.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This instructs sd_mod to send START STOP UNIT on suspend and resume,
and on driver unbinding or unloading (including when the system is shut
down).
We don't do this though if multiple initiators may log in to the target.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Reported by Tino Keitel: PL-3507 with firmware from Prolific does not
spin down the disk on START STOP UNIT with power condition = 0 and start
= 0. It does however work with power condition = 2 or 3.
Also found while investigating this: DViCO Momobay CX-1 and FX-3A (TI
TSB42AA9/A based) become unresponsive after START STOP UNIT with power
condition = 0 and start = 0. They stay responsive if power condition is
set when stopping the motor.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Rename and reorder some prompts and modify some help texts.
The result:
-------------------- IEEE 1394 (FireWire) support --------------------
*** Enable only one of the two stacks, unless you know what you are doing ***
New FireWire stack, EXPERIMENTAL
OHCI-1394 controllers
Storage devices (SBP-2 protocol)
Stable FireWire stack
OHCI-1394 controllers
PCILynx controller
Storage devices (SBP-2 protocol)
Enable replacement for physical DMA in SBP2
IP over 1394
raw1394 userspace interface
video1394 userspace interface
dv1394 userspace interface (deprecated)
Excessive debugging output
The old prompts for reference:
-------------------- IEEE 1394 (FireWire) support --------------------
IEEE 1394 (FireWire) support - alternative stack, EXPERIMENTAL
Support for OHCI FireWire host controllers
Support for storage devices (SBP-2 protocol driver)
IEEE 1394 (FireWire) support
*** Subsystem Options ***
Excessive debugging output
*** Controllers ***
Texas Instruments PCILynx support
OHCI-1394 support
*** Protocols ***
OHCI-1394 Video support
SBP-2 support (Harddisks etc.)
Enable replacement for physical DMA in SBP2
IP over 1394
OHCI-DV I/O support (deprecated)
Raw IEEE1394 I/O support
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Boaz Harrosh wrote:
> cmd->cmd_len is now guarantied to be set properly at all cases.
> And some commands you want to support will not be set correctly
> by COMMAND_SIZE().
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
firewire: fw-sbp2: log scsi_target ID at release
ieee1394: fix NULL pointer dereference in sysfs access
Regression since "ieee1394: prevent device binding of raw1394,
video1394, dv1394", commit d2ace29fa44589da51fedc06a67b3f05301f3bfd:
$ cat /sys/bus/ieee1394/drivers/raw1394/device_ids
triggers a NULL pointer dereference in fw_show_drv_device_ids.
Reported by Miles Lane.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Tested-by: Miles Lane <miles.lane@gmail.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
ieee1394: silence defined but not used warning in non-modular builds
ieee1394: rawiso: requeue packet for transmission after skipped cycle
Currently the kernel will issue the following warning:
drivers/ieee1394/raw1394.c:2938: warning: 'raw1394_id_table' defined but not used
Add #ifdef MODULE guards around the declaration.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Ditto with dv1394_id_table and video1394_id_table.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
As it seems, some host controllers have issues that can cause them to
skip cycles now and then when using large packets. I suspect that this
is due to DMA not succeeding in time. If the transmit fifo can't contain
more than one packet (big packets), the DMA should provide a new packet
each cycle (125us). I am under the impression that my current PCI
express test system can't guarantee this.
In any case, the patch tries to provide a workaround as follows:
The DMA program descriptors are modified such that when an error occurs,
the DMA engine retries the descriptor the next cycle instead of
stalling. This way no data is lost. The side effect of this is that
packets are sent with one cycle delay. This however might not be that
much of a problem for certain protocols (e.g. AM824). If they use
padding packets for e.g. rate matching they can drop one of those to
resync the streams.
The amount of skips between two userspace wakeups is counted. This
number is then propagated to userspace through the upper 16 bits of the
'dropped' parameter. This allows unmodified userspace applications due
to the following:
1) libraw simply passes this dropped parameter to the user application
2) the meaning of the dropped parameter is: if it's nonzero, something
bad has happened. The actual value of the parameter at this moment does
not have a specific meaning.
A libraw client can then retrieve the number of skipped cycles and
account for them if needed.
Signed-off-by: Pieter Palmers <pieterp@joow.be>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The following patch limits the node speed to the host interface speed,
before using it.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
It should actually suffice to do this only for the local node's
speedcap[]. But there is another bug in the speed calculation:
The local node's speed is not correctly propagated to the speeds
which are to be used to access remote nodes.
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/11772/focus=12024
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Unless you're adding a kobject to the sysfs hierarchy, there is no
point setting its kobject name.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The failure path of ohci1394_pci_probe() reuses ohci1394_pci_remove().
Doing so it missed to call ohci1394_pmac_off() in a few unlikely early
error cases.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
We don't want to hide something like return in a preprocessor macro.
Unroll the macro and use a goto, which also reduces the size of
ohci1394.ko.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The platform feature calls in the suspend method switched off cable
power, but the calls in the resume method did not switch it back on.
Add the necessary feature call to .resume. Also add the corresponding
call to .suspend to make .suspend's behavior explicitly the same on all
PMacs.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
These drivers don't need to match any unit_directory type device.
They just need the id_table for module autoloading per module alias.
Not binding any of these drivers allows special-purpose drivers with
similar or same IDs to bind to devices. This currently only benefits
out-of-tree drivers; on the other hand it is in no way detrimental to
in-tree drivers.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Fix I/O errors due to SYM13FW500's inability to handle larger request
sizes. Reported by Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> for
firewire-sbp2 in https://bugzilla.redhat.com/show_bug.cgi?id=436879
This fix is necessary because sbp2's default request size limit has been
lifted since 2.6.25-rc1.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Add the same workaround as found in fw-sbp2 for feature parity and
compatibility of the workarounds module parameter.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
sg_dma_len(sg) is invalid before the s/g list is DMA-mapped.
This fixes a post 2.6.24 regression which prevents access to SBP-2
devices on several architectures, introduced by "ieee1394: sbp2: s/g
list access cosmetics", commit 825f1df545.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Bug noted by Pieter Palmers: Isochronous transmit tasklets were
scheduled on isochronous receive events, in addition to the proper
isochronous receive tasklets.
http://marc.info/?l=linux1394-devel&m=119783196222802
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This patch speeds up sbp2 a little bit --- but more importantly, it
brings the behavior of sbp2 and fw-sbp2 closer to each other. Like
fw-sbp2, sbp2 now does not limit the size of single transfers to 255
sectors anymore, unless told so by a blacklist flag or by module load
parameters.
Only very old bridge chips have been known to need the 255 sectors
limit, and we have got one such chip in our hardwired blacklist. There
certainly is a danger that more bridges need that limit; but I prefer to
have this issue present in both fw-sbp2 and sbp2 rather than just one of
them.
An OXUF922 with 400GB 7200RPM disk on an S400 controller is sped up by
this patch from 22.9 to 23.5 MB/s according to hdparm. The same effect
could be achieved before by setting a higher max_sectors module
parameter. On buses which use 1394b beta mode, sbp2 and fw-sbp2 will
now achieve virtually the same bandwidth. Fw-sbp2 only remains faster
on 1394a buses due to fw-core's gap count optimization.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Convert ieee1394 from nopage to fault.
Remove redundant vma range checks (correct resource range check is retained).
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Replace sg->length by sg_dma_len(sg). Rename a variable for shorter
line lengths and eliminate some superfluous local variables.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This patch adds a new configuration option, which adds support for a new
early_param which gets checked in arch/x86/kernel/setup_{32,64}.c:setup_arch()
to decide wether OHCI-1394 FireWire controllers should be initialized and
enabled for physical DMA access to allow remote debugging of early problems
like issues ACPI or other subsystems which are executed very early.
If the config option is not enabled, no code is changed, and if the boot
paramenter is not given, no new code is executed, and independent of that,
all new code is freed after boot, so the config option can be even enabled
in standard, non-debug kernels.
With specialized tools, it is then possible to get debugging information
from machines which have no serial ports (notebooks) such as the printk
buffer contents, or any data which can be referenced from global pointers,
if it is stored below the 4GB limit and even memory dumps of of the physical
RAM region below the 4GB limit can be taken without any cooperation from the
CPU of the host, so the machine can be crashed early, it does not matter.
In the extreme, even kernel debuggers can be accessed in this way. I wrote
a small kgdb module and an accompanying gdb stub for FireWire which allows
to gdb to talk to kgdb using remote remory reads and writes over FireWire.
An version of the gdb stub fore FireWire is able to read all global data
from a system which is running a a normal kernel without any kernel debugger,
without any interruption or support of the system's CPU. That way, e.g. the
task struct and so on can be read and even manipulated when the physical DMA
access is granted.
A HOWTO is included in this patch, in Documentation/debugging-via-ohci1394.txt
and I've put a copy online at
ftp://ftp.suse.de/private/bk/firewire/docs/debugging-via-ohci1394.txt
It also has links to all the tools which are available to make use of it
another copy of it is online at:
ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diff
Signed-Off-By: Bernhard Kaindl <bk@suse.de>
Tested-By: Thomas Renninger <trenn@suse.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (200 commits)
[SCSI] usbstorage: use last_sector_bug flag universally
[SCSI] libsas: abstract STP task status into a function
[SCSI] ultrastor: clean up inline asm warnings
[SCSI] aic7xxx: fix firmware build
[SCSI] aacraid: fib context lock for management ioctls
[SCSI] ch: remove forward declarations
[SCSI] ch: fix device minor number management bug
[SCSI] ch: handle class_device_create failure properly
[SCSI] NCR5380: fix section mismatch
[SCSI] sg: fix /proc/scsi/sg/devices when no SCSI devices
[SCSI] IB/iSER: add logical unit reset support
[SCSI] don't use __GFP_DMA for sense buffers if not required
[SCSI] use dynamically allocated sense buffer
[SCSI] scsi.h: add macro for enclosure bit of inquiry data
[SCSI] sd: add fix for devices with last sector access problems
[SCSI] fix pcmcia compile problem
[SCSI] aacraid: add Voodoo Lite class of cards.
[SCSI] aacraid: add new driver features flags
[SCSI] qla2xxx: Update version number to 8.02.00-k7.
[SCSI] qla2xxx: Issue correct MBC_INITIALIZE_FIRMWARE command.
...
Convert to use the class iteration api.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch relaxes the default SCSI DMA alignment from 512 bytes to 4
bytes. I remember from previous discussions that usb and firewire have
sector size alignment requirements, so I upped their alignments in the
respective slave allocs.
The reason for doing this is so that we don't get such a huge amount of
copy overhead in bio_copy_user() for udev. (basically all inquiries it
issues can now be directly mapped).
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Torsten Kaiser wrote:
> Looking that calltrace upwards, it seems replacing the
> memset(dma->sglist,...) with sg_init_table(...) would fix the BUG_ON()
> as that inits the SG_MAGIC.
Tested-by: Torsten Kaiser <just.for.lkml@googlemail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Not architecture specific code should not #include <asm/scatterlist.h>.
This patch therefore either replaces them with
#include <linux/scatterlist.h> or simply removes them if they were
unused.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Stefan Richter
Linus Torvalds
Jean Delvare
David S. Miller
Stephen Hemminger
Harvey Harrison
Frans Pop
Nigel Cunningham
Al Viro
Kay Sievers
Greg Kroah-Hartman
Julia Lawall
Andrea Righi
Philippe De Muyter
Alan Cox
Tony Breeds
Pieter Palmers
Matthew Wilcox
Robert P. J. Day
Marcin Slusarz
Nick Piggin
Joe Perches
Bernhard Kaindl
Dave Young
James Bottomley
Jens Axboe
Adrian Bunk