* [PATCH 0/4] Remove LPC register partitioning
@ 2020-09-11 3:46 ` Chia-Wei, Wang
0 siblings, 0 replies; 31+ messages in thread
From: Chia-Wei, Wang @ 2020-09-11 3:46 UTC (permalink / raw)
To: robh+dt, joel, andrew, minyard, linus.walleij, haiyue.wang,
cyrilbur, rlippert, linux-arm-kernel, linux-aspeed, linux-kernel,
openbmc
Cc: ryan_chen
The LPC controller has no concept of the BMC and the Host partitions.
The incorrect partitioning can impose unnecessary range restrictions
on register access through the syscon regmap interface.
For instance, HICRB contains the I/O port address configuration
of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access
HICRB as it is located at the other LPC partition.
In addition, to be backward compatible, the newly added HW control
bits could be added at any reserved bits over the LPC addressing space.
Thereby, this patch series aims to remove the LPC partitioning for
better driver development and maintenance.
Chia-Wei, Wang (4):
ARM: dts: Remove LPC BMC and Host partitions
soc: aspeed: Fix LPC register offsets
ipmi: kcs: aspeed: Fix LPC register offsets
pinctrl: aspeed-g5: Fix LPC register offsets
arch/arm/boot/dts/aspeed-g4.dtsi | 74 +++++------
arch/arm/boot/dts/aspeed-g5.dtsi | 135 +++++++++------------
arch/arm/boot/dts/aspeed-g6.dtsi | 135 +++++++++------------
drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +-
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +-
drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +-
drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +-
7 files changed, 162 insertions(+), 214 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 31+ messages in thread
* [PATCH 1/4] ARM: dts: Remove LPC BMC and Host partitions
2020-09-11 3:46 ` Chia-Wei, Wang
@ 2020-09-11 3:46 ` Chia-Wei, Wang
-1 siblings, 0 replies; 31+ messages in thread
From: Chia-Wei, Wang @ 2020-09-11 3:46 UTC (permalink / raw)
To: robh+dt, joel, andrew, minyard, linus.walleij, haiyue.wang,
cyrilbur, rlippert, linux-arm-kernel, linux-aspeed, linux-kernel,
openbmc
Cc: ryan_chen
The LPC controller has no concept of the BMC and the Host partitions.
A concrete instance is that the HICRB[5:4] are for the I/O port address
configurtaion of KCS channel 1/2. However, the KCS driver cannot access
HICRB for channel 1/2 initialization via syscon regmap interface due to
the parition boundary. (i.e. offset 80h)
In addition, to be backward compatible, the newly added HW control bits
could be located at any reserved bits over the LPC addressing space.
Thereby, this patch removes the lpc-bmc and lpc-host child node and thus
the LPC partitioning for better driver development and maintenance.
Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 74 +++++++----------
arch/arm/boot/dts/aspeed-g5.dtsi | 135 ++++++++++++++-----------------
arch/arm/boot/dts/aspeed-g6.dtsi | 135 ++++++++++++++-----------------
3 files changed, 148 insertions(+), 196 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 82f0213e3a3c..22996b3c4a00 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -338,58 +338,44 @@
};
lpc: lpc@1e789000 {
- compatible = "aspeed,ast2400-lpc", "simple-mfd";
+ compatible = "aspeed,ast2400-lpc", "simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
+ reg-io-width = <4>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
- lpc_bmc: lpc-bmc@0 {
- compatible = "aspeed,ast2400-lpc-bmc";
- reg = <0x0 0x80>;
+ lpc_ctrl: lpc-ctrl@80 {
+ compatible = "aspeed,ast2400-lpc-ctrl";
+ reg = <0x80 0x10>;
+ clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
+ status = "disabled";
};
- lpc_host: lpc-host@80 {
- compatible = "aspeed,ast2400-lpc-host", "simple-mfd", "syscon";
- reg = <0x80 0x1e0>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80 0x1e0>;
-
- lpc_ctrl: lpc-ctrl@0 {
- compatible = "aspeed,ast2400-lpc-ctrl";
- reg = <0x0 0x10>;
- clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
- status = "disabled";
- };
-
- lpc_snoop: lpc-snoop@10 {
- compatible = "aspeed,ast2400-lpc-snoop";
- reg = <0x10 0x8>;
- interrupts = <8>;
- status = "disabled";
- };
-
- lhc: lhc@20 {
- compatible = "aspeed,ast2400-lhc";
- reg = <0x20 0x24 0x48 0x8>;
- };
-
- lpc_reset: reset-controller@18 {
- compatible = "aspeed,ast2400-lpc-reset";
- reg = <0x18 0x4>;
- #reset-cells = <1>;
- };
-
- ibt: ibt@c0 {
- compatible = "aspeed,ast2400-ibt-bmc";
- reg = <0xc0 0x18>;
- interrupts = <8>;
- status = "disabled";
- };
+ lpc_snoop: lpc-snoop@90 {
+ compatible = "aspeed,ast2400-lpc-snoop";
+ reg = <0x90 0x8>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ lhc: lhc@a0 {
+ compatible = "aspeed,ast2400-lhc";
+ reg = <0xa0 0x24 0xc8 0x8>;
+ };
+
+ lpc_reset: reset-controller@98 {
+ compatible = "aspeed,ast2400-lpc-reset";
+ reg = <0x98 0x4>;
+ #reset-cells = <1>;
+ };
+
+ ibt: ibt@140 {
+ compatible = "aspeed,ast2400-ibt-bmc";
+ reg = <0x140 0x18>;
+ interrupts = <8>;
+ status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 9c91afb2b404..617efa703207 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -430,90 +430,73 @@
};
lpc: lpc@1e789000 {
- compatible = "aspeed,ast2500-lpc", "simple-mfd";
+ compatible = "aspeed,ast2500-lpc", "simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
+ reg-io-width = <4>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
- lpc_bmc: lpc-bmc@0 {
- compatible = "aspeed,ast2500-lpc-bmc", "simple-mfd", "syscon";
- reg = <0x0 0x80>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x0 0x80>;
-
- kcs1: kcs@24 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>;
- interrupts = <8>;
- status = "disabled";
- };
- kcs2: kcs@28 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x28 0x1>, <0x34 0x1>, <0x40 0x1>;
- interrupts = <8>;
- status = "disabled";
- };
- kcs3: kcs@2c {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x2c 0x1>, <0x38 0x1>, <0x44 0x1>;
- interrupts = <8>;
- status = "disabled";
- };
+ kcs1: kcs@24 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ kcs2: kcs@28 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x28 0x1>, <0x34 0x1>, <0x40 0x1>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ kcs3: kcs@2c {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x2c 0x1>, <0x38 0x1>, <0x44 0x1>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ kcs4: kcs@114 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x114 0x1>, <0x118 0x1>, <0x11c 0x1>;
+ interrupts = <8>;
+ status = "disabled";
};
- lpc_host: lpc-host@80 {
- compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon";
- reg = <0x80 0x1e0>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80 0x1e0>;
-
- kcs4: kcs@94 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x94 0x1>, <0x98 0x1>, <0x9c 0x1>;
- interrupts = <8>;
- status = "disabled";
- };
-
- lpc_ctrl: lpc-ctrl@0 {
- compatible = "aspeed,ast2500-lpc-ctrl";
- reg = <0x0 0x10>;
- clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
- status = "disabled";
- };
-
- lpc_snoop: lpc-snoop@10 {
- compatible = "aspeed,ast2500-lpc-snoop";
- reg = <0x10 0x8>;
- interrupts = <8>;
- status = "disabled";
- };
-
- lpc_reset: reset-controller@18 {
- compatible = "aspeed,ast2500-lpc-reset";
- reg = <0x18 0x4>;
- #reset-cells = <1>;
- };
-
- lhc: lhc@20 {
- compatible = "aspeed,ast2500-lhc";
- reg = <0x20 0x24 0x48 0x8>;
- };
-
-
- ibt: ibt@c0 {
- compatible = "aspeed,ast2500-ibt-bmc";
- reg = <0xc0 0x18>;
- interrupts = <8>;
- status = "disabled";
- };
+ lpc_ctrl: lpc-ctrl@80 {
+ compatible = "aspeed,ast2500-lpc-ctrl";
+ reg = <0x80 0x10>;
+ clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
+ status = "disabled";
+ };
+
+ lpc_snoop: lpc-snoop@90 {
+ compatible = "aspeed,ast2500-lpc-snoop";
+ reg = <0x90 0x8>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ lpc_reset: reset-controller@98 {
+ compatible = "aspeed,ast2500-lpc-reset";
+ reg = <0x98 0x4>;
+ #reset-cells = <1>;
+ };
+
+ lhc: lhc@a0 {
+ compatible = "aspeed,ast2500-lhc";
+ reg = <0xa0 0x24 0xc8 0x8>;
+ };
+
+
+ ibt: ibt@140 {
+ compatible = "aspeed,ast2500-ibt-bmc";
+ reg = <0x140 0x18>;
+ interrupts = <8>;
+ status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index b58220a49cbd..8dfb5847fc34 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -449,90 +449,73 @@
};
lpc: lpc@1e789000 {
- compatible = "aspeed,ast2600-lpc", "simple-mfd";
+ compatible = "aspeed,ast2600-lpc", "simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
+ reg-io-width = <4>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
- lpc_bmc: lpc-bmc@0 {
- compatible = "aspeed,ast2600-lpc-bmc", "simple-mfd", "syscon";
- reg = <0x0 0x80>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x0 0x80>;
-
- kcs1: kcs@24 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>;
- interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
- kcs_chan = <1>;
- status = "disabled";
- };
- kcs2: kcs@28 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x28 0x1>, <0x34 0x1>, <0x40 0x1>;
- interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
- kcs3: kcs@2c {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x2c 0x1>, <0x38 0x1>, <0x44 0x1>;
- interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
+ kcs1: kcs@24 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>;
+ interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
+ kcs_chan = <1>;
+ status = "disabled";
+ };
+
+ kcs2: kcs@28 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x28 0x1>, <0x34 0x1>, <0x40 0x1>;
+ interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ kcs3: kcs@2c {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x2c 0x1>, <0x38 0x1>, <0x44 0x1>;
+ interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ kcs4: kcs@114 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x114 0x1>, <0x118 0x1>, <0x11c 0x1>;
+ interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ lpc_ctrl: lpc-ctrl@80 {
+ compatible = "aspeed,ast2600-lpc-ctrl";
+ reg = <0x80 0x80>;
+ clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
+ status = "disabled";
+ };
+
+ lpc_snoop: lpc-snoop@80 {
+ compatible = "aspeed,ast2600-lpc-snoop";
+ reg = <0x80 0x80>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
};
- lpc_host: lpc-host@80 {
- compatible = "aspeed,ast2600-lpc-host", "simple-mfd", "syscon";
- reg = <0x80 0x1e0>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80 0x1e0>;
-
- kcs4: kcs@94 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x94 0x1>, <0x98 0x1>, <0x9c 0x1>;
- interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
-
- lpc_ctrl: lpc-ctrl@0 {
- compatible = "aspeed,ast2600-lpc-ctrl";
- reg = <0x0 0x80>;
- clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
- status = "disabled";
- };
-
- lpc_snoop: lpc-snoop@0 {
- compatible = "aspeed,ast2600-lpc-snoop";
- reg = <0x0 0x80>;
- interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
-
- lhc: lhc@20 {
- compatible = "aspeed,ast2600-lhc";
- reg = <0x20 0x24 0x48 0x8>;
- };
-
- lpc_reset: reset-controller@18 {
- compatible = "aspeed,ast2600-lpc-reset";
- reg = <0x18 0x4>;
- #reset-cells = <1>;
- };
-
- ibt: ibt@c0 {
- compatible = "aspeed,ast2600-ibt-bmc";
- reg = <0xc0 0x18>;
- interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
+ lhc: lhc@a0 {
+ compatible = "aspeed,ast2600-lhc";
+ reg = <0xa0 0x24 0xc8 0x8>;
+ };
+
+ lpc_reset: reset-controller@98 {
+ compatible = "aspeed,ast2600-lpc-reset";
+ reg = <0x98 0x4>;
+ #reset-cells = <1>;
+ };
+
+ ibt: ibt@140 {
+ compatible = "aspeed,ast2600-ibt-bmc";
+ reg = <0x140 0x18>;
+ interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
};
};
--
2.17.1
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 1/4] ARM: dts: Remove LPC BMC and Host partitions
@ 2020-09-11 3:46 ` Chia-Wei, Wang
0 siblings, 0 replies; 31+ messages in thread
From: Chia-Wei, Wang @ 2020-09-11 3:46 UTC (permalink / raw)
To: robh+dt, joel, andrew, minyard, linus.walleij, haiyue.wang,
cyrilbur, rlippert, linux-arm-kernel, linux-aspeed, linux-kernel,
openbmc
Cc: ryan_chen
The LPC controller has no concept of the BMC and the Host partitions.
A concrete instance is that the HICRB[5:4] are for the I/O port address
configurtaion of KCS channel 1/2. However, the KCS driver cannot access
HICRB for channel 1/2 initialization via syscon regmap interface due to
the parition boundary. (i.e. offset 80h)
In addition, to be backward compatible, the newly added HW control bits
could be located at any reserved bits over the LPC addressing space.
Thereby, this patch removes the lpc-bmc and lpc-host child node and thus
the LPC partitioning for better driver development and maintenance.
Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 74 +++++++----------
arch/arm/boot/dts/aspeed-g5.dtsi | 135 ++++++++++++++-----------------
arch/arm/boot/dts/aspeed-g6.dtsi | 135 ++++++++++++++-----------------
3 files changed, 148 insertions(+), 196 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 82f0213e3a3c..22996b3c4a00 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -338,58 +338,44 @@
};
lpc: lpc@1e789000 {
- compatible = "aspeed,ast2400-lpc", "simple-mfd";
+ compatible = "aspeed,ast2400-lpc", "simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
+ reg-io-width = <4>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
- lpc_bmc: lpc-bmc@0 {
- compatible = "aspeed,ast2400-lpc-bmc";
- reg = <0x0 0x80>;
+ lpc_ctrl: lpc-ctrl@80 {
+ compatible = "aspeed,ast2400-lpc-ctrl";
+ reg = <0x80 0x10>;
+ clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
+ status = "disabled";
};
- lpc_host: lpc-host@80 {
- compatible = "aspeed,ast2400-lpc-host", "simple-mfd", "syscon";
- reg = <0x80 0x1e0>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80 0x1e0>;
-
- lpc_ctrl: lpc-ctrl@0 {
- compatible = "aspeed,ast2400-lpc-ctrl";
- reg = <0x0 0x10>;
- clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
- status = "disabled";
- };
-
- lpc_snoop: lpc-snoop@10 {
- compatible = "aspeed,ast2400-lpc-snoop";
- reg = <0x10 0x8>;
- interrupts = <8>;
- status = "disabled";
- };
-
- lhc: lhc@20 {
- compatible = "aspeed,ast2400-lhc";
- reg = <0x20 0x24 0x48 0x8>;
- };
-
- lpc_reset: reset-controller@18 {
- compatible = "aspeed,ast2400-lpc-reset";
- reg = <0x18 0x4>;
- #reset-cells = <1>;
- };
-
- ibt: ibt@c0 {
- compatible = "aspeed,ast2400-ibt-bmc";
- reg = <0xc0 0x18>;
- interrupts = <8>;
- status = "disabled";
- };
+ lpc_snoop: lpc-snoop@90 {
+ compatible = "aspeed,ast2400-lpc-snoop";
+ reg = <0x90 0x8>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ lhc: lhc@a0 {
+ compatible = "aspeed,ast2400-lhc";
+ reg = <0xa0 0x24 0xc8 0x8>;
+ };
+
+ lpc_reset: reset-controller@98 {
+ compatible = "aspeed,ast2400-lpc-reset";
+ reg = <0x98 0x4>;
+ #reset-cells = <1>;
+ };
+
+ ibt: ibt@140 {
+ compatible = "aspeed,ast2400-ibt-bmc";
+ reg = <0x140 0x18>;
+ interrupts = <8>;
+ status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 9c91afb2b404..617efa703207 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -430,90 +430,73 @@
};
lpc: lpc@1e789000 {
- compatible = "aspeed,ast2500-lpc", "simple-mfd";
+ compatible = "aspeed,ast2500-lpc", "simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
+ reg-io-width = <4>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
- lpc_bmc: lpc-bmc@0 {
- compatible = "aspeed,ast2500-lpc-bmc", "simple-mfd", "syscon";
- reg = <0x0 0x80>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x0 0x80>;
-
- kcs1: kcs@24 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>;
- interrupts = <8>;
- status = "disabled";
- };
- kcs2: kcs@28 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x28 0x1>, <0x34 0x1>, <0x40 0x1>;
- interrupts = <8>;
- status = "disabled";
- };
- kcs3: kcs@2c {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x2c 0x1>, <0x38 0x1>, <0x44 0x1>;
- interrupts = <8>;
- status = "disabled";
- };
+ kcs1: kcs@24 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ kcs2: kcs@28 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x28 0x1>, <0x34 0x1>, <0x40 0x1>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ kcs3: kcs@2c {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x2c 0x1>, <0x38 0x1>, <0x44 0x1>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ kcs4: kcs@114 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x114 0x1>, <0x118 0x1>, <0x11c 0x1>;
+ interrupts = <8>;
+ status = "disabled";
};
- lpc_host: lpc-host@80 {
- compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon";
- reg = <0x80 0x1e0>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80 0x1e0>;
-
- kcs4: kcs@94 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x94 0x1>, <0x98 0x1>, <0x9c 0x1>;
- interrupts = <8>;
- status = "disabled";
- };
-
- lpc_ctrl: lpc-ctrl@0 {
- compatible = "aspeed,ast2500-lpc-ctrl";
- reg = <0x0 0x10>;
- clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
- status = "disabled";
- };
-
- lpc_snoop: lpc-snoop@10 {
- compatible = "aspeed,ast2500-lpc-snoop";
- reg = <0x10 0x8>;
- interrupts = <8>;
- status = "disabled";
- };
-
- lpc_reset: reset-controller@18 {
- compatible = "aspeed,ast2500-lpc-reset";
- reg = <0x18 0x4>;
- #reset-cells = <1>;
- };
-
- lhc: lhc@20 {
- compatible = "aspeed,ast2500-lhc";
- reg = <0x20 0x24 0x48 0x8>;
- };
-
-
- ibt: ibt@c0 {
- compatible = "aspeed,ast2500-ibt-bmc";
- reg = <0xc0 0x18>;
- interrupts = <8>;
- status = "disabled";
- };
+ lpc_ctrl: lpc-ctrl@80 {
+ compatible = "aspeed,ast2500-lpc-ctrl";
+ reg = <0x80 0x10>;
+ clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
+ status = "disabled";
+ };
+
+ lpc_snoop: lpc-snoop@90 {
+ compatible = "aspeed,ast2500-lpc-snoop";
+ reg = <0x90 0x8>;
+ interrupts = <8>;
+ status = "disabled";
+ };
+
+ lpc_reset: reset-controller@98 {
+ compatible = "aspeed,ast2500-lpc-reset";
+ reg = <0x98 0x4>;
+ #reset-cells = <1>;
+ };
+
+ lhc: lhc@a0 {
+ compatible = "aspeed,ast2500-lhc";
+ reg = <0xa0 0x24 0xc8 0x8>;
+ };
+
+
+ ibt: ibt@140 {
+ compatible = "aspeed,ast2500-ibt-bmc";
+ reg = <0x140 0x18>;
+ interrupts = <8>;
+ status = "disabled";
};
};
diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index b58220a49cbd..8dfb5847fc34 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -449,90 +449,73 @@
};
lpc: lpc@1e789000 {
- compatible = "aspeed,ast2600-lpc", "simple-mfd";
+ compatible = "aspeed,ast2600-lpc", "simple-mfd", "syscon";
reg = <0x1e789000 0x1000>;
+ reg-io-width = <4>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x1e789000 0x1000>;
- lpc_bmc: lpc-bmc@0 {
- compatible = "aspeed,ast2600-lpc-bmc", "simple-mfd", "syscon";
- reg = <0x0 0x80>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x0 0x80>;
-
- kcs1: kcs@24 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>;
- interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
- kcs_chan = <1>;
- status = "disabled";
- };
- kcs2: kcs@28 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x28 0x1>, <0x34 0x1>, <0x40 0x1>;
- interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
- kcs3: kcs@2c {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x2c 0x1>, <0x38 0x1>, <0x44 0x1>;
- interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
+ kcs1: kcs@24 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>;
+ interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
+ kcs_chan = <1>;
+ status = "disabled";
+ };
+
+ kcs2: kcs@28 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x28 0x1>, <0x34 0x1>, <0x40 0x1>;
+ interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ kcs3: kcs@2c {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x2c 0x1>, <0x38 0x1>, <0x44 0x1>;
+ interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ kcs4: kcs@114 {
+ compatible = "aspeed,ast2500-kcs-bmc-v2";
+ reg = <0x114 0x1>, <0x118 0x1>, <0x11c 0x1>;
+ interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ lpc_ctrl: lpc-ctrl@80 {
+ compatible = "aspeed,ast2600-lpc-ctrl";
+ reg = <0x80 0x80>;
+ clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
+ status = "disabled";
+ };
+
+ lpc_snoop: lpc-snoop@80 {
+ compatible = "aspeed,ast2600-lpc-snoop";
+ reg = <0x80 0x80>;
+ interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
};
- lpc_host: lpc-host@80 {
- compatible = "aspeed,ast2600-lpc-host", "simple-mfd", "syscon";
- reg = <0x80 0x1e0>;
- reg-io-width = <4>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0x0 0x80 0x1e0>;
-
- kcs4: kcs@94 {
- compatible = "aspeed,ast2500-kcs-bmc-v2";
- reg = <0x94 0x1>, <0x98 0x1>, <0x9c 0x1>;
- interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
-
- lpc_ctrl: lpc-ctrl@0 {
- compatible = "aspeed,ast2600-lpc-ctrl";
- reg = <0x0 0x80>;
- clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
- status = "disabled";
- };
-
- lpc_snoop: lpc-snoop@0 {
- compatible = "aspeed,ast2600-lpc-snoop";
- reg = <0x0 0x80>;
- interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
-
- lhc: lhc@20 {
- compatible = "aspeed,ast2600-lhc";
- reg = <0x20 0x24 0x48 0x8>;
- };
-
- lpc_reset: reset-controller@18 {
- compatible = "aspeed,ast2600-lpc-reset";
- reg = <0x18 0x4>;
- #reset-cells = <1>;
- };
-
- ibt: ibt@c0 {
- compatible = "aspeed,ast2600-ibt-bmc";
- reg = <0xc0 0x18>;
- interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
- status = "disabled";
- };
+ lhc: lhc@a0 {
+ compatible = "aspeed,ast2600-lhc";
+ reg = <0xa0 0x24 0xc8 0x8>;
+ };
+
+ lpc_reset: reset-controller@98 {
+ compatible = "aspeed,ast2600-lpc-reset";
+ reg = <0x98 0x4>;
+ #reset-cells = <1>;
+ };
+
+ ibt: ibt@140 {
+ compatible = "aspeed,ast2600-ibt-bmc";
+ reg = <0x140 0x18>;
+ interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
};
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [PATCH 2/4] soc: aspeed: Fix LPC register offsets
2020-09-11 3:46 ` Chia-Wei, Wang
@ 2020-09-11 3:46 ` Chia-Wei, Wang
-1 siblings, 0 replies; 31+ messages in thread
From: Chia-Wei, Wang @ 2020-09-11 3:46 UTC (permalink / raw)
To: robh+dt, joel, andrew, minyard, linus.walleij, haiyue.wang,
cyrilbur, rlippert, linux-arm-kernel, linux-aspeed, linux-kernel,
openbmc
Cc: ryan_chen
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
---
drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +++---
drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +++++------
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/soc/aspeed/aspeed-lpc-ctrl.c b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
index 01ed21e8bfee..36faa0618ada 100644
--- a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
+++ b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
@@ -17,12 +17,12 @@
#define DEVICE_NAME "aspeed-lpc-ctrl"
-#define HICR5 0x0
+#define HICR5 0x80
#define HICR5_ENL2H BIT(8)
#define HICR5_ENFWH BIT(10)
-#define HICR7 0x8
-#define HICR8 0xc
+#define HICR7 0x88
+#define HICR8 0x8c
struct aspeed_lpc_ctrl {
struct miscdevice miscdev;
diff --git a/drivers/soc/aspeed/aspeed-lpc-snoop.c b/drivers/soc/aspeed/aspeed-lpc-snoop.c
index f3d8d53ab84d..7ce5c9fcc73c 100644
--- a/drivers/soc/aspeed/aspeed-lpc-snoop.c
+++ b/drivers/soc/aspeed/aspeed-lpc-snoop.c
@@ -28,26 +28,25 @@
#define NUM_SNOOP_CHANNELS 2
#define SNOOP_FIFO_SIZE 2048
-#define HICR5 0x0
+#define HICR5 0x80
#define HICR5_EN_SNP0W BIT(0)
#define HICR5_ENINT_SNP0W BIT(1)
#define HICR5_EN_SNP1W BIT(2)
#define HICR5_ENINT_SNP1W BIT(3)
-
-#define HICR6 0x4
+#define HICR6 0x84
#define HICR6_STR_SNP0W BIT(0)
#define HICR6_STR_SNP1W BIT(1)
-#define SNPWADR 0x10
+#define SNPWADR 0x90
#define SNPWADR_CH0_MASK GENMASK(15, 0)
#define SNPWADR_CH0_SHIFT 0
#define SNPWADR_CH1_MASK GENMASK(31, 16)
#define SNPWADR_CH1_SHIFT 16
-#define SNPWDR 0x14
+#define SNPWDR 0x94
#define SNPWDR_CH0_MASK GENMASK(7, 0)
#define SNPWDR_CH0_SHIFT 0
#define SNPWDR_CH1_MASK GENMASK(15, 8)
#define SNPWDR_CH1_SHIFT 8
-#define HICRB 0x80
+#define HICRB 0x100
#define HICRB_ENSNP0D BIT(14)
#define HICRB_ENSNP1D BIT(15)
--
2.17.1
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 2/4] soc: aspeed: Fix LPC register offsets
@ 2020-09-11 3:46 ` Chia-Wei, Wang
0 siblings, 0 replies; 31+ messages in thread
From: Chia-Wei, Wang @ 2020-09-11 3:46 UTC (permalink / raw)
To: robh+dt, joel, andrew, minyard, linus.walleij, haiyue.wang,
cyrilbur, rlippert, linux-arm-kernel, linux-aspeed, linux-kernel,
openbmc
Cc: ryan_chen
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
---
drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +++---
drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +++++------
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/soc/aspeed/aspeed-lpc-ctrl.c b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
index 01ed21e8bfee..36faa0618ada 100644
--- a/drivers/soc/aspeed/aspeed-lpc-ctrl.c
+++ b/drivers/soc/aspeed/aspeed-lpc-ctrl.c
@@ -17,12 +17,12 @@
#define DEVICE_NAME "aspeed-lpc-ctrl"
-#define HICR5 0x0
+#define HICR5 0x80
#define HICR5_ENL2H BIT(8)
#define HICR5_ENFWH BIT(10)
-#define HICR7 0x8
-#define HICR8 0xc
+#define HICR7 0x88
+#define HICR8 0x8c
struct aspeed_lpc_ctrl {
struct miscdevice miscdev;
diff --git a/drivers/soc/aspeed/aspeed-lpc-snoop.c b/drivers/soc/aspeed/aspeed-lpc-snoop.c
index f3d8d53ab84d..7ce5c9fcc73c 100644
--- a/drivers/soc/aspeed/aspeed-lpc-snoop.c
+++ b/drivers/soc/aspeed/aspeed-lpc-snoop.c
@@ -28,26 +28,25 @@
#define NUM_SNOOP_CHANNELS 2
#define SNOOP_FIFO_SIZE 2048
-#define HICR5 0x0
+#define HICR5 0x80
#define HICR5_EN_SNP0W BIT(0)
#define HICR5_ENINT_SNP0W BIT(1)
#define HICR5_EN_SNP1W BIT(2)
#define HICR5_ENINT_SNP1W BIT(3)
-
-#define HICR6 0x4
+#define HICR6 0x84
#define HICR6_STR_SNP0W BIT(0)
#define HICR6_STR_SNP1W BIT(1)
-#define SNPWADR 0x10
+#define SNPWADR 0x90
#define SNPWADR_CH0_MASK GENMASK(15, 0)
#define SNPWADR_CH0_SHIFT 0
#define SNPWADR_CH1_MASK GENMASK(31, 16)
#define SNPWADR_CH1_SHIFT 16
-#define SNPWDR 0x14
+#define SNPWDR 0x94
#define SNPWDR_CH0_MASK GENMASK(7, 0)
#define SNPWDR_CH0_SHIFT 0
#define SNPWDR_CH1_MASK GENMASK(15, 8)
#define SNPWDR_CH1_SHIFT 8
-#define HICRB 0x80
+#define HICRB 0x100
#define HICRB_ENSNP0D BIT(14)
#define HICRB_ENSNP1D BIT(15)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [PATCH 3/4] ipmi: kcs: aspeed: Fix LPC register offsets
2020-09-11 3:46 ` Chia-Wei, Wang
@ 2020-09-11 3:46 ` Chia-Wei, Wang
-1 siblings, 0 replies; 31+ messages in thread
From: Chia-Wei, Wang @ 2020-09-11 3:46 UTC (permalink / raw)
To: robh+dt, joel, andrew, minyard, linus.walleij, haiyue.wang,
cyrilbur, rlippert, linux-arm-kernel, linux-aspeed, linux-kernel,
openbmc
Cc: ryan_chen
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
---
drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
index a140203c079b..8843cf867a5d 100644
--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
@@ -27,7 +27,6 @@
#define KCS_CHANNEL_MAX 4
-/* mapped to lpc-bmc@0 IO space */
#define LPC_HICR0 0x000
#define LPC_HICR0_LPC3E BIT(7)
#define LPC_HICR0_LPC2E BIT(6)
@@ -52,15 +51,13 @@
#define LPC_STR1 0x03C
#define LPC_STR2 0x040
#define LPC_STR3 0x044
-
-/* mapped to lpc-host@80 IO space */
-#define LPC_HICRB 0x080
+#define LPC_HICRB 0x100
#define LPC_HICRB_IBFIF4 BIT(1)
#define LPC_HICRB_LPC4E BIT(0)
-#define LPC_LADR4 0x090
-#define LPC_IDR4 0x094
-#define LPC_ODR4 0x098
-#define LPC_STR4 0x09C
+#define LPC_LADR4 0x110
+#define LPC_IDR4 0x114
+#define LPC_ODR4 0x118
+#define LPC_STR4 0x11C
struct aspeed_kcs_bmc {
struct regmap *map;
--
2.17.1
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 3/4] ipmi: kcs: aspeed: Fix LPC register offsets
@ 2020-09-11 3:46 ` Chia-Wei, Wang
0 siblings, 0 replies; 31+ messages in thread
From: Chia-Wei, Wang @ 2020-09-11 3:46 UTC (permalink / raw)
To: robh+dt, joel, andrew, minyard, linus.walleij, haiyue.wang,
cyrilbur, rlippert, linux-arm-kernel, linux-aspeed, linux-kernel,
openbmc
Cc: ryan_chen
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
---
drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/char/ipmi/kcs_bmc_aspeed.c b/drivers/char/ipmi/kcs_bmc_aspeed.c
index a140203c079b..8843cf867a5d 100644
--- a/drivers/char/ipmi/kcs_bmc_aspeed.c
+++ b/drivers/char/ipmi/kcs_bmc_aspeed.c
@@ -27,7 +27,6 @@
#define KCS_CHANNEL_MAX 4
-/* mapped to lpc-bmc@0 IO space */
#define LPC_HICR0 0x000
#define LPC_HICR0_LPC3E BIT(7)
#define LPC_HICR0_LPC2E BIT(6)
@@ -52,15 +51,13 @@
#define LPC_STR1 0x03C
#define LPC_STR2 0x040
#define LPC_STR3 0x044
-
-/* mapped to lpc-host@80 IO space */
-#define LPC_HICRB 0x080
+#define LPC_HICRB 0x100
#define LPC_HICRB_IBFIF4 BIT(1)
#define LPC_HICRB_LPC4E BIT(0)
-#define LPC_LADR4 0x090
-#define LPC_IDR4 0x094
-#define LPC_ODR4 0x098
-#define LPC_STR4 0x09C
+#define LPC_LADR4 0x110
+#define LPC_IDR4 0x114
+#define LPC_ODR4 0x118
+#define LPC_STR4 0x11C
struct aspeed_kcs_bmc {
struct regmap *map;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 31+ messages in thread
* [PATCH 4/4] pinctrl: aspeed-g5: Fix LPC register offsets
2020-09-11 3:46 ` Chia-Wei, Wang
@ 2020-09-11 3:46 ` Chia-Wei, Wang
-1 siblings, 0 replies; 31+ messages in thread
From: Chia-Wei, Wang @ 2020-09-11 3:46 UTC (permalink / raw)
To: robh+dt, joel, andrew, minyard, linus.walleij, haiyue.wang,
cyrilbur, rlippert, linux-arm-kernel, linux-aspeed, linux-kernel,
openbmc
Cc: ryan_chen
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 0cab4c2576e2..98e62333fa54 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -60,7 +60,7 @@
#define COND2 { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
/* LHCR0 is offset from the end of the H8S/2168-compatible registers */
-#define LHCR0 0x20
+#define LHCR0 0xa0
#define GFX064 0x64
#define B14 0
--
2.17.1
^ permalink raw reply related [flat|nested] 31+ messages in thread* [PATCH 4/4] pinctrl: aspeed-g5: Fix LPC register offsets
@ 2020-09-11 3:46 ` Chia-Wei, Wang
0 siblings, 0 replies; 31+ messages in thread
From: Chia-Wei, Wang @ 2020-09-11 3:46 UTC (permalink / raw)
To: robh+dt, joel, andrew, minyard, linus.walleij, haiyue.wang,
cyrilbur, rlippert, linux-arm-kernel, linux-aspeed, linux-kernel,
openbmc
Cc: ryan_chen
The LPC register offsets are fixed to adapt to the LPC DTS change,
where the LPC partitioning is removed.
Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
index 0cab4c2576e2..98e62333fa54 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
@@ -60,7 +60,7 @@
#define COND2 { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
/* LHCR0 is offset from the end of the H8S/2168-compatible registers */
-#define LHCR0 0x20
+#define LHCR0 0xa0
#define GFX064 0x64
#define B14 0
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 31+ messages in thread* Re: [PATCH 4/4] pinctrl: aspeed-g5: Fix LPC register offsets
2020-09-11 3:46 ` Chia-Wei, Wang
(?)
@ 2020-09-29 12:42 ` Linus Walleij
-1 siblings, 0 replies; 31+ messages in thread
From: Linus Walleij @ 2020-09-29 12:42 UTC (permalink / raw)
To: Chia-Wei, Wang, Andrew Jeffery
Cc: Rob Herring, Joel Stanley, Corey Minyard, haiyue.wang, cyrilbur,
rlippert, Linux ARM, linux-aspeed, linux-kernel,
OpenBMC Maillist, Ryan Chen
On Fri, Sep 11, 2020 at 5:47 AM Chia-Wei, Wang
<chiawei_wang@aspeedtech.com> wrote:
> The LPC register offsets are fixed to adapt to the LPC DTS change,
> where the LPC partitioning is removed.
>
> Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
I can apply this one patch if I get a review from one of the
Aspeed pinctrl maintainer.
Andrew?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 4/4] pinctrl: aspeed-g5: Fix LPC register offsets
@ 2020-09-29 12:42 ` Linus Walleij
0 siblings, 0 replies; 31+ messages in thread
From: Linus Walleij @ 2020-09-29 12:42 UTC (permalink / raw)
To: Chia-Wei, Wang, Andrew Jeffery
Cc: Linux ARM, rlippert, Ryan Chen, linux-aspeed, Corey Minyard,
OpenBMC Maillist, linux-kernel, Rob Herring, Joel Stanley,
cyrilbur, haiyue.wang
On Fri, Sep 11, 2020 at 5:47 AM Chia-Wei, Wang
<chiawei_wang@aspeedtech.com> wrote:
> The LPC register offsets are fixed to adapt to the LPC DTS change,
> where the LPC partitioning is removed.
>
> Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
I can apply this one patch if I get a review from one of the
Aspeed pinctrl maintainer.
Andrew?
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 4/4] pinctrl: aspeed-g5: Fix LPC register offsets
@ 2020-09-29 12:42 ` Linus Walleij
0 siblings, 0 replies; 31+ messages in thread
From: Linus Walleij @ 2020-09-29 12:42 UTC (permalink / raw)
To: Chia-Wei, Wang, Andrew Jeffery
Cc: Linux ARM, Ryan Chen, linux-aspeed, Corey Minyard,
OpenBMC Maillist, linux-kernel, Rob Herring, cyrilbur,
haiyue.wang
On Fri, Sep 11, 2020 at 5:47 AM Chia-Wei, Wang
<chiawei_wang@aspeedtech.com> wrote:
> The LPC register offsets are fixed to adapt to the LPC DTS change,
> where the LPC partitioning is removed.
>
> Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
I can apply this one patch if I get a review from one of the
Aspeed pinctrl maintainer.
Andrew?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 4/4] pinctrl: aspeed-g5: Fix LPC register offsets
2020-09-29 12:42 ` Linus Walleij
(?)
@ 2020-10-01 0:42 ` Andrew Jeffery
-1 siblings, 0 replies; 31+ messages in thread
From: Andrew Jeffery @ 2020-10-01 0:42 UTC (permalink / raw)
To: Linus Walleij, Chia-Wei, Wang
Cc: Rob Herring, Joel Stanley, Corey Minyard, Haiyue Wang, Cyril Bur,
Robert Lippert, Linux ARM, linux-aspeed, linux-kernel,
OpenBMC Maillist, Ryan Chen
On Tue, 29 Sep 2020, at 22:12, Linus Walleij wrote:
> On Fri, Sep 11, 2020 at 5:47 AM Chia-Wei, Wang
> <chiawei_wang@aspeedtech.com> wrote:
>
> > The LPC register offsets are fixed to adapt to the LPC DTS change,
> > where the LPC partitioning is removed.
> >
> > Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
>
> I can apply this one patch if I get a review from one of the
> Aspeed pinctrl maintainer.
>
> Andrew?
There needs to be a v2 of the series that fixes the binding documentation,
which will drive some discussion about backwards compatibility. So lets not
apply this patch just yet.
Thanks for touching base!
Andrew
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 4/4] pinctrl: aspeed-g5: Fix LPC register offsets
@ 2020-10-01 0:42 ` Andrew Jeffery
0 siblings, 0 replies; 31+ messages in thread
From: Andrew Jeffery @ 2020-10-01 0:42 UTC (permalink / raw)
To: Linus Walleij, Chia-Wei, Wang
Cc: Linux ARM, Robert Lippert, Ryan Chen, linux-aspeed,
Corey Minyard, OpenBMC Maillist, linux-kernel, Rob Herring,
Joel Stanley, Cyril Bur, Haiyue Wang
On Tue, 29 Sep 2020, at 22:12, Linus Walleij wrote:
> On Fri, Sep 11, 2020 at 5:47 AM Chia-Wei, Wang
> <chiawei_wang@aspeedtech.com> wrote:
>
> > The LPC register offsets are fixed to adapt to the LPC DTS change,
> > where the LPC partitioning is removed.
> >
> > Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
>
> I can apply this one patch if I get a review from one of the
> Aspeed pinctrl maintainer.
>
> Andrew?
There needs to be a v2 of the series that fixes the binding documentation,
which will drive some discussion about backwards compatibility. So lets not
apply this patch just yet.
Thanks for touching base!
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 4/4] pinctrl: aspeed-g5: Fix LPC register offsets
@ 2020-10-01 0:42 ` Andrew Jeffery
0 siblings, 0 replies; 31+ messages in thread
From: Andrew Jeffery @ 2020-10-01 0:42 UTC (permalink / raw)
To: Linus Walleij, Chia-Wei, Wang
Cc: Linux ARM, Ryan Chen, linux-aspeed, Corey Minyard,
OpenBMC Maillist, linux-kernel, Rob Herring, Cyril Bur,
Haiyue Wang
On Tue, 29 Sep 2020, at 22:12, Linus Walleij wrote:
> On Fri, Sep 11, 2020 at 5:47 AM Chia-Wei, Wang
> <chiawei_wang@aspeedtech.com> wrote:
>
> > The LPC register offsets are fixed to adapt to the LPC DTS change,
> > where the LPC partitioning is removed.
> >
> > Signed-off-by: Chia-Wei, Wang <chiawei_wang@aspeedtech.com>
>
> I can apply this one patch if I get a review from one of the
> Aspeed pinctrl maintainer.
>
> Andrew?
There needs to be a v2 of the series that fixes the binding documentation,
which will drive some discussion about backwards compatibility. So lets not
apply this patch just yet.
Thanks for touching base!
Andrew
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/4] Remove LPC register partitioning
2020-09-11 3:46 ` Chia-Wei, Wang
(?)
@ 2020-09-11 4:03 ` Joel Stanley
-1 siblings, 0 replies; 31+ messages in thread
From: Joel Stanley @ 2020-09-11 4:03 UTC (permalink / raw)
To: Chia-Wei, Wang, Andrew Jeffery
Cc: Rob Herring, Corey Minyard, Linus Walleij, Haiyue Wang,
Cyril Bur, Robert Lippert, Linux ARM, linux-aspeed,
Linux Kernel Mailing List, OpenBMC Maillist, Ryan Chen
Hello,
On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang
<chiawei_wang@aspeedtech.com> wrote:
>
> The LPC controller has no concept of the BMC and the Host partitions.
> The incorrect partitioning can impose unnecessary range restrictions
> on register access through the syscon regmap interface.
>
> For instance, HICRB contains the I/O port address configuration
> of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access
> HICRB as it is located at the other LPC partition.
>
> In addition, to be backward compatible, the newly added HW control
> bits could be added at any reserved bits over the LPC addressing space.
>
> Thereby, this patch series aims to remove the LPC partitioning for
> better driver development and maintenance.
I support this cleanup. The only consideration is to be careful with
breaking the driver/device-tree relationship. We either need to ensure
the drivers remain compatible with both device trees.
Another solution is to get agreement from all parties that for the LPC
device the device tree is always the one shipped with the kernel, so
it is okay to make incompatible changes.
While we are doing a cleanup, Andrew suggested we remove the detailed
description of LPC out of the device tree. We would have the one LPC
node, and create a LPC driver that creates all of the sub devices
(snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this
plan?
Cheers,
Joel
>
> Chia-Wei, Wang (4):
> ARM: dts: Remove LPC BMC and Host partitions
> soc: aspeed: Fix LPC register offsets
> ipmi: kcs: aspeed: Fix LPC register offsets
> pinctrl: aspeed-g5: Fix LPC register offsets
>
> arch/arm/boot/dts/aspeed-g4.dtsi | 74 +++++------
> arch/arm/boot/dts/aspeed-g5.dtsi | 135 +++++++++------------
> arch/arm/boot/dts/aspeed-g6.dtsi | 135 +++++++++------------
> drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +-
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +-
> drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +-
> drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +-
> 7 files changed, 162 insertions(+), 214 deletions(-)
>
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/4] Remove LPC register partitioning
@ 2020-09-11 4:03 ` Joel Stanley
0 siblings, 0 replies; 31+ messages in thread
From: Joel Stanley @ 2020-09-11 4:03 UTC (permalink / raw)
To: Chia-Wei, Wang, Andrew Jeffery
Cc: Robert Lippert, Ryan Chen, linux-aspeed, Corey Minyard,
Linus Walleij, Linux Kernel Mailing List, OpenBMC Maillist,
Rob Herring, Linux ARM, Cyril Bur, Haiyue Wang
Hello,
On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang
<chiawei_wang@aspeedtech.com> wrote:
>
> The LPC controller has no concept of the BMC and the Host partitions.
> The incorrect partitioning can impose unnecessary range restrictions
> on register access through the syscon regmap interface.
>
> For instance, HICRB contains the I/O port address configuration
> of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access
> HICRB as it is located at the other LPC partition.
>
> In addition, to be backward compatible, the newly added HW control
> bits could be added at any reserved bits over the LPC addressing space.
>
> Thereby, this patch series aims to remove the LPC partitioning for
> better driver development and maintenance.
I support this cleanup. The only consideration is to be careful with
breaking the driver/device-tree relationship. We either need to ensure
the drivers remain compatible with both device trees.
Another solution is to get agreement from all parties that for the LPC
device the device tree is always the one shipped with the kernel, so
it is okay to make incompatible changes.
While we are doing a cleanup, Andrew suggested we remove the detailed
description of LPC out of the device tree. We would have the one LPC
node, and create a LPC driver that creates all of the sub devices
(snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this
plan?
Cheers,
Joel
>
> Chia-Wei, Wang (4):
> ARM: dts: Remove LPC BMC and Host partitions
> soc: aspeed: Fix LPC register offsets
> ipmi: kcs: aspeed: Fix LPC register offsets
> pinctrl: aspeed-g5: Fix LPC register offsets
>
> arch/arm/boot/dts/aspeed-g4.dtsi | 74 +++++------
> arch/arm/boot/dts/aspeed-g5.dtsi | 135 +++++++++------------
> arch/arm/boot/dts/aspeed-g6.dtsi | 135 +++++++++------------
> drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +-
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +-
> drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +-
> drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +-
> 7 files changed, 162 insertions(+), 214 deletions(-)
>
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/4] Remove LPC register partitioning
@ 2020-09-11 4:03 ` Joel Stanley
0 siblings, 0 replies; 31+ messages in thread
From: Joel Stanley @ 2020-09-11 4:03 UTC (permalink / raw)
To: Chia-Wei, Wang, Andrew Jeffery
Cc: Rob Herring, Corey Minyard, Linus Walleij, Haiyue Wang,
Cyril Bur, Robert Lippert, Linux ARM, linux-aspeed,
Linux Kernel Mailing List, OpenBMC Maillist, Ryan Chen
Hello,
On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang
<chiawei_wang@aspeedtech.com> wrote:
>
> The LPC controller has no concept of the BMC and the Host partitions.
> The incorrect partitioning can impose unnecessary range restrictions
> on register access through the syscon regmap interface.
>
> For instance, HICRB contains the I/O port address configuration
> of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access
> HICRB as it is located at the other LPC partition.
>
> In addition, to be backward compatible, the newly added HW control
> bits could be added at any reserved bits over the LPC addressing space.
>
> Thereby, this patch series aims to remove the LPC partitioning for
> better driver development and maintenance.
I support this cleanup. The only consideration is to be careful with
breaking the driver/device-tree relationship. We either need to ensure
the drivers remain compatible with both device trees.
Another solution is to get agreement from all parties that for the LPC
device the device tree is always the one shipped with the kernel, so
it is okay to make incompatible changes.
While we are doing a cleanup, Andrew suggested we remove the detailed
description of LPC out of the device tree. We would have the one LPC
node, and create a LPC driver that creates all of the sub devices
(snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this
plan?
Cheers,
Joel
>
> Chia-Wei, Wang (4):
> ARM: dts: Remove LPC BMC and Host partitions
> soc: aspeed: Fix LPC register offsets
> ipmi: kcs: aspeed: Fix LPC register offsets
> pinctrl: aspeed-g5: Fix LPC register offsets
>
> arch/arm/boot/dts/aspeed-g4.dtsi | 74 +++++------
> arch/arm/boot/dts/aspeed-g5.dtsi | 135 +++++++++------------
> arch/arm/boot/dts/aspeed-g6.dtsi | 135 +++++++++------------
> drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +-
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +-
> drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +-
> drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +-
> 7 files changed, 162 insertions(+), 214 deletions(-)
>
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/4] Remove LPC register partitioning
2020-09-11 4:03 ` Joel Stanley
@ 2020-09-11 4:45 ` Andrew Jeffery
-1 siblings, 0 replies; 31+ messages in thread
From: Andrew Jeffery @ 2020-09-11 4:45 UTC (permalink / raw)
To: Joel Stanley, Chia-Wei, Wang
Cc: Rob Herring, Corey Minyard, Linus Walleij, Haiyue Wang,
Cyril Bur, Robert Lippert, Linux ARM, linux-aspeed,
Linux Kernel Mailing List, OpenBMC Maillist, Ryan Chen
On Fri, 11 Sep 2020, at 13:33, Joel Stanley wrote:
> Hello,
>
> On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang
> <chiawei_wang@aspeedtech.com> wrote:
> >
> > The LPC controller has no concept of the BMC and the Host partitions.
> > The incorrect partitioning can impose unnecessary range restrictions
> > on register access through the syscon regmap interface.
> >
> > For instance, HICRB contains the I/O port address configuration
> > of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access
> > HICRB as it is located at the other LPC partition.
Thanks for addressing this, I've regretted that choice for a while now.
The split was rooted in trying to support pinmux while not being
across every detail of the LPC controller, and so I made some poor
decisions.
> >
> > In addition, to be backward compatible, the newly added HW control
> > bits could be added at any reserved bits over the LPC addressing space.
> >
> > Thereby, this patch series aims to remove the LPC partitioning for
> > better driver development and maintenance.
>
> I support this cleanup. The only consideration is to be careful with
> breaking the driver/device-tree relationship. We either need to ensure
> the drivers remain compatible with both device trees.
>
> Another solution is to get agreement from all parties that for the LPC
> device the device tree is always the one shipped with the kernel, so
> it is okay to make incompatible changes.
>
> While we are doing a cleanup, Andrew suggested we remove the detailed
> description of LPC out of the device tree. We would have the one LPC
> node, and create a LPC driver that creates all of the sub devices
> (snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this
> plan?
I dug up the conversation I had with Rob over a year ago about being
unhappy with what I'd cooked up.
https://lore.kernel.org/linux-arm-kernel/CAL_JsqJ+sFDG8eKbV3gvmqVHx+otWbki4dY213apzXgfhbXXEw@mail.gmail.com/
But I think you covered most of the idea there: We have the LPC driver
create the subdevices and that moves the details out of the devicetree.
However, I haven't thought about it more than that, and I think there are
still problems with that idea. For instance, how we manage configuration
of those devices, and how to enable only the devices a given platform
actually cares about (i.e. the problems that devicetree solves for us).
It may be that the only way to do that is with platform code, and that's
not really a direction we should be going either.
Andrew
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/4] Remove LPC register partitioning
@ 2020-09-11 4:45 ` Andrew Jeffery
0 siblings, 0 replies; 31+ messages in thread
From: Andrew Jeffery @ 2020-09-11 4:45 UTC (permalink / raw)
To: Joel Stanley, Chia-Wei, Wang
Cc: Robert Lippert, Ryan Chen, linux-aspeed, Corey Minyard,
Linus Walleij, Linux Kernel Mailing List, OpenBMC Maillist,
Rob Herring, Linux ARM, Cyril Bur, Haiyue Wang
On Fri, 11 Sep 2020, at 13:33, Joel Stanley wrote:
> Hello,
>
> On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang
> <chiawei_wang@aspeedtech.com> wrote:
> >
> > The LPC controller has no concept of the BMC and the Host partitions.
> > The incorrect partitioning can impose unnecessary range restrictions
> > on register access through the syscon regmap interface.
> >
> > For instance, HICRB contains the I/O port address configuration
> > of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access
> > HICRB as it is located at the other LPC partition.
Thanks for addressing this, I've regretted that choice for a while now.
The split was rooted in trying to support pinmux while not being
across every detail of the LPC controller, and so I made some poor
decisions.
> >
> > In addition, to be backward compatible, the newly added HW control
> > bits could be added at any reserved bits over the LPC addressing space.
> >
> > Thereby, this patch series aims to remove the LPC partitioning for
> > better driver development and maintenance.
>
> I support this cleanup. The only consideration is to be careful with
> breaking the driver/device-tree relationship. We either need to ensure
> the drivers remain compatible with both device trees.
>
> Another solution is to get agreement from all parties that for the LPC
> device the device tree is always the one shipped with the kernel, so
> it is okay to make incompatible changes.
>
> While we are doing a cleanup, Andrew suggested we remove the detailed
> description of LPC out of the device tree. We would have the one LPC
> node, and create a LPC driver that creates all of the sub devices
> (snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this
> plan?
I dug up the conversation I had with Rob over a year ago about being
unhappy with what I'd cooked up.
https://lore.kernel.org/linux-arm-kernel/CAL_JsqJ+sFDG8eKbV3gvmqVHx+otWbki4dY213apzXgfhbXXEw@mail.gmail.com/
But I think you covered most of the idea there: We have the LPC driver
create the subdevices and that moves the details out of the devicetree.
However, I haven't thought about it more than that, and I think there are
still problems with that idea. For instance, how we manage configuration
of those devices, and how to enable only the devices a given platform
actually cares about (i.e. the problems that devicetree solves for us).
It may be that the only way to do that is with platform code, and that's
not really a direction we should be going either.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: [PATCH 0/4] Remove LPC register partitioning
2020-09-11 4:45 ` Andrew Jeffery
@ 2020-09-11 8:21 ` ChiaWei Wang
-1 siblings, 0 replies; 31+ messages in thread
From: ChiaWei Wang @ 2020-09-11 8:21 UTC (permalink / raw)
To: Andrew Jeffery, Joel Stanley
Cc: Rob Herring, Corey Minyard, Linus Walleij, Haiyue Wang,
Cyril Bur, Robert Lippert, Linux ARM, linux-aspeed,
Linux Kernel Mailing List, OpenBMC Maillist, Ryan Chen
Hello,
Thanks for your prompt feedback.
> -----Original Message-----
> From: Andrew Jeffery <andrew@aj.id.au>
> Sent: Friday, September 11, 2020 12:46 PM
> To: Joel Stanley <joel@jms.id.au>; ChiaWei Wang
> <chiawei_wang@aspeedtech.com>
> Subject: Re: [PATCH 0/4] Remove LPC register partitioning
>
>
> On Fri, 11 Sep 2020, at 13:33, Joel Stanley wrote:
> > Hello,
> >
> > On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang
> > <chiawei_wang@aspeedtech.com> wrote:
> > >
> > > The LPC controller has no concept of the BMC and the Host partitions.
> > > The incorrect partitioning can impose unnecessary range restrictions
> > > on register access through the syscon regmap interface.
> > >
> > > For instance, HICRB contains the I/O port address configuration of
> > > KCS channel 1/2. However, the KCS#1/#2 drivers cannot access HICRB
> > > as it is located at the other LPC partition.
>
> Thanks for addressing this, I've regretted that choice for a while now.
>
> The split was rooted in trying to support pinmux while not being across every
> detail of the LPC controller, and so I made some poor decisions.
>
> > >
> > > In addition, to be backward compatible, the newly added HW control
> > > bits could be added at any reserved bits over the LPC addressing space.
> > >
> > > Thereby, this patch series aims to remove the LPC partitioning for
> > > better driver development and maintenance.
> >
> > I support this cleanup. The only consideration is to be careful with
> > breaking the driver/device-tree relationship. We either need to ensure
> > the drivers remain compatible with both device trees.
> >
> > Another solution is to get agreement from all parties that for the LPC
> > device the device tree is always the one shipped with the kernel, so
> > it is okay to make incompatible changes.
If it is possible, I would prefer this solution to avoid adding additional if-logic for the compatibility support in the driver implementation.
As the patch can be less change made to register offset definitions and leave the core logic untouched.
> >
> > While we are doing a cleanup, Andrew suggested we remove the detailed
> > description of LPC out of the device tree. We would have the one LPC
> > node, and create a LPC driver that creates all of the sub devices
> > (snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this
> > plan?
>
> I dug up the conversation I had with Rob over a year ago about being unhappy
> with what I'd cooked up.
>
> https://lore.kernel.org/linux-arm-kernel/CAL_JsqJ+sFDG8eKbV3gvmqVHx+otW
> bki4dY213apzXgfhbXXEw@mail.gmail.com/
>
> But I think you covered most of the idea there: We have the LPC driver create
> the subdevices and that moves the details out of the devicetree.
> However, I haven't thought about it more than that, and I think there are still
> problems with that idea. For instance, how we manage configuration of those
> devices, and how to enable only the devices a given platform actually cares
> about (i.e. the problems that devicetree solves for us).
Another concern to make centralized LPC driver implementation more complicated is the relationship with eSPI driver.
AST2500 binds the reset control of LPC and eSPI together. If eSPI is used for the Host communication, the behavior in current "lpc-ctrl" should be skipped but not for KCS, BT, Snoop, etc.
And this will be much easier to achieve by devicetree if LPC sub devices are individually described.
>
> It may be that the only way to do that is with platform code, and that's not
> really a direction we should be going either.
>
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: [PATCH 0/4] Remove LPC register partitioning
@ 2020-09-11 8:21 ` ChiaWei Wang
0 siblings, 0 replies; 31+ messages in thread
From: ChiaWei Wang @ 2020-09-11 8:21 UTC (permalink / raw)
To: Andrew Jeffery, Joel Stanley
Cc: Robert Lippert, Ryan Chen, linux-aspeed, Corey Minyard,
Linus Walleij, Linux Kernel Mailing List, OpenBMC Maillist,
Rob Herring, Linux ARM, Cyril Bur, Haiyue Wang
Hello,
Thanks for your prompt feedback.
> -----Original Message-----
> From: Andrew Jeffery <andrew@aj.id.au>
> Sent: Friday, September 11, 2020 12:46 PM
> To: Joel Stanley <joel@jms.id.au>; ChiaWei Wang
> <chiawei_wang@aspeedtech.com>
> Subject: Re: [PATCH 0/4] Remove LPC register partitioning
>
>
> On Fri, 11 Sep 2020, at 13:33, Joel Stanley wrote:
> > Hello,
> >
> > On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang
> > <chiawei_wang@aspeedtech.com> wrote:
> > >
> > > The LPC controller has no concept of the BMC and the Host partitions.
> > > The incorrect partitioning can impose unnecessary range restrictions
> > > on register access through the syscon regmap interface.
> > >
> > > For instance, HICRB contains the I/O port address configuration of
> > > KCS channel 1/2. However, the KCS#1/#2 drivers cannot access HICRB
> > > as it is located at the other LPC partition.
>
> Thanks for addressing this, I've regretted that choice for a while now.
>
> The split was rooted in trying to support pinmux while not being across every
> detail of the LPC controller, and so I made some poor decisions.
>
> > >
> > > In addition, to be backward compatible, the newly added HW control
> > > bits could be added at any reserved bits over the LPC addressing space.
> > >
> > > Thereby, this patch series aims to remove the LPC partitioning for
> > > better driver development and maintenance.
> >
> > I support this cleanup. The only consideration is to be careful with
> > breaking the driver/device-tree relationship. We either need to ensure
> > the drivers remain compatible with both device trees.
> >
> > Another solution is to get agreement from all parties that for the LPC
> > device the device tree is always the one shipped with the kernel, so
> > it is okay to make incompatible changes.
If it is possible, I would prefer this solution to avoid adding additional if-logic for the compatibility support in the driver implementation.
As the patch can be less change made to register offset definitions and leave the core logic untouched.
> >
> > While we are doing a cleanup, Andrew suggested we remove the detailed
> > description of LPC out of the device tree. We would have the one LPC
> > node, and create a LPC driver that creates all of the sub devices
> > (snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this
> > plan?
>
> I dug up the conversation I had with Rob over a year ago about being unhappy
> with what I'd cooked up.
>
> https://lore.kernel.org/linux-arm-kernel/CAL_JsqJ+sFDG8eKbV3gvmqVHx+otW
> bki4dY213apzXgfhbXXEw@mail.gmail.com/
>
> But I think you covered most of the idea there: We have the LPC driver create
> the subdevices and that moves the details out of the devicetree.
> However, I haven't thought about it more than that, and I think there are still
> problems with that idea. For instance, how we manage configuration of those
> devices, and how to enable only the devices a given platform actually cares
> about (i.e. the problems that devicetree solves for us).
Another concern to make centralized LPC driver implementation more complicated is the relationship with eSPI driver.
AST2500 binds the reset control of LPC and eSPI together. If eSPI is used for the Host communication, the behavior in current "lpc-ctrl" should be skipped but not for KCS, BT, Snoop, etc.
And this will be much easier to achieve by devicetree if LPC sub devices are individually described.
>
> It may be that the only way to do that is with platform code, and that's not
> really a direction we should be going either.
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: [PATCH 0/4] Remove LPC register partitioning
2020-09-11 8:21 ` ChiaWei Wang
(?)
@ 2020-09-28 7:43 ` Ryan Chen
-1 siblings, 0 replies; 31+ messages in thread
From: Ryan Chen @ 2020-09-28 7:43 UTC (permalink / raw)
To: ChiaWei Wang, Andrew Jeffery, Joel Stanley
Cc: Rob Herring, Corey Minyard, Linus Walleij, Haiyue Wang,
Cyril Bur, Robert Lippert, Linux ARM, linux-aspeed,
Linux Kernel Mailing List, OpenBMC Maillist
Hello Joel & Andrew,
Those patches are more organize for ASPEED SOC LPC register layout.
Does those patches have any feedback?
Ryan
> -----Original Message-----
> From: ChiaWei Wang <chiawei_wang@aspeedtech.com>
> Sent: Friday, September 11, 2020 4:21 PM
> To: Andrew Jeffery <andrew@aj.id.au>; Joel Stanley <joel@jms.id.au>
> Cc: Rob Herring <robh+dt@kernel.org>; Corey Minyard <minyard@acm.org>;
> Linus Walleij <linus.walleij@linaro.org>; Haiyue Wang
> <haiyue.wang@linux.intel.com>; Cyril Bur <cyrilbur@gmail.com>; Robert
> Lippert <rlippert@google.com>; Linux ARM
> <linux-arm-kernel@lists.infradead.org>; linux-aspeed
> <linux-aspeed@lists.ozlabs.org>; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; OpenBMC Maillist
> <openbmc@lists.ozlabs.org>; Ryan Chen <ryan_chen@aspeedtech.com>
> Subject: RE: [PATCH 0/4] Remove LPC register partitioning
>
> Hello,
>
> Thanks for your prompt feedback.
>
> > -----Original Message-----
> > From: Andrew Jeffery <andrew@aj.id.au>
> > Sent: Friday, September 11, 2020 12:46 PM
> > To: Joel Stanley <joel@jms.id.au>; ChiaWei Wang
> > <chiawei_wang@aspeedtech.com>
> > Subject: Re: [PATCH 0/4] Remove LPC register partitioning
> >
> >
> > On Fri, 11 Sep 2020, at 13:33, Joel Stanley wrote:
> > > Hello,
> > >
> > > On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang
> > > <chiawei_wang@aspeedtech.com> wrote:
> > > >
> > > > The LPC controller has no concept of the BMC and the Host partitions.
> > > > The incorrect partitioning can impose unnecessary range
> > > > restrictions on register access through the syscon regmap interface.
> > > >
> > > > For instance, HICRB contains the I/O port address configuration of
> > > > KCS channel 1/2. However, the KCS#1/#2 drivers cannot access HICRB
> > > > as it is located at the other LPC partition.
> >
> > Thanks for addressing this, I've regretted that choice for a while now.
> >
> > The split was rooted in trying to support pinmux while not being
> > across every detail of the LPC controller, and so I made some poor decisions.
> >
> > > >
> > > > In addition, to be backward compatible, the newly added HW control
> > > > bits could be added at any reserved bits over the LPC addressing space.
> > > >
> > > > Thereby, this patch series aims to remove the LPC partitioning for
> > > > better driver development and maintenance.
> > >
> > > I support this cleanup. The only consideration is to be careful with
> > > breaking the driver/device-tree relationship. We either need to
> > > ensure the drivers remain compatible with both device trees.
> > >
> > > Another solution is to get agreement from all parties that for the
> > > LPC device the device tree is always the one shipped with the
> > > kernel, so it is okay to make incompatible changes.
> If it is possible, I would prefer this solution to avoid adding additional if-logic
> for the compatibility support in the driver implementation.
> As the patch can be less change made to register offset definitions and leave
> the core logic untouched.
> > >
> > > While we are doing a cleanup, Andrew suggested we remove the
> > > detailed description of LPC out of the device tree. We would have
> > > the one LPC node, and create a LPC driver that creates all of the
> > > sub devices (snoop, FW cycles, kcs, bt, vuart). Andrew, can you
> > > elaborate on this plan?
> >
> > I dug up the conversation I had with Rob over a year ago about being
> > unhappy with what I'd cooked up.
> >
> > https://lore.kernel.org/linux-arm-kernel/CAL_JsqJ+sFDG8eKbV3gvmqVHx+ot
> > W
> > bki4dY213apzXgfhbXXEw@mail.gmail.com/
> >
> > But I think you covered most of the idea there: We have the LPC driver
> > create the subdevices and that moves the details out of the devicetree.
> > However, I haven't thought about it more than that, and I think there
> > are still problems with that idea. For instance, how we manage
> > configuration of those devices, and how to enable only the devices a
> > given platform actually cares about (i.e. the problems that devicetree solves
> for us).
> Another concern to make centralized LPC driver implementation more
> complicated is the relationship with eSPI driver.
> AST2500 binds the reset control of LPC and eSPI together. If eSPI is used for the
> Host communication, the behavior in current "lpc-ctrl" should be skipped but
> not for KCS, BT, Snoop, etc.
> And this will be much easier to achieve by devicetree if LPC sub devices are
> individually described.
> >
> > It may be that the only way to do that is with platform code, and
> > that's not really a direction we should be going either.
> >
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: [PATCH 0/4] Remove LPC register partitioning
@ 2020-09-28 7:43 ` Ryan Chen
0 siblings, 0 replies; 31+ messages in thread
From: Ryan Chen @ 2020-09-28 7:43 UTC (permalink / raw)
To: ChiaWei Wang, Andrew Jeffery, Joel Stanley
Cc: Robert Lippert, linux-aspeed, Corey Minyard, Linus Walleij,
Linux Kernel Mailing List, OpenBMC Maillist, Rob Herring,
Linux ARM, Cyril Bur, Haiyue Wang
Hello Joel & Andrew,
Those patches are more organize for ASPEED SOC LPC register layout.
Does those patches have any feedback?
Ryan
> -----Original Message-----
> From: ChiaWei Wang <chiawei_wang@aspeedtech.com>
> Sent: Friday, September 11, 2020 4:21 PM
> To: Andrew Jeffery <andrew@aj.id.au>; Joel Stanley <joel@jms.id.au>
> Cc: Rob Herring <robh+dt@kernel.org>; Corey Minyard <minyard@acm.org>;
> Linus Walleij <linus.walleij@linaro.org>; Haiyue Wang
> <haiyue.wang@linux.intel.com>; Cyril Bur <cyrilbur@gmail.com>; Robert
> Lippert <rlippert@google.com>; Linux ARM
> <linux-arm-kernel@lists.infradead.org>; linux-aspeed
> <linux-aspeed@lists.ozlabs.org>; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; OpenBMC Maillist
> <openbmc@lists.ozlabs.org>; Ryan Chen <ryan_chen@aspeedtech.com>
> Subject: RE: [PATCH 0/4] Remove LPC register partitioning
>
> Hello,
>
> Thanks for your prompt feedback.
>
> > -----Original Message-----
> > From: Andrew Jeffery <andrew@aj.id.au>
> > Sent: Friday, September 11, 2020 12:46 PM
> > To: Joel Stanley <joel@jms.id.au>; ChiaWei Wang
> > <chiawei_wang@aspeedtech.com>
> > Subject: Re: [PATCH 0/4] Remove LPC register partitioning
> >
> >
> > On Fri, 11 Sep 2020, at 13:33, Joel Stanley wrote:
> > > Hello,
> > >
> > > On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang
> > > <chiawei_wang@aspeedtech.com> wrote:
> > > >
> > > > The LPC controller has no concept of the BMC and the Host partitions.
> > > > The incorrect partitioning can impose unnecessary range
> > > > restrictions on register access through the syscon regmap interface.
> > > >
> > > > For instance, HICRB contains the I/O port address configuration of
> > > > KCS channel 1/2. However, the KCS#1/#2 drivers cannot access HICRB
> > > > as it is located at the other LPC partition.
> >
> > Thanks for addressing this, I've regretted that choice for a while now.
> >
> > The split was rooted in trying to support pinmux while not being
> > across every detail of the LPC controller, and so I made some poor decisions.
> >
> > > >
> > > > In addition, to be backward compatible, the newly added HW control
> > > > bits could be added at any reserved bits over the LPC addressing space.
> > > >
> > > > Thereby, this patch series aims to remove the LPC partitioning for
> > > > better driver development and maintenance.
> > >
> > > I support this cleanup. The only consideration is to be careful with
> > > breaking the driver/device-tree relationship. We either need to
> > > ensure the drivers remain compatible with both device trees.
> > >
> > > Another solution is to get agreement from all parties that for the
> > > LPC device the device tree is always the one shipped with the
> > > kernel, so it is okay to make incompatible changes.
> If it is possible, I would prefer this solution to avoid adding additional if-logic
> for the compatibility support in the driver implementation.
> As the patch can be less change made to register offset definitions and leave
> the core logic untouched.
> > >
> > > While we are doing a cleanup, Andrew suggested we remove the
> > > detailed description of LPC out of the device tree. We would have
> > > the one LPC node, and create a LPC driver that creates all of the
> > > sub devices (snoop, FW cycles, kcs, bt, vuart). Andrew, can you
> > > elaborate on this plan?
> >
> > I dug up the conversation I had with Rob over a year ago about being
> > unhappy with what I'd cooked up.
> >
> > https://lore.kernel.org/linux-arm-kernel/CAL_JsqJ+sFDG8eKbV3gvmqVHx+ot
> > W
> > bki4dY213apzXgfhbXXEw@mail.gmail.com/
> >
> > But I think you covered most of the idea there: We have the LPC driver
> > create the subdevices and that moves the details out of the devicetree.
> > However, I haven't thought about it more than that, and I think there
> > are still problems with that idea. For instance, how we manage
> > configuration of those devices, and how to enable only the devices a
> > given platform actually cares about (i.e. the problems that devicetree solves
> for us).
> Another concern to make centralized LPC driver implementation more
> complicated is the relationship with eSPI driver.
> AST2500 binds the reset control of LPC and eSPI together. If eSPI is used for the
> Host communication, the behavior in current "lpc-ctrl" should be skipped but
> not for KCS, BT, Snoop, etc.
> And this will be much easier to achieve by devicetree if LPC sub devices are
> individually described.
> >
> > It may be that the only way to do that is with platform code, and
> > that's not really a direction we should be going either.
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: [PATCH 0/4] Remove LPC register partitioning
@ 2020-09-28 7:43 ` Ryan Chen
0 siblings, 0 replies; 31+ messages in thread
From: Ryan Chen @ 2020-09-28 7:43 UTC (permalink / raw)
To: ChiaWei Wang, Andrew Jeffery, Joel Stanley
Cc: linux-aspeed, Corey Minyard, Linus Walleij,
Linux Kernel Mailing List, OpenBMC Maillist, Rob Herring,
Linux ARM, Cyril Bur, Haiyue Wang
Hello Joel & Andrew,
Those patches are more organize for ASPEED SOC LPC register layout.
Does those patches have any feedback?
Ryan
> -----Original Message-----
> From: ChiaWei Wang <chiawei_wang@aspeedtech.com>
> Sent: Friday, September 11, 2020 4:21 PM
> To: Andrew Jeffery <andrew@aj.id.au>; Joel Stanley <joel@jms.id.au>
> Cc: Rob Herring <robh+dt@kernel.org>; Corey Minyard <minyard@acm.org>;
> Linus Walleij <linus.walleij@linaro.org>; Haiyue Wang
> <haiyue.wang@linux.intel.com>; Cyril Bur <cyrilbur@gmail.com>; Robert
> Lippert <rlippert@google.com>; Linux ARM
> <linux-arm-kernel@lists.infradead.org>; linux-aspeed
> <linux-aspeed@lists.ozlabs.org>; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; OpenBMC Maillist
> <openbmc@lists.ozlabs.org>; Ryan Chen <ryan_chen@aspeedtech.com>
> Subject: RE: [PATCH 0/4] Remove LPC register partitioning
>
> Hello,
>
> Thanks for your prompt feedback.
>
> > -----Original Message-----
> > From: Andrew Jeffery <andrew@aj.id.au>
> > Sent: Friday, September 11, 2020 12:46 PM
> > To: Joel Stanley <joel@jms.id.au>; ChiaWei Wang
> > <chiawei_wang@aspeedtech.com>
> > Subject: Re: [PATCH 0/4] Remove LPC register partitioning
> >
> >
> > On Fri, 11 Sep 2020, at 13:33, Joel Stanley wrote:
> > > Hello,
> > >
> > > On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang
> > > <chiawei_wang@aspeedtech.com> wrote:
> > > >
> > > > The LPC controller has no concept of the BMC and the Host partitions.
> > > > The incorrect partitioning can impose unnecessary range
> > > > restrictions on register access through the syscon regmap interface.
> > > >
> > > > For instance, HICRB contains the I/O port address configuration of
> > > > KCS channel 1/2. However, the KCS#1/#2 drivers cannot access HICRB
> > > > as it is located at the other LPC partition.
> >
> > Thanks for addressing this, I've regretted that choice for a while now.
> >
> > The split was rooted in trying to support pinmux while not being
> > across every detail of the LPC controller, and so I made some poor decisions.
> >
> > > >
> > > > In addition, to be backward compatible, the newly added HW control
> > > > bits could be added at any reserved bits over the LPC addressing space.
> > > >
> > > > Thereby, this patch series aims to remove the LPC partitioning for
> > > > better driver development and maintenance.
> > >
> > > I support this cleanup. The only consideration is to be careful with
> > > breaking the driver/device-tree relationship. We either need to
> > > ensure the drivers remain compatible with both device trees.
> > >
> > > Another solution is to get agreement from all parties that for the
> > > LPC device the device tree is always the one shipped with the
> > > kernel, so it is okay to make incompatible changes.
> If it is possible, I would prefer this solution to avoid adding additional if-logic
> for the compatibility support in the driver implementation.
> As the patch can be less change made to register offset definitions and leave
> the core logic untouched.
> > >
> > > While we are doing a cleanup, Andrew suggested we remove the
> > > detailed description of LPC out of the device tree. We would have
> > > the one LPC node, and create a LPC driver that creates all of the
> > > sub devices (snoop, FW cycles, kcs, bt, vuart). Andrew, can you
> > > elaborate on this plan?
> >
> > I dug up the conversation I had with Rob over a year ago about being
> > unhappy with what I'd cooked up.
> >
> > https://lore.kernel.org/linux-arm-kernel/CAL_JsqJ+sFDG8eKbV3gvmqVHx+ot
> > W
> > bki4dY213apzXgfhbXXEw@mail.gmail.com/
> >
> > But I think you covered most of the idea there: We have the LPC driver
> > create the subdevices and that moves the details out of the devicetree.
> > However, I haven't thought about it more than that, and I think there
> > are still problems with that idea. For instance, how we manage
> > configuration of those devices, and how to enable only the devices a
> > given platform actually cares about (i.e. the problems that devicetree solves
> for us).
> Another concern to make centralized LPC driver implementation more
> complicated is the relationship with eSPI driver.
> AST2500 binds the reset control of LPC and eSPI together. If eSPI is used for the
> Host communication, the behavior in current "lpc-ctrl" should be skipped but
> not for KCS, BT, Snoop, etc.
> And this will be much easier to achieve by devicetree if LPC sub devices are
> individually described.
> >
> > It may be that the only way to do that is with platform code, and
> > that's not really a direction we should be going either.
> >
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/4] Remove LPC register partitioning
2020-09-28 7:43 ` Ryan Chen
(?)
@ 2020-09-30 6:11 ` Andrew Jeffery
-1 siblings, 0 replies; 31+ messages in thread
From: Andrew Jeffery @ 2020-09-30 6:11 UTC (permalink / raw)
To: Ryan Chen, Chia-Wei, Wang, Joel Stanley
Cc: Robert Lippert, linux-aspeed, Corey Minyard, Linus Walleij,
Linux Kernel Mailing List, OpenBMC Maillist, Rob Herring,
Linux ARM, Cyril Bur, Haiyue Wang
On Mon, 28 Sep 2020, at 17:13, Ryan Chen wrote:
> Hello Joel & Andrew,
> Those patches are more organize for ASPEED SOC LPC register layout.
> Does those patches have any feedback?
I support getting the problem fixed. However, the series also needs to fix the
LPC devicetree binding at
Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
What's proposed isn't backwards compatible. We need to agree that a breaking
change is the way we want to go and get Rob's buy-in. Given the impact of the
change I'd prefer we don't try to maintain backwards compatibility. All known
users of the binding ship the dtb with the kernel.
Can we get a v2 with the binding documentation fixed? That will probably need
some review.
Andrew
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/4] Remove LPC register partitioning
@ 2020-09-30 6:11 ` Andrew Jeffery
0 siblings, 0 replies; 31+ messages in thread
From: Andrew Jeffery @ 2020-09-30 6:11 UTC (permalink / raw)
To: Ryan Chen, Chia-Wei, Wang, Joel Stanley
Cc: Robert Lippert, linux-aspeed, Corey Minyard, OpenBMC Maillist,
Linux Kernel Mailing List, Cyril Bur, Rob Herring, Haiyue Wang,
Linus Walleij, Linux ARM
On Mon, 28 Sep 2020, at 17:13, Ryan Chen wrote:
> Hello Joel & Andrew,
> Those patches are more organize for ASPEED SOC LPC register layout.
> Does those patches have any feedback?
I support getting the problem fixed. However, the series also needs to fix the
LPC devicetree binding at
Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
What's proposed isn't backwards compatible. We need to agree that a breaking
change is the way we want to go and get Rob's buy-in. Given the impact of the
change I'd prefer we don't try to maintain backwards compatibility. All known
users of the binding ship the dtb with the kernel.
Can we get a v2 with the binding documentation fixed? That will probably need
some review.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 0/4] Remove LPC register partitioning
@ 2020-09-30 6:11 ` Andrew Jeffery
0 siblings, 0 replies; 31+ messages in thread
From: Andrew Jeffery @ 2020-09-30 6:11 UTC (permalink / raw)
To: Ryan Chen, Chia-Wei, Wang, Joel Stanley
Cc: linux-aspeed, Corey Minyard, OpenBMC Maillist,
Linux Kernel Mailing List, Cyril Bur, Rob Herring, Haiyue Wang,
Linus Walleij, Linux ARM
On Mon, 28 Sep 2020, at 17:13, Ryan Chen wrote:
> Hello Joel & Andrew,
> Those patches are more organize for ASPEED SOC LPC register layout.
> Does those patches have any feedback?
I support getting the problem fixed. However, the series also needs to fix the
LPC devicetree binding at
Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
What's proposed isn't backwards compatible. We need to agree that a breaking
change is the way we want to go and get Rob's buy-in. Given the impact of the
change I'd prefer we don't try to maintain backwards compatibility. All known
users of the binding ship the dtb with the kernel.
Can we get a v2 with the binding documentation fixed? That will probably need
some review.
Andrew
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: [PATCH 0/4] Remove LPC register partitioning
2020-09-30 6:11 ` Andrew Jeffery
@ 2020-09-30 7:54 ` ChiaWei Wang
-1 siblings, 0 replies; 31+ messages in thread
From: ChiaWei Wang @ 2020-09-30 7:54 UTC (permalink / raw)
To: Andrew Jeffery, Ryan Chen, Joel Stanley
Cc: Robert Lippert, linux-aspeed, Corey Minyard, Linus Walleij,
Linux Kernel Mailing List, OpenBMC Maillist, Rob Herring,
Linux ARM, Cyril Bur, Haiyue Wang
Hi Andrew,
> -----Original Message-----
> From: Andrew Jeffery <andrew@aj.id.au>
> Sent: Wednesday, September 30, 2020 2:12 PM
> To: Ryan Chen <ryan_chen@aspeedtech.com>; ChiaWei Wang
> <chiawei_wang@aspeedtech.com>; Joel Stanley <joel@jms.id.au>
> Subject: Re: [PATCH 0/4] Remove LPC register partitioning
>
>
>
> On Mon, 28 Sep 2020, at 17:13, Ryan Chen wrote:
> > Hello Joel & Andrew,
> > Those patches are more organize for ASPEED SOC LPC register layout.
> > Does those patches have any feedback?
>
> I support getting the problem fixed. However, the series also needs to fix the
> LPC devicetree binding at
>
> Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
>
> What's proposed isn't backwards compatible. We need to agree that a
> breaking change is the way we want to go and get Rob's buy-in. Given the
> impact of the change I'd prefer we don't try to maintain backwards
> compatibility. All known users of the binding ship the dtb with the kernel.
>
> Can we get a v2 with the binding documentation fixed? That will probably need
> some review.
Yes, I will fix the binding documentation and resend the v2 patch for the review.
Thanks.
^ permalink raw reply [flat|nested] 31+ messages in thread
* RE: [PATCH 0/4] Remove LPC register partitioning
@ 2020-09-30 7:54 ` ChiaWei Wang
0 siblings, 0 replies; 31+ messages in thread
From: ChiaWei Wang @ 2020-09-30 7:54 UTC (permalink / raw)
To: Andrew Jeffery, Ryan Chen, Joel Stanley
Cc: linux-aspeed, Corey Minyard, OpenBMC Maillist,
Linux Kernel Mailing List, Cyril Bur, Rob Herring, Haiyue Wang,
Linus Walleij, Linux ARM
Hi Andrew,
> -----Original Message-----
> From: Andrew Jeffery <andrew@aj.id.au>
> Sent: Wednesday, September 30, 2020 2:12 PM
> To: Ryan Chen <ryan_chen@aspeedtech.com>; ChiaWei Wang
> <chiawei_wang@aspeedtech.com>; Joel Stanley <joel@jms.id.au>
> Subject: Re: [PATCH 0/4] Remove LPC register partitioning
>
>
>
> On Mon, 28 Sep 2020, at 17:13, Ryan Chen wrote:
> > Hello Joel & Andrew,
> > Those patches are more organize for ASPEED SOC LPC register layout.
> > Does those patches have any feedback?
>
> I support getting the problem fixed. However, the series also needs to fix the
> LPC devicetree binding at
>
> Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
>
> What's proposed isn't backwards compatible. We need to agree that a
> breaking change is the way we want to go and get Rob's buy-in. Given the
> impact of the change I'd prefer we don't try to maintain backwards
> compatibility. All known users of the binding ship the dtb with the kernel.
>
> Can we get a v2 with the binding documentation fixed? That will probably need
> some review.
Yes, I will fix the binding documentation and resend the v2 patch for the review.
Thanks.
^ permalink raw reply [flat|nested] 31+ messages in thread