public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Pecio <michal.pecio@gmail.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: <gregkh@linuxfoundation.org>, <linux-usb@vger.kernel.org>,
	"Rai Amardeep" <amardeep.rai@intel.com>
Subject: Re: [PATCH 23/23] usb: xhci: Add debugfs support for xHCI Port Link Info (PORTLI) register.
Date: Wed, 4 Mar 2026 10:42:44 +0100	[thread overview]
Message-ID: <20260304103856.48b785fd.michal.pecio@gmail.com> (raw)
In-Reply-To: <20251119142417.2820519-24-mathias.nyman@linux.intel.com>

On Wed, 19 Nov 2025 16:24:17 +0200, Mathias Nyman wrote:
> From: "Rai, Amardeep" <amardeep.rai@intel.com>
> 
> Each xHCI roothub port has a Port Link Info (PORTLI) register that is
> used by USB3 and eUSB2V2 ports.
> 
> USB3 ports show link error count, rx lane count, and tx lane count.
> 
> eUSB2V2 ports show Rx Data Rate (RDR) and Tx Data Rate (TDR).
> 
> Rx/Tx Data Rate is a multiple of USB2 2.0 HS 480 Mb/s data rates,
> and is only valid if a eUSB2V2 device is connected (CCS=1).
> 
> 0 = "USB 2.0 HS" normal HS 480 Mb/s, no eUSB2V2 in use
> 1 = "HS1" Assymetric eUSB2V2 where this direction runs normal 480Mb/s
> 2 = "HS2" 960Mb/s
> ...
> 10 = "HS10" 4.8 Gb/s, max eUSB2V2 rate
> 
> PORTLI is Reserved and preserve "RsvdP" for normal USB2 ports
> 
> Sample output of USB3 port PORTLI:
> cat /sys/kernel/debug/usb/xhci/0000:00:14.0/ports/port14/portli
> 0x00000000 LEC=0 RLC=0 TLC=0
> 
> Signed-off-by: Rai, Amardeep <amardeep.rai@intel.com>
> Co-developed-by: Mathias Nyman <mathias.nyman@linux.intel.com>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>

Hi,

This patch causes an oops when there are more port registers counted in
xhci->max_ports than ports reported by Supported Protocol capabilities.
On my HW it's due to max_ports being more than maximum port number, but
it seems that gaps between ports of different speeds are also possible.

> +static int xhci_portli_show(struct seq_file *s, void *unused)
> +{
> +	struct xhci_port	*port = s->private;
> +	struct xhci_hcd		*xhci = hcd_to_xhci(port->rhub->hcd);

In such cases port->rhub will be NULL so we can't reach xhci. One
obvious solution (which works for me) is an explicit NULL check here
and another seq_printf just for this case, followed by early return.

Or maybe not bother printing anything and just return?
Or make this check before creating the files in the first place?

> +	u32			portli;
> +
> +	portli = readl(&port->port_reg->portli);
> +
> +	/* PORTLI fields are valid if port is a USB3 or eUSB2V2 port */
> +	if (port->rhub == &xhci->usb3_rhub)
> +		seq_printf(s, "0x%08x LEC=%u RLC=%u TLC=%u\n", portli,
> +			   PORT_LEC(portli), PORT_RX_LANES(portli), PORT_TX_LANES(portli));
> +	else if (xhci->hcc_params2 & HCC2_E2V2C)
> +		seq_printf(s, "0x%08x RDR=%u TDR=%u\n", portli,
> +			   PORTLI_RDR(portli), PORTLI_TDR(portli));

Or I suppose we could alternatively use PORTSC to determine speed
and remove the dependency on hcc_params2 by always decoding eUSB2v2
fields whether the HW supports it or not. It's debugfs, who cares.

> +	else
> +		seq_printf(s, "0x%08x RsvdP\n", portli);
> +
> +	return 0;
> +}

Regards,
Michal

  reply	other threads:[~2026-03-04  9:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-19 14:23 [PATCH 00/23] xhci features for usb-next Mathias Nyman
2025-11-19 14:23 ` [PATCH 01/23] usb: xhci: limit run_graceperiod for only usb 3.0 devices Mathias Nyman
2025-11-19 14:23 ` [PATCH 02/23] xhci: Add helper to find trb from its dma address Mathias Nyman
2025-11-19 14:23 ` [PATCH 03/23] xhci: simplify and rework trb_in_td() Mathias Nyman
2025-11-19 14:23 ` [PATCH 04/23] usb: xhci: rework xhci_decode_portsc() Mathias Nyman
2025-11-19 14:23 ` [PATCH 05/23] usb: xhci: add tracing for PORTSC register writes Mathias Nyman
2025-11-19 14:24 ` [PATCH 06/23] usb: xhci: add helper to read PORTSC register Mathias Nyman
2025-11-19 14:24 ` [PATCH 07/23] usb: xhci: add USB Port Register Set struct Mathias Nyman
2025-11-19 14:24 ` [PATCH 08/23] usb: xhci: implement " Mathias Nyman
2025-11-19 14:24 ` [PATCH 09/23] usb: xhci: Assume that endpoints halt as specified Mathias Nyman
2025-11-19 14:24 ` [PATCH 10/23] usb: xhci: Don't unchain link TRBs on quirky HCs Mathias Nyman
2025-11-19 14:24 ` [PATCH 11/23] usb: xhci: replace use of system_wq with system_percpu_wq Mathias Nyman
2025-11-19 14:24 ` [PATCH 12/23] usb: xhci: remove deprecated TODO comment Mathias Nyman
2025-11-19 14:24 ` [PATCH 13/23] usb: xhci: remove unused trace operation and argument Mathias Nyman
2025-11-19 14:24 ` [PATCH 14/23] usb: xhci: use cached HCSPARAMS1 value Mathias Nyman
2025-11-19 14:24 ` [PATCH 15/23] usb: xhci: simplify handling of Structural Parameters 1 values Mathias Nyman
2025-11-19 14:24 ` [PATCH 16/23] usb: xhci: limit number of ports to 127 Mathias Nyman
2025-11-19 14:24 ` [PATCH 17/23] usb: xhci: limit number of interrupts to 128 Mathias Nyman
2025-11-19 14:24 ` [PATCH 18/23] usb: xhci: improve xhci-caps.h comments Mathias Nyman
2025-11-19 14:24 ` [PATCH 19/23] usb: xhci: simplify Isochronous Scheduling Threshold handling Mathias Nyman
2025-11-19 14:24 ` [PATCH 20/23] usb: xhci: simplify Max Scratchpad buffer macros Mathias Nyman
2025-11-19 14:24 ` [PATCH 21/23] usb: xhci: drop xhci-caps.h dependence on xhci-ext-caps.h Mathias Nyman
2025-11-19 14:24 ` [PATCH 22/23] usb: xhci: standardize single bit-field macros Mathias Nyman
2025-11-19 14:24 ` [PATCH 23/23] usb: xhci: Add debugfs support for xHCI Port Link Info (PORTLI) register Mathias Nyman
2026-03-04  9:42   ` Michal Pecio [this message]
2026-03-04 14:25     ` Mathias Nyman
2026-03-04 16:40       ` Michal Pecio

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=20260304103856.48b785fd.michal.pecio@gmail.com \
    --to=michal.pecio@gmail.com \
    --cc=amardeep.rai@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.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