linux-kernel - Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

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]

Date:	Thu, 22 Oct 2015 10:33:10 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Javier Martinez Canillas <javier@....samsung.com>
Cc:	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Markus Reichl <m.reichl@...etechno.de>,
	Anand Moon <linux.amoon@...il.com>,
	linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
	Alim Akhtar <alim.akhtar@...sung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	Alexandre Courbot <acourbot@...dia.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Heiko Stübner <heiko@...ech.de>
Subject: Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

Hi,

On Thu, Oct 22, 2015 at 9:07 AM, Javier Martinez Canillas
<javier@....samsung.com> wrote:
>> Note that personally I would only choose the "highest" priority as an
>> absolute last resort.  Leaving a little extra slack in there means
>> that when the next person comes up with a really good reason to run
>> before you do that they can do it without changing your code.  All
>> good BASIC programmers know to skip "10" in their first version for
>> just this reason.  ;)
>>
>> If I were to pick a number, I suppose I'd pick something like "220",
>> but that's pretty arbitrary.  I would have picked 200 except that it
>> appears that would race with veyron's choice.
>>
>
> Yes, I actually gave some thought about choosing a number since I didn't
> want to come with another arbitrary one. That's why I tried to understand
> the policy as I mentioned before but I didn't find anything besides the
> values listed in the register_restart_handler() doc: 0, 128 and 255.
>
> It seems that most default system restart handlers use 128 and that's
> the reason why gpio-restart and mmc-pwrseq-emmc use 129 and other restart
> handlers that can be registered via DT use 192 (which is in the middle of
> 128 and 255).
>
> So I actually thought to use a number in between 192 and 255 (i.e: 220)
> but then there could be another platform that uses 221 instead of 200
> so eMMC restart won't work there. That's why I finally chose the highest.
>
> Do you know why the priority 200 was chosen for veyron gpi-restart ooi?

In David Riley's original patch the example had 200:
    https://patchwork.kernel.org/patch/4784611/

In the ChromeOS 3.14 kernel tree I believe we're still using the old
patch (we still have /bits/ 8).  ...it looks like I'm the one who
originally added it to the veyron dts file and I set it to 200, so I'd
presume that I just copied the example and called it "good enough".

I'm sure the upstream dts just used the number from the ChromeOS 3.14 tree...

Note that the GPIO-restart definitely need to be higher priorities
than others in the system.  The two I know of off the top of my head
are the "dw watchdog" and the one in the CRU.  The "dw watchdog" has a
priority of 128 and so does the one in "rockchip/clk.c".  Hrm,
actually, the Rockchip-specific one should probably have its priority
bumped up since it seems better not to just randomly pick between
these two...


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/