linux-kernel - Re: [PATCH v5 4/5] Input: cs40l50 - Add support for the CS40L50 haptic driver

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]

Date: Wed, 24 Jan 2024 20:58:28 +0000
From: James Ogletree <James.Ogletree@...rus.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
CC: James Ogletree <jogletre@...nsource.cirrus.com>,
        Fred Treven
	<Fred.Treven@...rus.com>,
        Ben Bright <Ben.Bright@...rus.com>,
        Conor Dooley
	<conor+dt@...nel.org>,
        Simon Trimmer <simont@...nsource.cirrus.com>,
        Charles
 Keepax <ckeepax@...nsource.cirrus.com>,
        James Schulman
	<James.Schulman@...rus.com>,
        David Rhodes <David.Rhodes@...rus.com>,
        Jeff
 LaBundy <jeff@...undy.com>,
        "open list:CIRRUS LOGIC HAPTIC DRIVERS"
	<patches@...nsource.cirrus.com>,
        "open list:INPUT (KEYBOARD, MOUSE, JOYSTICK,
 TOUCHSCREEN)..." <linux-input@...r.kernel.org>,
        open list
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 4/5] Input: cs40l50 - Add support for the CS40L50
 haptic driver

Hi Dmitry,

> On Jan 12, 2024, at 9:41 AM, James Ogletree <James.Ogletree@...rus.com> wrote:
> 
>> On Jan 11, 2024, at 1:28 AM, Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
>> 
>> On Wed, Jan 10, 2024 at 02:36:55PM +0000, James Ogletree wrote:
>>> 
>>>> On Jan 9, 2024, at 4:31 PM, Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
>>>> 
>>>> On Tue, Jan 09, 2024 at 10:03:02PM +0000, James Ogletree wrote:
>>>>> 
>>>>> 
>>>>>> On Jan 6, 2024, at 7:58 PM, Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
>>>>>> 
>>>>>> On Thu, Jan 04, 2024 at 10:36:37PM +0000, James Ogletree wrote:
>>>>>>> + } else {
>>>>>>> + queue_work(info->vibe_wq, &info->vibe_stop_work);
>>>>>> 
>>>>>> Which effect are you stopping? All of them? You need to stop a
>>>>>> particular one.
>>>>> 
>>>>> Our implementation of “stop” stops all effects in flight which is intended.
>>>>> That is probably unusual so I will add a comment here in the next
>>>>> version.
>>>> 
>>>> Again, please implement the driver properly, not define your own
>>>> carveouts for the expected behavior.
>>> 
>>> Ack, and a clarification question: the device is not actually able to
>>> play multiple effects at once. In that case, does stopping a specific
>>> effect entail just cancelling an effect in the queue?
>> 
>> In this case I believe the device should declare maximum number of
>> effects as 1. Userspace is supposed to determine maximum number of
>> simultaneously playable effects by issuing EVIOCGEFFECTS ioctl on the
>> corresponding event device.
> 
> Is it possible to specify the device’s maximum simultaneous effects
> without also restricting the number of effects the user can upload? It
> looks like both are tied to ff->max_effects.
> 
> Best,
> James
> 

Is there an opportunity here for a subsystem change to disassociate max
upload-able effects and max simultaneously playable effects, or if not what
do you advise in the case of a device in which the two differ? Or is this
a misuse of the subsystem in some way?

Best,
James