- 21 Jul, 2022 1 commit
-
-
Celeste Liu authored
As mentioned in Table 4.5 in RISC-V spec Volume 2 Section 4.3, write but not read is "Reserved for future use.". For now, they are not valid. In the current code, -wx is marked as invalid, but -w- is not marked as invalid. This patch refines that judgment. Reported-by:
xctan <xc-tan@outlook.com> Co-developed-by:
dram <dramforever@live.com> Signed-off-by:
Ruizhe Pan <c141028@gmail.com> Signed-off-by:
Celeste Liu <coelacanthus@outlook.com> Link: https://lore.kernel.org/r/PH7PR14MB559464DBDD310E755F5B21E8CEDC9@PH7PR14MB5594.namprd14.prod.outlook.comSigned-off-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
- 20 Jul, 2022 1 commit
-
-
Palmer Dabbelt authored
The hartid can be a 64bit value on RV64 platforms. This series updates the code so that 64bit hartid can be supported on RV64 platforms. * 'riscv-64bit_hartid' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git: riscv/efi_stub: Add 64bit boot-hartid support on RV64 riscv: cpu: Add 64bit hartid support on RV64 riscv: smp: Add 64bit hartid support on RV64 riscv: spinwait: Fix hartid variable type riscv: cpu_ops_sbi: Add 64bit hartid support on RV64
-
- 19 Jul, 2022 5 commits
-
-
Sunil V L authored
The boot-hartid can be a 64bit value on RV64 platforms but the "boot-hartid" in DT is assumed to be 32bit only. Detect the size of the "boot-hartid" in DT and use 32bit or 64bit read appropriately. Signed-off-by:
Sunil V L <sunilvl@ventanamicro.com> Link: https://lore.kernel.org/r/20220527051743.2829940-6-sunilvl@ventanamicro.comSigned-off-by:
-
Sunil V L authored
The hartid can be a 64bit value on RV64 platforms. Add support for 64bit hartid in riscv_of_processor_hartid() and update its callers. Signed-off-by:
Atish Patra <atishp@rivosinc.com> Link: https://lore.kernel.org/r/20220527051743.2829940-5-sunilvl@ventanamicro.comSigned-off-by:
-
Sunil V L authored
The hartid can be a 64bit value on RV64 platforms. Modify the hartid parameter in riscv_hartid_to_cpuid() as unsigned long so that it can hold 64bit value on RV64 platforms. Signed-off-by:
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by:
-
Sunil V L authored
The hartid variable is of type int but compared with ULONG_MAX(INVALID_HARTID). This issue is fixed by changing the hartid variable type to unsigned long. Fixes: c78f94f3 ("RISC-V: Use __cpu_up_stack/task_pointer only for spinwait method") Signed-off-by:
-
Sunil V L authored
The hartid can be a 64bit value on RV64 platforms. Modify the hartid variable type to unsigned long so that it can hold 64bit value on RV64 platforms. Signed-off-by:
-
- 14 Jul, 2022 9 commits
-
-
Conor Dooley authored
After converting the pmic watchdog binding to yaml, dtbs_check complains that the node name doesn't match the binding. "Fix" it. Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20220606201343.514391-5-mail@conchuod.ieSigned-off-by:
-
Palmer Dabbelt authored
Merge branch 'riscv-cpu_map_topo' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git into for-next RISC-V: Add cpu-map topology information nodes It was reported to me that the Hive Unmatched incorrectly reports its topology to hwloc, but the StarFive VisionFive did in [0] & a subsequent off-list email from Brice (the hwloc maintainer). This turned out not to be entirely true, the /downstream/ version of the VisionFive does work correctly but not upstream, as the downstream devicetree has a cpu-map node that was added recently. This series adds a cpu-map node to all upstream devicetrees, which I have tested on mpfs & fu540. The first patch is lifted directly from the downstream StarFive devicetree. 0: https://github.com/open-mpi/hwloc/issues/536 Link: https://lore.kernel.org/linux-riscv/20220705190435.1790466-1-mail@conchuod.ie/ [Palmer: except the Microchip DT, that went in via the previous PR.] * 'riscv-cpu_map_topo' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git: riscv: dts: canaan: Add k210 topology information riscv: dts: sifive: Add fu740 topology information riscv: dts: sifive: Add fu540 topology information riscv: dts: starfive: Add JH7100 CPU topology
-
Palmer Dabbelt authored
Merge tag 'dt-for-palmer-v5.20-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git into for-next Microchip RISC-V devicetrees for 5.20 A pair of changes for mpfs.dtsi: - A pair of patches from Suresh & I, removing the bogus max frequency properties from the controller nodes for {q,}spi. This is a device only property with no meaning for a controller and should never have been there. - RISC-V has no sensible defaults for cpu topology, so I added a this information to the dt for MPFS as a cpu-map. This is an optional property and therefore is not a fix. * tag 'dt-for-palmer-v5.20-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git: riscv: dts: microchip: Add mpfs' topology information riscv: dts: microchip: remove spi-max-frequency property riscv: dts: microchip: remove spi-max-frequency property
-
Conor Dooley authored
The k210 has no cpu-map node, so tools like hwloc cannot correctly parse the topology. Add the node using the existing node labels. Reported-by:
Brice Goglin <Brice.Goglin@inria.fr> Link: https://github.com/open-mpi/hwloc/issues/536Signed-off-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com> Link: https://lore.kernel.org/r/20220705190435.1790466-6-mail@conchuod.ieSigned-off-by:
-
Conor Dooley authored
The fu740 has no cpu-map node, so tools like hwloc cannot correctly parse the topology. Add the node using the existing node labels. Reported-by:
-
Conor Dooley authored
The fu540 has no cpu-map node, so tools like hwloc cannot correctly parse the topology. Add the node using the existing node labels. Reported-by:
-
Jonas Hahnfeld authored
Add cpu-map binding to inform the kernel about the hardware topology of the CPU cores. Before this change, lstopo would report 1 core with 2 threads: Machine (7231MB total) Package L#0 NUMANode L#0 (P#0 7231MB) L2 L#0 (2048KB) + Core L#0 L1d L#0 (32KB) + L1i L#0 (32KB) + PU L#0 (P#0) L1d L#1 (32KB) + L1i L#1 (32KB) + PU L#1 (P#1) After this change, it correctly identifies two cores: Machine (7231MB total) Package L#0 NUMANode L#0 (P#0 7231MB) L2 L#0 (2048KB) L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0) L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1) Signed-off-by:Jonas Hahnfeld <hahnjo@hahnjo.de> Co-developed-by:
Emil Renner Berthing <kernel@esmil.dk> Signed-off-by:
-
Palmer Dabbelt authored
The RISC-V port has collected a handful of options that are fundamentally non-portable. To prevent users from shooting themselves in the foot, hide them all behind a config entry that explicitly calls out that non-portable binaries may be produced. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20220521193356.26562-1-palmer@rivosinc.comSigned-off-by:
-
Conor Dooley authored
SOC_STARFIVE is the odd one out among the (compatible) SOC_FOO options as it is not enabled in the default defconfig. Add it to make catching dt regressions etc easier. Signed-off-by:
-
- 07 Jul, 2022 1 commit
-
-
Conor Dooley authored
The mpfs has no cpu-map node, so tools like hwloc cannot correctly parse the topology. Add the node using the existing node labels. Reported-by:
Sudeep Holla <sudeep.holla@arm.com>
-
- 01 Jul, 2022 1 commit
-
-
Palmer Dabbelt authored
The majority of the Kconfig files use a single tab for basic indentation and a single tab followed by two whitespaces for help text indentation. Fix the lines that don't follow this convention. While at it, add trailing comments to endif/endmenu statements for better readability. * 'riscv-kconfig_cleanups' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/palmer/linux: riscv: Kconfig.socs: Add comments riscv: Kconfig.erratas: Add comments riscv: Kconfig: Fix indentation and add comments
-
- 30 Jun, 2022 3 commits
-
-
Juerg Haefliger authored
Add trailing comments to endif and endmenu statements for better readability. Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Link: https://lore.kernel.org/r/20220520120232.148310-4-juergh@canonical.comSigned-off-by:
-
Juerg Haefliger authored
Add trailing comments to endmenu statements for better readability. Signed-off-by:
-
Juerg Haefliger authored
The convention for indentation seems to be a single tab. Help text is further indented by an additional two whitespaces. Fix the lines that violate these rules. While add it, add trailing comments to endmenu statements for better readability. Signed-off-by:
-
- 22 Jun, 2022 1 commit
-
-
Maciej W. Rozycki authored
For RISC-V platforms we permit assigning addresses from 0 to PCI devices, both in the memory and the I/O bus space, and we happily do so if there is no conflict, e.g.: pci 0000:07:00.0: BAR 0: assigned [io 0x0000-0x0007] pci 0000:07:00.1: BAR 0: assigned [io 0x0008-0x000f] pci 0000:06:01.0: PCI bridge to [bus 07] pci 0000:06:01.0: bridge window [io 0x0000-0x0fff] (with the SiFive HiFive Unmatched RISC-V board and a dual serial port option card based on the OxSemi OXPCIe952 device wired for the legacy UART mode). Address 0 is treated specially however in many places, for example in `pci_iomap_range' and `pci_iomap_wc_range' we require that the start address is non-zero, and even if we let such an address through, then individual device drivers could reject a request to handle a device at such an address, such as in `uart_configure_port'. Consequently given devices configured as shown above only one is actually usable: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial 0000:07:00.0: enabling device (0000 -> 0001) serial: probe of 0000:07:00.0 failed with error -12 serial 0000:07:00.1: enabling device (0000 -> 0001) serial 0000:07:00.1: detected caps 00000700 should be 00000500 0000:07:00.1: ttyS0 at I/O 0x8 (irq = 39, base_baud = 15625000) is a 16C950/954 Therefore avoid handing out address 0, by bumping the lowest address available to PCI via PCIBIOS_MIN_IO and PCIBIOS_MIN_MEM up by 4 and 16 respectively, which is the minimum allocation size for I/O and memory BARs. With this in place the system in question we have: pci 0000:07:00.0: BAR 0: assigned [io 0x1000-0x1007] pci 0000:07:00.1: BAR 0: assigned [io 0x1008-0x100f] pci 0000:06:01.0: PCI bridge to [bus 07] pci 0000:06:01.0: bridge window [io 0x1000-0x1fff] and then devices work correctly: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled serial 0000:07:00.0: enabling device (0000 -> 0001) serial 0000:07:00.0: detected caps 00000700 should be 00000500 0000:07:00.0: ttyS0 at I/O 0x1000 (irq = 38, base_baud = 15625000) is a 16C950/954 serial 0000:07:00.1: enabling device (0000 -> 0001) serial 0000:07:00.1: detected caps 00000700 should be 00000500 0000:07:00.1: ttyS1 at I/O 0x1008 (irq = 39, base_baud = 15625000) is a 16C950/954 Especially I/O space ranges are particularly valuable, because bridges only decode bits from 12 up and consequently where 16-bit addressing is in effect, as few as 16 separate ranges can be assigned to individual buses only, however a generic change to avoid handing out address 0 only has turned out controversial as per the discussion referred via the link below. Conversely sorting this out in platform code has been standard practice since forever to avoid a clash with legacy devices subtractively decoded by the southbridge where present. This can be revised should a generic solution be adopted sometime. Signed-off-by:
Maciej W. Rozycki <macro@orcam.me.uk> Link: https://lore.kernel.org/r/alpine.DEB.2.21.2202260044180.25061@angie.orcam.me.ukSigned-off-by:
-
- 16 Jun, 2022 10 commits
-
-
Palmer Dabbelt authored
Some additionals comments and notes from autobuilders received after the series got applied, warranted some changes. * 'riscv-svpbmt' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/palmer/linux: riscv: remove usage of function-pointers from cpufeatures and t-head errata riscv: make patch-function pointer more generic in cpu_manufacturer_info struct riscv: Improve description for RISCV_ISA_SVPBMT Kconfig symbol riscv: drop cpufeature_apply_feature tracking variable riscv: fix dependency for t-head errata
-
Heiko Stuebner authored
Having a list of alternatives to check with a per-entry function pointer to a check function is nice style-wise. But in case of early-alternatives it can clash with the non-relocated kernel and the function pointer in the list pointing to a completely wrong location. This isn't an issue with one or two list entries, as in that case the compiler seems to unroll the loop and even usage of the list structure and then only does relative jumps into the check functions based on this. When adding a third entry to either list though, the issue that was hiding there from the beginning is triggered resulting a jump to a memory address that isn't part of the kernel at all. The list of features/erratas only contained an unused name and the pointer to the check function, so an easy solution for the problem is to just unroll the loop in code, dismantle the whole list structure and just call the relevant check functions one by one ourself. For the T-Head errata this includes moving the stage-check inside the check functions. The issue is only relevant for things that might be called for early- alternatives (T-Head and possible future main extensions), so the SiFive erratas were not affected from the beginning, as they got an early return for early-alternatives in the original patchset. Signed-off-by:
Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20220526205646.258337-6-heiko@sntech.deSigned-off-by:
-
Heiko Stuebner authored
During review the naming of the function-pointer was called confusing as the vendor id is just one of three inputs for the patching and indeed it serves no real purpose, as with recent changes the function pointer is not a static global element anymore, so drop the "vendor_" prefix. Suggested-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Heiko Stuebner authored
This improves the symbol's description to make it easier for people to understand what it is about. Suggested-by:
Philipp Tomsich <philipp.tomsich@vrull.eu> Signed-off-by:
-
Heiko Stuebner authored
The variable was tracking which feature patches got applied but that information was never actually used - and thus resulted in a warning as well. Drop the variable. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Heiko Stuebner authored
alternatives only work correctly on non-xip-kernels and while the selected alternative-symbol has the correct dependency the symbol selecting it also needs that dependency. So add the missing dependency to the T-Head errata Kconfig symbol. Reported-by:
kernel test robot <yujie.liu@intel.com> Reviewed-by:
-
Palmer Dabbelt authored
This pull the static key management code for the FPU into the generic ISA extension probing code, so it can be used by other extensions that need static keys. * 'riscv-static_key' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/palmer/linux: riscv: switch has_fpu() to the unified static key mechanism riscv: introduce unified static key mechanism for ISA extensions
-
Jisheng Zhang authored
This is to use the unified static key mechanism instead of putting static key related here and there. Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Reviewed-by:
Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20220522153543.2656-3-jszhang@kernel.orgSigned-off-by:
-
Jisheng Zhang authored
Currently, riscv has several extensions which may not be supported on all riscv platforms, for example, FPU and so on. To support unified kernel Image style, we need to check whether the feature is supported or not. If the check sits at hot code path, then performance will be impacted a lot. static key can be used to solve the issue. In the past, FPU support has been converted to use static key mechanism. I believe we will have similar cases in the future. This patch tries to add an unified mechanism to use static keys for some ISA extensions by implementing an array of default-false static keys and enabling them when detected. Signed-off-by:
-
Nagasuresh Relli authored
Remove the spi-max-frequency property from the spi0 controller node as it is supposed to be a per SPI peripheral device property. Reported-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/lkml/20220526014141.2872567-1-robh@kernel.org/Signed-off-by:
Nagasuresh Relli <nagasuresh.relli@microchip.com> Signed-off-by:
-
- 06 Jun, 2022 4 commits
-
-
Conor Dooley authored
spi-max-frequency property is supposed to be a per SPI peripheral device property, not a SPI controller property, so remove it. Reported-by:
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull file descriptor fix from Al Viro: "Fix for breakage in #work.fd this window" * tag 'pull-work.fd-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: fix the breakage in close_fd_get_file() calling conventions change
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull mm hotfixes from Andrew Morton: "Fixups for various recently-added and longer-term issues and a few minor tweaks: - fixes for material merged during this merge window - cc:stable fixes for more longstanding issues - minor mailmap and MAINTAINERS updates" * tag 'mm-hotfixes-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/oom_kill.c: fix vm_oom_kill_table[] ifdeffery x86/kexec: fix memory leak of elf header buffer mm/memremap: fix missing call to untrack_pfn() in pagemap_range() mm: page_isolation: use compound_nr() correctly in isolate_single_pageblock() mm: hugetlb_vmemmap: fix CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON MAINTAINERS: add maintainer information for z3fold mailmap: update Josh Poimboeuf's email
-
- 05 Jun, 2022 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mmLinus Torvalds authored
Pull delay-accounting update from Andrew Morton: "A single featurette for delay accounting. Delayed a bit because, unusually, it had dependencies on both the mm-stable and mm-nonmm-stable queues" * tag 'mm-nonmm-stable-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: delayacct: track delays from write-protect copy
-
Linus Torvalds authored
The bluetooth code uses our bitmap infrastructure for the two bits (!) of connection setup flags, and in the process causes odd problems when it converts between a bitmap and just the regular values of said bits. It's completely pointless to do things like bitmap_to_arr32() to convert a bitmap into a u32. It shoudln't have been a bitmap in the first place. The reason to use bitmaps is if you have arbitrary number of bits you want to manage (not two!), or if you rely on the atomicity guarantees of the bitmap setting and clearing. The code could use an "atomic_t" and use "atomic_or/andnot()" to set and clear the bit values, but considering that it then copies the bitmaps around with "bitmap_to_arr32()" and friends, there clearly cannot be a lot of atomicity requirements. So just use a regular integer. In the process, this avoids the warnings about erroneous use of bitmap_from_u64() which were triggered on 32-bit architectures when conversion from a u64 would access two words (and, surprise, surprise, only one word is needed - and indeed overkill - for a 2-bit bitmap). That was always problematic, but the compiler seems to notice it and warn about the invalid pattern only after commit 0a97953f ("lib: add bitmap_{from,to}_arr64") changed the exact implementation details of 'bitmap_from_u64()', as reported by Sudip Mukherjee and Stephen Rothwell. Fixes: fe92ee64 ("Bluetooth: hci_core: Rework hci_conn_params flags") Link: https://lore.kernel.org/all/YpyJ9qTNHJzz0FHY@debian/ Link: https://lore.kernel.org/all/20220606080631.0c3014f2@canb.auug.org.au/ Link: https://lore.kernel.org/all/20220605162537.1604762-1-yury.norov@gmail.com/Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Reviewed-by:
Yury Norov <yury.norov@gmail.com> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Al Viro authored
It used to grab an extra reference to struct file rather than just transferring to caller the one it had removed from descriptor table. New variant doesn't, and callers need to be adjusted. Reported-and-tested-by: syzbot+47dd250f527cb7bebf24@syzkaller.appspotmail.com Fixes: 6319194e ("Unify the primitives for file descriptor closing") Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 SGX fix from Thomas Gleixner: "A single fix for x86/SGX to prevent that memory which is allocated for an SGX enclave is accounted to the wrong memory control group" * tag 'x86-urgent-2022-06-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/sgx: Set active memcg prior to shmem allocation
-
