Replace occurrences of the magic value ~(u64)0 for invalid
CSR address spaces by a named constant for better readability.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
The proper designator of an invalid CSR address is ~(u64)0, not (u64)0.
Use the correct value in initialization and deregistration.
Also, scsi_id->sbp2_lun does not need to be initialized twice.
(scsi_id was kzalloc'd.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
I've been experimenting to track down the cause of suspend/resume problems
on my Compaq Presario X1050 laptop:
http://bugzilla.kernel.org/show_bug.cgi?id=6075
Essentially the ACPI Embedded Controller and keyboard controller would
get into a bizarre, confused state after resume.
I found that unloading the ohci1394 module before suspend and reloading it
after resume made the problem go away. Diffing the dmesg output from
resume, with and without the module loaded, I found that with the module
loaded I was missing these:
PM: Writing back config space on device 0000:02:00.0 at offset 1. (Was 2100080, writing 2100007)
PM: Writing back config space on device 0000:02:00.0 at offset 3. (Was 0, writing 8008)
PM: Writing back config space on device 0000:02:00.0 at offset 4. (Was 0, writing 90200000)
PM: Writing back config space on device 0000:02:00.0 at offset 5. (Was 1, writing 2401)
PM: Writing back config space on device 0000:02:00.0 at offset f. (Was 20000100, writing 2000010a)
The default PCI driver performs the pci_restore_state when no driver is
loaded for the device. When the ohci1394 driver is loaded, it is supposed
to do this, however it appears not to do so.
I created the patch below and tested it, and it appears to resolve the
suspend problems I was having with the module loaded. I only added in the
pci_save_state and pci_restore_state - however, though I know little of
this hardware, surely the driver should really be doing more than this when
suspending and resuming? Currently it does almost nothing, what if there
are commands in progress, etc?
Signed-off-by: Robert Hancock <hancockr@shaw.ca>
Cc: Jody McIntyre <scjody@modernduck.com>
Cc: Ben Collins <bcollins@debian.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
It seems to have worked without the attribute during all the years
just because sizes of all struct members are multiples of 32 bits.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
It appears I will not get it fixed overnight.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
If sbp2 is forced to move data via ARM handler, the maximum packet size
allowed for S800 transfers exceeds ohci1394's buffer size on platforms
where PAGE_SIZE is 4096.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Being able to switch physical DMA on and off at run time would be a nice
feature but a PITA to support by highlevel drivers and userspace apps.
Therefore allow it only to be set when the driver is being loaded.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
This patch supplies the API extension introduced by patch
"ieee1394: extend lowlevel API for address range properties"
with proper addresses.
Like in patch ''ohci1394, sbp2: fix "scsi_add_device failed"
with PL-3507 based devices'', 1 TeraByte is chosen as physical
upper bound. This leaves a window for the middle address range.
This choice is only relevant for adapters which actually have a
programmable pysical upper bound register. (Only ALi and
Fujitsu adapters are known for this. Most adapters have a fixed
bound at 4 GB.) The middle address range is suitable for posted
writes.
AFAIK, PCILynx does not support physical DMA nor posted writes,
therefore no equivalent change in the pcilynx driver is necessary.
There is also a driver for GP2Lynx, although not in mainline Linux.
I assume this hardware does not support these OHCI features either.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Host adapter hardware imposes certain restrictions and features on
address ranges. Instead of hard-wire such ranges into the ieee1394
core or even into protocol drivers, let lowlevel drivers specify
these ranges via struct hpsb_host.
Patch "ohci1394: set address range properties" must be applied too,
else hpsb_allocate_and_register_addrspace() won't work properly.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Since this is useful information, promote it from a debug macro to
a regular log message. The message appears only if the user set
exclusive_login=0, therefore won't clutter the logs in normal use.
Also update the comment on exclusive_login.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
This code became ineffective a few Linux releases ago and is not
required anyway.
Note from Christoph Hellwig: scsi_cmnd.request_buffer is always a
scatterlist these days. Checking random bites into it and then
mangling the data in sbp2_check_sbp2_response will cause really bad
memory corruption when you're not lucky enough to have the check not
trigger by luck.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Since broadcast transactions are already complete when the request has
been sent, the same transaction label can be reused all over again, see
IEEE 1394 7.3.2.5 and 6.2.4.3. Therefore we can reduce the footprint
of struct hpsb_host by the size of one struct hpsb_tlabel_pool.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Add support for the following types of hardware:
+ nodes that have a link speed < PHY speed
+ 1394b PHYs that are less than S800 capable
+ 1394b/1394a adapter cable between two 1394b PHYs
Also, S1600 and S3200 are now supported if IEEE1394_SPEED_MAX is raised.
A probing function is added to nodemgr's config ROM fetching routine
which adjusts the allowable speed if an access problem was encountered.
Pros and Cons of the approach:
+ minimum code footprint to support this less widely used hardware
+ nearly no overhead for unaffected hardware
- ineffective before nodemgr began to read the ROM of affected nodes
- ineffective if ieee1394 is loaded with disable_nodemgr=1
The speed map CSRs which are published to the bus are not touched by the
patch.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Hakan Ardo <hakan@debian.org>
Cc: Calculex <linux@calculex.com>
Cc: Robert J. Kosinski <robk@cmcherald.com>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
This patch modifies the ohci1394.c file to enable and manage the "cycle too
long" interrupt.
If this interrupt occurs, the "LinkControl.CycleMaster" bit of the host
controller is reseted. This implies, that the host controller does not send
"cycle start" packet anymore freezing then the isochronous communication.
The management of the interrupt added by the patch is that when the interrupt
occurs, the OHCI irq handler prints a kernel log warning and then sets the
"LinkControl.CycleMaster" bit again resuming the isochronous communication.
Signed-off-by: Jean-Baptiste Mur <jeanbaptiste@maunakeatech.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Semaphore to mutex conversion.
The conversion was generated via scripts, and the result was validated
automatically via a script as well.
Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Ben Collins <bcollins@debian.org>
Cc: Jody McIntyre <scjody@modernduck.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
The workarounds are not required for DViCO Momobay FX-3A and AFAIR not
for Momobay CX-2. These contain an TSB42AA9A but feature the same
firmware_revision value as the older DViCO Momobay CX-1.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
spotted by Adrian Bunk. Also remove some superfluous comments.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
when attempting to find the 'last' part of the dma region continue the
search from where we left off, instead of starting the search over.
Signed-off-by: Jim Westfall <jwestfall@surrealistic.net>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
When working with multiple cameras and intensive applications, our logs
get flooded with video1394 information which isn't of much interest.
Any objections to demoting these messages to debug messages?
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
I added a failure check in patch "sbp2: variable status FIFO address (fix
login timeout)" --- alas for a wrong error value. This is a bug since
Linux 2.6.16. Leads to NULL pointer dereference if the call failed, and
bogus failure handling if call succeeded.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: <stable@kernel.org>
Cc: Ben Collins <bcollins@debian.org>
Cc: Jody McIntyre <scjody@modernduck.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Re-enable posted writes for status FIFO.
Besides bringing back a very minor bandwidth tweak from Linux 2.6.15.x
and older, this also fixes an interoperability regression since 2.6.16:
http://bugzilla.kernel.org/show_bug.cgi?id=6356
(sbp2: scsi_add_device failed. IEEE1394 HD is not working anymore.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Tested-by: Vanei Heidemann <linux@javanei.com.br>
Tested-by: Martin Putzlocher <mputzi@gmx.de> (chip type unconfirmed)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
In case the blacklist with workarounds for device bugs yields a false
positive, the module load parameter can now also be used as an override
instead of an addition to the blacklist.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Apple decided to copy some USB stupidity over to FireWire.
The sector number returned by iPods from read_capacity is one too many.
This may cause I/O errors, especially if the kernel is configured for EFI
partition support. We use the same workaround as usb-storage but have to
check for different model IDs.
http://marc.theaimsgroup.com/?t=114233262300001https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187409
Acknowledgements:
Diagnosis and therapy by Mathieu Chouquet-Stringer <ml2news@free.fr>,
additional data about affected and unaffected Apple hardware from
Vladimir Kotal, Sander De Graaf, Bryan Olmstead and Hugh Dixon.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Grand unification of the three types of workarounds we have so far.
The "skip mode page 8" workaround is now limited to devices which
pretend to be of TYPE_DISK instead of TYPE_RBC. This workaround is no
longer enabled for Initio bridges.
Patch update in anticipation of more workarounds:
- Add module parameter "workarounds".
- Deprecate parameter "force_inquiry_hack".
- Compose the blacklist of a compound type for better readability and
extensibility.
- Remove a now unused #define.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
sbp2util_mark_command_completed takes a lock which was already taken by
sbp2scsi_complete_all_commands. This is a regression in Linux 2.6.15.
Reported by Kristian Harms at
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187394
[ More complete commentary, as response to questions by Andrew: ]
> This changes the call environment for all implementations of
> ->Current_done(). Are they all safe to call under this lock?
Short answer: Yes, trust me. ;-) Long answer:
The done() callbacks are passed on to sbp2 from the SCSI stack along
with each SCSI command via the queuecommand hook. The done() callback
is safe to call in atomic context. So does
Documentation/scsi/scsi_mid_low_api.txt say, and many if not all SCSI
low-level handlers rely on this fact. So whatever this callback does,
it is "self-contained" and it won't conflict with sbp2's internal ORB
list handling. In particular, it won't race with the
sbp2_command_orb_lock.
Moreover, sbp2 already calls the done() handler with
sbp2_command_orb_lock taken in sbp2scsi_complete_all_commands(). I
admit this is ultimately no proof of correctness, especially since this
portion of code introduced the spinlock recursion in the first place and
we didn't realize it since this code's submission before 2.6.15 until
now. (I have learned a lesson from this.)
I stress-tested my patch on x86 uniprocessor with a preemptible SMP
kernel (alas I have no SMP machine yet) and made sure that all code
paths which involve the sbp2_command_orb_lock were gone through multiple
times.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc: (67 commits)
[PATCH] powerpc: Remove oprofile spinlock backtrace code
[PATCH] powerpc: Add oprofile calltrace support to all powerpc cpus
[PATCH] powerpc: Add oprofile calltrace support
[PATCH] for_each_possible_cpu: ppc
[PATCH] for_each_possible_cpu: powerpc
[PATCH] lock PTE before updating it in 440/BookE page fault handler
[PATCH] powerpc: Kill _machine and hard-coded platform numbers
ppc: Fix compile error in arch/ppc/lib/strcase.c
[PATCH] git-powerpc: WARN was a dumb idea
[PATCH] powerpc: a couple of trivial compile warning fixes
powerpc: remove OCP references
powerpc: Make uImage default build output for MPC8540 ADS
powerpc: move math-emu over to arch/powerpc
powerpc: use memparse() for mem= command line parsing
ppc: fix strncasecmp prototype
[PATCH] powerpc: make ISA floppies work again
[PATCH] powerpc: Fix some initcall return values
[PATCH] powerpc: Workaround for pSeries RTAS bug
[PATCH] spufs: fix __init/__exit annotations
[PATCH] powerpc: add hvc backend for rtas
...
This warning happens in practice because the resource length reported by
the chipset is too large. This is not actually a problem, so don't warn
about it. If it happens to be too small, warn about that, but with
a different message so people who are used to ignoring the old message
don't.
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
- move call of scsi_print_command from sbp2_send_command to the beginning of
sbp2_queue_command to show also commands which are not sent
- put sbp2's name into scsi_print_sense
- use __FUNCTION__ in log messages
- remove a few less useful log messages and comments
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
Sbp2 relied on DID_OK to be defined as 0. Always shift DID_OK into the right
position anyway, and explicitly return DID_OK together with CHECK_CONDITION.
Also comment on some #if 0 code. The patch does not change current behaviour.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
No need to hide it from /sys/module/ieee1394/parameters/.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
Sbp2 did not check for successful registration of the lower address range
when CONFIG_IEEE1394_SBP2_PHYS_DMA was set. If hpsb_register_addrspace
failed, a "login timed-out" would occur which is misleading. Now sbp2 logs
a sensible error message.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
Various cleanups of how ohci1394 programs AsynchronousRequestFilter,
PhysicalRequestFilter, and physUpperBoundOffset. In particular, do not
rewrite registers within the bus reset interrupt handler if bus resets
do not affect the registers in the first place.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
Devfs has been disabled in the last kernel releases, so let's
remove it from ieee1394core, raw1394, video1394, dv1394.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Dan Dennedy <dan@dennedy.org>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
When a new SBP-2 unit is added, sbp2 now takes a reference on the 1394
low-level driver (ohci1394 or pcilynx). This prevents the 1394 host driver
module from being unloaded, e.g. by an administrative routine cleanup of
unused kernel modules or when another 1394 driver which depends on ohci1394
is unloaded.
The reference is dropped when the SBP-2 unit was disconnected, when sbp2 is
unloaded or detached from the unit, or when addition of the SBP-2 unit failed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
This removes statically assigned platform numbers and reworks the
powerpc platform probe code to use a better mechanism. With this,
board support files can simply declare a new machine type with a
macro, and implement a probe() function that uses the flattened
device-tree to detect if they apply for a given machine.
We now have a machine_is() macro that replaces the comparisons of
_machine with the various PLATFORM_* constants. This commit also
changes various drivers to use the new macro instead of looking at
_machine.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
By defining generic hweight*() routines
- hweight64() will be defined on all architectures
- hweight_long() will use architecture optimized hweight32() or hweight64()
I found two possible cleanups by these reasons.
Signed-off-by: Akinobu Mita <mita@miraclelinux.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Not for the ioctls so far because I was too lazy.
Cc: bcollins@debian.org
Cc: dan@dennedy.org
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Since about Linux 2.6.14, sbp2's inquiry workaround did not work anymore
due to changes in the SCSI layer. Update it to become effective again.
Testing one of the two known affected bridges has shown that skip_ms_page_8
is required as well.
Also, make force_inquiry_hack tunable via /sys/module/sbp2/parameters.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
(cherry picked from 99496037c6744fd938ffb8ccfc8fc91762322ff8 commit)
Let the ieee1394 core select a suitable 1394 address range for sbp2's
status FIFO instead of using a fixed range. Since the core only selects
addresses which are guaranteed to be out of the "physical range" as per
OHCI 1.1, this patch also fixes an old bug:
OHCI controllers which implement a writeable PhysicalUpperBound register
included sbp2's status FIFO in the physical range. That way sbp2 was
never notified of a succesful login and always failed after timeout.
Affected OHCI host adapters include ALi and Fujitsu controllers.
As another side effect of this patch, the status FIFO is no longer
located in a range for which OHCI chips perform "posted writes". Each
status write now requires a response subaction. But since large data
transfers involve only few status writes, there is no measurable
decrease of I/O throughput. What's more, the status FIFO is now safe
from potential host bus errors. Nevertheless, posted writes could be
re-enabled by extensions to the ARM features of the 1394 stack.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
(cherry picked from b2d38cccad4ef80d6b672b8f89aae5fe2907b113 commit)
If there were commands enqueued but not completed before an SBP-2 unit
was unplugged (or an attempt to reconnect failed), knodemgrd or any
process which tried to remove the device would sleep uninterruptibly
in blk_execute_rq(). Therefore make sure that all commands are
completed when sbp2 retreats.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jody McIntyre <scjody@modernduck.com>
(cherry picked from 61daa34c132c5d4ed8630e2c46e9bf2f0c7b3428 commit)
sbp2.c mangles INQUIRY response in a way that only applies to standard
inquiry data (i.e. when both cmddt and evpd bits are 0). Leave other cases
alone; e.g. when asking for VPD the length of reply is in byte 3, not 4
and byte 4 is the first byte of device serial number.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
These days ioctl32.h is only used for communication of fs/compat.c and
fs/compat_ioctl.c and doesn't contain anything of interest to drivers.
Remove inclusion in various drivers.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We had a report from one loony user who tried out suspend to disk using a
swap partition on a firewire drive. As the firewire thread was put to
sleep it didn't work out too well.
Signed-off-by: Dave Jones <davej@redhat.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Ben Collins <bcollins@debian.org>
Cc: Jody McIntyre <scjody@modernduck.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>