Re: [PATCH v2 2/4] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, May 16, 2022 at 12:01 AM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:
>
> On 13/05/2022 18:59, Douglas Anderson wrote:
> > This copy-pastes compatibles from sc7180-based boards from the device
> > trees to the yaml file so that `make dtbs_check` will be happy.
> >
> > NOTES:
> > - I make no attempt to try to share an "item" for all sc7180 based
> >   Chromebooks. Because of the revision matching scheme used by the
> >   Chromebook bootloader, at times we need a different number of
> >   revisions listed.
> > - Some of the odd entries in here (like google,homestar-rev23 or the
> >   fact that "Google Lazor Limozeen without Touchscreen" changed from
> >   sku5 to sku6) are not typos but simply reflect reality.
> > - Many revisions of boards here never actually went to consumers, but
> >   they are still in use within various companies that were involved in
> >   Chromebook development. Since Chromebooks are developed with an
> >   "upstream first" methodology, having these revisions supported with
> >   upstream Linux is important. Making it easy for Chromebooks to be
> >   developed with an "upstream first" methodology is valuable to the
> >   upstream community because it improves the quality of upstream and
> >   gets Chromebooks supported with vanilla upstream faster.
> >
> > This patch also adds a link to the Chromebook boot flow documentation
> > to explain that Chromebooks don't use the scheme described for the
> > Qualcomm bootloader.
> >
> > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
> > ---
> > The link added here will (obviously) not function until the
> > documentation patch makes it to mainline. Presumably folks who want to
> > read it in the meantime can find it pretty easily. If there's a better
> > way to link this then please let me know.
> >
> > Changes in v2:
> > - Add link to doc about how Chromebook devicetrees work.
> > - Use a "description" instead of a comment for each item.
> > - Use the marketing name instead of the code name where possible.
> >
> >  .../devicetree/bindings/arm/qcom.yaml         | 187 +++++++++++++++++-
> >  1 file changed, 186 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> > index 5c06d1bfc046..8ec0805f4996 100644
> > --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> > @@ -90,6 +90,11 @@ description: |
> >    A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
> >    foundry 2.
> >
> > +  There are many devices in the list below that run the standard ChromeOS
> > +  bootloader setup and use the open source depthcharge bootloader to boot the
> > +  OS. These devices do not use the scheme described above. For details, see:
> > +  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/chromebook-boot-flow.rst
>
> Absolute path within Linux repo, please, so
> "Documentation/devicetree/chromebook-boot-flow.rst" (assuming that will
> be the final location). There are tools which check them for validity.

Got it, thanks!


> Actually this change should be rather part of that other commit...

I'm not sure I understand. Which of these are you suggesting?

1. You want me to squash the two commits into one, so we add the
generic doc in the same patch as the one adding sc7180 Chromebooks.

2. You want the generic doc to come first in the series and it just
adds the little blurb into
"Documentation/devicetree/bindings/arm/qcom.yaml" even though
Chromebooks aren't actually added until a later commit in the series.

3. You want to add the sc7180 Chromebooks first in the series with no
documentation and then later add in the generic documentation and the
blurb into "Documentation/devicetree/bindings/arm/qcom.yaml".


I'm also interested to know if you think the generic documentation
patch should land through the Qualcomm tree. I think it would
absolutely have to if I take your suggestion, right?


Thanks!

-Doug



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux