Re: [PATCH v5 1/2] platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for the reply!

Den tors 4 jan. 2024 kl 09:41 skrev Shinichiro Kawasaki
<shinichiro.kawasaki@xxxxxxx>:
> Could you confirm that p2sb_bar() is not called during boot process on your
> system? Applying the one liner printk patch below, let's confirm that the
> string "p2sb_bar" does not appear in the dmesg log.
>
> diff --git a/drivers/platform/x86/p2sb.c b/drivers/platform/x86/p2sb.c
> index 99a0e456f075..e034a58d7531 100644
> --- a/drivers/platform/x86/p2sb.c
> +++ b/drivers/platform/x86/p2sb.c
> @@ -195,6 +195,7 @@ int p2sb_bar(struct pci_bus *bus, unsigned int devfn, struct resource *mem)
>         struct p2sb_res_cache *cache;
>         int ret;
>
> +       printk("%s\n", __func__);
>         bus = p2sb_get_bus(bus);
>         if (!bus)
>                 return -ENODEV;

p2sb_bar does indeed not appear in the kernel log with this patch
snippet applied.

> My mere idea was to just blacklist Intel CPUs with family != 6. If my guesses
> are all correct, following patch will avoid the failure on the reported system,
> since the system has CPU with family == 0xf. This will cover certain amount of
> old CPUs which should not access DEVFN 31:1 as P2SB. But family 6 started around
> 2006, then it is not the complete blacklist, probably. I will think about the
> better way.
>
> diff --git a/drivers/platform/x86/p2sb.c b/drivers/platform/x86/p2sb.c
> index 99a0e456f075..c9bcef8e2c4c 100644
> --- a/drivers/platform/x86/p2sb.c
> +++ b/drivers/platform/x86/p2sb.c
> @@ -46,6 +46,10 @@ static int p2sb_get_devfn(unsigned int *devfn)
>         unsigned int fn = P2SB_DEVFN_DEFAULT;
>         const struct x86_cpu_id *id;
>
> +       /* ICH/PCHs for old CPUs do not have P2SB */
> +       if (boot_cpu_data.x86 != 6)
> +               return -ENODEV;
> +
>         id = x86_match_cpu(p2sb_cpu_ids);
>         if (id)
>                 fn = (unsigned int)id->driver_data;

This patch snippet resolves the issue, at least in my use case.

Thanks,
Tested-by: Klara Modin <klarasmodin@xxxxxxxxx>

Attachment: dmesg-both-patches
Description: Binary data

Attachment: serial-first-patch
Description: Binary data


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux