linux-kernel - Re: [PATCH] pinctrl: baytrail: show output gpio state correctly on Intel Baytrail

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

Message-ID: <CACRpkda8eRp5tzvUppVvAfh0djR6q=3kYuec-nvJvnd+aCHC=A@mail.gmail.com>
Date:	Fri, 14 Nov 2014 10:30:55 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:	Felipe Balbi <balbi@...com>,
	David Cohen <david.a.cohen@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	stable <stable@...r.kernel.org>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>
Subject: Re: [PATCH] pinctrl: baytrail: show output gpio state correctly on
 Intel Baytrail

On Mon, Nov 3, 2014 at 7:42 PM, Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:
> On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote:

>> that's an issue that needs solving, but forcing every x86 kernel to ship
>> with this driver, is not a proper solution.
>
> I would rather have the driver build in to the kernel now (and btw it
> has been already in mainline quite some time so I suspect many distros
> have already enabled it), than turning it module and render some devices
> that have been working previously, fail suddenly.

We have an analogous problem with large device tree kernels for ARM
(supporting a multitude of ARM subarchitectures): a lot of statically
compiled-in drivers that just idle around after boot.

What would be nice was for the kernel to have a way of marking some
platform drivers such that if it has not been probed by init_late(),
the entire driver would be discarded, like a module that gets unloaded.

When I posed this idea in some forum it was considered "pretty hard
to achieve" (plus I guess it runs into the dilemma that we can never
discard strings) but I still think it'd be the right thing to do. It'd be very
straight-forward for driver authors to annotate their on-chip platform
drivers with some MODULE_LATE_DISCARD() or whatever.

Yours,
Linus Walleij
--
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/