Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LAN7430 driver needs patching - fix included #4117

Closed
mangodan2003 opened this issue Feb 4, 2021 · 17 comments
Closed

LAN7430 driver needs patching - fix included #4117

mangodan2003 opened this issue Feb 4, 2021 · 17 comments

Comments

@mangodan2003
Copy link

Describe the bug
lan743x module fails to map DMA here https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/net/ethernet/microchip/lan743x_main.c#L1986

To reproduce
Using the CM4IO board along with the LAN7430 evaluation board (PCIe) build and load the lan743x module.

Expected behaviour
Should work

Actual behaviour
Module init fails (note I added some debug printk's)

[   68.229990] lan743x 0000:01:00.0 eth1: using MSIX interrupts, number of vectors = 6
[   68.245017] lan743x 0000:01:00.0 eth1: Link is Down
[   68.246830] ------------[ cut here ]------------
[   68.246862] WARNING: CPU: 3 PID: 396 at kernel/dma/swiotlb.c:683 swiotlb_map+0x388/0x438
[   68.246883] lan743x 0000:01:00.0: swiotlb addr 0x0000000419400000+9236 overflow (mask ffffffff, bus limit 47fffffff).
[   68.246898] Modules linked in: sha256_generic cfg80211 rfkill 8021q garp stp llc panel_auo_h139bln01_2(O) v3d gpu_sched raspberrypi_hwmon i2c_brcmstb bcm2835_v4l2(C) dwc2 bcm2835_codec(C) roles bcm2835_isp(C) v4l2_mem2mem bcm2835_mmal_vchiq(C) videobuf2_dma_contig videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common vc4 videodev cec mc vc_sm_cma(C) drm_kms_helper snd_bcm2835(C) drm drm_panel_orientation_quirks snd_soc_core lan743x(O) snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd syscopyarea sysfillrect sysimgblt fb_sys_fops backlight rpivid_mem uio_pdrv_genirq uio ip_tables x_tables ipv6
[   68.247642] CPU: 3 PID: 396 Comm: dhcpcd Tainted: G         C O      5.10.11-v7l+ #1
[   68.247652] Hardware name: BCM2711
[   68.247662] Backtrace: 
[   68.247690] [<c020c37c>] (dump_backtrace) from [<c020c6c8>] (show_stack+0x20/0x24)
[   68.247705]  r7:ffffffff r6:00000000 r5:60000013 r4:c12e69bc
[   68.247724] [<c020c6a8>] (show_stack) from [<c0b62db4>] (dump_stack+0xcc/0xf8)
[   68.247742] [<c0b62ce8>] (dump_stack) from [<c02213a4>] (__warn+0x110/0x114)
[   68.247758]  r10:c1205048 r9:c02a7380 r8:000002ab r7:00000009 r6:00000000 r5:c0e22528
[   68.247768]  r4:c3ce7af4 r3:c1205094
[   68.247785] [<c0221294>] (__warn) from [<c022142c>] (warn_slowpath_fmt+0x84/0xc0)
[   68.247799]  r9:00000009 r8:c02a7380 r7:000002ab r6:c0e22528 r5:c0e224e4 r4:c1205048
[   68.247816] [<c02213ac>] (warn_slowpath_fmt) from [<c02a7380>] (swiotlb_map+0x388/0x438)
[   68.247830]  r9:00000000 r8:19400000 r7:00002414 r6:c1bcb070 r5:00000000 r4:ffffffff
[   68.247848] [<c02a6ff8>] (swiotlb_map) from [<c02a1fcc>] (dma_map_page_attrs+0x254/0x360)
[   68.247862]  r10:00000040 r9:00000000 r8:c1bcb1e0 r7:c1205048 r6:c1bcb070 r5:00000000
[   68.247872]  r4:ffffffff
[   68.247905] [<c02a1d78>] (dma_map_page_attrs) from [<bf137750>] (lan743x_rx_init_ring_element+0xa0/0x1d0 [lan743x])
[   68.247919]  r10:c1bcb000 r9:ded46000 r8:ded46000 r7:c270ed70 r6:00000000 r5:00000000
[   68.247928]  r4:c3c20000
[   68.247959] [<bf1376b0>] (lan743x_rx_init_ring_element [lan743x]) from [<bf138948>] (lan743x_netdev_open+0x978/0x1300 [lan743x])
[   68.247973]  r10:c1205048 r9:c270e580 r8:c270ed70 r7:00000000 r6:00000000 r5:c270ed70
[   68.247983]  r4:c270e580
[   68.248009] [<bf137fd0>] (lan743x_netdev_open [lan743x]) from [<c09f71fc>] (__dev_open+0x108/0x1a4)
[   68.248023]  r10:00000000 r9:00000000 r8:c270e028 r7:bf13c024 r6:c1205048 r5:00000000
[   68.248033]  r4:c270e000
[   68.248052] [<c09f70f4>] (__dev_open) from [<c09f762c>] (__dev_change_flags+0x178/0x1d0)
[   68.248065]  r8:00001002 r7:c1205048 r6:00001043 r5:00000001 r4:c270e000
[   68.248085] [<c09f74b4>] (__dev_change_flags) from [<c09f76ac>] (dev_change_flags+0x28/0x58)
[   68.248098]  r9:00000000 r8:00008914 r7:c270e144 r6:00000000 r5:00001002 r4:c270e000
[   68.248118] [<c09f7684>] (dev_change_flags) from [<c0ab7690>] (devinet_ioctl+0x5f0/0x768)
[   68.248132]  r9:00000000 r8:00008914 r7:c272e50c r6:c1205048 r5:00000000 r4:c3ce7e40
[   68.248149] [<c0ab70a0>] (devinet_ioctl) from [<c0abb2ac>] (inet_ioctl+0x1e4/0x320)
[   68.248162]  r10:00000009 r9:be9d5a24 r8:c131e700 r7:c131e700 r6:00008914 r5:be9d5a24
[   68.248172]  r4:c1205048
[   68.248188] [<c0abb0c8>] (inet_ioctl) from [<c09ca31c>] (sock_ioctl+0x340/0x510)
[   68.248201]  r8:c131e700 r7:be9d5a24 r6:00008914 r5:c1205048 r4:00008914
[   68.248219] [<c09c9fdc>] (sock_ioctl) from [<c0443e84>] (sys_ioctl+0x280/0x8c8)
[   68.248233]  r9:be9d5a24 r8:00000000 r7:c3349840 r6:00008914 r5:c3349840 r4:c1205048
[   68.248250] [<c0443c04>] (sys_ioctl) from [<c0200040>] (ret_fast_syscall+0x0/0x28)
[   68.248261] Exception stack(0xc3ce7fa8 to 0xc3ce7ff0)
[   68.248275] 7fa0:                   0152cb08 00001043 00000009 00008914 be9d5a24 be9d5b00
[   68.248290] 7fc0: 0152cb08 00001043 0005dca0 00000036 431bde83 000f423f 3b9aca00 0152f158
[   68.248301] 7fe0: 0005dea4 be9d5a1c 0001ba6c b6ea251c
[   68.248316]  r10:00000036 r9:c3ce6000 r8:c0200204 r7:00000036 r6:0005dca0 r5:00001043
[   68.248326]  r4:0152cb08
[   68.248338] ---[ end trace 5e4455b751f391fa ]---
[   68.248355] lan743x_rx_init_ring_element dma_ptr check failed to map 9236 bytes @ 0xC33F4040
[   68.248411] lan743x 0000:01:00.0 eth1: lan743x_rx_open failed : -12, index : 0
[   68.265349] lan743x 0000:01:00.0 eth1: Error opening LAN743x

System
pi@raspberrypi:~ $ raspinfo
System Information

Raspberry Pi Compute Module 4 Rev 1.0
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"

Raspberry Pi reference 2021-01-11
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 21090519d85bdaa1615d5d5057d37b09368ea5d2, stage2

Linux raspberrypi 5.10.11-v7l+ #1 SMP Tue Feb 2 16:54:44 UTC 2021 armv7l GNU/Linux
Revision : b03140
Serial : 1000000023f4f9b4
Model : Raspberry Pi Compute Module 4 Rev 1.0
Throttled flag : throttled=0x0
Camera : supported=0 detected=0

Videocore information

Jan 8 2021 14:31:16
Copyright (c) 2012 Broadcom
version 194a85abd768c7334bbadc3f1911c10a7d18ed14 (clean) (release) (start)

alloc failures: 0
compactions: 0
legacy block fails: 0

Filesystem information

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 7220040 1615168 5279048 24% /
devtmpfs 823568 0 823568 0% /dev
tmpfs 955664 0 955664 0% /dev/shm
tmpfs 955664 8612 947052 1% /run
tmpfs 5120 4 5116 1% /run/lock
tmpfs 955664 0 955664 0% /sys/fs/cgroup
/dev/mmcblk0p1 258095 61626 196470 24% /boot
tmpfs 191132 0 191132 0% /run/user/1000

Filename Type Size Used Priority
/var/swap file 102396 0 -2

Package version information

raspberrypi-ui-mods:
Installed: (none)
raspberrypi-sys-mods:
Installed: 20201026
openbox:
Installed: (none)
lxpanel:
Installed: (none)
pcmanfm:
Installed: (none)
rpd-plym-splash:
Installed: (none)

Networking Information

eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether m.m.m.m txqueuelen 1000 (Ethernet)
RX packets 370 bytes 28608 (27.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 392 bytes 80454 (78.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet x.x.x.x netmask x.x.x.x broadcast x.x.x.x
inet6 y::y.y.y.y prefixlen 64 scopeid 0x20
ether m.m.m.m txqueuelen 1000 (Ethernet)
RX packets 1452043 bytes 2203006024 (2.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 30435 bytes 2142999 (2.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet x.x.x.x netmask x.x.x.x
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

USB Information

/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M

config.txt

arm_freq=1500
audio_pwm_mode=514
config_hdmi_boost=5
core_freq=500
core_freq_min=200
disable_commandline_tags=2
disable_l2cache=1
display_hdmi_rotate=-1
display_lcd_rotate=-1
enable_gic=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
gpu_freq=500
gpu_freq_min=250
ignore_lcd=1
init_uart_clock=0x2dc6c00
mask_gpu_interrupt0=3072
mask_gpu_interrupt1=25651
max_framebuffers=2
over_voltage_avs=-40000
pause_burst_frames=1
program_serial_random=1
total_mem=2048
hdmi_force_cec_address:0=65535
hdmi_force_cec_address:1=65535
hdmi_pixel_freq_limit:0=0x11e1a300
hdmi_pixel_freq_limit:1=0x11e1a300
device_tree=-
overlay_prefix=overlays/
hdmi_cvt:0=
hdmi_cvt:1=
hdmi_edid_filename:0=
hdmi_edid_filename:1=
hdmi_timings:0=
hdmi_timings:1=

cmdline.txt

coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 smsc95xx.macaddr=DC:A6:32:E2:C3:13 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=PARTUUID=a49b9582-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

raspi-gpio settings

BANK0 (GPIO 0 to 27):
GPIO 0: level=1 fsel=0 func=INPUT pull=UP
GPIO 1: level=1 fsel=0 func=INPUT pull=UP
GPIO 2: level=1 fsel=0 func=INPUT pull=UP
GPIO 3: level=1 fsel=0 func=INPUT pull=UP
GPIO 4: level=1 fsel=0 func=INPUT pull=UP
GPIO 5: level=1 fsel=1 func=OUTPUT pull=UP
GPIO 6: level=1 fsel=0 func=INPUT pull=UP
GPIO 7: level=1 fsel=0 func=INPUT pull=UP
GPIO 8: level=1 fsel=0 func=INPUT pull=UP
GPIO 9: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 10: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 11: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 12: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 13: level=1 fsel=1 func=OUTPUT pull=DOWN
GPIO 14: level=1 fsel=0 func=INPUT pull=NONE
GPIO 15: level=1 fsel=0 func=INPUT pull=UP
GPIO 16: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 17: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 18: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 19: level=1 fsel=1 func=OUTPUT pull=DOWN
GPIO 20: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 21: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 22: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 23: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 24: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 25: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 26: level=1 fsel=1 func=OUTPUT pull=DOWN
GPIO 27: level=0 fsel=0 func=INPUT pull=DOWN
BANK1 (GPIO 28 to 45):
GPIO 28: level=1 fsel=2 alt=5 func=RGMII_MDIO pull=UP
GPIO 29: level=0 fsel=2 alt=5 func=RGMII_MDC pull=DOWN
GPIO 30: level=1 fsel=7 alt=3 func=CTS0 pull=UP
GPIO 31: level=1 fsel=7 alt=3 func=RTS0 pull=NONE
GPIO 32: level=0 fsel=7 alt=3 func=TXD0 pull=NONE
GPIO 33: level=1 fsel=7 alt=3 func=RXD0 pull=UP
GPIO 34: level=0 fsel=7 alt=3 func=SD1_CLK pull=NONE
GPIO 35: level=1 fsel=7 alt=3 func=SD1_CMD pull=UP
GPIO 36: level=1 fsel=7 alt=3 func=SD1_DAT0 pull=UP
GPIO 37: level=1 fsel=7 alt=3 func=SD1_DAT1 pull=UP
GPIO 38: level=1 fsel=7 alt=3 func=SD1_DAT2 pull=UP
GPIO 39: level=1 fsel=7 alt=3 func=SD1_DAT3 pull=UP
GPIO 40: level=1 fsel=0 func=INPUT pull=NONE
GPIO 41: level=1 fsel=0 func=INPUT pull=NONE
GPIO 42: level=0 fsel=1 func=OUTPUT pull=NONE
GPIO 43: level=1 fsel=0 func=INPUT pull=NONE
GPIO 44: level=1 fsel=0 func=INPUT pull=NONE
GPIO 45: level=1 fsel=0 func=INPUT pull=NONE
BANK2 (GPIO 46 to 53):
GPIO 46: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 47: level=0 fsel=0 func=INPUT pull=DOWN
GPIO 48: level=0 fsel=4 alt=0 func=SD0_CLK pull=DOWN
GPIO 49: level=0 fsel=4 alt=0 func=SD0_CMD pull=DOWN
GPIO 50: level=0 fsel=4 alt=0 func=SD0_DAT0 pull=DOWN
GPIO 51: level=0 fsel=4 alt=0 func=SD0_DAT1 pull=DOWN
GPIO 52: level=0 fsel=4 alt=0 func=SD0_DAT2 pull=DOWN
GPIO 53: level=0 fsel=4 alt=0 func=SD0_DAT3 pull=DOWN

vcdbg log messages

004557.852: arasan: arasan_emmc_open
004746.113: brfs: File read: /mfs/sd/config.txt
004746.946: brfs: File read: 1896 bytes
004815.057: brfs: File read: /mfs/sd/config.txt
004815.832: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
004831.434: brfs: File read: 1896 bytes
004836.476: gpioman: gpioman_get_pin_num: pin FLASH_0_ENABLE not defined
004836.493: gpioman: gpioman_get_pin_num: pin FLASH_0_INDICATOR not defined
004836.526: gpioman: gpioman_get_pin_num: pin FLASH_0_ENABLE not defined
004836.541: gpioman: gpioman_get_pin_num: pin FLASH_0_INDICATOR not defined
005292.008: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
005293.289: *** Restart logging
005298.462: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
005301.835: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
005301.849: HDMI0: hdmi_pixel_encoding: 300000000
005301.863: HDMI1: hdmi_pixel_encoding: 300000000
005302.350: gpioman: gpioman_get_pin_num: pin CAMERA_0_SDA_PIN not defined
005302.366: gpioman: gpioman_get_pin_num: pin CAMERA_0_SCL_PIN not defined
005302.382: gpioman: gpioman_get_pin_num: pin CAMERA_0_I2C_PORT not defined
005306.643: dtb_file 'bcm2711-rpi-cm4.dtb'
005312.558: brfs: File read: /mfs/sd/bcm2711-rpi-cm4.dtb
005312.573: Loading 'bcm2711-rpi-cm4.dtb' to 0x100 size 0xbd85
005324.882: brfs: File read: 48517 bytes
005331.544: brfs: File read: /mfs/sd/overlays/overlay_map.dtb
005391.263: brfs: File read: 1523 bytes
005393.018: brfs: File read: /mfs/sd/config.txt
005393.495: dtparam: audio=on
005403.160: brfs: File read: 1896 bytes
005410.980: brfs: File read: /mfs/sd/overlays/vc4-fkms-v3d.dtbo
005427.719: Loaded overlay 'vc4-fkms-v3d'
005462.189: brfs: File read: 1446 bytes
005464.586: brfs: File read: /mfs/sd/overlays/dwc2.dtbo
005470.271: Loaded overlay 'dwc2'
005470.283: dtparam: dr_mode=host
005480.306: brfs: File read: 801 bytes
005487.343: brfs: File read: /mfs/sd/overlays/panel-auo-h139bln01_2-0.dtbo
005496.633: Loaded overlay 'panel-auo-h139bln01_2-0'
005514.449: brfs: File read: 1259 bytes
005522.366: brfs: File read: /mfs/sd/overlays/vc4-kms-v3d-pi4.dtbo
005580.802: Loaded overlay 'vc4-kms-v3d'
005734.241: brfs: File read: 3710 bytes
005735.475: brfs: File read: /mfs/sd/cmdline.txt
005735.514: Read command line from file 'cmdline.txt':
005735.528: 'console=serial0,115200 console=tty1 root=PARTUUID=a49b9582-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait'
006786.166: brfs: File read: 121 bytes
007394.932: brfs: File read: /mfs/sd/kernel7l.img
007394.954: Loading 'kernel7l.img' to 0x8000 size 0x65ec68
007394.978: Device tree loaded to 0x2eff3b00 (size 0xc440)
007401.308: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
010110.470: vchiq_core: vchiq_init_state: slot_zero = 0xded00000, is_master = 1

dmesg log

Note this is with the fix applied, see above for the error.

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.10.11-v7l+ (dan@melon) (arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0, GNU ld (GNU Binutils for Ubuntu) 2.30) #1 SMP Tue Feb 2 16:54:44 UTC 2021
[    0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=30c5383d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: Raspberry Pi Compute Module 4 Rev 1.0
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Reserved memory: created CMA memory pool at 0x000000001ec00000, size 256 MiB
[    0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000]   Normal   empty
[    0.000000]   HighMem  [mem 0x0000000030000000-0x000000007fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000003b3fffff]
[    0.000000]   node   0: [mem 0x0000000040000000-0x000000007fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000007fffffff]
[    0.000000] On node 0 totalpages: 504832
[    0.000000]   DMA zone: 2304 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 196608 pages, LIFO batch:63
[    0.000000]   HighMem zone: 308224 pages, LIFO batch:63
[    0.000000] percpu: Embedded 20 pages/cpu s50700 r8192 d23028 u81920
[    0.000000] pcpu-alloc: s50700 r8192 d23028 u81920 alloc=20*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 502528
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1  smsc95xx.macaddr=m.m.m.m vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  console=ttyS0,115200 console=tty1 root=PARTUUID=a49b9582-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[    0.000000] Kernel parameter elevator= does not have any effect anymore.
               Please use sysfs to set IO scheduler for individual devices.
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: mapped [mem 0x0000000019400000-0x000000001d400000] (64MB)
[    0.000000] Memory: 1647140K/2019328K available (10240K kernel code, 1354K rwdata, 3148K rodata, 2048K init, 893K bss, 110044K reserved, 262144K cma-reserved, 1232896K highmem)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] ftrace: allocating 33809 entries in 67 pages
[    0.000000] ftrace: allocated 67 pages with 3 groups
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000]  Rude variant of Tasks RCU enabled.
[    0.000000]  Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] random: get_random_bytes called from start_kernel+0x3c8/0x59c with crng_init=0
[    0.000008] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
[    0.000035] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[    0.000100] bcm2835: system timer (irq = 25)
[    0.000754] arch_timer: cp15 timer(s) running at 54.00MHz (phys).
[    0.000776] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xc743ce346, max_idle_ns: 440795203123 ns
[    0.000800] sched_clock: 56 bits at 54MHz, resolution 18ns, wraps every 4398046511102ns
[    0.000818] Switching to timer-based delay loop, resolution 18ns
[    0.001078] Console: colour dummy device 80x30
[    0.001826] printk: console [tty1] enabled
[    0.001892] Calibrating delay loop (skipped), value calculated using timer frequency.. 108.00 BogoMIPS (lpj=540000)
[    0.001947] pid_max: default: 32768 minimum: 301
[    0.002130] LSM: Security Framework initializing
[    0.002330] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.002377] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[    0.003874] Disabling memory control group subsystem
[    0.004010] CPU: Testing write buffer coherency: ok
[    0.004486] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.005729] Setting up static identity map for 0x200000 - 0x20003c
[    0.005947] rcu: Hierarchical SRCU implementation.
[    0.006899] smp: Bringing up secondary CPUs ...
[    0.008159] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.009555] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[    0.011003] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[    0.011160] smp: Brought up 1 node, 4 CPUs
[    0.011207] SMP: Total of 4 processors activated (432.00 BogoMIPS).
[    0.011237] CPU: All CPU(s) started in HYP mode.
[    0.011263] CPU: Virtualization extensions available.
[    0.012123] devtmpfs: initialized
[    0.025965] VFP support v0.3: implementor 41 architecture 3 part 40 variant 8 rev 0
[    0.026228] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.026281] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[    0.033502] pinctrl core: initialized pinctrl subsystem
[    0.034614] NET: Registered protocol family 16
[    0.038787] DMA: preallocated 1024 KiB pool for atomic coherent allocations
[    0.039570] audit: initializing netlink subsys (disabled)
[    0.039859] audit: type=2000 audit(0.030:1): state=initialized audit_enabled=0 res=1
[    0.040428] thermal_sys: Registered thermal governor 'step_wise'
[    0.041139] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
[    0.041194] hw-breakpoint: maximum watchpoint size is 8 bytes.
[    0.041605] Serial: AMBA PL011 UART driver
[    0.087741] bcm2835-mbox fe00b880.mailbox: mailbox enabled
[    0.100926] raspberrypi-firmware soc:firmware: Attached to firmware from 2021-01-08T14:31:16, variant start
[    0.110940] raspberrypi-firmware soc:firmware: Firmware hash is 194a85abd768c7334bbadc3f1911c10a7d18ed14
[    0.155936] bcm2835-dma fe007000.dma: DMA legacy API manager, dmachans=0x1
[    0.160292] vgaarb: loaded
[    0.160758] SCSI subsystem initialized
[    0.161349] usbcore: registered new interface driver usbfs
[    0.161428] usbcore: registered new interface driver hub
[    0.161519] usbcore: registered new device driver usb
[    0.161936] usb_phy_generic phy: supply vcc not found, using dummy regulator
[    0.163844] clocksource: Switched to clocksource arch_sys_counter
[    1.338038] VFS: Disk quotas dquot_6.6.0
[    1.338172] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.338374] FS-Cache: Loaded
[    1.338568] CacheFiles: Loaded
[    1.347695] NET: Registered protocol family 2
[    1.348590] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[    1.348752] TCP established hash table entries: 8192 (order: 3, 32768 bytes, linear)
[    1.348839] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    1.348924] TCP: Hash tables configured (established 8192 bind 8192)
[    1.349102] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[    1.349158] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[    1.349437] NET: Registered protocol family 1
[    1.350227] RPC: Registered named UNIX socket transport module.
[    1.350261] RPC: Registered udp transport module.
[    1.350290] RPC: Registered tcp transport module.
[    1.350318] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.350356] PCI: CLS 0 bytes, default 64
[    1.353418] Initialise system trusted keyrings
[    1.353688] workingset: timestamp_bits=14 max_order=19 bucket_order=5
[    1.361971] zbud: loaded
[    1.363985] FS-Cache: Netfs 'nfs' registered for caching
[    1.364770] NFS: Registering the id_resolver key type
[    1.364822] Key type id_resolver registered
[    1.364851] Key type id_legacy registered
[    1.365017] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    1.366056] Key type asymmetric registered
[    1.366088] Asymmetric key parser 'x509' registered
[    1.366293] bounce: pool size: 64 pages
[    1.366365] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[    1.366610] io scheduler mq-deadline registered
[    1.366642] io scheduler kyber registered
[    1.371218] gpio-507 (ant1): hogged as output/high
[    1.372669] gpio-511 (ant2): hogged as output/low
[    1.374337] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
[    1.374389] brcm-pcie fd500000.pcie:   No bus range found for /scb/pcie@7d500000, using [bus 00-ff]
[    1.374491] brcm-pcie fd500000.pcie:      MEM 0x0600000000..0x063fffffff -> 0x00c0000000
[    1.374602] brcm-pcie fd500000.pcie:   IB MEM 0x0000000000..0x007fffffff -> 0x0400000000
[    1.405989] brcm-pcie fd500000.pcie: link up, 2.5 GT/s PCIe x1 (SSC)
[    1.406395] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
[    1.406432] pci_bus 0000:00: root bus resource [bus 00-ff]
[    1.406469] pci_bus 0000:00: root bus resource [mem 0x600000000-0x63fffffff] (bus address [0xc0000000-0xffffffff])
[    1.406578] pci 0000:00:00.0: [14e4:2711] type 01 class 0x060400
[    1.406840] pci 0000:00:00.0: PME# supported from D0 D3hot
[    1.410261] PCI: bus0: Fast back to back transfers disabled
[    1.410302] pci 0000:00:00.0: bridge configuration invalid ([bus ff-ff]), reconfiguring
[    1.410598] pci 0000:01:00.0: [1055:7430] type 00 class 0x020000
[    1.410697] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00001fff 64bit]
[    1.410768] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x000000ff 64bit]
[    1.410838] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x000000ff 64bit]
[    1.411159] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
[    1.414502] PCI: bus1: Fast back to back transfers disabled
[    1.414540] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[    1.414643] pci 0000:00:00.0: BAR 8: assigned [mem 0x600000000-0x6000fffff]
[    1.414698] pci 0000:01:00.0: BAR 0: assigned [mem 0x600000000-0x600001fff 64bit]
[    1.414769] pci 0000:01:00.0: BAR 2: assigned [mem 0x600002000-0x6000020ff 64bit]
[    1.414838] pci 0000:01:00.0: BAR 4: assigned [mem 0x600002100-0x6000021ff 64bit]
[    1.414910] pci 0000:00:00.0: PCI bridge to [bus 01]
[    1.414950] pci 0000:00:00.0:   bridge window [mem 0x600000000-0x6000fffff]
[    1.415362] pcieport 0000:00:00.0: enabling device (0140 -> 0142)
[    1.415595] pcieport 0000:00:00.0: PME: Signaling with IRQ 71
[    1.425001] iproc-rng200 fe104000.rng: hwrng registered
[    1.425383] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[    1.426294] gpiomem-bcm2835 fe200000.gpiomem: Initialised: Registers at 0xfe200000
[    1.439440] brd: module loaded
[    1.451648] loop: module loaded
[    1.453393] Loading iSCSI transport class v2.0-870.
[    1.455949] libphy: Fixed MDIO Bus: probed
[    1.457400] bcmgenet fd580000.ethernet: GENET 5.0 EPHY: 0x0000
[    1.473925] libphy: bcmgenet MII bus: probed
[    1.553988] unimac-mdio unimac-mdio.-19: Broadcom UniMAC MDIO bus
[    1.555154] usbcore: registered new interface driver r8152
[    1.555239] usbcore: registered new interface driver lan78xx
[    1.555329] usbcore: registered new interface driver smsc95xx
[    1.556019] dwc_otg: version 3.00a 10-AUG-2012 (platform bus)
[    1.556399] dwc_otg: FIQ enabled
[    1.556414] dwc_otg: NAK holdoff enabled
[    1.556429] dwc_otg: FIQ split-transaction FSM enabled
[    1.556448] Module dwc_common_port init
[    1.556864] usbcore: registered new interface driver uas
[    1.556944] usbcore: registered new interface driver usb-storage
[    1.557171] mousedev: PS/2 mouse device common for all mice
[    1.558945] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[    1.562653] sdhci: Secure Digital Host Controller Interface driver
[    1.562689] sdhci: Copyright(c) Pierre Ossman
[    1.563470] mmc-bcm2835 fe300000.mmcnr: could not get clk, deferring probe
[    1.564244] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.567262] ledtrig-cpu: registered to indicate activity on CPUs
[    1.567628] hid: raw HID events driver (C) Jiri Kosina
[    1.567822] usbcore: registered new interface driver usbhid
[    1.567852] usbhid: USB HID core driver
[    1.574100] Initializing XFRM netlink socket
[    1.574164] NET: Registered protocol family 17
[    1.574299] Key type dns_resolver registered
[    1.574663] Registering SWP/SWPB emulation handler
[    1.574858] registered taskstats version 1
[    1.574898] Loading compiled-in X.509 certificates
[    1.575748] Key type ._fscrypt registered
[    1.575779] Key type .fscrypt registered
[    1.575807] Key type fscrypt-provisioning registered
[    1.587706] uart-pl011 fe201000.serial: there is not valid maps for state default
[    1.588032] uart-pl011 fe201000.serial: cts_event_workaround enabled
[    1.588125] fe201000.serial: ttyAMA0 at MMIO 0xfe201000 (irq = 37, base_baud = 0) is a PL011 rev2
[    1.594949] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[    1.596033] mmc-bcm2835 fe300000.mmcnr: mmc_debug:0 mmc_debug2:0
[    1.596068] mmc-bcm2835 fe300000.mmcnr: DMA channel allocated
[    1.625206] of_cfs_init
[    1.625494] of_cfs_init: OK
[    1.661499] mmc0: SDHCI controller on fe340000.emmc2 [fe340000.emmc2] using ADMA
[    1.662522] Waiting for root device PARTUUID=a49b9582-02...
[    1.730350] mmc0: new DDR MMC card at address 0001
[    1.731347] mmcblk0: mmc0:0001 8GTF4R 7.28 GiB
[    1.731861] mmcblk0boot0: mmc0:0001 8GTF4R partition 1 4.00 MiB
[    1.732396] mmcblk0boot1: mmc0:0001 8GTF4R partition 2 4.00 MiB
[    1.732645] mmcblk0rpmb: mmc0:0001 8GTF4R partition 3 512 KiB, chardev (245:0)
[    1.736526]  mmcblk0: p1 p2
[    1.754934] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[    1.755032] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    1.759241] devtmpfs: mounted
[    1.768153] Freeing unused kernel memory: 2048K
[    1.814167] Run /sbin/init as init process
[    1.814196]   with arguments:
[    1.814211]     /sbin/init
[    1.814226]   with environment:
[    1.814240]     HOME=/
[    1.814254]     TERM=linux
[    1.873413] random: fast init done
[    2.065341] systemd[1]: System time before build time, advancing clock.
[    2.138324] NET: Registered protocol family 10
[    2.139836] Segment Routing with IPv6
[    2.190395] systemd[1]: systemd 241 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[    2.191227] systemd[1]: Detected architecture arm.
[    2.244205] systemd[1]: Set hostname to <raspberrypi>.
[    2.816442] random: systemd: uninitialized urandom read (16 bytes read)
[    2.825849] random: systemd: uninitialized urandom read (16 bytes read)
[    2.826425] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[    2.827072] random: systemd: uninitialized urandom read (16 bytes read)
[    2.828000] systemd[1]: Listening on Journal Socket.
[    2.828988] systemd[1]: Condition check resulted in Huge Pages File System being skipped.
[    2.829706] systemd[1]: Listening on Journal Socket (/dev/log).
[    2.830460] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[    2.830914] systemd[1]: Reached target Paths.
[    2.839191] systemd[1]: Starting Create list of required static device nodes for the current kernel...
[    3.375773] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    3.507234] systemd-journald[128]: Received request to flush runtime journal from PID 1
[    3.939309] rpivid-mem feb00000.hevc-decoder: rpivid-hevcmem initialised: Registers at 0xfeb00000 length 0x00010000
[    3.939854] rpivid-mem feb10000.rpivid-local-intc:pi@raspberrypi:~ $  rpivid-intcmem initialised: Registers at 0xfeb10000 length 0x00001000
[    3.940504] rpivid-mem feb20000.h264-decoder: rpivid-h264mem initialised: Registers at 0xfeb20000 length 0x00010000
[    3.941229] rpivid-mem feb30000.vp9-decoder: rpivid-vp9mem initialised: Registers at 0xfeb30000 length 0x00010000
[    3.993269] lan743x: loading out-of-tree module taints kernel.
[    4.013816] lan743x 0000:01:00.0: enabling device (0140 -> 0142)
[    4.013982] lan743x 0000:01:00.0 (unnamed net_device) (uninitialized): PCI: Vendor ID = 0x1055, Device ID = 0x7430
[    4.015561] lan743x 0000:01:00.0 (unnamed net_device) (uninitialized): ID_REV = 0x74300011, FPGA_REV = 0.0
[    4.016821] lan743x 0000:01:00.0 (unnamed net_device) (uninitialized): MAC address set to m.m.m.m
[    4.022463] mc: Linux media interface: v0.10
[    4.025815] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[    4.027816] pinctrl-bcm2835 fe200000.gpio: /soc/gpio@7e200000/audio_pins: missing brcm,pins property
[    4.027856] bcm2835_audio: probe of bcm2835_audio failed with error -22
[    4.044768] videodev: Linux video capture interface: v2.00
[    4.063351] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[    4.077413] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[    4.077442] [vc_sm_connected_init]: start
[    4.088244] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[    4.095104] vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
[    4.106889] [vc_sm_connected_init]: installed successfully
[    4.109106] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[    4.111979] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[    4.115221] bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
[    4.117891] libphy: lan743x-mdiobus: probed
[    4.119487] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[    4.148665] bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video13
[    4.149240] bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video14
[    4.149347] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[    4.150071] bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video15
[    4.150440] bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video16
[    4.150482] bcm2835-isp bcm2835-isp: Register output node 0 with media controller
[    4.150517] bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
[    4.150547] bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
[    4.150569] bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
[    4.150781] bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp
[    4.203291] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[    4.203377] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[    4.213968] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[    4.214018] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[    4.232386] brcmstb-i2c fef04500.i2c:  @97500hz registered in polling mode
[    4.233549] brcmstb-i2c fef09500.i2c:  @97500hz registered in polling mode
[    4.235601] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[    4.235653] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[    4.323881] dwc2 fe980000.usb: supply vusb_d not found, using dummy regulator
[    4.324164] dwc2 fe980000.usb: supply vusb_a not found, using dummy regulator
[    4.381307] dwc2 fe980000.usb: DWC OTG Controller
[    4.381350] dwc2 fe980000.usb: new USB bus registered, assigned bus number 1
[    4.381408] dwc2 fe980000.usb: irq 40, io mem 0xfe980000
[    4.381892] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.10
[    4.381913] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    4.381931] usb usb1: Product: DWC OTG Controller
[    4.381949] usb usb1: Manufacturer: Linux 5.10.11-v7l+ dwc2_hsotg
[    4.381965] usb usb1: SerialNumber: fe980000.usb
[    4.382928] hub 1-0:1.0: USB hub found
[    4.383014] hub 1-0:1.0: 1 port detected
[    4.404173] Registered IR keymap rc-cec
[    4.404330] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    4.404570] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
[    4.405534] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    4.410368] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    4.415520] Registered IR keymap rc-cec
[    4.415683] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    4.415969] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input1
[    4.424208] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    4.434849] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    4.447860] [drm] Initialized v3d 1.0.0 20180419 for fec00000.v3d on minor 1
[    4.683488] Registered IR keymap rc-cec
[    4.683648] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    4.683905] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input2
[    4.684696] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    4.688260] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    4.689818] Registered IR keymap rc-cec
[    4.689967] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    4.690179] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input3
[    4.690965] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    4.692915] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    4.814008] usb 1-1: new high-speed USB device number 2 using dwc2
[    4.925496] Registered IR keymap rc-cec
[    4.925654] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[    4.925916] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input4
[    4.926739] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi-0' already present!
[    4.928457] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[    4.929239] Registered IR keymap rc-cec
[    4.929391] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[    4.929608] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input5
[    4.930444] debugfs: Directory 'fef05700.hdmi' with parent 'vc4-hdmi-1' already present!
[    4.935027] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[    4.936480] vc4-drm gpu: bound fe209000.dsi (ops vc4_dsi_ops [vc4])
[    4.936803] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[    4.937173] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[    4.937517] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[    4.937854] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[    4.938165] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[    4.938430] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[    4.938784] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops [vc4])
[    4.973951] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[    5.065267] usb 1-1: New USB device found, idVendor=0424, idProduct=2514, bcdDevice= b.b3
[    5.065295] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    5.066060] hub 1-1:1.0: USB hub found
[    5.066183] hub 1-1:1.0: 4 ports detected
[    6.083900] vc4_dsi fe209000.dsi: transfer interrupt wait timeout
[    6.083918] vc4_dsi fe209000.dsi: instat: 0x00000000
[    6.084013] [drm:vc4_dsi_host_transfer [vc4]] *ERROR* DSI transfer failed, resetting: -110
[    6.084037] panel-auo-h139bln01_2 fe209000.dsi.0: MIPI DSI DCS write failed: -110
[    7.113871] vc4_dsi fe209000.dsi: transfer interrupt wait timeout
[    7.113887] vc4_dsi fe209000.dsi: instat: 0x00000000
[    7.113979] [drm:vc4_dsi_host_transfer [vc4]] *ERROR* DSI transfer failed, resetting: -110
[    7.114000] panel-auo-h139bln01_2 fe209000.dsi.0: MIPI DSI DCS write failed: -110
[    8.153884] vc4_dsi fe209000.dsi: transfer interrupt wait timeout
[    8.153900] vc4_dsi fe209000.dsi: instat: 0x00000000
[    8.153986] [drm:vc4_dsi_host_transfer [vc4]] *ERROR* DSI transfer failed, resetting: -110
[    8.154006] panel-auo-h139bln01_2 fe209000.dsi.0: MIPI DSI DCS write failed: -110
[    9.193871] vc4_dsi fe209000.dsi: transfer interrupt wait timeout
[    9.193887] vc4_dsi fe209000.dsi: instat: 0x00000000
[    9.193972] [drm:vc4_dsi_host_transfer [vc4]] *ERROR* DSI transfer failed, resetting: -110
[    9.193991] panel-auo-h139bln01_2 fe209000.dsi.0: MIPI DSI DCS write failed: -110
[   10.233875] vc4_dsi fe209000.dsi: transfer interrupt wait timeout
[   10.233891] vc4_dsi fe209000.dsi: instat: 0x00000000
[   10.233978] [drm:vc4_dsi_host_transfer [vc4]] *ERROR* DSI transfer failed, resetting: -110
[   10.233998] panel-auo-h139bln01_2 fe209000.dsi.0: MIPI DSI DCS write failed: -110
[   11.273870] vc4_dsi fe209000.dsi: transfer interrupt wait timeout
[   11.273886] vc4_dsi fe209000.dsi: instat: 0x00000000
[   11.273968] [drm:vc4_dsi_host_transfer [vc4]] *ERROR* DSI transfer failed, resetting: -110
[   11.273988] panel-auo-h139bln01_2 fe209000.dsi.0: MIPI DSI DCS write failed: -110
[   12.313870] vc4_dsi fe209000.dsi: transfer interrupt wait timeout
[   12.313885] vc4_dsi fe209000.dsi: instat: 0x00000000
[   12.313967] [drm:vc4_dsi_host_transfer [vc4]] *ERROR* DSI transfer failed, resetting: -110
[   12.313986] panel-auo-h139bln01_2 fe209000.dsi.0: MIPI DSI DCS write failed: -110
[   13.353870] vc4_dsi fe209000.dsi: transfer interrupt wait timeout
[   13.353885] vc4_dsi fe209000.dsi: instat: 0x00000000
[   13.353968] [drm:vc4_dsi_host_transfer [vc4]] *ERROR* DSI transfer failed, resetting: -110
[   13.353987] panel-auo-h139bln01_2 fe209000.dsi.0: MIPI DSI DCS write failed: -110
[   14.393870] vc4_dsi fe209000.dsi: transfer interrupt wait timeout
[   14.393886] vc4_dsi fe209000.dsi: instat: 0x00000000
[   14.393966] [drm:vc4_dsi_host_transfer [vc4]] *ERROR* DSI transfer failed, resetting: -110
[   14.393986] panel-auo-h139bln01_2 fe209000.dsi.0: MIPI DSI DCS write failed: -110
[   15.433870] vc4_dsi fe209000.dsi: transfer interrupt wait timeout
[   15.433885] vc4_dsi fe209000.dsi: instat: 0x00000000
[   15.433965] [drm:vc4_dsi_host_transfer [vc4]] *ERROR* DSI transfer failed, resetting: -110
[   15.433983] panel-auo-h139bln01_2 fe209000.dsi.0: mipi_dsi_dcs_exit_sleep_mode: -110
[   26.073968] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:69:crtc-2] flip_done timed out
[   26.074263] Console: switching to colour frame buffer device 50x25
[   36.313964] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:69:crtc-2] flip_done timed out
[   46.553959] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:42:DSI-1] flip_done timed out
[   56.793955] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:63:plane-2] flip_done timed out
[   67.033973] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:69:crtc-2] flip_done timed out
[   67.035148] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
[   67.761666] 8021q: 802.1Q VLAN Support v1.8
[   67.987758] uart-pl011 fe201000.serial: no DMA platform data
[   67.989174] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[   68.000106] random: crng init done
[   68.000129] random: 7 urandom warning(s) missed due to ratelimiting
[   68.087395] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   68.214166] Adding 102396k swap on /var/swap.  Priority:-2 extents:1 across:102396k SSFS
[   68.237128] bcmgenet fd580000.ethernet: configuring instance for external RGMII (RX delay)
[   68.237632] bcmgenet fd580000.ethernet eth0: Link is Down
[   68.239304] lan743x 0000:01:00.0 eth1: using MSIX interrupts, number of vectors = 6
[   68.254862] lan743x 0000:01:00.0 eth1: Link is Down
[   72.394142] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   72.394194] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[  164.951161] bcmgenet fd580000.ethernet eth0: Link is Down
[  169.111125] lan743x 0000:01:00.0 eth1: Link is Up - 1Gbps/Full - flow control rx/tx
[  169.111175] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

