[Ksummit-2013-discuss] [ATTEND] ACPI vs DT

Guenter Roeck linux at roeck-us.net
Tue Jul 30 08:19:13 UTC 2013


On 07/27/2013 03:33 AM, Simon Guinot wrote:
> On Sat, Jul 27, 2013 at 01:49:27AM -0500, linux at roeck-us.net wrote:
>> Quoting "Rafael J. Wysocki" <rjw at sisk.pl>:
>>
>>> On Thursday, July 25, 2013 10:16:28 AM Linus Walleij wrote:
>>>> On Thu, Jul 25, 2013 at 1:05 AM, Rafael J. Wysocki <rjw at sisk.pl> wrote:
>>>>
>>>>> If you want a platform device to be created automatically for
>>>> an object with
>>>>> a particular PNP ID, add that PNP ID to acpi_platform_device_ids[] in
>>>>> drivers/acpi/acpi_platform.c.  Then, you'll be able to match
>>>> your driver to
>>>>> that platform device using acpi_match_table, as described in
>>>>> Documentation/acpi/enumeration.txt.
>>>>>
>>>>> Of course, that's going to work only if the ACPI namespace
>>>> contains an object
>>>>> with that PNP ID.  Now, you can ask me "What to do if it
>>>> doesn't?" and that's
>>>>> a good question.
>>>>
>>>> Hm this fits well into the topic of the thread.
>>>>
>>>> Atleast it seems like ACPI+ioport detection should be possible to
>>>> combine in the same driver, so that if no PNP ID is found through
>>>> ACPI, it can fall back to the ioport probing.
>>>
>>> Yes, that's viable in my opinion.
>>>
>> Sounds reasonable. I'll play with that and see if I can get it
>> working on any of the boards I have access to.
>
> At least on my boards, I am almost sure that the ACPI namespace doesn't
> contain any ID related with the super-I/O. At the time this boards has
> been developed, LaCie (the board vendor) didn't do anything to add a
> such ID.
>
That is one of my concerns. Another is that - at least to my knowledge
- ACPI bindings may not be as well defined as, for example, PCI IDs or
devicetree properties. Or maybe they are, and I just don't know where to 
find the necessary information.

> However, I will spend some time the next week to double-check that. And
> I will also try to make coexist ACPI and ioport detection inside the
> gpio-f7188x driver.
>
Another concern is that your driver is not synchronized with the hwmon 
driver and the watchdog driver for the same chip. The hwmon driver only 
uses superio access during initialization, so it is probably not that 
critical. The watchdog driver, however, uses superio accesses for its 
keepalive function. As far as I can see, you did not implement any 
synchronization (eg by using request_muxed_region before enabling 
superio accesses), which may result in the two drivers stepping on each 
other's foot.

Guenter



More information about the Ksummit-2013-discuss mailing list