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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Nov 2015 12:10:45 -0600
From:	"Andrew F. Davis" <afd@...com>
To:	Mark Brown <broonie@...nel.org>
CC:	Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Lee Jones <lee.jones@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Grygorii Strashko <grygorii.strashko@...com>,
	<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the
 TPS65912 PMIC

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/