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 stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html