Re: Imminent rebase of pdx86 trees to v7.2-rc2

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

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

On Tue, 7 Jul 2026, Uwe Kleine-König wrote:
> On Mon, Jul 06, 2026 at 06:02:11PM +0300, Andy Shevchenko wrote:
> > On Mon, Jul 06, 2026 at 12:37:36PM +0200, Uwe Kleine-König wrote:
> > > On Mon, Jul 06, 2026 at 11:48:18AM +0300, Ilpo Järvinen wrote:
> > > > Because of the recent mid-rc-cycle merge of the rework for 
> > > > mod_devicetable.h in d2c9a99135da ("Merge tag 'device-id-rework' of 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux"), I'll be 
> > > > (re)basing our pdx86 tree on top of v7.2-rc2.
> > > 
> > > Probably to late now, but I guess merging v7.2-rc2 into your tree to
> > > handle (potential?) merge conflicts would have been the solution that
> > > doesn't involve a rebase.
> > 
> > Rebases are cleaner in this situation.
> 
> Yes, a rebase yields a cleaner result, but less history and more hassle
> for your downstreams. The tree being used by downstream developers and
> Ilpo's urge to notify them for this rebase, would be a strong indicator
> for me to not rebase but to pull in v7.2-rc2 (or only the
> device-id-rework tag).

No. It's a strong indicator your header refactoring shouldn't have been 
merged mid-rc-cycle but now you also try to say I shouldn't try to cope 
with the cards I've been dealt with the way I see best... :-(

We do occasionally force pushes anyway so this is not something as 
extraordinary as you seem to think. I didn't write this notification 
mainly because of the rebase but to warn about the include changes which 
may result in conflicts unless the submissions are based on late enough 
commit in my tree.

Merging -rc2 backwards removes degrees of freedom from me when it comes 
to patches I've accepted before that merge. It also makes history less 
clean (which also you acknowledge).

