mbox series

[v6,00/12] platform/x86: introduce p2sb_bar() helper

Message ID 20220606164138.66535-1-andriy.shevchenko@linux.intel.com
Headers show
Series platform/x86: introduce p2sb_bar() helper | expand

Message

Andy Shevchenko June 6, 2022, 4:41 p.m. UTC
There are a few users that would like to utilize P2SB mechanism of hiding
and unhiding a device from the PCI configuration space.

Here is the series to consolidate p2sb handling code for existing users
and to provide a generic way for new comer(s).

It also includes a patch to enable GPIO controllers on Apollo Lake
when it's used with ABL bootloader w/o ACPI support.

The patch that brings the helper ("platform/x86/intel: Add Primary to
Sideband (P2SB) bridge support") has a commit message that sheds a light
on what the P2SB is and why this is needed.

I have tested this on Apollo Lake platform (I'm able to see SPI NOR and
since we have an ACPI device for GPIO I do not see any attempts to recreate
one).

The series is ready to be merged via MFD tree, but see below.

The series also includes updates for Simatic IPC drivers that partially
tagged by respective maintainers (the main question is if Pavel is okay
with the last three patches, since I believe Hans is okay with removing
some code under PDx86). Hence the first 8 patches can be merged right
away and the rest when Pavel does his review.

Changes in v6:
- added tag to patch 5 (Lee)
- incorporated Henning's series on top of v5

Changes in v5:
- rewritten patch 1 to use pci_scan_single_device() (Lukas, Bjorn)
- rebased patch 2 on top of the new Intel SPI NOR codebase
- fixed a potential bug and rewritten resource filling in patch 5 (Lee)
- added many different tags in a few patches (Jean, Wolfram, Henning)

Changes in v4:
- added tag to the entire series (Hans)
- added tag to pin control patch (Mika)
- dropped PCI core changes (PCI core doesn't want modifications to be made)
- as a consequence of the above merged necessary bits into p2sb.c
- added a check that p2sb is really hidden (Hans)
- added EDAC patches (reviewed by maintainer internally)

Changes in v3:
- resent with cover letter

Changes in v2:
- added parentheses around bus in macros (Joe)
- added tag (Jean)
- fixed indentation and wrapping in the header (Christoph)
- moved out of PCI realm to PDx86 as the best common denominator (Bjorn)
- added a verbose commit message to explain P2SB thingy (Bjorn)
- converted first parameter from pci_dev to pci_bus
- made first two parameters (bus and devfn) optional (Henning, Lee)
- added Intel pin control patch to the series (Henning, Mika)
- fixed English style in the commit message of one of MFD patch (Lee)
- added tags to my MFD LPC ICH patches (Lee)
- used consistently (c) (Lee)
- made indexing for MFD cell and resource arrays (Lee)
- fixed the resource size in i801 (Jean)

Andy Shevchenko (6):
  pinctrl: intel: Check against matching data instead of ACPI companion
  mfd: lpc_ich: Factor out lpc_ich_enable_spi_write()
  mfd: lpc_ich: Switch to generic p2sb_bar()
  i2c: i801: convert to use common P2SB accessor
  EDAC, pnd2: Use proper I/O accessors and address space annotation
  EDAC, pnd2: convert to use common P2SB accessor

Henning Schild (4):
  watchdog: simatic-ipc-wdt: convert to use P2SB accessor
  leds: simatic-ipc-leds: convert to use P2SB accessor
  platform/x86: simatic-ipc: drop custom P2SB bar code
  leds: simatic-ipc-leds-gpio: add GPIO version of Siemens driver

Jonathan Yong (1):
  platform/x86/intel: Add Primary to Sideband (P2SB) bridge support

Tan Jui Nee (1):
  mfd: lpc_ich: Add support for pinctrl in non-ACPI system

 drivers/edac/Kconfig                          |   1 +
 drivers/edac/pnd2_edac.c                      |  62 +++----
 drivers/i2c/busses/Kconfig                    |   1 +
 drivers/i2c/busses/i2c-i801.c                 |  39 +----
 drivers/leds/simple/Kconfig                   |   6 +-
 drivers/leds/simple/Makefile                  |   1 +
 drivers/leds/simple/simatic-ipc-leds-gpio.c   | 105 ++++++++++++
 drivers/leds/simple/simatic-ipc-leds.c        |  80 +--------
 drivers/mfd/Kconfig                           |   1 +
 drivers/mfd/lpc_ich.c                         | 161 ++++++++++++++----
 drivers/pinctrl/intel/pinctrl-intel.c         |  14 +-
 drivers/platform/x86/intel/Kconfig            |  12 ++
 drivers/platform/x86/intel/Makefile           |   2 +
 drivers/platform/x86/intel/p2sb.c             | 133 +++++++++++++++
 drivers/platform/x86/simatic-ipc.c            |  43 +----
 drivers/watchdog/Kconfig                      |   1 +
 drivers/watchdog/simatic-ipc-wdt.c            |  15 +-
 include/linux/platform_data/x86/p2sb.h        |  28 +++
 .../platform_data/x86/simatic-ipc-base.h      |   2 -
 19 files changed, 464 insertions(+), 243 deletions(-)
 create mode 100644 drivers/leds/simple/simatic-ipc-leds-gpio.c
 create mode 100644 drivers/platform/x86/intel/p2sb.c
 create mode 100644 include/linux/platform_data/x86/p2sb.h


base-commit: 40b58e42584bf5bd9230481dc8946f714fb387de

Comments

Hans de Goede June 7, 2022, 5:16 p.m. UTC | #1
Hi,

On 6/6/22 18:41, Andy Shevchenko wrote:
> There are a few users that would like to utilize P2SB mechanism of hiding
> and unhiding a device from the PCI configuration space.
> 
> Here is the series to consolidate p2sb handling code for existing users
> and to provide a generic way for new comer(s).
> 
> It also includes a patch to enable GPIO controllers on Apollo Lake
> when it's used with ABL bootloader w/o ACPI support.
> 
> The patch that brings the helper ("platform/x86/intel: Add Primary to
> Sideband (P2SB) bridge support") has a commit message that sheds a light
> on what the P2SB is and why this is needed.
> 
> I have tested this on Apollo Lake platform (I'm able to see SPI NOR and
> since we have an ACPI device for GPIO I do not see any attempts to recreate
> one).
> 
> The series is ready to be merged via MFD tree, but see below.
> 
> The series also includes updates for Simatic IPC drivers that partially
> tagged by respective maintainers (the main question is if Pavel is okay
> with the last three patches, since I believe Hans is okay with removing
> some code under PDx86). Hence the first 8 patches can be merged right
> away and the rest when Pavel does his review.
> 
> Changes in v6:
> - added tag to patch 5 (Lee)
> - incorporated Henning's series on top of v5

I've taken a quick look at the new patches and they look ok to me:

Acked-by: Hans de Goede <hdegoede@redhat.com>

for the entire series.

Regards,

Hans


> 
> Changes in v5:
> - rewritten patch 1 to use pci_scan_single_device() (Lukas, Bjorn)
> - rebased patch 2 on top of the new Intel SPI NOR codebase
> - fixed a potential bug and rewritten resource filling in patch 5 (Lee)
> - added many different tags in a few patches (Jean, Wolfram, Henning)
> 
> Changes in v4:
> - added tag to the entire series (Hans)
> - added tag to pin control patch (Mika)
> - dropped PCI core changes (PCI core doesn't want modifications to be made)
> - as a consequence of the above merged necessary bits into p2sb.c
> - added a check that p2sb is really hidden (Hans)
> - added EDAC patches (reviewed by maintainer internally)
> 
> Changes in v3:
> - resent with cover letter
> 
> Changes in v2:
> - added parentheses around bus in macros (Joe)
> - added tag (Jean)
> - fixed indentation and wrapping in the header (Christoph)
> - moved out of PCI realm to PDx86 as the best common denominator (Bjorn)
> - added a verbose commit message to explain P2SB thingy (Bjorn)
> - converted first parameter from pci_dev to pci_bus
> - made first two parameters (bus and devfn) optional (Henning, Lee)
> - added Intel pin control patch to the series (Henning, Mika)
> - fixed English style in the commit message of one of MFD patch (Lee)
> - added tags to my MFD LPC ICH patches (Lee)
> - used consistently (c) (Lee)
> - made indexing for MFD cell and resource arrays (Lee)
> - fixed the resource size in i801 (Jean)
> 
> Andy Shevchenko (6):
>   pinctrl: intel: Check against matching data instead of ACPI companion
>   mfd: lpc_ich: Factor out lpc_ich_enable_spi_write()
>   mfd: lpc_ich: Switch to generic p2sb_bar()
>   i2c: i801: convert to use common P2SB accessor
>   EDAC, pnd2: Use proper I/O accessors and address space annotation
>   EDAC, pnd2: convert to use common P2SB accessor
> 
> Henning Schild (4):
>   watchdog: simatic-ipc-wdt: convert to use P2SB accessor
>   leds: simatic-ipc-leds: convert to use P2SB accessor
>   platform/x86: simatic-ipc: drop custom P2SB bar code
>   leds: simatic-ipc-leds-gpio: add GPIO version of Siemens driver
> 
> Jonathan Yong (1):
>   platform/x86/intel: Add Primary to Sideband (P2SB) bridge support
> 
> Tan Jui Nee (1):
>   mfd: lpc_ich: Add support for pinctrl in non-ACPI system
> 
>  drivers/edac/Kconfig                          |   1 +
>  drivers/edac/pnd2_edac.c                      |  62 +++----
>  drivers/i2c/busses/Kconfig                    |   1 +
>  drivers/i2c/busses/i2c-i801.c                 |  39 +----
>  drivers/leds/simple/Kconfig                   |   6 +-
>  drivers/leds/simple/Makefile                  |   1 +
>  drivers/leds/simple/simatic-ipc-leds-gpio.c   | 105 ++++++++++++
>  drivers/leds/simple/simatic-ipc-leds.c        |  80 +--------
>  drivers/mfd/Kconfig                           |   1 +
>  drivers/mfd/lpc_ich.c                         | 161 ++++++++++++++----
>  drivers/pinctrl/intel/pinctrl-intel.c         |  14 +-
>  drivers/platform/x86/intel/Kconfig            |  12 ++
>  drivers/platform/x86/intel/Makefile           |   2 +
>  drivers/platform/x86/intel/p2sb.c             | 133 +++++++++++++++
>  drivers/platform/x86/simatic-ipc.c            |  43 +----
>  drivers/watchdog/Kconfig                      |   1 +
>  drivers/watchdog/simatic-ipc-wdt.c            |  15 +-
>  include/linux/platform_data/x86/p2sb.h        |  28 +++
>  .../platform_data/x86/simatic-ipc-base.h      |   2 -
>  19 files changed, 464 insertions(+), 243 deletions(-)
>  create mode 100644 drivers/leds/simple/simatic-ipc-leds-gpio.c
>  create mode 100644 drivers/platform/x86/intel/p2sb.c
>  create mode 100644 include/linux/platform_data/x86/p2sb.h
> 
> 
> base-commit: 40b58e42584bf5bd9230481dc8946f714fb387de
Lee Jones June 8, 2022, 7:42 a.m. UTC | #2
On Mon, 06 Jun 2022, Andy Shevchenko wrote:

> There are a few users that would like to utilize P2SB mechanism of hiding
> and unhiding a device from the PCI configuration space.
> 
> Here is the series to consolidate p2sb handling code for existing users
> and to provide a generic way for new comer(s).
> 
> It also includes a patch to enable GPIO controllers on Apollo Lake
> when it's used with ABL bootloader w/o ACPI support.
> 
> The patch that brings the helper ("platform/x86/intel: Add Primary to
> Sideband (P2SB) bridge support") has a commit message that sheds a light
> on what the P2SB is and why this is needed.
> 
> I have tested this on Apollo Lake platform (I'm able to see SPI NOR and
> since we have an ACPI device for GPIO I do not see any attempts to recreate
> one).
> 
> The series is ready to be merged via MFD tree, but see below.
> 
> The series also includes updates for Simatic IPC drivers that partially
> tagged by respective maintainers (the main question is if Pavel is okay
> with the last three patches, since I believe Hans is okay with removing
> some code under PDx86). Hence the first 8 patches can be merged right
> away and the rest when Pavel does his review.

Can we just wait for Pavel's review, then merge them all at once?
Andy Shevchenko June 8, 2022, 10:50 a.m. UTC | #3
On Wed, Jun 8, 2022 at 9:42 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> On Mon, 06 Jun 2022, Andy Shevchenko wrote:
>
> > There are a few users that would like to utilize P2SB mechanism of hiding
> > and unhiding a device from the PCI configuration space.
> >
> > Here is the series to consolidate p2sb handling code for existing users
> > and to provide a generic way for new comer(s).
> >
> > It also includes a patch to enable GPIO controllers on Apollo Lake
> > when it's used with ABL bootloader w/o ACPI support.
> >
> > The patch that brings the helper ("platform/x86/intel: Add Primary to
> > Sideband (P2SB) bridge support") has a commit message that sheds a light
> > on what the P2SB is and why this is needed.
> >
> > I have tested this on Apollo Lake platform (I'm able to see SPI NOR and
> > since we have an ACPI device for GPIO I do not see any attempts to recreate
> > one).
> >
> > The series is ready to be merged via MFD tree, but see below.
> >
> > The series also includes updates for Simatic IPC drivers that partially
> > tagged by respective maintainers (the main question is if Pavel is okay
> > with the last three patches, since I believe Hans is okay with removing
> > some code under PDx86). Hence the first 8 patches can be merged right
> > away and the rest when Pavel does his review.
>
> Can we just wait for Pavel's review, then merge them all at once?

Sure, it would be the best course of action.
Andy Shevchenko June 21, 2022, 11:58 a.m. UTC | #4
On Wed, Jun 08, 2022 at 12:50:44PM +0200, Andy Shevchenko wrote:
> On Wed, Jun 8, 2022 at 9:42 AM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > On Mon, 06 Jun 2022, Andy Shevchenko wrote:
> >
> > > There are a few users that would like to utilize P2SB mechanism of hiding
> > > and unhiding a device from the PCI configuration space.
> > >
> > > Here is the series to consolidate p2sb handling code for existing users
> > > and to provide a generic way for new comer(s).
> > >
> > > It also includes a patch to enable GPIO controllers on Apollo Lake
> > > when it's used with ABL bootloader w/o ACPI support.
> > >
> > > The patch that brings the helper ("platform/x86/intel: Add Primary to
> > > Sideband (P2SB) bridge support") has a commit message that sheds a light
> > > on what the P2SB is and why this is needed.
> > >
> > > I have tested this on Apollo Lake platform (I'm able to see SPI NOR and
> > > since we have an ACPI device for GPIO I do not see any attempts to recreate
> > > one).
> > >
> > > The series is ready to be merged via MFD tree, but see below.
> > >
> > > The series also includes updates for Simatic IPC drivers that partially
> > > tagged by respective maintainers (the main question is if Pavel is okay
> > > with the last three patches, since I believe Hans is okay with removing
> > > some code under PDx86). Hence the first 8 patches can be merged right
> > > away and the rest when Pavel does his review.
> >
> > Can we just wait for Pavel's review, then merge them all at once?
> 
> Sure, it would be the best course of action.

Pavel, do you have a chance to review the patches (last three) that touch
LED drivers? What would be your verdict?
Andy Shevchenko June 29, 2022, 4:39 p.m. UTC | #5
+Cc: Rafael

On Tue, Jun 21, 2022 at 02:58:16PM +0300, Andy Shevchenko wrote:
> On Wed, Jun 08, 2022 at 12:50:44PM +0200, Andy Shevchenko wrote:
> > On Wed, Jun 8, 2022 at 9:42 AM Lee Jones <lee.jones@linaro.org> wrote:
> > > On Mon, 06 Jun 2022, Andy Shevchenko wrote:
> > >
> > > > There are a few users that would like to utilize P2SB mechanism of hiding
> > > > and unhiding a device from the PCI configuration space.
> > > >
> > > > Here is the series to consolidate p2sb handling code for existing users
> > > > and to provide a generic way for new comer(s).
> > > >
> > > > It also includes a patch to enable GPIO controllers on Apollo Lake
> > > > when it's used with ABL bootloader w/o ACPI support.
> > > >
> > > > The patch that brings the helper ("platform/x86/intel: Add Primary to
> > > > Sideband (P2SB) bridge support") has a commit message that sheds a light
> > > > on what the P2SB is and why this is needed.
> > > >
> > > > I have tested this on Apollo Lake platform (I'm able to see SPI NOR and
> > > > since we have an ACPI device for GPIO I do not see any attempts to recreate
> > > > one).
> > > >
> > > > The series is ready to be merged via MFD tree, but see below.
> > > >
> > > > The series also includes updates for Simatic IPC drivers that partially
> > > > tagged by respective maintainers (the main question is if Pavel is okay
> > > > with the last three patches, since I believe Hans is okay with removing
> > > > some code under PDx86). Hence the first 8 patches can be merged right
> > > > away and the rest when Pavel does his review.
> > >
> > > Can we just wait for Pavel's review, then merge them all at once?
> > 
> > Sure, it would be the best course of action.
> 
> Pavel, do you have a chance to review the patches (last three) that touch
> LED drivers? What would be your verdict?

Lee, Rafael,

It seems quite hard to get Pavel's attention to this series [1]. It's already
passed more than 3 weeks for any sign of review of three top patches of the
series that touched LED subsystem. The entire series has all necessary tags,
but for LED changes.

Note, that the top of this series is not done by me and was sent for
preliminary review much earlier [2], altogether it makes months of no response from
the maintainer.

The nature of patches is pretty simple and doesn't touch any of other than Simatic LED
drivers nor LED core. Moreover, it was written by Siemens, who produces the H/W in
question and very well tested as a separate change and as part of the series.

I think to move forward we may ask Rafael to review it on behalf of good maintainer
and with his approval apply entire series.

Thoughts?

[1]: https://lore.kernel.org/all/20220606164138.66535-1-andriy.shevchenko@linux.intel.com/
[2]: https://lore.kernel.org/linux-leds/20220513083652.974-1-henning.schild@siemens.com/
Henning Schild June 29, 2022, 5:14 p.m. UTC | #6
Am Wed, 29 Jun 2022 19:39:58 +0300
schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

> +Cc: Rafael
> 
> On Tue, Jun 21, 2022 at 02:58:16PM +0300, Andy Shevchenko wrote:
> > On Wed, Jun 08, 2022 at 12:50:44PM +0200, Andy Shevchenko wrote:  
> > > On Wed, Jun 8, 2022 at 9:42 AM Lee Jones <lee.jones@linaro.org>
> > > wrote:  
> > > > On Mon, 06 Jun 2022, Andy Shevchenko wrote:
> > > >  
> > > > > There are a few users that would like to utilize P2SB
> > > > > mechanism of hiding and unhiding a device from the PCI
> > > > > configuration space.
> > > > >
> > > > > Here is the series to consolidate p2sb handling code for
> > > > > existing users and to provide a generic way for new comer(s).
> > > > >
> > > > > It also includes a patch to enable GPIO controllers on Apollo
> > > > > Lake when it's used with ABL bootloader w/o ACPI support.
> > > > >
> > > > > The patch that brings the helper ("platform/x86/intel: Add
> > > > > Primary to Sideband (P2SB) bridge support") has a commit
> > > > > message that sheds a light on what the P2SB is and why this
> > > > > is needed.
> > > > >
> > > > > I have tested this on Apollo Lake platform (I'm able to see
> > > > > SPI NOR and since we have an ACPI device for GPIO I do not
> > > > > see any attempts to recreate one).
> > > > >
> > > > > The series is ready to be merged via MFD tree, but see below.
> > > > >
> > > > > The series also includes updates for Simatic IPC drivers that
> > > > > partially tagged by respective maintainers (the main question
> > > > > is if Pavel is okay with the last three patches, since I
> > > > > believe Hans is okay with removing some code under PDx86).
> > > > > Hence the first 8 patches can be merged right away and the
> > > > > rest when Pavel does his review.  
> > > >
> > > > Can we just wait for Pavel's review, then merge them all at
> > > > once?  
> > > 
> > > Sure, it would be the best course of action.  
> > 
> > Pavel, do you have a chance to review the patches (last three) that
> > touch LED drivers? What would be your verdict?  
> 
> Lee, Rafael,
> 
> It seems quite hard to get Pavel's attention to this series [1]. It's
> already passed more than 3 weeks for any sign of review of three top
> patches of the series that touched LED subsystem. The entire series
> has all necessary tags, but for LED changes.
> 
> Note, that the top of this series is not done by me and was sent for
> preliminary review much earlier [2], altogether it makes months of no
> response from the maintainer.
> 
> The nature of patches is pretty simple and doesn't touch any of other
> than Simatic LED drivers nor LED core. Moreover, it was written by
> Siemens, who produces the H/W in question and very well tested as a
> separate change and as part of the series.

The code has been reviewed and is in fact pretty simple. The only
questionable but pragmatic change that might catch the attention of a
pedantic reviewer is that i did put the gpio implementation of the
driver under the same/existing kernel config switch.

> I think to move forward we may ask Rafael to review it on behalf of
> good maintainer and with his approval apply entire series.
> 
> Thoughts?

Thanks for pushing this Andy. I was wondering how and when that story
would continue. Technically these changes should really go in one badge
or we need to find a way to separate them somehow. I would try to go
that extra mile to get out of your way. But i am kind of afraid such an
effort might also end up touching the same files and block us at the
same maintainer.

Did anyone check whether Pavel was active at all in those last months
and maybe other patches waiting for review? Hope he is fine and active
and just somehow forgot/overlooked/ignored this one.

Henning

> [1]:
> https://lore.kernel.org/all/20220606164138.66535-1-andriy.shevchenko@linux.intel.com/
> [2]:
> https://lore.kernel.org/linux-leds/20220513083652.974-1-henning.schild@siemens.com/
>
Andy Shevchenko July 13, 2022, 4:40 p.m. UTC | #7
On Wed, Jun 29, 2022 at 07:14:06PM +0200, Henning Schild wrote:
> Am Wed, 29 Jun 2022 19:39:58 +0300
> schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> 
> > +Cc: Rafael
> > 
> > On Tue, Jun 21, 2022 at 02:58:16PM +0300, Andy Shevchenko wrote:
> > > On Wed, Jun 08, 2022 at 12:50:44PM +0200, Andy Shevchenko wrote:  
> > > > On Wed, Jun 8, 2022 at 9:42 AM Lee Jones <lee.jones@linaro.org>
> > > > wrote:  
> > > > > On Mon, 06 Jun 2022, Andy Shevchenko wrote:
> > > > >  
> > > > > > There are a few users that would like to utilize P2SB
> > > > > > mechanism of hiding and unhiding a device from the PCI
> > > > > > configuration space.
> > > > > >
> > > > > > Here is the series to consolidate p2sb handling code for
> > > > > > existing users and to provide a generic way for new comer(s).
> > > > > >
> > > > > > It also includes a patch to enable GPIO controllers on Apollo
> > > > > > Lake when it's used with ABL bootloader w/o ACPI support.
> > > > > >
> > > > > > The patch that brings the helper ("platform/x86/intel: Add
> > > > > > Primary to Sideband (P2SB) bridge support") has a commit
> > > > > > message that sheds a light on what the P2SB is and why this
> > > > > > is needed.
> > > > > >
> > > > > > I have tested this on Apollo Lake platform (I'm able to see
> > > > > > SPI NOR and since we have an ACPI device for GPIO I do not
> > > > > > see any attempts to recreate one).
> > > > > >
> > > > > > The series is ready to be merged via MFD tree, but see below.
> > > > > >
> > > > > > The series also includes updates for Simatic IPC drivers that
> > > > > > partially tagged by respective maintainers (the main question
> > > > > > is if Pavel is okay with the last three patches, since I
> > > > > > believe Hans is okay with removing some code under PDx86).
> > > > > > Hence the first 8 patches can be merged right away and the
> > > > > > rest when Pavel does his review.  
> > > > >
> > > > > Can we just wait for Pavel's review, then merge them all at
> > > > > once?  
> > > > 
> > > > Sure, it would be the best course of action.  
> > > 
> > > Pavel, do you have a chance to review the patches (last three) that
> > > touch LED drivers? What would be your verdict?  
> > 
> > Lee, Rafael,
> > 
> > It seems quite hard to get Pavel's attention to this series [1]. It's
> > already passed more than 3 weeks for any sign of review of three top
> > patches of the series that touched LED subsystem. The entire series
> > has all necessary tags, but for LED changes.
> > 
> > Note, that the top of this series is not done by me and was sent for
> > preliminary review much earlier [2], altogether it makes months of no
> > response from the maintainer.
> > 
> > The nature of patches is pretty simple and doesn't touch any of other
> > than Simatic LED drivers nor LED core. Moreover, it was written by
> > Siemens, who produces the H/W in question and very well tested as a
> > separate change and as part of the series.
> 
> The code has been reviewed and is in fact pretty simple. The only
> questionable but pragmatic change that might catch the attention of a
> pedantic reviewer is that i did put the gpio implementation of the
> driver under the same/existing kernel config switch.
> 
> > I think to move forward we may ask Rafael to review it on behalf of
> > good maintainer and with his approval apply entire series.
> > 
> > Thoughts?
> 
> Thanks for pushing this Andy. I was wondering how and when that story
> would continue. Technically these changes should really go in one badge
> or we need to find a way to separate them somehow. I would try to go
> that extra mile to get out of your way. But i am kind of afraid such an
> effort might also end up touching the same files and block us at the
> same maintainer.
> 
> Did anyone check whether Pavel was active at all in those last months
> and maybe other patches waiting for review? Hope he is fine and active
> and just somehow forgot/overlooked/ignored this one.

I have send a private mail to Pavel and have got no response.
Can we move this forward, let's say, by applying first 8 patches?

> > [1]:
> > https://lore.kernel.org/all/20220606164138.66535-1-andriy.shevchenko@linux.intel.com/
> > [2]:
> > https://lore.kernel.org/linux-leds/20220513083652.974-1-henning.schild@siemens.com/
>
Rafael J. Wysocki July 13, 2022, 4:51 p.m. UTC | #8
On Wed, Jul 13, 2022 at 6:40 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Jun 29, 2022 at 07:14:06PM +0200, Henning Schild wrote:
> > Am Wed, 29 Jun 2022 19:39:58 +0300
> > schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> >
> > > +Cc: Rafael
> > >
> > > On Tue, Jun 21, 2022 at 02:58:16PM +0300, Andy Shevchenko wrote:
> > > > On Wed, Jun 08, 2022 at 12:50:44PM +0200, Andy Shevchenko wrote:
> > > > > On Wed, Jun 8, 2022 at 9:42 AM Lee Jones <lee.jones@linaro.org>
> > > > > wrote:
> > > > > > On Mon, 06 Jun 2022, Andy Shevchenko wrote:
> > > > > >
> > > > > > > There are a few users that would like to utilize P2SB
> > > > > > > mechanism of hiding and unhiding a device from the PCI
> > > > > > > configuration space.
> > > > > > >
> > > > > > > Here is the series to consolidate p2sb handling code for
> > > > > > > existing users and to provide a generic way for new comer(s).
> > > > > > >
> > > > > > > It also includes a patch to enable GPIO controllers on Apollo
> > > > > > > Lake when it's used with ABL bootloader w/o ACPI support.
> > > > > > >
> > > > > > > The patch that brings the helper ("platform/x86/intel: Add
> > > > > > > Primary to Sideband (P2SB) bridge support") has a commit
> > > > > > > message that sheds a light on what the P2SB is and why this
> > > > > > > is needed.
> > > > > > >
> > > > > > > I have tested this on Apollo Lake platform (I'm able to see
> > > > > > > SPI NOR and since we have an ACPI device for GPIO I do not
> > > > > > > see any attempts to recreate one).
> > > > > > >
> > > > > > > The series is ready to be merged via MFD tree, but see below.
> > > > > > >
> > > > > > > The series also includes updates for Simatic IPC drivers that
> > > > > > > partially tagged by respective maintainers (the main question
> > > > > > > is if Pavel is okay with the last three patches, since I
> > > > > > > believe Hans is okay with removing some code under PDx86).
> > > > > > > Hence the first 8 patches can be merged right away and the
> > > > > > > rest when Pavel does his review.
> > > > > >
> > > > > > Can we just wait for Pavel's review, then merge them all at
> > > > > > once?
> > > > >
> > > > > Sure, it would be the best course of action.
> > > >
> > > > Pavel, do you have a chance to review the patches (last three) that
> > > > touch LED drivers? What would be your verdict?
> > >
> > > Lee, Rafael,
> > >
> > > It seems quite hard to get Pavel's attention to this series [1]. It's
> > > already passed more than 3 weeks for any sign of review of three top
> > > patches of the series that touched LED subsystem. The entire series
> > > has all necessary tags, but for LED changes.
> > >
> > > Note, that the top of this series is not done by me and was sent for
> > > preliminary review much earlier [2], altogether it makes months of no
> > > response from the maintainer.
> > >
> > > The nature of patches is pretty simple and doesn't touch any of other
> > > than Simatic LED drivers nor LED core. Moreover, it was written by
> > > Siemens, who produces the H/W in question and very well tested as a
> > > separate change and as part of the series.
> >
> > The code has been reviewed and is in fact pretty simple. The only
> > questionable but pragmatic change that might catch the attention of a
> > pedantic reviewer is that i did put the gpio implementation of the
> > driver under the same/existing kernel config switch.
> >
> > > I think to move forward we may ask Rafael to review it on behalf of
> > > good maintainer and with his approval apply entire series.
> > >
> > > Thoughts?
> >
> > Thanks for pushing this Andy. I was wondering how and when that story
> > would continue. Technically these changes should really go in one badge
> > or we need to find a way to separate them somehow. I would try to go
> > that extra mile to get out of your way. But i am kind of afraid such an
> > effort might also end up touching the same files and block us at the
> > same maintainer.
> >
> > Did anyone check whether Pavel was active at all in those last months
> > and maybe other patches waiting for review? Hope he is fine and active
> > and just somehow forgot/overlooked/ignored this one.
>
> I have send a private mail to Pavel and have got no response.
> Can we move this forward, let's say, by applying first 8 patches?

IMV, everything up to and including patc [11/12] in the series should
be good to go.  There are ACKs from the relevant maintainers on that
material and I'm not sure what Pavel can add to that TBH.

> > > [1]:
> > > https://lore.kernel.org/all/20220606164138.66535-1-andriy.shevchenko@linux.intel.com/
> > > [2]:
> > > https://lore.kernel.org/linux-leds/20220513083652.974-1-henning.schild@siemens.com/
> >
Henning Schild July 13, 2022, 6:48 p.m. UTC | #9
Am Wed, 13 Jul 2022 19:40:23 +0300
schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

> On Wed, Jun 29, 2022 at 07:14:06PM +0200, Henning Schild wrote:
> > Am Wed, 29 Jun 2022 19:39:58 +0300
> > schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> >   
> > > +Cc: Rafael
> > > 
> > > On Tue, Jun 21, 2022 at 02:58:16PM +0300, Andy Shevchenko wrote:  
> > > > On Wed, Jun 08, 2022 at 12:50:44PM +0200, Andy Shevchenko
> > > > wrote:    
> > > > > On Wed, Jun 8, 2022 at 9:42 AM Lee Jones
> > > > > <lee.jones@linaro.org> wrote:    
> > > > > > On Mon, 06 Jun 2022, Andy Shevchenko wrote:
> > > > > >    
> > > > > > > There are a few users that would like to utilize P2SB
> > > > > > > mechanism of hiding and unhiding a device from the PCI
> > > > > > > configuration space.
> > > > > > >
> > > > > > > Here is the series to consolidate p2sb handling code for
> > > > > > > existing users and to provide a generic way for new
> > > > > > > comer(s).
> > > > > > >
> > > > > > > It also includes a patch to enable GPIO controllers on
> > > > > > > Apollo Lake when it's used with ABL bootloader w/o ACPI
> > > > > > > support.
> > > > > > >
> > > > > > > The patch that brings the helper ("platform/x86/intel: Add
> > > > > > > Primary to Sideband (P2SB) bridge support") has a commit
> > > > > > > message that sheds a light on what the P2SB is and why
> > > > > > > this is needed.
> > > > > > >
> > > > > > > I have tested this on Apollo Lake platform (I'm able to
> > > > > > > see SPI NOR and since we have an ACPI device for GPIO I
> > > > > > > do not see any attempts to recreate one).
> > > > > > >
> > > > > > > The series is ready to be merged via MFD tree, but see
> > > > > > > below.
> > > > > > >
> > > > > > > The series also includes updates for Simatic IPC drivers
> > > > > > > that partially tagged by respective maintainers (the main
> > > > > > > question is if Pavel is okay with the last three patches,
> > > > > > > since I believe Hans is okay with removing some code
> > > > > > > under PDx86). Hence the first 8 patches can be merged
> > > > > > > right away and the rest when Pavel does his review.    
> > > > > >
> > > > > > Can we just wait for Pavel's review, then merge them all at
> > > > > > once?    
> > > > > 
> > > > > Sure, it would be the best course of action.    
> > > > 
> > > > Pavel, do you have a chance to review the patches (last three)
> > > > that touch LED drivers? What would be your verdict?    
> > > 
> > > Lee, Rafael,
> > > 
> > > It seems quite hard to get Pavel's attention to this series [1].
> > > It's already passed more than 3 weeks for any sign of review of
> > > three top patches of the series that touched LED subsystem. The
> > > entire series has all necessary tags, but for LED changes.
> > > 
> > > Note, that the top of this series is not done by me and was sent
> > > for preliminary review much earlier [2], altogether it makes
> > > months of no response from the maintainer.
> > > 
> > > The nature of patches is pretty simple and doesn't touch any of
> > > other than Simatic LED drivers nor LED core. Moreover, it was
> > > written by Siemens, who produces the H/W in question and very
> > > well tested as a separate change and as part of the series.  
> > 
> > The code has been reviewed and is in fact pretty simple. The only
> > questionable but pragmatic change that might catch the attention of
> > a pedantic reviewer is that i did put the gpio implementation of the
> > driver under the same/existing kernel config switch.
> >   
> > > I think to move forward we may ask Rafael to review it on behalf
> > > of good maintainer and with his approval apply entire series.
> > > 
> > > Thoughts?  
> > 
> > Thanks for pushing this Andy. I was wondering how and when that
> > story would continue. Technically these changes should really go in
> > one badge or we need to find a way to separate them somehow. I
> > would try to go that extra mile to get out of your way. But i am
> > kind of afraid such an effort might also end up touching the same
> > files and block us at the same maintainer.
> > 
> > Did anyone check whether Pavel was active at all in those last
> > months and maybe other patches waiting for review? Hope he is fine
> > and active and just somehow forgot/overlooked/ignored this one.  
> 
> I have send a private mail to Pavel and have got no response.
> Can we move this forward, let's say, by applying first 8 patches?

I am sorry that situation is now coming. Both simatic-ipc and that
appollo lake pinctrl driver compete for the same device memory. That
conflict was known and we agreed on sorting it out together somehow.
Not applying my patches could leave my LED drivers simply not working
any longer, or worse ... them making the apollolake platform stuff act
up somehow weird with unexpected EBUSY.

The series can not be split, or we have to write additional code to
properly deal with the conflict. I could envision my LED drivers still
accessing raw memory and ignoring EBUSY (very hacky! ... and touching
"we need Pavel code")

Another way could maybe be. Do the whole P2SB but do not make
apollolake pinctrl come up without ACPI. Somewhere in patches 1-8 there
is code which makes the pinctrl stuff come up for certain CPUs without
ACPI. It is really only some out of many CPUs which have pinctrl, and i
am not sure i remember what that has to do with the P2SB helpers as
such. The helpers are a refactoring, while the "bring up apollolake
pinctrl at all times" is a functional change ... now causing conflict.

And maybe there is a way/process to escalate to another maintainer.
Does anyone even know what is going on with Pavel? 

Henning

> > > [1]:
> > > https://lore.kernel.org/all/20220606164138.66535-1-andriy.shevchenko@linux.intel.com/
> > > [2]:
> > > https://lore.kernel.org/linux-leds/20220513083652.974-1-henning.schild@siemens.com/
> > >  
> >   
>
Lee Jones July 14, 2022, 9:37 a.m. UTC | #10
On Wed, 13 Jul 2022, Henning Schild wrote:

> Am Wed, 13 Jul 2022 19:40:23 +0300
> schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> 
> > On Wed, Jun 29, 2022 at 07:14:06PM +0200, Henning Schild wrote:
> > > Am Wed, 29 Jun 2022 19:39:58 +0300
> > > schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> > >   
> > > > +Cc: Rafael
> > > > 
> > > > On Tue, Jun 21, 2022 at 02:58:16PM +0300, Andy Shevchenko wrote:  
> > > > > On Wed, Jun 08, 2022 at 12:50:44PM +0200, Andy Shevchenko
> > > > > wrote:    
> > > > > > On Wed, Jun 8, 2022 at 9:42 AM Lee Jones
> > > > > > <lee.jones@linaro.org> wrote:    
> > > > > > > On Mon, 06 Jun 2022, Andy Shevchenko wrote:
> > > > > > >    
> > > > > > > > There are a few users that would like to utilize P2SB
> > > > > > > > mechanism of hiding and unhiding a device from the PCI
> > > > > > > > configuration space.
> > > > > > > >
> > > > > > > > Here is the series to consolidate p2sb handling code for
> > > > > > > > existing users and to provide a generic way for new
> > > > > > > > comer(s).
> > > > > > > >
> > > > > > > > It also includes a patch to enable GPIO controllers on
> > > > > > > > Apollo Lake when it's used with ABL bootloader w/o ACPI
> > > > > > > > support.
> > > > > > > >
> > > > > > > > The patch that brings the helper ("platform/x86/intel: Add
> > > > > > > > Primary to Sideband (P2SB) bridge support") has a commit
> > > > > > > > message that sheds a light on what the P2SB is and why
> > > > > > > > this is needed.
> > > > > > > >
> > > > > > > > I have tested this on Apollo Lake platform (I'm able to
> > > > > > > > see SPI NOR and since we have an ACPI device for GPIO I
> > > > > > > > do not see any attempts to recreate one).
> > > > > > > >
> > > > > > > > The series is ready to be merged via MFD tree, but see
> > > > > > > > below.
> > > > > > > >
> > > > > > > > The series also includes updates for Simatic IPC drivers
> > > > > > > > that partially tagged by respective maintainers (the main
> > > > > > > > question is if Pavel is okay with the last three patches,
> > > > > > > > since I believe Hans is okay with removing some code
> > > > > > > > under PDx86). Hence the first 8 patches can be merged
> > > > > > > > right away and the rest when Pavel does his review.    
> > > > > > >
> > > > > > > Can we just wait for Pavel's review, then merge them all at
> > > > > > > once?    
> > > > > > 
> > > > > > Sure, it would be the best course of action.    
> > > > > 
> > > > > Pavel, do you have a chance to review the patches (last three)
> > > > > that touch LED drivers? What would be your verdict?    
> > > > 
> > > > Lee, Rafael,
> > > > 
> > > > It seems quite hard to get Pavel's attention to this series [1].
> > > > It's already passed more than 3 weeks for any sign of review of
> > > > three top patches of the series that touched LED subsystem. The
> > > > entire series has all necessary tags, but for LED changes.
> > > > 
> > > > Note, that the top of this series is not done by me and was sent
> > > > for preliminary review much earlier [2], altogether it makes
> > > > months of no response from the maintainer.
> > > > 
> > > > The nature of patches is pretty simple and doesn't touch any of
> > > > other than Simatic LED drivers nor LED core. Moreover, it was
> > > > written by Siemens, who produces the H/W in question and very
> > > > well tested as a separate change and as part of the series.  
> > > 
> > > The code has been reviewed and is in fact pretty simple. The only
> > > questionable but pragmatic change that might catch the attention of
> > > a pedantic reviewer is that i did put the gpio implementation of the
> > > driver under the same/existing kernel config switch.
> > >   
> > > > I think to move forward we may ask Rafael to review it on behalf
> > > > of good maintainer and with his approval apply entire series.
> > > > 
> > > > Thoughts?  
> > > 
> > > Thanks for pushing this Andy. I was wondering how and when that
> > > story would continue. Technically these changes should really go in
> > > one badge or we need to find a way to separate them somehow. I
> > > would try to go that extra mile to get out of your way. But i am
> > > kind of afraid such an effort might also end up touching the same
> > > files and block us at the same maintainer.
> > > 
> > > Did anyone check whether Pavel was active at all in those last
> > > months and maybe other patches waiting for review? Hope he is fine
> > > and active and just somehow forgot/overlooked/ignored this one.  
> > 
> > I have send a private mail to Pavel and have got no response.
> > Can we move this forward, let's say, by applying first 8 patches?
> 
> I am sorry that situation is now coming. Both simatic-ipc and that
> appollo lake pinctrl driver compete for the same device memory. That
> conflict was known and we agreed on sorting it out together somehow.
> Not applying my patches could leave my LED drivers simply not working
> any longer, or worse ... them making the apollolake platform stuff act
> up somehow weird with unexpected EBUSY.
> 
> The series can not be split, or we have to write additional code to
> properly deal with the conflict. I could envision my LED drivers still
> accessing raw memory and ignoring EBUSY (very hacky! ... and touching
> "we need Pavel code")
> 
> Another way could maybe be. Do the whole P2SB but do not make
> apollolake pinctrl come up without ACPI. Somewhere in patches 1-8 there
> is code which makes the pinctrl stuff come up for certain CPUs without
> ACPI. It is really only some out of many CPUs which have pinctrl, and i
> am not sure i remember what that has to do with the P2SB helpers as
> such. The helpers are a refactoring, while the "bring up apollolake
> pinctrl at all times" is a functional change ... now causing conflict.
> 
> And maybe there is a way/process to escalate to another maintainer.
> Does anyone even know what is going on with Pavel? 

I'll take the hit.  He had his chance.

I'm happy to move forward with Andy's review.

(Side note: Seeing as Pavel hasn't been seen for 2 months, I'll also
 follow-up on  the LED ML to offer to become temporary maintainer for a
 bit)
Andy Shevchenko July 14, 2022, 10:23 a.m. UTC | #11
On Thu, Jul 14, 2022 at 10:37:19AM +0100, Lee Jones wrote:
> On Wed, 13 Jul 2022, Henning Schild wrote:
> > Am Wed, 13 Jul 2022 19:40:23 +0300
> > schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

...

> > And maybe there is a way/process to escalate to another maintainer.
> > Does anyone even know what is going on with Pavel? 
> 
> I'll take the hit.  He had his chance.
> 
> I'm happy to move forward with Andy's review.

Thank you, Lee, much appreciated!
The patches (9..12) have my SoB, I think it should be enough, but if you thinks
they need my Rb tag, I can reply to them with it.

> (Side note: Seeing as Pavel hasn't been seen for 2 months, I'll also
>  follow-up on  the LED ML to offer to become temporary maintainer for a
>  bit)

This is good news as well, because I noticed there are a few series there stuck
as well.
Lee Jones July 14, 2022, 10:34 a.m. UTC | #12
On Thu, 14 Jul 2022, Andy Shevchenko wrote:

> On Thu, Jul 14, 2022 at 10:37:19AM +0100, Lee Jones wrote:
> > On Wed, 13 Jul 2022, Henning Schild wrote:
> > > Am Wed, 13 Jul 2022 19:40:23 +0300
> > > schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> 
> ...
> 
> > > And maybe there is a way/process to escalate to another maintainer.
> > > Does anyone even know what is going on with Pavel? 
> > 
> > I'll take the hit.  He had his chance.
> > 
> > I'm happy to move forward with Andy's review.
> 
> Thank you, Lee, much appreciated!
> The patches (9..12) have my SoB, I think it should be enough, but if you thinks
> they need my Rb tag, I can reply to them with it.

That's okay.  I've applied them and they are currently in soak.

> > (Side note: Seeing as Pavel hasn't been seen for 2 months, I'll also
> >  follow-up on  the LED ML to offer to become temporary maintainer for a
> >  bit)
> 
> This is good news as well, because I noticed there are a few series there stuck
> as well.

Feel free to reply to object or in support:

https://lore.kernel.org/all/Ys%2Fkruf8DE4ISo8M@google.com/
Henning Schild July 14, 2022, 11:03 a.m. UTC | #13
Am Thu, 14 Jul 2022 11:34:31 +0100
schrieb Lee Jones <lee.jones@linaro.org>:

> On Thu, 14 Jul 2022, Andy Shevchenko wrote:
> 
> > On Thu, Jul 14, 2022 at 10:37:19AM +0100, Lee Jones wrote:  
> > > On Wed, 13 Jul 2022, Henning Schild wrote:  
> > > > Am Wed, 13 Jul 2022 19:40:23 +0300
> > > > schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:  
> > 
> > ...
> >   
> > > > And maybe there is a way/process to escalate to another
> > > > maintainer. Does anyone even know what is going on with Pavel?
> > > >  
> > > 
> > > I'll take the hit.  He had his chance.
> > > 
> > > I'm happy to move forward with Andy's review.  
> > 
> > Thank you, Lee, much appreciated!
> > The patches (9..12) have my SoB, I think it should be enough, but
> > if you thinks they need my Rb tag, I can reply to them with it.  
> 
> That's okay.  I've applied them and they are currently in soak.

Very good news and thanks so much!

Henning

> > > (Side note: Seeing as Pavel hasn't been seen for 2 months, I'll
> > > also follow-up on  the LED ML to offer to become temporary
> > > maintainer for a bit)  
> > 
> > This is good news as well, because I noticed there are a few series
> > there stuck as well.  
> 
> Feel free to reply to object or in support:
> 
> https://lore.kernel.org/all/Ys%2Fkruf8DE4ISo8M@google.com/
>
Pavel Machek July 14, 2022, 11:26 a.m. UTC | #14
On Wed 2022-06-08 08:42:40, Lee Jones wrote:
> On Mon, 06 Jun 2022, Andy Shevchenko wrote:
> 
> > There are a few users that would like to utilize P2SB mechanism of hiding
> > and unhiding a device from the PCI configuration space.
> > 
> > Here is the series to consolidate p2sb handling code for existing users
> > and to provide a generic way for new comer(s).
> > 
> > It also includes a patch to enable GPIO controllers on Apollo Lake
> > when it's used with ABL bootloader w/o ACPI support.
> > 
> > The patch that brings the helper ("platform/x86/intel: Add Primary to
> > Sideband (P2SB) bridge support") has a commit message that sheds a light
> > on what the P2SB is and why this is needed.
> > 
> > I have tested this on Apollo Lake platform (I'm able to see SPI NOR and
> > since we have an ACPI device for GPIO I do not see any attempts to recreate
> > one).
> > 
> > The series is ready to be merged via MFD tree, but see below.
> > 
> > The series also includes updates for Simatic IPC drivers that partially
> > tagged by respective maintainers (the main question is if Pavel is okay
> > with the last three patches, since I believe Hans is okay with removing
> > some code under PDx86). Hence the first 8 patches can be merged right
> > away and the rest when Pavel does his review.
> 
> Can we just wait for Pavel's review, then merge them all at once?

10,12: Acked-by: Pavel Machek <pavel@ucw.cz>
								Pavel
Lee Jones July 14, 2022, 12:10 p.m. UTC | #15
On Thu, 14 Jul 2022, Pavel Machek wrote:

> On Wed 2022-06-08 08:42:40, Lee Jones wrote:
> > On Mon, 06 Jun 2022, Andy Shevchenko wrote:
> > 
> > > There are a few users that would like to utilize P2SB mechanism of hiding
> > > and unhiding a device from the PCI configuration space.
> > > 
> > > Here is the series to consolidate p2sb handling code for existing users
> > > and to provide a generic way for new comer(s).
> > > 
> > > It also includes a patch to enable GPIO controllers on Apollo Lake
> > > when it's used with ABL bootloader w/o ACPI support.
> > > 
> > > The patch that brings the helper ("platform/x86/intel: Add Primary to
> > > Sideband (P2SB) bridge support") has a commit message that sheds a light
> > > on what the P2SB is and why this is needed.
> > > 
> > > I have tested this on Apollo Lake platform (I'm able to see SPI NOR and
> > > since we have an ACPI device for GPIO I do not see any attempts to recreate
> > > one).
> > > 
> > > The series is ready to be merged via MFD tree, but see below.
> > > 
> > > The series also includes updates for Simatic IPC drivers that partially
> > > tagged by respective maintainers (the main question is if Pavel is okay
> > > with the last three patches, since I believe Hans is okay with removing
> > > some code under PDx86). Hence the first 8 patches can be merged right
> > > away and the rest when Pavel does his review.
> > 
> > Can we just wait for Pavel's review, then merge them all at once?
> 
> 10,12: Acked-by: Pavel Machek <pavel@ucw.cz>

Thanks Pavel.  I'll get that added.
Pavel Machek July 17, 2022, 10:27 a.m. UTC | #16
Hi!

> > > Can we just wait for Pavel's review, then merge them all at once?
> > 
> > 10,12: Acked-by: Pavel Machek <pavel@ucw.cz>
> 
> Thanks Pavel.  I'll get that added.

Thank you, sorry for the delays.

Best regards,
							Pavel
Andy Shevchenko July 18, 2022, 11:17 a.m. UTC | #17
On Mon, Jun 06, 2022 at 07:41:26PM +0300, Andy Shevchenko wrote:
> There are a few users that would like to utilize P2SB mechanism of hiding
> and unhiding a device from the PCI configuration space.
> 
> Here is the series to consolidate p2sb handling code for existing users
> and to provide a generic way for new comer(s).
> 
> It also includes a patch to enable GPIO controllers on Apollo Lake
> when it's used with ABL bootloader w/o ACPI support.
> 
> The patch that brings the helper ("platform/x86/intel: Add Primary to
> Sideband (P2SB) bridge support") has a commit message that sheds a light
> on what the P2SB is and why this is needed.
> 
> I have tested this on Apollo Lake platform (I'm able to see SPI NOR and
> since we have an ACPI device for GPIO I do not see any attempts to recreate
> one).
> 
> The series is ready to be merged via MFD tree, but see below.
> 
> The series also includes updates for Simatic IPC drivers that partially
> tagged by respective maintainers (the main question is if Pavel is okay
> with the last three patches, since I believe Hans is okay with removing
> some code under PDx86). Hence the first 8 patches can be merged right
> away and the rest when Pavel does his review.

Kernel test bot seems found an issue with dependencies, because selection
of P2SB is not enough.

There are two solutions that I can see now:
1) move P2SB out of X86_PLATFORM_DEVICES section (like PMC_ATOM);
2) add 'depends on X86_PLATFORM_DEVICES' to the affected drivers.

I think the first solution cleaner, because it would be strange to have
the dependency on the drivers that quite unlikely be on server platforms
(e.g. EDAC).

In long term perhaps something like drivers/platform/x86/lib which is for
platform libraries or so and independent on X86_PLATFORM_DEVICES?

I will send a fix soon as per 1) above, feel free to comment here or there.
Henning Schild Aug. 10, 2022, 7:38 a.m. UTC | #18
Am Mon, 18 Jul 2022 14:17:42 +0300
schrieb Andy Shevchenko <andriy.shevchenko@linux.intel.com>:

> On Mon, Jun 06, 2022 at 07:41:26PM +0300, Andy Shevchenko wrote:
> > There are a few users that would like to utilize P2SB mechanism of
> > hiding and unhiding a device from the PCI configuration space.
> > 
> > Here is the series to consolidate p2sb handling code for existing
> > users and to provide a generic way for new comer(s).
> > 
> > It also includes a patch to enable GPIO controllers on Apollo Lake
> > when it's used with ABL bootloader w/o ACPI support.
> > 
> > The patch that brings the helper ("platform/x86/intel: Add Primary
> > to Sideband (P2SB) bridge support") has a commit message that sheds
> > a light on what the P2SB is and why this is needed.
> > 
> > I have tested this on Apollo Lake platform (I'm able to see SPI NOR
> > and since we have an ACPI device for GPIO I do not see any attempts
> > to recreate one).
> > 
> > The series is ready to be merged via MFD tree, but see below.
> > 
> > The series also includes updates for Simatic IPC drivers that
> > partially tagged by respective maintainers (the main question is if
> > Pavel is okay with the last three patches, since I believe Hans is
> > okay with removing some code under PDx86). Hence the first 8
> > patches can be merged right away and the rest when Pavel does his
> > review.  
> 
> Kernel test bot seems found an issue with dependencies, because
> selection of P2SB is not enough.
> 
> There are two solutions that I can see now:
> 1) move P2SB out of X86_PLATFORM_DEVICES section (like PMC_ATOM);
> 2) add 'depends on X86_PLATFORM_DEVICES' to the affected drivers.
> 
> I think the first solution cleaner, because it would be strange to
> have the dependency on the drivers that quite unlikely be on server
> platforms (e.g. EDAC).
> 
> In long term perhaps something like drivers/platform/x86/lib which is
> for platform libraries or so and independent on X86_PLATFORM_DEVICES?
> 
> I will send a fix soon as per 1) above, feel free to comment here or
> there.

Hey Andy,

is that one on the way already? I meanwhile also found a possible
configuration issue in my patches you carry on top. And i suggest to
include or squash
[PATCH] leds: simatic-ipc-leds-gpio: make sure we have the GPIO
providing driver

in this series.

I am also working on adding more models which have GPIO based LEDs. All
the patches are based on this series because it is where i currently
introduce GPIO based LEDs for simatic. I would not want to change the
ordering but at the same time i would like to meet 5.20.

regards,
Henning