| Message ID | edff5ba0d286a41b94a6b4bb332b63228f7faebe.1661181584.git-series.marmarek@invisiblethingslab.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add Xue - console over USB 3 Debug Capability | expand |
On 22.08.2022 17:27, Marek Marczykowski-Górecki wrote: > This allows configuring EHCI and XHCI consoles separately, > simultaneously. > > Suggested-by: Jan Beulich <jbeulich@suse.com> But was I maybe confused, and much less of a change would suffice? After all ... > --- a/xen/drivers/char/xhci-dbc.c > +++ b/xen/drivers/char/xhci-dbc.c > @@ -1058,9 +1058,9 @@ static struct xhci_dbc_ctx ctx __aligned(16); > static uint8_t out_wrk_buf[DBC_WORK_RING_CAP]; > static struct xhci_string_descriptor str_buf[DBC_STRINGS_COUNT]; > > -static char __initdata opt_dbgp[30]; > +static char __initdata opt_dbc[30]; > > -string_param("dbgp", opt_dbgp); > +string_param("dbc", opt_dbc); > > void __init xhci_dbc_uart_init(void) > { > @@ -1068,25 +1068,25 @@ void __init xhci_dbc_uart_init(void) > struct dbc *dbc = &uart->dbc; > const char *e; > > - if ( strncmp(opt_dbgp, "xhci", 4) ) > + if ( strncmp(opt_dbc, "xhci", 4) ) > return; ... this already avoids mixing up who's going to parse what. So right now I think that ... > @@ -1102,7 +1102,7 @@ void __init xhci_dbc_uart_init(void) > dbc->dbc_str = str_buf; > > if ( dbc_open(dbc) ) > - serial_register_uart(SERHND_DBGP, &dbc_uart_driver, &dbc_uart); > + serial_register_uart(SERHND_DBC, &dbc_uart_driver, &dbc_uart); > } ... this and other SERHND_* related changes are enough, and there's no need for a separate "dbc=" option. > --- a/xen/include/xen/serial.h > +++ b/xen/include/xen/serial.h > @@ -95,6 +95,7 @@ struct uart_driver { > # define SERHND_COM1 (0<<0) > # define SERHND_COM2 (1<<0) > # define SERHND_DBGP (2<<0) > +# define SERHND_DBC (3<<0) Please also update the comment just out of context. Jan
On Thu, Aug 25, 2022 at 05:44:54PM +0200, Jan Beulich wrote: > On 22.08.2022 17:27, Marek Marczykowski-Górecki wrote: > > This allows configuring EHCI and XHCI consoles separately, > > simultaneously. > > > > Suggested-by: Jan Beulich <jbeulich@suse.com> > > But was I maybe confused, and much less of a change would suffice? After > all ... > > > --- a/xen/drivers/char/xhci-dbc.c > > +++ b/xen/drivers/char/xhci-dbc.c > > @@ -1058,9 +1058,9 @@ static struct xhci_dbc_ctx ctx __aligned(16); > > static uint8_t out_wrk_buf[DBC_WORK_RING_CAP]; > > static struct xhci_string_descriptor str_buf[DBC_STRINGS_COUNT]; > > > > -static char __initdata opt_dbgp[30]; > > +static char __initdata opt_dbc[30]; > > > > -string_param("dbgp", opt_dbgp); > > +string_param("dbc", opt_dbc); > > > > void __init xhci_dbc_uart_init(void) > > { > > @@ -1068,25 +1068,25 @@ void __init xhci_dbc_uart_init(void) > > struct dbc *dbc = &uart->dbc; > > const char *e; > > > > - if ( strncmp(opt_dbgp, "xhci", 4) ) > > + if ( strncmp(opt_dbc, "xhci", 4) ) > > return; > > ... this already avoids mixing up who's going to parse what. So right > now I think that ... > > > @@ -1102,7 +1102,7 @@ void __init xhci_dbc_uart_init(void) > > dbc->dbc_str = str_buf; > > > > if ( dbc_open(dbc) ) > > - serial_register_uart(SERHND_DBGP, &dbc_uart_driver, &dbc_uart); > > + serial_register_uart(SERHND_DBC, &dbc_uart_driver, &dbc_uart); > > } > > ... this and other SERHND_* related changes are enough, and there's no > need for a separate "dbc=" option. But then you wouldn't be able to configure "dbgp=ehci dbgp=xhci" as one would override the other, no? > > > --- a/xen/include/xen/serial.h > > +++ b/xen/include/xen/serial.h > > @@ -95,6 +95,7 @@ struct uart_driver { > > # define SERHND_COM1 (0<<0) > > # define SERHND_COM2 (1<<0) > > # define SERHND_DBGP (2<<0) > > +# define SERHND_DBC (3<<0) > > Please also update the comment just out of context. > > Jan
On 26.08.2022 13:46, Marek Marczykowski-Górecki wrote: > On Thu, Aug 25, 2022 at 05:44:54PM +0200, Jan Beulich wrote: >> On 22.08.2022 17:27, Marek Marczykowski-Górecki wrote: >>> This allows configuring EHCI and XHCI consoles separately, >>> simultaneously. >>> >>> Suggested-by: Jan Beulich <jbeulich@suse.com> >> >> But was I maybe confused, and much less of a change would suffice? After >> all ... >> >>> --- a/xen/drivers/char/xhci-dbc.c >>> +++ b/xen/drivers/char/xhci-dbc.c >>> @@ -1058,9 +1058,9 @@ static struct xhci_dbc_ctx ctx __aligned(16); >>> static uint8_t out_wrk_buf[DBC_WORK_RING_CAP]; >>> static struct xhci_string_descriptor str_buf[DBC_STRINGS_COUNT]; >>> >>> -static char __initdata opt_dbgp[30]; >>> +static char __initdata opt_dbc[30]; >>> >>> -string_param("dbgp", opt_dbgp); >>> +string_param("dbc", opt_dbc); >>> >>> void __init xhci_dbc_uart_init(void) >>> { >>> @@ -1068,25 +1068,25 @@ void __init xhci_dbc_uart_init(void) >>> struct dbc *dbc = &uart->dbc; >>> const char *e; >>> >>> - if ( strncmp(opt_dbgp, "xhci", 4) ) >>> + if ( strncmp(opt_dbc, "xhci", 4) ) >>> return; >> >> ... this already avoids mixing up who's going to parse what. So right >> now I think that ... >> >>> @@ -1102,7 +1102,7 @@ void __init xhci_dbc_uart_init(void) >>> dbc->dbc_str = str_buf; >>> >>> if ( dbc_open(dbc) ) >>> - serial_register_uart(SERHND_DBGP, &dbc_uart_driver, &dbc_uart); >>> + serial_register_uart(SERHND_DBC, &dbc_uart_driver, &dbc_uart); >>> } >> >> ... this and other SERHND_* related changes are enough, and there's no >> need for a separate "dbc=" option. > > But then you wouldn't be able to configure "dbgp=ehci dbgp=xhci" as > one would override the other, no? Not as long as both use string_param(), true. They'd need to both become custom_param(), doing at least some basic parsing right away. But using two such options at the same time isn't of interest anyway without your multiple-serial-consoles change, so possibly not of immediate need (unless someone comes forward expressing interest and actually approving that change of yours). Jan
On 26/08/2022 15:20, Jan Beulich wrote: > On 26.08.2022 13:46, Marek Marczykowski-Górecki wrote: >> On Thu, Aug 25, 2022 at 05:44:54PM +0200, Jan Beulich wrote: >>> On 22.08.2022 17:27, Marek Marczykowski-Górecki wrote: >>>> This allows configuring EHCI and XHCI consoles separately, >>>> simultaneously. >>>> >>>> Suggested-by: Jan Beulich <jbeulich@suse.com> >>> But was I maybe confused, and much less of a change would suffice? After >>> all ... >>> >>>> --- a/xen/drivers/char/xhci-dbc.c >>>> +++ b/xen/drivers/char/xhci-dbc.c >>>> @@ -1058,9 +1058,9 @@ static struct xhci_dbc_ctx ctx __aligned(16); >>>> static uint8_t out_wrk_buf[DBC_WORK_RING_CAP]; >>>> static struct xhci_string_descriptor str_buf[DBC_STRINGS_COUNT]; >>>> >>>> -static char __initdata opt_dbgp[30]; >>>> +static char __initdata opt_dbc[30]; >>>> >>>> -string_param("dbgp", opt_dbgp); >>>> +string_param("dbc", opt_dbc); >>>> >>>> void __init xhci_dbc_uart_init(void) >>>> { >>>> @@ -1068,25 +1068,25 @@ void __init xhci_dbc_uart_init(void) >>>> struct dbc *dbc = &uart->dbc; >>>> const char *e; >>>> >>>> - if ( strncmp(opt_dbgp, "xhci", 4) ) >>>> + if ( strncmp(opt_dbc, "xhci", 4) ) >>>> return; >>> ... this already avoids mixing up who's going to parse what. So right >>> now I think that ... >>> >>>> @@ -1102,7 +1102,7 @@ void __init xhci_dbc_uart_init(void) >>>> dbc->dbc_str = str_buf; >>>> >>>> if ( dbc_open(dbc) ) >>>> - serial_register_uart(SERHND_DBGP, &dbc_uart_driver, &dbc_uart); >>>> + serial_register_uart(SERHND_DBC, &dbc_uart_driver, &dbc_uart); >>>> } >>> ... this and other SERHND_* related changes are enough, and there's no >>> need for a separate "dbc=" option. >> But then you wouldn't be able to configure "dbgp=ehci dbgp=xhci" as >> one would override the other, no? > Not as long as both use string_param(), true. They'd need to both become > custom_param(), doing at least some basic parsing right away. I've looked through our string params, and none of them look like they should be string params. I have half a mind to transform them all, one at a time, and remove string_param() to prevent problems like this in the future. ~Andrew
On Fri, Aug 26, 2022 at 04:20:52PM +0200, Jan Beulich wrote: > On 26.08.2022 13:46, Marek Marczykowski-Górecki wrote: > > On Thu, Aug 25, 2022 at 05:44:54PM +0200, Jan Beulich wrote: > >> On 22.08.2022 17:27, Marek Marczykowski-Górecki wrote: > >>> This allows configuring EHCI and XHCI consoles separately, > >>> simultaneously. > >>> > >>> Suggested-by: Jan Beulich <jbeulich@suse.com> > >> > >> But was I maybe confused, and much less of a change would suffice? After > >> all ... > >> > >>> --- a/xen/drivers/char/xhci-dbc.c > >>> +++ b/xen/drivers/char/xhci-dbc.c > >>> @@ -1058,9 +1058,9 @@ static struct xhci_dbc_ctx ctx __aligned(16); > >>> static uint8_t out_wrk_buf[DBC_WORK_RING_CAP]; > >>> static struct xhci_string_descriptor str_buf[DBC_STRINGS_COUNT]; > >>> > >>> -static char __initdata opt_dbgp[30]; > >>> +static char __initdata opt_dbc[30]; > >>> > >>> -string_param("dbgp", opt_dbgp); > >>> +string_param("dbc", opt_dbc); > >>> > >>> void __init xhci_dbc_uart_init(void) > >>> { > >>> @@ -1068,25 +1068,25 @@ void __init xhci_dbc_uart_init(void) > >>> struct dbc *dbc = &uart->dbc; > >>> const char *e; > >>> > >>> - if ( strncmp(opt_dbgp, "xhci", 4) ) > >>> + if ( strncmp(opt_dbc, "xhci", 4) ) > >>> return; > >> > >> ... this already avoids mixing up who's going to parse what. So right > >> now I think that ... > >> > >>> @@ -1102,7 +1102,7 @@ void __init xhci_dbc_uart_init(void) > >>> dbc->dbc_str = str_buf; > >>> > >>> if ( dbc_open(dbc) ) > >>> - serial_register_uart(SERHND_DBGP, &dbc_uart_driver, &dbc_uart); > >>> + serial_register_uart(SERHND_DBC, &dbc_uart_driver, &dbc_uart); > >>> } > >> > >> ... this and other SERHND_* related changes are enough, and there's no > >> need for a separate "dbc=" option. > > > > But then you wouldn't be able to configure "dbgp=ehci dbgp=xhci" as > > one would override the other, no? > > Not as long as both use string_param(), true. They'd need to both become > custom_param(), doing at least some basic parsing right away. > > But using two such options at the same time isn't of interest anyway > without your multiple-serial-consoles change, so possibly not of > immediate need (unless someone comes forward expressing interest and > actually approving that change of yours). Then why change at all? Since you can configure only one (dbgp=ehci _or_ dbgp=xhci), then there is not ambiguity what "console=dbgp" means. Separating SERHND_DBC from SERHND_DBGP would IMO make sense only if you can actually use them both (even if not both for console, but for example one for debugger).
On Mon, Aug 29, 2022 at 01:49:30PM +0200, Marek Marczykowski-Górecki wrote: > On Fri, Aug 26, 2022 at 04:20:52PM +0200, Jan Beulich wrote: > > On 26.08.2022 13:46, Marek Marczykowski-Górecki wrote: > > > On Thu, Aug 25, 2022 at 05:44:54PM +0200, Jan Beulich wrote: > > >> On 22.08.2022 17:27, Marek Marczykowski-Górecki wrote: > > >>> This allows configuring EHCI and XHCI consoles separately, > > >>> simultaneously. > > >>> > > >>> Suggested-by: Jan Beulich <jbeulich@suse.com> > > >> > > >> But was I maybe confused, and much less of a change would suffice? After > > >> all ... > > >> > > >>> --- a/xen/drivers/char/xhci-dbc.c > > >>> +++ b/xen/drivers/char/xhci-dbc.c > > >>> @@ -1058,9 +1058,9 @@ static struct xhci_dbc_ctx ctx __aligned(16); > > >>> static uint8_t out_wrk_buf[DBC_WORK_RING_CAP]; > > >>> static struct xhci_string_descriptor str_buf[DBC_STRINGS_COUNT]; > > >>> > > >>> -static char __initdata opt_dbgp[30]; > > >>> +static char __initdata opt_dbc[30]; > > >>> > > >>> -string_param("dbgp", opt_dbgp); > > >>> +string_param("dbc", opt_dbc); > > >>> > > >>> void __init xhci_dbc_uart_init(void) > > >>> { > > >>> @@ -1068,25 +1068,25 @@ void __init xhci_dbc_uart_init(void) > > >>> struct dbc *dbc = &uart->dbc; > > >>> const char *e; > > >>> > > >>> - if ( strncmp(opt_dbgp, "xhci", 4) ) > > >>> + if ( strncmp(opt_dbc, "xhci", 4) ) > > >>> return; > > >> > > >> ... this already avoids mixing up who's going to parse what. So right > > >> now I think that ... > > >> > > >>> @@ -1102,7 +1102,7 @@ void __init xhci_dbc_uart_init(void) > > >>> dbc->dbc_str = str_buf; > > >>> > > >>> if ( dbc_open(dbc) ) > > >>> - serial_register_uart(SERHND_DBGP, &dbc_uart_driver, &dbc_uart); > > >>> + serial_register_uart(SERHND_DBC, &dbc_uart_driver, &dbc_uart); > > >>> } > > >> > > >> ... this and other SERHND_* related changes are enough, and there's no > > >> need for a separate "dbc=" option. > > > > > > But then you wouldn't be able to configure "dbgp=ehci dbgp=xhci" as > > > one would override the other, no? > > > > Not as long as both use string_param(), true. They'd need to both become > > custom_param(), doing at least some basic parsing right away. > > > > But using two such options at the same time isn't of interest anyway > > without your multiple-serial-consoles change, so possibly not of > > immediate need (unless someone comes forward expressing interest and > > actually approving that change of yours). > > Then why change at all? Since you can configure only one (dbgp=ehci _or_ > dbgp=xhci), then there is not ambiguity what "console=dbgp" means. > Separating SERHND_DBC from SERHND_DBGP would IMO make sense only if you > can actually use them both (even if not both for console, but for > example one for debugger). Or do you mean to use custom_param() to actually make "dbgp=xhci dbgp=ehci" working? But then IMO having "console=dbgp console=dbc" would be confusing, as "dbc" has no obvious relation to neither side of "dbgp=xhci". Maybe use "console=xhci" then?
On 29.08.2022 13:57, Marek Marczykowski-Górecki wrote: > On Mon, Aug 29, 2022 at 01:49:30PM +0200, Marek Marczykowski-Górecki wrote: >> On Fri, Aug 26, 2022 at 04:20:52PM +0200, Jan Beulich wrote: >>> On 26.08.2022 13:46, Marek Marczykowski-Górecki wrote: >>>> On Thu, Aug 25, 2022 at 05:44:54PM +0200, Jan Beulich wrote: >>>>> On 22.08.2022 17:27, Marek Marczykowski-Górecki wrote: >>>>>> This allows configuring EHCI and XHCI consoles separately, >>>>>> simultaneously. >>>>>> >>>>>> Suggested-by: Jan Beulich <jbeulich@suse.com> >>>>> >>>>> But was I maybe confused, and much less of a change would suffice? After >>>>> all ... >>>>> >>>>>> --- a/xen/drivers/char/xhci-dbc.c >>>>>> +++ b/xen/drivers/char/xhci-dbc.c >>>>>> @@ -1058,9 +1058,9 @@ static struct xhci_dbc_ctx ctx __aligned(16); >>>>>> static uint8_t out_wrk_buf[DBC_WORK_RING_CAP]; >>>>>> static struct xhci_string_descriptor str_buf[DBC_STRINGS_COUNT]; >>>>>> >>>>>> -static char __initdata opt_dbgp[30]; >>>>>> +static char __initdata opt_dbc[30]; >>>>>> >>>>>> -string_param("dbgp", opt_dbgp); >>>>>> +string_param("dbc", opt_dbc); >>>>>> >>>>>> void __init xhci_dbc_uart_init(void) >>>>>> { >>>>>> @@ -1068,25 +1068,25 @@ void __init xhci_dbc_uart_init(void) >>>>>> struct dbc *dbc = &uart->dbc; >>>>>> const char *e; >>>>>> >>>>>> - if ( strncmp(opt_dbgp, "xhci", 4) ) >>>>>> + if ( strncmp(opt_dbc, "xhci", 4) ) >>>>>> return; >>>>> >>>>> ... this already avoids mixing up who's going to parse what. So right >>>>> now I think that ... >>>>> >>>>>> @@ -1102,7 +1102,7 @@ void __init xhci_dbc_uart_init(void) >>>>>> dbc->dbc_str = str_buf; >>>>>> >>>>>> if ( dbc_open(dbc) ) >>>>>> - serial_register_uart(SERHND_DBGP, &dbc_uart_driver, &dbc_uart); >>>>>> + serial_register_uart(SERHND_DBC, &dbc_uart_driver, &dbc_uart); >>>>>> } >>>>> >>>>> ... this and other SERHND_* related changes are enough, and there's no >>>>> need for a separate "dbc=" option. >>>> >>>> But then you wouldn't be able to configure "dbgp=ehci dbgp=xhci" as >>>> one would override the other, no? >>> >>> Not as long as both use string_param(), true. They'd need to both become >>> custom_param(), doing at least some basic parsing right away. >>> >>> But using two such options at the same time isn't of interest anyway >>> without your multiple-serial-consoles change, so possibly not of >>> immediate need (unless someone comes forward expressing interest and >>> actually approving that change of yours). >> >> Then why change at all? Since you can configure only one (dbgp=ehci _or_ >> dbgp=xhci), then there is not ambiguity what "console=dbgp" means. >> Separating SERHND_DBC from SERHND_DBGP would IMO make sense only if you >> can actually use them both (even if not both for console, but for >> example one for debugger). > > Or do you mean to use custom_param() to actually make "dbgp=xhci > dbgp=ehci" working? Yes. > But then IMO having "console=dbgp console=dbc" would > be confusing, as "dbc" has no obvious relation to neither side of > "dbgp=xhci". Well, there was never any idea of using multiple serial consoles, so the present "console=dbgp" doesn't provide room for telling apart the two. Just like there's no way to tell apart two EHCI controllers' debug ports both (intended to be) used at the same time. JanMaybe use "console=xhci" then? >
diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index 9a79385a3712..0d07f0c75990 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -409,7 +409,7 @@ The following are examples of correct specifications: Specify the size of the console ring buffer. ### console -> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | none ]` +> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | dbc | none ]` > Default: `console=com1,vga` @@ -428,7 +428,9 @@ cleared. This allows a single port to be shared by two subsystems `pv` indicates that Xen should use Xen's PV console. This option is only available when used together with `pv-in-pvh`. -`dbgp` indicates that Xen should use a USB debug port. +`dbgp` indicates that Xen should use a USB2 debug port. + +`dbc` indicates that Xen should use a USB3 debug port. `none` indicates that Xen should not use a console. This option only makes sense on its own. @@ -721,14 +723,18 @@ Available alternatives, with their meaning, are: ### dbgp > `= ehci[ <integer> | @pci<bus>:<slot>.<func> ]` + +Specify the USB controller to use, either by instance number (when going +over the PCI busses sequentially) or by PCI device (must be on segment 0). + +### dbc > `= xhci[ <integer> | @pci<bus>:<slot>.<func> ]` Specify the USB controller to use, either by instance number (when going over the PCI busses sequentially) or by PCI device (must be on segment 0). -Use `ehci` for EHCI debug port, use `xhci` for XHCI debug capability (output -only). XHCI driver will wait indefinitely for the debug host to connect - make -sure the cable is connected. +Output only console. XHCI driver will wait indefinitely for the debug host to +connect - make sure the cable is connected. ### debug_stack_lines > `= <integer>` @@ -1174,7 +1180,7 @@ virtualization, to allow the L1 hypervisor to use EPT even if the L0 hypervisor does not provide `VM_ENTRY_LOAD_GUEST_PAT`. ### gdb -> `= com1[H,L] | com2[H,L] | dbgp` +> `= com1[H,L] | com2[H,L] | dbgp | dbc` > Default: `` diff --git a/xen/drivers/char/serial.c b/xen/drivers/char/serial.c index 47899222cef8..7daaa61361bb 100644 --- a/xen/drivers/char/serial.c +++ b/xen/drivers/char/serial.c @@ -311,6 +311,12 @@ int __init serial_parse_handle(const char *conf) goto common; } + if ( !strncmp(conf, "dbc", 3) && (!conf[3] || conf[3] == ',') ) + { + handle = SERHND_DBC; + goto common; + } + if ( !strncmp(conf, "dtuart", 6) ) { handle = SERHND_DTUART; diff --git a/xen/drivers/char/xhci-dbc.c b/xen/drivers/char/xhci-dbc.c index ca7d4a62139e..eb35e3a2ee4f 100644 --- a/xen/drivers/char/xhci-dbc.c +++ b/xen/drivers/char/xhci-dbc.c @@ -1058,9 +1058,9 @@ static struct xhci_dbc_ctx ctx __aligned(16); static uint8_t out_wrk_buf[DBC_WORK_RING_CAP]; static struct xhci_string_descriptor str_buf[DBC_STRINGS_COUNT]; -static char __initdata opt_dbgp[30]; +static char __initdata opt_dbc[30]; -string_param("dbgp", opt_dbgp); +string_param("dbc", opt_dbc); void __init xhci_dbc_uart_init(void) { @@ -1068,25 +1068,25 @@ void __init xhci_dbc_uart_init(void) struct dbc *dbc = &uart->dbc; const char *e; - if ( strncmp(opt_dbgp, "xhci", 4) ) + if ( strncmp(opt_dbc, "xhci", 4) ) return; memset(dbc, 0, sizeof(*dbc)); - if ( isdigit(opt_dbgp[4]) ) + if ( isdigit(opt_dbc[4]) ) { - dbc->xhc_num = simple_strtoul(opt_dbgp + 4, &e, 10); + dbc->xhc_num = simple_strtoul(opt_dbc + 4, &e, 10); } - else if ( strncmp(opt_dbgp + 4, "@pci", 4) == 0 ) + else if ( strncmp(opt_dbc + 4, "@pci", 4) == 0 ) { unsigned int bus, slot, func; - e = parse_pci(opt_dbgp + 8, NULL, &bus, &slot, &func); + e = parse_pci(opt_dbc + 8, NULL, &bus, &slot, &func); if ( !e || *e ) { printk(XENLOG_ERR - "Invalid dbgp= PCI device spec: '%s'\n", - opt_dbgp + 8); + "Invalid dbc= PCI device spec: '%s'\n", + opt_dbc + 8); return; } @@ -1102,7 +1102,7 @@ void __init xhci_dbc_uart_init(void) dbc->dbc_str = str_buf; if ( dbc_open(dbc) ) - serial_register_uart(SERHND_DBGP, &dbc_uart_driver, &dbc_uart); + serial_register_uart(SERHND_DBC, &dbc_uart_driver, &dbc_uart); } #ifdef DBC_DEBUG diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h index 4cd4ae5e6f1c..186afbed9c92 100644 --- a/xen/include/xen/serial.h +++ b/xen/include/xen/serial.h @@ -95,6 +95,7 @@ struct uart_driver { # define SERHND_COM1 (0<<0) # define SERHND_COM2 (1<<0) # define SERHND_DBGP (2<<0) +# define SERHND_DBC (3<<0) # define SERHND_DTUART (0<<0) /* Steal SERHND_COM1 value */ #define SERHND_HI (1<<2) /* Mux/demux each transferred char by MSB. */ #define SERHND_LO (1<<3) /* Ditto, except that the MSB is cleared. */
This allows configuring EHCI and XHCI consoles separately, simultaneously. Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> --- new in v5 --- docs/misc/xen-command-line.pandoc | 18 ++++++++++++------ xen/drivers/char/serial.c | 6 ++++++ xen/drivers/char/xhci-dbc.c | 20 ++++++++++---------- xen/include/xen/serial.h | 1 + 4 files changed, 29 insertions(+), 16 deletions(-)