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

Kory Maincent kory.maincent at bootlin.com
Tue Sep 9 16:23:56 CEST 2025


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.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


More information about the U-Boot mailing list