[PATCH v1 0/3] driver core: Split device.h even more

[PATCH v1 0/3] driver core: Split device.h even more

[Andy Shevchenko]

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

[PATCH v1 1/3] driver core: Split device data types to device/types.h

[Andy Shevchenko]

device.h is a huge header which is hard to follow and easy to miss
something. Improve that by splitting device data types to device/types.h.

In particular this helps to speedup the build of the code that includes
device.h solely for a device data types.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 include/linux/device.h       | 395 +--------------------------------
 include/linux/device/types.h | 415 +++++++++++++++++++++++++++++++++++
 2 files changed, 416 insertions(+), 394 deletions(-)
 create mode 100644 include/linux/device/types.h

diff --git a/include/linux/device.h b/include/linux/device.h
index 0be95294b6e6..8c85ee363567 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -30,22 +30,15 @@
 #include <linux/device/class.h>
 #include <linux/device/devres.h>
 #include <linux/device/driver.h>
+#include <linux/device/types.h>
 #include <linux/cleanup.h>
-#include <asm/device.h>
 
-struct device;
-struct device_private;
 struct device_driver;
-struct driver_private;
 struct module;
 struct class;
 struct subsys_private;
 struct device_node;
 struct fwnode_handle;
-struct iommu_group;
-struct dev_pin_info;
-struct dev_iommu;
-struct msi_device_data;
 
 /**
  * struct subsys_interface - interfaces to device functions
@@ -76,26 +69,6 @@ int subsys_system_register(const struct bus_type *subsys,
 int subsys_virtual_register(const struct bus_type *subsys,
 			    const struct attribute_group **groups);
 
-/*
- * The type of device, "struct device" is embedded in. A class
- * or bus can contain devices of different types
- * like "partitions" and "disks", "mouse" and "event".
- * This identifies the device type and carries type-specific
- * information, equivalent to the kobj_type of a kobject.
- * If "name" is specified, the uevent will contain it in
- * the DEVTYPE variable.
- */
-struct device_type {
-	const char *name;
-	const struct attribute_group **groups;
-	int (*uevent)(const struct device *dev, struct kobj_uevent_env *env);
-	char *(*devnode)(const struct device *dev, umode_t *mode,
-			 kuid_t *uid, kgid_t *gid);
-	void (*release)(struct device *dev);
-
-	const struct dev_pm_ops *pm;
-};
-
 /**
  * struct device_attribute - Interface for exporting device attributes.
  * @attr: sysfs attribute definition.
@@ -281,16 +254,6 @@ int __must_check device_create_bin_file(struct device *dev,
 void device_remove_bin_file(struct device *dev,
 			    const struct bin_attribute *attr);
 
-struct device_dma_parameters {
-	/*
-	 * a low level driver may set these to teach IOMMU code about
-	 * sg limitations.
-	 */
-	unsigned int max_segment_size;
-	unsigned int min_align_mask;
-	unsigned long segment_boundary_mask;
-};
-
 /**
  * enum device_link_state - Device link states.
  * @DL_STATE_NONE: The presence of the drivers is not being tracked.
@@ -333,344 +296,6 @@ enum device_link_state {
 #define DL_FLAG_INFERRED		BIT(8)
 #define DL_FLAG_CYCLE			BIT(9)
 
-/**
- * enum dl_dev_state - Device driver presence tracking information.
- * @DL_DEV_NO_DRIVER: There is no driver attached to the device.
- * @DL_DEV_PROBING: A driver is probing.
- * @DL_DEV_DRIVER_BOUND: The driver has been bound to the device.
- * @DL_DEV_UNBINDING: The driver is unbinding from the device.
- */
-enum dl_dev_state {
-	DL_DEV_NO_DRIVER = 0,
-	DL_DEV_PROBING,
-	DL_DEV_DRIVER_BOUND,
-	DL_DEV_UNBINDING,
-};
-
-/**
- * enum device_removable - Whether the device is removable. The criteria for a
- * device to be classified as removable is determined by its subsystem or bus.
- * @DEVICE_REMOVABLE_NOT_SUPPORTED: This attribute is not supported for this
- *				    device (default).
- * @DEVICE_REMOVABLE_UNKNOWN:  Device location is Unknown.
- * @DEVICE_FIXED: Device is not removable by the user.
- * @DEVICE_REMOVABLE: Device is removable by the user.
- */
-enum device_removable {
-	DEVICE_REMOVABLE_NOT_SUPPORTED = 0, /* must be 0 */
-	DEVICE_REMOVABLE_UNKNOWN,
-	DEVICE_FIXED,
-	DEVICE_REMOVABLE,
-};
-
-/**
- * struct dev_links_info - Device data related to device links.
- * @suppliers: List of links to supplier devices.
- * @consumers: List of links to consumer devices.
- * @defer_sync: Hook to global list of devices that have deferred sync_state.
- * @status: Driver status information.
- */
-struct dev_links_info {
-	struct list_head suppliers;
-	struct list_head consumers;
-	struct list_head defer_sync;
-	enum dl_dev_state status;
-};
-
-/**
- * struct dev_msi_info - Device data related to MSI
- * @domain:	The MSI interrupt domain associated to the device
- * @data:	Pointer to MSI device data
- */
-struct dev_msi_info {
-#ifdef CONFIG_GENERIC_MSI_IRQ
-	struct irq_domain	*domain;
-	struct msi_device_data	*data;
-#endif
-};
-
-/**
- * enum device_physical_location_panel - Describes which panel surface of the
- * system's housing the device connection point resides on.
- * @DEVICE_PANEL_TOP: Device connection point is on the top panel.
- * @DEVICE_PANEL_BOTTOM: Device connection point is on the bottom panel.
- * @DEVICE_PANEL_LEFT: Device connection point is on the left panel.
- * @DEVICE_PANEL_RIGHT: Device connection point is on the right panel.
- * @DEVICE_PANEL_FRONT: Device connection point is on the front panel.
- * @DEVICE_PANEL_BACK: Device connection point is on the back panel.
- * @DEVICE_PANEL_UNKNOWN: The panel with device connection point is unknown.
- */
-enum device_physical_location_panel {
-	DEVICE_PANEL_TOP,
-	DEVICE_PANEL_BOTTOM,
-	DEVICE_PANEL_LEFT,
-	DEVICE_PANEL_RIGHT,
-	DEVICE_PANEL_FRONT,
-	DEVICE_PANEL_BACK,
-	DEVICE_PANEL_UNKNOWN,
-};
-
-/**
- * enum device_physical_location_vertical_position - Describes vertical
- * position of the device connection point on the panel surface.
- * @DEVICE_VERT_POS_UPPER: Device connection point is at upper part of panel.
- * @DEVICE_VERT_POS_CENTER: Device connection point is at center part of panel.
- * @DEVICE_VERT_POS_LOWER: Device connection point is at lower part of panel.
- */
-enum device_physical_location_vertical_position {
-	DEVICE_VERT_POS_UPPER,
-	DEVICE_VERT_POS_CENTER,
-	DEVICE_VERT_POS_LOWER,
-};
-
-/**
- * enum device_physical_location_horizontal_position - Describes horizontal
- * position of the device connection point on the panel surface.
- * @DEVICE_HORI_POS_LEFT: Device connection point is at left part of panel.
- * @DEVICE_HORI_POS_CENTER: Device connection point is at center part of panel.
- * @DEVICE_HORI_POS_RIGHT: Device connection point is at right part of panel.
- */
-enum device_physical_location_horizontal_position {
-	DEVICE_HORI_POS_LEFT,
-	DEVICE_HORI_POS_CENTER,
-	DEVICE_HORI_POS_RIGHT,
-};
-
-/**
- * struct device_physical_location - Device data related to physical location
- * of the device connection point.
- * @panel: Panel surface of the system's housing that the device connection
- *         point resides on.
- * @vertical_position: Vertical position of the device connection point within
- *                     the panel.
- * @horizontal_position: Horizontal position of the device connection point
- *                       within the panel.
- * @dock: Set if the device connection point resides in a docking station or
- *        port replicator.
- * @lid: Set if this device connection point resides on the lid of laptop
- *       system.
- */
-struct device_physical_location {
-	enum device_physical_location_panel panel;
-	enum device_physical_location_vertical_position vertical_position;
-	enum device_physical_location_horizontal_position horizontal_position;
-	bool dock;
-	bool lid;
-};
-
-/**
- * struct device - The basic device structure
- * @parent:	The device's "parent" device, the device to which it is attached.
- * 		In most cases, a parent device is some sort of bus or host
- * 		controller. If parent is NULL, the device, is a top-level device,
- * 		which is not usually what you want.
- * @p:		Holds the private data of the driver core portions of the device.
- * 		See the comment of the struct device_private for detail.
- * @kobj:	A top-level, abstract class from which other classes are derived.
- * @init_name:	Initial name of the device.
- * @type:	The type of device.
- * 		This identifies the device type and carries type-specific
- * 		information.
- * @mutex:	Mutex to synchronize calls to its driver.
- * @bus:	Type of bus device is on.
- * @driver:	Which driver has allocated this
- * @platform_data: Platform data specific to the device.
- * 		Example: For devices on custom boards, as typical of embedded
- * 		and SOC based hardware, Linux often uses platform_data to point
- * 		to board-specific structures describing devices and how they
- * 		are wired.  That can include what ports are available, chip
- * 		variants, which GPIO pins act in what additional roles, and so
- * 		on.  This shrinks the "Board Support Packages" (BSPs) and
- * 		minimizes board-specific #ifdefs in drivers.
- * @driver_data: Private pointer for driver specific info.
- * @links:	Links to suppliers and consumers of this device.
- * @power:	For device power management.
- *		See Documentation/driver-api/pm/devices.rst for details.
- * @pm_domain:	Provide callbacks that are executed during system suspend,
- * 		hibernation, system resume and during runtime PM transitions
- * 		along with subsystem-level and driver-level callbacks.
- * @em_pd:	device's energy model performance domain
- * @pins:	For device pin management.
- *		See Documentation/driver-api/pin-control.rst for details.
- * @msi:	MSI related data
- * @numa_node:	NUMA node this device is close to.
- * @dma_ops:    DMA mapping operations for this device.
- * @dma_mask:	Dma mask (if dma'ble device).
- * @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all
- * 		hardware supports 64-bit addresses for consistent allocations
- * 		such descriptors.
- * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
- *		DMA limit than the device itself supports.
- * @dma_range_map: map for DMA memory ranges relative to that of RAM
- * @dma_parms:	A low level driver may set these to teach IOMMU code about
- * 		segment limitations.
- * @dma_pools:	Dma pools (if dma'ble device).
- * @dma_mem:	Internal for coherent mem override.
- * @cma_area:	Contiguous memory area for dma allocations
- * @dma_io_tlb_mem: Software IO TLB allocator.  Not for driver use.
- * @dma_io_tlb_pools:	List of transient swiotlb memory pools.
- * @dma_io_tlb_lock:	Protects changes to the list of active pools.
- * @dma_uses_io_tlb: %true if device has used the software IO TLB.
- * @archdata:	For arch-specific additions.
- * @of_node:	Associated device tree node.
- * @fwnode:	Associated device node supplied by platform firmware.
- * @devt:	For creating the sysfs "dev".
- * @id:		device instance
- * @devres_lock: Spinlock to protect the resource of the device.
- * @devres_head: The resources list of the device.
- * @class:	The class of the device.
- * @groups:	Optional attribute groups.
- * @release:	Callback to free the device after all references have
- * 		gone away. This should be set by the allocator of the
- * 		device (i.e. the bus driver that discovered the device).
- * @iommu_group: IOMMU group the device belongs to.
- * @iommu:	Per device generic IOMMU runtime data
- * @physical_location: Describes physical location of the device connection
- *		point in the system housing.
- * @removable:  Whether the device can be removed from the system. This
- *              should be set by the subsystem / bus driver that discovered
- *              the device.
- *
- * @offline_disabled: If set, the device is permanently online.
- * @offline:	Set after successful invocation of bus type's .offline().
- * @of_node_reused: Set if the device-tree node is shared with an ancestor
- *              device.
- * @state_synced: The hardware state of this device has been synced to match
- *		  the software state of this device by calling the driver/bus
- *		  sync_state() callback.
- * @can_match:	The device has matched with a driver at least once or it is in
- *		a bus (like AMBA) which can't check for matching drivers until
- *		other devices probe successfully.
- * @dma_coherent: this particular device is dma coherent, even if the
- *		architecture supports non-coherent devices.
- * @dma_ops_bypass: If set to %true then the dma_ops are bypassed for the
- *		streaming DMA operations (->map_* / ->unmap_* / ->sync_*),
- *		and optionall (if the coherent mask is large enough) also
- *		for dma allocations.  This flag is managed by the dma ops
- *		instance from ->dma_supported.
- * @dma_skip_sync: DMA sync operations can be skipped for coherent buffers.
- * @dma_iommu: Device is using default IOMMU implementation for DMA and
- *		doesn't rely on dma_ops structure.
- *
- * At the lowest level, every device in a Linux system is represented by an
- * instance of struct device. The device structure contains the information
- * that the device model core needs to model the system. Most subsystems,
- * however, track additional information about the devices they host. As a
- * result, it is rare for devices to be represented by bare device structures;
- * instead, that structure, like kobject structures, is usually embedded within
- * a higher-level representation of the device.
- */
-struct device {
-	struct kobject kobj;
-	struct device		*parent;
-
-	struct device_private	*p;
-
-	const char		*init_name; /* initial name of the device */
-	const struct device_type *type;
-
-	const struct bus_type	*bus;	/* type of bus device is on */
-	struct device_driver *driver;	/* which driver has allocated this
-					   device */
-	void		*platform_data;	/* Platform specific data, device
-					   core doesn't touch it */
-	void		*driver_data;	/* Driver data, set and get with
-					   dev_set_drvdata/dev_get_drvdata */
-	struct mutex		mutex;	/* mutex to synchronize calls to
-					 * its driver.
-					 */
-
-	struct dev_links_info	links;
-	struct dev_pm_info	power;
-	struct dev_pm_domain	*pm_domain;
-
-#ifdef CONFIG_ENERGY_MODEL
-	struct em_perf_domain	*em_pd;
-#endif
-
-#ifdef CONFIG_PINCTRL
-	struct dev_pin_info	*pins;
-#endif
-	struct dev_msi_info	msi;
-#ifdef CONFIG_ARCH_HAS_DMA_OPS
-	const struct dma_map_ops *dma_ops;
-#endif
-	u64		*dma_mask;	/* dma mask (if dma'able device) */
-	u64		coherent_dma_mask;/* Like dma_mask, but for
-					     alloc_coherent mappings as
-					     not all hardware supports
-					     64 bit addresses for consistent
-					     allocations such descriptors. */
-	u64		bus_dma_limit;	/* upstream dma constraint */
-	const struct bus_dma_region *dma_range_map;
-
-	struct device_dma_parameters *dma_parms;
-
-	struct list_head	dma_pools;	/* dma pools (if dma'ble) */
-
-#ifdef CONFIG_DMA_DECLARE_COHERENT
-	struct dma_coherent_mem	*dma_mem; /* internal for coherent mem
-					     override */
-#endif
-#ifdef CONFIG_DMA_CMA
-	struct cma *cma_area;		/* contiguous memory area for dma
-					   allocations */
-#endif
-#ifdef CONFIG_SWIOTLB
-	struct io_tlb_mem *dma_io_tlb_mem;
-#endif
-#ifdef CONFIG_SWIOTLB_DYNAMIC
-	struct list_head dma_io_tlb_pools;
-	spinlock_t dma_io_tlb_lock;
-	bool dma_uses_io_tlb;
-#endif
-	/* arch specific additions */
-	struct dev_archdata	archdata;
-
-	struct device_node	*of_node; /* associated device tree node */
-	struct fwnode_handle	*fwnode; /* firmware device node */
-
-#ifdef CONFIG_NUMA
-	int		numa_node;	/* NUMA node this device is close to */
-#endif
-	dev_t			devt;	/* dev_t, creates the sysfs "dev" */
-	u32			id;	/* device instance */
-
-	spinlock_t		devres_lock;
-	struct list_head	devres_head;
-
-	const struct class	*class;
-	const struct attribute_group **groups;	/* optional groups */
-
-	void	(*release)(struct device *dev);
-	struct iommu_group	*iommu_group;
-	struct dev_iommu	*iommu;
-
-	struct device_physical_location *physical_location;
-
-	enum device_removable	removable;
-
-	bool			offline_disabled:1;
-	bool			offline:1;
-	bool			of_node_reused:1;
-	bool			state_synced:1;
-	bool			can_match:1;
-#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
-    defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
-    defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
-	bool			dma_coherent:1;
-#endif
-#ifdef CONFIG_DMA_OPS_BYPASS
-	bool			dma_ops_bypass : 1;
-#endif
-#ifdef CONFIG_DMA_NEED_SYNC
-	bool			dma_skip_sync:1;
-#endif
-#ifdef CONFIG_IOMMU_DMA
-	bool			dma_iommu:1;
-#endif
-};
-
 /**
  * struct device_link - Device link representation.
  * @supplier: The device on the supplier end of the link.
@@ -699,8 +324,6 @@ struct device_link {
 	bool supplier_preactivated; /* Owned by consumer probe. */
 };
 
