On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote: > I don't know that there *is* a coherent plan here to address it all. > > Certainly, we *will* need subsystems to have firmware-specific > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to > describe GPIO, and properties which reference GPIO pins are intended to > work through that — while in DT, properties which reference GPIO pins > will have different contents. They'll be compatible at the driver > level, in the sense that there's a call to get a given GPIO given the > property name, but the subsystems *will* be doing different things > behind the scenes. It's a bit ironic that you've chosen GPIO as an example there. The "new" GPIO API (the gpiod_* stuff) only has a fwnode way to get the gpio descriptor. There's no of_* method. I'd like to use the gpiod_* stuff, but I feel that my options are rather limited: either use fwnode_get_named_gpiod() with &dev->of_node->fwnode, which seems like a hack by going underneath the covers of how fwnode is (partially) implemented with DT, or by using of_get_named_gpio() and the converting the gpio number to a descriptor via gpio_to_desc(). Both feel very hacky. If ACPI already handles GPIOs internally, then I'm left wondering why GPIO descriptor stuff went down the fwnode route at all - it seems rather pointless in this case, and it seems to make the use of the gpiod* interfaces where we _do_ need to use it (DT) harder and more hacky. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
