Hi Robin,

On Tue, 2021-03-02 at 11:29 +0000, Robin Murphy wrote:
> On 2021-02-26 14:02, Nicolas Saenz Julienne wrote:
> > Some devices might inadvertently sit on buses that don't support 64bit
> > MMIO access, and need a mechanism to query these limitations without
> > prejudice to other buses in the system (i.e. defaulting to 32bit access
> > system wide isn't an option).
> > 
> > Introduce a new bus callback, 'mmio_configure(),' which will take care
> > of populating the relevant device properties based on the bus'
> > limitations.
> 
> Devil's advocate: there already exist workarounds for 8-bit and/or 
> 16-bit accesses not working in various places, does it make sense for a 
> 64-bit workaround to be so wildly different and disjoint?

Can you point out an example of the workarounds?

> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
> >   arch/Kconfig               | 8 ++++++++
> >   drivers/base/dd.c          | 6 ++++++
> >   include/linux/device.h     | 3 +++
> >   include/linux/device/bus.h | 3 +++
> >   4 files changed, 20 insertions(+)
> > 
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 2bb30673d8e6..ba7f246b6b9d 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -1191,6 +1191,14 @@ config ARCH_SPLIT_ARG64
> >   config ARCH_HAS_ELFCORE_COMPAT
> >   	bool
> >   
> > 
> > +config ARCH_HAS_64BIT_MMIO_BROKEN
> > +	bool
> > +	depends on 64BIT
> 
> As mentioned previously, 32-bit systems may not need the overrides for 
> kernel I/O accessors, but they could still need the same workarounds for 
> the memory-mapping implications (if this is to be a proper generic 
> mechanism).

I'll keep it in mind.

> > +	default n
>
> Tip: it is always redundant to state that.

Noted!

Regards,
Nicolas