linux-kernel - Re: [PATCH v3 1/3] dt-bindings: usb: mtk-xhci: add a property for Gen1 isoc-in transfer issue

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]

Message-ID: <6510fb531ffb109c05b3ccd270ee516831209bd7.camel@mediatek.com>
Date: Wed, 27 Dec 2023 02:08:39 +0000
From: Chunfeng Yun (云春峰) <Chunfeng.Yun@...iatek.com>
To: "krzysztof.kozlowski@...aro.org" <krzysztof.kozlowski@...aro.org>,
	"angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>, "gregkh@...uxfoundation.org"
	<gregkh@...uxfoundation.org>, "robh+dt@...nel.org" <robh+dt@...nel.org>,
	"krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>
CC: "linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"mathias.nyman@...el.com" <mathias.nyman@...el.com>,
	Eddie Hung (洪正鑫) <Eddie.Hung@...iatek.com>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	Macpaul Lin (林智斌) <Macpaul.Lin@...iatek.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "matthias.bgg@...il.com"
	<matthias.bgg@...il.com>
Subject: Re: [PATCH v3 1/3] dt-bindings: usb: mtk-xhci: add a property for
 Gen1 isoc-in transfer issue

On Wed, 2023-12-20 at 11:40 +0100, AngeloGioacchino Del Regno wrote:
> Il 20/12/23 08:38, Krzysztof Kozlowski ha scritto:
> > On 20/12/2023 03:58, Chunfeng Yun wrote:
> > > For Gen1 isoc-in endpoint on controller before about SSUSB IPM
> > > v1.6.0, it
> > > still send out unexpected ACK after receiving a short packet in
> > > burst
> > > transfer, this will cause an exception on connected device,
> > > specially for
> > > a 4k camera.
> > > Add a quirk property "rx-fifo-depth" to work around this hardware
> > > issue,
> > > prefer to use 3k bytes;
> > > The side-effect is that may cause performance drop about 10%,
> > > including
> > > bulk transfer.
> > > 
> > > Signed-off-by: Chunfeng Yun <chunfeng.yun@...iatek.com>
> > > ---
> > > v3: add fifo depth unit, change the value range from 0-3 to 1-4
> > > v2: change 'mediatek,rxfifo-depth' to 'rx-fifo-depth'
> > > ---
> > >   .../devicetree/bindings/usb/mediatek,mtk-xhci.yaml   | 12
> > > ++++++++++++
> > >   1 file changed, 12 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml
> > > index e9644e333d78..9478b7031796 100644
> > > --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml
> > > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-
> > > xhci.yaml
> > > @@ -124,6 +124,18 @@ properties:
> > >         defined in the xHCI spec on MTK's controller.
> > >       default: 5000
> > >   
> > > +  rx-fifo-depth:
> > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > > +    description:
> > > +      It is a quirk used to work around Gen1 isoc-in endpoint
> > > transfer issue
> > > +      that still send out unexpected ACK after device finish the
> > > burst transfer
> > > +      with a short packet and cause an exception, specially on a
> > > 4K camera
> > > +      device, it happens on controller before about IPM v1.6.0;
> > > the side-effect
> > > +      is that may cause performance drop about 10%, include bulk
> > > transfer,
> > > +      prefer to use 3 here. The unit is 1K bytes.
> > 
> > NAK. Read comments on previous submission.
> > 
> > Best regards,
> > Krzysztof
> > 
> 
> Chunfeng, I think the discussion was not clear for you, so I will try
> to give
> you a different explanation: this should be expressed in bytes, so
> 1000, or 1024,
> 2048, 4096, etc, and not 1/2/3/4/5/n.
> 
> The driver shall then validate and map your bytes number to hardware
> register
> value and subsequently write to the registers.
Got it, I left out Krzysztof's comments when sent v3 series,

Thanks a lot

> 
> Cheers,
> Angleo