On 05/01/2015 12:56 PM, Timur Tabi wrote:
On 05/01/2015 02:24 PM, Arnd Bergmann wrote:
No, that is not a reasonable assumption to make. All the ARM64 server
systems we have today are using DT only and we will of course keep
supporting systems like that.
This is what drives me crazy about Linux kernel development. I've been doing this for 15 years, and I still get random emails that contradict everything I've been told to date.
I was repeatedly told over the past year by multiple people that ARM64 server == ACPI, no ifs, ands, or buts.
I don't think anyone ever claimed that Linux development is free
of politics. Except for master politicians, of course.
This means we need a DT binding for the driver, and the ACPI portion
that creates the platform device should be split out from the main
driver.
Well, someone who actually has a DT-based ARM64 server system (which is not me) should come up with such a definition.
I'm hoping that my driver can be accepted without DT support, and that someone else who is interested in running my driver on an SBSA device tree platform can add what's missing.
I am perfectly fine with that. All I am asking for is flexibility on your part.
Even if you (and/or others) may personally believe that ACPI _is_ the
center of the universe, please be open to the possibility that others
may have a different opinion and/or different requirements. We should not
have to completely rewrite the driver to add devicetree support later on.
Note we still have to figure out how to instantiate the device based on
the acpi data. I have no idea how that should be done, but it seems
odd if it is really supposed to be done as you have implemented it.
Maybe that is the case, but if so I would like to get a confirmation
from an acpi maintainer.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
