Date:   Thu, 23 Feb 2023 12:59:30 +0200
From:   Matti Vaittinen <mazziesaccount@...il.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Shreeya Patel <shreeya.patel@...labora.com>,
        Zhigang Shi <Zhigang.Shi@...eon.com>,
        Paul Gazzillo <paul@...zz.com>,
        Dmitry Osipenko <dmitry.osipenko@...labora.com>,
        Liam Beguin <liambeguin@...il.com>,
        Peter Rosin <peda@...ntia.se>,
        Randy Dunlap <rdunlap@...radead.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 1/6] dt-bindings: iio: light: Support ROHM BU27034

On 2/23/23 11:26, Krzysztof Kozlowski wrote:
> On 23/02/2023 07:20, Vaittinen, Matti wrote:
>> On 2/22/23 20:57, Krzysztof Kozlowski wrote:
>>> On 22/02/2023 17:14, Matti Vaittinen wrote:
>>>> ROHM BU27034 is an ambient light sesnor with 3 channels and 3 photo diodes
>>>> capable of detecting a very wide range of illuminance. Typical application
>>>> is adjusting LCD and backlight power of TVs and mobile phones.
>>>>
>>>> Add initial dt-bindings.
>>>
>>> Driver can be "initial", but bindings better to be closer to complete,
>>> even if not used by the driver currently.
>>
>> Out of the curiosity - why is that? (Please, don't take me wrong, I am
>> not trying to argue against this - just learn the reason behind). I
>> can't immediately see the harm caused by adding new properties later
>> when we learn more of hardware. (and no, I don't expect this simple IC
>> to gain at least many properties).
> 
> Linux drivers change, but the hardware does not, thus DTS, which
> describes the hardware, can be complete. It should be written based on
> the hardware, not based on Linux drivers. If you add incomplete
> bindings, this suggests you wrote them to match your driver, not to
> match hardware. This in turn (adjusting bindings to driver) makes them
> less portable, narrowed to one specific driver implementation and more
> ABI-break-prone later.
> 
> Imagine you that clock inputs, which you skipped in the binding, were
> actually needed but on your board they were enabled by bootloader. The
> binding is then used on other systems or by out of tree users. On your
> new system the clocks are not enabled by bootloader anymore, thus you
> add them to the binding. They are actually required for device to work,
> so you make them required. But all these other users cannot be fixed...
> 
> What's more, incomplete binding/DTS is then used together with other
> pieces - DTS and driver, e.g. via some graphs or other
> phandles/supplies/pinctrl. So some other DTS or driver code might rely
> on your particular binding. Imagine you had only vdd-supply regulator,
> but no reset pins, so the only way to power-cycle device was to turn
> off/on regulator supply. Then you figure out that you have reset pins
> and it would be useful to add and use it. But already drivers are
> written to power cycle via regulator... or even someone wrote new driver
> regulator-pwrseq to power cycle your device due to missing reset GPIOs...

Thanks for explanation Krzysztof. I think that what you wrote here makes 
sense. Still, I don't think this "adding features only later can cause 
problems to others" is in any way fundamentally different for bindings 
and software. Sure this clock example is a valid thing, adding a clock 
later could cause kernel to suddenly be aware of it can disable it - but 
disabling the clock would still require a new piece of clk driver too...

I think same problems can happen when lower layer SW does not implement 
all the features - upper layers may need to implement some odd quircks 
and workarounds to get things working, and all that can be useless or 
even incompatible with the new low-level SW which finally adds the 
missing implementation.

I guess the 'fundamental' difference I was looking for is that the 
hardware itself should not change - so in theory we should know the HW 
from the day 1. Still, we (I) at times notice we need some information 
about the hardware only when we are (I am) writing the drivers ;) 
Unfortunately there are companies where all the information about the 
hardware is not immediately available ...

Out of the curiosity 2 (an no need to respond if you're in hurry) - how 
should one treat hardware logic which is implemented on FPGA? I have in 
the past worked for a good while on a project where FPGA blocks were 
also described in dt - but this _really_ blurs the line between 
"immutable" hardware and "mutable" software. (And yes, we had a great 
deal of "fun" with updating the FPGA images, FPGA device-trees, linux 
images and board device-trees...)

Anyways, I agree with you. It would be good to have as complete bindings 
as possible from the day 1.

By the way - planning to attend ELCE next summer? It'd be great to have 
a lecture part II about writing the bindings ;)

Yours,
	--Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~

Powered by blists - more mailing lists