On 19 August 2014 19:06, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Tue, Aug 19, 2014 at 2:19 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >> On 18 August 2014 19:13, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > >>> Or maybe even do the second approach of putting stubs in slot-gpio.h >>> for !GPIOLIB... >> >> Hmm, that doesn't sound the proper solution either. >> >> Currently there are already stubs for the "gpiod" API in >> gpio/consumer.h. I think the original error was that the "GPIOD_IN" >> flag couldn't be found for !GPIOLIB. >> So, how about actually move these flags and it's corresponding defines >> to be available for !GPIOLIB as well. That should solve this problem >> for other subsytems using gpiod API as well, right? > > Yeah you're right, I've sent such a patch now, I will queue this for > fixes so we can rely on it in the development trees. Great! Please keep me on cc on the PR to easier follow the progress. > > But I still think it's kind of awkward that slot-gpio is compiled into > the MMC core even if GPIOLIB is not available on the machine :-/ > it simply doesn't make much sense, since it never will add anything. Actually there a bit of mix for how such situations are handled in the mmc subsystem. For example, we have stubs for the mmc regulator functions (mmc_regulator_get_ocrmask() and mmc_regulator_set_ocr()), but we don't for DT parsing (mmc_of_parse()) and for slot-gpio. Implementation wise, I would prefer to not have stubs unless it's explicitly needed. Still one may argue that a built kernel binary should have the smallest possible footprint, which means stubs should be added. Do you know if there are common understanding among maintainers of how this should be done? Kind regards Uffe > But this path should get us to the situation where everything > just compiles nicely atleast. I will try it on zeroday builds. > > Yours, > Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
