[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZSZzsfaunP5yRvZ4@smile.fi.intel.com>
Date: Wed, 11 Oct 2023 13:06:41 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
Dipen Patel <dipenp@...dia.com>, linux-gpio@...r.kernel.org,
linux-kernel@...r.kernel.org, timestamp@...ts.linux.dev,
linux-tegra@...r.kernel.org,
Linus Walleij <linus.walleij@...aro.org>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>
Subject: Re: [PATCH v1 0/4] hte: Improve GPIO handling and other cleanups
On Wed, Oct 11, 2023 at 11:33:51AM +0200, Bartosz Golaszewski wrote:
> On Tue, Oct 10, 2023 at 5:18 PM Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com> wrote:
> >
> > This is a series provides a new API to GPIO library (so far only
> > available in the GPIO tree), and respective update to the Tegra
> > HTE driver. On top a couple of other cleaups (patches 3 & 4, they
> > can be applied separately).
> >
> > Patch 2 inherited tags from its respective discussion thread [1],
> > but I believe the Tested-by needs to be confirmed again.
> >
> > Due to dependencies this either should be applied to the GPIO tree,
> > or to the HTE when GPIO updates land the upstream (optionally with
> > the first patch be applied even now to the GPIO tree independently).
> >
> > Another option is to have an immutable branch or tag, but I assume
> > that was discussed and rejected (?) in [1].
>
> The series looks good to me. I'd like to take patches 1 and 2 through
> the GPIO tree once v2 is out. This way we could potentially remove
> gpiochip_find() for v6.7 already.
It would be nice to see it being removed sooner than later!
I'm waiting for the test results by Dipen, I'll send the v2
ASAP if tests pass.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists