From 98f0d68f94ea21541e0050cc64fa108ade779839 Mon Sep 17 00:00:00 2001 From: Cristian Marussi Date: Thu, 24 Feb 2022 15:24:04 +0000 Subject: firmware: arm_scmi: Remove clear channel call on the TX channel On SCMI transports whose channels are based on a shared resource the TX channel area has to be acquired by the agent before placing the desired command into the channel and it will be then relinquished by the platform once the related reply has been made available into the channel. On an RX channel the logic is reversed with the platform acquiring the channel area and the agent reliquishing it once done by calling the scmi_clear_channel() helper. As a consequence, even in case of error, the agent must never try to clear a TX channel from its side: restrict the existing clear channel call on the the reply path only to delayed responses since they are indeed coming from the RX channel. Link: https://lore.kernel.org/r/20220224152404.12877-1-cristian.marussi@arm.com Fixes: e9b21c96181c ("firmware: arm_scmi: Make .clear_channel optional") Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla --- drivers/firmware/arm_scmi/driver.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'drivers/firmware') diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c index 46118300a4d1..e17c6568344d 100644 --- a/drivers/firmware/arm_scmi/driver.c +++ b/drivers/firmware/arm_scmi/driver.c @@ -679,7 +679,8 @@ static void scmi_handle_response(struct scmi_chan_info *cinfo, xfer = scmi_xfer_command_acquire(cinfo, msg_hdr); if (IS_ERR(xfer)) { - scmi_clear_channel(info, cinfo); + if (MSG_XTRACT_TYPE(msg_hdr) == MSG_TYPE_DELAYED_RESP) + scmi_clear_channel(info, cinfo); return; } -- cgit v1.2.3 From 23274739a5b6166f74d8d9cb5243d7bf6b46aab9 Mon Sep 17 00:00:00 2001 From: Cristian Marussi Date: Fri, 18 Mar 2022 09:28:13 +0000 Subject: firmware: arm_scmi: Fix sorting of retrieved clock rates During SCMI Clock protocol initialization, after having retrieved from the SCMI platform all the available discrete rates for a specific clock, the clock rates array is sorted, unfortunately using a pointer to its end as a base instead of its start, so that sorting does not work. Fix invocation of sort() passing as base a pointer to the start of the retrieved clock rates array. Link: https://lore.kernel.org/r/20220318092813.49283-1-cristian.marussi@arm.com Fixes: dccec73de91d ("firmware: arm_scmi: Keep the discrete clock rates sorted") Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla --- drivers/firmware/arm_scmi/clock.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'drivers/firmware') diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c index cf6fed6dec77..ef6431c6eb1c 100644 --- a/drivers/firmware/arm_scmi/clock.c +++ b/drivers/firmware/arm_scmi/clock.c @@ -210,7 +210,8 @@ scmi_clock_describe_rates_get(const struct scmi_protocol_handle *ph, u32 clk_id, if (rate_discrete && rate) { clk->list.num_rates = tot_rate_cnt; - sort(rate, tot_rate_cnt, sizeof(*rate), rate_cmp_func, NULL); + sort(clk->list.rates, tot_rate_cnt, sizeof(*rate), + rate_cmp_func, NULL); } clk->rate_discrete = rate_discrete; -- cgit v1.2.3 From f1ad601d1f4a8f5dac69706d641f3a88beccc488 Mon Sep 17 00:00:00 2001 From: Lv Ruyi Date: Fri, 1 Apr 2022 07:55:37 +0000 Subject: firmware: arm_scmi: Replace zero-length array with flexible-array member MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.16/process/deprecated.html#zero-length-and-one-element-arrays Link: https://lore.kernel.org/r/20220401075537.2407376-1-lv.ruyi@zte.com.cn Reported-by: Zeal Robot Signed-off-by: Lv Ruyi Signed-off-by: Sudeep Holla --- drivers/firmware/arm_scmi/clock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/firmware') diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c index ef6431c6eb1c..45600acc0f45 100644 --- a/drivers/firmware/arm_scmi/clock.c +++ b/drivers/firmware/arm_scmi/clock.c @@ -49,7 +49,7 @@ struct scmi_msg_resp_clock_describe_rates { struct { __le32 value_low; __le32 value_high; - } rate[0]; + } rate[]; #define RATE_TO_U64(X) \ ({ \ typeof(X) x = (X); \ -- cgit v1.2.3 From bf36619a5463fbe6d3ecde37bb13680b532a253b Mon Sep 17 00:00:00 2001 From: Sudeep Holla Date: Mon, 4 Apr 2022 11:24:19 +0100 Subject: firmware: arm_scmi: Fix sparse warnings in OPTEE transport driver The sparse checker complains about converting pointers between address spaces. We correctly stored an __iomem pointer in struct scmi_optee_channel, but discarded the __iomem when returning it from get_channel_shm, causing one warning. Then we passed the non-__iomem pointer return from get_channel_shm at two other places, where an __iomem pointer is expected, causing couple of other warnings Add the appropriate __iomem annotations at all places where it is missing. optee.c:414:20: warning: incorrect type in return expression (different address spaces) optee.c:414:20: expected struct scmi_shared_mem * optee.c:414:20: got struct scmi_shared_mem [noderef] __iomem *shmem optee.c:426:26: warning: incorrect type in argument 1 (different address spaces) optee.c:426:26: expected struct scmi_shared_mem [noderef] __iomem *shmem optee.c:426:26: got struct scmi_shared_mem *shmem optee.c:441:30: warning: incorrect type in argument 1 (different address spaces) optee.c:441:30: expected struct scmi_shared_mem [noderef] __iomem *shmem optee.c:441:30: got struct scmi_shared_mem *shmem Link: https://lore.kernel.org/r/20220404102419.1159705-1-sudeep.holla@arm.com Cc: Etienne Carriere Cc: Cristian Marussi Reported-by: kernel test robot Signed-off-by: Sudeep Holla --- drivers/firmware/arm_scmi/optee.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'drivers/firmware') diff --git a/drivers/firmware/arm_scmi/optee.c b/drivers/firmware/arm_scmi/optee.c index 734f1eeee161..8302a2b4aeeb 100644 --- a/drivers/firmware/arm_scmi/optee.c +++ b/drivers/firmware/arm_scmi/optee.c @@ -405,8 +405,8 @@ static int scmi_optee_chan_free(int id, void *p, void *data) return 0; } -static struct scmi_shared_mem *get_channel_shm(struct scmi_optee_channel *chan, - struct scmi_xfer *xfer) +static struct scmi_shared_mem __iomem * +get_channel_shm(struct scmi_optee_channel *chan, struct scmi_xfer *xfer) { if (!chan) return NULL; @@ -419,7 +419,7 @@ static int scmi_optee_send_message(struct scmi_chan_info *cinfo, struct scmi_xfer *xfer) { struct scmi_optee_channel *channel = cinfo->transport_info; - struct scmi_shared_mem *shmem = get_channel_shm(channel, xfer); + struct scmi_shared_mem __iomem *shmem = get_channel_shm(channel, xfer); int ret; mutex_lock(&channel->mu); @@ -436,7 +436,7 @@ static void scmi_optee_fetch_response(struct scmi_chan_info *cinfo, struct scmi_xfer *xfer) { struct scmi_optee_channel *channel = cinfo->transport_info; - struct scmi_shared_mem *shmem = get_channel_shm(channel, xfer); + struct scmi_shared_mem __iomem *shmem = get_channel_shm(channel, xfer); shmem_fetch_response(shmem, xfer); } -- cgit v1.2.3