linux.git/drivers/base, branch v4.19.285

regmap: Account for register length when chunking

2023-06-09T08:24:04+00:00

commit 3981514180c987a79ea98f0ae06a7cbf58a9ac0f upstream.

Currently, when regmap_raw_write() splits the data, it uses the
max_raw_write value defined for the bus.  For any bus that includes
the target register address in the max_raw_write value, the chunked
transmission will always exceed the maximum transmission length.
To avoid this problem, subtract the length of the register and the
padding from the maximum transmission.

Signed-off-by: Jim Wylder

drivers: depend on HAS_IOMEM for devm_platform_ioremap_resource()

2023-05-30T11:42:15+00:00

commit 837ccda3480d2861c09aabc5fa014be18df9dd3c upstream.

We only build devm_ioremap_resource() if HAS_IOMEM is selected, so this
dependency must cascade down to devm_platform_ioremap_resource().

Signed-off-by: Bartosz Golaszewski 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Linus Walleij 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

drivers: provide devm_platform_ioremap_resource()

2023-05-30T11:42:10+00:00

[ Upstream commit 7945f929f1a77a1c8887a97ca07f87626858ff42 ]

There are currently 1200+ instances of using platform_get_resource()
and devm_ioremap_resource() together in the kernel tree.

This patch wraps these two calls in a single helper. Thanks to that
we don't have to declare a local variable for struct resource * and can
omit the redundant argument for resource type. We also have one
function call less.

Signed-off-by: Bartosz Golaszewski 
Acked-by: Greg Kroah-Hartman 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Linus Walleij 
Stable-dep-of: 8ab5fc55d7f6 ("serial: arc_uart: fix of_iomap leak in `arc_serial_probe`")
Signed-off-by: Sasha Levin

regmap: cache: Return error in cache sync operations for REGCACHE_NONE

2023-05-30T11:42:08+00:00

[ Upstream commit fd883d79e4dcd2417c2b80756f22a2ff03b0f6e0 ]

There is no sense in doing a cache sync on REGCACHE_NONE regmaps.
Instead of panicking the kernel due to missing cache_ops, return an error
to client driver.

Signed-off-by: Alexander Stein 
Link: https://lore.kernel.org/r/20230313071812.13577-1-alexander.stein@ew.tq-group.com
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin

tick/nohz: Fix cpu_is_hotpluggable() by checking with nohz subsystem

2023-05-17T09:13:22+00:00

[ Upstream commit 58d7668242647e661a20efe065519abd6454287e ]

For CONFIG_NO_HZ_FULL systems, the tick_do_timer_cpu cannot be offlined.
However, cpu_is_hotpluggable() still returns true for those CPUs. This causes
torture tests that do offlining to end up trying to offline this CPU causing
test failures. Such failure happens on all architectures.

Fix the repeated error messages thrown by this (even if the hotplug errors are
harmless) by asking the opinion of the nohz subsystem on whether the CPU can be
hotplugged.

[ Apply Frederic Weisbecker feedback on refactoring tick_nohz_cpu_down(). ]

For drivers/base/ portion:
Acked-by: Greg Kroah-Hartman 
Acked-by: Frederic Weisbecker 
Cc: Frederic Weisbecker 
Cc: "Paul E. McKenney" 
Cc: Zhouyi Zhou 
Cc: Will Deacon 
Cc: Marc Zyngier 
Cc: rcu 
Cc: stable@vger.kernel.org
Fixes: 2987557f52b9 ("driver-core/cpu: Expose hotpluggability to the rest of the kernel")
Signed-off-by: Paul E. McKenney 
Signed-off-by: Joel Fernandes (Google) 
Signed-off-by: Sasha Levin

driver core: Fix bus_type.match() error handling in __driver_attach()

2023-01-18T10:30:51+00:00

commit 27c0d217340e47ec995557f61423ef415afba987 upstream.

When a driver registers with a bus, it will attempt to match with every
device on the bus through the __driver_attach() function. Currently, if
the bus_type.match() function encounters an error that is not
-EPROBE_DEFER, __driver_attach() will return a negative error code, which
causes the driver registration logic to stop trying to match with the
remaining devices on the bus.

This behavior is not correct; a failure while matching a driver to a
device does not mean that the driver won't be able to match and bind
with other devices on the bus. Update the logic in __driver_attach()
to reflect this.

Fixes: 656b8035b0ee ("ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()")
Cc: stable@vger.kernel.org
Cc: Saravana Kannan 
Signed-off-by: Isaac J. Manjarres 
Link: https://lore.kernel.org/r/20220921001414.4046492-1-isaacmanjarres@google.com
Signed-off-by: Greg Kroah-Hartman

