linux-kernel - gpio-ucb1400

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-next>] [day] [month] [year] [list]

Message-ID: <1364586399.4216.312.camel@amber.site>
Date:	Fri, 29 Mar 2013 20:46:39 +0100
From:	Jean Delvare <jdelvare@...e.de>
To:	linux-kernel <linux-kernel@...r.kernel.org>,
	Marek Vasut <marek.vasut@...il.com>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: gpio-ucb1400

Hi all,

In September 2009, a driver for the GPIO function of the UCB1400 chip
was added to the kernel tree. The probe function of this driver requires
ucbdata to be set. The only place where this happens is in function
ucb1400_gpio_set_data(). This function was never call, and still isn't.
So this is dead code for 3.5 years as far as the upstream kernel is
concerned.

To make things worse, this driver can't be built as a module, for no
good reason that I can see.

Marek, can you explain what was the point of submitting this driver that
nobody can use?

I would like either this driver to be fixed so that it can be used (and
that would IMHO start with dropping the ugly ucb1400_gpio_set_data hook
and global variable ucbdata), or this driver to be dropped from the
kernel tree. If the driver is kept, it should be adjusted so that it can
be built as a module.

If I overlooked something, please let me know.

Thanks,
-- 
Jean Delvare
Suse L3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/