Wong Vee Khee [Tue, 5 Oct 2021 11:51:00 +0000 (19:51 +0800)]
net: stmmac: trigger PCS EEE to turn off on link down
The current implementation enable PCS EEE feature in the event of link
up, but PCS EEE feature is not disabled on link down.
This patch makes sure PCE EEE feature is disabled on link down.
Fixes: 656ed8b015f1 ("net: stmmac: fix EEE init issue when paired with EEE capable PHYs") Signed-off-by: Wong Vee Khee <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Wong Vee Khee [Tue, 5 Oct 2021 11:50:59 +0000 (19:50 +0800)]
net: pcs: xpcs: fix incorrect steps on disable EEE
When Energy-Efficient Ethernet(EEE) is disable from the MAC side,
we need to clear the DW_VR_MII_EEE_TRN_LPI bit of DW_VR_MII_EEE_MCTRL1
register.
Fixes: 7617af3d1a5e ("net: pcs: Introducing support for DWC xpcs Energy Efficient Ethernet") Cc: Michael Sit Wei Hong <[email protected]> Signed-off-by: Wong Vee Khee <[email protected]> Signed-off-by: David S. Miller <[email protected]>
firmware: arm_scmi: Add proper barriers to scmi virtio device
Only one single SCMI Virtio device is currently supported by this driver
and it is referenced using a static global variable which is initialized
once for all during probing and nullified at virtio device removal.
Add proper SMP barriers to protect accesses to such device reference to
ensure that the initialzation state of such device is correctly observed by
all PEs at any time.
Return -EBUSY, instead of -EINVAL, and a descriptive error message if more
than one SCMI Virtio device is ever found and probed.
Jeremy Cline [Thu, 3 Dec 2020 00:02:20 +0000 (19:02 -0500)]
drm/nouveau: avoid a use-after-free when BO init fails
nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code
back to the caller. On failures, ttm_bo_init() invokes the provided
destructor which should de-initialize and free the memory.
Thus, when nouveau_bo_init() returns an error the gem object has already
been released and the memory freed by nouveau_bo_del_ttm().
Mark Brown [Tue, 21 Sep 2021 21:21:02 +0000 (22:21 +0100)]
video: fbdev: gbefb: Only instantiate device when built for IP32
The gbefb driver not only registers a driver but also the device for that
driver. This is all well and good when run on the IP32 machines that are
supported by the driver but since the driver supports building with
COMPILE_TEST we might also be building on other platforms which do not have
this hardware and will crash instantiating the driver. Add an IS_ENABLED()
check so we compile out the device registration if we don't have the Kconfig
option for the machine enabled.
Configurations with both CONFIG_FB_SIMPLE=y and CONFIG_DRM_SIMPLEDRM=m
are allowed by Kconfig because the 'depends on !DRM_SIMPLEDRM' dependency
does not disallow FB_SIMPLE as long as SIMPLEDRM is not built-in. This
can however result in a build failure when cfb_fillrect() etc are then
also in loadable modules:
x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x1f8): undefined reference to `cfb_fillrect'
x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x200): undefined reference to `cfb_copyarea'
x86_64-linux-ld: drivers/video/fbdev/simplefb.o:(.rodata+0x208): undefined reference to `cfb_imageblit'
To work around this, change FB_SIMPLE to be a 'tristate' symbol,
which still allows both to be =m together, but not one of them to
be =y if the other one is =m. If a distro kernel picks this
configuration, it can be determined by local policy which of
the two modules gets loaded. The 'of_chosen' export is needed
as this is the first loadable module referencing it.
Alternatively, the Kconfig dependency could be changed to
'depends on DRM_SIMPLEDRM=n', which would forbid the configuration
with both drivers.
Chris Morgan [Thu, 16 Sep 2021 20:29:07 +0000 (15:29 -0500)]
drm/rockchip: Update crtc fixup to account for fractional clk change
After commit 928f9e268611 ("clk: fractional-divider: Hide
clk_fractional_divider_ops from wide audience") was merged it appears
that the DSI panel on my Odroid Go Advance stopped working. Upon closer
examination of the problem, it looks like it was the fixup in the
rockchip_drm_vop.c file was causing the issue. The changes made to the
clk driver appear to change some assumptions made in the fixup.
After debugging the working 5.14 kernel and the no-longer working
5.15 kernel, it looks like this was broken all along but still
worked, whereas after the fractional clock change it stopped
working despite the issue (it went from sort-of broken to very broken).
In the 5.14 kernel the dclk_vopb_frac was being requested to be set to 17000999 on my board. The clock driver was taking the value of the
parent clock and attempting to divide the requested value from it
(17000000/17000999 = 0), then subtracting 1 from it (making it -1),
and running it through fls_long to get 64. It would then subtract
the value of fd->mwidth from it to get 48, and then bit shift 17000999 to the left by 48, coming up with a very large number of 7649082492112076800. This resulted in a numerator of 65535 and a
denominator of 1 from the clk driver. The driver seemingly would
try again and get a correct 1:1 value later, and then move on.
Output from my 5.14 kernel (with some printfs for good measure):
[ 2.830066] rockchip-drm display-subsystem: bound ff460000.vop (ops vop_component_ops)
[ 2.839431] rockchip-drm display-subsystem: bound ff450000.dsi (ops dw_mipi_dsi_rockchip_ops)
[ 2.855980] Clock is dclk_vopb_frac
[ 2.856004] Scale 64, Rate 7649082492112076800, Oldrate 17000999, Parent Rate 17000000, Best Numerator 65535, Best Denominator 1, fd->mwidth 16
[ 2.903529] Clock is dclk_vopb_frac
[ 2.903556] Scale 0, Rate 17000000, Oldrate 17000000, Parent Rate 17000000, Best Numerator 1, Best Denominator 1, fd->mwidth 16
[ 2.903579] Clock is dclk_vopb_frac
[ 2.903583] Scale 0, Rate 17000000, Oldrate 17000000, Parent Rate 17000000, Best Numerator 1, Best Denominator 1, fd->mwidth 16
Contrast this with 5.15 after the clk change where the rate of 17000999
was getting passed and resulted in numerators/denomiators of 17001/
17000.
Output from my 5.15 kernel (with some printfs added for good measure):
[ 2.817571] rockchip-drm display-subsystem: bound ff460000.vop (ops vop_component_ops)
[ 2.826975] rockchip-drm display-subsystem: bound ff450000.dsi (ops dw_mipi_dsi_rockchip_ops)
[ 2.843430] Rate 17000999, Parent Rate 17000000, Best Numerator 17018, Best Denominator 17017
[ 2.891073] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000
[ 2.891269] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000
[ 2.891281] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000
I have tested the change extensively on my Odroid Go Advance (Rockchip
RK3326) and it appears to work well. However, this change will affect
all Rockchip SoCs that use this driver so I believe further testing
is warranted. Please note that without this change I can confirm
at least all PX30s with DSI panels will stop working with the 5.15
kernel.
Upon advice from Doug Anderson <[email protected]> it was decided
that we would first check if the clock rate can be set exactly as
requested, and only if it could not would we then add 999 to it and
attempt the process again. This way we can preserve the behavior for
clocks that still need it while resolving the specific issue for the
PX30 and DSI panels (since it is using a fractional clock).
Changes since v2:
- Moved fixes to correct location.
Changes since v1:
- Made the addition of 999 conditional based on whether the clock
subsystem can set the actual clock rate as requested.
- Updated the notes in the fixup routine to reflect this new behavior.
- Added reference to original commit, as this has technically been
broken since then however only now is it an issue due to the clock
changes.
Ben Skeggs [Thu, 16 Sep 2021 22:04:06 +0000 (08:04 +1000)]
drm/nouveau/ga102-: support ttm buffer moves via copy engine
We don't currently have any kind of real acceleration on Ampere GPUs,
but the TTM memcpy() fallback paths aren't really designed to handle
copies between different devices, such as on Optimus systems, and
result in a kernel OOPS.
A few options were investigated to try and fix this, but didn't work
out, and likely would have resulted in a very unpleasant experience
for users anyway.
This commit adds just enough support for setting up a single channel
connected to a copy engine, which the kernel can use to accelerate
the buffer copies between devices. Userspace has no access to this
incomplete channel support, but it's suitable for TTM's needs.
A more complete implementation of host(fifo) for Ampere GPUs is in
the works, but the required changes are far too invasive that they
would be unsuitable to backport to fix this issue on current kernels.
v2: fix GPFIFO length in RAMFC (reported by Karol)
Recent rework, which made HDMI PHY driver a platform device, inadvertely
reversed clock setup order. HW is very touchy about it. Proper way is to
handle controllers resets and clocks first and HDMI PHYs second.
Currently, without this fix, first mode set completely fails (nothing on
HDMI monitor) on H3 era PHYs. On H6, it still somehow work.
Move HDMI PHY reset & clocks handling to sun8i_hdmi_phy_init() which
will assure that code is executed after controllers reset & clocks are
handled. Additionally, add sun8i_hdmi_phy_deinit() which will deinit
them at controllers driver unload.
Maxime Ripard [Thu, 19 Aug 2021 14:07:53 +0000 (16:07 +0200)]
drm/vc4: hdmi: Remove unused struct
Commitc7d30623540b ("drm/vc4: hdmi: Remove unused struct") removed the
references to the vc4_hdmi_audio_widgets and vc4_hdmi_audio_routes
structures, but not the structures themselves resulting in two warnings.
Remove it.
ksmbd: add the check to vaildate if stream protocol length exceeds maximum value
This patch add MAX_STREAM_PROT_LEN macro and check if stream protocol
length exceeds maximum value. opencode pdu size check in
ksmbd_pdu_size_has_room().
Tony Lindgren [Wed, 8 Sep 2021 05:49:36 +0000 (08:49 +0300)]
bus: ti-sysc: Use CLKDM_NOAUTO for dra7 dcan1 for errata i893
Commit 94f6345712b3 ("bus: ti-sysc: Implement quirk handling for
CLKDM_NOAUTO") should have also added the quirk for dra7 dcan1 in
addition to dcan2 for errata i893 handling.
Let's also pass the quirk flag for legacy mode booting for if "ti,hwmods"
dts property is used with related dcan hwmod data. This should be only
needed if anybody needs to git bisect earlier stable trees though.
Fixes: 94f6345712b3 ("bus: ti-sysc: Implement quirk handling for CLKDM_NOAUTO") Signed-off-by: Tony Lindgren <[email protected]>
Guenter Roeck [Sun, 1 Aug 2021 17:36:59 +0000 (10:36 -0700)]
xtensa: xtfpga: Try software restart before simulating CPU reset
Rebooting xtensa images loaded with the '-kernel' option in qemu does
not work. When executing a reboot command, the qemu session either hangs
or experiences an endless sequence of error messages.
Kernel panic - not syncing: Unrecoverable error in exception handler
Reset code jumps to the CPU restart address, but Linux can not recover
from there because code and data in the kernel init sections have been
discarded and overwritten at this point.
XTFPGA platforms have a means to reset the CPU by writing 0xdead into a
specific FPGA IO address. When used in QEMU the kernel image loaded with
the '-kernel' option gets restored to its original state allowing the
machine to boot successfully.
Use that mechanism to attempt a platform reset. If it does not work,
fall back to the existing mechanism.
Max Filippov [Tue, 5 Oct 2021 18:36:01 +0000 (11:36 -0700)]
xtensa: xtfpga: use CONFIG_USE_OF instead of CONFIG_OF
Use platform data to initialize xtfpga device drivers when CONFIG_USE_OF
is not selected. This fixes xtfpga networking when CONFIG_USE_OF is not
selected but CONFIG_OF is.
Joe Lawrence [Sun, 22 Aug 2021 22:50:36 +0000 (18:50 -0400)]
objtool: Make .altinstructions section entry size consistent
Commit e31694e0a7a7 ("objtool: Don't make .altinstructions writable")
aligned objtool-created and kernel-created .altinstructions section
flags, but there remains a minor discrepency in their use of a section
entry size: objtool sets one while the kernel build does not.
While sh_entsize of sizeof(struct alt_instr) seems intuitive, this small
deviation can cause failures with external tooling (kpatch-build).
Fix this by creating new .altinstructions sections with sh_entsize of 0
and then later updating sec->sh_size as alternatives are added to the
section. An added benefit is avoiding the data descriptor and buffer
created by elf_create_section(), but previously unused by
elf_add_alternative().
Josh Poimboeuf [Mon, 4 Oct 2021 17:07:50 +0000 (10:07 -0700)]
objtool: Remove reloc symbol type checks in get_alt_entry()
Converting a special section's relocation reference to a symbol is
straightforward. No need for objtool to complain that it doesn't know
how to handle it. Just handle it.
This fixes the following warning:
arch/x86/kvm/emulate.o: warning: objtool: __ex_table+0x4: don't know how to handle reloc symbol type: kvm_fastop_exception
The Topdown metrics events were added as 'perf stat' default events
since commit 42641d6f4d15e6db ("perf stat: Add Topdown metrics events as
default events").
However, the perf attr tests were not updated
accordingly.
The perf attr test fails on the platform which supports Topdown metrics.
# perf test 17
17: Setup struct perf_event_attr :FAILED!
Add Topdown metrics events into perf attr test cases. Make them optional
since they are only available on newer platforms.
Linus Torvalds [Tue, 5 Oct 2021 17:52:53 +0000 (10:52 -0700)]
Merge tag 'warning-fixes-20211005' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
Pull misc fs warning fixes from David Howells:
"The first four patches fix kerneldoc warnings in fscache, afs, 9p and
nfs - they're mostly just comment changes, though there's one place in
9p where a comment got detached from the function it was attached to
(v9fs_fid_add) and has to switch places with a function that got
inserted between (__add_fid).
The patch on the end removes an unused symbol in fscache"
* tag 'warning-fixes-20211005' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
fscache: Remove an unused static variable
fscache: Fix some kerneldoc warnings shown up by W=1
9p: Fix a bunch of kerneldoc warnings shown up by W=1
afs: Fix kerneldoc warning shown up by W=1
nfs: Fix kerneldoc warning shown up by W=1
Which entails no changes in the tooling side as it doesn't introduce new
SNDRV_PCM_IOCTL_ ioctls.
To silence this perf tools build warning:
Warning: Kernel ABI header at 'tools/include/uapi/sound/asound.h' differs from latest version at 'include/uapi/sound/asound.h'
diff -u tools/include/uapi/sound/asound.h include/uapi/sound/asound.h
perf build: Fix plugin static linking with libopencsd on ARM and ARM64
Filter out -static flag when building plugins as they are always built
as dynamic libraries and -static and -dynamic don't work well together
on arm and arm64.
Guchun Chen [Fri, 1 Oct 2021 01:48:50 +0000 (09:48 +0800)]
drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume
In current code, when a PCI error state pci_channel_io_normal is detectd,
it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI
driver will continue the execution of PCI resume callback report_resume by
pci_walk_bridge, and the callback will go into amdgpu_pci_resume
finally, where write lock is releasd unconditionally without acquiring
such lock first. In this case, a deadlock will happen when other threads
start to acquire the read lock.
To fix this, add a member in amdgpu_device strucutre to cache
pci_channel_state, and only continue the execution in amdgpu_pci_resume
when it's pci_channel_io_frozen.
Lijo Lazar [Fri, 1 Oct 2021 08:49:07 +0000 (16:49 +0800)]
drm/amdgpu: During s0ix don't wait to signal GFXOFF
In the rare event when GFX IP suspend coincides with a s0ix entry, don't
schedule a delayed work, instead signal PMFW immediately to allow GFXOFF
entry. GFXOFF is a prerequisite for s0ix entry. PMFW needs to be
signaled about GFXOFF status before amd-pmc module passes OS HINT
to PMFW telling that everything is ready for a safe s0ix entry.
ARM: sharpsl_param: work around -Wstringop-overread warning
gcc warns that accessing a pointer based on a numeric constant may
be an offset into a NULL pointer, and would therefore has zero
accessible bytes:
arch/arm/common/sharpsl_param.c: In function ‘sharpsl_save_param’:
arch/arm/common/sharpsl_param.c:43:9: error: ‘memcpy’ reading 64 bytes from a region of size 0 [-Werror=stringop-overread]
43 | memcpy(&sharpsl_param, param_start(PARAM_BASE), sizeof(struct sharpsl_param_info));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In this particular case, the warning is bogus since this is the actual
pointer, not an offset on a NULL pointer. Add a local variable to shut
up the warning and hope it doesn't come back.
Arnd Bergmann [Tue, 5 Oct 2021 13:41:15 +0000 (15:41 +0200)]
Merge tag 'imx-fixes-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 5.15:
- Revert cc8870bf4c3a to fix the regression on i.MX6 that suspend
support becomes broken.
- Add `qca,clk-out-frequency` property to fix Ethernet support on
imx6qdl-pico board.
- Re-enable FB support in imx_v6_v7_defconfig. It gets lost due to f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB").
- Fix LP5562 LED support on imx6dl-yapp4 board.
- Add missing pinctrl-names for panel on M53Menlo board.
- Fix USB host power regulator polarity on M53Menlo board.
* tag 'imx-fixes-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: imx_v6_v7_defconfig: enable fb
ARM: dts: imx6qdl-pico: Fix Ethernet support
ARM: dts: imx: Fix USB host power regulator polarity on M53Menlo
ARM: dts: imx: Add missing pinctrl-names for panel on M53Menlo
Revert "ARM: imx6q: drop of_platform_default_populate() from init_machine"
ARM: dts: imx6dl-yapp4: Fix lp5562 LED driver probe
This can cause a randconfig warning without the 'inline' flag
that every other platform uses:
In file included from arch/arm/boot/compressed/misc.c:29:
arch/arm/mach-dove/include/mach/uncompress.h:14:13: error: 'putc' defined but not used [-Werror=unused-function]
14 | static void putc(const char c)
| ^~~~
ARM: omap1: move omap15xx local bus handling to usb.c
Commit 38225f2ef2f4 ("ARM/omap1: switch to use dma_direct_set_offset for
lbus DMA offsets") removed a lot of mach/memory.h, but left the USB
offset handling split into arch/arm/mach-omap1/usb.c and
drivers/usb/host/ohci-omap.c.
This can cause a randconfig build warning that now fails the build
with -Werror:
arch/arm/mach-omap1/usb.c:561:30: error: 'omap_1510_usb_ohci_nb' defined but not used [-Werror=unused-variable]
561 | static struct notifier_block omap_1510_usb_ohci_nb = {
| ^~~~~~~~~~~~~~~~~~~~~
Move it all into the platform file to get rid of the final
location that relies on mach/memory.h.
Arnd Bergmann [Tue, 5 Oct 2021 13:38:03 +0000 (15:38 +0200)]
Merge tag 'qcom-drivers-fixes-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm driver fixes for v5.15
This restricts the QCOM_SCM driver to depend on ARCH_QCOM, to reduce
it's presence after becoming a loadable module.
It then fixes a regression in the mdt_loader, where firmware with the
hash segment marked as PT_LOAD would no longer be accepted, preventing
several MSM8974 and SDM660 devices from loading remoteproc firmware.
Lastly it corrects the drvdata associated with the socinfo device during
probe, to match that expected by the remove function.
* tag 'qcom-drivers-fixes-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
firmware: qcom_scm: QCOM_SCM should depend on ARCH_QCOM
soc: qcom: mdt_loader: Drop PT_LOAD check on hash segment
soc: qcom: socinfo: Fixed argument passed to platform_set_data()
Arnd Bergmann [Tue, 5 Oct 2021 13:37:02 +0000 (15:37 +0200)]
Merge tag 'qcom-arm64-fixes-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm ARM64 DTS fixes for 5.15
This starts by reverting the SC7280 CPUfreq update, which was merged
before concensus about the associated drivers changes was reached.
It then moves the reserved-memory changes done to get IPA working on the
Lenovo Yoga C630 into the Yoga specific DTS, as changing the memory map
on the platform level did break a couple of the other boards.
It fixes the HDMI audio on Trogdor and add missing Aggre2 NOC qos clocks
on SDM6{30,36,60} which prevented some boards from booting.
Lastly it enables the PON module on SM8250/QRB5165, as the lack thereof
is blocking automated testing in LKFT.
* tag 'qcom-arm64-fixes-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: sdm630: Add missing a2noc qos clocks
arm64: dts: qcom: qrb5165-rb5: enabled pwrkey and resin nodes
arm64: dts: qcom: pm8150: specify reboot mode magics
arm64: dts: qcom: pm8150: use qcom,pm8998-pon binding
arm64: dts: qcom: sc7180-trogdor: Fix lpass dai link for HDMI
arm64: dts: qcom: sdm850-yoga: Reshuffle IPA memory mappings
Revert "arm64: dts: qcom: sc7280: Fixup the cpufreq node"
Arnd Bergmann [Tue, 5 Oct 2021 13:36:02 +0000 (15:36 +0200)]
Merge tag 'juno-fixes-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
Juno/Vexpress fixes for v5.15
Bunch of DTS fixes to resolve addressing issues with some of the device
nodes, dropping unused/undocumented properties in various nodes, and
aligning node names with dtschema.
* tag 'juno-fixes-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
arm: dts: vexpress: Fix motherboard bus 'interrupt-map'
arm: dts: vexpress: Fix addressing issues with 'motherboard-bus' nodes
arm: dts: vexpress-v2p-ca9: Fix the SMB unit-address
arm: dts: vexpress: Drop unused properties from motherboard node
arm64: dts: arm: drop unused interrupt-names in MHU
ARM: dts: arm: align watchdog and mmc node names with dtschema
arm64: dts: arm: align watchdog and mmc node names with dtschema
arm64: dts: fvp: Remove panel timings
Arnd Bergmann [Tue, 5 Oct 2021 13:33:31 +0000 (15:33 +0200)]
Merge tag 'qcom-dts-fixes-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm DTS fixes for v5.15
This corrects the use of depricated chipid and clock names, for which
support was finally dropped from the driver. It also ensures that the
DSI PLL is fed by the correct clock, now that it's being migrated to not
rely on global clock names.
* tag 'qcom-dts-fixes-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
ARM: dts: qcom: apq8064: update Adreno clock names
ARM: dts: qcom: apq8064: Use 27MHz PXO clock as DSI PLL reference
ARM: dts: qcom: apq8064: use compatible which contains chipid
Arnd Bergmann [Tue, 5 Oct 2021 13:32:30 +0000 (15:32 +0200)]
Merge tag 'at91-fixes-5.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/fixes
AT91 fixes #2 for 5.15:
- More fixes for AT91 platform power management code related to the
introduction of sama7g5:
- management of DDR3L regulator rails for sama7g5ek
- loading of TLB on different cores
- PIO controller slew-rate settings for sama7g5ek: be aligned with
datasheet requirements.
* tag 'at91-fixes-5.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: dts: at91: sama7g5ek: to not touch slew-rate for SDMMC pins
ARM: dts: at91: sama7g5ek: use proper slew-rate settings for GMACs
ARM: at91: pm: preload base address of controllers in tlb
ARM: at91: pm: group constants and addresses loading
ARM: dts: at91: sama7g5ek: add suspend voltage for ddr3l rail
Eric Dumazet [Mon, 4 Oct 2021 21:24:15 +0000 (14:24 -0700)]
netlink: annotate data races around nlk->bound
While existing code is correct, KCSAN is reporting
a data-race in netlink_insert / netlink_sendmsg [1]
It is correct to read nlk->bound without a lock, as netlink_autobind()
will acquire all needed locks.
[1]
BUG: KCSAN: data-race in netlink_insert / netlink_sendmsg
write to 0xffff8881031c8b30 of 1 bytes by task 18752 on cpu 0:
netlink_insert+0x5cc/0x7f0 net/netlink/af_netlink.c:597
netlink_autobind+0xa9/0x150 net/netlink/af_netlink.c:842
netlink_sendmsg+0x479/0x7c0 net/netlink/af_netlink.c:1892
sock_sendmsg_nosec net/socket.c:703 [inline]
sock_sendmsg net/socket.c:723 [inline]
____sys_sendmsg+0x360/0x4d0 net/socket.c:2392
___sys_sendmsg net/socket.c:2446 [inline]
__sys_sendmsg+0x1ed/0x270 net/socket.c:2475
__do_sys_sendmsg net/socket.c:2484 [inline]
__se_sys_sendmsg net/socket.c:2482 [inline]
__x64_sys_sendmsg+0x42/0x50 net/socket.c:2482
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
read to 0xffff8881031c8b30 of 1 bytes by task 18751 on cpu 1:
netlink_sendmsg+0x270/0x7c0 net/netlink/af_netlink.c:1891
sock_sendmsg_nosec net/socket.c:703 [inline]
sock_sendmsg net/socket.c:723 [inline]
__sys_sendto+0x2a8/0x370 net/socket.c:2019
__do_sys_sendto net/socket.c:2031 [inline]
__se_sys_sendto net/socket.c:2027 [inline]
__x64_sys_sendto+0x74/0x90 net/socket.c:2027
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
value changed: 0x00 -> 0x01
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 18751 Comm: syz-executor.0 Not tainted 5.14.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Wong Vee Khee [Tue, 5 Oct 2021 03:45:21 +0000 (11:45 +0800)]
net: pcs: xpcs: fix incorrect CL37 AN sequence
According to Synopsys DesignWare Cores Ethernet PCS databook, it is
required to disable Clause 37 auto-negotiation by programming bit-12
(AN_ENABLE) to 0 if it is already enabled, before programming various
fields of VR_MII_AN_CTRL registers.
After all these programming are done, it is then required to enable
Clause 37 auto-negotiation by programming bit-12 (AN_ENABLE) to 1.
Sean Anderson [Mon, 4 Oct 2021 21:50:02 +0000 (17:50 -0400)]
net: sfp: Fix typo in state machine debug string
The string should be "tx_disable" to match the state enum.
Fixes: 4005a7cb4f55 ("net: phy: sftp: print debug message with text, not numbers") Signed-off-by: Sean Anderson <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Johan Hovold [Wed, 29 Sep 2021 09:09:37 +0000 (11:09 +0200)]
USB: cdc-acm: fix break reporting
A recent change that started reporting break events forgot to push the
event to the line discipline, which meant that a detected break would
not be reported until further characters had been receive (the port
could even have been closed and reopened in between).
Johan Hovold [Wed, 29 Sep 2021 09:09:36 +0000 (11:09 +0200)]
USB: cdc-acm: fix racy tty buffer accesses
A recent change that started reporting break events to the line
discipline caused the tty-buffer insertions to no longer be serialised
by inserting events also from the completion handler for the interrupt
endpoint.
Completion calls for distinct endpoints are not guaranteed to be
serialised. For example, in case a host-controller driver uses
bottom-half completion, the interrupt and bulk-in completion handlers
can end up running in parallel on two CPUs (high-and low-prio tasklets,
respectively) thereby breaking the tty layer's single producer
assumption.
Fix this by holding the read lock also when inserting characters from
the bulk endpoint.
Pavel Hofman [Fri, 24 Sep 2021 08:00:27 +0000 (10:00 +0200)]
usb: gadget: f_uac2: fixed EP-IN wMaxPacketSize
Async feedback patches broke enumeration on Windows 10 previously fixed
by commit 789ea77310f0 ("usb: gadget: f_uac2: always increase endpoint
max_packet_size by one audio slot").
While the existing calculation for EP OUT capture for async mode yields
size+1 frame due to uac2_opts->fb_max > 0, playback side lost the +1
feature. Therefore the +1 frame addition must be re-introduced for
playback. Win10 enumerates the device only when both EP IN and EP OUT
max packet sizes are (at least) +1 frame.
CONFIG_WWAN_CORE was with CONFIG_WWAN in commit 89212e160b81 ("net: wwan:
Fix WWAN config symbols"), but did not update all users of it. Change it
back to use CONFIG_WWAN instead.
usb: chipidea: ci_hdrc_imx: Also search for 'phys' phandle
When passing 'phys' in the devicetree to describe the USB PHY phandle
(which is the recommended way according to
Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt) the
following NULL pointer dereference is observed on i.MX7 and i.MX8MM:
[ 1.489344] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098
[ 1.498170] Mem abort info:
[ 1.500966] ESR = 0x96000044
[ 1.504030] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.509356] SET = 0, FnV = 0
[ 1.512416] EA = 0, S1PTW = 0
[ 1.515569] FSC = 0x04: level 0 translation fault
[ 1.520458] Data abort info:
[ 1.523349] ISV = 0, ISS = 0x00000044
[ 1.527196] CM = 0, WnR = 1
[ 1.530176] [0000000000000098] user address but active_mm is swapper
[ 1.536544] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[ 1.542125] Modules linked in:
[ 1.545190] CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.14.0-dirty #3
[ 1.551901] Hardware name: Kontron i.MX8MM N801X S (DT)
[ 1.557133] Workqueue: events_unbound deferred_probe_work_func
[ 1.562984] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
[ 1.568998] pc : imx7d_charger_detection+0x3f0/0x510
[ 1.573973] lr : imx7d_charger_detection+0x22c/0x510
This happens because the charger functions check for the phy presence
inside the imx_usbmisc_data structure (data->usb_phy), but the chipidea
core populates the usb_phy passed via 'phys' inside 'struct ci_hdrc'
(ci->usb_phy) instead.
This causes the NULL pointer dereference inside imx7d_charger_detection().
Fix it by also searching for 'phys' in case 'fsl,usbphy' is not found.
Xu Yang [Tue, 28 Sep 2021 11:16:39 +0000 (19:16 +0800)]
usb: typec: tcpm: handle SRC_STARTUP state if cc changes
TCPM for DRP should do the same action as SRC_ATTACHED when cc changes in
SRC_STARTUP state. Otherwise, TCPM will transition to SRC_UNATTACHED state
which is not satisfied with the Type-C spec.
Per Type-C spec:
DRP port should move to Unattached.SNK instead of Unattached.SRC if sink
removed.
Xu Yang [Sun, 26 Sep 2021 10:14:15 +0000 (18:14 +0800)]
usb: typec: tcpci: don't handle vSafe0V event if it's not enabled
USB TCPCI Spec, 4.4.3 Mask Registers:
"A masked register will still indicate in the ALERT register, but shall
not set the Alert# pin low."
Thus, the Extended Status will still indicate in ALERT register if vSafe0V
is detected by TCPC even though being masked. In current code, howerer,
this event will not be handled in detection time. Rather it will be
handled when next ALERT event coming(CC evnet, PD event, etc).
Tcpm might transition to a wrong state in this situation. Thus, the vSafe0V
event should not be handled when it's masked.
Ben Hutchings [Tue, 21 Sep 2021 14:34:42 +0000 (16:34 +0200)]
Partially revert "usb: Kconfig: using select for USB_COMMON dependency"
This reverts commit cb9c1cfc86926d0e86d19c8e34f6c23458cd3478 for
USB_LED_TRIG. This config symbol has bool type and enables extra code
in usb_common itself, not a separate driver. Enabling it should not
force usb_common to be built-in!
Andy Shevchenko [Mon, 4 Oct 2021 14:18:39 +0000 (17:18 +0300)]
usb: dwc3: gadget: Revert "set gadgets parent to the right controller"
The commit c6e23b89a95d ("usb: dwc3: gadget: set gadgets parent to the right
controller") changed the device for the UDC and broke the user space scripts
that instantiate the USB gadget(s) via ConfigFS.
Revert it for now until the better solution will be proposed.
Eric Dumazet [Tue, 5 Oct 2021 01:05:08 +0000 (18:05 -0700)]
net: bridge: fix under estimation in br_get_linkxstats_size()
Commit de1799667b00 ("net: bridge: add STP xstats")
added an additional nla_reserve_64bit() in br_fill_linkxstats(),
but forgot to update br_get_linkxstats_size() accordingly.
This can trigger the following in rtnl_stats_get()
Arnd Bergmann [Tue, 5 Oct 2021 11:20:28 +0000 (13:20 +0200)]
usb: xhci: tegra: mark PM functions as __maybe_unused
The added #ifdefs in the PM rework were almost correct, but still
cause warnings in some randconfig builds:
drivers/usb/host/xhci-tegra.c:2147:12: error: 'tegra_xusb_resume' defined but not used [-Werror=unused-function]
2147 | static int tegra_xusb_resume(struct device *dev)
| ^~~~~~~~~~~~~~~~~
drivers/usb/host/xhci-tegra.c:2105:12: error: 'tegra_xusb_suspend' defined but not used [-Werror=unused-function]
2105 | static int tegra_xusb_suspend(struct device *dev)
Replace the #ifdef checks with simpler __maybe_unused annotations to
reliably shut up these warnings.
Hayes Wang [Mon, 4 Oct 2021 06:28:58 +0000 (14:28 +0800)]
r8152: avoid to resubmit rx immediately
For the situation that the disconnect event comes very late when the
device is unplugged, the driver would resubmit the RX bulk transfer
after getting the callback with -EPROTO immediately and continually.
Finally, soft lockup occurs.
This patch avoids to resubmit RX immediately. It uses a workqueue to
schedule the RX NAPI. And the NAPI would resubmit the RX. It let the
disconnect event have opportunity to stop the submission before soft
lockup.
David Howells [Thu, 12 Aug 2021 22:08:54 +0000 (23:08 +0100)]
afs: Fix afs_launder_page() to set correct start file position
Fix afs_launder_page() to set the starting position of the StoreData RPC at
the offset into the page at which the modified data starts instead of at
the beginning of the page (the iov_iter is correctly offset).
The offset got lost during the conversion to passing an iov_iter into
afs_store_data().
Changes:
ver #2:
- Use page_offset() rather than manually calculating it[1].
David Howells [Mon, 26 Jul 2021 09:37:57 +0000 (10:37 +0100)]
netfs: Fix READ/WRITE confusion when calling iov_iter_xarray()
Fix netfs_clear_unread() to pass READ to iov_iter_xarray() instead of WRITE
(the flag is about the operation accessing the buffer, not what sort of
access it is doing to the buffer).
cachefiles: Fix oops with cachefiles_cull() due to NULL object
When cachefiles_cull() calls cachefiles_bury_object(), it passes
a NULL object. When this occurs, either trace_cachefiles_unlink()
or trace_cachefiles_rename() may oops due to the NULL object.
Check for NULL object in the tracepoint and if so, set debug_id
to MAX_UINT as was done in 2908f5e101e3.
The following oops was seen with xfstests generic/100.
BUG: kernel NULL pointer dereference, address: 0000000000000010
...
RIP: 0010:trace_event_raw_event_cachefiles_unlink+0x4e/0xa0 [cachefiles]
...
Call Trace:
cachefiles_bury_object+0x242/0x430 [cachefiles]
? __vfs_removexattr_locked+0x10f/0x150
? vfs_removexattr+0x51/0xd0
cachefiles_cull+0x84/0x120 [cachefiles]
cachefiles_daemon_cull+0xd1/0x120 [cachefiles]
cachefiles_daemon_write+0x158/0x190 [cachefiles]
vfs_write+0xbc/0x260
ksys_write+0x4f/0xc0
do_syscall_64+0x3b/0x90
The following oops was seen with xfstests generic/290.
BUG: kernel NULL pointer dereference, address: 0000000000000010
...
RIP: 0010:trace_event_raw_event_cachefiles_rename+0x54/0xa0 [cachefiles]
...
Call Trace:
cachefiles_bury_object+0x35c/0x430 [cachefiles]
cachefiles_cull+0x84/0x120 [cachefiles]
cachefiles_daemon_cull+0xd1/0x120 [cachefiles]
cachefiles_daemon_write+0x158/0x190 [cachefiles]
vfs_write+0xbc/0x260
ksys_write+0x4f/0xc0
do_syscall_64+0x3b/0x90
Ville Syrjälä [Thu, 30 Sep 2021 19:09:42 +0000 (22:09 +0300)]
drm/i915: Extend the async flip VT-d w/a to skl/bxt
Looks like skl/bxt/derivatives also need the plane stride
stretch w/a when using async flips and VT-d is enabled, or
else we get corruption on screen. To my surprise this was
even documented in bspec, but only as a note on the
CHICHKEN_PIPESL register description rather than on the
w/a list.
So very much the same thing as on HSW/BDW, except the bits
moved yet again.
With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
the size of bdb_lfp_backlight_data structure has been increased,
causing if-statement in the parse_lfp_backlight function
that comapres this structure size to the one retrieved from BDB,
always to fail for older revisions.
This patch calculates expected size of the structure for a given
BDB version and compares it with the value gathered from BDB.
Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
Imre Deak [Wed, 29 Sep 2021 13:28:27 +0000 (16:28 +0300)]
drm/i915/tc: Fix TypeC port init/resume time sanitization
Atm during driver loading and system resume TypeC ports are accessed
before their HW/SW state is synced. Move the TypeC port sanitization to
the encoder's sync_state hook to fix this.
v2: Handle the encoder disabled case in gen11_dsi_sync_state() as well
(Jose, Jani)
Jan Beulich [Thu, 30 Sep 2021 12:21:13 +0000 (14:21 +0200)]
xen/x86: adjust data placement
Both xen_pvh and xen_start_flags get written just once early during
init. Using the respective annotation then allows the open-coded placing
in .data to go away.
Additionally the former, like the latter, wants exporting, or else
xen_pvh_domain() can't be used from modules.
Jan Beulich [Thu, 30 Sep 2021 12:20:42 +0000 (14:20 +0200)]
x86/PVH: adjust function/data placement
Two of the variables can live in .init.data, allowing the open-coded
placing in .data to go away. Another "variable" is used to communicate a
size value only to very early assembly code, which hence can be both
const and live in .init.*. Additionally two functions were lacking
__init annotations.
Jan Beulich [Thu, 30 Sep 2021 12:19:48 +0000 (14:19 +0200)]
xen/x86: hook up xen_banner() also for PVH
This was effectively lost while dropping PVHv1 code. Move the function
and arrange for it to be called the same way as done in PV mode. Clearly
this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
check that was recently removed, as that's a PV-only feature.
Since the string pointed at by pv_info.name describes the mode, drop
"paravirtualized" from the log message while moving the code.
Jan Beulich [Thu, 30 Sep 2021 12:19:16 +0000 (14:19 +0200)]
xen/x86: generalize preferred console model from PV to PVH Dom0
Without announcing hvc0 as preferred it won't get used as long as tty0
gets registered earlier. This is particularly problematic with there not
being any screen output for PVH Dom0 when the screen is in graphics
mode, as the necessary information doesn't get conveyed yet from the
hypervisor.
Follow PV's model, but be conservative and do this for Dom0 only for
now.
Jan Beulich [Thu, 30 Sep 2021 12:18:12 +0000 (14:18 +0200)]
xen/x86: allow "earlyprintk=xen" to work for PV Dom0
With preferred consoles "tty" and "hvc" announced as preferred,
registering "xenboot" early won't result in use of the console: It also
needs to be registered as preferred. Generalize this from being DomU-
only so far.
Jan Beulich [Thu, 30 Sep 2021 12:17:41 +0000 (14:17 +0200)]
xen/x86: make "earlyprintk=xen" work better for PVH Dom0
The xen_hvm_early_write() path better wouldn't be taken in this case;
while port 0xE9 can be used, the hypercall path is quite a bit more
efficient. Put that first, as it may also work for DomU-s (see also
xen_raw_console_write()).
While there also bail from the function when the first
domU_write_console() failed - later ones aren't going to succeed.
Jan Beulich [Thu, 30 Sep 2021 12:16:47 +0000 (14:16 +0200)]
xen/x86: allow PVH Dom0 without XEN_PV=y
Decouple XEN_DOM0 from XEN_PV, converting some existing uses of XEN_DOM0
to a new XEN_PV_DOM0. (I'm not convinced all are really / should really
be PV-specific, but for starters I've tried to be conservative.)
For PVH Dom0 the hypervisor populates MADT with only x2APIC entries, so
without x2APIC support enabled in the kernel things aren't going to work
very well. (As opposed, DomU-s would only ever see LAPIC entries in MADT
as of now.) Note that this then requires PVH Dom0 to be 64-bit, as
X86_X2APIC depends on X86_64.
In the course of this xen_running_on_version_or_later() needs to be
available more broadly. Move it from a PV-specific to a generic file,
considering that what it does isn't really PV-specific at all anyway.
Note that xen/interface/version.h cannot be included on its own; in
enlighten.c, which uses SCHEDOP_* anyway, include xen/interface/sched.h
first to resolve the apparently sole missing type (xen_ulong_t).
Jan Beulich [Thu, 30 Sep 2021 12:16:15 +0000 (14:16 +0200)]
xen/x86: prevent PVH type from getting clobbered
Like xen_start_flags, xen_domain_type gets set before .bss gets cleared.
Hence this variable also needs to be prevented from getting put in .bss,
which is possible because XEN_NATIVE is an enumerator evaluating to
zero. Any use prior to init_hvm_pv_info() setting the variable again
would lead to wrong decisions; one such case is xenboot_console_setup()
when called as a result of "earlyprintk=xen".
Use __ro_after_init as more applicable than either __section(".data") or
__read_mostly.
Jan Beulich [Wed, 22 Sep 2021 10:18:25 +0000 (12:18 +0200)]
xen/privcmd: drop "pages" parameter from xen_remap_pfn()
The function doesn't use it and all of its callers say in a comment that
their respective arguments are to be non-NULL only in auto-translated
mode. Since xen_remap_domain_mfn_array() isn't supposed to be used by
non-PV, drop the parameter there as well. It was bogusly passed as non-
NULL (PRIV_VMA_LOCKED) by its only caller anyway. For
xen_remap_domain_gfn_range(), otoh, it's not clear at all why this
wouldn't want / might not need to gain auto-translated support down the
road, so the parameter is retained there despite now remaining unused
(and the only caller passing NULL); correct a respective comment as
well.
Jan Beulich [Wed, 22 Sep 2021 10:17:48 +0000 (12:17 +0200)]
xen/privcmd: fix error handling in mmap-resource processing
xen_pfn_t is the same size as int only on 32-bit builds (and not even
on Arm32). Hence pfns[] can't be used directly to read individual error
values returned from xen_remap_domain_mfn_array(); every other error
indicator would be skipped/ignored on 64-bit.
Jan Beulich [Wed, 22 Sep 2021 10:16:35 +0000 (12:16 +0200)]
xen/privcmd: replace kcalloc() by kvcalloc() when allocating empty pages
Osstest has been suffering test failures for a little while from order-4
allocation failures, resulting from alloc_empty_pages() calling
kcalloc(). As there's no need for physically contiguous space here,
switch to kvcalloc().
projects / linux.git / log