Dnia Wed, Sep 22, 2021 at 05:39:26AM -0700, Guenter Roeck napisał(a):

On Wed, Sep 22, 2021 at 09:22:33AM +0200, Krzysztof Adamski wrote:

quoted

Dnia Tue, Sep 21, 2021 at 05:58:31AM -0700, Guenter Roeck napisał(a):

quoted

quoted

ti,n-factor

n-factor isn't just supported by TI sensors, though it isn't always called
n-factor. Maxim (eg MAX6581) uses the term "ideality factor", though they
also refer to the factor as "N" in the datasheet.

So question is if we make this ti,n-factor and maxim,n-factor, or if we make
it generic and define some kind of generic units. Thoughts ? My personal
preference would be a generic definition, but is not a strong preference.

That was exactly my way of thinking here - many sensors have n-factor
parameter and this is the name I see most often.

That being said, maybe it should be "nfactor" instead of "n-factor", as
this is what tmp513 is using?

quoted

In regard to units, the n-factor is, as the name says, a factor. Default
value is 1.008. The value range for MAX6581 is 0.999 to 1.030. For TMP421
it is 0.706542 to 1.747977. So the scondary question is if the value
written should be the register value (as proposed here) or the absolute
factor (eg in micro-units).

Since expressing the fractional values in DT isn't well supported and
(at least here) hardware guys like to think in terms of register values
so this is what I proposed. Also, I just noticed that, for example,
TMP531 is using register values as well.

I never see "someone else does that" as valid argument.

It is not an argument for "so I should be allowed too" but more like "so
it is generic enough to make sense for more than a single case" :)

Also, DT does support fractional values, via units. It is perfectly
valid to describe a voltage as micro-volt, for example.

True. But doing so for unit-less values isn't as obvious. For real
fractions we don't even know what the resolution should be and then we
also may have those rounding errors etc (while with register values we
know precisely what we get). As usual, we have some pros and
cons of both approaches. While I agree raw values are not perfect, I
still think it makes more sense so I vote for them. But my vote,
obviously, isn't that important here so I'll let you guys decide.

If the agreement is to use raw register values, I think the property name
should be prefixed with the vendor name, since it won't be a standard
property. I'll defer on Rob for that, though.

Fair enough. If we go that route, we should use "ti,nfactor" (without
dash) to be consistent with ti513?

Krzysztof