| Message ID | 20240110175221.2335480-3-Frank.Li@nxp.com |
|---|---|
| State | New |
| Headers | show |
| Series | I3C target mode support | expand |
On 10/01/2024 18:52, Frank Li wrote: > Add compatible string 'silvaco,i3c-target-v1' for target mode. Your subject has some multiple prefixes? Why there is one more ":"? Just: add XYZ device > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > --- > .../devicetree/bindings/i3c/silvaco,i3c-master.yaml | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml > index 133855f11b4f5..17849c91d4d2b 100644 > --- a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml > +++ b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml > @@ -4,7 +4,7 @@ > $id: http://devicetree.org/schemas/i3c/silvaco,i3c-master.yaml# > $schema: http://devicetree.org/meta-schemas/core.yaml# > > -title: Silvaco I3C master > +title: Silvaco I3C master/target > > maintainers: > - Conor Culhane <conor.culhane@silvaco.com> > @@ -14,8 +14,9 @@ allOf: > > properties: > compatible: > - const: silvaco,i3c-master-v1 NAK, you got comment, didn't you? Why did you ignore it? It's like third time you try to push it ignoring what we keep asking. Pushing the same without resolving anything in previous discussion is not acceptable and it feels like waste of my time. > - Why are you removing the blank line? Best regards, Krzysztof
On Fri, Jan 12, 2024 at 08:38:39AM +0100, Krzysztof Kozlowski wrote: > On 10/01/2024 18:52, Frank Li wrote: > > Add compatible string 'silvaco,i3c-target-v1' for target mode. > > Your subject has some multiple prefixes? Why there is one more ":"? > Just: add XYZ device > > > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com> > > --- > > .../devicetree/bindings/i3c/silvaco,i3c-master.yaml | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml > > index 133855f11b4f5..17849c91d4d2b 100644 > > --- a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml > > +++ b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml > > @@ -4,7 +4,7 @@ > > $id: http://devicetree.org/schemas/i3c/silvaco,i3c-master.yaml# > > $schema: http://devicetree.org/meta-schemas/core.yaml# > > > > -title: Silvaco I3C master > > +title: Silvaco I3C master/target > > > > maintainers: > > - Conor Culhane <conor.culhane@silvaco.com> > > @@ -14,8 +14,9 @@ allOf: > > > > properties: > > compatible: > > - const: silvaco,i3c-master-v1 > > NAK, you got comment, didn't you? Why did you ignore it? It's like third > time you try to push it ignoring what we keep asking. Pushing the same > without resolving anything in previous discussion is not acceptable and > it feels like waste of my time. I review previous comments. The previous RFC patches and I just want I3C expert review to check if there are comments about whole software architecture. Of course, thank you for your comments about "slave". Go back this binding doc problem. "No, it's the same device. Anyway, this was not tested. Please use scripts/get_maintainers.pl to get a list of necessary people and lists to CC. It might happen, that command when run on an older kernel, gives you outdated entries. Therefore please be sure you base your patches on recent Linux kernel. You missed at least devicetree list (maybe more), so this won't be tested by automated tooling. Performing review on untested code might be a waste of time, thus I will skip this patch entirely till you follow the process allowing the patch to be tested. Please kindly resend and include all necessary To/Cc entries. " It is the same devices, work at difference mode (master and target). what's do you want to change to? Copy to new file like pci/pci-ep? all context is the same, except for compatible string. Frank > > > > - > > Why are you removing the blank line? > > > Best regards, > Krzysztof >
On 12/01/2024 16:31, Frank Li wrote: > I review previous comments. The previous RFC patches and I just want I3C > expert review to check if there are comments about whole software > architecture. Of course, thank you for your comments about "slave". > > Go back this binding doc problem. > > "No, it's the same device. > > Anyway, this was not tested. > > Please use scripts/get_maintainers.pl to get a list of necessary people > and lists to CC. It might happen, that command when run on an older > kernel, gives you outdated entries. Therefore please be sure you base > your patches on recent Linux kernel. > > You missed at least devicetree list (maybe more), so this won't be > tested by automated tooling. Performing review on untested code might be > a waste of time, thus I will skip this patch entirely till you follow > the process allowing the patch to be tested. > > Please kindly resend and include all necessary To/Cc entries. > " > > It is the same devices, work at difference mode (master and target). > what's do you want to change to? > > Copy to new file like pci/pci-ep? all context is the same, except for > compatible string. > Apologies, I mixed up a bit patches, so this was not obvious. I meant this comment: https://lore.kernel.org/all/20231017201404.GA2570433-robh@kernel.org/ There is no indication in your commit msg that these concerns were addressed. Best regards, Krzysztof
On 12/01/2024 16:50, Krzysztof Kozlowski wrote: > On 12/01/2024 16:31, Frank Li wrote: >> I review previous comments. The previous RFC patches and I just want I3C >> expert review to check if there are comments about whole software >> architecture. Of course, thank you for your comments about "slave". >> >> Go back this binding doc problem. >> >> "No, it's the same device. >> >> Anyway, this was not tested. >> >> Please use scripts/get_maintainers.pl to get a list of necessary people >> and lists to CC. It might happen, that command when run on an older >> kernel, gives you outdated entries. Therefore please be sure you base >> your patches on recent Linux kernel. >> >> You missed at least devicetree list (maybe more), so this won't be >> tested by automated tooling. Performing review on untested code might be >> a waste of time, thus I will skip this patch entirely till you follow >> the process allowing the patch to be tested. >> >> Please kindly resend and include all necessary To/Cc entries. >> " >> >> It is the same devices, work at difference mode (master and target). >> what's do you want to change to? >> >> Copy to new file like pci/pci-ep? all context is the same, except for >> compatible string. >> > > Apologies, I mixed up a bit patches, so this was not obvious. I meant > this comment: > > https://lore.kernel.org/all/20231017201404.GA2570433-robh@kernel.org/ > > There is no indication in your commit msg that these concerns were > addressed. And here: https://lore.kernel.org/all/6110c58a-8003-4889-9a4b-6a7d1821c00e@linaro.org/ Best regards, Krzysztof
On Fri, Jan 12, 2024 at 04:50:25PM +0100, Krzysztof Kozlowski wrote: > On 12/01/2024 16:31, Frank Li wrote: > > I review previous comments. The previous RFC patches and I just want I3C > > expert review to check if there are comments about whole software > > architecture. Of course, thank you for your comments about "slave". > > > > Go back this binding doc problem. > > > > "No, it's the same device. > > > > Anyway, this was not tested. > > > > Please use scripts/get_maintainers.pl to get a list of necessary people > > and lists to CC. It might happen, that command when run on an older > > kernel, gives you outdated entries. Therefore please be sure you base > > your patches on recent Linux kernel. > > > > You missed at least devicetree list (maybe more), so this won't be > > tested by automated tooling. Performing review on untested code might be > > a waste of time, thus I will skip this patch entirely till you follow > > the process allowing the patch to be tested. > > > > Please kindly resend and include all necessary To/Cc entries. > > " > > > > It is the same devices, work at difference mode (master and target). > > what's do you want to change to? > > > > Copy to new file like pci/pci-ep? all context is the same, except for > > compatible string. > > > > Apologies, I mixed up a bit patches, so this was not obvious. I meant > this comment: > > https://lore.kernel.org/all/20231017201404.GA2570433-robh@kernel.org/ > > There is no indication in your commit msg that these concerns were > addressed. Look like everyone already accecpted 'silvaco,i3c-master-v1'. driver part: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=8911eae9c8a947e5c1cc4fcce40473f1f5e475cd dts part: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=b8ec0f3b42a3498d5115d1fb1490082ab525747b Frank > > Best regards, > Krzysztof >
On 15/01/2024 20:44, Frank Li wrote: > On Fri, Jan 12, 2024 at 11:06:01AM -0500, Frank Li wrote: >> On Fri, Jan 12, 2024 at 04:50:25PM +0100, Krzysztof Kozlowski wrote: >>> On 12/01/2024 16:31, Frank Li wrote: >>>> I review previous comments. The previous RFC patches and I just want I3C >>>> expert review to check if there are comments about whole software >>>> architecture. Of course, thank you for your comments about "slave". >>>> >>>> Go back this binding doc problem. >>>> >>>> "No, it's the same device. >>>> >>>> Anyway, this was not tested. >>>> >>>> Please use scripts/get_maintainers.pl to get a list of necessary people >>>> and lists to CC. It might happen, that command when run on an older >>>> kernel, gives you outdated entries. Therefore please be sure you base >>>> your patches on recent Linux kernel. >>>> >>>> You missed at least devicetree list (maybe more), so this won't be >>>> tested by automated tooling. Performing review on untested code might be >>>> a waste of time, thus I will skip this patch entirely till you follow >>>> the process allowing the patch to be tested. >>>> >>>> Please kindly resend and include all necessary To/Cc entries. >>>> " >>>> >>>> It is the same devices, work at difference mode (master and target). >>>> what's do you want to change to? >>>> >>>> Copy to new file like pci/pci-ep? all context is the same, except for >>>> compatible string. >>>> >>> >>> Apologies, I mixed up a bit patches, so this was not obvious. I meant >>> this comment: >>> >>> https://lore.kernel.org/all/20231017201404.GA2570433-robh@kernel.org/ >>> >>> There is no indication in your commit msg that these concerns were >>> addressed. >> >> Look like everyone already accecpted 'silvaco,i3c-master-v1'. >> >> driver part: >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=8911eae9c8a947e5c1cc4fcce40473f1f5e475cd >> dts part: >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=b8ec0f3b42a3498d5115d1fb1490082ab525747b > > @Krzysztof: > Patches were accepted after discussion, what you ponit to. So I > think everyone agree on the name 'silvaco,i3c-master-v1'. > I plan send next version to fix auto build error. Any additional > comments about this? I still do not see how did you address Rob's comment and his point is valid. You just did not reply to it. Best regards, Krzysztof
On Tue, Jan 16, 2024 at 12:35:44PM -0500, Frank Li wrote: > On Tue, Jan 16, 2024 at 09:48:08AM +0000, Conor Dooley wrote: > > On Tue, Jan 16, 2024 at 10:33:48AM +0100, Krzysztof Kozlowski wrote: > > > On 16/01/2024 10:30, Conor Dooley wrote: > > > > On Tue, Jan 16, 2024 at 08:24:20AM +0100, Krzysztof Kozlowski wrote: > > > >> On 16/01/2024 03:29, Frank Li wrote: > > > >>>>> Patches were accepted after discussion, what you ponit to. So I > > > >>>>> think everyone agree on the name 'silvaco,i3c-master-v1'. > > > >>>>> I plan send next version to fix auto build error. Any additional > > > >>>>> comments about this? > > > >>>> > > > >>>> I still do not see how did you address Rob's comment and his point is > > > >>>> valid. You just did not reply to it. > > > >>> > > > >>> See https://lore.kernel.org/imx/ZXCiaKfMYYShoiXK@lizhi-Precision-Tower-5810/ > > > >> > > > >> First of all, that's not the answer to Rob's email, but some other > > > >> thread which is 99% ignored by Rob (unless he has filters for > > > >> "@Rob"...). Therefore no, it does not count as valid answer. > > > >> > > > >> Second, explanation does not make sense. There is no argument granting > > > >> you exception from SoC specific compatibles. > > > > > > > > The patch could have been applied two months ago had Frank done as > > > > was requested (multiple times). I don't understand the resistance > > > > towards doing so given the process has taken way way longer as a result. > > > > > > I think that Rob's comment was just skipped and original master binding > > > was merged without addressing it. I don't want to repeat the same > > > process for the "target". Indeed I could point this earlier... if I only > > > knew that Rob pointed out that issue. > > > > Oh I think I got confused here. The context for this mail led me to > > think that this was still trying to push the i3c-master-v1 stuff through > > and I was commenting on my frustration with the resistance to applying > > the feedback received. I didn't realise that this was for another > > patch adding a target. > > > > I think you already said it, but NAK to adding any more compatibles here > > until the soc-specific compatible that was asked for for the imx93 is > > added. > > Is it okay for 'silvaco,i3c-target-imx93'? I don't know. Is the device in question capable of also operating in master mode? I have no idea from the commit message since it contains zero information on the hardware. If the exact same controller can operate in master and target mode, having two compatibles for the same device does not seem okay to me. Also, "silvaco" does not make the imx93 so that is not a suitable vendor prefix. If the imx93 only supports i3c IPs in target mode, I would call it "<vendorofimx>,imx93-i3c" with "silvaco,i3c-target-v1" as a fallback. Thanks, Conor.
On Tue, Jan 16, 2024 at 09:30:24PM +0100, Krzysztof Kozlowski wrote: > On 16/01/2024 20:13, Frank Li wrote: > > On Tue, Jan 16, 2024 at 06:23:09PM +0000, Conor Dooley wrote: > >> On Tue, Jan 16, 2024 at 12:35:44PM -0500, Frank Li wrote: > >>> On Tue, Jan 16, 2024 at 09:48:08AM +0000, Conor Dooley wrote: > >>>> On Tue, Jan 16, 2024 at 10:33:48AM +0100, Krzysztof Kozlowski wrote: > >>>>> On 16/01/2024 10:30, Conor Dooley wrote: > >>>>>> On Tue, Jan 16, 2024 at 08:24:20AM +0100, Krzysztof Kozlowski wrote: > >>>>>>> On 16/01/2024 03:29, Frank Li wrote: > >>>>>>>>>> Patches were accepted after discussion, what you ponit to. So I > >>>>>>>>>> think everyone agree on the name 'silvaco,i3c-master-v1'. > >>>>>>>>>> I plan send next version to fix auto build error. Any additional > >>>>>>>>>> comments about this? > >>>>>>>>> > >>>>>>>>> I still do not see how did you address Rob's comment and his point is > >>>>>>>>> valid. You just did not reply to it. > >>>>>>>> > >>>>>>>> See https://lore.kernel.org/imx/ZXCiaKfMYYShoiXK@lizhi-Precision-Tower-5810/ > >>>>>>> > >>>>>>> First of all, that's not the answer to Rob's email, but some other > >>>>>>> thread which is 99% ignored by Rob (unless he has filters for > >>>>>>> "@Rob"...). Therefore no, it does not count as valid answer. > >>>>>>> > >>>>>>> Second, explanation does not make sense. There is no argument granting > >>>>>>> you exception from SoC specific compatibles. > >>>>>> > >>>>>> The patch could have been applied two months ago had Frank done as > >>>>>> was requested (multiple times). I don't understand the resistance > >>>>>> towards doing so given the process has taken way way longer as a result. > >>>>> > >>>>> I think that Rob's comment was just skipped and original master binding > >>>>> was merged without addressing it. I don't want to repeat the same > >>>>> process for the "target". Indeed I could point this earlier... if I only > >>>>> knew that Rob pointed out that issue. > >>>> > >>>> Oh I think I got confused here. The context for this mail led me to > >>>> think that this was still trying to push the i3c-master-v1 stuff through > >>>> and I was commenting on my frustration with the resistance to applying > >>>> the feedback received. I didn't realise that this was for another > >>>> patch adding a target. > >>>> > >>>> I think you already said it, but NAK to adding any more compatibles here > >>>> until the soc-specific compatible that was asked for for the imx93 is > >>>> added. > >>> > >>> Is it okay for 'silvaco,i3c-target-imx93'? > > No, because imx93 is product of NXP, not Silvaco. > > You need regular SoC-block compatibles, just like we have for all other > snps, dwc and cdns. "nxp,imx93-svc-i3c-target" ? Just little bit strange for binding file name is silvaco,i3c-master.yaml. look like "dwc,*" compatitble string's file name is "dwc,*".yaml. Frank > > > Best regards, > Krzysztof >
On 16/01/2024 21:56, Krzysztof Kozlowski wrote: > On 16/01/2024 21:44, Frank Li wrote: >> On Tue, Jan 16, 2024 at 09:30:24PM +0100, Krzysztof Kozlowski wrote: >>> On 16/01/2024 20:13, Frank Li wrote: >>>> On Tue, Jan 16, 2024 at 06:23:09PM +0000, Conor Dooley wrote: >>>>> On Tue, Jan 16, 2024 at 12:35:44PM -0500, Frank Li wrote: >>>>>> On Tue, Jan 16, 2024 at 09:48:08AM +0000, Conor Dooley wrote: >>>>>>> On Tue, Jan 16, 2024 at 10:33:48AM +0100, Krzysztof Kozlowski wrote: >>>>>>>> On 16/01/2024 10:30, Conor Dooley wrote: >>>>>>>>> On Tue, Jan 16, 2024 at 08:24:20AM +0100, Krzysztof Kozlowski wrote: >>>>>>>>>> On 16/01/2024 03:29, Frank Li wrote: >>>>>>>>>>>>> Patches were accepted after discussion, what you ponit to. So I >>>>>>>>>>>>> think everyone agree on the name 'silvaco,i3c-master-v1'. >>>>>>>>>>>>> I plan send next version to fix auto build error. Any additional >>>>>>>>>>>>> comments about this? >>>>>>>>>>>> >>>>>>>>>>>> I still do not see how did you address Rob's comment and his point is >>>>>>>>>>>> valid. You just did not reply to it. >>>>>>>>>>> >>>>>>>>>>> See https://lore.kernel.org/imx/ZXCiaKfMYYShoiXK@lizhi-Precision-Tower-5810/ >>>>>>>>>> >>>>>>>>>> First of all, that's not the answer to Rob's email, but some other >>>>>>>>>> thread which is 99% ignored by Rob (unless he has filters for >>>>>>>>>> "@Rob"...). Therefore no, it does not count as valid answer. >>>>>>>>>> >>>>>>>>>> Second, explanation does not make sense. There is no argument granting >>>>>>>>>> you exception from SoC specific compatibles. >>>>>>>>> >>>>>>>>> The patch could have been applied two months ago had Frank done as >>>>>>>>> was requested (multiple times). I don't understand the resistance >>>>>>>>> towards doing so given the process has taken way way longer as a result. >>>>>>>> >>>>>>>> I think that Rob's comment was just skipped and original master binding >>>>>>>> was merged without addressing it. I don't want to repeat the same >>>>>>>> process for the "target". Indeed I could point this earlier... if I only >>>>>>>> knew that Rob pointed out that issue. >>>>>>> >>>>>>> Oh I think I got confused here. The context for this mail led me to >>>>>>> think that this was still trying to push the i3c-master-v1 stuff through >>>>>>> and I was commenting on my frustration with the resistance to applying >>>>>>> the feedback received. I didn't realise that this was for another >>>>>>> patch adding a target. >>>>>>> >>>>>>> I think you already said it, but NAK to adding any more compatibles here >>>>>>> until the soc-specific compatible that was asked for for the imx93 is >>>>>>> added. >>>>>> >>>>>> Is it okay for 'silvaco,i3c-target-imx93'? >>> >>> No, because imx93 is product of NXP, not Silvaco. >>> >>> You need regular SoC-block compatibles, just like we have for all other >>> snps, dwc and cdns. >> >> "nxp,imx93-svc-i3c-target" ? > > Could be, now please point me to patch adding such code to DTS. I would > like to see the real use case for it. Probably I was not clear enough, so let's be more precise: I think you might have troubles pointing to such code, because it just does not exist. It is a bit contradicting to single hardware description, because you want to describe one hardware in two different ways, with two different compatibles. Your commit msg is here empty - it says what patch is does, which is obvious. Tells nothing about the hardware being described here, which does not help this discussion. This would need solving as well, but main point stays - don't add new compatibles for the same hardware, at least not without valid reason/explanation. Best regards, Krzysztof
On Tue, Jan 16, 2024 at 10:01:42PM +0100, Krzysztof Kozlowski wrote: > On 16/01/2024 21:56, Krzysztof Kozlowski wrote: > > On 16/01/2024 21:44, Frank Li wrote: > >> On Tue, Jan 16, 2024 at 09:30:24PM +0100, Krzysztof Kozlowski wrote: > >>> On 16/01/2024 20:13, Frank Li wrote: > >>>> On Tue, Jan 16, 2024 at 06:23:09PM +0000, Conor Dooley wrote: > >>>>> On Tue, Jan 16, 2024 at 12:35:44PM -0500, Frank Li wrote: > >>>>>> On Tue, Jan 16, 2024 at 09:48:08AM +0000, Conor Dooley wrote: > >>>>>>> On Tue, Jan 16, 2024 at 10:33:48AM +0100, Krzysztof Kozlowski wrote: > >>>>>>>> On 16/01/2024 10:30, Conor Dooley wrote: > >>>>>>>>> On Tue, Jan 16, 2024 at 08:24:20AM +0100, Krzysztof Kozlowski wrote: > >>>>>>>>>> On 16/01/2024 03:29, Frank Li wrote: > >>>>>>>>>>>>> Patches were accepted after discussion, what you ponit to. So I > >>>>>>>>>>>>> think everyone agree on the name 'silvaco,i3c-master-v1'. > >>>>>>>>>>>>> I plan send next version to fix auto build error. Any additional > >>>>>>>>>>>>> comments about this? > >>>>>>>>>>>> > >>>>>>>>>>>> I still do not see how did you address Rob's comment and his point is > >>>>>>>>>>>> valid. You just did not reply to it. > >>>>>>>>>>> > >>>>>>>>>>> See https://lore.kernel.org/imx/ZXCiaKfMYYShoiXK@lizhi-Precision-Tower-5810/ > >>>>>>>>>> > >>>>>>>>>> First of all, that's not the answer to Rob's email, but some other > >>>>>>>>>> thread which is 99% ignored by Rob (unless he has filters for > >>>>>>>>>> "@Rob"...). Therefore no, it does not count as valid answer. > >>>>>>>>>> > >>>>>>>>>> Second, explanation does not make sense. There is no argument granting > >>>>>>>>>> you exception from SoC specific compatibles. > >>>>>>>>> > >>>>>>>>> The patch could have been applied two months ago had Frank done as > >>>>>>>>> was requested (multiple times). I don't understand the resistance > >>>>>>>>> towards doing so given the process has taken way way longer as a result. > >>>>>>>> > >>>>>>>> I think that Rob's comment was just skipped and original master binding > >>>>>>>> was merged without addressing it. I don't want to repeat the same > >>>>>>>> process for the "target". Indeed I could point this earlier... if I only > >>>>>>>> knew that Rob pointed out that issue. > >>>>>>> > >>>>>>> Oh I think I got confused here. The context for this mail led me to > >>>>>>> think that this was still trying to push the i3c-master-v1 stuff through > >>>>>>> and I was commenting on my frustration with the resistance to applying > >>>>>>> the feedback received. I didn't realise that this was for another > >>>>>>> patch adding a target. > >>>>>>> > >>>>>>> I think you already said it, but NAK to adding any more compatibles here > >>>>>>> until the soc-specific compatible that was asked for for the imx93 is > >>>>>>> added. > >>>>>> > >>>>>> Is it okay for 'silvaco,i3c-target-imx93'? > >>> > >>> No, because imx93 is product of NXP, not Silvaco. > >>> > >>> You need regular SoC-block compatibles, just like we have for all other > >>> snps, dwc and cdns. > >> > >> "nxp,imx93-svc-i3c-target" ? > > > > Could be, now please point me to patch adding such code to DTS. I would > > like to see the real use case for it. > > Probably I was not clear enough, so let's be more precise: I think you > might have troubles pointing to such code, because it just does not > exist. It is a bit contradicting to single hardware description, because > you want to describe one hardware in two different ways, with two > different compatibles. > > Your commit msg is here empty - it says what patch is does, which is > obvious. Tells nothing about the hardware being described here, which > does not help this discussion. This would need solving as well, but main > point stays - don't add new compatibles for the same hardware, at least > not without valid reason/explanation. I can improve commt msg. It was similar PCI case (There are two work mode: root complex and endpoint). So there are two kind compatible string for it. If you think it is good for using two compatible string for two work mode of the same hardware. 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. Frank > > Best regards, > Krzysztof >
On 16/01/2024 23:25, Frank Li wrote: > On Tue, Jan 16, 2024 at 10:01:42PM +0100, Krzysztof Kozlowski wrote: >> On 16/01/2024 21:56, Krzysztof Kozlowski wrote: >>> On 16/01/2024 21:44, Frank Li wrote: >>>> On Tue, Jan 16, 2024 at 09:30:24PM +0100, Krzysztof Kozlowski wrote: >>>>> On 16/01/2024 20:13, Frank Li wrote: >>>>>> On Tue, Jan 16, 2024 at 06:23:09PM +0000, Conor Dooley wrote: >>>>>>> On Tue, Jan 16, 2024 at 12:35:44PM -0500, Frank Li wrote: >>>>>>>> On Tue, Jan 16, 2024 at 09:48:08AM +0000, Conor Dooley wrote: >>>>>>>>> On Tue, Jan 16, 2024 at 10:33:48AM +0100, Krzysztof Kozlowski wrote: >>>>>>>>>> On 16/01/2024 10:30, Conor Dooley wrote: >>>>>>>>>>> On Tue, Jan 16, 2024 at 08:24:20AM +0100, Krzysztof Kozlowski wrote: >>>>>>>>>>>> On 16/01/2024 03:29, Frank Li wrote: >>>>>>>>>>>>>>> Patches were accepted after discussion, what you ponit to. So I >>>>>>>>>>>>>>> think everyone agree on the name 'silvaco,i3c-master-v1'. >>>>>>>>>>>>>>> I plan send next version to fix auto build error. Any additional >>>>>>>>>>>>>>> comments about this? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I still do not see how did you address Rob's comment and his point is >>>>>>>>>>>>>> valid. You just did not reply to it. >>>>>>>>>>>>> >>>>>>>>>>>>> See https://lore.kernel.org/imx/ZXCiaKfMYYShoiXK@lizhi-Precision-Tower-5810/ >>>>>>>>>>>> >>>>>>>>>>>> First of all, that's not the answer to Rob's email, but some other >>>>>>>>>>>> thread which is 99% ignored by Rob (unless he has filters for >>>>>>>>>>>> "@Rob"...). Therefore no, it does not count as valid answer. >>>>>>>>>>>> >>>>>>>>>>>> Second, explanation does not make sense. There is no argument granting >>>>>>>>>>>> you exception from SoC specific compatibles. >>>>>>>>>>> >>>>>>>>>>> The patch could have been applied two months ago had Frank done as >>>>>>>>>>> was requested (multiple times). I don't understand the resistance >>>>>>>>>>> towards doing so given the process has taken way way longer as a result. >>>>>>>>>> >>>>>>>>>> I think that Rob's comment was just skipped and original master binding >>>>>>>>>> was merged without addressing it. I don't want to repeat the same >>>>>>>>>> process for the "target". Indeed I could point this earlier... if I only >>>>>>>>>> knew that Rob pointed out that issue. >>>>>>>>> >>>>>>>>> Oh I think I got confused here. The context for this mail led me to >>>>>>>>> think that this was still trying to push the i3c-master-v1 stuff through >>>>>>>>> and I was commenting on my frustration with the resistance to applying >>>>>>>>> the feedback received. I didn't realise that this was for another >>>>>>>>> patch adding a target. >>>>>>>>> >>>>>>>>> I think you already said it, but NAK to adding any more compatibles here >>>>>>>>> until the soc-specific compatible that was asked for for the imx93 is >>>>>>>>> added. >>>>>>>> >>>>>>>> Is it okay for 'silvaco,i3c-target-imx93'? >>>>> >>>>> No, because imx93 is product of NXP, not Silvaco. >>>>> >>>>> You need regular SoC-block compatibles, just like we have for all other >>>>> snps, dwc and cdns. >>>> >>>> "nxp,imx93-svc-i3c-target" ? >>> >>> Could be, now please point me to patch adding such code to DTS. I would >>> like to see the real use case for it. >> >> Probably I was not clear enough, so let's be more precise: I think you >> might have troubles pointing to such code, because it just does not >> exist. It is a bit contradicting to single hardware description, because >> you want to describe one hardware in two different ways, with two >> different compatibles. >> >> Your commit msg is here empty - it says what patch is does, which is >> obvious. Tells nothing about the hardware being described here, which >> does not help this discussion. This would need solving as well, but main >> point stays - don't add new compatibles for the same hardware, at least >> not without valid reason/explanation. > > I can improve commt msg. It was similar PCI case (There are two work mode: > root complex and endpoint). So there are two kind compatible string for it. > > If you think it is good for using two compatible string for two work mode > of the same hardware. 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). > > 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. Best regards, Krzysztof
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 >
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@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? @krzyszkof: Do you agree using "mode"? Frank > > Frank > > > > > Best regards, > > Krzysztof > >
diff --git a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml index 133855f11b4f5..17849c91d4d2b 100644 --- a/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml +++ b/Documentation/devicetree/bindings/i3c/silvaco,i3c-master.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/i3c/silvaco,i3c-master.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Silvaco I3C master +title: Silvaco I3C master/target maintainers: - Conor Culhane <conor.culhane@silvaco.com> @@ -14,8 +14,9 @@ allOf: properties: compatible: - const: silvaco,i3c-master-v1 - + enum: + - silvaco,i3c-master-v1 + - silvaco,i3c-target-v1 reg: maxItems: 1
Add compatible string 'silvaco,i3c-target-v1' for target mode. Signed-off-by: Frank Li <Frank.Li@nxp.com> --- .../devicetree/bindings/i3c/silvaco,i3c-master.yaml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)