Re: [Xen-devel] [PATCH v2] ns16550: Add ACPI support for ARM only

[Julien Grall <julien@xxxxxxx>]

Hi Jan,

On 21/01/2020 11:25, Jan Beulich wrote:
> On 21.01.2020 12:16, Julien Grall wrote:
> > On 21/01/2020 11:13, Jan Beulich wrote:
> > > > +    if ( ACPI_FAILURE(status) )
> > > > +    {
> > > > +        printk("ns16550: Failed to get SPCR table\n");
> > > Is such a message warranted? I.e. wouldn't it trigger on all
> > > systems not having the table, which is hardly what you/we want?
> > >
> > > > +        return -EINVAL;
> > > Also, is it really an error if there's no such table?
> > You can only be there if the arm-uart.c found an SPCR table. So this is
> > a sanity check. Therefore I think the error message is warrant here.
> If so - fine. But from
>
> ACPI_DEVICE_START(ans16550, "NS16550 UART", DEVICE_SERIAL)
>      .class_type = ACPI_DBG2_16550_COMPATIBLE,
>      .init = ns16550_acpi_uart_init,
> ACPI_DEVICE_END
>
> I can't see why this would be. Would you mind educating me?
The bits you pasted only register a driver for any serial device with 
the class 16550_COMPATIBLE. This is up to an upper layer to decide how 
class_type will be interpreted.
As I mentioned in v1, in the case of serial, the class_type will be 
matches against the field interface_type in the SPCR table. This is done 
in the function acpi_uart_init().
The function will try to retrieve the SPCR table. If there is none, then 
it will bail out. Otherwise, it will call the generic device framework 
to lookup for the driver.
Therefore a serial driver can only be called with the SPCR table 
actually exists.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel