@@ -115,6 +115,8 @@ properties:usb2-lpm-disable:true+tpl-support:true+imod-interval-ns:description:Interrupt moderation interval value, it is 8 times as much as that
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
There are 4 USB controllers on MT8195, the controllers (IP1~IP3,
exclude IP0) have a wrong default SOF/ITP interval which is
calculated from the frame counter clock 24Mhz by default, but
in fact, the frame counter clock is 48Mhz, so we should set
the accurate interval according to 48Mhz. Here add a new compatible
for MT8195, it's also supported in driver. But the first controller
(IP0) has no such issue, we prefer to use generic compatible,
e.g. mt8192's compatible.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 1 +
1 file changed, 1 insertion(+)
There are 4 USB controllers on MT8195, the controllers (IP1~IP3,
exclude IP0) have a wrong default SOF/ITP interval which is
calculated from the frame counter clock 24Mhz by default, but
in fact, the frame counter clock is 48Mhz, so we should set
the accurate interval according to 48Mhz for those controllers.
Note: the first controller no need set it.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/host/xhci-mtk.c | 65 +++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
@@ -368,6 +429,9 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)ret=xhci_mtk_ssusb_config(mtk);if(ret)returnret;++/* workaround only for mt8195 */+xhci_mtk_set_frame_interval(mtk);}ret=xhci_gen_setup(hcd,xhci_mtk_quirks);
Add support to disable specific usb2 host ports, it's useful when
a usb2 port is disabled on some platforms, but enabled on others for
the same SoC, another case is that the different package may support
different number of ports.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 5 +++++
1 file changed, 5 insertions(+)
@@ -154,6 +154,11 @@ properties:description:The mask to disable u3ports, bit0 for u3port0,bit1 for u3port1, ... etc+mediatek,u2p-dis-msk:+$ref:/schemas/types.yaml#/definitions/uint32+description:The mask to disable u2ports, bit0 for u2port0,+bit1 for u2port1, ... etc+"#address-cells":const:1
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Add a member num_esit to save the number of esit, then no need
caculate it in some functions.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/host/xhci-mtk-sch.c | 20 +++++++-------------
drivers/usb/host/xhci-mtk.h | 2 ++
2 files changed, 9 insertions(+), 13 deletions(-)
Add support to disable specific usb2 host ports, it's useful when
a usb2 port is disabled on some platforms, but enabled on others
for the same SoC.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/host/xhci-mtk.c | 12 ++++++++++--
drivers/usb/host/xhci-mtk.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
@@ -116,8 +116,11 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)writel(value,&ippc->u3_ctrl_p[i]);}-/* power on and enable all u2 ports */+/* power on and enable all u2 ports except skipped ones */for(i=0;i<mtk->num_u2_ports;i++){+if(BIT(i)&mtk->u2p_dis_msk)+continue;+value=readl(&ippc->u2_ctrl_p[i]);value&=~(CTRL_U2_PORT_PDN|CTRL_U2_PORT_DIS);value|=CTRL_U2_PORT_HOST_SEL;
@@ -164,8 +167,11 @@ static int xhci_mtk_host_disable(struct xhci_hcd_mtk *mtk)writel(value,&ippc->u3_ctrl_p[i]);}-/* power down all u2 ports */+/* power down all u2 ports except skipped ones */for(i=0;i<mtk->num_u2_ports;i++){+if(BIT(i)&mtk->u2p_dis_msk)+continue;+value=readl(&ippc->u2_ctrl_p[i]);value|=CTRL_U2_PORT_PDN;writel(value,&ippc->u2_ctrl_p[i]);
@@ -445,6 +451,8 @@ static int xhci_mtk_probe(struct platform_device *pdev)/* optional property, ignore the error if it does not exist */of_property_read_u32(node,"mediatek,u3p-dis-msk",&mtk->u3p_dis_msk);+of_property_read_u32(node,"mediatek,u2p-dis-msk",+&mtk->u2p_dis_msk);ret=usb_wakeup_of_property_parse(mtk,node);if(ret){
Bus bandwidth array access is based on esit, increase one
will cause out-of-bounds issue; for example, when esit is
XHCI_MTK_MAX_ESIT, will overstep boundary.
Fixes: 7c986fbc16ae ("usb: xhci-mtk: get the microframe boundary for ESIT")
Cc: <redacted>
Reported-by: Stan Lu <redacted>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/host/xhci-mtk-sch.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
Use @bw_budget_table[] to update fs bus bandwidth due to
not all microframes consume @bw_cost_per_microframe, see
setup_sch_info().
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/host/xhci-mtk-sch.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
From: Ikjoon Jang <hidden> Date: 2021-08-03 06:05:33
Hi Chunfeng,
On Fri, Jul 30, 2021 at 4:51 PM Chunfeng Yun [off-list ref] wrote:
quoted hunk
Use @bw_budget_table[] to update fs bus bandwidth due to
not all microframes consume @bw_cost_per_microframe, see
setup_sch_info().
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/host/xhci-mtk-sch.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
I agree that xhci-mtk-sch still has more rooms for tt periodic bandwidth
but I think this approach could trigger a problem.
for example, if there are two endpoints scheduled in the same u-frame index,
* ep1out = iso 192bytes bw_budget_table[] = { 188, 188, 0, ...} --> y0
* ep2in = int 64bytes, bw_budget_table[] = { 0, 0, 64, ... } --> y0
(If this is possible allocation from this patch),
I guess xhci-mtk could have some problems on internal scheduling?
On Tue, 2021-08-03 at 14:05 +0800, Ikjoon Jang wrote:
Hi Chunfeng,
On Fri, Jul 30, 2021 at 4:51 PM Chunfeng Yun [off-list ref] wrote:
quoted
Use @bw_budget_table[] to update fs bus bandwidth due to
not all microframes consume @bw_cost_per_microframe, see
setup_sch_info().
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/host/xhci-mtk-sch.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
I agree that xhci-mtk-sch still has more rooms for tt periodic bandwidth
but I think this approach could trigger a problem.
See updat_bus_bw(), when add fs ep's bandwidth, it uses
bw_budget_table[], so prefer to use the same way
for example, if there are two endpoints scheduled in the same u-frame index,
* ep1out = iso 192bytes bw_budget_table[] = { 188, 188, 0, ...} --> y0
* ep2in = int 64bytes, bw_budget_table[] = { 0, 0, 64, ... } --> y0
(If this is possible allocation from this patch),
I guess xhci-mtk could have some problems on internal scheduling?
Test it on dvt env. don't encounter issues;
Thanks
From: Ikjoon Jang <hidden> Date: 2021-08-04 14:06:36
Hi,
On Wed, Aug 4, 2021 at 1:19 PM Chunfeng Yun [off-list ref] wrote:
On Tue, 2021-08-03 at 14:05 +0800, Ikjoon Jang wrote:
quoted
Hi Chunfeng,
On Fri, Jul 30, 2021 at 4:51 PM Chunfeng Yun [off-list ref] wrote:
quoted
Use @bw_budget_table[] to update fs bus bandwidth due to
not all microframes consume @bw_cost_per_microframe, see
setup_sch_info().
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/host/xhci-mtk-sch.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
I agree that xhci-mtk-sch still has more rooms for tt periodic bandwidth
but I think this approach could trigger a problem.
See updat_bus_bw(), when add fs ep's bandwidth, it uses
bw_budget_table[], so prefer to use the same way
quoted
for example, if there are two endpoints scheduled in the same u-frame index,
* ep1out = iso 192bytes bw_budget_table[] = { 188, 188, 0, ...} --> y0
* ep2in = int 64bytes, bw_budget_table[] = { 0, 0, 64, ... } --> y0
(If this is possible allocation from this patch),
I guess xhci-mtk could have some problems on internal scheduling?
Test it on dvt env. don't encounter issues;
As you can see In the above example, this patch starts to allow that allocation.
Do you mean that we don't have to worry about such a case (on all MTK
platforms)?
thanks
@@ -115,6 +115,8 @@ properties:usb2-lpm-disable:true+tpl-support:true+imod-interval-ns:description:Interrupt moderation interval value, it is 8 times as much as that
From: Rob Herring <robh@kernel.org> Date: 2021-08-06 20:41:21
On Fri, Jul 30, 2021 at 04:49:53PM +0800, Chunfeng Yun wrote:
quoted hunk
Add support to disable specific usb2 host ports, it's useful when
a usb2 port is disabled on some platforms, but enabled on others for
the same SoC, another case is that the different package may support
different number of ports.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 5 +++++
1 file changed, 5 insertions(+)
@@ -154,6 +154,11 @@ properties:description:The mask to disable u3ports, bit0 for u3port0,bit1 for u3port1, ... etc+mediatek,u2p-dis-msk:+$ref:/schemas/types.yaml#/definitions/uint32+description:The mask to disable u2ports, bit0 for u2port0,+bit1 for u2port1, ... etc
You already have this property in the parent node, right? Why are we
duplicating it in both places?
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2021-08-06 20:43:26
On Fri, Jul 30, 2021 at 04:49:54PM +0800, Chunfeng Yun wrote:
There are 4 USB controllers on MT8195, the controllers (IP1~IP3,
exclude IP0) have a wrong default SOF/ITP interval which is
calculated from the frame counter clock 24Mhz by default, but
in fact, the frame counter clock is 48Mhz, so we should set
the accurate interval according to 48Mhz. Here add a new compatible
for MT8195, it's also supported in driver. But the first controller
(IP0) has no such issue, we prefer to use generic compatible,
e.g. mt8192's compatible.
That only works until you find some 8195 bug common to all instances.
Can't you read the clock frequency?
From: Ikjoon Jang <hidden> Date: 2021-08-13 05:26:45
On Fri, Jul 30, 2021 at 4:50 PM Chunfeng Yun [off-list ref] wrote:
BUG: KASAN: use-after-free in usb_hcd_is_primary_hcd+0x38/0x60
Call trace:
dump_backtrace+0x0/0x3dc
show_stack+0x20/0x2c
dump_stack+0x15c/0x1d4
print_address_description+0x7c/0x510
kasan_report+0x164/0x1ac
__asan_report_load8_noabort+0x44/0x50
usb_hcd_is_primary_hcd+0x38/0x60
xhci_mtk_runtime_suspend+0x68/0x148
pm_generic_runtime_suspend+0x90/0xac
__rpm_callback+0xb8/0x1f4
rpm_callback+0x54/0x1d0
rpm_suspend+0x4e0/0xc84
__pm_runtime_suspend+0xc4/0x114
xhci_mtk_probe+0xa58/0xd00
This may happen when probe fails, needn't suspend it synchronously,
fix it by using pm_runtime_put_noidle().
Reported-by: Pi Hsun <redacted>
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Reviewed-and-Tested-by: Ikjoon Jang [off-list ref]