From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Wolfram Sang <wsa@kernel.org>, Jean Delvare <jdelvare@suse.de>,
Heiner Kallweit <hkallweit1@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
Tan Jui Nee <jui.nee.tan@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Hans de Goede <hdegoede@redhat.com>, Kate Hsuan <hpa@redhat.com>,
Jonathan Yong <jonathan.yong@intel.com>,
linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-pci@vger.kernel.org, linux-gpio@vger.kernel.org,
platform-driver-x86@vger.kernel.org,
Jean Delvare <jdelvare@suse.com>,
Peter Tyser <ptyser@xes-inc.com>,
Andy Shevchenko <andy@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Mark Gross <markgross@kernel.org>,
Henning Schild <henning.schild@siemens.com>
Subject: Re: [PATCH v3 3/8] platform/x86/intel: Add Primary to Sideband (P2SB) bridge support
Date: Tue, 1 Feb 2022 20:52:22 +0200 [thread overview]
Message-ID: <YfmBZvQ28y/Mh60J@smile.fi.intel.com> (raw)
In-Reply-To: <20220201181401.GA292815@bhelgaas>
On Tue, Feb 01, 2022 at 12:14:01PM -0600, Bjorn Helgaas wrote:
> On Fri, Jan 28, 2022 at 08:30:20PM +0200, Andy Shevchenko wrote:
> > On Fri, Jan 07, 2022 at 11:11:08AM -0600, Bjorn Helgaas wrote:
> > > On Fri, Jan 07, 2022 at 04:56:42PM +0200, Andy Shevchenko wrote:
> >
> > ...
> >
> > > > The unhide/hide back has been tested and we have already users
> > > > in the kernel (they have other issues though with the PCI rescan
> > > > lock, but it doesn't mean it wasn't ever tested).
> > >
> > > Does the firmware team that hid this device sign off on the OS
> > > unhiding and using it? How do we know that BIOS is not using the
> > > device?
> >
> > BIOS might use the device via OperationRegion() in ACPI, but that
> > means that _CRS needs to have that region available. It seems not
> > the case.
> >
> > And as far I as see in the internal documentation the hide / unhide
> > approach is not forbidden for OS side.
>
> Unhiding is device-specific behavior, so generic PCI enumeration
> cannot use it. We have to know there's a P2SB device at some address
> before we can safely do a config write to it. PCI enumeration would
> learn there's a P2SB device at an address by reading a Vendor/Device
> ID.
>
> > > My point is that the unhide is architecturally messed up. The OS
> > > runs on the platform as described by ACPI. Devices that cannot be
> > > enumerated are described in the ACPI namespace.
> >
> > This device may or may not be _partially_ or _fully_ (due to being
> > multifunctional) described in ACPI. I agree, that ideally the
> > devices in question it has behind should be represented properly by
> > firmware. However, the firmwares in the wild for selected products
> > / devices don't do that. We need to solve (work around) it in the
> > software.
> >
> > This is already done for a few devices. This series consolidates
> > that and enables it for very known GPIO IPs.
>
> Consolidating the code to unhide the device and size the BAR is fine.
>
> I would prefer the PCI core to be involved as little as possible
> because we're violating some key assumptions and we could trip over
> those later. We're assuming the existence of P2SB based on the fact
> that we found some *other* device, we're assuming firmware isn't using
> P2SB (may be true now, but impossible to verify), we're assuming the
> P2SB BAR contains a valid address that's not used elsewhere but also
> won't be assigned to anything.
>
> > PCI core just provides a code that is very similar to what we need
> > here. Are you specifically suggesting that we have to copy'n'paste
> > that rather long function and maintain in parallel with PCI?
>
> I think we're talking about __pci_read_base(), which is currently an
> internal PCI interface. This series adds pci_bus_info/warn/etc(),
The patch that adds those macros is good on its own, if you think so...
I tried to submit it separately, but it was no response, so I don't know.
> reworks __pci_read_base() to operate on a struct pci_bus *, exports
> it, and uses it via #include <../../../pci/pci.h>.
Yes, which allows at least to have the same code, doing same things to be
in one copy in one place.
> __pci_read_base() is fairly long, but you apparently don't need all
> the functionality there because the core of the patch is this:
>
> - pci_bus_read_config_dword(bus, spi, PCI_BASE_ADDRESS_0,
> - &spi_base);
> - if (spi_base != ~0) {
> - res->start = spi_base & 0xfffffff0;
> - res->end = res->start + SPIBASE_APL_SZ - 1;
> - }
> + __pci_bus_read_base(bus, devfn, pci_bar_unknown, mem, PCI_BASE_ADDRESS_0, true)
You probably took the least pleasant (to me) example, because it's buggy in a
few ways:
- it misses 64-bit handling code
- it misses PCI rescan lock (in case PCI code decides to change addresses,
previously ones will be invalid, while other drivers may still use that
MMIO space
- it doesn't check if (for a new version Hans suggested me to add this check as
it's done in one out of 3 cases)
It also useful to have some messages to be printed just in cases of errors
or success in a standard (PCI core provided) way.
> I don't think it's worth all the __pci_read_base() changes to do that.
> What if you made a library function that looks like this?
>
> int p2sb_bar(...)
> {
> pci_bus_write_config_byte(bus, devfn_p2sb, P2SBC_HIDE_BYTE, 0);
> pci_bus_read_config_dword(bus, devfn, PCI_BASE_ADDRESS_0, &orig);
> if (orig) {
> pci_bus_write_config_dword(bus, devfn, PCI_BASE_ADDRESS_0, ~0);
> pci_bus_read_config_dword(bus, devfn, PCI_BASE_ADDRESS_0, &val);
> pci_bus_write_config_dword(bus, devfn, PCI_BASE_ADDRESS_0, orig);
> res->start = orig;
> res->end = res->start + (~val + 1);
> }
> pci_bus_write_config_byte(bus, devfn, P2SBC_HIDE_BYTE, P2SBC_HIDE_BIT);
> }
It seems simple, but with the above mentioned adjustments, it will become
closer to the size of the original __pci_read_base().
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2022-02-01 18:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-21 18:15 [PATCH v3 0/8] platform/x86: introduce p2sb_bar() helper Andy Shevchenko
2021-12-21 18:15 ` [PATCH v3 1/8] PCI: Introduce pci_bus_*() printing macros when device is not available Andy Shevchenko
2021-12-21 18:15 ` [PATCH v3 2/8] PCI: Convert __pci_read_base() to __pci_bus_read_base() Andy Shevchenko
2021-12-21 18:15 ` [PATCH v3 3/8] platform/x86/intel: Add Primary to Sideband (P2SB) bridge support Andy Shevchenko
2022-01-07 1:03 ` Bjorn Helgaas
2022-01-07 14:56 ` Andy Shevchenko
2022-01-07 17:11 ` Bjorn Helgaas
2022-01-28 18:30 ` Andy Shevchenko
2022-02-01 18:14 ` Bjorn Helgaas
2022-02-01 18:52 ` Andy Shevchenko [this message]
2022-02-02 20:36 ` Bjorn Helgaas
2021-12-21 18:15 ` [PATCH v3 4/8] pinctrl: intel: Check against matching data instead of ACPI companion Andy Shevchenko
2021-12-27 6:48 ` Mika Westerberg
2021-12-21 18:15 ` [PATCH v3 5/8] mfd: lpc_ich: Factor out lpc_ich_enable_spi_write() Andy Shevchenko
2021-12-21 18:15 ` [PATCH v3 6/8] mfd: lpc_ich: Switch to generic p2sb_bar() Andy Shevchenko
2021-12-21 18:15 ` [PATCH v3 7/8] mfd: lpc_ich: Add support for pinctrl in non-ACPI system Andy Shevchenko
2022-01-28 20:01 ` Andy Shevchenko
2021-12-21 18:15 ` [PATCH v3 8/8] i2c: i801: convert to use common P2SB accessor Andy Shevchenko
2022-01-28 20:00 ` Andy Shevchenko
2021-12-22 2:48 ` [PATCH v3 0/8] platform/x86: introduce p2sb_bar() helper Linus Walleij
2021-12-22 11:13 ` Andy Shevchenko
2021-12-23 15:54 ` Andy Shevchenko
2021-12-23 17:00 ` Hans de Goede
2021-12-23 17:02 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YfmBZvQ28y/Mh60J@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=andy@kernel.org \
--cc=bhelgaas@google.com \
--cc=hdegoede@redhat.com \
--cc=helgaas@kernel.org \
--cc=henning.schild@siemens.com \
--cc=hkallweit1@gmail.com \
--cc=hpa@redhat.com \
--cc=jdelvare@suse.com \
--cc=jdelvare@suse.de \
--cc=jonathan.yong@intel.com \
--cc=jui.nee.tan@intel.com \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=markgross@kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=ptyser@xes-inc.com \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).