On Thu, Jan 09, 2014 at 02:22:48PM +0000, Opensource [Adam Thomson] wrote:
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
Right, but at the time...
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.
If you want to support any additional CODEC only devices with compatible register maps that exist you just need to add something like less than a hundred lines of mostly boilerplate code to do so in the ASoC driver. It's hard to see any difference to devices that have both I2C and SPI or both PCI and platform buses here. Those devices should have separate device ID entries anyway.
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?
I do agree that the current situation is not great - this is intended to try to move things forwards since mainline is currently broken for this device and has been for a couple of releases now. One of the things my patch is trying to do is to get someone to tell us what we need to plug into i2c_add_dummy() to make this work. I had hoped that if I wrote the code we could get this fixed but without documentation or something that last bit can't be done, would that be possible?