The reason for this patch is xilinx_uartps driver which create one dynamic
instance per IP with unique major and minor combinations. drv->nr is in
this case all the time setup to 1. That means that uport->line is all the
time setup to 0 and drv->tty_driver->name_base is doing shift in name to
for example ttyPS3.
register_console() is looping over console_cmdline array and looking for
proper name/index combination which is in our case ttyPS/3.
That's why every instance of driver needs to be registered with proper
combination of name/number (ttyPS/3). Using uport->line is doing
registration with ttyPS/0 which is wrong that's why proper console index
should be used which is in cons->index field.
Also it is visible that recording console should be done based on
information about console not about the port but in most cases numbers are
the same and xilinx_uartps is only one exception now.
Signed-off-by: Michal Simek <[email protected]>
---
drivers/tty/serial/serial_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 4223cb496764..5ec447a4c5c3 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2825,7 +2825,8 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
lockdep_set_class(&uport->lock, &port_lock_key);
}
if (uport->cons && uport->dev)
- of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
+ of_console_check(uport->dev->of_node, uport->cons->name,
+ uport->cons->index);
uart_configure_port(drv, state, uport);
--
2.17.1
On Tue, Oct 15, 2019 at 11:19 AM Geert Uytterhoeven
<[email protected]> wrote:
> On Mon, Sep 2, 2019 at 4:29 PM Michal Simek <[email protected]> wrote:
> > The reason for this patch is xilinx_uartps driver which create one dynamic
> > instance per IP with unique major and minor combinations. drv->nr is in
> > this case all the time setup to 1. That means that uport->line is all the
> > time setup to 0 and drv->tty_driver->name_base is doing shift in name to
> > for example ttyPS3.
> >
> > register_console() is looping over console_cmdline array and looking for
> > proper name/index combination which is in our case ttyPS/3.
> > That's why every instance of driver needs to be registered with proper
> > combination of name/number (ttyPS/3). Using uport->line is doing
> > registration with ttyPS/0 which is wrong that's why proper console index
> > should be used which is in cons->index field.
> >
> > Also it is visible that recording console should be done based on
> > information about console not about the port but in most cases numbers are
> > the same and xilinx_uartps is only one exception now.
> >
> > Signed-off-by: Michal Simek <[email protected]>
>
> This is now commit 91daae03188e0dd1 ("serial: core: Use cons->index
> for preferred console registration") in tty-next.
>
> This has been bisected to break the serial console on (at least)
> r8a7791/koelsch and r8a7795/h3-salvator-xs.
>
> The line "printk: console [ttySC0] enabled" is no longer printed.
s/is no longer printed/no longer appears in the kernel log/, of course.
> The system continues booting without any serial console output, and the
> login prompt never appears on the serial console.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Michal,
On Mon, Sep 2, 2019 at 4:29 PM Michal Simek <[email protected]> wrote:
> The reason for this patch is xilinx_uartps driver which create one dynamic
> instance per IP with unique major and minor combinations. drv->nr is in
> this case all the time setup to 1. That means that uport->line is all the
> time setup to 0 and drv->tty_driver->name_base is doing shift in name to
> for example ttyPS3.
>
> register_console() is looping over console_cmdline array and looking for
> proper name/index combination which is in our case ttyPS/3.
> That's why every instance of driver needs to be registered with proper
> combination of name/number (ttyPS/3). Using uport->line is doing
> registration with ttyPS/0 which is wrong that's why proper console index
> should be used which is in cons->index field.
>
> Also it is visible that recording console should be done based on
> information about console not about the port but in most cases numbers are
> the same and xilinx_uartps is only one exception now.
>
> Signed-off-by: Michal Simek <[email protected]>
This is now commit 91daae03188e0dd1 ("serial: core: Use cons->index
for preferred console registration") in tty-next.
This has been bisected to break the serial console on (at least)
r8a7791/koelsch and r8a7795/h3-salvator-xs.
The line "printk: console [ttySC0] enabled" is no longer printed.
The system continues booting without any serial console output, and the
login prompt never appears on the serial console.
Reverting this commit fixes the issue.
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -2825,7 +2825,8 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
> lockdep_set_class(&uport->lock, &port_lock_key);
> }
> if (uport->cons && uport->dev)
> - of_console_check(uport->dev->of_node, uport->cons->name, uport->line);
> + of_console_check(uport->dev->of_node, uport->cons->name,
> + uport->cons->index);
>
> uart_configure_port(drv, state, uport);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Geert,
On 15. 10. 19 11:19, Geert Uytterhoeven wrote:
> Hi Michal,
>
> On Mon, Sep 2, 2019 at 4:29 PM Michal Simek <[email protected]> wrote:
>> The reason for this patch is xilinx_uartps driver which create one dynamic
>> instance per IP with unique major and minor combinations. drv->nr is in
>> this case all the time setup to 1. That means that uport->line is all the
>> time setup to 0 and drv->tty_driver->name_base is doing shift in name to
>> for example ttyPS3.
>>
>> register_console() is looping over console_cmdline array and looking for
>> proper name/index combination which is in our case ttyPS/3.
>> That's why every instance of driver needs to be registered with proper
>> combination of name/number (ttyPS/3). Using uport->line is doing
>> registration with ttyPS/0 which is wrong that's why proper console index
>> should be used which is in cons->index field.
>>
>> Also it is visible that recording console should be done based on
>> information about console not about the port but in most cases numbers are
>> the same and xilinx_uartps is only one exception now.
>>
>> Signed-off-by: Michal Simek <[email protected]>
>
> This is now commit 91daae03188e0dd1 ("serial: core: Use cons->index
> for preferred console registration") in tty-next.
>
> This has been bisected to break the serial console on (at least)
> r8a7791/koelsch and r8a7795/h3-salvator-xs.
>
> The line "printk: console [ttySC0] enabled" is no longer printed.
> The system continues booting without any serial console output, and the
> login prompt never appears on the serial console.
>
> Reverting this commit fixes the issue.
Sorry for trouble with this patch. Can you please point me to dts files
for these boards and also what's the value you have in uport->line and
uport->cons->index?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Hi Michal,
On Tue, Oct 15, 2019 at 11:22 AM Michal Simek <[email protected]> wrote:
> On 15. 10. 19 11:19, Geert Uytterhoeven wrote:
> > On Mon, Sep 2, 2019 at 4:29 PM Michal Simek <[email protected]> wrote:
> >> The reason for this patch is xilinx_uartps driver which create one dynamic
> >> instance per IP with unique major and minor combinations. drv->nr is in
> >> this case all the time setup to 1. That means that uport->line is all the
> >> time setup to 0 and drv->tty_driver->name_base is doing shift in name to
> >> for example ttyPS3.
> >>
> >> register_console() is looping over console_cmdline array and looking for
> >> proper name/index combination which is in our case ttyPS/3.
> >> That's why every instance of driver needs to be registered with proper
> >> combination of name/number (ttyPS/3). Using uport->line is doing
> >> registration with ttyPS/0 which is wrong that's why proper console index
> >> should be used which is in cons->index field.
> >>
> >> Also it is visible that recording console should be done based on
> >> information about console not about the port but in most cases numbers are
> >> the same and xilinx_uartps is only one exception now.
> >>
> >> Signed-off-by: Michal Simek <[email protected]>
> >
> > This is now commit 91daae03188e0dd1 ("serial: core: Use cons->index
> > for preferred console registration") in tty-next.
> >
> > This has been bisected to break the serial console on (at least)
> > r8a7791/koelsch and r8a7795/h3-salvator-xs.
> >
> > The line "printk: console [ttySC0] enabled" is no longer printed.
> > The system continues booting without any serial console output, and the
> > login prompt never appears on the serial console.
> >
> > Reverting this commit fixes the issue.
>
> Sorry for trouble with this patch. Can you please point me to dts files
> for these boards and also what's the value you have in uport->line and
arch/arm/boot/dts/r8a7791-koelsch.dts
arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
> uport->cons->index?
On r8a7791/koelsch:
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
platform serial8250: uport->line = 0, uport->cons->index = -1
platform serial8250: uport->line = 1, uport->cons->index = -1
platform serial8250: uport->line = 2, uport->cons->index = -1
platform serial8250: uport->line = 3, uport->cons->index = -1
SuperH (H)SCI(F) driver initialized
* sh-sci e6e60000.serial: uport->line = 0, uport->cons->index = -1
* e6e60000.serial: ttySC0 at MMIO 0xe6e60000 (irq = 79, base_baud =
0) is a scif
printk: console [ttySC0] enabled
sh-sci e6e68000.serial: uport->line = 1, uport->cons->index = 0
e6e68000.serial: ttySC1 at MMIO 0xe6e68000 (irq = 80, base_baud =
0) is a scif
On r8a7795/salvator-xs:
sh-sci e6550000.serial: uport->line = 1, uport->cons->index = -1
e6550000.serial: ttySC1 at MMIO 0xe6550000 (irq = 34, base_baud =
0) is a hscif
* sh-sci e6e88000.serial: uport->line = 0, uport->cons->index = -1
* e6e88000.serial: ttySC0 at MMIO 0xe6e88000 (irq = 120, base_baud =
0) is a scif
printk: console [ttySC0] enabled
Actual serial consoles marked with *.
There are no 8250 serial ports in the system, shmobile_defconfig just includes
driver support for it.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 15. 10. 19 11:51, Geert Uytterhoeven wrote:
> Hi Michal,
>
> On Tue, Oct 15, 2019 at 11:22 AM Michal Simek <[email protected]> wrote:
>> On 15. 10. 19 11:19, Geert Uytterhoeven wrote:
>>> On Mon, Sep 2, 2019 at 4:29 PM Michal Simek <[email protected]> wrote:
>>>> The reason for this patch is xilinx_uartps driver which create one dynamic
>>>> instance per IP with unique major and minor combinations. drv->nr is in
>>>> this case all the time setup to 1. That means that uport->line is all the
>>>> time setup to 0 and drv->tty_driver->name_base is doing shift in name to
>>>> for example ttyPS3.
>>>>
>>>> register_console() is looping over console_cmdline array and looking for
>>>> proper name/index combination which is in our case ttyPS/3.
>>>> That's why every instance of driver needs to be registered with proper
>>>> combination of name/number (ttyPS/3). Using uport->line is doing
>>>> registration with ttyPS/0 which is wrong that's why proper console index
>>>> should be used which is in cons->index field.
>>>>
>>>> Also it is visible that recording console should be done based on
>>>> information about console not about the port but in most cases numbers are
>>>> the same and xilinx_uartps is only one exception now.
>>>>
>>>> Signed-off-by: Michal Simek <[email protected]>
>>>
>>> This is now commit 91daae03188e0dd1 ("serial: core: Use cons->index
>>> for preferred console registration") in tty-next.
>>>
>>> This has been bisected to break the serial console on (at least)
>>> r8a7791/koelsch and r8a7795/h3-salvator-xs.
>>>
>>> The line "printk: console [ttySC0] enabled" is no longer printed.
>>> The system continues booting without any serial console output, and the
>>> login prompt never appears on the serial console.
>>>
>>> Reverting this commit fixes the issue.
>>
>> Sorry for trouble with this patch. Can you please point me to dts files
>> for these boards and also what's the value you have in uport->line and
>
> arch/arm/boot/dts/r8a7791-koelsch.dts
> arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
>
>> uport->cons->index?
>
> On r8a7791/koelsch:
>
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> platform serial8250: uport->line = 0, uport->cons->index = -1
> platform serial8250: uport->line = 1, uport->cons->index = -1
> platform serial8250: uport->line = 2, uport->cons->index = -1
> platform serial8250: uport->line = 3, uport->cons->index = -1
> SuperH (H)SCI(F) driver initialized
> * sh-sci e6e60000.serial: uport->line = 0, uport->cons->index = -1
> * e6e60000.serial: ttySC0 at MMIO 0xe6e60000 (irq = 79, base_baud =
> 0) is a scif
> printk: console [ttySC0] enabled
> sh-sci e6e68000.serial: uport->line = 1, uport->cons->index = 0
> e6e68000.serial: ttySC1 at MMIO 0xe6e68000 (irq = 80, base_baud =
> 0) is a scif
>
> On r8a7795/salvator-xs:
>
> sh-sci e6550000.serial: uport->line = 1, uport->cons->index = -1
> e6550000.serial: ttySC1 at MMIO 0xe6550000 (irq = 34, base_baud =
> 0) is a hscif
> * sh-sci e6e88000.serial: uport->line = 0, uport->cons->index = -1
> * e6e88000.serial: ttySC0 at MMIO 0xe6e88000 (irq = 120, base_baud =
> 0) is a scif
> printk: console [ttySC0] enabled
>
> Actual serial consoles marked with *.
>
> There are no 8250 serial ports in the system, shmobile_defconfig just includes
> driver support for it.
ok. I will take a look at why it is not initialized in this case. Do you
have any qemu available for these boards?
Greg: Please revert this patch I will investigate why it is failing.
Thanks,
Michal
Hi Michal,
On Tue, Oct 15, 2019 at 4:37 PM Michal Simek <[email protected]> wrote:
> On 15. 10. 19 11:51, Geert Uytterhoeven wrote:
> > On Tue, Oct 15, 2019 at 11:22 AM Michal Simek <[email protected]> wrote:
> >> On 15. 10. 19 11:19, Geert Uytterhoeven wrote:
> >>> On Mon, Sep 2, 2019 at 4:29 PM Michal Simek <[email protected]> wrote:
> >>>> The reason for this patch is xilinx_uartps driver which create one dynamic
> >>>> instance per IP with unique major and minor combinations. drv->nr is in
> >>>> this case all the time setup to 1. That means that uport->line is all the
> >>>> time setup to 0 and drv->tty_driver->name_base is doing shift in name to
> >>>> for example ttyPS3.
> >>>>
> >>>> register_console() is looping over console_cmdline array and looking for
> >>>> proper name/index combination which is in our case ttyPS/3.
> >>>> That's why every instance of driver needs to be registered with proper
> >>>> combination of name/number (ttyPS/3). Using uport->line is doing
> >>>> registration with ttyPS/0 which is wrong that's why proper console index
> >>>> should be used which is in cons->index field.
> >>>>
> >>>> Also it is visible that recording console should be done based on
> >>>> information about console not about the port but in most cases numbers are
> >>>> the same and xilinx_uartps is only one exception now.
> >>>>
> >>>> Signed-off-by: Michal Simek <[email protected]>
> >>>
> >>> This is now commit 91daae03188e0dd1 ("serial: core: Use cons->index
> >>> for preferred console registration") in tty-next.
> >>>
> >>> This has been bisected to break the serial console on (at least)
> >>> r8a7791/koelsch and r8a7795/h3-salvator-xs.
> >>>
> >>> The line "printk: console [ttySC0] enabled" is no longer printed.
> >>> The system continues booting without any serial console output, and the
> >>> login prompt never appears on the serial console.
> >>>
> >>> Reverting this commit fixes the issue.
> >>
> >> Sorry for trouble with this patch. Can you please point me to dts files
> >> for these boards and also what's the value you have in uport->line and
> >
> > arch/arm/boot/dts/r8a7791-koelsch.dts
> > arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
> >
> >> uport->cons->index?
> >
> > On r8a7791/koelsch:
> >
> > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> > platform serial8250: uport->line = 0, uport->cons->index = -1
> > platform serial8250: uport->line = 1, uport->cons->index = -1
> > platform serial8250: uport->line = 2, uport->cons->index = -1
> > platform serial8250: uport->line = 3, uport->cons->index = -1
> > SuperH (H)SCI(F) driver initialized
> > * sh-sci e6e60000.serial: uport->line = 0, uport->cons->index = -1
> > * e6e60000.serial: ttySC0 at MMIO 0xe6e60000 (irq = 79, base_baud =
> > 0) is a scif
> > printk: console [ttySC0] enabled
> > sh-sci e6e68000.serial: uport->line = 1, uport->cons->index = 0
> > e6e68000.serial: ttySC1 at MMIO 0xe6e68000 (irq = 80, base_baud =
> > 0) is a scif
> >
> > On r8a7795/salvator-xs:
> >
> > sh-sci e6550000.serial: uport->line = 1, uport->cons->index = -1
> > e6550000.serial: ttySC1 at MMIO 0xe6550000 (irq = 34, base_baud =
> > 0) is a hscif
> > * sh-sci e6e88000.serial: uport->line = 0, uport->cons->index = -1
> > * e6e88000.serial: ttySC0 at MMIO 0xe6e88000 (irq = 120, base_baud =
> > 0) is a scif
> > printk: console [ttySC0] enabled
> >
> > Actual serial consoles marked with *.
> >
> > There are no 8250 serial ports in the system, shmobile_defconfig just includes
> > driver support for it.
>
> ok. I will take a look at why it is not initialized in this case. Do you
> have any qemu available for these boards?
Not me. But Marek (CC) may have something.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, Oct 15, 2019 at 04:36:56PM +0200, Michal Simek wrote:
> On 15. 10. 19 11:51, Geert Uytterhoeven wrote:
> > Hi Michal,
> >
> > On Tue, Oct 15, 2019 at 11:22 AM Michal Simek <[email protected]> wrote:
> >> On 15. 10. 19 11:19, Geert Uytterhoeven wrote:
> >>> On Mon, Sep 2, 2019 at 4:29 PM Michal Simek <[email protected]> wrote:
> >>>> The reason for this patch is xilinx_uartps driver which create one dynamic
> >>>> instance per IP with unique major and minor combinations. drv->nr is in
> >>>> this case all the time setup to 1. That means that uport->line is all the
> >>>> time setup to 0 and drv->tty_driver->name_base is doing shift in name to
> >>>> for example ttyPS3.
> >>>>
> >>>> register_console() is looping over console_cmdline array and looking for
> >>>> proper name/index combination which is in our case ttyPS/3.
> >>>> That's why every instance of driver needs to be registered with proper
> >>>> combination of name/number (ttyPS/3). Using uport->line is doing
> >>>> registration with ttyPS/0 which is wrong that's why proper console index
> >>>> should be used which is in cons->index field.
> >>>>
> >>>> Also it is visible that recording console should be done based on
> >>>> information about console not about the port but in most cases numbers are
> >>>> the same and xilinx_uartps is only one exception now.
> >>>>
> >>>> Signed-off-by: Michal Simek <[email protected]>
> >>>
> >>> This is now commit 91daae03188e0dd1 ("serial: core: Use cons->index
> >>> for preferred console registration") in tty-next.
> >>>
> >>> This has been bisected to break the serial console on (at least)
> >>> r8a7791/koelsch and r8a7795/h3-salvator-xs.
> >>>
> >>> The line "printk: console [ttySC0] enabled" is no longer printed.
> >>> The system continues booting without any serial console output, and the
> >>> login prompt never appears on the serial console.
> >>>
> >>> Reverting this commit fixes the issue.
> >>
> >> Sorry for trouble with this patch. Can you please point me to dts files
> >> for these boards and also what's the value you have in uport->line and
> >
> > arch/arm/boot/dts/r8a7791-koelsch.dts
> > arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
> >
> >> uport->cons->index?
> >
> > On r8a7791/koelsch:
> >
> > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> > platform serial8250: uport->line = 0, uport->cons->index = -1
> > platform serial8250: uport->line = 1, uport->cons->index = -1
> > platform serial8250: uport->line = 2, uport->cons->index = -1
> > platform serial8250: uport->line = 3, uport->cons->index = -1
> > SuperH (H)SCI(F) driver initialized
> > * sh-sci e6e60000.serial: uport->line = 0, uport->cons->index = -1
> > * e6e60000.serial: ttySC0 at MMIO 0xe6e60000 (irq = 79, base_baud =
> > 0) is a scif
> > printk: console [ttySC0] enabled
> > sh-sci e6e68000.serial: uport->line = 1, uport->cons->index = 0
> > e6e68000.serial: ttySC1 at MMIO 0xe6e68000 (irq = 80, base_baud =
> > 0) is a scif
> >
> > On r8a7795/salvator-xs:
> >
> > sh-sci e6550000.serial: uport->line = 1, uport->cons->index = -1
> > e6550000.serial: ttySC1 at MMIO 0xe6550000 (irq = 34, base_baud =
> > 0) is a hscif
> > * sh-sci e6e88000.serial: uport->line = 0, uport->cons->index = -1
> > * e6e88000.serial: ttySC0 at MMIO 0xe6e88000 (irq = 120, base_baud =
> > 0) is a scif
> > printk: console [ttySC0] enabled
> >
> > Actual serial consoles marked with *.
> >
> > There are no 8250 serial ports in the system, shmobile_defconfig just includes
> > driver support for it.
>
> ok. I will take a look at why it is not initialized in this case. Do you
> have any qemu available for these boards?
>
> Greg: Please revert this patch I will investigate why it is failing.
Which patch exactly? Can you provide a revert? That makes it easiest
for me.
thanks,
greg k-h
On 15. 10. 19 19:54, Greg Kroah-Hartman wrote:
> On Tue, Oct 15, 2019 at 04:36:56PM +0200, Michal Simek wrote:
>> On 15. 10. 19 11:51, Geert Uytterhoeven wrote:
>>> Hi Michal,
>>>
>>> On Tue, Oct 15, 2019 at 11:22 AM Michal Simek <[email protected]> wrote:
>>>> On 15. 10. 19 11:19, Geert Uytterhoeven wrote:
>>>>> On Mon, Sep 2, 2019 at 4:29 PM Michal Simek <[email protected]> wrote:
>>>>>> The reason for this patch is xilinx_uartps driver which create one dynamic
>>>>>> instance per IP with unique major and minor combinations. drv->nr is in
>>>>>> this case all the time setup to 1. That means that uport->line is all the
>>>>>> time setup to 0 and drv->tty_driver->name_base is doing shift in name to
>>>>>> for example ttyPS3.
>>>>>>
>>>>>> register_console() is looping over console_cmdline array and looking for
>>>>>> proper name/index combination which is in our case ttyPS/3.
>>>>>> That's why every instance of driver needs to be registered with proper
>>>>>> combination of name/number (ttyPS/3). Using uport->line is doing
>>>>>> registration with ttyPS/0 which is wrong that's why proper console index
>>>>>> should be used which is in cons->index field.
>>>>>>
>>>>>> Also it is visible that recording console should be done based on
>>>>>> information about console not about the port but in most cases numbers are
>>>>>> the same and xilinx_uartps is only one exception now.
>>>>>>
>>>>>> Signed-off-by: Michal Simek <[email protected]>
>>>>>
>>>>> This is now commit 91daae03188e0dd1 ("serial: core: Use cons->index
>>>>> for preferred console registration") in tty-next.
>>>>>
>>>>> This has been bisected to break the serial console on (at least)
>>>>> r8a7791/koelsch and r8a7795/h3-salvator-xs.
>>>>>
>>>>> The line "printk: console [ttySC0] enabled" is no longer printed.
>>>>> The system continues booting without any serial console output, and the
>>>>> login prompt never appears on the serial console.
>>>>>
>>>>> Reverting this commit fixes the issue.
>>>>
>>>> Sorry for trouble with this patch. Can you please point me to dts files
>>>> for these boards and also what's the value you have in uport->line and
>>>
>>> arch/arm/boot/dts/r8a7791-koelsch.dts
>>> arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts
>>>
>>>> uport->cons->index?
>>>
>>> On r8a7791/koelsch:
>>>
>>> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>>> platform serial8250: uport->line = 0, uport->cons->index = -1
>>> platform serial8250: uport->line = 1, uport->cons->index = -1
>>> platform serial8250: uport->line = 2, uport->cons->index = -1
>>> platform serial8250: uport->line = 3, uport->cons->index = -1
>>> SuperH (H)SCI(F) driver initialized
>>> * sh-sci e6e60000.serial: uport->line = 0, uport->cons->index = -1
>>> * e6e60000.serial: ttySC0 at MMIO 0xe6e60000 (irq = 79, base_baud =
>>> 0) is a scif
>>> printk: console [ttySC0] enabled
>>> sh-sci e6e68000.serial: uport->line = 1, uport->cons->index = 0
>>> e6e68000.serial: ttySC1 at MMIO 0xe6e68000 (irq = 80, base_baud =
>>> 0) is a scif
>>>
>>> On r8a7795/salvator-xs:
>>>
>>> sh-sci e6550000.serial: uport->line = 1, uport->cons->index = -1
>>> e6550000.serial: ttySC1 at MMIO 0xe6550000 (irq = 34, base_baud =
>>> 0) is a hscif
>>> * sh-sci e6e88000.serial: uport->line = 0, uport->cons->index = -1
>>> * e6e88000.serial: ttySC0 at MMIO 0xe6e88000 (irq = 120, base_baud =
>>> 0) is a scif
>>> printk: console [ttySC0] enabled
>>>
>>> Actual serial consoles marked with *.
>>>
>>> There are no 8250 serial ports in the system, shmobile_defconfig just includes
>>> driver support for it.
>>
>> ok. I will take a look at why it is not initialized in this case. Do you
>> have any qemu available for these boards?
>>
>> Greg: Please revert this patch I will investigate why it is failing.
>
> Which patch exactly? Can you provide a revert? That makes it easiest
> for me.
Sure. Revert sent.
Thanks,
Michal