* Re: [PATCH v6 1/6] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Varadarajan Narayanan @ 2024-04-03 10:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: andersson, konrad.dybcio, mturquette, sboyd, robh,
krzysztof.kozlowski+dt, conor+dt, djakov, dmitry.baryshkov,
quic_anusha, linux-arm-msm, linux-clk, devicetree, linux-kernel,
linux-pm
In-Reply-To: <1a6fccd3-452c-423f-b73e-cef5f9d01633@linaro.org>
On Wed, Apr 03, 2024 at 09:09:15AM +0200, Krzysztof Kozlowski wrote:
> On 02/04/2024 12:34, Varadarajan Narayanan wrote:
> > +#define ICC_NSSNOC_NSSCC 10
> > +#define ICC_NSSNOC_SNOC_0 11
> > +#define ICC_NSSNOC_SNOC_1 12
> > +#define ICC_NSSNOC_PCNOC_1 13
> > +#define ICC_NSSNOC_QOSGEN_REF 14
> > +#define ICC_NSSNOC_TIMEOUT_REF 15
> > +#define ICC_NSSNOC_XO_DCD 16
> > +#define ICC_NSSNOC_ATB 17
> > +#define ICC_MEM_NOC_NSSNOC 18
> > +#define ICC_NSSNOC_MEMNOC 19
> > +#define ICC_NSSNOC_MEM_NOC_1 20
> > +
> > +#define ICC_NSSNOC_PPE 0
> > +#define ICC_NSSNOC_PPE_CFG 1
> > +#define ICC_NSSNOC_NSS_CSR 2
> > +#define ICC_NSSNOC_IMEM_QSB 3
> > +#define ICC_NSSNOC_IMEM_AHB 4
> > +
> > +#define MASTER(x) ((ICC_ ## x) * 2)
> > +#define SLAVE(x) (MASTER(x) + 1)
>
> You already received comment to make your bindings consistent with other
> Qualcomm bindings. Now you repeat the same mistake.
>
> No, that is neither consistent nor greppble.
Sorry. Have restored the naming and posted v7.
Kindly take a look.
Thanks
Varada
^ permalink raw reply
* [PATCH v7 5/5] arm64: dts: qcom: ipq9574: Add icc provider ability to gcc
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-1-quic_varada@quicinc.com>
IPQ SoCs dont involve RPM in managing NoC related clocks and
there is no NoC scaling. Linux itself handles these clocks.
However, these should not be exposed as just clocks and align
with other Qualcomm SoCs that handle these clocks from a
interconnect provider.
Hence include icc provider capability to the gcc node so that
peripherals can use the interconnect facility to enable these
clocks.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
arch/arm64/boot/dts/qcom/ipq9574.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/ipq9574.dtsi b/arch/arm64/boot/dts/qcom/ipq9574.dtsi
index c5abadf94975..0aba4c60e850 100644
--- a/arch/arm64/boot/dts/qcom/ipq9574.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq9574.dtsi
@@ -8,6 +8,7 @@
#include <dt-bindings/clock/qcom,apss-ipq.h>
#include <dt-bindings/clock/qcom,ipq9574-gcc.h>
+#include <dt-bindings/interconnect/qcom,ipq9574.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/reset/qcom,ipq9574-gcc.h>
#include <dt-bindings/clock/qcom,ipq9574-nsscc.h>
@@ -457,6 +458,7 @@ gcc: clock-controller@1800000 {
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
+ #interconnect-cells = <1>;
};
tcsr_mutex: hwlock@1905000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v7 4/5] clk: qcom: ipq9574: Use icc-clk for enabling NoC related clocks
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-1-quic_varada@quicinc.com>
Use the icc-clk framework to enable few clocks to be able to
create paths and use the peripherals connected on those NoCs.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v7: Auto select INTERCONNECT & INTERCONNECT_CLK in COMMON_CLK_QCOM
to address build break with random config build test, with the
following combination
CONFIG_COMMON_CLK_QCOM=y
and
CONFIG_INTERCONNECT_CLK=m
the following error is seen as devm_icc_clk_register is in a
module and being referenced from vmlinux.
powerpc64-linux-ld: drivers/clk/qcom/common.o: in function `qcom_cc_really_probe':
>> common.c:(.text+0x980): undefined reference to `devm_icc_clk_register'
v6: Move enum to dt-bindings and share between here and DT
first_id -> icc_first_node_id
v5: Split from common.c changes into separate patch
No functional changes
---
drivers/clk/qcom/Kconfig | 2 ++
drivers/clk/qcom/gcc-ipq9574.c | 30 ++++++++++++++++++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index b0e0eeb1604e..e51328bbd146 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -17,6 +17,8 @@ menuconfig COMMON_CLK_QCOM
select RATIONAL
select REGMAP_MMIO
select RESET_CONTROLLER
+ select INTERCONNECT
+ select INTERCONNECT_CLK
if COMMON_CLK_QCOM
diff --git a/drivers/clk/qcom/gcc-ipq9574.c b/drivers/clk/qcom/gcc-ipq9574.c
index 43da03e4c2dd..0ede625777c9 100644
--- a/drivers/clk/qcom/gcc-ipq9574.c
+++ b/drivers/clk/qcom/gcc-ipq9574.c
@@ -12,6 +12,7 @@
#include <dt-bindings/clock/qcom,ipq9574-gcc.h>
#include <dt-bindings/reset/qcom,ipq9574-gcc.h>
+#include <dt-bindings/interconnect/qcom,ipq9574.h>
#include "clk-alpha-pll.h"
#include "clk-branch.h"
@@ -4067,6 +4068,32 @@ static const struct qcom_reset_map gcc_ipq9574_resets[] = {
[GCC_WCSS_Q6_TBU_BCR] = { 0x12054, 0 },
};
+#define IPQ_APPS_ID 9574 /* some unique value */
+
+static struct clk_hw *icc_ipq9574_hws[] = {
+ [ICC_ANOC_PCIE0] = &gcc_anoc_pcie0_1lane_m_clk.clkr.hw,
+ [ICC_SNOC_PCIE0] = &gcc_anoc_pcie1_1lane_m_clk.clkr.hw,
+ [ICC_ANOC_PCIE1] = &gcc_anoc_pcie2_2lane_m_clk.clkr.hw,
+ [ICC_SNOC_PCIE1] = &gcc_anoc_pcie3_2lane_m_clk.clkr.hw,
+ [ICC_ANOC_PCIE2] = &gcc_snoc_pcie0_1lane_s_clk.clkr.hw,
+ [ICC_SNOC_PCIE2] = &gcc_snoc_pcie1_1lane_s_clk.clkr.hw,
+ [ICC_ANOC_PCIE3] = &gcc_snoc_pcie2_2lane_s_clk.clkr.hw,
+ [ICC_SNOC_PCIE3] = &gcc_snoc_pcie3_2lane_s_clk.clkr.hw,
+ [ICC_SNOC_USB] = &gcc_snoc_usb_clk.clkr.hw,
+ [ICC_ANOC_USB_AXI] = &gcc_anoc_usb_axi_clk.clkr.hw,
+ [ICC_NSSNOC_NSSCC] = &gcc_nssnoc_nsscc_clk.clkr.hw,
+ [ICC_NSSNOC_SNOC_0] = &gcc_nssnoc_snoc_clk.clkr.hw,
+ [ICC_NSSNOC_SNOC_1] = &gcc_nssnoc_snoc_1_clk.clkr.hw,
+ [ICC_NSSNOC_PCNOC_1] = &gcc_nssnoc_pcnoc_1_clk.clkr.hw,
+ [ICC_NSSNOC_QOSGEN_REF] = &gcc_nssnoc_qosgen_ref_clk.clkr.hw,
+ [ICC_NSSNOC_TIMEOUT_REF] = &gcc_nssnoc_timeout_ref_clk.clkr.hw,
+ [ICC_NSSNOC_XO_DCD] = &gcc_nssnoc_xo_dcd_clk.clkr.hw,
+ [ICC_NSSNOC_ATB] = &gcc_nssnoc_atb_clk.clkr.hw,
+ [ICC_MEM_NOC_NSSNOC] = &gcc_mem_noc_nssnoc_clk.clkr.hw,
+ [ICC_NSSNOC_MEMNOC] = &gcc_nssnoc_memnoc_clk.clkr.hw,
+ [ICC_NSSNOC_MEM_NOC_1] = &gcc_nssnoc_mem_noc_1_clk.clkr.hw,
+};
+
static const struct of_device_id gcc_ipq9574_match_table[] = {
{ .compatible = "qcom,ipq9574-gcc" },
{ }
@@ -4089,6 +4116,9 @@ static const struct qcom_cc_desc gcc_ipq9574_desc = {
.num_resets = ARRAY_SIZE(gcc_ipq9574_resets),
.clk_hws = gcc_ipq9574_hws,
.num_clk_hws = ARRAY_SIZE(gcc_ipq9574_hws),
+ .icc_hws = icc_ipq9574_hws,
+ .num_icc_hws = ARRAY_SIZE(icc_ipq9574_hws),
+ .icc_first_node_id = IPQ_APPS_ID,
};
static int gcc_ipq9574_probe(struct platform_device *pdev)
--
2.34.1
^ permalink raw reply related
* [PATCH v7 3/5] clk: qcom: common: Add interconnect clocks support
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-1-quic_varada@quicinc.com>
Unlike MSM platforms that manage NoC related clocks and scaling
from RPM, IPQ SoCs dont involve RPM in managing NoC related
clocks and there is no NoC scaling.
However, there is a requirement to enable some NoC interface
clocks for accessing the peripheral controllers present on
these NoCs. Though exposing these as normal clocks would work,
having a minimalistic interconnect driver to handle these clocks
would make it consistent with other Qualcomm platforms resulting
in common code paths. This is similar to msm8996-cbf's usage of
icc-clk framework.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v7: Restore clk_get
v6: first_id -> icc_first_node_id
Remove clock get so that the peripheral that uses the clock
can do the clock get
v5: Split changes in common.c to separate patch
Fix error handling
Use devm_icc_clk_register instead of icc_clk_register
v4: Use clk_hw instead of indices
Do icc register in qcom_cc_probe() call stream
Add icc clock info to qcom_cc_desc structure
v3: Use indexed identifiers here to avoid confusion
Fix error messages and move to common.c
v2: Move DTS to separate patch
Update commit log
Auto select CONFIG_INTERCONNECT & CONFIG_INTERCONNECT_CLK to fix build error
---
drivers/clk/qcom/common.c | 31 ++++++++++++++++++++++++++++++-
drivers/clk/qcom/common.h | 3 +++
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index 8b6080eb43a7..fa4ec89c04c4 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -8,6 +8,7 @@
#include <linux/regmap.h>
#include <linux/platform_device.h>
#include <linux/clk-provider.h>
+#include <linux/interconnect-clk.h>
#include <linux/reset-controller.h>
#include <linux/of.h>
@@ -252,6 +253,34 @@ static struct clk_hw *qcom_cc_clk_hw_get(struct of_phandle_args *clkspec,
return cc->rclks[idx] ? &cc->rclks[idx]->hw : NULL;
}
+static int qcom_cc_icc_register(struct device *dev,
+ const struct qcom_cc_desc *desc)
+{
+ struct icc_clk_data *icd;
+ int i;
+
+ if (!IS_ENABLED(CONFIG_INTERCONNECT_CLK))
+ return 0;
+
+ if (!desc->icc_hws)
+ return 0;
+
+ icd = devm_kcalloc(dev, desc->num_icc_hws, sizeof(*icd), GFP_KERNEL);
+ if (!icd)
+ return -ENOMEM;
+
+ for (i = 0; i < desc->num_icc_hws; i++) {
+ icd[i].clk = devm_clk_hw_get_clk(dev, desc->icc_hws[i], "icc");
+ if (!icd[i].clk)
+ return dev_err_probe(dev, -ENOENT,
+ "(%d) clock entry is null\n", i);
+ icd[i].name = clk_hw_get_name(desc->icc_hws[i]);
+ }
+
+ return devm_icc_clk_register(dev, desc->icc_first_node_id,
+ desc->num_icc_hws, icd);
+}
+
int qcom_cc_really_probe(struct platform_device *pdev,
const struct qcom_cc_desc *desc, struct regmap *regmap)
{
@@ -327,7 +356,7 @@ int _qcom_cc_really_probe(struct device *dev,
if (ret)
return ret;
- return 0;
+ return qcom_cc_icc_register(dev, desc);
}
EXPORT_SYMBOL_GPL(_qcom_cc_really_probe);
diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h
index 8657257d56d3..43073d2ef32a 100644
--- a/drivers/clk/qcom/common.h
+++ b/drivers/clk/qcom/common.h
@@ -29,6 +29,9 @@ struct qcom_cc_desc {
size_t num_gdscs;
struct clk_hw **clk_hws;
size_t num_clk_hws;
+ struct clk_hw **icc_hws;
+ size_t num_icc_hws;
+ unsigned int icc_first_node_id;
};
/**
--
2.34.1
^ permalink raw reply related
* [PATCH v7 2/5] interconnect: icc-clk: Add devm_icc_clk_register
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-1-quic_varada@quicinc.com>
Wrap icc_clk_register to create devm_icc_clk_register to be
able to release the resources properly.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v7: Simplify devm_icc_clk_register implementation as suggested in review
v5: Introduced devm_icc_clk_register
---
drivers/interconnect/icc-clk.c | 18 ++++++++++++++++++
include/linux/interconnect-clk.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/interconnect/icc-clk.c b/drivers/interconnect/icc-clk.c
index d787f2ea36d9..bce946592c98 100644
--- a/drivers/interconnect/icc-clk.c
+++ b/drivers/interconnect/icc-clk.c
@@ -148,6 +148,24 @@ struct icc_provider *icc_clk_register(struct device *dev,
}
EXPORT_SYMBOL_GPL(icc_clk_register);
+static void devm_icc_release(void *res)
+{
+ icc_clk_unregister(res);
+}
+
+int devm_icc_clk_register(struct device *dev, unsigned int first_id,
+ unsigned int num_clocks, const struct icc_clk_data *data)
+{
+ struct icc_provider *prov;
+
+ prov = icc_clk_register(dev, first_id, num_clocks, data);
+ if (IS_ERR(prov))
+ return PTR_ERR(prov);
+
+ return devm_add_action_or_reset(dev, devm_icc_release, prov);
+}
+EXPORT_SYMBOL_GPL(devm_icc_clk_register);
+
/**
* icc_clk_unregister() - unregister a previously registered clk interconnect provider
* @provider: provider returned by icc_clk_register()
diff --git a/include/linux/interconnect-clk.h b/include/linux/interconnect-clk.h
index 0cd80112bea5..5c611a8b0892 100644
--- a/include/linux/interconnect-clk.h
+++ b/include/linux/interconnect-clk.h
@@ -17,6 +17,8 @@ struct icc_provider *icc_clk_register(struct device *dev,
unsigned int first_id,
unsigned int num_clocks,
const struct icc_clk_data *data);
+int devm_icc_clk_register(struct device *dev, unsigned int first_id,
+ unsigned int num_clocks, const struct icc_clk_data *data);
void icc_clk_unregister(struct icc_provider *provider);
#endif
--
2.34.1
^ permalink raw reply related
* [PATCH v7 1/5] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <20240403104220.1092431-1-quic_varada@quicinc.com>
Add interconnect-cells to clock provider so that it can be
used as icc provider.
Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip
interfaces. This will be used by the gcc-ipq9574 driver
that will for providing interconnect services using the
icc-clk framework.
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
---
v7:
Fix macro names to be consistent with other bindings
v6:
Removed Reviewed-by: Krzysztof Kozlowski
Redefine the bindings such that driver and DT can share them
v3:
Squash Documentation/ and include/ changes into same patch
qcom,ipq9574.h
Move 'first id' to clock driver
---
.../bindings/clock/qcom,ipq9574-gcc.yaml | 3 +
.../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++
2 files changed, 90 insertions(+)
create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
index 944a0ea79cd6..824781cbdf34 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
@@ -33,6 +33,9 @@ properties:
- description: PCIE30 PHY3 pipe clock source
- description: USB3 PHY pipe clock source
+ '#interconnect-cells':
+ const: 1
+
required:
- compatible
- clocks
diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h
new file mode 100644
index 000000000000..0b076b0cf880
--- /dev/null
+++ b/include/dt-bindings/interconnect/qcom,ipq9574.h
@@ -0,0 +1,87 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+#ifndef INTERCONNECT_QCOM_IPQ9574_H
+#define INTERCONNECT_QCOM_IPQ9574_H
+
+#define ICC_ANOC_PCIE0 0
+#define ICC_SNOC_PCIE0 1
+#define ICC_ANOC_PCIE1 2
+#define ICC_SNOC_PCIE1 3
+#define ICC_ANOC_PCIE2 4
+#define ICC_SNOC_PCIE2 5
+#define ICC_ANOC_PCIE3 6
+#define ICC_SNOC_PCIE3 7
+#define ICC_SNOC_USB 8
+#define ICC_ANOC_USB_AXI 9
+#define ICC_NSSNOC_NSSCC 10
+#define ICC_NSSNOC_SNOC_0 11
+#define ICC_NSSNOC_SNOC_1 12
+#define ICC_NSSNOC_PCNOC_1 13
+#define ICC_NSSNOC_QOSGEN_REF 14
+#define ICC_NSSNOC_TIMEOUT_REF 15
+#define ICC_NSSNOC_XO_DCD 16
+#define ICC_NSSNOC_ATB 17
+#define ICC_MEM_NOC_NSSNOC 18
+#define ICC_NSSNOC_MEMNOC 19
+#define ICC_NSSNOC_MEM_NOC_1 20
+
+#define ICC_NSSNOC_PPE 0
+#define ICC_NSSNOC_PPE_CFG 1
+#define ICC_NSSNOC_NSS_CSR 2
+#define ICC_NSSNOC_IMEM_QSB 3
+#define ICC_NSSNOC_IMEM_AHB 4
+
+#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2)
+#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1)
+#define MASTER_SNOC_PCIE0 (ICC_SNOC_PCIE0 * 2)
+#define SLAVE_SNOC_PCIE0 ((ICC_SNOC_PCIE0 * 2) + 1)
+#define MASTER_ANOC_PCIE1 (ICC_ANOC_PCIE1 * 2)
+#define SLAVE_ANOC_PCIE1 ((ICC_ANOC_PCIE1 * 2) + 1)
+#define MASTER_SNOC_PCIE1 (ICC_SNOC_PCIE1 * 2)
+#define SLAVE_SNOC_PCIE1 ((ICC_SNOC_PCIE1 * 2) + 1)
+#define MASTER_ANOC_PCIE2 (ICC_ANOC_PCIE2 * 2)
+#define SLAVE_ANOC_PCIE2 ((ICC_ANOC_PCIE2 * 2) + 1)
+#define MASTER_SNOC_PCIE2 (ICC_SNOC_PCIE2 * 2)
+#define SLAVE_SNOC_PCIE2 ((ICC_SNOC_PCIE2 * 2) + 1)
+#define MASTER_ANOC_PCIE3 (ICC_ANOC_PCIE3 * 2)
+#define SLAVE_ANOC_PCIE3 ((ICC_ANOC_PCIE3 * 2) + 1)
+#define MASTER_SNOC_PCIE3 (ICC_SNOC_PCIE3 * 2)
+#define SLAVE_SNOC_PCIE3 ((ICC_SNOC_PCIE3 * 2) + 1)
+#define MASTER_USB (ICC_USB * 2)
+#define SLAVE_USB ((ICC_USB * 2) + 1)
+#define MASTER_USB_AXI (ICC_USB_AXI * 2)
+#define SLAVE_USB_AXI ((ICC_USB_AXI * 2) + 1)
+#define MASTER_NSSNOC_NSSCC (ICC_NSSNOC_NSSCC * 2)
+#define SLAVE_NSSNOC_NSSCC ((ICC_NSSNOC_NSSCC * 2) + 1)
+#define MASTER_NSSNOC_SNOC_0 (ICC_NSSNOC_SNOC_0 * 2)
+#define SLAVE_NSSNOC_SNOC_0 ((ICC_NSSNOC_SNOC_0 * 2) + 1)
+#define MASTER_NSSNOC_SNOC_1 (ICC_NSSNOC_SNOC_1 * 2)
+#define SLAVE_NSSNOC_SNOC_1 ((ICC_NSSNOC_SNOC_1 * 2) + 1)
+#define MASTER_NSSNOC_PCNOC_1 (ICC_NSSNOC_PCNOC_1 * 2)
+#define SLAVE_NSSNOC_PCNOC_1 ((ICC_NSSNOC_PCNOC_1 * 2) + 1)
+#define MASTER_NSSNOC_QOSGEN_REF (ICC_NSSNOC_QOSGEN_REF * 2)
+#define SLAVE_NSSNOC_QOSGEN_REF ((ICC_NSSNOC_QOSGEN_REF * 2) + 1)
+#define MASTER_NSSNOC_TIMEOUT_REF (ICC_NSSNOC_TIMEOUT_REF * 2)
+#define SLAVE_NSSNOC_TIMEOUT_REF ((ICC_NSSNOC_TIMEOUT_REF * 2) + 1)
+#define MASTER_NSSNOC_XO_DCD (ICC_NSSNOC_XO_DCD * 2)
+#define SLAVE_NSSNOC_XO_DCD ((ICC_NSSNOC_XO_DCD * 2) + 1)
+#define MASTER_NSSNOC_ATB (ICC_NSSNOC_ATB * 2)
+#define SLAVE_NSSNOC_ATB ((ICC_NSSNOC_ATB * 2) + 1)
+#define MASTER_MEM_NOC_NSSNOC (ICC_MEM_NOC_NSSNOC * 2)
+#define SLAVE_MEM_NOC_NSSNOC ((ICC_MEM_NOC_NSSNOC * 2) + 1)
+#define MASTER_NSSNOC_MEMNOC (ICC_NSSNOC_MEMNOC * 2)
+#define SLAVE_NSSNOC_MEMNOC ((ICC_NSSNOC_MEMNOC * 2) + 1)
+#define MASTER_NSSNOC_MEM_NOC_1 (ICC_NSSNOC_MEM_NOC_1 * 2)
+#define SLAVE_NSSNOC_MEM_NOC_1 ((ICC_NSSNOC_MEM_NOC_1 * 2) + 1)
+
+#define MASTER_NSSNOC_PPE (ICC_NSSNOC_PPE * 2)
+#define SLAVE_NSSNOC_PPE ((ICC_NSSNOC_PPE * 2) + 1)
+#define MASTER_NSSNOC_PPE_CFG (ICC_NSSNOC_PPE_CFG * 2)
+#define SLAVE_NSSNOC_PPE_CFG ((ICC_NSSNOC_PPE_CFG * 2) + 1)
+#define MASTER_NSSNOC_NSS_CSR (ICC_NSSNOC_NSS_CSR * 2)
+#define SLAVE_NSSNOC_NSS_CSR ((ICC_NSSNOC_NSS_CSR * 2) + 1)
+#define MASTER_NSSNOC_IMEM_QSB (ICC_NSSNOC_IMEM_QSB * 2)
+#define SLAVE_NSSNOC_IMEM_QSB ((ICC_NSSNOC_IMEM_QSB * 2) + 1)
+#define MASTER_NSSNOC_IMEM_AHB (ICC_NSSNOC_IMEM_AHB * 2)
+#define SLAVE_NSSNOC_IMEM_AHB ((ICC_NSSNOC_IMEM_AHB * 2) + 1)
+
+#endif /* INTERCONNECT_QCOM_IPQ9574_H */
--
2.34.1
^ permalink raw reply related
* [PATCH v7 0/5] Add interconnect driver for IPQ9574 SoC
From: Varadarajan Narayanan @ 2024-04-03 10:42 UTC (permalink / raw)
To: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_varada, quic_anusha,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-pm
MSM platforms manage NoC related clocks and scaling from RPM.
However, in IPQ SoCs, RPM is not involved in managing NoC
related clocks and there is no NoC scaling.
However, there is a requirement to enable some NoC interface
clocks for the accessing the peripherals present in the
system. Hence add a minimalistic interconnect driver that
establishes a path from the processor/memory to those peripherals
and vice versa.
---
v7: Fix macro names in dt-bindings header
Do clock get in icc driver
v6: Removed 'Reviewed-by: Krzysztof' from dt-bindings patch
Remove clock get from ICC driver as suggested by Stephen Boyd
so that the actual peripheral can do the clock get
first_id -> icc_first_node_id
Remove tristate from INTERCONNECT_CLK
v5:
Split gcc-ipq9574.c and common.c changes into separate patches
Introduce devm_icc_clk_register
Fix error handling
v4:
gcc-ipq9574.c
Use clk_hw instead of indices
common.c
Do icc register in qcom_cc_probe() call stream
common.h
Add icc clock info to qcom_cc_desc structure
v3:
qcom,ipq9574.h
Move 'first id' define to clock driver
gcc-ipq9574.c:
Use indexed identifiers here to avoid confusion
Fix error messages and move code to common.c as it can be
shared with future SoCs
v2:
qcom,ipq9574.h
Fix license identifier
Rename macros
qcom,ipq9574-gcc.yaml
Include interconnect-cells
gcc-ipq9574.c
Update commit log
Remove IS_ENABLED(CONFIG_INTERCONNECT) and auto select it from Kconfig
ipq9574.dtsi
Moved to separate patch
Include interconnect-cells to clock controller node
drivers/clk/qcom/Kconfig:
Auto select CONFIG_INTERCONNECT & CONFIG_INTERCONNECT_CLK
Varadarajan Narayanan (5):
dt-bindings: interconnect: Add Qualcomm IPQ9574 support
interconnect: icc-clk: Add devm_icc_clk_register
clk: qcom: common: Add interconnect clocks support
clk: qcom: ipq9574: Use icc-clk for enabling NoC related clocks
arm64: dts: qcom: ipq9574: Add icc provider ability to gcc
.../bindings/clock/qcom,ipq9574-gcc.yaml | 3 +
arch/arm64/boot/dts/qcom/ipq9574.dtsi | 2 +
drivers/clk/qcom/Kconfig | 2 +
drivers/clk/qcom/common.c | 31 ++++++-
drivers/clk/qcom/common.h | 3 +
drivers/clk/qcom/gcc-ipq9574.c | 30 +++++++
drivers/interconnect/icc-clk.c | 18 ++++
.../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++
include/linux/interconnect-clk.h | 2 +
9 files changed, 177 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h
--
2.34.1
^ permalink raw reply
* Re: [PATCH] ARM: dts: n900: set charge current limit to 950mA
From: Tony Lindgren @ 2024-04-03 9:03 UTC (permalink / raw)
To: Sicelo A. Mhlongo
Cc: devicetree, Benoît Cousson, Krzysztof Kozlowski,
Conor Dooley, linux-pm, pali, sre, spinal.by, maemo-leste,
linux-omap
In-Reply-To: <20240228083846.2401108-2-absicsz@gmail.com>
* Sicelo A. Mhlongo <absicsz@gmail.com> [240228 10:40]:
> From: Arthur Demchenkov <spinal.by@gmail.com>
>
> The vendor kernel used 950mA as the default. The same value works fine on
> the mainline Linux kernel, and has been tested extensively under Maemo
> Leste [1] and postmarketOS, who have been using it for a number of years.
Thanks applying into omap-for-v6.10/dt.
Tony
> [1] https://github.com/maemo-leste/n9xx-linux/commit/fbc4ce7a84e59215914a8981afe918002b191493
^ permalink raw reply
* Re: [PATCH v4 1/4] interconnect: qcom: icc-rpmh: Add QoS configuration support
From: Odelu Kukatla @ 2024-04-03 8:45 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Georgi Djakov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Kees Cook, cros-qcom-dts-watchers, Gustavo A . R . Silva,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
linux-hardening, quic_rlaggysh, quic_mdtipton
In-Reply-To: <d59896bb-a559-4013-a615-37bb43278b2e@linaro.org>
On 3/27/2024 2:26 AM, Konrad Dybcio wrote:
> On 25.03.2024 7:16 PM, Odelu Kukatla wrote:
>> It adds QoS support for QNOC device and includes support for
>> configuring priority, priority forward disable, urgency forwarding.
>> This helps in priortizing the traffic originating from different
>> interconnect masters at NoC(Network On Chip).
>>
>> Signed-off-by: Odelu Kukatla <quic_okukatla@quicinc.com>
>> ---
>
> [...]
>
>>
>> + if (desc->config) {
>> + struct resource *res;
>> + void __iomem *base;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + goto skip_qos_config;
>> +
>> + base = devm_ioremap_resource(dev, res);
>
> You were asked to substitute this call like 3 times already..
>
> devm_platform_get_and_ioremap_resource
>
> or even better, devm_platform_ioremap_resource
>
> [...]
>
>> @@ -70,6 +102,7 @@ struct qcom_icc_node {
>> u64 max_peak[QCOM_ICC_NUM_BUCKETS];
>> struct qcom_icc_bcm *bcms[MAX_BCM_PER_NODE];
>> size_t num_bcms;
>> + const struct qcom_icc_qosbox *qosbox;
>
> I believe I came up with a better approach for storing this.. see [1]
>
> Konrad
>
> [1] https://lore.kernel.org/linux-arm-msm/20240326-topic-rpm_icc_qos_cleanup-v1-4-357e736792be@linaro.org/
>
I see in this series, QoS parameters are moved into struct qcom_icc_desc.
Even though we program QoS at Provider/Bus level, it is property of the node/master connected to a Bus/NoC.
It will be easier later to know which master's QoS we are programming if we add in node data.
Readability point of view, it might be good to keep QoS parameters in node data.
Thanks,
Odelu
^ permalink raw reply
* [rafael-pm:bleeding-edge] BUILD SUCCESS acc71791e32e8c9a8fbe04ced8b00c49dfbcc52b
From: kernel test robot @ 2024-04-03 8:20 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, devel, linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: acc71791e32e8c9a8fbe04ced8b00c49dfbcc52b Merge branch 'acpi-thermal' into bleeding-edge
elapsed time: 729m
configs tested: 162
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc nsimosci_hs_smp_defconfig gcc
arc randconfig-001-20240403 gcc
arc randconfig-002-20240403 gcc
arm allmodconfig gcc
arm allnoconfig clang
arm allyesconfig gcc
arm defconfig clang
arm integrator_defconfig clang
arm randconfig-001-20240403 gcc
arm randconfig-002-20240403 gcc
arm randconfig-003-20240403 clang
arm randconfig-004-20240403 gcc
arm realview_defconfig clang
arm s5pv210_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240403 clang
arm64 randconfig-002-20240403 clang
arm64 randconfig-003-20240403 gcc
arm64 randconfig-004-20240403 clang
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240403 gcc
csky randconfig-002-20240403 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20240403 clang
hexagon randconfig-002-20240403 clang
i386 allmodconfig gcc
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240403 gcc
i386 buildonly-randconfig-002-20240403 clang
i386 buildonly-randconfig-003-20240403 clang
i386 buildonly-randconfig-004-20240403 clang
i386 buildonly-randconfig-005-20240403 gcc
i386 buildonly-randconfig-006-20240403 clang
i386 defconfig clang
i386 randconfig-001-20240403 gcc
i386 randconfig-002-20240403 clang
i386 randconfig-003-20240403 gcc
i386 randconfig-004-20240403 gcc
i386 randconfig-005-20240403 clang
i386 randconfig-006-20240403 gcc
i386 randconfig-011-20240403 gcc
i386 randconfig-012-20240403 clang
i386 randconfig-013-20240403 gcc
i386 randconfig-014-20240403 clang
i386 randconfig-015-20240403 gcc
i386 randconfig-016-20240403 clang
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240403 gcc
loongarch randconfig-002-20240403 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k bvme6000_defconfig gcc
m68k defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allnoconfig gcc
mips allyesconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240403 gcc
nios2 randconfig-002-20240403 gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
openrisc or1ksim_defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240403 gcc
parisc randconfig-002-20240403 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc cm5200_defconfig clang
powerpc eiger_defconfig clang
powerpc ep8248e_defconfig gcc
powerpc kmeter1_defconfig gcc
powerpc mpc8315_rdb_defconfig clang
powerpc randconfig-001-20240403 gcc
powerpc randconfig-002-20240403 gcc
powerpc randconfig-003-20240403 clang
powerpc tqm8555_defconfig clang
powerpc64 randconfig-001-20240403 gcc
powerpc64 randconfig-002-20240403 clang
powerpc64 randconfig-003-20240403 gcc
riscv allmodconfig clang
riscv allnoconfig gcc
riscv allyesconfig clang
riscv defconfig clang
riscv randconfig-001-20240403 clang
riscv randconfig-002-20240403 clang
s390 allmodconfig clang
s390 allnoconfig clang
s390 allyesconfig gcc
s390 defconfig clang
s390 randconfig-001-20240403 clang
s390 randconfig-002-20240403 clang
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh kfr2r09-romimage_defconfig gcc
sh kfr2r09_defconfig gcc
sh lboxre2_defconfig gcc
sh randconfig-001-20240403 gcc
sh randconfig-002-20240403 gcc
sh se7724_defconfig gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240403 gcc
sparc64 randconfig-002-20240403 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig gcc
um defconfig clang
um i386_defconfig gcc
um randconfig-001-20240403 gcc
um randconfig-002-20240403 clang
um x86_64_defconfig clang
x86_64 allnoconfig clang
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240403 gcc
x86_64 buildonly-randconfig-002-20240403 gcc
x86_64 buildonly-randconfig-003-20240403 clang
x86_64 buildonly-randconfig-004-20240403 gcc
x86_64 buildonly-randconfig-005-20240403 clang
x86_64 buildonly-randconfig-006-20240403 gcc
x86_64 defconfig gcc
x86_64 rhel-8.3-rust clang
xtensa allnoconfig gcc
xtensa audio_kc705_defconfig gcc
xtensa randconfig-001-20240403 gcc
xtensa randconfig-002-20240403 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH 27/34] cpufreq: intel_pstate: hide unused intel_pstate_cpu_oob_ids[]
From: Arnd Bergmann @ 2024-04-03 8:06 UTC (permalink / raw)
To: linux-kernel, Srinivas Pandruvada, Len Brown, Rafael J. Wysocki,
Viresh Kumar
Cc: Arnd Bergmann, Doug Smythies, Zhenguo Yao, Tero Kristo,
Jiri Slaby (SUSE), linux-pm
In-Reply-To: <20240403080702.3509288-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
The reference to this variable is hidden in an #ifdef:
drivers/cpufreq/intel_pstate.c:2440:32: error: 'intel_pstate_cpu_oob_ids' defined but not used [-Werror=unused-const-variable=]
Use the same check around the definition.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/cpufreq/intel_pstate.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index dbbf299f4219..29ce9edc6f68 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2437,6 +2437,7 @@ static const struct x86_cpu_id intel_pstate_cpu_ids[] = {
};
MODULE_DEVICE_TABLE(x86cpu, intel_pstate_cpu_ids);
+#ifdef CONFIG_ACPI
static const struct x86_cpu_id intel_pstate_cpu_oob_ids[] __initconst = {
X86_MATCH(BROADWELL_D, core_funcs),
X86_MATCH(BROADWELL_X, core_funcs),
@@ -2445,6 +2446,7 @@ static const struct x86_cpu_id intel_pstate_cpu_oob_ids[] __initconst = {
X86_MATCH(SAPPHIRERAPIDS_X, core_funcs),
{}
};
+#endif
static const struct x86_cpu_id intel_pstate_cpu_ee_disable_ids[] = {
X86_MATCH(KABYLAKE, core_funcs),
--
2.39.2
^ permalink raw reply related
* [PATCH 09/34] power: rt9455: hide unused rt9455_boost_voltage_values
From: Arnd Bergmann @ 2024-04-03 8:06 UTC (permalink / raw)
To: linux-kernel, Sebastian Reichel, Anda-Maria Nicolae,
Krzysztof Kozlowski
Cc: Arnd Bergmann, David Lechner, Rob Herring, Uwe Kleine-König,
linux-pm
In-Reply-To: <20240403080702.3509288-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
The rt9455_boost_voltage_values[] array is only used when USB PHY
support is enabled, causing a W=1 warning otherwise:
drivers/power/supply/rt9455_charger.c:200:18: error: 'rt9455_boost_voltage_values' defined but not used [-Werror=unused-const-variable=]
Enclose the definition in the same #ifdef as the references to it.
Fixes: e86d69dd786e ("power_supply: Add support for Richtek RT9455 battery charger")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/power/supply/rt9455_charger.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/power/supply/rt9455_charger.c b/drivers/power/supply/rt9455_charger.c
index c345a77f9f78..e4dbacd50a43 100644
--- a/drivers/power/supply/rt9455_charger.c
+++ b/drivers/power/supply/rt9455_charger.c
@@ -192,6 +192,7 @@ static const int rt9455_voreg_values[] = {
4450000, 4450000, 4450000, 4450000, 4450000, 4450000, 4450000, 4450000
};
+#if IS_ENABLED(CONFIG_USB_PHY)
/*
* When the charger is in boost mode, REG02[7:2] represent boost output
* voltage.
@@ -207,6 +208,7 @@ static const int rt9455_boost_voltage_values[] = {
5600000, 5600000, 5600000, 5600000, 5600000, 5600000, 5600000, 5600000,
5600000, 5600000, 5600000, 5600000, 5600000, 5600000, 5600000, 5600000,
};
+#endif
/* REG07[3:0] (VMREG) in uV */
static const int rt9455_vmreg_values[] = {
--
2.39.2
^ permalink raw reply related
* [PATCH 00/34] address all -Wunused-const warnings
From: Arnd Bergmann @ 2024-04-03 8:06 UTC (permalink / raw)
To: linux-kernel
Cc: Arnd Bergmann, Michael Ellerman, Christophe Leroy, Damien Le Moal,
Jiri Kosina, Greg Kroah-Hartman, Corey Minyard, Peter Huewe,
Jarkko Sakkinen, Tero Kristo, Stephen Boyd, Ian Abbott,
H Hartley Sweeten, Srinivas Pandruvada, Len Brown,
Rafael J. Wysocki, John Allen, Herbert Xu, Vinod Koul,
Ard Biesheuvel, Bjorn Andersson, Moritz Fischer, Liviu Dudau,
Benjamin Tissoires, Andi Shyti, Michael Hennerich, Peter Rosin,
Lars-Peter Clausen, Jonathan Cameron, Dmitry Torokhov,
Markuss Broks, Alexandre Torgue, Lee Jones, Jakub Kicinski,
Shyam Sundar S K, Iyappan Subramanian, Yisen Zhuang,
Stanislaw Gruszka, Kalle Valo, Sebastian Reichel, Tony Lindgren,
Mark Brown, Alexandre Belloni, Xiang Chen, Martin K. Petersen,
Neil Armstrong, Heiko Stuebner, Krzysztof Kozlowski,
Vaibhav Hiremath, Alex Elder, Jiri Slaby, Jacky Huang,
Helge Deller, Christoph Hellwig, Robin Murphy, Steven Rostedt,
Masami Hiramatsu, Andrew Morton, Kees Cook, Trond Myklebust,
Anna Schumaker, Masahiro Yamada, Nathan Chancellor, Takashi Iwai,
linuxppc-dev, linux-ide, openipmi-developer, linux-integrity,
linux-omap, linux-clk, linux-pm, linux-crypto, dmaengine,
linux-efi, linux-arm-msm, linux-fpga, dri-devel, linux-input,
linux-i2c, linux-iio, linux-stm32, linux-arm-kernel, netdev,
linux-leds, linux-wireless, linux-rtc, linux-scsi, linux-spi,
linux-amlogic, linux-rockchip, linux-samsung-soc, greybus-dev,
linux-staging, linux-serial, linux-usb, linux-fbdev, iommu,
linux-trace-kernel, kasan-dev, linux-hardening, linux-nfs,
linux-kbuild, alsa-devel, linux-sound
From: Arnd Bergmann <arnd@arndb.de>
Compilers traditionally warn for unused 'static' variables, but not
if they are constant. The reason here is a custom for C++ programmers
to define named constants as 'static const' variables in header files
instead of using macros or enums.
In W=1 builds, we get warnings only static const variables in C
files, but not in headers, which is a good compromise, but this still
produces warning output in at least 30 files. These warnings are
almost all harmless, but also trivial to fix, and there is no
good reason to warn only about the non-const variables being unused.
I've gone through all the files that I found using randconfig and
allmodconfig builds and created patches to avoid these warnings,
with the goal of retaining a clean build once the option is enabled
by default.
Unfortunately, there is one fairly large patch ("drivers: remove
incorrect of_match_ptr/ACPI_PTR annotations") that touches
34 individual drivers that all need the same one-line change.
If necessary, I can split it up by driver or by subsystem,
but at least for reviewing I would keep it as one piece for
the moment.
Please merge the individual patches through subsystem trees.
I expect that some of these will have to go through multiple
revisions before they are picked up, so anything that gets
applied early saves me from resending.
Arnd
Arnd Bergmann (31):
powerpc/fsl-soc: hide unused const variable
ubsan: fix unused variable warning in test module
platform: goldfish: remove ACPI_PTR() annotations
i2c: pxa: hide unused icr_bits[] variable
3c515: remove unused 'mtu' variable
tracing: hide unused ftrace_event_id_fops
Input: synaptics: hide unused smbus_pnp_ids[] array
power: rt9455: hide unused rt9455_boost_voltage_values
efi: sysfb: don't build when EFI is disabled
clk: ti: dpll: fix incorrect #ifdef checks
apm-emulation: hide an unused variable
sisfb: hide unused variables
dma/congiguous: avoid warning about unused size_bytes
leds: apu: remove duplicate DMI lookup data
iio: ad5755: hook up of_device_id lookup to platform driver
greybus: arche-ctrl: move device table to its right location
lib: checksum: hide unused expected_csum_ipv6_magic[]
sunrpc: suppress warnings for unused procfs functions
comedi: ni_atmio: avoid warning for unused device_ids[] table
iwlegacy: don't warn for unused variables with DEBUG_FS=n
drm/komeda: don't warn for unused debugfs files
firmware: qcom_scm: mark qcom_scm_qseecom_allowlist as __maybe_unused
crypto: ccp - drop platform ifdef checks
usb: gadget: omap_udc: remove unused variable
isdn: kcapi: don't build unused procfs code
cpufreq: intel_pstate: hide unused intel_pstate_cpu_oob_ids[]
net: xgbe: remove extraneous #ifdef checks
Input: imagis - remove incorrect ifdef checks
sata: mv: drop unnecessary #ifdef checks
ASoC: remove incorrect of_match_ptr/ACPI_PTR annotations
spi: remove incorrect of_match_ptr annotations
drivers: remove incorrect of_match_ptr/ACPI_PTR annotations
kbuild: always enable -Wunused-const-variable
Krzysztof Kozlowski (1):
Input: stmpe-ts - mark OF related data as maybe unused
arch/powerpc/sysdev/fsl_msi.c | 2 +
drivers/ata/sata_mv.c | 64 +++++++++----------
drivers/char/apm-emulation.c | 5 +-
drivers/char/ipmi/ipmb_dev_int.c | 2 +-
drivers/char/tpm/tpm_ftpm_tee.c | 2 +-
drivers/clk/ti/dpll.c | 10 ++-
drivers/comedi/drivers/ni_atmio.c | 2 +-
drivers/cpufreq/intel_pstate.c | 2 +
drivers/crypto/ccp/sp-platform.c | 14 +---
drivers/dma/img-mdc-dma.c | 2 +-
drivers/firmware/efi/Makefile | 3 +-
drivers/firmware/efi/sysfb_efi.c | 2 -
drivers/firmware/qcom/qcom_scm.c | 2 +-
drivers/fpga/versal-fpga.c | 2 +-
.../gpu/drm/arm/display/komeda/komeda_dev.c | 8 ---
drivers/hid/hid-google-hammer.c | 6 +-
drivers/i2c/busses/i2c-pxa.c | 2 +-
drivers/i2c/muxes/i2c-mux-ltc4306.c | 2 +-
drivers/i2c/muxes/i2c-mux-reg.c | 2 +-
drivers/iio/dac/ad5755.c | 1 +
drivers/input/mouse/synaptics.c | 2 +
drivers/input/touchscreen/imagis.c | 4 +-
drivers/input/touchscreen/stmpe-ts.c | 2 +-
drivers/input/touchscreen/wdt87xx_i2c.c | 2 +-
drivers/isdn/capi/Makefile | 3 +-
drivers/isdn/capi/kcapi.c | 7 +-
drivers/leds/leds-apu.c | 3 +-
drivers/mux/adg792a.c | 2 +-
drivers/net/ethernet/3com/3c515.c | 3 -
drivers/net/ethernet/amd/xgbe/xgbe-platform.c | 8 ---
drivers/net/ethernet/apm/xgene-v2/main.c | 2 +-
drivers/net/ethernet/hisilicon/hns_mdio.c | 2 +-
drivers/net/wireless/intel/iwlegacy/4965-rs.c | 15 +----
drivers/net/wireless/intel/iwlegacy/common.h | 2 -
drivers/platform/goldfish/goldfish_pipe.c | 2 +-
drivers/power/supply/rt9455_charger.c | 2 +
drivers/regulator/pbias-regulator.c | 2 +-
drivers/regulator/twl-regulator.c | 2 +-
drivers/regulator/twl6030-regulator.c | 2 +-
drivers/rtc/rtc-fsl-ftm-alarm.c | 2 +-
drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 2 +-
drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 2 +-
drivers/spi/spi-armada-3700.c | 2 +-
drivers/spi/spi-img-spfi.c | 2 +-
drivers/spi/spi-meson-spicc.c | 2 +-
drivers/spi/spi-meson-spifc.c | 2 +-
drivers/spi/spi-orion.c | 2 +-
drivers/spi/spi-pic32-sqi.c | 2 +-
drivers/spi/spi-pic32.c | 2 +-
drivers/spi/spi-rockchip.c | 2 +-
drivers/spi/spi-s3c64xx.c | 2 +-
drivers/spi/spi-st-ssc4.c | 2 +-
drivers/staging/greybus/arche-apb-ctrl.c | 1 +
drivers/staging/greybus/arche-platform.c | 9 +--
drivers/staging/pi433/pi433_if.c | 2 +-
drivers/tty/serial/amba-pl011.c | 6 +-
drivers/tty/serial/ma35d1_serial.c | 2 +-
drivers/usb/gadget/udc/omap_udc.c | 10 +--
drivers/video/fbdev/sis/init301.c | 3 +-
kernel/dma/contiguous.c | 2 +-
kernel/trace/trace_events.c | 4 ++
lib/checksum_kunit.c | 2 +
lib/test_ubsan.c | 2 +-
net/sunrpc/cache.c | 10 +--
scripts/Makefile.extrawarn | 1 -
sound/soc/atmel/sam9x5_wm8731.c | 2 +-
sound/soc/codecs/rt5514-spi.c | 2 +-
sound/soc/qcom/lpass-sc7280.c | 2 +-
sound/soc/samsung/aries_wm8994.c | 2 +-
69 files changed, 121 insertions(+), 169 deletions(-)
--
2.39.2
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Damien Le Moal <dlemoal@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Corey Minyard <minyard@acm.org>
Cc: Peter Huewe <peterhuewe@gmx.de>
Cc: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Tero Kristo <kristo@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Ian Abbott <abbotti@mev.co.uk>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: John Allen <john.allen@amd.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Moritz Fischer <mdf@kernel.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Andi Shyti <andi.shyti@kernel.org>
Cc: Michael Hennerich <michael.hennerich@analog.com>
Cc: Peter Rosin <peda@axentia.se>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Markuss Broks <markuss.broks@gmail.com>
Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
Cc: Lee Jones <lee@kernel.org>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Cc: Iyappan Subramanian <iyappan@os.amperecomputing.com>
Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
Cc: Stanislaw Gruszka <stf_xl@wp.pl>
Cc: Kalle Valo <kvalo@kernel.org>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Xiang Chen <chenxiang66@hisilicon.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Vaibhav Hiremath <hvaibhav.linux@gmail.com>
Cc: Alex Elder <elder@kernel.org>
Cc: Jiri Slaby <jirislaby@kernel.org>
Cc: Jacky Huang <ychuang3@nuvoton.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: Anna Schumaker <anna@kernel.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-ide@vger.kernel.org
Cc: openipmi-developer@lists.sourceforge.net
Cc: linux-integrity@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: dmaengine@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-fpga@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-input@vger.kernel.org
Cc: linux-i2c@vger.kernel.org
Cc: linux-iio@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: netdev@vger.kernel.org
Cc: linux-leds@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: greybus-dev@lists.linaro.org
Cc: linux-staging@lists.linux.dev
Cc: linux-serial@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: iommu@lists.linux.dev
Cc: linux-trace-kernel@vger.kernel.org
Cc: kasan-dev@googlegroups.com
Cc: linux-hardening@vger.kernel.org
Cc: linux-nfs@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: linux-sound@vger.kernel.org
^ permalink raw reply
* kernel/sched/core.c:961:15: error: incompatible pointer to integer conversion passing 'typeof
From: Naresh Kamboju @ 2024-04-03 7:38 UTC (permalink / raw)
To: open list, Linux Regressions, lkft-triage, clang-built-linux,
Linux PM
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Nathan Chancellor, Nick Desaulniers
The riscv clang-17 defconfig build failed due to following warnings / errors
on the Linux next-20240402.
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
riscv:
build:
* clang-17-lkftconfig - Failed
* rv32-clang-17-defconfig - Failed
* clang-17-tinyconfig - Failed
* rv32-clang-17-tinyconfig - Failed
* clang-17-defconfig - Failed
* clang-17-allnoconfig - Failed
* rv32-clang-17-allnoconfig - Failed
Build log:
-------
kernel/sched/core.c:961:15: error: incompatible pointer to integer
conversion passing 'typeof (*((__ai_ptr)))' (aka 'struct wake_q_node
*') to parameter of type 'uintptr_t' (aka 'unsigned long')
[-Wint-conversion]
961 | if (unlikely(cmpxchg_relaxed(&node->next, NULL, WAKE_Q_TAIL)))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Steps to reproduce:
---------
# tuxmake --runtime podman --target-arch riscv --toolchain clang-17
--kconfig defconfig LLVM=1 LLVM_IAS=1
Links:
- https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240402/testrun/23264917/suite/build/test/clang-17-defconfig/details/
- https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20240402/testrun/23264917/suite/build/test/clang-17-defconfig/log
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply
* Re: [PATCH 00/18] platform/chrome: provide ID table for avoiding fallback match
From: patchwork-bot+chrome-platform @ 2024-04-03 7:20 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: bleung, groeck, linus.walleij, brgl, hverkuil-cisco, mchehab, sre,
alexandre.belloni, chrome-platform, pmalani, linux-gpio,
linux-media, linux-pm, linux-rtc, krzk
In-Reply-To: <20240329075630.2069474-1-tzungbi@kernel.org>
Hello:
This series was applied to chrome-platform/linux.git (for-next)
by Tzung-Bi Shih <tzungbi@kernel.org>:
On Fri, 29 Mar 2024 15:56:12 +0800 you wrote:
> Inspired by [1]. Turn all MODULE_ALIAS() in ChromeOS EC platform drivers into
> proper platform_device_id table and MODULE_DEVICE_TABLE().
>
> The series is basically looking for drivers from:
> - `struct mfd_cell` in drivers/mfd/cros_ec_dev.c.
> - grep -R MODULE_ALIAS drivers/platform/chrome/.
>
> [...]
Here is the summary with links:
- [01/18] media: platform: cros-ec: provide ID table for avoiding fallback match
(no matching commit)
- [02/18] gpio: cros-ec: provide ID table for avoiding fallback match
(no matching commit)
- [03/18] rtc: cros-ec: provide ID table for avoiding fallback match
(no matching commit)
- [04/18] platform/chrome: cros_ec_sensorhub: provide ID table for avoiding fallback match
(no matching commit)
- [05/18] power: supply: cros_usbpd: provide ID table for avoiding fallback match
(no matching commit)
- [06/18] platform/chrome: cros_usbpd_logger: provide ID table for avoiding fallback match
(no matching commit)
- [07/18] platform/chrome: cros_usbpd_notify: provide ID table for avoiding fallback match
(no matching commit)
- [08/18] platform/chrome: cros_ec_chardev: provide ID table for avoiding fallback match
(no matching commit)
- [09/18] platform/chrome: cros_ec_debugfs: provide ID table for avoiding fallback match
(no matching commit)
- [10/18] platform/chrome: cros_ec_sysfs: provide ID table for avoiding fallback match
(no matching commit)
- [11/18] power: supply: cros_pchg: provide ID table for avoiding fallback match
(no matching commit)
- [12/18] platform/chrome: cros_ec_lightbar: provide ID table for avoiding fallback match
(no matching commit)
- [13/18] platform/chrome: cros_ec_vbc: provide ID table for avoiding fallback match
(no matching commit)
- [14/18] platform/chrome: cros_kbd_led_backlight: provide ID table for avoiding fallback match
https://git.kernel.org/chrome-platform/c/d91ca83599cd
- [15/18] platform/chrome: wilco_ec: telemetry: provide ID table for avoiding fallback match
(no matching commit)
- [16/18] platform/chrome: wilco_ec: debugfs: provide ID table for avoiding fallback match
(no matching commit)
- [17/18] platform/chrome: wilco_ec: event: remove redundant MODULE_ALIAS
(no matching commit)
- [18/18] platform/chrome/wilco_ec: core: provide ID table for avoiding fallback match
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 00/18] platform/chrome: provide ID table for avoiding fallback match
From: patchwork-bot+chrome-platform @ 2024-04-03 7:20 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: bleung, groeck, linus.walleij, brgl, hverkuil-cisco, mchehab, sre,
alexandre.belloni, chrome-platform, pmalani, linux-gpio,
linux-media, linux-pm, linux-rtc, krzk
In-Reply-To: <20240329075630.2069474-1-tzungbi@kernel.org>
Hello:
This series was applied to chrome-platform/linux.git (for-kernelci)
by Tzung-Bi Shih <tzungbi@kernel.org>:
On Fri, 29 Mar 2024 15:56:12 +0800 you wrote:
> Inspired by [1]. Turn all MODULE_ALIAS() in ChromeOS EC platform drivers into
> proper platform_device_id table and MODULE_DEVICE_TABLE().
>
> The series is basically looking for drivers from:
> - `struct mfd_cell` in drivers/mfd/cros_ec_dev.c.
> - grep -R MODULE_ALIAS drivers/platform/chrome/.
>
> [...]
Here is the summary with links:
- [01/18] media: platform: cros-ec: provide ID table for avoiding fallback match
(no matching commit)
- [02/18] gpio: cros-ec: provide ID table for avoiding fallback match
(no matching commit)
- [03/18] rtc: cros-ec: provide ID table for avoiding fallback match
(no matching commit)
- [04/18] platform/chrome: cros_ec_sensorhub: provide ID table for avoiding fallback match
(no matching commit)
- [05/18] power: supply: cros_usbpd: provide ID table for avoiding fallback match
(no matching commit)
- [06/18] platform/chrome: cros_usbpd_logger: provide ID table for avoiding fallback match
(no matching commit)
- [07/18] platform/chrome: cros_usbpd_notify: provide ID table for avoiding fallback match
(no matching commit)
- [08/18] platform/chrome: cros_ec_chardev: provide ID table for avoiding fallback match
(no matching commit)
- [09/18] platform/chrome: cros_ec_debugfs: provide ID table for avoiding fallback match
(no matching commit)
- [10/18] platform/chrome: cros_ec_sysfs: provide ID table for avoiding fallback match
(no matching commit)
- [11/18] power: supply: cros_pchg: provide ID table for avoiding fallback match
(no matching commit)
- [12/18] platform/chrome: cros_ec_lightbar: provide ID table for avoiding fallback match
(no matching commit)
- [13/18] platform/chrome: cros_ec_vbc: provide ID table for avoiding fallback match
(no matching commit)
- [14/18] platform/chrome: cros_kbd_led_backlight: provide ID table for avoiding fallback match
https://git.kernel.org/chrome-platform/c/d91ca83599cd
- [15/18] platform/chrome: wilco_ec: telemetry: provide ID table for avoiding fallback match
(no matching commit)
- [16/18] platform/chrome: wilco_ec: debugfs: provide ID table for avoiding fallback match
(no matching commit)
- [17/18] platform/chrome: wilco_ec: event: remove redundant MODULE_ALIAS
(no matching commit)
- [18/18] platform/chrome/wilco_ec: core: provide ID table for avoiding fallback match
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v6 1/6] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Krzysztof Kozlowski @ 2024-04-03 7:09 UTC (permalink / raw)
To: Varadarajan Narayanan, andersson, konrad.dybcio, mturquette,
sboyd, robh, krzysztof.kozlowski+dt, conor+dt, djakov,
dmitry.baryshkov, quic_anusha, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-pm
In-Reply-To: <20240402103406.3638821-2-quic_varada@quicinc.com>
On 02/04/2024 12:34, Varadarajan Narayanan wrote:
> +#define ICC_NSSNOC_NSSCC 10
> +#define ICC_NSSNOC_SNOC_0 11
> +#define ICC_NSSNOC_SNOC_1 12
> +#define ICC_NSSNOC_PCNOC_1 13
> +#define ICC_NSSNOC_QOSGEN_REF 14
> +#define ICC_NSSNOC_TIMEOUT_REF 15
> +#define ICC_NSSNOC_XO_DCD 16
> +#define ICC_NSSNOC_ATB 17
> +#define ICC_MEM_NOC_NSSNOC 18
> +#define ICC_NSSNOC_MEMNOC 19
> +#define ICC_NSSNOC_MEM_NOC_1 20
> +
> +#define ICC_NSSNOC_PPE 0
> +#define ICC_NSSNOC_PPE_CFG 1
> +#define ICC_NSSNOC_NSS_CSR 2
> +#define ICC_NSSNOC_IMEM_QSB 3
> +#define ICC_NSSNOC_IMEM_AHB 4
> +
> +#define MASTER(x) ((ICC_ ## x) * 2)
> +#define SLAVE(x) (MASTER(x) + 1)
You already received comment to make your bindings consistent with other
Qualcomm bindings. Now you repeat the same mistake.
No, that is neither consistent nor greppble.
Best regards,
Krzysztof
^ permalink raw reply
* [rafael-pm:intel_pstate-testing 14/14] drivers/cpufreq/intel_pstate.c:3301:undefined reference to `arch_rebuild_sched_domains'
From: kernel test robot @ 2024-04-03 6:58 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: oe-kbuild-all, linux-acpi, devel, linux-pm
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git intel_pstate-testing
head: e35f6a1b27a71e7c8cb1880197e01d93b593cc85
commit: e35f6a1b27a71e7c8cb1880197e01d93b593cc85 [14/14] cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems
config: x86_64-randconfig-014-20240403 (https://download.01.org/0day-ci/archive/20240403/202404031421.nMNiWZMY-lkp@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240403/202404031421.nMNiWZMY-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202404031421.nMNiWZMY-lkp@intel.com/
All errors (new ones prefixed by >>):
ld: drivers/cpufreq/intel_pstate.o: in function `intel_pstate_register_driver':
>> drivers/cpufreq/intel_pstate.c:3301:(.text+0x409c): undefined reference to `arch_rebuild_sched_domains'
vim +3301 drivers/cpufreq/intel_pstate.c
3267
3268 static int intel_pstate_register_driver(struct cpufreq_driver *driver)
3269 {
3270 int ret;
3271
3272 if (driver == &intel_pstate)
3273 intel_pstate_sysfs_expose_hwp_dynamic_boost();
3274
3275 memset(&global, 0, sizeof(global));
3276 global.max_perf_pct = 100;
3277 global.turbo_disabled = turbo_is_disabled();
3278 global.no_turbo = global.turbo_disabled;
3279
3280 arch_set_max_freq_ratio(global.turbo_disabled);
3281
3282 intel_pstate_driver = driver;
3283 ret = cpufreq_register_driver(intel_pstate_driver);
3284 if (ret) {
3285 intel_pstate_driver_cleanup();
3286 return ret;
3287 }
3288
3289 global.min_perf_pct = min_perf_pct_min();
3290
3291 /*
3292 * On hybrid systems, use asym capacity instead of ITMT, but because
3293 * the capacity of SMT threads is not deterministic even approximately,
3294 * do not do that when SMT is in use.
3295 */
3296 if (hwp_is_hybrid && !sched_smt_active()) {
3297 sched_clear_itmt_support();
3298
3299 hybrid_init_cpu_scaling();
3300
> 3301 arch_rebuild_sched_domains();
3302 }
3303
3304 return 0;
3305 }
3306
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [regression] 6.8.1: fails to hibernate with pm_runtime_force_suspend+0x0/0x120 returns -16
From: Linux regression tracking (Thorsten Leemhuis) @ 2024-04-03 4:49 UTC (permalink / raw)
To: Martin Steigerwald, linux-pm, regressions, linux-kernel
In-Reply-To: <22240355.EfDdHjke4D@lichtvoll.de>
On 02.04.24 21:42, Martin Steigerwald wrote:
> Linux regression tracking (Thorsten Leemhuis) - 19.03.24, 09:40:06 CEST:
>> On 16.03.24 17:12, Martin Steigerwald wrote:
>>> Martin Steigerwald - 16.03.24, 17:02:44 CET:
>>>> ThinkPad T14 AMD Gen 1 fails to hibernate with self-compiled 6.8.1.
>>>> Hibernation works correctly with self-compiled 6.7.9.
>>>
>>> Apparently 6.8.1 does not even reboot correctly anymore. runit on
>>> Devuan. It says it is doing the system reboot but then nothing
>>> happens.
>>>
>>> As for hibernation the kernel cancels the attempt and returns back to
>>> user space desktop session.
>>>
>>>> Trying to use "no_console_suspend" to debug next. Will not do bisect
>>>> between major kernel releases on a production machine.
>>
>> FWIW, without a bisection I guess no developer will take a closer look
>> (but I might be wrong and you lucky here!), as any change in those
>> hundreds of drivers used on that machine can possibly lead to problems
>> like yours. So without a bisection we are likely stuck here, unless
>> someone else runs into the same problem and bisects or fixes it. Sorry,
>> but that's just how it is.
>
> I have been asked this repeatedly with previous bug reports. My issue
> with bisecting between major kernel versions is this:
>
> When I look around here I see no second ThinkPad T14 AMD Gen 1 here I
> could use for testing. Also doing a kernel bisect using a GRML live iso…
> not really.
>
> The one I reported this from is a production machine with a 4 TB NVMe
> SSD which contains a lot of data. I am not willing to risk data loss or
> (silent) file system corruption by bisecting between major kernel
> releases. Bisecting between major kernel releases in my understanding
> would require to test various releases between in this example 6.7 and
> 6.8 and even between 6.7 and 6.8-rc1. At least in my understand anything
> between 6.7 and 6.8-rc1 is not guaranteed to be even be somewhat stable.
It's hard to qualify and always a matter of personal viewpoint/opinion,
but I'd say: kernel from the merge window are pretty stable and
reliable. But sure, accidents that eat data happen and they happen
slightly more often during merge windows because the rate of change is
higher. But in the end they do not happen often, which is why Fedora
rawhide for example ships merge window kernels all the time.
> I
> am not usually installing an rc1 kernel on a production machine, but
> rather wait for at least rc2/3 nowadays. Its a balanced risk calculation.
> And rc2/3 or later appears to be a risk I am willing to take. But
> something between stable and rc1? Nope.
Well, that's up to you -- but the reality is also that developers are
not obliged to look into regressions report closely, unless someone
bisected it.
> It is not even that rare. 6.7 some rc failed with hibernation as well.
Maybe too few people (or too few of those that run the latest kernels)
use hibernate these days (I haven't for more than 15 years), which is
why it's not tested much.
> With exactly the same machine. I refused to do a bisect as well in that
> case. At some later time the issue was fixed without me doing anything
> more.
Maybe you were lucky, maybe someone else bisected and reported the problem.
> Now my question is this: Without me willing to bisect in that case, is
> a bug report even useful? Otherwise I may just switch this last machine
> to distribution kernels. It would save a lot of time for me. This private
> and freelancer production machine is the last left-over machine with self-
> compiled kernels.
>
> So far I still thought I would somehow be contributing to Linux kernel
> quality with detailed bug reports that take time to write, but apparently
> I am not. Can you clarify?
Not really, as it always depends on the situation. There are bugs (like
https://lore.kernel.org/all/08275279-7462-4f4a-a0ee-8aa015f829bc@leemhuis.info/
) where a report without a bisection is enough. But there are others
where it's unlikely that anyone will take a closer look; a lot of those
reg. suspend/hibernate fall into this category, as problems in that area
can be cause by any subsystem and its drivers -- which is why the power
management people can't look into most of those, as then they quickly
wouldn't get anything else done while spending time on bugs most of the
time other people caused.
Ciao, Thorsten
^ permalink raw reply
* [rafael-pm:intel_pstate-testing 14/14] intel_pstate.c:undefined reference to `arch_rebuild_sched_domains'
From: kernel test robot @ 2024-04-03 0:50 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: oe-kbuild-all, linux-acpi, devel, linux-pm
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git intel_pstate-testing
head: e35f6a1b27a71e7c8cb1880197e01d93b593cc85
commit: e35f6a1b27a71e7c8cb1880197e01d93b593cc85 [14/14] cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems
config: i386-buildonly-randconfig-001-20240403 (https://download.01.org/0day-ci/archive/20240403/202404030858.0AJW6re4-lkp@intel.com/config)
compiler: gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240403/202404030858.0AJW6re4-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202404030858.0AJW6re4-lkp@intel.com/
All errors (new ones prefixed by >>):
ld: drivers/cpufreq/intel_pstate.o: in function `intel_pstate_register_driver':
>> intel_pstate.c:(.text+0x232e): undefined reference to `arch_rebuild_sched_domains'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 3/3] arm64: cpuidle: Add arm_poll_idle
From: Ankur Arora @ 2024-04-02 23:17 UTC (permalink / raw)
To: Mark Rutland
Cc: Haris Okanovic, linux-kernel, linux-pm, linux-assembly, peterz,
Ali Saidi, Geoff Blake, Brian Silver
In-Reply-To: <Zgw--fHBH9kEQsi0@FVFF77S0Q05N>
Mark Rutland <mark.rutland@arm.com> writes:
> On Mon, Apr 01, 2024 at 08:47:06PM -0500, Haris Okanovic wrote:
>> An arm64 cpuidle driver with two states: (1) First polls for new runable
>> tasks up to 100 us (by default) before (2) a wfi idle and awoken by
>> interrupt (the current arm64 behavior). It allows CPUs to return from
>> idle more quickly by avoiding the longer interrupt wakeup path, which
>> may require EL1/EL2 transition in certain VM scenarios.
>
> Please start off with an explanation of the problem you're trying to solve
> (which IIUC is to wake up more quickly in certain cases), before describing the
> solution. That makes it *significantly* easier for people to review this, since
> once you have the problem statement in mind it's much easier to understand how
> the solution space follows from that.
>
>> Poll duration is optionally configured at load time via the poll_limit
>> module parameter.
>
> Why should this be a configurable parameter?
>
> (note, at this point you haven't introduced any of the data below, so the
> trade-off isn't clear to anyone).
>
>> The default 100 us duration was experimentally chosen, by measuring QPS
>> (queries per sec) of the MLPerf bert inference benchmark, which seems
>> particularly susceptible to this change; see procedure below. 100 us is
>> the inflection point where QPS stopped growing in a range of tested
>> values. All results are from AWS m7g.16xlarge instances (Graviton3 SoC)
>> with dedicated tenancy (dedicated hardware).
>>
>> | before | 10us | 25us | 50us | 100us | 125us | 150us | 200us | 300us |
>> | 5.87 | 5.91 | 5.96 | 6.01 | 6.06 | 6.07 | 6.06 | 6.06 | 6.06 |
>>
>> Perf's scheduler benchmarks also improve with a range of poll_limit
>> values >= 10 us. Higher limits produce near identical results within a
>> 3% noise margin. The following tables are `perf bench sched` results,
>> run times in seconds.
>>
>> `perf bench sched messaging -l 80000`
>> | AWS instance | SoC | Before | After | % Change |
>> | c6g.16xl (VM) | Graviton2 | 18.974 | 18.400 | none |
>> | c7g.16xl (VM) | Graviton3 | 13.852 | 13.859 | none |
>> | c6g.metal | Graviton2 | 17.621 | 16.744 | none |
>> | c7g.metal | Graviton3 | 13.430 | 13.404 | none |
>>
>> `perf bench sched pipe -l 2500000`
>> | AWS instance | SoC | Before | After | % Change |
>> | c6g.16xl (VM) | Graviton2 | 30.158 | 15.181 | -50% |
>> | c7g.16xl (VM) | Graviton3 | 18.289 | 12.067 | -34% |
>> | c6g.metal | Graviton2 | 17.609 | 15.170 | -14% |
>> | c7g.metal | Graviton3 | 14.103 | 12.304 | -13% |
>>
>> `perf bench sched seccomp-notify -l 2500000`
>> | AWS instance | SoC | Before | After | % Change |
>> | c6g.16xl (VM) | Graviton2 | 28.784 | 13.754 | -52% |
>> | c7g.16xl (VM) | Graviton3 | 16.964 | 11.430 | -33% |
>> | c6g.metal | Graviton2 | 15.717 | 13.536 | -14% |
>> | c7g.metal | Graviton3 | 13.301 | 11.491 | -14% |
>
> Ok, so perf numbers for a busy workload go up.
>
> What happens for idle state residency on a mostly idle system?
>
>> Steps to run MLPerf bert inference on Ubuntu 22.04:
>> sudo apt install build-essential python3 python3-pip
>> pip install "pybind11[global]" tensorflow transformers
>> export TF_ENABLE_ONEDNN_OPTS=1
>> export DNNL_DEFAULT_FPMATH_MODE=BF16
>> git clone https://github.com/mlcommons/inference.git --recursive
>> cd inference
>> git checkout v2.0
>> cd loadgen
>> CFLAGS="-std=c++14" python3 setup.py bdist_wheel
>> pip install dist/*.whl
>> cd ../language/bert
>> make setup
>> python3 run.py --backend=tf --scenario=SingleStream
>>
>> Suggested-by: Ali Saidi <alisaidi@amazon.com>
>> Reviewed-by: Ali Saidi <alisaidi@amazon.com>
>> Reviewed-by: Geoff Blake <blakgeof@amazon.com>
>> Cc: Brian Silver <silverbr@amazon.com>
>> Signed-off-by: Haris Okanovic <harisokn@amazon.com>
>> ---
>> drivers/cpuidle/Kconfig.arm | 13 ++
>> drivers/cpuidle/Makefile | 1 +
>> drivers/cpuidle/cpuidle-arm-polling.c | 171 ++++++++++++++++++++++++++
>> 3 files changed, 185 insertions(+)
>> create mode 100644 drivers/cpuidle/cpuidle-arm-polling.c
>>
>> diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
>> index a1ee475d180d..484666dda38d 100644
>> --- a/drivers/cpuidle/Kconfig.arm
>> +++ b/drivers/cpuidle/Kconfig.arm
>> @@ -14,6 +14,19 @@ config ARM_CPUIDLE
>> initialized by calling the CPU operations init idle hook
>> provided by architecture code.
>>
>> +config ARM_POLL_CPUIDLE
>> + bool "ARM64 CPU idle Driver with polling"
>> + depends on ARM64
>> + depends on ARM_ARCH_TIMER_EVTSTREAM
>> + select CPU_IDLE_MULTIPLE_DRIVERS
>> + help
>> + Select this to enable a polling cpuidle driver for ARM64:
>> + The first state polls TIF_NEED_RESCHED for best latency on short
>> + sleep intervals. The second state falls back to arch_cpu_idle() to
>> + wait for interrupt. This is can be helpful in workloads that
>> + frequently block/wake at short intervals or VMs where wakeup IPIs
>> + are more expensive.
>
> Why is this a separate driver rather than an optional feature in the existing
> driver?
>
> The fact that this duplicates a bunch of code indicates to me that this should
> not be a separate driver.
Also, the cpuidle-haltpoll driver is meant to do something quite similar.
That driver polls adaptively based on the haltpoll governor's tuning of
the polling period.
However, cpuidle-haltpoll is currently x86 only. Mihai (also from Oracle)
posted patches [1] adding support for ARM64.
Haris, could you take a look at it and see if it does what you are
looking for? The polling path in the linked version also uses
smp_cond_load_relaxed() so even the mechanisms for both of these
are fairly similar.
(I'll be sending out the next version shortly. Happy to Cc you if you
would like to try that out.)
Thanks
Ankur
[1] https://lore.kernel.org/lkml/1707982910-27680-1-git-send-email-mihai.carabas@oracle.com/
>
>> +
>> config ARM_PSCI_CPUIDLE
>> bool "PSCI CPU idle Driver"
>> depends on ARM_PSCI_FW
>> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
>> index d103342b7cfc..23c21422792d 100644
>> --- a/drivers/cpuidle/Makefile
>> +++ b/drivers/cpuidle/Makefile
>> @@ -22,6 +22,7 @@ obj-$(CONFIG_ARM_U8500_CPUIDLE) += cpuidle-ux500.o
>> obj-$(CONFIG_ARM_AT91_CPUIDLE) += cpuidle-at91.o
>> obj-$(CONFIG_ARM_EXYNOS_CPUIDLE) += cpuidle-exynos.o
>> obj-$(CONFIG_ARM_CPUIDLE) += cpuidle-arm.o
>> +obj-$(CONFIG_ARM_POLL_CPUIDLE) += cpuidle-arm-polling.o
>> obj-$(CONFIG_ARM_PSCI_CPUIDLE) += cpuidle-psci.o
>> obj-$(CONFIG_ARM_PSCI_CPUIDLE_DOMAIN) += cpuidle-psci-domain.o
>> obj-$(CONFIG_ARM_TEGRA_CPUIDLE) += cpuidle-tegra.o
>> diff --git a/drivers/cpuidle/cpuidle-arm-polling.c b/drivers/cpuidle/cpuidle-arm-polling.c
>> new file mode 100644
>> index 000000000000..bca128568114
>> --- /dev/null
>> +++ b/drivers/cpuidle/cpuidle-arm-polling.c
>> @@ -0,0 +1,171 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * ARM64 CPU idle driver using wfe polling
>> + *
>> + * Copyright 2024 Amazon.com, Inc. or its affiliates. All rights reserved.
>> + *
>> + * Authors:
>> + * Haris Okanovic <harisokn@amazon.com>
>> + * Brian Silver <silverbr@amazon.com>
>> + *
>> + * Based on cpuidle-arm.c
>> + * Copyright (C) 2014 ARM Ltd.
>> + * Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> + */
>> +
>> +#include <linux/cpu.h>
>> +#include <linux/cpu_cooling.h>
>> +#include <linux/cpuidle.h>
>> +#include <linux/sched/clock.h>
>> +
>> +#include <asm/cpuidle.h>
>> +#include <asm/readex.h>
>> +
>> +#include "dt_idle_states.h"
>> +
>> +/* Max duration of the wfe() poll loop in us, before transitioning to
>> + * arch_cpu_idle()/wfi() sleep.
>> + */
>
> /*
> * Comments should have the leading '/*' on a separate line.
> * See https://www.kernel.org/doc/html/v6.8/process/coding-style.html#commenting
> */
>
>> +#define DEFAULT_POLL_LIMIT_US 100
>> +static unsigned int poll_limit __read_mostly = DEFAULT_POLL_LIMIT_US;
>> +
>> +/*
>> + * arm_idle_wfe_poll - Polls state in wfe loop until reschedule is
>> + * needed or timeout
>> + */
>> +static int __cpuidle arm_idle_wfe_poll(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv, int idx)
>> +{
>> + u64 time_start, time_limit;
>> +
>> + time_start = local_clock();
>> + dev->poll_time_limit = false;
>> +
>> + local_irq_enable();
>
> Why enable IRQs here? We don't do that in the regular cpuidle-arm driver, nor
> the cpuidle-psci driver, and there's no explanation here or in the commit message.
>
> How does this interact with RCU? Is that still watching or are we in an
> extended quiescent state? For PSCI idle states we enter an EQS, and it seems
> like we probably should here...
>
>> +
>> + if (current_set_polling_and_test())
>> + goto end;
>> +
>> + time_limit = cpuidle_poll_time(drv, dev);
>> +
>> + do {
>> + // exclusive read arms the monitor for wfe
>> + if (__READ_ONCE_EX(current_thread_info()->flags) & _TIF_NEED_RESCHED)
>> + goto end;
>> +
>> + // may exit prematurely, see ARM_ARCH_TIMER_EVTSTREAM
>> + wfe();
>> + } while (local_clock() - time_start < time_limit);
>
> .. and if the EVTSTREAM is disabled, we'll sit in WFE forever rather than
> entering a deeper idle state, which doesn't seem desirable.
>
> It's worth noting that now that we have WFET, we'll probably want to disable
> the EVTSTREAM by default at some point, at least in some configurations, since
> that'll be able to sit in a WFE state for longer while also reliably waking up
> when required.
>
> I suspect we want something like an smp_load_acquire_timeout() here to do the
> wait in arch code (allowing us to use WFET), and enabling this state will
> depend on either having WFET or EVTSTREAM.
>
>> +
>> + dev->poll_time_limit = true;
>> +
>> +end:
>> + current_clr_polling();
>> + return idx;
>> +}
>> +
>> +/*
>> + * arm_idle_wfi - Places cpu in lower power state until interrupt,
>> + * a fallback to polling
>> + */
>> +static int __cpuidle arm_idle_wfi(struct cpuidle_device *dev,
>> + struct cpuidle_driver *drv, int idx)
>> +{
>> + if (current_clr_polling_and_test()) {
>> + local_irq_enable();
>> + return idx;
>> + }
>
> Same as above, why enable IRQs here?
>
>> + arch_cpu_idle();
>> + return idx;
>
> .. and if we need to enable IRQs in the other cases above, why do we *not*
> need to enable them here?
>
>> +}
>> +
>> +static struct cpuidle_driver arm_poll_idle_driver __initdata = {
>> + .name = "arm_poll_idle",
>> + .owner = THIS_MODULE,
>> + .states = {
>> + {
>> + .enter = arm_idle_wfe_poll,
>> + .exit_latency = 0,
>> + .target_residency = 0,
>> + .exit_latency_ns = 0,
>> + .power_usage = UINT_MAX,
>> + .flags = CPUIDLE_FLAG_POLLING,
>> + .name = "WFE",
>> + .desc = "ARM WFE",
>> + },
>> + {
>> + .enter = arm_idle_wfi,
>> + .exit_latency = DEFAULT_POLL_LIMIT_US,
>> + .target_residency = DEFAULT_POLL_LIMIT_US,
>> + .power_usage = UINT_MAX,
>> + .name = "WFI",
>> + .desc = "ARM WFI",
>> + },
>> + },
>> + .state_count = 2,
>> +};
>
> How does this interact with the existing driver?
>
> How does DEFAULT_POLL_LIMIT_US compare with PSCI idle states?
>
>> +
>> +/*
>> + * arm_poll_init_cpu - Initializes arm cpuidle polling driver for one cpu
>> + */
>> +static int __init arm_poll_init_cpu(int cpu)
>> +{
>> + int ret;
>> + struct cpuidle_driver *drv;
>> +
>> + drv = kmemdup(&arm_poll_idle_driver, sizeof(*drv), GFP_KERNEL);
>> + if (!drv)
>> + return -ENOMEM;
>> +
>> + drv->cpumask = (struct cpumask *)cpumask_of(cpu);
>> + drv->states[1].exit_latency = poll_limit;
>> + drv->states[1].target_residency = poll_limit;
>> +
>> + ret = cpuidle_register(drv, NULL);
>> + if (ret) {
>> + pr_err("failed to register driver: %d, cpu %d\n", ret, cpu);
>> + goto out_kfree_drv;
>> + }
>> +
>> + pr_info("registered driver cpu %d\n", cpu);
>
> This does not need to be printed for each CPU.
>
> Mark.
>
>> +
>> + cpuidle_cooling_register(drv);
>> +
>> + return 0;
>> +
>> +out_kfree_drv:
>> + kfree(drv);
>> + return ret;
>> +}
>> +
>> +/*
>> + * arm_poll_init - Initializes arm cpuidle polling driver
>> + */
>> +static int __init arm_poll_init(void)
>> +{
>> + int cpu, ret;
>> + struct cpuidle_driver *drv;
>> + struct cpuidle_device *dev;
>> +
>> + for_each_possible_cpu(cpu) {
>> + ret = arm_poll_init_cpu(cpu);
>> + if (ret)
>> + goto out_fail;
>> + }
>> +
>> + return 0;
>> +
>> +out_fail:
>> + pr_info("de-register all");
>> + while (--cpu >= 0) {
>> + dev = per_cpu(cpuidle_devices, cpu);
>> + drv = cpuidle_get_cpu_driver(dev);
>> + cpuidle_unregister(drv);
>> + kfree(drv);
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +module_param(poll_limit, uint, 0444);
>> +device_initcall(arm_poll_init);
>> --
>> 2.34.1
>>
>>
--
ankur
^ permalink raw reply
* Re: [PATCH v3 0/6] thermal: More separation between the core and drivers
From: Rafael J. Wysocki @ 2024-04-02 19:42 UTC (permalink / raw)
To: Linux PM
Cc: LKML, Srinivas Pandruvada, Daniel Lezcano, Lukasz Luba,
AngeloGioacchino Del Regno, Rafael J. Wysocki
In-Reply-To: <4558251.LvFx2qVVIh@kreacher>
On Tue, Apr 2, 2024 at 9:04 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> Hi Everyone,
>
> This is an update of
>
> https://lore.kernel.org/linux-pm/4558384.LvFx2qVVIh@kreacher/
>
> and
>
> https://lore.kernel.org/linux-pm/2331888.ElGaqSPkdT@kreacher/
>
> which rebases the first patch on top of 6.9-rc2, adds 3 patches and adjusts
> the third patch from v2.
>
> The original description of the first two patches still applies:
>
> > Patch [1/2] is based on the observation that the threshold field in struct
> > thermal_trip really should be core-internal and to make that happen it
> > introduces a wrapper structure around struct thermal_trip for internal
> > use in the core.
> >
> > Patch [2/2] moves the definition of the new structure and the struct
> > thermal_zone_device one to a local header file in the core to enforce
> > more separation between the core and drivers.
> >
> > The patches are not expected to introduce any observable differences in
> > behavior, so please let me know if you see any of that.
>
> Note that these patches were first sent before the merge window and have not
> really changed since then (except for a minor rebase of the first patch in
> this series). Moreover, no comments regarding the merit of these patches
> have been made shared, so if this continues, I will be considering them as
> good to go by the end of this week.
>
> Patch [3/6] is a rewrite of comments regarding trip crossing and threshold
> computations.
>
> Patch [4/6] updates the trip crossing detection code to consolidate the
> threshold initialization with trip crossing on the way up.
>
> Patch [5/6] ([3/3] in v2) adds a mechanism to sort notifications and debug
> calls taking place during one invocation of __thermal_zone_device_update() so
> they always go in temperature order.
>
> Patch [6/6] relocates the critical and trip point handling to avoid a
> redundant temperature check.
>
> The series applies on top of 6.9-rc2 and I'm planning to create a test
> branch containing it.
As promised:
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=thermal-core-testing
^ permalink raw reply
* Re: [regression] 6.8.1: fails to hibernate with pm_runtime_force_suspend+0x0/0x120 returns -16
From: Martin Steigerwald @ 2024-04-02 19:42 UTC (permalink / raw)
To: linux-pm, regressions, linux-kernel,
Linux regressions mailing list
In-Reply-To: <be5a7213-78b3-4917-b95b-ec31cd2350e4@leemhuis.info>
Hi Thorsten, hi,
Linux regression tracking (Thorsten Leemhuis) - 19.03.24, 09:40:06 CEST:
> On 16.03.24 17:12, Martin Steigerwald wrote:
> > Martin Steigerwald - 16.03.24, 17:02:44 CET:
> >> ThinkPad T14 AMD Gen 1 fails to hibernate with self-compiled 6.8.1.
> >> Hibernation works correctly with self-compiled 6.7.9.
> >
> > Apparently 6.8.1 does not even reboot correctly anymore. runit on
> > Devuan. It says it is doing the system reboot but then nothing
> > happens.
> >
> > As for hibernation the kernel cancels the attempt and returns back to
> > user space desktop session.
> >
> >> Trying to use "no_console_suspend" to debug next. Will not do bisect
> >> between major kernel releases on a production machine.
>
> FWIW, without a bisection I guess no developer will take a closer look
> (but I might be wrong and you lucky here!), as any change in those
> hundreds of drivers used on that machine can possibly lead to problems
> like yours. So without a bisection we are likely stuck here, unless
> someone else runs into the same problem and bisects or fixes it. Sorry,
> but that's just how it is.
I have been asked this repeatedly with previous bug reports. My issue
with bisecting between major kernel versions is this:
When I look around here I see no second ThinkPad T14 AMD Gen 1 here I
could use for testing. Also doing a kernel bisect using a GRML live iso…
not really.
The one I reported this from is a production machine with a 4 TB NVMe
SSD which contains a lot of data. I am not willing to risk data loss or
(silent) file system corruption by bisecting between major kernel
releases. Bisecting between major kernel releases in my understanding
would require to test various releases between in this example 6.7 and
6.8 and even between 6.7 and 6.8-rc1. At least in my understand anything
between 6.7 and 6.8-rc1 is not guaranteed to be even be somewhat stable. I
am not usually installing an rc1 kernel on a production machine, but
rather wait for at least rc2/3 nowadays. Its a balanced risk calculation.
And rc2/3 or later appears to be a risk I am willing to take. But
something between stable and rc1? Nope.
It is not even that rare. 6.7 some rc failed with hibernation as well.
With exactly the same machine. I refused to do a bisect as well in that
case. At some later time the issue was fixed without me doing anything
more.
Now my question is this: Without me willing to bisect in that case, is
a bug report even useful? Otherwise I may just switch this last machine
to distribution kernels. It would save a lot of time for me. This private
and freelancer production machine is the last left-over machine with self-
compiled kernels.
So far I still thought I would somehow be contributing to Linux kernel
quality with detailed bug reports that take time to write, but apparently
I am not. Can you clarify?
Ciao,
--
Martin
^ permalink raw reply
* [PATCH v3 2/6] thermal: core: Make struct thermal_zone_device definition internal
From: Rafael J. Wysocki @ 2024-04-02 18:57 UTC (permalink / raw)
To: Linux PM
Cc: LKML, Srinivas Pandruvada, Daniel Lezcano, Lukasz Luba,
AngeloGioacchino Del Regno
In-Reply-To: <4558251.LvFx2qVVIh@kreacher>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Move the definitions of struct thermal_trip_desc and struct
thermal_zone_device to an internal header file in the thermal core,
as they don't need to be accessible to any code other than the thermal
core and so they don't need to be present in a global header.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
v2 -> v3: Minor changelog update
v1 -> v2: No changes
---
drivers/thermal/thermal_core.h | 85 +++++++++++++++++++++++++++++++++++++++
drivers/thermal/thermal_trace.h | 2
include/linux/thermal.h | 87 ----------------------------------------
3 files changed, 89 insertions(+), 85 deletions(-)
Index: linux-pm/drivers/thermal/thermal_core.h
===================================================================
--- linux-pm.orig/drivers/thermal/thermal_core.h
+++ linux-pm/drivers/thermal/thermal_core.h
@@ -15,6 +15,91 @@
#include "thermal_netlink.h"
#include "thermal_debugfs.h"
+struct thermal_trip_desc {
+ struct thermal_trip trip;
+ int threshold;
+};
+
+/**
+ * struct thermal_zone_device - structure for a thermal zone
+ * @id: unique id number for each thermal zone
+ * @type: the thermal zone device type
+ * @device: &struct device for this thermal zone
+ * @removal: removal completion
+ * @trip_temp_attrs: attributes for trip points for sysfs: trip temperature
+ * @trip_type_attrs: attributes for trip points for sysfs: trip type
+ * @trip_hyst_attrs: attributes for trip points for sysfs: trip hysteresis
+ * @mode: current mode of this thermal zone
+ * @devdata: private pointer for device private data
+ * @num_trips: number of trip points the thermal zone supports
+ * @passive_delay_jiffies: number of jiffies to wait between polls when
+ * performing passive cooling.
+ * @polling_delay_jiffies: number of jiffies to wait between polls when
+ * checking whether trip points have been crossed (0 for
+ * interrupt driven systems)
+ * @temperature: current temperature. This is only for core code,
+ * drivers should use thermal_zone_get_temp() to get the
+ * current temperature
+ * @last_temperature: previous temperature read
+ * @emul_temperature: emulated temperature when using CONFIG_THERMAL_EMULATION
+ * @passive: 1 if you've crossed a passive trip point, 0 otherwise.
+ * @prev_low_trip: the low current temperature if you've crossed a passive
+ trip point.
+ * @prev_high_trip: the above current temperature if you've crossed a
+ passive trip point.
+ * @need_update: if equals 1, thermal_zone_device_update needs to be invoked.
+ * @ops: operations this &thermal_zone_device supports
+ * @tzp: thermal zone parameters
+ * @governor: pointer to the governor for this thermal zone
+ * @governor_data: private pointer for governor data
+ * @thermal_instances: list of &struct thermal_instance of this thermal zone
+ * @ida: &struct ida to generate unique id for this zone's cooling
+ * devices
+ * @lock: lock to protect thermal_instances list
+ * @node: node in thermal_tz_list (in thermal_core.c)
+ * @poll_queue: delayed work for polling
+ * @notify_event: Last notification event
+ * @suspended: thermal zone suspend indicator
+ * @trips: array of struct thermal_trip objects
+ */
+struct thermal_zone_device {
+ int id;
+ char type[THERMAL_NAME_LENGTH];
+ struct device device;
+ struct completion removal;
+ struct attribute_group trips_attribute_group;
+ struct thermal_attr *trip_temp_attrs;
+ struct thermal_attr *trip_type_attrs;
+ struct thermal_attr *trip_hyst_attrs;
+ enum thermal_device_mode mode;
+ void *devdata;
+ int num_trips;
+ unsigned long passive_delay_jiffies;
+ unsigned long polling_delay_jiffies;
+ int temperature;
+ int last_temperature;
+ int emul_temperature;
+ int passive;
+ int prev_low_trip;
+ int prev_high_trip;
+ atomic_t need_update;
+ struct thermal_zone_device_ops ops;
+ struct thermal_zone_params *tzp;
+ struct thermal_governor *governor;
+ void *governor_data;
+ struct list_head thermal_instances;
+ struct ida ida;
+ struct mutex lock;
+ struct list_head node;
+ struct delayed_work poll_queue;
+ enum thermal_notify_event notify_event;
+ bool suspended;
+#ifdef CONFIG_THERMAL_DEBUGFS
+ struct thermal_debugfs *debugfs;
+#endif
+ struct thermal_trip_desc trips[] __counted_by(num_trips);
+};
+
/* Default Thermal Governor */
#if defined(CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE)
#define DEFAULT_THERMAL_GOVERNOR "step_wise"
Index: linux-pm/include/linux/thermal.h
===================================================================
--- linux-pm.orig/include/linux/thermal.h
+++ linux-pm/include/linux/thermal.h
@@ -73,17 +73,14 @@ struct thermal_trip {
void *priv;
};
-struct thermal_trip_desc {
- struct thermal_trip trip;
- int threshold;
-};
-
#define THERMAL_TRIP_FLAG_RW_TEMP BIT(0)
#define THERMAL_TRIP_FLAG_RW_HYST BIT(1)
#define THERMAL_TRIP_FLAG_RW (THERMAL_TRIP_FLAG_RW_TEMP | \
THERMAL_TRIP_FLAG_RW_HYST)
+struct thermal_zone_device;
+
struct thermal_zone_device_ops {
int (*bind) (struct thermal_zone_device *,
struct thermal_cooling_device *);
@@ -130,86 +127,6 @@ struct thermal_cooling_device {
};
/**
- * struct thermal_zone_device - structure for a thermal zone
- * @id: unique id number for each thermal zone
- * @type: the thermal zone device type
- * @device: &struct device for this thermal zone
- * @removal: removal completion
- * @trip_temp_attrs: attributes for trip points for sysfs: trip temperature
- * @trip_type_attrs: attributes for trip points for sysfs: trip type
- * @trip_hyst_attrs: attributes for trip points for sysfs: trip hysteresis
- * @mode: current mode of this thermal zone
- * @devdata: private pointer for device private data
- * @num_trips: number of trip points the thermal zone supports
- * @passive_delay_jiffies: number of jiffies to wait between polls when
- * performing passive cooling.
- * @polling_delay_jiffies: number of jiffies to wait between polls when
- * checking whether trip points have been crossed (0 for
- * interrupt driven systems)
- * @temperature: current temperature. This is only for core code,
- * drivers should use thermal_zone_get_temp() to get the
- * current temperature
- * @last_temperature: previous temperature read
- * @emul_temperature: emulated temperature when using CONFIG_THERMAL_EMULATION
- * @passive: 1 if you've crossed a passive trip point, 0 otherwise.
- * @prev_low_trip: the low current temperature if you've crossed a passive
- trip point.
- * @prev_high_trip: the above current temperature if you've crossed a
- passive trip point.
- * @need_update: if equals 1, thermal_zone_device_update needs to be invoked.
- * @ops: operations this &thermal_zone_device supports
- * @tzp: thermal zone parameters
- * @governor: pointer to the governor for this thermal zone
- * @governor_data: private pointer for governor data
- * @thermal_instances: list of &struct thermal_instance of this thermal zone
- * @ida: &struct ida to generate unique id for this zone's cooling
- * devices
- * @lock: lock to protect thermal_instances list
- * @node: node in thermal_tz_list (in thermal_core.c)
- * @poll_queue: delayed work for polling
- * @notify_event: Last notification event
- * @suspended: thermal zone suspend indicator
- * @trips: array of struct thermal_trip objects
- */
-struct thermal_zone_device {
- int id;
- char type[THERMAL_NAME_LENGTH];
- struct device device;
- struct completion removal;
- struct attribute_group trips_attribute_group;
- struct thermal_attr *trip_temp_attrs;
- struct thermal_attr *trip_type_attrs;
- struct thermal_attr *trip_hyst_attrs;
- enum thermal_device_mode mode;
- void *devdata;
- int num_trips;
- unsigned long passive_delay_jiffies;
- unsigned long polling_delay_jiffies;
- int temperature;
- int last_temperature;
- int emul_temperature;
- int passive;
- int prev_low_trip;
- int prev_high_trip;
- atomic_t need_update;
- struct thermal_zone_device_ops ops;
- struct thermal_zone_params *tzp;
- struct thermal_governor *governor;
- void *governor_data;
- struct list_head thermal_instances;
- struct ida ida;
- struct mutex lock;
- struct list_head node;
- struct delayed_work poll_queue;
- enum thermal_notify_event notify_event;
- bool suspended;
-#ifdef CONFIG_THERMAL_DEBUGFS
- struct thermal_debugfs *debugfs;
-#endif
- struct thermal_trip_desc trips[] __counted_by(num_trips);
-};
-
-/**
* struct thermal_governor - structure that holds thermal governor information
* @name: name of the governor
* @bind_to_tz: callback called when binding to a thermal zone. If it
Index: linux-pm/drivers/thermal/thermal_trace.h
===================================================================
--- linux-pm.orig/drivers/thermal/thermal_trace.h
+++ linux-pm/drivers/thermal/thermal_trace.h
@@ -9,6 +9,8 @@
#include <linux/thermal.h>
#include <linux/tracepoint.h>
+#include "thermal_core.h"
+
TRACE_DEFINE_ENUM(THERMAL_TRIP_CRITICAL);
TRACE_DEFINE_ENUM(THERMAL_TRIP_HOT);
TRACE_DEFINE_ENUM(THERMAL_TRIP_PASSIVE);
^ permalink raw reply
* [PATCH v3 3/6] thermal: core: Rewrite comments in handle_thermal_trip()
From: Rafael J. Wysocki @ 2024-04-02 18:59 UTC (permalink / raw)
To: Linux PM
Cc: LKML, Srinivas Pandruvada, Daniel Lezcano, Lukasz Luba,
AngeloGioacchino Del Regno
In-Reply-To: <4558251.LvFx2qVVIh@kreacher>
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Make the comments regarding trip crossing and threshold updates in
handle_thermal_trip() slightly more clear.
No functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
v2 -> v3: New patch
---
drivers/thermal/thermal_core.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
Index: linux-pm/drivers/thermal/thermal_core.c
===================================================================
--- linux-pm.orig/drivers/thermal/thermal_core.c
+++ linux-pm/drivers/thermal/thermal_core.c
@@ -368,6 +368,13 @@ static void handle_thermal_trip(struct t
if (trip->temperature == THERMAL_TEMP_INVALID)
return;
+ /*
+ * If the trip temperature or hysteresis has been updated recently,
+ * the threshold needs to be computed again using the new values.
+ * However, its initial value still reflects the old ones and that
+ * is what needs to be compared with the previous zone temperature
+ * to decide which action to take.
+ */
if (tz->last_temperature == THERMAL_TEMP_INVALID) {
/* Initialization. */
td->threshold = trip->temperature;
@@ -375,11 +382,9 @@ static void handle_thermal_trip(struct t
td->threshold -= trip->hysteresis;
} else if (tz->last_temperature < td->threshold) {
/*
- * The trip threshold is equal to the trip temperature, unless
- * the latter has changed in the meantime. In either case,
- * the trip is crossed if the current zone temperature is at
- * least equal to its temperature, but otherwise ensure that
- * the threshold and the trip temperature will be equal.
+ * There is no mitigation under way, so it needs to be started
+ * if the zone temperature exceeds the trip one. The new
+ * threshold is then set to the low temperature of the trip.
*/
if (tz->temperature >= trip->temperature) {
thermal_notify_tz_trip_up(tz, trip);
@@ -390,14 +395,9 @@ static void handle_thermal_trip(struct t
}
} else {
/*
- * The previous zone temperature was above or equal to the trip
- * threshold, which would be equal to the "low temperature" of
- * the trip (its temperature minus its hysteresis), unless the
- * trip temperature or hysteresis had changed. In either case,
- * the trip is crossed if the current zone temperature is below
- * the low temperature of the trip, but otherwise ensure that
- * the trip threshold will be equal to the low temperature of
- * the trip.
+ * Mitigation is under way, so it needs to stop if the zone
+ * temperature falls below the low temperature of the trip.
+ * In that case, the trip temperature becomes the new threshold.
*/
if (tz->temperature < trip->temperature - trip->hysteresis) {
thermal_notify_tz_trip_down(tz, trip);
^ 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