RE: (EXT) Re: [PATCH v2 1/1] edac: fsl_ddr_edac: fix expected data message
> > drivers/edac/fsl_ddr_edac.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/edac/fsl_ddr_edac.c b/drivers/edac/fsl_ddr_edac.c
> > index 6d8ea226010d..4b6989cf1947 100644
> > --- a/drivers/edac/fsl_ddr_edac.c
> > +++ b/drivers/edac/fsl_ddr_edac.c
> > @@ -343,9 +343,9 @@ static void fsl_mc_check(struct mem_ctl_info *mci)
> >
> > fsl_mc_printk(mci, KERN_ERR,
> > "Expected Data / ECC:\t%#8.8x_%08x / %#2.2x\n",
> > - cap_high ^ (1 << (bad_data_bit - 32)),
> > - cap_low ^ (1 << bad_data_bit),
> > - syndrome ^ (1 << bad_ecc_bit));
> > + (bad_data_bit > 31) ? cap_high ^ (1 << (bad_data_bit - 32)) : cap_high,
> > + (bad_data_bit <= 31) ? cap_low ^ (1 << (bad_data_bit)) : cap_low,
>
> But if bad_data_bit is -1, this check above will hit and you'd still
> shift by -1, IINM.
You are right. It worked on my machine, but i guess that is again
machine-dependent.
> How about you fix it properly, clean it up and make it more readable in
> the process (pasting the code directly instead of a diff because a diff
> is less readable):
>
> if ((err_detect & DDR_EDE_SBE) && (bus_width == 64)) {
> sbe_ecc_decode(cap_high, cap_low, syndrome,
> &bad_data_bit, &bad_ecc_bit);
>
> if (bad_data_bit != -1) {
> if (bad_data_bit > 31)
> cap_high ^= 1 << (bad_data_bit - 32);
> else
> cap_low ^= 1 << bad_data_bit;
>
> fsl_mc_printk(mci, KERN_ERR, "Faulty Data bit: %d\n",
> bad_data_bit);
> fsl_mc_printk(mci, KERN_ERR, "Expected Data:
>%#8.8x_%08x\n",
> cap_high, cap_low);
> }
>
> if (bad_ecc_bit != -1) {
> fsl_mc_printk(mci, KERN_ERR, "Faulty ECC bit: %d\n",
> bad_ecc_bit);
> fsl_mc_printk(mci, KERN_ERR, "Expected ECC: %#2.2x\n",
> syndrome ^ (1 << bad_ecc_bit));
> }
> }
>
> This way you print only when the respective faulty bits have been
> properly found and not print anything otherwise.
The cap_low, cap_high and syndrome are used in the printk following the
if-Block.
This will make expected data / captured data look the same.
>
> Hmm?
I would prefer printing exptected data and captured data in the same format,
making it
easier to compare them directly.
diff --git a/drivers/edac/fsl_ddr_edac.c b/drivers/edac/fsl_ddr_edac.c
index 6d8ea226010d..880cf3f4712b 100644
--- a/drivers/edac/fsl_ddr_edac.c
+++ b/drivers/edac/fsl_ddr_edac.c
@@ -288,6 +288,9 @@ static void fsl_mc_check(struct mem_ctl_info *mci)
u32 cap_low;
int bad_data_bit;
int bad_ecc_bit;
+ u32 exp_high;
+ u32 exp_low;
+ u32 exp_syndrome;
err_detect = ddr_in32(pdata->mc_vbase + FSL_MC_ERR_DETECT);
if (!err_detect)
@@ -334,18 +337,32 @@ static void fsl_mc_check(struct mem_ctl_info *mci)
sbe_ecc_decode(cap_high, cap_low, syndrome,
&bad_data_bit, &bad_ecc_bit);
+ exp_high = cap_high;
+ exp_low = cap_low;
+ exp_syndrome = syndrome;
+
if (bad_data_bit != -1)
+ {
fsl_mc_printk(mci, KERN_ERR,
"Faulty Data bit: %d\n", bad_data_bit);
+
+ if (bad_data_bit < 32)
+ exp_low = cap_low ^ (1 << bad_data_bit);
+ else
+ exp_high = cap_high ^ (1 << (bad_data_bit -
32));
+ }
+
if (bad_ecc_bit != -1)
+ {
fsl_mc_printk(mci, KERN_ERR,
"Faulty ECC bit: %d\n", bad_ecc_bit);
+ exp_syndrome = syndrome ^ (1 << bad_ecc_bit);
+ }
+
fsl_mc_printk(mci, KERN_ERR,
"Expected Data / ECC:\t%#8.8x_%08x / %#2.2x\n",
- cap_high ^ (1 << (bad_data_bit - 32)),
- cap_low ^ (1 << bad_data_bit),
- syndrome ^ (1 << bad_ecc_bit));
+ exp_high, exp_low, exp_syndrome);
}
fsl_mc_printk(mci, KERN_ERR,
"Captured Data / ECC:\t%#8.8x_%08x / %#2.2x\n",
cap_high, cap_low, syndrome);
How about something like this?
Re: [PATCH v1 0/5] seqlock: Introduce PREEMPT_RT support
FWIW, can you please start a new thread with ever posting? I lost this one because it got stuck onto some ancient thread.
Re: [PATCH v2 1/3] ARM: dts: exynos: Add assigned clock parent to CMU in Exynos3250
Hi Krzysztof,
On 03.09.2020 20:14, Krzysztof Kozlowski wrote:
> Commit 52005dece527 ("ARM: dts: Add assigned clock parents to CMU node
> for exynos3250") added assigned clocks under Clock Management Unit to
> fix hangs when accessing ISP registers.
>
> However the dtschema expects "clocks" property if "assigned-clocks" are
> used. Add reference to input clock, the parent used in
> "assigned-clock-parents" to silence the dtschema warnings:
>
>arch/arm/boot/dts/exynos3250-artik5-eval.dt.yaml:
> clock-controller@1003: 'clocks' is a dependency of 'assigned-clocks'
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1. Add clocks property.
>
> This is a v2 for:
> https://lore.kernel.org/linux-samsung-soc/20200901101534.GE23793@kozik-lap/T/#me85ac382b847dadbc3f6ebf30e94e70b5df1ebb6
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index a1e93fb7f694..89b160280469 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -214,6 +214,7 @@
> compatible = "samsung,exynos3250-cmu";
> reg = <0x1003 0x2>;
> #clock-cells = <1>;
> + clocks = <&cmu CLK_FIN_PLL>;
This is not a correct input clock for this CMU. Please assign it to
xusbxti, xxti or xtcxo in the respective board dts, as this is a board
property.
> assigned-clocks = <&cmu CLK_MOUT_ACLK_400_MCUISP_SUB>,
> <&cmu CLK_MOUT_ACLK_266_SUB>;
> assigned-clock-parents = <&cmu CLK_FIN_PLL>,
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
[PATCH 0/3] Mediatek MT8192 scpsys support
This series is based on v5.9-rc1, MT8192 clock v3[1] and MT8183 scpsys v17[2]. [1] https://patchwork.kernel.org/cover/11752231/ [2] https://patchwork.kernel.org/cover/11703253/ Weiyi Lu (3): dt-bindings: soc: Add MT8192 power dt-bindings soc: mediatek: Add MT8192 scpsys support arm64: dts: Add power controller device node of MT8192 .../bindings/soc/mediatek/scpsys.txt | 5 + arch/arm64/boot/dts/mediatek/mt8192.dtsi | 148 + drivers/soc/mediatek/mtk-scpsys.c | 297 ++ include/dt-bindings/power/mt8192-power.h | 32 ++ 4 files changed, 482 insertions(+) create mode 100644 include/dt-bindings/power/mt8192-power.h
[PATCH 3/3] arm64: dts: Add power controller device node of MT8192
Add power controller node for MT8192.
In scpsys node, it contains clocks and regmapping of
infracfg for bus protection.
And list all the power domains of MT8192 under scpsys node
to show the dependency between each other through hierarchical
structure.
Signed-off-by: Weiyi Lu
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 148 +++
1 file changed, 148 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index b3fab4f..be90137 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
/ {
compatible = "mediatek,mt8192";
@@ -257,6 +258,153 @@
#interrupt-cells = <2>;
};
+ scpsys: power-controller@10006000 {
+ compatible = "mediatek,mt8192-scpsys", "syscon";
+ reg = <0 0x10006000 0 0x1000>;
+ clocks = <&topckgen CLK_TOP_AUD_INTBUS_SEL>,
+<&infracfg CLK_INFRA_AUDIO_26M_B>,
+<&infracfg CLK_INFRA_AUDIO>,
+<&infracfg CLK_INFRA_PMIC_CONN>,
+<&topckgen CLK_TOP_MFG_PLL_SEL>,
+<&topckgen CLK_TOP_DISP_SEL>,
+<&infracfg CLK_INFRA_DEVICE_APC_SYNC>,
+<&topckgen CLK_TOP_IPE_SEL>,
+<&topckgen CLK_TOP_IMG1_SEL>,
+<&topckgen CLK_TOP_IMG2_SEL>,
+<&topckgen CLK_TOP_MDP_SEL>,
+<&topckgen CLK_TOP_VENC_SEL>,
+<&topckgen CLK_TOP_VDEC_SEL>,
+<&topckgen CLK_TOP_CAM_SEL>;
+ clock-names = "audio", "audio1", "audio2", "conn",
"mfg",
+ "disp", "disp1", "ipe", "isp", "isp1",
+ "mdp", "venc", "vdec", "cam";
+ infracfg = <&infracfg>;
+ #power-domain-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio@MT8192_POWER_DOMAIN_AUDIO {
+ reg = ;
+ };
+
+ conn@MT8192_POWER_DOMAIN_CONN {
+ reg = ;
+ };
+
+ mfg@MT8192_POWER_DOMAIN_MFG0 {
+ reg = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mfg1@MT8192_POWER_DOMAIN_MFG1 {
+ reg = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mfg2@MT8192_POWER_DOMAIN_MFG2 {
+ reg =
;
+ };
+
+ mfg3@MT8192_POWER_DOMAIN_MFG3 {
+ reg =
;
+ };
+
+ mfg4@MT8192_POWER_DOMAIN_MFG4 {
+ reg =
;
+ };
+
+ mfg5@MT8192_POWER_DOMAIN_MFG5 {
+ reg =
;
+ };
+
+ mfg6@MT8192_POWER_DOMAIN_MFG6 {
+ reg =
;
+ };
+ };
+ };
+
+ disp@MT8192_POWER_DOMAIN_DISP {
+ reg = ;
+ clocks = <&mmsys CLK_MM_SMI_INFRA>,
+<&mmsys CLK_MM_SMI_COMMON>,
+<&mmsys CLK_MM_SMI_GALS>,
+<&mmsys CLK_MM_SMI_IOMMU>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ipe@MT8192_POWER_DOMAIN_IPE {
+ reg = ;
+ clocks = <&ipesys CLK_IPE_LARB19>,
+<&ipesys CLK_IPE_LARB20>,
+<&ipesys CLK_IPE_SMI_SUBCOM>,
+<&ipesys CLK_IPE_GALS>;
+ };
+
+ isp@MT8192_POWER_DOMAIN_ISP {
+ reg = ;
+
[PATCH 1/3] dt-bindings: soc: Add MT8192 power dt-bindings
Add power dt-bindings of MT8192 Signed-off-by: Weiyi Lu --- .../devicetree/bindings/soc/mediatek/scpsys.txt| 5 include/dt-bindings/power/mt8192-power.h | 32 ++ 2 files changed, 37 insertions(+) create mode 100644 include/dt-bindings/power/mt8192-power.h diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt index efe2025..7f322f9 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt @@ -16,6 +16,7 @@ power/power-domain.yaml. It provides the power domains defined in - include/dt-bindings/power/mt2712-power.h - include/dt-bindings/power/mt7622-power.h - include/dt-bindings/power/mt8183-power.h +- include/dt-bindings/power/mt8192-power.h Required properties for power controller: - compatible: Should be one of: @@ -29,6 +30,7 @@ Required properties for power controller: - "mediatek,mt7629-scpsys", "mediatek,mt7622-scpsys": For MT7629 SoC - "mediatek,mt8173-scpsys" - "mediatek,mt8183-scpsys" + - "mediatek,mt8192-scpsys" - #power-domain-cells: Must be 1 - #address-cells: Should be 1 - #size-cells: Should be 0 @@ -50,6 +52,9 @@ Required properties for power controller: Required clocks for MT8183: "audio", "audio1", "audio2", "mfg", "mm", "cam", "isp", "vpu", "vpu1", "vpu2", "vpu3"; + Required clocks for MT8192: "audio", "audio1", "audio2", "conn", "mfg", + "disp", "disp1", "ipe", "isp", "isp1", + "mdp", "venc", "vdec", "cam" Optional properties for power controller: - vdec-supply: Power supply for the vdec power domain diff --git a/include/dt-bindings/power/mt8192-power.h b/include/dt-bindings/power/mt8192-power.h new file mode 100644 index 000..4eaa53d --- /dev/null +++ b/include/dt-bindings/power/mt8192-power.h @@ -0,0 +1,32 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (c) 2020 MediaTek Inc. + * Author: Weiyi Lu + */ + +#ifndef _DT_BINDINGS_POWER_MT8192_POWER_H +#define _DT_BINDINGS_POWER_MT8192_POWER_H + +#define MT8192_POWER_DOMAIN_AUDIO 0 +#define MT8192_POWER_DOMAIN_CONN 1 +#define MT8192_POWER_DOMAIN_MFG0 2 +#define MT8192_POWER_DOMAIN_MFG1 3 +#define MT8192_POWER_DOMAIN_MFG2 4 +#define MT8192_POWER_DOMAIN_MFG3 5 +#define MT8192_POWER_DOMAIN_MFG4 6 +#define MT8192_POWER_DOMAIN_MFG5 7 +#define MT8192_POWER_DOMAIN_MFG6 8 +#define MT8192_POWER_DOMAIN_DISP 9 +#define MT8192_POWER_DOMAIN_IPE10 +#define MT8192_POWER_DOMAIN_ISP11 +#define MT8192_POWER_DOMAIN_ISP2 12 +#define MT8192_POWER_DOMAIN_MDP13 +#define MT8192_POWER_DOMAIN_VENC 14 +#define MT8192_POWER_DOMAIN_VDEC 15 +#define MT8192_POWER_DOMAIN_VDEC2 16 +#define MT8192_POWER_DOMAIN_CAM17 +#define MT8192_POWER_DOMAIN_CAM_RAWA 18 +#define MT8192_POWER_DOMAIN_CAM_RAWB 19 +#define MT8192_POWER_DOMAIN_CAM_RAWC 20 + +#endif /* _DT_BINDINGS_POWER_MT8192_POWER_H */ -- 1.8.1.1.dirty
[PATCH 2/3] soc: mediatek: Add MT8192 scpsys support
Add scpsys driver for MT8192
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 297 ++
1 file changed, 297 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index 7158863b..19a0c7e 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define MTK_POLL_DELAY_US 10
#define MTK_POLL_TIMEOUTUSEC_PER_SEC
@@ -129,6 +130,43 @@
#define MT8183_SMI_COMMON_SMI_CLAMP_VPU_TOP(BIT(5) | BIT(6))
#define MT8183_SMI_COMMON_SMI_CLAMP_VDEC BIT(7)
+#define MT8192_TOP_AXI_PROT_EN_DISP(BIT(6) | BIT(23))
+#define MT8192_TOP_AXI_PROT_EN_CONN(BIT(13) | BIT(18))
+#define MT8192_TOP_AXI_PROT_EN_CONN_2NDBIT(14)
+#define MT8192_TOP_AXI_PROT_EN_MFG1GENMASK(22, 21)
+#define MT8192_TOP_AXI_PROT_EN_1_CONN BIT(10)
+#define MT8192_TOP_AXI_PROT_EN_1_MFG1 BIT(21)
+#define MT8192_TOP_AXI_PROT_EN_1_CAM BIT(22)
+#define MT8192_TOP_AXI_PROT_EN_2_CAM BIT(0)
+#define MT8192_TOP_AXI_PROT_EN_2_ADSP BIT(3)
+#define MT8192_TOP_AXI_PROT_EN_2_AUDIO BIT(4)
+#define MT8192_TOP_AXI_PROT_EN_2_MFG1 GENMASK(6, 5)
+#define MT8192_TOP_AXI_PROT_EN_2_MFG1_2ND BIT(7)
+#define MT8192_TOP_AXI_PROT_EN_MM_CAM (BIT(0) | BIT(2))
+#define MT8192_TOP_AXI_PROT_EN_MM_DISP (BIT(0) | BIT(2) | \
+ BIT(10) | BIT(12) | \
+ BIT(14) | BIT(16) | \
+ BIT(24) | BIT(26))
+#define MT8192_TOP_AXI_PROT_EN_MM_CAM_2ND (BIT(1) | BIT(3))
+#define MT8192_TOP_AXI_PROT_EN_MM_DISP_2ND (BIT(1) | BIT(3) | \
+ BIT(15) | BIT(17) | \
+ BIT(25) | BIT(27))
+#define MT8192_TOP_AXI_PROT_EN_MM_ISP2 BIT(14)
+#define MT8192_TOP_AXI_PROT_EN_MM_ISP2_2ND BIT(15)
+#define MT8192_TOP_AXI_PROT_EN_MM_IPE BIT(16)
+#define MT8192_TOP_AXI_PROT_EN_MM_IPE_2ND BIT(17)
+#define MT8192_TOP_AXI_PROT_EN_MM_VDEC BIT(24)
+#define MT8192_TOP_AXI_PROT_EN_MM_VDEC_2ND BIT(25)
+#define MT8192_TOP_AXI_PROT_EN_MM_VENC BIT(26)
+#define MT8192_TOP_AXI_PROT_EN_MM_VENC_2ND BIT(27)
+#define MT8192_TOP_AXI_PROT_EN_MM_2_ISPBIT(8)
+#define MT8192_TOP_AXI_PROT_EN_MM_2_DISP (BIT(8) | BIT(12))
+#define MT8192_TOP_AXI_PROT_EN_MM_2_ISP_2NDBIT(9)
+#define MT8192_TOP_AXI_PROT_EN_MM_2_DISP_2ND (BIT(9) | BIT(13))
+#define MT8192_TOP_AXI_PROT_EN_MM_2_MDPBIT(12)
+#define MT8192_TOP_AXI_PROT_EN_MM_2_MDP_2NDBIT(13)
+#define MT8192_TOP_AXI_PROT_EN_VDNR_CAMBIT(21)
+
#define MAX_CLKS 3
#define MAX_SUBSYS_CLKS 10
@@ -1463,6 +1501,253 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
},
};
+/*
+ * MT8192 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt8192[] = {
+ [MT8192_POWER_DOMAIN_AUDIO] = {
+ .name = "audio",
+ .sta_mask = BIT(21),
+ .ctl_offs = 0x0354,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .basic_clk_name = {"audio", "audio1", "audio2"},
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x714, 0x718, 0x710, 0x724,
+ MT8192_TOP_AXI_PROT_EN_2_AUDIO),
+ },
+ },
+ [MT8192_POWER_DOMAIN_CONN] = {
+ .name = "conn",
+ .sta_mask = PWR_STATUS_CONN,
+ .ctl_offs = 0x0304,
+ .sram_pdn_bits = 0,
+ .sram_pdn_ack_bits = 0,
+ .basic_clk_name = {"conn"},
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0x220, 0x228,
+ MT8192_TOP_AXI_PROT_EN_CONN),
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0x220, 0x228,
+ MT8192_TOP_AXI_PROT_EN_CONN_2ND),
+ BUS_PROT(IFR_TYPE, 0x2a8, 0x2ac, 0x250, 0x258,
+ MT8192_TOP_AXI_PROT_EN_1_CONN),
+ },
+ },
+ [MT8192_POWER_DOMAIN_MFG0] = {
+ .name = "mfg",
+ .sta_mask = BIT(2),
+ .ctl_offs = 0x0308,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .basic_clk_name = {"mfg"},
+ },
+ [MT8192_POWER_DOMAIN_MFG1] = {
+
Re: [PATCH v11 3/5] arm64: kdump: reimplement crashkernel=X
On 2020/9/4 12:16, Dave Young wrote:
> On 09/04/20 at 12:02pm, chenzhou wrote:
>>
>> On 2020/9/4 11:10, Dave Young wrote:
>>> On 09/04/20 at 11:04am, Dave Young wrote:
On 09/03/20 at 07:26pm, chenzhou wrote:
> Hi Catalin,
>
>
> On 2020/9/3 1:09, Catalin Marinas wrote:
>> On Sat, Aug 01, 2020 at 09:08:54PM +0800, Chen Zhou wrote:
>>> There are following issues in arm64 kdump:
>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which
>>> will fail when there is no enough low memory.
>>> 2. If reserving crashkernel above 4G, in this case, crash dump
>>> kernel will boot failure because there is no low memory available
>>> for allocation.
>>> 3. Since commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and
>>> ZONE_DMA32"),
>>> if the memory reserved for crash dump kernel falled in ZONE_DMA32,
>>> the devices in crash dump kernel need to use ZONE_DMA will alloc
>>> fail.
>>>
>>> To solve these issues, change the behavior of crashkernel=X.
>>> crashkernel=X tries low allocation in ZONE_DMA, and fall back to
>>> high allocation if it fails.
>>>
>>> If requized size X is too large and leads to very little free memory
>>> in ZONE_DMA after low allocation, the system may not work normally.
>>> So add a threshold and go for high allocation directly if the required
>>> size is too large. The value of threshold is set as the half of
>>> the low memory.
>>>
>>> If crash_base is outside ZONE_DMA, try to allocate at least 256M in
>>> ZONE_DMA automatically. "crashkernel=Y,low" can be used to allocate
>>> specified size low memory.
>> Except for the threshold to keep zone ZONE_DMA memory,
>> reserve_crashkernel() looks very close to the x86 version. Shall we try
>> to make this generic as well? In the first instance, you could avoid the
>> threshold check if it takes an explicit ",high" option.
> Ok, i will try to do this.
>
> I look into the function reserve_crashkernel() of x86 and found the start
> address is
> CRASH_ALIGN in function memblock_find_in_range(), which is different with
> arm64.
>
> I don't figure out why is CRASH_ALIGN in x86, is there any specific
> reason?
Hmm, took another look at the option CONFIG_PHYSICAL_ALIGN
config PHYSICAL_ALIGN
hex "Alignment value to which kernel should be aligned"
default "0x20"
range 0x2000 0x100 if X86_32
range 0x20 0x100 if X86_64
According to above, I think the 16M should come from the largest value
But the default value is 2M, with smaller value reservation can have
more chance to succeed.
It seems we still need arch specific CRASH_ALIGN, but the initial
version you added the #ifdef for different arches, can you move the
macro to arch specific headers?
>>> And just keep the x86 align value as is, I can try to change the x86
>>> value later to CONFIG_PHYSICAL_ALIGN, in this way this series can be
>>> cleaner.
>> Ok. I have no question about the value of macro CRASH_ALIGN,
>> instead the lower bound of memblock_find_in_range().
>>
>> For x86, in reserve_crashkernel()，restrict the lower bound of the range to
>> CRASH_ALIGN,
>> ...
>> crash_base = memblock_find_in_range(CRASH_ALIGN,
>> CRASH_ADDR_LOW_MAX,
>> crash_size, CRASH_ALIGN);
>> ...
>>
>> in reserve_crashkernel_low()，with no this restriction.
>> ...
>> low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
>> ...
>>
>> How about all making memblock_find_in_range() search from the start of
>> memory?
>> If it is ok, i will do like this in the generic version.
> I feel starting with CRASH_ALIGN sounds better, can you just search from
> CRASH_ALIGN in generic version?
ok.
>
> Thanks
> Dave
>
>
> .
>
[PATCH] usb: core: fix slab-out-of-bounds Read in read_descriptors
The USB device descriptor may get changed between two consecutive
enumerations on the same device for some reason, such as DFU or
malicius device.
In that case, we may access the changing descriptor if we don't take
the device lock here.
The issue is reported:
https://syzkaller.appspot.com/bug?id=901a0d9e6519ef8dc7acab25344bd287dd3c7be9
Cc: stable
Cc: Alan Stern
Reported-by: syzbot+256e56ddde8b8957e...@syzkaller.appspotmail.com
Fixes: 217a9081d8e6 ("USB: add all configs to the "descriptors" attribute")
Signed-off-by: Zeng Tao
---
drivers/usb/core/sysfs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index a2ca38e..8d13419 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -889,7 +889,11 @@ read_descriptors(struct file *filp, struct kobject *kobj,
size_t srclen, n;
int cfgno;
void *src;
+ int retval;
+ retval = usb_lock_device_interruptible(udev);
+ if (retval < 0)
+ return -EINTR;
/* The binary attribute begins with the device descriptor.
* Following that are the raw descriptor entries for all the
* configurations (config plus subsidiary descriptors).
@@ -914,6 +918,7 @@ read_descriptors(struct file *filp, struct kobject *kobj,
off -= srclen;
}
}
+ usb_unlock_device(udev);
return count - nleft;
}
--
2.8.1
[PATCH 5/6] arm64: dts: qcom: qrb5165-rb5: Add gpio-line-names for TLMM block
Add gpio-line-names property for QRB5165 RB5 board for naming all GPIOs
exposed by TLMM block.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 181 +++
1 file changed, 181 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
index 312316e23298..cf6dc0ec1640 100644
--- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
+++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
@@ -431,6 +431,187 @@
&tlmm {
gpio-reserved-ranges = <40 4>;
+ gpio-line-names =
+ "GPIO-MM",
+ "GPIO-NN",
+ "GPIO-OO",
+ "GPIO-PP",
+ "GPIO-A",
+ "GPIO-C",
+ "GPIO-E",
+ "GPIO-D",
+ "I2C0-SDA",
+ "I2C0-SCL",
+ "GPIO-TT", /* GPIO_10 */
+ "NC",
+ "GPIO_12_I2C_SDA",
+ "GPIO_13_I2C_SCL",
+ "GPIO-X",
+ "GPIO_15_RGMII_INT",
+ "HST_BT_UART_CTS",
+ "HST_BT_UART_RFR",
+ "HST_BT_UART_TX",
+ "HST_BT_UART_RX",
+ "HST_WLAN_EN", /* GPIO_20 */
+ "HST_BT_EN",
+ "GPIO-AAA",
+ "GPIO-BBB",
+ "GPIO-CCC",
+ "GPIO-Z",
+ "GPIO-DDD",
+ "GPIO-BB",
+ "GPIO_28_CAN_SPI_MISO",
+ "GPIO_29_CAN_SPI_MOSI",
+ "GPIO_30_CAN_SPI_CLK", /* GPIO_30 */
+ "GPIO_31_CAN_SPI_CS",
+ "GPIO-UU",
+ "NC",
+ "UART1_TXD_SOM",
+ "UART1_RXD_SOM",
+ "UART0_CTS",
+ "UART0_RTS",
+ "UART0_TXD",
+ "UART0_RXD",
+ "SPI1_MISO", /* GPIO_40 */
+ "SPI1_MOSI",
+ "SPI1_CLK",
+ "SPI1_CS",
+ "I2C1_SDA",
+ "I2C1_SCL",
+ "GPIO-F",
+ "GPIO-JJ",
+ "Board_ID1",
+ "Board_ID2",
+ "NC", /* GPIO_50 */
+ "NC",
+ "SPI0_MISO",
+ "SPI0_MOSI",
+ "SPI0_SCLK",
+ "SPI0_CS",
+ "GPIO-QQ",
+ "GPIO-RR",
+ "USB2LAN_RESET",
+ "USB2LAN_EXTWAKE",
+ "NC", /* GPIO_60 */
+ "NC",
+ "NC",
+ "LT9611_INT",
+ "GPIO-AA",
+ "USB_CC_DIR",
+ "GPIO-G",
+ "GPIO-LL",
+ "USB_DP_HPD_1P8",
+ "NC",
+ "NC", /* GPIO_70 */
+ "SD_CMD",
+ "SD_DAT3",
+ "SD_SCLK",
+ "SD_DAT2",
+ "SD_DAT1",
+ "SD_DAT0", /* BOOT_CFG3 */
+ "SD_UFS_CARD_DET_N",
+ "GPIO-II",
+ "PCIE0_RST_N",
+ "PCIE0_CLK_REQ_N", /* GPIO_80 */
+ "PCIE0_WAKE_N",
+ "GPIO-CC",
+ "GPIO-DD",
+ "GPIO-EE",
+ "GPIO-FF",
+ "GPIO-GG",
+ "GPIO-HH",
+ "GPIO-VV",
+ "GPIO-WW",
+ "NC", /* GPIO_90 */
+ "NC",
+ "GPIO-K",
+ "GPIO-I",
+ "CSI0_MCLK",
+ "CSI1_MCLK",
+ "CSI2_MCLK",
+ "CSI3_MCLK",
+ "GPIO-AA", /* CSI4_MCLK */
+ "GPIO-BB", /* CSI5_MCLK */
+ "GPIO-KK", /* GPIO_100 */
+ "CCI_I2C_SDA0",
+ "CCI_I2C_SCL0",
+ "CCI_I2C_SDA1",
+ "CCI_I2C_SCL1",
+ "CCI_I2C_SDA2",
+ "CCI_I2C_SCL2",
+ "CCI_I2C_SDA3",
+ "CCI_I2C_SCL3",
+ "GPIO-L",
+ "NC", /* GPIO_110 */
+ "NC",
+ "ACCEL_INT",
+ "GYRO_INT",
+ "GPIO-J",
+ "GPIO-YY",
+ "GPIO-H",
+ "GPIO-ZZ",
+ "NC",
+ "NC",
+ "NC", /* GPIO_120 */
+ "NC",
+ "MAG_INT",
+ "MAG_DRDY_INT",
+ "HST_SW_CTRL",
+ "GPIO-M",
+ "GPIO-N",
+ "GPIO-O",
+ "GPIO-P",
+ "PS_INT",
+ "WSA1_EN", /* GPIO_130 */
+ "USB_HUB_RESET",
+ "SDM_FORCE_USB_BOOT",
+ "I2S1_CLK_HDMI",
+ "I2S1_DATA0_HDMI",
+ "I2S1_WS_HDMI",
+ "GPIO-B",
+ "GPIO_137", /* To LT9611_I2S_MCLK_3V3 */
+ "PCM_CLK",
+ "PCM_DI",
+ "PCM_DO", /* GPIO_140 */
+ "PCM_FS",
+ "HST_SLIM_CLK",
+ "HST_SLIM_DATA",
+ "GPIO-U",
+ "GPIO-Y
[PATCH 4/6] arm64: dts: qcom: qrb5165-rb5: Add onboard LED support
Only User4, WLAN and BT LEDs are added for now. These GPIOs are coming
from PM8150. Rest are coming from LPG block which is not supported yet!
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 26
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
index f201e064b3e7..312316e23298 100644
--- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
+++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
@@ -32,6 +32,32 @@
regulator-always-on;
};
+ leds {
+ compatible = "gpio-leds";
+
+ user4 {
+ label = "green:user4";
+ gpios = <&pm8150_gpios 10 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "panic-indicator";
+ default-state = "off";
+ };
+
+ wlan {
+ label = "yellow:wlan";
+ gpios = <&pm8150_gpios 9 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "phy0tx";
+ default-state = "off";
+ };
+
+ bt {
+ label = "blue:bt";
+ gpios = <&pm8150_gpios 7 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "bluetooth-power";
+ default-state = "off";
+ };
+
+ };
+
vbat: vbat-regulator {
compatible = "regulator-fixed";
regulator-name = "VBAT";
--
2.17.1
Re: [PATCH 12/14] x86: remove address space overrides using set_fs()
On Fri, Sep 04, 2020 at 03:55:10AM +0100, Al Viro wrote: > On Thu, Sep 03, 2020 at 04:22:40PM +0200, Christoph Hellwig wrote: > > > diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S > > index c8a85b512796e1..94f7be4971ed04 100644 > > --- a/arch/x86/lib/getuser.S > > +++ b/arch/x86/lib/getuser.S > > @@ -35,10 +35,19 @@ > > #include > > #include > > > > +#ifdef CONFIG_X86_5LEVEL > > +#define LOAD_TASK_SIZE_MINUS_N(n) \ > > + ALTERNATIVE "mov $((1 << 47) - 4096 - (n)),%rdx", \ > > + "mov $((1 << 56) - 4096 - (n)),%rdx", X86_FEATURE_LA57 > > +#else > > +#define LOAD_TASK_SIZE_MINUS_N(n) \ > > + mov $(TASK_SIZE_MAX - (n)),%_ASM_DX > > +#endif > > Wait a sec... how is that supposed to build with X86_5LEVEL? Do you mean > > #define LOAD_TASK_SIZE_MINUS_N(n) \ > ALTERNATIVE __stringify(mov $((1 << 47) - 4096 - (n)),%rdx), \ > __stringify(mov $((1 << 56) - 4096 - (n)),%rdx), > X86_FEATURE_LA57 > > there? Don't ask me about the how, but it builds and works with X86_5LEVEL, and the style is copied from elsewhere..
linux-kernel@vger.kernel.org
Add gpio-line-names for the GPIO pins exposed by PM8150, PM8150B and
PM8150L PMIC nodes.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 47
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
index cf6dc0ec1640..1528a865f1f8 100644
--- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
+++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
@@ -412,6 +412,53 @@
status = "okay";
};
+&pm8150_gpios {
+ gpio-reserved-ranges = <1 1>, <3 2>, <7 1>;
+ gpio-line-names =
+ "NC",
+ "OPTION2",
+ "PM_GPIO-F",
+ "PM_SLP_CLK_IN",
+ "OPTION1",
+ "VOL_UP_N",
+ "PM8250_GPIO7", /* Blue LED */
+ "SP_ARI_PWR_ALARM",
+ "GPIO_9_P", /* Yellow LED */
+ "GPIO_10_P"; /* Green LED */
+};
+
+&pm8150b_gpios {
+ gpio-line-names =
+ "NC",
+ "NC",
+ "NC",
+ "NC",
+ "HAP_BOOST_EN", /* SOM */
+ "SMB_STAT", /* SOM */
+ "NC",
+ "NC",
+ "SDM_FORCE_USB_BOOT",
+ "NC",
+ "NC",
+ "NC";
+};
+
+&pm8150l_gpios {
+ gpio-line-names =
+ "NC",
+ "PM3003A_EN",
+ "NC",
+ "NC",
+ "PM_GPIO5", /* HDMI RST_N */
+ "PM_GPIO-A", /* PWM */
+ "PM_GPIO7",
+ "NC",
+ "NC",
+ "PM_GPIO-B",
+ "NC",
+ "PM3003A_MODE";
+};
+
&qupv3_id_0 {
status = "okay";
};
--
2.17.1
[PATCH 3/6] arm64: dts: qcom: Add basic devicetree support for QRB5165 RB5
Add basic devicetree support for Qualcomm Technologies, Inc. Robotics
RB5 platform. This board is one of the 96Boards CE platform targeted for
Robotics usecases from Qualcomm.
This basic devicetree support includes regulators, onboard debug UART,
I2C, SPI, and UFS support.
Co-developed-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/qcom/Makefile| 1 +
arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 432 +++
2 files changed, 433 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index d8f1466e6758..05d21ba311f9 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -35,3 +35,4 @@ dtb-$(CONFIG_ARCH_QCOM) += sm8150-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sm8250-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-1000.dtb
dtb-$(CONFIG_ARCH_QCOM)+= qcs404-evb-4000.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= qrb5165-rb5.dtb
diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
new file mode 100644
index ..f201e064b3e7
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
@@ -0,0 +1,432 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2020, Linaro Ltd.
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "sm8250.dtsi"
+#include "pm8150.dtsi"
+#include "pm8150b.dtsi"
+#include "pm8150l.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. Robotics RB5";
+ compatible = "qcom,qrb5165-rb5", "qcom,sm8250";
+
+ aliases {
+ serial0 = &uart12;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ dc12v: dc12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "DC12V";
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ regulator-always-on;
+ };
+
+ vbat: vbat-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT";
+ vin-supply = <&vreg_l11c_3p3>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vbat_som: vbat-som-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VBAT_SOM";
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <420>;
+ regulator-max-microvolt = <420>;
+ regulator-always-on;
+ };
+
+ vdc_3v3: vdc-3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_3V3";
+ vin-supply = <&dc12v>;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ vdc_5v: vdc-5v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "VDC_5V";
+
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ vin-supply = <&vreg_l11c_3p3>;
+ };
+
+ vph_pwr: vph-pwr-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <370>;
+ regulator-max-microvolt = <370>;
+ regulator-always-on;
+ };
+
+ vreg_s4a_1p8: vreg-s4a-1p8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_s4a_1p8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+};
+
+&apps_rsc {
+ pm8009-rpmh-regulators {
+ compatible = "qcom,pm8009-rpmh-regulators";
+ qcom,pmic-id = "f";
+
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-l2-supply = <&vreg_s8c_1p3>;
+ vdd-l5-l6-supply = <&vreg_bob>;
+ vdd-l7-supply = <&vreg_s4a_1p8>;
+
+ vreg_l1f_1p1: ldo1 {
+ regulator-name = "vreg_l1f_1p1";
+ regulator-min-microvolt = <1104000>;
+ regulator-max-microvolt = <1104000>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l2f_1p2: ldo2 {
+ regulator-name = "vreg_l2f_1p2";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-initial-mode = ;
+ };
+
+ vreg_l6f_2p8: ldo6 {
+ regulato
[PATCH 2/6] arm64: dts: qcom: sm8250: Rename UART2 node to UART12
The UART12 node has been mistakenly mentioned as UART2. Let's fix that
for both SM8250 SoC and MTP board and also add pinctrl definition for
it.
Fixes: 60378f1a171e ("arm64: dts: qcom: sm8250: Add sm8250 dts file")
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/qcom/sm8250-mtp.dts | 4 ++--
arch/arm64/boot/dts/qcom/sm8250.dtsi| 11 ++-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-mtp.dts
b/arch/arm64/boot/dts/qcom/sm8250-mtp.dts
index 6894f8490dae..6e2f7ae1d621 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8250-mtp.dts
@@ -17,7 +17,7 @@
compatible = "qcom,sm8250-mtp";
aliases {
- serial0 = &uart2;
+ serial0 = &uart12;
};
chosen {
@@ -371,7 +371,7 @@
gpio-reserved-ranges = <28 4>, <40 4>;
};
-&uart2 {
+&uart12 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 377172e8967b..e7d139e1a6ce 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -935,11 +935,13 @@
status = "disabled";
};
- uart2: serial@a9 {
+ uart12: serial@a9 {
compatible = "qcom,geni-debug-uart";
reg = <0x0 0x00a9 0x0 0x4000>;
clock-names = "se";
clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_uart12_default>;
interrupts = ;
status = "disabled";
};
@@ -1880,6 +1882,13 @@
bias-disable;
};
};
+
+ qup_uart12_default: qup-uart12-default {
+ mux {
+ pins = "gpio34", "gpio35";
+ function = "qup12";
+ };
+ };
};
adsp: remoteproc@1730 {
--
2.17.1
[PATCH 1/6] dt-bindings: arm: qcom: Document SM8250 SoC and boards
Document the SM8250 SoC binding and also the boards using it. Signed-off-by: Manivannan Sadhasivam --- Documentation/devicetree/bindings/arm/qcom.yaml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 6031aee0f5a8..1adc8a33a3e4 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -40,6 +40,7 @@ description: | sdm630 sdm660 sdm845 +sm8250 The 'board' element must be one of the following strings: @@ -165,4 +166,10 @@ properties: - qcom,ipq6018-cp01-c1 - const: qcom,ipq6018 + - items: + - enum: + - qcom,qrb5165-rb5 + - qcom,sm8250-mtp + - const: qcom,sm8250 + ... -- 2.17.1
[PATCH 0/6] Add initial support for Qualcomm RB5 platform
Hello, This series adds initial support for Qualcomm Robotics RB5 Platform based on QRB5165 SoC which is a derivative of SM8250 SoC customized for robotics applications. This board is one of the Consumer Edition boards of the 96Boards family manufactured by Thundercomm. This initial support includes regulators, UFS, debug UART, I2C, SPI, GPIO and LED peripherals. More information about this board can be found in Qualcomm website: https://www.qualcomm.com/products/qualcomm-robotics-rb5-platform This series functionally depends on following patches for proper working: irqchip: Fix probing deferal when using IRQCHIP_PLATFORM_DRIVER helpers arm64: dts: qcom: sm8250: add apps_smmu node Thanks, Mani Manivannan Sadhasivam (6): dt-bindings: arm: qcom: Document SM8250 SoC and boards arm64: dts: qcom: sm8250: Rename UART2 node to UART12 arm64: dts: qcom: Add basic devicetree support for QRB5165 RB5 arm64: dts: qcom: qrb5165-rb5: Add onboard LED support arm64: dts: qcom: qrb5165-rb5: Add gpio-line-names for TLMM block arm64: dts: qcom: qrb5165-rb5: Add gpio-line-names for PM8150(B&L) .../devicetree/bindings/arm/qcom.yaml | 7 + arch/arm64/boot/dts/qcom/Makefile | 1 + arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 686 ++ arch/arm64/boot/dts/qcom/sm8250-mtp.dts | 4 +- arch/arm64/boot/dts/qcom/sm8250.dtsi | 11 +- 5 files changed, 706 insertions(+), 3 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts -- 2.17.1
Re: [PATCH 3/6] mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.14
On Thu, Sep 03, 2020 at 04:24:38PM -0700, Douglas Anderson wrote:
> This is like commit 3d3451124f3d ("mmc: sdhci-msm: Prefer asynchronous
> probe") but applied to a whole pile of drivers. This batch converts
> the drivers that appeared to be around in the v4.14 timeframe.
The LTS granularity of patches is a nice idea! I will keep it in mind.
>
> Signed-off-by: Douglas Anderson
In general, I like more coverage of async probing. It makes sense for
SD/MMC, I think.
Reviewed-by: Wolfram Sang
> drivers/mmc/host/renesas_sdhi_internal_dmac.c | 1 +
> drivers/mmc/host/renesas_sdhi_sys_dmac.c | 1 +
For these two also:
Tested-by: Wolfram Sang # SDHI drivers
The speedups somewhat match the expected values and no regressions when
checksumming a large file.
signature.asc
Description: PGP signature
Re: [PATCH v2] staging: media: atomisp: Fix error path in lm3554_probe()
On Thu, Sep 03, 2020 at 07:24:51PM +0100, Alex Dewar wrote: > + > + ret = atomisp_register_i2c_module(&flash->sd, NULL, LED_FLASH); > + if (!ret) > + return 0; Ugh!!! This is a a special case of the "success handling instead of failure handling" anti-pattern where the last condition in the function is different. I just fixed a bug caused by this on Wed. https://www.spinics.net/lists/netdev/msg680226.html But it doesn't cause any problems here so whatever... Reviewed-by: Dan Carpenter regards, dan carpenter
Re: [PATCH] mm/memory_hotplug: drain per-cpu pages again during memory offline
On 9/3/20 8:23 PM, Pavel Tatashin wrote: >> >> As expressed in reply to v2, I dislike this hack. There is strong >> synchronization, just PCP is special. Allocating from MIGRATE_ISOLATE is >> just plain ugly. >> >> Can't we temporarily disable PCP (while some pageblock in the zone is >> isolated, which we know e.g., due to the counter), so no new pages get >> put into PCP lists after draining, and re-enable after no pageblocks are >> isolated again? We keep draining the PCP, so it doesn't seem to be of a >> lot of use during that period, no? It's a performance hit already. >> >> Then, we would only need exactly one drain. And we would only have to >> check on the free path whether PCP is temporarily disabled. > > Hm, we could use a static branches to disable it, that would keep > release code just as fast, but I am worried it will make code even > uglier. Let's see what others in this thread think about this idea. Maybe we could just set pcp->high = 0 or something, make sure the pcplist user only reads this value while irqs are disabled. Then the the IPI in drain_all_pages() should guarantee there's nobody racing freeing to pcplist. But careful to not introduce bugs like the one fixed with [1]. And not sure if this guarantee survives when RT comes and replaces the disabled irq's with local_lock or something. [1] https://lore.kernel.org/linux-mm/1597150703-19003-1-git-send-email-chara...@codeaurora.org/ > Thank you, > Pasha >
Re: [PATCH v5 2/2] Add Intel LGM soc DMA support.
On 31/08/2020 11.07, Reddy, MallikarjunaX wrote:
>
> On 8/28/2020 7:17 PM, Peter Ujfalusi wrote:
>> Hi,
>>
>> On 27/08/2020 17.41, Reddy, MallikarjunaX wrote:
>>> +
>>> + dma_dev->device_alloc_chan_resources =
>>> + d->inst->ops->device_alloc_chan_resources;
>>> + dma_dev->device_free_chan_resources =
>>> + d->inst->ops->device_free_chan_resources;
>>> + dma_dev->device_terminate_all =
>>> d->inst->ops->device_terminate_all;
>>> + dma_dev->device_issue_pending =
>>> d->inst->ops->device_issue_pending;
>>> + dma_dev->device_tx_status = d->inst->ops->device_tx_status;
>>> + dma_dev->device_resume = d->inst->ops->device_resume;
>>> + dma_dev->device_pause = d->inst->ops->device_pause;
>>> + dma_dev->device_config = d->inst->ops->device_config;
>>> + dma_dev->device_prep_slave_sg =
>>> d->inst->ops->device_prep_slave_sg;
>>> + dma_dev->device_synchronize = d->inst->ops->device_synchronize;
>>> +
>>> + if (d->ver == DMA_VER22) {
>>> + dma_dev->src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
>>> + dma_dev->dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
>>> + dma_dev->directions = BIT(DMA_MEM_TO_DEV) |
>>> + BIT(DMA_DEV_TO_MEM);
>>> + dma_dev->residue_granularity =
>>> + DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
>>> + }
>> So, if version is != DMA_VER22, then you don't support any direction?
>> Why register the DMA device if it can not do any transfer?
> Only dma0 instance (intel,lgm-cdma) is used as a general purpose slave
> DMA. we set both control and datapath here.
> Other instances we set only control path. data path is taken care
> by dma
> client(GSWIP).
How the client (GSWIP) can request a channel from intel,lgm-* ? Don't
you need some capabilities for the DMA device so core can sort out the
request?
>>> client request channel by name, dma_request_slave_channel(dev, name);
>> clients should use dma_request_chan(dev, name);
>>
>> If the channel can be requested via DT or ACPI then we don't check the
>> capabilities at all, so yes, that could work.
>>
> Only thing needs to do is get the channel, set the descriptor and just
> on the channel.
How do you 'on' the channel?
>>> we on the channel in issue_pending.
>> Right.
>> Basically you only prep_slave_sg/single for the DMA_VER22? Or do you
>> that for the others w/o direction support?
>
> Yes. prep_slave_sg/single only for the DMA_VER22.
So, you place the transfers to DMA_VER22's channel
>>
>> For the intel,lgm-* DMAs you only call issue_pending() and probably
>> terminate_all?
> Yes, correct.
and issue_pending on a channel which does not have anything pending?
How client knows which of the 'only need to be ON' channel to enable
when it placed a transfer to another channel?
How would the client driver (and the IP) would be integrated with
different system DMA which have standard channel management?
If DMA_VER22 knows which intel,lgm-* it should place the transfer then
with virt-dma you can handle that just fine?
Do you have public documentation for the DMA? It sounds a bit like TI's
EDMA which is in essence is a two part setup:
CC: Channel Controller - to submit transfers (like your DMA_VER22)
TC: Transfer Controller - it executes the transfers submitted by the CC
One CC can be backed by multiple TCs. I don't have direct control over
the TC (can not start/stop), it is controlled by the CC.
Documentation/devicetree/bindings/dma/ti-edma.txt
Or is it a different setup?
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v5 1/2] dt-bindings: dma: Add bindings for intel LGM SOC
On 18/08/2020 10.00, Reddy, MallikarjunaX wrote: > Hi Rob, > Thanks for your valuable comments. Please see my comments inline.. > > On 8/15/2020 4:32 AM, Rob Herring wrote: >> On Fri, Aug 14, 2020 at 01:26:09PM +0800, Amireddy Mallikarjuna reddy >> wrote: >>> Add DT bindings YAML schema for DMA controller driver >>> of Lightning Mountain(LGM) SoC. >>> >>> Signed-off-by: Amireddy Mallikarjuna reddy >>> >>> --- >>> v1: >>> - Initial version. >>> >>> v2: >>> - Fix bot errors. >>> >>> v3: >>> - No change. >>> >>> v4: >>> - Address Thomas langer comments >>> - use node name pattern as dma-controller as in common binding. >>> - Remove "_" (underscore) in instance name. >>> - Remove "port-" and "chan-" in attribute name for both >>> 'dma-ports' & 'dma-channels' child nodes. >>> >>> v5: >>> - Moved some of the attributes in 'dma-ports' & 'dma-channels' child >>> nodes to dma client/consumer side as cells in 'dmas' properties. >>> --- >>> .../devicetree/bindings/dma/intel,ldma.yaml | 319 >>> + >>> 1 file changed, 319 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/dma/intel,ldma.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/dma/intel,ldma.yaml >>> b/Documentation/devicetree/bindings/dma/intel,ldma.yaml >>> new file mode 100644 >>> index ..9beaf191a6de >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/dma/intel,ldma.yaml >>> @@ -0,0 +1,319 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/dma/intel,ldma.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Lightning Mountain centralized low speed DMA and high speed >>> DMA controllers. >>> + >>> +maintainers: >>> + - chuanhua@intel.com >>> + - mallikarjunax.re...@intel.com >>> + >>> +allOf: >>> + - $ref: "dma-controller.yaml#" >>> + >>> +properties: >>> + $nodename: >>> + pattern: "^dma-controller(@.*)?$" >>> + >>> + "#dma-cells": >>> + const: 1 >> Example says 3. > OK, i will fix it. It would help if you would add description of what is the meaning of the individual cell. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 03/14] arm64: dts: imx8mm-evk: Align pin configuration group names with schema
Device tree schema expects pin configuration groups to end with 'grp'
suffix, otherwise dtbs_check complain with a warning like:
... do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
index 1c39a2b90ee1..27e54583a8e4 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
@@ -456,13 +456,13 @@
>;
};
- pinctrl_pmic: pmicirq {
+ pinctrl_pmic: pmicirqgrp {
fsl,pins = <
MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
>;
};
- pinctrl_reg_usdhc2_vmmc: regusdhc2vmmc {
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
>;
@@ -490,7 +490,7 @@
>;
};
- pinctrl_usdhc2_gpio: usdhc2grpgpio {
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
fsl,pins = <
MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x1c4
>;
@@ -508,7 +508,7 @@
>;
};
- pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194
MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4
@@ -520,7 +520,7 @@
>;
};
- pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196
MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6
@@ -548,7 +548,7 @@
>;
};
- pinctrl_usdhc3_100mhz: usdhc3grp100mhz {
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x194
MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d4
@@ -564,7 +564,7 @@
>;
};
- pinctrl_usdhc3_200mhz: usdhc3grp200mhz {
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x196
MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d6
--
2.17.1
[PATCH v2 05/14] arm64: dts: imx8mn-ddr4-evk: Align regulator names with schema
Device tree schema expects regulator names to be lowercase. Changing to
lowercase has multiple effects:
1. LDO6 supply is now properly configured, because regulator driver
looks for supplies by lowercase name,
2. User-visible names via sysfs or debugfs are now lowercase,
2. dtbs_check warnings are fixed:
pmic@4b: regulators:LDO1:regulator-name:0: 'LDO1' does not match
'^ldo[1-6]$'
Signed-off-by: Krzysztof Kozlowski
---
.../boot/dts/freescale/imx8mn-ddr4-evk.dts| 22 +--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
index 3ac8f9d3c372..8f7155716c84 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
@@ -60,7 +60,7 @@
regulators {
buck1_reg: BUCK1 {
- regulator-name = "BUCK1";
+ regulator-name = "buck1";
regulator-min-microvolt = <70>;
regulator-max-microvolt = <130>;
regulator-boot-on;
@@ -69,7 +69,7 @@
};
buck2_reg: BUCK2 {
- regulator-name = "BUCK2";
+ regulator-name = "buck2";
regulator-min-microvolt = <70>;
regulator-max-microvolt = <130>;
regulator-boot-on;
@@ -79,14 +79,14 @@
buck3_reg: BUCK3 {
// BUCK5 in datasheet
- regulator-name = "BUCK3";
+ regulator-name = "buck3";
regulator-min-microvolt = <70>;
regulator-max-microvolt = <135>;
};
buck4_reg: BUCK4 {
// BUCK6 in datasheet
- regulator-name = "BUCK4";
+ regulator-name = "buck4";
regulator-min-microvolt = <300>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -95,7 +95,7 @@
buck5_reg: BUCK5 {
// BUCK7 in datasheet
- regulator-name = "BUCK5";
+ regulator-name = "buck5";
regulator-min-microvolt = <1605000>;
regulator-max-microvolt = <1995000>;
regulator-boot-on;
@@ -104,7 +104,7 @@
buck6_reg: BUCK6 {
// BUCK8 in datasheet
- regulator-name = "BUCK6";
+ regulator-name = "buck6";
regulator-min-microvolt = <80>;
regulator-max-microvolt = <140>;
regulator-boot-on;
@@ -112,7 +112,7 @@
};
ldo1_reg: LDO1 {
- regulator-name = "LDO1";
+ regulator-name = "ldo1";
regulator-min-microvolt = <160>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -120,7 +120,7 @@
};
ldo2_reg: LDO2 {
- regulator-name = "LDO2";
+ regulator-name = "ldo2";
regulator-min-microvolt = <80>;
regulator-max-microvolt = <90>;
regulator-boot-on;
@@ -128,7 +128,7 @@
};
ldo3_reg: LDO3 {
- regulator-name = "LDO3";
+ regulator-name = "ldo3";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -136,7 +136,7 @@
};
ldo4_reg: LDO4 {
- regulator-name = "LDO4";
+ regulator-name = "ldo4";
regulator-min-microvolt = <90>;
regulator-max-microvolt = <180>;
regulator-boot-on;
@@ -144,7 +144,7 @@
};
ldo6_reg: LDO6 {
- regulator-name = "LDO6";
+
[PATCH v2 06/14] arm64: dts: imx8mn-evk: Align pin configuration group names with schema
Device tree schema expects pin configuration groups to end with 'grp'
suffix, otherwise dtbs_check complain with a warning like:
... do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
index 76e0225729b1..7f4b904e9982 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
@@ -223,13 +223,13 @@
>;
};
- pinctrl_pmic: pmicirq {
+ pinctrl_pmic: pmicirqgrp {
fsl,pins = <
MX8MN_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
>;
};
- pinctrl_reg_usdhc2_vmmc: regusdhc2vmmc {
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
fsl,pins = <
MX8MN_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
>;
@@ -248,7 +248,7 @@
>;
};
- pinctrl_usdhc2_gpio: usdhc2grpgpio {
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
fsl,pins = <
MX8MN_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x1c4
>;
@@ -266,7 +266,7 @@
>;
};
- pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
fsl,pins = <
MX8MN_IOMUXC_SD2_CLK_USDHC2_CLK 0x194
MX8MN_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4
@@ -278,7 +278,7 @@
>;
};
- pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
fsl,pins = <
MX8MN_IOMUXC_SD2_CLK_USDHC2_CLK 0x196
MX8MN_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6
@@ -306,7 +306,7 @@
>;
};
- pinctrl_usdhc3_100mhz: usdhc3grp100mhz {
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
fsl,pins = <
MX8MN_IOMUXC_NAND_WE_B_USDHC3_CLK
0x4194
MX8MN_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d4
@@ -322,7 +322,7 @@
>;
};
- pinctrl_usdhc3_200mhz: usdhc3grp200mhz {
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
fsl,pins = <
MX8MN_IOMUXC_NAND_WE_B_USDHC3_CLK
0x4196
MX8MN_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d6
--
2.17.1
[PATCH v2 08/14] arm64: dts: imx8mq-librem5-devkit: Align pin configuration group names with schema
Device tree schema expects pin configuration groups to end with 'grp'
suffix, otherwise dtbs_check complain with a warning like:
... do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
.../boot/dts/freescale/imx8mq-librem5-devkit.dts | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
b/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
index a80e53428c2f..10f30ff85fd3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
@@ -735,7 +735,7 @@
>;
};
- pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x8d
MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xcd
@@ -752,7 +752,7 @@
>;
};
- pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x9f
MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xdf
@@ -769,13 +769,13 @@
>;
};
- pinctrl_usdhc2_pwr: usdhc2grppwr {
+ pinctrl_usdhc2_pwr: usdhc2pwrgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
>;
};
- pinctrl_usdhc2_gpio: usdhc2grpgpio {
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_WP_GPIO2_IO20 0x80 /*
WIFI_WAKE */
>;
@@ -792,7 +792,7 @@
>;
};
- pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x8d
MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcd
@@ -803,7 +803,7 @@
>;
};
- pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x9f
MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcf
--
2.17.1
[PATCH v2 14/14] ARM: dts: imx28-m28: Align GPMI NAND node name with schema
Device tree schema expects NAND controller to be named
"nand-controller", otherwise dtbs_check complain with a warning like:
arch/arm/boot/dts/imx28-eukrea-mbmx283lc.dt.yaml: gpmi-nand@8000c000:
$nodename:0: 'gpmi-nand@8000c000' does not match
'^nand-controller(@.*)?'
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Rebase on already applied similar patches
---
arch/arm/boot/dts/imx28-m28.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx28-m28.dtsi b/arch/arm/boot/dts/imx28-m28.dtsi
index 0bac72d5351f..2bdb4c093545 100644
--- a/arch/arm/boot/dts/imx28-m28.dtsi
+++ b/arch/arm/boot/dts/imx28-m28.dtsi
@@ -16,7 +16,7 @@
apb@8000 {
apbh@8000 {
- gpmi-nand@8000c000 {
+ nand-controller@8000c000 {
#address-cells = <1>;
#size-cells = <1>;
pinctrl-names = "default";
--
2.17.1
[PATCH v2 11/14] arm64: dts: imx8mq-sr-som: Align pin configuration group names with schema
Device tree schema expects pin configuration groups to end with 'grp'
suffix, otherwise dtbs_check complain with a warning like:
... do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
index 404c46671b96..0187890a90c5 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-sr-som.dtsi
@@ -275,7 +275,7 @@
>;
};
- pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x8d
MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xcd
@@ -292,7 +292,7 @@
>;
};
- pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x9f
MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xdf
--
2.17.1
[PATCH v2 10/14] arm64: dts: imx8mq-pico-pi: Align pin configuration group names with schema
Device tree schema expects pin configuration groups to end with 'grp'
suffix, otherwise dtbs_check complain with a warning like:
... do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mq-pico-pi.dts | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-pico-pi.dts
b/arch/arm64/boot/dts/freescale/imx8mq-pico-pi.dts
index 59da96b7143f..f4d5748a7bd6 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-pico-pi.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-pico-pi.dts
@@ -297,7 +297,7 @@
>;
};
- pinctrl_pmic: pmicirq {
+ pinctrl_pmic: pmicirqgrp {
fsl,pins = <
MX8MQ_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
>;
@@ -335,7 +335,7 @@
>;
};
- pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x85
MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc5
@@ -351,7 +351,7 @@
>;
};
- pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x87
MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc7
@@ -367,7 +367,7 @@
>;
};
- pinctrl_usdhc2_gpio: usdhc2grpgpio {
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_CD_B_GPIO2_IO120x41
>;
@@ -385,7 +385,7 @@
>;
};
- pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x85
MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc5
@@ -397,7 +397,7 @@
>;
};
- pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x87
MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc7
--
2.17.1
[PATCH v2 09/14] arm64: dts: imx8mq-phanbell: Align pin configuration group names with schema
Device tree schema expects pin configuration groups to end with 'grp'
suffix, otherwise dtbs_check complain with a warning like:
... do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mq-phanbell.dts | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-phanbell.dts
b/arch/arm64/boot/dts/freescale/imx8mq-phanbell.dts
index 3f541ddf0768..d6d3a3d5abc3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-phanbell.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-phanbell.dts
@@ -365,7 +365,7 @@
>;
};
- pinctrl_pmic: pmicirq {
+ pinctrl_pmic: pmicirqgrp {
fsl,pins = <
MX8MQ_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
>;
@@ -395,7 +395,7 @@
>;
};
- pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x85
MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc5
@@ -412,7 +412,7 @@
>;
};
- pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x87
MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD 0xc7
@@ -429,7 +429,7 @@
>;
};
- pinctrl_usdhc2_gpio: usdhc2grpgpio {
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_CD_B_GPIO2_IO120x41
MX8MQ_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
@@ -448,7 +448,7 @@
>;
};
- pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x85
MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc5
@@ -460,7 +460,7 @@
>;
};
- pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x87
MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc7
--
2.17.1
[PATCH v2 12/14] arm64: dts: imx8mq-hummingboard-pulse: Align pin configuration group names with schema
Device tree schema expects pin configuration groups to end with 'grp'
suffix, otherwise dtbs_check complain with a warning like:
... do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
.../boot/dts/freescale/imx8mq-hummingboard-pulse.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
b/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
index bfd91c1ed6a5..366693f31992 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-hummingboard-pulse.dts
@@ -214,13 +214,13 @@
>;
};
- pinctrl_usdhc2_gpio: usdhc2grpgpio {
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_CD_B_GPIO2_IO120x41
>;
};
- pinctrl_usdhc2_vmmc: usdhc2vmmcgpio {
+ pinctrl_usdhc2_vmmc: usdhc2vmmcgpiogrp {
fsl,pins = <
MX8MQ_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x41
>;
@@ -238,7 +238,7 @@
>;
};
- pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x8d
MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xcd
@@ -250,7 +250,7 @@
>;
};
- pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x9f
MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xdf
--
2.17.1
[PATCH v2 13/14] arm64: dts: imx8qxp-colibri: Align pin configuration group names with schema
Device tree schema expects pin configuration groups to end with 'grp'
suffix, otherwise dtbs_check complain with a warning like:
... do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi
index 75f17a29f81e..f38acff0d25c 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-colibri.dtsi
@@ -494,7 +494,7 @@
>;
};
- pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
fsl,pins = <
IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK
0x0641
IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD0x21
@@ -511,7 +511,7 @@
>;
};
- pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
fsl,pins = <
IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK
0x0641
IMX8QXP_EMMC0_CMD_CONN_EMMC0_CMD0x21
@@ -554,7 +554,7 @@
>;
};
- pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
fsl,pins = <
IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK
0x0641 /* SODIMM 47 */
IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD 0x21
/* SODIMM 190 */
@@ -566,7 +566,7 @@
>;
};
- pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
fsl,pins = <
IMX8QXP_USDHC1_CLK_CONN_USDHC1_CLK
0x0641 /* SODIMM 47 */
IMX8QXP_USDHC1_CMD_CONN_USDHC1_CMD 0x21
/* SODIMM 190 */
--
2.17.1
[PATCH v2 07/14] arm64: dts: imx8mq-evk: Align pin configuration group names with schema
Device tree schema expects pin configuration groups to end with 'grp'
suffix, otherwise dtbs_check complain with a warning like:
... do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index a088831d2e24..7c6808814856 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -407,7 +407,7 @@
>;
};
- pinctrl_reg_usdhc2: regusdhc2grpgpio {
+ pinctrl_reg_usdhc2: regusdhc2gpiogrp {
fsl,pins = <
MX8MQ_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
>;
--
2.17.1
[PATCH v2 04/14] arm64: dts: imx8mm-ddr4-evk: Align pin configuration group names with schema
Device tree schema expects pin configuration groups to end with 'grp'
suffix, otherwise dtbs_check complain with a warning like:
... do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
index a1e5483dbbbe..3ac8f9d3c372 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
@@ -155,7 +155,7 @@
};
&iomuxc {
- pinctrl_pmic: pmicirq {
+ pinctrl_pmic: pmicirqgrp {
fsl,pins = <
MX8MN_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x41
>;
--
2.17.1
[PATCH v2 02/14] arm64: dts: imx8mm-evk: Add 32.768 kHz clock to PMIC
The ROHM BD71847 PMIC has a 32.768 kHz clock. Adding necessary parent
allows to probe the bd718x7 clock driver fixing boot errors:
bd718xx-clk bd71847-clk.1.auto: No parent clk found
bd718xx-clk: probe of bd71847-clk.1.auto failed with error -22
Signed-off-by: Krzysztof Kozlowski
Acked-By: Matti Vaittinen
---
arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
index 38134d201eef..1c39a2b90ee1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
@@ -169,6 +169,10 @@
interrupts = <3 GPIO_ACTIVE_LOW>;
rohm,reset-snvs-powered;
+ #clock-cells = <0>;
+ clocks = <&osc_32k 0>;
+ clock-output-names = "clk-32k-out";
+
regulators {
buck1_reg: BUCK1 {
regulator-name = "buck1";
--
2.17.1
[PATCH v2 01/14] arm64: dts: imx8mm-beacon: Align pin configuration group names with schema
Device tree schema expects pin configuration groups to end with 'grp'
suffix. This fixes dtbs_check warnings like:
pinctrl@3033: 'pcal6414-gpio', 'pmicirq', 'usdhc1grp100mhz',
'usdhc1grp200mhz', 'usdhc1grpgpio',
'usdhc2grp100mhz', 'usdhc2grp200mhz', 'usdhc2grpgpio', 'usdhc3grp100mhz',
'usdhc3grp200mhz'
do not match any of the regexes: 'grp$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
.../boot/dts/freescale/imx8mm-beacon-baseboard.dtsi | 8
arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi | 12 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi
index 5b5af8b381df..d6b9dedd168f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi
@@ -210,7 +210,7 @@
>;
};
- pinctrl_pcal6414: pcal6414-gpio {
+ pinctrl_pcal6414: pcal6414-gpiogrp {
fsl,pins = <
MX8MM_IOMUXC_SAI2_MCLK_GPIO4_IO27 0x19
>;
@@ -240,7 +240,7 @@
>;
};
- pinctrl_usdhc2_gpio: usdhc2grpgpio {
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CD_B_USDHC2_CD_B 0x41
MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
@@ -259,7 +259,7 @@
>;
};
- pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194
MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4
@@ -271,7 +271,7 @@
>;
};
- pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196
MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
index 620a124dfb5f..502faf6144b0 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
@@ -290,7 +290,7 @@
>;
};
- pinctrl_pmic: pmicirq {
+ pinctrl_pmic: pmicirqgrp {
fsl,pins = <
MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3
0x41
>;
@@ -309,7 +309,7 @@
>;
};
- pinctrl_usdhc1_gpio: usdhc1grpgpio {
+ pinctrl_usdhc1_gpio: usdhc1gpiogrp {
fsl,pins = <
MX8MM_IOMUXC_SD1_RESET_B_GPIO2_IO10 0x41
>;
@@ -326,7 +326,7 @@
>;
};
- pinctrl_usdhc1_100mhz: usdhc1grp100mhz {
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x194
MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d4
@@ -337,7 +337,7 @@
>;
};
- pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x196
MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d6
@@ -364,7 +364,7 @@
>;
};
- pinctrl_usdhc3_100mhz: usdhc3grp100mhz {
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK
0x194
MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD
0x1d4
@@ -380,7 +380,7 @@
>;
};
- pinctrl_usdhc3_200mhz: usdhc3grp200mhz {
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
fsl,pins = <
MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK
0x196
MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD
0x1d6
--
2.17.1
Re: [PATCH v6 04/20] gpio: uapi: define uAPI v2
On Mon, Aug 31, 2020 at 5:21 AM Kent Gibson wrote:
>
> Add a new version of the uAPI to address existing 32/64-bit alignment
> issues, add support for debounce and event sequence numbers, allow
> requested lines with different configurations, and provide some future
> proofing by adding padding reserved for future use.
>
> The alignment issue relates to the gpioevent_data, which packs to different
> sizes on 32-bit and 64-bit platforms. That creates problems for 32-bit apps
> running on 64-bit kernels. uAPI v2 addresses that particular issue, and
> the problem more generally, by adding pad fields that explicitly pad
> structs out to 64-bit boundaries, so they will pack to the same size now,
> and even if some of the reserved padding is used for __u64 fields in the
> future.
>
> The new structs have been analysed with pahole to ensure that they
> are sized as expected and contain no implicit padding.
>
> The lack of future proofing in v1 makes it impossible to, for example,
> add the debounce feature that is included in v2.
> The future proofing is addressed by providing configurable attributes in
> line config and reserved padding in all structs for future features.
> Specifically, the line request, config, info, info_changed and event
> structs receive updated versions and new ioctls.
>
> As the majority of the structs and ioctls were being replaced, it is
> opportune to rework some of the other aspects of the uAPI:
>
> v1 has three different flags fields, each with their own separate
> bit definitions. In v2 that is collapsed to one - gpio_v2_line_flag.
>
> The handle and event requests are merged into a single request, the line
> request, as the two requests were mostly the same other than the edge
> detection provided by event requests. As a byproduct, the v2 uAPI allows
> for multiple lines producing edge events on the same line handle.
> This is a new capability as v1 only supports a single line in an event
> request.
>
> As a consequence, there are now only two types of file handle to be
> concerned with, the chip and the line, and it is clearer which ioctls
> apply to which type of handle.
>
> There is also some minor renaming of fields for consistency compared to
> their v1 counterparts, e.g. offset rather than lineoffset or line_offset,
> and consumer rather than consumer_label.
>
> Additionally, v1 GPIOHANDLES_MAX becomes GPIO_V2_LINES_MAX in v2 for
> clarity, and the gpiohandle_data __u8 array becomes a bitmap in
> gpio_v2_line_values.
>
> The v2 uAPI is mostly a reorganisation and extension of v1, so userspace
> code, particularly libgpiod, should readily port to it.
>
> Signed-off-by: Kent Gibson
> ---
[snip]
> +
> +/**
> + * enum gpio_v2_line_flag - &struct gpio_v2_line_attribute.flags values
> + */
> +enum gpio_v2_line_flag {
> + GPIO_V2_LINE_FLAG_USED = 1ULL << 0, /* line is not
> available for request */
> + GPIO_V2_LINE_FLAG_ACTIVE_LOW= 1ULL << 1,
> + GPIO_V2_LINE_FLAG_INPUT = 1ULL << 2,
> + GPIO_V2_LINE_FLAG_OUTPUT= 1ULL << 3,
> + GPIO_V2_LINE_FLAG_EDGE_RISING = 1ULL << 4,
> + GPIO_V2_LINE_FLAG_EDGE_FALLING = 1ULL << 5,
> + GPIO_V2_LINE_FLAG_OPEN_DRAIN= 1ULL << 6,
> + GPIO_V2_LINE_FLAG_OPEN_SOURCE = 1ULL << 7,
> + GPIO_V2_LINE_FLAG_BIAS_PULL_UP = 1ULL << 8,
> + GPIO_V2_LINE_FLAG_BIAS_PULL_DOWN= 1ULL << 9,
> + GPIO_V2_LINE_FLAG_BIAS_DISABLED = 1ULL << 10,
> +};
> +
>
One more small thing I noticed: the uapi exports _BITULL() macro to
user-space for bit definitions. I think it's worth using it here as
it's more readable than (1ULL << X) IMO.
Bart
[snip]
[PATCH v1] Bluetooth: btusb: Add Qualcomm Bluetooth SoC WCN6855 support
This patch add support for WCN6855 i.e. patch and nvm download
support.
Signed-off-by: Rocky Liao
---
drivers/bluetooth/btusb.c | 42 +++
1 file changed, 38 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index fe80588c7bd3..e51e754ca9b8 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -59,6 +59,7 @@ static struct usb_driver btusb_driver;
#define BTUSB_MEDIATEK 0x20
#define BTUSB_WIDEBAND_SPEECH 0x40
#define BTUSB_VALID_LE_STATES 0x80
+#define BTUSB_QCA_WCN6855 0x100
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
@@ -273,6 +274,10 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x13d3, 0x3496), .driver_info = BTUSB_QCA_ROME },
{ USB_DEVICE(0x13d3, 0x3501), .driver_info = BTUSB_QCA_ROME },
+ /* QCA WCN6855 chipset */
+ { USB_DEVICE(0x0cf3, 0xe600), .driver_info = BTUSB_QCA_WCN6855 |
+BTUSB_WIDEBAND_SPEECH },
+
/* Broadcom BCM2035 */
{ USB_DEVICE(0x0a5c, 0x2009), .driver_info = BTUSB_BCM92035 },
{ USB_DEVICE(0x0a5c, 0x200a), .driver_info = BTUSB_WRONG_SCO_MTU },
@@ -3391,6 +3396,26 @@ static int btusb_set_bdaddr_ath3012(struct hci_dev *hdev,
return 0;
}
+static int btusb_set_bdaddr_wcn6855(struct hci_dev *hdev,
+ const bdaddr_t *bdaddr)
+{
+ struct sk_buff *skb;
+ u8 buf[6];
+ long ret;
+
+ memcpy(buf, bdaddr, sizeof(bdaddr_t));
+
+ skb = __hci_cmd_sync(hdev, 0xfc14, sizeof(buf), buf, HCI_INIT_TIMEOUT);
+ if (IS_ERR(skb)) {
+ ret = PTR_ERR(skb);
+ bt_dev_err(hdev, "Change address command failed (%ld)", ret);
+ return ret;
+ }
+ kfree_skb(skb);
+
+ return 0;
+}
+
#define QCA_DFU_PACKET_LEN 4096
#define QCA_GET_TARGET_VERSION 0x09
@@ -3428,6 +3453,8 @@ static const struct qca_device_info qca_devices_table[] =
{
{ 0x0201, 28, 4, 18 }, /* Rome 2.1 */
{ 0x0300, 28, 4, 18 }, /* Rome 3.0 */
{ 0x0302, 28, 4, 18 }, /* Rome 3.2 */
+ { 0x00130100, 40, 4, 18 }, /* WCN6855 1.0 */
+ { 0x00130200, 40, 4, 18 } /* WCN6855 2.0 */
};
static int btusb_qca_send_vendor_req(struct usb_device *udev, u8 request,
@@ -3530,7 +3557,7 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev
*hdev,
struct qca_rampatch_version *rver;
const struct firmware *fw;
u32 ver_rom, ver_patch;
- u16 rver_rom, rver_patch;
+ u32 rver_rom, rver_patch;
char fwname[64];
int err;
@@ -3552,6 +3579,9 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev
*hdev,
rver_rom = le16_to_cpu(rver->rom_version);
rver_patch = le16_to_cpu(rver->patch_version);
+ if (ver_rom & ~0xU)
+ rver_rom = *(u16 *)(fw->data + 16) << 16 | rver_rom;
+
bt_dev_info(hdev, "QCA: patch rome 0x%x build 0x%x, "
"firmware rome 0x%x build 0x%x",
rver_rom, rver_patch, ver_rom, ver_patch);
@@ -3625,9 +3655,6 @@ static int btusb_setup_qca(struct hci_dev *hdev)
return err;
ver_rom = le32_to_cpu(ver.rom_version);
- /* Don't care about high ROM versions */
- if (ver_rom & ~0xU)
- return 0;
for (i = 0; i < ARRAY_SIZE(qca_devices_table); i++) {
if (ver_rom == qca_devices_table[i].rom_version)
@@ -4063,6 +4090,13 @@ static int btusb_probe(struct usb_interface *intf,
btusb_check_needs_reset_resume(intf);
}
+ if (id->driver_info & BTUSB_QCA_WCN6855) {
+ data->setup_on_usb = btusb_setup_qca;
+ hdev->set_bdaddr = btusb_set_bdaddr_wcn6855;
+ hdev->cmd_timeout = btusb_qca_cmd_timeout;
+ set_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, &hdev->quirks);
+ }
+
if (id->driver_info & BTUSB_AMP) {
/* AMP controllers do not support SCO packets */
data->isoc = NULL;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
[PATCH] test_power: add missing newlines when printing parameters by sysfs
When I cat some module parameters by sysfs, it displays as follows.
It's better to add a newline for easy reading.
root@syzkaller:~# cd /sys/module/test_power/parameters/
root@syzkaller:/sys/module/test_power/parameters# cat ac_online
onroot@syzkaller:/sys/module/test_power/parameters# cat battery_present
trueroot@syzkaller:/sys/module/test_power/parameters# cat battery_health
goodroot@syzkaller:/sys/module/test_power/parameters# cat battery_status
dischargingroot@syzkaller:/sys/module/test_power/parameters# cat
battery_technology
LIONroot@syzkaller:/sys/module/test_power/parameters# cat usb_online
onroot@syzkaller:/sys/module/test_power/parameters#
Signed-off-by: Xiongfeng Wang
---
drivers/power/supply/test_power.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/power/supply/test_power.c
b/drivers/power/supply/test_power.c
index 04acd76..4895ee5 100644
--- a/drivers/power/supply/test_power.c
+++ b/drivers/power/supply/test_power.c
@@ -353,6 +353,7 @@ static int param_set_ac_online(const char *key, const
struct kernel_param *kp)
static int param_get_ac_online(char *buffer, const struct kernel_param *kp)
{
strcpy(buffer, map_get_key(map_ac_online, ac_online, "unknown"));
+ strcat(buffer, "\n");
return strlen(buffer);
}
@@ -366,6 +367,7 @@ static int param_set_usb_online(const char *key, const
struct kernel_param *kp)
static int param_get_usb_online(char *buffer, const struct kernel_param *kp)
{
strcpy(buffer, map_get_key(map_ac_online, usb_online, "unknown"));
+ strcat(buffer, "\n");
return strlen(buffer);
}
@@ -380,6 +382,7 @@ static int param_set_battery_status(const char *key,
static int param_get_battery_status(char *buffer, const struct kernel_param
*kp)
{
strcpy(buffer, map_get_key(map_status, battery_status, "unknown"));
+ strcat(buffer, "\n");
return strlen(buffer);
}
@@ -394,6 +397,7 @@ static int param_set_battery_health(const char *key,
static int param_get_battery_health(char *buffer, const struct kernel_param
*kp)
{
strcpy(buffer, map_get_key(map_health, battery_health, "unknown"));
+ strcat(buffer, "\n");
return strlen(buffer);
}
@@ -409,6 +413,7 @@ static int param_get_battery_present(char *buffer,
const struct kernel_param *kp)
{
strcpy(buffer, map_get_key(map_present, battery_present, "unknown"));
+ strcat(buffer, "\n");
return strlen(buffer);
}
@@ -426,6 +431,7 @@ static int param_get_battery_technology(char *buffer,
{
strcpy(buffer,
map_get_key(map_technology, battery_technology, "unknown"));
+ strcat(buffer, "\n");
return strlen(buffer);
}
--
1.7.12.4
Re: linux-next: Tree for Sep 2 (lib/ubsan.c)
On 9/2/20 8:44 AM, Randy Dunlap wrote: > On 9/2/20 1:09 AM, Stephen Rothwell wrote: >> Hi all, >> >> Changes since 20200828: >> > > > on i386: > > ../lib/ubsan.c: In function ‘ubsan_prologue’: > ../lib/ubsan.c:141:2: error: implicit declaration of function > ‘kunit_fail_current_test’; did you mean ‘kunit_init_test’? > [-Werror=implicit-function-declaration] > kunit_fail_current_test(); > > > Full randconfig file is attached. > Hi Brendan, Do you know anything about this build error? I can't find kunit_fail_current_test() anywhere. thanks. -- ~Randy
Re: [PATCH v2 0/3] KVM: x86: KVM_MEM_PCI_HOLE memory
On Wed, Sep 02, 2020 at 10:59:20AM +0200, Vitaly Kuznetsov wrote:
> Peter Xu writes:
> > My whole point was more about trying to understand the problem behind.
> > Providing a fast path for reading pci holes seems to be reasonable as is,
> > however it's just that I'm confused on why there're so many reads on the pci
> > holes after all. Another important question is I'm wondering how this
> > series
> > will finally help the use case of microvm. I'm not sure I get the whole
> > point
> > of it, but... if microvm is the major use case of this, it would be good to
> > provide some quick numbers on those if possible.
> >
> > For example, IIUC microvm uses qboot (as a better alternative than seabios)
> > for
> > fast boot, and qboot has:
> >
> > https://github.com/bonzini/qboot/blob/master/pci.c#L20
> >
> > I'm kind of curious whether qboot will still be used when this series is
> > used
> > with microvm VMs? Since those are still at least PIO based.
>
> I'm afraid there is no 'grand plan' for everything at this moment :-(
> For traditional VMs 0.04 sec per boot is negligible and definitely not
> worth adding a feature, memory requirements are also very
> different. When it comes to microvm-style usage things change.
>
> '8193' PCI hole accesses I mention in the PATCH0 blurb are just from
> Linux as I was doing direct kernel boot, we can't get better than that
> (if PCI is in the game of course). Firmware (qboot, seabios,...) can
> only add more. I *think* the plan is to eventually switch them all to
> MMCFG, at least for KVM guests, by default but we need something to put
> to the advertisement.
I see a similar ~8k PCI hole reads with a -kernel boot w/ OVMF. All but 60
of those are from pcibios_fixup_peer_bridges(), and all are from the kernel.
My understanding is that pcibios_fixup_peer_bridges() is useful if and only
if there multiple root buses. And AFAICT, when running under QEMU, the only
way for there to be multiple buses in is if there is an explicit bridge
created ("pxb" or "pxb-pcie"). Based on the cover letter from those[*], the
main reason for creating a bridge is to handle pinned CPUs on a NUMA system
with pass-through devices. That use case seems highly unlikely to cross
paths with micro VMs, i.e. micro VMs will only ever have a single bus.
Unless I'm mistaken, microvm doesn't even support PCI, does it?
If all of the above is true, this can be handled by adding "pci=lastbus=0"
as a guest kernel param to override its scanning of buses. And couldn't
that be done by QEMU's microvm_fix_kernel_cmdline() to make it transparent
to the end user?
[*] https://www.redhat.com/archives/libvir-list/2016-March/msg01213.html
[PATCH RESEND] x86, fakenuma: Fix invalid starting node ID
Commit cc9aec03e58f ("x86/numa_emulation: Introduce uniform split
capability") uses "-1" as the starting node ID, which causes the
strange kernel log as following, when "numa=fake=32G" is added to the
kernel command line.
Faking node -1 at [mem 0x-0x000893ff] (35136MB)
Faking node 0 at [mem 0x00184000-0x00203fff] (32768MB)
Faking node 1 at [mem 0x00089400-0x00183fff] (64192MB)
Faking node 2 at [mem 0x00204000-0x00283fff] (32768MB)
Faking node 3 at [mem 0x00284000-0x00303fff] (32768MB)
And finally kernel BUG as following,
BUG: Bad page state in process swapper pfn:00011
page:(ptrval) refcount:0 mapcount:1 mapping:(ptrval)
index:0x55cd7e44b270 pfn:0x11
failed to read mapping contents, not a valid kernel address?
flags: 0x5(locked|uptodate)
raw: 0005 55cd7e44af30 55cd7e44af50 00010006
raw: 55cd7e44b270 55cd7e44b290 55cd7e44b510
page dumped because: page still charged to cgroup
page->mem_cgroup:55cd7e44b510
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.9.0-rc2 #1
Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS
SE5C620.86B.02.01.0008.031920191559 03/19/2019
Call Trace:
dump_stack+0x57/0x80
bad_page.cold+0x63/0x94
__free_pages_ok+0x33f/0x360
memblock_free_all+0x127/0x195
mem_init+0x23/0x1f5
start_kernel+0x219/0x4f5
secondary_startup_64+0xb6/0xc0
Fixes this bug via using 0 as the starting node ID. This restores the
original behavior before the commit cc9aec03e58f ("x86/numa_emulation:
Introduce uniform split capability").
Fixes: cc9aec03e58f ("x86/numa_emulation: Introduce uniform split capability")
Signed-off-by: "Huang, Ying"
Cc: Andrew Morton
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Dan Williams
Cc: David Rientjes
Cc: Dave Jiang
---
arch/x86/mm/numa_emulation.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/numa_emulation.c b/arch/x86/mm/numa_emulation.c
index c5174b4e318b..683cd12f4793 100644
--- a/arch/x86/mm/numa_emulation.c
+++ b/arch/x86/mm/numa_emulation.c
@@ -321,7 +321,7 @@ static int __init split_nodes_size_interleave(struct
numa_meminfo *ei,
u64 addr, u64 max_addr, u64 size)
{
return split_nodes_size_interleave_uniform(ei, pi, addr, max_addr, size,
- 0, NULL, NUMA_NO_NODE);
+ 0, NULL, 0);
}
static int __init setup_emu2phys_nid(int *dfl_phys_nid)
--
2.28.0
[PATCH] trace: Fix race in trace_open and buffer resize call
Below race can come, if trace_open and resize of
cpu buffer is running parallely on different cpus
CPUXCPUY
ring_buffer_resize
atomic_read(&buffer->resize_disabled)
tracing_open
tracing_reset_online_cpus
ring_buffer_reset_cpu
rb_reset_cpu
rb_update_pages
remove/insert pages
resetting pointer
This race can cause data abort or some times infinte loop in
rb_remove_pages and rb_insert_pages while checking pages
for sanity.
Take ring buffer lock in trace_open to avoid resetting of cpu buffer.
Signed-off-by: Gaurav Kohli
diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
index 136ea09..55f9115 100644
--- a/include/linux/ring_buffer.h
+++ b/include/linux/ring_buffer.h
@@ -163,6 +163,8 @@ bool ring_buffer_empty_cpu(struct trace_buffer *buffer, int
cpu);
void ring_buffer_record_disable(struct trace_buffer *buffer);
void ring_buffer_record_enable(struct trace_buffer *buffer);
+void ring_buffer_mutex_acquire(struct trace_buffer *buffer);
+void ring_buffer_mutex_release(struct trace_buffer *buffer);
void ring_buffer_record_off(struct trace_buffer *buffer);
void ring_buffer_record_on(struct trace_buffer *buffer);
bool ring_buffer_record_is_on(struct trace_buffer *buffer);
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 93ef0ab..638ec8f 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -3632,6 +3632,25 @@ void ring_buffer_record_enable(struct trace_buffer
*buffer)
EXPORT_SYMBOL_GPL(ring_buffer_record_enable);
/**
+ * ring_buffer_mutex_acquire - prevent resetting of buffer
+ * during resize
+ */
+void ring_buffer_mutex_acquire(struct trace_buffer *buffer)
+{
+ mutex_lock(&buffer->mutex);
+}
+EXPORT_SYMBOL_GPL(ring_buffer_mutex_acquire);
+
+/**
+ * ring_buffer_mutex_release - prevent resetting of buffer
+ * during resize
+ */
+void ring_buffer_mutex_release(struct trace_buffer *buffer)
+{
+ mutex_unlock(&buffer->mutex);
+}
+EXPORT_SYMBOL_GPL(ring_buffer_mutex_release);
+/**
* ring_buffer_record_off - stop all writes into the buffer
* @buffer: The ring buffer to stop writes to.
*
@@ -4918,6 +4937,8 @@ void ring_buffer_reset(struct trace_buffer *buffer)
struct ring_buffer_per_cpu *cpu_buffer;
int cpu;
+ /* prevent another thread from changing buffer sizes */
+ mutex_lock(&buffer->mutex);
for_each_buffer_cpu(buffer, cpu) {
cpu_buffer = buffer->buffers[cpu];
@@ -4936,6 +4957,7 @@ void ring_buffer_reset(struct trace_buffer *buffer)
atomic_dec(&cpu_buffer->record_disabled);
atomic_dec(&cpu_buffer->resize_disabled);
}
+ mutex_unlock(&buffer->mutex);
}
EXPORT_SYMBOL_GPL(ring_buffer_reset);
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index f40d850..392e9aa 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2006,6 +2006,8 @@ void tracing_reset_online_cpus(struct array_buffer *buf)
if (!buffer)
return;
+ ring_buffer_mutex_acquire(buffer);
+
ring_buffer_record_disable(buffer);
/* Make sure all commits have finished */
@@ -2016,6 +2018,8 @@ void tracing_reset_online_cpus(struct array_buffer *buf)
ring_buffer_reset_online_cpus(buffer);
ring_buffer_record_enable(buffer);
+
+ ring_buffer_mutex_release(buffer);
}
/* Must have trace_types_lock held */
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative
Project
Re: [RFC][PATCH] cpu_pm: Remove RCU abuse
On Thu, 3 Sep 2020 at 17:08, wrote:
>
> On Thu, Sep 03, 2020 at 04:36:35PM +0200, Ulf Hansson wrote:
> > On Thu, 3 Sep 2020 at 15:53, wrote:
> > > static int cpu_pm_notify(enum cpu_pm_event event)
> > > {
> > > int ret;
> > >
> > > + lockdep_assert_irqs_disabled();
> >
> > Nitpick, maybe the lockdep should be moved to a separate patch.
>
> Well, the unregister relies on IRQs being disabled here, so I figured
> asserting this was a good thing ;-)
Okay, make sense then.
>
> Starting the audit below, this might not in fact be true, which then
> invalidates the unregister implementation. In particular the notifier in
> arch/arm/kernel/hw_breakpoint.c seems to unconditionally enable IRQs.
I see.
>
> > > + ret = raw_notifier_call_chain(&cpu_pm_notifier_chain, event,
> > > NULL);
> >
> > Converting to raw_notifiers seems reasonable - if we need to avoid the
> > RCU usage.
> >
> > My point is, I wonder about if the notifier callbacks themselves are
> > safe from RCU usage. For example, I would not be surprised if tracing
> > is happening behind them.
>
> A bunch of them seem to call into the clk domain stuff, and I think
> there's tracepoints in that.
>
> > Moreover, I am not sure that we really need to prevent and limit
> > tracing from happening. Instead we could push rcu_idle_enter|exit()
> > further down to the arch specific code in the cpuidle drivers, as you
> > kind of all proposed earlier.
>
> Well, at some point the CPU is in a really dodgy state, ISTR there being
> ARM platforms where you have to manually leave the cache coherency
> fabric and all sorts of insanity. There should be a definite cut-off on
> tracing before that.
That's probably the case for some platforms, but I don't see why we
need to make everybody "suffer".
>
> Also, what is the point of all this clock and power domain callbacks, if
> not to put the CPU into an extremely low power state, surely you want to
> limit the amount of code that's ran when the CPU is in such a state.
>
> > In this way, we can step by step, move to a new "version" of
> > cpu_pm_enter() that doesn't have to deal with rcu_irq_enter_irqson(),
> > because RCU hasn't been pushed to idle yet.
>
> That should be easy enough to audit. The thing is that mainline is now
> generating (debug) splats, and some people are upset with this.
>
> If you're ok with ARM not being lockdep clean while this is being
> reworked I'm perfectly fine with that.
I think the splats can easily be fixed. Short term.
Adding RCU_NONIDLE (or similar) around pm_runtime calls in
psci_enter_domain_idle_state() does the trick. I have a patch for
that, it's tested and ready. Let me send it out.
Perhaps we should just accept that this is needed, as to allow us to
move step by step into a better situation, while also avoiding the
current splats.
>
> (There used to be a separate CONFIG for RCU-lockdep, but that seems to
> have been removed)
I don't think that would help. Infrastructure for testing will just
enable that Kconfig anyway still complains to us.
Kind regards
Uffe
Re: [PATCH] i2c: virtio: add a virtio i2c frontend driver
On 2020/9/3 18:20, Andy Shevchenko wrote:
On Thu, Sep 03, 2020 at 01:34:45PM +0800, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
This driver communicates with the backend driver through a
virtio I2C message structure which includes following parts:
- Header: i2c_msg addr, flags, len.
- Data buffer: the pointer to the i2c msg data.
- Status: the processing result from the backend.
People may implement different backend drivers to emulate
different controllers according to their needs. A backend
example can be found in the device model of the open source
project ACRN. For more information, please refer to
https://projectacrn.org.
The virtio device ID 34 is used for this I2C adpter since IDs
before 34 have been reserved by other virtio devices.
Seems it's slightly different version to what I have reviewed internally.
My comments below. (I admit that some of them maybe new)
...
Yeah... Some new devices have been added into the virtio spec during
these days.
+/**
+ * struct virtio_i2c_hdr - the virtio I2C message header structure
+ * @addr: i2c_msg addr, the slave address
+ * @flags: i2c_msg flags
+ * @len: i2c_msg len
+ */
+struct virtio_i2c_hdr {
+ __virtio16 addr;
+ __virtio16 flags;
+ __virtio16 len;
+} __packed;
As Misha noticed and somewhere I saw 0-day reports these should be carefully
taken care of.
...
Sure. Will fix these.
+static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int
num)
+{
+ struct virtio_i2c *vi = i2c_get_adapdata(adap);
+ struct virtio_i2c_msg *vmsg_o, *vmsg_i;
+ struct virtqueue *vq = vi->vq;
+ unsigned long time_left;
+ int len, i, ret = 0;
+
+ vmsg_o = kzalloc(sizeof(*vmsg_o), GFP_KERNEL);
+ if (!vmsg_o)
+ return -ENOMEM;
+
+ mutex_lock(&vi->i2c_lock);
+ vmsg_o->buf = NULL;
+ for (i = 0; i < num; i++) {
+ ret = virtio_i2c_add_msg(vq, vmsg_o, &msgs[i]);
+ if (ret) {
+ dev_err(&adap->dev, "failed to add msg[%d] to
virtqueue.\n", i);
+ goto err_unlock_free;
break;
OK.
+ }
+
+ virtqueue_kick(vq);
+
+ time_left = wait_for_completion_timeout(&vi->completion,
adap->timeout);
+ if (!time_left) {
+ dev_err(&adap->dev, "msg[%d]: addr=0x%x timeout.\n", i,
msgs[i].addr);
+ ret = i;
+ goto err_unlock_free;
break;
And so on.
OK.
+ }
+
+ vmsg_i = (struct virtio_i2c_msg *)virtqueue_get_buf(vq, &len);
+ if (vmsg_i) {
+ /* vmsg_i should point to the same address with vmsg_o
*/
+ if (vmsg_i != vmsg_o) {
+ dev_err(&adap->dev, "msg[%d]: addr=0x%x virtqueue
error.\n",
+ i, vmsg_i->hdr.addr);
+ ret = i;
+ goto err_unlock_free;
+ }
+ if (vmsg_i->status != VIRTIO_I2C_MSG_OK) {
+ dev_err(&adap->dev, "msg[%d]: addr=0x%x
error=%d.\n",
+ i, vmsg_i->hdr.addr, vmsg_i->status);
+ ret = i;
+ goto err_unlock_free;
+ }
+ if ((vmsg_i->hdr.flags & I2C_M_RD) && vmsg_i->hdr.len)
+ memcpy(msgs[i].buf, vmsg_i->buf,
vmsg_i->hdr.len);
+
+ kfree(vmsg_i->buf);
+ vmsg_i->buf = NULL;
+ }
+ reinit_completion(&vi->completion);
+ }
+ if (i == num)
+ ret = num;
And this conditional seems a dup of the for-loop successfully iterating over
entire queue.
You are right.
We may save several lines of code by using "Return (ret<0) ? ret : i" at
the end.
+err_unlock_free:
Redundant.
OK.
+ mutex_unlock(&vi->i2c_lock);
+ kfree(vmsg_o->buf);
+ kfree(vmsg_o);
+ return ret;
+}
...
+ vi->adap.timeout = HZ / 10;
+ Blank line.
OK.
+ ret = i2c_add_adapter(&vi->adap);
+ if (ret) {
+ dev_err(&vdev->dev, "failed to add virtio-i2c adapter.\n");
+ virtio_i2c_del_vqs(vdev);
Usually we do clean up followed by message.
I will change the order. Thank you.
+ }
+
+ return ret;
Re: [PATCH v1 02/10] powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE on iommu_*_coherent()
On Thu, 2020-09-03 at 14:41 +1000, Alexey Kardashevskiy wrote:
> I am new to this, so I am trying to understand how a memory page mapped
> > as DMA, and used for something else could be a problem.
>
> From the device prospective, there is PCI space and everything from 0
> till 1<<64 is accessible and what is that mapped to - the device does
> not know. PHB's IOMMU is the thing to notice invalid access and raise
> EEH but PHB only knows about PCI->physical memory mapping (with IOMMU
> pages) but nothing about the host kernel pages. Does this help? Thanks,
According to our conversation on Slack:
1- There is a problem if a hypervisor gives to it's VMs contiguous
memory blocks that are not aligned to IOMMU pages, because then an
iommu_map_page() could map some memory in this VM and some memory in
other VM / process.
2- To guarantee this, we should have system pagesize >= iommu_pagesize
One way to get (2) is by doing this in enable_ddw():
if ((query.page_size & 4) && PAGE_SHIFT >= 24) {
page_shift = 24; /* 16MB */
} else if ((query.page_size & 2) && PAGE_SHIFT >= 16 ) {
page_shift = 16; /* 64kB */
} else if (query.page_size & 1 && PAGE_SHIFT >= 12) {
page_shift = 12; /* 4kB */
[...]
Another way of solving this, would be adding in LoPAR documentation
that the blocksize of contiguous memory the hypervisor gives a VM
should always be aligned to IOMMU pagesize offered.
I think the best approach would be first sending the above patch, which
is faster, and then get working into adding that to documentation, so
hypervisors guarantee this.
If this gets into the docs, we can revert the patch.
What do you think?
Best regards!
Re: [PATCH] mmc: renesas_sdhi: Drop local dma_parms
On Thu, Sep 03, 2020 at 10:18:06PM +0100, Robin Murphy wrote:
> Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
> for platform devices"), struct platform_device already provides a
> dma_parms structure, so we can save allocating another one.
>
> Signed-off-by: Robin Murphy
Double-checked the mentioned commit above:
Reviewed-by: Wolfram Sang
No regression and same performance when checksumming a large file:
Tested-by: Wolfram Sang
Thanks for the patch!
signature.asc
Description: PGP signature
Re: remove the last set_fs() in common code, and remove it for x86 and powerpc v3
* Christoph Hellwig wrote: > Hi all, > > this series removes the last set_fs() used to force a kernel address > space for the uaccess code in the kernel read/write/splice code, and then > stops implementing the address space overrides entirely for x86 and > powerpc. Cool! For the x86 bits: Acked-by: Ingo Molnar Thanks, Ingo
Re: [PATCH v7 0/5] Warn on orphan section placement
* Nick Desaulniers wrote: > On Tue, Sep 1, 2020 at 7:53 PM Kees Cook wrote: > > > > Hi Ingo, > > > > The ever-shortening series. ;) Here is "v7", which is just the remaining > > Makefile changes to enable orphan section warnings, now updated to > > include ld-option calls. > > > > Thanks for getting this all into -tip! > > For the series, > Reviewed-by: Nick Desaulniers > > As the recent ppc vdso boogaloo exposed, what about the vdsos? > * arch/x86/entry/vdso/Makefile > * arch/arm/vdso/Makefile > * arch/arm64/kernel/vdso/Makefile > * arch/arm64/kernel/vdso32/Makefile Kees, will these patches DTRT for the vDSO builds? I will be unable to test these patches on that old system until tomorrow the earliest. I'm keeping these latest changes in WIP.core/build for now. Thanks, Ingo
Re: [PATCH v2] perf expr: Force encapsulation on expr_id_data
On Thu, Aug 27, 2020 at 12:00 AM kajoljain wrote: > > > > On 8/26/20 9:27 PM, Jiri Olsa wrote: > > On Wed, Aug 26, 2020 at 08:30:55AM -0700, Ian Rogers wrote: > >> This patch resolves some undefined behavior where variables in > >> expr_id_data were accessed (for debugging) without being defined. To > >> better enforce the tagged union behavior, the struct is moved into > >> expr.c and accessors provided. Tag values (kinds) are explicitly > >> identified. > > Reviewed-By: Kajol Jain > > Thanks, > Kajol Jain > >> > >> Signed-off-by: Ian Rogers > > > > great, thanks for doing this > > > > Acked-by: Jiri Olsa > > > > jirka > > Thanks for the reviews! Arnaldo could this get merged? Thanks! Ian
Re: [PATCH v9 2/3] drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge
Hi, On 04/09/2020 05:29, Laurent Pinchart wrote: >> Laurent mentioned that atomic_check should not change state. Note that >> cdns_mhdp_validate_mode_params also changes state, as it calculates tu_size, >> vs and line_thresh. > > .atomic_check() isn't allowed to change any global state, which means > both hardware state and data in cdns_mhdp_device. The drm_bridge_state > (and thus the cdns_mhdp_bridge_state) can be modified as it stores the > state for the atomic commit being checked. > >> There seems to be issues with mode changes, but I think the first step would >> be to clarify the >> related code a bit. cdns_mhdp_validate_mode_params() is misnamed, I think it >> should be renamed to >> calculate_tu or something like that. >> >> cdns_mhdp_bandwidth_ok() should take display_fmt or bpp as a parameter, as >> currently it digs that up >> from the current state. >> >> Probably cdns_mhdp_validate_mode_params() would be better if it doesn't >> write the result to the >> state, but returns the values. That way it could also be used to verify if >> suitable settings can be >> found, without changing the state. > > This use case is actually a very good example of proper usage of the > atomic state :-) .atomic_check() has to perform computations to verify > the atomic commit, and storing the results in the commit's state > prevents duplicating the same calculation at .atomic_commit() time. Yes, you're right. But it's still not good, as cdns_mhdp_validate_mode_params uses link details to do the calculations, but we do link training only later and thus the calculations are invalid. cdns_mhdp_validate_mode_params is also called from the HPD interrupt, and there it changes the current bridge state. link_mutex is being held in every place where cdns_mhdp_validate_mode_params is called, so I guess it's fine. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 5/9] libperf: Add support for user space counter access
On Wed, Sep 2, 2020 at 12:48 PM Rob Herring wrote:
>
> On Wed, Sep 2, 2020 at 12:07 PM Ian Rogers wrote:
> >
> > On Fri, Aug 28, 2020 at 1:56 PM Rob Herring wrote:
> > >
> > > x86 and arm64 can both support direct access of event counters in
> > > userspace. The access sequence is less than trivial and currently exists
> > > in perf test code (tools/perf/arch/x86/tests/rdpmc.c) with copies in
> > > projects such as PAPI and libpfm4.
> > >
> > > In order to support usersapce access, an event must be mmapped. While
> > > there's already mmap support for evlist, the usecase is a bit different
> > > than the self monitoring with userspace access. So let's add a new
> > > perf_evsel__mmap() function to mmap an evsel. This allows implementing
> > > userspace access as a fastpath for perf_evsel__read().
> > >
> > > The mmapped address is returned by perf_evsel__mmap() primarily for
> > > users/tests to check if userspace access is enabled.
> > >
> > > Signed-off-by: Rob Herring
> > > ---
>
> > > +int perf_mmap__read_self(struct perf_mmap *map, struct
> > > perf_counts_values *count)
> > > +{
> > > + struct perf_event_mmap_page *pc = map->base;
> > > + u32 seq, idx, time_mult = 0, time_shift = 0;
> > > + u64 cnt, cyc = 0, time_offset = 0, time_cycles = 0, time_mask =
> > > ~0ULL;
> > > +
> > > + BUG_ON(!pc);
> > > +
> > > + if (!pc->cap_user_rdpmc)
> > > + return -1;
> > > +
> > > + do {
> > > + seq = READ_ONCE(pc->lock);
> > > + barrier();
> > > +
> > > + count->ena = READ_ONCE(pc->time_enabled);
> > > + count->run = READ_ONCE(pc->time_running);
> > > +
> > > + if (pc->cap_user_time && count->ena != count->run) {
> > > + cyc = read_timestamp();
> > > + time_mult = READ_ONCE(pc->time_mult);
> > > + time_shift = READ_ONCE(pc->time_shift);
> > > + time_offset = READ_ONCE(pc->time_offset);
> > > +
> > > + if (pc->cap_user_time_short) {
> > > + time_cycles = READ_ONCE(pc->time_cycles);
> > > + time_mask = READ_ONCE(pc->time_mask);
> > > + }
> > > + }
> > > +
> > > + idx = READ_ONCE(pc->index);
> > > + cnt = READ_ONCE(pc->offset);
> > > + if (pc->cap_user_rdpmc && idx) {
> > > + u64 evcnt = read_perf_counter(idx - 1);
> > > + u16 width = READ_ONCE(pc->pmc_width);
> > > +
> > > + evcnt <<= 64 - width;
> > > + evcnt >>= 64 - width;
> > > + cnt += evcnt;
> > > + } else
> > > + return -1;
> > > +
> > > + barrier();
> > > + } while (READ_ONCE(pc->lock) != seq);
> > > +
> > > + if (count->ena != count->run) {
> >
> > There's an existing bug here that I tried to resolve in this patch:
> > https://lore.kernel.org/lkml/CAP-5=fvrdqvswtyqmg5cb+nttgda+sayskjtqedneh-aezo...@mail.gmail.com/
> > Due to multiplexing, enabled may be > 0 but run == 0 and the divide
> > below can end up with divide by zero.
>
> Yeah, I saw that, but didn't try to also fix that issue here.
>
> > I like the idea of this code being in a library, there's an intent
> > that the perf_event.h and test code be copy-paste-able, but there is
> > some pre-existing divergence. It would be nice if this code could be
> > closer to the sample code in both the test and perf_event.h.
>
> The only way we get and keep all the versions of the code aligned is
> removing the other copies. We should just remove the code comment from
> perf_event.h IMO. If rdpmc.c is going to stick around given some
> resistance to removing it, then perhaps it should be converted to use
> libperf. At that point it could also be arch independent. Though I
> don't like the idea of having the same test twice.
This makes sense to me, perhaps others could comment. Given the
cleaned up API fixing or deleting tools/perf/arch/x86/tests/rdpmc.c is
desirable (as your patch set does). I wondered if we could do Jiri's
suggestion to run the lib/perf tests with perf test. One way would be
to have shell script wrapper in tools/perf/tests/shell. It's not clear
how to make a dependency from a shell script there and tests built
elsewhere in the tree though.
> > As per the change above, I think running and enabled times need to be
> > out arguments.
>
> They are now in this version.
Sorry, my mistake. I'd missed that.
Thanks,
Ian
> Rob
Re: 回复: [PATCH v2] debugobjects: install cpu hotplug callback
* Zhang, Qiang wrote:
> tglx please review.
>
> Thanks
> Qiang
>
> 发件人: linux-kernel-ow...@vger.kernel.org
> 代表 qiang.zh...@windriver.com
> 发送时间: 2020年8月27日 13:06
> 收件人: t...@linutronix.de; long...@redhat.com; el...@google.com
> 抄送: linux-kernel@vger.kernel.org
> 主题: [PATCH v2] debugobjects: install cpu hotplug callback
>
> From: Zqiang
>
> Due to cpu hotplug, it may never be online after it's offline,
> some objects in percpu pool is never free, in order to avoid
> this happening, install cpu hotplug callback, call this callback
> func to free objects in percpu pool when cpu going offline.
We capitalize 'CPU'. Also, please split this in at least two sentences.
>
> Signed-off-by: Zqiang
> ---
> v1->v2:
> Modify submission information.
>
> include/linux/cpuhotplug.h | 1 +
> lib/debugobjects.c | 23 +++
> 2 files changed, 24 insertions(+)
>
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index a2710e654b64..2e77db655cfa 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -36,6 +36,7 @@ enum cpuhp_state {
> CPUHP_X86_MCE_DEAD,
> CPUHP_VIRT_NET_DEAD,
> CPUHP_SLUB_DEAD,
> + CPUHP_DEBUG_OBJ_DEAD,
> CPUHP_MM_WRITEBACK_DEAD,
> CPUHP_MM_VMSTAT_DEAD,
> CPUHP_SOFTIRQ_DEAD,
> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index fe4557955d97..50e21ed0519e 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #define ODEBUG_HASH_BITS 14
> #define ODEBUG_HASH_SIZE (1 << ODEBUG_HASH_BITS)
> @@ -433,6 +434,23 @@ static void free_object(struct debug_obj *obj)
> }
> }
>
> +#if defined(CONFIG_HOTPLUG_CPU)
> +static int object_cpu_offline(unsigned int cpu)
> +{
> + struct debug_percpu_free *percpu_pool;
> + struct hlist_node *tmp;
> + struct debug_obj *obj;
> +
> + percpu_pool = per_cpu_ptr(&percpu_obj_pool, cpu);
> + hlist_for_each_entry_safe(obj, tmp, &percpu_pool->free_objs, node) {
> + hlist_del(&obj->node);
> + kmem_cache_free(obj_cache, obj);
> + }
> +
> + return 0;
> +}
> +#endif
What happens to ->obj_free, if the CPU is brought back online? Won't it be
out of sync at that point?
> +#if defined(CONFIG_HOTPLUG_CPU)
There's a shorter preprocessor sequence for that pattern.
Thanks,
Ingo
KASAN: null-ptr-deref Read in percpu_ref_exit
Hello,
syzbot found the following issue on:
HEAD commit:7a695657 Add linux-next specific files for 20200903
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15ac984e90
kernel config: https://syzkaller.appspot.com/x/.config?x=39134fcec6c78e33
dashboard link: https://syzkaller.appspot.com/bug?extid=4264ecfcf0f27a5e4180
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13709f1590
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=147047e990
The issue was bisected to:
commit d0c567d60f3730b97050347ea806e1ee06445c78
Author: Ming Lei
Date: Wed Sep 2 12:26:42 2020 +
percpu_ref: reduce memory footprint of percpu_ref in fast path
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17ed5a9590
final oops: https://syzkaller.appspot.com/x/report.txt?x=141d5a9590
console output: https://syzkaller.appspot.com/x/log.txt?x=101d5a9590
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4264ecfcf0f27a5e4...@syzkaller.appspotmail.com
Fixes: d0c567d60f37 ("percpu_ref: reduce memory footprint of percpu_ref in fast
path")
==
BUG: KASAN: null-ptr-deref in instrument_atomic_read
include/linux/instrumented.h:71 [inline]
BUG: KASAN: null-ptr-deref in atomic64_read
include/asm-generic/atomic-instrumented.h:837 [inline]
BUG: KASAN: null-ptr-deref in atomic_long_read
include/asm-generic/atomic-long.h:29 [inline]
BUG: KASAN: null-ptr-deref in percpu_ref_exit+0x102/0x1f0
lib/percpu-refcount.c:136
Read of size 8 at addr by task syz-executor932/7175
CPU: 0 PID: 7175 Comm: syz-executor932 Not tainted
5.9.0-rc3-next-20200903-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x198/0x1fd lib/dump_stack.c:118
__kasan_report mm/kasan/report.c:517 [inline]
kasan_report.cold+0x5/0x37 mm/kasan/report.c:530
check_memory_region_inline mm/kasan/generic.c:186 [inline]
check_memory_region+0x13d/0x180 mm/kasan/generic.c:192
instrument_atomic_read include/linux/instrumented.h:71 [inline]
atomic64_read include/asm-generic/atomic-instrumented.h:837 [inline]
atomic_long_read include/asm-generic/atomic-long.h:29 [inline]
percpu_ref_exit+0x102/0x1f0 lib/percpu-refcount.c:136
hd_free_part block/partitions/../blk.h:391 [inline]
part_release+0x9d/0xc0 block/partitions/core.c:262
device_release+0x9f/0x240 drivers/base/core.c:1802
kobject_cleanup lib/kobject.c:708 [inline]
kobject_release lib/kobject.c:739 [inline]
kref_put include/linux/kref.h:65 [inline]
kobject_put+0x171/0x270 lib/kobject.c:756
put_device+0x1b/0x30 drivers/base/core.c:3031
add_partition+0x648/0xb00 block/partitions/core.c:493
blk_add_partition block/partitions/core.c:685 [inline]
blk_add_partitions+0x9db/0xe00 block/partitions/core.c:761
bdev_disk_changed+0x208/0x390 fs/block_dev.c:1417
loop_reread_partitions+0x29/0x50 drivers/block/loop.c:658
loop_set_status+0x6da/0x1010 drivers/block/loop.c:1427
loop_set_status64 drivers/block/loop.c:1547 [inline]
lo_ioctl+0x900/0x1690 drivers/block/loop.c:1715
__blkdev_driver_ioctl block/ioctl.c:224 [inline]
blkdev_ioctl+0x28c/0x700 block/ioctl.c:620
block_ioctl+0xf9/0x140 fs/block_dev.c:1870
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl fs/ioctl.c:739 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446c27
Code: 48 83 c4 08 48 89 d8 5b 5d c3 66 0f 1f 84 00 00 00 00 00 48 89 e8 48 f7
d8 48 39 c3 0f 92 c0 eb 92 66 90 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83
6d 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fb6aa64db48 EFLAGS: 0202 ORIG_RAX: 0010
RAX: ffda RBX: 0004 RCX: 00446c27
RDX: 7fb6aa64dbe0 RSI: 4c04 RDI: 0004
RBP: 200158a8 R08: fe03f80fe03f80ff R09:
R10: R11: 0202 R12: 7fb6aa64e6d0
R13: 0003 R14: 0003 R15: 000a00d800050102
==
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH 3/4] perf vendor events amd: Add recommended events
On Thu, Sep 3, 2020 at 11:27 AM Kim Phillips wrote: > > On 9/3/20 1:19 AM, Ian Rogers wrote: > > On Tue, Sep 1, 2020 at 3:10 PM Kim Phillips wrote: > >> The nps1_die_to_dram event may need perf stat's --metric-no-group > >> switch if the number of available data fabric counters is less > >> than the number it uses (8). > > > > These are really excellent additions! Does: > > "MetricConstraint": "NO_NMI_WATCHDOG" > > solve the grouping issue? Perhaps the MetricConstraint needs to be > > named more generically to cover this case as it seems sub-optimal to > > require the use of --metric-no-group. > > That metric uses data fabric (DFPMC/amd_df) events, not Core PMC > events, which the watchdog uses, so NO_NMI_WATCHDOG wouldn't have > an effect. The event is defined as an approximation anyway. > > I'll have to get back to you on the other items. > > Thanks for your review! NP, more nits than anything else. Acked-by: Ian Rogers Thanks, Ian > Kim
Re: [PATCH v2 03/10] mm/memory_hotplug: simplify page offlining
> Am 03.09.2020 um 23:58 schrieb Andrew Morton :
>
> On Wed, 19 Aug 2020 19:59:50 +0200 David Hildenbrand
> wrote:
>
>> We make sure that we cannot have any memory holes right at the beginning
>> of offline_pages(). We no longer need walk_system_ram_range() and can
>> call test_pages_isolated() and __offline_isolated_pages() directly.
>>
>> offlined_pages always corresponds to nr_pages, so we can simplify that.
>
> This patch ran afoul of Pavel's "mm/memory_hotplug: drain per-cpu pages
> again during memory offline", here:
>
>> @@ -1481,7 +1459,7 @@ static int count_system_ram_pages_cb(unsigned long
>> start_pfn,
>> int __ref offline_pages(unsigned long start_pfn, unsigned long nr_pages)
>> {
>>const unsigned long end_pfn = start_pfn + nr_pages;
>> -unsigned long pfn, system_ram_pages = 0, offlined_pages = 0;
>> +unsigned long pfn, system_ram_pages = 0;
>>int ret, node, nr_isolate_pageblock;
>>unsigned long flags;
>>struct zone *zone;
>> @@ -1579,16 +1557,12 @@ int __ref offline_pages(unsigned long start_pfn,
>> unsigned long nr_pages)
>>reason = "failure to dissolve huge pages";
>>goto failed_removal_isolated;
>>}
>> -/* check again */
>> -ret = walk_system_ram_range(start_pfn, end_pfn - start_pfn,
>> -NULL, check_pages_isolated_cb);
>> -} while (ret);
>> -
>> -/* Ok, all of our target is isolated.
>> - We cannot do rollback at this point. */
>> -walk_system_ram_range(start_pfn, end_pfn - start_pfn,
>> - &offlined_pages, offline_isolated_pages_cb);
>> -pr_info("Offlined Pages %ld\n", offlined_pages);
>> +} while (test_pages_isolated(start_pfn, end_pfn, MEMORY_OFFLINE));
>> +
>> +/* Mark all sections offline and remove free pages from the buddy. */
>> +__offline_isolated_pages(start_pfn, end_pfn);
>> +pr_info("Offlined Pages %ld\n", nr_pages);
>> +
>>/*
>> * Onlining will reset pagetype flags and makes migrate type
>
> I did this. Looks OK?
>
Reading on my smartphone, it looks like you squashed both patches?
> From: David Hildenbrand
> Subject: mm/memory_hotplug: simplify page offlining
>
> We make sure that we cannot have any memory holes right at the beginning
> of offline_pages(). We no longer need walk_system_ram_range() and can
> call test_pages_isolated() and __offline_isolated_pages() directly.
>
> offlined_pages always corresponds to nr_pages, so we can simplify that.
>
> Link: https://lkml.kernel.org/r/20200819175957.28465-4-da...@redhat.com
> Signed-off-by: David Hildenbrand
> Acked-by: Michal Hocko
> Reviewed-by: Oscar Salvador
> Cc: Wei Yang
> Cc: Baoquan He
> Cc: Pankaj Gupta
> Cc: Charan Teja Reddy
> Cc: Dan Williams
> Cc: Fenghua Yu
> Cc: Logan Gunthorpe
> Cc: "Matthew Wilcox (Oracle)"
> Cc: Mel Gorman
> Cc: Mel Gorman
> Cc: Michel Lespinasse
> Cc: Mike Rapoport
> Cc: Tony Luck
> Signed-off-by: Andrew Morton
> ---
>
> mm/memory_hotplug.c | 61 +-
> 1 file changed, 25 insertions(+), 36 deletions(-)
>
> --- a/mm/memory_hotplug.c~mm-memory_hotplug-simplify-page-offlining
> +++ a/mm/memory_hotplug.c
> @@ -1383,28 +1383,6 @@ do_migrate_range(unsigned long start_pfn
>return ret;
> }
>
> -/* Mark all sections offline and remove all free pages from the buddy. */
> -static int
> -offline_isolated_pages_cb(unsigned long start, unsigned long nr_pages,
> -void *data)
> -{
> -unsigned long *offlined_pages = (unsigned long *)data;
> -
> -*offlined_pages += __offline_isolated_pages(start, start + nr_pages);
> -return 0;
> -}
> -
> -/*
> - * Check all pages in range, recorded as memory resource, are isolated.
> - */
> -static int
> -check_pages_isolated_cb(unsigned long start_pfn, unsigned long nr_pages,
> -void *data)
> -{
> -return test_pages_isolated(start_pfn, start_pfn + nr_pages,
> - MEMORY_OFFLINE);
> -}
> -
> static int __init cmdline_parse_movable_node(char *p)
> {
>movable_node_enabled = true;
> @@ -1491,7 +1469,7 @@ static int count_system_ram_pages_cb(uns
> int __ref offline_pages(unsigned long start_pfn, unsigned long nr_pages)
> {
>const unsigned long end_pfn = start_pfn + nr_pages;
> -unsigned long pfn, system_ram_pages = 0, offlined_pages = 0;
> +unsigned long pfn, system_ram_pages = 0;
>int ret, node, nr_isolate_pageblock;
>unsigned long flags;
>struct zone *zone;
> @@ -1589,16 +1567,27 @@ int __ref offline_pages(unsigned long st
>reason = "failure to dissolve huge pages";
>goto failed_removal_isolated;
>}
> -/* check again */
> -ret = walk_system_ram_range(start_pfn, end_pfn - start_pfn,
> -NULL, check_pages_isolated_cb);
> -} while (ret);
> -
> -/* Ok, all of our target is isolated.
> - We cannot do rollback at this point. */
> -walk_system_ram_range(start_pfn, end_pfn - st
Re: [PATCH v2 4/5] perf record: Don't clear event's period if set by a term
On Tue, Aug 4, 2020 at 8:50 AM Ian Rogers wrote:
>
> On Tue, Aug 4, 2020 at 7:49 AM Adrian Hunter wrote:
> >
> > On 4/08/20 4:33 pm, Ian Rogers wrote:
> > > On Tue, Aug 4, 2020 at 3:08 AM Adrian Hunter
> > > wrote:
> > >>
> > >> On 28/07/20 11:57 am, Ian Rogers wrote:
> > >>> If events in a group explicitly set a frequency or period with leader
> > >>> sampling, don't disable the samples on those events.
> > >>>
> > >>> Prior to 5.8:
> > >>> perf record -e
> > >>> '{cycles/period=12345000/,instructions/period=6789000/}:S'
> > >>
> > >> Might be worth explaining this use-case some more.
> > >> Perhaps add it to the leader sampling documentation for perf-list.
> > >>
> > >>> would clear the attributes then apply the config terms. In commit
> > >>> 5f34278867b7 leader sampling configuration was moved to after applying
> > >>> the
> > >>> config terms, in the example, making the instructions' event have its
> > >>> period
> > >>> cleared.
> > >>> This change makes it so that sampling is only disabled if configuration
> > >>> terms aren't present.
> > >>>
> > >>> Fixes: 5f34278867b7 ("perf evlist: Move leader-sampling configuration")
> > >>> Signed-off-by: Ian Rogers
> > >>> ---
> > >>> tools/perf/util/record.c | 28
> > >>> 1 file changed, 20 insertions(+), 8 deletions(-)
> > >>>
> > >>> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
> > >>> index a4cc11592f6b..01d1c6c613f7 100644
> > >>> --- a/tools/perf/util/record.c
> > >>> +++ b/tools/perf/util/record.c
> > >>> @@ -2,6 +2,7 @@
> > >>> #include "debug.h"
> > >>> #include "evlist.h"
> > >>> #include "evsel.h"
> > >>> +#include "evsel_config.h"
> > >>> #include "parse-events.h"
> > >>> #include
> > >>> #include
> > >>> @@ -38,6 +39,9 @@ static void evsel__config_leader_sampling(struct
> > >>> evsel *evsel, struct evlist *ev
> > >>> struct perf_event_attr *attr = &evsel->core.attr;
> > >>> struct evsel *leader = evsel->leader;
> > >>> struct evsel *read_sampler;
> > >>> + struct evsel_config_term *term;
> > >>> + struct list_head *config_terms = &evsel->config_terms;
> > >>> + int term_types, freq_mask;
> > >>>
> > >>> if (!leader->sample_read)
> > >>> return;
> > >>> @@ -47,16 +51,24 @@ static void evsel__config_leader_sampling(struct
> > >>> evsel *evsel, struct evlist *ev
> > >>> if (evsel == read_sampler)
> > >>> return;
> > >>>
> > >>> + /* Determine the evsel's config term types. */
> > >>> + term_types = 0;
> > >>> + list_for_each_entry(term, config_terms, list) {
> > >>> + term_types |= 1 << term->type;
> > >>> + }
> > >>> /*
> > >>> - * Disable sampling for all group members other than the leader in
> > >>> - * case the leader 'leads' the sampling, except when the leader
> > >>> is an
> > >>> - * AUX area event, in which case the 2nd event in the group is
> > >>> the one
> > >>> - * that 'leads' the sampling.
> > >>> + * Disable sampling for all group members except those with
> > >>> explicit
> > >>> + * config terms or the leader. In the case of an AUX area event,
> > >>> the 2nd
> > >>> + * event in the group is the one that 'leads' the sampling.
> > >>>*/
> > >>> - attr->freq = 0;
> > >>> - attr->sample_freq= 0;
> > >>> - attr->sample_period = 0;
> > >>> - attr->write_backward = 0;
> > >>> + freq_mask = (1 << EVSEL__CONFIG_TERM_FREQ) | (1 <<
> > >>> EVSEL__CONFIG_TERM_PERIOD);
> > >>> + if ((term_types & freq_mask) == 0) {
> > >>
> > >> It would be nicer to have a helper e.g.
> > >>
> > >> if (!evsel__have_config_term(evsel, FREQ) &&
> > >> !evsel__have_config_term(evsel, PERIOD)) {
> > >
> > > Sure. The point of doing it this way was to avoid repeatedly iterating
> > > over the config term list.
> >
> > But perhaps it is premature optimization
>
> The alternative is more loc. I think we can bike shed on this but it's
> not really changing the substance of the change. I'm keen to try to be
> efficient where we can as we see issues at scale.
>
> Thanks,
> Ian
Ping. Do we want to turn this into multiple O(N) searches using a
helper rather than 1 as coded here?
Thanks,
Ian
> > >
> > >>> + attr->freq = 0;
> > >>> + attr->sample_freq= 0;
> > >>> + attr->sample_period = 0;
> > >>
> > >> If we are not sampling, then maybe we should also put here:
> > >>
> > >> attr->write_backward = 0;
> > >>
> > >>> + }
> > >>
> > >> Then, if we are sampling this evsel shouldn't the backward setting
> > >> match the leader? e.g.
> > >>
> > >> if (attr->sample_freq)
> > >> attr->write_backward = leader->core.attr.write_backward;
> > >
> > > Perhaps that should be a follow up change? This change is trying to
> > > make the behavior match the previous behavior.
> >
> > Sure
> >
> > >
> > > Thanks,
> > > I
Re: [PATCH v3 0/7] set clang minimum version to 10.0.1
On Thu, Sep 3, 2020 at 7:28 PM Nathan Chancellor wrote: > > I would say this should go through either Andrew or Masahiro. We do not > have a formal git tree plus I believe there are other things that need > to happen before we can push stuff to Linus. Note that a git.kernel.org repo/account isn't required to send PRs. The hard requirement is getting your keys signed. Putting stuff into -next is also important. > Given that this is not a regression or a bug fix, it should go into 5.10 > in my opinion. It is a bit late, yeah. Cheers, Miguel
Re: [PATCH v2 2/5] perf record: Prevent override of attr->sample_period for libpfm4 events
On Wed, Jul 29, 2020 at 4:24 PM Ian Rogers wrote:
>
> On Tue, Jul 28, 2020 at 9:10 AM Jiri Olsa wrote:
> >
> > On Tue, Jul 28, 2020 at 05:59:46PM +0200, Jiri Olsa wrote:
> > > On Tue, Jul 28, 2020 at 01:57:31AM -0700, Ian Rogers wrote:
> > > > From: Stephane Eranian
> > > >
> > > > Before:
> > > > $ perf record -c 1 --pfm-events=cycles:period=7
> > > >
> > > > Would yield a cycles event with period=1, instead of 7.
> > > >
> > > > This was due to an ordering issue between libpfm4 parsing
> > > > the event string and perf record initializing the event.
> > > >
> > > > This patch fixes the problem by preventing override for
> > > > events with attr->sample_period != 0 by the time
> > > > perf_evsel__config() is invoked. This seems to have been the
> > > > intent of the author.
> > > >
> > > > Signed-off-by: Stephane Eranian
> > > > Reviewed-by: Ian Rogers
> > > > ---
> > > > tools/perf/util/evsel.c | 3 +--
> > > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > > >
> > > > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> > > > index 811f538f7d77..8afc24e2ec52 100644
> > > > --- a/tools/perf/util/evsel.c
> > > > +++ b/tools/perf/util/evsel.c
> > > > @@ -976,8 +976,7 @@ void evsel__config(struct evsel *evsel, struct
> > > > record_opts *opts,
> > > > * We default some events to have a default interval. But keep
> > > > * it a weak assumption overridable by the user.
> > > > */
> > > > - if (!attr->sample_period || (opts->user_freq != UINT_MAX ||
> > > > -opts->user_interval != ULLONG_MAX)) {
> > > > + if (!attr->sample_period) {
> > >
> > > I was wondering why this wouldn't break record/top
> > > but we take care of the via record_opts__config
> > >
> > > as long as 'perf test attr' works it looks ok to me
> >
> > hum ;-)
> >
> > [jolsa@krava perf]$ sudo ./perf test 17 -v
> > 17: Setup struct perf_event_attr :
> > ...
> > running './tests/attr/test-record-C0'
> > expected sample_period=4000, got 3000
> > FAILED './tests/attr/test-record-C0' - match failure
>
> I'm not able to reproduce this. Do you have a build configuration or
> something else to look at? The test doesn't seem obviously connected
> with this patch.
>
> Thanks,
> Ian
Jiri, any update? Thanks,
Ian
> > jirka
> >
> > >
> > > Acked-by: Jiri Olsa
> > >
> > > thanks,
> > > jirka
> >
Re: [PATCH v2 1/5] perf record: Set PERF_RECORD_PERIOD if attr->freq is set.
On Wed, Jul 29, 2020 at 2:43 PM Ian Rogers wrote:
>
> On Wed, Jul 29, 2020 at 11:52 AM Arnaldo Carvalho de Melo
> wrote:
> >
> > Em Tue, Jul 28, 2020 at 01:57:30AM -0700, Ian Rogers escreveu:
> > > From: David Sharp
> > >
> > > evsel__config() would only set PERF_RECORD_PERIOD if it set attr->freq
> >
> > There is no such thing as 'PERF_RECORD_PERIOD', its PERF_SAMPLE_PERIOD,
> > also...
> >
> > > from perf record options. When it is set by libpfm events, it would not
> > > get set. This changes evsel__config to see if attr->freq is set outside of
> > > whether or not it changes attr->freq itself.
> > >
> > > Signed-off-by: David Sharp
> > > Signed-off-by: Ian Rogers
> > > ---
> > > tools/perf/util/evsel.c | 7 ++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> > > index ef802f6d40c1..811f538f7d77 100644
> > > --- a/tools/perf/util/evsel.c
> > > +++ b/tools/perf/util/evsel.c
> > > @@ -979,13 +979,18 @@ void evsel__config(struct evsel *evsel, struct
> > > record_opts *opts,
> > > if (!attr->sample_period || (opts->user_freq != UINT_MAX ||
> > >opts->user_interval != ULLONG_MAX)) {
> > > if (opts->freq) {
> > > - evsel__set_sample_bit(evsel, PERIOD);
> > > attr->freq = 1;
> > > attr->sample_freq = opts->freq;
> > > } else {
> > > attr->sample_period = opts->default_interval;
> > > }
> > > }
> > > + /*
> > > + * If attr->freq was set (here or earlier), ask for period
> > > + * to be sampled.
> > > + */
> > > + if (attr->freq)
> > > + evsel__set_sample_bit(evsel, PERIOD);
> >
> > Why can't the libpfm code set opts?
> >
> > With this patch we will end up calling evsel__set_sample_bit(evsel,
> > PERIOD) twice, which isn't a problem but looks strange.
>
> Thanks Arnaldo! The case I was looking at was something like:
> perf record --pfm-events cycles:freq=1000
>
> For regular events this would be:
> perf record -e cycles/freq=1000/
>
> With libpfm4 events the perf_event_attr is set up (a public API in
> linux/perf_event.h) and then parse_events__add_event is used (an
> internal API) to make the evsel and this added to the evlist
> (parse_libpfm_events_option). This is similar to the parse_events
> function except rather than set up a perf_event_attr the regular
> parsing sets up config terms that are then applied to evsel and attr
> later in evsel__config, via evsel__apply_config_terms.
>
> I think we can update this change so that in pfm.c after
> parse_events__add_event we do:
> if (attr.freq)
> evsel__set_sample_bit(evsel, PERIOD);
>
> This code could also be part of parse_events__add_event. I think the
> intent in placing this code here was that it is close to the similar
> evsel__apply_config_terms and setting of sample bits in the evsel. The
> logic here is already dependent on reading the attr->sample_period.
>
> I'm not sure I follow the double setting case - I think that is only
> possible with a config term or with period_set (-P).
>
> Thanks,
> Ian
Polite ping. Thanks,
Ian
>
> > - Arnaldo
> >
> > >
> > > if (opts->no_samples)
> > > attr->sample_freq = 0;
> > > --
> > > 2.28.0.163.g6104cc2f0b6-goog
> > >
> >
> > --
> >
> > - Arnaldo
Re: [PATCH] perf parse-events: Use uintptr_t when casting numbers to pointers
On Thu, Sep 3, 2020 at 11:44 AM Arnaldo Carvalho de Melo
wrote:
>
> Hi Ian,
>
> Please check that this is ok with you,
>
> Thanks,
>
> - Arnaldo
Thanks Arnaldo, this looks good to me! There is a separate issue, the
casts are necessary as we have PE_VALUEs that are supposed to be
numbers but here are list*. It seems error prone to have something
that is a pointer or a number, and so I wonder if we can introduce new
tokens in parse-events.y to handle this. It'd also mean that
yydestructors and the like could clean up error states. I'll try to
take a look.
Thanks,
Ian
> commit 0823f768b800cca2592fad3b5649766ae6bc4eba
> Author: Arnaldo Carvalho de Melo
> Date: Thu Sep 3 15:34:20 2020 -0300
>
> perf parse-events: Use uintptr_t when casting numbers to pointers
>
> To address these errors found when cross building from x86_64 to MIPS
> little endian 32-bit:
>
> CC /tmp/build/perf/util/parse-events-bison.o
> util/parse-events.y: In function 'parse_events_parse':
> util/parse-events.y:514:6: error: cast to pointer from integer of
> different size [-Werror=int-to-pointer-cast]
> 514 | (void *) $2, $6, $4);
> | ^
> util/parse-events.y:531:7: error: cast to pointer from integer of
> different size [-Werror=int-to-pointer-cast]
> 531 | (void *) $2, NULL, $4)) {
> | ^
> util/parse-events.y:547:6: error: cast to pointer from integer of
> different size [-Werror=int-to-pointer-cast]
> 547 | (void *) $2, $4, 0);
> | ^
> util/parse-events.y:564:7: error: cast to pointer from integer of
> different size [-Werror=int-to-pointer-cast]
> 564 | (void *) $2, NULL, 0)) {
> | ^
>
> Fixes: cabbf26821aa210f ("perf parse: Before yyabort-ing free components")
> Cc: Adrian Hunter
> Cc: Alexander Shishkin
> Cc: Alexei Starovoitov
> Cc: Andi Kleen
> Cc: Daniel Borkmann
> Cc: Ian Rogers
> Cc: Jin Yao
> Cc: Jiri Olsa
> Cc: John Garry
> Cc: Kan Liang
> Cc: Mark Rutland
> Cc: Martin KaFai Lau
> Cc: Namhyung Kim
> Cc: Peter Zijlstra
> Cc: Song Liu
> Cc: Stephane Eranian
> Cc: Yonghong Song
> Signed-off-by: Arnaldo Carvalho de Melo
>
> diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
> index b9fb91fdc5de9177..645bf4f1859fd76b 100644
> --- a/tools/perf/util/parse-events.y
> +++ b/tools/perf/util/parse-events.y
> @@ -511,7 +511,7 @@ PE_PREFIX_MEM PE_VALUE '/' PE_VALUE ':' PE_MODIFIER_BP
> sep_dc
> list = alloc_list();
> ABORT_ON(!list);
> err = parse_events_add_breakpoint(list, &parse_state->idx,
> - (void *) $2, $6, $4);
> + (void *)(uintptr_t) $2, $6, $4);
> free($6);
> if (err) {
> free(list);
> @@ -528,7 +528,7 @@ PE_PREFIX_MEM PE_VALUE '/' PE_VALUE sep_dc
> list = alloc_list();
> ABORT_ON(!list);
> if (parse_events_add_breakpoint(list, &parse_state->idx,
> - (void *) $2, NULL, $4)) {
> + (void *)(uintptr_t) $2, NULL,
> $4)) {
> free(list);
> YYABORT;
> }
> @@ -544,7 +544,7 @@ PE_PREFIX_MEM PE_VALUE ':' PE_MODIFIER_BP sep_dc
> list = alloc_list();
> ABORT_ON(!list);
> err = parse_events_add_breakpoint(list, &parse_state->idx,
> - (void *) $2, $4, 0);
> + (void *)(uintptr_t) $2, $4, 0);
> free($4);
> if (err) {
> free(list);
> @@ -561,7 +561,7 @@ PE_PREFIX_MEM PE_VALUE sep_dc
> list = alloc_list();
> ABORT_ON(!list);
> if (parse_events_add_breakpoint(list, &parse_state->idx,
> - (void *) $2, NULL, 0)) {
> + (void *)(uintptr_t) $2, NULL,
> 0)) {
> free(list);
> YYABORT;
> }
Re: [PATCH v3 1/4] arm64: smp: Introduce a new IPI as IPI_CALL_NMI_FUNC
On Thu, 3 Sep 2020 at 22:06, Marc Zyngier wrote:
>
> On 2020-09-03 13:05, Sumit Garg wrote:
> > Introduce a new inter processor interrupt as IPI_CALL_NMI_FUNC that
> > can be invoked to run special handlers in NMI context. One such handler
> > example is kgdb_nmicallback() which is invoked in order to round up
> > CPUs
> > to enter kgdb context.
> >
> > As currently pseudo NMIs are supported on specific arm64 platforms
> > which
> > incorporates GICv3 or later version of interrupt controller. In case a
> > particular platform doesn't support pseudo NMIs, IPI_CALL_NMI_FUNC will
> > act as a normal IPI which can still be used to invoke special handlers.
> >
> > Signed-off-by: Sumit Garg
> > ---
> > arch/arm64/include/asm/smp.h | 1 +
> > arch/arm64/kernel/smp.c | 11 +++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/arch/arm64/include/asm/smp.h
> > b/arch/arm64/include/asm/smp.h
> > index 2e7f529..e85f5d5 100644
> > --- a/arch/arm64/include/asm/smp.h
> > +++ b/arch/arm64/include/asm/smp.h
> > @@ -89,6 +89,7 @@ extern void secondary_entry(void);
> >
> > extern void arch_send_call_function_single_ipi(int cpu);
> > extern void arch_send_call_function_ipi_mask(const struct cpumask
> > *mask);
> > +extern void arch_send_call_nmi_func_ipi_mask(const struct cpumask
> > *mask);
> >
> > #ifdef CONFIG_ARM64_ACPI_PARKING_PROTOCOL
> > extern void arch_send_wakeup_ipi_mask(const struct cpumask *mask);
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index b6bde26..1b4c07c 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -74,6 +74,7 @@ enum ipi_msg_type {
> > IPI_TIMER,
> > IPI_IRQ_WORK,
> > IPI_WAKEUP,
> > + IPI_CALL_NMI_FUNC,
> > NR_IPI
> > };
> >
> > @@ -793,6 +794,7 @@ static const char *ipi_types[NR_IPI]
> > __tracepoint_string = {
> > S(IPI_TIMER, "Timer broadcast interrupts"),
> > S(IPI_IRQ_WORK, "IRQ work interrupts"),
> > S(IPI_WAKEUP, "CPU wake-up interrupts"),
> > + S(IPI_CALL_NMI_FUNC, "NMI function call interrupts"),
> > };
> >
> > static void smp_cross_call(const struct cpumask *target, unsigned int
> > ipinr);
> > @@ -840,6 +842,11 @@ void arch_irq_work_raise(void)
> > }
> > #endif
> >
> > +void arch_send_call_nmi_func_ipi_mask(const struct cpumask *mask)
> > +{
> > + smp_cross_call(mask, IPI_CALL_NMI_FUNC);
> > +}
> > +
> > static void local_cpu_stop(void)
> > {
> > set_cpu_online(smp_processor_id(), false);
> > @@ -932,6 +939,10 @@ static void do_handle_IPI(int ipinr)
> > break;
> > #endif
> >
> > + case IPI_CALL_NMI_FUNC:
> > + /* nop, IPI handlers for special features can be added here.
> > */
> > + break;
> > +
> > default:
> > pr_crit("CPU%u: Unknown IPI message 0x%x\n", cpu, ipinr);
> > break;
>
> I'm really not keen on adding more IPIs to the SMP code. One of the
> main reasons for using these SGIs as normal IRQs was to make them
> "requestable" from non-arch code as if they were standard percpu
> interrupts.
>
> What prevents you from moving that all the way to the kgdb code?
>
Since we only have one SGI left (SGI7) which this patch reserves for
NMI purposes, I am not sure what value add do you see to make it
requestable from non-arch code.
Also, allocating SGI7 entirely to kgdb would not allow us to leverage
it for NMI backtrace support via magic sysrq. But with current
implementation we should be able to achieve that.
Moreover, irq ids for normal interrupts are assigned via DT/ACPI, how
do you envision this for SGIs?
-Sumit
> M.
> --
> Jazz is not dead. It just smells funny...
Re: [PATCH] i2c: virtio: add a virtio i2c frontend driver
On 2020/9/3 17:58, Michael S. Tsirkin wrote:
On Thu, Sep 03, 2020 at 01:34:45PM +0800, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
This driver communicates with the backend driver through a
virtio I2C message structure which includes following parts:
- Header: i2c_msg addr, flags, len.
- Data buffer: the pointer to the i2c msg data.
- Status: the processing result from the backend.
People may implement different backend drivers to emulate
different controllers according to their needs. A backend
example can be found in the device model of the open source
project ACRN. For more information, please refer to
https://projectacrn.org.
The virtio device ID 34 is used for this I2C adpter since IDs
before 34 have been reserved by other virtio devices.
Please reserve the ID with the virtio tc so no one conflicts.
Sure. I will send a patch to request the ID.
+
+/**
+ * struct virtio_i2c_hdr - the virtio I2C message header structure
+ * @addr: i2c_msg addr, the slave address
+ * @flags: i2c_msg flags
+ * @len: i2c_msg len
+ */
+struct virtio_i2c_hdr {
+ __virtio16 addr;
+ __virtio16 flags;
+ __virtio16 len;
+} __packed;
virtio16 is for legacy devices, modern ones should be __le.
and we don't really need to pack it I think.
Right. I will fix these. Thanks.
Re: [PATCH v12 3/5] firmware: xilinx: Add RPU configuration APIs
Hi Ben,
Thanks for addressing the comments on the previous version. One comment
below.
Ben Levinsky writes:
> This patch adds APIs to access to configure RPU and its
> processor-specific memory.
>
> That is query the run-time mode of RPU as either split or lockstep as well
> as API to set this mode. In addition add APIs to access configuration of
> the RPUs' tightly coupled memory (TCM).
>
> Signed-off-by: Ben Levinsky
> ---
> v3:
> - add xilinx-related platform mgmt fn's instead of wrapping around
> function pointer in xilinx eemi ops struct
> v4:
> - add default values for enums
> v9:
> - update commit message
> - for zynqmp_pm_set_tcm_config and zynqmp_pm_get_rpu_mode update docs for
> expected output, arguments as well removing unused args
> - remove unused fn zynqmp_pm_get_node_status
> v11:
> - update usage of zynqmp_pm_get_rpu_mode to return rpu mode in enum
> - update zynqmp_pm_set_tcm_config and zynqmp_pm_set_rpu_mode arguments to
> remove unused args
> v12:
> - in drivers/firmware/zynqmp.c, update zynqmp_pm_set_rpu_mode so rpu_mode
> is only set if no error
> - update args for zynqmp_pm_set_rpu_mode, zynqmp_pm_set_tcm_config fn arg's to
> reflect what is expected in the function and the usage in
> zynqmp_r5_remoteproc accordingly
> ---
> drivers/firmware/xilinx/zynqmp.c | 60
> include/linux/firmware/xlnx-zynqmp.h | 18 +
> 2 files changed, 78 insertions(+)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c
> b/drivers/firmware/xilinx/zynqmp.c
> index a966ee956573..916a0b15ab33 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -846,6 +846,66 @@ int zynqmp_pm_release_node(const u32 node)
> }
> EXPORT_SYMBOL_GPL(zynqmp_pm_release_node);
>
> +/**
> + * zynqmp_pm_get_rpu_mode() - Get RPU mode
> + * @node_id: Node ID of the device
> + * @rpu_mode:return by reference value
> + * either split or lockstep
> + *
> + * Return: return 0 on success or error+reason.
> + * if success, then rpu_mode will be set
> + * to current rpu mode.
> + */
> +int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode)
> +{
> + u32 ret_payload[PAYLOAD_ARG_CNT];
> + int ret;
> +
> + ret = zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
> + IOCTL_GET_RPU_OPER_MODE, 0, 0, ret_payload);
> +
> + /* only set rpu_mode if no error */
> + *rpu_mode = ret_payload[0];
The comment and the statement do not match. rpu_mode is being
un-conditionally set even if there is an error.
It's not clear which is correct - the code or the comment?
Other than that, the rest of the patch looks fine.
Thanks,
Punit
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_get_rpu_mode);
> +
> +/**
> + * zynqmp_pm_set_rpu_mode() - Set RPU mode
> + * @node_id: Node ID of the device
> + * @rpu_mode:Argument 1 to requested IOCTL call. either split or
> lockstep
> + *
> + * This function is used to set RPU mode to split or
> + * lockstep
> + *
> + * Return: Returns status, either success or error+reason
> + */
> +int zynqmp_pm_set_rpu_mode(u32 node_id, enum rpu_oper_mode rpu_mode)
> +{
> + return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
> +IOCTL_SET_RPU_OPER_MODE, (u32)rpu_mode,
> +0, NULL);
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_set_rpu_mode);
> +
> +/**
> + * zynqmp_pm_set_tcm_config - configure TCM
> + * @tcm_mode:Argument 1 to requested IOCTL call
> + * either PM_RPU_TCM_COMB or PM_RPU_TCM_SPLIT
> + *
> + * This function is used to set RPU mode to split or combined
> + *
> + * Return: status: 0 for success, else failure
> + */
> +int zynqmp_pm_set_tcm_config(u32 node_id, enum rpu_tcm_comb tcm_mode)
> +{
> + return zynqmp_pm_invoke_fn(PM_IOCTL, node_id,
> +IOCTL_TCM_COMB_CONFIG, (u32)tcm_mode, 0,
> +NULL);
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_set_tcm_config);
> +
> /**
> * zynqmp_pm_force_pwrdwn - PM call to request for another PU or subsystem to
> * be powered down forcefully
> diff --git a/include/linux/firmware/xlnx-zynqmp.h
> b/include/linux/firmware/xlnx-zynqmp.h
> index 6241c5ac51b3..79aa2fcbcd54 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -385,6 +385,9 @@ int zynqmp_pm_request_wake(const u32 node,
> const bool set_addr,
> const u64 address,
> const enum zynqmp_pm_request_ack ack);
> +int zynqmp_pm_get_rpu_mode(u32 node_id, enum rpu_oper_mode *rpu_mode);
> +int zynqmp_pm_set_rpu_mode(u32 node_id, u32 arg1);
> +int zynqmp_pm_set_tcm_config(u32 node_id, u32 arg1);
> #else
> static inline struct zynqmp_eemi_ops *zynqmp_pm_get_eemi_ops(void)
> {
> @@ -549,6 +552,21 @@ static inline int zynqmp_pm_request_wake(const u32 nod
Re: [PATCH 1/4] drivers: hv: dxgkrnl: core code
On Thu, Sep 03, 2020 at 02:39:05PM -0700, Iouri Tarassov wrote:
> Hi Greg,
>
> On 8/27/2020 11:18 PM, Greg KH wrote:
> > On Thu, Aug 27, 2020 at 05:25:23PM -0700, Iouri Tarassov wrote:
> > > > > +bool dxghwqueue_acquire_reference(struct dxghwqueue *hwqueue)
> > > > > +{
> > > > > + return refcount_inc_not_zero(&hwqueue->refcount);
> > > > > +}
> > > > > > Midlayers are evil.
> > > I strongly agree in general, but think that in our case the layers are
> > > very
> > > small. It allows to quickly find all places where a reference/dereference
> > > on
> > > an object is done and addition of debug tracing to catch errors.
> >
> > Again, no, please remove all layers like this. They just make it
> > impossible for others to review and understand the code over time.
> >
> > Also, in this specific case, it would have allowed me to easily realize
> > that you are doing this type of call incorrectly and should be using a
> > different data structure :)
>
> Are you suggesting that the current code is incorrect? Could you comment
> what changes need to be done?
You should be using the built-in reference counting object (a kref) and
not trying to roll your own as you did here. That way we "know" you got
the logic right and do not have to audit your codebase to prove that
your hand-made one is correct.
thanks,
greg k-h
Re: [PATCH 0/7] ASoC: soundwire: Move sdw stream operations to
On 03-09-20, 09:05, Pierre-Louis Bossart wrote: > > > On 9/3/20 5:42 AM, Vinod Koul wrote: > > On 01-09-20, 23:02, Bard Liao wrote: > > > sdw stream operation APIs can be called once per stream. dailink > > > callbacks are good places to call these APIs. > > > > Again, please mention here if this is to be merged thru sdw tree or ASoC > > tree > > Good point, I thought it wouldn't matter but it does. I just gave it a try > and there seems to be a conflict on Mark's tree w/ drivers/soundwire/intel.c > (likely due to missing patches already added to Vinod's tree). > > So this should go to Vinod's tree with Mark's Acked-by tag on the ASoC > changes. > > Alternatively we can also split this in two, with ASoC-only and > SoundWire-only patches in separate series if it's easier for maintainers. We > would lose the rationale for the changes but that's not essential. If there are no dependencies on each other, that is best preferred option. One should mention in cover-letter about the linked series though. > > > > Pierre-Louis Bossart (7): > > >ASoC: soc-dai: clarify return value for get_sdw_stream() > > >soundwire: stream: fix NULL/IS_ERR confusion > > >soundwire: intel: fix NULL/ERR_PTR confusion > > >ASOC: Intel: sof_sdw: add dailink .trigger callback > > >ASOC: Intel: sof_sdw: add dailink .prepare and .hw_free callback > > > > These should be ASoC > > Right. if you are fine with the content and this goes in your tree, can this > be modified while applying? Or do want a v2? > > > >soundwire: intel: remove .trigger operation > > >soundwire: intel: remove stream handling from .prepare and .hw_free > > > > > > drivers/soundwire/intel.c| 60 --- > > > drivers/soundwire/stream.c | 2 +- > > > include/sound/soc-dai.h | 3 +- > > > sound/soc/intel/boards/sof_sdw.c | 81 > > > 4 files changed, 92 insertions(+), 54 deletions(-) > > > > > > -- > > > 2.17.1 > > -- ~Vinod
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:122:19: warning: initialized field overwritten
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 59126901f200f5fc907153468b03c64e0081b6e6
commit: af776a3e1c304bf0409106cd2306173885e415f2 drm/msm/dpu: add SM8250 to hw
catalog
date: 5 weeks ago
config: arm64-randconfig-r013-20200904 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout af776a3e1c304bf0409106cd2306173885e415f2
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:122:19: warning: initialized
>> field overwritten [-Woverride-init]
122 | .max_linewidth = 4096,
| ^~~~
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:122:19: note: (near
initialization for 'sm8250_dpu_caps.max_linewidth')
In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:11:
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h:7:23: warning:
'qcom_compressed_supported_formats' defined but not used
[-Wunused-const-variable=]
7 | static const uint32_t qcom_compressed_supported_formats[] = {
| ^
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=af776a3e1c304bf0409106cd2306173885e415f2
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout af776a3e1c304bf0409106cd2306173885e415f2
vim +122 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
110
111 static const struct dpu_caps sm8250_dpu_caps = {
112 .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
113 .max_mixer_blendstages = 0xb,
114 .max_linewidth = 4096,
115 .qseed_type = DPU_SSPP_SCALER_QSEED3, /* TODO: qseed3 lite */
116 .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
117 .ubwc_version = DPU_HW_UBWC_VER_40,
118 .has_src_split = true,
119 .has_dim_layer = true,
120 .has_idle_pc = true,
121 .has_3d_merge = true,
> 122 .max_linewidth = 4096,
123 .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
124 };
125
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: Packet gets stuck in NOLOCK pfifo_fast qdisc
Cong Wang wrote:
> On Thu, Sep 3, 2020 at 1:40 AM Paolo Abeni wrote:
> >
> > On Wed, 2020-09-02 at 22:01 -0700, Cong Wang wrote:
> > > Can you test the attached one-line fix? I think we are overthinking,
> > > probably all
> > > we need here is a busy wait.
> >
> > I think that will solve, but I also think that will kill NOLOCK
> > performances due to really increased contention.
>
> Yeah, we somehow end up with more locks (seqlock, skb array lock)
> for lockless qdisc. What an irony... ;)
I went back to the original nolock implementation code to try and figure
out how this was working in the first place.
After initial patch series we have this in __dev_xmit_skb()
if (q->flags & TCQ_F_NOLOCK) {
if (unlikely(test_bit(__QDISC_STATE_DEACTIVATED, &q->state))) {
__qdisc_drop(skb, &to_free);
rc = NET_XMIT_DROP;
} else {
rc = q->enqueue(skb, q, &to_free) & NET_XMIT_MASK;
__qdisc_run(q);
}
if (unlikely(to_free))
kfree_skb_list(to_free);
return rc;
}
One important piece here is we used __qdisc_run(q) instead of
what we have there now qdisc_run(q). Here is the latest code,
if (q->flags & TCQ_F_NOLOCK) {
rc = q->enqueue(skb, q, &to_free) & NET_XMIT_MASK;
qdisc_run(q);
...
__qdisc_run is going to always go into a qdisc_restart loop and
dequeue packets. There is no check here to see if another CPU
is running or not. Compare that to qdisc_run()
static inline void qdisc_run(struct Qdisc *q)
{
if (qdisc_run_begin(q)) {
__qdisc_run(q);
qdisc_run_end(q);
}
}
Here we have all the racing around qdisc_is_running() that seems
unsolvable.
Seems we flipped __qdisc_run to qdisc_run here 32f7b44d0f566
("sched: manipulate __QDISC_STATE_RUNNING in qdisc_run_* helpers").
Its not clear to me from thatpatch though why it was even done
there?
Maybe this would unlock us,
diff --git a/net/core/dev.c b/net/core/dev.c
index 7df6c9617321..9b09429103f1 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3749,7 +3749,7 @@ static inline int __dev_xmit_skb(struct sk_buff *skb,
struct Qdisc *q,
if (q->flags & TCQ_F_NOLOCK) {
rc = q->enqueue(skb, q, &to_free) & NET_XMIT_MASK;
- qdisc_run(q);
+ __qdisc_run(q);
if (unlikely(to_free))
kfree_skb_list(to_free);
Per other thread we also need the state deactivated check added
back.
>
> >
> > At this point I fear we could consider reverting the NOLOCK stuff.
> > I personally would hate doing so, but it looks like NOLOCK benefits are
> > outweighed by its issues.
>
> I agree, NOLOCK brings more pains than gains. There are many race
> conditions hidden in generic qdisc layer, another one is enqueue vs.
> reset which is being discussed in another thread.
Sure. Seems they crept in over time. I had some plans to write a
lockless HTB implementation. But with fq+EDT with BPF it seems that
it is no longer needed, we have a more generic/better solution. So
I dropped it. Also most folks should really be using fq, fq_codel,
etc. by default anyways. Using pfifo_fast alone is not ideal IMO.
Thanks,
John
Re: [PATCH] cpufreq,cppc: fix issue when hotplugging out policy->cpu
On 03-09-20, 12:19, Ionela Voinescu wrote:
> An issue is observed in the cpufreq CPPC driver when having dependency
> domains (PSD) and the policy->cpu is hotplugged out.
>
> Considering a platform with 4 CPUs and 2 PSD domains (CPUs 0 and 1 in
> PSD-1, CPUs 2 and 3 in PSD-2), cppc_cpufreq_cpu_init() will be called
> for the two cpufreq policies that are created and it will set
> all_cpu_data[policy->cpu]->cpu = policy->cpu.
>
> Therefore all_cpu_data[0]->cpu=0, and all_cpu_data[2]->cpu=2. But for
> CPUs 1 and 3, all_cpu_data[{1,3}]->cpu will remain 0 from the structure
> allocation.
>
> If CPU 2 is hotplugged out, CPU 3 will become policy->cpu. But its
> all_cpu_data[3]->cpu will remain 0. Later, when the .target() function
> is called for policy2, the cpu argument to cppc_set_perf() will be 0 and
> therefore it will use the performance controls of CPU 0, which will
> result in a performance level change for the wrong domain.
>
> While the possibility of setting a correct CPU value in the per-cpu
> cppc_cpudata structure is available, it can be noticed that this cpu value
> is not used at all outside the .target() function, where it's not actually
> necessary. Therefore, remove the cpu variable from the cppc_cpudata
> structure and use policy->cpu in the .target() function as done for the
> other CPPC cpufreq functions.
>
> Fixes: 5477fb3bd1e8 ("ACPI / CPPC: Add a CPUFreq driver for use with CPPC")
> Signed-off-by: Ionela Voinescu
> Cc: Rafael J. Wysocki
> Cc: Viresh Kumar
> ---
>
> Testing was done on a Juno R2 platform (with the proper ACPI/CPPC setup):
> CPUs 0, 1, 2, 3 are in PSD-0 (policy0), CPUs 4 and 5 are in PSD-4
> (policy4).
>
> Before the fix:
>
> root@sqwt-ubuntu:~# dmesg | grep address
> [2.165177] ACPI CPPC: ACPI desired perf address 0: - 80001004d200
> [2.174226] ACPI CPPC: ACPI desired perf address 1: - 800010055200
> [2.183231] ACPI CPPC: ACPI desired perf address 2: - 80001005d200
> [2.192234] ACPI CPPC: ACPI desired perf address 3: - 800010065200
> [2.201245] ACPI CPPC: ACPI desired perf address 4: - 80001006d218
> [2.210256] ACPI CPPC: ACPI desired perf address 5: - 800011ff1218
> [..]
> [2.801940] ACPI CPPC: Writing to address for CPU 0:80001004d200: 38300
> [2.835286] ACPI CPPC: Writing to address for CPU 4:80001006d218:
> 102400
> [..]
> root@sqwt-ubuntu:~# cd /sys/devices/system/cpu/cpufreq/
> root@sqwt-ubuntu:/sys/devices/system/cpu/cpufreq# echo 60 >
> policy4/scaling_setspeed
> [ 72.098758] ACPI CPPC: Writing to address for CPU 4:80001006d218: 51200
> root@sqwt-ubuntu:/sys/devices/system/cpu/cpufreq# echo 120 >
> policy4/scaling_setspeed
> [ 85.430645] ACPI CPPC: Writing to address for CPU 4:80001006d218:
> 102400
> root@sqwt-ubuntu:/sys/devices/system/cpu/cpufreq# echo 0 > ../cpu4/online
> [ 102.606380] CPPC Cpufreq:CPPC: Calculate: (6285/261)*4266=102727.
> [ 102.612491] CPPC Cpufreq:CPPC: Core rate = 1203832, arch timer rate:
> 5000
> [ 102.619659] ACPI CPPC: Writing to address for CPU 0:80001004d200:
> 102400
> [ 102.626898] CPU4: shutdown
> root@sqwt-ubuntu:/sys/devices/system/cpu/cpufreq# echo 60 >
> policy4/scaling_setspeed
> [ 141.116882] ACPI CPPC: Writing to address for CPU 0:80001004d200: 51200
> root@sqwt-ubuntu:/sys/devices/system/cpu/cpufreq# echo 120 >
> policy4/scaling_setspeed
> [ 159.288273] ACPI CPPC: Writing to address for CPU 0:80001004d200:
> 102400
>
>
> After the fix:
>
> root@sqwt-ubuntu:~# cd /sys/devices/system/cpu/cpufreq/
> root@sqwt-ubuntu:/sys/devices/system/cpu/cpufreq# echo 60 >
> policy4/scaling_setspeed
> [ 139.903322] ACPI CPPC: Writing to address for CPU 4:80001006d218: 51200
> root@sqwt-ubuntu:/sys/devices/system/cpu/cpufreq# echo 120 >
> policy4/scaling_setspeed
> [ 147.279040] ACPI CPPC: Writing to address for CPU 4:80001006d218:
> 102400
> root@sqwt-ubuntu:/sys/devices/system/cpu/cpufreq# echo 0 > ../cpu4/online
> [ 153.598686] CPPC Cpufreq:CPPC: Calculate: (6171/253)*4266=104053.
> [ 153.604797] CPPC Cpufreq:CPPC: Core rate = 1219371, arch timer rate:
> 5000
> [ 153.611960] ACPI CPPC: Writing to address for CPU 5:800011ff1218:
> 102400
> [ 153.619190] CPU4: shutdown
> [ 153.621911] psci: CPU4 killed (polled 0 ms)
> root@sqwt-ubuntu:/sys/devices/system/cpu/cpufreq# echo 60 >
> policy4/scaling_setspeed
> [ 170.122495] ACPI CPPC: Writing to address for CPU 5:800011ff1218: 51200
> root@sqwt-ubuntu:/sys/devices/system/cpu/cpufreq# echo 120 >
> policy4/scaling_setspeed
> [ 177.206342] ACPI CPPC: Writing to address for CPU 5:800011ff1218:
> 102400
>
> Thanks,
> Ionela.
>
> drivers/cpufreq/cppc_cpufreq.c | 8
> include/acpi/cppc_acpi.h | 1 -
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index f29e8d0553a8..54457f5fe49e 100644
> --- a/drivers/cpufre
Re: [PATCH net-next RFC v3 02/14] devlink: Add reload actions counters
On 9/2/2020 3:01 AM, Jakub Kicinski wrote:
External email: Use caution opening links or attachments
On Tue, 1 Sep 2020 22:05:36 +0300 Moshe Shemesh wrote:
+void devlink_reload_actions_cnts_update(struct devlink *devlink, unsigned long
actions_done)
+{
+ int action;
+
+ for (action = 0; action < DEVLINK_RELOAD_ACTION_MAX; action++) {
+ if (!test_bit(action, &actions_done))
+ continue;
+ devlink->reload_actions_cnts[action]++;
+ }
+}
+EXPORT_SYMBOL_GPL(devlink_reload_actions_cnts_update);
I don't follow why this is an exported symbol if you only use it from
this .c. Looks like a leftover...
Not leftover, in the commit message I notified and explained why I
exposed it.
We should generate devlink notifications on this event (down and up)
so the counters don't have to be exposed to drivers. We need a more
thorough API.
I will add devlink notifications for the counters, but what I meant here
is to have counters data updated also on hosts that are having reset but
didn't trigger the fw_activate action by themselves, so such host's
devlink is not aware of it. I mean fw_activate action was triggered on
another's host devlink sharing the same device/firmware.
Maybe I should have named this function
devlink_reload_implicit_actions_performed().
Re: [PATCH] mm: workingset: ignore slab memory size when calculating shadows pressure
On Thu, Sep 03, 2020 at 09:10:59PM -0700, Andrew Morton wrote:
> On Thu, 3 Sep 2020 16:00:55 -0700 Roman Gushchin wrote:
>
> > In the memcg case count_shadow_nodes() sums the number of pages in lru
> > lists and the amount of slab memory (reclaimable and non-reclaimable)
> > as a baseline for the allowed number of shadow entries.
> >
> > It seems to be a good analogy for the !memcg case, where
> > node_present_pages() is used. However, it's not quite true, as there
> > two problems:
> >
> > 1) Due to slab reparenting introduced by commit fb2f2b0adb98 ("mm:
> > memcg/slab: reparent memcg kmem_caches on cgroup removal") local
> > per-lruvec slab counters might be inaccurate on non-leaf levels.
> > It's the only place where local slab counters are used.
> >
> > 2) Shadow nodes by themselves are backed by slabs. So there is a loop
> > dependency: the more shadow entries are there, the less pressure the
> > kernel applies to reclaim them.
> >
> > Fortunately, there is a simple way to solve both problems: slab
> > counters shouldn't be taken into the account by count_shadow_nodes().
> >
> > ...
> >
> > --- a/mm/workingset.c
> > +++ b/mm/workingset.c
> > @@ -495,10 +495,6 @@ static unsigned long count_shadow_nodes(struct
> > shrinker *shrinker,
> > for (pages = 0, i = 0; i < NR_LRU_LISTS; i++)
> > pages += lruvec_page_state_local(lruvec,
> > NR_LRU_BASE + i);
> > - pages += lruvec_page_state_local(
> > - lruvec, NR_SLAB_RECLAIMABLE_B) >> PAGE_SHIFT;
> > - pages += lruvec_page_state_local(
> > - lruvec, NR_SLAB_UNRECLAIMABLE_B) >> PAGE_SHIFT;
> > } else
> > #endif
> > pages = node_present_pages(sc->nid);
>
> Did this have any observable runtime effects?
Most likely not.
I maybe saw the second effect once, but it was backed up by a bug in the inode
reclaim path in the exact kernel version I used (not an upstream one).
The first problem is pure theoretical, I'm just not comfortable with using these
counters, which are known to be inaccurate after reparenting.
That's why I didn't add stable@.
Thanks!
Re: [PATCH v2 2/3] soundwire: SDCA: add helper macro to access controls
On 01-09-20, 11:22, Pierre-Louis Bossart wrote: > The upcoming SDCA (SoundWire Device Class Audio) specification defines > a hierarchical encoding to interface with Class-defined capabilities. > > The specification is not yet accessible to the general public but this > information is released with explicit permission from the MIPI Board > to avoid delays with SDCA support on Linux platforms. > > A block of 64 MBytes of register addresses is allocated to SDCA > controls, starting at address 0x4000. The 26 LSBs which identify > individual controls are set based on the following variables: > > - Function Number. An SCDA device can be split in up to 8 independent > Functions. Each of these Functions is described in the SDCA > specification, e.g. Smart Amplifier, Smart Microphone, Simple > Microphone, Jack codec, HID, etc. > > - Entity Number. Within each Function, an Entity is an identifiable > block. Up to 127 Entities are connected in a pre-defined > graph (similar to USB), with Entity0 reserved for Function-level > configurations. In contrast to USB, the SDCA spec pre-defines > Function Types, topologies, and allowed options, i.e. the degree of > freedom is not unlimited to limit the possibility of errors in > descriptors leading to software quirks. > > - Control Selector. Within each Entity, the SDCA specification defines > up-to 48 controls such as Mute, Gain, AGC, etc, and 16 > implementation defined ones. Some Control Selectors might be used > for low-level platform setup, and other exposed to applications and > users. Note that the same Control Selector capability, e.g. Latency > control, might be located at different offsets in different > entities - the Control Selector mapping is Entity-specific. > > - Control Number. Some Control Selectors allow channel-specific values > to be set, with up to 64 channels allowed. This is mostly used for > volume control. > > - Current/Next values. Some Control Selectors are > 'Dual-Ranked'. Software may either update the Current value directly > for immediate effect. Alternatively, software may write into the > 'Next' values and update the SoundWire 1.2 'Commit Groups' register > to copy 'Next' values into 'Current' ones in a synchronized > manner. This is different from bank switching which is typically > used to change the bus configuration only. > > - MBQ. the Multi-Byte Quantity bit is used to provide atomic updates > when accessing more that one byte, for example a 16-bit volume > control would be updated consistently, the intermediate values > mixing old MSB with new LSB are not applied. > > These 6 parameters are used to build a 32-bit address to access the > desired Controls. Because of address range, paging is required, but > the most often used parameter values are placed in the lower 16 bits > of the address. This helps to keep the paging registers constant while > updating Controls for a specific Device/Function. This is good, thanks for adding it in changelog. Can you also add this description to Documentation (that can come as an individual patch), > > Reviewed-by: Rander Wang > Reviewed-by: Guennadi Liakhovetski > Reviewed-by: Kai Vehmanen > Acked-by: Bard Liao > Signed-off-by: Pierre-Louis Bossart > --- > include/linux/soundwire/sdw_registers.h | 33 + > 1 file changed, 33 insertions(+) > > diff --git a/include/linux/soundwire/sdw_registers.h > b/include/linux/soundwire/sdw_registers.h > index 5d3c271af7d1..99ff7afc27a2 100644 > --- a/include/linux/soundwire/sdw_registers.h > +++ b/include/linux/soundwire/sdw_registers.h > @@ -305,4 +305,37 @@ > #define SDW_CASC_PORT_MASK_INTSTAT3 1 > #define SDW_CASC_PORT_REG_OFFSET_INTSTAT32 > > +/* > + * v1.2 device - SDCA address mapping > + * > + * Spec definition > + * BitsContents > + * 31 0 (required by addressing range) > + * 30:26 0b1 (Control Prefix) So this is for 30:26 > + * 25 0 (Reserved) > + * 24:22 Function Number [2:0] > + * 21 Entity[6] > + * 20:19 Control Selector[5:4] > + * 18 0 (Reserved) > + * 17:15 Control Number[5:3] > + * 14 Next > + * 13 MBQ > + * 12:7Entity[5:0] > + * 6:3 Control Selector[3:0] > + * 2:0 Control Number[2:0] > + */ > + > +#define SDW_SDCA_CTL(fun, ent, ctl, ch) > \ > + (BIT(30)| > \ Programmatically this is fine, but then since we are defining for the description above, IMO it would actually make sense for this to be defined as FIELD_PREP: FIELD_PREP(GENMASK(30, 26), 1) or better u32_encode_bits(GENMASK(30, 26), 1) > + FIELD_PREP(GENMASK(24, 22), FIELD_GET(GENMASK(2, 0), (fun)))| > \ Why not use u32_encode_bits(G
Re: [PATCH 0/2] add support for Hisilicon SD5203 vector interrupt controller
On 2020/9/4 0:46, Marc Zyngier wrote: > On 2020-09-03 13:05, Zhen Lei wrote: >> The interrupt controller of SD5203 SoC is VIC(vector interrupt controller), >> it's >> based on Synopsys DesignWare APB interrupt controller (dw_apb_ictl) IP, but >> it >> can not directly use dw_apb_ictl driver. The main reason is that VIC is used >> as >> primary interrupt controller and dw_apb_ictl driver worked for secondary >> interrupt controller. > > What prevents you from improving the existing driver so that it can act > as a primary interrupt controller? It shouldn't be rocket science, really. > > There are some examples in the tree of drivers that can be used in > both situations (GIC, VIC OK, thanks for the tip. > > Thanks, > > M.
Re: [PATCH v2 00/28] Add support for Clang LTO
On Thu, Sep 03, 2020 at 04:34:09PM -0700, Kees Cook wrote: > On Thu, Sep 03, 2020 at 01:30:25PM -0700, Sami Tolvanen wrote: > > This patch series adds support for building x86_64 and arm64 kernels > > with Clang's Link Time Optimization (LTO). > > Tested-by: Kees Cook Tested-by: Nathan Chancellor I have been continuously running this series on virtualized x86_64 (WSL2 on my home workstation) and bare metal arm64 (Raspberry Pi 4) with no major issues or regressions noticed. > FWIW, this gives me a happy booting x86 kernel: > > # cat /proc/version > Linux version 5.9.0-rc3+ (kees@amarok) (clang version 12.0.0 > (https://github.com/llvm/llvm-project.git > db1ec04963cce70f2593e58cecac55f2e6accf52), LLD 12.0.0 > (https://github.com/llvm/llvm-project.git > db1ec04963cce70f2593e58cecac55f2e6accf52)) #1 SMP Thu Sep 3 15:54:14 PDT 2020 > # zgrep 'LTO[_=]' /proc/config.gz > CONFIG_LTO=y > CONFIG_ARCH_SUPPORTS_LTO_CLANG=y > CONFIG_ARCH_SUPPORTS_THINLTO=y > CONFIG_THINLTO=y > # CONFIG_LTO_NONE is not set > CONFIG_LTO_CLANG=y > > I'd like to find a way to get this series landing sanely. It has > dependencies on fixes/features in a few trees, and it looks like > it's been difficult to keep forward momentum on LTO while trying to > simultaneously chase changes in those trees, especially since it means > no one care carry LTO in -next without shared branches. To that end, > I'd like to find a way forward where Sami doesn't have to keep carrying > a couple dozen patches. :) > > The fixes/features outside of, or partially overlapping, Masahiro's > kbuild tree appear to be: > > [PATCH v2 01/28] x86/boot/compressed: Disable relocation relaxation > [PATCH v2 02/28] x86/asm: Replace __force_order with memory clobber > [PATCH v2 03/28] lib/string.c: implement stpcpy > [PATCH v2 04/28] RAS/CEC: Fix cec_init() prototype > [PATCH v2 05/28] objtool: Add a pass for generating __mcount_loc > [PATCH v2 06/28] objtool: Don't autodetect vmlinux.o > [PATCH v2 07/28] kbuild: add support for objtool mcount > [PATCH v2 08/28] x86, build: use objtool mcount > [PATCH v2 17/28] PCI: Fix PREL32 relocations for LTO > [PATCH v2 20/28] efi/libstub: disable LTO > [PATCH v2 21/28] drivers/misc/lkdtm: disable LTO for rodata.o > [PATCH v2 22/28] arm64: export CC_USING_PATCHABLE_FUNCTION_ENTRY > [PATCH v2 23/28] arm64: vdso: disable LTO > [PATCH v2 24/28] KVM: arm64: disable LTO for the nVHE directory > [PATCH v2 25/28] arm64: allow LTO_CLANG and THINLTO to be selected > [PATCH v2 26/28] x86, vdso: disable LTO only for vDSO > [PATCH v2 27/28] x86, relocs: Ignore L4_PAGE_OFFSET relocations > [PATCH v2 28/28] x86, build: allow LTO_CLANG and THINLTO to be selected > > The distinctly kbuild patches are: > > [PATCH v2 09/28] kbuild: add support for Clang LTO > [PATCH v2 10/28] kbuild: lto: fix module versioning > [PATCH v2 11/28] kbuild: lto: postpone objtool > [PATCH v2 12/28] kbuild: lto: limit inlining > [PATCH v2 13/28] kbuild: lto: merge module sections > [PATCH v2 14/28] kbuild: lto: remove duplicate dependencies from .mod files > [PATCH v2 15/28] init: lto: ensure initcall ordering > [PATCH v2 16/28] init: lto: fix PREL32 relocations > [PATCH v2 18/28] modpost: lto: strip .lto from module names > [PATCH v2 19/28] scripts/mod: disable LTO for empty.c > > Patch 3 is in -mm and I expect it will land in the next rc (I hope, > since it's needed universally for Clang builds). > > Patch 4 is living in -tip, to appear shortly in -next, AFAICT? > > I would expect 1 and 2 to appear in -tip soon, but I'm not sure? > > For patches 5, 6, 7, and 8 I would expect them to normally go via -tip's > objtool tree, but getting an Ack would let them land elsewhere. > > Patch 17 I'd expect to normally go via Bjorn's tree, but he's given an > Ack so it can live elsewhere without surprises. :) > > Patches 19, 20, 21, 23, 24, 26 are all simple "just disable LTO" > patches. > > This leaves 9-16 and 18. Patches 10, 12, 14, 16, and 18 seem mostly > "mechanical" in nature, leaving the bulk of the review on patches 9, > 11, 13, and 15. > > Masahiro, given the spread of dependent patches between 2 (or more?) -tip > branches and -mm, how do you want to proceed? I wonder if it might > be possible to create a shared branch to avoid merge headaches, and I > (or -tip folks, or you) could carry patches 1-8 there so patches 9 and > later could have a common base? > > Thanks! > > -- > Kees Cook > For what it's worth, the static call series that is in -tip and about to land in -next conflicts relatively heavy with this. There are fairly innocuous conflicts in some objtool files but two contextual changes are needed to keep things building. It probably makes sense for most if not all of this to live in -tip with acks. Ideally, if the stpcpy patch gets merged into an -rc, this can just be based on that. check.c:556:80: error: too few arguments to function call, expected 5, have 4 sec = elf_create_section(file->elf, "__mcount_loc", sizeof(unsigned long),
Re: [PATCH v5 3/3] arm64: Add IMA kexec buffer to DTB
On 9/3/20 3:11 PM, Thiago Jung Bauermann wrote:
Lakshmi Ramasubramanian writes:
The address and size of the current kernel's IMA measurement log
need to be added to the device tree's IMA kexec buffer node for
the log to be carried over to the next kernel on the kexec call.
Add the IMA measurement log buffer properties to the device tree for
ARM64 and reserve the memory for storing the IMA log.
Update CONFIG_KEXEC_FILE to select CONFIG_HAVE_IMA_KEXEC to
indicate that the IMA measurement log information is present in
the device tree.
Co-developed-by: Prakhar Srivastava
Signed-off-by: Prakhar Srivastava
Signed-off-by: Lakshmi Ramasubramanian
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/machine_kexec_file.c | 15 +++
2 files changed, 16 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6d232837cbee..9f03c8245e5b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1077,6 +1077,7 @@ config KEXEC
config KEXEC_FILE
bool "kexec file based system call"
select KEXEC_CORE
+ select HAVE_IMA_KEXEC
help
This is new version of kexec system call. This system call is
file based and takes file descriptors as system call argument
diff --git a/arch/arm64/kernel/machine_kexec_file.c
b/arch/arm64/kernel/machine_kexec_file.c
index 361a1143e09e..0fe3d629eefe 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -136,6 +136,21 @@ static int setup_dtb(struct kimage *image,
FDT_PROP_KASLR_SEED);
}
+ /* add ima-kexec-buffer */
+ if (image->arch.ima_buffer_size > 0) {
+ ret = fdt_appendprop_addrrange(dtb, 0, off,
+ FDT_PROP_IMA_KEXEC_BUFFER,
+ image->arch.ima_buffer_addr,
+ image->arch.ima_buffer_size);
+ if (ret)
+ return (ret == -FDT_ERR_NOSPACE ? -ENOMEM : -EINVAL);
+
+ ret = fdt_add_mem_rsv(dtb, image->arch.ima_buffer_addr,
+ image->arch.ima_buffer_size);
+ if (ret)
+ goto out;
+ }
+
/* add rng-seed */
if (rng_is_initialized()) {
void *rng_seed;
I just noticed one more thing this code isn't doing compared to the
powerpc version (sorry to bring these issues piecemeal, I didn't realize
this before):
You're not checking whether there already is a device tree property and
corresponding memory reservation for an IMA kexec buffer that the
currently running kernel might have received from a previous kernel. In
that case, this code will do the wrong thing because
fdt_appendprop_addrrange() will append the range to the existing
property, which is not what you want. You'll also have a memory
reservation entry for a stale IMA kexec buffer, which just wastes
memory.
So one thing you need to do, whether or not there's an IMA kexec buffer
to be passed to the next kernel, is to remove any existing
FDT_PROP_IMA_KEXEC_BUFFER property and also its corresponding memory
reservation, so that you avoid accumulating stale memory reservations
for non-existing IMA kexec buffers from previous kexecs.
That's good catch Thiago. Thanks for the feedback. I'll make this change
and update.
thanks,
-lakshmi
Re: [PATCH 12/14] x86: remove address space overrides using set_fs()
On Fri, Sep 04, 2020 at 03:55:10AM +0100, Al Viro wrote: > On Thu, Sep 03, 2020 at 04:22:40PM +0200, Christoph Hellwig wrote: > > > diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S > > index c8a85b512796e1..94f7be4971ed04 100644 > > --- a/arch/x86/lib/getuser.S > > +++ b/arch/x86/lib/getuser.S > > @@ -35,10 +35,19 @@ > > #include > > #include > > > > +#ifdef CONFIG_X86_5LEVEL > > +#define LOAD_TASK_SIZE_MINUS_N(n) \ > > + ALTERNATIVE "mov $((1 << 47) - 4096 - (n)),%rdx", \ > > + "mov $((1 << 56) - 4096 - (n)),%rdx", X86_FEATURE_LA57 > > +#else > > +#define LOAD_TASK_SIZE_MINUS_N(n) \ > > + mov $(TASK_SIZE_MAX - (n)),%_ASM_DX > > +#endif > > Wait a sec... how is that supposed to build with X86_5LEVEL? Do you mean > > #define LOAD_TASK_SIZE_MINUS_N(n) \ > ALTERNATIVE __stringify(mov $((1 << 47) - 4096 - (n)),%rdx), \ > __stringify(mov $((1 << 56) - 4096 - (n)),%rdx), > X86_FEATURE_LA57 > > there? Pushed out with the following folded in. diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S index 94f7be4971ed..2f052bc96866 100644 --- a/arch/x86/lib/getuser.S +++ b/arch/x86/lib/getuser.S @@ -37,8 +37,8 @@ #ifdef CONFIG_X86_5LEVEL #define LOAD_TASK_SIZE_MINUS_N(n) \ - ALTERNATIVE "mov $((1 << 47) - 4096 - (n)),%rdx", \ - "mov $((1 << 56) - 4096 - (n)),%rdx", X86_FEATURE_LA57 + ALTERNATIVE __stringify(mov $((1 << 47) - 4096 - (n)),%rdx), \ + __stringify(mov $((1 << 56) - 4096 - (n)),%rdx), X86_FEATURE_LA57 #else #define LOAD_TASK_SIZE_MINUS_N(n) \ mov $(TASK_SIZE_MAX - (n)),%_ASM_DX diff --git a/arch/x86/lib/putuser.S b/arch/x86/lib/putuser.S index 445374885153..358239d77dff 100644 --- a/arch/x86/lib/putuser.S +++ b/arch/x86/lib/putuser.S @@ -33,8 +33,8 @@ #ifdef CONFIG_X86_5LEVEL #define LOAD_TASK_SIZE_MINUS_N(n) \ - ALTERNATIVE "mov $((1 << 47) - 4096 - (n)),%rbx", \ - "mov $((1 << 56) - 4096 - (n)),%rbx", X86_FEATURE_LA57 + ALTERNATIVE __stringify(mov $((1 << 47) - 4096 - (n)),%rbx), \ + __stringify(mov $((1 << 56) - 4096 - (n)),%rbx), X86_FEATURE_LA57 #else #define LOAD_TASK_SIZE_MINUS_N(n) \ mov $(TASK_SIZE_MAX - (n)),%_ASM_BX
[PATCH] drm: xlnx: fix build warning & errors when DMADEVICES is not set
From: Randy Dunlap Fix kconfig warnings & build errors caused by DRM_ZYNQMP_DPSUB. Any driver that selects DMA_ENGINE should make sure that DMADEVICES is already enabled. As is, this causes build errors in many other drivers. See https://lore.kernel.org/lkml/202009020239.ouph82xc%25...@intel.com/ for the numerous build errors. WARNING: unmet direct dependencies detected for DMA_ENGINE Depends on [n]: DMADEVICES [=n] Selected by [y]: - DRM_ZYNQMP_DPSUB [=y] && HAS_IOMEM [=y] && (ARCH_ZYNQMP || COMPILE_TEST [=y]) && COMMON_CLK [=y] && DRM [=y] && OF [=y] Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Hyun Kwon Cc: Laurent Pinchart Cc: dri-de...@lists.freedesktop.org --- drivers/gpu/drm/xlnx/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20200903.orig/drivers/gpu/drm/xlnx/Kconfig +++ linux-next-20200903/drivers/gpu/drm/xlnx/Kconfig @@ -2,6 +2,7 @@ config DRM_ZYNQMP_DPSUB tristate "ZynqMP DisplayPort Controller Driver" depends on ARCH_ZYNQMP || COMPILE_TEST depends on COMMON_CLK && DRM && OF + depends on DMADEVICES select DMA_ENGINE select DRM_GEM_CMA_HELPER select DRM_KMS_CMA_HELPER
Re: [PATCH v2 07/17] virt: acrn: Introduce an ioctl to set vCPU registers state
Hi Greg,
On 9/3/2020 21:03, Greg Kroah-Hartman wrote:
> On Thu, Sep 03, 2020 at 08:41:51PM +0800, shuo.a@intel.com wrote:
>> From: Shuo Liu
>>
>> A virtual CPU of User VM has different context due to the different
>> registers state. ACRN userspace needs to set the virtual CPU
>> registers state (e.g. giving a initial registers state to a virtual
>> BSP of a User VM).
>>
>> HSM provides an ioctl ACRN_IOCTL_SET_VCPU_REGS to do the virtual CPU
>> registers state setting. The ioctl passes the registers state from ACRN
>> userspace to the hypervisor directly.
>>
>> Signed-off-by: Shuo Liu
>> Reviewed-by: Zhi Wang
>> Reviewed-by: Reinette Chatre
>> Cc: Zhi Wang
>> Cc: Zhenyu Wang
>> Cc: Yu Wang
>> Cc: Reinette Chatre
>> Cc: Greg Kroah-Hartman
>> ---
>> drivers/virt/acrn/hsm.c | 14 +++
>> drivers/virt/acrn/hypercall.h | 13 +++
>> include/uapi/linux/acrn.h | 71 +++
>> 3 files changed, 98 insertions(+)
>>
>> diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
>> index 6ec6aa9053d3..13df76d0206e 100644
>> --- a/drivers/virt/acrn/hsm.c
>> +++ b/drivers/virt/acrn/hsm.c
>> @@ -12,6 +12,7 @@
>> #define pr_fmt(fmt) "acrn: " fmt
>> #define dev_fmt(fmt) "acrn: " fmt
>>
>> +#include
>> #include
>> #include
>> #include
>> @@ -49,6 +50,7 @@ static long acrn_dev_ioctl(struct file *filp, unsigned int
>> cmd,
>> {
>> struct acrn_vm *vm = filp->private_data;
>> struct acrn_vm_creation *vm_param;
>> +struct acrn_vcpu_regs *cpu_regs;
>> int ret = 0;
>>
>> if (vm->vmid == ACRN_INVALID_VMID && cmd != ACRN_IOCTL_CREATE_VM) {
>> @@ -96,6 +98,18 @@ static long acrn_dev_ioctl(struct file *filp, unsigned
>> int cmd,
>> case ACRN_IOCTL_DESTROY_VM:
>> ret = acrn_vm_destroy(vm);
>> break;
>> +case ACRN_IOCTL_SET_VCPU_REGS:
>> +cpu_regs = memdup_user((void __user *)ioctl_param,
>> + sizeof(struct acrn_vcpu_regs));
>> +if (IS_ERR(cpu_regs))
>> +return PTR_ERR(cpu_regs);
>> +
>> +ret = hcall_set_vcpu_regs(vm->vmid, virt_to_phys(cpu_regs));
>
> No sanity checking of any arguments?
The HSM driver has limited VM status maintenance so it doesn't have full
ability to do the sanity checking.
>
> Wow, fuzzers are going to have a fun time with your hypervisor, good
> luck! :)
The hypervisor has some sanity checking. :)
Thanks
shuo
Re: [PATCH v5 0/5] cpufreq: improve frequency invariance support
On 03-09-20, 14:32, Ionela Voinescu wrote: > Hi Rafael, Viresh, > > Would it be okay for you to apply this series, as the majority of > changes are in cpufreq? For arch_topology and arm64 changes, they have > been reviewed and acked-by Catalin and Sudeep. > > Also, please let me know if I should send v6 with Sudeep's Reviewed-by/s > applied. No need to resend. Rafael will apply these with the tags. -- viresh
Re: [PATCH v2 06/17] virt: acrn: Introduce VM management interfaces
Hi Greg,
On 9/3/2020 21:02, Greg Kroah-Hartman wrote:
> On Thu, Sep 03, 2020 at 08:41:50PM +0800, shuo.a@intel.com wrote:
>> From: Shuo Liu
>>
>> The VM management interfaces expose several VM operations to ACRN
>> userspace via ioctls. For example, creating VM, starting VM, destroying
>> VM and so on.
>>
>> The ACRN Hypervisor needs to exchange data with the ACRN userspace
>> during the VM operations. HSM provides VM operation ioctls to the ACRN
>> userspace and communicates with the ACRN Hypervisor for VM operations
>> via hypercalls.
>>
>> HSM maintains a list of User VM. Each User VM will be bound to an
>> existing file descriptor of /dev/acrn_hsm. The User VM will be
>> destroyed when the file descriptor is closed.
>>
>> Signed-off-by: Shuo Liu
>> Reviewed-by: Zhi Wang
>> Reviewed-by: Reinette Chatre
>> Cc: Zhi Wang
>> Cc: Zhenyu Wang
>> Cc: Yu Wang
>> Cc: Reinette Chatre
>> Cc: Greg Kroah-Hartman
>> ---
>> drivers/virt/acrn/Makefile| 2 +-
>> drivers/virt/acrn/acrn_drv.h | 21 +-
>> drivers/virt/acrn/hsm.c | 62 +++-
>> drivers/virt/acrn/hypercall.h | 78 +++
>> drivers/virt/acrn/vm.c| 67 ++
>> include/uapi/linux/acrn.h | 39 ++
>> 6 files changed, 266 insertions(+), 3 deletions(-)
>> create mode 100644 drivers/virt/acrn/hypercall.h
>> create mode 100644 drivers/virt/acrn/vm.c
>>
>> diff --git a/drivers/virt/acrn/Makefile b/drivers/virt/acrn/Makefile
>> index 6920ed798aaf..cf8b4ed5e74e 100644
>> --- a/drivers/virt/acrn/Makefile
>> +++ b/drivers/virt/acrn/Makefile
>> @@ -1,3 +1,3 @@
>> # SPDX-License-Identifier: GPL-2.0
>> obj-$(CONFIG_ACRN_HSM) := acrn.o
>> -acrn-y := hsm.o
>> +acrn-y := hsm.o vm.o
>> diff --git a/drivers/virt/acrn/acrn_drv.h b/drivers/virt/acrn/acrn_drv.h
>> index 0b8e4fdc168a..043ae6840995 100644
>> --- a/drivers/virt/acrn/acrn_drv.h
>> +++ b/drivers/virt/acrn/acrn_drv.h
>> @@ -4,16 +4,35 @@
>> #define __ACRN_HSM_DRV_H
>>
>> #include
>> +#include
>> #include
>>
>> +#include "hypercall.h"
>> +
>> #define ACRN_INVALID_VMID (0xU)
>>
>> +#define ACRN_VM_FLAG_DESTROYED 0U
>> +extern struct list_head acrn_vm_list;
>> +extern rwlock_t acrn_vm_list_lock;
>> /**
>> * struct acrn_vm - Properties of ACRN User VM.
>> + * @dev:The struct device this VM belongs to
>> + * @list: Entry within global list of all VMs
>> * @vmid: User VM ID
>> + * @vcpu_num: Number of virtual CPUs in the VM
>> + * @flags: Flags (ACRN_VM_FLAG_*) of the VM. This is VM flag management
>> + * in HSM which is different from the &acrn_vm_creation.vm_flag.
>> */
>> struct acrn_vm {
>> -u16 vmid;
>> +struct device *dev;
>> +struct list_headlist;
>> +u16 vmid;
>> +int vcpu_num;
>> +unsigned long flags;
>> };
>>
>> +struct acrn_vm *acrn_vm_create(struct acrn_vm *vm,
>> + struct acrn_vm_creation *vm_param);
>> +int acrn_vm_destroy(struct acrn_vm *vm);
>> +
>> #endif /* __ACRN_HSM_DRV_H */
>> diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
>> index 549c7f8d6b5f..6ec6aa9053d3 100644
>> --- a/drivers/virt/acrn/hsm.c
>> +++ b/drivers/virt/acrn/hsm.c
>> @@ -10,6 +10,7 @@
>> */
>>
>> #define pr_fmt(fmt) "acrn: " fmt
>> +#define dev_fmt(fmt) "acrn: " fmt
>
> This should not be needed anywhere, what is wrong with the default
> prefix given to you by the dev_*() calls?
OK, the default prefix is enough. I will remove this define.
>
>>
>> #include
>> #include
>> @@ -21,6 +22,8 @@
>>
>> #include "acrn_drv.h"
>>
>> +static struct device *dev;
>
> Um, why? This feels really odd...
Sorry, my foolish. :)
Will use 'static struct miscdevice acrn_dev' directly.
>> +
>> /*
>> * When /dev/acrn_hsm is opened, a 'struct acrn_vm' object is created to
>> * represent a VM instance and continues to be associated with the opened
>> file
>> @@ -36,6 +39,7 @@ static int acrn_dev_open(struct inode *inode, struct file
>> *filp)
>> return -ENOMEM;
>>
>> vm->vmid = ACRN_INVALID_VMID;
>> +vm->dev = dev;
>> filp->private_data = vm;
>> return 0;
>> }
>> @@ -43,13 +47,68 @@ static int acrn_dev_open(struct inode *inode, struct
>> file *filp)
>> static long acrn_dev_ioctl(struct file *filp, unsigned int cmd,
>> unsigned long ioctl_param)
>> {
>> -return 0;
>> +struct acrn_vm *vm = filp->private_data;
>> +struct acrn_vm_creation *vm_param;
>> +int ret = 0;
>> +
>> +if (vm->vmid == ACRN_INVALID_VMID && cmd != ACRN_IOCTL_CREATE_VM) {
>> +dev_err(dev, "ioctl 0x%x: Invalid VM state!\n", cmd);
>> +return -EFAULT;
>> +}
>> +
>> +switch (cmd) {
>> +case ACRN_IOCTL_CREATE_VM:
>> +vm_param = memdup_user((void __user *)ioctl_param,
>> +
Re: [PATCH] Documentation: kunit: Add naming guidelines
On Tue, Sep 1, 2020 at 8:23 PM Marco Elver wrote:
>
> On Tue, 1 Sep 2020 at 07:31, David Gow wrote:
> > On Tue, Sep 1, 2020 at 7:47 AM Kees Cook wrote:
> > > On Fri, Aug 28, 2020 at 12:17:05AM +0800, David Gow wrote:
> > > > On Thu, Aug 27, 2020 at 9:14 PM Marco Elver wrote:
> [...]
> >
> > I guess there are two audiences to cater for:
> > 1. Test authors, who may wish to have both unit-style and
> > integration-style tests, and want to distinguish them. They probably
> > have the best idea of where the line should be drawn for their
> > subsystems, and may have some existing style/nomenclature.
> > 2. People running "all tests", who want to broadly understand how the
> > whole suite of tests will behave (e.g., how long they'll take to run,
> > are they possibly nondeterministic, are there weird hardware/software
> > dependencies). This is where some more standardisation probably makes
> > sense.
> >
> > I'm not 100% the file/module name is the best place to make these
> > distinctions (given that it's the Kconfig entries that are at least
> > our current way of finding and running tests).
>
> I agree -- as you note, it's very hard to make this distinction. Since
> we're still discussing the best convention to use, one point I want to
> make is that encoding a dependency ("kunit") or type of test (unit,
> integration, etc.) in the name hurts scalability of our workflows.
> Because as soon as the dependency changes, or the type, any
> rename/move is very destructive to our workflow, because it
> immediately causes conflict with any in-flight patches. Whereas
> encoding this either in a comment, or via Kconfig would be less
> destructive.
>
This is a good point -- renaming files is definitely a pain. It's
obviously my hope that KUnit sticks around long enough that it's not
being added/removed as a dependency too often, particularly for the
unit tests, so "_kunit" as a name doesn't worry me that much
otherwise.
> > An off-the-wall idea
> > would be to have a flags field in the test suite structure to note
> > things like "large/long-running test" or "nondeterministic", and have
> > either a KUnit option to bypass them, note them in the output, or even
> > something terrifying like parsing it out of a compiled module.
>
> As a side-node, in the other very large codebase I have worked on, we
> have such markers ("size = ..."):
> https://docs.bazel.build/versions/master/be/common-definitions.html#common-attributes-tests
> However, there is also incentive to get this distinction right,
> because the test will be killed by the CI system if it exceeds the
> specified size (ran too long, OOM). Not sure we have this incentive
> yet.
>
KUnit does have test timeouts, but they're generous (30 seconds), and
not configurable per-test or per-suite. Fixing that's probably a
separate feature request which, as you point out, probably isn't worth
doing until we're actually seeing a problem. Maybe it's something
that'll become more apparent as KUnit is integrated into KernelCI and
the like, so we see more (and more varied) test runs/configs.
> [...]
> > > > I guess the interesting thing to note is that we've to date not really
> > > > made a distinction between KUnit the framework and the suite of all
> > > > KUnit tests. Maybe having a separate file/module naming scheme could
> > > > be a way of making that distinction, though it'd really only appear
> > > > when loading tests as modules -- there'd be no indication in e.g.,
> > > > suite names or test results. The more obvious solution to me (at
> > > > least, based on the current proposal) would be to have "integration"
> > > > or similar be part of the suite name (and hence the filename, so
> > > > _integration_kunit.c or similar), though even I admit that that's much
> > > > uglier. Maybe the idea of having the subsystem/suite distinction be
> > > > represented in the code could pave the way to having different suites
> > > > support different suffixes like that.
> > >
> > > Heh, yeah, let's not call them "_integration_kunit.c" ;) _behavior.c?
> > > _integration.c?
>
> If possible, I'd still prefer generic filenames, because it's easy to
> get wrong as we noted. Changes will cause conflicts.
>
> > I think we'd really like something that says more strongly that this
> > is a test (which is I suspect one of the reasons why _kunit.c has its
> > detractors: it doesn't have the word "test" in it).
>
> ^ Agreed.
>
I'm not personally convinced that "kunit" isn't something people could
associate with tests, particularly as it becomes more popular, but if
people really dislike it, we could have"_unittest.c" or similar.
There's a balancing act between being generic (and not distinguishing
between unit/integration/etc tests) and being consistent or avoiding
renames. Take the case where there's a set of unit tests in a
"-test.c" file, and an integration test is written as well: it
probably should go in a speparate file, so now you'd either have a
"-test.c" and a separate "-int
drivers/gpu/drm/msm/msm_drv.c:123:15: warning: no previous prototype for '_msm_ioremap'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 59126901f200f5fc907153468b03c64e0081b6e6
commit: 62a35e81c2c1bae04fdefde56f2a92dd3e56164d drm/msm: Quiet error during
failure in optional resource mappings.
date: 5 weeks ago
config: arm64-randconfig-r013-20200904 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 62a35e81c2c1bae04fdefde56f2a92dd3e56164d
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/msm/msm_drv.c:123:15: warning: no previous prototype for
>> '_msm_ioremap' [-Wmissing-prototypes]
123 | void __iomem *_msm_ioremap(struct platform_device *pdev, const char
*name,
| ^~~~
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62a35e81c2c1bae04fdefde56f2a92dd3e56164d
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 62a35e81c2c1bae04fdefde56f2a92dd3e56164d
vim +/_msm_ioremap +123 drivers/gpu/drm/msm/msm_drv.c
122
> 123 void __iomem *_msm_ioremap(struct platform_device *pdev, const char
> *name,
124 const char *dbgname, bool quiet)
125 {
126 struct resource *res;
127 unsigned long size;
128 void __iomem *ptr;
129
130 if (name)
131 res = platform_get_resource_byname(pdev,
IORESOURCE_MEM, name);
132 else
133 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
134
135 if (!res) {
136 if (!quiet)
137 DRM_DEV_ERROR(&pdev->dev, "failed to get memory
resource: %s\n", name);
138 return ERR_PTR(-EINVAL);
139 }
140
141 size = resource_size(res);
142
143 ptr = devm_ioremap(&pdev->dev, res->start, size);
144 if (!ptr) {
145 if (!quiet)
146 DRM_DEV_ERROR(&pdev->dev, "failed to ioremap:
%s\n", name);
147 return ERR_PTR(-ENOMEM);
148 }
149
150 if (reglog)
151 printk(KERN_DEBUG "IO:region %s %p %08lx\n", dbgname,
ptr, size);
152
153 return ptr;
154 }
155
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v11 3/5] arm64: kdump: reimplement crashkernel=X
On 09/04/20 at 12:02pm, chenzhou wrote:
>
>
> On 2020/9/4 11:10, Dave Young wrote:
> > On 09/04/20 at 11:04am, Dave Young wrote:
> >> On 09/03/20 at 07:26pm, chenzhou wrote:
> >>> Hi Catalin,
> >>>
> >>>
> >>> On 2020/9/3 1:09, Catalin Marinas wrote:
> On Sat, Aug 01, 2020 at 09:08:54PM +0800, Chen Zhou wrote:
> > There are following issues in arm64 kdump:
> > 1. We use crashkernel=X to reserve crashkernel below 4G, which
> > will fail when there is no enough low memory.
> > 2. If reserving crashkernel above 4G, in this case, crash dump
> > kernel will boot failure because there is no low memory available
> > for allocation.
> > 3. Since commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and
> > ZONE_DMA32"),
> > if the memory reserved for crash dump kernel falled in ZONE_DMA32,
> > the devices in crash dump kernel need to use ZONE_DMA will alloc
> > fail.
> >
> > To solve these issues, change the behavior of crashkernel=X.
> > crashkernel=X tries low allocation in ZONE_DMA, and fall back to
> > high allocation if it fails.
> >
> > If requized size X is too large and leads to very little free memory
> > in ZONE_DMA after low allocation, the system may not work normally.
> > So add a threshold and go for high allocation directly if the required
> > size is too large. The value of threshold is set as the half of
> > the low memory.
> >
> > If crash_base is outside ZONE_DMA, try to allocate at least 256M in
> > ZONE_DMA automatically. "crashkernel=Y,low" can be used to allocate
> > specified size low memory.
> Except for the threshold to keep zone ZONE_DMA memory,
> reserve_crashkernel() looks very close to the x86 version. Shall we try
> to make this generic as well? In the first instance, you could avoid the
> threshold check if it takes an explicit ",high" option.
> >>> Ok, i will try to do this.
> >>>
> >>> I look into the function reserve_crashkernel() of x86 and found the start
> >>> address is
> >>> CRASH_ALIGN in function memblock_find_in_range(), which is different with
> >>> arm64.
> >>>
> >>> I don't figure out why is CRASH_ALIGN in x86, is there any specific
> >>> reason?
> >> Hmm, took another look at the option CONFIG_PHYSICAL_ALIGN
> >> config PHYSICAL_ALIGN
> >> hex "Alignment value to which kernel should be aligned"
> >> default "0x20"
> >> range 0x2000 0x100 if X86_32
> >> range 0x20 0x100 if X86_64
> >>
> >> According to above, I think the 16M should come from the largest value
> >> But the default value is 2M, with smaller value reservation can have
> >> more chance to succeed.
> >>
> >> It seems we still need arch specific CRASH_ALIGN, but the initial
> >> version you added the #ifdef for different arches, can you move the
> >> macro to arch specific headers?
> > And just keep the x86 align value as is, I can try to change the x86
> > value later to CONFIG_PHYSICAL_ALIGN, in this way this series can be
> > cleaner.
> Ok. I have no question about the value of macro CRASH_ALIGN,
> instead the lower bound of memblock_find_in_range().
>
> For x86, in reserve_crashkernel()，restrict the lower bound of the range to
> CRASH_ALIGN,
> ...
> crash_base = memblock_find_in_range(CRASH_ALIGN,
> CRASH_ADDR_LOW_MAX,
> crash_size, CRASH_ALIGN);
> ...
>
> in reserve_crashkernel_low()，with no this restriction.
> ...
> low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
> ...
>
> How about all making memblock_find_in_range() search from the start of memory?
> If it is ok, i will do like this in the generic version.
I feel starting with CRASH_ALIGN sounds better, can you just search from
CRASH_ALIGN in generic version?
Thanks
Dave
Re: [PATCH] mm: workingset: ignore slab memory size when calculating shadows pressure
On Thu, 3 Sep 2020 16:00:55 -0700 Roman Gushchin wrote:
> In the memcg case count_shadow_nodes() sums the number of pages in lru
> lists and the amount of slab memory (reclaimable and non-reclaimable)
> as a baseline for the allowed number of shadow entries.
>
> It seems to be a good analogy for the !memcg case, where
> node_present_pages() is used. However, it's not quite true, as there
> two problems:
>
> 1) Due to slab reparenting introduced by commit fb2f2b0adb98 ("mm:
> memcg/slab: reparent memcg kmem_caches on cgroup removal") local
> per-lruvec slab counters might be inaccurate on non-leaf levels.
> It's the only place where local slab counters are used.
>
> 2) Shadow nodes by themselves are backed by slabs. So there is a loop
> dependency: the more shadow entries are there, the less pressure the
> kernel applies to reclaim them.
>
> Fortunately, there is a simple way to solve both problems: slab
> counters shouldn't be taken into the account by count_shadow_nodes().
>
> ...
>
> --- a/mm/workingset.c
> +++ b/mm/workingset.c
> @@ -495,10 +495,6 @@ static unsigned long count_shadow_nodes(struct shrinker
> *shrinker,
> for (pages = 0, i = 0; i < NR_LRU_LISTS; i++)
> pages += lruvec_page_state_local(lruvec,
>NR_LRU_BASE + i);
> - pages += lruvec_page_state_local(
> - lruvec, NR_SLAB_RECLAIMABLE_B) >> PAGE_SHIFT;
> - pages += lruvec_page_state_local(
> - lruvec, NR_SLAB_UNRECLAIMABLE_B) >> PAGE_SHIFT;
> } else
> #endif
> pages = node_present_pages(sc->nid);
Did this have any observable runtime effects?
Re: [PATCH] i2c: virtio: add a virtio i2c frontend driver
On 2020/9/3 下午1:34, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
This driver communicates with the backend driver through a
virtio I2C message structure which includes following parts:
- Header: i2c_msg addr, flags, len.
- Data buffer: the pointer to the i2c msg data.
- Status: the processing result from the backend.
People may implement different backend drivers to emulate
different controllers according to their needs. A backend
example can be found in the device model of the open source
project ACRN. For more information, please refer to
https://projectacrn.org.
The virtio device ID 34 is used for this I2C adpter since IDs
before 34 have been reserved by other virtio devices.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
Reviewed-by: Shuo Liu
Reviewed-by: Andy Shevchenko
---
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3 +
drivers/i2c/busses/i2c-virtio.c | 276
include/uapi/linux/virtio_ids.h | 1 +
4 files changed, 291 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-virtio.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 293e7a0..70c8e30 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -21,6 +21,17 @@ config I2C_ALI1535
This driver can also be built as a module. If so, the module
will be called i2c-ali1535.
+config I2C_VIRTIO
+ tristate "Virtio I2C Adapter"
+ depends on VIRTIO
I guess it should depend on some I2C module here.
+ help
+ If you say yes to this option, support will be included for the virtio
+ i2c adapter driver. The hardware can be emulated by any device model
+ software according to the virtio protocol.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-virtio.
+
config I2C_ALI1563
tristate "ALI 1563"
depends on PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 19aff0e..821acfa 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -6,6 +6,9 @@
# ACPI drivers
obj-$(CONFIG_I2C_SCMI)+= i2c-scmi.o
+# VIRTIO I2C host controller driver
+obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
+
# PC SMBus host controller drivers
obj-$(CONFIG_I2C_ALI1535) += i2c-ali1535.o
obj-$(CONFIG_I2C_ALI1563) += i2c-ali1563.o
diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
new file mode 100644
index 000..47f9fd1
--- /dev/null
+++ b/drivers/i2c/busses/i2c-virtio.c
@@ -0,0 +1,276 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Virtio I2C Bus Driver
+ *
+ * Copyright (c) 2020 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define VIRTIO_I2C_MSG_OK 0
+#define VIRTIO_I2C_MSG_ERR 1
+
+/**
+ * struct virtio_i2c_hdr - the virtio I2C message header structure
+ * @addr: i2c_msg addr, the slave address
+ * @flags: i2c_msg flags
+ * @len: i2c_msg len
+ */
+struct virtio_i2c_hdr {
+ __virtio16 addr;
+ __virtio16 flags;
+ __virtio16 len;
+} __packed;
+
+/**
+ * struct virtio_i2c_msg - the virtio I2C message structure
+ * @hdr: the virtio I2C message header
+ * @buf: virtio I2C message data buffer
+ * @status: the processing result from the backend
+ */
+struct virtio_i2c_msg {
+ struct virtio_i2c_hdr hdr;
+ char *buf;
+ u8 status;
Any reason for separating status out of virtio_i2c_hdr?
+};
+
+/**
+ * struct virtio_i2c - virtio I2C data
+ * @vdev: virtio device for this controller
+ * @completion: completion of virtio I2C message
+ * @adap: I2C adapter for this controller
+ * @i2c_lock: lock for virtqueue processing
+ * @vq: the virtio virtqueue for communication
+ */
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion;
+ struct i2c_adapter adap;
+ struct mutex i2c_lock;
+ struct virtqueue *vq;
+};
+
+static void virtio_i2c_msg_done(struct virtqueue *vq)
+{
+ struct virtio_i2c *vi = vq->vdev->priv;
+
+ complete(&vi->completion);
+}
+
+static int virtio_i2c_add_msg(struct virtqueue *vq,
+ struct virtio_i2c_msg *vmsg,
+ struct i2c_msg *msg)
+{
+ struct scatterlist *sgs[3], hdr, bout, bin, status;
+ int outcnt = 0, incnt = 0;
+
+ if (!msg->len)
+ return -EINVAL;
+
+ vmsg->hdr.addr = msg->addr;
+ vmsg->hdr.flags = msg->flags;
+ vmsg->hdr.len = msg->len;
Missing endian conversion?
+
+ vmsg->buf = kzalloc(vmsg->hdr.len, GFP_KERNEL);
+ if (!v
Re: [PATCH tip/core/rcu 05/13] rcu: Always set .need_qs from __rcu_read_lock() for strict GPs
Hi Paul,
On Mon, Aug 31, 2020 at 11:11:12AM -0700, paul...@kernel.org wrote:
> From: "Paul E. McKenney"
>
> The ->rcu_read_unlock_special.b.need_qs field in the task_struct
> structure indicates that the RCU core needs a quiscent state from the
> corresponding task. The __rcu_read_unlock() function checks this (via
> an eventual call to rcu_preempt_deferred_qs_irqrestore()), and if set
> reports a quiscent state immediately upon exit from the outermost RCU
> read-side critical section.
>
> Currently, this flag is only set when the scheduling-clock interrupt
> decides that the current RCU grace period is too old, as in about
> one full second too old. But if the kernel has been built with
> CONFIG_RCU_STRICT_GRACE_PERIOD=y, we clearly do not want to wait that
> long. This commit therefore sets the .need_qs field immediately at the
> start of the RCU read-side critical section from within __rcu_read_lock()
> in order to unconditionally enlist help from __rcu_read_unlock().
>
So why not make rcu_preempt_deferred_qs_irqrestore() always treat
need_qs is true if CONFIG_RCU_STRICT_GRACE_PERIOD = y? IOW:
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 982fc5be5269..2a9f31545453 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -449,6 +449,8 @@ rcu_preempt_deferred_qs_irqrestore(struct task_struct *t,
unsigned long flags)
* t->rcu_read_unlock_special cannot change.
*/
special = t->rcu_read_unlock_special;
+ if (IS_ENABLED(CONFIG_RCU_STRICT_GRACE_PERIOD) && rcu_state.gp_kthread)
+ special.b.need_qs = true;
rdp = this_cpu_ptr(&rcu_data);
if (!special.s && !rdp->exp_deferred_qs) {
local_irq_restore(flags);
, and in this way, you can save one store for each rcu_read_lock() ;-)
Regards,
Boqun
> But note the additional check for rcu_state.gp_kthread, which prevents
> attempts to awaken RCU's grace-period kthread during early boot before
> there is a scheduler. Leaving off this check results in early boot hangs.
> So early that there is no console output. Thus, this additional check
> fails until such time as RCU's grace-period kthread has been created,
> avoiding these empty-console hangs.
>
> Reported-by Jann Horn
> Signed-off-by: Paul E. McKenney
> ---
> kernel/rcu/tree_plugin.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 44cf77d..668bbd2 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -376,6 +376,8 @@ void __rcu_read_lock(void)
> rcu_preempt_read_enter();
> if (IS_ENABLED(CONFIG_PROVE_LOCKING))
> WARN_ON_ONCE(rcu_preempt_depth() > RCU_NEST_PMAX);
> + if (IS_ENABLED(CONFIG_RCU_STRICT_GRACE_PERIOD) && rcu_state.gp_kthread)
> + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true);
> barrier(); /* critical section after entry code. */
> }
> EXPORT_SYMBOL_GPL(__rcu_read_lock);
> --
> 2.9.5
>
Re: [PATCH v11 3/5] arm64: kdump: reimplement crashkernel=X
On 2020/9/4 11:10, Dave Young wrote:
> On 09/04/20 at 11:04am, Dave Young wrote:
>> On 09/03/20 at 07:26pm, chenzhou wrote:
>>> Hi Catalin,
>>>
>>>
>>> On 2020/9/3 1:09, Catalin Marinas wrote:
On Sat, Aug 01, 2020 at 09:08:54PM +0800, Chen Zhou wrote:
> There are following issues in arm64 kdump:
> 1. We use crashkernel=X to reserve crashkernel below 4G, which
> will fail when there is no enough low memory.
> 2. If reserving crashkernel above 4G, in this case, crash dump
> kernel will boot failure because there is no low memory available
> for allocation.
> 3. Since commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32"),
> if the memory reserved for crash dump kernel falled in ZONE_DMA32,
> the devices in crash dump kernel need to use ZONE_DMA will alloc
> fail.
>
> To solve these issues, change the behavior of crashkernel=X.
> crashkernel=X tries low allocation in ZONE_DMA, and fall back to
> high allocation if it fails.
>
> If requized size X is too large and leads to very little free memory
> in ZONE_DMA after low allocation, the system may not work normally.
> So add a threshold and go for high allocation directly if the required
> size is too large. The value of threshold is set as the half of
> the low memory.
>
> If crash_base is outside ZONE_DMA, try to allocate at least 256M in
> ZONE_DMA automatically. "crashkernel=Y,low" can be used to allocate
> specified size low memory.
Except for the threshold to keep zone ZONE_DMA memory,
reserve_crashkernel() looks very close to the x86 version. Shall we try
to make this generic as well? In the first instance, you could avoid the
threshold check if it takes an explicit ",high" option.
>>> Ok, i will try to do this.
>>>
>>> I look into the function reserve_crashkernel() of x86 and found the start
>>> address is
>>> CRASH_ALIGN in function memblock_find_in_range(), which is different with
>>> arm64.
>>>
>>> I don't figure out why is CRASH_ALIGN in x86, is there any specific reason?
>> Hmm, took another look at the option CONFIG_PHYSICAL_ALIGN
>> config PHYSICAL_ALIGN
>> hex "Alignment value to which kernel should be aligned"
>> default "0x20"
>> range 0x2000 0x100 if X86_32
>> range 0x20 0x100 if X86_64
>>
>> According to above, I think the 16M should come from the largest value
>> But the default value is 2M, with smaller value reservation can have
>> more chance to succeed.
>>
>> It seems we still need arch specific CRASH_ALIGN, but the initial
>> version you added the #ifdef for different arches, can you move the
>> macro to arch specific headers?
> And just keep the x86 align value as is, I can try to change the x86
> value later to CONFIG_PHYSICAL_ALIGN, in this way this series can be
> cleaner.
Ok. I have no question about the value of macro CRASH_ALIGN,
instead the lower bound of memblock_find_in_range().
For x86, in reserve_crashkernel()，restrict the lower bound of the range to
CRASH_ALIGN,
...
crash_base = memblock_find_in_range(CRASH_ALIGN,
CRASH_ADDR_LOW_MAX,
crash_size, CRASH_ALIGN);
...
in reserve_crashkernel_low()，with no this restriction.
...
low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
...
How about all making memblock_find_in_range() search from the start of memory?
If it is ok, i will do like this in the generic version.
Thanks,
Chen Zhou
>
>> Thanks
>> Dave
>
> .
>
Re: [PATCH] perf metric: Fix some memory leaks
On Thu, Sep 3, 2020 at 8:21 PM Namhyung Kim wrote:
>
> I found some memory leaks while reading the metric code. Some are
> real and others only occur in the error path.
Thanks Namhyung! Is it possible to get test coverage?
Ian
> Cc: Kajol Jain
> Cc: John Garry
> Cc: Ian Rogers
> Fixes: 9afe5658a6fa8 ("perf tools: Release metric_events rblist")
> Fixes: 4ea2896715e67 ("perf metric: Collect referenced metrics in struct
> metric_expr")
> Fixes: 71b0acce78d12 ("perf list: Add metric groups to perf list")
> Fixes: b18f3e365019d ("perf stat: Support JSON metrics in perf stat")
> Signed-off-by: Namhyung Kim
> ---
> I'm not sure it'd better have them together or split each fix as
> they came from different commits. Please let me know if you prefer
> split.
>
> tools/perf/util/metricgroup.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 8831b964288f..7e31c4578ce8 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -85,6 +85,7 @@ static void metric_event_delete(struct rblist *rblist
> __maybe_unused,
>
> list_for_each_entry_safe(expr, tmp, &me->head, nd) {
> free(expr->metric_refs);
> + free(expr->metric_events);
> free(expr);
> }
>
> @@ -316,6 +317,7 @@ static int metricgroup__setup_events(struct list_head
> *groups,
> if (!metric_refs) {
> ret = -ENOMEM;
> free(metric_events);
> + free(expr);
> break;
> }
>
> @@ -530,6 +532,9 @@ void metricgroup__print(bool metrics, bool metricgroups,
> char *filter,
> continue;
> strlist__add(me->metrics, s);
> }
> +
> + if (!raw)
> + free(s);
> }
> free(omg);
> }
> @@ -1048,11 +1053,11 @@ static int parse_groups(struct evlist *perf_evlist,
> const char *str,
> parse_events_print_error(&parse_error, extra_events.buf);
> goto out;
> }
> - strbuf_release(&extra_events);
> ret = metricgroup__setup_events(&metric_list, metric_no_merge,
> perf_evlist, metric_events);
> out:
> metricgroup__free_metrics(&metric_list);
> + strbuf_release(&extra_events);
> return ret;
> }
>
> --
> 2.28.0.526.ge36021eeef-goog
>
Re: [PATCH net-next] net: dsa: bcm_sf2: Ensure that MDIO diversion is used
On 9/3/2020 3:03 PM, Andrew Lunn wrote: The firmware provides the Device Tree but here is the relevant section for you pasted below. The problematic device is a particular revision of the silicon (D0) which got later fixed (E0) however the Device Tree was created after the fixed platform, not the problematic one. Both revisions of the silicon are in production. There should have been an internal MDIO bus created for that chip revision such that we could have correctly parented phy@0 (bcm53125 below) as child node of the internal MDIO bus, but you have to realize that this was done back in 2014 when DSA was barely revived as an active subsystem. The BCM53125 node should have have been converted to an actual switch node at some point, I use a mdio_boardinfo overlay downstream to support the switch as a proper b53/DSA switch, anyway. I was expecting something like that. I think this patch needs a comment in the code explaining it is a workaround for a DT blob which cannot be changed. Maybe also make it conditional on the board compatible string? It is already targeted at the Broadcom pseudo PHY address (30) which is the one that needs diversion, I will update the patch description accordingly though. -- Florian
Re: [PATCH] ext4: flag as supporting buffered async reads
Hi Jens, Sorry, the past few months have been *crazy* insane. Between Linux Plumbers Conference organizing, having to deal with some interns at $WORK, performance reviews, etc.., etc., it's been a perfect storm. As a result, I was late getting the primary ext4 pull request to Linus, and he's already yelled at me for a late pull request. As a result, I'm being super paranoid about asking Linus for anything, even a one-time change, if it's not a bug fix. And what you are asking for isn't a bug fix, but enabling a new feature. Worse, right now, -rc1 and -rc2 is causing random crashes in my gce-xfstests framework. Sometimes it happens before we've run even a single xfstests; sometimes it happens after we have successfully completed all of the tests, and we're doing a shutdown of the VM under test. Other times it happens in the middle of a test run. Given that I'm seeing this at -rc1, which is before my late ext4 pull request to Linus, it's probably not an ext4 related bug. But it also means that I'm partially blind in terms of my kernel testing at the moment. So I can't even tell Linus that I've run lots of tests and I'm 100% confident your one-line change is 100% safe. Next week after Labor Day, I should be completely done with the performance review writeups that are on my plate, and I will hopefully have a bit more time to try to debug these mysterious failures. Or maybe someone else will be able to figure out what the heck is going wrong, and perhaps -rc3 will make all of these failures go away. I'm sorry your frustrated; I'm frustrated too! But until I can find the time to do a full bisect (v5.8 works just fine. v5.9-rc1 is flakey as hell when booting my test config in a GCE VM), I'm not in a position to send anything to Linus. Sorry, - Ted [ 3326.130032] BUG: unable to handle page fault for address: 949e7c958e3f [ 3326.137056] #PF: supervisor write access in kernel mode [ 3326.142497] #PF: error_code(0x0002) - not-present page [ 3326.147776] PGD 23fe01067 P4D 23fe01067 PUD 0 [ 3326.154384] Oops: 0002 [#1] SMP PTI [ 3326.157995] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.9.0-rc2-xfstests #1886 [ 3326.165337] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ 3326.174695] RIP: 0010:free_block+0x14b/0x260 [ 3326.180083] Code: af f1 0f b6 4d 1c 48 c1 ee 20 29 f0 d3 e8 0f b6 4d 1d 01 f0 49 8b 75 20 d3 e8 8d 4f ff 48 85 f6 41 89 4d 30 0f 84 f8 00 00 00 <88> 04 0e 41 8b 45 30 85 c0 0f 84 f9 fe ff ff 4d 8b 67 50 49 8d 57 [ 3326.199667] RSP: 0018:b11c80003ab8 EFLAGS: 00010082 [ 3326.205015] RAX: 0027 RBX: d11c7fa007b0 RCX: [ 3326.212282] RDX: fab945f25608 RSI: 949d7c958e40 RDI: [ 3326.219537] RBP: 949dd8041180 R08: fab9458bdf88 R09: 000c201d [ 3326.226791] R10: R11: 0008 R12: 949d7c9589c0 [ 3326.234151] R13: fab945f25600 R14: fab945f25608 R15: 949dd8042240 [ 3326.241512] FS: () GS:949dd900() knlGS: [ 3326.249725] CS: 0010 DS: ES: CR0: 80050033 [ 3326.255590] CR2: 949e7c958e3f CR3: 0001cf5b4003 CR4: 003706f0 [ 3326.262863] DR0: DR1: DR2: [ 3326.270214] DR3: DR6: fffe0ff0 DR7: 0400 [ 3326.277481] Call Trace: [ 3326.280046] [ 3326.282182] cache_flusharray+0x90/0x110 [ 3326.286239] ___cache_free+0x2e0/0x390 [ 3326.290130] kfree+0xc9/0x1d0 [ 3326.293222] kmem_freepages+0xa0/0xf0 [ 3326.297014] slabs_destroy+0x8e/0xd0 [ 3326.300717] cache_flusharray+0xa5/0x110 [ 3326.304761] ___cache_free+0x2e0/0x390 [ 3326.308634] kfree+0xc9/0x1d0 [ 3326.311722] kmem_freepages+0xa0/0xf0 [ 3326.315508] slabs_destroy+0x8e/0xd0 [ 3326.319235] cache_flusharray+0xa5/0x110 [ 3326.323305] ___cache_free+0x2e0/0x390 [ 3326.328915] kfree+0xc9/0x1d0 [ 3326.332028] kmem_freepages+0xa0/0xf0 [ 3326.336531] slabs_destroy+0x8e/0xd0 [ 3326.340251] cache_flusharray+0xa5/0x110 [ 3326.344318] ___cache_free+0x2e0/0x390 [ 3326.348209] ? rcu_do_batch+0x14e/0x780 [ 3326.352167] kmem_cache_free.part.0+0x34/0x110 [ 3326.356766] rcu_do_batch+0x19e/0x780 [ 3326.360569] rcu_core+0xef/0x190 [ 3326.363920] __do_softirq+0xc9/0x425 [ 3326.367644] asm_call_on_stack+0x12/0x20 [ 3326.371685] [ 3326.373906] do_softirq_own_stack+0x4e/0x60 [ 3326.378583] irq_exit_rcu+0x96/0xd0 [ 3326.382198] sysvec_apic_timer_interrupt+0x43/0x90 [ 3326.387129] asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 3326.392405] RIP: 0010:acpi_safe_halt+0x29/0x30 [ 3326.397056] Code: cc 0f 1f 44 00 00 65 48 8b 04 25 00 6e 01 00 48 8b 00 a8 08 74 01 c3 e8 25 96 5c ff e9 07 00 00 00 0f 00 2d b3 80 4f 00 fb f4 e9 e1 97 5c ff cc 0f 1f 44 00 00 41 56 49 89 f6 41 55 41 89 d5 [ 3326.415945] RSP: 0018:ade03e20 EFLAGS: 0202 [ 3326.421293] RAX: 0199dedf
Re: [PATCH v2 01/11] usb: gadget: bdc: fix improper SPDX comment style for header file
On 9/3/2020 8:17 PM, Chunfeng Yun wrote: Hi Florian, On Thu, 2020-08-20 at 19:30 +0800, Chunfeng Yun wrote: For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used). Cc: Florian Fainelli Signed-off-by: Chunfeng Yun --- [snip] Would you please take a look at this series? I'll drop the patches that not fine with you. It all looks good to me, thanks and sorry for not responding earlier. -- Florian
Re: [PATCH v2 11/11] usb: gadget: bdc: fix checkpatch.pl repeated word warning
On 8/20/2020 4:30 AM, Chunfeng Yun wrote: fix the warning: WARNING:REPEATED_WORD: Possible repeated word: 'and' Cc: Florian Fainelli Signed-off-by: Chunfeng Yun Acked-by: Florian Fainelli -- Florian
[git pull] drm fixes for 5.9-rc4
Hi Linus, Not much going on this week, nouveau has a display hw bug workaround, amdgpu has some PM fixes and CIK regression fixes, one single radeon PLL fix, and a couple of i915 display fixes. Dave. drm-fixes-2020-09-04: drm fixes for 5.9-rc4 amdgpu: - Fix for 32bit systems - SW CTF fix - Update for Sienna Cichlid - CIK bug fixes radeon: - PLL fix i915: - Clang build warning fix - HDCP fixes nouveau: - display fixes The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b: Linux 5.9-rc3 (2020-08-30 16:01:54 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-09-04 for you to fetch changes up to d37d56920004cae612fa32d1f92aaacca5e145f7: Merge branch 'linux-5.9' of git://github.com/skeggsb/linux into drm-fixes (2020-09-04 11:14:49 +1000) drm fixes for 5.9-rc4 amdgpu: - Fix for 32bit systems - SW CTF fix - Update for Sienna Cichlid - CIK bug fixes radeon: - PLL fix i915: - Clang build warning fix - HDCP fixes nouveau: - display fixes Ben Skeggs (3): drm/nouveau/kms/nv50-: add some whitespace before debug message drm/nouveau/kms/nv50-gp1xx: disable notifies again after core update drm/nouveau/kms/nv50-gp1xx: add WAR for EVO push buffer HW bug Dave Airlie (3): Merge tag 'amd-drm-fixes-5.9-2020-09-03' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2020-09-03' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge branch 'linux-5.9' of git://github.com/skeggsb/linux into drm-fixes Evan Quan (1): drm/amd/pm: avoid false alarm due to confusing softwareshutdowntemp setting Jiansong Chen (1): drm/amd/pm: enable MP0 DPM for sienna_cichlid Kai-Heng Feng (1): drm/radeon: Prefer lower feedback dividers Kevin Wang (1): drm/amd/pm: fix is_dpm_running() run error on 32bit system Lyude Paul (1): drm/nouveau/kms/gv100-: Include correct push header in crcc37d.c Nathan Chancellor (1): drm/i915/display: Ensure that ret is always initialized in icl_combo_phy_verify_state Sandeep Raghuraman (2): drm/amdgpu: Specify get_argument function for ci_smu_funcs drm/amdgpu: Fix bug in reporting voltage for CIK Sean Paul (2): drm/i915: Fix sha_text population code drm/i915: Clear the repeater bit on HDCP disable drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 10 +-- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 +- .../gpu/drm/amd/powerplay/hwmgr/vega10_thermal.c | 14 -- drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 10 +-- drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c | 14 +++--- drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c | 2 ++ drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 +-- drivers/gpu/drm/i915/display/intel_hdcp.c | 32 ++ drivers/gpu/drm/nouveau/dispnv50/core507d.c| 5 +++- drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/disp.c| 6 drivers/gpu/drm/nouveau/include/nvif/push507c.h| 2 +- drivers/gpu/drm/radeon/radeon_display.c| 2 +- include/drm/drm_hdcp.h | 3 ++ 14 files changed, 84 insertions(+), 25 deletions(-)
Re: [PATCH v2 10/11] usb: gadget: bdc: fix checkpatch.pl spacing error
On 8/20/2020 4:30 AM, Chunfeng Yun wrote: fix checkpatch.pl error: ERROR:SPACING: space prohibited before that ',' Cc: Florian Fainelli Signed-off-by: Chunfeng Yun Acked-by: Florian Fainelli -- Florian
Re: [PATCH v2 08/11] usb: gadget: bdc: use the BIT macro to define bit filed
On 8/20/2020 4:30 AM, Chunfeng Yun wrote: Prefer using the BIT macro to define bit fileds Cc: Florian Fainelli Signed-off-by: Chunfeng Yun Acked-by: Florian Fainelli -- Florian
Re: [PATCH v2 09/11] usb: gadget: bdc: fix checkpatch.pl tab warning
On 8/20/2020 4:30 AM, Chunfeng Yun wrote: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional statements WARNING:TABSTOP: Statements should start on a tabstop Cc: Florian Fainelli Signed-off-by: Chunfeng Yun Acked-by: Florian Fainelli -- Florian
Re: [PATCH v2 07/11] usb: gadget: bdc: avoid precedence issues
On 8/20/2020 4:30 AM, Chunfeng Yun wrote: Add () around macro argument to avoid precedence issues Cc: Florian Fainelli Signed-off-by: Chunfeng Yun Acked-by: Florian Fainelli -- Florian
Re: [PATCH v2 05/11] usb: gadget: bdc: fix check warning of block comments alignment
On 8/20/2020 4:30 AM, Chunfeng Yun wrote: fix the warning: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line Cc: Florian Fainelli Signed-off-by: Chunfeng Yun Acked-by: Florian Fainelli -- Florian
Re: [PATCH v2 06/11] usb: gadget: bdc: add identifier name for function declaraion
On 8/20/2020 4:30 AM, Chunfeng Yun wrote: This is used to avoid the warning of function arguments, e.g. WARNING:FUNCTION_ARGUMENTS: function definition argument 'u32' should also have an identifier name Cc: Florian Fainelli Signed-off-by: Chunfeng Yun Acked-by: Florian Fainelli -- Florian
Re: [PATCH v2 03/11] usb: gadget: bdc: prefer pointer dereference to pointer type
On 8/20/2020 4:30 AM, Chunfeng Yun wrote: Prefer kzalloc(sizeof(*bd_table)...) over kzalloc(sizeof(struct bd_table) Cc: Florian Fainelli Signed-off-by: Chunfeng Yun Acked-by: Florian Fainelli -- Florian
