* Re: Linux regressions report for mainline [2022-08-28]
2022-08-28 19:08 88% ` Thorsten Leemhuis
@ 2022-08-29 5:20 0% ` Greg KH
0 siblings, 0 replies; 25+ results
From: Greg KH @ 2022-08-29 5:20 UTC (permalink / raw)
To: Thorsten Leemhuis; +Cc: Linus Torvalds, LKML, Linux regressions mailing list
On Sun, Aug 28, 2022 at 09:08:12PM +0200, Thorsten Leemhuis wrote:
>
>
> On 28.08.22 20:41, Linus Torvalds wrote:
> > On Sun, Aug 28, 2022 at 11:23 AM Regzbot (on behalf of Thorsten
> > Leemhuis) <regressions@leemhuis.info> wrote:
> >>
> >> Not sure, maybe it would have been good if the following fix would have
> >> found the way into rc3, as it seems more than just one or two people
> >> already stumbled over the regression fixed by it:
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=master&id a8e0f6b01b14b2e28ba144e112c883f03a3db2
> >> https://lore.kernel.org/all/?qœbffc7*
> >
> > Neither of those links are valid for me.
> >
> > "a8e0f6b01b14b2e28ba144e112c883f03a3db2" doesn't exist in linux-next.
> > never mind that that isn't valid link syntax anyway.
> >
> > The lore.kernel.org link is also just random noise.
> >
> > So I'm not actually sure what you are trying to say...
>
> Sorry, you are right, I did something really stupid when preparing the
> mail (I manually modified one that was ready so send and already
> encoded...). Here are the links:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=master&id=13a8e0f6b01b14b2e28ba144e112c883f03a3db2
> https://lore.kernel.org/all/?q=9cbffc7*
>
> But I just noticed that's not the only stupid thing I did, as the linked
> commit in next (13a8e0f6b01b) is part of a series:
>
> https://lore.kernel.org/all/20220819221616.2107893-1-saravanak@google.com/
>
> The series fixes the regression "Regression: PM: domains: Delete usage
> of driver_deferred_probe_check_state" that is in the list from regzbot:
> https://lore.kernel.org/all/DU0PR04MB941735271F45C716342D0410886B9@DU0PR04MB9417.eurprd04.prod.outlook.com/
>
> But there are more reports, for example:
> https://lore.kernel.org/all/YvrkjH6%2FFpIzyAv+@euler/
>
> Not sure if Greg didn't sent them to you because he think they need more
> time or because he's simply afk/busy and didn't manage to send pull
> requests.
I was busy, will get these out to Linus in the next few days.
thanks,
greg k-h
^ permalink raw reply [relevance 0%]
* Re: Linux regressions report for mainline [2022-08-28]
@ 2022-08-28 19:08 88% ` Thorsten Leemhuis
2022-08-29 5:20 0% ` Greg KH
0 siblings, 1 reply; 25+ results
From: Thorsten Leemhuis @ 2022-08-28 19:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: LKML, Linux regressions mailing list
On 28.08.22 20:41, Linus Torvalds wrote:
> On Sun, Aug 28, 2022 at 11:23 AM Regzbot (on behalf of Thorsten
> Leemhuis) <regressions@leemhuis.info> wrote:
>>
>> Not sure, maybe it would have been good if the following fix would have
>> found the way into rc3, as it seems more than just one or two people
>> already stumbled over the regression fixed by it:
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=master&id a8e0f6b01b14b2e28ba144e112c883f03a3db2
>> https://lore.kernel.org/all/?qœbffc7*
>
> Neither of those links are valid for me.
>
> "a8e0f6b01b14b2e28ba144e112c883f03a3db2" doesn't exist in linux-next.
> never mind that that isn't valid link syntax anyway.
>
> The lore.kernel.org link is also just random noise.
>
> So I'm not actually sure what you are trying to say...
Sorry, you are right, I did something really stupid when preparing the
mail (I manually modified one that was ready so send and already
encoded...). Here are the links:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=master&id=13a8e0f6b01b14b2e28ba144e112c883f03a3db2
https://lore.kernel.org/all/?q=9cbffc7*
But I just noticed that's not the only stupid thing I did, as the linked
commit in next (13a8e0f6b01b) is part of a series:
https://lore.kernel.org/all/20220819221616.2107893-1-saravanak@google.com/
The series fixes the regression "Regression: PM: domains: Delete usage
of driver_deferred_probe_check_state" that is in the list from regzbot:
https://lore.kernel.org/all/DU0PR04MB941735271F45C716342D0410886B9@DU0PR04MB9417.eurprd04.prod.outlook.com/
But there are more reports, for example:
https://lore.kernel.org/all/YvrkjH6%2FFpIzyAv+@euler/
Not sure if Greg didn't sent them to you because he think they need more
time or because he's simply afk/busy and didn't manage to send pull
requests.
Guess waiting another week won't do too much harm.
Ciao, Thorsten
^ permalink raw reply [relevance 88%]
* RE: [PATCH v2 1/4] Revert "driver core: Delete driver_deferred_probe_check_state()"
2022-08-19 22:16 99% ` [PATCH v2 1/4] Revert "driver core: Delete driver_deferred_probe_check_state()" Saravana Kannan
2022-08-22 20:34 0% ` Doug Anderson
@ 2022-08-23 9:02 0% ` Peng Fan
1 sibling, 0 replies; 25+ results
From: Peng Fan @ 2022-08-23 9:02 UTC (permalink / raw)
To: Saravana Kannan, Greg Kroah-Hartman, Rafael J. Wysocki,
Kevin Hilman, Ulf Hansson, Pavel Machek, Len Brown, Joerg Roedel,
Will Deacon, Robin Murphy, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Luca Weiss, Doug Anderson, Colin Foster, Tony Lindgren,
Alexander Stein, Naresh Kamboju, Geert Uytterhoeven,
Jean-Philippe Brucker, kernel-team, linux-kernel, linux-pm,
iommu, netdev
> Subject: [PATCH v2 1/4] Revert "driver core: Delete
> driver_deferred_probe_check_state()"
>
> This reverts commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b.
>
> There are a few more issues to fix that have been reported in the thread for
> the original series [1]. We'll need to fix those before this will work.
> So, revert it for now.
>
> [1] -
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.
> kernel.org%2Flkml%2F20220601070707.3946847-1-
> saravanak%40google.com%2F&data=05%7C01%7Cpeng.fan%40nxp.co
> m%7Ce9205a2ec9c049d2a68408da82307410%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C0%7C637965441862478527%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C3000%7C%7C%7C&sdata=tGjnNEQ6BwaNrxug9ceThYOlj0a3
> Gmds8qpwNcHf%2FH8%3D&reserved=0
>
> Fixes: 9cbffc7a5956 ("driver core: Delete
> driver_deferred_probe_check_state()")
> Reviewed-by: Tony Lindgren <tony@atomide.com>
> Tested-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
Tested-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/base/dd.c | 30 ++++++++++++++++++++++++++++++
> include/linux/device/driver.h | 1 +
> 2 files changed, 31 insertions(+)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c index
> 70f79fc71539..a8916d1bfdcb 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -274,12 +274,42 @@ static int __init
> deferred_probe_timeout_setup(char *str) }
> __setup("deferred_probe_timeout=", deferred_probe_timeout_setup);
>
> +/**
> + * driver_deferred_probe_check_state() - Check deferred probe state
> + * @dev: device to check
> + *
> + * Return:
> + * * -ENODEV if initcalls have completed and modules are disabled.
> + * * -ETIMEDOUT if the deferred probe timeout was set and has expired
> + * and modules are enabled.
> + * * -EPROBE_DEFER in other cases.
> + *
> + * Drivers or subsystems can opt-in to calling this function instead of
> +directly
> + * returning -EPROBE_DEFER.
> + */
> +int driver_deferred_probe_check_state(struct device *dev) {
> + if (!IS_ENABLED(CONFIG_MODULES) && initcalls_done) {
> + dev_warn(dev, "ignoring dependency for device, assuming
> no driver\n");
> + return -ENODEV;
> + }
> +
> + if (!driver_deferred_probe_timeout && initcalls_done) {
> + dev_warn(dev, "deferred probe timeout, ignoring
> dependency\n");
> + return -ETIMEDOUT;
> + }
> +
> + return -EPROBE_DEFER;
> +}
> +EXPORT_SYMBOL_GPL(driver_deferred_probe_check_state);
> +
> static void deferred_probe_timeout_work_func(struct work_struct *work)
> {
> struct device_private *p;
>
> fw_devlink_drivers_done();
>
> + driver_deferred_probe_timeout = 0;
> driver_deferred_probe_trigger();
> flush_work(&deferred_probe_work);
>
> diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
> index 7acaabde5396..2114d65b862f 100644
> --- a/include/linux/device/driver.h
> +++ b/include/linux/device/driver.h
> @@ -242,6 +242,7 @@ driver_find_device_by_acpi_dev(struct
> device_driver *drv, const void *adev)
>
> extern int driver_deferred_probe_timeout; void
> driver_deferred_probe_add(struct device *dev);
> +int driver_deferred_probe_check_state(struct device *dev);
> void driver_init(void);
>
> /**
> --
> 2.37.1.595.g718a3a8f04-goog
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/4] Revert "driver core: Delete driver_deferred_probe_check_state()"
2022-08-19 22:16 99% ` [PATCH v2 1/4] Revert "driver core: Delete driver_deferred_probe_check_state()" Saravana Kannan
@ 2022-08-22 20:34 0% ` Doug Anderson
2022-08-23 9:02 0% ` Peng Fan
1 sibling, 0 replies; 25+ results
From: Doug Anderson @ 2022-08-22 20:34 UTC (permalink / raw)
To: Saravana Kannan
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson,
Pavel Machek, Len Brown, Joerg Roedel, Will Deacon, Robin Murphy,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Peng Fan, Luca Weiss,
Colin Foster, Tony Lindgren, Alexander Stein, Naresh Kamboju,
Geert Uytterhoeven, Jean-Philippe Brucker, kernel-team, LKML,
Linux PM, iommu, netdev
Hi,
On Fri, Aug 19, 2022 at 3:16 PM Saravana Kannan <saravanak@google.com> wrote:
>
> This reverts commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b.
>
> There are a few more issues to fix that have been reported in the thread
> for the original series [1]. We'll need to fix those before this will work.
> So, revert it for now.
>
> [1] - https://lore.kernel.org/lkml/20220601070707.3946847-1-saravanak@google.com/
>
> Fixes: 9cbffc7a5956 ("driver core: Delete driver_deferred_probe_check_state()")
> Reviewed-by: Tony Lindgren <tony@atomide.com>
> Tested-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---
> drivers/base/dd.c | 30 ++++++++++++++++++++++++++++++
> include/linux/device/driver.h | 1 +
> 2 files changed, 31 insertions(+)
Tested-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply [relevance 0%]
* [PATCH v2 1/4] Revert "driver core: Delete driver_deferred_probe_check_state()"
@ 2022-08-19 22:16 99% ` Saravana Kannan
2022-08-22 20:34 0% ` Doug Anderson
2022-08-23 9:02 0% ` Peng Fan
0 siblings, 2 replies; 25+ results
From: Saravana Kannan @ 2022-08-19 22:16 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson,
Pavel Machek, Len Brown, Joerg Roedel, Will Deacon, Robin Murphy,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Saravana Kannan
Cc: Peng Fan, Luca Weiss, Doug Anderson, Colin Foster, Tony Lindgren,
Alexander Stein, Naresh Kamboju, Geert Uytterhoeven,
Jean-Philippe Brucker, kernel-team, linux-kernel, linux-pm,
iommu, netdev
This reverts commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b.
There are a few more issues to fix that have been reported in the thread
for the original series [1]. We'll need to fix those before this will work.
So, revert it for now.
[1] - https://lore.kernel.org/lkml/20220601070707.3946847-1-saravanak@google.com/
Fixes: 9cbffc7a5956 ("driver core: Delete driver_deferred_probe_check_state()")
Reviewed-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
drivers/base/dd.c | 30 ++++++++++++++++++++++++++++++
include/linux/device/driver.h | 1 +
2 files changed, 31 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 70f79fc71539..a8916d1bfdcb 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -274,12 +274,42 @@ static int __init deferred_probe_timeout_setup(char *str)
}
__setup("deferred_probe_timeout=", deferred_probe_timeout_setup);
+/**
+ * driver_deferred_probe_check_state() - Check deferred probe state
+ * @dev: device to check
+ *
+ * Return:
+ * * -ENODEV if initcalls have completed and modules are disabled.
+ * * -ETIMEDOUT if the deferred probe timeout was set and has expired
+ * and modules are enabled.
+ * * -EPROBE_DEFER in other cases.
+ *
+ * Drivers or subsystems can opt-in to calling this function instead of directly
+ * returning -EPROBE_DEFER.
+ */
+int driver_deferred_probe_check_state(struct device *dev)
+{
+ if (!IS_ENABLED(CONFIG_MODULES) && initcalls_done) {
+ dev_warn(dev, "ignoring dependency for device, assuming no driver\n");
+ return -ENODEV;
+ }
+
+ if (!driver_deferred_probe_timeout && initcalls_done) {
+ dev_warn(dev, "deferred probe timeout, ignoring dependency\n");
+ return -ETIMEDOUT;
+ }
+
+ return -EPROBE_DEFER;
+}
+EXPORT_SYMBOL_GPL(driver_deferred_probe_check_state);
+
static void deferred_probe_timeout_work_func(struct work_struct *work)
{
struct device_private *p;
fw_devlink_drivers_done();
+ driver_deferred_probe_timeout = 0;
driver_deferred_probe_trigger();
flush_work(&deferred_probe_work);
diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
index 7acaabde5396..2114d65b862f 100644
--- a/include/linux/device/driver.h
+++ b/include/linux/device/driver.h
@@ -242,6 +242,7 @@ driver_find_device_by_acpi_dev(struct device_driver *drv, const void *adev)
extern int driver_deferred_probe_timeout;
void driver_deferred_probe_add(struct device *dev);
+int driver_deferred_probe_check_state(struct device *dev);
void driver_init(void);
/**
--
2.37.1.595.g718a3a8f04-goog
^ permalink raw reply related [relevance 99%]
* RE: Regression: PM: domains: Delete usage of driver_deferred_probe_check_state
2022-08-18 18:08 0% ` Saravana Kannan
@ 2022-08-19 9:00 0% ` Peng Fan
-1 siblings, 0 replies; 25+ results
From: Peng Fan @ 2022-08-19 9:00 UTC (permalink / raw)
To: Saravana Kannan
Cc: linux-arm-kernel, dl-linux-imx, sudeep.holla, linux-pm,
Alice Guo, Bough Chen
> driver_deferred_probe_check_state
>
> On Mon, Aug 15, 2022 at 11:43 PM Peng Fan <peng.fan@nxp.com> wrote:
> >
> > > Subject: Regression: PM: domains: Delete usage of
> > > driver_deferred_probe_check_state
> >
> > Just see your patchset :)
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fall%2F20220727185012.3255200-1-
> saravanak%40google.com%2F
> >
> &data=05%7C01%7Cpeng.fan%40nxp.com%7C4bab1e117c1e46b8cba9
> 08da8144b
> >
> e22%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6379644294901
> 88104%7C
> >
> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik1h
> >
> aWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZHriJc2t88Dyjt79
> DomOMvDN5
> > 2JJAcgJUK6wfOVtS6I%3D&reserved=0
> >
> > Thanks,
> > Peng.
> > >
> > > Hi Saravana,
> > >
> > > The following two patches breaks NXP i.MX8ULP, but I think it may
> > > break others use SCMI.
> > >
> > > commit 5a46079a96451cfb15e4f5f01f73f7ba24ef851a
> > > Author: Saravana Kannan <mailto:saravanak@google.com>
> > > Date: Wed Jun 1 00:06:57 2022 -0700
> > >
> > > PM: domains: Delete usage of driver_deferred_probe_check_state()
> > >
> > > Now that fw_devlink=on by default and fw_devlink supports
> > > "power-domains" property, the execution will never get to the point
> > > where driver_deferred_probe_check_state() is called before the
> supplier
> > > has probed successfully or before deferred probe timeout has expired.
> > >
> > > So, delete the call and replace it with -ENODEV.
> > >
> > > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > > Reviewed-by: Ulf Hansson <mailto:ulf.hansson@linaro.org>
> > > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > > Link:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > > re.kernel.org%2Fr%2F20220601070707.3946847-2-
> &data=05%7C01%7Cpen
> > >
> g.fan%40nxp.com%7C4bab1e117c1e46b8cba908da8144be22%7C686ea1d3b
> c2b4c6
> > >
> fa92cd99c5c301635%7C0%7C0%7C637964429490188104%7CUnknown%7CT
> WFpbGZsb
> > >
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3
> > >
> D%7C3000%7C%7C%7C&sdata=k98c9AaiMDTpYkx1353btm%2BB2DA4y
> Q8PPjV0zI
> > > RPMsE%3D&reserved=0
> > > saravanak@google.com
> > > Signed-off-by: Greg Kroah-Hartman
> > > <mailto:gregkh@linuxfoundation.org>
> > >
> > > commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b
> > > Author: Saravana Kannan <mailto:saravanak@google.com>
> > > Date: Wed Jun 1 00:07:05 2022 -0700
> > >
> > > driver core: Delete driver_deferred_probe_check_state()
> > >
> > > The function is no longer used. So delete it.
> > >
> > > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > > Link:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > > re.kernel.org%2Fr%2F20220601070707.3946847-10-
> &data=05%7C01%7Cpe
> > >
> ng.fan%40nxp.com%7C4bab1e117c1e46b8cba908da8144be22%7C686ea1d3
> bc2b4c
> > >
> 6fa92cd99c5c301635%7C0%7C0%7C637964429490188104%7CUnknown%7C
> TWFpbGZs
> > >
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%
> > >
> 3D%7C3000%7C%7C%7C&sdata=pG64f9hJO9pAhCQ4v8txcD5LA3VXQu
> 8IsVYr4Sb
> > > 5Id8%3D&reserved=0
> > > saravanak@google.com
> > > Signed-off-by: Greg Kroah-Hartman
> > > <mailto:gregkh@linuxfoundation.org>
> > >
> > > The i.MX8ULP mmc device node use
> > > "power-domains = <&scmi_devpd IMX8ULP_PD_USDHC0>;"
> > >
> > > The scmi firmware node as below:
> > > firmware {
> > > scmi {
> > > compatible = "arm,scmi-smc";
> > > arm,smc-id = <0xc20000fe>;
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > shmem = <&scmi_buf>;
> > >
> > > scmi_devpd: protocol@11 {
> > > reg = <0x11>;
> > > #power-domain-cells = <1>;
> > > };
> > >
> > > scmi_sensor: protocol@15 {
> > > reg = <0x15>;
> > > #thermal-sensor-cells = <1>;
> > > };
> > > };
> > > };
> > >
> > > When sdhc driver probe, the scmi power domain provider has not been
> > > registered. So __genpd_dev_pm_attach directly return -ENODEV.
> > >
> > > device_links_check_suppliers should already check suppliers, but
> > > scmi protocol device not have compatible, so of_link_to_phandle
> > > |-> of_get_compat_node
> > > use the parent node of scmi protocol as supplier if I understand correct.
> > >
> > > I am not sure whether we need to revert the above two patches, or do
> > > you have other suggestions?
>
> Hi Peng,
>
> Thanks for the report. If you try this series with the following diff, I expect it
> to fix the issue for you. Can you please test it out and let me know? The v1
> of the series removes the dependency on "compatible" strings. The first diff
> below is something I'm going to roll into v2 of the series and the 2nd diff
> below is fixing up the scmi bus to set the fwnode for devices it creates.
>
> Thanks,
> Saravana
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.
> kernel.org%2Flkml%2F20220810060040.321697-1-
> saravanak%40google.com%2F&data=05%7C01%7Cpeng.fan%40nxp.co
> m%7C4bab1e117c1e46b8cba908da8144be22%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C637964429490344320%7CUnknown%7CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000%7C%7C%7C&sdata=ZIJqjOJb80tBKhEvCa8ZilQQY0OF
> LZBuon6H5A7%2FeRU%3D&reserved=0
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c index
> 2f012e826986..866755d8ad95 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2068,7 +2068,11 @@ static int fw_devlink_create_devlink(struct
> device *con,
> device_links_write_unlock();
> }
>
> - sup_dev = get_dev_from_fwnode(sup_handle);
> + if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE)
> + sup_dev = fwnode_get_next_parent_dev(sup_handle);
> + else
> + sup_dev = get_dev_from_fwnode(sup_handle);
> +
> if (sup_dev) {
> /*
> * If it's one of those drivers that don't actually bind to
>
>
> diff --git a/drivers/firmware/arm_scmi/bus.c
> b/drivers/firmware/arm_scmi/bus.c index d4e23101448a..0802bdd0ebfc
> 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -192,6 +192,7 @@ scmi_device_create(struct device_node *np, struct
> device *parent, int protocol,
> scmi_dev->protocol_id = protocol;
> scmi_dev->dev.parent = parent;
> scmi_dev->dev.of_node = np;
> + scmi_dev->dev.fwnode= of_fwnode_handle(np);
> scmi_dev->dev.bus = &scmi_bus_type;
> scmi_dev->dev.release = scmi_device_release;
> dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
The issue is
really_probe->device_links_check_suppliers
Because we use scmi protocol node as supplier, the supplier
is changed to firmware:scmi. So the supplier check pass.
However the protocol device is created later, before the protocol device
ready, the mmc device is probed and dev_pm_domain_attach
return error.
BTW, your patchset plus your new diff still not work.
[ 1.583526] arm-scmi firmware:scmi: Enabled polling mode TX channel - prot_id:16
[ 1.590775] device: 'firmware:scmi': device_add
[ 1.595256] arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
[ 1.601805] arm-scmi firmware:scmi: Malformed reply - real_sz:8 calc_sz:4 (loop_num_ret:2)
[ 1.610098] arm-scmi firmware:scmi: SCMI Protocol v2.0 'NXP:' Firmware version 0x0
[ 1.617731] mmc@298d0000 Linked as a fwnode consumer to scmi
[ 1.623279] mmc@298d0000 Dropping the fwnode link to protocol@11
[ 1.629270] fw_devlink_create_devlink 298d0000.mmc firmware:scmi
[ 1.635257] device: 'platform:firmware:scmi--platform:298d0000.mmc': device_add
[ 1.642590] devices_kset: Moving 298d0000.mmc to end of list
[ 1.648166] platform 298d0000.mmc: Linked as a consumer to firmware:scmi
[ 1.654840] mmc@298d0000 Dropping the fwnode link to scmi
Per log, mmc not take the protocol@11 as supplier in the end.
Regards,
Peng.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 0%]
* RE: Regression: PM: domains: Delete usage of driver_deferred_probe_check_state
@ 2022-08-19 9:00 0% ` Peng Fan
0 siblings, 0 replies; 25+ results
From: Peng Fan @ 2022-08-19 9:00 UTC (permalink / raw)
To: Saravana Kannan
Cc: linux-arm-kernel, dl-linux-imx, sudeep.holla, linux-pm,
Alice Guo, Bough Chen
> driver_deferred_probe_check_state
>
> On Mon, Aug 15, 2022 at 11:43 PM Peng Fan <peng.fan@nxp.com> wrote:
> >
> > > Subject: Regression: PM: domains: Delete usage of
> > > driver_deferred_probe_check_state
> >
> > Just see your patchset :)
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fall%2F20220727185012.3255200-1-
> saravanak%40google.com%2F
> >
> &data=05%7C01%7Cpeng.fan%40nxp.com%7C4bab1e117c1e46b8cba9
> 08da8144b
> >
> e22%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6379644294901
> 88104%7C
> >
> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik1h
> >
> aWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZHriJc2t88Dyjt79
> DomOMvDN5
> > 2JJAcgJUK6wfOVtS6I%3D&reserved=0
> >
> > Thanks,
> > Peng.
> > >
> > > Hi Saravana,
> > >
> > > The following two patches breaks NXP i.MX8ULP, but I think it may
> > > break others use SCMI.
> > >
> > > commit 5a46079a96451cfb15e4f5f01f73f7ba24ef851a
> > > Author: Saravana Kannan <mailto:saravanak@google.com>
> > > Date: Wed Jun 1 00:06:57 2022 -0700
> > >
> > > PM: domains: Delete usage of driver_deferred_probe_check_state()
> > >
> > > Now that fw_devlink=on by default and fw_devlink supports
> > > "power-domains" property, the execution will never get to the point
> > > where driver_deferred_probe_check_state() is called before the
> supplier
> > > has probed successfully or before deferred probe timeout has expired.
> > >
> > > So, delete the call and replace it with -ENODEV.
> > >
> > > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > > Reviewed-by: Ulf Hansson <mailto:ulf.hansson@linaro.org>
> > > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > > Link:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > > re.kernel.org%2Fr%2F20220601070707.3946847-2-
> &data=05%7C01%7Cpen
> > >
> g.fan%40nxp.com%7C4bab1e117c1e46b8cba908da8144be22%7C686ea1d3b
> c2b4c6
> > >
> fa92cd99c5c301635%7C0%7C0%7C637964429490188104%7CUnknown%7CT
> WFpbGZsb
> > >
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3
> > >
> D%7C3000%7C%7C%7C&sdata=k98c9AaiMDTpYkx1353btm%2BB2DA4y
> Q8PPjV0zI
> > > RPMsE%3D&reserved=0
> > > saravanak@google.com
> > > Signed-off-by: Greg Kroah-Hartman
> > > <mailto:gregkh@linuxfoundation.org>
> > >
> > > commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b
> > > Author: Saravana Kannan <mailto:saravanak@google.com>
> > > Date: Wed Jun 1 00:07:05 2022 -0700
> > >
> > > driver core: Delete driver_deferred_probe_check_state()
> > >
> > > The function is no longer used. So delete it.
> > >
> > > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > > Link:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > > re.kernel.org%2Fr%2F20220601070707.3946847-10-
> &data=05%7C01%7Cpe
> > >
> ng.fan%40nxp.com%7C4bab1e117c1e46b8cba908da8144be22%7C686ea1d3
> bc2b4c
> > >
> 6fa92cd99c5c301635%7C0%7C0%7C637964429490188104%7CUnknown%7C
> TWFpbGZs
> > >
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%
> > >
> 3D%7C3000%7C%7C%7C&sdata=pG64f9hJO9pAhCQ4v8txcD5LA3VXQu
> 8IsVYr4Sb
> > > 5Id8%3D&reserved=0
> > > saravanak@google.com
> > > Signed-off-by: Greg Kroah-Hartman
> > > <mailto:gregkh@linuxfoundation.org>
> > >
> > > The i.MX8ULP mmc device node use
> > > "power-domains = <&scmi_devpd IMX8ULP_PD_USDHC0>;"
> > >
> > > The scmi firmware node as below:
> > > firmware {
> > > scmi {
> > > compatible = "arm,scmi-smc";
> > > arm,smc-id = <0xc20000fe>;
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > shmem = <&scmi_buf>;
> > >
> > > scmi_devpd: protocol@11 {
> > > reg = <0x11>;
> > > #power-domain-cells = <1>;
> > > };
> > >
> > > scmi_sensor: protocol@15 {
> > > reg = <0x15>;
> > > #thermal-sensor-cells = <1>;
> > > };
> > > };
> > > };
> > >
> > > When sdhc driver probe, the scmi power domain provider has not been
> > > registered. So __genpd_dev_pm_attach directly return -ENODEV.
> > >
> > > device_links_check_suppliers should already check suppliers, but
> > > scmi protocol device not have compatible, so of_link_to_phandle
> > > |-> of_get_compat_node
> > > use the parent node of scmi protocol as supplier if I understand correct.
> > >
> > > I am not sure whether we need to revert the above two patches, or do
> > > you have other suggestions?
>
> Hi Peng,
>
> Thanks for the report. If you try this series with the following diff, I expect it
> to fix the issue for you. Can you please test it out and let me know? The v1
> of the series removes the dependency on "compatible" strings. The first diff
> below is something I'm going to roll into v2 of the series and the 2nd diff
> below is fixing up the scmi bus to set the fwnode for devices it creates.
>
> Thanks,
> Saravana
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.
> kernel.org%2Flkml%2F20220810060040.321697-1-
> saravanak%40google.com%2F&data=05%7C01%7Cpeng.fan%40nxp.co
> m%7C4bab1e117c1e46b8cba908da8144be22%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C637964429490344320%7CUnknown%7CTWFpbG
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000%7C%7C%7C&sdata=ZIJqjOJb80tBKhEvCa8ZilQQY0OF
> LZBuon6H5A7%2FeRU%3D&reserved=0
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c index
> 2f012e826986..866755d8ad95 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2068,7 +2068,11 @@ static int fw_devlink_create_devlink(struct
> device *con,
> device_links_write_unlock();
> }
>
> - sup_dev = get_dev_from_fwnode(sup_handle);
> + if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE)
> + sup_dev = fwnode_get_next_parent_dev(sup_handle);
> + else
> + sup_dev = get_dev_from_fwnode(sup_handle);
> +
> if (sup_dev) {
> /*
> * If it's one of those drivers that don't actually bind to
>
>
> diff --git a/drivers/firmware/arm_scmi/bus.c
> b/drivers/firmware/arm_scmi/bus.c index d4e23101448a..0802bdd0ebfc
> 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -192,6 +192,7 @@ scmi_device_create(struct device_node *np, struct
> device *parent, int protocol,
> scmi_dev->protocol_id = protocol;
> scmi_dev->dev.parent = parent;
> scmi_dev->dev.of_node = np;
> + scmi_dev->dev.fwnode= of_fwnode_handle(np);
> scmi_dev->dev.bus = &scmi_bus_type;
> scmi_dev->dev.release = scmi_device_release;
> dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
The issue is
really_probe->device_links_check_suppliers
Because we use scmi protocol node as supplier, the supplier
is changed to firmware:scmi. So the supplier check pass.
However the protocol device is created later, before the protocol device
ready, the mmc device is probed and dev_pm_domain_attach
return error.
BTW, your patchset plus your new diff still not work.
[ 1.583526] arm-scmi firmware:scmi: Enabled polling mode TX channel - prot_id:16
[ 1.590775] device: 'firmware:scmi': device_add
[ 1.595256] arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
[ 1.601805] arm-scmi firmware:scmi: Malformed reply - real_sz:8 calc_sz:4 (loop_num_ret:2)
[ 1.610098] arm-scmi firmware:scmi: SCMI Protocol v2.0 'NXP:' Firmware version 0x0
[ 1.617731] mmc@298d0000 Linked as a fwnode consumer to scmi
[ 1.623279] mmc@298d0000 Dropping the fwnode link to protocol@11
[ 1.629270] fw_devlink_create_devlink 298d0000.mmc firmware:scmi
[ 1.635257] device: 'platform:firmware:scmi--platform:298d0000.mmc': device_add
[ 1.642590] devices_kset: Moving 298d0000.mmc to end of list
[ 1.648166] platform 298d0000.mmc: Linked as a consumer to firmware:scmi
[ 1.654840] mmc@298d0000 Dropping the fwnode link to scmi
Per log, mmc not take the protocol@11 as supplier in the end.
Regards,
Peng.
^ permalink raw reply [relevance 0%]
* RE: Regression: PM: domains: Delete usage of driver_deferred_probe_check_state
2022-08-18 18:08 0% ` Saravana Kannan
@ 2022-08-19 4:04 0% ` Bough Chen
-1 siblings, 0 replies; 25+ results
From: Bough Chen @ 2022-08-19 4:04 UTC (permalink / raw)
To: Saravana Kannan, Peng Fan
Cc: linux-arm-kernel, dl-linux-imx, sudeep.holla, linux-pm, Alice Guo
> -----Original Message-----
> From: Saravana Kannan <saravanak@google.com>
> Sent: 2022年8月19日 2:08
> To: Peng Fan <peng.fan@nxp.com>
> Cc: linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>;
> sudeep.holla@arm.com; linux-pm@vger.kernel.org; Alice Guo
> <alice.guo@nxp.com>; Bough Chen <haibo.chen@nxp.com>
> Subject: Re: Regression: PM: domains: Delete usage of
> driver_deferred_probe_check_state
>
> On Mon, Aug 15, 2022 at 11:43 PM Peng Fan <peng.fan@nxp.com> wrote:
> >
> > > Subject: Regression: PM: domains: Delete usage of
> > > driver_deferred_probe_check_state
> >
> > Just see your patchset :)
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fall%2F20220727185012.3255200-1-saravanak%40google.com
> %2F
> >
> &data=05%7C01%7Chaibo.chen%40nxp.com%7C360d3e523a9441882e59
> 08da814
> >
> 4be16%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637964429489
> 059385%
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> I6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ks6LI%2FRywgIK
> HrMJmXtzG
> > mdz%2B2M1j5M7BvfsNiXOxVc%3D&reserved=0
> >
> > Thanks,
> > Peng.
> > >
> > > Hi Saravana,
> > >
> > > The following two patches breaks NXP i.MX8ULP, but I think it may
> > > break others use SCMI.
> > >
> > > commit 5a46079a96451cfb15e4f5f01f73f7ba24ef851a
> > > Author: Saravana Kannan <mailto:saravanak@google.com>
> > > Date: Wed Jun 1 00:06:57 2022 -0700
> > >
> > > PM: domains: Delete usage of driver_deferred_probe_check_state()
> > >
> > > Now that fw_devlink=on by default and fw_devlink supports
> > > "power-domains" property, the execution will never get to the point
> > > where driver_deferred_probe_check_state() is called before the
> supplier
> > > has probed successfully or before deferred probe timeout has expired.
> > >
> > > So, delete the call and replace it with -ENODEV.
> > >
> > > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > > Reviewed-by: Ulf Hansson <mailto:ulf.hansson@linaro.org>
> > > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > > Link:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > >
> re.kernel.org%2Fr%2F20220601070707.3946847-2-&data=05%7C01%7Ch
> ai
> > >
> bo.chen%40nxp.com%7C360d3e523a9441882e5908da8144be16%7C686ea1d3
> bc2b4
> > >
> c6fa92cd99c5c301635%7C0%7C0%7C637964429489059385%7CUnknown%7CT
> WFpbGZ
> > >
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > %3D%7C3000%7C%7C%7C&sdata=iEFIifTVfvCnrrrJ8F19nIacGdF8VQ6Y
> wnN9BJ
> > > edaPk%3D&reserved=0
> > > saravanak@google.com
> > > Signed-off-by: Greg Kroah-Hartman
> > > <mailto:gregkh@linuxfoundation.org>
> > >
> > > commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b
> > > Author: Saravana Kannan <mailto:saravanak@google.com>
> > > Date: Wed Jun 1 00:07:05 2022 -0700
> > >
> > > driver core: Delete driver_deferred_probe_check_state()
> > >
> > > The function is no longer used. So delete it.
> > >
> > > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > > Link:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > >
> re.kernel.org%2Fr%2F20220601070707.3946847-10-&data=05%7C01%7C
> ha
> > >
> ibo.chen%40nxp.com%7C360d3e523a9441882e5908da8144be16%7C686ea1d3
> bc2b
> > >
> 4c6fa92cd99c5c301635%7C0%7C0%7C637964429489059385%7CUnknown%7C
> TWFpbG
> > >
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> > >
> 0%3D%7C3000%7C%7C%7C&sdata=4odCYW1lE17PZLBlvYFM4%2B0b0pm
> chu3vs8W
> > > iSfEuHI8%3D&reserved=0
> > > saravanak@google.com
> > > Signed-off-by: Greg Kroah-Hartman
> > > <mailto:gregkh@linuxfoundation.org>
> > >
> > > The i.MX8ULP mmc device node use
> > > "power-domains = <&scmi_devpd IMX8ULP_PD_USDHC0>;"
> > >
> > > The scmi firmware node as below:
> > > firmware {
> > > scmi {
> > > compatible = "arm,scmi-smc";
> > > arm,smc-id = <0xc20000fe>;
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > shmem = <&scmi_buf>;
> > >
> > > scmi_devpd: protocol@11 {
> > > reg = <0x11>;
> > > #power-domain-cells = <1>;
> > > };
> > >
> > > scmi_sensor: protocol@15 {
> > > reg = <0x15>;
> > > #thermal-sensor-cells = <1>;
> > > };
> > > };
> > > };
> > >
> > > When sdhc driver probe, the scmi power domain provider has not been
> > > registered. So __genpd_dev_pm_attach directly return -ENODEV.
> > >
> > > device_links_check_suppliers should already check suppliers, but
> > > scmi protocol device not have compatible, so of_link_to_phandle
> > > |-> of_get_compat_node
> > > use the parent node of scmi protocol as supplier if I understand correct.
> > >
> > > I am not sure whether we need to revert the above two patches, or do
> > > you have other suggestions?
>
> Hi Peng,
>
> Thanks for the report. If you try this series with the following diff, I expect it to
> fix the issue for you. Can you please test it out and let me know? The v1 of the
> series removes the dependency on "compatible" strings. The first diff below is
> something I'm going to roll into v2 of the series and the 2nd diff below is fixing
> up the scmi bus to set the fwnode for devices it creates.
HI Saravana,
I notice that the three reverted patch do not in upstream 6.0-RC1, so on the latest 6.0-RC1,
I apply your 9 patch set and the two diff, but unfortunately still meet the same issue. MMC still not probe.
You can refer to arch/arm64/boot/dts/freescale/imx8ulp.dtsi for more detail.
And for your second diff, will meet following build error, I just add a little change to fix it:
1, add onel line : #include <linux/of.h>
2, add a blank before "=" in line 195.
drivers/firmware/arm_scmi/bus.c: In function ‘scmi_device_create’:
drivers/firmware/arm_scmi/bus.c:195:31: error: implicit declaration of function ‘of_fwnode_handle’ [-Werror=implicit-function-declaration]
195 | scmi_dev->dev.fwnode= of_fwnode_handle(np);
| ^~~~~~~~~~~~~~~~
drivers/firmware/arm_scmi/bus.c:195:29: warning: assignment to ‘struct fwnode_handle *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
195 | scmi_dev->dev.fwnode= of_fwnode_handle(np);
| ^
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:250: drivers/firmware/arm_scmi/bus.o] Error 1
make[3]: *** Waiting for unfinished jobs....
Best Regards
Haibo Chen
>
> Thanks,
> Saravana
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kern
> el.org%2Flkml%2F20220810060040.321697-1-saravanak%40google.com%2F&a
> mp;data=05%7C01%7Chaibo.chen%40nxp.com%7C360d3e523a9441882e5908
> da8144be16%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6379644
> 29489059385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
> a=o7%2B5HStu82S3dj1J5SfEO3PrG9fo2SSsR6PT5t0v0x0%3D&reserved=0
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c index
> 2f012e826986..866755d8ad95 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2068,7 +2068,11 @@ static int fw_devlink_create_devlink(struct device
> *con,
> device_links_write_unlock();
> }
>
> - sup_dev = get_dev_from_fwnode(sup_handle);
> + if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE)
> + sup_dev = fwnode_get_next_parent_dev(sup_handle);
> + else
> + sup_dev = get_dev_from_fwnode(sup_handle);
> +
> if (sup_dev) {
> /*
> * If it's one of those drivers that don't actually bind to
>
>
> diff --git a/drivers/firmware/arm_scmi/bus.c
> b/drivers/firmware/arm_scmi/bus.c index d4e23101448a..0802bdd0ebfc
> 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -192,6 +192,7 @@ scmi_device_create(struct device_node *np, struct
> device *parent, int protocol,
> scmi_dev->protocol_id = protocol;
> scmi_dev->dev.parent = parent;
> scmi_dev->dev.of_node = np;
> + scmi_dev->dev.fwnode= of_fwnode_handle(np);
> scmi_dev->dev.bus = &scmi_bus_type;
> scmi_dev->dev.release = scmi_device_release;
> dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 0%]
* RE: Regression: PM: domains: Delete usage of driver_deferred_probe_check_state
@ 2022-08-19 4:04 0% ` Bough Chen
0 siblings, 0 replies; 25+ results
From: Bough Chen @ 2022-08-19 4:04 UTC (permalink / raw)
To: Saravana Kannan, Peng Fan
Cc: linux-arm-kernel, dl-linux-imx, sudeep.holla, linux-pm, Alice Guo
> -----Original Message-----
> From: Saravana Kannan <saravanak@google.com>
> Sent: 2022年8月19日 2:08
> To: Peng Fan <peng.fan@nxp.com>
> Cc: linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>;
> sudeep.holla@arm.com; linux-pm@vger.kernel.org; Alice Guo
> <alice.guo@nxp.com>; Bough Chen <haibo.chen@nxp.com>
> Subject: Re: Regression: PM: domains: Delete usage of
> driver_deferred_probe_check_state
>
> On Mon, Aug 15, 2022 at 11:43 PM Peng Fan <peng.fan@nxp.com> wrote:
> >
> > > Subject: Regression: PM: domains: Delete usage of
> > > driver_deferred_probe_check_state
> >
> > Just see your patchset :)
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fall%2F20220727185012.3255200-1-saravanak%40google.com
> %2F
> >
> &data=05%7C01%7Chaibo.chen%40nxp.com%7C360d3e523a9441882e59
> 08da814
> >
> 4be16%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637964429489
> 059385%
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> I6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ks6LI%2FRywgIK
> HrMJmXtzG
> > mdz%2B2M1j5M7BvfsNiXOxVc%3D&reserved=0
> >
> > Thanks,
> > Peng.
> > >
> > > Hi Saravana,
> > >
> > > The following two patches breaks NXP i.MX8ULP, but I think it may
> > > break others use SCMI.
> > >
> > > commit 5a46079a96451cfb15e4f5f01f73f7ba24ef851a
> > > Author: Saravana Kannan <mailto:saravanak@google.com>
> > > Date: Wed Jun 1 00:06:57 2022 -0700
> > >
> > > PM: domains: Delete usage of driver_deferred_probe_check_state()
> > >
> > > Now that fw_devlink=on by default and fw_devlink supports
> > > "power-domains" property, the execution will never get to the point
> > > where driver_deferred_probe_check_state() is called before the
> supplier
> > > has probed successfully or before deferred probe timeout has expired.
> > >
> > > So, delete the call and replace it with -ENODEV.
> > >
> > > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > > Reviewed-by: Ulf Hansson <mailto:ulf.hansson@linaro.org>
> > > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > > Link:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > >
> re.kernel.org%2Fr%2F20220601070707.3946847-2-&data=05%7C01%7Ch
> ai
> > >
> bo.chen%40nxp.com%7C360d3e523a9441882e5908da8144be16%7C686ea1d3
> bc2b4
> > >
> c6fa92cd99c5c301635%7C0%7C0%7C637964429489059385%7CUnknown%7CT
> WFpbGZ
> > >
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > > %3D%7C3000%7C%7C%7C&sdata=iEFIifTVfvCnrrrJ8F19nIacGdF8VQ6Y
> wnN9BJ
> > > edaPk%3D&reserved=0
> > > saravanak@google.com
> > > Signed-off-by: Greg Kroah-Hartman
> > > <mailto:gregkh@linuxfoundation.org>
> > >
> > > commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b
> > > Author: Saravana Kannan <mailto:saravanak@google.com>
> > > Date: Wed Jun 1 00:07:05 2022 -0700
> > >
> > > driver core: Delete driver_deferred_probe_check_state()
> > >
> > > The function is no longer used. So delete it.
> > >
> > > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > > Link:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
> > >
> re.kernel.org%2Fr%2F20220601070707.3946847-10-&data=05%7C01%7C
> ha
> > >
> ibo.chen%40nxp.com%7C360d3e523a9441882e5908da8144be16%7C686ea1d3
> bc2b
> > >
> 4c6fa92cd99c5c301635%7C0%7C0%7C637964429489059385%7CUnknown%7C
> TWFpbG
> > >
> Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> > >
> 0%3D%7C3000%7C%7C%7C&sdata=4odCYW1lE17PZLBlvYFM4%2B0b0pm
> chu3vs8W
> > > iSfEuHI8%3D&reserved=0
> > > saravanak@google.com
> > > Signed-off-by: Greg Kroah-Hartman
> > > <mailto:gregkh@linuxfoundation.org>
> > >
> > > The i.MX8ULP mmc device node use
> > > "power-domains = <&scmi_devpd IMX8ULP_PD_USDHC0>;"
> > >
> > > The scmi firmware node as below:
> > > firmware {
> > > scmi {
> > > compatible = "arm,scmi-smc";
> > > arm,smc-id = <0xc20000fe>;
> > > #address-cells = <1>;
> > > #size-cells = <0>;
> > > shmem = <&scmi_buf>;
> > >
> > > scmi_devpd: protocol@11 {
> > > reg = <0x11>;
> > > #power-domain-cells = <1>;
> > > };
> > >
> > > scmi_sensor: protocol@15 {
> > > reg = <0x15>;
> > > #thermal-sensor-cells = <1>;
> > > };
> > > };
> > > };
> > >
> > > When sdhc driver probe, the scmi power domain provider has not been
> > > registered. So __genpd_dev_pm_attach directly return -ENODEV.
> > >
> > > device_links_check_suppliers should already check suppliers, but
> > > scmi protocol device not have compatible, so of_link_to_phandle
> > > |-> of_get_compat_node
> > > use the parent node of scmi protocol as supplier if I understand correct.
> > >
> > > I am not sure whether we need to revert the above two patches, or do
> > > you have other suggestions?
>
> Hi Peng,
>
> Thanks for the report. If you try this series with the following diff, I expect it to
> fix the issue for you. Can you please test it out and let me know? The v1 of the
> series removes the dependency on "compatible" strings. The first diff below is
> something I'm going to roll into v2 of the series and the 2nd diff below is fixing
> up the scmi bus to set the fwnode for devices it creates.
HI Saravana,
I notice that the three reverted patch do not in upstream 6.0-RC1, so on the latest 6.0-RC1,
I apply your 9 patch set and the two diff, but unfortunately still meet the same issue. MMC still not probe.
You can refer to arch/arm64/boot/dts/freescale/imx8ulp.dtsi for more detail.
And for your second diff, will meet following build error, I just add a little change to fix it:
1, add onel line : #include <linux/of.h>
2, add a blank before "=" in line 195.
drivers/firmware/arm_scmi/bus.c: In function ‘scmi_device_create’:
drivers/firmware/arm_scmi/bus.c:195:31: error: implicit declaration of function ‘of_fwnode_handle’ [-Werror=implicit-function-declaration]
195 | scmi_dev->dev.fwnode= of_fwnode_handle(np);
| ^~~~~~~~~~~~~~~~
drivers/firmware/arm_scmi/bus.c:195:29: warning: assignment to ‘struct fwnode_handle *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
195 | scmi_dev->dev.fwnode= of_fwnode_handle(np);
| ^
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:250: drivers/firmware/arm_scmi/bus.o] Error 1
make[3]: *** Waiting for unfinished jobs....
Best Regards
Haibo Chen
>
> Thanks,
> Saravana
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kern
> el.org%2Flkml%2F20220810060040.321697-1-saravanak%40google.com%2F&a
> mp;data=05%7C01%7Chaibo.chen%40nxp.com%7C360d3e523a9441882e5908
> da8144be16%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6379644
> 29489059385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat
> a=o7%2B5HStu82S3dj1J5SfEO3PrG9fo2SSsR6PT5t0v0x0%3D&reserved=0
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c index
> 2f012e826986..866755d8ad95 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2068,7 +2068,11 @@ static int fw_devlink_create_devlink(struct device
> *con,
> device_links_write_unlock();
> }
>
> - sup_dev = get_dev_from_fwnode(sup_handle);
> + if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE)
> + sup_dev = fwnode_get_next_parent_dev(sup_handle);
> + else
> + sup_dev = get_dev_from_fwnode(sup_handle);
> +
> if (sup_dev) {
> /*
> * If it's one of those drivers that don't actually bind to
>
>
> diff --git a/drivers/firmware/arm_scmi/bus.c
> b/drivers/firmware/arm_scmi/bus.c index d4e23101448a..0802bdd0ebfc
> 100644
> --- a/drivers/firmware/arm_scmi/bus.c
> +++ b/drivers/firmware/arm_scmi/bus.c
> @@ -192,6 +192,7 @@ scmi_device_create(struct device_node *np, struct
> device *parent, int protocol,
> scmi_dev->protocol_id = protocol;
> scmi_dev->dev.parent = parent;
> scmi_dev->dev.of_node = np;
> + scmi_dev->dev.fwnode= of_fwnode_handle(np);
> scmi_dev->dev.bus = &scmi_bus_type;
> scmi_dev->dev.release = scmi_device_release;
> dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
^ permalink raw reply [relevance 0%]
* Re: Regression: PM: domains: Delete usage of driver_deferred_probe_check_state
2022-08-16 6:43 0% ` Peng Fan
@ 2022-08-18 18:08 0% ` Saravana Kannan
-1 siblings, 0 replies; 25+ results
From: Saravana Kannan @ 2022-08-18 18:08 UTC (permalink / raw)
To: Peng Fan
Cc: linux-arm-kernel, dl-linux-imx, sudeep.holla, linux-pm,
Alice Guo, Bough Chen
On Mon, Aug 15, 2022 at 11:43 PM Peng Fan <peng.fan@nxp.com> wrote:
>
> > Subject: Regression: PM: domains: Delete usage of
> > driver_deferred_probe_check_state
>
> Just see your patchset :)
> https://lore.kernel.org/all/20220727185012.3255200-1-saravanak@google.com/
>
> Thanks,
> Peng.
> >
> > Hi Saravana,
> >
> > The following two patches breaks NXP i.MX8ULP, but I think it may break
> > others use SCMI.
> >
> > commit 5a46079a96451cfb15e4f5f01f73f7ba24ef851a
> > Author: Saravana Kannan <mailto:saravanak@google.com>
> > Date: Wed Jun 1 00:06:57 2022 -0700
> >
> > PM: domains: Delete usage of driver_deferred_probe_check_state()
> >
> > Now that fw_devlink=on by default and fw_devlink supports
> > "power-domains" property, the execution will never get to the point
> > where driver_deferred_probe_check_state() is called before the supplier
> > has probed successfully or before deferred probe timeout has expired.
> >
> > So, delete the call and replace it with -ENODEV.
> >
> > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > Reviewed-by: Ulf Hansson <mailto:ulf.hansson@linaro.org>
> > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > Link: https://lore.kernel.org/r/20220601070707.3946847-2-
> > saravanak@google.com
> > Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
> >
> > commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b
> > Author: Saravana Kannan <mailto:saravanak@google.com>
> > Date: Wed Jun 1 00:07:05 2022 -0700
> >
> > driver core: Delete driver_deferred_probe_check_state()
> >
> > The function is no longer used. So delete it.
> >
> > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > Link: https://lore.kernel.org/r/20220601070707.3946847-10-
> > saravanak@google.com
> > Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
> >
> > The i.MX8ULP mmc device node use
> > "power-domains = <&scmi_devpd IMX8ULP_PD_USDHC0>;"
> >
> > The scmi firmware node as below:
> > firmware {
> > scmi {
> > compatible = "arm,scmi-smc";
> > arm,smc-id = <0xc20000fe>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > shmem = <&scmi_buf>;
> >
> > scmi_devpd: protocol@11 {
> > reg = <0x11>;
> > #power-domain-cells = <1>;
> > };
> >
> > scmi_sensor: protocol@15 {
> > reg = <0x15>;
> > #thermal-sensor-cells = <1>;
> > };
> > };
> > };
> >
> > When sdhc driver probe, the scmi power domain provider has not been
> > registered. So __genpd_dev_pm_attach directly return -ENODEV.
> >
> > device_links_check_suppliers should already check suppliers, but scmi
> > protocol device not have compatible, so of_link_to_phandle
> > |-> of_get_compat_node
> > use the parent node of scmi protocol as supplier if I understand correct.
> >
> > I am not sure whether we need to revert the above two patches, or do you
> > have other suggestions?
Hi Peng,
Thanks for the report. If you try this series with the following diff,
I expect it to fix the issue for you. Can you please test it out and
let me know? The v1 of the series removes the dependency on
"compatible" strings. The first diff below is something I'm going to
roll into v2 of the series and the 2nd diff below is fixing up the
scmi bus to set the fwnode for devices it creates.
Thanks,
Saravana
https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 2f012e826986..866755d8ad95 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2068,7 +2068,11 @@ static int fw_devlink_create_devlink(struct device *con,
device_links_write_unlock();
}
- sup_dev = get_dev_from_fwnode(sup_handle);
+ if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE)
+ sup_dev = fwnode_get_next_parent_dev(sup_handle);
+ else
+ sup_dev = get_dev_from_fwnode(sup_handle);
+
if (sup_dev) {
/*
* If it's one of those drivers that don't actually bind to
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index d4e23101448a..0802bdd0ebfc 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -192,6 +192,7 @@ scmi_device_create(struct device_node *np, struct
device *parent, int protocol,
scmi_dev->protocol_id = protocol;
scmi_dev->dev.parent = parent;
scmi_dev->dev.of_node = np;
+ scmi_dev->dev.fwnode= of_fwnode_handle(np);
scmi_dev->dev.bus = &scmi_bus_type;
scmi_dev->dev.release = scmi_device_release;
dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [relevance 0%]
* Re: Regression: PM: domains: Delete usage of driver_deferred_probe_check_state
@ 2022-08-18 18:08 0% ` Saravana Kannan
0 siblings, 0 replies; 25+ results
From: Saravana Kannan @ 2022-08-18 18:08 UTC (permalink / raw)
To: Peng Fan
Cc: linux-arm-kernel, dl-linux-imx, sudeep.holla, linux-pm,
Alice Guo, Bough Chen
On Mon, Aug 15, 2022 at 11:43 PM Peng Fan <peng.fan@nxp.com> wrote:
>
> > Subject: Regression: PM: domains: Delete usage of
> > driver_deferred_probe_check_state
>
> Just see your patchset :)
> https://lore.kernel.org/all/20220727185012.3255200-1-saravanak@google.com/
>
> Thanks,
> Peng.
> >
> > Hi Saravana,
> >
> > The following two patches breaks NXP i.MX8ULP, but I think it may break
> > others use SCMI.
> >
> > commit 5a46079a96451cfb15e4f5f01f73f7ba24ef851a
> > Author: Saravana Kannan <mailto:saravanak@google.com>
> > Date: Wed Jun 1 00:06:57 2022 -0700
> >
> > PM: domains: Delete usage of driver_deferred_probe_check_state()
> >
> > Now that fw_devlink=on by default and fw_devlink supports
> > "power-domains" property, the execution will never get to the point
> > where driver_deferred_probe_check_state() is called before the supplier
> > has probed successfully or before deferred probe timeout has expired.
> >
> > So, delete the call and replace it with -ENODEV.
> >
> > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > Reviewed-by: Ulf Hansson <mailto:ulf.hansson@linaro.org>
> > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > Link: https://lore.kernel.org/r/20220601070707.3946847-2-
> > saravanak@google.com
> > Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
> >
> > commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b
> > Author: Saravana Kannan <mailto:saravanak@google.com>
> > Date: Wed Jun 1 00:07:05 2022 -0700
> >
> > driver core: Delete driver_deferred_probe_check_state()
> >
> > The function is no longer used. So delete it.
> >
> > Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> > Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> > Link: https://lore.kernel.org/r/20220601070707.3946847-10-
> > saravanak@google.com
> > Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
> >
> > The i.MX8ULP mmc device node use
> > "power-domains = <&scmi_devpd IMX8ULP_PD_USDHC0>;"
> >
> > The scmi firmware node as below:
> > firmware {
> > scmi {
> > compatible = "arm,scmi-smc";
> > arm,smc-id = <0xc20000fe>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > shmem = <&scmi_buf>;
> >
> > scmi_devpd: protocol@11 {
> > reg = <0x11>;
> > #power-domain-cells = <1>;
> > };
> >
> > scmi_sensor: protocol@15 {
> > reg = <0x15>;
> > #thermal-sensor-cells = <1>;
> > };
> > };
> > };
> >
> > When sdhc driver probe, the scmi power domain provider has not been
> > registered. So __genpd_dev_pm_attach directly return -ENODEV.
> >
> > device_links_check_suppliers should already check suppliers, but scmi
> > protocol device not have compatible, so of_link_to_phandle
> > |-> of_get_compat_node
> > use the parent node of scmi protocol as supplier if I understand correct.
> >
> > I am not sure whether we need to revert the above two patches, or do you
> > have other suggestions?
Hi Peng,
Thanks for the report. If you try this series with the following diff,
I expect it to fix the issue for you. Can you please test it out and
let me know? The v1 of the series removes the dependency on
"compatible" strings. The first diff below is something I'm going to
roll into v2 of the series and the 2nd diff below is fixing up the
scmi bus to set the fwnode for devices it creates.
Thanks,
Saravana
https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 2f012e826986..866755d8ad95 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2068,7 +2068,11 @@ static int fw_devlink_create_devlink(struct device *con,
device_links_write_unlock();
}
- sup_dev = get_dev_from_fwnode(sup_handle);
+ if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE)
+ sup_dev = fwnode_get_next_parent_dev(sup_handle);
+ else
+ sup_dev = get_dev_from_fwnode(sup_handle);
+
if (sup_dev) {
/*
* If it's one of those drivers that don't actually bind to
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index d4e23101448a..0802bdd0ebfc 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -192,6 +192,7 @@ scmi_device_create(struct device_node *np, struct
device *parent, int protocol,
scmi_dev->protocol_id = protocol;
scmi_dev->dev.parent = parent;
scmi_dev->dev.of_node = np;
+ scmi_dev->dev.fwnode= of_fwnode_handle(np);
scmi_dev->dev.bus = &scmi_bus_type;
scmi_dev->dev.release = scmi_device_release;
dev_set_name(&scmi_dev->dev, "scmi_dev.%d", id);
^ permalink raw reply related [relevance 0%]
* Re: boot stuck at starting kernel, due to __genpd_dev_pm_attach?
2022-08-16 0:43 0% ` Saravana Kannan
@ 2022-08-17 5:48 0% ` Colin Foster
0 siblings, 0 replies; 25+ results
From: Colin Foster @ 2022-08-17 5:48 UTC (permalink / raw)
To: Saravana Kannan
Cc: Pavel Machek, linux-kernel, Greg Kroah-Hartman, Len Brown,
Ulf Hansson, Kevin Hilman, Rafael J. Wysocki, Geert Uytterhoeven
On Mon, Aug 15, 2022 at 05:43:19PM -0700, Saravana Kannan wrote:
> On Mon, Aug 15, 2022 at 5:28 PM Colin Foster
> <colin.foster@in-advantage.com> wrote:
> >
> > On Mon, Aug 15, 2022 at 08:23:07PM +0200, Pavel Machek wrote:
> > > Hi!
> > >
> > > > You might have already gotten this report, but I tried running v6.0-rc1
> > > > on my BeagleBone Black and it gets stuck right after "Starting kernel
> > > > ..." from U-Boot.
> > > >
> > > > A bisect pointed me to commit 5a46079a9645 ("PM: domains: Delete usage
> > > > of driver_deferred_probe_check_state()").
> > > >
> > > > I don't have much more detail than that, other than I'm using the
> > > > in-tree am335x-boneblack.dts device tree and I believe I had tested with
> > > > the multi-v7-defconfig for this verification. I'm happy to test anything
> > > > that might offer more information.
> > >
> > > Well, standart next step is reverting 5a46079a9645 on top of v6.0-rc1,
> > > and if it starts working, either you get fix in your inbox, or you ask
> > > Linus to revert :-).
> >
> > I was able to revert 5a46079a9645 and 9cbffc7a5956 and successfully boot
> > v6.0-rc1 on the Beaglebone Black.
> >
> > I still don't know whether the root cause is the patch, or perhaps an
> > invalid boneblack DTS. I'll try and dig to get more info about what
> > might be failing. But I do think anyone using a Beaglebone will have
> > this issue, and I also think I'm not the only using the BBB.
> >
>
> Hi Colin,
>
> Thanks for the report. There have been other reports like this. This
> commit in question is probably the cause. I have two series going.
>
> One [1] is to revert these patches. Probably more suited for 5.19.xxx releases.
>
> The other [2] is to actually fix the issues you are seeing without
> reverting these patches (long term we do want to keep the patch that's
> causing the issue for you -- not going into the details here). Can you
> give this series[2] a shot and tell me if it fixes the issue? You
> might need to pull in this additional diff on top of [2] (I'll roll it
> into v2 of the series once I get some tests on this)
Hi Saravana,
I can confirm that series [2] fixes the boot issues I was having with
6.0-rc1 on the Beaglebone Black. I did not need to apply the diff you
posted below.
Thanks!
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 2f012e826986..866755d8ad95 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2068,7 +2068,11 @@ static int fw_devlink_create_devlink(struct device *con,
> device_links_write_unlock();
> }
>
> - sup_dev = get_dev_from_fwnode(sup_handle);
> + if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE)
> + sup_dev = fwnode_get_next_parent_dev(sup_handle);
> + else
> + sup_dev = get_dev_from_fwnode(sup_handle);
> +
> if (sup_dev) {
> /*
> * If it's one of those drivers that don't actually bind to
>
> Thanks,
> Saravana
>
> [1] - https://lore.kernel.org/lkml/20220727185012.3255200-1-saravanak@google.com/
> [2] - https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/
^ permalink raw reply [relevance 0%]
* RE: Regression: PM: domains: Delete usage of driver_deferred_probe_check_state
2022-08-16 6:21 78% ` Peng Fan
@ 2022-08-16 6:43 0% ` Peng Fan
-1 siblings, 0 replies; 25+ results
From: Peng Fan @ 2022-08-16 6:43 UTC (permalink / raw)
To: linux-arm-kernel, dl-linux-imx, sudeep.holla, Saravana Kannan, linux-pm
Cc: Alice Guo, Bough Chen
> Subject: Regression: PM: domains: Delete usage of
> driver_deferred_probe_check_state
Just see your patchset :)
https://lore.kernel.org/all/20220727185012.3255200-1-saravanak@google.com/
Thanks,
Peng.
>
> Hi Saravana,
>
> The following two patches breaks NXP i.MX8ULP, but I think it may break
> others use SCMI.
>
> commit 5a46079a96451cfb15e4f5f01f73f7ba24ef851a
> Author: Saravana Kannan <mailto:saravanak@google.com>
> Date: Wed Jun 1 00:06:57 2022 -0700
>
> PM: domains: Delete usage of driver_deferred_probe_check_state()
>
> Now that fw_devlink=on by default and fw_devlink supports
> "power-domains" property, the execution will never get to the point
> where driver_deferred_probe_check_state() is called before the supplier
> has probed successfully or before deferred probe timeout has expired.
>
> So, delete the call and replace it with -ENODEV.
>
> Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> Reviewed-by: Ulf Hansson <mailto:ulf.hansson@linaro.org>
> Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> Link: https://lore.kernel.org/r/20220601070707.3946847-2-
> saravanak@google.com
> Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
>
> commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b
> Author: Saravana Kannan <mailto:saravanak@google.com>
> Date: Wed Jun 1 00:07:05 2022 -0700
>
> driver core: Delete driver_deferred_probe_check_state()
>
> The function is no longer used. So delete it.
>
> Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> Link: https://lore.kernel.org/r/20220601070707.3946847-10-
> saravanak@google.com
> Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
>
> The i.MX8ULP mmc device node use
> "power-domains = <&scmi_devpd IMX8ULP_PD_USDHC0>;"
>
> The scmi firmware node as below:
> firmware {
> scmi {
> compatible = "arm,scmi-smc";
> arm,smc-id = <0xc20000fe>;
> #address-cells = <1>;
> #size-cells = <0>;
> shmem = <&scmi_buf>;
>
> scmi_devpd: protocol@11 {
> reg = <0x11>;
> #power-domain-cells = <1>;
> };
>
> scmi_sensor: protocol@15 {
> reg = <0x15>;
> #thermal-sensor-cells = <1>;
> };
> };
> };
>
> When sdhc driver probe, the scmi power domain provider has not been
> registered. So __genpd_dev_pm_attach directly return -ENODEV.
>
> device_links_check_suppliers should already check suppliers, but scmi
> protocol device not have compatible, so of_link_to_phandle
> |-> of_get_compat_node
> use the parent node of scmi protocol as supplier if I understand correct.
>
> I am not sure whether we need to revert the above two patches, or do you
> have other suggestions?
>
> Thanks,
> Peng.
^ permalink raw reply [relevance 0%]
* Regression: PM: domains: Delete usage of driver_deferred_probe_check_state
@ 2022-08-16 6:21 78% ` Peng Fan
0 siblings, 0 replies; 25+ results
From: Peng Fan @ 2022-08-16 6:21 UTC (permalink / raw)
To: linux-arm-kernel, dl-linux-imx, sudeep.holla, Saravana Kannan, linux-pm
Cc: Alice Guo
Hi Saravana,
The following two patches breaks NXP i.MX8ULP, but I think
it may break others use SCMI.
commit 5a46079a96451cfb15e4f5f01f73f7ba24ef851a
Author: Saravana Kannan <mailto:saravanak@google.com>
Date: Wed Jun 1 00:06:57 2022 -0700
PM: domains: Delete usage of driver_deferred_probe_check_state()
Now that fw_devlink=on by default and fw_devlink supports
"power-domains" property, the execution will never get to the point
where driver_deferred_probe_check_state() is called before the supplier
has probed successfully or before deferred probe timeout has expired.
So, delete the call and replace it with -ENODEV.
Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <mailto:ulf.hansson@linaro.org>
Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
Link: https://lore.kernel.org/r/20220601070707.3946847-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b
Author: Saravana Kannan <mailto:saravanak@google.com>
Date: Wed Jun 1 00:07:05 2022 -0700
driver core: Delete driver_deferred_probe_check_state()
The function is no longer used. So delete it.
Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
Link: https://lore.kernel.org/r/20220601070707.3946847-10-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
The i.MX8ULP mmc device node use
"power-domains = <&scmi_devpd IMX8ULP_PD_USDHC0>;"
The scmi firmware node as below:
firmware {
scmi {
compatible = "arm,scmi-smc";
arm,smc-id = <0xc20000fe>;
#address-cells = <1>;
#size-cells = <0>;
shmem = <&scmi_buf>;
scmi_devpd: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
scmi_sensor: protocol@15 {
reg = <0x15>;
#thermal-sensor-cells = <1>;
};
};
};
When sdhc driver probe, the scmi power domain provider has not
been registered. So __genpd_dev_pm_attach directly return
-ENODEV.
device_links_check_suppliers should already check suppliers,
but scmi protocol device not have compatible, so
of_link_to_phandle
|-> of_get_compat_node
use the parent node of scmi protocol as supplier if I understand
correct.
I am not sure whether we need to revert the above two patches,
or do you have other suggestions?
Thanks,
Peng.
^ permalink raw reply [relevance 78%]
* RE: Regression: PM: domains: Delete usage of driver_deferred_probe_check_state
@ 2022-08-16 6:43 0% ` Peng Fan
0 siblings, 0 replies; 25+ results
From: Peng Fan @ 2022-08-16 6:43 UTC (permalink / raw)
To: linux-arm-kernel, dl-linux-imx, sudeep.holla, Saravana Kannan, linux-pm
Cc: Alice Guo, Bough Chen
> Subject: Regression: PM: domains: Delete usage of
> driver_deferred_probe_check_state
Just see your patchset :)
https://lore.kernel.org/all/20220727185012.3255200-1-saravanak@google.com/
Thanks,
Peng.
>
> Hi Saravana,
>
> The following two patches breaks NXP i.MX8ULP, but I think it may break
> others use SCMI.
>
> commit 5a46079a96451cfb15e4f5f01f73f7ba24ef851a
> Author: Saravana Kannan <mailto:saravanak@google.com>
> Date: Wed Jun 1 00:06:57 2022 -0700
>
> PM: domains: Delete usage of driver_deferred_probe_check_state()
>
> Now that fw_devlink=on by default and fw_devlink supports
> "power-domains" property, the execution will never get to the point
> where driver_deferred_probe_check_state() is called before the supplier
> has probed successfully or before deferred probe timeout has expired.
>
> So, delete the call and replace it with -ENODEV.
>
> Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> Reviewed-by: Ulf Hansson <mailto:ulf.hansson@linaro.org>
> Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> Link: https://lore.kernel.org/r/20220601070707.3946847-2-
> saravanak@google.com
> Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
>
> commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b
> Author: Saravana Kannan <mailto:saravanak@google.com>
> Date: Wed Jun 1 00:07:05 2022 -0700
>
> driver core: Delete driver_deferred_probe_check_state()
>
> The function is no longer used. So delete it.
>
> Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
> Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
> Link: https://lore.kernel.org/r/20220601070707.3946847-10-
> saravanak@google.com
> Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
>
> The i.MX8ULP mmc device node use
> "power-domains = <&scmi_devpd IMX8ULP_PD_USDHC0>;"
>
> The scmi firmware node as below:
> firmware {
> scmi {
> compatible = "arm,scmi-smc";
> arm,smc-id = <0xc20000fe>;
> #address-cells = <1>;
> #size-cells = <0>;
> shmem = <&scmi_buf>;
>
> scmi_devpd: protocol@11 {
> reg = <0x11>;
> #power-domain-cells = <1>;
> };
>
> scmi_sensor: protocol@15 {
> reg = <0x15>;
> #thermal-sensor-cells = <1>;
> };
> };
> };
>
> When sdhc driver probe, the scmi power domain provider has not been
> registered. So __genpd_dev_pm_attach directly return -ENODEV.
>
> device_links_check_suppliers should already check suppliers, but scmi
> protocol device not have compatible, so of_link_to_phandle
> |-> of_get_compat_node
> use the parent node of scmi protocol as supplier if I understand correct.
>
> I am not sure whether we need to revert the above two patches, or do you
> have other suggestions?
>
> Thanks,
> Peng.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 0%]
* Regression: PM: domains: Delete usage of driver_deferred_probe_check_state
@ 2022-08-16 6:21 78% ` Peng Fan
0 siblings, 0 replies; 25+ results
From: Peng Fan @ 2022-08-16 6:21 UTC (permalink / raw)
To: linux-arm-kernel, dl-linux-imx, sudeep.holla, Saravana Kannan, linux-pm
Cc: Alice Guo
Hi Saravana,
The following two patches breaks NXP i.MX8ULP, but I think
it may break others use SCMI.
commit 5a46079a96451cfb15e4f5f01f73f7ba24ef851a
Author: Saravana Kannan <mailto:saravanak@google.com>
Date: Wed Jun 1 00:06:57 2022 -0700
PM: domains: Delete usage of driver_deferred_probe_check_state()
Now that fw_devlink=on by default and fw_devlink supports
"power-domains" property, the execution will never get to the point
where driver_deferred_probe_check_state() is called before the supplier
has probed successfully or before deferred probe timeout has expired.
So, delete the call and replace it with -ENODEV.
Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
Reviewed-by: Ulf Hansson <mailto:ulf.hansson@linaro.org>
Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
Link: https://lore.kernel.org/r/20220601070707.3946847-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b
Author: Saravana Kannan <mailto:saravanak@google.com>
Date: Wed Jun 1 00:07:05 2022 -0700
driver core: Delete driver_deferred_probe_check_state()
The function is no longer used. So delete it.
Tested-by: Geert Uytterhoeven <mailto:geert+renesas@glider.be>
Signed-off-by: Saravana Kannan <mailto:saravanak@google.com>
Link: https://lore.kernel.org/r/20220601070707.3946847-10-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <mailto:gregkh@linuxfoundation.org>
The i.MX8ULP mmc device node use
"power-domains = <&scmi_devpd IMX8ULP_PD_USDHC0>;"
The scmi firmware node as below:
firmware {
scmi {
compatible = "arm,scmi-smc";
arm,smc-id = <0xc20000fe>;
#address-cells = <1>;
#size-cells = <0>;
shmem = <&scmi_buf>;
scmi_devpd: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
scmi_sensor: protocol@15 {
reg = <0x15>;
#thermal-sensor-cells = <1>;
};
};
};
When sdhc driver probe, the scmi power domain provider has not
been registered. So __genpd_dev_pm_attach directly return
-ENODEV.
device_links_check_suppliers should already check suppliers,
but scmi protocol device not have compatible, so
of_link_to_phandle
|-> of_get_compat_node
use the parent node of scmi protocol as supplier if I understand
correct.
I am not sure whether we need to revert the above two patches,
or do you have other suggestions?
Thanks,
Peng.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [relevance 78%]
* Re: boot stuck at starting kernel, due to __genpd_dev_pm_attach?
@ 2022-08-16 0:27 86% ` Colin Foster
2022-08-16 0:43 0% ` Saravana Kannan
0 siblings, 1 reply; 25+ results
From: Colin Foster @ 2022-08-16 0:27 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-kernel, Greg Kroah-Hartman, Len Brown, Ulf Hansson,
Kevin Hilman, Rafael J. Wysocki, Saravana Kannan,
Geert Uytterhoeven
On Mon, Aug 15, 2022 at 08:23:07PM +0200, Pavel Machek wrote:
> Hi!
>
> > You might have already gotten this report, but I tried running v6.0-rc1
> > on my BeagleBone Black and it gets stuck right after "Starting kernel
> > ..." from U-Boot.
> >
> > A bisect pointed me to commit 5a46079a9645 ("PM: domains: Delete usage
> > of driver_deferred_probe_check_state()").
> >
> > I don't have much more detail than that, other than I'm using the
> > in-tree am335x-boneblack.dts device tree and I believe I had tested with
> > the multi-v7-defconfig for this verification. I'm happy to test anything
> > that might offer more information.
>
> Well, standart next step is reverting 5a46079a9645 on top of v6.0-rc1,
> and if it starts working, either you get fix in your inbox, or you ask
> Linus to revert :-).
I was able to revert 5a46079a9645 and 9cbffc7a5956 and successfully boot
v6.0-rc1 on the Beaglebone Black.
I still don't know whether the root cause is the patch, or perhaps an
invalid boneblack DTS. I'll try and dig to get more info about what
might be failing. But I do think anyone using a Beaglebone will have
this issue, and I also think I'm not the only using the BBB.
>
> Best regards,
> Pavel
> --
> People of Russia, stop Putin before his war on Ukraine escalates.
^ permalink raw reply [relevance 86%]
* Re: boot stuck at starting kernel, due to __genpd_dev_pm_attach?
2022-08-16 0:27 86% ` Colin Foster
@ 2022-08-16 0:43 0% ` Saravana Kannan
2022-08-17 5:48 0% ` Colin Foster
0 siblings, 1 reply; 25+ results
From: Saravana Kannan @ 2022-08-16 0:43 UTC (permalink / raw)
To: Colin Foster
Cc: Pavel Machek, linux-kernel, Greg Kroah-Hartman, Len Brown,
Ulf Hansson, Kevin Hilman, Rafael J. Wysocki, Geert Uytterhoeven
On Mon, Aug 15, 2022 at 5:28 PM Colin Foster
<colin.foster@in-advantage.com> wrote:
>
> On Mon, Aug 15, 2022 at 08:23:07PM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > You might have already gotten this report, but I tried running v6.0-rc1
> > > on my BeagleBone Black and it gets stuck right after "Starting kernel
> > > ..." from U-Boot.
> > >
> > > A bisect pointed me to commit 5a46079a9645 ("PM: domains: Delete usage
> > > of driver_deferred_probe_check_state()").
> > >
> > > I don't have much more detail than that, other than I'm using the
> > > in-tree am335x-boneblack.dts device tree and I believe I had tested with
> > > the multi-v7-defconfig for this verification. I'm happy to test anything
> > > that might offer more information.
> >
> > Well, standart next step is reverting 5a46079a9645 on top of v6.0-rc1,
> > and if it starts working, either you get fix in your inbox, or you ask
> > Linus to revert :-).
>
> I was able to revert 5a46079a9645 and 9cbffc7a5956 and successfully boot
> v6.0-rc1 on the Beaglebone Black.
>
> I still don't know whether the root cause is the patch, or perhaps an
> invalid boneblack DTS. I'll try and dig to get more info about what
> might be failing. But I do think anyone using a Beaglebone will have
> this issue, and I also think I'm not the only using the BBB.
>
Hi Colin,
Thanks for the report. There have been other reports like this. This
commit in question is probably the cause. I have two series going.
One [1] is to revert these patches. Probably more suited for 5.19.xxx releases.
The other [2] is to actually fix the issues you are seeing without
reverting these patches (long term we do want to keep the patch that's
causing the issue for you -- not going into the details here). Can you
give this series[2] a shot and tell me if it fixes the issue? You
might need to pull in this additional diff on top of [2] (I'll roll it
into v2 of the series once I get some tests on this)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 2f012e826986..866755d8ad95 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2068,7 +2068,11 @@ static int fw_devlink_create_devlink(struct device *con,
device_links_write_unlock();
}
- sup_dev = get_dev_from_fwnode(sup_handle);
+ if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE)
+ sup_dev = fwnode_get_next_parent_dev(sup_handle);
+ else
+ sup_dev = get_dev_from_fwnode(sup_handle);
+
if (sup_dev) {
/*
* If it's one of those drivers that don't actually bind to
Thanks,
Saravana
[1] - https://lore.kernel.org/lkml/20220727185012.3255200-1-saravanak@google.com/
[2] - https://lore.kernel.org/lkml/20220810060040.321697-1-saravanak@google.com/
^ permalink raw reply related [relevance 0%]
* Re: [PATCH v1 1/3] Revert "driver core: Delete driver_deferred_probe_check_state()"
2022-07-27 18:50 80% ` [PATCH v1 1/3] Revert "driver core: Delete driver_deferred_probe_check_state()" Saravana Kannan
@ 2022-08-15 10:58 0% ` Tony Lindgren
0 siblings, 0 replies; 25+ results
From: Tony Lindgren @ 2022-08-15 10:58 UTC (permalink / raw)
To: Saravana Kannan
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson,
Pavel Machek, Len Brown, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, naresh.kamboju, kernel-team, linux-kernel, linux-pm,
netdev
* Saravana Kannan <saravanak@google.com> [700101 02:00]:
> This reverts commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b.
>
> There are a few more issues to fix that have been reported in the thread
> for the original series [1]. We'll need to fix those before this will
> work. So, revert it for now.
This fixes booting for several TI 32-bit ARM SoCs such as am335x and dra7.
Please add a proper fixes tag for this patch though:
Fixes: 5a46079a9645 ("PM: domains: Delete usage of driver_deferred_probe_check_state()")
Reviewed-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 3/9] net: mdio: Delete usage of driver_deferred_probe_check_state()
2022-07-05 9:11 77% ` Geert Uytterhoeven
(?)
(?)
@ 2022-08-15 8:38 0% ` Geert Uytterhoeven
-1 siblings, 0 replies; 25+ results
From: Geert Uytterhoeven @ 2022-08-15 8:38 UTC (permalink / raw)
To: Saravana Kannan
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson,
Len Brown, Pavel Machek, Joerg Roedel, Will Deacon, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Linus Walleij, Hideaki YOSHIFUJI,
David Ahern, Android Kernel Team, Linux Kernel Mailing List,
Linux PM list, Linux IOMMU, netdev, open list:GPIO SUBSYSTEM,
Linux-Renesas
Hi Saravana,
On Tue, Jul 5, 2022 at 11:11 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Wed, Jun 1, 2022 at 2:44 PM Saravana Kannan <saravanak@google.com> wrote:
> > Now that fw_devlink=on by default and fw_devlink supports interrupt
> > properties, the execution will never get to the point where
> > driver_deferred_probe_check_state() is called before the supplier has
> > probed successfully or before deferred probe timeout has expired.
> >
> > So, delete the call and replace it with -ENODEV.
> >
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
>
> Thanks for your patch, which is now commit f8217275b57aa48d ("net:
> mdio: Delete usage of driver_deferred_probe_check_state()") in
> driver-core/driver-core-next.
>
> Seems like I missed something when providing my T-b for this series,
> sorry for that.
>
> arch/arm/boot/dts/r8a7791-koelsch.dts has:
>
> ðer {
> pinctrl-0 = <ðer_pins>, <&phy1_pins>;
> pinctrl-names = "default";
>
> phy-handle = <&phy1>;
> renesas,ether-link-active-low;
> status = "okay";
>
> phy1: ethernet-phy@1 {
> compatible = "ethernet-phy-id0022.1537",
> "ethernet-phy-ieee802.3-c22";
> reg = <1>;
> interrupt-parent = <&irqc0>;
> interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> micrel,led-mode = <1>;
> reset-gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
> };
> };
>
> Despite the interrupts property, ðer is now probed before irqc0
> (interrupt-controller@e61c0000 in arch/arm/boot/dts/r8a7791.dtsi),
> causing the PHY not finding its interrupt, and resorting to polling:
>
> -Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
> driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=185)
> +Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
> driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=POLL)
>
> Reverting this commit, and commit 9cbffc7a59561be9 ("driver core:
> Delete driver_deferred_probe_check_state()") fixes that.
FTR, this issue is now present in v6.0-rc1.
I haven't tried your newest series yet.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [relevance 0%]
* [PATCH v1 1/3] Revert "driver core: Delete driver_deferred_probe_check_state()"
@ 2022-07-27 18:50 80% ` Saravana Kannan
2022-08-15 10:58 0% ` Tony Lindgren
0 siblings, 1 reply; 25+ results
From: Saravana Kannan @ 2022-07-27 18:50 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson,
Pavel Machek, Len Brown, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Saravana Kannan, naresh.kamboju, kernel-team, linux-kernel,
linux-pm, netdev
This reverts commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b.
There are a few more issues to fix that have been reported in the thread
for the original series [1]. We'll need to fix those before this will
work. So, revert it for now.
[1] - https://lore.kernel.org/lkml/20220601070707.3946847-1-saravanak@google.com/
Signed-off-by: Saravana Kannan <saravanak@google.com>
---
drivers/base/dd.c | 30 ++++++++++++++++++++++++++++++
include/linux/device/driver.h | 1 +
2 files changed, 31 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 70f79fc71539..a8916d1bfdcb 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -274,12 +274,42 @@ static int __init deferred_probe_timeout_setup(char *str)
}
__setup("deferred_probe_timeout=", deferred_probe_timeout_setup);
+/**
+ * driver_deferred_probe_check_state() - Check deferred probe state
+ * @dev: device to check
+ *
+ * Return:
+ * * -ENODEV if initcalls have completed and modules are disabled.
+ * * -ETIMEDOUT if the deferred probe timeout was set and has expired
+ * and modules are enabled.
+ * * -EPROBE_DEFER in other cases.
+ *
+ * Drivers or subsystems can opt-in to calling this function instead of directly
+ * returning -EPROBE_DEFER.
+ */
+int driver_deferred_probe_check_state(struct device *dev)
+{
+ if (!IS_ENABLED(CONFIG_MODULES) && initcalls_done) {
+ dev_warn(dev, "ignoring dependency for device, assuming no driver\n");
+ return -ENODEV;
+ }
+
+ if (!driver_deferred_probe_timeout && initcalls_done) {
+ dev_warn(dev, "deferred probe timeout, ignoring dependency\n");
+ return -ETIMEDOUT;
+ }
+
+ return -EPROBE_DEFER;
+}
+EXPORT_SYMBOL_GPL(driver_deferred_probe_check_state);
+
static void deferred_probe_timeout_work_func(struct work_struct *work)
{
struct device_private *p;
fw_devlink_drivers_done();
+ driver_deferred_probe_timeout = 0;
driver_deferred_probe_trigger();
flush_work(&deferred_probe_work);
diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
index 7acaabde5396..2114d65b862f 100644
--- a/include/linux/device/driver.h
+++ b/include/linux/device/driver.h
@@ -242,6 +242,7 @@ driver_find_device_by_acpi_dev(struct device_driver *drv, const void *adev)
extern int driver_deferred_probe_timeout;
void driver_deferred_probe_add(struct device *dev);
+int driver_deferred_probe_check_state(struct device *dev);
void driver_init(void);
/**
--
2.37.1.359.gd136c6c3e2-goog
^ permalink raw reply related [relevance 80%]
* Re: [PATCH v2 3/9] net: mdio: Delete usage of driver_deferred_probe_check_state()
2022-07-05 9:11 77% ` Geert Uytterhoeven
(?)
@ 2022-07-13 1:40 0% ` Saravana Kannan
-1 siblings, 0 replies; 25+ results
From: Saravana Kannan @ 2022-07-13 1:40 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson,
Len Brown, Pavel Machek, Joerg Roedel, Will Deacon, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Linus Walleij, Hideaki YOSHIFUJI,
David Ahern, Android Kernel Team, Linux Kernel Mailing List,
Linux PM list, Linux IOMMU, netdev, open list:GPIO SUBSYSTEM,
Linux-Renesas
On Tue, Jul 5, 2022 at 2:11 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Saravana,
>
> On Wed, Jun 1, 2022 at 2:44 PM Saravana Kannan <saravanak@google.com> wrote:
> > Now that fw_devlink=on by default and fw_devlink supports interrupt
> > properties, the execution will never get to the point where
> > driver_deferred_probe_check_state() is called before the supplier has
> > probed successfully or before deferred probe timeout has expired.
> >
> > So, delete the call and replace it with -ENODEV.
> >
> > Signed-off-by: Saravana Kannan <saravanak@google.com>
>
> Thanks for your patch, which is now commit f8217275b57aa48d ("net:
> mdio: Delete usage of driver_deferred_probe_check_state()") in
> driver-core/driver-core-next.
>
> Seems like I missed something when providing my T-b for this series,
> sorry for that.
No worries. Appreciate any testing help.
>
> arch/arm/boot/dts/r8a7791-koelsch.dts has:
>
> ðer {
> pinctrl-0 = <ðer_pins>, <&phy1_pins>;
> pinctrl-names = "default";
>
> phy-handle = <&phy1>;
> renesas,ether-link-active-low;
> status = "okay";
>
> phy1: ethernet-phy@1 {
> compatible = "ethernet-phy-id0022.1537",
> "ethernet-phy-ieee802.3-c22";
> reg = <1>;
> interrupt-parent = <&irqc0>;
> interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> micrel,led-mode = <1>;
> reset-gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
> };
> };
>
> Despite the interrupts property, ðer is now probed before irqc0
> (interrupt-controller@e61c0000 in arch/arm/boot/dts/r8a7791.dtsi),
> causing the PHY not finding its interrupt, and resorting to polling:
I'd still expect the device link to have been created properly for
this phy device. Could you enable the logging in device_link_add() to
check the link is created between the phy and the IRQ?
My guess is that this probably has something to do with phys being
attached to drivers differently.
>
> -Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
> driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=185)
> +Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
> driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=POLL)
Can you drop a WARN() where this is printed to get the stack trace to
check my hypothesis?
-Saravana
>
> Reverting this commit, and commit 9cbffc7a59561be9 ("driver core:
> Delete driver_deferred_probe_check_state()") fixes that.
>
> > --- a/drivers/net/mdio/fwnode_mdio.c
> > +++ b/drivers/net/mdio/fwnode_mdio.c
> > @@ -47,9 +47,7 @@ int fwnode_mdiobus_phy_device_register(struct mii_bus *mdio,
> > * just fall back to poll mode
> > */
> > if (rc == -EPROBE_DEFER)
> > - rc = driver_deferred_probe_check_state(&phy->mdio.dev);
> > - if (rc == -EPROBE_DEFER)
> > - return rc;
> > + rc = -ENODEV;
> >
> > if (rc > 0) {
> > phy->irq = rc;
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply [relevance 0%]
* Re: [PATCH v20 2/5] usb: dwc3: core: Host wake up support from system suspend
[not found] ` <9f9f9abc-9b37-8bfb-3efa-6c860b5dba8d@quicinc.com>
@ 2022-07-13 1:34 0% ` Matthias Kaehlcke
0 siblings, 0 replies; 25+ results
From: Matthias Kaehlcke @ 2022-07-13 1:34 UTC (permalink / raw)
To: Krishna Kurapati PSSNV
Cc: Pavan Kondeti, saravanak, Stephen Boyd, Bjorn Andersson,
Felipe Balbi, Krzysztof Kozlowski, Rob Herring, Andy Gross,
Greg Kroah-Hartman, Doug Anderson, Mathias Nyman, devicetree,
linux-arm-msm, linux-usb, linux-kernel, linux-pm, quic_ppratap,
quic_vpulyala
On Fri, Jul 08, 2022 at 04:37:19PM +0530, Krishna Kurapati PSSNV wrote:
> On 7/6/2022 12:28 PM, Krishna Kurapati PSSNV wrote:
>
> On 7/1/2022 9:22 PM, Matthias Kaehlcke wrote:
>
> On Fri, Jul 01, 2022 at 03:45:26PM +0530, Pavan Kondeti wrote:
>
> On Thu, Jun 30, 2022 at 06:10:50PM -0700, Matthias Kaehlcke wrote:
>
> dwc3-qcom should wait for dwc3 core to call component_add() and then do
> whatever needs to be done once the dwc3 core is registered in the
> dwc3-qcom bind callback. Honestly this may all be a little overkill if
> there's only two drivers here, dwc3-qcom and dwc3 core. It could
> probably just be some callback from dwc3 core at the end of probe that
> calls some function in dwc3-qcom.
>
> Since the issue we are facing is that the ssphy device links are not ready
> causing the dwc3 probe not being invoked, can we add an API as Pavan
> suggested
> to check if deferred_probe listfor dwc3 device is empty or not andbased on
> that we can choose to defer our qcomprobe ? In this case, we don't need to
> touch the dwc3 core driver and would be making changesonly in qcom glue
> driver.
>
> As mentioned above, it shouldn't be necessary to add component support to
> all the glue drivers. An API to check for deferred probing is an option,
> however there is a possible race condition: When the dwc3-qcom driver checks
> for a deferred probe the core could still be probing, in that situation the
> glue would proceed before the core driver is ready. That could be avoided
> with the component based approach.
>
> The race can happen only if asynchronous probe is enabled, otherwise the
> child's probe happens synchronously in of_platform_populate()
>
> I was thinking about the case where the dwc3-qcom probe is initially deferred,
> then the deferred probe starts shortly after (asynchronously) and now the
> dwc3-qcom driver does its check. Probably it's not very likely to happen ...
>
>
> OTOH, would the below condition suffice for our needs here? if our device
> is not bounded to a driver, we check the state of initcalls and return
> either error or -EPROBE_DEFER
>
> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> index 7b6eff5..519a503 100644
> --- a/drivers/usb/dwc3/dwc3-qcom.c
> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> @@ -722,6 +722,9 @@ static int dwc3_qcom_of_register_core(struct platform_device
> *pdev)
> dev_err(dev, "failed to get dwc3 platform device\n");
> }
>
> + if (!qcom->dwc3->dev.driver)
> + return driver_deferred_probe_check_state(&qcom->dwc3->dev);
> +
> node_put:
> of_node_put(dwc3_np);
>
> I like the simplicity of it, no need for new APIs.
>
> The components based approach would be slightly safer, but in practice I
> think this should be good enough.
>
> Hi Pavan, Mathias,
> I have tested the suggested code and verified that it works on
> sc7180. I see that the API has been removed recently in the following
> patch :\
> commit 9cbffc7a59561be950ecc675d19a3d2b45202b2b
> Author: Saravana Kannan [1]<saravanak@google.com>
> Date: Wed Jun 1 00:07:05 2022 -0700
> driver core: Delete driver_deferred_probe_check_state()
> Can we make a patch and add it back to the kernel for this purpose ?
> Hi Saravana,
> Can you help suggest if we can revert your patch or make a new one to
> add back the function.
The cover letter [1] of the 'deferred_probe_timeout logic clean up'
series [2] has more context:
A lot of the deferred_probe_timeout logic is redundant with
fw_devlink=on. Also, enabling deferred_probe_timeout by default breaks
a few cases.
This series tries to delete the redundant logic, simplify the frameworks
that use driver_deferred_probe_check_state(), enable
deferred_probe_timeout=10 by default, and fixes the nfsroot failure
case.
The overall idea of this series is to replace the global behavior of
driver_deferred_probe_check_state() where all devices give up waiting on
supplier at the same time with a more granular behavior:
1. Devices with all their suppliers successfully probed by late_initcall
probe as usual and avoid unnecessary deferred probe attempts.
2. At or after late_initcall, in cases where boot would break because of
fw_devlink=on being strict about the ordering, we
a. Temporarily relax the enforcement to probe any unprobed devices
that can probe successfully in the current state of the system.
For example, when we boot with a NFS rootfs and no network device
has probed.
b. Go back to enforcing the ordering for any devices that haven't
probed.
3. After deferred probe timeout expires, we permanently give up waiting
on supplier devices without drivers. At this point, whatever devices
can probe without some of their optional suppliers end up probing.
In the case where module support is disabled, it's fairly
straightforward and all device probes are completed before the initcalls
are done.
[1] https://lore.kernel.org/all/20220601070707.3946847-1-saravanak@google.com/
[2] https://patchwork.kernel.org/project/linux-pm/list/?series=646471&archive=both&state=*
Does anything speak against returning -EPROBE_DEFER directly from dwc3-qcom's
probe()? Now with deferred_probe_timeout > 0 there should be at least no endless
probing.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 3/9] net: mdio: Delete usage of driver_deferred_probe_check_state()
@ 2022-07-05 9:11 77% ` Geert Uytterhoeven
0 siblings, 0 replies; 25+ results
From: Geert Uytterhoeven @ 2022-07-05 9:11 UTC (permalink / raw)
To: Saravana Kannan
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson,
Len Brown, Pavel Machek, Joerg Roedel, Will Deacon, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Linus Walleij, Hideaki YOSHIFUJI,
David Ahern, Android Kernel Team, Linux Kernel Mailing List,
Linux PM list, Linux IOMMU, netdev, open list:GPIO SUBSYSTEM,
Linux-Renesas
Hi Saravana,
On Wed, Jun 1, 2022 at 2:44 PM Saravana Kannan <saravanak@google.com> wrote:
> Now that fw_devlink=on by default and fw_devlink supports interrupt
> properties, the execution will never get to the point where
> driver_deferred_probe_check_state() is called before the supplier has
> probed successfully or before deferred probe timeout has expired.
>
> So, delete the call and replace it with -ENODEV.
>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
Thanks for your patch, which is now commit f8217275b57aa48d ("net:
mdio: Delete usage of driver_deferred_probe_check_state()") in
driver-core/driver-core-next.
Seems like I missed something when providing my T-b for this series,
sorry for that.
arch/arm/boot/dts/r8a7791-koelsch.dts has:
ðer {
pinctrl-0 = <ðer_pins>, <&phy1_pins>;
pinctrl-names = "default";
phy-handle = <&phy1>;
renesas,ether-link-active-low;
status = "okay";
phy1: ethernet-phy@1 {
compatible = "ethernet-phy-id0022.1537",
"ethernet-phy-ieee802.3-c22";
reg = <1>;
interrupt-parent = <&irqc0>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
micrel,led-mode = <1>;
reset-gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
};
};
Despite the interrupts property, ðer is now probed before irqc0
(interrupt-controller@e61c0000 in arch/arm/boot/dts/r8a7791.dtsi),
causing the PHY not finding its interrupt, and resorting to polling:
-Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=185)
+Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=POLL)
Reverting this commit, and commit 9cbffc7a59561be9 ("driver core:
Delete driver_deferred_probe_check_state()") fixes that.
> --- a/drivers/net/mdio/fwnode_mdio.c
> +++ b/drivers/net/mdio/fwnode_mdio.c
> @@ -47,9 +47,7 @@ int fwnode_mdiobus_phy_device_register(struct mii_bus *mdio,
> * just fall back to poll mode
> */
> if (rc == -EPROBE_DEFER)
> - rc = driver_deferred_probe_check_state(&phy->mdio.dev);
> - if (rc == -EPROBE_DEFER)
> - return rc;
> + rc = -ENODEV;
>
> if (rc > 0) {
> phy->irq = rc;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [relevance 77%]
* Re: [PATCH v2 3/9] net: mdio: Delete usage of driver_deferred_probe_check_state()
@ 2022-07-05 9:11 77% ` Geert Uytterhoeven
0 siblings, 0 replies; 25+ results
From: Geert Uytterhoeven @ 2022-07-05 9:11 UTC (permalink / raw)
To: Saravana Kannan
Cc: Andrew Lunn, Ulf Hansson, Rafael J. Wysocki, Linus Walleij,
Eric Dumazet, Pavel Machek, Will Deacon, Kevin Hilman,
Russell King, Jakub Kicinski, Paolo Abeni, Android Kernel Team,
Len Brown, Linux PM list, open list:GPIO SUBSYSTEM,
Hideaki YOSHIFUJI, Greg Kroah-Hartman, David Ahern,
Linux Kernel Mailing List, Linux-Renesas, Linux IOMMU, netdev,
David S. Miller, Heiner Kallweit
Hi Saravana,
On Wed, Jun 1, 2022 at 2:44 PM Saravana Kannan <saravanak@google.com> wrote:
> Now that fw_devlink=on by default and fw_devlink supports interrupt
> properties, the execution will never get to the point where
> driver_deferred_probe_check_state() is called before the supplier has
> probed successfully or before deferred probe timeout has expired.
>
> So, delete the call and replace it with -ENODEV.
>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
Thanks for your patch, which is now commit f8217275b57aa48d ("net:
mdio: Delete usage of driver_deferred_probe_check_state()") in
driver-core/driver-core-next.
Seems like I missed something when providing my T-b for this series,
sorry for that.
arch/arm/boot/dts/r8a7791-koelsch.dts has:
ðer {
pinctrl-0 = <ðer_pins>, <&phy1_pins>;
pinctrl-names = "default";
phy-handle = <&phy1>;
renesas,ether-link-active-low;
status = "okay";
phy1: ethernet-phy@1 {
compatible = "ethernet-phy-id0022.1537",
"ethernet-phy-ieee802.3-c22";
reg = <1>;
interrupt-parent = <&irqc0>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
micrel,led-mode = <1>;
reset-gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
};
};
Despite the interrupts property, ðer is now probed before irqc0
(interrupt-controller@e61c0000 in arch/arm/boot/dts/r8a7791.dtsi),
causing the PHY not finding its interrupt, and resorting to polling:
-Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=185)
+Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY
driver (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=POLL)
Reverting this commit, and commit 9cbffc7a59561be9 ("driver core:
Delete driver_deferred_probe_check_state()") fixes that.
> --- a/drivers/net/mdio/fwnode_mdio.c
> +++ b/drivers/net/mdio/fwnode_mdio.c
> @@ -47,9 +47,7 @@ int fwnode_mdiobus_phy_device_register(struct mii_bus *mdio,
> * just fall back to poll mode
> */
> if (rc == -EPROBE_DEFER)
> - rc = driver_deferred_probe_check_state(&phy->mdio.dev);
> - if (rc == -EPROBE_DEFER)
> - return rc;
> + rc = -ENODEV;
>
> if (rc > 0) {
> phy->irq = rc;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [relevance 77%]
Results 1-25 of 25 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2022-06-01 7:06 [PATCH v2 0/9] deferred_probe_timeout logic clean up Saravana Kannan via iommu
2022-06-01 7:06 ` [PATCH v2 3/9] net: mdio: Delete usage of driver_deferred_probe_check_state() Saravana Kannan
2022-07-05 9:11 77% ` Geert Uytterhoeven
2022-07-05 9:11 77% ` Geert Uytterhoeven
2022-07-13 1:40 0% ` Saravana Kannan
2022-08-15 8:38 0% ` Geert Uytterhoeven
2022-06-20 8:54 [PATCH v20 2/5] usb: dwc3: core: Host wake up support from system suspend Pavan Kondeti
2022-06-27 20:02 ` Stephen Boyd
2022-06-28 5:31 ` Pavan Kondeti
2022-06-29 22:15 ` Stephen Boyd
2022-06-30 18:13 ` Krishna Kurapati PSSNV
2022-07-01 1:10 ` Matthias Kaehlcke
2022-07-01 10:15 ` Pavan Kondeti
2022-07-01 15:52 ` Matthias Kaehlcke
[not found] ` <09f6a717-2bbb-6bd3-f7a8-5ac9e3db51f3@quicinc.com>
[not found] ` <9f9f9abc-9b37-8bfb-3efa-6c860b5dba8d@quicinc.com>
2022-07-13 1:34 0% ` Matthias Kaehlcke
2022-07-27 18:50 [PATCH v1 0/3] Bring back driver_deferred_probe_check_state() for now Saravana Kannan
2022-07-27 18:50 80% ` [PATCH v1 1/3] Revert "driver core: Delete driver_deferred_probe_check_state()" Saravana Kannan
2022-08-15 10:58 0% ` Tony Lindgren
2022-08-15 14:53 boot stuck at starting kernel, due to __genpd_dev_pm_attach? Colin Foster
2022-08-15 18:23 ` Pavel Machek
2022-08-16 0:27 86% ` Colin Foster
2022-08-16 0:43 0% ` Saravana Kannan
2022-08-17 5:48 0% ` Colin Foster
2022-08-16 6:21 78% Regression: PM: domains: Delete usage of driver_deferred_probe_check_state Peng Fan
2022-08-16 6:21 78% ` Peng Fan
2022-08-16 6:43 0% ` Peng Fan
2022-08-16 6:43 0% ` Peng Fan
2022-08-18 18:08 0% ` Saravana Kannan
2022-08-18 18:08 0% ` Saravana Kannan
2022-08-19 4:04 0% ` Bough Chen
2022-08-19 4:04 0% ` Bough Chen
2022-08-19 9:00 0% ` Peng Fan
2022-08-19 9:00 0% ` Peng Fan
2022-08-19 22:16 [PATCH v2 0/4] Bring back driver_deferred_probe_check_state() for now Saravana Kannan
2022-08-19 22:16 99% ` [PATCH v2 1/4] Revert "driver core: Delete driver_deferred_probe_check_state()" Saravana Kannan
2022-08-22 20:34 0% ` Doug Anderson
2022-08-23 9:02 0% ` Peng Fan
2022-08-28 18:23 Linux regressions report for mainline [2022-08-28] Regzbot (on behalf of Thorsten Leemhuis)
2022-08-28 18:41 ` Linus Torvalds
2022-08-28 19:08 88% ` Thorsten Leemhuis
2022-08-29 5:20 0% ` Greg KH
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.