Re: [PATCH 1/2] dt-bindings: i2c: add atciic100

[Ben Zong-You Xie <ben717@andestech.com>]

On Thu, Jan 22, 2026 at 12:27:00PM +0100, Krzysztof Kozlowski wrote:
> [EXTERNAL MAIL]
> 
> On 22/01/2026 12:18, Ben Zong-You Xie wrote:
> > On Sun, Feb 09, 2025 at 01:29:58PM +0100, Krzysztof Kozlowski wrote:
> >> On Fri, Feb 07, 2025 at 10:19:22AM +0800, Ben Zong-You Xie wrote:
> >>> Document devicetree bindings for Andes I2C controller.
> >>
> >> Explain what is the hardware... Here is Andes I2C
> >>
> >>>
> >>> Signed-off-by: Ben Zong-You Xie <ben717@andestech.com>
> >>> ---
> >>>  .../bindings/i2c/andestech,i2c-atciic100.yaml | 40 +++++++++++++++++++
> >>>  MAINTAINERS                                   |  5 +++
> >>>  2 files changed, 45 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/i2c/andestech,i2c-atciic100.yaml
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/i2c/andestech,i2c-atciic100.yaml b/Documentation/devicetree/bindings/i2c/andestech,i2c-atciic100.yaml
> >>> new file mode 100644
> >>> index 000000000000..cf96a9186176
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/i2c/andestech,i2c-atciic100.yaml
> >>> @@ -0,0 +1,40 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> >>> +%YAML 1.2
> >>> +---
> >>> +$id: http://devicetree.org/schemas/pwm/andestech,atciic100.yaml#
> >>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>> +
> >>> +title: Andes I2C Controller
> >>
> >> Here as well
> >>
> >>> +
> >>> +maintainers:
> >>> +  - Ben Zong-You Xie <ben717@andestech.com>
> >>> +
> >>> +allOf:
> >>> +  - $ref: /schemas/i2c/i2c-controller.yaml#
> >>> +
> >>> +properties:
> >>> +  compatible:
> >>> +    const: andestech,atciic100
> >>
> >> But here atciic100. This is all confusing. What is the SoC? What is the
> >> name of this device?
> >
> > Hi Krzysztof,
> >
> > Sorry for the confusion. atciic100 is the name for the I2C IP block, and it
> > is integrated on QiLai SoC. That's why I added a new compatible
> > "andestech,qilai-i2c" in v2.
> 
> So atciic100 is not an SoC... but then why there is I2C and SPI variant?
> Is this some serial engine? Because if it is, you probably miss here
> much more bindings for complete hardware description.
> 

There is no variant for atciic100. It's a dedicated I2C controller IP.

> Plus, if this is IP block, how can it be used alone? We forbid that sort
> of compatibles long time ago.
>

I made the mistake you mentioned above in v1. But after your review,
I know the compatibles in the bindings should be <soc/platform>-<device>.
Thus, I have removed "andestech,atciic100" in v2, and have used
"andestech,qilai-i2c" and "andestech,ae350-i2c" instead. Also, I have
removed all the occurrences of atciic100 in v2 to avoid the confusion.

v2: https://lore.kernel.org/linux-i2c/20260122-atciic100-v2-0-7559136d07cf@andestech.com/

> Anyway you have entire commit msg to explain that.
> 

> >
> > For AE350 platform, I know it has not been upstreamed yet, but it was
> > discussed and acknowledged in a separate SPI series [1], which is why I
> 
> I see ae350-spi there, not atciic100.
> 

The reason I mentioned the SPI series is I want to add "ae350-i2c" in
this binding, like "ae350-spi" in the SPI series. Again, could I keep the
compatible "ae350-i2c" as the fallback compatible in this binding? If
not, there will be only one compatible "andestech,qilai-i2c" in the
next version.

> > included it as a fallback. Can I keep this? If not, I will drop it
> > and update the compatibles in v3 as follows:
> 
> Nothing was explained in the commit msg, so with all this being
> confusing that's the review you got. You literally wrote one half baked
> sentence being copy of subject, so like nothing relevant and should be
> treated as almost empty commit msg.
> 
> How do you expect us to understand anything from that if you write
> NOTHING in the commit msg (except copying subject)?
> 

I apologize for the lack of detail, and thank you for your patience.

Thanks,
Ben