All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>
Cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>,
	gregkh <gregkh@linuxfoundation.org>,
	"Rafael Wysocki" <rafael@kernel.org>,
	"Horia Geantă" <horia.geanta@nxp.com>,
	aymen.sghaier@nxp.com, "Herbert Xu" <herbert@gondor.apana.org.au>,
	"David Miller" <davem@davemloft.net>,
	"Tony Lindgren" <tony@atomide.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Vinod Koul" <vkoul@kernel.org>,
	peter.ujfalusi@gmail.com, "Andrzej Hajda" <a.hajda@samsung.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Robert Foss" <robert.foss@linaro.org>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Kevin Hilman" <khilman@baylibre.com>,
	tomba@kernel.org, jyri.sarha@iki.fi,
	"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>, Kishon <kishon@ti.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Roy Pledge" <Roy.Pledge@nxp.com>, "Leo Li" <leoyang.li@nxp.com>,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Eduardo Valentin" <edubezval@gmail.com>,
	Keerthy <j-keerthy@ti.com>, "Felipe Balbi" <balbi@kernel.org>,
	"Tony Prisk" <linux@prisktech.co.nz>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	dmaengine@vger.kernel.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"open list:ARM/Amlogic Meson SoC support"
	<linux-amlogic@lists.infradead.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	linux-phy@lists.infradead.org,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-staging@lists.linux.dev,
	"moderated list:ARM/Mediatek SoC..."
	<linux-mediatek@lists.infradead.org>,
	"Linux PM list" <linux-pm@vger.kernel.org>,
	"USB list" <linux-usb@vger.kernel.org>,
	LINUXWATCHDOG <linux-watchdog@vger.kernel.org>
Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Tue, 20 Apr 2021 11:10:40 +0200	[thread overview]
Message-ID: <CAK8P3a1tPQm1Qj2KZu2jOM=TUP0dJgP4G9eKkWfv-PZEAWEhyA@mail.gmail.com> (raw)
In-Reply-To: <YH4VdPNO9cdzc5MD@atmark-techno.com>

On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
<dominique.martinet@atmark-techno.com> wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
> > For loadable modules, this is up to user space in the end.
> >
> > Which of the drivers in this scenario are loadable modules?
>
> All the drivers involved in my case are built-in (nvmem, soc and final
> soc_device_match consumer e.g. caam_jr that crashes the kernel if soc is
> not identified properly).

Ok, in that case you may have a chance to just adapt the initcall
levels. This is somewhat fragile if someone else already relies
on a particular order, but it's an easy one-line change to change
a driver e.g. from module_init() or device_initcall() to arch_initcall().

> I frankly don't like the idea of moving nvmem/ above soc/ in
> drivers/Makefile as a "solution" to this (especially as there is one
> that seems to care about what soc they run on...), so I'll have a look
> at links first, hopefully that will work out.

Right, that would be way more fragile.

I think the main problem in this case is the caam driver that really
should not look into the particular SoC type or even machine
compatible string. This is something we can do as a last resort
for compatibility with busted devicetree files, but it appears that
this driver does it as the primary method for identifying different
hardware revisions. I would suggest fixing the binding so that
each SoC that includes one of these devices has a soc specific
compatible string associated with the device that the driver can
use as the primary way of identifying the device.

We probably need to keep the old logic around for old dtb files,
but there can at least be a comment next to that table that
discourages people from adding more entries there.

      Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>
