Re: [PATCH v2] ARM: dts: mvebu: Add device tree for ATL-x530 Board

2021-04-07 Thread Gregory CLEMENT
_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> + sda-gpio = < 3 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> +
> + i2c0mux: mux@71 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "nxp,pca9544";
> + reg = <0x71>;
> + i2c-mux-idle-disconnect;
> +
> + i2c@0 { /* POE devices MUX */
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + };
> +
> + i2c@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + adt7476_2e: hwmon@2e {
> + compatible = "adi,adt7476";
> + reg = <0x2e>;
> + };
> +
> + adt7476_2d: hwmon@2d {
> + compatible = "adi,adt7476";
> + reg = <0x2d>;
> + };
> + };
> +
> + i2c@2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <2>;
> +
> + rtc@68 {
> + compatible = "dallas,ds1340";
> + reg = <0x68>;
> + };
> + };
> +
> + i2c@3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <3>;
> +
> + gpio@20 {
> + compatible = "nxp,pca9554";
> + gpio-controller;
> + #gpio-cells = <2>;
> + reg = <0x20>;
> + };
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + status = "okay";
> +
> + spi-flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "jedec,spi-nor";
> + reg = <1>; /* Chip select 1 */
> + spi-max-frequency = <5400>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@u-boot {
> + reg = <0x 0x0010>;
> + label = "u-boot";
> + };
> + partition@u-boot-env {
> + reg = <0x0010 0x0004>;
> + label = "u-boot-env";
> + };
> + partition@unused {
> + reg = <0x0014 0x00e8>;
> + label = "unused";
> + };
> + partition@idprom {
> + reg = <0x00fc 0x0004>;
> + label = "idprom";
> + };
> + };
> + };
> +};
> +
> +_controller {
> + status = "okay";
> +
> + nand@0 {
> + reg = <0>;
> + label = "pxa3xx_nand-0";
> + nand-rb = <0>;
> + nand-on-flash-bbt;
> + nand-ecc-strength = <4>;
> + nand-ecc-step-size = <512>;
> +
> + marvell,nand-enable-arbiter;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@user {
> + reg = <0x 0x0f00>;
> + label = "user";
> + };
> + partition@errlog {
> + /* Maximum mtdoops size is 8MB, so set to that. 
> */
> + reg = <0x0f00 0x0080>;
> + label = "errlog";
> + };
> + partition@nand-bbt {
> + reg = <0x0f80 0x0080>;
> + label = "nand-bbt";
> + };
> + };
> + };
> +};
> +
> -- 
> 2.29.2
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v3 0/5] Add support for CP110 UTMI PHY

2021-04-02 Thread Gregory CLEMENT
Hi Kosta,

> From: Konstantin Porotchkin 
>
> This series of patches adds a new PHY driver for supporting CP110 UTMI
> PHY in Linux. Currently the functionality of USB ports connected to
> this PHY depends on boot loader setup.
> The new driver eliminates kernel configuration dependency from the boot
> loader. 
>
> v3:
> - rebase on top of Linux 5.12-rc2
> - convert Armada 3700 UTMI PHY DT binding document to YAML schema
> - create a separate DT binding for Armada CP11x UTMI PHY in YAML format
> - change UTMI PHY port node names from "phy" to "usb-phy"
>
> v2:
> - extend the comment about reference clock 
> - fix driver probe function, add some prints
> - move to usage of dr_mode from connected USB controller instead of
>   dedicated device tree property
>
> Konstantin Porotchkin (5):
>   drivers: phy: add support for Armada CP110 UTMI PHY
>   dt-bindings: phy: convert phy-mvebu-utmi to YAML schema
>   devicetree/bindings: add support for CP110 UTMI PHY
>   arch/arm64: dts: add support for Marvell CP110 UTMI PHY
>   arch/arm64: dts: enable CP110 UTMI PHY usage

Patch 4 and 5 applied on mvebu/dt64.

I've just modified the title to align with the other commits in
arch/arm64/boot/dts/marvell. They now begin by "arm64: dts: marvell:".

Thanks,

Gregory


>
>  .../phy/marvell,armada-3700-utmi-phy.yaml |  57 +++
>  .../phy/marvell,armada-cp110-utmi-phy.yaml| 109 +
>  .../bindings/phy/phy-mvebu-utmi.txt   |  38 --
>  .../arm64/boot/dts/marvell/armada-7040-db.dts |  14 +-
>  .../arm64/boot/dts/marvell/armada-8040-db.dts |  21 +-
>  .../boot/dts/marvell/armada-8040-mcbin.dtsi   |  19 +-
>  arch/arm64/boot/dts/marvell/armada-cp11x.dtsi |  19 +
>  arch/arm64/boot/dts/marvell/cn9130-db.dts |  12 +-
>  arch/arm64/boot/dts/marvell/cn9131-db.dts |   9 +-
>  arch/arm64/boot/dts/marvell/cn9132-db.dts |  11 +-
>  drivers/phy/marvell/Kconfig   |   8 +
>  drivers/phy/marvell/Makefile  |   1 +
>  drivers/phy/marvell/phy-mvebu-cp110-utmi.c| 384 ++
>  13 files changed, 650 insertions(+), 52 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/marvell,armada-3700-utmi-phy.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/phy/marvell,armada-cp110-utmi-phy.yaml
>  delete mode 100644 Documentation/devicetree/bindings/phy/phy-mvebu-utmi.txt
>  create mode 100644 drivers/phy/marvell/phy-mvebu-cp110-utmi.c
>
> -- 
> 2.17.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH] ARM: dts: turris-omnia: fix hardware buffer management

2021-04-02 Thread Gregory CLEMENT
Hi Rui,

> Hardware buffer management has never worked on the Turris Omnia, as the
> required MBus window hadn't been reserved. Fix thusly.
>
> Fixes: 018b88eee1a2 ("ARM: dts: turris-omnia: enable HW buffer management")
>
> Signed-off-by: Rui Salvaterra 

Applied on mvebu/fixes

Thanks,

Gregory

> ---
>  arch/arm/boot/dts/armada-385-turris-omnia.dts | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts 
> b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> index 646a06420c77..dc80a909ea88 100644
> --- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> @@ -32,7 +32,8 @@ soc {
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10
> MBUS_ID(0x09, 0x19) 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x15) 0 0xf111 0x1>;
> +   MBUS_ID(0x09, 0x15) 0 0xf111 0x1
> +   MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
>  
>   internal-regs {
>  
> -- 
> 2.30.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH mvebu v2 01/10] arm64: dts: marvell: armada-37xx: add syscon compatible to NB clk node

2021-04-02 Thread Gregory CLEMENT
Hi Pali,

> From: Marek Behún 
>
> Add "syscon" compatible to the North Bridge clocks node to allow the
> cpufreq driver to access these registers via syscon API.
>
> This is needed for a fix of cpufreq driver.
>
> Signed-off-by: Marek Behún 
> Fixes: e8d66e7927b2 ("arm64: dts: marvell: armada-37xx: add nodes...")
> Cc: sta...@vger.kernel.org
> Cc: Gregory CLEMENT 
> Cc: Miquel Raynal 

Applied on mvebu/dt64

Thanks,

Gregory

> ---
>  arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index d5b6c0a1c54a..a89e47d95eef 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -156,7 +156,8 @@
>   };
>  
>   nb_periph_clk: nb-periph-clk@13000 {
> - compatible = 
> "marvell,armada-3700-periph-clock-nb";
> + compatible = 
> "marvell,armada-3700-periph-clock-nb",
> +  "syscon";
>   reg = <0x13000 0x100>;
>   clocks = < 0>, < 1>, < 2>,
>   < 3>, <>;
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH mvebu v3 05/10] clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to 1 GHz

2021-03-29 Thread Gregory CLEMENT
Pali Rohár  writes:

> It was observed that the workaround introduced by commit 61c40f35f5cd
> ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to
> 1.2GHz") when base CPU frequency is 1.2 GHz is also required when base
> CPU frequency is 1 GHz. Otherwise switching CPU frequency directly from
> L2 (250 MHz) to L0 (1 GHz) causes a crash.
>
> When base CPU frequency is just 800 MHz no crashed were observed during
> switch from L2 to L0.
>
> Signed-off-by: Pali Rohár 
> Acked-by: Stephen Boyd 
> Tested-by: Tomasz Maciej Nowak 
> Tested-by: Anders Trier Olesen 
> Tested-by: Philip Soares 
> Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for 
> cpu clocks")
> Cc: sta...@vger.kernel.org # 61c40f35f5cd ("clk: mvebu: armada-37xx-periph: 
> Fix switching CPU rate from 300Mhz to 1.2GHz")


Acked-by: Gregory CLEMENT 

Thanks,

Gregory

> ---
>  drivers/clk/mvebu/armada-37xx-periph.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/mvebu/armada-37xx-periph.c 
> b/drivers/clk/mvebu/armada-37xx-periph.c
> index 6507bd2c5f31..b15e177bea7e 100644
> --- a/drivers/clk/mvebu/armada-37xx-periph.c
> +++ b/drivers/clk/mvebu/armada-37xx-periph.c
> @@ -487,8 +487,10 @@ static long clk_pm_cpu_round_rate(struct clk_hw *hw, 
> unsigned long rate,
>  }
>  
>  /*
> - * Switching the CPU from the L2 or L3 frequencies (300 and 200 Mhz
> - * respectively) to L0 frequency (1.2 Ghz) requires a significant
> + * Workaround when base CPU frequnecy is 1000 or 1200 MHz
> + *
> + * Switching the CPU from the L2 or L3 frequencies (250/300 or 200 MHz
> + * respectively) to L0 frequency (1/1.2 GHz) requires a significant
>   * amount of time to let VDD stabilize to the appropriate
>   * voltage. This amount of time is large enough that it cannot be
>   * covered by the hardware countdown register. Due to this, the CPU
> @@ -498,15 +500,15 @@ static long clk_pm_cpu_round_rate(struct clk_hw *hw, 
> unsigned long rate,
>   * To work around this problem, we prevent switching directly from the
>   * L2/L3 frequencies to the L0 frequency, and instead switch to the L1
>   * frequency in-between. The sequence therefore becomes:
> - * 1. First switch from L2/L3(200/300MHz) to L1(600MHZ)
> + * 1. First switch from L2/L3 (200/250/300 MHz) to L1 (500/600 MHz)
>   * 2. Sleep 20ms for stabling VDD voltage
> - * 3. Then switch from L1(600MHZ) to L0(1200Mhz).
> + * 3. Then switch from L1 (500/600 MHz) to L0 (1000/1200 MHz).
>   */
>  static void clk_pm_cpu_set_rate_wa(unsigned long rate, struct regmap *base)
>  {
>   unsigned int cur_level;
>  
> - if (rate != 1200 * 1000 * 1000)
> + if (rate < 1000 * 1000 * 1000)
>   return;
>  
>   regmap_read(base, ARMADA_37XX_NB_CPU_LOAD, _level);
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH mvebu v3 04/10] cpufreq: armada-37xx: Fix the AVS value for load L1

2021-03-29 Thread Gregory CLEMENT
Pali Rohár  writes:

> The original CPU voltage value for load L1 is too low for Armada 37xx SoC
> when base CPU frequency is 1000 or 1200 MHz. It leads to instabilities
> where CPU gets stuck soon after dynamic voltage scaling from load L1 to L0.
>
> Update the CPU voltage value for load L1 accordingly when base frequency is
> 1000 or 1200 MHz. The minimal L1 value for base CPU frequency 1000 MHz is
> updated from the original 1.05V to 1.108V and for 1200 MHz is updated to
> 1.155V. This minimal L1 value is used only in the case when it is lower
> than value for L0.
>
> This change fixes CPU instability issues on 1 GHz and 1.2 GHz variants of
> Espressobin and 1 GHz Turris Mox.
>
> Marvell previously for 1 GHz variant of Espressobin provided a patch [1]
> suitable only for their Marvell Linux kernel 4.4 fork which workarounded
> this issue. Patch forced CPU voltage value to 1.108V in all loads. But
> such change does not fix CPU instability issues on 1.2 GHz variants of
> Armada 3720 SoC.
>
> During testing we come to the conclusion that using 1.108V as minimal
> value for L1 load makes 1 GHz variants of Espressobin and Turris Mox boards
> stable. And similarly 1.155V for 1.2 GHz variant of Espressobin.
>
> These two values 1.108V and 1.155V are documented in Armada 3700 Hardware
> Specifications as typical initial CPU voltage values.
>
> Discussion about this issue is also at the Armbian forum [2].
>
> [1] - 
> https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/dc33b62c90696afb6adc7dbcc4ebbd48bedec269
> [2] - https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/
>
> Signed-off-by: Pali Rohár 
> Tested-by: Tomasz Maciej Nowak 
> Tested-by: Anders Trier Olesen 
> Tested-by: Philip Soares 
> Fixes: 1c3528232f4b ("cpufreq: armada-37xx: Add AVS support")
> Cc: sta...@vger.kernel.org

Acked-by: Gregory CLEMENT 

Thanks,

