SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
against unused function warnings. The new combination of pm_sleep_ptr()
and DEFINE_SIMPLE_DEV_PM_OPS() allows the compiler to see the functions,
thus suppressing the warning, but still allowing the unused code to be
removed. Thus also drop the __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230102181842.718010-10-jic23@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
against unused function warnings. The new combination of pm_sleep_ptr()
and DEFINE_SIMPLE_DEV_PM_OPS() allows the compiler to see the functions,
thus suppressing the warning, but still allowing the unused code to be
removed. Thus also drop the __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Jeff LaBundy <jeff@labundy.com>
Reviewed-by: Jeff LaBundy <jeff@labundy.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230102181842.718010-9-jic23@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
against unused function warnings. The new combination of pm_sleep_ptr()
and DEFINE_SIMPLE_DEV_PM_OPS() allows the compiler to see the functions,
thus suppressing the warning, but still allowing the unused code to be
removed. Thus also drop the __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230102181842.718010-8-jic23@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
against unused function warnings. The new combination of pm_sleep_ptr()
and DEFINE_SIMPLE_DEV_PM_OPS() allows the compiler to see the functions,
thus suppressing the warning, but still allowing the unused code to be
removed. Thus also drop the __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Moritz Fischer <mdf@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230102181842.718010-7-jic23@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
against unused function warnings. The new combination of pm_sleep_ptr()
and DEFINE_SIMPLE_DEV_PM_OPS() allows the compiler to see the functions,
thus suppressing the warning, but still allowing the unused code to be
removed. Thus also drop the __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230102181842.718010-6-jic23@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
against unused function warnings. The new combination of pm_sleep_ptr()
and DEFINE_SIMPLE_DEV_PM_OPS() allows the compiler to see the functions,
thus suppressing the warning, but still allowing the unused code to be
removed. Thus also drop the __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230102181842.718010-5-jic23@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
against unused function warnings. The new combination of pm_sleep_ptr()
and DEFINE_SIMPLE_DEV_PM_OPS() allows the compiler to see the functions,
thus suppressing the warning, but still allowing the unused code to be
removed. Thus also drop the __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230102181842.718010-4-jic23@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
against unused function warnings. The new combination of pm_sleep_ptr()
and DEFINE_SIMPLE_DEV_PM_OPS() allows the compiler to see the functions,
thus suppressing the warning, but still allowing the unused code to be
removed. Thus also drop the __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Roy Im <roy.im.opensource@diasemi.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230102181842.718010-3-jic23@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
SIMPLE_DEV_PM_OPS() is deprecated as it requires explicit protection
against unused function warnings. The new combination of pm_sleep_ptr()
and DEFINE_SIMPLE_DEV_PM_OPS() allows the compiler to see the functions,
thus suppressing the warning, but still allowing the unused code to be
removed. Thus also drop the __maybe_unused markings.
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230102181842.718010-2-jic23@kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Use NULL for NULL pointer to fix the following sparse warning:
drivers/cpufreq/armada-37xx-cpufreq.c:448:32: sparse: warning: Using plain integer as NULL pointer
Signed-off-by: Miles Chen <miles.chen@mediatek.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
It was determined that the do_idr_lock parameter to
bpf_prog_free_id() was not necessary as it should always be true.
Suggested-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Acked-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/r/20230106154400.74211-2-paul@paul-moore.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
When changing the ebpf program put() routines to support being called
from within IRQ context the program ID was reset to zero prior to
calling the perf event and audit UNLOAD record generators, which
resulted in problems as the ebpf program ID was bogus (always zero).
This patch addresses this problem by removing an unnecessary call to
bpf_prog_free_id() in __bpf_prog_offload_destroy() and adjusting
__bpf_prog_put() to only call bpf_prog_free_id() after audit and perf
have finished their bpf program unload tasks in
bpf_prog_put_deferred(). For the record, no one can determine, or
remember, why it was necessary to free the program ID, and remove it
from the IDR, prior to executing bpf_prog_put_deferred();
regardless, both Stanislav and Alexei agree that the approach in this
patch should be safe.
It is worth noting that when moving the bpf_prog_free_id() call, the
do_idr_lock parameter was forced to true as the ebpf devs determined
this was the correct as the do_idr_lock should always be true. The
do_idr_lock parameter will be removed in a follow-up patch, but it
was kept here to keep the patch small in an effort to ease any stable
backports.
I also modified the bpf_audit_prog() logic used to associate the
AUDIT_BPF record with other associated records, e.g. @ctx != NULL.
Instead of keying off the operation, it now keys off the execution
context, e.g. '!in_irg && !irqs_disabled()', which is much more
appropriate and should help better connect the UNLOAD operations with
the associated audit state (other audit records).
Cc: stable@vger.kernel.org
Fixes: d809e134be ("bpf: Prepare bpf_prog_put() to be called from irq context.")
Reported-by: Burn Alting <burn.alting@iinet.net.au>
Reported-by: Jiri Olsa <olsajiri@gmail.com>
Suggested-by: Stanislav Fomichev <sdf@google.com>
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Acked-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/r/20230106154400.74211-1-paul@paul-moore.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a
validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid
combination according to the comment above 'struct nla_policy':
"
Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN:
NLA_BINARY Validation function called for the attribute.
All other Unused - but note that it's a union
"
This can trigger the warning [1] in nla_get_range_unsigned() when
validation of the attribute fails. Despite being of 'NLA_U32' type, the
associated 'min'/'max' fields in the policy are negative as they are
aliased by the 'validate' field.
Fix by changing the attribute type to 'NLA_BINARY' which is consistent
with the above comment and all other users of NLA_POLICY_VALIDATE_FN().
As a result, move the length validation to the validation function.
No regressions in MPLS tests:
# ./tdc.py -f tc-tests/actions/mpls.json
[...]
# echo $?
0
[1]
WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118
nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
Modules linked in:
CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
[...]
Call Trace:
<TASK>
__netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310
netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411
netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]
netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506
netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546
rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg net/socket.c:734 [inline]
____sys_sendmsg+0x38f/0x500 net/socket.c:2482
___sys_sendmsg net/socket.c:2536 [inline]
__sys_sendmsg+0x197/0x230 net/socket.c:2565
__do_sys_sendmsg net/socket.c:2574 [inline]
__se_sys_sendmsg net/socket.c:2572 [inline]
__x64_sys_sendmsg+0x42/0x50 net/socket.c:2572
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Link: https://lore.kernel.org/netdev/CAO4mrfdmjvRUNbDyP0R03_DrD_eFCLCguz6OxZ2TYRSv0K9gxA@mail.gmail.com/
Fixes: 2a2ea50870 ("net: sched: add mpls manipulation actions to TC")
Reported-by: Wei Chen <harperchen1110@gmail.com>
Tested-by: Wei Chen <harperchen1110@gmail.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://lore.kernel.org/r/20230107171004.608436-1-idosch@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that the needed changes have been made to fs/buffer.c, ext4 is ready
to support the verity feature when the filesystem block size is less
than the page size. So remove the mount-time check that prevented this.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20221223203638.41293-12-ebiggers@kernel.org
After each filesystem block (as represented by a buffer_head) has been
read from disk by block_read_full_folio(), verify it if needed. The
verification is done on the fsverity_read_workqueue. Also allow reads
of verity metadata past i_size, as required by ext4.
This is needed to support fsverity on ext4 filesystems where the
filesystem block size is less than the page size.
The new code is compiled away when CONFIG_FS_VERITY=n.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20221223203638.41293-11-ebiggers@kernel.org
Now that the implementation of FS_IOC_ENABLE_VERITY has changed to not
involve reading back Merkle tree blocks that were previously written,
there is no need for f2fs_readpage_limit() to allow for this case.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20221223203638.41293-10-ebiggers@kernel.org
Now that the implementation of FS_IOC_ENABLE_VERITY has changed to not
involve reading back Merkle tree blocks that were previously written,
there is no need for ext4_readpage_limit() to allow for this case.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20221223203638.41293-9-ebiggers@kernel.org
Make FS_IOC_ENABLE_VERITY support values of
fsverity_enable_arg::block_size other than PAGE_SIZE.
To make this possible, rework build_merkle_tree(), which was reading
data and hash pages from the file and assuming that they were the same
thing as "blocks".
For reading the data blocks, just replace the direct pagecache access
with __kernel_read(), to naturally read one block at a time.
(A disadvantage of the above is that we lose the two optimizations of
hashing the pagecache pages in-place and forcing the maximum readahead.
That shouldn't be very important, though.)
The hash block reads are a bit more difficult to handle, as the only way
to do them is through fsverity_operations::read_merkle_tree_page().
Instead, let's switch to the single-pass tree construction algorithm
that fsverity-utils uses. This eliminates the need to read back any
hash blocks while the tree is being built, at the small cost of an extra
block-sized memory buffer per Merkle tree level. This is probably what
I should have done originally.
Taken together, the above two changes result in page-size independent
code that is also a bit simpler than what we had before.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20221223203638.41293-8-ebiggers@kernel.org
Add support for verifying data from verity files whose Merkle tree block
size is less than the page size. The main use case for this is to allow
a single Merkle tree block size to be used across all systems, so that
only one set of fsverity file digests and signatures is needed.
To do this, eliminate various assumptions that the Merkle tree block
size and the page size are the same:
- Make fsverity_verify_page() a wrapper around a new function
fsverity_verify_blocks() which verifies one or more blocks in a page.
- When a Merkle tree block is needed, get the corresponding page and
only verify and use the needed portion. (The Merkle tree continues to
be read and cached in page-sized chunks; that doesn't need to change.)
- When the Merkle tree block size and page size differ, use a bitmap
fsverity_info::hash_block_verified to keep track of which Merkle tree
blocks have been verified, as PageChecked cannot be used directly.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20221223203638.41293-7-ebiggers@kernel.org
In preparation for allowing the Merkle tree block size to differ from
PAGE_SIZE, replace fsverity_hash_page() with fsverity_hash_block(). The
new function is similar to the old one, but it operates on the block at
the given offset in the page instead of on the full page.
(For now, all callers still pass a full page.)
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20221223203638.41293-6-ebiggers@kernel.org
Currently, there is an implementation limit where files can't have more
than 8 Merkle tree levels. With SHA-256 and 4K blocks, this limit is
never reached, since a file would need to be larger than 2**64 bytes to
need 9 levels. However, with SHA-512, 9 levels are needed for files
larger than about 1.15 EB, which is possible on btrfs. Therefore, this
limit technically became reachable when btrfs added fsverity support.
Meanwhile, support for merkle_tree_block_size < PAGE_SIZE will introduce
another implementation limit on file size, resulting from the use of an
in-memory bitmap to track which Merkle tree blocks have been verified.
In any case, currently FS_IOC_ENABLE_VERITY fails with EINVAL when the
file is too large. This is undocumented, and also ambiguous since
EINVAL can mean other things too. Let's change the error code to EFBIG,
which is much clearer, and document it.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20221223203638.41293-5-ebiggers@kernel.org
Add log_digestsize to struct merkle_tree_params so that it can be used
in verify.c. Also save memory by using u8 for all the log_* fields.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20221223203638.41293-4-ebiggers@kernel.org
First, calculate max_ra_pages more efficiently by using the bio size.
Second, calculate the number of readahead pages from the hash page
index, instead of calculating it ahead of time using the data page
index. This ends up being a bit simpler, especially since level 0 is
last in the tree, so we can just limit the readahead to the tree size.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20221223203638.41293-3-ebiggers@kernel.org
fs/verity/ isn't consistent with whether Merkle tree block indices are
'unsigned long' or 'u64'. There's no real point to using u64 for them,
though, since (a) a Merkle tree with over ULONG_MAX blocks would only be
needed for a file larger than MAX_LFS_FILESIZE, and (b) for reads, the
status of all Merkle tree blocks has to be tracked in memory.
Therefore, let's make things a bit more efficient on 32-bit systems by
using 'unsigned long[]' for merkle_tree_params::level_start, instead of
'u64[]'. Also, to be extra safe, explicitly check that there aren't
more than ULONG_MAX Merkle tree blocks.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Andrey Albershteyn <aalbersh@redhat.com>
Tested-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20221223203638.41293-2-ebiggers@kernel.org
User resource lookups used rcu to avoid two extra atomics. Unfortunately
the rcu paths were buggy and it was easy to make the driver crash by
submitting command buffers from two different threads. Because the
lookups never show up in performance profiles replace them with a
regular spin lock which fixes the races in accesses to those shared
resources.
Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and
seen crashes with apps using shared resources.
Fixes: e14c02e6b6 ("drm/vmwgfx: Look up objects without taking a reference")
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221207172907.959037-1-zack@kde.org
This enables link partner advertised support to show link modes and
pause frame use.
Signed-off-by: Jamie Gloudon <jamie.gloudon@gmx.fr>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20230103230653.1102544-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference. For that reason, dropping
the handle's reference must be done *after* we are done dereferencing
the object.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Fixes: 62fb7a5e10 ("virtio-gpu: add 3d/virgl support")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221216233355.542197-2-robdclark@gmail.com
We had already disabled this warning for gcc-12 due to bugs in the value
range analysis, but it turns out we end up having some similar problems
with gcc-11.3 too, so let's disable it there too.
Older gcc versions end up being increasingly less relevant, and
hopefully clang and newer version of gcc (ie gcc-13) end up working
reliably enough that we still get the build coverage even when we
disable this for some versions.
Link: https://lore.kernel.org/all/20221227002941.GA2691687@roeck-us.net/
Link: https://lore.kernel.org/all/D8BDBF66-E44C-45D4-9758-BAAA4F0C1998@kernel.org/
Cc: Kees Cook <kees@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
While going through the removal of board files on some other
platforms, I noticed a bit of outdated code on omap2+ that
was left behind after the platform became DT only.
This is a separate branch, to avoid conflicts with other omap2
changes.
* 'omap/omap2-cleanup' of https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
ARM: omap2: make functions static
ARM: omap2: remove unused omap2_pm_init
ARM: omap2: remove unused declarations
ARM: omap2: remove unused functions
ARM: omap2: smartreflex: remove on_init control
ARM: omap2: remove APLL control
ARM: omap2: simplify clock2xxx header
ARM: omap2: remove unused omap_hwmod_reset.c
ARM: omap2: remove unused headers
ARM: omap2: remove unused USB code
ARM: remove CONFIG_UNUSED_BOARD_FILES
Avoid a build error by disabling the invalid combination of building
reset-ti-sci built-in but ti-sci as a module.
Fix a possible NULL pointer dereference in reset-uniphier-glue in case
platform_get_resource() fails.
-----BEGIN PGP SIGNATURE-----
iI0EABYIADUWIQRRO6F6WdpH1R0vGibVhaclGDdiwAUCY7VMThcccC56YWJlbEBw
ZW5ndXRyb25peC5kZQAKCRDVhaclGDdiwDBIAQCh6Cc1gJtYi08WbF3nGB3ojKAz
+ciz6F8gBhXMphCahAEAoFpMjiIjkxvN5e1E+Rvxix5DzUJoteVtE1fIOtrNjAg=
=PQAz
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmO8kikACgkQmmx57+YA
GNktLQ//SdDorslDy/GfR46tZddaruMo3AXQ84zOjVz0cQOH613nTE5P487b8+y+
h+MIW6KJQNgwLi7zLAF0SVZjV50LkF7ic52IyZlaVbri6sMsoVEm0jIp8UWVy5bU
JV23VWd4kpgoNvK6b0QlhrytU3AVV1oZfbK+PJoINMPZUM76qwKijASH0778c7AF
jWrPQE3jCQ4UqudfBq8PAcu/j5ALp4GKkWSIiqFlesho/lCG+Ycto0tTPUfPDCFL
lmv2sdiUIv5X5Y/MkB99DH/nTY81LlmIs3KHD22QYMDrqE6R2vX3OiQ/bfKcCvPg
KAA96+XLXuWUZAc3ldJIDAZ++fsEFvyPLAg74uFZVgqcUEFYoh07WOVJpAbTYOSN
kJ49k+LtI/58iOoekjj+/95/pD3lg5HE87N2XIw199AhA8fIW+oKIrq7aYlECHjS
FN7871/Jtt45QACYCmtWM0YmDmRI1gaGLbXRdvEtyK4U5h4nh8HRkxdVk+DcB83W
2glSqpgIPnKtqgDSg/14dv4p5BaLd5v8Cm6GFavfAGBJSrHBr2ZFguV74i9ixVUJ
AoXFlguO0G1OrYsfppW7bF1ThgebBV88F4ESxeLyWnP4VOhnJdo8Yg1i/2FQyN+q
iPIvlDOpBFuOyMqIZhYeSe/hCroZ3OWA2xhv2B32g/m1HK/HCIk=
=Q4/c
-----END PGP SIGNATURE-----
Merge tag 'reset-fixes-for-v6.2' of git://git.pengutronix.de/pza/linux into arm/fixes
Reset controller fixes for v6.2
Avoid a build error by disabling the invalid combination of building
reset-ti-sci built-in but ti-sci as a module.
Fix a possible NULL pointer dereference in reset-uniphier-glue in case
platform_get_resource() fails.
* tag 'reset-fixes-for-v6.2' of git://git.pengutronix.de/pza/linux:
reset: uniphier-glue: Fix possible null-ptr-deref
reset: ti-sci: honor TI_SCI_PROTOCOL setting when not COMPILE_TEST
Link: https://lore.kernel.org/r/20230104095855.3809733-1-p.zabel@pengutronix.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Few fixes addressing:
1. Possible compromise with the shorter message size from a misbheaving
SCMI platform firmware. The shmem accesses are now hardened to handle
the same in fetch_notification and fetch_response.
2. Possible unsafe locking scenario which is solved by calling
virtio_break_device() before getting hold of vioch->lock.
3. Possible stale error status reported from a previous message being
used again as it is not cleared.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmO3s5sACgkQAEG6vDF+
4phoag/+KShujYrx9bTvpZc+6f6AbDaUHVJmgQZko6Hlw2CdjQUbL0NU+hrwglIb
InsaRdMGGFBGCv1XsXFCHlw9N8hO47r8z+HxWAXW+jvW99ywPL9lMFamtwTj65Ib
NR0Qm1jGNRrWwgWaZxcjlz2gVTurHZN3ZGacIzxl0TAakx4Tlfh/8b/8RGegJ9L4
sVkJiXaUoEcPLQ6uZqrEqZIte737cUILw5HBaCRrUhVdYH7goAYSUbxnWrHPZLXG
lYzEFEU6ayy2/iHaJEBekOg4xfD0QKBjJrgHz5IOVhFY04oDGIphEELDEW3OK62K
FYXhNG9lrbhgwyYtFmh1HIo7Sf6bkgzkVRNf0pl88hhURALEgVRsxlOvGCno9//Q
FyOS2xwlL0Y2xT8ka8RAkT21o6pTttKM1eJ3kdjabOvQcvqoTo/WzP2Ju6ZoXzur
Nedj0i3gh6JKuU1fmmVJuQ753lnNzm73i813uAzsCkAgLpX+kDYgHuyNldK3dLv2
1WWkqa6GZjxOAfo/dnM/cYV6Shoy6++TenRpQH8wENRj/1254UTafQz6i79Ejmdu
cSgGrrsYU0UxeBbNeow6z9xEK9SEefEaZUgD+hlFMhepux57mxYNrRpkLWKAZ/kC
Ei46ZacWQpQe/sWcX09kIYBe6P9Wab/UObdY/vGciDalTFMMCV0=
=f+vJ
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmO8ke0ACgkQmmx57+YA
GNk7fhAAphlezeNNhwJyQ68ruZhf5z6ilOBvLFKr5kOVdDeQ7clX6ChN00NX00lV
7VWB+rsb0By1vPm4QMVBfeyGe4bFYic2YiTPLMjbV2MUt1lTZrHgWfazuzBtKO+y
hyPmaOA3WuDrdZSCSkUWLJegV6Jzj3b2TKlYW/gdkvcTE2zcGNjTVh3WYjgEmPKl
FwJ4ozb3iDUviXvfOz+GaqX6w7LicuHytgc3OOtDoiAAgJN26duzY5WIKLG3COcu
5MaocOziM2QXLV+OJt2K9L+jgskuLhbTGUZKKPgc3MI0avts4IY8I3dvZogjzOys
fsZCBKQJK4P29lgv1EOOsSot0O64VLlZA4xFLvyUCubRAY3VUT4NvOTmofDWKX0A
Lq9YolinwYyRlga7R/n9pluzwqDv6PZH8cYndNiz1uh7UztLLxS5TN6AEwRHKYf9
qDPp58goXHow9+cw9iY9j6CLYAb1lxiyO4e2OpkqbSOp+qS/H8rLemUiQVvoKoUy
cM6pB9cNGAwbmafPhYXrhmlPbKYVaW6rE9g4y5BPCjqoNT9bUVVu4LHGv7l79tjF
+mUZFgZ95sVO8EBasd3B2bhEa8ZijwpOqrr9reMCBimwqq2n6aagVl98u62lbuam
oiKBa6yAjokoCIAd4C9/bqZvHUmLiYuqfCAaYohz3xTl+ActbQ0=
=Th/N
-----END PGP SIGNATURE-----
Merge tag 'scmi-fixes-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Arm SCMI fixes for v6.2
Few fixes addressing:
1. Possible compromise with the shorter message size from a misbheaving
SCMI platform firmware. The shmem accesses are now hardened to handle
the same in fetch_notification and fetch_response.
2. Possible unsafe locking scenario which is solved by calling
virtio_break_device() before getting hold of vioch->lock.
3. Possible stale error status reported from a previous message being
used again as it is not cleared.
* tag 'scmi-fixes-6.2' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Fix virtio channels cleanup on shutdown
firmware: arm_scmi: Harden shared memory access in fetch_notification
firmware: arm_scmi: Harden shared memory access in fetch_response
firmware: arm_scmi: Clear stale xfer->hdr.status
Link: https://lore.kernel.org/r/20230106093909.652657-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Broken in v6.2:
1. OMAP GPMC: do not fail if "gpmc,wait-pin" optional property
(introduced for v6.2) is missing.
Broken earlier:
1. Tegra MC: Drop SID override programming as it is handled by
bootloader and doing it in the kernel can cause unexpected results.
2. Atmel SDRAMC, MVEBU devbus: Add missing clock unprepare/disable in
exit and error paths.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmO8LEcQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD14SuD/wKnO0cjQ183vLQ9HQghpRmyiQ1EMDGcWyY
zBh4wB9bOmA33leshGDCxYMyqTzgyZHW6iH4fKcGKmPmOnekRVnVUqEAdLq2Yi7S
DzNpbQXWjPx1eEZtYTKKLny/GGa03zk9X8L0784llKsujX2slTpVgDav9z+ChdUj
x+oIP8tk2n1i9gF6cDaAT/yDJMSGhj8BLoonZNuNj5PpFDWMJjAVjl+7jtF5w1ys
CFYLFcOiGjybLOwbRLisz8lVU4H7W6ydVmN89I4d+8ca/ba0YkPnHJMQ7kXPYZnM
XXRYhTpL9t1hTSPGc51A4+Pm+375wslMyjUPLka6MsotEXIaYW8xTT/Tzq0M4xHG
7iB5qffqbu+p57sf2YI7EbQkqm2NDGdRj2dVCJ7jISGTz/2knajrVHwwC0QV8h1/
iZbhLn5zEnJVmZovZIq6VddCskbDwHxvYDsKkYytyZX21bo3d3wXkg2Dva2c52v1
z8zAY22+kXVfytr7Tb3Sez9A6XnaIVEd++nWHeFJCSSd106R8u3IZo/psqDHgEMc
KlYneKWjGCZxLM5fPoYqNHtWMblYdRKrKvrgftr56NttTB15jEAB3HJ9NlIbZbAn
BopYMvAfr4PpOda2iy8+QsKKEHkeiowkah4QB0kCUiNDnPI+tyg8sKATm4r+u6oS
AL+NxzKD3Q==
=74mf
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmO8kbIACgkQmmx57+YA
GNmxow/+NzksoLlz2LFKlFHAJQGdCpAuuW5YXSRUt9We5qlkx+HMUm912KxObzHA
8m/9d9Sshv8p9dc8YaVWxsPaH3Bq9dcSJIgAEBYyNePkfC9D44KMYzPqvhk12/Tt
IJKkABwyTYDtBZaaqOYmaORqgywEC24lDJ0McQGX/cEWZXnbg/9dgmRkyr8oD9B+
iCr3N2egOD9BUQF3PHKTmrl4raVzu8R3nccwVBnSCpyu3mGpxZXcUje8Oj9hLqjR
RP5/W7auVuYfyOL6AZgVpZUxxfgU4xgFwbsU8Bh9sCKUZm81CqwTAOG9h2evSFTq
EGJfWpXEoGRSQIOC3VlZs6maMQ8xh3pgl21ee6El6t7t57/CwknOx/2Aty/DQT13
A6i32ud5wDzpD+tqVFIFCum5yWTolMzJ0wfhBhzjZABkRoY/OZ30IE8HXzulWeGX
HJ4yJdfqNMniQe4dhOn/e2k2VFFyfKY5LHvFkjVetnPAX7qAilzyt7B7NPkpvwp3
TqzvuCCJwdvp0aNY4SzvYFIRb2Co4ekmIHEH1XT8lmf83bHK8NiaoiYxj37CaIsY
UZ+lL7444UNkajXw1HqQZnLYQ/+AuzNNCtC5MY8ZkbYDt+/3nVMy/onND5I+/K3l
RDTEAJcbpacnnI2bMRaOcvVOjxOTJZp6b1vrs47sUFhs/3eoouw=
=Dy7f
-----END PGP SIGNATURE-----
Merge tag 'memory-controller-drv-fixes-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into arm/fixes
Memory controller drivers - fixes for v6.2
Broken in v6.2:
1. OMAP GPMC: do not fail if "gpmc,wait-pin" optional property
(introduced for v6.2) is missing.
Broken earlier:
1. Tegra MC: Drop SID override programming as it is handled by
bootloader and doing it in the kernel can cause unexpected results.
2. Atmel SDRAMC, MVEBU devbus: Add missing clock unprepare/disable in
exit and error paths.
* tag 'memory-controller-drv-fixes-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
memory: mvebu-devbus: Fix missing clk_disable_unprepare in mvebu_devbus_probe()
memory: atmel-sdramc: Fix missing clk_disable_unprepare in atmel_ramc_probe()
memory: tegra: Remove clients SID override programming
memory: omap-gpmc: fix wait pin validation
Link: https://lore.kernel.org/r/20230109150322.329614-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
.probe_new() doesn't get the i2c_device_id * parameter, so determine
that explicitly in the probe function.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20221118224540.619276-561-uwe@kleine-koenig.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Add the check for the return value of kzalloc in order to avoid
NULL pointer dereference.
Moreover, use the goto-label to share the clean code.
Fixes: d6b98c8d24 ("ice: add write functionality for GNSS TTY")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
The ice_gnss_tty_write() return directly if the write_buf alloc failed,
leaking the cmd_buf.
Fix by free cmd_buf if write_buf alloc failed.
Fixes: d6b98c8d24 ("ice: add write functionality for GNSS TTY")
Signed-off-by: Yuan Can <yuancan@huawei.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
If GFX11 microcode is required but not available during early init, the
firmware framebuffer will have already been released and the screen will
freeze.
Move the request for GFX11 microcode into the early_init phase
so that if it's not available, driver init will fail.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
The `amdgpu_ucode_release` helper will provide symmetery on unload.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Simplifies the code so that GFX10 will get the firmware
name from `amdgpu_ucode_ip_version_decode` and then use this filename
to load microcode as part of the early_init process.
Any failures will cause the driver to fail to probe before the firmware
framebuffer has been removed.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
The `amdgpu_ucode_release` helper is for symmetry on unload.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If GFX9 microcode is required but not available during early init, the
firmware framebuffer will have already been released and the screen will
freeze.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
The `amdgpu_ucode_release` helper will provide symmetry on unload.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
`amdgpu_mes_init` already sets `adev->mes.adev`, so there is no need
to also set it in the IP specific versions.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The `amdgpu_ucode_request` helper will ensure that the return code for
missing firmware is -ENODEV so that early_init can fail.
The `amdgpu_ucode_release` helper provides symmetry for releasing firmware.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add an early_init phase to MES for fetching and validating microcode
from the filesystem.
If MES microcode is required but not available during early init, the
firmware framebuffer will have already been released and the screen will
freeze.
Move the request for MES microcode into the early_init phase
so that if it's not available, early_init will fail.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
