linux-kernel - Mainlining of Pyra nub joystick 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160614114523.GC4820@zver>
Date:	Tue, 14 Jun 2016 14:45:23 +0300
From:	Andrey Utkin <andrey_utkin@...tmail.com>
To:	linux-input@...r.kernel.org, devel@...verdev.osuosl.org,
	kernel-mentors@...enic.com, linux-kernel@...r.kernel.org,
	letux-kernel@...nphoenux.org, kernel@...a-handheld.com,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Arnd Bergmann <arnd@...db.de>, Mark Brown <broonie@...nel.org>,
	Daniel Hung-yu Wu <hywu@...gle.com>,
	Moritz Fischer <moritz.fischer@...us.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	S Twiss <stwiss.opensource@...semi.com>,
	Rob Herring <robh@...nel.org>,
	Grant Grundler <grundler@...omium.org>
Subject: Mainlining of Pyra nub joystick driver

There's a pair of "nub" devices on Pyra handheld PC
(https://pyra-handheld.com/), and there's driver for nub, which is going
to be reworked for upstreaming. While the device itself fits most to
"joystick" category, the computer itself lacks touchpad and mouse
buttons, and the existing driver is capable of switching between modes, in
which it shows up like one of the following:
 - scrolling wheel,
 - mouse buttons set,
 - pointer updating its absolute position (graphic pad alike AFAIU),
 - pointer device behaving like actual joystick / pointing stick.

Currently modes switching happens through r/w file in /proc, which is of
couse going to be changed.

I wonder if such mode switching mechanism is tolerable for inclusion to
upstream kernel in this case. I'd like some advice how to rearrange the
driver to save most of flexibility while matching upstream kernel
conventions. I am especially interested in comments from subsystem
maintainers.

Existing driver:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/input/misc/as5013.c;h=1bfb5243f692c0c0a9c93881968849cac947c92d;hb=refs/heads/work/hns/input/as5013