Cc: "Ulf Hansson" <ulf.hansson@linaro.org>,
	aymen.sghaier@nxp.com,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Rafael Wysocki" <rafael@kernel.org>,
	"David Airlie" <airlied@linux.ie>,
	"Michael Turquette" <mturquette@baylibre.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Andrzej Hajda" <a.hajda@samsung.com>,
	Networking <netdev@vger.kernel.org>,
	linux-phy@lists.infradead.org, peter.ujfalusi@gmail.com,
	linux-clk <linux-clk@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Horia Geantă" <horia.geanta@nxp.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	linux-staging@lists.linux.dev,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Kishon <kishon@ti.com>, "Tony Lindgren" <tony@atomide.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	LINUXWATCHDOG <linux-watchdog@vger.kernel.org>,
	"Will Deacon" <will@kernel.org>,
	"Linux PM list" <linux-pm@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	"Eduardo Valentin" <edubezval@gmail.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"moderated list:ARM/Mediatek SoC..."
	<linux-mediatek@lists.infradead.org>,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"open list:ARM/Amlogic Meson SoC support"
	<linux-amlogic@lists.infradead.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>,
	"Felipe Balbi" <balbi@kernel.org>,
	tomba@kernel.org, "Stephen Boyd" <sboyd@kernel.org>,
	gregkh <gregkh@linuxfoundation.org>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	"USB list" <linux-usb@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	"Robert Foss" <robert.foss@linaro.org>,
	"Leo Li" <leoyang.li@nxp.com>,
	"Tony Prisk" <linux@prisktech.co.nz>,
	"Vinod Koul" <vkoul@kernel.org>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>, "Daniel Vetter" <daniel@ffwll.ch>,
	Keerthy <j-keerthy@ti.com>,
	dmaengine@vger.kernel.org, "Roy Pledge" <Roy.Pledge@nxp.com>,
	jyri.sarha@iki.fi, "David Miller" <davem@davemloft.net>
Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Tue, 20 Apr 2021 11:10:40 +0200	[thread overview]
Message-ID: <CAK8P3a1tPQm1Qj2KZu2jOM=TUP0dJgP4G9eKkWfv-PZEAWEhyA@mail.gmail.com> (raw)
In-Reply-To: <YH4VdPNO9cdzc5MD@atmark-techno.com>

On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
<dominique.martinet@atmark-techno.com> wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
> > For loadable modules, this is up to user space in the end.
> >
> > Which of the drivers in this scenario are loadable modules?
>
> All the drivers involved in my case are built-in (nvmem, soc and final
> soc_device_match consumer e.g. caam_jr that crashes the kernel if soc is
> not identified properly).

Ok, in that case you may have a chance to just adapt the initcall
levels. This is somewhat fragile if someone else already relies
on a particular order, but it's an easy one-line change to change
a driver e.g. from module_init() or device_initcall() to arch_initcall().

> I frankly don't like the idea of moving nvmem/ above soc/ in
> drivers/Makefile as a "solution" to this (especially as there is one
> that seems to care about what soc they run on...), so I'll have a look
> at links first, hopefully that will work out.

Right, that would be way more fragile.

I think the main problem in this case is the caam driver that really
should not look into the particular SoC type or even machine
compatible string. This is something we can do as a last resort
for compatibility with busted devicetree files, but it appears that
this driver does it as the primary method for identifying different
hardware revisions. I would suggest fixing the binding so that
each SoC that includes one of these devices has a soc specific
compatible string associated with the device that the driver can
use as the primary way of identifying the device.

We probably need to keep the old logic around for old dtb files,
but there can at least be a comment next to that table that
discourages people from adding more entries there.

      Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>
Cc: "Ulf Hansson" <ulf.hansson@linaro.org>,
	aymen.sghaier@nxp.com,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Rafael Wysocki" <rafael@kernel.org>,
	"David Airlie" <airlied@linux.ie>,
	"Michael Turquette" <mturquette@baylibre.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Andrzej Hajda" <a.hajda@samsung.com>,
	Networking <netdev@vger.kernel.org>,
	linux-phy@lists.infradead.org, peter.ujfalusi@gmail.com,
	linux-clk <linux-clk@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Horia Geantă" <horia.geanta@nxp.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	linux-staging@lists.linux.dev,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Kishon <kishon@ti.com>, "Tony Lindgren" <tony@atomide.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	LINUXWATCHDOG <linux-watchdog@vger.kernel.org>,
	"Will Deacon" <will@kernel.org>,
	"Linux PM list" <linux-pm@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	"Eduardo Valentin" <edubezval@gmail.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"moderated list:ARM/Mediatek SoC..."
	<linux-mediatek@lists.infradead.org>,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"open list:ARM/Amlogic Meson SoC support"
	<linux-amlogic@lists.infradead.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>,
	"Felipe Balbi" <balbi@kernel.org>,
	tomba@kernel.org, "Stephen Boyd" <sboyd@kernel.org>,
	gregkh <gregkh@linuxfoundation.org>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	"USB list" <linux-usb@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	"Robert Foss" <robert.foss@linaro.org>,
	"Leo Li" <leoyang.li@nxp.com>,
	"Tony Prisk" <linux@prisktech.co.nz>,
	"Vinod Koul" <vkoul@kernel.org>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>, "Daniel Vetter" <daniel@ffwll.ch>,
	Keerthy <j-keerthy@ti.com>,
	dmaengine@vger.kernel.org, "Roy Pledge" <Roy.Pledge@nxp.com>,
	jyri.sarha@iki.fi, "David Miller" <davem@davemloft.net>
Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Tue, 20 Apr 2021 11:10:40 +0200	[thread overview]
Message-ID: <CAK8P3a1tPQm1Qj2KZu2jOM=TUP0dJgP4G9eKkWfv-PZEAWEhyA@mail.gmail.com> (raw)
In-Reply-To: <YH4VdPNO9cdzc5MD@atmark-techno.com>

