[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