Message ID | 20230414004455.19275-1-dipenp@nvidia.com (mailing list archive) |
---|---|
Headers | show |
Series | Add Tegra234 HTE support | expand |
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. Best regards, Krzysztof
On Fri, Apr 14, 2023 at 9:36 AM Krzysztof Kozlowski <krzysztof.kozlowski@linaro.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
On Fri, Apr 14, 2023 at 09:36:15AM +0200, Krzysztof Kozlowski 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. I used to get this wrong as well because I didn't know (or perhaps it didn't exist yet at the time) --reroll-count|-v and used to manually override --subject-prefix. Thierry
On 4/14/23 12:36 AM, Krzysztof Kozlowski 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. My bad...excitement of sending the patch series got hold of me :) Now I have realized it is been happening since the beginning. Since all the previous patches have been sent without PATCH prefix, is it ok for this version as it is or do you want me to resend with proper prefix? > > Best regards, > Krzysztof >
On 4/14/23 1:07 AM, Linus Walleij wrote: > On Fri, Apr 14, 2023 at 9:36 AM Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.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 Thanks for sharing...will have to look into it to avoid such mistakes. > > 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
On 14/04/2023 19:14, Dipen Patel wrote: > On 4/14/23 12:36 AM, Krzysztof Kozlowski 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. > > My bad...excitement of sending the patch series got hold of me :) Now I have realized > it is been happening since the beginning. Since all the previous patches have been > sent without PATCH prefix, is it ok for this version as it is or do you want me to resend > with proper prefix? > It's okay for me, no need to resend. I just wanted to bring this to your attention, so future patchsets can be improved. Best regards, Krzysztof