LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: [RFC][PATCH 0/1] serdev: Support HS-UART serdev slaves over tty
       [not found] <20180424082954.11453-1-shrirang.bagul@canonical.com>
@ 2018-04-24 17:18 ` Johan Hovold
  2018-04-24 21:16   ` Hans de Goede
  0 siblings, 1 reply; 5+ messages in thread
From: Johan Hovold @ 2018-04-24 17:18 UTC (permalink / raw)
  To: Shrirang Bagul
  Cc: johan, linux-serial, gregkh, Rob Herring,
	Frédéric Danis, Hans de Goede, Rafael J. Wysocki,
	Lukas Wunner, linux-kernel

[ Adding some more people on CC. ]

On Tue, Apr 24, 2018 at 04:29:53PM +0800, Shrirang Bagul wrote:
> On systems using Intel Atom (Baytrail-I) SoC's, slave devices connected on
> HSUART1/2 ports are described by the ACPI BIOS as virtual hardware using
> HID's INT3511/INT3512 [1].
> 
> As a consequence, HW manufacturers have complete freedom to install any
> devices on-board as long as they can be accessed over serial tty
> interface. Once such device is Dell Edge 3002 IoT Gateway which sports
> ZigBee & GPS devices on the HS-UART ports 1 & 2 respectively.
> 
> In kernels before the introduction of 'Serial Device Bus (serdev)'
> subsystem, these devices were accessible using /dev/ttySx nodes. But,
> kernels since 4.15 can no longer do so.
> 
> Post 4.15, with CONFIG_SERIAL_DEV_BUS=y, serdev port controller driver
> handles the enumeration for the slaves connected on these ports. Also,
> /dev/ttySx device nodes for these ports are no longer exposed to the
> userspace.
> 
> This patch implements a new driver which binds to the ACPI serdev slaves
> enumerated by the serdev port controller and exposes /dev/ttyHSx device
> nodes which the userspace applications can use. Otherwise, upgrades to 4.15
> or higher kernels would certainly render these devices unusable.
> 
> Considering serdev is new and evolving, this is one approach to solving
> the problem at hand. An obvious drawback is the change in the tty device
> node name from ttySx => ttyHSx, which means userspace applications have to
> be modified (I know that this is strongly discouraged). For the same
> reason, I am submitting these patches as RFC.
> 
> If there are other/better ways of solving this or improving on the
> proposed solution, that will be most helpful.

Yeah, I don't think this is the right solution to this problem. It seems
we need to blacklist (or maybe even use whitelists) ACPI-ids until there
are drivers for the slave devices that would otherwise be claimed by
serdev.

> This patch is based on:
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v4.17-rc2
> 
> [1] Enabling Multi-COM Port for Microsoft Windows OS 8.1 & 10 / IoT Core [Sec. 4.1]
> (https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/enabling-multi-com-port-white-paper.pdf)

