[alsa-devel] [PATCH] ASoC: da9055: Partially fix device

[Opensource [Adam Thomson]]

On Wed, 9 Jan 2014 12:14:53 +0000, Mark Brown wrote:

> Hrm, you hadn't mentioned the rename in that thread.  I do note that the
> change was from KPIT Cummins who submitted the drivers for this chip for
> you guys and appear to be doing updates too...

I said at the beginning of that thread that we would be taking responsibility
of the driver and KPIT Cummins are no longer involved with this work. At that
point the change to the PMIC I2C id name had already been made (by KPIT) and was
in the kernel. I refer you to this mail in the thread, and to the last paragraph
where I make the proposal of changing the codec I2C Id name to tidy things up:

http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066138.html

> > the I2C Id names and avoid this but you would not agree. The codec
> > part can be standalone and by doing what you've done here means that
> > customers would need to now add additional, unnecessary code to be
> > able to use just the codec driver.  This is not right to me.
> 
> No, users will not have to do any extra work - if anything they have to
> do marginally less with only registering one device.  As discussed this
> is the way Linux handles things (which is also the rationale in the
> changelog for the PMIC rename).  Looking at the changelogs I'd not be
> surprised if the rename was done due to the author getting caught out by
> the non-standard way the driver was done.

Use JUST the codec driver. No PMIC. For some chips, 'the way Linux handles
things' makes sense, but not here. I don't want to re-cover old ground though as
we spent long enough over this last time.

What I would like to highlight, and it's something that concerns me more, is
that someone went into the kernel and changed the I2C Id name for no good
reason, and didn't test if their submission worked correctly (I am of course
well aware in the original submission from KPIT there was a conflict in the I2C
Id name, but that was rectified, and would've been tidied up further had it been
permitted). On top of that you are also leaving it in an unusable state with
your change. If we direct customers to the drivers in the mainline kernel, the
codec cannot be simply instantiated as before, and certainly won't be
instantiated from the MFD code. How is this acceptable?