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.
>

The reference Chromebook platform is not available on the market now
however there will be Chromebooks based on that platform available for
purchase in the future.
We'd prefer not to carry a private patch for this issue.

Thanks,
Lukasz

> > 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