linux-kernel - Re: [PATCH v3 10/22] firmware: arm_scmi: probe and initialise all the supported protocols

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]

Date:   Wed, 4 Oct 2017 13:06:20 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     ALKML <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Roy Franz <roy.franz@...ium.com>,
        Harb Abdulhamid <harba@...eaurora.org>,
        Nishanth Menon <nm@...com>, Loc Ho <lho@....com>,
        Alexey Klimov <alexey.klimov@....com>,
        Ryan Harkin <Ryan.Harkin@....com>,
        Jassi Brar <jassisinghbrar@...il.com>
Subject: Re: [PATCH v3 10/22] firmware: arm_scmi: probe and initialise all the
 supported protocols

On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla <sudeep.holla@....com> wrote:
> +static const struct scmi_protocol_match scmi_protocols[] = {
> +       {
> +               .protocol_id = SCMI_PROTOCOL_PERF,
> +               .fn = scmi_perf_protocol_init,
> +               .name = "scmi-cpufreq",
> +       }, {
> +               .protocol_id = SCMI_PROTOCOL_CLOCK,
> +               .fn = scmi_clock_protocol_init,
> +               .name = "scmi-clocks",
> +       }, {
> +               .protocol_id = SCMI_PROTOCOL_POWER,
> +               .fn = scmi_power_protocol_init,
> +               .name = "scmi-power-domain",
> +       }, {
> +               .protocol_id = SCMI_PROTOCOL_SENSOR,
> +               .fn = scmi_sensors_protocol_init,
> +               .name = "scmi-hwmon",
> +       },
> +       {}
> +};

This looks backwards from what we do elsewhere in the kernel,
and could be considered a layering violation: it requires a generic
part of of the driver to know about all the more specific ones,
and it means that we have to modify the global table here each
time we add another protocol.

Can you rewrite this to allow dynamic registration of the protocols?

       Arnd