<feed xmlns='http://www.w3.org/2005/Atom'>
<title>litmus-rt-ext-res.git/drivers/net/ethernet/amd/xgbe, branch EXT-RES</title>
<subtitle>LITMUS^RT with extended reservations for Forbidden Zones paper @ RTAS'20</subtitle>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-ext-res.git/'/>
<entry>
<title>amd-xgbe: Fix jumbo MTU processing on newer hardware</title>
<updated>2017-03-30T07:41:21+00:00</updated>
<author>
<name>Lendacky, Thomas</name>
<email>Thomas.Lendacky@amd.com</email>
</author>
<published>2017-03-15T20:11:23+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-ext-res.git/commit/?id=fafc9555d87a19c78bcd43ed731c3a73bf0b37a9'/>
<id>fafc9555d87a19c78bcd43ed731c3a73bf0b37a9</id>
<content type='text'>
[ Upstream commit 622c36f143fc9566ba49d7cec994c2da1182d9e2 ]

Newer hardware does not provide a cumulative payload length when multiple
descriptors are needed to handle the data. Once the MTU increases beyond
the size that can be handled by a single descriptor, the SKB does not get
built properly by the driver.

The driver will now calculate the size of the data buffers used by the
hardware.  The first buffer of the first descriptor is for packet headers
or packet headers and data when the headers can't be split. Subsequent
descriptors in a multi-descriptor chain will not use the first buffer. The
second buffer is used by all the descriptors in the chain for payload data.
Based on whether the driver is processing the first, intermediate, or last
descriptor it can calculate the buffer usage and build the SKB properly.

Tested and verified on both old and new hardware.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.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>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 622c36f143fc9566ba49d7cec994c2da1182d9e2 ]

Newer hardware does not provide a cumulative payload length when multiple
descriptors are needed to handle the data. Once the MTU increases beyond
the size that can be handled by a single descriptor, the SKB does not get
built properly by the driver.

The driver will now calculate the size of the data buffers used by the
hardware.  The first buffer of the first descriptor is for packet headers
or packet headers and data when the headers can't be split. Subsequent
descriptors in a multi-descriptor chain will not use the first buffer. The
second buffer is used by all the descriptors in the chain for payload data.
Based on whether the driver is processing the first, intermediate, or last
descriptor it can calculate the buffer usage and build the SKB properly.

Tested and verified on both old and new hardware.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>amd-xgbe: Fix unused suspend handlers build warning</title>
<updated>2016-11-28T17:19:36+00:00</updated>
<author>
<name>Borislav Petkov</name>
<email>bp@suse.de</email>
</author>
<published>2016-11-26T20:53:52+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-ext-res.git/commit/?id=91eefaabf102c539e6f5531e9a1e5ed46d2b41ca'/>
<id>91eefaabf102c539e6f5531e9a1e5ed46d2b41ca</id>
<content type='text'>
Fix:

  drivers/net/ethernet/amd/xgbe/xgbe-main.c:835:12: warning: ‘xgbe_suspend’ defined
    but not used [-Wunused-function]
  drivers/net/ethernet/amd/xgbe/xgbe-main.c:855:12: warning: ‘xgbe_resume’ defined
    but not used [-Wunused-function]

I see it during randconfig builds here.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix:

  drivers/net/ethernet/amd/xgbe/xgbe-main.c:835:12: warning: ‘xgbe_suspend’ defined
    but not used [-Wunused-function]
  drivers/net/ethernet/amd/xgbe/xgbe-main.c:855:12: warning: ‘xgbe_resume’ defined
    but not used [-Wunused-function]

I see it during randconfig builds here.

Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Cc: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xgbe: constify get_netdev_ops and get_ethtool_ops</title>
<updated>2016-08-31T21:17:30+00:00</updated>
<author>
<name>stephen hemminger</name>
<email>stephen@networkplumber.org</email>
</author>
<published>2016-08-31T15:57:36+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-ext-res.git/commit/?id=ce0b15d1103102b78ad95739fa71e62fb16774bd'/>
<id>ce0b15d1103102b78ad95739fa71e62fb16774bd</id>
<content type='text'>
Casting away const is bad practice. Since this is ARM specific driver
don't have hardware actually test this.

Having getter functions for ops is really unnecessary code bloat, but
not going to touch that.

Signed-off-by: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Casting away const is bad practice. Since this is ARM specific driver
don't have hardware actually test this.

Having getter functions for ops is really unnecessary code bloat, but
not going to touch that.

Signed-off-by: Stephen Hemminger &lt;stephen@networkplumber.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>amd-xgbe: Reset running devices after resume from hibernate</title>
<updated>2016-08-29T04:25:47+00:00</updated>
<author>
<name>James Morse</name>
<email>james.morse@arm.com</email>
</author>
<published>2016-08-26T08:21:23+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-ext-res.git/commit/?id=a039b638592c8b967797d96f50bebfaa64964c3f'/>
<id>a039b638592c8b967797d96f50bebfaa64964c3f</id>
<content type='text'>
After resume from hibernate on arm64, any amd-xgbe devices that were
running when we hibernated are reported as down, even when it is not.