Thanks,
Johan

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC][PATCH 0/1] serdev: Support HS-UART serdev slaves over tty
  2018-04-24 17:18 ` [RFC][PATCH 0/1] serdev: Support HS-UART serdev slaves over tty Johan Hovold
@ 2018-04-24 21:16   ` Hans de Goede
  2018-04-25  7:47     ` Johan Hovold
  0 siblings, 1 reply; 5+ messages in thread
From: Hans de Goede @ 2018-04-24 21:16 UTC (permalink / raw)
  To: Johan Hovold, Shrirang Bagul
  Cc: linux-serial, gregkh, Rob Herring, Frédéric Danis,
	Rafael J. Wysocki, Lukas Wunner, linux-kernel

Hi,

On 24-04-18 19:18, Johan Hovold wrote:
> [ Adding some more people on CC. ]
> 
> On Tue, Apr 24, 2018 at 04:29:53PM +0800, Shrirang Bagul wrote:
>> On systems using Intel Atom (Baytrail-I) SoC's, slave devices connected on
>> HSUART1/2 ports are described by the ACPI BIOS as virtual hardware using
>> HID's INT3511/INT3512 [1].
>>
>> As a consequence, HW manufacturers have complete freedom to install any
>> devices on-board as long as they can be accessed over serial tty
>> interface. Once such device is Dell Edge 3002 IoT Gateway which sports
>> ZigBee & GPS devices on the HS-UART ports 1 & 2 respectively.
>>
>> In kernels before the introduction of 'Serial Device Bus (serdev)'
>> subsystem, these devices were accessible using /dev/ttySx nodes. But,
>> kernels since 4.15 can no longer do so.
>>
>> Post 4.15, with CONFIG_SERIAL_DEV_BUS=y, serdev port controller driver
>> handles the enumeration for the slaves connected on these ports. Also,
>> /dev/ttySx device nodes for these ports are no longer exposed to the
>> userspace.
>>
>> This patch implements a new driver which binds to the ACPI serdev slaves
>> enumerated by the serdev port controller and exposes /dev/ttyHSx device
>> nodes which the userspace applications can use. Otherwise, upgrades to 4.15
>> or higher kernels would certainly render these devices unusable.
>>
>> Considering serdev is new and evolving, this is one approach to solving
>> the problem at hand. An obvious drawback is the change in the tty device
>> node name from ttySx => ttyHSx, which means userspace applications have to
>> be modified (I know that this is strongly discouraged). For the same
>> reason, I am submitting these patches as RFC.
>>
>> If there are other/better ways of solving this or improving on the
>> proposed solution, that will be most helpful.
> 
> Yeah, I don't think this is the right solution to this problem. It seems
> we need to blacklist (or maybe even use whitelists) ACPI-ids until there
> are drivers for the slave devices that would otherwise be claimed by
> serdev.

FWIW I've been using this patch for a while for realtek UART attached bluetooth:
https://github.com/jwrdegoede/linux-sunxi/commit/bc904e3703940600ca66c65fcdb0a8cb01dff55d
which is a gross hack.

If we're going to do a whitelist for this, it better support some sort of
wildcards as there are a LOT of BCM2E?? devices which need to be on the
whitelist. I think a blacklist would actually be better though, this also
documents which devices are lacking a proper kernel (where applicable).

Regards,

Hans


> 
>> This patch is based on:
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v4.17-rc2
>>
>> [1] Enabling Multi-COM Port for Microsoft Windows OS 8.1 & 10 / IoT Core [Sec. 4.1]
>> (https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/enabling-multi-com-port-white-paper.pdf)
> 
> Thanks,
> Johan
> 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC][PATCH 0/1] serdev: Support HS-UART serdev slaves over tty
  2018-04-24 21:16   ` Hans de Goede
@ 2018-04-25  7:47     ` Johan Hovold
  2018-04-25  9:00       ` Rafael J. Wysocki
  0 siblings, 1 reply; 5+ messages in thread
From: Johan Hovold @ 2018-04-25  7:47 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Johan Hovold, Shrirang Bagul, linux-serial, gregkh, Rob Herring,
	Frédéric Danis, Rafael J. Wysocki, Lukas Wunner,
	linux-kernel

On Tue, Apr 24, 2018 at 11:16:38PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 24-04-18 19:18, Johan Hovold wrote:
> > [ Adding some more people on CC. ]
> > 
> > On Tue, Apr 24, 2018 at 04:29:53PM +0800, Shrirang Bagul wrote:
> >> On systems using Intel Atom (Baytrail-I) SoC's, slave devices connected on
> >> HSUART1/2 ports are described by the ACPI BIOS as virtual hardware using
> >> HID's INT3511/INT3512 [1].
> >>
> >> As a consequence, HW manufacturers have complete freedom to install any
> >> devices on-board as long as they can be accessed over serial tty
> >> interface. Once such device is Dell Edge 3002 IoT Gateway which sports
> >> ZigBee & GPS devices on the HS-UART ports 1 & 2 respectively.
> >>
> >> In kernels before the introduction of 'Serial Device Bus (serdev)'
> >> subsystem, these devices were accessible using /dev/ttySx nodes. But,
> >> kernels since 4.15 can no longer do so.
> >>
> >> Post 4.15, with CONFIG_SERIAL_DEV_BUS=y, serdev port controller driver
> >> handles the enumeration for the slaves connected on these ports. Also,
> >> /dev/ttySx device nodes for these ports are no longer exposed to the
> >> userspace.
> >>
> >> This patch implements a new driver which binds to the ACPI serdev slaves
> >> enumerated by the serdev port controller and exposes /dev/ttyHSx device
> >> nodes which the userspace applications can use. Otherwise, upgrades to 4.15
> >> or higher kernels would certainly render these devices unusable.
> >>
> >> Considering serdev is new and evolving, this is one approach to solving
> >> the problem at hand. An obvious drawback is the change in the tty device
> >> node name from ttySx => ttyHSx, which means userspace applications have to
> >> be modified (I know that this is strongly discouraged). For the same
> >> reason, I am submitting these patches as RFC.
> >>
> >> If there are other/better ways of solving this or improving on the
> >> proposed solution, that will be most helpful.
> > 
> > Yeah, I don't think this is the right solution to this problem. It seems
> > we need to blacklist (or maybe even use whitelists) ACPI-ids until there
> > are drivers for the slave devices that would otherwise be claimed by
> > serdev.
> 
> FWIW I've been using this patch for a while for realtek UART attached bluetooth:
> https://github.com/jwrdegoede/linux-sunxi/commit/bc904e3703940600ca66c65fcdb0a8cb01dff55d
> which is a gross hack.
> 
> If we're going to do a whitelist for this, it better support some sort of
> wildcards as there are a LOT of BCM2E?? devices which need to be on the
> whitelist. I think a blacklist would actually be better though, this also
> documents which devices are lacking a proper kernel (where applicable).

Yeah, you guys know the ACPI space better than I do. I just fear that
if we go with the blacklist approach, we'll be playing a whack-a-mole
with this for a long time when people start upgrading there systems to
4.15 and discover that their serial ports are gone.

Since this would qualify as a severe regression, me may need to consider
adding a serdev whitelist for every ACPI id we add to a serdev driver
instead.