Additional context
Though it may not be the complete solution this allows the module to work. Note line numbers are likely off as this is a subset of the patch with a load of printks removed.

diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
index 8947c3a62..0bf25e03c 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -2318,6 +2322,13 @@ static int lan743x_rx_ring_init(struct lan743x_rx *rx)
                ret = -EINVAL;
                goto cleanup;
        }
+       
+       if (dma_set_mask_and_coherent(&rx->adapter->pdev->dev, DMA_BIT_MASK(64))) {
+               dev_warn(&rx->adapter->pdev->dev, "lan743x_: No suitable DMA available\n");
+        ret = -ENOMEM;
+        goto cleanup;
+    }
+       
        ring_allocation_size = ALIGN(rx->ring_size *
                                     sizeof(struct lan743x_rx_descriptor),
                                     PAGE_SIZE);
@martinum4
Copy link

can confirm this bug, EVB-LAN7430 is not recognized correctly and needs fixing.
Unfortunately i'm too dumb to compile the kernel correctly and thus can't confirm the fix.

@6by9
Copy link
Contributor

6by9 commented Feb 28, 2021

The lan743x driver is unmodified from mainline so any real bugs ought to be reported upstream and fixed there.

That said, the patch feels like the default mask is incorrect as I wouldn't have expected individual drivers to need patching like this. @pelwell may know what those defaults will be/how it is initialised.

LPAE extensions do confuse matters significantly between 32 and 64 bit systems though. Does it work on the 64bit kernel?

@martinum4
Copy link

LPAE extensions do confuse matters significantly between 32 and 64 bit systems though. Does it work on the 64bit kernel?

Tried with Ubuntu Server ARM (uname -a -> Linux ubuntu 5.4.0-1028-raspi #31-Ubuntu SMP PREEMPT Wed Jan 20 11:30:45 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux), not working either.

@mangodan2003
Copy link
Author

The lan743x driver is unmodified from mainline so any real bugs ought to be reported upstream and fixed there.

That said, the patch feels like the default mask is incorrect as I wouldn't have expected individual drivers to need patching like this. @pelwell may know what those defaults will be/how it is initialised.

LPAE extensions do confuse matters significantly between 32 and 64 bit systems though. Does it work on the 64bit kernel?

Last I tried to boot a 64Bit kernel it hung waiting for the root device and I haven't tried again since. I will so so when I get a spare moment.

@mangodan2003
Copy link
Author

I've now tested 5.10.17 64bit. Doesn't work out of the box. Works with the above fix applied.

@aep
Copy link

aep commented Apr 13, 2021

patch works for me with 5.10.27-v8+

@gnijieb
Copy link

gnijieb commented Jul 30, 2021

Any updates on this issue? Is the above fix deemed good enough to be used in production?

Backporting all the lan743x changes from mainline to the rpi-5.10.y branch did not fix the issue.

Can confirm the issue and the fix.

@pelwell
Copy link
Contributor

pelwell commented Jul 30, 2021

As @6by9 rightly said:

The lan743x driver is unmodified from mainline so any real bugs ought to be reported upstream and fixed there.

fengguang pushed a commit to 0day-ci/linux that referenced this issue Oct 24, 2021
…g dma_set_mask_and_coherent

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
woodsts pushed a commit to woodsts/linux-stable that referenced this issue Nov 2, 2021
…g dma_set_mask_and_coherent

commit 95a359c upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Nov 2, 2021
…g dma_set_mask_and_coherent

commit 95a359c upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Nov 2, 2021
…g dma_set_mask_and_coherent

commit 95a359c upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Whissi pushed a commit to Whissi/linux-stable that referenced this issue Nov 2, 2021
…g dma_set_mask_and_coherent

commit 95a359c upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
miraclestars pushed a commit to miraclestars/android_kernel_samsung_sm8250 that referenced this issue Nov 3, 2021
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
freeza-inc pushed a commit to freeza-inc/bm-galaxy-s20-ultra-snap-r that referenced this issue Nov 6, 2021
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
ZenkaBestia pushed a commit to NusantaraROM-Devices/kernel_xiaomi_lmi that referenced this issue Nov 11, 2021
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
it-is-a-robot pushed a commit to openeuler-mirror/kernel that referenced this issue Nov 16, 2021
…g dma_set_mask_and_coherent

stable inclusion
from stable-5.10.77
commit c2af2092c9bbb33c0131a8aca5b8f6db7c223d08
bugzilla: 185677 https://gitee.com/openeuler/kernel/issues/I4IAP7

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c2af2092c9bbb33c0131a8aca5b8f6db7c223d08

--------------------------------

commit 95a359c upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Chen Jun <[email protected]>
Acked-by: Weilong Chen <[email protected]>

Signed-off-by: Chen Jun <[email protected]>
Signed-off-by: Zheng Zengkai <[email protected]>
jpuhlman pushed a commit to MontaVista-OpenSourceTechnology/linux-mvista that referenced this issue Nov 16, 2021
…g dma_set_mask_and_coherent

Source: Kernel.org
MR: 113846
Type: Integration
Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.4.y
ChangeID: b232898c1d4bcade408a0a84229211c5fae5ab5f
Description:

commit 95a359c upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Armin Kuster <[email protected]>
chandu078 pushed a commit to Havoc-Devices/kernel_oneplus_sm8250 that referenced this issue Jan 5, 2022
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
melles1991 pushed a commit to CraftRom/Chidori-Kernel_chime that referenced this issue Jan 15, 2022
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
oraclelinuxkernel pushed a commit to oracle/linux-uek that referenced this issue Jan 21, 2022
…g dma_set_mask_and_coherent

commit 95a359c upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
(cherry picked from commit b232898c1d4bcade408a0a84229211c5fae5ab5f)
Signed-off-by: Sherry Yang <[email protected]>
haridhayal11 pushed a commit to haridhayal11/android_kernel_samsung_exynos2100 that referenced this issue Jan 23, 2022
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Matombo pushed a commit to tuxedocomputers/linux that referenced this issue Jan 26, 2022
…g dma_set_mask_and_coherent

BugLink: https://bugs.launchpad.net/bugs/1952665

commit 95a359c upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
Signed-off-by: Kelsey Skunberg <[email protected]>
delphix-devops-bot pushed a commit to delphix/linux-kernel-oracle that referenced this issue Feb 2, 2022
…g dma_set_mask_and_coherent

BugLink: https://bugs.launchpad.net/bugs/1952785

commit 95a359c upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
Signed-off-by: Stefan Bader <[email protected]>
DozNaka pushed a commit to DozNaka/KawaKernel-A217X that referenced this issue Apr 10, 2022
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
hellobbn pushed a commit to hellobbn/android_kernel_sony_sm8250 that referenced this issue Jul 21, 2022
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
@user-redans
Copy link

user-redans commented Aug 23, 2022

Hello,

I ' ve used this driver on my RPI kernel version:

root@raspberrypi:~# uname -a
Linux raspberrypi 5.10.17-v7l+ #1403 SMP Mon Feb 22 11:33:35 GMT 2021 armv7l GNU/Linux

And it's works !

But, when I 've tried to another RPI, with another kernel version:

raspberrypi:/home/pi# uname -a
Linux raspberrypi 5.15.32-v7l+ #1538 SMP Thu Mar 31 19:39:41 BST 2022 armv7l GNU/Linux

It doesn't work! System can 't find my module and of course.... I can't start it with modprobe:

raspberrypi:/home/pi# modprobe lan743x
modprobe: FATAL: Module lan743x not found in directory /lib/modules/5.15.32-v7l+

raspberrypi:/lib/modules/5.15.32-v7l+/kernel/drivers/net/ethernet/microchip# modinfo lan743x
modinfo: ERROR: Module lan743x not found.
raspberrypi:/lib/modules/5.15.32-v7l+/kernel/drivers/net/ethernet/microchip# ll
total 84
-rw-r--r-- 1 root root 32308 Mar 31 22:40 enc28j60.ko
-rw-r--r-- 1 root root 52828 Jul 30 15:20 lan743x.ko

NOTE: That lan743x.ko is the same for both kernel versions.... Do I have to re-compile this patch ( lan743x_main.c file) for every versions?

@pelwell
Copy link
Contributor

pelwell commented Aug 23, 2022

Do I have to re-compile this patch ( lan743x_main.c file) for every versions?

Yes, you do.

@user-redans
Copy link

Ok, but how can I re-compile for a new kernel version?

When I compile with make command, I' ve received this:

raspberrypi:/home/pi/lan743x# make
make: *** No targets. Stop.

This is my lan743x directory:

raspberrypi:/home/pi/lan743x# ll
total 96
-rw-r--r-- 1 pi pi 1494 May 26 2021 Kconfig
-rw-r--r-- 1 pi pi 86947 May 26 2021 lan743x_main.c
-rw-r--r-- 1 pi pi 317 Aug 23 11:09 Makefile

popcornmix pushed a commit that referenced this issue Sep 20, 2022
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue Sep 20, 2022
popcornmix pushed a commit that referenced this issue Sep 26, 2022
popcornmix pushed a commit that referenced this issue Sep 26, 2022
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue Sep 28, 2022
popcornmix pushed a commit that referenced this issue Oct 3, 2022
popcornmix pushed a commit that referenced this issue Oct 5, 2022
popcornmix pushed a commit that referenced this issue Oct 12, 2022
popcornmix pushed a commit that referenced this issue Oct 12, 2022
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue Oct 12, 2022
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue Oct 12, 2022
popcornmix pushed a commit that referenced this issue Oct 17, 2022
popcornmix pushed a commit that referenced this issue Oct 17, 2022
popcornmix pushed a commit that referenced this issue Oct 25, 2022
developerjuan729 pushed a commit to developerjuan729/android_kernel_msm-5.4_oneplus_sm6375 that referenced this issue Nov 2, 2022
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Rohail33 pushed a commit to Rohail33/Realking_xiaomi_xaga that referenced this issue Dec 31, 2022
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
lsahn-gh pushed a commit to lsahn-org/ubuntu-raspi that referenced this issue Jan 13, 2023
BugLink: https://bugs.launchpad.net/bugs/1989958

See: raspberrypi/linux#4117

Signed-off-by: Phil Elwell <[email protected]>

(cherry picked from commit 6e7b5a9c4cf011e1911c1d99d36f9ab08cee20da rpi-5.19.y)
Signed-off-by: Juerg Haefliger <[email protected]>
intersectRaven pushed a commit to intersectRaven/rk356x-kernel that referenced this issue Sep 16, 2023
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
warudooooo added a commit to warudooooo/android_kernel_sm6225_spes that referenced this issue Sep 20, 2023
Merge: 9e5a216016f0 a027d43cf3f2
Author: warudo <[email protected]>
Date:   Wed Sep 20 16:00:07 2023 +0800

    Merge tag 'v4.19.215' of https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable

    This is the 4.19.215 stable release

commit a027d43cf3f2fdaabf467b4bcb92d0fe748c2eaf
Author: Greg Kroah-Hartman <[email protected]>
Date:   Tue Nov 2 18:26:46 2021 +0100

    Linux 4.19.215

    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Hulk Robot <[email protected]>
    Tested-by: Sudip Mukherjee <[email protected]>
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1ff3c379248ea579aa122d4ca245028e4bc9af23
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:47 2021 -0400

    sctp: add vtag check in sctp_sf_ootb

    [ Upstream commit 9d02831e517aa36ee6bdb453a0eb47bd49923fe3 ]

    sctp_sf_ootb() is called when processing DATA chunk in closed state,
    and many other places are also using it.

    The vtag in the chunk's sctphdr should be verified, otherwise, as
    later in chunk length check, it may send abort with the existent
    asoc's vtag, which can be exploited by one to cook a malicious
    chunk to terminate a SCTP asoc.

    When fails to verify the vtag from the chunk, this patch sets asoc
    to NULL, so that the abort will be made with the vtag from the
    received chunk later.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit d9a4f990aab48dd5c134a9e76c7b651d404b05d3
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:46 2021 -0400

    sctp: add vtag check in sctp_sf_do_8_5_1_E_sa

    [ Upstream commit ef16b1734f0a176277b7bb9c71a6d977a6ef3998 ]

    sctp_sf_do_8_5_1_E_sa() is called when processing SHUTDOWN_ACK chunk
    in cookie_wait and cookie_echoed state.

    The vtag in the chunk's sctphdr should be verified, otherwise, as
    later in chunk length check, it may send abort with the existent
    asoc's vtag, which can be exploited by one to cook a malicious
    chunk to terminate a SCTP asoc.

    Note that when fails to verify the vtag from SHUTDOWN-ACK chunk,
    SHUTDOWN COMPLETE message will still be sent back to peer, but
    with the vtag from SHUTDOWN-ACK chunk, as said in 5) of
    rfc4960#section-8.4.

    While at it, also remove the unnecessary chunk length check from
    sctp_sf_shut_8_4_5(), as it's already done in both places where
    it calls sctp_sf_shut_8_4_5().

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7bf2f6a30d1851c530ad5e4ee7e5c45fb6be0128
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:45 2021 -0400

    sctp: add vtag check in sctp_sf_violation

    [ Upstream commit aa0f697e45286a6b5f0ceca9418acf54b9099d99 ]

    sctp_sf_violation() is called when processing HEARTBEAT_ACK chunk
    in cookie_wait state, and some other places are also using it.

    The vtag in the chunk's sctphdr should be verified, otherwise, as
    later in chunk length check, it may send abort with the existent
    asoc's vtag, which can be exploited by one to cook a malicious
    chunk to terminate a SCTP asoc.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 86044244fc6f9eaec0070cb668e0d500de22dbba
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:44 2021 -0400

    sctp: fix the processing for COOKIE_ECHO chunk

    [ Upstream commit a64b341b8695e1c744dd972b39868371b4f68f83 ]

    1. In closed state: in sctp_sf_do_5_1D_ce():

      When asoc is NULL, making packet for abort will use chunk's vtag
      in sctp_ootb_pkt_new(). But when asoc exists, vtag from the chunk
      should be verified before using peer.i.init_tag to make packet
      for abort in sctp_ootb_pkt_new(), and just discard it if vtag is
      not correct.

    2. In the other states: in sctp_sf_do_5_2_4_dupcook():

      asoc always exists, but duplicate cookie_echo's vtag will be
      handled by sctp_tietags_compare() and then take actions, so before
      that we only verify the vtag for the abort sent for invalid chunk
      length.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 1f52dfacca7bb315d89f5ece5660b0337809798e
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:41 2021 -0400

    sctp: use init_tag from inithdr for ABORT chunk

    [ Upstream commit 4f7019c7eb33967eb87766e0e4602b5576873680 ]

    Currently Linux SCTP uses the verification tag of the existing SCTP
    asoc when failing to process and sending the packet with the ABORT
    chunk. This will result in the peer accepting the ABORT chunk and
    removing the SCTP asoc. One could exploit this to terminate a SCTP
    asoc.

    This patch is to fix it by always using the initiate tag of the
    received INIT chunk for the ABORT chunk to be sent.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit b75fa48e42d022d6757b7de29178d531df8cf43b
Author: Trevor Woerner <[email protected]>
Date:   Sun Oct 24 13:50:02 2021 -0400

    net: nxp: lpc_eth.c: avoid hang when bringing interface down

    commit ace19b992436a257d9a793672e57abc28fe83e2e upstream.

    A hard hang is observed whenever the ethernet interface is brought
    down. If the PHY is stopped before the LPC core block is reset,
    the SoC will hang. Comparing lpc_eth_close() and lpc_eth_open() I
    re-arranged the ordering of the functions calls in lpc_eth_close() to
    reset the hardware before stopping the PHY.
    Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
    Signed-off-by: Trevor Woerner <[email protected]>
    Acked-by: Vladimir Zapolskiy <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 84a9eb9a2f179ea5e6398fe270560a8aaa16f996
Author: Yuiko Oshino <[email protected]>
Date:   Fri Oct 22 11:53:43 2021 -0400

    net: ethernet: microchip: lan743x: Fix dma allocation failure by using dma_set_mask_and_coherent

    commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

    The dma failure was reported in the raspberry pi github (issue #4117).
    https://github.com/raspberrypi/linux/issues/4117
    The use of dma_set_mask_and_coherent fixes the issue.
    Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

    Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
    Signed-off-by: Yuiko Oshino <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fcda74cc95aa450a6d17780ccb1a8853cac7d0cd
Author: Yuiko Oshino <[email protected]>
Date:   Fri Oct 22 11:13:53 2021 -0400

    net: ethernet: microchip: lan743x: Fix driver crash when lan743x_pm_resume fails

    commit d6423d2ec39cce2bfca418c81ef51792891576bc upstream.

    The driver needs to clean up and return when the initialization fails on resume.

    Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
    Signed-off-by: Yuiko Oshino <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 25d852a8adf017a478246d19c8b282e975521e8a
Author: Guenter Roeck <[email protected]>
Date:   Wed Oct 20 12:11:16 2021 -0700

    nios2: Make NIOS2_DTB_SOURCE_BOOL depend on !COMPILE_TEST

    commit 4a089e95b4d6bb625044d47aed0c442a8f7bd093 upstream.

    nios2:allmodconfig builds fail with

    make[1]: *** No rule to make target 'arch/nios2/boot/dts/""',
    	needed by 'arch/nios2/boot/dts/built-in.a'.  Stop.
    make: [Makefile:1868: arch/nios2/boot/dts] Error 2 (ignored)

    This is seen with compile tests since those enable NIOS2_DTB_SOURCE_BOOL,
    which in turn enables NIOS2_DTB_SOURCE. This causes the build error
    because the default value for NIOS2_DTB_SOURCE is an empty string.
    Disable NIOS2_DTB_SOURCE_BOOL for compile tests to avoid the error.

    Fixes: 2fc8483fdcde ("nios2: Build infrastructure")
    Signed-off-by: Guenter Roeck <[email protected]>
    Reviewed-by: Randy Dunlap <[email protected]>
    Signed-off-by: Dinh Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 02302cbd52264337630a32848ac03648648e9685
Author: Michael Chan <[email protected]>
Date:   Mon Oct 25 05:05:28 2021 -0400

    net: Prevent infinite while loop in skb_tx_hash()

    commit 0c57eeecc559ca6bc18b8c4e2808bc78dbe769b0 upstream.

    Drivers call netdev_set_num_tc() and then netdev_set_tc_queue()
    to set the queue count and offset for each TC.  So the queue count
    and offset for the TCs may be zero for a short period after dev->num_tc
    has been set.  If a TX packet is being transmitted at this time in the
    code path netdev_pick_tx() -> skb_tx_hash(), skb_tx_hash() may see
    nonzero dev->num_tc but zero qcount for the TC.  The while loop that
    keeps looping while hash >= qcount will not end.

    Fix it by checking the TC's qcount to be nonzero before using it.

    Fixes: eadec877ce9c ("net: Add support for subordinate traffic classes to netdev_pick_tx")
    Reviewed-by: Andy Gospodarek <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fbf150b16a3635634b7dfb7f229d8fcd643c6c51
Author: Pavel Skripkin <[email protected]>
Date:   Sun Oct 24 16:13:56 2021 +0300

    net: batman-adv: fix error handling

    commit 6f68cd634856f8ca93bafd623ba5357e0f648c68 upstream.

    Syzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was
    in wrong error handling in batadv_mesh_init().

    Before this patch batadv_mesh_init() was calling batadv_mesh_free() in case
    of any batadv_*_init() calls failure. This approach may work well, when
    there is some kind of indicator, which can tell which parts of batadv are
    initialized; but there isn't any.

    All written above lead to cleaning up uninitialized fields. Even if we hide
    ODEBUG warning by initializing bat_priv->nc.work, syzbot was able to hit
    GPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]

    To fix these bugs we can unwind batadv_*_init() calls one by one.
    It is good approach for 2 reasons: 1) It fixes bugs on error handling
    path 2) It improves the performance, since we won't call unneeded
    batadv_*_free() functions.

    So, this patch makes all batadv_*_init() clean up all allocated memory
    before returning with an error to no call correspoing batadv_*_free()
    and open-codes batadv_mesh_free() with proper order to avoid touching
    uninitialized fields.

    Link: https://lore.kernel.org/netdev/[email protected]/ [1]
    Reported-and-tested-by: [email protected]
    Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
    Signed-off-by: Pavel Skripkin <[email protected]>
    Acked-by: Sven Eckelmann <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3dae1a4eced3ee733d7222e69b8a55caf2d61091
Author: Yang Yingliang <[email protected]>
Date:   Tue Oct 12 10:37:35 2021 +0800

    regmap: Fix possible double-free in regcache_rbtree_exit()

    commit 55e6d8037805b3400096d621091dfbf713f97e83 upstream.

    In regcache_rbtree_insert_to_block(), when 'present' realloc failed,
    the 'blk' which is supposed to assign to 'rbnode->block' will be freed,
    so 'rbnode->block' points a freed memory, in the error handling path of
    regcache_rbtree_init(), 'rbnode->block' will be freed again in
    regcache_rbtree_exit(), KASAN will report double-free as follows:

    BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390
    Call Trace:
     slab_free_freelist_hook+0x10d/0x240
     kfree+0xce/0x390
     regcache_rbtree_exit+0x15d/0x1a0
     regcache_rbtree_init+0x224/0x2c0
     regcache_init+0x88d/0x1310
     __regmap_init+0x3151/0x4a80
     __devm_regmap_init+0x7d/0x100
     madera_spi_probe+0x10f/0x333 [madera_spi]
     spi_probe+0x183/0x210
     really_probe+0x285/0xc30

    To fix this, moving up the assignment of rbnode->block to immediately after
    the reallocation has succeeded so that the data structure stays valid even
    if the second reallocation fails.

    Reported-by: Hulk Robot <[email protected]>
    Fixes: 3f4ff561bc88b ("regmap: rbtree: Make cache_present bitmap per node")
    Signed-off-by: Yang Yingliang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cdaf7a469244b5e65ae5eda062ff5ea90172de62
Author: Clément Bœsch <[email protected]>
Date:   Sun Sep 5 02:20:27 2021 +0200

    arm64: dts: allwinner: h5: NanoPI Neo 2: Fix ethernet node

    commit 0764e365dacd0b8f75c1736f9236be280649bd18 upstream.

    RX and TX delay are provided by ethernet PHY. Reflect that in ethernet
    node.

    Fixes: 44a94c7ef989 ("arm64: dts: allwinner: H5: Restore EMAC changes")
    Signed-off-by: Clément Bœsch <[email protected]>
    Reviewed-by: Jernej Skrabec <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Maxime Ripard <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2864b6d54244b82a8c7d4628a43055c57bfba80c
Author: Patrisious Haddad <[email protected]>
Date:   Wed Oct 6 12:31:53 2021 +0300

    RDMA/mlx5: Set user priority for DCT

    commit 1ab52ac1e9bc9391f592c9fa8340a6e3e9c36286 upstream.

    Currently, the driver doesn't set the PCP-based priority for DCT, hence
    DCT response packets are transmitted without user priority.

    Fix it by setting user provided priority in the eth_prio field in the DCT
    context, which in turn sets the value in the transmitted packet.

    Fixes: 776a3906b692 ("IB/mlx5: Add support for DC target QP")
    Link: https://lore.kernel.org/r/5fd2d94a13f5742d8803c218927322257d53205c.1633512672.git.leonro@nvidia.com
    Signed-off-by: Patrisious Haddad <[email protected]>
    Reviewed-by: Maor Gottlieb <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 326da4f6ffdbd8671e86f69ded7a714dcc12fecf
Author: Johan Hovold <[email protected]>
Date:   Tue Oct 26 12:36:17 2021 +0200

    net: lan78xx: fix division by zero in send path

    commit db6c3c064f5d55fa9969f33eafca3cdbefbb3541 upstream.

    Add the missing endpoint max-packet sanity check to probe() to avoid
    division by zero in lan78xx_tx_bh() in case a malicious device has
    broken descriptors (or when doing descriptor fuzz testing).

    Note that USB core will reject URBs submitted for endpoints with zero
    wMaxPacketSize but that drivers doing packet-size calculations still
    need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
    endpoint descriptors with maxpacket=0")).

    Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
    Cc: [email protected]      # 4.3
    Cc: [email protected] <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2ff5289793fd61c56ac8774408f27350e5da865f
Author: Haibo Chen <[email protected]>
Date:   Fri Oct 15 10:00:36 2021 +0800

    mmc: sdhci-esdhc-imx: clear the buffer_read_ready to reset standard tuning circuit

    commit 9af372dc70e9fdcbb70939dac75365e7b88580b4 upstream.

    To reset standard tuning circuit completely, after clear ESDHC_MIX_CTRL_EXE_TUNE,
    also need to clear bit buffer_read_ready, this operation will finally clear the
    USDHC IP internal logic flag execute_tuning_with_clr_buf, make sure the following
    normal data transfer will not be impacted by standard tuning logic used before.

    Find this issue when do quick SD card insert/remove stress test. During standard
    tuning prodedure, if remove SD card, USDHC standard tuning logic can't clear the
    internal flag execute_tuning_with_clr_buf. Next time when insert SD card, all
    data related commands can't get any data related interrupts, include data transfer
    complete interrupt, data timeout interrupt, data CRC interrupt, data end bit interrupt.
    Always trigger software timeout issue. Even reset the USDHC through bits in register
    SYS_CTRL (0x2C, bit28 reset tuning, bit26 reset data, bit 25 reset command, bit 24
    reset all) can't recover this. From the user's point of view, USDHC stuck, SD can't
    be recognized any more.

    Fixes: d9370424c948 ("mmc: sdhci-esdhc-imx: reset tuning circuit when power on mmc card")
    Signed-off-by: Haibo Chen <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7824414c2903e2cfe56ea610387a22c0c88fb468
