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 11:38:43 +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 09:49:20AM +0000, Opensource [Adam Thomson] wrote:

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

> At present I believe your suggestion is to instantiate the codec regmap in the MFD
> core for the PMIC, and then pass this in as part initialisation of the codec driver,
> from the PMIC. Please correct me if I'm wrong.

That's correct.

> If I'm correct then to me this doesn't make sense. The devices are separate,
> and have completely independent register maps. As such I believe the instantiation

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).

> 2) Including the above change, add some optional code to the PMIC MFD core which
> uses 'i2c_new_device()' to instantiate the codec, if it's required (I guess indicated by
> platform data to the PMIC). Means the Codec can still be used as is, but the PMIC core
> code can, if required, instantiate the codec.

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.

> I personally believe option 2 seems unnecessary and it would be simple enough
> just to instantiate the codec driver from machine code, as is done for many standalone
> codecs. Am interested though in understanding the reasoning behind your suggestion,
> for devices like this which are completely independent but can share the same HW
> package. I currently don't see a good reason to make PMIC MFD core instantiate the
> codec, for this type of scenario, but maybe you see something I don't?

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.

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