On Wed, Nov 02, 2016 at 02:52:12PM +0100, Jérôme de Bretagne wrote: > 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. I can reproduce this now with a Thinkpad10 we have. Cheers, -- heikki -- 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