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, 05 Apr 2018 16:10:58 +0300
From:   Kalle Valo <>
To:     Ulf Hansson <>
Cc:     Arend van Spriel <>,
        Florian Fainelli <>,
        Alexey Roslyakov <>,
        Andrew Lunn <>, Rob Herring <>,
        Mark Rutland <>,
        Franky Lin <>,
        Hante Meuleman <>,
        Chi-Hsien Lin <>,
        Wright Feng <>,,,,
        Linux Kernel Mailing List <>,,
Subject: Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

Ulf Hansson <> writes:

> On 20 March 2018 at 10:55, Kalle Valo <> wrote:
>> Arend van Spriel <> 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...

Actually I was talking about a different patch, found it now:

ath10k_sdio: DMA bounce buffers for read write

Kalle Valo

Powered by blists - more mailing lists