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]
Message-ID: <d3b574f5-b49e-60be-1559-b98e0832bd62@arm.com>
Date:   Fri, 20 Aug 2021 15:49:10 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Johan Jonker <jbx6244@...il.com>, heiko@...ech.de
Cc:     robh+dt@...nel.org, linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, paweljarosz3691@...il.com
Subject: Re: [PATCH] ARM: dts: rockchip: remove cap-mmc-highspeed property
 from mk808 &mmc0 node

On 2021-08-20 15:41, Johan Jonker wrote:
> 
> 
> On 8/20/21 4:17 PM, Robin Murphy wrote:
>> On 2021-08-20 14:19, Johan Jonker wrote:
>>> On the MK808 only a microSD slot is connected with the SDMMC Host
>>> Controller,
>>> so remove the cap-mmc-highspeed property from the &mmc0 node.
>>
>> Why, does it do any harm?
> 
> Harm not. Example rk3066 u-boot:
> 
>>>>> sd_select_mode_and_width
> sd card: widths [4, 1, ..] modes [MMC legacy, SD High Speed (50MHz), UHS
> SDR12 (25MHz), UHS SDR25 (50MHz), ..]
> host: widths [4, 1, ..] modes [MMC legacy, MMC High Speed (26MHz), SD
> High Speed (50MHz), MMC High Speed (52MHz), ..]
> trying mode SD High Speed (50MHz) width 4 (at 50 MHz)
> 
> I would say only advertise host capabilities that are under normal
> circumstances occur. How realistic is it to use a TF/Micro SD TO SD Card
> Extension Cable Adapter (giggle) for a deprecated mmc card?

Well, if you want a far more realistic example:

https://www.hardkernel.com/shop/emmc-module-reader-board-for-os-upgrade/

Who are we to dictate what "normal circumstances" are, and what do we 
gain by removing support for modes that could work fine and at least be 
useful to someone on occasion?

Robin.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