[U-Boot] [PATCH 1/4] usb: xhci: Set accurate add context flags when updating hub attributes

[U-Boot] [PATCH 1/4] usb: xhci: Set accurate add context flags when updating hub attributes

[Bin Meng]

If a USB 3.0 hub is plugged into the root port of the xHC, the xHCI
driver will issue a 'Configure Endpoint' command to the xHC for it
to update its internal data structure for this hub device. The hub
attributes are in the slot context so we need tell xHC to update the
slot context by setting the add context flags of the input control
context to only cover the slot context.

At present the add context flags is or'ed with the slot context bit,
but it should really be accurately set to the slot context, as the
variable that holds the value of the add context flags comes from
whatever was set in the last command execution, which may contain
additional contexts that 'Configure Endpoint' command should not
touch. Some xHC implementations like x86 don't complain such, but
it was observed on Renesas RCar Gen3 platform that the RCar xHC
complains with a 'TRB error' completion codes as the response.

Reported-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Tested-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
---

 drivers/usb/host/xhci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3adb002..565948c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1424,7 +1424,7 @@ static int xhci_update_hub_device(struct udevice *dev, struct usb_device *udev)
 
 	ctrl_ctx = xhci_get_input_control_ctx(in_ctx);
 	/* Initialize the input context control */
-	ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG);
+	ctrl_ctx->add_flags = cpu_to_le32(SLOT_FLAG);
 	ctrl_ctx->drop_flags = 0;
 
 	xhci_inval_cache((uintptr_t)out_ctx->bytes, out_ctx->size);
-- 
2.7.4

[U-Boot] [PATCH 2/4] usb: xhci: Initialize dev_state to 0 in the input slot context

[Bin Meng]

Per xHCI spec chapter 6.2.2 table 6-7, as input, software shall
initialize the dev_state field to '0'. Though this does not seem
to cause any issue with most xHC implementations, let's do this
to conform with the spec.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Tested-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
---

 drivers/usb/host/xhci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 565948c..8c1126e 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1452,6 +1452,7 @@ static int xhci_update_hub_device(struct udevice *dev, struct usb_device *udev)
 		think_time = (think_time / 666) - 1;
 	if (udev->speed == USB_SPEED_HIGH)
 		slot_ctx->tt_info |= cpu_to_le32(TT_THINK_TIME(think_time));
+	slot_ctx->dev_state = 0;
 
 	return xhci_configure_endpoints(udev, false);
 }
-- 
2.7.4

[U-Boot] [PATCH 3/4] usb: xhci: Fix config fail of FS hub behind a HS hub with MTT

[Bin Meng]

If a full speed hub connects to a high speed hub which supports MTT,
the MTT field of its slot context will be set to 1 when xHCI driver
setups an xHCI virtual device in xhci_setup_addressable_virt_dev().
Once usb core fetch its hub descriptor, and need to update the xHC's
internal data structures for the device, the HUB field of its slot
context will be set to 1 too, meanwhile MTT is also set before, this
will cause configure endpoint command fail. In the case, we should
clear MTT to 0 for full speed hub according to section 6.2.2.

This keeps in sync with Linux kernel commit:
  096b110: usb: xhci: fix config fail of FS hub behind a HS hub with MTT

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/usb/host/xhci.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 8c1126e..f9c6bbb 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1435,8 +1435,15 @@ static int xhci_update_hub_device(struct udevice *dev, struct usb_device *udev)
 
 	/* Update hub related fields */
 	slot_ctx->dev_info |= cpu_to_le32(DEV_HUB);
-	if (hub->tt.multi && udev->speed == USB_SPEED_HIGH)
+	/*
+	 * refer to section 6.2.2: MTT should be 0 for full speed hub,
+	 * but it may be already set to 1 when setup an xHCI virtual
+	 * device, so clear it anyway.
+	 */
+	if (hub->tt.multi)
 		slot_ctx->dev_info |= cpu_to_le32(DEV_MTT);
+	else if (udev->speed == USB_SPEED_FULL)
+		slot_ctx->dev_info &= cpu_to_le32(~DEV_MTT);
 	slot_ctx->dev_info2 |= cpu_to_le32(XHCI_MAX_PORTS(udev->maxchild));
 	/*
 	 * Set TT think time - convert from ns to FS bit times.
-- 
2.7.4

[U-Boot] [PATCH 4/4] usb: xhci: Handle endianness in xhci_set_configuration()

[Bin Meng]

In xhci_set_configuration(), 'Context Entries' field in the slot
context was cleared with mask LAST_CTX_MASK, but it should have
taken the endianness into consideration.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/usb/host/xhci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index f9c6bbb..9ded14c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -536,7 +536,7 @@ static int xhci_set_configuration(struct usb_device *udev)
 	/* slot context */
 	xhci_slot_copy(ctrl, in_ctx, out_ctx);
 	slot_ctx = xhci_get_slot_ctx(ctrl, in_ctx);
-	slot_ctx->dev_info &= ~(LAST_CTX_MASK);
+	slot_ctx->dev_info &= ~(cpu_to_le32(LAST_CTX_MASK));
 	slot_ctx->dev_info |= cpu_to_le32(LAST_CTX(max_ep_flag + 1) | 0);
 
 	xhci_endpoint_copy(ctrl, in_ctx, out_ctx, 0);
-- 
2.7.4

[U-Boot] [PATCH 1/4] usb: xhci: Set accurate add context flags when updating hub attributes

[Marek Vasut]

On 05/24/2018 08:40 AM, Bin Meng wrote:
> If a USB 3.0 hub is plugged into the root port of the xHC, the xHCI
> driver will issue a 'Configure Endpoint' command to the xHC for it
> to update its internal data structure for this hub device. The hub
> attributes are in the slot context so we need tell xHC to update the
> slot context by setting the add context flags of the input control
> context to only cover the slot context.
> 
> At present the add context flags is or'ed with the slot context bit,
> but it should really be accurately set to the slot context, as the
> variable that holds the value of the add context flags comes from
> whatever was set in the last command execution, which may contain
> additional contexts that 'Configure Endpoint' command should not
> touch. Some xHC implementations like x86 don't complain such, but
> it was observed on Renesas RCar Gen3 platform that the RCar xHC
> complains with a 'TRB error' completion codes as the response.
> 
> Reported-by: Marek Vasut <marek.vasut@gmail.com>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> Tested-by: Marek Vasut <marek.vasut@gmail.com>
> Tested-by: Matthias Blankertz <matthias.blankertz@cetitec.com>

Applied all, thanks!

-- 
Best regards,
Marek Vasut