Messages in this thread | | | Subject | Re: [RFC 0/1] serdes: Add whitelist to bring back missing serial port | From | Hans de Goede <> | Date | Mon, 16 Dec 2019 07:29:46 +0100 |
| |
HI,
On 16-12-2019 05:08, Punit Agrawal wrote: > > Hi, > > While booting v5.5-rc1 on Apollo Lake based UP2[0], I ran into an > issue with the primary serial port. The kernel is able to output to > ttyS0 but systemd isn't able to raise a login prompt. On further > investigation, it turns out that no serial device (/dev/ttyS0) is > being created as the device is claimed by serdev sub-system. > > The issue has been reported in a few different places[0][1]. A patch > was proposed to solve the issue but there doesn't seem to be any > further progress[2]. Feedback on the thread suggested implementing a > whitelist based approach - which is what this RFC does. > > With this patch, systemd is able to create a login prompt. The > whitelist has intentionally been left blank as it's not clear which > devices go in there.
As I already mentioned when discussing this upstream:
https://marc.info/?l=linux-serial&m=152460460418058&w=2
I am afraid that a whitelist is not going to fly, that means duplicating all the device-ids in all the relevant drivers and that everytime we add a device-id we need to do so in 2 places. Just take a look at drivers/bluetooth/hci_bcm.c at the device-id list starting at line 1187 and that is just 1 driver.
I also mention a hack for RTL8723BS devices there, but those have gotten a proper in kernel driver in the mean time.
Looking at the ACPI device id list in the proposed upstream fix with a "hsuart serdev driver": https://www.spinics.net/lists/linux-serial/msg30035.html
+static const struct acpi_device_id hsuart_acpi_match[] = { + {"INT3511", 0}, + {"INT3512", 0}, + { }, +};
Then blacklist with just these 2 ids would clearly be a much better approach, as we are talking 2 ids vs 50+ ids here for whitelist vs blacklist.
The whitepaper on this: https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/enabling-multi-com-port-white-paper.pdf Also mentions these 2 as "the default Hardware IDs (INT3511 and INT3512) used here are Intel HS-UART COM port peripheral device IDs." as the hardware ids to use if the port has no specific function, in other words to use these 2 ids when under Linux the serial-port should just show up as a /dev/ttyS* device.
So I believe that the fix here is using a blacklist with just these 2 ids in there.
Regards,
Hans
| |