<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/base/dd.c, branch v5.18.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>net: mdio: don't defer probe forever if PHY IRQ provider is missing</title>
<updated>2022-04-08T21:17:55+00:00</updated>
<author>
<name>Vladimir Oltean</name>
<email>vladimir.oltean@nxp.com</email>
</author>
<published>2022-04-07T16:55:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=74befa447e6839cdd90ed541159ec783726946f9'/>
<id>74befa447e6839cdd90ed541159ec783726946f9</id>
<content type='text'>
When a driver for an interrupt controller is missing, of_irq_get()
returns -EPROBE_DEFER ad infinitum, causing
fwnode_mdiobus_phy_device_register(), and ultimately, the entire
of_mdiobus_register() call, to fail. In turn, any phy_connect() call
towards a PHY on this MDIO bus will also fail.

This is not what is expected to happen, because the PHY library falls
back to poll mode when of_irq_get() returns a hard error code, and the
MDIO bus, PHY and attached Ethernet controller work fine, albeit
suboptimally, when the PHY library polls for link status. However,
-EPROBE_DEFER has special handling given the assumption that at some
point probe deferral will stop, and the driver for the supplier will
kick in and create the IRQ domain.

Reasons for which the interrupt controller may be missing:

- It is not yet written. This may happen if a more recent DT blob (with
  an interrupt-parent for the PHY) is used to boot an old kernel where
  the driver didn't exist, and that kernel worked with the
  vintage-correct DT blob using poll mode.

- It is compiled out. Behavior is the same as above.

- It is compiled as a module. The kernel will wait for a number of
  seconds specified in the "deferred_probe_timeout" boot parameter for
  user space to load the required module. The current default is 0,
  which times out at the end of initcalls. It is possible that this
  might cause regressions unless users adjust this boot parameter.

The proposed solution is to use the driver_deferred_probe_check_state()
helper function provided by the driver core, which gives up after some
-EPROBE_DEFER attempts, taking "deferred_probe_timeout" into consideration.
The return code is changed from -EPROBE_DEFER into -ENODEV or
-ETIMEDOUT, depending on whether the kernel is compiled with support for
modules or not.

Fixes: 66bdede495c7 ("of_mdio: Fix broken PHY IRQ in case of probe deferral")
Suggested-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20220407165538.4084809-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When a driver for an interrupt controller is missing, of_irq_get()
returns -EPROBE_DEFER ad infinitum, causing
fwnode_mdiobus_phy_device_register(), and ultimately, the entire
of_mdiobus_register() call, to fail. In turn, any phy_connect() call
towards a PHY on this MDIO bus will also fail.

This is not what is expected to happen, because the PHY library falls
back to poll mode when of_irq_get() returns a hard error code, and the
MDIO bus, PHY and attached Ethernet controller work fine, albeit
suboptimally, when the PHY library polls for link status. However,
-EPROBE_DEFER has special handling given the assumption that at some
point probe deferral will stop, and the driver for the supplier will
kick in and create the IRQ domain.

Reasons for which the interrupt controller may be missing:

- It is not yet written. This may happen if a more recent DT blob (with
  an interrupt-parent for the PHY) is used to boot an old kernel where
  the driver didn't exist, and that kernel worked with the
  vintage-correct DT blob using poll mode.

- It is compiled out. Behavior is the same as above.

- It is compiled as a module. The kernel will wait for a number of
  seconds specified in the "deferred_probe_timeout" boot parameter for
  user space to load the required module. The current default is 0,
  which times out at the end of initcalls. It is possible that this
  might cause regressions unless users adjust this boot parameter.

The proposed solution is to use the driver_deferred_probe_check_state()
helper function provided by the driver core, which gives up after some
-EPROBE_DEFER attempts, taking "deferred_probe_timeout" into consideration.
The return code is changed from -EPROBE_DEFER into -ENODEV or
-ETIMEDOUT, depending on whether the kernel is compiled with support for
modules or not.

