Re: [linux-next:master 12059/12643] drivers/ptp/ptp_pch.c:224:undefined reference to `ioread64_lo_hi'

["Arnd Bergmann" <arnd@arndb.de>]

On Thu, Jul 11, 2024, at 16:52, kernel test robot wrote:
> tree:   
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
> master
> head:   f477dd6eede3ecedc8963478571d99ec3bf3f762
> commit: e435f39b57d5fb97b6df67c3d6ce2400e907a69c [12059/12643] 
> asm-generic/iomap.h: don't check for readq/writeq

Ok, so this is a 64-bit architecture that defines its own
readq(), includes asm-generic/iomap.h manually but does
not set CONFIG_GENERIC_IOMAP.

>    alpha-linux-ld: drivers/ptp/ptp_pch.o: in function `pch_rx_snap_read':
>>> drivers/ptp/ptp_pch.c:224:(.text+0x25c): undefined reference to `ioread64_lo_hi'

After the patch I merged, this configuration defines
ioread64_lo_hi to itself but has no definition for it.
Before the patch, we fell back to a pair of ioread32()
calls

#ifndef ioread64_lo_hi
#define ioread64_lo_hi ioread64_lo_hi
static inline u64 ioread64_lo_hi(const void __iomem *addr)
{
        u32 low, high;

        low = ioread32(addr);
        high = ioread32(addr + sizeof(u32));

        return low + ((u64)high << 32);
}
#endif

I need to think more about what we actually want to happen
here, given how on x86 we have no ioread64/iowrite64
and ioread64_lo_hi() turns into a 64-bit MMIO access,
while on most other architectures ioread64() does
a 64-bit access while ioread64_lo_hi() does a pair
of 32-bit ones.

      Arnd