All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Nuno Sá" <nuno.sa@analog.com>, dl-linux-imx <linux-imx@nxp.com>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	"linux-arm Mailing List" <linux-arm-kernel@lists.infradead.org>,
	chrome-platform@lists.linux.dev,
	"Lad Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-iio <linux-iio@vger.kernel.org>,
	"OpenBMC Maillist" <openbmc@lists.ozlabs.org>,
	"Cai Huoqing" <cai.huoqing@linux.dev>,
	"Benjamin Fair" <benjaminfair@google.com>,
	"Jishnu Prakash" <quic_jprakash@quicinc.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Amit Kucheria" <amitk@kernel.org>,
	"Andy Gross" <agross@kernel.org>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Haibo Chen" <haibo.chen@nxp.com>,
	"Benson Leung" <bleung@chromium.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Christophe Branchereau" <cbranchereau@gmail.com>,
	"Patrick Venture" <venture@google.com>,
	"Arnd Bergmann" <arnd@arndb.de>, "Nancy Yuen" <yuenn@google.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Gwendal Grignou" <gwendal@chromium.org>,
	"Saravanan Sekar" <sravanhome@gmail.com>,
	"Tali Perry" <tali.perry1@gmail.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Paul Cercueil" <paul@crapouillou.net>,
	"Thara Gopinath" <thara.gopinath@linaro.org>,
	"Avi Fishman" <avifishman70@gmail.com>,
	"Lorenzo Bianconi" <lorenzo@kernel.org>,
	"Claudiu Beznea" <claudiu.beznea@microchip.com>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabrice Gasnier" <fabrice.gasnier@foss.st.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Tomer Maimon" <tmaimon77@gmail.com>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	"Nicolas Ferre" <nicolas.ferre@microchip.com>,
	"Zhang Rui" <rui.zhang@intel.com>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Guenter Roeck" <groeck@chromium.org>,
	"Fabio Estevam" <festevam@gmail.com>,
	"Olivier Moysan" <olivier.moysan@foss.st.com>,
	"Eugen Hristev" <eugen.hristev@microchip.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Mark Brown" <broonie@kernel.org>
Subject: Re: [PATCH 20/34] iio: inkern: only relase the device node when done with it
Date: Mon, 13 Jun 2022 09:20:26 +0200	[thread overview]
Message-ID: <5e81f73b996de80445c2e905c44ebb18c63a739b.camel@gmail.com> (raw)
In-Reply-To: <20220611155902.2a5a7738@jic23-huawei>

On Sat, 2022-06-11 at 15:59 +0100, Jonathan Cameron wrote:
> 
> +Cc Mark Brown for a query on ordering in device tree based SPI
> setup.
> 
> On Fri, 10 Jun 2022 22:08:41 +0200
> Nuno Sá <noname.nuno@gmail.com> wrote:
> 
> > On Fri, 2022-06-10 at 16:56 +0200, Andy Shevchenko wrote:
> > > On Fri, Jun 10, 2022 at 10:48 AM Nuno Sá <nuno.sa@analog.com>
> > > wrote:  
> > > > 
> > > > 'of_node_put()' can potentially release the memory pointed to
> > > > by
> > > > 'iiospec.np' which would leave us with an invalid pointer (and
> > > > we
> > > > would
> > > > still pass it in 'of_xlate()'). As such, we can only release
> > > > the
> > > > node
> > > > after we are done with it.  
> > > 
> > > The question you should answer in the commit message is the
> > > following:
> > > "Can an OF node, attached to a struct device, be gone before the
> > > device itself?" If it so, then patch is good, otherwise there is
> > > no
> > > point in this patch in the first place.
> > >   
> > 
> > Yeah, I might be wrong but from a quick look... yes, I think the
> > node
> > can be gone before the device. Take a look on the spi or i2c
> > of_notify
> > handling and you can see that the nodes are get/put on the
> > add/remove
> > notifcation. Meaning that the node lifespan is not really attached
> > to
> > the device lifespan. If it was, I would expect to see of_node_put()
> > on
> > the device release() function...
> 
> I had a look at spi_of_notify() and indeed via
> spi_unregister_device()
> the node is put just before device_del() so I agree that at first
> glance
> it seems like there may be a race there against the useage here.
> Mark (+CC) out of interest why are the node gets before the
> device_add()
> in spi_add_device() called from of_register_spi_device() but the
> matching
> node puts before the device_del() in spi_unregister_device()?
> Seems like inconsistent ordering...
> 
> Which is not to say we shouldn't fix the IIO usage as this patch
> does!
> 

