20 Aug, 2008
3 commits
-
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
-
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
-
Regression since commit 73cf60232ef16e1f8a64defa97214a1722db1e6c,
"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
25 Jul, 2008
1 commit
-
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
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
22 Jul, 2008
3 commits
-
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman -
device_create() is race-prone, so use the race-free
device_create_drvdata() instead as device_create() is going away.Cc: Ben Collins
Acked-by: Stefan Richter
Signed-off-by: Greg Kroah-Hartman
16 Jul, 2008
1 commit
-
* '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
14 Jul, 2008
6 commits
-
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
Also affects users of the rawiso ioctl API of raw1394.
Signed-off-by: Stefan Richter
-
Actually in this case wrap the function for now.
Signed-off-by: Alan Cox
Added raw1394_compat_ioctl hunk.
Signed-off-by: Stefan Richter
-
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
-
This avoids redundant messages about a special and usually harmless
firmware flaw.Signed-off-by: Stefan Richter
-
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
-
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
19 Jun, 2008
1 commit
-
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 outputThe 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 supportSigned-off-by: Stefan Richter
21 May, 2008
1 commit
-
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
02 May, 2008
2 commits
-
* '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
Tested-by: Miles Lane
26 Apr, 2008
3 commits
-
* '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
Ditto with dv1394_id_table and video1394_id_table.
Signed-off-by: Stefan Richter
-
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
Signed-off-by: Stefan Richter
19 Apr, 2008
1 commit
-
Signed-off-by: Matthew Wilcox
18 Apr, 2008
12 commits
-
The following patch limits the node speed to the host interface speed,
before using it.Signed-off-by: Philippe De Muyter
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=12024Signed-off-by: Stefan Richter
-
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
Signed-off-by: Stefan Richter -
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
-
to reduce the size of ohci1394.ko.
Signed-off-by: Stefan Richter
-
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
-
Signed-off-by: Robert P. J. Day
Signed-off-by: Stefan Richter -
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison
Signed-off-by: Andrew Morton
Signed-off-by: Stefan Richter -
Clean up shared code and variable names.
Signed-off-by: Stefan Richter
-
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
-
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
-
replace all:
big_endian_variable = cpu_to_beX(beX_to_cpu(big_endian_variable) +
expression_in_cpu_byteorder);
with:
beX_add_cpu(&big_endian_variable, expression_in_cpu_byteorder);
generated with semantic patchSigned-off-by: Marcin Slusarz
Signed-off-by: Stefan Richter -
Signed-off-by: Stefan Richter
14 Mar, 2008
1 commit
-
Fix I/O errors due to SYM13FW500's inability to handle larger request
sizes. Reported by Piergiorgio Sartor for
firewire-sbp2 in https://bugzilla.redhat.com/show_bug.cgi?id=436879This fix is necessary because sbp2's default request size limit has been
lifted since 2.6.25-rc1.Signed-off-by: Stefan Richter
Signed-off-by: Jarod Wilson
20 Feb, 2008
1 commit
-
rescan-scsi-bus used to add SBP-2 targets which weren't there.
Signed-off-by: Stefan Richter
16 Feb, 2008
1 commit
-
Add the same workaround as found in fw-sbp2 for feature parity and
compatibility of the workarounds module parameter.Signed-off-by: Stefan Richter
Signed-off-by: Jarod Wilson
02 Feb, 2008
1 commit
-
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 825f1df545ab0289185373b0eaf06fb0b3487422.Signed-off-by: Stefan Richter
31 Jan, 2008
2 commits
-
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
-
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