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@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
