lkml.org 
[lkml]   [2023]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v10 5/8] dt-bindings: media: add TI DS90UB960 FPD-Link III Deserializer
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.

And yes, the "i2c-alias-pool" is definately optional.

Happy hacking,

Wolfram

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2023-04-20 20:47    [W:0.091 / U:2.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site