On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
<dominique.martinet@atmark-techno.com> wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
> > For loadable modules, this is up to user space in the end.
> >
> > Which of the drivers in this scenario are loadable modules?
>
> All the drivers involved in my case are built-in (nvmem, soc and final
> soc_device_match consumer e.g. caam_jr that crashes the kernel if soc is
> not identified properly).

Ok, in that case you may have a chance to just adapt the initcall
levels. This is somewhat fragile if someone else already relies
on a particular order, but it's an easy one-line change to change
a driver e.g. from module_init() or device_initcall() to arch_initcall().

> I frankly don't like the idea of moving nvmem/ above soc/ in
> drivers/Makefile as a "solution" to this (especially as there is one
> that seems to care about what soc they run on...), so I'll have a look
> at links first, hopefully that will work out.

Right, that would be way more fragile.

I think the main problem in this case is the caam driver that really
should not look into the particular SoC type or even machine
compatible string. This is something we can do as a last resort
for compatibility with busted devicetree files, but it appears that
this driver does it as the primary method for identifying different
hardware revisions. I would suggest fixing the binding so that
each SoC that includes one of these devices has a soc specific
compatible string associated with the device that the driver can
use as the primary way of identifying the device.

We probably need to keep the old logic around for old dtb files,
but there can at least be a comment next to that table that
discourages people from adding more entries there.

      Arnd
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>
Cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>,
	gregkh <gregkh@linuxfoundation.org>,
	"Rafael Wysocki" <rafael@kernel.org>,
	"Horia Geantă" <horia.geanta@nxp.com>,
	aymen.sghaier@nxp.com, "Herbert Xu" <herbert@gondor.apana.org.au>,
	"David Miller" <davem@davemloft.net>,
	"Tony Lindgren" <tony@atomide.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Vinod Koul" <vkoul@kernel.org>,
	peter.ujfalusi@gmail.com, "Andrzej Hajda" <a.hajda@samsung.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Robert Foss" <robert.foss@linaro.org>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Kevin Hilman" <khilman@baylibre.com>,
	tomba@kernel.org, jyri.sarha@iki.fi,
	"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>, Kishon <kishon@ti.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Roy Pledge" <Roy.Pledge@nxp.com>, "Leo Li" <leoyang.li@nxp.com>,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Eduardo Valentin" <edubezval@gmail.com>,
	Keerthy <j-keerthy@ti.com>, "Felipe Balbi" <balbi@kernel.org>,
	"Tony Prisk" <linux@prisktech.co.nz>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	dmaengine@vger.kernel.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"open list:ARM/Amlogic Meson SoC support"
	<linux-amlogic@lists.infradead.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	linux-phy@lists.infradead.org,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-staging@lists.linux.dev,
	"moderated list:ARM/Mediatek SoC..."
	<linux-mediatek@lists.infradead.org>,
	"Linux PM list" <linux-pm@vger.kernel.org>,
	"USB list" <linux-usb@vger.kernel.org>,
	LINUXWATCHDOG <linux-watchdog@vger.kernel.org>
Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Tue, 20 Apr 2021 11:10:40 +0200	[thread overview]
Message-ID: <CAK8P3a1tPQm1Qj2KZu2jOM=TUP0dJgP4G9eKkWfv-PZEAWEhyA@mail.gmail.com> (raw)
In-Reply-To: <YH4VdPNO9cdzc5MD@atmark-techno.com>

On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
<dominique.martinet@atmark-techno.com> wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
> > For loadable modules, this is up to user space in the end.
> >
> > Which of the drivers in this scenario are loadable modules?
>
> All the drivers involved in my case are built-in (nvmem, soc and final
> soc_device_match consumer e.g. caam_jr that crashes the kernel if soc is
> not identified properly).

