Skip to content
Commit 284a83a0 authored by David S. Miller's avatar David S. Miller
Browse files

Merge branch 'defxx-next'



Maciej W. Rozycki says:

====================
defxx: Fixes for 64-bit host support

 This mini patch series addresses issues with 64-bit host support for FDDI
interface boards supported by the defxx driver where DMA mapping
synchronisation is required on swiotlb systems.  While PDQ, the DMA engine
chip used with these boards, supports 48-bit addressing that would
normally suffice for typical 64-bit systems in existence, the host bus
interface chips used by individual implementations have their limitations
as follows:

* DEFTA or DEC FDDIcontroller/TURBOchannel -- there's no host bus
  interface chip, the PDQ connects to TURBOchannel directly; TURBOchannel
  supports DMA addressing of up to 16GB (34-bit addressing), however no
  TURBOchannel system has ever been made that supports more than 1GB of
  RAM, so in reality no remapping is ever required,

* DEFEA or DEC FDDIcontroller/EISA -- the ESIC EISA interface chip only
  supports 32-bit addressing, all accesses beyond 4GB have to be remapped,

* DEFPA or DEC FDDIcontroller/PCI -- the PFI PCI interface chip rev. 1 & 2
  only support 32-bit addressing, they have 32 AD lines only both on the
  PDQ and the PCI side, and consequently no Dual Address Cycle support, so
  all accesses beyond 4GB have to be remapped; the range of addressing
  supported by PFI rev. 3 is currently not certain, however the chip is
  backwards compatible with earlier revisions and will work with code that
  supports them.

Some other issues discovered in the course of correcting 64-bit support
have been fixed as well.  Each of the patches is functionally
self-contained and can be applied independentely, although there may be
mechanical dependencies making it necessary to apply patches in order.

 The driver suffers from non-standard formatting and while I did my best
with these bug fixes to follow our coding style, I found some pieces
hopeless, checkpatch.pl will complain.  I plan to reformat the whole
driver, that will inevitably require factoring out some pieces into
separate functions, but that's going to be a major effort and therefore I
want to do this separately, with no functional changes made at the same
time.  If anyone has specific suggestions as to how to reformat any of the
pieces submitted here for a better layout, then I'll be happy to take them
into account.

 And last but not least many thanks to Robert Coerver, who was the most
recent person to report this problem with the driver and was kind enough
to patiently try a few revisions of the driver update on his system as I
was finding and addressing issues.
====================

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parents 90fb5679 8848761f
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment