Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 13 Apr 2023 11:13:30 +0200
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Stanley Chang <stanley_chang@realtek.com>
Cc:     Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Felipe Balbi <balbi@kernel.org>, linux-usb@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/2] dt-bindings: usb: snps,dwc3: Add
 'snps,parkmode-disable-hs-quirk' quirk
Message-ID: <2023041346-shamrock-sterilize-9165@gregkh>
References: <20230413085351.26808-1-stanley_chang@realtek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230413085351.26808-1-stanley_chang@realtek.com>
Precedence: bulk

On Thu, Apr 13, 2023 at 04:53:50PM +0800, Stanley Chang wrote:
> Add a new 'snps,parkmode-disable-hs-quirk' DT quirk to dwc3 core for
> disable the high-speed parkmode.
> 
> For some USB wifi devices, if enable this feature it will reduce the
> performance. Therefore, add an option for disabling HS park mode by
> device-tree.
> 
> In Synopsys's dwc3 data book:
> In a few high speed devices when an IN request is sent within 900ns of the
> ACK of the previous packet, these devices send a NAK. When connected to
> these devices, if required, the software can disable the park mode if you
> see performance drop in your system. When park mode is disabled,
> pipelining of multiple packet is disabled and instead one packet at a time
> is requested by the scheduler. This allows up to 12 NAKs in a micro-frame
> and improves performance of these slow devices.
> 
> Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
> ---
> v2 to v3 change:
> 1. Add the comment message.
> 2. cc the right maintainers.

This is not properly threaded with patch 1/2 for some reason, so our
tools can not pick up the whole thread at once.  Please fix up your
sending script, or just use git send-email directly.

thanks,

greg k-h