earlycon issues in -next with amba-pl011 updates

Hi all,

The kernelci.org bot picked up a complete boot failure (no output past
UEFI stub) with next-20150806 and Tyler bisected it down to somewhere
in
8cd90e5 uart: pl011: Add support to ZTE ZX296702 uart
09dcc7d uart: pl011: Improve LCRH register access decision
2c096a9 uart: pl011: Introduce register look up table
7b753f3 uart: pl011: Introduce register accessor

The issue only appears with earlycon on command line, for pl011
consoles.

Some investigation shows that the cause lies with
commit 7b753f318d14 ("uart: pl011: Introduce register accessor")
and
commit 2c096a9eedc6 ("uart: pl011: Introduce register look up table")

Specifically, the changes to pl011_putc() are incorrect:
The new pl011_ accessors take a (struct uart_amba_port *) input, but
pl011_putc() directly uses the incoming (struct uart_port *) for this.

Apart from ending up with an unintended/incorrect UART base address,
the introduction of the lookup table for register offsets also means
the accessors try to dereference (struct uart_amba_port *)->reg_lut.

The below is a hack that shows/resolves the issue, but some
refactoring of the original patches might be in order.

/
    Leif

2015-08-11 7:23 GMT+08:00 Leif Lindholm <leif.lindholm@linaro.org>:
> Hi all,
>
> The kernelci.org bot picked up a complete boot failure (no output past
> UEFI stub) with next-20150806 and Tyler bisected it down to somewhere
> in
> 8cd90e5 uart: pl011: Add support to ZTE ZX296702 uart
> 09dcc7d uart: pl011: Improve LCRH register access decision
> 2c096a9 uart: pl011: Introduce register look up table
> 7b753f3 uart: pl011: Introduce register accessor
>
> The issue only appears with earlycon on command line, for pl011
> consoles.
>
> Some investigation shows that the cause lies with
> commit 7b753f318d14 ("uart: pl011: Introduce register accessor")
> and
> commit 2c096a9eedc6 ("uart: pl011: Introduce register look up table")
>
> Specifically, the changes to pl011_putc() are incorrect:
> The new pl011_ accessors take a (struct uart_amba_port *) input, but
> pl011_putc() directly uses the incoming (struct uart_port *) for this.
>
> Apart from ending up with an unintended/incorrect UART base address,
> the introduction of the lookup table for register offsets also means
> the accessors try to dereference (struct uart_amba_port *)->reg_lut.
>
> The below is a hack that shows/resolves the issue, but some
> refactoring of the original patches might be in order.
>
> /
>     Leif

Leif,

Sorry for the inconvenience. I do not have idea of early console till
now and I always have debug console for early panic debug. Learned
more from this issue.

Suppose Peter's patch will resolve your issue.

Jun

