kernel.git/drivers/firmware/arm_scmi, branch linux-5.6.y

drivers: firmware: scmi: Extend SCMI transport layer by trace events

2019-12-30T12:34:37Z

The SCMI transport layer communicates via mailboxes and shared memory with firmware running on a microcontroller. It is platform specific how long it takes to pass a SCMI message. The most sensitive requests are coming from CPUFreq subsystem, which might be used by the scheduler. Thus, there is a need to measure these delays and capture anomalies. This change introduces trace events wrapped around transfer code. According to Jim's suggestion a unique transfer_id is to distinguish similar entries which might have the same message id, protocol id and sequence. This is a case then there are some timeouts in transfers. Suggested-by: Jim Quinlan Signed-off-by: Lukasz Luba Signed-off-by: Sudeep Holla

firmware: arm_scmi: Skip protocol initialisation for additional devices

2019-12-24T11:36:26Z

The scmi bus now supports adding multiple devices per protocol, and since scmi_protocol_init is called for each scmi device created, we must avoid allocating protocol private data and initialising the protocol itself if it is already initialised. In order to achieve the same, we can simple replace the idr pointer from protocol initialisation function to a dummy function. Suggested-by: Cristian Marussi Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Stash version in protocol init functions

2019-12-24T11:35:49Z

In order to avoid querying the individual protocol versions multiple time with more that one device created for each protocol, we can simple store the copy in the protocol specific private data and use them whenever required. Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Match scmi device by both name and protocol id

2019-12-24T11:35:49Z

The scmi bus now has support to match the driver with devices not only based on their protocol id but also based on their device name if one is available. This was added to cater the need to support multiple devices and drivers for the same protocol. Let us add the name "genpd" to scmi_device_id table in the driver so that in matches only with device with the same name and protocol id SCMI_PROTOCOL_POWER. Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add versions and identifier attributes using dev_groups

2019-12-24T11:35:49Z

Platform drivers now have the option to have the platform core create and remove any needed sysfs attribute files. Using the same, let's add the scmi firmware and protocol version attributes as well as vendor and sub-vendor identifiers to sysfs. It helps to identify the firmware details from the sysfs entries similar to ARM SCPI implementation. Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add names to scmi devices created

2019-12-24T11:35:49Z

Now that scmi bus provides option to create named scmi device, let us create the default devices with names. This will help to add names for matching to respective drivers and eventually to add multiple devices and drivers per protocol. Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Skip scmi mbox channel setup for addtional devices

2019-12-24T11:35:49Z

Now that the scmi bus supports adding multiple devices per protocol, and since scmi_create_protocol_device calls scmi_mbox_chan_setup, we must avoid allocating and initialising the mbox channel if it is already initialised. Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Add support for multiple device per protocol

2019-12-24T11:35:48Z

Currently only one scmi device is created for each protocol enumerated. However, there is requirement to make use of some procotols by multiple kernel subsystems/frameworks. One such example is SCMI PERFORMANCE protocol which can be used by both cpufreq and devfreq drivers. Similarly, SENSOR protocol may be used by hwmon and iio subsystems, and POWER protocol may be used by genpd and regulator drivers. In order to achieve that, let us extend the scmi bus to match based not only protocol id but also the scmi device name if one is available. Reviewed-by: Cristian Marussi Signed-off-by: Sudeep Holla

firmware: arm_scmi: Avoid double free in error flow

2019-11-26T10:50:30Z

If device_register() fails, both put_device() and kfree() are called, ending with a double free of the scmi_dev. Calling kfree() is needed only when a failure happens between the allocation of the scmi_dev and its registration, so move it to there and remove it from the error flow. Fixes: 46edb8d1322c ("firmware: arm_scmi: provide the mandatory device release callback") Signed-off-by: Wen Yang Signed-off-by: Sudeep Holla

firmware: arm_scmi: Fix doorbell ring logic for !CONFIG_64BIT

2019-11-14T11:13:50Z

The logic to ring the scmi performance fastchannel ignores the value read from the doorbell register in case of !CONFIG_64BIT. This bug also shows up as warning with '-Wunused-but-set-variable' gcc flag: drivers/firmware/arm_scmi/perf.c: In function scmi_perf_fc_ring_db: drivers/firmware/arm_scmi/perf.c:323:7: warning: variable val set but not used [-Wunused-but-set-variable] Fix the same by aligning the logic with CONFIG_64BIT as used in the macro SCMI_PERF_FC_RING_DB(). Fixes: 823839571d76 ("firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol") Reported-by: Hulk Robot Reported-by: Zheng Yongjun Signed-off-by: Sudeep Holla