Re: [PATCH v8 3/5] drm/xe/i2c: use device_create_managed_software_node()

[Bartosz Golaszewski]

On Tue, 22 Sep 2026 12:30:45 +0200, Heikki Krogerus
<heikki.krogerus@xxxxxxxxxxxxxxx> said:
> On Thu, Jul 16, 2026 at 02:31:38PM +0200, Bartosz Golaszewski wrote:
>> This driver intentionally uses the fine-grained approach to creating
>> platform devices. It assigns a software node as the primary firmware
>> node of the device it creates. Ahead of improving the reference counting
>> of platform device software nodes, switch to using
>> device_create_managed_software_node(). This way, we create a dynamic
>> software node whose life-time is tied to the device to which it's
>> assigned.
>>
>> Reviewed-by: Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>
>> Acked-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxxxxxxxx>
>
> What happened to this one? I can see the commit 0f485f88656a
> ("drm/xe/i2c: use device_create_managed_software_node()"), but not the
> code change?
>
> There is no revert and there are no other commits touching this part
> of the driver, so it's as if the patch was never actually applied?
>

I had no idea what happened here so I had the robot look into it and it came
back with this:

--
Your commit 0f485f88656a ("drm/xe/i2c: use
device_create_managed_software_node()") landed upstream on 2026-07-16, but it
went in through the driver-core tree (it's signed off by Danilo Krummrich,
a driver-core maintainer), not through drm-xe. It reached mainline via the
"Merge tag 'driver-core-7.3-rc1'" pull, and was present in v7.3-rc1.

Meanwhile, Intel's drm-xe-next tree had last synced with mainline back on
2026-08-06 (merge-base ec3e9419371d, before your commit existed). Off that
stale base, Heikki Krogerus landed a large I2C IRQ-handling rewrite on
2026-08-11 (a55b76b8bc2c "Fix the interrupt handling", 76cc14e2faed "Keep
the i2c controller always enabled") that touched
xe_i2c_register_adapter()/xe_i2c_unregister_adapter() — the same function
your patch changed — but built on the pre-conversion
fwnode_create_software_node() code, since drm-xe-next didn't have your commit
yet.

The regression happened here:

cc467969646b — "Merge drm/drm-next into drm-xe-next" by Matthew Brost
(Intel), 2026-08-31, merging:
- parent 1: drm-xe-next's tip (Heikki's rewrite, on the old fwnode code)
- parent 2: v7.3-rc1 (mainline, with your new
  device_create_managed_software_node() code)

I diffed the merge result against both parents directly: for the
xe_i2c_register_adapter/unregister_adapter hunk, the merge commit is
byte-for-byte identical to parent 1 — it silently dropped your API-migration
change and kept the old fwnode code (plus Heikki's IRQ rework on top of it).
No Conflicts: trailer is in the merge message, so this wasn't a manual
conflict resolution that anyone flagged — either it merged cleanly in a way
that just discarded your side, or it was resolved without git noting it in
the message.

That merge (drm-xe-next-2026-08-31-1) then flowed drm-xe-next → drm-next
→ mainline, and it's still that way in current mainline (verified: HEAD,
v7.3-rc4-based, still has the old code — confirmed via git blame).

Bottom line: your change wasn't reverted on purpose — it was silently clobbered
by a stale-base merge conflict resolution when drm-xe-next resynced with
mainline on 2026-08-31, because drm-xe-next hadn't picked up your
driver-core-authored commit before building new code on top of the same
function. This is a real upstream bug worth flagging (to Matthew Brost
/ Heikki Krogerus / Danilo Krummrich): the driver-core migration for xe_i2c.c
needs to be reapplied on current mainline.
--

I think we need to reapply this patch.

Bart