aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-09-23net: dsa: mt7530: add support for in-band link statusDaniel Golle2-13/+38
Read link status from SGMII PCS for in-band managed 2500Base-X and 1000Base-X connection on a MAC port of the MT7531. This is needed to get the SFP cage working which is connected to SGMII interface of port 5 of the MT7531 switch IC on the Bananapi BPi-R3 board. While at it also handle an_complete for both the autoneg and the non-autoneg codepath. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23Merge branch 'phy-rate-matching'David S. Miller11-34/+440
Sean Anderson says: ==================== net: phy: Add support for rate matching This adds support for phy rate matching: when a phy adapts between differing phy interface and link speeds. It was originally submitted as part of [1], which is considered "v1" of this series. Several past discussions [2-4] around adding rate adaptation provide some context. Although in earlier versions of this series, userspace could disable rate matching, now it is only possible to determine the current rate adaptation type. Disabling or otherwise configuring rate adaptation has been left for future work. However, because currently only RATE_MATCH_PAUSE is implemented, it is possible to disable rate adaptation by modifying the advertisement appropriately. [1] https://lore.kernel.org/netdev/20220715215954.1449214-1-sean.anderson@seco.com/T/#t [2] https://lore.kernel.org/netdev/1579701573-6609-1-git-send-email-madalin.bucur@oss.nxp.com/ [3] https://lore.kernel.org/netdev/1580137671-22081-1-git-send-email-madalin.bucur@oss.nxp.com/ [4] https://lore.kernel.org/netdev/20200116181933.32765-1-olteanv@gmail.com/ Changes in v6: - Don't announce that we've enabled pause frames for rate adaptation - Merry Christmas - Rename rate adaptation to rate matching - Reword documentation, (hopefully) taking into account feedback Changes in v5: - Break off patch "net: phy: Add 1000BASE-KX interface mode" for separate submission. - Document phy_rate_adaptation_to_str - Drop patch "Add some helpers for working with mac caps"; it has been incorperated into the autonegotiation patch. - Move phylink_cap_from_speed_duplex to this commit - Rebase onto net-next/master - Remove unnecessary comma Changes in v4: - Export phy_rate_adaptation_to_str - Remove phylink_interface_max_speed, which was accidentally added - Split off the LS1046ARDB 1G fix Changes in v3: - Add phylink_cap_from_speed_duplex to look up the mac capability corresponding to the interface's speed. - Document MAC_(A)SYM_PAUSE - Include RATE_ADAPT_CRS; it's a few lines and it doesn't hurt. - Modify link settings directly in phylink_link_up, instead of doing things more indirectly via link_*. - Move unused defines to next commit (where they will be used) - Remove "Support differing link/interface speed/duplex". It has been rendered unnecessary due to simplification of the rate adaptation patches. Thanks Russell! - Rewrite cover letter to better reflect the opinions of the developers involved Changes in v2: - Add (read-only) ethtool support for rate adaptation - Add comments clarifying the register defines - Add locking to phy_get_rate_adaptation - Always use the rate adaptation setting to determine the interface speed/duplex (instead of sometimes using the interface mode). - Determine the interface speed and max mac speed directly instead of guessing based on the caps. - Move part of commit message to cover letter, as it gives a good overview of the whole series, and allows this patch to focus more on the specifics. - Reorder variables in aqr107_read_rate - Use int/defines instead of enum to allow for use in ioctls/netlink - Use the phy's rate adaptation setting to determine whether to use its link speed/duplex or the MAC's speed/duplex with MLO_AN_INBAND. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23net: phy: aquantia: Add support for rate matchingSean Anderson1-4/+47
This adds support for rate matching for phys similar to the AQR107. We assume that all phys using aqr107_read_status support rate matching. However, it could be possible to determine support based on the firmware revision if there are phys discovered which do not support rate matching. However, as rate matching is advertised in the datasheets for these phys, I suspect it is supported most boards. Despite the name, the "config" registers are updated with the current rate matching method (if any). Because they appear to be updated automatically, I don't know if these registers can be used to disable rate matching. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23cpuidle: riscv-sbi: Fix CPU_PM_CPU_IDLE_ENTER_xyz() macro usageAnup Patel1-1/+6
Currently, we are using CPU_PM_CPU_IDLE_ENTER_PARAM() for all SBI HSM suspend types so retentive suspend types are also treated non-retentive and kernel will do redundant additional work for these states. The BIT[31] of SBI HSM suspend types allows us to differentiate between retentive and non-retentive suspend types so we should use this BIT to call appropriate CPU_PM_CPU_IDLE_ENTER_xyz() macro. Fixes: 6abf32f1d9c5 ("cpuidle: Add RISC-V SBI CPU idle driver") Signed-off-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20220718084553.2056169-1-apatel@ventanamicro.com/ Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2022-09-23net: phy: aquantia: Add some additional phy interfacesSean Anderson1-1/+16
These are documented in the AQR115 register reference. I haven't tested them, but perhaps they'll be useful to someone. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23net: phylink: Adjust advertisement based on rate matchingSean Anderson2-4/+105
This adds support for adjusting the advertisement for pause-based rate matching. This may result in a lossy link, since the final link settings are not adjusted. Asymmetric pause support is necessary. It would be possible for a MAC supporting only symmetric pause to use pause-based rate adaptation, but only if pause reception was enabled as well. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23net: phylink: Adjust link settings based on rate matchingSean Anderson2-12/+128
If the phy is configured to use pause-based rate matching, ensure that the link is full duplex with pause frame reception enabled. As suggested, if pause-based rate matching is enabled by the phy, then pause reception is unconditionally enabled. The interface duplex is determined based on the rate matching type. When rate matching is enabled, so is the speed. We assume the maximum interface speed is used. This is only relevant for MLO_AN_PHY. For MLO_AN_INBAND, the MAC/PCS's view of the interface speed will be used. Although there are no RATE_ADAPT_CRS phys in-tree, it has been added for comparison (and the implementation is quite simple). Co-developed-by: Russell King <linux@armlinux.org.uk> Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23net: phy: Add support for rate matchingSean Anderson8-3/+95
This adds support for rate matching (also known as rate adaptation) to the phy subsystem. The general idea is that the phy interface runs at one speed, and the MAC throttles the rate at which it sends packets to the link speed. There's a good overview of several techniques for achieving this at [1]. This patch adds support for three: pause-frame based (such as in Aquantia phys), CRS-based (such as in 10PASS-TS and 2BASE-TL), and open-loop-based (such as in 10GBASE-W). This patch makes a few assumptions and a few non assumptions about the types of rate matching available. First, it assumes that different phys may use different forms of rate matching. Second, it assumes that phys can use rate matching for any of their supported link speeds (e.g. if a phy supports 10BASE-T and XGMII, then it can adapt XGMII to 10BASE-T). Third, it does not assume that all interface modes will use the same form of rate matching. Fourth, it does not assume that all phy devices will support rate matching (even if some do). Relaxing or strengthening these (non-)assumptions could result in a different API. For example, if all interface modes were assumed to use the same form of rate matching, then a bitmask of interface modes supportting rate matching would suffice. For some better visibility into the process, the current rate matching mode is exposed as part of the ethtool ksettings. For the moment, only read access is supported. I'm not sure what userspace might want to configure yet (disable it altogether, disable just one mode, specify the mode to use, etc.). For the moment, since only pause-based rate adaptation support is added in the next few commits, rate matching can be disabled altogether by adjusting the advertisement. 802.3 calls this feature "rate adaptation" in clause 49 (10GBASE-R) and "rate matching" in clause 61 (10PASS-TL and 2BASE-TS). Aquantia also calls this feature "rate adaptation". I chose "rate matching" because it is shorter, and because Russell doesn't think "adaptation" is correct in this context. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23net: phylink: Generate caps and convert to linkmodes separatelySean Anderson2-12/+13
If we call phylink_caps_to_linkmodes directly from phylink_get_linkmodes, it is difficult to re-use this functionality in MAC drivers. This is because MAC drivers must then work with an ethtool linkmode bitmap, instead of with mac capabilities. Instead, let the caller of phylink_get_linkmodes do the conversion. To reflect this change, rename the function to phylink_get_capabilities. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23net: phylink: Export phylink_caps_to_linkmodesSean Anderson2-2/+11
This function is convenient for MAC drivers. They can use it to add or remove particular link modes based on capabilities (such as if half duplex is not supported for a particular interface mode). Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23net: phylink: Document MAC_(A)SYM_PAUSESean Anderson1-0/+29
This documents the possible MLO_PAUSE_* settings which can result from different combinations of MAC_(A)SYM_PAUSE. Special note is paid to settings which can result from user configuration (MLO_PAUSE_AN). The autonegotiation results are more-or-less a direct consequence of IEEE 802.3 Table 28B-2. Signed-off-by: Sean Anderson <sean.anderson@seco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23x86/resctrl: Allow per-rmid arch private storage to be resetJames Morse3-14/+62
To abstract the rmid counters into a helper that returns the number of bytes counted, architecture specific per-rmid state is needed. It needs to be possible to reset this hidden state, as the values may outlive the life of an rmid, or the mount time of the filesystem. mon_event_read() is called with first = true when an rmid is first allocated in mkdir_mondata_subdir(). Add resctrl_arch_reset_rmid() and call it from __mon_event_count()'s rr->first check. Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Jamie Iles <quic_jiles@quicinc.com> Reviewed-by: Shaopeng Tan <tan.shaopeng@fujitsu.com> Reviewed-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Xin Hao <xhao@linux.alibaba.com> Tested-by: Shaopeng Tan <tan.shaopeng@fujitsu.com> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20220902154829.30399-15-james.morse@arm.com
2022-09-23scsi: storvsc: remove an extraneous "to" in a commentwangjianli1-1/+1
Signed-off-by: wangjianli <wangjianli@cdjrlc.com> Link: https://lore.kernel.org/r/20220908130754.34999-1-wangjianli@cdjrlc.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2022-09-23Drivers: hv: vmbus: Don't wait for the ACPI device upon initializationStanislav Kinsburskiy1-9/+4
Waiting to 5 seconds in case of missing VMBus ACPI device is redundant as the device is either present already or won't be available at all. This patch enforces synchronous probing to make sure the bus traversal, happening upon driver registering will either find the device (if present) or not spend any additional time if device is absent. Signed-off-by: Stanislav Kinsburskiy <stanislav.kinsburskiy@gmail.com> CC: "K. Y. Srinivasan" <kys@microsoft.com> CC: Haiyang Zhang <haiyangz@microsoft.com> CC: Stephen Hemminger <sthemmin@microsoft.com> CC: Wei Liu <wei.liu@kernel.org> CC: Dexuan Cui <decui@microsoft.com> CC: linux-hyperv@vger.kernel.org CC: linux-kernel@vger.kernel.org Reviewed-by: Michael Kelley <mikelley@microsoft.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Link: https://lore.kernel.org/r/166378554568.581670.1124852716698789244.stgit@skinsburskii-cloud-desktop.internal.cloudapp.net Signed-off-by: Wei Liu <wei.liu@kernel.org>
2022-09-23mm/slub: enable debugging memory wasting of kmallocFeng Tang4-50/+142
kmalloc's API family is critical for mm, with one nature that it will round up the request size to a fixed one (mostly power of 2). Say when user requests memory for '2^n + 1' bytes, actually 2^(n+1) bytes could be allocated, so in worst case, there is around 50% memory space waste. The wastage is not a big issue for requests that get allocated/freed quickly, but may cause problems with objects that have longer life time. We've met a kernel boot OOM panic (v5.10), and from the dumped slab info: [ 26.062145] kmalloc-2k 814056KB 814056KB From debug we found there are huge number of 'struct iova_magazine', whose size is 1032 bytes (1024 + 8), so each allocation will waste 1016 bytes. Though the issue was solved by giving the right (bigger) size of RAM, it is still nice to optimize the size (either use a kmalloc friendly size or create a dedicated slab for it). And from lkml archive, there was another crash kernel OOM case [1] back in 2019, which seems to be related with the similar slab waste situation, as the log is similar: [ 4.332648] iommu: Adding device 0000:20:02.0 to group 16 [ 4.338946] swapper/0 invoked oom-killer: gfp_mask=0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null), order=0, oom_score_adj=0 ... [ 4.857565] kmalloc-2048 59164KB 59164KB The crash kernel only has 256M memory, and 59M is pretty big here. (Note: the related code has been changed and optimised in recent kernel [2], these logs are just picked to demo the problem, also a patch changing its size to 1024 bytes has been merged) So add an way to track each kmalloc's memory waste info, and leverage the existing SLUB debug framework (specifically SLUB_STORE_USER) to show its call stack of original allocation, so that user can evaluate the waste situation, identify some hot spots and optimize accordingly, for a better utilization of memory. The waste info is integrated into existing interface: '/sys/kernel/debug/slab/kmalloc-xx/alloc_traces', one example of 'kmalloc-4k' after boot is: 126 ixgbe_alloc_q_vector+0xbe/0x830 [ixgbe] waste=233856/1856 age=280763/281414/282065 pid=1330 cpus=32 nodes=1 __kmem_cache_alloc_node+0x11f/0x4e0 __kmalloc_node+0x4e/0x140 ixgbe_alloc_q_vector+0xbe/0x830 [ixgbe] ixgbe_init_interrupt_scheme+0x2ae/0xc90 [ixgbe] ixgbe_probe+0x165f/0x1d20 [ixgbe] local_pci_probe+0x78/0xc0 work_for_cpu_fn+0x26/0x40 ... which means in 'kmalloc-4k' slab, there are 126 requests of 2240 bytes which got a 4KB space (wasting 1856 bytes each and 233856 bytes in total), from ixgbe_alloc_q_vector(). And when system starts some real workload like multiple docker instances, there could are more severe waste. [1]. https://lkml.org/lkml/2019/8/12/266 [2]. https://lore.kernel.org/lkml/2920df89-9975-5785-f79b-257d3052dfaf@huawei.com/ [Thanks Hyeonggon for pointing out several bugs about sorting/format] [Thanks Vlastimil for suggesting way to reduce memory usage of orig_size and keep it only for kmalloc objects] Signed-off-by: Feng Tang <feng.tang@intel.com> Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: John Garry <john.garry@huawei.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2022-09-23random: clamp credited irq bits to maximum mixedJason A. Donenfeld1-1/+1
Since the most that's mixed into the pool is sizeof(long)*2, don't credit more than that many bytes of entropy. Fixes: e3e33fc2ea7f ("random: do not use input pool from hard IRQs") Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-09-23Drivers: hv: vmbus: Use PCI_VENDOR_ID_MICROSOFT for better discoverabilityEaswar Hariharan1-1/+1
pci_ids.h already defines PCI_VENDOR_ID_MICROSOFT, and is included via linux/pci.h. Use the define instead of the magic number. Signed-off-by: Easwar Hariharan <easwar.hariharan@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/1663625084-2518-2-git-send-email-eahariha@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2022-09-23Drivers: hv: vmbus: Fix kernel-docJiapeng Chong1-1/+1
drivers/hv/vmbus_drv.c:1587: warning: expecting prototype for __vmbus_child_driver_register(). Prototype was for __vmbus_driver_register() instead. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2210 Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/20220919063815.1881-1-jiapeng.chong@linux.alibaba.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2022-09-23dt-bindings: clock: convert rockchip,rk3128-cru.txt to YAMLJohan Jonker2-58/+76
Convert rockchip,rk3128-cru.txt to YAML. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/4e69a06d-7b53-ab48-1e50-2b29ff3a54e6@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-23random: throttle hwrng writes if no entropy is creditedJason A. Donenfeld1-2/+2
If a hwrng source does not provide an entropy estimate, it currently does not contribute at all to the CRNG. In order to help fix this, in case add_hwgenerator_randomness() is called with the entropy parameter set to zero, go to sleep until one reseed interval has passed. While the hwrng thread currently only runs under conditions where this is non-zero, this change is not harmful and prepares for future updates to the hwrng core. Cc: Herbert Xu <herbert@gondor.apana.org.au> Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-09-23random: use hwgenerator randomness more frequently at early bootDominik Brodowski1-12/+10
Mix in randomness from hw-rng sources more frequently during early boot, approximately once for every rng reseed. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-09-23random: restore O_NONBLOCK supportJason A. Donenfeld2-2/+7
Prior to 5.6, when /dev/random was opened with O_NONBLOCK, it would return -EAGAIN if there was no entropy. When the pools were unified in 5.6, this was lost. The post 5.6 behavior of blocking until the pool is initialized, and ignoring O_NONBLOCK in the process, went unnoticed, with no reports about the regression received for two and a half years. However, eventually this indeed did break somebody's userspace. So we restore the old behavior, by returning -EAGAIN if the pool is not initialized. Unlike the old /dev/random, this can only occur during early boot, after which it never blocks again. In order to make this O_NONBLOCK behavior consistent with other expectations, also respect users reading with preadv2(RWF_NOWAIT) and similar. Fixes: 30c08efec888 ("random: make /dev/random be almost like /dev/urandom") Reported-by: Guozihua <guozihua@huawei.com> Reported-by: Zhongguohua <zhongguohua1@huawei.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Andrew Lutomirski <luto@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-09-23arm64: dts: rockchip: Add DSI and DSI-DPHY nodes to rk356xChris Morgan1-0/+80
This adds the DSI controller nodes and DSI-DPHY controller nodes to the rk356x device tree. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Michael Riesch <michael.riesch@wolfvision.net> Link: https://lore.kernel.org/r/20220919164616.12492-4-macroalpha82@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-23drm/hyperv: Don't overwrite dirt_needed value set by hostSaurabh Sengar1-2/+0
Existing code is causing a race condition where dirt_needed value is already set by the host and gets overwritten with default value. Remove this default setting of dirt_needed, to avoid overwriting the value received in the channel callback set by vmbus_open. Removing this setting also means the default value for dirt_needed is changed to false as it's allocated by kzalloc which is similar to legacy hyperv_fb driver. Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> Reviewed-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/1662996766-19304-1-git-send-email-ssengar@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2022-09-23drm/meson: remove drm bridges at aggregate driver unbind timeAdrián Larumbe6-0/+39
drm bridges added by meson_encoder_hdmi_init and meson_encoder_cvbs_init were not manually removed at module unload time, which caused dangling references to freed memory to remain linked in the global bridge_list. When loading the driver modules back in, the same functions would again call drm_bridge_add, and when traversing the global bridge_list, would end up peeking into freed memory. Once again KASAN revealed the problem: [ +0.000095] ============================================================= [ +0.000008] BUG: KASAN: use-after-free in __list_add_valid+0x9c/0x120 [ +0.000018] Read of size 8 at addr ffff00003da291f0 by task modprobe/2483 [ +0.000018] CPU: 3 PID: 2483 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000011] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000006] dump_backtrace+0x1ec/0x280 [ +0.000012] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000008] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000009] __list_add_valid+0x9c/0x120 [ +0.000009] drm_bridge_add+0x6c/0x104 [drm] [ +0.000165] dw_hdmi_probe+0x1900/0x2360 [dw_hdmi] [ +0.000022] meson_dw_hdmi_bind+0x520/0x814 [meson_dw_hdmi] [ +0.000014] component_bind+0x174/0x520 [ +0.000012] component_bind_all+0x1a8/0x38c [ +0.000010] meson_drv_bind_master+0x5e8/0xb74 [meson_drm] [ +0.000032] meson_drv_bind+0x20/0x2c [meson_drm] [ +0.000027] try_to_bring_up_aggregate_device+0x19c/0x390 [ +0.000010] component_master_add_with_match+0x1c8/0x284 [ +0.000009] meson_drv_probe+0x274/0x280 [meson_drm] [ +0.000026] platform_probe+0xd0/0x220 [ +0.000009] really_probe+0x3ac/0xa80 [ +0.000009] __driver_probe_device+0x1f8/0x400 [ +0.000009] driver_probe_device+0x68/0x1b0 [ +0.000009] __driver_attach+0x20c/0x480 [ +0.000008] bus_for_each_dev+0x114/0x1b0 [ +0.000009] driver_attach+0x48/0x64 [ +0.000008] bus_add_driver+0x390/0x564 [ +0.000009] driver_register+0x1a8/0x3e4 [ +0.000009] __platform_driver_register+0x6c/0x94 [ +0.000008] meson_drm_platform_driver_init+0x3c/0x1000 [meson_drm] [ +0.000027] do_one_initcall+0xc4/0x2b0 [ +0.000011] do_init_module+0x154/0x570 [ +0.000011] load_module+0x1a78/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000009] __arm64_sys_init_module+0x78/0xb0 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000016] Allocated by task 879: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] __kasan_kmalloc+0x90/0xd0 [ +0.000007] __kmalloc+0x278/0x4a0 [ +0.000011] mpi_resize+0x13c/0x1d0 [ +0.000011] mpi_powm+0xd24/0x1570 [ +0.000009] rsa_enc+0x1a4/0x30c [ +0.000009] pkcs1pad_verify+0x3f0/0x580 [ +0.000009] public_key_verify_signature+0x7a8/0xba4 [ +0.000010] public_key_verify_signature_2+0x40/0x60 [ +0.000008] verify_signature+0xb4/0x114 [ +0.000008] pkcs7_validate_trust_one.constprop.0+0x3b8/0x574 [ +0.000009] pkcs7_validate_trust+0xb8/0x15c [ +0.000008] verify_pkcs7_message_sig+0xec/0x1b0 [ +0.000012] verify_pkcs7_signature+0x78/0xac [ +0.000007] mod_verify_sig+0x110/0x190 [ +0.000009] module_sig_check+0x114/0x1e0 [ +0.000009] load_module+0xa0/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000008] __arm64_sys_init_module+0x78/0xb0 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0x1a8/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000013] Freed by task 2422: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000009] kasan_set_track+0x2c/0x40 [ +0.000007] kasan_set_free_info+0x28/0x50 [ +0.000009] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000010] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000009] devres_release_group+0x180/0x270 [ +0.000008] take_down_aggregate_device+0xcc/0x160 [ +0.000010] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000013] platform_remove+0x64/0xb0 [ +0.000008] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000009] platform_driver_unregister+0x20/0x2c [ +0.000007] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000009] __arm64_sys_delete_module+0x5c/0x80 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000008] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000013] The buggy address belongs to the object at ffff00003da29000 which belongs to the cache kmalloc-1k of size 1024 [ +0.000008] The buggy address is located 496 bytes inside of 1024-byte region [ffff00003da29000, ffff00003da29400) [ +0.000015] The buggy address belongs to the physical page: [ +0.000009] page:fffffc0000f68a00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3da28 [ +0.000012] head:fffffc0000f68a00 order:3 compound_mapcount:0 compound_pincount:0 [ +0.000009] flags: 0xffff00000010200(slab|head|node=0|zone=0|lastcpupid=0xffff) [ +0.000019] raw: 0ffff00000010200 fffffc0000eb5c08 fffffc0000d96608 ffff000000002a80 [ +0.000008] raw: 0000000000000000 00000000000a000a 00000001ffffffff 0000000000000000 [ +0.000008] page dumped because: kasan: bad access detected [ +0.000011] Memory state around the buggy address: [ +0.000009] ffff00003da29080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ffff00003da29100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] >ffff00003da29180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ^ [ +0.000008] ffff00003da29200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000006] ffff00003da29280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ================================================================== Fix by keeping track of which encoders were initialised in the meson_drm structure and manually removing their bridges at aggregate driver's unbind time. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220920222842.1053234-1-adrian.larumbe@collabora.com
2022-09-23drm/meson: explicitly remove aggregate driver at module unload timeAdrián Larumbe1-0/+8
Because component_master_del wasn't being called when unloading the meson_drm module, the aggregate device would linger forever in the global aggregate_devices list. That means when unloading and reloading the meson_dw_hdmi module, component_add would call into try_to_bring_up_aggregate_device and find the unbound meson_drm aggregate device. This would in turn dereference some of the aggregate_device's struct entries which point to memory automatically freed by the devres API when unbinding the aggregate device from meson_drv_unbind, and trigger an use-after-free bug: [ +0.000014] ============================================================= [ +0.000007] BUG: KASAN: use-after-free in find_components+0x468/0x500 [ +0.000017] Read of size 8 at addr ffff000006731688 by task modprobe/2536 [ +0.000018] CPU: 4 PID: 2536 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000010] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000005] dump_backtrace+0x1ec/0x280 [ +0.000011] show_stack+0x24/0x80 [ +0.000007] dump_stack_lvl+0x98/0xd4 [ +0.000010] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000007] kasan_report+0xb8/0xfc [ +0.000007] __asan_report_load8_noabort+0x3c/0x50 [ +0.000009] find_components+0x468/0x500 [ +0.000008] try_to_bring_up_aggregate_device+0x64/0x390 [ +0.000009] __component_add+0x1dc/0x49c [ +0.000009] component_add+0x20/0x30 [ +0.000008] meson_dw_hdmi_probe+0x28/0x34 [meson_dw_hdmi] [ +0.000013] platform_probe+0xd0/0x220 [ +0.000008] really_probe+0x3ac/0xa80 [ +0.000008] __driver_probe_device+0x1f8/0x400 [ +0.000008] driver_probe_device+0x68/0x1b0 [ +0.000008] __driver_attach+0x20c/0x480 [ +0.000009] bus_for_each_dev+0x114/0x1b0 [ +0.000007] driver_attach+0x48/0x64 [ +0.000009] bus_add_driver+0x390/0x564 [ +0.000007] driver_register+0x1a8/0x3e4 [ +0.000009] __platform_driver_register+0x6c/0x94 [ +0.000007] meson_dw_hdmi_platform_driver_init+0x30/0x1000 [meson_dw_hdmi] [ +0.000014] do_one_initcall+0xc4/0x2b0 [ +0.000008] do_init_module+0x154/0x570 [ +0.000010] load_module+0x1a78/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000008] __arm64_sys_init_module+0x78/0xb0 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000008] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000014] Allocated by task 902: [ +0.000007] kasan_save_stack+0x2c/0x5c [ +0.000009] __kasan_kmalloc+0x90/0xd0 [ +0.000007] __kmalloc_node+0x240/0x580 [ +0.000010] memcg_alloc_slab_cgroups+0xa4/0x1ac [ +0.000010] memcg_slab_post_alloc_hook+0xbc/0x4c0 [ +0.000008] kmem_cache_alloc_node+0x1d0/0x490 [ +0.000009] __alloc_skb+0x1d4/0x310 [ +0.000010] alloc_skb_with_frags+0x8c/0x620 [ +0.000008] sock_alloc_send_pskb+0x5ac/0x6d0 [ +0.000010] unix_dgram_sendmsg+0x2e0/0x12f0 [ +0.000010] sock_sendmsg+0xcc/0x110 [ +0.000007] sock_write_iter+0x1d0/0x304 [ +0.000008] new_sync_write+0x364/0x460 [ +0.000007] vfs_write+0x420/0x5ac [ +0.000008] ksys_write+0x19c/0x1f0 [ +0.000008] __arm64_sys_write+0x78/0xb0 [ +0.000007] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0x1a8/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000008] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000013] Freed by task 2509: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000007] kasan_set_track+0x2c/0x40 [ +0.000008] kasan_set_free_info+0x28/0x50 [ +0.000008] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000010] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000008] devres_release_all+0xfc/0x180 [ +0.000008] device_unbind_cleanup+0x24/0x164 [ +0.000008] device_release_driver_internal+0x3e8/0x5b0 [ +0.000010] driver_detach+0xac/0x1b0 [ +0.000008] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000009] platform_driver_unregister+0x20/0x2c [ +0.000007] 0xffff800003722d98 [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000009] __arm64_sys_delete_module+0x5c/0x80 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000008] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000013] Last potentially related work creation: [ +0.000007] kasan_save_stack+0x2c/0x5c [ +0.000007] __kasan_record_aux_stack+0xb8/0xf0 [ +0.000009] kasan_record_aux_stack_noalloc+0x14/0x20 [ +0.000008] insert_work+0x54/0x290 [ +0.000009] __queue_work+0x48c/0xd24 [ +0.000008] queue_work_on+0x90/0x11c [ +0.000008] call_usermodehelper_exec+0x188/0x404 [ +0.000010] kobject_uevent_env+0x5a8/0x794 [ +0.000010] kobject_uevent+0x14/0x20 [ +0.000008] driver_register+0x230/0x3e4 [ +0.000009] __platform_driver_register+0x6c/0x94 [ +0.000007] gxbb_driver_init+0x28/0x34 [ +0.000010] do_one_initcall+0xc4/0x2b0 [ +0.000008] do_initcalls+0x20c/0x24c [ +0.000010] kernel_init_freeable+0x22c/0x278 [ +0.000009] kernel_init+0x3c/0x170 [ +0.000008] ret_from_fork+0x10/0x20 [ +0.000013] The buggy address belongs to the object at ffff000006731600 which belongs to the cache kmalloc-256 of size 256 [ +0.000009] The buggy address is located 136 bytes inside of 256-byte region [ffff000006731600, ffff000006731700) [ +0.000015] The buggy address belongs to the physical page: [ +0.000008] page:fffffc000019cc00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff000006730a00 pfn:0x6730 [ +0.000011] head:fffffc000019cc00 order:2 compound_mapcount:0 compound_pincount:0 [ +0.000008] flags: 0xffff00000010200(slab|head|node=0|zone=0|lastcpupid=0xffff) [ +0.000016] raw: 0ffff00000010200 fffffc00000c3d08 fffffc0000ef2b08 ffff000000002680 [ +0.000009] raw: ffff000006730a00 0000000000150014 00000001ffffffff 0000000000000000 [ +0.000006] page dumped because: kasan: bad access detected [ +0.000011] Memory state around the buggy address: [ +0.000007] ffff000006731580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ +0.000007] ffff000006731600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] >ffff000006731680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ^ [ +0.000006] ffff000006731700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ +0.000007] ffff000006731780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ +0.000006] ================================================================== Fix by adding 'remove' driver callback for meson-drm, and explicitly deleting the aggregate device. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220919010940.419893-3-adrian.larumbe@collabora.com
2022-09-23drm/meson: reorder driver deinit sequence to fix use-after-free bugAdrián Larumbe1-1/+1
Unloading the driver triggers the following KASAN warning: [ +0.006275] ============================================================= [ +0.000029] BUG: KASAN: use-after-free in __list_del_entry_valid+0xe0/0x1a0 [ +0.000026] Read of size 8 at addr ffff000020c395e0 by task rmmod/2695 [ +0.000019] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000013] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000007] dump_backtrace+0x1ec/0x280 [ +0.000013] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000007] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000010] __list_del_entry_valid+0xe0/0x1a0 [ +0.000009] drm_atomic_private_obj_fini+0x30/0x200 [drm] [ +0.000172] drm_bridge_detach+0x94/0x260 [drm] [ +0.000145] drm_encoder_cleanup+0xa4/0x290 [drm] [ +0.000144] drm_mode_config_cleanup+0x118/0x740 [drm] [ +0.000143] drm_mode_config_init_release+0x1c/0x2c [drm] [ +0.000144] drm_managed_release+0x170/0x414 [drm] [ +0.000142] drm_dev_put.part.0+0xc0/0x124 [drm] [ +0.000143] drm_dev_put+0x20/0x30 [drm] [ +0.000142] meson_drv_unbind+0x1d8/0x2ac [meson_drm] [ +0.000028] take_down_aggregate_device+0xb0/0x160 [ +0.000016] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000015] platform_remove+0x64/0xb0 [ +0.000009] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000009] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000011] __arm64_sys_delete_module+0x5c/0x80 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000018] Allocated by task 0: [ +0.000007] (stack is not available) [ +0.000011] Freed by task 2695: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] kasan_set_track+0x2c/0x40 [ +0.000008] kasan_set_free_info+0x28/0x50 [ +0.000009] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000011] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000009] devres_release_group+0x180/0x270 [ +0.000008] component_unbind+0x128/0x1e0 [ +0.000010] component_unbind_all+0x1b8/0x264 [ +0.000009] meson_drv_unbind+0x1a0/0x2ac [meson_drm] [ +0.000025] take_down_aggregate_device+0xb0/0x160 [ +0.000009] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000012] platform_remove+0x64/0xb0 [ +0.000008] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000011] __do_sys_delete_module+0x288/0x400 [ +0.000010] __arm64_sys_delete_module+0x5c/0x80 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000014] The buggy address belongs to the object at ffff000020c39000 which belongs to the cache kmalloc-4k of size 4096 [ +0.000008] The buggy address is located 1504 bytes inside of 4096-byte region [ffff000020c39000, ffff000020c3a000) [ +0.000016] The buggy address belongs to the physical page: [ +0.000009] page:fffffc0000830e00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20c38 [ +0.000013] head:fffffc0000830e00 order:3 compound_mapcount:0 compound_pincount:0 [ +0.000008] flags: 0xffff00000010200(slab|head|node=0|zone=0|lastcpupid=0xffff) [ +0.000019] raw: 0ffff00000010200 fffffc0000fd4808 fffffc0000126208 ffff000000002e80 [ +0.000009] raw: 0000000000000000 0000000000020002 00000001ffffffff 0000000000000000 [ +0.000008] page dumped because: kasan: bad access detected [ +0.000011] Memory state around the buggy address: [ +0.000008] ffff000020c39480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ffff000020c39500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] >ffff000020c39580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ^ [ +0.000007] ffff000020c39600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ffff000020c39680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000006] ================================================================== The reason this is happening is unloading meson-dw-hdmi will cause the component API to take down the aggregate device, which in turn will cause all devres-managed memory to be freed, including the struct dw_hdmi allocated in dw_hdmi_probe. This struct embeds a struct drm_bridge that is added at the end of the function, and which is later on picked up in meson_encoder_hdmi_init. However, when attaching the bridge to the encoder created in meson_encoder_hdmi_init, it's linked to the encoder's bridge chain, from where it never leaves, even after devres_release_group is called when the driver's components are unbound and the embedding structure freed. Then, when calling drm_dev_put in the aggregate driver's unbind function, drm_bridge_detach is called for every single bridge linked to the encoder, including the one whose memory had already been deallocated. Fix by calling component_unbind_all after drm_dev_put. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220919010940.419893-2-adrian.larumbe@collabora.com
2022-09-23arm64: dts: rockchip: Enable HDMI and GPU on quartz64-bNicolas Frattaroli1-0/+60
This enables the GPU and HDMI output (including HDMI audio) on the PINE64 Quartz64 Model B single board computer. Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Link: https://lore.kernel.org/r/20220920143446.633956-1-frattaroli.nicolas@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-23Drivers: hv: vmbus: Optimize vmbus_on_eventSaurabh Sengar2-19/+23
In the vmbus_on_event loop, 2 jiffies timer will not serve the purpose if callback_fn takes longer. For effective use move this check inside of callback functions where needed. Out of all the VMbus drivers using vmbus_on_event, only storvsc has a high packet volume, thus add this limit only in storvsc callback for now. There is no apparent benefit of loop itself because this tasklet will be scheduled anyway again if there are packets left in ring buffer. This patch removes this unnecessary loop as well. Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/1658741848-4210-1-git-send-email-ssengar@linux.microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org>
2022-09-23Merge branch 'mt7621-dt'David S. Miller8-166/+80
Arınç ÜNAL says: ==================== dt-bindings and mt7621 devicetree changes This patch series removes old MediaTek bindings, improves mediatek,mt7530 and mt7621 memory controller bindings and improves mt7621 DTs. v4: - Keep memory-controller node name. - Change syscon to memory-controller on mt7621.dtsi. v3: - Explain the mt7621 memory controller binding change in more details. - Remove explaining the remaining DTC warnings from the patch log as there are new schemas submitted for them. v2: - Change memory controller node name to syscon on the schema example. - Keep cpu compatible string and syscon on the memory controller node. - Add Rob and Sergio's tags. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23mips: dts: ralink: mt7621: add GB-PC2 LEDsArınç ÜNAL2-12/+36
Add the missing LEDs for GB-PC2. The ethblack-green, ethblue-green, power and system LEDs weren't added previously, because they don't exist on the device schematics. Tests on a GB-PC2 by me and Petr proved otherwise. The i2c bus cannot be used on GB-PC2 as its pins are wired to LEDs instead, and GB-PC1 does not use it. Therefore, do not enable it on both devices. Link: https://github.com/ngiger/GnuBee_Docs/blob/master/GB-PCx/Documents/GB-PC2_V1.1_schematic.pdf Tested-by: Petr Louda <petr.louda@outlook.cz> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23mips: dts: ralink: mt7621: fix external phy on GB-PC2Arınç ÜNAL1-3/+3
The address of the external phy on the mdio bus is 5. Update the devicetree for GB-PC2 accordingly. Fixes: 5bc148649cf3 ("staging: mt7621-dts: fix GB-PC2 devicetree") Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23mips: dts: ralink: mt7621: change mt7530 switch addressArınç ÜNAL1-2/+2
In the case of muxing phy0 of the MT7530 switch, the switch and the phy will have the same address on the mdio bus, 0. This causes the ethernet driver to fail since devices on the mdio bus cannot share an address. Any address can be used for the switch, therefore, change the switch address to 0x1f. Suggested-by: Sungbo Eo <mans0n@gorani.run> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23mips: dts: ralink: mt7621: change phy-mode of gmac1 to rgmiiArınç ÜNAL1-1/+1
Change phy-mode of gmac1 to rgmii on mt7621.dtsi. Same code path is followed for delayed rgmii and rgmii phy-mode on mtk_eth_soc.c. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23mips: dts: ralink: mt7621: remove interrupt-parent from switch nodeArınç ÜNAL1-1/+0
The interrupt-parent property is inherited from the ethernet node as it's a parent node of the switch node. Therefore, remove the unnecessary interrupt-parent property from the switch node. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23mips: dts: ralink: mt7621: fix some dtc warningsArınç ÜNAL3-20/+14
Fix the dtc warnings below. uartlite@c00: $nodename:0: 'uartlite@c00' does not match '^serial(@.*)?$' From schema: /home/arinc9/Documents/linux/Documentation/devicetree/bindings/serial/8250.yaml uartlite@c00: Unevaluated properties are not allowed ('clock-names' was unexpected) From schema: /home/arinc9/Documents/linux/Documentation/devicetree/bindings/serial/8250.yaml sdhci@1e130000: $nodename:0: 'sdhci@1e130000' does not match '^mmc(@.*)?$' From schema: /home/arinc9/Documents/linux/Documentation/devicetree/bindings/mmc/mtk-sd.yaml xhci@1e1c0000: $nodename:0: 'xhci@1e1c0000' does not match '^usb(@.*)?' From schema: /home/arinc9/Documents/linux/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml xhci@1e1c0000: compatible: ['mediatek,mt8173-xhci'] is too short From schema: /home/arinc9/Documents/linux/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml switch0@0: $nodename:0: 'switch0@0' does not match '^(ethernet-)?switch(@.*)?$' From schema: /home/arinc9/Documents/linux/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml port@1: status:0: 'off' is not one of ['okay', 'disabled', 'reserved'] From schema: /home/arinc9/.local/lib/python3.10/site-packages/dtschema/schemas/dt-core.yaml port@2: status:0: 'off' is not one of ['okay', 'disabled', 'reserved'] From schema: /home/arinc9/.local/lib/python3.10/site-packages/dtschema/schemas/dt-core.yaml port@3: status:0: 'off' is not one of ['okay', 'disabled', 'reserved'] From schema: /home/arinc9/.local/lib/python3.10/site-packages/dtschema/schemas/dt-core.yaml - Change "memc: syscon@5000" to "memc: memory-controller@5000". - Change "uartlite: uartlite@c00" to "serial0: serial@c00" and remove the aliases node. - Remove "clock-names" from the serial0 node. The property doesn't exist on the 8250.yaml schema. - Change "sdhci: sdhci@1e130000" to "mmc: mmc@1e130000". - Change "xhci: xhci@1e1c0000" to "usb: usb@1e1c0000". - Add "mediatek,mtk-xhci" as the second compatible string on the usb node. - Change "switch0: switch0@0" to "switch0: switch@0" - Change "off" to "disabled" for disabled nodes. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23dt-bindings: memory: mt7621: add syscon as compatible stringArınç ÜNAL1-2/+4
The syscon string was introduced because the mt7621 clock driver needs to read some registers creating a regmap from the syscon. The bindings were added before the clock driver was properly mainlined and at first the clock driver was using ralink architecture dependent operations rt_memc_* defined in 'arch/mips/include/asm/mach-ralink/ralink_regs.h'. This string is already there on the memory controller node on mt7621.dtsi. Add syscon as a constant string on the compatible property, now that memc became a syscon. Update the example accordingly. Fixes: 5278e4a181ff ("dt-bindings: memory: add binding for Mediatek's MT7621 SDRAM memory controller") Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23dt-bindings: net: dsa: mediatek,mt7530: expand gpio-controller descriptionArınç ÜNAL1-1/+9
Expand the description of the gpio-controller property to include the controllable pins of the MT7530 switch. The gpio-controller property is only used for the MT7530 switch. Therefore, invalidate it for the MT7531 switch. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23dt-bindings: net: dsa: mediatek,mt7530: change mt7530 switch addressArınç ÜNAL1-12/+12
In the case of muxing phy0 of the MT7530 switch, the switch and the phy will have the same address on the mdio bus, 0. This causes the ethernet driver to fail since devices on the mdio bus cannot share an address. Any address can be used for the switch, therefore, change the switch address to 0x1f. Suggested-by: Sungbo Eo <mans0n@gorani.run> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23dt-bindings: net: drop old mediatek bindingsArınç ÜNAL3-113/+0
Remove these old mediatek bindings which are not used. Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23arm64: defconfig: Enable Synopsys DWC MSHC driverAnand Moon1-0/+1
Enable the driver SDHCI support for the Synopsys DWC MSHC controller which can be found on Rockchip 356x SoCs. Cc: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Anand Moon <linux.amoon@gmail.com> Link: https://lore.kernel.org/r/20220922192050.2031-1-linux.amoon@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-23drm/bridge: lt8912b: clarify lvds output statusFrancesco Dolcini1-9/+17
Add comments on the lt8912_write_lvds_config() config to document the current settings and to make it clear that this is a hardcoded configuration not relevant for the HDMI output (could be removed without affecting the HDMI port). No changes on the actual register writes. Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-5-dev@pschenker.ch
2022-09-23drm/bridge: lt8912b: fix corrupted image outputFrancesco Dolcini1-1/+1
Correct I2C address for the register list in lt8912_write_lvds_config(), these registers are on the first I2C address (0x48), the current function is just writing garbage to the wrong registers and this creates multiple issues (artifacts and output completely corrupted) on some HDMI displays. Correct I2C address comes from Lontium documentation and it is the one used on other out-of-tree LT8912B drivers [1]. [1] https://github.com/boundarydevices/linux/blob/boundary-imx_5.10.x_2.0.0/drivers/video/lt8912.c#L296 Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-4-dev@pschenker.ch
2022-09-23drm/bridge: lt8912b: set hdmi or dvi modePhilippe Schenker1-0/+2
The Lontium LT8912 does have a setting for DVI or HDMI. This patch reads from EDID what the display needs and sets it accordingly. Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-3-dev@pschenker.ch
2022-09-23drm/bridge: lt8912b: add vsync hsyncPhilippe Schenker1-1/+8
Currently the bridge driver does not take care whether or not the display needs positive/negative vertical/horizontal syncs. Pass these two flags to the bridge from the EDID that was read out from the display. Fixes: 30e2ae943c26 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com> Acked-by: Adrien Grassein <adrien.grassein@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220922124306.34729-2-dev@pschenker.ch
2022-09-23clk: rockchip: Add clock controller support for RV1126 SoCJagan Teki4-0/+1165
Clock & Reset Unit (CRU) in RV1126 support clocks for CRU and CRU_PMU blocks. This patch is trying to add minimal Clock-Architecture Diagram's inferred from [1] authored by Finley Xiao. [1] https://github.com/rockchip-linux/kernel/blob/develop-4.19/drivers/clk/rockchip/clk-rv1126.c Cc: linux-clk@vger.kernel.org Cc: Michael Turquette <mturquette@baylibre.com> Cc: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com> Signed-off-by: Jagan Teki <jagan@edgeble.ai> Link: https://lore.kernel.org/r/20220915163947.1922183-5-jagan@edgeble.ai Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-23Merge branch 'sparx5-qos'David S. Miller9-2/+916
Daniel Machon says: ==================== net: Add QoS offload support for sparx5 This patch series adds support for offloading QoS features with the tc command suite, to the sparx5 switch. The new offloadable QoS features introduced in this patch series are: - tc-mqprio for mapping traffic class to hardware queue. Queues are by default mapped 1:1 in hardware, as such the mqprio qdisc is used as an attachment point for qdiscs tbf and ets. $ tc qdisc add dev eth0 root handle 1:0 mqprio - tc-tbf for setting up shaping on scheduler elements of the HSCH (Hierarchical Scheduler) block. Shaping on either port output or queue output is supported. Port shaper: $ tc qdisc add dev eth0 root handle 1:0 tbf rate \ 10000000 burst 8192 limit 1m Queue shaper: $ tc qdisc replace dev eth0 parent 1:5 handle 2:0 tbf \ rate 10000000 burst 8192 limit 1m - tc-ets for setting up strict and or bandwidth-sharing bands on one through eight priority queues. Configure a mix of strict and bw-sharing bands: $ tc qdisc add dev eth0 handle 1: root ets bands 8 strict 5 \ quanta 1000 1000 1000 priomap 7 6 5 4 3 2 1 0 Patch #1 Sets up the tc hook. Patch #2 Adds support for offloading the tc-mqprio qdisc. Patch #3 Adds support for offloading the tc-tbf qdisc. Patch #4 Adds support for offloading the tc-ets qdisc. Patch #5 Updates the maintainers of the sparx5 driver. ======================================================================== v1: https://lore.kernel.org/netdev/20220919120215.3815696-1-daniel.machon@microchip.com/ v1 -> v2: - Fix compiler warning in patch #2 - Fix comment style in patch #4 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23maintainers: update MAINTAINERS file.Daniel Machon1-0/+1
Update Maintainers file. Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23net: microchip: sparx5: add support for offloading ets qdiscDaniel Machon4-0/+154
Add support for offloading ets qdisc to sparx5 switch. The ets qdisc makes it possible to configure a mix og strict and bandwidth-sharing bands. The ets qdisc must be attached as a root qdisc. Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-23net: microchip: sparx5: add support for offloading tbf qdiscDaniel Machon5-0/+648
Add support for offloading tbf qdisc to sparx5 qdisc. The tbf qdisc makes it possible to attach a shaper on traffic egressing from a port or a queue. Per-port tbf qdiscs are attached as a root qdisc directly and queue tbf qdiscs are attached to one of the classes of a parent qdisc (such as mqprio). Signed-off-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.