From: Wolfram Sang <wsa@the-dreams.de>
To: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
linux-i2c@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Luca Ceresoli <luca@lucaceresoli.net>,
Jacopo Mondi <jacopo@jmondi.org>,
Vladimir Zapolskiy <vz@mleia.com>
Subject: Re: [RFC PATCH 3/5] i2c: core: add function to request an alias
Date: Wed, 8 Jan 2020 14:35:33 +0100 [thread overview]
Message-ID: <20200108133533.GD834@kunai> (raw)
In-Reply-To: <61344235-9e66-0d89-89cd-1adef2e0bce1@ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
> >> I.e. if say the adv748x had in DT defined aliases at 0x08, 0x09,
> >> 0x0A..., but not yet probed (thus no device is listening at these
> >> addresses) ... and then a max9286 came along and asked for 'any' spare
> >> address with this call, would it be given 0x08 first?
You have a point here. Ancillary addresses are not blocked until the
driver probes, this is true. I wonder now if we should handle multiple
addresses in i2c-core-of.c somehow, too? It does block the first <reg>
entry, but not all.
> The core 'could' parse all reg entries, and conclude that any extended
> entries within a device node are aliases as well, which should be
> reserved, but I don't think it could know if the device is actually
> going to be enabled by a driver (well, it could look it up).
We could argue that if it is described in DT, it should be blocked in
any case, or?
> But it would also have to traverse any i2c-muxes too!
I probably need a second thought about muxes as well.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-01-08 13:35 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-31 16:13 [RFC PATCH 0/5] i2c: implement mechanism to retrieve an alias device Wolfram Sang
2019-12-31 16:13 ` [RFC PATCH 1/5] i2c: core: refactor scanning for a client Wolfram Sang
2020-01-01 16:45 ` Laurent Pinchart
2020-01-07 9:26 ` Kieran Bingham
2020-01-07 9:53 ` Geert Uytterhoeven
2020-01-07 9:58 ` Kieran Bingham
2020-01-07 10:25 ` Wolfram Sang
2020-01-07 10:36 ` Geert Uytterhoeven
2020-01-07 11:23 ` Wolfram Sang
2020-01-07 15:03 ` Luca Ceresoli
2020-01-07 16:45 ` Wolfram Sang
2020-01-07 16:52 ` Kieran Bingham
2019-12-31 16:13 ` [RFC PATCH 2/5] i2c: core: add new variant to check " Wolfram Sang
2020-01-01 16:49 ` Laurent Pinchart
2020-01-07 9:42 ` Kieran Bingham
2019-12-31 16:13 ` [RFC PATCH 3/5] i2c: core: add function to request an alias Wolfram Sang
2020-01-01 16:55 ` Laurent Pinchart
2020-01-02 18:58 ` Luca Ceresoli
2020-01-02 21:13 ` Wolfram Sang
2020-01-02 22:27 ` Luca Ceresoli
2020-01-03 0:10 ` Laurent Pinchart
2020-01-07 15:03 ` Luca Ceresoli
2020-01-07 17:13 ` Laurent Pinchart
2020-01-08 13:27 ` Wolfram Sang
2020-01-08 13:31 ` Laurent Pinchart
2020-01-08 13:38 ` Wolfram Sang
2020-01-08 13:22 ` Wolfram Sang
2020-01-08 13:19 ` Wolfram Sang
2020-01-08 13:29 ` Geert Uytterhoeven
2020-01-08 13:34 ` Laurent Pinchart
2020-01-02 21:03 ` Wolfram Sang
2020-01-21 9:05 ` Peter Rosin
2020-01-07 9:40 ` Kieran Bingham
2020-01-07 17:11 ` Laurent Pinchart
2020-01-07 17:14 ` Kieran Bingham
2020-01-08 13:35 ` Wolfram Sang [this message]
2020-01-08 13:36 ` Laurent Pinchart
2019-12-31 16:13 ` [RFC PATCH 4/5] i2c: core: add simple caching to the 'alias' scanning Wolfram Sang
2020-01-07 9:59 ` Kieran Bingham
2020-01-21 9:22 ` Peter Rosin
2019-12-31 16:14 ` [RFC PATCH 5/5] simple test case for the I2C alias functionality Wolfram Sang
2019-12-31 16:27 ` [RFC PATCH 0/5] i2c: implement mechanism to retrieve an alias device Wolfram Sang
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=20200108133533.GD834@kunai \
--to=wsa@the-dreams.de \
--cc=jacopo@jmondi.org \
--cc=kieran.bingham@ideasonboard.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=luca@lucaceresoli.net \
--cc=vz@mleia.com \
--cc=wsa+renesas@sang-engineering.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.