| 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
| ||
|
Message-ID: <ZaqtsjIOsswTqXsv@lizhi-Precision-Tower-5810>
Date: Fri, 19 Jan 2024 12:13:22 -0500
From: Frank Li <Frank.li@....com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Conor Dooley <conor@...nel.org>,
Conor Dooley <conor.dooley@...rochip.com>, robh@...nel.org,
alexandre.belloni@...tlin.com, conor.culhane@...vaco.com,
gregkh@...uxfoundation.org, imx@...ts.linux.dev,
jirislaby@...nel.org, joe@...ches.com,
linux-i3c@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-serial@...r.kernel.org, miquel.raynal@...tlin.com,
zbigniew.lukwinski@...ux.intel.com, devicetree@...r.kernel.org,
krzysztof.kozlowski+dt@...aro.org
Subject: Re: [PATCH v2 2/7] dt-bindings: i3c: svc: add compatible string i3c:
silvaco,i3c-target-v1
On Wed, Jan 17, 2024 at 01:06:15PM -0500, Frank Li wrote:
> 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@...30000 {
> > > 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@...30000 {
> ...
> compatible = "silvaco,i3c-master-v1";
> ...
> status = disabled;
> }
>
> i3c1-target: i3c-target@...30000 {
> ...
> 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?
@krzyszkof:
Do you agree using "mode"?
Frank
>
> Frank
>
> >
> > Best regards,
> > Krzysztof
> >
Powered by blists - more mailing lists