summaryrefslogtreecommitdiffstats
path: root/drivers/firmware/arm_scmi/virtio.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* firmware: arm_scmi: Use dedicated devices to initialize channelsCristian Marussi2023-01-191-2/+0
| | | | | | | | | | | | | Refactor channels initialization to use dedicated transport devices instead of using devices borrowed from the SCMI drivers. Initialize all channels, as described in the device tree, upfront during SCMI core stack probe phase and free all of them, including the underlying devices, when the SCMI core is removed. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Simplify chan_available transport operationCristian Marussi2023-01-191-1/+1
| | | | | | | | | | | | | | | SCMI transport operation .chan_available determines in a transport specific way if an SCMI channel is still available and to be configured. Such information is derived by analyzing bits of device node in a transport specific way, all it needs is a device node to operate up on, not necessarily a full blown device. Simplify the helper to receive in input a reference to a device_node instead of a device carrying a pointer to such device_node. Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222185049.737625-2-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Fix virtio channels cleanup on shutdownCristian Marussi2023-01-031-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When unloading the SCMI core stack module, configured to use the virtio SCMI transport, LOCKDEP reports the splat down below about unsafe locks dependencies. In order to avoid this possible unsafe locking scenario call upfront virtio_break_device() before getting hold of vioch->lock. ===================================================== WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected 6.1.0-00067-g6b934395ba07-dirty #4 Not tainted ----------------------------------------------------- rmmod/307 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: ffff000080c510e0 (&dev->vqs_list_lock){+.+.}-{3:3}, at: virtio_break_device+0x28/0x68 and this task is already holding: ffff00008288ada0 (&channels[i].lock){-.-.}-{3:3}, at: virtio_chan_free+0x60/0x168 [scmi_module] which would create a new lock dependency: (&channels[i].lock){-.-.}-{3:3} -> (&dev->vqs_list_lock){+.+.}-{3:3} but this new dependency connects a HARDIRQ-irq-safe lock: (&channels[i].lock){-.-.}-{3:3} ... which became HARDIRQ-irq-safe at: lock_acquire+0x128/0x398 _raw_spin_lock_irqsave+0x78/0x140 scmi_vio_complete_cb+0xb4/0x3b8 [scmi_module] vring_interrupt+0x84/0x120 vm_interrupt+0x94/0xe8 __handle_irq_event_percpu+0xb4/0x3d8 handle_irq_event_percpu+0x20/0x68 handle_irq_event+0x50/0xb0 handle_fasteoi_irq+0xac/0x138 generic_handle_domain_irq+0x34/0x50 gic_handle_irq+0xa0/0xd8 call_on_irq_stack+0x2c/0x54 do_interrupt_handler+0x8c/0x90 el1_interrupt+0x40/0x78 el1h_64_irq_handler+0x18/0x28 el1h_64_irq+0x64/0x68 _raw_write_unlock_irq+0x48/0x80 ep_start_scan+0xf0/0x128 do_epoll_wait+0x390/0x858 do_compat_epoll_pwait.part.34+0x1c/0xb8 __arm64_sys_epoll_pwait+0x80/0xd0 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.3+0x98/0x120 do_el0_svc+0x34/0xd0 el0_svc+0x40/0x98 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174 to a HARDIRQ-irq-unsafe lock: (&dev->vqs_list_lock){+.+.}-{3:3} ... which became HARDIRQ-irq-unsafe at: ... lock_acquire+0x128/0x398 _raw_spin_lock+0x58/0x70 __vring_new_virtqueue+0x130/0x1c0 vring_create_virtqueue+0xc4/0x2b8 vm_find_vqs+0x20c/0x430 init_vq+0x308/0x390 virtblk_probe+0x114/0x9b0 virtio_dev_probe+0x1a4/0x248 really_probe+0xc8/0x3a8 __driver_probe_device+0x84/0x190 driver_probe_device+0x44/0x110 __driver_attach+0x104/0x1e8 bus_for_each_dev+0x7c/0xd0 driver_attach+0x2c/0x38 bus_add_driver+0x1e4/0x258 driver_register+0x6c/0x128 register_virtio_driver+0x2c/0x48 virtio_blk_init+0x70/0xac do_one_initcall+0x84/0x420 kernel_init_freeable+0x2d0/0x340 kernel_init+0x2c/0x138 ret_from_fork+0x10/0x20 other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->vqs_list_lock); local_irq_disable(); lock(&channels[i].lock); lock(&dev->vqs_list_lock); <Interrupt> lock(&channels[i].lock); *** DEADLOCK *** ================ Fixes: 42e90eb53bf3f ("firmware: arm_scmi: Add a virtio channel refcount") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221222183823.518856-6-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Fix deferred_tx_wq release on error pathsCristian Marussi2022-11-011-7/+13
| | | | | | | | | | | Use devres to allocate the dedicated deferred_tx_wq polling workqueue so as to automatically trigger the proper resource release on error path. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 5a3b7185c47c ("firmware: arm_scmi: Add atomic mode support to virtio transport") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221028140833.280091-6-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Fix devres allocation device in virtio transportCristian Marussi2022-11-011-3/+3
| | | | | | | | | | | SCMI virtio transport device managed allocations must use the main platform device in devres operations instead of the channel devices. Cc: Peter Hilber <peter.hilber@opensynergy.com> Fixes: 46abe13b5e3d ("firmware: arm_scmi: Add virtio transport") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Link: https://lore.kernel.org/r/20221028140833.280091-5-cristian.marussi@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add atomic mode support to virtio transportCristian Marussi2022-02-211-18/+372
| | | | | | | | | | | | | | | | | Add support for .mark_txdone and .poll_done transport operations to SCMI VirtIO transport as pre-requisites to enable atomic operations. Add a Kernel configuration option to enable SCMI VirtIO transport polling and atomic mode for selected SCMI transactions while leaving it default disabled. Link: https://lore.kernel.org/r/20220217131234.50328-4-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Skalkin <igor.skalkin@opensynergy.com> Cc: Peter Hilber <peter.hilber@opensynergy.com> Cc: virtualization@lists.linux-foundation.org Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Review virtio free_list handlingCristian Marussi2022-02-211-31/+57
| | | | | | | | | | | | | Add a new spinlock dedicated to the access of the TX free list and a couple of helpers to get and put messages back and forth from the free_list. Link: https://lore.kernel.org/r/20220217131234.50328-3-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Skalkin <igor.skalkin@opensynergy.com> Cc: Peter Hilber <peter.hilber@opensynergy.com> Cc: virtualization@lists.linux-foundation.org Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add a virtio channel refcountCristian Marussi2022-02-211-51/+92
| | | | | | | | | | | | | | | | | | | | | | Currently SCMI VirtIO channels are marked with a ready flag and related lock to track channel lifetime and support proper synchronization at shutdown when virtqueues have to be stopped. This leads to some extended spinlocked sections with IRQs off on the RX path to keep hold of the ready flag and does not scale well especially when SCMI VirtIO polling mode will be introduced. Add an SCMI VirtIO channel dedicated refcount to track active users on both the TX and the RX path and properly enforce synchronization and cleanup at shutdown, inhibiting further usage of the channel once freed. Link: https://lore.kernel.org/r/20220217131234.50328-2-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Igor Skalkin <igor.skalkin@opensynergy.com> Cc: Peter Hilber <peter.hilber@opensynergy.com> Cc: virtualization@lists.linux-foundation.org Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* Merge tag 'scmi-updates-5.17' of ↵Sudeep Holla2022-02-071-11/+11
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into for-next/scmi Arm SCMI firmware interface updates for v5.17 Couple of main additions: - Support for OPTEE based SCMI transport to enable using SCMI service provided by OPTEE on some platforms - Support for atomic SCMI transports which enables few SCMI transactions to be completed in atomic context. This involves other refactoring work associated with it. It also marks SMC and OPTEE as atomic transport as the commands are completed once the return Other changes involves some trace and log enhancements and a miscellaneous bug fix. * tag 'scmi-updates-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: firmware: arm_scmi: Add new parameter to mark_txdone firmware: arm_scmi: Add atomic mode support to smc transport firmware: arm_scmi: Add support for atomic transports firmware: arm_scmi: Make optee support sync_cmds_completed_on_ret firmware: arm_scmi: Make smc support sync_cmds_completed_on_ret firmware: arm_scmi: Add sync_cmds_completed_on_ret transport flag firmware: arm_scmi: Make smc transport use common completions firmware: arm_scmi: Add configurable polling mode for transports firmware: arm_scmi: Use new trace event scmi_xfer_response_wait include: trace: Add new scmi_xfer_response_wait event firmware: arm_scmi: Refactor message response path firmware: arm_scmi: Set polling timeout to max_rx_timeout_ms firmware: arm_scmi: Perform earlier cinfo lookup call in do_xfer firmware: arm_scmi: optee: Drop the support for the OPTEE shared dynamic buffer firmware: arm_scmi: optee: Fix missing mutex_init() firmware: arm_scmi: Make virtio Version_1 compliance optional firmware: arm_scmi: Add optee transport dt-bindings: arm: Add OP-TEE transport for SCMI firmware: arm_scmi: Review some virtio log messages
| * firmware: arm_scmi: Make virtio Version_1 compliance optionalCristian Marussi2021-11-171-1/+2
| | | | | | | | | | | | | | | | | | | | Introduce a compilation option to disable strict enforcement of compliance against VirtIO Version_1 backends, so as to allow to support also Legacy VirtIO devices implementations. Link: https://lore.kernel.org/r/20211115102910.7639-1-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
| * firmware: arm_scmi: Review some virtio log messagesCristian Marussi2021-11-171-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | Be more verbose avoiding to use _once flavour of dev_info/_err/_notice. Remove usage of __func_ to identify which vqueue is referred in some error messages and explicitly name the TX/RX vqueue. Link: https://lore.kernel.org/r/20210916103336.7243-1-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* | virtio: wrap config->reset callsMichael S. Tsirkin2022-01-151-1/+1
|/ | | | | | | | | | | This will enable cleanups down the road. The idea is to disable cbs, then add "flush_queued_cbs" callback as a parameter, this way drivers can flush any work queued after callbacks have been disabled. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/r/20211013105226.20225-1-mst@redhat.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
* firmware: arm_scmi: Fix null de-reference on error pathCristian Marussi2021-11-151-5/+5
| | | | | | | | | | | | | During channel setup a failure in the call of scmi_vio_feed_vq_rx() leads to an attempt to access a dev pointer by dereferencing vioch->cinfo at a time when vioch->cinfo has still to be initialized. Fix it by providing the device reference directly to scmi_vio_feed_vq_rx. Link: https://lore.kernel.org/r/20211112180705.41601-1-cristian.marussi@arm.com Fixes: 46abe13b5e3db ("firmware: arm_scmi: Add virtio transport") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add proper barriers to scmi virtio deviceCristian Marussi2021-10-061-4/+9
| | | | | | | | | | | | | | | | | | | Only one single SCMI Virtio device is currently supported by this driver and it is referenced using a static global variable which is initialized once for all during probing and nullified at virtio device removal. Add proper SMP barriers to protect accesses to such device reference to ensure that the initialzation state of such device is correctly observed by all PEs at any time. Return -EBUSY, instead of -EINVAL, and a descriptive error message if more than one SCMI Virtio device is ever found and probed. Link: https://lore.kernel.org/r/20210916103336.7243-3-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Simplify spinlocks in virtio transportCristian Marussi2021-10-061-8/+21
| | | | | | | | | | | | Remove unneeded nested irqsave/irqrestore spinlocks. Add also a few descriptive comments to explain better the system behaviour at shutdown time. Link: https://lore.kernel.org/r/20210916103336.7243-2-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Remove __exit annotationArnd Bergmann2021-09-201-1/+1
| | | | | | | | | | | | | | | | | virtio_scmi_exit() is only called from __exit function, so the annotation is correct, but when the driver is built-in, the section gets discarded and the reference from a callback pointer causes a link-time error: `virtio_scmi_exit' referenced in section `.rodata' of drivers/firmware/arm_scmi/virtio.o: defined in discarded section `.exit.text' of drivers/firmware/arm_scmi/virtio.o I could not figure out a better workaround, so let's just remove that annotation even if it wastes a couple of bytes in .text. Link: https://lore.kernel.org/r/20210920100301.1466486-2-arnd@kernel.org Fixes: 46abe13b5e3d ("firmware: arm_scmi: Add virtio transport") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Fix boolconv.cocci warningskernel test robot2021-08-091-1/+1
| | | | | | | | | | | | | | | | | | drivers/firmware/arm_scmi/virtio.c:225:40-45: WARNING: conversion to bool not needed here Remove unneeded conversion to bool Semantic patch information: Relational and logical operators evaluate to bool, explicit conversion is overly verbose and unneeded. Generated by: scripts/coccinelle/misc/boolconv.cocci Link: https://lore.kernel.org/r/20210807173127.GA43248@a24dbc127934 CC: Igor Skalkin <igor.skalkin@opensynergy.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
* firmware: arm_scmi: Add virtio transportIgor Skalkin2021-08-051-0/+491
This transport enables communications with an SCMI platform through virtio; the SCMI platform will be represented by a virtio device. Implement an SCMI virtio driver according to the virtio SCMI device spec [1]. Virtio device id 32 has been reserved for the SCMI device [2]. The virtio transport has one Tx channel (virtio cmdq, A2P channel) and at most one Rx channel (virtio eventq, P2A channel). The following feature bit defined in [1] is not implemented: VIRTIO_SCMI_F_SHARED_MEMORY. The number of messages which can be pending simultaneously is restricted according to the virtqueue capacity negotiated at probing time. As soon as Rx channel message buffers are allocated or have been read out by the arm-scmi driver, feed them back to the virtio device. Since some virtio devices may not have the short response time exhibited by SCMI platforms using other transports, set a generous response timeout. SCMI polling mode is not supported by this virtio transport since deemed meaningless: polling mode operation is offered by the SCMI core to those transports that could not provide a completion interrupt on the TX path, which is never the case for virtio whose core callbacks can easily call into core scmi_rx_callback upon messages reception. [1] https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-scmi.tex [2] https://www.oasis-open.org/committees/ballot.php?id=3496 Link: https://lore.kernel.org/r/20210803131024.40280-16-cristian.marussi@arm.com Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com> Co-developed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com> [ Peter: Adapted patch for submission to upstream. ] Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com> [ Cristian: simplified driver logic, changed link_supplier and channel available/setup logic, removed dummy callbacks ] Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-30 16:12:37 +0100