netdev - Re: Need input on placement of driver

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: <CA+sq2Ce65Ufj4hrjcKW2cVJzDvC1_ZVNVdugwi3fxaboibWemg@mail.gmail.com>
Date:   Sat, 15 Sep 2018 09:10:47 +0530
From:   Sunil Kovvuri <sunil.kovvuri@...il.com>
To:     "David S. Miller" <davem@...emloft.net>
Cc:     Linux Netdev List <netdev@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: Need input on placement of driver

On Wed, Sep 12, 2018 at 10:20 PM Sunil Kovvuri <sunil.kovvuri@...il.com> wrote:
>
> Hi David,
>
> I am trying to submit a driver into drivers/soc folder and Arnd is of
> the opinion that
> the driver should be moved to drivers/net/ethernet.
>
> Can you please go through below and give your feedback.
>
> HW functionality in brief
> # HW has a Admin function (AF) PCI device which has privilege access
> to configure co-processors.
> # Co-processors include network block, crypto block, ring buffer block
> used by both network and crypto blocks, packet or anyother work
> scheduler block, ingress/egress packet parser and forwarding block,
> internal state machine caches etc.
> # Each of these blocks are multiple in number and can be attached to
> other PCI devices.
> # Future variants of the same silicon might have additional functional
> blocks in AF.
> # There are other SRIOV PF/VF devices which are dumb at power-on and
> acquire functionality based
>     what blocks are attached to them by AF.
> # So AF is the one which configures, facilities and manages all HW
> resources (network and non-network).
>    But doesn't handle any data.
> # PF/VFs communicate with AF via a shared mailbox memory for functional block
>    attach / detach requests, HW configuration etc etc.
>
> AF driver will have logic not only the functionality needed by kernel
> netdev or crypto drivers but
> also the HW configuration logic needed by userspace application drivers.
>
> Keeping current and future functionality in view we thought of having
> 3 drivers in kernel
> # AF driver at drivers/soc
> # PF/ VF netdev driver (network & ring buffer blocks attached to these
> devices) at drivers/net/ethernet
> # PF / VF crypto driver (ring buffer and crypto blocks attached to
> these devices) at drivers/crypto.
>
> I have submitted few patches for the AF driver
> https://patchwork.kernel.org/cover/10587635/
>
> Here Arnd has opined that all drivers should move into drivers/net/ethernet.
> So wanted to check if you would be okay with this.
>
> Thanks,
> Sunil.


Hi David,

Sorry for the reminder.
It would be great to have your feedback / inputs.

Thanks,
Sunil.