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: <CA+h21ho3NStn5BSBA1FjfRy6H0QTepGPyLT8xgCSB5af6PaHqg@mail.gmail.com>
Date:   Tue, 12 May 2020 03:10:52 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     David Miller <davem@...emloft.net>
Cc:     Xiaoliang Yang <xiaoliang.yang_1@....com>, Po Liu <po.liu@....com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandru Marginean <alexandru.marginean@....com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Li Yang <leoyang.li@....com>, Mingkai Hu <mingkai.hu@....com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Jiri Pirko <jiri@...nulli.us>,
        Ido Schimmel <idosch@...sch.org>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "Allan W. Nielsen" <allan.nielsen@...rochip.com>,
        Joergen Andreasen <joergen.andreasen@...rochip.com>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>,
        Vinicius Costa Gomes <vinicius.gomes@...el.com>,
        Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        linux-devel@...ux.nxdi.nxp.com
Subject: Re: [PATCH v1 net-next 2/3] net: dsa: felix: Configure Time-Aware
 Scheduler via taprio offload

On Tue, 12 May 2020 at 02:54, David Miller <davem@...emloft.net> wrote:
>
> From: Xiaoliang Yang <xiaoliang.yang_1@....com>
> Date: Mon, 11 May 2020 13:43:31 +0800
>
> > @@ -710,7 +714,7 @@ static void felix_port_policer_del(struct dsa_switch *ds, int port)
> >       ocelot_port_policer_del(ocelot, port);
> >  }
> >
> > -static const struct dsa_switch_ops felix_switch_ops = {
> > +static struct dsa_switch_ops felix_switch_ops = {
> >       .get_tag_protocol       = felix_get_tag_protocol,
> >       .setup                  = felix_setup,
> >       .teardown               = felix_teardown,
>
> There has to be a better way to do this, removing const for operation
> structs is very undesirable.

Actually I think this was at my suggestion, but now I agree that it is
a bit undesirable.
struct felix_info is on its toes in case vsc7511 or any other switch
revision will be added to the felix driver. It is likely that those
other chips will have hardware support for a different set of qdiscs.
So we thought of populating the .port_setup_tc conditionally,
depending on chip version (while also having DSA return -EOPNOTSUPP
automatically when the function pointer is NULL). Otherwise an extra
function call would be needed. But I think that keeping felix flexible
for more hardware revisions is a concern to be had for another
time/somebody else.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