| Message ID | 20241204155806.3781200-1-claudiu.beznea.uj@bp.renesas.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | serial: sh-sci: Fixes for earlycon and keep_bootcon | expand |
Hi Claudiu, > in the following scenarios: > > 1/ "earlycon keep_bootcon" were present in bootargs > 2/ only "earlycon" was present in bootargs > 3/ none of the "earlycon" or "earlycon keep_bootcon" were present in > bootargs ... > Please give it a try on your devices as well. Will happily do so. Is there something to look for? Except for "it works"? Happy hacking, Wolfram
Hi, Wolfram, On 04.12.2024 23:38, Wolfram Sang wrote: > Hi Claudiu, > >> in the following scenarios: >> >> 1/ "earlycon keep_bootcon" were present in bootargs >> 2/ only "earlycon" was present in bootargs >> 3/ none of the "earlycon" or "earlycon keep_bootcon" were present in >> bootargs > ... >> Please give it a try on your devices as well. > > Will happily do so. Is there something to look for? Except for "it > works"? As this code touches the earlycon functionality, of interest are the 3 cases highlighted above: 1/ "earlycon keep_bootcon" are both present in bootargs 2/ only "earlycon" is present in bootargs 3/ none of the "earlycon" or "earlycon keep_bootcon" are present in bootargs One other thing, that I was currently able to test only on RZ/G3S, is to see how it behaves when the debug serial is described in DT with an alias other than zero. E.g., on [1] the debug serial alias on RZ/G3S was changed from 0 to 3. With the new alias (3) there were issues that I've tried to fix with this series. Thank you for checking it, Claudiu [1] https://lore.kernel.org/all/20241115134401.3893008-6-claudiu.beznea.uj@bp.renesas.com/ > > Happy hacking, > > Wolfram >
Hi, Wolfram, On 05.12.2024 10:39, Claudiu Beznea wrote: > Hi, Wolfram, > > On 04.12.2024 23:38, Wolfram Sang wrote: >> Hi Claudiu, >> >>> in the following scenarios: >>> >>> 1/ "earlycon keep_bootcon" were present in bootargs >>> 2/ only "earlycon" was present in bootargs >>> 3/ none of the "earlycon" or "earlycon keep_bootcon" were present in >>> bootargs >> ... >>> Please give it a try on your devices as well. >> >> Will happily do so. Is there something to look for? Except for "it >> works"? Sorry, I noticed I missed to provide a clear answer your question: if boot works for this scenarios we should be OK. > > As this code touches the earlycon functionality, of interest are the 3 > cases highlighted above: > > 1/ "earlycon keep_bootcon" are both present in bootargs > 2/ only "earlycon" is present in bootargs > 3/ none of the "earlycon" or "earlycon keep_bootcon" are present in > bootargs > > One other thing, that I was currently able to test only on RZ/G3S, is to > see how it behaves when the debug serial is described in DT with an alias > other than zero. E.g., on [1] the debug serial alias on RZ/G3S was changed > from 0 to 3. With the new alias (3) there were issues that I've tried to > fix with this series. If you can also check: - it boots in this case and - the serial device with alias zero and the debug serial are both working (tx, rx are working) after boot then we can declare it OK as well. Thank you, Claudiu > > Thank you for checking it, > Claudiu > > [1] > https://lore.kernel.org/all/20241115134401.3893008-6-claudiu.beznea.uj@bp.renesas.com/ > >> >> Happy hacking, >> >> Wolfram >>
Hi Claudiu, On Thu, Dec 5, 2024 at 9:39 AM Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote: > On 04.12.2024 23:38, Wolfram Sang wrote: > >> in the following scenarios: > >> > >> 1/ "earlycon keep_bootcon" were present in bootargs > >> 2/ only "earlycon" was present in bootargs > >> 3/ none of the "earlycon" or "earlycon keep_bootcon" were present in > >> bootargs > > ... > >> Please give it a try on your devices as well. > > > > Will happily do so. Is there something to look for? Except for "it > > works"? > > As this code touches the earlycon functionality, of interest are the 3 > cases highlighted above: > > 1/ "earlycon keep_bootcon" are both present in bootargs > 2/ only "earlycon" is present in bootargs > 3/ none of the "earlycon" or "earlycon keep_bootcon" are present in > bootargs > > One other thing, that I was currently able to test only on RZ/G3S, is to > see how it behaves when the debug serial is described in DT with an alias > other than zero. E.g., on [1] the debug serial alias on RZ/G3S was changed > from 0 to 3. With the new alias (3) there were issues that I've tried to > fix with this series. I gave this a try on Koelsch, which has two easily-accessible usb-serial ports, for all three cases above. Originally, I had CONFIG_VT_CONSOLE=y (tty0 takes over from earlycon rather early), but I had to disable that to exercise all code paths (ttySC0 takes over much later). A. CONFIG_VT_CONSOLE=y: OK B. CONFIG_VT_CONSOLE=y earlycon: OK early_console_setup: mapbase 0x00000000e6e60000 earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') printk: legacy bootconsole [scif0] enabled printk: legacy console [tty0] enabled printk: legacy bootconsole [scif0] disabled early_console_exit: Clearing sci_ports[0] C. CONFIG_VT_CONSOLE=n earlycon: OK early_console_setup: mapbase 0x00000000e6e60000 earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') printk: legacy bootconsole [scif0] enabled printk: legacy console [ttySC0] enabled printk: legacy bootconsole [scif0] disabled early_console_exit: Not clearing sci_ports[0] D. CONFIG_VT_CONSOLE=y earlycon keep_bootcon: OK early_console_setup: mapbase 0x00000000e6e60000 earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') printk: legacy bootconsole [scif0] enabled printk: legacy console [tty0] enabled So all good, but note that these cases worked fine without your series, too. The real troublesome cases involve using earlycon on a different serial port than serial0. As I don't have any Renesas boards where chosen/stdout-path does not use serial0, I tried exchanging the serial0 and serial1 DT aliases, and updating chosen/stdout-path accordingly. E. CONFIG_VT_CONSOLE=y: OK F. CONFIG_VT_CONSOLE=y earlycon: OK early_console_setup: mapbase 0x00000000e6e60000 earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') printk: legacy bootconsole [scif0] enabled printk: legacy console [tty0] enabled printk: legacy bootconsole [scif0] disabled early_console_exit: Clearing sci_ports[0] G. CONFIG_VT_CONSOLE=y earlycon keep_bootcon: SCIF1 missing early_console_setup: mapbase 0x00000000e6e60000 earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') printk: legacy bootconsole [scif0] enabled printk: legacy console [tty0] enabled sh-sci e6e68000.serial: error -EBUSY: sci_port[0] is used by earlycon! H. CONFIG_VT_CONSOLE=n earlycon: SCIF1 missing early_console_setup: mapbase 0x00000000e6e60000 earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') printk: legacy bootconsole [scif0] enabled printk: legacy console [ttySC1] enabled printk: legacy bootconsole [scif0] disabled early_console_exit: Not clearing sci_ports[0] sh-sci e6e68000.serial: error -EBUSY: sci_port[0] is used by earlycon! Case G gives a missing SCIF1, because sci_port[0] is still used for earlycon, as expected. Case H also gives a missing SCIF1, but should succeed IMHO, as earlycon is no longer active. I think early_console_exit() should clear the earlycon flag regardless. Note that before your series, cases E-F worked too, but cases G-H gave an initialized but broken SCIF1 instead. Now, can we improve? - Can we use a proper id instead of zero for earlycon, e.g. sci_probe_earlyprintk() does fill in early_serial_console.index? - Alternatively, can we use a separate sci_port structure instead of abusing sci_ports[0]? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org 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 19.12.2024 17:11, Geert Uytterhoeven wrote: > Hi Claudiu, > > On Thu, Dec 5, 2024 at 9:39 AM Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote: >> On 04.12.2024 23:38, Wolfram Sang wrote: >>>> in the following scenarios: >>>> >>>> 1/ "earlycon keep_bootcon" were present in bootargs >>>> 2/ only "earlycon" was present in bootargs >>>> 3/ none of the "earlycon" or "earlycon keep_bootcon" were present in >>>> bootargs >>> ... >>>> Please give it a try on your devices as well. >>> >>> Will happily do so. Is there something to look for? Except for "it >>> works"? >> >> As this code touches the earlycon functionality, of interest are the 3 >> cases highlighted above: >> >> 1/ "earlycon keep_bootcon" are both present in bootargs >> 2/ only "earlycon" is present in bootargs >> 3/ none of the "earlycon" or "earlycon keep_bootcon" are present in >> bootargs >> >> One other thing, that I was currently able to test only on RZ/G3S, is to >> see how it behaves when the debug serial is described in DT with an alias >> other than zero. E.g., on [1] the debug serial alias on RZ/G3S was changed >> from 0 to 3. With the new alias (3) there were issues that I've tried to >> fix with this series. > > I gave this a try on Koelsch, which has two easily-accessible usb-serial > ports, for all three cases above. Originally, I had CONFIG_VT_CONSOLE=y > (tty0 takes over from earlycon rather early), but I had to disable > that to exercise all code paths (ttySC0 takes over much later). > > A. CONFIG_VT_CONSOLE=y: OK > B. CONFIG_VT_CONSOLE=y earlycon: OK > early_console_setup: mapbase 0x00000000e6e60000 > earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') > printk: legacy bootconsole [scif0] enabled > printk: legacy console [tty0] enabled > printk: legacy bootconsole [scif0] disabled > early_console_exit: Clearing sci_ports[0] > C. CONFIG_VT_CONSOLE=n earlycon: OK > early_console_setup: mapbase 0x00000000e6e60000 > earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') > printk: legacy bootconsole [scif0] enabled > printk: legacy console [ttySC0] enabled > printk: legacy bootconsole [scif0] disabled > early_console_exit: Not clearing sci_ports[0] > D. CONFIG_VT_CONSOLE=y earlycon keep_bootcon: OK > early_console_setup: mapbase 0x00000000e6e60000 > earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') > printk: legacy bootconsole [scif0] enabled > printk: legacy console [tty0] enabled > > So all good, but note that these cases worked fine without your > series, too. > > The real troublesome cases involve using earlycon on a different > serial port than serial0. As I don't have any Renesas boards where > chosen/stdout-path does not use serial0, I tried exchanging the serial0 > and serial1 DT aliases, and updating chosen/stdout-path accordingly. > > E. CONFIG_VT_CONSOLE=y: OK > F. CONFIG_VT_CONSOLE=y earlycon: OK > early_console_setup: mapbase 0x00000000e6e60000 > earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') > printk: legacy bootconsole [scif0] enabled > printk: legacy console [tty0] enabled > printk: legacy bootconsole [scif0] disabled > early_console_exit: Clearing sci_ports[0] > G. CONFIG_VT_CONSOLE=y earlycon keep_bootcon: SCIF1 missing > early_console_setup: mapbase 0x00000000e6e60000 > earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') > printk: legacy bootconsole [scif0] enabled > printk: legacy console [tty0] enabled > sh-sci e6e68000.serial: error -EBUSY: sci_port[0] is used by earlycon! > H. CONFIG_VT_CONSOLE=n earlycon: SCIF1 missing > early_console_setup: mapbase 0x00000000e6e60000 > earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') > printk: legacy bootconsole [scif0] enabled > printk: legacy console [ttySC1] enabled > printk: legacy bootconsole [scif0] disabled > early_console_exit: Not clearing sci_ports[0] > sh-sci e6e68000.serial: error -EBUSY: sci_port[0] is used by earlycon! > > Case G gives a missing SCIF1, because sci_port[0] is still > used for earlycon, as expected. > Case H also gives a missing SCIF1, but should succeed IMHO, as earlycon > is no longer active. I think early_console_exit() should clear the > earlycon flag regardless. I'll double check it. > > Note that before your series, cases E-F worked too, but cases G-H gave > an initialized but broken SCIF1 instead. > > Now, can we improve? > - Can we use a proper id instead of zero for earlycon, e.g. > sci_probe_earlyprintk() does fill in early_serial_console.index? I looked into that but, as of my investigation, index zero is the one used in the earlyprintk initialization process. sci_probe_earlyprintk() is called from sci_probe(). I'll double checked it though, anyway. > - Alternatively, can we use a separate sci_port structure instead > of abusing sci_ports[0]? I explored this too, but didn't manage to make it work. Thank you for running all these tests, Claudiu > > Thanks! > > Gr{oetje,eeting}s, > > Geert > > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > 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 21.12.2024 11:54, Claudiu Beznea wrote: > Hi, Geert, > > On 19.12.2024 17:11, Geert Uytterhoeven wrote: >> Hi Claudiu, >> >> On Thu, Dec 5, 2024 at 9:39 AM Claudiu Beznea <claudiu.beznea@tuxon.dev> wrote: >>> On 04.12.2024 23:38, Wolfram Sang wrote: >>>>> in the following scenarios: >>>>> >>>>> 1/ "earlycon keep_bootcon" were present in bootargs >>>>> 2/ only "earlycon" was present in bootargs >>>>> 3/ none of the "earlycon" or "earlycon keep_bootcon" were present in >>>>> bootargs >>>> ... >>>>> Please give it a try on your devices as well. >>>> >>>> Will happily do so. Is there something to look for? Except for "it >>>> works"? >>> >>> As this code touches the earlycon functionality, of interest are the 3 >>> cases highlighted above: >>> >>> 1/ "earlycon keep_bootcon" are both present in bootargs >>> 2/ only "earlycon" is present in bootargs >>> 3/ none of the "earlycon" or "earlycon keep_bootcon" are present in >>> bootargs >>> >>> One other thing, that I was currently able to test only on RZ/G3S, is to >>> see how it behaves when the debug serial is described in DT with an alias >>> other than zero. E.g., on [1] the debug serial alias on RZ/G3S was changed >>> from 0 to 3. With the new alias (3) there were issues that I've tried to >>> fix with this series. >> >> I gave this a try on Koelsch, which has two easily-accessible usb-serial >> ports, for all three cases above. Originally, I had CONFIG_VT_CONSOLE=y >> (tty0 takes over from earlycon rather early), but I had to disable >> that to exercise all code paths (ttySC0 takes over much later). >> >> A. CONFIG_VT_CONSOLE=y: OK >> B. CONFIG_VT_CONSOLE=y earlycon: OK >> early_console_setup: mapbase 0x00000000e6e60000 >> earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') >> printk: legacy bootconsole [scif0] enabled >> printk: legacy console [tty0] enabled >> printk: legacy bootconsole [scif0] disabled >> early_console_exit: Clearing sci_ports[0] >> C. CONFIG_VT_CONSOLE=n earlycon: OK >> early_console_setup: mapbase 0x00000000e6e60000 >> earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') >> printk: legacy bootconsole [scif0] enabled >> printk: legacy console [ttySC0] enabled >> printk: legacy bootconsole [scif0] disabled >> early_console_exit: Not clearing sci_ports[0] >> D. CONFIG_VT_CONSOLE=y earlycon keep_bootcon: OK >> early_console_setup: mapbase 0x00000000e6e60000 >> earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') >> printk: legacy bootconsole [scif0] enabled >> printk: legacy console [tty0] enabled >> >> So all good, but note that these cases worked fine without your >> series, too. >> >> The real troublesome cases involve using earlycon on a different >> serial port than serial0. As I don't have any Renesas boards where >> chosen/stdout-path does not use serial0, I tried exchanging the serial0 >> and serial1 DT aliases, and updating chosen/stdout-path accordingly. >> >> E. CONFIG_VT_CONSOLE=y: OK >> F. CONFIG_VT_CONSOLE=y earlycon: OK >> early_console_setup: mapbase 0x00000000e6e60000 >> earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') >> printk: legacy bootconsole [scif0] enabled >> printk: legacy console [tty0] enabled >> printk: legacy bootconsole [scif0] disabled >> early_console_exit: Clearing sci_ports[0] >> G. CONFIG_VT_CONSOLE=y earlycon keep_bootcon: SCIF1 missing >> early_console_setup: mapbase 0x00000000e6e60000 >> earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') >> printk: legacy bootconsole [scif0] enabled >> printk: legacy console [tty0] enabled >> sh-sci e6e68000.serial: error -EBUSY: sci_port[0] is used by earlycon! >> H. CONFIG_VT_CONSOLE=n earlycon: SCIF1 missing >> early_console_setup: mapbase 0x00000000e6e60000 >> earlycon: scif0 at MMIO 0x00000000e6e60000 (options '115200n8') >> printk: legacy bootconsole [scif0] enabled >> printk: legacy console [ttySC1] enabled >> printk: legacy bootconsole [scif0] disabled >> early_console_exit: Not clearing sci_ports[0] >> sh-sci e6e68000.serial: error -EBUSY: sci_port[0] is used by earlycon! >> >> Case G gives a missing SCIF1, because sci_port[0] is still >> used for earlycon, as expected. >> Case H also gives a missing SCIF1, but should succeed IMHO, as earlycon >> is no longer active. I think early_console_exit() should clear the >> earlycon flag regardless. > > I'll double check it. Indeed, clearing the earlycon flag leads to case H succeeding as well. > >> >> Note that before your series, cases E-F worked too, but cases G-H gave >> an initialized but broken SCIF1 instead. >> >> Now, can we improve? >> - Can we use a proper id instead of zero for earlycon, e.g. >> sci_probe_earlyprintk() does fill in early_serial_console.index? > > I looked into that but, as of my investigation, index zero is the one used > in the earlyprintk initialization process. sci_probe_earlyprintk() is > called from sci_probe(). I'll double checked it though, anyway. As of my investigation, the current code initializes the index based on the name registered though the OF_EARLYCON_DECLARE(). That name is used in earlycon_init() to initialize the early serial index: of_setup_earlycon(match, ...) earlycon_init(&earlycon_console_dev, match->name) // ... earlycon->index = simple_strtoul(s, NULL, 10); // ... On sh-sci driver that name is generic and have nothing to do with board setup. Also, in the sh-sci early_console_setup() function we cannot use of_alias_get_id() as we don't have a struct device node associated to the struct earlycon_device object, argument of early_console_setup(), when the earlycon is configured. And I think, at the moment the early_console_setup() is called the alias list is not yet populated. Parsing the linux,stdout-path/stdout-path again in early_console_setup() will duplicate the code from early_init_dt_scan_chosen_stdout(). I have a PoC code that parses the alias from the stdout-chosen, in early_init_dt_scan_chosen_stdout(), but introducing it may need testing on all the currently enabled devices, to avoid breakage. This code takes into account the device alias provided though the device tree (rudimentary tested for the moment). Diff bellow: diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c index 0121100372b4..ce65b9cc620d 100644 --- a/drivers/of/fdt.c +++ b/drivers/of/fdt.c @@ -876,10 +876,11 @@ void __init early_init_dt_check_for_usable_mem_range(void) int __init early_init_dt_scan_chosen_stdout(void) { int offset; - const char *p, *q, *options = NULL; - int l; + const char *p, *q, *tmp, *options = NULL; + int l, alias_len; const struct earlycon_id *match; const void *fdt = initial_boot_params; + int alias; int ret; offset = fdt_path_offset(fdt, "/chosen"); @@ -898,6 +899,7 @@ int __init early_init_dt_scan_chosen_stdout(void) if (*q != '\0') options = q + 1; l = q - p; + alias_len = q - p; /* Get the node specified by stdout-path */ offset = fdt_path_offset_namelen(fdt, p, l); @@ -906,6 +908,16 @@ int __init early_init_dt_scan_chosen_stdout(void) return 0; } + /* Get the alias ID. */ + /* scan backwards from end of string for first non-numeral */ + for (tmp = p + alias_len; + tmp > p && tmp[-1] >= '0' && tmp[-1] <= '9'; + tmp--) + ; + + if (*tmp) + alias = *tmp - '0'; + for (match = __earlycon_table; match < __earlycon_table_end; match++) { if (!match->compatible[0]) continue; @@ -913,7 +925,7 @@ int __init early_init_dt_scan_chosen_stdout(void) if (fdt_node_check_compatible(fdt, offset, match->compatible)) continue; - ret = of_setup_earlycon(match, offset, options); + ret = of_setup_earlycon(match, offset, options, alias); if (!ret || ret == -EALREADY) return 0; } diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c index ab9af37f6cda..52b4a5c56269 100644 --- a/drivers/tty/serial/earlycon.c +++ b/drivers/tty/serial/earlycon.c @@ -53,7 +53,7 @@ static void __iomem * __init earlycon_map(resource_size_t paddr, size_t size) } static void __init earlycon_init(struct earlycon_device *device, - const char *name) + const char *name, int alias) { struct console *earlycon = device->con; const char *s; @@ -66,6 +66,9 @@ static void __init earlycon_init(struct earlycon_device *device, ; if (*s) earlycon->index = simple_strtoul(s, NULL, 10); + else if (alias >= 0) + earlycon->index = alias; + len = s - name; strscpy(earlycon->name, name, min(len + 1, sizeof(earlycon->name))); earlycon->data = &early_console_dev; @@ -150,7 +153,7 @@ static int __init register_earlycon(char *buf, const struct earlycon_id *match) if (port->mapbase) port->membase = earlycon_map(port->mapbase, 64); - earlycon_init(&early_console_dev, match->name); + earlycon_init(&early_console_dev, match->name, -1); err = match->setup(&early_console_dev, buf); earlycon_print_info(&early_console_dev); if (err < 0) @@ -275,7 +278,8 @@ early_param("console", param_setup_earlycon_console_alias); int __init of_setup_earlycon(const struct earlycon_id *match, unsigned long node, - const char *options) + const char *options, + int alias) { int err; struct uart_port *port = &early_console_dev.port; @@ -337,7 +341,7 @@ int __init of_setup_earlycon(const struct earlycon_id *match, strscpy(early_console_dev.options, options, sizeof(early_console_dev.options)); } - earlycon_init(&early_console_dev, match->name); + earlycon_init(&early_console_dev, match->name, alias); err = match->setup(&early_console_dev, options); earlycon_print_info(&early_console_dev); if (err < 0) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index 17e0cd7642fc..10dff3053218 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -3655,17 +3655,19 @@ static int early_console_exit(struct console *co) static int __init early_console_setup(struct earlycon_device *device, int type) { + int index = device->con->index; + if (!device->port.membase) return -ENODEV; device->port.type = type; - sci_ports[0].port = device->port; + sci_ports[index].port = device->port; port_cfg.type = type; - sci_ports[0].cfg = &port_cfg; - sci_ports[0].params = sci_probe_regmap(&port_cfg); - sci_ports[0].earlycon = true; - port_cfg.scscr = sci_serial_in(&sci_ports[0].port, SCSCR); - sci_serial_out(&sci_ports[0].port, SCSCR, + sci_ports[index].cfg = &port_cfg; + sci_ports[index].params = sci_probe_regmap(&port_cfg); + sci_uart_earlycon = true; + port_cfg.scscr = sci_serial_in(&sci_ports[index].port, SCSCR); + sci_serial_out(&sci_ports[index].port, SCSCR, SCSCR_RE | SCSCR_TE | port_cfg.scscr); device->con->write = serial_console_write; diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index 743b4afaad4c..06c46ade5482 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -1078,7 +1078,7 @@ extern const struct earlycon_id __earlycon_table_end[]; #define EARLYCON_DECLARE(_name, fn) OF_EARLYCON_DECLARE(_name, "", fn) int of_setup_earlycon(const struct earlycon_id *match, unsigned long node, - const char *options); + const char *options, int alias); #ifdef CONFIG_SERIAL_EARLYCON extern bool earlycon_acpi_spcr_enable __initdata; What do you think? Are you OK with still handling it in the driver though the index 0 (mostly as it has been proposed in the previous version) or prefer to go with the PoC code that may change behavior on current devices? Or do you have another idea? Thank you, Claudiu > > >> - Alternatively, can we use a separate sci_port structure instead >> of abusing sci_ports[0]? > > I explored this too, but didn't manage to make it work. > > Thank you for running all these tests, > Claudiu > >> >> Thanks! >> >> Gr{oetje,eeting}s, >> >> Geert >> >> >> -- >> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org >> >> 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 >
From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Hi, This series adds fixes for earlycon and keep_bootcon on sh-sci driver. Patch 1/6 was initially part of [1], then posted as standalone fix at [2]. Patch 5/6 was integrated but then reverted as issues were identified after that with it as standalone patch. I added it in this series to keep all the sh-sci fixes in the same place. All these fixes are prerequisites for the Renesas RZ/G3S SCI support. Series was tested on the boards with the following device trees binaries: - r8a7742-iwg21d-q7.dtb - r8a7743-iwg20d-q7.dtb - r8a7745-iwg22d-sodimm.dtb - r8a77470-iwg23s-sbc.dtb - r8a774a1-hihope-rzg2m-ex.dtb - r8a774b1-hihope-rzg2n-ex.dtb - r8a774e1-hihope-rzg2h-ex.dtb - r9a07g043u11-smarc.dtb - r9a07g044c2-smarc.dtb - r9a07g044l2-smarc.dtb - r9a07g054l2-smarc.dtb - r9a08g045s33-smarc.dtb - r9a08g045s33-smarc-pmod.dtb (not integrated in the latest kernel tree, but the device tree was posted at [3]) in the following scenarios: 1/ "earlycon keep_bootcon" were present in bootargs 2/ only "earlycon" was present in bootargs 3/ none of the "earlycon" or "earlycon keep_bootcon" were present in bootargs 1, 2, 3 were tested also with renesas_defconfig on r9a08g045s33-smarc-pmod.dtb. Please give it a try on your devices as well. Thank you, Claudiu Beznea [1] https://lore.kernel.org/all/20241115134401.3893008-1-claudiu.beznea.uj@bp.renesas.com/ [2] https://lore.kernel.org/all/20241125115856.513642-1-claudiu.beznea.uj@bp.renesas.com/ [3] https://lore.kernel.org/all/20241115134401.3893008-9-claudiu.beznea.uj@bp.renesas.com/ Claudiu Beznea (6): serial: sh-sci: Check if TX data was written to device in .tx_empty() serial: sh-sci: Drop __initdata macro for port_cfg serial: sh-sci: Move runtime PM enable to sci_probe_single() serial: sh-sci: Do not probe the serial port if its slot in sci_ports[] is in use serial: sh-sci: Clean sci_ports[0] after at earlycon exit serial: sh-sci: Increment the runtime usage counter for the earlycon device drivers/tty/serial/sh-sci.c | 121 ++++++++++++++++++++++++++++++------ 1 file changed, 102 insertions(+), 19 deletions(-)