In many drivers the whole bunch of what device.h provides is not
being used. Currently we already have device/devres.h which helps
a lot, but splitting more, will do even better. Hence this mini-series.

Note, it hasn't got comprehensive compile-test, so I would be not in
a hurry to apply it (but if you can test or *temporally* place into
Linux Next, it would be nice) and let others to test, including all
crawling CIs and bots.

Andy Shevchenko (3):
  driver core: Split device data types to device/types.h
  driver core: Split device link data types and API to device/devlink.h
  driver core: Split device related fwnode API to device/fwnode.h

 include/linux/device.h         | 498 +--------------------------------
 include/linux/device/devlink.h |  97 +++++++
 include/linux/device/fwnode.h  |  28 ++
 include/linux/device/types.h   | 415 +++++++++++++++++++++++++++
 include/linux/fwnode.h         |   2 +
 5 files changed, 545 insertions(+), 495 deletions(-)
 create mode 100644 include/linux/device/devlink.h
 create mode 100644 include/linux/device/fwnode.h
 create mode 100644 include/linux/device/types.h

-- 
2.50.1

On Mon, Feb 23, 2026 at 09:30:29PM +0100, Andy Shevchenko wrote:
> In many drivers the whole bunch of what device.h provides is not
> being used. Currently we already have device/devres.h which helps
> a lot, but splitting more, will do even better. Hence this mini-series.

What is "better"?  Faster builds?  Smaller builds?  Something else?  Why
do this?  A big .h file might not be "nice", but it's usually faster
than having multiple .h files that are always included from that
original .h file

thanks,

greg k-h