linux-stable.git/drivers/base/core.c, branch v5.16.2 Linux kernel stable tree driver core: Provide device_match_acpi_handle() helper 2021-10-20T17:38:29+00:00 Andy Shevchenko andriy.shevchenko@linux.intel.com 2021-10-14T13:47:54+00:00 a164ff53cbd34479aeac3366840669b10845ce53 We have a couple of users of this helper, make it available for them. The prototype for the helper is specifically crafted in order to be easily used with bus_find_device() call. That's why its location is in the driver core rather than ACPI. Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211014134756.39092-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
We have a couple of users of this helper, make it available for them.

The prototype for the helper is specifically crafted in order to be
easily used with bus_find_device() call. That's why its location is
in the driver core rather than ACPI.

Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20211014134756.39092-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge 5.15-rc6 into driver-core-next 2021-10-18T07:43:37+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2021-10-18T07:43:37+00:00 b5bc8ac25aa1477fee3853718f2673a594efdc4b We need the driver-core fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
We need the driver-core fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
driver core: Reject pointless SYNC_STATE_ONLY device links 2021-10-05T15:45:54+00:00 Saravana Kannan saravanak@google.com 2021-09-29T19:05:49+00:00 f729a592adb6760013c3e48622a5bf256b992452 SYNC_STATE_ONLY device links intentionally allow cycles because cyclic sync_state() dependencies are valid and necessary. However a SYNC_STATE_ONLY device link where the consumer and the supplier are the same device is pointless because the device link would be deleted as soon as the device probes (because it's also the consumer) and won't affect when the sync_state() callback is called. It's a waste of CPU cycles and memory to create this device link. So reject any attempts to create such a device link. Fixes: 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY flag") Cc: stable <stable@vger.kernel.org> Reported-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210929190549.860541-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
SYNC_STATE_ONLY device links intentionally allow cycles because cyclic
sync_state() dependencies are valid and necessary.

However a SYNC_STATE_ONLY device link where the consumer and the supplier
are the same device is pointless because the device link would be deleted
as soon as the device probes (because it's also the consumer) and won't
affect when the sync_state() callback is called. It's a waste of CPU cycles
and memory to create this device link. So reject any attempts to create
such a device link.

Fixes: 05ef983e0d65 ("driver core: Add device link support for SYNC_STATE_ONLY flag")
Cc: stable <stable@vger.kernel.org>
Reported-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210929190549.860541-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
driver core: use NUMA_NO_NODE during device_initialize 2021-10-05T13:42:22+00:00 Max Gurtovoy mgurtovoy@nvidia.com 2021-10-04T13:34:52+00:00 d460d7f7bb43233e5e4c6c62955b3b26cf462062 Don't use (-1) constant for setting initial device node. Instead, use the generic NUMA_NO_NODE definition to indicate that "no node id specified". Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com> Link: https://lore.kernel.org/r/20211004133453.18881-1-mgurtovoy@nvidia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Don't use (-1) constant for setting initial device node. Instead, use
the generic NUMA_NO_NODE definition to indicate that "no node id
specified".

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Link: https://lore.kernel.org/r/20211004133453.18881-1-mgurtovoy@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
driver core: Fix possible memory leak in device_link_add() 2021-10-05T13:39:29+00:00 Yang Yingliang yangyingliang@huawei.com 2021-09-30T08:57:14+00:00 df0a18149474c7e6b21f6367fbc6bc8d0f192444 I got memory leak as follows: unreferenced object 0xffff88801f0b2200 (size 64): comm "i2c-lis2hh12-21", pid 5455, jiffies 4294944606 (age 15.224s) hex dump (first 32 bytes): 72 65 67 75 6c 61 74 6f 72 3a 72 65 67 75 6c 61 regulator:regula 74 6f 72 2e 30 2d 2d 69 32 63 3a 31 2d 30 30 31 tor.0--i2c:1-001 backtrace: [<00000000bf5b0c3b>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000050da42d9>] kvasprintf+0xb5/0x150 [<000000004bbbed13>] kvasprintf_const+0x60/0x190 [<00000000cdac7480>] kobject_set_name_vargs+0x56/0x150 [<00000000bf83f8e8>] dev_set_name+0xc0/0x100 [<00000000cc1cf7e3>] device_link_add+0x6b4/0x17c0 [<000000009db9faed>] _regulator_get+0x297/0x680 [<00000000845e7f2b>] _devm_regulator_get+0x5b/0xe0 [<000000003958ee25>] st_sensors_power_enable+0x71/0x1b0 [st_sensors] [<000000005f450f52>] st_accel_i2c_probe+0xd9/0x150 [st_accel_i2c] [<00000000b5f2ab33>] i2c_device_probe+0x4d8/0xbe0 [<0000000070fb977b>] really_probe+0x299/0xc30 [<0000000088e226ce>] __driver_probe_device+0x357/0x500 [<00000000c21dda32>] driver_probe_device+0x4e/0x140 [<000000004e650441>] __device_attach_driver+0x257/0x340 [<00000000cf1891b8>] bus_for_each_drv+0x166/0x1e0 When device_register() returns an error, the name allocated in dev_set_name() will be leaked, the put_device() should be used instead of kfree() to give up the device reference, then the name will be freed in kobject_cleanup() and the references of consumer and supplier will be decreased in device_link_release_fn(). Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs") Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Saravana Kannan <saravanak@google.com> Reviewed-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210930085714.2057460-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
I got memory leak as follows:

unreferenced object 0xffff88801f0b2200 (size 64):
  comm "i2c-lis2hh12-21", pid 5455, jiffies 4294944606 (age 15.224s)
  hex dump (first 32 bytes):
    72 65 67 75 6c 61 74 6f 72 3a 72 65 67 75 6c 61  regulator:regula
    74 6f 72 2e 30 2d 2d 69 32 63 3a 31 2d 30 30 31  tor.0--i2c:1-001
  backtrace:
    [<00000000bf5b0c3b>] __kmalloc_track_caller+0x19f/0x3a0
    [<0000000050da42d9>] kvasprintf+0xb5/0x150
    [<000000004bbbed13>] kvasprintf_const+0x60/0x190
    [<00000000cdac7480>] kobject_set_name_vargs+0x56/0x150
    [<00000000bf83f8e8>] dev_set_name+0xc0/0x100
    [<00000000cc1cf7e3>] device_link_add+0x6b4/0x17c0
    [<000000009db9faed>] _regulator_get+0x297/0x680
    [<00000000845e7f2b>] _devm_regulator_get+0x5b/0xe0
    [<000000003958ee25>] st_sensors_power_enable+0x71/0x1b0 [st_sensors]
    [<000000005f450f52>] st_accel_i2c_probe+0xd9/0x150 [st_accel_i2c]
    [<00000000b5f2ab33>] i2c_device_probe+0x4d8/0xbe0
    [<0000000070fb977b>] really_probe+0x299/0xc30
    [<0000000088e226ce>] __driver_probe_device+0x357/0x500
    [<00000000c21dda32>] driver_probe_device+0x4e/0x140
    [<000000004e650441>] __device_attach_driver+0x257/0x340
    [<00000000cf1891b8>] bus_for_each_drv+0x166/0x1e0

When device_register() returns an error, the name allocated in dev_set_name()
will be leaked, the put_device() should be used instead of kfree() to give up
the device reference, then the name will be freed in kobject_cleanup() and the
references of consumer and supplier will be decreased in device_link_release_fn().

Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs")
Reported-by: Hulk Robot <hulkci@huawei.com>
Reviewed-by: Saravana Kannan <saravanak@google.com>
Reviewed-by: Rafael J. Wysocki <rafael@kernel.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20210930085714.2057460-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge 5.15-rc4 into driver-core-next 2021-10-04T07:20:57+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2021-10-04T07:20:57+00:00 bb76c823585b108b8e3ee9dfc5ef99dd4715ea9a We need the driver core fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
We need the driver core fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
driver core: Add debug logs when fwnode links are added/deleted 2021-09-28T07:48:48+00:00 Saravana Kannan saravanak@google.com 2021-09-15T17:28:07+00:00 ebd6823af378c7d91f80cbe83ce07b5f166744e4 This will help with debugging fw_devlink issues. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210915172808.620546-4-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This will help with debugging fw_devlink issues.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210915172808.620546-4-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
driver core: Create __fwnode_link_del() helper function 2021-09-28T07:48:48+00:00 Saravana Kannan saravanak@google.com 2021-09-15T17:28:06+00:00 76f130810b477243ce1312bf5754dc41ce7f91a8 The same code is repeated in multiple locations. Create a helper function for it. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210915172808.620546-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The same code is repeated in multiple locations. Create a helper
function for it.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210915172808.620546-3-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
driver core: Set deferred probe reason when deferred by driver core 2021-09-28T07:48:48+00:00 Saravana Kannan saravanak@google.com 2021-09-15T17:28:05+00:00 68223eeec70898cd5e42451a9168cd9b2808e248 When the driver core defers the probe of a device, set the deferred probe reason so that it's easier to debug. The deferred probe reason is available in debugfs under devices_deferred. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210915172808.620546-2-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
When the driver core defers the probe of a device, set the deferred
probe reason so that it's easier to debug. The deferred probe reason is
available in debugfs under devices_deferred.

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210915172808.620546-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
driver core: fw_devlink: Add support for FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD 2021-09-23T17:26:54+00:00 Saravana Kannan saravanak@google.com 2021-09-15T17:09:38+00:00 5501765a02a6c324f78581e6bb8209d054fe13ae If a parent device is also a supplier to a child device, fw_devlink=on by design delays the probe() of the child device until the probe() of the parent finishes successfully. However, some drivers of such parent devices (where parent is also a supplier) expect the child device to finish probing successfully as soon as they are added using device_add() and before the probe() of the parent device has completed successfully. One example of such a case is discussed in the link mentioned below. Add a flag to make fw_devlink=on not enforce these supplier-consumer relationships, so these drivers can continue working. Link: https://lore.kernel.org/netdev/CAGETcx_uj0V4DChME-gy5HGKTYnxLBX=TH2rag29f_p=UcG+Tg@mail.gmail.com/ Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by default""") Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20210915170940.617415-3-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
If a parent device is also a supplier to a child device, fw_devlink=on by
design delays the probe() of the child device until the probe() of the
parent finishes successfully.

However, some drivers of such parent devices (where parent is also a
supplier) expect the child device to finish probing successfully as soon as
they are added using device_add() and before the probe() of the parent
device has completed successfully. One example of such a case is discussed
in the link mentioned below.

Add a flag to make fw_devlink=on not enforce these supplier-consumer
relationships, so these drivers can continue working.

Link: https://lore.kernel.org/netdev/CAGETcx_uj0V4DChME-gy5HGKTYnxLBX=TH2rag29f_p=UcG+Tg@mail.gmail.com/
Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by default""")
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210915170940.617415-3-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>