linux-kernel - Re: [RESENDING RFC PATCH 1/4] dt-bindings: usb: Add snps,consolidate-sgl & consolidate-sgl

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] [day] [month] [year] [list]

Date:   Fri, 17 Apr 2020 14:44:50 +0300
From:   Mathias Nyman <mathias.nyman@...ux.intel.com>
To:     Tejas Joglekar <Tejas.Joglekar@...opsys.com>,
        Felipe Balbi <balbi@...nel.org>, Rob Herring <robh@...nel.org>,
        Mathias Nyman <mathias.nyman@...el.com>
Cc:     "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        John Youn <John.Youn@...opsys.com>
Subject: Re: [RESENDING RFC PATCH 1/4] dt-bindings: usb: Add
 snps,consolidate-sgl & consolidate-sgl

On 16.4.2020 19.37, Tejas Joglekar wrote:
> Hi,
> On 4/16/2020 1:52 PM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Tejas Joglekar <Tejas.Joglekar@...opsys.com> writes:
>>> Hi,
>>> On 4/5/2020 7:15 AM, Rob Herring wrote:
>>>> On Fri, Mar 27, 2020 at 03:11:56PM +0530, Tejas Joglekar wrote:
>>>>> This commit adds the documentation for consolidate-sgl, and
>>>>> snps,consolidate-sgl property. These when set enables the quirk for
>>>>> XHCI driver for consolidation of sg list into a temporary buffer when small
>>>>> buffer sizes are scattered over the sg list not making up to MPS or total
>>>>> transfer size within TRB cache size with Synopsys xHC.
>>>>>
>>>>> Signed-off-by: Tejas Joglekar <joglekar@...opsys.com>
>>>>> ---
>>>>>  Documentation/devicetree/bindings/usb/dwc3.txt     | 3 +++
>>>>>  Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 +++
>>>>>  2 files changed, 6 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>> index 9946ff9ba735..292d1f7969e4 100644
>>>>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>> @@ -104,6 +104,9 @@ Optional properties:
>>>>>  			this and tx-thr-num-pkt-prd to a valid, non-zero value
>>>>>  			1-16 (DWC_usb31 programming guide section 1.2.3) to
>>>>>  			enable periodic ESS TX threshold.
>>>>> + - snps,consolidate-sgl: enable sg list consolidation - host mode only. Set to use
>>>>> +			SG buffers of at least MPS size by consolidating smaller SG
>>>>> +			buffers list into a single buffer.
>>>>
>>>> The preference is not to keep adding properties for every single quirk 
>>>> or feature. These should be implied by specific compatibles. As Synopsys 
>>>> knows what quirks/errata/features are in each version of IP, the 
>>>> compatible strings should reflect those versions. (And yes, I'm sure 
>>>> there's customer ECO fixes that aren't reflected in the version, but 
>>>> that's why we have SoC specific compatibles too.) This is the only way 
>>>> we can fix quirks in the OS without doing DT updates. For comparison, do 
>>>> you want to have to update your PC BIOS so an OS can work-around issues?
>>>>
>>> Yes, I understand what you want to say here. But I think this compatible string
>>> does not work with the platform drivers with PCI based systems. So based on the vendor 
>>> id and device id then I need to set the quirk required. 
>>>
>>> @Felipe: What do you suggest for setting up quirk without the DT update for dwc3?
>>
>> We have been using Synopsys controller's revision register, but that's
>> not visible to xhci driver and we don't have a separate compatible for
>> each synopsys version on the xhci driver side. One option would be to
>> add "snps,xhci-foo-bar" to xhci-plat and use that.
>>
> @Felipe: Thanks for suggestion
> 
> @Mathias: Do you prefer parameter passed this way? I can send the v2 patch set,
> after your input.

should work, I don't see any issues with that.

-Mathias