Message ID | 20211221181526.53798-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
---|---|
Headers | show |
Series | platform/x86: introduce p2sb_bar() helper | expand |
On Tue, Dec 21, 2021 at 7:21 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > Please, comment on the approach and individual patches. This approach looks reasonable to me so FWIW: Acked-by: Linus Walleij <linus.walleij@linaro.org> for the series. Yours, Linus Walleij
On Wed, Dec 22, 2021 at 03:48:15AM +0100, Linus Walleij wrote: > On Tue, Dec 21, 2021 at 7:21 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > Please, comment on the approach and individual patches. > > This approach looks reasonable to me so FWIW: > Acked-by: Linus Walleij <linus.walleij@linaro.org> > for the series. Thank you!
On Tue, Dec 21, 2021 at 08:15:18PM +0200, Andy Shevchenko wrote: > There are a few users and at least one more is coming that would > like to utilize P2SB mechanism of hiding and unhiding a device from > the PCI configuration space. > > Here is the series to deduplicate existing users and provide > a generic way for new comers. > > 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 bring 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. > > Please, comment on the approach and individual patches. > > The changes made in v2 do not change the main idea and the functionality > in a big scale. What we need is probably one more (RE-)test done by Henning. > I hope to have it merged to v5.17-rc1 that Siemens can develop their changes > based on this series. > > 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). > > (Since it's cross subsystem, the PDx86 seems the main one and > I think it makes sense to route it throught it with immutable > tag or branch provided for the others). > > Bjorn, are you okay with this approach and the commit message in the main > patch? > > 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) I'm going to be on vacation till 2022-01-03, I'll address comments if any during the first week of January and I hope it can make v5.17. Hans, what do you think? (Meanwhile I'm expecting that my patch to fix dependencies will be applied, so kbuild bot won't complain anymore on them being broken)
Hi, On 12/21/21 19:15, Andy Shevchenko wrote: > There are a few users and at least one more is coming that would > like to utilize P2SB mechanism of hiding and unhiding a device from > the PCI configuration space. > > Here is the series to deduplicate existing users and provide > a generic way for new comers. > > 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 bring 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. > > Please, comment on the approach and individual patches. > > The changes made in v2 do not change the main idea and the functionality > in a big scale. What we need is probably one more (RE-)test done by Henning. > I hope to have it merged to v5.17-rc1 that Siemens can develop their changes > based on this series. > > 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). > > (Since it's cross subsystem, the PDx86 seems the main one and > I think it makes sense to route it throught it with immutable > tag or branch provided for the others). The series looks good to me: Acked-by: Hans de Goede <hdegoede@redhat.com> For the series. Not sure if this is really 5.17 material this late in the cycle though, but lets wait and see what Bjorn and Lee have to say (patch 8/8 still needs an ack from Lee). I'm fine with taking this upstream through the pdx86 tree, please prepare a pull-req for everyone involved with an immutable branch pushed to pdx86/platform-drivers-x86.git/ based on 5.16-rc1 (if everyone is happy with merging this for 5.17) or based on 5.17-rc1 once that is out. Regards, Hans
Hi, On 12/23/21 18:00, Hans de Goede wrote: > Hi, > > On 12/21/21 19:15, Andy Shevchenko wrote: >> There are a few users and at least one more is coming that would >> like to utilize P2SB mechanism of hiding and unhiding a device from >> the PCI configuration space. >> >> Here is the series to deduplicate existing users and provide >> a generic way for new comers. >> >> 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 bring 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. >> >> Please, comment on the approach and individual patches. >> >> The changes made in v2 do not change the main idea and the functionality >> in a big scale. What we need is probably one more (RE-)test done by Henning. >> I hope to have it merged to v5.17-rc1 that Siemens can develop their changes >> based on this series. >> >> 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). >> >> (Since it's cross subsystem, the PDx86 seems the main one and >> I think it makes sense to route it throught it with immutable >> tag or branch provided for the others). > > The series looks good to me: > > Acked-by: Hans de Goede <hdegoede@redhat.com> > > For the series. > > Not sure if this is really 5.17 material this late in the cycle though, > but lets wait and see what Bjorn and Lee have to say (patch 8/8 still > needs an ack from Lee). Correction I just realized that that would be 7/8 that needs an ack from Lee and that 8/8 needs an ack from Wolfram. > I'm fine with taking this upstream through the pdx86 tree, please > prepare a pull-req for everyone involved with an immutable branch > pushed to pdx86/platform-drivers-x86.git/ > based on 5.16-rc1 (if everyone is happy with merging this for 5.17) or > based on 5.17-rc1 once that is out. Regards, Hans