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>
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>
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>
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>
Refine some depends statements to limit their visibility to the
environments that are actually supported.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
- s/Device Drivers/Controllers/
- clarify who needs pcilynx
- don't recommend Y for raw1394; M is typically used
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Until now, ieee1394 put an IP-over-1394 capability entry into each new
host's config ROM. As soon as the controller was initialized --- i.e.
right after modprobe ohci1394 --- this entry triggered a hotplug event
which typically caused auto-loading of eth1394.
This irritated or annoyed many users and distributors. Of course they
could blacklist eth1394, but then ieee1394 wrongly advertized IP-over-
1394 capability to the FireWire bus.
Therefore
- remove the offending kernel config option
IEEE1394_CONFIG_ROM_IP1394,
- let eth1394 add the ROM entry by itself, i.e. only after eth1394 was
loaded.
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=7793 .
To emulate the behaviour of older kernels, simply add the following to
to /etc/modprobe.conf:
install ohci1394 /sbin/modprobe eth1394; \
/sbin/modprobe --ignore-install ohci1394
Note, autoloading of eth1394 when an _external_ IP-over-1394 capable
device is discovered is _not_ affected by this patch.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This considerably reduces the memory requirements for a packet and
eliminates ieee1394's dependency on CONFIG_NET.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Nobody ported ffmpeg from dv1394 to rawiso yet, and there is no
justification to remove dv1394 right now.
Nevertheless, a strong deprecation of this ABI makes a lot of sense,
especially as Kristian H's drivers shape up to be an attractive
alternative to the existing ones. But we don't have a schedule at the
moment.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This patch contains the scheduled IEEE1394_OUI_DB removal.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Update: Also remove drivers/ieee1394/.gitignore.
Remove now unused struct members in drivers/ieee1394/nodemgr.h.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This patch contains the scheduled IEEE1394_EXPORT_FULL_API removal.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Update: Pull proper portion of feature-removal-schedule.txt.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
There is no manpower available to reform oui.db into a library for use
in more kernel subsystems. The low ratio of usefulness to size and the
occasional need to update oui.db from IEEE's official list suggest to
drop oui.db. I plan to make a userspace script available which
translates the remaining numeric sysfs attributes to names of
organizations.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Also revert patch "frv: ieee1394 is borken on frv", as it no longer is.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: David Howells <dhowells@redhat.com>
Cc: Jody McIntyre <scjody@modernduck.com>
Cc: Ben Collins <bcollins@ubuntu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The ieee1394 assumes it may make direct use of ->count in the semaphore
structure.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Ben Collins <bcollins@ubuntu.com>
Cc: Jody McIntyre <scjody@modernduck.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We only support x86 and ppc, due to the use of bus_to_virt() and friends.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
It appears I will not get it fixed overnight.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
Remove the Audio and Music Data Transmission Protocol driver and the
Connection Management Procedures driver. These are incomplete, have never
worked, and are better implemented in userland via raw1394 (see
http://freebob.sourceforge.net/ for example.)
Signed-off-by: Jody McIntyre <scjody@steamballoon.com>
Cc: Adrian Bunk <bunk@stusta.de>
Lots of this patch is trivial code cleanups (static vars were being
intialized to 0, etc).
There's also some fixes for ISO transmits (max buffer handling).
Aswell, we have a few fixes to disable IRM capabilites correctly. We've
also disabled, by default some generally unused EXPORT symbols for the
sake of cleanliness in the kernel. However, instead of removing them
completely, we felt it necessary to have a config option that allowed
them to be enabled for the many projects outside of the main kernel tree
that use our API for driver development.
The primary reason for this patch is to revert a MODE6->MODE10 RBC
conversion patch from the SCSI maintainers. The new conversions handled
directly in the scsi layer do not seem to work for SBP2. This patch
reverts to our old working code so that users can enjoy using Firewire
disks and dvd drives again.
We are working with the SCSI maintainers to resolve this issue outside
of the main kernel tree. We'll merge the patch once the SCSI layer's
handling of the MODE10 conversion is working for us.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The options CONFIG_IEEE1394_PCILYNX_LOCALRAM and CONFIG_IEEE1394_PCILYNX_PORTS
are not available for some time.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Jody McIntyre <scjody@steamballoon.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Stefan Richter