Use the Interval value from isoc/intr endpoint descriptor, no need
minus one. The original code doesn't cause transfer error for
normal cases, but it may have side effect with respond time of ERDY
or tPingTimeout.
Signed-off-by: Chunfeng Yun <[email protected]>
---
v2: modify commit message to explain more about the issue to be fixed
---
drivers/usb/mtu3/mtu3_gadget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index a9a65b4bbfed..c51be015345b 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -77,7 +77,7 @@ static int mtu3_ep_enable(struct mtu3_ep *mep)
if (usb_endpoint_xfer_int(desc) ||
usb_endpoint_xfer_isoc(desc)) {
interval = desc->bInterval;
- interval = clamp_val(interval, 1, 16) - 1;
+ interval = clamp_val(interval, 1, 16);
if (usb_endpoint_xfer_isoc(desc) && comp_desc)
mult = comp_desc->bmAttributes;
}
@@ -89,7 +89,7 @@ static int mtu3_ep_enable(struct mtu3_ep *mep)
if (usb_endpoint_xfer_isoc(desc) ||
usb_endpoint_xfer_int(desc)) {
interval = desc->bInterval;
- interval = clamp_val(interval, 1, 16) - 1;
+ interval = clamp_val(interval, 1, 16);
mult = usb_endpoint_maxp_mult(desc) - 1;
}
break;
--
2.18.0
There is a seldom issue that the controller access invalid address
and trigger devapc or emimpu violation. That is due to memory access
is out of order and cause gpd data is not correct.
Add mb() to prohibit compiler or cpu from reordering to make sure GPD
is fully written before setting its HWO.
Fixes: 48e0d3735aa5 ("usb: mtu3: supports new QMU format")
Cc: [email protected]
Reported-by: Eddie Hung <[email protected]>
Signed-off-by: Chunfeng Yun <[email protected]>
---
v2: modify misleading comment and commit message
---
drivers/usb/mtu3/mtu3_qmu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_qmu.c b/drivers/usb/mtu3/mtu3_qmu.c
index 3f414f91b589..2ea3157ddb6e 100644
--- a/drivers/usb/mtu3/mtu3_qmu.c
+++ b/drivers/usb/mtu3/mtu3_qmu.c
@@ -273,6 +273,8 @@ static int mtu3_prepare_tx_gpd(struct mtu3_ep *mep, struct mtu3_request *mreq)
gpd->dw3_info |= cpu_to_le32(GPD_EXT_FLAG_ZLP);
}
+ /* prevent reorder, make sure GPD's HWO is set last */
+ mb();
gpd->dw0_info |= cpu_to_le32(GPD_FLAGS_IOC | GPD_FLAGS_HWO);
mreq->gpd = gpd;
@@ -306,6 +308,8 @@ static int mtu3_prepare_rx_gpd(struct mtu3_ep *mep, struct mtu3_request *mreq)
gpd->next_gpd = cpu_to_le32(lower_32_bits(enq_dma));
ext_addr |= GPD_EXT_NGP(mtu, upper_32_bits(enq_dma));
gpd->dw3_info = cpu_to_le32(ext_addr);
+ /* prevent reorder, make sure GPD's HWO is set last */
+ mb();
gpd->dw0_info |= cpu_to_le32(GPD_FLAGS_IOC | GPD_FLAGS_HWO);
mreq->gpd = gpd;
@@ -445,7 +449,8 @@ static void qmu_tx_zlp_error_handler(struct mtu3 *mtu, u8 epnum)
return;
}
mtu3_setbits(mbase, MU3D_EP_TXCR0(mep->epnum), TX_TXPKTRDY);
-
+ /* prevent reorder, make sure GPD's HWO is set last */
+ mb();
/* by pass the current GDP */
gpd_current->dw0_info |= cpu_to_le32(GPD_FLAGS_BPS | GPD_FLAGS_HWO);
--
2.18.0
This is caused by uninitialization of list_head.
BUG: KASAN: use-after-free in __list_del_entry_valid+0x34/0xe4
Call trace:
dump_backtrace+0x0/0x298
show_stack+0x24/0x34
dump_stack+0x130/0x1a8
print_address_description+0x88/0x56c
__kasan_report+0x1b8/0x2a0
kasan_report+0x14/0x20
__asan_load8+0x9c/0xa0
__list_del_entry_valid+0x34/0xe4
mtu3_req_complete+0x4c/0x300 [mtu3]
mtu3_gadget_stop+0x168/0x448 [mtu3]
usb_gadget_unregister_driver+0x204/0x3a0
unregister_gadget_item+0x44/0xa4
Fixes: 83374e035b62 ("usb: mtu3: add tracepoints to help debug")
Cc: [email protected]
Reported-by: Yuwen Ng <[email protected]>
Signed-off-by: Chunfeng Yun <[email protected]>
---
v2: add Fixes and Cc suggested by Greg
---
drivers/usb/mtu3/mtu3_gadget.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index c51be015345b..b6c8a4a99c4d 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -235,6 +235,7 @@ struct usb_request *mtu3_alloc_request(struct usb_ep *ep, gfp_t gfp_flags)
mreq->request.dma = DMA_ADDR_INVALID;
mreq->epnum = mep->epnum;
mreq->mep = mep;
+ INIT_LIST_HEAD(&mreq->list);
trace_mtu3_alloc_request(mreq);
return &mreq->request;
--
2.18.0
Add support to set interval also for FS intr and isoc endpoint.
Fixes: 4d79e042ed8b ("usb: mtu3: add support for usb3.1 IP")
Cc: [email protected]
Signed-off-by: Chunfeng Yun <[email protected]>
---
v2: new patch
---
drivers/usb/mtu3/mtu3_gadget.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index b6c8a4a99c4d..9977600616d7 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -92,6 +92,13 @@ static int mtu3_ep_enable(struct mtu3_ep *mep)
interval = clamp_val(interval, 1, 16);
mult = usb_endpoint_maxp_mult(desc) - 1;
}
+ break;
+ case USB_SPEED_FULL:
+ if (usb_endpoint_xfer_isoc(desc))
+ interval = clamp_val(desc->bInterval, 1, 16);
+ else if (usb_endpoint_xfer_int(desc))
+ interval = clamp_val(desc->bInterval, 1, 255);
+
break;
default:
break; /*others are ignored */
--
2.18.0
On 18.12.2021 12:57, Chunfeng Yun wrote:
> This is caused by uninitialization of list_head.
Again, there's no such word as "uninitialization" (even if it existed, it
wouldn't mean what you wanted to say); please replace by "not initializing".
> BUG: KASAN: use-after-free in __list_del_entry_valid+0x34/0xe4
>
> Call trace:
> dump_backtrace+0x0/0x298
> show_stack+0x24/0x34
> dump_stack+0x130/0x1a8
> print_address_description+0x88/0x56c
> __kasan_report+0x1b8/0x2a0
> kasan_report+0x14/0x20
> __asan_load8+0x9c/0xa0
> __list_del_entry_valid+0x34/0xe4
> mtu3_req_complete+0x4c/0x300 [mtu3]
> mtu3_gadget_stop+0x168/0x448 [mtu3]
> usb_gadget_unregister_driver+0x204/0x3a0
> unregister_gadget_item+0x44/0xa4
>
> Fixes: 83374e035b62 ("usb: mtu3: add tracepoints to help debug")
> Cc: [email protected]
> Reported-by: Yuwen Ng <[email protected]>
> Signed-off-by: Chunfeng Yun <[email protected]>
[...]
MBR, Sergey
On Sun, Dec 19, 2021 at 01:14:25PM +0300, Sergei Shtylyov wrote:
> On 18.12.2021 12:57, Chunfeng Yun wrote:
>
> > This is caused by uninitialization of list_head.
>
> Again, there's no such word as "uninitialization" (even if it existed, it
> wouldn't mean what you wanted to say); please replace by "not initializing".
We are not English language scholars, most of us do not have English as
their native language. We all can understand what is being said here,
there's no need for any change, please do not be so critical.
thanks,
greg k-h
On 19.12.2021 13:40, Greg Kroah-Hartman wrote:
[...]
>>> This is caused by uninitialization of list_head.
>>
>> Again, there's no such word as "uninitialization" (even if it existed, it
>> wouldn't mean what you wanted to say); please replace by "not initializing".
>
> We are not English language scholars, most of us do not have English as
> their native language. We all can understand what is being said here,
> there's no need for any change, please do not be so critical.
OK, noted...
I was just somewhat upset that my 1st comment was ignored. :-/
> thanks,
>
> greg k-h
MBR, Sergey
On Sun, 2021-12-19 at 14:00 +0300, Sergei Shtylyov wrote:
> On 19.12.2021 13:40, Greg Kroah-Hartman wrote:
> [...]
>
> > > > This is caused by uninitialization of list_head.
> > >
> > > Again, there's no such word as "uninitialization" (even if it
> > > existed, it
> > > wouldn't mean what you wanted to say); please replace by "not
> > > initializing".
> >
> > We are not English language scholars, most of us do not have
> > English as
> > their native language. We all can understand what is being said
> > here,
> > there's no need for any change, please do not be so critical.
>
> OK, noted...
> I was just somewhat upset that my 1st comment was ignored. :-/
Very sorry, I planned to fix it, but forgot it;
Please feel free to point out my mistakes;
Thanks a lot
>
> > thanks,
> >
> > greg k-h
>
> MBR, Sergey