Just to add something that came to my attention. In the IIO case, it
does not even matter if the parent device has the OF node lifetime
"linked" to it (as it actually happens for platform devices). The
reason is that iio_dev only has a weak reference to it's parent and (I
think) the parent can actually go away while the iio_dev is still
around (eg: someone has an open fd to the iio_dev cdev).

> > 
> > Again, I might be wrong and I admit I was not sure about including
> > this
> > patch because it's a very unlikely scenario even though I think, in
> > theory, a possible one.
> 
> The patch is currently valid even if it's not a 'real' bug.
> Given we are doing a put on that device_node, it makes sense for that
> to occur after the local use has finished - we shouldn't be relying
> on
> what happens to be the case for lifetimes today.
> 
> Now, I did wonder if any drivers actually use it in their xlate
> callbacks.
> One does for an error print, so this is potentially real (if very
> unlikely!)
> 
> This isn't a 'fix' I'd expect to rush in, or necessarily backport to
> stable
> but I think it's a valid fix.
> 

Should I drop the fixes tag?

- Nuno Sá





WARNING: multiple messages have this Message-ID (diff)
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Nuno Sá" <nuno.sa@analog.com>, dl-linux-imx <linux-imx@nxp.com>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
	"linux-arm Mailing List" <linux-arm-kernel@lists.infradead.org>,
	chrome-platform@lists.linux.dev,
	"Lad Prabhakar" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	"moderated list:ARM/Mediatek SoC support"
	<linux-mediatek@lists.infradead.org>,
	linux-stm32@st-md-mailman.stormreply.com,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	linux-iio <linux-iio@vger.kernel.org>,
	"OpenBMC Maillist" <openbmc@lists.ozlabs.org>,
	"Cai Huoqing" <cai.huoqing@linux.dev>,
	"Benjamin Fair" <benjaminfair@google.com>,
	"Jishnu Prakash" <quic_jprakash@quicinc.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Amit Kucheria" <amitk@kernel.org>,
	"Andy Gross" <agross@kernel.org>,
	"Michael Hennerich" <Michael.Hennerich@analog.com>,
	"Haibo Chen" <haibo.chen@nxp.com>,
	"Benson Leung" <bleung@chromium.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Christophe Branchereau" <cbranchereau@gmail.com>,
	"Patrick Venture" <venture@google.com>,
	"Arnd Bergmann" <arnd@arndb.de>, "Nancy Yuen" <yuenn@google.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Gwendal Grignou" <gwendal@chromium.org>,
	"Saravanan Sekar" <sravanhome@gmail.com>,
	"Tali Perry" <tali.perry1@gmail.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Paul Cercueil" <paul@crapouillou.net>,
	"Thara Gopinath" <thara.gopinath@linaro.org>,
	"Avi Fishman" <avifishman70@gmail.com>,
	"Lorenzo Bianconi" <lorenzo@kernel.org>,
	"Claudiu Beznea" <claudiu.beznea@microchip.com>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Fabrice Gasnier" <fabrice.gasnier@foss.st.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Tomer Maimon" <tmaimon77@gmail.com>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	"Nicolas Ferre" <nicolas.ferre@microchip.com>,
	"Zhang Rui" <rui.zhang@intel.com>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Guenter Roeck" <groeck@chromium.org>,
	"Fabio Estevam" <festevam@gmail.com>,
	"Olivier Moysan" <olivier.moysan@foss.st.com>,
	"Eugen Hristev" <eugen.hristev@microchip.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Mark Brown" <broonie@kernel.org>
