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: NStefan Richter <stefanr@s5r6.in-berlin.de>

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: NStefan 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: NStefan 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: NStefan 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: NStefan Richter <stefanr@s5r6.in-berlin.de>

Refine some depends statements to limit their visibility to the
environments that are actually supported.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

  - s/Device Drivers/Controllers/
  - clarify who needs pcilynx
  - don't recommend Y for raw1394; M is typically used
Signed-off-by: NStefan 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: NStefan 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: NStefan 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: NStefan Richter <stefanr@s5r6.in-berlin.de>

Screenshot from "make menuconfig":
...
  ?????????????????????? IEEE 1394 (FireWire) support ???????????????????????
  ?  Arrow keys navigate the menu.  <Enter> selects submenus --->.          ?
...
  ? ??????????????????????????????????????????????????????????????????????? ?
  ? ?    <M> IEEE 1394 (FireWire) support (JUJU alternative stack, experim? ?
  ? ?    <M>   Support for OHCI firewire host controllers                 ? ?
  ? ?    <M>   Support for storage devices (SBP-2 protocol driver)        ? ?
  ? ?    <M> IEEE 1394 (FireWire) support                                 ? ?
  ? ?    ---   Subsystem Options                                          ? ?
  ? ?    [ ]   Excessive debugging output                                 ? ?
...
  ?                    <Select>    < Exit >    < Help >                     ?
  ???????????????????????????????????????????????????????????????????????????
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This patch contains the scheduled IEEE1394_OUI_DB removal.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Update: Also remove drivers/ieee1394/.gitignore.
Remove now unused struct members in drivers/ieee1394/nodemgr.h.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

This patch contains the scheduled IEEE1394_EXPORT_FULL_API removal.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Update: Pull proper portion of feature-removal-schedule.txt.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

API conversion without change in functionality
Signed-off-by: NStefan 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: NStefan Richter <stefanr@s5r6.in-berlin.de>

This also means that former parts of ieee1394's API will be subject to
change or removal.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Add some pointers to SCSI to the configuration menu item of sbp2.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Also revert patch "frv: ieee1394 is borken on frv", as it no longer is.
Signed-off-by: NStefan 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: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The ieee1394 assumes it may make direct use of ->count in the semaphore
structure.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NDavid 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: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We only support x86 and ppc, due to the use of bus_to_virt() and friends.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NBen Collins <bcollins@ubuntu.com>

It appears I will not get it fixed overnight.
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: NBen 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: NJody 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: NLinus Torvalds <torvalds@osdl.org>

The options CONFIG_IEEE1394_PCILYNX_LOCALRAM and CONFIG_IEEE1394_PCILYNX_PORTS
are not available for some time.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NJody McIntyre <scjody@steamballoon.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus 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!