Here's a proper patchset based on net-next.
v1 -> v2:
- Rebased on net-next
- Add Nicolas's Acks
- Reorder commits, putting the list_empty() cleanups prior to the
others.
- Added commit reverting the GFP_ATOMIC change.
Julia Cartwright (3):
net: macb: kill useless use
et: macb: Added support for RX filtering")
Cc: Rafal Ozieblo
Cc: Julia Lawall
Acked-by: Nicolas Ferre
Signed-off-by: Julia Cartwright
---
drivers/net/ethernet/cadence/macb_main.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/ca
The list_for_each_entry() macro already handles the case where the list
is empty (by not executing the loop body). It's not necessary to handle
this case specially, so stop doing so.
Cc: Rafal Ozieblo
Acked-by: Nicolas Ferre
Signed-off-by: Julia Cartwright
---
drivers/net/ethernet/ca
Now that the rx_fs_lock is no longer held across allocation, it's safe
to use GFP_KERNEL for allocating new entries.
This reverts commit 81da3bf6e3f88 ("net: macb: change GFP_KERNEL to
GFP_ATOMIC").
Cc: Julia Lawall
Signed-off-by: Julia Cartwright
---
drivers/net/ethernet/cade
The list_for_each_entry() macro already handles the case where the list
is empty (by not executing the loop body). It's not necessary to handle
this case specially, so stop doing so.
Cc: Rafal Ozieblo
Signed-off-by: Julia Cartwright
---
This is an additional cleanup patch found when looki
et: macb: Added support for RX filtering")
Cc: Rafal Ozieblo
Cc: Julia Lawall
Signed-off-by: Julia Cartwright
---
While Julia Lawall's cocci-generated patch fixes the problem, the right
solution is to obviate the problem altogether.
Thanks,
The Other Julia
drivers/net/ethernet
On Sat, Oct 15, 2016 at 12:06:33AM +0200, Richard Cochran wrote:
> On Fri, Oct 14, 2016 at 08:58:22AM +, Koehrer Mathias (ETAS/ESW5) wrote:
> > @@ -753,7 +756,9 @@ u32 igb_rd32(struct e1000_hw *hw, u32 re
> > if (E1000_REMOVED(hw_addr))
> > return ~value;
> >
> > +trac
+linux-pci
On Mon, Oct 17, 2016 at 08:39:40AM -0700, Alexander Duyck wrote:
> On Mon, Oct 17, 2016 at 8:00 AM, Koehrer Mathias (ETAS/ESW5)
> wrote:
> > Hi Julia!
> >> > > Have you tested on a vanilla (non-RT) kernel? I doubt there is
> >> > > anything RT specific about what you are seeing, but i
On Fri, Oct 14, 2016 at 08:58:22AM +, Koehrer Mathias (ETAS/ESW5) wrote:
> Hi Julia,
>
> > Have you tested on a vanilla (non-RT) kernel? I doubt there is anything RT
> > specific
> > about what you are seeing, but it might be nice to get confirmation. Also,
> > bisection
> > would probably
Hey Mathias-
On Thu, Oct 13, 2016 at 10:57:18AM +, Koehrer Mathias (ETAS/ESW5) wrote:
[..]
Interesting indeed!
> > Here are some places where I added traces:
> > In file igb_ptp.c:
> > void igb_ptp_rx_hang(struct igb_adapter *adapter) {
> > struct e1000_hw *hw = &adapter->hw;
> >
Hello Mathias-
On Fri, Oct 07, 2016 at 08:58:08AM +, Koehrer Mathias (ETAS/ESW5) wrote:
[..]
> I modified the in-kernel's igb_main.c (function igb_watchdog_task) to comment
> out
> the access to the EICS registers:
>
> --- igb_main.c.orig 2016-10-07 10:43:37.855873754 +0200
> +++ igb_mai
On Wed, Oct 05, 2016 at 07:02:21AM +, Koehrer Mathias (ETAS/ESW5) wrote:
> Hi Julia,
>
> > > In the meanwhile I have detected another finding which might be relevant:
> > >
> > > With the 3.18 kernel the igb driver comes with two interrupts per
> > > NIC (e.g. eth2 and eth2-TxRx0) with the 4.6
12 matches
Mail list logo
