linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Shawn Guo <shawnguo@kernel.org>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	Fabio Estevam <festevam@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Dong Aisheng <aisheng.dong@nxp.com>, Jacky Bai <ping.bai@nxp.com>,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, imx@lists.linux.dev,
	linux-gpio@vger.kernel.org, Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH v3 4/6] pinctrl: scmi: export pinctrl_scmi_get_pins
Date: Wed, 1 May 2024 13:36:57 +0100	[thread overview]
Message-ID: <ZjI3abJUIgo4xgRu@pluto> (raw)
In-Reply-To: <20240428-pinctrl-scmi-oem-v3-v3-4-eda341eb47ed@nxp.com>

On Sun, Apr 28, 2024 at 01:07:50PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
> 
> Add pinctrl-scmi.h to include the function prototype and 'struct
> scmi_pinctrl' to export pinctrl_scmi_get_pins, so other drivers
> could use it.
> 

Hi Peng,

so you wrote a new alternative SCMI driver using Pinctrl protocol@0x19
so that you can just parse you custom DT bindings and then use the SCMI
pinctrl_ops to set the OEM extensions to configure your platform...
...since your firmware cannot cope with the all SCMI stack footprint....

... you seemed to have solved the issue of having 2 Pinctrl drivers
coexisting under the Linux Pinctrl subsystem while attached to the same
protocol@19 node with patch 5/6 blocklist (if I get that right..)

I think this approach of a standalone SCMI alternative Pinctrl driver
that handles distinctly NXP OEM extensions and DT-parsing is certainly
more preferable than the original series you posted months ago where
custom NXP stuff were simply stuck on top of the Generic SCMI Pinctrl driver...

...what I still dont understand is why you exported data and structure
from pincttl-scmi.c to use it here; when NXP pinctrl is active the
standard Linux generic Pinctrl driver wont be alive, so not probed, so
no data can be shared, the only thing I can imagine is that you are
just trying to avoid duplicating a dozen lines from the logic of
scmi_pinctrl_get_pins() into your new NXP driver.

In this way, though, you are creating a dependency between 2 drivers,
that are not even allowed to cohexist at runtime really (due to the
blocklist trick).

Am I missing something ?

If not, I think it will be much better to just rewrite that few lines of
scmi_pincrtrl_pins_get trivial logic into your NXP driver and keep the 2
drivers fully distinct at all times.

Thanks,
Cristian


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-05-01 12:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-28  5:07 [PATCH v3 0/6] pinctrl: scmi: support i.MX95 OEM extensions Peng Fan (OSS)
2024-04-28  5:07 ` [PATCH v3 1/6] dt-bindings: firmware: arm,scmi: Add properties for i.MX95 Pinctrl " Peng Fan (OSS)
2024-04-28  5:07 ` [PATCH v3 2/6] pinctrl: scmi: move pinctrl_ops to scmi_pinctrl Peng Fan (OSS)
2024-04-28  5:07 ` [PATCH v3 3/6] pinctrl: core: guard with __PINCTRL_CORE_H Peng Fan (OSS)
2024-04-28  5:07 ` [PATCH v3 4/6] pinctrl: scmi: export pinctrl_scmi_get_pins Peng Fan (OSS)
2024-05-01 12:36   ` Cristian Marussi [this message]
2024-05-01 12:42     ` Peng Fan
2024-04-28  5:07 ` [PATCH v3 5/6] pinctrl: scmi: add blocklist Peng Fan (OSS)
2024-04-28  5:07 ` [PATCH v3 6/6] pinctrl: imx: support SCMI pinctrl protocol for i.MX95 Peng Fan (OSS)
2024-04-28 12:11   ` Dan Carpenter
2024-04-28 12:21     ` Peng Fan

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=ZjI3abJUIgo4xgRu@pluto \
    --to=cristian.marussi@arm.com \
    --cc=aisheng.dong@nxp.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --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=peng.fan@nxp.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=ping.bai@nxp.com \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).