[ Upstream commit db0746e339 ]
Maple Ridge is first discrete USB4 host controller from Intel. It comes
with firmware based connection manager and the flows are similar as used
in Intel Titan Ridge.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Stable-dep-of: 14c7d90528 ("thunderbolt: Add support for Intel Maple Ridge single port controller")
Signed-off-by: Sasha Levin <sashal@kernel.org>
ab9c52146f ("ANDROID: cgroup: Add vendor hook for rebuild_root_domains_bypass")
introduced a hook that declared a parameter whose name collided with a
global variable. If !CONFIG_SMP, this global variable is instead a
compile-time constant which causes this error:
include/linux/cpu.h:101:28: error: expected ‘;’, ‘,’ or ‘)’ before numeric constant
Fixes: ab9c52146f ("ANDROID: cgroup: Add vendor hook for rebuild_root_domains_bypass")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I7831c5067be2ee548e8f6885eec99ab9085414fa
Test: run various range options
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Bug: 248576331
Change-Id: I75bfa9b499b974250d4d3e375537de1807268c47
commit 4071bf121d upstream.
There are sleep in atomic bug that could cause kernel panic during
firmware download process. The root cause is that nlmsg_new with
GFP_KERNEL parameter is called in fw_dnld_timeout which is a timer
handler. The call trace is shown below:
BUG: sleeping function called from invalid context at include/linux/sched/mm.h:265
Call Trace:
kmem_cache_alloc_node
__alloc_skb
nfc_genl_fw_download_done
call_timer_fn
__run_timers.part.0
run_timer_softirq
__do_softirq
...
The nlmsg_new with GFP_KERNEL parameter may sleep during memory
allocation process, and the timer handler is run as the result of
a "software interrupt" that should not call any other function
that could sleep.
This patch changes allocation mode of netlink message from GFP_KERNEL
to GFP_ATOMIC in order to prevent sleep in atomic bug. The GFP_ATOMIC
flag makes memory allocation operation could be used in atomic context.
Bug: 245675148
Fixes: 9674da8759 ("NFC: Add firmware upload netlink command")
Fixes: 9ea7187c53 ("NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOAD")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220504055847.38026-1-duoming@zju.edu.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I510b617174c0575cc6f438b2edf44f0262f9c09c
Ensure that pointer authentication is initialized when the vcpu
is initialized as well, and not only when the vcpu is reset.
Bug: 249192647
Signed-off-by: Fuad Tabba <tabba@google.com>
Change-Id: Ida39a3ee5e6b4b0d3255bfef95601890afd80709
Vendor could decide to bypass this function.
Bug: 238390134
Change-Id: Ia6bc71c7569d21da9ae226e5d8739f97b9ca1a4f
Signed-off-by: Rick Yiu <rickyiu@google.com>
There is a race present where the DWC3 runtime resume runs in parallel
to the UDC unbind sequence. This will eventually lead to a possible
scenario where we are enabling the run/stop bit, without a valid
composition defined.
Thread#1 (handling UDC unbind):
usb_gadget_remove_driver()
-->usb_gadget_disconnect()
-->dwc3_gadget_pullup(0)
--> continue UDC unbind sequence
-->Thread#2 is running in parallel here
Thread#2 (handing next cable connect)
__dwc3_set_mode()
-->pm_runtime_get_sync()
-->dwc3_gadget_resume()
-->dwc->gadget_driver is NOT NULL yet
-->dwc3_gadget_run_stop(1)
--> _dwc3gadget_start()
...
Fix this by tracking the pullup disable routine, and avoiding resuming
of the DWC3 gadget. Once the UDC is re-binded, that will trigger the
pullup enable routine, which would handle enabling the DWC3 gadget.
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Link: https://lore.kernel.org/r/20210917021852.2037-1-wcheng@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 200287549
(cherry picked from commit 8217f07a50https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing)
[wcheng: Fixed KMI breakage by moving softconnect to a new parent structure]
Change-Id: I9554933826710cc68136b08176290584f9ab74df
Signed-off-by: Wesley Cheng <wcheng@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This reverts commit b83692feb0 which is
commit 8217f07a50 upstream.
It breaks the kernel ABI and will be brought back in an abi-safe way in
a later commit.
Bug: 161946584
Bug: 200287549
Cc: Wesley Cheng <wcheng@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib9a113d36bc784b243e5a1b168a8c7470992c8ff
Ignore kvm-arm.mode if !is_hyp_mode_available(). Specifically, we want
to avoid switching kvm_mode to KVM_MODE_PROTECTED if hypervisor mode is
not available. This prevents "Protected KVM" cpu capability being
reported when Linux is booting in EL1 and would not have KVM enabled.
Reasonably though, we should warn if the command line is requesting a
KVM mode at all if KVM isn't actually available. Allow
"kvm-arm.mode=none" to skip the warning since this would disable KVM
anyway.
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220920190658.2880184-1-quic_eberman@quicinc.com
Bug: 249052880
(cherry picked from commit b2a4d007c3https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git next)
Change-Id: I196649fc00537e563a1fab0a22bf23c5b7abe00d
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
commit cc5250cdb4 upstream.
We won't really have enough skbs to need a 64-bit cookie,
and on 32-bit platforms storing the 64-bit cookie into the
void *rate_driver_data doesn't work anyway. Switch back to
using just a 32-bit cookie and uintptr_t for the type to
avoid compiler warnings about all this.
Fixes: 4ee186fa7e ("wifi: mac80211_hwsim: fix race condition in pending packet")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: Jeongik Cha <jeongik@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6dece5ad6e)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 236994625
Change-Id: I81b075297ec2248f706aebc914cd5e2783665bbc
commit 58b6259d82 upstream.
The robots report that we're now casting to a differently
sized integer, which is correct, and the previous patch
had erroneously removed it.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 4ee186fa7e ("wifi: mac80211_hwsim: fix race condition in pending packet")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: Jeongik Cha <jeongik@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d400222f49)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 236994625
Change-Id: I4b5cfa77c47d4d03b46600f0b543e27340c228c0
commit 4ee186fa7e upstream.
A pending packet uses a cookie as an unique key, but it can be duplicated
because it didn't use atomic operators.
And also, a pending packet can be null in hwsim_tx_info_frame_received_nl
due to race condition with mac80211_hwsim_stop.
For this,
* Use an atomic type and operator for a cookie
* Add a lock around the loop for pending packets
Signed-off-by: Jeongik Cha <jeongik@google.com>
Link: https://lore.kernel.org/r/20220704084354.3556326-1-jeongik@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit eb8fc4277b)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 236994625
Change-Id: Ic6613c8869a51b5de303e40406f023af689b9d64
Changes in 5.10.146
drm/amdgpu: move nbio sdma_doorbell_range() into sdma code for vega
drm/amdgpu: indirect register access for nv12 sriov
drm/amdgpu: Separate vf2pf work item init from virt data exchange
drm/amdgpu: make sure to init common IP before gmc
usb: typec: intel_pmc_mux: Update IOM port status offset for AlderLake
usb: typec: intel_pmc_mux: Add new ACPI ID for Meteor Lake IOM device
usb: dwc3: gadget: Avoid starting DWC3 gadget during UDC unbind
usb: dwc3: Issue core soft reset before enabling run/stop
usb: dwc3: gadget: Prevent repeat pullup()
usb: dwc3: gadget: Refactor pullup()
usb: dwc3: gadget: Don't modify GEVNTCOUNT in pullup()
usb: dwc3: gadget: Avoid duplicate requests to enable Run/Stop
usb: xhci-mtk: get the microframe boundary for ESIT
usb: xhci-mtk: add only one extra CS for FS/LS INTR
usb: xhci-mtk: use @sch_tt to check whether need do TT schedule
usb: xhci-mtk: add a function to (un)load bandwidth info
usb: xhci-mtk: add some schedule error number
usb: xhci-mtk: allow multiple Start-Split in a microframe
usb: xhci-mtk: relax TT periodic bandwidth allocation
mmc: core: Fix inconsistent sd3_bus_mode at UHS-I SD voltage switch failure
serial: atmel: remove redundant assignment in rs485_config
tty: serial: atmel: Preserve previous USART mode if RS485 disabled
usb: add quirks for Lenovo OneLink+ Dock
usb: gadget: udc-xilinx: replace memcpy with memcpy_toio
usb: cdns3: fix incorrect handling TRB_SMM flag for ISOC transfer
usb: cdns3: fix issue with rearming ISO OUT endpoint
Revert "usb: add quirks for Lenovo OneLink+ Dock"
vfio/type1: Change success value of vaddr_get_pfn()
vfio/type1: Prepare for batched pinning with struct vfio_batch
vfio/type1: Unpin zero pages
Revert "usb: gadget: udc-xilinx: replace memcpy with memcpy_toio"
arm64: Restrict ARM64_BTI_KERNEL to clang 12.0.0 and newer
arm64/bti: Disable in kernel BTI when cross section thunks are broken
USB: core: Fix RST error in hub.c
USB: serial: option: add Quectel BG95 0x0203 composition
USB: serial: option: add Quectel RM520N
ALSA: hda/tegra: set depop delay for tegra
ALSA: hda: add Intel 5 Series / 3400 PCI DID
ALSA: hda/realtek: Add quirk for Huawei WRT-WX9
ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5570 laptop
ALSA: hda/realtek: Re-arrange quirk table entries
ALSA: hda/realtek: Add pincfg for ASUS G513 HP jack
ALSA: hda/realtek: Add pincfg for ASUS G533Z HP jack
ALSA: hda/realtek: Add quirk for ASUS GA503R laptop
ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5530 laptop
iommu/vt-d: Check correct capability for sagaw determination
media: flexcop-usb: fix endpoint type check
efi: x86: Wipe setup_data on pure EFI boot
efi: libstub: check Shim mode using MokSBStateRT
wifi: mt76: fix reading current per-tid starting sequence number for aggregation
gpio: mockup: fix NULL pointer dereference when removing debugfs
gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully
riscv: fix a nasty sigreturn bug...
can: flexcan: flexcan_mailbox_read() fix return value for drop = true
mm/slub: fix to return errno if kmalloc() fails
KVM: SEV: add cache flush to solve SEV cache incoherency issues
interconnect: qcom: icc-rpmh: Add BCMs to commit list in pre_aggregate
xfs: fix up non-directory creation in SGID directories
xfs: reorder iunlink remove operation in xfs_ifree
xfs: validate inode fork size against fork format
arm64: dts: rockchip: Pull up wlan wake# on Gru-Bob
drm/mediatek: dsi: Add atomic {destroy,duplicate}_state, reset callbacks
arm64: dts: rockchip: Set RK3399-Gru PCLK_EDP to 24 MHz
dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get()
arm64: dts: rockchip: Remove 'enable-active-low' from rk3399-puma
netfilter: nf_conntrack_sip: fix ct_sip_walk_headers
netfilter: nf_conntrack_irc: Tighten matching on DCC message
netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find()
iavf: Fix cached head and tail value for iavf_get_tx_pending
ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header
net: let flow have same hash in two directions
net: core: fix flow symmetric hash
net: phy: aquantia: wait for the suspend/resume operations to finish
scsi: mpt3sas: Force PCIe scatterlist allocations to be within same 4 GB region
scsi: mpt3sas: Fix return value check of dma_get_required_mask()
net: bonding: Share lacpdu_mcast_addr definition
net: bonding: Unsync device addresses on ndo_stop
net: team: Unsync device addresses on ndo_stop
drm/panel: simple: Fix innolux_g121i1_l01 bus_format
MIPS: lantiq: export clk_get_io() for lantiq_wdt.ko
MIPS: Loongson32: Fix PHY-mode being left unspecified
iavf: Fix bad page state
iavf: Fix set max MTU size with port VLAN and jumbo frames
i40e: Fix VF set max MTU size
i40e: Fix set max_tx_rate when it is lower than 1 Mbps
sfc: fix TX channel offset when using legacy interrupts
sfc: fix null pointer dereference in efx_hard_start_xmit
drm/hisilicon/hibmc: Allow to be built if COMPILE_TEST is enabled
drm/hisilicon: Add depends on MMU
of: mdio: Add of_node_put() when breaking out of for_each_xx
net: ipa: fix assumptions about DMA address size
net: ipa: fix table alignment requirement
net: ipa: avoid 64-bit modulus
net: ipa: DMA addresses are nicely aligned
net: ipa: kill IPA_TABLE_ENTRY_SIZE
net: ipa: properly limit modem routing table use
wireguard: ratelimiter: disable timings test by default
wireguard: netlink: avoid variable-sized memcpy on sockaddr
net: enetc: move enetc_set_psfp() out of the common enetc_set_features()
net: socket: remove register_gifconf
net/sched: taprio: avoid disabling offload when it was never enabled
net/sched: taprio: make qdisc_leaf() see the per-netdev-queue pfifo child qdiscs
netfilter: nf_tables: fix nft_counters_enabled underflow at nf_tables_addchain()
netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain()
netfilter: ebtables: fix memory leak when blob is malformed
can: gs_usb: gs_can_open(): fix race dev->can.state condition
perf jit: Include program header in ELF files
perf kcore_copy: Do not check /proc/modules is unchanged
drm/mediatek: dsi: Move mtk_dsi_stop() call back to mtk_dsi_poweroff()
net/smc: Stop the CLC flow if no link to map buffers on
net: sunhme: Fix packet reception for len < RX_COPY_THRESHOLD
net: sched: fix possible refcount leak in tc_new_tfilter()
selftests: forwarding: add shebang for sch_red.sh
drm/amd/amdgpu: fixing read wrong pf2vf data in SRIOV
serial: Create uart_xmit_advance()
serial: tegra: Use uart_xmit_advance(), fixes icount.tx accounting
serial: tegra-tcu: Use uart_xmit_advance(), fixes icount.tx accounting
s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup
usb: xhci-mtk: fix issue of out-of-bounds array access
vfio/type1: fix vaddr_get_pfns() return in vfio_pin_page_external()
drm/amdgpu: Fix check for RAS support
cifs: use discard iterator to discard unneeded network data more efficiently
cifs: always initialize struct msghdr smb_msg completely
Drivers: hv: Never allocate anything besides framebuffer from framebuffer memory region
drm/gma500: Fix BUG: sleeping function called from invalid context errors
drm/amdgpu: use dirty framebuffer helper
drm/amd/display: Limit user regamma to a valid value
drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack usage
drm/rockchip: Fix return type of cdn_dp_connector_mode_valid
workqueue: don't skip lockdep work dependency in cancel_work_sync()
i2c: imx: If pm_runtime_get_sync() returned 1 device access is possible
i2c: mlxbf: incorrect base address passed during io write
i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction()
i2c: mlxbf: Fix frequency calculation
devdax: Fix soft-reservation memory description
ext4: fix bug in extents parsing when eh_entries == 0 and eh_depth > 0
ext4: limit the number of retries after discarding preallocations blocks
ext4: make directory inode spreading reflect flexbg size
Linux 5.10.146
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I318b932aea45394d834e80317a26c465bdd201b8
This patch addresses an issue seen where SCHED_FIFO prio 99
tasks were being woken up on a cpu where a long-running softirq
was executing, and the RT task was not being migrated, causing
long (10+ms wakeup latencies).
Prior to upstream commit 934fc3314b ("sched/cpupri: Remap
CPUPRI_NORMAL to MAX_RT_PRIO-1") the task->prio -> cpupri
mapping is a little ackward.
For RT tasks, its calculated as:
cpupri = MAX_RT_PRIO - prio + 1;
See:
https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.10/kernel/sched/cpupri.c#39
This is added ontop of the also ackward detail that the
task->prio is inverted (RT prio99 -> 0), means the cpupri
mapping for RT tasks goes from 2->101. This makes it easy to
evaluate the cpupri incorrectly.
Which it turns out happened In commit 3adfd8e344 ("ANDROID:
sched: avoid placing RT threads on cores handling softirqs"):
3adfd8e344%5E%21/
With the lines:
int task_pri = convert_prio(p->prio);
bool drop_nopreempts = task_pri <= MAX_RT_PRIO;
Where the added logic to decide to migrate a rt task off of a
cpu depended on this drop_nopreempts being true.
This works properly for rt tasks from prio 99 to 1, but for the
case of task->prio == 0 (userland rt prio 99 tasks) it breaks,
as the cpupri will be MAX_RT_PRIO - 0 + 1, which then gets
checked as <= MAX_RT_PRIO.
This prevents the cpu from being dropped from the scheduling
set and prevents the rt user prio 99 task from migrating, which
results in high priority rt tasks being left on cpus where long
running softirqs are executing, causing long latencies.
This patch fixes the off by one by changing the evaulation
to MAX_RT_PRIO + 1, so that user-prio 99 tasks will also be
migrated if appropriate.
Luckilly this odd cpupri mapping has been fixed upstream, making
this patch no longer necessary in 5.15 and newer kernels.
Fixes: 3adfd8e344 ("ANDROID: sched: avoid placing RT threads on cores handling softirqs")
Signed-off-by: John Stultz <jstultz@google.com>
Change-Id: Ia2db7cd461eb4c90f5850b791de1ae95582f7530
commit 80fa46d6b9 upstream.
This patch avoids threads live-locking for hours when a large number
threads are competing over the last few free extents as they blocks
getting added and removed from preallocation pools. From our bug
reporter:
A reliable way for triggering this has multiple writers
continuously write() to files when the filesystem is full, while
small amounts of space are freed (e.g. by truncating a large file
-1MiB at a time). In the local filesystem, this can be done by
simply not checking the return code of write (0) and/or the error
(ENOSPACE) that is set. Over NFS with an async mount, even clients
with proper error checking will behave this way since the linux NFS
client implementation will not propagate the server errors [the
write syscalls immediately return success] until the file handle is
closed. This leads to a situation where NFS clients send a
continuous stream of WRITE rpcs which result in ERRNOSPACE -- but
since the client isn't seeing this, the stream of writes continues
at maximum network speed.
When some space does appear, multiple writers will all attempt to
claim it for their current write. For NFS, we may see dozens to
hundreds of threads that do this.
The real-world scenario of this is database backup tooling (in
particular, github.com/mdkent/percona-xtrabackup) which may write
large files (>1TiB) to NFS for safe keeping. Some temporary files
are written, rewound, and read back -- all before closing the file
handle (the temp file is actually unlinked, to trigger automatic
deletion on close/crash.) An application like this operating on an
async NFS mount will not see an error code until TiB have been
written/read.
The lockup was observed when running this database backup on large
filesystems (64 TiB in this case) with a high number of block
groups and no free space. Fragmentation is generally not a factor
in this filesystem (~thousands of large files, mostly contiguous
except for the parts written while the filesystem is at capacity.)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 67feaba413 upstream.
The "hmem" platform-devices that are created to represent the
platform-advertised "Soft Reserved" memory ranges end up inserting a
resource that causes the iomem_resource tree to look like this:
340000000-43fffffff : hmem.0
340000000-43fffffff : Soft Reserved
340000000-43fffffff : dax0.0
This is because insert_resource() reparents ranges when they completely
intersect an existing range.
This matters because code that uses region_intersects() to scan for a
given IORES_DESC will only check that top-level 'hmem.0' resource and
not the 'Soft Reserved' descendant.
So, to support EINJ (via einj_error_inject()) to inject errors into
memory hosted by a dax-device, be sure to describe the memory as
IORES_DESC_SOFT_RESERVED. This is a follow-on to:
commit b13a3e5fd4 ("ACPI: APEI: Fix _EINJ vs EFI_MEMORY_SP")
...that fixed EINJ support for "Soft Reserved" ranges in the first
instance.
Fixes: 262b45ae3a ("x86/efi: EFI soft reservation to E820 enumeration")
Reported-by: Ricardo Sandoval Torres <ricardo.sandoval.torres@intel.com>
Tested-by: Ricardo Sandoval Torres <ricardo.sandoval.torres@intel.com>
Cc: <stable@vger.kernel.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Omar Avelar <omar.avelar@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Mark Gross <markgross@kernel.org>
Link: https://lore.kernel.org/r/166397075670.389916.7435722208896316387.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 37f071ec32 ]
The i2c-mlxbf.c driver is currently broken because there is a bug
in the calculation of the frequency. core_f, core_r and core_od
are components read from hardware registers and are used to
compute the frequency used to compute different timing parameters.
The shifting mechanism used to get core_f, core_r and core_od is
wrong. Use FIELD_GET to mask and shift the bitfields properly.
Fixes: b5b5b32081 (i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC)
Reviewed-by: Khalil Blaiech <kblaiech@nvidia.com>
Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit de24aceb07 ]
memcpy() is called in a loop while 'operation->length' upper bound
is not checked and 'data_idx' also increments.
Fixes: b5b5b32081 ("i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC")
Reviewed-by: Khalil Blaiech <kblaiech@nvidia.com>
Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2a5be6d134 ]
Correct the base address used during io write.
This bug had no impact over the overall functionality of the read and write
transactions. MLXBF_I2C_CAUSE_OR_CLEAR=0x18 so writing to (smbus->io + 0x18)
instead of (mst_cause->ioi + 0x18) actually writes to the sc_low_timeout
register which just sets the timeout value before a read/write aborts.
Fixes: b5b5b32081 (i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC)
Reviewed-by: Khalil Blaiech <kblaiech@nvidia.com>
Signed-off-by: Asmaa Mnebhi <asmaa@nvidia.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 085aacaa73 ]
pm_runtime_get_sync() returning 1 also means the device is powered. So
resetting the chip registers in .remove() is possible and should be
done.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: d98bdd3a5b ("i2c: imx: Make sure to unregister adapter on remove()")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c0feea594e ]
Like Hillf Danton mentioned
syzbot should have been able to catch cancel_work_sync() in work context
by checking lockdep_map in __flush_work() for both flush and cancel.
in [1], being unable to report an obvious deadlock scenario shown below is
broken. From locking dependency perspective, sync version of cancel request
should behave as if flush request, for it waits for completion of work if
that work has already started execution.
----------
#include <linux/module.h>
#include <linux/sched.h>
static DEFINE_MUTEX(mutex);
static void work_fn(struct work_struct *work)
{
schedule_timeout_uninterruptible(HZ / 5);
mutex_lock(&mutex);
mutex_unlock(&mutex);
}
static DECLARE_WORK(work, work_fn);
static int __init test_init(void)
{
schedule_work(&work);
schedule_timeout_uninterruptible(HZ / 10);
mutex_lock(&mutex);
cancel_work_sync(&work);
mutex_unlock(&mutex);
return -EINVAL;
}
module_init(test_init);
MODULE_LICENSE("GPL");
----------
The check this patch restores was added by commit 0976dfc1d0
("workqueue: Catch more locking problems with flush_work()").
Then, lockdep's crossrelease feature was added by commit b09be676e0
("locking/lockdep: Implement the 'crossrelease' feature"). As a result,
this check was once removed by commit fd1a5b04df ("workqueue: Remove
now redundant lock acquisitions wrt. workqueue flushes").
But lockdep's crossrelease feature was removed by commit e966eaeeb6
("locking/lockdep: Remove the cross-release locking checks"). At this
point, this check should have been restored.
Then, commit d6e89786be ("workqueue: skip lockdep wq dependency in
cancel_work_sync()") introduced a boolean flag in order to distinguish
flush_work() and cancel_work_sync(), for checking "struct workqueue_struct"
dependency when called from cancel_work_sync() was causing false positives.
Then, commit 87915adc3f ("workqueue: re-add lockdep dependencies for
flushing") tried to restore "struct work_struct" dependency check, but by
error checked this boolean flag. Like an example shown above indicates,
"struct work_struct" dependency needs to be checked for both flush_work()
and cancel_work_sync().
Link: https://lkml.kernel.org/r/20220504044800.4966-1-hdanton@sina.com [1]
Reported-by: Hillf Danton <hdanton@sina.com>
Suggested-by: Lai Jiangshan <jiangshanlai@gmail.com>
Fixes: 87915adc3f ("workqueue: re-add lockdep dependencies for flushing")
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 41012d715d ]
This function consumes a lot of stack space and it blows up the size of
dml30_ModeSupportAndSystemConfigurationFull() with clang:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3542:6: error: stack frame size (2200) exceeds limit (2048) in 'dml30_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than]
void dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib)
^
1 error generated.
Commit a0f7e7f759 ("drm/amd/display: fix i386 frame size warning")
aimed to address this for i386 but it did not help x86_64.
To reduce the amount of stack space that
dml30_ModeSupportAndSystemConfigurationFull() uses, mark
UseMinimumDCFCLK() as noinline, using the _for_stack variant for
documentation. While this will increase the total amount of stack usage
between the two functions (1632 and 1304 bytes respectively), it will
make sure both stay below the limit of 2048 bytes for these files. The
aforementioned change does help reduce UseMinimumDCFCLK()'s stack usage
so it should not be reverted in favor of this change.
Link: https://github.com/ClangBuiltLinux/linux/issues/1681
Reported-by: "Sudip Mukherjee (Codethink)" <sudipm.mukherjee@gmail.com>
Tested-by: Maíra Canal <mairacanal@riseup.net>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3601d620f2 ]
[Why]
For HDR mode, we get total 512 tf_point and after switching to SDR mode
we actually get 400 tf_point and the rest of points(401~512) still use
dirty value from HDR mode. We should limit the rest of the points to max
value.
[How]
Limit the value when coordinates_x.x > 1, just like what we do in
translate_from_linear_space for other re-gamma build paths.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: Krunoslav Kovac <Krunoslav.Kovac@amd.com>
Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Pavle Kotarac <Pavle.Kotarac@amd.com>
Signed-off-by: Yao Wang1 <Yao.Wang1@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f0880e2cb7 ]
Passed through PCI device sometimes misbehave on Gen1 VMs when Hyper-V
DRM driver is also loaded. Looking at IOMEM assignment, we can see e.g.
$ cat /proc/iomem
...
f8000000-fffbffff : PCI Bus 0000:00
f8000000-fbffffff : 0000:00:08.0
f8000000-f8001fff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
...
fe0000000-fffffffff : PCI Bus 0000:00
fe0000000-fe07fffff : bb8c4f33-2ba2-4808-9f7f-02f3b4da22fe
fe0000000-fe07fffff : 2ba2:00:02.0
fe0000000-fe07fffff : mlx4_core
the interesting part is the 'f8000000' region as it is actually the
VM's framebuffer:
$ lspci -v
...
0000:00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual VGA (prog-if 00 [VGA controller])
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at f8000000 (32-bit, non-prefetchable) [size=64M]
...
hv_vmbus: registering driver hyperv_drm
hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Synthvid Version major 3, minor 5
hyperv_drm 0000:00:08.0: vgaarb: deactivate vga console
hyperv_drm 0000:00:08.0: BAR 0: can't reserve [mem 0xf8000000-0xfbffffff]
hyperv_drm 5620e0c7-8062-4dce-aeb7-520c7ef76171: [drm] Cannot request framebuffer, boot fb still active?
Note: "Cannot request framebuffer" is not a fatal error in
hyperv_setup_gen1() as the code assumes there's some other framebuffer
device there but we actually have some other PCI device (mlx4 in this
case) config space there!
The problem appears to be that vmbus_allocate_mmio() can use dedicated
framebuffer region to serve any MMIO request from any device. The
semantics one might assume of a parameter named "fb_overlap_ok"
aren't implemented because !fb_overlap_ok essentially has no effect.
The existing semantics are really "prefer_fb_overlap". This patch
implements the expected and needed semantics, which is to not allocate
from the frame buffer space when !fb_overlap_ok.
Note, Gen2 VMs are usually unaffected by the issue because
framebuffer region is already taken by EFI fb (in case kernel supports
it) but Gen1 VMs may have this region unclaimed by the time Hyper-V PCI
pass-through driver tries allocating MMIO space if Hyper-V DRM/FB drivers
load after it. Devices can be brought up in any sequence so let's
resolve the issue by always ignoring 'fb_mmio' region for non-FB
requests, even if the region is unclaimed.
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Link: https://lore.kernel.org/r/20220827130345.1320254-4-vkuznets@redhat.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit bedc8f76b3 ]
So far we were just lucky because the uninitialized members
of struct msghdr are not used by default on a SOCK_STREAM tcp
socket.
But as new things like msg_ubuf and sg_from_iter where added
recently, we should play on the safe side and avoid potention
problems in future.
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Cc: stable@vger.kernel.org
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit cf0604a686 ]
The iterator, ITER_DISCARD, that can only be used in READ mode and
just discards any data copied to it, was added to allow a network
filesystem to discard any unwanted data sent by a server.
Convert cifs_discard_from_socket() to use this.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Stable-dep-of: bedc8f76b3 ("cifs: always initialize struct msghdr smb_msg completely")
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4ab4fcfce5 upstream.
vaddr_get_pfns() now returns the positive number of pfns successfully
gotten instead of zero. vfio_pin_page_external() might return 1 to
vfio_iommu_type1_pin_pages(), which will treat it as an error, if
vaddr_get_pfns() is successful but vfio_pin_page_external() doesn't
reach vfio_lock_acct().
Fix it up in vfio_pin_page_external(). Found by inspection.
Fixes: be16c1fd99 ("vfio/type1: Change success value of vaddr_get_pfn()")
Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Message-Id: <20210308172452.38864-1-daniel.m.jordan@oracle.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit db7ba07108 upstream.
Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup
pointer being NULL.
The pavgroup pointer is checked on the entrance of the function but
without the lcu->lock being held. Therefore there is a race window
between dasd_alias_get_start_dev() and _lcu_update() which sets
pavgroup to NULL with the lcu->lock held.
Fix by checking the pavgroup pointer with lcu->lock held.
Cc: <stable@vger.kernel.org> # 2.6.25+
Fixes: 8e09f21574 ("[S390] dasd: add hyper PAV support to DASD device driver, part 1")
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
Link: https://lore.kernel.org/r/20220919154931.4123002-2-sth@linux.ibm.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9a458402fb upstream.
[Why]
This fixes 892deb4826 ("drm/amdgpu: Separate vf2pf work item init from virt data exchange").
we should read pf2vf data based at mman.fw_vram_usage_va after gmc
sw_init. commit 892deb4826 breaks this logic.
[How]
calling amdgpu_virt_exchange_data in amdgpu_virt_init_data_exchange to
set the right base in the right sequence.
v2:
call amdgpu_virt_init_data_exchange after gmc sw_init to make data
exchange workqueue run
v3:
clean up the code logic
v4:
add some comment and make the code more readable
Fixes: 892deb4826 ("drm/amdgpu: Separate vf2pf work item init from virt data exchange")
Signed-off-by: Jingwen Chen <Jingwen.Chen2@amd.com>
Reviewed-by: Horace Chen <horace.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 878e240571 ]
There is a separate receive path for small packets (under 256 bytes).
Instead of allocating a new dma-capable skb to be used for the next packet,
this path allocates a skb and copies the data into it (reusing the existing
sbk for the next packet). There are two bytes of junk data at the beginning
of every packet. I believe these are inserted in order to allow aligned DMA
and IP headers. We skip over them using skb_reserve. Before copying over
the data, we must use a barrier to ensure we see the whole packet. The
current code only synchronizes len bytes, starting from the beginning of
the packet, including the junk bytes. However, this leaves off the final
two bytes in the packet. Synchronize the whole packet.
To reproduce this problem, ping a HME with a payload size between 17 and
214
$ ping -s 17 <hme_address>
which will complain rather loudly about the data mismatch. Small packets
(below 60 bytes on the wire) do not have this issue. I suspect this is
related to the padding added to increase the minimum packet size.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20220920235018.1675956-1-seanga2@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
