Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Vladimir Oltean <vladimir.oltean@nxp.com>
To:     Marc Zyngier <maz@kernel.org>
CC:     "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        Rob Herring <robh+dt@kernel.org>,
        Shawn Guo <shawnguo@kernel.org>, Leo Li <leoyang.li@nxp.com>,
        Biwen Li <biwen.li@nxp.com>, "Z.Q. Hou" <zhiqiang.hou@nxp.com>,
        Kurt Kanzenbach <kurt@linutronix.de>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: [RFC PATCH devicetree 00/10] Do something about ls-extirq
 interrupt-map breakage
Thread-Topic: [RFC PATCH devicetree 00/10] Do something about ls-extirq
 interrupt-map breakage
Thread-Index: AQHX8ItO3xtQxxPJV0yONti9mp5846wxrpCAgAASv4CAAAYSAICdm7aA
Date:   Thu, 24 Mar 2022 17:10:42 +0000
Message-ID: <20220324171041.t5yoocinj6gizcc7@skbuf>
References: <20211214013800.2703568-1-vladimir.oltean@nxp.com>
 <87ilvrk1r0.wl-maz@kernel.org> <20211214095853.4emzycaxkuqr4tun@skbuf>
 <87czlzjxmz.wl-maz@kernel.org>
In-Reply-To: <87czlzjxmz.wl-maz@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?m2ENI57NJVNnVxGVY72BqCITUSc+uzZ73PF2DVKGVu+1vq61uvBG9uZ+Y32b?=
 =?us-ascii?Q?T0NZM1kM/LucsRu1QvA5INu/BOkYV/jw4HmdfGPsClOBgzxeDmG1hTSLCGJH?=
 =?us-ascii?Q?IisDDq5bAunOqOBMsqbQnHdzHx2yv1s5tNRCaW/Y4fnVryQ0dCtESQ/LtXrn?=
 =?us-ascii?Q?I+UPDoeW8AnbM7GRNaQ0d1zhqeLQ+lxJ8xtPg/pgVm61LloAi6fu0ZkoG0pj?=
 =?us-ascii?Q?8HKSa879TXGxB12dROj3Iwv0qSEp+yxVleWax3rNlWuaCi5Ojp3cHPGhwLsX?=
 =?us-ascii?Q?UE/GEf94I5HXJsBbArNxvEMHnnevpKi0dC+AQlUn53yNwlY/CUBPx1EG/rcC?=
 =?us-ascii?Q?G0BTQDJ0qqglAVNCBorMwOiz+Manf7LJicwsUOIXp8UcF7ZfG01KAhFePNdX?=
 =?us-ascii?Q?Zi+92lKkHaEkMo21Fr2PkKPTHDV1RAYZF6I+9KfwvmExj/2g78oIibZ5wlzq?=
 =?us-ascii?Q?zWaMptLEAlMVxtM/qGiO+ptynmzWTUM97mnjp4R9m/ZdgbnkH550gnNxbeHk?=
 =?us-ascii?Q?PrbVaH099rwxJi/GP9bO3xijpnKN0yWXJJOK7KikBeQ0a39gJD5P8YsmHXLp?=
 =?us-ascii?Q?Vkn04y5H76NA7NFZCxMdeQhI5XNofqOEvGOCaxZr4ZbL7YGblLJe/al593yF?=
 =?us-ascii?Q?yro3otc/ZTnOO1hwz4943wV3vaUAX/JFExvg00rJ0UKtgLgyHb0oRgyylNNH?=
 =?us-ascii?Q?DmtES9/JcI8osdp9LxVqZx9PUw3RKxkzIRPdYreO6Dsh8hq3shK7CKWQ4v3f?=
 =?us-ascii?Q?gcyKBhKpity2xM+sfNb7Fu9kQyp2sHIZZMN0NFTWR23xDayE0z9C5AFuk1r1?=
 =?us-ascii?Q?gdIE4oqNn4WiGVnH+rAmEs6slvCNe4RygPShh3SdQoh7ZKzjTXF1fjWb/UYb?=
 =?us-ascii?Q?lfQtCGs4DKbBMznoBoA1qvu2ZmZLSAcS+NaamiLTm/TVuDJC0IFjNsN1O8+C?=
 =?us-ascii?Q?Jgo+CQmWH7FxD6An7mjXhZhGFPgw4ls9cYWy/UuAHoTl2x3RB7A6OCVK13Lq?=
 =?us-ascii?Q?rmZuiZfbv1KLlnFaDdpLbPj5gk6HhqdCyjwNkEGymuiRNsL7x02yGlyCOsE9?=
 =?us-ascii?Q?y+bWhvx0d+PeWBQVtkKddxREdWSHDlNuIBo5DTaMR9SgiJTHHA8Ion3ZKjhL?=
 =?us-ascii?Q?PrRzTWXnl8ejGv5w5/LPLSft25vLgqv+bl+FnI+1/BbKVCMiP2tBHp2cCfzt?=
 =?us-ascii?Q?qvKO0sR7vV9+8JYLZltL2QPdlnPr4pjNxcdr3Jc4XkW9QSxGuYoIue7xTXPK?=
 =?us-ascii?Q?BpjYhMDa8ulupKjiEuisy39b++r8B8C/CET7Q7o8kDjm/qzrSTLGHWqAHD9x?=
 =?us-ascii?Q?IFK73WUS/AOXkWJYWjvACtUuFCFok/pCfsXNixIyfjmST7v8nikG84TQ8S70?=
 =?us-ascii?Q?QT4d1medeo6pLqDOvNKsV+JN5Cml2AvygjRib2yQv20rjhlR6f79TatOzPfB?=
 =?us-ascii?Q?6OQWD+uk6dBfK4GTG8X/aGW/WGGqIkWDxETlQ3zDHpBRgX6pZ7IAbS1ZBfg6?=
 =?us-ascii?Q?kQPUV4ZsOsr2KC1hz79WFGtnm6KhdXCtX/Dgp8osnT4q5jIQG56e2qwTXef6?=
 =?us-ascii?Q?Ost90ZTCEJQyJmy87p7S6BEF/JyoToAs+QQRs0VJrVh5k600cdkJrZxECWle?=
 =?us-ascii?Q?iBGJ8W7uuMrfeNiT7Ud9xkL6s5YVJE7CoGUlQOeDLkma80Ny4OmjRHVfTDwk?=
 =?us-ascii?Q?MmMvJLdA5qRB0TL8KqoFSs4OV7OgCvvxNVacFIIdkB/JM1UphOk94T0P15dX?=
 =?us-ascii?Q?5H31KCDtCP1VAGxWFUjUB3wwsOOnh58=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6DBB7331E2362343BAA66A3CE2CCC873@eurprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR04MB5121.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 70e93d56-a54c-4be9-5847-08da0db93a5c
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2022 17:10:42.4806
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: M6Lcui9FPuRH2KCENrejI/RdKp3lfY6FFaA5/R2/lwPSbPa94LbcZ0nvrEBwftM5X9l7NoGHm0w+ua4zplOWBw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAXPR04MB8943
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hello Marc,

