From: Wolfram Sang <wsa@the-dreams.de>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: "Jacopo Mondi" <jacopo@jmondi.org>,
"Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
linux-kernel@vger.kernel.org, "Vladimir Zapolskiy" <vz@mleia.com>,
linux-renesas-soc@vger.kernel.org,
"Kieran Bingham" <kieran@bingham.xyz>,
linux-i2c@vger.kernel.org,
"Luca Ceresoli" <luca@lucaceresoli.net>,
linux-i3c@lists.infradead.org,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>
Subject: Re: [RFC PATCH v2 0/6] i2c: of: reserve unknown and ancillary addresses
Date: Sat, 28 Mar 2020 04:50:36 +0100 [thread overview]
Message-ID: <20200328035036.GA1017@kunai> (raw)
In-Reply-To: <20200318150059.21714-1-wsa+renesas@sang-engineering.com>
[-- Attachment #1.1: Type: text/plain, Size: 998 bytes --]
> There is only one thing giving me some headache now. There is a danger
> of a regression maybe. If someone has multiple 'reg' entries in the DT
> but never used i2c_new_ancillary_device but i2c_new_dummy_device, then
> things will break now because i2c_new_dummy_device has not enough
> information to convert a "reserved" device to a "dummy" one. It will
> just see the address as busy. However, all binding documentations I
> found which use 'reg' as an array correctly use
> i2c_new_ancillary_device. On the other hand, my search strategy for
> finding such bindings and DTs do not feel perfect to me. Maybe there are
> also some more corner cases in this area, so this series is still RFC.
So, I used another search strategy: I checked every
i2c_new_dummy_device() caller in the kernel tree and made sure they
don't get the address to use from DT. I can confirm this is not the
case. That gives me enough trust to say the above issue is a non-issue.
Still open for comments, of course...
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 155 bytes --]
_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
WARNING: multiple messages have this Message-ID (diff)
From: Wolfram Sang <wsa@the-dreams.de>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-i2c@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-i3c@lists.infradead.org,
"Kieran Bingham" <kieran@ksquared.org.uk>,
"Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
"Luca Ceresoli" <luca@lucaceresoli.net>,
"Jacopo Mondi" <jacopo@jmondi.org>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
"Vladimir Zapolskiy" <vz@mleia.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/6] i2c: of: reserve unknown and ancillary addresses
Date: Sat, 28 Mar 2020 04:50:36 +0100 [thread overview]
Message-ID: <20200328035036.GA1017@kunai> (raw)
In-Reply-To: <20200318150059.21714-1-wsa+renesas@sang-engineering.com>
[-- Attachment #1: Type: text/plain, Size: 998 bytes --]
> There is only one thing giving me some headache now. There is a danger
> of a regression maybe. If someone has multiple 'reg' entries in the DT
> but never used i2c_new_ancillary_device but i2c_new_dummy_device, then
> things will break now because i2c_new_dummy_device has not enough
> information to convert a "reserved" device to a "dummy" one. It will
> just see the address as busy. However, all binding documentations I
> found which use 'reg' as an array correctly use
> i2c_new_ancillary_device. On the other hand, my search strategy for
> finding such bindings and DTs do not feel perfect to me. Maybe there are
> also some more corner cases in this area, so this series is still RFC.
So, I used another search strategy: I checked every
i2c_new_dummy_device() caller in the kernel tree and made sure they
don't get the address to use from DT. I can confirm this is not the
case. That gives me enough trust to say the above issue is a non-issue.
Still open for comments, of course...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-03-28 3:50 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-18 15:00 [RFC PATCH v2 0/6] i2c: of: reserve unknown and ancillary addresses Wolfram Sang
2020-03-18 15:00 ` Wolfram Sang
2020-03-18 15:00 ` [RFC PATCH v2 1/6] i2c: use DEFINE for the dummy driver name Wolfram Sang
2020-03-18 15:00 ` Wolfram Sang
2020-04-15 8:09 ` Kieran Bingham
2020-04-15 8:09 ` Kieran Bingham
2020-03-18 15:00 ` [RFC PATCH v2 2/6] i2c: allow DT nodes without 'compatible' Wolfram Sang
2020-03-18 15:00 ` Wolfram Sang
2020-04-10 13:49 ` Luca Ceresoli
2020-04-10 13:49 ` Luca Ceresoli
2020-04-15 7:59 ` Wolfram Sang
2020-04-15 7:59 ` Wolfram Sang
2020-04-15 8:07 ` Kieran Bingham
2020-04-15 8:07 ` Kieran Bingham
2020-04-15 8:16 ` Wolfram Sang
2020-04-15 8:16 ` Wolfram Sang
2020-04-15 8:38 ` Kieran Bingham
2020-04-15 8:38 ` Kieran Bingham
2020-04-16 14:53 ` Luca Ceresoli
2020-04-16 14:53 ` Luca Ceresoli
2020-04-15 8:48 ` Kieran Bingham
2020-04-15 8:48 ` Kieran Bingham
2020-04-15 9:46 ` Wolfram Sang
2020-04-15 9:46 ` Wolfram Sang
2020-03-18 15:00 ` [RFC PATCH v2 3/6] i2c: of: remove superfluous parameter from exported function Wolfram Sang
2020-03-18 15:00 ` Wolfram Sang
2020-03-19 12:41 ` Boris Brezillon
2020-03-19 12:41 ` Boris Brezillon
2020-04-15 8:13 ` Kieran Bingham
2020-04-15 8:13 ` Kieran Bingham
2020-03-18 15:00 ` [RFC PATCH v2 4/6] i2c: of: error message unification Wolfram Sang
2020-03-18 15:00 ` Wolfram Sang
2020-04-10 17:02 ` Luca Ceresoli
2020-04-10 17:02 ` Luca Ceresoli
2020-04-15 8:17 ` Kieran Bingham
2020-04-15 8:17 ` Kieran Bingham
2020-04-15 8:50 ` Kieran Bingham
2020-04-15 8:50 ` Kieran Bingham
2020-03-18 15:00 ` [RFC PATCH v2 5/6] i2c: of: mark a whole array of regs as reserved Wolfram Sang
2020-03-18 15:00 ` Wolfram Sang
2020-04-10 17:05 ` Luca Ceresoli
2020-04-10 17:05 ` Luca Ceresoli
2020-04-13 9:55 ` Luca Ceresoli
2020-04-13 9:55 ` Luca Ceresoli
2020-04-15 8:10 ` Wolfram Sang
2020-04-15 8:10 ` Wolfram Sang
2020-04-15 10:07 ` Luca Ceresoli
2020-04-15 10:07 ` Luca Ceresoli
2020-03-18 15:00 ` [RFC PATCH v2 6/6] i2c: core: hand over reserved devices when requesting ancillary addresses Wolfram Sang
2020-03-18 15:00 ` Wolfram Sang
2020-04-15 10:07 ` Luca Ceresoli
2020-04-15 10:07 ` Luca Ceresoli
2020-03-28 3:50 ` Wolfram Sang [this message]
2020-03-28 3:50 ` [RFC PATCH v2 0/6] i2c: of: reserve unknown and " Wolfram Sang
2020-04-15 8:27 ` Wolfram Sang
2020-04-15 8:27 ` Wolfram Sang
2020-04-15 8:35 ` Kieran Bingham
2020-04-15 8:35 ` Kieran Bingham
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=20200328035036.GA1017@kunai \
--to=wsa@the-dreams.de \
--cc=jacopo@jmondi.org \
--cc=kieran@bingham.xyz \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=luca@lucaceresoli.net \
--cc=niklas.soderlund@ragnatech.se \
--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.