All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: "Alice Guo (OSS)" <alice.guo@oss.nxp.com>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"rafael@kernel.org" <rafael@kernel.org>,
	Horia Geanta <horia.geanta@nxp.com>,
	Aymen Sghaier <aymen.sghaier@nxp.com>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"tony@atomide.com" <tony@atomide.com>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"peter.ujfalusi@gmail.com" <peter.ujfalusi@gmail.com>,
	"a.hajda@samsung.com" <a.hajda@samsung.com>,
	"narmstrong@baylibre.com" <narmstrong@baylibre.com>,
	"robert.foss@linaro.org" <robert.foss@linaro.org>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"khilman@baylibre.com" <khilman@baylibre.com>,
	"tomba@kernel.org" <tomba@kernel.org>,
	"jyri.sarha@iki.fi" <jyri.sarha@iki.fi>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"will@kernel.org" <will@kernel.org>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	"kishon@ti.com" <kishon@ti.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	Roy Pledge <roy.pledge@nxp.com>, Leo Li <leoyang.li@nxp.com>,
	"ssantosh@kernel.org" <ssantosh@kernel.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"edubezval@gmail.com" <edubezval@gmail.com>,
	"j-keerthy@ti.com" <j-keerthy@ti.com>,
	"balbi@kernel.org" <balbi@kernel.org>,
	"linux@prisktech.co.nz" <linux@prisktech.co.nz>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	"wim@linux-watchdog.org" <wim@linux-watchdog.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org" 
	<linux-renesas-soc@vger.kernel.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-amlogic@lists.infradead.org" 
	<linux-amlogic@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
	"linux-mediatek@lists.infradead.org" 
	<linux-mediatek@lists.infradead.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>
Subject: RE: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Mon, 19 Apr 2021 07:09:35 +0000	[thread overview]
Message-ID: <AM6PR04MB6053B332D2FED8BD42C8642CE2499@AM6PR04MB6053.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <YH0O907dfGY9jQRZ@atmark-techno.com>



