Re: [PATCH v2 3/3] firmware: arm_scmi: Add qcom hvc/shmem transport

From: Cristian Marussi <cristian.marussi@arm.com>
To: Nikunj Kela <quic_nkela@quicinc.com>
Cc: sudeep.holla@arm.com, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
	agross@kernel.org, andersson@kernel.org,
	konrad.dybcio@linaro.org, linux-arm-kernel@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v2 3/3] firmware: arm_scmi: Add qcom hvc/shmem transport
Date: Tue, 25 Jul 2023 18:03:04 +0100	[thread overview]
Message-ID: <ZMAASCqwMbqX7T7L@pluto> (raw)
In-Reply-To: <20230724164419.16092-4-quic_nkela@quicinc.com>

On Mon, Jul 24, 2023 at 09:44:19AM -0700, Nikunj Kela wrote:
> Add a new transport channel to the SCMI firmware interface driver for
> SCMI message exchange on Qualcomm virtual platforms.
> 
> The hypervisor associates an object-id also known as capability-id
> with each hvc doorbell object. The capability-id is used to identify the
> doorbell from the VM's capability namespace, similar to a file-descriptor.
> 
> The hypervisor, in addition to the function-id, expects the capability-id
> to be passed in x1 register when HVC call is invoked.
> 
> The qcom hvc doorbell/shared memory transport uses a statically defined
> shared memory region that binds with "arm,scmi-shmem" device tree node.
> 
> The function-id & capability-id are allocated by the hypervisor on bootup
> and are stored in the shmem region by the firmware before starting Linux.
> 
> Currently, there is no usecase for the atomic support therefore this driver
> doesn't include the changes for the same.
> 

Hi Nikunj,

so basically this new SCMI transport that you are introducing is just
exactly like the existing SMC transport with the only difference that
you introduced even another new way to configure func_id, a new cap_id
param AND the fact that you use HVC instead of SMC... all of this tied
to a new compatible to identify this new transport mechanism....
..but all in all is just a lot of plain duplicated code to maintain...

...why can't you fit this other smc/hvc transport variant into the
existing SMC transport by properly picking and configuring func_id/cap_id
and "doorbell" method (SMC vs HVC) in the chan_setup() step ?

..I mean ... you can decide where to pick your params based on
compatibles and also you can setup your invokation method (SMC vs HVC)
based on those...while keeping all the other stuff exactly the same...
...including support for atomic exchanges...if not, when you'll need that
too in your QC_HVC transport you'll have to duplicate also that (and my
bugs too probably :P)

(... well maybe in this scenario also the transport itself should be
renamed from SMC to something more general...)

Not sure if I am missing something, or if Sudeep will be horrified by
this unifying proposal of mine, but in this series as it stands now I
just see a lot of brutally duplicated stuff that just differs by naming
and a very minimal change in logic that could be addressed changing and
generalizing the original SMC transport code instead.

Thanks,
Cristian