[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a0wdXRmZOw+yyws00GU=xYAFkGm81xKTF3-DjNmjjZH5g@mail.gmail.com>
Date: Fri, 31 Aug 2018 16:20:03 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Sunil Kovvuri <sunil.kovvuri@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Olof Johansson <olof@...om.net>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
linux-soc@...r.kernel.org, sgoutham@...vell.com
Subject: Re: [PATCH 11/15] soc: octeontx2: Add Marvell OcteonTX2 CGX driver
On Thu, Aug 30, 2018 at 7:55 PM Sunil Kovvuri <sunil.kovvuri@...il.com> wrote:
> On Thu, Aug 30, 2018 at 7:37 PM Arnd Bergmann <arnd@...db.de> wrote:
> > On Tue, Aug 28, 2018 at 3:10 PM Sunil Kovvuri <sunil.kovvuri@...il.com> wrote:
> > Ok, I think I understand the PF/VF distinction now. One (to me)
> > surprising aspect here is that you not just have one physical function
> > that you can use to assign resources to multiple virtual functions,
> > but also a second level of virtualization that is used to assign
> > resources to "physical functions" that are less physical than the
> > name suggests.
>
> Yes, PF is just for name sake, on-boot there is no difference between
> PFs/VFs as such.
> PF0 has privilege access to assign resources to all PFs and their VFs.
> This admin function driver loads for PF0.
ok
> > The part that I have not grasped yet is what the split between
> > the CGX and the AF is for, how they relate to one another, and
> > what the software abstraction for the two is going to be.
>
> In HW, CGX is a separate PCI device which handles the serdes and
> physical ethernet interface.
> Ethernet driver in drivers/net/ethernet can only communicate to
> admin function driver since they share a mailbox memory.
> So we had to bind both CGX and admin function drivers to almost work as one,
> inorder to provide relavent info to ethernet drivers. That's why we
> have many functions
> from CGX driver which AF uses.
>
> eg: Firmware gets to know about a physical interface status change,
> which CGX driver gets
> to know and it uses AF's mailbox communication to inform ethernet
> driver about the event.
Would it make sense then to combine the CGX driver and the AF
driver into a single module? It sounds like you can never really
use one without the other anyway, and that would make it easier
to have a sensible abstraction to user space.
Arnd
Powered by blists - more mailing lists