On Thu, Jun 1, 2017 at 5:29 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Thu, Jun 1, 2017 at 5:20 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > >>> So again, the reason this - which is not a GPIO controller at all - >>> should anyways >>> be in drivers/gpio/ is that some firmware person think it's convenien > >>> Shouldn't this rather be in drivers/platform/x86? >> >> >> That is where it started, I'm fine with putting it back there. >> >>> You can still use the gpio driver abstraction. >> >> Ack, if you're ok with using the gpio driver abstraction while >> putting the driver in drivers/platform/x86 that might be the >> best way to deal with this. > > OK let's proceed like that. Cool. Well, I actually overlooked the "virtual" part somehow, sorry about that. Yes, it totally should be platform/x86. > I guess I could be hopeless and require that it reimplement > the ACPI parser and whatnot just because it's not GPIO but > code duplication is a greater evil and thus modelling this as a > "GPIO" is the lesser evil, so I just have to accept it as such. Thanks for looking into this! Cheers, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
