From: Cristian Marussi <cristian.marussi@arm.com>
To: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
Cc: "sudeep.holla@arm.com" <sudeep.holla@arm.com>,
Linus Walleij <linus.walleij@linaro.org>,
Peng Fan <peng.fan@oss.nxp.com>,
Michal Simek <michal.simek@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [RFC v2 1/3] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
Date: Fri, 12 May 2023 09:55:53 +0100 [thread overview]
Message-ID: <ZF3/Ge4b+49ni+e6@e120937-lin> (raw)
In-Reply-To: <20230512083805.GA3424996@EPUAKYIW0A6A>
On Fri, May 12, 2023 at 08:38:06AM +0000, Oleksii Moisieiev wrote:
> On Fri, May 05, 2023 at 08:52:03PM +0100, Cristian Marussi wrote:
> > On Wed, Apr 26, 2023 at 01:26:37PM +0000, Oleksii Moisieiev wrote:
> > > scmi: Introduce pinctrl SCMI protocol driver
> > >
> > > Add basic implementation of the SCMI v3.2 pincontrol protocol
> > > excluding GPIO support. All pinctrl related callbacks and operations
> > > are exposed in the include/linux/scmi_protocol.h
> > >
> >
> > Hi Oleksii,
> >
> > Thanks for this.
> >
> > I tried out this in an emulated setup and found just a minor issue from
> > the spec/functional point of view...then I reworked the extended names
> > support using a modified hops->extended_name_get helper (as said the core
> > SCMI support needed a small modification to support PINCTRL): I'll reply
> > to this mail thread with such core SCMI modification patch, so you can
> > include this patch of mine in your next V3 and use it in your series.
> >
> > Moreover, given that I wanted to test such rework of mine and a bunch
> > of other cleanups I did (as detailed down below), and it seemed silly
> > to throw all away just to then having to detail all to you, I'll also
> > include in another distinct reply the raw diff of what I changed in
> > your series to use the new extended_name support and a few other cleanups,
> > so that, if you want, you can just quickly merge that into your V3 patch
> > (of course if you like it and tests fine also for you...)...these are
> > small changes, if you take it, no need to bother with authorship and
> > attribution from my point of view.
> >
>
> Hi Cristian,
>
Hi,
> Thank you for the patches. I've applied them and tested with powerpc,
> mx68 and clang environments (as test-robot complained about).
>
Yes, sure, they were just tentative fixes, needed cleanup.
I forgot to add the RFC tag on my proposed fixes to avoid triggering the bots.
> > > Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
> > > ---
> > > MAINTAINERS | 6 +
>
> [snip]
>
> > > SYSTEM RESET/SHUTDOWN DRIVERS
> > > M: Sebastian Reichel <sre@kernel.org>
> > > L: linux-pm@vger.kernel.org
> > > diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile
> > > index b31d78fa66cc..071ac65f22b9 100644
> > > --- a/drivers/firmware/arm_scmi/Makefile
> > > +++ b/drivers/firmware/arm_scmi/Makefile
> > > @@ -3,6 +3,7 @@ scmi-bus-y = bus.o
> > > scmi-core-objs := $(scmi-bus-y)
> > >
> > > scmi-driver-y = driver.o notify.o
> > > +
> >
> > Do not add spurios lines.
> >
>
> Thanks, removed
>
> > > scmi-driver-$(CONFIG_ARM_SCMI_RAW_MODE_SUPPORT) += raw_mode.o
> > > scmi-transport-$(CONFIG_ARM_SCMI_HAVE_SHMEM) = shmem.o
> > > scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_MAILBOX) += mailbox.o
> > > @@ -10,7 +11,7 @@ scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_SMC) += smc.o
> > > scmi-transport-$(CONFIG_ARM_SCMI_HAVE_MSG) += msg.o
> > > scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO) += virtio.o
> > > scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o
> > > -scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o system.o voltage.o powercap.o
> > > +scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o system.o voltage.o powercap.o pinctrl.o
> > > scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y) $(scmi-transport-y)
> > >
>
> I've applied patches you provided and made a small fixes. I'm going to
> make patch:
> "firmware: arm_scmi: Add optional flags to extended names helper"
> as a separate and squach "Misc Fixes and refactor" to my changes in V3 if you
> don't mind.
Sure, that's what I meant: include my general extended fixes at the
start of your series and just squash the misc_fixes (additionally fixed
by you :D) in your series.
A small nitpick I noticed later in scmi_protocol_ops Dox comment
+ * struct scmi_pinctrl_protocol_ops - represents the various operations provided
should be
* struct scmi_pinctrl_proto_ops
Thanks,
Cristian
next prev parent reply other threads:[~2023-05-12 8:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-26 13:26 [RFC v2 0/2] Introducing generic SCMI pinctrl driver implementation Oleksii Moisieiev
2023-04-26 13:26 ` [RFC v2 1/3] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Oleksii Moisieiev
2023-05-05 19:52 ` Cristian Marussi
2023-05-05 20:10 ` [PATCH] [REVIEW][PINCTRL]: Misc Fixes and refactor Cristian Marussi
2023-05-05 21:20 ` kernel test robot
2023-05-09 9:46 ` kernel test robot
2023-05-05 20:14 ` [PATCH] firmware: arm_scmi: Add optional flags to extended names helper Cristian Marussi
2023-05-07 20:38 ` [RFC v2 1/3] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support Cristian Marussi
2023-05-12 8:38 ` Oleksii Moisieiev
2023-05-12 8:55 ` Cristian Marussi [this message]
2023-05-12 12:31 ` Oleksii Moisieiev
2023-05-12 12:32 ` Michal Simek
2023-06-07 6:31 ` Oleksii Moisieiev
2023-04-26 13:26 ` [RFC v2 2/3] pinctrl: Implementation of the generic scmi-pinctrl driver Oleksii Moisieiev
2023-05-05 12:03 ` Linus Walleij
2023-05-05 20:01 ` Cristian Marussi
2023-05-11 10:23 ` Oleksii Moisieiev
2023-05-05 20:35 ` andy.shevchenko
2023-05-11 13:15 ` Oleksii Moisieiev
2023-05-12 9:04 ` Cristian Marussi
2023-05-12 12:18 ` Oleksii Moisieiev
2023-05-12 13:11 ` Cristian Marussi
2023-04-26 13:26 ` [RFC v2 3/3] dt-bindings: firmware: arm,scmi: Add support for pinctrl protocol Oleksii Moisieiev
2023-04-27 7:07 ` Michal Simek
2023-04-27 7:19 ` Oleksii Moisieiev
2023-04-28 10:06 ` Krzysztof Kozlowski
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=ZF3/Ge4b+49ni+e6@e120937-lin \
--to=cristian.marussi@arm.com \
--cc=Oleksii_Moisieiev@epam.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=peng.fan@oss.nxp.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox