linux-kernel - [PATCH] Re: 2.6.26-rc1 regression: ISA DMA broken (bisected)

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: <48406E8D.8050408@keyaccess.nl>
Date:	Fri, 30 May 2008 23:15:57 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
CC:	Takashi Iwai <tiwai@...e.de>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	ALSA devel <alsa-devel@...a-project.org>,
	Andrew Morton <akpm@...l.org>
Subject: [PATCH] Re: 2.6.26-rc1 regression: ISA DMA broken (bisected)

On 14-05-08 21:09, Rene Herman wrote:

> On 14-05-08 20:50, Bjorn Helgaas wrote:

>> I agree, it seems a bit of a hack to use a DMA mask from the card
>> instead of from the device, since the driver should be programming
>> the device to do the DMA.
>>
>> But I know very little about pnp_card in general, so don't attach too
>> much weight to my opinion.
> 
> Okay, I'll sit on this for a bit. Right now we're using a global device 
> even but this is exactly about cleaning that up so couldn't convince 
> myself. Will see what happens when I try to make it nice...

It gets uglier. ALSA ISA drivers (for cards that exist both as legacy 
and as ISAPnP at least) keep a merged legacy/isapnp model; PnP is used 
mostly for initializing global variables that the same old legacy probe 
routines then reference. This means that beyond that global resource 
init step the specific struct device is no longer available. Without 
restructuring too many things really only fixable through other hacks 
again such as a global dma_dev[] array or some such.

 From the viewpoint of PnP itself setting the dma_mask for a pnp_card (a 
pnp_dev collection) makes isolated sense so if no objections, I'll 
submit the attached after all. From the ALSA side we'd then pass the 
card dev (which we'd also do for isa_dev) and keep in mind that we might 
want to get more specific if over time structure permits it.

struct snd_pcm already has its own struct device * which would be the 
right one here but it's setting that which gets ugly...

Rene.

View attachment "0001-PNP-set-the-pnp_card-dma_mask-for-use-by-ISAPnP-car.patch" of type "text/plain" (1127 bytes)