Re: [PATCH v1] thunderbolt: fix PCI device class after powering up

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

 



On Thu, Jul 28, 2022 at 03:16:08PM +0200, Lukasz Bartosik wrote:
> From: Łukasz Bartosik <lb@xxxxxxxxxxxx>
> 
> A thunderbolt
> lspci -d 8086:9a1b -vmmknn
> Slot:	00:0d.2
> Class:	System peripheral [0880]
> Vendor:	Intel Corporation [8086]
> Device:	Tiger Lake-LP Thunderbolt 4 NHI #0 [9a1b]
> 
> presents itself with PCI class 0x088000 after Chromebook boots.
> lspci -s 00:0d.2 -xxx
> 00:0d.2 System peripheral: Intel Corporation Tiger Lake-LP Thunderbolt 4
> NHI #0 (rev 01)
> 00: 86 80 1b 9a 00 00 10 00 01 00 80 08 00 00 00 00
> ...
> 
> However after thunderbolt is powered up in nhi_probe()
> its class changes to 0x0c0340
> lspci -s 00:0d.2 -xxx
> 00:0d.2 System peripheral: Intel Corporation Tiger Lake-LP Thunderbolt 4
> NHI #0 (rev 01)
> 00: 86 80 1b 9a 06 04 10 00 01 40 03 0c 00 00 00 00
> ...
> 
> which leaves pci_dev structure with old class value
> cat /sys/bus/pci/devices/0000:00:0d.2/class
> 0x088000
> 
> This fix updates PCI device class in pci_dev structure after
> thunderbolt is powered up.
> 
> Fixes: 3cdb9446a117 ("thunderbolt: Add support for Intel Ice Lake")
> Signed-off-by: Łukasz Bartosik <lb@xxxxxxxxxxxx>
> ---
>  drivers/thunderbolt/nhi_ops.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/thunderbolt/nhi_ops.c b/drivers/thunderbolt/nhi_ops.c
> index 96da07e88c52..6a343d7e3f90 100644
> --- a/drivers/thunderbolt/nhi_ops.c
> +++ b/drivers/thunderbolt/nhi_ops.c
> @@ -160,12 +160,17 @@ static int icl_nhi_suspend_noirq(struct tb_nhi *nhi, bool wakeup)
>  
>  static int icl_nhi_resume(struct tb_nhi *nhi)
>  {
> +	u32 class;
>  	int ret;
>  
>  	ret = icl_nhi_force_power(nhi, true);
>  	if (ret)
>  		return ret;
>  
> +	/* Set device class code as it might have changed after powering up */
> +	pci_read_config_dword(nhi->pdev, PCI_CLASS_REVISION, &class);
> +	nhi->pdev->class = class >> 8;

What about the revision field, why not set that as well:
	nhi->pdev->revision = class & 0xff;

If the value is overwritten for 3 of the bytes, why not the 4th?

Also this feels odd, what is changing the bytes here?  Why only the
class?  What else changed and what caused it?

thanks,

greg k-h



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux