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@xxxxxxx> > > --- > > 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
Attachment:
signature.asc
Description: This is a digitally signed message part
