Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC

[Andrew F. Davis]

On 11/06/2015 04:43 AM, Mark Brown wrote:
> On Thu, Nov 05, 2015 at 12:04:00PM -0600, Andrew F. Davis wrote:
> > On 11/05/2015 04:14 AM, Mark Brown wrote:
>
> > > That sounds like a bug to me, it'll have broken a bunch of existing
> > > devices.
>
> > Most OF drivers have the OF MODALIAS.
>
> That's nice but not relevant to non-OF devices.
>
> > 'platform_uevent' can only emit one MODALIAS string per device (only
> > the last emitted one seems to count), so for any device with
> > 'dev->of_node' set it will be the OF MODALIAS string. So I need
> > that table (to generate the OF MODALIAS) or this sub-device module
> > will not be loaded.
>
> No, you need to fix the bug that is causing dev->of_node to be populated
> for the MFD function device.  Probably the issue is that you have put
> this pointless compatible string in your DT.

If it is pointless what is the reason we have .of_compatible in mfd_cell?
How else do you want us to populate the sub-device dev->of_node? Looking
at other DT regulators a lot *do( just use an OF table, others use their
parent's dev to get of_node, why all the push back on having an OF match
table? Probe gets called with the pdev filled with its of_node to begin with.

> Please stop this.  I don't understand why you are pushing so hard to put
> the Linux device model representation of the device into DT but it's
> getting very repetitive.

I'm not pushing anything, this is how other sub-nodes of MFD devices are
represented, I'm not sure what you think I'm doing that is so wrong here.
No one else seems to have an issue with the DT for this device, I see no
reason the regulator node has to be different than the other sub-device
nodes.

It looks rather out of place to have regulators be singled out like this,
for instance look at the mfd_cells for drivers/mfd/rt5033.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/