Re: [PATCH v6 0/8] Add virtio-mmio support to m68k virt machine

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 2263 bytes --]

On Mon, May 11, 2026 at 05:50:40PM +0900, Daniel Palmer wrote:
> Hi Tom,
> 
> On Sat, 9 May 2026 at 04:29, Tom Rini <trini@konsulko.com> wrote:
> 
> > We hit another error in CI now, with "allyesconfig":
> > drivers/sysreset/sysreset_qemu_virt_ctrl.c: In function 'qemu_virt_ctrl_request':
> > drivers/sysreset/sysreset_qemu_virt_ctrl.c:41:37: error: passing argument 2 of '__raw_writel' makes pointer from integer without a cast [-Werror=int-conversion]
> >    41 |         __raw_writel(val, plat->reg + VIRT_CTRL_REG_CMD);
> >       |                                     ^
> >       |                                     |
> >       |                                     phys_addr_t {aka long long unsigned int}
> > In file included from ./arch/sandbox/include/asm/io.h:257,
> >                  from drivers/sysreset/sysreset_qemu_virt_ctrl.c:11:
> > include/asm-generic/io.h:168:67: note: expected 'volatile void *' but argument is of type 'phys_addr_t' {aka 'long long unsigned int'}
> >   168 | static inline void __raw_writel(u32 value, volatile void __iomem *addr)
> >       |
> 
> mmm that one is interesting. It seems like it's triggering because
> sandbox doesn't define __raw_writel() so the generic version is being
> used and that is a static inline function so it doesn't cast the
> address to a pointer like most places do. But for riscv writel() is
> already a static inline function so it should have broke the build for
> riscv before the change?
> 
> Anyhow, I added a patch that I think solves it for v7.
> 
> > Please see https://docs.u-boot.org/en/latest/develop/ci_testing.html for
> > v7, thanks.
> 
> I didn't realise I could trigger a pipeline run so thanks for the
> information. Anyhow, I triggered a run for v6 and it completed and I
> couldn't actually find where the error in the result. I triggered it
> again for the v7 and it passed too. Is there something I should check
> before I send it again? The run is here:
> https://github.com/u-boot/u-boot/pull/964/checks

That's very strange. I just re-checked v6 and still get:
https://source.denx.de/u-boot/u-boot/-/jobs/1446347 and both Azure and
Gitlab run the job the same way. Can you trigger it locally with
allyesconfig ?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]