Re-plugging the cables does not cause the interface to come back, the
link must be marked as down then up via 'ip set link' using the serial
console.

This happens because the device has been power-cycled and possibly
re-initialised by firmware, whereas the driver's memory structures have
been restored from the hibernate image and the two do not agree.

Schedule a restart of the device after powerup in case the world changed
while we were asleep.

Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
After resume from hibernate on arm64, any amd-xgbe devices that were
running when we hibernated are reported as down, even when it is not.

Re-plugging the cables does not cause the interface to come back, the
link must be marked as down then up via 'ip set link' using the serial
console.

This happens because the device has been power-cycled and possibly
re-initialised by firmware, whereas the driver's memory structures have
been restored from the hibernate image and the two do not agree.

Schedule a restart of the device after powerup in case the world changed
while we were asleep.

Signed-off-by: James Morse &lt;james.morse@arm.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: amd-xgbe: use correct format specifier</title>
<updated>2016-08-01T20:32:51+00:00</updated>
<author>
<name>xypron.glpk@gmx.de</name>
<email>xypron.glpk@gmx.de</email>
</author>
<published>2016-07-31T08:07:18+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-ext-res.git/commit/?id=fb160ebd512c505e8d3a18b4f877c7edd24acb49'/>
<id>fb160ebd512c505e8d3a18b4f877c7edd24acb49</id>
<content type='text'>
i has been defined as unsigned int.
So use %u for output.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
i has been defined as unsigned int.
So use %u for output.

Signed-off-by: Heinrich Schuchardt &lt;xypron.glpk@gmx.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: relax setup_tc ndo op handle restriction</title>
<updated>2016-03-03T21:25:15+00:00</updated>
<author>
<name>John Fastabend</name>
<email>john.fastabend@gmail.com</email>
</author>
<published>2016-02-29T19:26:13+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-ext-res.git/commit/?id=5eb4dce3b3471ec9d1ea2945fa3d2bab4ac7e100'/>
<id>5eb4dce3b3471ec9d1ea2945fa3d2bab4ac7e100</id>
<content type='text'>
I added this check in setup_tc to multiple drivers,

 if (handle != TC_H_ROOT || tc-&gt;type != TC_SETUP_MQPRIO)

Unfortunately restricting to TC_H_ROOT like this breaks the old
instantiation of mqprio to setup a hardware qdisc. This patch
relaxes the test to only check the type to make it equivalent
to the check before I broke it. With this the old instantiation
continues to work.

A good smoke test is to setup mqprio with,

# tc qdisc add dev eth4 root mqprio num_tc 8 \
  map 0 1 2 3 4 5 6 7 \
  queues 0@0 1@1 2@2 3@3 4@4 5@5 6@6 7@7

Fixes: e4c6734eaab9 ("net: rework ndo tc op to consume additional qdisc handle paramete")
Reported-by: Singh Krishneil &lt;krishneil.k.singh@intel.com&gt;
Reported-by: Jake Keller &lt;jacob.e.keller@intel.com&gt;
CC: Murali Karicheri &lt;m-karicheri2@ti.com&gt;
CC: Shradha Shah &lt;sshah@solarflare.com&gt;
CC: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
CC: Ariel Elior &lt;ariel.elior@qlogic.com&gt;
CC: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
CC: Bruce Allan &lt;bruce.w.allan@intel.com&gt;
CC: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
CC: Don Skidmore &lt;donald.c.skidmore@intel.com&gt;
Signed-off-by: John Fastabend &lt;john.r.fastabend@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I added this check in setup_tc to multiple drivers,

 if (handle != TC_H_ROOT || tc-&gt;type != TC_SETUP_MQPRIO)

Unfortunately restricting to TC_H_ROOT like this breaks the old
instantiation of mqprio to setup a hardware qdisc. This patch
relaxes the test to only check the type to make it equivalent
to the check before I broke it. With this the old instantiation
continues to work.

A good smoke test is to setup mqprio with,

# tc qdisc add dev eth4 root mqprio num_tc 8 \
  map 0 1 2 3 4 5 6 7 \
  queues 0@0 1@1 2@2 3@3 4@4 5@5 6@6 7@7

Fixes: e4c6734eaab9 ("net: rework ndo tc op to consume additional qdisc handle paramete")
Reported-by: Singh Krishneil &lt;krishneil.k.singh@intel.com&gt;
Reported-by: Jake Keller &lt;jacob.e.keller@intel.com&gt;
CC: Murali Karicheri &lt;m-karicheri2@ti.com&gt;
CC: Shradha Shah &lt;sshah@solarflare.com&gt;
CC: Or Gerlitz &lt;ogerlitz@mellanox.com&gt;
CC: Ariel Elior &lt;ariel.elior@qlogic.com&gt;
CC: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
CC: Bruce Allan &lt;bruce.w.allan@intel.com&gt;
CC: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
CC: Don Skidmore &lt;donald.c.skidmore@intel.com&gt;
Signed-off-by: John Fastabend &lt;john.r.fastabend@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>amd-xgbe: Mask auto-negotiation interrupts in ISR</title>
<updated>2016-02-17T20:22:20+00:00</updated>
<author>
<name>Lendacky, Thomas</name>
<email>Thomas.Lendacky@amd.com</email>
</author>
<published>2016-02-17T17:49:28+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-ext-res.git/commit/?id=ced3fcae693b563b20ee8d2dba966760e6b771d4'/>
<id>ced3fcae693b563b20ee8d2dba966760e6b771d4</id>
<content type='text'>
Currently the auto-negotiation interrupt handling disables the irq
instead of masking off the interrupts. This was done because the phy
library was originally used to read and write the PCS registers, which
could not be performed in interrupt context. Now that the phy library is
no longer used to read and write the PCS registers the interrupts can be
masked off in the interrupt service routine eliminating the need to call
disable_irq/enable_irq. This also requires changing the protection mutex
to a spinlock.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently the auto-negotiation interrupt handling disables the irq
instead of masking off the interrupts. This was done because the phy
library was originally used to read and write the PCS registers, which
could not be performed in interrupt context. Now that the phy library is
no longer used to read and write the PCS registers the interrupts can be
masked off in the interrupt service routine eliminating the need to call
disable_irq/enable_irq. This also requires changing the protection mutex
to a spinlock.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>amd-xgbe: Check Rx queue fifos before stopping Rx DMA</title>
<updated>2016-02-17T20:22:20+00:00</updated>
<author>
<name>Lendacky, Thomas</name>
<email>Thomas.Lendacky@amd.com</email>
</author>
<published>2016-02-17T17:49:16+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-ext-res.git/commit/?id=c3727d61ea73a1df60bacd0b416e01282a94240b'/>
<id>c3727d61ea73a1df60bacd0b416e01282a94240b</id>
<content type='text'>
Check to be sure that the Rx queue fifos are empty before stopping the
Rx DMA channels.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Check to be sure that the Rx queue fifos are empty before stopping the
Rx DMA channels.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>amd-xgbe: Do traffic class setup when called through dcbnl</title>
<updated>2016-02-17T20:22:20+00:00</updated>
<author>
<name>Lendacky, Thomas</name>
<email>Thomas.Lendacky@amd.com</email>
</author>
<published>2016-02-17T17:49:08+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-ext-res.git/commit/?id=b3b715974bfe69f626d6a633b8c96590de1b7338'/>
<id>b3b715974bfe69f626d6a633b8c96590de1b7338</id>
<content type='text'>
Currently the netdev traffic class setup is only performed when invoked
through the ndo_setup_tc interface. However, the same setup should be
performed when the dcbnl interface (ieee_setets) is invoked. Rework the
netdev traffic class setup to be invokable through either interface and
also provide the priority to traffic class mapping if available.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently the netdev traffic class setup is only performed when invoked
through the ndo_setup_tc interface. However, the same setup should be
performed when the dcbnl interface (ieee_setets) is invoked. Rework the
netdev traffic class setup to be invokable through either interface and
also provide the priority to traffic class mapping if available.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>amd-xgbe: Fix the mapping of priorities to traffic classes</title>
<updated>2016-02-17T20:22:19+00:00</updated>
<author>
<name>Lendacky, Thomas</name>
<email>Thomas.Lendacky@amd.com</email>
</author>
<published>2016-02-17T17:48:57+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt-ext-res.git/commit/?id=6a49ee4e1b9eb8747ff79c5438a42c0726aaa03b'/>
<id>6a49ee4e1b9eb8747ff79c5438a42c0726aaa03b</id>
<content type='text'>
The driver is checking the pfc_en field of the ieee_pfc structure to
determine whether to associate a priority with a traffic class. This is
incorrect since the pfc_en field is for determining if PFC is enabled
for a traffic class.

The association of priority to traffic class does not depend on whether
the traffic class is enabled for PFC, so remove that check. Also, the
mapping of priorities to traffic classes should be done when configuring
the traffic classes and not the PFC support so move the priority to traffic
class association from xgbe_config_dcb_pfc to xgbe_config_dcb_tc.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The driver is checking the pfc_en field of the ieee_pfc structure to
determine whether to associate a priority with a traffic class. This is
incorrect since the pfc_en field is for determining if PFC is enabled
for a traffic class.

The association of priority to traffic class does not depend on whether
the traffic class is enabled for PFC, so remove that check. Also, the
mapping of priorities to traffic classes should be done when configuring
the traffic classes and not the PFC support so move the priority to traffic
class association from xgbe_config_dcb_pfc to xgbe_config_dcb_tc.

Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
</feed>
