aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/ieee1394
Commit message (Collapse)AuthorAge
* Merge branch 'for-linus' of ↵Linus Torvalds2009-06-23
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * firewire: new stack is no longer experimentalStefan Richter2009-06-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * firewire: net: add Kconfig item, rename driverStefan Richter2009-06-14
| | | | | | | | | | | | | | 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>
* | Merge branch 'for-linus2' of ↵Linus Torvalds2009-06-16
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * | ieee1394/csr1212: fix false positive kmemcheck reportVegard Nossum2009-06-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ieee1394: annotate bitfieldVegard Nossum2009-06-15
| | | | | | | | | | | | Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
* | | ieee1394: remove driver_data direct access of struct deviceGreg Kroah-Hartman2009-06-16
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | fs: Remove i_cindex from struct inodeTheodore Ts'o2009-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | dma-mapping: replace all DMA_32BIT_MASK macro with DMA_BIT_MASK(32)Yang Hongyang2009-04-07
| | | | | | | | | | | | | | | | 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>
* | Merge branch 'for-linus' of ↵Linus Torvalds2009-03-27
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * ieee1394: constify device ID tablesStefan Richter2009-03-24
| | | | | | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: raw1394: add sparse annotations to raw1394_compat_writeStefan Richter2009-03-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: Storage class should be before const qualifierTobias Klauser2009-03-24
| | | | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: sbp2: follow up on "ieee1394: inherit ud vendor_id from node ↵Stefan Richter2009-03-24
| | | | | | | | | | | | vendor_id" Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | Rationalize fasync return valuesJonathan Corbet2009-03-16
|/ | | | | | | | | | | | | | | | | | | | 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>
* Make ieee1394_init a fs-initcallLinus Torvalds2009-02-26
| | | | | | | | | | | | | | | | | 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>
* ieee1394: remove superfluous assertionsStefan Richter2009-02-24
| | | | | | | | 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>
* ieee1394: inherit ud vendor_id from node vendor_idStefan Richter2009-02-24
| | | | | | | | | | | | | | | | | 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>
* ieee1394: add hpsb_node_read() and hpsb_node_lock()Stefan Richter2009-02-24
| | | | | | | | | | | | 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>
* ieee1394: use correct barrier types between accesses of nodeid and generationStefan Richter2009-02-24
| | | | | | | | | | | | | | 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>
* firesat: copyrights, rename to firedtv, API conversions, fix remote control ↵Stefan Richter2009-02-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'for-linus' of ↵Linus Torvalds2009-02-06
|\ | | | | | | | | | | | | | | 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
| * ieee1394: dv1394: move deprecation message from module init to file openStefan Richter2009-02-06
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'for-linus' of ↵Linus Torvalds2009-01-29
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * ieee1394: sbp2: add workarounds for 2nd and 3rd generation iPodsStefan Richter2009-01-29
| | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: sbp2: don't assume zero model_id or firmware_revision if there is noneStefan Richter2009-01-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: sbp2: fix payload limit at S1600 and S3200Stefan Richter2009-01-28
| | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: sbp2: update a help stringStefan Richter2009-01-28
| | | | | | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: support for speeds greater than S800Stefan Richter2009-01-28
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from Panasonic ↵Stefan Richter2009-01-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | i2c: Delete many unused adapter IDsJean Delvare2009-01-26
|/ | | | Signed-off-by: Jean Delvare <khali@linux-fr.org>
* Merge branch 'master' of ↵David S. Miller2009-01-08
|\ | | | | | | master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
| * ieee1934: dv1394: interrupt enabling/disabling broken on big-endianHarvey Harrison2009-01-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: dv1394: annotate frame input/output structs as little endianHarvey Harrison2009-01-04
| | | | | | | | | | | | | | No Functional changes. Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: eth1394: trivial sparse annotationsHarvey Harrison2009-01-04
| | | | | | | | | | | | | | 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>
| * ieee1394: mark bus_info_data as a __be32 arrayHarvey Harrison2009-01-04
| | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: replace CSR_SET_BUS_INFO_GENERATION macroHarvey Harrison2009-01-04
| | | | | | | | | | Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: pcilynx: trivial endian annotationHarvey Harrison2009-01-04
| | | | | | | | | | | | | | | | 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>
| * ieee1394: ignore nonzero Bus_Info_Block.max_rom, fetch config ROM in quadletsStefan Richter2009-01-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: consolidate uses of IEEE1934_BUSID_MAGICHarvey Harrison2009-01-04
| | | | | | | | | | | | | | 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>
| * ieee1394: ohci1394: flush MMIO writes before delay in initializationStefan Richter2009-01-04
| | | | | | | | | | | | and replace busy-wait by msleep. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: ohci1394: pass error codes from request_irq throughStefan Richter2009-01-04
| | | | | | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: ohci1394: don't leave interrupts enabled during suspend/resumeFrans Pop2009-01-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * ieee1394: mark all hpsb_address_ops instances as constStefan Richter2009-01-04
| | | | | | | | | | | | These are never modified. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
| * ieee1394: replace a GFP_ATOMIC by GFP_KERNEL allocationStefan Richter2009-01-04
| | | | | | | | | | | | All callers of hpsb_register_addrspace() can sleep. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
* | ieee1394: use internal network device statsStephen Hemminger2009-01-06
| | | | | | | | | | | | | | | | 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>
* | ieee1394: remove unneeded last_rxStephen Hemminger2009-01-06
| | | | | | | | | | | | | | | | 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>
* | ieee1394: convert to net_device_opsStephen Hemminger2009-01-06
|/ | | | | | | | 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>
* ieee1394: add quirk fix for Freecom HDDStefan Richter2008-12-13
| | | | | | | | | | 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>
* ieee1394: node manager causes up to ~3.25s delay in freezing tasksNigel Cunningham2008-12-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-20 11:24:28 -0500