Re: [PATCH 00/17] -Wmissing-prototype warning fixes

2023-08-16 Thread Palmer Dabbelt
 ++
 kernel/time/tick-internal.h  |  3 ++-
 lib/test_ida.c   |  2 +-
 scripts/Makefile.extrawarn   |  5 +++--
 63 files changed, 101 insertions(+), 63 deletions(-)


Acked-by: Palmer Dabbelt  # RISC-V

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] treewide: drop CONFIG_EMBEDDED

2023-08-16 Thread Palmer Dabbelt

On Tue, 15 Aug 2023 22:50:10 PDT (-0700), rdun...@infradead.org wrote:

There is only one Kconfig user of CONFIG_EMBEDDED and it can be
switched to EXPERT or "if !ARCH_MULTIPLATFORM" (suggested by Arnd).

Signed-off-by: Randy Dunlap 
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Arnd Bergmann 
Cc: Jason A. Donenfeld 
Cc: wiregu...@lists.zx2c4.com
Cc: linux-a...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: Vineet Gupta 
Cc: Brian Cain 
Cc: linux-hexa...@vger.kernel.org
Cc: Greg Ungerer 
Cc: Geert Uytterhoeven 
Cc: linux-m...@lists.linux-m68k.org
Cc: Michal Simek 
Cc: Thomas Bogendoerfer 
Cc: Dinh Nguyen 
Cc: Jonas Bonn 
Cc: Stefan Kristiansson 
Cc: Stafford Horne 
Cc: linux-openr...@vger.kernel.org
Cc: linux-m...@vger.kernel.org
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: John Paul Adrian Glaubitz 
Cc: linux...@vger.kernel.org
Cc: Max Filippov 
Cc: Josh Triplett 
Cc: Masahiro Yamada 
Cc: linux-kbu...@vger.kernel.org
Cc: Andrew Morton 
---
 arch/arc/configs/axs101_defconfig|2 +-
 arch/arc/configs/axs103_defconfig|2 +-
 arch/arc/configs/axs103_smp_defconfig|2 +-
 arch/arc/configs/haps_hs_smp_defconfig   |2 +-
 arch/arc/configs/hsdk_defconfig  |2 +-
 arch/arc/configs/nsim_700_defconfig  |2 +-
 arch/arc/configs/nsimosci_defconfig  |2 +-
 arch/arc/configs/nsimosci_hs_defconfig   |2 +-
 arch/arc/configs/tb10x_defconfig |2 +-
 arch/arc/configs/vdk_hs38_defconfig  |2 +-
 arch/arc/configs/vdk_hs38_smp_defconfig  |2 +-
 arch/arm/Kconfig |2 +-
 arch/arm/configs/aspeed_g4_defconfig |2 +-
 arch/arm/configs/aspeed_g5_defconfig |2 +-
 arch/arm/configs/at91_dt_defconfig   |2 +-
 arch/arm/configs/axm55xx_defconfig   |2 +-
 arch/arm/configs/bcm2835_defconfig   |2 +-
 arch/arm/configs/clps711x_defconfig  |2 +-
 arch/arm/configs/keystone_defconfig  |2 +-
 arch/arm/configs/lpc18xx_defconfig   |2 +-
 arch/arm/configs/lpc32xx_defconfig   |2 +-
 arch/arm/configs/milbeaut_m10v_defconfig |2 +-
 arch/arm/configs/moxart_defconfig|2 +-
 arch/arm/configs/multi_v4t_defconfig |2 +-
 arch/arm/configs/multi_v7_defconfig  |2 +-
 arch/arm/configs/pxa_defconfig   |2 +-
 arch/arm/configs/qcom_defconfig  |2 +-
 arch/arm/configs/sama5_defconfig |2 +-
 arch/arm/configs/sama7_defconfig |2 +-
 arch/arm/configs/socfpga_defconfig   |2 +-
 arch/arm/configs/stm32_defconfig |2 +-
 arch/arm/configs/tegra_defconfig |2 +-
 arch/arm/configs/vf610m4_defconfig   |2 +-
 arch/hexagon/configs/comet_defconfig |2 +-
 arch/m68k/configs/amcore_defconfig   |2 +-
 arch/m68k/configs/m5475evb_defconfig |2 +-
 arch/m68k/configs/stmark2_defconfig  |2 +-
 arch/microblaze/configs/mmu_defconfig|2 +-
 arch/mips/configs/ath25_defconfig|2 +-
 arch/mips/configs/ath79_defconfig|2 +-
 arch/mips/configs/bcm47xx_defconfig  |2 +-
 arch/mips/configs/ci20_defconfig |2 +-
 arch/mips/configs/cu1000-neo_defconfig   |2 +-
 arch/mips/configs/cu1830-neo_defconfig   |2 +-
 arch/mips/configs/db1xxx_defconfig   |2 +-
 arch/mips/configs/gcw0_defconfig |2 +-
 arch/mips/configs/generic_defconfig  |2 +-
 arch/mips/configs/loongson2k_defconfig   |2 +-
 arch/mips/configs/loongson3_defconfig|2 +-
 arch/mips/configs/malta_qemu_32r6_defconfig  |2 +-
 arch/mips/configs/maltaaprp_defconfig|2 +-
 arch/mips/configs/maltasmvp_defconfig|2 +-
 arch/mips/configs/maltasmvp_eva_defconfig|2 +-
 arch/mips/configs/maltaup_defconfig  |2 +-
 arch/mips/configs/omega2p_defconfig  |2 +-
 arch/mips/configs/pic32mzda_defconfig|2 +-
 arch/mips/configs/qi_lb60_defconfig  |2 +-
 arch/mips/configs/rs90_defconfig |2 +-
 arch/mips/configs/rt305x_defconfig   |2 +-
 arch/mips/configs/vocore2

Re: [PATCH] Remove HAVE_VIRT_CPU_ACCOUNTING_GEN option

2023-04-29 Thread Palmer Dabbelt

On Fri, 28 Apr 2023 23:33:48 PDT (-0700), npig...@gmail.com wrote:

This option was created in commit 554b0004d0ec4 ("vtime: Add
HAVE_VIRT_CPU_ACCOUNTING_GEN Kconfig") for architectures to indicate
they support the 64-bit cputime_t required for VIRT_CPU_ACCOUNTING_GEN.

The cputime_t type has since been removed, so this doesn't have any
meaning. Remove it.

Cc: linux-a...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Vineet Gupta 
Cc: linux-snps-arc@lists.infradead.org
Cc: Brian Cain 
Cc: linux-hexa...@vger.kernel.org
Cc: Huacai Chen 
Cc: loonga...@lists.linux.dev
Cc: Geert Uytterhoeven 
Cc: linux-m...@lists.linux-m68k.org
Cc: Michal Simek 
Cc: Thomas Bogendoerfer 
Cc: linux-m...@vger.kernel.org
Cc: Dinh Nguyen 
Cc: Jonas Bonn 
Cc: Stefan Kristiansson 
Cc: Stafford Horne 
Cc: linux-openr...@vger.kernel.org
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: linux-par...@vger.kernel.org
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: linux-ri...@lists.infradead.org
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: John Paul Adrian Glaubitz 
Cc: linux...@vger.kernel.org
Cc: "David S. Miller" 
Cc: sparcli...@vger.kernel.org
Cc: Richard Weinberger 
Cc: Anton Ivanov 
Cc: Johannes Berg 
Cc: linux...@lists.infradead.org
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
Cc: Kevin Hilman 
Cc: Frederic Weisbecker 
Signed-off-by: Nicholas Piggin 
---
Hi,

Could we tidy this? I don't know what tree it can go in, timers,
sched, asm-generic, probably doesn't matter.

The only thing this actually does is gate VIRT_CPU_ACCOUNTING_GEN and
NO_HZ_FULL so if your arch has some other issue that requires this
then the documentation needs to change. Any concerns from the archs?
I.e., 32-bit that does *not* define HAVE_VIRT_CPU_ACCOUNTING_GEN
which looks to be:

arc
hexagon
loongarch 32-bit with SMP
m68k
microblaze
mips 32-bit with SMP
nios2
openrisc
parisc 32-bit
riscv 32-bit


Nothing's jumping out, though I haven't tested this yet so I'm not 100%.  
I assume this isn't aimed for this merge window, given the timing?  
Probably best to give this sort of thing time to bake in linux-next, but 
I doubt anyone is even paying attention to rv32/NO_HZ_FULL so no big 
deal either way on my end.


Acked-by: Palmer Dabbelt  # RISC-V


sh
sparc 32-bit
um 32-bit
x86 32-bit

Thanks,
Nick


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 09/21] riscv: dma-mapping: skip invalidation before bidirectional DMA

2023-04-19 Thread Palmer Dabbelt

On Mon, 27 Mar 2023 05:13:05 PDT (-0700), a...@kernel.org wrote:

From: Arnd Bergmann 

For a DMA_BIDIRECTIONAL transfer, the caches have to be cleaned
first to let the device see data written by the CPU, and invalidated
after the transfer to let the CPU see data written by the device.

riscv also invalidates the caches before the transfer, which does
not appear to serve any purpose.

Signed-off-by: Arnd Bergmann 
---
 arch/riscv/mm/dma-noncoherent.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c
index 640f4c496d26..69c80b2155a1 100644
--- a/arch/riscv/mm/dma-noncoherent.c
+++ b/arch/riscv/mm/dma-noncoherent.c
@@ -25,7 +25,7 @@ void arch_sync_dma_for_device(phys_addr_t paddr, size_t size,
ALT_CMO_OP(clean, vaddr, size, riscv_cbom_block_size);
break;
case DMA_BIDIRECTIONAL:
-   ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size);
+   ALT_CMO_OP(clean, vaddr, size, riscv_cbom_block_size);
break;
default:
break;


Acked-by: Palmer Dabbelt 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 08/21] riscv: dma-mapping: only invalidate after DMA, not flush

2023-04-19 Thread Palmer Dabbelt

On Mon, 27 Mar 2023 05:13:04 PDT (-0700), a...@kernel.org wrote:

From: Arnd Bergmann 

No other architecture intentionally writes back dirty cache lines into
a buffer that a device has just finished writing into. If the cache is
clean, this has no effect at all, but if a cacheline in the buffer has
actually been written by the CPU,  there is a drive bug that is likely
made worse by overwriting that buffer.

