From: Wolfram Sang <email@example.com> To: Luca Ceresoli <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Mauro Carvalho Chehab <email@example.com>, Rob Herring <firstname.lastname@example.org>, Mark Rutland <email@example.com>, Sakari Ailus <firstname.lastname@example.org>, Hans Verkuil <email@example.com>, Laurent Pinchart <firstname.lastname@example.org>, Kieran Bingham <email@example.com>, Jacopo Mondi <firstname.lastname@example.org>, Vladimir Zapolskiy <email@example.com>, Peter Rosin <firstname.lastname@example.org> Subject: Re: [RFC,v2 3/6] media: dt-bindings: add DS90UB954-Q1 video deserializer Date: Tue, 3 Sep 2019 11:34:55 +0200 [thread overview] Message-ID: <20190903093455.GD1020@kunai> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 2444 bytes --] > Not if you define enough addresses in the pool. E.g. the DS90UB954 > hardware can have 8 aliases per port, so if you have (n_ports * 8) > addresses in the pool the problem is solved. And then you plug-in somewhere another board with another need for ATR and you are out of addresses. > > And another add-on module with > > non-repogrammable devices may occupy addresses from the defined pool > > above. > > You mean a new device on the local (SoC-to-ATR) bus? Well, it could as > well occupy a non-described address that the ATR has already picked as > an alias. Nope, I mean a seperate add-on which has a hardcoded I2C address on the bus of the ATR parent. Then this hardcoded address needs to be removed from the pool if it is in the wrong range. > > I am not perfectly happy with the assumption that all undescribed > > addresses are automatically free. That also might need DTS updates to > > describe all clients properly. But this change only needs to be done > > once, and it will improve the description of the hardware. > > Right, but I still suspect some users won't do their homework and > discover address conflicts at runtime, maybe months later, in a painful > way. Also a chip might be undocumented on a given board, so they could > do their homework and still have problems. Yes, we probably need a binding to mark an address as used even though we don't know the device or don't have a driver for it. Don't get me wrong, I know what you mean. One of my boards has a client soldered in a way so that it is still in debug mode. That means it listens to addresses 0x03-0x07 to provide debug information. Took me a while to find out what is happening there. But still, 'i2cdetect' showed all of these. > Despite my comments, I'm not strongly against your proposal. To me it > doesn't seem to solve any problem, while it does introduce some degree > of risk. Could you elaborate more on but what benefit it introduces? I'd think the risk of running out of defined addresses is somewhere equal to running into (after a while) an unexpectedly used address. I like the fix for the latter better because describing what is on the bus is more helpful and generic than updating the pool-property every time you need it. Plus, as mentioned above, other add-on hardware may disturb your pool allocation. I expect this topic to be one of the discussion points of the BoF. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-09-03 9:35 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-23 20:37 [RFC,v2 0/6] TI camera serdes and I2C address translation Luca Ceresoli 2019-07-23 20:37 ` [RFC,v2 1/6] i2c: core: let adapters be notified of client attach/detach Luca Ceresoli 2019-07-23 20:37 ` [RFC,v2 2/6] i2c: add I2C Address Translator (ATR) support Luca Ceresoli 2019-09-01 14:31 ` jacopo mondi 2019-09-03 7:31 ` Luca Ceresoli 2019-09-03 7:37 ` Wolfram Sang 2019-09-04 8:09 ` Peter Rosin 2019-09-08 19:40 ` Luca Ceresoli 2019-09-10 18:46 ` Wolfram Sang 2019-09-08 20:45 ` Vladimir Zapolskiy 2019-09-09 4:56 ` Vladimir Zapolskiy 2019-09-10 17:40 ` Luca Ceresoli 2019-09-09 7:22 ` Wolfram Sang 2019-09-09 15:10 ` Vladimir Zapolskiy 2019-09-09 17:48 ` Luca Ceresoli 2019-09-10 17:16 ` Wolfram Sang 2019-09-02 20:42 ` Wolfram Sang 2019-09-03 8:48 ` Luca Ceresoli 2019-09-03 9:06 ` Wolfram Sang 2019-07-23 20:37 ` [RFC,v2 3/6] media: dt-bindings: add DS90UB954-Q1 video deserializer Luca Ceresoli 2019-08-13 15:44 ` Rob Herring 2019-08-19 22:41 ` Luca Ceresoli 2019-08-20 15:44 ` Rob Herring 2019-08-21 21:50 ` Luca Ceresoli 2019-09-02 20:48 ` Wolfram Sang 2019-09-03 9:09 ` Luca Ceresoli 2019-09-03 9:34 ` Wolfram Sang [this message] 2019-09-03 11:03 ` Luca Ceresoli 2019-09-03 14:16 ` Wolfram Sang 2019-09-10 9:43 ` Sakari Ailus 2019-09-10 15:02 ` Luca Ceresoli 2019-07-23 20:37 ` [RFC,v2 4/6] media: dt-bindings: add DS90UB953-Q1 video serializer Luca Ceresoli 2019-07-23 20:37 ` [RFC,v2 5/6] media: ds90ub954: new driver for TI DS90UB954-Q1 video deserializer Luca Ceresoli 2019-07-23 20:37 ` [RFC,v2 6/6] media: ds90ub953: new driver for TI DS90UB953-Q1 video serializer Luca Ceresoli
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190903093455.GD1020@kunai \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RFC,v2 3/6] media: dt-bindings: add DS90UB954-Q1 video deserializer' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).