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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2023102105-frivolous-kindred-f566@gregkh>
Date:   Sat, 21 Oct 2023 23:00:59 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Jay Buddhabhatti <jay.buddhabhatti@....com>
Cc:     michal.simek@....com, tanmay.shah@....com,
        mathieu.poirier@...aro.org, ben.levinsky@....com,
        nava.kishore.manne@....com, marex@...x.de, robh@...nel.org,
        arnd@...db.de, ruanjinjie@...wei.com, sai.krishna.potthuri@....com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Izhar Ameer Shaikh <izhar.ameer.shaikh@....com>
Subject: Re: [PATCH v3 1/5] firmware: xilinx: Update firmware call interface
 to support additional arg

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