From: "Łukasz Bartosik" <lb@semihalf.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andreas Noever <andreas.noever@gmail.com>,
Michael Jamet <michael.jamet@intel.com>,
Yehezkel Bernat <YehezkelShB@gmail.com>,
linux-usb@vger.kernel.org, upstream@semihalf.com
Subject: Re: [PATCH v2] thunderbolt: fix PCI device class after powering up
Date: Wed, 3 Aug 2022 11:30:09 +0200 [thread overview]
Message-ID: <CAK8ByeK=xOGshi9Yk2C3eVVNYprYFejX53OQzAztuxrKNK7F9A@mail.gmail.com> (raw)
In-Reply-To: <YuoyBf20gNLNqYdC@lahna>
>
> 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).
next prev parent reply other threads:[~2022-08-03 9:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-29 9:40 [PATCH v2] thunderbolt: fix PCI device class after powering up Łukasz Bartosik
2022-08-01 10:24 ` Mika Westerberg
2022-08-02 12:27 ` Łukasz Bartosik
2022-08-02 13:07 ` Mika Westerberg
2022-08-02 15:06 ` Łukasz Bartosik
2022-08-03 8:29 ` Mika Westerberg
2022-08-03 9:30 ` Łukasz Bartosik [this message]
2022-08-03 9:46 ` Mika Westerberg
2022-08-03 10:41 ` Łukasz Bartosik
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='CAK8ByeK=xOGshi9Yk2C3eVVNYprYFejX53OQzAztuxrKNK7F9A@mail.gmail.com' \
--to=lb@semihalf.com \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
--cc=michael.jamet@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=upstream@semihalf.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.