[GIT PULL] intel-gpio for 5.11-1

[GIT PULL] intel-gpio for 5.11-1

[Andy Shevchenko]

Hi Linux GPIO  maintainers,

ACPI GPIO library refactoring. It's based on recent gpio/for-next.

Thanks,

With Best Regards,
Andy Shevchenko

The following changes since commit b72de3ff19fdc4bbe4d4bb3f4483c7e46e00bac3:

  gpio: sifive: Fix SiFive gpio probe (2020-11-11 09:53:09 +0100)

are available in the Git repository at:

  git@gitolite.kernel.org:pub/scm/linux/kernel/git/andy/linux-gpio-intel.git tags/intel-gpio-v5.11-1

for you to fetch changes up to e709a7b5a066362b697d65dda90edc71f913df70:

  gpiolib: acpi: Make Intel GPIO tree official for GPIO ACPI work (2020-11-16 14:14:35 +0200)

----------------------------------------------------------------
intel-gpio for v5.11-1

* Refactor GPIO library to support bias and debounce ACPI settings

The following is an automated git shortlog grouped by driver:

gpiolib:
 -  acpi: Make Intel GPIO tree official for GPIO ACPI work
 -  acpi: Use BIT() macro to increase readability
 -  acpi: Convert pin_index to be u16
 -  acpi: Extract acpi_request_own_gpiod() helper
 -  acpi: Make acpi_gpio_to_gpiod_flags() usable for GpioInt()
 -  acpi: Set initial value for output pin based on bias and polarity
 -  acpi: Move acpi_gpio_to_gpiod_flags() upper in the code
 -  acpi: Move non-critical code outside of critical section
 -  acpi: Take into account debounce settings
 -  acpi: Use named item for enum gpiod_flags variable
 -  acpi: Respect bias settings for GpioInt() resource
 -  Introduce gpio_set_debounce_timeout() for internal use
 -  Extract gpio_set_config_with_argument_optional() helper
 -  move bias related code from gpio_set_config() to gpio_set_bias()
 -  Extract gpio_set_config_with_argument() for future use
 -  use proper API to pack pin configuration parameters
 -  add missed break statement
 -  Replace unsigned by unsigned int

Merge tag 'intel-pinctrl-v5.10-2' into HEAD:
 - Merge tag 'intel-pinctrl-v5.10-2' into HEAD

pinctrl:
 -  intel: Set default bias in case no particular value given
 -  intel: Fix 2 kOhm bias which is 833 Ohm

----------------------------------------------------------------
Andy Shevchenko (20):
      gpiolib: Use proper type for bias enumerator in gpio_set_bias()
      gpiolib: Switch to use compat_need_64bit_alignment_fixup() helper
      Merge tag 'intel-pinctrl-v5.10-2' into HEAD
      gpiolib: Replace unsigned by unsigned int
      gpiolib: add missed break statement
      gpiolib: use proper API to pack pin configuration parameters
      gpiolib: Extract gpio_set_config_with_argument() for future use
      gpiolib: move bias related code from gpio_set_config() to gpio_set_bias()
      gpiolib: Extract gpio_set_config_with_argument_optional() helper
      gpiolib: Introduce gpio_set_debounce_timeout() for internal use
      gpiolib: acpi: Respect bias settings for GpioInt() resource
      gpiolib: acpi: Use named item for enum gpiod_flags variable
      gpiolib: acpi: Take into account debounce settings
      gpiolib: acpi: Move non-critical code outside of critical section
      gpiolib: acpi: Move acpi_gpio_to_gpiod_flags() upper in the code
      gpiolib: acpi: Make acpi_gpio_to_gpiod_flags() usable for GpioInt()
      gpiolib: acpi: Extract acpi_request_own_gpiod() helper
      gpiolib: acpi: Convert pin_index to be u16
      gpiolib: acpi: Use BIT() macro to increase readability
      gpiolib: acpi: Make Intel GPIO tree official for GPIO ACPI work

Deepak R Varma (1):
      gpio: 104-idi-48: improve code indentation

Linus Walleij (3):
      gpio: Retire the explicit gpio irqchip code
      gpio: stmpe: Fix forgotten refactoring
      Merge branch 'devel' into for-next

Vasile-Laurentiu Stanimir (1):
      gpiolib: acpi: Set initial value for output pin based on bias and polarity

 Documentation/driver-api/gpio/driver.rst |  67 +++++---
 MAINTAINERS                              |   1 +
 drivers/gpio/TODO                        |  49 ------
 drivers/gpio/gpio-104-idi-48.c           |   6 +-
 drivers/gpio/gpio-stmpe.c                |  10 +-
 drivers/gpio/gpiolib-acpi.c              | 138 ++++++++++-------
 drivers/gpio/gpiolib-acpi.h              |   2 +
 drivers/gpio/gpiolib-cdev.c              |  24 +--
 drivers/gpio/gpiolib.c                   | 256 ++++++++-----------------------
 drivers/gpio/gpiolib.h                   |   1 +
 drivers/pinctrl/intel/pinctrl-intel.c    |  40 +++--
 include/linux/gpio/consumer.h            |   4 +-
 include/linux/gpio/driver.h              |  71 ---------
 13 files changed, 235 insertions(+), 434 deletions(-)

