Message ID | 20221010201453.77401-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
---|---|
Headers | show |
Series | pinctrl: Clean up and add missed headers | expand |
On Mon, Oct 10, 2022 at 10:15 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > than logical. This series is basically out of two parts: > - add missed headers to the pin control drivers / users > - clean up the headers of pin control subsystem > > The idea is to have this series to be pulled after -rc1 by the GPIO and > pin control subsystems, so all new drivers will utilize cleaned up headers > of the pin control. > > Please, review and comment. > > Changelog v2: > - added preparatory patches: all, but last (LKP) > - added missed forward declaration to the last patch (LKP) > Thanks for doing this. Did you use any kind of automation for detecting for which symbols the headers are missing? Bart
On Tue, Oct 11, 2022 at 09:10:07AM +0200, Bartosz Golaszewski wrote: > On Mon, Oct 10, 2022 at 10:15 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > > than logical. This series is basically out of two parts: > > - add missed headers to the pin control drivers / users > > - clean up the headers of pin control subsystem > > > > The idea is to have this series to be pulled after -rc1 by the GPIO and > > pin control subsystems, so all new drivers will utilize cleaned up headers > > of the pin control. > > > > Please, review and comment. > > > > Changelog v2: > > - added preparatory patches: all, but last (LKP) > > - added missed forward declaration to the last patch (LKP) > > Thanks for doing this. You're welcome! > Did you use any kind of automation for > detecting for which symbols the headers are missing? No, it's manual + what CI(s) reported back to me, that's why even in this series I have got a few compile breakages. I have very limited compile-testing cycle.
On 10/10/2022 1:14 PM, Andy Shevchenko wrote: > Currently the header inclusion inside the pinctrl headers seems more arbitrary > than logical. This series is basically out of two parts: > - add missed headers to the pin control drivers / users > - clean up the headers of pin control subsystem > > The idea is to have this series to be pulled after -rc1 by the GPIO and > pin control subsystems, so all new drivers will utilize cleaned up headers > of the pin control. > > Please, review and comment. Did you really need to split this on a per-driver basis as opposed to just a treewide drivers/pinctrl, drivers/media and drivers/gpiolib patch set? 36 patches seems needlessly high when 4 patches could have achieve the same outcome.
On Tue, Oct 11, 2022 at 11:56 PM Florian Fainelli <f.fainelli@gmail.com> wrote: > On 10/10/2022 1:14 PM, Andy Shevchenko wrote: > > Currently the header inclusion inside the pinctrl headers seems more arbitrary > > than logical. This series is basically out of two parts: > > - add missed headers to the pin control drivers / users > > - clean up the headers of pin control subsystem > > > > The idea is to have this series to be pulled after -rc1 by the GPIO and > > pin control subsystems, so all new drivers will utilize cleaned up headers > > of the pin control. > > > > Please, review and comment. > > Did you really need to split this on a per-driver basis as opposed to > just a treewide drivers/pinctrl, drivers/media and drivers/gpiolib patch > set? > > 36 patches seems needlessly high when 4 patches could have achieve the > same outcome. I can combine them if maintainers ask for that, nevertheless for Intel pin control and GPIO drivers, which I care more about, I would like to leave as separate changes (easy to see in history what was done).
On Mon, Oct 10, 2022 at 10:15 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > Currently the header inclusion inside the pinctrl headers seems more arbitrary > than logical. This series is basically out of two parts: > - add missed headers to the pin control drivers / users > - clean up the headers of pin control subsystem > > The idea is to have this series to be pulled after -rc1 by the GPIO and > pin control subsystems, so all new drivers will utilize cleaned up headers > of the pin control. Aha I see you want to send a pull request so I backed out the applied patches from the series for now. Yours, Linus Walleij