Re: linusw/devel boot bisection: v5.4-rc1-31-g6a41b6c5fc20 on rk3399-puma-haikou

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Thu, Oct 31, 2019 at 8:35 PM Chris Packham
<Chris.Packham@xxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 2019-10-31 at 11:41 -0700, kernelci.org bot wrote:

> > Breaking commit found:
> >
> > -------------------------------------------------------------------------------
> > commit 6a41b6c5fc20abced88fa0eed42ae5e5cb70b280
> > Author: Chris Packham <chris.packham@xxxxxxxxxxxxxxxxxxx>
> > Date:   Fri Oct 25 09:27:03 2019 +1300
> >
> >     gpio: Add xgs-iproc driver
> >
> >     This driver supports the Chip Common A GPIO controller present on a
> >     number of Broadcom switch ASICs with integrated SoCs. The controller is
> >     similar to the pinctrl-nsp-gpio and pinctrl-iproc-gpio blocks but
> >     different enough that a separate driver is required.
> >
> >     This has been ported from Broadcom's XLDK 5.0.3 retaining only the CCA
> >     support (pinctrl-iproc-gpio covers CCB).
> >
> >     Signed-off-by: Chris Packham <chris.packham@xxxxxxxxxxxxxxxxxxx>
> >     Link: https://lore.kernel.org/r/20191024202703.8017-3-chris.packham@xxxxxxxxxxxxxxxxxxx
> >     Acked-by: Scott Branden <scott.branden@xxxxxxxxxxxx>
> >     Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
>
> Hmm,
>
> I don't see how this commit would have caused the oops. The new driver
> shouldn't (and doesn't appear to be) run on any platform as nothing
> declares .compatible = "brcm,iproc-gpio-cca" (yet).

I think it looks really bogus as well.

Could it be that these systems are memory constrained such that
the kernel image just exactly right now collides with the upper
memory limit or corrupts its own ramdisk?

I suppose I can't ask the kernel robot to do any more detailed
debugging.

I can't see any problem with this patch.

Yours,
Linus Walleij