Hi, On Thu, Feb 22, 2018 at 11:54:19AM -0800, Tony Lindgren wrote: > * Mark Brown <broonie@xxxxxxxxxx> [180219 12:05]: > > On Fri, Feb 16, 2018 at 07:57:07AM -0800, Tony Lindgren wrote: > > > One advantage of using a compatible property for the pmic subdevices > > > though is that it leaves out a dependency between various device > > > drivers things happen automagically. The mfd core driver can be > > > minimal and just implement interrupt handling and regmap. So no need > > > to to parse the child nodes in the pmic mfd driver :) > > > > There's no need to do that anyway - with a MFD the child devices can > > assume that they're part of the MFD and reference their parent. > > > > > So personally I'd prefer the option that requires least amount > > > of custom code if compatible vs no compatible property is the > > > only issue here. > > > > It's a few lines of code to register the child devices from code rather > > than the DT, and keeps it out of the ABI. > > OK yeah that's a good point with avoiding the ABI. Seems > we still want the dts child node(s) though. That way audio > device can be disabled for devices where audio is not wired > up at all on this PMIC. We need something to identify the correct child node. If there is no compatible, the node name will become ABI. So I don't think we gain anything by removing the compatible. As far as I can see it seems to be unusual to use fixed node names. I could find some examples, but most sub-devices are identified using compatibles. This method also has direct support in MFD (using .of_compatible in mfd_cell). Based on a bit of grepping through drivers/mfd/, the node name based identification seems to be mainly used by ASoC, while most other subsystems seem to prefer compatible based identification. Anyways, I have implemented the node name based identification and will post patches once I fixed the enum issue. I will probably send them later today. -- Sebastian
Attachment:
signature.asc
Description: PGP signature