-- 
With Best Regards,
Andy Shevchenko

Re: [GIT PULL] intel-gpio for 5.11-1

[Linus Walleij]

On Mon, Nov 16, 2020 at 4:26 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:

> The following changes since commit b72de3ff19fdc4bbe4d4bb3f4483c7e46e00bac3:
>
>   gpio: sifive: Fix SiFive gpio probe (2020-11-11 09:53:09 +0100)
>
> are available in the Git repository at:
>
>   git@gitolite.kernel.org:pub/scm/linux/kernel/git/andy/linux-gpio-intel.git tags/intel-gpio-v5.11-1
>
> for you to fetch changes up to e709a7b5a066362b697d65dda90edc71f913df70:
>
>   gpiolib: acpi: Make Intel GPIO tree official for GPIO ACPI work (2020-11-16 14:14:35 +0200)

Thanks! I merged in v5.10-rc4 to the GPIO devel branch and
pulled in this on top, works like a charm!

Yours,
Linus Walleij

Re: [GIT PULL] intel-gpio for 5.11-1

[Andy Shevchenko]

On Tue, Nov 17, 2020 at 10:24:37PM +0100, Linus Walleij wrote:
> On Mon, Nov 16, 2020 at 4:26 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> 
> > The following changes since commit b72de3ff19fdc4bbe4d4bb3f4483c7e46e00bac3:
> >
> >   gpio: sifive: Fix SiFive gpio probe (2020-11-11 09:53:09 +0100)
> >
> > are available in the Git repository at:
> >
> >   git@gitolite.kernel.org:pub/scm/linux/kernel/git/andy/linux-gpio-intel.git tags/intel-gpio-v5.11-1
> >
> > for you to fetch changes up to e709a7b5a066362b697d65dda90edc71f913df70:
> >
> >   gpiolib: acpi: Make Intel GPIO tree official for GPIO ACPI work (2020-11-16 14:14:35 +0200)
> 
> Thanks! I merged in v5.10-rc4 to the GPIO devel branch and
> pulled in this on top, works like a charm!

I'm not sure I understood why you merged v5.10-rc4, but in any case thanks,
result is great!

-- 
With Best Regards,
Andy Shevchenko

Re: [GIT PULL] intel-gpio for 5.11-1

[Linus Walleij]

On Wed, Nov 18, 2020 at 3:17 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Tue, Nov 17, 2020 at 10:24:37PM +0100, Linus Walleij wrote:

> > Thanks! I merged in v5.10-rc4 to the GPIO devel branch and
> > pulled in this on top, works like a charm!
>
> I'm not sure I understood why you merged v5.10-rc4, but in any case thanks,
> result is great!

I merged v5.10-rc4 because the pull request says:

> The following changes since commit b72de3ff19fdc4bbe4d4bb3f4483c7e46e00bac3:
>
>   gpio: sifive: Fix SiFive gpio probe (2020-11-11 09:53:09 +0100)

And that patch was on my fixes branch, which went into v5.10-rc4,
so in order to have the base commit in the devel tree I had to merge
in v5.10-rc4.

Yours,
Linus Walleij

Re: [GIT PULL] intel-gpio for 5.11-1

[Andy Shevchenko]

On Thu, Nov 19, 2020 at 09:31:03AM +0100, Linus Walleij wrote:
> On Wed, Nov 18, 2020 at 3:17 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Nov 17, 2020 at 10:24:37PM +0100, Linus Walleij wrote:
> 
> > > Thanks! I merged in v5.10-rc4 to the GPIO devel branch and
> > > pulled in this on top, works like a charm!
> >
> > I'm not sure I understood why you merged v5.10-rc4, but in any case thanks,
> > result is great!
> 
> I merged v5.10-rc4 because the pull request says:
> 
> > The following changes since commit b72de3ff19fdc4bbe4d4bb3f4483c7e46e00bac3:
> >
> >   gpio: sifive: Fix SiFive gpio probe (2020-11-11 09:53:09 +0100)
> 
> And that patch was on my fixes branch, which went into v5.10-rc4,
> so in order to have the base commit in the devel tree I had to merge
> in v5.10-rc4.

I based solely on your gpio/for-next as has been stated in the cover letter.
So, the PR might have been applied on top of your gpio/for-next without any
additional merge required.

I admit that PR automatic text is a bit deviated (it has been taken from wrong
base, note that tag is correct nevertheless). I will look forward to amend my
scripts.

-- 
With Best Regards,
Andy Shevchenko

Re: [GIT PULL] intel-gpio for 5.11-1

[Andy Shevchenko]