Gregory
> ---
>  drivers/cpufreq/armada-37xx-cpufreq.c | 37 +++
>  1 file changed, 37 insertions(+)
>
> diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c 
> b/drivers/cpufreq/armada-37xx-cpufreq.c
> index b8dc6c849579..c7683d447b11 100644
> --- a/drivers/cpufreq/armada-37xx-cpufreq.c
> +++ b/drivers/cpufreq/armada-37xx-cpufreq.c
> @@ -73,6 +73,8 @@
>  #define LOAD_LEVEL_NR4
>  
>  #define MIN_VOLT_MV 1000
> +#define MIN_VOLT_MV_FOR_L1_1000MHZ 1108
> +#define MIN_VOLT_MV_FOR_L1_1200MHZ 1155
>  
>  /*  AVS value for the corresponding voltage (in mV) */
>  static int avs_map[] = {
> @@ -208,6 +210,8 @@ static u32 armada_37xx_avs_val_match(int target_vm)
>   * - L2 & L3 voltage should be about 150mv smaller than L0 voltage.
>   * This function calculates L1 & L2 & L3 AVS values dynamically based
>   * on L0 voltage and fill all AVS values to the AVS value table.
> + * When base CPU frequency is 1000 or 1200 MHz then there is additional
> + * minimal avs value for load L1.
>   */
>  static void __init armada37xx_cpufreq_avs_configure(struct regmap *base,
>   struct armada_37xx_dvfs *dvfs)
> @@ -239,6 +243,19 @@ static void __init 
> armada37xx_cpufreq_avs_configure(struct regmap *base,
>   for (load_level = 1; load_level < LOAD_LEVEL_NR; load_level++)
>   dvfs->avs[load_level] = avs_min;
>  
> + /*
> +  * Set the avs values for load L0 and L1 when base CPU frequency
> +  * is 1000/1200 MHz to its typical initial values according to
> +  * the Armada 3700 Hardware Specifications.
> +  */
> + if (dvfs->cpu_freq_max >= 1000*1000*1000) {
> + if (dvfs->cpu_freq_max >= 1200*1000*1000)
> + avs_min = 
> armada_37xx_avs_val_match(MIN_VOLT_MV_FOR_L1_1200MHZ);
> + else
> + avs_min = 
> armada_37xx_avs_val_match(MIN_VOLT_MV_FOR_L1_1000MHZ);
> + dvfs->avs[0] = dvfs->avs[1] = avs_min;
> + }
> +
>   return;
>   }
>  
> @@ -258,6 +275,26 @@ static void __init 
> armada37xx_cpufreq_avs_configure(struct regmap *base,
>   target_vm = avs_map[l0_vdd_min] - 150;
>   target_vm = target_vm > MIN_VOLT_MV ? target_vm : MIN_VOLT_MV;
>   dvfs->avs[2] = dvfs->avs[3] = armada_37xx_avs_val_match(target_vm);
> +
> + /*
> +  * Fix the avs value for load L1 when base CPU frequency is 1000/1200 
> MHz,
> +  * otherwise the CPU gets stuck when switching from load L1 to load L0.
> +  * Also ensure that avs value for load L1 is not higher than for L0.
> +  */
> + if (dvfs->cpu_freq_max >= 

Re: [PATCH mvebu v2 09/10] cpufreq: armada-37xx: Remove cur_frequency variable

2021-03-29 Thread Gregory CLEMENT
Pali Rohár  writes:

> Variable cur_frequency in armada37xx_cpufreq_driver_init() is unused.
>
> Signed-off-by: Pali Rohár 

Acked-by: Gregory CLEMENT 

Thanks,

Gregory

> ---
>  drivers/cpufreq/armada-37xx-cpufreq.c | 10 +-
>  1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c 
> b/drivers/cpufreq/armada-37xx-cpufreq.c
> index f08281fc525c..f13646d143de 100644
> --- a/drivers/cpufreq/armada-37xx-cpufreq.c
> +++ b/drivers/cpufreq/armada-37xx-cpufreq.c
> @@ -389,7 +389,7 @@ static int __init armada37xx_cpufreq_driver_init(void)
>   struct armada_37xx_dvfs *dvfs;
>   struct platform_device *pdev;
>   unsigned long freq;
> - unsigned int cur_frequency, base_frequency;
> + unsigned int base_frequency;
>   struct regmap *nb_clk_base, *nb_pm_base, *avs_base;
>   struct device *cpu_dev;
>   int load_lvl, ret;
> @@ -450,14 +450,6 @@ static int __init armada37xx_cpufreq_driver_init(void)
>   return -EINVAL;
>   }
>  
> - /* Get nominal (current) CPU frequency */
> - cur_frequency = clk_get_rate(clk);
> - if (!cur_frequency) {
> - dev_err(cpu_dev, "Failed to get clock rate for CPU\n");
> - clk_put(clk);
> - return -EINVAL;
> - }
> -
>   dvfs = armada_37xx_cpu_freq_info_get(base_frequency);
>   if (!dvfs) {
>   clk_put(clk);
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH mvebu v3 08/10] cpufreq: armada-37xx: Fix determining base CPU frequency

2021-03-29 Thread Gregory CLEMENT
Pali Rohár  writes:

> When current CPU load is not L0 then loading armada-37xx-cpufreq.ko driver
> fails with following error:
>
> # modprobe armada-37xx-cpufreq
> [  502.702097] Unsupported CPU frequency 250 MHz
>
> This issue was partially fixed by commit 8db82563451f ("cpufreq:
> armada-37xx: fix frequency calculation for opp"), but only for calculating
> CPU frequency for opp.
>
> Fix this also for determination of base CPU frequency.
>
> Signed-off-by: Pali Rohár 
> Tested-by: Tomasz Maciej Nowak 
> Tested-by: Anders Trier Olesen 
> Tested-by: Philip Soares 
> Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx")
> Cc: sta...@vger.kernel.org # 8db82563451f ("cpufreq: armada-37xx: fix
> frequency calculation for opp")

Acked-by: Gregory CLEMENT 

Thanks,

Gregory

> ---
>  drivers/cpufreq/armada-37xx-cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c 
> b/drivers/cpufreq/armada-37xx-cpufreq.c
> index 1ab2113daef5..e4782f562e7a 100644
> --- a/drivers/cpufreq/armada-37xx-cpufreq.c
> +++ b/drivers/cpufreq/armada-37xx-cpufreq.c
> @@ -469,7 +469,7 @@ static int __init armada37xx_cpufreq_driver_init(void)
>   return -EINVAL;
>   }
>  
> - dvfs = armada_37xx_cpu_freq_info_get(cur_frequency);
> + dvfs = armada_37xx_cpu_freq_info_get(base_frequency);
>   if (!dvfs) {
>   clk_put(clk);
>   return -EINVAL;
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH mvebu v3 07/10] cpufreq: armada-37xx: Fix driver cleanup when registration failed

2021-03-29 Thread Gregory CLEMENT
Pali Rohár  writes:

> Commit 8db82563451f ("cpufreq: armada-37xx: fix frequency calculation for
> opp") changed calculation of frequency passed to the dev_pm_opp_add()
> function call. But the code for dev_pm_opp_remove() function call was not
> updated, so the driver cleanup phase does not work when registration fails.
>
> This fixes the issue by using the same frequency in both calls.
>
> Signed-off-by: Pali Rohár 
> Tested-by: Tomasz Maciej Nowak 
> Tested-by: Anders Trier Olesen 
> Tested-by: Philip Soares 
> Fixes: 8db82563451f ("cpufreq: armada-37xx: fix frequency calculation for 
> opp")
> Cc: sta...@vger.kernel.org

Acked-by: Gregory CLEMENT 

Thanks,

Gregory
> ---
>  drivers/cpufreq/armada-37xx-cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c 
> b/drivers/cpufreq/armada-37xx-cpufreq.c
> index c7683d447b11..1ab2113daef5 100644
> --- a/drivers/cpufreq/armada-37xx-cpufreq.c
> +++ b/drivers/cpufreq/armada-37xx-cpufreq.c
> @@ -521,7 +521,7 @@ static int __init armada37xx_cpufreq_driver_init(void)
>  remove_opp:
>   /* clean-up the already added opp before leaving */
>   while (load_lvl-- > ARMADA_37XX_DVFS_LOAD_0) {
> - freq = cur_frequency / dvfs->divider[load_lvl];
> + freq = base_frequency / dvfs->divider[load_lvl];
>   dev_pm_opp_remove(cpu_dev, freq);
>   }
>  
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH mvebu v3 06/10] clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 to L0

2021-03-29 Thread Gregory CLEMENT
Pali Rohár  writes:

> When CPU frequency is at 250 MHz and set_rate() is called with 500 MHz (L1)
> quickly followed by a call with 1 GHz (L0), the CPU does not necessarily
> stay in L1 for at least 20ms as is required by Marvell errata.
>
> This situation happens frequently with the ondemand cpufreq governor and
> can be also reproduced with userspace governor. In most cases it causes CPU
> to crash.
>
> This change fixes the above issue and ensures that the CPU always stays in
> L1 for at least 20ms when switching from any state to L0.
>
> Signed-off-by: Marek Behún 
> Signed-off-by: Pali Rohár 
> Acked-by: Stephen Boyd 
> Tested-by: Tomasz Maciej Nowak 
> Tested-by: Anders Trier Olesen 
> Tested-by: Philip Soares 
> Fixes: 61c40f35f5cd ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate 
> from 300Mhz to 1.2GHz")
> Cc: sta...@vger.kernel.org

Acked-by: Gregory CLEMENT 

Thanks,

Gregory
> ---
>  drivers/clk/mvebu/armada-37xx-periph.c | 45 ++
>  1 file changed, 39 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clk/mvebu/armada-37xx-periph.c 
> b/drivers/clk/mvebu/armada-37xx-periph.c
> index b15e177bea7e..32ac6b6b7530 100644
> --- a/drivers/clk/mvebu/armada-37xx-periph.c
> +++ b/drivers/clk/mvebu/armada-37xx-periph.c
> @@ -84,6 +84,7 @@ struct clk_pm_cpu {
>   void __iomem *reg_div;
>   u8 shift_div;
>   struct regmap *nb_pm_base;
> + unsigned long l1_expiration;
>  };
>  
>  #define to_clk_double_div(_hw) container_of(_hw, struct clk_double_div, hw)
> @@ -504,22 +505,52 @@ static long clk_pm_cpu_round_rate(struct clk_hw *hw, 
> unsigned long rate,
>   * 2. Sleep 20ms for stabling VDD voltage
>   * 3. Then switch from L1 (500/600 MHz) to L0 (1000/1200 MHz).
>   */
> -static void clk_pm_cpu_set_rate_wa(unsigned long rate, struct regmap *base)
> +static void clk_pm_cpu_set_rate_wa(struct clk_pm_cpu *pm_cpu,
> +unsigned int new_level, unsigned long rate,
> +struct regmap *base)
>  {
>   unsigned int cur_level;
>  
> - if (rate < 1000 * 1000 * 1000)
> - return;
> -
>   regmap_read(base, ARMADA_37XX_NB_CPU_LOAD, _level);
>   cur_level &= ARMADA_37XX_NB_CPU_LOAD_MASK;
> - if (cur_level <= ARMADA_37XX_DVFS_LOAD_1)
> +
> + if (cur_level == new_level)
> + return;
> +
> + /*
> +  * System wants to go to L1 on its own. If we are going from L2/L3,
> +  * remember when 20ms will expire. If from L0, set the value so that
> +  * next switch to L0 won't have to wait.
> +  */
> + if (new_level == ARMADA_37XX_DVFS_LOAD_1) {
> + if (cur_level == ARMADA_37XX_DVFS_LOAD_0)
> + pm_cpu->l1_expiration = jiffies;
> + else
> + pm_cpu->l1_expiration = jiffies + msecs_to_jiffies(20);
>   return;
> + }
> +
> + /*
> +  * If we are setting to L2/L3, just invalidate L1 expiration time,
> +  * sleeping is not needed.
> +  */
> + if (rate < 1000*1000*1000)
> + goto invalidate_l1_exp;
> +
> + /*
> +  * We are going to L0 with rate >= 1GHz. Check whether we have been at
> +  * L1 for long enough time. If not, go to L1 for 20ms.
> +  */
> + if (pm_cpu->l1_expiration && jiffies >= pm_cpu->l1_expiration)
> + goto invalidate_l1_exp;
>  
>   regmap_update_bits(base, ARMADA_37XX_NB_CPU_LOAD,
>  ARMADA_37XX_NB_CPU_LOAD_MASK,
>  ARMADA_37XX_DVFS_LOAD_1);
>   msleep(20);
> +
> +invalidate_l1_exp:
> + pm_cpu->l1_expiration = 0;
>  }
>  
>  static int clk_pm_cpu_set_rate(struct clk_hw *hw, unsigned long rate,
> @@ -553,7 +584,9 @@ static int clk_pm_cpu_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>   reg = ARMADA_37XX_NB_CPU_LOAD;
>   mask = ARMADA_37XX_NB_CPU_LOAD_MASK;
>  
> - clk_pm_cpu_set_rate_wa(rate, base);
> + /* Apply workaround when base CPU frequency is 1000 or 
> 1200 MHz */
> + if (parent_rate >= 1000*1000*1000)
> + clk_pm_cpu_set_rate_wa(pm_cpu, load_level, 
> rate, base);
>  
>   regmap_update_bits(base, reg, mask, load_level);
>  
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH mvebu v3 03/10] clk: mvebu: armada-37xx-periph: remove .set_parent method for CPU PM clock

2021-03-29 Thread Gregory CLEMENT
Pali Rohár  writes:

> From: Marek Behún 
>
> Remove the .set_parent method in clk_pm_cpu_ops.
>
> This method was supposed to be needed by the armada-37xx-cpufreq driver,
> but was never actually called due to wrong assumptions in the cpufreq
> driver. After this was fixed in the cpufreq driver, this method is not
> needed anymore.
>
> Signed-off-by: Marek Behún 
> Acked-by: Stephen Boyd 
> Tested-by: Pali Rohár 
> Tested-by: Tomasz Maciej Nowak 
> Tested-by: Anders Trier Olesen 
> Tested-by: Philip Soares 
> Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for 
> cpu clocks")

Acked-by: Gregory CLEMENT 

Thanks,

Gregory
> ---
>  drivers/clk/mvebu/armada-37xx-periph.c | 28 --
>  1 file changed, 28 deletions(-)
>
> diff --git a/drivers/clk/mvebu/armada-37xx-periph.c 
> b/drivers/clk/mvebu/armada-37xx-periph.c
> index f5746f9ea929..6507bd2c5f31 100644
> --- a/drivers/clk/mvebu/armada-37xx-periph.c
> +++ b/drivers/clk/mvebu/armada-37xx-periph.c
> @@ -440,33 +440,6 @@ static u8 clk_pm_cpu_get_parent(struct clk_hw *hw)
>   return val;
>  }
>  
> -static int clk_pm_cpu_set_parent(struct clk_hw *hw, u8 index)
> -{
> - struct clk_pm_cpu *pm_cpu = to_clk_pm_cpu(hw);
> - struct regmap *base = pm_cpu->nb_pm_base;
> - int load_level;
> -
> - /*
> -  * We set the clock parent only if the DVFS is available but
> -  * not enabled.
> -  */
> - if (IS_ERR(base) || armada_3700_pm_dvfs_is_enabled(base))
> - return -EINVAL;
> -
> - /* Set the parent clock for all the load level */
> - for (load_level = 0; load_level < LOAD_LEVEL_NR; load_level++) {
> - unsigned int reg, mask,  val,
> - offset = ARMADA_37XX_NB_TBG_SEL_OFF;
> -
> - armada_3700_pm_dvfs_update_regs(load_level, , );
> -
> - val = index << offset;
> - mask = ARMADA_37XX_NB_TBG_SEL_MASK << offset;
> - regmap_update_bits(base, reg, mask, val);
> - }
> - return 0;
> -}
> -
>  static unsigned long clk_pm_cpu_recalc_rate(struct clk_hw *hw,
>   unsigned long parent_rate)
>  {
> @@ -592,7 +565,6 @@ static int clk_pm_cpu_set_rate(struct clk_hw *hw, 
> unsigned long rate,
>  
>  static const struct clk_ops clk_pm_cpu_ops = {
>   .get_parent = clk_pm_cpu_get_parent,
> - .set_parent = clk_pm_cpu_set_parent,
>   .round_rate = clk_pm_cpu_round_rate,
>   .set_rate = clk_pm_cpu_set_rate,
>   .recalc_rate = clk_pm_cpu_recalc_rate,
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH mvebu v3 02/10] cpufreq: armada-37xx: Fix setting TBG parent for load levels

2021-03-29 Thread Gregory CLEMENT
Pali Rohár  writes:

> From: Marek Behún 
>
> With CPU frequency determining software [1] we have discovered that
> after this driver does one CPU frequency change, the base frequency of
> the CPU is set to the frequency of TBG-A-P clock, instead of the TBG
> that is parent to the CPU.
>
> This can be reproduced on EspressoBIN and Turris MOX:
>   cd /sys/devices/system/cpu/cpufreq/policy0
>   echo powersave >scaling_governor
>   echo performance >scaling_governor
>
> Running the mhz tool before this driver is loaded reports 1000 MHz, and
> after loading the driver and executing commands above the tool reports
> 800 MHz.
>
> The change of TBG clock selector is supposed to happen in function
> armada37xx_cpufreq_dvfs_setup. Before the function returns, it does
> this:
>   parent = clk_get_parent(clk);
>   clk_set_parent(clk, parent);
>
> The armada-37xx-periph clock driver has the .set_parent method
> implemented correctly for this, so if the method was actually called,
> this would work. But since the introduction of the common clock
> framework in commit b2476490ef11 ("clk: introduce the common clock..."),
> the clk_set_parent function checks whether the parent is actually
> changing, and if the requested new parent is same as the old parent
> (which is obviously the case for the code above), the .set_parent method
> is not called at all.
>
> This patch fixes this issue by filling the correct TBG clock selector
> directly in the armada37xx_cpufreq_dvfs_setup during the filling of
> other registers at the same address. But the determination of CPU TBG
> index cannot be done via the common clock framework, therefore we need
> to access the North Bridge Peripheral Clock registers directly in this
> driver.
>
> [1] https://github.com/wtarreau/mhz
>
> Signed-off-by: Marek Behún 
> Tested-by: Pali Rohár 
> Tested-by: Tomasz Maciej Nowak 
> Tested-by: Anders Trier Olesen 
> Tested-by: Philip Soares 
> Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx")
> Cc: sta...@vger.kernel.org

Acked-by: Gregory CLEMENT 

Thanks,

Gregory
> ---
>  drivers/cpufreq/armada-37xx-cpufreq.c | 35 ++-
>  1 file changed, 23 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/cpufreq/armada-37xx-cpufreq.c 
> b/drivers/cpufreq/armada-37xx-cpufreq.c
> index b4af4094309b..b8dc6c849579 100644
> --- a/drivers/cpufreq/armada-37xx-cpufreq.c
> +++ b/drivers/cpufreq/armada-37xx-cpufreq.c
> @@ -25,6 +25,10 @@
>  
>  #include "cpufreq-dt.h"
>  
> +/* Clk register set */
> +#define ARMADA_37XX_CLK_TBG_SEL  0
> +#define ARMADA_37XX_CLK_TBG_SEL_CPU_OFF  22
> +
>  /* Power management in North Bridge register set */
>  #define ARMADA_37XX_NB_L0L1  0x18
>  #define ARMADA_37XX_NB_L2L3  0x1C
> @@ -120,10 +124,15 @@ static struct armada_37xx_dvfs 
> *armada_37xx_cpu_freq_info_get(u32 freq)
>   * will be configured then the DVFS will be enabled.
>   */
>  static void __init armada37xx_cpufreq_dvfs_setup(struct regmap *base,
> -  struct clk *clk, u8 *divider)
> +  struct regmap *clk_base, u8 
> *divider)
>  {
> + u32 cpu_tbg_sel;
>   int load_lvl;
> - struct clk *parent;
> +
> + /* Determine to which TBG clock is CPU connected */
> + regmap_read(clk_base, ARMADA_37XX_CLK_TBG_SEL, _tbg_sel);
> + cpu_tbg_sel >>= ARMADA_37XX_CLK_TBG_SEL_CPU_OFF;
> + cpu_tbg_sel &= ARMADA_37XX_NB_TBG_SEL_MASK;
>  
>   for (load_lvl = 0; load_lvl < LOAD_LEVEL_NR; load_lvl++) {
>   unsigned int reg, mask, val, offset = 0;
> @@ -142,6 +151,11 @@ static void __init armada37xx_cpufreq_dvfs_setup(struct 
> regmap *base,
>   mask = (ARMADA_37XX_NB_CLK_SEL_MASK
>   << ARMADA_37XX_NB_CLK_SEL_OFF);
>  
> + /* Set TBG index, for all levels we use the same TBG */
> + val = cpu_tbg_sel << ARMADA_37XX_NB_TBG_SEL_OFF;
> + mask = (ARMADA_37XX_NB_TBG_SEL_MASK
> + << ARMADA_37XX_NB_TBG_SEL_OFF);
> +
>   /*
>* Set cpu divider based on the pre-computed array in
>* order to have balanced step.
> @@ -160,14 +174,6 @@ static void __init armada37xx_cpufreq_dvfs_setup(struct 
> regmap *base,
>  
>   regmap_update_bits(base, reg, mask, val);
>   }
> -
> - /*
> -  * Set cpu clock source, for all the level we keep the same
> -  * clock source that the one already configured. For this one
> -  * we need to use the clock framework
> -  */
> - parent = clk

Re: [PATCH mvebu v3 00/10] Armada 37xx: Fix cpufreq changing base CPU speed to 800 MHz from 1000 MHz

2021-03-12 Thread Gregory CLEMENT
Hello Pali,

> Hello Gregory!
>
> Patches are the for almost two months and more people have tested them.
> They are marked with Fixed/CC-stable tags, they should go also into
> stable trees as they are fixing CPU scaling and instability issues.
>
> Are there any issues with these patches? If not, could you please merge
> them for upcoming Linux version?

Actually I am not the maintainer of the clk and cpufreq subsystems, so
the only thing I can apply is the device tree relative patch.

Gregory

>
> On Monday 22 February 2021 20:41:48 Pali Rohár wrote:
>> Hello!
>> 
>> This is third version of patches for Armada 37xx cpufreq driver which
>> fix CPU scaling with 1 GHz base frequency.
>> 
>> The only change in this third version is modified patch 04/10 with fixes
>> for 1.2 GHz variant of Espressobin. Minimal CPU voltage in L1 load for
>> 1.2 GHz variant was increased to 1.155V.
>> 
>> Patches are now rebased on top of the kernel version 5.11 with all
>> collected Acked-by/Tested-by lines and are available also in my git
>> tree in branch a3720-cpufreq-issues:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=a3720-cpufreq-issues
>> 
>> If you have other Armada 3720 boards with 1.2 GHz CPU, including
>> Espressobin V7, let us know if it is working fine for you.
>> 
>> Marek & Pali
>> 
>> Marek Behún (3):
>>   arm64: dts: marvell: armada-37xx: add syscon compatible to NB clk node
>>   cpufreq: armada-37xx: Fix setting TBG parent for load levels
>>   clk: mvebu: armada-37xx-periph: remove .set_parent method for CPU PM
>> clock
>> 
>> Pali Rohár (7):
>>   cpufreq: armada-37xx: Fix the AVS value for load L1
>>   clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to
>> 1 GHz
>>   clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1
>> to L0
>>   cpufreq: armada-37xx: Fix driver cleanup when registration failed
>>   cpufreq: armada-37xx: Fix determining base CPU frequency
>>   cpufreq: armada-37xx: Remove cur_frequency variable
>>   cpufreq: armada-37xx: Fix module unloading
>> 
>>  arch/arm64/boot/dts/marvell/armada-37xx.dtsi |   3 +-
>>  drivers/clk/mvebu/armada-37xx-periph.c   |  83 +++---
>>  drivers/cpufreq/armada-37xx-cpufreq.c| 111 +++
>>  3 files changed, 135 insertions(+), 62 deletions(-)
>> 
>> -- 
>> 2.20.1
>> 

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH] bus: mvebu-mbus: make iounmap() symmetric with ioremap()

2021-01-29 Thread Gregory CLEMENT
Hi,

> On Fri, 29 Jan 2021 17:01:35 +0100
> Gregory CLEMENT  wrote:
>
>> Could you sent me the patch I don't have it in my emails boxes.
>
> https://lore.kernel.org/lkml/20201112032149.21906-1-chris.pack...@alliedtelesis.co.nz/raw


Applied on mvebu/arm

Thanks,

Gregory

>
> Thomas
> -- 
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


[irqchip: irq/irqchip-next] irqchip/ocelot: Add support for Jaguar2 platforms

2020-12-11 Thread irqchip-bot for Gregory CLEMENT
The following commit has been merged into the irq/irqchip-next branch of 
irqchip:

Commit-ID: 550c1424acf0123ba0c17e22dfcac92d152b2f0e
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/550c1424acf0123ba0c17e22dfcac92d152b2f0e
Author:Gregory CLEMENT 
AuthorDate:Wed, 25 Nov 2020 11:32:06 +01:00
Committer: Marc Zyngier 
CommitterDate: Fri, 11 Dec 2020 14:47:49 

irqchip/ocelot: Add support for Jaguar2 platforms

This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Jaguar2.

Based on a larger patch from Lars Povlsen 

Signed-off-by: Gregory CLEMENT 
Signed-off-by: Marc Zyngier 
Acked-by: Alexandre Belloni 
Link: 
https://lore.kernel.org/r/20201125103206.136498-7-gregory.clem...@bootlin.com
---
 drivers/irqchip/irq-mscc-ocelot.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index da5a0ad..8235d98 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -63,6 +63,17 @@ static struct chip_props luton_props = {
.n_irq  = 28,
 };
 
+static struct chip_props jaguar2_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .n_irq  = 29,
+};
+
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
@@ -197,3 +208,11 @@ static int __init luton_irq_init(struct device_node *node,
 }
 
 IRQCHIP_DECLARE(luton_icpu, "mscc,luton-icpu-intr", luton_irq_init);
+
+static int __init jaguar2_irq_init(struct device_node *node,
+  struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(jaguar2_icpu, "mscc,jaguar2-icpu-intr", jaguar2_irq_init);


[irqchip: irq/irqchip-next] dt-bindings: interrupt-controller: Add binding for few Microsemi interrupt controllers

2020-12-11 Thread irqchip-bot for Gregory CLEMENT
The following commit has been merged into the irq/irqchip-next branch of 
irqchip:

Commit-ID: b307ee828f61bc65d918e820a93b5c547a73dda3
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/b307ee828f61bc65d918e820a93b5c547a73dda3
Author:Gregory CLEMENT 
AuthorDate:Wed, 25 Nov 2020 11:32:02 +01:00
Committer: Marc Zyngier 
CommitterDate: Fri, 11 Dec 2020 14:47:49 

dt-bindings: interrupt-controller: Add binding for few Microsemi interrupt 
controllers

Add the Device Tree binding documentation for the Microsemi Jaguar2,
Luton and Serval interrupt controller that is part of the ICPU. It is
connected directly to the MIPS core interrupt controller.

Signed-off-by: Gregory CLEMENT 
Signed-off-by: Marc Zyngier 
Reviewed-by: Rob Herring 
Link: 
https://lore.kernel.org/r/20201125103206.136498-3-gregory.clem...@bootlin.com
---
 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
index be82920..27b798b 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -21,7 +21,11 @@ properties:
   compatible:
 items:
   - enum:
+  - mscc,jaguar2-icpu-intr
+  - mscc,luton-icpu-intr
   - mscc,ocelot-icpu-intr
+  - mscc,serval-icpu-intr
+
 
   '#interrupt-cells':
 const: 1


[irqchip: irq/irqchip-next] irqchip/ocelot: Add support for Luton platforms

2020-12-11 Thread irqchip-bot for Gregory CLEMENT
The following commit has been merged into the irq/irqchip-next branch of 
irqchip:

Commit-ID: ffce73d4415391b2d6da4878bf04d6610edf56db
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/ffce73d4415391b2d6da4878bf04d6610edf56db
Author:Gregory CLEMENT 
AuthorDate:Wed, 25 Nov 2020 11:32:04 +01:00
Committer: Marc Zyngier 
CommitterDate: Fri, 11 Dec 2020 14:47:49 

irqchip/ocelot: Add support for Luton platforms

This patch extends irqchip driver for oceleot to be used with an other
vcoreiii base platform: Luton.

For this platform there is a few differences:
   - the interrupt must be enabled for the parent controller
   - there is no trigger register needed to be managed

Signed-off-by: Gregory CLEMENT 
Signed-off-by: Marc Zyngier 
Acked-by: Alexandre Belloni 
Link: 
https://lore.kernel.org/r/20201125103206.136498-5-gregory.clem...@bootlin.com
---
 drivers/irqchip/irq-mscc-ocelot.c | 38 ++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 6d4029a..496f955 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -16,6 +16,7 @@
 #define ICPU_CFG_INTR_INTR_TRIGGER(_p, x)   ((_p)->reg_off_trigger + 0x4 * (x))
 
 #define FLAGS_HAS_TRIGGER  BIT(0)
+#define FLAGS_NEED_INIT_ENABLE BIT(1)
 
 struct chip_props {
u8 flags;
@@ -40,6 +41,17 @@ static struct chip_props ocelot_props = {
.n_irq  = 24,
 };
 
+static struct chip_props luton_props = {
+   .flags  = FLAGS_NEED_INIT_ENABLE,
+   .reg_off_sticky = 0,
+   .reg_off_ena= 0x4,
+   .reg_off_ena_clr= 0x8,
+   .reg_off_ena_set= 0xc,
+   .reg_off_ident  = 0x18,
+   .reg_off_ena_irq0   = 0x14,
+   .n_irq  = 28,
+};
+
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
@@ -115,17 +127,27 @@ static int __init vcoreiii_irq_init(struct device_node 
*node,
goto err_gc_free;
}
 
-   gc->chip_types[0].regs.ack = p->reg_off_sticky;
-   gc->chip_types[0].regs.mask = p->reg_off_ena_clr;
gc->chip_types[0].chip.irq_ack = irq_gc_ack_set_bit;
-   gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit;
-   if (p->flags & FLAGS_HAS_TRIGGER)
+   gc->chip_types[0].regs.ack = p->reg_off_sticky;
+   if (p->flags & FLAGS_HAS_TRIGGER) {
+   gc->chip_types[0].regs.mask = p->reg_off_ena_clr;
gc->chip_types[0].chip.irq_unmask = ocelot_irq_unmask;
+   gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit;
+   } else {
+   gc->chip_types[0].regs.enable = p->reg_off_ena_set;
+   gc->chip_types[0].regs.disable = p->reg_off_ena_clr;
+   gc->chip_types[0].chip.irq_mask = irq_gc_mask_disable_reg;
+   gc->chip_types[0].chip.irq_unmask = irq_gc_unmask_enable_reg;
+   }
 
/* Mask and ack all interrupts */
irq_reg_writel(gc, 0, p->reg_off_ena);
irq_reg_writel(gc, 0x, p->reg_off_sticky);
 
+   /* Overall init */
+   if (p->flags & FLAGS_NEED_INIT_ENABLE)
+   irq_reg_writel(gc, BIT(0), p->reg_off_ena_irq0);
+
domain->host_data = p;
irq_set_chained_handler_and_data(parent_irq, ocelot_irq_handler,
 domain);
@@ -148,3 +170,11 @@ static int __init ocelot_irq_init(struct device_node *node,
 }
 
 IRQCHIP_DECLARE(ocelot_icpu, "mscc,ocelot-icpu-intr", ocelot_irq_init);
+
+static int __init luton_irq_init(struct device_node *node,
+struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(luton_icpu, "mscc,luton-icpu-intr", luton_irq_init);


[irqchip: irq/irqchip-next] dt-bindings: interrupt-controller: convert icpu intr bindings to json-schema

2020-12-11 Thread irqchip-bot for Gregory CLEMENT
The following commit has been merged into the irq/irqchip-next branch of 
irqchip:

Commit-ID: 47d5e0b0e1c151c06885a78a108001ead96adc75
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/47d5e0b0e1c151c06885a78a108001ead96adc75
Author:Gregory CLEMENT 
AuthorDate:Wed, 25 Nov 2020 11:32:01 +01:00
Committer: Marc Zyngier 
CommitterDate: Fri, 11 Dec 2020 14:47:49 

dt-bindings: interrupt-controller: convert icpu intr bindings to json-schema

Convert device tree bindings for Microsemi Ocelot SoC ICPU Interrupt
Controller to YAML format

Signed-off-by: Gregory CLEMENT 
Signed-off-by: Marc Zyngier 
Reviewed-by: Rob Herring 
Link: 
https://lore.kernel.org/r/20201125103206.136498-2-gregory.clem...@bootlin.com
---
 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
  | 21 -
 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 | 60 
 2 files changed, 60 insertions(+), 21 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
deleted file mode 100644
index f5baecc..000
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Microsemi Ocelot SoC ICPU Interrupt Controller
-
-Required properties:
-
-- compatible : should be "mscc,ocelot-icpu-intr"
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
-  interrupt source. The value shall be 1.
-- interrupts : Specifies the CPU interrupt the controller is connected to.
-
-Example:
-
-   intc: interrupt-controller@7070 {
-   compatible = "mscc,ocelot-icpu-intr";
-   reg = <0x7070 0x70>;
-   #interrupt-cells = <1>;
-   interrupt-controller;
-   interrupt-parent = <>;
-   interrupts = <2>;
-   };
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
new file mode 100644
index 000..be82920
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/interrupt-controller/mscc,ocelot-icpu-intr.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Microsemi Ocelot SoC ICPU Interrupt Controller
+
+maintainers:
+  - Alexandre Belloni 
+
+allOf:
+  - $ref: /schemas/interrupt-controller.yaml#
+
+description: |
+  the Microsemi Ocelot interrupt controller that is part of the
+  ICPU. It is connected directly to the MIPS core interrupt
+  controller.
+
+properties:
+  compatible:
+items:
+  - enum:
+  - mscc,ocelot-icpu-intr
+
+  '#interrupt-cells':
+const: 1
+
+  '#address-cells':
+const: 0
+
+  interrupt-controller: true
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+required:
+  - compatible
+  - '#interrupt-cells'
+  - '#address-cells'
+  - interrupt-controller
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+intc: interrupt-controller@7070 {
+compatible = "mscc,ocelot-icpu-intr";
+reg = <0x7070 0x70>;
+#interrupt-cells = <1>;
+#address-cells = <0>;
+interrupt-controller;
+interrupt-parent = <>;
+interrupts = <2>;
+};
+...


[irqchip: irq/irqchip-next] irqchip/ocelot: prepare to support more SoC

2020-12-11 Thread irqchip-bot for Gregory CLEMENT
The following commit has been merged into the irq/irqchip-next branch of 
irqchip:

Commit-ID: 5f0c75e7a1333f5ebb5303af55d8c863ea292c23
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/5f0c75e7a1333f5ebb5303af55d8c863ea292c23
Author:Gregory CLEMENT 
AuthorDate:Wed, 25 Nov 2020 11:32:03 +01:00
Committer: Marc Zyngier 
CommitterDate: Fri, 11 Dec 2020 14:47:49 

irqchip/ocelot: prepare to support more SoC

This patch extends irqchip driver for oceleot to be used with other
vcoreiii base platforms.

Signed-off-by: Gregory CLEMENT 
Signed-off-by: Marc Zyngier 
Acked-by: Alexandre Belloni 
Link: 
https://lore.kernel.org/r/20201125103206.136498-4-gregory.clem...@bootlin.com
---
 drivers/irqchip/irq-mscc-ocelot.c | 76 +-
 1 file changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 88143c0..6d4029a 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -12,30 +12,51 @@
 #include 
 #include 
 
-#define ICPU_CFG_INTR_INTR_STICKY  0x10
-#define ICPU_CFG_INTR_INTR_ENA 0x18
-#define ICPU_CFG_INTR_INTR_ENA_CLR 0x1c
-#define ICPU_CFG_INTR_INTR_ENA_SET 0x20
-#define ICPU_CFG_INTR_DST_INTR_IDENT(x)(0x38 + 0x4 * (x))
-#define ICPU_CFG_INTR_INTR_TRIGGER(x)  (0x5c + 0x4 * (x))
-
-#define OCELOT_NR_IRQ 24
+#define ICPU_CFG_INTR_DST_INTR_IDENT(_p, x) ((_p)->reg_off_ident + 0x4 * (x))
+#define ICPU_CFG_INTR_INTR_TRIGGER(_p, x)   ((_p)->reg_off_trigger + 0x4 * (x))
+
+#define FLAGS_HAS_TRIGGER  BIT(0)
+
+struct chip_props {
+   u8 flags;
+   u8 reg_off_sticky;
+   u8 reg_off_ena;
+   u8 reg_off_ena_clr;
+   u8 reg_off_ena_set;
+   u8 reg_off_ident;
+   u8 reg_off_trigger;
+   u8 reg_off_ena_irq0;
+   u8 n_irq;
+};
+
+static struct chip_props ocelot_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .n_irq  = 24,
+};
 
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct irq_domain *d = data->domain;
+   struct chip_props *p = d->host_data;
struct irq_chip_type *ct = irq_data_get_chip_type(data);
unsigned int mask = data->mask;
u32 val;
 
irq_gc_lock(gc);
-   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(0)) |
- irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(1));
+   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 0)) |
+   irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 1));
if (!(val & mask))
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_STICKY);
+   irq_reg_writel(gc, mask, p->reg_off_sticky);
 
*ct->mask_cache &= ~mask;
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_ENA_SET);
+   irq_reg_writel(gc, mask, p->reg_off_ena_set);
irq_gc_unlock(gc);
 }
 
@@ -43,8 +64,9 @@ static void ocelot_irq_handler(struct irq_desc *desc)
 {
struct irq_chip *chip = irq_desc_get_chip(desc);
struct irq_domain *d = irq_desc_get_handler_data(desc);
+   struct chip_props *p = d->host_data;
struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0);
-   u32 reg = irq_reg_readl(gc, ICPU_CFG_INTR_DST_INTR_IDENT(0));
+   u32 reg = irq_reg_readl(gc, ICPU_CFG_INTR_DST_INTR_IDENT(p, 0));
 
chained_irq_enter(chip, desc);
 
@@ -58,8 +80,9 @@ static void ocelot_irq_handler(struct irq_desc *desc)
chained_irq_exit(chip, desc);
 }
 