Signed-off-by: Arnd Bergmann 
---
 arch/riscv/mm/dma-noncoherent.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/dma-noncoherent.c b/arch/riscv/mm/dma-noncoherent.c
index d919efab6eba..640f4c496d26 100644
--- a/arch/riscv/mm/dma-noncoherent.c
+++ b/arch/riscv/mm/dma-noncoherent.c
@@ -42,7 +42,7 @@ void arch_sync_dma_for_cpu(phys_addr_t paddr, size_t size,
break;
case DMA_FROM_DEVICE:
case DMA_BIDIRECTIONAL:
-   ALT_CMO_OP(flush, vaddr, size, riscv_cbom_block_size);
+   ALT_CMO_OP(inval, vaddr, size, riscv_cbom_block_size);
break;
default:
break;


Acked-by: Palmer Dabbelt 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v5 12/26] riscv: Remove COMMAND_LINE_SIZE from uapi

2023-03-07 Thread Palmer Dabbelt

On Mon, 06 Mar 2023 02:04:54 PST (-0800), alexgh...@rivosinc.com wrote:

As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.

Signed-off-by: Alexandre Ghiti 
---
 arch/riscv/include/asm/setup.h  | 7 +++
 arch/riscv/include/uapi/asm/setup.h | 2 --
 2 files changed, 7 insertions(+), 2 deletions(-)
 create mode 100644 arch/riscv/include/asm/setup.h

diff --git a/arch/riscv/include/asm/setup.h b/arch/riscv/include/asm/setup.h
new file mode 100644
index ..f165a14344e2
--- /dev/null
+++ b/arch/riscv/include/asm/setup.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef _ASM_RISCV_SETUP_H
+#define _ASM_RISCV_SETUP_H
+
+#define COMMAND_LINE_SIZE   1024
+
+#endif /* _ASM_RISCV_SETUP_H */
diff --git a/arch/riscv/include/uapi/asm/setup.h 
b/arch/riscv/include/uapi/asm/setup.h
index 66b13a522880..17fcecd4a2f8 100644
--- a/arch/riscv/include/uapi/asm/setup.h
+++ b/arch/riscv/include/uapi/asm/setup.h
@@ -3,6 +3,4 @@
 #ifndef _UAPI_ASM_RISCV_SETUP_H
 #define _UAPI_ASM_RISCV_SETUP_H

-#define COMMAND_LINE_SIZE  1024
-
 #endif /* _UAPI_ASM_RISCV_SETUP_H */


Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 

Thanks!

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi

2023-03-01 Thread Palmer Dabbelt

On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote:

On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:

Hi Heiko,

On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens  wrote:
> On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> > This all came up in the context of increasing COMMAND_LINE_SIZE in the
> > RISC-V port.  In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> > maximum length of /proc/cmdline and userspace could staticly rely on
> > that to be correct.
> >
> > Usually I wouldn't mess around with changing this sort of thing, but
> > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> > to 2048").  There are also a handful of examples of COMMAND_LINE_SIZE
> > increasing, but they're from before the UAPI split so I'm not quite sure
> > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> > asm-generic/setup.h.").
> >
> > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> > part of the uapi to begin with, and userspace should be able to handle
> > /proc/cmdline of whatever length it turns out to be.  I don't see any
> > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> > search, but that's not really enough to consider it unused on my end.
> >
> > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> > shouldn't be part of uapi, so this now touches all the ports.  I've
> > tried to split this all out and leave it bisectable, but I haven't
> > tested it all that aggressively.
>
> Just to confirm this assumption a bit more: that's actually the same
> conclusion that we ended up with when commit 3da0243f906a ("s390: make
> command line configurable") went upstream.


Thanks, I guess I'd missed that one.  At some point I think there was 
some discussion of making this a Kconfig for everyone, which seems 
reasonable to me -- our use case for this being extended is syzkaller, 
but we're sort of just picking a value that's big enough for now and 
running with it.


Probably best to get it out of uapi first, though, as that way at least 
it's clear that it's not uABI.



Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?


Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.


Alex: Probably worth adding that to the list in the cover letter as it 
looks like you were planning on a v4 anyway (which I guess you now have 
to do, given that I just added the issue to RISC-V).


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v3 03/24] arm: Remove COMMAND_LINE_SIZE from uapi

2023-03-01 Thread Palmer Dabbelt

On Thu, 23 Feb 2023 05:09:17 PST (-0800), Arnd Bergmann wrote:

On Thu, Feb 23, 2023, at 10:54, Alexandre Ghiti wrote:

On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann  wrote:


On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
> On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
>> From: Palmer Dabbelt 
>>
>> As far as I can tell this is not used by userspace and thus should not
>> be part of the user-visible API.
>>
>> Signed-off-by: Palmer Dabbelt 
>
> Looks good to me. What's the merge plan for this?

The easiest way is probably if I merge it through the whole
series through the asm-generic tree. The timing is a bit
unfortunate as we're just ahead of the merge window, so unless
we really need this in 6.3, I'd suggest that Alexandre resend
the series to me in two weeks with the Acks added in and I'll
pick it up for 6.4.


Sorry for the response delay, I was waiting to see if Palmer would
merge my KASAN patchset in 6.3 (which he does): I have to admit that
fixing the command line size + the KASAN patchset would allow 6.3 to
run on syzkaller, which would be nice.

If I don't see this merged in 6.3, I'll send another round as you
suggested in 1 week now :)


Hi Alexandre,

I have no plans to still pick up the series for 6.3. The patches
all look fine to me, but it's clearly too late now. What is the
actual dependency for KASAN, do you just need a longer command
line or something else? If it's just the command line size,
I would suggest that Palmer can still pick up a oneline change
to increase it and refer to this thread in the changelog as a
reference for why it is not an actual UAPI break.


Sorry for being slow here, I just queued up the original patch in the 
RISC-V tree and intend on sending it for 6.3 -- the main worry was that 
it's a uABi change and we're confident it's not.  It's late, but I'd 
prefer to have this as it should let us start running syzkaller now and 
that'll probably find more bugs than this is likely to trigger.


https://lore.kernel.org/r/mhng-b5f934ff-a9bb-4c2b-9ba6-3ab68312077a@palmer-ri-x1c9a/

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH mm-unstable v1 19/26] riscv/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE

2023-02-28 Thread Palmer Dabbelt

On Fri, 13 Jan 2023 09:10:19 PST (-0800), da...@redhat.com wrote:

Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE by stealing one bit
from the offset. This reduces the maximum swap space per file: on 32bit
to 16 GiB (was 32 GiB).


Seems fine to me, I doubt anyone wants a huge pile of swap on rv32.



Note that this bit does not conflict with swap PMDs and could also be used
in swap PMD context later.

While at it, mask the type in __swp_entry().

Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Signed-off-by: David Hildenbrand 
---
 arch/riscv/include/asm/pgtable-bits.h |  3 +++
 arch/riscv/include/asm/pgtable.h  | 29 ++-
 2 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/arch/riscv/include/asm/pgtable-bits.h 
b/arch/riscv/include/asm/pgtable-bits.h
index b9e13a8fe2b7..f896708e8331 100644
--- a/arch/riscv/include/asm/pgtable-bits.h
+++ b/arch/riscv/include/asm/pgtable-bits.h
@@ -27,6 +27,9 @@
  */
 #define _PAGE_PROT_NONE _PAGE_GLOBAL

+/* Used for swap PTEs only. */
+#define _PAGE_SWP_EXCLUSIVE _PAGE_ACCESSED
+
 #define _PAGE_PFN_SHIFT 10

 /*
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index 4eba9a98d0e3..03a4728db039 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -724,16 +724,18 @@ static inline pmd_t pmdp_establish(struct vm_area_struct 
*vma,
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */

 /*
- * Encode and decode a swap entry
+ * Encode/decode swap entries and swap PTEs. Swap PTEs are all PTEs that
+ * are !pte_none() && !pte_present().
  *
  * Format of swap PTE:
  * bit0:   _PAGE_PRESENT (zero)
  * bit   1 to 3:   _PAGE_LEAF (zero)
  * bit5:   _PAGE_PROT_NONE (zero)
- * bits  6 to 10:  swap type
- * bits 10 to XLEN-1:  swap offset
+ * bit6:   exclusive marker
+ * bits  7 to 11:  swap type
+ * bits 11 to XLEN-1:  swap offset
  */
-#define __SWP_TYPE_SHIFT   6
+#define __SWP_TYPE_SHIFT   7
 #define __SWP_TYPE_BITS5
 #define __SWP_TYPE_MASK((1UL << __SWP_TYPE_BITS) - 1)
 #define __SWP_OFFSET_SHIFT (__SWP_TYPE_BITS + __SWP_TYPE_SHIFT)
@@ -744,11 +746,28 @@ static inline pmd_t pmdp_establish(struct vm_area_struct 
*vma,
 #define __swp_type(x)  (((x).val >> __SWP_TYPE_SHIFT) & __SWP_TYPE_MASK)
 #define __swp_offset(x)((x).val >> __SWP_OFFSET_SHIFT)
 #define __swp_entry(type, offset) ((swp_entry_t) \
-   { ((type) << __SWP_TYPE_SHIFT) | ((offset) << __SWP_OFFSET_SHIFT) })
+   { (((type) & __SWP_TYPE_MASK) << __SWP_TYPE_SHIFT) | \
+ ((offset) << __SWP_OFFSET_SHIFT) })

 #define __pte_to_swp_entry(pte)((swp_entry_t) { pte_val(pte) })
 #define __swp_entry_to_pte(x)  ((pte_t) { (x).val })

+#define __HAVE_ARCH_PTE_SWP_EXCLUSIVE
+static inline int pte_swp_exclusive(pte_t pte)
+{
+   return pte_val(pte) & _PAGE_SWP_EXCLUSIVE;
+}
+
+static inline pte_t pte_swp_mkexclusive(pte_t pte)
+{
+   return __pte(pte_val(pte) | _PAGE_SWP_EXCLUSIVE);
+}
+
+static inline pte_t pte_swp_clear_exclusive(pte_t pte)
+{
+   return __pte(pte_val(pte) & ~_PAGE_SWP_EXCLUSIVE);
+}
+
 #ifdef CONFIG_ARCH_ENABLE_THP_MIGRATION
 #define __pmd_to_swp_entry(pmd) ((swp_entry_t) { pmd_val(pmd) })
 #define __swp_entry_to_pmd(swp) __pmd((swp).val)


