On Mon, May 4, 2015 at 1:36 PM, Antonio Ospite <ao2@xxxxxx> wrote: > On Mon, 4 May 2015 13:40:00 +0300 Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: >> Well, if you happen to have another GPIO chip (a GPIO expander for >> example) and it somehow gets loaded before this driver. It may take the >> range you have reserved for the BYT driver. >> >> Not sure how realistic case that is, though... > > Indeed, being this for the SoC gpio controller I thought it was > unlikely, however I do not have a huge experience on these matters. > > I have no strong opinion on this, Mika, so whether or not you merge the > change it'll be fine by me. The ability to set .base is basically there for legacy reasons, and the critical legacy case is usually when setting it to 0 for the on-SoC GPIO. In the long run we want to get rid of static GPIO numbers altogether so I prefer if you construct your userspace to traverse sysfs to get the GPIOs you need to get at, sysfs is horrible and unreliable for GPIO. Yours, Linus Walleij -- 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