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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20141104193424.GT1618@lahna.fi.intel.com>
Date:	Tue, 4 Nov 2014 21:34:24 +0200
From:	Mika Westerberg <mika.westerberg@...ux.intel.com>
To:	David Cohen <david.a.cohen@...ux.intel.com>
Cc:	Felipe Balbi <balbi@...com>,
	Linus Walleij <linus.walleij@...aro.org>,
	"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@...ux.intel.com
Subject: Re: [PATCH] pinctrl: baytrail: show output gpio state correctly on
 Intel Baytrail

On Tue, Nov 04, 2014 at 11:11:16AM -0800, David Cohen wrote:
> > It is not implicit at all.
> > 
> > The user of the GPIO in ACPI DSDT table says something like:
> > 
> > 	Name (_DEP, Package () { \_SB.GPO2 })
> > 
> > or similar. That is *explicit* dependency. Here \_SB.GPO2 is one of the
> > GPIO banks.
> 
> Either kernel knows on-the-fly or statically the required dependency.
> The static dependency is well described by Kconfig. An on-the-fly
> dependency could be a probe execution failing because it couldn't access
> part of required resources. If the dependency is temporarily not
> described this way, it would still be acceptable a documentation
> somewhere explaining that we do have this hidden thing going on.

The only thing kernel knows about this is when it finds that the
device in question has _DEP object. Once that happens and it evaluates
to a list of devices we depend on, we can defer this particular driver
going further in probe until all the dependencies listed in _DEP are
resolved.

The documentation you are after is ACPI 5.1 specification downloadable
freely at uefi.org/acpi.

> > > But IMHO all dependency to a driver should be explicitly described
> > > (e.g. on Kconfigs, or maybe failing probe). With current situation if we
> > > do not select pinctrl_baytrail, instead of affecting just the drivers
> > > that explicitly depend on that, it affects others which we are unable to
> > > easily identify.
> > 
> > So how do you propose we describe the dependency? It is completely in
> > firmware. Should we make i2c-hid.c dependent on pinctrl-baytrail.c just
> > because some underlying firmware method (_PSx for example) needs the
> > GPIO but the driver itself does not?
> 
> i2c-hid.c should fail, WARN, yell, scream or whatever :)
> This way one could say: hey, we needed GPIO.

But i2c-hid.c does not know anything about GPIOS in the first place.
Like I said the dependency is in the firmware level. It may need GPIOs
to do something or not but the driver never sees those GPIOs.
--
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/