| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The drivers
- ohci1394 (controller driver)
- ieee1394 (core)
- dv1394, raw1394, video1394 (userspace ABI)
- eth1394, sbp2 (protocol drivers)
are replaced by
- firewire-ohci (controller driver)
- firewire-core (core and userspace ABI)
- firewire-net, firewire-sbp2 (protocol drivers)
which are more featureful, better performing, and more secure than the older
drivers; all with a smaller and more modern code base.
The driver firedtv in drivers/media/dvb/firewire/ contains backends to both
ieee1394 and firewire-core. Its ieee1394 backend code can be removed in an
independent commit; firedtv as-is builds and works fine without ieee1394.
The driver pcilynx (an incomplete controller driver) is deleted without
replacement since PCILynx cards are extremely rare. Owners of these cards
use them with the stand-alone bus sniffer driver nosy instead.
The drivers nosy and init_ohci1394_dma which do not interact with either of
the two IEEE 1394 stacks are not affected by the ieee1394 subsystem removal.
There are still some issues with the newer firewire subsystem compared to
the older one:
- The rare and quirky controllers ALi M52xx, Apple UniNorth v1, NVIDIA
NForce2 are even less well supported by firewire-ohci than by ohci1394.
I am looking into the M52xx issue.
- The experimental firewire-net is reportedly less stable than its
experimental cousin eth1394.
- Audio playback of a certain group of audio devices (ones based on DICE
chipset with EAP; supported by prerelease FFADO code) does not work yet.
This issue is still under investigation.
- There were some ieee1394 based out-of-the-mainline drivers. Of them,
only lisight, an audio driver for iSight webcams, seems still useful.
Work is underway to reimplement it on top of firewire-core.
All these remainig issues are minor; they should not stand in the way of
overall better user experience of IEEE 1394 on Linux, together with a
reduction in support efforts and maintenance burden. The coexistence of two
IEEE 1394 kernel driver stacks in the mainline since 2.6.22 shall end now,
as announced earlier this year.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
because drivers/ieee1394/ will be deleted.
Additional changes:
- add some #include directives
- adjust to use firewire/ohci.h instead of ieee1394/ohci1394.h,
replace struct ti_ohci by a minimal struct ohci,
replace quadlet_t from ieee1394_types.h by u32
- two or three trivial stylistic changes
- __iomem annotation
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Indent the branch of an if.
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Conflicts:
drivers/firewire/core-card.c
drivers/firewire/core-cdev.c
and forgotten #include <linux/time.h> in drivers/firewire/ohci.c
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
which caused gcc 4.6 to warn about
variable 'XYZ' set but not used.
sbp2.c, unit_characteristics:
The underlying problem which was spotted here --- an incomplete
implementation --- is already 50% fixed in drivers/firewire/sbp2.c which
observes mgt_ORB_timeout but not yet ORB_size.
raw1394.c, length_conflict; dv1394.c, ts_off:
Impossible to tell why these variables are there. We can safely remove
them though because we don't need a compiler warning to realize that we
are dealing with (at least stylistically) flawed code here.
dv1394.c, packet_time:
This was used in debug macro that is only compiled in with
DV1394_DEBUG_LEVEL >= 2 defined at compile-time. Just drop it since
nobody debugs dv1394 anymore. Avoids noise in regular kernel builds.
dv1394.c, ohci; eth1394.c, priv:
These variables clearly can go away. Somebody wanted to use them but
then didn't (or not anymore).
Note, all of this code is considered to be at its end of life and is
thus not really meant to receive janitorial updates anymore. But if we
can easily remove noisy warnings from kernel builds, we should.
Reported-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
...when user data is immediately copied into the allocated region.
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog)
|
|
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: schedule for removal
firewire: core: use separate timeout for each transaction
firewire: core: Fix tlabel exhaustion problem
firewire: core: make transaction label allocation more robust
firewire: core: clean up config ROM related defined constants
ieee1394: mark char device files as not seekable
firewire: cdev: mark char device files as not seekable
firewire: ohci: cleanups and fix for nonstandard build without debug facility
firewire: ohci: wait for PHY register accesses to complete
firewire: ohci: fix up configuration of TI chips
firewire: ohci: enable 1394a enhancements
firewire: ohci: do not clear PHY interrupt status inadvertently
firewire: ohci: add a function for reading PHY registers
Trivial conflicts in Documentation/feature-removal-schedule.txt
|
|
The
- raw1394 (/dev/raw1394),
- video1394 (/dev/video1394/*),
- dv1394 (/dev/dv1394/*)
character device file ABIs do not make any use of lseek(), pread(), or
pwrite(). Therefore use nonseekable_open() and, redundantly, set
file_operations.llseek to no_llseek to remove any doubt whether the BKL-
grabbing default_llseek handler is used.
Although all this is legacy code which should be left in peace until it
is eventually removed (as it is superseded by firewire-core's
<linux/firewire-cdev.h> ABI), this change seems still worth doing to
further minimize the presence of BKL usage in the kernel.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (56 commits)
doc: fix typo in comment explaining rb_tree usage
Remove fs/ntfs/ChangeLog
doc: fix console doc typo
doc: cpuset: Update the cpuset flag file
Fix of spelling in arch/sparc/kernel/leon_kernel.c no longer needed
Remove drivers/parport/ChangeLog
Remove drivers/char/ChangeLog
doc: typo - Table 1-2 should refer to "status", not "statm"
tree-wide: fix typos "ass?o[sc]iac?te" -> "associate" in comments
No need to patch AMD-provided drivers/gpu/drm/radeon/atombios.h
devres/irq: Fix devm_irq_match comment
Remove reference to kthread_create_on_cpu
tree-wide: Assorted spelling fixes
tree-wide: fix 'lenght' typo in comments and code
drm/kms: fix spelling in error message
doc: capitalization and other minor fixes in pnp doc
devres: typo fix s/dev/devm/
Remove redundant trailing semicolons from macros
fix typo "definetly" -> "definitely" in comment
tree-wide: s/widht/width/g typo in comments
...
Fix trivial conflict in Documentation/laptops/00-INDEX
|
|
Conflicts:
Documentation/filesystems/proc.txt
arch/arm/mach-u300/include/mach/debug-macro.S
drivers/net/qlge/qlge_ethtool.c
drivers/net/qlge/qlge_main.c
drivers/net/typhoon.c
|
|
In the future, we are going to be changing the lock type for struct
device (once we get the lockdep infrastructure properly worked out) To
make that changeover easier, and to possibly burry the lock in a
different part of struct device, let's create some functions to lock and
unlock a device so that no out-of-core code needs to be changed in the
future.
This patch creates the device_lock/unlock/trylock() functions, and
converts all in-tree users to them.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Dave Young <hidave.darkstar@gmail.com>
Cc: Ming Lei <tom.leiming@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Len Brown <len.brown@intel.com>
Cc: Magnus Damm <damm@igel.co.jp>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Alex Chiang <achiang@hp.com>
Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Patterson <andrew.patterson@hp.com>
Cc: Yu Zhao <yu.zhao@intel.com>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: CHENG Renquan <rqcheng@smu.edu.sg>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: Frans Pop <elendil@planet.nl>
Cc: David Vrabel <david.vrabel@csr.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
The block layer calling convention is blk_queue_<limit name>.
blk_queue_max_sectors predates this practice, leading to some confusion.
Rename the function to appropriately reflect that its intended use is to
set max_hw_sectors.
Also introduce a temporary wrapper for backwards compability. This can
be removed after the merge window is closed.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Some comments misspell "should" or "shouldn't"; this fixes them. No code changes.
Signed-off-by: Adam Buchbinder <adam.buchbinder@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Update the Kconfig help texts of both stacks to encourage a general move
from the older to the newer drivers. However, do not label ieee1394 as
"Obsolete" yet, as the newer drivers have not been deployed as default
stack in the majority of Linux distributions yet, and those who start
doing so now may still want to install the old drivers as fallback for
unforeseen issues.
Since Linux 2.6.32, FireWire audio devices can be driven by the newer
firewire driver stack too, hence remove an outdated comment about audio
devices. Also remove comments about library versions since the 2nd
generation of libraw1394 and libdc1394 is now in common use; details on
library versions can be read at the wiki link from the help texts.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (42 commits)
tree-wide: fix misspelling of "definition" in comments
reiserfs: fix misspelling of "journaled"
doc: Fix a typo in slub.txt.
inotify: remove superfluous return code check
hdlc: spelling fix in find_pvc() comment
doc: fix regulator docs cut-and-pasteism
mtd: Fix comment in Kconfig
doc: Fix IRQ chip docs
tree-wide: fix assorted typos all over the place
drivers/ata/libata-sff.c: comment spelling fixes
fix typos/grammos in Documentation/edac.txt
sysctl: add missing comments
fs/debugfs/inode.c: fix comment typos
sgivwfb: Make use of ARRAY_SIZE.
sky2: fix sky2_link_down copy/paste comment error
tree-wide: fix typos "couter" -> "counter"
tree-wide: fix typos "offest" -> "offset"
fix kerneldoc for set_irq_msi()
spidev: fix double "of of" in comment
comment typo fix: sybsystem -> subsystem
...
|
|
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: Use hweight32
firewire: cdev: reduce stack usage by ioctl_dispatch
firewire: ohci: 0 may be a valid DMA address
firewire: core: WARN on wrong usage of core transaction functions
firewire: core: optimize Topology Map creation
firewire: core: clarify generate_config_rom usage
firewire: optimize config ROM creation
firewire: cdev: normalize variable names
firewire: normalize style of queue_work wrappers
firewire: cdev: fix memory leak in an error path
|
|
That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Use hweight32 instead of counting for each bit
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (add required include)
|
|
After m68k's task_thread_info() doesn't refer to current,
it's possible to remove sched.h from interrupt.h and not break m68k!
Many thanks to Heiko Carstens for allowing this.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
|
|
* mark struct vm_area_struct::vm_ops as const
* mark vm_ops in AGP code
But leave TTM code alone, something is fishy there with global vm_ops
being used.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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: remove a workaround for Momobay FX-3A
firewire: sbp2: remove a workaround for Momobay FX-3A
firewire: sbp2: fix status reception
firewire: core: fix topology map response handler
firewire: core: fix race with parallel PCI device probe
firewire: core: header file cleanup
firewire: ohci: fix Self ID Count register mask (safeguard against buffer overflow)
ieee1394: raw1394: Do not leak memory on failed trylock.
|
|
The inquiry delay is not necessary anymore in tests on a recent kernel.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Do not leak the allocated memory in case the mutex_trylock() failed
to acquire the lock.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
This bug does not happen in practice: All raw1394 clients use
libraw1394, and accesses to a libraw1394 handle need to be serialized
by the client. This is documented in libraw1394's API reference.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
The generic packet receive code takes care of setting
netdev->last_rx when necessary, for the sake of the
bonding ARP monitor.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Neil Horman <nhorman@txudriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
No need to put ethtool_ops in data, they should be const.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
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
|
|
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>
|
|
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
|
|
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>
|
|
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
...
|
|
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>
|
|
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>
|
|
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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
...
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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>
|
|
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>
|
|
vendor_id"
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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
|
|
as per https://bugs.launchpad.net/bugs/294391. These got one sample of
each iPod generation going. However there still occurred I/O stalls
with the 3rd generation iPod which remain undiagnosed at the time of
this writing.
Acked-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This makes sbp2 behave more like firewire-sbp2 which reports 0xff000000
as immediate value if there are no unit directory entries for model_id
or firmware_revision.
It does not reduce matches with the currently existing quirks table; the
only zero entry there is for a device which actually does have a zero
model_id. It only changes how model_id and firmware_revision are logged
if they are missing.
Other functionally unrelated changes: The model_id member of quirks
list entries is renamed to model; the value (but not the effect) of
SBP2_ROM_VALUE_WILDCARD is changed. Now this part of the source is
identical with firewire-sbp2 for easier maintenance.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
1394-2008 clause 16.3.4.1 (1394b-2002 clause 16.3.1.1) defines tighter
limits than 1394-2008 clause 6.2.2.3 (1394a-2000 clause 6.2.2.3).
Our previously too large limit doesn't matter though if the controller
reports its max_receive correctly.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
The hard-wired configuration of the top speed (until now S800) was
unnecessary, remove it.
If the local link layer controller supports S1600 or S3200, we now
assume this speed for all present 1394b PHYs (except if they are
behind 1394a repeaters) until nodemgr figured out the actual speed
while fetching the config ROM.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Jean Delvare <khali@linux-fr.org>
|
|
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>
|
|
master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
|
|
Use the network_device_stats field in network_device.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Last_rx is now done if needed inside bonding.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Convert to net_device_ops.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
After annotating the frame structs, this was left:
drivers/ieee1394/dv1394.c:2113:23: warning: invalid assignment: |=
drivers/ieee1394/dv1394.c:2113:23: left side has type restricted __le32
drivers/ieee1394/dv1394.c:2113:23: right side has type int
drivers/ieee1394/dv1394.c:2121:24: warning: invalid assignment: &=
drivers/ieee1394/dv1394.c:2121:24: left side has type restricted __le32
drivers/ieee1394/dv1394.c:2121:24: right side has type int
drivers/ieee1394/dv1394.c:2123:24: warning: invalid assignment: |=
drivers/ieee1394/dv1394.c:2123:24: left side has type restricted __le32
drivers/ieee1394/dv1394.c:2123:24: right side has type int
Which looks like a real bug on a big-endian arch as it would set/clear
the wrong bit.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Bill Fink writes:
I finally got a chance to test the patch on my kernel, and live DV
viewing using xine still worked fine. Although I admit to being
mystified how it works both before and after the patch, since the
cpu_to_le32() calls that were added should result in byte swapping on
PPC that wasn't being done before. I guess that either the code paths
involved aren't actually being triggered by my xine DV viewing, or
there's some fortuitous palindromic setting of bits.
Tested-by: Bill Fink <billfink@mindspring.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
No Functional changes.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Mostly annotations of ether_type as a be16.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Two access functions get_max_rom and set_hw_config_rom are
changed to take __be32 as well. Only bus_info_data was
ever passed in so this is OK. All other uses of bus_info_data
treated it as a be32 value already.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
bus_info_block was treated as a be32 everywhere, annotate
as such. Removes plenty of sparse warnings.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
It is already known that buggy firmwares exist which report a bogus
link_spd in their config ROM bus info block. We now got the first
report of a bogus max_rom too (Freecom FireWire Hard Drive 1TB,
http://bugzilla.kernel.org/show_bug.cgi?id=12206).
I suspect other OSs only use quadlet reads to fetch the config ROM,
otherwise the firmware authors would have noticed their mistake.
Hence limit ieee1394's config ROM fetching routine to quadlets as the
safe minimum regardless of what the bus info block says.
This will potentially slow the bus reset handling by nodemgr somewhat
down. But most existing devices support only quadlet reads anyway,
hence there will often be no actual difference to before this change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Move the definition out of nodemgr.h and use it in csr.c/pcilynx.c
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
and replace busy-wait by msleep.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
On my HP 2510p I get the following in dmesg during near the end of most
resumes from suspend to RAM:
irq 19: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Not tainted 2.6.28-rc7 #67
Call Trace:
<IRQ> [<ffffffffa00ee9e1>] ? ohci_irq_handler+0x60/0x7e9 [ohci1394]
[<ffffffff8026aa4d>] __report_bad_irq+0x38/0x87
[<ffffffff8026abaa>] note_interrupt+0x10e/0x174
[<ffffffff8026b262>] handle_fasteoi_irq+0xa7/0xd1
[<ffffffff8020eb87>] do_IRQ+0x73/0xe4
[<ffffffff8020c626>] ret_from_intr+0x0/0xa
<EOI> [<ffffffffa0012606>] ? acpi_idle_enter_bm+0x26b/0x2b2 [processor]
[<ffffffffa00125fc>] ? acpi_idle_enter_bm+0x261/0x2b2 [processor]
[<ffffffff8024f30f>] ? notifier_call_chain+0x33/0x5b
[<ffffffff803b9c64>] ? cpuidle_idle_call+0x8c/0xc4
[<ffffffff8020b312>] ? cpu_idle+0x4a/0x9a
[<ffffffff8042c5c8>] ? rest_init+0x5c/0x5e
handlers:
[<ffffffffa00ee981>] (ohci_irq_handler+0x0/0x7e9 [ohci1394])
Disabling IRQ #19
There also seems to be an interrupt storm during suspend/resume when this
happens:
19: 99968 33 IO-APIC-fasteoi ohci1394
This patch gets rid of both issues and makes the resume as a whole
significantly faster.
Signed-off-by: Frans Pop <elendil@planet.nl>
As was pointed out in http://lkml.org/lkml/2008/12/6/127, this does not
fix the cause of the interrupt storm. However, since the source of the
interrupts could not be determined yet, we make the system at least more
usable with this change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
These are never modified.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
All callers of hpsb_register_addrspace() can sleep.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
According to http://bugzilla.kernel.org/show_bug.cgi?id=12206, Freecom
FireWire Hard Drive 1TB reports max_rom=2 but returns garbage if block
read requests are used to read the config ROM. Force max_rom=0 to limit
them to quadlet read requests.
Reported-by: Christian Mueller <cm1@mumac.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
The firewire nodemanager function "nodemgr_host_thread" contains a loop
that calls try_to_freeze near the top of the loop, but then delays for
up to 3.25 seconds (plus time to do work) before getting back to the top
of the loop. When starting a cycle post-boot, this doesn't seem to bite,
but it is causing a noticeable delay at boot time, when freezing
processes prior to starting to read the image.
The following patch adds invocation of try_to_freeze to the subloops
that are used in the body of this function. With these additions, the
time to freeze when starting to resume at boot time is virtually zero.
I'm no expert on firewire, and so don't know that we shouldn't check
the return value and jump back to the top of the loop or such like after
being frozen, but I submit it for your consideration.
Signed-off-by: Nigel Cunningham <nigel@tuxonice.net>
The delay until nodemgr freezes was up to 0.25s (plus time for node
probes) in Linux 2.6.27 and older and up to 3.25s (plus ~) since Linux
2.6.28-rc1, hence much more noticeable.
try_to_freeze() without any jump is correct. The surrounding code in
the respective loops will catch whether another bus reset happens during
the freeze and handle it.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
An intermediate transition from _RUNNING to _IN_SHUTDOWN could have been
missed by the former code.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
If there is more than one FireWire controller present, dummy_zero_addr
and dummy_max_addr were added multiple times to different lists, thus
corrupting the lists. Fix this by allocating them dynamically per host
instead of just once globally.
(Perhaps a better address space allocation algorithm could rid us of the
two dummy address spaces.)
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=10129 .
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Add another model ID of a broken firmware to prevent early I/O errors
by acesses at the end of the disk. Reported at linux1394-user,
http://marc.info/?t=122670842900002
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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: fix possible deadlock in multithreaded clients
ieee1394: raw1394: fix possible deadlock in multithreaded clients
ieee1394: struct device - replace bus_id with dev_name(), dev_set_name()
firewire: struct device - replace bus_id with dev_name(), dev_set_name()
|
|
As it is, all instances of ->release() for files that have ->fasync()
need to remember to evict file from fasync lists; forgetting that
creates a hole and we actually have a bunch that *does* forget.
So let's keep our lives simple - let __fput() check FASYNC in
file->f_flags and call ->fasync() there if it's been set. And lose that
crap in ->release() instances - leaving it there is still valid, but we
don't have to bother anymore.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Fix a possible though highly unlikely deadlock:
Thread A: Thread B:
- acquire mmap_sem - dv1394_ioctl/read/write()
- dv1394_mmap() - acquire video->mtx
- acquire video->mtx - copy_to/from_user(), possible page fault:
acquire mmap_sem
The simplest fix is to use mutex_trylock() instead of mutex_lock() in
dv1394_mmap(). This changes the behavior under contention in a way
which is visible to userspace clients. However, my guess is that no
clients exist which use mmap vs. ioctl/read/write on the dv1394
character device file interface in concurrent threads.
Reported-by: Johannes Weiner <hannes@saeurebad.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Regression in 2.6.28-rc1: When I added the new state_mutex which
prevents corruption of raw1394's internal state when accessed by
multithreaded client applications, the following possible though
highly unlikely deadlock slipped in:
Thread A: Thread B:
- acquire mmap_sem - raw1394_write() or raw1394_ioctl()
- raw1394_mmap() - acquire state_mutex
- acquire state_mutex - copy_to/from_user(), possible page fault:
acquire mmap_sem
The simplest fix is to use mutex_trylock() instead of mutex_lock() in
raw1394_mmap(). This changes the behavior under contention in a way
which is visible to userspace clients. However, since multithreaded
access was entirely buggy before state_mutex was added and libraw1394's
documentation advised application programmers to use a handle only in a
single thread, this change in behaviour should not be an issue in
practice at all.
Since we have to use mutex_trylock() in raw1394_mmap() regardless
whether /dev/raw1394 was opened with O_NONBLOCK or not, we now use
mutex_trylock() unconditionally everywhere for state_mutex, just to have
consistent behavior.
Reported-by: Johannes Weiner <hannes@saeurebad.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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: Add more documentation to firewire-cdev.h
firewire: fix ioctl() return code
firewire: fix setting tag and sy in iso transmission
firewire: fw-sbp2: fix another small generation access bug
firewire: fw-sbp2: enforce s/g segment size limit
firewire: fw_send_request_sync()
ieee1394: survive a few seconds connection loss
ieee1394: nodemgr clean up class iterators
ieee1394: dv1394, video1394: remove unnecessary expressions
ieee1394: raw1394: make write() thread-safe
ieee1394: raw1394: narrow down the state_mutex protected region
ieee1394: raw1394: replace BKL by local mutex, make ioctl() and mmap() thread-safe
ieee1394: sbp2: enforce s/g segment size limit
ieee1394: sbp2: check for DMA mapping failures
ieee1394: sbp2: stricter dma_sync
ieee1394: Use DIV_ROUND_UP
|
|
Now that device_create() has been audited, rename things back to the
original call to be sane.
Cc: Ben Collins <ben.collins@ubuntu.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
There are situations when nodes vanish from the bus and come back in
quickly thereafter:
- When certain bus-powered hubs are plugged in,
- when certain disk enclosures are switched from self-power to bus
power or vice versa and break the daisy chain during the transition,
- when the user plugs a cable out and quickly plugs it back in, e.g.
to reorder a daisy chain (works on Mac OS X if done quickly enough),
- when certain hubs temporarily malfunction during high bus traffic.
The ieee1394 driver's nodemgr already contained a function to set
vanished nodes aside into "limbo"; i.e. they wouldn't actually be
deleted right away. (In fact, only unloading the driver or writing into
an obscure sysfs attribute would delete them eventually.) If nodes
reappeared later, they would be resurrected out of limbo.
Moving nodes into and out of limbo was accompanied with calling the
.suspend() and .resume() driver methods of the drivers which were bound
to a respective node's unit directories. Not only is this somewhat
strange due to the intended use of these driver methods for power
management, also the sbp2 driver in particular does not implement
.suspend() and .resume(). Hence sbp2 would be disconnected from devices
in situations as listed above.
We now:
- leave drivers bound when nodes go into limbo,
- call the drivers' .update() when nodes come out of limbo,
- automatically delete in-limbo nodes 3 seconds after the last
bus reset and bus rescan.
- Because of the automatic removal, the now obsolete bus attribute
/sys/bus/ieee1394/destroy_node is removed.
This especially lets sbp2 survive brief disconnections. You can for
example yank a disk's cable and plug it back in while reading the
respective disk with dd, but dd will happily continue as if nothing
happened.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Remove useless pointer type casts.
Remove unnecessary hi->host indirection where only host is used.
Remove an unnecessary WARN_ON.
Change a few names.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
init->channel and v.buffer are unsigned and tests for < 0 therefore
always false. gcc knows this and eliminates the code, but anyway...
Reported by Roel Kluin.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Application programs should use a libraw1394 handle only in a single
thread. The raw1394 driver was apparently relying on this, because it
did nothing to protect its fi->state variable from corruption due to
concurrent accesses.
We now serialize the fi->state accesses. This affects the write() path.
We re-use the state_mutex which was introduced to protect fi->iso_state
accesses in the ioctl() path. These paths and accesses are independent
of each other, hence separate mutexes could be used. But I don't see
much benefit in that.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Refactor the ioctl dispatcher in order to move a fraction of it out of
the section which is serialized by fi->state_mutex. This is not so much
about performance but more about self-documentation: The mutex_lock()/
mutex_unlock() calls are now closer to the data accesses which the mutex
protects, i.e. to the iso_state switch.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
thread-safe
This removes the last usage of the Big Kernel Lock from the ieee1394
stack, i.e. from raw1394's (unlocked_)ioctl and compat_ioctl.
The ioctl()s don't need to take the BKL, but they need to be serialized
per struct file *. In particular, accesses to ->iso_state need to be
serial. We simply use a blocking mutex for this purpose because
libraw1394 does not use O_NONBLOCK. In practice, there is no lock
contention anyway because most if not all libraw1394 clients use a
libraw1394 handle only in a single thread.
mmap() also accesses ->iso_state. Until now this was unprotected
against concurrent changes by ioctls. Fix this bug while we are at it.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
1. We don't need to round the SBP-2 segment size limit down to a
multiple of 4 kB (0xffff -> 0xf000). It is only necessary to
ensure quadlet alignment (0xffff -> 0xfffc).
2. Use dma_set_max_seg_size() to tell the DMA mapping infrastructure
and the block IO layer about the restriction. This way we can
remove the size checks and segment splitting in the queuecommand
path.
This assumes that no other code in the ieee1394 stack uses
dma_map_sg() with conflicting requirements. It furthermore assumes
that the controller device's platform actually allows us to set the
segment size to our liking. Assert the latter with a BUG_ON().
3. Also use blk_queue_max_segment_size() to tell the block IO layer
about it. It cannot know it because our scsi_add_host() does not
point to the FireWire controller's device.
We can also uniformly use dma_map_sg() for the single segment case just
like for the multi segment case, to further simplify the code.
Also clean up how the page table is converted to big endian.
Thanks to Grant Grundler and FUJITA Tomonori for advice.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Two dma_sync_single_for_cpu() were called in the wrong place.
Luckily they were merely for DMA_TO_DEVICE, hence nobody noticed.
Also reorder the matching dma_sync_single_for_device() a little bit
so that they reside in the same functions as their counterparts.
This also avoids syncing the s/g table for requests which don't use it.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
sbp2 was too quick to report .update() to the ieee1394 core as failed.
(Logged as "Failed to reconnect to sbp2 device!".) The core would then
unbind sbp2 from the device.
This is not justified if the .update() failed because another bus reset
happened. We check this and tell the ieee1394 that .update() succeeded,
and the core will call sbp2's .update() for the new bus reset as well.
This improves reconnection/re-login especially on buses with several
disks as they may issue bus resets in close succession when they come
online.
Tested by Damien Benoist.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
nodemgr_node_probe checked for generation increments too late and
therefore prematurely reported nodes as "suspended".
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=11349. Reported and
tested by Damien Benoist.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Regression since commit 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 <stefanr@s5r6.in-berlin.de>
|
|
On 32-bit architectures PAGE_ALIGN() truncates 64-bit values to the 32-bit
boundary. For example:
u64 val = PAGE_ALIGN(size);
always returns a value < 4GB even if size is greater than 4GB.
The problem resides in PAGE_MASK definition (from include/asm-x86/page.h for
example):
#define PAGE_SHIFT 12
#define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
#define PAGE_MASK (~(PAGE_SIZE-1))
...
#define PAGE_ALIGN(addr) (((addr)+PAGE_SIZE-1)&PAGE_MASK)
The "~" is performed on a 32-bit value, so everything in "and" with
PAGE_MASK greater than 4GB will be truncated to the 32-bit boundary.
Using the ALIGN() macro seems to be the right way, because it uses
typeof(addr) for the mask.
Also move the PAGE_ALIGN() definitions out of include/asm-*/page.h in
include/linux/mm.h.
See also lkml discussion: http://lkml.org/lkml/2008/6/11/237
[akpm@linux-foundation.org: fix drivers/media/video/uvc/uvc_queue.c]
[akpm@linux-foundation.org: fix v850]
[akpm@linux-foundation.org: fix powerpc]
[akpm@linux-foundation.org: fix arm]
[akpm@linux-foundation.org: fix mips]
[akpm@linux-foundation.org: fix drivers/media/video/pvrusb2/pvrusb2-dvb.c]
[akpm@linux-foundation.org: fix drivers/mtd/maps/uclinux.c]
[akpm@linux-foundation.org: fix powerpc]
Signed-off-by: Andrea Righi <righi.andrea@gmail.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This mirrors the functionality that driver_find_device has as well.
We add a start variable, and all callers of the function are fixed up at
the same time.
The block layer will be using this new functionality in a follow-on
patch.
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This mirrors the functionality that driver_for_each_device has as well.
We add a start variable, and all callers of the function are fixed up at
the same time.
The block layer will be using this new functionality in a follow-on
patch.
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
device_create() is race-prone, so use the race-free
device_create_drvdata() instead as device_create() is going away.
Cc: Ben Collins <ben.collins@ubuntu.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
* 'sbp2-spindown' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
ieee1394: sbp2: spin disks down on suspend and shutdown
firewire: fw-sbp2: spin disks down on suspend and shutdown
ieee1394: sbp2: fix spindown for PL-3507 and TSB42AA9 firmwares
firewire: fw-sbp2: fix spindown for PL-3507 and TSB42AA9 firmwares
scsi: sd: optionally set power condition in START STOP UNIT
|
|
Currently, core files do not contain the mmapped memory of the video1394
or dv1394 devices, which contain the actual video input, making it
impossible to analyse the cause of abnormal program termination for
image analysis or (de)compression software. Fix that.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Also affects users of the rawiso ioctl API of raw1394.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Actually in this case wrap the function for now.
Signed-off-by: Alan Cox <alan@redhat.com>
Added raw1394_compat_ioctl hunk.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This prepares video1394 for removal of the BKL (big kernel lock):
It allows video1394_open() to be called while video1394_init_module()
is still in progress.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This avoids redundant messages about a special and usually harmless
firmware flaw.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This instructs sd_mod to send START STOP UNIT on suspend and resume,
and on driver unbinding or unloading (including when the system is shut
down).
We don't do this though if multiple initiators may log in to the target.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Reported by Tino Keitel: PL-3507 with firmware from Prolific does not
spin down the disk on START STOP UNIT with power condition = 0 and start
= 0. It does however work with power condition = 2 or 3.
Also found while investigating this: DViCO Momobay CX-1 and FX-3A (TI
TSB42AA9/A based) become unresponsive after START STOP UNIT with power
condition = 0 and start = 0. They stay responsive if power condition is
set when stopping the motor.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Rename and reorder some prompts and modify some help texts.
The result:
-------------------- IEEE 1394 (FireWire) support --------------------
*** Enable only one of the two stacks, unless you know what you are doing ***
New FireWire stack, EXPERIMENTAL
OHCI-1394 controllers
Storage devices (SBP-2 protocol)
Stable FireWire stack
OHCI-1394 controllers
PCILynx controller
Storage devices (SBP-2 protocol)
Enable replacement for physical DMA in SBP2
IP over 1394
raw1394 userspace interface
video1394 userspace interface
dv1394 userspace interface (deprecated)
Excessive debugging output
The old prompts for reference:
-------------------- IEEE 1394 (FireWire) support --------------------
IEEE 1394 (FireWire) support - alternative stack, EXPERIMENTAL
Support for OHCI FireWire host controllers
Support for storage devices (SBP-2 protocol driver)
IEEE 1394 (FireWire) support
*** Subsystem Options ***
Excessive debugging output
*** Controllers ***
Texas Instruments PCILynx support
OHCI-1394 support
*** Protocols ***
OHCI-1394 Video support
SBP-2 support (Harddisks etc.)
Enable replacement for physical DMA in SBP2
IP over 1394
OHCI-DV I/O support (deprecated)
Raw IEEE1394 I/O support
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Boaz Harrosh wrote:
> cmd->cmd_len is now guarantied to be set properly at all cases.
> And some commands you want to support will not be set correctly
> by COMMAND_SIZE().
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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: fw-sbp2: log scsi_target ID at release
ieee1394: fix NULL pointer dereference in sysfs access
|
|
Regression since "ieee1394: prevent device binding of raw1394,
video1394, dv1394", commit d2ace29fa44589da51fedc06a67b3f05301f3bfd:
$ cat /sys/bus/ieee1394/drivers/raw1394/device_ids
triggers a NULL pointer dereference in fw_show_drv_device_ids.
Reported by Miles Lane.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Tested-by: Miles Lane <miles.lane@gmail.com>
|
|
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: silence defined but not used warning in non-modular builds
ieee1394: rawiso: requeue packet for transmission after skipped cycle
|
|
Currently the kernel will issue the following warning:
drivers/ieee1394/raw1394.c:2938: warning: 'raw1394_id_table' defined but not used
Add #ifdef MODULE guards around the declaration.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
Ditto with dv1394_id_table and video1394_id_table.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
As it seems, some host controllers have issues that can cause them to
skip cycles now and then when using large packets. I suspect that this
is due to DMA not succeeding in time. If the transmit fifo can't contain
more than one packet (big packets), the DMA should provide a new packet
each cycle (125us). I am under the impression that my current PCI
express test system can't guarantee this.
In any case, the patch tries to provide a workaround as follows:
The DMA program descriptors are modified such that when an error occurs,
the DMA engine retries the descriptor the next cycle instead of
stalling. This way no data is lost. The side effect of this is that
packets are sent with one cycle delay. This however might not be that
much of a problem for certain protocols (e.g. AM824). If they use
padding packets for e.g. rate matching they can drop one of those to
resync the streams.
The amount of skips between two userspace wakeups is counted. This
number is then propagated to userspace through the upper 16 bits of the
'dropped' parameter. This allows unmodified userspace applications due
to the following:
1) libraw simply passes this dropped parameter to the user application
2) the meaning of the dropped parameter is: if it's nonzero, something
bad has happened. The actual value of the parameter at this moment does
not have a specific meaning.
A libraw client can then retrieve the number of skipped cycles and
account for them if needed.
Signed-off-by: Pieter Palmers <pieterp@joow.be>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
|
|
The following patch limits the node speed to the host interface speed,
before using it.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
It should actually suffice to do this only for the local node's
speedcap[]. But there is another bug in the speed calculation:
The local node's speed is not correctly propagated to the speeds
which are to be used to access remote nodes.
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/11772/focus=12024
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Unless you're adding a kobject to the sysfs hierarchy, there is no
point setting its kobject name.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
The failure path of ohci1394_pci_probe() reuses ohci1394_pci_remove().
Doing so it missed to call ohci1394_pmac_off() in a few unlikely early
error cases.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
to reduce the size of ohci1394.ko.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
We don't want to hide something like return in a preprocessor macro.
Unroll the macro and use a goto, which also reduces the size of
ohci1394.ko.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Clean up shared code and variable names.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
The platform feature calls in the suspend method switched off cable
power, but the calls in the resume method did not switch it back on.
Add the necessary feature call to .resume. Also add the corresponding
call to .suspend to make .suspend's behavior explicitly the same on all
PMacs.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
These drivers don't need to match any unit_directory type device.
They just need the id_table for module autoloading per module alias.
Not binding any of these drivers allows special-purpose drivers with
similar or same IDs to bind to devices. This currently only benefits
out-of-tree drivers; on the other hand it is in no way detrimental to
in-tree drivers.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
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 patch
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Fix I/O errors due to SYM13FW500's inability to handle larger request
sizes. Reported by Piergiorgio Sartor <piergiorgio.sartor@nexgo.de> for
firewire-sbp2 in https://bugzilla.redhat.com/show_bug.cgi?id=436879
This fix is necessary because sbp2's default request size limit has been
lifted since 2.6.25-rc1.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
|
|
rescan-scsi-bus used to add SBP-2 targets which weren't there.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Add the same workaround as found in fw-sbp2 for feature parity and
compatibility of the workarounds module parameter.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
|
|
sg_dma_len(sg) is invalid before the s/g list is DMA-mapped.
This fixes a post 2.6.24 regression which prevents access to SBP-2
devices on several architectures, introduced by "ieee1394: sbp2: s/g
list access cosmetics", commit 825f1df545ab0289185373b0eaf06fb0b3487422.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Bug noted by Pieter Palmers: Isochronous transmit tasklets were
scheduled on isochronous receive events, in addition to the proper
isochronous receive tasklets.
http://marc.info/?l=linux1394-devel&m=119783196222802
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This patch speeds up sbp2 a little bit --- but more importantly, it
brings the behavior of sbp2 and fw-sbp2 closer to each other. Like
fw-sbp2, sbp2 now does not limit the size of single transfers to 255
sectors anymore, unless told so by a blacklist flag or by module load
parameters.
Only very old bridge chips have been known to need the 255 sectors
limit, and we have got one such chip in our hardwired blacklist. There
certainly is a danger that more bridges need that limit; but I prefer to
have this issue present in both fw-sbp2 and sbp2 rather than just one of
them.
An OXUF922 with 400GB 7200RPM disk on an S400 controller is sped up by
this patch from 22.9 to 23.5 MB/s according to hdparm. The same effect
could be achieved before by setting a higher max_sectors module
parameter. On buses which use 1394b beta mode, sbp2 and fw-sbp2 will
now achieve virtually the same bandwidth. Fw-sbp2 only remains faster
on 1394a buses due to fw-core's gap count optimization.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
The code has been in "#if 0 - #endif" since Linux 2.6.12.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Convert ieee1394 from nopage to fault.
Remove redundant vma range checks (correct resource range check is retained).
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Replace sg->length by sg_dma_len(sg). Rename a variable for shorter
line lengths and eliminate some superfluous local variables.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This patch adds a new configuration option, which adds support for a new
early_param which gets checked in arch/x86/kernel/setup_{32,64}.c:setup_arch()
to decide wether OHCI-1394 FireWire controllers should be initialized and
enabled for physical DMA access to allow remote debugging of early problems
like issues ACPI or other subsystems which are executed very early.
If the config option is not enabled, no code is changed, and if the boot
paramenter is not given, no new code is executed, and independent of that,
all new code is freed after boot, so the config option can be even enabled
in standard, non-debug kernels.
With specialized tools, it is then possible to get debugging information
from machines which have no serial ports (notebooks) such as the printk
buffer contents, or any data which can be referenced from global pointers,
if it is stored below the 4GB limit and even memory dumps of of the physical
RAM region below the 4GB limit can be taken without any cooperation from the
CPU of the host, so the machine can be crashed early, it does not matter.
In the extreme, even kernel debuggers can be accessed in this way. I wrote
a small kgdb module and an accompanying gdb stub for FireWire which allows
to gdb to talk to kgdb using remote remory reads and writes over FireWire.
An version of the gdb stub fore FireWire is able to read all global data
from a system which is running a a normal kernel without any kernel debugger,
without any interruption or support of the system's CPU. That way, e.g. the
task struct and so on can be read and even manipulated when the physical DMA
access is granted.
A HOWTO is included in this patch, in Documentation/debugging-via-ohci1394.txt
and I've put a copy online at
ftp://ftp.suse.de/private/bk/firewire/docs/debugging-via-ohci1394.txt
It also has links to all the tools which are available to make use of it
another copy of it is online at:
ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diff
Signed-Off-By: Bernhard Kaindl <bk@suse.de>
Tested-By: Thomas Renninger <trenn@suse.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (200 commits)
[SCSI] usbstorage: use last_sector_bug flag universally
[SCSI] libsas: abstract STP task status into a function
[SCSI] ultrastor: clean up inline asm warnings
[SCSI] aic7xxx: fix firmware build
[SCSI] aacraid: fib context lock for management ioctls
[SCSI] ch: remove forward declarations
[SCSI] ch: fix device minor number management bug
[SCSI] ch: handle class_device_create failure properly
[SCSI] NCR5380: fix section mismatch
[SCSI] sg: fix /proc/scsi/sg/devices when no SCSI devices
[SCSI] IB/iSER: add logical unit reset support
[SCSI] don't use __GFP_DMA for sense buffers if not required
[SCSI] use dynamically allocated sense buffer
[SCSI] scsi.h: add macro for enclosure bit of inquiry data
[SCSI] sd: add fix for devices with last sector access problems
[SCSI] fix pcmcia compile problem
[SCSI] aacraid: add Voodoo Lite class of cards.
[SCSI] aacraid: add new driver features flags
[SCSI] qla2xxx: Update version number to 8.02.00-k7.
[SCSI] qla2xxx: Issue correct MBC_INITIALIZE_FIRMWARE command.
...
|
|
Convert to use the class iteration api.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This patch relaxes the default SCSI DMA alignment from 512 bytes to 4
bytes. I remember from previous discussions that usb and firewire have
sector size alignment requirements, so I upped their alignments in the
respective slave allocs.
The reason for doing this is so that we don't get such a huge amount of
copy overhead in bio_copy_user() for udev. (basically all inquiries it
issues can now be directly mapped).
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
|
|
Torsten Kaiser wrote:
> Looking that calltrace upwards, it seems replacing the
> memset(dma->sglist,...) with sg_init_table(...) would fix the BUG_ON()
> as that inits the SG_MAGIC.
Tested-by: Torsten Kaiser <just.for.lkml@googlemail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Not architecture specific code should not #include <asm/scatterlist.h>.
This patch therefore either replaces them with
#include <linux/scatterlist.h> or simply removes them if they were
unused.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
This patch removes dead code spotted by the Intel C Compiler.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Most drivers need to set length and offset as well, so may as well fold
those three lines into one.
Add sg_assign_page() for those two locations that only needed to set
the page, where the offset/length is set outside of the function context.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Commits
58b053e4ce9d2fc3023645c1b96e537c72aa8d9a ("Update arch/ to use sg helpers")
45711f1af6eff1a6d010703b4862e0d2b9afd056 ("[SG] Update drivers to use sg helpers")
fa05f1286be25a8ce915c5dd492aea61126b3f33 ("Update net/ to use sg helpers")
converted many files to use the scatter gather helpers without ensuring
that the necessary headerfile <linux/scatterlist> is included. This
happened to work for ia64, powerpc, sparc64 and x86 because they
happened to drag in that file via their <asm/dma-mapping.h>.
On most of the others this probably broke.
Instead of increasing the header file spider web I choose to include
<linux/scatterlist.h> directly into the affectes files.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
drivers/ieee1394/ieee1394_core.c: Define spinlock using
DEFINE_SPINLOCK instead of assignment to SPIN_LOCK_UNLOCKED
Signed-off-by: Matthias Kaehlcke <matthias.kaehlcke@gmail.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
At least since nodemgr got rid of coarse global locking, accesses to
struct csr1212_keyval's reference counter should be atomic and coupled
with proper barriers. Also, calls to csr1212_keep_keyval(kv) should
occur before kv is being used.
(We probably should convert refcnt to struct kref, but how to keep
csr1212_destroy_keyval's implementation non-recursively then?)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
csr1212_keep_keyval(kv) in nodemgr_process_root_directory was
unbalanced if ne->vendor_name_kv already exists. This happens for
example if eth1394 or raw1394 modify the local config ROM and it is
parsed again.
As a bonus, the attempt to add the vendor_name_kv sysfs attribute
when it already exists is now fixed for good.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
* Delete optional and empty i2c client_register and client_unregister
callbacks.
* Use the proper i2c adapter ID.
* Don't use a template to initialize the i2c_adapter structure, it's
inefficient.
* Update a misleading comment on why we use i2c_transfer rather than
higher level i2c functions.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
The nodemgr host thread can exit on its own even when kthread_should_stop
is not true, on receiving a signal (might never happen in practice, as
it ignores signals). But considering kthread_stop() must not be mixed with
kthreads that can exit on their own, I think changing the code like this
is clearer. This change means the thread can cut its sleep short when
receive a signal but looking at the code around, that sounds okay (and
again, it might never actually recieve a signal in practice).
Signed-off-by: Satyam Sharma <satyam@infradead.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
sbp2_host_reset and sbp2_handle_status_write are not serialized against
sbp2_alloc_device and sbp2_remove_device.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
bad_proto can be reached from points which did not take priv->lock.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This changes the uevent buffer functions to use a struct instead of a
long list of parameters. It does no longer require the caller to do the
proper buffer termination and size accounting, which is currently wrong
in some places. It fixes a known bug where parts of the uevent
environment are overwritten because of wrong index calculations.
Many thanks to Mathieu Desnoyers for finding bugs and improving the
error handling.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Since hardware header operations are part of the protocol class
not the device instance, make them into a separate object and
save memory.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Wrap the hard_header_parse function to simplify next step of
header_ops conversion.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
It's been a useless no-op for long enough in 2.6 so I figured it's time to
remove it. The number of people that could object because they're
maintaining unified 2.4 and 2.6 drivers is probably rather small.
[ Handled drivers added by netdev tree and some missed IRDA cases... -DaveM ]
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Initialization of ohci1394 was broken according to one reporter if the
driver was statically linked, i.e. not built as loadable module. Dmesg:
PCI: Device 0000:02:07.0 not available because of resource collisions
ohci1394: Failed to enable OHCI hardware.
This was reported for a Toshiba Satellite 5100-503. The cause is commit
8df4083c5291b3647e0381d3c69ab2196f5dd3b7 in Linux 2.6.19-rc1 which only
served purposes of early remote debugging via FireWire. This
functionality is better provided by the currently out-of-tree driver
ohci1394_earlyinit. Reversal of the commit was OK'd by Andi Kleen.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Bug found by Olaf Hering <olh@suse.de>:
sbp2util_remove_command_orb_pool requires a valid lu->hi pointer.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Make the option SBP2_PHYS_DMA available on all architectures where it
compiles. This includes x86-64 where I runtime-tested it successfully.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Revert commit 0555659d63c285ceb7ead3115532e1b71b0f27a7 from 2.6.22-rc1.
The dma_set_mask call somehow failed on a PowerMac G5, PPC64:
http://lkml.org/lkml/2007/8/1/344
Should there ever occur a DMA mapping beyond the physical DMA range, a
proper SBP-2 firmware will report transport errors. So let's leave it
at that.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Tested-by: Olaf Hering <olh@suse.de>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Slab destructors were no longer supported after Christoph's
c59def9f222d44bb7e2f0a559f2906191a0862d7 change. They've been
BUGs for both slab and slub, and slob never supported them
either.
This rips out support for the dtor pointer from kmem_cache_create()
completely and fixes up every single callsite in the kernel (there were
about 224, not including the slab allocator definitions themselves,
or the documentation references).
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
|
|
Currently, the freezer treats all tasks as freezable, except for the kernel
threads that explicitly set the PF_NOFREEZE flag for themselves. This
approach is problematic, since it requires every kernel thread to either
set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
care for the freezing of tasks at all.
It seems better to only require the kernel threads that want to or need to
be frozen to use some freezer-related code and to remove any
freezer-related code from the other (nonfreezable) kernel threads, which is
done in this patch.
The patch causes all kernel threads to be nonfreezable by default (ie. to
have PF_NOFREEZE set by default) and introduces the set_freezable()
function that should be called by the freezable kernel threads in order to
unset PF_NOFREEZE. It also makes all of the currently freezable kernel
threads call set_freezable(), so it shouldn't cause any (intentional)
change of behaviour to appear. Additionally, it updates documentation to
describe the freezing of tasks more accurately.
[akpm@linux-foundation.org: build fixes]
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Nigel Cunningham <nigel@nigel.suspend2.net>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Gautham R Shenoy <ego@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
* master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (166 commits)
[SCSI] ibmvscsi: convert to use the data buffer accessors
[SCSI] dc395x: convert to use the data buffer accessors
[SCSI] ncr53c8xx: convert to use the data buffer accessors
[SCSI] sym53c8xx: convert to use the data buffer accessors
[SCSI] ppa: coding police and printk levels
[SCSI] aic7xxx_old: remove redundant GFP_ATOMIC from kmalloc
[SCSI] i2o: remove redundant GFP_ATOMIC from kmalloc from device.c
[SCSI] remove the dead CYBERSTORMIII_SCSI option
[SCSI] don't build scsi_dma_{map,unmap} for !HAS_DMA
[SCSI] Clean up scsi_add_lun a bit
[SCSI] 53c700: Remove printk, which triggers because of low scsi clock on SNI RMs
[SCSI] sni_53c710: Cleanup
[SCSI] qla4xxx: Fix underrun/overrun conditions
[SCSI] megaraid_mbox: use mutex instead of semaphore
[SCSI] aacraid: add 51245, 51645 and 52245 adapters to documentation.
[SCSI] qla2xxx: update version to 8.02.00-k1.
[SCSI] qla2xxx: add support for NPIV
[SCSI] stex: use resid for xfer len information
[SCSI] Add Brownie 1200U3P to blacklist
[SCSI] scsi.c: convert to use the data buffer accessors
...
|
|
Going through the string and waiting for _pointer_ to become '\0'
is not what the authors meant...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Ben Collins <ben.collins@ubuntu.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Based on patch "the scheduled removal of RAW1394_REQ_ISO_{SEND,LISTEN}"
from Adrian Bunk, November 20 2006.
This patch also removes the underlying facilities in ohci1394 and
disables them in pcilynx. That is, hpsb_host_driver.devctl() and
hpsb_host_driver.transmit_packet() are no longer used for iso reception
and transmission.
Since video1394 and dv1394 only work with ohci1394 and raw1394's rawiso
interface has never been implemented in pcilynx, pcilynx is now no
longer useful for isochronous applications.
raw1394 will still handle the request types but will complete the
requests with errors that indicate API version conflicts.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This is upwards compatible, except that integer values other than 0 or 1
are no longer accepted. But values like "Y", "N", "no", "nnoooh!" work
now.
Also, improve a comment on the serialize_io parameter and make the
ORB_SET_EXCLUSIVE macro ultra-safe.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Association of a host device with a node on NUMA machines optimizes
allocations of skbs given from the networking stack to eth1394.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
After ieee1394 was converted away from class_device like the networking
subsystem was already in 2.6.21, eth1394's device may point to the
fw-host device as its parent again like in 2.6.20.
This affects userspace tools which examine the sysfs representation of
eth1394's device.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Remove the global nodemgr_serialize mutex which enclosed most of the
host thread event loop. This allows for parallelism between several
host adapter cards.
Properly serialize the driver hooks .update(), .suspend(), .resume(),
and .remove() by means of device->sem. These hooks can be called from
outside the host threads' contexts.
Get() and put() the device.driver when calling its hooks.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Here is a straightforward conversion to "struct device". The "struct
class_device" will be removed from the kernel.
It seems to work fine for me with and without CONFIG_SYSFS_DEPRECATED
set.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
I was told that only i386 aligns 64 bit integers at 4 bytes boundaries
while all other architectures (32 bit architectures with 64 bit
siblings) align it on 8 bytes boundaries.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Pointed out by Arnd Bergmann: PPC32 aligns this at 64bit, IA32 packs
it. A kernel-wide available __compat_u64 which is 4-byte aligned on
AMD64 and IA64 would be nicer though.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Add compat_ioctl. Although all structures are more or less same,
raw1394_iso_packets got pointer inside, and raw1394_cycle_timer got unwanted
padding in the middle. I did not add any translation for ioctls passing array
of integers around as integers seem to have same size (32 bits) on all
architectures supported by Linux.
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Acked-by: Dan Dennedy <dan@dennedy.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (split into 3 patches)
|
|
* write(fd, buf, 52) from 32bit app was returning 56. Most of callers did not
care, but some (arm registration) did, and anyway it looks bad if request for
writing 52 bytes returns 56. And returning sizeof anything in 'int' is not
good as well. So all functions now return '0' instead of
sizeof(struct raw1394_request) on success, and write() itself provides correct
return value (it just returns value it was asked to write on success as raw1394
does not do any partial writes at all).
* Related to this was problem that write() could have returned 0 when kernel
state would become corrupted and moved to different state than
opened/initialized/connected. Now it returns -EBADFD which seemed appropriate.
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Acked-by: Dan Dennedy <dan@dennedy.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (split into 3 patches)
|
|
read() always failed with -EFAULT. This was happening due to
raw1394_compat_read copying data to wrong location - access_ok always
failed as 'r' is kernel address, not user. Whole function just tried to
copy data from 'r' to 'r', which is not good.
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Acked-by: Dan Dennedy <dan@dennedy.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (split into 3 patches)
|
|
to clarify who is supposed to set what
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
spotted by Robert P. J. Day <rpjday@mindspring.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This patch fixes a problem that occurs when packets cannot be sent across
the ieee1394 bus and we return NETDEV_TX_BUSY in the net driver "hard start
xmit" routine ether1394_tx. When we return NETDEV_TX_BUSY the stack will
call ether1394_tx again with the same skb. So we need to restore the header
to look like it did before we munged it for xmit over ieee1394.
[Stefan Richter: changed whitespace, deleted a local variable]
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
With "modprobe sbp2 long_ieee1394_id=y", the format of
/sys/bus/scsi/devices/*:*:*:*/ieee1394_id is changed from e.g.
0001041010004beb:0:0 to 0001041010004beb:00042c:0000.
The longer format fully conforms to object identifier sizes as per
SAM(-2...4) and reflects what the SAM target port identifier is meant to
contain: A Discovery ID allegedly specified by ISO/IEC 13213:1994 ---
however there is no such thing; the authors of SAM probably meant
Directory ID). Especially target nodes with multiple dynamically added
targets may use Directory IDs to persistently identify target ports.
The new format is independent of implementation details of nodemgr.
Thus the same ieee1394_id attribute format can be implemented in the new
firewire stack.
The ieee1394_id is typically used to create persistently named links in
/dev/disk/by-id.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
struct csr1212_keyval.offset is relative to 0xffff f000 0000 rather than
0xffff f000 0400.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Conflicts:
drivers/scsi/jazz_esp.c
Same changes made by both SCSI and SPARC trees: problem with UTF-8
conversion in the copyright.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
While playing with libiec61883 I've noticed that async_send is broken
because it was doing copy_from_user(...., packet->data_size) before
packet->data_size was set to any useful value. It got broken when
packet->allocated_data_size got introduced, as hpsb_alloc_packet does
not set packet->data_size anymore. (Regression in 2.6.22-rc1)
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This adds a real parent device to eth1394's ethX device like in Linux
2.6.20 and older. However, due to unfinished conversion of the ieee1394
away from class_device, we now refer to the FireWire controller's PCI
device as the parent, not to the ieee1394 driver's fw-host device.
Having a real parent device instead of a virtual one allows udev scripts
to distinguish eth1394 interfaces from networking bridges, bondings and
the likes.
Fixes a regression since 2.6.21:
https://bugs.gentoo.org/show_bug.cgi?id=177199
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
When eth1394 was unable to acquire a transaction label, it just dropped
outgoing packets without attempt to resend them later.
The transmit queue is now halted if no tlabel is available to
->hard_start_xmit(). A workqueue job is then scheduled to catch the
moment when ieee1394 recycled the next lot of tlabels.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=8402
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
When we are within hard_start_xmit, the queue is already awake.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
