diff mbox series

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

Message ID 20240110175221.2335480-3-Frank.Li@nxp.com
State New
Headers
Series I3C target mode support |

Commit Message

Frank Li Jan. 10, 2024, 5:52 p.m. UTC 
  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(-)

Comments

Krzysztof Kozlowski Jan. 12, 2024, 7:38 a.m. UTC | #1 
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
Frank Li Jan. 12, 2024, 3:31 p.m. UTC | #2 
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
>
Krzysztof Kozlowski Jan. 12, 2024, 3:50 p.m. UTC | #3 
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
Krzysztof Kozlowski Jan. 12, 2024, 4 p.m. UTC | #4 
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
Frank Li Jan. 12, 2024, 4:06 p.m. UTC | #5 
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
>
Frank Li Jan. 15, 2024, 7:44 p.m. UTC | #6 
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?

Frank

> 
> Frank
> 
> > 
> > Best regards,
> > Krzysztof
> >
Krzysztof Kozlowski Jan. 15, 2024, 8:38 p.m. UTC | #7 
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
Frank Li Jan. 16, 2024, 2:29 a.m. UTC | #8 
On Mon, Jan 15, 2024 at 09:38:19PM +0100, Krzysztof Kozlowski wrote:
> 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.

See https://lore.kernel.org/imx/ZXCiaKfMYYShoiXK@lizhi-Precision-Tower-5810/

Frank

> 
> Best regards,
> Krzysztof
>
Krzysztof Kozlowski Jan. 16, 2024, 7:24 a.m. UTC | #9 
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.

Best regards,
Krzysztof
Conor Dooley Jan. 16, 2024, 9:30 a.m. UTC | #10 
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.
Krzysztof Kozlowski Jan. 16, 2024, 9:33 a.m. UTC | #11 
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.

Best regards,
Krzysztof
Conor Dooley Jan. 16, 2024, 9:48 a.m. UTC | #12 
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.

Thanks,
Conor.
Frank Li Jan. 16, 2024, 5:35 p.m. UTC | #13 
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'?

Frank

> 
> Thanks,
> Conor.
Conor Dooley Jan. 16, 2024, 6:23 p.m. UTC | #14 
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.
Frank Li Jan. 16, 2024, 7:13 p.m. UTC | #15 
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'?
> 
> 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.

Yes, it is dual mode controller.

> 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.
> 

what's your suggestion? create a total new yaml file for target mode (like
PCI ep)?
All target information(interrupt, reg, clock) are the same as master.

Or added "mode" property instead of using difference compatible string?
It may cause kconfig become complex to handle difference mode at the same
drivers.

> 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.
> 

Look like Rob and krysztof don't likes 'silvaco,i3c-target-v1'. 

> Thanks,
> Conor.
Krzysztof Kozlowski Jan. 16, 2024, 8:30 p.m. UTC | #16 
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.


Best regards,
Krzysztof
Frank Li Jan. 16, 2024, 8:44 p.m. UTC | #17 
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
>
Krzysztof Kozlowski Jan. 16, 2024, 8:56 p.m. UTC | #18 
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.

> Just little bit strange for binding file name
> is silvaco,i3c-master.yaml.

Many other bindings do it. I don't see a problem in creating device
specific schema sharing some parts, if you have some common pieces.

> 
> look like "dwc,*" compatitble string's file name is "dwc,*".yaml.

? I don't understand how is this related, but if this is what you want
to discuss then look:
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml

or many other examples. Please open dwc, snps and cdns bindings and look
how it is done there.

Best regards,
Krzysztof
Krzysztof Kozlowski Jan. 16, 2024, 9:01 p.m. UTC | #19 
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
Frank Li Jan. 16, 2024, 9:31 p.m. UTC | #20 
On Tue, Jan 16, 2024 at 09:56:03PM +0100, 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.

This part have not sent to review yet. basically in imx93evk.dts add

&i3c1 { 
	compatible = "silvaco,i3c-target-v1";
        pinctrl-names = "default", "sleep";                                
        pinctrl-0 = <&pinctrl_i3c1>;                                       
        pinctrl-1 = <&pinctrl_i3c1>;                                       
        status = "okay"
}

> 
> > Just little bit strange for binding file name
> > is silvaco,i3c-master.yaml.
> 
> Many other bindings do it. I don't see a problem in creating device
> specific schema sharing some parts, if you have some common pieces.
> 
> > 
> > look like "dwc,*" compatitble string's file name is "dwc,*".yaml.
> 
> ? I don't understand how is this related, but if this is what you want
> to discuss then look:
> Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> 
> or many other examples. Please open dwc, snps and cdns bindings and look
> how it is done there.
> 
> Best regards,
> Krzysztof
>
Frank Li Jan. 16, 2024, 10:25 p.m. UTC | #21 
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
>
Krzysztof Kozlowski Jan. 17, 2024, 6:45 a.m. UTC | #22 
On 16/01/2024 22:31, Frank Li wrote:

>>>>>>>
>>>>>>> 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.
> 
> This part have not sent to review yet. basically in imx93evk.dts add
> 
> &i3c1 { 
> 	compatible = "silvaco,i3c-target-v1";
>         pinctrl-names = "default", "sleep";                                
>         pinctrl-0 = <&pinctrl_i3c1>;                                       
>         pinctrl-1 = <&pinctrl_i3c1>;                                       
>         status = "okay"
> }

Overriding compatible is not desired. It also supports here the
statement that this is the same hardware.

Best regards,
Krzysztof
Krzysztof Kozlowski Jan. 17, 2024, 6:50 a.m. UTC | #23 
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
Frank Li Jan. 17, 2024, 4:19 p.m. UTC | #24 
On Wed, Jan 17, 2024 at 07:50:16AM +0100, Krzysztof Kozlowski wrote:
> 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).

GPIO and UART is simple. Actuall SPI and I2C have two mode, slave and
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.
> 
> > 
> > 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!
   
                                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";                       
                        }; 

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.

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.

Although it is one hardware, I think it is exculsive multi function device.

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.

> 
> Best regards,
> Krzysztof
>
Krzysztof Kozlowski Jan. 17, 2024, 5:15 p.m. UTC | #25 
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
Frank Li Jan. 17, 2024, 6:06 p.m. UTC | #26 
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
>
Frank Li Jan. 19, 2024, 5:13 p.m. UTC | #27 
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 mbox series

Patch

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