Hi
This v6 series adds basic networking support support TI K3 AM654x/J721E SoC which
have integrated Gigabit Ethernet MAC (Media Access Controller) into device MCU
domain and named MCU_CPSW0 (CPSW2G NUSS).
Formally TRMs refer CPSW2G NUSS as two-port Gigabit Ethernet Switch subsystem
with port 0 being the CPPI DMA host port and port 1 being the external Ethernet
port, but for 1 external port device it's just Port 0 <-> ALE <-> Port 1 and it's
rather device with HW filtering capabilities then actually switching device.
It's expected to have similar devices, but with more external ports.
The new Host port 0 Communications Port Programming Interface (CPPI5) is
operating by TI AM654x/J721E NAVSS Unified DMA Peripheral Root Complex (UDMA-P)
controller [1].
The CPSW2G contains below modules for which existing code is re-used:
- MAC SL: cpsw_sl.c
- Address Lookup Engine (ALE): cpsw_ale.c, basically compatible with K2 66AK2E/G
- Management Data Input/Output interface (MDIO): davinci_mdio.c, fully
compatible with TI AM3/4/5 devices
Basic features supported by CPSW2G NUSS driver:
- VLAN support, 802.1Q compliant, Auto add port VLAN for untagged frames on
ingress, Auto VLAN removal on egress and auto pad to minimum frame size.
- multicast filtering
- promisc mode
- TX multiq support in Round Robin or Fixed priority modes
- RX checksum offload for non-fragmented IPv4/IPv6 TCP/UDP packets
- TX checksum offload support for IPv4/IPv6 TCP/UDP packets (J721E only).
Features under development:
- Support for IEEE 1588 Clock Synchronization. The CPSW2G NUSS includes new
version of Common Platform Time Sync (CPTS)
- tc-mqprio: priority level Quality Of Service (QOS) support (802.1p)
- tc-cbs: Support for Audio/Video Bridging (P802.1Qav/D6.0) HW shapers
- tc-taprio: IEEE 802.1Qbv/D2.2 Enhancements for Scheduled Traffic
- frame preemption: IEEE P902.3br/D2.0 Interspersing Express Traffic, 802.1Qbu
- extended ALE features: classifier/policers, auto-aging
Patches 1-6 are intended for netdev, Patches 7-11 are intended for K3 Platform
tree and provided here for testing purposes.
Changes in v6:
- fixed comments from Rob Herring <[email protected]> and added his Reviewed-by.
- added Tested-by: Peter Ujfalusi <[email protected]>
Changes in v5:
- renamed files k3-udma-desc-pool.* k3-udma-desc-pool to k3-cppi-desc-pool.*,
and API to k3_cppi_desc_pool_* as requested by Peter Ujfalusi <[email protected]>
- fixed copy-paste err in am65_cpsw_nuss_ndo_slave_set_rx_mode() which blocked
recieving of mcast frames.
- added Tested-by: Murali Karicheri <[email protected]>
Changes in v4:
- fixed minor comments from Jakub Kicinski <[email protected]>
- dependencies resolved: required phy-rmii-sel changes [2] queued for merge
except one [3] which is included in this series with Kishon's ask.
Changes in v3:
- add ARM64 defconfig changes for testing purposes
- fixed DT yaml definition
- fixed comments from Jakub Kicinski <[email protected]>
Changes in v2:
- fixed DT yaml definition
- fixed comments from David Miller
v5: https://patchwork.ozlabs.org/cover/1258295/
v4: https://patchwork.ozlabs.org/cover/1256092/
v3: https://patchwork.ozlabs.org/cover/1254568/
v2: https://patchwork.ozlabs.org/cover/1250674/
v1: https://lwn.net/Articles/813087/
TRMs:
AM654: http://www.ti.com/lit/ug/spruid7e/spruid7e.pdf
J721E: http://www.ti.com/lit/ug/spruil1a/spruil1a.pdf
Preliminary documentation can be found at:
http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/K3_CPSW2g.html
[1] https://lwn.net/Articles/808030/
[2] https://lkml.org/lkml/2020/2/22/100
[3] https://lkml.org/lkml/2020/3/3/724
Grygorii Strashko (11):
phy: ti: gmii-sel: simplify config dependencies between net drivers
and gmii phy
net: ethernet: ti: ale: fix seeing unreg mcast packets with promisc
and allmulti disabled
net: ethernet: ti: ale: add support for mac-only mode
net: ethernet: ti: ale: am65: add support for default thread cfg
dt-binding: ti: am65x: document mcu cpsw nuss
net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver
arm64: dts: ti: k3-am65-mcu: add cpsw nuss node
arm64: dts: k3-am654-base-board: add mcu cpsw nuss pinmux and phy defs
arm64: dts: ti: k3-j721e-mcu: add mcu cpsw nuss node
arm64: dts: ti: k3-j721e-common-proc-board: add mcu cpsw nuss pinmux
and phy defs
arm64: defconfig: ti: k3: enable dma and networking
.../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 225 ++
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 49 +
arch/arm64/boot/dts/ti/k3-am65.dtsi | 1 +
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 42 +
.../dts/ti/k3-j721e-common-proc-board.dts | 43 +
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 49 +
arch/arm64/boot/dts/ti/k3-j721e.dtsi | 1 +
arch/arm64/configs/defconfig | 3 +
drivers/net/ethernet/ti/Kconfig | 20 +-
drivers/net/ethernet/ti/Makefile | 3 +
drivers/net/ethernet/ti/am65-cpsw-ethtool.c | 747 +++++++
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 1965 +++++++++++++++++
drivers/net/ethernet/ti/am65-cpsw-nuss.h | 142 ++
drivers/net/ethernet/ti/cpsw_ale.c | 38 +
drivers/net/ethernet/ti/cpsw_ale.h | 4 +
drivers/net/ethernet/ti/k3-cppi-desc-pool.c | 126 ++
drivers/net/ethernet/ti/k3-cppi-desc-pool.h | 30 +
drivers/phy/ti/Kconfig | 3 -
18 files changed, 3486 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
create mode 100644 drivers/net/ethernet/ti/am65-cpsw-ethtool.c
create mode 100644 drivers/net/ethernet/ti/am65-cpsw-nuss.c
create mode 100644 drivers/net/ethernet/ti/am65-cpsw-nuss.h
create mode 100644 drivers/net/ethernet/ti/k3-cppi-desc-pool.c
create mode 100644 drivers/net/ethernet/ti/k3-cppi-desc-pool.h
--
2.17.1
The phy-gmii-sel can be only auto selected in Kconfig and now the pretty
complex Kconfig dependencies are defined for phy-gmii-sel driver, which
also need to be updated every time phy-gmii-sel is re-used for any new
networking driver.
Simplify Kconfig definition for phy-gmii-sel PHY driver - drop all
dependencies and from networking drivers and rely on using 'imply
PHY_TI_GMII_SEL' in Kconfig definitions for networking drivers instead.
Signed-off-by: Grygorii Strashko <[email protected]>
Acked-by: Kishon Vijay Abraham I <[email protected]>
Tested-by: Murali Karicheri <[email protected]>
Tested-by: Peter Ujfalusi <[email protected]>
---
drivers/net/ethernet/ti/Kconfig | 1 +
drivers/phy/ti/Kconfig | 3 ---
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index bf98e0fa7d8b..8a6ca16eee3b 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -53,6 +53,7 @@ config TI_CPSW
select MFD_SYSCON
select PAGE_POOL
select REGMAP
+ imply PHY_TI_GMII_SEL
---help---
This driver supports TI's CPSW Ethernet Switch.
diff --git a/drivers/phy/ti/Kconfig b/drivers/phy/ti/Kconfig
index 6dbe9d0b9ff3..15a3bcf32308 100644
--- a/drivers/phy/ti/Kconfig
+++ b/drivers/phy/ti/Kconfig
@@ -106,11 +106,8 @@ config TWL4030_USB
config PHY_TI_GMII_SEL
tristate
- default y if TI_CPSW=y || TI_CPSW_SWITCHDEV=y
- depends on TI_CPSW || TI_CPSW_SWITCHDEV || COMPILE_TEST
select GENERIC_PHY
select REGMAP
- default m
help
This driver supports configuring of the TI CPSW Port mode depending on
the Ethernet PHY connected to the CPSW Port.
--
2.17.1
AM654 EVM base board has TI DP83867 PHY connected to external CPSW NUSS
Port 1 in rgmii-rxid mode.
Hence, add pinmux and Ethernet PHY configuration for TI am654 SoC Gigabit
Ethernet two ports Switch subsystem (CPSW NUSS).
Signed-off-by: Grygorii Strashko <[email protected]>
Tested-by: Murali Karicheri <[email protected]>
Tested-by: Peter Ujfalusi <[email protected]>
---
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 42 +++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index 1700996800eb..2f3d3316a1cf 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -7,6 +7,7 @@
#include "k3-am654.dtsi"
#include <dt-bindings/input/input.h>
+#include <dt-bindings/net/ti-dp83867.h>
/ {
compatible = "ti,am654-evm", "ti,am654";
@@ -95,7 +96,30 @@
wkup_pca554_default: wkup_pca554_default {
pinctrl-single,pins = <
AM65X_WKUP_IOPAD(0x0034, PIN_INPUT, 7) /* (T1) MCU_OSPI1_CLK.WKUP_GPIO0_25 */
+ >;
+ };
+
+ mcu_cpsw_pins_default: mcu_cpsw_pins_default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT, 0) /* (N4) MCU_RGMII1_TX_CTL */
+ AM65X_WKUP_IOPAD(0x005c, PIN_INPUT, 0) /* (N5) MCU_RGMII1_RX_CTL */
+ AM65X_WKUP_IOPAD(0x0060, PIN_OUTPUT, 0) /* (M2) MCU_RGMII1_TD3 */
+ AM65X_WKUP_IOPAD(0x0064, PIN_OUTPUT, 0) /* (M3) MCU_RGMII1_TD2 */
+ AM65X_WKUP_IOPAD(0x0068, PIN_OUTPUT, 0) /* (M4) MCU_RGMII1_TD1 */
+ AM65X_WKUP_IOPAD(0x006c, PIN_OUTPUT, 0) /* (M5) MCU_RGMII1_TD0 */
+ AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 0) /* (L2) MCU_RGMII1_RD3 */
+ AM65X_WKUP_IOPAD(0x007c, PIN_INPUT, 0) /* (L5) MCU_RGMII1_RD2 */
+ AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 0) /* (M6) MCU_RGMII1_RD1 */
+ AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 0) /* (L6) MCU_RGMII1_RD0 */
+ AM65X_WKUP_IOPAD(0x0070, PIN_INPUT, 0) /* (N1) MCU_RGMII1_TXC */
+ AM65X_WKUP_IOPAD(0x0074, PIN_INPUT, 0) /* (M1) MCU_RGMII1_RXC */
+ >;
+ };
+ mcu_mdio_pins_default: mcu_mdio1_pins_default {
+ pinctrl-single,pins = <
+ AM65X_WKUP_IOPAD(0x008c, PIN_OUTPUT, 0) /* (L1) MCU_MDIO0_MDC */
+ AM65X_WKUP_IOPAD(0x0088, PIN_INPUT, 0) /* (L4) MCU_MDIO0_MDIO */
>;
};
};
@@ -419,3 +443,21 @@
data-lanes = <1 2>;
};
};
+
+&mcu_cpsw {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_cpsw_pins_default &mcu_mdio_pins_default>;
+};
+
+&davinci_mdio {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ };
+};
+
+&cpsw_port1 {
+ phy-mode = "rgmii-rxid";
+ phy-handle = <&phy0>;
+};
--
2.17.1
Add DT node for the TI AM65x SoC Gigabit Ethernet two ports Switch
subsystem (CPSW NUSS).
Signed-off-by: Grygorii Strashko <[email protected]>
Tested-by: Murali Karicheri <[email protected]>
Tested-by: Peter Ujfalusi <[email protected]>
---
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 49 +++++++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am65.dtsi | 1 +
2 files changed, 50 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index ad89f93f30e5..e645664f004e 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -193,4 +193,53 @@
#size-cells = <0>;
};
};
+
+ mcu_cpsw: ethernet@46000000 {
+ compatible = "ti,am654-cpsw-nuss";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ reg = <0x0 0x46000000 0x0 0x200000>;
+ reg-names = "cpsw_nuss";
+ ranges = <0x0 0x0 0x0 0x46000000 0x0 0x200000>;
+ dma-coherent;
+ clocks = <&k3_clks 5 10>;
+ clock-names = "fck";
+ power-domains = <&k3_pds 5 TI_SCI_PD_EXCLUSIVE>;
+
+ dmas = <&mcu_udmap 0xf000>,
+ <&mcu_udmap 0xf001>,
+ <&mcu_udmap 0xf002>,
+ <&mcu_udmap 0xf003>,
+ <&mcu_udmap 0xf004>,
+ <&mcu_udmap 0xf005>,
+ <&mcu_udmap 0xf006>,
+ <&mcu_udmap 0xf007>,
+ <&mcu_udmap 0x7000>;
+ dma-names = "tx0", "tx1", "tx2", "tx3",
+ "tx4", "tx5", "tx6", "tx7",
+ "rx";
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpsw_port1: port@1 {
+ reg = <1>;
+ ti,mac-only;
+ label = "port1";
+ ti,syscon-efuse = <&mcu_conf 0x200>;
+ phys = <&phy_gmii_sel 1>;
+ };
+ };
+
+ davinci_mdio: mdio@f00 {
+ compatible = "ti,cpsw-mdio","ti,davinci_mdio";
+ reg = <0x0 0xf00 0x0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&k3_clks 5 10>;
+ clock-names = "fck";
+ bus_freq = <1000000>;
+ };
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-am65.dtsi b/arch/arm64/boot/dts/ti/k3-am65.dtsi
index aea36e29dd32..5be75e430965 100644
--- a/arch/arm64/boot/dts/ti/k3-am65.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65.dtsi
@@ -30,6 +30,7 @@
i2c3 = &main_i2c1;
i2c4 = &main_i2c2;
i2c5 = &main_i2c3;
+ ethernet0 = &cpsw_port1;
};
chosen { };
--
2.17.1
On AM65xx MCU CPSW2G NUSS and 66AK2E/L NUSS the unregistered multicast
packets are still can be received with promisc and allmulti disabled.
This happens, because ALE VLAN entries on these SoCs do not contain port
masks for reg/unreg mcast packets, but instead store indexes of
ALE_VLAN_MASK_MUXx_REG registers which intended for store port masks for
reg/unreg mcast packets.
ALE VLAN entry:UNREG_MCAST_FLOOD_INDEX -> ALE_VLAN_MASK_MUXx
ALE VLAN entry:REG_MCAST_FLOOD_INDEX -> ALE_VLAN_MASK_MUXy
The commit b361da837392 ("net: netcp: ale: add proper ale entry mask bits
for netcp switch ALE") update ALE code to support such ALE entries, it is
always used ALE_VLAN_MASK_MUX0_REG index in ALE VLAN entry for unreg mcast
packets mask configuration, which is read-only, at least for AM65xx MCU
CPSW2G NUSS and 66AK2E/L NUSS. As result unreg mcast packets are allowed
always.
Hence, update ALE code to use ALE_VLAN_MASK_MUX1_REG index for ALE VLAN
entries to configure unreg mcast port mask.
Fixes: b361da837392 ("net: netcp: ale: add proper ale entry mask bits for netcp switch ALE")
Signed-off-by: Grygorii Strashko <[email protected]>
Tested-by: Murali Karicheri <[email protected]>
Tested-by: Peter Ujfalusi <[email protected]>
---
drivers/net/ethernet/ti/cpsw_ale.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw_ale.c b/drivers/net/ethernet/ti/cpsw_ale.c
index ecdbde539eb7..5815225c000c 100644
--- a/drivers/net/ethernet/ti/cpsw_ale.c
+++ b/drivers/net/ethernet/ti/cpsw_ale.c
@@ -122,6 +122,8 @@ DEFINE_ALE_FIELD(mcast, 40, 1)
DEFINE_ALE_FIELD(vlan_unreg_mcast_idx, 20, 3)
DEFINE_ALE_FIELD(vlan_reg_mcast_idx, 44, 3)
+#define NU_VLAN_UNREG_MCAST_IDX 1
+
/* The MAC address field in the ALE entry cannot be macroized as above */
static inline void cpsw_ale_get_addr(u32 *ale_entry, u8 *addr)
{
@@ -455,6 +457,8 @@ int cpsw_ale_add_vlan(struct cpsw_ale *ale, u16 vid, int port_mask, int untag,
cpsw_ale_set_vlan_unreg_mcast(ale_entry, unreg_mcast,
ale->vlan_field_bits);
} else {
+ cpsw_ale_set_vlan_unreg_mcast_idx(ale_entry,
+ NU_VLAN_UNREG_MCAST_IDX);
cpsw_ale_set_vlan_mcast(ale, ale_entry, reg_mcast, unreg_mcast);
}
cpsw_ale_set_vlan_member_list(ale_entry, port_mask,
--
2.17.1
From: Grygorii Strashko <[email protected]>
Date: Tue, 24 Mar 2020 00:52:43 +0200
> This v6 series adds basic networking support support TI K3 AM654x/J721E SoC which
> have integrated Gigabit Ethernet MAC (Media Access Controller) into device MCU
> domain and named MCU_CPSW0 (CPSW2G NUSS).
...
Series applied, thank you.
Hi David,
On Fri, 27 Mar 2020 at 05:02, David Miller <[email protected]> wrote:
>
> From: Grygorii Strashko <[email protected]>
> Date: Tue, 24 Mar 2020 00:52:43 +0200
>
> > This v6 series adds basic networking support support TI K3 AM654x/J721E SoC which
> > have integrated Gigabit Ethernet MAC (Media Access Controller) into device MCU
> > domain and named MCU_CPSW0 (CPSW2G NUSS).
> ...
>
> Series applied, thank you.
The build is now broken on net-next:
arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
(phandle_references):
/interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
Reference to non-existent node
or label "mcu_conf"
also defined at
arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
(phandle_references):
/interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
Reference to non-existent node
or label "phy_gmii_sel"
also defined at
arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
As Grygorii said:
Patches 1-6 are intended for netdev, Patches 7-11 are intended for K3 Platform
tree and provided here for testing purposes.
Regards,
-Vladimir
On 28/03/2020 03:53, Vladimir Oltean wrote:
> Hi David,
>
> On Fri, 27 Mar 2020 at 05:02, David Miller <[email protected]> wrote:
>>
>> From: Grygorii Strashko <[email protected]>
>> Date: Tue, 24 Mar 2020 00:52:43 +0200
>>
>>> This v6 series adds basic networking support support TI K3 AM654x/J721E SoC which
>>> have integrated Gigabit Ethernet MAC (Media Access Controller) into device MCU
>>> domain and named MCU_CPSW0 (CPSW2G NUSS).
>> ...
>>
>> Series applied, thank you.
>
> The build is now broken on net-next:
>
> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
> (phandle_references):
> /interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
> Reference to non-existent node
> or label "mcu_conf"
>
> also defined at
> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
> (phandle_references):
> /interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
> Reference to non-existent node
> or label "phy_gmii_sel"
>
> also defined at
> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
>
> As Grygorii said:
>
> Patches 1-6 are intended for netdev, Patches 7-11 are intended for K3 Platform
> tree and provided here for testing purposes.
Yeah, I think you are missing a dependency that was applied via the K3
branch earlier. They are in linux-next now, but I am not so sure how
much that is going to help you.
You could just drop the DT patches from this merge and let me apply them
via the platform branch.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 30/03/20 12:45 PM, Tero Kristo wrote:
> On 28/03/2020 03:53, Vladimir Oltean wrote:
>> Hi David,
>>
>> On Fri, 27 Mar 2020 at 05:02, David Miller <[email protected]> wrote:
>>>
>>> From: Grygorii Strashko <[email protected]>
>>> Date: Tue, 24 Mar 2020 00:52:43 +0200
>>>
>>>> This v6 series adds basic networking support support TI K3
>>>> AM654x/J721E SoC which
>>>> have integrated Gigabit Ethernet MAC (Media Access Controller) into
>>>> device MCU
>>>> domain and named MCU_CPSW0 (CPSW2G NUSS).
>>> ...
>>>
>>> Series applied, thank you.
>>
>> The build is now broken on net-next:
>>
>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
>> (phandle_references):
>> /interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
>>
>> Reference to non-existent node
>> or label "mcu_conf"
>>
>> also defined at
>> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
>> (phandle_references):
>> /interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
>>
>> Reference to non-existent node
>> or label "phy_gmii_sel"
>>
>> also defined at
>> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
>>
>> As Grygorii said:
>>
>> Patches 1-6 are intended for netdev, Patches 7-11 are intended for K3
>> Platform
>> tree and provided here for testing purposes.
>
> Yeah, I think you are missing a dependency that was applied via the K3
> branch earlier. They are in linux-next now, but I am not so sure how
> much that is going to help you.
>
> You could just drop the DT patches from this merge and let me apply them
> via the platform branch.
One other option would be that Dave merges your K3 tag which was sent to
ARM SoC to net-next. Its based on v5.6-rc1, has no other dependencies,
is already in linux-next, should be immutable and safe to merge. This
has the advantage that no rebase is necessary on net-next.
git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux
tags/ti-k3-soc-for-v5.7
+ ARM SoC maintainers for their information and any advise.
Thanks,
Sekhar
On 30/03/20 1:06 PM, Sekhar Nori wrote:
> On 30/03/20 12:45 PM, Tero Kristo wrote:
>> On 28/03/2020 03:53, Vladimir Oltean wrote:
>>> Hi David,
>>>
>>> On Fri, 27 Mar 2020 at 05:02, David Miller <[email protected]> wrote:
>>>>
>>>> From: Grygorii Strashko <[email protected]>
>>>> Date: Tue, 24 Mar 2020 00:52:43 +0200
>>>>
>>>>> This v6 series adds basic networking support support TI K3
>>>>> AM654x/J721E SoC which
>>>>> have integrated Gigabit Ethernet MAC (Media Access Controller) into
>>>>> device MCU
>>>>> domain and named MCU_CPSW0 (CPSW2G NUSS).
>>>> ...
>>>>
>>>> Series applied, thank you.
>>>
>>> The build is now broken on net-next:
>>>
>>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
>>> (phandle_references):
>>> /interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
>>>
>>> Reference to non-existent node
>>> or label "mcu_conf"
>>>
>>> also defined at
>>> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
>>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
>>> (phandle_references):
>>> /interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
>>>
>>> Reference to non-existent node
>>> or label "phy_gmii_sel"
>>>
>>> also defined at
>>> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
>>>
>>> As Grygorii said:
>>>
>>> Patches 1-6 are intended for netdev, Patches 7-11 are intended for K3
>>> Platform
>>> tree and provided here for testing purposes.
>>
>> Yeah, I think you are missing a dependency that was applied via the K3
>> branch earlier. They are in linux-next now, but I am not so sure how
>> much that is going to help you.
>>
>> You could just drop the DT patches from this merge and let me apply them
>> via the platform branch.
>
> One other option would be that Dave merges your K3 tag which was sent to
> ARM SoC to net-next. Its based on v5.6-rc1, has no other dependencies,
> is already in linux-next, should be immutable and safe to merge. This
> has the advantage that no rebase is necessary on net-next.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux
> tags/ti-k3-soc-for-v5.7
FWIW, I was able to reproduce the build failure reported by Vladimir on
net-next, merge Tero's tag (above) cleanly into it, and see that ARM64
defconfig build on net-next succeeds after the merge.
Thanks,
Sekhar
Hi
On 30/03/2020 11:28, Sekhar Nori wrote:
> On 30/03/20 1:06 PM, Sekhar Nori wrote:
>> On 30/03/20 12:45 PM, Tero Kristo wrote:
>>> On 28/03/2020 03:53, Vladimir Oltean wrote:
>>>> Hi David,
>>>>
>>>> On Fri, 27 Mar 2020 at 05:02, David Miller <[email protected]> wrote:
>>>>>
>>>>> From: Grygorii Strashko <[email protected]>
>>>>> Date: Tue, 24 Mar 2020 00:52:43 +0200
>>>>>
>>>>>> This v6 series adds basic networking support support TI K3
>>>>>> AM654x/J721E SoC which
>>>>>> have integrated Gigabit Ethernet MAC (Media Access Controller) into
>>>>>> device MCU
>>>>>> domain and named MCU_CPSW0 (CPSW2G NUSS).
>>>>> ...
>>>>>
>>>>> Series applied, thank you.
>>>>
>>>> The build is now broken on net-next:
>>>>
>>>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
>>>> (phandle_references):
>>>> /interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
>>>>
>>>> Reference to non-existent node
>>>> or label "mcu_conf"
>>>>
>>>> also defined at
>>>> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
>>>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
>>>> (phandle_references):
>>>> /interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
>>>>
>>>> Reference to non-existent node
>>>> or label "phy_gmii_sel"
>>>>
>>>> also defined at
>>>> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
>>>>
>>>> As Grygorii said:
>>>>
>>>> Patches 1-6 are intended for netdev, Patches 7-11 are intended for K3
>>>> Platform
>>>> tree and provided here for testing purposes.
>>>
>>> Yeah, I think you are missing a dependency that was applied via the K3
>>> branch earlier. They are in linux-next now, but I am not so sure how
>>> much that is going to help you.
>>>
>>> You could just drop the DT patches from this merge and let me apply them
>>> via the platform branch.
>>
>> One other option would be that Dave merges your K3 tag which was sent to
>> ARM SoC to net-next. Its based on v5.6-rc1, has no other dependencies,
>> is already in linux-next, should be immutable and safe to merge. This
>> has the advantage that no rebase is necessary on net-next.
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux
>> tags/ti-k3-soc-for-v5.7
>
> FWIW, I was able to reproduce the build failure reported by Vladimir on
> net-next, merge Tero's tag (above) cleanly into it, and see that ARM64
> defconfig build on net-next succeeds after the merge.
Thank you Sekhar for checking this.
I'm very sorry for introducing this issue. I've tried hard to avoid such issue,
but still missed it (probably I have had to drop DT patches from last submission
and send them separately).
Sorry again.
--
Best regards,
grygorii
Hi David,
On Mon, 30 Mar 2020 at 21:14, Grygorii Strashko
<[email protected]> wrote:
>
> Hi
>
> On 30/03/2020 11:28, Sekhar Nori wrote:
> > On 30/03/20 1:06 PM, Sekhar Nori wrote:
> >> On 30/03/20 12:45 PM, Tero Kristo wrote:
> >>> On 28/03/2020 03:53, Vladimir Oltean wrote:
> >>>> Hi David,
> >>>>
> >>>> On Fri, 27 Mar 2020 at 05:02, David Miller <[email protected]> wrote:
> >>>>>
> >>>>> From: Grygorii Strashko <[email protected]>
> >>>>> Date: Tue, 24 Mar 2020 00:52:43 +0200
> >>>>>
> >>>>>> This v6 series adds basic networking support support TI K3
> >>>>>> AM654x/J721E SoC which
> >>>>>> have integrated Gigabit Ethernet MAC (Media Access Controller) into
> >>>>>> device MCU
> >>>>>> domain and named MCU_CPSW0 (CPSW2G NUSS).
> >>>>> ...
> >>>>>
> >>>>> Series applied, thank you.
> >>>>
> >>>> The build is now broken on net-next:
> >>>>
> >>>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
> >>>> (phandle_references):
> >>>> /interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
> >>>>
> >>>> Reference to non-existent node
> >>>> or label "mcu_conf"
> >>>>
> >>>> also defined at
> >>>> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
> >>>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:303.23-309.6: ERROR
> >>>> (phandle_references):
> >>>> /interconnect@100000/interconnect@28380000/ethernet@46000000/ethernet-ports/port@1:
> >>>>
> >>>> Reference to non-existent node
> >>>> or label "phy_gmii_sel"
> >>>>
> >>>> also defined at
> >>>> arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts:471.13-474.3
> >>>>
> >>>> As Grygorii said:
> >>>>
> >>>> Patches 1-6 are intended for netdev, Patches 7-11 are intended for K3
> >>>> Platform
> >>>> tree and provided here for testing purposes.
> >>>
> >>> Yeah, I think you are missing a dependency that was applied via the K3
> >>> branch earlier. They are in linux-next now, but I am not so sure how
> >>> much that is going to help you.
> >>>
> >>> You could just drop the DT patches from this merge and let me apply them
> >>> via the platform branch.
> >>
> >> One other option would be that Dave merges your K3 tag which was sent to
> >> ARM SoC to net-next. Its based on v5.6-rc1, has no other dependencies,
> >> is already in linux-next, should be immutable and safe to merge. This
> >> has the advantage that no rebase is necessary on net-next.
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux
> >> tags/ti-k3-soc-for-v5.7
> >
> > FWIW, I was able to reproduce the build failure reported by Vladimir on
> > net-next, merge Tero's tag (above) cleanly into it, and see that ARM64
> > defconfig build on net-next succeeds after the merge.
>
> Thank you Sekhar for checking this.
>
> I'm very sorry for introducing this issue. I've tried hard to avoid such issue,
> but still missed it (probably I have had to drop DT patches from last submission
> and send them separately).
>
> Sorry again.
>
> --
> Best regards,
> grygorii
I think the ARM64 build is now also broken on Linus' master branch,
after the net-next merge? I am not quite sure if the device tree
patches were supposed to land in mainline the way they did.
Thanks,
-Vladimir
From: Vladimir Oltean <[email protected]>
Date: Wed, 1 Apr 2020 21:27:04 +0300
> I think the ARM64 build is now also broken on Linus' master branch,
> after the net-next merge? I am not quite sure if the device tree
> patches were supposed to land in mainline the way they did.
There's a fix in my net tree and it will go to Linus soon.
There is no clear policy for dt change integration, and honestly
I try to deal with the situation on a case by case basis.
>> I think the ARM64 build is now also broken on Linus' master branch,
>> after the net-next merge? I am not quite sure if the device tree
>> patches were supposed to land in mainline the way they did.
>
>There's a fix in my net tree and it will go to Linus soon.
>
>There is no clear policy for dt change integration, and honestly
>I try to deal with the situation on a case by case basis.
Yep, mainline aarch64-linux-gnu- builds are totally hosed. DTC fails the build
very early on:
https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/311246218
https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/311246270
There was no failure in -next, not sure how we skipped our canary in the coal
mine.
On Wed, Apr 01, 2020 at 03:35:00PM -0700, Nick Desaulniers wrote:
> >> I think the ARM64 build is now also broken on Linus' master branch,
> >> after the net-next merge? I am not quite sure if the device tree
> >> patches were supposed to land in mainline the way they did.
> >
> >There's a fix in my net tree and it will go to Linus soon.
> >
> >There is no clear policy for dt change integration, and honestly
> >I try to deal with the situation on a case by case basis.
>
> Yep, mainline aarch64-linux-gnu- builds are totally hosed. DTC fails the build
> very early on:
> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/311246218
> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/311246270
> There was no failure in -next, not sure how we skipped our canary in the coal
> mine.
Yes, one of the things linux-next does a really good job at catching is
build breakage so it would've been nice to have seen this there rather
than end up with breakage in Linus' tree :(
Was the timing just bad, or are we missing DT coverage or something else?
Will
On 02/04/2020 12:42, Will Deacon wrote:
> On Wed, Apr 01, 2020 at 03:35:00PM -0700, Nick Desaulniers wrote:
>>>> I think the ARM64 build is now also broken on Linus' master branch,
>>>> after the net-next merge? I am not quite sure if the device tree
>>>> patches were supposed to land in mainline the way they did.
>>>
>>> There's a fix in my net tree and it will go to Linus soon.
>>>
>>> There is no clear policy for dt change integration, and honestly
>>> I try to deal with the situation on a case by case basis.
>>
>> Yep, mainline aarch64-linux-gnu- builds are totally hosed. DTC fails the build
>> very early on:
>> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/311246218
>> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/311246270
>> There was no failure in -next, not sure how we skipped our canary in the coal
>> mine.
>
> Yes, one of the things linux-next does a really good job at catching is
> build breakage so it would've been nice to have seen this there rather
> than end up with breakage in Linus' tree :(
>
> Was the timing just bad, or are we missing DT coverage or something else?
It seems issue was not caught in -next because the patch that fixes the issue was already in -next
before this series was pushed.
Sorry for the mess again.
--
Best regards,
grygorii
On Thu, Apr 2, 2020 at 4:05 AM Grygorii Strashko
<[email protected]> wrote:
>
>
>
> On 02/04/2020 12:42, Will Deacon wrote:
> > On Wed, Apr 01, 2020 at 03:35:00PM -0700, Nick Desaulniers wrote:
> >>>> I think the ARM64 build is now also broken on Linus' master branch,
> >>>> after the net-next merge? I am not quite sure if the device tree
> >>>> patches were supposed to land in mainline the way they did.
> >>>
> >>> There's a fix in my net tree and it will go to Linus soon.
> >>>
> >>> There is no clear policy for dt change integration, and honestly
> >>> I try to deal with the situation on a case by case basis.
> >>
> >> Yep, mainline aarch64-linux-gnu- builds are totally hosed. DTC fails the build
> >> very early on:
> >> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/311246218
> >> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/311246270
> >> There was no failure in -next, not sure how we skipped our canary in the coal
> >> mine.
> >
> > Yes, one of the things linux-next does a really good job at catching is
> > build breakage so it would've been nice to have seen this there rather
> > than end up with breakage in Linus' tree :(
> >
> > Was the timing just bad, or are we missing DT coverage or something else?
>
> It seems issue was not caught in -next because the patch that fixes the issue was already in -next
> before this series was pushed.
>
> Sorry for the mess again.
No worries, it's just worthwhile to study failures. So IIUC, in this case:
mainline was 5.6
the broken patch was merged in 5.7 merge window
a fix was already in -next, but not slated for the new merge window.
(Maybe scheduled for 5.8?)
So it sounds like it can be dangerous to have 2 branches from 1 tree
flow into -next, as the branch meant for a later release can mask
failures in pull requests for the earlier release?
Do we know what and where the fix currently is?
Can we make sure it's sent to Linus for 5.7-rc1? (Or sooner?)
--
Thanks,
~Nick Desaulniers
On 02/04/20 10:57 PM, Nick Desaulniers wrote:
> On Thu, Apr 2, 2020 at 4:05 AM Grygorii Strashko
> <[email protected]> wrote:
>>
>>
>>
>> On 02/04/2020 12:42, Will Deacon wrote:
>>> On Wed, Apr 01, 2020 at 03:35:00PM -0700, Nick Desaulniers wrote:
>>>>>> I think the ARM64 build is now also broken on Linus' master branch,
>>>>>> after the net-next merge? I am not quite sure if the device tree
>>>>>> patches were supposed to land in mainline the way they did.
>>>>>
>>>>> There's a fix in my net tree and it will go to Linus soon.
>>>>>
>>>>> There is no clear policy for dt change integration, and honestly
>>>>> I try to deal with the situation on a case by case basis.
>>>>
>>>> Yep, mainline aarch64-linux-gnu- builds are totally hosed. DTC fails the build
>>>> very early on:
>>>> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/311246218
>>>> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/311246270
>>>> There was no failure in -next, not sure how we skipped our canary in the coal
>>>> mine.
>>>
>>> Yes, one of the things linux-next does a really good job at catching is
>>> build breakage so it would've been nice to have seen this there rather
>>> than end up with breakage in Linus' tree :(
>>>
>>> Was the timing just bad, or are we missing DT coverage or something else?
>>
>> It seems issue was not caught in -next because the patch that fixes the issue was already in -next
>> before this series was pushed.
>>
>> Sorry for the mess again.
>
> No worries, it's just worthwhile to study failures. So IIUC, in this case:
> mainline was 5.6
> the broken patch was merged in 5.7 merge window
> a fix was already in -next, but not slated for the new merge window.
> (Maybe scheduled for 5.8?)
No, the "fix" is scheduled to go into v5.7 kernel as well. It is here:
git://git.kernel.org/pub/scm/linux/kernel/git/kristo/linux tags/ti-k3-soc-for-v5.7
This is already part of ARM SoC tree, and slated for v5.7
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=arm/dt
Arnd, Olof,
Can you please help by either queuing the arm/dt entirely or just the K3 SoC
parts to Linus sooner than later?
Thanks,
Sekhar