[PATCH net 0/3] be2net fixes

[PATCH net 0/3] be2net fixes

[Somnath Kotur]

Pls apply

Kalesh AP (2):
  be2net: Fix firmware download for Lancer
  be2net: avoid napi_disable() when it has not been enabled

Somnath Kotur (1):
  be2net: Fix to fail probe if MSI-X enable fails for a VF

 drivers/net/ethernet/emulex/benet/be.h         |    1 +
 drivers/net/ethernet/emulex/benet/be_cmds.c    |    2 +-
 drivers/net/ethernet/emulex/benet/be_main.c    |   24 ++++++++++++-------
 4 files changed, 25 insertions(+), 17 deletions(-)

Re: [PATCH net 0/3] be2net fixes

[David Miller]

From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Thu, 2 May 2013 19:06:14 +0530

> Pls apply
> 
> Kalesh AP (2):
>   be2net: Fix firmware download for Lancer
>   be2net: avoid napi_disable() when it has not been enabled
> 
> Somnath Kotur (1):
>   be2net: Fix to fail probe if MSI-X enable fails for a VF

Can you be2net knuckleheads possibly coordinate?

Please?

There was already a series submitted by Ajit and your work overlaps
and conflicts with his patch set applied.

I sorted out the merge problems and was able to apply your series too,
but you guys cannot have two patch sets for the same driver in flight
at the same time.

[PATCH net 0/3] be2net fixes

[Somnath Kotur]

Please apply.

Somnath Kotur (3):
  be2net: Fix Lancer error recovery to distinguish FW download
  be2net: Log a kernel message when the user tries to configure more
    Multicast addresses than supported
  be2net: Free/delete pmacs (in be_clear()) only if they exist

 drivers/net/ethernet/emulex/benet/be.h      |    1 +
 drivers/net/ethernet/emulex/benet/be_hw.h   |    3 +
 drivers/net/ethernet/emulex/benet/be_main.c |   72 +++++++++++++++++++-------
 3 files changed, 56 insertions(+), 20 deletions(-)

Re: [PATCH net 0/3] be2net fixes

[David Miller]

From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Thu, 5 Dec 2013 10:34:00 +0530

>   be2net: Log a kernel message when the user tries to configure more
>     Multicast addresses than supported

This is absolutely not appropriate.

RE: [PATCH net 0/3] be2net fixes

[Somnath Kotur]

> From: Somnath Kotur <somnath.kotur@emulex.com>
> Date: Thu, 5 Dec 2013 10:34:00 +0530
> 
> >   be2net: Log a kernel message when the user tries to configure more
> >     Multicast addresses than supported
> 
> This is absolutely not appropriate.
Hi Dave,
         	Sorry, but i'm not sure sure I understand what is the inappropriate part here ?
 Is it the fact that we chose to log a kernel message when the user tries to configure more MC addresses ? 

Thanks
Som

Re: [PATCH net 0/3] be2net fixes

[David Miller]

From: Somnath Kotur <Somnath.Kotur@Emulex.Com>
Date: Thu, 5 Dec 2013 05:38:21 +0000

>  Is it the fact that we chose to log a kernel message when the user
>  tries to configure more MC addresses ?

Yes.

This is absolutely not something an individual driver should
decide to do, _EVERY_ driver has this issue.

RE: [PATCH net 0/3] be2net fixes

[Somnath Kotur]

> This is absolutely not something an individual driver should decide to do,
> _EVERY_ driver has this issue.

OK, Understood, guess you want this to ideally be handled somewhere up in the stack/framework?

Meanwhile, I will  resend just the other 2 patches in the series , is that OK?

Thanks
Som

Re: [PATCH net 0/3] be2net fixes

[David Miller]

From: Somnath Kotur <Somnath.Kotur@Emulex.Com>
Date: Thu, 5 Dec 2013 06:24:10 +0000

>> This is absolutely not something an individual driver should decide to do,
>> _EVERY_ driver has this issue.
> 
> OK, Understood, guess you want this to ideally be handled somewhere up in the stack/framework?

I think it's pointless to do at all.

Re: [PATCH net 0/3] be2net fixes

[Ben Hutchings]

On Thu, 2013-12-05 at 01:28 -0500, David Miller wrote:
> From: Somnath Kotur <Somnath.Kotur@Emulex.Com>
> Date: Thu, 5 Dec 2013 06:24:10 +0000
> 
> >> This is absolutely not something an individual driver should decide to do,
> >> _EVERY_ driver has this issue.
> > 
> > OK, Understood, guess you want this to ideally be handled somewhere up in the stack/framework?
> 
> I think it's pointless to do at all.

It's not entirely pointless - if there is a lot of unwanted multicast
traffic the change to all-multicast can substantially increase CPU load
and the reason for this may not be obvious since there is no way to find
out the real state of the hardware filter (or even the real state of the
IFF_ALLMULTI flag).

The same may be true if an interface is automatically switched into
promiscuous mode, though switches can generally be assumed to filter
unicast traffic properly.

It seems like it would be useful to expose the real state of the
hardware filter to userland - just not through log messages.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: [PATCH net 0/3] be2net fixes

[David Miller]

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 5 Dec 2013 15:58:45 +0000

> It seems like it would be useful to expose the real state of the
> hardware filter to userland - just not through log messages.

This is what I meant.