public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Rustam Adilov <adilov@disroot.org>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: 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>,
	linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Jonas Jelonek <jelonek.jonas@gmail.com>
Subject: Re: [PATCH 7/8] dt-bindings: i2c: realtek,rtl9301-i2c: extend for RTL9607C support
Date: Sun, 15 Mar 2026 16:18:31 +0000	[thread overview]
Message-ID: <1e2119e91baf59936c0d42f047a1c733@disroot.org> (raw)
In-Reply-To: <764c3942-925d-47e9-99fb-cfd84daee0fe@kernel.org>

On 2026-03-15 10:15, Krzysztof Kozlowski wrote:
> On 15/03/2026 11:10, Rustam Adilov wrote:
>> Hello,
>> 
>> On 2026-03-15 08:56, Krzysztof Kozlowski wrote:
>>> On Sat, Mar 14, 2026 at 01:26:27PM +0500, Rustam Adilov wrote:
>>>> Add the "realtek,rtl9607-i2c" compatible for i2c controller on the
>>>> RTL9607C SoC series.
>>>>
>>>> Add a clocks property to the properties since RTL9607C requires it
>>>> along with the realtek,scl.
>>>>
>>>> Signed-off-by: Rustam Adilov <adilov@disroot.org>
>>>> ---
>>>>  .../bindings/i2c/realtek,rtl9301-i2c.yaml         | 15 +++++++++++++++
>>>>  1 file changed, 15 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml b/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml
>>>> index f9a449fee2b0..5873cfdc5b3e 100644
>>>> --- a/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml
>>>> +++ b/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml
>>>> @@ -15,6 +15,8 @@ description:
>>>>    assigned to either I2C controller.
>>>>    RTL9310 SoCs have equal capabilities but support 12 common SDA lines which
>>>>    can be assigned to either I2C controller.
>>>> +  RTL9607C SoCs have equal capabilities but each controller only supports 1
>>>> +  SCL/SDA line.
>>>>  
>>>>  properties:
>>>>    compatible:
>>>> @@ -34,6 +36,7 @@ properties:
>>>>        - enum:
>>>>            - realtek,rtl9301-i2c
>>>>            - realtek,rtl9310-i2c
>>>> +          - realtek,rtl9607-i2c
>>>>  
>>>>    reg:
>>>>      items:
>>>> @@ -51,6 +54,9 @@ properties:
>>>>        The SCL line number of this I2C controller.
>>>>      enum: [ 0, 1 ]
>>>>  
>>>> +  clocks:
>>>> +    maxItems: 1
>>>> +
>>>>  patternProperties:
>>>>    '^i2c@[0-9ab]$':
>>>>      $ref: /schemas/i2c/i2c-controller.yaml
>>>> @@ -81,6 +87,15 @@ allOf:
>>>>      then:
>>>>        patternProperties:
>>>>          '^i2c@[89ab]$': false
>>>
>>> Other devices do not have any clock input? Hard to believe, but if that
>>> was the case then previous "if:then:" should disallow this. But if you
>>> assume they have clock, which is expected, then document this in the
>>> commit msg. Now you just silently add clock to each of existing variant
>>> without any explanation WHY.
>> 
>> As far as i can tell, that does seem to be the case that they don't need the
>> clocks input. In RTL9300 and RL9310 there is a simple SCL_FREQ bit field that
>> sets the frequency from preselected option (100khz, 400kHz, 2.5MHz and 50kHz) and
>> it is gotten straight from the clock-frequency of the i2c child nodes.
> 
> And from where does this clock gets its frequency? Really SoC IP block
> not having clock input would mean it is not part of the SoC, because it
> would have completely independent clock domain.

I will have to leave this question to someone who knows it as i certainly don't know.
Maybe the driver maintainer has some knowledge on this.

>> But in RTL9607C there is CLK_DIV bit field instead and it is set to the calculated
>> value of "clk_get_rate(i2c->clk) / i2c->bus_freq - 1" and that is why it requires
>> clocks.
>> 
>> With this, what should be changed in this i2c bindings file? I was under assumption
> 
> If devices *do not have* clock, you set it as false (see example schema
> and even line above!). Clue here is what I wrote "devices" and "do not
> have".

I have read the example-schema file and from what i understand it i can put the
"else: properties: clocks: false" ?

So then, the whole would look like

  - if:
      properties:
        compatible:
          contains:
            const: realtek,rtl9607-i2c
    then:
      required:
        - realtek,scl
        - clocks
    else:
      properties:
        clocks: false

Let me know if my understanding of scheme is accurate cause i am very new to this.
Or should the "clocks: false" be under each other "if:" for rtl9300 and rtl9310
const compatibles?

> Best regards,
> Krzysztof

Best,
Rustam

  reply	other threads:[~2026-03-15 16:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-14  8:26 [PATCH 0/8] i2c: rtl9300: support for RTL9607C I2C controller Rustam Adilov
2026-03-14  8:26 ` [PATCH 1/8] i2c: rtl9300: split data_reg into read and write reg Rustam Adilov
2026-03-14  8:26 ` [PATCH 2/8] i2c: rtl9300: introduce max length property to driver data Rustam Adilov
2026-03-14  8:26 ` [PATCH 3/8] i2c: rtl9300: introduce F_BUSY to the reg_fields struct Rustam Adilov
2026-03-14  8:26 ` [PATCH 4/8] i2c: rtl9300: introduce a property for 8 bit width reg address Rustam Adilov
2026-03-15 21:26   ` Chris Packham
2026-03-15 21:31   ` Chris Packham
2026-03-16 16:28     ` Rustam Adilov
2026-03-16 20:24       ` Chris Packham
2026-03-14  8:26 ` [PATCH 5/8] i2c: rtl9300: introduce clk struct for upcoming rtl9607 support Rustam Adilov
2026-03-14  8:26 ` [PATCH 6/8] i2c: rtl9300: intoduce new function properties to driver data Rustam Adilov
2026-03-15 21:36   ` Chris Packham
2026-03-16 16:42     ` Rustam Adilov
2026-03-14  8:26 ` [PATCH 7/8] dt-bindings: i2c: realtek,rtl9301-i2c: extend for RTL9607C support Rustam Adilov
2026-03-15  8:56   ` Krzysztof Kozlowski
2026-03-15 10:10     ` Rustam Adilov
2026-03-15 10:15       ` Krzysztof Kozlowski
2026-03-15 16:18         ` Rustam Adilov [this message]
2026-03-14  8:26 ` [PATCH 8/8] i2c: rtl9300: add RTL9607C i2c controller support Rustam Adilov
2026-03-15 21:45 ` [PATCH 0/8] i2c: rtl9300: support for RTL9607C I2C controller Chris Packham

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=1e2119e91baf59936c0d42f047a1c733@disroot.org \
    --to=adilov@disroot.org \
    --cc=andi.shyti@kernel.org \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jelonek.jonas@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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