Author: Shawn Guo <[email protected]>
Date:   Mon Oct 4 10:49:35 2021 +0800

    mmc: sdhci: Map more voltage level to SDHCI_POWER_330

    commit 4217d07b9fb328751f877d3bd9550122014860a2 upstream.

    On Thundercomm TurboX CM2290, the eMMC OCR reports vdd = 23 (3.5 ~ 3.6 V),
    which is being treated as an invalid value by sdhci_set_power_noreg().
    And thus eMMC is totally broken on the platform.

    [    1.436599] ------------[ cut here ]------------
    [    1.436606] mmc0: Invalid vdd 0x17
    [    1.436640] WARNING: CPU: 2 PID: 69 at drivers/mmc/host/sdhci.c:2048 sdhci_set_power_noreg+0x168/0x2b4
    [    1.436655] Modules linked in:
    [    1.436662] CPU: 2 PID: 69 Comm: kworker/u8:1 Tainted: G        W         5.15.0-rc1+ #137
    [    1.436669] Hardware name: Thundercomm TurboX CM2290 (DT)
    [    1.436674] Workqueue: events_unbound async_run_entry_fn
    [    1.436685] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [    1.436692] pc : sdhci_set_power_noreg+0x168/0x2b4
    [    1.436698] lr : sdhci_set_power_noreg+0x168/0x2b4
    [    1.436703] sp : ffff800010803a60
    [    1.436705] x29: ffff800010803a60 x28: ffff6a9102465f00 x27: ffff6a9101720a70
    [    1.436715] x26: ffff6a91014de1c0 x25: ffff6a91014de010 x24: ffff6a91016af280
    [    1.436724] x23: ffffaf7b1b276640 x22: 0000000000000000 x21: ffff6a9101720000
    [    1.436733] x20: ffff6a9101720370 x19: ffff6a9101720580 x18: 0000000000000020
    [    1.436743] x17: 0000000000000000 x16: 0000000000000004 x15: ffffffffffffffff
    [    1.436751] x14: 0000000000000000 x13: 00000000fffffffd x12: ffffaf7b1b84b0bc
    [    1.436760] x11: ffffaf7b1b720d10 x10: 000000000000000a x9 : ffff800010803a60
    [    1.436769] x8 : 000000000000000a x7 : 000000000000000f x6 : 00000000fffff159
    [    1.436778] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff
    [    1.436787] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff6a9101718d80
    [    1.436797] Call trace:
    [    1.436800]  sdhci_set_power_noreg+0x168/0x2b4
    [    1.436805]  sdhci_set_ios+0xa0/0x7fc
    [    1.436811]  mmc_power_up.part.0+0xc4/0x164
    [    1.436818]  mmc_start_host+0xa0/0xb0
    [    1.436824]  mmc_add_host+0x60/0x90
    [    1.436830]  __sdhci_add_host+0x174/0x330
    [    1.436836]  sdhci_msm_probe+0x7c0/0x920
    [    1.436842]  platform_probe+0x68/0xe0
    [    1.436850]  really_probe.part.0+0x9c/0x31c
    [    1.436857]  __driver_probe_device+0x98/0x144
    [    1.436863]  driver_probe_device+0xc8/0x15c
    [    1.436869]  __device_attach_driver+0xb4/0x120
    [    1.436875]  bus_for_each_drv+0x78/0xd0
    [    1.436881]  __device_attach_async_helper+0xac/0xd0
    [    1.436888]  async_run_entry_fn+0x34/0x110
    [    1.436895]  process_one_work+0x1d0/0x354
    [    1.436903]  worker_thread+0x13c/0x470
    [    1.436910]  kthread+0x150/0x160
    [    1.436915]  ret_from_fork+0x10/0x20
    [    1.436923] ---[ end trace fcfac44cb045c3a8 ]---

    Fix the issue by mapping MMC_VDD_35_36 (and MMC_VDD_34_35) to
    SDHCI_POWER_330 as well.

    Signed-off-by: Shawn Guo <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 29d56f3790e684e630d56f500b59e834fa382209
Author: Jaehoon Chung <[email protected]>
Date:   Fri Oct 22 17:21:06 2021 +0900

    mmc: dw_mmc: exynos: fix the finding clock sample value

    commit 697542bceae51f7620af333b065dd09d213629fb upstream.

    Even though there are candiates value if can't find best value, it's
    returned -EIO. It's not proper behavior.
    If there is not best value, use a first candiate value to work eMMC.

    Signed-off-by: Jaehoon Chung <[email protected]>
    Tested-by: Marek Szyprowski <[email protected]>
    Tested-by: Christian Hewitt <[email protected]>
    Cc: [email protected]
    Fixes: c537a1c5ff63 ("mmc: dw_mmc: exynos: add variable delay tuning sequence")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 24f8658690477e8983f88cbfe21fb7f4062ad837
Author: Wenbin Mei <[email protected]>
Date:   Tue Oct 26 15:08:12 2021 +0800

    mmc: cqhci: clear HALT state after CQE enable

    commit 92b18252b91de567cd875f2e84722b10ab34ee28 upstream.

    While mmc0 enter suspend state, we need halt CQE to send legacy cmd(flush
    cache) and disable cqe, for resume back, we enable CQE and not clear HALT
    state.
    In this case MediaTek mmc host controller will keep the value for HALT
    state after CQE disable/enable flow, so the next CQE transfer after resume
    will be timeout due to CQE is in HALT state, the log as below:
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: timeout for tag 2
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: ============ CQHCI REGISTER DUMP ===========
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Caps:      0x100020b6 | Version:  0x00000510
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Config:    0x00001103 | Control:  0x00000001
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Int stat:  0x00000000 | Int enab: 0x00000006
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Int sig:   0x00000006 | Int Coal: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: TDL base:  0xfd05f000 | TDL up32: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Doorbell:  0x8000203c | TCN:      0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Task clr:  0x00000000 | SSC1:     0x00001000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: SSC2:      0x00000001 | DCMD rsp: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: RED mask:  0xfdf9a080 | TERRI:    0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Resp idx:  0x00000000 | Resp arg: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: CRNQP:     0x00000000 | CRNQDUN:  0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: CRNQIS:    0x00000000 | CRNQIE:   0x00000000

    This change check HALT state after CQE enable, if CQE is in HALT state, we
    will clear it.

    Signed-off-by: Wenbin Mei <[email protected]>
    Cc: [email protected]
    Acked-by: Adrian Hunter <[email protected]>
    Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 99641238575c26c2e47fa593f562dae476709d68
Author: Johan Hovold <[email protected]>
Date:   Mon Oct 25 13:56:08 2021 +0200

    mmc: vub300: fix control-message timeouts

    commit 8c8171929116cc23f74743d99251eedadf62341a upstream.

    USB control-message timeouts are specified in milliseconds and should
    specifically not vary with CONFIG_HZ.

    Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
    Cc: [email protected]      # 3.0
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c6d0d68d6da68159948cad3d808d61bb291a0283
Author: Eric Dumazet <[email protected]>
Date:   Sun Aug 29 15:16:14 2021 -0700

    ipv6: make exception cache less predictible

    commit a00df2caffed3883c341d5685f830434312e4a43 upstream.

    Even after commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()"),
    an attacker can still use brute force to learn some secrets from a victim
    linux host.

    One way to defeat these attacks is to make the max depth of the hash
    table bucket a random value.

    Before this patch, each bucket of the hash table used to store exceptions
    could contain 6 items under attack.

    After the patch, each bucket would contains a random number of items,
    between 6 and 10. The attacker can no longer infer secrets.

    This is slightly increasing memory size used by the hash table,
    we do not expect this to be a problem.

    Following patch is dealing with the same issue in IPv4.

    Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Keyu Man <[email protected]>
    Cc: Wei Wang <[email protected]>
    Cc: Martin KaFai Lau <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    [OP: adjusted context for 4.19 stable]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ad829847ad59af8e26a1f1c345716099abbc7a58
Author: Eric Dumazet <[email protected]>
Date:   Fri Oct 29 10:50:26 2021 +0300

    ipv6: use siphash in rt6_exception_hash()

    commit 4785305c05b25a242e5314cc821f54ade4c18810 upstream.

    A group of security researchers brought to our attention
    the weakness of hash function used in rt6_exception_hash()

    Lets use siphash instead of Jenkins Hash, to considerably
    reduce security risks.

    Following patch deals with IPv4.

    Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Keyu Man <[email protected]>
    Cc: Wei Wang <[email protected]>
    Cc: Martin KaFai Lau <[email protected]>
    Acked-by: Wei Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    [OP: adjusted context for 4.19 stable]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6e2856767eb1a9cfcfcd82136928037f04920e97