On Thu, Nov 19, 2020 at 12:58:28PM +0200, Andy Shevchenko wrote:
> On Thu, Nov 19, 2020 at 09:31:03AM +0100, Linus Walleij wrote:
> > On Wed, Nov 18, 2020 at 3:17 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Tue, Nov 17, 2020 at 10:24:37PM +0100, Linus Walleij wrote:
> > 
> > > > Thanks! I merged in v5.10-rc4 to the GPIO devel branch and
> > > > pulled in this on top, works like a charm!
> > >
> > > I'm not sure I understood why you merged v5.10-rc4, but in any case thanks,
> > > result is great!
> > 
> > I merged v5.10-rc4 because the pull request says:
> > 
> > > The following changes since commit b72de3ff19fdc4bbe4d4bb3f4483c7e46e00bac3:
> > >
> > >   gpio: sifive: Fix SiFive gpio probe (2020-11-11 09:53:09 +0100)
> > 
> > And that patch was on my fixes branch, which went into v5.10-rc4,
> > so in order to have the base commit in the devel tree I had to merge
> > in v5.10-rc4.
> 
> I based solely on your gpio/for-next as has been stated in the cover letter.
> So, the PR might have been applied on top of your gpio/for-next without any
> additional merge required.
> 
> I admit that PR automatic text is a bit deviated (it has been taken from wrong
> base, note that tag is correct nevertheless). I will look forward to amend my

"information in the tag"

> scripts.

-- 
With Best Regards,
Andy Shevchenko

Re: [GIT PULL] intel-gpio for 5.11-1

[Linus Walleij]

On Thu, Nov 19, 2020 at 11:57 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:

> > And that patch was on my fixes branch, which went into v5.10-rc4,
> > so in order to have the base commit in the devel tree I had to merge
> > in v5.10-rc4.
>
> I based solely on your gpio/for-next as has been stated in the cover letter.
> So, the PR might have been applied on top of your gpio/for-next without any
> additional merge required.

OK but my for-next isn't what is going to be merged by Torvalds so there
is some misunderstanding here.

In my tree "for-next" does not mean "for the next kernel that Torvalds
is going to release", it means "for the linux-next integration tree".

What is going into v5.11 is "devel" and that is why I'm always talking
about pulling stuff into devel etc.

for-next is created when I merged a few patches like this:

> git checkout for-next
> git reset --hard fixes
> git merge devel

(Procedure to create integration branch recommended by
Stephen Rothwell at one point.)

This is why your pull request work fine anyways if I merge in -rc4
because then "devel" will contain all commits from these two
branches at that point.

> I admit that PR automatic text is a bit deviated (it has been taken from wrong
> base, note that tag is correct nevertheless). I will look forward to amend my
> scripts.

Don't worry about it.

Maybe I need to think about how I name stuff.

Should I rename the branch "for-next" to "for-sjr-next" and
rename "devel" to "for-torvalds-next" then "fixes"
into "for-torvalds-current" or something
so it is crystal clear what they are for?

The community doesn't really have an established standard
here.

Yours,
Linus Walleij

Re: [GIT PULL] intel-gpio for 5.11-1

[Andy Shevchenko]

On Thu, Nov 19, 2020 at 01:43:38PM +0100, Linus Walleij wrote:
> On Thu, Nov 19, 2020 at 11:57 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> 
> > > And that patch was on my fixes branch, which went into v5.10-rc4,
> > > so in order to have the base commit in the devel tree I had to merge
> > > in v5.10-rc4.
> >
> > I based solely on your gpio/for-next as has been stated in the cover letter.
> > So, the PR might have been applied on top of your gpio/for-next without any
> > additional merge required.
> 
> OK but my for-next isn't what is going to be merged by Torvalds so there
> is some misunderstanding here.
> 
> In my tree "for-next" does not mean "for the next kernel that Torvalds
> is going to release", it means "for the linux-next integration tree".
> 
> What is going into v5.11 is "devel" and that is why I'm always talking
> about pulling stuff into devel etc.
> 
> for-next is created when I merged a few patches like this:
> 
> > git checkout for-next
> > git reset --hard fixes
> > git merge devel
> 
> (Procedure to create integration branch recommended by
> Stephen Rothwell at one point.)
> 
> This is why your pull request work fine anyways if I merge in -rc4
> because then "devel" will contain all commits from these two
> branches at that point.
> 
> > I admit that PR automatic text is a bit deviated (it has been taken from wrong
> > base, note that tag is correct nevertheless). I will look forward to amend my
> > scripts.
> 
> Don't worry about it.
> 
> Maybe I need to think about how I name stuff.
> 
> Should I rename the branch "for-next" to "for-sjr-next" and
> rename "devel" to "for-torvalds-next" then "fixes"
> into "for-torvalds-current" or something
> so it is crystal clear what they are for?
> 
> The community doesn't really have an established standard
> here.

Hmm... Usually for-next is what should come as material for next cycle.
And devel or so is for testing (can be rebased / etc)

I like the following schema (with possible variations in the parentheses):

 fixes (for-current) - what is going to the next rc of current cycle
 for-next - what is going to the next release cycle
 devel (review, ...) - what is under review / testing / etc

What you explained to me seems like swapped for-next and devel semantics and
this is confusing because the above schema is what I met in 99% of repositories
I'm cooking patches against.

-- 
With Best Regards,
Andy Shevchenko