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

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

 



Hi,

On Tue, Aug 02, 2022 at 05:06:40PM +0200, Łukasz Bartosik wrote:
> > Is this something available for purchase? I'm asking because I have Acer
> > Tiger Lake based Chromebook (740 spin or something) here and the TBT
> > controller class is "USB controller" all the time, and this is what is
> > expected. It should not change the class at any point.
> 
> Sorry this platform is not available on the market.

I don't think the mainline Linux needs to have this kind of a quirk for
a device that is not available for general public.

> I compared the platform where I see the issue with another platform
> where thunderbolt is "usb controller" all the time
> and I noticed one difference in function icl_nhi_force_power() in
> drivers/thunderbolt/nhi_ops.c I observed the value of VS_CAP_22
> after being read and before being written again with additional bits
> set. And on the platform where thunderbolt is "usb controller" all the
> time
> this value was 0x22061002 after reading and 0x22061002 before being
> written. The value has not changed
> which suggest that thunderbolt was already powered up during probe.

It is being set also if you boot with device connected but in any case
the class code should not change ever. It may be that this is some older
spin of the Tiger Lake silicon that still had the wrong class but it got
fixed in later spins (or firmware, I don't remember which).



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

  Powered by Linux