Thanks,
Johan

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC][PATCH 0/1] serdev: Support HS-UART serdev slaves over tty
  2018-04-25  7:47     ` Johan Hovold
@ 2018-04-25  9:00       ` Rafael J. Wysocki
  2018-04-25  9:12         ` Johan Hovold
  0 siblings, 1 reply; 5+ messages in thread
From: Rafael J. Wysocki @ 2018-04-25  9:00 UTC (permalink / raw)
  To: Johan Hovold, Shrirang Bagul
  Cc: Hans de Goede, linux-serial, gregkh, Rob Herring,
	Frédéric Danis, Lukas Wunner, linux-kernel, linux-acpi

On Wednesday, April 25, 2018 9:47:36 AM CEST Johan Hovold wrote:
> On Tue, Apr 24, 2018 at 11:16:38PM +0200, Hans de Goede wrote:
> > Hi,
> > 
> > On 24-04-18 19:18, Johan Hovold wrote:
> > > [ Adding some more people on CC. ]
> > > 
> > > On Tue, Apr 24, 2018 at 04:29:53PM +0800, Shrirang Bagul wrote:
> > >> On systems using Intel Atom (Baytrail-I) SoC's, slave devices connected on
> > >> HSUART1/2 ports are described by the ACPI BIOS as virtual hardware using
> > >> HID's INT3511/INT3512 [1].
> > >>
> > >> As a consequence, HW manufacturers have complete freedom to install any
> > >> devices on-board as long as they can be accessed over serial tty
> > >> interface. Once such device is Dell Edge 3002 IoT Gateway which sports
> > >> ZigBee & GPS devices on the HS-UART ports 1 & 2 respectively.
> > >>
> > >> In kernels before the introduction of 'Serial Device Bus (serdev)'
> > >> subsystem, these devices were accessible using /dev/ttySx nodes. But,
> > >> kernels since 4.15 can no longer do so.
> > >>
> > >> Post 4.15, with CONFIG_SERIAL_DEV_BUS=y, serdev port controller driver
> > >> handles the enumeration for the slaves connected on these ports. Also,
> > >> /dev/ttySx device nodes for these ports are no longer exposed to the
> > >> userspace.
> > >>
> > >> This patch implements a new driver which binds to the ACPI serdev slaves
> > >> enumerated by the serdev port controller and exposes /dev/ttyHSx device
> > >> nodes which the userspace applications can use. Otherwise, upgrades to 4.15
> > >> or higher kernels would certainly render these devices unusable.
> > >>
> > >> Considering serdev is new and evolving, this is one approach to solving
> > >> the problem at hand. An obvious drawback is the change in the tty device
> > >> node name from ttySx => ttyHSx, which means userspace applications have to
> > >> be modified (I know that this is strongly discouraged). For the same
> > >> reason, I am submitting these patches as RFC.
> > >>
> > >> If there are other/better ways of solving this or improving on the
> > >> proposed solution, that will be most helpful.
> > > 
> > > Yeah, I don't think this is the right solution to this problem. It seems
> > > we need to blacklist (or maybe even use whitelists) ACPI-ids until there
> > > are drivers for the slave devices that would otherwise be claimed by
> > > serdev.
> > 
> > FWIW I've been using this patch for a while for realtek UART attached bluetooth:
> > https://github.com/jwrdegoede/linux-sunxi/commit/bc904e3703940600ca66c65fcdb0a8cb01dff55d
> > which is a gross hack.
> > 
> > If we're going to do a whitelist for this, it better support some sort of
> > wildcards as there are a LOT of BCM2E?? devices which need to be on the
> > whitelist. I think a blacklist would actually be better though, this also
> > documents which devices are lacking a proper kernel (where applicable).
> 
> Yeah, you guys know the ACPI space better than I do. I just fear that
> if we go with the blacklist approach, we'll be playing a whack-a-mole
> with this for a long time when people start upgrading there systems to
> 4.15 and discover that their serial ports are gone.
> 
> Since this would qualify as a severe regression, me may need to consider
> adding a serdev whitelist for every ACPI id we add to a serdev driver
> instead.

OK, so let's have the ACPI discussion on linux-acpi pretty please.

Could this be resent with a CC to linux-acpi for some more complete context?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC][PATCH 0/1] serdev: Support HS-UART serdev slaves over tty
  2018-04-25  9:00       ` Rafael J. Wysocki