Subject: Re: [PATCH 20/34] iio: inkern: only relase the device node when done with it
Date: Mon, 13 Jun 2022 09:20:26 +0200	[thread overview]
Message-ID: <5e81f73b996de80445c2e905c44ebb18c63a739b.camel@gmail.com> (raw)
In-Reply-To: <20220611155902.2a5a7738@jic23-huawei>

On Sat, 2022-06-11 at 15:59 +0100, Jonathan Cameron wrote:
> 
> +Cc Mark Brown for a query on ordering in device tree based SPI
> setup.
> 
> On Fri, 10 Jun 2022 22:08:41 +0200
> Nuno Sá <noname.nuno@gmail.com> wrote:
> 
> > On Fri, 2022-06-10 at 16:56 +0200, Andy Shevchenko wrote:
> > > On Fri, Jun 10, 2022 at 10:48 AM Nuno Sá <nuno.sa@analog.com>
> > > wrote:  
> > > > 
> > > > 'of_node_put()' can potentially release the memory pointed to
> > > > by
> > > > 'iiospec.np' which would leave us with an invalid pointer (and
> > > > we
> > > > would
> > > > still pass it in 'of_xlate()'). As such, we can only release
> > > > the
> > > > node
> > > > after we are done with it.  
> > > 
> > > The question you should answer in the commit message is the
> > > following:
> > > "Can an OF node, attached to a struct device, be gone before the
> > > device itself?" If it so, then patch is good, otherwise there is
> > > no
> > > point in this patch in the first place.
> > >   
> > 
> > Yeah, I might be wrong but from a quick look... yes, I think the
> > node
> > can be gone before the device. Take a look on the spi or i2c
> > of_notify
> > handling and you can see that the nodes are get/put on the
> > add/remove
> > notifcation. Meaning that the node lifespan is not really attached
> > to
> > the device lifespan. If it was, I would expect to see of_node_put()
> > on
> > the device release() function...
> 
> I had a look at spi_of_notify() and indeed via
> spi_unregister_device()
> the node is put just before device_del() so I agree that at first
> glance
> it seems like there may be a race there against the useage here.
> Mark (+CC) out of interest why are the node gets before the
> device_add()
> in spi_add_device() called from of_register_spi_device() but the
> matching
> node puts before the device_del() in spi_unregister_device()?
> Seems like inconsistent ordering...
> 
> Which is not to say we shouldn't fix the IIO usage as this patch
> does!
> 

Just to add something that came to my attention. In the IIO case, it
does not even matter if the parent device has the OF node lifetime
"linked" to it (as it actually happens for platform devices). The
reason is that iio_dev only has a weak reference to it's parent and (I
think) the parent can actually go away while the iio_dev is still
around (eg: someone has an open fd to the iio_dev cdev).

> > 
> > Again, I might be wrong and I admit I was not sure about including
> > this
> > patch because it's a very unlikely scenario even though I think, in
> > theory, a possible one.
> 
> The patch is currently valid even if it's not a 'real' bug.
> Given we are doing a put on that device_node, it makes sense for that
> to occur after the local use has finished - we shouldn't be relying
> on
> what happens to be the case for lifetimes today.
> 
> Now, I did wonder if any drivers actually use it in their xlate
> callbacks.
> One does for an error print, so this is potentially real (if very
> unlikely!)
> 
> This isn't a 'fix' I'd expect to rush in, or necessarily backport to
> stable
> but I think it's a valid fix.
> 

Should I drop the fixes tag?

- Nuno Sá





