linux-kernel - Re: [PATCH v2 0/11] Changes to support 150 MHz eMMC on rk3399

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: <2340840.IUG4rtlpvT@phil>
Date:	Fri, 17 Jun 2016 01:39:55 +0200
From:	Heiko Stuebner <heiko@...ech.de>
To:	Douglas Anderson <dianders@...omium.org>
Cc:	ulf.hansson@...aro.org, kishon@...com, robh+dt@...nel.org,
	shawn.lin@...k-chips.com, xzy.xu@...k-chips.com,
	briannorris@...omium.org, adrian.hunter@...el.com,
	linux-rockchip@...ts.infradead.org, linux-mmc@...r.kernel.org,
	devicetree@...r.kernel.org, mark.rutland@....com,
	catalin.marinas@....com, will.deacon@....com,
	zhengxing@...k-chips.com, michal.simek@...inx.com,
	linux-arm-kernel@...ts.infradead.org, jay.xu@...k-chips.com,
	wxt@...k-chips.com, pawel.moll@....com,
	ijc+devicetree@...lion.org.uk, soren.brinkmann@...inx.com,
	linux-kernel@...r.kernel.org, galak@...eaurora.org
Subject: Re: [PATCH v2 0/11] Changes to support 150 MHz eMMC on rk3399

Am Montag, 13. Juni 2016, 16:04:24 schrieb Douglas Anderson:
> The theme of this series of patches is to try to allow running the eMMC
> at 150 MHz on the rk3399 SoC, though the changes should still be correct
> and have merit on their own.  The motivation for running at 150 MHz is
> that doing so improves signal integrity and (with some eMMC devices)
> doesn't affect throughput.
> 
> These patches have been structured to keep things as separate as
> possible, but nevertheless there are still some dependencies between
> patches.  It probably makes the most sense for all of the non-device
> tree patches to go through a single tree.  If others agree, perhaps the
> most sane would be to get Acks from PHY maintainers and then to land the
> patches in the MMC tree.  Device tree patches should be able to be
> landed separately and the worst what would happen is a warning in the
> kernel log if you have the code without the device tree.

while my evaluation board does not seem to have an enhanced strobe emmc, it 
nevertheless still runs fine with these patches applied, for the series 
(including the separate v2.1) on a rk3399-evb:

Tested-by: Heiko Stuebner <heiko@...ech.de>