linux-kernel - Re: [RFC PATCH] arm64: defconfig: Set MFD_TPS6594

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: <ZsXE427Dh6w35wvz@arm.com>
Date: Wed, 21 Aug 2024 11:43:47 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Nishanth Menon <nm@...com>, Arnd Bergmann <arnd@...nel.org>,
	Judith Mendez <jm@...com>, Will Deacon <will@...nel.org>,
	Bjorn Andersson <quic_bjorande@...cinc.com>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
	Neil Armstrong <neil.armstrong@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Vignesh Raghavendra <vigneshr@...com>, Bryan Brattlof <bb@...com>
Subject: Re: [RFC PATCH] arm64: defconfig: Set MFD_TPS6594_I2C as built-in

On Wed, Aug 21, 2024 at 08:33:49AM +0200, Krzysztof Kozlowski wrote:
> On 20/08/2024 13:53, Nishanth Menon wrote:
> > On 23:01-20240819, Krzysztof Kozlowski wrote:
> >> On 19/08/2024 22:43, Judith Mendez wrote:
> >>> SK-AM62A-LP is a device targeting automotive front-camera applications
> >>> among other use-cases. It utilizes the TPS6593x PMIC (interfaced over I2C)
> >>> to power the SoC and various other peripherals on the board [1].
> >>>
> >>> MMCSD requires the PMIC to be setup correctly before setting the bus
> >>> pins to 1.8V using the TPS6594 driver interfaced over i2c.
> >>>
> >>> Currently, the following could be seen when booting the am62ax platform:
> >>>
> >>> "platform fa00000.mmc: deferred probe pending: platform: supplier regulator-5 not ready"
> >>> "vdd_mmc1: disabling"
> >>>
> >>> and a failure to boot the SK-AM62A-LP.
> >>>
> >>> One solution is to use initramfs [2], but using initramfs increases the
> >>> boot time for this automotive solution which requires faster boot time
> >>> parameters.
> >>
> >> This is a defconfig, not a distro/product config, so your product
> >> constraints are not really relevant. You are supposed to boot defconfig
> >> with proper initramfs with necessary modules.
[...]
> > I understand that you have provided similar comments for other
> > platforms[1] as well, but, I am now wondering if this is a new rule
> > we are taking in aarch64 platforms to allow just initramfs and
> > force all drivers to be modules (I understand that is the default
[...]
> There are different point of views. I am presenting here mine and I back
> it with arguments, that such changes accumulate and have impact on
> developers workflow.
> 
> Defconfig is for developers and as starting point for distros or
> products. Not as final product defconfig.

Drive-by comment here (defconfig is mostly an arm-soc thing): in general
I agree with this position. Just because a product cannot (efficiently)
use initramfs, we shouldn't pollute the default built-ins with random
drivers. If you want something optimal for your product, just tweak the
defconfig or take it up with the distros. I'm fine with built-ins,
however, if they are required before reaching the initramfs stage (e.g.
interrupt controllers) but that's not the case here.

-- 
Catalin