Author: Eric Dumazet <[email protected]>
Date:   Fri Oct 29 10:50:25 2021 +0300

    ipv4: use siphash instead of Jenkins in fnhe_hashfun()

    commit 6457378fe796815c973f631a1904e147d6ee33b1 upstream.

    A group of security researchers brought to our attention
    the weakness of hash function used in fnhe_hashfun().

    Lets use siphash instead of Jenkins Hash, to considerably
    reduce security risks.

    Also remove the inline keyword, this really is distracting.

    Fixes: d546c621542d ("ipv4: harden fnhe_hashfun()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Keyu Man <[email protected]>
    Cc: Willy Tarreau <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    [OP: adjusted context for 4.19 stable]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8121d0d4fd108280f5cd7b7fe8c6592adaa37be9
Author: Pavel Skripkin <[email protected]>
Date:   Thu Sep 30 20:49:42 2021 +0300

    Revert "net: mdiobus: Fix memory leak in __mdiobus_register"

    commit 10eff1f5788b6ffac212c254e2f3666219576889 upstream.

    This reverts commit ab609f25d19858513919369ff3d9a63c02cd9e2e.

    This patch is correct in the sense that we _should_ call device_put() in
    case of device_register() failure, but the problem in this code is more
    vast.

    We need to set bus->state to UNMDIOBUS_REGISTERED before calling
    device_register() to correctly release the device in mdiobus_free().
    This patch prevents us from doing it, since in case of device_register()
    failure put_device() will be called 2 times and it will cause UAF or
    something else.

    Also, Reported-by: tag in revered commit was wrong, since syzbot
    reported different leak in same function.

    Link: https://lore.kernel.org/netdev/20210928092657.GI2048@kadam/
    Acked-by: Yanfei Xu <[email protected]>
    Signed-off-by: Pavel Skripkin <[email protected]>
    Link: https://lore.kernel.org/r/f12fb1faa4eccf0f355788225335eb4309ff2599.1633024062.git.paskripkin@gmail.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4a9043ba1b0e9bea1da0fe34366222974f2c0f92
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Oct 25 16:49:36 2021 +0200

    nfc: port100: fix using -ERRNO as command type mask

    commit 2195f2062e4cc93870da8e71c318ef98a1c51cef upstream.

    During probing, the driver tries to get a list (mask) of supported
    command types in port100_get_command_type_mask() function.  The value
    is u64 and 0 is treated as invalid mask (no commands supported).  The
    function however returns also -ERRNO as u64 which will be interpret as
    valid command mask.

    Return 0 on every error case of port100_get_command_type_mask(), so the
    probing will stop.

    Cc: <[email protected]>
    Fixes: 0347a6ab300a ("NFC: port100: Commands mechanism implementation")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a36119f9b3fb069437383a8eff4e65181b6e7e2f
Author: Zheyu Ma <[email protected]>
Date:   Fri Oct 22 09:12:26 2021 +0000

    ata: sata_mv: Fix the error handling of mv_chip_id()

    commit a0023bb9dd9bc439d44604eeec62426a990054cd upstream.

    mv_init_host() propagates the value returned by mv_chip_id() which in turn
    gets propagated by mv_pci_init_one() and hits local_pci_probe().

    During the process of driver probing, the probe function should return < 0
    for failure, otherwise, the kernel will treat value > 0 as success.

    Since this is a bug rather than a recoverable runtime error we should
    use dev_alert() instead of dev_err().

    Signed-off-by: Zheyu Ma <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 78c2dc1cdf0bdfc83e473d78f23da4d2aeb98142
Author: Wang Hai <[email protected]>
Date:   Tue Oct 26 20:40:15 2021 +0800

    usbnet: fix error return code in usbnet_probe()

    commit 6f7c88691191e6c52ef2543d6f1da8d360b27a24 upstream.

    Return error code if usb_maxpacket() returns 0 in usbnet_probe()

    Fixes: 397430b50a36 ("usbnet: sanity check for maxpacket")
    Reported-by: Hulk Robot <[email protected]>
    Signed-off-by: Wang Hai <[email protected]>
    Reviewed-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 002d82227c0abe29118cf80f7e2f396b22d448ed
Author: Oliver Neukum <[email protected]>
Date:   Thu Oct 21 14:29:44 2021 +0200

    usbnet: sanity check for maxpacket

    commit 397430b50a363d8b7bdda00522123f82df6adc5e upstream.

    maxpacket of 0 makes no sense and oopses as we need to divide
    by it. Give up.

    V2: fixed typo in log and stylistic issues

    Signed-off-by: Oliver Neukum <[email protected]>
    Reported-by: [email protected]
    Reviewed-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d725978abb0bac6e0c427548dfd6db86709a2a1e
Author: Nathan Chancellor <[email protected]>
Date:   Sat Jan 5 19:35:25 2019 +0100

    ARM: 8819/1: Remove '-p' from LDFLAGS

    commit 091bb549f7722723b284f63ac665e2aedcf9dec9 upstream.

    This option is not supported by lld:

        ld.lld: error: unknown argument: -p

    This has been a no-op in binutils since 2004 (see commit dea514f51da1 in
    that tree). Given that the lowest officially supported of binutils for
    the kernel is 2.20, which was released in 2009, nobody needs this flag
    around so just remove it. Commit 1a381d4a0a9a ("arm64: remove no-op -p
    linker flag") did the same for arm64.

    Signed-off-by: Nathan Chancellor <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Acked-by: Nicolas Pitre <[email protected]>
    Reviewed-by: Nick Desaulniers <[email protected]>
    Reviewed-by: Stefan Agner <[email protected]>
    Signed-off-by: Russell King <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit aaf4e1b05cab800b36b40c1aa09f7c13ef30de56
Author: Robin Murphy <[email protected]>
Date:   Mon Jul 12 15:27:46 2021 +0100

    arm64: Avoid premature usercopy failure

    commit 295cf156231ca3f9e3a66bde7fab5e09c41835e0 upstream.

    Al reminds us that the usercopy API must only return complete failure
    if absolutely nothing could be copied. Currently, if userspace does
    something silly like giving us an unaligned pointer to Device memory,
    or a size which overruns MTE tag bounds, we may fail to honour that
    requirement when faulting on a multi-byte access even though a smaller
    access could have succeeded.

    Add a mitigation to the fixup routines to fall back to a single-byte
    copy if we faulted on a larger access before anything has been written
    to the destination, to guarantee making *some* forward progress. We
    needn't be too concerned about the overall performance since this should
    only occur when callers are doing something a bit dodgy in the first
    place. Particularly broken userspace might still be able to trick
    generic_perform_write() into an infinite loop by targeting write() at
    an mmap() of some read-only device register where the fault-in load
    succeeds but any store synchronously aborts such that copy_to_user() is
    genuinely unable to make progress, but, well, don't do that...

    CC: [email protected]
    Reported-by: Chen Huang <[email protected]>
    Suggested-by: Al Viro <[email protected]>
    Reviewed-by: Catalin Marinas <[email protected]>
    Signed-off-by: Robin Murphy <[email protected]>
    Link: https://lore.kernel.org/r/dc03d5c675731a1f24a62417dba5429ad744234e.1626098433.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Chen Huang <[email protected]>

commit 5909b851b5e11d04f299e5f0a8937e9dcc807248
Author: Naveen N. Rao <[email protected]>
Date:   Wed Oct 6 01:55:22 2021 +0530

    powerpc/bpf: Fix BPF_MOD when imm == 1

    commit 8bbc9d822421d9ac8ff9ed26a3713c9afc69d6c8 upstream.

    Only ignore the operation if dividing by 1.

    Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
    Signed-off-by: Naveen N. Rao <[email protected]>
    Tested-by: Johan Almbladh <[email protected]>
    Reviewed-by: Christophe Leroy <[email protected]>
    Acked-by: Song Liu <[email protected]>
    Acked-by: Johan Almbladh <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/c674ca18c3046885602caebb326213731c675d06.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
    [cascardo: use PPC_LI instead of EMIT(PPC_RAW_LI)]
    Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 901741a53d7cf45be861e881c0e3cba5b4bd1f94
Author: Arnd Bergmann <[email protected]>
Date:   Mon Oct 18 15:30:37 2021 +0100

    ARM: 9141/1: only warn about XIP address when not compile testing

    commit 48ccc8edf5b90622cdc4f8878e0042ab5883e2ca upstream.

    In randconfig builds, we sometimes come across this warning:

    arm-linux-gnueabi-ld: XIP start address may cause MPU programming issues

    While this is helpful for actual systems to figure out why it
    fails, the warning does not provide any benefit for build testing,
    so guard it in a check for CONFIG_COMPILE_TEST, which is usually
    set on randconfig builds.

    Fixes: 216218308cfb ("ARM: 8713/1: NOMMU: Support MPU in XIP configuration")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ee4b38ce37ed31beca29d3ebec7db3d5e87fe39e
Author: Arnd Bergmann <[email protected]>
Date:   Mon Oct 18 15:30:09 2021 +0100

    ARM: 9139/1: kprobes: fix arch_init_kprobes() prototype

    commit 1f323127cab086e4fd618981b1e5edc396eaf0f4 upstream.

    With extra warnings enabled, gcc complains about this function
    definition:

    arch/arm/probes/kprobes/core.c: In function 'arch_init_kprobes':
    arch/arm/probes/kprobes/core.c:465:12: warning: old-style function definition [-Wold-style-definition]
      465 | int __init arch_init_kprobes()

    Link: https://lore.kernel.org/all/[email protected]/

    Fixes: 24ba613c9d6c ("ARM kprobes: core code")
    Acked-by: Masami Hiramatsu <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c0b4f1db7feef31d401814121760b45aff7885c1
Author: Arnd Bergmann <[email protected]>
Date:   Mon Oct 18 15:30:04 2021 +0100

    ARM: 9134/1: remove duplicate memcpy() definition

    commit eaf6cc7165c9c5aa3c2f9faa03a98598123d0afb upstream.

    Both the decompressor code and the kasan logic try to override
    the memcpy() and memmove()  definitions, which leading to a clash
    in a KASAN-enabled kernel with XZ decompression:

    arch/arm/boot/compressed/decompress.c:50:9: error: 'memmove' macro redefined [-Werror,-Wmacro-redefined]
     #define memmove memmove
            ^
    arch/arm/include/asm/string.h:59:9: note: previous definition is here
     #define memmove(dst, src, len) __memmove(dst, src, len)
            ^
    arch/arm/boot/compressed/decompress.c:51:9: error: 'memcpy' macro redefined [-Werror,-Wmacro-redefined]
     #define memcpy memcpy
            ^
    arch/arm/include/asm/string.h:58:9: note: previous definition is here
     #define memcpy(dst, src, len) __memcpy(dst, src, len)
            ^

    Here we want the set of functions from the decompressor, so undefine
    the other macros before the override.

    Link: https://lore.kernel.org/linux-arm-kernel/CACRpkdZYJogU_SN3H9oeVq=zJkRgRT1gDz3xp59gdqWXxw-B=w@mail.gmail.com/
    Link: https://lore.kernel.org/lkml/[email protected]/

    Fixes: d6d51a96c7d6 ("ARM: 9014/2: Replace string mem* functions for KASan")
    Fixes: a7f464f3db93 ("ARM: 7001/2: Wire up support for the XZ decompressor")
    Reported-by: kernel test robot <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 00dcbb2d2cd3594faa2f977f2f7175cf23d4e326
Author: Nick Desaulniers <[email protected]>
Date:   Mon Oct 4 18:03:28 2021 +0100

    ARM: 9133/1: mm: proc-macros: ensure *_tlb_fns are 4B aligned

    commit e6a0c958bdf9b2e1b57501fc9433a461f0a6aadd upstream.

    A kernel built with CONFIG_THUMB2_KERNEL=y and using clang as the
    assembler could generate non-naturally-aligned v7wbi_tlb_fns which
    results in a boot failure. The original commit adding the macro missed
    the .align directive on this data.

    Link: https://github.com/ClangBuiltLinux/linux/issues/1447
    Link: https://lore.kernel.org/all/[email protected]/
    Debugged-by: Ard Biesheuvel <[email protected]>
    Debugged-by: Nathan Chancellor <[email protected]>
    Debugged-by: Richard Henderson <[email protected]>

    Fixes: 66a625a88174 ("ARM: mm: proc-macros: Add generic proc/cache/tlb struct definition macros")
    Suggested-by: Ard Biesheuvel <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Nick Desaulniers <[email protected]>
    Tested-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 38ec06730e44b2166e87fecca9e36380080801ac
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed Oct 27 09:53:15 2021 +0200

    Linux 4.19.214

    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Sudip Mukherjee <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0b7d55ca605e611aceeadf7c29c75808faae951a
Author: Nick Desaulniers <[email protected]>
Date:   Wed Sep 8 19:25:59 2021 +0100

    ARM: 9122/1: select HAVE_FUTEX_CMPXCHG

    commit 9d417cbe36eee7afdd85c2e871685f8dab7c2dba upstream.

    tglx notes:
      This function [futex_detect_cmpxchg] is only needed when an
      architecture has to runtime discover whether the CPU supports it or
      not.  ARM has unconditional support for this, so the obvious thing to
      do is the below.

    Fixes linkage failure from Clang randconfigs:
    kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit: R_ARM_JUMP24 against `.init.text'
    and boot failures for CONFIG_THUMB2_KERNEL.

    Link: https://github.com/ClangBuiltLinux/linux/issues/325

    Comments from Nick Desaulniers:

     See-also: 03b8c7b623c8 ("futex: Allow architectures to skip
     futex_atomic_cmpxchg_inatomic() test")

    Reported-by: Arnd Bergmann <[email protected]>
    Reported-by: Nathan Chancellor <[email protected]>
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Nick Desaulniers <[email protected]>
    Reviewed-by: Thomas Gleixner <[email protected]>
    Tested-by: Nathan Chancellor <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Cc: [email protected] # v3.14+
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3de1ed125fc4c35bf7abb08260646100a6dcb04e
Author: Steven Rostedt (VMware) <[email protected]>
Date:   Mon Oct 18 15:44:12 2021 -0400

    tracing: Have all levels of checks prevent recursion

    commit ed65df63a39a3f6ed04f7258de8b6789e5021c18 upstream.

    While writing an email explaining the "bit = 0" logic for a discussion on
    making ftrace_test_recursion_trylock() disable preemption, I discovered a
    path that makes the "not do the logic if bit is zero" unsafe.

    The recursion logic is done in hot paths like the function tracer. Thus,
    any code executed causes noticeable overhead. Thus, tricks are done to try
    to limit the amount of code executed. This included the recursion testing
    logic.

    Having recursion testing is important, as there are many paths that can
    end up in an infinite recursion cycle when tracing every function in the
    kernel. Thus protection is needed to prevent that from happening.

    Because it is OK to recurse due to different running context levels (e.g.
    an interrupt preempts a trace, and then a trace occurs in the interrupt
    handler), a set of bits are used to know which context one is in (normal,
    softirq, irq and NMI). If a recursion occurs in the same level, it is
    prevented*.

    Then there are infrastructure levels of recursion as well. When more than
    one callback is attached to the same function to trace, it calls a loop
    function to iterate over all the callbacks. Both the callbacks and the
    loop function have recursion protection. The callbacks use the
    "ftrace_test_recursion_trylock()" which has a "function" set of context
    bits to test, and the loop function calls the internal
    trace_test_and_set_recursion() directly, with an "internal" set of bits.

    If an architecture does not implement all the features supported by ftrace
    then the callbacks are never called directly, and the loop function is
    called instead, which will implement the features of ftrace.

    Since both the loop function and the callbacks do recursion protection, it
    was seemed unnecessary to do it in both locations. Thus, a trick was made
    to have the internal set of recursion bits at a more significant bit
    location than the function bits. Then, if any of the higher bits were set,
    the logic of the function bits could be skipped, as any new recursion
    would first have to go through the loop function.

    This is true for architectures that do not support all the ftrace
    features, because all functions being traced must first go through the
    loop function before going to the callbacks. But this is not true for
    architectures that support all the ftrace features. That's because the
    loop function could be called due to two callbacks attached to the same
    function, but then a recursion function inside the callback could be
    called that does not share any other callback, and it will be called
    directly.

    i.e.

     traced_function_1: [ more than one callback tracing it ]
       call loop_func

     loop_func:
       trace_recursion set internal bit
       call callback

     callback:
       trace_recursion [ skipped because internal bit is set, return 0 ]
       call traced_function_2

     traced_function_2: [ only traced by above callback ]
       call callback

     callback:
       trace_recursion [ skipped because internal bit is set, return 0 ]
       call traced_function_2

     [ wash, rinse, repeat, BOOM! out of shampoo! ]

    Thus, the "bit == 0 skip" trick is not safe, unless the loop function is
    call for all functions.

    Since we want to encourage architectures to implement all ftrace features,
    having them slow down due to this extra logic may encourage the
    maintainers to update to the latest ftrace features. And because this
    logic is only safe for them, remove it completely.

     [*] There is on layer of recursion that is allowed, and that is to allow
         for the transition between interrupt context (normal -> softirq ->
         irq -> NMI), because a trace may occur before the context update is
         visible to the trace recursion logic.

    Link: https://lore.kernel.org/all/[email protected]/
    Link: https://lkml.kernel.org/r/[email protected]

    Cc: Linus Torvalds <[email protected]>
    Cc: Petr Mladek <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: "James E.J. Bottomley" <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: Michael Ellerman <[email protected]>
    Cc: Benjamin Herrenschmidt <[email protected]>
    Cc: Paul Mackerras <[email protected]>
    Cc: Paul Walmsley <[email protected]>
    Cc: Palmer Dabbelt <[email protected]>
    Cc: Albert Ou <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: Josh Poimboeuf <[email protected]>
    Cc: Jiri Kosina <[email protected]>
    Cc: Miroslav Benes <[email protected]>
    Cc: Joe Lawrence <[email protected]>
    Cc: Colin Ian King <[email protected]>
    Cc: Masami Hiramatsu <[email protected]>
    Cc: "Peter Zijlstra (Intel)" <[email protected]>
    Cc: Nicholas Piggin <[email protected]>
    Cc: Jisheng Zhang <[email protected]>
    Cc: =?utf-8?b?546L6LSH?= <[email protected]>
    Cc: Guo Ren <[email protected]>
    Cc: [email protected]
    Fixes: edc15cafcbfa3 ("tracing: Avoid unnecessary multiple recursion checks")
    Signed-off-by: Steven Rostedt (VMware) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a9831afa2dc8a18205403907c41aa4e0950ac611
Author: Yanfei Xu <[email protected]>
Date:   Sun Sep 26 12:53:13 2021 +0800

    net: mdiobus: Fix memory leak in __mdiobus_register

    commit ab609f25d19858513919369ff3d9a63c02cd9e2e upstream.

    Once device_register() failed, we should call put_device() to
    decrement reference count for cleanup. Or it will cause memory
    leak.

    BUG: memory leak
    unreferenced object 0xffff888114032e00 (size 256):
      comm "kworker/1:3", pid 2960, jiffies 4294943572 (age 15.920s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 08 2e 03 14 81 88 ff ff  ................
        08 2e 03 14 81 88 ff ff 90 76 65 82 ff ff ff ff  .........ve.....
      backtrace:
        [<ffffffff8265cfab>] kmalloc include/linux/slab.h:591 [inline]
        [<ffffffff8265cfab>] kzalloc include/linux/slab.h:721 [inline]
        [<ffffffff8265cfab>] device_private_init drivers/base/core.c:3203 [inline]
        [<ffffffff8265cfab>] device_add+0x89b/0xdf0 drivers/base/core.c:3253
        [<ffffffff828dd643>] __mdiobus_register+0xc3/0x450 drivers/net/phy/mdio_bus.c:537
        [<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
        [<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
        [<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
        [<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
        [<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
        [<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
        [<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
        [<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
        [<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
        [<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
        [<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
        [<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
        [<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969
        [<ffffffff82660916>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
        [<ffffffff8265cd0b>] device_add+0x5fb/0xdf0 drivers/base/core.c:3359
        [<ffffffff82c343b9>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2170
        [<ffffffff82c4473c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238

    BUG: memory leak
    unreferenced object 0xffff888116f06900 (size 32):
      comm "kworker/0:2", pid 2670, jiffies 4294944448 (age 7.160s)
      hex dump (first 32 bytes):
        75 73 62 2d 30 30 31 3a 30 30 33 00 00 00 00 00  usb-001:003.....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff81484516>] kstrdup+0x36/0x70 mm/util.c:60
        [<ffffffff814845a3>] kstrdup_const+0x53/0x80 mm/util.c:83
        [<ffffffff82296ba2>] kvasprintf_const+0xc2/0x110 lib/kasprintf.c:48
        [<ffffffff82358d4b>] kobject_set_name_vargs+0x3b/0xe0 lib/kobject.c:289
        [<ffffffff826575f3>] dev_set_name+0x63/0x90 drivers/base/core.c:3147
        [<ffffffff828dd63b>] __mdiobus_register+0xbb/0x450 drivers/net/phy/mdio_bus.c:535
        [<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
        [<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
        [<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
        [<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
        [<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
        [<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
        [<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
        [<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
        [<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
        [<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
        [<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
        [<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
        [<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969

    Reported-by: [email protected]
    Signed-off-by: Yanfei Xu <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 629e870ca473bbf3ec2429d441efb0406869783d
Author: Dexuan Cui <[email protected]>
Date:   Thu Oct 7 21:35:46 2021 -0700

    scsi: core: Fix shost->cmd_per_lun calculation in scsi_add_host_with_dma()

    commit 50b6cb3516365cb69753b006be2b61c966b70588 upstream.

    After commit ea2f0f77538c ("scsi: core: Cap scsi_host cmd_per_lun at
    can_queue"), a 416-CPU VM running on Hyper-V hangs during boot because the
    hv_storvsc driver sets scsi_driver.can_queue to an integer value that
    exceeds SHRT_MAX, and hence scsi_add_host_with_dma() sets
    shost->cmd_per_lun to a negative "short" value.

    Use min_t(int, ...) to work around the issue.

    Link: https://lore.kernel.org/r/[email protected]
    Fixes: ea2f0f77538c ("scsi: core: Cap scsi_host cmd_per_lun at can_queue")
    Cc: [email protected]
    Reviewed-by: Haiyang Zhang <[email protected]>
    Reviewed-by: Ming Lei <[email protected]>
    Reviewed-by: John Garry <[email protected]>
    Signed-off-by: Dexuan Cui <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1360f9cde7eaaea4e6b48ab4ec544c706dbc6a8a
Author: Kai Vehmanen <[email protected]>
Date:   Tue Oct 12 17:29:35 2021 +0300

    ALSA: hda: avoid write to STATESTS if controller is in reset

    [ Upstream commit b37a15188eae9d4c49c5bb035e0c8d4058e4d9b3 ]

    The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
    before performing controller reset. This code dates back to an old
    bugfix in commit e8a7f136f5ed ("[ALSA] hda-intel - Improve HD-audio
    codec probing robustness"). Originally the code was added to
    azx_reset().

    The code was moved around in commit a41d122449be ("ALSA: hda - Embed bus
    into controller object") and ended up to snd_hdac_bus_reset_link() and
    called primarily via snd_hdac_bus_init_chip().

    The logic to clear STATESTS is correct when snd_hdac_bus_init_chip() is
    called when controller is not in reset. In this case, STATESTS can be
    cleared. This can be useful e.g. when forcing a controller reset to retry
    codec probe. A normal non-power-on reset will not clear the bits.

    However, this old logic is problematic when controller is already in
    reset. The HDA specification states that controller must be taken out of
    reset before writing to registers other than GCTL.CRST (1.0a spec,
    3.3.7). The write to STATESTS in snd_hdac_bus_reset_link() will be lost
    if the controller is already in reset per the HDA specification mentioned.

    This has been harmless on older hardware. On newer generation of Intel
    PCIe based HDA controllers, if configured to report issues, this write
    will emit an unsupported request error. If ACPI Platform Error Interface
    (APEI) is enabled in kernel, this will end up to kernel log.

    Fix the code in snd_hdac_bus_reset_link() to only clear the STATESTS if
    the function is called when controller is not in reset. Otherwise
    clearing the bits is not possible and should be skipped.

    Signed-off-by: Kai Vehmanen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit f7db1bc1cdb809fdd65d50485fb67bd418eadbd5
Author: Prashant Malani <[email protected]>
Date:   Tue Sep 28 03:19:34 2021 -0700

    platform/x86: intel_scu_ipc: Update timeout value in comment

    [ Upstream commit a0c5814b9933f25ecb6de169483c5b88cf632bca ]

    The comment decribing the IPC timeout hadn't been updated when the
    actual timeout was changed from 3 to 5 seconds in
    commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual
    timeout from 3 to 5 seconds") .

    Since the value is anyway updated to 10s now, take this opportunity to
    update the value in the comment too.

    Signed-off-by: Prashant Malani <[email protected]>
    Cc: Benson Leung <[email protected]>
    Reviewed-by: Mika Westerberg <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a5b34409d3fc52114c828be4adbc30744fa3258b
Author: Zheyu Ma <[email protected]>
Date:   Sat Oct 9 11:33:49 2021 +0000

    isdn: mISDN: Fix sleeping function called from invalid context

    [ Upstream commit 6510e80a0b81b5d814e3aea6297ba42f5e76f73c ]

    The driver can call card->isac.release() function from an atomic
    context.

    Fix this by calling this function after releasing the lock.

    The following log reveals it:

    [   44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018
    [   44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe
    [   44.169574 ] INFO: lockdep is turned off.
    [   44.169899 ] irq event stamp: 0
    [   44.170160 ] hardirqs last  enabled at (0): [<0000000000000000>] 0x0
    [   44.170627 ] hardirqs last disabled at (0): [<ffffffff814209ed>] copy_process+0x132d/0x3e00
    [   44.171240 ] softirqs last  enabled at (0): [<ffffffff81420a1a>] copy_process+0x135a/0x3e00
    [   44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0
    [   44.172318 ] Preemption disabled at:
    [   44.172320 ] [<ffffffffa009b0a9>] nj_release+0x69/0x500 [netjet]
    [   44.174441 ] Call Trace:
    [   44.174630 ]  dump_stack_lvl+0xa8/0xd1
    [   44.174912 ]  dump_stack+0x15/0x17
    [   44.175166 ]  ___might_sleep+0x3a2/0x510
    [   44.175459 ]  ? nj_release+0x69/0x500 [netjet]
    [   44.175791 ]  __might_sleep+0x82/0xe0
    [   44.176063 ]  ? start_flush_work+0x20/0x7b0
    [   44.176375 ]  start_flush_work+0x33/0x7b0
    [   44.176672 ]  ? trace_irq_enable_rcuidle+0x85/0x170
    [   44.177034 ]  ? kasan_quarantine_put+0xaa/0x1f0
    [   44.177372 ]  ? kasan_quarantine_put+0xaa/0x1f0
    [   44.177711 ]  __flush_work+0x11a/0x1a0
    [   44.177991 ]  ? flush_work+0x20/0x20
    [   44.178257 ]  ? lock_release+0x13c/0x8f0
    [   44.178550 ]  ? __kasan_check_write+0x14/0x20
    [   44.178872 ]  ? do_raw_spin_lock+0x148/0x360
    [   44.179187 ]  ? read_lock_is_recursive+0x20/0x20
    [   44.179530 ]  ? __kasan_check_read+0x11/0x20
    [   44.179846 ]  ? do_raw_spin_unlock+0x55/0x900
    [   44.180168 ]  ? ____kasan_slab_free+0x116/0x140
    [   44.180505 ]  ? _raw_spin_unlock_irqrestore+0x41/0x60
    [   44.180878 ]  ? skb_queue_purge+0x1a3/0x1c0
    [   44.181189 ]  ? kfree+0x13e/0x290
    [   44.181438 ]  flush_work+0x17/0x20
    [   44.181695 ]  mISDN_freedchannel+0xe8/0x100
    [   44.182006 ]  isac_release+0x210/0x260 [mISDNipac]
    [   44.182366 ]  nj_release+0xf6/0x500 [netjet]
    [   44.182685 ]  nj_remove+0x48/0x70 [netjet]
    [   44.182989 ]  pci_device_remove+0xa9/0x250

    Signed-off-by: Zheyu Ma <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 207f6c3a82e19626aedad6e2f9aa0bb348495447
Author: Herve Codina <[email protected]>
Date:   Fri Oct 8 12:34:40 2021 +0200

    ARM: dts: spear3xx: Fix gmac node

    [ Upstream commit 6636fec29cdf6665bd219564609e8651f6ddc142 ]

    On SPEAr3xx, ethernet driver is not compatible with the SPEAr600
    one.
    Indeed, SPEAr3xx uses an earlier version of this IP (v3.40) and
    needs some driver tuning compare to SPEAr600.

    The v3.40 IP support was added to stmmac driver and this patch
    fixes this issue and use the correct compatible string for
    SPEAr3xx

    Signed-off-by: Herve Codina <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit cfe8c4a4d6eb21af53504c6b85393de2f8345685
Author: Herve Codina <[email protected]>
Date:   Fri Oct 8 12:34:39 2021 +0200

    net: stmmac: add support for dwmac 3.40a

    [ Upstream commit 9cb1d19f47fafad7dcf7c8564e633440c946cfd7 ]

    dwmac 3.40a is an old ip version that can be found on SPEAr3xx soc.

    Signed-off-by: Herve Codina <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit f03a8a85e91580f7881b24c24ab2e4e37d8080b1
Author: Filipe Manana <[email protected]>
Date:   Fri Oct 1 13:52:30 2021 +0100

    btrfs: deal with errors when checking if a dir entry exists during log replay

    [ Upstream commit 77a5b9e3d14cbce49ceed2766b2003c034c066dc ]

    Currently inode_in_dir() ignores errors returned from
    btrfs_lookup_dir_index_item() and from btrfs_lookup_dir_item(), treating
    any errors as if the directory entry does not exists in the fs/subvolume
    tree, which is obviously not correct, as we can get errors such as -EIO
    when reading extent buffers while searching the fs/subvolume's tree.

    Fix that by making inode_in_dir() return the errors and making its only
    caller, add_inode_ref(), deal with returned errors a…
warudooooo added a commit to warudooooo/android_kernel_sm6225_spes that referenced this issue Sep 20, 2023
…x/kernel/git/stable/linux-stable

commit 00a95330f3b295d4a581c36a5f2949c731386e37
Merge: 9e5a216016f0 a027d43cf3f2
Author: warudo <[email protected]>
Date:   Wed Sep 20 16:00:07 2023 +0800

    Merge tag 'v4.19.215'

    This is the 4.19.215 stable release

commit a027d43cf3f2fdaabf467b4bcb92d0fe748c2eaf
Author: Greg Kroah-Hartman <[email protected]>
Date:   Tue Nov 2 18:26:46 2021 +0100

    Linux 4.19.215

    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Hulk Robot <[email protected]>
    Tested-by: Sudip Mukherjee <[email protected]>
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1ff3c379248ea579aa122d4ca245028e4bc9af23
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:47 2021 -0400

    sctp: add vtag check in sctp_sf_ootb

    [ Upstream commit 9d02831e517aa36ee6bdb453a0eb47bd49923fe3 ]

    sctp_sf_ootb() is called when processing DATA chunk in closed state,
    and many other places are also using it.

    The vtag in the chunk's sctphdr should be verified, otherwise, as
    later in chunk length check, it may send abort with the existent
    asoc's vtag, which can be exploited by one to cook a malicious
    chunk to terminate a SCTP asoc.

    When fails to verify the vtag from the chunk, this patch sets asoc
    to NULL, so that the abort will be made with the vtag from the
    received chunk later.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit d9a4f990aab48dd5c134a9e76c7b651d404b05d3
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:46 2021 -0400

    sctp: add vtag check in sctp_sf_do_8_5_1_E_sa

    [ Upstream commit ef16b1734f0a176277b7bb9c71a6d977a6ef3998 ]

    sctp_sf_do_8_5_1_E_sa() is called when processing SHUTDOWN_ACK chunk
    in cookie_wait and cookie_echoed state.

    The vtag in the chunk's sctphdr should be verified, otherwise, as
    later in chunk length check, it may send abort with the existent
    asoc's vtag, which can be exploited by one to cook a malicious
    chunk to terminate a SCTP asoc.

    Note that when fails to verify the vtag from SHUTDOWN-ACK chunk,
    SHUTDOWN COMPLETE message will still be sent back to peer, but
    with the vtag from SHUTDOWN-ACK chunk, as said in 5) of
    rfc4960#section-8.4.

    While at it, also remove the unnecessary chunk length check from
    sctp_sf_shut_8_4_5(), as it's already done in both places where
    it calls sctp_sf_shut_8_4_5().

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7bf2f6a30d1851c530ad5e4ee7e5c45fb6be0128
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:45 2021 -0400

    sctp: add vtag check in sctp_sf_violation

    [ Upstream commit aa0f697e45286a6b5f0ceca9418acf54b9099d99 ]

    sctp_sf_violation() is called when processing HEARTBEAT_ACK chunk
    in cookie_wait state, and some other places are also using it.

    The vtag in the chunk's sctphdr should be verified, otherwise, as
    later in chunk length check, it may send abort with the existent
    asoc's vtag, which can be exploited by one to cook a malicious
    chunk to terminate a SCTP asoc.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 86044244fc6f9eaec0070cb668e0d500de22dbba
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:44 2021 -0400

    sctp: fix the processing for COOKIE_ECHO chunk

    [ Upstream commit a64b341b8695e1c744dd972b39868371b4f68f83 ]

    1. In closed state: in sctp_sf_do_5_1D_ce():

      When asoc is NULL, making packet for abort will use chunk's vtag
      in sctp_ootb_pkt_new(). But when asoc exists, vtag from the chunk
      should be verified before using peer.i.init_tag to make packet
      for abort in sctp_ootb_pkt_new(), and just discard it if vtag is
      not correct.

    2. In the other states: in sctp_sf_do_5_2_4_dupcook():

      asoc always exists, but duplicate cookie_echo's vtag will be
      handled by sctp_tietags_compare() and then take actions, so before
      that we only verify the vtag for the abort sent for invalid chunk
      length.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 1f52dfacca7bb315d89f5ece5660b0337809798e
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:41 2021 -0400

    sctp: use init_tag from inithdr for ABORT chunk

    [ Upstream commit 4f7019c7eb33967eb87766e0e4602b5576873680 ]

    Currently Linux SCTP uses the verification tag of the existing SCTP
    asoc when failing to process and sending the packet with the ABORT
    chunk. This will result in the peer accepting the ABORT chunk and
    removing the SCTP asoc. One could exploit this to terminate a SCTP
    asoc.

    This patch is to fix it by always using the initiate tag of the
    received INIT chunk for the ABORT chunk to be sent.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit b75fa48e42d022d6757b7de29178d531df8cf43b
Author: Trevor Woerner <[email protected]>
Date:   Sun Oct 24 13:50:02 2021 -0400

    net: nxp: lpc_eth.c: avoid hang when bringing interface down

    commit ace19b992436a257d9a793672e57abc28fe83e2e upstream.

    A hard hang is observed whenever the ethernet interface is brought
    down. If the PHY is stopped before the LPC core block is reset,
    the SoC will hang. Comparing lpc_eth_close() and lpc_eth_open() I
    re-arranged the ordering of the functions calls in lpc_eth_close() to
    reset the hardware before stopping the PHY.
    Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
    Signed-off-by: Trevor Woerner <[email protected]>
    Acked-by: Vladimir Zapolskiy <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 84a9eb9a2f179ea5e6398fe270560a8aaa16f996
Author: Yuiko Oshino <[email protected]>
Date:   Fri Oct 22 11:53:43 2021 -0400

    net: ethernet: microchip: lan743x: Fix dma allocation failure by using dma_set_mask_and_coherent

    commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

    The dma failure was reported in the raspberry pi github (issue #4117).
    https://github.com/raspberrypi/linux/issues/4117
    The use of dma_set_mask_and_coherent fixes the issue.
    Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

    Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
    Signed-off-by: Yuiko Oshino <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fcda74cc95aa450a6d17780ccb1a8853cac7d0cd
Author: Yuiko Oshino <[email protected]>
Date:   Fri Oct 22 11:13:53 2021 -0400

    net: ethernet: microchip: lan743x: Fix driver crash when lan743x_pm_resume fails

    commit d6423d2ec39cce2bfca418c81ef51792891576bc upstream.

    The driver needs to clean up and return when the initialization fails on resume.

    Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
    Signed-off-by: Yuiko Oshino <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 25d852a8adf017a478246d19c8b282e975521e8a
Author: Guenter Roeck <[email protected]>
Date:   Wed Oct 20 12:11:16 2021 -0700

    nios2: Make NIOS2_DTB_SOURCE_BOOL depend on !COMPILE_TEST

    commit 4a089e95b4d6bb625044d47aed0c442a8f7bd093 upstream.

    nios2:allmodconfig builds fail with

    make[1]: *** No rule to make target 'arch/nios2/boot/dts/""',
    	needed by 'arch/nios2/boot/dts/built-in.a'.  Stop.
    make: [Makefile:1868: arch/nios2/boot/dts] Error 2 (ignored)

    This is seen with compile tests since those enable NIOS2_DTB_SOURCE_BOOL,
    which in turn enables NIOS2_DTB_SOURCE. This causes the build error
    because the default value for NIOS2_DTB_SOURCE is an empty string.
    Disable NIOS2_DTB_SOURCE_BOOL for compile tests to avoid the error.

    Fixes: 2fc8483fdcde ("nios2: Build infrastructure")
    Signed-off-by: Guenter Roeck <[email protected]>
    Reviewed-by: Randy Dunlap <[email protected]>
    Signed-off-by: Dinh Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 02302cbd52264337630a32848ac03648648e9685
Author: Michael Chan <[email protected]>
Date:   Mon Oct 25 05:05:28 2021 -0400

    net: Prevent infinite while loop in skb_tx_hash()

    commit 0c57eeecc559ca6bc18b8c4e2808bc78dbe769b0 upstream.

    Drivers call netdev_set_num_tc() and then netdev_set_tc_queue()
    to set the queue count and offset for each TC.  So the queue count
    and offset for the TCs may be zero for a short period after dev->num_tc
    has been set.  If a TX packet is being transmitted at this time in the
    code path netdev_pick_tx() -> skb_tx_hash(), skb_tx_hash() may see
    nonzero dev->num_tc but zero qcount for the TC.  The while loop that
    keeps looping while hash >= qcount will not end.

    Fix it by checking the TC's qcount to be nonzero before using it.

    Fixes: eadec877ce9c ("net: Add support for subordinate traffic classes to netdev_pick_tx")
    Reviewed-by: Andy Gospodarek <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fbf150b16a3635634b7dfb7f229d8fcd643c6c51
Author: Pavel Skripkin <[email protected]>
Date:   Sun Oct 24 16:13:56 2021 +0300

    net: batman-adv: fix error handling

    commit 6f68cd634856f8ca93bafd623ba5357e0f648c68 upstream.

    Syzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was
    in wrong error handling in batadv_mesh_init().

    Before this patch batadv_mesh_init() was calling batadv_mesh_free() in case
    of any batadv_*_init() calls failure. This approach may work well, when
    there is some kind of indicator, which can tell which parts of batadv are
    initialized; but there isn't any.

    All written above lead to cleaning up uninitialized fields. Even if we hide
    ODEBUG warning by initializing bat_priv->nc.work, syzbot was able to hit
    GPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]

    To fix these bugs we can unwind batadv_*_init() calls one by one.
    It is good approach for 2 reasons: 1) It fixes bugs on error handling
    path 2) It improves the performance, since we won't call unneeded
    batadv_*_free() functions.

    So, this patch makes all batadv_*_init() clean up all allocated memory
    before returning with an error to no call correspoing batadv_*_free()
    and open-codes batadv_mesh_free() with proper order to avoid touching
    uninitialized fields.

    Link: https://lore.kernel.org/netdev/[email protected]/ [1]
    Reported-and-tested-by: [email protected]
    Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
    Signed-off-by: Pavel Skripkin <[email protected]>
    Acked-by: Sven Eckelmann <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3dae1a4eced3ee733d7222e69b8a55caf2d61091
Author: Yang Yingliang <[email protected]>
Date:   Tue Oct 12 10:37:35 2021 +0800

    regmap: Fix possible double-free in regcache_rbtree_exit()

    commit 55e6d8037805b3400096d621091dfbf713f97e83 upstream.

    In regcache_rbtree_insert_to_block(), when 'present' realloc failed,
    the 'blk' which is supposed to assign to 'rbnode->block' will be freed,
    so 'rbnode->block' points a freed memory, in the error handling path of
    regcache_rbtree_init(), 'rbnode->block' will be freed again in
    regcache_rbtree_exit(), KASAN will report double-free as follows:

    BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390
    Call Trace:
     slab_free_freelist_hook+0x10d/0x240
     kfree+0xce/0x390
     regcache_rbtree_exit+0x15d/0x1a0
     regcache_rbtree_init+0x224/0x2c0
     regcache_init+0x88d/0x1310
     __regmap_init+0x3151/0x4a80
     __devm_regmap_init+0x7d/0x100
     madera_spi_probe+0x10f/0x333 [madera_spi]
     spi_probe+0x183/0x210
     really_probe+0x285/0xc30

    To fix this, moving up the assignment of rbnode->block to immediately after
    the reallocation has succeeded so that the data structure stays valid even
    if the second reallocation fails.

    Reported-by: Hulk Robot <[email protected]>
    Fixes: 3f4ff561bc88b ("regmap: rbtree: Make cache_present bitmap per node")
    Signed-off-by: Yang Yingliang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cdaf7a469244b5e65ae5eda062ff5ea90172de62
Author: Clément Bœsch <[email protected]>
Date:   Sun Sep 5 02:20:27 2021 +0200

    arm64: dts: allwinner: h5: NanoPI Neo 2: Fix ethernet node

    commit 0764e365dacd0b8f75c1736f9236be280649bd18 upstream.

    RX and TX delay are provided by ethernet PHY. Reflect that in ethernet
    node.

    Fixes: 44a94c7ef989 ("arm64: dts: allwinner: H5: Restore EMAC changes")
    Signed-off-by: Clément Bœsch <[email protected]>
    Reviewed-by: Jernej Skrabec <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Maxime Ripard <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2864b6d54244b82a8c7d4628a43055c57bfba80c
Author: Patrisious Haddad <[email protected]>
Date:   Wed Oct 6 12:31:53 2021 +0300

    RDMA/mlx5: Set user priority for DCT

    commit 1ab52ac1e9bc9391f592c9fa8340a6e3e9c36286 upstream.

    Currently, the driver doesn't set the PCP-based priority for DCT, hence
    DCT response packets are transmitted without user priority.

    Fix it by setting user provided priority in the eth_prio field in the DCT
    context, which in turn sets the value in the transmitted packet.

    Fixes: 776a3906b692 ("IB/mlx5: Add support for DC target QP")
    Link: https://lore.kernel.org/r/5fd2d94a13f5742d8803c218927322257d53205c.1633512672.git.leonro@nvidia.com
    Signed-off-by: Patrisious Haddad <[email protected]>
    Reviewed-by: Maor Gottlieb <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 326da4f6ffdbd8671e86f69ded7a714dcc12fecf
Author: Johan Hovold <[email protected]>
Date:   Tue Oct 26 12:36:17 2021 +0200

    net: lan78xx: fix division by zero in send path

    commit db6c3c064f5d55fa9969f33eafca3cdbefbb3541 upstream.

    Add the missing endpoint max-packet sanity check to probe() to avoid
    division by zero in lan78xx_tx_bh() in case a malicious device has
    broken descriptors (or when doing descriptor fuzz testing).

    Note that USB core will reject URBs submitted for endpoints with zero
    wMaxPacketSize but that drivers doing packet-size calculations still
    need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
    endpoint descriptors with maxpacket=0")).

    Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
    Cc: [email protected]      # 4.3
    Cc: [email protected] <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2ff5289793fd61c56ac8774408f27350e5da865f
Author: Haibo Chen <[email protected]>
Date:   Fri Oct 15 10:00:36 2021 +0800

    mmc: sdhci-esdhc-imx: clear the buffer_read_ready to reset standard tuning circuit

    commit 9af372dc70e9fdcbb70939dac75365e7b88580b4 upstream.

    To reset standard tuning circuit completely, after clear ESDHC_MIX_CTRL_EXE_TUNE,
    also need to clear bit buffer_read_ready, this operation will finally clear the
    USDHC IP internal logic flag execute_tuning_with_clr_buf, make sure the following
    normal data transfer will not be impacted by standard tuning logic used before.

    Find this issue when do quick SD card insert/remove stress test. During standard
    tuning prodedure, if remove SD card, USDHC standard tuning logic can't clear the
    internal flag execute_tuning_with_clr_buf. Next time when insert SD card, all
    data related commands can't get any data related interrupts, include data transfer
    complete interrupt, data timeout interrupt, data CRC interrupt, data end bit interrupt.
    Always trigger software timeout issue. Even reset the USDHC through bits in register
    SYS_CTRL (0x2C, bit28 reset tuning, bit26 reset data, bit 25 reset command, bit 24
    reset all) can't recover this. From the user's point of view, USDHC stuck, SD can't
    be recognized any more.

    Fixes: d9370424c948 ("mmc: sdhci-esdhc-imx: reset tuning circuit when power on mmc card")
    Signed-off-by: Haibo Chen <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7824414c2903e2cfe56ea610387a22c0c88fb468
Author: Shawn Guo <[email protected]>
Date:   Mon Oct 4 10:49:35 2021 +0800

    mmc: sdhci: Map more voltage level to SDHCI_POWER_330

    commit 4217d07b9fb328751f877d3bd9550122014860a2 upstream.

    On Thundercomm TurboX CM2290, the eMMC OCR reports vdd = 23 (3.5 ~ 3.6 V),
    which is being treated as an invalid value by sdhci_set_power_noreg().
    And thus eMMC is totally broken on the platform.

    [    1.436599] ------------[ cut here ]------------
    [    1.436606] mmc0: Invalid vdd 0x17
    [    1.436640] WARNING: CPU: 2 PID: 69 at drivers/mmc/host/sdhci.c:2048 sdhci_set_power_noreg+0x168/0x2b4
    [    1.436655] Modules linked in:
    [    1.436662] CPU: 2 PID: 69 Comm: kworker/u8:1 Tainted: G        W         5.15.0-rc1+ #137
    [    1.436669] Hardware name: Thundercomm TurboX CM2290 (DT)
    [    1.436674] Workqueue: events_unbound async_run_entry_fn
    [    1.436685] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [    1.436692] pc : sdhci_set_power_noreg+0x168/0x2b4
    [    1.436698] lr : sdhci_set_power_noreg+0x168/0x2b4
    [    1.436703] sp : ffff800010803a60
    [    1.436705] x29: ffff800010803a60 x28: ffff6a9102465f00 x27: ffff6a9101720a70
    [    1.436715] x26: ffff6a91014de1c0 x25: ffff6a91014de010 x24: ffff6a91016af280
    [    1.436724] x23: ffffaf7b1b276640 x22: 0000000000000000 x21: ffff6a9101720000
    [    1.436733] x20: ffff6a9101720370 x19: ffff6a9101720580 x18: 0000000000000020
    [    1.436743] x17: 0000000000000000 x16: 0000000000000004 x15: ffffffffffffffff
    [    1.436751] x14: 0000000000000000 x13: 00000000fffffffd x12: ffffaf7b1b84b0bc
    [    1.436760] x11: ffffaf7b1b720d10 x10: 000000000000000a x9 : ffff800010803a60
    [    1.436769] x8 : 000000000000000a x7 : 000000000000000f x6 : 00000000fffff159
    [    1.436778] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff
    [    1.436787] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff6a9101718d80
    [    1.436797] Call trace:
    [    1.436800]  sdhci_set_power_noreg+0x168/0x2b4
    [    1.436805]  sdhci_set_ios+0xa0/0x7fc
    [    1.436811]  mmc_power_up.part.0+0xc4/0x164
    [    1.436818]  mmc_start_host+0xa0/0xb0
    [    1.436824]  mmc_add_host+0x60/0x90
    [    1.436830]  __sdhci_add_host+0x174/0x330
    [    1.436836]  sdhci_msm_probe+0x7c0/0x920
    [    1.436842]  platform_probe+0x68/0xe0
    [    1.436850]  really_probe.part.0+0x9c/0x31c
    [    1.436857]  __driver_probe_device+0x98/0x144
    [    1.436863]  driver_probe_device+0xc8/0x15c
    [    1.436869]  __device_attach_driver+0xb4/0x120
    [    1.436875]  bus_for_each_drv+0x78/0xd0
    [    1.436881]  __device_attach_async_helper+0xac/0xd0
    [    1.436888]  async_run_entry_fn+0x34/0x110
    [    1.436895]  process_one_work+0x1d0/0x354
    [    1.436903]  worker_thread+0x13c/0x470
    [    1.436910]  kthread+0x150/0x160
    [    1.436915]  ret_from_fork+0x10/0x20
    [    1.436923] ---[ end trace fcfac44cb045c3a8 ]---

    Fix the issue by mapping MMC_VDD_35_36 (and MMC_VDD_34_35) to
    SDHCI_POWER_330 as well.

    Signed-off-by: Shawn Guo <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 29d56f3790e684e630d56f500b59e834fa382209
Author: Jaehoon Chung <[email protected]>
Date:   Fri Oct 22 17:21:06 2021 +0900

    mmc: dw_mmc: exynos: fix the finding clock sample value

    commit 697542bceae51f7620af333b065dd09d213629fb upstream.

    Even though there are candiates value if can't find best value, it's
    returned -EIO. It's not proper behavior.
    If there is not best value, use a first candiate value to work eMMC.

    Signed-off-by: Jaehoon Chung <[email protected]>
    Tested-by: Marek Szyprowski <[email protected]>
    Tested-by: Christian Hewitt <[email protected]>
    Cc: [email protected]
    Fixes: c537a1c5ff63 ("mmc: dw_mmc: exynos: add variable delay tuning sequence")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 24f8658690477e8983f88cbfe21fb7f4062ad837
Author: Wenbin Mei <[email protected]>
Date:   Tue Oct 26 15:08:12 2021 +0800

    mmc: cqhci: clear HALT state after CQE enable

    commit 92b18252b91de567cd875f2e84722b10ab34ee28 upstream.

    While mmc0 enter suspend state, we need halt CQE to send legacy cmd(flush
    cache) and disable cqe, for resume back, we enable CQE and not clear HALT
    state.
    In this case MediaTek mmc host controller will keep the value for HALT
    state after CQE disable/enable flow, so the next CQE transfer after resume
    will be timeout due to CQE is in HALT state, the log as below:
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: timeout for tag 2
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: ============ CQHCI REGISTER DUMP ===========
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Caps:      0x100020b6 | Version:  0x00000510
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Config:    0x00001103 | Control:  0x00000001
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Int stat:  0x00000000 | Int enab: 0x00000006
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Int sig:   0x00000006 | Int Coal: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: TDL base:  0xfd05f000 | TDL up32: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Doorbell:  0x8000203c | TCN:      0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Task clr:  0x00000000 | SSC1:     0x00001000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: SSC2:      0x00000001 | DCMD rsp: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: RED mask:  0xfdf9a080 | TERRI:    0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Resp idx:  0x00000000 | Resp arg: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: CRNQP:     0x00000000 | CRNQDUN:  0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: CRNQIS:    0x00000000 | CRNQIE:   0x00000000

    This change check HALT state after CQE enable, if CQE is in HALT state, we
    will clear it.

    Signed-off-by: Wenbin Mei <[email protected]>
    Cc: [email protected]
    Acked-by: Adrian Hunter <[email protected]>
    Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 99641238575c26c2e47fa593f562dae476709d68
Author: Johan Hovold <[email protected]>
Date:   Mon Oct 25 13:56:08 2021 +0200

    mmc: vub300: fix control-message timeouts

    commit 8c8171929116cc23f74743d99251eedadf62341a upstream.

    USB control-message timeouts are specified in milliseconds and should
    specifically not vary with CONFIG_HZ.

    Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
    Cc: [email protected]      # 3.0
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c6d0d68d6da68159948cad3d808d61bb291a0283
Author: Eric Dumazet <[email protected]>
Date:   Sun Aug 29 15:16:14 2021 -0700

    ipv6: make exception cache less predictible

    commit a00df2caffed3883c341d5685f830434312e4a43 upstream.

    Even after commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()"),
    an attacker can still use brute force to learn some secrets from a victim
    linux host.

    One way to defeat these attacks is to make the max depth of the hash
    table bucket a random value.

    Before this patch, each bucket of the hash table used to store exceptions
    could contain 6 items under attack.

    After the patch, each bucket would contains a random number of items,
    between 6 and 10. The attacker can no longer infer secrets.

    This is slightly increasing memory size used by the hash table,
    we do not expect this to be a problem.

    Following patch is dealing with the same issue in IPv4.

    Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Keyu Man <[email protected]>
    Cc: Wei Wang <[email protected]>
    Cc: Martin KaFai Lau <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    [OP: adjusted context for 4.19 stable]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ad829847ad59af8e26a1f1c345716099abbc7a58
Author: Eric Dumazet <[email protected]>
Date:   Fri Oct 29 10:50:26 2021 +0300

    ipv6: use siphash in rt6_exception_hash()

    commit 4785305c05b25a242e5314cc821f54ade4c18810 upstream.

    A group of security researchers brought to our attention
    the weakness of hash function used in rt6_exception_hash()

    Lets use siphash instead of Jenkins Hash, to considerably
    reduce security risks.

    Following patch deals with IPv4.

    Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Keyu Man <[email protected]>
    Cc: Wei Wang <[email protected]>
    Cc: Martin KaFai Lau <[email protected]>
    Acked-by: Wei Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    [OP: adjusted context for 4.19 stable]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6e2856767eb1a9cfcfcd82136928037f04920e97
Author: Eric Dumazet <[email protected]>
Date:   Fri Oct 29 10:50:25 2021 +0300

    ipv4: use siphash instead of Jenkins in fnhe_hashfun()

    commit 6457378fe796815c973f631a1904e147d6ee33b1 upstream.

    A group of security researchers brought to our attention
    the weakness of hash function used in fnhe_hashfun().

    Lets use siphash instead of Jenkins Hash, to considerably
    reduce security risks.

    Also remove the inline keyword, this really is distracting.

    Fixes: d546c621542d ("ipv4: harden fnhe_hashfun()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Keyu Man <[email protected]>
    Cc: Willy Tarreau <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    [OP: adjusted context for 4.19 stable]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8121d0d4fd108280f5cd7b7fe8c6592adaa37be9
Author: Pavel Skripkin <[email protected]>
Date:   Thu Sep 30 20:49:42 2021 +0300

    Revert "net: mdiobus: Fix memory leak in __mdiobus_register"

    commit 10eff1f5788b6ffac212c254e2f3666219576889 upstream.

    This reverts commit ab609f25d19858513919369ff3d9a63c02cd9e2e.

    This patch is correct in the sense that we _should_ call device_put() in
    case of device_register() failure, but the problem in this code is more
    vast.

    We need to set bus->state to UNMDIOBUS_REGISTERED before calling
    device_register() to correctly release the device in mdiobus_free().
    This patch prevents us from doing it, since in case of device_register()
    failure put_device() will be called 2 times and it will cause UAF or
    something else.

    Also, Reported-by: tag in revered commit was wrong, since syzbot
    reported different leak in same function.

    Link: https://lore.kernel.org/netdev/20210928092657.GI2048@kadam/
    Acked-by: Yanfei Xu <[email protected]>
    Signed-off-by: Pavel Skripkin <[email protected]>
    Link: https://lore.kernel.org/r/f12fb1faa4eccf0f355788225335eb4309ff2599.1633024062.git.paskripkin@gmail.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4a9043ba1b0e9bea1da0fe34366222974f2c0f92
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Oct 25 16:49:36 2021 +0200

    nfc: port100: fix using -ERRNO as command type mask

    commit 2195f2062e4cc93870da8e71c318ef98a1c51cef upstream.

    During probing, the driver tries to get a list (mask) of supported
    command types in port100_get_command_type_mask() function.  The value
    is u64 and 0 is treated as invalid mask (no commands supported).  The
    function however returns also -ERRNO as u64 which will be interpret as
    valid command mask.

    Return 0 on every error case of port100_get_command_type_mask(), so the
    probing will stop.

    Cc: <[email protected]>
    Fixes: 0347a6ab300a ("NFC: port100: Commands mechanism implementation")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a36119f9b3fb069437383a8eff4e65181b6e7e2f
Author: Zheyu Ma <[email protected]>
Date:   Fri Oct 22 09:12:26 2021 +0000

    ata: sata_mv: Fix the error handling of mv_chip_id()

    commit a0023bb9dd9bc439d44604eeec62426a990054cd upstream.

    mv_init_host() propagates the value returned by mv_chip_id() which in turn
    gets propagated by mv_pci_init_one() and hits local_pci_probe().

    During the process of driver probing, the probe function should return < 0
    for failure, otherwise, the kernel will treat value > 0 as success.

    Since this is a bug rather than a recoverable runtime error we should
    use dev_alert() instead of dev_err().

    Signed-off-by: Zheyu Ma <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 78c2dc1cdf0bdfc83e473d78f23da4d2aeb98142
Author: Wang Hai <[email protected]>
Date:   Tue Oct 26 20:40:15 2021 +0800

    usbnet: fix error return code in usbnet_probe()

    commit 6f7c88691191e6c52ef2543d6f1da8d360b27a24 upstream.

    Return error code if usb_maxpacket() returns 0 in usbnet_probe()

    Fixes: 397430b50a36 ("usbnet: sanity check for maxpacket")
    Reported-by: Hulk Robot <[email protected]>
    Signed-off-by: Wang Hai <[email protected]>
    Reviewed-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 002d82227c0abe29118cf80f7e2f396b22d448ed
Author: Oliver Neukum <[email protected]>
Date:   Thu Oct 21 14:29:44 2021 +0200

    usbnet: sanity check for maxpacket

    commit 397430b50a363d8b7bdda00522123f82df6adc5e upstream.

    maxpacket of 0 makes no sense and oopses as we need to divide
    by it. Give up.

    V2: fixed typo in log and stylistic issues

    Signed-off-by: Oliver Neukum <[email protected]>
    Reported-by: [email protected]
    Reviewed-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d725978abb0bac6e0c427548dfd6db86709a2a1e
Author: Nathan Chancellor <[email protected]>
Date:   Sat Jan 5 19:35:25 2019 +0100

    ARM: 8819/1: Remove '-p' from LDFLAGS

    commit 091bb549f7722723b284f63ac665e2aedcf9dec9 upstream.

    This option is not supported by lld:

        ld.lld: error: unknown argument: -p

    This has been a no-op in binutils since 2004 (see commit dea514f51da1 in
    that tree). Given that the lowest officially supported of binutils for
    the kernel is 2.20, which was released in 2009, nobody needs this flag
    around so just remove it. Commit 1a381d4a0a9a ("arm64: remove no-op -p
    linker flag") did the same for arm64.

    Signed-off-by: Nathan Chancellor <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Acked-by: Nicolas Pitre <[email protected]>
    Reviewed-by: Nick Desaulniers <[email protected]>
    Reviewed-by: Stefan Agner <[email protected]>
    Signed-off-by: Russell King <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit aaf4e1b05cab800b36b40c1aa09f7c13ef30de56
Author: Robin Murphy <[email protected]>
Date:   Mon Jul 12 15:27:46 2021 +0100

    arm64: Avoid premature usercopy failure

    commit 295cf156231ca3f9e3a66bde7fab5e09c41835e0 upstream.

    Al reminds us that the usercopy API must only return complete failure
    if absolutely nothing could be copied. Currently, if userspace does
    something silly like giving us an unaligned pointer to Device memory,
    or a size which overruns MTE tag bounds, we may fail to honour that
    requirement when faulting on a multi-byte access even though a smaller
    access could have succeeded.

    Add a mitigation to the fixup routines to fall back to a single-byte
    copy if we faulted on a larger access before anything has been written
    to the destination, to guarantee making *some* forward progress. We
    needn't be too concerned about the overall performance since this should
    only occur when callers are doing something a bit dodgy in the first
    place. Particularly broken userspace might still be able to trick
    generic_perform_write() into an infinite loop by targeting write() at
    an mmap() of some read-only device register where the fault-in load
    succeeds but any store synchronously aborts such that copy_to_user() is
    genuinely unable to make progress, but, well, don't do that...

    CC: [email protected]
    Reported-by: Chen Huang <[email protected]>
    Suggested-by: Al Viro <[email protected]>
    Reviewed-by: Catalin Marinas <[email protected]>
    Signed-off-by: Robin Murphy <[email protected]>
    Link: https://lore.kernel.org/r/dc03d5c675731a1f24a62417dba5429ad744234e.1626098433.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Chen Huang <[email protected]>

commit 5909b851b5e11d04f299e5f0a8937e9dcc807248
Author: Naveen N. Rao <[email protected]>
Date:   Wed Oct 6 01:55:22 2021 +0530

    powerpc/bpf: Fix BPF_MOD when imm == 1

    commit 8bbc9d822421d9ac8ff9ed26a3713c9afc69d6c8 upstream.

    Only ignore the operation if dividing by 1.

    Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
    Signed-off-by: Naveen N. Rao <[email protected]>
    Tested-by: Johan Almbladh <[email protected]>
    Reviewed-by: Christophe Leroy <[email protected]>
    Acked-by: Song Liu <[email protected]>
    Acked-by: Johan Almbladh <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/c674ca18c3046885602caebb326213731c675d06.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
    [cascardo: use PPC_LI instead of EMIT(PPC_RAW_LI)]
    Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 901741a53d7cf45be861e881c0e3cba5b4bd1f94
Author: Arnd Bergmann <[email protected]>
Date:   Mon Oct 18 15:30:37 2021 +0100

    ARM: 9141/1: only warn about XIP address when not compile testing

    commit 48ccc8edf5b90622cdc4f8878e0042ab5883e2ca upstream.

    In randconfig builds, we sometimes come across this warning:

    arm-linux-gnueabi-ld: XIP start address may cause MPU programming issues

    While this is helpful for actual systems to figure out why it
    fails, the warning does not provide any benefit for build testing,
    so guard it in a check for CONFIG_COMPILE_TEST, which is usually
    set on randconfig builds.

    Fixes: 216218308cfb ("ARM: 8713/1: NOMMU: Support MPU in XIP configuration")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ee4b38ce37ed31beca29d3ebec7db3d5e87fe39e
Author: Arnd Bergmann <[email protected]>
Date:   Mon Oct 18 15:30:09 2021 +0100

    ARM: 9139/1: kprobes: fix arch_init_kprobes() prototype

    commit 1f323127cab086e4fd618981b1e5edc396eaf0f4 upstream.

    With extra warnings enabled, gcc complains about this function
    definition:

    arch/arm/probes/kprobes/core.c: In function 'arch_init_kprobes':
    arch/arm/probes/kprobes/core.c:465:12: warning: old-style function definition [-Wold-style-definition]
      465 | int __init arch_init_kprobes()

    Link: https://lore.kernel.org/all/[email protected]/

    Fixes: 24ba613c9d6c ("ARM kprobes: core code")
    Acked-by: Masami Hiramatsu <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c0b4f1db7feef31d401814121760b45aff7885c1
Author: Arnd Bergmann <[email protected]>
Date:   Mon Oct 18 15:30:04 2021 +0100

    ARM: 9134/1: remove duplicate memcpy() definition

    commit eaf6cc7165c9c5aa3c2f9faa03a98598123d0afb upstream.

    Both the decompressor code and the kasan logic try to override
    the memcpy() and memmove()  definitions, which leading to a clash
    in a KASAN-enabled kernel with XZ decompression:

    arch/arm/boot/compressed/decompress.c:50:9: error: 'memmove' macro redefined [-Werror,-Wmacro-redefined]
     #define memmove memmove
            ^
    arch/arm/include/asm/string.h:59:9: note: previous definition is here
     #define memmove(dst, src, len) __memmove(dst, src, len)
            ^
    arch/arm/boot/compressed/decompress.c:51:9: error: 'memcpy' macro redefined [-Werror,-Wmacro-redefined]
     #define memcpy memcpy
            ^
    arch/arm/include/asm/string.h:58:9: note: previous definition is here
     #define memcpy(dst, src, len) __memcpy(dst, src, len)
            ^

    Here we want the set of functions from the decompressor, so undefine
    the other macros before the override.

    Link: https://lore.kernel.org/linux-arm-kernel/CACRpkdZYJogU_SN3H9oeVq=zJkRgRT1gDz3xp59gdqWXxw-B=w@mail.gmail.com/
    Link: https://lore.kernel.org/lkml/[email protected]/

    Fixes: d6d51a96c7d6 ("ARM: 9014/2: Replace string mem* functions for KASan")
    Fixes: a7f464f3db93 ("ARM: 7001/2: Wire up support for the XZ decompressor")
    Reported-by: kernel test robot <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 00dcbb2d2cd3594faa2f977f2f7175cf23d4e326
Author: Nick Desaulniers <[email protected]>
Date:   Mon Oct 4 18:03:28 2021 +0100

    ARM: 9133/1: mm: proc-macros: ensure *_tlb_fns are 4B aligned

    commit e6a0c958bdf9b2e1b57501fc9433a461f0a6aadd upstream.

    A kernel built with CONFIG_THUMB2_KERNEL=y and using clang as the
    assembler could generate non-naturally-aligned v7wbi_tlb_fns which
    results in a boot failure. The original commit adding the macro missed
    the .align directive on this data.

    Link: https://github.com/ClangBuiltLinux/linux/issues/1447
    Link: https://lore.kernel.org/all/[email protected]/
    Debugged-by: Ard Biesheuvel <[email protected]>
    Debugged-by: Nathan Chancellor <[email protected]>
    Debugged-by: Richard Henderson <[email protected]>

    Fixes: 66a625a88174 ("ARM: mm: proc-macros: Add generic proc/cache/tlb struct definition macros")
    Suggested-by: Ard Biesheuvel <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Nick Desaulniers <[email protected]>
    Tested-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 38ec06730e44b2166e87fecca9e36380080801ac
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed Oct 27 09:53:15 2021 +0200

    Linux 4.19.214

    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Sudip Mukherjee <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0b7d55ca605e611aceeadf7c29c75808faae951a
Author: Nick Desaulniers <[email protected]>
Date:   Wed Sep 8 19:25:59 2021 +0100

    ARM: 9122/1: select HAVE_FUTEX_CMPXCHG

    commit 9d417cbe36eee7afdd85c2e871685f8dab7c2dba upstream.

    tglx notes:
      This function [futex_detect_cmpxchg] is only needed when an
      architecture has to runtime discover whether the CPU supports it or
      not.  ARM has unconditional support for this, so the obvious thing to
      do is the below.

    Fixes linkage failure from Clang randconfigs:
    kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit: R_ARM_JUMP24 against `.init.text'
    and boot failures for CONFIG_THUMB2_KERNEL.

    Link: https://github.com/ClangBuiltLinux/linux/issues/325

    Comments from Nick Desaulniers:

     See-also: 03b8c7b623c8 ("futex: Allow architectures to skip
     futex_atomic_cmpxchg_inatomic() test")

    Reported-by: Arnd Bergmann <[email protected]>
    Reported-by: Nathan Chancellor <[email protected]>
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Nick Desaulniers <[email protected]>
    Reviewed-by: Thomas Gleixner <[email protected]>
    Tested-by: Nathan Chancellor <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Cc: [email protected] # v3.14+
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3de1ed125fc4c35bf7abb08260646100a6dcb04e
Author: Steven Rostedt (VMware) <[email protected]>
Date:   Mon Oct 18 15:44:12 2021 -0400

    tracing: Have all levels of checks prevent recursion

    commit ed65df63a39a3f6ed04f7258de8b6789e5021c18 upstream.

    While writing an email explaining the "bit = 0" logic for a discussion on
    making ftrace_test_recursion_trylock() disable preemption, I discovered a
    path that makes the "not do the logic if bit is zero" unsafe.

    The recursion logic is done in hot paths like the function tracer. Thus,
    any code executed causes noticeable overhead. Thus, tricks are done to try
    to limit the amount of code executed. This included the recursion testing
    logic.

    Having recursion testing is important, as there are many paths that can
    end up in an infinite recursion cycle when tracing every function in the
    kernel. Thus protection is needed to prevent that from happening.

    Because it is OK to recurse due to different running context levels (e.g.
    an interrupt preempts a trace, and then a trace occurs in the interrupt
    handler), a set of bits are used to know which context one is in (normal,
    softirq, irq and NMI). If a recursion occurs in the same level, it is
    prevented*.

    Then there are infrastructure levels of recursion as well. When more than
    one callback is attached to the same function to trace, it calls a loop
    function to iterate over all the callbacks. Both the callbacks and the
    loop function have recursion protection. The callbacks use the
    "ftrace_test_recursion_trylock()" which has a "function" set of context
    bits to test, and the loop function calls the internal
    trace_test_and_set_recursion() directly, with an "internal" set of bits.

    If an architecture does not implement all the features supported by ftrace
    then the callbacks are never called directly, and the loop function is
    called instead, which will implement the features of ftrace.

    Since both the loop function and the callbacks do recursion protection, it
    was seemed unnecessary to do it in both locations. Thus, a trick was made
    to have the internal set of recursion bits at a more significant bit
    location than the function bits. Then, if any of the higher bits were set,
    the logic of the function bits could be skipped, as any new recursion
    would first have to go through the loop function.

    This is true for architectures that do not support all the ftrace
    features, because all functions being traced must first go through the
    loop function before going to the callbacks. But this is not true for
    architectures that support all the ftrace features. That's because the
    loop function could be called due to two callbacks attached to the same
    function, but then a recursion function inside the callback could be
    called that does not share any other callback, and it will be called
    directly.

    i.e.

     traced_function_1: [ more than one callback tracing it ]
       call loop_func

     loop_func:
       trace_recursion set internal bit
       call callback

     callback:
       trace_recursion [ skipped because internal bit is set, return 0 ]
       call traced_function_2

     traced_function_2: [ only traced by above callback ]
       call callback

     callback:
       trace_recursion [ skipped because internal bit is set, return 0 ]
       call traced_function_2

     [ wash, rinse, repeat, BOOM! out of shampoo! ]

    Thus, the "bit == 0 skip" trick is not safe, unless the loop function is
    call for all functions.

    Since we want to encourage architectures to implement all ftrace features,
    having them slow down due to this extra logic may encourage the
    maintainers to update to the latest ftrace features. And because this
    logic is only safe for them, remove it completely.

     [*] There is on layer of recursion that is allowed, and that is to allow
         for the transition between interrupt context (normal -> softirq ->
         irq -> NMI), because a trace may occur before the context update is
         visible to the trace recursion logic.

    Link: https://lore.kernel.org/all/[email protected]/
    Link: https://lkml.kernel.org/r/[email protected]

    Cc: Linus Torvalds <[email protected]>
    Cc: Petr Mladek <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: "James E.J. Bottomley" <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: Michael Ellerman <[email protected]>
    Cc: Benjamin Herrenschmidt <[email protected]>
    Cc: Paul Mackerras <[email protected]>
    Cc: Paul Walmsley <[email protected]>
    Cc: Palmer Dabbelt <[email protected]>
    Cc: Albert Ou <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: Josh Poimboeuf <[email protected]>
    Cc: Jiri Kosina <[email protected]>
    Cc: Miroslav Benes <[email protected]>
    Cc: Joe Lawrence <[email protected]>
    Cc: Colin Ian King <[email protected]>
    Cc: Masami Hiramatsu <[email protected]>
    Cc: "Peter Zijlstra (Intel)" <[email protected]>
    Cc: Nicholas Piggin <[email protected]>
    Cc: Jisheng Zhang <[email protected]>
    Cc: =?utf-8?b?546L6LSH?= <[email protected]>
    Cc: Guo Ren <[email protected]>
    Cc: [email protected]
    Fixes: edc15cafcbfa3 ("tracing: Avoid unnecessary multiple recursion checks")
    Signed-off-by: Steven Rostedt (VMware) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a9831afa2dc8a18205403907c41aa4e0950ac611
Author: Yanfei Xu <[email protected]>
Date:   Sun Sep 26 12:53:13 2021 +0800

    net: mdiobus: Fix memory leak in __mdiobus_register

    commit ab609f25d19858513919369ff3d9a63c02cd9e2e upstream.

    Once device_register() failed, we should call put_device() to
    decrement reference count for cleanup. Or it will cause memory
    leak.

    BUG: memory leak
    unreferenced object 0xffff888114032e00 (size 256):
      comm "kworker/1:3", pid 2960, jiffies 4294943572 (age 15.920s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 08 2e 03 14 81 88 ff ff  ................
        08 2e 03 14 81 88 ff ff 90 76 65 82 ff ff ff ff  .........ve.....
      backtrace:
        [<ffffffff8265cfab>] kmalloc include/linux/slab.h:591 [inline]
        [<ffffffff8265cfab>] kzalloc include/linux/slab.h:721 [inline]
        [<ffffffff8265cfab>] device_private_init drivers/base/core.c:3203 [inline]
        [<ffffffff8265cfab>] device_add+0x89b/0xdf0 drivers/base/core.c:3253
        [<ffffffff828dd643>] __mdiobus_register+0xc3/0x450 drivers/net/phy/mdio_bus.c:537
        [<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
        [<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
        [<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
        [<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
        [<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
        [<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
        [<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
        [<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
        [<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
        [<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
        [<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
        [<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
        [<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969
        [<ffffffff82660916>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
        [<ffffffff8265cd0b>] device_add+0x5fb/0xdf0 drivers/base/core.c:3359
        [<ffffffff82c343b9>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2170
        [<ffffffff82c4473c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238

    BUG: memory leak
    unreferenced object 0xffff888116f06900 (size 32):
      comm "kworker/0:2", pid 2670, jiffies 4294944448 (age 7.160s)
      hex dump (first 32 bytes):
        75 73 62 2d 30 30 31 3a 30 30 33 00 00 00 00 00  usb-001:003.....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff81484516>] kstrdup+0x36/0x70 mm/util.c:60
        [<ffffffff814845a3>] kstrdup_const+0x53/0x80 mm/util.c:83
        [<ffffffff82296ba2>] kvasprintf_const+0xc2/0x110 lib/kasprintf.c:48
        [<ffffffff82358d4b>] kobject_set_name_vargs+0x3b/0xe0 lib/kobject.c:289
        [<ffffffff826575f3>] dev_set_name+0x63/0x90 drivers/base/core.c:3147
        [<ffffffff828dd63b>] __mdiobus_register+0xbb/0x450 drivers/net/phy/mdio_bus.c:535
        [<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
        [<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
        [<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
        [<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
        [<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
        [<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
        [<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
        [<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
        [<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
        [<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
        [<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
        [<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
        [<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969

    Reported-by: [email protected]
    Signed-off-by: Yanfei Xu <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 629e870ca473bbf3ec2429d441efb0406869783d
Author: Dexuan Cui <[email protected]>
Date:   Thu Oct 7 21:35:46 2021 -0700

    scsi: core: Fix shost->cmd_per_lun calculation in scsi_add_host_with_dma()

    commit 50b6cb3516365cb69753b006be2b61c966b70588 upstream.

    After commit ea2f0f77538c ("scsi: core: Cap scsi_host cmd_per_lun at
    can_queue"), a 416-CPU VM running on Hyper-V hangs during boot because the
    hv_storvsc driver sets scsi_driver.can_queue to an integer value that
    exceeds SHRT_MAX, and hence scsi_add_host_with_dma() sets
    shost->cmd_per_lun to a negative "short" value.

    Use min_t(int, ...) to work around the issue.

    Link: https://lore.kernel.org/r/[email protected]
    Fixes: ea2f0f77538c ("scsi: core: Cap scsi_host cmd_per_lun at can_queue")
    Cc: [email protected]
    Reviewed-by: Haiyang Zhang <[email protected]>
    Reviewed-by: Ming Lei <[email protected]>
    Reviewed-by: John Garry <[email protected]>
    Signed-off-by: Dexuan Cui <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1360f9cde7eaaea4e6b48ab4ec544c706dbc6a8a
Author: Kai Vehmanen <[email protected]>
Date:   Tue Oct 12 17:29:35 2021 +0300

    ALSA: hda: avoid write to STATESTS if controller is in reset

    [ Upstream commit b37a15188eae9d4c49c5bb035e0c8d4058e4d9b3 ]

    The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
    before performing controller reset. This code dates back to an old
    bugfix in commit e8a7f136f5ed ("[ALSA] hda-intel - Improve HD-audio
    codec probing robustness"). Originally the code was added to
    azx_reset().

    The code was moved around in commit a41d122449be ("ALSA: hda - Embed bus
    into controller object") and ended up to snd_hdac_bus_reset_link() and
    called primarily via snd_hdac_bus_init_chip().

    The logic to clear STATESTS is correct when snd_hdac_bus_init_chip() is
    called when controller is not in reset. In this case, STATESTS can be
    cleared. This can be useful e.g. when forcing a controller reset to retry
    codec probe. A normal non-power-on reset will not clear the bits.

    However, this old logic is problematic when controller is already in
    reset. The HDA specification states that controller must be taken out of
    reset before writing to registers other than GCTL.CRST (1.0a spec,
    3.3.7). The write to STATESTS in snd_hdac_bus_reset_link() will be lost
    if the controller is already in reset per the HDA specification mentioned.

    This has been harmless on older hardware. On newer generation of Intel
    PCIe based HDA controllers, if configured to report issues, this write
    will emit an unsupported request error. If ACPI Platform Error Interface
    (APEI) is enabled in kernel, this will end up to kernel log.

    Fix the code in snd_hdac_bus_reset_link() to only clear the STATESTS if
    the function is called when controller is not in reset. Otherwise
    clearing the bits is not possible and should be skipped.

    Signed-off-by: Kai Vehmanen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit f7db1bc1cdb809fdd65d50485fb67bd418eadbd5
Author: Prashant Malani <[email protected]>
Date:   Tue Sep 28 03:19:34 2021 -0700

    platform/x86: intel_scu_ipc: Update timeout value in comment

    [ Upstream commit a0c5814b9933f25ecb6de169483c5b88cf632bca ]

    The comment decribing the IPC timeout hadn't been updated when the
    actual timeout was changed from 3 to 5 seconds in
    commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual
    timeout from 3 to 5 seconds") .

    Since the value is anyway updated to 10s now, take this opportunity to
    update the value in the comment too.

    Signed-off-by: Prashant Malani <[email protected]>
    Cc: Benson Leung <[email protected]>
    Reviewed-by: Mika Westerberg <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a5b34409d3fc52114c828be4adbc30744fa3258b
Author: Zheyu Ma <[email protected]>
Date:   Sat Oct 9 11:33:49 2021 +0000

    isdn: mISDN: Fix sleeping function called from invalid context

    [ Upstream commit 6510e80a0b81b5d814e3aea6297ba42f5e76f73c ]

    The driver can call card->isac.release() function from an atomic
    context.

    Fix this by calling this function after releasing the lock.

    The following log reveals it:

    [   44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018
    [   44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe
    [   44.169574 ] INFO: lockdep is turned off.
    [   44.169899 ] irq event stamp: 0
    [   44.170160 ] hardirqs last  enabled at (0): [<0000000000000000>] 0x0
    [   44.170627 ] hardirqs last disabled at (0): [<ffffffff814209ed>] copy_process+0x132d/0x3e00
    [   44.171240 ] softirqs last  enabled at (0): [<ffffffff81420a1a>] copy_process+0x135a/0x3e00
    [   44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0
    [   44.172318 ] Preemption disabled at:
    [   44.172320 ] [<ffffffffa009b0a9>] nj_release+0x69/0x500 [netjet]
    [   44.174441 ] Call Trace:
    [   44.174630 ]  dump_stack_lvl+0xa8/0xd1
    [   44.174912 ]  dump_stack+0x15/0x17
    [   44.175166 ]  ___might_sleep+0x3a2/0x510
    [   44.175459 ]  ? nj_release+0x69/0x500 [netjet]
    [   44.175791 ]  __might_sleep+0x82/0xe0
    [   44.176063 ]  ? start_flush_work+0x20/0x7b0
    [   44.176375 ]  start_flush_work+0x33/0x7b0
    [   44.176672 ]  ? trace_irq_enable_rcuidle+0x85/0x170
    [   44.177034 ]  ? kasan_quarantine_put+0xaa/0x1f0
    [   44.177372 ]  ? kasan_quarantine_put+0xaa/0x1f0
    [   44.177711 ]  __flush_work+0x11a/0x1a0
    [   44.177991 ]  ? flush_work+0x20/0x20
    [   44.178257 ]  ? lock_release+0x13c/0x8f0
    [   44.178550 ]  ? __kasan_check_write+0x14/0x20
    [   44.178872 ]  ? do_raw_spin_lock+0x148/0x360
    [   44.179187 ]  ? read_lock_is_recursive+0x20/0x20
    [   44.179530 ]  ? __kasan_check_read+0x11/0x20
    [   44.179846 ]  ? do_raw_spin_unlock+0x55/0x900
    [   44.180168 ]  ? ____kasan_slab_free+0x116/0x140
    [   44.180505 ]  ? _raw_spin_unlock_irqrestore+0x41/0x60
    [   44.180878 ]  ? skb_queue_purge+0x1a3/0x1c0
    [   44.181189 ]  ? kfree+0x13e/0x290
    [   44.181438 ]  flush_work+0x17/0x20
    [   44.181695 ]  mISDN_freedchannel+0xe8/0x100
    [   44.182006 ]  isac_release+0x210/0x260 [mISDNipac]
    [   44.182366 ]  nj_release+0xf6/0x500 [netjet]
    [   44.182685 ]  nj_remove+0x48/0x70 [netjet]
    [   44.182989 ]  pci_device_remove+0xa9/0x250

    Signed-off-by: Zheyu Ma <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 207f6c3a82e19626aedad6e2f9aa0bb348495447
Author: Herve Codina <[email protected]>
Date:   Fri Oct 8 12:34:40 2021 +0200

    ARM: dts: spear3xx: Fix gmac node

    [ Upstream commit 6636fec29cdf6665bd219564609e8651f6ddc142 ]

    On SPEAr3xx, ethernet driver is not compatible with the SPEAr600
    one.
    Indeed, SPEAr3xx uses an earlier version of this IP (v3.40) and
    needs some driver tuning compare to SPEAr600.

    The v3.40 IP support was added to stmmac driver and this patch
    fixes this issue and use the correct compatible string for
    SPEAr3xx

    Signed-off-by: Herve Codina <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit cfe8c4a4d6eb21af53504c6b85393de2f8345685
Author: Herve Codina <[email protected]>
Date:   Fri Oct 8 12:34:39 2021 +0200

    net: stmmac: add support for dwmac 3.40a

    [ Upstream commit 9cb1d19f47fafad7dcf7c8564e633440c946cfd7 ]

    dwmac 3.40a is an old ip version that can be found on SPEAr3xx soc.

    Signed-off-by: Herve Codina <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit f03a8a85e91580f7881b24c24ab2e4e37d8080b1
Author: Filipe Manana <[email protected]>
Date:   Fri Oct 1 13:52:30 2021 +0100

    btrfs: deal with errors when checking if a dir entry exists during log replay

    [ Upstream commit 77a5b9e3d14cbce49ceed2766b2003c034c066dc ]

    Currently inode_in_dir() ignores errors returned from
    btrfs_lookup_dir_index_item() and from btrfs_lookup_dir_item(), treating
    any errors as if the directory entry does not exists in the fs/subvolume
    tree, which is obviously not correct, as we can get errors such as -EIO
    when reading extent buffers while searching the fs/subvolume's tree.

    Fix that by making inode_in_dir() return the errors and making its only
    caller, add_inode_ref(), deal…
warudooooo added a commit to warudooooo/android_kernel_sm6225_spes that referenced this issue Sep 20, 2023
…x/kernel/git/stable/linux-stable

commit 00a95330f3b295d4a581c36a5f2949c731386e37
Merge: 9e5a216016f0 a027d43cf3f2
Author: warudo <[email protected]>
Date:   Wed Sep 20 16:00:07 2023 +0800

    Merge tag 'v4.19.215'

    This is the 4.19.215 stable release

commit a027d43cf3f2fdaabf467b4bcb92d0fe748c2eaf
Author: Greg Kroah-Hartman <[email protected]>
Date:   Tue Nov 2 18:26:46 2021 +0100

    Linux 4.19.215

    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Hulk Robot <[email protected]>
    Tested-by: Sudip Mukherjee <[email protected]>
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1ff3c379248ea579aa122d4ca245028e4bc9af23
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:47 2021 -0400

    sctp: add vtag check in sctp_sf_ootb

    [ Upstream commit 9d02831e517aa36ee6bdb453a0eb47bd49923fe3 ]

    sctp_sf_ootb() is called when processing DATA chunk in closed state,
    and many other places are also using it.

    The vtag in the chunk's sctphdr should be verified, otherwise, as
    later in chunk length check, it may send abort with the existent
    asoc's vtag, which can be exploited by one to cook a malicious
    chunk to terminate a SCTP asoc.

    When fails to verify the vtag from the chunk, this patch sets asoc
    to NULL, so that the abort will be made with the vtag from the
    received chunk later.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit d9a4f990aab48dd5c134a9e76c7b651d404b05d3
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:46 2021 -0400

    sctp: add vtag check in sctp_sf_do_8_5_1_E_sa

    [ Upstream commit ef16b1734f0a176277b7bb9c71a6d977a6ef3998 ]

    sctp_sf_do_8_5_1_E_sa() is called when processing SHUTDOWN_ACK chunk
    in cookie_wait and cookie_echoed state.

    The vtag in the chunk's sctphdr should be verified, otherwise, as
    later in chunk length check, it may send abort with the existent
    asoc's vtag, which can be exploited by one to cook a malicious
    chunk to terminate a SCTP asoc.

    Note that when fails to verify the vtag from SHUTDOWN-ACK chunk,
    SHUTDOWN COMPLETE message will still be sent back to peer, but
    with the vtag from SHUTDOWN-ACK chunk, as said in 5) of
    rfc4960#section-8.4.

    While at it, also remove the unnecessary chunk length check from
    sctp_sf_shut_8_4_5(), as it's already done in both places where
    it calls sctp_sf_shut_8_4_5().

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 7bf2f6a30d1851c530ad5e4ee7e5c45fb6be0128
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:45 2021 -0400

    sctp: add vtag check in sctp_sf_violation

    [ Upstream commit aa0f697e45286a6b5f0ceca9418acf54b9099d99 ]

    sctp_sf_violation() is called when processing HEARTBEAT_ACK chunk
    in cookie_wait state, and some other places are also using it.

    The vtag in the chunk's sctphdr should be verified, otherwise, as
    later in chunk length check, it may send abort with the existent
    asoc's vtag, which can be exploited by one to cook a malicious
    chunk to terminate a SCTP asoc.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 86044244fc6f9eaec0070cb668e0d500de22dbba
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:44 2021 -0400

    sctp: fix the processing for COOKIE_ECHO chunk

    [ Upstream commit a64b341b8695e1c744dd972b39868371b4f68f83 ]

    1. In closed state: in sctp_sf_do_5_1D_ce():

      When asoc is NULL, making packet for abort will use chunk's vtag
      in sctp_ootb_pkt_new(). But when asoc exists, vtag from the chunk
      should be verified before using peer.i.init_tag to make packet
      for abort in sctp_ootb_pkt_new(), and just discard it if vtag is
      not correct.

    2. In the other states: in sctp_sf_do_5_2_4_dupcook():

      asoc always exists, but duplicate cookie_echo's vtag will be
      handled by sctp_tietags_compare() and then take actions, so before
      that we only verify the vtag for the abort sent for invalid chunk
      length.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 1f52dfacca7bb315d89f5ece5660b0337809798e
Author: Xin Long <[email protected]>
Date:   Wed Oct 20 07:42:41 2021 -0400

    sctp: use init_tag from inithdr for ABORT chunk

    [ Upstream commit 4f7019c7eb33967eb87766e0e4602b5576873680 ]

    Currently Linux SCTP uses the verification tag of the existing SCTP
    asoc when failing to process and sending the packet with the ABORT
    chunk. This will result in the peer accepting the ABORT chunk and
    removing the SCTP asoc. One could exploit this to terminate a SCTP
    asoc.

    This patch is to fix it by always using the initiate tag of the
    received INIT chunk for the ABORT chunk to be sent.

    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit b75fa48e42d022d6757b7de29178d531df8cf43b
Author: Trevor Woerner <[email protected]>
Date:   Sun Oct 24 13:50:02 2021 -0400

    net: nxp: lpc_eth.c: avoid hang when bringing interface down

    commit ace19b992436a257d9a793672e57abc28fe83e2e upstream.

    A hard hang is observed whenever the ethernet interface is brought
    down. If the PHY is stopped before the LPC core block is reset,
    the SoC will hang. Comparing lpc_eth_close() and lpc_eth_open() I
    re-arranged the ordering of the functions calls in lpc_eth_close() to
    reset the hardware before stopping the PHY.
    Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
    Signed-off-by: Trevor Woerner <[email protected]>
    Acked-by: Vladimir Zapolskiy <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 84a9eb9a2f179ea5e6398fe270560a8aaa16f996
Author: Yuiko Oshino <[email protected]>
Date:   Fri Oct 22 11:53:43 2021 -0400

    net: ethernet: microchip: lan743x: Fix dma allocation failure by using dma_set_mask_and_coherent

    commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

    The dma failure was reported in the raspberry pi github (issue #4117).
    https://github.com/raspberrypi/linux/issues/4117
    The use of dma_set_mask_and_coherent fixes the issue.
    Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

    Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
    Signed-off-by: Yuiko Oshino <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fcda74cc95aa450a6d17780ccb1a8853cac7d0cd
Author: Yuiko Oshino <[email protected]>
Date:   Fri Oct 22 11:13:53 2021 -0400

    net: ethernet: microchip: lan743x: Fix driver crash when lan743x_pm_resume fails

    commit d6423d2ec39cce2bfca418c81ef51792891576bc upstream.

    The driver needs to clean up and return when the initialization fails on resume.

    Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
    Signed-off-by: Yuiko Oshino <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 25d852a8adf017a478246d19c8b282e975521e8a
Author: Guenter Roeck <[email protected]>
Date:   Wed Oct 20 12:11:16 2021 -0700

    nios2: Make NIOS2_DTB_SOURCE_BOOL depend on !COMPILE_TEST

    commit 4a089e95b4d6bb625044d47aed0c442a8f7bd093 upstream.

    nios2:allmodconfig builds fail with

    make[1]: *** No rule to make target 'arch/nios2/boot/dts/""',
    	needed by 'arch/nios2/boot/dts/built-in.a'.  Stop.
    make: [Makefile:1868: arch/nios2/boot/dts] Error 2 (ignored)

    This is seen with compile tests since those enable NIOS2_DTB_SOURCE_BOOL,
    which in turn enables NIOS2_DTB_SOURCE. This causes the build error
    because the default value for NIOS2_DTB_SOURCE is an empty string.
    Disable NIOS2_DTB_SOURCE_BOOL for compile tests to avoid the error.

    Fixes: 2fc8483fdcde ("nios2: Build infrastructure")
    Signed-off-by: Guenter Roeck <[email protected]>
    Reviewed-by: Randy Dunlap <[email protected]>
    Signed-off-by: Dinh Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 02302cbd52264337630a32848ac03648648e9685
Author: Michael Chan <[email protected]>
Date:   Mon Oct 25 05:05:28 2021 -0400

    net: Prevent infinite while loop in skb_tx_hash()

    commit 0c57eeecc559ca6bc18b8c4e2808bc78dbe769b0 upstream.

    Drivers call netdev_set_num_tc() and then netdev_set_tc_queue()
    to set the queue count and offset for each TC.  So the queue count
    and offset for the TCs may be zero for a short period after dev->num_tc
    has been set.  If a TX packet is being transmitted at this time in the
    code path netdev_pick_tx() -> skb_tx_hash(), skb_tx_hash() may see
    nonzero dev->num_tc but zero qcount for the TC.  The while loop that
    keeps looping while hash >= qcount will not end.

    Fix it by checking the TC's qcount to be nonzero before using it.

    Fixes: eadec877ce9c ("net: Add support for subordinate traffic classes to netdev_pick_tx")
    Reviewed-by: Andy Gospodarek <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit fbf150b16a3635634b7dfb7f229d8fcd643c6c51
Author: Pavel Skripkin <[email protected]>
Date:   Sun Oct 24 16:13:56 2021 +0300

    net: batman-adv: fix error handling

    commit 6f68cd634856f8ca93bafd623ba5357e0f648c68 upstream.

    Syzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was
    in wrong error handling in batadv_mesh_init().

    Before this patch batadv_mesh_init() was calling batadv_mesh_free() in case
    of any batadv_*_init() calls failure. This approach may work well, when
    there is some kind of indicator, which can tell which parts of batadv are
    initialized; but there isn't any.

    All written above lead to cleaning up uninitialized fields. Even if we hide
    ODEBUG warning by initializing bat_priv->nc.work, syzbot was able to hit
    GPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]

    To fix these bugs we can unwind batadv_*_init() calls one by one.
    It is good approach for 2 reasons: 1) It fixes bugs on error handling
    path 2) It improves the performance, since we won't call unneeded
    batadv_*_free() functions.

    So, this patch makes all batadv_*_init() clean up all allocated memory
    before returning with an error to no call correspoing batadv_*_free()
    and open-codes batadv_mesh_free() with proper order to avoid touching
    uninitialized fields.

    Link: https://lore.kernel.org/netdev/[email protected]/ [1]
    Reported-and-tested-by: [email protected]
    Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
    Signed-off-by: Pavel Skripkin <[email protected]>
    Acked-by: Sven Eckelmann <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3dae1a4eced3ee733d7222e69b8a55caf2d61091
Author: Yang Yingliang <[email protected]>
Date:   Tue Oct 12 10:37:35 2021 +0800

    regmap: Fix possible double-free in regcache_rbtree_exit()

    commit 55e6d8037805b3400096d621091dfbf713f97e83 upstream.

    In regcache_rbtree_insert_to_block(), when 'present' realloc failed,
    the 'blk' which is supposed to assign to 'rbnode->block' will be freed,
    so 'rbnode->block' points a freed memory, in the error handling path of
    regcache_rbtree_init(), 'rbnode->block' will be freed again in
    regcache_rbtree_exit(), KASAN will report double-free as follows:

    BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390
    Call Trace:
     slab_free_freelist_hook+0x10d/0x240
     kfree+0xce/0x390
     regcache_rbtree_exit+0x15d/0x1a0
     regcache_rbtree_init+0x224/0x2c0
     regcache_init+0x88d/0x1310
     __regmap_init+0x3151/0x4a80
     __devm_regmap_init+0x7d/0x100
     madera_spi_probe+0x10f/0x333 [madera_spi]
     spi_probe+0x183/0x210
     really_probe+0x285/0xc30

    To fix this, moving up the assignment of rbnode->block to immediately after
    the reallocation has succeeded so that the data structure stays valid even
    if the second reallocation fails.

    Reported-by: Hulk Robot <[email protected]>
    Fixes: 3f4ff561bc88b ("regmap: rbtree: Make cache_present bitmap per node")
    Signed-off-by: Yang Yingliang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit cdaf7a469244b5e65ae5eda062ff5ea90172de62
Author: Clément Bœsch <[email protected]>
Date:   Sun Sep 5 02:20:27 2021 +0200

    arm64: dts: allwinner: h5: NanoPI Neo 2: Fix ethernet node

    commit 0764e365dacd0b8f75c1736f9236be280649bd18 upstream.

    RX and TX delay are provided by ethernet PHY. Reflect that in ethernet
    node.

    Fixes: 44a94c7ef989 ("arm64: dts: allwinner: H5: Restore EMAC changes")
    Signed-off-by: Clément Bœsch <[email protected]>
    Reviewed-by: Jernej Skrabec <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: Maxime Ripard <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2864b6d54244b82a8c7d4628a43055c57bfba80c
Author: Patrisious Haddad <[email protected]>
Date:   Wed Oct 6 12:31:53 2021 +0300

    RDMA/mlx5: Set user priority for DCT

    commit 1ab52ac1e9bc9391f592c9fa8340a6e3e9c36286 upstream.

    Currently, the driver doesn't set the PCP-based priority for DCT, hence
    DCT response packets are transmitted without user priority.

    Fix it by setting user provided priority in the eth_prio field in the DCT
    context, which in turn sets the value in the transmitted packet.

    Fixes: 776a3906b692 ("IB/mlx5: Add support for DC target QP")
    Link: https://lore.kernel.org/r/5fd2d94a13f5742d8803c218927322257d53205c.1633512672.git.leonro@nvidia.com
    Signed-off-by: Patrisious Haddad <[email protected]>
    Reviewed-by: Maor Gottlieb <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 326da4f6ffdbd8671e86f69ded7a714dcc12fecf
Author: Johan Hovold <[email protected]>
Date:   Tue Oct 26 12:36:17 2021 +0200

    net: lan78xx: fix division by zero in send path

    commit db6c3c064f5d55fa9969f33eafca3cdbefbb3541 upstream.

    Add the missing endpoint max-packet sanity check to probe() to avoid
    division by zero in lan78xx_tx_bh() in case a malicious device has
    broken descriptors (or when doing descriptor fuzz testing).

    Note that USB core will reject URBs submitted for endpoints with zero
    wMaxPacketSize but that drivers doing packet-size calculations still
    need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
    endpoint descriptors with maxpacket=0")).

    Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
    Cc: [email protected]      # 4.3
    Cc: [email protected] <[email protected]>
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 2ff5289793fd61c56ac8774408f27350e5da865f
Author: Haibo Chen <[email protected]>
Date:   Fri Oct 15 10:00:36 2021 +0800

    mmc: sdhci-esdhc-imx: clear the buffer_read_ready to reset standard tuning circuit

    commit 9af372dc70e9fdcbb70939dac75365e7b88580b4 upstream.

    To reset standard tuning circuit completely, after clear ESDHC_MIX_CTRL_EXE_TUNE,
    also need to clear bit buffer_read_ready, this operation will finally clear the
    USDHC IP internal logic flag execute_tuning_with_clr_buf, make sure the following
    normal data transfer will not be impacted by standard tuning logic used before.

    Find this issue when do quick SD card insert/remove stress test. During standard
    tuning prodedure, if remove SD card, USDHC standard tuning logic can't clear the
    internal flag execute_tuning_with_clr_buf. Next time when insert SD card, all
    data related commands can't get any data related interrupts, include data transfer
    complete interrupt, data timeout interrupt, data CRC interrupt, data end bit interrupt.
    Always trigger software timeout issue. Even reset the USDHC through bits in register
    SYS_CTRL (0x2C, bit28 reset tuning, bit26 reset data, bit 25 reset command, bit 24
    reset all) can't recover this. From the user's point of view, USDHC stuck, SD can't
    be recognized any more.

    Fixes: d9370424c948 ("mmc: sdhci-esdhc-imx: reset tuning circuit when power on mmc card")
    Signed-off-by: Haibo Chen <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7824414c2903e2cfe56ea610387a22c0c88fb468
Author: Shawn Guo <[email protected]>
Date:   Mon Oct 4 10:49:35 2021 +0800

    mmc: sdhci: Map more voltage level to SDHCI_POWER_330

    commit 4217d07b9fb328751f877d3bd9550122014860a2 upstream.

    On Thundercomm TurboX CM2290, the eMMC OCR reports vdd = 23 (3.5 ~ 3.6 V),
    which is being treated as an invalid value by sdhci_set_power_noreg().
    And thus eMMC is totally broken on the platform.

    [    1.436599] ------------[ cut here ]------------
    [    1.436606] mmc0: Invalid vdd 0x17
    [    1.436640] WARNING: CPU: 2 PID: 69 at drivers/mmc/host/sdhci.c:2048 sdhci_set_power_noreg+0x168/0x2b4
    [    1.436655] Modules linked in:
    [    1.436662] CPU: 2 PID: 69 Comm: kworker/u8:1 Tainted: G        W         5.15.0-rc1+ #137
    [    1.436669] Hardware name: Thundercomm TurboX CM2290 (DT)
    [    1.436674] Workqueue: events_unbound async_run_entry_fn
    [    1.436685] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [    1.436692] pc : sdhci_set_power_noreg+0x168/0x2b4
    [    1.436698] lr : sdhci_set_power_noreg+0x168/0x2b4
    [    1.436703] sp : ffff800010803a60
    [    1.436705] x29: ffff800010803a60 x28: ffff6a9102465f00 x27: ffff6a9101720a70
    [    1.436715] x26: ffff6a91014de1c0 x25: ffff6a91014de010 x24: ffff6a91016af280
    [    1.436724] x23: ffffaf7b1b276640 x22: 0000000000000000 x21: ffff6a9101720000
    [    1.436733] x20: ffff6a9101720370 x19: ffff6a9101720580 x18: 0000000000000020
    [    1.436743] x17: 0000000000000000 x16: 0000000000000004 x15: ffffffffffffffff
    [    1.436751] x14: 0000000000000000 x13: 00000000fffffffd x12: ffffaf7b1b84b0bc
    [    1.436760] x11: ffffaf7b1b720d10 x10: 000000000000000a x9 : ffff800010803a60
    [    1.436769] x8 : 000000000000000a x7 : 000000000000000f x6 : 00000000fffff159
    [    1.436778] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff
    [    1.436787] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff6a9101718d80
    [    1.436797] Call trace:
    [    1.436800]  sdhci_set_power_noreg+0x168/0x2b4
    [    1.436805]  sdhci_set_ios+0xa0/0x7fc
    [    1.436811]  mmc_power_up.part.0+0xc4/0x164
    [    1.436818]  mmc_start_host+0xa0/0xb0
    [    1.436824]  mmc_add_host+0x60/0x90
    [    1.436830]  __sdhci_add_host+0x174/0x330
    [    1.436836]  sdhci_msm_probe+0x7c0/0x920
    [    1.436842]  platform_probe+0x68/0xe0
    [    1.436850]  really_probe.part.0+0x9c/0x31c
    [    1.436857]  __driver_probe_device+0x98/0x144
    [    1.436863]  driver_probe_device+0xc8/0x15c
    [    1.436869]  __device_attach_driver+0xb4/0x120
    [    1.436875]  bus_for_each_drv+0x78/0xd0
    [    1.436881]  __device_attach_async_helper+0xac/0xd0
    [    1.436888]  async_run_entry_fn+0x34/0x110
    [    1.436895]  process_one_work+0x1d0/0x354
    [    1.436903]  worker_thread+0x13c/0x470
    [    1.436910]  kthread+0x150/0x160
    [    1.436915]  ret_from_fork+0x10/0x20
    [    1.436923] ---[ end trace fcfac44cb045c3a8 ]---

    Fix the issue by mapping MMC_VDD_35_36 (and MMC_VDD_34_35) to
    SDHCI_POWER_330 as well.

    Signed-off-by: Shawn Guo <[email protected]>
    Acked-by: Adrian Hunter <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 29d56f3790e684e630d56f500b59e834fa382209
Author: Jaehoon Chung <[email protected]>
Date:   Fri Oct 22 17:21:06 2021 +0900

    mmc: dw_mmc: exynos: fix the finding clock sample value

    commit 697542bceae51f7620af333b065dd09d213629fb upstream.

    Even though there are candiates value if can't find best value, it's
    returned -EIO. It's not proper behavior.
    If there is not best value, use a first candiate value to work eMMC.

    Signed-off-by: Jaehoon Chung <[email protected]>
    Tested-by: Marek Szyprowski <[email protected]>
    Tested-by: Christian Hewitt <[email protected]>
    Cc: [email protected]
    Fixes: c537a1c5ff63 ("mmc: dw_mmc: exynos: add variable delay tuning sequence")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 24f8658690477e8983f88cbfe21fb7f4062ad837
Author: Wenbin Mei <[email protected]>
Date:   Tue Oct 26 15:08:12 2021 +0800

    mmc: cqhci: clear HALT state after CQE enable

    commit 92b18252b91de567cd875f2e84722b10ab34ee28 upstream.

    While mmc0 enter suspend state, we need halt CQE to send legacy cmd(flush
    cache) and disable cqe, for resume back, we enable CQE and not clear HALT
    state.
    In this case MediaTek mmc host controller will keep the value for HALT
    state after CQE disable/enable flow, so the next CQE transfer after resume
    will be timeout due to CQE is in HALT state, the log as below:
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: timeout for tag 2
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: ============ CQHCI REGISTER DUMP ===========
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Caps:      0x100020b6 | Version:  0x00000510
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Config:    0x00001103 | Control:  0x00000001
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Int stat:  0x00000000 | Int enab: 0x00000006
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Int sig:   0x00000006 | Int Coal: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: TDL base:  0xfd05f000 | TDL up32: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Doorbell:  0x8000203c | TCN:      0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Task clr:  0x00000000 | SSC1:     0x00001000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: SSC2:      0x00000001 | DCMD rsp: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: RED mask:  0xfdf9a080 | TERRI:    0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Resp idx:  0x00000000 | Resp arg: 0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: CRNQP:     0x00000000 | CRNQDUN:  0x00000000
    <4>.(4)[318:kworker/4:1H]mmc0: cqhci: CRNQIS:    0x00000000 | CRNQIE:   0x00000000

    This change check HALT state after CQE enable, if CQE is in HALT state, we
    will clear it.

    Signed-off-by: Wenbin Mei <[email protected]>
    Cc: [email protected]
    Acked-by: Adrian Hunter <[email protected]>
    Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 99641238575c26c2e47fa593f562dae476709d68
Author: Johan Hovold <[email protected]>
Date:   Mon Oct 25 13:56:08 2021 +0200

    mmc: vub300: fix control-message timeouts

    commit 8c8171929116cc23f74743d99251eedadf62341a upstream.

    USB control-message timeouts are specified in milliseconds and should
    specifically not vary with CONFIG_HZ.

    Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
    Cc: [email protected]      # 3.0
    Signed-off-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c6d0d68d6da68159948cad3d808d61bb291a0283
Author: Eric Dumazet <[email protected]>
Date:   Sun Aug 29 15:16:14 2021 -0700

    ipv6: make exception cache less predictible

    commit a00df2caffed3883c341d5685f830434312e4a43 upstream.

    Even after commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()"),
    an attacker can still use brute force to learn some secrets from a victim
    linux host.

    One way to defeat these attacks is to make the max depth of the hash
    table bucket a random value.

    Before this patch, each bucket of the hash table used to store exceptions
    could contain 6 items under attack.

    After the patch, each bucket would contains a random number of items,
    between 6 and 10. The attacker can no longer infer secrets.

    This is slightly increasing memory size used by the hash table,
    we do not expect this to be a problem.

    Following patch is dealing with the same issue in IPv4.

    Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Keyu Man <[email protected]>
    Cc: Wei Wang <[email protected]>
    Cc: Martin KaFai Lau <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    [OP: adjusted context for 4.19 stable]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ad829847ad59af8e26a1f1c345716099abbc7a58
Author: Eric Dumazet <[email protected]>
Date:   Fri Oct 29 10:50:26 2021 +0300

    ipv6: use siphash in rt6_exception_hash()

    commit 4785305c05b25a242e5314cc821f54ade4c18810 upstream.

    A group of security researchers brought to our attention
    the weakness of hash function used in rt6_exception_hash()

    Lets use siphash instead of Jenkins Hash, to considerably
    reduce security risks.

    Following patch deals with IPv4.

    Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Keyu Man <[email protected]>
    Cc: Wei Wang <[email protected]>
    Cc: Martin KaFai Lau <[email protected]>
    Acked-by: Wei Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    [OP: adjusted context for 4.19 stable]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 6e2856767eb1a9cfcfcd82136928037f04920e97
Author: Eric Dumazet <[email protected]>
Date:   Fri Oct 29 10:50:25 2021 +0300

    ipv4: use siphash instead of Jenkins in fnhe_hashfun()

    commit 6457378fe796815c973f631a1904e147d6ee33b1 upstream.

    A group of security researchers brought to our attention
    the weakness of hash function used in fnhe_hashfun().

    Lets use siphash instead of Jenkins Hash, to considerably
    reduce security risks.

    Also remove the inline keyword, this really is distracting.

    Fixes: d546c621542d ("ipv4: harden fnhe_hashfun()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: Keyu Man <[email protected]>
    Cc: Willy Tarreau <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    [OP: adjusted context for 4.19 stable]
    Signed-off-by: Ovidiu Panait <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 8121d0d4fd108280f5cd7b7fe8c6592adaa37be9
Author: Pavel Skripkin <[email protected]>
Date:   Thu Sep 30 20:49:42 2021 +0300

    Revert "net: mdiobus: Fix memory leak in __mdiobus_register"

    commit 10eff1f5788b6ffac212c254e2f3666219576889 upstream.

    This reverts commit ab609f25d19858513919369ff3d9a63c02cd9e2e.

    This patch is correct in the sense that we _should_ call device_put() in
    case of device_register() failure, but the problem in this code is more
    vast.

    We need to set bus->state to UNMDIOBUS_REGISTERED before calling
    device_register() to correctly release the device in mdiobus_free().
    This patch prevents us from doing it, since in case of device_register()
    failure put_device() will be called 2 times and it will cause UAF or
    something else.

    Also, Reported-by: tag in revered commit was wrong, since syzbot
    reported different leak in same function.

    Link: https://lore.kernel.org/netdev/20210928092657.GI2048@kadam/
    Acked-by: Yanfei Xu <[email protected]>
    Signed-off-by: Pavel Skripkin <[email protected]>
    Link: https://lore.kernel.org/r/f12fb1faa4eccf0f355788225335eb4309ff2599.1633024062.git.paskripkin@gmail.com
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 4a9043ba1b0e9bea1da0fe34366222974f2c0f92
Author: Krzysztof Kozlowski <[email protected]>
Date:   Mon Oct 25 16:49:36 2021 +0200

    nfc: port100: fix using -ERRNO as command type mask

    commit 2195f2062e4cc93870da8e71c318ef98a1c51cef upstream.

    During probing, the driver tries to get a list (mask) of supported
    command types in port100_get_command_type_mask() function.  The value
    is u64 and 0 is treated as invalid mask (no commands supported).  The
    function however returns also -ERRNO as u64 which will be interpret as
    valid command mask.

    Return 0 on every error case of port100_get_command_type_mask(), so the
    probing will stop.

    Cc: <[email protected]>
    Fixes: 0347a6ab300a ("NFC: port100: Commands mechanism implementation")
    Signed-off-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a36119f9b3fb069437383a8eff4e65181b6e7e2f
Author: Zheyu Ma <[email protected]>
Date:   Fri Oct 22 09:12:26 2021 +0000

    ata: sata_mv: Fix the error handling of mv_chip_id()

    commit a0023bb9dd9bc439d44604eeec62426a990054cd upstream.

    mv_init_host() propagates the value returned by mv_chip_id() which in turn
    gets propagated by mv_pci_init_one() and hits local_pci_probe().

    During the process of driver probing, the probe function should return < 0
    for failure, otherwise, the kernel will treat value > 0 as success.

    Since this is a bug rather than a recoverable runtime error we should
    use dev_alert() instead of dev_err().

    Signed-off-by: Zheyu Ma <[email protected]>
    Signed-off-by: Damien Le Moal <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 78c2dc1cdf0bdfc83e473d78f23da4d2aeb98142
Author: Wang Hai <[email protected]>
Date:   Tue Oct 26 20:40:15 2021 +0800

    usbnet: fix error return code in usbnet_probe()

    commit 6f7c88691191e6c52ef2543d6f1da8d360b27a24 upstream.

    Return error code if usb_maxpacket() returns 0 in usbnet_probe()

    Fixes: 397430b50a36 ("usbnet: sanity check for maxpacket")
    Reported-by: Hulk Robot <[email protected]>
    Signed-off-by: Wang Hai <[email protected]>
    Reviewed-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 002d82227c0abe29118cf80f7e2f396b22d448ed
Author: Oliver Neukum <[email protected]>
Date:   Thu Oct 21 14:29:44 2021 +0200

    usbnet: sanity check for maxpacket

    commit 397430b50a363d8b7bdda00522123f82df6adc5e upstream.

    maxpacket of 0 makes no sense and oopses as we need to divide
    by it. Give up.

    V2: fixed typo in log and stylistic issues

    Signed-off-by: Oliver Neukum <[email protected]>
    Reported-by: [email protected]
    Reviewed-by: Johan Hovold <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d725978abb0bac6e0c427548dfd6db86709a2a1e
Author: Nathan Chancellor <[email protected]>
Date:   Sat Jan 5 19:35:25 2019 +0100

    ARM: 8819/1: Remove '-p' from LDFLAGS

    commit 091bb549f7722723b284f63ac665e2aedcf9dec9 upstream.

    This option is not supported by lld:

        ld.lld: error: unknown argument: -p

    This has been a no-op in binutils since 2004 (see commit dea514f51da1 in
    that tree). Given that the lowest officially supported of binutils for
    the kernel is 2.20, which was released in 2009, nobody needs this flag
    around so just remove it. Commit 1a381d4a0a9a ("arm64: remove no-op -p
    linker flag") did the same for arm64.

    Signed-off-by: Nathan Chancellor <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Acked-by: Nicolas Pitre <[email protected]>
    Reviewed-by: Nick Desaulniers <[email protected]>
    Reviewed-by: Stefan Agner <[email protected]>
    Signed-off-by: Russell King <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit aaf4e1b05cab800b36b40c1aa09f7c13ef30de56
Author: Robin Murphy <[email protected]>
Date:   Mon Jul 12 15:27:46 2021 +0100

    arm64: Avoid premature usercopy failure

    commit 295cf156231ca3f9e3a66bde7fab5e09c41835e0 upstream.

    Al reminds us that the usercopy API must only return complete failure
    if absolutely nothing could be copied. Currently, if userspace does
    something silly like giving us an unaligned pointer to Device memory,
    or a size which overruns MTE tag bounds, we may fail to honour that
    requirement when faulting on a multi-byte access even though a smaller
    access could have succeeded.

    Add a mitigation to the fixup routines to fall back to a single-byte
    copy if we faulted on a larger access before anything has been written
    to the destination, to guarantee making *some* forward progress. We
    needn't be too concerned about the overall performance since this should
    only occur when callers are doing something a bit dodgy in the first
    place. Particularly broken userspace might still be able to trick
    generic_perform_write() into an infinite loop by targeting write() at
    an mmap() of some read-only device register where the fault-in load
    succeeds but any store synchronously aborts such that copy_to_user() is
    genuinely unable to make progress, but, well, don't do that...

    CC: [email protected]
    Reported-by: Chen Huang <[email protected]>
    Suggested-by: Al Viro <[email protected]>
    Reviewed-by: Catalin Marinas <[email protected]>
    Signed-off-by: Robin Murphy <[email protected]>
    Link: https://lore.kernel.org/r/dc03d5c675731a1f24a62417dba5429ad744234e.1626098433.git.robin.murphy@arm.com
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Chen Huang <[email protected]>

commit 5909b851b5e11d04f299e5f0a8937e9dcc807248
Author: Naveen N. Rao <[email protected]>
Date:   Wed Oct 6 01:55:22 2021 +0530

    powerpc/bpf: Fix BPF_MOD when imm == 1

    commit 8bbc9d822421d9ac8ff9ed26a3713c9afc69d6c8 upstream.

    Only ignore the operation if dividing by 1.

    Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
    Signed-off-by: Naveen N. Rao <[email protected]>
    Tested-by: Johan Almbladh <[email protected]>
    Reviewed-by: Christophe Leroy <[email protected]>
    Acked-by: Song Liu <[email protected]>
    Acked-by: Johan Almbladh <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/c674ca18c3046885602caebb326213731c675d06.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
    [cascardo: use PPC_LI instead of EMIT(PPC_RAW_LI)]
    Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 901741a53d7cf45be861e881c0e3cba5b4bd1f94
Author: Arnd Bergmann <[email protected]>
Date:   Mon Oct 18 15:30:37 2021 +0100

    ARM: 9141/1: only warn about XIP address when not compile testing

    commit 48ccc8edf5b90622cdc4f8878e0042ab5883e2ca upstream.

    In randconfig builds, we sometimes come across this warning:

    arm-linux-gnueabi-ld: XIP start address may cause MPU programming issues

    While this is helpful for actual systems to figure out why it
    fails, the warning does not provide any benefit for build testing,
    so guard it in a check for CONFIG_COMPILE_TEST, which is usually
    set on randconfig builds.

    Fixes: 216218308cfb ("ARM: 8713/1: NOMMU: Support MPU in XIP configuration")
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ee4b38ce37ed31beca29d3ebec7db3d5e87fe39e
Author: Arnd Bergmann <[email protected]>
Date:   Mon Oct 18 15:30:09 2021 +0100

    ARM: 9139/1: kprobes: fix arch_init_kprobes() prototype

    commit 1f323127cab086e4fd618981b1e5edc396eaf0f4 upstream.

    With extra warnings enabled, gcc complains about this function
    definition:

    arch/arm/probes/kprobes/core.c: In function 'arch_init_kprobes':
    arch/arm/probes/kprobes/core.c:465:12: warning: old-style function definition [-Wold-style-definition]
      465 | int __init arch_init_kprobes()

    Link: https://lore.kernel.org/all/[email protected]/

    Fixes: 24ba613c9d6c ("ARM kprobes: core code")
    Acked-by: Masami Hiramatsu <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c0b4f1db7feef31d401814121760b45aff7885c1
Author: Arnd Bergmann <[email protected]>
Date:   Mon Oct 18 15:30:04 2021 +0100

    ARM: 9134/1: remove duplicate memcpy() definition

    commit eaf6cc7165c9c5aa3c2f9faa03a98598123d0afb upstream.

    Both the decompressor code and the kasan logic try to override
    the memcpy() and memmove()  definitions, which leading to a clash
    in a KASAN-enabled kernel with XZ decompression:

    arch/arm/boot/compressed/decompress.c:50:9: error: 'memmove' macro redefined [-Werror,-Wmacro-redefined]
     #define memmove memmove
            ^
    arch/arm/include/asm/string.h:59:9: note: previous definition is here
     #define memmove(dst, src, len) __memmove(dst, src, len)
            ^
    arch/arm/boot/compressed/decompress.c:51:9: error: 'memcpy' macro redefined [-Werror,-Wmacro-redefined]
     #define memcpy memcpy
            ^
    arch/arm/include/asm/string.h:58:9: note: previous definition is here
     #define memcpy(dst, src, len) __memcpy(dst, src, len)
            ^

    Here we want the set of functions from the decompressor, so undefine
    the other macros before the override.

    Link: https://lore.kernel.org/linux-arm-kernel/CACRpkdZYJogU_SN3H9oeVq=zJkRgRT1gDz3xp59gdqWXxw-B=w@mail.gmail.com/
    Link: https://lore.kernel.org/lkml/[email protected]/

    Fixes: d6d51a96c7d6 ("ARM: 9014/2: Replace string mem* functions for KASan")
    Fixes: a7f464f3db93 ("ARM: 7001/2: Wire up support for the XZ decompressor")
    Reported-by: kernel test robot <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 00dcbb2d2cd3594faa2f977f2f7175cf23d4e326
Author: Nick Desaulniers <[email protected]>
Date:   Mon Oct 4 18:03:28 2021 +0100

    ARM: 9133/1: mm: proc-macros: ensure *_tlb_fns are 4B aligned

    commit e6a0c958bdf9b2e1b57501fc9433a461f0a6aadd upstream.

    A kernel built with CONFIG_THUMB2_KERNEL=y and using clang as the
    assembler could generate non-naturally-aligned v7wbi_tlb_fns which
    results in a boot failure. The original commit adding the macro missed
    the .align directive on this data.

    Link: https://github.com/ClangBuiltLinux/linux/issues/1447
    Link: https://lore.kernel.org/all/[email protected]/
    Debugged-by: Ard Biesheuvel <[email protected]>
    Debugged-by: Nathan Chancellor <[email protected]>
    Debugged-by: Richard Henderson <[email protected]>

    Fixes: 66a625a88174 ("ARM: mm: proc-macros: Add generic proc/cache/tlb struct definition macros")
    Suggested-by: Ard Biesheuvel <[email protected]>
    Acked-by: Ard Biesheuvel <[email protected]>
    Signed-off-by: Nick Desaulniers <[email protected]>
    Tested-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 38ec06730e44b2166e87fecca9e36380080801ac
Author: Greg Kroah-Hartman <[email protected]>
Date:   Wed Oct 27 09:53:15 2021 +0200

    Linux 4.19.214

    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Sudip Mukherjee <[email protected]>
    Tested-by: Guenter Roeck <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 0b7d55ca605e611aceeadf7c29c75808faae951a
Author: Nick Desaulniers <[email protected]>
Date:   Wed Sep 8 19:25:59 2021 +0100

    ARM: 9122/1: select HAVE_FUTEX_CMPXCHG

    commit 9d417cbe36eee7afdd85c2e871685f8dab7c2dba upstream.

    tglx notes:
      This function [futex_detect_cmpxchg] is only needed when an
      architecture has to runtime discover whether the CPU supports it or
      not.  ARM has unconditional support for this, so the obvious thing to
      do is the below.

    Fixes linkage failure from Clang randconfigs:
    kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit: R_ARM_JUMP24 against `.init.text'
    and boot failures for CONFIG_THUMB2_KERNEL.

    Link: https://github.com/ClangBuiltLinux/linux/issues/325

    Comments from Nick Desaulniers:

     See-also: 03b8c7b623c8 ("futex: Allow architectures to skip
     futex_atomic_cmpxchg_inatomic() test")

    Reported-by: Arnd Bergmann <[email protected]>
    Reported-by: Nathan Chancellor <[email protected]>
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Nick Desaulniers <[email protected]>
    Reviewed-by: Thomas Gleixner <[email protected]>
    Tested-by: Nathan Chancellor <[email protected]>
    Reviewed-by: Linus Walleij <[email protected]>
    Cc: [email protected] # v3.14+
    Reviewed-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Russell King (Oracle) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 3de1ed125fc4c35bf7abb08260646100a6dcb04e
Author: Steven Rostedt (VMware) <[email protected]>
Date:   Mon Oct 18 15:44:12 2021 -0400

    tracing: Have all levels of checks prevent recursion

    commit ed65df63a39a3f6ed04f7258de8b6789e5021c18 upstream.

    While writing an email explaining the "bit = 0" logic for a discussion on
    making ftrace_test_recursion_trylock() disable preemption, I discovered a
    path that makes the "not do the logic if bit is zero" unsafe.

    The recursion logic is done in hot paths like the function tracer. Thus,
    any code executed causes noticeable overhead. Thus, tricks are done to try
    to limit the amount of code executed. This included the recursion testing
    logic.

    Having recursion testing is important, as there are many paths that can
    end up in an infinite recursion cycle when tracing every function in the
    kernel. Thus protection is needed to prevent that from happening.

    Because it is OK to recurse due to different running context levels (e.g.
    an interrupt preempts a trace, and then a trace occurs in the interrupt
    handler), a set of bits are used to know which context one is in (normal,
    softirq, irq and NMI). If a recursion occurs in the same level, it is
    prevented*.

    Then there are infrastructure levels of recursion as well. When more than
    one callback is attached to the same function to trace, it calls a loop
    function to iterate over all the callbacks. Both the callbacks and the
    loop function have recursion protection. The callbacks use the
    "ftrace_test_recursion_trylock()" which has a "function" set of context
    bits to test, and the loop function calls the internal
    trace_test_and_set_recursion() directly, with an "internal" set of bits.

    If an architecture does not implement all the features supported by ftrace
    then the callbacks are never called directly, and the loop function is
    called instead, which will implement the features of ftrace.

    Since both the loop function and the callbacks do recursion protection, it
    was seemed unnecessary to do it in both locations. Thus, a trick was made
    to have the internal set of recursion bits at a more significant bit
    location than the function bits. Then, if any of the higher bits were set,
    the logic of the function bits could be skipped, as any new recursion
    would first have to go through the loop function.

    This is true for architectures that do not support all the ftrace
    features, because all functions being traced must first go through the
    loop function before going to the callbacks. But this is not true for
    architectures that support all the ftrace features. That's because the
    loop function could be called due to two callbacks attached to the same
    function, but then a recursion function inside the callback could be
    called that does not share any other callback, and it will be called
    directly.

    i.e.

     traced_function_1: [ more than one callback tracing it ]
       call loop_func

     loop_func:
       trace_recursion set internal bit
       call callback

     callback:
       trace_recursion [ skipped because internal bit is set, return 0 ]
       call traced_function_2

     traced_function_2: [ only traced by above callback ]
       call callback

     callback:
       trace_recursion [ skipped because internal bit is set, return 0 ]
       call traced_function_2

     [ wash, rinse, repeat, BOOM! out of shampoo! ]

    Thus, the "bit == 0 skip" trick is not safe, unless the loop function is
    call for all functions.

    Since we want to encourage architectures to implement all ftrace features,
    having them slow down due to this extra logic may encourage the
    maintainers to update to the latest ftrace features. And because this
    logic is only safe for them, remove it completely.

     [*] There is on layer of recursion that is allowed, and that is to allow
         for the transition between interrupt context (normal -> softirq ->
         irq -> NMI), because a trace may occur before the context update is
         visible to the trace recursion logic.

    Link: https://lore.kernel.org/all/[email protected]/
    Link: https://lkml.kernel.org/r/[email protected]

    Cc: Linus Torvalds <[email protected]>
    Cc: Petr Mladek <[email protected]>
    Cc: Ingo Molnar <[email protected]>
    Cc: "James E.J. Bottomley" <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: Michael Ellerman <[email protected]>
    Cc: Benjamin Herrenschmidt <[email protected]>
    Cc: Paul Mackerras <[email protected]>
    Cc: Paul Walmsley <[email protected]>
    Cc: Palmer Dabbelt <[email protected]>
    Cc: Albert Ou <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: "H. Peter Anvin" <[email protected]>
    Cc: Josh Poimboeuf <[email protected]>
    Cc: Jiri Kosina <[email protected]>
    Cc: Miroslav Benes <[email protected]>
    Cc: Joe Lawrence <[email protected]>
    Cc: Colin Ian King <[email protected]>
    Cc: Masami Hiramatsu <[email protected]>
    Cc: "Peter Zijlstra (Intel)" <[email protected]>
    Cc: Nicholas Piggin <[email protected]>
    Cc: Jisheng Zhang <[email protected]>
    Cc: =?utf-8?b?546L6LSH?= <[email protected]>
    Cc: Guo Ren <[email protected]>
    Cc: [email protected]
    Fixes: edc15cafcbfa3 ("tracing: Avoid unnecessary multiple recursion checks")
    Signed-off-by: Steven Rostedt (VMware) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a9831afa2dc8a18205403907c41aa4e0950ac611
Author: Yanfei Xu <[email protected]>
Date:   Sun Sep 26 12:53:13 2021 +0800

    net: mdiobus: Fix memory leak in __mdiobus_register

    commit ab609f25d19858513919369ff3d9a63c02cd9e2e upstream.

    Once device_register() failed, we should call put_device() to
    decrement reference count for cleanup. Or it will cause memory
    leak.

    BUG: memory leak
    unreferenced object 0xffff888114032e00 (size 256):
      comm "kworker/1:3", pid 2960, jiffies 4294943572 (age 15.920s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 08 2e 03 14 81 88 ff ff  ................
        08 2e 03 14 81 88 ff ff 90 76 65 82 ff ff ff ff  .........ve.....
      backtrace:
        [<ffffffff8265cfab>] kmalloc include/linux/slab.h:591 [inline]
        [<ffffffff8265cfab>] kzalloc include/linux/slab.h:721 [inline]
        [<ffffffff8265cfab>] device_private_init drivers/base/core.c:3203 [inline]
        [<ffffffff8265cfab>] device_add+0x89b/0xdf0 drivers/base/core.c:3253
        [<ffffffff828dd643>] __mdiobus_register+0xc3/0x450 drivers/net/phy/mdio_bus.c:537
        [<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
        [<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
        [<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
        [<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
        [<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
        [<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
        [<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
        [<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
        [<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
        [<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
        [<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
        [<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
        [<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969
        [<ffffffff82660916>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
        [<ffffffff8265cd0b>] device_add+0x5fb/0xdf0 drivers/base/core.c:3359
        [<ffffffff82c343b9>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2170
        [<ffffffff82c4473c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238

    BUG: memory leak
    unreferenced object 0xffff888116f06900 (size 32):
      comm "kworker/0:2", pid 2670, jiffies 4294944448 (age 7.160s)
      hex dump (first 32 bytes):
        75 73 62 2d 30 30 31 3a 30 30 33 00 00 00 00 00  usb-001:003.....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<ffffffff81484516>] kstrdup+0x36/0x70 mm/util.c:60
        [<ffffffff814845a3>] kstrdup_const+0x53/0x80 mm/util.c:83
        [<ffffffff82296ba2>] kvasprintf_const+0xc2/0x110 lib/kasprintf.c:48
        [<ffffffff82358d4b>] kobject_set_name_vargs+0x3b/0xe0 lib/kobject.c:289
        [<ffffffff826575f3>] dev_set_name+0x63/0x90 drivers/base/core.c:3147
        [<ffffffff828dd63b>] __mdiobus_register+0xbb/0x450 drivers/net/phy/mdio_bus.c:535
        [<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
        [<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
        [<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
        [<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
        [<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
        [<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
        [<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
        [<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
        [<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
        [<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
        [<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
        [<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
        [<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969

    Reported-by: [email protected]
    Signed-off-by: Yanfei Xu <[email protected]>
    Reviewed-by: Andrew Lunn <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 629e870ca473bbf3ec2429d441efb0406869783d
Author: Dexuan Cui <[email protected]>
Date:   Thu Oct 7 21:35:46 2021 -0700

    scsi: core: Fix shost->cmd_per_lun calculation in scsi_add_host_with_dma()

    commit 50b6cb3516365cb69753b006be2b61c966b70588 upstream.

    After commit ea2f0f77538c ("scsi: core: Cap scsi_host cmd_per_lun at
    can_queue"), a 416-CPU VM running on Hyper-V hangs during boot because the
    hv_storvsc driver sets scsi_driver.can_queue to an integer value that
    exceeds SHRT_MAX, and hence scsi_add_host_with_dma() sets
    shost->cmd_per_lun to a negative "short" value.

    Use min_t(int, ...) to work around the issue.

    Link: https://lore.kernel.org/r/[email protected]
    Fixes: ea2f0f77538c ("scsi: core: Cap scsi_host cmd_per_lun at can_queue")
    Cc: [email protected]
    Reviewed-by: Haiyang Zhang <[email protected]>
    Reviewed-by: Ming Lei <[email protected]>
    Reviewed-by: John Garry <[email protected]>
    Signed-off-by: Dexuan Cui <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 1360f9cde7eaaea4e6b48ab4ec544c706dbc6a8a
Author: Kai Vehmanen <[email protected]>
Date:   Tue Oct 12 17:29:35 2021 +0300

    ALSA: hda: avoid write to STATESTS if controller is in reset

    [ Upstream commit b37a15188eae9d4c49c5bb035e0c8d4058e4d9b3 ]

    The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
    before performing controller reset. This code dates back to an old
    bugfix in commit e8a7f136f5ed ("[ALSA] hda-intel - Improve HD-audio
    codec probing robustness"). Originally the code was added to
    azx_reset().

    The code was moved around in commit a41d122449be ("ALSA: hda - Embed bus
    into controller object") and ended up to snd_hdac_bus_reset_link() and
    called primarily via snd_hdac_bus_init_chip().

    The logic to clear STATESTS is correct when snd_hdac_bus_init_chip() is
    called when controller is not in reset. In this case, STATESTS can be
    cleared. This can be useful e.g. when forcing a controller reset to retry
    codec probe. A normal non-power-on reset will not clear the bits.

    However, this old logic is problematic when controller is already in
    reset. The HDA specification states that controller must be taken out of
    reset before writing to registers other than GCTL.CRST (1.0a spec,
    3.3.7). The write to STATESTS in snd_hdac_bus_reset_link() will be lost
    if the controller is already in reset per the HDA specification mentioned.

    This has been harmless on older hardware. On newer generation of Intel
    PCIe based HDA controllers, if configured to report issues, this write
    will emit an unsupported request error. If ACPI Platform Error Interface
    (APEI) is enabled in kernel, this will end up to kernel log.

    Fix the code in snd_hdac_bus_reset_link() to only clear the STATESTS if
    the function is called when controller is not in reset. Otherwise
    clearing the bits is not possible and should be skipped.

    Signed-off-by: Kai Vehmanen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit f7db1bc1cdb809fdd65d50485fb67bd418eadbd5
Author: Prashant Malani <[email protected]>
Date:   Tue Sep 28 03:19:34 2021 -0700

    platform/x86: intel_scu_ipc: Update timeout value in comment

    [ Upstream commit a0c5814b9933f25ecb6de169483c5b88cf632bca ]

    The comment decribing the IPC timeout hadn't been updated when the
    actual timeout was changed from 3 to 5 seconds in
    commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual
    timeout from 3 to 5 seconds") .

    Since the value is anyway updated to 10s now, take this opportunity to
    update the value in the comment too.

    Signed-off-by: Prashant Malani <[email protected]>
    Cc: Benson Leung <[email protected]>
    Reviewed-by: Mika Westerberg <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Hans de Goede <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit a5b34409d3fc52114c828be4adbc30744fa3258b
Author: Zheyu Ma <[email protected]>
Date:   Sat Oct 9 11:33:49 2021 +0000

    isdn: mISDN: Fix sleeping function called from invalid context

    [ Upstream commit 6510e80a0b81b5d814e3aea6297ba42f5e76f73c ]

    The driver can call card->isac.release() function from an atomic
    context.

    Fix this by calling this function after releasing the lock.

    The following log reveals it:

    [   44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018
    [   44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe
    [   44.169574 ] INFO: lockdep is turned off.
    [   44.169899 ] irq event stamp: 0
    [   44.170160 ] hardirqs last  enabled at (0): [<0000000000000000>] 0x0
    [   44.170627 ] hardirqs last disabled at (0): [<ffffffff814209ed>] copy_process+0x132d/0x3e00
    [   44.171240 ] softirqs last  enabled at (0): [<ffffffff81420a1a>] copy_process+0x135a/0x3e00
    [   44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0
    [   44.172318 ] Preemption disabled at:
    [   44.172320 ] [<ffffffffa009b0a9>] nj_release+0x69/0x500 [netjet]
    [   44.174441 ] Call Trace:
    [   44.174630 ]  dump_stack_lvl+0xa8/0xd1
    [   44.174912 ]  dump_stack+0x15/0x17
    [   44.175166 ]  ___might_sleep+0x3a2/0x510
    [   44.175459 ]  ? nj_release+0x69/0x500 [netjet]
    [   44.175791 ]  __might_sleep+0x82/0xe0
    [   44.176063 ]  ? start_flush_work+0x20/0x7b0
    [   44.176375 ]  start_flush_work+0x33/0x7b0
    [   44.176672 ]  ? trace_irq_enable_rcuidle+0x85/0x170
    [   44.177034 ]  ? kasan_quarantine_put+0xaa/0x1f0
    [   44.177372 ]  ? kasan_quarantine_put+0xaa/0x1f0
    [   44.177711 ]  __flush_work+0x11a/0x1a0
    [   44.177991 ]  ? flush_work+0x20/0x20
    [   44.178257 ]  ? lock_release+0x13c/0x8f0
    [   44.178550 ]  ? __kasan_check_write+0x14/0x20
    [   44.178872 ]  ? do_raw_spin_lock+0x148/0x360
    [   44.179187 ]  ? read_lock_is_recursive+0x20/0x20
    [   44.179530 ]  ? __kasan_check_read+0x11/0x20
    [   44.179846 ]  ? do_raw_spin_unlock+0x55/0x900
    [   44.180168 ]  ? ____kasan_slab_free+0x116/0x140
    [   44.180505 ]  ? _raw_spin_unlock_irqrestore+0x41/0x60
    [   44.180878 ]  ? skb_queue_purge+0x1a3/0x1c0
    [   44.181189 ]  ? kfree+0x13e/0x290
    [   44.181438 ]  flush_work+0x17/0x20
    [   44.181695 ]  mISDN_freedchannel+0xe8/0x100
    [   44.182006 ]  isac_release+0x210/0x260 [mISDNipac]
    [   44.182366 ]  nj_release+0xf6/0x500 [netjet]
    [   44.182685 ]  nj_remove+0x48/0x70 [netjet]
    [   44.182989 ]  pci_device_remove+0xa9/0x250

    Signed-off-by: Zheyu Ma <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit 207f6c3a82e19626aedad6e2f9aa0bb348495447
Author: Herve Codina <[email protected]>
Date:   Fri Oct 8 12:34:40 2021 +0200

    ARM: dts: spear3xx: Fix gmac node

    [ Upstream commit 6636fec29cdf6665bd219564609e8651f6ddc142 ]

    On SPEAr3xx, ethernet driver is not compatible with the SPEAr600
    one.
    Indeed, SPEAr3xx uses an earlier version of this IP (v3.40) and
    needs some driver tuning compare to SPEAr600.

    The v3.40 IP support was added to stmmac driver and this patch
    fixes this issue and use the correct compatible string for
    SPEAr3xx

    Signed-off-by: Herve Codina <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit cfe8c4a4d6eb21af53504c6b85393de2f8345685
Author: Herve Codina <[email protected]>
Date:   Fri Oct 8 12:34:39 2021 +0200

    net: stmmac: add support for dwmac 3.40a

    [ Upstream commit 9cb1d19f47fafad7dcf7c8564e633440c946cfd7 ]

    dwmac 3.40a is an old ip version that can be found on SPEAr3xx soc.

    Signed-off-by: Herve Codina <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

commit f03a8a85e91580f7881b24c24ab2e4e37d8080b1
Author: Filipe Manana <[email protected]>
Date:   Fri Oct 1 13:52:30 2021 +0100

    btrfs: deal with errors when checking if a dir entry exists during log replay

    [ Upstream commit 77a5b9e3d14cbce49ceed2766b2003c034c066dc ]

    Currently inode_in_dir() ignores errors returned from
    btrfs_lookup_dir_index_item() and from btrfs_lookup_dir_item(), treating
    any errors as if the directory entry does not exists in the fs/subvolume
    tree, which is obviously not correct, as we can get errors such as -EIO
    when reading extent buffers while searching the fs/subvolume's tree.

    Fix that by making inode_in_dir() return the errors and making its only
    caller, add_inode_ref(), deal…
warudooooo added a commit to warudooooo/android_kernel_sm6225_spes that referenced this issue Sep 20, 2023
…x/kernel/git/stable/linux-stable

    commit 00a95330f3b295d4a581c36a5f2949c731386e37
    Merge: 9e5a216016f0 a027d43cf3f2
    Author: warudo <[email protected]>
    Date:   Wed Sep 20 16:00:07 2023 +0800

        Merge tag 'v4.19.215'

        This is the 4.19.215 stable release

    commit a027d43cf3f2fdaabf467b4bcb92d0fe748c2eaf
    Author: Greg Kroah-Hartman <[email protected]>
    Date:   Tue Nov 2 18:26:46 2021 +0100

        Linux 4.19.215

        Link: https://lore.kernel.org/r/[email protected]
        Link: https://lore.kernel.org/r/[email protected]
        Tested-by: Jon Hunter <[email protected]>
        Tested-by: Shuah Khan <[email protected]>
        Tested-by: Guenter Roeck <[email protected]>
        Tested-by: Linux Kernel Functional Testing <[email protected]>
        Tested-by: Hulk Robot <[email protected]>
        Tested-by: Sudip Mukherjee <[email protected]>
        Tested-by: Pavel Machek (CIP) <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 1ff3c379248ea579aa122d4ca245028e4bc9af23
    Author: Xin Long <[email protected]>
    Date:   Wed Oct 20 07:42:47 2021 -0400

        sctp: add vtag check in sctp_sf_ootb

        [ Upstream commit 9d02831e517aa36ee6bdb453a0eb47bd49923fe3 ]

        sctp_sf_ootb() is called when processing DATA chunk in closed state,
        and many other places are also using it.

        The vtag in the chunk's sctphdr should be verified, otherwise, as
        later in chunk length check, it may send abort with the existent
        asoc's vtag, which can be exploited by one to cook a malicious
        chunk to terminate a SCTP asoc.

        When fails to verify the vtag from the chunk, this patch sets asoc
        to NULL, so that the abort will be made with the vtag from the
        received chunk later.

        Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
        Signed-off-by: Xin Long <[email protected]>
        Acked-by: Marcelo Ricardo Leitner <[email protected]>
        Signed-off-by: Jakub Kicinski <[email protected]>
        Signed-off-by: Sasha Levin <[email protected]>

    commit d9a4f990aab48dd5c134a9e76c7b651d404b05d3
    Author: Xin Long <[email protected]>
    Date:   Wed Oct 20 07:42:46 2021 -0400

        sctp: add vtag check in sctp_sf_do_8_5_1_E_sa

        [ Upstream commit ef16b1734f0a176277b7bb9c71a6d977a6ef3998 ]

        sctp_sf_do_8_5_1_E_sa() is called when processing SHUTDOWN_ACK chunk
        in cookie_wait and cookie_echoed state.

        The vtag in the chunk's sctphdr should be verified, otherwise, as
        later in chunk length check, it may send abort with the existent
        asoc's vtag, which can be exploited by one to cook a malicious
        chunk to terminate a SCTP asoc.

        Note that when fails to verify the vtag from SHUTDOWN-ACK chunk,
        SHUTDOWN COMPLETE message will still be sent back to peer, but
        with the vtag from SHUTDOWN-ACK chunk, as said in 5) of
        rfc4960#section-8.4.

        While at it, also remove the unnecessary chunk length check from
        sctp_sf_shut_8_4_5(), as it's already done in both places where
        it calls sctp_sf_shut_8_4_5().

        Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
        Signed-off-by: Xin Long <[email protected]>
        Acked-by: Marcelo Ricardo Leitner <[email protected]>
        Signed-off-by: Jakub Kicinski <[email protected]>
        Signed-off-by: Sasha Levin <[email protected]>

    commit 7bf2f6a30d1851c530ad5e4ee7e5c45fb6be0128
    Author: Xin Long <[email protected]>
    Date:   Wed Oct 20 07:42:45 2021 -0400

        sctp: add vtag check in sctp_sf_violation

        [ Upstream commit aa0f697e45286a6b5f0ceca9418acf54b9099d99 ]

        sctp_sf_violation() is called when processing HEARTBEAT_ACK chunk
        in cookie_wait state, and some other places are also using it.

        The vtag in the chunk's sctphdr should be verified, otherwise, as
        later in chunk length check, it may send abort with the existent
        asoc's vtag, which can be exploited by one to cook a malicious
        chunk to terminate a SCTP asoc.

        Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
        Signed-off-by: Xin Long <[email protected]>
        Acked-by: Marcelo Ricardo Leitner <[email protected]>
        Signed-off-by: Jakub Kicinski <[email protected]>
        Signed-off-by: Sasha Levin <[email protected]>

    commit 86044244fc6f9eaec0070cb668e0d500de22dbba
    Author: Xin Long <[email protected]>
    Date:   Wed Oct 20 07:42:44 2021 -0400

        sctp: fix the processing for COOKIE_ECHO chunk

        [ Upstream commit a64b341b8695e1c744dd972b39868371b4f68f83 ]

        1. In closed state: in sctp_sf_do_5_1D_ce():

          When asoc is NULL, making packet for abort will use chunk's vtag
          in sctp_ootb_pkt_new(). But when asoc exists, vtag from the chunk
          should be verified before using peer.i.init_tag to make packet
          for abort in sctp_ootb_pkt_new(), and just discard it if vtag is
          not correct.

        2. In the other states: in sctp_sf_do_5_2_4_dupcook():

          asoc always exists, but duplicate cookie_echo's vtag will be
          handled by sctp_tietags_compare() and then take actions, so before
          that we only verify the vtag for the abort sent for invalid chunk
          length.

        Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
        Signed-off-by: Xin Long <[email protected]>
        Acked-by: Marcelo Ricardo Leitner <[email protected]>
        Signed-off-by: Jakub Kicinski <[email protected]>
        Signed-off-by: Sasha Levin <[email protected]>

    commit 1f52dfacca7bb315d89f5ece5660b0337809798e
    Author: Xin Long <[email protected]>
    Date:   Wed Oct 20 07:42:41 2021 -0400

        sctp: use init_tag from inithdr for ABORT chunk

        [ Upstream commit 4f7019c7eb33967eb87766e0e4602b5576873680 ]

        Currently Linux SCTP uses the verification tag of the existing SCTP
        asoc when failing to process and sending the packet with the ABORT
        chunk. This will result in the peer accepting the ABORT chunk and
        removing the SCTP asoc. One could exploit this to terminate a SCTP
        asoc.

        This patch is to fix it by always using the initiate tag of the
        received INIT chunk for the ABORT chunk to be sent.

        Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
        Signed-off-by: Xin Long <[email protected]>
        Acked-by: Marcelo Ricardo Leitner <[email protected]>
        Signed-off-by: Jakub Kicinski <[email protected]>
        Signed-off-by: Sasha Levin <[email protected]>

    commit b75fa48e42d022d6757b7de29178d531df8cf43b
    Author: Trevor Woerner <[email protected]>
    Date:   Sun Oct 24 13:50:02 2021 -0400

        net: nxp: lpc_eth.c: avoid hang when bringing interface down

        commit ace19b992436a257d9a793672e57abc28fe83e2e upstream.

        A hard hang is observed whenever the ethernet interface is brought
        down. If the PHY is stopped before the LPC core block is reset,
        the SoC will hang. Comparing lpc_eth_close() and lpc_eth_open() I
        re-arranged the ordering of the functions calls in lpc_eth_close() to
        reset the hardware before stopping the PHY.
        Fixes: b7370112f519 ("lpc32xx: Added ethernet driver")
        Signed-off-by: Trevor Woerner <[email protected]>
        Acked-by: Vladimir Zapolskiy <[email protected]>
        Signed-off-by: David S. Miller <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 84a9eb9a2f179ea5e6398fe270560a8aaa16f996
    Author: Yuiko Oshino <[email protected]>
    Date:   Fri Oct 22 11:53:43 2021 -0400

        net: ethernet: microchip: lan743x: Fix dma allocation failure by using dma_set_mask_and_coherent

        commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

        The dma failure was reported in the raspberry pi github (issue #4117).
        https://github.com/raspberrypi/linux/issues/4117
        The use of dma_set_mask_and_coherent fixes the issue.
        Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

        Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
        Signed-off-by: Yuiko Oshino <[email protected]>
        Signed-off-by: David S. Miller <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit fcda74cc95aa450a6d17780ccb1a8853cac7d0cd
    Author: Yuiko Oshino <[email protected]>
    Date:   Fri Oct 22 11:13:53 2021 -0400

        net: ethernet: microchip: lan743x: Fix driver crash when lan743x_pm_resume fails

        commit d6423d2ec39cce2bfca418c81ef51792891576bc upstream.

        The driver needs to clean up and return when the initialization fails on resume.

        Fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver")
        Signed-off-by: Yuiko Oshino <[email protected]>
        Signed-off-by: David S. Miller <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 25d852a8adf017a478246d19c8b282e975521e8a
    Author: Guenter Roeck <[email protected]>
    Date:   Wed Oct 20 12:11:16 2021 -0700

        nios2: Make NIOS2_DTB_SOURCE_BOOL depend on !COMPILE_TEST

        commit 4a089e95b4d6bb625044d47aed0c442a8f7bd093 upstream.

        nios2:allmodconfig builds fail with

        make[1]: *** No rule to make target 'arch/nios2/boot/dts/""',
        	needed by 'arch/nios2/boot/dts/built-in.a'.  Stop.
        make: [Makefile:1868: arch/nios2/boot/dts] Error 2 (ignored)

        This is seen with compile tests since those enable NIOS2_DTB_SOURCE_BOOL,
        which in turn enables NIOS2_DTB_SOURCE. This causes the build error
        because the default value for NIOS2_DTB_SOURCE is an empty string.
        Disable NIOS2_DTB_SOURCE_BOOL for compile tests to avoid the error.

        Fixes: 2fc8483fdcde ("nios2: Build infrastructure")
        Signed-off-by: Guenter Roeck <[email protected]>
        Reviewed-by: Randy Dunlap <[email protected]>
        Signed-off-by: Dinh Nguyen <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 02302cbd52264337630a32848ac03648648e9685
    Author: Michael Chan <[email protected]>
    Date:   Mon Oct 25 05:05:28 2021 -0400

        net: Prevent infinite while loop in skb_tx_hash()

        commit 0c57eeecc559ca6bc18b8c4e2808bc78dbe769b0 upstream.

        Drivers call netdev_set_num_tc() and then netdev_set_tc_queue()
        to set the queue count and offset for each TC.  So the queue count
        and offset for the TCs may be zero for a short period after dev->num_tc
        has been set.  If a TX packet is being transmitted at this time in the
        code path netdev_pick_tx() -> skb_tx_hash(), skb_tx_hash() may see
        nonzero dev->num_tc but zero qcount for the TC.  The while loop that
        keeps looping while hash >= qcount will not end.

        Fix it by checking the TC's qcount to be nonzero before using it.

        Fixes: eadec877ce9c ("net: Add support for subordinate traffic classes to netdev_pick_tx")
        Reviewed-by: Andy Gospodarek <[email protected]>
        Signed-off-by: Michael Chan <[email protected]>
        Signed-off-by: David S. Miller <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit fbf150b16a3635634b7dfb7f229d8fcd643c6c51
    Author: Pavel Skripkin <[email protected]>
    Date:   Sun Oct 24 16:13:56 2021 +0300

        net: batman-adv: fix error handling

        commit 6f68cd634856f8ca93bafd623ba5357e0f648c68 upstream.

        Syzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was
        in wrong error handling in batadv_mesh_init().

        Before this patch batadv_mesh_init() was calling batadv_mesh_free() in case
        of any batadv_*_init() calls failure. This approach may work well, when
        there is some kind of indicator, which can tell which parts of batadv are
        initialized; but there isn't any.

        All written above lead to cleaning up uninitialized fields. Even if we hide
        ODEBUG warning by initializing bat_priv->nc.work, syzbot was able to hit
        GPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]

        To fix these bugs we can unwind batadv_*_init() calls one by one.
        It is good approach for 2 reasons: 1) It fixes bugs on error handling
        path 2) It improves the performance, since we won't call unneeded
        batadv_*_free() functions.

        So, this patch makes all batadv_*_init() clean up all allocated memory
        before returning with an error to no call correspoing batadv_*_free()
        and open-codes batadv_mesh_free() with proper order to avoid touching
        uninitialized fields.

        Link: https://lore.kernel.org/netdev/[email protected]/ [1]
        Reported-and-tested-by: [email protected]
        Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
        Signed-off-by: Pavel Skripkin <[email protected]>
        Acked-by: Sven Eckelmann <[email protected]>
        Signed-off-by: David S. Miller <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 3dae1a4eced3ee733d7222e69b8a55caf2d61091
    Author: Yang Yingliang <[email protected]>
    Date:   Tue Oct 12 10:37:35 2021 +0800

        regmap: Fix possible double-free in regcache_rbtree_exit()

        commit 55e6d8037805b3400096d621091dfbf713f97e83 upstream.

        In regcache_rbtree_insert_to_block(), when 'present' realloc failed,
        the 'blk' which is supposed to assign to 'rbnode->block' will be freed,
        so 'rbnode->block' points a freed memory, in the error handling path of
        regcache_rbtree_init(), 'rbnode->block' will be freed again in
        regcache_rbtree_exit(), KASAN will report double-free as follows:

        BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390
        Call Trace:
         slab_free_freelist_hook+0x10d/0x240
         kfree+0xce/0x390
         regcache_rbtree_exit+0x15d/0x1a0
         regcache_rbtree_init+0x224/0x2c0
         regcache_init+0x88d/0x1310
         __regmap_init+0x3151/0x4a80
         __devm_regmap_init+0x7d/0x100
         madera_spi_probe+0x10f/0x333 [madera_spi]
         spi_probe+0x183/0x210
         really_probe+0x285/0xc30

        To fix this, moving up the assignment of rbnode->block to immediately after
        the reallocation has succeeded so that the data structure stays valid even
        if the second reallocation fails.

        Reported-by: Hulk Robot <[email protected]>
        Fixes: 3f4ff561bc88b ("regmap: rbtree: Make cache_present bitmap per node")
        Signed-off-by: Yang Yingliang <[email protected]>
        Link: https://lore.kernel.org/r/[email protected]
        Signed-off-by: Mark Brown <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit cdaf7a469244b5e65ae5eda062ff5ea90172de62
    Author: Clément Bœsch <[email protected]>
    Date:   Sun Sep 5 02:20:27 2021 +0200

        arm64: dts: allwinner: h5: NanoPI Neo 2: Fix ethernet node

        commit 0764e365dacd0b8f75c1736f9236be280649bd18 upstream.

        RX and TX delay are provided by ethernet PHY. Reflect that in ethernet
        node.

        Fixes: 44a94c7ef989 ("arm64: dts: allwinner: H5: Restore EMAC changes")
        Signed-off-by: Clément Bœsch <[email protected]>
        Reviewed-by: Jernej Skrabec <[email protected]>
        Reviewed-by: Andrew Lunn <[email protected]>
        Signed-off-by: Maxime Ripard <[email protected]>
        Link: https://lore.kernel.org/r/[email protected]
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 2864b6d54244b82a8c7d4628a43055c57bfba80c
    Author: Patrisious Haddad <[email protected]>
    Date:   Wed Oct 6 12:31:53 2021 +0300

        RDMA/mlx5: Set user priority for DCT

        commit 1ab52ac1e9bc9391f592c9fa8340a6e3e9c36286 upstream.

        Currently, the driver doesn't set the PCP-based priority for DCT, hence
        DCT response packets are transmitted without user priority.

        Fix it by setting user provided priority in the eth_prio field in the DCT
        context, which in turn sets the value in the transmitted packet.

        Fixes: 776a3906b692 ("IB/mlx5: Add support for DC target QP")
        Link: https://lore.kernel.org/r/5fd2d94a13f5742d8803c218927322257d53205c.1633512672.git.leonro@nvidia.com
        Signed-off-by: Patrisious Haddad <[email protected]>
        Reviewed-by: Maor Gottlieb <[email protected]>
        Signed-off-by: Leon Romanovsky <[email protected]>
        Signed-off-by: Jason Gunthorpe <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 326da4f6ffdbd8671e86f69ded7a714dcc12fecf
    Author: Johan Hovold <[email protected]>
    Date:   Tue Oct 26 12:36:17 2021 +0200

        net: lan78xx: fix division by zero in send path

        commit db6c3c064f5d55fa9969f33eafca3cdbefbb3541 upstream.

        Add the missing endpoint max-packet sanity check to probe() to avoid
        division by zero in lan78xx_tx_bh() in case a malicious device has
        broken descriptors (or when doing descriptor fuzz testing).

        Note that USB core will reject URBs submitted for endpoints with zero
        wMaxPacketSize but that drivers doing packet-size calculations still
        need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip
        endpoint descriptors with maxpacket=0")).

        Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
        Cc: [email protected]      # 4.3
        Cc: [email protected] <[email protected]>
        Signed-off-by: Johan Hovold <[email protected]>
        Signed-off-by: David S. Miller <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 2ff5289793fd61c56ac8774408f27350e5da865f
    Author: Haibo Chen <[email protected]>
    Date:   Fri Oct 15 10:00:36 2021 +0800

        mmc: sdhci-esdhc-imx: clear the buffer_read_ready to reset standard tuning circuit

        commit 9af372dc70e9fdcbb70939dac75365e7b88580b4 upstream.

        To reset standard tuning circuit completely, after clear ESDHC_MIX_CTRL_EXE_TUNE,
        also need to clear bit buffer_read_ready, this operation will finally clear the
        USDHC IP internal logic flag execute_tuning_with_clr_buf, make sure the following
        normal data transfer will not be impacted by standard tuning logic used before.

        Find this issue when do quick SD card insert/remove stress test. During standard
        tuning prodedure, if remove SD card, USDHC standard tuning logic can't clear the
        internal flag execute_tuning_with_clr_buf. Next time when insert SD card, all
        data related commands can't get any data related interrupts, include data transfer
        complete interrupt, data timeout interrupt, data CRC interrupt, data end bit interrupt.
        Always trigger software timeout issue. Even reset the USDHC through bits in register
        SYS_CTRL (0x2C, bit28 reset tuning, bit26 reset data, bit 25 reset command, bit 24
        reset all) can't recover this. From the user's point of view, USDHC stuck, SD can't
        be recognized any more.

        Fixes: d9370424c948 ("mmc: sdhci-esdhc-imx: reset tuning circuit when power on mmc card")
        Signed-off-by: Haibo Chen <[email protected]>
        Acked-by: Adrian Hunter <[email protected]>
        Cc: [email protected]
        Link: https://lore.kernel.org/r/[email protected]
        Signed-off-by: Ulf Hansson <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 7824414c2903e2cfe56ea610387a22c0c88fb468
    Author: Shawn Guo <[email protected]>
    Date:   Mon Oct 4 10:49:35 2021 +0800

        mmc: sdhci: Map more voltage level to SDHCI_POWER_330

        commit 4217d07b9fb328751f877d3bd9550122014860a2 upstream.

        On Thundercomm TurboX CM2290, the eMMC OCR reports vdd = 23 (3.5 ~ 3.6 V),
        which is being treated as an invalid value by sdhci_set_power_noreg().
        And thus eMMC is totally broken on the platform.

        [    1.436599] ------------[ cut here ]------------
        [    1.436606] mmc0: Invalid vdd 0x17
        [    1.436640] WARNING: CPU: 2 PID: 69 at drivers/mmc/host/sdhci.c:2048 sdhci_set_power_noreg+0x168/0x2b4
        [    1.436655] Modules linked in:
        [    1.436662] CPU: 2 PID: 69 Comm: kworker/u8:1 Tainted: G        W         5.15.0-rc1+ #137
        [    1.436669] Hardware name: Thundercomm TurboX CM2290 (DT)
        [    1.436674] Workqueue: events_unbound async_run_entry_fn
        [    1.436685] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
        [    1.436692] pc : sdhci_set_power_noreg+0x168/0x2b4
        [    1.436698] lr : sdhci_set_power_noreg+0x168/0x2b4
        [    1.436703] sp : ffff800010803a60
        [    1.436705] x29: ffff800010803a60 x28: ffff6a9102465f00 x27: ffff6a9101720a70
        [    1.436715] x26: ffff6a91014de1c0 x25: ffff6a91014de010 x24: ffff6a91016af280
        [    1.436724] x23: ffffaf7b1b276640 x22: 0000000000000000 x21: ffff6a9101720000
        [    1.436733] x20: ffff6a9101720370 x19: ffff6a9101720580 x18: 0000000000000020
        [    1.436743] x17: 0000000000000000 x16: 0000000000000004 x15: ffffffffffffffff
        [    1.436751] x14: 0000000000000000 x13: 00000000fffffffd x12: ffffaf7b1b84b0bc
        [    1.436760] x11: ffffaf7b1b720d10 x10: 000000000000000a x9 : ffff800010803a60
        [    1.436769] x8 : 000000000000000a x7 : 000000000000000f x6 : 00000000fffff159
        [    1.436778] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff
        [    1.436787] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff6a9101718d80
        [    1.436797] Call trace:
        [    1.436800]  sdhci_set_power_noreg+0x168/0x2b4
        [    1.436805]  sdhci_set_ios+0xa0/0x7fc
        [    1.436811]  mmc_power_up.part.0+0xc4/0x164
        [    1.436818]  mmc_start_host+0xa0/0xb0
        [    1.436824]  mmc_add_host+0x60/0x90
        [    1.436830]  __sdhci_add_host+0x174/0x330
        [    1.436836]  sdhci_msm_probe+0x7c0/0x920
        [    1.436842]  platform_probe+0x68/0xe0
        [    1.436850]  really_probe.part.0+0x9c/0x31c
        [    1.436857]  __driver_probe_device+0x98/0x144
        [    1.436863]  driver_probe_device+0xc8/0x15c
        [    1.436869]  __device_attach_driver+0xb4/0x120
        [    1.436875]  bus_for_each_drv+0x78/0xd0
        [    1.436881]  __device_attach_async_helper+0xac/0xd0
        [    1.436888]  async_run_entry_fn+0x34/0x110
        [    1.436895]  process_one_work+0x1d0/0x354
        [    1.436903]  worker_thread+0x13c/0x470
        [    1.436910]  kthread+0x150/0x160
        [    1.436915]  ret_from_fork+0x10/0x20
        [    1.436923] ---[ end trace fcfac44cb045c3a8 ]---

        Fix the issue by mapping MMC_VDD_35_36 (and MMC_VDD_34_35) to
        SDHCI_POWER_330 as well.

        Signed-off-by: Shawn Guo <[email protected]>
        Acked-by: Adrian Hunter <[email protected]>
        Cc: [email protected]
        Link: https://lore.kernel.org/r/[email protected]
        Signed-off-by: Ulf Hansson <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 29d56f3790e684e630d56f500b59e834fa382209
    Author: Jaehoon Chung <[email protected]>
    Date:   Fri Oct 22 17:21:06 2021 +0900

        mmc: dw_mmc: exynos: fix the finding clock sample value

        commit 697542bceae51f7620af333b065dd09d213629fb upstream.

        Even though there are candiates value if can't find best value, it's
        returned -EIO. It's not proper behavior.
        If there is not best value, use a first candiate value to work eMMC.

        Signed-off-by: Jaehoon Chung <[email protected]>
        Tested-by: Marek Szyprowski <[email protected]>
        Tested-by: Christian Hewitt <[email protected]>
        Cc: [email protected]
        Fixes: c537a1c5ff63 ("mmc: dw_mmc: exynos: add variable delay tuning sequence")
        Link: https://lore.kernel.org/r/[email protected]
        Signed-off-by: Ulf Hansson <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 24f8658690477e8983f88cbfe21fb7f4062ad837
    Author: Wenbin Mei <[email protected]>
    Date:   Tue Oct 26 15:08:12 2021 +0800

        mmc: cqhci: clear HALT state after CQE enable

        commit 92b18252b91de567cd875f2e84722b10ab34ee28 upstream.

        While mmc0 enter suspend state, we need halt CQE to send legacy cmd(flush
        cache) and disable cqe, for resume back, we enable CQE and not clear HALT
        state.
        In this case MediaTek mmc host controller will keep the value for HALT
        state after CQE disable/enable flow, so the next CQE transfer after resume
        will be timeout due to CQE is in HALT state, the log as below:
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: timeout for tag 2
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: ============ CQHCI REGISTER DUMP ===========
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Caps:      0x100020b6 | Version:  0x00000510
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Config:    0x00001103 | Control:  0x00000001
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Int stat:  0x00000000 | Int enab: 0x00000006
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Int sig:   0x00000006 | Int Coal: 0x00000000
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: TDL base:  0xfd05f000 | TDL up32: 0x00000000
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Doorbell:  0x8000203c | TCN:      0x00000000
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x00000000
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Task clr:  0x00000000 | SSC1:     0x00001000
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: SSC2:      0x00000001 | DCMD rsp: 0x00000000
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: RED mask:  0xfdf9a080 | TERRI:    0x00000000
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: Resp idx:  0x00000000 | Resp arg: 0x00000000
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: CRNQP:     0x00000000 | CRNQDUN:  0x00000000
        <4>.(4)[318:kworker/4:1H]mmc0: cqhci: CRNQIS:    0x00000000 | CRNQIE:   0x00000000

        This change check HALT state after CQE enable, if CQE is in HALT state, we
        will clear it.

        Signed-off-by: Wenbin Mei <[email protected]>
        Cc: [email protected]
        Acked-by: Adrian Hunter <[email protected]>
        Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
        Link: https://lore.kernel.org/r/[email protected]
        Signed-off-by: Ulf Hansson <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 99641238575c26c2e47fa593f562dae476709d68
    Author: Johan Hovold <[email protected]>
    Date:   Mon Oct 25 13:56:08 2021 +0200

        mmc: vub300: fix control-message timeouts

        commit 8c8171929116cc23f74743d99251eedadf62341a upstream.

        USB control-message timeouts are specified in milliseconds and should
        specifically not vary with CONFIG_HZ.

        Fixes: 88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
        Cc: [email protected]      # 3.0
        Signed-off-by: Johan Hovold <[email protected]>
        Link: https://lore.kernel.org/r/[email protected]
        Signed-off-by: Ulf Hansson <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit c6d0d68d6da68159948cad3d808d61bb291a0283
    Author: Eric Dumazet <[email protected]>
    Date:   Sun Aug 29 15:16:14 2021 -0700

        ipv6: make exception cache less predictible

        commit a00df2caffed3883c341d5685f830434312e4a43 upstream.

        Even after commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()"),
        an attacker can still use brute force to learn some secrets from a victim
        linux host.

        One way to defeat these attacks is to make the max depth of the hash
        table bucket a random value.

        Before this patch, each bucket of the hash table used to store exceptions
        could contain 6 items under attack.

        After the patch, each bucket would contains a random number of items,
        between 6 and 10. The attacker can no longer infer secrets.

        This is slightly increasing memory size used by the hash table,
        we do not expect this to be a problem.

        Following patch is dealing with the same issue in IPv4.

        Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache")
        Signed-off-by: Eric Dumazet <[email protected]>
        Reported-by: Keyu Man <[email protected]>
        Cc: Wei Wang <[email protected]>
        Cc: Martin KaFai Lau <[email protected]>
        Reviewed-by: David Ahern <[email protected]>
        Signed-off-by: David S. Miller <[email protected]>
        [OP: adjusted context for 4.19 stable]
        Signed-off-by: Ovidiu Panait <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit ad829847ad59af8e26a1f1c345716099abbc7a58
    Author: Eric Dumazet <[email protected]>
    Date:   Fri Oct 29 10:50:26 2021 +0300

        ipv6: use siphash in rt6_exception_hash()

        commit 4785305c05b25a242e5314cc821f54ade4c18810 upstream.

        A group of security researchers brought to our attention
        the weakness of hash function used in rt6_exception_hash()

        Lets use siphash instead of Jenkins Hash, to considerably
        reduce security risks.

        Following patch deals with IPv4.

        Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache")
        Signed-off-by: Eric Dumazet <[email protected]>
        Reported-by: Keyu Man <[email protected]>
        Cc: Wei Wang <[email protected]>
        Cc: Martin KaFai Lau <[email protected]>
        Acked-by: Wei Wang <[email protected]>
        Signed-off-by: David S. Miller <[email protected]>
        [OP: adjusted context for 4.19 stable]
        Signed-off-by: Ovidiu Panait <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 6e2856767eb1a9cfcfcd82136928037f04920e97
    Author: Eric Dumazet <[email protected]>
    Date:   Fri Oct 29 10:50:25 2021 +0300

        ipv4: use siphash instead of Jenkins in fnhe_hashfun()

        commit 6457378fe796815c973f631a1904e147d6ee33b1 upstream.

        A group of security researchers brought to our attention
        the weakness of hash function used in fnhe_hashfun().

        Lets use siphash instead of Jenkins Hash, to considerably
        reduce security risks.

        Also remove the inline keyword, this really is distracting.

        Fixes: d546c621542d ("ipv4: harden fnhe_hashfun()")
        Signed-off-by: Eric Dumazet <[email protected]>
        Reported-by: Keyu Man <[email protected]>
        Cc: Willy Tarreau <[email protected]>
        Signed-off-by: David S. Miller <[email protected]>
        [OP: adjusted context for 4.19 stable]
        Signed-off-by: Ovidiu Panait <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 8121d0d4fd108280f5cd7b7fe8c6592adaa37be9
    Author: Pavel Skripkin <[email protected]>
    Date:   Thu Sep 30 20:49:42 2021 +0300

        Revert "net: mdiobus: Fix memory leak in __mdiobus_register"

        commit 10eff1f5788b6ffac212c254e2f3666219576889 upstream.

        This reverts commit ab609f25d19858513919369ff3d9a63c02cd9e2e.

        This patch is correct in the sense that we _should_ call device_put() in
        case of device_register() failure, but the problem in this code is more
        vast.

        We need to set bus->state to UNMDIOBUS_REGISTERED before calling
        device_register() to correctly release the device in mdiobus_free().
        This patch prevents us from doing it, since in case of device_register()
        failure put_device() will be called 2 times and it will cause UAF or
        something else.

        Also, Reported-by: tag in revered commit was wrong, since syzbot
        reported different leak in same function.

        Link: https://lore.kernel.org/netdev/20210928092657.GI2048@kadam/
        Acked-by: Yanfei Xu <[email protected]>
        Signed-off-by: Pavel Skripkin <[email protected]>
        Link: https://lore.kernel.org/r/f12fb1faa4eccf0f355788225335eb4309ff2599.1633024062.git.paskripkin@gmail.com
        Signed-off-by: Jakub Kicinski <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 4a9043ba1b0e9bea1da0fe34366222974f2c0f92
    Author: Krzysztof Kozlowski <[email protected]>
    Date:   Mon Oct 25 16:49:36 2021 +0200

        nfc: port100: fix using -ERRNO as command type mask

        commit 2195f2062e4cc93870da8e71c318ef98a1c51cef upstream.

        During probing, the driver tries to get a list (mask) of supported
        command types in port100_get_command_type_mask() function.  The value
        is u64 and 0 is treated as invalid mask (no commands supported).  The
        function however returns also -ERRNO as u64 which will be interpret as
        valid command mask.

        Return 0 on every error case of port100_get_command_type_mask(), so the
        probing will stop.

        Cc: <[email protected]>
        Fixes: 0347a6ab300a ("NFC: port100: Commands mechanism implementation")
        Signed-off-by: Krzysztof Kozlowski <[email protected]>
        Signed-off-by: David S. Miller <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit a36119f9b3fb069437383a8eff4e65181b6e7e2f
    Author: Zheyu Ma <[email protected]>
    Date:   Fri Oct 22 09:12:26 2021 +0000

        ata: sata_mv: Fix the error handling of mv_chip_id()

        commit a0023bb9dd9bc439d44604eeec62426a990054cd upstream.

        mv_init_host() propagates the value returned by mv_chip_id() which in turn
        gets propagated by mv_pci_init_one() and hits local_pci_probe().

        During the process of driver probing, the probe function should return < 0
        for failure, otherwise, the kernel will treat value > 0 as success.

        Since this is a bug rather than a recoverable runtime error we should
        use dev_alert() instead of dev_err().

        Signed-off-by: Zheyu Ma <[email protected]>
        Signed-off-by: Damien Le Moal <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 78c2dc1cdf0bdfc83e473d78f23da4d2aeb98142
    Author: Wang Hai <[email protected]>
    Date:   Tue Oct 26 20:40:15 2021 +0800

        usbnet: fix error return code in usbnet_probe()

        commit 6f7c88691191e6c52ef2543d6f1da8d360b27a24 upstream.

        Return error code if usb_maxpacket() returns 0 in usbnet_probe()

        Fixes: 397430b50a36 ("usbnet: sanity check for maxpacket")
        Reported-by: Hulk Robot <[email protected]>
        Signed-off-by: Wang Hai <[email protected]>
        Reviewed-by: Johan Hovold <[email protected]>
        Link: https://lore.kernel.org/r/[email protected]
        Signed-off-by: Jakub Kicinski <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 002d82227c0abe29118cf80f7e2f396b22d448ed
    Author: Oliver Neukum <[email protected]>
    Date:   Thu Oct 21 14:29:44 2021 +0200

        usbnet: sanity check for maxpacket

        commit 397430b50a363d8b7bdda00522123f82df6adc5e upstream.

        maxpacket of 0 makes no sense and oopses as we need to divide
        by it. Give up.

        V2: fixed typo in log and stylistic issues

        Signed-off-by: Oliver Neukum <[email protected]>
        Reported-by: [email protected]
        Reviewed-by: Johan Hovold <[email protected]>
        Link: https://lore.kernel.org/r/[email protected]
        Signed-off-by: Jakub Kicinski <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit d725978abb0bac6e0c427548dfd6db86709a2a1e
    Author: Nathan Chancellor <[email protected]>
    Date:   Sat Jan 5 19:35:25 2019 +0100

        ARM: 8819/1: Remove '-p' from LDFLAGS

        commit 091bb549f7722723b284f63ac665e2aedcf9dec9 upstream.

        This option is not supported by lld:

            ld.lld: error: unknown argument: -p

        This has been a no-op in binutils since 2004 (see commit dea514f51da1 in
        that tree). Given that the lowest officially supported of binutils for
        the kernel is 2.20, which was released in 2009, nobody needs this flag
        around so just remove it. Commit 1a381d4a0a9a ("arm64: remove no-op -p
        linker flag") did the same for arm64.

        Signed-off-by: Nathan Chancellor <[email protected]>
        Acked-by: Ard Biesheuvel <[email protected]>
        Acked-by: Nicolas Pitre <[email protected]>
        Reviewed-by: Nick Desaulniers <[email protected]>
        Reviewed-by: Stefan Agner <[email protected]>
        Signed-off-by: Russell King <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit aaf4e1b05cab800b36b40c1aa09f7c13ef30de56
    Author: Robin Murphy <[email protected]>
    Date:   Mon Jul 12 15:27:46 2021 +0100

        arm64: Avoid premature usercopy failure

        commit 295cf156231ca3f9e3a66bde7fab5e09c41835e0 upstream.

        Al reminds us that the usercopy API must only return complete failure
        if absolutely nothing could be copied. Currently, if userspace does
        something silly like giving us an unaligned pointer to Device memory,
        or a size which overruns MTE tag bounds, we may fail to honour that
        requirement when faulting on a multi-byte access even though a smaller
        access could have succeeded.

        Add a mitigation to the fixup routines to fall back to a single-byte
        copy if we faulted on a larger access before anything has been written
        to the destination, to guarantee making *some* forward progress. We
        needn't be too concerned about the overall performance since this should
        only occur when callers are doing something a bit dodgy in the first
        place. Particularly broken userspace might still be able to trick
        generic_perform_write() into an infinite loop by targeting write() at
        an mmap() of some read-only device register where the fault-in load
        succeeds but any store synchronously aborts such that copy_to_user() is
        genuinely unable to make progress, but, well, don't do that...

        CC: [email protected]
        Reported-by: Chen Huang <[email protected]>
        Suggested-by: Al Viro <[email protected]>
        Reviewed-by: Catalin Marinas <[email protected]>
        Signed-off-by: Robin Murphy <[email protected]>
        Link: https://lore.kernel.org/r/dc03d5c675731a1f24a62417dba5429ad744234e.1626098433.git.robin.murphy@arm.com
        Signed-off-by: Will Deacon <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>
        Signed-off-by: Chen Huang <[email protected]>

    commit 5909b851b5e11d04f299e5f0a8937e9dcc807248
    Author: Naveen N. Rao <[email protected]>
    Date:   Wed Oct 6 01:55:22 2021 +0530

        powerpc/bpf: Fix BPF_MOD when imm == 1

        commit 8bbc9d822421d9ac8ff9ed26a3713c9afc69d6c8 upstream.

        Only ignore the operation if dividing by 1.

        Fixes: 156d0e290e969c ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
        Signed-off-by: Naveen N. Rao <[email protected]>
        Tested-by: Johan Almbladh <[email protected]>
        Reviewed-by: Christophe Leroy <[email protected]>
        Acked-by: Song Liu <[email protected]>
        Acked-by: Johan Almbladh <[email protected]>
        Signed-off-by: Michael Ellerman <[email protected]>
        Link: https://lore.kernel.org/r/c674ca18c3046885602caebb326213731c675d06.1633464148.git.naveen.n.rao@linux.vnet.ibm.com
        [cascardo: use PPC_LI instead of EMIT(PPC_RAW_LI)]
        Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 901741a53d7cf45be861e881c0e3cba5b4bd1f94
    Author: Arnd Bergmann <[email protected]>
    Date:   Mon Oct 18 15:30:37 2021 +0100

        ARM: 9141/1: only warn about XIP address when not compile testing

        commit 48ccc8edf5b90622cdc4f8878e0042ab5883e2ca upstream.

        In randconfig builds, we sometimes come across this warning:

        arm-linux-gnueabi-ld: XIP start address may cause MPU programming issues

        While this is helpful for actual systems to figure out why it
        fails, the warning does not provide any benefit for build testing,
        so guard it in a check for CONFIG_COMPILE_TEST, which is usually
        set on randconfig builds.

        Fixes: 216218308cfb ("ARM: 8713/1: NOMMU: Support MPU in XIP configuration")
        Signed-off-by: Arnd Bergmann <[email protected]>
        Signed-off-by: Russell King (Oracle) <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit ee4b38ce37ed31beca29d3ebec7db3d5e87fe39e
    Author: Arnd Bergmann <[email protected]>
    Date:   Mon Oct 18 15:30:09 2021 +0100

        ARM: 9139/1: kprobes: fix arch_init_kprobes() prototype

        commit 1f323127cab086e4fd618981b1e5edc396eaf0f4 upstream.

        With extra warnings enabled, gcc complains about this function
        definition:

        arch/arm/probes/kprobes/core.c: In function 'arch_init_kprobes':
        arch/arm/probes/kprobes/core.c:465:12: warning: old-style function definition [-Wold-style-definition]
          465 | int __init arch_init_kprobes()

        Link: https://lore.kernel.org/all/[email protected]/

        Fixes: 24ba613c9d6c ("ARM kprobes: core code")
        Acked-by: Masami Hiramatsu <[email protected]>
        Signed-off-by: Arnd Bergmann <[email protected]>
        Signed-off-by: Russell King (Oracle) <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit c0b4f1db7feef31d401814121760b45aff7885c1
    Author: Arnd Bergmann <[email protected]>
    Date:   Mon Oct 18 15:30:04 2021 +0100

        ARM: 9134/1: remove duplicate memcpy() definition

        commit eaf6cc7165c9c5aa3c2f9faa03a98598123d0afb upstream.

        Both the decompressor code and the kasan logic try to override
        the memcpy() and memmove()  definitions, which leading to a clash
        in a KASAN-enabled kernel with XZ decompression:

        arch/arm/boot/compressed/decompress.c:50:9: error: 'memmove' macro redefined [-Werror,-Wmacro-redefined]
         #define memmove memmove
                ^
        arch/arm/include/asm/string.h:59:9: note: previous definition is here
         #define memmove(dst, src, len) __memmove(dst, src, len)
                ^
        arch/arm/boot/compressed/decompress.c:51:9: error: 'memcpy' macro redefined [-Werror,-Wmacro-redefined]
         #define memcpy memcpy
                ^
        arch/arm/include/asm/string.h:58:9: note: previous definition is here
         #define memcpy(dst, src, len) __memcpy(dst, src, len)
                ^

        Here we want the set of functions from the decompressor, so undefine
        the other macros before the override.

        Link: https://lore.kernel.org/linux-arm-kernel/CACRpkdZYJogU_SN3H9oeVq=zJkRgRT1gDz3xp59gdqWXxw-B=w@mail.gmail.com/
        Link: https://lore.kernel.org/lkml/[email protected]/

        Fixes: d6d51a96c7d6 ("ARM: 9014/2: Replace string mem* functions for KASan")
        Fixes: a7f464f3db93 ("ARM: 7001/2: Wire up support for the XZ decompressor")
        Reported-by: kernel test robot <[email protected]>
        Reviewed-by: Linus Walleij <[email protected]>
        Signed-off-by: Arnd Bergmann <[email protected]>
        Signed-off-by: Russell King (Oracle) <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 00dcbb2d2cd3594faa2f977f2f7175cf23d4e326
    Author: Nick Desaulniers <[email protected]>
    Date:   Mon Oct 4 18:03:28 2021 +0100

        ARM: 9133/1: mm: proc-macros: ensure *_tlb_fns are 4B aligned

        commit e6a0c958bdf9b2e1b57501fc9433a461f0a6aadd upstream.

        A kernel built with CONFIG_THUMB2_KERNEL=y and using clang as the
        assembler could generate non-naturally-aligned v7wbi_tlb_fns which
        results in a boot failure. The original commit adding the macro missed
        the .align directive on this data.

        Link: https://github.com/ClangBuiltLinux/linux/issues/1447
        Link: https://lore.kernel.org/all/[email protected]/
        Debugged-by: Ard Biesheuvel <[email protected]>
        Debugged-by: Nathan Chancellor <[email protected]>
        Debugged-by: Richard Henderson <[email protected]>

        Fixes: 66a625a88174 ("ARM: mm: proc-macros: Add generic proc/cache/tlb struct definition macros")
        Suggested-by: Ard Biesheuvel <[email protected]>
        Acked-by: Ard Biesheuvel <[email protected]>
        Signed-off-by: Nick Desaulniers <[email protected]>
        Tested-by: Nathan Chancellor <[email protected]>
        Signed-off-by: Russell King (Oracle) <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 38ec06730e44b2166e87fecca9e36380080801ac
    Author: Greg Kroah-Hartman <[email protected]>
    Date:   Wed Oct 27 09:53:15 2021 +0200

        Linux 4.19.214

        Link: https://lore.kernel.org/r/[email protected]
        Tested-by: Pavel Machek (CIP) <[email protected]>
        Tested-by: Linux Kernel Functional Testing <[email protected]>
        Tested-by: Shuah Khan <[email protected]>
        Tested-by: Sudip Mukherjee <[email protected]>
        Tested-by: Guenter Roeck <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 0b7d55ca605e611aceeadf7c29c75808faae951a
    Author: Nick Desaulniers <[email protected]>
    Date:   Wed Sep 8 19:25:59 2021 +0100

        ARM: 9122/1: select HAVE_FUTEX_CMPXCHG

        commit 9d417cbe36eee7afdd85c2e871685f8dab7c2dba upstream.

        tglx notes:
          This function [futex_detect_cmpxchg] is only needed when an
          architecture has to runtime discover whether the CPU supports it or
          not.  ARM has unconditional support for this, so the obvious thing to
          do is the below.

        Fixes linkage failure from Clang randconfigs:
        kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit: R_ARM_JUMP24 against `.init.text'
        and boot failures for CONFIG_THUMB2_KERNEL.

        Link: https://github.com/ClangBuiltLinux/linux/issues/325

        Comments from Nick Desaulniers:

         See-also: 03b8c7b623c8 ("futex: Allow architectures to skip
         futex_atomic_cmpxchg_inatomic() test")

        Reported-by: Arnd Bergmann <[email protected]>
        Reported-by: Nathan Chancellor <[email protected]>
        Suggested-by: Thomas Gleixner <[email protected]>
        Signed-off-by: Nick Desaulniers <[email protected]>
        Reviewed-by: Thomas Gleixner <[email protected]>
        Tested-by: Nathan Chancellor <[email protected]>
        Reviewed-by: Linus Walleij <[email protected]>
        Cc: [email protected] # v3.14+
        Reviewed-by: Arnd Bergmann <[email protected]>
        Signed-off-by: Russell King (Oracle) <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 3de1ed125fc4c35bf7abb08260646100a6dcb04e
    Author: Steven Rostedt (VMware) <[email protected]>
    Date:   Mon Oct 18 15:44:12 2021 -0400

        tracing: Have all levels of checks prevent recursion

        commit ed65df63a39a3f6ed04f7258de8b6789e5021c18 upstream.

        While writing an email explaining the "bit = 0" logic for a discussion on
        making ftrace_test_recursion_trylock() disable preemption, I discovered a
        path that makes the "not do the logic if bit is zero" unsafe.

        The recursion logic is done in hot paths like the function tracer. Thus,
        any code executed causes noticeable overhead. Thus, tricks are done to try
        to limit the amount of code executed. This included the recursion testing
        logic.

        Having recursion testing is important, as there are many paths that can
        end up in an infinite recursion cycle when tracing every function in the
        kernel. Thus protection is needed to prevent that from happening.

        Because it is OK to recurse due to different running context levels (e.g.
        an interrupt preempts a trace, and then a trace occurs in the interrupt
        handler), a set of bits are used to know which context one is in (normal,
        softirq, irq and NMI). If a recursion occurs in the same level, it is
        prevented*.

        Then there are infrastructure levels of recursion as well. When more than
        one callback is attached to the same function to trace, it calls a loop
        function to iterate over all the callbacks. Both the callbacks and the
        loop function have recursion protection. The callbacks use the
        "ftrace_test_recursion_trylock()" which has a "function" set of context
        bits to test, and the loop function calls the internal
        trace_test_and_set_recursion() directly, with an "internal" set of bits.

        If an architecture does not implement all the features supported by ftrace
        then the callbacks are never called directly, and the loop function is
        called instead, which will implement the features of ftrace.

        Since both the loop function and the callbacks do recursion protection, it
        was seemed unnecessary to do it in both locations. Thus, a trick was made
        to have the internal set of recursion bits at a more significant bit
        location than the function bits. Then, if any of the higher bits were set,
        the logic of the function bits could be skipped, as any new recursion
        would first have to go through the loop function.

        This is true for architectures that do not support all the ftrace
        features, because all functions being traced must first go through the
        loop function before going to the callbacks. But this is not true for
        architectures that support all the ftrace features. That's because the
        loop function could be called due to two callbacks attached to the same
        function, but then a recursion function inside the callback could be
        called that does not share any other callback, and it will be called
        directly.

        i.e.

         traced_function_1: [ more than one callback tracing it ]
           call loop_func

         loop_func:
           trace_recursion set internal bit
           call callback

         callback:
           trace_recursion [ skipped because internal bit is set, return 0 ]
           call traced_function_2

         traced_function_2: [ only traced by above callback ]
           call callback

         callback:
           trace_recursion [ skipped because internal bit is set, return 0 ]
           call traced_function_2

         [ wash, rinse, repeat, BOOM! out of shampoo! ]

        Thus, the "bit == 0 skip" trick is not safe, unless the loop function is
        call for all functions.

        Since we want to encourage architectures to implement all ftrace features,
        having them slow down due to this extra logic may encourage the
        maintainers to update to the latest ftrace features. And because this
        logic is only safe for them, remove it completely.

         [*] There is on layer of recursion that is allowed, and that is to allow
             for the transition between interrupt context (normal -> softirq ->
             irq -> NMI), because a trace may occur before the context update is
             visible to the trace recursion logic.

        Link: https://lore.kernel.org/all/[email protected]/
        Link: https://lkml.kernel.org/r/[email protected]

        Cc: Linus Torvalds <[email protected]>
        Cc: Petr Mladek <[email protected]>
        Cc: Ingo Molnar <[email protected]>
        Cc: "James E.J. Bottomley" <[email protected]>
        Cc: Helge Deller <[email protected]>
        Cc: Michael Ellerman <[email protected]>
        Cc: Benjamin Herrenschmidt <[email protected]>
        Cc: Paul Mackerras <[email protected]>
        Cc: Paul Walmsley <[email protected]>
        Cc: Palmer Dabbelt <[email protected]>
        Cc: Albert Ou <[email protected]>
        Cc: Thomas Gleixner <[email protected]>
        Cc: Borislav Petkov <[email protected]>
        Cc: "H. Peter Anvin" <[email protected]>
        Cc: Josh Poimboeuf <[email protected]>
        Cc: Jiri Kosina <[email protected]>
        Cc: Miroslav Benes <[email protected]>
        Cc: Joe Lawrence <[email protected]>
        Cc: Colin Ian King <[email protected]>
        Cc: Masami Hiramatsu <[email protected]>
        Cc: "Peter Zijlstra (Intel)" <[email protected]>
        Cc: Nicholas Piggin <[email protected]>
        Cc: Jisheng Zhang <[email protected]>
        Cc: =?utf-8?b?546L6LSH?= <[email protected]>
        Cc: Guo Ren <[email protected]>
        Cc: [email protected]
        Fixes: edc15cafcbfa3 ("tracing: Avoid unnecessary multiple recursion checks")
        Signed-off-by: Steven Rostedt (VMware) <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit a9831afa2dc8a18205403907c41aa4e0950ac611
    Author: Yanfei Xu <[email protected]>
    Date:   Sun Sep 26 12:53:13 2021 +0800

        net: mdiobus: Fix memory leak in __mdiobus_register

        commit ab609f25d19858513919369ff3d9a63c02cd9e2e upstream.

        Once device_register() failed, we should call put_device() to
        decrement reference count for cleanup. Or it will cause memory
        leak.

        BUG: memory leak
        unreferenced object 0xffff888114032e00 (size 256):
          comm "kworker/1:3", pid 2960, jiffies 4294943572 (age 15.920s)
          hex dump (first 32 bytes):
            00 00 00 00 00 00 00 00 08 2e 03 14 81 88 ff ff  ................
            08 2e 03 14 81 88 ff ff 90 76 65 82 ff ff ff ff  .........ve.....
          backtrace:
            [<ffffffff8265cfab>] kmalloc include/linux/slab.h:591 [inline]
            [<ffffffff8265cfab>] kzalloc include/linux/slab.h:721 [inline]
            [<ffffffff8265cfab>] device_private_init drivers/base/core.c:3203 [inline]
            [<ffffffff8265cfab>] device_add+0x89b/0xdf0 drivers/base/core.c:3253
            [<ffffffff828dd643>] __mdiobus_register+0xc3/0x450 drivers/net/phy/mdio_bus.c:537
            [<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
            [<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
            [<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
            [<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
            [<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
            [<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
            [<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
            [<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
            [<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
            [<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
            [<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
            [<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
            [<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969
            [<ffffffff82660916>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487
            [<ffffffff8265cd0b>] device_add+0x5fb/0xdf0 drivers/base/core.c:3359
            [<ffffffff82c343b9>] usb_set_configuration+0x9d9/0xb90 drivers/usb/core/message.c:2170
            [<ffffffff82c4473c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238

        BUG: memory leak
        unreferenced object 0xffff888116f06900 (size 32):
          comm "kworker/0:2", pid 2670, jiffies 4294944448 (age 7.160s)
          hex dump (first 32 bytes):
            75 73 62 2d 30 30 31 3a 30 30 33 00 00 00 00 00  usb-001:003.....
            00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          backtrace:
            [<ffffffff81484516>] kstrdup+0x36/0x70 mm/util.c:60
            [<ffffffff814845a3>] kstrdup_const+0x53/0x80 mm/util.c:83
            [<ffffffff82296ba2>] kvasprintf_const+0xc2/0x110 lib/kasprintf.c:48
            [<ffffffff82358d4b>] kobject_set_name_vargs+0x3b/0xe0 lib/kobject.c:289
            [<ffffffff826575f3>] dev_set_name+0x63/0x90 drivers/base/core.c:3147
            [<ffffffff828dd63b>] __mdiobus_register+0xbb/0x450 drivers/net/phy/mdio_bus.c:535
            [<ffffffff828cb835>] __devm_mdiobus_register+0x75/0xf0 drivers/net/phy/mdio_devres.c:87
            [<ffffffff82b92a00>] ax88772_init_mdio drivers/net/usb/asix_devices.c:676 [inline]
            [<ffffffff82b92a00>] ax88772_bind+0x330/0x480 drivers/net/usb/asix_devices.c:786
            [<ffffffff82baa33f>] usbnet_probe+0x3ff/0xdf0 drivers/net/usb/usbnet.c:1745
            [<ffffffff82c36e17>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396
            [<ffffffff82661d17>] call_driver_probe drivers/base/dd.c:517 [inline]
            [<ffffffff82661d17>] really_probe.part.0+0xe7/0x380 drivers/base/dd.c:596
            [<ffffffff826620bc>] really_probe drivers/base/dd.c:558 [inline]
            [<ffffffff826620bc>] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:751
            [<ffffffff826621ba>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:781
            [<ffffffff82662a26>] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:898
            [<ffffffff8265eca7>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427
            [<ffffffff826625a2>] __device_attach+0x122/0x260 drivers/base/dd.c:969

        Reported-by: [email protected]
        Signed-off-by: Yanfei Xu <[email protected]>
        Reviewed-by: Andrew Lunn <[email protected]>
        Signed-off-by: David S. Miller <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 629e870ca473bbf3ec2429d441efb0406869783d
    Author: Dexuan Cui <[email protected]>
    Date:   Thu Oct 7 21:35:46 2021 -0700

        scsi: core: Fix shost->cmd_per_lun calculation in scsi_add_host_with_dma()

        commit 50b6cb3516365cb69753b006be2b61c966b70588 upstream.

        After commit ea2f0f77538c ("scsi: core: Cap scsi_host cmd_per_lun at
        can_queue"), a 416-CPU VM running on Hyper-V hangs during boot because the
        hv_storvsc driver sets scsi_driver.can_queue to an integer value that
        exceeds SHRT_MAX, and hence scsi_add_host_with_dma() sets
        shost->cmd_per_lun to a negative "short" value.

        Use min_t(int, ...) to work around the issue.

        Link: https://lore.kernel.org/r/[email protected]
        Fixes: ea2f0f77538c ("scsi: core: Cap scsi_host cmd_per_lun at can_queue")
        Cc: [email protected]
        Reviewed-by: Haiyang Zhang <[email protected]>
        Reviewed-by: Ming Lei <[email protected]>
        Reviewed-by: John Garry <[email protected]>
        Signed-off-by: Dexuan Cui <[email protected]>
        Signed-off-by: Martin K. Petersen <[email protected]>
        Signed-off-by: Greg Kroah-Hartman <[email protected]>

    commit 1360f9cde7eaaea4e6b48ab4ec544c706dbc6a8a
    Author: Kai Vehmanen <[email protected]>
    Date:   Tue Oct 12 17:29:35 2021 +0300

        ALSA: hda: avoid write to STATESTS if controller is in reset

        [ Upstream commit b37a15188eae9d4c49c5bb035e0c8d4058e4d9b3 ]

        The snd_hdac_bus_reset_link() contains logic to clear STATESTS register
        before performing controller reset. This code dates back to an old
        bugfix in commit e8a7f136f5ed ("[ALSA] hda-intel - Improve HD-audio
        codec probing robustness"). Originally the code was added to
        azx_reset().

        The code was moved around in commit a41d122449be ("ALSA: hda - Embed bus
        into controller object") and ended up to snd_hdac_bus_reset_link() and
        called primarily via snd_hdac_bus_init_chip().

        The logic to clear STATESTS is correct when snd_hdac_bus_init_chip() is
        called when controller is not in reset. In this case, STATESTS can be
        cleared. This can be useful e.g. when forcing a controller reset to retry
        codec probe. A normal non-power-on reset will not clear the bits.

        However, this old logic is problematic when controller is already in
        reset. The HDA specification states that controller must be taken out of
        reset before writing to registers other than GCTL.CRST (1.0a spec,
        3.3.7). The write to STATESTS in snd_hdac_bus_reset_link() will be lost
        if the controller is already in reset per the HDA specification mentioned.

        This has been harmless on older hardware. On newer generation of Intel
        PCIe based HDA controllers, if configured to report issues, this write
        will emit an unsupported request error. If ACPI Platform Error Interface
        (APEI) is enabled in kernel, this will end up to kernel log.

        Fix the code in snd_hdac_bus_reset_link() to only clear the STATESTS if
        the function is called when controller is not in reset. Otherwise
        clearing the bits is not possible and should be skipped.

        Signed-off-by: Kai Vehmanen <[email protected]>
        Link: https://lore.kernel.org/r/[email protected]
        Signed-off-by: Takashi Iwai <[email protected]>
        Signed-off-by: Sasha Levin <[email protected]>

    commit f7db1bc1cdb809fdd65d50485fb67bd418eadbd5
    Author: Prashant Malani <[email protected]>
    Date:   Tue Sep 28 03:19:34 2021 -0700

        platform/x86: intel_scu_ipc: Update timeout value in comment

        [ Upstream commit a0c5814b9933f25ecb6de169483c5b88cf632bca ]

        The comment decribing the IPC timeout hadn't been updated when the
        actual timeout was changed from 3 to 5 seconds in
        commit a7d53dbbc70a ("platform/x86: intel_scu_ipc: Increase virtual
        timeout from 3 to 5 seconds") .

        Since the value is anyway updated to 10s now, take this opportunity to
        update the value in the comment too.

        Signed-off-by: Prashant Malani <[email protected]>
        Cc: Benson Leung <[email protected]>
        Reviewed-by: Mika Westerberg <[email protected]>
        Link: https://lore.kernel.org/r/[email protected]
        Signed-off-by: Hans de Goede <[email protected]>
        Signed-off-by: Sasha Levin <[email protected]>

    commit a5b34409d3fc52114c828be4adbc30744fa3258b
    Author: Zheyu Ma <[email protected]>
    Date:   Sat Oct 9 11:33:49 2021 +0000

        isdn: mISDN: Fix sleeping function called from invalid context

        [ Upstream commit 6510e80a0b81b5d814e3aea6297ba42f5e76f73c ]

        The driver can call card->isac.release() function from an atomic
        context.

        Fix this by calling this function after releasing the lock.

        The following log reveals it:

        [   44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018
        [   44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe
        [   44.169574 ] INFO: lockdep is tu…
Dheeraj3031A pushed a commit to Dheeraj3031A/kernel_oplus_RMX3461 that referenced this issue Jan 21, 2024
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
RT1648 pushed a commit to RT1648/android_kernel_asus_sdm660 that referenced this issue Feb 17, 2024
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
RT1648 pushed a commit to RT1648/android_kernel_asus_sdm660 that referenced this issue Feb 17, 2024
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
RT1648 pushed a commit to RT1648/android_kernel_asus_sdm660 that referenced this issue Feb 17, 2024
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
RT1648 pushed a commit to RT1648/android_kernel_asus_sdm660 that referenced this issue Feb 17, 2024
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
FakeShell pushed a commit to FuriLabs/linux-android-furiphone-krypton that referenced this issue Aug 20, 2024
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
xnnnsets pushed a commit to xnnnsets/android_kernel_samsung_a34x that referenced this issue Nov 10, 2024
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Badmaneers pushed a commit to Badmaneers/kernel_even_4.19 that referenced this issue Dec 27, 2024
…g dma_set_mask_and_coherent

commit 95a359c9553342d36d408d35331ff0bfce75272f upstream.

The dma failure was reported in the raspberry pi github (issue #4117).
raspberrypi/linux#4117
The use of dma_set_mask_and_coherent fixes the issue.
Tested on 32/64-bit raspberry pi CM4 and 64-bit ubuntu x86 PC with EVB-LAN7430.

Fixes: 23f0703 ("lan743x: Add main source files for new lan743x driver")
Signed-off-by: Yuiko Oshino <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants