Re: [PATCH net-next 1/7] ethernet: Remove the Sun Cassini driver
On Sat, Jan 7, 2023 at 1:00 AM Anirudh Venkataramanan wrote: > > In a recent patch series that touched this driver [1], it was suggested > that this driver should be removed completely. git logs suggest that > there hasn't been any significant feature addition, improvement or fixes to > user-visible bugs in a while. A web search didn't indicate any recent > discussions or any evidence that there are users out there who care about > this driver. Thus, remove this driver. > > Notes: > > checkpatch complains "WARNING: added, moved or deleted file(s), does > MAINTAINERS need updating?". The files being removed don't have their > own entries in the MAINTAINERS file, so there's nothing to remove. > > checkpatch also complains about the long lore link below. > > [1] > https://lore.kernel.org/netdev/99629223-ac1b-0f82-50b8-ea307b3b0...@intel.com/T/#t > > Suggested-by: Leon Romanovsky > Signed-off-by: Anirudh Venkataramanan Do we drop/delete a working functionality by only taking in account git activity ? What is a proper way to decline patch series (vs Acked-by) ? Thanks.
Re: [PATCH net-next 7/7] sparc: configs: Remove references to CONFIG_SUNVNET and CONFIG_LDMVSW
On Sat, Jan 7, 2023 at 1:00 AM Anirudh Venkataramanan wrote: > > An earlier patch removed the Sun LDOM vswitch and sunvnet drivers. Remove > references to CONFIG_SUNVNET and CONFIG_LDMVSW from the sparc64 defconfig. > > Cc: Leon Romanovsky > Signed-off-by: Anirudh Venkataramanan > --- > arch/sparc/configs/sparc64_defconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/sparc/configs/sparc64_defconfig > b/arch/sparc/configs/sparc64_defconfig > index 1809909..a2c76e8 100644 > --- a/arch/sparc/configs/sparc64_defconfig > +++ b/arch/sparc/configs/sparc64_defconfig > @@ -95,8 +95,6 @@ CONFIG_MII=m > CONFIG_SUNLANCE=m > CONFIG_HAPPYMEAL=y > CONFIG_SUNGEM=m > -CONFIG_SUNVNET=m > -CONFIG_LDMVSW=m > CONFIG_NET_PCI=y > CONFIG_E1000=m > CONFIG_E1000E=m I wonder what is the reason for removing the perfectly working sunvnet driver which is used in LDOMs under sun hardware hypervisor? Can we please not remove drivers which are actually used? Or either drop sparc32/sparc64 (whole arch) from linux kernel as well. Thanks.
Re: [PATCH 07/11] x86: remove the IOMMU table infrastructure
On Sun, Feb 27, 2022 at 7:31 PM Christoph Hellwig wrote: > > The IOMMU table tries to separate the different IOMMUs into different > backends, but actually requires various cross calls. > > Rewrite the code to do the generic swiotlb/swiotlb-xen setup directly > in pci-dma.c and then just call into the IOMMU drivers. ... > --- a/arch/x86/include/asm/iommu_table.h > +++ /dev/null > @@ -1,102 +0,0 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > -#ifndef _ASM_X86_IOMMU_TABLE_H > -#define _ASM_X86_IOMMU_TABLE_H > - > -#include > - > -/* > - * History lesson: > - * The execution chain of IOMMUs in 2.6.36 looks as so: > - * > - *[xen-swiotlb] > - * | > - * +[swiotlb *]--+ > - */ | \ > - * / | \ > - *[GART] [Calgary] [Intel VT-d] > - * / > - */ > - * [AMD-Vi] > - * > - * *: if SWIOTLB detected 'iommu=soft'/'swiotlb=force' it would skip > - * over the rest of IOMMUs and unconditionally initialize the SWIOTLB. > - * Also it would surreptitiously initialize set the swiotlb=1 if there were > - * more than 4GB and if the user did not pass in 'iommu=off'. The swiotlb > - * flag would be turned off by all IOMMUs except the Calgary one. > - * > - * The IOMMU_INIT* macros allow a similar tree (or more complex if desired) > - * to be built by defining who we depend on. > - * > - * And all that needs to be done is to use one of the macros in the IOMMU > - * and the pci-dma.c will take care of the rest. > - */ Christoph, Is it possible to keep documentation comments in source files? Or are they completely irrelevant now? Thanks.
Re: [PATCH RFC v1] drivers/base/node: consolidate node device subsystem initialization in node_dev_init()
On Mon, Jan 31, 2022 at 2:11 PM David Hildenbrand wrote: > > ... and call node_dev_init() after memory_dev_init() from driver_init(), > so before any of the existing arch/subsys calls. All online nodes should > be known at that point. > > This is in line with memory_dev_init(), which initializes the memory > device subsystem and creates all memory block devices. > > Similar to memory_dev_init(), panic() if anything goes wrong, we don't > want to continue with such basic initialization errors. > > The important part is that node_dev_init() gets called after > memory_dev_init() and after cpu_dev_init(), but before any of the > relevant archs call register_cpu() to register the new cpu device under > the node device. The latter should be the case for the current users > of topology_init(). > > RFC because I tested only on x86-64 and s390x, I think I cross-compiled all > applicable architectures except riscv and sparc. Compiled and boot tested on sparc. Tested-by: Anatoly Pugachev (sparc64)
Re: [PATCH v2] mm: Move mem_init_print_info() into mm_init()
On Wed, Mar 17, 2021 at 4:51 AM Kefeng Wang wrote: > > mem_init_print_info() is called in mem_init() on each architecture, > and pass NULL argument, so using void argument and move it into mm_init(). > > Acked-by: Dave Hansen > Signed-off-by: Kefeng Wang > --- > v2: > - Cleanup 'str' line suggested by Christophe and ACK applied patch (5.12.0-rc3-00020-g1df27313f50a-dirty) over linus.git and tested boot on a sparc64 virtual machine (ldom) - boots.
Re: [PATCH v2] vio: make remove callback return void
On Wed, Feb 24, 2021 at 11:17 AM Uwe Kleine-König wrote: > > The driver core ignores the return value of struct bus_type::remove() > because there is only little that can be done. To simplify the quest to > make this function return void, let struct vio_driver::remove() return > void, too. All users already unconditionally return 0, this commit makes > it obvious that returning an error code is a bad idea and makes it > obvious for future driver authors that returning an error code isn't > intended. > > Note there are two nominally different implementations for a vio bus: > one in arch/sparc/kernel/vio.c and the other in > arch/powerpc/platforms/pseries/vio.c. I didn't care to check which > driver is using which of these busses (or if even some of them can be > used with both) and simply adapt all drivers and the two bus codes in > one go. Applied over current git kernel, boots on my sparc64 LDOM (sunvdc block driver which uses vio). Linux ttip 5.11.0-10201-gc03c21ba6f4e-dirty #189 SMP Wed Feb 24 13:48:37 MSK 2021 sparc64 GNU/Linux boot logs (and kernel config) on [1] for "5.11.0-10201-gc03c21ba6f4e-dirty". Up to you to add "tested-by". Thanks. 1. https://github.com/mator/sparc64-dmesg PS: going to check with ppc64 later as well on LPAR (uses vio).
Re: [PATCH v2 3/4] sparc64: remove mm_cpumask clearing to fix kthread_use_mm race
On Mon, Sep 14, 2020 at 10:00 AM Nicholas Piggin wrote: > > Excerpts from Nicholas Piggin's message of September 14, 2020 2:52 pm: > > [...] > > > The basic fix for sparc64 is to remove its mm_cpumask clearing code. The > > optimisation could be effectively restored by sending IPIs to mm_cpumask > > members and having them remove themselves from mm_cpumask. This is more > > tricky so I leave it as an exercise for someone with a sparc64 SMP. > > powerpc has a (currently similarly broken) example. > > So this compiles and boots on qemu, but qemu does not support any > sparc64 machines with SMP. Attempting some simple hacks doesn't get > me far because openbios isn't populating an SMP device tree, which > blows up everywhere. > > The patch is _relatively_ simple, hopefully it shouldn't explode, so > it's probably ready for testing on real SMP hardware, if someone has > a few cycles. Nick, applied this patch to over 'v5.9-rc5' tag , used my test VM (ldom) with 32 vcpus. Machine boot, stress-ng test ( run as "stress-ng --cpu 8 --io 8 --vm 8 --vm-bytes 2G --fork 8 --timeout 15m" ) finishes without errors.
unable to boot kernel on power6
Hello! Can someone from powerpc kernel guys look at https://bugzilla.redhat.com/show_bug.cgi?id=1093163 It can not load kernel on power6 JS22 (type 7998) blade, starting from 3.11 kernel (but 3.9.x actually bootable). Thanks. PS: not sure, is it worth investigating since it's power6 (old hardware). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
device tree, fedora 20 install
Hello! There's a regression somewhere in kernel, I'm unable to boot installation kernel version 3.11.10-301.fc20.ppc64 of fedora 20 on IBM JS22 (type 7998) blade. But my previous attempt with kernel 3.9.5-301.fc19.ppc64 was able to boot. I have the following output with 3.11.10-301.fc20.ppc64 kernel: Booting `Install Fedora 20 (64-bit kernel)' OF stdout device is: /vdevice/vty@3000 Preparing to boot Linux version 3.11.10-301.fc20.ppc64 (mockbu...@ppc-builder7.qa.fedoraproject.org) (gcc version 4.8.2 20131017 (Red Hat 4.8.2-1) (GCC) ) #1 SMP Tue Dec 10 00:35:15 MST 2013 Detected machine type: 0101 Max number of cores passed to firmware: 512 (NR_CPUS = 1024) Calling ibm,client-architecture- support... done command line: BOOT_IMAGE=/ppc/ppc64/vmlinuz ro memory layout at init: memory_limit : (16 MB aligned) alloc_bottom : 06e8 alloc_top: 0800 alloc_top_hi : 0800 rmo_top : 0800 ram_top : 0800 found display : /pci@8002202/display@1, opening... done instantiating rtas at 0x06eb... done Querying for OPAL presence... not there. boot cpu hw idx 0 starting cpu hw idx 2... done starting cpu hw idx 4... done starting cpu hw idx 6... done copying OF device tree... Building dt strings... Building dt structure... No memory for flatten_device_tree (no room) EXIT called ok 0 while with 3.9.5-301.fc19.ppc64 it pass DT stage: Welcome to the 64-bit Fedora 19 installer! Hit TAB for boot options. Welcome to yaboot version 1.3.17 (Red Hat 1.3.17-6.fc19) Enter help to get some basic usage information boot: linux Please wait, loading kernel... Elf64 kernel loaded... Loading ramdisk... ramdisk loaded at 0398, size: 9872 Kbytes OF stdout device is: /vdevice/vty@3000 Preparing to boot Linux version 3.9.5-301.fc19.ppc64 (mockbu...@ppc-builder3.qa.fedoraproject.org) (gcc version 4.8.1 20130603 (Red Hat 4.8.1-1) (GCC) ) #1 SMP Tue Jun 11 15:07:48 MST 2013 Detected machine type: 0101 Max number of cores passed to firmware: 512 (NR_CPUS = 1024) Calling ibm,client-architecture-support... done command line: ro memory layout at init: memory_limit : (16 MB aligned) alloc_bottom : 0433 alloc_top: 0800 alloc_top_hi : 0800 rmo_top : 0800 ram_top : 0800 found display : /pci@8002202/display@1, opening... done instantiating rtas at 0x06db... done Querying for OPAL presence... not there. boot cpu hw idx 0 starting cpu hw idx 2... done starting cpu hw idx 4... done starting cpu hw idx 6... done copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x0444 - 0x0444182e Device tree struct 0x0445 - 0x0447 Calling quiesce... returning from prom_init [0.00] Using pSeries machine description [0.00] Using 1TB segments [0.00] Found initrd at 0xc398:0xc4324000 [0.00] bootconsole [udbg0] enabled [0.00] Partition configured for 8 cpus. (and so on...) Can someone help me with this issue? Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
