The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Konrad Dybcio <konradybcio@kernel.org>,
	Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mathias Nyman <mathias.nyman@intel.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"usb4-upstream@oss.qualcomm.com" <usb4-upstream@oss.qualcomm.com>,
	Raghavendra Thoorpu <rthoorpu@qti.qualcomm.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Sven Peter <sven@kernel.org>
Subject: Re: [PATCH v2 0/4] DWC3 link tunneling state reporting
Date: Wed, 22 Jul 2026 23:07:05 +0000	[thread overview]
Message-ID: <amFLpbtdT9MCwPIf@vbox> (raw)
In-Reply-To: <42b1c982-410f-44f9-84ec-40d042bef1cb@oss.qualcomm.com>

On Wed, Jul 15, 2026, Konrad Dybcio wrote:
> On 7/15/26 2:29 PM, 'Konrad Dybcio' via USB4 - Upstream wrote:
> > Currently, retrieving the tunneled/native state of a running port is
> > only possible on Intel XHCI hosts. This series extends that to CIO-
> > capable DWC31 controllers (see [1]).
> > 
> > Note that this patchset only results in the correct udev->tunnel_mode
> > value being assigned. Creating the device links (which requires this
> > information) between the USB4 router and the USB3 controller does not
> > currently take place on DT-based platforms, but that will be amended
> > in a follow-up patchset.
> > 
> > Tested on a Qualcomm X1E80100 CRD board, with a (currently) out-of-tree
> > set of drivers.
> > 
> > [1] I'm not entirely sure about the DWC version range (particularly
> >     wrt DWC32 and newer), so I limited it to a reasonable subset. I'll
> >     happily amend that.
> > 
> > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > ---
> > Changes in v2:
> > - Add handling for XHCI v1.2's USB3 tunneling and PORTSC.TM for
> >   platforms that advertise it (!!! UNTESTED !!!, I have no access to
> >   HW that exposes this)
> > - Prefer the aforementioned cap over custom implementations
> > - Bail out of the DWC3-specific check if `usb4-host-interface` device
> >   property is absent - hence this now depends on:
> >   https://urldefense.com/v3/__https://github.com/devicetree-org/dt-schema/pull/196__;!!A4F2R9G_pg!Yp4eQxr_V48OU-fhHIAT1pJrvhKI2VbT19cN4M-3EHIA5K9G57Npd31Hs5MLCPneAJ3pxM3JzzaQ7Mc_8sTGV7KEa_bieEilDA$ 
> > 
> > - Link to v1: https://urldefense.com/v3/__https://patch.msgid.link/20260505-topic-dwc3_tunneling_state-v1-0-4aaa6c3c14cb@oss.qualcomm.com__;!!A4F2R9G_pg!Yp4eQxr_V48OU-fhHIAT1pJrvhKI2VbT19cN4M-3EHIA5K9G57Npd31Hs5MLCPneAJ3pxM3JzzaQ7Mc_8sTGV7KEa_bYNq9e3w$ 
> 
> +Cc Sven sorry, I forgot to include you..
> 
> Konrad

Thank you for the patch series!

Don't worry about the DWC32 version range. Newer controllers should
follow the xhci v1.2 spec. We can always apply fixes later as needed.

Thanks,
Thinh

ps. I'll be out of office tomorrow until 7/31. My response may be
delayed.

      reply	other threads:[~2026-07-22 23:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 12:29 [PATCH v2 0/4] DWC3 link tunneling state reporting Konrad Dybcio
2026-07-15 12:29 ` [PATCH v2 1/4] usb: xhci: debugfs: Expose the USB3 tunneling ext_cap register value Konrad Dybcio
2026-07-15 12:29 ` [PATCH v2 2/4] usb: xhci: Honor PORTSC.TM if valid Konrad Dybcio
2026-07-22 22:57   ` Thinh Nguyen
2026-07-15 12:29 ` [PATCH v2 3/4] usb: xhci: Allow custom op for usb_link_tunnel_mode reporting Konrad Dybcio
2026-07-22 22:37   ` Thinh Nguyen
2026-07-15 12:29 ` [PATCH v2 4/4] usb: dwc3: Notify XHCI core of tunneled status Konrad Dybcio
2026-07-22 23:01   ` Thinh Nguyen
2026-07-15 12:58 ` [PATCH v2 0/4] DWC3 link tunneling state reporting Konrad Dybcio
2026-07-22 23:07   ` Thinh Nguyen [this message]

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=amFLpbtdT9MCwPIf@vbox \
    --to=thinh.nguyen@synopsys.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rthoorpu@qti.qualcomm.com \
    --cc=sven@kernel.org \
    --cc=usb4-upstream@oss.qualcomm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox