From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Hans de Goede <hdegoede@redhat.com>
Subject: Re: [RESEND][PATCH v2 0/7] gpiolib: fix GPIO <-> pin mapping registration
Date: Wed, 13 Nov 2019 15:28:22 +0200 [thread overview]
Message-ID: <20191113132822.GF32742@smile.fi.intel.com> (raw)
In-Reply-To: <CACRpkdZWh7MD+psE9zndg4S59Eq-PRcmgrs-ABUaTGHnm7S4Sw@mail.gmail.com>
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)
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2019-11-13 13:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-05 20:35 [RESEND][PATCH v2 0/7] gpiolib: fix GPIO <-> pin mapping registration Andy Shevchenko
2019-11-05 20:35 ` [PATCH v2 1/7] gpiolib: Switch order of valid mask and hw init Andy Shevchenko
2019-11-05 20:35 ` [PATCH v2 2/7] gpiolib: No need to call gpiochip_remove_pin_ranges() twice Andy Shevchenko
2019-11-05 20:35 ` [PATCH v2 3/7] gpiolib: Introduce ->add_pin_ranges() callback Andy Shevchenko
2019-11-06 13:51 ` Mika Westerberg
2019-11-13 9:46 ` Linus Walleij
2019-11-13 13:22 ` Andy Shevchenko
2019-11-13 17:25 ` Linus Walleij
2019-11-13 17:47 ` Andy Shevchenko
2019-11-05 20:35 ` [PATCH v2 4/7] gpio: merrifield: Add GPIO <-> pin mapping ranges via callback Andy Shevchenko
2019-11-06 13:54 ` Mika Westerberg
2019-11-06 16:52 ` Andy Shevchenko
2019-11-05 20:35 ` [PATCH v2 5/7] gpio: merrifield: Pass irqchip when adding gpiochip Andy Shevchenko
2019-11-06 13:56 ` Mika Westerberg
2019-11-05 20:35 ` [PATCH v2 6/7] pinctrl: baytrail: Add GPIO <-> pin mapping ranges via callback Andy Shevchenko
2019-11-06 13:56 ` Mika Westerberg
2019-11-05 20:35 ` [PATCH v2 7/7] pinctrl: baytrail: Pass irqchip when adding gpiochip Andy Shevchenko
2019-11-06 14:00 ` Mika Westerberg
2019-11-06 11:59 ` [RESEND][PATCH v2 0/7] gpiolib: fix GPIO <-> pin mapping registration Hans de Goede
2019-11-06 17:30 ` Andy Shevchenko
2019-11-08 9:40 ` Linus Walleij
2019-11-08 13:39 ` Andy Shevchenko
2019-11-13 9:43 ` Linus Walleij
2019-11-13 13:28 ` Andy Shevchenko [this message]
2019-11-13 13:37 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191113132822.GF32742@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=bgolaszewski@baylibre.com \
--cc=hdegoede@redhat.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.