On Tue, Dec 14, 2021 at 10:20:36AM +0000, Marc Zyngier wrote:
> On Tue, 14 Dec 2021 09:58:54 +0000,
> Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> >=20
> > Hi Marc (with a c),
> >=20
> > I wish the firmware for these SoCs was smart enough to be compatible
> > with the bindings that are in the kernel and provide a blob that the
> > kernel could actually use. Some work has been started there and this is
> > work in progress. True, I don't know what other OF-based firmware some
> > other customers may use, but I trust it isn't a lot more advanced than
> > what U-Boot currently has :)
> >=20
> > Also, the machines may have been in the wild for years, but the
> > ls-extirq driver was added in November 2019. So not with the
> > introduction of the SoC device trees themselves. That isn't so long ago=
.
> >=20
> > As for compatibility between old kernel and new DT: I guess you'll hear
> > various opinions on this one.
> > https://www.spinics.net/lists/linux-mips/msg07778.html
> >=20
> > | > Are we okay with the new device tree blobs breaking the old kernel?
> > |
> > | From my point of view, newer device trees are not required to work on
> > | older kernel, this would impose an unreasonable limitation and the us=
e
> > | case is very limited.
>=20
> My views are on the opposite side. DT is an ABI, full stop. If you
> change something, you *must* guarantee forward *and* backward
> compatibility. That's because:
>=20
> - you don't control how updatable the firmware is
>=20
> - people may need to revert to other versions of the kernel because
>   the new one is broken
>=20
> - there are plenty of DT users beyond Linux, and we are not creating
>   bindings for Linux only.
>=20
> You may disagree with this, but for the subsystems I maintain, this is
> the rule I intent to stick to.
>=20
> 	M.
>=20
> --=20
> Without deviation from the norm, progress is not possible.

I was just debugging an interesting issue with an old kernel not working
with a new DT blob, and after figuring out what the problem was (is),
I remembered this message and I'm curious what you have to say about it.

I have this DT layout:

	ethernet-phy@1 {
		reg =3D <0x1>;
		interrupts-extended =3D <&extirq 2 IRQ_TYPE_LEVEL_LOW>;
	};

	extirq: interrupt-controller@1ac {
		compatible =3D "fsl,ls1021a-extirq";
		<bla bla>
	};

I booted the new DT blob (which has "interrupts-extended") on a kernel
where the ls-extirq driver did not exist. This had the result of
of_mdiobus_phy_device_register() -> of_irq_get() returning -EPROBE_DEFER
forever and ever. So the PHY driver in turn never probed, and Ethernet
was broken. So I had to delete the interrupts OF property to let the PHY
at least work in poll mode.

What went wrong here in your opinion?=