@ 2018-04-25  9:12         ` Johan Hovold
  0 siblings, 0 replies; 5+ messages in thread
From: Johan Hovold @ 2018-04-25  9:12 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Johan Hovold, Shrirang Bagul, Hans de Goede, linux-serial,
	gregkh, Rob Herring, Frédéric Danis, Lukas Wunner,
	linux-kernel, linux-acpi

On Wed, Apr 25, 2018 at 11:00:47AM +0200, Rafael J. Wysocki wrote:
> On Wednesday, April 25, 2018 9:47:36 AM CEST Johan Hovold wrote:
> > On Tue, Apr 24, 2018 at 11:16:38PM +0200, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 24-04-18 19:18, Johan Hovold wrote:
> > > > [ Adding some more people on CC. ]
> > > > 
> > > > On Tue, Apr 24, 2018 at 04:29:53PM +0800, Shrirang Bagul wrote:
> > > >> On systems using Intel Atom (Baytrail-I) SoC's, slave devices connected on
> > > >> HSUART1/2 ports are described by the ACPI BIOS as virtual hardware using
> > > >> HID's INT3511/INT3512 [1].
> > > >>
> > > >> As a consequence, HW manufacturers have complete freedom to install any
> > > >> devices on-board as long as they can be accessed over serial tty
> > > >> interface. Once such device is Dell Edge 3002 IoT Gateway which sports
> > > >> ZigBee & GPS devices on the HS-UART ports 1 & 2 respectively.
> > > >>
> > > >> In kernels before the introduction of 'Serial Device Bus (serdev)'
> > > >> subsystem, these devices were accessible using /dev/ttySx nodes. But,
> > > >> kernels since 4.15 can no longer do so.
> > > >>
> > > >> Post 4.15, with CONFIG_SERIAL_DEV_BUS=y, serdev port controller driver
> > > >> handles the enumeration for the slaves connected on these ports. Also,
> > > >> /dev/ttySx device nodes for these ports are no longer exposed to the
> > > >> userspace.
> > > >>
> > > >> This patch implements a new driver which binds to the ACPI serdev slaves
> > > >> enumerated by the serdev port controller and exposes /dev/ttyHSx device
> > > >> nodes which the userspace applications can use. Otherwise, upgrades to 4.15
> > > >> or higher kernels would certainly render these devices unusable.
> > > >>
> > > >> Considering serdev is new and evolving, this is one approach to solving
> > > >> the problem at hand. An obvious drawback is the change in the tty device
> > > >> node name from ttySx => ttyHSx, which means userspace applications have to
> > > >> be modified (I know that this is strongly discouraged). For the same
> > > >> reason, I am submitting these patches as RFC.
> > > >>
> > > >> If there are other/better ways of solving this or improving on the
> > > >> proposed solution, that will be most helpful.
> > > > 
> > > > Yeah, I don't think this is the right solution to this problem. It seems
> > > > we need to blacklist (or maybe even use whitelists) ACPI-ids until there
> > > > are drivers for the slave devices that would otherwise be claimed by
> > > > serdev.
> > > 
> > > FWIW I've been using this patch for a while for realtek UART attached bluetooth:
> > > https://github.com/jwrdegoede/linux-sunxi/commit/bc904e3703940600ca66c65fcdb0a8cb01dff55d
> > > which is a gross hack.
> > > 
> > > If we're going to do a whitelist for this, it better support some sort of
> > > wildcards as there are a LOT of BCM2E?? devices which need to be on the
> > > whitelist. I think a blacklist would actually be better though, this also
> > > documents which devices are lacking a proper kernel (where applicable).
> > 
> > Yeah, you guys know the ACPI space better than I do. I just fear that
> > if we go with the blacklist approach, we'll be playing a whack-a-mole
> > with this for a long time when people start upgrading there systems to
> > 4.15 and discover that their serial ports are gone.
> > 
> > Since this would qualify as a severe regression, me may need to consider
> > adding a serdev whitelist for every ACPI id we add to a serdev driver
> > instead.
> 
> OK, so let's have the ACPI discussion on linux-acpi pretty please.

Oh, sorry, I forgot to add linux-acpi.

> Could this be resent with a CC to linux-acpi for some more complete
> context?

Fortunately, I think the relevant context is still there above.

In short, when we added ACPI support to serdev, serdev started claiming
all slave devices to UARTs that happen to described by ACPI. Regardless
of whether there's a kernel driver for them or not. This means that
serial ports (/dev/ttySn) will simply start disappearing on such systems
when updating to 4.15 unless we act somehow (blacklist or whitelist).

Thanks,
Johan

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-04-25  9:12 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20180424082954.11453-1-shrirang.bagul@canonical.com>
2018-04-24 17:18 ` [RFC][PATCH 0/1] serdev: Support HS-UART serdev slaves over tty Johan Hovold
2018-04-24 21:16   ` Hans de Goede
2018-04-25  7:47     ` Johan Hovold
2018-04-25  9:00       ` Rafael J. Wysocki
2018-04-25  9:12         ` Johan Hovold

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).