linux-kernel - Re: [Device-drivers-devel] [alsa-devel] [PATCH 2/3] ASoC: Blackfin: Add bf5xx-adau1701 machine driver

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: <20110610180137.GP26436@opensource.wolfsonmicro.com>
Date:	Fri, 10 Jun 2011 19:01:38 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Mike Frysinger <vapier@...too.org>
Cc:	Lars-Peter Clausen <lars@...afoo.de>, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org,
	device-drivers-devel@...ckfin.uclinux.org,
	uclinux-dist-devel@...ckfin.uclinux.org, Liam Girdwood <lrg@...com>
Subject: Re: [Device-drivers-devel] [alsa-devel] [PATCH 2/3] ASoC: Blackfin:
 Add bf5xx-adau1701 machine driver

On Fri, Jun 10, 2011 at 01:47:34PM -0400, Mike Frysinger wrote:
> On Fri, Jun 10, 2011 at 13:30, Mark Brown wrote:

> > So, I keep on complaining about the way these drivers are just generic
> > to any random Blackfin plus CODEC combination rather than being board
> > specific.  It'd be good if we could improve this, even adding something
> > into the driver name to make it clear these are for the EVB would help.

> i know you keep complaining, but i honestly dont understand why this
> is undesirable.  connecting a codec to a Blackfin is pretty much
> always the same.  you pick a SPORT # and that's about it.

Only if you're looking at very basic boards - as soon as you start
adding any external components on the boards like speaker amps, start
handling jacks (with detection or without) or start dealing with more
flexible CODEC devices with a wider range of connection possibilities
the number of possibilities expands dramatically.

> the spi cs and i2c address could differ (so maybe make that a field
> for the platform resources), but otherwise i dont see why people
> should have to copy & paste the same code to change all of 4 bytes.

Reusing code where there's similiarities is fine - Tegra is doing that
for WM8903 based systems in a fairly tasteful fashion - but that's not
really what this stuff feels like it is doing.  For example, the SPORT
selection and reset GPIO selection should be platform data not Kconfig
options and drivers that explicitly say they're for a particular board
in Kconfig should probably say so in code also.
--
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/