aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-04-21MAINTAINERS: add Bug entry for Samsung and memory controller driversKrzysztof Kozlowski1-0/+7
Add a Bug sections, indicating preferred mailing method for bug reports, to Samsung SoC related entries and memory controller drivers. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220420104708.106738-1-krzysztof.kozlowski@linaro.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21memory: renesas-rpc-if: Fix HF/OSPI data transfer in Manual ModeGeert Uytterhoeven2-14/+47
HyperFlash devices fail to probe: rpc-if-hyperflash rpc-if-hyperflash: probing of hyperbus device failed In HyperFlash or Octal-SPI Flash mode, the Transfer Data Enable bits (SPIDE) in the Manual Mode Enable Setting Register (SMENR) are derived from half of the transfer size, cfr. the rpcif_bits_set() helper function. However, rpcif_reg_{read,write}() does not take the bus size into account, and does not double all Manual Mode Data Register access sizes when communicating with a HyperFlash or Octal-SPI Flash device. Fix this, and avoid the back-and-forth conversion between transfer size and Transfer Data Enable bits, by explicitly storing the transfer size in struct rpcif, and using that value to determine access size in rpcif_reg_{read,write}(). Enforce that the "high" Manual Mode Read/Write Data Registers (SM[RW]DR1) are only used for 8-byte data accesses. While at it, forbid writing to the Manual Mode Read Data Registers, as they are read-only. Fixes: fff53a551db50f5e ("memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/cde9bfacf704c81865f57b15d1b48a4793da4286.1649681476.git.geert+renesas@glider.be Link: https://lore.kernel.org/r/20220420070526.9367-1-krzysztof.kozlowski@linaro.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21ASoC: rsnd: care return value from rsnd_node_fixed_index()Kuninori Morimoto6-11/+43
Renesas Sound is very complex, and thus it needs to use rsnd_node_fixed_index() to know enabled pin index. It returns error if strange pin was selected, but some codes didn't check it. This patch 1) indicates error message, 2) check return value. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87pmlbgn5t.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-21ASoC: audio-graph-card2: indicate "Experimental stage" warning only when successedKuninori Morimoto1-2/+3
Because Sound Card needs many drivers to probe, current audio-graph-card2 will indicate "Experimental stage" at top of probe function even though in case it gets -EPROBE_DEFER, thus it will be indicated many times. This patch indicates it when probe was succeeded. [ 1.601393] asoc-audio-graph-card2 sound: Audio Graph Card2 is still under Experimental stage ... [ 1.721269] asoc-audio-graph-card2 sound: Audio Graph Card2 is still under Experimental stage ... [ 1.755231] asoc-audio-graph-card2 sound: Audio Graph Card2 is still under Experimental stage ... [ 1.907710] asoc-audio-graph-card2 sound: Audio Graph Card2 is still under Experimental stage ... [ 1.933173] rcar_sound ec500000.sound: probed [ 1.948875] asoc-audio-graph-card2 sound: Audio Graph Card2 is still under Experimental stage [ 1.959558] asoc-audio-graph-card2 sound: ak4613-hifi <-> rsnd-dai.0 mapping ok [ 1.968119] asoc-audio-graph-card2 sound: i2s-hifi <-> rsnd-dai.1 mapping ok Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87o80vgn5a.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-21ASoC: rsnd: care default case on rsnd_ssiu_busif_err_status_clear()Kuninori Morimoto1-1/+3
commit cfb7b8bf1e2d66 ("ASoC: rsnd: tidyup rsnd_ssiu_busif_err_status_clear()") merged duplicate code, but it didn't care about default case, and causes smatch warnings. smatch warnings: sound/soc/sh/rcar/ssiu.c:112 rsnd_ssiu_busif_err_status_clear() \ error: uninitialized symbol 'offset'. sound/soc/sh/rcar/ssiu.c:114 rsnd_ssiu_busif_err_status_clear() \ error: uninitialized symbol 'shift'. This patch cares it. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87r15rgn6p.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-21ASoC: dt-bindings: max98390: add reset gpio bindingsSteve Lee1-0/+5
This adds support for the reset gpio binding. Signed-off-by: Steve Lee <steve.lee.analog@gmail.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220420044900.2989-2-steve.lee.analog@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-21ASoC: max98390: Add reset gpio controlSteve Lee1-0/+12
Add reset gpio control to support RESET PIN connected to gpio. Signed-off-by: Steve Lee <steve.lee.analog@gmail.com> Acked-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220420044900.2989-1-steve.lee.analog@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-21selftests/bpf: Fix attach tests retcode checksArtem Savkov2-2/+2
Switching to libbpf 1.0 API broke test_sock and test_sysctl as they check for return of bpf_prog_attach to be exactly -1. Switch the check to '< 0' instead. Fixes: b858ba8c52b6 ("selftests/bpf: Use libbpf 1.0 API mode instead of RLIMIT_MEMLOCK") Signed-off-by: Artem Savkov <asavkov@redhat.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Yafang Shao <laoar.shao@gmail.com> Link: https://lore.kernel.org/bpf/20220421130104.1582053-1-asavkov@redhat.com
2022-04-21i40e, xsk: Get rid of redundant 'fallthrough'Maciej Fijalkowski1-1/+0
Intel drivers translate actions returned from XDP programs to their own return codes that have the following mapping: XDP_REDIRECT -> I40E_XDP_{REDIR,CONSUMED} XDP_TX -> I40E_XDP_{TX,CONSUMED} XDP_DROP -> I40E_XDP_CONSUMED XDP_ABORTED -> I40E_XDP_CONSUMED XDP_PASS -> I40E_XDP_PASS Commit b8aef650e549 ("i40e, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full") introduced new translation XDP_REDIRECT -> I40E_XDP_EXIT which is set when XSK RQ gets full and to indicate that driver should stop further Rx processing. This happens for unsuccessful xdp_do_redirect() so it is valuable to call trace_xdp_exception() for this case. In order to avoid I40E_XDP_EXIT -> IXGBE_XDP_CONSUMED overwrite, XDP_DROP case was moved above which in turn made the 'fallthrough' that is in XDP_ABORTED useless as it became the last label in the switch statement. Simply drop this leftover. Fixes: b8aef650e549 ("i40e, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full") Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220421132126.471515-3-maciej.fijalkowski@intel.com
2022-04-21ixgbe, xsk: Get rid of redundant 'fallthrough'Maciej Fijalkowski1-1/+0
Intel drivers translate actions returned from XDP programs to their own return codes that have the following mapping: XDP_REDIRECT -> IXGBE_XDP_{REDIR,CONSUMED} XDP_TX -> IXGBE_XDP_{TX,CONSUMED} XDP_DROP -> IXGBE_XDP_CONSUMED XDP_ABORTED -> IXGBE_XDP_CONSUMED XDP_PASS -> IXGBE_XDP_PASS Commit c7dd09fd4628 ("ixgbe, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full") introduced new translation XDP_REDIRECT -> IXGBE_XDP_EXIT which is set when XSK RQ gets full and to indicate that driver should stop further Rx processing. This happens for unsuccessful xdp_do_redirect() so it is valuable to call trace_xdp_exception() for this case. In order to avoid IXGBE_XDP_EXIT -> IXGBE_XDP_CONSUMED overwrite, XDP_DROP case was moved above which in turn made the 'fallthrough' that is in XDP_ABORTED useless as it became the last label in the switch statement. Simply drop this leftover. Fixes: c7dd09fd4628 ("ixgbe, xsk: Terminate Rx side of NAPI when XSK Rx queue gets full") Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220421132126.471515-2-maciej.fijalkowski@intel.com
2022-04-21bpf: Move check_ptr_off_reg before check_map_accessKumar Kartikeya Dwivedi1-38/+38
Some functions in next patch want to use this function, and those functions will be called by check_map_access, hence move it before check_map_access. Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Joanne Koong <joannelkoong@gmail.com> Link: https://lore.kernel.org/bpf/20220415160354.1050687-3-memxor@gmail.com
2022-04-21bpf: Make btf_find_field more genericKumar Kartikeya Dwivedi1-31/+89
Next commit introduces field type 'kptr' whose kind will not be struct, but pointer, and it will not be limited to one offset, but multiple ones. Make existing btf_find_struct_field and btf_find_datasec_var functions amenable to use for finding kptrs in map value, by moving spin_lock and timer specific checks into their own function. The alignment, and name are checked before the function is called, so it is the last point where we can skip field or return an error before the next loop iteration happens. Size of the field and type is meant to be checked inside the function. Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220415160354.1050687-2-memxor@gmail.com
2022-04-21libbpf: Add documentation to API functionsGrant Seltzer1-0/+76
This adds documentation for the following API functions: - bpf_program__set_expected_attach_type() - bpf_program__set_type() - bpf_program__set_attach_target() - bpf_program__attach() - bpf_program__pin() - bpf_program__unpin() Signed-off-by: Grant Seltzer <grantseltzer@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220420161226.86803-3-grantseltzer@gmail.com
2022-04-21pinctrl: stm32: Do not call stm32_gpio_get() for edge triggered IRQs in EOIMarek Vasut1-0/+4
The stm32_gpio_get() should only be called for LEVEL triggered interrupts, skip calling it for EDGE triggered interrupts altogether to avoid wasting CPU cycles in EOI handler. On this platform, EDGE triggered interrupts are the majority and LEVEL triggered interrupts are the exception no less, and the CPU cycles are not abundant. Fixes: 47beed513a85b ("pinctrl: stm32: Add level interrupt support to gpio irq chip") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Cc: Fabien Dessenne <fabien.dessenne@foss.st.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Marc Zyngier <maz@kernel.org> Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-arm-kernel@lists.infradead.org To: linux-gpio@vger.kernel.org Link: https://lore.kernel.org/r/20220415215410.498349-1-marex@denx.de Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-21pinctrl: Fix an error in pin-function table of SP7021Wells Lu1-0/+8
The first valid item of pin-function table should start from the third item. The first two items, due to historical and compatible reasons, should be dummy items. The two dummy items were removed accidentally in initial submission. This fix adds them back. Signed-off-by: Wells Lu <wellslutw@gmail.com> Link: https://lore.kernel.org/r/1650015688-19774-1-git-send-email-wellslutw@gmail.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-21libbpf: Update API functions usage to check errorGrant Seltzer1-7/+5
This updates usage of the following API functions within libbpf so their newly added error return is checked: - bpf_program__set_expected_attach_type() - bpf_program__set_type() Signed-off-by: Grant Seltzer <grantseltzer@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220420161226.86803-2-grantseltzer@gmail.com
2022-04-21libbpf: Add error returns to two API functionsGrant Seltzer2-5/+13
This adds an error return to the following API functions: - bpf_program__set_expected_attach_type() - bpf_program__set_type() In both cases, the error occurs when the BPF object has already been loaded when the function is called. In this case -EBUSY is returned. Signed-off-by: Grant Seltzer <grantseltzer@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220420161226.86803-1-grantseltzer@gmail.com
2022-04-21pinctrl: ocelot: add clock monitor option for LAN966xMichael Walle1-2/+4
The SoC supports a debug clock output of its internal clocks. Depending on the clk_sel input (GPIO_31) clk_mon (GPIO_30) will output either cpu_clk/64 or sys_clk/64. This is very useful for debugging and is missing in the pinmux table. Add it. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20220326192848.2944519-2-michael@walle.cc Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-21pinctrl: ocelot: add pwm output option for LAN966xMichael Walle1-2/+6
According to the reference manual, you can mux the PWM output on GPIO27 and GPIO51. This was missing in the pinmux table. Add it. Tested on a LAN9668 on GPIO51. Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20220326192848.2944519-1-michael@walle.cc Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-21dt-bindings: pinctrl: convert ocelot-pinctrl to YAML formatMichael Walle2-42/+108
Convert the ocelot-pinctrl device tree binding to the new YAML format. Additionally to the original binding documentation, add interrupt properties which are optional and already used on several SoCs like SparX-5, Luton, Ocelot and LAN966x but were not documented before. Also, on the sparx5 and the lan966x SoCs there are two items for the reg property. Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20220319204628.1759635-7-michael@walle.cc Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-21pinctrl: qcom-pmic-gpio: Add support for pmx65Rohit Agarwal1-0/+1
PMX65 pmic support gpio controller so add compatible. Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> Link: https://lore.kernel.org/r/1649048650-14059-3-git-send-email-quic_rohiagar@quicinc.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-21dt-bindings: pinctrl: qcom-pmic-gpio: Add pmx65 supportRohit Agarwal1-0/+2
Add support for the PMX65 GPIO support to the Qualcomm PMIC GPIO binding. Signed-off-by: Rohit Agarwal <quic_rohiagar@quicinc.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/1649048650-14059-2-git-send-email-quic_rohiagar@quicinc.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-21pinctrl: bcm2835: implement hook for missing gpio-rangesStefan Wahren1-0/+18
The commit c8013355ead6 ("ARM: dts: gpio-ranges property is now required") fixed the GPIO probing issues caused by "pinctrl: bcm2835: Change init order for gpio hogs". This changed only the kernel DTS files. Unfortunately it isn't guaranteed that these files are shipped to all users. So implement the necessary backward compatibility for BCM2835 and BCM2711 platform. Fixes: 266423e60ea1 ("pinctrl: bcm2835: Change init order for gpio hogs") Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20220409095129.45786-3-stefan.wahren@i2se.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-21gpiolib: of: Introduce hook for missing gpio-rangesStefan Wahren2-0/+17
Since commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") the device tree nodes of GPIO controller need the gpio-ranges property to handle gpio-hogs. Unfortunately it's impossible to guarantee that every new kernel is shipped with an updated device tree binary. In order to provide backward compatibility with those older DTB, we need a callback within of_gpiochip_add_pin_range() so the relevant platform driver can handle this case. Fixes: 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges") Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Bartosz Golaszewski <brgl@bgdev.pl> Link: https://lore.kernel.org/r/20220409095129.45786-2-stefan.wahren@i2se.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2022-04-21btrfs: zoned: use dedicated lock for data relocationNaohiro Aota3-2/+4
Currently, we use btrfs_inode_{lock,unlock}() to grant an exclusive writeback of the relocation data inode in btrfs_zoned_data_reloc_{lock,unlock}(). However, that can cause a deadlock in the following path. Thread A takes btrfs_inode_lock() and waits for metadata reservation by e.g, waiting for writeback: prealloc_file_extent_cluster() - btrfs_inode_lock(&inode->vfs_inode, 0); - btrfs_prealloc_file_range() ... - btrfs_replace_file_extents() - btrfs_start_transaction ... - btrfs_reserve_metadata_bytes() Thread B (e.g, doing a writeback work) needs to wait for the inode lock to continue writeback process: do_writepages - btrfs_writepages - extent_writpages - btrfs_zoned_data_reloc_lock(BTRFS_I(inode)); - btrfs_inode_lock() The deadlock is caused by relying on the vfs_inode's lock. By using it, we introduced unnecessary exclusion of writeback and btrfs_prealloc_file_range(). Also, the lock at this point is useless as we don't have any dirty pages in the inode yet. Introduce fs_info->zoned_data_reloc_io_lock and use it for the exclusive writeback. Fixes: 35156d852762 ("btrfs: zoned: only allow one process to add pages to a relocation inode") CC: stable@vger.kernel.org # 5.16.x: 869f4cdc73f9: btrfs: zoned: encapsulate inode locking for zoned relocation CC: stable@vger.kernel.org # 5.16.x CC: stable@vger.kernel.org # 5.17 Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com> Signed-off-by: David Sterba <dsterba@suse.com>
2022-04-21btrfs: fix assertion failure during scrub due to block group reallocationFilipe Manana2-2/+31
During a scrub, or device replace, we can race with block group removal and allocation and trigger the following assertion failure: [7526.385524] assertion failed: cache->start == chunk_offset, in fs/btrfs/scrub.c:3817 [7526.387351] ------------[ cut here ]------------ [7526.387373] kernel BUG at fs/btrfs/ctree.h:3599! [7526.388001] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [7526.388970] CPU: 2 PID: 1158150 Comm: btrfs Not tainted 5.17.0-rc8-btrfs-next-114 #4 [7526.390279] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [7526.392430] RIP: 0010:assertfail.constprop.0+0x18/0x1a [btrfs] [7526.393520] Code: f3 48 c7 c7 20 (...) [7526.396926] RSP: 0018:ffffb9154176bc40 EFLAGS: 00010246 [7526.397690] RAX: 0000000000000048 RBX: ffffa0db8a910000 RCX: 0000000000000000 [7526.398732] RDX: 0000000000000000 RSI: ffffffff9d7239a2 RDI: 00000000ffffffff [7526.399766] RBP: ffffa0db8a911e10 R08: ffffffffa71a3ca0 R09: 0000000000000001 [7526.400793] R10: 0000000000000001 R11: 0000000000000000 R12: ffffa0db4b170800 [7526.401839] R13: 00000003494b0000 R14: ffffa0db7c55b488 R15: ffffa0db8b19a000 [7526.402874] FS: 00007f6c99c40640(0000) GS:ffffa0de6d200000(0000) knlGS:0000000000000000 [7526.404038] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [7526.405040] CR2: 00007f31b0882160 CR3: 000000014b38c004 CR4: 0000000000370ee0 [7526.406112] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [7526.407148] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [7526.408169] Call Trace: [7526.408529] <TASK> [7526.408839] scrub_enumerate_chunks.cold+0x11/0x79 [btrfs] [7526.409690] ? do_wait_intr_irq+0xb0/0xb0 [7526.410276] btrfs_scrub_dev+0x226/0x620 [btrfs] [7526.410995] ? preempt_count_add+0x49/0xa0 [7526.411592] btrfs_ioctl+0x1ab5/0x36d0 [btrfs] [7526.412278] ? __fget_files+0xc9/0x1b0 [7526.412825] ? kvm_sched_clock_read+0x14/0x40 [7526.413459] ? lock_release+0x155/0x4a0 [7526.414022] ? __x64_sys_ioctl+0x83/0xb0 [7526.414601] __x64_sys_ioctl+0x83/0xb0 [7526.415150] do_syscall_64+0x3b/0xc0 [7526.415675] entry_SYSCALL_64_after_hwframe+0x44/0xae [7526.416408] RIP: 0033:0x7f6c99d34397 [7526.416931] Code: 3c 1c e8 1c ff (...) [7526.419641] RSP: 002b:00007f6c99c3fca8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [7526.420735] RAX: ffffffffffffffda RBX: 00005624e1e007b0 RCX: 00007f6c99d34397 [7526.421779] RDX: 00005624e1e007b0 RSI: 00000000c400941b RDI: 0000000000000003 [7526.422820] RBP: 0000000000000000 R08: 00007f6c99c40640 R09: 0000000000000000 [7526.423906] R10: 00007f6c99c40640 R11: 0000000000000246 R12: 00007fff746755de [7526.424924] R13: 00007fff746755df R14: 0000000000000000 R15: 00007f6c99c40640 [7526.425950] </TASK> That assertion is relatively new, introduced with commit d04fbe19aefd2 ("btrfs: scrub: cleanup the argument list of scrub_chunk()"). The block group we get at scrub_enumerate_chunks() can actually have a start address that is smaller then the chunk offset we extracted from a device extent item we got from the commit root of the device tree. This is very rare, but it can happen due to a race with block group removal and allocation. For example, the following steps show how this can happen: 1) We are at transaction T, and we have the following blocks groups, sorted by their logical start address: [ bg A, start address A, length 1G (data) ] [ bg B, start address B, length 1G (data) ] (...) [ bg W, start address W, length 1G (data) ] --> logical address space hole of 256M, there used to be a 256M metadata block group here [ bg Y, start address Y, length 256M (metadata) ] --> Y matches W's end offset + 256M Block group Y is the block group with the highest logical address in the whole filesystem; 2) Block group Y is deleted and its extent mapping is removed by the call to remove_extent_mapping() made from btrfs_remove_block_group(). So after this point, the last element of the mapping red black tree, its rightmost node, is the mapping for block group W; 3) While still at transaction T, a new data block group is allocated, with a length of 1G. When creating the block group we do a call to find_next_chunk(), which returns the logical start address for the new block group. This calls returns X, which corresponds to the end offset of the last block group, the rightmost node in the mapping red black tree (fs_info->mapping_tree), plus one. So we get a new block group that starts at logical address X and with a length of 1G. It spans over the whole logical range of the old block group Y, that was previously removed in the same transaction. However the device extent allocated to block group X is not the same device extent that was used by block group Y, and it also does not overlap that extent, which must be always the case because we allocate extents by searching through the commit root of the device tree (otherwise it could corrupt a filesystem after a power failure or an unclean shutdown in general), so the extent allocator is behaving as expected; 4) We have a task running scrub, currently at scrub_enumerate_chunks(). There it searches for device extent items in the device tree, using its commit root. It finds a device extent item that was used by block group Y, and it extracts the value Y from that item into the local variable 'chunk_offset', using btrfs_dev_extent_chunk_offset(); It then calls btrfs_lookup_block_group() to find block group for the logical address Y - since there's currently no block group that starts at that logical address, it returns block group X, because its range contains Y. This results in triggering the assertion: ASSERT(cache->start == chunk_offset); right before calling scrub_chunk(), as cache->start is X and chunk_offset is Y. This is more likely to happen of filesystems not larger than 50G, because for these filesystems we use a 256M size for metadata block groups and a 1G size for data block groups, while for filesystems larger than 50G, we use a 1G size for both data and metadata block groups (except for zoned filesystems). It could also happen on any filesystem size due to the fact that system block groups are always smaller (32M) than both data and metadata block groups, but these are not frequently deleted, so much less likely to trigger the race. So make scrub skip any block group with a start offset that is less than the value we expect, as that means it's a new block group that was created in the current transaction. It's pointless to continue and try to scrub its extents, because scrub searches for extents using the commit root, so it won't find any. For a device replace, skip it as well for the same reasons, and we don't need to worry about the possibility of extents of the new block group not being to the new device, because we have the write duplication setup done through btrfs_map_block(). Fixes: d04fbe19aefd ("btrfs: scrub: cleanup the argument list of scrub_chunk()") CC: stable@vger.kernel.org # 5.17 Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
2022-04-21drm/i915: Check EDID for HDR static metadata when choosing blcJouni Högander1-8/+26
We have now seen panel (XMG Core 15 e21 laptop) advertizing support for Intel proprietary eDP backlight control via DPCD registers, but actually working only with legacy pwm control. This patch adds panel EDID check for possible HDR static metadata and Intel proprietary eDP backlight control is used only if that exists. Missing HDR static metadata is ignored if user specifically asks for Intel proprietary eDP backlight control via enable_dpcd_backlight parameter. v2 : - Ignore missing HDR static metadata if Intel proprietary eDP backlight control is forced via i915.enable_dpcd_backlight - Printout info message if panel is missing HDR static metadata and support for Intel proprietary eDP backlight control is detected Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5284 Cc: Lyude Paul <lyude@redhat.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Filippo Falezza <filippo.falezza@outlook.it> Cc: stable@vger.kernel.org Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220413082826.120634-1-jouni.hogander@intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
2022-04-21ASoC: meson: Fix event generation for G12A tohdmi muxMark Brown1-1/+1
The G12A tohdmi has a custom put() operation which returns 0 when the value of the mux changes, meaning that events are not generated for userspace. Change to return 1 in this case, the function returns early in the case where there is no change. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20220421123803.292063-4-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2022-04-21ASoC: meson: Fix event generation for AUI CODEC muxMark Brown1-1/+1
The AIU CODEC has a custom put() operation which returns 0 when the value of the mux changes, meaning that events are not generated for userspace. Change to return 1 in this case, the function returns early in the case where there is no change. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20220421123803.292063-3-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2022-04-21ASoC: meson: Fix event generation for AUI ACODEC muxMark Brown1-1/+1
The AIU ACODEC has a custom put() operation which returns 0 when the value of the mux changes, meaning that events are not generated for userspace. Change to return 1 in this case, the function returns early in the case where there is no change. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://lore.kernel.org/r/20220421123803.292063-2-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2022-04-21powerpc/perf: Fix 32bit compileAlexey Kardashevskiy1-2/+2
The "read_bhrb" global symbol is only called under CONFIG_PPC64 of arch/powerpc/perf/core-book3s.c but it is compiled for both 32 and 64 bit anyway (and LLVM fails to link this on 32bit). This fixes it by moving bhrb.o to obj64 targets. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220421025756.571995-1-aik@ozlabs.ru
2022-04-21powerpc/perf: Fix power10 event alternativesAthira Rajeev1-1/+1
When scheduling a group of events, there are constraint checks done to make sure all events can go in a group. Example, one of the criteria is that events in a group cannot use the same PMC. But platform specific PMU supports alternative event for some of the event codes. During perf_event_open(), if any event group doesn't match constraint check criteria, further lookup is done to find alternative event. By current design, the array of alternatives events in PMU code is expected to be sorted by column 0. This is because in find_alternative() the return criteria is based on event code comparison. ie. "event < ev_alt[i][0])". This optimisation is there since find_alternative() can be called multiple times. In power10 PMU code, the alternative event array is not sorted properly and hence there is breakage in finding alternative event. To work with existing logic, fix the alternative event array to be sorted by column 0 for power10-pmu.c Results: In case where an alternative event is not chosen when we could, events will be multiplexed. ie, time sliced where it could actually run concurrently. Example, in power10 PM_INST_CMPL_ALT(0x00002) has alternative event, PM_INST_CMPL(0x500fa). Without the fix, if a group of events with PMC1 to PMC4 is used along with PM_INST_CMPL_ALT, it will be time sliced since all programmable PMC's are consumed already. But with the fix, when it picks alternative event on PMC5, all events will run concurrently. Before: # perf stat -e r00002,r100fc,r200fa,r300fc,r400fc Performance counter stats for 'system wide': 328668935 r00002 (79.94%) 56501024 r100fc (79.95%) 49564238 r200fa (79.95%) 376 r300fc (80.19%) 660 r400fc (79.97%) 4.039150522 seconds time elapsed With the fix, since alternative event is chosen to run on PMC6, events will be run concurrently. After: # perf stat -e r00002,r100fc,r200fa,r300fc,r400fc Performance counter stats for 'system wide': 23596607 r00002 4907738 r100fc 2283608 r200fa 135 r300fc 248 r400fc 1.664671390 seconds time elapsed Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support") Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220419114828.89843-2-atrajeev@linux.vnet.ibm.com
2022-04-21powerpc/perf: Fix power9 event alternativesAthira Rajeev1-4/+4
When scheduling a group of events, there are constraint checks done to make sure all events can go in a group. Example, one of the criteria is that events in a group cannot use the same PMC. But platform specific PMU supports alternative event for some of the event codes. During perf_event_open(), if any event group doesn't match constraint check criteria, further lookup is done to find alternative event. By current design, the array of alternatives events in PMU code is expected to be sorted by column 0. This is because in find_alternative() the return criteria is based on event code comparison. ie. "event < ev_alt[i][0])". This optimisation is there since find_alternative() can be called multiple times. In power9 PMU code, the alternative event array is not sorted properly and hence there is breakage in finding alternative events. To work with existing logic, fix the alternative event array to be sorted by column 0 for power9-pmu.c Results: With alternative events, multiplexing can be avoided. That is, for example, in power9 PM_LD_MISS_L1 (0x3e054) has alternative event, PM_LD_MISS_L1_ALT (0x400f0). This is an identical event which can be programmed in a different PMC. Before: # perf stat -e r3e054,r300fc Performance counter stats for 'system wide': 1057860 r3e054 (50.21%) 379 r300fc (49.79%) 0.944329741 seconds time elapsed Since both the events are using PMC3 in this case, they are multiplexed here. After: # perf stat -e r3e054,r300fc Performance counter stats for 'system wide': 1006948 r3e054 182 r300fc Fixes: 91e0bd1e6251 ("powerpc/perf: Add PM_LD_MISS_L1 and PM_BR_2PATH to power9 event list") Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220419114828.89843-1-atrajeev@linux.vnet.ibm.com
2022-04-21regulator: core: Sleep (not delay) in set_voltage()Brian Norris1-6/+1
These delays can be relatively large (e.g., hundreds of microseconds to several milliseconds on RK3399 Gru systems). Per Documentation/timers/timers-howto.rst, that should usually use a sleeping delay. Let's use the existing regulator delay helper to handle both large and small delays appropriately. This avoids burning a bunch of CPU time and hurting scheduling latencies when hitting regulators a lot (e.g., during cpufreq). The sleep vs. delay issue choice has been made differently over time -- early versions of RK3399 Gru PWM-regulator support used usleep_range() in pwm-regulator.c. More of this got moved into the regulator core, in commits like: 73e705bf81ce regulator: core: Add set_voltage_time op At the same time, the sleep turned into a delay. It's OK to sleep in _regulator_do_set_voltage(), as we aren't in an atomic context. (All our callers grab various mutexes already.) I avoid using fsleep() because it uses a usleep_range() of [N to N*2], and usleep_range() very commonly biases to the high end of the range. We don't want to double the expected delay, especially for long delays. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20220420141511.v2.2.If0fc61a894f537b052ca41572aff098cf8e7e673@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-21regulator: core: Rename _regulator_enable_delay()Brian Norris1-8/+8
I want to use it in other contexts besides _regulator_do_enable(). Signed-off-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20220420141511.v2.1.I31ef0014c9597d53722ab513890f839f357fdfb3@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-21regulator: da9121: Fix uninit-value in da9121_assign_chip_model()Wei Yongjun1-0/+2
KASAN report slab-out-of-bounds in __regmap_init as follows: BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841 Read of size 1 at addr ffff88803678cdf1 by task xrun/9137 CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88 print_report.cold+0xcd/0x69b mm/kasan/report.c:313 kasan_report+0x8e/0xc0 mm/kasan/report.c:491 __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841 __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266 __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394 da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039 i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563 This happend when da9121 device is probe by da9121_i2c_id, but with invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later da9121_assign_chip_model() will access 'regmap' without init it. Fix it by return -EINVAL from da9121_assign_chip_model() if 'chip->subvariant_id' is invalid. Fixes: f3fbd5566f6a ("regulator: da9121: Add device variants") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Adam Ward <Adam.Ward.Opensource@diasemi.com> Link: https://lore.kernel.org/r/20220421090335.1876149-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-21spi: spi-mem: check if data buffers are on stackPratyush Yadav1-0/+10
The buffers passed in the data phase must be DMA-able. Programmers often don't realise this requirement and pass in buffers that reside on the stack. This can be hard to spot when reviewing code. Reject ops if their data buffer is on the stack to avoid this. Signed-off-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/20220420102022.3310970-1-p.yadav@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-21ARM: s3c: mark as deprecated and schedule removalKrzysztof Kozlowski6-3/+29
The Samsung S3C24xx and S3C64xx platforms are very old designs. S3C2416 was introduced in 2008 and S3C6410 in 2009/2010. They are not widely available anymore - out-of-stock on FriendlyArm (one of manufacturers of boards) and only few specialist stores still offer them for quite a high price. The community around these platforms was not very active, so I suspect no one really uses them anymore. Maintenance takes precious time so there is little sense in keeping them alive if there are no real users. Let's mark all S3C24xx and S3C64xx platforms as deprecated and mention possible removal in after 2022 for the first and 2024 for the lattere. The deprecation message will be as text in Kconfig, build message (not a warning though) and runtime print error. If there are any users, they might respond and postpone the removal. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Tomasz Figa <tomasz.figa@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20220407072319.75614-1-krzysztof.kozlowski@linaro.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21ARM: omap: dma: make usb support optionalArnd Bergmann3-25/+27
Most of the plat-omap/dma.c code is specific to the USB driver. Hide that code when it is not in use, to make it clearer which parts are actually still required. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21ARM: omap: remove debug-leds driverArnd Bergmann3-185/+0
It has been impossible to select this driver for six years without anyone noticing, so just kill it completely. Fixes: 54ea18e8866a ("ARM: OMAP2+: Remove board file for H4") Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21ARM: omap1: move 32k counter from plat-omap to mach-omap1Arnd Bergmann6-136/+110
omap2 stopped using this code with commit 8d39ff3d1696 ("ARM: OMAP2+: Remove unused legacy code for timer"), so just move it to mach-omap1 now, along with the other half of that driver. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21ARM: omap1: innovator: move ohci phy power handling to board fileArnd Bergmann3-26/+26
The innovator board needs a special case for its phy control. Move the corresponding code into the board file and out of the common code by adding another callback. Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21input: omap: void using mach/*.h headersArnd Bergmann1-0/+1
The omap-keypad driver currently relies on including mach/memory.h implicitly, but that won't happen once omap1 is converted to CONFIG_ARCH_MULTIPLATFORM. Include the required header explicitly. Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21serial: 8250/omap1: include linux/soc/ti/omap1-soc.hArnd Bergmann1-0/+1
As a preparation for cleaning up the omap1 headers, start including linux/soc/ti/omap1-soc.h directly so we can keep calling cpu_is_omap1510(). Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21clocksource: ti-dmtimer: avoid using mach/hardware.hArnd Bergmann1-1/+1
As a preparation for future omap1 multiplatform support, stop using mach/hardware.h and instead include the omap1-io.h for low-level register access to MOD_CONF_CTRL_1. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21usb: omap: avoid mach/*.h headersArnd Bergmann6-9/+11
The omap usb drivers still rely on mach/*.h headers that are explicitly or implicitly included, but all the required definitions are now in include/linux/soc/ti/, so use those instead and allow compile-testing on other architectures. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21fbdev: omap: avoid using mach/*.h filesArnd Bergmann10-13/+16
All the headers we actually need are now in include/linux/soc, so use those versions instead and allow compile-testing on other architectures. Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21ARM: omap1: move CF chipselect setup to board fileArnd Bergmann3-37/+42
There is only one board that uses the omap_cf driver, so moving the chipselect configuration there does not lead to code duplication but avoids the use of mach/tc.h in drivers. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21ARM: omap1: move perseus spi pinconf to board fileArnd Bergmann3-13/+10
The driver has always had a FIXME about this, and it seems like this trivial code move avoids a mach header inclusion, so just do it. With that out of the way, and the header file inclusions changed to global files, the driver can also be compile-tested on other platforms. Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-21ARM: omap1: move some headers to include/linux/socArnd Bergmann9-449/+467
There are three remaining header files that are used by omap1 specific device drivers: - mach/soc.h provides cpu_is_omapXXX abstractions - mach/hardware.h provides omap_read/omap_write functions and physical addresses - mach/mux.h provides an omap specific pinctrl abstraction This is generally not how we do platform abstractions today, and it would be good to completely get rid of these in favor of passing information through platform devices and the pinctrl subsystem. However, given that nobody is working on that, just move it one step forward by splitting out the header files that are used by drivers today from the machine headers that are only used internally. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.