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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/04/2023 21:47, Wolfram Sang wrote:
Hi Tomi,

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.

So, how does a driver manage the aliases without a pool of available
addresses? I can't imagine another way right now.

In general, your above proposal sounds good to me. With my lack of
imagination regarding a different alias handling, I could also see that
i2c-atr already provides the alias to the attach callback. But if you
teach me another way of alias handling, then I could agree that your
proposal makes sense as is.

Oh, my imagination doesn't go so far to give you concrete examples. If the driver has to do runtime decisions on the pool, a fixed pool handled by the i2c-atr won't work. But why exactly would there be runtime events affecting the pool... I don't know.

Maybe that doesn't matter here. We can start with the i2c-atr providing the alias to the attach callback, and if we ever need something else, the (kernel internal) API can be changed accordingly. The DT bindings should be fine in either case.

 Tomi




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux