On 07-09-16, 10:04, Dave Gerlach wrote:
> >>+static const struct of_device_id ti_cpufreq_of_match[] = {
> >>+ { .compatible = "operating-points-v2-ti-am3352-cpu",
> >>+ .data = &am3x_soc_data, },
> >>+ { .compatible = "operating-points-v2-ti-am4372-cpu",
> >>+ .data = &am4x_soc_data, },
> >>+ { .compatible = "operating-points-v2-ti-dra7-cpu",
> >>+ .data = &dra7_soc_data },
> >
> >You should be using your SoC compatible strings here. OPP compatible
> >property isn't supposed to be (mis)used for this purpose.
> >
>
> Referring to my comments in patch 1, what if we end up changing the bindings
> based on DT maintainer comments? We will have these compatible strings, and
> at that point is it acceptable to match against them? Or is it still better
> to match to SoC compatibles? I think it makes sense to just probe against
> these.
But even then I think these are not correct. You should have added a
single compatible string: operating-points-v2-ti-cpu.
As the properties will stay the same across machines. And then you
need to use SoC strings here.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
