On Fri, Oct 23, 2015 at 07:46:39AM -0500, Andrew F. Davis wrote: > I know just because other drivers do it doesn't mean it's a good idea, > but this is not new for MFDs and it is done in other regulators as well > (mt6397, tps659038, qcom,spmi, etc..). mt6397 doesn't do this, it doesn't have a compatible string at all (it's doing what I'm recommending that you do). The SPMI devices are standalone devices, their parent device is actually functioning as a bus controller here (it's really a microcontroller inside the SoC). The Palmas is part of how we realised this was a problem. > >It seems like this is describing how Linux > >loads drivers not how the hardware is constructed but DT should describe > >the hardware. > While I agree to a point, if we follow this to its logical conclusion we > would end up with one compatible binding per SoC and be basically back to > board files. We need some granularity, just finding out where is the issue, The fact that the SoC DT is not distinct from the board DT is actually one of the problems with the way we're using DT at the minute, it means that DTBs are much less stable than they should be since we can enhance support for SoCs but DTBs need regenerating to take advantage of it. It would be much better if the boards just referenced the SoC they use and pulled in a separate definition of the SoC (DT overlays will make it much more tractable to implement that if someone has time...). > I would say that as these devices belong to different subsystems and are > almost completely independent there should be no problem with having their > own compatible matched hardware sub-node. All it's adding is more typing for users.
Attachment:
signature.asc
Description: PGP signature