Fixes: 66bdede495c7 ("of_mdio: Fix broken PHY IRQ in case of probe deferral")
Suggested-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Signed-off-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Reviewed-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Link: https://lore.kernel.org/r/20220407165538.4084809-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers/base/dd.c : Remove the initial value of the global variable</title>
<updated>2022-03-18T13:31:31+00:00</updated>
<author>
<name>lizhe</name>
<email>sensor1010@163.com</email>
</author>
<published>2022-03-09T13:54:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=901581389eade09af969c1a4183e17ec663131d0'/>
<id>901581389eade09af969c1a4183e17ec663131d0</id>
<content type='text'>
The global variable driver_deferred_probe_enable has a default value of
false and does not need to be initialized to false.

Signed-off-by: lizhe &lt;sensor1010@163.com&gt;
Link: https://lore.kernel.org/r/20220309135418.31101-1-sensor1010@163.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The global variable driver_deferred_probe_enable has a default value of
false and does not need to be initialized to false.

Signed-off-by: lizhe &lt;sensor1010@163.com&gt;
Link: https://lore.kernel.org/r/20220309135418.31101-1-sensor1010@163.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>driver core: dd: fix return value of __setup handler</title>
<updated>2022-03-18T13:27:51+00:00</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2022-03-01T04:18:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f2aad54703dbe630f9d8b235eb58e8c8cc78f37d'/>
<id>f2aad54703dbe630f9d8b235eb58e8c8cc78f37d</id>
<content type='text'>
When "driver_async_probe=nulltty" is used on the kernel boot command line,
it causes an Unknown parameter message and the string is added to init's
environment strings, polluting them.

  Unknown kernel command line parameters "BOOT_IMAGE=/boot/bzImage-517rc6
  driver_async_probe=nulltty", will be passed to user space.

 Run /sbin/init as init process
   with arguments:
     /sbin/init
   with environment:
     HOME=/
     TERM=linux
     BOOT_IMAGE=/boot/bzImage-517rc6
     driver_async_probe=nulltty

Change the return value of the __setup function to 1 to indicate
that the __setup option has been handled.

Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Fixes: 1ea61b68d0f8 ("async: Add cmdline option to specify drivers to be async probed")
Cc: Feng Tang &lt;feng.tang@intel.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: "Rafael J. Wysocki" &lt;rafael@kernel.org&gt;
Reported-by: Igor Zhbanov &lt;i.zhbanov@omprussia.ru&gt;
Reviewed-by: Feng Tang &lt;feng.tang@intel.com&gt;
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Link: https://lore.kernel.org/r/20220301041829.15137-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When "driver_async_probe=nulltty" is used on the kernel boot command line,
it causes an Unknown parameter message and the string is added to init's
environment strings, polluting them.

  Unknown kernel command line parameters "BOOT_IMAGE=/boot/bzImage-517rc6
  driver_async_probe=nulltty", will be passed to user space.

 Run /sbin/init as init process
   with arguments:
     /sbin/init
   with environment:
     HOME=/
     TERM=linux
     BOOT_IMAGE=/boot/bzImage-517rc6
     driver_async_probe=nulltty

Change the return value of the __setup function to 1 to indicate
that the __setup option has been handled.

Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Fixes: 1ea61b68d0f8 ("async: Add cmdline option to specify drivers to be async probed")
Cc: Feng Tang &lt;feng.tang@intel.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Cc: "Rafael J. Wysocki" &lt;rafael@kernel.org&gt;
Reported-by: Igor Zhbanov &lt;i.zhbanov@omprussia.ru&gt;
Reviewed-by: Feng Tang &lt;feng.tang@intel.com&gt;
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Link: https://lore.kernel.org/r/20220301041829.15137-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>driver core: Refactor sysfs and drv/bus remove hooks</title>
<updated>2022-03-18T13:27:26+00:00</updated>
<author>
<name>Rob Herring</name>
<email>robh@kernel.org</email>
</author>
<published>2022-02-23T22:52:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4b775aaf1ea9997f5eb1a792f357a7b81a1fc632'/>
<id>4b775aaf1ea9997f5eb1a792f357a7b81a1fc632</id>
<content type='text'>
There are 3 copies of the same device sysfs cleanup and drv/bus remove()
hooks used for probe failure, testing re-probing, and device unbinding.

