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]
Message-id: <6031045c-0eb2-7bea-1efd-874dade0f009@samsung.com>
Date:   Mon, 31 Oct 2016 20:59:10 +0900
From:   Jaehoon Chung <jh80.chung@...sung.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Zach Brown <zach.brown@...com>
Cc:     Adrian Hunter <adrian.hunter@...el.com>,
        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 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.

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
> 
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