On Mon, Oct 29, 2018 at 5:33 AM Sunil Kovvuri wrote:
> On Sat, Oct 27, 2018 at 12:59 AM Arnd Bergmann wrote:
> > On Fri, Oct 26, 2018 at 6:33 PM Sunil Kovvuri
> > wrote:
> > > On Fri, Oct 26, 2018 at 9:56 PM Sunil Kovvuri
> > > wrote:
> > Aside from this, there is the stuff that Andrew
On Sat, Oct 27, 2018 at 12:59 AM Arnd Bergmann wrote:
>
> On Fri, Oct 26, 2018 at 6:33 PM Sunil Kovvuri wrote:
> > On Fri, Oct 26, 2018 at 9:56 PM Sunil Kovvuri
> > wrote:
> > > On Fri, Oct 26, 2018 at 7:34 PM Arnd Bergmann wrote:
> > > > > On 10/26/18, Sunil Kovvuri wrote:
> > > > > On Fri,
On Fri, Oct 26, 2018 at 6:33 PM Sunil Kovvuri wrote:
> On Fri, Oct 26, 2018 at 9:56 PM Sunil Kovvuri wrote:
> > On Fri, Oct 26, 2018 at 7:34 PM Arnd Bergmann wrote:
> > > > On 10/26/18, Sunil Kovvuri wrote:
> > > > On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann wrote:
> > > >
> > > > As of now
From: Arnd Bergmann
Date: Fri, 26 Oct 2018 16:04:44 +0200
> I fear that setting a precedent of using the mbox for user-level
> configuration management would mean that we would have to
> treat each of these interfaces as an ABI, which in turn requires
> much deeper review as well as raising the
> No there is no need for any userspace tools.
Cool.
The problem with the Freescale architecture is that you seem to need
to provision the hardware. Tell it how many instances of various
things to create, and how to logically connect them together. They
have a user space tool to do this, in an
On Fri, Oct 26, 2018 at 9:56 PM Sunil Kovvuri wrote:
>
> On Fri, Oct 26, 2018 at 7:34 PM Arnd Bergmann wrote:
> >
> > On 10/26/18, Sunil Kovvuri wrote:
> > > On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann wrote:
> > >>
> > >> I see this has been applied, but I'd still like to understand better
On Fri, Oct 26, 2018 at 7:34 PM Arnd Bergmann wrote:
>
> On 10/26/18, Sunil Kovvuri wrote:
> > On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann wrote:
> >>
> >> I see this has been applied, but I'd still like to understand better how
> >> the
> >> configuration interface is expected to work once
On Fri, Oct 26, 2018 at 5:47 PM Andrew Lunn wrote:
>
> > I fear that setting a precedent of using the mbox for user-level
> > configuration management would mean that we would have to
> > treat each of these interfaces as an ABI, which in turn requires
> > much deeper review as well as raising
> I fear that setting a precedent of using the mbox for user-level
> configuration management would mean that we would have to
> treat each of these interfaces as an ABI, which in turn requires
> much deeper review as well as raising the fundamental question
> on how this should be done across
On 10/26/18, Sunil Kovvuri wrote:
> On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann wrote:
>>
>> I see this has been applied, but I'd still like to understand better how
>> the
>> configuration interface is expected to work once the driver is complete.
>>
>> In particular, so far the interfaces
On Fri, Oct 26, 2018 at 6:24 PM Arnd Bergmann wrote:
>
> On 10/23/18, David Miller wrote:
> > From: sunil.kovv...@gmail.com
> > Date: Mon, 22 Oct 2018 23:25:47 +0530
> >
> >> From: Sunil Goutham
> >>
> >> This patchset is a continuation to earlier submitted two patch
> >> series to add a new
On 10/23/18, David Miller wrote:
> From: sunil.kovv...@gmail.com
> Date: Mon, 22 Oct 2018 23:25:47 +0530
>
>> From: Sunil Goutham
>>
>> This patchset is a continuation to earlier submitted two patch
>> series to add a new driver for Marvell's OcteonTX2 SOC's
>> Resource virtualization unit (RVU)
From: sunil.kovv...@gmail.com
Date: Mon, 22 Oct 2018 23:25:47 +0530
> From: Sunil Goutham
>
> This patchset is a continuation to earlier submitted two patch
> series to add a new driver for Marvell's OcteonTX2 SOC's
> Resource virtualization unit (RVU) admin function driver.
>
> 1.
From: Sunil Goutham
This patchset is a continuation to earlier submitted two patch
series to add a new driver for Marvell's OcteonTX2 SOC's
Resource virtualization unit (RVU) admin function driver.
1. octeontx2-af: Add RVU Admin Function driver
14 matches
Mail list logo
