| Message ID | 20220606164138.66535-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | platform/x86: introduce p2sb_bar() helper | expand |
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
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?
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.
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?
+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/
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/ >
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/ >
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/ > >
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/ > > > > > >
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)
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.
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/
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/ >
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
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.
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
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.
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
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