Re: [PATCH 1/2] soc: fsl: qbman: qman_portal: defer probing when qman is not available
From: Alexandre Belloni
Date: Wed Sep 26 2018 - 05:27:23 EST
On 25/09/2018 21:45:56+0200, Olof Johansson wrote:
> On Thu, Aug 23, 2018 at 11:36 PM Alexandre Belloni
> <alexandre.belloni@xxxxxxxxxxx> wrote:
> > If the qman driver (qman_ccsr) doesn't probe or fail to probe before
> > qman_portal, qm_ccsr_start will be either NULL or a stale pointer to an
> > unmapped page.
> > This leads to a crash when probing qman_portal as the init_pcfg function
> > calls qman_liodn_fixup that tries to read qman registers.
> > Assume that qman didn't probe when the pool mask is 0.
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx>
> > ---
> > drivers/soc/fsl/qbman/qman_portal.c | 2 ++
> > 1 file changed, 2 insertions(+)
> > diff --git a/drivers/soc/fsl/qbman/qman_portal.c b/drivers/soc/fsl/qbman/qman_portal.c
> > index a120002b630e..4fc80d2c8feb 100644
> > --- a/drivers/soc/fsl/qbman/qman_portal.c
> > +++ b/drivers/soc/fsl/qbman/qman_portal.c
> > @@ -277,6 +277,8 @@ static int qman_portal_probe(struct platform_device *pdev)
> > }
> > pcfg->pools = qm_get_pools_sdqcr();
> > + if (pcfg->pools == 0)
> > + return -EPROBE_DEFER;
> This is quite late in the probe, after a bunch of resources have been claimed.
> Note that the ioremaps above this are doing unwinds, and you'll end up
> doing duplicate ioremaps if you come in and probe again.
> You should probably unwind those allocations, or move them to devm_*
> or do this check earlier in the function.
The actual chance of having that happen is quite small (this was coming
from a non working DT) and I mainly wanted to avoid a crash so the
platform could still boot. I would think moving to devm_ would be the
right thing to do.
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering