Re: [GIT PULL] ARM: tegra: Changes for v2023.10-rc1

[Thierry Reding <thierry.reding@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5030 bytes --]

On Tue, Aug 22, 2023 at 08:16:29AM +0300, Svyatoslav Ryhel wrote:
> 
> 
> 18 серпня 2023 р. 20:04:47 GMT+03:00, Tom Rini <trini@konsulko.com> написав(-ла):
> >On Fri, Aug 18, 2023 at 08:02:30PM +0300, Svyatoslav Ryhel wrote:
> >> 
> >> 
> >> 18 серпня 2023 р. 19:49:43 GMT+03:00, Tom Rini <trini@konsulko.com> написав(-ла):
> >> >On Fri, Aug 18, 2023 at 03:39:22PM +0200, Thierry Reding wrote:
> >> >
> >> >> From: Thierry Reding <treding@nvidia.com>
> >> >> 
> >> >> Hi Tom,
> >> >> 
> >> >> The following changes since commit 68c07fc5fdf34f0926cf06fc0c4ebd6f2f3afe19:
> >> >> 
> >> >>   Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2023-06-21 14:42:50 -0400)
> >> >> 
> >> >> are available in the Git repository at:
> >> >> 
> >> >>   git@source.denx.de:u-boot/custodians/u-boot-tegra.git tags/tegra-for-2023.10-rc1
> >> >
> >> >FYI, in your .git/config you can do:
> >> >	url = https://source.denx.de/u-boot/custodians/u-boot-tegra.git
> >> >	pushurl = git@source.denx.de:u-boot/custodians/u-boot-tegra.git
> >> >
> >> >And this part looks "nicer".  Not a big deal, just an FYI.
> >> >
> >> >> for you to fetch changes up to bdf9dead86f06c7d6980c399a4a6339430b531ec:
> >> >> 
> >> >>   board: htc: endeavoru: add One X support (2023-06-30 15:20:37 +0200)
> >> >> 
> >> >> This passes CI successfully:
> >> >> 
> >> >>   https://source.denx.de/u-boot/custodians/u-boot-tegra/-/pipelines/17411
> >> >> 
> >> >> Thanks,
> >> >> Thierry
> >> >> 
> >> >> ----------------------------------------------------------------
> >> >> ARM: tegra: Changes for v2023.10-rc1
> >> >> 
> >> >> This adds support for various new Tegra30 boards (ASUS, LG and HTC) and
> >> >> has some other minor enhancements, such as enabling the poweroff command
> >> >> on several Tegra210 and Tegra186 boards.
> >> >> 
> >> >> ----------------------------------------------------------------
> >> >> Jonas Schwöbel (1):
> >> >>       configs: tegra-common-post: make PXE and DHCP boot targets optional
> >> >> 
> >> >> Svyatoslav Ryhel (6):
> >> >>       configs: tegra-common-post: add GPIO keyboard as STDIN device
> >> >>       ARM: tegra: add SoC UID calculation function
> >> >>       board: asus: transformer: add ASUS Transformer T30 family support
> >> >>       board: asus: grouper: add Google Nexus 7 (2012) support
> >> >>       board: lg: x3: add Optimus 4X HD and Optimus Vu support
> >> >>       board: htc: endeavoru: add One X support
> >> >> 
> >> >> Thierry Reding (2):
> >> >>       ARM: tegra: Enable poweroff command on Jetson TX1 and Jetson Nano
> >> >>       ARM: tegra: Enable poweroff command on Jetson TX2
> >> >> 
> >> >> Tomasz Maciej Nowak (1):
> >> >>       ARM: dts: trimslice: sync SPI node with Linux dts
> >> >
> >> >Since I'm not sure if this is v8 or v9, given when v9 was posted, I've
> >> >applied this PR now, as I had said I wanted this in.  I do have two
> >> >requests for you Svyatoslav, however.  First, if there's changes that
> >> >are missing in master, please post those ASAP and we'll get them in, for
> >> >v2023.10. 
> >> 
> >> Patches Thierry applied are v8, while v9 has significant improvements.
> >
> >OK, I've updated patchwork to try and reflect this too.
> >
> 
> Merged patches are not the most recent I have sent. How to fix this?

Usually once something has been merged it's difficult to back it out. So
unless Tom can (and is willing to) somehow redo the merge with the
newest patches, you're going to have to rebase what you have and send
out as follow-up patches.

That's one of the reasons why you shouldn't keep sending new versions of
patches once things have settled down and there haven't been any more
review comments on the list. The assumption is that when you send
patches out you think they are all done. They may still need to be
updated based on review comments and that's fine because there's
communication on the mailing list to indicate so. Once discussions have
stopped it is assumed that the patches are done. This doesn't
necessarily mean that they get picked up right away, because people
might be busy.

The prudent thing to do in such cases, in my experience, is to leave the
patches as-is and do any subsequent changes in follow-up patches. If you
quickly notice that there will need to be more changes, then let people
know as soon as possible, otherwise they may apply patches and run tests
on them, all of which will have to be redone if you repost a new version
later on.

In this particular case I was in the process of preparing the pull
request to Tom and didn't see v9 until I had sent out the PR.

Depending on who you're sending patches to the "point of no return"
could be a lot sooner. Once patches are applied to a custodian tree and
other patches have been applied on top, switching out new versions of
patches can become really messy. Once they hit the mainline it often
becomes impossible.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]