| Message ID | 20230608194519.10665-2-s.shtylyov@omp.ru |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,01/12] mmc: bcm2835: fix deferred probing | expand |
On 6/9/23 12:39 AM, Stefan Wahren wrote: [...] >> The driver overrides the error codes and IRQ0 returned by platform_get_irq() >> to -EINVAL, so if it returns -EPROBE_DEFER, the driver will fail the probe >> permanently instead of the deferred probing. Switch to propagating the error >> codes upstream. IRQ0 is no longer returned by platform_get_irq(), so we now >> can safely ignore it... >> >> Fixes: 660fc733bd74 ("mmc: bcm2835: Add new driver for the sdhost controller.") > > I know this is very theoretical, but does the statement "IRQ0 is no longer returned by platform_get_irq()" also applies to the time of the fixes commit? Unfortunately, no. IRQ0 finally ceased to be returned in 5.19; there was a fat warning in platform_get_irq() and friends before that (which is still there)... > I'm asking because the fix could be backported to Linux 4.14. I think the deferred probing can currently occur only with DT platforms (I may be wrong here). Is this your case? > Best regards > >> Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> [...] MBR, Sergey
Am 12.06.23 um 21:43 schrieb Sergey Shtylyov: > On 6/9/23 12:39 AM, Stefan Wahren wrote: > [...] > >>> The driver overrides the error codes and IRQ0 returned by platform_get_irq() >>> to -EINVAL, so if it returns -EPROBE_DEFER, the driver will fail the probe >>> permanently instead of the deferred probing. Switch to propagating the error >>> codes upstream. IRQ0 is no longer returned by platform_get_irq(), so we now >>> can safely ignore it... >>> >>> Fixes: 660fc733bd74 ("mmc: bcm2835: Add new driver for the sdhost controller.") >> >> I know this is very theoretical, but does the statement "IRQ0 is no longer returned by platform_get_irq()" also applies to the time of the fixes commit? > > Unfortunately, no. IRQ0 finally ceased to be returned in 5.19; there was a fat > warning in platform_get_irq() and friends before that (which is still there)... Okay, in this case the usage of the fixes tag is wrong. Maybe we should refer to the commit which changed platform_get_irq()? > >> I'm asking because the fix could be backported to Linux 4.14. > > I think the deferred probing can currently occur only with DT platforms > (I may be wrong here). Is this your case? AFAIK Raspberry Pi was always a DT platform in the mainline kernel. At least in Linux 4.14. > >> Best regards >> >>> Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> > [...] > > MBR, Sergey > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 6/13/23 11:56 AM, Stefan Wahren wrote: [...] >>>> The driver overrides the error codes and IRQ0 returned by platform_get_irq() >>>> to -EINVAL, so if it returns -EPROBE_DEFER, the driver will fail the probe >>>> permanently instead of the deferred probing. Switch to propagating the error >>>> codes upstream. IRQ0 is no longer returned by platform_get_irq(), so we now >>>> can safely ignore it... >>>> >>>> Fixes: 660fc733bd74 ("mmc: bcm2835: Add new driver for the sdhost controller.") >>> >>> I know this is very theoretical, but does the statement "IRQ0 is no longer returned by platform_get_irq()" also applies to the time of the fixes commit? >> >> Unfortunately, no. IRQ0 finally ceased to be returned in 5.19; there was a fat >> warning in platform_get_irq() and friends before that (which is still there)... > > Okay, in this case the usage of the fixes tag is wrong. Why? Returning -EPROBE_DEFER from platform_get_irq() predates this driver. > Maybe we should refer to the commit which changed platform_get_irq()? No, IRQ0 is a different issue than that I'm trying to solve here. >>> I'm asking because the fix could be backported to Linux 4.14. >> >> I think the deferred probing can currently occur only with DT platforms ACPI too (I was too lazy to look on the code yesterday). >> (I may be wrong here). Is this your case? > > AFAIK Raspberry Pi was always a DT platform in the mainline kernel. At least in Linux 4.14. Good to know. :-) >>> Best regards >>> >>>> Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> >> [...] MBR, Sergey
diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c index 8648f7e63ca1..eea208856ce0 100644 --- a/drivers/mmc/host/bcm2835.c +++ b/drivers/mmc/host/bcm2835.c @@ -1403,8 +1403,8 @@ static int bcm2835_probe(struct platform_device *pdev) host->max_clk = clk_get_rate(clk); host->irq = platform_get_irq(pdev, 0); - if (host->irq <= 0) { - ret = -EINVAL; + if (host->irq < 0) { + ret = host->irq; goto err; }
The driver overrides the error codes and IRQ0 returned by platform_get_irq() to -EINVAL, so if it returns -EPROBE_DEFER, the driver will fail the probe permanently instead of the deferred probing. Switch to propagating the error codes upstream. IRQ0 is no longer returned by platform_get_irq(), so we now can safely ignore it... Fixes: 660fc733bd74 ("mmc: bcm2835: Add new driver for the sdhost controller.") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> --- Changes in version 2: - refreshed the patch; - slightly reformatted the patch description. drivers/mmc/host/bcm2835.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)