Hi Hans, Thanks for chiming in. Hans de Goede <hdegoede@xxxxxxxxxx> writes: > 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 had seen the linked mail but was missing the context given here. I am not that familiar with the serial devices framework. > > 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. That makes sense. A shorter list of exceptions is better than the longer list of supported device list that is going to be duplicated. I will respin the patches taking the blacklist approach if there is no other feedback. Thanks, Punit
