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.
>>
>>>
>>> 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.
>
> 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...
>
> 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?
>
> 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.
Best regards,
Krzysztof
