lkml.org 
[lkml]   [2017]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] ACPI / GED: use late init to allow other drivers init
    Date
    On Thursday, April 27, 2017 10:32:07 PM Sinan Kaya wrote:
    > On 4/25/2017 12:24 PM, Sinan Kaya wrote:
    > > On 4/25/2017 3:01 AM, Lukas Wunner wrote:
    > >> On Sat, Apr 22, 2017 at 12:48 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
    > >>> On 4/21/2017 6:43 PM, Rafael J. Wysocki wrote:
    > >>>> +late_initcall(ged_init);
    > >>>> Does this fix the problem?
    > >>>>
    > >>>> What about if the module in question is loaded after running
    > >>>> late_initcalls?
    > >>>
    > >>> This fixed the issue for me where I had dependencies for QUP I2C driver
    > >>> and GHES drivers. Both of them are modules and get probed via normal
    > >>> module execution path.
    > >>>
    > >>> However, I'm open to improvements. Do you have a better suggestion?
    > >>> I can try to add some _DEP stuff if it is present, but I remember Linux
    > >>> doesn't like _DEP stuff too much.
    > >>
    > >> Would it be possible to solve this by just returning -EPROBE_DEFER from the
    > >> ->probe hook if the devices you depend on are not bound yet?
    > >>
    > >
    > > I'm not sure.
    > >
    > >> Alternatively, would it be possible to solve it with a struct device_link?
    > >
    > > I wasn't aware of device_link concept. This is something that I will keep in
    > > my mind when I'm dealing with producer/consumer problems with known device
    > > driver instances. It looked very useful.
    > >
    > > Here is how the overall relationship between drivers.
    > >
    > > | GED | <---> | Platform specific ACPI AML | <----> Vendor GPIO
    > > <----> Vendor I2C
    > > <----> ACPI GHES
    > > <----> Some other driver
    > >
    > > The problem with Generic Event Device (GED) is that it produces event
    > > notification facility to the platform specific AML code and GED doesn't
    > > have any idea about the consumers of these interrupts or what platform AML
    > > does.
    > >
    > > GED only sees the interrupts that it needs to register and
    > > knows the ASL code it needs to execute when that interrupt happens.
    > >
    > > It is possible for AML code not to use any of these drivers or require
    > > some arbitrary driver as well as vendor specific drivers. It is totally
    > > up to the firmware to decide what to do with this event.
    > >
    > > My proposal was to require platform AML code to indicate the dependencies
    > > between GED and drivers on the right side of the picture via _DEP as this
    > > cannot be done via normal kernel mechanisms.
    > >
    > > This approach might work in general. However, it also has its own caveats.
    > >
    > > All of these drivers on the right side are unrelated to each other. Some
    > > operating system can implement a subset of these drivers.
    > >
    > > If I include the dependencies, GED will never load for partial driver situations.
    > > This is also a deal breaker.
    > >
    > > Why would you break some other feature if your OS doesn't support RAS as an
    > > example?
    > >
    > > Given all these lose bindings and no driver association, where do we go
    > > from here?
    > >
    > > I consider GED as a light version of Embedded controller (EC) implementation.
    > >
    > > How is this problem solved for EC as it has the same problem?
    > >
    >
    > This recommendation came from Timur. I wanted to see how everybody feels about it.
    >
    > When GED driver makes an AML call and the driver on the right side of the picture
    > is not present, GED driver gets an ACPI error return code.

    This means that _EVT evaluation failed, right?

    How does the _EVT in question look like? What does make it depend on the
    other drivers to be present in particular?

    Thanks,
    Rafael

    \
     
     \ /
      Last update: 2017-05-11 03:05    [W:5.643 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site