From: Krzysztof Kozlowski <krzk@kernel•org>
To: Frank Li <Frank.li@nxp•com>
Cc: "Chancel Liu (OSS)" <chancel.liu@oss•nxp.com>,
Chancel Liu <chancel.liu@nxp•com>,
"robh@kernel•org" <robh@kernel•org>,
"krzk+dt@kernel•org" <krzk+dt@kernel•org>,
"conor+dt@kernel•org" <conor+dt@kernel•org>,
"s.hauer@pengutronix•de" <s.hauer@pengutronix•de>,
"festevam@gmail•com" <festevam@gmail•com>,
"mturquette@baylibre•com" <mturquette@baylibre•com>,
"sboyd@kernel•org" <sboyd@kernel•org>,
"kernel@pengutronix•de" <kernel@pengutronix•de>,
"devicetree@vger•kernel.org" <devicetree@vger•kernel.org>,
"linux-kernel@vger•kernel.org" <linux-kernel@vger•kernel.org>,
"imx@lists•linux.dev" <imx@lists•linux.dev>,
"linux-arm-kernel@lists•infradead.org"
<linux-arm-kernel@lists•infradead.org>,
"linux-clk@vger•kernel.org" <linux-clk@vger•kernel.org>
Subject: Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
Date: Sun, 24 May 2026 20:20:52 +0200 [thread overview]
Message-ID: <74eb56fb-546d-4b2c-9bbc-01a40937f5d3@kernel.org> (raw)
In-Reply-To: <ag3GMdmxw60B15Oe@lizhi-Precision-Tower-5810>
On 20/05/2026 16:33, Frank Li wrote:
> On Wed, May 20, 2026 at 09:08:42AM +0200, Krzysztof Kozlowski wrote:
>> On 20/05/2026 07:02, Chancel Liu (OSS) wrote:
>>>>>>>>> +description:
>>>>>>>>> + The NXP I/O connector represents a physically present I/O
>>>>>>>>> +connector on the
>>>>>>>>> + base board. It acts as a nexus that exposes a constrained set
>>>> of
>>>>>>>>> +I/O
>>>>>>>>> + resources, such as GPIOs, clocks, PWMs and interrupts, through
>>>>>>>>> +fixed
>>>>>>>>> + electrical wiring. All actual hardware providers reside on the
>>>> base
>>>>>> board.
>>>>>>>>> + The connector node only defines index-based mappings to those
>>>>>>>> providers.
>>>>>>>>> +
>>>>>>>>> +properties:
>>>>>>>>> + compatible:
>>>>>>>>> + const: fsl,io-connector
>>>>>>>>
>>>>>>>> Everything is IO. Everything is connector, so your compatible does
>>>>>>>> not match requirements from writing bindings.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, this compatible is too generic. I will rename the compatible to
>>>>>>> fsl,aud-io-connector.
>>>>>>
>>>>>> aud is not much better. Which boards have it? What's the pinout?
>>>> What's
>>>>>> standard? Is it described anywhere? If so, provide reference to
>>>> spec/docs.
>>>>>>
>>>>>
>>>>> This is not an industry standard electrical interface. This connector
>>>>
>>>> Then if you do not have standard, then you have board specific layouts
>>>> thus you need board-specific compatibles. You can use fallbacks. Generic
>>>> fallback could work, but both io-connector and aud-io-connector are just
>>>> too generic. Every connector is "connector" and "io", thus absolutely
>>>> anything can be "io-connector". "aud" improves it only a bit, thus
>>>> honestly I would go with board specific fallback as well.
>>>>
>>>
>>> How about board specific + common fallback compatible like this:
>>> compatible:
>>> items:
>>> - enum:
>>> - fsl,imx95-19x19-evk-aud-io-connector
>>> - fsl,imx952-evk-aud-io-connector
>>> - const: fsl,imx-aud-io-connector
>>> Since the daughter board is named “IMX-AUD-IO” in publicly available
>>
>> I don't think it is named like that.
>>
>> git grep -i imx-aud-io
>>
>>> documentation, common compatible clearly indicates that this connector
>>> is intended for that.
>>>
>>> Also, I want to talk about the topic of generic connector. It's a common
>>> design that daughter board is connected to base board through a
>>> connector. This connector more often acts as a nexus that exposes a
>>> constrained subset of GPIO, clock, PWM and interrupt resources to the
>>> daughter board. Can we document this kind of connector as a generic
>>> binding?
>>
>> So this binding is the connector between carrier and some addon? Then
>> you don't get a compatible for that at all, because it is not necessary,
>> not useful and NEVER used. Do you see socket LGA "connector" bindings? No.
>
> Not exactly. Any connector connects a carrier board with an add-on board.
> The key point here is that this connector type is reused across different
> boards, even though it is not an industry-standard connector. Both the
> signal definitions and the mechanical layout are defined.
>
> The same add-on boards can therefore be reused across different base boards
> that use this type of connector.
>
> There are also GPIO mappings involved. For example, pin 1 on the connector
> may represent reset-gpios, but it could be connected to GPIO0 on board A
> and GPIO1 on board B.
>
> Without a connector definition layer, this would create an N × M
> combination problem. The Nexus node discussion already covered this topic:
> https://osseu2025.sched.com/event/25Vrw
>
> An LGA socket is a CPU socket, where the signals are completely transparent
> to software, so it is not a good comparison. A PCIe M.2 Key-M/E connector
> would be a more appropriate comparison.
>
So the terminology of daughter and carrier boards was confusing. If this
is a hat, mezzanine or other addon, it's fine.
I still insist on board specific compatibles - fallback and specific.
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-05-24 18:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-09 2:48 [PATCH 0/5] arm64: dts: freescale: Add IMX-AUD-IO daughter board support Chancel Liu
2026-05-09 2:48 ` [PATCH 1/5] clk: Add support for clock nexus dt bindings Chancel Liu
2026-05-13 3:19 ` Chancel Liu
2026-05-09 2:48 ` [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding Chancel Liu
2026-05-15 7:19 ` Krzysztof Kozlowski
2026-05-18 4:18 ` Chancel Liu
2026-05-18 7:07 ` Krzysztof Kozlowski
2026-05-19 2:56 ` Chancel Liu
2026-05-19 8:29 ` Krzysztof Kozlowski
2026-05-20 5:02 ` Chancel Liu (OSS)
2026-05-20 7:08 ` Krzysztof Kozlowski
2026-05-20 14:33 ` Frank Li
2026-05-24 18:20 ` Krzysztof Kozlowski [this message]
2026-05-25 6:26 ` Chancel Liu (OSS)
2026-05-25 12:28 ` Krzysztof Kozlowski
2026-06-02 22:18 ` Frank Li
2026-06-05 9:11 ` Krzysztof Kozlowski
2026-05-09 2:48 ` [PATCH 3/5] arm64: dts: freescale: imx95-19x19-evk: Add IMX-AUD-IO board support Chancel Liu
2026-05-09 2:48 ` [PATCH 4/5] arm64: dts: freescale: imx952-evk: " Chancel Liu
2026-05-11 8:20 ` Bough Chen
2026-05-13 5:50 ` Chancel Liu
2026-05-09 2:48 ` [PATCH 5/5] arm64: dts: freescale: Add common DTS overlay for IMX-AUD-IO daughter board Chancel Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=74eb56fb-546d-4b2c-9bbc-01a40937f5d3@kernel.org \
--to=krzk@kernel$(echo .)org \
--cc=Frank.li@nxp$(echo .)com \
--cc=chancel.liu@nxp$(echo .)com \
--cc=chancel.liu@oss$(echo .)nxp.com \
--cc=conor+dt@kernel$(echo .)org \
--cc=devicetree@vger$(echo .)kernel.org \
--cc=festevam@gmail$(echo .)com \
--cc=imx@lists$(echo .)linux.dev \
--cc=kernel@pengutronix$(echo .)de \
--cc=krzk+dt@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-clk@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=mturquette@baylibre$(echo .)com \
--cc=robh@kernel$(echo .)org \
--cc=s.hauer@pengutronix$(echo .)de \
--cc=sboyd@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox