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 <tr...@konsulko.com>
> > ---
> > Changes in v3:
> > - Actually commit the changes I intended for v2
> > 
> > Changes in v2:
> > - Address Quentin's feedback
> > 
> > Cc: Heinrich Schuchardt <xypron.g...@gmx.de>
> > Cc: Quentin Schulz <quentin.sch...@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: signature.asc
Description: PGP signature

Reply via email to