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] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.2002031100500.31058@cbobk.fhfr.pm>
Date:   Mon, 3 Feb 2020 11:02:19 +0100 (CET)
From:   Jiri Kosina <jikos@...nel.org>
To:     Roderick Colenbrander <thunderbird2k@...il.com>
cc:     Martyn Welch <martyn@...chs.me.uk>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        linux-input <linux-input@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Conn O'Griofa <connogriofa@...il.com>,
        "Colenbrander, Roelof" <roderick.colenbrander@...y.com>
Subject: Re: [PATCH] HID: Sony: Add support for Gasia controllers

On Tue, 28 Jan 2020, Roderick Colenbrander wrote:

> Let me explain the situation a little bit better from our angle. These 
> devices exist and from the Linux community perspective of course they 
> should see some level of support. And as I said since this is PS3 
> generation I don't have much of a concern.
> 
> Where it becomes tricky for any company in our situation is the support 
> side. We don't know these devices and don't have access to datasheets or 
> anything, but when such code is in our "official driver" it means we 
> have to involve them in our QA process and support them in some manner 
> (kind of legitimizing their existence as well). We now support this 
> driver in a large capacity (pretty much all mobile devices will start 
> shipping it) it puts challenges on our partners (not a big issue since 
> just PS3 right now).
> 
> As you can see this creates an awkward situation. I'm sure there other 
> such devices as well e.g. counterfeit Logitech keyboards, USB serial 
> adapters and other periperhals with similar challenges. In an ideal 
> world the support would live in another driver, but since in case of 
> this "fake" PS3 controller it "share" our product / vendor ids it is 
> tricky. At this point there is not a strong enough case yet to augment 
> the "hid-quirks" to do so, but perhaps if it became a serious issue 
> (e.g. for newer controllers) maybe we need to think of something.

If this is a big issue for you, one possible way around it would be 
creating a module parameter which would tell the driver whether it should 
those "fake" devices, and you can then turn it off in your products (or we 
can of course start the "what should the default setting me" bikeshedding 
:) ).

Thanks,

-- 
Jiri Kosina
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