summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-02-12Merge tag 'vfs-6.8-rc5.fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: - Fix performance regression introduced by moving the security permission hook out of do_clone_file_range() and into its caller vfs_clone_file_range(). This causes the security hook to be called in situation were it wasn't called before as the fast permission checks were left in do_clone_file_range(). Fix this by merging the two implementations back together and restoring the old ordering: fast permission checks first, expensive ones later. - Tweak mount_setattr() permission checking so that mount properties on the real rootfs can be changed. When we added mount_setattr() we added additional checks compared to legacy mount(2). If the mount had a parent then verify that the caller and the mount namespace the mount is attached to match and if not make sure that it's an anonymous mount. But the real rootfs falls into neither category. It is neither an anoymous mount because it is obviously attached to the initial mount namespace but it also obviously doesn't have a parent mount. So that means legacy mount(2) allows changing mount properties on the real rootfs but mount_setattr(2) blocks this. This causes regressions (See the commit for details). Fix this by relaxing the check. If the mount has a parent or if it isn't a detached mount, verify that the mount namespaces of the caller and the mount are the same. Technically, we could probably write this even simpler and check that the mount namespaces match if it isn't a detached mount. But the slightly longer check makes it clearer what conditions one needs to think about. * tag 'vfs-6.8-rc5.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: fs: relax mount_setattr() permission checks remap_range: merge do_clone_file_range() into vfs_clone_file_range()
2024-02-12nouveau/svm: fix kvcalloc() argument orderArnd Bergmann
The conversion to kvcalloc() mixed up the object size and count arguments, causing a warning: drivers/gpu/drm/nouveau/nouveau_svm.c: In function 'nouveau_svm_fault_buffer_ctor': drivers/gpu/drm/nouveau/nouveau_svm.c:1010:40: error: 'kvcalloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] 1010 | buffer->fault = kvcalloc(sizeof(*buffer->fault), buffer->entries, GFP_KERNEL); | ^ drivers/gpu/drm/nouveau/nouveau_svm.c:1010:40: note: earlier argument should specify number of elements, later size of each element The behavior is still correct aside from the warning, but fixing it avoids the warnings and can help the compiler track the individual objects better. Fixes: 71e4bbca070e ("nouveau/svm: Use kvcalloc() instead of kvzalloc()") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212112230.1117284-1-arnd@kernel.org
2024-02-12regmap: kunit: Ensure that changed bytes are actually differentMark Brown
During the cache sync test we verify that values we expect to have been written only to the cache do not appear in the hardware. This works most of the time but since we randomly generate both the original and new values there is a low probability that these values may actually be the same. Wrap get_random_bytes() to ensure that the values are different, there are other tests which should have similar verification that we actually changed something. While we're at it refactor the test to use three changed values rather than attempting to use one of them twice, that just complicates checking that our new values are actually new. We use random generation to try to avoid data dependencies in the tests. Reported-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://msgid.link/r/20240211-regmap-kunit-random-change-v3-1-e387a9ea4468@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-12spi: intel-pci: Add support for Lunar Lake-M SPI serial flashMika Westerberg
Add Intel Lunar Lake-M PCI ID to the driver list of supported devices. This is the same controller found in previous generations. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://msgid.link/r/20240212082027.2462849-1-mika.westerberg@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-12spi: omap2-mcspi: Revert FIFO support without DMAVaishnav Achath
MCSPI controller have few limitations regarding the transaction size when the FIFO buffer is enabled and the WCNT feature is used to find the end of word, in this case if WCNT is not a multiple of the FIFO Almost Empty Level (AEL), then the FIFO empty event is not generated correctly. In addition to this limitation, few other unknown sequence of events that causes the FIFO empty status to not reflect the exact status were found when FIFO is being used without DMA enabled during extended testing in AM65x platform. Till the exact root cause is found and fixed, revert the FIFO support without DMA. See J721E Technical Reference Manual (SPRUI1C), section 12.1.5 for further details: http://www.ti.com/lit/pdf/spruil1 This reverts commit 75223bbea840e ("spi: omap2-mcspi: Add FIFO support without DMA") Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com> Link: https://msgid.link/r/20240212120049.438495-1-vaishnav.a@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-12ASoC: rt5645: Add DMI quirk for inverted jack-detect on MeeGoPad T8Hans de Goede
The MeeGoPad T8 uses the standard rt5645 jd_mode=3 setting for jack-detect, but the used jack connector outputs an inverted jack-detect signal. Add a DMI quirk for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://msgid.link/r/20240211212736.179605-2-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-12ASoC: rt5645: Make LattePanda board DMI match more preciseHans de Goede
The DMI strings used for the LattePanda board DMI quirks are very generic. Using the dmidecode database from https://linux-hardware.org/ shows that the chosen DMI strings also match the following 2 laptops which also have a rt5645 codec: Insignia NS-P11W7100 https://linux-hardware.org/?computer=E092FFF8BA04 Insignia NS-P10W8100 https://linux-hardware.org/?computer=AFB6C0BF7934 All 4 hw revisions of the LattePanda board have "S70CR" in their BIOS version DMI strings: DF-BI-7-S70CR100-* DF-BI-7-S70CR110-* DF-BI-7-S70CR200-* LP-BS-7-S70CR700-* See e.g. https://linux-hardware.org/?computer=D98250A817C0 Add a partial (non exact) DMI match on this string to make the LattePanda board DMI match more precise to avoid false-positive matches. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://msgid.link/r/20240211212736.179605-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-12arm64: dts: fsd: Add fifosize for UART in Device TreeTamseel Shams
UART in FSD SoC has fifosize of 64 bytes. Set fifosize as 64 bytes for UART from Device Tree. Signed-off-by: Tamseel Shams <m.shams@samsung.com> Link: https://lore.kernel.org/r/20240205082625.39259-1-m.shams@samsung.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-02-12arm64: dts: exynos: gs101: minor whitespace cleanupKrzysztof Kozlowski
The DTS code coding style expects exactly one space before '{' and around '=' characters. Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20240208105243.128875-1-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2024-02-12arm64: dts: mediatek: mt7622: add missing "device_type" to memory nodesRafał Miłecki
This fixes: arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: /: memory@40000000: 'device_type' is a required property from schema $id: http://devicetree.org/schemas/memory.yaml# arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dtb: /: memory@40000000: 'device_type' is a required property from schema $id: http://devicetree.org/schemas/memory.yaml# Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240122132357.31264-1-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: reorder nodesRafał Miłecki
Use order described as preferred in DTS Coding Style: 1. Sort bus nodes by unit address 2. Use alpha-numerical order for the rest Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240212121620.15035-2-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: reorder propertiesRafał Miłecki
Use order described as preferred in DTS Coding Style. Mostly just move "compatible", "reg" and "ranges" properties. In two nodes also move vendor-prefixed props down. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240212121620.15035-1-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add Acelink EW-7886CAXRafał Miłecki
Acelink EW-7886CAX is an MT7986A (AKA Filogic 830) based access point. It has 512 MiB of RAM, one 2.5 Gbps PoE (802.3at) Ethernet port and on-SoC Wi-Fi. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231207080512.3688-3-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: arm64: dts: mediatek: Add Acelink EW-7886CAX access pointRafał Miłecki
Acelink EW-7886CAX is an MT7986A (AKA Filogic 830) based access point. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231207080512.3688-2-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: vendor-prefixes: add acelinkRafał Miłecki
Acelink is a Taiwan company providing network products (routers, access points, switches, cameras and more). Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231207080512.3688-1-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Introduce the MT8395 Radxa NIO 12L boardAngeloGioacchino Del Regno
Add a device tree for the Radxa NIO 12L SBC, powered by the MediaTek MT8395 Genio 1200 SoC. This board features: * MT6359 + MT6360 PMICs at I2C-6 - Regulators, battery charger, TypeC Port Controller Interface - Audio through 3.5mm jack (2CH out, 1CH in) * Two MT6315 PMICs over SPMI - CPU-Big and GPU Core regulators * Network Connectivity - Realtek RTL8211FD MDIO PHY/Transceiver, 10/100/1000M Ethernet - MT7921E WiFi (PCIe1) / Bluetooth (USB 2.0) combo chip * Storage - On-board UFS storage - On-board eMMC on MMC0 controller - MicroSD card slot on MMC1 controller * Other connectivity - 1x USB Type-C Charging/Power only port - 1x USB 3.2 SuperSpeed Type-C OTG+DisplayPort mode - Muxed by ITE IT5205 Alternate Mode Passive MUX - 4x USB 3.0 Type-A ports on VL805 USB Hub (PCIe0) - 1x HDMI IN port - 1x HDMI OUT port - 1x MIPI DSI (Display) port - 2x MIPI CSI (Camera) ports * 40-pin Expansion Header - Two UART ports - I2C, SPI busses - I2S for external audio chips - ADC - GPIOs Link: https://lore.kernel.org/r/20240202114821.79227-3-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: arm64: mediatek: Add MT8395 Radxa NIO 12L board compatibleAngeloGioacchino Del Regno
Add a board compatible for the Radxa NIO 12L, based on the MediaTek MT8395 SoC. Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240202114821.79227-2-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8186: Add video decoder device nodesYunfei Dong
Add mt8186 video decoder device nodes. Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> [eugen.hristev@collabora.com: minor cleanup] Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Link: https://lore.kernel.org/r/20231220133302.39411-1-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8195: Add MTU3 nodes and correctly describe USBAngeloGioacchino Del Regno
The MT8195 SoC has four USB controllers: only one is a direct path to a XHCI controller, while the other three (0, 2 and 3) are behind the MTU3 DRD controller instead! Add the missing MTU3 nodes, default disabled, for controllers 0, 2 and 3 and move the related XHCI nodes to be children of their MTU3 DRD to correctly describe the SoC. In order to retain USB functionality on all of the MT8195 and MT8395 boards, also move the vusb33 supply and enable the relevant MTU3 nodes with special attention to the MT8195 Cherry Chromebook, where it was necessary to set the dr_mode of all MTU3 controllers to host to avoid interfering with the EC performing DRD on its own. Tested-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://lore.kernel.org/r/20240115084336.938426-1-angelogioacchino.delregno@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add MT8186 Magneton ChromebooksChen-Yu Tsai
Add entries for the MT8186 based Chromebooks, also collectively known as the Lenovo IdeaPad Slim 3 Chromebook (14M868). It is also based on the "Steelix" design. Being a laptop instead of a convertible device, there is no stylus, which is similar to Rusty. However Magneton does not have ports on the right side of the device. Three variants are listed separately. These use different touchscreen controllers, or lack a touchscreen altogether. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-10-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add MT8186 Steelix platform based RustyChen-Yu Tsai
MT8186 Rusty, otherwise known as the Lenovo 100e Chromebook Gen 4, is an MT8186 based laptop. It is based on the "Steelix" design. Being a laptop instead of a convertible device, there is no touchscreen or stylus. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-9-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Introduce MT8186 SteelixChen-Yu Tsai
The MT8186 Steelix, also known as the Lenovo 300e Yoga Chromebook Gen 4, is a convertible device based on a common design of the same name. The device comes in different variants. Of them, whether a world facing camera is integrated is the only differentiating factor between the two device trees added. The different SKU IDs describe this alone. The other device difference is the trackpad component used. This is simply handled by having both possible components described in the device tree, and letting the implementation figure out which one is actually available. The system bootloader / firmware does not differentiate this in that they share the same SKU IDs. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-8-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add MT8186 Krabby platform based Tentacruel / TentacoolChen-Yu Tsai
Tentacruel and Tentacool are MT8186 based Chromebooks based on the Krabby design. Tentacruel, also known as the ASUS Chromebook CM14 Flip CM1402F, is a convertible device with touchscreen and stylus. Tentacool, also known as the ASUS Chromebook CM14 CM1402C, is a laptop device. It does not have a touchscreen or stylus. The two devices both have two variants. The difference is a second source trackpad controller that shares the same address as the original, but is incompatible. The extra SKU IDs for the Tentacruel devices map to different sensor components attached to the Embedded Controller. These are not visible to the main processor. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-7-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: arm: mediatek: Add MT8186 Magneton ChromebooksChen-Yu Tsai
Add entries for the MT8186 based Chromebooks, also collectively known as the Lenovo IdeaPad Slim 3 Chromebook (14M868). It is also based on the "Steelix" design. Being a laptop instead of a convertible device, there is no touchscreen or stylus, which is similar to Rusty. However Magneton does not have ports on the right side of the device. Three variants are listed separately. These use different touchscreen controllers, or lack a touchscreen altogether. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-6-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: arm: mediatek: Add MT8186 Rusty ChromebookChen-Yu Tsai
Add an entry for the MT8186 based Rusty Chromebook, also known as the Lenovo 100e Chromebook Gen 4. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-5-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: arm: mediatek: Add MT8186 Steelix ChromebookChen-Yu Tsai
Add an entry for the MT8186 based Steelix Chromebook, also known as the Lenovo 300e Yoga Chromebook Gen 4. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-4-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: arm: mediatek: Add MT8186 Tentacruel / Tentacool ChromebooksChen-Yu Tsai
Add entries for MT8186 based Tentacruel / Tentacool Chromebooks. The two are based on the same board design: the former is a convertible device with a touchscreen, stylus, and some extra buttons; the latter is a clamshell device and lacks these additional features. The two devices both have two variants. The difference is a second source trackpad controller that shares the same address as the original, but is incompatible. The extra SKU IDs for the Tentacruel devices map to different sensor components attached to the Embedded Controller. These are not visible to the main processor. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-3-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: arm: mediatek: Sort entries by SoC then board compatiblesChen-Yu Tsai
Some of the new MediaTek board entries were inserted in a chronological order, or just randomly. This makes it harder to search for an entry. Sort the entries by first grouping by SoC, then sorting by board compatible strings. Also add a comment at the top asking people to do the same. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240126083802.2728610-2-wenst@chromium.org Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8186: Add jpgenc nodeAllen-KH Cheng
Add JPEG encoder node. Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by: Max Staudt <mstaudt@chromium.org> Tested-by: Max Staudt <mstaudt@chromium.org> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org> [eugen.hristev@collabora.com: minor cleanup] Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240127084258.68302-2-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: media: mediatek-jpeg-encoder: change max iommus countEugen Hristev
MT8186 has 4 iommus in the list, to cope with this situation, adjust the maxItems to 4 (instead of previous 2). Add also minItems as 2 to keep compatibility with current devices. Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240127084258.68302-1-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8186: Add venc nodeKyrie Wu
Add video encoder node. Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com> Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> [eugen.hristev@collabora.com: minor cleanup] Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231228113245.174706-7-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8186: fix VENC power domain clocksEugen Hristev
The larb clock is in fact a subsys clock, so it must be prefixed by 'subsys-' to be correctly identified in the driver. Fixes: d9e43c1e7a38 ("arm64: dts: mt8186: Add power domains controller") Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231228113245.174706-6-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: media: mtk-vcodec-encoder: add compatible for mt8186Eugen Hristev
Add compatible for the mt8186 encoder which currently works in the same way as mt8183. Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231228113245.174706-5-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8192: fix vencoder clock nameEugen Hristev
Clock name should be `venc_sel` as per binding. Fix the warning message : arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dtb: vcodec@17020000: clock-names:0: 'venc_sel' was expected from schema $id: http://devicetree.org/schemas/media/mediatek,vcodec-encoder.yaml# Fixes: aa8f3711fc87 ("arm64: dts: mt8192: Add H264 venc device node") Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231228113245.174706-4-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: media: mtk-vcodec-encoder: fix non-vp8 clock nameEugen Hristev
Looking at the binding it makes sense that the `-vp8` compatible has the `venc_lt_sel` while the other bindings have the `venc_sel` as name for the clock. This was also mentioned in the txt version of the binding before the conversion: ` clock-names: avc encoder must contain "venc_sel", vp8 encoder must contain "venc_lt_sel", decoder must contain "vcodecpll", "univpll_d2", ` So it is easier to check for compatible that includes vp8, since that's just one, to have the requirement for the clock name property as `venc_lt_sel`, rather than for all the others, some of which are missing, thus for them, the requirement is wrongly `venc_lt_sel`. Reordered the if/then/else to match `-vp8` and have all the rest of the compatibles using the other clock name (`venc_sel`). Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231228113245.174706-3-eugen.hristev@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add socinfo efuses to MT8173/83/96/92/95 SoCsWilliam-tw Lin
Add efuse nodes for socinfo retrieval for MT8173, MT8183, MT8186, MT8192 and MT8195. Signed-off-by: William-tw Lin <william-tw.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231222080739.21706-2-william-tw.lin@mediatek.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8195: Enable cros-ec-spi as wake sourceMark Hasemeyer
The cros_ec driver currently assumes that cros-ec-spi compatible device nodes are a wakeup-source even though the wakeup-source property is not defined. Some Chromebooks use a separate wake pin, while others overload the interrupt for wake and IO. With the current assumption, spurious wakes can occur on systems that use a separate wake pin. It is planned to update the driver to no longer assume that the EC interrupt pin should be enabled for wake. Add the wakeup-source property to all cros-ec-spi compatible device nodes to signify to the driver that they should still be a valid wakeup source. Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240102140734.v4.12.Iee33a7f1f991408cef372744199026f936bf54e2@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8192: Enable cros-ec-spi as wake sourceMark Hasemeyer
The cros_ec driver currently assumes that cros-ec-spi compatible device nodes are a wakeup-source even though the wakeup-source property is not defined. Some Chromebooks use a separate wake pin, while others overload the interrupt for wake and IO. With the current assumption, spurious wakes can occur on systems that use a separate wake pin. It is planned to update the driver to no longer assume that the EC interrupt pin should be enabled for wake. Add the wakeup-source property to all cros-ec-spi compatible device nodes to signify to the driver that they should still be a valid wakeup source. Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240102140734.v4.11.Ibd330d26a00f5e219a7e448452769124833a9762@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8183: Enable cros-ec-spi as wake sourceMark Hasemeyer
The cros_ec driver currently assumes that cros-ec-spi compatible device nodes are a wakeup-source even though the wakeup-source property is not defined. Some Chromebooks use a separate wake pin, while others overload the interrupt for wake and IO. With the current assumption, spurious wakes can occur on systems that use a separate wake pin. It is planned to update the driver to no longer assume that the EC interrupt pin should be enabled for wake. Add the wakeup-source property to all cros-ec-spi compatible device nodes to signify to the driver that they should still be a valid wakeup source. Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240102140734.v4.10.Iba4a8b7e908989e57f7838a80013a4062be5e614@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8173: Enable cros-ec-spi as wake sourceMark Hasemeyer
The cros_ec driver currently assumes that cros-ec-spi compatible device nodes are a wakeup-source even though the wakeup-source property is not defined. Some Chromebooks use a separate wake pin, while others overload the interrupt for wake and IO. With the current assumption, spurious wakes can occur on systems that use a separate wake pin. It is planned to update the driver to no longer assume that the EC interrupt pin should be enabled for wake. Add the wakeup-source property to all cros-ec-spi compatible device nodes to signify to the driver that they should still be a valid wakeup source. Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240102140734.v4.9.Ic09ebe116c18e83cc1161f4bb073fea8043f03f3@changeid Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7988: add clock controllersRafał Miłecki
Add bindings of on-SoC clocks. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/20240108085228.4727-4-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add initial MT7988A and BPI-R4Rafał Miłecki
MT7988A (AKA MediaTek Filogic 880) is a quad-core ARM Cortex-A73 platform designed for Wi-Fi 7 devices (there is no wireless on SoC though). The first public MT7988A device is Banana Pi BPI-R4. Many SoC parts remain to be added (they need their own bindings or depend on missing clocks). Those present block however are correct and having base .dtsi will help testing & working on missing stuff. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240108085228.4727-3-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: arm64: mediatek: Add MT7988A and BPI-R4Rafał Miłecki
MT7988A is another MediaTek's SoC with just 1 device available right now: Banana Pi BPI-R4. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240108085228.4727-2-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: Add initial MT7981B and Xiaomi AX3000TRafał Miłecki
MT7981B (AKA MediaTek Filogic 820) is a dual-core ARM Cortex-A53 SoC. One of market devices using this SoC is Xiaomi AX3000T. This is initial contribution with basic SoC support. More hardware block will get added later. Some will need their bindings (like auxadc). Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240111103928.721-3-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12dt-bindings: arm64: mediatek: Add MT7981B and Xiaomi AX3000TRafał Miłecki
MT7981B (AKA Filogic 820) is MediaTek's dual-core ARM Cortex-A53 SoC. One of market devices using this SoC is Xiaomi AX3000T. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240111103928.721-2-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt8192-asurada: Remove CrosEC base detection nodeNícolas F. R. A. Prado
The commit adding the ChromeOS EC to the Asurada Devicetree mistakenly added a base detection node. While tablet mode detection is supported by CrosEC and used by Hayato, it is done through the cros-ec-keyb driver. The base detection node, which is handled by the hid-google-hammer driver, also provides tablet mode detection but by checking base attachment status on the CrosEC, which is not supported for Asurada. Hence, remove the unused CrosEC base detection node for Asurada. Fixes: eb188a2aaa82 ("arm64: dts: mediatek: asurada: Add ChromeOS EC") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Link: https://lore.kernel.org/r/20240207-mt8192-asurada-cbas-remove-v1-1-04cb65951975@collabora.com Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: add "#reset-cells" to infracfgRafał Miłecki
MT7986's Infrastructure System Configuration Controller includes reset controller. It can reset blocks as specified in the include/dt-bindings/reset/mt7986-resets.h . Add #reset-cells so it can be referenced properly. This fixes: arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: infracfg@10001000: '#reset-cells' is a required property from schema $id: http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml# Fixes: 1f9986b258c2 ("arm64: dts: mediatek: add clock support for mt7986a") Cc: Sam Shih <sam.shih@mediatek.com> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240101182040.28538-2-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: drop "#clock-cells" from PWMRafał Miłecki
PWM is not a clock provider and its binding doesn't specify "#clock-cells" property. This fixes: arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: pwm@10048000: '#clock-cells' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/pwm/mediatek,mt2712-pwm.yaml# Fixes: eabb04df46c6 ("arm64: dts: mt7986: add PWM") Cc: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Link: https://lore.kernel.org/r/20240101182040.28538-1-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: fix SPI nodenameRafał Miłecki
This fixes following validation errors: arch/arm64/boot/dts/mediatek/mt7986a-rfb.dtb: spi_nand@0: $nodename:0: 'spi_nand@0' does not match '^(flash|.*sram|nand)(@.*)?$' from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# arch/arm64/boot/dts/mediatek/mt7986b-rfb.dtb: spi_nand@0: $nodename:0: 'spi_nand@0' does not match '^(flash|.*sram|nand)(@.*)?$' from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# Fixes: 885e153ed7c1 ("arm64: dts: mt7986: add spi related device nodes") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231116130952.5099-2-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2024-02-12arm64: dts: mediatek: mt7986: fix SPI bus width propertiesRafał Miłecki
This fixes SPI setup and resolves following validation errors: arch/arm64/boot/dts/mediatek/mt7986a-rfb.dtb: spi_nand@0: Unevaluated properties are not allowed ('spi-rx-buswidth', 'spi-tx-buswidth' were unexpected) from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# arch/arm64/boot/dts/mediatek/mt7986b-rfb.dtb: spi_nand@0: Unevaluated properties are not allowed ('spi-rx-buswidth', 'spi-tx-buswidth' were unexpected) from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# Fixes: 885e153ed7c1 ("arm64: dts: mt7986: add spi related device nodes") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20231116130952.5099-1-zajec5@gmail.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
generated by cgit (git 2.34.1) at 2025-09-15 23:52:38 +0000