On Tue, May 16, 2017 at 1:41 PM, Alexander Sverdlin
wrote:
> it turns out I've used this patch two weeks long already in 4.11; but I've
> spent
> a couple of hours now torturing the new driver and was not able to provoke
> any inadequate behavior. It either receives all packets in time or not at
Hello all,
On 15/05/17 23:02, Alexander Sverdlin wrote:
>>> I don't know if we really care about this hardware anymore (I don't),
>>> but the ep93xx platform is still listed as being maintained in the
>>> MAINTAINERS file -- adding Ryan and Hartley.
>> I no longer have any ep93xx hardware to test
Hi!
On Mon May 15 22:43:20 2017 Ryan Mallon wrote:
> > I don't know if we really care about this hardware anymore (I don't),
> > but the ep93xx platform is still listed as being maintained in the
> > MAINTAINERS file -- adding Ryan and Hartley.
>
> I no longer have any ep93xx hardware to test wi
On 15/05/17 20:31, Lennert Buytenhek wrote:
> On Sat, Feb 04, 2017 at 03:24:56PM -0800, Eric Dumazet wrote:
>
>> Use napi_complete_done() instead of __napi_complete() to :
>>
>> 1) Get support of gro_flush_timeout if opt-in
>> 2) Not rearm interrupts for busy-polling users.
>> 3) use standard NA
On Sat, Feb 04, 2017 at 03:24:56PM -0800, Eric Dumazet wrote:
> Use napi_complete_done() instead of __napi_complete() to :
>
> 1) Get support of gro_flush_timeout if opt-in
> 2) Not rearm interrupts for busy-polling users.
> 3) use standard NAPI API.
> 4) get rid of baroque code and ease maintena
Use napi_complete_done() instead of __napi_complete() to :
1) Get support of gro_flush_timeout if opt-in
2) Not rearm interrupts for busy-polling users.
3) use standard NAPI API.
4) get rid of baroque code and ease maintenance.
Signed-off-by: Eric Dumazet
---
drivers/net/ethernet/cirrus/ep93xx_