summaryrefslogtreecommitdiffstats
path: root/drivers/ieee1394
AgeCommit message (Collapse)AuthorFilesLines
2009-09-01netdev: convert pseudo-devices to netdev_tx_tStephen Hemminger1-10/+4
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-06Merge branch 'for-linus' of ↵Linus Torvalds2-1/+8
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: ieee1394: sbp2: add support for disks >2 TB (and 16 bytes long CDBs) firewire: sbp2: add support for disks >2 TB (and 16 bytes long CDBs) firewire: core: do not DMA-map stack addresses
2009-07-02ieee1394: sbp2: add support for disks >2 TB (and 16 bytes long CDBs)Stefan Richter2-1/+8
Increase the command ORB data structure to transport up to 16 bytes long CDBs (instead of 12 bytes), and tell the SCSI mid layer about it. This is notably necessary for READ CAPACITY(16) and friends, i.e. support of large disks. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-06-22Merge branch 'for-linus' of ↵Linus Torvalds1-13/+6
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: new stack is no longer experimental firewire: net: better FIFO address range check and rcodes firewire: net: fix card driver reloading firewire: core: fix iso context shutdown on card removal firewire: core: fix DMA unmapping in iso buffer removal firewire: net: adjust net_device ops firewire: net: remove unused code firewire: net: allow for unordered unit discovery firewire: net: style changes firewire: net: add Kconfig item, rename driver firewire: add IPv4 support
2009-06-21firewire: new stack is no longer experimentalStefan Richter1-13/+6
The new stack is now recommended over the old one if used for industrial video (IIDC/DCAM) or for storage devices (SBP-2) due to better performance, improved compatibility, added features, and security. It should also be functionally on par with and is more secure than the old ieee1394 stack in the use case of consumer video devices. IP-over-1394 support for the new stack is currently emerging, and a backend of the firedtv DVB driver to the new stack should be available soon. The one remaining area where the old stack is still required are audio devices, as the new stack is not yet able to support the FFADO FireWire audio framework. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-06-16Merge branch 'for-linus2' of ↵Linus Torvalds2-0/+7
git://git.kernel.org/pub/scm/linux/kernel/git/vegard/kmemcheck * 'for-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/vegard/kmemcheck: (39 commits) signal: fix __send_signal() false positive kmemcheck warning fs: fix do_mount_root() false positive kmemcheck warning fs: introduce __getname_gfp() trace: annotate bitfields in struct ring_buffer_event net: annotate struct sock bitfield c2port: annotate bitfield for kmemcheck net: annotate inet_timewait_sock bitfields ieee1394/csr1212: fix false positive kmemcheck report ieee1394: annotate bitfield net: annotate bitfields in struct inet_sock net: use kmemcheck bitfields API for skbuff kmemcheck: introduce bitfield API kmemcheck: add opcode self-testing at boot x86: unify pte_hidden x86: make _PAGE_HIDDEN conditional kmemcheck: make kconfig accessible for other architectures kmemcheck: enable in the x86 Kconfig kmemcheck: add hooks for the page allocator kmemcheck: add hooks for page- and sg-dma-mappings kmemcheck: don't track page tables ...
2009-06-15ieee1394: remove driver_data direct access of struct deviceGreg Kroah-Hartman2-13/+11
In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Cc: linux1394-devel@lists.sourceforge.net Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Ben Collins <ben.collins@ubuntu.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-06-15ieee1394/csr1212: fix false positive kmemcheck reportVegard Nossum1-0/+2
kmemcheck reports a use of uninitialized memory here, but it's not a real error. The structure in question has just been allocated, and the whole field is initialized, but it happens in two steps. We fix the false positive by inserting a kmemcheck annotation. Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
2009-06-15ieee1394: annotate bitfieldVegard Nossum1-0/+5
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
2009-06-14firewire: net: add Kconfig item, rename driverStefan Richter1-1/+1
The driver is now called firewire-net. It might implement the transport of other networking protocols in the future, notably IPv6 per RFC 3146. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-06-11fs: Remove i_cindex from struct inodeTheodore Ts'o2-3/+8
The only user of the i_cindex element in the inode structure is used is by the firewire drivers. As part of an attempt to slim down the inode structure to save memory --- since a typical Linux system will have hundreds of thousands if not millions of inodes cached, a reduction in the size inode has high leverage. The firewire driver does not need i_cindex in any fast path, so it's simple enough to calculate when it is needed, instead of wasting space in the inode structure. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: krh@redhat.com Cc: stefanr@s5r6.in-berlin.de Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2009-04-07dma-mapping: replace all DMA_32BIT_MASK macro with DMA_BIT_MASK(32)Yang Hongyang1-1/+1
Replace all DMA_32BIT_MASK macro with DMA_BIT_MASK(32) Signed-off-by: Yang Hongyang<yanghy@cn.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-03-27Merge branch 'for-linus' of ↵Linus Torvalds9-22/+25
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: (53 commits) DVB: firedtv: FireDTV S2 problems with tuning solved DVB: firedtv: fix printk format mismatch ieee1394: constify device ID tables ieee1394: raw1394: add sparse annotations to raw1394_compat_write ieee1394: Storage class should be before const qualifier ieee1394: sbp2: follow up on "ieee1394: inherit ud vendor_id from node vendor_id" firewire: core: optimize propagation of BROADCAST_CHANNEL firewire: core: simplify broadcast channel allocation firewire: core: increase bus manager grace period firewire: core: drop unused call parameters of close_transaction firewire: cdev: add closure to async stream ioctl firewire: cdev: simplify FW_CDEV_IOC_SEND_REQUEST return value firewire: cdev: fix race of ioctl_send_request with bus reset firewire: cdev: secure add_descriptor ioctl firewire: cdev: amendment to "add ioctl to query maximum transmission speed" firewire: broadcast channel support firewire: implement asynchronous stream transmission firewire: core: normalize a function argument name firewire: normalize a variable name firewire: core: remove condition which is always false ...
2009-03-24ieee1394: constify device ID tablesStefan Richter7-8/+8
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-03-24ieee1394: raw1394: add sparse annotations to raw1394_compat_writeStefan Richter1-3/+7
Eliminate the following warnings in raw1394_compat_write()'s error return path, seen on x86-64 with CONFIG_COMPAT=y: drivers/ieee1394/raw1394.c:381:17: warning: incorrect type in return expression (different address spaces) drivers/ieee1394/raw1394.c:381:17: expected char const [noderef] <asn:1>* drivers/ieee1394/raw1394.c:381:17: got void * drivers/ieee1394/raw1394.c:2252:14: warning: incorrect type in argument 1 (different address spaces) drivers/ieee1394/raw1394.c:2252:14: expected void const *ptr drivers/ieee1394/raw1394.c:2252:14: got char const [noderef] <asn:1>*[assigned] buffer drivers/ieee1394/raw1394.c:2253:19: warning: incorrect type in argument 1 (different address spaces) drivers/ieee1394/raw1394.c:2253:19: expected void const *ptr drivers/ieee1394/raw1394.c:2253:19: got char const [noderef] <asn:1>*[assigned] buffer Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-03-24ieee1394: Storage class should be before const qualifierTobias Klauser5-9/+9
The C99 specification states in section 6.11.5: The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-03-24ieee1394: sbp2: follow up on "ieee1394: inherit ud vendor_id from node ↵Stefan Richter1-2/+1
vendor_id" Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-03-16Rationalize fasync return valuesJonathan Corbet1-5/+1
Most fasync implementations do something like: return fasync_helper(...); But fasync_helper() will return a positive value at times - a feature used in at least one place. Thus, a number of other drivers do: err = fasync_helper(...); if (err < 0) return err; return 0; In the interests of consistency and more concise code, it makes sense to map positive return values onto zero where ->fasync() is called. Cc: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2009-02-26Make ieee1394_init a fs-initcallLinus Torvalds1-1/+1
It needs to happen before any firewire driver actually registers itself, and that was previously handled by having the Makefile list the core ieee1394 files before the drivers. But now there are firewire drivers in drivers/media, and the Makefile games aren't enough. So just make ieee1394_init happen earlier in the init sequence, the way all other bus layers already do. Reported-and-tested-by: Ingo Molnar <mingo@elte.hu> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Henrik Kurelid <henrik@kurelid.se> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Ben Backx <ben@bbackx.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-02-24ieee1394: remove superfluous assertionsStefan Richter1-6/+0
hpsb_read, hpsb_write, hpsb_lock are sleeping functions which nobody is in danger to use in atomic context. Besides, in_interrupt does not cover all types of atomic context. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-02-24ieee1394: inherit ud vendor_id from node vendor_idStefan Richter1-0/+3
While Module_Vendor_ID in the configuration ROM's root directory is mandatory, there often aren't vendor IDs in unit directories. This affects the new firedtv driver which is meant to be auto-loaded and matched only for vendor-specific devices. We now always copy ne->vendor_id into ud->vendor_id before we scan a unit directory (and fill in a possibly present vendor ID from there). This way, the root directory's vendor ID is used as fallback in the "uevent" environment for modprobe'ing per module alias when a node was plugged in, and in the driver match routine when protocol drivers are bound to unit directories. It will however not be used as sysfs attribute of a unit directory device. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-02-24ieee1394: add hpsb_node_read() and hpsb_node_lock()Stefan Richter1-0/+18
These will be used by the firedtv driver. Like hpsb_node_write() they are much better APIs for high-level drivers than hpsb_write() and its siblings --- easier to use correctly and also terser. Unlike hspb_node_write(), the two new functions will only be used by one call site. Hence make them static inline instead of exported symbols. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-02-24ieee1394: use correct barrier types between accesses of nodeid and generationStefan Richter1-3/+4
A compiler barrier (explicit on the read side, implicit on the write side) is not quite enough for what has to be accomplished here. Use hardware memory barriers on systems which need them. (Of course a full fix of generation handling would require much more than this. The ieee1394 core's bus generation counter had to be tied to the controller's bus generation counter; cf. Kristian's stack. It's just that I have other current business with the code around these barrier()s, so why not do at least this small fix.) Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-02-24firesat: copyrights, rename to firedtv, API conversions, fix remote control ↵Stefan Richter5-0/+34
input Combination of the following changes: Tue, 26 Aug 2008 00:17:30 +0200 (CEST) firedtv: fix remote control input and update the scancode-to-keycode mapping to a current model. Per default, various media key keycodes are emitted which closely match what is printed on the remote. Userland can modify the mapping by means of evdev ioctls. (Not tested.) The old scancode-to-keycode mapping is left in the driver but cannot be modified by ioctls. This preserves status quo for old remotes. Tue, 26 Aug 2008 00:11:28 +0200 (CEST) firedtv: replace tasklet by workqueue job Non-atomic context is a lot nicer to work with. Sun, 24 Aug 2008 23:30:00 +0200 (CEST) firedtv: move some code back to ieee1394 core Partially reverts "ieee1394: remove unused code" of Linux 2.6.25. Sun, 24 Aug 2008 23:29:30 +0200 (CEST) firedtv: replace semaphore by mutex firesat->avc_sem and ->demux_sem have been used exactly like a mutex. The only exception is the schedule_remotecontrol tasklet which did a down_trylock in atomic context. This is not possible with mutex_trylock; however the whole remote control related code is non-functional anyway at the moment. This should be fixed eventually, probably by turning the tasklet into a worqueue job. Convert everything else from semaphore to mutex. Also rewrite a few of the affected functions to unlock the mutex at a single exit point, instead of in several branches. Sun, 24 Aug 2008 23:28:45 +0200 (CEST) firedtv: some header cleanups Unify #ifndef/#define/#endif guards against multiple inclusion. Drop extern keyword from function declarations. Remove #include's into header files where struct declarations suffice. Remove unused ohci1394 interface and related unused ieee1394 interfaces. Add a few missing #include's and remove a few apparently obsolete ones. Sort them alphabetically. Sun, 24 Aug 2008 23:27:45 +0200 (CEST) firedtv: nicer registration message and some initialization fixes Print the correct name in dvb_register_adapter(). While we are at it, replace two switch cascades by one for loop, remove a superfluous member of struct firesat and of two unused arguments of AVCIdentifySubunit(), and fix bogus kfree's in firesat_dvbdev_init(). Tue, 26 Aug 2008 14:24:17 +0200 (CEST) firesat: rename to firedtv Suggested by Andreas Monitzer. Besides DVB-S/-S2 receivers, the driver also supports DVB-C and DVB-T receivers, hence the previous project name is too narrow now. Not yet done: Rename source directory, files, types, variables... Sun, 24 Aug 2008 23:26:23 +0200 (CEST) firesat: add missing copyright notes Reported by Andreas Monitzer and Christian Dolzer. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-02-06Merge branch 'for-linus' of ↵Linus Torvalds1-4/+4
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: ieee1394: dv1394: move deprecation message from module init to file open firewire: core: Remove card from list of cards when enable fails
2009-02-06ieee1394: dv1394: move deprecation message from module init to file openStefan Richter1-4/+4
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>
2009-01-29Merge branch 'for-linus' of ↵Linus Torvalds4-33/+43
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: 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
2009-01-29ieee1394: sbp2: add workarounds for 2nd and 3rd generation iPodsStefan Richter1-0/+10
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>
2009-01-28ieee1394: sbp2: don't assume zero model_id or firmware_revision if there is noneStefan Richter1-18/+20
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>
2009-01-28ieee1394: sbp2: fix payload limit at S1600 and S3200Stefan Richter1-1/+1
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>
2009-01-28ieee1394: sbp2: update a help stringStefan Richter1-2/+2
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-28ieee1394: support for speeds greater than S800Stefan Richter2-11/+9
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>
2009-01-26i2c: Delete many unused adapter IDsJean Delvare1-1/+0
Signed-off-by: Jean Delvare <khali@linux-fr.org>
2009-01-24ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from Panasonic ↵Stefan Richter1-1/+1
camcorders and others 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>
2009-01-08Merge branch 'master' of ↵David S. Miller20-141/+121
master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
2009-01-06ieee1394: use internal network device statsStephen Hemminger2-23/+16
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>
2009-01-06ieee1394: remove unneeded last_rxStephen Hemminger1-2/+0
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>
2009-01-06ieee1394: convert to net_device_opsStephen Hemminger1-6/+10
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>
2009-01-04ieee1934: dv1394: interrupt enabling/disabling broken on big-endianHarvey Harrison1-4/+4
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>
2009-01-04ieee1394: dv1394: annotate frame input/output structs as little endianHarvey Harrison2-24/+24
No Functional changes. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04ieee1394: eth1394: trivial sparse annotationsHarvey Harrison2-21/+21
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>
2009-01-04ieee1394: mark bus_info_data as a __be32 arrayHarvey Harrison3-3/+3
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>
2009-01-04ieee1394: replace CSR_SET_BUS_INFO_GENERATION macroHarvey Harrison2-8/+8
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04ieee1394: pcilynx: trivial endian annotationHarvey Harrison1-1/+1
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>
2009-01-04ieee1394: ignore nonzero Bus_Info_Block.max_rom, fetch config ROM in quadletsStefan Richter3-53/+19
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>
2009-01-04ieee1394: consolidate uses of IEEE1934_BUSID_MAGICHarvey Harrison4-6/+6
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>
2009-01-04ieee1394: ohci1394: flush MMIO writes before delay in initializationStefan Richter1-4/+6
and replace busy-wait by msleep. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04ieee1394: ohci1394: pass error codes from request_irq throughStefan Richter1-5/+7
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-04ieee1394: ohci1394: don't leave interrupts enabled during suspend/resumeFrans Pop1-0/+8
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>
2009-01-04ieee1394: mark all hpsb_address_ops instances as constStefan Richter6-14/+16
These are never modified. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>