When converting legacy board code to use static device properties,
especially when using static device properties for GPIO references,
it is often required to attach a secondary software node to platform
devices being created.

To reduce the amount of boilerplate needed add 'swnode' field to
platform_device_info structure and attach this software node (and
register it if it is not yet registered) as a secondary node to the
new platform device.

v2:
- add kerneldoc for platform_device_info
- split out formatting changes into a separate patch

Dmitry Torokhov (3):
  driver core: platform: add kerneldoc to struct platform_device_info
  driver core: platform: allow attaching software nodes when creating
    devices
  driver core: platform: fix various formatting issues

 drivers/base/platform.c         | 58 ++++++++++++++++-----------------
 include/linux/platform_device.h | 58 ++++++++++++++++++++++++++-------
 2 files changed, 76 insertions(+), 40 deletions(-)

Thanks.

-- 
Dmitry

On Sat Feb 14, 2026 at 3:52 AM CET, Dmitry Torokhov wrote:
> v2:
> - add kerneldoc for platform_device_info

Thanks for documenting the whole struct!

> - split out formatting changes into a separate patch

There is still the mixup in the documentation patch, but I can see why you did
it and I think it's fine.

>   driver core: platform: add kerneldoc to struct platform_device_info
>   driver core: platform: allow attaching software nodes when creating
>     devices

Unless there there is any contrary feedback from Greg or Rafael, I can pick up
the series after -rc1 is out and hand out a signed tag for the two of those.

>   driver core: platform: fix various formatting issues

Thanks,
Danilo

Hi Danilo,

On Sat, Feb 14, 2026 at 11:55:57AM +0100, Danilo Krummrich wrote:
> On Sat Feb 14, 2026 at 3:52 AM CET, Dmitry Torokhov wrote:
> > v2:
> > - add kerneldoc for platform_device_info
> 
> Thanks for documenting the whole struct!
> 
> > - split out formatting changes into a separate patch
> 
> There is still the mixup in the documentation patch, but I can see why you did
> it and I think it's fine.
> 
> >   driver core: platform: add kerneldoc to struct platform_device_info
> >   driver core: platform: allow attaching software nodes when creating
> >     devices
> 
> Unless there there is any contrary feedback from Greg or Rafael, I can pick up
> the series after -rc1 is out and hand out a signed tag for the two of those.

Yes, could this be applied please? I have a few patches that depend on
this that I'd like to send out.

Thanks.

-- 
Dmitry

On Sun Mar 1, 2026 at 6:02 AM CET, Dmitry Torokhov wrote:
>> Unless there there is any contrary feedback from Greg or Rafael, I can pick up
>> the series after -rc1 is out and hand out a signed tag for the two of those.
>
> Yes, could this be applied please? I have a few patches that depend on
> this that I'd like to send out.

Sorry for the delay, will do tomorrow!

Thanks,
Danilo

On Mon Mar 2, 2026 at 1:42 AM CET, Danilo Krummrich wrote:
> On Sun Mar 1, 2026 at 6:02 AM CET, Dmitry Torokhov wrote:
>>> Unless there there is any contrary feedback from Greg or Rafael, I can pick up
>>> the series after -rc1 is out and hand out a signed tag for the two of those.
>>
>> Yes, could this be applied please? I have a few patches that depend on
>> this that I'd like to send out.
>
> Sorry for the delay, will do tomorrow!

Again, sorry for the delay, I gave this some extra cycles to make sure Greg and
Rafael have a chance to comment (especially since this will be shared with other
trees).

I now applied this to driver-core-testing; I will share a signed tag once I have
the 0day result.

I have one consideration about the

	if (pdevinfo->swnode && pdevinfo->properties)
		return ERR_PTR(-EINVAL);

case (which I hate we can't catch at compile time). Maybe it is worth to at
least print a warning?

Thanks,
Danilo

On Mon Mar 2, 2026 at 3:39 PM CET, Danilo Krummrich wrote:
> Again, sorry for the delay, I gave this some extra cycles to make sure Greg and
> Rafael have a chance to comment (especially since this will be shared with other
> trees).
>
> I now applied this to driver-core-testing; I will share a signed tag once I have
> the 0day result.

https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git/tag/?h=platform_device_info_swnode-7.1-rc1

Hi Danilo,

On Mon, Mar 02, 2026 at 03:39:51PM +0100, Danilo Krummrich wrote:
> On Mon Mar 2, 2026 at 1:42 AM CET, Danilo Krummrich wrote:
> > On Sun Mar 1, 2026 at 6:02 AM CET, Dmitry Torokhov wrote:
> >>> Unless there there is any contrary feedback from Greg or Rafael, I can pick up
> >>> the series after -rc1 is out and hand out a signed tag for the two of those.
> >>
> >> Yes, could this be applied please? I have a few patches that depend on
> >> this that I'd like to send out.
> >
> > Sorry for the delay, will do tomorrow!
> 
> Again, sorry for the delay, I gave this some extra cycles to make sure Greg and
> Rafael have a chance to comment (especially since this will be shared with other
> trees).
> 
> I now applied this to driver-core-testing; I will share a signed tag once I have
> the 0day result.

Thank you!

> 
> I have one consideration about the
> 
> 	if (pdevinfo->swnode && pdevinfo->properties)
> 		return ERR_PTR(-EINVAL);
> 
> case (which I hate we can't catch at compile time). Maybe it is worth to at
> least print a warning?

I am not sure how much it will help: the setup is typically static so
the developer using this change/api will immediately run into this error
if they try to set both, users will not see it.

OTOH it is a single message...

Thanks.

-- 
Dmitry