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>
[ Upstream commit 0571a753cb ]
pxa168_eth_remove() firstly calls unregister_netdev(),
then cancels a timeout work. unregister_netdev() shuts down a device
interface and removes it from the kernel tables. If the timeout occurs
in parallel, the timeout work (pxa168_eth_tx_timeout_task) performs stop
and open of the device. It may lead to an inconsistent state and memory
leaks.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Pavel Andrianov <andrianov@ispras.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a7b5d7c496 ]
We currently get thefollowing on driver unbind if a reset is configured
and asserted:
WARNING: CPU: 0 PID: 993 at drivers/reset/core.c:432 reset_control_assert
...
(reset_control_assert) from [<c0fecda8>] (sysc_remove+0x190/0x1e4)
(sysc_remove) from [<c0a2bb58>] (platform_remove+0x24/0x3c)
(platform_remove) from [<c0a292fc>] (__device_release_driver+0x154/0x214)
(__device_release_driver) from [<c0a2a210>] (device_driver_detach+0x3c/0x8c)
(device_driver_detach) from [<c0a27d64>] (unbind_store+0x60/0xd4)
(unbind_store) from [<c0546bec>] (kernfs_fop_write_iter+0x10c/0x1cc)
Let's fix it by checking the reset status.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9bbce32a20 ]
Without DT aliases, the numbering of mmc interfaces is unpredictable.
Adding them makes it possible to refer to devices consistently. The
popular suggestion to use UUIDs obviously doesn't work with a blank
device fresh from the factory.
See commit fa2d0aa969 ("mmc: core: Allow setting slot index via
device tree alias") for more discussion.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
tcpm_pd_select_pps_apdo overwrites port->pps_data.min_volt,
port->pps_data.max_volt, port->pps_data.max_curr even before
port partner accepts the requests. This leaves incorrect values
in current_limit and supply_voltage that get exported by
"tcpm-source-psy-". Solving this problem by caching the request
values in req_min_volt, req_max_volt, req_max_curr, req_out_volt,
req_op_curr. min_volt, max_volt, max_curr gets updated once the
partner accepts the request. current_limit, supply_voltage gets updated
once local port's tcpm enters SNK_TRANSITION_SINK when the accepted
current_limit and supply_voltage is enforced.
Fixes: f2a8aa053c ("typec: tcpm: Represent source supply through power_supply")
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Cc: stable <stable@vger.kernel.org>
Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20210407200723.1914388-2-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e3a0720224https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9e6d899cec1c8e3c62d68bd0e2ba90c662a2403c
Update KMI with most 4/9 changes (one more coming)
Leaf changes summary: 576 artifacts changed
Changed leaf types summary: 9 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 554 Changed, 7 Added functions
Removed/Changed/Added variables summary: 0 Removed, 4 Changed, 2 Added variables
7 Added functions:
[A] 'function ieee802154_hw* ieee802154_alloc_hw(size_t, const ieee802154_ops*)'
[A] 'function void ieee802154_free_hw(ieee802154_hw*)'
[A] 'function int ieee802154_register_hw(ieee802154_hw*)'
[A] 'function void ieee802154_rx_irqsafe(ieee802154_hw*, sk_buff*, u8)'
[A] 'function void ieee802154_unregister_hw(ieee802154_hw*)'
[A] 'function void ieee802154_wake_queue(ieee802154_hw*)'
[A] 'function void ieee802154_xmit_complete(ieee802154_hw*, sk_buff*, bool)'
554 functions with some sub-type change:
[C] 'function int ___pskb_trim(sk_buff*, unsigned int)' at skbuff.c:1928:1 has some sub-type changes:
CRC (modversions) changed from 0x750d7278 to 0x81d5292f
[C] 'function sk_buff* __alloc_skb(unsigned int, gfp_t, int, int)' at skbuff.c:182:1 has some sub-type changes:
CRC (modversions) changed from 0x35ad9f50 to 0xc662eb3c
[C] 'function sk_buff* __cfg80211_alloc_event_skb(wiphy*, wireless_dev*, nl80211_commands, nl80211_attrs, unsigned int, int, int, gfp_t)' at nl80211.c:10274:1 has some sub-type changes:
CRC (modversions) changed from 0x8515ad95 to 0x55be0cb8
... 551 omitted; 554 symbols have only CRC changes
2 Added variables:
[A] 'tracepoint __tracepoint_android_rvh_cpu_cgroup_online'
[A] 'tracepoint __tracepoint_android_rvh_replace_next_task_fair'
4 Changed variables:
[C] 'net init_net' was changed at net_namespace.c:47:1:
CRC (modversions) changed from 0xae43d102 to 0x75836cf9
[C] 'pid_namespace init_pid_ns' was changed at pid.c:75:1:
CRC (modversions) changed from 0xbf931239 to 0x30fc5784
[C] 'const dev_pm_ops snd_soc_pm_ops' was changed at soc-core.c:2028:1:
CRC (modversions) changed from 0x785e2782 to 0xab291a76
... 1 omitted; 4 symbols have only CRC changes
'struct bpf_prog_aux at bpf.h:757:1' changed:
type size changed from 5120 to 5056 (in bits)
1 data member deletion:
'bpf_tramp_prog_type trampoline_prog_type', at offset 1024 (in bits) at bpf.h:783:1
there are data member changes:
29 ('hlist_node tramp_hlist' .. 'bpf_prog_stats* stats') offsets changed (by -64 bits)
while looking at anonymous data member 'union {work_struct work; callback_head rcu;}':
the internal name of that anonymous data member changed from:
__anonymous_union__27
to:
__anonymous_union__28
This is usually due to an anonymous member type being added or removed from the containing type
and offset changed from 4864 to 4800 (in bits) (by -64 bits)
2740 impacted interfaces
'struct bpf_trampoline at bpf.h:586:1' changed:
type size changed from 3008 to 1280 (in bits)
1 data member deletion:
'bpf_ksym ksym', at offset 1280 (in bits) at bpf.h:610:1
there are data member changes:
type 'void*' of 'bpf_trampoline::image' changed:
pointer type changed from: 'void*' to: 'bpf_tramp_image*'
and name of 'bpf_trampoline::image' changed to 'bpf_trampoline::cur_image' at bpf.h:624:1
2740 impacted interfaces
'struct io_pgtable_ops at io-pgtable.h:150:1' changed:
type size changed from 256 to 384 (in bits)
2 data member insertions:
'int (io_pgtable_ops*, unsigned long int, typedef phys_addr_t, typedef size_t, typedef size_t, int, typedef gfp_t, size_t*)* map_pages', at offset 64 (in bits) at io-pgtable.h:155:1
'typedef size_t (io_pgtable_ops*, unsigned long int, typedef size_t, typedef size_t, iommu_iotlb_gather*)* unmap_pages', at offset 256 (in bits) at io-pgtable.h:163:1
there are data member changes:
2 ('int (io_pgtable_ops*, unsigned long int, scatterlist*, unsigned int, int, typedef gfp_t, size_t*)* map_sg' .. 'typedef size_t (io_pgtable_ops*, unsigned long int, typedef size_t, iommu_iotlb_gather*)* unmap') offsets changed (by +64 bits)
'typedef phys_addr_t (io_pgtable_ops*, unsigned long int)* iova_to_phys' offset changed (by +128 bits)
2 impacted interfaces
'struct iommu_ops at iommu.h:248:1' changed:
type size changed from 2688 to 2816 (in bits)
2 data member insertions:
'int (iommu_domain*, unsigned long int, typedef phys_addr_t, typedef size_t, typedef size_t, int, typedef gfp_t, size_t*)* map_pages', at offset 384 (in bits) at iommu.h:262:1
'typedef size_t (iommu_domain*, unsigned long int, typedef size_t, typedef size_t, iommu_iotlb_gather*)* unmap_pages', at offset 576 (in bits) at iommu.h:270:1
there are data member changes:
2 ('int (iommu_domain*, unsigned long int, scatterlist*, unsigned int, int, typedef gfp_t, size_t*)* map_sg' .. 'typedef size_t (iommu_domain*, unsigned long int, typedef size_t, iommu_iotlb_gather*)* unmap') offsets changed (by +64 bits)
34 ('void (iommu_domain*)* flush_iotlb_all' .. 'module* owner') offsets changed (by +128 bits)
2740 impacted interfaces
'struct net_device at netdevice.h:1891:1' changed:
type size hasn't changed
2 data member insertions:
'netdev_ml_priv_type ml_priv_type', at offset 9792 (in bits) at netdevice.h:2151:1
'union {pcpu_lstats* lstats; pcpu_sw_netstats* tstats; pcpu_dstats* dstats;}', at offset 9856 (in bits) at netdevice.h:2153:1
there are data member changes:
anonymous data member union {void* ml_priv; pcpu_lstats* lstats; pcpu_sw_netstats* tstats; pcpu_dstats* dstats;} at offset 9728 (in bits) became data member 'void* ml_priv'
26 ('device dev' .. 'u64 android_kabi_reserved8') offsets changed (by +128 bits)
2740 impacted interfaces
'struct phy_device at phy.h:539:1' changed:
type size changed from 11008 to 11072 (in bits)
1 data member insertion:
'int port', at offset 8416 (in bits) at phy.h:581:1
there are data member changes:
5 ('int pause' .. 'u8 master_slave_state') offsets changed (by +32 bits)
22 ('unsigned long int supported[2]' .. 'void (net_device*)* adjust_link') offsets changed (by +64 bits)
2740 impacted interfaces
'struct rtnl_link_ops at rtnetlink.h:59:1' changed:
type size hasn't changed
1 data member insertion:
'bool netns_refund', at offset 320 (in bits) at rtnetlink.h:68:1
there are data member changes:
'unsigned int maxtype' offset changed (by +32 bits)
2740 impacted interfaces
'struct ufs_hba at ufshcd.h:708:1' changed:
type size changed from 32448 to 33344 (in bits)
1 data member insertion:
'dentry* debugfs_root', at offset 33280 (in bits) at ufshcd.h:837:1
there are data member changes:
type 'struct ufs_stats' of 'ufs_hba::ufs_stats' changed:
type size changed from 11072 to 11904 (in bits)
12 data member deletions:
'ufs_err_reg_hist dl_err', at offset 1088 (in bits) at ufshcd.h:450:1
'ufs_err_reg_hist nl_err', at offset 1920 (in bits) at ufshcd.h:451:1
'ufs_err_reg_hist tl_err', at offset 2752 (in bits) at ufshcd.h:452:1
'ufs_err_reg_hist dme_err', at offset 3584 (in bits) at ufshcd.h:453:1
'ufs_err_reg_hist auto_hibern8_err', at offset 4416 (in bits) at ufshcd.h:456:1
'ufs_err_reg_hist fatal_err', at offset 5248 (in bits) at ufshcd.h:457:1
'ufs_err_reg_hist link_startup_err', at offset 6080 (in bits) at ufshcd.h:458:1
'ufs_err_reg_hist resume_err', at offset 6912 (in bits) at ufshcd.h:459:1
'ufs_err_reg_hist suspend_err', at offset 7744 (in bits) at ufshcd.h:460:1
'ufs_err_reg_hist dev_reset', at offset 8576 (in bits) at ufshcd.h:463:1
'ufs_err_reg_hist host_reset', at offset 9408 (in bits) at ufshcd.h:464:1
'ufs_err_reg_hist task_abort', at offset 10240 (in bits) at ufshcd.h:465:1
there are data member changes:
type 'struct ufs_err_reg_hist' of 'ufs_stats::pa_err' changed:
entity changed from 'struct ufs_err_reg_hist' to 'ufs_event_hist[13]'
type size changed from 832 to 11648 (in bits)
and name of 'ufs_stats::pa_err' changed to 'ufs_stats::event' at ufshcd.h:459:1
16 impacted interfaces
33 ('bool force_reset' .. 'blk_keyslot_manager ksm') offsets changed (by +832 bits)
16 impacted interfaces
'struct ufs_stats at ufshcd.h:441:1' changed:
details were reported earlier
Bug: 184983567
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I9e1533bae92343335000a50b79a2acae02cc9c3e
