On Mon, May 11, 2026 at 4:31 PM Danilo Krummrich <[email protected]> wrote:
>
> On Mon May 11, 2026 at 4:17 PM CEST, Bartosz Golaszewski wrote:
> > On Mon, 11 May 2026 16:00:23 +0200, Danilo Krummrich <[email protected]> said:
> >> On Mon May 11, 2026 at 9:33 AM CEST, Bartosz Golaszewski wrote:
> >>> Danilo: if there are no further comments, can you pick it up for v7.1?
> >>
> >> It seems that sashiko has a valid concern in [1]; can you confirm?
> >>
> >> [1] 
> >> https://sashiko.dev/#/patchset/20260430-swnode-remove-on-dev-unreg-v4-0-01574da0aed3%40oss.qualcomm.com
> >>
> >
> > Yes, I explained it here[1]. Basically it's similar to how we need to call
> > platform_device_add_data() for devices created with platform_device_alloc().
> >
> > We can consider adding platform_device_add_software_node() once there's
> > a potential user but for now I'd just leave it like this.
>
> But there are users that already need this, no? There is Xe [1] and Surface 
> GPE
> [2], or am I missing something?
>
> [1] 
> https://elixir.bootlin.com/linux/v7.1-rc2/source/drivers/gpu/drm/xe/xe_i2c.c#L99
> [2] 
> https://elixir.bootlin.com/linux/v7.1-rc2/source/drivers/platform/surface/surface_gpe.c#L308

Right, I was not aware of these. That could indeed cause a regression.
I'd like to fix the problem in v7.1 but also keep it minimal so adding
platform_device_add_software_node() and updating drivers to using it
may be the next step but for now: how about adding
platform_device_release_full() which would call
device_remove_software_node() and then the existing
platform_device_release()? We'd replace the .release callback of
struct device in platform_device_register_full() but if the user just
uses platform_device_alloc(), they would keep the regular .release()
that doesn't remove the software node?

That would go into v7.1 and then I'd provide
platform_device_add_software_node(), use it in all drivers that need
it, and then we'd remove platform_device_release_full() and go back to
a single, unified release callback?

Does it make sense?

Bart

Reply via email to