driver core: Set deferred_probe_timeout to a longer default if CONFIG_MODULES is set

2023-01-18T10:30:47+00:00

[ Upstream commit e2cec7d6853712295cef5377762165a489b2957f ]

When using modules, its common for the modules not to be loaded
until quite late by userland. With the current code,
driver_deferred_probe_check_state() will stop returning
EPROBE_DEFER after late_initcall, which can cause module
dependency resolution to fail after that.

So allow a longer window of 30 seconds (picked somewhat
arbitrarily, but influenced by the similar regulator core
timeout value) in the case where modules are enabled.

Cc: linux-pm@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: Linus Walleij 
Cc: Thierry Reding 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Bjorn Andersson 
Cc: Saravana Kannan 
Cc: Todd Kjos 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: Ulf Hansson 
Cc: Kevin Hilman 
Cc: "Rafael J. Wysocki" 
Cc: Rob Herring 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: John Stultz 
Link: https://lore.kernel.org/r/20200225050828.56458-3-john.stultz@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

class: fix possible memory leak in __class_register()

2023-01-18T10:30:25+00:00

[ Upstream commit 8c3e8a6bdb5253b97ad532570f8b5db5f7a06407 ]

If class_add_groups() returns error, the 'cp->subsys' need be
unregister, and the 'cp' need be freed.

We can not call kset_unregister() here, because the 'cls' will
be freed in callback function class_release() and it's also
freed in caller's error path, it will cause double free.

So fix this by calling kobject_del() and kfree_const(name) to
cleanup kobject. Besides, call kfree() to free the 'cp'.

Fault injection test can trigger this:

unreferenced object 0xffff888102fa8190 (size 8):
  comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s)
  hex dump (first 8 bytes):
    70 6b 74 63 64 76 64 00                          pktcdvd.
  backtrace:
    [<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320
    [<000000005e4d70bc>] kstrdup+0x3a/0x70
    [<00000000c2e5e85a>] kstrdup_const+0x68/0x80
    [<000000000049a8c7>] kvasprintf_const+0x10b/0x190
    [<0000000029123163>] kobject_set_name_vargs+0x56/0x150
    [<00000000747219c9>] kobject_set_name+0xab/0xe0
    [<0000000005f1ea4e>] __class_register+0x15c/0x49a

unreferenced object 0xffff888037274000 (size 1024):
  comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s)
  hex dump (first 32 bytes):
    00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff  .@'7.....@'7....
    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
  backtrace:
    [<00000000151f9600>] kmem_cache_alloc_trace+0x17c/0x2f0
    [<00000000ecf3dd95>] __class_register+0x86/0x49a

Fixes: ced6473e7486 ("driver core: class: add class_groups support")
Signed-off-by: Yang Yingliang 
Link: https://lore.kernel.org/r/20221026082803.3458760-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

PM: runtime: Do not call __rpm_callback() from rpm_idle()

2023-01-18T10:30:07+00:00

[ Upstream commit bc80c2e438dcbfcf748452ec0f7ad5b79ff3ad88 ]

Calling __rpm_callback() from rpm_idle() after adding device links
support to the former is a clear mistake.

Not only it causes rpm_idle() to carry out unnecessary actions, but it
is also against the assumption regarding the stability of PM-runtime
status across __rpm_callback() invocations, because rpm_suspend() and
rpm_resume() may run in parallel with __rpm_callback() when it is called
by rpm_idle() and the device's PM-runtime status can be updated by any
of them.

Fixes: 21d5c57b3726 ("PM / runtime: Use device links")
Link: https://lore.kernel.org/linux-pm/36aed941-a73e-d937-2721-4f0decd61ce0@quicinc.com
Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Adrian Hunter 
Signed-off-by: Sasha Levin

PM: runtime: Improve path in rpm_idle() when no callback

2023-01-18T10:30:07+00:00

[ Upstream commit 5a2bd1b1c64e1ac5627db3767ac465f18606315c ]

When pm_runtime_no_callbacks() has been called for a struct device to set
the dev->power.no_callbacks flag for it, it enables rpm_idle() to take a
slightly quicker path by assuming that a ->runtime_idle() callback would
have returned 0 to indicate success.

A device that does not have the dev->power.no_callbacks flag set for it,
may still be missing a corresponding ->runtime_idle() callback, in which
case the slower path in rpm_idle() is taken. Let's improve the behaviour
for this case, by aligning code to the quicker path.

Signed-off-by: Ulf Hansson 
Acked-by: Alan Stern 
Signed-off-by: Rafael J. Wysocki 
Stable-dep-of: bc80c2e438dc ("PM: runtime: Do not call __rpm_callback() from rpm_idle()")
Signed-off-by: Sasha Levin