Ok, in that case you may have a chance to just adapt the initcall
levels. This is somewhat fragile if someone else already relies
on a particular order, but it's an easy one-line change to change
a driver e.g. from module_init() or device_initcall() to arch_initcall().

> I frankly don't like the idea of moving nvmem/ above soc/ in
> drivers/Makefile as a "solution" to this (especially as there is one
> that seems to care about what soc they run on...), so I'll have a look
> at links first, hopefully that will work out.

Right, that would be way more fragile.

I think the main problem in this case is the caam driver that really
should not look into the particular SoC type or even machine
compatible string. This is something we can do as a last resort
for compatibility with busted devicetree files, but it appears that
this driver does it as the primary method for identifying different
hardware revisions. I would suggest fixing the binding so that
each SoC that includes one of these devices has a soc specific
compatible string associated with the device that the driver can
use as the primary way of identifying the device.

We probably need to keep the old logic around for old dtb files,
but there can at least be a comment next to that table that
discourages people from adding more entries there.

      Arnd

_______________________________________________
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: Arnd Bergmann <arnd@kernel.org>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>
Cc: "Ulf Hansson" <ulf.hansson@linaro.org>,
	aymen.sghaier@nxp.com,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Rafael Wysocki" <rafael@kernel.org>,
	"David Airlie" <airlied@linux.ie>,
	"Michael Turquette" <mturquette@baylibre.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Andrzej Hajda" <a.hajda@samsung.com>,
	Networking <netdev@vger.kernel.org>,
	linux-phy@lists.infradead.org, peter.ujfalusi@gmail.com,
	linux-clk <linux-clk@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Horia Geantă" <horia.geanta@nxp.com>,
	"Kevin Hilman" <khilman@baylibre.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	linux-staging@lists.linux.dev,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	Kishon <kishon@ti.com>, "Tony Lindgren" <tony@atomide.com>,
	linux-omap <linux-omap@vger.kernel.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	LINUXWATCHDOG <linux-watchdog@vger.kernel.org>,
	"Will Deacon" <will@kernel.org>,
	"Linux PM list" <linux-pm@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	"Eduardo Valentin" <edubezval@gmail.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	"moderated list:ARM/Mediatek SoC..."
	<linux-mediatek@lists.infradead.org>,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"open list:ARM/Amlogic Meson SoC support"
	<linux-amlogic@lists.infradead.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>,
	"Felipe Balbi" <balbi@kernel.org>,
	tomba@kernel.org, "Stephen Boyd" <sboyd@kernel.org>,
	gregkh <gregkh@linuxfoundation.org>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	"USB list" <linux-usb@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>,
	"Robert Foss" <robert.foss@linaro.org>,
	"Leo Li" <leoyang.li@nxp.com>,
	"Tony Prisk" <linux@prisktech.co.nz>,
	"Vinod Koul" <vkoul@kernel.org>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>, Keerthy <j-keerthy@ti.com>,
	dmaengine@vger.kernel.org, "Roy Pledge" <Roy.Pledge@nxp.com>,
	jyri.sarha@iki.fi, "David Miller" <davem@davemloft.net>
Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Tue, 20 Apr 2021 11:10:40 +0200	[thread overview]
Message-ID: <CAK8P3a1tPQm1Qj2KZu2jOM=TUP0dJgP4G9eKkWfv-PZEAWEhyA@mail.gmail.com> (raw)
In-Reply-To: <YH4VdPNO9cdzc5MD@atmark-techno.com>

On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
<dominique.martinet@atmark-techno.com> wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
> > For loadable modules, this is up to user space in the end.
> >
> > Which of the drivers in this scenario are loadable modules?
>
> All the drivers involved in my case are built-in (nvmem, soc and final
> soc_device_match consumer e.g. caam_jr that crashes the kernel if soc is
> not identified properly).

Ok, in that case you may have a chance to just adapt the initcall
levels. This is somewhat fragile if someone else already relies
on a particular order, but it's an easy one-line change to change
a driver e.g. from module_init() or device_initcall() to arch_initcall().

> I frankly don't like the idea of moving nvmem/ above soc/ in
> drivers/Makefile as a "solution" to this (especially as there is one
> that seems to care about what soc they run on...), so I'll have a look
> at links first, hopefully that will work out.

Right, that would be way more fragile.

