[PATCH 1/1] board: ti: am335x: Do not call disabled PMIC functions

[Tom Rini]

On Tue, Sep 09, 2025 at 04:23:56PM +0200, Kory Maincent wrote:
> On Tue, 9 Sep 2025 12:45:10 +0000
> Maarten Brock <Maarten.Brock at sttls.nl> wrote:
> 
> > > From: Kory Maincent <kory.maincent at bootlin.com>
> > > 
> > > On Mon, 8 Sep 2025 16:05:04 +0000
> > > Maarten Brock <Maarten.Brock at sttls.nl> wrote:
> > >   
> > > > When PMIC drivers are disabled their functions should not be called.
> > > >
> > > > Signed-off-by: Maarten Brock <maarten.brock at sttls.nl>  
> > > 
> > > There is already board check with board_is_bone or board_is_beaglebonex
> > > call. Is it not sufficient? Why would we disable the PMIC support if we are
> > > using one of these boards?  
> > 
> > Why would you keep the PMIC support if you are NOT using one of those boards?
> > Note that those checks are at runtime, not at compile time.
> > 
> > > Maybe the only relevant return would be in scale_vcores_generic, as it
> > > matches the case where the board is not known.  
> > 
> > When a board is using a certain PMIC it should be possible to deselect all
> > other PMICs that are not present. There is no point in keeping unused code
> > in the binary. Isn't that the whole idea of the configuration?
> > The current situation gives a build failure when the unused PMIC is
> > deselected.
> > 
> > This file board/ti/am335x/board.c gives the impression to be useable for all
> > AM335X based boards, including those yet unknown. What if a board does not
> > need any PMIC configuration, because the default strapped config is enough,
> > does one still need to drag those drivers along?
> > 
> > Or to turn things around: if configuration is not to be used to create the
> > smallest possible executable image, then why not incorporate all PMIC drivers
> > by default? All those config options could then be removed to simplify things
> > a lot.
> 
> Indeed, I hadn't understood that you would face a build error as the PMIC
> functions are not defined if we disable PMIC configs.
> 
> I think the first issue is the design of this board.c file, but, well it is
> U-boot typical design. 
> And scale_vcores_generic() is not a generic function at all ...
> 
> Ok, your change are legit after all.

A thing to keep in mind is that am335x_evm is intended for the TI EVM
family of boards and look-alikes (so all of the beagles which are
kinda-sorta TI EVMs depending on when you asked someone).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250909/b19b579e/attachment.sig>