intel-gpio for 5.11-1
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:
[email protected]: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(-)
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 11 lines · 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:
[email protected]: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
Quoted 9 lines · Linus Walleij
Quoted 6 lines · 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:
Quoted 8 lines
Quoted 5 lines
[email protected]: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!
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 7 lines · Andy Shevchenko
Quoted 2 lines · Linus Walleij
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:
Quoted 3 lines
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
Quoted 12 lines · Linus Walleij
Quoted 7 lines · Andy Shevchenko
Quoted 2 lines · Linus Walleij
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:
Quoted 7 lines
Quoted 3 lines
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.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 21 lines · Andy Shevchenko
Quoted 12 lines · Linus Walleij
Quoted 7 lines · Andy Shevchenko
Quoted 2 lines · Linus Walleij
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:
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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"
Quoted 1 line
scripts.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 7 lines · Andy Shevchenko
Quoted 3 lines
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:
Quoted 3 lines
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.
Quoted 3 lines
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
Quoted 41 lines · Linus Walleij
Quoted 7 lines · Andy Shevchenko
Quoted 3 lines
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:
Quoted 3 lines
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.
Quoted 3 lines
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.
Quoted 7 lines
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.
Signature · 2 lines
With Best Regards, Andy Shevchenko