-static int __init ocelot_irq_init(struct device_node *node,
- struct device_node *parent)
+static int __init vcoreiii_irq_init(struct device_node *node,
+   struct device_node *parent,
+   struct chip_props *p)
 {
struct irq_domain *domain;
struct irq_chip_generic *gc;
@@ -69,14 +92,14 @@ static int __init ocelot_irq_init(struct device_node *node,
if (!parent_irq)
return -EINVAL;
 
-   domain = irq_domain_add_linear(node, OCELOT_NR_IRQ,
+   domain = irq_domain_add_linear(node, p->n_irq,
   _generic_chip_ops, NULL);
if (!domain) {
pr_err("%pOFn: unable to add irq domain\n", node);
return -ENOMEM;
}
 
-   ret = irq_alloc_domain_generic_chips(domain, OCELOT_NR_IRQ, 1,
+   ret = irq_alloc_domain_generic_chips(domain, p->n_irq, 1,
 "icpu", handle_level_irq,
  

[irqchip: irq/irqchip-next] irqchip/ocelot: Add support for Serval platforms

2020-12-11 Thread irqchip-bot for Gregory CLEMENT
The following commit has been merged into the irq/irqchip-next branch of 
irqchip:

Commit-ID: 7efdfbd15a21788de8c0743590e777f151a3031b
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/7efdfbd15a21788de8c0743590e777f151a3031b
Author:Gregory CLEMENT 
AuthorDate:Wed, 25 Nov 2020 11:32:05 +01:00
Committer: Marc Zyngier 
CommitterDate: Fri, 11 Dec 2020 14:47:49 

irqchip/ocelot: Add support for Serval platforms

This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Serval.

Based on a larger patch from Lars Povlsen 

Signed-off-by: Gregory CLEMENT 
Signed-off-by: Marc Zyngier 
Acked-by: Alexandre Belloni 
Link: 
https://lore.kernel.org/r/20201125103206.136498-6-gregory.clem...@bootlin.com
---
 drivers/irqchip/irq-mscc-ocelot.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 496f955..da5a0ad 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -41,6 +41,17 @@ static struct chip_props ocelot_props = {
.n_irq  = 24,
 };
 
+static struct chip_props serval_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0xc,
+   .reg_off_ena= 0x14,
+   .reg_off_ena_clr= 0x18,
+   .reg_off_ena_set= 0x1c,
+   .reg_off_ident  = 0x20,
+   .reg_off_trigger= 0x4,
+   .n_irq  = 24,
+};
+
 static struct chip_props luton_props = {
.flags  = FLAGS_NEED_INIT_ENABLE,
.reg_off_sticky = 0,
@@ -171,6 +182,14 @@ static int __init ocelot_irq_init(struct device_node *node,
 
 IRQCHIP_DECLARE(ocelot_icpu, "mscc,ocelot-icpu-intr", ocelot_irq_init);
 
+static int __init serval_irq_init(struct device_node *node,
+ struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(serval_icpu, "mscc,serval-icpu-intr", serval_irq_init);
+
 static int __init luton_irq_init(struct device_node *node,
 struct device_node *parent)
 {


Re: [PATCH 1/1] arm64: dts: marvell: keep SMMU disabled by default for Armada 7040 and 8040

2020-11-30 Thread Gregory CLEMENT
Hi,

> FW has to configure devices' StreamIDs so that SMMU is able to lookup
> context and do proper translation later on. For Armada 7040 & 8040 and
> publicly available FW, most of the devices are configured properly,
> but some like ap_sdhci0, PCIe, NIC still remain unassigned which
> results in SMMU faults about unmatched StreamID (assuming
> ARM_SMMU_DISABLE_BYPASS_BY_DEFAUL=y).
>
> Since there is dependency on custom FW let SMMU be disabled by default.
> People who still willing to use SMMU need to enable manually and
> use ARM_SMMU_DISABLE_BYPASS_BY_DEFAUL=n (or via kernel command line)
> with extra caution.
>
> Fixes: 83a3545d9c37 ("arm64: dts: marvell: add SMMU support")
> Cc:  # 5.9+
> Signed-off-by: Tomasz Nowicki 


Applied on mvebu/dt64

Thanks,

Gregory

> ---
>  arch/arm64/boot/dts/marvell/armada-7040.dtsi | 4 
>  arch/arm64/boot/dts/marvell/armada-8040.dtsi | 4 
>  2 files changed, 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-7040.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-7040.dtsi
> index 7a3198cd7a07..2f440711d21d 100644
> --- a/arch/arm64/boot/dts/marvell/armada-7040.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-7040.dtsi
> @@ -15,10 +15,6 @@ / {
>"marvell,armada-ap806";
>  };
>  
> - {
> - status = "okay";
> -};
> -
>  _pcie0 {
>   iommu-map =
>   <0x00x480 0x20>,
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-8040.dtsi
> index 79e8ce59baa8..22c2d6ebf381 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-8040.dtsi
> @@ -15,10 +15,6 @@ / {
>    "marvell,armada-ap806";
>  };
>  
> - {
> - status = "okay";
> -};
> -
>  _pcie0 {
>   iommu-map =
>   <0x00x480 0x20>,
> -- 
> 2.25.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH] arm64: dts: mcbin-singleshot: add heartbeat LED

2020-11-30 Thread Gregory CLEMENT
Hi,

> With board revision 1.3, SolidRun moved the power LED to the middle of
> the board. In old place of power LED a GPIO controllable heartbeat LED
> was added. This commit only touches Single Shot variant, since only this
> variant is all revision 1.3.
>
> Reported-by: Alexandra Alth 
> Signed-off-by: Tomasz Maciej Nowak 

Applied on mvebu/dt64

Thanks,

Gregory

> ---
>  .../marvell/armada-8040-mcbin-singleshot.dts  | 22 +++
>  1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts 
> b/arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts
> index 2e6832d02a59..411d20064271 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin-singleshot.dts
> @@ -5,6 +5,8 @@
>   * Device Tree file for MACCHIATOBin Armada 8040 community board platform
>   */
>  
> +#include 
> +
>  #include "armada-8040-mcbin.dtsi"
>  
>  / {
> @@ -12,6 +14,19 @@ / {
>   compatible = "marvell,armada8040-mcbin-singleshot",
>   "marvell,armada8040-mcbin", "marvell,armada8040",
>   "marvell,armada-ap806-quad", "marvell,armada-ap806";
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-0 = <_led18_pins>;
> + pinctrl-names = "default";
> +
> + led18 {
> + gpios = <_gpio2 1 GPIO_ACTIVE_LOW>;
> + function = LED_FUNCTION_HEARTBEAT;
> + color = ;
> + linux,default-trigger = "heartbeat";
> + };
> + };
>  };
>  
>  _eth0 {
> @@ -27,3 +42,10 @@ _eth0 {
>   managed = "in-band-status";
>   sfp = <_eth1>;
>  };
> +
> +_pinctrl {
> + cp0_led18_pins: led18-pins {
> + marvell,pins = "mpp33";
> + marvell,function = "gpio";
> + };
> +};
> -- 
> 2.29.2
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v2] ARM: dts: mvebu: Add device tree for RD-AC3X-48G4X2XL board

2020-11-30 Thread Gregory CLEMENT
Hi Aryan,

> Add device tree for RD-AC3X-48G4X2XL board. This has a Armada 382 SoC on
> a interposer board connected to a baseboard with a Prestera AC3X ASIC
> connected via PCI.
>
> Signed-off-by: Aryan Srivastava 
> Reviewed-by: Chris Packham 

Applied on mvebu/dt

Thanks,

Gregory

> ---
>
> Notes:
> Changes in v2:
> -Added comment for CPLD
>
>  arch/arm/boot/dts/Makefile|   1 +
>  .../boot/dts/armada-382-rd-ac3x-48g4x2xl.dts  | 112 ++
>  2 files changed, 113 insertions(+)
>  create mode 100644 arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index ce66ffd5a1bb..a60407ad7347 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1319,6 +1319,7 @@ dtb-$(CONFIG_MACH_ARMADA_370) += \
>  dtb-$(CONFIG_MACH_ARMADA_375) += \
>   armada-375-db.dtb
>  dtb-$(CONFIG_MACH_ARMADA_38X) += \
> + armada-382-rd-ac3x-48g4x2xl.dtb \
>   armada-385-clearfog-gtr-s4.dtb \
>   armada-385-clearfog-gtr-l8.dtb \
>   armada-385-db-88f6820-amc.dtb \
> diff --git a/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts 
> b/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
> new file mode 100644
> index ..584f0d0398a5
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-382-rd-ac3x-48g4x2xl.dts
> @@ -0,0 +1,112 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Device Tree file for Marvell Armada 382 reference board
> + * (RD-AC3X-48G4X2XL)
> + *
> + * Copyright (C) 2020 Allied Telesis Labs
> + */
> +
> +/dts-v1/;
> +#include "armada-385.dtsi"
> +
> +#include 
> +
> +/ {
> + model = "Marvell Armada 382 RD-AC3X";
> + compatible = "marvell,rd-ac3x-48g4x2xl", "marvell,rd-ac3x",
> +  "marvell,armada385", "marvell,armada380";
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + aliases {
> + ethernet0 = 
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x 0x2000>; /* 512MB */
> + };
> +
> + soc {
> + ranges =  +   MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10>;
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + status = "okay";
> +
> + eeprom@53{
> + compatible = "atmel,24c64";
> + reg = <0x53>;
> + };
> +
> + /* CPLD device present at 0x3c. Function unknown */
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + phy = <>;
> + phy-mode = "rgmii-id";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + phy0: ethernet-phy@0 {
> + reg = <0>;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + /* Port 0, Lane 0 */
> + status = "okay";
> +};
> +
> +_controller {
> + status = "okay";
> +
> + nand@0 {
> + reg = <0>;
> + label = "pxa3xx_nand-0";
> + nand-rb = <0>;
> + nand-on-flash-bbt;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +     partition@0 {
> + reg = <0x 0x0050>;
> + label = "u-boot";
> + };
> + partition@50{
> + reg = <0x0050 0x0040>;
> + label = "u-boot env";
> + };
> + partition@90{
> + reg = <0x0090 0x3F70>;
> + label = "user";
> + };
> + };
> + };
> +};
> +
> + {
> + clock-frequency = <2>;
> +};
> -- 
> 2.29.2
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name

2020-11-30 Thread Gregory CLEMENT
Hi,

> In accordance with the Generic xHCI bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "generic-xhci"-compatible nodes are
> correctly named.
>
> Signed-off-by: Serge Semin 
> Acked-by: Krzysztof Kozlowski 

Applied on mvebu/dt64

Thanks,

Gregory
> ---
>  arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
> index 9dcf16beabf5..1e37ae181acf 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
> @@ -275,7 +275,7 @@ CP11X_LABEL(thermal): thermal-sensor@70 {
>   };
>   };
>  
> - CP11X_LABEL(usb3_0): usb3@50 {
> + CP11X_LABEL(usb3_0): usb@50 {
>   compatible = "marvell,armada-8k-xhci",
>   "generic-xhci";
>   reg = <0x50 0x4000>;
> @@ -287,7 +287,7 @@ CP11X_LABEL(usb3_0): usb3@50 {
>   status = "disabled";
>   };
>  
> - CP11X_LABEL(usb3_1): usb3@51 {
> + CP11X_LABEL(usb3_1): usb@51 {
>   compatible = "marvell,armada-8k-xhci",
>   "generic-xhci";
>   reg = <0x51 0x4000>;
> -- 
> 2.28.0
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes name

2020-11-30 Thread Gregory CLEMENT
Hi,

> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
> named.
>
> Signed-off-by: Serge Semin 
> Acked-by: Krzysztof Kozlowski 


Applied on mvebu/dt

Thanks,

Gregory

> ---
>  arch/arm/boot/dts/armada-375.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/armada-375.dtsi 
> b/arch/arm/boot/dts/armada-375.dtsi
> index 9805e507c695..7f2f24a29e6c 100644
> --- a/arch/arm/boot/dts/armada-375.dtsi
> +++ b/arch/arm/boot/dts/armada-375.dtsi
> @@ -426,7 +426,7 @@ usb1: usb@54000 {
>   status = "disabled";
>   };
>  
> - usb2: usb3@58000 {
> + usb2: usb@58000 {
>   compatible = "marvell,armada-375-xhci";
>   reg = <0x58000 0x2>,<0x5b880 0x80>;
>   interrupts = ;
> -- 
> 2.28.0
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v2] arm64: dts: marvell: espressobin: Update link to V7 schematic

2020-11-30 Thread Gregory CLEMENT
Hello Pali,

> Up-to-date version of V7 schematic is on new URL linked from official
> tech-spec webpage http://espressobin.net/tech-spec/
>
> Signed-off-by: Pali Rohár 


Applied on mvebu/dt64

Thanks,

Gregory

>
> ---
> Changes in V2:
> * Added commit description
> ---
>  arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts | 2 +-
>  arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts 
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> index e225dce64b9e..4775a7eda481 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> @@ -8,7 +8,7 @@
>   *
>   */
>  /*
> - * Schematic available at 
> http://wiki.espressobin.net/tiki-download_file.php?fileId=200
> + * Schematic available at 
> http://espressobin.net/wp-content/uploads/2020/05/ESPRESSObin_V7-0_Schematic.pdf
>   */
>  
>  /dts-v1/;
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts 
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> index 44dbe9a21cc7..c47a93978386 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> @@ -8,7 +8,7 @@
>   *
>   */
>  /*
> - * Schematic available at 
> http://wiki.espressobin.net/tiki-download_file.php?fileId=200
> + * Schematic available at 
> http://espressobin.net/wp-content/uploads/2020/05/ESPRESSObin_V7-0_Schematic.pdf
>   */
>  
>  /dts-v1/;
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v5] arm64: dts: marvell: add DT for ESPRESSObin-Ultra

2020-11-29 Thread Gregory CLEMENT
x-frequency = <10800>;
> + spi-rx-bus-width = <4>;
> + spi-tx-bus-width = <4>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "firmware";
> + reg = <0x0 0x3e>;
> + };
> + partition@3e {
> + label = "hw-info";
> + reg = <0x3e 0x1>;
> + read-only;
> + };
> + partition@3f {
> + label = "u-boot-env";
> + reg = <0x3f 0x1>;
> + };
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + clock-frequency = <10>;
> +
> + rtc@51 {
> + compatible = "nxp,pcf8563";
> + reg = <0x51>;
> + };
> +};
> +
> + {
> + usb-phy = <_phy>;
> + status = "disabled";
> +};
> +
> + {
> + extphy: ethernet-phy@1 {
> + reg = <1>;
> + };
> +};
> +
> + {
> + reg = <3>;
> +
> + ports {
> + switch0port1: port@1 {
> + reg = <1>;
> + label = "lan0";
> + phy-handle = <>;
> + };
> +
> + switch0port2: port@2 {
> + reg = <2>;
> + label = "lan1";
> + phy-handle = <>;
> + };
> +
> + switch0port3: port@3 {
> + reg = <3>;
> + label = "lan2";
> + phy-handle = <>;
> + };
> +
> + switch0port4: port@4 {
> + reg = <4>;
> + label = "lan3";
> + phy-handle = <>;
> + };
> +
> + switch0port5: port@5 {
> + reg = <5>;
> + label = "wan";
> + phy-handle = <>;
> + phy-mode = "sgmii";
> + };
> + };
> +
> + mdio {
> + switch0phy3: switch0phy3@14 {
> + reg = <0x14>;
> + };
> + };
> +};
> -- 
> 2.27.0
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH] arm64: dts: marvell: espressobin: Add support for LED2

2020-11-29 Thread Gregory CLEMENT
Hi Pali,

> LED2 is connected to MPP1_2 pin. It is working only on V7 boards.
> V5 boards have hw bug which cause that LED2 is non-working.
>
> So enable LED2 only for Espressobin V7 boards.
>
> Note that LED1 is connected to LED_WLAN# pin on miniPCIe card and LED3 to
> power supply. Therefore on Espressobin board only LED2 can be controlled
> directly from the host. LED1 is possible to control via WiFi card inserted
> in miniPCIe slot if driver for particular card supports it.
>
> Signed-off-by: Pali Rohár 
> Tested-by: Gérald Kerma 


Applied on mvebu/dt64

Thanks,

Gregory


>
> ---
>
> Previous version of this patch was sent by Uwe in March 2018, but it did
> not work on any tested V5 board. Now we know it was due to V5 HW bug.
>
> https://lore.kernel.org/linux-arm-kernel/20180321105005.18426-3-u.kleine-koe...@pengutronix.de/
> ---
>  .../dts/marvell/armada-3720-espressobin-v7-emmc.dts |  4 
>  .../boot/dts/marvell/armada-3720-espressobin-v7.dts |  4 
>  .../boot/dts/marvell/armada-3720-espressobin.dtsi   | 13 +
>  3 files changed, 21 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts 
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> index 4775a7eda481..75401eab4d42 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> @@ -39,3 +39,7 @@
>   {
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts 
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> index c47a93978386..48a7f50fb427 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> @@ -34,3 +34,7 @@
>   {
>   label = "wan";
>  };
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
> index 8a1c678bea5f..daffe136c523 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
> @@ -41,6 +41,19 @@
> 330 0x0>;
>   enable-active-high;
>   };
> +
> + led2: gpio-led2 {
> + /* led2 is working only on v7 board */
> + status = "disabled";
> +
> + compatible = "gpio-leds";
> +
> + led2 {
> + label = "led2";
> + gpios = < 2 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> + };
>  };
>  
>  /* J9 */
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v2 1/1] arm64: dts: marvell: Add a device tree for the IEI Puzzle-M801 board

2020-11-29 Thread Gregory CLEMENT
cp0_ge_mdio_pins: ge-mdio-pins {
> + marvell,pins = "mpp32", "mpp34";
> + marvell,function = "ge";
> + };
> + cp0_i2c1_pins: i2c1-pins {
> + marvell,pins = "mpp35", "mpp36";
> + marvell,function = "i2c1";
> + };
> + cp0_i2c0_pins: i2c0-pins {
> + marvell,pins = "mpp37", "mpp38";
> + marvell,function = "i2c0";
> + };
> + cp0_uart1_pins: uart1-pins {
> + marvell,pins = "mpp40", "mpp41";
> + marvell,function = "uart1";
> + };
> + cp0_xhci_vbus_pins: xhci0-vbus-pins {
> + marvell,pins = "mpp47";
> + marvell,function = "gpio";
> + };
> + cp0_pcie_pins: pcie-pins {
> + marvell,pins = "mpp52";
> + marvell,function = "gpio";
> + };
> + cp0_sdhci_pins: sdhci-pins {
> + marvell,pins = "mpp55", "mpp56", "mpp57", "mpp58", "mpp59",
> +"mpp60", "mpp61";
> + marvell,function = "sdio";
> + };
> + cp0_sfpplus_led_pins: sfpplus-led-pins {
> + marvell,pins = "mpp54";
> + marvell,function = "gpio";
> + };
> +};
> +
> +_ethernet {
> + status = "okay";
> +};
> +
> +_eth0 {
> + status = "okay";
> + phy-mode = "10gbase-r";
> + phys = <_comphy4 0>;
> + local-mac-address = [ae 00 00 00 ff 00];
> + sfp = <_cp0_eth0>;
> + managed = "in-band-status";
> +};
> +
> +_eth1 {
> +     status = "okay";
> + phy = <_phy2>;
> + phy-mode = "sgmii";
> + local-mac-address = [ae 00 00 00 ff 01];
> + phys = <_comphy3 1>;
> +};
> +
> +_eth2 {
> + status = "okay";
> + phy-mode = "sgmii";
> + phys = <_comphy1 2>;
> + local-mac-address = [ae 00 00 00 ff 02];
> + phy = <_phy3>;
> +};
> +
> +_sata0 {
> + status = "okay";
> +
> + sata-port@0 {
> + phys = <_comphy2 0>;
> + phy-names = "cp0-sata0-0-phy";
> + };
> +
> + sata-port@1 {
> + phys = <_comphy5 1>;
> + phy-names = "cp0-sata0-1-phy";
> + };
> +};
> +
> +_sdhci0 {
> + broken-cd;
> + bus-width = <4>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_sdhci_pins>;
> + status = "okay";
> + vqmmc-supply = <_3_3>;
> +};
> +
> +_usb3_0 {
> + status = "okay";
> +};
> +
> +_usb3_1 {
> + status = "okay";
> +};
> +
> +_i2c0 {
> + clock-frequency = <10>;
> + status = "disabled";
> +};
> +
> +_i2c1 {
> + clock-frequency = <10>;
> + status = "disabled";
> +};
> +
> +_rtc {
> + status = "disabled";
> +};
> +
> +_ethernet {
> + status = "okay";
> +};
> +
> +_eth0 {
> + status = "okay";
> + phy-mode = "10gbase-r";
> + phys = <_comphy4 0>;
> + local-mac-address = [ae 00 00 00 ff 03];
> + sfp = <_cp1_eth0>;
> + managed = "in-band-status";
> +};
> +
> +_eth1 {
> + status = "okay";
> + phy = <_phy4>;
> + phy-mode = "sgmii";
> + local-mac-address = [ae 00 00 00 ff 04];
> + phys = <_comphy3 1>;
> +};
> +
> +_eth2 {
> + status = "okay";
> + phy-mode = "sgmii";
> + local-mac-address = [ae 00 00 00 ff 05];
> + phys = <_comphy5 2>;
> + phy = <_phy5>;
> +};
> +
> +_pinctrl {
> + cp1_sfpplus_led_pins: sfpplus-led-pins {
> + marvell,pins = "mpp6", "mpp7", "mpp8", "mpp10", "mpp14", 
> "mpp31";
> + marvell,function = "gpio";
> + };
> +};
> +
> +_uart0 {
> + status = "disabled";
> +};
> +
> +_comphy2 {
> + cp1_usbh0_con: connector {
> + compatible = "usb-a-connector";
> + phy-supply = <_5v0_usb3_hst_vbus>;
> + };
> +};
> +
> +_usb3_0 {
> + phys = <_comphy2 0>;
> + phy-names = "cp1-usb3h0-comphy";
> + status = "okay";
> +};
> +
> +_mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + status = "okay";
> +
> + ge_phy4: ethernet-phy@1 {
> + reg = <1>;
> + };
> + ge_phy5: ethernet-phy@0 {
> + reg = <0>;
> + };
> +};
> +
> +_pcie0 {
> + num-lanes = <2>;
> + phys = <_comphy0 0>, <_comphy1 0>;
> + phy-names = "cp1-pcie0-x2-lane0-phy", "cp1-pcie0-x2-lane1-phy";
> + status = "okay";
> +};
> -- 
> 2.26.2
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH] MAINTAINERS: Move Jason Cooper to CREDITS

2020-11-29 Thread Gregory CLEMENT
Marc Zyngier  writes:

> Jason's email address has now been bouncing for weeks, and no
> reply was received when trying to reach out on other addresses.
>
> We really hope he is OK. But until we hear of his whereabouts,
> let's move him to the CREDITS file so that people stop Cc-ing
> him.
>
> Cc: Andrew Lunn 
> Cc: Sebastian Hesselbarth 
> Cc: Gregory Clement 
> Cc: Thomas Gleixner 
> Cc: Thomas Petazzoni 
> Signed-off-by: Marc Zyngier 

Acked-by: Gregory CLEMENT 

Thanks,

Gregory


> ---
>  CREDITS | 5 +
>  MAINTAINERS | 4 
>  2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/CREDITS b/CREDITS
> index 8592e45e3932..cf112d3e9382 100644
> --- a/CREDITS
> +++ b/CREDITS
> @@ -740,6 +740,11 @@ S: (ask for current address)
>  S: Portland, Oregon
>  S: USA
>  
> +N: Jason Cooper
> +D: ARM/Marvell SOC co-maintainer
> +D: irqchip co-maintainer
> +D: MVEBU PCI DRIVER co-maintainer
> +
>  N: Robin Cornelius
>  E: robincornel...@users.sourceforge.net
>  D: Ralink rt2x00 WLAN driver
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e451dcce054f..7ba26942a573 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2012,7 +2012,6 @@ M:  Philipp Zabel 
>  S:   Maintained
>  
>  ARM/Marvell Dove/MV78xx0/Orion SOC support
> -M:   Jason Cooper 
>  M:   Andrew Lunn 
>  M:   Sebastian Hesselbarth 
>  M:   Gregory Clement 
> @@ -2029,7 +2028,6 @@ F:  arch/arm/plat-orion/
>  F:   drivers/soc/dove/
>  
>  ARM/Marvell Kirkwood and Armada 370, 375, 38x, 39x, XP, 3700, 7K/8K, CN9130 
> SOC support
> -M:   Jason Cooper 
>  M:   Andrew Lunn 
>  M:   Gregory Clement 
>  M:   Sebastian Hesselbarth 
> @@ -9255,7 +9253,6 @@ F:  kernel/irq/
>  
>  IRQCHIP DRIVERS
>  M:   Thomas Gleixner 
> -M:   Jason Cooper 
>  M:   Marc Zyngier 
>  L:   linux-kernel@vger.kernel.org
>  S:   Maintained
> @@ -13405,7 +13402,6 @@ F:drivers/pci/controller/mobiveil/pcie-mobiveil*
>  
>  PCI DRIVER FOR MVEBU (Marvell Armada 370 and Armada XP SOC support)
>  M:   Thomas Petazzoni 
> -M:   Jason Cooper 
>  L:   linux-...@vger.kernel.org
>  L:   linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
>  S:   Maintained
> -- 
> 2.29.2
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


[PATCH v5 5/6] irqchip: ocelot: Add support for Serval platforms

2020-11-25 Thread Gregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Serval.

Based on a larger patch from Lars Povlsen 
Acked-by: Alexandre Belloni 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 496f955b8fc4..da5a0ad991a1 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -41,6 +41,17 @@ static struct chip_props ocelot_props = {
.n_irq  = 24,
 };
 
+static struct chip_props serval_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0xc,
+   .reg_off_ena= 0x14,
+   .reg_off_ena_clr= 0x18,
+   .reg_off_ena_set= 0x1c,
+   .reg_off_ident  = 0x20,
+   .reg_off_trigger= 0x4,
+   .n_irq  = 24,
+};
+
 static struct chip_props luton_props = {
.flags  = FLAGS_NEED_INIT_ENABLE,
.reg_off_sticky = 0,
@@ -171,6 +182,14 @@ static int __init ocelot_irq_init(struct device_node *node,
 
 IRQCHIP_DECLARE(ocelot_icpu, "mscc,ocelot-icpu-intr", ocelot_irq_init);
 
+static int __init serval_irq_init(struct device_node *node,
+ struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(serval_icpu, "mscc,serval-icpu-intr", serval_irq_init);
+
 static int __init luton_irq_init(struct device_node *node,
 struct device_node *parent)
 {
-- 
2.29.2



[PATCH v5 6/6] irqchip: ocelot: Add support for Jaguar2 platforms

2020-11-25 Thread Gregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Jaguar2.

Based on a larger patch from Lars Povlsen 
Acked-by: Alexandre Belloni 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index da5a0ad991a1..8235d98650c1 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -63,6 +63,17 @@ static struct chip_props luton_props = {
.n_irq  = 28,
 };
 
+static struct chip_props jaguar2_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .n_irq  = 29,
+};
+
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
@@ -197,3 +208,11 @@ static int __init luton_irq_init(struct device_node *node,
 }
 
 IRQCHIP_DECLARE(luton_icpu, "mscc,luton-icpu-intr", luton_irq_init);
+
+static int __init jaguar2_irq_init(struct device_node *node,
+  struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(jaguar2_icpu, "mscc,jaguar2-icpu-intr", jaguar2_irq_init);
-- 
2.29.2



[PATCH v5 2/6] dt-bindings: interrupt-controller: Add binding for few Microsemi interrupt controllers

2020-11-25 Thread Gregory CLEMENT
Add the Device Tree binding documentation for the Microsemi Jaguar2,
Luton and Serval interrupt controller that is part of the ICPU. It is
connected directly to the MIPS core interrupt controller.

Signed-off-by: Gregory CLEMENT 
---
 .../bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml  | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
index be82920f6798..27b798bfe29b 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -21,7 +21,11 @@ properties:
   compatible:
 items:
   - enum:
+  - mscc,jaguar2-icpu-intr
+  - mscc,luton-icpu-intr
   - mscc,ocelot-icpu-intr
+  - mscc,serval-icpu-intr
+
 
   '#interrupt-cells':
 const: 1
-- 
2.29.2



[PATCH v5 3/6] irqchip: ocelot: prepare to support more SoC

2020-11-25 Thread Gregory CLEMENT
This patch extends irqchip driver for oceleot to be used with other
vcoreiii base platforms.

Acked-by: Alexandre Belloni 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 76 ++-
 1 file changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 88143c0b700c..6d4029a2ded0 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -12,30 +12,51 @@
 #include 
 #include 
 
-#define ICPU_CFG_INTR_INTR_STICKY  0x10
-#define ICPU_CFG_INTR_INTR_ENA 0x18
-#define ICPU_CFG_INTR_INTR_ENA_CLR 0x1c
-#define ICPU_CFG_INTR_INTR_ENA_SET 0x20
-#define ICPU_CFG_INTR_DST_INTR_IDENT(x)(0x38 + 0x4 * (x))
-#define ICPU_CFG_INTR_INTR_TRIGGER(x)  (0x5c + 0x4 * (x))
-
-#define OCELOT_NR_IRQ 24
+#define ICPU_CFG_INTR_DST_INTR_IDENT(_p, x) ((_p)->reg_off_ident + 0x4 * (x))
+#define ICPU_CFG_INTR_INTR_TRIGGER(_p, x)   ((_p)->reg_off_trigger + 0x4 * (x))
+
+#define FLAGS_HAS_TRIGGER  BIT(0)
+
+struct chip_props {
+   u8 flags;
+   u8 reg_off_sticky;
+   u8 reg_off_ena;
+   u8 reg_off_ena_clr;
+   u8 reg_off_ena_set;
+   u8 reg_off_ident;
+   u8 reg_off_trigger;
+   u8 reg_off_ena_irq0;
+   u8 n_irq;
+};
+
+static struct chip_props ocelot_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .n_irq  = 24,
+};
 
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct irq_domain *d = data->domain;
+   struct chip_props *p = d->host_data;
struct irq_chip_type *ct = irq_data_get_chip_type(data);
unsigned int mask = data->mask;
u32 val;
 
irq_gc_lock(gc);
-   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(0)) |
- irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(1));
+   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 0)) |
+   irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 1));
if (!(val & mask))
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_STICKY);
+   irq_reg_writel(gc, mask, p->reg_off_sticky);
 
*ct->mask_cache &= ~mask;
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_ENA_SET);
+   irq_reg_writel(gc, mask, p->reg_off_ena_set);
irq_gc_unlock(gc);
 }
 
