| Message ID | 20191105203557.78562-1-andriy.shevchenko@linux.intel.com |
|---|---|
| Headers | show |
| Series | gpiolib: fix GPIO <-> pin mapping registration | expand |
Hi, On 05-11-2019 21:35, Andy Shevchenko wrote: > This is the ordering fix for GPIO <-> pin mapping registration to allow > delegation of IRQ chip to the GPIO library. Two drivers are actually converted > to use the new callback followed by switching to use of irqchip structure > inside gpiochip. > > The series has been tested on Merrifield device (though no AEI) and on Thinkpad > 10 where 4 events are registered, one of which has reasonable amount of > interrupts coming from battery. > > First two patches are definitely good for v5.4 cycle (and have Fixes tag) while > the rest can be applied for v5.5 if I didn't miss anything. So, they can go like > patches 1-3 -> v5.4 (gpio/fixes) and to gpio/for-next and to pinctrl/for-next > patches 4-5 -> v5.5 (gpio/for-next) > patches 6-7 -> v5.5 (pinctrl/for-next) > > Perhaps it would require to wait next v5.4 rc in order to avoid dependency > issues. Given were we ar ein the cycle I think it is probably best to merge everything for 5.5, but that is not my call. I've given this a test run on a BYT device, and it works for me, So patches 1-3 and 6-7 are: Tested-by: Hans de Goede <hdegoede@redhat.com> I've also reviewed all the patch and the entire set (so 1-7) looks good to me: Reviewed-by: Hans de Goede <hdegoede@redhat.com> One related remark, I notice that the following patches which were in -next for a bit and where then dropped because this needed more work are missing from this set: "pinctrl: baytrail: Allocate IRQ chip dynamic" "pinctrl: baytrail: Group GPIO IRQ chip initialization" "pinctrl: baytrail: Move IRQ valid mask initialization to a dedicated callback" IMHO it would be good to get these landed too (could be done in a follow up series I guess). I've also prepared and tested a set of patches on top of this one to also "Pass irqchip when adding gpiochip" for CHT, I will post these right after this email. Regards, Hans > > Changelog v2 (resent): > - fixed cover letter > - resent with ML included > > Changelog v2: > - added fixes tag to the first patch > - reworked commit message for the second patch > - added baytrail conversion > - tested on ThinkPad 10 > > Andy Shevchenko (6): > gpiolib: No need to call gpiochip_remove_pin_ranges() twice > gpiolib: Introduce ->add_pin_ranges() callback > gpio: merrifield: Add GPIO <-> pin mapping ranges via callback > gpio: merrifield: Pass irqchip when adding gpiochip > pinctrl: baytrail: Add GPIO <-> pin mapping ranges via callback > pinctrl: baytrail: Pass irqchip when adding gpiochip > > Linus Walleij (1): > gpiolib: Switch order of valid mask and hw init > > drivers/gpio/gpio-merrifield.c | 76 ++++++++++++++---------- > drivers/gpio/gpiolib-of.c | 5 +- > drivers/gpio/gpiolib.c | 19 +++++- > drivers/pinctrl/intel/pinctrl-baytrail.c | 64 ++++++++++++-------- > include/linux/gpio/driver.h | 5 ++ > 5 files changed, 107 insertions(+), 62 deletions(-) >
On Tue, Nov 05, 2019 at 10:35:50PM +0200, Andy Shevchenko wrote: > This is the ordering fix for GPIO <-> pin mapping registration to allow > delegation of IRQ chip to the GPIO library. Two drivers are actually converted > to use the new callback followed by switching to use of irqchip structure > inside gpiochip. > > The series has been tested on Merrifield device (though no AEI) and on Thinkpad > 10 where 4 events are registered, one of which has reasonable amount of > interrupts coming from battery. > > First two patches are definitely good for v5.4 cycle (and have Fixes tag) while > the rest can be applied for v5.5 if I didn't miss anything. So, they can go like > patches 1-3 -> v5.4 (gpio/fixes) and to gpio/for-next and to pinctrl/for-next > patches 4-5 -> v5.5 (gpio/for-next) > patches 6-7 -> v5.5 (pinctrl/for-next) > > Perhaps it would require to wait next v5.4 rc in order to avoid dependency > issues. So, I consolidated everything I have under my review-andy branch in pinctrl/intel.git repository. When I applied Hans' CHV series, I fixed minor conflict due to new small patch in for-next branch. Linus, I think it would be good if we have first 3 (okay, I noticed you have pushed first one to your devel branch) patches to go to v5.4. It will reduce dependency burden in v5.5. Hans, if you have time you can test altogether (actually that set I used for local testing, so, I'm not expecting anything unusual there). > Changelog v2 (resent): > - fixed cover letter > - resent with ML included > > Changelog v2: > - added fixes tag to the first patch > - reworked commit message for the second patch > - added baytrail conversion > - tested on ThinkPad 10 > > Andy Shevchenko (6): > gpiolib: No need to call gpiochip_remove_pin_ranges() twice > gpiolib: Introduce ->add_pin_ranges() callback > gpio: merrifield: Add GPIO <-> pin mapping ranges via callback > gpio: merrifield: Pass irqchip when adding gpiochip > pinctrl: baytrail: Add GPIO <-> pin mapping ranges via callback > pinctrl: baytrail: Pass irqchip when adding gpiochip > > Linus Walleij (1): > gpiolib: Switch order of valid mask and hw init > > drivers/gpio/gpio-merrifield.c | 76 ++++++++++++++---------- > drivers/gpio/gpiolib-of.c | 5 +- > drivers/gpio/gpiolib.c | 19 +++++- > drivers/pinctrl/intel/pinctrl-baytrail.c | 64 ++++++++++++-------- > include/linux/gpio/driver.h | 5 ++ > 5 files changed, 107 insertions(+), 62 deletions(-) > > -- > 2.24.0.rc1 >
On Wed, Nov 6, 2019 at 6:30 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > Linus, I think it would be good if we have first 3 (okay, I noticed you have > pushed first one to your devel branch) patches to go to v5.4. It will reduce > dependency burden in v5.5. At this point in the kernel release cycle I can really only apply patches for serious regressions. That's the policy I need to keep to. It also causes a problem if I put dependencies on Torvald's tree this late in the kernel cycle, because I need to get the changes back into my tree in order to base new stuff on them. I can't really do that until he releases an -rc that I can merge back. At this point I'd maybe have to merge back v5.4 and that doesn't feel good at all. So far I applied patches 1 & 2 for v5.5. Yours, Linus Walleij
On Fri, Nov 08, 2019 at 10:40:47AM +0100, Linus Walleij wrote: > On Wed, Nov 6, 2019 at 6:30 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > Linus, I think it would be good if we have first 3 (okay, I noticed you have > > pushed first one to your devel branch) patches to go to v5.4. It will reduce > > dependency burden in v5.5. > > At this point in the kernel release cycle I can really only apply > patches for serious regressions. That's the policy I need to keep > to. > > It also causes a problem if I put dependencies on Torvald's > tree this late in the kernel cycle, because I need to get the > changes back into my tree in order to base new stuff on them. > I can't really do that until he releases an -rc that I can merge > back. > > At this point I'd maybe have to merge back v5.4 and that doesn't > feel good at all. > > So far I applied patches 1 & 2 for v5.5. Thanks! Does it mean that the rest is material for v5.6?
On Fri, Nov 8, 2019 at 2:39 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Fri, Nov 08, 2019 at 10:40:47AM +0100, Linus Walleij wrote: > > On Wed, Nov 6, 2019 at 6:30 PM Andy Shevchenko > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > Linus, I think it would be good if we have first 3 (okay, I noticed you have > > > pushed first one to your devel branch) patches to go to v5.4. It will reduce > > > dependency burden in v5.5. > > > > At this point in the kernel release cycle I can really only apply > > patches for serious regressions. That's the policy I need to keep > > to. > > > > It also causes a problem if I put dependencies on Torvald's > > tree this late in the kernel cycle, because I need to get the > > changes back into my tree in order to base new stuff on them. > > I can't really do that until he releases an -rc that I can merge > > back. > > > > At this point I'd maybe have to merge back v5.4 and that doesn't > > feel good at all. > > > > So far I applied patches 1 & 2 for v5.5. > > Thanks! Does it mean that the rest is material for v5.6? No, if they work for you and Hans both I have 100% trust in you guys so just send me a big pull request for all of it for v5.5. Besides Torvalds is talking about an -rc8 this next weekend. Please base your pull request on my "devel" branch though, since I already applied some of the patches (sorry for the mess!) We can certainly hash out any remaining nits during the v5.5 kernel cycle. Yours, Linus Walleij
On Wed, Nov 13, 2019 at 10:43:28AM +0100, Linus Walleij wrote: > On Fri, Nov 8, 2019 at 2:39 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Fri, Nov 08, 2019 at 10:40:47AM +0100, Linus Walleij wrote: > > > On Wed, Nov 6, 2019 at 6:30 PM Andy Shevchenko > > > <andriy.shevchenko@linux.intel.com> wrote: > > > > > > > Linus, I think it would be good if we have first 3 (okay, I noticed you have > > > > pushed first one to your devel branch) patches to go to v5.4. It will reduce > > > > dependency burden in v5.5. > > > > > > At this point in the kernel release cycle I can really only apply > > > patches for serious regressions. That's the policy I need to keep > > > to. > > > > > > It also causes a problem if I put dependencies on Torvald's > > > tree this late in the kernel cycle, because I need to get the > > > changes back into my tree in order to base new stuff on them. > > > I can't really do that until he releases an -rc that I can merge > > > back. > > > > > > At this point I'd maybe have to merge back v5.4 and that doesn't > > > feel good at all. > > > > > > So far I applied patches 1 & 2 for v5.5. > > > > Thanks! Does it mean that the rest is material for v5.6? > > No, if they work for you and Hans both I have 100% trust in you > guys so just send me a big pull request for all of it for v5.5. > Besides Torvalds is talking about an -rc8 this next weekend. > > Please base your pull request on my "devel" branch though, I think you meant for-next, which contains reverts my series based on. > since I already applied some of the patches (sorry for the mess!) > We can certainly hash out any remaining nits during the v5.5 > kernel cycle. As I explained in previous mail we have the current state: - gpiolib patch + merrifield fixes (may be submitted as PR for v5.5) - Intel pin control (for-next is going as usual for v5.5) - Intel pin control fixes based on gpiolib patch (for v5.6) - Lynxpoint as separate PR (didn't check for which tree it suits better, I guess due to nature of patches, it rather pin control, but we can wait with it till v5.6)
Linus, okay, first three patches had been send as PR against gpio/for-next for v5.5.