linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonas Jelonek <jelonek.jonas@gmail.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: linux-i2c@vger.kernel.org,
	Chris Packham <chris.packham@alliedtelesis.co.nz>,
	Andi Shyti <andi.shyti@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	Markus Stockhausen <markus.stockhausen@gmx.de>
Subject: Re: [PATCH v2 2/3] dt-bindings: i2c: realtek,rtl9301-i2c: extend for RTL9310 support
Date: Wed, 23 Jul 2025 09:49:18 +0200	[thread overview]
Message-ID: <e5d4e059-1274-46fe-8719-139f388fd975@gmail.com> (raw)
In-Reply-To: <3515f1dd-bed2-4f54-97fb-194850440e14@kernel.org>

Hi Kryzysztof,

On 23.07.2025 08:22, Krzysztof Kozlowski wrote:
> On 22/07/2025 20:25, Jonas Jelonek wrote:
>>>> Since you have a lot of expertise on that and I obviously fail to find
>>>> documentation that helps me to do that properly, could you give me some hints
>>>> on how that has to look? I'd really appreciate this.
>>> So in your if:then: block where you narrow mst-id, you add on same level
>>> as properties:
>>>
>>> patternProperties:
>>>   YOUR_REGEX: false
>> How I thought of narrowing that in the first place was to make mst-id required
>> for RTL9310 but optional for RTL9300. In terms of describing the hardware, this
>> is valid for RTL9300 too (but there's no need for the driver or anything else to
>> know that).
>>
>> But I don't mind if you'd rather have it only defined in the 'then' block, or
>> just disallowed for RTL9300, effectively forbidding the usage for RTL9300.
>>
>> Either way, it seems I'm still doing it wrong with the regex. Adding as you
>> suggested:
>>
>> if:
>>     properties:
>>         compatible:
>>             contains:
>>                 const: realtek,rtl9301-i2c
>> then:
>>     patternProperties:
>>         '^i2c@([0-9]|1[0-1])$': false
>>
>> breaks validation of the RTL9300 example. Probably I don't see how this
>> is expected to look like in a working state.
> RTL9300 has 8 controllers, so why are you disallowing them? We talk here
> only about new stuff. Why would you change EXISTING behavior when adding
> something new?
>
> You need pattern matching redundant children for existing device.
>

It wasn't my intention to disallow that, but I'm struggling with these specifics
of the dt-bindings to accomplish what is requested. Anyway, I think your comment
gave me a good hint to solve that now.

if:
    properties:
        compatible:
            contains:
                const: realtek,rtl9301-i2c
then:
    patternProperties:
        '^i2c@([8-9]|1[0-1])$': false

This seems to do the trick, dt_binding_check is fine with this. Is this how you
intended it to look like?


Talking about 'not changing existing behaviour', is it fine to allow the mst-id
property for the existing RTL9300 too or should that really only be allowed for
what I add here now?

> Best regards,
> Krzysztof

Best regards,
Jonas Jelonek

  reply	other threads:[~2025-07-23  7:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-12 19:42 [PATCH v2 0/3] i2c: rework and extend RTL9300 I2C driver Jonas Jelonek
2025-07-12 19:42 ` [PATCH v2 1/3] i2c: rework RTL9300 I2C controller driver Jonas Jelonek
2025-07-12 19:42 ` [PATCH v2 2/3] dt-bindings: i2c: realtek,rtl9301-i2c: extend for RTL9310 support Jonas Jelonek
2025-07-12 21:22   ` Rob Herring (Arm)
2025-07-14  6:00   ` Krzysztof Kozlowski
2025-07-20 19:51     ` Jonas Jelonek
2025-07-21  7:02       ` Krzysztof Kozlowski
2025-07-22 18:25         ` Jonas Jelonek
2025-07-23  6:22           ` Krzysztof Kozlowski
2025-07-23  7:49             ` Jonas Jelonek [this message]
2025-07-12 19:42 ` [PATCH v2 3/3] i2c: add RTL9310 support to RTL9300 I2C controller driver Jonas Jelonek

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=e5d4e059-1274-46fe-8719-139f388fd975@gmail.com \
    --to=jelonek.jonas@gmail.com \
    --cc=andi.shyti@kernel.org \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.stockhausen@gmx.de \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).