> Looking at next-20260706 (where drivers-x86 is
> ff7836fa850c2f815bc219f1e48f6ec8699f4ae7 which is still based on v7.2-rc1) and
> 
> 	https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git review-ilpo-next
> 
> (51a153f2747fad5dc566f94238b08da07d6a6fb6, based on v7.2-rc2), I wonder
> if just doing nothing would have been the right approach:
> 
> 	$ git range-diff linus/master..ff7836fa850c2f815bc219f1e48f6ec8699f4ae7 linus/master..51a153f2747fad5dc566f94238b08da07d6a6fb6
> 	 1:  4799d6229436 =  1:  7bc99dff4d97 platform/x86: asus-armoury: gate PPT writes behind active fan curve
> 	 2:  2f70f3d2fd3d =  2:  27ef0cdcdc20 platform/x86: msi-ec: Add MSI Raider A18 HX A9WJG EC firmware
> 	 3:  2d79283eec8d =  3:  63af040b0b40 platform/x86: uniwill-laptop: Add keyboard backlight support
> 	 4:  c7f3d21c8f50 =  4:  69be0016c161 platform/x86: uniwill-laptop: Handle screen-related events
> 	 5:  e8a41051b95b =  5:  c393505bab5b platform/x86: uniwill-laptop: Add AC auto boot support
> 	 6:  58d88f08ab1f =  6:  e02c8d7a197d platform/x86: uniwill-laptop: Add support for USB powershare
> 	 7:  c1c6633e3f1f =  7:  e76799915b86 platform/x86: uniwill-laptop: Add support for the MACHENIKE L16 Pro
> 	 8:  62f334005d59 =  8:  efd0636aaedb platform/x86: uniwill-laptop: Add support for the AiStone X4SP4NAL
> 	 9:  e451ae739a2c =  9:  866e728b489b platform/x86: uniwill-laptop: Add lightbar support for LAPQC71A/B
> 	10:  385bf4f87b05 = 10:  e5a316220dae platform/x86: hp-wmi: Introduce board-specific feature data
> 	11:  9ed0f2562f9a = 11:  c1ce649189ed platform/x86: hp-wmi: Drive fan control from board data
> 	12:  5417f92a1d46 = 12:  c95f61d198c7 platform/x86: hp-wmi: Add Victus 15-fb0xxx support
> 	13:  a3ec96c8b7bc = 13:  dd26a15b1d28 platform/x86: dell-privacy: Fix race condition
> 	14:  f58553cda9aa = 14:  16e2c381d72c platform/x86: dell-wmi-base: Fix resource leak on module load failure
> 	15:  cfe467c730f6 = 15:  530a2dd4ee84 platform/x86: dell-wmi-base: Fix handling of ultra performance key
> 	16:  74850eb0012b = 16:  356f771f3a4a platform/x86: dell-ddv: Use no_free_ptr() to simplify error handling
> 	17:  43a862be3002 = 17:  3488f4727898 platform/x86: msi-wmi: Reformat msi_wmi_notify()
> 	18:  0c716d1848ac = 18:  41cd652e1b8f platform/x86: msi-wmi: Add MSI Claw M-Center keys
> 	19:  0df706e5e724 = 19:  9e560f6761e3 platform/x86: dell-wmi-sysman: Don't hex dump attribute security buffer
> 	20:  ace16d4d3f38 = 20:  e05f35070d27 platform/x86: lenovo/ymc: Only match lower byte in WMI lid switch query response
> 	21:  d3f2ecd21924 = 21:  bfd4586c8458 platform/surface: aggregator: Consistently define ssam_device_ids using named initializers
> 	22:  2f0fab3e8ef9 = 22:  be3e8304fc35 power: supply: surface_{battery,charger}: Consistently define ssam_device_ids using named initializers
> 	23:  f3aaddb8a085 = 23:  67444032146a platform/x86: toshiba_bluetooth: Use more common error handling code in toshiba_bt_rfkill_probe()
> 	24:  f820f61f079a = 24:  258da36b410d platform/x86/amd/hsmp: Validate ACPI UID before parsing socket index
> 	25:  1cacf5e8693d = 25:  18506e66652e platform/x86/amd/hsmp: Validate _DSD mailbox sub-package element count
> 	26:  0c963c5b4d68 = 26:  dabf39aac670 platform/x86/amd/hsmp: Pass struct device explicitly to ACPI mailbox parsers
> 	27:  ff7836fa850c = 27:  67e753cf0448 platform/x86/amd/hsmp: Gate the data plane on a fully initialized socket
> 	 -:  ------------ > 28:  d8258e35a542 platform/x86: asus-laptop: Stop setting acpi_device_name/class()
> 	 -:  ------------ > 29:  c327e5c90164 platform/x86: eeepc-laptop: Stop setting acpi_device_name/class()
> 	 -:  ------------ > 30:  c0948dcbc48a platform/x86: fujitsu-laptop: Stop setting acpi_device_name/class()
> 	 -:  ------------ > 31:  852a85c15a7f platform/x86: fujitsu-tablet: Stop setting acpi_device_name/class()
> 	 -:  ------------ > 32:  fc0ed8545cb0 platform/x86: thinkpad_acpi: Stop setting acpi_device_class()
> 	 -:  ------------ > 33:  68a04fe822ac platform/x86: panasonic-laptop: Stop setting acpi_device_name/class()
> 	 -:  ------------ > 34:  d3d6f7e72a77 platform/x86: sony-laptop: Stop setting acpi_device_class()
> 	 -:  ------------ > 35:  5fec95ebc3ad platform/x86: toshiba_acpi: Do not use uninitialized device_class
> 	 -:  ------------ > 36:  a3fbc0114add platform/x86: toshiba_haps: Do not use uninitialized device_class
> 	 -:  ------------ > 37:  90a0805bc911 platform/x86: xo15-ebook: Stop setting acpi_device_name/class()
> 	 -:  ------------ > 38:  51a153f2747f platform/x86: topstar-laptop: Stop setting acpi_device_name/class()
> 
> The rebase went cleanly without any change, and ...
> 
> 	$ git log -G'#include' 67e753cf0448..51a153f2747f
> 	$
> 
> the patches on top of the cleanly rebased ones don't touch any include
> stuff.
>
> As long as no patches should be applied that actually depend on the
> rework that went into -rc2, I would have just continued with my branch
> on top of -rc1.
> To handle the anxiety that the rework might break something in my
> branch, I'd just merge -rc2, test, and if nothing relevant is found, I'd
> just throw away the test merge again.

It's not just about the patches already there... (I probably haven't yet 
processed that many patches that are more prone to add includes.)

In pdx86 world, we actually try to force people add includes for 
everything they use. Even those which would come through some other 
include which is not what many reviewers/maintainers actively enforce. 
It's because missing them makes refactoring headers even more painful than 
it is because of the build fail landmines awaiting (I think you 
encountered one or two of such cases too during your refactoring). As 
such, I expect there to be more churn in the includes block than many 
other trees might have.

I've done this so that I catch include conflicts while merging. A 
throwaway merge wouldn't be very helpful for that.

> > Basically what Linux has done should
> > have been done just before issuing -rc1.
> 
> Well, getting such a rework ready before -rc1 is difficult. A driver
> that is added late in the merge window might break these changes. So I
> still think the way we chose to do it (i.e. getting the changes into
> next directly after -rc1 and merge just before -rc2 after no issues
> showed up) is sane.
> 
> From my POV "mid-rc-cycle merge" is unjustified blaming. Yes, it was
> after -rc1, but as argued above before -rc1 is hard and IMHO it doesn't
> matter much if it goes in soon after -rc1 or just before -rc2 because
> only the tags are sync points and keeping some flexibility by exposing
> it for testing in next instead of Linus's tree is IMHO also justified.

Like it or not, from my point of view, mid-rc-cycle merge caused me this 
extra hassle.

Also, I wrote mid-rc-cycle merge as a fact/explanation, not with the 
intention to blame you. I understood you wanted to have it done this way,
I conceded. I knew it has some consequences into my workflow.

I still appreciate you actually doing that work even if it caused some 
hassle for me!


-- 
 i.