_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: "Nuno Sá" <noname.nuno@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: "Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Tomer Maimon" <tmaimon77@gmail.com>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	linux-iio <linux-iio@vger.kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Amit Kucheria" <amitk@kernel.org>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Paul Cercueil" <paul@crapouillou.net>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Guenter Roeck" <groeck@chromium.org>,
	"Fabio Estevam" <festevam@gmail.com>,
	linux-stm32@st-md-mailman.stormreply.com,
	chrome-platform@lists.linux.dev,
	"Lars-Peter Clausen" <lars@metafoo.de>,
	"Benjamin Fair" <benjaminfair@google.com>,
	"OpenBMC Maillist" <openbmc@lists.ozlabs.org>,
	"Jishnu Prakash" <quic_jprakash@quicinc.com>,
	"Haibo Chen" <haibo.chen@nxp.com>,
	"Andy Shevchenko" <andy.shevchenko@gmail.com>,
	"Andy Gross" <agross@kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	"Olivier Moysan" <olivier.moysan@foss.st.com>,
	"Zhang Rui" <rui.zhang@in>
Subject: Re: [PATCH 20/34] iio: inkern: only relase the device node when done with it
Date: Mon, 13 Jun 2022 09:20:26 +0200	[thread overview]
Message-ID: <5e81f73b996de80445c2e905c44ebb18c63a739b.camel@gmail.com> (raw)
In-Reply-To: <20220611155902.2a5a7738@jic23-huawei>

On Sat, 2022-06-11 at 15:59 +0100, Jonathan Cameron wrote:
> 
> +Cc Mark Brown for a query on ordering in device tree based SPI
> setup.
> 
> On Fri, 10 Jun 2022 22:08:41 +0200
> Nuno Sá <noname.nuno@gmail.com> wrote:
> 
> > On Fri, 2022-06-10 at 16:56 +0200, Andy Shevchenko wrote:
> > > On Fri, Jun 10, 2022 at 10:48 AM Nuno Sá <nuno.sa@analog.com>
> > > wrote:  
> > > > 
> > > > 'of_node_put()' can potentially release the memory pointed to
> > > > by
> > > > 'iiospec.np' which would leave us with an invalid pointer (and
> > > > we
> > > > would
> > > > still pass it in 'of_xlate()'). As such, we can only release
> > > > the
> > > > node
> > > > after we are done with it.  
> > > 
> > > The question you should answer in the commit message is the
> > > following:
> > > "Can an OF node, attached to a struct device, be gone before the
> > > device itself?" If it so, then patch is good, otherwise there is
> > > no
> > > point in this patch in the first place.
> > >   
> > 
> > Yeah, I might be wrong but from a quick look... yes, I think the
> > node
> > can be gone before the device. Take a look on the spi or i2c
> > of_notify
> > handling and you can see that the nodes are get/put on the
> > add/remove
> > notifcation. Meaning that the node lifespan is not really attached
> > to
> > the device lifespan. If it was, I would expect to see of_node_put()
> > on
> > the device release() function...
> 
> I had a look at spi_of_notify() and indeed via
> spi_unregister_device()
> the node is put just before device_del() so I agree that at first
> glance
> it seems like there may be a race there against the useage here.
> Mark (+CC) out of interest why are the node gets before the
> device_add()
> in spi_add_device() called from of_register_spi_device() but the
> matching
> node puts before the device_del() in spi_unregister_device()?
> Seems like inconsistent ordering...
> 
> Which is not to say we shouldn't fix the IIO usage as this patch
> does!
> 

Just to add something that came to my attention. In the IIO case, it
does not even matter if the parent device has the OF node lifetime
"linked" to it (as it actually happens for platform devices). The
reason is that iio_dev only has a weak reference to it's parent and (I
think) the parent can actually go away while the iio_dev is still
around (eg: someone has an open fd to the iio_dev cdev).

