[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