Hi,

On Thu, Feb 22, 2018 at 11:54:19AM -0800, Tony Lindgren wrote:
> * Mark Brown <broonie@kernel.org> [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