netdev - Re: ssb: Fix DMA-API compilation for non-PCI systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20081110.145343.171487164.davem@davemloft.net>
Date:	Mon, 10 Nov 2008 14:53:43 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	mb@...sch.de
Cc:	netdev@...r.kernel.org
Subject: Re: ssb: Fix DMA-API compilation for non-PCI systems

From: Michael Buesch <mb@...sch.de>
Date: Mon, 10 Nov 2008 23:07:37 +0100

> On Monday 10 November 2008 22:52:31 David Miller wrote:
> > 
> > I applied this since it's a build buster and we should
> > get it fixed quickly.
> > 
> > But as I look at this, the thing to really do here is get
> > rid of these stupid switch statements.  None of it is needed.
> > 
> > The layer that sets up the SSB devices should simply save the
> > generic device pointer for the DMA entity into some new
> > ->dma_dev struct member.
> >
> > Then you just use generic dma_*() interfaces unilaterally.  For PCI
> > devices it will "just work".
> 
> We tried that. It doesn't work. It breaks on several architectures
> that do special things in the pci_dma... functions.
> See the git history and mailinglists, please.

Then those architectures need to fix their implementations,
simply.  They aren't implementing the generic DMA interfaces
properly.  Other subsystems do make use of the generic DMA
interfaces in this way.

Even something as simple as checking for &pci_bus_type in the
dma_*() routines (like powerpc did for quite some time) is
enough to fix the problem.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html