linux-kernel - Re: [PATCH v10 5/8] dt-bindings: media: add TI DS90UB960 FPD-Link III Deserializer

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <b85a2198-dffd-6c1e-53ea-61bc4d14ce2a@ideasonboard.com>
Date:   Thu, 20 Apr 2023 10:30:19 +0300
From:   Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To:     Wolfram Sang <wsa@...nel.org>, linux-media@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-i2c@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Luca Ceresoli <luca.ceresoli@...tlin.com>,
        Andy Shevchenko <andriy.shevchenko@...el.com>,
        Matti Vaittinen <Matti.Vaittinen@...rohmeurope.com>,
        Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Peter Rosin <peda@...ntia.se>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Michael Tretter <m.tretter@...gutronix.de>,
        Hans Verkuil <hverkuil@...all.nl>,
        Mike Pagano <mpagano@...too.org>,
        Krzysztof Hałasa <khalasa@...p.pl>,
        Marek Vasut <marex@...x.de>,
        Satish Nagireddy <satish.nagireddy@...cruise.com>,
        Rob Herring <robh@...nel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH v10 5/8] dt-bindings: media: add TI DS90UB960 FPD-Link III
 Deserializer

On 18/04/2023 16:06, Wolfram Sang wrote:
> 
>> +  i2c-alias-pool:
>> +    $ref: /schemas/types.yaml#/definitions/uint16-array
>> +    description:
>> +      I2C alias pool is a pool of I2C addresses on the main I2C bus that can be
>> +      used to access the remote peripherals on the serializer's I2C bus. The
>> +      addresses must be available, not used by any other peripheral. Each
>> +      remote peripheral is assigned an alias from the pool, and transactions to
>> +      that address will be forwarded to the remote peripheral, with the address
>> +      translated to the remote peripheral's real address. This property is not
>> +      needed if there are no I2C addressable remote peripherals.
> 
> After some initial discussion with Tomi on IRC, this question is
> probably more for Luca:
> 
> Why is "i2c-alias-pool" in the drivers binding and not a regular i2c

Where should be the binding documented? A new 
Documentation/devicetree/bindings/i2c/i2c-atr.yaml file that only 
contains the i2c-alias-pool?

> binding? Same question for the implementation of the alias-pool
> handling. Shouldn't this be in the i2c-atr library? I'd think managing
> the list of aliases would look all the same in the drivers otherwise?

I think this is fine, but I also think that we need to keep the door 
open to other kinds of alias management. We only have a single user for 
this for now. A driver/device might have other requirements for its 
i2c-atr. Say, a pool per link, or perhaps runtime events may affect the 
pool.

If we dictate the use of i2c-alias-pool property and the i2c-atr will 
automatically get an alias from that pool, i2c-atr won't be usable for 
the hypothetical drivers that have other needs.

With that in mind the current binding and i2c-atr.c is safe, as the 
i2c-atr.c isn't even aware of the pool.

We can easily re-arrange the code later if and when we get more users 
and understand their needs. But the bindings are important to get 
right(-ish) now. So:

- Is the "i2c-alias-pool" property a driver property or a common 
property for all drivers using i2c-atr?

- It the property mandatory or optional? It must be optional, as a setup 
(meaning, e.g., what cameras you happen to connect) might not have any 
i2c addressable remote devices, in which case the driver doesn't even 
need i2c-atr (even if it supports i2c-atr). But is it optional even in 
the case where the driver needs i2c-atr? In other words, do we allow 
some other way to manage the aliases?

How does this sound:

- If "i2c-alias-pool" is present in the DT data of the device passed to 
i2c_atr_new(), i2c_atr_new() will parse the property. i2c-atr.c will 
export functions to get a new alias and to release a previously reserved 
alias. The driver can use those functions in attach/detach_client() 
callbacks. In other words, the alias pool management wouldn't be fully 
automatic inside the i2c-atr, but it would provide helpers for the 
driver to do the common work.

- If "i2c-alias-pool" is not present, i2c-atr.c will behave as it does 
now, and expects the driver to manage the aliases.

Also, looking at the ub960 code... I don't think this will simplify the 
attach/detach_client callbacks much. Most of the code in those functions 
is about managing the UB960's registers related to ATR, not managing the 
address pool itself. However, it will remove the probe time 
"i2c-alias-pool" parsing from the driver, which is nice.

  Tomi