On Mon, Feb 5, 2018 at 8:08 PM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Mon, Feb 05, 2018 at 08:02:40PM +0100, Linus Walleij wrote: >> On Mon, Feb 5, 2018 at 6:59 PM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: >> >> > Anyway, I think going with the pinctrl/devinfo.h include only is fine >> > for now. If it turns out that the Mediatek ethernet and Rockchip LVDS >> > drivers can just omit the bits fiddling with struct dev_pin_info, we can >> > swap out the pinctrl/devinfo.h include for pinctrl/consumer.h at that >> > time. >> > >> > LinusW: what are your thoughts on the struct dev_pin_info usage by these >> > drivers? Does their code seem redundant to you, too? >> >> I don't think they should use struct dev_pin_info at all, >> that thing is for the device core only. >> >> I like to think that <linux/pinctrl/consumer.h> is for drivers that >> explicitly grab and control pin control states so this driver should >> only include <linux/pinctrl/consumer.h>. >> >> Torvalds: can you do it like that instead? Either way will >> make the compile work again, we can also tidy it up later. >> (i.e. I will grep for includes of pinctrl/dev_info.h and replace >> it with consumer.h) at some point. > > That won't work, unfortunately, because these drivers actually try to > dereference pointers to struct dev_pin_info and hence need that include > for the structure's definition. Those are the only two drivers I can see > that access this structure directly (other than the device core). Grrr OK I thought I was aiming for encapsulation here but then what can I do, sigh. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