Acked-by: Palmer Dabbelt 
Reviewed-by: Palmer Dabbelt 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 13/19] arch/riscv: rename internal name __xchg to __arch_xchg

2023-02-14 Thread Palmer Dabbelt

On Thu, 22 Dec 2022 03:46:29 PST (-0800), andrzej.ha...@intel.com wrote:

__xchg will be used for non-atomic xchg macro.

Signed-off-by: Andrzej Hajda 
---
 arch/riscv/include/asm/atomic.h  | 2 +-
 arch/riscv/include/asm/cmpxchg.h | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h
index 0dfe9d857a762b..bba472928b5393 100644
--- a/arch/riscv/include/asm/atomic.h
+++ b/arch/riscv/include/asm/atomic.h
@@ -261,7 +261,7 @@ c_t arch_atomic##prefix##_xchg_release(atomic##prefix##_t 
*v, c_t n)\
 static __always_inline \
 c_t arch_atomic##prefix##_xchg(atomic##prefix##_t *v, c_t n)   \
 {  \
-   return __xchg(&(v->counter), n, size);   \
+   return __arch_xchg(&(v->counter), n, size);  \
 }  \
 static __always_inline \
 c_t arch_atomic##prefix##_cmpxchg_relaxed(atomic##prefix##_t *v,   \
diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
index 12debce235e52d..2f4726d3cfcc25 100644
--- a/arch/riscv/include/asm/cmpxchg.h
+++ b/arch/riscv/include/asm/cmpxchg.h
@@ -114,7 +114,7 @@
_x_, sizeof(*(ptr)));   \
 })

-#define __xchg(ptr, new, size) \
+#define __arch_xchg(ptr, new, size)\
 ({ \
__typeof__(ptr) __ptr = (ptr);  \
__typeof__(new) __new = (new);  \
@@ -143,7 +143,7 @@
 #define arch_xchg(ptr, x)  \
 ({ \
__typeof__(*(ptr)) _x_ = (x);   \
-   (__typeof__(*(ptr))) __xchg((ptr), _x_, sizeof(*(ptr)));\
+   (__typeof__(*(ptr))) __arch_xchg((ptr), _x_, sizeof(*(ptr)));   \
 })

 #define xchg32(ptr, x) \


Acked-by: Palmer Dabbelt 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 13/19] arch/riscv: rename internal name __xchg to __arch_xchg

2022-12-29 Thread Palmer Dabbelt

On Thu, 22 Dec 2022 03:46:29 PST (-0800), andrzej.ha...@intel.com wrote:

__xchg will be used for non-atomic xchg macro.

Signed-off-by: Andrzej Hajda 
---
 arch/riscv/include/asm/atomic.h  | 2 +-
 arch/riscv/include/asm/cmpxchg.h | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h
index 0dfe9d857a762b..bba472928b5393 100644
--- a/arch/riscv/include/asm/atomic.h
+++ b/arch/riscv/include/asm/atomic.h
@@ -261,7 +261,7 @@ c_t arch_atomic##prefix##_xchg_release(atomic##prefix##_t 
*v, c_t n)\
 static __always_inline \
 c_t arch_atomic##prefix##_xchg(atomic##prefix##_t *v, c_t n)   \
 {  \
-   return __xchg(&(v->counter), n, size);   \
+   return __arch_xchg(&(v->counter), n, size);  \
 }  \
 static __always_inline \
 c_t arch_atomic##prefix##_cmpxchg_relaxed(atomic##prefix##_t *v,   \
diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
index 12debce235e52d..2f4726d3cfcc25 100644
--- a/arch/riscv/include/asm/cmpxchg.h
+++ b/arch/riscv/include/asm/cmpxchg.h
@@ -114,7 +114,7 @@
_x_, sizeof(*(ptr)));   \
 })

-#define __xchg(ptr, new, size) \
+#define __arch_xchg(ptr, new, size)\
 ({ \
__typeof__(ptr) __ptr = (ptr);  \
__typeof__(new) __new = (new);  \
@@ -143,7 +143,7 @@
 #define arch_xchg(ptr, x)  \
 ({ \
__typeof__(*(ptr)) _x_ = (x);   \
-   (__typeof__(*(ptr))) __xchg((ptr), _x_, sizeof(*(ptr)));\
+   (__typeof__(*(ptr))) __arch_xchg((ptr), _x_, sizeof(*(ptr)));   \
 })

 #define xchg32(ptr, x) \


Acked-by: Palmer Dabbelt 

Thanks!

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v3 0/8] Generic IPI sending tracepoint

2022-12-13 Thread Palmer Dabbelt
ernel/smp.c  |  3 +-
 arch/csky/kernel/smp.c   |  2 +-
 arch/hexagon/kernel/smp.c|  2 +-
 arch/ia64/kernel/smp.c   |  4 +-
 arch/loongarch/include/asm/smp.h |  2 +-
 arch/mips/include/asm/smp.h  |  2 +-
 arch/mips/kernel/rtlx-cmp.c  |  2 +
 arch/openrisc/kernel/smp.c   |  2 +-
 arch/parisc/kernel/smp.c |  4 +-
 arch/powerpc/kernel/smp.c|  6 +-
 arch/powerpc/kvm/book3s_hv.c |  3 +
 arch/powerpc/platforms/powernv/subcore.c |  2 +
 arch/riscv/kernel/smp.c  |  4 +-
 arch/s390/kernel/smp.c   |  2 +-
 arch/sh/kernel/smp.c |  2 +-
 arch/sparc/kernel/smp_32.c   |  2 +-
 arch/sparc/kernel/smp_64.c   |  2 +-
 arch/x86/include/asm/smp.h   |  2 +-
 arch/x86/kvm/svm/svm.c   |  4 +
 arch/x86/kvm/x86.c   |  2 +
 arch/xtensa/kernel/smp.c |  2 +-
 include/linux/smp.h  |  8 +-
 include/trace/bpf_probe.h|  6 ++
 include/trace/events/ipi.h   | 22 ++
 include/trace/perf.h |  6 ++
 include/trace/stages/stage1_struct_define.h  |  6 ++
 include/trace/stages/stage2_data_offsets.h   |  6 ++
 include/trace/stages/stage3_trace_output.h   |  6 ++
 include/trace/stages/stage4_event_fields.h   |  6 ++
 include/trace/stages/stage5_get_offsets.h|  6 ++
 include/trace/stages/stage6_event_callback.h | 20 +
 include/trace/stages/stage7_class_define.h   |  2 +
 kernel/irq_work.c| 14 +++-
 kernel/sched/core.c  | 19 +++--
 kernel/sched/smp.h   |  2 +-
 kernel/smp.c | 78 
 samples/trace_events/trace-events-sample.c   |  2 +-
 samples/trace_events/trace-events-sample.h   | 34 +++--
 virt/kvm/kvm_main.c  |  1 +
 43 files changed, 250 insertions(+), 61 deletions(-)


Acked-by: Palmer Dabbelt  # riscv

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] mm: remove kern_addr_valid() completely

2022-11-10 Thread Palmer Dabbelt
  pud_t *pud;
-   pmd_t *pmd;
-   pte_t *pte;
-
-   if (above != 0 && above != -1UL)
-   return 0;
-
-   pgd = pgd_offset_k(addr);
-   if (pgd_none(*pgd))
-   return 0;
-
-   p4d = p4d_offset(pgd, addr);
-   if (!p4d_present(*p4d))
-   return 0;
-
-   pud = pud_offset(p4d, addr);
-   if (!pud_present(*pud))
-   return 0;
-
-   if (pud_large(*pud))
-   return pfn_valid(pud_pfn(*pud));
-
-   pmd = pmd_offset(pud, addr);
-   if (!pmd_present(*pmd))
-   return 0;
-
-   if (pmd_large(*pmd))
-   return pfn_valid(pmd_pfn(*pmd));
-
-   pte = pte_offset_kernel(pmd, addr);
-   if (pte_none(*pte))
-   return 0;
-
-   return pfn_valid(pte_pfn(*pte));
-}
-
 /*
  * Block size is the minimum amount of memory which can be hotplugged or
  * hotremoved. It must be power of two and must be equal or larger than
diff --git a/arch/xtensa/include/asm/pgtable.h 
b/arch/xtensa/include/asm/pgtable.h
index 54f577c13afa..5b5484d707b2 100644
--- a/arch/xtensa/include/asm/pgtable.h
+++ b/arch/xtensa/include/asm/pgtable.h
@@ -386,8 +386,6 @@ ptep_set_wrprotect(struct mm_struct *mm, unsigned long 
addr, pte_t *ptep)

 #else

-#define kern_addr_valid(addr)  (1)
-
 extern  void update_mmu_cache(struct vm_area_struct * vma,
  unsigned long address, pte_t *ptep);

diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index dff921f7ca33..590ecb79ad8b 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -541,25 +541,17 @@ read_kcore(struct file *file, char __user *buffer, size_t 
buflen, loff_t *fpos)
fallthrough;
case KCORE_VMEMMAP:
case KCORE_TEXT:
-   if (kern_addr_valid(start)) {
-   /*
-* Using bounce buffer to bypass the
-* hardened user copy kernel text checks.
-*/
-   if (copy_from_kernel_nofault(buf, (void *)start,
-   tsz)) {
-   if (clear_user(buffer, tsz)) {
-   ret = -EFAULT;
-   goto out;
-   }
-   } else {
-   if (copy_to_user(buffer, buf, tsz)) {
-   ret = -EFAULT;
-   goto out;
-   }
+   /*
+* Using bounce buffer to bypass the
+* hardened user copy kernel text checks.
+*/
+   if (copy_from_kernel_nofault(buf, (void *)start, tsz)) {
+   if (clear_user(buffer, tsz)) {
+   ret = -EFAULT;
+   goto out;
}
} else {
-   if (clear_user(buffer, tsz)) {
+   if (copy_to_user(buffer, buf, tsz)) {
ret = -EFAULT;
            goto out;
}


Acked-by: Palmer Dabbelt 

Thanks!

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] RISC-V: Add STACKLEAK erasing the kernel stack at the end of syscalls

2022-10-06 Thread Palmer Dabbelt

On Tue, 06 Sep 2022 10:35:10 PDT (-0700), conor.doo...@microchip.com wrote:

On 03/09/2022 17:23, guo...@kernel.org wrote:

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe

From: Xianting Tian 

This adds support for the STACKLEAK gcc plugin to RISC-V and disables
the plugin in EFI stub code, which is out of scope for the protection.

For the benefits of STACKLEAK feature, please check the commit
afaef01c0015 ("x86/entry: Add STACKLEAK erasing the kernel stack at the end of 
syscalls")

Performance impact (tested on qemu env with 1 riscv64 hart, 1GB mem)
hackbench -s 512 -l 200 -g 15 -f 25 -P
2.0% slowdown

Signed-off-by: Xianting Tian 


What changed since Xianting posted it himself a week ago:
https://lore.kernel.org/linux-riscv/20220828135407.3897717-1-xianting.t...@linux.alibaba.com/

There's an older patch from Du Lao adding STACKLEAK too:
https://lore.kernel.org/linux-riscv/20220615213834.3116135-1-da...@rivosinc.com/

But since there's been no activity there since June...


Looks like the only issues were some commit log wording stuff, and that 
there's a test suite that should be run.  It's not clear from the 
commits that anyone has done that, I'm fine with the patch if it passes 
the tests but don't really know how to run them.


Has anyone run the tests?




---
 arch/riscv/Kconfig| 1 +
 arch/riscv/include/asm/processor.h| 4 
 arch/riscv/kernel/entry.S | 3 +++
 drivers/firmware/efi/libstub/Makefile | 2 +-
 4 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index ed66c31e4655..61fd0dad4463 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -85,6 +85,7 @@ config RISCV
select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
select HAVE_ARCH_THREAD_STRUCT_WHITELIST
select HAVE_ARCH_VMAP_STACK if MMU && 64BIT
+   select HAVE_ARCH_STACKLEAK
select HAVE_ASM_MODVERSIONS
select HAVE_CONTEXT_TRACKING_USER
select HAVE_DEBUG_KMEMLEAK
diff --git a/drivers/firmware/efi/libstub/Makefile 
b/drivers/firmware/efi/libstub/Makefile
index d0537573501e..5e1fc4f82883 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -25,7 +25,7 @@ cflags-$(CONFIG_ARM)  := $(subst 
$(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \
   -fno-builtin -fpic \
   $(call cc-option,-mno-single-pic-base)
 cflags-$(CONFIG_RISCV) := $(subst 
$(CC_FLAGS_FTRACE),,$(KBUILD_CFLAGS)) \
-  -fpic
+  -fpic $(DISABLE_STACKLEAK_PLUGIN)

 cflags-$(CONFIG_EFI_GENERIC_STUB) += -I$(srctree)/scripts/dtc/libfdt

--
2.17.1


___
linux-riscv mailing list
linux-ri...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv




___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 2/3] trace: refactor TRACE_IRQFLAGS_SUPPORT in Kconfig

2021-08-24 Thread Palmer Dabbelt

On Fri, 30 Jul 2021 22:22:32 PDT (-0700), masahi...@kernel.org wrote:

Make architectures select TRACE_IRQFLAGS_SUPPORT instead of
having many defines.

Signed-off-by: Masahiro Yamada 
---

 arch/riscv/Kconfig| 4 +---


Acked-by: Palmer Dabbelt 

Thanks!

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 17/21] lib: provide a simple generic ioremap implementation

2019-11-07 Thread Palmer Dabbelt

On Mon, 28 Oct 2019 23:48:30 PDT (-0700), Christoph Hellwig wrote:

A lot of architectures reuse the same simple ioremap implementation, so
start lifting the most simple variant to lib/ioremap.c.  It provides
ioremap_prot and iounmap, plus a default ioremap that uses prot_noncached,
although that can be overridden by asm/io.h.

Signed-off-by: Christoph Hellwig 
---
 include/asm-generic/io.h | 20 
 lib/Kconfig  |  3 +++
 lib/ioremap.c| 39 +++
 3 files changed, 58 insertions(+), 4 deletions(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 4e45e1cb6560..4a661fdd1937 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -923,9 +923,10 @@ static inline void *phys_to_virt(unsigned long address)
  * DOC: ioremap() and ioremap_*() variants
  *
  * Architectures with an MMU are expected to provide ioremap() and iounmap()
- * themselves.  For NOMMU architectures we provide a default nop-op
- * implementation that expect that the physical address used for MMIO are
- * already marked as uncached, and can be used as kernel virtual addresses.
+ * themselves or rely on GENERIC_IOREMAP.  For NOMMU architectures we provide
+ * a default nop-op implementation that expect that the physical address used
+ * for MMIO are already marked as uncached, and can be used as kernel virtual
+ * addresses.
  *
  * ioremap_wc() and ioremap_wt() can provide more relaxed caching attributes
  * for specific drivers if the architecture choses to implement them.  If they
@@ -946,7 +947,18 @@ static inline void iounmap(void __iomem *addr)
 {
 }
 #endif
-#endif /* CONFIG_MMU */
+#elif defined(CONFIG_GENERIC_IOREMAP)
+#include 
+
+void __iomem *ioremap_prot(phys_addr_t addr, size_t size, unsigned long prot);
+void iounmap(volatile void __iomem *addr);
+
+static inline void __iomem *ioremap(phys_addr_t addr, size_t size)
+{
+   /* _PAGE_IOREMAP needs to be supplied by the architecture */
+   return ioremap_prot(addr, size, _PAGE_IOREMAP);
+}
+#endif /* !CONFIG_MMU || CONFIG_GENERIC_IOREMAP */

 #ifndef ioremap_nocache
 #define ioremap_nocache ioremap
diff --git a/lib/Kconfig b/lib/Kconfig
index 183f92a297ca..afc78aaf2b25 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -638,6 +638,9 @@ config STRING_SELFTEST

 endmenu

+config GENERIC_IOREMAP
+   bool
+
 config GENERIC_LIB_ASHLDI3
bool

diff --git a/lib/ioremap.c b/lib/ioremap.c
index 0a2ffadc6d71..3f0e18543de8 100644
--- a/lib/ioremap.c
+++ b/lib/ioremap.c
@@ -231,3 +231,42 @@ int ioremap_page_range(unsigned long addr,

return err;
 }
+
+#ifdef CONFIG_GENERIC_IOREMAP
+void __iomem *ioremap_prot(phys_addr_t addr, size_t size, unsigned long prot)
+{
+   unsigned long offset, vaddr;
+   phys_addr_t last_addr;
+   struct vm_struct *area;
+
+   /* Disallow wrap-around or zero size */
+   last_addr = addr + size - 1;
+   if (!size || last_addr < addr)
+   return NULL;
+
+   /* Page-align mappings */
+   offset = addr & (~PAGE_MASK);
+   addr -= offset;
+   size = PAGE_ALIGN(size + offset);
+
+   area = get_vm_area_caller(size, VM_IOREMAP,
+   __builtin_return_address(0));
+   if (!area)
+   return NULL;
+   vaddr = (unsigned long)area->addr;
+
+   if (ioremap_page_range(vaddr, vaddr + size, addr, __pgprot(prot))) {
+   free_vm_area(area);
+   return NULL;
+   }
+
+   return (void __iomem *)(vaddr + offset);
+}
+EXPORT_SYMBOL(ioremap_prot);
+
+void iounmap(volatile void __iomem *addr)
+{
+   vunmap((void *)((unsigned long)addr & PAGE_MASK));
+}
+EXPORT_SYMBOL(iounmap);
+#endif /* CONFIG_GENERIC_IOREMAP */


Reviewed-by: Palmer Dabbelt 

Thanks!  This should let us get rid of arch/riscv/mm/ioremap.c.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 12/21] arch: rely on asm-generic/io.h for default ioremap_* definitions

2019-11-07 Thread Palmer Dabbelt
) virt_to_phys(page_to_virt(page))

diff --git a/arch/openrisc/include/asm/io.h b/arch/openrisc/include/asm/io.h
index 5b81a96ab85e..e18f038b2a6d 100644
--- a/arch/openrisc/include/asm/io.h
+++ b/arch/openrisc/include/asm/io.h
@@ -25,7 +25,6 @@
 #define PIO_OFFSET 0
 #define PIO_MASK   0

-#define ioremap_nocache ioremap
 #include 
 #include 

diff --git a/arch/riscv/include/asm/io.h b/arch/riscv/include/asm/io.h
index fc1189ad3777..c1de6875cc77 100644
--- a/arch/riscv/include/asm/io.h
+++ b/arch/riscv/include/asm/io.h
@@ -15,16 +15,6 @@
 #include 

 extern void __iomem *ioremap(phys_addr_t offset, unsigned long size);
-
-/*
- * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
- * change the properties of memory regions.  This should be fixed by the
- * upcoming platform spec.
- */
-#define ioremap_nocache(addr, size) ioremap((addr), (size))
-#define ioremap_wc(addr, size) ioremap((addr), (size))
-#define ioremap_wt(addr, size) ioremap((addr), (size))
-
 extern void iounmap(volatile void __iomem *addr);

 /* Generic IO read/write.  These perform native-endian accesses. */
diff --git a/arch/s390/include/asm/io.h b/arch/s390/include/asm/io.h
index ca421614722f..5a16f500515a 100644
--- a/arch/s390/include/asm/io.h
+++ b/arch/s390/include/asm/io.h
@@ -26,10 +26,6 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr);

 #define IO_SPACE_LIMIT 0

-#define ioremap_nocache(addr, size)ioremap(addr, size)
-#define ioremap_wc ioremap_nocache
-#define ioremap_wt ioremap_nocache
-
 void __iomem *ioremap(unsigned long offset, unsigned long size);
 void iounmap(volatile void __iomem *addr);

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 6b5cc41319a7..9997521fc5cd 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -205,7 +205,6 @@ extern void __iomem *ioremap_encrypted(resource_size_t 
phys_addr, unsigned long
  */
 void __iomem *ioremap(resource_size_t offset, unsigned long size);
 #define ioremap ioremap
-#define ioremap_nocache ioremap

 extern void iounmap(volatile void __iomem *addr);
 #define iounmap iounmap
diff --git a/arch/xtensa/include/asm/io.h b/arch/xtensa/include/asm/io.h
index 441fb56926a7..54188e69b988 100644
--- a/arch/xtensa/include/asm/io.h
+++ b/arch/xtensa/include/asm/io.h
@@ -52,10 +52,6 @@ static inline void __iomem *ioremap_cache(unsigned long 
offset,
 }
 #define ioremap_cache ioremap_cache

-#define ioremap_nocache ioremap
-#define ioremap_wc ioremap
-#define ioremap_wt ioremap
-
 static inline void iounmap(volatile void __iomem *addr)
 {
unsigned long va = (unsigned long) addr;
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 6a5edc23afe2..4e45e1cb6560 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -949,27 +949,15 @@ static inline void iounmap(void __iomem *addr)
 #endif /* CONFIG_MMU */

 #ifndef ioremap_nocache
-#define ioremap_nocache ioremap_nocache
-static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
-{
-   return ioremap(offset, size);
-}
+#define ioremap_nocache ioremap
 #endif

 #ifndef ioremap_wc
-#define ioremap_wc ioremap_wc
-static inline void __iomem *ioremap_wc(phys_addr_t offset, size_t size)
-{
-   return ioremap_nocache(offset, size);
-}
+#define ioremap_wc ioremap
 #endif

 #ifndef ioremap_wt
-#define ioremap_wt ioremap_wt
-static inline void __iomem *ioremap_wt(phys_addr_t offset, size_t size)
-{
-   return ioremap_nocache(offset, size);
-}
+#define ioremap_wt ioremap
 #endif

 /*


Reviewed-by: Palmer Dabbelt 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 11/21] asm-generic: don't provide ioremap for CONFIG_MMU

2019-11-06 Thread Palmer Dabbelt

On Mon, 28 Oct 2019 23:48:24 PDT (-0700), Christoph Hellwig wrote:

All MMU-enabled ports have a non-trivial ioremap and should thus provide
the prototype for their implementation instead of providing a generic
one unless a different symbol is not defined.  Note that this only
affects sparc32 nds32 as all others do provide their own version.

Also update the kerneldoc comments in asm-generic/io.h to explain the
situation around the default ioremap* implementations correctly.

Signed-off-by: Christoph Hellwig 
---
 arch/nds32/include/asm/io.h|  2 ++
 arch/sparc/include/asm/io_32.h |  1 +
 include/asm-generic/io.h   | 29 -
 3 files changed, 11 insertions(+), 21 deletions(-)

diff --git a/arch/nds32/include/asm/io.h b/arch/nds32/include/asm/io.h
index 16f262322b8f..fb0e8a24c7af 100644
--- a/arch/nds32/include/asm/io.h
+++ b/arch/nds32/include/asm/io.h
@@ -6,6 +6,7 @@

 #include 

+void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
 extern void iounmap(volatile void __iomem *addr);
 #define __raw_writeb __raw_writeb
 static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
@@ -80,4 +81,5 @@ static inline u32 __raw_readl(const volatile void __iomem 
*addr)
 #define writew(v,c)({ __iowmb(); writew_relaxed((v),(c)); })
 #define writel(v,c)({ __iowmb(); writel_relaxed((v),(c)); })
 #include 
+
 #endif /* __ASM_NDS32_IO_H */
diff --git a/arch/sparc/include/asm/io_32.h b/arch/sparc/include/asm/io_32.h
index df2dc1784673..9a52d9506f80 100644
--- a/arch/sparc/include/asm/io_32.h
+++ b/arch/sparc/include/asm/io_32.h
@@ -127,6 +127,7 @@ static inline void sbus_memcpy_toio(volatile void __iomem 
*dst,
  * Bus number may be embedded in the higher bits of the physical address.
  * This is why we have no bus number argument to ioremap().
  */
+void __iomem *ioremap(phys_addr_t offset, size_t size);
 void iounmap(volatile void __iomem *addr);
 /* Create a virtual mapping cookie for an IO port range */
 void __iomem *ioport_map(unsigned long port, unsigned int nr);
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index a98ed6325727..6a5edc23afe2 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -922,28 +922,16 @@ static inline void *phys_to_virt(unsigned long address)
 /**
  * DOC: ioremap() and ioremap_*() variants
  *
- * If you have an IOMMU your architecture is expected to have both ioremap()
- * and iounmap() implemented otherwise the asm-generic helpers will provide a
- * direct mapping.
+ * Architectures with an MMU are expected to provide ioremap() and iounmap()
+ * themselves.  For NOMMU architectures we provide a default nop-op
+ * implementation that expect that the physical address used for MMIO are
+ * already marked as uncached, and can be used as kernel virtual addresses.
  *
- * There are ioremap_*() call variants, if you have no IOMMU we naturally will
- * default to direct mapping for all of them, you can override these defaults.
- * If you have an IOMMU you are highly encouraged to provide your own
- * ioremap variant implementation as there currently is no safe architecture
- * agnostic default. To avoid possible improper behaviour default asm-generic
- * ioremap_*() variants all return NULL when an IOMMU is available. If you've
- * defined your own ioremap_*() variant you must then declare your own
- * ioremap_*() variant as defined to itself to avoid the default NULL return.
+ * ioremap_wc() and ioremap_wt() can provide more relaxed caching attributes
+ * for specific drivers if the architecture choses to implement them.  If they
+ * are not implemented we fall back to plain ioremap.
  */
 #ifndef CONFIG_MMU
-
-/*
- * Change "struct page" to physical address.
- *
- * This implementation is for the no-MMU case only... if you have an MMU
- * you'll need to provide your own definitions.
- */
-
 #ifndef ioremap
 #define ioremap ioremap
 static inline void __iomem *ioremap(phys_addr_t offset, size_t size)
@@ -954,14 +942,13 @@ static inline void __iomem *ioremap(phys_addr_t offset, 
size_t size)

 #ifndef iounmap
 #define iounmap iounmap
-
 static inline void iounmap(void __iomem *addr)
 {
 }
 #endif
 #endif /* CONFIG_MMU */
+
 #ifndef ioremap_nocache
-void __iomem *ioremap(phys_addr_t phys_addr, size_t size);
 #define ioremap_nocache ioremap_nocache
 static inline void __iomem *ioremap_nocache(phys_addr_t offset, size_t size)
 {


It looks like the difference in prototype between the architectures is between

   void __iomem *ioremap(resource_size_t, size_t)
   void __iomem *ioremap(phys_addr_t, size_t)
   void __iomem *ioremap(phys_addr_t, unsigned long)
   void __iomem *ioremap(unsigned long, unsigned long)

shouldn't they all just be that first one?  In other words, wouldn't it be 
better to always provide the generic ioremap prototype and unify the ports 
instead?


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org

Re: [PATCH v2 16/15] syscall_get_arch: add "struct task_struct *" argument

2018-11-21 Thread Palmer Dabbelt

On Tue, 20 Nov 2018 16:44:22 PST (-0800), l...@altlinux.org wrote:

This argument is required to extend the generic ptrace API
with PTRACE_GET_SYSCALL_INFO request: syscall_get_arch() is going to be
called from ptrace_request() along with other syscall_get_* functions
with a tracee as their argument.

This change partially reverts commit 5e937a9ae913 ("syscall_get_arch:
remove useless function arguments").

Cc: linux-al...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-au...@redhat.com
Cc: linux-c6x-...@linux-c6x.org
Cc: linux-hexa...@vger.kernel.org
Cc: linux-i...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-m...@linux-mips.org
Cc: linux-par...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux...@lists.infradead.org
Cc: linux-xte...@linux-xtensa.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: nios2-...@lists.rocketboards.org
Cc: openr...@lists.librecores.org
Cc: sparcli...@vger.kernel.org
Cc: uclinux-h8-de...@lists.sourceforge.jp
Cc: x...@kernel.org
Signed-off-by: Dmitry V. Levin 


Reviewed-by: Palmer Dabbelt 

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

2018-04-10 Thread Palmer Dabbelt

On Tue, 10 Apr 2018 09:09:32 PDT (-0700), wi...@infradead.org wrote:

On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote:

 arch/powerpc/include/asm/pte-common.h  | 3 ---
 arch/riscv/Kconfig | 1 +
 arch/s390/Kconfig  | 1 +


You forgot to delete __HAVE_ARCH_PTE_SPECIAL from
arch/riscv/include/asm/pgtable-bits.h


Thanks -- I was looking for that but couldn't find it and assumed I'd just 
misunderstood something.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v2 02/16] riscv: Use INITRAMFS_GENERIC_UNLOAD.

2018-03-25 Thread Palmer Dabbelt

On Sun, 25 Mar 2018 15:18:39 PDT (-0700), s...@shealevy.com wrote:

Signed-off-by: Shea Levy <s...@shealevy.com>
---
 arch/riscv/Kconfig   | 1 +
 arch/riscv/mm/init.c | 6 --
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c22ebe08e902..ab1b4cee84fc 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -37,6 +37,7 @@ config RISCV
select THREAD_INFO_IN_TASK
select RISCV_TIMER
select GENERIC_IRQ_MULTI_HANDLER
+   select INITRAMFS_GENERIC_UNLOAD

 config MMU
def_bool y
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index c77df8142be2..36f83fe8a726 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -62,9 +62,3 @@ void free_initmem(void)
 {
free_initmem_default(0);
 }
-
-#ifdef CONFIG_BLK_DEV_INITRD
-void free_initrd_mem(unsigned long start, unsigned long end)
-{
-}
-#endif /* CONFIG_BLK_DEV_INITRD */


I haven't looked through the rest of the patch set, but this is a pretty 
trivial change so feel free to add a 


Reviewed-By: Palmer Dabbelt <pal...@sifive.com>

if you'd like.  If you'd like it merged through my tree then just say 
something!


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

2017-06-27 Thread Palmer Dabbelt
On Tue, 27 Jun 2017 16:37:40 PDT (-0700), helg...@kernel.org wrote:
> [+cc Lorenzo]
>
> Hi Palmer,
>
> On Fri, Jun 23, 2017 at 02:45:38PM -0700, Palmer Dabbelt wrote:
>> We wanted to add RISC-V to the list of architectures that used the
>> generic PCI setup-irq.o inside the Makefile and it was suggested that
>> instead we define a Kconfig entry and use that.
>>
>> I've done very minimal testing on this: I just checked to see that
>> an aarch64 defconfig still build setup-irq.o with the patch applied.
>> The intention is that this patch doesn't change the behavior of any
>> build.
>>
>> Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
>
> Lorenzo Pieralisi's "ARM/ARM64: remove pci_fixup_irqs() usage" series
> overlaps with this quite a bit, and includes this patch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=pci/enumeration=5b64036feff4
>
> which makes it so we build setup-irq.o on *all* arches.  Can you check
> out the pci/enumeration branch and see whether it accomplishes what
> you need?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/log/?h=pci/enumeration

Great, that's even better for me, as I don't have to go touch a bunch of
different arch code :).  We'll use that instead when it lands.

Thanks!

>
>> ---
>>  arch/alpha/Kconfig |  1 +
>>  arch/arc/Kconfig   |  1 +
>>  arch/arm/Kconfig   |  1 +
>>  arch/arm64/Kconfig |  1 +
>>  arch/m68k/Kconfig  |  1 +
>>  arch/mips/Kconfig  |  1 +
>>  arch/sh/Kconfig|  1 +
>>  arch/sparc/Kconfig |  1 +
>>  arch/tile/Kconfig  |  1 +
>>  arch/unicore32/Kconfig |  1 +
>>  drivers/pci/Kconfig|  3 +++
>>  drivers/pci/Makefile   | 11 +--
>>  12 files changed, 14 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
>> index 0e49d39ea74a..30f4e711f681 100644
>> --- a/arch/alpha/Kconfig
>> +++ b/arch/alpha/Kconfig
>> @@ -26,6 +26,7 @@ config ALPHA
>>  select ODD_RT_SIGACTION
>>  select OLD_SIGSUSPEND
>>  select CPU_NO_EFFICIENT_FFS if !ALPHA_EV67
>> +select PCI_GENERIC_SETUP
>>  help
>>The Alpha is a 64-bit general-purpose processor designed and
>>marketed by the Digital Equipment Corporation of blessed memory,
>> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
>> index a5459698f0ee..dd1f64858118 100644
>> --- a/arch/arc/Kconfig
>> +++ b/arch/arc/Kconfig
>> @@ -44,6 +44,7 @@ config ARC
>>  select HAVE_GENERIC_DMA_COHERENT
>>  select HAVE_KERNEL_GZIP
>>  select HAVE_KERNEL_LZMA
>> +select PCI_GENERIC_SETUP
>>
>>  config MIGHT_HAVE_PCI
>>  bool
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 4c1a35f15838..86872246951c 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -96,6 +96,7 @@ config ARM
>>  select PERF_USE_VMALLOC
>>  select RTC_LIB
>>  select SYS_SUPPORTS_APM_EMULATION
>> +select PCI_GENERIC_SETUP
>>  # Above selects are sorted alphabetically; please add new ones
>>  # according to that.  Thanks.
>>  help
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index b2024db225a9..6c684d8c8816 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -115,6 +115,7 @@ config ARM64
>>  select SPARSE_IRQ
>>  select SYSCTL_EXCEPTION_TRACE
>>  select THREAD_INFO_IN_TASK
>> +select PCI_GENERIC_SETUP
>>  help
>>ARM 64-bit (AArch64) Linux support.
>>
>> diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
>> index d140206d5d29..c16214344f1c 100644
>> --- a/arch/m68k/Kconfig
>> +++ b/arch/m68k/Kconfig
>> @@ -22,6 +22,7 @@ config M68K
>>  select MODULES_USE_ELF_RELA
>>  select OLD_SIGSUSPEND3
>>  select OLD_SIGACTION
>> +select PCI_GENERIC_SETUP
>>
>>  config RWSEM_GENERIC_SPINLOCK
>>  bool
>> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
>> index 2828ecde133d..474a7c710686 100644
>> --- a/arch/mips/Kconfig
>> +++ b/arch/mips/Kconfig
>> @@ -70,6 +70,7 @@ config MIPS
>>  select HAVE_EXIT_THREAD
>>  select HAVE_REGS_AND_STACK_ACCESS_API
>>  select HAVE_COPY_THREAD_TLS
>> +select PCI_GENERIC_SETUP
>>
>>  menu "Machine selection"
>>
>> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
>> index ee086958b2b2..90a98ac526fb 100644
>> --- a/arch/sh/Kconfig
>> +++ b/arch/sh/Kconfig
>>

[PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

2017-06-26 Thread Palmer Dabbelt
We wanted to add RISC-V to the list of architectures that used the
generic PCI setup-irq.o inside the Makefile and it was suggested that
instead we define a Kconfig entry and use that.

I've done very minimal testing on this: I just checked to see that
an aarch64 defconfig still build setup-irq.o with the patch applied.
The intention is that this patch doesn't change the behavior of any
build.

Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
Reviewed-by: James Hogan <james.ho...@imgtec.com>
Acked-by: Russell King <rmk+ker...@armlinux.org.uk>
Acked-by: Richard Henderson <r...@twiddle.net>
Acked-by: Vineet Gupta <vgu...@synopsys.com>   [arch/arc]
---
 arch/alpha/Kconfig |  1 +
 arch/arc/Kconfig   |  1 +
 arch/arm/Kconfig   |  1 +
 arch/arm64/Kconfig |  1 +
 arch/m68k/Kconfig.bus  |  1 +
 arch/mips/Kconfig  |  1 +
 arch/sh/Kconfig|  1 +
 arch/sparc/Kconfig |  1 +
 arch/tile/Kconfig  |  1 +
 arch/unicore32/Kconfig |  1 +
 drivers/pci/Kconfig|  3 +++
 drivers/pci/Makefile   | 11 +--
 12 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 0e49d39ea74a..30f4e711f681 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -26,6 +26,7 @@ config ALPHA
select ODD_RT_SIGACTION
select OLD_SIGSUSPEND
select CPU_NO_EFFICIENT_FFS if !ALPHA_EV67
+   select PCI_GENERIC_SETUP
help
  The Alpha is a 64-bit general-purpose processor designed and
  marketed by the Digital Equipment Corporation of blessed memory,
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index a5459698f0ee..dd1f64858118 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -44,6 +44,7 @@ config ARC
select HAVE_GENERIC_DMA_COHERENT
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZMA
+   select PCI_GENERIC_SETUP
 
 config MIGHT_HAVE_PCI
bool
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4c1a35f15838..4f910c4c37b2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -93,6 +93,7 @@ config ARM
select OF_RESERVED_MEM if OF
select OLD_SIGACTION
select OLD_SIGSUSPEND3
+   select PCI_GENERIC_SETUP
select PERF_USE_VMALLOC
select RTC_LIB
select SYS_SUPPORTS_APM_EMULATION
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b2024db225a9..02d4676cb00e 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -110,6 +110,7 @@ config ARM64
select OF_EARLY_FLATTREE
select OF_RESERVED_MEM
select PCI_ECAM if ACPI
+   select PCI_GENERIC_SETUP
select POWER_RESET
select POWER_SUPPLY
select SPARSE_IRQ
diff --git a/arch/m68k/Kconfig.bus b/arch/m68k/Kconfig.bus
index 675b087198f6..bcab783f0487 100644
--- a/arch/m68k/Kconfig.bus
+++ b/arch/m68k/Kconfig.bus
@@ -61,6 +61,7 @@ config GENERIC_ISA_DMA
 config PCI
bool "PCI support"
depends on M54xx
+   select PCI_GENERIC_SETUP
help
  Enable the PCI bus. Support for the PCI bus hardware built into the
  ColdFire 547x and 548x processors.
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 2828ecde133d..474a7c710686 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -70,6 +70,7 @@ config MIPS
select HAVE_EXIT_THREAD
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_COPY_THREAD_TLS
+   select PCI_GENERIC_SETUP
 
 menu "Machine selection"
 
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index ee086958b2b2..90a98ac526fb 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -48,6 +48,7 @@ config SUPERH
select HAVE_ARCH_AUDITSYSCALL
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_NMI
+   select PCI_GENERIC_SETUP
help
  The SuperH is a RISC processor targeted for use in embedded systems
  and consumer electronics; it was also used in the Sega Dreamcast
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 5639c9fe5b55..24cea64104bd 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -424,6 +424,7 @@ config SPARC_LEON
depends on SPARC32
select USB_EHCI_BIG_ENDIAN_MMIO
select USB_EHCI_BIG_ENDIAN_DESC
+   select PCI_GENERIC_SETUP
---help---
  If you say Y here if you are running on a SPARC-LEON processor.
  The LEON processor is a synthesizable VHDL model of the
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 4583c0320059..451000db8c62 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -28,6 +28,7 @@ config TILE
select HAVE_PERF_EVENTS
select HAVE_SYSCALL_TRACEPOINTS
select MODULES_USE_ELF_RELA
+   select PCI_GENERIC_SETUP
select SYSCTL_EXCEPTION_TRACE
select SYS_HYPERVISOR
select USER_STACKTRACE_SUPPORT
diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
index 0769066929c6..162a7d3def0c 100644
--- a/a

Re: [PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

2017-06-26 Thread Palmer Dabbelt
>On Mon, Jun 26, 2017 at 7:39 AM, kbuild test robot <l...@intel.com> wrote:
>> [auto build test WARNING on linus/master]
>> [also build test WARNING on v4.12-rc6]
>> [cannot apply to next-20170623]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improve the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Palmer-Dabbelt/pci-Add-and-use-PCI_GENERIC_SETUP-Kconfig-entry/20170626-043558
>> config: m68k-allnoconfig (attached as .config)
>> compiler: m68k-linux-gcc (GCC) 4.9.0
>> reproduce:
>> wget 
>> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
>> ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # save the attached .config to linux build tree
>> make.cross ARCH=m68k
>>
>> All warnings (new ones prefixed by >>):
>>
>> warning: (M68K) selects PCI_GENERIC_SETUP which has unmet direct 
>> dependencies (MMU)
>
>I can't seem to find this dependency of PCI_GENERIC_SETUP on MMU?

It looks like M68K only includes the PCI Kconfig entry when MMU is enabled.  I
moved the select around a bit and it builds the config that was failing for me.

The updated patch is threaded.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 1/3] pci: Add a generic, weakly-linked pcibios_fixup_bus

2017-06-24 Thread Palmer Dabbelt
On Sat, 24 Jun 2017 02:34:06 PDT (-0700), ge...@linux-m68k.org wrote:
> Hi Palmer,
>
> On Sat, Jun 24, 2017 at 3:50 AM, Palmer Dabbelt <pal...@dabbelt.com> wrote:
>> Multiple architectures define this as an empty function, and I'm adding
>> another one as part of the RISC-V port.  This adds a __weak version of
>> pci_fixup_bios and deletes the now obselete ones in a handful of ports.
>>
>> The only functional change should be that microblaze used to export
>> pcibios_fixup_bus.  None of the other architectures export this, so I
>> just dropped it.
>>
>> Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
>
> Given this is an empty function, wouldn't it make more sense to have
> a static inline in asm-generic, protected by #ifndef pcibios_fixup_bus?

I think the PCI people were considering changing this from a per-arch function
to a per-controller function, so I think the inline won't help any there.  I
think since they hope to eventually clean up all the __weak functions it fits a
bit better this way, but I'm really fine with anything here.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH 2/3] pci: Add a generic, weakly-linked pcibios_align_resource

2017-06-24 Thread Palmer Dabbelt
On Sat, 24 Jun 2017 02:41:42 PDT (-0700), ge...@linux-m68k.org wrote:
> Hi Palmer,
>
> On Sat, Jun 24, 2017 at 3:50 AM, Palmer Dabbelt <pal...@dabbelt.com> wrote:
>> Multiple architectures define this as trivial function, and I'm adding
>> another one as part of the RISC-V port.  This adds a __weak version of
>> pcibios_align_resource and deletes the now obselete ones in a handful of
>> ports.
>>
>> The only functional change should be that a handful of ports used to
>> export pcibios_fixup_bus.  Only some architectures export this, so I
>> just dropped it.
>>
>> Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
>
> This function is only ever used as a pointer passed to
> pci_bus_alloc_resource()?
>
> What about having
>
> #ifndef pcibios_fixup_bus
> #define pcibios_fixup_bus NULL
> #endif
>
> in asm-generic/pci.h, letting the architecture with a non-trivial
> implementation predefine the preprocessor symbol, and teaching
> pci_bus_alloc_resource() to handle NULL?
>
> [...]
>
> Oh, the latter eventually calls into allocate_resource(), which already falls
> back to simple_align_resource() if the alignment function is NULL, which
> does the same thing.
> So NULL should already work.

I'm OK with that, but like your comments on the last one I think it might fit
better as a __weak function.  I think there were also some questions as to
whether these should actually be empty functions or not.  I'm really happy with
either way.

Since this is all out of my wheelhouse, can one of the PCI maintainers chime in
as to what I should do here?

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


[PATCH 1/3] pci: Add a generic, weakly-linked pcibios_fixup_bus

2017-06-23 Thread Palmer Dabbelt
Multiple architectures define this as an empty function, and I'm adding
another one as part of the RISC-V port.  This adds a __weak version of
pci_fixup_bios and deletes the now obselete ones in a handful of ports.

The only functional change should be that microblaze used to export
pcibios_fixup_bus.  None of the other architectures export this, so I
just dropped it.

Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
---
 arch/arc/kernel/pcibios.c |  4 
 arch/arm64/kernel/pci.c   |  8 
 arch/cris/arch-v32/drivers/pci/bios.c |  4 
 arch/microblaze/pci/pci-common.c  |  6 --
 arch/s390/pci/pci.c   |  4 
 arch/sh/drivers/pci/pci.c |  8 
 arch/sparc/kernel/pci.c   |  4 
 arch/tile/kernel/pci.c|  8 
 arch/tile/kernel/pci_gx.c |  5 -
 drivers/pci/probe.c   | 10 ++
 10 files changed, 10 insertions(+), 51 deletions(-)

diff --git a/arch/arc/kernel/pcibios.c b/arch/arc/kernel/pcibios.c
index 72e1d73d0bd6..1c8df8fd5fed 100644
--- a/arch/arc/kernel/pcibios.c
+++ b/arch/arc/kernel/pcibios.c
@@ -16,7 +16,3 @@ resource_size_t pcibios_align_resource(void *data, const 
struct resource *res,
 {
return res->start;
 }
-
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-}
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index c7e3e6387a49..4c7f451aca05 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -23,14 +23,6 @@
 #include 
 
 /*
- * Called after each bus is probed, but before its children are examined
- */
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-   /* nothing to do, expected to be removed in the future */
-}
-
-/*
  * We don't have to worry about legacy ISA devices, so nothing to do here
  */
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
diff --git a/arch/cris/arch-v32/drivers/pci/bios.c 
b/arch/cris/arch-v32/drivers/pci/bios.c
index 394c2a73d5e2..5cc622c0225e 100644
--- a/arch/cris/arch-v32/drivers/pci/bios.c
+++ b/arch/cris/arch-v32/drivers/pci/bios.c
@@ -2,10 +2,6 @@
 #include 
 #include 
 
-void pcibios_fixup_bus(struct pci_bus *b)
-{
-}
-
 void pcibios_set_master(struct pci_dev *dev)
 {
u8 lat;
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 404fb38d06b7..940f266e5d5c 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -810,12 +810,6 @@ void pcibios_setup_bus_devices(struct pci_bus *bus)
}
 }
 
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-   /* nothing to do */
-}
-EXPORT_SYMBOL(pcibios_fixup_bus);
-
 /*
  * We need to avoid collisions with `mirrored' VGA ports
  * and other strange ISA hardware, so we always want the
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
index 8051df109db3..98a54dd63483 100644
--- a/arch/s390/pci/pci.c
+++ b/arch/s390/pci/pci.c
@@ -234,10 +234,6 @@ static int zpci_cfg_store(struct zpci_dev *zdev, int 
offset, u32 val, u8 len)
return rc;
 }
 
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-}
-
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
   resource_size_t size,
   resource_size_t align)
diff --git a/arch/sh/drivers/pci/pci.c b/arch/sh/drivers/pci/pci.c
index c99ee286b69f..749642e1272e 100644
--- a/arch/sh/drivers/pci/pci.c
+++ b/arch/sh/drivers/pci/pci.c
@@ -155,14 +155,6 @@ static int __init pcibios_init(void)
 subsys_initcall(pcibios_init);
 
 /*
- *  Called after each bus is probed, but before its children
- *  are examined.
- */
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-}
-
-/*
  * We need to avoid collisions with `mirrored' VGA ports
  * and other strange ISA hardware, so we always want the
  * addresses to be allocated in the 0x000-0x0ff region
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 7eceaa10836f..78d3dc25e126 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -690,10 +690,6 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
return bus;
 }
 
-void pcibios_fixup_bus(struct pci_bus *pbus)
-{
-}
-
 resource_size_t pcibios_align_resource(void *data, const struct resource *res,
resource_size_t size, resource_size_t align)
 {
diff --git a/arch/tile/kernel/pci.c b/arch/tile/kernel/pci.c
index bc6656b5708b..3113d4d5c329 100644
--- a/arch/tile/kernel/pci.c
+++ b/arch/tile/kernel/pci.c
@@ -369,14 +369,6 @@ int __init pcibios_init(void)
 }
 subsys_initcall(pcibios_init);
 
-/*
- * No bus fixups needed.
- */
-void pcibios_fixup_bus(struct pci_bus *bus)
-{
-   /* Nothing needs to be done. */
-}
-
 void pcibios_set_master(struct pci_dev *dev)
 {
/* No special bus mastering setup handling. */
diff --git a/arch/tile/kernel/pci_gx.c b/arch/tile/kernel/pci_gx.c
index b554a68eea1b..b89172b592cc 100644
-

[PATCH 3/3] arc: kernel/pcibios.c is empty, delete it

2017-06-23 Thread Palmer Dabbelt
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
---
 arch/arc/kernel/Makefile  | 1 -
 arch/arc/kernel/pcibios.c | 9 -
 2 files changed, 10 deletions(-)
 delete mode 100644 arch/arc/kernel/pcibios.c

diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile
index 8942c5c3b4c5..2dc5f4296d44 100644
--- a/arch/arc/kernel/Makefile
+++ b/arch/arc/kernel/Makefile
@@ -12,7 +12,6 @@ obj-y := arcksyms.o setup.o irq.o reset.o ptrace.o process.o 
devtree.o
 obj-y  += signal.o traps.o sys.o troubleshoot.o stacktrace.o disasm.o
 obj-$(CONFIG_ISA_ARCOMPACT)+= entry-compact.o intc-compact.o
 obj-$(CONFIG_ISA_ARCV2)+= entry-arcv2.o intc-arcv2.o
-obj-$(CONFIG_PCI)  += pcibios.o
 
 obj-$(CONFIG_MODULES)  += arcksyms.o module.o
 obj-$(CONFIG_SMP)  += smp.o
diff --git a/arch/arc/kernel/pcibios.c b/arch/arc/kernel/pcibios.c
deleted file mode 100644
index 05aba5a7b5d2..
--- a/arch/arc/kernel/pcibios.c
+++ /dev/null
@@ -1,9 +0,0 @@
-/*
- * Copyright (C) 2014-2015 Synopsys, Inc. (www.synopsys.com)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include 
-- 
2.13.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


[PATCH 2/3] pci: Add a generic, weakly-linked pcibios_align_resource

2017-06-23 Thread Palmer Dabbelt
Multiple architectures define this as trivial function, and I'm adding
another one as part of the RISC-V port.  This adds a __weak version of
pcibios_align_resource and deletes the now obselete ones in a handful of
ports.

The only functional change should be that a handful of ports used to
export pcibios_fixup_bus.  Only some architectures export this, so I
just dropped it.

Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
---
 arch/arc/kernel/pcibios.c|  9 -
 arch/arm64/kernel/pci.c  |  9 -
 arch/ia64/pci/pci.c  |  7 ---
 arch/microblaze/pci/pci-common.c |  7 ---
 arch/sparc/kernel/leon_pci.c |  6 --
 arch/sparc/kernel/pci.c  |  6 --
 arch/sparc/kernel/pcic.c |  6 --
 arch/tile/kernel/pci.c   | 10 --
 arch/tile/kernel/pci_gx.c|  9 -
 drivers/pci/setup-res.c  | 12 
 10 files changed, 12 insertions(+), 69 deletions(-)

diff --git a/arch/arc/kernel/pcibios.c b/arch/arc/kernel/pcibios.c
index 1c8df8fd5fed..05aba5a7b5d2 100644
--- a/arch/arc/kernel/pcibios.c
+++ b/arch/arc/kernel/pcibios.c
@@ -7,12 +7,3 @@
  */
 
 #include 
-
-/*
- * We don't have to worry about legacy ISA devices, so nothing to do here
- */
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 4c7f451aca05..9753ca23cfa1 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -23,15 +23,6 @@
 #include 
 
 /*
- * We don't have to worry about legacy ISA devices, so nothing to do here
- */
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
-/*
  * Try to assign the IRQ number when probing a new device
  */
 int pcibios_alloc_irq(struct pci_dev *dev)
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 4068bde623dc..f5ec736100ee 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -411,13 +411,6 @@ pcibios_disable_device (struct pci_dev *dev)
acpi_pci_irq_disable(dev);
 }
 
-resource_size_t
-pcibios_align_resource (void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
 /**
  * ia64_pci_get_legacy_mem - generic legacy mem routine
  * @bus: bus to get legacy memory base address for
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 940f266e5d5c..5835c09c6e26 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -823,13 +823,6 @@ void pcibios_setup_bus_devices(struct pci_bus *bus)
  * but we want to try to avoid allocating at 0x2900-0x2bff
  * which might have be mirrored at 0x0100-0x03ff..
  */
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-EXPORT_SYMBOL(pcibios_align_resource);
-
 int pcibios_add_device(struct pci_dev *dev)
 {
dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
diff --git a/arch/sparc/kernel/leon_pci.c b/arch/sparc/kernel/leon_pci.c
index 4371f72ff025..0eafdf3d036d 100644
--- a/arch/sparc/kernel/leon_pci.c
+++ b/arch/sparc/kernel/leon_pci.c
@@ -94,9 +94,3 @@ void pcibios_fixup_bus(struct pci_bus *pbus)
}
}
 }
