aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-06-17pinctrl: ralink: mt76x8: fix pinmux functionWeihao Li1-61/+27
The current version of the pinctrl driver has some issues: 1. Duplicated "gpio" pmx function The common code will add a "gpio" pmx functon to every pin group, so it's not necessary to define a separate "gpio" pmx function in pin groups. 2. Duplicated pmx function name There are some same function name in different pin groups, which will cause some problems. For example, when we want to use PAD_GPIO0 as refclk output function, the common clk framework code will search the entire pin function lists, then return the first one matched, in this case the matched function list only include the PAD_CO_CLKO pin group because there are three "refclk" pin function, which is added by refclk_grp, spi_cs1_grp and gpio_grp. To solve this problem, a simple way is just add a pingrp refix to function name like mt7620 pinctrl driver does. 3. Useless "-" or "rsvd" functon It's really unnecessary to add a reserved pin mux function to the function lists, because we never use it. Signed-off-by: Weihao Li <[email protected]> Link: https://lore.kernel.org/r/20240527022036.31985-1-user@blabla Signed-off-by: Linus Walleij <[email protected]>
2024-06-17pinctrl: pinctrl-tps6594: make tps65224_muxval_remap and ↵Nirmala Devi Mal Nadar1-2/+2
tps6594_muxval_remap as static to fix sparse warning pinctrl: tps6594: Fix sparse warning. warning: symbol 'tps65224_muxval_remap' was not declared. Should it be static? warning: symbol 'tps6594_muxval_remap' was not declared. Should it be static? Signed-off-by: Nirmala Devi Mal Nadar <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Link: https://lore.kernel.org/r/0109018f85002ae1-6fb831b2-74c2-4559-98f1-a3ef25e72558-000000@ap-south-1.amazonses.com Signed-off-by: Linus Walleij <[email protected]>
2024-06-17pinctrl: qcom: spmi: Add PMC8380Konrad Dybcio1-0/+1
PMC8380 is a new chip, featuring 10 GPIOs. Describe it. Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-06-17dt-bindings: pinctrl: qcom,pmic-gpio: Document PMC8380Konrad Dybcio1-0/+2
PMC8380 is a new PMIC used with X1 SoCs. Document it Signed-off-by: Konrad Dybcio <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-06-17pinctrl: core: reset gpio_device in loop in pinctrl_pins_show()Léo DUBOIN1-0/+1
We were not resetting the pointer to the associated gpio_device once we are done displaying a pin's information. This meant that once we reached the end of a gpio-range, if there were pins right after it that did not belong to any known range, they would be associated with the previous range's gpio device. This resulted in those pins appearing as <4294966783:old_gdev> instead of the expected <0:?> (due to gpio_num being -1). Signed-off-by: Léo DUBOIN <[email protected]> Link: https://lore.kernel.org/r/c40d0634abefa19e689ffd450e0f48a8d63c4fc4.1714049455.git.lduboin@freebox.fr Signed-off-by: Linus Walleij <[email protected]>
2024-06-17pinctrl: core: take into account the pins array in pinctrl_pins_show()Léo DUBOIN1-4/+13
We previously only looked at the 'pin_base' of the pinctrl_gpio_ranges struct for determining if a pin matched a GPIO number. This value is present only if the 'pins' array is not NULL, and is 0 otherwise. This means that GPIO ranges declared using gpiochip_add_pingroup_range(), thus making use of pins, were always matched by the pins in the range [0-npins] even if they contained pins in a completely separate range. Signed-off-by: Léo DUBOIN <[email protected]> Link: https://lore.kernel.org/r/6df39bd47942156be5713f8f4e317d2ad3e0ddeb.1714049455.git.lduboin@freebox.fr Signed-off-by: Linus Walleij <[email protected]>
2024-06-17pinctrl: nuvoton: Add ma35d1 pinctrl and GPIO driverJacky Huang5-0/+3059
Add common pinctrl and GPIO driver for Nuvoton MA35 series SoC, and add support for ma35d1 pinctrl. Signed-off-by: Jacky Huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-06-17dt-bindings: pinctrl: Document nuvoton ma35d1 pin controlJacky Huang1-0/+178
Add documentation to describe nuvoton ma35d1 pin control and GPIO. Signed-off-by: Jacky Huang <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-06-17dt-bindings: reset: Add syscon to nuvoton ma35d1 system-management nodeJacky Huang1-1/+2
Add a compatible 'syscon' to the system management node since the system control registers are mapped by this driver. The other driver must access the system control registers through 'regmap' using a phandle that references this node. Signed-off-by: Jacky Huang <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Acked-by: Philipp Zabel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-06-17pinctrl: st: Use scope based of_node_put() cleanupsPeng Fan1-26/+11
Use scope based of_node_put() cleanup to simplify code. Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Patrice Chotard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-06-17pinctrl: stm32: Use scope based of_node_put() cleanupsPeng Fan1-3/+1
Use scope based of_node_put() cleanup to simplify code. Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Patrice Chotard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-06-17pinctrl: imx: Add pinctrl driver support for i.MX91Peng Fan3-0/+279
Add NXP i.MX91 pinctrl driver Signed-off-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-06-17dt-bindings: pinctrl: imx: Support i.MX91 IOMUXCPeng Fan1-3/+5
i.MX91 and i.MX93 share similar design. They could share same dt-binding doc, so rename fsl,imx93-pinctrl.yaml to fsl,imx9-pinctrl.yaml and add i.MX91 compatible string Signed-off-by: Peng Fan <[email protected]> Acked-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-06-17dt-bindings: pinctrl: qcom,pmic-gpio: drop pm8008Johan Hovold1-3/+0
The binding for PM8008 is being reworked so that internal details like interrupts and register offsets are no longer described. This specifically also involves dropping the gpio child node and its compatible string which is no longer needed. Note that there are currently no users of the upstream binding and driver. Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Reviewed-by: Rob Herring (Arm) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-06-17pinctrl: qcom: spmi-gpio: drop broken pm8008 supportJohan Hovold1-1/+0
The SPMI GPIO driver assumes that the parent device is an SPMI device and accesses random data when backcasting the parent struct device pointer for non-SPMI devices. Fortunately this does not seem to cause any issues currently when the parent device is an I2C client like the PM8008, but this could change if the structures are reorganised (e.g. using structure randomisation). Notably the interrupt implementation is also broken for non-SPMI devices. Also note that the two GPIO pins on PM8008 are used for interrupts and reset so their practical use should be limited. Drop the broken GPIO support for PM8008 for now. Fixes: ea119e5a482a ("pinctrl: qcom-pmic-gpio: Add support for pm8008") Cc: [email protected] # 5.13 Reviewed-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2024-06-17arm64: zynqmp: Add pwm-fan node and fix ttc0 pwm-cells propertyVishal Patel1-0/+11
Add pwm-fan node to control fan through hwmon and change pwm-cells property to 3 to allow fancontrol utility to function correctly. Signed-off-by: Vishal Patel <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/ff6b4dbfc9bb1b53769ffbf7d0e932c7a8be7c08.1716802450.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Add support for K26 rev2 boardsMichal Simek2-6/+10
Revision 2 is SW compatible with revision 1 but it is necessary to reflect it in model and compatible properties which are parsed by user space. Rev 2 has improved a power on boot reset and MIO34 shutdown glich improvement done via an additional filter in the GreenPak chip. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/458698666fdfcaaac70967d9f755422a480bed99.1716802450.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Describe DisplayPort connector for KriaVishal Sagar1-0/+20
Add a device tree node to describe the DisplayPort connector, and connect it to the DPSUB output. The patch was tested on kv260-revB/rev2. Signed-off-by: Vishal Sagar <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/4f69489c005719d280b8df97f3e82a5ce0cd9660.1716802450.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Add description for ina260 on kv260Michal Simek2-3/+23
The commit f7ab2d180e6a ("dt-bindings: hwmon: ina2xx: Describe ina260 chip"), commit f29996d0295e ("dt-bindings: hwmon: ina2xx: Describe #io-channel-cells property") and commit eea32fafadd3 ("dt-bindings: hwmon: ina2xx: Add label property") added description for ina260 that's why describe them on kv260 Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/944cba76ef5df932f1bebde6c5e64ec9d201356d.1716802450.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Add compatible string for kv260Michal Simek2-0/+12
The commit dbcd27526e6a ("dt-bindings: soc: xilinx: Add support for KV260 CC") added description for kv260 kit and it should be also reflected in DTs. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/1e436f82182a92187f3892401664db2507482870.1716802450.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Disable Tri-state for SDIOTejas Bhumkar2-0/+2
Since the zynqmp pinctrl driver now includes support for the tri-state registers, ensure that the pins needing output-enable are correctly configured for SOMs. Currently, there is an issue with the detection of the MMC for the SOM kv260, resulting in the following error: ZynqMP> mmc dev 1 Card did not respond to voltage select! : -110 To address this problem, configure the SDIO pins for output-enable to enable MMC detection. Signed-off-by: Tejas Bhumkar <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/540f83f7d88b80441c9fa3d771dd7b000b0710a4.1716802450.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Remove address/size-cells from ams nodeMichal Simek1-2/+0
Remove unused address/size-cells properties without defining child. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/39f73999bbec0233264ce40f05c0885c46e423be.1716802450.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Describe OCM controllerMichal Simek1-0/+7
Describe OCM controller which brings EDAC functionality. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/679736679fdf7897d68684295f6ed8256fb5f18e.1716802450.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Describe USB wakeup interruptMichal Simek1-4/+6
Describe usb wakeup interrupt. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/8c11ac7d73c822ee207cecd1445205f19fcaf004.1716802450.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Add missing description for efusesMichal Simek1-0/+55
The commit 737c0c8d07b5 ("nvmem: zynqmp_nvmem: Add support to access efuse") added support for efuses that's why also describe them in DT. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/beb8002f8dae47ce6f38f7f961d024e65372b654.1716802450.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Use fpga-region as node nameMichal Simek1-1/+1
Based on commit 85f838adad54 ("dt-bindings: fpga: Convert fpga-region binding to yaml") fpga/programmable logic should use fpga-region as node name that's why move to it. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/9133aed74a24ad5cd9af5a6d5aa7ee9a160f94ee.1716802450.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Align nvmem node with dt schemaMichal Simek1-6/+9
Use new soc-nvmem node name and swich to nvmem fixed layout. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/7796804c7c7dd8bb2c93bdfe028c22746a24fe54.1716802450.git.michal.simek@amd.com
2024-06-17Merge tag 'v6.10-rc4' into driver-core-nextGreg Kroah-Hartman572-3282/+5855
We need the driver core and sysfs fixes in here to build on top of. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-17Merge tag 'v6.10-rc4' into char-misc-nextGreg Kroah-Hartman572-3282/+5855
We need the char-misc and iio fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-17dt-bindings: memory: fsl: replace maintainerMichael Walle1-1/+1
Li Yang's mail address is bouncing, replace it with Shawn Guo's one. Signed-off-by: Michael Walle <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]>
2024-06-17xfs: fix unlink vs cluster buffer instantiation raceDave Chinner1-4/+19
Luis has been reporting an assert failure when freeing an inode cluster during inode inactivation for a while. The assert looks like: XFS: Assertion failed: bp->b_flags & XBF_DONE, file: fs/xfs/xfs_trans_buf.c, line: 241 ------------[ cut here ]------------ kernel BUG at fs/xfs/xfs_message.c:102! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 4 PID: 73 Comm: kworker/4:1 Not tainted 6.10.0-rc1 #4 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: xfs-inodegc/loop5 xfs_inodegc_worker [xfs] RIP: 0010:assfail (fs/xfs/xfs_message.c:102) xfs RSP: 0018:ffff88810188f7f0 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff88816e748250 RCX: 1ffffffff844b0e7 RDX: 0000000000000004 RSI: ffff88810188f558 RDI: ffffffffc2431fa0 RBP: 1ffff11020311f01 R08: 0000000042431f9f R09: ffffed1020311e9b R10: ffff88810188f4df R11: ffffffffac725d70 R12: ffff88817a3f4000 R13: ffff88812182f000 R14: ffff88810188f998 R15: ffffffffc2423f80 FS: 0000000000000000(0000) GS:ffff8881c8400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055fe9d0f109c CR3: 000000014426c002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> xfs_trans_read_buf_map (fs/xfs/xfs_trans_buf.c:241 (discriminator 1)) xfs xfs_imap_to_bp (fs/xfs/xfs_trans.h:210 fs/xfs/libxfs/xfs_inode_buf.c:138) xfs xfs_inode_item_precommit (fs/xfs/xfs_inode_item.c:145) xfs xfs_trans_run_precommits (fs/xfs/xfs_trans.c:931) xfs __xfs_trans_commit (fs/xfs/xfs_trans.c:966) xfs xfs_inactive_ifree (fs/xfs/xfs_inode.c:1811) xfs xfs_inactive (fs/xfs/xfs_inode.c:2013) xfs xfs_inodegc_worker (fs/xfs/xfs_icache.c:1841 fs/xfs/xfs_icache.c:1886) xfs process_one_work (kernel/workqueue.c:3231) worker_thread (kernel/workqueue.c:3306 (discriminator 2) kernel/workqueue.c:3393 (discriminator 2)) kthread (kernel/kthread.c:389) ret_from_fork (arch/x86/kernel/process.c:147) ret_from_fork_asm (arch/x86/entry/entry_64.S:257) </TASK> And occurs when the the inode precommit handlers is attempt to look up the inode cluster buffer to attach the inode for writeback. The trail of logic that I can reconstruct is as follows. 1. the inode is clean when inodegc runs, so it is not attached to a cluster buffer when precommit runs. 2. #1 implies the inode cluster buffer may be clean and not pinned by dirty inodes when inodegc runs. 3. #2 implies that the inode cluster buffer can be reclaimed by memory pressure at any time. 4. The assert failure implies that the cluster buffer was attached to the transaction, but not marked done. It had been accessed earlier in the transaction, but not marked done. 5. #4 implies the cluster buffer has been invalidated (i.e. marked stale). 6. #5 implies that the inode cluster buffer was instantiated uninitialised in the transaction in xfs_ifree_cluster(), which only instantiates the buffers to invalidate them and never marks them as done. Given factors 1-3, this issue is highly dependent on timing and environmental factors. Hence the issue can be very difficult to reproduce in some situations, but highly reliable in others. Luis has an environment where it can be reproduced easily by g/531 but, OTOH, I've reproduced it only once in ~2000 cycles of g/531. I think the fix is to have xfs_ifree_cluster() set the XBF_DONE flag on the cluster buffers, even though they may not be initialised. The reasons why I think this is safe are: 1. A buffer cache lookup hit on a XBF_STALE buffer will clear the XBF_DONE flag. Hence all future users of the buffer know they have to re-initialise the contents before use and mark it done themselves. 2. xfs_trans_binval() sets the XFS_BLI_STALE flag, which means the buffer remains locked until the journal commit completes and the buffer is unpinned. Hence once marked XBF_STALE/XFS_BLI_STALE by xfs_ifree_cluster(), the only context that can access the freed buffer is the currently running transaction. 3. #2 implies that future buffer lookups in the currently running transaction will hit the transaction match code and not the buffer cache. Hence XBF_STALE and XFS_BLI_STALE will not be cleared unless the transaction initialises and logs the buffer with valid contents again. At which point, the buffer will be marked marked XBF_DONE again, so having XBF_DONE already set on the stale buffer is a moot point. 4. #2 also implies that any concurrent access to that cluster buffer will block waiting on the buffer lock until the inode cluster has been fully freed and is no longer an active inode cluster buffer. 5. #4 + #1 means that any future user of the disk range of that buffer will always see the range of disk blocks covered by the cluster buffer as not done, and hence must initialise the contents themselves. 6. Setting XBF_DONE in xfs_ifree_cluster() then means the unlinked inode precommit code will see a XBF_DONE buffer from the transaction match as it expects. It can then attach the stale but newly dirtied inode to the stale but newly dirtied cluster buffer without unexpected failures. The stale buffer will then sail through the journal and do the right thing with the attached stale inode during unpin. Hence the fix is just one line of extra code. The explanation of why we have to set XBF_DONE in xfs_ifree_cluster, OTOH, is long and complex.... Fixes: 82842fee6e59 ("xfs: fix AGF vs inode cluster buffer deadlock") Signed-off-by: Dave Chinner <[email protected]> Tested-by: Luis Chamberlain <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Chandan Babu R <[email protected]>
2024-06-17dt-bindings: arm: fsl: add i.MX93 9x9 QSB boardPeng Fan1-0/+1
Add compatible string for i.MX93 9x9 Quick Start Board. Acked-by: Conor Dooley <[email protected]> Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17dt-bindings: arm: fsl: add i.MX95 19x19 EVK boardPeng Fan1-0/+6
Add DT compatible string for NXP i.MX95 19x19 EVK board. Acked-by: Conor Dooley <[email protected]> Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17dt-bindings: arm: fsl: Document Compulab IOT-GATE-iMX8Fabio Estevam1-0/+7
Document Compulab's IOT-GATE-iMX8 board, which is based on Compulab's UCM-iMX8M-Mini SoM. Board URL: https://www.compulab.com/products/iot-gateways/iot-gate-imx8-industrial-arm-iot-gateway/ SoM URL: https://www.compulab.com/products/computer-on-modules/ucm-imx8m-mini-nxp-i-mx-8m-mini-som-system-on-module-computer/ Signed-off-by: Fabio Estevam <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17arm64: dts: freescale: Support i.MX93 9x9 Quick Start BoardPeng Fan2-0/+493
Add the board device tree with sdhc1/2, cm33, mu, lpuart1, lpi2c1/2, usb enabled and etc, which to support the i.MX 93 quick start evaluation kit that provides a low-cost platform to evaluate the i.MX 93 applications processors in a 9x9mm package. Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17arm64: dts: imx8qm-mek: fix gpio number for reg_usdhc2_vmmcFrank Li1-1/+1
The gpio in "reg_usdhc2_vmmc" should be 7 instead of 19. Cc: [email protected] Fixes: 307fd14d4b14 ("arm64: dts: imx: add imx8qm mek support") Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17arm64: dts: freescale: add i.MX95 19x19 EVK minimal board dtsPeng Fan2-0/+201
Add a minimal dts for i.MX95 19x19 EVK board: - lpuart1 as console - sdhc1/2 as storage Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17arm64: dts: freescale: add i.MX95 basic dtsiPeng Fan4-0/+2141
i.MX95 features 6 A55 Cores, ARM Mali GPU, ISP, ML acceleration NPU, and Edgelock secure enclave security. This patch is to add a minimal dtsi, with cpu cores, scmi, gic, uart, mu, sdhc, lpi2c added. Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17arm64: dts: imx8mm-iot-gateway: Add initial supportFabio Estevam3-0/+898
Add the initial support for the CompuLab i.MX8MM IoT Gateway board, which is based on the Compulab's UCM-iMX8M-Mini SoM. Board URL: https://www.compulab.com/products/iot-gateways/iot-gate-imx8-industrial-arm-iot-gateway/ SoM URL: https://www.compulab.com/products/computer-on-modules/ucm-imx8m-mini-nxp-i-mx-8m-mini-som-system-on-module-computer/ Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17wifi: rtw89: pci: fix RX tag race condition resulting in wrong RX lengthPing-Ke Shih1-5/+8
Read 32 bits RX info to a local variable to fix race condition between reading RX length and RX tag. Another solution is to get RX tag at first statement, but adopted solution can save some memory read, and also save 15 bytes binary code. RX tag, a sequence number, is used to ensure that RX data has been DMA to memory completely, so driver must check sequence number is expected before reading other data. This potential problem happens only after enabling 36-bit DMA. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17arm64: dts: layerscape: change thermal node nameFrank Li5-23/+23
Add thermal subfix for thermal node name to fix DTB_CHECK warning: thermal-zones: '...' do not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$' Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17wifi: rtw89: pci: support 36-bit PCI DMA addressPing-Ke Shih7-19/+95
Modern platforms can install more than 4GB memory, so DMA address can larger than 32 bits. If a platform doesn't enable IOMMU, kernel needs extra works of swiotlb to help DMA that packets reside on memory over 4GB. The DMA addressing capability of Realtek WiFi chips is 36 bits, so set LSB 4 bits of high 32-bit address to register and TX/RX descriptor, which below figure shows 3-level pointers in TX direction, and RX direction is similar but 2-level pointers only. +--------+ | | register to head of TX BD +---|----+ | +---------+ +-----> | TX BD | (in memory) +----|----+ | +---------+ +------> | TX WD | (in memory) +----|----+ | +--------+ +------> | skb | +--------+ Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17arm64: dts: layerscape: Change node name from 'esdhc' to 'mmc'Frank Li6-10/+10
Use common node name 'mmc' to fix DTB_CHECK warning. Add compatible string 'fsl,ls2080a-esdhc' for fsl-lx2160a. arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dtb: esdhc@1560000: $nodename:0: 'esdhc@1560000' does not match '^mmc(@.*)?$' arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dtb: esdhc@1560000: $nodename:0: 'esdhc@1560000' does not match '^mmc(@.*)?$' arch/arm64/boot/dts/freescale/fsl-ls1046a-frwy.dtb: esdhc@1560000: $nodename:0: 'esdhc@1560000' does not match '^mmc(@.*)?$' arch/arm64/boot/dts/freescale/fsl-ls1088a-qds.dtb: esdhc@2140000: $nodename:0: 'esdhc@2140000' does not match '^mmc(@.*)?$' arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dtb: esdhc@2140000: $nodename:0: 'esdhc@2140000' does not match '^mmc(@.*)?$' arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dtb: esdhc@2140000: compatible:0: 'fsl,esdhc' is not one of ['fsl,mpc8536-esdhc', 'fsl,mpc8378-esdhc', 'fsl,p2020-esdhc', 'fsl,p4080-esdhc', 'fsl,t1040-esdhc', 'fsl,t4240-esdhc', 'fsl,ls1012a-esdhc', 'fsl,ls1028a-esdhc', 'fsl,ls1088a-esdhc', 'fsl,ls1043a-esdhc', 'fsl,ls1046a-esdhc', 'fsl,ls2080a-esdhc'] from schema $id: http://devicetree.org/schemas/mmc/fsl,esdhc.yaml# arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dtb: esdhc@2140000: $nodename:0: 'esdhc@2140000' does not match '^mmc(@.*)?$' Signed-off-by: Frank Li <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17wifi: rtw89: adopt firmware whose version is equal or less but closestPing-Ke Shih1-8/+26
Version C of 8922AE hardware will use the same firmware of version B, so extend rule of firmware recognition to allow less but closest firmware version. Originally only accept firmware with matched version. Tested on version A/B/C of 8922AE. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17arm64: dts: imx8mp-msc-sm2s: Add HDMI outputLuca Ceresoli1-0/+27
Enable the HDMI output of the MSC SM2-MB-EP1 carrier board based the SM2S-IMX8PLUS SMARC module. Signed-off-by: Luca Ceresoli <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17wifi: rtw89: 885xbx: apply common settings to 8851B, 8852B and 8852BTPing-Ke Shih9-46/+57
Many common settings can share to 8851B, 8852B and 8852BT, so add an inline function rtw89_is_rtl885xb() to be concise. Meanwhile review and align settings for existing chips. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17wifi: rtw89: 8852bx: add extra handles for 8852BT in 8852b_commonPing-Ke Shih8-9/+315
The channel configuration of 8852BT is very similar but a little different to 8852B, so use chip ID as condition to add extra handles including external loss compensation, ADC configurations, spur settings and so on. Don't affect existing 8852BE. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17arm64: dts: freescale: imx8mp-verdin: add HDMI supportFrancesco Dolcini7-7/+160
Enable HDMI output on Verdin iMX8MP on all the supported carrier boards (dev, dahlia, mallow and yavia). HDMI DDC I2C is used in regular I2C mode, see link on the related dt-bindings patch. Fix CEC and HPD pinctrl, having a pull-down on HPD and a pull-up on CEC. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Francesco Dolcini <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2024-06-17wifi: rtw89: 8852bx: move common code from 8852b to 8852b_commonPing-Ke Shih7-1800/+2079
New upcoming chip is RTL8852BE-VT (or RTL8852BTE; 8852BT PCIE interface), which is a variant of 8852B, and many codes excepting to RF calibration can be shared, so move common code to an new kernel module named rtw89_8852b_common.ko. No logic change. Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected]
2024-06-17arm64: dts: imx8mp-debix-model-a: Enable HDMI outputChristopher Obbard1-0/+47
Enable the HDMI output on the Debix Model A SBC, using the HDMI encoder present in the i.MX8MP SoC. This has been tested with a generic 1080p HDMI display, along with a smaller 1280x800 HDMI display. Signed-off-by: Christopher Obbard <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Tested-by: Laurent Pinchart <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.