Re: [PATCH v2 2/7] dt-bindings: i3c: svc: add compatible string i3c: silvaco,i3c-target-v1

[Frank Li]

On Wed, Jan 17, 2024 at 06:15:51PM +0100, Krzysztof Kozlowski wrote:
> On 17/01/2024 17:19, Frank Li wrote:
> >>
> >> Not really, because compatible describes hardware and it is the same
> >> hardware here. We do not have two different compatibles for GPIOs being
> >> input or output.  Or two different compatibles for serial engines (ones
> >> providing UART, SPI or I2C).
> > 
> > GPIO and UART is simple. Actuall SPI and I2C have two mode, slave and
> 
> I talked about serial engines which can be multiple: UART, SPI and I2C.
> 
> > master. Many SPI/I2C is dual mode controller. Just seldom use slave mode
> > at linux side. So you just see master mode SPI/I2C controller in dt-binding
> > and dts file. So few people upstream slave part to linux kernel community.
> > They have the exact same problems if support slave mode.
> > 
> > PCI is typical example: 
> > EP mode:  Documentation/devicetree/bindings/pci/qcom,pcie-ep.yaml
> > RC mode:  Documentation/devicetree/bindings/pci/qcom,pcie.yaml
> > 
> > Which is the same hardware for two difference compatible string.
> 
> That's the only case, I recall.

As my knowledge, yes. 

> 
> >>
> >>>
> >>> I can write git commit message like:
> >>>
> >>> dt-bindings: i3c: svc: add compatible string nxp,imx93-svc-i3c-target
> >>>
> >>> silvaco i3c controller is dual mode controller, which can work as master
> >>> and target mode. All clock, reg, irq are the same for both mode. Add
> >>> compatible string "nxp,imx93-svc-i3c-target" to let silivaco i3c
> >>> controller work as target mode.
> >>>
> >>> Of course, alternate method to added a property "mode" to distingiush
> >>> master and target mode. but old "silvaco,i3c-master-v1" will actually work
> >>> as dual mode support. Driver structure will become complex.
> >>
> >> Please send full DTS of user for this, which works for 100%, so we can
> >> see how it differs from controller mode. If your code snippet from other
> >> thread is correct, then it would suggest "mode" property or lack of
> >> children. Maybe lack of children is not enough, if user-space could
> >> control I3C bus.
> > 
> > According to current implment, only need change imx93.dtsi's @i3c1's 
> > compatible string to "silvaco,i3c-target-v1". I attached imx93 dts node for
> > your reference.
> > 
> > 	i3c1: i3c-master@44330000 {                        
> >                                 compatible = "silvaco,i3c-master-v1"; 
> > 					     ^^^^ only need change here!
> 
> Nope, don't change compatibles of existing nodes. Unreadable and
> unmanageable code.

It is just show minimize difference.

Normally, it should be.

	i3c1: i3c-master@44330000 {
		...
		compatible = "silvaco,i3c-master-v1";
		...
		status = disabled;
	}
	
	i3c1-target: i3c-target@44330000 {
		...
		compatible = "silvaco,i3c-target-v1";
		...
		status = disabled;
	}

in board dts

@i3c1{
	status = "okay";
}

Or
@i3c1-target{
	status = "okay";
}
> 
> >    
> >                                 reg = <0x44330000 0x10000>;                
> >                                 interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> >                                 #address-cells = <3>;                      
> >                                 #size-cells = <0>;                         
> >                                 clocks = <&clk IMX93_CLK_BUS_AON>,         
> >                                          <&clk IMX93_CLK_I3C1_GATE>,       
> >                                          <&clk IMX93_CLK_I3C1_SLOW>;       
> >                                 clock-names = "pclk", "fast_clk", "slow_clk";
> >                                 dmas = <&edma1 6 0 1>, <&edma1 5 0 0>;     
> >                                 dma-names = "rx", "tx";                    
> >                                 status = "disabled";                       
> >                         }; 
> 
> That's not a patch for existing file. I did not claim you cannot write
> such DTS. I claimed you don't have such DTS for upstream...

Yes, it need finialize this topic before handle dts upstream.

> 
> > 
> > For master mode:
> > Unlike i2c. Genenally I3C can auto probe children node like USB can auto
> > detect attached devices. So I3C master can work without children nodes.
> > Such as auto load i3c sensor driver according to i3c standard vendor id and
> > production id.
> 
> Then presence of children cannot be used.
> 
> > 
> > For target mode: using configfs to controller I3C.
> > 
> > mkdir /sys/kernel/config/i3c_target/functions/tty/t
> > echo 0x011b > /sys/kernel/config/i3c_target/functions/tty/t/vendor_id
> > echo 0x1000 > /sys/kernel/config/i3c_target/functions/tty/t/part_id
> > echo 0x6 > /sys/kernel/config/i3c_target/functions/tty/t/bcr
> > 
> > ln -s /sys/kernel/config/i3c_target/functions/tty/t /sys/kernel/config/i3c_target/controllers/44330000.i3c-master/
> > 
> > Then you echo test >/dev/ttySI3C0.
> > 
> > Unlike USB, user can switch host and gadget mode dymatically. Suppose I3C
> > only work on one of master or slave mode only, which is static.
> 
> I don't understand this. So it can switch dynamically or not?

I3C Protocal allow do that. But no one really do that. 

> 
> > 
> > Although it is one hardware, I think it is exculsive multi function device.
> 
> Just like serial engines. Do you see there replacing compatibles? No.
> 
> > 
> > Summary: basice two option to distingiush controller and target mode.
> > 1. by "compatible" string
> > 2. by "mode"
> > 
> > I think 1 is relatively simple and easy to understand.
> 
> Eh, if you only saw my comments on people replacing compatibles...
> Anyway, I stated my reasons, so to reiterate: NAK.

I know it.  Needn't emphase it every time.

Is using "mode" ('controller' and 'target') proptery okay?

Frank

> 
> Best regards,
> Krzysztof
>