Linux-i3c Archive on
 help / color / Atom feed
From: Wolfram Sang <>
To: Luca Ceresoli <>
	"Kieran Bingham" <>,
	"Alexandre Belloni" <>,
	"Linux Kernel Mailing List" <>,
	"Jacopo Mondi" <>,
	"Vladimir Zapolskiy" <>,
	Linux-Renesas <>,
	"Wolfram Sang" <>,
	"Geert Uytterhoeven" <>,
	"Linux I2C" <>,
	"Niklas Söderlund" <>,,
	"Laurent Pinchart" <>
Subject: Re: [RFC PATCH 3/7] i2c: allow DT nodes without 'compatible'
Date: Thu, 12 Mar 2020 12:19:51 +0100
Message-ID: <20200312111950.GA1013@ninjato> (raw)
In-Reply-To: <>

[-- Attachment #1.1: Type: text/plain, Size: 2892 bytes --]

Hi Luca,

> But the kernel currently ignores nodes that have no matching driver,
> right? So in this case the kernel knows that that address is used, but
> ignores this information and considers the address as available.

I'd rather call it "unbound" than available. See later.

> Seen in this perspective, we should have a "compatible" for all nodes:
> it is just describing the hardware and could be out of the kernel
> control. But instead of discarding all nodes without a matching driver,

And what compatible value would you use if you know there is something
sitting there and don't know what? This is what this series aims to
address because we thought a compatible name like "reserved" would not
be a good idea.

> the i2c-core-of code should mark them as "reserved".
> Does it sound correct?

With this patch series, this is quite what happens for ancillary
addresses. They get their own dummy device automatically now, are marked
as reserved and can only be obtained by the driver which bound to the
main address (of_node of ancillary addr == of_node of main addr).

For the main address, I think things are a bit different. They already
have their struct device. The only thing we gain from reserving them (=
binding to the dummy driver) is that they are kinda blocked for
userspace access. The "protection" is kinda low, though. There are
already ways to communicate with bound addresses from userspace.

In kernel space we still need to probe this address until a driver is
bound to it, I don't see what a "reserved" state gains us here. If we
are talking about the pool of available addresses, we are all good
because we operate on existing struct device and don't care if they are
bound or not. Or?

What would be kinda nice, though, is when i2cdetect could show reserved
addresses (unbound but having a struct device) as "RR" or so. However, I
currently can't see a way to do it without breaking compability.

> Clearly this does not fit the case reported by Alexandre: a device
> having a driver which is known to be badly buggy, so we don't want to
> instantiate it. But again, this should not affect DT as it is not
> describing the HW, but only an implementation detail. Probably disabling
> or blacklisting the driver would be a better option there?

"Fixing the driver" is the first thing coming to my mind ;) But yeah,
blacklisting would be another good solution. With only the information
above, DT is not the right place to fix a broken driver.

> My apologies to Wolfram, I appreciate a lot the effort you are doing,
> but before reviewing this patch I have never realized what I tried to
> explain above.

All good, Luca! Talking over code usually brings in viewpoints which
have been missed so far. This is expected. Actually, I am very happy to
have this discussion!

All the best,


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

linux-i3c mailing list

  reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20 17:23 [RFC PATCH 0/7] i2c: of: reserve unknown and ancillary addresses Wolfram Sang
2020-02-20 17:23 ` [RFC PATCH 1/7] i2c: add sanity check for parameter of i2c_verify_client() Wolfram Sang
2020-02-21  9:36   ` Geert Uytterhoeven
2020-02-20 17:23 ` [RFC PATCH 2/7] i2c: use DEFINE for the dummy driver name Wolfram Sang
2020-02-21  9:38   ` Geert Uytterhoeven
2020-02-20 17:23 ` [RFC PATCH 3/7] i2c: allow DT nodes without 'compatible' Wolfram Sang
2020-02-21  9:45   ` Geert Uytterhoeven
2020-02-21  9:48     ` Geert Uytterhoeven
2020-02-23 23:11     ` Luca Ceresoli
2020-03-12 11:19       ` Wolfram Sang [this message]
2020-03-12 11:44         ` Alexandre Belloni
2020-02-26 16:30   ` Rob Herring
2020-02-20 17:24 ` [RFC PATCH 4/7] i2c: of: remove superfluous parameter from exported function Wolfram Sang
2020-02-21  9:50   ` Geert Uytterhoeven
2020-02-24  8:12   ` Luca Ceresoli
2020-02-20 17:24 ` [RFC PATCH 5/7] i2c: of: error message unification Wolfram Sang
2020-02-21  9:54   ` Geert Uytterhoeven
2020-02-20 17:24 ` [RFC PATCH 6/7] i2c: of: mark a whole array of regs as reserved Wolfram Sang
2020-02-21 10:09   ` Geert Uytterhoeven
2020-03-12 11:21     ` Wolfram Sang
2020-03-18 14:33     ` Wolfram Sang
2020-02-28 12:11   ` Luca Ceresoli
2020-02-20 17:24 ` [RFC PATCH 7/7] i2c: core: hand over reserved devices when requesting ancillary addresses Wolfram Sang
2020-02-21 10:13   ` Geert Uytterhoeven
2020-02-28 12:11     ` Luca Ceresoli
2020-03-12 11:30       ` Wolfram Sang
2020-03-12 11:21     ` Wolfram Sang
2020-03-13 12:42     ` Wolfram Sang
2020-02-21 10:15 ` [RFC PATCH 0/7] i2c: of: reserve unknown and " Geert Uytterhoeven

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200312111950.GA1013@ninjato \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-i3c Archive on

Archives are clonable:
	git clone --mirror linux-i3c/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-i3c linux-i3c/ \
	public-inbox-index linux-i3c

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone