<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/ethernet/freescale/gianfar.h, branch linux-4.3.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.3.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.3.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2016-01-23T04:55:50Z</updated>
<entry>
<title>gianfar: Don't enable RX Filer if not supported</title>
<updated>2016-01-23T04:55:50Z</updated>
<author>
<name>Hamish Martin</name>
<email>hamish.martin@alliedtelesis.co.nz</email>
</author>
<published>2015-12-15T01:14:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d46972df5551d3b4b5c3b4cc4abb45d613769e1e'/>
<id>urn:sha1:d46972df5551d3b4b5c3b4cc4abb45d613769e1e</id>
<content type='text'>
[ Upstream commit 7bff47da1ee23d00d1257905f2944c29594f799d ]

After commit 15bf176db1fb ("gianfar: Don't enable the Filer w/o the
Parser"), 'TSEC' model controllers (for example as seen on MPC8541E)
always have 8 bytes stripped from the front of received frames.
Only 'eTSEC' gianfar controllers have the RX Filer capability (amongst
other enhancements). Previously this was treated as always enabled
for both 'TSEC' and 'eTSEC' controllers.
In commit 15bf176db1fb ("gianfar: Don't enable the Filer w/o the Parser")
a subtle change was made to the setting of 'uses_rxfcb' to effectively
always set it (since 'rx_filer_enable' was always true). This had the
side-effect of always stripping 8 bytes from the front of received frames
on 'TSEC' type controllers.

We now only enable the RX Filer capability on controller types that
support it, thereby avoiding the issue for 'TSEC' type controllers.

Reviewed-by: Chris Packham &lt;chris.packham@alliedtelesis.co.nz&gt;
Reviewed-by: Mark Tomlinson &lt;mark.tomlinson@alliedtelesis.co.nz&gt;
Signed-off-by: Hamish Martin &lt;hamish.martin@alliedtelesis.co.nz&gt;
Reviewed-by: Claudiu Manoil &lt;claudiu.manoil@freescale.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net</title>
<updated>2015-08-01T06:52:20Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2015-08-01T06:52:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5510b3c2a173921374ec847848fb20b98e1c698a'/>
<id>urn:sha1:5510b3c2a173921374ec847848fb20b98e1c698a</id>
<content type='text'>
Conflicts:
	arch/s390/net/bpf_jit_comp.c
	drivers/net/ethernet/ti/netcp_ethss.c
	net/bridge/br_multicast.c
	net/ipv4/ip_fragment.c

All four conflicts were cases of simple overlapping
changes.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>gianfar: Enable device wakeup when appropriate</title>
<updated>2015-07-31T22:41:49Z</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@freescale.com</email>
</author>
<published>2015-07-31T15:38:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b0734b6dc895258b74c6e7a441cb47b6b0ba3465'/>
<id>urn:sha1:b0734b6dc895258b74c6e7a441cb47b6b0ba3465</id>
<content type='text'>
The wol_en flag is 0 by default anyway, and we have the
following inconsistency: a MAGIC packet wol capable eth
interface is registered as a wake-up source but unable
to wake-up the system as wol_en is 0 (wake-on flag set to 'd').
Calling set_wakeup_enable() at netdev open is just redundant
because wol_en is 0 by default.
Let only ethtool call set_wakeup_enable() for now.

The bflock is obviously obsoleted, its utility has been corroded
over time.  The bitfield flags used today in gianfar are accessed
only on the init/ config path, with no real possibility of
concurrency - nothing that would justify smth. like bflock.

Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@freescale.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>gianfar: Fix warnings when built on 64-bit</title>
<updated>2015-07-30T05:57:24Z</updated>
<author>
<name>Scott Wood</name>
<email>scottwood@freescale.com</email>
</author>
<published>2015-07-29T13:13:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b4b67f269d28c70174e11b7af7fbdb81124d220c'/>
<id>urn:sha1:b4b67f269d28c70174e11b7af7fbdb81124d220c</id>
<content type='text'>
As part of defconfig consolidation using fragments, we'd like to be
able to have the same drivers enabled on 32-bit and 64-bit.  Gianfar
happens to only exist on 32-bit systems, and when building the
resulting 64-bit kernel warnings were produced.

A couple of the warnings are trivial, but the rfbptr code has deeper
issues.  It uses the virtual address as the DMA address, which again,
happens to work in the environments where this driver is currently
used, but is not the right thing to do.

Fixes: 45b679c9a3cc ("gianfar: Implement PAUSE frame generation
support")
Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@freescale.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>gianfar: Add paged allocation and Rx S/G</title>
<updated>2015-07-16T00:13:24Z</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@freescale.com</email>
</author>
<published>2015-07-13T13:22:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=75354148ce697266b57c13d051ddffa3bb75fc9e'/>
<id>urn:sha1:75354148ce697266b57c13d051ddffa3bb75fc9e</id>
<content type='text'>
The eTSEC h/w is capable of scatter/gather on the receive side
too if MAXFRM &gt; MRBLR, when the allowed maximum Rx frame size
is set to be greater than the maximum Rx buffer size (MRBLR).
It's about time the driver makes use of this h/w capability,
by supporting fixed buffer sizes and Rx S/G.

The buffer size given to eTSEC for reception is fixed to
1536B (must be multiple of 64), which is the same default
buffer size as before, used to accommodate standard MTU
(1500B) size frames.  As before, eTSEC can receive frames of
up to 9600B.  Individual Rx buffers are mapped to page halves
(page size for eTSEC systems is 4KB).  The skb is built around
the first buffer of a frame (using build_skb()).  In case the
frame spans multiple buffers, the trailing buffers are added
as Rx fragments to the skb.  The last buffer in frame is marked
by the L status flag.  A mechanism is in place to reuse the pages
owned by the driver (for Rx) for subsequent receptions.

Supporting fixed size buffers allows the implementation of Rx S/G,
which in turn removes the memory pressure issues the driver had
before when MTU was set for jumbo frame reception.
Also, in most cases, the Rx path becomes faster due to Rx page
reusal, since the overhead of allocating new rx buffers is removed
from the fast path.

Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@freescale.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>gianfar: Use ndev, more Rx path cleanup</title>
<updated>2015-07-16T00:13:24Z</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@freescale.com</email>
</author>
<published>2015-07-13T13:22:05Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f23223f15fd7d359a08ea346a0a537ccaf417014'/>
<id>urn:sha1:f23223f15fd7d359a08ea346a0a537ccaf417014</id>
<content type='text'>
Use "ndev" instead of "dev", as the rx queue back pointer
to a net_device struct, to avoid name clashing with a
"struct device" reference.  This prepares the addition of a
"struct device" back pointer to the rx queue structure.

Remove duplicated rxq registration in the process.
Move napi_gro_receive() outside gfar_process_frame().

Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@freescale.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>gianfar: Bundle Rx allocation, cleanup</title>
<updated>2015-07-16T00:13:23Z</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@freescale.com</email>
</author>
<published>2015-07-13T13:22:03Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=76f31e8b0911e620ac9191c8d3775cc91ed65c4c'/>
<id>urn:sha1:76f31e8b0911e620ac9191c8d3775cc91ed65c4c</id>
<content type='text'>
Use a more common consumer/ producer index design to improve
rx buffer allocation.  Instead of allocating a single new buffer
(skb) on each iteration, bundle the allocation of several rx
buffers at a time.  This also opens the path for further memory
optimizations.

Remove useless check of rxq-&gt;rfbptr, since this patch touches
rx pause frame handling code as well.  rxq-&gt;rfbptr is always
initialized as part of Rx BD ring init.
Remove redundant (and misleading) 'amount_pull' parameter.

Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@freescale.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>gianfar: Make FCB access endian safe</title>
<updated>2015-03-15T23:56:47Z</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@freescale.com</email>
</author>
<published>2015-03-13T08:36:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=26eb9374f83d129f26a417fc3cc9b480fb47e5e4'/>
<id>urn:sha1:26eb9374f83d129f26a417fc3cc9b480fb47e5e4</id>
<content type='text'>
Use conversion macros to correctly access the BE
fields of the Rx and Tx Frame Control Block on LE CPUs.

Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@freescale.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>gianfar: Make BDs access endian safe</title>
<updated>2015-03-15T23:56:46Z</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@freescale.com</email>
</author>
<published>2015-03-13T08:36:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a7312d5803759c29c7f341428858d353caabf793'/>
<id>urn:sha1:a7312d5803759c29c7f341428858d353caabf793</id>
<content type='text'>
Use conversion macros to correctly access the BE
fields of the Rx and Tx Buffer Descriptors on LE CPUs.

Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@freescale.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: gianfar: add missing __iomem annotation</title>
<updated>2014-12-30T23:54:15Z</updated>
<author>
<name>Kevin Hao</name>
<email>haokexin@gmail.com</email>
</author>
<published>2014-12-24T06:05:45Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=03366a33db91abd298457b0f707187247f1a6b7d'/>
<id>urn:sha1:03366a33db91abd298457b0f707187247f1a6b7d</id>
<content type='text'>
Fix the following spare warning:
drivers/net/ethernet/freescale/gianfar.c:3521:60: warning: incorrect type in argument 1 (different address spaces)
drivers/net/ethernet/freescale/gianfar.c:3521:60:    expected unsigned int [noderef] &lt;asn:2&gt;*addr
drivers/net/ethernet/freescale/gianfar.c:3521:60:    got unsigned int [usertype] *rfbptr
drivers/net/ethernet/freescale/gianfar.c:205:16: warning: incorrect type in assignment (different address spaces)
drivers/net/ethernet/freescale/gianfar.c:205:16:    expected unsigned int [usertype] *rfbptr
drivers/net/ethernet/freescale/gianfar.c:205:16:    got unsigned int [noderef] &lt;asn:2&gt;*&lt;noident&gt;
drivers/net/ethernet/freescale/gianfar.c:2918:44: warning: incorrect type in argument 1 (different address spaces)
drivers/net/ethernet/freescale/gianfar.c:2918:44:    expected unsigned int [noderef] &lt;asn:2&gt;*addr
drivers/net/ethernet/freescale/gianfar.c:2918:44:    got unsigned int [usertype] *rfbptr

Signed-off-by: Kevin Hao &lt;haokexin@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
