[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdY6R9WvwOr3mVgrJcf9dVB4s13eu8juZkBt0Q+=gg2G2w@mail.gmail.com>
Date: Fri, 14 Apr 2023 10:07:33 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Dipen Patel <dipenp@...dia.com>, thierry.reding@...il.com,
jonathanh@...dia.com, linux-kernel@...r.kernel.org,
linux-tegra@...r.kernel.org, linux-gpio@...r.kernel.org,
devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
robh+dt@...nel.org, timestamp@...ts.linux.dev,
krzysztof.kozlowski+dt@...aro.org, brgl@...ev.pl, corbet@....net,
gregkh@...uxfoundation.org,
Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Subject: Re: [V6 0/9] Add Tegra234 HTE support
On Fri, Apr 14, 2023 at 9:36 AM Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
> On 14/04/2023 02:44, Dipen Patel wrote:
> > This patch series mainly adds support for the Tegra234 HTE provider. In
> > addition, it addresses dt binding comments which prompted code
> > changes in the existing HTE provider driver without breaking the
> > Tegra194 provider. The comments raised concern how existing code
> > retrieves gpio controller node
> > (the node is used to help namespace conversion between HTE and GPIOLIB).
> > To help simplify that process, new DT property is suggested which adds
> > gpio controller node in the HTE provider binding as phandle property. To
> > conlude this patch series:
> > - adds Tegra234 HTE provider
> > - modifies existing provider code to address new dt binding for Tegra234
> > without breaking it for the Tegra194 chip.
> >
> > The V1 patch series:
> > - Adds tegra Tegra234 HTE(timestamp) provider supports.
> > - Updates MAINTAINERS file for git tree, mail list fields.
> > - Updates devicetree and API documentations.
> > - Enables HTE subsystem, Tegra194 and Tegra234 HTE providers
> > by default in arm64 defconfig and dts files.
>
> All your emails miss PATCH prefix. Use `git format-patch` to generate
> proper versioned patch. Stripping important part messes up with our
> filters. We have quite a lot of emails, so proper filtering is important.
At this point I would even recommend kernel maintainers to get b4
into the workflow:
https://people.kernel.org/monsieuricon/sending-a-kernel-patch-with-b4-part-1
This tool will also implement other desired behaviours and version
the patch set for you.
I am gradually adopting it for my own work, using it all the time when
applying patches but also getting better at using it for submitting
them. It has a small overhead (like learning and memorizing the
subcommands) but once you get used to it, it is really helpful.
Yours,
Linus Walleij
Powered by blists - more mailing lists