On Thu, Sep 12, 2013 at 22:58, Mark Brown wrote:
It's limiting in as much as it's insisting on a required order for initialisation which shouldn't be there. As said previously they're 2 separate devices in one package, with no internal connection, so either could be instantiated first. It should be open to the user to decide on this based on their platform and needs.
With your approach, it is more work for no gain here, and holds us to a logical representation which doesn't fit with the device in question (which is not really an MFD, it's two devices, one of which is an MFD, the PMIC).
I'm having a hard time understanding this as a practical limitation, can you be more specific about the cases where this would present a noticable problem? It'd at least ensure that the configuration where the whole device is present gets tested to some extent, though that doesn't seem likely to break again.
If I'm honest I didn't have anything specific in mind here. There is the possibility that the Codec needn't be powered from the packaged PMIC (unlikely but technically possible in HW), in the same way as if it were a standalone chip, so I didn't want to unnecessarily imply or force any kind of link or required ordering in Software, to leave it flexible for the future should some need arise.
I understand your concern over testing, given the issue that was found with these drivers, and I can only apologise that it wasn't caught. This is not something that will occur again as we certainly don't want a repeat scenario. It should be noted though that the drivers were thoroughly tested individually for each device and proven fully functional, and I maintain the approach taken for driver development was the correct one here. It will make it easier in the future with standalone versions, and where these devices themselves are paired with a different devices, in the same manor.