linux-kernel - Re: [PATCH] mmc: core: add auto bkops support

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: <CAPDyKFqehk9Prnz_KM+7w5CzWd-wC51C=Searke-tH7hJqYaKA@mail.gmail.com>
Date:	Mon, 27 Jun 2016 11:00:07 +0200
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Shawn Lin <shawn.lin@...k-chips.com>
Cc:	Adrian Hunter <adrian.hunter@...el.com>,
	Jaehoon Chung <jh80.chung@...sung.com>,
	Alex Lemberg <alex.lemberg@...disk.com>,
	linux-mmc <linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Doug Anderson <dianders@...omium.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>
Subject: Re: [PATCH] mmc: core: add auto bkops support

[...]

>>>> one possible way is to control it by mmc-utils on
>>>> user space?  So we should add a cmd for mmc-utils
>>>> there?
>>>
>>>
>>> That would be consistent with manual bkops.
>>>
>>
>>> From my first impression I agree, as that is the policy we have been
>>
>> sticking to when writing to persistent EXT_CSD persistent .
>> Although, in this case, I am actually wondering on what is the best
>> approach.
>
>
> I don't know what is the real meaning of "persistent". :)
> I don't know should we count auto bkops as the persistent
> registers....HS_TIMING and BUS_WIDTH should also be persistent
> registers as them are always used after initialization if not changing
> them?
>
> IHMO the more reasonable way is that:
> IIRC many settings for  EXT_CSD should be OTP, like hw-reset(162),
> reliable write(167) fw-configure(169)..etc, which are marked as R/W.
> These should be controlled by userpace or even by firmware when
> flashing emmc, like reliable write...

Yes, that's makes sense to me. OTP registers must only be written to
via mmc utils/userspace.

>
>
> I'm not sure whether should I updete this $SUBJUCT or migirating it to
> userspace... We need to come to an agreement :)
>

I don't have any issue to allow all non-OTP registers bits to be written.

Kind regards
Uffe