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, 31 Dec 2015 15:45:22 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	James Liao <jamesjj.liao@...iatek.com>
Cc:	devicetree@...r.kernel.org, srv_heupstream@...iatek.com,
	Kevin Hilman <khilman@...nel.org>,
	linux-kernel@...r.kernel.org, linux-mediatek@...ts.infradead.org,
	Sascha Hauer <kernel@...gutronix.de>,
	Matthias Brugger <matthias.bgg@...il.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/4] soc: mediatek: Init MT8173 scpsys driver earlier

On Thursday 31 December 2015 17:16:34 James Liao wrote:
> 
> """
> Take a example for our IOMMU(M4U) and SMI.  The IOMMU which is
> subsys_init defaultly will depend on SMI. 
> The SMI is a bridge between m4u and the Multimedia HW.  About the HW
> block diagram and more other information please help check  [1].
> SMI is responsible to enable/disable iommu and help transfer data for
> each Multimedia HW,  Both have to wait until the power and the clocks is
> enabled.  
> 
> So our iommu should probe done after smi, smi should be after
> power-domain, and all the iommu consumer(display/vdec/venc/camera etc.)
> should be after the iommu.
> Then all the multimedia module will be delayed by power-domain who is
> module_init currently.
> 
> After grep, we get some example whose  pm is not module_init:
> core_initcall(exynos4_pm_init_power_domain);
> subsys_initcall(imx_pgc_init);
> 
> So we expect move the power-domain initial more earlier too.  The
> power-domain seems to be a basic module like ccf.
> Is there some special reason about we should use module_init,  or do you
> have any concern if we change it?
> Thanks.

Ok, got it. Generally, we should try to avoid using the earlier initcall
levels, but a few things like clock controllers, iommus etc are special
enough that we need to make sure their dependencies are there by the
time those are probed.

Please put your explanation above into the patch changelog and add a code
comment about the IOMMU next to the subsys_initcall() so it doesn't
accidentally get changed when someone tries to do a code cleanup.

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

Powered by blists - more mailing lists