Hi Johan
On Sat, Feb 25, 2023 at 10:50 AM Johan Jonker <jbx6...@gmail.com> wrote:
>
>
>
> On 2/25/23 10:26, Michael Nazzareno Trimarchi wrote:
> > Hi Johan
> >
> > On Thu, Feb 23, 2023 at 3:06 PM Johan Jonker <jbx6...@gmail.com> wrote:
> >>
> >> The fdt_addr_t and phys_addr_t size have been decoupled.
> >> A 32bit CPU can expect 64-bit data from the device tree parser,
> >> so convert devfdt_get_addr_index output to phys_addr_t in the
> >> spi-aspeed-smc.c file. Also fix dev_dbg to be able to handle
> >> both sizes.
> >>
> >> Signed-off-by: Johan Jonker <jbx6...@gmail.com>
> >> ---
> >>
> >> Note:
> >>
> >> This is needed for a Rockchip patch serie to pass the test and
> >> must be merged before by Rockchip maintainers:
> >>
> >> [PATCH v4 00/11] Fixes for Rockchip NFC driver part 1
> >> https://lore.kernel.org/u-boot/f3dba231-4a55-0a94-dfab-5cab1419d...@gmail.com/
> >>
> >> Request for hardware test by Aspeed people.
> >> ---
> >> drivers/spi/spi-aspeed-smc.c | 8 ++++----
> >> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
> >> index a3c96333..17696441 100644
> >> --- a/drivers/spi/spi-aspeed-smc.c
> >> +++ b/drivers/spi/spi-aspeed-smc.c
> >> @@ -1125,14 +1125,14 @@ static int apseed_spi_of_to_plat(struct udevice
> >> *bus)
> >> int ret;
> >> struct clk hclk;
> >>
> >> - priv->regs = (void __iomem *)devfdt_get_addr_index(bus, 0);
> >> + priv->regs = (void __iomem
> >> *)((phys_addr_t)devfdt_get_addr_index(bus, 0));
> >
>
> > devfdt_get_addr_index_ptr is not the right way?
>
> That may work.
>
> >
> >> if ((u32)priv->regs == FDT_ADDR_T_NONE) {
> >> dev_err(bus, "wrong ctrl base\n");
> >> return -ENODEV;
> >> }
> >>
> >> plat->ahb_base =
> >> - (void __iomem *)devfdt_get_addr_size_index(bus, 1,
> >> &plat->ahb_sz);
> >> + (void __iomem
> >> *)((phys_addr_t)devfdt_get_addr_size_index(bus, 1, &plat->ahb_sz));
> >
>
> > devfdt_get_addr_index_ptr, same here
>
> fdt_addr_t devfdt_get_addr_size_index(const struct udevice *dev, int index,
> fdt_size_t *size)
> vs
>
> void *devfdt_get_addr_index_ptr(const struct udevice *dev, int index)
>
> ===
>
> devfdt_get_addr_index_ptr does not offer the ahb_sz size.
>
> https://elixir.bootlin.com/u-boot/latest/source/drivers/core/fdtaddr.c#L112
>
> This function is used for that in devfdt_get_addr_size_index:
>
> fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, dev_of_offset(dev),
> "reg", index, size, false);
>
> What would you suggest? Keep the cast or use
> fdtdec_get_addr_size_auto_noparent ?
>
> I'm a little bit "reluctant" to poke in code that I don't have hardware for.
>
Something like this
diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
index 91bcd1a2c2..d18749c3fd 100644
--- a/drivers/core/fdtaddr.c
+++ b/drivers/core/fdtaddr.c
@@ -122,6 +122,14 @@ fdt_addr_t devfdt_get_addr_size_index(const
struct udevice *dev, int index,
#endif
}
+void *devfdt_get_addr_size_index_ptr(const struct udevice *dev, int index,
+ fdt_size_t *size)
+{
+ fdt_addr_t addr = devfdt_get_addr_size_index(dev, index, size);
+
+ return (addr == FDT_ADDR_T_NONE) ? NULL : (void *)(uintptr_t)addr;
+}
+
Michael
> Johan
>
> >
> >> if ((u32)plat->ahb_base == FDT_ADDR_T_NONE) {
> >> dev_err(bus, "wrong AHB base\n");
> >> return -ENODEV;
> >> @@ -1151,8 +1151,8 @@ static int apseed_spi_of_to_plat(struct udevice *bus)
> >> plat->hclk_rate = clk_get_rate(&hclk);
> >> clk_free(&hclk);
> >>
> >> - dev_dbg(bus, "ctrl_base = 0x%x, ahb_base = 0x%p, size = 0x%lx\n",
> >> - (u32)priv->regs, plat->ahb_base, plat->ahb_sz);
> >> + dev_dbg(bus, "ctrl_base = 0x%x, ahb_base = 0x%p, size = 0x%llx\n",
> >> + (u32)priv->regs, plat->ahb_base, (fdt64_t)plat->ahb_sz);
> >> dev_dbg(bus, "hclk = %dMHz, max_cs = %d\n",
> >> plat->hclk_rate / 1000000, plat->max_cs);
> >>
> >> --
> >
> > Michael
> >
> >> 2.20.1
> >>
> >
> >
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__________________________________
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
