From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CBACAC531DC for ; Tue, 20 Aug 2024 16:36:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=I/jQ4CsoLAYAWazFQRdZD0QAtpzqYEXDl/Ljb9v3uaE=; b=uX80k9aEyhfE+ld6UR5XLgVYIV q218a6GIX9jDtsDiN9CLm0++ic+MdBWbwq3luESMxzxDqUEAE0zAlU8RhjexupJm4MkJ5CHidFv6q VAQ/vLdqba86bTPLjsttH8AXyKDyLMSmIjyUQEdYUNIO6OlNgeG/+bQtkvGCtCxpI9jrLLgjyXnRe mGNuX3vlW8/LWDY78uX06MIjo+JhIQzt3V02O68ahClEPv//dhPhUmsCMrwyFa40ExurC8VGDY+Xh AidxyQu0+i2zouDcWDSFOhpd1gkWORBNcfPU7lne2pVKROP5S9cukS+jDNCgPsb3gQO2XEkknesUU y7qgIhZA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgRpl-000000061T8-2Bh1; Tue, 20 Aug 2024 16:35:49 +0000 Received: from mail-pf1-x42d.google.com ([2607:f8b0:4864:20::42d]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgRp1-000000061FT-2uV6 for linux-arm-kernel@lists.infradead.org; Tue, 20 Aug 2024 16:35:05 +0000 Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-713eeb4e4a9so1846660b3a.0 for ; Tue, 20 Aug 2024 09:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1724171702; x=1724776502; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=I/jQ4CsoLAYAWazFQRdZD0QAtpzqYEXDl/Ljb9v3uaE=; b=KayYbOf2oVoF8623nSGHER3+j4LgxBIQmaaxk5hriGda3zzCO6DuX+CW7lBQ1GyMlU 8FetOkoXGTzI5N6wabXNAoAJrWWn2SMCxAkPs0SXcCbLYGLh4njlx7QNfbPv2uY+EXHY Ull6h2hBqfGHPqBf7mzKLmb0+1L9huyTOweuA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724171702; x=1724776502; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=I/jQ4CsoLAYAWazFQRdZD0QAtpzqYEXDl/Ljb9v3uaE=; b=kZ1Gw5unrFuamFgK8Nxp/bWWertmmF+CUc39iHD+3/8eGFhCPAE8P+RWo6NG1aQQv2 xqgp1phlziwgN/j6zV0N0rSuXtlfcu/OUNy1lXkPAVTTuSly7/Cp99sXuLLoG0uYk5+M OgfcooqXbF2q1Qz1OJtbvG9VqO/FtUP4ZNulfu0uYdbRjzykn1Vl54kYHReezK1MlJeh 909iqIkHGkJpeKv7GzLHcX69MokT0NnT8LMNqdH8Z3OWUAiK4jLd9z+ZlYn/CP4nlr1P XTQIuWOUnpyc6/zU0pmThIm8/y3mmK1cuvwk2kncL5xDm2ZDvMUzFjguVNrgOa8L9UG8 +Ubw== X-Forwarded-Encrypted: i=1; AJvYcCXPnllsC6Y+BkHWBfJ7G8rJa6NjEeJ/PG9QeLPoR5pRWcZGnqx8F38wW1sAGhO2dowehrw+ZM+IiG3CoUhozDlEs4lgl3W/pE/nNHcXj4B78jGqjRA= X-Gm-Message-State: AOJu0Yx7P0SbU1HiL0i+oPVnJFAhTJ1gF03MbzvaAb04NgNM+cf/FcG4 R2tmYjlkSo/oLfnb1YBC2vzkemFwBj8wXuqDwXoDz8OOgMSwIMu2CbntpMtF1l1pR+wNtHVUoHk = X-Google-Smtp-Source: AGHT+IFd776z14UzYpO+PvAZ+OsQuKluFGT6Sas0CXJ3qt53396lWSFk10aFDTPjlR6JPoZn3aRHhw== X-Received: by 2002:a05:6a21:e8f:b0:1c6:fa1d:5b6a with SMTP id adf61e73a8af0-1cac8eb00e7mr3143945637.29.1724171701871; Tue, 20 Aug 2024 09:35:01 -0700 (PDT) Received: from [10.67.48.245] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7127add721dsm8433185b3a.42.2024.08.20.09.35.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Aug 2024 09:35:01 -0700 (PDT) Message-ID: <1a486ead-3a65-4ef9-a562-c23ea7026b9e@broadcom.com> Date: Tue, 20 Aug 2024 09:34:59 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] firmware: arm_scmi: Support 'reg-io-width' property for shared memory To: Peng Fan , "linux-arm-kernel@lists.infradead.org" Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sudeep Holla , Cristian Marussi , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list , "open list:SYSTEM CONTROL & POWER/MANAGEMENT INTERFACE" , "justin.chen@broadcom.com" , "opendmb@gmail.com" , "kapil.hali@broadcom.com" , "bcm-kernel-feedback-list@broadcom.com" References: <20240816224221.3256455-1-florian.fainelli@broadcom.com> <20240816224221.3256455-3-florian.fainelli@broadcom.com> Content-Language: en-US From: Florian Fainelli Autocrypt: addr=florian.fainelli@broadcom.com; keydata= xsBNBFPAG8ABCAC3EO02urEwipgbUNJ1r6oI2Vr/+uE389lSEShN2PmL3MVnzhViSAtrYxeT M0Txqn1tOWoIc4QUl6Ggqf5KP6FoRkCrgMMTnUAINsINYXK+3OLe7HjP10h2jDRX4Ajs4Ghs JrZOBru6rH0YrgAhr6O5gG7NE1jhly+EsOa2MpwOiXO4DE/YKZGuVe6Bh87WqmILs9KvnNrQ PcycQnYKTVpqE95d4M824M5cuRB6D1GrYovCsjA9uxo22kPdOoQRAu5gBBn3AdtALFyQj9DQ KQuc39/i/Kt6XLZ/RsBc6qLs+p+JnEuPJngTSfWvzGjpx0nkwCMi4yBb+xk7Hki4kEslABEB AAHNMEZsb3JpYW4gRmFpbmVsbGkgPGZsb3JpYW4uZmFpbmVsbGlAYnJvYWRjb20uY29tPsLB IQQQAQgAywUCZWl41AUJI+Jo+hcKAAG/SMv+fS3xUQWa0NryPuoRGjsA3SAUAAAAAAAWAAFr ZXktdXNhZ2UtbWFza0BwZ3AuY29tjDAUgAAAAAAgAAdwcmVmZXJyZWQtZW1haWwtZW5jb2Rp bmdAcGdwLmNvbXBncG1pbWUICwkIBwMCAQoFF4AAAAAZGGxkYXA6Ly9rZXlzLmJyb2FkY29t Lm5ldAUbAwAAAAMWAgEFHgEAAAAEFQgJChYhBNXZKpfnkVze1+R8aIExtcQpvGagAAoJEIEx tcQpvGagWPEH/2l0DNr9QkTwJUxOoP9wgHfmVhqc0ZlDsBFv91I3BbhGKI5UATbipKNqG13Z TsBrJHcrnCqnTRS+8n9/myOF0ng2A4YT0EJnayzHugXm+hrkO5O9UEPJ8a+0553VqyoFhHqA zjxj8fUu1px5cbb4R9G4UAySqyeLLeqnYLCKb4+GklGSBGsLMYvLmIDNYlkhMdnnzsSUAS61 WJYW6jjnzMwuKJ0ZHv7xZvSHyhIsFRiYiEs44kiYjbUUMcXor/uLEuTIazGrE3MahuGdjpT2 IOjoMiTsbMc0yfhHp6G/2E769oDXMVxCCbMVpA+LUtVIQEA+8Zr6mX0Yk4nDS7OiBlvOwE0E U8AbwQEIAKxr71oqe+0+MYCc7WafWEcpQHFUwvYLcdBoOnmJPxDwDRpvU5LhqSPvk/yJdh9k 4xUDQu3rm1qIW2I9Puk5n/Jz/lZsqGw8T13DKyu8eMcvaA/irm9lX9El27DPHy/0qsxmxVmU pu9y9S+BmaMb2CM9IuyxMWEl9ruWFS2jAWh/R8CrdnL6+zLk60R7XGzmSJqF09vYNlJ6Bdbs MWDXkYWWP5Ub1ZJGNJQ4qT7g8IN0qXxzLQsmz6tbgLMEHYBGx80bBF8AkdThd6SLhreCN7Uh IR/5NXGqotAZao2xlDpJLuOMQtoH9WVNuuxQQZHVd8if+yp6yRJ5DAmIUt5CCPcAEQEAAcLB gQQYAQIBKwUCU8AbwgUbDAAAAMBdIAQZAQgABgUCU8AbwQAKCRCTYAaomC8PVQ0VCACWk3n+ obFABEp5Rg6Qvspi9kWXcwCcfZV41OIYWhXMoc57ssjCand5noZi8bKg0bxw4qsg+9cNgZ3P N/DFWcNKcAT3Z2/4fTnJqdJS//YcEhlr8uGs+ZWFcqAPbteFCM4dGDRruo69IrHfyyQGx16s CcFlrN8vD066RKevFepb/ml7eYEdN5SRALyEdQMKeCSf3mectdoECEqdF/MWpfWIYQ1hEfdm C2Kztm+h3Nkt9ZQLqc3wsPJZmbD9T0c9Rphfypgw/SfTf2/CHoYVkKqwUIzI59itl5Lze+R5 wDByhWHx2Ud2R7SudmT9XK1e0x7W7a5z11Q6vrzuED5nQvkhAAoJEIExtcQpvGagugcIAJd5 EYe6KM6Y6RvI6TvHp+QgbU5dxvjqSiSvam0Ms3QrLidCtantcGT2Wz/2PlbZqkoJxMQc40rb fXa4xQSvJYj0GWpadrDJUvUu3LEsunDCxdWrmbmwGRKqZraV2oG7YEddmDqOe0Xm/NxeSobc MIlnaE6V0U8f5zNHB7Y46yJjjYT/Ds1TJo3pvwevDWPvv6rdBeV07D9s43frUS6xYd1uFxHC 7dZYWJjZmyUf5evr1W1gCgwLXG0PEi9n3qmz1lelQ8lSocmvxBKtMbX/OKhAfuP/iIwnTsww 95A2SaPiQZA51NywV8OFgsN0ITl2PlZ4Tp9hHERDe6nQCsNI/Us= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240820_093504_109951_C0BB071E X-CRM114-Status: GOOD ( 20.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 8/19/24 19:49, Peng Fan wrote: >> Subject: [PATCH v3 2/2] firmware: arm_scmi: Support 'reg-io-width' >> property for shared memory >> >> Some shared memory areas might only support a certain access width, >> such as 32-bit, which memcpy_{from,to}_io() does not adhere to at >> least on ARM64 by making both 8-bit and 64-bit accesses to such >> memory. >> >> Update the shmem layer to support reading from and writing to such >> shared memory area using the specified I/O width in the Device Tree. >> The various transport layers making use of the shmem.c code are >> updated accordingly to pass the I/O accessors that they store. >> >> Signed-off-by: Florian Fainelli >> --- >> drivers/firmware/arm_scmi/common.h | 32 ++++++- >> .../arm_scmi/scmi_transport_mailbox.c | 13 ++- >> .../firmware/arm_scmi/scmi_transport_optee.c | 11 ++- >> .../firmware/arm_scmi/scmi_transport_smc.c | 11 ++- >> drivers/firmware/arm_scmi/shmem.c | 86 +++++++++++++++++- >> - >> 5 files changed, 132 insertions(+), 21 deletions(-) >> >> diff --git a/drivers/firmware/arm_scmi/common.h >> b/drivers/firmware/arm_scmi/common.h >> index 69928bbd01c2..73bb496fac01 100644 >> --- a/drivers/firmware/arm_scmi/common.h >> +++ b/drivers/firmware/arm_scmi/common.h >> @@ -316,6 +316,26 @@ enum scmi_bad_msg { >> MSG_MBOX_SPURIOUS = -5, >> }; >> >> +/* Used for compactness and signature validation of the function >> +pointers being >> + * passed. >> + */ >> +typedef void (*shmem_copy_toio_t)(volatile void __iomem *to, const >> void *from, >> + size_t count); >> +typedef void (*shmem_copy_fromio_t)(void *to, const volatile void >> __iomem *from, >> + size_t count); >> + >> +/** >> + * struct scmi_shmem_io_ops - I/O operations to read from/write to >> + * Shared Memory >> + * >> + * @toio: Copy data to the shared memory area >> + * @fromio: Copy data from the shared memory area */ struct >> +scmi_shmem_io_ops { >> + shmem_copy_fromio_t fromio; >> + shmem_copy_toio_t toio; >> +}; >> + >> /* shmem related declarations */ >> struct scmi_shared_mem; >> >> @@ -336,13 +356,16 @@ struct scmi_shared_mem; struct >> scmi_shared_mem_operations { >> void (*tx_prepare)(struct scmi_shared_mem __iomem >> *shmem, >> struct scmi_xfer *xfer, >> - struct scmi_chan_info *cinfo); >> + struct scmi_chan_info *cinfo, >> + shmem_copy_toio_t toio); >> u32 (*read_header)(struct scmi_shared_mem __iomem >> *shmem); >> >> void (*fetch_response)(struct scmi_shared_mem __iomem >> *shmem, >> - struct scmi_xfer *xfer); >> + struct scmi_xfer *xfer, >> + shmem_copy_fromio_t fromio); >> void (*fetch_notification)(struct scmi_shared_mem __iomem >> *shmem, >> - size_t max_len, struct scmi_xfer >> *xfer); >> + size_t max_len, struct scmi_xfer >> *xfer, >> + shmem_copy_fromio_t fromio); >> void (*clear_channel)(struct scmi_shared_mem __iomem >> *shmem); >> bool (*poll_done)(struct scmi_shared_mem __iomem *shmem, >> struct scmi_xfer *xfer); >> @@ -350,7 +373,8 @@ struct scmi_shared_mem_operations { >> bool (*channel_intr_enabled)(struct scmi_shared_mem >> __iomem *shmem); >> void __iomem *(*setup_iomap)(struct scmi_chan_info *cinfo, >> struct device *dev, >> - bool tx, struct resource *res); >> + bool tx, struct resource *res, >> + struct scmi_shmem_io_ops **ops); >> }; >> >> const struct scmi_shared_mem_operations >> *scmi_shared_mem_operations_get(void); >> diff --git a/drivers/firmware/arm_scmi/scmi_transport_mailbox.c >> b/drivers/firmware/arm_scmi/scmi_transport_mailbox.c >> index dc5ca894d5eb..1a2e90e5c765 100644 >> --- a/drivers/firmware/arm_scmi/scmi_transport_mailbox.c >> +++ b/drivers/firmware/arm_scmi/scmi_transport_mailbox.c >> @@ -25,6 +25,7 @@ >> * @chan_platform_receiver: Optional Platform Receiver mailbox >> unidirectional channel >> * @cinfo: SCMI channel info >> * @shmem: Transmit/Receive shared memory area >> + * @io_ops: Transport specific I/O operations >> */ >> struct scmi_mailbox { >> struct mbox_client cl; >> @@ -33,6 +34,7 @@ struct scmi_mailbox { >> struct mbox_chan *chan_platform_receiver; >> struct scmi_chan_info *cinfo; >> struct scmi_shared_mem __iomem *shmem; >> + struct scmi_shmem_io_ops *io_ops; >> }; >> >> #define client_to_scmi_mailbox(c) container_of(c, struct scmi_mailbox, >> cl) @@ -43,7 +45,8 @@ static void tx_prepare(struct mbox_client *cl, >> void *m) { >> struct scmi_mailbox *smbox = client_to_scmi_mailbox(cl); >> >> - core->shmem->tx_prepare(smbox->shmem, m, smbox->cinfo); >> + core->shmem->tx_prepare(smbox->shmem, m, smbox->cinfo, >> + smbox->io_ops->toio); >> } >> >> static void rx_callback(struct mbox_client *cl, void *m) @@ -197,7 >> +200,8 @@ static int mailbox_chan_setup(struct scmi_chan_info >> *cinfo, struct device *dev, >> if (!smbox) >> return -ENOMEM; >> >> - smbox->shmem = core->shmem->setup_iomap(cinfo, dev, tx, >> NULL); >> + smbox->shmem = core->shmem->setup_iomap(cinfo, dev, tx, >> NULL, >> + &smbox->io_ops); >> if (IS_ERR(smbox->shmem)) >> return PTR_ERR(smbox->shmem); >> >> @@ -298,7 +302,7 @@ static void mailbox_fetch_response(struct >> scmi_chan_info *cinfo, { >> struct scmi_mailbox *smbox = cinfo->transport_info; >> >> - core->shmem->fetch_response(smbox->shmem, xfer); >> + core->shmem->fetch_response(smbox->shmem, xfer, >> +smbox->io_ops->fromio); >> } >> >> static void mailbox_fetch_notification(struct scmi_chan_info *cinfo, >> @@ -306,7 +310,8 @@ static void mailbox_fetch_notification(struct >> scmi_chan_info *cinfo, { >> struct scmi_mailbox *smbox = cinfo->transport_info; >> >> - core->shmem->fetch_notification(smbox->shmem, max_len, >> xfer); >> + core->shmem->fetch_notification(smbox->shmem, max_len, >> xfer, >> + smbox->io_ops->fromio); >> } >> >> static void mailbox_clear_channel(struct scmi_chan_info *cinfo) diff -- >> git a/drivers/firmware/arm_scmi/scmi_transport_optee.c >> b/drivers/firmware/arm_scmi/scmi_transport_optee.c >> index 08911f40d1ff..2be4124c6826 100644 >> --- a/drivers/firmware/arm_scmi/scmi_transport_optee.c >> +++ b/drivers/firmware/arm_scmi/scmi_transport_optee.c >> @@ -114,6 +114,7 @@ enum scmi_optee_pta_cmd { >> * @req.shmem: Virtual base address of the shared memory >> * @req.msg: Shared memory protocol handle for SCMI request and >> * synchronous response >> + * @io_ops: Transport specific I/O operations >> * @tee_shm: TEE shared memory handle @req or NULL if using >> IOMEM shmem >> * @link: Reference in agent's channel list >> */ >> @@ -128,6 +129,7 @@ struct scmi_optee_channel { >> struct scmi_shared_mem __iomem *shmem; >> struct scmi_msg_payld *msg; >> } req; >> + struct scmi_shmem_io_ops *io_ops; >> struct tee_shm *tee_shm; >> struct list_head link; >> }; >> @@ -350,7 +352,8 @@ static int setup_dynamic_shmem(struct device >> *dev, struct scmi_optee_channel *ch static int >> setup_static_shmem(struct device *dev, struct scmi_chan_info *cinfo, >> struct scmi_optee_channel *channel) { >> - channel->req.shmem = core->shmem->setup_iomap(cinfo, dev, >> true, NULL); >> + channel->req.shmem = core->shmem->setup_iomap(cinfo, dev, >> true, NULL, >> + &channel- >>> io_ops); >> if (IS_ERR(channel->req.shmem)) >> return PTR_ERR(channel->req.shmem); >> >> @@ -465,7 +468,8 @@ static int scmi_optee_send_message(struct >> scmi_chan_info *cinfo, >> ret = invoke_process_msg_channel(channel, >> core->msg- >>> command_size(xfer)); >> } else { >> - core->shmem->tx_prepare(channel->req.shmem, xfer, >> cinfo); >> + core->shmem->tx_prepare(channel->req.shmem, xfer, >> cinfo, >> + channel->io_ops->toio); >> ret = invoke_process_smt_channel(channel); >> } >> >> @@ -484,7 +488,8 @@ static void scmi_optee_fetch_response(struct >> scmi_chan_info *cinfo, >> core->msg->fetch_response(channel->req.msg, >> channel->rx_len, xfer); >> else >> - core->shmem->fetch_response(channel->req.shmem, >> xfer); >> + core->shmem->fetch_response(channel->req.shmem, >> xfer, >> + channel->io_ops->fromio); >> } >> >> static void scmi_optee_mark_txdone(struct scmi_chan_info *cinfo, int >> ret, diff --git a/drivers/firmware/arm_scmi/scmi_transport_smc.c >> b/drivers/firmware/arm_scmi/scmi_transport_smc.c >> index c6c69a17a9cc..04e715ec1570 100644 >> --- a/drivers/firmware/arm_scmi/scmi_transport_smc.c >> +++ b/drivers/firmware/arm_scmi/scmi_transport_smc.c >> @@ -45,6 +45,7 @@ >> * @irq: An optional IRQ for completion >> * @cinfo: SCMI channel info >> * @shmem: Transmit/Receive shared memory area >> + * @io_ops: Transport specific I/O operations >> * @shmem_lock: Lock to protect access to Tx/Rx shared memory area. >> * Used when NOT operating in atomic mode. >> * @inflight: Atomic flag to protect access to Tx/Rx shared memory >> area. >> @@ -60,6 +61,7 @@ struct scmi_smc { >> int irq; >> struct scmi_chan_info *cinfo; >> struct scmi_shared_mem __iomem *shmem; >> + struct scmi_shmem_io_ops *io_ops; >> /* Protect access to shmem area */ >> struct mutex shmem_lock; >> #define INFLIGHT_NONE MSG_TOKEN_MAX >> @@ -144,7 +146,8 @@ static int smc_chan_setup(struct >> scmi_chan_info *cinfo, struct device *dev, >> if (!scmi_info) >> return -ENOMEM; >> >> - scmi_info->shmem = core->shmem->setup_iomap(cinfo, dev, >> tx, &res); >> + scmi_info->shmem = core->shmem->setup_iomap(cinfo, dev, >> tx, &res, >> + &scmi_info- >>> io_ops); >> if (IS_ERR(scmi_info->shmem)) >> return PTR_ERR(scmi_info->shmem); >> >> @@ -229,7 +232,8 @@ static int smc_send_message(struct >> scmi_chan_info *cinfo, >> */ >> smc_channel_lock_acquire(scmi_info, xfer); >> >> - core->shmem->tx_prepare(scmi_info->shmem, xfer, cinfo); >> + core->shmem->tx_prepare(scmi_info->shmem, xfer, cinfo, >> + scmi_info->io_ops->toio); >> >> if (scmi_info->cap_id != ULONG_MAX) >> arm_smccc_1_1_invoke(scmi_info->func_id, >> scmi_info->cap_id, 0, @@ -253,7 +257,8 @@ static void >> smc_fetch_response(struct scmi_chan_info *cinfo, { >> struct scmi_smc *scmi_info = cinfo->transport_info; >> >> - core->shmem->fetch_response(scmi_info->shmem, xfer); >> + core->shmem->fetch_response(scmi_info->shmem, xfer, >> + scmi_info->io_ops->fromio); >> } >> >> static void smc_mark_txdone(struct scmi_chan_info *cinfo, int ret, diff >> --git a/drivers/firmware/arm_scmi/shmem.c >> b/drivers/firmware/arm_scmi/shmem.c >> index 01d8a9398fe8..aded5f1cd49f 100644 >> --- a/drivers/firmware/arm_scmi/shmem.c >> +++ b/drivers/firmware/arm_scmi/shmem.c >> @@ -34,9 +34,67 @@ struct scmi_shared_mem { >> u8 msg_payload[]; >> }; >> >> +static inline void shmem_memcpy_fromio32(void *to, >> + const volatile void __iomem >> *from, >> + size_t count) >> +{ >> + while (count) { >> + *(u32 *)to = __raw_readl(from); >> + from += 4; >> + to += 4; >> + count -= 4; > > This may not have issue, considering the 'count % 4' will be 0 > and 'from' is 4 bytes aligned. Correct, this cannot possibly happen today by virtue of msg->payload being naturally aligned on a 4 bytes boundary. > > But I think it maybe better to add check if 'count' and 'from' > are not 4 bytes aligned. Humm, what would be the fallback, or should we just WARN()? > >> + } >> + >> + /* Ensure all reads from I/O have completed */ >> + rmb(); > > Is there a need to use rmb here? I am not sure, just wonder. I personally do not think there is because there is an implicit data dependency eventually we will be consuming data that was copied into msg->payload and that will ensure that the data is there. > >> +} >> + >> +static inline void shmem_memcpy_toio32(volatile void __iomem *to, >> + const void *from, >> + size_t count) >> +{ >> + while (count) { >> + __raw_writel(*(u32 *)from, to); >> + from += 4; >> + to += 4; >> + count -= 4; >> + } > > Ditto. > >> + >> + /* Ensure all writes to I/O have completed */ >> + wmb(); > > This maybe not needed. > The mailbox will use "writel", the SMC will use "smc", > the virtio will have "hvc", both will have barrier I think. Yes, those are all implicit barriers, I was attempting to address Christian's concerns raised in v2: https://lore.kernel.org/all/Zr-GJts3Gu6GEkhC@pluto/ -- Florian