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