@@ -43,8 +64,9 @@ static void ocelot_irq_handler(struct irq_desc *desc)
 {
struct irq_chip *chip = irq_desc_get_chip(desc);
struct irq_domain *d = irq_desc_get_handler_data(desc);
+   struct chip_props *p = d->host_data;
struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0);
-   u32 reg = irq_reg_readl(gc, ICPU_CFG_INTR_DST_INTR_IDENT(0));
+   u32 reg = irq_reg_readl(gc, ICPU_CFG_INTR_DST_INTR_IDENT(p, 0));
 
chained_irq_enter(chip, desc);
 
@@ -58,8 +80,9 @@ static void ocelot_irq_handler(struct irq_desc *desc)
chained_irq_exit(chip, desc);
 }
 
-static int __init ocelot_irq_init(struct device_node *node,
- struct device_node *parent)
+static int __init vcoreiii_irq_init(struct device_node *node,
+   struct device_node *parent,
+   struct chip_props *p)
 {
struct irq_domain *domain;
struct irq_chip_generic *gc;
@@ -69,14 +92,14 @@ static int __init ocelot_irq_init(struct device_node *node,
if (!parent_irq)
return -EINVAL;
 
-   domain = irq_domain_add_linear(node, OCELOT_NR_IRQ,
+   domain = irq_domain_add_linear(node, p->n_irq,
   _generic_chip_ops, NULL);
if (!domain) {
pr_err("%pOFn: unable to add irq domain\n", node);
return -ENOMEM;
}
 
-   ret = irq_alloc_domain_generic_chips(domain, OCELOT_NR_IRQ, 1,
+   ret = irq_alloc_domain_generic_chips(domain, p->n_irq, 1,
 "icpu", handle_level_irq,
 0, 0, 0);
if (ret) {
@@ -92,16 +115,18 @@ static int __init ocelot_irq_init(struct device_node *node,
goto err_gc_free;
}
 
-   gc->chip_types[0].regs.ack = ICPU_CFG_INTR_INTR_STICKY;
-   gc->chip_types[0].regs.mask = ICPU_CFG_INTR_INTR_ENA_CLR;
+   gc->chip_types[0].regs.ack = p->reg_off_sticky;
+   gc->chip_types[0].regs.mask = p->reg_off_ena_clr;
gc->chip_types[0].chip.irq_ack = irq_gc_ack_set_bit;
gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit

[PATCH v5 1/6] dt-bindings: interrupt-controller: convert icpu intr bindings to json-schema

2020-11-25 Thread Gregory CLEMENT
Convert device tree bindings for Microsemi Ocelot SoC ICPU Interrupt
Controller to YAML format

Signed-off-by: Gregory CLEMENT 
---
 .../mscc,ocelot-icpu-intr.txt | 21 ---
 .../mscc,ocelot-icpu-intr.yaml| 60 +++
 2 files changed, 60 insertions(+), 21 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
deleted file mode 100644
index f5baeccb689f..
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Microsemi Ocelot SoC ICPU Interrupt Controller
-
-Required properties:
-
-- compatible : should be "mscc,ocelot-icpu-intr"
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
-  interrupt source. The value shall be 1.
-- interrupts : Specifies the CPU interrupt the controller is connected to.
-
-Example:
-
-   intc: interrupt-controller@7070 {
-   compatible = "mscc,ocelot-icpu-intr";
-   reg = <0x7070 0x70>;
-   #interrupt-cells = <1>;
-   interrupt-controller;
-   interrupt-parent = <>;
-   interrupts = <2>;
-   };
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
new file mode 100644
index ..be82920f6798
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/interrupt-controller/mscc,ocelot-icpu-intr.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Microsemi Ocelot SoC ICPU Interrupt Controller
+
+maintainers:
+  - Alexandre Belloni 
+
+allOf:
+  - $ref: /schemas/interrupt-controller.yaml#
+
+description: |
+  the Microsemi Ocelot interrupt controller that is part of the
+  ICPU. It is connected directly to the MIPS core interrupt
+  controller.
+
+properties:
+  compatible:
+items:
+  - enum:
+  - mscc,ocelot-icpu-intr
+
+  '#interrupt-cells':
+const: 1
+
+  '#address-cells':
+const: 0
+
+  interrupt-controller: true
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+required:
+  - compatible
+  - '#interrupt-cells'
+  - '#address-cells'
+  - interrupt-controller
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+intc: interrupt-controller@7070 {
+compatible = "mscc,ocelot-icpu-intr";
+reg = <0x7070 0x70>;
+#interrupt-cells = <1>;
+#address-cells = <0>;
+interrupt-controller;
+interrupt-parent = <>;
+interrupts = <2>;
+};
+...
-- 
2.29.2



[PATCH v5 4/6] irqchip: ocelot: Add support for Luton platforms

2020-11-25 Thread Gregory CLEMENT
This patch extends irqchip driver for oceleot to be used with an other
vcoreiii base platform: Luton.

For this platform there is a few differences:
   - the interrupt must be enabled for the parent controller
   - there is no trigger register needed to be managed

Acked-by: Alexandre Belloni 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 38 +++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 6d4029a2ded0..496f955b8fc4 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -16,6 +16,7 @@
 #define ICPU_CFG_INTR_INTR_TRIGGER(_p, x)   ((_p)->reg_off_trigger + 0x4 * (x))
 
 #define FLAGS_HAS_TRIGGER  BIT(0)
+#define FLAGS_NEED_INIT_ENABLE BIT(1)
 
 struct chip_props {
u8 flags;
@@ -40,6 +41,17 @@ static struct chip_props ocelot_props = {
.n_irq  = 24,
 };
 
+static struct chip_props luton_props = {
+   .flags  = FLAGS_NEED_INIT_ENABLE,
+   .reg_off_sticky = 0,
+   .reg_off_ena= 0x4,
+   .reg_off_ena_clr= 0x8,
+   .reg_off_ena_set= 0xc,
+   .reg_off_ident  = 0x18,
+   .reg_off_ena_irq0   = 0x14,
+   .n_irq  = 28,
+};
+
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
@@ -115,17 +127,27 @@ static int __init vcoreiii_irq_init(struct device_node 
*node,
goto err_gc_free;
}
 
-   gc->chip_types[0].regs.ack = p->reg_off_sticky;
-   gc->chip_types[0].regs.mask = p->reg_off_ena_clr;
gc->chip_types[0].chip.irq_ack = irq_gc_ack_set_bit;
-   gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit;
-   if (p->flags & FLAGS_HAS_TRIGGER)
+   gc->chip_types[0].regs.ack = p->reg_off_sticky;
+   if (p->flags & FLAGS_HAS_TRIGGER) {
+   gc->chip_types[0].regs.mask = p->reg_off_ena_clr;
gc->chip_types[0].chip.irq_unmask = ocelot_irq_unmask;
+   gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit;
+   } else {
+   gc->chip_types[0].regs.enable = p->reg_off_ena_set;
+   gc->chip_types[0].regs.disable = p->reg_off_ena_clr;
+   gc->chip_types[0].chip.irq_mask = irq_gc_mask_disable_reg;
+   gc->chip_types[0].chip.irq_unmask = irq_gc_unmask_enable_reg;
+   }
 
/* Mask and ack all interrupts */
irq_reg_writel(gc, 0, p->reg_off_ena);
irq_reg_writel(gc, 0x, p->reg_off_sticky);
 
+   /* Overall init */
+   if (p->flags & FLAGS_NEED_INIT_ENABLE)
+   irq_reg_writel(gc, BIT(0), p->reg_off_ena_irq0);
+
domain->host_data = p;
irq_set_chained_handler_and_data(parent_irq, ocelot_irq_handler,
 domain);
@@ -148,3 +170,11 @@ static int __init ocelot_irq_init(struct device_node *node,
 }
 
 IRQCHIP_DECLARE(ocelot_icpu, "mscc,ocelot-icpu-intr", ocelot_irq_init);
+
+static int __init luton_irq_init(struct device_node *node,
+struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(luton_icpu, "mscc,luton-icpu-intr", luton_irq_init);
-- 
2.29.2



[PATCH v5 0/6] Extend irqchip ocelot driver to support other SoCs

2020-11-25 Thread Gregory CLEMENT
Ocelot SoC belongs to a larger family of SoCs which use the same
interrupt controller with a few variation.

This series of patches add support for Luton, Serval and Jaguar2, they
are all MIPS based.

The first patches of the series also updates the binding documentation
with the new compatible strings.

Gregory

Changelog:

v4 -> v5:

 - Fix yaml binding description by removing the tab and using space
   instead.

 - Add acked-by from Alexandre on the patches 3 and 4.

v3 -> v4
 - Fix example in binding adding #address-cells property.

 - Split the intial "irqchip: ocelot: Add support for Luton platforms"
   patch with a new patch "irqchip: ocelot: prepare to support more
   SoC"

 - Move from u32 to u8 the type used inside the "struct chip_props"

 - Keep the function ocelot_irq_unmask as is and use generic function
   irq_gc_mask_disable_reg and irq_gc_unmask_enable_reg for Luton.

 - Removed the irq_set_irqchip_state callback, actually this function
   was never called on this platform and seemed in the end useless.

 - Add acked-by from Alexandre on the last 2 patches.

v2 -> v3
 - Fix new-line-at-end-of-file error in the yaml file

v1 -> v2:
 - Convert the binding to yaml
 - Squashed the patches adding new binding in a single one


Gregory CLEMENT (6):
  dt-bindings: interrupt-controller: convert icpu intr bindings to
json-schema
  dt-bindings: interrupt-controller: Add binding for few Microsemi
interrupt controllers
  irqchip: ocelot: prepare to support more SoC
  irqchip: ocelot: Add support for Luton platforms
  irqchip: ocelot: Add support for Serval platforms
  irqchip: ocelot: Add support for Jaguar2 platforms

 .../mscc,ocelot-icpu-intr.txt |  21 ---
 .../mscc,ocelot-icpu-intr.yaml|  64 
 drivers/irqchip/irq-mscc-ocelot.c | 146 +++---
 3 files changed, 187 insertions(+), 44 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml

-- 
2.29.2



[PATCH v2 3/3] MIPS: dts: mscc: add reset support for Luton and Jaguar2

2020-11-24 Thread Gregory CLEMENT
Allow Luton and Jaguar2 SoCs to use reset feature by adding the reset
node.

Signed-off-by: Gregory CLEMENT 
---
 arch/mips/boot/dts/mscc/jaguar2.dtsi | 5 +
 arch/mips/boot/dts/mscc/luton.dtsi   | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/mips/boot/dts/mscc/jaguar2.dtsi 
b/arch/mips/boot/dts/mscc/jaguar2.dtsi
index 42b2b0a51ddc..7032fe550277 100644
--- a/arch/mips/boot/dts/mscc/jaguar2.dtsi
+++ b/arch/mips/boot/dts/mscc/jaguar2.dtsi
@@ -60,6 +60,11 @@ cpu_ctrl: syscon@7000 {
reg = <0x7000 0x2c>;
};
 
+   reset@71010008 {
+   compatible = "mscc,jaguar2-chip-reset";
+   reg = <0x71010008 0x4>;
+   };
+
intc: interrupt-controller@7070 {
compatible = "mscc,jaguar2-icpu-intr";
reg = <0x7070 0x94>;
diff --git a/arch/mips/boot/dts/mscc/luton.dtsi 
b/arch/mips/boot/dts/mscc/luton.dtsi
index 2a170b84c5a9..4a26c2874386 100644
--- a/arch/mips/boot/dts/mscc/luton.dtsi
+++ b/arch/mips/boot/dts/mscc/luton.dtsi
@@ -56,6 +56,11 @@ cpu_ctrl: syscon@1000 {
reg = <0x1000 0x2c>;
};
 
+   reset@00070090 {
+   compatible = "mscc,luton-chip-reset";
+   reg = <0x70090 0x4>;
+   };
+
intc: interrupt-controller@1084 {
compatible = "mscc,luton-icpu-intr";
reg = <0x1084 0x70>;
-- 
2.29.2



[PATCH v2 0/3] Add reset support in ocelot driver for new platforms

2020-11-24 Thread Gregory CLEMENT
Hello,

This series extends reset support for 2 other MIPS based SoCs: Luton
and Jaguar 2.

Patches 1 and 2 should be merged through the reset subsystem, while
the device tree changes in patches 3 should go through the mips
subsystem.

In this second series I removed the microchip,reset-switch-core
property support waiting for finding a butter solution for it.

Changelog:

 v1 -> v2:
 - Add binding documentation for the 2 new SoC
 - Fix compatible string in name device tree node
 - Add Acked-by from Alexande

Gregory

Gregory CLEMENT (3):
  dt-bindings: reset: ocelot: Add Luton and Jaguar2 support
  power: reset: ocelot: Add support 2 other MIPS based SoCs
  MIPS: dts: mscc: add reset support for Luton and Jaguar2

 .../bindings/power/reset/ocelot-reset.txt |  4 ++-
 arch/mips/boot/dts/mscc/jaguar2.dtsi  |  5 
 arch/mips/boot/dts/mscc/luton.dtsi|  5 
 drivers/power/reset/ocelot-reset.c| 30 +--
 4 files changed, 40 insertions(+), 4 deletions(-)

-- 
2.29.2



[PATCH v2 1/3] dt-bindings: reset: ocelot: Add Luton and Jaguar2 support

2020-11-24 Thread Gregory CLEMENT
This adds the support for 2 others MIPS based VCore III SoCs: Luton
and Jaguar2.

Signed-off-by: Gregory CLEMENT 
---
 .../devicetree/bindings/power/reset/ocelot-reset.txt  | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt 
b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
index 4d530d815484..c5de7b555feb 100644
--- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
+++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
@@ -7,7 +7,9 @@ The reset registers are both present in the MSCC vcoreiii MIPS 
and
 microchip Sparx5 armv8 SoC's.
 
 Required Properties:
- - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
+
+ - compatible: "mscc,ocelot-chip-reset", "mscc,luton-chip-reset",
+   "mscc,jaguar2-chip-reset" or "microchip,sparx5-chip-reset"
 
 Example:
reset@1070008 {
-- 
2.29.2



[PATCH v2 2/3] power: reset: ocelot: Add support 2 other MIPS based SoCs

2020-11-24 Thread Gregory CLEMENT
This adds reset support for Luton and Jaguar2 in the ocelot-reset
driver. They are both MIPS based belonging to the Vcore III family.

Acked-by: Alexandre Belloni 
Signed-off-by: Gregory CLEMENT 
---
 drivers/power/reset/ocelot-reset.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/power/reset/ocelot-reset.c 
b/drivers/power/reset/ocelot-reset.c
index f74e1dbb4ba3..8caa90cb58fc 100644
--- a/drivers/power/reset/ocelot-reset.c
+++ b/drivers/power/reset/ocelot-reset.c
@@ -29,6 +29,8 @@ struct ocelot_reset_context {
struct notifier_block restart_handler;
 };
 
+#define BIT_OFF_INVALID32
+
 #define SOFT_CHIP_RST BIT(0)
 
 #define ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL  0x24
@@ -50,9 +52,11 @@ static int ocelot_restart_handle(struct notifier_block *this,
   ctx->props->vcore_protect, 0);
 
/* Make the SI back to boot mode */
-   regmap_update_bits(ctx->cpu_ctrl, ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL,
-  IF_SI_OWNER_MASK << if_si_owner_bit,
-  IF_SI_OWNER_SIBM << if_si_owner_bit);
+   if (if_si_owner_bit != BIT_OFF_INVALID)
+   regmap_update_bits(ctx->cpu_ctrl,
+  ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL,
+  IF_SI_OWNER_MASK << if_si_owner_bit,
+  IF_SI_OWNER_SIBM << if_si_owner_bit);
 
pr_emerg("Resetting SoC\n");
 
@@ -96,6 +100,20 @@ static int ocelot_reset_probe(struct platform_device *pdev)
return err;
 }
 
+static const struct reset_props reset_props_jaguar2 = {
+   .syscon  = "mscc,ocelot-cpu-syscon",
+   .protect_reg = 0x20,
+   .vcore_protect   = BIT(2),
+   .if_si_owner_bit = 6,
+};
+
+static const struct reset_props reset_props_luton = {
+   .syscon  = "mscc,ocelot-cpu-syscon",
+   .protect_reg = 0x20,
+   .vcore_protect   = BIT(2),
+   .if_si_owner_bit = BIT_OFF_INVALID, /* n/a */
+};
+
 static const struct reset_props reset_props_ocelot = {
.syscon  = "mscc,ocelot-cpu-syscon",
.protect_reg = 0x20,
@@ -112,6 +130,12 @@ static const struct reset_props reset_props_sparx5 = {
 
 static const struct of_device_id ocelot_reset_of_match[] = {
{
+   .compatible = "mscc,jaguar2-chip-reset",
+   .data = _props_jaguar2
+   }, {
+   .compatible = "mscc,luton-chip-reset",
+   .data = _props_luton
+   }, {
.compatible = "mscc,ocelot-chip-reset",
.data = _props_ocelot
}, {
-- 
2.29.2



[PATCH v4 0/6] Extend irqchip ocelot driver to support other SoCs

2020-11-20 Thread Gregory CLEMENT
Hello,

Ocelot SoC belongs to a larger family of SoCs which use the same
interrupt controller with a few variation.

This series of patches add support for Luton, Serval and Jaguar2, they
are all MIPS based.

The first patches of the series also updates the binding documentation
with the new compatible strings.

Gregory

Changelog:
v3 -> v4
 - Fix example in binding adding #address-cells property.

 - Split the intial "irqchip: ocelot: Add support for Luton platforms"
   patch with a new patch "irqchip: ocelot: prepare to support more
   SoC"

 - Move from u32 to u8 the type used inside the "struct chip_props"

 - Keep the function ocelot_irq_unmask as is and use generic function
   irq_gc_mask_disable_reg and irq_gc_unmask_enable_reg for Luton.

 - Removed the irq_set_irqchip_state callback, actually this function
   was never called on this platform and seemed in the end useless.

 - Add acked-by from Alexandre on the last 2 patches.

v2 -> v3
 - Fix new-line-at-end-of-file error in the yaml file

v1 -> v2:
 - Convert the binding to yaml
 - Squashed the patches adding new binding in a single one

Gregory CLEMENT (6):
  dt-bindings: interrupt-controller: convert icpu intr bindings to
json-schema
  dt-bindings: interrupt-controller: Add binding for few Microsemi
interrupt controllers
  irqchip: ocelot: prepare to support more SoC
  irqchip: ocelot: Add support for Luton platforms
  irqchip: ocelot: Add support for Serval platforms
  irqchip: ocelot: Add support for Jaguar2 platforms

 .../mscc,ocelot-icpu-intr.txt |  21 ---
 .../mscc,ocelot-icpu-intr.yaml|  64 
 drivers/irqchip/irq-mscc-ocelot.c | 146 +++---
 3 files changed, 187 insertions(+), 44 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml

-- 
2.29.2



[PATCH v4 4/6] irqchip: ocelot: Add support for Luton platforms

2020-11-20 Thread Gregory CLEMENT
This patch extends irqchip driver for oceleot to be used with an other
vcoreiii base platform: Luton.

For this platform there is a few differences:
   - the interrupt must be enabled for the parent controller
   - there is no trigger register needed to be managed

Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 38 +++
 1 file changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 6d4029a2ded0..496f955b8fc4 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -16,6 +16,7 @@
 #define ICPU_CFG_INTR_INTR_TRIGGER(_p, x)   ((_p)->reg_off_trigger + 0x4 * (x))
 
 #define FLAGS_HAS_TRIGGER  BIT(0)
+#define FLAGS_NEED_INIT_ENABLE BIT(1)
 
 struct chip_props {
u8 flags;
@@ -40,6 +41,17 @@ static struct chip_props ocelot_props = {
.n_irq  = 24,
 };
 
+static struct chip_props luton_props = {
+   .flags  = FLAGS_NEED_INIT_ENABLE,
+   .reg_off_sticky = 0,
+   .reg_off_ena= 0x4,
+   .reg_off_ena_clr= 0x8,
+   .reg_off_ena_set= 0xc,
+   .reg_off_ident  = 0x18,
+   .reg_off_ena_irq0   = 0x14,
+   .n_irq  = 28,
+};
+
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
@@ -115,17 +127,27 @@ static int __init vcoreiii_irq_init(struct device_node 
*node,
goto err_gc_free;
}
 
-   gc->chip_types[0].regs.ack = p->reg_off_sticky;
-   gc->chip_types[0].regs.mask = p->reg_off_ena_clr;
gc->chip_types[0].chip.irq_ack = irq_gc_ack_set_bit;
-   gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit;
-   if (p->flags & FLAGS_HAS_TRIGGER)
+   gc->chip_types[0].regs.ack = p->reg_off_sticky;
+   if (p->flags & FLAGS_HAS_TRIGGER) {
+   gc->chip_types[0].regs.mask = p->reg_off_ena_clr;
gc->chip_types[0].chip.irq_unmask = ocelot_irq_unmask;
+   gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit;
+   } else {
+   gc->chip_types[0].regs.enable = p->reg_off_ena_set;
+   gc->chip_types[0].regs.disable = p->reg_off_ena_clr;
+   gc->chip_types[0].chip.irq_mask = irq_gc_mask_disable_reg;
+   gc->chip_types[0].chip.irq_unmask = irq_gc_unmask_enable_reg;
+   }
 
/* Mask and ack all interrupts */
irq_reg_writel(gc, 0, p->reg_off_ena);
irq_reg_writel(gc, 0x, p->reg_off_sticky);
 
+   /* Overall init */
+   if (p->flags & FLAGS_NEED_INIT_ENABLE)
+   irq_reg_writel(gc, BIT(0), p->reg_off_ena_irq0);
+
domain->host_data = p;
irq_set_chained_handler_and_data(parent_irq, ocelot_irq_handler,
 domain);
@@ -148,3 +170,11 @@ static int __init ocelot_irq_init(struct device_node *node,
 }
 
 IRQCHIP_DECLARE(ocelot_icpu, "mscc,ocelot-icpu-intr", ocelot_irq_init);
+
+static int __init luton_irq_init(struct device_node *node,
+struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(luton_icpu, "mscc,luton-icpu-intr", luton_irq_init);
-- 
2.29.2



[PATCH v4 6/6] irqchip: ocelot: Add support for Jaguar2 platforms

2020-11-20 Thread Gregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Jaguar2.

Based on a larger patch from Lars Povlsen 
Acked-by: Alexandre Belloni 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index da5a0ad991a1..8235d98650c1 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -63,6 +63,17 @@ static struct chip_props luton_props = {
.n_irq  = 28,
 };
 
+static struct chip_props jaguar2_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .n_irq  = 29,
+};
+
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
@@ -197,3 +208,11 @@ static int __init luton_irq_init(struct device_node *node,
 }
 
 IRQCHIP_DECLARE(luton_icpu, "mscc,luton-icpu-intr", luton_irq_init);
+
+static int __init jaguar2_irq_init(struct device_node *node,
+  struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(jaguar2_icpu, "mscc,jaguar2-icpu-intr", jaguar2_irq_init);
-- 
2.29.2



[PATCH v4 2/6] dt-bindings: interrupt-controller: Add binding for few Microsemi interrupt controllers

2020-11-20 Thread Gregory CLEMENT
Add the Device Tree binding documentation for the Microsemi Jaguar2,
Luton and Serval interrupt controller that is part of the ICPU. It is
connected directly to the MIPS core interrupt controller.

Signed-off-by: Gregory CLEMENT 
---
 .../bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml  | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
index f34b319c7874..92fb1baf600f 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -21,7 +21,11 @@ properties:
   compatible:
 items:
   - enum:
+  - mscc,jaguar2-icpu-intr
+  - mscc,luton-icpu-intr
   - mscc,ocelot-icpu-intr
+  - mscc,serval-icpu-intr
+
 
   '#interrupt-cells':
 const: 1
-- 
2.29.2



[PATCH v4 5/6] irqchip: ocelot: Add support for Serval platforms

2020-11-20 Thread Gregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Serval.

Based on a larger patch from Lars Povlsen 
Acked-by: Alexandre Belloni 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 496f955b8fc4..da5a0ad991a1 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -41,6 +41,17 @@ static struct chip_props ocelot_props = {
.n_irq  = 24,
 };
 
+static struct chip_props serval_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0xc,
+   .reg_off_ena= 0x14,
+   .reg_off_ena_clr= 0x18,
+   .reg_off_ena_set= 0x1c,
+   .reg_off_ident  = 0x20,
+   .reg_off_trigger= 0x4,
+   .n_irq  = 24,
+};
+
 static struct chip_props luton_props = {
.flags  = FLAGS_NEED_INIT_ENABLE,
.reg_off_sticky = 0,
@@ -171,6 +182,14 @@ static int __init ocelot_irq_init(struct device_node *node,
 
 IRQCHIP_DECLARE(ocelot_icpu, "mscc,ocelot-icpu-intr", ocelot_irq_init);
 
+static int __init serval_irq_init(struct device_node *node,
+ struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(serval_icpu, "mscc,serval-icpu-intr", serval_irq_init);
+
 static int __init luton_irq_init(struct device_node *node,
 struct device_node *parent)
 {
-- 
2.29.2



[PATCH v4 3/6] irqchip: ocelot: prepare to support more SoC

2020-11-20 Thread Gregory CLEMENT
This patch extends irqchip driver for oceleot to be used with other
vcoreiii base platforms.

Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 76 ++-
 1 file changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 88143c0b700c..6d4029a2ded0 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -12,30 +12,51 @@
 #include 
 #include 
 
-#define ICPU_CFG_INTR_INTR_STICKY  0x10
-#define ICPU_CFG_INTR_INTR_ENA 0x18
-#define ICPU_CFG_INTR_INTR_ENA_CLR 0x1c
-#define ICPU_CFG_INTR_INTR_ENA_SET 0x20
-#define ICPU_CFG_INTR_DST_INTR_IDENT(x)(0x38 + 0x4 * (x))
-#define ICPU_CFG_INTR_INTR_TRIGGER(x)  (0x5c + 0x4 * (x))
-
-#define OCELOT_NR_IRQ 24
+#define ICPU_CFG_INTR_DST_INTR_IDENT(_p, x) ((_p)->reg_off_ident + 0x4 * (x))
+#define ICPU_CFG_INTR_INTR_TRIGGER(_p, x)   ((_p)->reg_off_trigger + 0x4 * (x))
+
+#define FLAGS_HAS_TRIGGER  BIT(0)
+
+struct chip_props {
+   u8 flags;
+   u8 reg_off_sticky;
+   u8 reg_off_ena;
+   u8 reg_off_ena_clr;
+   u8 reg_off_ena_set;
+   u8 reg_off_ident;
+   u8 reg_off_trigger;
+   u8 reg_off_ena_irq0;
+   u8 n_irq;
+};
+
+static struct chip_props ocelot_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .n_irq  = 24,
+};
 
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct irq_domain *d = data->domain;
+   struct chip_props *p = d->host_data;
struct irq_chip_type *ct = irq_data_get_chip_type(data);
unsigned int mask = data->mask;
u32 val;
 
irq_gc_lock(gc);
-   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(0)) |
- irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(1));
+   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 0)) |
+   irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 1));
if (!(val & mask))
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_STICKY);
+   irq_reg_writel(gc, mask, p->reg_off_sticky);
 
*ct->mask_cache &= ~mask;
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_ENA_SET);
+   irq_reg_writel(gc, mask, p->reg_off_ena_set);
irq_gc_unlock(gc);
 }
 
@@ -43,8 +64,9 @@ static void ocelot_irq_handler(struct irq_desc *desc)
 {
struct irq_chip *chip = irq_desc_get_chip(desc);
struct irq_domain *d = irq_desc_get_handler_data(desc);
+   struct chip_props *p = d->host_data;
struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0);
-   u32 reg = irq_reg_readl(gc, ICPU_CFG_INTR_DST_INTR_IDENT(0));
+   u32 reg = irq_reg_readl(gc, ICPU_CFG_INTR_DST_INTR_IDENT(p, 0));
 
chained_irq_enter(chip, desc);
 
@@ -58,8 +80,9 @@ static void ocelot_irq_handler(struct irq_desc *desc)
chained_irq_exit(chip, desc);
 }
 
-static int __init ocelot_irq_init(struct device_node *node,
- struct device_node *parent)
+static int __init vcoreiii_irq_init(struct device_node *node,
+   struct device_node *parent,
+   struct chip_props *p)
 {
struct irq_domain *domain;
struct irq_chip_generic *gc;
@@ -69,14 +92,14 @@ static int __init ocelot_irq_init(struct device_node *node,
if (!parent_irq)
return -EINVAL;
 
-   domain = irq_domain_add_linear(node, OCELOT_NR_IRQ,
+   domain = irq_domain_add_linear(node, p->n_irq,
   _generic_chip_ops, NULL);
if (!domain) {
pr_err("%pOFn: unable to add irq domain\n", node);
return -ENOMEM;
}
 
-   ret = irq_alloc_domain_generic_chips(domain, OCELOT_NR_IRQ, 1,
+   ret = irq_alloc_domain_generic_chips(domain, p->n_irq, 1,
 "icpu", handle_level_irq,
 0, 0, 0);
if (ret) {
@@ -92,16 +115,18 @@ static int __init ocelot_irq_init(struct device_node *node,
goto err_gc_free;
}
 
-   gc->chip_types[0].regs.ack = ICPU_CFG_INTR_INTR_STICKY;
-   gc->chip_types[0].regs.mask = ICPU_CFG_INTR_INTR_ENA_CLR;
+   gc->chip_types[0].regs.ack = p->reg_off_sticky;
+   gc->chip_types[0].regs.mask = p->reg_off_ena_clr;
gc->chip_types[0].chip.irq_ack = irq_gc_ack_set_bit;
gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit;
-   gc->chip_types[0].chip.irq_

[PATCH v4 1/6] dt-bindings: interrupt-controller: convert icpu intr bindings to json-schema

2020-11-20 Thread Gregory CLEMENT
Convert device tree bindings for Microsemi Ocelot SoC ICPU Interrupt
Controller to YAML format

Signed-off-by: Gregory CLEMENT 
---
 .../mscc,ocelot-icpu-intr.txt | 21 ---
 .../mscc,ocelot-icpu-intr.yaml| 60 +++
 2 files changed, 60 insertions(+), 21 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
deleted file mode 100644
index f5baeccb689f..
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Microsemi Ocelot SoC ICPU Interrupt Controller
-
-Required properties:
-
-- compatible : should be "mscc,ocelot-icpu-intr"
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
-  interrupt source. The value shall be 1.
-- interrupts : Specifies the CPU interrupt the controller is connected to.
-
-Example:
-
-   intc: interrupt-controller@7070 {
-   compatible = "mscc,ocelot-icpu-intr";
-   reg = <0x7070 0x70>;
-   #interrupt-cells = <1>;
-   interrupt-controller;
-   interrupt-parent = <>;
-   interrupts = <2>;
-   };
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
new file mode 100644
index ..f34b319c7874
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/interrupt-controller/mscc,ocelot-icpu-intr.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Microsemi Ocelot SoC ICPU Interrupt Controller
+
+maintainers:
+  - Alexandre Belloni 
+
+allOf:
+  - $ref: /schemas/interrupt-controller.yaml#
+
+description: |
+  the Microsemi Ocelot interrupt controller that is part of the
+  ICPU. It is connected directly to the MIPS core interrupt
+  controller.
+
+properties:
+  compatible:
+items:
+  - enum:
+  - mscc,ocelot-icpu-intr
+
+  '#interrupt-cells':
+const: 1
+
+  '#address-cells':
+const: 0
+
+  interrupt-controller: true
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+required:
+  - compatible
+  - '#interrupt-cells'
+  - '#address-cells'
+  - interrupt-controller
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+intc: interrupt-controller@7070 {
+compatible = "mscc,ocelot-icpu-intr";
+reg = <0x7070 0x70>;
+#interrupt-cells = <1>;
+   #address-cells = <0>;
+interrupt-controller;
+interrupt-parent = <>;
+interrupts = <2>;
+};
+...
-- 
2.29.2



[PATCH 4/5] power: reset: ocelot: Add support 2 othe MIPS based SoCs

2020-11-16 Thread Gregory CLEMENT
This adds reset support for Luton and Jaguar2 in the ocelot-reset
driver. They are both MIPS based belonging to the VvoreIII family.

Signed-off-by: Gregory CLEMENT 
---
 drivers/power/reset/ocelot-reset.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/power/reset/ocelot-reset.c 
b/drivers/power/reset/ocelot-reset.c
index a203c42e99d4..0f92416f2907 100644
--- a/drivers/power/reset/ocelot-reset.c
+++ b/drivers/power/reset/ocelot-reset.c
@@ -29,6 +29,8 @@ struct ocelot_reset_context {
struct notifier_block restart_handler;
 };
 
+#define BIT_OFF_INVALID32
+
 #define SOFT_SWC_RST  BIT(1)
 #define SOFT_CHIP_RST BIT(0)
 
@@ -77,9 +79,11 @@ static int ocelot_restart_handle(struct notifier_block *this,
   ctx->props->vcore_protect, 0);
 
/* Make the SI back to boot mode */
-   regmap_update_bits(ctx->cpu_ctrl, ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL,
-  IF_SI_OWNER_MASK << if_si_owner_bit,
-  IF_SI_OWNER_SIBM << if_si_owner_bit);
+   if (if_si_owner_bit != BIT_OFF_INVALID)
+   regmap_update_bits(ctx->cpu_ctrl,
+  ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL,
+  IF_SI_OWNER_MASK << if_si_owner_bit,
+  IF_SI_OWNER_SIBM << if_si_owner_bit);
 
pr_emerg("Resetting SoC\n");
 
@@ -127,6 +131,20 @@ static int ocelot_reset_probe(struct platform_device *pdev)
return err;
 }
 
+static const struct reset_props reset_props_jaguar2 = {
+   .syscon  = "mscc,ocelot-cpu-syscon",
+   .protect_reg = 0x20,
+   .vcore_protect   = BIT(2),
+   .if_si_owner_bit = 6,
+};
+
+static const struct reset_props reset_props_luton = {
+   .syscon  = "mscc,ocelot-cpu-syscon",
+   .protect_reg = 0x20,
+   .vcore_protect   = BIT(2),
+   .if_si_owner_bit = BIT_OFF_INVALID, /* n/a */
+};
+
 static const struct reset_props reset_props_ocelot = {
.syscon  = "mscc,ocelot-cpu-syscon",
.protect_reg = 0x20,
@@ -143,6 +161,12 @@ static const struct reset_props reset_props_sparx5 = {
 
 static const struct of_device_id ocelot_reset_of_match[] = {
{
+   .compatible = "mscc,jaguar2-chip-reset",
+   .data = _props_jaguar2
+   }, {
+   .compatible = "mscc,luton-chip-reset",
+   .data = _props_luton
+   }, {
.compatible = "mscc,ocelot-chip-reset",
.data = _props_ocelot
}, {
-- 
2.29.2



[PATCH 2/5] power: reset: ocelot: Add support for reset switch on load time

2020-11-16 Thread Gregory CLEMENT
From: Lars Povlsen 

This patch add support for resetting the networking switch core at
reset driver load time. It is useful in order to bring the switch core
in a known state after a reboot or after a bootloader may have been
using the switch for network access.

Signed-off-by: Lars Povlsen 
---
 drivers/power/reset/ocelot-reset.c | 40 --
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/power/reset/ocelot-reset.c 
b/drivers/power/reset/ocelot-reset.c
index f74e1dbb4ba3..a203c42e99d4 100644
--- a/drivers/power/reset/ocelot-reset.c
+++ b/drivers/power/reset/ocelot-reset.c
@@ -29,6 +29,7 @@ struct ocelot_reset_context {
struct notifier_block restart_handler;
 };
 
+#define SOFT_SWC_RST  BIT(1)
 #define SOFT_CHIP_RST BIT(0)
 
 #define ICPU_CFG_CPU_SYSTEM_CTRL_GENERAL_CTRL  0x24
@@ -37,6 +38,32 @@ struct ocelot_reset_context {
 #define IF_SI_OWNER_SIBM   1
 #define IF_SI_OWNER_SIMC   2
 
+static int ocelot_switch_core_reset(const struct ocelot_reset_context *ctx)
+{
+
+   const char *driver = "ocelot-reset";
+   int timeout;
+
+   pr_notice("%s: Resetting Switch Core\n", driver);
+
+   /* Make sure the core is PROTECTED from reset */
+   regmap_update_bits(ctx->cpu_ctrl, ctx->props->protect_reg,
+  ctx->props->vcore_protect,
+  ctx->props->vcore_protect);
+
+   writel(SOFT_SWC_RST, ctx->base);
+   for (timeout = 0; timeout < 100; timeout++) {
+   if ((readl(ctx->base) & SOFT_SWC_RST) == 0) {
+   pr_debug("%s: Switch Core Reset complete.\n", driver);
+   return 0;
+   }
+   udelay(1);
+   }
+
+   pr_warn("%s: Switch Core Reset timeout!\n", driver);
+   return -ENXIO;
+}
+
 static int ocelot_restart_handle(struct notifier_block *this,
 unsigned long mode, void *cmd)
 {
@@ -66,7 +93,6 @@ static int ocelot_reset_probe(struct platform_device *pdev)
 {
struct ocelot_reset_context *ctx;
struct resource *res;
-
struct device *dev = >dev;
int err;
 
@@ -87,6 +113,11 @@ static int ocelot_reset_probe(struct platform_device *pdev)
return PTR_ERR(ctx->cpu_ctrl);
}
 
+   /* Optionally, call switch reset function */
+   if (of_property_read_bool(pdev->dev.of_node,
+ "microchip,reset-switch-core"))
+   ocelot_switch_core_reset(ctx);
+
ctx->restart_handler.notifier_call = ocelot_restart_handle;
ctx->restart_handler.priority = 192;
err = register_restart_handler(>restart_handler);
@@ -128,4 +159,9 @@ static struct platform_driver ocelot_reset_driver = {
.of_match_table = ocelot_reset_of_match,
},
 };
-builtin_platform_driver(ocelot_reset_driver);
+
+static int __init reset_init(void)
+{
+   return platform_driver_register(_reset_driver);
+}
+postcore_initcall(reset_init);
-- 
2.29.2



[PATCH 3/5] MIPS: dts: mscc: add reset switch property

2020-11-16 Thread Gregory CLEMENT
This property allows resetting the networking switch core at reset
driver load time.

Signed-off-by: Gregory CLEMENT 
---
 arch/mips/boot/dts/mscc/ocelot.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/boot/dts/mscc/ocelot.dtsi 
b/arch/mips/boot/dts/mscc/ocelot.dtsi
index 535a98284dcb..070c4a6b790d 100644
--- a/arch/mips/boot/dts/mscc/ocelot.dtsi
+++ b/arch/mips/boot/dts/mscc/ocelot.dtsi
@@ -187,6 +187,7 @@ port10: port@10 {
reset@1070008 {
compatible = "mscc,ocelot-chip-reset";
reg = <0x1070008 0x4>;
+   microchip,reset-switch-core;
};
 
gpio: pinctrl@1070034 {
-- 
2.29.2



[PATCH 5/5] MIPS: dts: mscc: add reset support for Luton and Jaguar2

2020-11-16 Thread Gregory CLEMENT
Allow Luton and Jaguar2 SoC to use reset feature by adding the reset
node.

Signed-off-by: Gregory CLEMENT 
---
 arch/mips/boot/dts/mscc/jaguar2.dtsi | 6 ++
 arch/mips/boot/dts/mscc/luton.dtsi   | 5 +
 2 files changed, 11 insertions(+)

diff --git a/arch/mips/boot/dts/mscc/jaguar2.dtsi 
b/arch/mips/boot/dts/mscc/jaguar2.dtsi
index 42b2b0a51ddc..f5f7b81c4044 100644
--- a/arch/mips/boot/dts/mscc/jaguar2.dtsi
+++ b/arch/mips/boot/dts/mscc/jaguar2.dtsi
@@ -60,6 +60,12 @@ cpu_ctrl: syscon@7000 {
reg = <0x7000 0x2c>;
};
 
+   reset@71010008 {
+   compatible = "mscc,luton-chip-reset";
+   reg = <0x71010008 0x4>;
+   microchip,reset-switch-core;
+   };
+
intc: interrupt-controller@7070 {
compatible = "mscc,jaguar2-icpu-intr";
reg = <0x7070 0x94>;
diff --git a/arch/mips/boot/dts/mscc/luton.dtsi 
b/arch/mips/boot/dts/mscc/luton.dtsi
index 2a170b84c5a9..4a26c2874386 100644
--- a/arch/mips/boot/dts/mscc/luton.dtsi
+++ b/arch/mips/boot/dts/mscc/luton.dtsi
@@ -56,6 +56,11 @@ cpu_ctrl: syscon@1000 {
reg = <0x1000 0x2c>;
};
 
+   reset@00070090 {
+   compatible = "mscc,luton-chip-reset";
+   reg = <0x70090 0x4>;
+   };
+
intc: interrupt-controller@1084 {
compatible = "mscc,luton-icpu-intr";
reg = <0x1084 0x70>;
-- 
2.29.2



[PATCH 0/5] Improve reset for ocelot and add support for new platfrom

2020-11-16 Thread Gregory CLEMENT
Hello,

This series first adds new feature to the ocelot reset driver and then
it extends its support for 2 other MIPS based SoCs: Luton and Jaguar 2.

Patches 1, 2 and 4 should be merged through the reset subsystem, while
the device tree changes in patches 3 and 5 should go through the mips
subsystem.

Gregory

Gregory CLEMENT (3):
  MIPS: dts: mscc: add reset switch property
  power: reset: ocelot: Add support 2 othe MIPS based SoCs
  MIPS: dts: mscc: add reset support for Luton and Jaguar2

Lars Povlsen (2):
  dt-bindings: reset: ocelot: Add documentation for
'microchip,reset-switch-core' property
  power: reset: ocelot: Add support for reset switch on load time

 .../bindings/power/reset/ocelot-reset.txt |  6 ++
 arch/mips/boot/dts/mscc/jaguar2.dtsi  |  6 ++
 arch/mips/boot/dts/mscc/luton.dtsi|  5 ++
 arch/mips/boot/dts/mscc/ocelot.dtsi   |  1 +
 drivers/power/reset/ocelot-reset.c| 70 +--
 5 files changed, 83 insertions(+), 5 deletions(-)

-- 
2.29.2



[PATCH 1/5] dt-bindings: reset: ocelot: Add documentation for 'microchip,reset-switch-core' property

2020-11-16 Thread Gregory CLEMENT
From: Lars Povlsen 

This documents the 'microchip,reset-switch-core' property in the
ocelot-reset driver.

Signed-off-by: Lars Povlsen 
---
 .../devicetree/bindings/power/reset/ocelot-reset.txt| 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt 
b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
index 4d530d815484..20fff03753ad 100644
--- a/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
+++ b/Documentation/devicetree/bindings/power/reset/ocelot-reset.txt
@@ -9,9 +9,15 @@ microchip Sparx5 armv8 SoC's.
 Required Properties:
  - compatible: "mscc,ocelot-chip-reset" or "microchip,sparx5-chip-reset"
 
+Optional properties:
+- microchip,reset-switch-core : Perform a switch core reset at the
+  time of driver load. This is may be used to initialize the switch
+  core to a known state (before other drivers are loaded).
+
 Example:
reset@1070008 {
compatible = "mscc,ocelot-chip-reset";
reg = <0x1070008 0x4>;
+   microchip,reset-switch-core;
};
 
-- 
2.29.2



[PATCH v3 2/5] dt-bindings: interrupt-controller: Add binding for few Microsemi interrupt controllers

2020-11-16 Thread Gregory CLEMENT
Add the Device Tree binding documentation for the Microsemi Jaguar2,
Luton and Serval interrupt controller that is part of the ICPU. It is
connected directly to the MIPS core interrupt controller.

Signed-off-by: Gregory CLEMENT 
---
 .../bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml  | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
index 3a537635a859..5483ed7062ba 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -21,7 +21,11 @@ properties:
   compatible:
 items:
   - enum:
+  - mscc,jaguar2-icpu-intr
+  - mscc,luton-icpu-intr
   - mscc,ocelot-icpu-intr
+  - mscc,serval-icpu-intr
+
 
   '#interrupt-cells':
 const: 1
-- 
2.29.2



[PATCH v3 5/5] irqchip: ocelot: Add support for Jaguar2 platforms

2020-11-16 Thread Gregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Jaguar2.

Based on a larger patch from Lars Povlsen 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 584af3b0a9e2..0dfea8771172 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -70,6 +70,18 @@ static const struct chip_props luton_props = {
.n_irq  = 28,
 };
 
+static const struct chip_props jaguar2_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .reg_off_force  = 0xc,
+   .n_irq  = 29,
+};
+
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
@@ -237,3 +249,11 @@ static int __init luton_irq_init(struct device_node *node,
 }
 
 IRQCHIP_DECLARE(luton_icpu, "mscc,luton-icpu-intr", luton_irq_init);
+
+static int __init jaguar2_irq_init(struct device_node *node,
+  struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(jaguar2_icpu, "mscc,jaguar2-icpu-intr", jaguar2_irq_init);
-- 
2.29.2



[PATCH v3 1/5] dt-bindings: interrupt-controller: convert icpu intr bindings to json-schema

2020-11-16 Thread Gregory CLEMENT
Convert device tree bindings for Microsemi Ocelot SoC ICPU Interrupt
Controller to YAML format

Signed-off-by: Gregory CLEMENT 
---
 .../mscc,ocelot-icpu-intr.txt | 21 ---
 .../mscc,ocelot-icpu-intr.yaml| 59 +++
 2 files changed, 59 insertions(+), 21 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
deleted file mode 100644
index f5baeccb689f..
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Microsemi Ocelot SoC ICPU Interrupt Controller
-
-Required properties:
-
-- compatible : should be "mscc,ocelot-icpu-intr"
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
-  interrupt source. The value shall be 1.
-- interrupts : Specifies the CPU interrupt the controller is connected to.
-
-Example:
-
-   intc: interrupt-controller@7070 {
-   compatible = "mscc,ocelot-icpu-intr";
-   reg = <0x7070 0x70>;
-   #interrupt-cells = <1>;
-   interrupt-controller;
-   interrupt-parent = <>;
-   interrupts = <2>;
-   };
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
new file mode 100644
index ..3a537635a859
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/interrupt-controller/mscc,ocelot-icpu-intr.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Microsemi Ocelot SoC ICPU Interrupt Controller
+
+maintainers:
+  - Alexandre Belloni 
+
+allOf:
+  - $ref: /schemas/interrupt-controller.yaml#
+
+description: |
+  the Microsemi Ocelot interrupt controller that is part of the
+  ICPU. It is connected directly to the MIPS core interrupt
+  controller.
+
+properties:
+  compatible:
+items:
+  - enum:
+  - mscc,ocelot-icpu-intr
+
+  '#interrupt-cells':
+const: 1
+
+  '#address-cells':
+const: 0
+
+  interrupt-controller: true
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+required:
+  - compatible
+  - '#interrupt-cells'
+  - '#address-cells'
+  - interrupt-controller
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+intc: interrupt-controller@7070 {
+compatible = "mscc,ocelot-icpu-intr";
+reg = <0x7070 0x70>;
+#interrupt-cells = <1>;
+interrupt-controller;
+interrupt-parent = <>;
+interrupts = <2>;
+};
+...
-- 
2.29.2



[PATCH v3 4/5] irqchip: ocelot: Add support for Serval platforms

2020-11-16 Thread Gregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Serval.

Based on a larger patch from Lars Povlsen 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 9964800c53c2..584af3b0a9e2 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -44,6 +44,18 @@ static const struct chip_props ocelot_props = {
.n_irq  = 24,
 };
 
+static const struct chip_props serval_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0xc,
+   .reg_off_ena= 0x14,
+   .reg_off_ena_clr= 0x18,
+   .reg_off_ena_set= 0x1c,
+   .reg_off_ident  = 0x20,
+   .reg_off_trigger= 0x4,
+   .reg_off_force  = 0x8,
+   .n_irq  = 24,
+};
+
 static const struct chip_props luton_props = {
.flags  = FLAGS_NEED_INIT_ENABLE |
  FLAGS_FORCE_LUTON_STYLE,
@@ -210,6 +222,14 @@ static int __init ocelot_irq_init(struct device_node *node,
 
 IRQCHIP_DECLARE(ocelot_icpu, "mscc,ocelot-icpu-intr", ocelot_irq_init);
 
+static int __init serval_irq_init(struct device_node *node,
+ struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(serval_icpu, "mscc,serval-icpu-intr", serval_irq_init);
+
 static int __init luton_irq_init(struct device_node *node,
 struct device_node *parent)
 {
-- 
2.29.2



[PATCH v3 3/5] irqchip: ocelot: Add support for Luton platforms

2020-11-16 Thread Gregory CLEMENT
This patch extends irqchip driver for oceleot to be used with an other
vcoreiii base platform: Luton.

Based on a larger patch from Lars Povlsen 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 145 +-
 1 file changed, 123 insertions(+), 22 deletions(-)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 88143c0b700c..9964800c53c2 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -12,39 +12,115 @@
 #include 
 #include 
 
-#define ICPU_CFG_INTR_INTR_STICKY  0x10
-#define ICPU_CFG_INTR_INTR_ENA 0x18
-#define ICPU_CFG_INTR_INTR_ENA_CLR 0x1c
-#define ICPU_CFG_INTR_INTR_ENA_SET 0x20
-#define ICPU_CFG_INTR_DST_INTR_IDENT(x)(0x38 + 0x4 * (x))
-#define ICPU_CFG_INTR_INTR_TRIGGER(x)  (0x5c + 0x4 * (x))
-
-#define OCELOT_NR_IRQ 24
+#define ICPU_CFG_INTR_DST_INTR_IDENT(_p, x)(_p->reg_off_ident + 0x4 * (x))
+#define ICPU_CFG_INTR_INTR_TRIGGER(_p, x)  (_p->reg_off_trigger + 0x4 * 
(x))
+
+#define FLAGS_NEED_INIT_ENABLE BIT(0)
+#define FLAGS_FORCE_LUTON_STYLEBIT(1)
+#define FLAGS_HAS_TRIGGER  BIT(2)
+
+struct chip_props {
+   u32 flags;
+   u32 reg_off_sticky;
+   u32 reg_off_ena;
+   u32 reg_off_ena_clr;
+   u32 reg_off_ena_set;
+   u32 reg_off_ident;
+   u32 reg_off_trigger;
+   u32 reg_off_force;
+   u32 reg_off_ena_irq0;
+   u32 n_irq;
+};
+
+static const struct chip_props ocelot_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .reg_off_force  = 0xc,
+   .n_irq  = 24,
+};
+
+static const struct chip_props luton_props = {
+   .flags  = FLAGS_NEED_INIT_ENABLE |
+ FLAGS_FORCE_LUTON_STYLE,
+   .reg_off_sticky = 0,
+   .reg_off_ena= 0x4,
+   .reg_off_ena_clr= 0x8,
+   .reg_off_ena_set= 0xc,
+   .reg_off_ident  = 0x18,
+   .reg_off_trigger= 0,
+   .reg_off_force  = 0x38,
+   .reg_off_ena_irq0   = 0x14,
+   .n_irq  = 28,
+};
 
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct irq_domain *d = data->domain;
+   struct chip_props *p = d->host_data;
struct irq_chip_type *ct = irq_data_get_chip_type(data);
unsigned int mask = data->mask;
u32 val;
 
irq_gc_lock(gc);
-   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(0)) |
- irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(1));
-   if (!(val & mask))
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_STICKY);
+   if (p->flags & FLAGS_HAS_TRIGGER) {
+   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 0)) |
+   irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 1));
+   if (!(val & mask))
+   irq_reg_writel(gc, mask, p->reg_off_sticky);
+   }
 
*ct->mask_cache &= ~mask;
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_ENA_SET);
+   irq_reg_writel(gc, mask, p->reg_off_ena_set);
irq_gc_unlock(gc);
 }
 
+static void luton_irq_force(struct irq_data *data,
+   struct irq_chip_generic *gc,
+   struct chip_props *p)
+{
+   int off = p->reg_off_force + (data->hwirq * sizeof(u32));
+   u32 val = irq_reg_readl(gc, off);
+
+   irq_reg_writel(gc, val | BIT(3), off);
+}
+
+static int ocelot_irq_force(struct irq_data *data,
+   enum irqchip_irq_state which, bool state)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct irq_domain *d = data->domain;
+   struct chip_props *p = d->host_data;
+   int ret = -EINVAL;
+
+   /* Only supports triggering */
+   if ((which == IRQCHIP_STATE_PENDING ||
+which == IRQCHIP_STATE_ACTIVE) &&
+   state && p->reg_off_force) {
+   if (p->flags & FLAGS_FORCE_LUTON_STYLE)
+   /* Config register style */
+   luton_irq_force(data, gc, p);
+   else
+   /* New, bitmask style */
+   irq_reg_writel(gc, data->mask, p->reg_off_force);
+   ret = 0;
+   }
+
+   return ret;
+}
+
 static void ocelot_irq_handler(struct irq_desc *desc)
 {
struct irq_chip *chip = irq_desc_get_chip(desc);
struct irq_domain *d = irq_desc_get_handler_data(desc);
+   struct chip_props *p = d->host_

[PATCH v3 0/5] Extend irqchip ocelot driver to support other SoCs

2020-11-16 Thread Gregory CLEMENT
Hello,

Ocelot SoC belongs to a larger family of SoCs which use the same
interrupt controller with a few variation.

This series of patches add support for Luton, Serval and Jaguar2, they
are all MIPS based.

The first patches of the series also updates the binding documentation
with the new compatible strings.

Gregory

Changelog:
v2 -> v3
 - Fix new-line-at-end-of-file error in the yaml file

v1 -> v2:
 - Convert the binding to yaml
 - Squashed the patches adding new binding in a single one

Gregory CLEMENT (5):
  dt-bindings: interrupt-controller: convert icpu intr bindings to
json-schema
  dt-bindings: interrupt-controller: Add binding for few Microsemi
interrupt controllers
  irqchip: ocelot: Add support for Luton platforms
  irqchip: ocelot: Add support for Serval platforms
  irqchip: ocelot: Add support for Jaguar2 platforms

 .../mscc,ocelot-icpu-intr.txt |  21 --
 .../mscc,ocelot-icpu-intr.yaml|  63 ++
 drivers/irqchip/irq-mscc-ocelot.c | 183 --
 3 files changed, 225 insertions(+), 42 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml

-- 
2.29.2



Re: [PATCH v2 1/5] dt-bindings: interrupt-controller: convert icpu intr bindings to json-schema

2020-11-16 Thread Gregory CLEMENT
Hello Rob,

> On Thu, 12 Nov 2020 17:04:20 +0100, Gregory CLEMENT wrote:
>> Convert device tree bindings for Microsemi Ocelot SoC ICPU Interrupt
>> Controller to YAML format
>> 
>> Signed-off-by: Gregory CLEMENT 
>> ---
>>  .../mscc,ocelot-icpu-intr.txt | 21 ---
>>  .../mscc,ocelot-icpu-intr.yaml| 59 +++
>>  2 files changed, 59 insertions(+), 21 deletions(-)
>>  delete mode 100644 
>> Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
>>  create mode 100644 
>> Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
>> 
>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
> ./Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml:59:4:
>  [error] no new line character at the end of file (new-line-at-end-of-file)
>
> dtschema/dtc warnings/errors:
> make[1]: *** [Documentation/devicetree/bindings/Makefile:59: 
> Documentation/devicetree/bindings/processed-schema-examples.json] Error 123
> make: *** [Makefile:1364: dt_binding_check] Error 2
>
>
> See https://patchwork.ozlabs.org/patch/1399077
>
> The base for the patch is generally the last rc1. Any dependencies
> should be noted.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:

I actually ran 'make dt_binding_check' and in the documentation there
was no reference of Documentation/devicetree/writing-schema.rst the need
of 'yamllint' while in the dependencies section of it was mentioned the
need of 'libyaml-dev'.

What do you think about updating the documentation ?

>
> pip3 install dtschema --upgrade
>
> Please check and re-submit.

Sure I am doing it right now.

Gregory


>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


[PATCH v2 4/5] irqchip: ocelot: Add support for Serval platforms

2020-11-12 Thread Gregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Serval.

Based on a larger patch from Lars Povlsen 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 9964800c53c2..584af3b0a9e2 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -44,6 +44,18 @@ static const struct chip_props ocelot_props = {
.n_irq  = 24,
 };
 
+static const struct chip_props serval_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0xc,
+   .reg_off_ena= 0x14,
+   .reg_off_ena_clr= 0x18,
+   .reg_off_ena_set= 0x1c,
+   .reg_off_ident  = 0x20,
+   .reg_off_trigger= 0x4,
+   .reg_off_force  = 0x8,
+   .n_irq  = 24,
+};
+
 static const struct chip_props luton_props = {
.flags  = FLAGS_NEED_INIT_ENABLE |
  FLAGS_FORCE_LUTON_STYLE,
@@ -210,6 +222,14 @@ static int __init ocelot_irq_init(struct device_node *node,
 
 IRQCHIP_DECLARE(ocelot_icpu, "mscc,ocelot-icpu-intr", ocelot_irq_init);
 
+static int __init serval_irq_init(struct device_node *node,
+ struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(serval_icpu, "mscc,serval-icpu-intr", serval_irq_init);
+
 static int __init luton_irq_init(struct device_node *node,
 struct device_node *parent)
 {
-- 
2.28.0



[PATCH v2 5/5] irqchip: ocelot: Add support for Jaguar2 platforms

2020-11-12 Thread Gregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Jaguar2.

Based on a larger patch from Lars Povlsen 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 584af3b0a9e2..0dfea8771172 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -70,6 +70,18 @@ static const struct chip_props luton_props = {
.n_irq  = 28,
 };
 
+static const struct chip_props jaguar2_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .reg_off_force  = 0xc,
+   .n_irq  = 29,
+};
+
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
@@ -237,3 +249,11 @@ static int __init luton_irq_init(struct device_node *node,
 }
 
 IRQCHIP_DECLARE(luton_icpu, "mscc,luton-icpu-intr", luton_irq_init);
+
+static int __init jaguar2_irq_init(struct device_node *node,
+  struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(jaguar2_icpu, "mscc,jaguar2-icpu-intr", jaguar2_irq_init);
-- 
2.28.0



[PATCH v2 3/5] irqchip: ocelot: Add support for Luton platforms

2020-11-12 Thread Gregory CLEMENT
This patch extends irqchip driver for oceleot to be used with an other
vcoreiii base platform: Luton.

Based on a larger patch from Lars Povlsen 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 145 +-
 1 file changed, 123 insertions(+), 22 deletions(-)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 88143c0b700c..9964800c53c2 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -12,39 +12,115 @@
 #include 
 #include 
 
-#define ICPU_CFG_INTR_INTR_STICKY  0x10
-#define ICPU_CFG_INTR_INTR_ENA 0x18
-#define ICPU_CFG_INTR_INTR_ENA_CLR 0x1c
-#define ICPU_CFG_INTR_INTR_ENA_SET 0x20
-#define ICPU_CFG_INTR_DST_INTR_IDENT(x)(0x38 + 0x4 * (x))
-#define ICPU_CFG_INTR_INTR_TRIGGER(x)  (0x5c + 0x4 * (x))
-
-#define OCELOT_NR_IRQ 24
+#define ICPU_CFG_INTR_DST_INTR_IDENT(_p, x)(_p->reg_off_ident + 0x4 * (x))
+#define ICPU_CFG_INTR_INTR_TRIGGER(_p, x)  (_p->reg_off_trigger + 0x4 * 
(x))
+
+#define FLAGS_NEED_INIT_ENABLE BIT(0)
+#define FLAGS_FORCE_LUTON_STYLEBIT(1)
+#define FLAGS_HAS_TRIGGER  BIT(2)
+
+struct chip_props {
+   u32 flags;
+   u32 reg_off_sticky;
+   u32 reg_off_ena;
+   u32 reg_off_ena_clr;
+   u32 reg_off_ena_set;
+   u32 reg_off_ident;
+   u32 reg_off_trigger;
+   u32 reg_off_force;
+   u32 reg_off_ena_irq0;
+   u32 n_irq;
+};
+
+static const struct chip_props ocelot_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .reg_off_force  = 0xc,
+   .n_irq  = 24,
+};
+
+static const struct chip_props luton_props = {
+   .flags  = FLAGS_NEED_INIT_ENABLE |
+ FLAGS_FORCE_LUTON_STYLE,
+   .reg_off_sticky = 0,
+   .reg_off_ena= 0x4,
+   .reg_off_ena_clr= 0x8,
+   .reg_off_ena_set= 0xc,
+   .reg_off_ident  = 0x18,
+   .reg_off_trigger= 0,
+   .reg_off_force  = 0x38,
+   .reg_off_ena_irq0   = 0x14,
+   .n_irq  = 28,
+};
 
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct irq_domain *d = data->domain;
+   struct chip_props *p = d->host_data;
struct irq_chip_type *ct = irq_data_get_chip_type(data);
unsigned int mask = data->mask;
u32 val;
 
irq_gc_lock(gc);
-   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(0)) |
- irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(1));
-   if (!(val & mask))
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_STICKY);
+   if (p->flags & FLAGS_HAS_TRIGGER) {
+   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 0)) |
+   irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 1));
+   if (!(val & mask))
+   irq_reg_writel(gc, mask, p->reg_off_sticky);
+   }
 
*ct->mask_cache &= ~mask;
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_ENA_SET);
+   irq_reg_writel(gc, mask, p->reg_off_ena_set);
irq_gc_unlock(gc);
 }
 
+static void luton_irq_force(struct irq_data *data,
+   struct irq_chip_generic *gc,
+   struct chip_props *p)
+{
+   int off = p->reg_off_force + (data->hwirq * sizeof(u32));
+   u32 val = irq_reg_readl(gc, off);
+
+   irq_reg_writel(gc, val | BIT(3), off);
+}
+
+static int ocelot_irq_force(struct irq_data *data,
+   enum irqchip_irq_state which, bool state)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct irq_domain *d = data->domain;
+   struct chip_props *p = d->host_data;
+   int ret = -EINVAL;
+
+   /* Only supports triggering */
+   if ((which == IRQCHIP_STATE_PENDING ||
+which == IRQCHIP_STATE_ACTIVE) &&
+   state && p->reg_off_force) {
+   if (p->flags & FLAGS_FORCE_LUTON_STYLE)
+   /* Config register style */
+   luton_irq_force(data, gc, p);
+   else
+   /* New, bitmask style */
+   irq_reg_writel(gc, data->mask, p->reg_off_force);
+   ret = 0;
+   }
+
+   return ret;
+}
+
 static void ocelot_irq_handler(struct irq_desc *desc)
 {
struct irq_chip *chip = irq_desc_get_chip(desc);
struct irq_domain *d = irq_desc_get_handler_data(desc);
+   struct chip_props *p = d->host_

[PATCH v2 0/5] Extend irqchip ocelot driver to support other SoCs

2020-11-12 Thread Gregory CLEMENT
Hello,

Ocelot SoC belongs to a larger family of SoCs which use the same
interrupt controller with a few variation.

This series of patches add support for Luton, Serval and Jaguar2, they
are all MIPS based.

The first patches of the series also updates the binding documentation
with the new compatible strings.

Gregory

Changelog:
v1 -> v2:
 - Convert the binding to yaml
 - Squashed the patches adding new binding in a single one

Gregory CLEMENT (5):
  dt-bindings: interrupt-controller: convert icpu intr bindings to
json-schema
  dt-bindings: interrupt-controller: Add binding for few Microsemi
interrupt controllers
  irqchip: ocelot: Add support for Luton platforms
  irqchip: ocelot: Add support for Serval platforms
  irqchip: ocelot: Add support for Jaguar2 platforms

 .../mscc,ocelot-icpu-intr.txt |  21 --
 .../mscc,ocelot-icpu-intr.yaml|  63 ++
 drivers/irqchip/irq-mscc-ocelot.c | 183 --
 3 files changed, 225 insertions(+), 42 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml

-- 
2.28.0



[PATCH v2 2/5] dt-bindings: interrupt-controller: Add binding for few Microsemi interrupt controllers

2020-11-12 Thread Gregory CLEMENT
Add the Device Tree binding documentation for the Microsemi Jaguar2,
Luton and Serval interrupt controller that is part of the ICPU. It is
connected directly to the MIPS core interrupt controller.

Signed-off-by: Gregory CLEMENT 
---
 .../bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml  | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
index afd00f9c9d74..e2f093faa906 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -21,7 +21,11 @@ properties:
   compatible:
 items:
   - enum:
+  - mscc,jaguar2-icpu-intr
+  - mscc,luton-icpu-intr
   - mscc,ocelot-icpu-intr
+  - mscc,serval-icpu-intr
+
 
   '#interrupt-cells':
 const: 1
-- 
2.28.0



[PATCH v2 1/5] dt-bindings: interrupt-controller: convert icpu intr bindings to json-schema

2020-11-12 Thread Gregory CLEMENT
Convert device tree bindings for Microsemi Ocelot SoC ICPU Interrupt
Controller to YAML format

Signed-off-by: Gregory CLEMENT 
---
 .../mscc,ocelot-icpu-intr.txt | 21 ---
 .../mscc,ocelot-icpu-intr.yaml| 59 +++
 2 files changed, 59 insertions(+), 21 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
deleted file mode 100644
index f5baeccb689f..
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Microsemi Ocelot SoC ICPU Interrupt Controller
-
-Required properties:
-
-- compatible : should be "mscc,ocelot-icpu-intr"
-- reg : Specifies base physical address and size of the registers.
-- interrupt-controller : Identifies the node as an interrupt controller
-- #interrupt-cells : Specifies the number of cells needed to encode an
-  interrupt source. The value shall be 1.
-- interrupts : Specifies the CPU interrupt the controller is connected to.
-
-Example:
-
-   intc: interrupt-controller@7070 {
-   compatible = "mscc,ocelot-icpu-intr";
-   reg = <0x7070 0x70>;
-   #interrupt-cells = <1>;
-   interrupt-controller;
-   interrupt-parent = <>;
-   interrupts = <2>;
-   };
diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
new file mode 100644
index ..afd00f9c9d74
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
"http://devicetree.org/schemas/interrupt-controller/mscc,ocelot-icpu-intr.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Microsemi Ocelot SoC ICPU Interrupt Controller
+
+maintainers:
+  - Alexandre Belloni 
+
+allOf:
+  - $ref: /schemas/interrupt-controller.yaml#
+
+description: |
+  the Microsemi Ocelot interrupt controller that is part of the
+  ICPU. It is connected directly to the MIPS core interrupt
+  controller.
+
+properties:
+  compatible:
+items:
+  - enum:
+  - mscc,ocelot-icpu-intr
+
+  '#interrupt-cells':
+const: 1
+
+  '#address-cells':
+const: 0
+
+  interrupt-controller: true
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+required:
+  - compatible
+  - '#interrupt-cells'
+  - '#address-cells'
+  - interrupt-controller
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+intc: interrupt-controller@7070 {
+compatible = "mscc,ocelot-icpu-intr";
+reg = <0x7070 0x70>;
+#interrupt-cells = <1>;
+interrupt-controller;
+interrupt-parent = <>;
+interrupts = <2>;
+};
+...
\ No newline at end of file
-- 
2.28.0



[PATCH 1/4] dt-bindings: pinctrl: ocelot: Add Luton SoC support

2020-11-06 Thread Gregory CLEMENT
Add the documentation for the Microsemi Luton pinmuxing and gpio
controller.

Signed-off-by: Gregory CLEMENT 
---
 .../devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt| 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
index 00912449237b..58ea2ae57713 100644
--- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
@@ -3,7 +3,8 @@ Microsemi Ocelot pin controller Device Tree Bindings
 
 Required properties:
  - compatible  : Should be "mscc,ocelot-pinctrl",
- "mscc,jaguar2-pinctrl" or "microchip,sparx5-pinctrl"
+ "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl"
+ or "mscc,luton-pinctrl"
  - reg : Address and length of the register set for the device
  - gpio-controller : Indicates this device is a GPIO controller
  - #gpio-cells : Must be 2.
-- 
2.28.0



[PATCH 3/4] pinctrl: ocelot: Add support for Luton platforms

2020-11-06 Thread Gregory CLEMENT
From: Lars Povlsen 

This patch adds support for Luton pinctrl, using the ocelot driver as
basis. It adds pinconfig support as well, as supported by the
platform.

gclement: Split from a larger patch adding support all platforms in
the same time.

Signed-off-by: Lars Povlsen 
Signed-off-by: Gregory CLEMENT 
---
 drivers/pinctrl/pinctrl-ocelot.c | 92 
 1 file changed, 92 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index a4a1b00f7f0d..ab74c79d7cca 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -158,6 +158,88 @@ struct ocelot_pinctrl {
u8 stride;
 };
 
+#define LUTON_P(p, f0, f1) \
+static struct ocelot_pin_caps luton_pin_##p = {
\
+   .pin = p,   \
+   .functions = {  \
+   FUNC_GPIO, FUNC_##f0, FUNC_##f1, FUNC_NONE, \
+   },  \
+}
+
+LUTON_P(0,  SG0,   NONE);
+LUTON_P(1,  SG0,   NONE);
+LUTON_P(2,  SG0,   NONE);
+LUTON_P(3,  SG0,   NONE);
+LUTON_P(4,  TACHO, NONE);
+LUTON_P(5,  TWI,   PHY_LED);
+LUTON_P(6,  TWI,   PHY_LED);
+LUTON_P(7,  NONE,  PHY_LED);
+LUTON_P(8,  EXT_IRQ,   PHY_LED);
+LUTON_P(9,  EXT_IRQ,   PHY_LED);
+LUTON_P(10, SFP,   PHY_LED);
+LUTON_P(11, SFP,   PHY_LED);
+LUTON_P(12, SFP,   PHY_LED);
+LUTON_P(13, SFP,   PHY_LED);
+LUTON_P(14, SI,PHY_LED);
+LUTON_P(15, SI,PHY_LED);
+LUTON_P(16, SI,PHY_LED);
+LUTON_P(17, SFP,   PHY_LED);
+LUTON_P(18, SFP,   PHY_LED);
+LUTON_P(19, SFP,   PHY_LED);
+LUTON_P(20, SFP,   PHY_LED);
+LUTON_P(21, SFP,   PHY_LED);
+LUTON_P(22, SFP,   PHY_LED);
+LUTON_P(23, SFP,   PHY_LED);
+LUTON_P(24, SFP,   PHY_LED);
+LUTON_P(25, SFP,   PHY_LED);
+LUTON_P(26, SFP,   PHY_LED);
+LUTON_P(27, SFP,   PHY_LED);
+LUTON_P(28, SFP,   PHY_LED);
+LUTON_P(29, PWM,   NONE);
+LUTON_P(30, UART,  NONE);
+LUTON_P(31, UART,  NONE);
+
+#define LUTON_PIN(n) { \
+   .number = n,\
+   .name = "GPIO_"#n,  \
+   .drv_data = _pin_##n  \
+}
+
+static const struct pinctrl_pin_desc luton_pins[] = {
+   LUTON_PIN(0),
+   LUTON_PIN(1),
+   LUTON_PIN(2),
+   LUTON_PIN(3),
+   LUTON_PIN(4),
+   LUTON_PIN(5),
+   LUTON_PIN(6),
+   LUTON_PIN(7),
+   LUTON_PIN(8),
+   LUTON_PIN(9),
+   LUTON_PIN(10),
+   LUTON_PIN(11),
+   LUTON_PIN(12),
+   LUTON_PIN(13),
+   LUTON_PIN(14),
+   LUTON_PIN(15),
+   LUTON_PIN(16),
+   LUTON_PIN(17),
+   LUTON_PIN(18),
+   LUTON_PIN(19),
+   LUTON_PIN(20),
+   LUTON_PIN(21),
+   LUTON_PIN(22),
+   LUTON_PIN(23),
+   LUTON_PIN(24),
+   LUTON_PIN(25),
+   LUTON_PIN(26),
+   LUTON_PIN(27),
+   LUTON_PIN(28),
+   LUTON_PIN(29),
+   LUTON_PIN(30),
+   LUTON_PIN(31),
+};
+
 #define OCELOT_P(p, f0, f1, f2)
\
 static struct ocelot_pin_caps ocelot_pin_##p = {   \
.pin = p,   \
@@ -868,6 +950,15 @@ static const struct pinctrl_ops ocelot_pctl_ops = {
.dt_free_map = pinconf_generic_dt_free_map,
 };
 
+static struct pinctrl_desc luton_desc = {
+   .name = "luton-pinctrl",
+   .pins = luton_pins,
+   .npins = ARRAY_SIZE(luton_pins),
+   .pctlops = _pctl_ops,
+   .pmxops = _pmx_ops,
+   .owner = THIS_MODULE,
+};
+
 static struct pinctrl_desc ocelot_desc = {
.name = "ocelot-pinctrl",
.pins = ocelot_pins,
@@ -1151,6 +1242,7 @@ static int ocelot_gpiochip_register(struct 
platform_device *pdev,
 }
 
 static const struct of_device_id ocelot_pinctrl_of_match[] = {
+   { .compatible = "mscc,luton-pinctrl", .data = _desc },
{ .compatible = "mscc,ocelot-pinctrl", .data = _desc },
{ .compatible = "mscc,jaguar2-pinctrl", .data = _desc },
{ .compatible = "microchip,sparx5-pinctrl", .data = _desc },
-- 
2.28.0



[PATCH 4/4] pinctrl: ocelot: Add support for Serval platforms

2020-11-06 Thread Gregory CLEMENT
From: Lars Povlsen 

This patch adds support for Serval pinctrl, using the ocelot driver as
basis. It adds pinconfig support as well, as supported by the
platform.

gclement: Split from a larger patch adding support all platforms in
the same time.

Signed-off-by: Lars Povlsen 
Signed-off-by: Gregory CLEMENT 
---
 drivers/pinctrl/pinctrl-ocelot.c | 92 
 1 file changed, 92 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index ab74c79d7cca..18336950fd95 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -240,6 +240,88 @@ static const struct pinctrl_pin_desc luton_pins[] = {
LUTON_PIN(31),
 };
 
+#define SERVAL_P(p, f0, f1, f2)
\
+static struct ocelot_pin_caps serval_pin_##p = {   \
+   .pin = p,   \
+   .functions = {  \
+   FUNC_GPIO, FUNC_##f0, FUNC_##f1, FUNC_##f2, \
+   },  \
+}
+
+SERVAL_P(0,  SG0,   NONE,  NONE);
+SERVAL_P(1,  SG0,   NONE,  NONE);
+SERVAL_P(2,  SG0,   NONE,  NONE);
+SERVAL_P(3,  SG0,   NONE,  NONE);
+SERVAL_P(4,  TACHO, NONE,  NONE);
+SERVAL_P(5,  PWM,   NONE,  NONE);
+SERVAL_P(6,  TWI,   NONE,  NONE);
+SERVAL_P(7,  TWI,   NONE,  NONE);
+SERVAL_P(8,  SI,NONE,  NONE);
+SERVAL_P(9,  SI,MD,NONE);
+SERVAL_P(10, SI,MD,NONE);
+SERVAL_P(11, SFP,   MD,TWI_SCL_M);
+SERVAL_P(12, SFP,   MD,TWI_SCL_M);
+SERVAL_P(13, SFP,   UART2, TWI_SCL_M);
+SERVAL_P(14, SFP,   UART2, TWI_SCL_M);
+SERVAL_P(15, SFP,   PTP0,  TWI_SCL_M);
+SERVAL_P(16, SFP,   PTP0,  TWI_SCL_M);
+SERVAL_P(17, SFP,   PCI_WAKE,  TWI_SCL_M);
+SERVAL_P(18, SFP,   NONE,  TWI_SCL_M);
+SERVAL_P(19, SFP,   NONE,  TWI_SCL_M);
+SERVAL_P(20, SFP,   NONE,  TWI_SCL_M);
+SERVAL_P(21, SFP,   NONE,  TWI_SCL_M);
+SERVAL_P(22, NONE,  NONE,  NONE);
+SERVAL_P(23, NONE,  NONE,  NONE);
+SERVAL_P(24, NONE,  NONE,  NONE);
+SERVAL_P(25, NONE,  NONE,  NONE);
+SERVAL_P(26, UART,  NONE,  NONE);
+SERVAL_P(27, UART,  NONE,  NONE);
+SERVAL_P(28, IRQ0,  NONE,  NONE);
+SERVAL_P(29, IRQ1,  NONE,  NONE);
+SERVAL_P(30, PTP0,  NONE,  NONE);
+SERVAL_P(31, PTP0,  NONE,  NONE);
+
+#define SERVAL_PIN(n) {\
+   .number = n,\
+   .name = "GPIO_"#n,  \
+   .drv_data = _pin_##n \
+}
+
+static const struct pinctrl_pin_desc serval_pins[] = {
+   SERVAL_PIN(0),
+   SERVAL_PIN(1),
+   SERVAL_PIN(2),
+   SERVAL_PIN(3),
+   SERVAL_PIN(4),
+   SERVAL_PIN(5),
+   SERVAL_PIN(6),
+   SERVAL_PIN(7),
+   SERVAL_PIN(8),
+   SERVAL_PIN(9),
+   SERVAL_PIN(10),
+   SERVAL_PIN(11),
+   SERVAL_PIN(12),
+   SERVAL_PIN(13),
+   SERVAL_PIN(14),
+   SERVAL_PIN(15),
+   SERVAL_PIN(16),
+   SERVAL_PIN(17),
+   SERVAL_PIN(18),
+   SERVAL_PIN(19),
+   SERVAL_PIN(20),
+   SERVAL_PIN(21),
+   SERVAL_PIN(22),
+   SERVAL_PIN(23),
+   SERVAL_PIN(24),
+   SERVAL_PIN(25),
+   SERVAL_PIN(26),
+   SERVAL_PIN(27),
+   SERVAL_PIN(28),
+   SERVAL_PIN(29),
+   SERVAL_PIN(30),
+   SERVAL_PIN(31),
+};
+
 #define OCELOT_P(p, f0, f1, f2)
\
 static struct ocelot_pin_caps ocelot_pin_##p = {   \
.pin = p,   \
@@ -959,6 +1041,15 @@ static struct pinctrl_desc luton_desc = {
.owner = THIS_MODULE,
 };
 
+static struct pinctrl_desc serval_desc = {
+   .name = "serval-pinctrl",
+   .pins = serval_pins,
+   .npins = ARRAY_SIZE(serval_pins),
+   .pctlops = _pctl_ops,
+   .pmxops = _pmx_ops,
+   .owner = THIS_MODULE,
+};
+
 static struct pinctrl_desc ocelot_desc = {
.name = "ocelot-pinctrl",
.pins = ocelot_pins,
@@ -1243,6 +1334,7 @@ static int ocelot_gpiochip_register(struct 
platform_device *pdev,
 
 static const struct of_device_id ocelot_pinctrl_of_match[] = {
{ .compatible = "mscc,luton-pinctrl", .data = _desc },
+   { .compatible = "mscc,serval-pinctrl", .data = _desc },
{ .compatible = "mscc,ocelot-pinctrl", .data = _desc },
{ .compatible = "mscc,jaguar2-pinctrl", .data = _desc },
{ .compatible = "microchip,sparx5-pinctrl", .data = _desc },
-- 
2.28.0



[PATCH 0/4] Extend pinctrl ocelot driver to support other SoCs

2020-11-06 Thread Gregory CLEMENT
Hello,

Ocelot SoC belongs to a larger family of SoCs which use the same
interrupt controller with a few variation.

This series of patches add support for Luton and Serval, they are all
MIPS based.

The first patches of the series also updates the binding documentation
with the new compatible strings.

Gregory

Gregory CLEMENT (2):
  dt-bindings: pinctrl: ocelot: Add Luton SoC support
  dt-bindings: pinctrl: ocelot: Add Serval SoC support

Lars Povlsen (2):
  pinctrl: ocelot: Add support for Luton platforms
  pinctrl: ocelot: Add support for Serval platforms

 .../bindings/pinctrl/mscc,ocelot-pinctrl.txt  |   3 +-
 drivers/pinctrl/pinctrl-ocelot.c  | 184 ++
 2 files changed, 186 insertions(+), 1 deletion(-)

-- 
2.28.0



[PATCH 2/4] dt-bindings: pinctrl: ocelot: Add Serval SoC support

2020-11-06 Thread Gregory CLEMENT
Add the documentation for the Microsemi Serval pinmuxing and gpio
controller.

Signed-off-by: Gregory CLEMENT 
---
 .../devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
index 58ea2ae57713..db99bd95d423 100644
--- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt
@@ -3,8 +3,8 @@ Microsemi Ocelot pin controller Device Tree Bindings
 
 Required properties:
  - compatible  : Should be "mscc,ocelot-pinctrl",
- "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl"
- or "mscc,luton-pinctrl"
+ "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl",
+ "mscc,luton-pinctrl" or "mscc,serval-pinctrl"
  - reg : Address and length of the register set for the device
  - gpio-controller : Indicates this device is a GPIO controller
  - #gpio-cells : Must be 2.
-- 
2.28.0



[PATCH 4/6] irqchip: ocelot: Add support for Luton platforms

2020-11-05 Thread Gregory CLEMENT
This patch extends irqchip driver for oceleot to be used with an other
vcoreiii base platform: Luton.

Based on a larger patch from Lars Povlsen 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 145 +-
 1 file changed, 123 insertions(+), 22 deletions(-)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 88143c0b700c..9964800c53c2 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -12,39 +12,115 @@
 #include 
 #include 
 
-#define ICPU_CFG_INTR_INTR_STICKY  0x10
-#define ICPU_CFG_INTR_INTR_ENA 0x18
-#define ICPU_CFG_INTR_INTR_ENA_CLR 0x1c
-#define ICPU_CFG_INTR_INTR_ENA_SET 0x20
-#define ICPU_CFG_INTR_DST_INTR_IDENT(x)(0x38 + 0x4 * (x))
-#define ICPU_CFG_INTR_INTR_TRIGGER(x)  (0x5c + 0x4 * (x))
-
-#define OCELOT_NR_IRQ 24
+#define ICPU_CFG_INTR_DST_INTR_IDENT(_p, x)(_p->reg_off_ident + 0x4 * (x))
+#define ICPU_CFG_INTR_INTR_TRIGGER(_p, x)  (_p->reg_off_trigger + 0x4 * 
(x))
+
+#define FLAGS_NEED_INIT_ENABLE BIT(0)
+#define FLAGS_FORCE_LUTON_STYLEBIT(1)
+#define FLAGS_HAS_TRIGGER  BIT(2)
+
+struct chip_props {
+   u32 flags;
+   u32 reg_off_sticky;
+   u32 reg_off_ena;
+   u32 reg_off_ena_clr;
+   u32 reg_off_ena_set;
+   u32 reg_off_ident;
+   u32 reg_off_trigger;
+   u32 reg_off_force;
+   u32 reg_off_ena_irq0;
+   u32 n_irq;
+};
+
+static const struct chip_props ocelot_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .reg_off_force  = 0xc,
+   .n_irq  = 24,
+};
+
+static const struct chip_props luton_props = {
+   .flags  = FLAGS_NEED_INIT_ENABLE |
+ FLAGS_FORCE_LUTON_STYLE,
+   .reg_off_sticky = 0,
+   .reg_off_ena= 0x4,
+   .reg_off_ena_clr= 0x8,
+   .reg_off_ena_set= 0xc,
+   .reg_off_ident  = 0x18,
+   .reg_off_trigger= 0,
+   .reg_off_force  = 0x38,
+   .reg_off_ena_irq0   = 0x14,
+   .n_irq  = 28,
+};
 
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct irq_domain *d = data->domain;
+   struct chip_props *p = d->host_data;
struct irq_chip_type *ct = irq_data_get_chip_type(data);
unsigned int mask = data->mask;
u32 val;
 
irq_gc_lock(gc);
-   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(0)) |
- irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(1));
-   if (!(val & mask))
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_STICKY);
+   if (p->flags & FLAGS_HAS_TRIGGER) {
+   val = irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 0)) |
+   irq_reg_readl(gc, ICPU_CFG_INTR_INTR_TRIGGER(p, 1));
+   if (!(val & mask))
+   irq_reg_writel(gc, mask, p->reg_off_sticky);
+   }
 
