Re: [RFC 0/1] serdes: Add whitelist to bring back missing serial port

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux