[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230809112548.cf5o7yxqeu3nfqdq@kobold>
Date: Wed, 9 Aug 2023 06:25:48 -0500
From: Nishanth Menon <nm@...com>
To: Dhruva Gole <d-gole@...com>
CC: Rob Herring <robh+dt@...nel.org>, Stephen Boyd <sboyd@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Tony Lindgren <tony@...mide.com>,
BenoƮt Cousson <bcousson@...libre.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Vibhore Vardhan <vibhore@...com>, <linux-omap@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-pm@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH V3 2/2] dt-bindings: cpufreq: Convert ti-cpufreq to json
schema
On 10:00-20230809, Dhruva Gole wrote:
[..]
> > +description:
> > + Certain TI SoCs, like those in the am335x, am437x, am57xx, am62x and dra7xx
> > + families support different OPPs depending on the silicon variant in use.
> > + The ti-cpufreq driver can use revision and an efuse value from the SoC to
>
> Just learned about this yesterday, hence missed it in my earlier review.
> Looks like the kernel docs [0] say that we DON'T refer to Linux or
> "device driver" in bindings.
>
> Bindings should be based on what the hardware has, not what an OS and
> driver currently support.
Thanks for catching this. will fix in the next rev.
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Powered by blists - more mailing lists