xpp: USB_FW rev 10401: minor 6FXS/2FXO caps issue

Fixes an issues with the 6FXS/2FXO module: if an extra FXS or FXO module
is added to a system with such a module, an excessive number of port
licenses was accidentally required (as if the 6FXS/2FXO module required
8FXS/8FXO licenses).

Internal-Issue-ID: #1371
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10534

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10537 a0bf4364-ded3-4de4-8d8a-66a801d63aff
xpp: firmwares to support E-Main 4

USB firmware (USB_FW.201.hex 10402) and FPGA firmware
(FPGA_1161.201.hex 10480) with support of the new E-Main 4 Astribank
mainboard.

(This was accidentally labeled as 'E-Main 3' in some previous commit
messages)

Also includes Makefile fixes from r10536.

Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10535

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10538 a0bf4364-ded3-4de4-8d8a-66a801d63aff
xpp: firmwares: useless 0x1A at EOF

Remove a mostly harmless 0x1A (^Z) at the end of the file. If you
add a NL after it, it breaks the firmware loading.

Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10550

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10553 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi: Add dahdi_pci_disable_link_state for kernel < 2.6.25.

Will allow the ASPM (Active State Power Management) state to be disabled on
PCIe devices before kernel version 2.6.25.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10556

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10564 a0bf4364-ded3-4de4-8d8a-66a801d63aff
wct4xxp: __t4_frame_in and __t4_framer_out slowdowns.

This is a partial revert of r10234 "wct4xxp: __t4_framer_in and
__t4_framer_out speedups."

There were some platform + firmware version combinations that would fail to
properly configure the framer with the aforementioned speedups. The originally
reported sympton was that interrupts would fail to start and while
troubleshooting I also saw cases where one of the spans would stay in alarm
after starting. By adding in additional reads to the version register, the
overall process of writing / reading from the framer control registers is
slowed down which increases reliability.

This change does *not* affect the main path of TDM data which is DMAed
directly into buffers in host memory and are not read / written to / from
framer registers directly.

Reported-and-Tested-by: Vahan Yerkanian <vahan@arminco.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10559

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10565 a0bf4364-ded3-4de4-8d8a-66a801d63aff
wct4xxp: Add compile-time option to disable ASPM for PCIe devices.

Certain BIOSes appear to enable ASPM even though it is not fully supported by
the platform. Also, since the PCIe links for TDM cards are always in use it
does not make sense to allow them to transition to the disabled state.

Just turn off power management on the PCIe links completely. For more
information see http://lwn.net/Articles/449448/.

Internal-Issue-ID: DAHLIN-283
Signed-off-by: Shaun Ruffell <sruffell@digium.com>

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10558

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10566 a0bf4364-ded3-4de4-8d8a-66a801d63aff
wcte12xp, wctdm24xxp: Add compile-time option to disable ASPM for PCIe devices.

Certain BIOSes appear to enable ASPM even though it is not fully supported by
the platform. Also, since the PCIe links for TDM cards are always in use it
does not make sense to allow them to transition to the disabled state.

Just turn off power management on the PCIe links completely. For more
information see http://lwn.net/Articles/449448/.

Internal-Issue-ID: DAHLIN-283
Signed-off-by: Shaun Ruffell <sruffell@digium.com>

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10557

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10567 a0bf4364-ded3-4de4-8d8a-66a801d63aff
A parent-less device should not crash dahdi

* A parent-less device should not crash dahdi:
  - Access span->parent->dev instead of span->parent-dev.parent
    in soem cases.
  - Access span->parent->dev via new inline span_device()
  - Use span_device() in all dahdi_dev_{dbg,info}()

* Allow low-level drivers to set their device name.
  - Drivers that don't use this feature get the default name
    based on the parent device name
  - Parent-less devices which don't set their name, fails
    to register with -EINVAL

Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10449

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10568 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi: Update dev_set_name / dev_name for RHEL 5.6+.

This is needed because dev_name() is mapped to kobject_name() in a backport,
but the kobject name isn't set until after device_add().  The result would be
parentless devices would fail since dahdi would not think a name was set for
these devices.

For these systems, we'll set both the bus_id string and the underlying
kobject_name.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10561

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10569 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi_dynamic_eth: Move tx packet flushing to process context.

The masterspan can be, and often is, called with interrupts disabled but
dev_queue_xmit() needs to be called with interrupts enabled. This potentially
fixes a deadlock.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10562

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10570 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi_dynamic: Since dynamic devices are 'parentless' we must name them.

This in conjunction with r10449 "A parent-less device should not crash dahdi",
this allows dahdi_dynamic spans to work post the dahdi_devices changes in
2.6.0.

The full address of the device is not used since kernels prior to 2.6.31 limit
the length of a devicename to 20 characters.  The full address of the device
can be pulled out of the "hardware_id" and "type" fields of the span.

This patch is just to get things working again. dahdi_dynamic devices *may*
still have issues if the auto_assign_spans module parameter is 0.

Internal-Issue-ID: DAHLIN-280
Reported-by: Pavel Selivanov
Signed-off-by: Shaun Ruffell <sruffell@digium.com>

Origin: http://svnview.digium.com/svn/dahdi?view=rev&rev=10563

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/branches/2.6@10571 a0bf4364-ded3-4de4-8d8a-66a801d63aff