aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-07-06Merge tag 'irqchip-fixes-5.19-2' of ↵Thomas Gleixner3-12/+33
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent Pull irqchip fixes from Marc Zygnier: - Gracefully handle failure to request MMIO resources in the GICv3 driver - Make a static key static in the Apple AIC driver - Fix the Xilinx intc driver dependency on OF_ADDRESS Link: https://lore.kernel.org/all/[email protected]
2022-07-06dt-bindings: dma: allwinner,sun50i-a64-dma: Fix min/max typoSamuel Holland1-1/+1
The conditional block for variants with a second clock should have set minItems, not maxItems, which was already 2. Since clock-names requires two items, this typo should not have caused any problems. Fixes: edd14218bd66 ("dt-bindings: dmaengine: Convert Allwinner A31 and A64 DMA to a schema") Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2022-07-06nvme-pci: phison e16 has bogus namespace idsKeith Busch1-1/+2
Add the quirk. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216049 Reported-by: Chris Egolf <[email protected]> Signed-off-by: Keith Busch <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2022-07-06video: of_display_timing.h: include errno.hHsin-Yi Wang1-0/+2
If CONFIG_OF is not enabled, default of_get_display_timing() returns an errno, so include the header. Fixes: 422b67e0b31a ("videomode: provide dummy inline functions for !CONFIG_OF") Suggested-by: Stephen Boyd <[email protected]> Signed-off-by: Hsin-Yi Wang <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Helge Deller <[email protected]>
2022-07-06fbdev: fbmem: Fix logo center image dx issueGuiling Deng1-1/+1
Image.dx gets wrong value because of missing '()'. If xres == logo->width and n == 1, image.dx = -16. Signed-off-by: Guiling Deng <[email protected]> Fixes: 3d8b1933eb1c ("fbdev: fbmem: add config option to center the bootup logo") Cc: [email protected] # v5.0+ Signed-off-by: Helge Deller <[email protected]>
2022-07-06Revert "tls: rx: move counting TlsDecryptErrors for sync"Gal Pressman1-4/+4
This reverts commit 284b4d93daee56dff3e10029ddf2e03227f50dbf. When using TLS device offload and coming from tls_device_reencrypt() flow, -EBADMSG error in tls_do_decryption() should not be counted towards the TLSTlsDecryptError counter. Move the counter increase back to the decrypt_internal() call site in decrypt_skb_update(). This also fixes an issue where: if (n_sgin < 1) return -EBADMSG; Errors in decrypt_internal() were not counted after the cited patch. Fixes: 284b4d93daee ("tls: rx: move counting TlsDecryptErrors for sync") Cc: Jakub Kicinski <[email protected]> Reviewed-by: Maxim Mikityanskiy <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Gal Pressman <[email protected]> Reviewed-by: Jakub Kicinski <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-07-06Merge branch 'mptcp-path-manager-fixes'David S. Miller7-31/+192
Mat Martineau says: ==================== mptcp: Path manager fixes for 5.19 The MPTCP userspace path manager is new in 5.19, and these patches fix some issues in that new code. Patches 1-3 fix path manager locking issues. Patches 4 and 5 allow userspace path managers to change priority of established subflows using the existing MPTCP_PM_CMD_SET_FLAGS generic netlink command. Includes corresponding self test update. Patches 6 and 7 fix accounting of available endpoint IDs and the MPTCP_MIB_RMSUBFLOW counter. ==================== Signed-off-by: David S. Miller <[email protected]>
2022-07-06mptcp: update MIB_RMSUBFLOW in cmd_sf_destroyGeliang Tang1-0/+2
This patch increases MPTCP_MIB_RMSUBFLOW mib counter in userspace pm destroy subflow function mptcp_nl_cmd_sf_destroy() when removing subflow. Fixes: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establishment") Signed-off-by: Geliang Tang <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-07-06mptcp: fix local endpoint accountingPaolo Abeni1-1/+2
In mptcp_pm_nl_rm_addr_or_subflow() we always mark as available the id corresponding to the just removed address. The used bitmap actually tracks only the local IDs: we must restrict the operation when a (local) subflow is removed. Fixes: a88c9e496937 ("mptcp: do not block subflows creation on errors") Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-07-06selftests: mptcp: userspace PM support for MP_PRIO signalsKishen Maloor2-2/+103
This change updates the testing sample (pm_nl_ctl) to exercise the updated MPTCP_PM_CMD_SET_FLAGS command for userspace PMs to issue MP_PRIO signals over the selected subflow. E.g. ./pm_nl_ctl set 10.0.1.2 port 47234 flags backup token 823274047 rip 10.0.1.1 rport 50003 userspace_pm.sh has a new selftest that invokes this command. Fixes: 259a834fadda ("selftests: mptcp: functional tests for the userspace PM type") Acked-by: Paolo Abeni <[email protected]> Signed-off-by: Kishen Maloor <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-07-06mptcp: netlink: issue MP_PRIO signals from userspace PMsKishen Maloor3-6/+62
This change updates MPTCP_PM_CMD_SET_FLAGS to allow userspace PMs to issue MP_PRIO signals over a specific subflow selected by the connection token, local and remote address+port. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/286 Fixes: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establishment") Acked-by: Paolo Abeni <[email protected]> Signed-off-by: Kishen Maloor <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-07-06mptcp: Acquire the subflow socket lock before modifying MP_PRIO flagsMat Martineau3-3/+12
When setting up a subflow's flags for sending MP_PRIO MPTCP options, the subflow socket lock was not held while reading and modifying several struct members that are also read and modified in mptcp_write_options(). Acquire the subflow socket lock earlier and send the MP_PRIO ACK with that lock already acquired. Add a new variant of the mptcp_subflow_send_ack() helper to use with the subflow lock held. Fixes: 067065422fcd ("mptcp: add the outgoing MP_PRIO support") Acked-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-07-06mptcp: Avoid acquiring PM lock for subflow priority changesMat Martineau2-6/+5
The in-kernel path manager code for changing subflow flags acquired both the msk socket lock and the PM lock when possibly changing the "backup" and "fullmesh" flags. mptcp_pm_nl_mp_prio_send_ack() does not access anything protected by the PM lock, and it must release and reacquire the PM lock. By pushing the PM lock to where it is needed in mptcp_pm_nl_fullmesh(), the lock is only acquired when the fullmesh flag is changed and the backup flag code no longer has to release and reacquire the PM lock. The change in locking context requires the MIB update to be modified - move that to a better location instead. This change also makes it possible to call mptcp_pm_nl_mp_prio_send_ack() for the userspace PM commands without manipulating the in-kernel PM lock. Fixes: 0f9f696a502e ("mptcp: add set_flags command in PM netlink") Acked-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-07-06mptcp: fix locking in mptcp_nl_cmd_sf_destroy()Paolo Abeni1-13/+6
The user-space PM subflow removal path uses a couple of helpers that must be called under the msk socket lock and the current code lacks such requirement. Change the existing lock scope so that the relevant code is under its protection. Fixes: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establishment") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/287 Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Mat Martineau <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-07-06Merge branch 'act_police-continue-offload-fix'David S. Miller3-8/+8
Vlad Buslov says: ==================== net: Fix police 'continue' action offload TC act_police with 'continue' action had been supported by mlx5 matchall classifier offload implementation for some time. However, 'continue' was assumed implicitly and recently got broken in multiple places. Fix it in both TC hardware offload validation code and mlx5 driver. ==================== Signed-off-by: David S. Miller <[email protected]>
2022-07-06net/mlx5e: Fix matchall police parameters validationVlad Buslov1-7/+6
Referenced commit prepared the code for upcoming extension that allows mlx5 to offload police action attached to flower classifier. However, with regard to existing matchall classifier offload validation should be reversed as FLOW_ACTION_CONTINUE is the only supported notexceed police action type. Fix the problem by allowing FLOW_ACTION_CONTINUE for police action and extend scan_tc_matchall_fdb_actions() to only allow such actions with matchall classifier. Fixes: d97b4b105ce7 ("flow_offload: reject offload for all drivers with invalid police parameters") Signed-off-by: Vlad Buslov <[email protected]> Acked-by: Saeed Mahameed <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-07-06net/sched: act_police: allow 'continue' action offloadVlad Buslov2-1/+2
Offloading police with action TC_ACT_UNSPEC was erroneously disabled even though it was supported by mlx5 matchall offload implementation, which didn't verify the action type but instead assumed that any single police action attached to matchall classifier is a 'continue' action. Lack of action type check made it non-obvious what mlx5 matchall implementation actually supports and caused implementers and reviewers of referenced commits to disallow it as a part of improved validation code. Fixes: b8cd5831c61c ("net: flow_offload: add tc police action parameters") Fixes: b50e462bc22d ("net/sched: act_police: Add extack messages for offload failure") Signed-off-by: Vlad Buslov <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Tested-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-07-06iommu/vt-d: Fix RID2PASID setup/teardown failureLu Baolu4-94/+3
The IOMMU driver shares the pasid table for PCI alias devices. When the RID2PASID entry of the shared pasid table has been filled by the first device, the subsequent device will encounter the "DMAR: Setup RID2PASID failed" failure as the pasid entry has already been marked as present. As the result, the IOMMU probing process will be aborted. On the contrary, when any alias device is hot-removed from the system, for example, by writing to /sys/bus/pci/devices/.../remove, the shared RID2PASID will be cleared without any notifications to other devices. As the result, any DMAs from those rest devices are blocked. Sharing pasid table among PCI alias devices could save two memory pages for devices underneath the PCIe-to-PCI bridges. Anyway, considering that those devices are rare on modern platforms that support VT-d in scalable mode and the saved memory is negligible, it's reasonable to remove this part of immature code to make the driver feasible and stable. Fixes: ef848b7e5a6a0 ("iommu/vt-d: Setup pasid entry for RID2PASID support") Reported-by: Chenyi Qiang <[email protected]> Reported-by: Ethan Zhao <[email protected]> Signed-off-by: Lu Baolu <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Ethan Zhao <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2022-07-06iommu/vt-d: Fix PCI bus rescan device hot addYian Chen1-1/+1
Notifier calling chain uses priority to determine the execution order of the notifiers or listeners registered to the chain. PCI bus device hot add utilizes the notification mechanism. The current code sets low priority (INT_MIN) to Intel dmar_pci_bus_notifier and postpones DMAR decoding after adding new device into IOMMU. The result is that struct device pointer cannot be found in DRHD search for the new device's DMAR/IOMMU. Subsequently, the device is put under the "catch-all" IOMMU instead of the correct one. This could cause system hang when device TLB invalidation is sent to the wrong IOMMU. Invalidation timeout error and hard lockup have been observed and data inconsistency/crush may occur as well. This patch fixes the issue by setting a positive priority(1) for dmar_pci_bus_notifier while the priority of IOMMU bus notifier uses the default value(0), therefore DMAR decoding will be in advance of DRHD search for a new device to find the correct IOMMU. Following is a 2-step example that triggers the bug by simulating PCI device hot add behavior in Intel Sapphire Rapids server. echo 1 > /sys/bus/pci/devices/0000:6a:01.0/remove echo 1 > /sys/bus/pci/rescan Fixes: 59ce0515cdaf ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope") Cc: [email protected] # v3.15+ Reported-by: Zhang, Bernice <[email protected]> Signed-off-by: Jacob Pan <[email protected]> Signed-off-by: Yian Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2022-07-06x86/compressed/64: Add identity mappings for setup_data entriesMichael Roth1-0/+13
The decompressed kernel initially relies on the identity map set up by the boot/compressed kernel for accessing things like boot_params. With the recent introduction of SEV-SNP support, the decompressed kernel also needs to access the setup_data entries pointed to by boot_params->hdr.setup_data. This can lead to a crash in the kexec kernel during early boot due to these entries not currently being included in the initial identity map, see thread at Link below. Include mappings for the setup_data entries in the initial identity map. [ bp: Massage commit message and use a helper var for better readability. ] Fixes: b190a043c49a ("x86/sev: Add SEV-SNP feature detection/setup") Reported-by: Jun'ichi Nomura <[email protected]> Signed-off-by: Michael Roth <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Link: https://lore.kernel.org/r/TYCPR01MB694815CD815E98945F63C99183B49@TYCPR01MB6948.jpnprd01.prod.outlook.com
2022-07-06dmaengine: lgm: Fix an error handling path in intel_ldma_probe()Christophe JAILLET1-1/+2
ldma_clk_disable() calls both: clk_disable_unprepare(d->core_clk); reset_control_assert(d->rst); So, should devm_reset_control_get_optional() fail, core_clk should not be prepare_enable'd before it, otherwise it will never be disable_unprepare'd. Reorder the code to handle the error handling path as expected. Fixes: 32d31c79a1a4 ("dmaengine: Add Intel LGM SoC DMA support.") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/18504549bc4d2b62a72a02cb22a2e4d8e6a58720.1653241224.git.christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul <[email protected]>
2022-07-06dmaengine: pl330: Fix lockdep warning about non-static keyDmitry Osipenko1-1/+1
The DEFINE_SPINLOCK() macro shouldn't be used for dynamically allocated spinlocks. The lockdep warns about this and disables locking validator. Fix the warning by making lock static. INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. Hardware name: Radxa ROCK Pi 4C (DT) Call trace: dump_backtrace.part.0+0xcc/0xe0 show_stack+0x18/0x6c dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 register_lock_class+0x4a8/0x4cc __lock_acquire+0x78/0x20cc lock_acquire.part.0+0xe0/0x230 lock_acquire+0x68/0x84 _raw_spin_lock_irqsave+0x84/0xc4 add_desc+0x44/0xc0 pl330_get_desc+0x15c/0x1d0 pl330_prep_dma_cyclic+0x100/0x270 snd_dmaengine_pcm_trigger+0xec/0x1c0 dmaengine_pcm_trigger+0x18/0x24 ... Fixes: e588710311ee ("dmaengine: pl330: fix descriptor allocation fail") Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2022-07-05net: lan966x: hardcode the number of external portsMichael Walle2-6/+3
Instead of counting the child nodes in the device tree, hardcode the number of ports in the driver itself. The counting won't work at all if an ethernet port is marked as disabled, e.g. because it is not connected on the board at all. It turns out that the LAN9662 and LAN9668 use the same switching IP with the same synthesis parameters. The only difference is that the output ports are not connected. Thus, we can just hardcode the number of physical ports to 8. Fixes: db8bcaad5393 ("net: lan966x: add the basic lan966x driver") Signed-off-by: Michael Walle <[email protected]> Reviewed-by: Horatiu Vultur <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-07-05Merge tag 'for-net-2022-07-05' of ↵Jakub Kicinski2-1/+3
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - Fix deadlock when powering on. * tag 'for-net-2022-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: core: Fix deadlock on hci_power_on_sync. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-07-05Bluetooth: core: Fix deadlock on hci_power_on_sync.Vasyl Vavrychuk2-1/+3
`cancel_work_sync(&hdev->power_on)` was moved to hci_dev_close_sync in commit [1] to ensure that power_on work is canceled after HCI interface down. But, in certain cases power_on work function may call hci_dev_close_sync itself: hci_power_on -> hci_dev_do_close -> hci_dev_close_sync -> cancel_work_sync(&hdev->power_on), causing deadlock. In particular, this happens when device is rfkilled on boot. To avoid deadlock, move power_on work canceling out of hci_dev_do_close/hci_dev_close_sync. Deadlock introduced by commit [1] was reported in [2,3] as broken suspend. Suspend did not work because `hdev->req_lock` held as result of `power_on` work deadlock. In fact, other BT features were not working. It was not observed when testing [1] since it was verified without rfkill in place. NOTE: It is not needed to cancel power_on work from other places where hci_dev_do_close/hci_dev_close_sync is called in case: * Requests were serialized due to `hdev->req_workqueue`. The power_on work is first in that workqueue. * hci_rfkill_set_block which won't close device anyway until HCI_SETUP is on. * hci_sock_release which runs after hci_sock_bind which ensures HCI_SETUP was cleared. As result, behaviour is the same as in pre-dd06ed7 commit, except power_on work cancel added to hci_dev_close. [1]: commit ff7f2926114d ("Bluetooth: core: Fix missing power_on work cancel on HCI close") [2]: https://lore.kernel.org/lkml/[email protected]/ [2]: https://lore.kernel.org/lkml/[email protected]/ Fixes: ff7f2926114d ("Bluetooth: core: Fix missing power_on work cancel on HCI close") Signed-off-by: Vasyl Vavrychuk <[email protected]> Reported-by: Max Krummenacher <[email protected]> Reported-by: Mateusz Jonczyk <[email protected]> Tested-by: Max Krummenacher <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
2022-07-05ACPI: CPPC: Don't require _OSC if X86_FEATURE_CPPC is supportedMario Limonciello3-1/+26
commit 72f2ecb7ece7 ("ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported") added support for claiming to support CPPC in _OSC on non-Intel platforms. This unfortunately caused a regression on a vartiety of AMD platforms in the field because a number of AMD platforms don't set the `_OSC` bit 5 or 6 to indicate CPPC or CPPC v2 support. As these AMD platforms already claim CPPC support via a dedicated MSR from `X86_FEATURE_CPPC`, use this enable this feature rather than requiring the `_OSC` on platforms with a dedicated MSR. If there is additional breakage on the shared memory designs also missing this _OSC, additional follow up changes may be needed. Fixes: 72f2ecb7ece7 ("Set CPPC _OSC bits for all and when CPPC_LIB is supported") Reported-by: Perry Yuan <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2022-07-05ACPI: CPPC: Only probe for _CPC if CPPC v2 is ackedMario Limonciello3-8/+9
Previously the kernel used to ignore whether the firmware masked CPPC or CPPCv2 and would just pretend that it worked. When support for the USB4 bit in _OSC was introduced from commit 9e1f561afb ("ACPI: Execute platform _OSC also with query bit clear") the kernel began to look at the return when the query bit was clear. This caused regressions that were misdiagnosed and attempted to be solved as part of commit 2ca8e6285250 ("Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag""). This caused a different regression where non-Intel systems weren't able to negotiate _OSC properly. This was reverted in commit 2ca8e6285250 ("Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag"") and attempted to be fixed by commit c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not supported by firmware") but the regression still returned. These systems with the regression only load support for CPPC from an SSDT dynamically when _OSC reports CPPC v2. Avoid the problem by not letting CPPC satisfy the requirement in `acpi_cppc_processor_probe`. Reported-by: CUI Hao <[email protected]> Reported-by: [email protected] Reported-by: [email protected] Reported-by: [email protected] Reported-by: [email protected] Fixes: c42fa24b4475 ("ACPI: bus: Avoid using CPPC if not supported by firmware") Fixes: 2ca8e6285250 ("Revert "ACPI Pass the same capabilities to the _OSC regardless of the query flag"") Link: https://bugzilla.kernel.org/show_bug.cgi?id=213023 Link: https://bugzilla.redhat.com/show_bug.cgi?id=2075387 Reviewed-by: Mika Westerberg <[email protected]> Tested-by: CUI Hao <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2022-07-05Merge tag 'xsa-5.19-tag' of ↵Linus Torvalds3-23/+93
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen security fixes from Juergen Gross: - XSA-403 (4 patches for blkfront and netfront drivers): Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). - XSA-405 (1 patch for netfront driver, only 5.10 and newer): While adding logic to support XDP (eXpress Data Path), a code label was moved in a way allowing for SKBs having references (pointers) retained for further processing to nevertheless be freed. - XSA-406 (1 patch for Arm specific dom0 code): When mapping pages of guests on Arm, dom0 is using an rbtree to keep track of the foreign mappings. Updating of that rbtree is not always done completely with the related lock held, resulting in a small race window, which can be used by unprivileged guests via PV devices to cause inconsistencies of the rbtree. These inconsistencies can lead to Denial of Service (DoS) of dom0, e.g. by causing crashes or the inability to perform further mappings of other guests' memory pages. * tag 'xsa-5.19-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen/arm: Fix race in RB-tree based P2M accounting xen-netfront: restore __skb_queue_tail() positioning in xennet_get_responses() xen/blkfront: force data bouncing when backend is untrusted xen/netfront: force data bouncing when backend is untrusted xen/netfront: fix leaking data in shared pages xen/blkfront: fix leaking data in shared pages
2022-07-05ALSA: cs46xx: Fix missing snd_card_free() call at probe errorTakashi Iwai1-9/+13
The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 5bff69b3645d ("ALSA: cs46xx: Allocate resources with device-managed APIs") Cc: <[email protected]> Reported-and-tested-by: Jan Engelhardt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2022-07-05fscache: Fix invalidation/lookup raceDavid Howells2-1/+15
If an NFS file is opened for writing and closed, fscache_invalidate() will be asked to invalidate the file - however, if the cookie is in the LOOKING_UP state (or the CREATING state), then request to invalidate doesn't get recorded for fscache_cookie_state_machine() to do something with. Fix this by making __fscache_invalidate() set a flag if it sees the cookie is in the LOOKING_UP state to indicate that we need to go to invalidation. Note that this requires a count on the n_accesses counter for the state machine, which that will release when it's done. fscache_cookie_state_machine() then shifts to the INVALIDATING state if it sees the flag. Without this, an nfs file can get corrupted if it gets modified locally and then read locally as the cache contents may not get updated. Fixes: d24af13e2e23 ("fscache: Implement cookie invalidation") Reported-by: Max Kellermann <[email protected]> Signed-off-by: David Howells <[email protected]> Tested-by: Max Kellermann <[email protected]> Link: https://lore.kernel.org/r/[email protected] [1]
2022-07-05cachefiles: narrow the scope of flushed requests when releasing fdJia Zhu1-1/+2
When an anonymous fd is released, only flush the requests associated with it, rather than all of requests in xarray. Fixes: 9032b6e8589f ("cachefiles: implement on-demand read") Signed-off-by: Jia Zhu <[email protected]> Signed-off-by: David Howells <[email protected]> Reviewed-by: Jeffle Xu <[email protected]> Reviewed-by: Gao Xiang <[email protected]> Link: https://listman.redhat.com/archives/linux-cachefs/2022-June/006937.html
2022-07-05fscache: Introduce fscache_cookie_is_dropped()Yue Hu1-3/+8
FSCACHE_COOKIE_STATE_DROPPED will be read more than once, so let's add a helper to avoid code duplication. Signed-off-by: Yue Hu <[email protected]> Signed-off-by: David Howells <[email protected]> Link: https://listman.redhat.com/archives/linux-cachefs/2022-May/006919.html
2022-07-05fscache: Fix if condition in fscache_wait_on_volume_collision()Yue Hu1-2/+2
After waiting for the volume to complete the acquisition with timeout, the if condition under which potential volume collision occurs should be acquire the volume is still pending rather than not pending so that we will continue to wait until the pending flag is cleared. Also, use the existing test pending wrapper directly instead of test_bit(). Fixes: 62ab63352350 ("fscache: Implement volume registration") Signed-off-by: Yue Hu <[email protected]> Signed-off-by: David Howells <[email protected]> Reviewed-by: Gao Xiang <[email protected]> Reviewed-by: Jeffle Xu <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Link: https://listman.redhat.com/archives/linux-cachefs/2022-May/006918.html
2022-07-05gpio: vf610: fix compilation errorLeon Romanovsky1-0/+1
Fix compilation error by explicitly adding the missing include. drivers/gpio/gpio-vf610.c: In function ‘vf610_gpio_direction_input’: drivers/gpio/gpio-vf610.c:120:9: error: implicit declaration of function ‘pinctrl_gpio_direction_input’; did you mean ‘vf610_gpio_direction_input’? [-Werror=implicit-function-declaration] 120 | return pinctrl_gpio_direction_input(chip->base + gpio); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ | vf610_gpio_direction_input Fixes: 30a35c07d9e9 ("gpio: vf610: drop the SOC_VF610 dependency for GPIO_VF610") Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Tariq Toukan <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Peng Fan <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2022-07-05dmaengine: idxd: Only call idxd_enable_system_pasid() if succeeded in ↵Jerry Snitselaar1-6/+7
enabling SVA feature On a Sapphire Rapids system if boot without intel_iommu=on, the IDXD driver will crash during probe in iommu_sva_bind_device(). [ 21.423729] BUG: kernel NULL pointer dereference, address: 0000000000000038 [ 21.445108] #PF: supervisor read access in kernel mode [ 21.450912] #PF: error_code(0x0000) - not-present page [ 21.456706] PGD 0 [ 21.459047] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 21.464004] CPU: 0 PID: 1420 Comm: kworker/0:3 Not tainted 5.19.0-0.rc3.27.eln120.x86_64 #1 [ 21.464011] Hardware name: Intel Corporation EAGLESTREAM/EAGLESTREAM, BIOS EGSDCRB1.SYS.0067.D12.2110190954 10/19/2021 [ 21.464015] Workqueue: events work_for_cpu_fn [ 21.464030] RIP: 0010:iommu_sva_bind_device+0x1d/0xe0 [ 21.464046] Code: c3 cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 57 41 56 49 89 d6 41 55 41 54 55 53 48 83 ec 08 48 8b 87 d8 02 00 00 <48> 8b 40 38 48 8b 50 10 48 83 7a 70 00 48 89 14 24 0f 84 91 00 00 [ 21.464050] RSP: 0018:ff7245d9096b7db8 EFLAGS: 00010296 [ 21.464054] RAX: 0000000000000000 RBX: ff1eadeec8a51000 RCX: 0000000000000000 [ 21.464058] RDX: ff7245d9096b7e24 RSI: 0000000000000000 RDI: ff1eadeec8a510d0 [ 21.464060] RBP: ff1eadeec8a51000 R08: ffffffffb1a12300 R09: ff1eadffbfce25b4 [ 21.464062] R10: ffffffffffffffff R11: 0000000000000038 R12: ffffffffc09f8000 [ 21.464065] R13: ff1eadeec8a510d0 R14: ff7245d9096b7e24 R15: ff1eaddf54429000 [ 21.464067] FS: 0000000000000000(0000) GS:ff1eadee7f600000(0000) knlGS:0000000000000000 [ 21.464070] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.464072] CR2: 0000000000000038 CR3: 00000008c0e10006 CR4: 0000000000771ef0 [ 21.464074] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 21.464076] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 21.464078] PKRU: 55555554 [ 21.464079] Call Trace: [ 21.464083] <TASK> [ 21.464092] idxd_pci_probe+0x259/0x1070 [idxd] [ 21.464121] local_pci_probe+0x3e/0x80 [ 21.464132] work_for_cpu_fn+0x13/0x20 [ 21.464136] process_one_work+0x1c4/0x380 [ 21.464143] worker_thread+0x1ab/0x380 [ 21.464147] ? _raw_spin_lock_irqsave+0x23/0x50 [ 21.464158] ? process_one_work+0x380/0x380 [ 21.464161] kthread+0xe6/0x110 [ 21.464168] ? kthread_complete_and_exit+0x20/0x20 [ 21.464172] ret_from_fork+0x1f/0x30 iommu_sva_bind_device() requires SVA has been enabled successfully on the IDXD device before it's called. Otherwise, iommu_sva_bind_device() will access a NULL pointer. If Intel IOMMU is disabled, SVA cannot be enabled and thus idxd_enable_system_pasid() and iommu_sva_bind_device() should not be called. Fixes: 42a1b73852c4 ("dmaengine: idxd: Separate user and kernel pasid enabling") Cc: Vinod Koul <[email protected]> Cc: [email protected] Cc: Dave Jiang <[email protected]> Cc: Fenghua Yu <[email protected]> Link: https://lore.kernel.org/dmaengine/20220623170232.6whonfjuh3m5vcoy@cantor/ Signed-off-by: Jerry Snitselaar <[email protected]> Acked-by: Fenghua Yu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2022-07-05dmaengine: at_xdma: handle errors of at_xdmac_alloc_desc() correctlyMichael Walle1-0/+5
It seems that it is valid to have less than the requested number of descriptors. But what is not valid and leads to subsequent errors is to have zero descriptors. In that case, abort the probing. Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Signed-off-by: Michael Walle <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>
2022-07-05Merge branch ↵Paolo Abeni1-1/+5
'fix-bridge_vlan_aware-sh-and-bridge_vlan_unaware-sh-with-iff_unicast_flt' Vladimir Oltean says: ==================== Fix bridge_vlan_aware.sh and bridge_vlan_unaware.sh with IFF_UNICAST_FLT Make sure that h1 and h2 don't drop packets with a random MAC DA, which otherwise confuses these selftests. Also, fix an incorrect error message found during those failures. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2022-07-05selftests: forwarding: fix error message in learning_testVladimir Oltean1-1/+1
When packets are not received, they aren't received on $host1_if, so the message talking about the second host not receiving them is incorrect. Fix it. Fixes: d4deb01467ec ("selftests: forwarding: Add a test for FDB learning") Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2022-07-05selftests: forwarding: fix learning_test when h1 supports IFF_UNICAST_FLTVladimir Oltean1-0/+2
The first host interface has by default no interest in receiving packets MAC DA de:ad:be:ef:13:37, so it might drop them before they hit the tc filter and this might confuse the selftest. Enable promiscuous mode such that the filter properly counts received packets. Fixes: d4deb01467ec ("selftests: forwarding: Add a test for FDB learning") Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Tested-by: Ido Schimmel <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2022-07-05selftests: forwarding: fix flood_unicast_test when h2 supports IFF_UNICAST_FLTVladimir Oltean1-0/+2
As mentioned in the blamed commit, flood_unicast_test() works by checking the match count on a tc filter placed on the receiving interface. But the second host interface (host2_if) has no interest in receiving a packet with MAC DA de:ad:be:ef:13:37, so its RX filter drops it even before the ingress tc filter gets to be executed. So we will incorrectly get the message "Packet was not flooded when should", when in fact, the packet was flooded as expected but dropped due to an unrelated reason, at some other layer on the receiving side. Force h2 to accept this packet by temporarily placing it in promiscuous mode. Alternatively we could either deliver to its MAC address or use tcpdump_start, but this has the fewest complications. This fixes the "flooding" test from bridge_vlan_aware.sh and bridge_vlan_unaware.sh, which calls flood_test from the lib. Fixes: 236dd50bf67a ("selftests: forwarding: Add a test for flooded traffic") Signed-off-by: Vladimir Oltean <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Tested-by: Ido Schimmel <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2022-07-04Merge tag 'linux-can-fixes-for-5.19-20220704' of ↵Jakub Kicinski12-216/+304
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== can 2022-07-04 The 1st patch is by Oliver Hartkopp, targets the BCM CAN protocol and converts a costly synchronize_rcu() to call_rcu() to fix a performance regression. Srinivas Neeli's patch for the xilinx_can driver drops the brp limit down to 1, as only the pre-production silicon have an issue with a brp of 1. The next patch is by Duy Nguyen and fixes the data transmission on R-Car V3U SoCs in the rcar_canfd driver. Rhett Aultman's patch fixes a DMA memory leak in the gs_usb driver. Liang He's patch removes an extra of_node_get() in the grcan driver. The next 2 patches are by me, target the m_can driver and fix the timestamp handling used for peripheral devices like the tcan4x5x. Jimmy Assarsson contributes 3 patches for the kvaser_usb driver and fixes CAN clock and bit timing related issues. The remaining 5 patches target the mcp251xfd driver. Thomas Kopp contributes 2 patches to improve the workaround for broken CRC when reading the TBC register. 3 patches by me add a missing hrtimer_cancel() during the ndo_stop() callback, and fix the reading of the Device ID register. * tag 'linux-can-fixes-for-5.19-20220704' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: mcp251xfd: mcp251xfd_register_get_dev_id(): fix endianness conversion can: mcp251xfd: mcp251xfd_register_get_dev_id(): use correct length to read dev_id can: mcp251xfd: mcp251xfd_stop(): add missing hrtimer_cancel() can: mcp251xfd: mcp251xfd_regmap_crc_read(): update workaround broken CRC on TBC register can: mcp251xfd: mcp251xfd_regmap_crc_read(): improve workaround handling for mcp2517fd can: kvaser_usb: kvaser_usb_leaf: fix bittiming limits can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency regression can: kvaser_usb: replace run-time checks with struct kvaser_usb_driver_info can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp to full 32 bits can: m_can: m_can_chip_config(): actually enable internal timestamping can: grcan: grcan_probe(): remove extra of_node_get() can: gs_usb: gs_usb_open/close(): fix memory leak can: rcar_canfd: Fix data transmission failed on R-Car V3U Revert "can: xilinx_can: Limit CANFD brp to 2" can: bcm: use call_rcu() instead of costly synchronize_rcu() ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-07-04Merge tag 'soc-fixes-5.19-2' of ↵Linus Torvalds33-188/+300
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "Another set of minor patches for Arm DTS files and soc specific drivers: - More reference counting bug fixes for DT nodes, and other trivial code fixes - Multiple code fixes for the Arm SCMI firmware driver to improve compatibility with firmware implementations. - A patch series for at91 to address power management issues from using the wrong DT compatible properties. - A series of patches to fix pad settings for NXP imx8mp to leave the configuration untouched from the boot loader - Additional DT fixes for qualcomm and NXP platforms - A boot time fix for stm32mp15 DT - Konrad Dybcio becomes an additional reviewer for the Qualcomm platforms" * tag 'soc-fixes-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (42 commits) soc: qcom: smem: use correct format characters ARM: dts: stm32: add missing usbh clock and fix clk order on stm32mp15 ARM: dts: stm32: delete fixed clock node on STM32MP15-SCMI ARM: dts: stm32: DSI should use LSE SCMI clock on DK1/ED1 STM32 board ARM: dts: stm32: use the correct clock source for CEC on stm32mp151 ARM: dts: stm32: fix pwr regulators references to use scmi soc: ixp4xx/npe: Fix unused match warning ARM: at91: pm: Mark at91_pm_secure_init as __init ARM: at91: fix soc detection for SAM9X60 SiPs ARM: dts: at91: sama5d2_icp: fix eeprom compatibles ARM: dts: at91: sam9x60ek: fix eeprom compatible and size ARM: at91: pm: use proper compatibles for sama7g5's rtc and rtt ARM: at91: pm: use proper compatibles for sam9x60's rtc and rtt ARM: at91: pm: use proper compatible for sama5d2's rtc arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo firmware: arm_scmi: Remove usage of the deprecated ida_simple_xxx API firmware: arm_scmi: Fix response size warning for OPTEE transport arm64: dts: imx8mp-icore-mx8mp-edim2.2: correct pad settings arm64: dts: imx8mp-phyboard-pollux-rdk: correct i2c2 & mmc settings arm64: dts: imx8mp-phyboard-pollux-rdk: correct eqos pad settings ...
2022-07-04Merge tag 'stm32-dt-for-v5.19-fixes-2' of ↵Arnd Bergmann6-3/+71
git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32 into arm/fixes STM32 DT fixes for v5.19, round 2 Highlights: ----------- -Fixes STM32MP15: - Add missing usbh clock and fix clk order for usbh to avoid PLL issue. - Fix SCMI version: use scmi regulator and update missing SCMI clocks to be able to correcly boot. * tag 'stm32-dt-for-v5.19-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32: ARM: dts: stm32: add missing usbh clock and fix clk order on stm32mp15 ARM: dts: stm32: delete fixed clock node on STM32MP15-SCMI ARM: dts: stm32: DSI should use LSE SCMI clock on DK1/ED1 STM32 board ARM: dts: stm32: use the correct clock source for CEC on stm32mp151 ARM: dts: stm32: fix pwr regulators references to use scmi Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2022-07-04soc: qcom: smem: use correct format charactersBill Wendling1-3/+3
When compiling with -Wformat, clang emits the following warnings: drivers/soc/qcom/smem.c:847:41: warning: format specifies type 'unsigned short' but the argument has type 'unsigned int' [-Wformat] dev_err(smem->dev, "bad host %hu\n", remote_host); ~~~ ^~~~~~~~~~~ %u ./include/linux/dev_printk.h:144:65: note: expanded from macro 'dev_err' dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__) ~~~ ^~~~~~~~~~~ ./include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap' _p_func(dev, fmt, ##__VA_ARGS__); \ ~~~ ^~~~~~~~~~~ drivers/soc/qcom/smem.c:852:47: warning: format specifies type 'unsigned short' but the argument has type 'unsigned int' [-Wformat] dev_err(smem->dev, "duplicate host %hu\n", remote_host); ~~~ ^~~~~~~~~~~ %u ./include/linux/dev_printk.h:144:65: note: expanded from macro 'dev_err' dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), ##__VA_ARGS__) ~~~ ^~~~~~~~~~~ ./include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap' _p_func(dev, fmt, ##__VA_ARGS__); \ ~~~ ^~~~~~~~~~~ The types of these arguments are unconditionally defined, so this patch updates the format character to the correct one and change type of remote_host to "u16" to match with other types. Signed-off-by: Bill Wendling <[email protected]> Tested-by: Justin Stitt <[email protected]> Reviewed-by: Justin Stitt <[email protected]> Link: https://github.com/ClangBuiltLinux/linux/issues/378 Signed-off-by: Arnd Bergmann <[email protected]>
2022-07-04Merge tag 'asoc-fix-v5.19-rc3' of ↵Takashi Iwai12984-253772/+1031855
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.19 A collection of fixes for v5.19, quite large but nothing major - a good chunk of it is more stuff that was identified by mixer-test regarding event generation.
2022-07-04ALSA: usb-audio: Add quirk for Fiero SC-01 (fw v1.0.0)Egor Vorontsov2-0/+136
The patch applies the same quirks used for SC-01 at firmware v1.1.0 to the ones running v1.0.0, with respect to hard-coded sample rates. I got two more units and successfully tested the patch series with both firmwares. The support is now complete (not accounting ASIO). Signed-off-by: Egor Vorontsov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2022-07-04ALSA: usb-audio: Add quirk for Fiero SC-01Egor Vorontsov2-0/+70
Fiero SC-01 is a USB sound card with two mono inputs and a single stereo output. The inputs are composed into a single stereo stream. The device uses a vendor-provided driver on Windows and does not work at all without it. The driver mostly provides ASIO functionality, but also alters the way the sound card is queried for sample rates and clocks. ALSA queries those failing with an EPIPE (same as Windows 10 does). Presumably, the vendor-provided driver does not query it at all, simply matching by VID:PID. Thus, I consider this a buggy firmware and adhere to a set of fixed endpoint quirks instead. The soundcard has an internal clock. Implicit feedback mode is required for the playback. I have updated my device to v1.1.0 from a Windows 10 VM using a vendor- provided binary prior to the development, hoping for it to just begin working. The device provides no obvious way to downgrade the firmware, and regardless, there's no binary available for v1.0.0 anyway. Thus, I will be getting another unit to extend the patch with support for that. Expected to be a simple copy-paste of the existing one, though. There were no previous reports of that device in context of Linux anywhere. Other issues have been reported though, but that's out of the scope. Signed-off-by: Egor Vorontsov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2022-07-04ALSA: hda/realtek: Add quirk for Clevo L140PUTim Crawford1-0/+1
Fixes headset detection on Clevo L140PU. Signed-off-by: Tim Crawford <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2022-07-04ALSA: usb-audio: Add quirks for MacroSilicon MS2100/MS2106 devicesJohn Veness2-0/+51
Treat the claimed 96kHz 1ch in the descriptors as 48kHz 2ch, so that the audio stream doesn't sound mono. Also fix initial stream alignment, so that left and right channels are in the correct order. Signed-off-by: John Veness <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2022-07-04powerpc/powernv: delay rng platform device creation until later in bootJason A. Donenfeld1-6/+10
The platform device for the rng must be created much later in boot. Otherwise it tries to connect to a parent that doesn't yet exist, resulting in this splat: [ 0.000478] kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_get() is being called. [ 0.002925] [c000000002a0fb30] [c00000000073b0bc] kobject_get+0x8c/0x100 (unreliable) [ 0.003071] [c000000002a0fba0] [c00000000087e464] device_add+0xf4/0xb00 [ 0.003194] [c000000002a0fc80] [c000000000a7f6e4] of_device_add+0x64/0x80 [ 0.003321] [c000000002a0fcb0] [c000000000a800d0] of_platform_device_create_pdata+0xd0/0x1b0 [ 0.003476] [c000000002a0fd00] [c00000000201fa44] pnv_get_random_long_early+0x240/0x2e4 [ 0.003623] [c000000002a0fe20] [c000000002060c38] random_init+0xc0/0x214 This patch fixes the issue by doing the platform device creation inside of machine_subsys_initcall. Fixes: f3eac426657d ("powerpc/powernv: wire up rng during setup_arch") Cc: [email protected] Reported-by: Sachin Sant <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]> Tested-by: Sachin Sant <[email protected]> [mpe: Change "of node" to "platform device" in change log] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.