On Tue, Aug 22, 2023 at 08:16:29AM +0300, Svyatoslav Ryhel wrote: > > > 18 серпня 2023 р. 20:04:47 GMT+03:00, Tom Rini <tr...@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 <tr...@konsulko.com> > >> написав(-ла): > >> >On Fri, Aug 18, 2023 at 03:39:22PM +0200, Thierry Reding wrote: > >> > > >> >> From: Thierry Reding <tred...@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: > >> >> > >> >> g...@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 = g...@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
signature.asc
Description: PGP signature