With CPU re-ordering on write instructions, there might
be a chance that the HWO is set before the TRB is updated
with the new mapped buffer address.
And in the case where core is processing a list of TRBs
it is possible that it fetched the TRBs when the HWO is set
but before the buffer address is updated.
Prevent this by adding a memory barrier before the HWO
is updated to ensure that the core always process the
updated TRBs.
Change-Id: Idc008b2d4e37dd0c10c8ae40ab5af1ffd0775877
Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
* refs/heads/tmp-3f413d0:
Linux 5.4.57
bpf: sockmap: Require attach_bpf_fd when detaching a program
selftests: bpf: Fix detach from sockmap tests
ext4: fix direct I/O read error
arm64: Workaround circular dependency in pointer_auth.h
random32: move the pseudo-random 32-bit definitions to prandom.h
random32: remove net_rand_state from the latent entropy gcc plugin
random: fix circular include dependency on arm64 after addition of percpu.h
ARM: percpu.h: fix build error
random32: update the net random state on interrupt and activity
ANDROID: Update ABI xml
UPSTREAM: of: property: Add device link support for pinctrl-0 through pinctrl-8
UPSTREAM: of: property: Add device link support for multiple DT bindings
UPSTREAM: of: property: Add device link support for extcon
UPSTREAM: driver core: Change delimiter in devlink device's name to "--"
UPSTREAM: driver core: Fix sleeping in invalid context during device link deletion
BACKPORT: driver core: Add waiting_for_supplier sysfs file for devices
UPSTREAM: driver core: Add state_synced sysfs file for devices that support it
UPSTREAM: driver core: Expose device link details in sysfs
UPSTREAM: driver core: Avoid deferred probe due to fw_devlink_pause/resume()
UPSTREAM: driver core: Rename dev_links_info.defer_sync to defer_hook
UPSTREAM: driver core: Don't do deferred probe in parallel with kernel_init thread
UPSTREAM: arm64/module: Optimize module load time by optimizing PLT counting
FROMGIT: scsi: block: pm: Simplify resume handling
Change-Id: Ide67c767b3a0f455ab5cec4b571ab599eae813d5
Signed-off-by: Blagovest Kolenichev <bkolenichev@codeaurora.org>
If symmetry is enabled and user sets the brightness on switch
device directly without setting brightness on flash or torch
devices, then an error log is printed. Fix it.
Change-Id: I10cc9e3143173fb4ea9dad0ed078fde3594b6e54
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Place appropriate validation checks for IOMMU mapping size. Without
these checks, a mapping in an invalid kernel space could be created
and fail during access.
Change-Id: I995c8c2a9ef8d746b8fc2433d6510dfa92596adc
Signed-off-by: Jeya R <jeyr@codeaurora.org>
The gpu_cc_hlos1_vote_gpu_smmu_clk clock is votable by multiple masters,
so it won't always turn off when requested, since other masters can
still be voting for it. Change its halt_check to BRANCH_HALT_VOTED to
skip polling for it to turn off.
Change-Id: I8c8a0160a0055b3462c76df3fdd3403e12352e53
Signed-off-by: Mike Tipton <mdtipton@codeaurora.org>
The tx_cfg_rdy signal from PHY to Controller to indicate
EOB(END OF BURST) runs using TX CFG clock which is half the Uniproclk
freq. But it is observed that tx_cfg_rdyn signal is getting sampled in
controller using Uniproclk (300 MHz) instead of TX CFG clock (150 MHz)
and hence FSM in controller is going into unwanted state when only
one of tx_cfg_rdyn_0 and tx_cfg_rdyn_1 is 0 around sampling clock edge.
To workaround this issue, control should bypass the Cfgready
signal(TX_CFGREADY and RX_CFGREDY) because controller stills wait
for another signal tx_savestatusn which will serve same purpose.
Change-Id: I2f32542682571ba6e7b1266393dfb1168dc68658
Signed-off-by: Nitin Rawat <nitirawa@codeaurora.org>
This patch contains changes for returning power sources status
to BT HAL and also setting value of SW CTRL for CHE chip.
Change-Id: I8a0349171a5bbd516b098cc5a070804a454c2b7d
Signed-off-by: priyankar <prigup@codeaurora.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAl8tBFAACgkQONu9yGCS
aT6R3Q//aGf+Xj12a/Mi+uE7QwNxct2YA3ZM52Wd9NRf8bTcPkgNPijyC0G3Ug5g
N5sl0lyUax74AkV+AbXzMlYsV47VOh5YmmHQVBpnR7IA6a2S5XalGYAttoLr/0YR
SwqLzKWXPAcfxju2phdRQovMisljnzT/1pICV6zX2c/eFznTk/ZXVZjzAopwg4lS
a3l7nots4zy9C8v8zRXm8shQNw+jnU3rXdhwA6yc8Tri+xM8ua7rrI/uHTJK4z//
137/B5pcOAC4UVG1xWvAwfFz2j8CDnJIgahnNAxnAtYUe/auWwAzAhg3CMjknNNi
ypOCxvRc3W6s5IuRh3mnIVTJ1TTA/4bEStZmC9RR8US//XgAQie09AA4e1UbXHxl
8/RUe3O1P3wdaLkrntOG2hVHdMbxj+d/Ou4uNwf5iFq9nCuoCJJxZxEdZIojo/Rg
9rWg9GdjNLgP0imk/4e586MgR41u+MSAHNqqxa3te58mvD9CQbsvwriYIXs2uGre
HeuRfI4dFJya/txOYaVV7irPKZK1wdLbOj36+Rh/ARKkjjHU4RjfIh2h6+ACOzc0
ncX21Lv9qfiSJeKcYyYZ3Xc4SlxF+GnUW1NmOsHwrBIx9RRUvnNWFEM6oQL4WiyJ
QyYgqmuD44HdUvd4/iXVRelrYYrf3aHyLoVBVcjiAjnlb/LEkKM=
=xcgc
-----END PGP SIGNATURE-----
Merge 5.4.57 into android11-5.4
Changes in 5.4.57
random32: update the net random state on interrupt and activity
ARM: percpu.h: fix build error
random: fix circular include dependency on arm64 after addition of percpu.h
random32: remove net_rand_state from the latent entropy gcc plugin
random32: move the pseudo-random 32-bit definitions to prandom.h
arm64: Workaround circular dependency in pointer_auth.h
ext4: fix direct I/O read error
selftests: bpf: Fix detach from sockmap tests
bpf: sockmap: Require attach_bpf_fd when detaching a program
Linux 5.4.57
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3f51a779843eb1bc50ac6dc7fd9c3db66b2aea7f
commit bb0de3131f4c60a9bf976681e0fe4d1e55c7a821 upstream.
The sockmap code currently ignores the value of attach_bpf_fd when
detaching a program. This is contrary to the usual behaviour of
checking that attach_bpf_fd represents the currently attached
program.
Ensure that attach_bpf_fd is indeed the currently attached
program. It turns out that all sockmap selftests already do this,
which indicates that this is unlikely to cause breakage.
Fixes: 604326b41a ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200629095630.7933-5-lmb@cloudflare.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f43cb0d672aa8eb09bfdb779de5900c040487d1d upstream.
Fix sockmap tests which rely on old bpf_prog_dispatch behaviour.
In the first case, the tests check that detaching without giving
a program succeeds. Since these are not the desired semantics,
invert the condition. In the second case, the clean up code doesn't
supply the necessary program fds.
Fixes: bb0de3131f4c ("bpf: sockmap: Require attach_bpf_fd when detaching a program")
Reported-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Lorenz Bauer <lmb@cloudflare.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/20200709115151.75829-1-lmb@cloudflare.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is used to fix ext4 direct I/O read error when
the read size is not aligned with block size.
Then, I will use a test to explain the error.
(1) Make a file that is not aligned with block size:
$dd if=/dev/zero of=./test.jar bs=1000 count=3
(2) I wrote a source file named "direct_io_read_file.c" as following:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/file.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <string.h>
#define BUF_SIZE 1024
int main()
{
int fd;
int ret;
unsigned char *buf;
ret = posix_memalign((void **)&buf, 512, BUF_SIZE);
if (ret) {
perror("posix_memalign failed");
exit(1);
}
fd = open("./test.jar", O_RDONLY | O_DIRECT, 0755);
if (fd < 0){
perror("open ./test.jar failed");
exit(1);
}
do {
ret = read(fd, buf, BUF_SIZE);
printf("ret=%d\n",ret);
if (ret < 0) {
perror("write test.jar failed");
}
} while (ret > 0);
free(buf);
close(fd);
}
(3) Compile the source file:
$gcc direct_io_read_file.c -D_GNU_SOURCE
(4) Run the test program:
$./a.out
The result is as following:
ret=1024
ret=1024
ret=952
ret=-1
write test.jar failed: Invalid argument.
I have tested this program on XFS filesystem, XFS does not have
this problem, because XFS use iomap_dio_rw() to do direct I/O
read. And the comparing between read offset and file size is done
in iomap_dio_rw(), the code is as following:
if (pos < size) {
retval = filemap_write_and_wait_range(mapping, pos,
pos + iov_length(iov, nr_segs) - 1);
if (!retval) {
retval = mapping->a_ops->direct_IO(READ, iocb,
iov, pos, nr_segs);
}
...
}
...only when "pos < size", direct I/O can be done, or 0 will be return.
I have tested the fix patch on Ext4, it is up to the mustard of
EINVAL in man2(read) as following:
#include <unistd.h>
ssize_t read(int fd, void *buf, size_t count);
EINVAL
fd is attached to an object which is unsuitable for reading;
or the file was opened with the O_DIRECT flag, and either the
address specified in buf, the value specified in count, or the
current file offset is not suitably aligned.
So I think this patch can be applied to fix ext4 direct I/O error.
However Ext4 introduces direct I/O read using iomap infrastructure
on kernel 5.5, the patch is commit <b1b4705d54ab>
("ext4: introduce direct I/O read using iomap infrastructure"),
then Ext4 will be the same as XFS, they all use iomap_dio_rw() to do direct
I/O read. So this problem does not exist on kernel 5.5 for Ext4.
>From above description, we can see this problem exists on all the kernel
versions between kernel 3.14 and kernel 5.4. It will cause the Applications
to fail to read. For example, when the search service downloads a new full
index file, the search engine is loading the previous index file and is
processing the search request, it can not use buffer io that may squeeze
the previous index file in use from pagecache, so the serch service must
use direct I/O read.
Please apply this patch on these kernel versions, or please use the method
on kernel 5.5 to fix this problem.
Fixes: 9fe55eea7e ("Fix race when checking i_size on direct i/o read")
Reviewed-by: Jan Kara <jack@suse.cz>
Co-developed-by: Wang Long <wanglong19@meituan.com>
Signed-off-by: Wang Long <wanglong19@meituan.com>
Signed-off-by: Jiang Ying <jiangying8582@126.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With the backport of f227e3ec3b5c ("random32: update the net random
state on interrupt and activity") and its associated fixes, the
arm64 build explodes early:
In file included from ../include/linux/smp.h:67,
from ../include/linux/percpu.h:7,
from ../include/linux/prandom.h:12,
from ../include/linux/random.h:118,
from ../arch/arm64/include/asm/pointer_auth.h:6,
from ../arch/arm64/include/asm/processor.h:39,
from ../include/linux/mutex.h:19,
from ../include/linux/kernfs.h:12,
from ../include/linux/sysfs.h:16,
from ../include/linux/kobject.h:20,
from ../include/linux/of.h:17,
from ../include/linux/irqdomain.h:35,
from ../include/linux/acpi.h:13,
from ../include/acpi/apei.h:9,
from ../include/acpi/ghes.h:5,
from ../include/linux/arm_sdei.h:8,
from ../arch/arm64/kernel/asm-offsets.c:10:
../arch/arm64/include/asm/smp.h💯29: error: field ‘ptrauth_key’ has
incomplete type
This is due to struct ptrauth_keys_kernel not being defined before
we transitively include asm/smp.h from linux/random.h.
Paper over it by moving the inclusion of linux/random.h *after* the
type has been defined.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c0842fbc1b18c7a044e6ff3e8fa78bfa822c7d1a upstream.
The addition of percpu.h to the list of includes in random.h revealed
some circular dependencies on arm64 and possibly other platforms. This
include was added solely for the pseudo-random definitions, which have
nothing to do with the rest of the definitions in this file but are
still there for legacy reasons.
This patch moves the pseudo-random parts to linux/prandom.h and the
percpu.h include with it, which is now guarded by _LINUX_PRANDOM_H and
protected against recursive inclusion.
A further cleanup step would be to remove this from <linux/random.h>
entirely, and make people who use the prandom infrastructure include
just the new header file. That's a bit of a churn patch, but grepping
for "prandom_" and "next_pseudo_random32" "struct rnd_state" should
catch most users.
But it turns out that that nice cleanup step is fairly painful, because
a _lot_ of code currently seems to depend on the implicit include of
<linux/random.h>, which can currently come in a lot of ways, including
such fairly core headfers as <linux/net.h>.
So the "nice cleanup" part may or may never happen.
Fixes: 1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
Tested-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 83bdc7275e6206f560d247be856bceba3e1ed8f2 upstream.
It turns out that the plugin right now ends up being really unhappy
about the change from 'static' to 'extern' storage that happened in
commit f227e3ec3b5c ("random32: update the net random state on interrupt
and activity").
This is probably a trivial fix for the latent_entropy plugin, but for
now, just remove net_rand_state from the list of things the plugin
worries about.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Emese Revfy <re.emese@gmail.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1c9df907da83812e4f33b59d3d142c864d9da57f upstream.
Daniel Díaz and Kees Cook independently reported that commit
f227e3ec3b5c ("random32: update the net random state on interrupt and
activity") broke arm64 due to a circular dependency on include files
since the addition of percpu.h in random.h.
The correct fix would definitely be to move all the prandom32 stuff out
of random.h but for backporting, a smaller solution is preferred.
This one replaces linux/percpu.h with asm/percpu.h, and this fixes the
problem on x86_64, arm64, arm, and mips. Note that moving percpu.h
around didn't change anything and that removing it entirely broke
differently. When backporting, such options might still be considered
if this patch fails to help.
[ It turns out that an alternate fix seems to be to just remove the
troublesome <asm/pointer_auth.h> remove from the arm64 <asm/smp.h>
that causes the circular dependency.
But we might as well do the whole belt-and-suspenders thing, and
minimize inclusion in <linux/random.h> too. Either will fix the
problem, and both are good changes. - Linus ]
Reported-by: Daniel Díaz <daniel.diaz@linaro.org>
Reported-by: Kees Cook <keescook@chromium.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Fixes: f227e3ec3b5c
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aa54ea903abb02303bf55855fb51e3fcee135d70 upstream.
Fix build error for the case:
defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)
config: keystone_defconfig
CC arch/arm/kernel/signal.o
In file included from ../include/linux/random.h:14,
from ../arch/arm/kernel/signal.c:8:
../arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’:
../arch/arm/include/asm/percpu.h:29:34: error: ‘current_stack_pointer’ undeclared (first use in this function); did you mean ‘user_stack_pointer’?
: "Q" (*(const unsigned long *)current_stack_pointer));
^~~~~~~~~~~~~~~~~~~~~
user_stack_pointer
Fixes: f227e3ec3b5c ("random32: update the net random state on interrupt and activity")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f227e3ec3b5cad859ad15666874405e8c1bbc1d4 upstream.
This modifies the first 32 bits out of the 128 bits of a random CPU's
net_rand_state on interrupt or CPU activity to complicate remote
observations that could lead to guessing the network RNG's internal
state.
Note that depending on some network devices' interrupt rate moderation
or binding, this re-seeding might happen on every packet or even almost
never.
In addition, with NOHZ some CPUs might not even get timer interrupts,
leaving their local state rarely updated, while they are running
networked processes making use of the random state. For this reason, we
also perform this update in update_process_times() in order to at least
update the state when there is user or system activity, since it's the
only case we care about.
Reported-by: Amit Klein <aksecurity@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Leaf changes summary: 642 artifacts changed (2214 filtered out)
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 632 Changed (2201 filtered out), 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 9 Changed (13 filtered out), 0 Added variable
632 functions with some sub-type change:
... lots of CRC changes ...
'struct device_link at device.h:1139:1' changed:
type size changed from 704 to 7808 (in bits)
1 data member insertion:
'device device_link::link_dev', at offset 384 (in bits) at device.h:1366:1
there are data member changes:
'device_link_state device_link::status' offset changed from 384 to 7488 (in bits) (by +7104 bits)
'u32 device_link::flags' offset changed from 416 to 7520 (in bits) (by +7104 bits)
'refcount_t device_link::rpm_active' offset changed from 448 to 7552 (in bits) (by +7104 bits)
'kref device_link::kref' offset changed from 480 to 7584 (in bits) (by +7104 bits)
'callback_head device_link::callback_head' offset changed from 512 to 7616 (in bits) (by +7104 bits)
'bool device_link::supplier_preactivated' offset changed from 640 to 7744 (in bits) (by +7104 bits)
2 impacted interfaces
Bug: 163090256
Bug: 157691602
Change-Id: Ia4d75e7d43fb546a88e682c3c66aac0bd47304fc
Signed-off-by: Saravana Kannan <saravanak@google.com>
Add support for pinctrl-0 through pinctrl-8 explicitly instead of trying
to add support for pinctrl-%d properties.
Of all the pinctrl-* properties in dts files (20322), only 47% (9531)
are pinctrl-%d properties. Of all the pinctrl-%d properties, 99.5%
(9486) are made up of pinctrl-[0-2]. 'pinctrl-8' is the current maximum
found in dts files.
Trying to parse all pinctrl-* properties and checking for pinctrl-%d is
unnecessarily complicated. So, just add support for pinctrl-[0-8] for
now. In the unlikely event we ever exceed pinctrl-8, we can come back
and improve this.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200724234415.1651639-2-saravanak@google.com
Signed-off-by: Rob Herring <robh@kernel.org>
(cherry picked from commit fb820b494acb70e3a20e50935118239c7e5c94dd)
Signed-off-by: Saravana Kannan <saravanak@google.com>
Bug: 163091301
Change-Id: I1ad8ba1b784a59a4230ac04331139c13da5d32ed
Add support for creating device links out of more DT properties.
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Rob Herring <robh@kernel.org>
(cherry picked from commit 78056e701c61132d15e0942e415926a6393fcf17)
Signed-off-by: Saravana Kannan <saravanak@google.com>
Bug: 163091301
Change-Id: Ifbf40d33788e59003a80c918098b08e94257d350
The devlink device name is of the form "supplier:consumer". But ":" is
fairly common in device names and makes it visually hard to distinguish
supplier and consumer. So, replace it with "--" to make it easier.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200724180523.1393383-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 90b109d50da09ddaa179732c01ccba7f759c125d)
Signed-off-by: Saravana Kannan <saravanak@google.com>
Bug: 163090256
Change-Id: Ibda7db293de6c2e0d9f963e61f2cec0321c82e09
Marek and Guenter reported that commit 287905e68dd2 ("driver core:
Expose device link details in sysfs") caused sleeping/scheduling while
atomic warnings.
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:935
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 12, name: kworker/0:1
2 locks held by kworker/0:1/12:
#0: ee8074a8 ((wq_completion)rcu_gp){+.+.}-{0:0}, at: process_one_work+0x174/0x7dc
#1: ee921f20 ((work_completion)(&sdp->work)){+.+.}-{0:0}, at: process_one_work+0x174/0x7dc
Preemption disabled at:
[<c01b10f0>] srcu_invoke_callbacks+0xc0/0x154
----- 8< ----- SNIP
[<c064590c>] (device_del) from [<c0645c9c>] (device_unregister+0x24/0x64)
[<c0645c9c>] (device_unregister) from [<c01b10fc>] (srcu_invoke_callbacks+0xcc/0x154)
[<c01b10fc>] (srcu_invoke_callbacks) from [<c01493c4>] (process_one_work+0x234/0x7dc)
[<c01493c4>] (process_one_work) from [<c01499b0>] (worker_thread+0x44/0x51c)
[<c01499b0>] (worker_thread) from [<c0150bf4>] (kthread+0x158/0x1a0)
[<c0150bf4>] (kthread) from [<c0100114>] (ret_from_fork+0x14/0x20)
Exception stack(0xee921fb0 to 0xee921ff8)
This was caused by the device link device being released in the context
of srcu_invoke_callbacks(). There is no need to wait till the RCU
callback to release the device link device. So release the device
earlier and move the call_srcu() into the device release code. That way,
the memory will get freed only after the device is released AND the RCU
callback is called.
Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs")
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20200716214523.2924704-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 843e600b8a2b01463c4d873a90b2c2ea8033f1f6)
Signed-off-by: Saravana Kannan <saravanak@google.com>
Bug: 163090256
Change-Id: I3381dcf475ff55ee5971a57968f847eeef36e05b
This would be useful to check if a device is not probing because it's
waiting for a supplier to be added and then linked to before it can
probe.
To reduce sysfs clutter, this file is added only if it can ever be 1.
So, if fw_devlink is disabled or set to permissive, this file is not
added. Also, this file is removed once the device probes as it's no
longer relevant.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200521191800.136035-4-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit da6d647598a6d182eb6a0344a7b14ae005244399)
[Conflicts due to missing fw_devlink_is_permissive() and fw_devlink_flags]
Signed-off-by: Saravana Kannan <saravanak@google.com>
Bug: 163090256
Change-Id: Ief4b9e35aff600f2eb88d15839e98a610f1c252f
This can be used to check if a device supports sync_state() callbacks
and therefore keeps resources left on by the bootloader enabled till all
its consumers have probed.
This can also be used to check if sync_state() has been called for a
device or whether it is still trying to keep resources enabled because
they were left enabled by the bootloader and all its consumers haven't
probed yet.
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200521191800.136035-3-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8fd456ec0cf03875908d6b67c1cd20cf0a7b4474)
Signed-off-by: Saravana Kannan <saravanak@google.com>
Bug: 163090256
Change-Id: I15b6db469e545eed9ecc97aca02ea90e7d318f2c
It's helpful to be able to look at device link details from sysfs. So,
expose it in sysfs.
Say device-A is supplier of device-B. These are the additional files
this patch would create:
/sys/class/devlink/device-A:device-B/
auto_remove_on
consumer/ -> .../device-B/
runtime_pm
status
supplier/ -> .../device-A/
sync_state_only
/sys/devices/.../device-A/
consumer:device-B/ -> /sys/class/devlink/device-A:device-B/
/sys/devices/.../device-B/
supplier:device-A/ -> /sys/class/devlink/device-A:device-B/
That way:
To get a list of all the device link in the system:
ls /sys/class/devlink/
To get the consumer names and links of a device:
ls -d /sys/devices/.../device-X/consumer:*
To get the supplier names and links of a device:
ls -d /sys/devices/.../device-X/supplier:*
Signed-off-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200521191800.136035-2-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 287905e68dd29873bcb7986a8290cd1e4cfde600)
Signed-off-by: Saravana Kannan <saravanak@google.com>
Bug: 163090256
Change-Id: I41dafdd731b8d429b5a21fd2e8d4d396b2bb571e
With the earlier patch in this series, all devices that deferred probe
due to fw_devlink_pause() will have their probes delayed till the
deferred probe thread is kicked off during late_initcall. This will also
affect all their consumers.
This delayed probing in unnecessary. So this patch just keeps track of
the devices that had their probe deferred due to fw_devlink_pause() and
attempts to probe them once during fw_devlink_resume().
Fixes: 716a7a259690 ("driver core: fw_devlink: Add support for batching fwnode parsing")
Signed-off-by: Saravana Kannan <saravanak@google.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200701194259.3337652-4-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2451e746478a6a6e981cfa66b62b791ca93b90c8)
Signed-off-by: Saravana Kannan <saravanak@google.com>
Bug: 157691602
Change-Id: I76205ec0851fa251da5df485b1503b65b3296c7c
