From: Cristian Marussi <cristian.marussi@arm.com>
To: Florian Fainelli <florian.fainelli@broadcom.com>
Cc: Cristian Marussi <cristian.marussi@arm.com>,
linux-kernel@vger.kernel.org, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"open list:SYSTEM CONTROL & POWER/MANAGEMENT INTERFACE"
<arm-scmi@vger.kernel.org>,
"moderated list:SYSTEM CONTROL & POWER/MANAGEMENT INTERFACE"
<linux-arm-kernel@lists.infradead.org>,
justin.chen@broadcom.com, opendmb@gmail.com,
kapil.hali@broadcom.com, bcm-kernel-feedback-list@broadcom.com
Subject: Re: [PATCH v2 2/2] firmware: arm_scmi: Support 'reg-io-width' property for shared memory
Date: Fri, 16 Aug 2024 18:54:14 +0100 [thread overview]
Message-ID: <Zr-SRo10QtSh4G9R@pluto> (raw)
In-Reply-To: <345aca0f-12f0-4a66-a760-3b8524fda7fe@broadcom.com>
On Fri, Aug 16, 2024 at 10:39:42AM -0700, Florian Fainelli wrote:
> On 8/16/24 10:02, Cristian Marussi wrote:
> > On Tue, Aug 13, 2024 at 11:07:47AM -0700, Florian Fainelli wrote:
> > > 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.
> > >
> >
> > Hi Florian,
> >
Hi,
> > I gave it ago at this on a JUNO regarding the mailbox/shmem transport
> > without any issue. I'll have a go later on an OPTEE/shmem scenario too.
> >
> > This looks fundamentally good to me, since you moved all ops setup at
> > setup time and you keep the pointers per-channel instead of global...
>
> Thanks!
>
[snip]
> > > +
> >
> > There are a bunch of warn/errs from checkpatch --strict, beside the volatile
> > here and on the previous typedefs, also about args reuse and trailing semicolon
> > in these macros...
>
> I don't think we can silence the volatile ones, checkpatch --strict did not
> complain about the typedefs in my case, what did it look like in yours?
...I dont get warns on new typedefs..only on volatile and macro args
reuse
---8<---
WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#36: FILE: drivers/firmware/arm_scmi/common.h:322:
+typedef void (*shmem_copy_toio_t)(volatile void __iomem *to, const void *from,
WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#38: FILE: drivers/firmware/arm_scmi/common.h:324:
+typedef void (*shmem_copy_fromio_t)(void *to, const volatile void __iomem *from,
CHECK: Macro argument reuse 'amt' - possible side-effects?
#94: FILE: drivers/firmware/arm_scmi/shmem.c:37:
+#define SHMEM_IO_OPS(w, s, amt) \
+static inline void shmem_memcpy_fromio##s(void *to, \
+ const volatile void __iomem *from, \
+ size_t count) \
+{ \
+ while (count) { \
+ *(u##s *)to = __raw_read##w(from); \
+ from += amt; \
+ to += amt; \
+ count -= amt; \
+ } \
+} \
+static inline void shmem_memcpy_toio##s(volatile void __iomem *to, \
+ const void *from, \
+ size_t count) \
+{ \
+ while (count) { \
+ __raw_write##w(*(u##s *)from, to); \
+ from += amt; \
+ to += amt; \
+ count -= amt; \
+ } \
+} \
+static struct scmi_shmem_io_ops shmem_io_ops##s = { \
+ .fromio = shmem_memcpy_fromio##s, \
+ .toio = shmem_memcpy_toio##s, \
+};
WARNING: macros should not use a trailing semicolon
#94: FILE: drivers/firmware/arm_scmi/shmem.c:37:
+#define SHMEM_IO_OPS(w, s, amt) \
+static inline void shmem_memcpy_fromio##s(void *to, \
+ const volatile void __iomem *from, \
+ size_t count) \
+{ \
+ while (count) { \
+ *(u##s *)to = __raw_read##w(from); \
+ from += amt; \
+ to += amt; \
+ count -= amt; \
+ } \
+} \
+static inline void shmem_memcpy_toio##s(volatile void __iomem *to, \
+ const void *from, \
+ size_t count) \
+{ \
+ while (count) { \
+ __raw_write##w(*(u##s *)from, to); \
+ from += amt; \
+ to += amt; \
+ count -= amt; \
+ } \
+} \
+static struct scmi_shmem_io_ops shmem_io_ops##s = { \
+ .fromio = shmem_memcpy_fromio##s, \
+ .toio = shmem_memcpy_toio##s, \
+};
WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#96: FILE: drivers/firmware/arm_scmi/shmem.c:39:
+ const volatile void __iomem *from, \
WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#106: FILE: drivers/firmware/arm_scmi/shmem.c:49:
+static inline void shmem_memcpy_toio##s(volatile void __iomem *to, \
WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#128: FILE: drivers/firmware/arm_scmi/shmem.c:71:
+ const volatile void __iomem *from,
WARNING: Use of volatile is usually wrong: see Documentation/process/volatile-considered-harmful.rst
#134: FILE: drivers/firmware/arm_scmi/shmem.c:77:
+static inline void shmem_memcpy_toio(volatile void __iomem *to,
total: 0 errors, 7 warnings, 1 checks, 312 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
"[PATCH] firmware: arm_scmi: Support 'reg-io-width' property for" has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
---8<----
prev parent reply other threads:[~2024-08-16 17:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-13 18:07 [PATCH v2 0/2] Support for I/O width within ARM SCMI SHMEM Florian Fainelli
2024-08-13 18:07 ` [PATCH v2 1/2] dt-bindings: sram: Document reg-io-width property Florian Fainelli
2024-08-13 19:29 ` Rob Herring (Arm)
2024-08-13 20:08 ` Florian Fainelli
2024-08-13 18:07 ` [PATCH v2 2/2] firmware: arm_scmi: Support 'reg-io-width' property for shared memory Florian Fainelli
2024-08-16 17:02 ` Cristian Marussi
2024-08-16 17:39 ` Florian Fainelli
2024-08-16 17:54 ` Cristian Marussi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zr-SRo10QtSh4G9R@pluto \
--to=cristian.marussi@arm.com \
--cc=arm-scmi@vger.kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=florian.fainelli@broadcom.com \
--cc=justin.chen@broadcom.com \
--cc=kapil.hali@broadcom.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=opendmb@gmail.com \
--cc=robh@kernel.org \
--cc=sudeep.holla@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.