Changes in 4.19.122
vhost: vsock: kick send_pkt worker once device is started
powerpc/pci/of: Parse unassigned resources
ASoC: topology: Check return value of pcm_new_ver
selftests/ipc: Fix test failure seen after initial test run
ASoC: sgtl5000: Fix VAG power-on handling
usb: dwc3: gadget: Properly set maxpacket limit
ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode
ASoC: rsnd: Fix HDMI channel mapping for multi-SSI mode
ASoC: codecs: hdac_hdmi: Fix incorrect use of list_for_each_entry
drm/amdgpu: Correctly initialize thermal controller for GPUs with Powerplay table v0 (e.g Hawaii)
wimax/i2400m: Fix potential urb refcnt leak
net: stmmac: fix enabling socfpga's ptp_ref_clock
net: stmmac: Fix sub-second increment
ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent
ASoC: rsnd: Fix "status check failed" spam for multi-SSI
cifs: protect updating server->dstaddr with a spinlock
s390/ftrace: fix potential crashes when switching tracers
scripts/config: allow colons in option strings for sed
lib/mpi: Fix building for powerpc with clang
net: bcmgenet: suppress warnings on failed Rx SKB allocations
net: systemport: suppress warnings on failed Rx SKB allocations
sctp: Fix SHUTDOWN CTSN Ack in the peer restart case
drm/amdgpu: Fix oops when pp_funcs is unset in ACPI event
lib: devres: add a helper function for ioremap_uc
mfd: intel-lpss: Use devm_ioremap_uc for MMIO
hexagon: clean up ioremap
hexagon: define ioremap_uc
ALSA: hda: Match both PCI ID and SSID for driver blacklist
platform/x86: GPD pocket fan: Fix error message when temp-limits are out of range
mac80211: add ieee80211_is_any_nullfunc()
cgroup, netclassid: remove double cond_resched
drm/atomic: Take the atomic toys away from X
Linux 4.19.122
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I7257fc5afa0c25d3ba2f6884822ec315d556426a
commit 30b2f0be23 upstream.
commit 08a5bdde38 ("mac80211: consider QoS Null frames for STA_NULLFUNC_ACKED")
Fixed a bug where we failed to take into account a
nullfunc frame can be either non-QoS or QoS. It turns out
there is at least one more bug in
ieee80211_sta_tx_notify(), introduced in
commit 7b6ddeaf27 ("mac80211: use QoS NDP for AP probing"),
where we forgot to check for the QoS variant and so
assumed the QoS nullfunc frame never went out
Fix this by adding a helper ieee80211_is_any_nullfunc()
which consolidates the check for non-QoS and QoS nullfunc
frames. Replace existing compound conditionals and add a
couple more missing checks for QoS variant.
Signed-off-by: Thomas Pedersen <thomas@adapt-ip.com>
Link: https://lore.kernel.org/r/20200114055940.18502-3-thomas@adapt-ip.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1d6f8c5bac upstream.
Commit 1f27dbd826 ("platform/x86: GPD pocket fan: Allow somewhat
lower/higher temperature limits") changed the module-param sanity check
to accept temperature limits between 20 and 90 degrees celcius.
But the error message printed when the module params are outside this
range was not updated. This commit updates the error message to match
the new min and max value for the temp-limits.
Reported-by: Pavel Machek <pavel@denx.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pavel Machek <pavel@denx.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 977dfef40c upstream.
The commit 3c6fd1f07e ("ALSA: hda: Add driver blacklist") added a
new blacklist for the devices that are known to have empty codecs, and
one of the entries was ASUS ROG Zenith II (PCI SSID 1043:874f).
However, it turned out that the very same PCI SSID is used for the
previous model that does have the valid HD-audio codecs and the change
broke the sound on it.
Since the empty codec problem appear on the certain AMD platform (PCI
ID 1022:1487), this patch changes the blacklist matching to both PCI
ID and SSID using pci_match_id(). Also, the entry that was removed by
the previous fix for ASUS ROG Zenigh II is re-added.
Link: https://lore.kernel.org/r/20200424061222.19792-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ac32292c85 upstream.
Use ioremap as the main implemented function, and defined
ioremap_nocache to it as a deprecated alias.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a8ff78f7f7 upstream.
Some BIOS erroneously specifies write-combining BAR for intel-lpss-pci
in MTRR. This will cause the system to hang during boot. If possible,
this bug could be corrected with a firmware update.
This patch use devm_ioremap_uc to overwrite/ignore the MTRR settings
by forcing the use of strongly uncachable pages for intel-lpss.
The BIOS bug is present on Dell XPS 13 7390 2-in-1:
[ 0.001734] 5 base 4000000000 mask 6000000000 write-combining
4000000000-7fffffffff : PCI Bus 0000:00
4000000000-400fffffff : 0000:00:02.0 (i915)
4010000000-4010000fff : 0000:00:15.0 (intel-lpss-pci)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203485
Cc: <stable@vger.kernel.org> # v4.19+
Tested-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Tuowen Zhao <ztuowen@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Roman Gilg <subdiff@gmail.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5932d260a8 upstream.
On ARCTURUS and RENOIR, powerplay is not supported yet.
When plug in or unplug power jack, ACPI event will issue.
Then kernel NULL pointer BUG will be triggered.
Check for NULL pointers before calling.
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 12dfd78e3a upstream.
When starting shutdown in sctp_sf_do_dupcook_a(), get the value for
SHUTDOWN Cumulative TSN Ack from the new association, which is
reconstructed from the cookie, instead of the old association, which
the peer doesn't have anymore.
Otherwise the SHUTDOWN is either ignored or replied to with an ABORT
by the peer because CTSN Ack doesn't match the peer's Initial TSN.
Fixes: bdf6fa52f0 ("sctp: handle association restarts when the socket is closed.")
Signed-off-by: Jere Leppänen <jere.leppanen@nokia.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 3554e54a46 ]
The driver is designed to drop Rx packets and reclaim the buffers
when an allocation fails, and the network interface needs to safely
handle this packet loss. Therefore, an allocation failure of Rx
SKBs is relatively benign.
However, the output of the warning message occurs with a high
scheduling priority that can cause excessive jitter/latency for
other high priority processing.
This commit suppresses the warning messages to prevent scheduling
problems while retaining the failure count in the statistics of
the network interface.
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ecaeceb8a8 ]
The driver is designed to drop Rx packets and reclaim the buffers
when an allocation fails, and the network interface needs to safely
handle this packet loss. Therefore, an allocation failure of Rx
SKBs is relatively benign.
However, the output of the warning message occurs with a high
scheduling priority that can cause excessive jitter/latency for
other high priority processing.
This commit suppresses the warning messages to prevent scheduling
problems while retaining the failure count in the statistics of
the network interface.
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e461bc9f9a ]
Sed broke on some strings as it used colon as a separator.
I made it more robust by using \001, which is legit POSIX AFAIK.
E.g. ./config --set-str CONFIG_USBNET_DEVADDR "de:ad:be:ef:00:01"
failed with: sed: -e expression #1, char 55: unknown option to `s'
Signed-off-by: Jeremie Francois (on alpha) <jeremie.francois@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8ebf6da9db ]
Switching tracers include instruction patching. To prevent that a
instruction is patched while it's read the instruction patching is done
in stop_machine 'context'. This also means that any function called
during stop_machine must not be traced. Thus add 'notrace' to all
functions called within stop_machine.
Fixes: 1ec2772e0c ("s390/diag: add a statistic for diagnose calls")
Fixes: 38f2c691a4 ("s390: improve wait logic of stop_machine")
Fixes: 4ecf0a43e7 ("processor: get rid of cpu_relax_yield")
Signed-off-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit fada37f6f6 ]
We use a spinlock while we are reading and accessing the destination address for a server.
We need to also use this spinlock to protect when we are modifying this address from
reconn_set_ipaddr().
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 54cb622168 ]
Fix the rsnd_ssi_stop function to skip disabling the individual SSIs of
a multi-SSI setup, as the actual stop is performed by rsnd_ssiu_stop_gen2
- the same logic as in rsnd_ssi_start. The attempt to disable these SSIs
was harmless, but caused a "status check failed" message to be printed
for every SSI in the multi-SSI setup.
The disabling of interrupts is still performed, as they are enabled for
all SSIs in rsnd_ssi_init, but care is taken to not accidentally set the
EN bit for an SSI where it was not set by rsnd_ssi_start.
Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200417153017.1744454-3-matthias.blankertz@cetitec.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0c258657dd ]
The master SSI of a multi-SSI setup was attached both to the
RSND_MOD_SSI slot and the RSND_MOD_SSIP slot of the rsnd_dai_stream.
This is not correct wrt. the meaning of being "parent" in the rest of
the SSI code, where it seems to indicate an SSI that provides clock and
word sync but is not transmitting/receiving audio data.
Not treating the multi-SSI master as parent allows removal of various
special cases to the rsnd_ssi_is_parent conditions introduced in commit
a09fb3f28a ("ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode").
It also fixes the issue that operations performed via rsnd_dai_call()
were performed twice for the master SSI. This caused some "status check
failed" spam when stopping a multi-SSI stream as the driver attempted to
stop the master SSI twice.
Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200417153017.1744454-2-matthias.blankertz@cetitec.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 91a2559c1d ]
In fine adjustement mode, which is the current default, the sub-second
increment register is the number of nanoseconds that will be added to
the clock when the accumulator overflows. At each clock cycle, the
value of the addend register is added to the accumulator.
Currently, we use 20ns = 1e09ns / 50MHz as this value whatever the
frequency of the ptp clock actually is.
The adjustment is then done on the addend register, only incrementing
every X clock cycles X being the ratio between 50MHz and ptp_clock_rate
(addend = 2^32 * 50MHz/ptp_clock_rate).
This causes the following issues :
- In case the frequency of the ptp clock is inferior or equal to 50MHz,
the addend value calculation will overflow and the default
addend value will be set to 0, causing the clock to not work at
all. (For instance, for ptp_clock_rate = 50MHz, addend = 2^32).
- The resolution of the timestamping clock is limited to 20ns while it
is not needed, thus limiting the accuracy of the timestamping to
20ns.
Fix this by setting sub-second increment to 2e09ns / ptp_clock_rate.
It will allow to reach the minimum possible frequency for
ptp_clk_ref, which is 5MHz for GMII 1000Mps Full-Duplex by setting the
sub-second-increment to a higher value. For instance, for 25MHz, it
gives ssinc = 80ns and default_addend = 2^31.
It will also allow to use a lower value for sub-second-increment, thus
improving the timestamping accuracy with frequencies higher than
100MHz, for instance, for 200MHz, ssinc = 10ns and default_addend =
2^31.
v1->v2:
- Remove modifications to the calculation of default addend, which broke
compatibility with clock frequencies for which 2000000000 / ptp_clk_freq
is not an integer.
- Modify description according to discussions.
Signed-off-by: Julien Beraud <julien.beraud@orolia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 15ce30609d ]
There are 2 registers to write to enable a ptp ref clock coming from the
fpga.
One that enables the usage of the clock from the fpga for emac0 and emac1
as a ptp ref clock, and the other to allow signals from the fpga to reach
emac0 and emac1.
Currently, if the dwmac-socfpga has phymode set to PHY_INTERFACE_MODE_MII,
PHY_INTERFACE_MODE_GMII, or PHY_INTERFACE_MODE_SGMII, both registers will
be written and the ptp ref clock will be set as coming from the fpga.
Separate the 2 register writes to only enable signals from the fpga to
reach emac0 or emac1 when ptp ref clock is not coming from the fpga.
Signed-off-by: Julien Beraud <julien.beraud@orolia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7717cbec17 ]
i2400mu_bus_bm_wait_for_ack() invokes usb_get_urb(), which increases the
refcount of the "notif_urb".
When i2400mu_bus_bm_wait_for_ack() returns, local variable "notif_urb"
becomes invalid, so the refcount should be decreased to keep refcount
balanced.
The issue happens in all paths of i2400mu_bus_bm_wait_for_ack(), which
forget to decrease the refcnt increased by usb_get_urb(), causing a
refcnt leak.
Fix this issue by calling usb_put_urb() before the
i2400mu_bus_bm_wait_for_ack() returns.
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit bbc25dadc7 ]
Initialize thermal controller fields in the PowerPlay table for Hawaii
GPUs, so that fan speeds are reported.
Signed-off-by: Sandeep Raghuraman <sandy.8925@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b94e164759 ]
The HDMI?_SEL register maps up to four stereo SSI data lanes onto the
sdata[0..3] inputs of the HDMI output block. The upper half of the
register contains four blocks of 4 bits, with the most significant
controlling the sdata3 line and the least significant the sdata0 line.
The shift calculation has an off-by-one error, causing the parent SSI to
be mapped to sdata3, the first multi-SSI child to sdata0 and so forth.
As the parent SSI transmits the stereo L/R channels, and the HDMI core
expects it on the sdata0 line, this causes no audio to be output when
playing stereo audio on a multichannel capable HDMI out, and
multichannel audio has permutated channels.
Fix the shift calculation to map the parent SSI to sdata0, the first
child to sdata1 etc.
Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200415141017.384017-3-matthias.blankertz@cetitec.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d94ea53198 ]
Currently the calculation of max packet size limit for IN endpoints is
too restrictive. This prevents a matching of a capable hardware endpoint
during configuration. Below is the minimum recommended HW configuration
to support a particular endpoint setup from the databook:
For OUT endpoints, the databook recommended the minimum RxFIFO size to
be at least 3x MaxPacketSize + 3x setup packets size (8 bytes each) +
clock crossing margin (16 bytes).
For IN endpoints, the databook recommended the minimum TxFIFO size to be
at least 3x MaxPacketSize for endpoints that support burst. If the
endpoint doesn't support burst or when the device is operating in USB
2.0 mode, a minimum TxFIFO size of 2x MaxPacketSize is recommended.
Base on these recommendations, we can calculate the MaxPacketSize limit
of each endpoint. This patch revises the IN endpoint MaxPacketSize limit
and also sets the MaxPacketSize limit for OUT endpoints.
Reference: Databook 3.30a section 3.2.2 and 3.2.3
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit aa7812737f ]
As mentioned slightly out of patch context in the code, there
is no reset routine for the chip. On boards where the chip is
supplied by a fixed regulator, it might not even be resetted
during (e.g. watchdog) reboot and can be in any state.
If the device is probed with VAG enabled, the driver's probe
routine will generate a loud pop sound when ANA_POWER is
being programmed. Avoid this by properly disabling just the
VAG bit and waiting the required power down time.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Reviewed-by: Fabio Estevam <festivem@gmail.com>
Link: https://lore.kernel.org/r/20200414181140.145825-1-sebastian.reichel@collabora.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b87080eab4 ]
After successfully running the IPC msgque test once, subsequent runs
result in a test failure:
$ sudo ./run_kselftest.sh
TAP version 13
1..1
# selftests: ipc: msgque
# Failed to get stats for IPC queue with id 0
# Failed to dump queue: -22
# Bail out!
# # Pass 0 Fail 0 Xfail 0 Xpass 0 Skip 0 Error 0
not ok 1 selftests: ipc: msgque # exit=1
The dump_queue() function loops through the possible message queue index
values using calls to msgctl(kern_id, MSG_STAT, ...) where kern_id
represents the index value. The first time the test is ran, the initial
index value of 0 is valid and the test is able to complete. The index
value of 0 is not valid in subsequent test runs and the loop attempts to
try index values of 1, 2, 3, and so on until a valid index value is
found that corresponds to the message queue created earlier in the test.
The msgctl() syscall returns -1 and sets errno to EINVAL when invalid
index values are used. The test failure is caused by incorrectly
comparing errno to -EINVAL when cycling through possible index values.
Fix invalid test failures on subsequent runs of the msgque test by
correctly comparing errno values to a non-negated EINVAL.
Fixes: 3a665531a3 ("selftests: IPC message queue copy feature test")
Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit dead1c845d upstream.
The pseries platform uses the PCI_PROBE_DEVTREE method of PCI probing
which reads "assigned-addresses" of every PCI device and initializes
the device resources. However if the property is missing or zero sized,
then there is no fallback of any kind and the PCI resources remain
undiscovered, i.e. pdev->resource[] array remains empty.
This adds a fallback which parses the "reg" property in pretty much same
way except it marks resources as "unset" which later make Linux assign
those resources proper addresses.
This has an effect when:
1. a hypervisor failed to assign any resource for a device;
2. /chosen/linux,pci-probe-only=0 is in the DT so the system may try
assigning a resource.
Neither is likely to happen under PowerVM.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0b84103062 upstream.
Ning Bo reported an abnormal 2-second gap when booting Kata container [1].
The unconditional timeout was caused by VSOCK_DEFAULT_CONNECT_TIMEOUT of
connecting from the client side. The vhost vsock client tries to connect
an initializing virtio vsock server.
The abnormal flow looks like:
host-userspace vhost vsock guest vsock
============== =========== ============
connect() --------> vhost_transport_send_pkt_work() initializing
| vq->private_data==NULL
| will not be queued
V
schedule_timeout(2s)
vhost_vsock_start() <--------- device ready
set vq->private_data
wait for 2s and failed
connect() again vq->private_data!=NULL recv connecting pkt
Details:
1. Host userspace sends a connect pkt, at that time, guest vsock is under
initializing, hence the vhost_vsock_start has not been called. So
vq->private_data==NULL, and the pkt is not been queued to send to guest
2. Then it sleeps for 2s
3. After guest vsock finishes initializing, vq->private_data is set
4. When host userspace wakes up after 2s, send connecting pkt again,
everything is fine.
As suggested by Stefano Garzarella, this fixes it by additional kicking the
send_pkt worker in vhost_vsock_start once the virtio device is started. This
makes the pending pkt sent again.
After this patch, kata-runtime (with vsock enabled) boot time is reduced
from 3s to 1s on a ThunderX2 arm64 server.
[1] https://github.com/kata-containers/runtime/issues/1917
Reported-by: Ning Bo <n.b@live.com>
Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Jia He <justin.he@arm.com>
Link: https://lore.kernel.org/r/20200501043840.186557-1-justin.he@arm.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Commit dbad92f6e8 ("ANDROID: GKI: ASoC: msm: fix integer overflow for
long duration offload playback") causes a build warning if the kernel is
built for a 32bit target, like i386.
The warning is:
CC [M] sound/soc/intel/atom/sst/sst_drv_interface.o
In file included from kernel/include/linux/printk.h:337:0,
from kernel/include/linux/kernel.h:13,
from kernel/include/linux/delay.h:22,
from kernel/sound/soc/intel/atom/sst/sst_drv_interface.c:21:
kernel/sound/soc/intel/atom/sst/sst_drv_interface.c: In function 'sst_cdev_tstamp':
kernel/include/linux/dynamic_debug.h:75:16: warning: format '%d' expects argument of type 'int', but argument 5 has type '__u64' [-Wformat=]
static struct _ddebug __aligned(8) \
^
kernel/include/linux/dynamic_debug.h:111:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA_KEY'
DEFINE_DYNAMIC_DEBUG_METADATA_KEY(name, fmt, 0, 0)
^
kernel/include/linux/dynamic_debug.h:133:2: note: in expansion of macro 'DEFINE_DYNAMIC_DEBUG_METADATA'
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
kernel/include/linux/device.h:1544:2: note: in expansion of macro 'dynamic_dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
^
kernel/sound/soc/intel/atom/sst/sst_drv_interface.c:380:2: note: in expansion of macro 'dev_dbg'
dev_dbg(dev, "Ptr Query on strid = %d copied_total %d, decodec %d\n",
^
Bug: 153747771
Cc: Dhananjay Kumar <dhakumar@codeaurora.org>
Cc: Banajit Goswami <bgoswami@codeaurora.org>
Cc: Meng Wang <mwang@codeaurora.org>
Cc: Will McVicker <willmcvicker@google.com>
Fixes: dbad92f6e8 ("ANDROID: GKI: ASoC: msm: fix integer overflow for long duration offload playback")
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I0d012271c90bd56764558467b5c53a6d49570604
Commit dbad92f6e8 ("ANDROID: GKI: ASoC: msm: fix integer overflow for
long duration offload playback") causes a link error if the kernel is
built for a 32bit target, like i386.
The error is::
ERROR: "__umoddi3" [sound/soc/intel/atom/snd-soc-sst-atom-hifi2-platform.ko] undefined!
kernel/scripts/Makefile.modpost:108: recipe for target '__modpost' failed
Fix this problem up by doing the division with the internal kernel
function to do so.
Bug: 153747771
Cc: Dhananjay Kumar <dhakumar@codeaurora.org>
Cc: Banajit Goswami <bgoswami@codeaurora.org>
Cc: Meng Wang <mwang@codeaurora.org>
Cc: Will McVicker <willmcvicker@google.com>
Fixes: dbad92f6e8 ("ANDROID: GKI: ASoC: msm: fix integer overflow for long duration offload playback")
Signed-off-by: Chih-Wei Huang <cwhuang@linux.org.tw>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I339bc24c5531c2f0a14e5875728d349f837245f3
Leaf changes summary: 2 artifacts changed
Changed leaf types summary: 2 leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct sched_entity at sched.h:455:1' changed:
type size hasn't changed
4 data member deletions:
'int sched_entity::depth', at offset 2624 (in bits) at sched.h:473:1
'sched_entity* sched_entity::parent', at offset 2688 (in bits) at sched.h:474:1
'cfs_rq* sched_entity::cfs_rq', at offset 2752 (in bits) at sched.h:476:1
'cfs_rq* sched_entity::my_q', at offset 2816 (in bits) at sched.h:478:1
1627 impacted interfaces
'struct task_struct at sched.h:647:1' changed (indirectly):
type size hasn't changed
there are data member changes:
type 'struct sched_entity' of 'task_struct::se' changed, as reported earlier
1627 impacted interfaces
Bug: 153203661
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I4280b00f8a8f9b8203e570e91aeae05266634f7d
This feature is undesirable and not required by Android.
Bug: 153203661
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Id33fbe3bb46ca21ee4e2a412a766be21ffe069e0
This will ensure we get a build-time error if the whitelist does not
match the KMI resulting from a build. This indicates that some
whitelisted symbols are not actually exported, or that we export
non-whitelisted symbols. This is non-desirable either way.
Bug: 151133259
Bug: 149980028
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: Ifaa1ae8a15f09f3791ed4487920d7751062fa210
Checked the variable in f2fs-stable, I think there was a mistake to remove this
line. Let's remove this to sync with -stable.
Bug: 155529912
Fixes: be3bb0daac ("Merge 4.19.119 into android-4.19")
Change-Id: I27af455f0c59924d122a782669bac741bd9a82ea
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
That should not be enabled nor tracked for the KASAN config.
Fixes: ed18ac2d4a ("ANDROID: KASAN support for GKI")
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: I0d2fa1748bcfd844667f4b8c9e013d2fd24bca05
Changes in 4.19.121
drm/edid: Fix off-by-one in DispID DTD pixel clock
drm/qxl: qxl_release leak in qxl_draw_dirty_fb()
drm/qxl: qxl_release leak in qxl_hw_surface_alloc()
drm/qxl: qxl_release use after free
btrfs: fix block group leak when removing fails
ALSA: hda/realtek - Two front mics on a Lenovo ThinkCenter
ALSA: usb-audio: Correct a typo of NuPrime DAC-10 USB ID
ALSA: hda/hdmi: fix without unlocked before return
ALSA: pcm: oss: Place the plugin buffer overflow checks correctly
PM: ACPI: Output correct message on target power state
PM: hibernate: Freeze kernel threads in software_resume()
dm verity fec: fix hash block number in verity_fec_decode
dm writecache: fix data corruption when reloading the target
dm multipath: use updated MPATHF_QUEUE_IO on mapping for bio-based mpath
scsi: qla2xxx: set UNLOADING before waiting for session deletion
scsi: qla2xxx: check UNLOADING before posting async work
RDMA/mlx5: Set GRH fields in query QP on RoCE
RDMA/mlx4: Initialize ib_spec on the stack
RDMA/core: Prevent mixed use of FDs between shared ufiles
RDMA/core: Fix race between destroy and release FD object
vfio: avoid possible overflow in vfio_iommu_type1_pin_pages
vfio/type1: Fix VA->PA translation for PFNMAP VMAs in vaddr_get_pfn()
iommu/qcom: Fix local_base status check
scsi: target/iblock: fix WRITE SAME zeroing
iommu/amd: Fix legacy interrupt remapping for x2APIC-enabled system
ALSA: opti9xx: shut up gcc-10 range warning
nfs: Fix potential posix_acl refcnt leak in nfs3_set_acl
dmaengine: dmatest: Fix iteration non-stop logic
selinux: properly handle multiple messages in selinux_netlink_send()
btrfs: fix partial loss of prealloc extent past i_size after fsync
btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info
mmc: cqhci: Avoid false "cqhci: CQE stuck on" by not open-coding timeout loop
mmc: sdhci-xenon: fix annoying 1.8V regulator warning
mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers
mmc: sdhci-msm: Enable host capabilities pertains to R1b response
mmc: meson-mx-sdio: Set MMC_CAP_WAIT_WHILE_BUSY
mmc: meson-mx-sdio: remove the broken ->card_busy() op
Linux 4.19.121
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iba9e535d8be8646d141c60515e02989eb64397ab
commit ddca1092c4 upstream.
The recent commit 0d84c3e6a5 ("mmc: core: Convert to
mmc_poll_for_busy() for erase/trim/discard") makes use of the
->card_busy() op for SD cards. This uncovered that the ->card_busy() op
in the Meson SDIO driver was never working right:
while polling the busy status with ->card_busy()
meson_mx_mmc_card_busy() reads only one of the two MESON_MX_SDIO_IRQC
register values 0x1f001f10 or 0x1f003f10. This translates to "three out
of four DAT lines are HIGH" and "all four DAT lines are HIGH", which
is interpreted as "the card is busy".
It turns out that no situation can be observed where all four DAT lines
are LOW, meaning the card is not busy anymore. Upon further research the
3.10 vendor driver for this controller does not implement the
->card_busy() op.
Remove the ->card_busy() op from the meson-mx-sdio driver since it is
not working. At the time of writing this patch it is not clear what's
needed to make the ->card_busy() implementation work with this specific
controller hardware. For all use-cases which have previously worked the
MMC_CAP_WAIT_WHILE_BUSY flag is now taking over, even if we don't have
a ->card_busy() op anymore.
Fixes: ed80a13bb4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200416183513.993763-3-martin.blumenstingl@googlemail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1a8eb6b373 upstream.
BIOS writers have begun the practice of setting 40 ohm eMMC driver strength
even though the eMMC may not support it, on the assumption that the kernel
will validate the value against the eMMC (Extended CSD DRIVER_STRENGTH
[offset 197]) and revert to the default 50 ohm value if 40 ohm is invalid.
This is done to avoid changing the value for different boards.
Putting aside the merits of this approach, it is clear the eMMC's mask
of supported driver strengths is more reliable than the value provided
by BIOS. Add validation accordingly.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: 51ced59cc0 ("mmc: sdhci-pci: Use ACPI DSM to get driver strength for some Intel devices")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200422111629.4899-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bb32e1987b upstream.
For some reason the Host Control2 register of the Xenon SDHCI controller
sometimes reports the bit representing 1.8V signaling as 0 when read
after it was written as 1. Subsequent read reports 1.
This causes the sdhci_start_signal_voltage_switch function to report
1.8V regulator output did not become stable
When CONFIG_PM is enabled, the host is suspended and resumend many
times, and in each resume the switch to 1.8V is called, and so the
kernel log reports this message annoyingly often.
Do an empty read of the Host Control2 register in Xenon's
.voltage_switch method to circumvent this.
This patch fixes this particular problem on Turris MOX.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Fixes: 8d876bf472 ("mmc: sdhci-xenon: wait 5ms after set 1.8V...")
Cc: stable@vger.kernel.org # v4.16+
Link: https://lore.kernel.org/r/20200420080444.25242-1-marek.behun@nic.cz
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
