linux-kernel - Re: [PATCH 1/2] dt-bindings: iio: magnetometer: add ti tmag5273 documentation file

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 17 Nov 2022 18:04:01 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Michael Riesch <michael.riesch@...fvision.net>,
        Gerald Loacker <gerald.loacker@...fvision.net>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc:     linux-iio@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Nikita Yushchenko <nikita.yoush@...entembedded.com>,
        Jakob Hauser <jahau@...ketmail.com>
Subject: Re: [PATCH 1/2] dt-bindings: iio: magnetometer: add ti tmag5273
 documentation file

On 17/11/2022 18:01, Michael Riesch wrote:
> Hi Krzysztof,
> 
> On 11/17/22 17:17, Krzysztof Kozlowski wrote:
>> On 17/11/2022 17:12, Gerald Loacker wrote:
>>>>
>>>>> +
>>>>> +  compatible:
>>>>> +    const: ti,tmag5273
>>>>> +
>>>>> +  reg:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  "#io-channel-cells":
>>>>> +    const: 1
>>>>> +
>>>>> +  ti,angle-enable:
>>>>> +    description:
>>>>> +      Enables angle measurement in the selected plane.
>>>>> +      0 = OFF
>>>>> +      1 = X-Y (default)
>>>>> +      2 = Y-Z
>>>>> +      3 = X-Z
>>>>
>>>> This feels like something we should be configuring at runtime rather that
>>>> DT, or is it driven by board design or similar?
>>>>
>>>
>>> We use this sensor for a zoom wheel application, there is an EVM from TI
>>> for this as well. So this is for setting the mounting position of the wheel.
>>
>> That's ok, but does not explain why choice of angle measurement should
>> be a property of the hardware. I could imagine configuring device to
>> measure sometimes X-Y and sometimes X-Z, depending on the use case. Use
>> case can change runtime.
> 
> If I may chime in here: in our use case the angle channel is used
> directly as an input to adc-joystick, so that the combination of the two
> is an input device. We feel that in this scenario this angle measurement
> setting *has* to be a hardware property because the correct function of
> the input device depends on the correct choice of the angle property
> (which does not change during runtime, of course).
> 
> If we were to create a different input device in which the magnetometer
> was tilted by 90° (for example), then the angle property could be easily
> changed in the device tree. The user space, on the other hand, couldn't
> possibly know the correct angle property.
> 
> That said, I agree that there may be use cases in which the angle
> property should be changed during runtime. Would it be acceptable to
> create an IIO property that is initialized by the device tree property?
> (Please note that the implementation of the IIO property may not be in
> our scope, though)

It's fine. Thanks for the explanations. For runtime-configurable setups
this still can be changed via some other interface.

Best regards,
Krzysztof