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]

Message-ID: <562A2C2F.1020808@ti.com>
Date:	Fri, 23 Oct 2015 07:46:39 -0500
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 10/22/2015 11:47 AM, Mark Brown wrote:
> On Thu, Oct 01, 2015 at 03:37:53PM -0500, Andrew F. Davis wrote:
>
>> +static const struct of_device_id tps65912_regulator_of_match_table[] = {
>> +	{ .compatible = "ti,tps65912-regulator", },
>> +	{ /* sentinel */ },
>> +};
>> +MODULE_DEVICE_TABLE(of, tps65912_regulator_of_match_table);
>
> Does this IP block exist outside of the tps65912?

Not that I know of yet.

> If not why is it directly represented in DT?

My logic here is that when spins of this device are released they will
add/modify/remove regulators or GPIO pins or other on chip IP, with this
we should be able to simply describe the hardware change by loading
a compatible handler module ("ti,tps65912[x]-regulator" or something),
without having to change out the core or add a bunch of checks and flags.

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..).

> 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,
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.
--
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/