* [v3 1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process"
@ 2024-05-17 17:49 Tom Rini
2024-05-17 17:49 ` [v3 2/2] doc: process.rst: Document device tree resync rules Tom Rini
2024-05-21 9:23 ` [v3 1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process" Quentin Schulz
0 siblings, 2 replies; 6+ messages in thread
From: Tom Rini @ 2024-05-17 17:49 UTC (permalink / raw
To: u-boot; +Cc: Heinrich Schuchardt
These sections which talk about the different phases of the development
process should be using the subsubheading identifier.
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
None
Changes in v2:
None
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
doc/develop/process.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 92477d05dd85..a66540a698c1 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -34,7 +34,7 @@ It is followed by a *Stabilization Period*.
The end of a Release Cycle is marked by the release of a new U-Boot version.
Merge Window
-------------
+^^^^^^^^^^^^
The Merge Window is the period when new patches get submitted (and hopefully
accepted) for inclusion into U-Boot mainline. This period lasts for 21 days (3
@@ -44,7 +44,7 @@ This is the only time when new code (like support for new processors or new
boards, or other new features or reorganization of code) is accepted.
Twilight Time
--------------
+^^^^^^^^^^^^^
Usually patches do not get accepted as they are - the peer review that takes
place will usually require changes and resubmissions of the patches before they
@@ -65,13 +65,13 @@ the Merge Window does not preclude patches that were already posted from being
merged for the upcoming release.
Stabilization Period
---------------------
+^^^^^^^^^^^^^^^^^^^^
During the Stabilization Period only patches containing bug fixes get
applied.
Corner Cases
-------------
+^^^^^^^^^^^^
Sometimes it is not clear if a patch contains a bug fix or not.
For example, changes that remove dead code, unused macros etc. or
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [v3 2/2] doc: process.rst: Document device tree resync rules
2024-05-17 17:49 [v3 1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process" Tom Rini
@ 2024-05-17 17:49 ` Tom Rini
2024-05-21 9:27 ` Quentin Schulz
2024-05-21 9:23 ` [v3 1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process" Quentin Schulz
1 sibling, 1 reply; 6+ messages in thread
From: Tom Rini @ 2024-05-17 17:49 UTC (permalink / raw
To: u-boot; +Cc: Heinrich Schuchardt, Quentin Schulz
Document the logic of when we do a full resync of the device trees used
by OF_UPSTREAM as well as that cherry-picking is allowed as needed.
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v3:
- Actually commit the changes I intended for v2
Changes in v2:
- Address Quentin's feedback
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Quentin Schulz <quentin.schulz@cherry.de>
---
doc/develop/devicetree/control.rst | 9 ++++++---
doc/develop/process.rst | 13 +++++++++++++
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index 4cc1457d4ea8..ca4fb0b5b10f 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -113,9 +113,12 @@ SoC being used via Kconfig and set `DEFAULT_DEVICE_TREE=<vendor>/<name>` when
prompted by Kconfig.
However, if `dts/upstream/` hasn't yet received devicetree source file for your
-newly added board support then you can add corresponding devicetree source file
-as `arch/<arch>/dts/<name>.dts`. To select that add `# CONFIG_OF_UPSTREAM is not
-set` and set `DEFAULT_DEVICE_TREE=<name>` when prompted by Kconfig.
+newly added board support then one option is that you can add the corresponding
+devicetree source file as `arch/<arch>/dts/<name>.dts`. To select that add `#
+CONFIG_OF_UPSTREAM is not set` and set `DEFAULT_DEVICE_TREE=<name>` when
+prompted by Kconfig. Another option is that you can use use the "pick" option of
+`dts/update-dts-subtree.sh` mentioned above to bring in the commits that you
+need.
This should include your CPU or SoC's devicetree file. On top of that any U-Boot
specific tweaks (see: :ref:`dttweaks`) can be made for your board.
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index a66540a698c1..0542b3fc1245 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -108,6 +108,19 @@ Differences to the Linux Development Process
In U-Boot, ``"-rc1"`` will only be released after all (or at least most of
the) patches that were submitted during the merge window have been applied.
+Resyncing of the device tree subtree
+------------------------------------
+
+As explained in :doc:`devicetree/control` some platforms make use of device tree
+files which come from a git subtree that mirrors the Linux Kernel sources
+itself. For our purposes, we only track releases and not release candidates for
+merging in our tree. These merges follow the normal merge window rules.
+
+In the case of specific changes, such as bug fixes or new platform support,
+these can be "cherry-picked" and are subject to the normal merge rules. For
+example, a bug fix can come in later in the window but a full re-sync only
+happens within the merge window itself.
+
.. _custodians:
Custodians
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [v3 1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process"
2024-05-17 17:49 [v3 1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process" Tom Rini
2024-05-17 17:49 ` [v3 2/2] doc: process.rst: Document device tree resync rules Tom Rini
@ 2024-05-21 9:23 ` Quentin Schulz
2024-05-21 16:36 ` Tom Rini
1 sibling, 1 reply; 6+ messages in thread
From: Quentin Schulz @ 2024-05-21 9:23 UTC (permalink / raw
To: Tom Rini, u-boot; +Cc: Heinrich Schuchardt
Hi Tom,
On 5/17/24 7:49 PM, Tom Rini wrote:
> These sections which talk about the different phases of the development
> process should be using the subsubheading identifier.
>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> Changes in v3:
> None
>
> Changes in v2:
> None
>
> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
> doc/develop/process.rst | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/doc/develop/process.rst b/doc/develop/process.rst
> index 92477d05dd85..a66540a698c1 100644
> --- a/doc/develop/process.rst
> +++ b/doc/develop/process.rst
> @@ -34,7 +34,7 @@ It is followed by a *Stabilization Period*.
> The end of a Release Cycle is marked by the release of a new U-Boot version.
>
> Merge Window
> -------------
> +^^^^^^^^^^^^
>
> The Merge Window is the period when new patches get submitted (and hopefully
> accepted) for inclusion into U-Boot mainline. This period lasts for 21 days (3
> @@ -44,7 +44,7 @@ This is the only time when new code (like support for new processors or new
> boards, or other new features or reorganization of code) is accepted.
>
> Twilight Time
> --------------
> +^^^^^^^^^^^^^
>
> Usually patches do not get accepted as they are - the peer review that takes
> place will usually require changes and resubmissions of the patches before they
> @@ -65,13 +65,13 @@ the Merge Window does not preclude patches that were already posted from being
> merged for the upcoming release.
>
> Stabilization Period
> ---------------------
> +^^^^^^^^^^^^^^^^^^^^
>
> During the Stabilization Period only patches containing bug fixes get
> applied.
>
> Corner Cases
> -------------
> +^^^^^^^^^^^^
>
> Sometimes it is not clear if a patch contains a bug fix or not.
> For example, changes that remove dead code, unused macros etc. or
Wondering if we shouldn't put:
Differences to the Linux Development Process
section under the "Phases of the development process" section as well?
Otherwise,
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [v3 2/2] doc: process.rst: Document device tree resync rules
2024-05-17 17:49 ` [v3 2/2] doc: process.rst: Document device tree resync rules Tom Rini
@ 2024-05-21 9:27 ` Quentin Schulz
2024-05-21 16:38 ` Tom Rini
0 siblings, 1 reply; 6+ messages in thread
From: Quentin Schulz @ 2024-05-21 9:27 UTC (permalink / raw
To: Tom Rini, u-boot; +Cc: Heinrich Schuchardt
Hi Tom,
On 5/17/24 7:49 PM, Tom Rini wrote:
> Document the logic of when we do a full resync of the device trees used
> by OF_UPSTREAM as well as that cherry-picking is allowed as needed.
>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> Changes in v3:
> - Actually commit the changes I intended for v2
>
> Changes in v2:
> - Address Quentin's feedback
>
> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Cc: Quentin Schulz <quentin.schulz@cherry.de>
> ---
> doc/develop/devicetree/control.rst | 9 ++++++---
> doc/develop/process.rst | 13 +++++++++++++
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
> index 4cc1457d4ea8..ca4fb0b5b10f 100644
> --- a/doc/develop/devicetree/control.rst
> +++ b/doc/develop/devicetree/control.rst
> @@ -113,9 +113,12 @@ SoC being used via Kconfig and set `DEFAULT_DEVICE_TREE=<vendor>/<name>` when
> prompted by Kconfig.
>
> However, if `dts/upstream/` hasn't yet received devicetree source file for your
> -newly added board support then you can add corresponding devicetree source file
> -as `arch/<arch>/dts/<name>.dts`. To select that add `# CONFIG_OF_UPSTREAM is not
> -set` and set `DEFAULT_DEVICE_TREE=<name>` when prompted by Kconfig.
> +newly added board support then one option is that you can add the corresponding
> +devicetree source file as `arch/<arch>/dts/<name>.dts`. To select that add `#
> +CONFIG_OF_UPSTREAM is not set` and set `DEFAULT_DEVICE_TREE=<name>` when
I don't like the wording here because it implies we should modify the
defconfig by hand, which nobody should ever do.
I could suggest:
"""
To do that, unselect `OF_UPSTREAM` and set `DEFAULT_DEVICE_TREE=<name>`
through a Kconfig tool (e.g. `menuconfig`).
"""
In any case, this is wording is not added in this patch, so I guess we
could fix it in another patch as well, making this remark not a "blocker".
> +prompted by Kconfig. Another option is that you can use use the "pick" option of
> +`dts/update-dts-subtree.sh` mentioned above to bring in the commits that you
> +need.
>
> This should include your CPU or SoC's devicetree file. On top of that any U-Boot
> specific tweaks (see: :ref:`dttweaks`) can be made for your board.
> diff --git a/doc/develop/process.rst b/doc/develop/process.rst
> index a66540a698c1..0542b3fc1245 100644
> --- a/doc/develop/process.rst
> +++ b/doc/develop/process.rst
> @@ -108,6 +108,19 @@ Differences to the Linux Development Process
> In U-Boot, ``"-rc1"`` will only be released after all (or at least most of
> the) patches that were submitted during the merge window have been applied.
>
> +Resyncing of the device tree subtree
> +------------------------------------
> +
> +As explained in :doc:`devicetree/control` some platforms make use of device tree
> +files which come from a git subtree that mirrors the Linux Kernel sources
> +itself. For our purposes, we only track releases and not release candidates for
> +merging in our tree. These merges follow the normal merge window rules.
> +
> +In the case of specific changes, such as bug fixes or new platform support,
> +these can be "cherry-picked" and are subject to the normal merge rules. For
> +example, a bug fix can come in later in the window but a full re-sync only
> +happens within the merge window itself.
> +
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks,
Quentin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [v3 1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process"
2024-05-21 9:23 ` [v3 1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process" Quentin Schulz
@ 2024-05-21 16:36 ` Tom Rini
0 siblings, 0 replies; 6+ messages in thread
From: Tom Rini @ 2024-05-21 16:36 UTC (permalink / raw
To: Quentin Schulz; +Cc: u-boot, Heinrich Schuchardt
[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]
On Tue, May 21, 2024 at 11:23:01AM +0200, Quentin Schulz wrote:
> Hi Tom,
>
> On 5/17/24 7:49 PM, Tom Rini wrote:
> > These sections which talk about the different phases of the development
> > process should be using the subsubheading identifier.
> >
> > Signed-off-by: Tom Rini <trini@konsulko.com>
> > ---
> > Changes in v3:
> > None
> >
> > Changes in v2:
> > None
> >
> > Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > ---
> > doc/develop/process.rst | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/doc/develop/process.rst b/doc/develop/process.rst
> > index 92477d05dd85..a66540a698c1 100644
> > --- a/doc/develop/process.rst
> > +++ b/doc/develop/process.rst
> > @@ -34,7 +34,7 @@ It is followed by a *Stabilization Period*.
> > The end of a Release Cycle is marked by the release of a new U-Boot version.
> > Merge Window
> > -------------
> > +^^^^^^^^^^^^
> > The Merge Window is the period when new patches get submitted (and hopefully
> > accepted) for inclusion into U-Boot mainline. This period lasts for 21 days (3
> > @@ -44,7 +44,7 @@ This is the only time when new code (like support for new processors or new
> > boards, or other new features or reorganization of code) is accepted.
> > Twilight Time
> > --------------
> > +^^^^^^^^^^^^^
> > Usually patches do not get accepted as they are - the peer review that takes
> > place will usually require changes and resubmissions of the patches before they
> > @@ -65,13 +65,13 @@ the Merge Window does not preclude patches that were already posted from being
> > merged for the upcoming release.
> > Stabilization Period
> > ---------------------
> > +^^^^^^^^^^^^^^^^^^^^
> > During the Stabilization Period only patches containing bug fixes get
> > applied.
> > Corner Cases
> > -------------
> > +^^^^^^^^^^^^
> > Sometimes it is not clear if a patch contains a bug fix or not.
> > For example, changes that remove dead code, unused macros etc. or
>
> Wondering if we shouldn't put:
>
> Differences to the Linux Development Process
>
> section under the "Phases of the development process" section as well?
I don't know. I thought not when I first did this patch. I still thought
not as I started this reply. And then I re-read the section again and,
well, maybe? Or maybe it would be better to integrate the contents of
that section in to other sections, and rework it a bit too as it's not
quite correct either. For example, I feel like the majority of new
patches posted in the merge window (even at the start) end up in the
upcoming next branch.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [v3 2/2] doc: process.rst: Document device tree resync rules
2024-05-21 9:27 ` Quentin Schulz
@ 2024-05-21 16:38 ` Tom Rini
0 siblings, 0 replies; 6+ messages in thread
From: Tom Rini @ 2024-05-21 16:38 UTC (permalink / raw
To: Quentin Schulz; +Cc: u-boot, Heinrich Schuchardt
[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]
On Tue, May 21, 2024 at 11:27:36AM +0200, Quentin Schulz wrote:
> Hi Tom,
>
> On 5/17/24 7:49 PM, Tom Rini wrote:
> > Document the logic of when we do a full resync of the device trees used
> > by OF_UPSTREAM as well as that cherry-picking is allowed as needed.
> >
> > Signed-off-by: Tom Rini <trini@konsulko.com>
> > ---
> > Changes in v3:
> > - Actually commit the changes I intended for v2
> >
> > Changes in v2:
> > - Address Quentin's feedback
> >
> > Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > Cc: Quentin Schulz <quentin.schulz@cherry.de>
> > ---
> > doc/develop/devicetree/control.rst | 9 ++++++---
> > doc/develop/process.rst | 13 +++++++++++++
> > 2 files changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
> > index 4cc1457d4ea8..ca4fb0b5b10f 100644
> > --- a/doc/develop/devicetree/control.rst
> > +++ b/doc/develop/devicetree/control.rst
> > @@ -113,9 +113,12 @@ SoC being used via Kconfig and set `DEFAULT_DEVICE_TREE=<vendor>/<name>` when
> > prompted by Kconfig.
> > However, if `dts/upstream/` hasn't yet received devicetree source file for your
> > -newly added board support then you can add corresponding devicetree source file
> > -as `arch/<arch>/dts/<name>.dts`. To select that add `# CONFIG_OF_UPSTREAM is not
> > -set` and set `DEFAULT_DEVICE_TREE=<name>` when prompted by Kconfig.
> > +newly added board support then one option is that you can add the corresponding
> > +devicetree source file as `arch/<arch>/dts/<name>.dts`. To select that add `#
> > +CONFIG_OF_UPSTREAM is not set` and set `DEFAULT_DEVICE_TREE=<name>` when
>
> I don't like the wording here because it implies we should modify the
> defconfig by hand, which nobody should ever do.
>
> I could suggest:
> """
> To do that, unselect `OF_UPSTREAM` and set `DEFAULT_DEVICE_TREE=<name>`
> through a Kconfig tool (e.g. `menuconfig`).
> """
>
> In any case, this is wording is not added in this patch, so I guess we could
> fix it in another patch as well, making this remark not a "blocker".
Yes, I agree that would be a better way to explain things here.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-05-21 16:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-05-17 17:49 [v3 1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process" Tom Rini
2024-05-17 17:49 ` [v3 2/2] doc: process.rst: Document device tree resync rules Tom Rini
2024-05-21 9:27 ` Quentin Schulz
2024-05-21 16:38 ` Tom Rini
2024-05-21 9:23 ` [v3 1/2] doc: process.rst: Use subsubheading for "Phases of the Development Process" Quentin Schulz
2024-05-21 16:36 ` Tom Rini
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.