30 Dec, 2020
1 commit
-
[ Upstream commit 6bbdb46c4b1bd57839c9c0a110bd81b0be0a4046 ]
destroy_workqueue is required before the return from scmi_notification_init
in case devm_kcalloc fails to allocate registered_protocols. Fix this by
simply moving registered_protocols allocation before alloc_workqueue.Link: https://lore.kernel.org/r/20201110074221.41235-1-miaoqinglang@huawei.com
Fixes: bd31b249692e ("firmware: arm_scmi: Add notification dispatch and delivery")
Suggested-by: Cristian Marussi
Reviewed-by: Cristian Marussi
Signed-off-by: Qinglang Miao
Signed-off-by: Sudeep Holla
Signed-off-by: Sasha Levin
15 Oct, 2020
2 commits
-
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 0x1Fix 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
[sudeep.holla: trimmed backtrace to remove all unwanted hexcodes and timestamps]
Signed-off-by: Sudeep Holla -
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/0x180Link: 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
Signed-off-by: Sudeep Holla
13 Oct, 2020
1 commit
-
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
Signed-off-by: Sudeep Holla
12 Oct, 2020
2 commits
-
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
Signed-off-by: Etienne Carriere
[sudeep.holla: reworded the commit message to indicate the practicality]
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Sudeep Holla
14 Sep, 2020
3 commits
-
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
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Sudeep Holla
09 Sep, 2020
1 commit
-
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
Cc: Viresh Kumar
Tested-by: Cristian Marussi
Reviewed-by: Cristian Marussi
Reviewed-by: Viresh Kumar
Signed-off-by: Sudeep Holla
08 Sep, 2020
2 commits
-
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
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Sudeep Holla
07 Sep, 2020
1 commit
-
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
Signed-off-by: Sudeep Holla
17 Jul, 2020
1 commit
-
Kbuild test robot reports the following sparse warning:
drivers/firmware/arm_scmi/clock.c:142:21:
sparse: Using plain integer as NULL pointerUse 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
Signed-off-by: Sudeep Holla
Signed-off-by: Arnd Bergmann
13 Jul, 2020
3 commits
-
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
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Sudeep Holla
10 Jul, 2020
1 commit
-
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
Signed-off-by: Sudeep Holla
02 Jul, 2020
9 commits
-
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
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla
30 Jun, 2020
4 commits
-
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/0x180Do 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
Signed-off-by: Sudeep Holla -
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
Cc: Arnd Bergmann
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Nicola Mazzucato
Signed-off-by: Sudeep Holla -
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
Cc: Lukasz Luba
Reviewed-by: Lukasz Luba
Signed-off-by: Sudeep Holla
07 May, 2020
1 commit
-
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
21 Apr, 2020
5 commits
-
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
Reviewed-by: Etienne Carriere
Reviewed-by: Peng Fan
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Sudeep Holla -
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
(sudeep.holla: Updated commit log to reflect that channel is now free for
platform to use)
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Sudeep Holla
14 Apr, 2020
3 commits
-
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
[Reworked/renamed scmi_handle_xfer_delayed_resp()]
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla -
Add common transport-layer methods to:
- fetch a notification instead of a response
- clear a pending notificationAdd 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
Reviewed-by: Viresh Kumar
Signed-off-by: Cristian Marussi
Signed-off-by: Sudeep Holla -
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
Signed-off-by: Sudeep Holla