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. And because RTL9607C is the only one that
requires the new clocks property, add "clocks: false" to everything
else.
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
.../bindings/i2c/realtek,rtl9301-i2c.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml b/Documentation/devicetree/bindings/i2c/realtek,rtl9301-i2c.yaml
index f9a449fee2b0..35ced0dcf410 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 and require clocks.
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,18 @@ allOf:
then:
patternProperties:
'^i2c@[89ab]$': false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: realtek,rtl9607-i2c
+ then:
+ required:
+ - realtek,scl
+ - clocks
+ else:
+ properties:
+ clocks: false
required:
- compatible
--
2.53.0On Thu, Mar 19, 2026 at 10:57:52PM +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. And because RTL9607C is the only one that My previous statement: "Other devices do not *have* any clock input?" And second one: "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"." So why are you using completely different wording "require" with completely different implications? I did not leave any room for interpreation in my statement "If devices *do not have* clock, you set it as false". Best regards, Krzysztof
On 2026-03-20 09:24, Krzysztof Kozlowski wrote:
> On Thu, Mar 19, 2026 at 10:57:52PM +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. And because RTL9607C is the only one that
>
> My previous statement:
>
> "Other devices do not *have* any clock input?"
>
> And second one:
>
> "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"."
>
> So why are you using completely different wording "require" with
> completely different implications?
>
> I did not leave any room for interpreation in my statement "If devices
> *do not have* clock, you set it as false".
I apologize. I was using "require" merely to relate with "required: - property" notation used in bindings.
Would changing the commit message to something similar in vein to [1] be better?
[1] - https://lore.kernel.org/linux-i2c/20250927101931.71575-9-jelonek.jonas@gmail.com/
As for the yaml, my only other interpretation (looking at how others have done it, like fsl,enetc.yaml)
if:
not:
properties:
compatible:
contains:
enum:
- realtek,rtl9607-i2c
then:
properties:
clocks: false
if it is *not* rtl9607-i2c (device that has clocks) then clocks is set to false.
Unless the check should be "if: not: required: clocks then: clocks: false" (like in samsung,s5c73m3.yaml)?
Or is the current configuration (which i got from reading the example-schema.yaml and arm,smmu.yaml)
with "else" fine?
It also doesn't help that i didn't get a response to my question in the previous email towards you in
the v1 patch series but i keep trying my best nonetheless to understand what is needed.
Best,
Rustam
On 20/03/2026 11:39, Rustam Adilov wrote: > On 2026-03-20 09:24, Krzysztof Kozlowski wrote: >> On Thu, Mar 19, 2026 at 10:57:52PM +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. And because RTL9607C is the only one that >> >> My previous statement: >> >> "Other devices do not *have* any clock input?" >> >> And second one: >> >> "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"." >> >> So why are you using completely different wording "require" with >> completely different implications? >> >> I did not leave any room for interpreation in my statement "If devices >> *do not have* clock, you set it as false". > > I apologize. I was using "require" merely to relate with "required: - property" notation used in bindings. > > Would changing the commit message to something similar in vein to [1] be better? > > [1] - https://lore.kernel.org/linux-i2c/20250927101931.71575-9-jelonek.jonas@gmail.com/ It does not cover clocks and it does not answer whether devices have it or not. Decide first whether devices have the clock or not. I asked more than once last time. Then write commit msg and code matching this. Best regards, Krzysztof
Hello On 2026-03-20 13:11, Krzysztof Kozlowski wrote: > On 20/03/2026 11:39, Rustam Adilov wrote: >> On 2026-03-20 09:24, Krzysztof Kozlowski wrote: >>> On Thu, Mar 19, 2026 at 10:57:52PM +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. And because RTL9607C is the only one that >>> >>> My previous statement: >>> >>> "Other devices do not *have* any clock input?" >>> >>> And second one: >>> >>> "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"." >>> >>> So why are you using completely different wording "require" with >>> completely different implications? >>> >>> I did not leave any room for interpreation in my statement "If devices >>> *do not have* clock, you set it as false". >> >> I apologize. I was using "require" merely to relate with "required: - property" notation used in bindings. >> >> Would changing the commit message to something similar in vein to [1] be better? >> >> [1] - https://lore.kernel.org/linux-i2c/20250927101931.71575-9-jelonek.jonas@gmail.com/ > > It does not cover clocks and it does not answer whether devices have it > or not. > > Decide first whether devices have the clock or not. I asked more than > once last time. I took some time to read the available docs like [1], [2] and my educated guess is, there has to be i2c clock/s and it is most likely connected to switch core by lexra bus as the other peripherals in SoC. I am not from Realtek so i don't know accurate that is. The difference with RTL9300/RTL9310 and RTL9607 is just, how SCL clock of the i2c master controller is configurable but that is for driver to deal with. [1] - https://svanheule.net/switches/rtl93xx [2] - https://github.com/plappermaul/realtek-doc/tree/main/datasheets > Then write commit msg and code matching this. > > Best regards, > Krzysztof Best, Rustam
On 21/03/2026 07:06, Rustam Adilov wrote: >>> >>> Would changing the commit message to something similar in vein to [1] be better? >>> >>> [1] - https://lore.kernel.org/linux-i2c/20250927101931.71575-9-jelonek.jonas@gmail.com/ >> >> It does not cover clocks and it does not answer whether devices have it >> or not. >> >> Decide first whether devices have the clock or not. I asked more than >> once last time. > > I took some time to read the available docs like [1], [2] and my educated guess is, there has > to be i2c clock/s and it is most likely connected to switch core by lexra bus as the other > peripherals in SoC. I am not from Realtek so i don't know accurate that is. > The difference with RTL9300/RTL9310 and RTL9607 is just, how SCL clock of the i2c master > controller is configurable but that is for driver to deal with. Then the clock should not be forbidden for the other variants and just explain it in the commit msg. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.