Re: [PATCH] vhost: do not enable VHOST_MENU by default
On Tue, Apr 14, 2020 at 10:44:38AM +0800, Jason Wang wrote:
> We try to keep the defconfig untouched after decoupling CONFIG_VHOST
> out of CONFIG_VIRTUALIZATION in commit 20c384f1ea1a
> ("vhost: refine vhost and vringh kconfig") by enabling VHOST_MENU by
> default. Then the defconfigs can keep enabling CONFIG_VHOST_NET
> without the caring of CONFIG_VHOST.
>
> But this will leave a "CONFIG_VHOST_MENU=y" in all defconfigs and even
> for the ones that doesn't want vhost. So it actually shifts the
> burdens to the maintainers of all other to add "CONFIG_VHOST_MENU is
> not set". So this patch tries to enable CONFIG_VHOST explicitly in
> defconfigs that enables CONFIG_VHOST_NET and CONFIG_VHOST_VSOCK.
>
> Cc: Thomas Bogendoerfer
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Christian Borntraeger
> Reported-by: Geert Uytterhoeven
> Signed-off-by: Jason Wang
> ---
> arch/mips/configs/malta_kvm_defconfig | 1 +
Acked-by: Thomas Bogendoerfer
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH 03/31] MIPS: unexport __flush_icache_user_range
On Sun, May 10, 2020 at 09:54:42AM +0200, Christoph Hellwig wrote: > __flush_icache_user_range is not used in modular code, so unexport it. > > Signed-off-by: Christoph Hellwig > --- > arch/mips/mm/cache.c | 1 - > 1 file changed, 1 deletion(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH] ibmveth: Fix use of ibmveth in a bridge.
On Mon, 26 Oct 2020 11:52:37 -0700
Jakub Kicinski wrote:
> On Mon, 26 Oct 2020 11:42:21 +0100 Michal Suchanek wrote:
> > From: Thomas Bogendoerfer
> >
> > The check for src mac address in ibmveth_is_packet_unsupported is wrong.
> > Commit 6f2275433a2f wanted to shut down messages for loopback packets,
> > but now suppresses bridged frames, which are accepted by the hypervisor
> > otherwise bridging won't work at all.
> >
> > Fixes: 6f2275433a2f ("ibmveth: Detect unsupported packets before sending to
> > the hypervisor")
> > Signed-off-by: Michal Suchanek
>
> Since the From: line says Thomas we need a signoff from him.
you can add
Signed-off-by: tbogendoer...@suse.de
Thomas.
--
SUSE Software Solutions Germany GmbH
HRB 36809 (AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Re: [PATCH v2 12/17] arch, drivers: replace for_each_membock() with for_each_mem_range()
On Sun, Aug 02, 2020 at 07:35:56PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> There are several occurrences of the following pattern:
>
> for_each_memblock(memory, reg) {
> start = __pfn_to_phys(memblock_region_memory_base_pfn(reg);
> end = __pfn_to_phys(memblock_region_memory_end_pfn(reg));
>
> /* do something with start and end */
> }
>
> Using for_each_mem_range() iterator is more appropriate in such cases and
> allows simpler and cleaner code.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/mips/cavium-octeon/dma-octeon.c | 12 +++---
> arch/mips/kernel/setup.c | 31 +++
Acked-by: Thomas Bogendoerfer
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2 17/17] memblock: use separate iterators for memory and reserved regions
On Sun, Aug 02, 2020 at 07:36:01PM +0300, Mike Rapoport wrote: > From: Mike Rapoport > > for_each_memblock() is used to iterate over memblock.memory in > a few places that use data from memblock_region rather than the memory > ranges. > > Introduce separate for_each_mem_region() and for_each_reserved_mem_region() > to improve encapsulation of memblock internals from its users. > > Signed-off-by: Mike Rapoport > --- > arch/mips/netlogic/xlp/setup.c | 2 +- Acked-by: Thomas Bogendoerfer Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 13/20] Documentation: mips/ingenic-tcu: eliminate duplicated word
On Tue, Jul 07, 2020 at 11:04:07AM -0700, Randy Dunlap wrote: > Drop the doubled word "to". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Paul Cercueil > Cc: Thomas Bogendoerfer > Cc: linux-m...@vger.kernel.org > --- > Documentation/mips/ingenic-tcu.rst |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Thomas Bogendoerfer Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 16/17] arch: remove HAVE_COPY_THREAD_TLS
On Tue, Jun 23, 2020 at 01:43:25AM +0200, Christian Brauner wrote: > All architectures support copy_thread_tls() now, so remove the legacy > copy_thread() function and the HAVE_COPY_THREAD_TLS config option. Everyone > uses the same process creation calling convention based on > copy_thread_tls() and struct kernel_clone_args. This will make it easier to > maintain the core process creation code under kernel/, simplifies the > callpaths and makes the identical for all architectures. > [..] > arch/mips/Kconfig | 1 - Acked-by: Thomas Bogendoerfer Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 17/17] arch: rename copy_thread_tls() back to copy_thread()
On Tue, Jun 23, 2020 at 01:43:26AM +0200, Christian Brauner wrote: > Now that HAVE_COPY_THREAD_TLS has been removed, rename copy_thread_tls() > back simply copy_thread(). It's a simpler name, and doesn't imply that only > tls is copied here. This finishes an outstanding chunk of internal process > creation work since we've added clone3(). > [..] > arch/mips/kernel/process.c | 2 +- Acked-by: Thomas Bogendoerfer Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2 0/5] drop unused BACKLIGHT_GENERIC option
On Tue, Dec 08, 2020 at 05:34:46PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> On Tue, 1 Dec 2020 22:29:17 +, Andrey Zhizhikin wrote:
> > Since the removal of generic_bl driver from the source tree in commit
> > 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> > unused") BACKLIGHT_GENERIC config option became obsolete as well and
> > therefore subject to clean-up from all configuration files.
> >
> > This series introduces patches to address this removal, separated by
> > architectures in the kernel tree.
> >
> > [...]
>
> While my plan was to only take the arm specific patches, it seems
> nobody else has applied the other architecture specific ones,
> but there have been a lot of Acks. Also, b4 makes it easy to
> merge the entire branch, so I'll just take all of these.
>
> Applied to arm/defconfig, thanks!
>
> [1/5] ARM: configs: drop unused BACKLIGHT_GENERIC option
> commit: 0437141b4e2233ae0109a9584e7a003cd05b0a20
> [2/5] arm64: defconfig: drop unused BACKLIGHT_GENERIC option
> commit: 717c4c8336486781630893508b3347ae18953fae
> [3/5] MIPS: configs: drop unused BACKLIGHT_GENERIC option
> commit: 2257682282531de45929c6006152f6e2ee881b42
this one is already in mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2 3/5] MIPS: configs: drop unused BACKLIGHT_GENERIC option
On Tue, Dec 01, 2020 at 10:29:20PM +, Andrey Zhizhikin wrote:
> Commit 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> unused") removed geenric_bl driver from the tree, together with
> corresponding config option.
>
> Remove BACKLIGHT_GENERIC config item from all MIPS configurations.
>
> Fixes: 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> unused")
> Cc: Sam Ravnborg
> Signed-off-by: Andrey Zhizhikin
> Reviewed-by: Krzysztof Kozlowski
> Acked-by: Daniel Thompson
> Acked-by: Sam Ravnborg
> ---
> arch/mips/configs/gcw0_defconfig | 1 -
> arch/mips/configs/gpr_defconfig | 1 -
> arch/mips/configs/lemote2f_defconfig | 1 -
> arch/mips/configs/loongson3_defconfig | 1 -
> arch/mips/configs/mtx1_defconfig | 1 -
> arch/mips/configs/rs90_defconfig | 1 -
> 6 files changed, 6 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH 2/3] kbuild: LD_VERSION redenomination
On Sun, Dec 13, 2020 at 01:54:30AM +0900, Masahiro Yamada wrote:
> Commit ccbef1674a15 ("Kbuild, lto: add ld-version and ld-ifversion
> macros") introduced scripts/ld-version.sh for GCC LTO.
>
> At that time, this script handled 5 version fields because GCC LTO
> needed the downstream binutils. (https://lkml.org/lkml/2014/4/8/272)
>
> The code snippet from the submitted patch was as follows:
>
> # We need HJ Lu's Linux binutils because mainline binutils does not
> # support mixing assembler and LTO code in the same ld -r object.
> # XXX check if the gcc plugin ld is the expected one too
> # XXX some Fedora binutils should also support it. How to check for that?
> ifeq ($(call ld-ifversion,-ge,22710001,y),y)
> ...
>
> However, GCC LTO was not merged into the mainline after all.
> (https://lkml.org/lkml/2014/4/8/272)
>
> So, the 4th and 5th fields were never used, and finally removed by
> commit 0d61ed17dd30 ("ld-version: Drop the 4th and 5th version
> components").
>
> Since then, the last 4-digits returned by this script is always zeros.
>
> Remove the meaningless last 4-digits. This makes the version format
> consistent with GCC_VERSION, CLANG_VERSION, LLD_VERSION.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/mips/loongson64/Platform | 2 +-
> arch/mips/vdso/Kconfig| 2 +-
Acked-by: Thomas Bogendoerfer
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
On Fri, Nov 13, 2020 at 03:59:32PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Stefan Agner reported a bug when using zsram on 32-bit Arm machines
> with RAM above the 4GB address boundary:
>
> Unable to handle kernel NULL pointer dereference at virtual address
> pgd = a27bd01c
> [] *pgd=236a0003, *pmd=1ffa64003
> Internal error: Oops: 207 [#1] SMP ARM
> Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil
> raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet
> CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
> Hardware name: BCM2711
> PC is at zs_map_object+0x94/0x338
> LR is at zram_bvec_rw.constprop.0+0x330/0xa64
> pc : []lr : []psr: 6013
> sp : e376bbe0 ip : fp : c1e2921c
> r10: 0002 r9 : c1dda730 r8 :
> r7 : e8ff7a00 r6 : r5 : 02f9ffa0 r4 : e371
> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 :
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5383d Table: 235c2a80 DAC: fffd
> Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
> Stack: (0xe376bbe0 to 0xe376c000)
>
> As it turns out, zsram needs to know the maximum memory size, which
> is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in
> MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture.
>
> The same problem will be hit on all 32-bit architectures that have a
> physical address space larger than 4GB and happen to not enable sparsemem
> and include asm/sparsemem.h from asm/pgtable.h.
>
> After the initial discussion, I suggested just always defining
> MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is
> set, or provoking a build error otherwise. This addresses all
> configurations that can currently have this runtime bug, but
> leaves all other configurations unchanged.
>
> I looked up the possible number of bits in source code and
> datasheets, here is what I found:
>
> - on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used
> - on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never
>support more than 32 bits, even though supersections in theory allow
>up to 40 bits as well.
> - on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5
>XPA supports up to 60 bits in theory, but 40 bits are more than
>anyone will ever ship
> - On PowerPC, there are three different implementations of 36 bit
>addressing, but 32-bit is used without CONFIG_PTE_64BIT
> - On RISC-V, the normal page table format can support 34 bit
>addressing. There is no highmem support on RISC-V, so anything
>above 2GB is unused, but it might be useful to eventually support
>CONFIG_ZRAM for high pages.
>
> Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
> Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS")
> Cc: Stefan Agner
> Cc: Mike Rapoport
> Cc: Kirill A. Shutemov
> Cc: Nitin Gupta
> Cc: Minchan Kim
> Cc: Vineet Gupta
> Cc: linux-snps-...@lists.infradead.org
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Thomas Bogendoerfer
> Cc: linux-m...@vger.kernel.org
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Albert Ou
> Cc: linux-ri...@lists.infradead.org
> Link:
> https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.ste...@agner.ch/
> Signed-off-by: Arnd Bergmann
> ---
> If everyone is happy with this version, I would suggest merging this as
> a bugfix through my asm-generic tree for linux-5.10. I originally
> said I'd send individual patches for each architecture tree, but
> I now think this is easier and better documents what is going on.
> ---
> arch/mips/include/asm/pgtable-32.h | 3 +++
Acked-by: Thomas Bogendoerfer
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote: > Hi Thomas, > > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. > > Any idea what could be happening? not yet, kernel crash log of a Malta QEMU is below. Thomas. Kernel bug detected[#1]: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc1-00017-gccb21774863a #2 $ 0 : 0001 0010 $ 4 : 0001 05cf 9e00059f $ 8 : 00118173 809e6db8 9e00059f $12 : 82023c00 0001 810da04c 0212422f $16 : 810da000 00027800 05cf 80b4bf9c $20 : 809e968c 82602400 810da000 000b $24 : 021558f9 $28 : 820e 820e3928 80b1 802710d0 Hi: 346c Lo: 02dd epc : 80271114 __kmap_local_pfn_prot+0x78/0x1c0 ra: 802710d0 __kmap_local_pfn_prot+0x34/0x1c0 Status: 1000a403KERNEL EXL IE Cause : 00800034 (ExcCode 0d) PrId : 0001a800 (MIPS P5600) Modules linked in: Process swapper/0 (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=) Stack : 7fff 820c2408 820e3990 ff04 0a00 80518224 81a4 810da000 0001 05cf fff64000 8011c77c 820e3b26 ff04 0a00 80518440 80b3 80b4bf64 9e0005cf 05cf fff64000 80271188 820e3a60 80b1 80194478 005e 80954406 809e 810da000 0001 05cf fff68000 8011c77c 8088fd44 809f6074 00f4 80b4bf68 ... Call Trace: [<80271114>] __kmap_local_pfn_prot+0x78/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<8011c77c>] __update_cache+0x16c/0x174 [<80271188>] __kmap_local_pfn_prot+0xec/0x1c0 [<802c49a0>] copy_string_kernel+0x168/0x264 [<802c5d18>] kernel_execve+0xd0/0x164 [<801006cc>] try_to_run_init_process+0x18/0x5c [<80859e0c>] kernel_init+0xd0/0x120 [<801037f8>] ret_from_kernel_thread+0x14/0x1c Code: 8c630564 28640010 38840001 <00040336> 8f82000c 2463 00021100 00431021 2403ffbf -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [patch V3 13/37] mips/mm/highmem: Switch to generic kmap atomic
On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote: > On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote: > > Hi Thomas, > > > > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit. > > > > Any idea what could be happening? > > not yet, kernel crash log of a Malta QEMU is below. update: This dirty hack lets the Malta QEMU boot again: diff --git a/mm/highmem.c b/mm/highmem.c index c3a9ea7875ef..190cdda1149d 100644 --- a/mm/highmem.c +++ b/mm/highmem.c @@ -515,7 +515,7 @@ void *__kmap_local_pfn_prot(unsigned long pfn, pgprot_t prot) vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx); BUG_ON(!pte_none(*(kmap_pte - idx))); pteval = pfn_pte(pfn, prot); - set_pte_at(_mm, vaddr, kmap_pte - idx, pteval); + set_pte(kmap_pte - idx, pteval); arch_kmap_local_post_map(vaddr, pteval); current->kmap_ctrl.pteval[kmap_local_idx()] = pteval; preempt_enable(); set_pte_at() tries to update cache and could do an kmap_atomic() there. Not sure, if this is allowed at this point. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [patch 3/4] mips/mm/highmem: Use set_pte() for kmap_local()
On Tue, Jan 12, 2021 at 06:01:39PM +0100, Thomas Gleixner wrote:
> set_pte_at() on MIPS invokes update_cache() which might recurse into
> kmap_local(). Use set_pte() like the original MIPS highmem implementation
> did.
>
> Fixes: a4c33e83bca1 ("mips/mm/highmem: Switch to generic kmap atomic")
> Reported-by: Paul Cercueil
> Reported-by: Thomas Bogendoerfer
> Signed-off-by: Thomas Gleixner
> ---
> arch/mips/include/asm/highmem.h |1 +
> 1 file changed, 1 insertion(+)
Acked-by: Thomas Bogendoerfer
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH 08/10] MIPS: disable CONFIG_IDE in malta*_defconfig
On Thu, Mar 18, 2021 at 05:57:04AM +0100, Christoph Hellwig wrote: > Various malta defconfigs enable CONFIG_IDE for the tc86c001 ide driver, > hich is a Toshiba plug in card that does not make much sense to use on > bigsur platforms. For all other ATA cards libata support is already > enabled. > > Signed-off-by: Christoph Hellwig > --- > arch/mips/configs/malta_kvm_defconfig | 3 --- > arch/mips/configs/malta_kvm_guest_defconfig | 3 --- > arch/mips/configs/maltaup_xpa_defconfig | 3 --- > 3 files changed, 9 deletions(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 06/10] MIPS: disable CONFIG_IDE in rbtx49xx_defconfig
On Thu, Mar 18, 2021 at 05:57:02AM +0100, Christoph Hellwig wrote: > rbtx49xx_defconfig enables CONFIG_IDE for the tx4938 and tx4939 ide > drivers, but those aren't actually used by the last known remaining user: > > https://lore.kernel.org/lkml/20210107.101729.1936921832901251107.an...@mba.ocn.ne.jp/ > > Signed-off-by: Christoph Hellwig > --- > arch/mips/configs/rbtx49xx_defconfig | 3 --- > 1 file changed, 3 deletions(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 04/10] MIPS: disable CONFIG_IDE in sb1250_swarm_defconfig
On Thu, Mar 18, 2021 at 05:57:00AM +0100, Christoph Hellwig wrote: > sb1250_swarm_defconfig enables CONFIG_IDE but no actual host controller > driver, so just drop CONFIG_IDE, CONFIG_BLK_DEV_IDECD and > CONFIG_BLK_DEV_IDETAPE as they are useless. > > Signed-off-by: Christoph Hellwig > --- > arch/mips/configs/sb1250_swarm_defconfig | 3 --- > 1 file changed, 3 deletions(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 05/10] MIPS: switch workpad_defconfig from legacy IDE to libata
On Thu, Mar 18, 2021 at 05:57:01AM +0100, Christoph Hellwig wrote: > Use libata instead of the deprecated legacy ide driver in > workpad_defconfig. > > Signed-off-by: Christoph Hellwig > --- > arch/mips/configs/workpad_defconfig | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 07/10] MIPS: disable CONFIG_IDE in bigsur_defconfig
On Thu, Mar 18, 2021 at 05:57:03AM +0100, Christoph Hellwig wrote: > bigsur_defconfig enables CONFIG_IDE for the tc86c001 ide driver, which > is a Toshiba plug in card that does not make much sense to use on bigsur > platforms. For all other ATA cards libata support is already enabled. > > Signed-off-by: Christoph Hellwig > --- > arch/mips/configs/bigsur_defconfig | 4 > 1 file changed, 4 deletions(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 6/9] mips: netlogic: Use irq_domain_simple_ops for XLP PIC
On Tue, Apr 06, 2021 at 10:35:54AM +0100, Marc Zyngier wrote: > Use the generic irq_domain_simple_ops structure instead of > a home-grown one. > > Signed-off-by: Marc Zyngier > --- > arch/mips/netlogic/common/irq.c | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) Acked-by: Thomas Bogendoerfer -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 08/10] MIPS: disable CONFIG_IDE in malta*_defconfig
On Thu, Mar 18, 2021 at 05:57:04AM +0100, Christoph Hellwig wrote: > arch/mips/configs/malta_kvm_guest_defconfig | 3 --- that file is gone in mips-next. I could take all MIPS patches into mips-next, if you want... Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2 1/1] kernel.h: Split out panic and oops helpers
On Fri, Apr 09, 2021 at 01:02:50PM +0300, Andy Shevchenko wrote: > kernel.h is being used as a dump for all kinds of stuff for a long time. > Here is the attempt to start cleaning it up by splitting out panic and > oops helpers. > > There are several purposes of doing this: > - dropping dependency in bug.h > - dropping a loop by moving out panic_notifier.h > - unload kernel.h from something which has its own domain > > At the same time convert users tree-wide to use new headers, although > for the time being include new header back to kernel.h to avoid twisted > indirected includes for existing users. > > Signed-off-by: Andy Shevchenko > Reviewed-by: Bjorn Andersson > Acked-by: Mike Rapoport > Acked-by: Corey Minyard > Acked-by: Christian Brauner > Acked-by: Arnd Bergmann > Acked-by: Kees Cook > Acked-by: Wei Liu > Acked-by: Rasmus Villemoes > Signed-off-by: Andrew Morton > --- > v2: > - fixed all errors with allmodconfig on x86_64 (Andrew) > - checked with allyesconfig on x86_64 > - additionally grepped source code for panic notifier list usage >and converted all users > - elaborated commit message (Luis) > - collected given tags (incl. Andrew's SoB, see below) > > I added Andrew's SoB since part of the fixes I took from him. Andrew, > feel free to amend or tell me how you want me to do. > > arch/mips/kernel/relocate.c | 1 + > arch/mips/sgi-ip22/ip22-reset.c | 1 + > arch/mips/sgi-ip32/ip32-reset.c | 1 + Acked-by: Thomas Bogendoerfer -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 1/3] arch: Export machine_restart() instances so they can be called from modules
On Thu, Aug 05, 2021 at 08:50:30AM +0100, Lee Jones wrote: > A recent attempt to convert the Power Reset Restart driver to tristate > failed because of the following compile error (reported once merged by > Stephen Rothwell via Linux Next): > > ERROR: "machine_restart" [drivers/power/reset/restart-poweroff.ko] > undefined! > > This error occurs since some of the machine_restart() instances are > not currently exported for use in modules. This patch aims to rectify > that. > > Cc: Vineet Gupta > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Guo Ren > Cc: Yoshinori Sato > Cc: Brian Cain > Cc: Geert Uytterhoeven > Cc: Michal Simek > Cc: Thomas Bogendoerfer > Cc: John Crispin > Cc: Ley Foon Tan > Cc: Jonas Bonn > Cc: Stefan Kristiansson > Cc: Stafford Horne > Cc: James E.J. Bottomley > Cc: Helge Deller > Cc: Michael Ellerman > Cc: Paul Walmsley > Cc: Palmer Dabbelt > Cc: Albert Ou > Cc: Heiko Carstens > Cc: Vasily Gorbik > Cc: Christian Borntraeger > Cc: Rich Felker > Cc: David S. Miller > Cc: Jeff Dike > Cc: Richard Weinberger > Cc: Anton Ivanov > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: Chris Zankel > Cc: Max Filippov > Cc: Greg Kroah-Hartman > Cc: Sebastian Reichel > Cc: linux-snps-...@lists.infradead.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-c...@vger.kernel.org > Cc: uclinux-h8-de...@lists.sourceforge.jp > Cc: linux-hexa...@vger.kernel.org > Cc: linux-m...@lists.linux-m68k.org > Cc: linux-m...@vger.kernel.org > Cc: openr...@lists.librecores.org > Cc: linux-par...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-ri...@lists.infradead.org > Cc: linux-s...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: sparcli...@vger.kernel.org > Cc: linux...@lists.infradead.org > Cc: linux-xte...@linux-xtensa.org > Signed-off-by: Lee Jones > --- > > The 2 patches this change supports have the required Acks already. > > NB: If it's safe to omit some of these, let me know and I'll revise the patch. > > [...] > arch/mips/kernel/reset.c | 1 + > arch/mips/lantiq/falcon/reset.c| 1 + > arch/mips/sgi-ip27/ip27-reset.c| 1 + Acked-by: Thomas Bogendoerfer -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2] arch: vdso: remove if-conditionals of $(c-gettimeofday-y)
On Sat, Jul 31, 2021 at 03:00:20PM +0900, Masahiro Yamada wrote: > arm, arm64, csky, mips, powerpc always select GENERIC_GETTIMEOFDAY, > hence $(gettimeofday-y) never becomes empty. > > riscv conditionally selects GENERIC_GETTIMEOFDAY when MMU=y && 64BIT=y, > but arch/riscv/kernel/vdso/vgettimeofday.o is built only under that > condition. So, you can always define CFLAGS_vgettimeofday.o > > Remove all the meaningless conditionals. > > Signed-off-by: Masahiro Yamada > --- > > Changes in v2: > - Fix csky as well > > [..] > arch/mips/vdso/Makefile | 2 -- Acked-by: Thomas Bogendoerfer -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: Build regressions/improvements in v5.16-rc1
On Mon, Nov 15, 2021 at 05:12:50PM +0100, Geert Uytterhoeven wrote: > > + error: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko] > > undefined!: => N/A > > + error: modpost: "mips_cm_lock_other" > > [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A > > + error: modpost: "mips_cm_unlock_other" > > [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A > > + error: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko] > > undefined!: => N/A > > + error: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko] > > undefined!: => N/A > > mips-allmodconfig there is a patchset fixing this https://lore.kernel.org/all/2025070809.15529-1-sergio.paracuel...@gmail.com/ > > 3 warning regressions: > > + : warning: #warning syscall futex_waitv not implemented [-Wcpp]: > > => 1559:2 > > powerpc, m68k, mips, s390, parisc (and probably more) I've queued a patch to fix this for mips. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [patch 09/22] MIPS: Octeon: Use arch_setup_msi_irq()
On Sat, Nov 27, 2021 at 02:18:48AM +0100, Thomas Gleixner wrote:
> The core code provides the same loop code except for the MSI-X reject. Move
> that to arch_setup_msi_irq() and remove the duplicated code.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner
> Cc: Thomas Bogendoerfer
> Cc: linux-m...@vger.kernel.org
> ---
> arch/mips/pci/msi-octeon.c | 32 +++-
> 1 file changed, 3 insertions(+), 29 deletions(-)
>
> --- a/arch/mips/pci/msi-octeon.c
> +++ b/arch/mips/pci/msi-octeon.c
> @@ -68,6 +68,9 @@ int arch_setup_msi_irq(struct pci_dev *d
> u64 search_mask;
> int index;
>
> + if (desc->pci.msi_attrib.is_msix)
> + return -EINVAL;
> +
> /*
>* Read the MSI config to figure out how many IRQs this device
>* wants. Most devices only want 1, which will give
> @@ -182,35 +185,6 @@ int arch_setup_msi_irq(struct pci_dev *d
> return 0;
> }
>
> -int arch_setup_msi_irqs(struct pci_dev *dev, int nvec, int type)
> -{
> - struct msi_desc *entry;
> - int ret;
> -
> - /*
> - * MSI-X is not supported.
> - */
> - if (type == PCI_CAP_ID_MSIX)
> - return -EINVAL;
> -
> - /*
> - * If an architecture wants to support multiple MSI, it needs to
> - * override arch_setup_msi_irqs()
> - */
> - if (type == PCI_CAP_ID_MSI && nvec > 1)
> - return 1;
> -
> - for_each_pci_msi_entry(entry, dev) {
> - ret = arch_setup_msi_irq(dev, entry);
> - if (ret < 0)
> - return ret;
> - if (ret > 0)
> - return -ENOSPC;
> - }
> -
> - return 0;
> -}
> -
> /**
> * Called when a device no longer needs its MSI interrupts. All
> * MSI interrupts for the device are freed.
Acked-by: Thomas Bogendoerfer
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2 0/6] Cleanup after removal of configs
On Thu, Dec 16, 2021 at 10:44:20AM +0100, Alexandre Ghiti wrote: > While bumping from 5.13 to 5.15, I found that a few deleted configs had > left some pieces here and there: this patchset cleans that. > > Changes in v2: > - Rebase on top of v5.16-rc1 > - Removed patch 6 since Matti said he would take care of that > - Added AB, RB > > Alexandre Ghiti (6): > Documentation, arch: Remove leftovers from fscache/cachefiles > histograms > Documentation, arch: Remove leftovers from raw device > Documentation, arch: Remove leftovers from CIFS_WEAK_PW_HASH > arch: Remove leftovers from mandatory file locking > Documentation, arch, fs: Remove leftovers from fscache object list > arch: Remove leftovers from prism54 wireless driver > > Documentation/admin-guide/cifs/usage.rst | 7 +- > Documentation/admin-guide/devices.txt | 8 +- > .../filesystems/caching/cachefiles.rst| 34 - > Documentation/filesystems/caching/fscache.rst | 123 +- > arch/arm/configs/axm55xx_defconfig| 3 - > arch/arm/configs/cm_x300_defconfig| 1 - > arch/arm/configs/ezx_defconfig| 1 - > arch/arm/configs/imote2_defconfig | 1 - > arch/arm/configs/nhk8815_defconfig| 1 - > arch/arm/configs/pxa_defconfig| 1 - > arch/arm/configs/spear13xx_defconfig | 1 - > arch/arm/configs/spear3xx_defconfig | 1 - > arch/arm/configs/spear6xx_defconfig | 1 - > arch/mips/configs/decstation_64_defconfig | 1 - > arch/mips/configs/decstation_defconfig| 1 - > arch/mips/configs/decstation_r4k_defconfig| 1 - > arch/mips/configs/fuloong2e_defconfig | 1 - > arch/mips/configs/ip27_defconfig | 1 - > arch/mips/configs/malta_defconfig | 1 - > arch/mips/configs/malta_kvm_defconfig | 1 - > arch/mips/configs/malta_qemu_32r6_defconfig | 1 - > arch/mips/configs/maltaaprp_defconfig | 1 - > arch/mips/configs/maltasmvp_defconfig | 1 - > arch/mips/configs/maltasmvp_eva_defconfig | 1 - > arch/mips/configs/maltaup_defconfig | 1 - > arch/mips/configs/maltaup_xpa_defconfig | 1 - > arch/powerpc/configs/pmac32_defconfig | 1 - > arch/powerpc/configs/ppc6xx_defconfig | 1 - > arch/powerpc/configs/pseries_defconfig| 1 - > arch/sh/configs/titan_defconfig | 1 - > fs/fscache/object.c | 3 - > fs/fscache/proc.c | 12 -- > 32 files changed, 6 insertions(+), 209 deletions(-) for the MIPS parts: Acked-by: Thomas Bogendoerfer -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2 4/4] bus: Make remove callback return void
On Tue, Jul 06, 2021 at 05:48:03PM +0200, Uwe Kleine-König wrote: > The driver core ignores the return value of this callback because there > is only little it can do when a device disappears. > > This is the final bit of a long lasting cleanup quest where several > buses were converted to also return void from their remove callback. > Additionally some resource leaks were fixed that were caused by drivers > returning an error code in the expectation that the driver won't go > away. > > With struct bus_type::remove returning void it's prevented that newly > implemented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > Acked-by: Russell King (Oracle) (For ARM, Amba > and related parts) > Acked-by: Mark Brown > Acked-by: Chen-Yu Tsai (for drivers/bus/sunxi-rsb.c) > Acked-by: Pali Rohár > Acked-by: Mauro Carvalho Chehab (for drivers/media) > Acked-by: Hans de Goede (For drivers/platform) > Acked-by: Alexandre Belloni > Acked-By: Vinod Koul > Acked-by: Juergen Gross (For Xen) > Acked-by: Lee Jones (For drivers/mfd) > Acked-by: Johannes Thumshirn (For drivers/mcb) > Acked-by: Johan Hovold > Acked-by: Srinivas Kandagatla (For > drivers/slimbus) > Acked-by: Kirti Wankhede (For drivers/vfio) > Acked-by: Maximilian Luz > Acked-by: Heikki Krogerus (For ulpi and > typec) > Acked-by: Samuel Iglesias Gonsálvez (For ipack) > Reviewed-by: Tom Rix (For fpga) > Acked-by: Geoff Levand (For ps3) > Signed-off-by: Uwe Kleine-König > --- > [...] > arch/mips/sgi-ip22/ip22-gio.c | 3 +-- Acked-by: Thomas Bogendoerfer -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2 09/18] mips: use simpler access_ok()
On Wed, Feb 16, 2022 at 02:13:23PM +0100, Arnd Bergmann wrote:
>
> diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h
> index db9a8e002b62..d7c89dc3426c 100644
> --- a/arch/mips/include/asm/uaccess.h
> +++ b/arch/mips/include/asm/uaccess.h
> @@ -19,6 +19,7 @@
> #ifdef CONFIG_32BIT
>
> #define __UA_LIMIT 0x8000UL
> +#define TASK_SIZE_MAX__UA_LIMIT
>
> #define __UA_ADDR".word"
> #define __UA_LA "la"
> @@ -33,6 +34,7 @@
> extern u64 __ua_limit;
>
> #define __UA_LIMIT __ua_limit
> +#define TASK_SIZE_MAXXKSSEG
this doesn't work. For every access above maximum implemented virtual address
space of the CPU an address error will be issued, but not a TLB miss.
And address error isn't able to handle this situation.
With this patch
diff --git a/arch/mips/kernel/unaligned.c b/arch/mips/kernel/unaligned.c
index df4b708c04a9..3911f1481f3d 100644
--- a/arch/mips/kernel/unaligned.c
+++ b/arch/mips/kernel/unaligned.c
@@ -1480,6 +1480,13 @@ asmlinkage void do_ade(struct pt_regs *regs)
prev_state = exception_enter();
perf_sw_event(PERF_COUNT_SW_ALIGNMENT_FAULTS,
1, regs, regs->cp0_badvaddr);
+
+ /* Are we prepared to handle this kernel fault? */
+ if (fixup_exception(regs)) {
+ current->thread.cp0_baduaddr = regs->cp0_badvaddr;
+ return;
+ }
+
/*
* Did we catch a fault trying to load an instruction?
*/
I at least get my simple test cases fixed, but I'm not sure this is
correct.
Is there a reason to not also #define TASK_SIZE_MAX __UA_LIMIT like
for the 32bit case ?
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2 09/18] mips: use simpler access_ok()
On Mon, Feb 21, 2022 at 03:31:23PM +0100, Arnd Bergmann wrote: > On Mon, Feb 21, 2022 at 2:24 PM Thomas Bogendoerfer > wrote: > > On Wed, Feb 16, 2022 at 02:13:23PM +0100, Arnd Bergmann wrote: > > > > > > diff --git a/arch/mips/include/asm/uaccess.h > > > b/arch/mips/include/asm/uaccess.h > > > index db9a8e002b62..d7c89dc3426c 100644 > > > > this doesn't work. For every access above maximum implemented virtual > > address > > space of the CPU an address error will be issued, but not a TLB miss. > > And address error isn't able to handle this situation. > > Ah, so the __ex_table entry only catches TLB misses? no, but there is no __ex_table handling in address error hanlder (yet). > Does this mean it also traps for kernel memory accesses, or do those > work again? it will trap for every access. > If the addresses on mips64 are separate like on > sparc64 or s390, the entire access_ok() step could be replaced > by a fixup code in the exception handler. I suppose this depends on > CONFIG_EVA and you still need a limit check at least when EVA is > disabled. only EVA has seperate address spaces for kernel/user. > > Is there a reason to not also #define TASK_SIZE_MAX __UA_LIMIT like > > for the 32bit case ? > > > > For 32-bit, the __UA_LIMIT is a compile-time constant, so the check > ends up being trivial. On all other architectures, the same thing can > be done after the set_fs removal, so I was hoping it would work here > as well. ic > I suspect doing the generic (size <= limit) && (addr <= (limit - size)) > check on mips64 with the runtime limit ends up slightly slower > than the current code that checks a bit mask instead. If you like, > I'll update it this way, otherwise I'd need help in form of a patch > that changes the exception handling so __get_user/__put_user > also return -EFAULT for an address error. that's what the patch does. For aligned accesses the patch should do the right thing, but it breaks unaligned get_user/put_user. Checking if the trapping vaddr is between end of CPU VM space and TASK_MAX_SIZE before exception handling should do the trick. I'll send a patch, if this works. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2 09/18] mips: use simpler access_ok()
On Wed, Feb 16, 2022 at 02:13:23PM +0100, Arnd Bergmann wrote: > diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h > index db9a8e002b62..d7c89dc3426c 100644 > --- a/arch/mips/include/asm/uaccess.h > +++ b/arch/mips/include/asm/uaccess.h > @@ -19,6 +19,7 @@ > #ifdef CONFIG_32BIT > > #define __UA_LIMIT 0x8000UL > +#define TASK_SIZE_MAX__UA_LIMIT using KSEG0 instead would IMHO be the better choice. This gives the chance to remove __UA_LIMIT completly after cleaning up ptrace.c Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2 09/18] mips: use simpler access_ok()
On Mon, Feb 21, 2022 at 03:31:23PM +0100, Arnd Bergmann wrote: > I'll update it this way, otherwise I'd need help in form of a patch > that changes the exception handling so __get_user/__put_user > also return -EFAULT for an address error. https://lore.kernel.org/all/20220222155345.138861-1-tsbog...@alpha.franken.de/ That does the trick. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 06/12] MIPS/octeon: use swiotlb_init instead of open coding it
On Tue, Mar 01, 2022 at 12:53:05PM +0200, Christoph Hellwig wrote: > Use the generic swiotlb initialization helper instead of open coding it. > > Signed-off-by: Christoph Hellwig > --- > arch/mips/cavium-octeon/dma-octeon.c | 15 ++- > arch/mips/pci/pci-octeon.c | 2 +- > 2 files changed, 3 insertions(+), 14 deletions(-) Acked-by: Thomas Bogendoerfer -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: Build regressions/improvements in v5.17-rc1
On Mon, Jan 24, 2022 at 08:55:40AM +0100, Geert Uytterhoeven wrote: > > + /kisskb/src/lib/test_printf.c: error: "PTR" redefined [-Werror]: => > > 247:0, 247 > > + /kisskb/src/sound/pci/ca0106/ca0106.h: error: "PTR" redefined [-Werror]: > > => 62, 62:0 > > mips-gcc8/mips-allmodconfig > mipsel/mips-allmodconfig fixing patch sent. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v5 3/4] arch/*/io.h: remove ioremap_uc in some architectures
On Thu, Sep 21, 2023 at 07:04:23PM +0800, Baoquan He wrote: > ioremap_uc() is only meaningful on old x86-32 systems with the PAT > extension, and on ia64 with its slightly unconventional ioremap() > behavior. So remove the ioremap_uc() definition in architecutures > other than x86 and ia64. These architectures all have asm-generic/io.h > included and will have the default ioremap_uc() definition which > returns NULL. > > This changes the existing behaviour, while no need to worry about > any breakage because in the only callsite of ioremap_uc(), code > has been adjusted to eliminate the impact. Please see > atyfb_setup_generic() of drivers/video/fbdev/aty/atyfb_base.c. > > If any new invocation of ioremap_uc() need be added, please consider > using ioremap() intead or adding a ARCH specific version if necessary. > > Signed-off-by: Baoquan He > Acked-by: Geert Uytterhoeven > Acked-by: Michael Ellerman (powerpc) > Acked-by: Helge Deller # parisc > Cc: linux-al...@vger.kernel.org > Cc: linux-hexa...@vger.kernel.org > Cc: linux-m...@lists.linux-m68k.org > Cc: linux-m...@vger.kernel.org > Cc: linux-par...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux...@vger.kernel.org > Cc: sparcli...@vger.kernel.org > --- > Documentation/driver-api/device-io.rst | 9 + > arch/alpha/include/asm/io.h| 1 - > arch/hexagon/include/asm/io.h | 3 --- > arch/m68k/include/asm/kmap.h | 1 - > arch/mips/include/asm/io.h | 1 - Acked-by: Thomas Bogendoerfer -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v3 3/4] arch/mips/configs/*_defconfig cleanup
On Thu, Aug 17, 2023 at 07:50:13AM -0400, Trevor Woerner wrote:
> Drop CONFIG_IP_NF_TARGET_CLUSTERIP from any remaining mips defconfigs as it
> was removed in commit 9db5d918e2c0 ("netfilter: ip_tables: remove clusterip
> target").
>
> Signed-off-by: Trevor Woerner
> ---
> arch/mips/configs/ip22_defconfig| 1 -
> arch/mips/configs/malta_defconfig | 1 -
> arch/mips/configs/malta_kvm_defconfig | 1 -
> arch/mips/configs/maltaup_xpa_defconfig | 1 -
> arch/mips/configs/rm200_defconfig | 1 -
> 5 files changed, 5 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH 07/30] mips: ip22: Reword PANICED to PANICKED and remove useless header
On Wed, Apr 27, 2022 at 07:49:01PM -0300, Guilherme G. Piccoli wrote: > Many other place in the kernel prefer the latter, so let's keep > it consistent in MIPS code as well. Also, removes a useless header. > > Cc: Thomas Bogendoerfer > Signed-off-by: Guilherme G. Piccoli > --- > arch/mips/sgi-ip22/ip22-reset.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 10/11] MIPS: mscc: jaguar2: Fix pca9545 i2c-mux node names
On Fri, Dec 02, 2022 at 05:49:25PM +0100, Geert Uytterhoeven wrote:
> "make dtbs_check":
>
> arch/mips/boot/dts/mscc/jaguar2_pcb110.dtb: pca9545@70: $nodename:0:
> 'pca9545@70' does not match '^(i2c-?)?mux'
> From schema:
> Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
> arch/mips/boot/dts/mscc/jaguar2_pcb110.dtb: pca9545@70: Unevaluated
> properties are not allowed ('#address-cells', '#size-cells', 'i2c@0',
> 'i2c@1', 'i2c@2', 'i2c@3' were unexpected)
> From schema:
> Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
> ...
>
> Fix this by renaming PCA9545 nodes to "i2c-mux", to match the I2C bus
> multiplexer/switch DT bindings and the Generic Names Recommendation in
> the Devicetree Specification.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> arch/mips/boot/dts/mscc/jaguar2_pcb110.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH 4/5] mips: dts: remove label = "cpu" from DSA dt-binding
On Wed, Nov 30, 2022 at 05:10:39PM +0300, Arınç ÜNAL wrote:
> This is not used by the DSA dt-binding, so remove it from all devicetrees.
>
> Signed-off-by: Arınç ÜNAL
> ---
> arch/mips/boot/dts/qca/ar9331.dtsi| 1 -
> arch/mips/boot/dts/ralink/mt7621.dtsi | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/arch/mips/boot/dts/qca/ar9331.dtsi
> b/arch/mips/boot/dts/qca/ar9331.dtsi
> index c4102b280b47..768ac0f869b1 100644
> --- a/arch/mips/boot/dts/qca/ar9331.dtsi
> +++ b/arch/mips/boot/dts/qca/ar9331.dtsi
> @@ -176,7 +176,6 @@ ports {
>
> switch_port0: port@0 {
> reg = <0x0>;
> - label = "cpu";
> ethernet = <>;
>
> phy-mode = "gmii";
> diff --git a/arch/mips/boot/dts/ralink/mt7621.dtsi
> b/arch/mips/boot/dts/ralink/mt7621.dtsi
> index f3f4c1f26e01..445817cbf376 100644
> --- a/arch/mips/boot/dts/ralink/mt7621.dtsi
> +++ b/arch/mips/boot/dts/ralink/mt7621.dtsi
> @@ -386,7 +386,6 @@ port@4 {
>
> port@6 {
> reg = <6>;
> - label = "cpu";
> ethernet = <>;
> phy-mode = "trgmii";
>
> --
> 2.34.1
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH v4 3/4] arch/*/io.h: remove ioremap_uc in some architectures
On Wed, Mar 08, 2023 at 09:07:09PM +0800, Baoquan He wrote: > ioremap_uc() is only meaningful on old x86-32 systems with the PAT > extension, and on ia64 with its slightly unconventional ioremap() > behavior. So remove the ioremap_uc() definition in architecutures > other than x86 and ia64. These architectures all have asm-generic/io.h > included and will have the default ioremap_uc() definition which > returns NULL. > > This changes the existing behaviour, while no need to worry about > any breakage because in the only callsite of ioremap_uc(), code > has been adjusted to eliminate the impact. Please see > atyfb_setup_generic() of drivers/video/fbdev/aty/atyfb_base.c. > > If any new invocation of ioremap_uc() need be added, please consider > using ioremap() intead or adding a ARCH specific version if necessary. > > Acked-by: Geert Uytterhoeven > Signed-off-by: Baoquan He > Cc: linux-al...@vger.kernel.org > Cc: linux-hexa...@vger.kernel.org > Cc: linux-m...@lists.linux-m68k.org > Cc: linux-m...@vger.kernel.org > Cc: linux-par...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux...@vger.kernel.org > Cc: sparcli...@vger.kernel.org > --- > Documentation/driver-api/device-io.rst | 9 + > arch/alpha/include/asm/io.h| 1 - > arch/hexagon/include/asm/io.h | 3 --- > arch/m68k/include/asm/kmap.h | 1 - > arch/mips/include/asm/io.h | 1 - > arch/parisc/include/asm/io.h | 2 -- > arch/powerpc/include/asm/io.h | 1 - > arch/sh/include/asm/io.h | 2 -- > arch/sparc/include/asm/io_64.h | 1 - > 9 files changed, 5 insertions(+), 16 deletions(-) this doesn't apply to v6.3-rc1... what tree is this based on ? Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v3 0/4] Use dma_default_coherent for devicetree default coherency
On Tue, Mar 28, 2023 at 03:18:12AM +0200, Christoph Hellwig wrote: > On Fri, Mar 24, 2023 at 09:17:38AM +, Jiaxun Yang wrote: > > > > > > Is patch a 6.3 candidate or should all of it go into 6.4? > > > > Please leave it for 6.4, as corresponding MIPS arch part will be a part of > > 6.4. > > Ok. I'll really need review from the MIPS and drivers/of/ maintainers, > through. I don't see any MIPS changes in the series besides the ifdef CONFIG_MIPS part in patch 1, which gets removed again in patch 4 (chance to drop that completely ?). I've merged the corresponding MIPS patches into mips-next last week. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH 2/4] vgacon: rework screen_info #ifdef checks
On Fri, Jul 07, 2023 at 11:52:24AM +0200, Arnd Bergmann wrote:
> diff --git a/arch/mips/jazz/setup.c b/arch/mips/jazz/setup.c
> index ee044261eb223..3c14548353e47 100644
> --- a/arch/mips/jazz/setup.c
> +++ b/arch/mips/jazz/setup.c
> @@ -76,7 +76,7 @@ void __init plat_mem_setup(void)
>
> _machine_restart = jazz_machine_restart;
>
> -#ifdef CONFIG_VT
> +#ifdef CONFIG_VGA_CONSOLE
> screen_info = (struct screen_info) {
> .orig_video_cols= 160,
> .orig_video_lines = 64,
that wssn't intended for VGA but for fbdev/g364fb, which doesn't use
it. So removing it is probably the best thing.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH v2 08/13] mips/kexec: refactor for kernel/Kconfig.kexec
On Mon, Jun 19, 2023 at 10:57:56AM -0400, Eric DeVolder wrote: > The kexec and crash kernel options are provided in the common > kernel/Kconfig.kexec. Utilize the common options and provide > the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the > equivalent set of KEXEC and CRASH options. > > Signed-off-by: Eric DeVolder > --- > arch/mips/Kconfig | 32 +--- > 1 file changed, 5 insertions(+), 27 deletions(-) Acked-by: Thomas Bogendoerfer -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
