linux-kernel - Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

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: <20160621144215.333bd825@lxorguk.ukuu.org.uk>
Date:	Tue, 21 Jun 2016 14:42:15 +0100
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Anthony Wong <anthony.wong@...onical.com>
Cc:	Pali Rohár <pali.rohar@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	Ben Gamari <ben@...rt-cactus.org>,
	Hans de Goede <hdegoede@...hat.com>,
	Allen Hung <Allen_Hung@...l.com>,
	Ben Morgan <Ben_Morgan@...l.com>,
	Masaki Ota <masaki.ota@...alps.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

> The fix in the DKMS package you referenced was not written by
> Canonical but by ALPS, as it came from them I think it is reasonable
> they send it to upstream, isn't it? As you can see the patch is non-trivial.

You published it on to milliosn of users, you'd think also mentioning its
existence upstream would have been easy enough.

> After we got the patch from ALPS, we had follow-up conversation a few
> times with our contacts at Taiwan and asked if they would upstream it,
> but unfortunately to no avail. I am as desperate as you if the fix
> cannot land in mainline, which means many Linux users will not benefit
> from it.  We also had opened this bug [1] for this particular issue,
> there is nothing to hide. If there is any code written by us, we
> happily submit them upstream.

Other vendors and users regularly upstream driver code that lurks in
third party repositories or amidst the grues in the dark smelly corners of
the Android underworld. (and contrary to Christoph's comment Canonical are
angels compared with a lot of the Android world)

I can see why you wouldn't want to submit it if ALPS were
going to, but really - not even mentioning it upstream when there was
other work going on was unfortunate. A single Canonical email saying
"You might want to look at the ALPS driver at URL" would have saved all
the wasted effort.

It's also good common sense behaviour - in this case there is no API
difference but vendors who sit on stuff get burned when we merge an
alternative piece of code.

Alan