I think the main problem in this case is the caam driver that really
should not look into the particular SoC type or even machine
compatible string. This is something we can do as a last resort
for compatibility with busted devicetree files, but it appears that
this driver does it as the primary method for identifying different
hardware revisions. I would suggest fixing the binding so that
each SoC that includes one of these devices has a soc specific
compatible string associated with the device that the driver can
use as the primary way of identifying the device.

We probably need to keep the old logic around for old dtb files,
but there can at least be a comment next to that table that
discourages people from adding more entries there.

      Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>
Cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>,
	gregkh <gregkh@linuxfoundation.org>,
	"Rafael Wysocki" <rafael@kernel.org>,
	"Horia Geantă" <horia.geanta@nxp.com>,
	aymen.sghaier@nxp.com, "Herbert Xu" <herbert@gondor.apana.org.au>,
	"David Miller" <davem@davemloft.net>,
	"Tony Lindgren" <tony@atomide.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Vinod Koul" <vkoul@kernel.org>,
	peter.ujfalusi@gmail.com, "Andrzej Hajda" <a.hajda@samsung.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Robert Foss" <robert.foss@linaro.org>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Kevin Hilman" <khilman@baylibre.com>,
	tomba@kernel.org, jyri.sarha@iki.fi,
	"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>, Kishon <kishon@ti.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Roy Pledge" <Roy.Pledge@nxp.com>, "Leo Li" <leoyang.li@nxp.com>,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Eduardo Valentin" <edubezval@gmail.com>,
	Keerthy <j-keerthy@ti.com>, "Felipe Balbi" <balbi@kernel.org>,
	"Tony Prisk" <linux@prisktech.co.nz>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	dmaengine@vger.kernel.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"open list:ARM/Amlogic Meson SoC support"
	<linux-amlogic@lists.infradead.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	linux-phy@lists.infradead.org,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-staging@lists.linux.dev,
	"moderated list:ARM/Mediatek SoC..."
	<linux-mediatek@lists.infradead.org>,
	"Linux PM list" <linux-pm@vger.kernel.org>,
	"USB list" <linux-usb@vger.kernel.org>,
	LINUXWATCHDOG <linux-watchdog@vger.kernel.org>
Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Tue, 20 Apr 2021 11:10:40 +0200	[thread overview]
Message-ID: <CAK8P3a1tPQm1Qj2KZu2jOM=TUP0dJgP4G9eKkWfv-PZEAWEhyA@mail.gmail.com> (raw)
In-Reply-To: <YH4VdPNO9cdzc5MD@atmark-techno.com>

On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
<dominique.martinet@atmark-techno.com> wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
> > For loadable modules, this is up to user space in the end.
> >
> > Which of the drivers in this scenario are loadable modules?
>
> All the drivers involved in my case are built-in (nvmem, soc and final
> soc_device_match consumer e.g. caam_jr that crashes the kernel if soc is
> not identified properly).

Ok, in that case you may have a chance to just adapt the initcall
levels. This is somewhat fragile if someone else already relies
on a particular order, but it's an easy one-line change to change
a driver e.g. from module_init() or device_initcall() to arch_initcall().

> I frankly don't like the idea of moving nvmem/ above soc/ in
> drivers/Makefile as a "solution" to this (especially as there is one
> that seems to care about what soc they run on...), so I'll have a look
> at links first, hopefully that will work out.

Right, that would be way more fragile.

I think the main problem in this case is the caam driver that really
should not look into the particular SoC type or even machine
compatible string. This is something we can do as a last resort
for compatibility with busted devicetree files, but it appears that
this driver does it as the primary method for identifying different
hardware revisions. I would suggest fixing the binding so that
each SoC that includes one of these devices has a soc specific
compatible string associated with the device that the driver can
use as the primary way of identifying the device.

