[PATCH AUTOSEL 4.14 7/7] tracing: relax trace_event_eval_update() execution with cond_resched()
From: Clément Léger [ Upstream commit 23cce5f25491968b23fb9c399bbfb25f13870cd9 ] When kernel is compiled without preemption, the eval_map_work_func() (which calls trace_event_eval_update()) will not be preempted up to its complete execution. This can actually cause a problem since if another CPU call stop_machine(), the call will have to wait for the eval_map_work_func() function to finish executing in the workqueue before being able to be scheduled. This problem was observe on a SMP system at boot time, when the CPU calling the initcalls executed clocksource_done_booting() which in the end calls stop_machine(). We observed a 1 second delay because one CPU was executing eval_map_work_func() and was not preempted by the stop_machine() task. Adding a call to cond_resched() in trace_event_eval_update() allows other tasks to be executed and thus continue working asynchronously like before without blocking any pending task at boot time. Link: https://lore.kernel.org/linux-trace-kernel/20230929191637.416931-1-cle...@rivosinc.com Cc: Masami Hiramatsu Signed-off-by: Clément Léger Tested-by: Atish Patra Reviewed-by: Atish Patra Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin --- kernel/trace/trace_events.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 37be6913cfb27..f29552b009c80 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2240,6 +2240,7 @@ void trace_event_eval_update(struct trace_eval_map **map, int len) update_event_printk(call, map[i]); } } + cond_resched(); } up_write(_event_sem); } -- 2.40.1
[PATCH AUTOSEL 4.19 8/8] tracing: relax trace_event_eval_update() execution with cond_resched()
From: Clément Léger [ Upstream commit 23cce5f25491968b23fb9c399bbfb25f13870cd9 ] When kernel is compiled without preemption, the eval_map_work_func() (which calls trace_event_eval_update()) will not be preempted up to its complete execution. This can actually cause a problem since if another CPU call stop_machine(), the call will have to wait for the eval_map_work_func() function to finish executing in the workqueue before being able to be scheduled. This problem was observe on a SMP system at boot time, when the CPU calling the initcalls executed clocksource_done_booting() which in the end calls stop_machine(). We observed a 1 second delay because one CPU was executing eval_map_work_func() and was not preempted by the stop_machine() task. Adding a call to cond_resched() in trace_event_eval_update() allows other tasks to be executed and thus continue working asynchronously like before without blocking any pending task at boot time. Link: https://lore.kernel.org/linux-trace-kernel/20230929191637.416931-1-cle...@rivosinc.com Cc: Masami Hiramatsu Signed-off-by: Clément Léger Tested-by: Atish Patra Reviewed-by: Atish Patra Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin --- kernel/trace/trace_events.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index a3dc6c126b3ee..ed39d3ec202e6 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2242,6 +2242,7 @@ void trace_event_eval_update(struct trace_eval_map **map, int len) update_event_printk(call, map[i]); } } + cond_resched(); } up_write(_event_sem); } -- 2.40.1
[PATCH AUTOSEL 5.4 8/8] tracing: relax trace_event_eval_update() execution with cond_resched()
From: Clément Léger [ Upstream commit 23cce5f25491968b23fb9c399bbfb25f13870cd9 ] When kernel is compiled without preemption, the eval_map_work_func() (which calls trace_event_eval_update()) will not be preempted up to its complete execution. This can actually cause a problem since if another CPU call stop_machine(), the call will have to wait for the eval_map_work_func() function to finish executing in the workqueue before being able to be scheduled. This problem was observe on a SMP system at boot time, when the CPU calling the initcalls executed clocksource_done_booting() which in the end calls stop_machine(). We observed a 1 second delay because one CPU was executing eval_map_work_func() and was not preempted by the stop_machine() task. Adding a call to cond_resched() in trace_event_eval_update() allows other tasks to be executed and thus continue working asynchronously like before without blocking any pending task at boot time. Link: https://lore.kernel.org/linux-trace-kernel/20230929191637.416931-1-cle...@rivosinc.com Cc: Masami Hiramatsu Signed-off-by: Clément Léger Tested-by: Atish Patra Reviewed-by: Atish Patra Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin --- kernel/trace/trace_events.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 0c21da12b650c..09fb9b0e38d75 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2234,6 +2234,7 @@ void trace_event_eval_update(struct trace_eval_map **map, int len) update_event_printk(call, map[i]); } } + cond_resched(); } up_write(_event_sem); } -- 2.40.1
[PATCH AUTOSEL 5.10 8/8] tracing: relax trace_event_eval_update() execution with cond_resched()
From: Clément Léger [ Upstream commit 23cce5f25491968b23fb9c399bbfb25f13870cd9 ] When kernel is compiled without preemption, the eval_map_work_func() (which calls trace_event_eval_update()) will not be preempted up to its complete execution. This can actually cause a problem since if another CPU call stop_machine(), the call will have to wait for the eval_map_work_func() function to finish executing in the workqueue before being able to be scheduled. This problem was observe on a SMP system at boot time, when the CPU calling the initcalls executed clocksource_done_booting() which in the end calls stop_machine(). We observed a 1 second delay because one CPU was executing eval_map_work_func() and was not preempted by the stop_machine() task. Adding a call to cond_resched() in trace_event_eval_update() allows other tasks to be executed and thus continue working asynchronously like before without blocking any pending task at boot time. Link: https://lore.kernel.org/linux-trace-kernel/20230929191637.416931-1-cle...@rivosinc.com Cc: Masami Hiramatsu Signed-off-by: Clément Léger Tested-by: Atish Patra Reviewed-by: Atish Patra Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin --- kernel/trace/trace_events.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index a46d34d840f69..1221b11ea0098 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2449,6 +2449,7 @@ void trace_event_eval_update(struct trace_eval_map **map, int len) update_event_printk(call, map[i]); } } + cond_resched(); } up_write(_event_sem); } -- 2.40.1
[PATCH AUTOSEL 5.15 10/10] tracing: relax trace_event_eval_update() execution with cond_resched()
From: Clément Léger [ Upstream commit 23cce5f25491968b23fb9c399bbfb25f13870cd9 ] When kernel is compiled without preemption, the eval_map_work_func() (which calls trace_event_eval_update()) will not be preempted up to its complete execution. This can actually cause a problem since if another CPU call stop_machine(), the call will have to wait for the eval_map_work_func() function to finish executing in the workqueue before being able to be scheduled. This problem was observe on a SMP system at boot time, when the CPU calling the initcalls executed clocksource_done_booting() which in the end calls stop_machine(). We observed a 1 second delay because one CPU was executing eval_map_work_func() and was not preempted by the stop_machine() task. Adding a call to cond_resched() in trace_event_eval_update() allows other tasks to be executed and thus continue working asynchronously like before without blocking any pending task at boot time. Link: https://lore.kernel.org/linux-trace-kernel/20230929191637.416931-1-cle...@rivosinc.com Cc: Masami Hiramatsu Signed-off-by: Clément Léger Tested-by: Atish Patra Reviewed-by: Atish Patra Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin --- kernel/trace/trace_events.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 2a2a57671..e6aef0066ccb8 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2751,6 +2751,7 @@ void trace_event_eval_update(struct trace_eval_map **map, int len) update_event_fields(call, map[i]); } } + cond_resched(); } up_write(_event_sem); } -- 2.40.1
[PATCH AUTOSEL 6.1 12/12] tracing: relax trace_event_eval_update() execution with cond_resched()
From: Clément Léger [ Upstream commit 23cce5f25491968b23fb9c399bbfb25f13870cd9 ] When kernel is compiled without preemption, the eval_map_work_func() (which calls trace_event_eval_update()) will not be preempted up to its complete execution. This can actually cause a problem since if another CPU call stop_machine(), the call will have to wait for the eval_map_work_func() function to finish executing in the workqueue before being able to be scheduled. This problem was observe on a SMP system at boot time, when the CPU calling the initcalls executed clocksource_done_booting() which in the end calls stop_machine(). We observed a 1 second delay because one CPU was executing eval_map_work_func() and was not preempted by the stop_machine() task. Adding a call to cond_resched() in trace_event_eval_update() allows other tasks to be executed and thus continue working asynchronously like before without blocking any pending task at boot time. Link: https://lore.kernel.org/linux-trace-kernel/20230929191637.416931-1-cle...@rivosinc.com Cc: Masami Hiramatsu Signed-off-by: Clément Léger Tested-by: Atish Patra Reviewed-by: Atish Patra Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin --- kernel/trace/trace_events.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 9da418442a063..2e3dce5e2575e 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2777,6 +2777,7 @@ void trace_event_eval_update(struct trace_eval_map **map, int len) update_event_fields(call, map[i]); } } + cond_resched(); } up_write(_event_sem); } -- 2.40.1
[PATCH AUTOSEL 6.5 18/18] tracing: relax trace_event_eval_update() execution with cond_resched()
From: Clément Léger [ Upstream commit 23cce5f25491968b23fb9c399bbfb25f13870cd9 ] When kernel is compiled without preemption, the eval_map_work_func() (which calls trace_event_eval_update()) will not be preempted up to its complete execution. This can actually cause a problem since if another CPU call stop_machine(), the call will have to wait for the eval_map_work_func() function to finish executing in the workqueue before being able to be scheduled. This problem was observe on a SMP system at boot time, when the CPU calling the initcalls executed clocksource_done_booting() which in the end calls stop_machine(). We observed a 1 second delay because one CPU was executing eval_map_work_func() and was not preempted by the stop_machine() task. Adding a call to cond_resched() in trace_event_eval_update() allows other tasks to be executed and thus continue working asynchronously like before without blocking any pending task at boot time. Link: https://lore.kernel.org/linux-trace-kernel/20230929191637.416931-1-cle...@rivosinc.com Cc: Masami Hiramatsu Signed-off-by: Clément Léger Tested-by: Atish Patra Reviewed-by: Atish Patra Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin --- kernel/trace/trace_events.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 0cf84a7449f5b..9841589b4af7f 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2777,6 +2777,7 @@ void trace_event_eval_update(struct trace_eval_map **map, int len) update_event_fields(call, map[i]); } } + cond_resched(); } up_write(_event_sem); } -- 2.40.1
Re: [PATCH] [v4] ieee802154: ca8210: Fix a potential UAF in ca8210_probe
Hello.
On 07.10.23 05:30, Dinghao Liu wrote:
If of_clk_add_provider() fails in ca8210_register_ext_clock(),
it calls clk_unregister() to release priv->clk and returns an
error. However, the caller ca8210_probe() then calls ca8210_remove(),
where priv->clk is freed again in ca8210_unregister_ext_clock(). In
this case, a use-after-free may happen in the second time we call
clk_unregister().
Fix this by removing the first clk_unregister(). Also, priv->clk could
be an error code on failure of clk_register_fixed_rate(). Use
IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().
Fixes: ded845a781a5 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver")
Signed-off-by: Dinghao Liu
---
Changelog:
v2: -Remove the first clk_unregister() instead of nulling priv->clk.
v3: -Simplify ca8210_register_ext_clock().
-Add a ';' after return in ca8210_unregister_ext_clock().
v4: -Remove an unused variable 'ret'.
This patch has been applied to the wpan tree and will be
part of the next pull request to net. Thanks!
regards
Stefan Schmidt
Re: [PATCH v1] samples: kprobes: Fixes a typo
On Sat, Sep 23, 2023 at 11:00:46PM +0530, Atul Kumar Pant wrote:
> On Thu, Aug 17, 2023 at 10:38:19PM +0530, Atul Kumar Pant wrote:
> > Fixes typo in a function name.
> >
> > Signed-off-by: Atul Kumar Pant
> > ---
> > samples/kprobes/kretprobe_example.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/samples/kprobes/kretprobe_example.c
> > b/samples/kprobes/kretprobe_example.c
> > index cbf16542d84e..ed79fd3d48fb 100644
> > --- a/samples/kprobes/kretprobe_example.c
> > +++ b/samples/kprobes/kretprobe_example.c
> > @@ -35,7 +35,7 @@ struct my_data {
> > ktime_t entry_stamp;
> > };
> >
> > -/* Here we use the entry_hanlder to timestamp function entry */
> > +/* Here we use the entry_handler to timestamp function entry */
> > static int entry_handler(struct kretprobe_instance *ri, struct pt_regs
> > *regs)
> > {
> > struct my_data *data;
> > --
> > 2.25.1
> >
>
> Hi all, can someone provide comments on this change.
Hi all, can someone please review this change. It has
been not
reviewed for quite some time.
[PATCH 7/7] arm64: dts: qcom: Add support for Xiaomi Redmi Note 9S
From: Joe Mason
Add a device tree for the Xiaomi Redmi Note 9S (curtana) phone, based on
sm7125-xiaomi-common.dtsi.
Signed-off-by: Joe Mason
Signed-off-by: David Wronek
---
arch/arm64/boot/dts/qcom/Makefile| 1 +
.../boot/dts/qcom/sm7125-xiaomi-curtana.dts | 16
2 files changed, 17 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sm7125-xiaomi-curtana.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index d6cb840b7050..57974fb0c580 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -207,6 +207,7 @@ dtb-$(CONFIG_ARCH_QCOM) +=
sm6125-sony-xperia-seine-pdx201.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm6125-xiaomi-laurel-sprout.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm6350-sony-xperia-lena-pdx213.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm6375-sony-xperia-murray-pdx225.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sm7125-xiaomi-curtana.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm7125-xiaomi-joyeuse.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm7225-fairphone-fp4.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8150-hdk.dtb
diff --git a/arch/arm64/boot/dts/qcom/sm7125-xiaomi-curtana.dts
b/arch/arm64/boot/dts/qcom/sm7125-xiaomi-curtana.dts
new file mode 100644
index ..12f517a8492c
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm7125-xiaomi-curtana.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023, Joe Mason
+ */
+
+/dts-v1/;
+
+#include "sm7125-xiaomi-common.dtsi"
+
+/ {
+ model = "Xiaomi Redmi Note 9S";
+ compatible = "xiaomi,curtana", "qcom,sm7125";
+
+ /* required for bootloader to select correct board */
+ qcom,board-id = <0x20022 1>;
+};
--
2.42.0
[PATCH 6/7] arm64: dts: qcom: sm7125-xiaomi-common: Add UFS nodes
Enable the UFS found on the SM7125 Xiaomi smartphones.
Signed-off-by: David Wronek
---
.../boot/dts/qcom/sm7125-xiaomi-common.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm7125-xiaomi-common.dtsi
b/arch/arm64/boot/dts/qcom/sm7125-xiaomi-common.dtsi
index e55cd83c19b8..22ad8a25217e 100644
--- a/arch/arm64/boot/dts/qcom/sm7125-xiaomi-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm7125-xiaomi-common.dtsi
@@ -398,6 +398,22 @@ sd-cd-pins {
};
};
+_mem_hc {
+ vcc-supply = <_l19a_3p0>;
+ vcc-max-microamp = <60>;
+ vccq2-supply = <_l12a_1p8>;
+ vccq2-max-microamp = <60>;
+ status = "okay";
+};
+
+_mem_phy {
+ vdda-phy-supply = <_l4a_0p88>;
+ vdda-pll-supply = <_l3c_1p23>;
+ vdda-phy-max-microamp = <62900>;
+ vdda-pll-max-microamp = <18300>;
+ status = "okay";
+};
+
_1 {
qcom,select-utmi-as-pipe-clk;
status = "okay";
--
2.42.0
[PATCH 5/7] arm64: dts: qcom: sc7180: Add UFS nodes
Add the UFS and QMP PHY nodes for the Qualcomm SC7180 SoC.
Signed-off-by: David Wronek
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 70
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 11f353d416b4..9f18be4fd61a 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -1532,6 +1532,76 @@ mmss_noc: interconnect@174 {
qcom,bcm-voters = <_bcm_voter>;
};
+ ufs_mem_hc: ufshc@1d84000 {
+ compatible = "qcom,sc7180-ufshc", "qcom,ufshc",
+"jedec,ufs-2.0";
+ reg = <0 0x01d84000 0 0x3000>,
+ <0 0x01d9 0 0x8000>;
+ reg-names = "std", "ice";
+ interrupts = ;
+ phys = <_mem_phy>;
+ phy-names = "ufsphy";
+ lanes-per-direction = <1>;
+ power-domains = < UFS_PHY_GDSC>;
+ #reset-cells = <1>;
+ resets = < GCC_UFS_PHY_BCR>;
+ reset-names = "rst";
+
+ iommus = <_smmu 0xa0 0x0>;
+
+ clock-names =
+ "core_clk",
+ "bus_aggr_clk",
+ "iface_clk",
+ "core_clk_unipro",
+ "ref_clk",
+ "tx_lane0_sync_clk",
+ "rx_lane0_sync_clk",
+ "ice_core_clk";
+ clocks =
+ < GCC_UFS_PHY_AXI_CLK>,
+ < GCC_AGGRE_UFS_PHY_AXI_CLK>,
+ < GCC_UFS_PHY_AHB_CLK>,
+ < GCC_UFS_PHY_UNIPRO_CORE_CLK>,
+ < RPMH_CXO_CLK>,
+ < GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
+ < GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
+ < GCC_UFS_PHY_ICE_CORE_CLK>;
+ freq-table-hz =
+ <5000 2>,
+ <0 0>,
+ <0 0>,
+ <3750 15000>,
+ <0 0>,
+ <0 0>,
+ <0 0>,
+ <0 3>;
+
+ interconnects = <_noc MASTER_UFS_MEM 0 _virt
SLAVE_EBI1 0>,
+ <_noc MASTER_APPSS_PROC 0 _noc
SLAVE_UFS_MEM_CFG 0>;
+ interconnect-names = "ufs-ddr", "cpu-ufs";
+
+ status = "disabled";
+ };
+
+ ufs_mem_phy: phy@1d87000 {
+ compatible = "qcom,sc7180-qmp-ufs-phy";
+ reg = <0 0x01d87000 0 0x1000>;
+
+ clocks = < GCC_UFS_MEM_CLKREF_CLK>,
+ < GCC_UFS_PHY_PHY_AUX_CLK>;
+ clock-names = "ref", "ref_aux";
+
+ power-domains = < UFS_PHY_GDSC>;
+
+ resets = <_mem_hc 0>;
+ reset-names = "ufsphy";
+
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
ipa: ipa@1e4 {
compatible = "qcom,sc7180-ipa";
--
2.42.0
[PATCH 4/7] phy: qcom: qmp-ufs: Add SC7180 support
The SC7180 UFS PHY is identical to the one found on SM7150. Add a
compatible for it.
Signed-off-by: David Wronek
---
drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
index 514fa14df634..1919b8bf5a85 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
@@ -1787,6 +1787,9 @@ static const struct of_device_id qmp_ufs_of_match_table[]
= {
}, {
.compatible = "qcom,sa8775p-qmp-ufs-phy",
.data = _ufsphy_cfg,
+ }, {
+ .compatible = "qcom,sc7180-qmp-ufs-phy",
+ .data = _ufsphy_cfg,
}, {
.compatible = "qcom,sc7280-qmp-ufs-phy",
.data = _ufsphy_cfg,
--
2.42.0
[PATCH 3/7] dt-bindings: arm: qcom: Add Xiaomi Redmi Note 9S
Document the Xiaomi Redmi Note 9S (curtana) smartphone, which is based on the Qualcomm SM7125 SoC. Signed-off-by: David Wronek --- Documentation/devicetree/bindings/arm/qcom.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 7f80f48a0954..42461b0f19a1 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -984,6 +984,7 @@ properties: - items: - enum: + - xiaomi,curtana - xiaomi,joyeuse - const: qcom,sm7125 -- 2.42.0
[PATCH 2/7] dt-bindings: phy: Add QMP UFS PHY compatible for SC7180
Document the QMP UFS PHY compatible for SC7180 Signed-off-by: David Wronek --- .../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml index f3a3296c811c..f2eee8b5326f 100644 --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml @@ -19,6 +19,7 @@ properties: - qcom,msm8996-qmp-ufs-phy - qcom,msm8998-qmp-ufs-phy - qcom,sa8775p-qmp-ufs-phy + - qcom,sc7180-qmp-ufs-phy - qcom,sc7280-qmp-ufs-phy - qcom,sc8180x-qmp-ufs-phy - qcom,sc8280xp-qmp-ufs-phy -- 2.42.0
[PATCH 0/7] Add UFS support for SC7180/SM7125
This patchset introduces UFS storage support for SC7180 and SM7125, as well as support for the Xiaomi Redmi Note 9S. David Wronek (6): dt-bindings: ufs: qcom: Add SC7180 compatible string dt-bindings: phy: Add QMP UFS PHY compatible for SC7180 dt-bindings: arm: qcom: Add Xiaomi Redmi Note 9S phy: qcom: qmp-ufs: Add SC7180 support arm64: dts: qcom: sc7180: Add UFS nodes arm64: dts: qcom: sm7125-xiaomi-common: Add UFS nodes Joe Mason (1): arm64: dts: qcom: Add support for Xiaomi Redmi Note 9S .../devicetree/bindings/arm/qcom.yaml | 1 + .../phy/qcom,sc8280xp-qmp-ufs-phy.yaml| 1 + .../devicetree/bindings/ufs/qcom,ufs.yaml | 2 + arch/arm64/boot/dts/qcom/Makefile | 1 + arch/arm64/boot/dts/qcom/sc7180.dtsi | 70 +++ .../boot/dts/qcom/sm7125-xiaomi-common.dtsi | 16 + .../boot/dts/qcom/sm7125-xiaomi-curtana.dts | 16 + drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 3 + 8 files changed, 110 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/sm7125-xiaomi-curtana.dts -- 2.42.0
[PATCH 1/7] dt-bindings: ufs: qcom: Add SC7180 compatible string
Document the compatible for the UFS found on SC7180. Signed-off-by: David Wronek --- Documentation/devicetree/bindings/ufs/qcom,ufs.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml index 462ead5a1cec..f99a933cc217 100644 --- a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml @@ -27,6 +27,7 @@ properties: - qcom,msm8996-ufshc - qcom,msm8998-ufshc - qcom,sa8775p-ufshc + - qcom,sc7180-ufshc - qcom,sc8280xp-ufshc - qcom,sdm845-ufshc - qcom,sm6115-ufshc @@ -210,6 +211,7 @@ allOf: compatible: contains: enum: + - qcom,sc7180-ufshc - qcom,sm6115-ufshc then: properties: -- 2.42.0
Re: [PATCH v4] eventfs: Remove eventfs_file and just use eventfs_inode
On Tue, 3 Oct 2023 18:40:59 -0400
Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Instead of having a descriptor for every file represented in the eventfs
> directory, only have the directory itself represented. Change the API to
> send in a list of entries that represent all the files in the directory
> (but not other directories). The entry list contains a name and a callback
> function that will be used to create the files when they are accessed.
>
> struct eventfs_inode *eventfs_create_events_dir(const char *name, struct
> dentry *parent,
> const struct eventfs_entry
> *entries,
> int size, void *data);
>
> is used for the top level eventfs directory, and returns an eventfs_inode
> that will be used by:
>
> struct eventfs_inode *eventfs_create_dir(const char *name, struct
> eventfs_inode *parent,
>const struct eventfs_entry *entries,
>int size, void *data);
>
> where both of the above take an array of struct eventfs_entry entries for
> every file that is in the directory.
>
> The entries are defined by:
>
> typedef int (*eventfs_callback)(const char *name, umode_t *mode, void **data,
> const struct file_operations **fops);
>
> struct eventfs_entry {
> const char *name;
> eventfs_callbackcallback;
> };
>
> Where the name is the name of the file and the callback gets called when
> the file is being created. The callback passes in the name (in case the
> same callback is used for multiple files), a pointer to the mode, data and
> fops. The data will be pointing to the data that was passed in
> eventfs_create_dir() or eventfs_create_events_dir() but may be overridden
> to point to something else, as it will be used to point to the
> inode->i_private that is created. The information passed back from the
> callback is used to create the dentry/inode.
>
> If the callback fills the data and the file should be created, it must
> return a positive number. On zero or negative, the file is ignored.
>
> This logic may also be used as a prototype to convert entire pseudo file
> systems into just-in-time allocation.
>
> The "show_events_dentry" file has been updated to show the directories,
> and any files they have.
>
> With just the eventfs_file allocations:
>
> Before after deltas for meminfo (in kB):
>
>MemFree: -14360
>MemAvailable: -14260
>Buffers: 40
>Cached:24
>Active:44
>Inactive: 48
>Inactive(anon):28
>Active(file): 44
>Inactive(file):20
>Dirty: -4
>AnonPages: 28
>Mapped:4
>KReclaimable: 132
>Slab: 1604
>SReclaimable: 132
>SUnreclaim:1472
>Committed_AS: 12
>
> Before after deltas for slabinfo:
>
>: [ * = ]
>
>ext4_inode_cache 27 [* 1184 = 31968 ]
>extent_status 102 [* 40 = 4080 ]
>tracefs_inode_cache144 [* 656 = 94464 ]
>buffer_head39 [* 104 = 4056 ]
>shmem_inode_cache 49 [* 800 = 39200 ]
>filp -53 [* 256 = -13568 ]
>dentry 251 [* 192 = 48192 ]
>lsm_file_cache 277 [* 32 = 8864 ]
>vm_area_struct -14 [* 184 = -2576 ]
>trace_event_file 1748[* 88 = 153824 ]
>kmalloc-1k 35 [* 1024 = 35840 ]
>kmalloc-25649 [* 256 = 12544 ]
>kmalloc-192-28 [* 192 = -5376 ]
>kmalloc-128-30 [* 128 = -3840 ]
>kmalloc-96 10581 [* 96 = 1015776 ]
>kmalloc-64 3056[* 64 = 195584 ]
>kmalloc-32 1291[* 32 = 41312 ]
>kmalloc-16 2310[* 16 = 36960 ]
>kmalloc-8 9216[*8 = 73728 ]
>
> Free memory dropped by 14,360 kB
> Available memory dropped by 14,260 kB
> Total slab additions in size: 1,771,032 bytes
>
> With this change:
>
> Before after deltas for meminfo (in kB):
>
>MemFree: -12084
>MemAvailable: -11976
>Buffers: 32
>Cached:32
>Active:72
>Inactive: 168
>Inactive(anon):176
>Active(file): 72
>Inactive(file):-8
>Dirty: 24
>AnonPages: 196
>Mapped:8
>KReclaimable: 148
>Slab: 836
>SReclaimable: 148
>SUnreclaim:688
>Committed_AS: 324
>
> Before after deltas for slabinfo:
>
>: [ * = ]
>
>
Re: [PATCH v2 3/6] ACPI: AC: Replace acpi_driver with platform_driver
On Sat, Oct 7, 2023 at 12:41 PM Rafael J. Wysocki wrote:
>
> On Sat, Oct 7, 2023 at 9:56 AM Andy Shevchenko
> wrote:
> >
> > On Fri, Oct 06, 2023 at 09:47:57PM +0200, Rafael J. Wysocki wrote:
> > > On Fri, Oct 6, 2023 at 8:33 PM Michal Wilczynski
> > > wrote:
> >
> > ...
> >
> > > > struct acpi_ac {
> > > > struct power_supply *charger;
> > > > struct power_supply_desc charger_desc;
> > > > - struct acpi_device *device;
> > > > + struct device *dev;
> > >
> > > I'm not convinced about this change.
> > >
> > > If I'm not mistaken, you only use the dev pointer above to get the
> > > ACPI_COMPANION() of it, but the latter is already found in _probe(),
> > > so it can be stored in struct acpi_ac for later use and then the dev
> > > pointer in there will not be necessary any more.
> > >
> > > That will save you a bunch of ACPI_HANDLE() evaluations and there's
> > > nothing wrong with using ac->device->handle. The patch will then
> > > become almost trivial AFAICS and if you really need to get from ac to
> > > the underlying platform device, a pointer to it can be added to struct
> > > acpi_ac without removing the ACPI device pointer from it.
> >
> > The idea behind is to eliminate data duplication.
>
> What data duplication exactly do you mean?
>
> struct acpi_device *device is replaced with struct device *dev which
> is the same size. The latter is then used to obtain a struct
> acpi_device pointer. Why is it better to do this than to store the
> struct acpi_device itself?
This should be "store the struct acpi_device pointer itself", sorry.
Re: [PATCH v2 3/6] ACPI: AC: Replace acpi_driver with platform_driver
On Sat, Oct 7, 2023 at 9:56 AM Andy Shevchenko
wrote:
>
> On Fri, Oct 06, 2023 at 09:47:57PM +0200, Rafael J. Wysocki wrote:
> > On Fri, Oct 6, 2023 at 8:33 PM Michal Wilczynski
> > wrote:
>
> ...
>
> > > struct acpi_ac {
> > > struct power_supply *charger;
> > > struct power_supply_desc charger_desc;
> > > - struct acpi_device *device;
> > > + struct device *dev;
> >
> > I'm not convinced about this change.
> >
> > If I'm not mistaken, you only use the dev pointer above to get the
> > ACPI_COMPANION() of it, but the latter is already found in _probe(),
> > so it can be stored in struct acpi_ac for later use and then the dev
> > pointer in there will not be necessary any more.
> >
> > That will save you a bunch of ACPI_HANDLE() evaluations and there's
> > nothing wrong with using ac->device->handle. The patch will then
> > become almost trivial AFAICS and if you really need to get from ac to
> > the underlying platform device, a pointer to it can be added to struct
> > acpi_ac without removing the ACPI device pointer from it.
>
> The idea behind is to eliminate data duplication.
What data duplication exactly do you mean?
struct acpi_device *device is replaced with struct device *dev which
is the same size. The latter is then used to obtain a struct
acpi_device pointer. Why is it better to do this than to store the
struct acpi_device itself?
Re: [PATCH v5 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks
Vishal Verma writes:
> The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is restricted to
> 'memblock_size' chunks of memory being added. Adding a larger span of
> memory precludes memmap_on_memory semantics.
>
> For users of hotplug such as kmem, large amounts of memory might get
> added from the CXL subsystem. In some cases, this amount may exceed the
> available 'main memory' to store the memmap for the memory being added.
> In this case, it is useful to have a way to place the memmap on the
> memory being added, even if it means splitting the addition into
> memblock-sized chunks.
>
> Change add_memory_resource() to loop over memblock-sized chunks of
> memory if caller requested memmap_on_memory, and if other conditions for
> it are met. Teach try_remove_memory() to also expect that a memory
> range being removed might have been split up into memblock sized chunks,
> and to loop through those as needed.
>
> Cc: Andrew Morton
> Cc: David Hildenbrand
> Cc: Michal Hocko
> Cc: Oscar Salvador
> Cc: Dan Williams
> Cc: Dave Jiang
> Cc: Dave Hansen
> Cc: Huang Ying
> Suggested-by: David Hildenbrand
> Signed-off-by: Vishal Verma
> ---
> mm/memory_hotplug.c | 162
>
> 1 file changed, 99 insertions(+), 63 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index f8d3e7427e32..77ec6f15f943 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1380,6 +1380,44 @@ static bool mhp_supports_memmap_on_memory(unsigned
> long size)
> return arch_supports_memmap_on_memory(vmemmap_size);
> }
>
> +static int add_memory_create_devices(int nid, struct memory_group *group,
> + u64 start, u64 size, mhp_t mhp_flags)
> +{
> + struct mhp_params params = { .pgprot = pgprot_mhp(PAGE_KERNEL) };
> + struct vmem_altmap mhp_altmap = {
> + .base_pfn = PHYS_PFN(start),
> + .end_pfn = PHYS_PFN(start + size - 1),
> + };
> + int ret;
> +
> + if ((mhp_flags & MHP_MEMMAP_ON_MEMORY)) {
> + mhp_altmap.free = memory_block_memmap_on_memory_pages();
> + params.altmap = kmalloc(sizeof(struct vmem_altmap), GFP_KERNEL);
> + if (!params.altmap)
> + return -ENOMEM;
> +
> + memcpy(params.altmap, _altmap, sizeof(mhp_altmap));
> + }
> +
> + /* call arch's memory hotadd */
> + ret = arch_add_memory(nid, start, size, );
> + if (ret < 0)
> + goto error;
> +
> + /* create memory block devices after memory was added */
> + ret = create_memory_block_devices(start, size, params.altmap, group);
> + if (ret)
> + goto err_bdev;
> +
> + return 0;
> +
> +err_bdev:
> + arch_remove_memory(start, size, NULL);
> +error:
> + kfree(params.altmap);
> + return ret;
> +}
> +
> /*
> * NOTE: The caller must call lock_device_hotplug() to serialize hotplug
> * and online/offline operations (triggered e.g. by sysfs).
> @@ -1388,14 +1426,10 @@ static bool mhp_supports_memmap_on_memory(unsigned
> long size)
> */
> int __ref add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)
> {
> - struct mhp_params params = { .pgprot = pgprot_mhp(PAGE_KERNEL) };
> + unsigned long memblock_size = memory_block_size_bytes();
> enum memblock_flags memblock_flags = MEMBLOCK_NONE;
> - struct vmem_altmap mhp_altmap = {
> - .base_pfn = PHYS_PFN(res->start),
> - .end_pfn = PHYS_PFN(res->end),
> - };
> struct memory_group *group = NULL;
> - u64 start, size;
> + u64 start, size, cur_start;
> bool new_node = false;
> int ret;
>
> @@ -1436,28 +1470,21 @@ int __ref add_memory_resource(int nid, struct
> resource *res, mhp_t mhp_flags)
> /*
>* Self hosted memmap array
>*/
> - if (mhp_flags & MHP_MEMMAP_ON_MEMORY) {
> - if (mhp_supports_memmap_on_memory(size)) {
> - mhp_altmap.free = memory_block_memmap_on_memory_pages();
> - params.altmap = kmalloc(sizeof(struct vmem_altmap),
> GFP_KERNEL);
> - if (!params.altmap)
> + if ((mhp_flags & MHP_MEMMAP_ON_MEMORY) &&
> + mhp_supports_memmap_on_memory(memblock_size)) {
> + for (cur_start = start; cur_start < start + size;
> + cur_start += memblock_size) {
> + ret = add_memory_create_devices(nid, group, cur_start,
> + memblock_size,
> + mhp_flags);
> + if (ret)
> goto error;
> -
> - memcpy(params.altmap, _altmap, sizeof(mhp_altmap));
> }
> - /* fallback to not using altmap */
> - }
> -
> - /* call arch's memory hotadd */
> - ret = arch_add_memory(nid, start, size, );
> - if
Re: [PATCH v2 3/6] ACPI: AC: Replace acpi_driver with platform_driver
On Fri, Oct 06, 2023 at 09:47:57PM +0200, Rafael J. Wysocki wrote:
> On Fri, Oct 6, 2023 at 8:33 PM Michal Wilczynski
> wrote:
...
> > struct acpi_ac {
> > struct power_supply *charger;
> > struct power_supply_desc charger_desc;
> > - struct acpi_device *device;
> > + struct device *dev;
>
> I'm not convinced about this change.
>
> If I'm not mistaken, you only use the dev pointer above to get the
> ACPI_COMPANION() of it, but the latter is already found in _probe(),
> so it can be stored in struct acpi_ac for later use and then the dev
> pointer in there will not be necessary any more.
>
> That will save you a bunch of ACPI_HANDLE() evaluations and there's
> nothing wrong with using ac->device->handle. The patch will then
> become almost trivial AFAICS and if you really need to get from ac to
> the underlying platform device, a pointer to it can be added to struct
> acpi_ac without removing the ACPI device pointer from it.
The idea behind is to eliminate data duplication.
> > unsigned long long state;
> > struct notifier_block battery_nb;
> > };
--
With Best Regards,
Andy Shevchenko
