linux-kernel - RE: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SEZPR06MB52698CCA6AE59DDC6C15CBE4F2AA9@SEZPR06MB5269.apcprd06.prod.outlook.com>
Date:   Wed, 22 Feb 2023 02:59:26 +0000
From:   Ryan Chen <ryan_chen@...eedtech.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Joel Stanley <joel@....id.au>,
        Andrew Jeffery <andrew@...id.au>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "openbmc@...ts.ozlabs.org" <openbmc@...ts.ozlabs.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2

Hello Krzysztof,

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> Sent: Tuesday, February 21, 2023 7:05 PM
> To: Ryan Chen <ryan_chen@...eedtech.com>; Rob Herring
> <robh+dt@...nel.org>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@...aro.org>; Joel Stanley <joel@....id.au>; Andrew
> Jeffery <andrew@...id.au>; Philipp Zabel <p.zabel@...gutronix.de>;
> openbmc@...ts.ozlabs.org; linux-arm-kernel@...ts.infradead.org;
> linux-aspeed@...ts.ozlabs.org; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v5 1/2] dt-bindings: i2c: Add support for ASPEED i2Cv2
> 
> On 21/02/2023 11:42, Ryan Chen wrote:
> >>>>> +    type: boolean
> >>>>> +    description: Enable i2c bus timeout for master/slave (35ms)
> >>>>
> >>>> Why this is property for DT? It's for sure not bool, but proper
> >>>> type coming from units.
> >>> This is i2c controller feature for enable slave mode inactive
> >>> timeout and also master mode sda/scl auto release timeout.
> >>> So I will modify to
> >>>   aspeed,timeout:
> >>> 	type: boolean
> >>>     description: I2C bus timeout enable for master/slave mode
> >>
> >> This does not answer my concerns. Why this is board specific?
> > Sorry, can’t catch your point.
> > It is not board specific. It is controller feature.
> > ASPEED SOC chip is server product, master connect may have fingerprint
> > connect to another board. And also support hotplug.
> > For example I2C controller as slave mode, and suddenly disconnected.
> > Slave state machine will keep waiting for master clock in for rx/tx transfer.
> > So it need timeout setting to enable timeout unlock controller state.
> > And in another side. As master mode, slave is clock stretching.
> > The master will be keep waiting, until slave release cll stretching.
> 
> OK, thanks for describing the feature. I still do not see how this is DT related.

Let me draw more about the board-specific. 
The following is an example about i2c layout in board.
Board A														Board B
--------------------------------------------------------							--------------------------------------------------------
|    i2c bus#1(master/slave)  <--------------------> fingerprint.(can be unplug)    <--------------------> i2c bus#x (master/slave) |
|    i2c bus#2(master) -> tmp i2c device     |			     		|									|
|    i2c bus#3(master) -> adc i2c device      |					|									|
--------------------------------------------------------							--------------------------------------------------------
In this case i2c bus#1 need enable timeout, avoid suddenly unplug the connector. That slave will keep state to drive clock stretching.
So it is specific enable in i2c bus#1. Others is not needed enable timeout. 
Does this draw is more clear in scenario?

> >
> > So in those reason add this timeout design in controller.
> 
> You need to justify why DT is correct place for this property. DT is not for
> configuring OS, but to describe hardware. I gave you one possibility
> - why different boards would like to set this property. You said it is not board
> specific, thus all boards will have it (or none of them).
> Without any other reason, this is not a DT property. Drop.
> 
> >>
> >>>
> >>>>> +
> >>>>> +  byte-mode:
> >>>>> +    type: boolean
> >>>>> +    description: Force i2c driver use byte mode transmit
> >>>>
> >>>> Drop, not a DT property.
> >>>>
> >>>>> +
> >>>>> +  buff-mode:
> >>>>> +    type: boolean
> >>>>> +    description: Force i2c driver use buffer mode transmit
> >>>>
> >>>> Drop, not a DT property.
> >>>>
> >>> The controller support 3 different for transfer.
> >>> Byte mode: it means step by step to issue transfer.
> >>> Example i2c read, each step will issue interrupt then enable next step.
> >>> Sr (start read) | D | D | D | P
> >>> Buffer mode: it means, the data can prepare into buffer register,
> >>> then Trigger transfer. So Sr D D D P, only have only 1 interrupt handling.
> >>> The DMA mode most like with buffer mode, The differ is data prepare
> >>> in DRAM, than trigger transfer.
> >>>
> >>> So, should I modify to
> >>>   aspeed,byte:
> >>> 	type: boolean
> >>>     description: Enable i2c controller transfer with byte mode
> >>>
> >>>   aspeed,buff:
> >>> 	type: boolean
> >>>     description: Enable i2c controller transfer with buff mode
> >>
> >> 1. No, these are not bools but enum in such case.
> >
> > Thanks, will modify following.
> > aspeed,xfer_mode:
> >     enum: [0, 1, 2]
> >     description:
> >       0: byte mode, 1: buff_mode, 2: dma_mode
> 
> Just keep it text - byte, buffered, dma
> 
> >
> >> 2. And why exactly this is board-specific?
> >
> > No, it not depends on board design. It is only for register control for
> controller transfer behave.
> > The controller support 3 different trigger mode for transfer.
> > Assign bus#1 ~ 3 : dma tranfer and assign bus#4 ~ 6 : buffer mode
> > transfer, That can reduce the dram usage.
> 
> Then anyway it does not look like property for Devicetree. DT describes
> hardware, not OS behavior.

The same draw, in this case, i2c bus#1 that is multi-master transfer architecture. 
Both will inactive with trunk data. That cane enable i2c#1 use DMA transfer to reduce CPU utilized.
Others (bus#2/3) can keep byte/buff mode. 

Board A														Board B
--------------------------------------------------------							--------------------------------------------------------
|    i2c bus#1(master/slave)  <--------------------> fingerprint.(can be unplug)    <--------------------> i2c bus#x (master/slave) |
|    i2c bus#2(master) -> tmp i2c device     |			     		|									|
|    i2c bus#3(master) -> adc i2c device      |					|									|
--------------------------------------------------------							--------------------------------------------------------
Best regards,
Ryan