[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <d5f29c86-4bd8-4550-971e-4e941b1099f2@app.fastmail.com>
Date: Tue, 08 Nov 2022 12:07:33 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jesse Taube" <mr.bossman075@...il.com>,
"NXP Linux Team" <linux-imx@....com>
Cc: "Rob Herring" <robh+dt@...nel.org>,
"Stephen Boyd" <sboyd@...nel.org>,
"Shawn Guo" <shawnguo@...nel.org>,
"Pengutronix Kernel Team" <kernel@...gutronix.de>,
"Fabio Estevam" <festevam@...il.com>, aisheng.dong@....com,
stefan@...er.ch, "Linus Walleij" <linus.walleij@...aro.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"Russell King" <linux@...linux.org.uk>, abel.vesa@....com,
dev@...xeye.de, "Marcel Ziswiler" <marcel.ziswiler@...adex.com>,
tharvey@...eworks.com, leoyang.li@....com, fugang.duan@....com,
"Giulio Benetti" <giulio.benetti@...ettiengineering.com>,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
linux-serial@...r.kernel.org
Subject: Re: [PATCH v1 7/7] ARM: dts: imx: Update i.MXRT1050.dtsi compatibles
On Mon, Nov 7, 2022, at 16:09, Jesse Taube wrote:
> On 11/7/22 02:44, Arnd Bergmann wrote:
>> On Mon, Nov 7, 2022, at 08:15, Jesse Taube wrote:
>>> Remove unused compatibles from i.MXRT1050.dtsi.
>>> Change GPT clock-names to match documentation.
>>>
>>> Cc: Giulio Benetti <giulio.benetti@...ettiengineering.com>
>>> Signed-off-by: Jesse Taube <Mr.Bossman075@...il.com>
>>
>> Can you make sure your changelog texts explain why you do this?
> Yes, sorry I wasn't clear.
>
>> Are they fundamentally different from the devices you had
>> claimed to be compatible with that need a different driver,
>
> UART and SDHC had drivers added which are better fit.
> The GPT binds to imx6dl which is also the same as imx6sl.
Where are those drivers added? Looking at linux-6.1-rc2
and linux-next, I still see them use the same drivers as
the original ones, and listing both strings would be the
preferred method.
>> or are there drivers in the field that bind to the wrong
>> string first?
> I don't understand?
I mean if you had run into the case where you have
a driver that misbehaves when the fallback string is
present in addition to the most specific one.
Arnd
Powered by blists - more mailing lists