On Tue, Nov 04, 2014 at 10:05:26AM -0800, David Cohen wrote:
> On Tue, Nov 04, 2014 at 09:59:36AM +0200, Mika Westerberg wrote:
> > On Mon, Nov 03, 2014 at 02:19:03PM -0800, David Cohen wrote:
> > > Hi Mika,
> > >
> > > Thanks for your feedbacks :)
> > >
> > > On Mon, Nov 03, 2014 at 08:42:47PM +0200, Mika Westerberg wrote:
> > > > On Mon, Nov 03, 2014 at 09:50:11AM -0600, Felipe Balbi wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, Nov 03, 2014 at 05:42:07PM +0200, Mika Westerberg wrote:
> > > > > > On Mon, Nov 03, 2014 at 05:27:43PM +0200, Mika Westerberg wrote:
> > > > > > > On Mon, Nov 03, 2014 at 09:00:48AM -0600, Felipe Balbi wrote:
> > > > > > > > On Mon, Nov 03, 2014 at 11:24:02AM +0200, Mika Westerberg wrote:
> > > > > > > > > On Fri, Oct 31, 2014 at 11:45:09AM -0700, David Cohen wrote:
> > > > > > > > > > > I think adding the module exit + allowing this driver to
> > > > > > > > > > > be a module
> > > > > > > > > > > would be a good approach. Then we don't need to force
> > > > > > > > > > > generic x86 kernel
> > > > > > > > > > > binaries to always have this driver. Unless Mathias or
> > > > > > > > > > > Mika knows a
> > > > > > > > > > > constraint to force this driver to be builtin only.
> > > > > > > > > >
> > > > > > > > > > It helps if I CC them when asking for feedback :)
> > > > > > > > > >
> > > > > > > > > > Mathias, Mika, do you know any constraint that forces
> > > > > > > > > > pinctrl-baytrail
> > > > > > > > > > to be bool?
> > > > > > > > >
> > > > > > > > > The only constraint that has been keeping this driver as bool
> > > > > > > > > is that
> > > > > > > > > some machines like, Asus T100, uses ACPI GPIO operation
> > > > > > > > > regions for
> > > > > > > > > toggling GPIOs to get things like sensor hub powered on. The
> > > > > > > > > GPIO
> > > > > > > > > operation region code does not yet handle -EPROBE_DEFER so
> > > > > > > > > only way to
> > > > > > > > > ensure that the operation region is there is to have the
> > > > > > > > > driver compiled
> > > > > > > > > in to the kernel.
> > > > > > > >
> > > > > > > > But that's not enough excuse to have every single x86 in the
> > > > > > > > market
> > > > > > > > shipping with this driver. Think about a distro kernel, most
> > > > > > > > likely this
> > > > > > > > gets enabled and it's wrong in 80% of the cases.
> > > > > > >
> > > > > > > True, but see below.
> > > > > > >
> > > > > > > > It would be nicer to add EPROBE_DEFER support, convert this into
> > > > > > > > tristate and have default = M if BAYTRAIL, or something.
> > > > > > >
> > > > > > > If it were simple as that we would have done that already. Please
> > > > > > > check
> > > > > > > drivers/gpio/gpiolib-acpi.c:acpi_gpio_adr_space_handler() and
> > > > > > > tell me
> > > > > > > how we can do that.
> > > > > >
> > > > > > Actually the above is not the problem because we already have
> > > > > > registered
> > > > > > the GPIO chip and hence we have the GPIO available to the firmware
> > > > > > code.
> > > > >
> > > > > what happens before you registered the gpio chip ? It takes some time
> > > > > from head.S to gpiochip_irqchip_add(). Anywhere between that time,
> > > > > firmware could try to access gpios and the same problem would occur.
> > > >
> > > > The operation region is not ready and the firmware does not try to use
> > > > it. However, the subsys_initcall() is there just to be sure that the
> > > > GPIO driver gets loaded before anything that is going to use GPIOs from
> > > > firmware.
> > >
> > > That sounds hackish and dangerous. There are shared registers between
> > > different GPIOs.
> >
> > For one it certainly is not hackish and dangerous. It is well defined
> > in the ACPI specification as interfaces between firmware and OS.
>
> It looks we have an implicit dependency to GPIO driver in Bay Trail, and
> having this window until load the module is not acceptable to fulfill
> this implicit dependency.
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.
> 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?
> Maybe I don't like or fully agreee/understand ACPI, but I'd call that
> dangerous.
>
> >
> > > > > > The real problem is that if the ACPI GPIO operation handler is not
> > > > > > there
> > > > > > at the time firmware decides to do something it will just skip
> > > > > > things
> > > > > > that depend on the operation region. So if it has a GPIO that is
> > > > > > used to
> > > > > > turn on sensor hub or touch panel or whatever, this will not be
> > > > > > done and
> > > > > > it results that the device in question might not work properly.
> > > > >
> > > > > 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.
> > >
> > > Hm.... it sounds like we're saying: we got it working somehow and from
> > > now on we'll avoid change it to not create regression.
> >
> > That's exactly what I'm saying :-)
>
> In this case, I think we need to carefully document our concerns about
> the driver to help others not involved in original implementation to
> easily contribute to it.
>
> >
> > > Correct if I'm wrong, but there's nothing really preventing this driver
> > > to be a module beside the buggy ACPI interface that allows kernel and fw
> > > to play freely (and silently) with same piece of hw.
> >
> > Not a buggy ACPI interface. Lack of implementation from Linux side.
> >
> > > IMHO we could allow this driver be M, but default to Y and an
> > > explanation to set to Y in case FW needs to use GPIO before module gets
> > > loaded. Since we've development board (Minnow Max), we should let kernel
> > > more free for other developers as well.
> >
> > All I'm saying both to you guys that this is the reasoning we have the
> > driver as a bool. Which is what you asked from me in the first place.
>
> I apology for my frustration :)
> You've been more than helpful clarifying our questions.
>
> >
> > Since you both insist to turn it module, please send a patch with the
> > corresponding changelog telling why you think it does not need to build
> > in and let's see if we are getting any regressions. If yes, then we just
> > revert the patch. Does that work for you?
>
> I'm in favor of not hardcoding kernel features based on possible hidden
> things that may happen on closed source FWs.
> Having the module option does help further development of this driver
> and others that depend on it. A clear explanation on Kconfig why we
> recommend Y for production and why M is still experimental should be
> enough to guide ppl working on distributions and at same time help
> kernel developers involved with the driver.
Like I said, send a patch describing why you think it needs to be module
and make it tristate instead. If it causes problems we can revert it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