*ct->mask_cache &= ~mask;
-   irq_reg_writel(gc, mask, ICPU_CFG_INTR_INTR_ENA_SET);
+   irq_reg_writel(gc, mask, p->reg_off_ena_set);
irq_gc_unlock(gc);
 }
 
+static void luton_irq_force(struct irq_data *data,
+   struct irq_chip_generic *gc,
+   struct chip_props *p)
+{
+   int off = p->reg_off_force + (data->hwirq * sizeof(u32));
+   u32 val = irq_reg_readl(gc, off);
+
+   irq_reg_writel(gc, val | BIT(3), off);
+}
+
+static int ocelot_irq_force(struct irq_data *data,
+   enum irqchip_irq_state which, bool state)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct irq_domain *d = data->domain;
+   struct chip_props *p = d->host_data;
+   int ret = -EINVAL;
+
+   /* Only supports triggering */
+   if ((which == IRQCHIP_STATE_PENDING ||
+which == IRQCHIP_STATE_ACTIVE) &&
+   state && p->reg_off_force) {
+   if (p->flags & FLAGS_FORCE_LUTON_STYLE)
+   /* Config register style */
+   luton_irq_force(data, gc, p);
+   else
+   /* New, bitmask style */
+   irq_reg_writel(gc, data->mask, p->reg_off_force);
+   ret = 0;
+   }
+
+   return ret;
+}
+
 static void ocelot_irq_handler(struct irq_desc *desc)
 {
struct irq_chip *chip = irq_desc_get_chip(desc);
struct irq_domain *d = irq_desc_get_handler_data(desc);
+   struct chip_props *p = d->host_

[PATCH 1/6] dt-bindings: interrupt-controller: Add binding for the Microsemi Luton interrupt controller

2020-11-05 Thread Gregory CLEMENT
Add the Device Tree binding documentation for the Microsemi Luton
interrupt controller that is part of the ICPU. It is connected directly to
the MIPS core interrupt controller.

Signed-off-by: Gregory CLEMENT 
---
 .../bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt   | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
index f5baeccb689f..94dc95cb815c 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
@@ -1,8 +1,10 @@
 Microsemi Ocelot SoC ICPU Interrupt Controller
 
+Luton belongs the same family of Ocelot: the VCoreIII family
+
 Required properties:
 
-- compatible : should be "mscc,ocelot-icpu-intr"
+- compatible : should be "mscc,ocelot-icpu-intr" or "mscc,luton-icpu-intr"
 - reg : Specifies base physical address and size of the registers.
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
-- 
2.28.0



[PATCH 0/6] Extend irqchip ocelot driver to support other SoCs

2020-11-05 Thread Gregory CLEMENT
Hello,

Ocelot SoC belongs to a larger family of SoCs which use the same
interrupt controller with a few variation.

This series of patches add support for Luton, Serval and Jaguar2, they
are all MIPS based.

The first patches of the series also updates the binding documentation
with the new compatible strings.

Gregory

Gregory CLEMENT (6):
  dt-bindings: interrupt-controller: Add binding for the Microsemi Luton
interrupt controller
  dt-bindings: interrupt-controller: Add binding for the Microsemi
Serval interrupt controller
  dt-bindings: interrupt-controller: Add binding for the Microsemi
Jaguar2 interrupt controller
  irqchip: ocelot: Add support for Luton platforms
  irqchip: ocelot: Add support for Serval platforms
  irqchip: ocelot: Add support for Jaguar2 platforms

 .../mscc,ocelot-icpu-intr.txt |   6 +-
 drivers/irqchip/irq-mscc-ocelot.c | 183 --
 2 files changed, 167 insertions(+), 22 deletions(-)

-- 
2.28.0



[PATCH 3/6] dt-bindings: interrupt-controller: Add binding for the Microsemi Jaguar2 interrupt controller

2020-11-05 Thread Gregory CLEMENT
Add the Device Tree binding documentation for the Microsemi Jaguar2
interrupt controller that is part of the ICPU. It is connected directly to
the MIPS core interrupt controller.

Signed-off-by: Gregory CLEMENT 
---
 .../interrupt-controller/mscc,ocelot-icpu-intr.txt | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
index 42de86e023a6..916832064d64 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
@@ -1,11 +1,12 @@
 Microsemi Ocelot SoC ICPU Interrupt Controller
 
-Luton and Servals belong the same family as Ocelot: the VCoreIII family
+Luton, Servals and Jaguar 2 belong the same family as Ocelot: the
+VCoreIII family
 
 Required properties:
 
-- compatible : should be "mscc,ocelot-icpu-intr" or "mscc,luton-icpu-intr"
-   or "mscc,serval-icpu-intr"
+- compatible : should be "mscc,ocelot-icpu-intr", "mscc,luton-icpu-intr",
+   "mscc,serval-icpu-intr" or "mscc,jaguar2-icpu-intr"
 - reg : Specifies base physical address and size of the registers.
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
-- 
2.28.0



[PATCH 5/6] irqchip: ocelot: Add support for Serval platforms

2020-11-05 Thread Gregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Serval.

Based on a larger patch from Lars Povlsen 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 9964800c53c2..584af3b0a9e2 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -44,6 +44,18 @@ static const struct chip_props ocelot_props = {
.n_irq  = 24,
 };
 
+static const struct chip_props serval_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0xc,
+   .reg_off_ena= 0x14,
+   .reg_off_ena_clr= 0x18,
+   .reg_off_ena_set= 0x1c,
+   .reg_off_ident  = 0x20,
+   .reg_off_trigger= 0x4,
+   .reg_off_force  = 0x8,
+   .n_irq  = 24,
+};
+
 static const struct chip_props luton_props = {
.flags  = FLAGS_NEED_INIT_ENABLE |
  FLAGS_FORCE_LUTON_STYLE,
@@ -210,6 +222,14 @@ static int __init ocelot_irq_init(struct device_node *node,
 
 IRQCHIP_DECLARE(ocelot_icpu, "mscc,ocelot-icpu-intr", ocelot_irq_init);
 
+static int __init serval_irq_init(struct device_node *node,
+ struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(serval_icpu, "mscc,serval-icpu-intr", serval_irq_init);
+
 static int __init luton_irq_init(struct device_node *node,
 struct device_node *parent)
 {
-- 
2.28.0



[PATCH 6/6] irqchip: ocelot: Add support for Jaguar2 platforms

2020-11-05 Thread Gregory CLEMENT
This patch extends irqchip driver for ocelot to be used with an other
vcoreiii base platform: Jaguar2.

Based on a larger patch from Lars Povlsen 
Signed-off-by: Gregory CLEMENT 
---
 drivers/irqchip/irq-mscc-ocelot.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/irqchip/irq-mscc-ocelot.c 
b/drivers/irqchip/irq-mscc-ocelot.c
index 584af3b0a9e2..0dfea8771172 100644
--- a/drivers/irqchip/irq-mscc-ocelot.c
+++ b/drivers/irqchip/irq-mscc-ocelot.c
@@ -70,6 +70,18 @@ static const struct chip_props luton_props = {
.n_irq  = 28,
 };
 
+static const struct chip_props jaguar2_props = {
+   .flags  = FLAGS_HAS_TRIGGER,
+   .reg_off_sticky = 0x10,
+   .reg_off_ena= 0x18,
+   .reg_off_ena_clr= 0x1c,
+   .reg_off_ena_set= 0x20,
+   .reg_off_ident  = 0x38,
+   .reg_off_trigger= 0x5c,
+   .reg_off_force  = 0xc,
+   .n_irq  = 29,
+};
+
 static void ocelot_irq_unmask(struct irq_data *data)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
@@ -237,3 +249,11 @@ static int __init luton_irq_init(struct device_node *node,
 }
 
 IRQCHIP_DECLARE(luton_icpu, "mscc,luton-icpu-intr", luton_irq_init);
+
+static int __init jaguar2_irq_init(struct device_node *node,
+  struct device_node *parent)
+{
+   return vcoreiii_irq_init(node, parent, _props);
+}
+
+IRQCHIP_DECLARE(jaguar2_icpu, "mscc,jaguar2-icpu-intr", jaguar2_irq_init);
-- 
2.28.0



[PATCH 2/6] dt-bindings: interrupt-controller: Add binding for the Microsemi Serval interrupt controller

2020-11-05 Thread Gregory CLEMENT
Add the Device Tree binding documentation for the Microsemi Serval
interrupt controller that is part of the ICPU. It is connected directly to
the MIPS core interrupt controller.

Signed-off-by: Gregory CLEMENT 
---
 .../bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt| 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
index 94dc95cb815c..42de86e023a6 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/mscc,ocelot-icpu-intr.txt
@@ -1,10 +1,11 @@
 Microsemi Ocelot SoC ICPU Interrupt Controller
 
-Luton belongs the same family of Ocelot: the VCoreIII family
+Luton and Servals belong the same family as Ocelot: the VCoreIII family
 
 Required properties:
 
 - compatible : should be "mscc,ocelot-icpu-intr" or "mscc,luton-icpu-intr"
+   or "mscc,serval-icpu-intr"
 - reg : Specifies base physical address and size of the registers.
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
-- 
2.28.0



Re: [PATCH] arm64: dts: marvell: espressobin: De-duplicate eMMC definitions

2020-10-05 Thread Gregory CLEMENT
Hi Pali,

> On Sunday 27 September 2020 08:40:41 Andre Heider wrote:
>> On 25/09/2020 10:50, Pali Rohár wrote:
>> > eMMC definitions in files armada-3720-espressobin-emmc.dts and
>> > armada-3720-espressobin-v7-emmc.dts is same. So move it into common
>> > armada-3720-espressobin.dtsi file with status "disabled".
>> > 
>> > This change simplifies eMMC variants of DTS files for Espressobin.
>> > 
>> > Signed-off-by: Pali Rohár 
>> 
>> Reviewed-by: Andre Heider 
>> Tested-by: Andre Heider 
>> 
>> > ---
>> > Compiled DTB files armada-3720-espressobin-emmc.dtb and
>> > armada-3720-espressobin-v7-emmc.dtb are identical as without applying
>> > this patch.
>> > 
>> > Files armada-3720-espressobin.dtb and armada-3720-espressobin-v7.dtb
>> > are slightly different compared to version without this patch.
>> > 
>> > Main change is that numering in all "phandle" nodes is shifted and
>> > "sdhci0" node contains more attributes, but node is disabled.
>> > 
>> > 
>> > Andre, could you test this change on Espressobin (without eMMC) if
>> > everything is OK and there is no issue?
>> 
>> Look good to me, the node appears with status=disabled and everything seems
>> to work as before.
>
> Great!
>
> Gregory, would do you think about including this patch into next queue
> too?


I've applied on mvebu/dt64, however I am not sure I will be able to make
it merged for 5.10, but I will try.

Thanks,

Gregory


>
>> > 
>> > ---
>> >   .../marvell/armada-3720-espressobin-emmc.dts  | 18 --
>> >   .../armada-3720-espressobin-v7-emmc.dts   | 18 --
>> >   .../dts/marvell/armada-3720-espressobin.dtsi  | 24 +++
>> >   3 files changed, 24 insertions(+), 36 deletions(-)
>> > 
>> > diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-emmc.dts 
>> > b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-emmc.dts
>> > index ec72a11ed80f..5c4d8f379704 100644
>> > --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-emmc.dts
>> > +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-emmc.dts
>> > @@ -21,24 +21,6 @@
>> > "marvell,armada3720", "marvell,armada3710";
>> >   };
>> > -/* U11 */
>> >{
>> > -  non-removable;
>> > -  bus-width = <8>;
>> > -  mmc-ddr-1_8v;
>> > -  mmc-hs400-1_8v;
>> > -  marvell,xenon-emmc;
>> > -  marvell,xenon-tun-count = <9>;
>> > -  marvell,pad-type = "fixed-1-8v";
>> > -
>> > -  pinctrl-names = "default";
>> > -  pinctrl-0 = <_pins>;
>> >status = "okay";
>> > -
>> > -  #address-cells = <1>;
>> > -  #size-cells = <0>;
>> > -  mmccard: mmccard@0 {
>> > -  compatible = "mmc-card";
>> > -  reg = <0>;
>> > -  };
>> >   };
>> > diff --git 
>> > a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts 
>> > b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
>> > index 6062a7df7342..4775a7eda481 100644
>> > --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
>> > +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
>> > @@ -36,24 +36,6 @@
>> >label = "wan";
>> >   };
>> > -/* U11 */
>> >{
>> > -  non-removable;
>> > -  bus-width = <8>;
>> > -  mmc-ddr-1_8v;
>> > -  mmc-hs400-1_8v;
>> > -  marvell,xenon-emmc;
>> > -  marvell,xenon-tun-count = <9>;
>> > -  marvell,pad-type = "fixed-1-8v";
>> > -
>> > -  pinctrl-names = "default";
>> > -  pinctrl-0 = <_pins>;
>> >status = "okay";
>> > -
>> > -  #address-cells = <1>;
>> > -  #size-cells = <0>;
>> > -  mmccard: mmccard@0 {
>> > -  compatible = "mmc-card";
>> > -  reg = <0>;
>> > -  };
>> >   };
>> > diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi 
>> > b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
>> > index 3169a820558f..8a1c678bea5f 100644
>> > --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
>> > +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
>> > @@ -58,6 +58,30 @@
>> >phy-names = "sata-phy";
>> >   };
>> > +/* U11 */
>> > + {
>> > +  /* Main DTS file for Espressobin is without eMMC */
>> > +  status = "disabled";
>> > +
>> > +  non-removable;
>> > +  bus-width = <8>;
>> > +  mmc-ddr-1_8v;
>> > +  mmc-hs400-1_8v;
>> > +  marvell,xenon-emmc;
>> > +  marvell,xenon-tun-count = <9>;
>> > +  marvell,pad-type = "fixed-1-8v";
>> > +
>> > +  pinctrl-names = "default";
>> > +  pinctrl-0 = <_pins>;
>> > +
>> > +  #address-cells = <1>;
>> > +  #size-cells = <0>;
>> > +  mmccard: mmccard@0 {
>> > +  compatible = "mmc-card";
>> > +  reg = <0>;
>> > +  };
>> > +};
>> > +
>> >   /* J1 */
>> >{
>> >wp-inverted;
>> > 
>> 

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH] arm64: dts: marvell: espressobin: Update link to V7 schematic

2020-09-25 Thread Gregory CLEMENT
Hello Pali,

could you add a commit log besides the topic ?

Also note that I've just sent the pull requests for 5.10 and I was
already a little late for that, so I fear this patch will be for 5.11.

Unless the former url was broken it this case it could be considered as
a fixe and could be applied for 5.9. If you think it, you should also
add a "Fixes:" tag.

Thank,

Gregory

> Signed-off-by: Pali Rohár 
> ---
>  arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts | 2 +-
>  arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts 
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> index 61d49d6a2a2a..6062a7df7342 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> @@ -8,7 +8,7 @@
>   *
>   */
>  /*
> - * Schematic available at 
> http://wiki.espressobin.net/tiki-download_file.php?fileId=200
> + * Schematic available at 
> http://espressobin.net/wp-content/uploads/2020/05/ESPRESSObin_V7-0_Schematic.pdf
>   */
>  
>  /dts-v1/;
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts 
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> index 44dbe9a21cc7..c47a93978386 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> @@ -8,7 +8,7 @@
>   *
>   */
>  /*
> - * Schematic available at 
> http://wiki.espressobin.net/tiki-download_file.php?fileId=200
> + * Schematic available at 
> http://espressobin.net/wp-content/uploads/2020/05/ESPRESSObin_V7-0_Schematic.pdf
>   */
>  
>  /dts-v1/;
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH] arm64: dts: marvell: espressobin: Add ethernet switch aliases

