[PATCH v2 4/4] soc: samsung: exynos-chipid: convert to driver and merge exynos-asv

'Krzysztof Kozlowski' krzk at kernel.org
Tue Dec 8 03:47:49 EST 2020


On Tue, Dec 08, 2020 at 12:31:23PM +0530, Pankaj Dubey wrote:
> 
> 
> > -----Original Message-----
> > From: Krzysztof Kozlowski <krzk at kernel.org>
> > Sent: Tuesday, December 8, 2020 12:35 AM
> > To: Krzysztof Kozlowski <krzk at kernel.org>; linux-arm-
> > kernel at lists.infradead.org; linux-samsung-soc at vger.kernel.org; linux-
> > kernel at vger.kernel.org
> > Cc: Sylwester Nawrocki <snawrocki at kernel.org>; Marek Szyprowski
> > <m.szyprowski at samsung.com>; Bartlomiej Zolnierkiewicz
> > <b.zolnierkie at samsung.com>; Arnd Bergmann <arnd at arndb.de>; Chanwoo
> > Choi <cw00.choi at samsung.com>; Alim Akhtar <alim.akhtar at samsung.com>;
> > Pankaj Dubey <pankaj.dubey at samsung.com>
> > Subject: [PATCH v2 4/4] soc: samsung: exynos-chipid: convert to driver and
> > merge exynos-asv
> > 
> > The Exynos Chip ID driver on Exynos SoCs has so far only informational
> > purpose - to expose the SoC device in sysfs.  No other drivers depend on
> it
> > so there is really no benefit of initializing it early.
> > 
> 
> One of the intention behind initializing Exynos Chip ID driver in early
> stage was to simplify code in arch/arm/mach-exynos specifically calls such
> as soc_is_exynosXXXX. 
> But there were lot of resistance from community to add any such calls (or
> exported function) from mach-exynos files to the driver file. Whereas some
> other SoC code is using the same, e.g. tegra_get_chip_id being called from
> mach-tegra files to drivers/soc/tegra/. Unfortunately we could not accept
> similar solution for Exynos SoC and hence could not get rid of
> soc_is_exynosxXXX and similar macros from various file in mach-exynos and
> eventually converting those files into a full-fledged driver files. 
> 
> Any opinion how can we achieve this if we convert Exynos Chip ID driver to a
> regular driver?

a. Some parts of mach code can be moved to drivers and then use OF calls.

b. The ones which cannot be moved, could use soc_device_match() assuming
   they are called after the soc-bus is operational - so after
   core_initcalls.

c. The ones which are called early or without cache coherency
   (soc_device_match() uses krefs()), cannot be converted.

This chip ID conversion indeed kills case (b) above... which I am not
sure is worth bothering. Which parts of code could be moved like this?
Not mentioning that none of this work have happened since few years...

Best regards,
Krzysztof



More information about the linux-arm-kernel mailing list