| Message ID | 1627635002-24521-1-git-send-email-chunfeng.yun@mediatek.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | [01/11] dt-bindings: usb: mtk-xhci: add support property 'tpl-support' | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success | |
| robh/dt-meta-schema | success | |
| robh/dtbs-check | success |
Hi Chunfeng, On Fri, Jul 30, 2021 at 4:51 PM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote: > > 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(-) > > diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c > index 0bb1a6295d64..10c0f0f6461f 100644 > --- a/drivers/usb/host/xhci-mtk-sch.c > +++ b/drivers/usb/host/xhci-mtk-sch.c > @@ -458,8 +458,8 @@ static int check_fs_bus_bw(struct mu3h_sch_ep_info *sch_ep, int offset) > * Compared with hs bus, no matter what ep type, > * the hub will always delay one uframe to send data > */ > - for (j = 0; j < sch_ep->cs_count; j++) { > - tmp = tt->fs_bus_bw[base + j] + sch_ep->bw_cost_per_microframe; > + for (j = 0; j < sch_ep->num_budget_microframes; j++) { > + tmp = tt->fs_bus_bw[base + j] + sch_ep->bw_budget_table[j]; > if (tmp > FS_PAYLOAD_MAX) > return -ESCH_BW_OVERFLOW; > } > @@ -534,21 +534,18 @@ static void update_sch_tt(struct mu3h_sch_ep_info *sch_ep, bool used) > { > struct mu3h_sch_tt *tt = sch_ep->sch_tt; > u32 base, num_esit; > - int bw_updated; > int i, j; > > num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit; > > - if (used) > - bw_updated = sch_ep->bw_cost_per_microframe; > - else > - bw_updated = -sch_ep->bw_cost_per_microframe; > - > for (i = 0; i < num_esit; i++) { > base = sch_ep->offset + i * sch_ep->esit; > > - for (j = 0; j < sch_ep->cs_count; j++) > - tt->fs_bus_bw[base + j] += bw_updated; > + for (j = 0; j < sch_ep->num_budget_microframes; j++) > + if (used) > + tt->fs_bus_bw[base + j] += sch_ep->bw_budget_table[j]; > + else > + tt->fs_bus_bw[base + j] -= sch_ep->bw_budget_table[j]; 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? > } > > if (used) > -- > 2.18.0 >
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 <chunfeng.yun@mediatek.com> wrote: > > > > 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(-) > > > > diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c > > index 0bb1a6295d64..10c0f0f6461f 100644 > > --- a/drivers/usb/host/xhci-mtk-sch.c > > +++ b/drivers/usb/host/xhci-mtk-sch.c > > @@ -458,8 +458,8 @@ static int check_fs_bus_bw(struct mu3h_sch_ep_info *sch_ep, int offset) > > * Compared with hs bus, no matter what ep type, > > * the hub will always delay one uframe to send data > > */ > > - for (j = 0; j < sch_ep->cs_count; j++) { > > - tmp = tt->fs_bus_bw[base + j] + sch_ep->bw_cost_per_microframe; > > + for (j = 0; j < sch_ep->num_budget_microframes; j++) { > > + tmp = tt->fs_bus_bw[base + j] + sch_ep->bw_budget_table[j]; > > if (tmp > FS_PAYLOAD_MAX) > > return -ESCH_BW_OVERFLOW; > > } > > @@ -534,21 +534,18 @@ static void update_sch_tt(struct mu3h_sch_ep_info *sch_ep, bool used) > > { > > struct mu3h_sch_tt *tt = sch_ep->sch_tt; > > u32 base, num_esit; > > - int bw_updated; > > int i, j; > > > > num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit; > > > > - if (used) > > - bw_updated = sch_ep->bw_cost_per_microframe; > > - else > > - bw_updated = -sch_ep->bw_cost_per_microframe; > > - > > for (i = 0; i < num_esit; i++) { > > base = sch_ep->offset + i * sch_ep->esit; > > > > - for (j = 0; j < sch_ep->cs_count; j++) > > - tt->fs_bus_bw[base + j] += bw_updated; > > + for (j = 0; j < sch_ep->num_budget_microframes; j++) > > + if (used) > > + tt->fs_bus_bw[base + j] += sch_ep->bw_budget_table[j]; > > + else > > + tt->fs_bus_bw[base + j] -= sch_ep->bw_budget_table[j]; > > 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 > > > } > > > > if (used) > > > -- > > 2.18.0 > >
Hi, On Wed, Aug 4, 2021 at 1:19 PM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote: > > 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 <chunfeng.yun@mediatek.com> wrote: > > > > > > 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(-) > > > > > > diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c > > > index 0bb1a6295d64..10c0f0f6461f 100644 > > > --- a/drivers/usb/host/xhci-mtk-sch.c > > > +++ b/drivers/usb/host/xhci-mtk-sch.c > > > @@ -458,8 +458,8 @@ static int check_fs_bus_bw(struct mu3h_sch_ep_info *sch_ep, int offset) > > > * Compared with hs bus, no matter what ep type, > > > * the hub will always delay one uframe to send data > > > */ > > > - for (j = 0; j < sch_ep->cs_count; j++) { > > > - tmp = tt->fs_bus_bw[base + j] + sch_ep->bw_cost_per_microframe; > > > + for (j = 0; j < sch_ep->num_budget_microframes; j++) { > > > + tmp = tt->fs_bus_bw[base + j] + sch_ep->bw_budget_table[j]; > > > if (tmp > FS_PAYLOAD_MAX) > > > return -ESCH_BW_OVERFLOW; > > > } > > > @@ -534,21 +534,18 @@ static void update_sch_tt(struct mu3h_sch_ep_info *sch_ep, bool used) > > > { > > > struct mu3h_sch_tt *tt = sch_ep->sch_tt; > > > u32 base, num_esit; > > > - int bw_updated; > > > int i, j; > > > > > > num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit; > > > > > > - if (used) > > > - bw_updated = sch_ep->bw_cost_per_microframe; > > > - else > > > - bw_updated = -sch_ep->bw_cost_per_microframe; > > > - > > > for (i = 0; i < num_esit; i++) { > > > base = sch_ep->offset + i * sch_ep->esit; > > > > > > - for (j = 0; j < sch_ep->cs_count; j++) > > > - tt->fs_bus_bw[base + j] += bw_updated; > > > + for (j = 0; j < sch_ep->num_budget_microframes; j++) > > > + if (used) > > > + tt->fs_bus_bw[base + j] += sch_ep->bw_budget_table[j]; > > > + else > > > + tt->fs_bus_bw[base + j] -= sch_ep->bw_budget_table[j]; > > > > 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; > 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 > Thanks > > > > > > } > > > > > > if (used) > > > > > -- > > > 2.18.0 > > > >
On Fri, Jul 30, 2021 at 04:49:52PM +0800, Chunfeng Yun wrote: > Add property 'tpl-support' to support targeted peripheral list > for USB-IF Embedded Host Compliance Test Given you have to configure the TPL somehow, how is this useful to be in DT? And no, that's not a suggestion to put all the TPL config into DT. > > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> > --- > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > index 240882b12565..49729aab6d1a 100644 > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > @@ -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 > >
Hi Chunfeng, On Fri, Jul 30, 2021 at 4:50 PM Chunfeng Yun <chunfeng.yun@mediatek.com> wrote: > > check_sch_tt() will access fs_bus_bw[] array, check boundary > firstly to avoid out-of-bounds issue. > > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> > --- > drivers/usb/host/xhci-mtk-sch.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c > index 10c0f0f6461f..c2f13d69c607 100644 > --- a/drivers/usb/host/xhci-mtk-sch.c > +++ b/drivers/usb/host/xhci-mtk-sch.c > @@ -600,13 +600,14 @@ static int check_sch_bw(struct mu3h_sch_bw_info *sch_bw, > * and find a microframe where its worst bandwidth is minimum. > */ > for (offset = 0; offset < sch_ep->esit; offset++) { > - ret = check_sch_tt(sch_ep, offset); > - if (ret) > - continue; > > if ((offset + sch_ep->num_budget_microframes) > esit_boundary) > break; Instead of dropping it, I'm wondering if it should be checked against (offset & 63) == 0 when it's 64? > > + ret = check_sch_tt(sch_ep, offset); > + if (ret) > + continue; > + > worst_bw = get_max_bw(sch_bw, sch_ep, offset); > if (worst_bw > bw_boundary) > continue; > -- > 2.18.0 >
On Wed, 2021-08-04 at 22:06 +0800, Ikjoon Jang wrote: > Hi, > > On Wed, Aug 4, 2021 at 1:19 PM Chunfeng Yun < > chunfeng.yun@mediatek.com> wrote: > > > > 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 < > > > chunfeng.yun@mediatek.com> wrote: > > > > > > > > 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(-) > > > > > > > > diff --git a/drivers/usb/host/xhci-mtk-sch.c > > > > b/drivers/usb/host/xhci-mtk-sch.c > > > > index 0bb1a6295d64..10c0f0f6461f 100644 > > > > --- a/drivers/usb/host/xhci-mtk-sch.c > > > > +++ b/drivers/usb/host/xhci-mtk-sch.c > > > > @@ -458,8 +458,8 @@ static int check_fs_bus_bw(struct > > > > mu3h_sch_ep_info *sch_ep, int offset) > > > > * Compared with hs bus, no matter what ep > > > > type, > > > > * the hub will always delay one uframe to send > > > > data > > > > */ > > > > - for (j = 0; j < sch_ep->cs_count; j++) { > > > > - tmp = tt->fs_bus_bw[base + j] + sch_ep- > > > > >bw_cost_per_microframe; > > > > + for (j = 0; j < sch_ep->num_budget_microframes; > > > > j++) { > > > > + tmp = tt->fs_bus_bw[base + j] + sch_ep- > > > > >bw_budget_table[j]; > > > > if (tmp > FS_PAYLOAD_MAX) > > > > return -ESCH_BW_OVERFLOW; > > > > } > > > > @@ -534,21 +534,18 @@ static void update_sch_tt(struct > > > > mu3h_sch_ep_info *sch_ep, bool used) > > > > { > > > > struct mu3h_sch_tt *tt = sch_ep->sch_tt; > > > > u32 base, num_esit; > > > > - int bw_updated; > > > > int i, j; > > > > > > > > num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit; > > > > > > > > - if (used) > > > > - bw_updated = sch_ep->bw_cost_per_microframe; > > > > - else > > > > - bw_updated = -sch_ep->bw_cost_per_microframe; > > > > - > > > > for (i = 0; i < num_esit; i++) { > > > > base = sch_ep->offset + i * sch_ep->esit; > > > > > > > > - for (j = 0; j < sch_ep->cs_count; j++) > > > > - tt->fs_bus_bw[base + j] += bw_updated; > > > > + for (j = 0; j < sch_ep->num_budget_microframes; > > > > j++) > > > > + if (used) > > > > + tt->fs_bus_bw[base + j] += > > > > sch_ep->bw_budget_table[j]; > > > > + else > > > > + tt->fs_bus_bw[base + j] -= > > > > sch_ep->bw_budget_table[j]; > > > > > > 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; > > > > 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)? No, that is another question, when update bus_bw[] and fs_bus_bw[] for FS with TT should use the same bw_budget_table[] which is filled in setup_sch_info(). If the bw_budget_table[] is something wrong, we can prepare new patch to fix it. > > thanks > > > Thanks > > > > > > > > > } > > > > > > > > if (used) > > > > -- > > > > 2.18.0 > > > >
On Fri, 2021-08-06 at 14:37 -0600, Rob Herring wrote: > On Fri, Jul 30, 2021 at 04:49:52PM +0800, Chunfeng Yun wrote: > > Add property 'tpl-support' to support targeted peripheral list > > for USB-IF Embedded Host Compliance Test > > Given you have to configure the TPL somehow, how is this useful to be > in > DT? And no, that's not a suggestion to put all the TPL config into > DT. Ok, will abandon this patch Thanks > > > > > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> > > --- > > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 2 > > ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk- > > xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk- > > xhci.yaml > > index 240882b12565..49729aab6d1a 100644 > > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > > @@ -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 > > > >
On Mon, 2021-08-09 at 15:32 +0800, Ikjoon Jang wrote: > Hi Chunfeng, > > On Fri, Jul 30, 2021 at 4:50 PM Chunfeng Yun < > chunfeng.yun@mediatek.com> wrote: > > > > check_sch_tt() will access fs_bus_bw[] array, check boundary > > firstly to avoid out-of-bounds issue. > > > > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> > > --- > > drivers/usb/host/xhci-mtk-sch.c | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/usb/host/xhci-mtk-sch.c > > b/drivers/usb/host/xhci-mtk-sch.c > > index 10c0f0f6461f..c2f13d69c607 100644 > > --- a/drivers/usb/host/xhci-mtk-sch.c > > +++ b/drivers/usb/host/xhci-mtk-sch.c > > @@ -600,13 +600,14 @@ static int check_sch_bw(struct > > mu3h_sch_bw_info *sch_bw, > > * and find a microframe where its worst bandwidth is > > minimum. > > */ > > for (offset = 0; offset < sch_ep->esit; offset++) { > > - ret = check_sch_tt(sch_ep, offset); > > - if (ret) > > - continue; > > > > if ((offset + sch_ep->num_budget_microframes) > > > esit_boundary) > > break; > > Instead of dropping it, > I'm wondering if it should be checked against (offset & 63) == 0 when > it's 64? No, sch_ep->esit already ensure it, it's <= 64, see get_esit() > > > > > + ret = check_sch_tt(sch_ep, offset); > > + if (ret) > > + continue; > > + > > worst_bw = get_max_bw(sch_bw, sch_ep, offset); > > if (worst_bw > bw_boundary) > > continue; > > -- > > 2.18.0 > >
On Fri, 2021-08-06 at 14:37 -0600, Rob Herring wrote: > On Fri, Jul 30, 2021 at 04:49:52PM +0800, Chunfeng Yun wrote: > > Add property 'tpl-support' to support targeted peripheral list > > for USB-IF Embedded Host Compliance Test > > Given you have to configure the TPL somehow, how is this useful to be > in > DT? And no, that's not a suggestion to put all the TPL config into > DT. It's indeed not flexible here, abandon this patch. Thanks > > > > > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> > > --- > > Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 2 > > ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk- > > xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk- > > xhci.yaml > > index 240882b12565..49729aab6d1a 100644 > > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml > > @@ -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 > > > >
On Fri, Jul 30, 2021 at 4:50 PM Chunfeng Yun <chunfeng.yun@mediatek.com> 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 <pihsun@google.com> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Reviewed-and-Tested-by: Ikjoon Jang <ikjn@chromium.org> > --- > drivers/usb/host/xhci-mtk.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c > index 2548976bcf05..cb27569186a0 100644 > --- a/drivers/usb/host/xhci-mtk.c > +++ b/drivers/usb/host/xhci-mtk.c > @@ -569,7 +569,7 @@ static int xhci_mtk_probe(struct platform_device *pdev) > xhci_mtk_ldos_disable(mtk); > > disable_pm: > - pm_runtime_put_sync_autosuspend(dev); > + pm_runtime_put_noidle(dev); > pm_runtime_disable(dev); > return ret; > } > -- > 2.18.0 >
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index 240882b12565..49729aab6d1a 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -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
Add property 'tpl-support' to support targeted peripheral list for USB-IF Embedded Host Compliance Test Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> --- Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml | 2 ++ 1 file changed, 2 insertions(+)