2020-09-24 Thread Gregory CLEMENT
Hi Pali,

> On Tuesday 08 September 2020 09:47:33 Pali Rohár wrote:
>> On Monday 07 September 2020 19:23:45 Andrew Lunn wrote:
>> > On Mon, Sep 07, 2020 at 06:13:16PM +0200, Pali Rohár wrote:
>> > > On Monday 07 September 2020 17:43:53 Andrew Lunn wrote:
>> > > > > I would not say it is a "new feature". But rather that patch in this
>> > > > > email fixes issue that Linux kernel did not set correct MAC address 
>> > > > > for
>> > > > > DSA slave ports. I think it is something which could be backported 
>> > > > > also
>> > > > > to stable releases as "ignoring" vendor/factory MAC address is not
>> > > > > correct behavior.
>> > > > 
>> > > > Hi Pali
>> > > > 
>> > > > The rules for stable are here:
>> > > > 
>> > > > https://www.kernel.org/doc/html/v5.8/process/stable-kernel-rules.html
>> > > > 
>> > > > Do you think it fits?
>> > > > 
>> > > >Andrew
>> > > 
>> > > Hello Andrew! I think it fits into those rules. As I wrote it fixes real
>> > > bug that Linux kernel does not use correct MAC address for particular
>> > > DSA slaves / ethernet ports.
>> > 
>> > O.K, then:
>> > 
>> > Reviewed-by: Andrew Lunn 
>> > 
>> > Andrew
>> 
>> Ok! Andrew, I would like to ask another question, how to correctly
>> define that this patch depends on a2c7023f7075c? I specified it in
>> human-readable part of commit description, but for backporting it would
>> also need some machine-readable format. So patch would not be
>> occasionally backported to older/stable kernel where a2c7023f7075c is
>> not available.
>
> Based on stable-kernel-rules.html document I think that following line
> should define this dependency in machine readable format:
>
> Cc:  # a2c7023f7075c: dsa: read mac address
>
> Gregory, if it is correct, would you add that line into commit sign-off
> area where is existing Fixes: line?