We probably need to keep the old logic around for old dtb files,
but there can at least be a comment next to that table that
discourages people from adding more entries there.

      Arnd

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

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>
Cc: "Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>,
	gregkh <gregkh@linuxfoundation.org>,
	"Rafael Wysocki" <rafael@kernel.org>,
	"Horia Geantă" <horia.geanta@nxp.com>,
	aymen.sghaier@nxp.com, "Herbert Xu" <herbert@gondor.apana.org.au>,
	"David Miller" <davem@davemloft.net>,
	"Tony Lindgren" <tony@atomide.com>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Vinod Koul" <vkoul@kernel.org>,
	peter.ujfalusi@gmail.com, "Andrzej Hajda" <a.hajda@samsung.com>,
	"Neil Armstrong" <narmstrong@baylibre.com>,
	"Robert Foss" <robert.foss@linaro.org>,
	"David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Kevin Hilman" <khilman@baylibre.com>,
	tomba@kernel.org, jyri.sarha@iki.fi,
	"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Ulf Hansson" <ulf.hansson@linaro.org>,
	"Adrian Hunter" <adrian.hunter@intel.com>, Kishon <kishon@ti.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Roy Pledge" <Roy.Pledge@nxp.com>, "Leo Li" <leoyang.li@nxp.com>,
	"Santosh Shilimkar" <ssantosh@kernel.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Eduardo Valentin" <edubezval@gmail.com>,
	Keerthy <j-keerthy@ti.com>, "Felipe Balbi" <balbi@kernel.org>,
	"Tony Prisk" <linux@prisktech.co.nz>,
	"Alan Stern" <stern@rowland.harvard.edu>,
	"Wim Van Sebroeck" <wim@linux-watchdog.org>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	dmaengine@vger.kernel.org,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"open list:ARM/Amlogic Meson SoC support"
	<linux-amlogic@lists.infradead.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"open list:IOMMU DRIVERS" <iommu@lists.linux-foundation.org>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	linux-phy@lists.infradead.org,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-staging@lists.linux.dev,
	"moderated list:ARM/Mediatek SoC..."
	<linux-mediatek@lists.infradead.org>,
	"Linux PM list" <linux-pm@vger.kernel.org>,
	"USB list" <linux-usb@vger.kernel.org>,
	LINUXWATCHDOG <linux-watchdog@vger.kernel.org>
Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Tue, 20 Apr 2021 11:10:40 +0200	[thread overview]
Message-ID: <CAK8P3a1tPQm1Qj2KZu2jOM=TUP0dJgP4G9eKkWfv-PZEAWEhyA@mail.gmail.com> (raw)
In-Reply-To: <YH4VdPNO9cdzc5MD@atmark-techno.com>

On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
<dominique.martinet@atmark-techno.com> wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
> > For loadable modules, this is up to user space in the end.
> >
> > Which of the drivers in this scenario are loadable modules?
>
> All the drivers involved in my case are built-in (nvmem, soc and final
> soc_device_match consumer e.g. caam_jr that crashes the kernel if soc is
> not identified properly).

Ok, in that case you may have a chance to just adapt the initcall
levels. This is somewhat fragile if someone else already relies
on a particular order, but it's an easy one-line change to change
a driver e.g. from module_init() or device_initcall() to arch_initcall().

> I frankly don't like the idea of moving nvmem/ above soc/ in
> drivers/Makefile as a "solution" to this (especially as there is one
> that seems to care about what soc they run on...), so I'll have a look
> at links first, hopefully that will work out.

Right, that would be way more fragile.

I think the main problem in this case is the caam driver that really
should not look into the particular SoC type or even machine
compatible string. This is something we can do as a last resort
for compatibility with busted devicetree files, but it appears that
this driver does it as the primary method for identifying different
hardware revisions. I would suggest fixing the binding so that
each SoC that includes one of these devices has a soc specific
compatible string associated with the device that the driver can
use as the primary way of identifying the device.

We probably need to keep the old logic around for old dtb files,
but there can at least be a comment next to that table that
discourages people from adding more entries there.

      Arnd

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  parent reply	other threads:[~2021-04-20  9:11 UTC|newest]

