Re: [PATCH v3 1/5] firmware: xilinx: Update firmware call interface to support additional arg

From: Greg KH <gregkh@linuxfoundation.org>
To: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Cc: michal.simek@amd.com, tanmay.shah@amd.com,
	mathieu.poirier@linaro.org, ben.levinsky@amd.com,
	nava.kishore.manne@amd.com, marex@denx.de, robh@kernel.org,
	arnd@arndb.de, ruanjinjie@huawei.com,
	sai.krishna.potthuri@amd.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Izhar Ameer Shaikh <izhar.ameer.shaikh@amd.com>
Subject: Re: [PATCH v3 1/5] firmware: xilinx: Update firmware call interface to support additional arg
Date: Sat, 21 Oct 2023 23:00:59 +0200	[thread overview]
Message-ID: <2023102105-frivolous-kindred-f566@gregkh> (raw)
In-Reply-To: <20231016111301.13369-2-jay.buddhabhatti@amd.com>

On Mon, Oct 16, 2023 at 04:12:57AM -0700, Jay Buddhabhatti wrote:
> System-level platform management layer (do_fw_call()) has support for
> maximum of 5 arguments as of now (1 EEMI API ID + 4 command arguments).
> In order to support new EEMI PM_IOCTL IDs (Secure Read/Write), this
> support must be extended to support one additional argument, which
> results in a configuration of - 1 EEMI API ID + 5 command arguments.
> 
> Update zynqmp_pm_invoke_fn() and do_fw_call() with this new definition
> containing additional argument. As a result, update all the references
> to pm invoke function with the updated definition.

There are simpler ways to do this to keep from having to constantly add
new parameters that do nothing to the existing calls.  Why not do this
in #defines that handle multiple arguments, or even simply functions
that can have less arguments to prevent this constant churn you go
through.

That will also make it more obvious that the other arguments mean
nothing for most of these callers, which is a good thing.

What is going to happen when you need to add support for another
argument?

thanks,

greg k-h