This reverts commit ce1cca1738.
Bug: 184927119
Test: OTA works
Change-Id: I23d4da47ba620085ea12ec38a80c106fa24d756f
Signed-off-by: David Anderson <dvander@google.com>
This driver is not used and can cause problems if used on modern
devices. Remove it.
This reverts commit 6115619831.
Bug: 185178770
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: I1d5acb96dda765a1e3ea0cf62a3bf4b2a78892ea
CONFIG_KFENCE_NUM_OBJECTS controls the constant memory overhead that
KFENCE introduces for its memory pool. By default it is 255 objects
(2Mb extra memory), but since concerns have been raised that low-memory
devices may not afford that, we are lowering the number of objects
to 63 (512Kb extra memory).
So far we haven't seen Android devices allocate more than 50 KFENCE
objects. Should the kernel exhaust the pool, KFENCE will stop allocating
new objects and fall back to SLAB/SLUB until one of the objects is
freed.
An immediate consequence of reducing the pool size is that a freed
KFENCE object will be reused 4x times faster, effectively reducing the
probability of detecting a use-after-free. Since KFENCE is a best-effort
error detection tool, not a use-after-free mitigation mechanism, we
believe this should not be problematic.
Bug: 181822795
Test: run KFENCE on an Android device
Signed-off-by: Alexander Potapenko <glider@google.com>
Change-Id: I88fca80eea8b382115de03dbb104fd305b35476f
cfg80211_inform_bss expects to receive a TSF value, but is given the
time since boot in nanoseconds. TSF values are expected to be at
microsecond scale rather than nanosecond scale.
Bug: 181840234
Test: atest CtsWifiTestCases:android.net.wifi.cts.ScanResultTest#testScanResultTimeStamp -- --abi x86_64
Signed-off-by: A. Cody Schuffelen <schuffelen@google.com>
Link: https://lore.kernel.org/r/20210318200419.1421034-1-schuffelen@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit b57aa17f07
https: //git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git master)
Change-Id: Icafc24ad303357926cbe955ffa12e28e0bf31e6f
Export stack_trace_save_tsk and stack_trace_save_regs so that modules
can use it to get the stacktrace of specific tasks or pt_regs.
Bug: 184317765
Signed-off-by: Sangmoon Kim <sangmoon.kim@samsung.com>
Change-Id: Ice4ede172b5ef2f1cf311a28414db0d8bf929ced
To know whether CPU supports 32bit el0 or not at module, declare
system_32bit_el0_cpumask as EXPORT_SYMBOL_GPL.
Bug: 184233663
Signed-off-by: Park Bumgyu <bumgyu.park@samsung.com>
Change-Id: Ia329a5cf35c0f2a40b8088b0c1facad2532b5a0b
Commit 08d46858c7 ("FROMLIST: iommu: Add support for the map_pages()
callback") used the wrong format specifier for the count variable in
__iommu_map_pages(), and introduced the following compilation warning:
drivers/iommu/iommu.c: In function '__iommu_map_pages':
>> drivers/iommu/iommu.c:7:24: warning: format '%ld' expects argument of
>> type 'long int', but argument 6 has type 'size_t' {aka 'unsigned
>> int'} [-Wformat=]
7 | #define pr_fmt(fmt) "iommu: " fmt
| ^~~~~~~~~
include/linux/dynamic_debug.h:129:15: note: in expansion of macro
'pr_fmt'
129 | func(&id, ##__VA_ARGS__); \
| ^~~~~~~~~~~
include/linux/dynamic_debug.h:147:2: note: in expansion of macro
'__dynamic_func_call'
147 | __dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func,
| ^~~~~~~~~~~~~~~~~~~
include/linux/dynamic_debug.h:157:2: note: in expansion of macro
'_dynamic_func_call'
157 | _dynamic_func_call(fmt, __dynamic_pr_debug, \
| ^~~~~~~~~~~~~~~~~~
include/linux/printk.h:424:2: note: in expansion of macro
'dynamic_pr_debug'
424 | dynamic_pr_debug(fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~~~~~~
drivers/iommu/iommu.c:2398:2: note: in expansion of macro 'pr_debug'
2398 | pr_debug("mapping: iova 0x%lx pa %pa pgsize 0x%zx count
%ld\n",
| ^~~~~~~~
drivers/iommu/iommu.c:2398:60: note: format string is defined here
2398 | pr_debug("mapping: iova 0x%lx pa %pa pgsize 0x%zx count
%ld\n",
Fix by using the correct format specifier for the count variable.
Bug: 178537788
Fixes: 08d46858c7 ("FROMLIST: iommu: Add support for the map_pages() callback")
Reported-by: kernel test robot <lkp@intel.com>
Change-Id: Idc116f559c89e7da8a2b7ae5d8ce173923424588
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
arm_lpae_map_pages() is currently passing NULL to __arm_lpae_map()
for its mapped argument, instead of the mapped argument that it is
supposed to pass, which can lead to memory that has been mapped
not being counted as mapped.
Fix this by passing the mapped argument from arm_lpae_map_pages()
to __arm_lpae_map().
Bug: 178537788
Reported-by: John Stultz <john.stultz@linaro.org>
Fixes: ac3994447c ("FROMLIST: iommu/io-pgtable-arm: Implement arm_lpae_map_pages()")
Change-Id: Ic97df34fc2e9e0404d193eff2024d334e3e75a24
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Free vendor specific transfer ring through vendor hook
when the offload is enabled.
Bug: 175850224
Test: boot pass and headset works
Change-Id: I1ee112f41dae56bf6e0b8cc5575d8f4e893071f5
Signed-off-by: Howard Yen <howardyen@google.com>
Signed-off-by: Puma Hsu <pumahsu@google.com>
Changes in 5.10.29
ARM: dts: am33xx: add aliases for mmc interfaces
bus: ti-sysc: Fix warning on unbind if reset is not deasserted
platform/x86: intel-hid: Support Lenovo ThinkPad X1 Tablet Gen 2
bpf, x86: Use kvmalloc_array instead kmalloc_array in bpf_jit_comp
net/mlx5e: Enforce minimum value check for ICOSQ size
net: pxa168_eth: Fix a potential data race in pxa168_eth_remove
kunit: tool: Fix a python tuple typing error
mISDN: fix crash in fritzpci
mac80211: Check crypto_aead_encrypt for errors
mac80211: choose first enabled channel for monitor
drm/msm/dsi_pll_7nm: Fix variable usage for pll_lockdet_rate
drm/msm/adreno: a5xx_power: Don't apply A540 lm_setup to other GPUs
drm/msm: Ratelimit invalid-fence message
netfilter: conntrack: Fix gre tunneling over ipv6
netfilter: nftables: skip hook overlap logic if flowtable is stale
net: ipa: fix init header command validation
platform/x86: thinkpad_acpi: Allow the FnLock LED to change state
kselftest/arm64: sve: Do not use non-canonical FFR register value
drm/msm/disp/dpu1: icc path needs to be set before dpu runtime resume
x86/build: Turn off -fcf-protection for realmode targets
block: clear GD_NEED_PART_SCAN later in bdev_disk_changed
platform/x86: intel_pmc_core: Ignore GBE LTR on Tiger Lake platforms
ptp_qoriq: fix overflow in ptp_qoriq_adjfine() u64 calcalation
scsi: target: pscsi: Clean up after failure in pscsi_map_sg()
selftests/vm: fix out-of-tree build
ia64: mca: allocate early mca with GFP_ATOMIC
ia64: fix format strings for err_inject
cifs: revalidate mapping when we open files for SMB1 POSIX
cifs: Silently ignore unknown oplock break handle
io_uring: fix timeout cancel return code
math: Export mul_u64_u64_div_u64
tools/resolve_btfids: Build libbpf and libsubcmd in separate directories
tools/resolve_btfids: Check objects before removing
tools/resolve_btfids: Set srctree variable unconditionally
kbuild: Add resolve_btfids clean to root clean target
kbuild: Do not clean resolve_btfids if the output does not exist
tools/resolve_btfids: Add /libbpf to .gitignore
bpf, x86: Validate computation of branch displacements for x86-64
bpf, x86: Validate computation of branch displacements for x86-32
init/Kconfig: make COMPILE_TEST depend on !S390
init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM
Linux 5.10.29
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib3f9484150747de48eca46c69d690830b790418e
Currently, there is an application on Mac that it will send
ClearFeature(halt_ep) request before transfering USB data.
If the device receives the ClearFeature(halt_ep) request, the
started requests would be removed and restart the transfer.
However, userspace services don't know this behavior. The services
will free the requests instead of retry and resend the requests.
It will cause the USB host can't get response so that it will try
to recover by issuing a reset signal.
Finally, it will take the infinite loop.
send reqeust > reset > re-enumeration > send request > reset > ...
To avoid this symptom, this patch will keep the started requests
so that userspace services didn't free the requests.
Bug: 178904115
Bug: 177879761
Signed-off-by: Ray Chi <raychi@google.com>
Change-Id: I52acf48871fd7f86cfcc51fb41c67d21ea895d69
Signed-off-by: Saravana Kannan <saravanak@google.com>
commit 334ef6ed06 upstream.
While allmodconfig and allyesconfig build for s390 there are also
various bots running compile tests with randconfig, where PCI is
disabled. This reveals that a lot of drivers should actually depend on
HAS_IOMEM.
Adding this to each device driver would be a never ending story,
therefore just disable COMPILE_TEST for s390.
The reasoning is more or less the same as described in
commit bc083a64b6 ("init/Kconfig: make COMPILE_TEST depend on !UML").
Reported-by: kernel test robot <lkp@intel.com>
Suggested-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 26f55a59dc upstream.
The branch displacement logic in the BPF JIT compilers for x86 assumes
that, for any generated branch instruction, the distance cannot
increase between optimization passes.
But this assumption can be violated due to how the distances are
computed. Specifically, whenever a backward branch is processed in
do_jit(), the distance is computed by subtracting the positions in the
machine code from different optimization passes. This is because part
of addrs[] is already updated for the current optimization pass, before
the branch instruction is visited.
And so the optimizer can expand blocks of machine code in some cases.
This can confuse the optimizer logic, where it assumes that a fixed
point has been reached for all machine code blocks once the total
program size stops changing. And then the JIT compiler can output
abnormal machine code containing incorrect branch displacements.
To mitigate this issue, we assert that a fixed point is reached while
populating the output image. This rejects any problematic programs.
The issue affects both x86-32 and x86-64. We mitigate separately to
ease backporting.
Signed-off-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e4d4d45643 upstream.
The branch displacement logic in the BPF JIT compilers for x86 assumes
that, for any generated branch instruction, the distance cannot
increase between optimization passes.
But this assumption can be violated due to how the distances are
computed. Specifically, whenever a backward branch is processed in
do_jit(), the distance is computed by subtracting the positions in the
machine code from different optimization passes. This is because part
of addrs[] is already updated for the current optimization pass, before
the branch instruction is visited.
And so the optimizer can expand blocks of machine code in some cases.
This can confuse the optimizer logic, where it assumes that a fixed
point has been reached for all machine code blocks once the total
program size stops changing. And then the JIT compiler can output
abnormal machine code containing incorrect branch displacements.
To mitigate this issue, we assert that a fixed point is reached while
populating the output image. This rejects any problematic programs.
The issue affects both x86-32 and x86-64. We mitigate separately to
ease backporting.
Signed-off-by: Piotr Krysiuk <piotras@gmail.com>
Reviewed-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 0e1aa629f1 ]
Nathan reported issue with cleaning empty build directory:
$ make -s O=build distclean
../../scripts/Makefile.include:4: *** \
O=/ho...build/tools/bpf/resolve_btfids does not exist. Stop.
The problem that tools scripts require existing output
directory, otherwise it fails.
Adding check around the resolve_btfids clean target to
ensure the output directory is in place.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/bpf/20210211124004.1144344-1-jolsa@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7962cb9b64 ]
We want this clean to be called from tree's root Makefile,
which defines same srctree variable and that will screw
the make setup.
We actually do not use srctree being passed from outside,
so we can solve this by setting current srctree value
directly.
Also changing the way how srctree is initialized as suggested
by Andrri.
Also root Makefile does not define the implicit RM variable,
so adding RM initialization.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210205124020.683286-4-jolsa@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 219481a8f9 ]
Make SMB2 not print out an error when an oplock break is received for an
unknown handle, similar to SMB1. The debug message which is printed for
these unknown handles may also be misleading, so fix that too.
The SMB2 lease break path is not affected by this patch.
Without this, a program which writes to a file from one thread, and
opens, reads, and writes the same file from another thread triggers the
below errors several times a minute when run against a Samba server
configured with "smb2 leases = no".
CIFS: VFS: \\192.168.0.1 No task to wake, unknown frame received! NumMids 2
00000000: 424d53fe 00000040 00000000 00000012 .SMB@...........
00000010: 00000001 00000000 ffffffff ffffffff ................
00000020: 00000000 00000000 00000000 00000000 ................
00000030: 00000000 00000000 00000000 00000000 ................
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Reviewed-by: Tom Talpey <tom@talpey.com>
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit cee8f4f6fc ]
RHBZ: 1933527
Under SMB1 + POSIX, if an inode is reused on a server after we have read and
cached a part of a file, when we then open the new file with the
re-cycled inode there is a chance that we may serve the old data out of cache
to the application.
This only happens for SMB1 (deprecated) and when posix are used.
The simplest solution to avoid this race is to force a revalidate
on smb1-posix open.
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f2a419cf49 ]
The sleep warning happens at early boot right at secondary CPU
activation bootup:
smp: Bringing up secondary CPUs ...
BUG: sleeping function called from invalid context at mm/page_alloc.c:4942
in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.12.0-rc2-00007-g79e228d0b611-dirty #99
..
Call Trace:
show_stack+0x90/0xc0
dump_stack+0x150/0x1c0
___might_sleep+0x1c0/0x2a0
__might_sleep+0xa0/0x160
__alloc_pages_nodemask+0x1a0/0x600
alloc_page_interleave+0x30/0x1c0
alloc_pages_current+0x2c0/0x340
__get_free_pages+0x30/0xa0
ia64_mca_cpu_init+0x2d0/0x3a0
cpu_init+0x8b0/0x1440
start_secondary+0x60/0x700
start_ap+0x750/0x780
Fixed BSP b0 value from CPU 1
As I understand interrupts are not enabled yet and system has a lot of
memory. There is little chance to sleep and switch to GFP_ATOMIC should
be a no-op.
Link: https://lkml.kernel.org/r/20210315085045.204414-1-slyfox@gentoo.org
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f51d7bf1db ]
Current calculation for diff of TMR_ADD register value may have
64-bit overflow in this code line, when long type scaled_ppm is
large.
adj *= scaled_ppm;
This patch is to resolve it by using mul_u64_u64_div_u64().
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d1635448f1 ]
Due to a HW limitation, the Latency Tolerance Reporting (LTR) value
programmed in the Tiger Lake GBE controller is not large enough to allow
the platform to enter Package C10, which in turn prevents the platform from
achieving its low power target during suspend-to-idle. Ignore the GBE LTR
value on Tiger Lake. LTR ignore functionality is currently performed solely
by a debugfs write call. Split out the LTR code into its own function that
can be called by both the debugfs writer and by this work around.
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Reviewed-by: Sasha Neftin <sasha.neftin@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Reviewed-by: Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Link: https://lore.kernel.org/r/20210319201844.3305399-2-david.e.box@linux.intel.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5116784039 ]
The GD_NEED_PART_SCAN is set by bdev_check_media_change to initiate
a partition scan while removing a block device. It should be cleared
after blk_drop_paritions because blk_drop_paritions could return
-EBUSY and then the consequence __blkdev_get has no chance to do
delete_partition if GD_NEED_PART_SCAN already cleared.
It causes some problems on some card readers. Ex. Realtek card
reader 0bda:0328 and 0bda:0158. The device node of the partition
will not disappear after the memory card removed. Thus the user
applications can not update the device mapping correctly.
BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1920874
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210323085219.24428-1-chris.chiu@canonical.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9fcb51c14d ]
The new Ubuntu GCC packages turn on -fcf-protection globally,
which causes a build failure in the x86 realmode code:
cc1: error: ‘-fcf-protection’ is not compatible with this target
Turn it off explicitly on compilers that understand this option.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210323124846.1584944-1-arnd@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 627dc55c27 ]
DPU runtime resume will request for a min vote on the AXI bus as
it is a necessary step before turning ON the AXI clock.
The change does below
1) Move the icc path set before requesting runtime get_sync.
2) remove the dependency of hw catalog for min ib vote
as it is initialized at a later point.
Signed-off-by: Kalyan Thota <kalyan_t@codeaurora.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7011d72588 ]
The "First Fault Register" (FFR) is an SVE register that mimics a
predicate register, but clears bits when a load or store fails to handle
an element of a vector. The supposed usage scenario is to initialise
this register (using SETFFR), then *read* it later on to learn about
elements that failed to load or store. Explicit writes to this register
using the WRFFR instruction are only supposed to *restore* values
previously read from the register (for context-switching only).
As the manual describes, this register holds only certain values, it:
"... contains a monotonic predicate value, in which starting from bit 0
there are zero or more 1 bits, followed only by 0 bits in any remaining
bit positions."
Any other value is UNPREDICTABLE and is not supposed to be "restored"
into the register.
The SVE test currently tries to write a signature pattern into the
register, which is *not* a canonical FFR value. Apparently the existing
setups treat UNPREDICTABLE as "read-as-written", but a new
implementation actually only stores canonical values. As a consequence,
the sve-test fails immediately when comparing the FFR value:
-----------
# ./sve-test
Vector length: 128 bits
PID: 207
Mismatch: PID=207, iteration=0, reg=48
Expected [cf00]
Got [0f00]
Aborted
-----------
Fix this by only populating the FFR with proper canonical values.
Effectively the requirement described above limits us to 17 unique
values over 16 bits worth of FFR, so we condense our signature down to 4
bits (2 bits from the PID, 2 bits from the generation) and generate the
canonical pattern from it. Any bits describing elements above the
minimum 128 bit are set to 0.
This aligns the FFR usage to the architecture and fixes the test on
microarchitectures implementing FFR in a more restricted way.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviwed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210319120128.29452-1-andre.przywara@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3d677f12ea ]
On many recent ThinkPad laptops, there's a new LED next to the ESC key,
that indicates the FnLock status.
When the Fn+ESC combo is pressed, FnLock is toggled, which causes the
Media Key functionality to change, making it so that the media keys
either perform their media key function, or function as an F-key by
default. The Fn key can be used the access the alternate function at any
time.
With the current linux kernel, the LED doens't change state if you press
the Fn+ESC key combo. However, the media key functionality *does*
change. This is annoying, since the LED will stay on if it was on during
bootup, and it makes it hard to keep track what the current state of the
FnLock is.
This patch calls an ACPI function, that gets the current media key
state, when the Fn+ESC key combo is pressed. Through testing it was
discovered that this function causes the LED to update correctly to
reflect the current state when this function is called.
The relevant ACPI calls are the following:
\_SB_.PCI0.LPC0.EC0_.HKEY.GMKS: Get media key state, returns 0x603 if the FnLock mode is enabled, and 0x602 if it's disabled.
\_SB_.PCI0.LPC0.EC0_.HKEY.SMKS: Set media key state, sending a 1 will enable FnLock mode, and a 0 will disable it.
Relevant discussion:
https://bugzilla.kernel.org/show_bug.cgi?id=207841https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1881015
Signed-off-by: Esteve Varela Colominas <esteve.varela@gmail.com>
Link: https://lore.kernel.org/r/20210315195823.23212-1-esteve.varela@gmail.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b4afd4b90a ]
We use ipa_cmd_header_valid() to ensure certain values we will
program into hardware are within range, well in advance of when we
actually program them. This way we avoid having to check for errors
when we actually program the hardware.
Unfortunately the dev_err() call for a bad offset value does not
supply the arguments to match the format specifiers properly.
Fix this.
There was also supposed to be a check to ensure the size to be
programmed fits in the field that holds it. Add this missing check.
Rearrange the way we ensure the header table fits in overall IPA
memory range.
Finally, update ipa_cmd_table_valid() so the format of messages
printed for errors matches what's done in ipa_cmd_header_valid().
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 86fe2c19ee ]
If the flowtable has been previously removed in this batch, skip the
hook overlap checks. This fixes spurious EEXIST errors when removing and
adding the flowtable in the same batch.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7ad48d27a2 ]
We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause. Lets ratelimit the dmesg spam so that next time it happens we
don't lose the kernel traces leading up to this.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4a9d36b061 ]
While passing the A530-specific lm_setup func to A530 and A540
to !A530 was fine back when only these two were supported, it
certainly is not a good idea to send A540 specifics to smaller
GPUs like A508 and friends.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9daaf31307 ]
The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value
directly, but the same value was also being specified in the
dsi_pll_regs struct pll_lockdet_rate variable: let's use it!
Based on 362cadf34b ("drm/msm/dsi_pll_10nm: Fix variable usage for
pll_lockdet_rate")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7421b1a4d1 ]
The first argument to namedtuple() should match the name of the type,
which wasn't the case for KconfigEntryBase.
Fixing this is enough to make mypy show no python typing errors again.
Fixes 97752c39bd ("kunit: kunit_tool: Allow .kunitconfig to disable config items")
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Daniel Latypov <dlatypov@google.com>
Acked-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
