linux-stable.git/include/asm-generic/io.h, branch v5.15

Merge tag 'asm-generic-fixes-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic

2021-10-08T18:57:54+00:00

Pull asm-generic fixes from Arnd Bergmann:
 "There is one build fix for Arm platforms that ended up impacting most
  architectures because of the way the drivers/firmware Kconfig file is
  wired up:

  The CONFIG_QCOM_SCM dependency have caused a number of randconfig
  regressions over time, and some still remain in v5.15-rc4. The fix we
  agreed on in the end is to make this symbol selected by any driver
  using it, and then building it even for non-Arm platforms with
  CONFIG_COMPILE_TEST.

  To make this work on all architectures, the drivers/firmware/Kconfig
  file needs to be included for all architectures to make the symbol
  itself visible.

  In a separate discussion, we found that a sound driver patch that is
  pending for v5.16 needs the same change to include this Kconfig file,
  so the easiest solution seems to have my Kconfig rework included in
  v5.15.

  Finally, the branch also includes a small unrelated build fix for
  NOMMU architectures"

Link: https://lore.kernel.org/all/20210928153508.101208f8@canb.auug.org.au/
Link: https://lore.kernel.org/all/20210928075216.4193128-1-arnd@kernel.org/
Link: https://lore.kernel.org/all/20211007151010.333516-1-arnd@kernel.org/

* tag 'asm-generic-fixes-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
  asm-generic/io.h: give stub iounmap() on !MMU same prototype as elsewhere
  qcom_scm: hide Kconfig symbol
  firmware: include drivers/firmware/Kconfig unconditionally

asm-generic/io.h: give stub iounmap() on !MMU same prototype as elsewhere

2021-10-08T13:39:33+00:00

It made -Werror sad.

Signed-off-by: Adam Borowski 
Signed-off-by: Arnd Bergmann

pci_iounmap'2: Electric Boogaloo: try to make sense of it all

2021-09-20T00:13:35+00:00

Nathan Chancellor reports that the recent change to pci_iounmap in
commit 9caea0007601 ("parisc: Declare pci_iounmap() parisc version only
when CONFIG_PCI enabled") causes build errors on arm64.

It took me about two hours to convince myself that I think I know what
the logic of that mess of #ifdef's in the  header file
really aim to do, and rewrite it to be easier to follow.

Famous last words.

Anyway, the code has now been lifted from that grotty header file into
lib/pci_iomap.c, and has fairly extensive comments about what the logic
is.  It also avoids indirecting through another confusing (and badly
named) helper function that has other preprocessor config conditionals.

Let's see what odd architecture did something else strange in this area
to break things.  But my arm64 cross build is clean.

Fixes: 9caea0007601 ("parisc: Declare pci_iounmap() parisc version only when CONFIG_PCI enabled")
Reported-by: Nathan Chancellor 
Cc: Helge Deller 
Cc: Arnd Bergmann 
Cc: Guenter Roeck 
Cc: Ulrich Teichert 
Cc: James Bottomley 
Signed-off-by: Linus Torvalds

mm: remove xlate_dev_kmem_ptr()

2021-05-07T07:26:34+00:00

Since /dev/kmem has been removed, let's remove the xlate_dev_kmem_ptr()
leftovers.

Link: https://lkml.kernel.org/r/20210324102351.6932-3-david@redhat.com
Signed-off-by: David Hildenbrand 
Acked-by: Geert Uytterhoeven 
Acked-by: Michal Hocko 
Cc: Linus Torvalds 
Cc: Greg Kroah-Hartman 
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Russell King 
Cc: Brian Cain 
Cc: Geert Uytterhoeven 
Cc: Thomas Bogendoerfer 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: "David S. Miller" 
Cc: Arnd Bergmann 
Cc: David Hildenbrand 
Cc: Krzysztof Kozlowski 
Cc: Mikulas Patocka 
Cc: Luc Van Oostenryck 
Cc: Mike Rapoport 
Cc: Palmer Dabbelt 
Cc: Luis Chamberlain 
Cc: Greentime Hu 
Cc: Sebastian Andrzej Siewior 
Cc: Randy Dunlap 
Cc: Jiaxun Yang 
Cc: "Peter Zijlstra (Intel)" 
Cc: Christophe Leroy 
Cc: Gerald Schaefer 
Cc: Niklas Schnelle 
Cc: Pierre Morel 
Cc: Ingo Molnar 
Cc: Kuninori Morimoto 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

asm-generic/io.h: Unbork ioremap_np() declaration

2021-04-09T06:48:27+00:00

It accidentally slipped into the #ifdef for ioremap_uc().

Signed-off-by: Hector Martin 
Link: https://lore.kernel.org/r/20210409052038.58925-1-marcan@marcan.st'
Signed-off-by: Arnd Bergmann

asm-generic/io.h: Add a non-posted variant of ioremap()

2021-04-08T11:18:38+00:00

ARM64 currently defaults to posted MMIO (nGnRE), but some devices
require the use of non-posted MMIO (nGnRnE). Introduce a new ioremap()
variant to handle this case. ioremap_np() returns NULL on arches that
do not implement this variant.

sparc64 is the only architecture that needs to be touched directly,
because it includes neither of the generic io.h or iomap.h headers.

This adds the IORESOURCE_MEM_NONPOSTED flag, which maps to this
variant and marks a given resource as requiring non-posted mappings.
This is implemented in the resource system because it is a SoC-level
requirement, so existing drivers do not need special-case code to pick
this ioremap variant.

Then this is implemented in devres by introducing devm_ioremap_np(),
and making devm_ioremap_resource() automatically select this variant
when the resource has the IORESOURCE_MEM_NONPOSTED flag set.

Acked-by: Marc Zyngier 
Signed-off-by: Hector Martin

Add and use a generic version of devmem_is_allowed()

2020-12-11T20:30:26+00:00

As part of adding STRICT_DEVMEM support to the RISC-V port, Zong provided an
implementation of devmem_is_allowed() that's exactly the same as the version in
a handful of other ports.  Rather than duplicate code, I've put a generic
version of this in lib/ and used it for the RISC-V port.

* palmer/generic-devmem:
  arm64: Use the generic devmem_is_allowed()
  arm: Use the generic devmem_is_allowed()
  RISC-V: Use the new generic devmem_is_allowed()
  lib: Add a generic version of devmem_is_allowed()

lib: Add a generic version of devmem_is_allowed()

2020-12-11T20:28:08+00:00

As part of adding support for STRICT_DEVMEM to the RISC-V port, Zong
provided a devmem_is_allowed() implementation that's exactly the same as
all the others I checked.  Instead I'm adding a generic version, which
will soon be used.

Reviewed-by: Luis Chamberlain 
Signed-off-by: Palmer Dabbelt

asm-generic/io.h: Fix !CONFIG_GENERIC_IOMAP pci_iounmap() implementation

2020-10-05T08:44:16+00:00

For arches that do not select CONFIG_GENERIC_IOMAP, the current
pci_iounmap() function does nothing causing obvious memory leaks
for mapped regions that are backed by MMIO physical space.

In order to detect if a mapped pointer is IO vs MMIO, a check must made
available to the pci_iounmap() function so that it can actually detect
whether the pointer has to be unmapped.

In configurations where CONFIG_HAS_IOPORT_MAP && !CONFIG_GENERIC_IOMAP,
a mapped port is detected using an ioport_map() stub defined in
asm-generic/io.h.

Use the same logic to implement a stub (ie __pci_ioport_unmap()) that
detects if the passed in pointer in pci_iounmap() is IO vs MMIO to
iounmap conditionally and call it in pci_iounmap() fixing the issue.

Leave __pci_ioport_unmap() as a NOP for all other config options.

Tested-by: George Cherian 
Link: https://lore.kernel.org/lkml/20200905024811.74701-1-yangyingliang@huawei.com
Link: https://lore.kernel.org/lkml/20200824132046.3114383-1-george.cherian@marvell.com
Link: https://lore.kernel.org/r/a9daf8d8444d0ebd00bc6d64e336ec49dbb50784.1600254147.git.lorenzo.pieralisi@arm.com
Reported-by: George Cherian 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Catalin Marinas 
Cc: Arnd Bergmann 
Cc: George Cherian 
Cc: Will Deacon 
Cc: Bjorn Helgaas 
Cc: Catalin Marinas 
Cc: Yang Yingliang

asm-generic/io.h: Fix sparse warnings on big-endian architectures

2020-08-04T03:52:23+00:00

On big-endian architectures like OpenRISC, sparse outputs below warnings on
asm-generic/io.h.  This is due to io statements like:

  __raw_writel(cpu_to_le32(value), PCI_IOBASE + addr);

The __raw_writel() function expects native endianness, however
cpu_to_le32() returns __le32.  On little-endian machines these match up
and there is no issue.  However, on big-endian we get warnings, for IO
that is defined as little-endian the mismatch is expected.

The fix I propose is to __force to native endian.

Warnings:

./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:166:15: warning: cast to restricted __le16
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:179:15: warning: cast to restricted __le32
./include/asm-generic/io.h:215:22: warning: incorrect type in argument 1 (different base types)
./include/asm-generic/io.h:215:22:    expected unsigned short [usertype] value
./include/asm-generic/io.h:215:22:    got restricted __le16 [usertype]
./include/asm-generic/io.h:225:22: warning: incorrect type in argument 1 (different base types)
./include/asm-generic/io.h:225:22:    expected unsigned int [usertype] value
./include/asm-generic/io.h:225:22:    got restricted __le32 [usertype]

Signed-off-by: Stafford Horne 
Acked-by: Arnd Bergmann