I amended the commit log with this change.

Thanks,

Gregory

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH] arm64: dts: marvell: espressobin: Get rid of duplicate serial aliases

2020-09-23 Thread Gregory CLEMENT
Hi Andre,

> The included armada-372x.dtsi already defines these two aliases.
>
> Signed-off-by: Andre Heider 

Applied on mvebu/dt

Thanks,

Gregory

> ---
>
> This goes on top of Pali's patch:
> "arm64: dts: marvell: espressobin: Add ethernet switch aliases"
>
> The resulting .dtb files are the same.
>
>  arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
> index 0775c16e0ec8..3169a820558f 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtsi
> @@ -17,8 +17,6 @@ aliases {
>   ethernet1 = 
>   ethernet2 = 
>   ethernet3 = 
> - serial0 = 
> -         serial1 = 
>   };
>  
>   chosen {
> -- 
> 2.28.0
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH] arm64: dts: marvell: espressobin: Simplify v7 ethernet port labeling

2020-09-23 Thread Gregory CLEMENT
Hi Andre,

> Now that the switch ports have a label in the .dtsi, simplify the whole
> "switch0" block for the v7 dts files.
>
> Signed-off-by: Andre Heider 

Applied on mvebu/dt64

Thanks,

Gregory

> ---
>
> This goes on top of Pali's patch:
> "arm64: dts: marvell: espressobin: Add ethernet switch aliases"
>
> The resulting .dtb files are the same.
>
>  .../armada-3720-espressobin-v7-emmc.dts| 18 +-
>  .../dts/marvell/armada-3720-espressobin-v7.dts | 18 +-
>  2 files changed, 10 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts 
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> index 215d2f702623..61d49d6a2a2a 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7-emmc.dts
> @@ -28,20 +28,12 @@ aliases {
>   };
>  };
>  
> - {
> - ports {
> - switch0port1: port@1 {
> - reg = <1>;
> - label = "lan1";
> - phy-handle = <>;
> - };
> + {
> + label = "lan1";
> +};
>  
> - switch0port3: port@3 {
> - reg = <3>;
> - label = "wan";
> - phy-handle = <>;
> - };
> - };
> + {
> + label = "wan";
>  };
>  
>  /* U11 */
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts 
> b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> index b6f4af8ebafb..44dbe9a21cc7 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-espressobin-v7.dts
> @@ -27,18 +27,10 @@ aliases {
>   };
>  };
>  
> - {
> - ports {
> - switch0port1: port@1 {
> - reg = <1>;
> - label = "lan1";
> - phy-handle = <>;
> -     };
> + {
> + label = "lan1";
> +};
>  
> - switch0port3: port@3 {
> - reg = <3>;
> - label = "wan";
> - phy-handle = <>;
> - };
> - };
> + {
> + label = "wan";
>  };
> -- 
> 2.28.0
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH] arm64: dts: marvell: espressobin: Add ethernet switch aliases

