<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/base, branch linux-6.5.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.5.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.5.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2023-11-28T17:15:07Z</updated>
<entry>
<title>driver core: Release all resources during unbind before updating device links</title>
<updated>2023-11-28T17:15:07Z</updated>
<author>
<name>Saravana Kannan</name>
<email>saravanak@google.com</email>
</author>
<published>2023-10-18T01:38:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b2f00346f57b5f0be8215aeeecce815e932851a6'/>
<id>urn:sha1:b2f00346f57b5f0be8215aeeecce815e932851a6</id>
<content type='text'>
commit 2e84dc37920012b458e9458b19fc4ed33f81bc74 upstream.

This commit fixes a bug in commit 9ed9895370ae ("driver core: Functional
dependencies tracking support") where the device link status was
incorrectly updated in the driver unbind path before all the device's
resources were released.

Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support")
Cc: stable &lt;stable@kernel.org&gt;
Reported-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Closes: https://lore.kernel.org/all/20231014161721.f4iqyroddkcyoefo@pengutronix.de/
Signed-off-by: Saravana Kannan &lt;saravanak@google.com&gt;
Cc: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Cc: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Cc: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Cc: Mark Brown &lt;broonie@kernel.org&gt;
Cc: Matti Vaittinen &lt;mazziesaccount@gmail.com&gt;
Cc: James Clark &lt;james.clark@arm.com&gt;
Acked-by: "Rafael J. Wysocki" &lt;rafael@kernel.org&gt;
Tested-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Acked-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Link: https://lore.kernel.org/r/20231018013851.3303928-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>regmap: Ensure range selector registers are updated after cache sync</title>
<updated>2023-11-28T17:15:02Z</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2023-10-26T15:49:19Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=117ccba0288b2cfce4645575053e5daeb619b938'/>
<id>urn:sha1:117ccba0288b2cfce4645575053e5daeb619b938</id>
<content type='text'>
commit 0ec7731655de196bc1e4af99e495b38778109d22 upstream.

When we sync the register cache we do so with the cache bypassed in order
to avoid overhead from writing the synced values back into the cache. If
the regmap has ranges and the selector register for those ranges is in a
register which is cached this has the unfortunate side effect of meaning
that the physical and cached copies of the selector register can be out of
sync after a cache sync. The cache will have whatever the selector was when
the sync started and the hardware will have the selector for the register
that was synced last.

Fix this by rewriting all cached selector registers after every sync,
ensuring that the hardware and cache have the same content. This will
result in extra writes that wouldn't otherwise be needed but is simple
so hopefully robust. We don't read from the hardware since not all
devices have physical read support.

Given that nobody noticed this until now it is likely that we are rarely if
ever hitting this case.

Reported-by: Hector Martin &lt;marcan@marcan.st&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Link: https://lore.kernel.org/r/20231026-regmap-fix-selector-sync-v1-1-633ded82770d@kernel.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>regmap: prevent noinc writes from clobbering cache</title>
<updated>2023-11-20T10:57:21Z</updated>
<author>
<name>Ben Wolsieffer</name>
<email>ben.wolsieffer@hefring.com</email>
</author>
<published>2023-11-01T14:29:27Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f6ac81f8269265e45ed58b9e655c63c14b8a99b1'/>
<id>urn:sha1:f6ac81f8269265e45ed58b9e655c63c14b8a99b1</id>
<content type='text'>
[ Upstream commit 984a4afdc87a1fc226fd657b1cd8255c13d3fc1a ]

Currently, noinc writes are cached as if they were standard incrementing
writes, overwriting unrelated register values in the cache. Instead, we
want to cache the last value written to the register, as is done in the
accelerated noinc handler (regmap_noinc_readwrite).

Fixes: cdf6b11daa77 ("regmap: Add regmap_noinc_write API")
Signed-off-by: Ben Wolsieffer &lt;ben.wolsieffer@hefring.com&gt;
Link: https://lore.kernel.org/r/20231101142926.2722603-2-ben.wolsieffer@hefring.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: debugfs: Fix a erroneous check after snprintf()</title>
<updated>2023-11-20T10:56:54Z</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2023-09-04T20:04:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=80a5d81d4cd25e7df50b6c836fcc4da61370f046'/>
<id>urn:sha1:80a5d81d4cd25e7df50b6c836fcc4da61370f046</id>
<content type='text'>
[ Upstream commit d3601857e14de6369f00ae19564f1d817d175d19 ]

This error handling looks really strange.
Check if the string has been truncated instead.

Fixes: f0c2319f9f19 ("regmap: Expose the driver name in debugfs")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Link: https://lore.kernel.org/r/8595de2462c490561f70020a6d11f4d6b652b468.1693857825.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: fix NULL deref on lookup</title>
<updated>2023-10-25T10:16:10Z</updated>
<author>
<name>Johan Hovold</name>
<email>johan+linaro@kernel.org</email>
</author>
<published>2023-10-06T08:21:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9379a0ef18528f614ff04e54b89a2e4797f97100'/>
<id>urn:sha1:9379a0ef18528f614ff04e54b89a2e4797f97100</id>
<content type='text'>
commit c6df843348d6b71ea986266c12831cb60c2cf325 upstream.

Not all regmaps have a name so make sure to check for that to avoid
dereferencing a NULL pointer when dev_get_regmap() is used to lookup a
named regmap.

Fixes: e84861fec32d ("regmap: dev_get_regmap_match(): fix string comparison")
Cc: stable@vger.kernel.org      # 5.8
Cc: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Link: https://lore.kernel.org/r/20231006082104.16707-1-johan+linaro@kernel.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>regmap: rbtree: Fix wrong register marked as in-cache when creating new node</title>
<updated>2023-10-10T20:03:00Z</updated>
<author>
<name>Richard Fitzgerald</name>
<email>rf@opensource.cirrus.com</email>
</author>
<published>2023-09-22T15:37:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bdd83fc0a5a9be3b0baa20c55ba7e049fc93ae3d'/>
<id>urn:sha1:bdd83fc0a5a9be3b0baa20c55ba7e049fc93ae3d</id>
<content type='text'>
[ Upstream commit 7a795ac8d49e2433e1b97caf5e99129daf8e1b08 ]

When regcache_rbtree_write() creates a new rbtree_node it was passing the
wrong bit number to regcache_rbtree_set_register(). The bit number is the
offset __in number of registers__, but in the case of creating a new block
regcache_rbtree_write() was not dividing by the address stride to get the
number of registers.

Fix this by dividing by map-&gt;reg_stride.
Compare with regcache_rbtree_read() where the bit is checked.

This bug meant that the wrong register was marked as present. The register
that was written to the cache could not be read from the cache because it
was not marked as cached. But a nearby register could be marked as having
a cached value even if it was never written to the cache.

Signed-off-by: Richard Fitzgerald &lt;rf@opensource.cirrus.com&gt;
Fixes: 3f4ff561bc88 ("regmap: rbtree: Make cache_present bitmap per node")
Link: https://lore.kernel.org/r/20230922153711.28103-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drivers: base: Free devm resources when unregistering a device</title>
<updated>2023-09-13T07:53:41Z</updated>
<author>
<name>David Gow</name>
<email>davidgow@google.com</email>
</author>
<published>2023-07-20T12:45:09Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c8c426fae26086a0ca8ab6cc6da2de79810ec038'/>
<id>urn:sha1:c8c426fae26086a0ca8ab6cc6da2de79810ec038</id>
<content type='text'>
[ Upstream commit 699fb50d99039a50e7494de644f96c889279aca3 ]

In the current code, devres_release_all() only gets called if the device
has a bus and has been probed.

This leads to issues when using bus-less or driver-less devices where
the device might never get freed if a managed resource holds a reference
to the device. This is happening in the DRM framework for example.

We should thus call devres_release_all() in the device_del() function to
make sure that the device-managed actions are properly executed when the
device is unregistered, even if it has neither a bus nor a driver.

This is effectively the same change than commit 2f8d16a996da ("devres:
release resources on device_del()") that got reverted by commit
a525a3ddeaca ("driver core: free devres in device_release") over
memory leaks concerns.

This patch effectively combines the two commits mentioned above to
release the resources both on device_del() and device_release() and get
the best of both worlds.

Fixes: a525a3ddeaca ("driver core: free devres in device_release")
Signed-off-by: David Gow &lt;davidgow@google.com&gt;
Signed-off-by: Maxime Ripard &lt;mripard@kernel.org&gt;
Link: https://lore.kernel.org/r/20230720-kunit-devm-inconsistencies-test-v3-3-6aa7e074f373@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>driver core: Call dma_cleanup() on the test_remove path</title>
<updated>2023-09-13T07:53:38Z</updated>
<author>
<name>Jason Gunthorpe</name>
<email>jgg@nvidia.com</email>
</author>
<published>2023-07-24T17:40:46Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2117576a33b149cc9fecb29971c6e14c76142e10'/>
<id>urn:sha1:2117576a33b149cc9fecb29971c6e14c76142e10</id>
<content type='text'>
[ Upstream commit f429378a9bf84d79a7e2cae05d2e3384cf7d68ba ]

When test_remove is enabled really_probe() does not properly pair
dma_configure() with dma_remove(), it will end up calling dma_configure()
twice. This corrupts the owner_cnt and renders the group unusable with
VFIO/etc.

Add the missing cleanup before going back to re_probe.

Fixes: 25f3bcfc54bc ("driver core: Add dma_cleanup callback in bus_type")
Reported-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Tested-by: Zenghui Yu &lt;yuzenghui@huawei.com&gt;
Closes: https://lore.kernel.org/all/6472f254-c3c4-8610-4a37-8d9dfdd54ce8@huawei.com/
Signed-off-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Reviewed-by: Kevin Tian &lt;kevin.tian@intel.com&gt;
Link: https://lore.kernel.org/r/0-v2-4deed94e283e+40948-really_probe_dma_cleanup_jgg@nvidia.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>driver core: test_async: fix an error code</title>
<updated>2023-09-13T07:53:38Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2023-07-18T07:03:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=437b2e21a70414def9722c64311de6178e4ced22'/>
<id>urn:sha1:437b2e21a70414def9722c64311de6178e4ced22</id>
<content type='text'>
[ Upstream commit 22d2381bbd70a5853c2ee77522f4965139672db9 ]

The test_platform_device_register_node() function should return error
pointers instead of NULL.  That is what the callers are expecting.

Fixes: 57ea974fb871 ("driver core: Rewrite test_async_driver_probe to cover serialization and NUMA affinity")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Link: https://lore.kernel.org/r/1e11ed19-e1f6-43d8-b352-474134b7c008@moroto.mountain
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>regmap: rbtree: Use alloc_flags for memory allocations</title>
<updated>2023-09-13T07:53:02Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@linaro.org</email>
</author>
<published>2023-07-21T14:55:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bcec8481ee555817620faac835954156eca08695'/>
<id>urn:sha1:bcec8481ee555817620faac835954156eca08695</id>
<content type='text'>
[ Upstream commit 0c8b0bf42c8cef56f7cd9cd876fbb7ece9217064 ]

The kunit tests discovered a sleeping in atomic bug.  The allocations
in the regcache-rbtree code should use the map-&gt;alloc_flags instead of
GFP_KERNEL.

[    5.005510] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306
[    5.005960] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 117, name: kunit_try_catch
[    5.006219] preempt_count: 1, expected: 0
[    5.006414] 1 lock held by kunit_try_catch/117:
[    5.006590]  #0: 833b9010 (regmap_kunit:86:(config)-&gt;lock){....}-{2:2}, at: regmap_lock_spinlock+0x14/0x1c
[    5.007493] irq event stamp: 162
[    5.007627] hardirqs last  enabled at (161): [&lt;80786738&gt;] crng_make_state+0x1a0/0x294
[    5.007871] hardirqs last disabled at (162): [&lt;80c531ec&gt;] _raw_spin_lock_irqsave+0x7c/0x80
[    5.008119] softirqs last  enabled at (0): [&lt;801110ac&gt;] copy_process+0x810/0x2138
[    5.008356] softirqs last disabled at (0): [&lt;00000000&gt;] 0x0
[    5.008688] CPU: 0 PID: 117 Comm: kunit_try_catch Tainted: G                 N 6.4.4-rc3-g0e8d2fdfb188 #1
[    5.009011] Hardware name: Generic DT based system
[    5.009277]  unwind_backtrace from show_stack+0x18/0x1c
[    5.009497]  show_stack from dump_stack_lvl+0x38/0x5c
[    5.009676]  dump_stack_lvl from __might_resched+0x188/0x2d0
[    5.009860]  __might_resched from __kmem_cache_alloc_node+0x1dc/0x25c
[    5.010061]  __kmem_cache_alloc_node from kmalloc_trace+0x30/0xc8
[    5.010254]  kmalloc_trace from regcache_rbtree_write+0x26c/0x468
[    5.010446]  regcache_rbtree_write from _regmap_write+0x88/0x140
[    5.010634]  _regmap_write from regmap_write+0x44/0x68
[    5.010803]  regmap_write from basic_read_write+0x8c/0x270
[    5.010980]  basic_read_write from kunit_try_run_case+0x48/0xa0

Fixes: 28644c809f44 ("regmap: Add the rbtree cache support")
Reported-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Closes: https://lore.kernel.org/all/ee59d128-413c-48ad-a3aa-d9d350c80042@roeck-us.net/
Signed-off-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Link: https://lore.kernel.org/r/58f12a07-5f4b-4a8f-ab84-0a42d1908cb9@moroto.mountain
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
