linux-kernel - Re: [PATCH v3] Documentation: add Device tree bindings for hwmon/nct7802

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Sep 2015 13:47:51 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	Constantine Shulyupin <const@...elinux.com>
Cc:	"linux@...ck-us.net" <linux@...ck-us.net>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <Pawel.Moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] Documentation: add Device tree bindings for
 hwmon/nct7802

On Tue, Sep 08, 2015 at 01:07:30PM +0100, Constantine Shulyupin wrote:
> >> Add add Device tree bindings for registers
> >> which are not covered by hwmon ABI and are required to
> >> configure specific HW.
> >
> > This doesn't really answer my question [1] of why you need these.
> >
> > We generally don't encode register values unless there's no other way to
> > describe the device. Why can we not describe the physical properties of
> > the device that make these values necessary?
> >
> ....
> > That said, as above I don't believe that these properties make sense
> > as they are. I think this needs properties that describe the HW, rather
> > than exposing the intricacies of the programming interface.
> ....
> > Thanks,
> > Mark.
> >
> > [1] http://lkml.kernel.org/r/20150907123531.GA11540@leverpostej
> >
> 
> Sources of the driver:
> 
> Let's see to register MODE.
> Excerpt from datasheet:
> 
> 7.2.32 Mode Selection Register
> Location : Index 22h
> Type : Read/Write
> Power on default value : 7Fh
> BIT; NAME; FUNC.:
> 0,1 RTD1_MD : 00=Closed , 01=Current mode , 10=Thermistor mode ,
> 11=Voltage sense
> 2,3 RTD2_MD : 00=Closed , 01=Current mode , 10=Thermistor mode ,
> 11=Voltage sense
> 4,5 RTD3_MD : 00=Closed , 01=Reserved , 10=Thermistor mode , 11=Voltage sense
> 6 EnLTD : 1 indicates the LTD function enabled
> 
> The register defines sensors types (Closed, Current mode, Thermistor
> mode, Voltage sense).
> Essential sensors will not work properly with wrong configuration.

Sure, but why do you need _raw_ register values?

Why can you not encode this in the DT in a manner that describes what is
connected to this device, then have the kernel figure out any particular
values that need to be poked into registers?

That'll be easier to read, and it's far more likely people will get
things correct in a dts.

Mark.

> It is board or platform depended configuration. It should be
> configured on boot only.
> Usually hwmon drivers are managed with utility lm-sensors via
> Documentation/hwmon/sysfs-interface. By design sensor type should be
> defined by platform data and lm-sensors only displays it.
> 
> Also MODE registers defines visibility temperature and input attributes:
> 
> https://git.kernel.org/cgit/linux/kernel/git/mpe/linux-next.git/tree/drivers/hwmon/nct7802.c#n532
> 
> https://git.kernel.org/cgit/linux/kernel/git/mpe/linux-next.git/tree/drivers/hwmon/nct7802.c#n641
> 
> Mark, does above answers your question?
> What do you propose?
> 
> -- 
> Thanks
> Constantine
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/