Hi again,
> > Heikki, I don't think anything depends on this commit, is that correct?
>
> Unfortunately we can't fix the values for every UART that has ACPI
> companion like we did before anymore.
>
> There is at least one new platform, that the driver supports, which
> does not have the Designware UART in this "16550 compatible" mode, and
> I guess it's possible that there are others as well. And I guess the
> other values can also be what ever on those platforms.
>
> Jérôme, can you test if using the quirk on Baytrails works:
>
> @@ -302,7 +302,8 @@ static void dw8250_quirks(struct uart_port *p, struct
> dw8250_data *data)
>
> id = acpi_match_device(p->dev->driver->acpi_match_table,
> p->dev);
> - if (id && !strcmp(id->id, "APMC0D08")) {
> + if (id && (!strcmp(id->id, "APMC0D08") ||
> + !strcmp(id->id, "80860F0A"))) {
> p->iotype = UPIO_MEM32;
> p->regshift = 2;
> p->serial_in = dw8250_serial_in32;
Compilation finished with that small modification applied: Bluetooth works
indeed in that case and I don't have the error messages in dmesg anymore.
>
> Please note that this really is not a fix, not even a temporary one
> for this issue. There are a lot of Baytrails on the market. I just
> want to make sure there really is a problem delivering those values as
> device properties with your board.
I guess this confirms there is indeed a problem delivering those values as
devices properties on that specific Baytrail device at least.
Let me know if there is anything else useful I could share/test.
Thanks,
Jérôme
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
