linux-kernel - Re: [RFC 1/2] mmc: sdhci: dt: Add device tree properties sdhci-caps and sdhci-caps-mask

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7bc4cb38-6864-c87e-390e-7f9f3f133dd6@intel.com>
Date:   Mon, 31 Oct 2016 14:34:36 +0200
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Jaehoon Chung <jh80.chung@...sung.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Zach Brown <zach.brown@...com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 1/2] mmc: sdhci: dt: Add device tree properties sdhci-caps
 and sdhci-caps-mask

On 31/10/16 13:59, Jaehoon Chung wrote:
> On 10/28/2016 05:12 PM, Ulf Hansson wrote:
>> On 25 October 2016 at 21:58, Zach Brown <zach.brown@...com> wrote:
>>> On some systems the sdhci capabilty registers are incorrect for one
>>> reason or another.
>>>
>>> The sdhci-caps-mask property specifies which bits in the registers
>>> are incorrect and should be turned off before using sdhci-caps to turn
>>> on bits.
>>>
>>> The sdhci-caps property specifies which bits should be turned on.
>>>
>>> Signed-off-by: Zach Brown <zach.brown@...com>
>>> ---
>>>  Documentation/devicetree/bindings/mmc/mmc.txt | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
>>> index 8a37782..1415aa0 100644
>>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
>>
>> The bindings in this document are common mmc DT bindings, not bindings
>> specific to a mmc controller.
>>
>> So unless these bindings are applicable for another controller than
>> sdhci, I suggest we create a new file to document these.
>> How about Documentation/devicetree/bindings/mmc/sdhci.txt?
>>
>>> @@ -52,6 +52,13 @@ Optional properties:
>>>  - no-sdio: controller is limited to send sdio cmd during initialization
>>>  - no-sd: controller is limited to send sd cmd during initialization
>>>  - no-mmc: controller is limited to send mmc cmd during initialization
>>> +- sdhci-caps-mask: The sdhci capabilities registers are incorrect. This 64bit
>>
>> /s/registers/register
>>
>> This applies to some more places below as well.
>>
>>> +  property corresponds to the bits in the sdhci capabilty registers. If the bit
>>> +  is on in the mask then the bit is incorrect in the registers and should be
>>> +  turned off.
>>> +- sdhci-caps: The sdhci capabilities registers are incorrect. This 64bit
>>> +  property corresponds to the bits in the sdhci capability registers. If the
>>> +  bit is on in the property then the bit should be on in the reigsters.
>>
>> /s/reigsters/register
>>
>>>
>>>  *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
>>>  polarity properties, we have to fix the meaning of the "normal" and "inverted"
>>> --
>>> 2.7.4
>>>
>>
>> Overall, I like this idea as it gives us good flexibility. Thus it
>> should avoid us to having to add any further new similar "sdhci broken
>> cap" DT binding. We could also decide to start deprecate some of the
>> existing sdhci bindings, if we think that makes sense.
>>
>> The downside is that we get a "magic" hex value in the dts. Although,
>> people could address this issue by providing some comments about what
>> the bits it means in the dts files themselves.
> 
> I think it's not good about getting "magic" hex value.
> In my experience, it's too difficult what bits means and calculate..
> Because some people who i know had already used like this.(locally..)
> 
> It needs to consider this...otherwise..it should become really complex magic code.

The bits we use are listed in sdhci.h and how we use them can be determined
from the sdhci source code.  Also, from the hardware perspective, there is
the SDHCI specification.  So what the bits mean is readily available.

With regard to calculating the values, won't it be obvious from testing if
they are wrong?

> 
> Best Regards,
> Jaehoon Chung
> 
>>
>> Let's see what Rob thinks about this.
>>
>> Kind regards
>> Uffe
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
> 
>