> -----Original Message-----
> From: Dominique MARTINET <dominique.martinet@atmark-techno.com>
> Sent: 2021年4月19日 13:03
> To: Alice Guo (OSS) <alice.guo@oss.nxp.com>
> Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use
> soc_device_match
> 
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo <alice.guo@nxp.com>
> >
> > Update all the code that use soc_device_match
> 
> A single patch might be difficult to accept for all components, a each maintainer
> will probably want to have a say on their subsystem?
> 
> I would suggest to split these for a non-RFC version; a this will really need to be
> case-by-case handling.
> 
> > because add support for soc_device_match returning -EPROBE_DEFER.
> 
> (English does not parse here for me)
> 
> I've only commented a couple of places in the code itself, but this doesn't seem
> to add much support for errors, just sweep the problem under the rug.
> 
> > Signed-off-by: Alice Guo <alice.guo@nxp.com>
> > ---
> >
> > diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c index
> > 5fae60f8c135..00c59aa217c1 100644
> > --- a/drivers/bus/ti-sysc.c
> > +++ b/drivers/bus/ti-sysc.c
> > @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> >  	}
> >
> >  	match = soc_device_match(sysc_soc_feat_match);
> > -	if (!match)
> > +	if (!match || IS_ERR(match))
> >  		return 0;
> 
> This function handles errors, I would recommend returning the error as is if
> soc_device_match returned one so the probe can be retried later.
> 
> >
> >  	if (match->data)
> > diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > index c32d2c678046..90a18336a4c3 100644
> > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[]
> > __initconst = {
> >
> >  static int __init r8a7795_cpg_mssr_init(struct device *dev)  {
> > +	const struct soc_device_attribute *match;
> >  	const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> >  	u32 cpg_mode;
> >  	int error;
> > @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device
> *dev)
> >  		return -EINVAL;
> >  	}
> >
> > -	if (soc_device_match(r8a7795es1)) {
> > +	match = soc_device_match(r8a7795es1);
> > +	if (!IS_ERR(match) && match) {
> 
> Same, return the error.
> Assuming an error means no match will just lead to hard to debug problems
> because the driver potentially assumed the wrong device when it's just not
> ready yet.
> 
> >  		cpg_core_nullify_range(r8a7795_core_clks,
> >  				       ARRAY_SIZE(r8a7795_core_clks),
> >  				       R8A7795_CLK_S0D2, R8A7795_CLK_S0D12); [...]
> diff --git
> > a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index
> > eaaec0a55cc6..13a06b613379 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -757,17 +757,20 @@ static const char * const devices_allowlist[] =
> > {
> >
> >  static bool ipmmu_device_is_allowed(struct device *dev)  {
> > +	const struct soc_device_attribute *match1, *match2;
> >  	unsigned int i;
> >
> >  	/*
> >  	 * R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> >  	 * For Other SoCs, this returns true anyway.
> >  	 */
> > -	if (!soc_device_match(soc_needs_opt_in))
> > +	match1 = soc_device_match(soc_needs_opt_in);
> > +	if (!IS_ERR(match1) && !match1)
> 
> I'm not sure what you intended to do, but !match1 already means there is no
> error so the original code is identical.
> 
> In this case ipmmu_device_is_allowed does not allow errors so this is one of the
> "difficult" drivers that require slightly more thinking.
> It is only called in ipmmu_of_xlate which does return errors properly, so in this
> case the most straightforward approach would be to make
> ipmmu_device_is_allowed return an int and forward errors as well.
> 

I will reconsider the existing problems. Thank you for your advice

> 
> ...
> This is going to need quite some more work to be acceptable, in my opinion, but
> I think it should be possible.
> 
> Thanks,
> --
> Dominique

WARNING: multiple messages have this Message-ID (diff)
From: "Alice Guo (OSS)" <alice.guo@oss.nxp.com>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>
Cc: "ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	Aymen Sghaier <aymen.sghaier@nxp.com>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"a.hajda@samsung.com" <a.hajda@samsung.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	"will@kernel.org" <will@kernel.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"wim@linux-watchdog.org" <wim@linux-watchdog.org>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	Horia Geanta <horia.geanta@nxp.com>,
	"khilman@baylibre.com" <khilman@baylibre.com>,
	"narmstrong@baylibre.com" <narmstrong@baylibre.com>,
	"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"peter.ujfalusi@gmail.com" <peter.ujfalusi@gmail.com>,
	"kishon@ti.com" <kishon@ti.com>,
	"tony@atomide.com" <tony@atomide.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	dl-linux-imx <linux-imx@nxp.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	Roy Pledge <roy.pledge@nxp.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"edubezval@gmail.com" <edubezval@gmail.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"ssantosh@kernel.org" <ssantosh@kernel.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"linux-amlogic@lists.infradead.org"
	<linux-amlogic@lists.infradead.org>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"balbi@kernel.org" <balbi@kernel.org>,
	"tomba@kernel.org" <tomba@kernel.org>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	"robert.foss@linaro.org" <robert.foss@linaro.org>,
	Leo Li <leoyang.li@nxp.com>,
	"linux@prisktech.co.nz" <linux@prisktech.co.nz>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"j-keerthy@ti.com" <j-keerthy@ti.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"jyri.sarha@iki.fi" <jyri.sarha@iki.fi>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: RE: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Mon, 19 Apr 2021 07:09:35 +0000	[thread overview]
Message-ID: <AM6PR04MB6053B332D2FED8BD42C8642CE2499@AM6PR04MB6053.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <YH0O907dfGY9jQRZ@atmark-techno.com>



> -----Original Message-----
> From: Dominique MARTINET <dominique.martinet@atmark-techno.com>
> Sent: 2021年4月19日 13:03
> To: Alice Guo (OSS) <alice.guo@oss.nxp.com>
> Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use
> soc_device_match
> 
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo <alice.guo@nxp.com>
> >
> > Update all the code that use soc_device_match
> 
> A single patch might be difficult to accept for all components, a each maintainer
> will probably want to have a say on their subsystem?
> 
> I would suggest to split these for a non-RFC version; a this will really need to be
> case-by-case handling.
> 
> > because add support for soc_device_match returning -EPROBE_DEFER.
> 
> (English does not parse here for me)
> 
> I've only commented a couple of places in the code itself, but this doesn't seem
> to add much support for errors, just sweep the problem under the rug.
> 
> > Signed-off-by: Alice Guo <alice.guo@nxp.com>
> > ---
> >
> > diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c index
> > 5fae60f8c135..00c59aa217c1 100644
> > --- a/drivers/bus/ti-sysc.c
> > +++ b/drivers/bus/ti-sysc.c
> > @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> >  	}
> >
> >  	match = soc_device_match(sysc_soc_feat_match);
> > -	if (!match)
> > +	if (!match || IS_ERR(match))
> >  		return 0;
> 
> This function handles errors, I would recommend returning the error as is if
> soc_device_match returned one so the probe can be retried later.
> 
> >
> >  	if (match->data)
> > diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > index c32d2c678046..90a18336a4c3 100644
> > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[]
> > __initconst = {
> >
> >  static int __init r8a7795_cpg_mssr_init(struct device *dev)  {
> > +	const struct soc_device_attribute *match;
> >  	const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> >  	u32 cpg_mode;
> >  	int error;
> > @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device
> *dev)
> >  		return -EINVAL;
> >  	}
> >
> > -	if (soc_device_match(r8a7795es1)) {
> > +	match = soc_device_match(r8a7795es1);
> > +	if (!IS_ERR(match) && match) {
> 
> Same, return the error.
> Assuming an error means no match will just lead to hard to debug problems
> because the driver potentially assumed the wrong device when it's just not
> ready yet.
> 
> >  		cpg_core_nullify_range(r8a7795_core_clks,
> >  				       ARRAY_SIZE(r8a7795_core_clks),
> >  				       R8A7795_CLK_S0D2, R8A7795_CLK_S0D12); [...]
> diff --git
> > a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index
> > eaaec0a55cc6..13a06b613379 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -757,17 +757,20 @@ static const char * const devices_allowlist[] =
> > {
> >
> >  static bool ipmmu_device_is_allowed(struct device *dev)  {
> > +	const struct soc_device_attribute *match1, *match2;
> >  	unsigned int i;
> >
> >  	/*
> >  	 * R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> >  	 * For Other SoCs, this returns true anyway.
> >  	 */
> > -	if (!soc_device_match(soc_needs_opt_in))
> > +	match1 = soc_device_match(soc_needs_opt_in);
> > +	if (!IS_ERR(match1) && !match1)
> 
> I'm not sure what you intended to do, but !match1 already means there is no
> error so the original code is identical.
> 
> In this case ipmmu_device_is_allowed does not allow errors so this is one of the
> "difficult" drivers that require slightly more thinking.
> It is only called in ipmmu_of_xlate which does return errors properly, so in this
> case the most straightforward approach would be to make
> ipmmu_device_is_allowed return an int and forward errors as well.
> 

I will reconsider the existing problems. Thank you for your advice

> 
> ...
> This is going to need quite some more work to be acceptable, in my opinion, but
> I think it should be possible.
> 
> Thanks,
> --
> Dominique
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: "Alice Guo (OSS)" <alice.guo@oss.nxp.com>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>
Cc: "ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	Aymen Sghaier <aymen.sghaier@nxp.com>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"a.hajda@samsung.com" <a.hajda@samsung.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	"will@kernel.org" <will@kernel.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"wim@linux-watchdog.org" <wim@linux-watchdog.org>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	Horia Geanta <horia.geanta@nxp.com>,
	"khilman@baylibre.com" <khilman@baylibre.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"narmstrong@baylibre.com" <narmstrong@baylibre.com>,
	"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"peter.ujfalusi@gmail.com" <peter.ujfalusi@gmail.com>,
	"kishon@ti.com" <kishon@ti.com>,
	"tony@atomide.com" <tony@atomide.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	dl-linux-imx <linux-imx@nxp.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	Roy Pledge <roy.pledge@nxp.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"edubezval@gmail.com" <edubezval@gmail.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"ssantosh@kernel.org" <ssantosh@kernel.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"linux-amlogic@lists.infradead.org"
	<linux-amlogic@lists.infradead.org>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"balbi@kernel.org" <balbi@kernel.org>,
	"tomba@kernel.org" <tomba@kernel.org>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	"robert.foss@linaro.org" <robert.foss@linaro.org>,
	Leo Li <leoyang.li@nxp.com>,
	"linux@prisktech.co.nz" <linux@prisktech.co.nz>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"j-keerthy@ti.com" <j-keerthy@ti.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"jyri.sarha@iki.fi" <jyri.sarha@iki.fi>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: RE: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Mon, 19 Apr 2021 07:09:35 +0000	[thread overview]
Message-ID: <AM6PR04MB6053B332D2FED8BD42C8642CE2499@AM6PR04MB6053.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <YH0O907dfGY9jQRZ@atmark-techno.com>



> -----Original Message-----
> From: Dominique MARTINET <dominique.martinet@atmark-techno.com>
> Sent: 2021年4月19日 13:03
> To: Alice Guo (OSS) <alice.guo@oss.nxp.com>
> Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use
> soc_device_match
> 
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo <alice.guo@nxp.com>
> >
> > Update all the code that use soc_device_match
> 
> A single patch might be difficult to accept for all components, a each maintainer
> will probably want to have a say on their subsystem?
> 
> I would suggest to split these for a non-RFC version; a this will really need to be
> case-by-case handling.
> 
> > because add support for soc_device_match returning -EPROBE_DEFER.
> 
> (English does not parse here for me)
> 
> I've only commented a couple of places in the code itself, but this doesn't seem
> to add much support for errors, just sweep the problem under the rug.
> 
> > Signed-off-by: Alice Guo <alice.guo@nxp.com>
> > ---
> >
> > diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c index
> > 5fae60f8c135..00c59aa217c1 100644
> > --- a/drivers/bus/ti-sysc.c
> > +++ b/drivers/bus/ti-sysc.c
> > @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> >  	}
> >
> >  	match = soc_device_match(sysc_soc_feat_match);
> > -	if (!match)
> > +	if (!match || IS_ERR(match))
> >  		return 0;
> 
> This function handles errors, I would recommend returning the error as is if
> soc_device_match returned one so the probe can be retried later.
> 
> >
> >  	if (match->data)
> > diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > index c32d2c678046..90a18336a4c3 100644
> > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[]
> > __initconst = {
> >
> >  static int __init r8a7795_cpg_mssr_init(struct device *dev)  {
> > +	const struct soc_device_attribute *match;
> >  	const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> >  	u32 cpg_mode;
> >  	int error;
> > @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device
> *dev)
> >  		return -EINVAL;
> >  	}
> >
> > -	if (soc_device_match(r8a7795es1)) {
> > +	match = soc_device_match(r8a7795es1);
> > +	if (!IS_ERR(match) && match) {
> 
> Same, return the error.
> Assuming an error means no match will just lead to hard to debug problems
> because the driver potentially assumed the wrong device when it's just not
> ready yet.
> 
> >  		cpg_core_nullify_range(r8a7795_core_clks,
> >  				       ARRAY_SIZE(r8a7795_core_clks),
> >  				       R8A7795_CLK_S0D2, R8A7795_CLK_S0D12); [...]
> diff --git
> > a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index
> > eaaec0a55cc6..13a06b613379 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -757,17 +757,20 @@ static const char * const devices_allowlist[] =
> > {
> >
> >  static bool ipmmu_device_is_allowed(struct device *dev)  {
> > +	const struct soc_device_attribute *match1, *match2;
> >  	unsigned int i;
> >
> >  	/*
> >  	 * R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> >  	 * For Other SoCs, this returns true anyway.
> >  	 */
> > -	if (!soc_device_match(soc_needs_opt_in))
> > +	match1 = soc_device_match(soc_needs_opt_in);
> > +	if (!IS_ERR(match1) && !match1)
> 
> I'm not sure what you intended to do, but !match1 already means there is no
> error so the original code is identical.
> 
> In this case ipmmu_device_is_allowed does not allow errors so this is one of the
> "difficult" drivers that require slightly more thinking.
> It is only called in ipmmu_of_xlate which does return errors properly, so in this
> case the most straightforward approach would be to make
> ipmmu_device_is_allowed return an int and forward errors as well.
> 

I will reconsider the existing problems. Thank you for your advice

> 
> ...
> This is going to need quite some more work to be acceptable, in my opinion, but
> I think it should be possible.
> 
> Thanks,
> --
> Dominique
_______________________________________________
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: "Alice Guo (OSS)" <alice.guo@oss.nxp.com>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"rafael@kernel.org" <rafael@kernel.org>,
	Horia Geanta <horia.geanta@nxp.com>,
	 Aymen Sghaier <aymen.sghaier@nxp.com>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"tony@atomide.com" <tony@atomide.com>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"peter.ujfalusi@gmail.com" <peter.ujfalusi@gmail.com>,
	"a.hajda@samsung.com" <a.hajda@samsung.com>,
	"narmstrong@baylibre.com" <narmstrong@baylibre.com>,
	"robert.foss@linaro.org" <robert.foss@linaro.org>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"khilman@baylibre.com" <khilman@baylibre.com>,
	"tomba@kernel.org" <tomba@kernel.org>,
	"jyri.sarha@iki.fi" <jyri.sarha@iki.fi>,
	"joro@8bytes.org" <joro@8bytes.org>,
	 "will@kernel.org" <will@kernel.org>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	"kishon@ti.com" <kishon@ti.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	Roy Pledge <roy.pledge@nxp.com>, Leo Li <leoyang.li@nxp.com>,
	"ssantosh@kernel.org" <ssantosh@kernel.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"edubezval@gmail.com" <edubezval@gmail.com>,
	"j-keerthy@ti.com" <j-keerthy@ti.com>,
	"balbi@kernel.org" <balbi@kernel.org>,
	"linux@prisktech.co.nz" <linux@prisktech.co.nz>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	"wim@linux-watchdog.org" <wim@linux-watchdog.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-amlogic@lists.infradead.org"
	<linux-amlogic@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>
Subject: RE: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Mon, 19 Apr 2021 07:09:35 +0000	[thread overview]
Message-ID: <AM6PR04MB6053B332D2FED8BD42C8642CE2499@AM6PR04MB6053.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <YH0O907dfGY9jQRZ@atmark-techno.com>



> -----Original Message-----
> From: Dominique MARTINET <dominique.martinet@atmark-techno.com>
> Sent: 2021年4月19日 13:03
> To: Alice Guo (OSS) <alice.guo@oss.nxp.com>
> Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use
> soc_device_match
> 
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo <alice.guo@nxp.com>
> >
> > Update all the code that use soc_device_match
> 
> A single patch might be difficult to accept for all components, a each maintainer
> will probably want to have a say on their subsystem?
> 
> I would suggest to split these for a non-RFC version; a this will really need to be
> case-by-case handling.
> 
> > because add support for soc_device_match returning -EPROBE_DEFER.
> 
> (English does not parse here for me)
> 
> I've only commented a couple of places in the code itself, but this doesn't seem
> to add much support for errors, just sweep the problem under the rug.
> 
> > Signed-off-by: Alice Guo <alice.guo@nxp.com>
> > ---
> >
> > diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c index
> > 5fae60f8c135..00c59aa217c1 100644
> > --- a/drivers/bus/ti-sysc.c
> > +++ b/drivers/bus/ti-sysc.c
> > @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> >  	}
> >
> >  	match = soc_device_match(sysc_soc_feat_match);
> > -	if (!match)
> > +	if (!match || IS_ERR(match))
> >  		return 0;
> 
> This function handles errors, I would recommend returning the error as is if
> soc_device_match returned one so the probe can be retried later.
> 
> >
> >  	if (match->data)
> > diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > index c32d2c678046..90a18336a4c3 100644
> > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[]
> > __initconst = {
> >
> >  static int __init r8a7795_cpg_mssr_init(struct device *dev)  {
> > +	const struct soc_device_attribute *match;
> >  	const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> >  	u32 cpg_mode;
> >  	int error;
> > @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device
> *dev)
> >  		return -EINVAL;
> >  	}
> >
> > -	if (soc_device_match(r8a7795es1)) {
> > +	match = soc_device_match(r8a7795es1);
> > +	if (!IS_ERR(match) && match) {
> 
> Same, return the error.
> Assuming an error means no match will just lead to hard to debug problems
> because the driver potentially assumed the wrong device when it's just not
> ready yet.
> 
> >  		cpg_core_nullify_range(r8a7795_core_clks,
> >  				       ARRAY_SIZE(r8a7795_core_clks),
> >  				       R8A7795_CLK_S0D2, R8A7795_CLK_S0D12); [...]
> diff --git
> > a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index
> > eaaec0a55cc6..13a06b613379 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -757,17 +757,20 @@ static const char * const devices_allowlist[] =
> > {
> >
> >  static bool ipmmu_device_is_allowed(struct device *dev)  {
> > +	const struct soc_device_attribute *match1, *match2;
> >  	unsigned int i;
> >
> >  	/*
> >  	 * R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> >  	 * For Other SoCs, this returns true anyway.
> >  	 */
> > -	if (!soc_device_match(soc_needs_opt_in))
> > +	match1 = soc_device_match(soc_needs_opt_in);
> > +	if (!IS_ERR(match1) && !match1)
> 
> I'm not sure what you intended to do, but !match1 already means there is no
> error so the original code is identical.
> 
> In this case ipmmu_device_is_allowed does not allow errors so this is one of the
> "difficult" drivers that require slightly more thinking.
> It is only called in ipmmu_of_xlate which does return errors properly, so in this
> case the most straightforward approach would be to make
> ipmmu_device_is_allowed return an int and forward errors as well.
> 

I will reconsider the existing problems. Thank you for your advice

> 
> ...
> This is going to need quite some more work to be acceptable, in my opinion, but
> I think it should be possible.
> 
> Thanks,
> --
> Dominique
-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

WARNING: multiple messages have this Message-ID (diff)
From: "Alice Guo (OSS)" <alice.guo@oss.nxp.com>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"rafael@kernel.org" <rafael@kernel.org>,
	Horia Geanta <horia.geanta@nxp.com>,
	 Aymen Sghaier <aymen.sghaier@nxp.com>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"tony@atomide.com" <tony@atomide.com>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"peter.ujfalusi@gmail.com" <peter.ujfalusi@gmail.com>,
	"a.hajda@samsung.com" <a.hajda@samsung.com>,
	"narmstrong@baylibre.com" <narmstrong@baylibre.com>,
	"robert.foss@linaro.org" <robert.foss@linaro.org>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"khilman@baylibre.com" <khilman@baylibre.com>,
	"tomba@kernel.org" <tomba@kernel.org>,
	"jyri.sarha@iki.fi" <jyri.sarha@iki.fi>,
	"joro@8bytes.org" <joro@8bytes.org>,
	 "will@kernel.org" <will@kernel.org>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	"kishon@ti.com" <kishon@ti.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	Roy Pledge <roy.pledge@nxp.com>, Leo Li <leoyang.li@nxp.com>,
	"ssantosh@kernel.org" <ssantosh@kernel.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"edubezval@gmail.com" <edubezval@gmail.com>,
	"j-keerthy@ti.com" <j-keerthy@ti.com>,
	"balbi@kernel.org" <balbi@kernel.org>,
	"linux@prisktech.co.nz" <linux@prisktech.co.nz>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	"wim@linux-watchdog.org" <wim@linux-watchdog.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-amlogic@lists.infradead.org"
	<linux-amlogic@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>
Subject: RE: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Mon, 19 Apr 2021 07:09:35 +0000	[thread overview]
Message-ID: <AM6PR04MB6053B332D2FED8BD42C8642CE2499@AM6PR04MB6053.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <YH0O907dfGY9jQRZ@atmark-techno.com>



> -----Original Message-----
> From: Dominique MARTINET <dominique.martinet@atmark-techno.com>
> Sent: 2021年4月19日 13:03
> To: Alice Guo (OSS) <alice.guo@oss.nxp.com>
> Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use
> soc_device_match
> 
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo <alice.guo@nxp.com>
> >
> > Update all the code that use soc_device_match
> 
> A single patch might be difficult to accept for all components, a each maintainer
> will probably want to have a say on their subsystem?
> 
> I would suggest to split these for a non-RFC version; a this will really need to be
> case-by-case handling.
> 
> > because add support for soc_device_match returning -EPROBE_DEFER.
> 
> (English does not parse here for me)
> 
> I've only commented a couple of places in the code itself, but this doesn't seem
> to add much support for errors, just sweep the problem under the rug.
> 
> > Signed-off-by: Alice Guo <alice.guo@nxp.com>
> > ---
> >
> > diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c index
> > 5fae60f8c135..00c59aa217c1 100644
> > --- a/drivers/bus/ti-sysc.c
> > +++ b/drivers/bus/ti-sysc.c
> > @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> >  	}
> >
> >  	match = soc_device_match(sysc_soc_feat_match);
> > -	if (!match)
> > +	if (!match || IS_ERR(match))
> >  		return 0;
> 
> This function handles errors, I would recommend returning the error as is if
> soc_device_match returned one so the probe can be retried later.
> 
> >
> >  	if (match->data)
> > diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > index c32d2c678046..90a18336a4c3 100644
> > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[]
> > __initconst = {
> >
> >  static int __init r8a7795_cpg_mssr_init(struct device *dev)  {
> > +	const struct soc_device_attribute *match;
> >  	const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> >  	u32 cpg_mode;
> >  	int error;
> > @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device
> *dev)
> >  		return -EINVAL;
> >  	}
> >
> > -	if (soc_device_match(r8a7795es1)) {
> > +	match = soc_device_match(r8a7795es1);
> > +	if (!IS_ERR(match) && match) {
> 
> Same, return the error.
> Assuming an error means no match will just lead to hard to debug problems
> because the driver potentially assumed the wrong device when it's just not
> ready yet.
> 
> >  		cpg_core_nullify_range(r8a7795_core_clks,
> >  				       ARRAY_SIZE(r8a7795_core_clks),
> >  				       R8A7795_CLK_S0D2, R8A7795_CLK_S0D12); [...]
> diff --git
> > a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index
> > eaaec0a55cc6..13a06b613379 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -757,17 +757,20 @@ static const char * const devices_allowlist[] =
> > {
> >
> >  static bool ipmmu_device_is_allowed(struct device *dev)  {
> > +	const struct soc_device_attribute *match1, *match2;
> >  	unsigned int i;
> >
> >  	/*
> >  	 * R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> >  	 * For Other SoCs, this returns true anyway.
> >  	 */
> > -	if (!soc_device_match(soc_needs_opt_in))
> > +	match1 = soc_device_match(soc_needs_opt_in);
> > +	if (!IS_ERR(match1) && !match1)
> 
> I'm not sure what you intended to do, but !match1 already means there is no
> error so the original code is identical.
> 
> In this case ipmmu_device_is_allowed does not allow errors so this is one of the
> "difficult" drivers that require slightly more thinking.
> It is only called in ipmmu_of_xlate which does return errors properly, so in this
> case the most straightforward approach would be to make
> ipmmu_device_is_allowed return an int and forward errors as well.
> 

I will reconsider the existing problems. Thank you for your advice

> 
> ...
> This is going to need quite some more work to be acceptable, in my opinion, but
> I think it should be possible.
> 
> Thanks,
> --
> Dominique
_______________________________________________
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: "Alice Guo (OSS)" <alice.guo@oss.nxp.com>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>
Cc: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"rafael@kernel.org" <rafael@kernel.org>,
	Horia Geanta <horia.geanta@nxp.com>,
	 Aymen Sghaier <aymen.sghaier@nxp.com>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"tony@atomide.com" <tony@atomide.com>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"peter.ujfalusi@gmail.com" <peter.ujfalusi@gmail.com>,
	"a.hajda@samsung.com" <a.hajda@samsung.com>,
	"narmstrong@baylibre.com" <narmstrong@baylibre.com>,
	"robert.foss@linaro.org" <robert.foss@linaro.org>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"khilman@baylibre.com" <khilman@baylibre.com>,
	"tomba@kernel.org" <tomba@kernel.org>,
	"jyri.sarha@iki.fi" <jyri.sarha@iki.fi>,
	"joro@8bytes.org" <joro@8bytes.org>,
	 "will@kernel.org" <will@kernel.org>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	"kishon@ti.com" <kishon@ti.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	Roy Pledge <roy.pledge@nxp.com>, Leo Li <leoyang.li@nxp.com>,
	"ssantosh@kernel.org" <ssantosh@kernel.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"edubezval@gmail.com" <edubezval@gmail.com>,
	"j-keerthy@ti.com" <j-keerthy@ti.com>,
	"balbi@kernel.org" <balbi@kernel.org>,
	"linux@prisktech.co.nz" <linux@prisktech.co.nz>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	"wim@linux-watchdog.org" <wim@linux-watchdog.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-amlogic@lists.infradead.org"
	<linux-amlogic@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>
Subject: RE: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Mon, 19 Apr 2021 07:09:35 +0000	[thread overview]
Message-ID: <AM6PR04MB6053B332D2FED8BD42C8642CE2499@AM6PR04MB6053.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <YH0O907dfGY9jQRZ@atmark-techno.com>



> -----Original Message-----
> From: Dominique MARTINET <dominique.martinet@atmark-techno.com>
> Sent: 2021年4月19日 13:03
> To: Alice Guo (OSS) <alice.guo@oss.nxp.com>
> Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use
> soc_device_match
> 
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo <alice.guo@nxp.com>
> >
> > Update all the code that use soc_device_match
> 
> A single patch might be difficult to accept for all components, a each maintainer
> will probably want to have a say on their subsystem?
> 
> I would suggest to split these for a non-RFC version; a this will really need to be
> case-by-case handling.
> 
> > because add support for soc_device_match returning -EPROBE_DEFER.
> 
> (English does not parse here for me)
> 
> I've only commented a couple of places in the code itself, but this doesn't seem
> to add much support for errors, just sweep the problem under the rug.
> 
> > Signed-off-by: Alice Guo <alice.guo@nxp.com>
> > ---
> >
> > diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c index
> > 5fae60f8c135..00c59aa217c1 100644
> > --- a/drivers/bus/ti-sysc.c
> > +++ b/drivers/bus/ti-sysc.c
> > @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> >  	}
> >
> >  	match = soc_device_match(sysc_soc_feat_match);
> > -	if (!match)
> > +	if (!match || IS_ERR(match))
> >  		return 0;
> 
> This function handles errors, I would recommend returning the error as is if
> soc_device_match returned one so the probe can be retried later.
> 
> >
> >  	if (match->data)
> > diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > index c32d2c678046..90a18336a4c3 100644
> > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[]
> > __initconst = {
> >
> >  static int __init r8a7795_cpg_mssr_init(struct device *dev)  {
> > +	const struct soc_device_attribute *match;
> >  	const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> >  	u32 cpg_mode;
> >  	int error;
> > @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device
> *dev)
> >  		return -EINVAL;
> >  	}
> >
> > -	if (soc_device_match(r8a7795es1)) {
> > +	match = soc_device_match(r8a7795es1);
> > +	if (!IS_ERR(match) && match) {
> 
> Same, return the error.
> Assuming an error means no match will just lead to hard to debug problems
> because the driver potentially assumed the wrong device when it's just not
> ready yet.
> 
> >  		cpg_core_nullify_range(r8a7795_core_clks,
> >  				       ARRAY_SIZE(r8a7795_core_clks),
> >  				       R8A7795_CLK_S0D2, R8A7795_CLK_S0D12); [...]
> diff --git
> > a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index
> > eaaec0a55cc6..13a06b613379 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -757,17 +757,20 @@ static const char * const devices_allowlist[] =
> > {
> >
> >  static bool ipmmu_device_is_allowed(struct device *dev)  {
> > +	const struct soc_device_attribute *match1, *match2;
> >  	unsigned int i;
> >
> >  	/*
> >  	 * R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> >  	 * For Other SoCs, this returns true anyway.
> >  	 */
> > -	if (!soc_device_match(soc_needs_opt_in))
> > +	match1 = soc_device_match(soc_needs_opt_in);
> > +	if (!IS_ERR(match1) && !match1)
> 
> I'm not sure what you intended to do, but !match1 already means there is no
> error so the original code is identical.
> 
> In this case ipmmu_device_is_allowed does not allow errors so this is one of the
> "difficult" drivers that require slightly more thinking.
> It is only called in ipmmu_of_xlate which does return errors properly, so in this
> case the most straightforward approach would be to make
> ipmmu_device_is_allowed return an int and forward errors as well.
> 

I will reconsider the existing problems. Thank you for your advice

> 
> ...
> This is going to need quite some more work to be acceptable, in my opinion, but
> I think it should be possible.
> 
> Thanks,
> --
> Dominique
_______________________________________________
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: "Alice Guo (OSS)" <alice.guo@oss.nxp.com>
To: Dominique MARTINET <dominique.martinet@atmark-techno.com>,
	"Alice Guo (OSS)" <alice.guo@oss.nxp.com>
Cc: "ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	Aymen Sghaier <aymen.sghaier@nxp.com>,
	"geert+renesas@glider.be" <geert+renesas@glider.be>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"mturquette@baylibre.com" <mturquette@baylibre.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"a.hajda@samsung.com" <a.hajda@samsung.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
	"will@kernel.org" <will@kernel.org>,
	"linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>,
	"wim@linux-watchdog.org" <wim@linux-watchdog.org>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	Horia Geanta <horia.geanta@nxp.com>,
	"khilman@baylibre.com" <khilman@baylibre.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"narmstrong@baylibre.com" <narmstrong@baylibre.com>,
	"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"peter.ujfalusi@gmail.com" <peter.ujfalusi@gmail.com>,
	"kishon@ti.com" <kishon@ti.com>,
	"tony@atomide.com" <tony@atomide.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	dl-linux-imx <linux-imx@nxp.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>,
	Roy Pledge <roy.pledge@nxp.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"edubezval@gmail.com" <edubezval@gmail.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"ssantosh@kernel.org" <ssantosh@kernel.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"linux-amlogic@lists.infradead.org"
	<linux-amlogic@lists.infradead.org>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"balbi@kernel.org" <balbi@kernel.org>,
	"tomba@kernel.org" <tomba@kernel.org>,
	"sboyd@kernel.org" <sboyd@kernel.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	"robert.foss@linaro.org" <robert.foss@linaro.org>,
	Leo Li <leoyang.li@nxp.com>,
	"linux@prisktech.co.nz" <linux@prisktech.co.nz>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"j-keerthy@ti.com" <j-keerthy@ti.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"jyri.sarha@iki.fi" <jyri.sarha@iki.fi>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: RE: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match
Date: Mon, 19 Apr 2021 07:09:35 +0000	[thread overview]
Message-ID: <AM6PR04MB6053B332D2FED8BD42C8642CE2499@AM6PR04MB6053.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <YH0O907dfGY9jQRZ@atmark-techno.com>



> -----Original Message-----
> From: Dominique MARTINET <dominique.martinet@atmark-techno.com>
> Sent: 2021年4月19日 13:03
> To: Alice Guo (OSS) <alice.guo@oss.nxp.com>
> Subject: Re: [RFC v1 PATCH 3/3] driver: update all the code that use
> soc_device_match
> 
> Alice Guo (OSS) wrote on Mon, Apr 19, 2021 at 12:27:22PM +0800:
> > From: Alice Guo <alice.guo@nxp.com>
> >
> > Update all the code that use soc_device_match
> 
> A single patch might be difficult to accept for all components, a each maintainer
> will probably want to have a say on their subsystem?
> 
> I would suggest to split these for a non-RFC version; a this will really need to be
> case-by-case handling.
> 
> > because add support for soc_device_match returning -EPROBE_DEFER.
> 
> (English does not parse here for me)
> 
> I've only commented a couple of places in the code itself, but this doesn't seem
> to add much support for errors, just sweep the problem under the rug.
> 
> > Signed-off-by: Alice Guo <alice.guo@nxp.com>
> > ---
> >
> > diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c index
> > 5fae60f8c135..00c59aa217c1 100644
> > --- a/drivers/bus/ti-sysc.c
> > +++ b/drivers/bus/ti-sysc.c
> > @@ -2909,7 +2909,7 @@ static int sysc_init_soc(struct sysc *ddata)
> >  	}
> >
> >  	match = soc_device_match(sysc_soc_feat_match);
> > -	if (!match)
> > +	if (!match || IS_ERR(match))
> >  		return 0;
> 
> This function handles errors, I would recommend returning the error as is if
> soc_device_match returned one so the probe can be retried later.
> 
> >
> >  	if (match->data)
> > diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > index c32d2c678046..90a18336a4c3 100644
> > --- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > +++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
> > @@ -439,6 +439,7 @@ static const unsigned int r8a7795es2_mod_nullify[]
> > __initconst = {
> >
> >  static int __init r8a7795_cpg_mssr_init(struct device *dev)  {
> > +	const struct soc_device_attribute *match;
> >  	const struct rcar_gen3_cpg_pll_config *cpg_pll_config;
> >  	u32 cpg_mode;
> >  	int error;
> > @@ -453,7 +454,8 @@ static int __init r8a7795_cpg_mssr_init(struct device
> *dev)
> >  		return -EINVAL;
> >  	}
> >
> > -	if (soc_device_match(r8a7795es1)) {
> > +	match = soc_device_match(r8a7795es1);
> > +	if (!IS_ERR(match) && match) {
> 
> Same, return the error.
> Assuming an error means no match will just lead to hard to debug problems
> because the driver potentially assumed the wrong device when it's just not
> ready yet.
> 
> >  		cpg_core_nullify_range(r8a7795_core_clks,
> >  				       ARRAY_SIZE(r8a7795_core_clks),
> >  				       R8A7795_CLK_S0D2, R8A7795_CLK_S0D12); [...]
> diff --git
> > a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c index
> > eaaec0a55cc6..13a06b613379 100644
> > --- a/drivers/iommu/ipmmu-vmsa.c
> > +++ b/drivers/iommu/ipmmu-vmsa.c
> > @@ -757,17 +757,20 @@ static const char * const devices_allowlist[] =
> > {
> >
> >  static bool ipmmu_device_is_allowed(struct device *dev)  {
> > +	const struct soc_device_attribute *match1, *match2;
> >  	unsigned int i;
> >
> >  	/*
> >  	 * R-Car Gen3 and RZ/G2 use the allow list to opt-in devices.
> >  	 * For Other SoCs, this returns true anyway.
> >  	 */
> > -	if (!soc_device_match(soc_needs_opt_in))
> > +	match1 = soc_device_match(soc_needs_opt_in);
> > +	if (!IS_ERR(match1) && !match1)
> 
> I'm not sure what you intended to do, but !match1 already means there is no
> error so the original code is identical.
> 
> In this case ipmmu_device_is_allowed does not allow errors so this is one of the
> "difficult" drivers that require slightly more thinking.
> It is only called in ipmmu_of_xlate which does return errors properly, so in this
> case the most straightforward approach would be to make
> ipmmu_device_is_allowed return an int and forward errors as well.
> 

I will reconsider the existing problems. Thank you for your advice

> 
> ...
> This is going to need quite some more work to be acceptable, in my opinion, but
> I think it should be possible.
> 
> Thanks,
> --
> Dominique

  reply	other threads:[~2021-04-19  7:09 UTC|newest]

Thread overview: 142+ 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  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  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) [this message]
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: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
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=AM6PR04MB6053B332D2FED8BD42C8642CE2499@AM6PR04MB6053.eurprd04.prod.outlook.com \
    --to=alice.guo@oss.nxp.com \
    --cc=a.hajda@samsung.com \
    --cc=adrian.hunter@intel.com \
    --cc=airlied@linux.ie \
    --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=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-imx@nxp.com \
    --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=roy.pledge@nxp.com \
    --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.