Samsung ARM/ARM64 SoCs (except legacy S5PV210) are also expected not to
bring any new dtbs_check warnings. In fact this have been already
enforced and tested since few release.
Cc: Conor Dooley <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
Not sure where to document this. Creating new maintainer profile for
Samsung SoC would be an overkill. OTOH, more SoCs might want to grow
this list, so this also scales poor.
---
Documentation/process/maintainer-soc.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
index 49f08289d62c..12637530d68f 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -133,8 +133,8 @@ with the dt-bindings that describe the ABI. Please read the section
more information on the validation of devicetrees.
For new platforms, or additions to existing ones, ``make dtbs_check`` should not
-add any new warnings. For RISC-V, as it has the advantage of being a newer
-architecture, ``make dtbs_check W=1`` is required to not add any new warnings.
+add any new warnings. For RISC-V and Samsung SoC, ``make dtbs_check W=1`` is
+required to not add any new warnings.
If in any doubt about a devicetree change, reach out to the devicetree
maintainers.
--
2.34.1
On Wed, Jul 12, 2023 at 10:41:31AM +0200, Krzysztof Kozlowski wrote:
> Samsung ARM/ARM64 SoCs (except legacy S5PV210) are also expected not to
> bring any new dtbs_check warnings. In fact this have been already
> enforced and tested since few release.
>
> Cc: Conor Dooley <[email protected]>
> Signed-off-by: Krzysztof Kozlowski <[email protected]>
>
> ---
> Not sure where to document this. Creating new maintainer profile for
> Samsung SoC would be an overkill. OTOH, more SoCs might want to grow
> this list, so this also scales poor.
To me, this portion of the document was "information to the
submaintainer", which would be you, not information to the contributors
to the platform. Adding the comment about Samsung SoC seems aimed at
contributors?
I added the bit about W=1 on RISC-V since there are multiple
sub-maintainers there.
> ---
> Documentation/process/maintainer-soc.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
> index 49f08289d62c..12637530d68f 100644
> --- a/Documentation/process/maintainer-soc.rst
> +++ b/Documentation/process/maintainer-soc.rst
> @@ -133,8 +133,8 @@ with the dt-bindings that describe the ABI. Please read the section
> more information on the validation of devicetrees.
>
> For new platforms, or additions to existing ones, ``make dtbs_check`` should not
> -add any new warnings. For RISC-V, as it has the advantage of being a newer
> -architecture, ``make dtbs_check W=1`` is required to not add any new warnings.
> +add any new warnings. For RISC-V and Samsung SoC, ``make dtbs_check W=1`` is
> +required to not add any new warnings.
> If in any doubt about a devicetree change, reach out to the devicetree
> maintainers.
>
> --
> 2.34.1
>
On 12/07/2023 11:48, Conor Dooley wrote:
> On Wed, Jul 12, 2023 at 10:41:31AM +0200, Krzysztof Kozlowski wrote:
>> Samsung ARM/ARM64 SoCs (except legacy S5PV210) are also expected not to
>> bring any new dtbs_check warnings. In fact this have been already
>> enforced and tested since few release.
>>
>> Cc: Conor Dooley <[email protected]>
>> Signed-off-by: Krzysztof Kozlowski <[email protected]>
>>
>> ---
>
>> Not sure where to document this. Creating new maintainer profile for
>> Samsung SoC would be an overkill. OTOH, more SoCs might want to grow
>> this list, so this also scales poor.
>
> To me, this portion of the document was "information to the
> submaintainer", which would be you, not information to the contributors
> to the platform. Adding the comment about Samsung SoC seems aimed at
> contributors?
Yes, I want to document it for contributors, so they won't be surprised.
Any hints where to store it? I could put it in the "About" tab of my
kernel.org repo, but no one checks this for contribution guidelines.
Best regards,
Krzysztof
On Wed, Jul 12, 2023 at 01:46:20PM +0200, Krzysztof Kozlowski wrote:
> On 12/07/2023 11:48, Conor Dooley wrote:
> > On Wed, Jul 12, 2023 at 10:41:31AM +0200, Krzysztof Kozlowski wrote:
> >> Samsung ARM/ARM64 SoCs (except legacy S5PV210) are also expected not to
> >> bring any new dtbs_check warnings. In fact this have been already
> >> enforced and tested since few release.
> >>
> >> Cc: Conor Dooley <[email protected]>
> >> Signed-off-by: Krzysztof Kozlowski <[email protected]>
> >>
> >> ---
> >
> >> Not sure where to document this. Creating new maintainer profile for
> >> Samsung SoC would be an overkill. OTOH, more SoCs might want to grow
> >> this list, so this also scales poor.
> >
> > To me, this portion of the document was "information to the
> > submaintainer", which would be you, not information to the contributors
> > to the platform. Adding the comment about Samsung SoC seems aimed at
> > contributors?
>
> Yes, I want to document it for contributors, so they won't be surprised.
> Any hints where to store it? I could put it in the "About" tab of my
> kernel.org repo, but no one checks this for contribution guidelines.
I've not got a better suggestion for where to put this, but under
something labelled as "Information for (new) Submaintainers" isn't
where I would be looking as a contributor.
Is adding to the generic DT documentation that dtbs_check should not add
any new warnings at W=1 too extreme?
writing-schema.rst has the instructions about how to run dtbs_check while
writing dt-binding patches, but we don't seem to have any docs about
running dtbs_check for dts/dtsi changes.
On 12/07/2023 14:34, Conor Dooley wrote:
> On Wed, Jul 12, 2023 at 01:46:20PM +0200, Krzysztof Kozlowski wrote:
>> On 12/07/2023 11:48, Conor Dooley wrote:
>>> On Wed, Jul 12, 2023 at 10:41:31AM +0200, Krzysztof Kozlowski wrote:
>>>> Samsung ARM/ARM64 SoCs (except legacy S5PV210) are also expected not to
>>>> bring any new dtbs_check warnings. In fact this have been already
>>>> enforced and tested since few release.
>>>>
>>>> Cc: Conor Dooley <[email protected]>
>>>> Signed-off-by: Krzysztof Kozlowski <[email protected]>
>>>>
>>>> ---
>>>
>>>> Not sure where to document this. Creating new maintainer profile for
>>>> Samsung SoC would be an overkill. OTOH, more SoCs might want to grow
>>>> this list, so this also scales poor.
>>>
>>> To me, this portion of the document was "information to the
>>> submaintainer", which would be you, not information to the contributors
>>> to the platform. Adding the comment about Samsung SoC seems aimed at
>>> contributors?
>>
>> Yes, I want to document it for contributors, so they won't be surprised.
>> Any hints where to store it? I could put it in the "About" tab of my
>> kernel.org repo, but no one checks this for contribution guidelines.
>
> I've not got a better suggestion for where to put this, but under
> something labelled as "Information for (new) Submaintainers" isn't
> where I would be looking as a contributor.
Yeah, true.
> Is adding to the generic DT documentation that dtbs_check should not add
> any new warnings at W=1 too extreme?
It is to extreme. Several sub-arch maintainers might prioritize features
than DT schema compliance. I would say it is their choice, even if I
don't agree with it.
> writing-schema.rst has the instructions about how to run dtbs_check while
> writing dt-binding patches, but we don't seem to have any docs about
> running dtbs_check for dts/dtsi changes.
Maybe I will add generic maintainer-sub-arch-soc profile doc which then
can be linked by multiple soc subsystems.
Best regards,
Krzysztof