From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"Kieran Bingham" <kieran@ksquared.org.uk>,
"Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Jacopo Mondi" <jacopo@jmondi.org>,
"Vladimir Zapolskiy" <vz@mleia.com>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"Linux I2C" <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 3/7] i2c: allow DT nodes without 'compatible'
Date: Thu, 12 Mar 2020 12:44:32 +0100 [thread overview]
Message-ID: <20200312114432.GA3384@piout.net> (raw)
In-Reply-To: <20200312111950.GA1013@ninjato>
On 12/03/2020 12:19:51+0100, Wolfram Sang wrote:
> > 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.
>
To be clear, the driver is working properly but the HW isn't. It is a
PMIC and we need to avoid linux talking to it so the PMIC doesn't end up
killing the bus.
We end up with a node properly described in the device tree but with
status = "disabled". The relevance to the discussion was that you know
what is there and you want to avoid using its address.
See the pmic node on i2c1 in arch/arm/boot/dts/at91-sama5d3_xplained.dts
for what I'm referring to.
> > 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,
>
> Wolfram
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
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: Alexandre Belloni <alexandre.belloni-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
To: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Cc: "Luca Ceresoli" <luca-ep08DiM7hqZH3+C6az13tg@public.gmane.org>,
"Geert Uytterhoeven"
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>,
"Wolfram Sang"
<wsa+renesas-jBu1N2QxHDJrcw3mvpCnnVaTQe2KTcn/@public.gmane.org>,
"Linux I2C" <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux-Renesas
<linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-i3c-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
"Kieran Bingham" <kieran-7hKh/agyDeatmTQ+vhA3Yw@public.gmane.org>,
"Niklas Söderlund"
<niklas.soderlund-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org>,
"Jacopo Mondi" <jacopo-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>,
"Laurent Pinchart"
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
"Vladimir Zapolskiy" <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org>,
"Linux Kernel Mailing List"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC PATCH 3/7] i2c: allow DT nodes without 'compatible'
Date: Thu, 12 Mar 2020 12:44:32 +0100 [thread overview]
Message-ID: <20200312114432.GA3384@piout.net> (raw)
In-Reply-To: <20200312111950.GA1013@ninjato>
On 12/03/2020 12:19:51+0100, Wolfram Sang wrote:
> > 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.
>
To be clear, the driver is working properly but the HW isn't. It is a
PMIC and we need to avoid linux talking to it so the PMIC doesn't end up
killing the bus.
We end up with a node properly described in the device tree but with
status = "disabled". The relevance to the discussion was that you know
what is there and you want to avoid using its address.
See the pmic node on i2c1 in arch/arm/boot/dts/at91-sama5d3_xplained.dts
for what I'm referring to.
> > 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,
>
> Wolfram
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: "Luca Ceresoli" <luca@lucaceresoli.net>,
"Geert Uytterhoeven" <geert@linux-m68k.org>,
"Wolfram Sang" <wsa+renesas@sang-engineering.com>,
"Linux I2C" <linux-i2c@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
linux-i3c@lists.infradead.org,
"Kieran Bingham" <kieran@ksquared.org.uk>,
"Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
"Jacopo Mondi" <jacopo@jmondi.org>,
"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>,
"Vladimir Zapolskiy" <vz@mleia.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>
Subject: Re: [RFC PATCH 3/7] i2c: allow DT nodes without 'compatible'
Date: Thu, 12 Mar 2020 12:44:32 +0100 [thread overview]
Message-ID: <20200312114432.GA3384@piout.net> (raw)
In-Reply-To: <20200312111950.GA1013@ninjato>
On 12/03/2020 12:19:51+0100, Wolfram Sang wrote:
> > 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.
>
To be clear, the driver is working properly but the HW isn't. It is a
PMIC and we need to avoid linux talking to it so the PMIC doesn't end up
killing the bus.
We end up with a node properly described in the device tree but with
status = "disabled". The relevance to the discussion was that you know
what is there and you want to avoid using its address.
See the pmic node on i2c1 in arch/arm/boot/dts/at91-sama5d3_xplained.dts
for what I'm referring to.
> > 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,
>
> Wolfram
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2020-03-13 8:54 UTC|newest]
Thread overview: 67+ 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 ` 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-20 17:23 ` Wolfram Sang
2020-02-21 9:36 ` Geert Uytterhoeven
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-20 17:23 ` Wolfram Sang
2020-02-21 9:38 ` Geert Uytterhoeven
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-20 17:23 ` Wolfram Sang
2020-02-20 17:23 ` Wolfram Sang
2020-02-21 9:45 ` Geert Uytterhoeven
2020-02-21 9:45 ` Geert Uytterhoeven
2020-02-21 9:45 ` Geert Uytterhoeven
2020-02-21 9:48 ` Geert Uytterhoeven
2020-02-21 9:48 ` Geert Uytterhoeven
2020-02-21 9:48 ` Geert Uytterhoeven
2020-02-23 23:11 ` Luca Ceresoli
2020-02-23 23:11 ` Luca Ceresoli
2020-03-12 11:19 ` Wolfram Sang
2020-03-12 11:19 ` Wolfram Sang
2020-03-12 11:44 ` Alexandre Belloni [this message]
2020-03-12 11:44 ` Alexandre Belloni
2020-03-12 11:44 ` Alexandre Belloni
2020-04-10 13:47 ` Luca Ceresoli
2020-04-10 13:47 ` Luca Ceresoli
2020-02-26 16:30 ` Rob Herring
2020-02-26 16:30 ` Rob Herring
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-20 17:24 ` Wolfram Sang
2020-02-21 9:50 ` Geert Uytterhoeven
2020-02-21 9:50 ` Geert Uytterhoeven
2020-02-21 9:50 ` Geert Uytterhoeven
2020-02-24 8:12 ` Luca Ceresoli
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-20 17:24 ` Wolfram Sang
2020-02-21 9:54 ` Geert Uytterhoeven
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-20 17:24 ` Wolfram Sang
2020-02-21 10:09 ` Geert Uytterhoeven
2020-02-21 10:09 ` Geert Uytterhoeven
2020-03-12 11:21 ` Wolfram Sang
2020-03-12 11:21 ` Wolfram Sang
2020-03-18 14:33 ` Wolfram Sang
2020-03-18 14:33 ` Wolfram Sang
2020-02-28 12:11 ` Luca Ceresoli
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-20 17:24 ` Wolfram Sang
2020-02-21 10:13 ` Geert Uytterhoeven
2020-02-21 10:13 ` Geert Uytterhoeven
2020-02-21 10:13 ` Geert Uytterhoeven
2020-02-28 12:11 ` Luca Ceresoli
2020-02-28 12:11 ` Luca Ceresoli
2020-03-12 11:30 ` Wolfram Sang
2020-03-12 11:30 ` Wolfram Sang
2020-03-12 11:21 ` Wolfram Sang
2020-03-12 11:21 ` Wolfram Sang
2020-03-13 12:42 ` 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
2020-02-21 10:15 ` 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:
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=20200312114432.GA3384@piout.net \
--to=alexandre.belloni@bootlin.com \
--cc=devicetree@vger.kernel.org \
--cc=geert@linux-m68k.org \
--cc=jacopo@jmondi.org \
--cc=kieran@ksquared.org.uk \
--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 \
--cc=wsa@the-dreams.de \
/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.