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] [day] [month] [year] [list]
Message-ID: <s5hfxmkpsw0.wl%tiwai@suse.de>
Date:	Sat, 25 Oct 2008 17:59:59 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Cédric Brégardis <cedric.bregardis@...e.fr>
Cc:	Chuck Ebbert <cebbert@...hat.com>, jhassler@...e.fr,
	linux-kernel@...r.kernel.org
Subject: Re: The snd-aw2 audio driver conflicts with saa7146-based video adapters

At Sat, 25 Oct 2008 16:53:12 +0200,
Cédric Brégardis wrote:
> 
> At Thursday 16 October 2008 07:51:30, Takashi Iwai wrote:
> > At Wed, 15 Oct 2008 23:07:29 +0200,
> >
> > Cédric Brégardis wrote:
> > > Le Tuesday 14 October 2008, Takashi Iwai a écrit :
> > > > At Mon, 13 Oct 2008 19:59:23 -0400,
> > > >
> > > > Chuck Ebbert wrote:
> > > > > snd-aw2 ("Emagic Audiowerk 2 sound driver") matches on PCI ID for any
> > > > > board containing an saa7146 chip. When the driver loads it blocks the
> > > > > proper driver from loading. It also blindly assumes that it is
> > > > > driving an aw2 adapter and just starts writing to various I/O
> > > > > ports...
> > > >
> > > > Indeed, that's bad.
> > > > I guess simply adding PCI SSID would solve this (hopefully).
> > > >
> > > > Cedric, Jean, could you show "lspci -nv" output of the AW2 device?
> > > > (more better submit a patch? :)
> > >
> > > Here is lspci -nv for aw2:
> > >
> > > 02:0b.0 0480: 1131:7146 (rev 01)
> > >         Flags: medium devsel, IRQ 19
> > >         Memory at feafbc00 (32-bit, non-prefetchable) [size=512]
> > >
> > > And here is lspci -x:
> > >
> > > 02:0b.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
> > > 00: 31 11 46 71 02 00 80 02 01 00 80 04 00 40 00 00
> > > 10: 00 bc af fe 00 00 00 00 00 00 00 00 00 00 00 00
> > > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 00
> > >
> > > So, the subsystem id and subsystem vendor id is 0, which is the default
> > > value for SAA7146. SAA7146 can be configured to use a specific subid with
> > > an eeprom, but it is not done here. However we can verify that the subid
> > > is zero. It is not a perfect solution, but it is better than nothing. I
> > > will try to provide a patch next week.
> >
> > Hrm, then maybe it doesn't help much, unfortunately.
> >
> > > However what can we do if there is another card with SAA7146 and with the
> > > default subid which is not the aw2 sound card ?
> >
> > The other drivers try to detect the hardware and returns the error in
> > probe, thus the system can continue to probe the next driver.  aw2
> > driver assumes that it must be an AW2.
> >
> > Is there any way to detect AW2 hardware properly?
> 
> I have looked drivers for other saa7146 based devices. It seams that there are 
> using a generic saa7146 driver (media/common/saa7146_core). If I understand 
> correctly, this driver is a kind of bus driver which initializes common 
> saa7146 features and manages other specific drivers for saa7146.
> So, when the probe of these drivers is called, the hardware is already 
> initialized, and it is possible to check what devices are present on the i2c 
> bus of saa7146. This check should be enough to distinguish if the card is a 
> real aw2 or not.
> 
> So, the solution for aw2 driver is to use this generic driver and check that 
> the i2c eeprom which is on the card is really present or not during the probe. 
> It means that the aw2 alsa driver would depend on 
> driver/media/common/saa7146_core.c (and its associated dependencies). 
> I don't think it is a problem, but tell me if I am wrong !

I think you are correct.  The best solution would be to use the
generic saa7146 stuff.

> I think the generic saa7146 has never be used for audio devices, so it could 
> be needed to patch it (I don't know yet). Again, tell me if it is a problem.

I don't think so.  Go ahead, and let's check whether we see any
problems on it.  There might be some kconfig dependency issues, but
this won't be a big problem, I guess.


Thanks!

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