Messages in this thread | | | Subject | Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC | From | "Andrew F. Davis" <> | Date | Fri, 23 Oct 2015 07:46:39 -0500 |
| |
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.
| |