All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Young <sean@mess.org>
To: Johan Hovold <johan@kernel.org>
Cc: linux-media@vger.kernel.org, linux-usb@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jon Rhees <support@usbuirt.com>, Oliver Neukum <oneukum@suse.com>
Subject: Re: [PATCH v3 0/3] IR driver for USB-UIRT device
Date: Tue, 11 May 2021 11:32:19 +0100	[thread overview]
Message-ID: <20210511103219.GA13769@gofer.mess.org> (raw)
In-Reply-To: <YJjrkhfN9Sgq6UX8@hovoldconsulting.com>

On Mon, May 10, 2021 at 10:15:14AM +0200, Johan Hovold wrote:
> On Thu, May 06, 2021 at 01:44:52PM +0100, Sean Young wrote:
> > This is a new rc-core driver for the USB-UIRT which you can see here
> > http://www.usbuirt.com/
> > 
> > This device is supported in lirc, via the usb serial kernel driver. This
> > driver is both for rc-core, which means it can use kernel/BPF decoding
> > ec. Also this implement is superior because it can:
> >  - support learning mode
> >  - setting transmit carrier
> >  - larger transmits using streaming tx command
> 
> This looks like something which should have been implemented as a
> line-discipline or serdev driver instead of reimplementing a minimal
> on-off ftdi driver and tying it closely to the RC subsystem.

The device is an infrared device, I'm not sure what it is lost by
doing it this way. The "minimal on-off ftdi driver" is super trivial.

> Why can't you just add support for the above features to whatever
> subsystem is managing this device today?
> 
> Serdev still doesn't support hotplugging unfortunately so that route may
> take a bit more work.

There seems to be at least three ways of attaching drivers to serial
devices: serio, serdev, and line-discipline. All seem to have limitations,
as you say none of them provide a way of hotplugging devices without
user-space attaching them through an ioctl or so.

If you want to go down this route, then ideally you'd want a quirk on
fdti saying "attach usb-uirt serdev device to this pid/vid". Considering
module dependencies, I don't know how that could work without again
userspace getting involved.

Getting userspace involved seem like a big song and dance because the
device uses an fdti device, even though it's not a serial port because
it's hardwired for infrared functions, no db9 connector in sight.


Sean

  reply	other threads:[~2021-05-11 10:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06 12:44 [PATCH v3 0/3] IR driver for USB-UIRT device Sean Young
2021-05-06 12:44 ` [PATCH v3 1/3] USB: serial: move ftdi_sio.h into include directories Sean Young
2021-05-14 11:16   ` Johan Hovold
2021-05-06 12:44 ` [PATCH v3 2/3] media: rc: new driver for USB-UIRT device Sean Young
2021-05-14 11:38   ` Johan Hovold
2021-05-15  9:52     ` Sean Young
2021-05-17  9:38       ` Johan Hovold
2021-05-06 12:44 ` [PATCH v3 3/3] USB: serial: blacklist USB-UIRT when driver is selected Sean Young
2021-05-14 11:40   ` Johan Hovold
2021-05-15  9:56     ` Sean Young
2021-05-17  9:40       ` Johan Hovold
2021-05-10  8:15 ` [PATCH v3 0/3] IR driver for USB-UIRT device Johan Hovold
2021-05-11 10:32   ` Sean Young [this message]
2021-05-14 11:16     ` Johan Hovold
2021-05-15  9:22       ` Sean Young
2021-05-17  9:30         ` Johan Hovold
2021-05-17 10:35           ` Sean Young
2021-05-17 12:35             ` Sean Young
2021-05-20 13:40               ` Johan Hovold
2021-05-20 13:31             ` Johan Hovold
2021-05-21 11:39               ` Sean Young
2021-06-23 12:48                 ` Johan Hovold
2021-05-25 12:25               ` Oliver Neukum
2021-06-23 13:10                 ` Johan Hovold
2021-06-24  9:13                   ` Sean Young
2021-06-24  9:41                     ` Johan Hovold
2021-06-25  8:08                       ` Sean Young
2021-07-02 10:44                         ` Johan Hovold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210511103219.GA13769@gofer.mess.org \
    --to=sean@mess.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan@kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oneukum@suse.com \
    --cc=support@usbuirt.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.