| Message ID | 20250313094708.1003092-1-alexander.sverdlin@siemens.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Revert "bus: ti-sysc: Probe for l4_wkup and l4_cfg interconnect devices first" | expand |
Hi Alexander, Am Thu, 13 Mar 2025 10:47:06 +0100 schrieb "A. Sverdlin" <alexander.sverdlin@siemens.com>: > From: Alexander Sverdlin <alexander.sverdlin@siemens.com> > > This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. > > It brakes target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case > when minimally-configured system tries to network-boot: > brakes or breaks? To unterstand the severity of the issue... > [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs > [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs > [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) > [ 26.878471] Waiting up to 100 more seconds for network. > > Arbitrary 10 deferrals is really not a solution to any problem. So there is a point where no more probe of anything pending are triggered and therefore things are not probed? > Stable mmc enumeration can be achiever by filling /aliases node properly > (4700a00755fb commit's rationale). > yes, it does not look like a clean solution. And we have the proper aliases node in many places. What I am a bit wondering about is what kind of sleeping dogs we are going to wake up by this revert. So I think this should be tested a lot esp. about possible pm issues. Not every dependency in the sysc probe area is properly defined. Regards, Andreas
Hi Andreas! On Thu, 2025-03-13 at 20:21 +0100, Andreas Kemnade wrote: > > This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. > > > > It brakes target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case > > when minimally-configured system tries to network-boot: > > > brakes or breaks? To unterstand the severity of the issue... Thanks for the correction, it should have been "breaks"... > > [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs > > [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs > > [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) > > [ 26.878471] Waiting up to 100 more seconds for network. > > > > Arbitrary 10 deferrals is really not a solution to any problem. > > So there is a point where no more probe of anything pending are > triggered and therefore things are not probed? Because there is a point indeed (if we configure quite minimal set of drivers just enough to mount NFS) when deferred probes are not triggered any longer. > > Stable mmc enumeration can be achiever by filling /aliases node properly > > (4700a00755fb commit's rationale). > > > yes, it does not look like a clean solution. And we have the > proper aliases node in many places. What I am a bit wondering about is > what kind of sleeping dogs we are going to wake up by this revert. So I > think this should be tested a lot esp. about possible pm issues. > > Not every dependency in the sysc probe area is properly defined. But the patch I propose to revert is really not a solution for missing dependencies on syscons. I'm fine with not propagating this to stable, but reverting in master should give enough time for older SoCs to test, WDYT?
Am Thu, 13 Mar 2025 20:42:23 +0000 schrieb "Sverdlin, Alexander" <alexander.sverdlin@siemens.com>: > Hi Andreas! > > On Thu, 2025-03-13 at 20:21 +0100, Andreas Kemnade wrote: > > > This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. > > > > > > It brakes target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case > > > when minimally-configured system tries to network-boot: > > > > > brakes or breaks? To unterstand the severity of the issue... > > Thanks for the correction, it should have been "breaks"... > > > > [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs > > > [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs > > > [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) > > > [ 26.878471] Waiting up to 100 more seconds for network. > > > > > > Arbitrary 10 deferrals is really not a solution to any problem. > > > > So there is a point where no more probe of anything pending are > > triggered and therefore things are not probed? > > Because there is a point indeed (if we configure quite minimal set of drivers just > enough to mount NFS) when deferred probes are not triggered any longer. > > > > Stable mmc enumeration can be achiever by filling /aliases node properly > > > (4700a00755fb commit's rationale). > > > > > yes, it does not look like a clean solution. And we have the > > proper aliases node in many places. What I am a bit wondering about is > > what kind of sleeping dogs we are going to wake up by this revert. So I > > think this should be tested a lot esp. about possible pm issues. > > > > Not every dependency in the sysc probe area is properly defined. > > But the patch I propose to revert is really not a solution for missing > dependencies on syscons. I'm fine with not propagating this to stable, > but reverting in master should give enough time for older SoCs to test, > WDYT? > I am not against your revert proposal and not against propagating it to stable, I would just like to see some Tested-Bys before it gets applied to anything. If anything nasty pops up, it should be solved in a cleaner way then with the offending patch. Regards, Andreas
* Andreas Kemnade <andreas@kemnade.info> [250313 22:01]: > Am Thu, 13 Mar 2025 20:42:23 +0000 > schrieb "Sverdlin, Alexander" <alexander.sverdlin@siemens.com>: > > > Hi Andreas! > > > > On Thu, 2025-03-13 at 20:21 +0100, Andreas Kemnade wrote: > > > > This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. > > > > > > > > It brakes target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case > > > > when minimally-configured system tries to network-boot: > > > > > > > brakes or breaks? To unterstand the severity of the issue... > > > > Thanks for the correction, it should have been "breaks"... > > > > > > [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs > > > > [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs > > > > [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) > > > > [ 26.878471] Waiting up to 100 more seconds for network. > > > > > > > > Arbitrary 10 deferrals is really not a solution to any problem. > > > > > > So there is a point where no more probe of anything pending are > > > triggered and therefore things are not probed? > > > > Because there is a point indeed (if we configure quite minimal set of drivers just > > enough to mount NFS) when deferred probes are not triggered any longer. > > > > > > Stable mmc enumeration can be achiever by filling /aliases node properly > > > > (4700a00755fb commit's rationale). > > > > > > > yes, it does not look like a clean solution. And we have the > > > proper aliases node in many places. What I am a bit wondering about is > > > what kind of sleeping dogs we are going to wake up by this revert. So I > > > think this should be tested a lot esp. about possible pm issues. > > > > > > Not every dependency in the sysc probe area is properly defined. > > > > But the patch I propose to revert is really not a solution for missing > > dependencies on syscons. I'm fine with not propagating this to stable, > > but reverting in master should give enough time for older SoCs to test, > > WDYT? > > > I am not against your revert proposal and not against propagating it > to stable, I would just like to see some Tested-Bys before it gets > applied to anything. If anything nasty pops up, it should be solved in a > cleaner way then with the offending patch. Sounds like for the AM62x problem there is simply some resource missing that needs to be configured. Did you track down which resource is causing the deferred probe without the revert? Reverting the commit does not really fix the root cause. It just ignores the problem of the hierarchy of the interconnect instances. Some of the interconnect instances are always-on, and contain devices providing resources for the other interconnect devices. So I would not consider patching MMC aliases all over the place as an alternative to fixing the real problem :) Regards, Tony
On Wed, 2025-03-19 at 05:56 +0200, Tony Lindgren wrote: > > > > > This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. > > > > > > > > > > It brakes target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case > > > > > when minimally-configured system tries to network-boot: > > > > > > > > > brakes or breaks? To unterstand the severity of the issue... > > > > > > Thanks for the correction, it should have been "breaks"... > > > > > > > > [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs > > > > > [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs > > > > > [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) > > > > > [ 26.878471] Waiting up to 100 more seconds for network. > > > > > > > > > > Arbitrary 10 deferrals is really not a solution to any problem. > > > > > > > > So there is a point where no more probe of anything pending are > > > > triggered and therefore things are not probed? > > > > > > Because there is a point indeed (if we configure quite minimal set of drivers just > > > enough to mount NFS) when deferred probes are not triggered any longer. > > > > > > > > Stable mmc enumeration can be achiever by filling /aliases node properly > > > > > (4700a00755fb commit's rationale). > > > > > > > > > yes, it does not look like a clean solution. And we have the > > > > proper aliases node in many places. What I am a bit wondering about is > > > > what kind of sleeping dogs we are going to wake up by this revert. So I > > > > think this should be tested a lot esp. about possible pm issues. > > > > > > > > Not every dependency in the sysc probe area is properly defined. > > > > > > But the patch I propose to revert is really not a solution for missing > > > dependencies on syscons. I'm fine with not propagating this to stable, > > > but reverting in master should give enough time for older SoCs to test, > > > WDYT? > > > > > I am not against your revert proposal and not against propagating it > > to stable, I would just like to see some Tested-Bys before it gets > > applied to anything. If anything nasty pops up, it should be solved in a > > cleaner way then with the offending patch. > > Sounds like for the AM62x problem there is simply some resource missing > that needs to be configured. Did you track down which resource is causing > the deferred probe without the revert? There is no resource missing in am62x without the revert. > Reverting the commit does not really fix the root cause. It just ignores It does, because the real problem is the commit itself. It aimed to reduce the number of -EPROBEDEFER on am33x, but added much more on am62x (to the point it stops working). There is no point of doing arbitrary deferrals on one platform if it results in more deferrals on another. > the problem of the hierarchy of the interconnect instances. Some of the > interconnect instances are always-on, and contain devices providing > resources for the other interconnect devices. So I would not consider > patching MMC aliases all over the place as an alternative to fixing the > real problem :) If mmc aliases are missing and you experience unstable enumeration of those, this is the real problem and someone has to correct the aliases. I wonder, how this patch has passed the review if it has no other tags other then SoB?
Hi Tony, On Wed, 2025-03-19 at 05:56 +0200, Tony Lindgren wrote: > > > > > This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. > > > > > > > > > > It brakes target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case > > > > > when minimally-configured system tries to network-boot: > > > > > > > > > brakes or breaks? To unterstand the severity of the issue... > > > > > > Thanks for the correction, it should have been "breaks"... > > > > > > > > [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs > > > > > [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs > > > > > [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) > > > > > [ 26.878471] Waiting up to 100 more seconds for network. > > > > > > > > > > Arbitrary 10 deferrals is really not a solution to any problem. ... > Reverting the commit does not really fix the root cause. It just ignores > the problem of the hierarchy of the interconnect instances. Some of the > interconnect instances are always-on, and contain devices providing > resources for the other interconnect devices. So I would not consider > patching MMC aliases all over the place as an alternative to fixing the > real problem :) I suppose you still have the test case which didn't work for you back then? Because in this case I could help you with proper mmc aliases.
Hi Tony, On Wed, 2025-03-19 at 05:56 +0200, Tony Lindgren wrote: > > > > > This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. > > > > > > > > > > It brakes target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [1] > > > > > when minimally-configured system tries to network-boot: > > > > > > > > > brakes or breaks? To unterstand the severity of the issue... > > > > > > Thanks for the correction, it should have been "breaks"... > > > > > > > > [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs > > > > > [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs > > > > > [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) ^^^^^^^^^^^^^^^^^^^^^^ [2] > > > > > [ 26.878471] Waiting up to 100 more seconds for network. > > > > > > > > > > Arbitrary 10 deferrals is really not a solution to any problem. > > > > > > > > So there is a point where no more probe of anything pending are > > > > triggered and therefore things are not probed? > > > > > > Because there is a point indeed (if we configure quite minimal set of drivers just > > > enough to mount NFS) when deferred probes are not triggered any longer. > > > > > > > > Stable mmc enumeration can be achiever by filling /aliases node properly > > > > > (4700a00755fb commit's rationale). > > > > > > > > > yes, it does not look like a clean solution. And we have the > > > > proper aliases node in many places. What I am a bit wondering about is > > > > what kind of sleeping dogs we are going to wake up by this revert. So I > > > > think this should be tested a lot esp. about possible pm issues. > > > > > > > > Not every dependency in the sysc probe area is properly defined. > > > > > > But the patch I propose to revert is really not a solution for missing > > > dependencies on syscons. I'm fine with not propagating this to stable, > > > but reverting in master should give enough time for older SoCs to test, > > > WDYT? > > > > > I am not against your revert proposal and not against propagating it > > to stable, I would just like to see some Tested-Bys before it gets > > applied to anything. If anything nasty pops up, it should be solved in a > > cleaner way then with the offending patch. > > Sounds like for the AM62x problem there is simply some resource missing > that needs to be configured. Did you track down which resource is causing > the deferred probe without the revert? This "missing" resource is pointed out above in [1] and [2]. And it's missing only because of the arbitrary 10 deferrals, which simply do not happen on all systems if you'd configure less drivers or they are ordered in a way that 10 deferrals are not necessary in the DT. If your patch is "fixing the root cause", could you please elaborate the number "10"? Why is it 10 and not 11 or 11000000? Could it be "2" or "1" as well?
Am Wed, 19 Mar 2025 05:56:06 +0200 schrieb Tony Lindgren <tony@atomide.com>: > * Andreas Kemnade <andreas@kemnade.info> [250313 22:01]: > > Am Thu, 13 Mar 2025 20:42:23 +0000 > > schrieb "Sverdlin, Alexander" <alexander.sverdlin@siemens.com>: > > > > > Hi Andreas! > > > > > > On Thu, 2025-03-13 at 20:21 +0100, Andreas Kemnade wrote: > > > > > This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. > > > > > > > > > > It brakes target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case > > > > > when minimally-configured system tries to network-boot: > > > > > > > > > brakes or breaks? To unterstand the severity of the issue... > > > > > > Thanks for the correction, it should have been "breaks"... > > > > > > > > [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs > > > > > [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs > > > > > [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) > > > > > [ 26.878471] Waiting up to 100 more seconds for network. > > > > > > > > > > Arbitrary 10 deferrals is really not a solution to any problem. > > > > > > > > So there is a point where no more probe of anything pending are > > > > triggered and therefore things are not probed? > > > > > > Because there is a point indeed (if we configure quite minimal set of drivers just > > > enough to mount NFS) when deferred probes are not triggered any longer. > > > > > > > > Stable mmc enumeration can be achiever by filling /aliases node properly > > > > > (4700a00755fb commit's rationale). > > > > > > > > > yes, it does not look like a clean solution. And we have the > > > > proper aliases node in many places. What I am a bit wondering about is > > > > what kind of sleeping dogs we are going to wake up by this revert. So I > > > > think this should be tested a lot esp. about possible pm issues. > > > > > > > > Not every dependency in the sysc probe area is properly defined. > > > > > > But the patch I propose to revert is really not a solution for missing > > > dependencies on syscons. I'm fine with not propagating this to stable, > > > but reverting in master should give enough time for older SoCs to test, > > > WDYT? > > > > > I am not against your revert proposal and not against propagating it > > to stable, I would just like to see some Tested-Bys before it gets > > applied to anything. If anything nasty pops up, it should be solved in a > > cleaner way then with the offending patch. > > Sounds like for the AM62x problem there is simply some resource missing > that needs to be configured. Did you track down which resource is causing > the deferred probe without the revert? > I think you have not understand the real problem here. I guess, that problem can be provoked on other systems, too, if you just limit the devices to the absolute minimum required. The problem is as far as I understand a bit different. The problem is not a resource is missing totally, it is just the artificial deferral here. If there are just a minimum devices configured, you can come to a point where there is nothing to trigger a loop through all the deferred devices causing them to never probe. An arbitary, unrelated device with a driver popping up would unstall that deferral. I will just play around with the systems I have access to and if nothing pops up, I will add a Tested-By/Reviewed-By. If more serious problems pops up (I do not think so), another clean fix should get in before getting this reverted. > Reverting the commit does not really fix the root cause. It just ignores > the problem of the hierarchy of the interconnect instances. Some of the > interconnect instances are always-on, and contain devices providing > resources for the other interconnect devices. So I would not consider > patching MMC aliases all over the place as an alternative to fixing the > real problem :) > So what is the real problem you wanted to fix? MMC aliases are there at many places already. So is there anything besides MMC order? Regards, Andreas
* Sverdlin, Alexander <alexander.sverdlin@siemens.com> [250319 07:39]: > Hi Tony, > > On Wed, 2025-03-19 at 05:56 +0200, Tony Lindgren wrote: > > > > > > This reverts commit 4700a00755fb5a4bb5109128297d6fd2d1272ee6. > > > > > > > > > > > > It brakes target-module@2b300050 ("ti,sysc-omap2") probe on AM62x in a case > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [1] > > > > > > > when minimally-configured system tries to network-boot: > > > > > > > > > > > brakes or breaks? To unterstand the severity of the issue... > > > > > > > > Thanks for the correction, it should have been "breaks"... > > > > > > > > > > [ 6.888776] probe of 2b300050.target-module returned 517 after 258 usecs > > > > > > [ 17.129637] probe of 2b300050.target-module returned 517 after 708 usecs > > > > > > [ 17.137397] platform 2b300050.target-module: deferred probe pending: (reason unknown) > ^^^^^^^^^^^^^^^^^^^^^^ > > [2] > > > > > > > [ 26.878471] Waiting up to 100 more seconds for network. > > > > > > > > > > > > Arbitrary 10 deferrals is really not a solution to any problem. > > > > > > > > > > So there is a point where no more probe of anything pending are > > > > > triggered and therefore things are not probed? > > > > > > > > Because there is a point indeed (if we configure quite minimal set of drivers just > > > > enough to mount NFS) when deferred probes are not triggered any longer. > > > > > > > > > > Stable mmc enumeration can be achiever by filling /aliases node properly > > > > > > (4700a00755fb commit's rationale). > > > > > > > > > > > yes, it does not look like a clean solution. And we have the > > > > > proper aliases node in many places. What I am a bit wondering about is > > > > > what kind of sleeping dogs we are going to wake up by this revert. So I > > > > > think this should be tested a lot esp. about possible pm issues. > > > > > > > > > > Not every dependency in the sysc probe area is properly defined. > > > > > > > > But the patch I propose to revert is really not a solution for missing > > > > dependencies on syscons. I'm fine with not propagating this to stable, > > > > but reverting in master should give enough time for older SoCs to test, > > > > WDYT? > > > > > > > I am not against your revert proposal and not against propagating it > > > to stable, I would just like to see some Tested-Bys before it gets > > > applied to anything. If anything nasty pops up, it should be solved in a > > > cleaner way then with the offending patch. > > > > Sounds like for the AM62x problem there is simply some resource missing > > that needs to be configured. Did you track down which resource is causing > > the deferred probe without the revert? > > This "missing" resource is pointed out above in [1] and [2]. > And it's missing only because of the arbitrary 10 deferrals, which simply > do not happen on all systems if you'd configure less drivers or they are > ordered in a way that 10 deferrals are not necessary in the DT. Oh OK, sorry I misunderstood your problem. I thought you're missing some resources like clocks or regulators. I did not realize this issue can trigger on any system with just a few devices configured. > If your patch is "fixing the root cause", could you please elaborate the > number "10"? Why is it 10 and not 11 or 11000000? > Could it be "2" or "1" as well? Heh a random number enough to quiet down things was the original idea :) Does not exactly always work as you pointed out. Regards, Tony
* Andreas Kemnade <andreas@kemnade.info> [250319 08:17]: > Am Wed, 19 Mar 2025 05:56:06 +0200 > schrieb Tony Lindgren <tony@atomide.com>: > > Sounds like for the AM62x problem there is simply some resource missing > > that needs to be configured. Did you track down which resource is causing > > the deferred probe without the revert? > > > I think you have not understand the real problem here. I guess, that > problem can be provoked on other systems, too, if you just limit the > devices to the absolute minimum required. OK yup sorry I misunderstood the problem. > The problem is as far as I understand a bit different. The problem is > not a resource is missing totally, it is just the artificial deferral > here. If there are just a minimum devices configured, you can come to a > point where there is nothing to trigger a loop through all the deferred > devices causing them to never probe. > An arbitary, unrelated device with a driver popping up would unstall > that deferral. Thanks for clarifying, yes that is broken. > I will just play around with the systems I have access to and if nothing > pops up, I will add a Tested-By/Reviewed-By. If more serious problems > pops up (I do not think so), another clean fix should get in before > getting this reverted. Agreed now that I understand the probem :) Best to revert if no other issues are found except for increased deferred probe. > > Reverting the commit does not really fix the root cause. It just ignores > > the problem of the hierarchy of the interconnect instances. Some of the > > interconnect instances are always-on, and contain devices providing > > resources for the other interconnect devices. So I would not consider > > patching MMC aliases all over the place as an alternative to fixing the > > real problem :) > > > So what is the real problem you wanted to fix? MMC aliases are there at > many places already. So is there anything besides MMC order? The "real problem" is that the probe order should consider the always-on interconnect instances first. They provide resources for the other interconnect instances. Ideally there would be a proper bus driver to take care of that instead of relying on deferred probe. Regards, Tony
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c index f67b927ae4caa..e5c02e950f2c1 100644 --- a/drivers/bus/ti-sysc.c +++ b/drivers/bus/ti-sysc.c @@ -677,51 +677,6 @@ static int sysc_parse_and_check_child_range(struct sysc *ddata) return 0; } -/* Interconnect instances to probe before l4_per instances */ -static struct resource early_bus_ranges[] = { - /* am3/4 l4_wkup */ - { .start = 0x44c00000, .end = 0x44c00000 + 0x300000, }, - /* omap4/5 and dra7 l4_cfg */ - { .start = 0x4a000000, .end = 0x4a000000 + 0x300000, }, - /* omap4 l4_wkup */ - { .start = 0x4a300000, .end = 0x4a300000 + 0x30000, }, - /* omap5 and dra7 l4_wkup without dra7 dcan segment */ - { .start = 0x4ae00000, .end = 0x4ae00000 + 0x30000, }, -}; - -static atomic_t sysc_defer = ATOMIC_INIT(10); - -/** - * sysc_defer_non_critical - defer non_critical interconnect probing - * @ddata: device driver data - * - * We want to probe l4_cfg and l4_wkup interconnect instances before any - * l4_per instances as l4_per instances depend on resources on l4_cfg and - * l4_wkup interconnects. - */ -static int sysc_defer_non_critical(struct sysc *ddata) -{ - struct resource *res; - int i; - - if (!atomic_read(&sysc_defer)) - return 0; - - for (i = 0; i < ARRAY_SIZE(early_bus_ranges); i++) { - res = &early_bus_ranges[i]; - if (ddata->module_pa >= res->start && - ddata->module_pa <= res->end) { - atomic_set(&sysc_defer, 0); - - return 0; - } - } - - atomic_dec_if_positive(&sysc_defer); - - return -EPROBE_DEFER; -} - static struct device_node *stdout_path; static void sysc_init_stdout_path(struct sysc *ddata) @@ -947,10 +902,6 @@ static int sysc_map_and_check_registers(struct sysc *ddata) if (error) return error; - error = sysc_defer_non_critical(ddata); - if (error) - return error; - sysc_check_children(ddata); if (!of_property_present(np, "reg"))