linux-kernel - Re: [PATCH] OMAP: hwmod: add kernel cmdline flag to avoid resetting IP blocks during init

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: <20110706064116.GH5783@atomide.com>
Date:	Tue, 5 Jul 2011 23:41:16 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Paul Walmsley <paul@...an.com>
Cc:	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Aaro Koskinen <aaro.koskinen@...ia.com>,
	Rajendra Nayak <rnayak@...com>,
	Benoît Cousson <b-cousson@...com>,
	Michael Buesch <mb@...sch.de>
Subject: Re: [PATCH] OMAP: hwmod: add kernel cmdline flag to avoid
 resetting IP blocks during init

* Paul Walmsley <paul@...an.com> [110705 18:37]:
> cc'ing Aaro
> 
> On Mon, 4 Jul 2011, Tony Lindgren wrote:
> 
> > Also related is the gptimer12 on secure omaps as reported by Aaro.
> 
> This problem is actually worse.  In this case it's not just preventing 
> reset; we must prevent the kernel from using the device at all. My 
> understanding is also that it's the X-Loader or bootloader -- or more 
> broadly, secure mode code -- that actually chooses which devices are 
> protected in this way.  In other words, we can't make any automatic 
> decisions that are based on knowing that a chip is a high-security chip -- 
> it will need to be defined by the board file :-(
> 
> For this case, we probably need some board file function to tell the hwmod 
> code to disregard a device completely, to tell the kernel to pretend that 
> the device does not exist.

Yeah that should be done in a generic way. Some shared devices can also
be used by a coprocessor like the DSP instead.

So basically we want to tell the following from the board file or board
specific .dts file:

- Device is being used on the board and can be reset and configured.
  This is the usual case.

- Device is being used on the board but can't be reset. This is the
  case for booting Linux from other operating systems initially where
  you want to keep the LCD on for debug console.

- Device is not being used on the board but can be reset for decent PM.
  This is often needed in cases where the bootloader just enables all the
  clocks.

- Device is reserved by secure mode or a coprocessor. In this case
  the device can't be reset.

So I guess that makes the flags noreset, disabled and unavailable?

For the devices with no special flags we would then reset the device.

Regards,

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