Add a new 'snps,global-regs-starting-offset' DT to dwc3 core to remap
the global register start address
The RTK DHC SoCs were designed the global register address offset at
0x8100. The default address is at DWC3_GLOBALS_REGS_START (0xc100).
Therefore, add the property of device-tree to adjust this start address.
Signed-off-by: Stanley Chang <[email protected]>
---
v1 to v2 change:
1. Change the name of the property "snps,global-regs-starting-offset".
---
Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
index be36956af53b..5cbf3b7ded04 100644
--- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml
@@ -359,6 +359,13 @@ properties:
items:
enum: [1, 4, 8, 16, 32, 64, 128, 256]
+ snps,global-regs-starting-offset:
+ description:
+ value for remapping global register start address. For some dwc3
+ controller, the dwc3 global register start address is not at
+ default DWC3_GLOBALS_REGS_START (0xc100). This property is added to
+ adjust the address.
+
port:
$ref: /schemas/graph.yaml#/properties/port
description:
--
2.34.1
On 13/04/2023 06:25, Stanley Chang wrote:
> Add a new 'snps,global-regs-starting-offset' DT to dwc3 core to remap
> the global register start address
>
> The RTK DHC SoCs were designed the global register address offset at
> 0x8100. The default address is at DWC3_GLOBALS_REGS_START (0xc100).
> Therefore, add the property of device-tree to adjust this start address.
>
> Signed-off-by: Stanley Chang <[email protected]>
> ---
> v1 to v2 change:
> 1. Change the name of the property "snps,global-regs-starting-offset".
> ---
Didn't you got already comment for this patch? How did you implement it?
Also, I asked you multiple times:
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.
I don't understand why you ignore this.
NAK, patch is not correct.
Best regards,
Krzysztof
On Thu, 13 Apr 2023 12:25:03 +0800, Stanley Chang wrote:
> Add a new 'snps,global-regs-starting-offset' DT to dwc3 core to remap
> the global register start address
>
> The RTK DHC SoCs were designed the global register address offset at
> 0x8100. The default address is at DWC3_GLOBALS_REGS_START (0xc100).
> Therefore, add the property of device-tree to adjust this start address.
>
> Signed-off-by: Stanley Chang <[email protected]>
> ---
> v1 to v2 change:
> 1. Change the name of the property "snps,global-regs-starting-offset".
> ---
> Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/usb/snps,dwc3.yaml: properties:snps,global-regs-starting-offset: 'oneOf' conditional failed, one must be fixed:
'type' is a required property
hint: A vendor boolean property can use "type: boolean"
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/usb/snps,dwc3.yaml: properties:snps,global-regs-starting-offset: 'oneOf' conditional failed, one must be fixed:
'enum' is a required property
'const' is a required property
hint: A vendor string property with exact values has an implicit type
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/usb/snps,dwc3.yaml: properties:snps,global-regs-starting-offset: 'oneOf' conditional failed, one must be fixed:
'$ref' is a required property
'allOf' is a required property
hint: A vendor property needs a $ref to types.yaml
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
hint: Vendor specific properties must have a type and description unless they have a defined, common suffix.
from schema $id: http://devicetree.org/meta-schemas/vendor-props.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/[email protected]
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
> On 13/04/2023 06:25, Stanley Chang wrote:
> > Add a new 'snps,global-regs-starting-offset' DT to dwc3 core to remap
> > the global register start address
> >
> > The RTK DHC SoCs were designed the global register address offset at
> > 0x8100. The default address is at DWC3_GLOBALS_REGS_START (0xc100).
> > Therefore, add the property of device-tree to adjust this start address.
> >
> > Signed-off-by: Stanley Chang <[email protected]>
> > ---
> > v1 to v2 change:
> > 1. Change the name of the property "snps,global-regs-starting-offset".
> > ---
>
> Didn't you got already comment for this patch? How did you implement it?
>
> Also, I asked you multiple times:
>
> 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.
>
> I don't understand why you ignore this.
>
> NAK, patch is not correct.
>
> Best regards,
> Krzysztof
>
Thank you for your patient guidance.
Because I'm not familiar with the review process and didn't use scripts/get_maintainers.pl properly in the initial email thread.
Therefore, this series of errors was caused. Sorry for the confusion.
Now I know how to use the script properly.
After correcting the maintainer's suggestion, I'll restart a new email thread and review again.
On 13/04/2023 16:58, Stanley Chang[昌育德] wrote:
>> On 13/04/2023 06:25, Stanley Chang wrote:
>>> Add a new 'snps,global-regs-starting-offset' DT to dwc3 core to remap
>>> the global register start address
>>>
>>> The RTK DHC SoCs were designed the global register address offset at
>>> 0x8100. The default address is at DWC3_GLOBALS_REGS_START (0xc100).
>>> Therefore, add the property of device-tree to adjust this start address.
>>>
>>> Signed-off-by: Stanley Chang <[email protected]>
>>> ---
>>> v1 to v2 change:
>>> 1. Change the name of the property "snps,global-regs-starting-offset".
>>> ---
>>
>> Didn't you got already comment for this patch? How did you implement it?
>>
>> Also, I asked you multiple times:
>>
>> 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.
>>
>> I don't understand why you ignore this.
>>
>> NAK, patch is not correct.
>>
>> Best regards,
>> Krzysztof
>>
>
> Thank you for your patient guidance.
> Because I'm not familiar with the review process and didn't use scripts/get_maintainers.pl properly in the initial email thread.
> Therefore, this series of errors was caused. Sorry for the confusion.
> Now I know how to use the script properly.
> After correcting the maintainer's suggestion, I'll restart a new email thread and review again.
Did you respond to feedback you got about the property? Did reviewer
agreed on your view after your feedback?
If not, then why resending this patch?
Best regards,
Krzysztof
> >> Didn't you got already comment for this patch? How did you implement it?
> >>
> >> Also, I asked you multiple times:
> >>
> >> 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.
> >>
> >> I don't understand why you ignore this.
> >>
> >> NAK, patch is not correct.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >
> > Thank you for your patient guidance.
> > Because I'm not familiar with the review process and didn't use
> scripts/get_maintainers.pl properly in the initial email thread.
> > Therefore, this series of errors was caused. Sorry for the confusion.
> > Now I know how to use the script properly.
> > After correcting the maintainer's suggestion, I'll restart a new email thread
> and review again.
>
> Did you respond to feedback you got about the property? Did reviewer agreed
> on your view after your feedback?
>
> If not, then why resending this patch?
>
1. Because you said, "This patch is incorrect". And I won't be cc'ing the proper maintainer.
I think I need to restart a new review process.
2. Modify the previous reviewer's comments and fix the dtschema validation error.
Am I misunderstanding what you mean?
Can I keep reviewing this patch on this email thread until consensus is reached with the reviewers?
Thanks,
Stanley
On 14/04/2023 04:12, Stanley Chang[昌育德] wrote:
>
>>>> Didn't you got already comment for this patch? How did you implement it?
>>>>
>>>> Also, I asked you multiple times:
>>>>
>>>> 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.
>>>>
>>>> I don't understand why you ignore this.
>>>>
>>>> NAK, patch is not correct.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>> Thank you for your patient guidance.
>>> Because I'm not familiar with the review process and didn't use
>> scripts/get_maintainers.pl properly in the initial email thread.
>>> Therefore, this series of errors was caused. Sorry for the confusion.
>>> Now I know how to use the script properly.
>>> After correcting the maintainer's suggestion, I'll restart a new email thread
>> and review again.
>>
>> Did you respond to feedback you got about the property? Did reviewer agreed
>> on your view after your feedback?
>>
>> If not, then why resending this patch?
>>
>
> 1. Because you said, "This patch is incorrect". And I won't be cc'ing the proper maintainer.
> I think I need to restart a new review process.
> 2. Modify the previous reviewer's comments and fix the dtschema validation error.
>
> Am I misunderstanding what you mean?
> Can I keep reviewing this patch on this email thread until consensus is reached with the reviewers?
I guess confusion is because you never received response from Rob. I'll
reply there.
Best regards,
Krzysztof