Messages in this thread | | | From | Hector Martin <> | Subject | Re: [RFT PATCH v3 08/27] asm-generic/io.h: Add a non-posted variant of ioremap() | Date | Thu, 25 Mar 2021 23:07:40 +0900 |
| |
On 25/03/2021 04.09, Arnd Bergmann wrote: > On Wed, Mar 24, 2021 at 7:12 PM Will Deacon <will@kernel.org> wrote: >> >>> +/* >>> + * ioremap_np needs an explicit architecture implementation, as it >>> + * requests stronger semantics than regular ioremap(). Portable drivers >>> + * should instead use one of the higher-level abstractions, like >>> + * devm_ioremap_resource(), to choose the correct variant for any given >>> + * device and bus. Portable drivers with a good reason to want non-posted >>> + * write semantics should always provide an ioremap() fallback in case >>> + * ioremap_np() is not available. >>> + */ >>> +#ifndef ioremap_np >>> +#define ioremap_np ioremap_np >>> +static inline void __iomem *ioremap_np(phys_addr_t offset, size_t size) >>> +{ >>> + return NULL; >>> +} >>> +#endif >> >> Can we implement the generic pci_remap_cfgspace() in terms of ioremap_np() >> if it is supported by the architecture? That way, we could avoid defining >> both on arm64. > > Good idea. It needs a fallback in case the ioremap_np() fails on most > architectures, but that sounds easy enough. > > Since pci_remap_cfgspace() only has custom implementations, it sounds like > we can actually make the generic implementation unconditional in the end, > but that requires adding ioremap_np() on 32-bit as well, and I would keep > that separate from this series.
Sounds good; I'm adding a patch to adjust the generic implementation and remove the arm64 one in v4, and we can then complete the cleanup for other arches later.
-- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub
| |