2020-09-23 Thread Gregory CLEMENT
{
> + switch0port1: port@1 {
>   reg = <1>;
>           label = "wan";
>   phy-handle = <>;
>   };
>  
> - port@2 {
> + switch0port2: port@2 {
>   reg = <2>;
>   label = "lan0";
>   phy-handle = <>;
>   };
>  
> - port@3 {
> + switch0port3: port@3 {
>   reg = <3>;
>   label = "lan1";
>   phy-handle = <>;
> -- 
> 2.20.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v2 0/3] 98dx3236 i2c related fixes

2020-09-23 Thread Gregory CLEMENT
Hi Chris,

> I noticed these while adding support for i2c recovery for a couple of our
> boards. They date back to when I initially added support for the 98dx3236. 
> They
> probably haven't been causing a problem because the HW defaults are correct 
> and
> unless you attempt to use the specific pinctrl functions there won't be a
> problem.
>
> Change in v2:
> - Fix grammo in patch 2/3
> - Add r-by from Andrew
>
> Chris Packham (3):
>   pinctrl: mvebu: Fix i2c sda definition for 98DX3236
>   ARM: dts: Remove non-existent i2c1 from 98dx3236
>   ARM: dts: Add i2c0 pinctrl information for 98dx3236

Applied the 2 dts pacthes on mvebu/dt

Thanks,

Gregory


>
>  arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 12 +++-
>  drivers/pinctrl/mvebu/pinctrl-armada-xp.c |  2 +-
>  2 files changed, 8 insertions(+), 6 deletions(-)
>
> -- 
> 2.28.0
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v3 13/15] ARM: dts: dove: fix PCA95xx GPIO expander properties on A510

2020-09-23 Thread Gregory CLEMENT
Hi Krzysztof,

> The PCA95xx GPIO expander requires GPIO controller properties to operate
> properly.

Applied on mvebu/dt

Thanks,

Gregory
>
> Signed-off-by: Krzysztof Kozlowski 
> Reviewed-by: Linus Walleij 
> ---
>  arch/arm/boot/dts/dove-sbc-a510.dts | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/dove-sbc-a510.dts 
> b/arch/arm/boot/dts/dove-sbc-a510.dts
> index 2bb85a9b7614..df021f9b0117 100644
> --- a/arch/arm/boot/dts/dove-sbc-a510.dts
> +++ b/arch/arm/boot/dts/dove-sbc-a510.dts
> @@ -143,6 +143,7 @@
>   gpio_ext: gpio@20 {
>   compatible = "nxp,pca9555";
>   reg = <0x20>;
> + gpio-controller;
>       #gpio-cells = <2>;
>   };
>  };
> -- 
> 2.17.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH 0/4] Add support for a series of MikroTik CRS3xx switches

2020-09-23 Thread Gregory CLEMENT
Hi Luka,

> These patches add support for a series of MikroTik CRS3xx switches
> based on the Marvell Prestera 98DX3236 switch chip.
>
> Namely, support is added for:
>  -  MikroTik CRS305-1G-4S+ (including the Bit variant)
>  -  MikroTik CRS326-24G-2S+ (including the Bit variant)
>  -  MikroTik CRS328-4C-20S-4S+ (including the Bit variant)
>
> The Bit board variant is added for each of the boards.
> These boards were modified to use a bigger Macronix flash.
>
> Currently only basic board support is added, but the support will
> be extended in a new patchset.
>
> Luka Kovacic (4):
>   arm: mvebu: dts: Add CRS326-24G-2S board
>   arm: mvebu: dts: Add CRS305-1G-4S board
>   arm: mvebu: dts: Add CRS328-4C-20S-4S board

These 3 patches have been applied on mvebu/dt

>   MAINTAINERS: Add an entry for MikroTik CRS3xx 98DX3236 boards

and this one on mvebu/arm

Thanks,

Gregory
>
>  MAINTAINERS   |  11 ++
>  arch/arm/boot/dts/Makefile|   6 +
>  .../boot/dts/armada-xp-crs305-1g-4s-bit.dts   |  43 
>  arch/arm/boot/dts/armada-xp-crs305-1g-4s.dts  |  17 +++
>  arch/arm/boot/dts/armada-xp-crs305-1g-4s.dtsi | 104 ++
>  .../boot/dts/armada-xp-crs326-24g-2s-bit.dts  |  43 
>  arch/arm/boot/dts/armada-xp-crs326-24g-2s.dts |  17 +++
>  .../arm/boot/dts/armada-xp-crs326-24g-2s.dtsi | 104 ++
>  .../dts/armada-xp-crs328-4c-20s-4s-bit.dts|  43 
>  .../boot/dts/armada-xp-crs328-4c-20s-4s.dts   |  17 +++
>  .../boot/dts/armada-xp-crs328-4c-20s-4s.dtsi  | 104 ++
>  11 files changed, 509 insertions(+)
>  create mode 100644 arch/arm/boot/dts/armada-xp-crs305-1g-4s-bit.dts
>  create mode 100644 arch/arm/boot/dts/armada-xp-crs305-1g-4s.dts
>  create mode 100644 arch/arm/boot/dts/armada-xp-crs305-1g-4s.dtsi
>  create mode 100644 arch/arm/boot/dts/armada-xp-crs326-24g-2s-bit.dts
>  create mode 100644 arch/arm/boot/dts/armada-xp-crs326-24g-2s.dts
>  create mode 100644 arch/arm/boot/dts/armada-xp-crs326-24g-2s.dtsi
>  create mode 100644 arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s-bit.dts
>  create mode 100644 arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s.dts
>  create mode 100644 arch/arm/boot/dts/armada-xp-crs328-4c-20s-4s.dtsi
>
> -- 
> 2.26.2
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v3 14/15] ARM: dts: armada: align GPIO hog names with dtschema

2020-09-23 Thread Gregory CLEMENT
Hi Krzysztof,

> The convention for node names is to use hyphens, not underscores.
> dtschema for pca95xx expects GPIO hogs to end with 'hog' prefix.


Applied on mvebu/dt

Thanks,

Gregory

>
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/arm/boot/dts/armada-388-clearfog.dts  |  4 ++--
>  arch/arm/boot/dts/armada-388-clearfog.dtsi | 10 +-
>  arch/arm/boot/dts/armada-388-helios4.dts   |  6 +++---
>  3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts 
> b/arch/arm/boot/dts/armada-388-clearfog.dts
> index 20f8d4667753..4140a5303b48 100644
> --- a/arch/arm/boot/dts/armada-388-clearfog.dts
> +++ b/arch/arm/boot/dts/armada-388-clearfog.dts
> @@ -73,13 +73,13 @@
>* 14-SFP_TX_DISABLE
>* 15-SFP_MOD_DEF0
>*/
> - pcie2_0_clkreq {
> + pcie2-0-clkreq-hog {
>   gpio-hog;
>   gpios = <4 GPIO_ACTIVE_LOW>;
>   input;
>   line-name = "pcie2.0-clkreq";
>   };
> - pcie2_0_w_disable {
> + pcie2-0-w-disable-hog {
>   gpio-hog;
>   gpios = <7 GPIO_ACTIVE_LOW>;
>   output-low;
> diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi 
> b/arch/arm/boot/dts/armada-388-clearfog.dtsi
> index a0aa1d188f0c..f8a06ae4a3c9 100644
> --- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
> +++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
> @@ -141,31 +141,31 @@
>   #gpio-cells = <2>;
>   reg = <0x20>;
>  
> - pcie1_0_clkreq {
> + pcie1-0-clkreq-hog {
>   gpio-hog;
>   gpios = <0 GPIO_ACTIVE_LOW>;
>   input;
>   line-name = "pcie1.0-clkreq";
>   };
> - pcie1_0_w_disable {
> + pcie1-0-w-disable-hog {
>   gpio-hog;
>   gpios = <3 GPIO_ACTIVE_LOW>;
>   output-low;
>   line-name = "pcie1.0-w-disable";
>   };
> - usb3_ilimit {
> + usb3-ilimit-hog {
>   gpio-hog;
>   gpios = <5 GPIO_ACTIVE_LOW>;
>   input;
>   line-name = "usb3-current-limit";
>   };
> - usb3_power {
> + usb3-power-hog {
>   gpio-hog;
>   gpios = <6 GPIO_ACTIVE_HIGH>;
>   output-high;
>   line-name = "usb3-power";
>   };
> - m2_devslp {
> + m2-devslp-hog {
>   gpio-hog;
>   gpios = <11 GPIO_ACTIVE_HIGH>;
>   output-low;
> diff --git a/arch/arm/boot/dts/armada-388-helios4.dts 
> b/arch/arm/boot/dts/armada-388-helios4.dts
> index fb49df2a3bce..b3728de3bd3f 100644
> --- a/arch/arm/boot/dts/armada-388-helios4.dts
> +++ b/arch/arm/boot/dts/armada-388-helios4.dts
> @@ -166,19 +166,19 @@
>   interrupt-controller;
>   #interrupt-cells = <2>;
>  
> - board_rev_bit_0 {
> + board-rev-bit-0-hog {
>   gpio-hog;
>   gpios = <0 GPIO_ACTIVE_LOW>;
>   input;
>   line-name = "board-rev-0";
>   };
> - board_rev_bit_1 {
> + board-rev-bit-1-hog {
>   gpio-hog;
>   gpios = <1 GPIO_ACTIVE_LOW>;
>   input;
>           line-name = "board-rev-1";
>   };
> - usb3_ilimit {
> + usb3-ilimit-hog {
>   gpio-hog;
>   gpios = <5 GPIO_ACTIVE_HIGH>;
>   input;
> -- 
> 2.17.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v4 4/4] arm64: dts: marvell: add SMMU support

2020-07-18 Thread Gregory CLEMENT
Tomasz Nowicki  writes:

> From: Marcin Wojtas 
>
> Add IOMMU node for Marvell AP806 based SoCs together with platform
> and PCI device Stream ID mapping.
>
> Signed-off-by: Marcin Wojtas 
> Signed-off-by: Tomasz Nowicki 

Applied on mvebu/dt64

Thanks,

Gregory
> ---
>  arch/arm64/boot/dts/marvell/armada-7040.dtsi  | 28 +
>  arch/arm64/boot/dts/marvell/armada-8040.dtsi  | 40 +++
>  arch/arm64/boot/dts/marvell/armada-ap80x.dtsi | 18 +
>  3 files changed, 86 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-7040.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-7040.dtsi
> index 47247215770d..7a3198cd7a07 100644
> --- a/arch/arm64/boot/dts/marvell/armada-7040.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-7040.dtsi
> @@ -14,3 +14,31 @@
>   compatible = "marvell,armada7040", "marvell,armada-ap806-quad",
>"marvell,armada-ap806";
>  };
> +
> + {
> + status = "okay";
> +};
> +
> +_pcie0 {
> + iommu-map =
> + <0x00x480 0x20>,
> + <0x100  0x4a0 0x20>,
> + <0x200  0x4c0 0x20>;
> + iommu-map-mask = <0x031f>;
> +};
> +
> +_sata0 {
> + iommus = < 0x444>;
> +};
> +
> +_sdhci0 {
> + iommus = < 0x445>;
> +};
> +
> +_usb3_0 {
> + iommus = < 0x440>;
> +};
> +
> +_usb3_1 {
> + iommus = < 0x441>;
> +};
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-8040.dtsi
> index 7699b19224c2..79e8ce59baa8 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-8040.dtsi
> @@ -15,6 +15,18 @@
>"marvell,armada-ap806";
>  };
>  
> + {
> + status = "okay";
> +};
> +
> +_pcie0 {
> + iommu-map =
> + <0x00x480 0x20>,
> + <0x100  0x4a0 0x20>,
> + <0x200  0x4c0 0x20>;
> + iommu-map-mask = <0x031f>;
> +};
> +
>  /* The RTC requires external oscillator. But on Aramda 80x0, the RTC clock
>   * in CP master is not connected (by package) to the oscillator. So
>   * disable it. However, the RTC clock in CP slave is connected to the
> @@ -23,3 +35,31 @@
>  _rtc {
>   status = "disabled";
>  };
> +
> +_sata0 {
> + iommus = < 0x444>;
> +};
> +
> +_sdhci0 {
> + iommus = < 0x445>;
> +};
> +
> +_usb3_0 {
> + iommus = < 0x440>;
> +};
> +
> +_usb3_1 {
> + iommus = < 0x441>;
> +};
> +
> +_sata0 {
> + iommus = < 0x454>;
> +};
> +
> +_usb3_0 {
> + iommus = < 0x450>;
> +};
> +
> +_usb3_1 {
> + iommus = < 0x451>;
> +};
> diff --git a/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> index 7f9b9a647717..12e477f1aeb9 100644
> --- a/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> @@ -56,6 +56,24 @@
>   compatible = "simple-bus";
>   ranges = <0x0 0x0 0xf000 0x100>;
>  
> + smmu: iommu@500 {
> + compatible = "marvell,ap806-smmu-500", 
> "arm,mmu-500";
> + reg = <0x10 0x10>;
> + dma-coherent;
> + #iommu-cells = <1>;
> + #global-interrupts = <1>;
> + interrupts = ,
> +  ,
> +      ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ,
> +  ;
> + status = "disabled";
> + };
> +
>   gic: interrupt-controller@21 {
>   compatible = "arm,gic-400";
>   #interrupt-cells = <3>;
> -- 
> 2.17.1
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v4 0/4] Add system mmu support for Armada-806

2020-07-18 Thread Gregory CLEMENT
Hello,

> czw., 16 lip 2020 o 14:02 Will Deacon  napisał(a):
>>
>> On Thu, Jul 16, 2020 at 01:00:43PM +0100, Will Deacon wrote:
>> > On Wed, 15 Jul 2020 09:06:45 +0200, Tomasz Nowicki wrote:
>> > > The series is meant to support SMMU for AP806 and a workaround
>> > > for accessing ARM SMMU 64bit registers is the gist of it.
>> > >
>> > > For the record, AP-806 can't access SMMU registers with 64bit width.
>> > > This patches split the readq/writeq into two 32bit accesses instead
>> > > and update DT bindings.
>> > >
>> > > [...]
>> >
>> > Applied to will (for-joerg/arm-smmu/updates), thanks!
>> >
>> > [1/3] iommu/arm-smmu: Call configuration impl hook before consuming 
>> > features
>> >   https://git.kernel.org/will/c/6a79a5a3842b
>> > [2/3] iommu/arm-smmu: Workaround for Marvell Armada-AP806 SoC erratum 
>> > #582743
>> >   https://git.kernel.org/will/c/f2d9848aeb9f
>> > [3/3] dt-bindings: arm-smmu: add compatible string for Marvell 
>> > Armada-AP806 SMMU-500
>> >   https://git.kernel.org/will/c/e85e84d19b9d
>>
>> (note that I left patch 4 for arm-soc, as that's just updating .dts files)
>>
>
> Hi Gregory,
>
> Can you please help with the review/merge of patch #4?

Sure!

I've followed the series since the v1 even if I didn't commetn and I am
happy that it finally managed to be merged. I can now remove it from
my TODO list! :)

Gregory


>
> Best regards,
> Marcin

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH] ARM: dts: kirkwood: Replace HTTP links with HTTPS ones

2020-07-18 Thread Gregory CLEMENT
"Alexander A. Klimov"  writes:

> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov 

Applied on mvebu/dt

Thanks,

Gregory
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
>
>  If there are any URLs to be removed completely or at least not just 
> HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
>
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
>
>  If you apply the patch, please let me know.
>
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
>
>
>  arch/arm/boot/dts/kirkwood-b3.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/kirkwood-b3.dts 
> b/arch/arm/boot/dts/kirkwood-b3.dts
> index 17f48f88a983..a7636fe28501 100644
> --- a/arch/arm/boot/dts/kirkwood-b3.dts
> +++ b/arch/arm/boot/dts/kirkwood-b3.dts
> @@ -9,7 +9,7 @@
>   * L2 cache. If your B3 silently fails to boot, u-boot is probably too
>   * old. Either upgrade, or consider the following email:
>   *
> - * http://lists.debian.org/debian-arm/2012/08/msg00128.html
> + * https://lists.debian.org/debian-arm/2012/08/msg00128.html
>   */
>  
>  /dts-v1/;
> -- 
> 2.27.0
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH][next] i2c: mv64xxx: Use fallthrough pseudo-keyword

2020-07-17 Thread Gregory CLEMENT
"Gustavo A. R. Silva"  writes:

> Replace the existing /* fall through */ comments and its variants with
> the new pseudo-keyword macro fallthrough[1].
>
> [1] 
> https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
>
> Signed-off-by: Gustavo A. R. Silva 

Reviewed-by: Gregory CLEMENT 

> ---
>  drivers/i2c/busses/i2c-mv64xxx.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c 
> b/drivers/i2c/busses/i2c-mv64xxx.c
> index 829b8c98ae51..8d9d4ffdcd24 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -251,7 +251,7 @@ mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 
> status)
>   MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK;
>   break;
>   }
> - /* FALLTHRU */
> + fallthrough;
>   case MV64XXX_I2C_STATUS_MAST_WR_ADDR_2_ACK: /* 0xd0 */
>   case MV64XXX_I2C_STATUS_MAST_WR_ACK: /* 0x28 */
>   if ((drv_data->bytes_left == 0)
> @@ -282,14 +282,14 @@ mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 
> status)
>   MV64XXX_I2C_STATE_WAITING_FOR_ADDR_2_ACK;
>   break;
>   }
> - /* FALLTHRU */
> + fallthrough;
>   case MV64XXX_I2C_STATUS_MAST_RD_ADDR_2_ACK: /* 0xe0 */
>   if (drv_data->bytes_left == 0) {
>   drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
>   drv_data->state = MV64XXX_I2C_STATE_IDLE;
>   break;
>   }
> - /* FALLTHRU */
> + fallthrough;
>   case MV64XXX_I2C_STATUS_MAST_RD_DATA_ACK: /* 0x50 */
>   if (status != MV64XXX_I2C_STATUS_MAST_RD_DATA_ACK)
>   drv_data->action = MV64XXX_I2C_ACTION_CONTINUE;
> @@ -417,8 +417,7 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
>   "mv64xxx_i2c_do_action: Invalid action: %d\n",
>   drv_data->action);
>   drv_data->rc = -EIO;
> -
> - /* FALLTHRU */
> + fallthrough;
>   case MV64XXX_I2C_ACTION_SEND_STOP:
>   drv_data->cntl_bits &= ~MV64XXX_I2C_REG_CONTROL_INTEN;
>   writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_STOP,
> -- 
> 2.27.0
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


Re: [PATCH v2 0/3] TTY improve n_gsm support

2020-05-18 Thread Gregory CLEMENT
Hello,

> Hello,
>
> This series is the second version of patch improving n_gms support
> especially with TELIT LE910. However the fix should benefit to any
> modem supporting cmux.

You can just ignore the emails from this point, I forgot to remove the
remaining .patch!

Sorry for the noise

Gregory

>
> The first patch is just about improving debugging output.
>
> The second one removes a tty optimization which make the LE910 hang.
>
> The last one fixes an issue observed on the LE910 but should benefit
> to all the modem. We observed that pretty quickly the transfer done
> using the virtual tty were blocked. We found that it was due of a
> wakeup to the real tty. Without this fix, the real tty wait for
> indefinitely.
>
> Thanks to Jiri Slaby for the review.
>
> Changelog:
>  v1 -> v2:
>  - don't replace the pr_info by pr_debug
>  - remove the superfluous printk("\n");
>  - use --follow option with git log to find the original commit to fix
>  - use tty_port_tty_wakeup
>  - use 'for' loop instead of 'while'
>
> Gregory
>
> Gregory CLEMENT (3):
>   tty: n_gsm: Improve debug output
>   tty: n_gsm: Fix SOF skipping
>   tty: n_gsm: Fix waking up upper tty layer when room available
>
>  drivers/tty/n_gsm.c | 48 +++++++--
>  1 file changed, 25 insertions(+), 23 deletions(-)
>
> -- 
> 2.26.2
>

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com


[PATCH v2 2/3] tty: n_gsm: Fix SOF skipping

2020-05-18 Thread Gregory CLEMENT
For at least some modems like the TELIT LE910, skipping SOF makes
transfers blocking indefinitely after a short amount of data
transferred.

Given the small improvement provided by skipping the SOF (just one
byte on about 100 bytes), it seems better to completely remove this
"feature" than make it optional.

Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
Signed-off-by: Gregory CLEMENT 
---
 drivers/tty/n_gsm.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 67c8f8173023..d8d196645500 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -667,7 +667,6 @@ static void gsm_data_kick(struct gsm_mux *gsm)
 {
struct gsm_msg *msg, *nmsg;
int len;
-   int skip_sof = 0;
 
list_for_each_entry_safe(msg, nmsg, >tx_list, list) {
if (gsm->constipated && msg->addr)
@@ -689,15 +688,10 @@ static void gsm_data_kick(struct gsm_mux *gsm)
print_hex_dump_bytes("gsm_data_kick: ",
 DUMP_PREFIX_OFFSET,
 gsm->txframe, len);
-
-   if (gsm->output(gsm, gsm->txframe + skip_sof,
-   len - skip_sof) < 0)
+   if (gsm->output(gsm, gsm->txframe, len) < 0)
break;
/* FIXME: Can eliminate one SOF in many more cases */
gsm->tx_bytes -= msg->len;
-   /* For a burst of frames skip the extra SOF within the
-  burst */
-   skip_sof = 1;
 
list_del(>list);
kfree(msg);
-- 
2.26.2



[PATCH 1/2] tty: n_gsm: Remove unnecessary test in gsm_print_packet()

2020-05-18 Thread Gregory CLEMENT
If the length is zero then the print_hex_dump_bytes won't output
anything, so testing the length before the call is unnecessary.

Signed-off-by: Gregory CLEMENT 
---
 drivers/tty/n_gsm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 69200bd411f7..4465dd04fead 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -504,8 +504,7 @@ static void gsm_print_packet(const char *hdr, int addr, int 
cr,
else
pr_cont("(F)");
 
-   if (dlen)
-   print_hex_dump_bytes("", DUMP_PREFIX_NONE, data, dlen);
+   print_hex_dump_bytes("", DUMP_PREFIX_NONE, data, dlen);
 }
 
 
-- 
2.26.2



[PATCH v2 0/3] TTY improve n_gsm support

2020-05-18 Thread Gregory CLEMENT
Hello,

This series is the second version of patch improving n_gms support
especially with TELIT LE910. However the fix should benefit to any
modem supporting cmux.

The first patch is just about improving debugging output.

The second one removes a tty optimization which make the LE910 hang.

The last one fixes an issue observed on the LE910 but should benefit
to all the modem. We observed that pretty quickly the transfer done
using the virtual tty were blocked. We found that it was due of a
wakeup to the real tty. Without this fix, the real tty wait for
indefinitely.

Thanks to Jiri Slaby for the review.

Changelog:
 v1 -> v2:
 - don't replace the pr_info by pr_debug
 - remove the superfluous printk("\n");
 - use --follow option with git log to find the original commit to fix
 - use tty_port_tty_wakeup
 - use 'for' loop instead of 'while'

Gregory

Gregory CLEMENT (3):
  tty: n_gsm: Improve debug output
  tty: n_gsm: Fix SOF skipping
  tty: n_gsm: Fix waking up upper tty layer when room available

 drivers/tty/n_gsm.c | 48 +++--
 1 file changed, 25 insertions(+), 23 deletions(-)

-- 
2.26.2



[PATCH 0/2] TTY fix-ups for "TTY improve n_gsm support" series

2020-05-18 Thread Gregory CLEMENT
Hello,

Jiri found issues or things to improve in the v2 of the series "TTY
improve n_gsm support". However it was already applied. So this series
implements the needed changes.

For the second patch, as the commit "tty: n_gsm: Fix waking up upper
tty layer when room available" was not yet in mainline, it has no
SHA-1 ID yet. That's why I reference the same commit that the one
fixed by "TTY improve n_gsm support", as they should be applied in the
same order in stable branch than in mainline.

Gregory


Gregory CLEMENT (2):
  tty: n_gsm: Remove unnecessary test in gsm_print_packet()
  tty: n_gsm: Fix bogus i++ in gsm_data_kick

 drivers/tty/n_gsm.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

-- 
2.26.2



[PATCH v2 3/3] tty: n_gsm: Fix waking up upper tty layer when room available

2020-05-18 Thread Gregory CLEMENT
Warn the upper layer when n_gms is ready to receive data
again. Without this the associated virtual tty remains blocked
indefinitely.

Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
Signed-off-by: Gregory CLEMENT 
---
 drivers/tty/n_gsm.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index d8d196645500..69200bd411f7 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -663,7 +663,7 @@ static struct gsm_msg *gsm_data_alloc(struct gsm_mux *gsm, 
u8 addr, int len,
  * FIXME: lock against link layer control transmissions
  */
 
-static void gsm_data_kick(struct gsm_mux *gsm)
+static void gsm_data_kick(struct gsm_mux *gsm, struct gsm_dlci *dlci)
 {
struct gsm_msg *msg, *nmsg;
int len;
@@ -695,6 +695,24 @@ static void gsm_data_kick(struct gsm_mux *gsm)
 
list_del(>list);
kfree(msg);
+
+   if (dlci) {
+   tty_port_tty_wakeup(>port);
+   } else {
+   int i = 0;
+
+   for (i = 0; i < NUM_DLCI; i++) {
+   struct gsm_dlci *dlci;
+
+   dlci = gsm->dlci[i];
+   if (dlci == NULL) {
+   i++;
+   continue;
+   }
+
+   tty_port_tty_wakeup(>port);
+   }
+   }
}
 }
 
@@ -746,7 +764,7 @@ static void __gsm_data_queue(struct gsm_dlci *dlci, struct 
gsm_msg *msg)
/* Add to the actual output queue */
list_add_tail(>list, >tx_list);
gsm->tx_bytes += msg->len;
-   gsm_data_kick(gsm);
+   gsm_data_kick(gsm, dlci);
 }
 
 /**
@@ -1207,7 +1225,7 @@ static void gsm_control_message(struct gsm_mux *gsm, 
unsigned int command,
gsm_control_reply(gsm, CMD_FCON, NULL, 0);
/* Kick the link in case it is idling */
spin_lock_irqsave(>tx_lock, flags);
-   gsm_data_kick(gsm);
+   gsm_data_kick(gsm, NULL);
spin_unlock_irqrestore(>tx_lock, flags);
break;
case CMD_FCOFF:
@@ -2529,7 +2547,7 @@ static void gsmld_write_wakeup(struct tty_struct *tty)
/* Queue poll */
clear_bit(TTY_DO_WRITE_WAKEUP, >flags);
spin_lock_irqsave(>tx_lock, flags);
-   gsm_data_kick(gsm);
+   gsm_data_kick(gsm, NULL);
if (gsm->tx_bytes < TX_THRESH_LO) {
gsm_dlci_data_sweep(gsm);
}
-- 
2.26.2



[PATCH 2/2] tty: n_gsm: Fix bogus i++ in gsm_data_kick

2020-05-18 Thread Gregory CLEMENT
When submitting the previous fix "tty: n_gsm: Fix waking up upper tty
layer when room available". It was suggested to switch from a while to
a for loop, but when doing it, there was a remaining bogus i++.

This patch removes this i++ and also reorganizes the code making it more
compact.

Fixes: e1eaea46bb40 ("tty: n_gsm line discipline")
Signed-off-by: Gregory CLEMENT 
---
 drivers/tty/n_gsm.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index 4465dd04fead..0a29a94ec438 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -700,17 +700,9 @@ static void gsm_data_kick(struct gsm_mux *gsm, struct 
gsm_dlci *dlci)
} else {
int i = 0;
 
-   for (i = 0; i < NUM_DLCI; i++) {
-   struct gsm_dlci *dlci;
-
-   dlci = gsm->dlci[i];
-   if (dlci == NULL) {
-   i++;
-   continue;
-   }
-
-   tty_port_tty_wakeup(>port);
-   }
+   for (i = 0; i < NUM_DLCI; i++)
+   if (gsm->dlci[i])
+   
tty_port_tty_wakeup(>dlci[i]->port);
}
}
 }
-- 
2.26.2



  1   2   3   4   5   6   7   8   9   10   >