>
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 2af09ab..452dbba 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -2348,13 +2348,14 @@ static struct console amba_console = {
>
>  static void pl011_putc(struct uart_port *port, int c)
>  {
> -       struct uart_amba_port *uap =
> -           container_of(port, struct uart_amba_port, port);
> +       struct uart_amba_port uap;
> +       uap.port = *port;
> +       uap.reg_lut = arm_reg;
>
> -       while (pl011_readw(uap, REG_FR) & UART01x_FR_TXFF)
> +       while (pl011_readw(&uap, REG_FR) & UART01x_FR_TXFF)
>                 ;
> -       pl011_writeb(uap, c, REG_DR);
> -       while (pl011_readw(uap, REG_FR) & uap->fr_busy)
> +       pl011_writeb(&uap, c, REG_DR);
> +       while (pl011_readw(&uap, REG_FR) & UART01x_FR_BUSY)
>                 ;
>  }
>
> --
> 2.1.4
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Peter,

On Mon, Aug 10, 2015 at 08:31:03PM -0400, Peter Hurley wrote:
> > The issue only appears with earlycon on command line, for pl011
> > consoles.
> > 
> > Some investigation shows that the cause lies with
> > commit 7b753f318d14 ("uart: pl011: Introduce register accessor")
> > and
> > commit 2c096a9eedc6 ("uart: pl011: Introduce register look up table")
> > 
> > Specifically, the changes to pl011_putc() are incorrect:
> > The new pl011_ accessors take a (struct uart_amba_port *) input, but
> > pl011_putc() directly uses the incoming (struct uart_port *) for this.
> > 
> > Apart from ending up with an unintended/incorrect UART base address,
> > the introduction of the lookup table for register offsets also means
> > the accessors try to dereference (struct uart_amba_port *)->reg_lut.
> 
> 
> Thanks for the bug report and bisect, and apologies for the breakage;
> I should have caught that on review.

I wouldn't have found it if I didn't have the boot failure to track
down, and I'm _not_ going to tell you how long I spent doing that.
 
> Would you please test the patch below and see if that resolves the
> problem for you?

Yeah, that's a more straightforward fix.

> PS - _NOT_ even compile-tested, sorry.
> 
> --- >% ---
> Subject: [PATCH] serial: pl011: Fix earlycon register LUT breakage
> 
> Commit 7b753f318d14 ("uart: pl011: Introduce register accessor")
> mistakenly used the register LUT i/o accessors for the pl011
> earlycon. Since the port has not been probed at earlycon time,
> the struct uart_amba_port (and register LUTs) are uninitialized.
> 
> Use direct register addressing for pl011 earlycon; other h/w supported
> by the amba-pl011 driver should declare an alternate earlycon.
> 
> Cc: Jun Nie <jun.nie@linaro.org>
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> ---
>  drivers/tty/serial/amba-pl011.c | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 2af09ab..fd54991 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -2348,13 +2348,10 @@ static struct console amba_console = {
>  
>  static void pl011_putc(struct uart_port *port, int c)
>  {
> -	struct uart_amba_port *uap =
> -	    container_of(port, struct uart_amba_port, port);
> -
> -	while (pl011_readw(uap, REG_FR) & UART01x_FR_TXFF)
> +	while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
>  		;
> -	pl011_writeb(uap, c, REG_DR);
> -	while (pl011_readw(uap, REG_FR) & uap->fr_busy)
> +	writeb(c, port->membase + UART01x_DR);
> +	while (readl(port->membase + UART01x_FR) & UART01x_FR_BUSY)
>  		;
>  }
>  
> -- 
> 2.5.0

It works, but builds with:
drivers/tty/serial/amba-pl011.c:329:13: warning: ‘pl011_writeb’
defined but not used [-Wunused-function]
 static void pl011_writeb(struct uart_amba_port *uap, u8 val, int
 index)
             ^
I was dithering about whether having _relaxed accessors in post boot
code and plain ones in earlycon was an issue, but I guess it doesn't
matter much.

/
    Leif
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, Sep 04, 2015 at 12:06:52PM +0100, Will Deacon wrote:
> On Thu, Sep 03, 2015 at 05:08:53PM +0100, Marc Zyngier wrote:
> > On 03/09/15 16:52, Greg Kroah-Hartman wrote:
> > > On Thu, Sep 03, 2015 at 11:23:15AM +0100, Marc Zyngier wrote:
> > >> So -next has now been broken for a while on a number of ARM platforms
> > >> because of this (they simply cannot boot), and no progress has been made
> > >> towards resolving this problem.
> > >>
> > >> Can we please drop this series (at least commits 7b753f3 and following)
> > >> from -next until is has been reworked and reviewed?
> > > 
> > > I don't have any patches in my -next tree, everything is in Linus's tree
> > > now.  So if I've missed something, or need to revert something, please
> > > let me know specifcally what to do.
> > 
> > Gahhh... Given that there is no obvious fix, that the discussion has
> > stalled and that the author of the series is apparently away, the
> > following patches should be reverted:
> > 
> > 8cd90e50d140 uart: pl011: Add support to ZTE ZX296702 uart
> > 09dcc7dfc05b uart: pl011: Improve LCRH register access decision
> > 2c096a9eedc6 uart: pl011: Introduce register look up table
> > 7b753f318d14 uart: pl011: Introduce register accessor
> > 534e14e2293d uart: pl011: Rename regs with enumeration
> > 
> > (7b753f318d14 being the one breaking everything, but it makes more sense
> > to revert the whole series until it is properly fixed and reviewed).
> 
> For the reverts (git revert 534e14e2293d~1..8cd90e50d140):
> 
>   Acked-by: Will Deacon <will.deacon@arm.com>
>   Tested-by: Will Deacon <will.deacon@arm.com>
> 
> We can discuss what could've and should've happened 'til we're blue in
> the face but, in the meantime, I'd like my serial console back.
> 
> Greg -- any chance you could send these for -rc1, please?

Given the number of reviews the patches went through, I eventually came
to the conclusion that it would be far better if I were to write the
set of patches for the driver - but I haven't had a slot to do that.
I basically stopped reviewing them because I decided it wasn't worth
spending the time anymore on the series.  That wasn't an implicit
"I'm happy with the patch set" but more a "I've given up with this
patch set, it's still not up to scratch."

2015-09-04 19:13 GMT+08:00 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Fri, Sep 04, 2015 at 12:06:52PM +0100, Will Deacon wrote:
>> On Thu, Sep 03, 2015 at 05:08:53PM +0100, Marc Zyngier wrote:
>> > On 03/09/15 16:52, Greg Kroah-Hartman wrote:
>> > > On Thu, Sep 03, 2015 at 11:23:15AM +0100, Marc Zyngier wrote:
>> > >> So -next has now been broken for a while on a number of ARM platforms
>> > >> because of this (they simply cannot boot), and no progress has been made
>> > >> towards resolving this problem.
>> > >>
>> > >> Can we please drop this series (at least commits 7b753f3 and following)
>> > >> from -next until is has been reworked and reviewed?
>> > >
>> > > I don't have any patches in my -next tree, everything is in Linus's tree
>> > > now.  So if I've missed something, or need to revert something, please
>> > > let me know specifcally what to do.
>> >
>> > Gahhh... Given that there is no obvious fix, that the discussion has
>> > stalled and that the author of the series is apparently away, the
>> > following patches should be reverted:
>> >
>> > 8cd90e50d140 uart: pl011: Add support to ZTE ZX296702 uart
>> > 09dcc7dfc05b uart: pl011: Improve LCRH register access decision
>> > 2c096a9eedc6 uart: pl011: Introduce register look up table
>> > 7b753f318d14 uart: pl011: Introduce register accessor
>> > 534e14e2293d uart: pl011: Rename regs with enumeration
>> >
>> > (7b753f318d14 being the one breaking everything, but it makes more sense
>> > to revert the whole series until it is properly fixed and reviewed).
>>
>> For the reverts (git revert 534e14e2293d~1..8cd90e50d140):
>>
>>   Acked-by: Will Deacon <will.deacon@arm.com>
>>   Tested-by: Will Deacon <will.deacon@arm.com>
>>
>> We can discuss what could've and should've happened 'til we're blue in
>> the face but, in the meantime, I'd like my serial console back.
>>
>> Greg -- any chance you could send these for -rc1, please?
>
> Given the number of reviews the patches went through, I eventually came
> to the conclusion that it would be far better if I were to write the
> set of patches for the driver - but I haven't had a slot to do that.
> I basically stopped reviewing them because I decided it wasn't worth
> spending the time anymore on the series.  That wasn't an implicit
> "I'm happy with the patch set" but more a "I've given up with this
> patch set, it's still not up to scratch."

Russell,

Thanks for your time for reviewing that patch set. I did made some
mistake for the register naming for not understand your intention
clearly. I thought reviewing out of date patches also made you
desperate because I update patches frequently. Anyway, the existing
merged patches are made per your suggestion except the bugs. Could you
help comments for the below patch set even they are already merged? So
that I can polish existing code or re-prepare those changes. Or you
have other plan on supporting pl011 controller with different register
mapping? Thanks for you any comments!

http://www.spinics.net/lists/linux-serial/msg18363.html

Jun

>
> --
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html