linux-kernel - Re: [alsa-devel] [PATCH] ASoC: codecs: da9055: Update driver name to fix breakage due to pmic driver with same name

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>] [day] [month] [year] [list]

Date:	Mon, 2 Sep 2013 18:41:21 +0100
From:	Mark Brown <broonie@...nel.org>
To:	"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@...semi.com>
Cc:	Ashish Chavan <ashish.chavan@...tcummins.com>, lrg <lrg@...com>,
	alsa-devel <alsa-devel@...a-project.org>,
	David Dajun Chen <david.chen@...semi.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"kiran.padwal" <kiran.padwal@...tcummins.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: codecs: da9055: Update driver name to
 fix breakage due to pmic driver with same name

On Mon, Sep 02, 2013 at 03:38:18PM +0000, Opensource [Adam Thomson] wrote:
> On Mon, Sep 02, 2013 at 11:39, Mark Brown wrote:

> > Please fix your mailer to wrap within 80 columns, it makes your mails
> > very hard to read if you don't do this.

> Yeah, sorry for that. Having to use Outlook and of course it doesn't seem to
> have that feature (at least not that I could find), so trying to do it
> manually.

It's always been in there, can't remember where exactly and I don't have
access to Outlook any more.

> > They are not separate, they are soldered to the board as part of the
> > same package - quite a few other devices use a similar scheme and are
> > also handled in this fashion (the TI TWL devices are one example).

> The difference here is that our combined devices can also be separate chips,
> not just one HW package containing logically separate devices. I don't believe
> that's the case with say the TI devices.

That doesn't seem like a unique feature.

> > This is roughly what ends up happening, you do need to instantiate
> > another I2C client no matter what.  The important thing here is that the
> > CODEC does not need to be separately registered by the user, if it
> > really is only the I2C client that needs creating that's probably OK so
> > long as the user doesn't need to worry about that implementation detail.

> The only thing that would need populating is some small platform data for the
> codec (MIC bias voltages, and such). You'd still have to do this, combined or
> separate, as this is platform specific. Other than this, the I2C client
> initialisation for the codec is simple, which is a reason why I don't think
> the PMIC needs to initialise it, and you can just as simply do it from machine
> code.

It's the bit where the board has to register the CODEC separately at all
that's the thing.  Think about it from the point of view of people
writing and reviewing the machine bindings - they end up with this odd
chip that appears twice with two names and registration schemas.

> > The reasoning is simply that if the chip design solders a single device
> > to the board then the software system integration should register a
> > single device with the system.

> Ok, but what about the scenario where the devices start life as separate chips
> and are then later also packaged together as one chip but still with no
> internal connection, like DA9055. The drivers were already written and accepted
> as separate entities in the kernel, without chained initialisation. What would
> be the approach there? To me, logically it makes sense to leave them separate.

It doesn't seem to make much difference what order the drivers are added
in here?  You're going to need to add a new device IDs for the SIP anyway
since it'd presumably be badged as something new - if it wasn't then
that's a bit different.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)