All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel Walker (danielwa)" <danielwa@cisco.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: "Shinichiro Kawasaki" <shinichiro.kawasaki@wdc.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Ilpo J�rvinen" <ilpo.jarvinen@linux.intel.com>,
	"Klara Modin" <klarasmodin@gmail.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Danil Rybakov" <danilrybakov249@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xe-linux-external(mailer list)" <xe-linux-external@cisco.com>
Subject: Re: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe
Date: Tue, 19 Nov 2024 20:51:00 +0000	[thread overview]
Message-ID: <Zzz6M9y+X/o39f7N@goliath> (raw)
In-Reply-To: <fbe53f25-2cce-4c1d-bace-e7976c4ba20c@redhat.com>

On Tue, Nov 19, 2024 at 07:28:16PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 19-Nov-24 3:20 AM, Shinichiro Kawasaki wrote:
> > On Nov 18, 2024 / 17:15, Daniel Walker (danielwa) wrote:
> >> On Mon, Nov 18, 2024 at 05:00:52PM +0100, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 18-Nov-24 4:55 PM, Andy Shevchenko wrote:
> > [...]
> >>>> Hans, there will be no need to fix anything if they implement correct access
> >>>> to the GPIO, i.e. via driver and board code with GPIO lookup tables.
> >>>
> >>> Agreed, still I'm not sure how I feel about us hiding the previously unhidden P2SB.
> >>>
> >>> OTOH I guess it may have only been unhidden in the BIOS to make the hack they
> >>> are using possible in the first place.
> >>
> >> From a flexibility POV I would suggest if you can not hide it if it's not already
> >> hidden by the BIOS that would be better since some company may have a good
> >> reason to make a custom driver or to export the pci device to userspace thru
> >> UIO. The current situation is you can't make a custom driver if p2sb is enable
> >> with this additional patch even if you unhide the device inside the BIOS.
> >>
> >> In our case it seems like we could use the already existing solution with
> >> pinctrl, but others may not be able to do that or may not want to for different
> >> reasons.
> > 
> > I don't have strong opinion about the choice, but I wonder how the p2sb code
> > will be if we keep the unhidden P2SB. I created a trial patch below. If the
> > device is not hidden, it does not call pci_scan_single_device() and
> > pci_stop_and_remove_bus_device(). Instead, it calls pci_get_slot() and
> > pci_dev_put(). I don't have the environment which unhides P2SB. Daniel, if you
> > have time to afford, please try it out.
> 
> Thank you for looking into this.
> 
> Daniel can you give this a try? It should fix the regression you are seeing
> without needing to rework your code (reworking your code to be cleaner
> might still be a good idea though).
> 

The patch restores the device 8086:19dd back to lspci which is the pre commit
5913320eb behavior. So I would say it's working on my system.

Daniel

  reply	other threads:[~2024-11-19 20:51 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-13 15:42 platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe Daniel Walker (danielwa)
2024-11-13 16:24 ` Hans de Goede
2024-11-13 16:33   ` Hans de Goede
2024-11-13 16:38     ` Hans de Goede
2024-11-13 17:19       ` Daniel Walker (danielwa)
2024-11-13 17:04     ` Hans de Goede
2024-11-13 17:41       ` Daniel Walker (danielwa)
2024-11-13 18:34         ` Hans de Goede
2024-11-15 11:35           ` Shinichiro Kawasaki
2024-11-15 14:57             ` Daniel Walker (danielwa)
2024-11-18 11:30               ` Shinichiro Kawasaki
2024-11-18 11:42                 ` Hans de Goede
2024-11-18 12:14                   ` Andy Shevchenko
2024-11-18 12:40                 ` Daniel Walker (danielwa)
2024-11-18 13:24                   ` Andy Shevchenko
2024-11-18 13:29                     ` Hans de Goede
2024-11-18 13:52                       ` Andy Shevchenko
2024-11-18 13:32                     ` Daniel Walker (danielwa)
2024-11-18 13:49                       ` Andy Shevchenko
2024-11-18 14:35                         ` Daniel Walker (danielwa)
2024-11-18 15:55                           ` Andy Shevchenko
2024-11-18 16:00                             ` Hans de Goede
2024-11-18 16:08                               ` Andy Shevchenko
2024-11-18 17:15                               ` Daniel Walker (danielwa)
2024-11-19  2:20                                 ` Shinichiro Kawasaki
2024-11-19  9:37                                   ` Andy Shevchenko
2024-11-20  4:03                                     ` Shinichiro Kawasaki
2024-11-19 18:28                                   ` Hans de Goede
2024-11-19 20:51                                     ` Daniel Walker (danielwa) [this message]
2024-11-20  7:06                                     ` Shinichiro Kawasaki
2024-11-19  9:41                                 ` Andy Shevchenko
2024-11-19 14:47                                   ` Daniel Walker (danielwa)
2024-11-19 15:03                                     ` Andy Shevchenko
2024-11-13 19:17     ` Andy Shevchenko
2024-11-16 11:34       ` Hans de Goede
2024-11-18 10:05         ` Andy Shevchenko

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=Zzz6M9y+X/o39f7N@goliath \
    --to=danielwa@cisco.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=danilrybakov249@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=klarasmodin@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shinichiro.kawasaki@wdc.com \
    --cc=xe-linux-external@cisco.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.