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

[Andrew F. Davis]

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