On 2/9/23 18:23, Tom Rini wrote:
On Sun, Feb 05, 2023 at 03:36:11PM -0700, Simon Glass wrote:
This converts 2 usages of this option to the non-SPL form, since there is
no SPL_ARCH_MVEBU defined in Kconfig
Signed-off-by: Simon Glass <[email protected]>
---
(no changes since v1)
drivers/mmc/mv_sdhci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
index 336ebf14102..20049981473 100644
--- a/drivers/mmc/mv_sdhci.c
+++ b/drivers/mmc/mv_sdhci.c
@@ -64,7 +64,7 @@ int mv_sdh_init(unsigned long regbase, u32 max_clk, u32
min_clk, u32 quirks)
host->ops = &mv_ops;
#endif
- if (CONFIG_IS_ENABLED(ARCH_MVEBU)) {
+ if (IS_ENABLED(CONFIG_ARCH_MVEBU)) {
/* Configure SDHCI MBUS mbus bridge windows */
sdhci_mvebu_mbus_config((void __iomem *)regbase);
}
@@ -103,7 +103,7 @@ static int mv_sdhci_probe(struct udevice *dev)
if (ret)
return ret;
- if (CONFIG_IS_ENABLED(ARCH_MVEBU)) {
+ if (IS_ENABLED(CONFIG_ARCH_MVEBU)) {
/* Configure SDHCI MBUS mbus bridge windows */
sdhci_mvebu_mbus_config(host->ioaddr);
}
So, a number of mvebu platforms now grow their SPL here, which is (a) a
functional change and (b) implies it's intentional. I'm adding Stefan
here to start to get a better handle on if this really should be like
this, or not.
I just checked this driver and it already depends on ARCH_MVEBU via
Kconfig. Even when used in SPL, the mbus windows should be configured,
even though I doubt that any target is using this driver in SPL.
I'll send a patchset to clean up this driver shortly. This patch can
be dropped then.
Thanks,
Stefan
