diff mbox

earlycon issues in -next with amba-pl011 updates

Message ID 20150810232312.GB10728@bivouac.eciton.net (mailing list archive)
State New, archived
Headers show

Commit Message

Leif Lindholm Aug. 10, 2015, 11:23 p.m. UTC
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

Comments

Jun Nie Aug. 11, 2015, 1:48 a.m. UTC | #1
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
>
>
>
Marc Zyngier Sept. 3, 2015, 10:23 a.m. UTC | #2
On 11/08/15 02:48, Jun Nie wrote:
> 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.

[+ Greg KH]

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?


Thanks,

	M.
Greg KH Sept. 3, 2015, 3:52 p.m. UTC | #3
On Thu, Sep 03, 2015 at 11:23:15AM +0100, Marc Zyngier wrote:
> On 11/08/15 02:48, Jun Nie wrote:
> > 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.
> 
> [+ Greg KH]
> 
> 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.

thanks,

greg k-h
Marc Zyngier Sept. 3, 2015, 4:08 p.m. UTC | #4
On 03/09/15 16:52, Greg Kroah-Hartman wrote:
> On Thu, Sep 03, 2015 at 11:23:15AM +0100, Marc Zyngier wrote:
>> On 11/08/15 02:48, Jun Nie wrote:
>>> 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.
>>
>> [+ Greg KH]
>>
>> 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).

Thanks,

	M.
Peter Hurley Sept. 3, 2015, 5:49 p.m. UTC | #5
On 09/03/2015 12:08 PM, 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:
>>> On 11/08/15 02:48, Jun Nie wrote:
>>>> 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.
>>>
>>> [+ Greg KH]
>>>
>>> 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

Fix has been on list since Aug 10.

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


> 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).
> 
> Thanks,
> 
> 	M.
>
Greg KH Sept. 3, 2015, 5:53 p.m. UTC | #6
On Thu, Sep 03, 2015 at 01:49:02PM -0400, Peter Hurley wrote:
> On 09/03/2015 12:08 PM, 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:
> >>> On 11/08/15 02:48, Jun Nie wrote:
> >>>> 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.
> >>>
> >>> [+ Greg KH]
> >>>
> >>> 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
> 
> Fix has been on list since Aug 10.
> 
> http://www.spinics.net/lists/linux-serial/msg18576.html

Now if only someone would have at least compile tested it :)
Marc Zyngier Sept. 3, 2015, 6 p.m. UTC | #7
On 03/09/15 18:49, Peter Hurley wrote:
> On 09/03/2015 12:08 PM, 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:
>>>> On 11/08/15 02:48, Jun Nie wrote:
>>>>> 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.
>>>>
>>>> [+ Greg KH]
>>>>
>>>> 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
> 
> Fix has been on list since Aug 10.
> 
> http://www.spinics.net/lists/linux-serial/msg18576.html

... with both Leif and Russell outlining issues with this patch:

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

so maybe coming up with an updated series would have been a good move.

	M.
Peter Hurley Sept. 3, 2015, 6:03 p.m. UTC | #8
On 09/03/2015 01:53 PM, Greg Kroah-Hartman wrote:
> On Thu, Sep 03, 2015 at 01:49:02PM -0400, Peter Hurley wrote:
>> On 09/03/2015 12:08 PM, 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:
>>>>> On 11/08/15 02:48, Jun Nie wrote:
>>>>>> 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.
>>>>>
>>>>> [+ Greg KH]
>>>>>
>>>>> 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
>>
>> Fix has been on list since Aug 10.
>>
>> http://www.spinics.net/lists/linux-serial/msg18576.html
> 
> Now if only someone would have at least compile tested it :)

On 08/11/2015 06:07 AM, Leif Lindholm wrote:
> 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.

Russell wanted me to do a bunch of improvements, but I wrote that
should wait until 4.3-rc cycle.

Regards,
Peter Hurley
Peter Hurley Sept. 3, 2015, 6:15 p.m. UTC | #9
On 09/03/2015 02:00 PM, Marc Zyngier wrote:
> On 03/09/15 18:49, Peter Hurley wrote:
>> On 09/03/2015 12:08 PM, 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:
>>>>> On 11/08/15 02:48, Jun Nie wrote:
>>>>>> 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.
>>>>>
>>>>> [+ Greg KH]
>>>>>
>>>>> 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
>>
>> Fix has been on list since Aug 10.
>>
>> http://www.spinics.net/lists/linux-serial/msg18576.html
> 
> ... with both Leif and Russell outlining issues with this patch:
> 
> http://www.spinics.net/lists/linux-serial/msg18594.html
> http://www.spinics.net/lists/linux-serial/msg18599.html

