linux-kernel - Re: [PATCH 2/3] input: serio: allow more than one byte to be sent at once

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20200513170411.GD9559@gofer.mess.org>
Date:   Wed, 13 May 2020 18:04:11 +0100
From:   Sean Young <sean@...s.org>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
        linux-media@...r.kernel.org
Subject: Re: [PATCH 2/3] input: serio: allow more than one byte to be sent at
 once

On Tue, May 12, 2020 at 10:37:27AM -0700, Dmitry Torokhov wrote:
> On Tue, May 12, 2020 at 10:07:24AM +0100, Sean Young wrote:
> > Now it would be nice to have a discussion about this rather than being
> > dismissed with:
> > 
> > > > > Ummm, serial protocol data size is at most 9 bits so I have no earthly
> > > > > idea how they expect to get 16.
> > 
> > Which is just a tad insulting.
> 
> That was not meant to be insulting, however serial protocol defines that
> the data size is at most 9 bits, so expecting that one can transmit
> anything more than that _atomically_ is wrong. If your device/firmware
> requires 16 bits to be transferred as indivisible units, then serial
> port abstraction is wrong one to be used.

Honestly thank you for explaining that. I had no idea this was an abstract
point about the demarcations of serial port-ness.

There is no physical rs-232 cabling involved at all in this case.

> Now serio is layer "above" serial ports (but does not have to have
> an underlying serial port) that provides byte-oriented communication
> that is expected to mostly flow into host. Its does not expect heavy
> data flows coming from the host and into the device (if you look at all
> the touchscreens, psmouse, etc, they all send initialization sequences
> to the device, and then all the data flows into the host). Therefore
> there is little benefit in optimizing serio writes.

True, I didn't think this would make much of an measurable improvement,
but still, some.

> You are using performance clams as a clutch for the requirement of
> sending u16s, but as I mentioned it is wrong if you use serial ports
> abstraction layer. Greg mentioned ir-usb. You can maybe enhance it, or
> create a similar driver that connects USB to rc-core and ensures that
> you can communicate with the device with exact format it needs.

Yes, I'll go down this route.

Thank you for the discussion, it was very helpful.


Sean