Messages in this thread | | | Date | Tue, 8 Dec 2020 09:47:49 +0100 | From | 'Krzysztof Kozlowski' <> | Subject | Re: [PATCH v2 4/4] soc: samsung: exynos-chipid: convert to driver and merge exynos-asv |
| |
On Tue, Dec 08, 2020 at 12:31:23PM +0530, Pankaj Dubey wrote: > > > > -----Original Message----- > > From: Krzysztof Kozlowski <krzk@kernel.org> > > Sent: Tuesday, December 8, 2020 12:35 AM > > To: Krzysztof Kozlowski <krzk@kernel.org>; linux-arm- > > kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; linux- > > kernel@vger.kernel.org > > Cc: Sylwester Nawrocki <snawrocki@kernel.org>; Marek Szyprowski > > <m.szyprowski@samsung.com>; Bartlomiej Zolnierkiewicz > > <b.zolnierkie@samsung.com>; Arnd Bergmann <arnd@arndb.de>; Chanwoo > > Choi <cw00.choi@samsung.com>; Alim Akhtar <alim.akhtar@samsung.com>; > > Pankaj Dubey <pankaj.dubey@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
| |