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: <201204172307.58016.linux@rainbow-software.org>
Date:	Tue, 17 Apr 2012 23:07:48 +0200
From:	Ondrej Zary <linux@...nbow-software.org>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [alsa-devel] [PATCH 3/4] Add Wolfson Microelectronics WM8776 codec ALSA driver

On Tuesday 17 April 2012 21:12:33 you wrote:
> At Tue, 17 Apr 2012 20:15:06 +0200,
>
> Ondrej Zary wrote:
> > On Tuesday 17 April 2012 20:06:19 Takashi Iwai wrote:
> > > At Tue, 17 Apr 2012 18:04:31 +0100,
> > >
> > > Mark Brown wrote:
> > > > On Tue, Apr 17, 2012 at 06:52:49PM +0200, Takashi Iwai wrote:
> > > > > Mark Brown wrote:
> > > > > > This isn't just adding something into a specific driver which
> > > > > > fails at abstraction, it's adding generic code.  If it were
> > > > > > adding something to the ice17xx driver then that'd be one thing
> > > > > > but look at the subject line and location of the file...  this
> > > > > > stuff should be buried inside the driver if it's too painful to
> > > > > > make the driver sane.
> > > > >
> > > > > The codes in sound/i2c are mostly oly for ice1712/ice1724 drivers
> > > > > after all...  They could be used by others, but I don't think there
> > > > > will be any more at this point.
> > > >
> > > > If they're specific to that driver we should make them specific to
> > > > that driver and make sure the pain is confined there.  We really
> > > > don't want to end up going back to the bad old days of having to do
> > > > per-CPU/card drivers for CODECs because nobody had thought to
> > > > abstract this stuff, that just makes everyone miserable.
> > > >
> > > > Looking at these commits I'd not expect anyone to figure out that
> > > > this isn't how we want or expect people to add generic CODEC drivers.
> > >
> > > Yeah, these stuff can be better put in pci/ice1712/ directory only
> > > for ice1724 driver.  In that way, you can avoid unnecessary exported
> > > symbols, too.
> >
> > Xonar (oxygen) has a private version of these drivers too. It could be
> > converted to use common code instead.
>
> Hm, only if the generated controls do match with your case,..
> It's case by case, especally if there is only one another candidate.

Control names can be changed (and also disabled) by the driver. In fact, 
psc724 does exactly this as is needs the WM8776 controls to be named 
as "front" and WM8766 as "rear".
I don't see any problem if something needs to be changed for this code to be 
used by Xonar (or some other driver).

-- 
Ondrej Zary
--
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