-#define kobj_to_dev(__kobj)	container_of_const(__kobj, struct device, kobj)
-
 /**
  * device_iommu_mapped - Returns true when the device DMA is translated
  *			 by an IOMMU
@@ -761,22 +384,6 @@ static inline void set_dev_node(struct device *dev, int node)
 }
 #endif
 
-static inline struct irq_domain *dev_get_msi_domain(const struct device *dev)
-{
-#ifdef CONFIG_GENERIC_MSI_IRQ
-	return dev->msi.domain;
-#else
-	return NULL;
-#endif
-}
-
-static inline void dev_set_msi_domain(struct device *dev, struct irq_domain *d)
-{
-#ifdef CONFIG_GENERIC_MSI_IRQ
-	dev->msi.domain = d;
-#endif
-}
-
 static inline void *dev_get_drvdata(const struct device *dev)
 {
 	return dev->driver_data;
diff --git a/include/linux/device/types.h b/include/linux/device/types.h
new file mode 100644
index 000000000000..569a7f0613e6
--- /dev/null
+++ b/include/linux/device/types.h
@@ -0,0 +1,415 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _DEVICE_TYPES_H_
+#define _DEVICE_TYPES_H_
+
+#include <linux/container_of.h>
+#include <linux/kobject.h>
+#include <linux/mutex_types.h>
+#include <linux/pm.h>
+#include <linux/spinlock_types.h>
+#include <linux/types.h>
+#include <linux/uidgid_types.h>
+
+#include <asm/device.h>
+
+/**
+ * enum device_physical_location_panel - Describes which panel surface of the
+ * system's housing the device connection point resides on.
+ * @DEVICE_PANEL_TOP: Device connection point is on the top panel.
+ * @DEVICE_PANEL_BOTTOM: Device connection point is on the bottom panel.
+ * @DEVICE_PANEL_LEFT: Device connection point is on the left panel.
+ * @DEVICE_PANEL_RIGHT: Device connection point is on the right panel.
+ * @DEVICE_PANEL_FRONT: Device connection point is on the front panel.
+ * @DEVICE_PANEL_BACK: Device connection point is on the back panel.
+ * @DEVICE_PANEL_UNKNOWN: The panel with device connection point is unknown.
+ */
+enum device_physical_location_panel {
+	DEVICE_PANEL_TOP,
+	DEVICE_PANEL_BOTTOM,
+	DEVICE_PANEL_LEFT,
+	DEVICE_PANEL_RIGHT,
+	DEVICE_PANEL_FRONT,
+	DEVICE_PANEL_BACK,
+	DEVICE_PANEL_UNKNOWN,
+};
+
+/**
+ * enum device_physical_location_vertical_position - Describes vertical
+ * position of the device connection point on the panel surface.
+ * @DEVICE_VERT_POS_UPPER: Device connection point is at upper part of panel.
+ * @DEVICE_VERT_POS_CENTER: Device connection point is at center part of panel.
+ * @DEVICE_VERT_POS_LOWER: Device connection point is at lower part of panel.
+ */
+enum device_physical_location_vertical_position {
+	DEVICE_VERT_POS_UPPER,
+	DEVICE_VERT_POS_CENTER,
+	DEVICE_VERT_POS_LOWER,
+};
+
+/**
+ * enum device_physical_location_horizontal_position - Describes horizontal
+ * position of the device connection point on the panel surface.
+ * @DEVICE_HORI_POS_LEFT: Device connection point is at left part of panel.
+ * @DEVICE_HORI_POS_CENTER: Device connection point is at center part of panel.
+ * @DEVICE_HORI_POS_RIGHT: Device connection point is at right part of panel.
+ */
+enum device_physical_location_horizontal_position {
+	DEVICE_HORI_POS_LEFT,
+	DEVICE_HORI_POS_CENTER,
+	DEVICE_HORI_POS_RIGHT,
+};
+
+/**
+ * struct device_physical_location - Device data related to physical location
+ * of the device connection point.
+ * @panel: Panel surface of the system's housing that the device connection
+ *         point resides on.
+ * @vertical_position: Vertical position of the device connection point within
+ *                     the panel.
+ * @horizontal_position: Horizontal position of the device connection point
+ *                       within the panel.
+ * @dock: Set if the device connection point resides in a docking station or
+ *        port replicator.
+ * @lid: Set if this device connection point resides on the lid of laptop
+ *       system.
+ */
+struct device_physical_location {
+	enum device_physical_location_panel panel;
+	enum device_physical_location_vertical_position vertical_position;
+	enum device_physical_location_horizontal_position horizontal_position;
+	bool dock;
+	bool lid;
+};
+
+/**
+ * enum dl_dev_state - Device driver presence tracking information.
+ * @DL_DEV_NO_DRIVER: There is no driver attached to the device.
+ * @DL_DEV_PROBING: A driver is probing.
+ * @DL_DEV_DRIVER_BOUND: The driver has been bound to the device.
+ * @DL_DEV_UNBINDING: The driver is unbinding from the device.
+ */
+enum dl_dev_state {
+	DL_DEV_NO_DRIVER = 0,
+	DL_DEV_PROBING,
+	DL_DEV_DRIVER_BOUND,
+	DL_DEV_UNBINDING,
+};
+
+/**
+ * struct dev_links_info - Device data related to device links.
+ * @suppliers: List of links to supplier devices.
+ * @consumers: List of links to consumer devices.
+ * @defer_sync: Hook to global list of devices that have deferred sync_state.
+ * @status: Driver status information.
+ */
+struct dev_links_info {
+	struct list_head suppliers;
+	struct list_head consumers;
+	struct list_head defer_sync;
+	enum dl_dev_state status;
+};
+
+struct irq_domain;
+struct msi_device_data;
+
+/**
+ * struct dev_msi_info - Device data related to MSI
+ * @domain: The MSI interrupt domain associated to the device
+ * @data: Pointer to MSI device data
+ */
+struct dev_msi_info {
+#ifdef CONFIG_GENERIC_MSI_IRQ
+	struct irq_domain	*domain;
+	struct msi_device_data	*data;
+#endif
+};
+
+struct device_dma_parameters {
+	/*
+	 * a low level driver may set these to teach IOMMU code about
+	 * sg limitations.
+	 */
+	unsigned int max_segment_size;
+	unsigned int min_align_mask;
+	unsigned long segment_boundary_mask;
+};
+
+/**
+ * enum device_removable - Whether the device is removable. The criteria for a
+ * device to be classified as removable is determined by its subsystem or bus.
+ * @DEVICE_REMOVABLE_NOT_SUPPORTED: This attribute is not supported for this
+ *				    device (default).
+ * @DEVICE_REMOVABLE_UNKNOWN:  Device location is Unknown.
+ * @DEVICE_FIXED: Device is not removable by the user.
+ * @DEVICE_REMOVABLE: Device is removable by the user.
+ */
+enum device_removable {
+	DEVICE_REMOVABLE_NOT_SUPPORTED = 0, /* must be 0 */
+	DEVICE_REMOVABLE_UNKNOWN,
+	DEVICE_FIXED,
+	DEVICE_REMOVABLE,
+};
+
+struct attribute_group;
+struct bus_dma_region;
+struct bus_type;
+struct class;
+struct cma;
+struct dev_iommu;
+struct dev_pin_info;
+struct device;
+struct device_driver;
+struct device_node;
+struct dma_coherent_mem;
+struct dma_map_ops;
+struct em_perf_domain;
+struct fwnode_handle;
+struct io_tlb_mem;
+struct iommu_group;
+
+/*
+ * The type of device, "struct device" is embedded in. A class
+ * or bus can contain devices of different types
+ * like "partitions" and "disks", "mouse" and "event".
+ * This identifies the device type and carries type-specific
+ * information, equivalent to the kobj_type of a kobject.
+ * If "name" is specified, the uevent will contain it in
+ * the DEVTYPE variable.
+ */
+struct device_type {
+	const char *name;
+	const struct attribute_group **groups;
+	int (*uevent)(const struct device *dev, struct kobj_uevent_env *env);
+	char *(*devnode)(const struct device *dev, umode_t *mode, kuid_t *uid, kgid_t *gid);
+	void (*release)(struct device *dev);
+
+	const struct dev_pm_ops *pm;
+};
+
+/**
+ * struct device - The basic device structure
+ * @parent:	The device's "parent" device, the device to which it is attached.
+ * 		In most cases, a parent device is some sort of bus or host
+ * 		controller. If parent is NULL, the device, is a top-level device,
+ * 		which is not usually what you want.
+ * @p:		Holds the private data of the driver core portions of the device.
+ * 		See the comment of the struct device_private for detail.
+ * @kobj:	A top-level, abstract class from which other classes are derived.
+ * @init_name:	Initial name of the device.
+ * @type:	The type of device.
+ * 		This identifies the device type and carries type-specific
+ * 		information.
+ * @mutex:	Mutex to synchronize calls to its driver.
+ * @bus:	Type of bus device is on.
+ * @driver:	Which driver has allocated this
+ * @platform_data: Platform data specific to the device.
+ * 		Example: For devices on custom boards, as typical of embedded
+ * 		and SOC based hardware, Linux often uses platform_data to point
+ * 		to board-specific structures describing devices and how they
+ * 		are wired.  That can include what ports are available, chip
+ * 		variants, which GPIO pins act in what additional roles, and so
+ * 		on.  This shrinks the "Board Support Packages" (BSPs) and
+ * 		minimizes board-specific #ifdefs in drivers.
+ * @driver_data: Private pointer for driver specific info.
+ * @links:	Links to suppliers and consumers of this device.
+ * @power:	For device power management.
+ *		See Documentation/driver-api/pm/devices.rst for details.
+ * @pm_domain:	Provide callbacks that are executed during system suspend,
+ * 		hibernation, system resume and during runtime PM transitions
+ * 		along with subsystem-level and driver-level callbacks.
+ * @em_pd:	device's energy model performance domain
+ * @pins:	For device pin management.
+ *		See Documentation/driver-api/pin-control.rst for details.
+ * @msi:	MSI related data
+ * @numa_node:	NUMA node this device is close to.
+ * @dma_ops:    DMA mapping operations for this device.
+ * @dma_mask:	Dma mask (if dma'ble device).
+ * @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all
+ * 		hardware supports 64-bit addresses for consistent allocations
+ * 		such descriptors.
+ * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
+ *		DMA limit than the device itself supports.
+ * @dma_range_map: map for DMA memory ranges relative to that of RAM
+ * @dma_parms:	A low level driver may set these to teach IOMMU code about
+ * 		segment limitations.
+ * @dma_pools:	Dma pools (if dma'ble device).
+ * @dma_mem:	Internal for coherent mem override.
+ * @cma_area:	Contiguous memory area for dma allocations
+ * @dma_io_tlb_mem: Software IO TLB allocator.  Not for driver use.
+ * @dma_io_tlb_pools:	List of transient swiotlb memory pools.
+ * @dma_io_tlb_lock:	Protects changes to the list of active pools.
+ * @dma_uses_io_tlb: %true if device has used the software IO TLB.
+ * @archdata:	For arch-specific additions.
+ * @of_node:	Associated device tree node.
+ * @fwnode:	Associated device node supplied by platform firmware.
+ * @devt:	For creating the sysfs "dev".
+ * @id:		device instance
+ * @devres_lock: Spinlock to protect the resource of the device.
+ * @devres_head: The resources list of the device.
+ * @class:	The class of the device.
+ * @groups:	Optional attribute groups.
+ * @release:	Callback to free the device after all references have
+ * 		gone away. This should be set by the allocator of the
+ * 		device (i.e. the bus driver that discovered the device).
+ * @iommu_group: IOMMU group the device belongs to.
+ * @iommu:	Per device generic IOMMU runtime data
+ * @physical_location: Describes physical location of the device connection
+ *		point in the system housing.
+ * @removable:  Whether the device can be removed from the system. This
+ *              should be set by the subsystem / bus driver that discovered
+ *              the device.
+ *
+ * @offline_disabled: If set, the device is permanently online.
+ * @offline:	Set after successful invocation of bus type's .offline().
+ * @of_node_reused: Set if the device-tree node is shared with an ancestor
+ *              device.
+ * @state_synced: The hardware state of this device has been synced to match
+ *		  the software state of this device by calling the driver/bus
+ *		  sync_state() callback.
+ * @can_match:	The device has matched with a driver at least once or it is in
+ *		a bus (like AMBA) which can't check for matching drivers until
+ *		other devices probe successfully.
+ * @dma_coherent: this particular device is dma coherent, even if the
+ *		architecture supports non-coherent devices.
+ * @dma_ops_bypass: If set to %true then the dma_ops are bypassed for the
+ *		streaming DMA operations (->map_* / ->unmap_* / ->sync_*),
+ *		and optionall (if the coherent mask is large enough) also
+ *		for dma allocations.  This flag is managed by the dma ops
+ *		instance from ->dma_supported.
+ * @dma_skip_sync: DMA sync operations can be skipped for coherent buffers.
+ * @dma_iommu: Device is using default IOMMU implementation for DMA and
+ *		doesn't rely on dma_ops structure.
+ *
+ * At the lowest level, every device in a Linux system is represented by an
+ * instance of struct device. The device structure contains the information
+ * that the device model core needs to model the system. Most subsystems,
+ * however, track additional information about the devices they host. As a
+ * result, it is rare for devices to be represented by bare device structures;
+ * instead, that structure, like kobject structures, is usually embedded within
+ * a higher-level representation of the device.
+ */
+struct device {
+	struct kobject kobj;
+	struct device		*parent;
+
+	struct device_private	*p;
+
+	const char		*init_name; /* initial name of the device */
+	const struct device_type *type;
+
+	const struct bus_type	*bus;	/* type of bus device is on */
+	struct device_driver *driver;	/* which driver has allocated this device */
+	void		*platform_data;	/* Platform specific data, device
+					   core doesn't touch it */
+	void		*driver_data;	/* Driver data, set and get with
+					   dev_set_drvdata/dev_get_drvdata */
+	struct mutex		mutex;	/* mutex to synchronize calls to its driver */
+
+	struct dev_links_info	links;
+	struct dev_pm_info	power;
+	struct dev_pm_domain	*pm_domain;
+
+#ifdef CONFIG_ENERGY_MODEL
+	struct em_perf_domain	*em_pd;
+#endif
+
+#ifdef CONFIG_PINCTRL
+	struct dev_pin_info	*pins;
+#endif
+	struct dev_msi_info	msi;
+#ifdef CONFIG_ARCH_HAS_DMA_OPS
+	const struct dma_map_ops *dma_ops;
+#endif
+	u64		*dma_mask;	/* dma mask (if dma'able device) */
+	u64		coherent_dma_mask;/* Like dma_mask, but for
+					     alloc_coherent mappings as
+					     not all hardware supports
+					     64 bit addresses for consistent
+					     allocations such descriptors. */
+	u64		bus_dma_limit;	/* upstream dma constraint */
+	const struct bus_dma_region *dma_range_map;
+
+	struct device_dma_parameters *dma_parms;
+
+	struct list_head	dma_pools;	/* dma pools (if dma'ble) */
+
+#ifdef CONFIG_DMA_DECLARE_COHERENT
+	struct dma_coherent_mem	*dma_mem; /* internal for coherent mem override */
+#endif
+#ifdef CONFIG_DMA_CMA
+	struct cma *cma_area;		/* contiguous memory area for dma allocations */
+#endif
+#ifdef CONFIG_SWIOTLB
+	struct io_tlb_mem *dma_io_tlb_mem;
+#endif
+#ifdef CONFIG_SWIOTLB_DYNAMIC
+	struct list_head dma_io_tlb_pools;
+	spinlock_t dma_io_tlb_lock;
+	bool dma_uses_io_tlb;
+#endif
+	/* arch specific additions */
+	struct dev_archdata	archdata;
+
+	struct device_node	*of_node; /* associated device tree node */
+	struct fwnode_handle	*fwnode; /* firmware device node */
+
+#ifdef CONFIG_NUMA
+	int		numa_node;	/* NUMA node this device is close to */
+#endif
+	dev_t			devt;	/* dev_t, creates the sysfs "dev" */
+	u32			id;	/* device instance */
+
+	spinlock_t		devres_lock;
+	struct list_head	devres_head;
+
+	const struct class	*class;
+	const struct attribute_group **groups;	/* optional groups */
+
+	void	(*release)(struct device *dev);
+	struct iommu_group	*iommu_group;
+	struct dev_iommu	*iommu;
+
+	struct device_physical_location *physical_location;
+
+	enum device_removable	removable;
+
+	bool			offline_disabled:1;
+	bool			offline:1;
+	bool			of_node_reused:1;
+	bool			state_synced:1;
+	bool			can_match:1;
+#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
+    defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
+    defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
+	bool			dma_coherent:1;
+#endif
+#ifdef CONFIG_DMA_OPS_BYPASS
+	bool			dma_ops_bypass : 1;
+#endif
+#ifdef CONFIG_DMA_NEED_SYNC
+	bool			dma_skip_sync:1;
+#endif
+#ifdef CONFIG_IOMMU_DMA
+	bool			dma_iommu:1;
+#endif
+};
+
+#define kobj_to_dev(__kobj)	container_of_const(__kobj, struct device, kobj)
+
+static inline struct irq_domain *dev_get_msi_domain(const struct device *dev)
+{
+#ifdef CONFIG_GENERIC_MSI_IRQ
+	return dev->msi.domain;
+#else
+	return NULL;
+#endif
+}
+
+static inline void dev_set_msi_domain(struct device *dev, struct irq_domain *d)
+{
+#ifdef CONFIG_GENERIC_MSI_IRQ
+	dev->msi.domain = d;
+#endif
+}
+
+#endif /* _DEVICE_TYPES_H_ */
-- 
2.50.1

