linux-kernel - Re: [PATCH] xhci: Make debug message consistent with bus and port number

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 8 Jun 2020 11:57:57 +0800
From:   Kai-Heng Feng <kai.heng.feng@...onical.com>
To:     Mathias Nyman <mathias.nyman@...ux.intel.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        mathias.nyman@...el.com,
        "open list:USB XHCI DRIVER" <linux-usb@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] xhci: Make debug message consistent with bus and port
 number



> On May 7, 2020, at 18:35, Mathias Nyman <mathias.nyman@...ux.intel.com> wrote:
> 
> On 7.5.2020 11.21, Greg Kroah-Hartman wrote:
>> On Thu, May 07, 2020 at 03:58:36PM +0800, Kai-Heng Feng wrote:
>>> 
>>> 
>>>> On May 7, 2020, at 15:31, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
>>>> 
>>>> On Thu, May 07, 2020 at 03:15:01PM +0800, Kai-Heng Feng wrote:
>>>>> 
>>>>> 
>>>>>> On May 7, 2020, at 14:45, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
>>>>>> 
>>>>>> On Thu, May 07, 2020 at 02:17:55PM +0800, Kai-Heng Feng wrote:
>>>>>>> Current xhci debug message doesn't always output bus number, so it's
>>>>>>> hard to figure out it's from USB2 or USB3 root hub.
>>>>>>> 
>>>>>>> In addition to that, some port numbers are offset to 0 and others are
>>>>>>> offset to 1. Use the latter to match the USB core.
>>>>>>> 
>>>>>>> So use "bus number - port index + 1" to make debug message consistent.
>>>>>>> 
>>>>>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
>>>>>>> ---
>>>>>>> drivers/usb/host/xhci-hub.c | 41 +++++++++++++++++++++----------------
>>>>>>> 1 file changed, 23 insertions(+), 18 deletions(-)
>>>>>>> 
>>>>>>> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
>>>>>>> index f37316d2c8fa..83088c262cc4 100644
>>>>>>> --- a/drivers/usb/host/xhci-hub.c
>>>>>>> +++ b/drivers/usb/host/xhci-hub.c
>>>>>>> @@ -1241,7 +1241,8 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
>>>>>>> 			temp = readl(ports[wIndex]->addr);
>>>>>>> 			/* Disable port */
>>>>>>> 			if (link_state == USB_SS_PORT_LS_SS_DISABLED) {
>>>>>>> -				xhci_dbg(xhci, "Disable port %d\n", wIndex);
>>>>>>> +				xhci_dbg(xhci, "Disable port %d-%d\n",
>>>>>>> +					 hcd->self.busnum, wIndex + 1);
>>>>>> 
>>>>>> Shouldn't xhci_dbg() show the bus number already?  
>>>>> 
>>>>> It's the PCI bus number, different to USB2/USB3 root hub bus number...
>>>> 
>>>> But if this is using dev_dbg(), and it is, then you know how to look
>>>> that up by seeing where that device is in sysfs at that point in time.
>>>> 
>>>> So why add this again?
>>> 
>>> xHCI has two HCD, one for USB2 and one for USB3.
>>> If both of their port with same number are in use, for instance, port 1, then they are port 1-1 and port 2-1.
>>> Right now the debug message only show "Port 1", we still can't find the corresponding port via sysfs with insufficient info.
>> 
>> Look at the full kernel log line, the xhci hcd device should be showing
>> you unique information.  If not, something else is wrong.
>> 
> 
> What Kai-Heng suggest here makes sense, and is useful.
> We use similar style debugging in other places, and it is helpful as it matches
> usb core debugging style.
> 
> This might seem odd but reason is that the xHC controller is one device which
> doesn't really separate USB2 and USB3.
> All ports are for example in one long array.
> 
> On the xhci driver side things look very different. We register two HCD's,
> one for usb 2 and one for USB 3. In many cases the debugging is not tied to a HCD
> in any way,  (starting, stopping controller, command completion interrupts etc),
> other cases the debugging is very much tied to a specific hcd,
> for example when we are handling a port requsts for the roothub.

A gentle ping...

> 
> Thanks
> -Mathias