| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When more than a single SCMI device are present in the system, the
creation of the notification workqueue with the WQ_SYSFS flag will lead
to the following sysfs duplicate node warning:
sysfs: cannot create duplicate filename '/devices/virtual/workqueue/scmi_notify'
CPU: 0 PID: 20 Comm: kworker/0:1 Not tainted 5.9.0-gdf4dd84a3f7d #29
Hardware name: Broadcom STB (Flattened Device Tree)
Workqueue: events deferred_probe_work_func
Backtrace:
show_stack + 0x20/0x24
dump_stack + 0xbc/0xe0
sysfs_warn_dup + 0x70/0x80
sysfs_create_dir_ns + 0x15c/0x1a4
kobject_add_internal + 0x140/0x4d0
kobject_add + 0xc8/0x138
device_add + 0x1dc/0xc20
device_register + 0x24/0x28
workqueue_sysfs_register + 0xe4/0x1f0
alloc_workqueue + 0x448/0x6ac
scmi_notification_init + 0x78/0x1dc
scmi_probe + 0x268/0x4fc
platform_drv_probe + 0x70/0xc8
really_probe + 0x184/0x728
driver_probe_device + 0xa4/0x278
__device_attach_driver + 0xe8/0x148
bus_for_each_drv + 0x108/0x158
__device_attach + 0x190/0x234
device_initial_probe + 0x1c/0x20
bus_probe_device + 0xdc/0xec
deferred_probe_work_func + 0xd4/0x11c
process_one_work + 0x420/0x8f0
worker_thread + 0x4fc/0x91c
kthread + 0x21c/0x22c
ret_from_fork + 0x14/0x20
kobject_add_internal failed for scmi_notify with -EEXIST, don't try to
register things with the same name in the same directory.
arm-scmi brcm_scmi@1: SCMI Notifications - Initialization Failed.
arm-scmi brcm_scmi@1: SCMI Notifications NOT available.
arm-scmi brcm_scmi@1: SCMI Protocol v1.0 'brcm-scmi:' Firmware version 0x1
Fix this by using dev_name(handle->dev) which guarantees that the name is
unique and this also helps correlate which notification workqueue corresponds
to which SCMI device instance.
Link: https://lore.kernel.org/r/20201014021737.287340-1-f.fainelli@gmail.com
Fixes: bd31b249692e ("firmware: arm_scmi: Add notification dispatch and delivery")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
[sudeep.holla: trimmed backtrace to remove all unwanted hexcodes and timestamps]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
When a protocol registers its events, the notification core takes care
to rescan the hashtable of pending event handlers and activate all the
possibly existent handlers referring to any of the events that are just
registered by the new protocol. When a pending handler becomes active
the core requests and enables the corresponding events in the SCMI
firmware.
If, for whatever reason, the enable fails, such invalid event handler
must be finally removed and freed. Let us ensure to use the
scmi_put_active_handler() helper which handles properly the needed
additional locking.
Failing to properly acquire all the needed mutexes exposes a race that
leads to the following splat being observed:
WARNING: CPU: 0 PID: 388 at lib/refcount.c:28 refcount_warn_saturate+0xf8/0x148
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development
Platform, BIOS EDK II Jun 30 2020
pstate: 40000005 (nZcv daif -PAN -UAO BTYPE=--)
pc : refcount_warn_saturate+0xf8/0x148
lr : refcount_warn_saturate+0xf8/0x148
Call trace:
refcount_warn_saturate+0xf8/0x148
scmi_put_handler_unlocked.isra.10+0x204/0x208
scmi_put_handler+0x50/0xa0
scmi_unregister_notifier+0x1bc/0x240
scmi_notify_tester_remove+0x4c/0x68 [dummy_scmi_consumer]
scmi_dev_remove+0x54/0x68
device_release_driver_internal+0x114/0x1e8
driver_detach+0x58/0xe8
bus_remove_driver+0x88/0xe0
driver_unregister+0x38/0x68
scmi_driver_unregister+0x1c/0x28
scmi_drv_exit+0x1c/0xae0 [dummy_scmi_consumer]
__arm64_sys_delete_module+0x1a4/0x268
el0_svc_common.constprop.3+0x94/0x178
do_el0_svc+0x2c/0x98
el0_sync_handler+0x148/0x1a8
el0_sync+0x158/0x180
Link: https://lore.kernel.org/r/20201013133109.49821-1-cristian.marussi@arm.com
Fixes: e7c215f358a35 ("firmware: arm_scmi: Add notification callbacks-registration")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Few commands provide the list of description partially and require
to be called consecutively until all the descriptors are fetched
completely. In such cases, we don't release the buffers and reuse
them for consecutive transmits.
However, currently we don't reset the Rx size which will be set as
per the response for the last transmit. This may result in incorrect
response size being interpretted as the firmware may repond with size
greater than the one set but we read only upto the size set by previous
response.
Let us reset the receive buffer size to max possible in such cases as
we don't know the exact size of the response.
Link: https://lore.kernel.org/r/20201012141746.32575-1-sudeep.holla@arm.com
Fixes: b6f20ff8bd94 ("firmware: arm_scmi: add common infrastructure and support for base protocol")
Reported-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
SMC/HVC can transmit only one message at the time as the shared memory
needs to be protected and the calls are synchronous.
However, in order to allow multiple threads to send SCMI messages
simultaneously, we need a larger poll of memory.
Let us just use value of 20 to keep it in sync mailbox transport
implementation. Any other value must work perfectly.
Link: https://lore.kernel.org/r/20201008143722.21888-4-etienne.carriere@linaro.org
Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport")
Cc: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
[sudeep.holla: reworded the commit message to indicate the practicality]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
The defination for ARCH_COLD_RESET is wrong. Let us fix it according to
the SCMI specification.
Link: https://lore.kernel.org/r/20201008143722.21888-5-etienne.carriere@linaro.org
Fixes: 95a15d80aa0d ("firmware: arm_scmi: Add RESET protocol in SCMI v2.0")
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Now, with all the plumbing in place to enable building scmi as a module
instead of built-in modules, let us enable the same.
Link: https://lore.kernel.org/r/20200907195046.56615-5-sudeep.holla@arm.com
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
In preparation to enable building SCMI as a single module, let us move
the SCMI protocol registration call into the driver. This enables us
to also add unregistration of the SCMI protocols.
The main reason for this is to keep it simple instead of maintaining
it as separate modules and dealing with all possible initcall races
and deferred probe handling. We can move it as separate modules if
needed in future.
Link: https://lore.kernel.org/r/20200907195046.56615-4-sudeep.holla@arm.com
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
In preparation to enable building scmi as a single module, let us move
the scmi bus {de-,}initialisation call into the driver.
The main reason for this is to keep it simple instead of maintaining
it as separate modules and dealing with all possible initcall races
and deferred probe handling. We can move it as separate modules if
needed in future.
Link: https://lore.kernel.org/r/20200907195046.56615-3-sudeep.holla@arm.com
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
scmi_mailbox is obtained from cinfo->transport_info and the first
call to mailbox_chan_free frees the channel and sets cinfo->transport_info
to NULL. Care is taken to check for non NULL smbox->chan but smbox can
itself be NULL. Fix it by checking for it without which, kernel crashes
with below NULL pointer dereference and eventually kernel panic.
Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000038
Modules linked in: scmi_module(-)
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno
Development Platform, BIOS EDK II Sep 2 2020
pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--)
pc : mailbox_chan_free+0x2c/0x70 [scmi_module]
lr : idr_for_each+0x6c/0xf8
Call trace:
mailbox_chan_free+0x2c/0x70 [scmi_module]
idr_for_each+0x6c/0xf8
scmi_remove+0xa8/0xf0 [scmi_module]
platform_drv_remove+0x34/0x58
device_release_driver_internal+0x118/0x1f0
driver_detach+0x58/0xe8
bus_remove_driver+0x64/0xe0
driver_unregister+0x38/0x68
platform_driver_unregister+0x1c/0x28
scmi_driver_exit+0x38/0x44 [scmi_module]
---[ end trace 17bde19f50436de9 ]---
Kernel panic - not syncing: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: 0x1d0000 from 0xffff800010000000
PHYS_OFFSET: 0x80000000
CPU features: 0x0240022,25806004
Memory Limit: none
---[ end Kernel panic - not syncing: Fatal exception ]---
Link: https://lore.kernel.org/r/20200908112611.31515-1-sudeep.holla@arm.com
Fixes: 5c8a47a5a91d ("firmware: arm_scmi: Make scmi core independent of the transport type")
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add SCMI device for system power protocol by just adding the name "syspower"
to the list of supported core protocol devices.
Link: https://lore.kernel.org/r/20200907174657.32466-3-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add bare protocol support for SCMI system power protocol as needed by
an OSPM agent: basic initialization and SYSTEM_POWER_STATE_NOTIFIER
core notification support.
No event-handling logic is attached to such notification..
Link: https://lore.kernel.org/r/20200907174657.32466-2-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
These are never modified, so make them const to allow the compiler to
put them in read-only memory.
Link: https://lore.kernel.org/r/20200906230452.33410-4-rikard.falkeborn@gmail.com
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Kbuild test robot reports the following sparse warning:
drivers/firmware/arm_scmi/clock.c:142:21:
sparse: Using plain integer as NULL pointer
Use NULL pointer instead of integer 0 for rate pointer and fix the
warning.
Link: https://lore.kernel.org/r/20200717140405.17905-1-sudeep.holla@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Event reports are used to convey information describing events to the
registered user-callbacks: they are necessarily derived from the underlying
raw SCMI events' messages but they are not meant to expose or directly
mirror any of those messages data layout, which belong to the protocol
layer.
Using fixed size types for report fields, mirroring messages structure,
is at odd with this: get rid of them using more generic, equivalent,
typing.
Substitute scmi_event_header fixed size fields with generic types too and
shuffle around fields definitions to minimize implicit padding while
adapting involved functions.
Link: https://lore.kernel.org/r/20200710133919.39792-3-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Remove __packed attribute from struct scmi_event_header.
Link: https://lore.kernel.org/r/20200710133919.39792-2-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
gcc as well as clang now produce warnings for missing kerneldoc function
parameter.
Fix the following W=1 kernel build warning:
drivers/firmware/arm_scmi/smc.c:32:
warning: Function parameter or member 'shmem_lock' not described in 'scmi_smc'
Link: https://lore.kernel.org/r/20200709153155.22573-1-sudeep.holla@arm.com
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Instead of relying on the firmware to keep the clock rates sorted, let
us sort the list. This is not essential for clock layer but it helps
to find the min and max rates easily from the list.
Link: https://lore.kernel.org/r/20200709081705.46084-1-sudeep.holla@arm.com
Fixes: 5f6c6430e904 ("firmware: arm_scmi: add initial support for clock protocol")
Reported-and-tested-by: Dien Pham <dien.pham.ry@renesas.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Make SCMI base protocol register with the notification core.
Link: https://lore.kernel.org/r/20200701155348.52864-10-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Make SCMI reset protocol register with the notification core.
Link: https://lore.kernel.org/r/20200701155348.52864-9-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Make SCMI sensor protocol register with the notification core.
Link: https://lore.kernel.org/r/20200701155348.52864-8-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Make SCMI perf protocol register with the notification core.
Link: https://lore.kernel.org/r/20200701155348.52864-7-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Make SCMI power protocol register with the notification core.
Link: https://lore.kernel.org/r/20200701155348.52864-6-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Initialize and enable SCMI notifications core support during bus/driver
probe phase, so that protocols can start registering their supported
events during their initialization.
Link: https://lore.kernel.org/r/20200701155348.52864-5-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add the core SCMI notifications dispatch and delivery support logic
which is able to dispatch well-known received events from the Rx
interrupt handler to the dedicated deferred worker. From there, it will
deliver the events to the registered users' callbacks.
Dispatch and delivery support is just added here, still not enabled.
Link: https://lore.kernel.org/r/20200701155348.52864-4-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add the core SCMI notifications callbacks-registration support: allow
users to register their own callbacks against the desired events.
Whenever a registration request is issued against a still non existent
event, mark such request as pending for later processing, in order to
account for possible late initializations of SCMI Protocols associated
to loadable drivers.
Link: https://lore.kernel.org/r/20200701155348.52864-3-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add the core SCMI notifications protocol-registration support: allow
protocols to register their own set of supported events, during their
initialization phase. Notification core can track multiple platform
instances by their handles.
Link: https://lore.kernel.org/r/20200701155348.52864-2-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
When, at probe time, an SCMI communication failure inhibits the capacity
to query power domains states, such domains should be skipped.
Registering partially initialized SCMI power domains with genpd will
causes kernel panic.
arm-scmi timed out in resp(caller: scmi_power_state_get+0xa4/0xd0)
scmi-power-domain scmi_dev.2: failed to get state for domain 9
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Mem abort info:
ESR = 0x96000006
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000006
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=00000009f3691000
[0000000000000000] pgd=00000009f1ca0003, p4d=00000009f1ca0003, pud=00000009f35ea003, pmd=0000000000000000
Internal error: Oops: 96000006 [#1] PREEMPT SMP
CPU: 2 PID: 381 Comm: bash Not tainted 5.8.0-rc1-00011-gebd118c2cca8 #2
Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jan 3 2020
Internal error: Oops: 96000006 [#1] PREEMPT SMP
pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--)
pc : of_genpd_add_provider_onecell+0x98/0x1f8
lr : of_genpd_add_provider_onecell+0x48/0x1f8
Call trace:
of_genpd_add_provider_onecell+0x98/0x1f8
scmi_pm_domain_probe+0x174/0x1e8
scmi_dev_probe+0x90/0xe0
really_probe+0xe4/0x448
driver_probe_device+0xfc/0x168
device_driver_attach+0x7c/0x88
bind_store+0xe8/0x128
drv_attr_store+0x2c/0x40
sysfs_kf_write+0x4c/0x60
kernfs_fop_write+0x114/0x230
__vfs_write+0x24/0x50
vfs_write+0xbc/0x1e0
ksys_write+0x70/0xf8
__arm64_sys_write+0x24/0x30
el0_svc_common.constprop.3+0x94/0x160
do_el0_svc+0x2c/0x98
el0_sync_handler+0x148/0x1a8
el0_sync+0x158/0x180
Do not register any power domain that failed to be queried with genpd.
Fixes: 898216c97ed2 ("firmware: arm_scmi: add device power domain support using genpd")
Link: https://lore.kernel.org/r/20200619220330.12217-1-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Commit e5bfb21d98b6 ("firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to
identify SMCCC v1.1 and above") introduced new config option to identify
the availability of SMCCC discoverability of version and features
transparently hiding the indirect dependency on ARM_PSCI_FW.
Commit 5a897e3ab429 ("firmware: arm_scmi: fix psci dependency") just
worked around the build dependency making SCMI SMC/HVC transport depend
on ARM_PSCI_FW at the time. Since it really just relies on SMCCC directly
and not on ARM_PSCI_FW, let us move to use CONFIG_HAVE_ARM_SMCCC_DISCOVERY
instead of CONFIG_ARM_PSCI_FW.
Link: https://lore.kernel.org/r/20200625101937.51939-1-sudeep.holla@arm.com
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add a new fast_switch_possible interface to the existing perf_ops to
export the information of whether or not fast_switch is possible for a
given device.
This can be used by the cpufreq driver and framework to choose proper
mechanism for frequency change.
Link: https://lore.kernel.org/r/20200617094332.8391-1-nicola.mazzucato@arm.com
Suggested-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Currently the trace event 'scmi_xfer_end' reports the status of the
transfer using the unsigned status field read from the firmware which
may not be easy to interpret. It may also miss to emit any timeouts
that happen in the driver resulting in emitting garbage in the status
field in those scenarios.
Let us use signed integer so that error values are emitted out after
they are mapped from firmware error formats to standard linux error
codes. While at this, also include any timeouts in the driver itself.
Link: https://lore.kernel.org/r/20200609134503.55860-1-sudeep.holla@arm.com
Cc: Jim Quinlan <james.quinlan@broadcom.com>
Cc: Lukasz Luba <lukasz.luba@arm.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
When CONFIG_ARM_PSCI_FW is disabled but CONFIG_HAVE_ARM_SMCCC is enabled,
arm-scmi runs into a link failure:
arm-linux-gnueabi-ld: drivers/firmware/arm_scmi/smc.o: in function `smc_send_message':
smc.c:(.text+0x200): undefined reference to `arm_smccc_1_1_get_conduit'
Change from HAVE_ARM_SMCCC to ARM_PSCI_FW config dependency for now.
We rely on PSCI bindings anyways for the conduit and this should be
fine.
Link: https://lore.kernel.org/r/20200507144905.11397-1-sudeep.holla@arm.com
Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport")
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
SMCCC can return NOT_SUPPORTED(-1). Map it to appropriate Linux error
codes namely -EOPNOTSUPP.
Link: https://lore.kernel.org/r/20200417103232.6896-1-sudeep.holla@arm.com
Reported-and-Tested-by:: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Upon reception of an unexpected bogus delayed response, clear the channel
and bail-out safely.
Link: https://lore.kernel.org/r/20200420152315.21008-5-cristian.marussi@arm.com
Fixes: 4d09852b6f01 ("firmware: arm_scmi: Add support for notifications message processing")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Clear channel properly when done processing a delayed response.
This will let the platform firmware know that the channel is now free to
use it for any new delayed response or notification.
Link: https://lore.kernel.org/r/20200420152315.21008-4-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
(sudeep.holla: Updated commit log to reflect that channel is now free for
platform to use)
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
When an unexpected response message is received we currently warn the user
and bail-out, ensure to also free the channel by invoking the transport
independent operation .clear_channel()
Link: https://lore.kernel.org/r/20200420152315.21008-3-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
SCMI transport operation .clear_notification() is indeed a generic method
to clear the channel in a transport dependent way, as such it could be a
useful helper also in other contexts.
Rename such method as .clear_channel(), renaming accordingly also its
already existent call-sites.
No functional change.
Link: https://lore.kernel.org/r/20200420152315.21008-2-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add the mechanisms to distinguish notifications from delayed responses
and command responses. Also add support to properly fetch notification
messages upon reception. Notifications processing does not continue any
further after the fetch phase.
Link: https://lore.kernel.org/r/20200327143438.5382-5-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
[Reworked/renamed scmi_handle_xfer_delayed_resp()]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add common transport-layer methods to:
- fetch a notification instead of a response
- clear a pending notification
Add also all the needed support in mailbox/shmem transports.
Link: https://lore.kernel.org/r/20200327143438.5382-4-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Add commands' enumerations and messages definitions for all existing
notify-enable commands across all protocols.
Link: https://lore.kernel.org/r/20200327143438.5382-3-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
With all the plumbing in place, let's just add the separate dedicated
receive buffers to handle notifications that can arrive asynchronously
from the platform firmware to OS.
Also add one check to see if the platform supports any receive channels
before allocating the receive buffers: since those buffers are optionally
supported though, the whole xfer initialization is also postponed to be
able to check for their existence in advance.
Link: https://lore.kernel.org/r/20200327143438.5382-2-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
[Changed parameters in __scmi_xfer_info_init()]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
The scmi protocol core driver checks for the channel availability
before evaluating the shmem property. If the individual protocols
don't have separate channel assigned to them, the channel alloted
for the BASE protocol is reused automatically.
Therefore there is no need to check for the shmem property in the
parent node if it is absent in the child protocol node.
Link: https://lore.kernel.org/r/20200327163654.13389-5-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Instead of declaring the channel availabilty unconditionally, let us
check for the presence of "shmem" property and return the channel
availablity accordingly.
Link: https://lore.kernel.org/r/20200327163654.13389-4-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
The scmi protocol core driver check for non NULL mark_txdone before
invoking the same. There is no need to provide a empty stub. SMC/HVC
calls are synchronous and the call return indicates the completion.
Link: https://lore.kernel.org/r/20200327163654.13389-3-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
In order to support multiple SMC/HVC transport channels with associated
shared memory, it is better to maintain the mutex per channel instead of
existing global one.
Move the smc_mutex into the scmi_smc structure and also rename it to
shmem_lock which is more appropriate for it's use.
Link: https://lore.kernel.org/r/20200327163654.13389-2-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Use the value of "arm,smc-id" property from the device tree as the first
argument for SMCCC call leaving all the other arguments as zero for now.
There is no Rx, only Tx because of smc/hvc not support Rx.
Link: https://lore.kernel.org/r/1583673879-20714-3-git-send-email-peng.fan@nxp.com
Signed-off-by: Peng Fan <peng.fan@nxp.com>
[sudeep.holla: reworded commit log/subject and fixed !HAVE_ARM_SMCCC build]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Replace the zero-length member "opp" in scmi_msg_resp_perf_describe_levels
structure with flexible-array.
Link: https://lore.kernel.org/r/20200211231252.GA14830@embeddedor
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Replace the zero-length member "msg_payload" in scmi_shared_mem
structure with flexible-array.
Link: https://lore.kernel.org/r/20200211231045.GA13956@embeddedor
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
[ rebased the change as files are moved around ]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
The SCMI specification is fairly independent of the transport protocol,
which can be a simple mailbox (already implemented) or anything else.
The current Linux implementation however is very much dependent on the
mailbox transport layer.
This patch makes the SCMI core code (driver.c) independent of the
mailbox transport layer and moves all mailbox related code to a new
file: mailbox.c and all struct shared_mem related code to a new file:
shmem.c.
We can now implement more transport protocols to transport SCMI
messages.
The transport protocols just need to provide struct scmi_transport_ops,
with its version of the callbacks to enable exchange of SCMI messages.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/8698a3cec199b8feab35c2339f02dc232bfd773b.1580448239.git.viresh.kumar@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Move message header specific macros and helper routines to common.h as
they will be used outside of driver.c in a later commit.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/6615db480370719b0a0241447a5f3feb8eea421f.1580448239.git.viresh.kumar@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
|
Fix minor formatting issues with the doc style comments.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/1bff7c0d1ad2c8b6eeff9660421f414f8c612eb2.1580448239.git.viresh.kumar@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
