netdev - Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

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]

Date:   Thu, 22 Mar 2018 11:29:53 +0100
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Kalle Valo <kvalo@...eaurora.org>
Cc:     Arend van Spriel <arend.vanspriel@...adcom.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Alexey Roslyakov <alexey.roslyakov@...il.com>,
        Andrew Lunn <andrew@...n.ch>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Franky Lin <franky.lin@...adcom.com>,
        Hante Meuleman <hante.meuleman@...adcom.com>,
        Chi-Hsien Lin <chi-hsien.lin@...ress.com>,
        Wright Feng <wright.feng@...ress.com>, netdev@...r.kernel.org,
        linux-wireless@...r.kernel.org, devicetree@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        brcm80211-dev-list.pdl@...adcom.com, brcm80211-dev-list@...ress.com
Subject: Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

On 20 March 2018 at 10:55, Kalle Valo <kvalo@...eaurora.org> wrote:
> Arend van Spriel <arend.vanspriel@...adcom.com> writes:
>
>>>> If I get it right, you mean something like this:
>>>>
>>>> mmc3: mmc@...2000 {
>>>> ...
>>>>          broken-sg-support;
>>>>          sd-head-align = 4;
>>>>          sd-sgentry-align = 512;
>>>>
>>>>          brcmf: wifi@1 {
>>>>                  ...
>>>>          };
>>>> };
>>>>
>>>> Where dt: bindings documentation for these entries should reside?
>>>> In generic MMC bindings? Well, this is the very special case and
>>>> mmc-linux maintainer will unlikely to accept these changes.
>>>> Also, extra kernel code modification might be required. It could make
>>>> quite trivial change much more complex.
>>>
>>> If the MMC maintainers are not copied on this patch series, it will
>>> likely be hard for them to identify this patch series and chime in...
>>
>> The main question is whether this is indeed a "very special case" as
>> Alexey claims it to be or that it is likely to be applicable to other
>> device and host combinations as you are suggesting.
>>
>> If these properties are imposed by the host or host controller it
>> would make sense to have these in the mmc bindings.
>
> BTW, last year we were discussing something similar (I mean related to
> alignment requirements) with ath10k SDIO patches and at the time the
> patch submitter was proposing to have a bounce buffer in ath10k to
> workaround that. I don't remember the details anymore, they are on the
> ath10k mailing list archive if anyone is curious to know, but I would
> not be surprised if they are similar as here. So there might be a need
> to solve this in a generic way (but not sure of course as I haven't
> checked the details).

I re-call something about these as well, here are the patches. Perhaps
I should pick some of them up...

https://patchwork.kernel.org/patch/10123137/
https://patchwork.kernel.org/patch/10123139/
https://patchwork.kernel.org/patch/10123141/
https://patchwork.kernel.org/patch/10123143/

Kind regards
Uffe