Russell's suggestions were noted in my reply

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

> so maybe coming up with an updated series would have been a good move.

Feel free to work from where I left off.

Regards,
Peter Hurley
Marc Zyngier Sept. 3, 2015, 6:16 p.m. UTC | #10
On 03/09/15 19:03, Peter Hurley wrote:
> On 09/03/2015 01:53 PM, Greg Kroah-Hartman wrote:
>> On Thu, Sep 03, 2015 at 01:49:02PM -0400, Peter Hurley wrote:
>>> On 09/03/2015 12:08 PM, 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:
>>>>>> On 11/08/15 02:48, Jun Nie wrote:
>>>>>>> 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.
>>>>>>
>>>>>> [+ Greg KH]
>>>>>>
>>>>>> 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
>>>
>>> Fix has been on list since Aug 10.
>>>
>>> http://www.spinics.net/lists/linux-serial/msg18576.html
>>
>> Now if only someone would have at least compile tested it :)
> 
> On 08/11/2015 06:07 AM, Leif Lindholm wrote:
>> 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.
> 
> Russell wanted me to do a bunch of improvements, but I wrote that
> should wait until 4.3-rc cycle.

It is well known that we merge "improvements" outside of the merge
window. And what about starting with a series that is actually bisectable?

It is quite apparent that this code hasn't been tested enough, hasn't
been reviewed enough, and breaks a wide range of platforms (almost
anything that sits on and under my desk, TBH).

That's really for Greg to decide, but I'm not overly confident with the
state of this series as it stands.

Thanks,

	M.
Peter Hurley Sept. 3, 2015, 6:21 p.m. UTC | #11
On 09/03/2015 02:16 PM, Marc Zyngier wrote:
> On 03/09/15 19:03, Peter Hurley wrote:
>> On 09/03/2015 01:53 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Sep 03, 2015 at 01:49:02PM -0400, Peter Hurley wrote:
>>>> On 09/03/2015 12:08 PM, 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:
>>>>>>> On 11/08/15 02:48, Jun Nie wrote:
>>>>>>>> 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.
>>>>>>>
>>>>>>> [+ Greg KH]
>>>>>>>
>>>>>>> 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
>>>>
>>>> Fix has been on list since Aug 10.
>>>>
>>>> http://www.spinics.net/lists/linux-serial/msg18576.html
>>>
>>> Now if only someone would have at least compile tested it :)
>>
>> On 08/11/2015 06:07 AM, Leif Lindholm wrote:
>>> 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.
>>
>> Russell wanted me to do a bunch of improvements, but I wrote that
>> should wait until 4.3-rc cycle.
> 
> It is well known that we merge "improvements" outside of the merge
> window. And what about starting with a series that is actually bisectable?
> 
> It is quite apparent that this code hasn't been tested enough, hasn't
> been reviewed enough, and breaks a wide range of platforms (almost
> anything that sits on and under my desk, TBH).
> 
> That's really for Greg to decide, but I'm not overly confident with the
> state of this series as it stands.

If you feel the code is not reliable enough/tested/not bisectable/whatever,
I have no objection to reverting and starting again.

But if the issue is only wrt earlycon, then my patch ought to address that.

Regards,
Peter Hurley
Will Deacon Sept. 4, 2015, 11:06 a.m. UTC | #12
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?

Will
Russell King - ARM Linux Sept. 4, 2015, 11:13 a.m. UTC | #13
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."
Greg KH Sept. 4, 2015, 4:15 p.m. UTC | #14
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?

Ok, now reverted, I'll send the pull request later today.

thanks,

greg k-h
Will Deacon Sept. 4, 2015, 4:16 p.m. UTC | #15
On Fri, Sep 04, 2015 at 05:15:10PM +0100, Greg Kroah-Hartman wrote:
> 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:
> > > 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?
> 
> Ok, now reverted, I'll send the pull request later today.

Brilliant, thanks Greg.

Will
Jun Nie Sept. 5, 2015, 2:54 p.m. UTC | #16
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.
diff mbox

Patch

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)
 		;
 }