linux-kernel - Re: [PATCH 1/3] ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALLhW=50Ro5T=u7KTObT6g7eF=835Ywj9sQ+z8kZ_+5U7U7fJA@mail.gmail.com>
Date:	Tue, 21 Aug 2012 12:48:16 -0500
From:	Omar Ramirez Luna <omar.luna@...aro.org>
To:	Benoit Cousson <b-cousson@...com>
Cc:	Paul Walmsley <paul@...an.com>, Tony Lindgren <tony@...mide.com>,
	Russell King <linux@....linux.org.uk>,
	Kevin Hilman <khilman@...com>,
	Ohad Ben-Cohen <ohad@...ery.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] ARM: OMAP: hwmod: partially un-reset hwmods might not
 be properly enabled

On 20 August 2012 09:49, Benoit Cousson <b-cousson@...com> wrote:
> On 07/16/2012 09:21 PM, Omar Ramirez Luna wrote:
>> Some IP blocks might not be using/controlling more than one
>> reset line, this check loosens the restriction to fully use
>> hwmod framework for those drivers.
>>
>> E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1.
>> - cpu1 might not be used and hence (with previous check)
>>   won't be fully enabled by hwmod code.
>
> You mean that you might have some case where you need to enable the
> mmu_cache and cpu0 and thus deassert only the mmu/cpu0 while keeping the
> cpu1 under reset?

Looks like I didn't reply to this question.

Yes, initially cpu1 might not be used and kept under reset. Or even
the mmu can be taken out of reset and configured, and cpu0 after it,
creating a small window where one is taken out and the other is under
reset.

> So the any_hardreset is indeed not appropriate in that case.
>
> In fact, since the hardreset cannot be handled at all by the hwmod fmwk,
> I'm even wondering if we should take care of checking the state at all.
> But as Paul stated, if was done due to the lack of understanding about
> the diver usage, so maybe things will become clearer once we will have
> that code available.

I still think it can, in fact all the code I'm using comes from the
hwmod fmwk. _deassert_reset is almost the same as _enable, I left it
this way to avoid reintroducing the issues that caused reset code to
be stripped out from _enable path.

Regards,

Omar
--
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/