On Wed, 2013-06-26 at 04:52 +0000, Matthew Garrett wrote: > On Tue, 2013-06-25 at 21:43 -0700, Darren Hart wrote: > > > 1) I need time, possibly a couple of months, to get proper ACPI support > > for these drivers into the firmware. Then I can rewrite these as ACPI > > drivers as is proper for an x86 board. I've already started down this > > path. > > A couple of months pushes you back one kernel release. It's not a huge > deal. I think I side with Olof here - the kernel developers have pushed > back against hardcoded and NIHed ARM device descriptors, and given that > we have a perfectly reasonable standard in the X86 world (ie, ACPI), I'm > not enthusiastic about merging something that's (a) going to be > superseded in the near future and (b) may end up serving as an example > to others who think this is ok. My biggest concern is fragmentation after the boards start to ship. I recognize this comes under the "lack of planning on your part doesn't constitute an emergency on my part" heading (although it really wasn't a lack of planning). Now that this is out here and people can see where it's going, if we choose to nack these and wait for a better implementation, that alone may accomplish the same goal. > Do these boards currently boot any other OSes? Currently the linux-yocto_3.8 standard/minnow Linux kernel is the only thing known to boot on it. This is what will ship with the device. > > See what happens when core kernel people are allowed to write driver > > code? How does this relate to converting this over to an ACPI device > > driver? I guess I would replace the above with > > MODULE_DEVICE_TABLE(acpi, ...) ? If I do the above.... is this still an > > evil board-file? What makes the acpi method of discover superior to > > setting up linux-hotplug via dmi? > > MODULE_DEVICE_TABLE is invisible to the running driver, it just exports > metadata that udev will use to decide whether to load the driver. If a > driver is intended to deal with a specific board, DMI makes sense. If > it's intended to deal with a specific ACPI device (ie, something with a > _HID that defines the programming model), ACPI makes sense. What are you referring to with "programming model" here? The three drivers in question: minnowboard.c minnowboard-gpio.c minnowboard-keys.c are all board-specific. They map GPIO to their fixed functions and provide an API for board-specific queries (minnowboard.c), they provide example uses (minnowboard-gpio and minnowboard-keys) which aid in experimentation and the development of new drivers. Which of these make sense as ACPI devices in your opinion? -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
