2017-11-07 17:30:07 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-06-18 12:34:59 -03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-06 16:00:44 -07:00
|
|
|
|
2005-10-29 19:07:23 +01:00
|
|
|
|
2010-06-08 07:48:20 -06:00
|
|
|
|
2014-04-23 17:57:41 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2020-12-02 18:36:56 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-10-30 15:09:49 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-10-30 15:03:48 -08:00
|
|
|
|
2009-08-20 20:25:32 +02:00
|
|
|
|
2014-09-29 13:58:47 +02:00
|
|
|
|
2012-07-27 22:14:59 +02:00
|
|
|
|
2012-10-31 22:45:02 +01:00
|
|
|
|
2014-06-18 17:29:32 +02:00
|
|
|
|
2014-06-02 19:42:58 -05:00
|
|
|
|
2015-11-30 17:11:38 +02:00
|
|
|
|
2019-01-03 15:29:05 -08:00
|
|
|
|
2019-12-10 17:41:37 -05:00
|
|
|
|
bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management
The devices on platform/amba/fsl-mc/PCI buses could be bound to drivers
with the device DMA managed by kernel drivers or user-space applications.
Unfortunately, multiple devices may be placed in the same IOMMU group
because they cannot be isolated from each other. The DMA on these devices
must either be entirely under kernel control or userspace control, never
a mixture. Otherwise the driver integrity is not guaranteed because they
could access each other through the peer-to-peer accesses which by-pass
the IOMMU protection.
This checks and sets the default DMA mode during driver binding, and
cleanups during driver unbinding. In the default mode, the device DMA is
managed by the device driver which handles DMA operations through the
kernel DMA APIs (see Documentation/core-api/dma-api.rst).
For cases where the devices are assigned for userspace control through the
userspace driver framework(i.e. VFIO), the drivers(for example, vfio_pci/
vfio_platfrom etc.) may set a new flag (driver_managed_dma) to skip this
default setting in the assumption that the drivers know what they are
doing with the device DMA.
Calling iommu_device_use_default_domain() before {of,acpi}_dma_configure
is currently a problem. As things stand, the IOMMU driver ignored the
initial iommu_probe_device() call when the device was added, since at
that point it had no fwspec yet. In this situation,
{of,acpi}_iommu_configure() are retriggering iommu_probe_device() after
the IOMMU driver has seen the firmware data via .of_xlate to learn that
it actually responsible for the given device. As the result, before
that gets fixed, iommu_use_default_domain() goes at the end, and calls
arch_teardown_dma_ops() if it fails.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Stuart Yoder <stuyoder@gmail.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Link: https://lore.kernel.org/r/20220418005000.897664-5-baolu.lu@linux.intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-04-18 08:49:53 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-10-13 17:54:41 +01:00
|
|
|
|
2012-08-06 01:45:11 +02:00
|
|
|
|
2005-10-13 17:54:41 +01:00
|
|
|
|
2012-07-27 22:14:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-10-30 01:36:48 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-12-10 01:36:28 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-09 23:04:40 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-12-10 17:41:37 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-15 22:05:15 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-10 01:36:28 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-12-09 22:36:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-22 10:43:14 +02:00
|
|
|
|
2020-03-24 00:06:08 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-09 23:04:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-24 00:06:08 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-20 11:12:39 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-01 10:16:35 +02:00
|
|
|
|
2019-02-20 11:12:39 +00:00
|
|
|
|
2020-09-09 23:04:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-20 11:12:39 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-24 00:06:12 +08:00
|
|
|
|
2019-02-20 11:12:39 +00:00
|
|
|
|
|
|
|
|
|
2019-10-22 10:43:14 +02:00
|
|
|
|
2019-10-22 10:43:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-09 23:04:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-22 10:43:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-21 17:26:27 +01:00
|
|
|
|
2019-02-20 11:12:39 +00:00
|
|
|
|
2021-04-07 11:47:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
2012-10-29 23:26:56 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-31 17:59:36 +03:00
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
|
|
|
|
|
2012-10-29 23:26:56 +00:00
|
|
|
|
2023-10-03 17:21:22 +03:00
|
|
|
|
2014-04-23 17:57:41 -05:00
|
|
|
|
2014-06-17 15:51:02 -07:00
|
|
|
|
2023-10-03 17:21:22 +03:00
|
|
|
|
|
|
|
|
|
2016-07-04 01:04:24 +03:00
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
2014-06-17 15:51:02 -07:00
|
|
|
|
2014-04-23 17:57:41 -05:00
|
|
|
|
|
|
|
|
|
2023-10-03 17:21:22 +03:00
|
|
|
|
2017-02-02 18:23:58 -05:00
|
|
|
|
2023-10-03 17:21:22 +03:00
|
|
|
|
2017-02-02 18:23:58 -05:00
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
2017-02-02 18:23:58 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-02-18 17:12:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-13 20:32:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-31 17:59:36 +03:00
|
|
|
|
|
|
|
|
|
2016-09-13 20:32:44 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-02-11 11:01:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-03 17:21:22 +03:00
|
|
|
|
|
|
|
|
|
2019-07-29 13:49:54 -07:00
|
|
|
|
|
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
2019-07-29 13:49:54 -07:00
|
|
|
|
2019-02-11 11:01:12 -08:00
|
|
|
|
2012-10-29 23:26:56 +00:00
|
|
|
|
2021-03-31 17:59:36 +03:00
|
|
|
|
|
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
2022-03-11 22:35:29 +03:00
|
|
|
|
|
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-10-09 11:37:46 +02:00
|
|
|
|
2019-07-29 22:38:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-14 18:48:45 +02:00
|
|
|
|
|
|
|
|
|
2019-07-29 22:38:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
2019-07-29 22:38:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-07 11:47:56 +02:00
|
|
|
|
2021-11-05 15:15:09 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-29 22:38:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-10 01:36:28 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-01-06 17:12:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-07 11:47:56 +02:00
|
|
|
|
2016-01-06 17:12:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-02 18:36:56 +08:00
|
|
|
|
|
|
|
|
|
2023-10-06 13:17:49 -07:00
|
|
|
|
2020-12-02 18:36:56 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-03 17:21:22 +03:00
|
|
|
|
2020-12-02 18:36:56 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-21 22:30:55 +08:00
|
|
|
|
|
|
|
|
|
2020-12-02 18:36:56 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
2009-04-27 02:38:16 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-12-10 17:41:37 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-23 17:10:00 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-15 22:05:15 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-10 01:36:28 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-10-05 23:04:47 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-05-20 13:42:02 +03:00
|
|
|
|
2019-10-23 15:25:05 +03:00
|
|
|
|
2014-05-20 13:42:02 +03:00
|
|
|
|
2022-11-11 17:45:42 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-05-20 13:42:02 +03:00
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
2022-03-11 22:35:29 +03:00
|
|
|
|
|
|
|
|
|
2019-07-29 22:38:43 -07:00
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
2019-07-29 22:38:43 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-10-05 23:04:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
2019-10-05 23:04:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-04 23:25:23 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-05 23:04:47 +02:00
|
|
|
|
|
|
|
|
|
2005-12-10 01:36:28 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-10-05 23:04:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-16 16:43:38 -05:00
|
|
|
|
2019-10-05 23:04:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-20 14:21:16 +05:30
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-10 01:36:28 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
driver core/platform: remove unused implicit padding in platform_object
Up to 7 bytes are wasted at the end of struct platform_object
in the form of padding after name field: unfortunately this
padding is not used when allocating the memory to hold the
name.
This patch converts name array from name[1] to C99 flexible
array name[] (equivalent to name[0]) so that no padding is
required by the presence of this field. Memory allocation
is updated to take care of allocating an additional byte for
the NUL terminating character.
Built on Fedora 20, using GCC 4.8, for ARM, i386, SPARC64 and
x86_64 architectures, the data structure layout can be reported
with following command:
$ pahole drivers/base/platform.o \
--recursive \
--class_name device,pdev_archdata,platform_device,platform_object
Please find below some comparisons of structure layout for arm,
i386, sparc64 and x86_64 architecture before and after the patch.
--- obj-arm/drivers/base/platform.o.pahole.v3.15-rc7-79-gfe45736f4134 2014-05-30 10:32:06.290960701 +0200
+++ obj-arm/drivers/base/platform.o.pahole.v3.15-rc7-80-g2cdb06858d71 2014-05-30 11:26:20.851988347 +0200
@@ -81,10 +81,9 @@
/* XXX last struct has 4 bytes of padding */
/* --- cacheline 6 boundary (384 bytes) was 8 bytes ago --- */
- char name[1]; /* 392 1 */
+ char name[0]; /* 392 0 */
- /* size: 400, cachelines: 7, members: 2 */
- /* padding: 7 */
+ /* size: 392, cachelines: 7, members: 2 */
/* paddings: 1, sum paddings: 4 */
- /* last cacheline: 16 bytes */
+ /* last cacheline: 8 bytes */
};
--- obj-i386/drivers/base/platform.o.pahole.v3.15-rc7-79-gfe45736f4134 2014-05-30 10:32:06.305960691 +0200
+++ obj-i386/drivers/base/platform.o.pahole.v3.15-rc7-80-g2cdb06858d71 2014-05-30 11:26:20.875988332 +0200
@@ -73,9 +73,8 @@
struct platform_object {
struct platform_device pdev; /* 0 396 */
/* --- cacheline 6 boundary (384 bytes) was 12 bytes ago --- */
- char name[1]; /* 396 1 */
+ char name[0]; /* 396 0 */
- /* size: 400, cachelines: 7, members: 2 */
- /* padding: 3 */
- /* last cacheline: 16 bytes */
+ /* size: 396, cachelines: 7, members: 2 */
+ /* last cacheline: 12 bytes */
};
--- obj-sparc64/drivers/base/platform.o.pahole.v3.15-rc7-79-gfe45736f4134 2014-05-30 10:32:06.406960625 +0200
+++ obj-sparc64/drivers/base/platform.o.pahole.v3.15-rc7-80-g2cdb06858d71 2014-05-30 11:26:20.971988269 +0200
@@ -94,9 +94,8 @@
struct platform_object {
struct platform_device pdev; /* 0 2208 */
/* --- cacheline 34 boundary (2176 bytes) was 32 bytes ago --- */
- char name[1]; /* 2208 1 */
+ char name[0]; /* 2208 0 */
- /* size: 2216, cachelines: 35, members: 2 */
- /* padding: 7 */
- /* last cacheline: 40 bytes */
+ /* size: 2208, cachelines: 35, members: 2 */
+ /* last cacheline: 32 bytes */
};
--- obj-x86_64/drivers/base/platform.o.pahole.v3.15-rc7-79-gfe45736f4134 2014-05-30 10:32:06.432960608 +0200
+++ obj-x86_64/drivers/base/platform.o.pahole.v3.15-rc7-80-g2cdb06858d71 2014-05-30 11:26:21.000988250 +0200
@@ -84,9 +84,8 @@
struct platform_object {
struct platform_device pdev; /* 0 720 */
/* --- cacheline 11 boundary (704 bytes) was 16 bytes ago --- */
- char name[1]; /* 720 1 */
+ char name[0]; /* 720 0 */
- /* size: 728, cachelines: 12, members: 2 */
- /* padding: 7 */
- /* last cacheline: 24 bytes */
+ /* size: 720, cachelines: 12, members: 2 */
+ /* last cacheline: 16 bytes */
};
Changes from v5 [1]:
- dropped dma_mask allocation changes and only kept padding
removal changes (name array length set to 0).
Changes from v4 [2]:
[by Emil Goode <emilgoode@gmail.com>:]
- Split v4 of the patch into two separate patches.
- Generated new object file size and data structure layout info.
- Updated the changelog message.
Changes from v3 [3]:
- fixed commit message so that git am doesn't fail.
Changes from v2 [4]:
- move 'dma_mask' to platform_object so that it's always
allocated and won't leak on release; remove all previously
added support functions.
- use C99 flexible array member for 'name' to remove padding
at the end of platform_object.
Changes from v1 [5]:
- remove unneeded kfree() from error path
- add reference to author/commit adding allocation of dmamask
Changes from v0 [6]:
- small rewrite to squeeze the patch to a bare minimal
[1] http://lkml.kernel.org/r/1401122483-31603-2-git-send-email-emilgoode@gmail.com
http://lkml.kernel.org/r/1401122483-31603-1-git-send-email-emilgoode@gmail.com
http://lkml.kernel.org/r/1401122483-31603-3-git-send-email-emilgoode@gmail.com
[2] http://lkml.kernel.org/r/1390817152-30898-1-git-send-email-ydroneaud@opteya.com
https://patchwork.kernel.org/patch/3541871/
[3] http://lkml.kernel.org/r/1390771138-28348-1-git-send-email-ydroneaud@opteya.com
https://patchwork.kernel.org/patch/3540081/
[4] http://lkml.kernel.org/r/1389683909-17495-1-git-send-email-ydroneaud@opteya.com
https://patchwork.kernel.org/patch/3484411/
[5] http://lkml.kernel.org/r/1389649085-7365-1-git-send-email-ydroneaud@opteya.com
https://patchwork.kernel.org/patch/3480961/
[6] http://lkml.kernel.org/r/1386886207-2735-1-git-send-email-ydroneaud@opteya.com
Cc: Emil Goode <emilgoode@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Olof Johansson <olof@lixom.net>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-30 22:02:47 +02:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
2019-08-16 08:24:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-22 12:09:54 +02:00
|
|
|
|
|
|
|
|
|
2019-08-16 08:24:35 +02:00
|
|
|
|
|
|
|
|
|
driver code: clarify and fix platform device DMA mask allocation
This does three inter-related things to clarify the usage of the
platform device dma_mask field. In the process, fix the bug introduced
by cdfee5623290 ("driver core: initialize a default DMA mask for
platform device") that caused Artem Tashkinov's laptop to not boot with
newer Fedora kernels.
This does:
- First off, rename the field to "platform_dma_mask" to make it
greppable.
We have way too many different random fields called "dma_mask" in
various data structures, where some of them are actual masks, and
some of them are just pointers to the mask. And the structures all
have pointers to each other, or embed each other inside themselves,
and "pdev" sometimes means "platform device" and sometimes it means
"PCI device".
So to make it clear in the code when you actually use this new field,
give it a unique name (it really should be something even more unique
like "platform_device_dma_mask", since it's per platform device, not
per platform, but that gets old really fast, and this is unique
enough in context).
To further clarify when the field gets used, initialize it when we
actually start using it with the default value.
- Then, use this field instead of the random one-off allocation in
platform_device_register_full() that is now unnecessary since we now
already have a perfectly fine allocation for it in the platform
device structure.
- The above then allows us to fix the actual bug, where the error path
of platform_device_register_full() would unconditionally free the
platform device DMA allocation with 'kfree()'.
That kfree() was dont regardless of whether the allocation had been
done earlier with the (now removed) kmalloc, or whether
setup_pdev_dma_masks() had already been used and the dma_mask pointer
pointed to the mask that was part of the platform device.
It seems most people never triggered the error path, or only triggered
it from a call chain that set an explicit pdevinfo->dma_mask value (and
thus caused the unnecessary allocation that was "cleaned up" in the
error path) before calling platform_device_register_full().
Robin Murphy points out that in Artem's case the wdat_wdt driver failed
in platform_device_add(), and that was the one that had called
platform_device_register_full() with pdevinfo.dma_mask = 0, and would
have caused that kfree() of pdev.dma_mask corrupting the heap.
A later unrelated kmalloc() then oopsed due to the heap corruption.
Fixes: cdfee5623290 ("driver core: initialize a default DMA mask for platform device")
Reported-bisected-and-tested-by: Artem S. Tashkinov <aros@gmx.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-03-11 17:07:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-16 08:24:35 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-02-14 14:18:53 +00:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-03 20:21:41 +02:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2021-02-11 17:27:45 -06:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2011-04-08 00:43:01 +02:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2014-06-02 19:42:58 -05:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-14 14:18:53 +00:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2007-09-09 12:54:16 +02:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
driver core/platform: remove unused implicit padding in platform_object
Up to 7 bytes are wasted at the end of struct platform_object
in the form of padding after name field: unfortunately this
padding is not used when allocating the memory to hold the
name.
This patch converts name array from name[1] to C99 flexible
array name[] (equivalent to name[0]) so that no padding is
required by the presence of this field. Memory allocation
is updated to take care of allocating an additional byte for
the NUL terminating character.
Built on Fedora 20, using GCC 4.8, for ARM, i386, SPARC64 and
x86_64 architectures, the data structure layout can be reported
with following command:
$ pahole drivers/base/platform.o \
--recursive \
--class_name device,pdev_archdata,platform_device,platform_object
Please find below some comparisons of structure layout for arm,
i386, sparc64 and x86_64 architecture before and after the patch.
--- obj-arm/drivers/base/platform.o.pahole.v3.15-rc7-79-gfe45736f4134 2014-05-30 10:32:06.290960701 +0200
+++ obj-arm/drivers/base/platform.o.pahole.v3.15-rc7-80-g2cdb06858d71 2014-05-30 11:26:20.851988347 +0200
@@ -81,10 +81,9 @@
/* XXX last struct has 4 bytes of padding */
/* --- cacheline 6 boundary (384 bytes) was 8 bytes ago --- */
- char name[1]; /* 392 1 */
+ char name[0]; /* 392 0 */
- /* size: 400, cachelines: 7, members: 2 */
- /* padding: 7 */
+ /* size: 392, cachelines: 7, members: 2 */
/* paddings: 1, sum paddings: 4 */
- /* last cacheline: 16 bytes */
+ /* last cacheline: 8 bytes */
};
--- obj-i386/drivers/base/platform.o.pahole.v3.15-rc7-79-gfe45736f4134 2014-05-30 10:32:06.305960691 +0200
+++ obj-i386/drivers/base/platform.o.pahole.v3.15-rc7-80-g2cdb06858d71 2014-05-30 11:26:20.875988332 +0200
@@ -73,9 +73,8 @@
struct platform_object {
struct platform_device pdev; /* 0 396 */
/* --- cacheline 6 boundary (384 bytes) was 12 bytes ago --- */
- char name[1]; /* 396 1 */
+ char name[0]; /* 396 0 */
- /* size: 400, cachelines: 7, members: 2 */
- /* padding: 3 */
- /* last cacheline: 16 bytes */
+ /* size: 396, cachelines: 7, members: 2 */
+ /* last cacheline: 12 bytes */
};
--- obj-sparc64/drivers/base/platform.o.pahole.v3.15-rc7-79-gfe45736f4134 2014-05-30 10:32:06.406960625 +0200
+++ obj-sparc64/drivers/base/platform.o.pahole.v3.15-rc7-80-g2cdb06858d71 2014-05-30 11:26:20.971988269 +0200
@@ -94,9 +94,8 @@
struct platform_object {
struct platform_device pdev; /* 0 2208 */
/* --- cacheline 34 boundary (2176 bytes) was 32 bytes ago --- */
- char name[1]; /* 2208 1 */
+ char name[0]; /* 2208 0 */
- /* size: 2216, cachelines: 35, members: 2 */
- /* padding: 7 */
- /* last cacheline: 40 bytes */
+ /* size: 2208, cachelines: 35, members: 2 */
+ /* last cacheline: 32 bytes */
};
--- obj-x86_64/drivers/base/platform.o.pahole.v3.15-rc7-79-gfe45736f4134 2014-05-30 10:32:06.432960608 +0200
+++ obj-x86_64/drivers/base/platform.o.pahole.v3.15-rc7-80-g2cdb06858d71 2014-05-30 11:26:21.000988250 +0200
@@ -84,9 +84,8 @@
struct platform_object {
struct platform_device pdev; /* 0 720 */
/* --- cacheline 11 boundary (704 bytes) was 16 bytes ago --- */
- char name[1]; /* 720 1 */
+ char name[0]; /* 720 0 */
- /* size: 728, cachelines: 12, members: 2 */
- /* padding: 7 */
- /* last cacheline: 24 bytes */
+ /* size: 720, cachelines: 12, members: 2 */
+ /* last cacheline: 16 bytes */
};
Changes from v5 [1]:
- dropped dma_mask allocation changes and only kept padding
removal changes (name array length set to 0).
Changes from v4 [2]:
[by Emil Goode <emilgoode@gmail.com>:]
- Split v4 of the patch into two separate patches.
- Generated new object file size and data structure layout info.
- Updated the changelog message.
Changes from v3 [3]:
- fixed commit message so that git am doesn't fail.
Changes from v2 [4]:
- move 'dma_mask' to platform_object so that it's always
allocated and won't leak on release; remove all previously
added support functions.
- use C99 flexible array member for 'name' to remove padding
at the end of platform_object.
Changes from v1 [5]:
- remove unneeded kfree() from error path
- add reference to author/commit adding allocation of dmamask
Changes from v0 [6]:
- small rewrite to squeeze the patch to a bare minimal
[1] http://lkml.kernel.org/r/1401122483-31603-2-git-send-email-emilgoode@gmail.com
http://lkml.kernel.org/r/1401122483-31603-1-git-send-email-emilgoode@gmail.com
http://lkml.kernel.org/r/1401122483-31603-3-git-send-email-emilgoode@gmail.com
[2] http://lkml.kernel.org/r/1390817152-30898-1-git-send-email-ydroneaud@opteya.com
https://patchwork.kernel.org/patch/3541871/
[3] http://lkml.kernel.org/r/1390771138-28348-1-git-send-email-ydroneaud@opteya.com
https://patchwork.kernel.org/patch/3540081/
[4] http://lkml.kernel.org/r/1389683909-17495-1-git-send-email-ydroneaud@opteya.com
https://patchwork.kernel.org/patch/3484411/
[5] http://lkml.kernel.org/r/1389649085-7365-1-git-send-email-ydroneaud@opteya.com
https://patchwork.kernel.org/patch/3480961/
[6] http://lkml.kernel.org/r/1386886207-2735-1-git-send-email-ydroneaud@opteya.com
Cc: Emil Goode <emilgoode@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Olof Johansson <olof@lixom.net>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-30 22:02:47 +02:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-08-16 08:24:35 +02:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
2005-12-10 01:36:27 -05:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-14 14:18:53 +00:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
2009-01-28 21:01:02 +01:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2011-04-20 09:44:44 +02:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2011-04-20 09:44:44 +02:00
|
|
|
|
2024-06-06 19:49:26 +03:00
|
|
|
|
2011-04-20 09:44:44 +02:00
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2011-04-20 09:44:44 +02:00
|
|
|
|
2011-04-20 09:44:45 +02:00
|
|
|
|
2011-04-20 09:44:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-02-14 14:18:53 +00:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2011-04-20 09:44:42 +02:00
|
|
|
|
2010-09-07 17:31:49 +04:00
|
|
|
|
2011-04-20 09:44:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2011-04-20 09:44:42 +02:00
|
|
|
|
2011-04-20 09:44:43 +02:00
|
|
|
|
2011-04-20 09:44:42 +02:00
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-10-03 17:21:21 +03:00
|
|
|
|
2019-12-10 17:41:37 -05:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-10-03 17:21:21 +03:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-10-03 17:21:21 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-07-27 22:14:59 +02:00
|
|
|
|
|
|
|
|
|
2023-10-03 17:21:21 +03:00
|
|
|
|
2012-07-27 22:14:59 +02:00
|
|
|
|
|
|
|
|
|
2023-10-03 17:21:21 +03:00
|
|
|
|
2012-07-27 22:14:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-09 20:02:48 +02:00
|
|
|
|
2012-07-27 22:14:59 +02:00
|
|
|
|
2023-10-03 17:21:20 +03:00
|
|
|
|
2012-07-27 22:14:59 +02:00
|
|
|
|
|
|
|
|
|
2023-10-03 17:21:21 +03:00
|
|
|
|
2012-07-27 22:14:59 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-06-10 08:38:02 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-10-03 17:21:21 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-10 08:38:29 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-06-10 08:38:29 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-04 11:11:58 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-03 17:21:21 +03:00
|
|
|
|
2019-04-04 11:11:58 +03:00
|
|
|
|
|
|
|
|
|
2015-06-10 08:38:02 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2023-10-03 17:21:21 +03:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-10-03 17:21:21 +03:00
|
|
|
|
2023-10-03 17:21:20 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-10 08:36:50 -07:00
|
|
|
|
2015-06-10 08:38:02 -07:00
|
|
|
|
2015-06-10 08:36:50 -07:00
|
|
|
|
2020-09-09 20:02:48 +02:00
|
|
|
|
2015-06-10 08:36:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-16 17:57:58 +00:00
|
|
|
|
2015-06-10 08:36:50 -07:00
|
|
|
|
drivercore: Fix unregistration path of platform devices
The unregister path of platform_device is broken. On registration, it
will register all resources with either a parent already set, or
type==IORESOURCE_{IO,MEM}. However, on unregister it will release
everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There
are also cases where resources don't get registered in the first place,
like with devices created by of_platform_populate()*.
Fix the unregister path to be symmetrical with the register path by
checking the parent pointer instead of the type field to decide which
resources to unregister. This is safe because the upshot of the
registration path algorithm is that registered resources have a parent
pointer, and non-registered resources do not.
* It can be argued that of_platform_populate() should be registering
it's resources, and they argument has some merit. However, there are
quite a few platforms that end up broken if we try to do that due to
overlapping resources in the device tree. Until that is fixed, we need
to solve the immediate problem.
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Tested-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
2015-06-07 15:20:11 +01:00
|
|
|
|
2015-06-10 08:36:50 -07:00
|
|
|
|
|
|
|
|
|
2008-10-15 22:05:15 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-11-05 21:19:33 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-12-10 01:36:27 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-12-10 17:41:37 -05:00
|
|
|
|
2008-10-15 22:05:15 -07:00
|
|
|
|
2018-12-03 20:21:41 +02:00
|
|
|
|
2015-06-10 08:36:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-09 20:02:48 +02:00
|
|
|
|
2015-06-10 08:36:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
drivercore: Fix unregistration path of platform devices
The unregister path of platform_device is broken. On registration, it
will register all resources with either a parent already set, or
type==IORESOURCE_{IO,MEM}. However, on unregister it will release
everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There
are also cases where resources don't get registered in the first place,
like with devices created by of_platform_populate()*.
Fix the unregister path to be symmetrical with the register path by
checking the parent pointer instead of the type field to decide which
resources to unregister. This is safe because the upshot of the
registration path algorithm is that registered resources have a parent
pointer, and non-registered resources do not.
* It can be argued that of_platform_populate() should be registering
it's resources, and they argument has some merit. However, there are
quite a few platforms that end up broken if we try to do that due to
overlapping resources in the device tree. Until that is fixed, we need
to solve the immediate problem.
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Tested-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: stable@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
2015-06-07 15:20:11 +01:00
|
|
|
|
2015-06-10 08:36:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-12-10 01:36:27 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
2021-12-22 11:42:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-10 01:36:27 -05:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
2005-12-10 01:36:27 -05:00
|
|
|
|
|
|
|
|
|
2019-08-16 08:24:35 +02:00
|
|
|
|
2005-12-10 01:36:27 -05:00
|
|
|
|
|
|
|
|
|
2005-12-10 01:36:28 -05:00
|
|
|
|
2005-12-10 01:36:27 -05:00
|
|
|
|
|
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
2005-12-10 01:36:27 -05:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-10 01:36:27 -05:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
2005-12-10 01:36:27 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-10 01:36:28 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-08-25 11:16:00 +02:00
|
|
|
|
2010-06-21 16:11:44 +02:00
|
|
|
|
2007-05-08 00:29:39 -07:00
|
|
|
|
2011-08-25 11:16:00 +02:00
|
|
|
|
2008-09-22 14:41:40 -07:00
|
|
|
|
2010-03-11 18:11:45 +02:00
|
|
|
|
2008-09-22 14:41:40 -07:00
|
|
|
|
2011-08-25 11:16:00 +02:00
|
|
|
|
2011-12-08 22:53:29 +01:00
|
|
|
|
2008-09-22 14:41:40 -07:00
|
|
|
|
2020-04-02 12:13:41 +01:00
|
|
|
|
2008-09-22 14:41:40 -07:00
|
|
|
|
|
|
|
|
|
2011-08-25 11:16:00 +02:00
|
|
|
|
2010-06-21 16:11:44 +02:00
|
|
|
|
2019-03-01 13:24:47 +01:00
|
|
|
|
2011-08-25 11:16:00 +02:00
|
|
|
|
|
|
|
|
|
2015-03-16 23:49:03 +01:00
|
|
|
|
2019-02-21 11:29:35 +00:00
|
|
|
|
|
|
|
|
|
2011-08-25 11:16:00 +02:00
|
|
|
|
|
|
|
|
|
driver code: clarify and fix platform device DMA mask allocation
This does three inter-related things to clarify the usage of the
platform device dma_mask field. In the process, fix the bug introduced
by cdfee5623290 ("driver core: initialize a default DMA mask for
platform device") that caused Artem Tashkinov's laptop to not boot with
newer Fedora kernels.
This does:
- First off, rename the field to "platform_dma_mask" to make it
greppable.
We have way too many different random fields called "dma_mask" in
various data structures, where some of them are actual masks, and
some of them are just pointers to the mask. And the structures all
have pointers to each other, or embed each other inside themselves,
and "pdev" sometimes means "platform device" and sometimes it means
"PCI device".
So to make it clear in the code when you actually use this new field,
give it a unique name (it really should be something even more unique
like "platform_device_dma_mask", since it's per platform device, not
per platform, but that gets old really fast, and this is unique
enough in context).
To further clarify when the field gets used, initialize it when we
actually start using it with the default value.
- Then, use this field instead of the random one-off allocation in
platform_device_register_full() that is now unnecessary since we now
already have a perfectly fine allocation for it in the platform
device structure.
- The above then allows us to fix the actual bug, where the error path
of platform_device_register_full() would unconditionally free the
platform device DMA allocation with 'kfree()'.
That kfree() was dont regardless of whether the allocation had been
done earlier with the (now removed) kmalloc, or whether
setup_pdev_dma_masks() had already been used and the dma_mask pointer
pointed to the mask that was part of the platform device.
It seems most people never triggered the error path, or only triggered
it from a call chain that set an explicit pdevinfo->dma_mask value (and
thus caused the unnecessary allocation that was "cleaned up" in the
error path) before calling platform_device_register_full().
Robin Murphy points out that in Artem's case the wdat_wdt driver failed
in platform_device_add(), and that was the one that had called
platform_device_register_full() with pdevinfo.dma_mask = 0, and would
have caused that kfree() of pdev.dma_mask corrupting the heap.
A later unrelated kmalloc() then oopsed due to the heap corruption.
Fixes: cdfee5623290 ("driver core: initialize a default DMA mask for platform device")
Reported-bisected-and-tested-by: Artem S. Tashkinov <aros@gmx.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-03-11 17:07:10 +01:00
|
|
|
|
|
|
|
|
|
2011-08-25 11:16:00 +02:00
|
|
|
|
|
|
|
|
|
2008-09-22 14:41:40 -07:00
|
|
|
|
2011-08-25 11:16:00 +02:00
|
|
|
|
|
|
|
|
|
2010-09-07 17:31:54 +04:00
|
|
|
|
|
|
|
|
|
2010-06-21 16:11:44 +02:00
|
|
|
|
2011-08-25 11:16:00 +02:00
|
|
|
|
|
|
|
|
|
2010-09-07 17:31:54 +04:00
|
|
|
|
|
|
|
|
|
2008-09-22 14:41:40 -07:00
|
|
|
|
2016-03-29 14:52:23 +03:00
|
|
|
|
2021-08-17 13:24:49 +03:00
|
|
|
|
|
|
|
|
|
2015-11-30 17:11:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-21 16:11:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it. Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.
The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.
First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
2013-11-11 22:41:56 +01:00
|
|
|
|
2010-06-21 16:11:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-22 14:41:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-25 11:16:00 +02:00
|
|
|
|
2008-09-22 14:41:40 -07:00
|
|
|
|
2005-11-09 17:23:39 +00:00
|
|
|
|
2013-05-25 12:40:50 +08:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
2013-07-14 17:43:06 -07:00
|
|
|
|
2005-11-09 17:23:39 +00:00
|
|
|
|
2013-05-25 12:40:50 +08:00
|
|
|
|
|
|
|
|
|
2005-11-09 17:23:39 +00:00
|
|
|
|
2013-05-25 12:40:50 +08:00
|
|
|
|
2005-11-09 17:23:39 +00:00
|
|
|
|
2009-06-04 22:13:33 +02:00
|
|
|
|
2005-11-09 17:23:39 +00:00
|
|
|
|
|
|
|
|
|
2013-05-25 12:40:50 +08:00
|
|
|
|
2005-11-09 17:23:39 +00:00
|
|
|
|
|
|
|
|
|
2010-02-14 14:18:53 +00:00
|
|
|
|
2008-01-24 22:50:12 -08:00
|
|
|
|
2005-11-09 17:23:39 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-19 13:46:10 +01:00
|
|
|
|
2020-11-19 13:46:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-31 09:24:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-16 23:28:47 -08:00
|
|
|
|
2014-10-28 17:40:41 +01:00
|
|
|
|
2006-11-16 23:28:47 -08:00
|
|
|
|
2013-09-23 16:27:26 +02:00
|
|
|
|
2014-10-28 17:40:41 +01:00
|
|
|
|
2006-11-16 23:28:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-23 16:27:26 +02:00
|
|
|
|
2013-03-26 10:35:15 +01:00
|
|
|
|
2006-11-16 23:28:47 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-28 17:40:41 +01:00
|
|
|
|
|
|
|
|
|
2006-11-16 23:28:47 -08:00
|
|
|
|
2023-01-31 09:24:58 +01:00
|
|
|
|
2006-11-16 23:28:47 -08:00
|
|
|
|
2015-03-30 16:20:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-23 16:27:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-12 20:17:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-16 23:28:47 -08:00
|
|
|
|
|
|
|
|
|
2023-01-31 09:24:58 +01:00
|
|
|
|
2020-04-08 14:40:03 -07:00
|
|
|
|
|
|
|
|
|
2006-11-16 23:28:47 -08:00
|
|
|
|
2023-01-31 09:24:59 +01:00
|
|
|
|
2020-11-19 13:46:10 +01:00
|
|
|
|
2006-11-16 23:28:47 -08:00
|
|
|
|
2023-01-31 09:24:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-16 23:28:47 -08:00
|
|
|
|
2023-01-31 09:24:59 +01:00
|
|
|
|
|
|
|
|
|
2006-11-16 23:28:47 -08:00
|
|
|
|
|
|
|
|
|
2014-10-28 17:40:41 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-29 20:11:20 -08:00
|
|
|
|
2014-10-28 17:40:42 +01:00
|
|
|
|
2009-12-29 20:11:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-28 17:40:42 +01:00
|
|
|
|
2009-12-29 20:11:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-11 18:11:45 +02:00
|
|
|
|
|
|
|
|
|
2009-12-29 20:11:20 -08:00
|
|
|
|
2014-10-28 17:40:42 +01:00
|
|
|
|
2009-12-29 20:11:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-28 17:40:42 +01:00
|
|
|
|
2009-12-29 20:11:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-30 18:36:27 +08:00
|
|
|
|
2009-12-29 20:11:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-07 17:31:54 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-29 20:11:20 -08:00
|
|
|
|
2010-09-07 17:31:54 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-29 20:11:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-28 17:40:42 +01:00
|
|
|
|
2009-12-29 20:11:20 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-10-28 17:40:42 +01:00
|
|
|
|
2009-12-29 20:11:20 -08:00
|
|
|
|
2015-09-25 17:29:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-20 22:12:02 +08:00
|
|
|
|
2015-09-25 17:29:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-04 11:52:40 +08:00
|
|
|
|
2010-01-26 09:35:00 +01:00
|
|
|
|
2009-02-04 11:52:40 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-29 19:49:21 +02:00
|
|
|
|
2009-02-04 11:52:40 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-06-04 22:13:33 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-06-04 22:13:33 +02:00
|
|
|
|
|
|
|
|
|
2006-09-03 13:16:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-06-04 22:13:33 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-06-04 22:13:33 +02:00
|
|
|
|
|
|
|
|
|
2005-10-28 09:52:56 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-29 00:36:05 +02:00
|
|
|
|
2009-08-20 20:25:32 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
2011-04-29 00:36:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
2024-06-11 15:01:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
2008-10-06 22:46:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-29 00:36:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
2024-06-11 15:01:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
2008-10-06 22:46:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-29 00:36:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
2011-04-11 22:54:42 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
2011-04-29 00:36:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
2024-06-11 15:01:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-29 00:36:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
2024-06-11 15:01:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
2008-10-06 22:46:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-29 00:36:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
2024-06-11 15:01:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
2008-10-06 22:46:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-29 00:36:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
2024-06-11 15:01:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
2008-10-06 22:46:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-29 00:36:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
2020-11-19 13:46:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-19 13:34:24 +02:00
|
|
|
|
2020-11-19 13:46:09 +01:00
|
|
|
|
2022-04-19 13:34:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-19 13:46:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-28 23:34:08 +02:00
|
|
|
|
2020-11-19 13:46:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-01 14:07:37 +02:00
|
|
|
|
2020-11-19 13:46:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-11 12:30:17 +01:00
|
|
|
|
2020-11-19 13:46:09 +01:00
|
|
|
|
2023-01-11 12:30:17 +01:00
|
|
|
|
2020-11-19 13:46:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-19 13:46:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
driver core: platform: Drop dev_pm_domain_detach() call
On the Renesas RZ/G3S (and other Renesas SoCs, e.g., RZ/G2{L, LC, UL}),
clocks are managed through PM domains. These PM domains, registered on
behalf of the clock controller driver, are configured with
GENPD_FLAG_PM_CLK. In most of the Renesas drivers used by RZ SoCs, the
clocks are enabled/disabled using runtime PM APIs. The power domains may
also have power_on/power_off support implemented. After the device PM
domain is powered off any CPU accesses to these domains leads to system
aborts.
During probe, devices are attached to the PM domain controlling their
clocks and power. Similarly, during removal, devices are detached from the
PM domain.
The detachment call stack is as follows:
device_driver_detach() ->
device_release_driver_internal() ->
__device_release_driver() ->
device_remove() ->
platform_remove() ->
dev_pm_domain_detach()
During driver unbind, after the device is detached from its PM domain,
the device_unbind_cleanup() function is called, which subsequently
invokes devres_release_all(). This function handles devres resource
cleanup.
If runtime PM is enabled in driver probe via devm_pm_runtime_enable(),
the cleanup process triggers the action or reset function for disabling
runtime PM. This function is pm_runtime_disable_action(), which leads
to the following call stack of interest when called:
pm_runtime_disable_action() ->
pm_runtime_dont_use_autosuspend() ->
__pm_runtime_use_autosuspend() ->
update_autosuspend() ->
rpm_idle()
The rpm_idle() function attempts to resume the device at runtime.
However, at the point it is called, the device is no longer part of a PM
domain (which manages clocks and power states). If the driver implements
its own runtime PM APIs for specific functionalities - such as the
rzg2l_adc driver - while also relying on the power domain subsystem for
power management, rpm_idle() will invoke the driver's runtime PM API.
However, since the device is no longer part of a PM domain at this point,
the PM domain's runtime PM APIs will not be called. This leads to system
aborts on Renesas SoCs.
Another identified case is when a subsystem performs various cleanups
using device_unbind_cleanup(), calling driver-specific APIs in the
process. A known example is the thermal subsystem, which may call driver-
specific APIs to disable the thermal device. The relevant call stack in
this case is:
device_driver_detach() ->
device_release_driver_internal() ->
device_unbind_cleanup() ->
devres_release_all() ->
devm_thermal_of_zone_release() ->
thermal_zone_device_disable() ->
thermal_zone_device_set_mode() ->
struct thermal_zone_device_ops::change_mode()
At the moment the driver-specific change_mode() API is called, the
device is no longer part of its PM domain. Accessing its registers
without proper power management leads to system aborts.
Drop the call to dev_pm_domain_detach() from the platform bus remove
function and rely on the newly introduced call in device_unbind_cleanup().
This ensures the same effect, but the call now occurs after all
driver-specific devres resources have been freed.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/20250703112708.1621607-4-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-03 14:27:08 +03:00
|
|
|
|
|
|
|
|
|
2020-11-19 13:46:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
driver core: platform: Drop dev_pm_domain_detach() call
On the Renesas RZ/G3S (and other Renesas SoCs, e.g., RZ/G2{L, LC, UL}),
clocks are managed through PM domains. These PM domains, registered on
behalf of the clock controller driver, are configured with
GENPD_FLAG_PM_CLK. In most of the Renesas drivers used by RZ SoCs, the
clocks are enabled/disabled using runtime PM APIs. The power domains may
also have power_on/power_off support implemented. After the device PM
domain is powered off any CPU accesses to these domains leads to system
aborts.
During probe, devices are attached to the PM domain controlling their
clocks and power. Similarly, during removal, devices are detached from the
PM domain.
The detachment call stack is as follows:
device_driver_detach() ->
device_release_driver_internal() ->
__device_release_driver() ->
device_remove() ->
platform_remove() ->
dev_pm_domain_detach()
During driver unbind, after the device is detached from its PM domain,
the device_unbind_cleanup() function is called, which subsequently
invokes devres_release_all(). This function handles devres resource
cleanup.
If runtime PM is enabled in driver probe via devm_pm_runtime_enable(),
the cleanup process triggers the action or reset function for disabling
runtime PM. This function is pm_runtime_disable_action(), which leads
to the following call stack of interest when called:
pm_runtime_disable_action() ->
pm_runtime_dont_use_autosuspend() ->
__pm_runtime_use_autosuspend() ->
update_autosuspend() ->
rpm_idle()
The rpm_idle() function attempts to resume the device at runtime.
However, at the point it is called, the device is no longer part of a PM
domain (which manages clocks and power states). If the driver implements
its own runtime PM APIs for specific functionalities - such as the
rzg2l_adc driver - while also relying on the power domain subsystem for
power management, rpm_idle() will invoke the driver's runtime PM API.
However, since the device is no longer part of a PM domain at this point,
the PM domain's runtime PM APIs will not be called. This leads to system
aborts on Renesas SoCs.
Another identified case is when a subsystem performs various cleanups
using device_unbind_cleanup(), calling driver-specific APIs in the
process. A known example is the thermal subsystem, which may call driver-
specific APIs to disable the thermal device. The relevant call stack in
this case is:
device_driver_detach() ->
device_release_driver_internal() ->
device_unbind_cleanup() ->
devres_release_all() ->
devm_thermal_of_zone_release() ->
thermal_zone_device_disable() ->
thermal_zone_device_set_mode() ->
struct thermal_zone_device_ops::change_mode()
At the moment the driver-specific change_mode() API is called, the
device is no longer part of its PM domain. Accessing its registers
without proper power management leads to system aborts.
Drop the call to dev_pm_domain_detach() from the platform bus remove
function and rely on the newly introduced call in device_unbind_cleanup().
This ensures the same effect, but the call now occurs after all
driver-specific devres resources have been freed.
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://patch.msgid.link/20250703112708.1621607-4-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-07-03 14:27:08 +03:00
|
|
|
|
2020-11-19 13:46:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-13 21:35:22 +02:00
|
|
|
|
2020-11-19 13:46:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-09 12:37:26 +02:00
|
|
|
|
|
|
|
|
|
2020-11-19 13:46:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-13 02:55:33 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-19 13:46:11 +01:00
|
|
|
|
2020-12-13 02:55:33 +03:00
|
|
|
|
2020-11-19 13:46:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-18 08:49:52 +08:00
|
|
|
|
2018-04-28 08:21:58 +05:30
|
|
|
|
2025-04-24 11:04:19 -07:00
|
|
|
|
2023-10-03 17:21:22 +03:00
|
|
|
|
2018-04-28 08:21:58 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-03 17:21:22 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-06 13:20:49 -08:00
|
|
|
|
2018-04-28 08:21:58 +05:30
|
|
|
|
2025-04-24 11:04:19 -07:00
|
|
|
|
|
|
|
|
|
2023-10-03 17:21:20 +03:00
|
|
|
|
2018-04-28 08:21:58 +05:30
|
|
|
|
2023-10-03 17:21:20 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management
The devices on platform/amba/fsl-mc/PCI buses could be bound to drivers
with the device DMA managed by kernel drivers or user-space applications.
Unfortunately, multiple devices may be placed in the same IOMMU group
because they cannot be isolated from each other. The DMA on these devices
must either be entirely under kernel control or userspace control, never
a mixture. Otherwise the driver integrity is not guaranteed because they
could access each other through the peer-to-peer accesses which by-pass
the IOMMU protection.
This checks and sets the default DMA mode during driver binding, and
cleanups during driver unbinding. In the default mode, the device DMA is
managed by the device driver which handles DMA operations through the
kernel DMA APIs (see Documentation/core-api/dma-api.rst).
For cases where the devices are assigned for userspace control through the
userspace driver framework(i.e. VFIO), the drivers(for example, vfio_pci/
vfio_platfrom etc.) may set a new flag (driver_managed_dma) to skip this
default setting in the assumption that the drivers know what they are
doing with the device DMA.
Calling iommu_device_use_default_domain() before {of,acpi}_dma_configure
is currently a problem. As things stand, the IOMMU driver ignored the
initial iommu_probe_device() call when the device was added, since at
that point it had no fwspec yet. In this situation,
{of,acpi}_iommu_configure() are retriggering iommu_probe_device() after
the IOMMU driver has seen the firmware data via .of_xlate to learn that
it actually responsible for the given device. As the result, before
that gets fixed, iommu_use_default_domain() goes at the end, and calls
arch_teardown_dma_ops() if it fails.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Stuart Yoder <stuyoder@gmail.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Link: https://lore.kernel.org/r/20220418005000.897664-5-baolu.lu@linux.intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-04-18 08:49:53 +08:00
|
|
|
|
2018-04-28 08:21:58 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management
The devices on platform/amba/fsl-mc/PCI buses could be bound to drivers
with the device DMA managed by kernel drivers or user-space applications.
Unfortunately, multiple devices may be placed in the same IOMMU group
because they cannot be isolated from each other. The DMA on these devices
must either be entirely under kernel control or userspace control, never
a mixture. Otherwise the driver integrity is not guaranteed because they
could access each other through the peer-to-peer accesses which by-pass
the IOMMU protection.
This checks and sets the default DMA mode during driver binding, and
cleanups during driver unbinding. In the default mode, the device DMA is
managed by the device driver which handles DMA operations through the
kernel DMA APIs (see Documentation/core-api/dma-api.rst).
For cases where the devices are assigned for userspace control through the
userspace driver framework(i.e. VFIO), the drivers(for example, vfio_pci/
vfio_platfrom etc.) may set a new flag (driver_managed_dma) to skip this
default setting in the assumption that the drivers know what they are
doing with the device DMA.
Calling iommu_device_use_default_domain() before {of,acpi}_dma_configure
is currently a problem. As things stand, the IOMMU driver ignored the
initial iommu_probe_device() call when the device was added, since at
that point it had no fwspec yet. In this situation,
{of,acpi}_iommu_configure() are retriggering iommu_probe_device() after
the IOMMU driver has seen the firmware data via .of_xlate to learn that
it actually responsible for the given device. As the result, before
that gets fixed, iommu_use_default_domain() goes at the end, and calls
arch_teardown_dma_ops() if it fails.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Stuart Yoder <stuyoder@gmail.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Link: https://lore.kernel.org/r/20220418005000.897664-5-baolu.lu@linux.intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-04-18 08:49:53 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-07-22 00:37:25 +02:00
|
|
|
|
2021-08-28 17:02:19 +08:00
|
|
|
|
2011-04-29 00:36:05 +02:00
|
|
|
|
2008-05-21 01:40:43 +02:00
|
|
|
|
|
|
|
|
|
2024-08-23 15:55:44 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-08-23 14:24:37 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-05-29 10:37:33 -07:00
|
|
|
|
2020-11-19 13:46:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-04-28 08:21:58 +05:30
|
|
|
|
bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management
The devices on platform/amba/fsl-mc/PCI buses could be bound to drivers
with the device DMA managed by kernel drivers or user-space applications.
Unfortunately, multiple devices may be placed in the same IOMMU group
because they cannot be isolated from each other. The DMA on these devices
must either be entirely under kernel control or userspace control, never
a mixture. Otherwise the driver integrity is not guaranteed because they
could access each other through the peer-to-peer accesses which by-pass
the IOMMU protection.
This checks and sets the default DMA mode during driver binding, and
cleanups during driver unbinding. In the default mode, the device DMA is
managed by the device driver which handles DMA operations through the
kernel DMA APIs (see Documentation/core-api/dma-api.rst).
For cases where the devices are assigned for userspace control through the
userspace driver framework(i.e. VFIO), the drivers(for example, vfio_pci/
vfio_platfrom etc.) may set a new flag (driver_managed_dma) to skip this
default setting in the assumption that the drivers know what they are
doing with the device DMA.
Calling iommu_device_use_default_domain() before {of,acpi}_dma_configure
is currently a problem. As things stand, the IOMMU driver ignored the
initial iommu_probe_device() call when the device was added, since at
that point it had no fwspec yet. In this situation,
{of,acpi}_iommu_configure() are retriggering iommu_probe_device() after
the IOMMU driver has seen the firmware data via .of_xlate to learn that
it actually responsible for the given device. As the result, before
that gets fixed, iommu_use_default_domain() goes at the end, and calls
arch_teardown_dma_ops() if it fails.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Stuart Yoder <stuyoder@gmail.com>
Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Link: https://lore.kernel.org/r/20220418005000.897664-5-baolu.lu@linux.intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2022-04-18 08:49:53 +08:00
|
|
|
|
2009-08-20 20:25:32 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-12-10 01:36:28 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2019-11-12 13:41:56 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-07-23 23:18:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-12 13:41:56 -08:00
|
|
|
|
2019-07-23 23:18:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-12-03 12:58:52 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-11-27 10:35:08 +01:00
|
|
|
|
|
|
|
|
|
2019-12-03 12:58:52 -08:00
|
|
|
|
|
|
|
|
|
2006-11-27 10:35:08 +01:00
|
|
|
|
2018-03-11 11:25:49 +05:30
|
|
|
|
|
|
|
|
|
2006-11-27 10:35:08 +01:00
|
|
|
|
2018-03-11 11:25:49 +05:30
|
|
|
|
2006-11-27 10:35:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-17 08:37:16 -06:00
|
|
|
|
2006-11-27 10:35:08 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|