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]
Date:	Tue, 19 Apr 2016 21:20:18 +0200
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Olliver Schinagl <oliver@...inagl.nl>
Cc:	Hans de Goede <hdegoede@...hat.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Chen-Yu Tsai <wens@...e.org>,
	Venu Byravarasu <vbyravarasu@...dia.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Michal Hocko <mhocko@...e.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Sudeep Holla <Sudeep.Holla@....com>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Wenkai Du <wenkai.du@...el.com>,
	Chaotian Jing <chaotian.jing@...iatek.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
	Jaehoon Chung <jh80.chung@...sung.com>,
	Michal Suchanek <hramrach@...il.com>,
	linux-mmc <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/2] mmc: core: Improve marking broken HPI through devicetree

[...]

> Well I think we still have a very small sample size, the sun4i, sun5i and
> sun7i boards (all using the same mmc controller afaik) have the broken-hpi
> set, the sun6i and sun8i seem to be working fine (different mmc
> controller?).
> I'm not so sure it is an eMMC specific problem though. The module we're
> using is a high-end micron part, industrial grade. Granted, it could be
> still broken there, but I find it less likely. Micron has an interessting
> technical document:
> "TN-52-05 e.EMMC Linux Enablement"
> talking specifically about HPI on eMMC.
> It also mentions HPI is a mmc/jedic 4.41 thing, afaik our controller is only
> 4.3 (which might not even matter according to Ulf if it is just a command).
>
> The datasheet of the chip I use, MTFC4GACAANA, also mentions explicitly that
> it supports HPI.
>
> Granted, it could still be broken, but I have doubts.

Perhaps the same eMMC is used without errors on other controllers?

>
>>
>> But given how rare eMMC-s are on sun4i/sun5i/sun7i I think the current
>> solution where we set a flag on the emmc dt node rather then on the
>> host node / in the host driver is fine.
>
> Yeah it is very limited, that is true, and I suppose I can live with that.
>>
>>
>> Taking your case into account too, that will bring us up to 2 cases
>> where we set the broken-hpi flag on the emmc node, which does not
>> really seem like a number to worry about.
>
> Actually, 4 :), there are 3 sun5i (tablets?) devices that suffer from this
> and my device now. The sun6i and sun8i devices are only 2 (the sinlinx
> devices in the current kernel) that a very quick grep (mmc-card ) showed.
> Grepping for non-removable yielded a bit more, like the chip sun5i-like
> device with a "non-removable" mmc, not sure what to make of that though.
>>
>>
>> TL;DR: Thanks for writing this patch set, but given recent developments
>> I believe that it is best to keep handling broken-hpi as we are doing
>> in current kernels and no changes are necessary.
>
> I would still recommend to add the capability and raise the flag for the
> sun[457]i devices though, as my gut thinks it's a problem with the sunxi IP
> there. But with the emmc-card level work around, it does solve/fix it, so
> what is the best way?

The best is clearly to make a proper debug investigation before we
decide to add a DT binding for the host.

I don't know on what level you are able to measure signals on the HW,
but if not, perhaps the newly TRACE support in the MMC core can help.

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