On Wed, Feb 4, 2015 at 11:11 PM, Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx> wrote: > On Wed, Feb 04, 2015 at 10:51:27AM +0100, Linus Walleij wrote: >> On Fri, Jan 30, 2015 at 5:17 PM, Rafael J. Wysocki <rjw@xxxxxxxxxxxxx> wrote: >> > On Friday, January 30, 2015 03:48:30 PM Linus Walleij wrote: >> >> >> So you could detect one by making a checksum of the binary or something. >> >> >> >> And then you'd know that the table with this checksum needs patching? >> > >> > At a single table level it is generally difficult to say whether or not >> > things are going to work. >> > >> > What needs to work is the namespace which is built from all of the tables >> > provided combined. So the namespace needs to be populated first and then >> > fixes applied on top of that (presumably by deleting, adding or replacing >> > objects). >> > >> > Now, in theory, you *may* be able to figure out that combination of tables >> > A produces namespace B which then will require fix X if the system is Y, >> > but quite frankly I wouldn't count on that. >> > >> > Moreover, fixups (or "patches" as I called them, but that wasn't exactly >> > correct) need to be provided in the form of AML definition blocks to apply on >> > top of an already populated namespace and if you want to use a binary kernel image, >> > you can't really afford putting all that stuff for all systems it can possibly >> > run on into it. This means that distros need to be able to combine a fixup for >> > the ACPI tables with the binary kernel and install the result into the system's >> > boot medium (whatever it is). Also it should be possible to update the fixup >> > and the kernel image separately if necessary. >> > >> > Now from the kernel's perspective that raises the question: "What if the >> > ACPI tables fixup provided by the distro is not sufficient?" >> > >> > That needs to be addressed somehow in the code. >> >> Yeah I guess I'm convinced that we need to handle this particular >> weirdness in the gpio-acpi code... if it can be contained there as >> expressed by Alexandre. > > I'm still fine if we want to confine this "gpio forwarding" to acpi > if you guys want it, but I was looking at the Sound SoC drivers and I > realised that we do have places which pass gpio descriptors to other > devices in platform data. And these of course aren't always used on > acpi platforms. By greping gpio_desc I saw at least these files are > passing it in platform data structures: > > include/sound/soc.h > include/linux/leds.h > include/linux/usb/usb_phy_generic.h > > There are probable others but I checked those. And of course now there > is nothing preventing people from adding more of them. For sound/soc.h, the member is indeed public but I don't see it being used to pass descriptors around between drivers. For linux/leds.h, I think this is the reason why we introduced devm_get_gpiod_from_child() These looks more like a bad usage of GPIO descriptors, but AFAICT they can be fixed by fixing the drivers and, by all means, this is where we should do it. This is a different situation from yours where we are trying to deal with broken firmware and need to resort to tricks at one point or the other. Or am I missing your point? -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html