lkml.org 
[lkml]   [2018]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 1/3] dt-bindings: thermal: Add binding document for SR thermal
On Thu, Sep 27, 2018 at 11:00:33AM -0700, Scott Branden wrote:
>
>
> On 18-09-27 10:31 AM, Florian Fainelli wrote:
> > On 09/27/2018 10:27 AM, Rob Herring wrote:
> > > On Thu, Sep 27, 2018 at 09:06:41PM +0530, Srinath Mannam wrote:
> > > > From: Pramod Kumar <pramod.kumar@broadcom.com>
> > > >
> > > > Add binding document for supported thermal implementation
> > > > in Stingray.
> > > >
> > > > Signed-off-by: Pramod Kumar <pramod.kumar@broadcom.com>
> > > > Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
> > > > Reviewed-by: Ray Jui <ray.jui@broadcom.com>
> > > > Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> > > > ---
> > > > .../bindings/thermal/brcm,sr-thermal.txt | 25 ++++++++++++++++++++++
> > > > 1 file changed, 25 insertions(+)
> > > > create mode 100644 Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
> > > > new file mode 100644
> > > > index 0000000..717617b
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
> > > > @@ -0,0 +1,25 @@
> > > > +* Broadcom Stingray Thermal
> > > > +
> > > > +This binding describes thermal sensors that is part of Stingray SoCs.
> > > > +
> > > > +Required properties:
> > > > +- compatible : Must be "brcm,sr-thermal"
> > > > +- reg : memory where tmon data will be available.
> > > > +- brcm,tmon-mask: A one cell bit mask of valid TMON sources.
> > > > + Each bit represents single TMON source.
> > > > +- brcm,max-crit-temp: Maximum supported critical temperature.
> > > We already have a defined binding for setting trip points.
> > Indeed, and if you have multiple TMONs, they would in premise possibly
> > each have a different critical trip point.
> Which may be a good reason to go back to our original bindings which were
> generic and had each sensor in its own node?

Perhaps. I wouldn't call it going back to your original, but rather
defining a complete binding. Of course, if you don't need different trip
points, then again that is just unnecessary bloat. But I can't argue
whether you do or don't.

Rob

\
 
 \ /
  Last update: 2018-09-27 21:00    [W:0.047 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site