On 04/29/2018 07:33 PM, David Miller wrote:
>
> I don't know if we really want all of these MIPS specific changes to
> go via the net-next tree.
>
> The right way to do this is probably getting this series into the MIPS
> architecture tree.
>
David,
Correct, and I should have been clearer about
From: "Steven J. Hill"
Date: Thu, 26 Apr 2018 18:30:10 -0500
> We want to add the Cavium OCTEON-III network driver. But since
> interacting with the input and output queues is done via special CPU
> local memory, we also need to add support to the MIPS/Octeon
> architect
We want to add the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way? These are the
prerequisite patches that are n
On 04/16/2018 08:29 AM, Steven J. Hill wrote:
> On 04/14/2018 07:08 PM, Florian Fainelli wrote:
>>
>> net-next tree is currently closed, but once it opens back up, you would
>> likely want to resubmit those patches. Last I remember they were ready
>> to go.
>>
> The announcement appears on this lis
On 04/14/2018 07:08 PM, Florian Fainelli wrote:
>
> net-next tree is currently closed, but once it opens back up, you would
> likely want to resubmit those patches. Last I remember they were ready
> to go.
>
The announcement appears on this list for when it is open, correct?
Hi Steven,
On 04/13/2018 03:43 PM, Steven J. Hill wrote:
> Patches for Cavium's Octeon III network driver were submitted by
> David Daney back on 20180222. David has since left the company and
> I am now responsible for the upstreaming effort. When looking at
> they are marked as "Not Applicable"
Patches for Cavium's Octeon III network driver were submitted by
David Daney back on 20180222. David has since left the company and
I am now responsible for the upstreaming effort. When looking at
they are marked as "Not Applicable". What
steps do I take next? Thanks.
Steve
We want to add the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way? These are the
prerequisite patches that are n
We want to add the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way? These are the
prerequisite patches that are n
David,
On Fri, Dec 8, 2017 at 1:09 AM, David Daney wrote:
[]
> Changes in v5:
[]
> o Removed redundant licensing text boilerplate.
Thank you very much!
Acked-by: Philippe Ombredanne
--
Cordially
Philippe Ombredanne, the licensing scruffy
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first five patches add the SoC support need
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first five patches add the SoC support need
The net-next tree is closed, please resubmit this when the net-next
tree opens again.
Thank you.
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first six patches add the SoC support need
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first six patches add the SoC support need
I need to send v3. With this v2 set, there is a small bug in the RX
initialization that causes failure on little-endian kernels.
David.
On 11/08/2017 04:51 PM, David Daney wrote:
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first six patches add the SoC support need
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first five patches add the SoC support need
18 matches
Mail list logo
