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: <CAK8P3a15DxNYzaYmAbxEqAm2FCJS9KQFk8vBDqmSn9QUiw64=A@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