Thread overview: 147+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-19  4:27 [RFC v1 PATCH 0/3] support soc_device_match to return -EPROBE_DEFER Alice Guo (OSS)
2021-04-19  4:27 ` Alice Guo (OSS)
2021-04-19  4:27 ` Alice Guo (OSS)
2021-04-19  4:27 ` Alice Guo (OSS)
2021-04-19  4:27 ` Alice Guo (OSS)
2021-04-19  4:27 ` Alice Guo (OSS)
2021-04-19  4:27 ` Alice Guo (OSS)
2021-04-19  4:27 ` [RFC v1 PATCH 1/3] drivers: soc: add support for soc_device_match returning -EPROBE_DEFER Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:49   ` Dominique MARTINET
2021-04-19  4:49     ` Dominique MARTINET
2021-04-19  4:49     ` Dominique MARTINET
2021-04-19  4:49     ` Dominique MARTINET
2021-04-19  4:49     ` Dominique MARTINET
2021-04-19  4:49     ` Dominique MARTINET
2021-04-19  4:49     ` Dominique MARTINET
2021-04-19  6:40     ` Alice Guo (OSS)
2021-04-19  6:40       ` Alice Guo (OSS)
2021-04-19  6:40       ` Alice Guo (OSS)
2021-04-19  6:40       ` Alice Guo (OSS)
2021-04-19  6:40       ` Alice Guo (OSS)
2021-04-19  6:40       ` Alice Guo (OSS)
2021-04-19  6:40       ` Alice Guo (OSS)
2021-04-19  6:40       ` Alice Guo (OSS)
2021-04-19  8:20   ` Geert Uytterhoeven
2021-04-19  8:20     ` Geert Uytterhoeven
2021-04-19  8:20     ` Geert Uytterhoeven
2021-04-19  8:20     ` Geert Uytterhoeven
2021-04-19  8:20     ` Geert Uytterhoeven
2021-04-19  8:20     ` Geert Uytterhoeven
2021-04-19  8:20     ` Geert Uytterhoeven
2021-04-19  8:20     ` Geert Uytterhoeven
2021-04-20 11:21     ` Dan Carpenter
2021-04-20 11:21       ` Dan Carpenter
2021-04-20 11:21       ` Dan Carpenter
2021-04-20 11:21       ` Dan Carpenter
2021-04-20 11:21       ` Dan Carpenter
2021-04-20 11:21       ` Dan Carpenter
2021-04-20 11:21       ` Dan Carpenter
2021-04-19  4:27 ` [RFC v1 PATCH 2/3] caam: add defer probe when the caam driver cannot identify SoC Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27 ` [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  4:27   ` Alice Guo (OSS)
2021-04-19  5:02   ` Leon Romanovsky
2021-04-19  5:02     ` Leon Romanovsky
2021-04-19  5:02     ` Leon Romanovsky
2021-04-19  5:02     ` Leon Romanovsky
2021-04-19  5:02     ` Leon Romanovsky
2021-04-19  5:02     ` Leon Romanovsky
2021-04-19  5:02     ` Leon Romanovsky
2021-04-19  6:46     ` Alice Guo (OSS)
2021-04-19  6:46       ` Alice Guo (OSS)
2021-04-19  6:46       ` Alice Guo (OSS)
2021-04-19  6:46       ` Alice Guo (OSS)
2021-04-19  6:46       ` Alice Guo (OSS)
2021-04-19  6:46       ` Alice Guo (OSS)
2021-04-19  6:46       ` Alice Guo (OSS)
2021-04-19  6:46       ` Alice Guo (OSS)
2021-04-19  5:02   ` Dominique MARTINET
2021-04-19  5:02     ` Dominique MARTINET
2021-04-19  5:02     ` Dominique MARTINET
2021-04-19  5:02     ` Dominique MARTINET
2021-04-19  5:02     ` Dominique MARTINET
2021-04-19  5:02     ` Dominique MARTINET
2021-04-19  5:02     ` Dominique MARTINET
2021-04-19  7:09     ` Alice Guo (OSS)
2021-04-19  7:09       ` Alice Guo (OSS)
2021-04-19  7:09       ` Alice Guo (OSS)
2021-04-19  7:09       ` Alice Guo (OSS)
2021-04-19  7:09       ` Alice Guo (OSS)
2021-04-19  7:09       ` Alice Guo (OSS)
2021-04-19  7:09       ` Alice Guo (OSS)
2021-04-19  7:09       ` Alice Guo (OSS)
2021-04-19  9:03     ` Geert Uytterhoeven
2021-04-19  9:03       ` Geert Uytterhoeven
2021-04-19  9:03       ` Geert Uytterhoeven
2021-04-19  9:03       ` Geert Uytterhoeven
2021-04-19  9:03       ` Geert Uytterhoeven
2021-04-19  9:03       ` Geert Uytterhoeven
2021-04-19  9:03       ` Geert Uytterhoeven
2021-04-19  9:03       ` Geert Uytterhoeven
2021-04-19  9:33       ` Dominique MARTINET
2021-04-19  9:33         ` Dominique MARTINET
2021-04-19  9:33         ` Dominique MARTINET
2021-04-19  9:33         ` Dominique MARTINET
2021-04-19  9:33         ` Dominique MARTINET
2021-04-19  9:33         ` Dominique MARTINET
2021-04-19  9:33         ` Dominique MARTINET
2021-04-19 12:16         ` Arnd Bergmann
2021-04-19 12:16           ` Arnd Bergmann
2021-04-19 12:16           ` Arnd Bergmann
2021-04-19 12:16           ` Arnd Bergmann
2021-04-19 12:16           ` Arnd Bergmann
2021-04-19 12:16           ` Arnd Bergmann
2021-04-19 12:16           ` Arnd Bergmann
2021-04-19 23:42           ` Dominique MARTINET
2021-04-19 23:42             ` Dominique MARTINET
2021-04-19 23:42             ` Dominique MARTINET
2021-04-19 23:42             ` Dominique MARTINET
2021-04-19 23:42             ` Dominique MARTINET
2021-04-19 23:42             ` Dominique MARTINET
2021-04-19 23:42             ` Dominique MARTINET
2021-04-20  9:07             ` Arnd Bergmann
2021-04-20  9:07               ` Arnd Bergmann
2021-04-20  9:07               ` Arnd Bergmann
2021-04-20  9:07               ` Arnd Bergmann
2021-04-20  9:07               ` Arnd Bergmann
2021-04-20  9:07               ` Arnd Bergmann
2021-04-20  9:07               ` Arnd Bergmann
2021-04-20  9:10             ` Arnd Bergmann [this message]
2021-04-20  9:10               ` Arnd Bergmann
2021-04-20  9:10               ` Arnd Bergmann
2021-04-20  9:10               ` Arnd Bergmann
2021-04-20  9:10               ` Arnd Bergmann
2021-04-20  9:10               ` Arnd Bergmann
2021-04-20  9:10               ` Arnd Bergmann
2021-04-19  6:57   ` kernel test robot
2021-04-19  9:29   ` kernel test robot
2021-04-19 13:36   ` Guenter Roeck
2021-04-19 13:36     ` Guenter Roeck
2021-04-19 13:36     ` Guenter Roeck
2021-04-19 13:36     ` Guenter Roeck
2021-04-19 13:36     ` Guenter Roeck
2021-04-19 13:36     ` Guenter Roeck
2021-04-19 13:36     ` Guenter Roeck
2021-04-20  9:40   ` Péter Ujfalusi
2021-04-20  9:40     ` Péter Ujfalusi
2021-04-20  9:40     ` Péter Ujfalusi
2021-04-20  9:40     ` Péter Ujfalusi
2021-04-20  9:40     ` Péter Ujfalusi
2021-04-20  9:40     ` Péter Ujfalusi
2021-04-20  9:40     ` Péter Ujfalusi

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='CAK8P3a1tPQm1Qj2KZu2jOM=TUP0dJgP4G9eKkWfv-PZEAWEhyA@mail.gmail.com' \
    --to=arnd@kernel.org \
    --cc=Roy.Pledge@nxp.com \
    --cc=a.hajda@samsung.com \
    --cc=adrian.hunter@intel.com \
    --cc=airlied@linux.ie \
    --cc=alice.guo@oss.nxp.com \
    --cc=aymen.sghaier@nxp.com \
    --cc=balbi@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=davem@davemloft.net \
    --cc=dmaengine@vger.kernel.org \
    --cc=dominique.martinet@atmark-techno.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=edubezval@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=horia.geanta@nxp.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=j-keerthy@ti.com \
    --cc=joro@8bytes.org \
    --cc=jyri.sarha@iki.fi \
    --cc=khilman@baylibre.com \
    --cc=kishon@ti.com \
    --cc=kuba@kernel.org \
    --cc=leoyang.li@nxp.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@prisktech.co.nz \
    --cc=linux@roeck-us.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=narmstrong@baylibre.com \
    --cc=netdev@vger.kernel.org \
    --cc=peter.ujfalusi@gmail.com \
    --cc=rafael@kernel.org \
    --cc=robert.foss@linaro.org \
    --cc=sboyd@kernel.org \
    --cc=ssantosh@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=tomba@kernel.org \
    --cc=tony@atomide.com \
    --cc=ulf.hansson@linaro.org \
    --cc=vkoul@kernel.org \
    --cc=will@kernel.org \
    --cc=wim@linux-watchdog.org \
    /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.