[PATCH v1 2/3] driver core: Split device link data types and API to device/devlink.h

[Andy Shevchenko]

device.h is a huge header which is hard to follow and easy to miss
something. Improve that by splitting device link data types and API
to device/devlink.h.

In particular this helps to speedup the build of the code that includes
device.h solely for a device link data types and/or API.

Note, get_dev_from_fwnode() goes to include/linux/fwnode.h as it seems
better to be there (it is on one hand related to device link, but it
is a getter for struct fwnode_handle respective field).

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 include/linux/device.h         | 86 +-----------------------------
 include/linux/device/devlink.h | 97 ++++++++++++++++++++++++++++++++++
 include/linux/fwnode.h         |  2 +
 3 files changed, 100 insertions(+), 85 deletions(-)
 create mode 100644 include/linux/device/devlink.h

diff --git a/include/linux/device.h b/include/linux/device.h
index 8c85ee363567..4ba6ae72ddf6 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -28,6 +28,7 @@
 #include <linux/gfp.h>
 #include <linux/device/bus.h>
 #include <linux/device/class.h>
+#include <linux/device/devlink.h>
 #include <linux/device/devres.h>
 #include <linux/device/driver.h>
 #include <linux/device/types.h>
@@ -254,76 +255,6 @@ int __must_check device_create_bin_file(struct device *dev,
 void device_remove_bin_file(struct device *dev,
 			    const struct bin_attribute *attr);
 
-/**
- * enum device_link_state - Device link states.
- * @DL_STATE_NONE: The presence of the drivers is not being tracked.
- * @DL_STATE_DORMANT: None of the supplier/consumer drivers is present.
- * @DL_STATE_AVAILABLE: The supplier driver is present, but the consumer is not.
- * @DL_STATE_CONSUMER_PROBE: The consumer is probing (supplier driver present).
- * @DL_STATE_ACTIVE: Both the supplier and consumer drivers are present.
- * @DL_STATE_SUPPLIER_UNBIND: The supplier driver is unbinding.
- */
-enum device_link_state {
-	DL_STATE_NONE = -1,
-	DL_STATE_DORMANT = 0,
-	DL_STATE_AVAILABLE,
-	DL_STATE_CONSUMER_PROBE,
-	DL_STATE_ACTIVE,
-	DL_STATE_SUPPLIER_UNBIND,
-};
-
-/*
- * Device link flags.
- *
- * STATELESS: The core will not remove this link automatically.
- * AUTOREMOVE_CONSUMER: Remove the link automatically on consumer driver unbind.
- * PM_RUNTIME: If set, the runtime PM framework will use this link.
- * RPM_ACTIVE: Run pm_runtime_get_sync() on the supplier during link creation.
- * AUTOREMOVE_SUPPLIER: Remove the link automatically on supplier driver unbind.
- * AUTOPROBE_CONSUMER: Probe consumer driver automatically after supplier binds.
- * MANAGED: The core tracks presence of supplier/consumer drivers (internal).
- * SYNC_STATE_ONLY: Link only affects sync_state() behavior.
- * INFERRED: Inferred from data (eg: firmware) and not from driver actions.
- */
-#define DL_FLAG_STATELESS		BIT(0)
-#define DL_FLAG_AUTOREMOVE_CONSUMER	BIT(1)
-#define DL_FLAG_PM_RUNTIME		BIT(2)
-#define DL_FLAG_RPM_ACTIVE		BIT(3)
-#define DL_FLAG_AUTOREMOVE_SUPPLIER	BIT(4)
-#define DL_FLAG_AUTOPROBE_CONSUMER	BIT(5)
-#define DL_FLAG_MANAGED			BIT(6)
-#define DL_FLAG_SYNC_STATE_ONLY		BIT(7)
-#define DL_FLAG_INFERRED		BIT(8)
-#define DL_FLAG_CYCLE			BIT(9)
-
-/**
- * struct device_link - Device link representation.
- * @supplier: The device on the supplier end of the link.
- * @s_node: Hook to the supplier device's list of links to consumers.
- * @consumer: The device on the consumer end of the link.
- * @c_node: Hook to the consumer device's list of links to suppliers.
- * @link_dev: device used to expose link details in sysfs
- * @status: The state of the link (with respect to the presence of drivers).
- * @flags: Link flags.
- * @rpm_active: Whether or not the consumer device is runtime-PM-active.
- * @kref: Count repeated addition of the same link.
- * @rm_work: Work structure used for removing the link.
- * @supplier_preactivated: Supplier has been made active before consumer probe.
- */
-struct device_link {
-	struct device *supplier;
-	struct list_head s_node;
-	struct device *consumer;
-	struct list_head c_node;
-	struct device link_dev;
-	enum device_link_state status;
-	u32 flags;
-	refcount_t rpm_active;
-	struct kref kref;
-	struct work_struct rm_work;
-	bool supplier_preactivated; /* Owned by consumer probe. */
-};
-
 /**
  * device_iommu_mapped - Returns true when the device DMA is translated
  *			 by an IOMMU
@@ -678,7 +609,6 @@ void device_set_node(struct device *dev, struct fwnode_handle *fwnode);
 int device_add_of_node(struct device *dev, struct device_node *of_node);
 void device_remove_of_node(struct device *dev);
 void device_set_of_node_from_dev(struct device *dev, const struct device *dev2);
-struct device *get_dev_from_fwnode(struct fwnode_handle *fwnode);
 
 static inline struct device_node *dev_of_node(struct device *dev)
 {
@@ -784,20 +714,6 @@ void device_shutdown(void);
 /* debugging and troubleshooting/diagnostic helpers. */
 const char *dev_driver_string(const struct device *dev);
 
-/* Device links interface. */
-struct device_link *device_link_add(struct device *consumer,
-				    struct device *supplier, u32 flags);
-void device_link_del(struct device_link *link);
-void device_link_remove(void *consumer, struct device *supplier);
-void device_links_supplier_sync_state_pause(void);
-void device_links_supplier_sync_state_resume(void);
-void device_link_wait_removal(void);
-
-static inline bool device_link_test(const struct device_link *link, u32 flags)
-{
-	return !!(link->flags & flags);
-}
-
 /* Create alias, so I can be autoloaded. */
 #define MODULE_ALIAS_CHARDEV(major,minor) \
 	MODULE_ALIAS("char-major-" __stringify(major) "-" __stringify(minor))
diff --git a/include/linux/device/devlink.h b/include/linux/device/devlink.h
new file mode 100644
index 000000000000..88e645bab303
--- /dev/null
+++ b/include/linux/device/devlink.h
@@ -0,0 +1,97 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _DEVICE_LINK_H_
+#define _DEVICE_LINK_H_
+
+#include <linux/bits.h>
+#include <linux/kref.h>
+#include <linux/refcount_types.h>
+#include <linux/types.h>
+#include <linux/workqueue_types.h>
+
+#include "types.h"
+
+/**
+ * enum device_link_state - Device link states.
+ * @DL_STATE_NONE: The presence of the drivers is not being tracked.
+ * @DL_STATE_DORMANT: None of the supplier/consumer drivers is present.
+ * @DL_STATE_AVAILABLE: The supplier driver is present, but the consumer is not.
+ * @DL_STATE_CONSUMER_PROBE: The consumer is probing (supplier driver present).
+ * @DL_STATE_ACTIVE: Both the supplier and consumer drivers are present.
+ * @DL_STATE_SUPPLIER_UNBIND: The supplier driver is unbinding.
+ */
+enum device_link_state {
+	DL_STATE_NONE = -1,
+	DL_STATE_DORMANT = 0,
+	DL_STATE_AVAILABLE,
+	DL_STATE_CONSUMER_PROBE,
+	DL_STATE_ACTIVE,
+	DL_STATE_SUPPLIER_UNBIND,
+};
+
+/*
+ * Device link flags.
+ *
+ * STATELESS: The core will not remove this link automatically.
+ * AUTOREMOVE_CONSUMER: Remove the link automatically on consumer driver unbind.
+ * PM_RUNTIME: If set, the runtime PM framework will use this link.
+ * RPM_ACTIVE: Run pm_runtime_get_sync() on the supplier during link creation.
+ * AUTOREMOVE_SUPPLIER: Remove the link automatically on supplier driver unbind.
+ * AUTOPROBE_CONSUMER: Probe consumer driver automatically after supplier binds.
+ * MANAGED: The core tracks presence of supplier/consumer drivers (internal).
+ * SYNC_STATE_ONLY: Link only affects sync_state() behavior.
+ * INFERRED: Inferred from data (eg: firmware) and not from driver actions.
+ */
+#define DL_FLAG_STATELESS		BIT(0)
+#define DL_FLAG_AUTOREMOVE_CONSUMER	BIT(1)
+#define DL_FLAG_PM_RUNTIME		BIT(2)
+#define DL_FLAG_RPM_ACTIVE		BIT(3)
+#define DL_FLAG_AUTOREMOVE_SUPPLIER	BIT(4)
+#define DL_FLAG_AUTOPROBE_CONSUMER	BIT(5)
+#define DL_FLAG_MANAGED			BIT(6)
+#define DL_FLAG_SYNC_STATE_ONLY		BIT(7)
+#define DL_FLAG_INFERRED		BIT(8)
+#define DL_FLAG_CYCLE			BIT(9)
+
+/**
+ * struct device_link - Device link representation.
+ * @supplier: The device on the supplier end of the link.
+ * @s_node: Hook to the supplier device's list of links to consumers.
+ * @consumer: The device on the consumer end of the link.
+ * @c_node: Hook to the consumer device's list of links to suppliers.
+ * @link_dev: device used to expose link details in sysfs
+ * @status: The state of the link (with respect to the presence of drivers).
+ * @flags: Link flags.
+ * @rpm_active: Whether or not the consumer device is runtime-PM-active.
+ * @kref: Count repeated addition of the same link.
+ * @rm_work: Work structure used for removing the link.
+ * @supplier_preactivated: Supplier has been made active before consumer probe.
+ */
+struct device_link {
+	struct device *supplier;
+	struct list_head s_node;
+	struct device *consumer;
+	struct list_head c_node;
+	struct device link_dev;
+	enum device_link_state status;
+	u32 flags;
+	refcount_t rpm_active;
+	struct kref kref;
+	struct work_struct rm_work;
+	bool supplier_preactivated; /* Owned by consumer probe. */
+};
+
+/* Device links interface. */
+struct device_link *device_link_add(struct device *consumer,
+				    struct device *supplier, u32 flags);
+void device_link_del(struct device_link *link);
+void device_link_remove(void *consumer, struct device *supplier);
+void device_links_supplier_sync_state_pause(void);
+void device_links_supplier_sync_state_resume(void);
+void device_link_wait_removal(void);
+
+static inline bool device_link_test(const struct device_link *link, u32 flags)
+{
+	return !!(link->flags & flags);
+}
+
+#endif /* _DEVICE_LINK_H_ */
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 097be89487bf..38ebd810c1ec 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -60,6 +60,8 @@ struct fwnode_handle {
 	u8 flags;
 };
 
+struct device *get_dev_from_fwnode(struct fwnode_handle *fwnode);
+
 /*
  * fwnode link flags
  *
-- 
2.50.1

[PATCH v1 3/3] driver core: Split device related fwnode API to device/fwnode.h

[Andy Shevchenko]

device.h is a huge header which is hard to follow and easy to miss
something. Improve that by splitting device related fwnode API
to device/fwnode.h.

In particular this helps to speedup the build of the code that includes
device.h solely for a device related fwnode API.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 include/linux/device.h        | 17 +----------------
 include/linux/device/fwnode.h | 28 ++++++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 16 deletions(-)
 create mode 100644 include/linux/device/fwnode.h

diff --git a/include/linux/device.h b/include/linux/device.h
index 4ba6ae72ddf6..d2e2745243ea 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -31,6 +31,7 @@
 #include <linux/device/devlink.h>
 #include <linux/device/devres.h>
 #include <linux/device/driver.h>
+#include <linux/device/fwnode.h>
 #include <linux/device/types.h>
 #include <linux/cleanup.h>
 
@@ -38,8 +39,6 @@ struct device_driver;
 struct module;
 struct class;
 struct subsys_private;
-struct device_node;
-struct fwnode_handle;
 
 /**
  * struct subsys_interface - interfaces to device functions
@@ -603,20 +602,6 @@ int lock_device_hotplug_sysfs(void);
 int device_offline(struct device *dev);
 int device_online(struct device *dev);
 
-void set_primary_fwnode(struct device *dev, struct fwnode_handle *fwnode);
-void set_secondary_fwnode(struct device *dev, struct fwnode_handle *fwnode);
-void device_set_node(struct device *dev, struct fwnode_handle *fwnode);
-int device_add_of_node(struct device *dev, struct device_node *of_node);
-void device_remove_of_node(struct device *dev);
-void device_set_of_node_from_dev(struct device *dev, const struct device *dev2);
-
-static inline struct device_node *dev_of_node(struct device *dev)
-{
-	if (!IS_ENABLED(CONFIG_OF) || !dev)
-		return NULL;
-	return dev->of_node;
-}
-
 static inline int dev_num_vf(struct device *dev)
 {
 	if (dev->bus && dev->bus->num_vf)
diff --git a/include/linux/device/fwnode.h b/include/linux/device/fwnode.h
new file mode 100644
index 000000000000..4fe6107191a6
--- /dev/null
+++ b/include/linux/device/fwnode.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _DEVICE_FWNODE_H_
+#define _DEVICE_FWNODE_H_
+
+#include <linux/stddef.h>
+
+#include "types.h"
+
+struct device_node;
+struct fwnode_handle;
+
+void set_primary_fwnode(struct device *dev, struct fwnode_handle *fwnode);
+void set_secondary_fwnode(struct device *dev, struct fwnode_handle *fwnode);
+
+void device_set_node(struct device *dev, struct fwnode_handle *fwnode);
+
+int device_add_of_node(struct device *dev, struct device_node *of_node);
+void device_remove_of_node(struct device *dev);
+void device_set_of_node_from_dev(struct device *dev, const struct device *dev2);
+
+static inline struct device_node *dev_of_node(struct device *dev)
+{
+	if (!IS_ENABLED(CONFIG_OF) || !dev)
+		return NULL;
+	return dev->of_node;
+}
+
+#endif /* _DEVICE_FWNODE_H_ */
-- 
2.50.1

Re: [PATCH v1 3/3] driver core: Split device related fwnode API to device/fwnode.h

[Rafael J. Wysocki]

On Mon, Feb 23, 2026 at 9:44 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> device.h is a huge header which is hard to follow and easy to miss
> something. Improve that by splitting device related fwnode API
> to device/fwnode.h.
>
> In particular this helps to speedup the build of the code that includes
> device.h solely for a device related fwnode API.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  include/linux/device.h        | 17 +----------------
>  include/linux/device/fwnode.h | 28 ++++++++++++++++++++++++++++

I would call this node.h, so it is less easily confused with
include/linux/fwnode.h and also because it is not just about
fwnode_handle.

>  2 files changed, 29 insertions(+), 16 deletions(-)
>  create mode 100644 include/linux/device/fwnode.h
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 4ba6ae72ddf6..d2e2745243ea 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -31,6 +31,7 @@
>  #include <linux/device/devlink.h>
>  #include <linux/device/devres.h>
>  #include <linux/device/driver.h>
> +#include <linux/device/fwnode.h>
>  #include <linux/device/types.h>
>  #include <linux/cleanup.h>
>
> @@ -38,8 +39,6 @@ struct device_driver;
>  struct module;
>  struct class;
>  struct subsys_private;
> -struct device_node;
> -struct fwnode_handle;
>
>  /**
>   * struct subsys_interface - interfaces to device functions
> @@ -603,20 +602,6 @@ int lock_device_hotplug_sysfs(void);
>  int device_offline(struct device *dev);
>  int device_online(struct device *dev);
>
> -void set_primary_fwnode(struct device *dev, struct fwnode_handle *fwnode);
> -void set_secondary_fwnode(struct device *dev, struct fwnode_handle *fwnode);
> -void device_set_node(struct device *dev, struct fwnode_handle *fwnode);
> -int device_add_of_node(struct device *dev, struct device_node *of_node);
> -void device_remove_of_node(struct device *dev);
> -void device_set_of_node_from_dev(struct device *dev, const struct device *dev2);
> -
> -static inline struct device_node *dev_of_node(struct device *dev)
> -{
> -       if (!IS_ENABLED(CONFIG_OF) || !dev)
> -               return NULL;
> -       return dev->of_node;
> -}
> -
>  static inline int dev_num_vf(struct device *dev)
>  {
>         if (dev->bus && dev->bus->num_vf)
> diff --git a/include/linux/device/fwnode.h b/include/linux/device/fwnode.h
> new file mode 100644
> index 000000000000..4fe6107191a6
> --- /dev/null
> +++ b/include/linux/device/fwnode.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _DEVICE_FWNODE_H_
> +#define _DEVICE_FWNODE_H_
> +
> +#include <linux/stddef.h>
> +
> +#include "types.h"
> +
> +struct device_node;
> +struct fwnode_handle;
> +
> +void set_primary_fwnode(struct device *dev, struct fwnode_handle *fwnode);
> +void set_secondary_fwnode(struct device *dev, struct fwnode_handle *fwnode);
> +
> +void device_set_node(struct device *dev, struct fwnode_handle *fwnode);
> +
> +int device_add_of_node(struct device *dev, struct device_node *of_node);
> +void device_remove_of_node(struct device *dev);
> +void device_set_of_node_from_dev(struct device *dev, const struct device *dev2);
> +
> +static inline struct device_node *dev_of_node(struct device *dev)
> +{
> +       if (!IS_ENABLED(CONFIG_OF) || !dev)
> +               return NULL;
> +       return dev->of_node;
> +}
> +
> +#endif /* _DEVICE_FWNODE_H_ */
> --
> 2.50.1
>

Re: [PATCH v1 1/3] driver core: Split device data types to device/types.h

[Rafael J. Wysocki]

On Mon, Feb 23, 2026 at 9:44 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> device.h is a huge header which is hard to follow and easy to miss
> something. Improve that by splitting device data types to device/types.h.
>
> In particular this helps to speedup the build of the code that includes
> device.h solely for a device data types.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

But why do you want to move the struct device definition out of device.h?

Re: [PATCH v1 2/3] driver core: Split device link data types and API to device/devlink.h

[Rafael J. Wysocki]

On Mon, Feb 23, 2026 at 9:44 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> device.h is a huge header which is hard to follow and easy to miss
> something. Improve that by splitting device link data types and API
> to device/devlink.h.
>
> In particular this helps to speedup the build of the code that includes
> device.h solely for a device link data types and/or API.
>
> Note, get_dev_from_fwnode() goes to include/linux/fwnode.h as it seems
> better to be there (it is on one hand related to device link, but it
> is a getter for struct fwnode_handle respective field).
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  include/linux/device.h         | 86 +-----------------------------
>  include/linux/device/devlink.h | 97 ++++++++++++++++++++++++++++++++++

The name "devlink" is somewhat ambiguous (see
Documentation/netlink/specs/devlink.yaml), so it would be better to
use a full device_link name here IMO.

The change itself looks reasonable to me though.

Re: [PATCH v1 0/3] driver core: Split device.h even more

[Greg Kroah-Hartman]

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

Re: [PATCH v1 3/3] driver core: Split device related fwnode API to device/fwnode.h

[Greg Kroah-Hartman]

On Mon, Feb 23, 2026 at 09:30:32PM +0100, Andy Shevchenko wrote:
> device.h is a huge header which is hard to follow and easy to miss
> something. Improve that by splitting device related fwnode API
> to device/fwnode.h.
> 
> In particular this helps to speedup the build of the code that includes
> device.h solely for a device related fwnode API.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  include/linux/device.h        | 17 +----------------
>  include/linux/device/fwnode.h | 28 ++++++++++++++++++++++++++++
>  2 files changed, 29 insertions(+), 16 deletions(-)
>  create mode 100644 include/linux/device/fwnode.h
> 
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 4ba6ae72ddf6..d2e2745243ea 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -31,6 +31,7 @@
>  #include <linux/device/devlink.h>
>  #include <linux/device/devres.h>
>  #include <linux/device/driver.h>
> +#include <linux/device/fwnode.h>
>  #include <linux/device/types.h>
>  #include <linux/cleanup.h>
>  
> @@ -38,8 +39,6 @@ struct device_driver;
>  struct module;
>  struct class;
>  struct subsys_private;
> -struct device_node;
> -struct fwnode_handle;
>  
>  /**
>   * struct subsys_interface - interfaces to device functions
> @@ -603,20 +602,6 @@ int lock_device_hotplug_sysfs(void);
>  int device_offline(struct device *dev);
>  int device_online(struct device *dev);
>  
> -void set_primary_fwnode(struct device *dev, struct fwnode_handle *fwnode);
> -void set_secondary_fwnode(struct device *dev, struct fwnode_handle *fwnode);
> -void device_set_node(struct device *dev, struct fwnode_handle *fwnode);
> -int device_add_of_node(struct device *dev, struct device_node *of_node);
> -void device_remove_of_node(struct device *dev);
> -void device_set_of_node_from_dev(struct device *dev, const struct device *dev2);
> -
> -static inline struct device_node *dev_of_node(struct device *dev)
> -{
> -	if (!IS_ENABLED(CONFIG_OF) || !dev)
> -		return NULL;
> -	return dev->of_node;
> -}
> -
>  static inline int dev_num_vf(struct device *dev)
>  {
>  	if (dev->bus && dev->bus->num_vf)
> diff --git a/include/linux/device/fwnode.h b/include/linux/device/fwnode.h
> new file mode 100644
> index 000000000000..4fe6107191a6
> --- /dev/null
> +++ b/include/linux/device/fwnode.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _DEVICE_FWNODE_H_
> +#define _DEVICE_FWNODE_H_

You lost the copyright notice.  While not really needed from a legal
point of view, it's not all that nice from a developer point of view :(

Re: [PATCH v1 3/3] driver core: Split device related fwnode API to device/fwnode.h

[Andy Shevchenko]

On Tue, Feb 24, 2026 at 01:33:21AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 23, 2026 at 09:30:32PM +0100, Andy Shevchenko wrote:
> > device.h is a huge header which is hard to follow and easy to miss
> > something. Improve that by splitting device related fwnode API
> > to device/fwnode.h.
> > 
> > In particular this helps to speedup the build of the code that includes
> > device.h solely for a device related fwnode API.

> You lost the copyright notice.  While not really needed from a legal
> point of view, it's not all that nice from a developer point of view :(

Oh, it wasn't my intention, thanks for catching this!
Sure, I will address this important issue.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] driver core: Split device data types to device/types.h

[Andy Shevchenko]

On Mon, Feb 23, 2026 at 09:53:17PM +0100, Rafael J. Wysocki wrote:
> On Mon, Feb 23, 2026 at 9:44 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > device.h is a huge header which is hard to follow and easy to miss
> > something. Improve that by splitting device data types to device/types.h.
> >
> > In particular this helps to speedup the build of the code that includes
> > device.h solely for a device data types.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> But why do you want to move the struct device definition out of device.h?

Because it's a data type, and we have many drivers that may require it
(embed the struct device), but no device.h API is called directly —
only via a certain framework).

device.h also includes many unrelated headers in such a case.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] driver core: Split device data types to device/types.h

[Rafael J. Wysocki]

On Tue, Feb 24, 2026 at 10:05 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Feb 23, 2026 at 09:53:17PM +0100, Rafael J. Wysocki wrote:
> > On Mon, Feb 23, 2026 at 9:44 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > device.h is a huge header which is hard to follow and easy to miss
> > > something. Improve that by splitting device data types to device/types.h.
> > >
> > > In particular this helps to speedup the build of the code that includes
> > > device.h solely for a device data types.
> > >
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > But why do you want to move the struct device definition out of device.h?
>
> Because it's a data type, and we have many drivers that may require it
> (embed the struct device), but no device.h API is called directly —
> only via a certain framework).
>
> device.h also includes many unrelated headers in such a case.

Why is this a problem?

Could those headers be moved to different header files instead?

device.h is mostly about the struct device definition and the other
stuff in it is more or less additional.  Why do you want to make it
the other way around?

Re: [PATCH v1 1/3] driver core: Split device data types to device/types.h

[Greg Kroah-Hartman]

On Tue, Feb 24, 2026 at 01:21:10PM +0100, Rafael J. Wysocki wrote:
> On Tue, Feb 24, 2026 at 10:05 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Mon, Feb 23, 2026 at 09:53:17PM +0100, Rafael J. Wysocki wrote:
> > > On Mon, Feb 23, 2026 at 9:44 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > >
> > > > device.h is a huge header which is hard to follow and easy to miss
> > > > something. Improve that by splitting device data types to device/types.h.
> > > >
> > > > In particular this helps to speedup the build of the code that includes
> > > > device.h solely for a device data types.
> > > >
> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > >
> > > But why do you want to move the struct device definition out of device.h?
> >
> > Because it's a data type, and we have many drivers that may require it
> > (embed the struct device), but no device.h API is called directly —
> > only via a certain framework).
> >
> > device.h also includes many unrelated headers in such a case.
> 
> Why is this a problem?
> 
> Could those headers be moved to different header files instead?
> 
> device.h is mostly about the struct device definition and the other
> stuff in it is more or less additional.  Why do you want to make it
> the other way around?

I agree, this feels wrong.

Re: [PATCH v1 1/3] driver core: Split device data types to device/types.h

[Danilo Krummrich]

On Tue Feb 24, 2026 at 2:17 PM CET, Greg Kroah-Hartman wrote:
> On Tue, Feb 24, 2026 at 01:21:10PM +0100, Rafael J. Wysocki wrote:
>> On Tue, Feb 24, 2026 at 10:05 AM Andy Shevchenko
>> <andriy.shevchenko@linux.intel.com> wrote:
>> >
>> > On Mon, Feb 23, 2026 at 09:53:17PM +0100, Rafael J. Wysocki wrote:
>> > > On Mon, Feb 23, 2026 at 9:44 PM Andy Shevchenko
>> > > <andriy.shevchenko@linux.intel.com> wrote:
>> > > >
>> > > > device.h is a huge header which is hard to follow and easy to miss
>> > > > something. Improve that by splitting device data types to device/types.h.
>> > > >
>> > > > In particular this helps to speedup the build of the code that includes
>> > > > device.h solely for a device data types.
>> > > >
>> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> > >
>> > > But why do you want to move the struct device definition out of device.h?
>> >
>> > Because it's a data type, and we have many drivers that may require it
>> > (embed the struct device), but no device.h API is called directly —
>> > only via a certain framework).
>> >
>> > device.h also includes many unrelated headers in such a case.
>> 
>> Why is this a problem?
>> 
>> Could those headers be moved to different header files instead?
>> 
>> device.h is mostly about the struct device definition and the other
>> stuff in it is more or less additional.  Why do you want to make it
>> the other way around?
>
> I agree, this feels wrong.

To me device/types.h also seems superfluous, the other ones seem OK to me as
they structure things a bit better.

Re: [PATCH v1 1/3] driver core: Split device data types to device/types.h

[Andy Shevchenko]

On Tue, Feb 24, 2026 at 01:21:10PM +0100, Rafael J. Wysocki wrote:
> On Tue, Feb 24, 2026 at 10:05 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Mon, Feb 23, 2026 at 09:53:17PM +0100, Rafael J. Wysocki wrote:
> > > On Mon, Feb 23, 2026 at 9:44 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > >
> > > > device.h is a huge header which is hard to follow and easy to miss
> > > > something. Improve that by splitting device data types to device/types.h.
> > > >
> > > > In particular this helps to speedup the build of the code that includes
> > > > device.h solely for a device data types.
> > > >
> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > >
> > > But why do you want to move the struct device definition out of device.h?
> >
> > Because it's a data type, and we have many drivers that may require it
> > (embed the struct device), but no device.h API is called directly —
> > only via a certain framework).
> >
> > device.h also includes many unrelated headers in such a case.
> 
> Why is this a problem?
> 
> Could those headers be moved to different header files instead?
> 
> device.h is mostly about the struct device definition and the other
> stuff in it is more or less additional.  Why do you want to make it
> the other way around?

It's a common trend in the kernel to split out _types.h and _api.h
(among possibly others). I follow this trend with a correction on
the folder versus prefix. That's why device/types.h.

$ git diff $A..$B --diff-filter=A --name-only -- include/ | grep _types.h

In v6.19:
include/linux/fs/super_types.h
include/linux/irq_work_types.h
include/linux/ns/ns_common_types.h
include/linux/ns/nstree_types.h
include/linux/rseq_types.h

In v6.17:
include/linux/unwind_deferred_types.h
include/linux/unwind_user_types.h

In v6.15
include/linux/resctrl_types.h

In v6.11
include/linux/cpumask_types.h

In v6.8
include/linux/hrtimer_types.h
include/linux/irqflags_types.h
include/linux/mutex_types.h
include/linux/nodemask_types.h
include/linux/pid_types.h
include/linux/plist_types.h
include/linux/posix-timers_types.h
include/linux/refcount_types.h
include/linux/seccomp_types.h
include/linux/sem_types.h
include/linux/seqlock_types.h
include/linux/syscall_user_dispatch_types.h
include/linux/timer_types.h
include/linux/timerqueue_types.h
include/linux/uidgid_types.h
include/linux/workqueue_types.h

In v6.4
include/linux/objtool_types.h

In v6.1
include/linux/cfi_types.h
include/linux/kmsan_types.h

In v6.0
include/linux/gfp_types.h
include/linux/io_uring_types.h

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] driver core: Split device data types to device/types.h

[Andy Shevchenko]

On Tue, Feb 24, 2026 at 05:17:43AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 24, 2026 at 01:21:10PM +0100, Rafael J. Wysocki wrote:
> > On Tue, Feb 24, 2026 at 10:05 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Mon, Feb 23, 2026 at 09:53:17PM +0100, Rafael J. Wysocki wrote:
> > > > On Mon, Feb 23, 2026 at 9:44 PM Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > >
> > > > > device.h is a huge header which is hard to follow and easy to miss
> > > > > something. Improve that by splitting device data types to device/types.h.
> > > > >
> > > > > In particular this helps to speedup the build of the code that includes
> > > > > device.h solely for a device data types.
> > > > >
> > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > >
> > > > But why do you want to move the struct device definition out of device.h?
> > >
> > > Because it's a data type, and we have many drivers that may require it
> > > (embed the struct device), but no device.h API is called directly —
> > > only via a certain framework).
> > >
> > > device.h also includes many unrelated headers in such a case.
> > 
> > Why is this a problem?
> > 
> > Could those headers be moved to different header files instead?
> > 
> > device.h is mostly about the struct device definition and the other
> > stuff in it is more or less additional.  Why do you want to make it
> > the other way around?
> 
> I agree, this feels wrong.

Nobody is going to remove device.h :-)
It's a split based on the trend in the kernel.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 1/3] driver core: Split device data types to device/types.h

[Rafael J. Wysocki]

On Tue, Feb 24, 2026 at 3:02 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Feb 24, 2026 at 05:17:43AM -0800, Greg Kroah-Hartman wrote:
> > On Tue, Feb 24, 2026 at 01:21:10PM +0100, Rafael J. Wysocki wrote:
> > > On Tue, Feb 24, 2026 at 10:05 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Mon, Feb 23, 2026 at 09:53:17PM +0100, Rafael J. Wysocki wrote:
> > > > > On Mon, Feb 23, 2026 at 9:44 PM Andy Shevchenko
> > > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > > >
> > > > > > device.h is a huge header which is hard to follow and easy to miss
> > > > > > something. Improve that by splitting device data types to device/types.h.
> > > > > >
> > > > > > In particular this helps to speedup the build of the code that includes
> > > > > > device.h solely for a device data types.
> > > > > >
> > > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > > >
> > > > > But why do you want to move the struct device definition out of device.h?
> > > >
> > > > Because it's a data type, and we have many drivers that may require it
> > > > (embed the struct device), but no device.h API is called directly —
> > > > only via a certain framework).
> > > >
> > > > device.h also includes many unrelated headers in such a case.
> > >
> > > Why is this a problem?
> > >
> > > Could those headers be moved to different header files instead?
> > >
> > > device.h is mostly about the struct device definition and the other
> > > stuff in it is more or less additional.  Why do you want to make it
> > > the other way around?
> >
> > I agree, this feels wrong.
>
> Nobody is going to remove device.h :-)

And nobody is talking about removing it.

We are simply saying that the definition of struct device should
remain in device.h proper.  I'm not sure what is unclear about that.

> It's a split based on the trend in the kernel.

Well, in this particular case that trend doesn't appear to be helpful.

Re: [PATCH v1 1/3] driver core: Split device data types to device/types.h

[Greg Kroah-Hartman]

On Tue, Feb 24, 2026 at 04:01:38PM +0200, Andy Shevchenko wrote:
> On Tue, Feb 24, 2026 at 01:21:10PM +0100, Rafael J. Wysocki wrote:
> > On Tue, Feb 24, 2026 at 10:05 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Mon, Feb 23, 2026 at 09:53:17PM +0100, Rafael J. Wysocki wrote:
> > > > On Mon, Feb 23, 2026 at 9:44 PM Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > >
> > > > > device.h is a huge header which is hard to follow and easy to miss
> > > > > something. Improve that by splitting device data types to device/types.h.
> > > > >
> > > > > In particular this helps to speedup the build of the code that includes
> > > > > device.h solely for a device data types.
> > > > >
> > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > >
> > > > But why do you want to move the struct device definition out of device.h?
> > >
> > > Because it's a data type, and we have many drivers that may require it
> > > (embed the struct device), but no device.h API is called directly —
> > > only via a certain framework).
> > >
> > > device.h also includes many unrelated headers in such a case.
> > 
> > Why is this a problem?
> > 
> > Could those headers be moved to different header files instead?
> > 
> > device.h is mostly about the struct device definition and the other
> > stuff in it is more or less additional.  Why do you want to make it
> > the other way around?
> 
> It's a common trend in the kernel to split out _types.h and _api.h
> (among possibly others). I follow this trend with a correction on
> the folder versus prefix. That's why device/types.h.
> 
> $ git diff $A..$B --diff-filter=A --name-only -- include/ | grep _types.h
> 
> In v6.19:
> include/linux/fs/super_types.h
> include/linux/irq_work_types.h
> include/linux/ns/ns_common_types.h
> include/linux/ns/nstree_types.h
> include/linux/rseq_types.h

Please no, let's keep things simple.  I only split up device.h because
it made sense for the class/bus stuff to be out of it.  Let's not just
try to make things even more fine-grained for no good reason (speed of
builds, size, etc.), which I do not see justified here at all.

thanks,

greg k-h