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

["Uwe Kleine-König" <u.kleine-koenig@baylibre.com>]

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

Hello Andy,

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).

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.

> 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.

Best regards
Uwe

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