Re: [PATCH v3 0/3] IR driver for USB-UIRT device

From: Johan Hovold <johan@kernel.org>
To: Oliver Neukum <oneukum@suse.com>
Cc: Sean Young <sean@mess.org>,
	linux-media@vger.kernel.org, linux-usb@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jon Rhees <support@usbuirt.com>
Subject: Re: [PATCH v3 0/3] IR driver for USB-UIRT device
Date: Wed, 23 Jun 2021 15:10:20 +0200	[thread overview]
Message-ID: <YNMyvCaZUIDOnSc9@hovoldconsulting.com> (raw)
In-Reply-To: <35840cdac1dcb2808e98ebb57afeba352624d15c.camel@suse.com>

Sorry about the late reply on this one too.

On Tue, May 25, 2021 at 02:25:49PM +0200, Oliver Neukum wrote:
> Am Donnerstag, den 20.05.2021, 15:31 +0200 schrieb Johan Hovold:

> > Isn't that already handled by lircd using uinput?
> 
> The problem with that reasoning, though it is true, is
> 
> 1) We would need to remove a lot of subsystems if we took that
> to the logical conclusion. 

Removing code is always nice. ;)

> 2) It makes runtime PM much harder

Possibly, depends on the bus and device.

> 3) We end up with two classes of LIRC devices

We already do, right? That's kind of my point since we have lircd
supporting uinput.

> > I hear you, but we still need to have those discussions from time to
> > time to make sure our architecture is sane. One of the problems today
> > with the kernel development process appears to be that too few
> > questions
> > are asked. If it builds, ship it...
> 
> Indeed, so, could we force a line discipline on a device on the kernel
> level? Code duplication is bad.

Not sure I understand what you have mind here. serdev is sort of a
line-discipline which we'd "force" on a device if there's a matching
description in devicetree, while line disciplines always need to be
instantiated by user space. Or are you referring to ldisc/serdev code
reuse?

> > But I think I've got that point across by now.
> 
> Yes and and we need to think about the conclusion we draw from
> that point. It seems to me that an architecture that pushes data
> through the whole tty layer into a demon, then through uinput
> is definitely not elegant.

The elegant answer is serdev, but it does not yet support the features
needed in this case (i.e. hotplugging).

Since we already support user-space drivers for these devices, I see
nothing wrong with implementing support for another one in user space
unless there are strong reasons against doing so (e.g. performance,
pm or usability). But if uinput works then great, we're done.

> So what else can we do, so that devices that are internally
> a serial chip plus additional stuff but externally unrelated
> devices? It looks to me we are in need of creativity beyond two options
> here.

Why? Leaving hotplugging aside for a moment, what is it that you cannot
do using either a serdev/ldisc driver or a user-space driver?

Johan