linux-kernel - Re: [PATCH v6 36/37] firmware: arm_scmi: add protocol modularization support

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210309080456.GB47884@e120937-lin>
Date:   Tue, 9 Mar 2021 08:04:56 +0000
From:   Cristian Marussi <cristian.marussi@....com>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        lukasz.luba@....com, james.quinlan@...adcom.com,
        Jonathan.Cameron@...wei.com, f.fainelli@...il.com,
        etienne.carriere@...aro.org, thara.gopinath@...aro.org,
        vincent.guittot@...aro.org, souvik.chakravarty@....com,
        cristian.marussi@....com
Subject: Re: [PATCH v6 36/37] firmware: arm_scmi: add protocol modularization
 support

Hi Sudeep,

On Mon, Mar 08, 2021 at 07:34:25AM +0000, Sudeep Holla wrote:
> On Tue, Feb 02, 2021 at 10:15:54PM +0000, Cristian Marussi wrote:
> > Extend SCMI protocols accounting mechanism to address possible module
> > usage and add the support to possibly define new protocols as loadable
> > modules.
> >
> > Keep Standard protocols built into the SCMI core.
> >
> 
> The changes look good, however without any users I am bit hesitant to add
> this yet. However if you think it is hard to maintain it outside the tree
> until first user gets merged, we can merge provided we test this every
> release. Let me know your thoughts.
> 

On one side this series aimed not only at simplifying the API exposed to
the drivers/protocols but also to unify such API betweeen custom and standard
protocols and drivers, so that whatever custom proto and driver you wrote, you
are anyway going to exercise the same API and triggering the same internals
as the standard protos, so to avoid the issue of having to expose/support
an API not used by anyone (still)....

...on the other side, indeed, you are right that this specific thin patch
WON'T be really tested/exercised indeed until a custon protocol module is
upstreamed...if ever.

For me it's fine to test it every cycle with my custom dummy protocol,
and maybe it could be an incentive for partners to post finally upstream
their protos if all the support is already there in the mainline (I know,
I'm a dreamer :D), but better would be as a future alternative (not for
this series though) to enable (in some well guarded/controlled form) the
optional modularization of core standard protocols too (also to possibly
comply with ACK extreme modularization policies...), so that this patch
would be constantly exercised by our std protocol too.

But I have not really a strong opinion on this, if you want to keep this
out and merge only once a real custom proto appears or once we modularize
the core standard protocols (in a controlled manner as said), it's fine
for me too.

Thanks

Cristian

> Also any comment from users requesting this would be useful.
> 

> --
> Regards,
> Sudeep