Let's refactor the code to its own function.

Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
Link: https://lore.kernel.org/r/20220223225257.1681968-3-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are 3 copies of the same device sysfs cleanup and drv/bus remove()
hooks used for probe failure, testing re-probing, and device unbinding.

Let's refactor the code to its own function.

Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
Link: https://lore.kernel.org/r/20220223225257.1681968-3-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>driver core: Refactor multiple copies of device cleanup</title>
<updated>2022-03-18T13:27:26+00:00</updated>
<author>
<name>Rob Herring</name>
<email>robh@kernel.org</email>
</author>
<published>2022-02-23T22:52:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9ad307213fa4081f4bc2f2daa31d4f2d35d7a213'/>
<id>9ad307213fa4081f4bc2f2daa31d4f2d35d7a213</id>
<content type='text'>
There are 3 copies of the same device cleanup code used for probe failure,
testing re-probing, and device unbinding. Changes to this code often miss
at least one of the copies of the code. See commits d0243bbd5dd3 ("drivers
core: Free dma_range_map when driver probe failed") and d8f7a5484f21
("driver core: Free DMA range map when device is released") for example.

Let's refactor the code to its own function.

Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
Link: https://lore.kernel.org/r/20220223225257.1681968-2-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are 3 copies of the same device cleanup code used for probe failure,
testing re-probing, and device unbinding. Changes to this code often miss
at least one of the copies of the code. See commits d0243bbd5dd3 ("drivers
core: Free dma_range_map when driver probe failed") and d8f7a5484f21
("driver core: Free DMA range map when device is released") for example.

Let's refactor the code to its own function.

Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
Link: https://lore.kernel.org/r/20220223225257.1681968-2-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge 5.17-rc6 into driver-core-next</title>
<updated>2022-02-28T06:45:41+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2022-02-28T06:45:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4a248f85b3dd8e010ff8335755c927130e9b0764'/>
<id>4a248f85b3dd8e010ff8335755c927130e9b0764</id>
<content type='text'>
We need the driver core fix in here as well for future changes.

Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We need the driver core fix in here as well for future changes.

Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>driver core: Free DMA range map when device is released</title>
<updated>2022-02-22T07:40:02+00:00</updated>
<author>
<name>Mårten Lindahl</name>
<email>marten.lindahl@axis.com</email>
</author>
<published>2022-02-16T09:41:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d8f7a5484f2188e9af2d9e4e587587d724501b12'/>
<id>d8f7a5484f2188e9af2d9e4e587587d724501b12</id>
<content type='text'>
When unbinding/binding a driver with DMA mapped memory, the DMA map is
not freed before the driver is reloaded. This leads to a memory leak
when the DMA map is overwritten when reprobing the driver.

This can be reproduced with a platform driver having a dma-range:

dummy {
	...
	#address-cells = &lt;0x2&gt;;
	#size-cells = &lt;0x2&gt;;
	ranges;
	dma-ranges = &lt;...&gt;;
	...
};

and then unbinding/binding it:

~# echo soc:dummy &gt;/sys/bus/platform/drivers/&lt;driver&gt;/unbind

DMA map object 0xffffff800b0ae540 still being held by &amp;pdev-&gt;dev

~# echo soc:dummy &gt;/sys/bus/platform/drivers/&lt;driver&gt;/bind
~# echo scan &gt; /sys/kernel/debug/kmemleak
~# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffffff800b0ae540 (size 64):
  comm "sh", pid 833, jiffies 4295174550 (age 2535.352s)
  hex dump (first 32 bytes):
    00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 80 00 00 00 00 00 00 00 80 00 00 00 00  ................
  backtrace:
    [&lt;ffffffefd1694708&gt;] create_object.isra.0+0x108/0x344
    [&lt;ffffffefd1d1a850&gt;] kmemleak_alloc+0x8c/0xd0
    [&lt;ffffffefd167e2d0&gt;] __kmalloc+0x440/0x6f0
    [&lt;ffffffefd1a960a4&gt;] of_dma_get_range+0x124/0x220
    [&lt;ffffffefd1a8ce90&gt;] of_dma_configure_id+0x40/0x2d0
    [&lt;ffffffefd198b68c&gt;] platform_dma_configure+0x5c/0xa4
    [&lt;ffffffefd198846c&gt;] really_probe+0x8c/0x514
    [&lt;ffffffefd1988990&gt;] __driver_probe_device+0x9c/0x19c
    [&lt;ffffffefd1988cd8&gt;] device_driver_attach+0x54/0xbc
    [&lt;ffffffefd1986634&gt;] bind_store+0xc4/0x120
    [&lt;ffffffefd19856e0&gt;] drv_attr_store+0x30/0x44
    [&lt;ffffffefd173c9b0&gt;] sysfs_kf_write+0x50/0x60
    [&lt;ffffffefd173c1c4&gt;] kernfs_fop_write_iter+0x124/0x1b4
    [&lt;ffffffefd16a013c&gt;] new_sync_write+0xdc/0x160
    [&lt;ffffffefd16a256c&gt;] vfs_write+0x23c/0x2a0
    [&lt;ffffffefd16a2758&gt;] ksys_write+0x64/0xec

To prevent this we should free the dma_range_map when the device is
released.

Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset")
Cc: stable &lt;stable@vger.kernel.org&gt;
Suggested-by: Rob Herring &lt;robh@kernel.org&gt;
Reviewed-by: Rob Herring &lt;robh@kernel.org&gt;
Signed-off-by: Mårten Lindahl &lt;marten.lindahl@axis.com&gt;
Link: https://lore.kernel.org/r/20220216094128.4025861-1-marten.lindahl@axis.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When unbinding/binding a driver with DMA mapped memory, the DMA map is
not freed before the driver is reloaded. This leads to a memory leak
when the DMA map is overwritten when reprobing the driver.

This can be reproduced with a platform driver having a dma-range:

dummy {
	...
	#address-cells = &lt;0x2&gt;;
	#size-cells = &lt;0x2&gt;;
	ranges;
	dma-ranges = &lt;...&gt;;
	...
};

and then unbinding/binding it:

~# echo soc:dummy &gt;/sys/bus/platform/drivers/&lt;driver&gt;/unbind

DMA map object 0xffffff800b0ae540 still being held by &amp;pdev-&gt;dev

~# echo soc:dummy &gt;/sys/bus/platform/drivers/&lt;driver&gt;/bind
~# echo scan &gt; /sys/kernel/debug/kmemleak
~# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffffff800b0ae540 (size 64):
  comm "sh", pid 833, jiffies 4295174550 (age 2535.352s)
  hex dump (first 32 bytes):
    00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 80 00 00 00 00 00 00 00 80 00 00 00 00  ................
  backtrace:
    [&lt;ffffffefd1694708&gt;] create_object.isra.0+0x108/0x344
    [&lt;ffffffefd1d1a850&gt;] kmemleak_alloc+0x8c/0xd0
    [&lt;ffffffefd167e2d0&gt;] __kmalloc+0x440/0x6f0
    [&lt;ffffffefd1a960a4&gt;] of_dma_get_range+0x124/0x220
    [&lt;ffffffefd1a8ce90&gt;] of_dma_configure_id+0x40/0x2d0
    [&lt;ffffffefd198b68c&gt;] platform_dma_configure+0x5c/0xa4
    [&lt;ffffffefd198846c&gt;] really_probe+0x8c/0x514
    [&lt;ffffffefd1988990&gt;] __driver_probe_device+0x9c/0x19c
    [&lt;ffffffefd1988cd8&gt;] device_driver_attach+0x54/0xbc
    [&lt;ffffffefd1986634&gt;] bind_store+0xc4/0x120
    [&lt;ffffffefd19856e0&gt;] drv_attr_store+0x30/0x44
    [&lt;ffffffefd173c9b0&gt;] sysfs_kf_write+0x50/0x60
    [&lt;ffffffefd173c1c4&gt;] kernfs_fop_write_iter+0x124/0x1b4
    [&lt;ffffffefd16a013c&gt;] new_sync_write+0xdc/0x160
    [&lt;ffffffefd16a256c&gt;] vfs_write+0x23c/0x2a0
    [&lt;ffffffefd16a2758&gt;] ksys_write+0x64/0xec

To prevent this we should free the dma_range_map when the device is
released.

Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset")
Cc: stable &lt;stable@vger.kernel.org&gt;
Suggested-by: Rob Herring &lt;robh@kernel.org&gt;
Reviewed-by: Rob Herring &lt;robh@kernel.org&gt;
Signed-off-by: Mårten Lindahl &lt;marten.lindahl@axis.com&gt;
Link: https://lore.kernel.org/r/20220216094128.4025861-1-marten.lindahl@axis.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>driver core: cleanup double words comments</title>
<updated>2022-02-22T07:16:05+00:00</updated>
<author>
<name>Tom Rix</name>
<email>trix@redhat.com</email>
</author>
<published>2022-02-12T14:32:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b4ae8c2fb673d2fc60cb8fe645dba4f4db8b0dab'/>
<id>b4ae8c2fb673d2fc60cb8fe645dba4f4db8b0dab</id>
<content type='text'>
Remove the second 'are' and 'the'.

Signed-off-by: Tom Rix &lt;trix@redhat.com&gt;
Link: https://lore.kernel.org/r/20220212143233.2648872-1-trix@redhat.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove the second 'are' and 'the'.

Signed-off-by: Tom Rix &lt;trix@redhat.com&gt;
Link: https://lore.kernel.org/r/20220212143233.2648872-1-trix@redhat.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>driver core: Make bus notifiers in right order in really_probe()</title>
<updated>2022-01-06T14:47:41+00:00</updated>
<author>
<name>Lu Baolu</name>
<email>baolu.lu@linux.intel.com</email>
</author>
<published>2021-12-31T03:39:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=00eb74ea2c14418042347eaa34c6b73ac6ec1e76'/>
<id>00eb74ea2c14418042347eaa34c6b73ac6ec1e76</id>
<content type='text'>
If a driver cannot be bound to a device, the correct bus notifier order
should be:

 - BUS_NOTIFY_BIND_DRIVER: driver is about to be bound
 - BUS_NOTIFY_DRIVER_NOT_BOUND: driver failed to be bound

or no notifier if the failure happens before the actual binding.

The really_probe() notifies a BUS_NOTIFY_DRIVER_NOT_BOUND event without
a BUS_NOTIFY_BIND_DRIVER if .dma_configure() returns failure. This
change makes the notifiers in order.

Signed-off-by: Lu Baolu &lt;baolu.lu@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20211231033901.2168664-3-baolu.lu@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If a driver cannot be bound to a device, the correct bus notifier order
should be:

 - BUS_NOTIFY_BIND_DRIVER: driver is about to be bound
 - BUS_NOTIFY_DRIVER_NOT_BOUND: driver failed to be bound

or no notifier if the failure happens before the actual binding.

The really_probe() notifies a BUS_NOTIFY_DRIVER_NOT_BOUND event without
a BUS_NOTIFY_BIND_DRIVER if .dma_configure() returns failure. This
change makes the notifiers in order.

Signed-off-by: Lu Baolu &lt;baolu.lu@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20211231033901.2168664-3-baolu.lu@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>driver core: Move driver_sysfs_remove() after driver_sysfs_add()</title>
<updated>2022-01-06T14:47:41+00:00</updated>
<author>
<name>Lu Baolu</name>
<email>baolu.lu@linux.intel.com</email>
</author>
<published>2021-12-31T03:39:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=885e50253bfd6750327a265405461496d6af1639'/>
<id>885e50253bfd6750327a265405461496d6af1639</id>
<content type='text'>
The driver_sysfs_remove() should be called after driver_sysfs_add() in
really_probe(). The out-of-order driver_sysfs_remove() tries to remove
some nonexistent nodes under the device and driver sysfs nodes. This is
allowed, hence this change doesn't fix any problem, just a cleanup.

Signed-off-by: Lu Baolu &lt;baolu.lu@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20211231033901.2168664-2-baolu.lu@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The driver_sysfs_remove() should be called after driver_sysfs_add() in
really_probe(). The out-of-order driver_sysfs_remove() tries to remove
some nonexistent nodes under the device and driver sysfs nodes. This is
allowed, hence this change doesn't fix any problem, just a cleanup.

Signed-off-by: Lu Baolu &lt;baolu.lu@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20211231033901.2168664-2-baolu.lu@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
