On Fri, Jan 10, 2014 at 06:32:38PM +0000, Opensource [Adam Thomson] wrote:
On Thu, 9 Jan 2014 20:24:46 +0000, Mark Brown wrote:
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.
The point is here is that it's unnecessary what you're suggesting. You're basically adding more code to instantiate the Codec from the PMIC, removing the valid I2C code from the Codec driver, and then if a user/customer wants to use the Codec standalone then they need to add that code again. Agreed that new device Ids should be added in the future for new standalone variants, but that should not mean having to add all of the I2C boilerplate code again. It think it makes things unnecessarily messy, on top of the additional effort required.
We also get people complaining about other stylistic things that they get asked to fix and people going round fixing style issues - the whole reason this broke is that people noticed and fixed the fact that the drivers looked wrong to inspection without realising that there were multiple drivers for the device because it's not done in the manner we usually do this (that's definitely why the CODEC driver was changed, I picked up on it during review on submission). It's really useful to have things follow common patterns, it makes maintianing the system easier and it makes factoring out shareable code easier. Things like interfaces to the rest of the system tend to get particular focus.
Please, this isn't helping...
Well, the truth is that there are default I2C addresses for both PMIC and Codec but as they are standalone devices, albeit in one package, both addresses can be changed. This is one more reason why I don't believe we should be taking your method of implementation here. If you just make sure PMIC and Codec drivers
...but on the other hand this sounds like an actual technical issue which could be a good reason to do something different - it's a bit surprising that it didn't come up before. What exactly is the flexibility the devices have here? It's a pretty unusual hardware design.
have unique Ids then the problem is solved. If you are worried about people changing this again in the future (although for the life of me I don't know why they would), then we can add a glaring comment to dissuade them, or point them at the codec driver.
That's definitely required.