linux-kernel - Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver

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]

Message-ID: <20150312072154.GB24885@pengutronix.de>
Date:	Thu, 12 Mar 2015 08:21:54 +0100
From:	Sascha Hauer <s.hauer@...gutronix.de>
To:	Kevin Hilman <khilman@...nel.org>
Cc:	James Liao <jamesjj.liao@...iatek.com>,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Matthias Brugger <matthias.bgg@...il.com>,
	linux-mediatek@...ts.infradead.org, kernel@...gutronix.de
Subject: Re: [PATCH 2/4] soc: Mediatek: Add SCPSYS power domain driver

On Wed, Mar 11, 2015 at 10:14:23AM -0700, Kevin Hilman wrote:
> Sascha Hauer <s.hauer@...gutronix.de> writes:
> 
> >> I asked our designer about the bus protection feature, here is his
> >> response:
> >> 
> >> "
> >> It's for unexpected signal glitch in Power switch process.
> >> 
> >> During Power switch process, we have clock switch, reset, isolation
> >> enable/disable and  power switch involved where the transition of
> >> asynchronous reset and  isolation is the most critical one,  which have
> >> risk to introduce a unexpected short period signal transition from
> >> MTCMOS’s interface to other alive HW . 
> >> "
> >> 
> >> That means it protects unexpected bus accessing from HW, not from SW. So
> >> it will not hide bugs from wrong SW access.
> >
> > Ok, thanks for clarifying. This means we should enable this feature
> > sooner or later. Since the audio driver which is likely the first user
> > of this driver doesn't need the protection bits I think we have some
> > time and can add the protection bits once the clock patches have been
> > merged.
> 
> Sounds OK to me.
> 
> But I still think it belongs in the infracfg layer, and not in the PM
> domain layer.

I already have plans how to put the code into the infracfg driver. Where
the code is going to be called from remains to be seen. The power domain
driver might or might not be a good place for it.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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/