From: Krzysztof Kozlowski <krzk@kernel.org>
To: Ryan Chen <ryan_chen@aspeedtech.com>
Cc: "benh@kernel.crashing.org" <benh@kernel.crashing.org>,
"joel@jms.id.au" <joel@jms.id.au>,
"andi.shyti@kernel.org" <andi.shyti@kernel.org>,
"robh@kernel.org" <robh@kernel.org>,
"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"andrew@codeconstruct.com.au" <andrew@codeconstruct.com.au>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
"andriy.shevchenko@linux.intel.com"
<andriy.shevchenko@linux.intel.com>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mo Elbadry <elbadrym@google.com>
Subject: Re: [PATCH v16 1/3] dt-bindings: i2c: aspeed: support for AST2600-i2cv2
Date: Mon, 24 Mar 2025 12:10:34 +0100 [thread overview]
Message-ID: <8e8aa069-af9f-453f-9bd0-e3dc2eab59ab@kernel.org> (raw)
In-Reply-To: <SI6PR06MB7535BAD19B51A381171A0E64F2A42@SI6PR06MB7535.apcprd06.prod.outlook.com>
On 24/03/2025 11:01, Ryan Chen wrote:
>> Subject: Re: [PATCH v16 1/3] dt-bindings: i2c: aspeed: support for
>> AST2600-i2cv2
>>
>> On 24/03/2025 09:30, Ryan Chen wrote:
>>>> Subject: Re: [PATCH v16 1/3] dt-bindings: i2c: aspeed: support for
>>>> AST2600-i2cv2
>>>>
>>>> On 19/03/2025 12:12, Ryan Chen wrote:
>>>>>> Subject: Re: [PATCH v16 1/3] dt-bindings: i2c: aspeed: support for
>>>>>> AST2600-i2cv2
>>>>>>
>>>>>> On 17/03/2025 10:21, Ryan Chen wrote:
>>>>>>>> Neither this.
>>>>>>>>
>>>>>>>> So it seems you describe already existing and documented I2C, but
>>>>>>>> for some reason you want second compatible. The problem is that
>>>>>>>> you do not provide reason from the point of view of bindings.
>>>>>>>>
>>>>>>>> To summarize: what your users want - don't care. Start properly
>>>>>>>> describing hardware and your SoC.
>>>>>>>
>>>>>>> OK, for ast2600 i2c controller have two register mode setting.
>>>>>>> One, I call it is old register setting, that is right now
>>>>>>> i2c-aspeed.c .compatible = "aspeed,ast2600-i2c-bus", And there
>>>>>>> have a global register
>>>>>> that can set i2c controller as new mode register set.
>>>>>>> That I am going to drive. That I post is all register in new an
>>>>>>> old register
>>>> list.
>>>>>>>
>>>>>>> For example,
>>>>>>> Global register [2] = 0 => i2c present as old register set Global
>>>>>>> register [2] = 1 => i2c present as new register set
>>>>>> It's the same device though, so the same compatible.
>>>>>
>>>>> Sorry, it is different design, and it share the same register space.
>>>>> So that the reason add new compatible "aspeed,ast2600-i2cv2" for
>>>>> this
>>>> driver.
>>>>> It is different register layout.
>>>>
>>>> Which device is described by the existing "aspeed,ast2600-i2c-bus"
>>>> compatible? And which device is described by new compatible?
>>>>
>>> On the AST2600 SoC, there are up to 16 I2C controller instances (I2C1 ~
>> I2C16).
>>
>> So you have 16 same devices.
> Yes, one driver instance for 16 i2c device.
>>
>>> Each of these controllers is hardwired at the SoC level to use either the
>> legacy register layout or the new v2 register layout.
>>> The mode is selected by a bit in the global register, these represent two
>> different hardware blocks:
>>> "aspeed,ast2600-i2c-bus" describes controllers using the legacy register
>> layout.
>>> "aspeed,ast2600-i2cv2" describes controllers using the new register
>>> layout
>>
>> Which part of "same device" is not clear? You have one device, one compatible.
>> Whatever you do with register layout, is already defined by that compatible. It
>> does not matter that you forgot to implement it in the Linux kernel.
>
> Sorry, I still can't catch your point.
I repeated twice "You have one device, one compatible.", provided few
more sentences and if this is still unclear, I don't know what to say more.
> I separated the support into two drivers:
I don't care about your drivers, why are you bringing them here?
> i2c-aspeed.c for legacy layout, compatible "aspeed,ast2600-i2c-bus"
> i2c-ast2600.c for the new register set, compatible compatible "aspeed,ast2600-i2cv2"
> Do you mean I have integrate into 1 driver at i2c-aspeed.c ? can't be separate two driver?
What is this patch about? Bindings. Not drivers. Look at email month ago:
"All this describes driver, not hardware."
Why are you keep bringing here drivers since a month?
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-03-24 11:10 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 5:59 [PATCH v16 0/3] Add ASPEED AST2600 I2Cv2 controller driver Ryan Chen
2025-02-24 5:59 ` [PATCH v16 1/3] dt-bindings: i2c: aspeed: support for AST2600-i2cv2 Ryan Chen
2025-02-24 7:16 ` Rob Herring (Arm)
2025-02-24 9:11 ` Krzysztof Kozlowski
2025-02-24 9:12 ` Krzysztof Kozlowski
2025-02-26 9:28 ` Ryan Chen
2025-02-26 9:56 ` Krzysztof Kozlowski
2025-02-27 8:19 ` Ryan Chen
2025-02-27 20:04 ` Krzysztof Kozlowski
2025-03-05 9:35 ` Ryan Chen
2025-03-17 7:45 ` Krzysztof Kozlowski
2025-03-17 9:21 ` Ryan Chen
2025-03-19 7:44 ` Krzysztof Kozlowski
2025-03-19 11:12 ` Ryan Chen
2025-03-24 7:21 ` Krzysztof Kozlowski
2025-03-24 8:30 ` Ryan Chen
2025-03-24 9:07 ` Krzysztof Kozlowski
2025-03-24 10:01 ` Ryan Chen
2025-03-24 11:10 ` Krzysztof Kozlowski [this message]
2025-03-25 9:52 ` Ryan Chen
2025-03-25 10:18 ` Krzysztof Kozlowski
2025-02-24 5:59 ` [PATCH v16 2/3] i2c: aspeed: support AST2600 i2c new register mode driver Ryan Chen
2025-02-24 8:54 ` Philipp Zabel
2025-02-24 9:04 ` Ryan Chen
2025-02-24 9:32 ` Philipp Zabel
2025-02-28 1:28 ` kernel test robot
2025-02-28 12:38 ` Andy Shevchenko
2025-03-17 7:48 ` Krzysztof Kozlowski
2025-03-17 8:00 ` Andy Shevchenko
2025-03-17 8:51 ` Ryan Chen
2025-03-17 8:57 ` Krzysztof Kozlowski
2025-02-24 5:59 ` [PATCH v16 3/3] i2c: aspeed: support AST2600 i2c new register target " Ryan Chen
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=8e8aa069-af9f-453f-9bd0-e3dc2eab59ab@kernel.org \
--to=krzk@kernel.org \
--cc=andi.shyti@kernel.org \
--cc=andrew@codeconstruct.com.au \
--cc=andriy.shevchenko@linux.intel.com \
--cc=benh@kernel.crashing.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=elbadrym@google.com \
--cc=joel@jms.id.au \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=openbmc@lists.ozlabs.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=ryan_chen@aspeedtech.com \
/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).