Re: [PATCH] ASoC: codecs: da9055: Update driver name to fix breakage due to pmic driver with same name

[Ashish Chavan <ashish.chavan@kpitcummins.com>]

On Mon, 2013-08-05 at 15:42 +0100, Mark Brown wrote:
> On Mon, Aug 05, 2013 at 01:25:31PM +0530, Ashish Chavan wrote:
> > On Mon, 2013-07-29 at 17:01 +0100, Mark Brown wrote:
>
> > > Well, it's a very unusual hardware design choice to have multiple I2C
> > > endpoints in a single physical chip.
>
> > I hope to see more of such devices in near future.
>
> There's probably a reason why it's not a common hardware design...
>
> > > With regmap it should be very straightforward to reuse the same driver
> > > for both standalone and non-standalone versions, just a small amount of
> > > glue code in the CODEC driver I'd expect.  Usually the bus level code is
> > > tiny.
>
> > The glue code that you are talking about is for the same virtual MFD
> > component that you proposed initially, right? I mean the glue code in
> > CODEC will help it to get attached to the MFD. In this case, in addition
> > to the glue code inside CODEC we will also need additional MFD
> > component. Or I am completely misinterpreting you here?
>
> No, I'm talking about the same thing I was talking about originally.

Thanks for confirming it. From our view point, we still feel that it's
not a good design which requires an additional MFD component even to
support a stand alone CODEC chip. The way we look at it is, there are so
many stand alone CODEC drivers in kernel and most of them are fine
without the MFD stub. We wish that our DA9055 CODEC driver should also
be treated in the same way. Just placing it in a different hardware
package (together with PMIC, in this case) shouldn't necessitate any
changes in software. e.g. whether any chip is produced as a BGA
component or through hole component, has no effect on it's software.

If you still feel that having additional MFD component is THE correct
way to move forward, then I would like to propose another way which
seems more logical to us. i.e. changing name of the CODEC driver. We
will rename the codec to "da9055c" or something similar to resolve the
name collision with PMIC. BTW this is not our preferred way and should
be considered as last option.


This message contains information that may be privileged or confidential and is the property of the KPIT Cummins Infosystems Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Cummins Infosystems Ltd. does not accept any liability for virus infected mails.