-
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 78d3dc25e126..3f8670c92951 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -690,12 +690,6 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
return bus;
 }
 
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
 int pcibios_enable_device(struct pci_dev *dev, int mask)
 {
u16 cmd, oldcmd;
diff --git a/arch/sparc/kernel/pcic.c b/arch/sparc/kernel/pcic.c
index a38787b84322..e038e343f2c1 100644
--- a/arch/sparc/kernel/pcic.c
+++ b/arch/sparc/kernel/pcic.c
@@ -746,12 +746,6 @@ static void watchdog_reset() {
 }
 #endif
 
-resource_size_t pcibios_align_resource(void *data, const struct resource *res,
-   resource_size_t size, resource_size_t align)
-{
-   return res->start;
-}
-
 int pcibios_enable_device(struct pci_dev *pdev, int mask)
 {
return 0;
diff --git a/arch/tile/kernel/pci.c b/arch/tile/kernel/pci.c
index 3113d4d5c329..8999a20ed9d1 100644
--- a/arch/tile/kernel/pci.

pci: Add generic pcibios_{fixup_bus,align_resource}

2017-06-23 Thread Palmer Dabbelt
While upstreaming the RISC-V port, it was pointed out that multiple
architectures have copied the mostly empty versions of at least one of these
functions.  This defines weakly bound versions of the common functions and
removes the now obselete functions from other ports.

This has been split out from the RISC-V submission so we can decouple all these
generic changes from our port review process.  There's some discussion on an
earlier version of the patch here

  https://lkml.org/lkml/2017/6/6/998

but I'm afraid a lot of this is really out of my wheelhouse (and I'm pretty
slammed trying to get the RISC-V port in better shape), so I'm afraid I'm not
going to be able to perform the full cleanup suggested.


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

2017-06-23 Thread Palmer Dabbelt
On Fri, 23 Jun 2017 15:01:04 PDT (-0700), james.ho...@imgtec.com wrote:
> On Fri, Jun 23, 2017 at 02:45:38PM -0700, Palmer Dabbelt wrote:
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 4c1a35f15838..86872246951c 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -96,6 +96,7 @@ config ARM
>>  select PERF_USE_VMALLOC
>>  select RTC_LIB
>>  select SYS_SUPPORTS_APM_EMULATION
>> +select PCI_GENERIC_SETUP
>>  # Above selects are sorted alphabetically; please add new ones
>>  # according to that.  Thanks.
>
> This comment seems to suggest PCI_GENERIC_SETUP should be added a few
> lines up to preserve the alphabetical sorting.
>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index b2024db225a9..6c684d8c8816 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -115,6 +115,7 @@ config ARM64
>>  select SPARSE_IRQ
>>  select SYSCTL_EXCEPTION_TRACE
>>  select THREAD_INFO_IN_TASK
>> +select PCI_GENERIC_SETUP
>
> Here too.
>
>> diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
>> index 4583c0320059..6679af85a882 100644
>> --- a/arch/tile/Kconfig
>> +++ b/arch/tile/Kconfig
>> @@ -33,6 +33,7 @@ config TILE
>>  select USER_STACKTRACE_SUPPORT
>>  select USE_PMC if PERF_EVENTS
>>  select VIRT_TO_BUS
>> +select PCI_GENERIC_SETUP
>
> and here
>
> Otherwise
> Reviewed-by: James Hogan <james.ho...@imgtec.com>

Whoops -- I guess I was just on autopilot after seeing the first one not be
alphabetized.  A fixed patch is in a threaded message.

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


[PATCH] pci: Add and use PCI_GENERIC_SETUP Kconfig entry

2017-06-23 Thread Palmer Dabbelt
We wanted to add RISC-V to the list of architectures that used the
generic PCI setup-irq.o inside the Makefile and it was suggested that
instead we define a Kconfig entry and use that.

I've done very minimal testing on this: I just checked to see that
an aarch64 defconfig still build setup-irq.o with the patch applied.
The intention is that this patch doesn't change the behavior of any
build.

Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
---
 arch/alpha/Kconfig |  1 +
 arch/arc/Kconfig   |  1 +
 arch/arm/Kconfig   |  1 +
 arch/arm64/Kconfig |  1 +
 arch/m68k/Kconfig  |  1 +
 arch/mips/Kconfig  |  1 +
 arch/sh/Kconfig|  1 +
 arch/sparc/Kconfig |  1 +
 arch/tile/Kconfig  |  1 +
 arch/unicore32/Kconfig |  1 +
 drivers/pci/Kconfig|  3 +++
 drivers/pci/Makefile   | 11 +--
 12 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index 0e49d39ea74a..30f4e711f681 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -26,6 +26,7 @@ config ALPHA
select ODD_RT_SIGACTION
select OLD_SIGSUSPEND
select CPU_NO_EFFICIENT_FFS if !ALPHA_EV67
+   select PCI_GENERIC_SETUP
help
  The Alpha is a 64-bit general-purpose processor designed and
  marketed by the Digital Equipment Corporation of blessed memory,
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index a5459698f0ee..dd1f64858118 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -44,6 +44,7 @@ config ARC
select HAVE_GENERIC_DMA_COHERENT
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZMA
+   select PCI_GENERIC_SETUP
 
 config MIGHT_HAVE_PCI
bool
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4c1a35f15838..86872246951c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -96,6 +96,7 @@ config ARM
select PERF_USE_VMALLOC
select RTC_LIB
select SYS_SUPPORTS_APM_EMULATION
+   select PCI_GENERIC_SETUP
# Above selects are sorted alphabetically; please add new ones
# according to that.  Thanks.
help
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b2024db225a9..6c684d8c8816 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -115,6 +115,7 @@ config ARM64
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select THREAD_INFO_IN_TASK
+   select PCI_GENERIC_SETUP
help
  ARM 64-bit (AArch64) Linux support.
 
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index d140206d5d29..c16214344f1c 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -22,6 +22,7 @@ config M68K
select MODULES_USE_ELF_RELA
select OLD_SIGSUSPEND3
select OLD_SIGACTION
+   select PCI_GENERIC_SETUP
 
 config RWSEM_GENERIC_SPINLOCK
bool
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 2828ecde133d..474a7c710686 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -70,6 +70,7 @@ config MIPS
select HAVE_EXIT_THREAD
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_COPY_THREAD_TLS
+   select PCI_GENERIC_SETUP
 
 menu "Machine selection"
 
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index ee086958b2b2..90a98ac526fb 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -48,6 +48,7 @@ config SUPERH
select HAVE_ARCH_AUDITSYSCALL
select HAVE_FUTEX_CMPXCHG if FUTEX
select HAVE_NMI
+   select PCI_GENERIC_SETUP
help
  The SuperH is a RISC processor targeted for use in embedded systems
  and consumer electronics; it was also used in the Sega Dreamcast
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 5639c9fe5b55..24cea64104bd 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -424,6 +424,7 @@ config SPARC_LEON
depends on SPARC32
select USB_EHCI_BIG_ENDIAN_MMIO
select USB_EHCI_BIG_ENDIAN_DESC
+   select PCI_GENERIC_SETUP
---help---
  If you say Y here if you are running on a SPARC-LEON processor.
  The LEON processor is a synthesizable VHDL model of the
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 4583c0320059..6679af85a882 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -33,6 +33,7 @@ config TILE
select USER_STACKTRACE_SUPPORT
select USE_PMC if PERF_EVENTS
select VIRT_TO_BUS
+   select PCI_GENERIC_SETUP
 
 config MMU
def_bool y
diff --git a/arch/unicore32/Kconfig b/arch/unicore32/Kconfig
index 0769066929c6..162a7d3def0c 100644
--- a/arch/unicore32/Kconfig
+++ b/arch/unicore32/Kconfig
@@ -18,6 +18,7 @@ config UNICORE32
select ARCH_WANT_FRAME_POINTERS
select GENERIC_IOMAP
select MODULES_USE_ELF_REL
+   select PCI_GENERIC_SETUP
help
  UniCore-32 is 32-bit Instruction Set Architecture,
  including a series of low-power-consumption RISC chip
diff --git a/drivers/pci/Kconfig b/dri