> > 
> > Again, I might be wrong and I admit I was not sure about including
> > this
> > patch because it's a very unlikely scenario even though I think, in
> > theory, a possible one.
> 
> The patch is currently valid even if it's not a 'real' bug.
> Given we are doing a put on that device_node, it makes sense for that
> to occur after the local use has finished - we shouldn't be relying
> on
> what happens to be the case for lifetimes today.
> 
> Now, I did wonder if any drivers actually use it in their xlate
> callbacks.
> One does for an error print, so this is potentially real (if very
> unlikely!)
> 
> This isn't a 'fix' I'd expect to rush in, or necessarily backport to
> stable
> but I think it's a valid fix.
> 

Should I drop the fixes tag?

- Nuno Sá





  reply	other threads:[~2022-06-13  7:19 UTC|newest]

Thread overview: 246+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-10  8:45 [PATCH 00/34] make iio inkern interface firmware agnostic Nuno Sá
2022-06-10  8:45 ` Nuno Sá
2022-06-10  8:45 ` Nuno Sá
2022-06-10  8:45 ` Nuno Sá
2022-06-10  8:45 ` [PATCH 01/34] iio: adc: ad7606: explicitly add proper header files Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 13:59   ` Jonathan Cameron
2022-06-11 13:59     ` Jonathan Cameron
2022-06-11 13:59     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 02/34] iio: adc: ad7606_par: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:00   ` Jonathan Cameron
2022-06-11 14:00     ` Jonathan Cameron
2022-06-11 14:00     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 03/34] iio: adc: berlin2-adc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:02   ` Jonathan Cameron
2022-06-11 14:02     ` Jonathan Cameron
2022-06-11 14:02     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 04/34] iio: adc: imx7d_adc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:04   ` Jonathan Cameron
2022-06-11 14:04     ` Jonathan Cameron
2022-06-11 14:04     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 05/34] iio: adc: imx8qxp-adc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:05   ` Jonathan Cameron
2022-06-11 14:05     ` Jonathan Cameron
2022-06-11 14:05     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 06/34] iio: adc: ingenic-adc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10 14:45   ` Andy Shevchenko
2022-06-10 14:45     ` Andy Shevchenko
2022-06-10 19:49     ` Nuno Sá
2022-06-10 19:49       ` Nuno Sá
2022-06-10 19:49       ` Nuno Sá
2022-06-11 14:07       ` Jonathan Cameron
2022-06-11 14:07         ` Jonathan Cameron
2022-06-11 14:07         ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 07/34] iio: adc: mp2629_adc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:08   ` Jonathan Cameron
2022-06-11 14:08     ` Jonathan Cameron
2022-06-11 14:08     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 08/34] iio: adc: mt6360-adc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:09   ` Jonathan Cameron
2022-06-11 14:09     ` Jonathan Cameron
2022-06-11 14:09     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 09/34] iio: adc: npcm_adc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:12   ` Jonathan Cameron
2022-06-11 14:12     ` Jonathan Cameron
2022-06-11 14:12     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 10/34] iio: adc: rzg2l_adc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:13   ` Jonathan Cameron
2022-06-11 14:13     ` Jonathan Cameron
2022-06-11 14:13     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 11/34] iio: common: cros_ec_lid_angle: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:14   ` Jonathan Cameron
2022-06-11 14:14     ` Jonathan Cameron
2022-06-11 14:14     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 12/34] iio: common: cros_ec_sensors: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:16   ` Jonathan Cameron
2022-06-11 14:16     ` Jonathan Cameron
2022-06-11 14:16     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 13/34] iio: dac: stm32-dac: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:17   ` Jonathan Cameron
2022-06-11 14:17     ` Jonathan Cameron
2022-06-11 14:17     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 14/34] iio: dac: vf610_dac: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:19   ` Jonathan Cameron
2022-06-11 14:19     ` Jonathan Cameron
2022-06-11 14:19     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 15/34] iio: humidity: hts221_buffer: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10 14:47   ` Andy Shevchenko
2022-06-10 14:47     ` Andy Shevchenko
2022-06-11 14:22     ` Jonathan Cameron
2022-06-11 14:22       ` Jonathan Cameron
2022-06-11 14:22       ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 16/34] iio: light: cros_ec_light_prox: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:23   ` Jonathan Cameron
2022-06-11 14:23     ` Jonathan Cameron
2022-06-11 14:23     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 17/34] iio: pressure: cros_ec_baro: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45 ` [PATCH 18/34] iio: trigger: stm32-lptimer-trigger: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45 ` [PATCH 19/34] iio: core: drop of.h from iio.h Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 14:30   ` Jonathan Cameron
2022-06-11 14:30     ` Jonathan Cameron
2022-06-11 14:30     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 20/34] iio: inkern: only relase the device node when done with it Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10 14:56   ` Andy Shevchenko
2022-06-10 14:56     ` Andy Shevchenko
2022-06-10 20:08     ` Nuno Sá
2022-06-10 20:08       ` Nuno Sá
2022-06-10 20:08       ` Nuno Sá
2022-06-11 14:59       ` Jonathan Cameron
2022-06-11 14:59         ` Jonathan Cameron
2022-06-11 14:59         ` Jonathan Cameron
2022-06-13  7:20         ` Nuno Sá [this message]
2022-06-13  7:20           ` Nuno Sá
2022-06-13  7:20           ` Nuno Sá
2022-06-18 14:03           ` Jonathan Cameron
2022-06-18 14:03             ` Jonathan Cameron
2022-06-18 14:13           ` Jonathan Cameron
2022-06-18 14:13             ` Jonathan Cameron
2022-06-18 17:30   ` Jonathan Cameron
2022-06-18 17:30     ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 21/34] iio: inkern: fix return value in devm_of_iio_channel_get_by_name() Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10 14:56   ` Andy Shevchenko
2022-06-10 14:56     ` Andy Shevchenko
2022-06-10  8:45 ` [PATCH 22/34] iio: inkern: only return error codes in iio_channel_get_*() APIs Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10 15:05   ` Andy Shevchenko
2022-06-10 15:05     ` Andy Shevchenko
2022-06-10 19:48     ` Nuno Sá
2022-06-10 19:48       ` Nuno Sá
2022-06-10 19:48       ` Nuno Sá
2022-06-11 15:17   ` Jonathan Cameron
2022-06-11 15:17     ` Jonathan Cameron
2022-06-11 15:17     ` Jonathan Cameron
2022-06-13  7:06     ` Nuno Sá
2022-06-13  7:06       ` Nuno Sá
2022-06-13  7:06       ` Nuno Sá
2022-06-18 14:06       ` Jonathan Cameron
2022-06-18 14:06         ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 23/34] iio: inkern: split of_iio_channel_get_by_name() Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10 15:07   ` Andy Shevchenko
2022-06-10 15:07     ` Andy Shevchenko
2022-06-10  8:45 ` [PATCH 24/34] iio: inkern: move to fwnode properties Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10 15:19   ` Andy Shevchenko
2022-06-10 15:19     ` Andy Shevchenko
2022-06-10 20:01     ` Nuno Sá
2022-06-10 20:01       ` Nuno Sá
2022-06-10 20:01       ` Nuno Sá
2022-06-11 15:30       ` Jonathan Cameron
2022-06-11 15:30         ` Jonathan Cameron
2022-06-11 15:30         ` Jonathan Cameron
2022-06-11 15:32         ` Jonathan Cameron
2022-06-11 15:32           ` Jonathan Cameron
2022-06-13  7:13           ` Nuno Sá
2022-06-18 14:09             ` Jonathan Cameron
2022-06-10  8:45 ` [PATCH 25/34] thermal: qcom: qcom-spmi-adc-tm5: convert to IIO fwnode API Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10 15:20   ` Andy Shevchenko
2022-06-10 15:20     ` Andy Shevchenko
2022-06-10 19:42     ` Nuno Sá
2022-06-10 19:42       ` Nuno Sá
2022-06-10 19:42       ` Nuno Sá
2022-06-10  8:45 ` [PATCH 26/34] iio: adc: ingenic-adc: convert to IIO fwnode interface Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45 ` [PATCH 27/34] iio: adc: ab8500-gpadc: convert to device properties Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-15 14:26   ` Linus Walleij
2022-06-15 14:26     ` Linus Walleij
2022-06-10  8:45 ` [PATCH 28/34] iio: adc: at91-sama5d2_adc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45 ` [PATCH 29/34] iio: adc: qcom-pm8xxx-xoadc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-15 14:27   ` Linus Walleij
2022-06-15 14:27     ` Linus Walleij
2022-06-10  8:45 ` [PATCH 30/34] iio: adc: qcom-spmi-vadc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-16 13:15   ` Linus Walleij
2022-06-16 13:15     ` Linus Walleij
2022-06-10  8:45 ` [PATCH 31/34] iio: adc: qcom-spmi-adc5: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-16 13:16   ` Linus Walleij
2022-06-16 13:16     ` Linus Walleij
2022-06-10  8:45 ` [PATCH 32/34] iio: adc: stm32-adc: " Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-11 15:47   ` Jonathan Cameron
2022-06-11 15:47     ` Jonathan Cameron
2022-06-11 15:47     ` Jonathan Cameron
2022-06-17 15:58     ` Fabrice Gasnier
2022-06-17 15:58       ` Fabrice Gasnier
2022-06-10  8:45 ` [PATCH 33/34] iio: inkern: remove OF dependencies Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45 ` [PATCH 34/34] iio: inkern: fix coding style warnings Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10  8:45   ` Nuno Sá
2022-06-10 15:53   ` Joe Simmons-Talbott
2022-06-10 15:53     ` Joe Simmons-Talbott
2022-06-10 15:53     ` Joe Simmons-Talbott
2022-06-10 19:51     ` Nuno Sá
2022-06-10 19:51       ` Nuno Sá
2022-06-10 19:51       ` Nuno Sá
2022-06-12 17:39       ` Geert Uytterhoeven
2022-06-12 17:39         ` Geert Uytterhoeven
2022-06-12 17:39         ` Geert Uytterhoeven
2022-06-13  7:23         ` Nuno Sá
2022-06-13  7:23           ` Nuno Sá
2022-06-13  7:23           ` Nuno Sá
2022-06-10 14:48 ` [PATCH 00/34] make iio inkern interface firmware agnostic Andy Shevchenko
2022-06-10 14:48   ` Andy Shevchenko
2022-06-10 15:28   ` Andy Shevchenko
2022-06-10 15:28     ` Andy Shevchenko
2022-06-11 15:50     ` Jonathan Cameron
2022-06-11 15:50       ` Jonathan Cameron

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=5e81f73b996de80445c2e905c44ebb18c63a739b.camel@gmail.com \
    --to=noname.nuno@gmail.com \
    --cc=Michael.Hennerich@analog.com \
    --cc=agross@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=amitk@kernel.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=avifishman70@gmail.com \
    --cc=benjaminfair@google.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=bleung@chromium.org \
    --cc=broonie@kernel.org \
    --cc=cai.huoqing@linux.dev \
    --cc=cbranchereau@gmail.com \
    --cc=chrome-platform@lists.linux.dev \
    --cc=claudiu.beznea@microchip.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=eugen.hristev@microchip.com \
    --cc=fabrice.gasnier@foss.st.com \
    --cc=festevam@gmail.com \
    --cc=groeck@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=haibo.chen@nxp.com \
    --cc=jic23@kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=lars@metafoo.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=lorenzo@kernel.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=nicolas.ferre@microchip.com \
    --cc=nuno.sa@analog.com \
    --cc=olivier.moysan@foss.st.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=paul@crapouillou.net \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
    --cc=quic_jprakash@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=sravanhome@gmail.com \
    --cc=tali.perry1@gmail.com \
    --cc=thara.gopinath@linaro.org \
    --cc=tmaimon77@gmail.com \
    --cc=venture@google.com \
    --cc=yuenn@google.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.