* [PATCH -next v4 1/7] x86, powerpc: fix function define in copy_mc_to_user
From: Tong Tiangen @ 2022-04-20 3:04 UTC (permalink / raw)
To: Mark Rutland, James Morse, Andrew Morton, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Robin Murphy, Dave Hansen,
Catalin Marinas, Will Deacon, Alexander Viro, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, x86, H . Peter Anvin
Cc: linuxppc-dev, linux-arm-kernel, linux-kernel, linux-mm,
Kefeng Wang, Xie XiuQi, Guohanjun, Tong Tiangen
In-Reply-To: <20220420030418.3189040-1-tongtiangen@huawei.com>
x86/powerpc has it's implementation of copy_mc_to_user but not use #define
to declare.
This may cause problems, for example, if other architectures open
CONFIG_ARCH_HAS_COPY_MC, but want to use copy_mc_to_user() outside the
architecture, the code add to include/linux/uaddess.h is as follows:
#ifndef copy_mc_to_user
static inline unsigned long __must_check
copy_mc_to_user(void *dst, const void *src, size_t cnt)
{
...
}
#endif
Then this definition will conflict with the implementation of x86/powerpc
and cause compilation errors as follow:
Fixes: ec6347bb4339 ("x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()")
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
---
arch/powerpc/include/asm/uaccess.h | 1 +
arch/x86/include/asm/uaccess.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index 9b82b38ff867..58dbe8e2e318 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -358,6 +358,7 @@ copy_mc_to_user(void __user *to, const void *from, unsigned long n)
return n;
}
+#define copy_mc_to_user copy_mc_to_user
#endif
extern long __copy_from_user_flushcache(void *dst, const void __user *src,
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index f78e2b3501a1..e18c5f098025 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -415,6 +415,7 @@ copy_mc_to_kernel(void *to, const void *from, unsigned len);
unsigned long __must_check
copy_mc_to_user(void *to, const void *from, unsigned len);
+#define copy_mc_to_user copy_mc_to_user
#endif
/*
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2 v4] ARM: dts: Add initial LS1021A IoT board dts support
From: Changming Huang @ 2022-04-20 2:35 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, shawnguo, l.stach,
alexander.stein, festevam, tharvey, marcel.ziswiler, linux,
matthias.schiffer, cniedermaier, sebastian.reichel, leoyang.li,
devicetree, linux-kernel, arnd, olof, soc, linux-arm-kernel
Cc: Changming Huang, Alison Wang
In-Reply-To: <20220420023556.33157-1-jerry.huang@nxp.com>
The LS1021A-IoT gateway reference design is a purpose-built,
small footprint hardware platform equipped with a wide array
of both high-speed connectivity and low speed serial interfaces.
CC: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Changming Huang <jerry.huang@nxp.com>
Signed-off-by: Alison Wang <alison.wang@nxp.com>
---
changes in v4:
- adjust node names with hyphen
changes in v3:
- adjust to generic node name for i2c nodes
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/ls1021a-iot.dts | 227 ++++++++++++++++++++++++++++++
2 files changed, 228 insertions(+)
create mode 100644 arch/arm/boot/dts/ls1021a-iot.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7c16f8a2b738..e2faf913e313 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -744,6 +744,7 @@ dtb-$(CONFIG_SOC_IMX7ULP) += \
dtb-$(CONFIG_SOC_LAN966) += \
lan966x-pcb8291.dtb
dtb-$(CONFIG_SOC_LS1021A) += \
+ ls1021a-iot.dtb \
ls1021a-moxa-uc-8410a.dtb \
ls1021a-qds.dtb \
ls1021a-tsn.dtb \
diff --git a/arch/arm/boot/dts/ls1021a-iot.dts b/arch/arm/boot/dts/ls1021a-iot.dts
new file mode 100644
index 000000000000..bdb7186f3590
--- /dev/null
+++ b/arch/arm/boot/dts/ls1021a-iot.dts
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2021-2022 NXP
+ *
+ */
+
+/dts-v1/;
+#include "ls1021a.dtsi"
+
+/ {
+ model = "LS1021A-IOT Board";
+ compatible = "fsl,ls1021a-iot", "fsl,ls1021a";
+
+ sys_mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24576000>;
+ };
+
+ reg_3p3v: regulator-3V3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_2p5v: regulator-2V5 {
+ compatible = "regulator-fixed";
+ regulator-name = "2P5V";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "Speaker Ext",
+ "Line", "Line In Jack";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "Microphone Jack", "Mic Bias",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "Speaker Ext", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai2>;
+ frame-master;
+ bitclock-master;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&sgtl5000>;
+ frame-master;
+ bitclock-master;
+ };
+ };
+};
+
+&can0{
+ status = "disabled";
+};
+
+&can1{
+ status = "disabled";
+};
+
+&can2{
+ status = "disabled";
+};
+
+&can3{
+ status = "okay";
+};
+
+&dcu {
+ display = <&display>;
+ status = "okay";
+
+ display: display@0 {
+ bits-per-pixel = <24>;
+
+ display-timings {
+ native-mode = <&timing0>;
+
+ timing0: mode0 {
+ clock-frequency = <25000000>;
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <80>;
+ hfront-porch = <80>;
+ vback-porch = <16>;
+ vfront-porch = <16>;
+ hsync-len = <12>;
+ vsync-len = <2>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+};
+
+&enet0 {
+ tbi-handle = <&tbi1>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "sgmii";
+ status = "okay";
+};
+
+&enet1 {
+ tbi-handle = <&tbi1>;
+ phy-handle = <&phy3>;
+ phy-connection-type = "sgmii";
+ status = "okay";
+};
+
+&enet2 {
+ fixed-link = <0 1 1000 0 0>;
+ phy-connection-type = "rgmii-id";
+ status = "okay";
+};
+
+&esdhc{
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ pca9555: gpio@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ sgtl5000: audio-codec@2a {
+ #sound-dai-cells=<0x0>;
+ compatible = "fsl,sgtl5000";
+ reg = <0x2a>;
+ VDDA-supply = <®_3p3v>;
+ VDDIO-supply = <®_2p5v>;
+ clocks = <&sys_mclk 1>;
+ };
+
+ max1239: adc@35 {
+ compatible = "maxim,max1239";
+ reg = <0x35>;
+ #io-channel-cells = <1>;
+ };
+
+ ina2201: core-monitor@44 {
+ compatible = "ti,ina220";
+ reg = <0x44>;
+ shunt-resistor = <1000>;
+ };
+
+ ina2202: current-monitor@45 {
+ compatible = "ti,ina220";
+ reg = <0x45>;
+ shunt-resistor = <1000>;
+ };
+
+ lm75b: thermal-monitor@48 {
+ compatible = "national,lm75b";
+ reg = <0x48>;
+ };
+};
+
+&lpuart0 {
+ status = "okay";
+};
+
+&mdio0 {
+ phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+
+ phy2: ethernet-phy@2 {
+ reg = <0x2>;
+ };
+
+ phy3: ethernet-phy@3 {
+ reg = <0x3>;
+ };
+
+ tbi1: tbi-phy@1f {
+ reg = <0x1f>;
+ device_type = "tbi-phy";
+ };
+};
+
+&qspi {
+ num-cs = <2>;
+ status = "okay";
+
+ s25fl128s: flash@0 {
+ compatible = "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ };
+};
+
+&sai2 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2 v4] dt-bindings: arm: fsl: add ls1021a-iot board
From: Changming Huang @ 2022-04-20 2:35 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, shawnguo, l.stach,
alexander.stein, festevam, tharvey, marcel.ziswiler, linux,
matthias.schiffer, cniedermaier, sebastian.reichel, leoyang.li,
devicetree, linux-kernel, arnd, olof, soc, linux-arm-kernel
Cc: Changming Huang, Rob Herring
Add the board ls1021a-iot in the binding docuemnt.
Signed-off-by: Changming Huang <jerry.huang@nxp.com>
Acked-by: Rob Herring <robh@kernel.org>
---
changes in v2:
- adjust the location in the alphabetic order
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 08bdd30e511c..242dd99c272c 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -999,6 +999,7 @@ properties:
- description: LS1021A based Boards
items:
- enum:
+ - fsl,ls1021a-iot
- fsl,ls1021a-moxa-uc-8410a
- fsl,ls1021a-qds
- fsl,ls1021a-tsn
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 4/7] clk: mediatek: reset: Add reset.h
From: Rex-BC Chen @ 2022-04-20 2:16 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, mturquette, sboyd
Cc: matthias.bgg, p.zabel, chun-jie.chen, wenst, yong.liang,
runyang.chen, linux-kernel, allen-kh.cheng, linux-clk,
linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20eaaba7-19cb-8f1d-ecf4-bfac14d50f67@collabora.com>
On Tue, 2022-04-19 at 12:46 +0200, AngeloGioacchino Del Regno wrote:
> Il 18/04/22 15:21, Rex-BC Chen ha scritto:
> > Add a new file "reset.h" to place some definitions for clock reset.
> >
> > Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> > ---
> > drivers/clk/mediatek/clk-mtk.h | 10 +---------
> > drivers/clk/mediatek/reset.h | 20 ++++++++++++++++++++
> > 2 files changed, 21 insertions(+), 9 deletions(-)
> > create mode 100644 drivers/clk/mediatek/reset.h
> >
> > diff --git a/drivers/clk/mediatek/clk-mtk.h
> > b/drivers/clk/mediatek/clk-mtk.h
> > index dafdf30fe94e..dfb0549ceb6c 100644
> > --- a/drivers/clk/mediatek/clk-mtk.h
> > +++ b/drivers/clk/mediatek/clk-mtk.h
> > @@ -12,6 +12,7 @@
> > #include <linux/kernel.h>
> > #include <linux/spinlock.h>
> > #include <linux/types.h>
> > +#include <reset.h>
>
> This should be
>
> #include "reset.h"
>
> ...since the header is in the same directory.
>
>
Hello Angelo,
I will fix this in next version.
Thanks!
BRs,
Rex
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/7] clk: mediatek: reset: Revise structure to control reset register
From: Rex-BC Chen @ 2022-04-20 2:20 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, mturquette, sboyd
Cc: matthias.bgg, p.zabel, chun-jie.chen, wenst, yong.liang,
runyang.chen, linux-kernel, allen-kh.cheng, linux-clk,
linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <dc4277ce-cf80-7176-a71f-cb9f93411086@collabora.com>
On Tue, 2022-04-19 at 12:46 +0200, AngeloGioacchino Del Regno wrote:
> Il 18/04/22 15:21, Rex-BC Chen ha scritto:
> > Replace the structure "struct mtk_reset" to reset.h, and rename it
> > as
> > "mtk_clk_rst_data". We use it to input the resset register data and
> > store reset controller device.
> >
> > Signed-off-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
> > ---
> > drivers/clk/mediatek/clk-mt2701-eth.c | 9 +++-
> > drivers/clk/mediatek/clk-mt2701-g3d.c | 9 +++-
> > drivers/clk/mediatek/clk-mt2701-hif.c | 9 +++-
> > drivers/clk/mediatek/clk-mt2701.c | 19 +++++++-
> > drivers/clk/mediatek/clk-mt2712.c | 19 +++++++-
> > drivers/clk/mediatek/clk-mt7622-eth.c | 9 +++-
> > drivers/clk/mediatek/clk-mt7622-hif.c | 19 +++++++-
> > drivers/clk/mediatek/clk-mt7622.c | 19 +++++++-
> > drivers/clk/mediatek/clk-mt7629-eth.c | 9 +++-
> > drivers/clk/mediatek/clk-mt7629-hif.c | 19 +++++++-
> > drivers/clk/mediatek/clk-mt8135.c | 19 +++++++-
> > drivers/clk/mediatek/clk-mt8173.c | 19 +++++++-
> > drivers/clk/mediatek/clk-mt8183.c | 10 ++++-
> > drivers/clk/mediatek/reset.c | 62 +++++++++++++---------
> > -----
> > drivers/clk/mediatek/reset.h | 12 +++++-
> > 15 files changed, 209 insertions(+), 53 deletions(-)
> >
> > diff --git a/drivers/clk/mediatek/clk-mt2701-eth.c
> > b/drivers/clk/mediatek/clk-mt2701-eth.c
> > index 71257714e6a6..16fc4a50d513 100644
> > --- a/drivers/clk/mediatek/clk-mt2701-eth.c
> > +++ b/drivers/clk/mediatek/clk-mt2701-eth.c
> > @@ -36,6 +36,13 @@ static const struct mtk_gate eth_clks[] = {
> > GATE_ETH(CLK_ETHSYS_CRYPTO, "crypto_clk", "ethif_sel", 29),
> > };
> >
> > +static struct mtk_clk_rst_data clk_rst_data = {
>
> static const struct mtk_clk_rst_data clk_rst_data[] = {
>
> ...because this is initialization data that is never supposed to
> change, and
> in the init function of reset.c, you should never modify this struct.
>
> > + .supported = true,
>
> It would make no sense to call mtk_clk_register_rst_ctrl() if the
> resets
> are not supported, so this .supported member is useless and should be
> removed.
Hello Angelo,
Yes, you are right. I will remove is.
>
> I will avoid commenting on patch 7/7 and will say it here: I know
> that on that
> patch you're checking for this one but, especially if this reset data
> becomes a
> const you can, at that point, simply check if anything has been
> assigned to it
> so that if it's not NULL, we implicitly know that said clock
> controller instance
> supports resets, and we register them:
>
> int mtk_clk_simple_probe(...)
> {
> .. blah blah ..
>
> if (mcd->rst)
> r = mtk_clk_register_rst_ctrl(....)
> return r;
> }
>
>
> > + .version = MTK_RST_V1,
> > + .reg_num = 1,
> > + .reg_ofs = 0x34,
> > +};
> > +
> > static const struct of_device_id of_match_clk_mt2701_eth[] = {
> > { .compatible = "mediatek,mt2701-ethsys", },
> > {}
>
> ..snip..
>
> > diff --git a/drivers/clk/mediatek/clk-mt2701.c
> > b/drivers/clk/mediatek/clk-mt2701.c
> > index c1100a20c7ed..a8ac3d11ced6 100644
> > --- a/drivers/clk/mediatek/clk-mt2701.c
> > +++ b/drivers/clk/mediatek/clk-mt2701.c
> > @@ -735,6 +735,21 @@ static const struct mtk_fixed_factor
> > infra_fixed_divs[] = {
> > FACTOR(CLK_INFRA_CLK_13M, "clk13m", "clk26m", 1, 2),
> > };
> >
>
> For increased readability, perhaps it's a good idea to do something
> like...
>
OK, I will do this.
> > +static struct mtk_clk_rst_data clk_rst_data[] = {
> > + {
>
> { /* infrasys */
>
> > + .supported = true,
> > + .version = MTK_RST_V1,
> > + .reg_num = 2,
> > + .reg_ofs = 0x30,
> > + },
>
> { /* pericfg */
>
> > + {
> > + .supported = true,
> > + .version = MTK_RST_V1,
> > + .reg_num = 2,
> > + .reg_ofs = 0x0,
> > + },
> > +};
> > +
> > static struct clk_onecell_data *infra_clk_data;
> >
> > static void __init mtk_infrasys_init_early(struct device_node
> > *node)
>
> ..snip...
>
> > diff --git a/drivers/clk/mediatek/clk-mt7622-hif.c
> > b/drivers/clk/mediatek/clk-mt7622-hif.c
> > index 6be894299ae3..a10ecc5b88a1 100644
> > --- a/drivers/clk/mediatek/clk-mt7622-hif.c
> > +++ b/drivers/clk/mediatek/clk-mt7622-hif.c
> > @@ -76,6 +76,21 @@ static const struct mtk_gate pcie_clks[] = {
> > GATE_PCIE(CLK_SATA_PM_EN, "sata_pm_en", "univpll2_d4", 30),
> > };
> >
> > +static struct mtk_clk_rst_data clk_rst_data[] = {
> > + {
> > + .supported = true,
> > + .version = MTK_RST_V1,
> > + .reg_num = 1,
> > + .reg_ofs = 0x34,
> > + },
>
> I get that the intention here is to separate the reset data between
> ssusbsys
> and pciesys, but both entries are declaring the exact same... since
> (as pointed out
> earlier) this should be a const, you can use the same entry for both.
>
OK, I will do this using new definition of structure.
> > + {
> > + .supported = true,
> > + .version = MTK_RST_V1,
> > + .reg_num = 1,
> > + .reg_ofs = 0x34,
> > + },
> > +};
> > +
> > static int clk_mt7622_ssusbsys_init(struct platform_device *pdev)
> > {
> > struct clk_onecell_data *clk_data;
>
> ..snip..
>
>
> > diff --git a/drivers/clk/mediatek/reset.c
> > b/drivers/clk/mediatek/reset.c
> > index 2a55e8bf6b28..709ae54efc18 100644
> > --- a/drivers/clk/mediatek/reset.c
> > +++ b/drivers/clk/mediatek/reset.c
>
> ..snip..
>
> > @@ -117,21 +123,15 @@ int mtk_clk_register_rst_ctrl(struct
> > device_node *np,
> > return -EINVAL;
> > }
> >
> > - data = kzalloc(sizeof(*data), GFP_KERNEL);
> > - if (!data)
> > - return -ENOMEM;
> > -
> > - data->regmap = regmap;
> > - data->regofs = reg_ofs;
> > - data->rcdev.owner = THIS_MODULE;
> > - data->rcdev.nr_resets = reg_num * 32;
> > - data->rcdev.ops = rst_op[version];
> > - data->rcdev.of_node = np;
>
>
> Here's a cleaner version of this:
>
> int mtk_clk_register_rst_ctrl(struct device *dev,
> const struct mtk_clk_rst_desc *rst_desc)
> {
> ....some code....
>
> struct mtk_reset_data *mtk_reset;
>
> mtk_reset = devm_kzalloc(dev, sizeof(*mtk_reset), GFP_KERNEL)
> if (!mtk_reset)
> return -ENOMEM;
>
> mtk_reset->desc = rst_desc;
> mtk_reset->regmap = regmap;
> mtk_reset->rcdev.owner = .... blah blah
>
> ret = devm_reset_controller_register(dev, &mtk_reset->rcdev);
> if (ret)
> return ret;
>
> ....so if you use the devm_* variant, you don't need patch 6/7, as
> unregistering
> the reset controller will be taken care of by devm actions.
>
> Besides, this is most probably not the case but remember that if you
> need to
> perform more operations to unregister this reset controller, you can
> always
> add a custom devm action with function devm_add_action_or_reset(dev,
> func, parm).
>
>
Yes, I have noticed that. But for some clock drivers, they only provide
device_node.
I will add a new register function using device.
> > + clk_rst->regmap = regmap;
> > + clk_rst->rcdev.owner = THIS_MODULE;
> > + clk_rst->rcdev.nr_resets = clk_rst->reg_num * 32;
> > + clk_rst->rcdev.ops = rst_op[clk_rst->version];
> > + clk_rst->rcdev.of_node = np;
> >
> > - ret = reset_controller_register(&data->rcdev);
> > + ret = reset_controller_register(&clk_rst->rcdev);
> > if (ret) {
> > pr_err("could not register reset controller: %d\n",
> > ret);
> > - kfree(data);
> > return -EINVAL;
> > }
> >
> > diff --git a/drivers/clk/mediatek/reset.h
> > b/drivers/clk/mediatek/reset.h
> > index 0af77531b918..851a29c92440 100644
> > --- a/drivers/clk/mediatek/reset.h
> > +++ b/drivers/clk/mediatek/reset.h
> > @@ -6,6 +6,7 @@
> > #ifndef __DRV_CLK_MTK_RESET_H
> > #define __DRV_CLK_MTK_RESET_H
> >
> > +#include <linux/reset-controller.h>
> > #include <linux/types.h>
> >
> > enum mtk_reset_version {
> > @@ -14,7 +15,16 @@ enum mtk_reset_version {
> > MTK_RST_MAX,
> > };
> >
> > +struct mtk_clk_rst_data {
> > + struct reset_controller_dev rcdev;
> > + struct regmap *regmap;
> > + bool supported;
> > + u8 version;
> > + u32 reg_num;
> > + u16 reg_ofs;
> > +};
>
> ...so here you'd have something like:
>
> struct mtk_clk_rst_desc {
> u8 version;
> u32 reg_num;
> u16 reg_ofs;
> };
>
> struct mtk_reset_data {
> struct regmap *regmap;
> struct reset_controller_dev rcdev;
> const struct mtk_clk_rst_desc *desc;
> };
>
OK. Thanks for your suggestion.
BRs,
Rex
>
> Cheers,
> Angelo
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/9] introduce mirrored memory support for arm64
From: mawupeng @ 2022-04-20 2:13 UTC (permalink / raw)
To: ardb
Cc: akpm, catalin.marinas, will, corbet, tglx, mingo, bp, dave.hansen,
x86, dvhart, andy, rppt, paulmck, peterz, jroedel, songmuchun,
macro, frederic, W_Armin, john.garry, seanjc, tsbogend,
anshuman.khandual, chenhuacai, david, gpiccoli, mark.rutland,
wangkefeng.wang, linux-doc, linux-kernel, linux-arm-kernel,
linux-efi, linux-ia64, platform-driver-x86, linux-mm
In-Reply-To: <CAMj1kXGyKQMeFWSK-s84pdL89qPTyTN_x3WHTgp_R7sH1+qOfA@mail.gmail.com>
在 2022/4/20 2:32, Ard Biesheuvel 写道:
> On Sat, 16 Apr 2022 at 03:32, mawupeng <mawupeng1@huawei.com> wrote:
>>
>>
>>
>> 在 2022/4/14 18:22, Ard Biesheuvel 写道:
>>> On Thu, 14 Apr 2022 at 11:54, Wupeng Ma <mawupeng1@huawei.com> wrote:
>>>>
>>>> From: Ma Wupeng <mawupeng1@huawei.com>
>>>>
>>>> Commit b05b9f5f9dcf ("x86, mirror: x86 enabling - find mirrored memory ranges")
>>>> introduced mirrored memory support for x86. This support rely on UEFI to
>>>> report mirrored memory address ranges. See UEFI 2.5 spec pages 157-158:
>>>>
>>>> http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf
>>>>
>>>> Memory mirroring is a technique used to separate memory into two separate
>>>> channels, usually on a memory device, like a server. In memory mirroring,
>>>> one channel is copied to another to create redundancy. This method makes
>>>> input/output (I/O) registers and memory appear with more than one address
>>>> range because the same physical byte is accessible at more than one
>>>> address. Using memory mirroring, higher memory reliability and a higher
>>>> level of memory consolidation are possible.
>>>>
>>>> Arm64 can support this too. So mirrored memory support is added to support
>>>> arm64.
>>>>
>>>> Efi_fake_mem is used for testing mirrored features and will not be used in
>>>> production environment. This test features can fake memory's attribute
>>>> values.
>>>>
>>>> The reason why efi_fake_mem support is put first is that memory's attribute
>>>> is reported by BIOS which is hard to simulate. With this support, any arm64
>>>> machines with efi support can easily test mirrored features.
>>>>
>>>> The main purpose of this patchset is to introduce mirrored support for
>>>> arm64 and we have already fixed the problems we had which is shown in
>>>> patch #5 to patch #7 and try to bring total isolation in patch #8 which
>>>> will disable mirror feature if kernelcore is not specified.
>>>>
>>>> In order to test this support in arm64:
>>>> - patch this patchset
>>>> - add efi_fake_mem=8G@0:0x10000 in kernel parameter to simulate mirrored
>>>> memroy between phy addr 0-8G.
>>>> - add kernelcore=mirror in kernel parameter
>>>> - start you kernel
>>>>
>>>
>>> As I explained before:
>>>
>>> - NAK to EFI fake_mem support on arm64
>>
>> fake_mem support on arm64 will be removed in subsequent version.
>>
>>> - NAK to the whole series until you come up with a proposal on how to
>>> locate the static kernel image itself into more reliable memory, as
>>> there is really no point to any of this otherwise.
>>
>> Sorry I am not familiar with this, as you metioned before,
>>
>> > you have to iterate over the memory map and look for regions with
>> > the desired attribute, and allocate those pages explicitly.
>>
>> Do you mean this is x86, commit c05cd79750fb
>> ("x86/boot/KASLR: Prefer mirrored memory regions for the kernel physical address").
>> I will do some research.
>>
>> > I'd prefer to implement this in the bootloader, and only add minimal
>> > logic to the stub to respect the placement of the kernel by the loader
>> > if the loader signals it to do so.
>>
>> Does this bootloader refer to grub and then add minimal logic to arm64-stub.c?
>>
>
> Any bootloader, yes.
>
>> What is the loader signal?
>
> A protocol installed onto the image handle, as I suggested before. I
> even cc'ed you on a patch that implements this.
Sorry to bother you.
I didn't receive any patches.
Could you share the link?
>
>> System exists mirrored memory reported by uefi?
>>
>
> What on earth is the point of any of this if the only use case being
> targeted is efi_fake_mem with arbitrary fake mirrored regions?
>
> So yes, unless there are systems that need this, I don't see a point
> in merging any of this
We do have mirrored memory reported by uefi and efi_fake_mem is added for easy testing
with qemu/hardware without update UEFI.
> .
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] arm64: ftrace: Add DYNAMIC_FTRACE_WITH_ARGS support
From: Li Huafei @ 2022-04-20 2:09 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: catalin.marinas, will, rostedt, mingo, broonie, mark.rutland,
ardb, lihuafei1
DYNAMIC_FTRACE_WITH_ARGS allows ftrace_ops without the FL_SAVE_REGS flag
set (via the "ftrace_caller" trampoline) to fetch all parameters and
stack pointer. On arm64, under the DYNAMIC_FTRACE_WITH_REGS
implementation, ftrace_caller() already supports filling the above
registers into pt_regs, all that remains to be done is to ensure that
arch_ftrace_get_regs() returns NULL when FL_SAVE_REGS is not set. We use
pt_regs::regs[10] to identify whether the FL_SAVE_REGS flag is set.
The mcount-based implementation supports DYNAMIC_FTRACE_WITH_ARGS with
some difficulty, as some registers (e.g. X0) are already clobbered
before entering the trampoline. We need to rely on gcc's
"-fpatchable-function-entry" feature, so here we have
DYNAMIC_FTRACE_WITH_ARGS depending on DYNAMIC_FTRACE_WITH_REGS, and the
mcount-based implementation is unaffected.
Signed-off-by: Li Huafei <lihuafei1@huawei.com>
---
arch/arm64/Kconfig | 2 ++
arch/arm64/include/asm/ftrace.h | 17 +++++++++++++++++
arch/arm64/kernel/entry-ftrace.S | 5 +++++
3 files changed, 24 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 18a18a0e855d..a1b4c5800b38 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -177,6 +177,8 @@ config ARM64
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
+ select HAVE_DYNAMIC_FTRACE_WITH_ARGS \
+ if HAVE_DYNAMIC_FTRACE_WITH_REGS
select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
if DYNAMIC_FTRACE_WITH_REGS
select HAVE_EFFICIENT_UNALIGNED_ACCESS
diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
index 1494cfa8639b..2b4cd442c843 100644
--- a/arch/arm64/include/asm/ftrace.h
+++ b/arch/arm64/include/asm/ftrace.h
@@ -78,6 +78,23 @@ static inline unsigned long ftrace_call_adjust(unsigned long addr)
return addr;
}
+#ifdef CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS
+struct ftrace_regs {
+ struct pt_regs regs;
+};
+
+static __always_inline struct pt_regs *
+arch_ftrace_get_regs(struct ftrace_regs *fregs)
+{
+ struct pt_regs *regs = &fregs->regs;
+
+ /* When FL_SAVE_REGS is not set, X10 is set to zero */
+ if (!pt_regs_read_reg(regs, 10))
+ return NULL;
+ return regs;
+}
+#endif /* CONFIG_HAVE_DYNAMIC_FTRACE_WITH_ARGS */
+
#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
struct dyn_ftrace;
int ftrace_init_nop(struct module *mod, struct dyn_ftrace *rec);
diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
index e535480a4069..805287fedb01 100644
--- a/arch/arm64/kernel/entry-ftrace.S
+++ b/arch/arm64/kernel/entry-ftrace.S
@@ -46,6 +46,8 @@
/* Optionally save the callee-saved registers, always save the FP */
.if \allregs == 1
+ /* Set X10 to 1 (just non-zero) for ops with FL_SAVE_REGS flag set */
+ mov x10, #1
stp x10, x11, [sp, #S_X10]
stp x12, x13, [sp, #S_X12]
stp x14, x15, [sp, #S_X14]
@@ -57,6 +59,9 @@
stp x26, x27, [sp, #S_X26]
stp x28, x29, [sp, #S_X28]
.else
+ /* Set X10 to 0 for ops without FL_SAVE_REGS flag */
+ mov x10, #0
+ str x10, [sp, #S_X10]
str x29, [sp, #S_FP]
.endif
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2] arm/xen: Fix some refcount leaks
From: Miaoqian Lin @ 2022-04-20 1:49 UTC (permalink / raw)
To: Stefano Stabellini, Russell King, Shannon Zhao, Catalin Marinas,
Julien Grall, Oleksandr Tyshchenko, Juergen Gross, xen-devel,
linux-arm-kernel, linux-kernel
Cc: linmq006
In-Reply-To: <20220406021905.GA30436@8345e2a12d0c>
The of_find_compatible_node() function returns a node pointer with
refcount incremented, We should use of_node_put() on it when done
Add the missing of_node_put() to release the refcount.
Fixes: 9b08aaa3199a ("ARM: XEN: Move xen_early_init() before efi_init()")
Fixes: b2371587fe0c ("arm/xen: Read extended regions from DT and init Xen resource")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
---
changes in v2:
- call of_node_put in non-error path in xen_dt_guest_init
- fix same refcount leak error in arch_xen_unpopulated_init
---
arch/arm/xen/enlighten.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index ec5b082f3de6..07eb69f9e7df 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -337,12 +337,15 @@ int __init arch_xen_unpopulated_init(struct resource **res)
if (!nr_reg) {
pr_err("No extended regions are found\n");
+ of_node_put(np);
return -EINVAL;
}
regs = kcalloc(nr_reg, sizeof(*regs), GFP_KERNEL);
- if (!regs)
+ if (!regs) {
+ of_node_put(np);
return -ENOMEM;
+ }
/*
* Create resource from extended regions provided by the hypervisor to be
@@ -403,8 +406,8 @@ int __init arch_xen_unpopulated_init(struct resource **res)
*res = &xen_resource;
err:
+ of_node_put(np);
kfree(regs);
-
return rc;
}
#endif
@@ -424,8 +427,10 @@ static void __init xen_dt_guest_init(void)
if (of_address_to_resource(xen_node, GRANT_TABLE_INDEX, &res)) {
pr_err("Xen grant table region is not found\n");
+ of_node_put(xen_node);
return;
}
+ of_node_put(xen_node);
xen_grant_frames = res.start;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 3/3] dt-bindings: arm: mediatek: infracfg: Convert to DT schema
From: Rob Herring @ 2022-04-20 1:19 UTC (permalink / raw)
To: Yassine Oudjana
Cc: Yassine Oudjana, linux-arm-kernel, devicetree, linux-mediatek,
Ryder Lee, Sam Shih, Stephen Boyd, Matthias Brugger, linux-kernel,
Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20220419180938.19397-4-y.oudjana@protonmail.com>
On Tue, 19 Apr 2022 22:09:39 +0400, Yassine Oudjana wrote:
> From: Yassine Oudjana <y.oudjana@protonmail.com>
>
> Convert infracfg bindings to DT schema format. Not all drivers
> currently implement resets, so #reset-cells is made a required
> property only for those that do. Using power-controller in the
> example node name makes #power-domain-cells required causing
> a dt_binding_check error. To solve this, the node is renamed to
> syscon@10001000.
>
> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
> ---
> .../arm/mediatek/mediatek,infracfg.txt | 42 ----------
> .../arm/mediatek/mediatek,infracfg.yaml | 79 +++++++++++++++++++
> 2 files changed, 79 insertions(+), 42 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
> create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.yaml
>
Running 'make dtbs_check' with the schema in this patch gives the
following warnings. Consider if they are expected or the schema is
incorrect. These may not be new warnings.
Note that it is not yet a requirement to have 0 warnings for dtbs_check.
This will change in the future.
Full log is available here: https://patchwork.ozlabs.org/patch/
infracfg@10001000: '#reset-cells' is a required property
arch/arm64/boot/dts/mediatek/mt7986a-rfb.dtb
arch/arm64/boot/dts/mediatek/mt7986b-rfb.dtb
syscon@10001000: '#reset-cells' is a required property
arch/arm64/boot/dts/mediatek/mt2712-evb.dtb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 14/17] KVM: arm64: Punt last page reference to rcu callback for parallel walk
From: Oliver Upton @ 2022-04-20 0:53 UTC (permalink / raw)
To: Ricardo Koller
Cc: kvmarm, kvm, Marc Zyngier, James Morse, Alexandru Elisei,
Suzuki K Poulose, linux-arm-kernel, Peter Shier, Reiji Watanabe,
Paolo Bonzini, Sean Christopherson, Ben Gardon, David Matlack
In-Reply-To: <Yl4n7o45K0HFK52S@google.com>
Hi Ricardo,
On Mon, Apr 18, 2022 at 8:09 PM Ricardo Koller <ricarkol@google.com> wrote:
>
> On Mon, Apr 18, 2022 at 07:59:04PM -0700, Ricardo Koller wrote:
> > On Fri, Apr 15, 2022 at 09:58:58PM +0000, Oliver Upton wrote:
> > > It is possible that a table page remains visible to another thread until
> > > the next rcu synchronization event. To that end, we cannot drop the last
> > > page reference synchronous with post-order traversal for a parallel
> > > table walk.
> > >
> > > Schedule an rcu callback to clean up the child table page for parallel
> > > walks.
> > >
> > > Signed-off-by: Oliver Upton <oupton@google.com>
> > > ---
> > > arch/arm64/include/asm/kvm_pgtable.h | 3 ++
> > > arch/arm64/kvm/hyp/pgtable.c | 24 +++++++++++++--
> > > arch/arm64/kvm/mmu.c | 44 +++++++++++++++++++++++++++-
> > > 3 files changed, 67 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h
> > > index 74955aba5918..52e55e00f0ca 100644
> > > --- a/arch/arm64/include/asm/kvm_pgtable.h
> > > +++ b/arch/arm64/include/asm/kvm_pgtable.h
> > > @@ -81,6 +81,8 @@ static inline bool kvm_level_supports_block_mapping(u32 level)
> > > * @put_page: Decrement the refcount on a page. When the
> > > * refcount reaches 0 the page is automatically
> > > * freed.
> > > + * @free_table: Drop the last page reference, possibly in the
> > > + * next RCU sync if doing a shared walk.
> > > * @page_count: Return the refcount of a page.
> > > * @phys_to_virt: Convert a physical address into a virtual
> > > * address mapped in the current context.
> > > @@ -98,6 +100,7 @@ struct kvm_pgtable_mm_ops {
> > > void (*get_page)(void *addr);
> > > void (*put_page)(void *addr);
> > > int (*page_count)(void *addr);
> > > + void (*free_table)(void *addr, bool shared);
> > > void* (*phys_to_virt)(phys_addr_t phys);
> > > phys_addr_t (*virt_to_phys)(void *addr);
> > > void (*dcache_clean_inval_poc)(void *addr, size_t size);
> > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > > index 121818d4c33e..a9a48edba63b 100644
> > > --- a/arch/arm64/kvm/hyp/pgtable.c
> > > +++ b/arch/arm64/kvm/hyp/pgtable.c
> > > @@ -147,12 +147,19 @@ static inline void kvm_pgtable_walk_end(void)
> > > {}
> > >
> > > #define kvm_dereference_ptep rcu_dereference_raw
> > > +
> > > +static inline void kvm_pgtable_destroy_barrier(void)
> > > +{}
> > > +
> > > #else
> > > #define kvm_pgtable_walk_begin rcu_read_lock
> > >
> > > #define kvm_pgtable_walk_end rcu_read_unlock
> > >
> > > #define kvm_dereference_ptep rcu_dereference
> > > +
> > > +#define kvm_pgtable_destroy_barrier rcu_barrier
> > > +
> > > #endif
> > >
> > > static kvm_pte_t *kvm_pte_follow(kvm_pte_t pte, struct kvm_pgtable_mm_ops *mm_ops)
> > > @@ -1063,7 +1070,12 @@ static int stage2_map_walk_table_post(u64 addr, u64 end, u32 level,
> > > childp = kvm_pte_follow(*old, mm_ops);
> > > }
> > >
> > > - mm_ops->put_page(childp);
> > > + /*
> > > + * If we do not have exclusive access to the page tables it is possible
> > > + * the unlinked table remains visible to another thread until the next
> > > + * rcu synchronization.
> > > + */
> > > + mm_ops->free_table(childp, shared);
> > > mm_ops->put_page(ptep);
> > >
> > > return ret;
> > > @@ -1203,7 +1215,7 @@ static int stage2_unmap_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
> > > kvm_granule_size(level));
> > >
> > > if (childp)
> > > - mm_ops->put_page(childp);
> > > + mm_ops->free_table(childp, shared);
> > >
> > > return 0;
> > > }
> > > @@ -1433,7 +1445,7 @@ static int stage2_free_walker(u64 addr, u64 end, u32 level, kvm_pte_t *ptep,
> > > mm_ops->put_page(ptep);
> > >
> > > if (kvm_pte_table(*old, level))
> > > - mm_ops->put_page(kvm_pte_follow(*old, mm_ops));
> > > + mm_ops->free_table(kvm_pte_follow(*old, mm_ops), shared);
> > >
> > > return 0;
> > > }
> > > @@ -1452,4 +1464,10 @@ void kvm_pgtable_stage2_destroy(struct kvm_pgtable *pgt)
> > > pgd_sz = kvm_pgd_pages(pgt->ia_bits, pgt->start_level) * PAGE_SIZE;
> > > pgt->mm_ops->free_pages_exact(pgt->pgd, pgd_sz);
> > > pgt->pgd = NULL;
> > > +
> > > + /*
> > > + * Guarantee that all unlinked subtrees associated with the stage2 page
> > > + * table have also been freed before returning.
> > > + */
> > > + kvm_pgtable_destroy_barrier();
> > > }
> > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > index cc6ed6b06ec2..6ecf37009c21 100644
> > > --- a/arch/arm64/kvm/mmu.c
> > > +++ b/arch/arm64/kvm/mmu.c
> > > @@ -98,9 +98,50 @@ static bool kvm_is_device_pfn(unsigned long pfn)
> > > static void *stage2_memcache_zalloc_page(void *arg)
> > > {
> > > struct kvm_mmu_caches *mmu_caches = arg;
> > > + struct stage2_page_header *hdr;
> > > + void *addr;
> > >
> > > /* Allocated with __GFP_ZERO, so no need to zero */
> > > - return kvm_mmu_memory_cache_alloc(&mmu_caches->page_cache);
> > > + addr = kvm_mmu_memory_cache_alloc(&mmu_caches->page_cache);
> > > + if (!addr)
> > > + return NULL;
> > > +
> > > + hdr = kvm_mmu_memory_cache_alloc(&mmu_caches->header_cache);
> > > + if (!hdr) {
> > > + free_page((unsigned long)addr);
> > > + return NULL;
> > > + }
> > > +
> > > + hdr->page = virt_to_page(addr);
> > > + set_page_private(hdr->page, (unsigned long)hdr);
> > > + return addr;
> > > +}
> > > +
> > > +static void stage2_free_page_now(struct stage2_page_header *hdr)
> > > +{
> > > + WARN_ON(page_ref_count(hdr->page) != 1);
> > > +
> > > + __free_page(hdr->page);
> > > + kmem_cache_free(stage2_page_header_cache, hdr);
> > > +}
> > > +
> > > +static void stage2_free_page_rcu_cb(struct rcu_head *head)
> > > +{
> > > + struct stage2_page_header *hdr = container_of(head, struct stage2_page_header,
> > > + rcu_head);
> > > +
> > > + stage2_free_page_now(hdr);
> > > +}
> > > +
> > > +static void stage2_free_table(void *addr, bool shared)
> > > +{
> > > + struct page *page = virt_to_page(addr);
> > > + struct stage2_page_header *hdr = (struct stage2_page_header *)page_private(page);
> > > +
> > > + if (shared)
> > > + call_rcu(&hdr->rcu_head, stage2_free_page_rcu_cb);
> >
> > Can the number of callbacks grow to "dangerous" numbers? can it be
> > bounded with something like the following?
> >
> > if number of readers is really high:
> > synchronize_rcu()
> > else
> > call_rcu()
>
> sorry, meant to say "number of callbacks"
Good point. I don't have data for this, but generally speaking I do
not believe we need to enqueue a callback for every page. In fact,
since we already make the invalid PTE visible in pre-order traversal
we could theoretically free all tables from a single RCU callback (per
fault).
I think if we used synchronize_rcu() then we would need to drop the
mmu lock since it will block the thread.
--
Thanks,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 00/14] Multi-Gen LRU Framework
From: Yu Zhao @ 2022-04-20 0:50 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, Linux-MM, Andi Kleen, Aneesh Kumar, Barry Song,
Catalin Marinas, Dave Hansen, Hillf Danton, Jens Axboe,
Jesse Barnes, Johannes Weiner, Jonathan Corbet, Linus Torvalds,
Matthew Wilcox, Mel Gorman, Michael Larabel, Michal Hocko,
Mike Rapoport, Rik van Riel, Vlastimil Babka, Will Deacon,
Ying Huang, Linux ARM, open list:DOCUMENTATION, linux-kernel,
Kernel Page Reclaim v2, the arch/x86 maintainers
In-Reply-To: <20220413220636.dd33898d36156bc7339f04e9@linux-foundation.org>
On Wed, Apr 13, 2022 at 11:06 PM Andrew Morton
<akpm@linux-foundation.org> wrote:
>
> The code uses
>
> struct lru_gen_mm_walk *walk
>
> in some places and
>
> struct mm_walk *walk
>
> in others. This is already driving me nuts. Can we please use
> different identifiers for different types?
Sorry.
Going with "struct lru_gen_mm_walk *args", unless there are objections.
("struct mm_walk *walk" is an existing convention so I don't think I
should change that.)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 05/14] mm: multi-gen LRU: groundwork
From: Yu Zhao @ 2022-04-20 0:39 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Andrew Morton, Stephen Rothwell, Linux-MM, Andi Kleen,
Aneesh Kumar, Barry Song, Catalin Marinas, Dave Hansen,
Hillf Danton, Jens Axboe, Jesse Barnes, Johannes Weiner,
Jonathan Corbet, Linus Torvalds, Matthew Wilcox, Mel Gorman,
Michael Larabel, Michal Hocko, Mike Rapoport, Rik van Riel,
Vlastimil Babka, Will Deacon, Ying Huang, Linux ARM,
open list:DOCUMENTATION, linux-kernel, Kernel Page Reclaim v2,
the arch/x86 maintainers, Brian Geffon, Jan Alexander Steffens,
Oleksandr Natalenko, Steven Barrett, Suleiman Souhlal,
Daniel Byrne, Donald Carr, Holger Hoffstätte,
Konstantin Kharlamov, Shuang Zhai, Sofia Trinh, Vaibhav Jain
In-Reply-To: <20220412070616.GT2731@worktop.programming.kicks-ass.net>
On Tue, Apr 12, 2022 at 1:06 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Apr 11, 2022 at 07:16:15PM -0700, Andrew Morton wrote:
>
> > > +{
> > > + int gen;
> > > + unsigned long old_flags, new_flags;
> > > +
> > > + do {
> > > + new_flags = old_flags = READ_ONCE(folio->flags);
> > > + if (!(new_flags & LRU_GEN_MASK))
> > > + return false;
> > > +
> > > + VM_BUG_ON_FOLIO(folio_test_active(folio), folio);
> > > + VM_BUG_ON_FOLIO(folio_test_unevictable(folio), folio);
> > > +
> > > + gen = ((new_flags & LRU_GEN_MASK) >> LRU_GEN_PGOFF) - 1;
> > > +
> > > + new_flags &= ~LRU_GEN_MASK;
> > > + /* for shrink_page_list() */
> > > + if (reclaiming)
> > > + new_flags &= ~(BIT(PG_referenced) | BIT(PG_reclaim));
> > > + else if (lru_gen_is_active(lruvec, gen))
> > > + new_flags |= BIT(PG_active);
> > > + } while (cmpxchg(&folio->flags, old_flags, new_flags) != old_flags);
>
> Also; please use the form:
>
> unsigned long new, old = READ_ONCE(folio->flags);
>
> do {
> new = /* something */ old;
> } while (!try_cmpxchg(&folio->flags, &old, new))
Sweet. Thanks.
A related question: if I pass new = old to try_cmpxchg(), does it know
that and avoid an unnecessary atomic op?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 6/6] arm/xen: Assign xen-virtio DMA ops for virtio devices in Xen guests
From: Stefano Stabellini @ 2022-04-20 0:23 UTC (permalink / raw)
To: Oleksandr
Cc: Juergen Gross, Stefano Stabellini, Christoph Hellwig, xen-devel,
linux-kernel, linux-arm-kernel, Oleksandr Tyshchenko,
Boris Ostrovsky, Julien Grall, Michael S. Tsirkin
In-Reply-To: <5afb9e61-4164-9cc9-278a-911fc21f4f6c@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4244 bytes --]
On Tue, 19 Apr 2022, Oleksandr wrote:
> On 19.04.22 17:48, Juergen Gross wrote:
> > On 19.04.22 14:17, Oleksandr wrote:
> > >
> > > Hello Stefano, Juergen
> > >
> > >
> > > On 18.04.22 22:11, Stefano Stabellini wrote:
> > > > On Mon, 18 Apr 2022, Oleksandr wrote:
> > > > > On 16.04.22 09:07, Christoph Hellwig wrote:
> > > > >
> > > > > Hello Christoph
> > > > >
> > > > > > On Fri, Apr 15, 2022 at 03:02:45PM -0700, Stefano Stabellini wrote:
> > > > > > > This makes sense overall. Considering that the swiotlb-xen case
> > > > > > > and the
> > > > > > > virtio case are mutually exclusive, I would write it like this:
> > > > > > Curious question: Why can't the same grant scheme also be used for
> > > > > > non-virtio devices? I really hate having virtio hooks in the arch
> > > > > > dma code. Why can't Xen just say in DT/ACPI that grants can be used
> > > > > > for a given device?
> > > > [...]
> > > >
> > > > > This patch series tries to make things work with "virtio" devices in
> > > > > Xen
> > > > > system without introducing any modifications to code under
> > > > > drivers/virtio.
> > > >
> > > > Actually, I think Christoph has a point.
> > > >
> > > > There is nothing inherently virtio specific in this patch series or in
> > > > the "xen,dev-domid" device tree binding.
> > >
> > >
> > > Although the main intention of this series was to enable using virtio
> > > devices in Xen guests, I agree that nothing in new DMA ops layer
> > > (xen-virtio.c) is virtio specific (at least at the moment). Regarding the
> > > whole patch series I am not quite sure, as it uses
> > > arch_has_restricted_virtio_memory_access(). >
> > > > Assuming a given device is
> > > > emulated by a Xen backend, it could be used with grants as well.
> > > >
> > > > For instance, we could provide an emulated e1000 NIC with a
> > > > "xen,dev-domid" property in device tree. Linux could use grants with it
> > > > and the backend could map the grants. It would work the same way as
> > > > virtio-net/block/etc. Passthrough devices wouldn't have the
> > > > "xen,dev-domid" property, so no problems.
> > > >
> > > > So I think we could easily generalize this work and expand it to any
> > > > device. We just need to hook on the "xen,dev-domid" device tree
> > > > property.
> > > >
> > > > I think it is just a matter of:
> > > > - remove the "virtio,mmio" check from xen_is_virtio_device
> > > > - rename xen_is_virtio_device to something more generic, like
> > > > xen_is_grants_device
> >
> > xen_is_grants_dma_device, please. Normal Xen PV devices are covered by
> > grants, too, and I'd like to avoid the confusion arising from this.
>
>
> yes, this definitely makes sense as we need to distinguish
>
>
> >
> >
> > > > - rename xen_virtio_setup_dma_ops to something more generic, like
> > > > xen_grants_setup_dma_ops
> > > >
> > > > And that's pretty much it.
> > >
> > > + likely renaming everything in that patch series not to mention virtio
> > > (mostly related to xen-virtio.c internals).
> > >
> > >
> > > Stefano, thank you for clarifying Christoph's point.
> > >
> > > Well, I am not against going this direction. Could we please make a
> > > decision on this? @Juergen, what is your opinion?
> >
> > Yes, why not.
>
>
> ok, thank you for confirming.
>
>
> >
> >
> > Maybe rename xen-virtio.c to grant-dma.c?
>
>
> Personally I don't mind.
>
>
> >
> > I'd keep the XEN_VIRTIO related config option, as this will be the normal
> > use
> > case. grant-dma.c should be covered by a new hidden config option
> > XEN_GRANT_DMA
> > selected by XEN_VIRTIO.
>
>
> I got it, ok
>
>
> >
> >
> > CONFIG_XEN_VIRTIO should still guard
> > xen_has_restricted_virtio_memory_access().
>
>
> ok
>
>
> So a few questions to clarify:
>
> 1. What is the best place to keep "xen,dev-domid" binding's description now? I
> think that proposed in current series place
> (Documentation/devicetree/bindings/virtio/) is not good fit now.
I would probably add it to the existing
Documentation/devicetree/bindings/arm/xen.txt.
> 2. I assume the logic in the current patch will remain the same, I mean we
> will still assign Xen grant DMA ops from xen_setup_dma_ops() here?
Yes I think so
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 13/48] ARM: pxa: use pdev resource for palmld mmio
From: Damien Le Moal @ 2022-04-19 23:55 UTC (permalink / raw)
To: Arnd Bergmann, robert.jarzmik, linux-arm-kernel
Cc: Arnd Bergmann, Daniel Mack, Haojian Zhuang, Marek Vasut,
Philipp Zabel, Lubomir Rintel, Paul Parsons, Tomas Cech,
Sergey Lapin, Thomas Bogendoerfer, Michael Turquette,
Stephen Boyd, Rafael J. Wysocki, Viresh Kumar, Dmitry Torokhov,
Ulf Hansson, Dominik Brodowski, Helge Deller, Mark Brown,
Linus Walleij, linux-kernel, linux-mips, linux-ide, linux-clk,
linux-pm, linux-input, patches, linux-leds, linux-mmc, linux-mtd,
linux-rtc, linux-usb, linux-fbdev, dri-devel, alsa-devel,
Jens Axboe, Bartlomiej Zolnierkiewicz
In-Reply-To: <20220419163810.2118169-14-arnd@kernel.org>
On 4/20/22 01:37, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The palmld header is almost unused in drivers, the only
> remaining thing now is the PATA device address, which should
> really be passed as a resource.
>
> Cc: Jens Axboe <axboe@kernel.dk>
> Cc: linux-ide@vger.kernel.org
> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-pxa/palmld-pcmcia.c | 3 ++-
> arch/arm/mach-pxa/palmld.c | 12 +++++++++---
> arch/arm/mach-pxa/{include/mach => }/palmld.h | 2 +-
> drivers/ata/pata_palmld.c | 3 +--
> 4 files changed, 13 insertions(+), 7 deletions(-)
> rename arch/arm/mach-pxa/{include/mach => }/palmld.h (98%)
>
> diff --git a/arch/arm/mach-pxa/palmld-pcmcia.c b/arch/arm/mach-pxa/palmld-pcmcia.c
> index 07e0f7438db1..720294a50864 100644
> --- a/arch/arm/mach-pxa/palmld-pcmcia.c
> +++ b/arch/arm/mach-pxa/palmld-pcmcia.c
> @@ -13,9 +13,10 @@
> #include <linux/gpio.h>
>
> #include <asm/mach-types.h>
> -#include <mach/palmld.h>
> #include <pcmcia/soc_common.h>
>
> +#include "palmld.h"
> +
> static struct gpio palmld_pcmcia_gpios[] = {
> { GPIO_NR_PALMLD_PCMCIA_POWER, GPIOF_INIT_LOW, "PCMCIA Power" },
> { GPIO_NR_PALMLD_PCMCIA_RESET, GPIOF_INIT_HIGH,"PCMCIA Reset" },
> diff --git a/arch/arm/mach-pxa/palmld.c b/arch/arm/mach-pxa/palmld.c
> index d85146957004..d821606ce0b5 100644
> --- a/arch/arm/mach-pxa/palmld.c
> +++ b/arch/arm/mach-pxa/palmld.c
> @@ -29,8 +29,8 @@
> #include <asm/mach/map.h>
>
> #include "pxa27x.h"
> +#include "palmld.h"
> #include <linux/platform_data/asoc-pxa.h>
> -#include <mach/palmld.h>
> #include <linux/platform_data/mmc-pxamci.h>
> #include <linux/platform_data/video-pxafb.h>
> #include <linux/platform_data/irda-pxaficp.h>
> @@ -279,9 +279,15 @@ static inline void palmld_leds_init(void) {}
> * HDD
> ******************************************************************************/
> #if defined(CONFIG_PATA_PALMLD) || defined(CONFIG_PATA_PALMLD_MODULE)
> +static struct resource palmld_ide_resources[] = {
> + DEFINE_RES_MEM(PALMLD_IDE_PHYS, 0x1000),
> +};
> +
> static struct platform_device palmld_ide_device = {
> - .name = "pata_palmld",
> - .id = -1,
> + .name = "pata_palmld",
> + .id = -1,
> + .resource = palmld_ide_resources,
> + .num_resources = ARRAY_SIZE(palmld_ide_resources),
> };
>
> static struct gpiod_lookup_table palmld_ide_gpio_table = {
> diff --git a/arch/arm/mach-pxa/include/mach/palmld.h b/arch/arm/mach-pxa/palmld.h
> similarity index 98%
> rename from arch/arm/mach-pxa/include/mach/palmld.h
> rename to arch/arm/mach-pxa/palmld.h
> index 99a6d8b3a1e3..ee3bc15b71a2 100644
> --- a/arch/arm/mach-pxa/include/mach/palmld.h
> +++ b/arch/arm/mach-pxa/palmld.h
> @@ -9,7 +9,7 @@
> #ifndef _INCLUDE_PALMLD_H_
> #define _INCLUDE_PALMLD_H_
>
> -#include "irqs.h" /* PXA_GPIO_TO_IRQ */
> +#include <mach/irqs.h> /* PXA_GPIO_TO_IRQ */
>
> /** HERE ARE GPIOs **/
>
> diff --git a/drivers/ata/pata_palmld.c b/drivers/ata/pata_palmld.c
> index 2448441571ed..400e65190904 100644
> --- a/drivers/ata/pata_palmld.c
> +++ b/drivers/ata/pata_palmld.c
> @@ -25,7 +25,6 @@
> #include <linux/gpio/consumer.h>
>
> #include <scsi/scsi_host.h>
> -#include <mach/palmld.h>
>
> #define DRV_NAME "pata_palmld"
>
> @@ -63,7 +62,7 @@ static int palmld_pata_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> /* remap drive's physical memory address */
> - mem = devm_ioremap(dev, PALMLD_IDE_PHYS, 0x1000);
> + mem = devm_platform_ioremap_resource(pdev, 0);
> if (!mem)
> return -ENOMEM;
>
Acked-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
--
Damien Le Moal
Western Digital Research
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Fix size calculation in arm_smmu_mm_invalidate_range()
From: Nicolin Chen @ 2022-04-19 23:36 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, joro, jean-philippe, jacob.jun.pan, baolu.lu,
fenghua.yu, rikard.falkeborn, linux-arm-kernel, iommu,
linux-kernel, stable
In-Reply-To: <20220419231034.GP64706@ziepe.ca>
On Tue, Apr 19, 2022 at 08:10:34PM -0300, Jason Gunthorpe wrote:
> > - size_t size = end - start + 1;
> > + size_t size;
> > +
> > + /*
> > + * The mm_types defines vm_end as the first byte after the end address,
> > + * different from IOMMU subsystem using the last address of an address
> > + * range. So do a simple translation here by calculating size correctly.
> > + */
> > + size = end - start;
>
> I would skip the comment though
It's a bit of highlight here to help us remember in the future,
per Robin's comments at my previous patch.
Thanks!
Nic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] perf/arm-cmn: Add CMN-650 support
From: Ilkka Koskinen @ 2022-04-19 23:47 UTC (permalink / raw)
To: Ilkka Koskinen; +Cc: Robin Murphy, will, mark.rutland, linux-arm-kernel
In-Reply-To: <alpine.DEB.2.22.394.2204191446440.2855@ubuntu200401>
On Tue, 19 Apr 2022, Ilkka Koskinen wrote:
>
> Hi Robin,
>
> I need to go through your patches more carefully, but I do have a couple of
> comments already:
>
> On Mon, 18 Apr 2022, Robin Murphy wrote:
>> Add the identifiers and events for CMN-650, which slots into its
>> evolutionary position between CMN-600 and the 700-series products.
>> Imagine CMN-600 made bigger, and with most of the rough edges smoothed
>> off, but that then balanced out by some bonkers PMU functionality for
>> the new HN-P enhancement in CMN-650r2.
>>
>> Most of the CXG events are actually common to newer revisions of CMN-600
>> too, so they're arguably a little late; oh well.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/perf/arm-cmn.c | 222 ++++++++++++++++++++++++++++++++---------
>> 1 file changed, 176 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
>> index 9c1d82be7a2f..cce8516d465c 100644
>> --- a/drivers/perf/arm-cmn.c
>> +++ b/drivers/perf/arm-cmn.c
>> @@ -1979,6 +2108,7 @@ MODULE_DEVICE_TABLE(of, arm_cmn_of_match);
>> #ifdef CONFIG_ACPI
>> static const struct acpi_device_id arm_cmn_acpi_match[] = {
>> { "ARMHC600", CMN600 },
>> + { "ARMHC650", CMN650 },
>
> Not the great place for this comment but there probably isn't any better.
>
> Based on DEN0093 v1.1, CMN's DSDT entries have been changed since CMN-600.
> ROOTNODEBASE seems to be specific for CMN-600. Moreover, if you compare the
> address maps in TRMs' Discovery chapters, you can see the difference.
>
> I'm thinking, at the minimal the second platform_get_resource() call has to
> be skipped and zero returned in arm_cmn600_acpi_probe(), if the model is
> cmn650 (probably also for cmn-700)
Uh, if only I had read the code more carefully, I had noticed that's what
the driver does indeed.
Anyway, so far it everything works fine. I test the driver a little more
(and review the patches more carefully) and will let know how it goes.
--Ilkka
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the samsung-krzk-fixes tree
From: Stephen Rothwell @ 2022-04-19 23:42 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, Krzysztof Kozlowski
Cc: ARM, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2097 bytes --]
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in:
arch/arm/Kconfig
between commit:
436ce66003d5 ("ARM: s3c: mark as deprecated and schedule removal")
from the samsung-krzk-fixes tree and commit:
8c1fb11b8a77 ("ARM: s3c: enable s3c24xx multiplatform support")
from the arm-soc tree.
I fixed it up (I used the latter version of this file and added the
following merge fix patch) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 20 Apr 2022 09:38:18 +1000
Subject: [PATCH] fixup for "ARM: s3c: mark as deprecated and schedule removal"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/arm/mach-s3c/Kconfig.s3c24xx | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-s3c/Kconfig.s3c24xx b/arch/arm/mach-s3c/Kconfig.s3c24xx
index d7dc031abc7a..f151a6f6d89e 100644
--- a/arch/arm/mach-s3c/Kconfig.s3c24xx
+++ b/arch/arm/mach-s3c/Kconfig.s3c24xx
@@ -6,7 +6,7 @@
# Copyright 2007 Simtec Electronics
menuconfig ARCH_S3C24XX
- bool "Samsung S3C24XX SoCs"
+ bool "Samsung S3C24XX SoCs (deprecated, see help)"
depends on ARCH_MULTI_V4T || ARCH_MULTI_V5
depends on CPU_LITTLE_ENDIAN
select ATAGS
@@ -22,6 +22,11 @@ menuconfig ARCH_S3C24XX
(<http://www.simtec.co.uk/products/EB110ITX/>), the IPAQ 1940 or the
Samsung SMDK2410 development board (and derivatives).
+ The platform is deprecated and scheduled for removal. Please reach to
+ the maintainers of the platform and linux-samsung-soc@vger.kernel.org if
+ you still use it.
+ Without such feedback, the platform will be removed after 2022.
+
if ARCH_S3C24XX
config PLAT_S3C24XX
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] iommu/arm-smmu-v3: Fix size calculation in arm_smmu_mm_invalidate_range()
From: Jason Gunthorpe @ 2022-04-19 23:10 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jean-philippe, jacob.jun.pan, baolu.lu,
fenghua.yu, rikard.falkeborn, linux-arm-kernel, iommu,
linux-kernel, stable
In-Reply-To: <20220419210158.21320-1-nicolinc@nvidia.com>
On Tue, Apr 19, 2022 at 02:01:58PM -0700, Nicolin Chen wrote:
> The arm_smmu_mm_invalidate_range function is designed to be called
> by mm core for Shared Virtual Addressing purpose between IOMMU and
> CPU MMU. However, the ways of two subsystems defining their "end"
> addresses are slightly different. IOMMU defines its "end" address
> using the last address of an address range, while mm core defines
> that using the following address of an address range:
>
> include/linux/mm_types.h:
> unsigned long vm_end;
> /* The first byte after our end address ...
>
> This mismatch resulted in an incorrect calculation for size so it
> failed to be page-size aligned. Further, it caused a dead loop at
> "while (iova < end)" check in __arm_smmu_tlb_inv_range function.
>
> This patch fixes the issue by doing the calculation correctly.
>
> Fixes: 2f7e8c553e98d ("iommu/arm-smmu-v3: Hook up ATC invalidation to mm ops")
> Cc: stable@vger.kernel.org
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> - size_t size = end - start + 1;
> + size_t size;
> +
> + /*
> + * The mm_types defines vm_end as the first byte after the end address,
> + * different from IOMMU subsystem using the last address of an address
> + * range. So do a simple translation here by calculating size correctly.
> + */
> + size = end - start;
I would skip the comment though
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] perf/arm-cmn: Add CMN-650 support
From: Ilkka Koskinen @ 2022-04-19 23:05 UTC (permalink / raw)
To: Robin Murphy; +Cc: will, mark.rutland, linux-arm-kernel
In-Reply-To: <b0adc5824db53f71a2b561c293e2120390106536.1650320598.git.robin.murphy@arm.com>
Hi Robin,
I need to go through your patches more carefully, but I do have a couple
of comments already:
On Mon, 18 Apr 2022, Robin Murphy wrote:
> Add the identifiers and events for CMN-650, which slots into its
> evolutionary position between CMN-600 and the 700-series products.
> Imagine CMN-600 made bigger, and with most of the rough edges smoothed
> off, but that then balanced out by some bonkers PMU functionality for
> the new HN-P enhancement in CMN-650r2.
>
> Most of the CXG events are actually common to newer revisions of CMN-600
> too, so they're arguably a little late; oh well.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/perf/arm-cmn.c | 222 ++++++++++++++++++++++++++++++++---------
> 1 file changed, 176 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
> index 9c1d82be7a2f..cce8516d465c 100644
> --- a/drivers/perf/arm-cmn.c
> +++ b/drivers/perf/arm-cmn.c
> @@ -39,7 +39,7 @@
> #define CMN_CHILD_NODE_ADDR GENMASK(27, 0)
> #define CMN_CHILD_NODE_EXTERNAL BIT(31)
>
> -#define CMN_MAX_DIMENSION 8
> +#define CMN_MAX_DIMENSION 12
I wonder if it made sense to dynamically allocate the arrays later in the
code instead of allocating them in stack, especially if mesh topologies
keeps growing fast. That would probably avoid setting max dimension
altogether if one could use num_xps, num_dns etc. Just for future
thoughts...
> #define CMN_MAX_XPS (CMN_MAX_DIMENSION * CMN_MAX_DIMENSION)
> #define CMN_MAX_DTMS (CMN_MAX_XPS + (CMN_MAX_DIMENSION - 1) * 4)
<snip>
> @@ -1692,8 +1802,13 @@ static int arm_cmn_discover(struct arm_cmn *cmn, unsigned int rgn_offset)
> cmn->num_dns += FIELD_GET(CMN_CI_CHILD_COUNT, reg);
How about checking if child count is bigger than the maximum mesh size
before this for loop? It would help in case someone would work on enabling
support for new, bigger models and would forget to update
CMN_MAX_DIMENSION...
> }
>
> - /* Cheeky +1 to help terminate pointer-based iteration later */
> - dn = devm_kcalloc(cmn->dev, cmn->num_dns + 1, sizeof(*dn), GFP_KERNEL);
> + /*
> + * Some nodes effectively have two separate types, which we'll handle
> + * by creating one of each internally. For a (very) safe initial upper
> + * bound, account for double the number of non-XP nodes.
> + */
> + dn = devm_kcalloc(cmn->dev, cmn->num_dns * 2 - cmn->num_xps,
> + sizeof(*dn), GFP_KERNEL);
> if (!dn)
> return -ENOMEM;
>
<snip>
> @@ -1970,6 +2098,7 @@ static int arm_cmn_remove(struct platform_device *pdev)
> #ifdef CONFIG_OF
> static const struct of_device_id arm_cmn_of_match[] = {
> { .compatible = "arm,cmn-600", .data = (void *)CMN600 },
> + { .compatible = "arm,cmn-650", .data = (void *)CMN650 },
> { .compatible = "arm,ci-700", .data = (void *)CI700 },
> {}
> };
> @@ -1979,6 +2108,7 @@ MODULE_DEVICE_TABLE(of, arm_cmn_of_match);
> #ifdef CONFIG_ACPI
> static const struct acpi_device_id arm_cmn_acpi_match[] = {
> { "ARMHC600", CMN600 },
> + { "ARMHC650", CMN650 },
Not the great place for this comment but there probably isn't any better.
Based on DEN0093 v1.1, CMN's DSDT entries have been changed since CMN-600.
ROOTNODEBASE seems to be specific for CMN-600. Moreover, if you compare
the address maps in TRMs' Discovery chapters, you can see the difference.
I'm thinking, at the minimal the second platform_get_resource() call has
to be skipped and zero returned in arm_cmn600_acpi_probe(), if the model
is cmn650 (probably also for cmn-700)
> {}
> };
> MODULE_DEVICE_TABLE(acpi, arm_cmn_acpi_match);
Cheers, Ilkka
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 2/6] dt-bindings: auxdisplay: Add Titan Micro Electronics TM1628
From: Robin Murphy @ 2022-04-19 23:04 UTC (permalink / raw)
To: Heiner Kallweit, Krzysztof Kozlowski, Rob Herring,
Krzysztof Kozlowski, Andreas Färber, Miguel Ojeda
Cc: linux-spi@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
open list:ARM/Amlogic Meson..., Jerome Brunet,
Martin Blumenstingl, Kevin Hilman, Neil Armstrong,
Geert Uytterhoeven
In-Reply-To: <5fde764f-4caf-8017-3cbd-3918f3390b6a@gmail.com>
On 2022-03-30 06:54, Heiner Kallweit wrote:
> On 23.03.2022 21:33, Heiner Kallweit wrote:
>> On 21.03.2022 09:34, Krzysztof Kozlowski wrote:
>>> On 18/03/2022 21:50, Robin Murphy wrote:
>>>> On 2022-02-25 21:13, Heiner Kallweit wrote:
>>>>> Add a YAML schema binding for TM1628 auxdisplay
>>>>> (7/11-segment LED) controller.
>>>>>
>>>>> This patch is partially based on previous work from
>>>>> Andreas Färber <afaerber@suse.de>.
>>>>>
>>>>> Co-developed-by: Andreas Färber <afaerber@suse.de>
>>>>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>>>> ---
>>>>> v5:
>>>>> - add vendor prefix to driver-specific properties
>>>>> ---
>>>>> .../bindings/auxdisplay/titanmec,tm1628.yaml | 92 +++++++++++++++++++
>>>>> 1 file changed, 92 insertions(+)
>>>>> create mode 100644 Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml
>>>>> new file mode 100644
>>>>> index 000000000..2a1ef692c
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/auxdisplay/titanmec,tm1628.yaml
>>>>> @@ -0,0 +1,92 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/auxdisplay/titanmec,tm1628.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: Titan Micro Electronics TM1628 LED controller
>>>>> +
>>>>> +maintainers:
>>>>> + - Andreas Färber <afaerber@suse.de>
>>>>> + - Heiner Kallweit <hkallweit1@gmail.com>
>>>>> +
>>>>> +allOf:
>>>>> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
>>>>> +
>>>>> +properties:
>>>>> + compatible:
>>>>> + const: titanmec,tm1628
>>>>> +
>>>>> + reg:
>>>>> + maxItems: 1
>>>>> +
>>>>> + titanmec,grid:
>>>>> + description:
>>>>> + Mapping of display digit position to grid number.
>>>>> + This implicitly defines the display size.
>>>>> + $ref: /schemas/types.yaml#/definitions/uint8-array
>>>>> + minItems: 1
>>>>> + maxItems: 7
>>>>> +
>>>>> + titanmec,segment-mapping:
>>>>> + description:
>>>>> + Mapping of 7 segment display segments A-G to bit numbers 1-12.
>>>>> + $ref: /schemas/types.yaml#/definitions/uint8-array
>>>>> + minItems: 7
>>>>> + maxItems: 7
>>>>> +
>>>>> + "#address-cells":
>>>>> + const: 2
>>>>> +
>>>>> + "#size-cells":
>>>>> + const: 0
>>>>> +
>>>>> +required:
>>>>> + - compatible
>>>>> + - reg
>>>>
>>>> Would it be fair to say that "spi-lsb-first" and "spi-3wire" are also
>>>> required? The chips aren't configurable so won't exactly be usable any
>>>> other way. Furthermore I believe the transmission format actually works
>>>> out equivalent to SPI mode 3, so should warrant "spi-cpha" and
>>>> "spi-cpol" as well.
>>>>
>>>>> +
>>>>> +patternProperties:
>>>>> + "^.*@[1-7],([1-9]|1[0-6])$":
>>>>> + type: object
>>>>> + $ref: /schemas/leds/common.yaml#
>>>>> + unevaluatedProperties: false
>>>>> + description: |
>>>>> + Properties for a single LED.
>>>>> +
>>>>> + properties:
>>>>> + reg:
>>>>> + description: |
>>>>> + 1-based grid number, followed by 1-based segment bit number.
>>>>> + maxItems: 1
>>>>> +
>>>>> + required:
>>>>> + - reg
>>>>
>>>> I'm concerned that this leaves us no room to support the additional
>>>> keypad functionality in future. Having now double-checked a datasheet,
>>>> the inputs are also a two-dimensional mux (sharing the segment lines),
>>>> so the device effectively has two distinct but numerically-overlapping
>>>> child address spaces - one addressed by (grid,segment) and the other by
>>>> (segment,key).
>>>>
>>>> Rob, Krysztof, any thoughts on the best DT idiom to leave accommodation
>>>> for that? I'm thinking either require an intermediate node to contain
>>>> each notional address space, or perhaps add another leading address cell
>>>> to select between them? I don't believe any of these things have further
>>>> functionality beyond that.
>>>
>>> I think intermediate nodes - leds, keys - are more appropriate, because
>>> it is self-describing. Additional address space number would require
>>> decoding this "0" or "1" into LED/key. For complex devices - like PMICs
>>> with regulators, RTC and clocks - we already have such patterns.
>>>
>> Then it's just the question who can implement such an intermediate node
>> based on what has been done so far.
>>
> As it is now it seems we end up with empty hands again and have to wait
> further two years for the next one to make an attempt.
> That's a pity because for most users the relevant use cases are supported.
Or, y'know, we could just reach a productive conclusion rather than
doom-and-gloom catastrophising. I apologise for not having much time for
non-work-related kernel hacking at the moment, but it didn't seem
particularly urgent to follow up on this in the middle of a merge window
anyway. In the course of helpfully being left to address my own review
feedback, I did eventually get round to implementing the intermediate
"leds" node[1] last weekend, but having now stumbled across the
matrix-keymap helpers and common "linux,keymap" property, I'm personally
inclined to think that that's even cleaner than a "keys" node with
children that we'd have to write more parsing code for, and thus may
well make the whole intermediate node notion moot anyway. If only anyone
had pointed it out sooner...
Thanks,
Robin.
[1] https://gitlab.arm.com/linux-arm/linux-rm/-/commits/tm1628
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] rtc: ftrtc010: Fix error handling in ftrtc010_rtc_probe
From: Linus Walleij @ 2022-04-19 22:55 UTC (permalink / raw)
To: Miaoqian Lin
Cc: Hans Ulli Kroll, Alessandro Zummo, Alexandre Belloni,
linux-arm-kernel, linux-rtc, linux-kernel
In-Reply-To: <20220403054912.31739-1-linmq006@gmail.com>
On Sun, Apr 3, 2022 at 7:49 AM Miaoqian Lin <linmq006@gmail.com> wrote:
> In the error handling path, the clk_prepare_enable() function
> call should be balanced by a corresponding 'clk_disable_unprepare()'
> call , as already done in the remove function.
>
> clk_disable_unprepare calls clk_disable() and clk_unprepare().
> They will use IS_ERR_OR_NULL to check the argument.
>
> Fixes: ac05fba39cc5 ("rtc: gemini: Add optional clock handling")
> Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Looks correct!
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] spi: add SPI_RX_CPHA_FLIP mode bit
From: Mark Brown @ 2022-04-19 22:45 UTC (permalink / raw)
To: baruch
Cc: linux-arm-kernel, festevam, Sascha Hauer, linux-spi, linux-imx,
baruch.siach, shawnguo, kernel
In-Reply-To: <a715ca92713ca02071f33dcca9960a66a03c949a.1649702729.git.baruch@tkos.co.il>
On Mon, 11 Apr 2022 21:45:27 +0300, Baruch Siach wrote:
> From: Baruch Siach <baruch.siach@siklu.com>
>
> Some SPI devices latch MOSI bits on one clock phase, but produce valid
> MISO bits on the other phase. Add SPI_RX_CPHA_FLIP mode to instruct the
> controller driver to flip CPHA for Rx (MISO) only transfers.
>
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/3] spi: add SPI_RX_CPHA_FLIP mode bit
commit: b617be33502d2bfefffef71924c7a7ba50264ff6
[2/3] spi: spidev: add SPI_RX_CPHA_FLIP
commit: 178d0cbbfe8ec652083058968c7a27485eaa33d2
[3/3] spi: spi-imx: add support for SPI_RX_CPHA_FLIP
commit: 79422ed9bd7fbd79f84d8a5abb0094c16221f55b
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] pinctrl: meson: fix unused variable warning
From: Linus Walleij @ 2022-04-19 22:42 UTC (permalink / raw)
To: Qianggui Song
Cc: linux-gpio, kernel test robot, Neil Armstrong, Jerome Brunet,
Kevin Hilman, Martin Blumenstingl, linux-arm-kernel,
linux-amlogic, linux-kernel
In-Reply-To: <20220330023720.18238-1-qianggui.song@amlogic.com>
On Wed, Mar 30, 2022 at 4:38 AM Qianggui Song <qianggui.song@amlogic.com> wrote:
> The kernel test robot reported a warning as below:
> >> drivers/pinctrl/meson/pinctrl-meson-s4.c:178:27: warning: unused variable 'tdm_sclk1_c_pins' [-Wunused-const-variable]
> static const unsigned int tdm_sclk1_c_pins[] = { GPIOC_3 };
>
> Fix it by adding missing description about this pins
>
> Fixes: 775214d389c2 ("pinctrl: meson: add pinctrl driver support for Meson-S4 Soc")
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Qianggui Song <qianggui.song@amlogic.com>
Patch applied!
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: mt8195: enable driver on mtk platforms
From: Linus Walleij @ 2022-04-19 22:40 UTC (permalink / raw)
To: Fabien Parent
Cc: Sean Wang, Matthias Brugger, Zhiyong Tao, linux-mediatek,
linux-gpio, linux-kernel, linux-arm-kernel
In-Reply-To: <20220327160813.2978637-1-fparent@baylibre.com>
On Sun, Mar 27, 2022 at 6:08 PM Fabien Parent <fparent@baylibre.com> wrote:
> Set the pinctrl driver as built-in by default if
> ARM64 and ARCH_MEDIATEK are enabled.
>
> Fixes: 6cf5e9ef362a ("pinctrl: add pinctrl driver on mt8195")
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
Patch applied!
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/4] rockchip: support configuring pins as input
From: Linus Walleij @ 2022-04-19 22:37 UTC (permalink / raw)
To: Caleb Connolly
Cc: Rob Herring, Heiko Stuebner, Bartosz Golaszewski, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-gpio,
~postmarketos/upstreaming, martijn, Arnaud Ferraris
In-Reply-To: <20220328005005.72492-1-kc@postmarketos.org>
Hi Caleb,
On Mon, Mar 28, 2022 at 2:50 AM Caleb Connolly <kc@postmarketos.org> wrote:
Caleb Connolly (4):
> pinctrl/rockchip: support deferring other gpio params
> pinctrl/rockchip: support setting input-enable param
> gpio/rockchip: handle deferring input-enable pinconfs
Those three applied to the pinctrl tree.
> arm64: dts: rockchip: rk3399: add an input enable pinconf
Please submit this through the SoC tree.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox