* [PATCH v2 1/5] arm64: dts: qcom: sc7280: Fix gmu unit address
From: Douglas Anderson @ 2022-01-25 22:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konrad.dybcio, swboyd, kgodara, mka, sibis, pmaliset,
quic_rjendra, Douglas Anderson, Akhil P Oommen, Andy Gross,
Rob Herring, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20220125224422.544381-1-dianders@chromium.org>
When processing sc7280 device trees, I can see:
Warning (simple_bus_reg): /soc@0/gmu@3d69000:
simple-bus unit address format error, expected "3d6a000"
There's a clear typo in the node name. Fix it.
Fixes: 96c471970b7b ("arm64: dts: qcom: sc7280: Add gpu support")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 937c2e0e93eb..eab7a8505053 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -1790,7 +1790,7 @@ opp-550000000 {
};
};
- gmu: gmu@3d69000 {
+ gmu: gmu@3d6a000 {
compatible="qcom,adreno-gmu-635.0", "qcom,adreno-gmu";
reg = <0 0x03d6a000 0 0x34000>,
<0 0x3de0000 0 0x10000>,
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 0/5] arm64: dts: qcom: sc7280: Introduce herobrine-rev1
From: Douglas Anderson @ 2022-01-25 22:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konrad.dybcio, swboyd, kgodara, mka, sibis, pmaliset,
quic_rjendra, Douglas Anderson, Akhil P Oommen, Andy Gross,
Rob Herring, devicetree, linux-arm-msm, linux-kernel
This series adds support for herobrine-rev1. Note that it's likely
that with the introduction of -rev1 we can drop -rev0 support, but
we'll keep it for now (though we won't try to "fit it in" and share
code with it).
This series is confirmed to boot herobrine-rev1 atop mainline, commit
0280e3c58f92 ("Merge tag 'nfs-for-5.17-1' of
git://git.linux-nfs.org/projects/anna/linux-nfs"), though it requires
a hack to work around a misconfigured DMA for i2c14
(https://crrev.com/c/3378660)
Changes in v2:
- memory-region syntax change as per Stephen.
- ("Factor gpio.h include to sc7280.dtsi") new for v2
- Herobrine compatible on one line, not two
- Wording change in comments for components enabled per-board
- Always sort "bias" above "drive-strength" in pinctrl.
- Properly sort "hub_en" pinctrl.
- Two comments moved from multiline to single line.
- Space after "/delete-property/"
Douglas Anderson (5):
arm64: dts: qcom: sc7280: Fix gmu unit address
arm64: dts: qcom: sc7280: Move herobrine-r0 to its own dts
arm64: dts: qcom: sc7280: Factor out Chrome common fragment
arm64: dts: qcom: sc7280: Factor gpio.h include to sc7280.dtsi
arm64: dts: qcom: sc7280: Add herobrine-r1
arch/arm64/boot/dts/qcom/Makefile | 3 +-
.../boot/dts/qcom/sc7280-chrome-common.dtsi | 97 ++
.../qcom/sc7280-herobrine-herobrine-r0.dts | 1350 +++++++++++++++++
.../qcom/sc7280-herobrine-herobrine-r1.dts | 313 ++++
arch/arm64/boot/dts/qcom/sc7280-herobrine.dts | 14 -
.../arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 1056 +++----------
arch/arm64/boot/dts/qcom/sc7280-idp.dtsi | 76 +-
arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi | 553 +++++++
arch/arm64/boot/dts/qcom/sc7280.dtsi | 3 +-
9 files changed, 2530 insertions(+), 935 deletions(-)
create mode 100644 arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
create mode 100644 arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
delete mode 100644 arch/arm64/boot/dts/qcom/sc7280-herobrine.dts
create mode 100644 arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
From: Andrew Lunn @ 2022-01-25 22:30 UTC (permalink / raw)
To: nick.hawkins
Cc: verdun, Rob Herring, Russell King, Krzysztof Kozlowski, Shawn Guo,
Stanislav Jakubek, Sam Ravnborg, Linus Walleij, Hao Fang,
Arnd Bergmann, Russell King (Oracle), Geert Uytterhoeven,
Mark Rutland, Ard Biesheuvel, Anshuman Khandual, Lukas Bulwahn,
Masahiro Yamada, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20220125194609.32314-1-nick.hawkins@hpe.com>
> + mdio0: mdio@c0004080 {
> + compatible = "hpe,gxp-umac-mdio";
> + reg = <0xc0004080 0x10>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ext_phy0: ethernt-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
c22 is the default, so you don't strictly need this.
> + phy-mode = "sgmii";
> + reg = <0>;
> + };
> + };
> +
> + mdio1: mdio@c0005080 {
> + compatible = "hpe,gxp-umac-mdio";
> + reg = <0xc0005080 0x10>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + int_phy0: ethernt-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "gmii";
> + reg = <0>;
> + };
> + int_phy1: ethernt-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + phy-mode = "gmii";
> + reg = <1>;
> + };
> + };
> +
> + umac0: umac@c0004000 {
> + compatible = "hpe, gxp-umac";
A space in a compatible?
> + reg = <0xc0004000 0x80>;
> + interrupts = <10>;
> + interrupt-parent = <&vic0>;
> + mac-address = [94 18 82 16 04 d8];
That is pretty unusual. Normally you leave the bootloader to fill this
in with a per board MAC address. The danger with listing it here is
that you have multiple boards in the same network using this MAC
address, and then bad things happen.
> + phy-handle = <&ext_phy0>;
> + int-phy-handle = <&int_phy0>;
Two phy-handles? Some very odd going on here!
> + xreg_kyes: xreg_keys {
> + compatible = "gpio-keys-polled";
> + poll-interval = <100>;
> +
> + IdButton {
> + label = "ID Button";
> + linux,code = <200>;
include/dt-bindings/input/linux-event-codes.h
However
#define KEY_PLAYCD 200
A BMC has a CD player? Maybe i have this wrong?
> + PortOwner@0 {
> + label = "Port Owner";
> + linux,code = <200>;
> + gpios = <&gpio 250 1>;
Two CD players?
> + };
> +
> + PortOwner@1 {
> + label = "Port Owner";
> + linux,code = <201>;
#define KEY_PAUSECD 201
And you can pause the second player?
Andrew
^ permalink raw reply
* Re: [RFC PATCH 0/2] Multicolor PWM LED support
From: Jacek Anaszewski @ 2022-01-25 22:31 UTC (permalink / raw)
To: sven, linux-leds, devicetree, linux-pwm
Cc: Sven Schwermer, pavel, dmurphy, robh+dt, thierry.reding,
u.kleine-koenig, lee.jones
In-Reply-To: <20220125092239.2006333-1-sven@svenschwermer.de>
Hi Sven,
On 1/25/22 10:22 AM, sven@svenschwermer.de wrote:
> From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
>
> Hi,
>
> As previously discussed [1] on the linux-leds list I am missing
> multicolor PWM LED support. In the mean time I have put together a
> working prototype for such a driver. This is my first Linux driver
> so I'm hoping for some feedback. Here are some questions that came up
> while putting this thing together:
>
> 1. Currently, the max-brightness property is expected as a property to
> the multi-led node. That seems consistent with the existing
> multicolor class code, but I'm wondering whether it would make
> sense to have a max-brigthness for the individual LEDs as well?
For the proper mixed color calculation all sub-leds should have
the same max_brightness as the global max_brightness.
Look at how sub-led intensities are calculated in
led_mc_calc_color_components().
See also [0] and [1].
> 2. The current multi-led node definition calls for a node index which
> would in turn require the reg property to be set within the node.
> In this context, that doesn't seem to make sense. Should this
> requirement be lifted from leds-class-multicolor.yaml?
reg is required for all DT nodes with address unit in the name.
If you skipped the address unit, then reg would be also not required.
> 3. I'm not currently reusing any leds-pwm code because there aren't
> too many overlaps. Does anyone have suggestions what could be
> factored out into a common source file?
I think that having a separate pwm driver for multicolor LEDs is a good
idea. leds-pwm.c is old and well tested driver, there's no need to
tinker at it for no vital reason. And there is not much code to share
as you've noticed.
> I would appreciate if anyone would test this code. It runs on my
> i.MX6ULL-based hardware.
>
> Best regards,
> Sven
>
> [1]: https://www.spinics.net/lists/linux-leds/msg19988.html
>
> Sven Schwermer (2):
> dt-bindings: leds: Add multicolor PWM LED bindings
> leds: Add PWM multicolor driver
>
> .../bindings/leds/leds-pwm-multicolor.yaml | 73 +++++++
> drivers/leds/Kconfig | 8 +
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-pwm-multicolor.c | 184 ++++++++++++++++++
> 4 files changed, 266 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml
> create mode 100644 drivers/leds/leds-pwm-multicolor.c
>
[0] Documentation/ABI/testing/sysfs-class-led-multicolor
[1] Documentation/leds/leds-class-multicolor.rst
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH RESEND v4 9/9] clk: cs2000-cp: convert driver to regmap
From: Stephen Boyd @ 2022-01-25 22:30 UTC (permalink / raw)
To: Daniel Mack, mturquette
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack
In-Reply-To: <20220125093336.226787-10-daniel@zonque.org>
Quoting Daniel Mack (2022-01-25 01:33:36)
> Regmap gives us caching, debugging infrastructure and other things for
> free and does away with open-coded bit-fiddling implementations.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH RESEND v4 8/9] clk: cs2000-cp: freeze config during register fiddling
From: Stephen Boyd @ 2022-01-25 22:30 UTC (permalink / raw)
To: Daniel Mack, mturquette
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack
In-Reply-To: <20220125093336.226787-9-daniel@zonque.org>
Quoting Daniel Mack (2022-01-25 01:33:35)
> Make sure to freeze the configuration of the chip during the programming
> of 32-bit registers. This avoids the processing of invalid intermediate
> states.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH RESEND v4 7/9] clk: cs2000-cp: make clock skip setting configurable
From: Stephen Boyd @ 2022-01-25 22:30 UTC (permalink / raw)
To: Daniel Mack, mturquette
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack
In-Reply-To: <20220125093336.226787-8-daniel@zonque.org>
Quoting Daniel Mack (2022-01-25 01:33:34)
> The clock skip function of this chip is not necessarily desirable in
> all hardware appliances. This patch makes the feature configurable
> through a device-tree property.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH RESEND v4 6/9] clk: cs2000-cp: add support for dynamic mode
From: Stephen Boyd @ 2022-01-25 22:30 UTC (permalink / raw)
To: Daniel Mack, mturquette
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack
In-Reply-To: <20220125093336.226787-7-daniel@zonque.org>
Quoting Daniel Mack (2022-01-25 01:33:33)
> The CS2000 chip features two input clocks, REF_CLK and CLK_IN.
>
> In static mode, the output clock (CLK_OUT) is directly derived from
> REF_CLK, and CLK_IN is ignored. In dynamic mode, CLK_IN is used by the
> digital PLL.
>
> In dynamic mode, a low-frequency ratio configuration that uses a higher
> multiplier factor.
>
> Until now, only the static mode and high-frequency divider rations of
> the hardware was supported by the driver. This patch adds support for
> dynamic mode and both ratios:
>
> * Parse a new OF property 'cirrus,dynamic-mode' to determine the mode
> * In dynamic mode, present CLK_IN as parent clock, else use REF_CLK
> * The low-frequency ratio mode is automatically selected, depending
> on the mode of operation and the given input and output rates
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH RESEND v4 5/9] clk: cs2000-cp: Make aux output function controllable
From: Stephen Boyd @ 2022-01-25 22:29 UTC (permalink / raw)
To: Daniel Mack, mturquette
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack
In-Reply-To: <20220125093336.226787-6-daniel@zonque.org>
Quoting Daniel Mack (2022-01-25 01:33:32)
> The aux output pin can be configured to output either of the two clock
> inputs, the generated clock or the pll lock status. Allow access to
> this feature through a new optional device-tree property.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH RESEND v4 4/9] dt-bindings: clock: cs2000-cp: document cirrus,dynamic-mode
From: Stephen Boyd @ 2022-01-25 22:29 UTC (permalink / raw)
To: Daniel Mack, mturquette
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack,
Rob Herring
In-Reply-To: <20220125093336.226787-5-daniel@zonque.org>
Quoting Daniel Mack (2022-01-25 01:33:31)
> This new flag exists to enable the dynamic mode of the hardware.
> When not given, the static mode is used.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH RESEND v4 3/9] dt-bindings: clock: cs2000-cp: document cirrus,clock-skip flag
From: Stephen Boyd @ 2022-01-25 22:29 UTC (permalink / raw)
To: Daniel Mack, mturquette
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack,
Rob Herring
In-Reply-To: <20220125093336.226787-4-daniel@zonque.org>
Quoting Daniel Mack (2022-01-25 01:33:30)
> This mode allows the PLL to maintain lock even when CLK_IN has
> missing pulses for up to 20 ms.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
^ permalink raw reply
* RE: [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap
From: David Laight @ 2022-01-25 22:29 UTC (permalink / raw)
To: 'Jessica Clarke', Atish Patra
Cc: Linux Kernel Mailing List, Anup Patel, Albert Ou, Atish Patra,
Damien Le Moal, devicetree, Jisheng Zhang, Krzysztof Kozlowski,
linux-riscv, Palmer Dabbelt, Paul Walmsley, Rob Herring
In-Reply-To: <1AA3005C-E9C8-4E4B-900D-DD48B37CEA41@jrtc27.com>
> On 20 Jan 2022, at 09:09, Atish Patra <atishp@rivosinc.com> wrote:
> >
> > Currently, SBI APIs accept a hartmask that is generated from struct
> > cpumask. Cpumask data structure can hold upto NR_CPUs value. Thus, it
> > is not the correct data structure for hartids as it can be higher
> > than NR_CPUs for platforms with sparse or discontguous hartids.
> >
> > Remove all association between hartid mask and struct cpumask.
....
> > -static int __sbi_rfence_v01(int fid, const unsigned long *hart_mask,
> > +static int __sbi_rfence_v01(int fid, const struct cpumask *cpu_mask,
> > unsigned long start, unsigned long size,
> > unsigned long arg4, unsigned long arg5)
> > {
> > int result = 0;
> > + unsigned long hart_mask;
> > +
> > + if (!cpu_mask)
> > + cpu_mask = cpu_online_mask;
> > + hart_mask = __sbi_v01_cpumask_to_hartmask(cpu_mask);
> >
> > /* v0.2 function IDs are equivalent to v0.1 extension IDs */
> > switch (fid) {
> > case SBI_EXT_RFENCE_REMOTE_FENCE_I:
> > sbi_ecall(SBI_EXT_0_1_REMOTE_FENCE_I, 0,
> > - (unsigned long)hart_mask, 0, 0, 0, 0, 0);
> > + (unsigned long)&hart_mask, 0, 0, 0, 0, 0);
You don't need the cast.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH RESEND v4 2/9] dt-bindings: clock: cs2000-cp: document aux-output-source
From: Stephen Boyd @ 2022-01-25 22:29 UTC (permalink / raw)
To: Daniel Mack, mturquette
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack,
Rob Herring
In-Reply-To: <20220125093336.226787-3-daniel@zonque.org>
Quoting Daniel Mack (2022-01-25 01:33:29)
> This new optional property can be used to control the function of the
> auxiliary output pin. Introduce a new dt-bindings include file that
> contains the numerical values.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH RESEND v4 1/9] dt-bindings: clock: convert cs2000-cp bindings to yaml
From: Stephen Boyd @ 2022-01-25 22:29 UTC (permalink / raw)
To: Daniel Mack, mturquette
Cc: linux-clk, robh+dt, devicetree, kuninori.morimoto.gx, Daniel Mack,
Rob Herring
In-Reply-To: <20220125093336.226787-2-daniel@zonque.org>
Quoting Daniel Mack (2022-01-25 01:33:28)
> The original author of the file was added as maintainer.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap
From: Jessica Clarke @ 2022-01-25 22:26 UTC (permalink / raw)
To: Atish Patra
Cc: Linux Kernel Mailing List, Anup Patel, Albert Ou, Atish Patra,
Damien Le Moal, devicetree, Jisheng Zhang, Krzysztof Kozlowski,
linux-riscv, Palmer Dabbelt, Paul Walmsley, Rob Herring
In-Reply-To: <20220120090918.2646626-7-atishp@rivosinc.com>
On 20 Jan 2022, at 09:09, Atish Patra <atishp@rivosinc.com> wrote:
>
> Currently, SBI APIs accept a hartmask that is generated from struct
> cpumask. Cpumask data structure can hold upto NR_CPUs value. Thus, it
> is not the correct data structure for hartids as it can be higher
> than NR_CPUs for platforms with sparse or discontguous hartids.
>
> Remove all association between hartid mask and struct cpumask.
>
> Reviewed-by: Anup Patel <anup@brainfault.org> (For Linux RISC-V changes)
> Acked-by: Anup Patel <anup@brainfault.org> (For KVM RISC-V changes)
> Signed-off-by: Atish Patra <atishp@rivosinc.com>
> ---
> arch/riscv/include/asm/sbi.h | 19 +--
> arch/riscv/include/asm/smp.h | 2 -
> arch/riscv/kernel/sbi.c | 189 +++++++++++++++++-------------
> arch/riscv/kernel/setup.c | 10 --
> arch/riscv/kernel/smpboot.c | 2 +-
> arch/riscv/kvm/mmu.c | 4 +-
> arch/riscv/kvm/vcpu_sbi_replace.c | 11 +-
> arch/riscv/kvm/vcpu_sbi_v01.c | 11 +-
> arch/riscv/kvm/vmid.c | 4 +-
> arch/riscv/mm/cacheflush.c | 5 +-
> arch/riscv/mm/tlbflush.c | 9 +-
> 11 files changed, 130 insertions(+), 136 deletions(-)
>
> diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> index 26ba6f2d7a40..d1c37479d828 100644
> --- a/arch/riscv/include/asm/sbi.h
> +++ b/arch/riscv/include/asm/sbi.h
> @@ -8,6 +8,7 @@
> #define _ASM_RISCV_SBI_H
>
> #include <linux/types.h>
> +#include <linux/cpumask.h>
>
> #ifdef CONFIG_RISCV_SBI
> enum sbi_ext_id {
> @@ -128,27 +129,27 @@ long sbi_get_mimpid(void);
> void sbi_set_timer(uint64_t stime_value);
> void sbi_shutdown(void);
> void sbi_clear_ipi(void);
> -int sbi_send_ipi(const unsigned long *hart_mask);
> -int sbi_remote_fence_i(const unsigned long *hart_mask);
> -int sbi_remote_sfence_vma(const unsigned long *hart_mask,
> +int sbi_send_ipi(const struct cpumask *cpu_mask);
> +int sbi_remote_fence_i(const struct cpumask *cpu_mask);
> +int sbi_remote_sfence_vma(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size);
>
> -int sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
> +int sbi_remote_sfence_vma_asid(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size,
> unsigned long asid);
> -int sbi_remote_hfence_gvma(const unsigned long *hart_mask,
> +int sbi_remote_hfence_gvma(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size);
> -int sbi_remote_hfence_gvma_vmid(const unsigned long *hart_mask,
> +int sbi_remote_hfence_gvma_vmid(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size,
> unsigned long vmid);
> -int sbi_remote_hfence_vvma(const unsigned long *hart_mask,
> +int sbi_remote_hfence_vvma(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size);
> -int sbi_remote_hfence_vvma_asid(const unsigned long *hart_mask,
> +int sbi_remote_hfence_vvma_asid(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size,
> unsigned long asid);
> @@ -183,7 +184,7 @@ static inline unsigned long sbi_mk_version(unsigned long major,
>
> int sbi_err_map_linux_errno(int err);
> #else /* CONFIG_RISCV_SBI */
> -static inline int sbi_remote_fence_i(const unsigned long *hart_mask) { return -1; }
> +static inline int sbi_remote_fence_i(const struct cpumask *cpu_mask) { return -1; }
> static inline void sbi_init(void) {}
> #endif /* CONFIG_RISCV_SBI */
> #endif /* _ASM_RISCV_SBI_H */
> diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
> index 6ad749f42807..23170c933d73 100644
> --- a/arch/riscv/include/asm/smp.h
> +++ b/arch/riscv/include/asm/smp.h
> @@ -92,8 +92,6 @@ static inline void riscv_clear_ipi(void)
>
> #endif /* CONFIG_SMP */
>
> -void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out);
> -
> #if defined(CONFIG_HOTPLUG_CPU) && (CONFIG_SMP)
> bool cpu_has_hotplug(unsigned int cpu);
> #else
> diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
> index 9a84f0cb5175..f72527fcb347 100644
> --- a/arch/riscv/kernel/sbi.c
> +++ b/arch/riscv/kernel/sbi.c
> @@ -16,8 +16,8 @@ unsigned long sbi_spec_version __ro_after_init = SBI_SPEC_VERSION_DEFAULT;
> EXPORT_SYMBOL(sbi_spec_version);
>
> static void (*__sbi_set_timer)(uint64_t stime) __ro_after_init;
> -static int (*__sbi_send_ipi)(const unsigned long *hart_mask) __ro_after_init;
> -static int (*__sbi_rfence)(int fid, const unsigned long *hart_mask,
> +static int (*__sbi_send_ipi)(const struct cpumask *cpu_mask) __ro_after_init;
> +static int (*__sbi_rfence)(int fid, const struct cpumask *cpu_mask,
> unsigned long start, unsigned long size,
> unsigned long arg4, unsigned long arg5) __ro_after_init;
>
> @@ -67,6 +67,30 @@ int sbi_err_map_linux_errno(int err)
> EXPORT_SYMBOL(sbi_err_map_linux_errno);
>
> #ifdef CONFIG_RISCV_SBI_V01
> +static unsigned long __sbi_v01_cpumask_to_hartmask(const struct cpumask *cpu_mask)
> +{
> + unsigned long cpuid, hartid;
> + unsigned long hmask = 0;
> +
> + /*
> + * There is no maximum hartid concept in RISC-V and NR_CPUS must not be
> + * associated with hartid. As SBI v0.1 is only kept for backward compatibility
> + * and will be removed in the future, there is no point in supporting hartid
> + * greater than BITS_PER_LONG (32 for RV32 and 64 for RV64). Ideally, SBI v0.2
> + * should be used for platforms with hartid greater than BITS_PER_LONG.
> + */
> + for_each_cpu(cpuid, cpu_mask) {
> + hartid = cpuid_to_hartid_map(cpuid);
> + if (hartid >= BITS_PER_LONG) {
> + pr_warn("Unable to send any request to hartid > BITS_PER_LONG for SBI v0.1\n");
> + break;
> + }
> + hmask |= 1 << hartid;
This should be 1UL otherwise hartid 31 and up cause UB.
> + }
> +
> + return hmask;
> +}
> +
> /**
> * sbi_console_putchar() - Writes given character to the console device.
> * @ch: The data to be written to the console.
> @@ -132,33 +156,44 @@ static void __sbi_set_timer_v01(uint64_t stime_value)
> #endif
> }
>
> -static int __sbi_send_ipi_v01(const unsigned long *hart_mask)
> +static int __sbi_send_ipi_v01(const struct cpumask *cpu_mask)
> {
> - sbi_ecall(SBI_EXT_0_1_SEND_IPI, 0, (unsigned long)hart_mask,
> + unsigned long hart_mask;
> +
> + if (!cpu_mask)
> + cpu_mask = cpu_online_mask;
> + hart_mask = __sbi_v01_cpumask_to_hartmask(cpu_mask);
> +
> + sbi_ecall(SBI_EXT_0_1_SEND_IPI, 0, (unsigned long)(&hart_mask),
> 0, 0, 0, 0, 0);
> return 0;
> }
>
> -static int __sbi_rfence_v01(int fid, const unsigned long *hart_mask,
> +static int __sbi_rfence_v01(int fid, const struct cpumask *cpu_mask,
> unsigned long start, unsigned long size,
> unsigned long arg4, unsigned long arg5)
> {
> int result = 0;
> + unsigned long hart_mask;
> +
> + if (!cpu_mask)
> + cpu_mask = cpu_online_mask;
> + hart_mask = __sbi_v01_cpumask_to_hartmask(cpu_mask);
>
> /* v0.2 function IDs are equivalent to v0.1 extension IDs */
> switch (fid) {
> case SBI_EXT_RFENCE_REMOTE_FENCE_I:
> sbi_ecall(SBI_EXT_0_1_REMOTE_FENCE_I, 0,
> - (unsigned long)hart_mask, 0, 0, 0, 0, 0);
> + (unsigned long)&hart_mask, 0, 0, 0, 0, 0);
> break;
> case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA:
> sbi_ecall(SBI_EXT_0_1_REMOTE_SFENCE_VMA, 0,
> - (unsigned long)hart_mask, start, size,
> + (unsigned long)&hart_mask, start, size,
> 0, 0, 0);
> break;
> case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID:
> sbi_ecall(SBI_EXT_0_1_REMOTE_SFENCE_VMA_ASID, 0,
> - (unsigned long)hart_mask, start, size,
> + (unsigned long)&hart_mask, start, size,
> arg4, 0, 0);
> break;
> default:
> @@ -180,7 +215,7 @@ static void __sbi_set_timer_v01(uint64_t stime_value)
> sbi_major_version(), sbi_minor_version());
> }
>
> -static int __sbi_send_ipi_v01(const unsigned long *hart_mask)
> +static int __sbi_send_ipi_v01(const struct cpumask *cpu_mask)
> {
> pr_warn("IPI extension is not available in SBI v%lu.%lu\n",
> sbi_major_version(), sbi_minor_version());
> @@ -188,7 +223,7 @@ static int __sbi_send_ipi_v01(const unsigned long *hart_mask)
> return 0;
> }
>
> -static int __sbi_rfence_v01(int fid, const unsigned long *hart_mask,
> +static int __sbi_rfence_v01(int fid, const struct cpumask *cpu_mask,
> unsigned long start, unsigned long size,
> unsigned long arg4, unsigned long arg5)
> {
> @@ -212,37 +247,33 @@ static void __sbi_set_timer_v02(uint64_t stime_value)
> #endif
> }
>
> -static int __sbi_send_ipi_v02(const unsigned long *hart_mask)
> +static int __sbi_send_ipi_v02(const struct cpumask *cpu_mask)
> {
> - unsigned long hartid, hmask_val, hbase;
> - struct cpumask tmask;
> + unsigned long hartid, cpuid, hmask = 0, hbase = 0;
> struct sbiret ret = {0};
> int result;
>
> - if (!hart_mask || !(*hart_mask)) {
> - riscv_cpuid_to_hartid_mask(cpu_online_mask, &tmask);
> - hart_mask = cpumask_bits(&tmask);
> - }
> + if (!cpu_mask)
> + cpu_mask = cpu_online_mask;
This is a change in behaviour. Are you sure nothing passes an empty mask?
> - hmask_val = 0;
> - hbase = 0;
> - for_each_set_bit(hartid, hart_mask, NR_CPUS) {
> - if (hmask_val && ((hbase + BITS_PER_LONG) <= hartid)) {
> + for_each_cpu(cpuid, cpu_mask) {
> + hartid = cpuid_to_hartid_map(cpuid);
> + if (hmask && ((hbase + BITS_PER_LONG) <= hartid)) {
> ret = sbi_ecall(SBI_EXT_IPI, SBI_EXT_IPI_SEND_IPI,
> - hmask_val, hbase, 0, 0, 0, 0);
> + hmask, hbase, 0, 0, 0, 0);
> if (ret.error)
> goto ecall_failed;
> - hmask_val = 0;
> + hmask = 0;
> hbase = 0;
> }
> - if (!hmask_val)
> + if (!hmask)
> hbase = hartid;
> - hmask_val |= 1UL << (hartid - hbase);
> + hmask |= 1UL << (hartid - hbase);
> }
>
> - if (hmask_val) {
> + if (hmask) {
> ret = sbi_ecall(SBI_EXT_IPI, SBI_EXT_IPI_SEND_IPI,
> - hmask_val, hbase, 0, 0, 0, 0);
> + hmask, hbase, 0, 0, 0, 0);
> if (ret.error)
> goto ecall_failed;
> }
> @@ -252,11 +283,11 @@ static int __sbi_send_ipi_v02(const unsigned long *hart_mask)
> ecall_failed:
> result = sbi_err_map_linux_errno(ret.error);
> pr_err("%s: hbase = [%lu] hmask = [0x%lx] failed (error [%d])\n",
> - __func__, hbase, hmask_val, result);
> + __func__, hbase, hmask, result);
> return result;
> }
>
> -static int __sbi_rfence_v02_call(unsigned long fid, unsigned long hmask_val,
> +static int __sbi_rfence_v02_call(unsigned long fid, unsigned long hmask,
> unsigned long hbase, unsigned long start,
> unsigned long size, unsigned long arg4,
> unsigned long arg5)
> @@ -267,31 +298,31 @@ static int __sbi_rfence_v02_call(unsigned long fid, unsigned long hmask_val,
>
> switch (fid) {
> case SBI_EXT_RFENCE_REMOTE_FENCE_I:
> - ret = sbi_ecall(ext, fid, hmask_val, hbase, 0, 0, 0, 0);
> + ret = sbi_ecall(ext, fid, hmask, hbase, 0, 0, 0, 0);
> break;
> case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA:
> - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> size, 0, 0);
> break;
> case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID:
> - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> size, arg4, 0);
> break;
>
> case SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA:
> - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> size, 0, 0);
> break;
> case SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID:
> - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> size, arg4, 0);
> break;
> case SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA:
> - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> size, 0, 0);
> break;
> case SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID:
> - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> size, arg4, 0);
> break;
> default:
> @@ -303,43 +334,39 @@ static int __sbi_rfence_v02_call(unsigned long fid, unsigned long hmask_val,
> if (ret.error) {
> result = sbi_err_map_linux_errno(ret.error);
> pr_err("%s: hbase = [%lu] hmask = [0x%lx] failed (error [%d])\n",
> - __func__, hbase, hmask_val, result);
> + __func__, hbase, hmask, result);
> }
>
> return result;
> }
>
> -static int __sbi_rfence_v02(int fid, const unsigned long *hart_mask,
> +static int __sbi_rfence_v02(int fid, const struct cpumask *cpu_mask,
> unsigned long start, unsigned long size,
> unsigned long arg4, unsigned long arg5)
> {
> - unsigned long hmask_val, hartid, hbase;
> - struct cpumask tmask;
> + unsigned long hartid, cpuid, hmask = 0, hbase = 0;
> int result;
>
> - if (!hart_mask || !(*hart_mask)) {
> - riscv_cpuid_to_hartid_mask(cpu_online_mask, &tmask);
> - hart_mask = cpumask_bits(&tmask);
> - }
> + if (!cpu_mask)
> + cpu_mask = cpu_online_mask;
As with __sbi_send_ipi_v02.
Jess
> - hmask_val = 0;
> - hbase = 0;
> - for_each_set_bit(hartid, hart_mask, NR_CPUS) {
> - if (hmask_val && ((hbase + BITS_PER_LONG) <= hartid)) {
> - result = __sbi_rfence_v02_call(fid, hmask_val, hbase,
> + for_each_cpu(cpuid, cpu_mask) {
> + hartid = cpuid_to_hartid_map(cpuid);
> + if (hmask && ((hbase + BITS_PER_LONG) <= hartid)) {
> + result = __sbi_rfence_v02_call(fid, hmask, hbase,
> start, size, arg4, arg5);
> if (result)
> return result;
> - hmask_val = 0;
> + hmask = 0;
> hbase = 0;
> }
> - if (!hmask_val)
> + if (!hmask)
> hbase = hartid;
> - hmask_val |= 1UL << (hartid - hbase);
> + hmask |= 1UL << (hartid - hbase);
> }
>
> - if (hmask_val) {
> - result = __sbi_rfence_v02_call(fid, hmask_val, hbase,
> + if (hmask) {
> + result = __sbi_rfence_v02_call(fid, hmask, hbase,
> start, size, arg4, arg5);
> if (result)
> return result;
> @@ -361,44 +388,44 @@ void sbi_set_timer(uint64_t stime_value)
>
> /**
> * sbi_send_ipi() - Send an IPI to any hart.
> - * @hart_mask: A cpu mask containing all the target harts.
> + * @cpu_mask: A cpu mask containing all the target harts.
> *
> * Return: 0 on success, appropriate linux error code otherwise.
> */
> -int sbi_send_ipi(const unsigned long *hart_mask)
> +int sbi_send_ipi(const struct cpumask *cpu_mask)
> {
> - return __sbi_send_ipi(hart_mask);
> + return __sbi_send_ipi(cpu_mask);
> }
> EXPORT_SYMBOL(sbi_send_ipi);
>
> /**
> * sbi_remote_fence_i() - Execute FENCE.I instruction on given remote harts.
> - * @hart_mask: A cpu mask containing all the target harts.
> + * @cpu_mask: A cpu mask containing all the target harts.
> *
> * Return: 0 on success, appropriate linux error code otherwise.
> */
> -int sbi_remote_fence_i(const unsigned long *hart_mask)
> +int sbi_remote_fence_i(const struct cpumask *cpu_mask)
> {
> return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_FENCE_I,
> - hart_mask, 0, 0, 0, 0);
> + cpu_mask, 0, 0, 0, 0);
> }
> EXPORT_SYMBOL(sbi_remote_fence_i);
>
> /**
> * sbi_remote_sfence_vma() - Execute SFENCE.VMA instructions on given remote
> * harts for the specified virtual address range.
> - * @hart_mask: A cpu mask containing all the target harts.
> + * @cpu_mask: A cpu mask containing all the target harts.
> * @start: Start of the virtual address
> * @size: Total size of the virtual address range.
> *
> * Return: 0 on success, appropriate linux error code otherwise.
> */
> -int sbi_remote_sfence_vma(const unsigned long *hart_mask,
> +int sbi_remote_sfence_vma(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size)
> {
> return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
> - hart_mask, start, size, 0, 0);
> + cpu_mask, start, size, 0, 0);
> }
> EXPORT_SYMBOL(sbi_remote_sfence_vma);
>
> @@ -406,38 +433,38 @@ EXPORT_SYMBOL(sbi_remote_sfence_vma);
> * sbi_remote_sfence_vma_asid() - Execute SFENCE.VMA instructions on given
> * remote harts for a virtual address range belonging to a specific ASID.
> *
> - * @hart_mask: A cpu mask containing all the target harts.
> + * @cpu_mask: A cpu mask containing all the target harts.
> * @start: Start of the virtual address
> * @size: Total size of the virtual address range.
> * @asid: The value of address space identifier (ASID).
> *
> * Return: 0 on success, appropriate linux error code otherwise.
> */
> -int sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
> +int sbi_remote_sfence_vma_asid(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size,
> unsigned long asid)
> {
> return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
> - hart_mask, start, size, asid, 0);
> + cpu_mask, start, size, asid, 0);
> }
> EXPORT_SYMBOL(sbi_remote_sfence_vma_asid);
>
> /**
> * sbi_remote_hfence_gvma() - Execute HFENCE.GVMA instructions on given remote
> * harts for the specified guest physical address range.
> - * @hart_mask: A cpu mask containing all the target harts.
> + * @cpu_mask: A cpu mask containing all the target harts.
> * @start: Start of the guest physical address
> * @size: Total size of the guest physical address range.
> *
> * Return: None
> */
> -int sbi_remote_hfence_gvma(const unsigned long *hart_mask,
> +int sbi_remote_hfence_gvma(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size)
> {
> return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> - hart_mask, start, size, 0, 0);
> + cpu_mask, start, size, 0, 0);
> }
> EXPORT_SYMBOL_GPL(sbi_remote_hfence_gvma);
>
> @@ -445,38 +472,38 @@ EXPORT_SYMBOL_GPL(sbi_remote_hfence_gvma);
> * sbi_remote_hfence_gvma_vmid() - Execute HFENCE.GVMA instructions on given
> * remote harts for a guest physical address range belonging to a specific VMID.
> *
> - * @hart_mask: A cpu mask containing all the target harts.
> + * @cpu_mask: A cpu mask containing all the target harts.
> * @start: Start of the guest physical address
> * @size: Total size of the guest physical address range.
> * @vmid: The value of guest ID (VMID).
> *
> * Return: 0 if success, Error otherwise.
> */
> -int sbi_remote_hfence_gvma_vmid(const unsigned long *hart_mask,
> +int sbi_remote_hfence_gvma_vmid(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size,
> unsigned long vmid)
> {
> return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID,
> - hart_mask, start, size, vmid, 0);
> + cpu_mask, start, size, vmid, 0);
> }
> EXPORT_SYMBOL(sbi_remote_hfence_gvma_vmid);
>
> /**
> * sbi_remote_hfence_vvma() - Execute HFENCE.VVMA instructions on given remote
> * harts for the current guest virtual address range.
> - * @hart_mask: A cpu mask containing all the target harts.
> + * @cpu_mask: A cpu mask containing all the target harts.
> * @start: Start of the current guest virtual address
> * @size: Total size of the current guest virtual address range.
> *
> * Return: None
> */
> -int sbi_remote_hfence_vvma(const unsigned long *hart_mask,
> +int sbi_remote_hfence_vvma(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size)
> {
> return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> - hart_mask, start, size, 0, 0);
> + cpu_mask, start, size, 0, 0);
> }
> EXPORT_SYMBOL(sbi_remote_hfence_vvma);
>
> @@ -485,20 +512,20 @@ EXPORT_SYMBOL(sbi_remote_hfence_vvma);
> * remote harts for current guest virtual address range belonging to a specific
> * ASID.
> *
> - * @hart_mask: A cpu mask containing all the target harts.
> + * @cpu_mask: A cpu mask containing all the target harts.
> * @start: Start of the current guest virtual address
> * @size: Total size of the current guest virtual address range.
> * @asid: The value of address space identifier (ASID).
> *
> * Return: None
> */
> -int sbi_remote_hfence_vvma_asid(const unsigned long *hart_mask,
> +int sbi_remote_hfence_vvma_asid(const struct cpumask *cpu_mask,
> unsigned long start,
> unsigned long size,
> unsigned long asid)
> {
> return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID,
> - hart_mask, start, size, asid, 0);
> + cpu_mask, start, size, asid, 0);
> }
> EXPORT_SYMBOL(sbi_remote_hfence_vvma_asid);
>
> @@ -591,11 +618,7 @@ long sbi_get_mimpid(void)
>
> static void sbi_send_cpumask_ipi(const struct cpumask *target)
> {
> - struct cpumask hartid_mask;
> -
> - riscv_cpuid_to_hartid_mask(target, &hartid_mask);
> -
> - sbi_send_ipi(cpumask_bits(&hartid_mask));
> + sbi_send_ipi(target);
> }
>
> static const struct riscv_ipi_ops sbi_ipi_ops = {
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 63241abe84eb..b42bfdc67482 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -59,16 +59,6 @@ atomic_t hart_lottery __section(".sdata")
> unsigned long boot_cpu_hartid;
> static DEFINE_PER_CPU(struct cpu, cpu_devices);
>
> -void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out)
> -{
> - int cpu;
> -
> - cpumask_clear(out);
> - for_each_cpu(cpu, in)
> - cpumask_set_cpu(cpuid_to_hartid_map(cpu), out);
> -}
> -EXPORT_SYMBOL_GPL(riscv_cpuid_to_hartid_mask);
> -
> /*
> * Place kernel memory regions on the resource tree so that
> * kexec-tools can retrieve them from /proc/iomem. While there
> diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
> index bd82375db51a..622f226454d5 100644
> --- a/arch/riscv/kernel/smpboot.c
> +++ b/arch/riscv/kernel/smpboot.c
> @@ -96,7 +96,7 @@ void __init setup_smp(void)
> if (cpuid >= NR_CPUS) {
> pr_warn("Invalid cpuid [%d] for hartid [%d]\n",
> cpuid, hart);
> - break;
> + continue;
> }
>
> cpuid_to_hartid_map(cpuid) = hart;
> diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> index 9af67dbdc66a..f80a34fbf102 100644
> --- a/arch/riscv/kvm/mmu.c
> +++ b/arch/riscv/kvm/mmu.c
> @@ -114,7 +114,6 @@ static bool stage2_get_leaf_entry(struct kvm *kvm, gpa_t addr,
>
> static void stage2_remote_tlb_flush(struct kvm *kvm, u32 level, gpa_t addr)
> {
> - struct cpumask hmask;
> unsigned long size = PAGE_SIZE;
> struct kvm_vmid *vmid = &kvm->arch.vmid;
>
> @@ -127,8 +126,7 @@ static void stage2_remote_tlb_flush(struct kvm *kvm, u32 level, gpa_t addr)
> * where the Guest/VM is running.
> */
> preempt_disable();
> - riscv_cpuid_to_hartid_mask(cpu_online_mask, &hmask);
> - sbi_remote_hfence_gvma_vmid(cpumask_bits(&hmask), addr, size,
> + sbi_remote_hfence_gvma_vmid(cpu_online_mask, addr, size,
> READ_ONCE(vmid->vmid));
> preempt_enable();
> }
> diff --git a/arch/riscv/kvm/vcpu_sbi_replace.c b/arch/riscv/kvm/vcpu_sbi_replace.c
> index 00036b7f83b9..1bc0608a5bfd 100644
> --- a/arch/riscv/kvm/vcpu_sbi_replace.c
> +++ b/arch/riscv/kvm/vcpu_sbi_replace.c
> @@ -82,7 +82,7 @@ static int kvm_sbi_ext_rfence_handler(struct kvm_vcpu *vcpu, struct kvm_run *run
> {
> int ret = 0;
> unsigned long i;
> - struct cpumask cm, hm;
> + struct cpumask cm;
> struct kvm_vcpu *tmp;
> struct kvm_cpu_context *cp = &vcpu->arch.guest_context;
> unsigned long hmask = cp->a0;
> @@ -90,7 +90,6 @@ static int kvm_sbi_ext_rfence_handler(struct kvm_vcpu *vcpu, struct kvm_run *run
> unsigned long funcid = cp->a6;
>
> cpumask_clear(&cm);
> - cpumask_clear(&hm);
> kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
> if (hbase != -1UL) {
> if (tmp->vcpu_id < hbase)
> @@ -103,17 +102,15 @@ static int kvm_sbi_ext_rfence_handler(struct kvm_vcpu *vcpu, struct kvm_run *run
> cpumask_set_cpu(tmp->cpu, &cm);
> }
>
> - riscv_cpuid_to_hartid_mask(&cm, &hm);
> -
> switch (funcid) {
> case SBI_EXT_RFENCE_REMOTE_FENCE_I:
> - ret = sbi_remote_fence_i(cpumask_bits(&hm));
> + ret = sbi_remote_fence_i(&cm);
> break;
> case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA:
> - ret = sbi_remote_hfence_vvma(cpumask_bits(&hm), cp->a2, cp->a3);
> + ret = sbi_remote_hfence_vvma(&cm, cp->a2, cp->a3);
> break;
> case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID:
> - ret = sbi_remote_hfence_vvma_asid(cpumask_bits(&hm), cp->a2,
> + ret = sbi_remote_hfence_vvma_asid(&cm, cp->a2,
> cp->a3, cp->a4);
> break;
> case SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA:
> diff --git a/arch/riscv/kvm/vcpu_sbi_v01.c b/arch/riscv/kvm/vcpu_sbi_v01.c
> index 4c7e13ec9ccc..07e2de14433a 100644
> --- a/arch/riscv/kvm/vcpu_sbi_v01.c
> +++ b/arch/riscv/kvm/vcpu_sbi_v01.c
> @@ -38,7 +38,7 @@ static int kvm_sbi_ext_v01_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
> int i, ret = 0;
> u64 next_cycle;
> struct kvm_vcpu *rvcpu;
> - struct cpumask cm, hm;
> + struct cpumask cm;
> struct kvm *kvm = vcpu->kvm;
> struct kvm_cpu_context *cp = &vcpu->arch.guest_context;
>
> @@ -101,15 +101,12 @@ static int kvm_sbi_ext_v01_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
> continue;
> cpumask_set_cpu(rvcpu->cpu, &cm);
> }
> - riscv_cpuid_to_hartid_mask(&cm, &hm);
> if (cp->a7 == SBI_EXT_0_1_REMOTE_FENCE_I)
> - ret = sbi_remote_fence_i(cpumask_bits(&hm));
> + ret = sbi_remote_fence_i(&cm);
> else if (cp->a7 == SBI_EXT_0_1_REMOTE_SFENCE_VMA)
> - ret = sbi_remote_hfence_vvma(cpumask_bits(&hm),
> - cp->a1, cp->a2);
> + ret = sbi_remote_hfence_vvma(&cm, cp->a1, cp->a2);
> else
> - ret = sbi_remote_hfence_vvma_asid(cpumask_bits(&hm),
> - cp->a1, cp->a2, cp->a3);
> + ret = sbi_remote_hfence_vvma_asid(&cm, cp->a1, cp->a2, cp->a3);
> break;
> default:
> ret = -EINVAL;
> diff --git a/arch/riscv/kvm/vmid.c b/arch/riscv/kvm/vmid.c
> index 807228f8f409..2fa4f7b1813d 100644
> --- a/arch/riscv/kvm/vmid.c
> +++ b/arch/riscv/kvm/vmid.c
> @@ -67,7 +67,6 @@ void kvm_riscv_stage2_vmid_update(struct kvm_vcpu *vcpu)
> {
> unsigned long i;
> struct kvm_vcpu *v;
> - struct cpumask hmask;
> struct kvm_vmid *vmid = &vcpu->kvm->arch.vmid;
>
> if (!kvm_riscv_stage2_vmid_ver_changed(vmid))
> @@ -102,8 +101,7 @@ void kvm_riscv_stage2_vmid_update(struct kvm_vcpu *vcpu)
> * running, we force VM exits on all host CPUs using IPI and
> * flush all Guest TLBs.
> */
> - riscv_cpuid_to_hartid_mask(cpu_online_mask, &hmask);
> - sbi_remote_hfence_gvma(cpumask_bits(&hmask), 0, 0);
> + sbi_remote_hfence_gvma(cpu_online_mask, 0, 0);
> }
>
> vmid->vmid = vmid_next;
> diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
> index 89f81067e09e..6cb7d96ad9c7 100644
> --- a/arch/riscv/mm/cacheflush.c
> +++ b/arch/riscv/mm/cacheflush.c
> @@ -67,10 +67,7 @@ void flush_icache_mm(struct mm_struct *mm, bool local)
> */
> smp_mb();
> } else if (IS_ENABLED(CONFIG_RISCV_SBI)) {
> - cpumask_t hartid_mask;
> -
> - riscv_cpuid_to_hartid_mask(&others, &hartid_mask);
> - sbi_remote_fence_i(cpumask_bits(&hartid_mask));
> + sbi_remote_fence_i(&others);
> } else {
> on_each_cpu_mask(&others, ipi_remote_fence_i, NULL, 1);
> }
> diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c
> index 64f8201237c2..37ed760d007c 100644
> --- a/arch/riscv/mm/tlbflush.c
> +++ b/arch/riscv/mm/tlbflush.c
> @@ -32,7 +32,6 @@ static void __sbi_tlb_flush_range(struct mm_struct *mm, unsigned long start,
> unsigned long size, unsigned long stride)
> {
> struct cpumask *cmask = mm_cpumask(mm);
> - struct cpumask hmask;
> unsigned int cpuid;
> bool broadcast;
>
> @@ -46,9 +45,7 @@ static void __sbi_tlb_flush_range(struct mm_struct *mm, unsigned long start,
> unsigned long asid = atomic_long_read(&mm->context.id);
>
> if (broadcast) {
> - riscv_cpuid_to_hartid_mask(cmask, &hmask);
> - sbi_remote_sfence_vma_asid(cpumask_bits(&hmask),
> - start, size, asid);
> + sbi_remote_sfence_vma_asid(cmask, start, size, asid);
> } else if (size <= stride) {
> local_flush_tlb_page_asid(start, asid);
> } else {
> @@ -56,9 +53,7 @@ static void __sbi_tlb_flush_range(struct mm_struct *mm, unsigned long start,
> }
> } else {
> if (broadcast) {
> - riscv_cpuid_to_hartid_mask(cmask, &hmask);
> - sbi_remote_sfence_vma(cpumask_bits(&hmask),
> - start, size);
> + sbi_remote_sfence_vma(cmask, start, size);
> } else if (size <= stride) {
> local_flush_tlb_page(start);
> } else {
> --
> 2.30.2
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH v3 10/15] drivers: clk: qcom: gcc-ipq806x: add additional freq for sdc table
From: Stephen Boyd @ 2022-01-25 22:18 UTC (permalink / raw)
To: Ansuel Smith
Cc: Andy Gross, Bjorn Andersson, Michael Turquette, Philipp Zabel,
Rob Herring, Taniya Das, devicetree, linux-arm-msm, linux-clk,
linux-kernel
In-Reply-To: <61f065b9.1c69fb81.ed14d.b9e2@mx.google.com>
Quoting Ansuel Smith (2022-01-25 13:03:52)
> On Tue, Jan 25, 2022 at 12:45:53PM -0800, Stephen Boyd wrote:
> > Quoting Ansuel Smith (2022-01-21 13:03:35)
> > > Add additional freq supported for the sdc table.
> > >
> > > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > > ---
> > > drivers/clk/qcom/gcc-ipq806x.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c
> > > index 77bc3d94f580..dbd61e4844b0 100644
> > > --- a/drivers/clk/qcom/gcc-ipq806x.c
> > > +++ b/drivers/clk/qcom/gcc-ipq806x.c
> > > @@ -1292,6 +1292,7 @@ static const struct freq_tbl clk_tbl_sdc[] = {
> > > { 20210000, P_PLL8, 1, 1, 19 },
> > > { 24000000, P_PLL8, 4, 1, 4 },
> > > { 48000000, P_PLL8, 4, 1, 2 },
> > > + { 52000000, P_PLL8, 1, 2, 15 }, /* 51.2 Mhz */
> >
> > Why the comment and fake rate? Can it be 51200000 instead and drop the
> > comment?
>
> I will add the related reason in the commit.
>
> We cannot achieve exact 52Mhz(jitter free) clock using PLL8.
> As per the MND calculator the closest possible jitter free clock
> using PLL8 is 51.2Mhz. This patch adds the values, which will provide
> jitter free 51.2Mhz when the requested frequency is 52mhz.
Sounds like this clk should use the round down clk_ops instead of the
round up ones. Then the actual frequency can be in the table.
^ permalink raw reply
* Re: [PATCH] kbuild: unify cmd_copy and cmd_shipped
From: Gabriel Krisman Bertazi @ 2022-01-25 22:11 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Masahiro Yamada, linux-kbuild, Michal Marek, Michal Simek,
Rob Herring, devicetree, linux-fsdevel, linux-kernel
In-Reply-To: <CAKwvOdm=-x1EP_xu2V_OZNdPid=gacVzCTx+=uSYqzCv+1Rbfw@mail.gmail.com>
Nick Desaulniers <ndesaulniers@google.com> writes:
> On Mon, Jan 24, 2022 at 10:41 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>>
>> cmd_copy and cmd_shipped have similar functionality. The difference is
>> that cmd_copy uses 'cp' while cmd_shipped 'cat'.
>>
>> Unify them into cmd_copy because this macro name is more intuitive.
>>
>> Going forward, cmd_copy will use 'cat' to avoid the permission issue.
>> I also thought of 'cp --no-preserve=mode' but this option is not
>> mentioned in the POSIX spec [1], so I am keeping the 'cat' command.
>>
>> [1]: https://pubs.opengroup.org/onlinepubs/009695299/utilities/cp.html
>> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
>> ---
>>
>> arch/microblaze/boot/Makefile | 2 +-
>> arch/microblaze/boot/dts/Makefile | 2 +-
>> fs/unicode/Makefile | 2 +-
>> scripts/Makefile.lib | 12 ++++--------
>> usr/Makefile | 4 ++--
>> 5 files changed, 9 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
>> index cff570a71946..2b42c370d574 100644
>> --- a/arch/microblaze/boot/Makefile
>> +++ b/arch/microblaze/boot/Makefile
>> @@ -29,7 +29,7 @@ $(obj)/simpleImage.$(DTB).ub: $(obj)/simpleImage.$(DTB) FORCE
>> $(call if_changed,uimage)
>>
>> $(obj)/simpleImage.$(DTB).unstrip: vmlinux FORCE
>> - $(call if_changed,shipped)
>> + $(call if_changed,copy)
>>
>> $(obj)/simpleImage.$(DTB).strip: vmlinux FORCE
>> $(call if_changed,strip)
>> diff --git a/arch/microblaze/boot/dts/Makefile b/arch/microblaze/boot/dts/Makefile
>> index ef00dd30d19a..b84e2cbb20ee 100644
>> --- a/arch/microblaze/boot/dts/Makefile
>> +++ b/arch/microblaze/boot/dts/Makefile
>> @@ -12,7 +12,7 @@ $(obj)/linked_dtb.o: $(obj)/system.dtb
>> # Generate system.dtb from $(DTB).dtb
>> ifneq ($(DTB),system)
>> $(obj)/system.dtb: $(obj)/$(DTB).dtb
>> - $(call if_changed,shipped)
>> + $(call if_changed,copy)
>> endif
>> endif
>>
>> diff --git a/fs/unicode/Makefile b/fs/unicode/Makefile
>> index 2f9d9188852b..74ae80fc3a36 100644
>> --- a/fs/unicode/Makefile
>> +++ b/fs/unicode/Makefile
>> @@ -31,7 +31,7 @@ $(obj)/utf8data.c: $(obj)/mkutf8data $(filter %.txt, $(cmd_utf8data)) FORCE
>> else
>>
>> $(obj)/utf8data.c: $(src)/utf8data.c_shipped FORCE
>
> do we want to retitle the _shipped suffix for this file to _copy now, too?
> fs/unicode/Makefile:11
> fs/unicode/Makefile:33
> fs/unicode/Makefile:34
I think _copy doesn't convey the sense that this is distributed with the
kernel tree, even though it is also generated from in-tree sources.
Even if that is not the original sense of _shipped (is it?), it makes
sense to me that way, but _copy doesn't.
The patch looks good to me, though.
Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.com>
>
> Either way
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
>
>> - $(call if_changed,shipped)
>> + $(call if_changed,copy)
>>
>> endif
>>
>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>> index 79be57fdd32a..40735a3adb54 100644
>> --- a/scripts/Makefile.lib
>> +++ b/scripts/Makefile.lib
>> @@ -246,20 +246,16 @@ $(foreach m, $(notdir $1), \
>> $(addprefix $(obj)/, $(foreach s, $3, $($(m:%$(strip $2)=%$(s)))))))
>> endef
>>
>> -quiet_cmd_copy = COPY $@
>> - cmd_copy = cp $< $@
>> -
>> -# Shipped files
>> +# Copy a file
>> # ===========================================================================
>> # 'cp' preserves permissions. If you use it to copy a file in read-only srctree,
>> # the copy would be read-only as well, leading to an error when executing the
>> # rule next time. Use 'cat' instead in order to generate a writable file.
>> -
>> -quiet_cmd_shipped = SHIPPED $@
>> -cmd_shipped = cat $< > $@
>> +quiet_cmd_copy = COPY $@
>> + cmd_copy = cat $< > $@
>>
>> $(obj)/%: $(src)/%_shipped
>> - $(call cmd,shipped)
>> + $(call cmd,copy)
>>
>> # Commands useful for building a boot image
>> # ===========================================================================
>> diff --git a/usr/Makefile b/usr/Makefile
>> index cc0d2824e100..59d9e8b07a01 100644
>> --- a/usr/Makefile
>> +++ b/usr/Makefile
>> @@ -3,7 +3,7 @@
>> # kbuild file for usr/ - including initramfs image
>> #
>>
>> -compress-y := shipped
>> +compress-y := copy
>> compress-$(CONFIG_INITRAMFS_COMPRESSION_GZIP) := gzip
>> compress-$(CONFIG_INITRAMFS_COMPRESSION_BZIP2) := bzip2
>> compress-$(CONFIG_INITRAMFS_COMPRESSION_LZMA) := lzma
>> @@ -37,7 +37,7 @@ endif
>> # .cpio.*, use it directly as an initramfs, and avoid double compression.
>> ifeq ($(words $(subst .cpio.,$(space),$(ramfs-input))),2)
>> cpio-data := $(ramfs-input)
>> -compress-y := shipped
>> +compress-y := copy
>> endif
>>
>> endif
>> --
>> 2.32.0
>>
--
Gabriel Krisman Bertazi
^ permalink raw reply
* Re: [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap
From: Ron Economos @ 2022-01-25 21:11 UTC (permalink / raw)
To: Geert Uytterhoeven, Atish Patra
Cc: Atish Patra, Linux Kernel Mailing List, Anup Patel, Albert Ou,
Damien Le Moal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Jisheng Zhang, Krzysztof Kozlowski, linux-riscv, Palmer Dabbelt,
Paul Walmsley, Rob Herring, Emil Renner Berthing
In-Reply-To: <CAMuHMdWBF0XXXQLfAH81F=BczjsDeQFU454_A2C_-qLPKJGpiQ@mail.gmail.com>
On 1/25/22 12:52, Geert Uytterhoeven wrote:
> Hi Atish,
>
> On Tue, Jan 25, 2022 at 9:17 PM Atish Patra <atishp@atishpatra.org> wrote:
>> On Tue, Jan 25, 2022 at 12:12 PM Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Thu, Jan 20, 2022 at 10:12 AM Atish Patra <atishp@rivosinc.com> wrote:
>>>> Currently, SBI APIs accept a hartmask that is generated from struct
>>>> cpumask. Cpumask data structure can hold upto NR_CPUs value. Thus, it
>>>> is not the correct data structure for hartids as it can be higher
>>>> than NR_CPUs for platforms with sparse or discontguous hartids.
>>>>
>>>> Remove all association between hartid mask and struct cpumask.
>>>>
>>>> Reviewed-by: Anup Patel <anup@brainfault.org> (For Linux RISC-V changes)
>>>> Acked-by: Anup Patel <anup@brainfault.org> (For KVM RISC-V changes)
>>>> Signed-off-by: Atish Patra <atishp@rivosinc.com>
>>> Thanks for your patch, which is now commit 26fb751ca37846c9 ("RISC-V:
>>> Do not use cpumask data structure for hartid bitmap") in v5.17-rc1.
>>>
>>> I am having an issue with random userspace SEGVs on Starlight Beta
>>> (which needs out-of-tree patches). It doesn't always manifest
>>> itself immediately, so it took a while to bisect, but I suspect the
>>> above commit to be the culprit.
>> I have never seen one before during my testing. How frequently do you see them?
>> Does it happen while running anything or just idle user space results
>> in SEGVs randomly.
> Sometimes they happen during startup (lots of failures from systemd),
> sometimes they happen later, during interactive work.
> Sometimes while idle, and something runs in the background (e.g. mandb).
>
>> Do you have a trace that I can look into ?
> # apt update
> [ 807.499050] apt[258]: unhandled signal 11 code 0x1 at
> 0xffffff8300060020 in libapt-pkg.so.6.0.0[3fa49ac000+174000]
> [ 807.509548] CPU: 0 PID: 258 Comm: apt Not tainted
> 5.16.0-starlight-11192-g26fb751ca378-dirty #153
> [ 807.518674] Hardware name: BeagleV Starlight Beta (DT)
> [ 807.524077] epc : 0000003fa4a47a0a ra : 0000003fa4a479fc sp :
> 0000003fcb4b39b0
> [ 807.531383] gp : 0000002adcef4800 tp : 0000003fa43287b0 t0 :
> 0000000000000001
> [ 807.538603] t1 : 0000000000000009 t2 : 00000000000003ff s0 :
> 0000000000000000
> [ 807.545887] s1 : 0000002adcf3cb60 a0 : 0000000000000003 a1 :
> 0000000000000000
> [ 807.553167] a2 : 0000003fcb4b3a30 a3 : 0000000000000000 a4 :
> 0000002adcf3cc1c
> [ 807.560390] a5 : 0007000300060000 a6 : 0000000000000003 a7 :
> 1999999999999999
> [ 807.567654] s2 : 0000003fcb4b3a28 s3 : 0000000000000002 s4 :
> 0000003fcb4b3a30
> [ 807.575039] s5 : 0000003fa4baa810 s6 : 0000000000000010 s7 :
> 0000002adcf19a40
> [ 807.582363] s8 : 0000003fcb4b4010 s9 : 0000003fa4baa810 s10:
> 0000003fcb4b3e90
> [ 807.589606] s11: 0000003fa4b2a528 t3 : 0000000000000000 t4 :
> 0000003fa47906a0
> [ 807.596891] t5 : 0000000000000005 t6 : ffffffffffffffff
> [ 807.602302] status: 0000000200004020 badaddr: ffffff8300060020
> cause: 000000000000000d
>
> (-dirty due to Starlight DTS and driver updates)
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
I'm not sure if it's related, but I'm also seeing a systemd segfault on
boot with the HiFive Unmatched and 5.17.0-rc1. I don't have the dmesg
dump, but here's the journalctl dump. It was built before the tag, so it
says 5.16.0.
Jan 23 02:41:50 riscv64 systemd-udevd[551]: mmcblk0p12: Failed to wait
for spawned command '/usr/bin/unshare -m /usr/bin/snap auto-import
--mount=/dev/mmcblk0p12': Invalid argument
Jan 23 02:41:50 riscv64 systemd-udevd[412]: mmcblk0p12: Process
'/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/mmcblk0p12'
terminated by signal SEGV.
Jan 23 02:41:50 riscv64 kernel: systemd-udevd[551]: unhandled signal 11
code 0x1 at 0x0000000003938700 in udevadm[3fa7eee000+b1000]
Jan 23 02:41:50 riscv64 kernel: CPU: 2 PID: 551 Comm: systemd-udevd Not
tainted 5.16.0 #1
Jan 23 02:41:50 riscv64 kernel: Hardware name: SiFive HiFive Unmatched
A00 (DT)
Jan 23 02:41:50 riscv64 kernel: epc : 0000003fa7f14104 ra :
0000003fa7f14102 sp : 0000003fe3da5320
Jan 23 02:41:50 riscv64 kernel: gp : 0000003fa7fc3ef8 tp :
0000003fa79f8530 t0 : 0000003fe3da38f0
Jan 23 02:41:50 riscv64 kernel: t1 : 0000003fa7f0425c t2 :
0000000000000000 s0 : 0000003fcd046d88
Jan 23 02:41:50 riscv64 kernel: s1 : 0000003fcd046d60 a0 :
ffffffffffffffff a1 : 0000003fcd0cb330
Jan 23 02:41:50 riscv64 kernel: a2 : 0000003fcd043028 a3 :
0000000000000007 a4 : c98b6a1813e46d00
Jan 23 02:41:50 riscv64 kernel: a5 : ffffffffffffffff a6 :
fefefefefefefeff a7 : 0000000000000039
Jan 23 02:41:50 riscv64 kernel: s2 : 0000000000000000 s3 :
ffffffffffffffea s4 : 0000000000000000
Jan 23 02:41:50 riscv64 kernel: s5 : 0000003fe3da5378 s6 :
ffffffffffffffea s7 : 0000000003938700
Jan 23 02:41:50 riscv64 kernel: s8 : 0000003fe3da53e0 s9 :
0000003fe3da53d8 s10: 0000003fa7fc200c
Jan 23 02:41:50 riscv64 kernel: s11: 0000000000081000 t3 :
0000003fa7db3822 t4 : 0000000000000000
Jan 23 02:41:50 riscv64 kernel: t5 : 0000003fe3da38c8 t6 : 000000000000002a
Jan 23 02:41:50 riscv64 kernel: status: 0000000200004020 badaddr:
0000000003938700 cause: 000000000000000d
Jan 23 02:41:50 riscv64 systemd-udevd[412]: mmcblk0p12: Failed to wait
for spawned command '/usr/bin/unshare -m /usr/bin/snap auto-import
--mount=/dev/mmcblk0p12': Input/output error
Jan 23 02:41:50 riscv64 systemd-udevd[412]: mmcblk0p12: Failed to
execute '/usr/bin/unshare -m /usr/bin/snap auto-import
--mount=/dev/mmcblk0p12', ignoring: Input/output error
I'll try removing this patch.
Ron
^ permalink raw reply
* [PATCH v2] leds: remove ide-disk trigger
From: Corentin Labbe @ 2022-01-25 21:05 UTC (permalink / raw)
To: pavel, robh+dt; +Cc: devicetree, linux-kernel, linux-leds, Corentin Labbe
No user of ide-disk remains, so remove this deprecated trigger.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
Changes since v1:
- remove also DEFINE_LED_TRIGGER(ledtrig_ide)
Documentation/devicetree/bindings/leds/common.yaml | 3 ---
drivers/leds/trigger/ledtrig-disk.c | 4 ----
2 files changed, 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index 37f8a6fd6518..c89f430df4a0 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -91,9 +91,6 @@ properties:
- disk-activity
- disk-read
- disk-write
- # LED indicates IDE disk activity (deprecated), in new implementations
- # use "disk-activity"
- - ide-disk
# LED flashes at a fixed, configurable rate
- timer
# LED alters the brightness for the specified duration with one software
diff --git a/drivers/leds/trigger/ledtrig-disk.c b/drivers/leds/trigger/ledtrig-disk.c
index 0741910785bb..0b7dfbd04273 100644
--- a/drivers/leds/trigger/ledtrig-disk.c
+++ b/drivers/leds/trigger/ledtrig-disk.c
@@ -16,7 +16,6 @@
DEFINE_LED_TRIGGER(ledtrig_disk);
DEFINE_LED_TRIGGER(ledtrig_disk_read);
DEFINE_LED_TRIGGER(ledtrig_disk_write);
-DEFINE_LED_TRIGGER(ledtrig_ide);
void ledtrig_disk_activity(bool write)
{
@@ -24,8 +23,6 @@ void ledtrig_disk_activity(bool write)
led_trigger_blink_oneshot(ledtrig_disk,
&blink_delay, &blink_delay, 0);
- led_trigger_blink_oneshot(ledtrig_ide,
- &blink_delay, &blink_delay, 0);
if (write)
led_trigger_blink_oneshot(ledtrig_disk_write,
&blink_delay, &blink_delay, 0);
@@ -40,7 +37,6 @@ static int __init ledtrig_disk_init(void)
led_trigger_register_simple("disk-activity", &ledtrig_disk);
led_trigger_register_simple("disk-read", &ledtrig_disk_read);
led_trigger_register_simple("disk-write", &ledtrig_disk_write);
- led_trigger_register_simple("ide-disk", &ledtrig_ide);
return 0;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] kbuild: unify cmd_copy and cmd_shipped
From: Nick Desaulniers @ 2022-01-25 21:04 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-kbuild, Gabriel Krisman Bertazi, Michal Marek, Michal Simek,
Rob Herring, devicetree, linux-fsdevel, linux-kernel
In-Reply-To: <20220125064027.873131-1-masahiroy@kernel.org>
On Mon, Jan 24, 2022 at 10:41 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> cmd_copy and cmd_shipped have similar functionality. The difference is
> that cmd_copy uses 'cp' while cmd_shipped 'cat'.
>
> Unify them into cmd_copy because this macro name is more intuitive.
>
> Going forward, cmd_copy will use 'cat' to avoid the permission issue.
> I also thought of 'cp --no-preserve=mode' but this option is not
> mentioned in the POSIX spec [1], so I am keeping the 'cat' command.
>
> [1]: https://pubs.opengroup.org/onlinepubs/009695299/utilities/cp.html
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> ---
>
> arch/microblaze/boot/Makefile | 2 +-
> arch/microblaze/boot/dts/Makefile | 2 +-
> fs/unicode/Makefile | 2 +-
> scripts/Makefile.lib | 12 ++++--------
> usr/Makefile | 4 ++--
> 5 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
> index cff570a71946..2b42c370d574 100644
> --- a/arch/microblaze/boot/Makefile
> +++ b/arch/microblaze/boot/Makefile
> @@ -29,7 +29,7 @@ $(obj)/simpleImage.$(DTB).ub: $(obj)/simpleImage.$(DTB) FORCE
> $(call if_changed,uimage)
>
> $(obj)/simpleImage.$(DTB).unstrip: vmlinux FORCE
> - $(call if_changed,shipped)
> + $(call if_changed,copy)
>
> $(obj)/simpleImage.$(DTB).strip: vmlinux FORCE
> $(call if_changed,strip)
> diff --git a/arch/microblaze/boot/dts/Makefile b/arch/microblaze/boot/dts/Makefile
> index ef00dd30d19a..b84e2cbb20ee 100644
> --- a/arch/microblaze/boot/dts/Makefile
> +++ b/arch/microblaze/boot/dts/Makefile
> @@ -12,7 +12,7 @@ $(obj)/linked_dtb.o: $(obj)/system.dtb
> # Generate system.dtb from $(DTB).dtb
> ifneq ($(DTB),system)
> $(obj)/system.dtb: $(obj)/$(DTB).dtb
> - $(call if_changed,shipped)
> + $(call if_changed,copy)
> endif
> endif
>
> diff --git a/fs/unicode/Makefile b/fs/unicode/Makefile
> index 2f9d9188852b..74ae80fc3a36 100644
> --- a/fs/unicode/Makefile
> +++ b/fs/unicode/Makefile
> @@ -31,7 +31,7 @@ $(obj)/utf8data.c: $(obj)/mkutf8data $(filter %.txt, $(cmd_utf8data)) FORCE
> else
>
> $(obj)/utf8data.c: $(src)/utf8data.c_shipped FORCE
do we want to retitle the _shipped suffix for this file to _copy now, too?
fs/unicode/Makefile:11
fs/unicode/Makefile:33
fs/unicode/Makefile:34
Either way
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> - $(call if_changed,shipped)
> + $(call if_changed,copy)
>
> endif
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 79be57fdd32a..40735a3adb54 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -246,20 +246,16 @@ $(foreach m, $(notdir $1), \
> $(addprefix $(obj)/, $(foreach s, $3, $($(m:%$(strip $2)=%$(s)))))))
> endef
>
> -quiet_cmd_copy = COPY $@
> - cmd_copy = cp $< $@
> -
> -# Shipped files
> +# Copy a file
> # ===========================================================================
> # 'cp' preserves permissions. If you use it to copy a file in read-only srctree,
> # the copy would be read-only as well, leading to an error when executing the
> # rule next time. Use 'cat' instead in order to generate a writable file.
> -
> -quiet_cmd_shipped = SHIPPED $@
> -cmd_shipped = cat $< > $@
> +quiet_cmd_copy = COPY $@
> + cmd_copy = cat $< > $@
>
> $(obj)/%: $(src)/%_shipped
> - $(call cmd,shipped)
> + $(call cmd,copy)
>
> # Commands useful for building a boot image
> # ===========================================================================
> diff --git a/usr/Makefile b/usr/Makefile
> index cc0d2824e100..59d9e8b07a01 100644
> --- a/usr/Makefile
> +++ b/usr/Makefile
> @@ -3,7 +3,7 @@
> # kbuild file for usr/ - including initramfs image
> #
>
> -compress-y := shipped
> +compress-y := copy
> compress-$(CONFIG_INITRAMFS_COMPRESSION_GZIP) := gzip
> compress-$(CONFIG_INITRAMFS_COMPRESSION_BZIP2) := bzip2
> compress-$(CONFIG_INITRAMFS_COMPRESSION_LZMA) := lzma
> @@ -37,7 +37,7 @@ endif
> # .cpio.*, use it directly as an initramfs, and avoid double compression.
> ifeq ($(words $(subst .cpio.,$(space),$(ramfs-input))),2)
> cpio-data := $(ramfs-input)
> -compress-y := shipped
> +compress-y := copy
> endif
>
> endif
> --
> 2.32.0
>
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH v3 10/15] drivers: clk: qcom: gcc-ipq806x: add additional freq for sdc table
From: Ansuel Smith @ 2022-01-25 21:03 UTC (permalink / raw)
To: Stephen Boyd
Cc: Andy Gross, Bjorn Andersson, Michael Turquette, Philipp Zabel,
Rob Herring, Taniya Das, devicetree, linux-arm-msm, linux-clk,
linux-kernel
In-Reply-To: <20220125204555.91DB4C340E0@smtp.kernel.org>
On Tue, Jan 25, 2022 at 12:45:53PM -0800, Stephen Boyd wrote:
> Quoting Ansuel Smith (2022-01-21 13:03:35)
> > Add additional freq supported for the sdc table.
> >
> > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > ---
> > drivers/clk/qcom/gcc-ipq806x.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c
> > index 77bc3d94f580..dbd61e4844b0 100644
> > --- a/drivers/clk/qcom/gcc-ipq806x.c
> > +++ b/drivers/clk/qcom/gcc-ipq806x.c
> > @@ -1292,6 +1292,7 @@ static const struct freq_tbl clk_tbl_sdc[] = {
> > { 20210000, P_PLL8, 1, 1, 19 },
> > { 24000000, P_PLL8, 4, 1, 4 },
> > { 48000000, P_PLL8, 4, 1, 2 },
> > + { 52000000, P_PLL8, 1, 2, 15 }, /* 51.2 Mhz */
>
> Why the comment and fake rate? Can it be 51200000 instead and drop the
> comment?
I will add the related reason in the commit.
We cannot achieve exact 52Mhz(jitter free) clock using PLL8.
As per the MND calculator the closest possible jitter free clock
using PLL8 is 51.2Mhz. This patch adds the values, which will provide
jitter free 51.2Mhz when the requested frequency is 52mhz.
--
Ansuel
^ permalink raw reply
* Re: [PATCH v3 11/15] dt-bindings: clock: add ipq8064 ce5 clk define
From: Ansuel Smith @ 2022-01-25 21:02 UTC (permalink / raw)
To: Stephen Boyd
Cc: Andy Gross, Bjorn Andersson, Michael Turquette, Philipp Zabel,
Rob Herring, Taniya Das, devicetree, linux-arm-msm, linux-clk,
linux-kernel
In-Reply-To: <20220125204727.D3BC8C340E0@smtp.kernel.org>
On Tue, Jan 25, 2022 at 12:47:26PM -0800, Stephen Boyd wrote:
> Quoting Ansuel Smith (2022-01-21 13:03:36)
> > Add ipq8064 ce5 clk define needed for CryptoEngine in gcc driver.
> >
> > Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> > ---
> > include/dt-bindings/clock/qcom,gcc-ipq806x.h | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/dt-bindings/clock/qcom,gcc-ipq806x.h b/include/dt-bindings/clock/qcom,gcc-ipq806x.h
> > index 7deec14a6dee..02262d2ac899 100644
> > --- a/include/dt-bindings/clock/qcom,gcc-ipq806x.h
> > +++ b/include/dt-bindings/clock/qcom,gcc-ipq806x.h
> > @@ -240,7 +240,7 @@
> > #define PLL14 232
> > #define PLL14_VOTE 233
> > #define PLL18 234
> > -#define CE5_SRC 235
> > +#define CE5_A_CLK 235
>
> Technically this is ABI and changing it is bad. I see that CE5_SRC isn't
> used though so I guess it's OK.
>
Consider that this naming comes directly from qsdk so I really don't
know why it was called SRC from the start.
> > #define CE5_H_CLK 236
> > #define CE5_CORE_CLK 237
> > #define CE3_SLEEP_CLK 238
> > @@ -283,5 +283,8 @@
> > #define EBI2_AON_CLK 281
> > #define NSSTCM_CLK_SRC 282
> > #define NSSTCM_CLK 283
> > +#define CE5_A_CLK_SRC 285
> > +#define CE5_H_CLK_SRC 286
> > +#define CE5_CORE_CLK_SRC 287
--
Ansuel
^ permalink raw reply
* [PATCH resend] dt-bindings: leds: common: add disk write/read and usb-host
From: Corentin Labbe @ 2022-01-25 21:02 UTC (permalink / raw)
To: pavel, jacek.anaszewski, linus.walleij, robh+dt
Cc: devicetree, linux-kernel, linux-leds, Corentin Labbe, Rob Herring
The triggers enum misses 3 cases used by gemini DT.
usb-host was added via commit 0cfbd328d60f ("usb: Add LED triggers for USB activity")
so we add also as valid trigger usb-gadget which was added along in this
commit.
disk-read/disk-write were added by commit d1ed7c558612 ("leds: Extends disk trigger for reads and writes")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
This is a resend of the patch since it was not applied for 6 months
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20210508193654.2596119-1-clabbe@baylibre.com/
Documentation/devicetree/bindings/leds/common.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index 697102707703..37f8a6fd6518 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -89,6 +89,8 @@ properties:
- heartbeat
# LED indicates disk activity
- disk-activity
+ - disk-read
+ - disk-write
# LED indicates IDE disk activity (deprecated), in new implementations
# use "disk-activity"
- ide-disk
@@ -97,6 +99,8 @@ properties:
# LED alters the brightness for the specified duration with one software
# timer (requires "led-pattern" property)
- pattern
+ - usb-gadget
+ - usb-host
led-pattern:
description: |
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap
From: Geert Uytterhoeven @ 2022-01-25 20:52 UTC (permalink / raw)
To: Atish Patra
Cc: Atish Patra, Linux Kernel Mailing List, Anup Patel, Albert Ou,
Damien Le Moal,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Jisheng Zhang, Krzysztof Kozlowski, linux-riscv, Palmer Dabbelt,
Paul Walmsley, Rob Herring, Emil Renner Berthing
In-Reply-To: <CAOnJCULjqeL9Q27n=g19ALbOivzid6pc_gYv6JUF4iP=64kJ-Q@mail.gmail.com>
Hi Atish,
On Tue, Jan 25, 2022 at 9:17 PM Atish Patra <atishp@atishpatra.org> wrote:
> On Tue, Jan 25, 2022 at 12:12 PM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Thu, Jan 20, 2022 at 10:12 AM Atish Patra <atishp@rivosinc.com> wrote:
> > > Currently, SBI APIs accept a hartmask that is generated from struct
> > > cpumask. Cpumask data structure can hold upto NR_CPUs value. Thus, it
> > > is not the correct data structure for hartids as it can be higher
> > > than NR_CPUs for platforms with sparse or discontguous hartids.
> > >
> > > Remove all association between hartid mask and struct cpumask.
> > >
> > > Reviewed-by: Anup Patel <anup@brainfault.org> (For Linux RISC-V changes)
> > > Acked-by: Anup Patel <anup@brainfault.org> (For KVM RISC-V changes)
> > > Signed-off-by: Atish Patra <atishp@rivosinc.com>
> >
> > Thanks for your patch, which is now commit 26fb751ca37846c9 ("RISC-V:
> > Do not use cpumask data structure for hartid bitmap") in v5.17-rc1.
> >
> > I am having an issue with random userspace SEGVs on Starlight Beta
> > (which needs out-of-tree patches). It doesn't always manifest
> > itself immediately, so it took a while to bisect, but I suspect the
> > above commit to be the culprit.
>
> I have never seen one before during my testing. How frequently do you see them?
> Does it happen while running anything or just idle user space results
> in SEGVs randomly.
Sometimes they happen during startup (lots of failures from systemd),
sometimes they happen later, during interactive work.
Sometimes while idle, and something runs in the background (e.g. mandb).
> Do you have a trace that I can look into ?
# apt update
[ 807.499050] apt[258]: unhandled signal 11 code 0x1 at
0xffffff8300060020 in libapt-pkg.so.6.0.0[3fa49ac000+174000]
[ 807.509548] CPU: 0 PID: 258 Comm: apt Not tainted
5.16.0-starlight-11192-g26fb751ca378-dirty #153
[ 807.518674] Hardware name: BeagleV Starlight Beta (DT)
[ 807.524077] epc : 0000003fa4a47a0a ra : 0000003fa4a479fc sp :
0000003fcb4b39b0
[ 807.531383] gp : 0000002adcef4800 tp : 0000003fa43287b0 t0 :
0000000000000001
[ 807.538603] t1 : 0000000000000009 t2 : 00000000000003ff s0 :
0000000000000000
[ 807.545887] s1 : 0000002adcf3cb60 a0 : 0000000000000003 a1 :
0000000000000000
[ 807.553167] a2 : 0000003fcb4b3a30 a3 : 0000000000000000 a4 :
0000002adcf3cc1c
[ 807.560390] a5 : 0007000300060000 a6 : 0000000000000003 a7 :
1999999999999999
[ 807.567654] s2 : 0000003fcb4b3a28 s3 : 0000000000000002 s4 :
0000003fcb4b3a30
[ 807.575039] s5 : 0000003fa4baa810 s6 : 0000000000000010 s7 :
0000002adcf19a40
[ 807.582363] s8 : 0000003fcb4b4010 s9 : 0000003fa4baa810 s10:
0000003fcb4b3e90
[ 807.589606] s11: 0000003fa4b2a528 t3 : 0000000000000000 t4 :
0000003fa47906a0
[ 807.596891] t5 : 0000000000000005 t6 : ffffffffffffffff
[ 807.602302] status: 0000000200004020 badaddr: ffffff8300060020
cause: 000000000000000d
(-dirty due to Starlight DTS and driver updates)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 11/15] dt-bindings: clock: add ipq8064 ce5 clk define
From: Stephen Boyd @ 2022-01-25 20:47 UTC (permalink / raw)
To: Andy Gross, Ansuel Smith, Bjorn Andersson, Michael Turquette,
Philipp Zabel, Rob Herring, Taniya Das, devicetree, linux-arm-msm,
linux-clk, linux-kernel
In-Reply-To: <20220121210340.32362-12-ansuelsmth@gmail.com>
Quoting Ansuel Smith (2022-01-21 13:03:36)
> Add ipq8064 ce5 clk define needed for CryptoEngine in gcc driver.
>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
> include/dt-bindings/clock/qcom,gcc-ipq806x.h | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/dt-bindings/clock/qcom,gcc-ipq806x.h b/include/dt-bindings/clock/qcom,gcc-ipq806x.h
> index 7deec14a6dee..02262d2ac899 100644
> --- a/include/dt-bindings/clock/qcom,gcc-ipq806x.h
> +++ b/include/dt-bindings/clock/qcom,gcc-ipq806x.h
> @@ -240,7 +240,7 @@
> #define PLL14 232
> #define PLL14_VOTE 233
> #define PLL18 234
> -#define CE5_SRC 235
> +#define CE5_A_CLK 235
Technically this is ABI and changing it is bad. I see that CE5_SRC isn't
used though so I guess it's OK.
> #define CE5_H_CLK 236
> #define CE5_CORE_CLK 237
> #define CE3_SLEEP_CLK 238
> @@ -283,5 +283,8 @@
> #define EBI2_AON_CLK 281
> #define NSSTCM_CLK_SRC 282
> #define NSSTCM_CLK 283
> +#define CE5_A_CLK_SRC 285
> +#define CE5_H_CLK_SRC 286
> +#define CE5_CORE_CLK_SRC 287
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox