<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/net/ethernet/intel/igb, branch linux-5.16.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.16.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.16.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-04-08T12:06:05Z</updated>
<entry>
<title>igb: refactor XDP registration</title>
<updated>2022-04-08T12:06:05Z</updated>
<author>
<name>Corinna Vinschen</name>
</author>
<published>2022-01-19T14:52:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=408db8ec1fa6b7f5ca786c9b99a87c2fda885b40'/>
<id>urn:sha1:408db8ec1fa6b7f5ca786c9b99a87c2fda885b40</id>
<content type='text'>
[ Upstream commit e62ad74aa534404b3ee7e250b114a3536ac56987 ]

On changing the RX ring parameters igb uses a hack to avoid a warning
when calling xdp_rxq_info_reg via igb_setup_rx_resources.  It just
clears the struct xdp_rxq_info content.

Instead, change this to unregister if we're already registered.  Align
code to the igc code.

Fixes: 9cbc948b5a20c ("igb: add XDP support")
Signed-off-by: Corinna Vinschen &lt;vinschen@redhat.com&gt;
Acked-by: Vinicius Costa Gomes &lt;vinicius.gomes@intel.com&gt;
Tested-by: Sandeep Penigalapati &lt;sandeep.penigalapati@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>igb: fix deadlock caused by taking RTNL in RPM resume path</title>
<updated>2021-12-21T02:48:09Z</updated>
<author>
<name>Heiner Kallweit</name>
</author>
<published>2021-12-20T20:18:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ac8c58f5b535d6272324e2b8b4a0454781c9147e'/>
<id>urn:sha1:ac8c58f5b535d6272324e2b8b4a0454781c9147e</id>
<content type='text'>
Recent net core changes caused an issue with few Intel drivers
(reportedly igb), where taking RTNL in RPM resume path results in a
deadlock. See [0] for a bug report. I don't think the core changes
are wrong, but taking RTNL in RPM resume path isn't needed.
The Intel drivers are the only ones doing this. See [1] for a
discussion on the issue. Following patch changes the RPM resume path
to not take RTNL.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=215129
[1] https://lore.kernel.org/netdev/20211125074949.5f897431@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/t/

Fixes: bd869245a3dc ("net: core: try to runtime-resume detached device in __dev_open")
Fixes: f32a21376573 ("ethtool: runtime-resume netdev parent before ethtool ioctl ops")
Tested-by: Martin Stolpe &lt;martin.stolpe@gmail.com&gt;
Signed-off-by: Heiner Kallweit &lt;hkallweit1@gmail.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Link: https://lore.kernel.org/r/20211220201844.2714498-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>igb: Fix removal of unicast MAC filters of VFs</title>
<updated>2021-12-15T19:08:18Z</updated>
<author>
<name>Karen Sornek</name>
</author>
<published>2021-08-31T11:16:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=584af82154f56e6b2740160fcc84a2966d969e15'/>
<id>urn:sha1:584af82154f56e6b2740160fcc84a2966d969e15</id>
<content type='text'>
Move checking condition of VF MAC filter before clearing
or adding MAC filter to VF to prevent potential blackout caused
by removal of necessary and working VF's MAC filter.

Fixes: 1b8b062a99dc ("igb: add VF trust infrastructure")
Signed-off-by: Karen Sornek &lt;karen.sornek@intel.com&gt;
Tested-by: Konrad Jankowski &lt;konrad0.jankowski@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>igb: fix netpoll exit with traffic</title>
<updated>2021-11-25T15:39:31Z</updated>
<author>
<name>Jesse Brandeburg</name>
</author>
<published>2021-11-23T20:40:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=eaeace60778e524a2820d0c0ad60bf80289e292c'/>
<id>urn:sha1:eaeace60778e524a2820d0c0ad60bf80289e292c</id>
<content type='text'>
Oleksandr brought a bug report where netpoll causes trace
messages in the log on igb.

Danielle brought this back up as still occurring, so we'll try
again.

[22038.710800] ------------[ cut here ]------------
[22038.710801] igb_poll+0x0/0x1440 [igb] exceeded budget in poll
[22038.710802] WARNING: CPU: 12 PID: 40362 at net/core/netpoll.c:155 netpoll_poll_dev+0x18a/0x1a0

As Alex suggested, change the driver to return work_done at the
exit of napi_poll, which should be safe to do in this driver
because it is not polling multiple queues in this single napi
context (multiple queues attached to one MSI-X vector). Several
other drivers contain the same simple sequence, so I hope
this will not create new problems.

Fixes: 16eb8815c235 ("igb: Refactor clean_rx_irq to reduce overhead and improve performance")
Reported-by: Oleksandr Natalenko &lt;oleksandr@natalenko.name&gt;
Reported-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Suggested-by: Alexander Duyck &lt;alexander.duyck@gmail.com&gt;
Signed-off-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Tested-by: Oleksandr Natalenko &lt;oleksandr@natalenko.name&gt;
Tested-by: Danielle Ratson &lt;danieller@nvidia.com&gt;
Link: https://lore.kernel.org/r/20211123204000.1597971-1-jesse.brandeburg@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>igb: unbreak I2C bit-banging on i350</title>
<updated>2021-10-29T16:42:59Z</updated>
<author>
<name>Jan Kundrát</name>
</author>
<published>2021-02-25T17:31:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a97f8783a9374a1527d88477c23039a6f3e8a909'/>
<id>urn:sha1:a97f8783a9374a1527d88477c23039a6f3e8a909</id>
<content type='text'>
The driver tried to use Linux' native software I2C bus master
(i2c-algo-bits) for exporting the I2C interface that talks to the SFP
cage(s) towards userspace. As-is, however, the physical SCL/SDA pins
were not moving at all, staying at logical 1 all the time.

The main culprit was the I2CPARAMS register where igb was not setting
the I2CBB_EN bit. That meant that all the careful signal bit-banging was
actually not being propagated to the chip pads (I verified this with a
scope).

The bit-banging was not correct either, because I2C is supposed to be an
open-collector bus, and the code was driving both lines via a totem
pole. The code was also trying to do operations which did not make any
sense with the i2c-algo-bits, namely manipulating both SDA and SCL from
igb_set_i2c_data (which is only supposed to set SDA). I'm not sure if
that was meant as an optimization, or was just flat out wrong, but given
that the i2c-algo-bits is set up to work with a totally dumb GPIO-ish
implementation underneath, there's no need for this code to be smart.

The open-drain vs. totem-pole is fixed by the usual trick where the
logical zero is implemented via regular output mode and outputting a
logical 0, and the logical high is implemented via the IO pad configured
as an input (thus floating), and letting the mandatory pull-up resistors
do the rest. Anything else is actually wrong on I2C where all devices
are supposed to have open-drain connection to the bus.

The missing I2CBB_EN is set (along with a safe initial value of the
GPIOs) just before registering this software I2C bus.

The chip datasheet mentions HW-implemented I2C transactions (SFP EEPROM
reads and writes) as well, but I'm not touching these for simplicity.

Tested on a LR-Link LRES2203PF-2SFP (which is an almost-miniPCIe form
factor card, a cable, and a module with two SFP cages). There was one
casualty, an old broken SFP we had laying around, which was used to
solder some thin wires as a DIY I2C breakout. Thanks for your service.
With this patch in place, I can `i2cdump -y 3 0x51 c` and read back data
which make sense. Yay.

Signed-off-by: Jan Kundrát &lt;jan.kundrat@cesnet.cz&gt;
See-also: https://www.spinics.net/lists/netdev/msg490554.html
Reviewed-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Tested-by: Tony Brelinski &lt;tony.brelinski@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>ethernet: use eth_hw_addr_set() for dev-&gt;addr_len cases</title>
<updated>2021-10-05T12:16:48Z</updated>
<author>
<name>Jakub Kicinski</name>
</author>
<published>2021-10-04T16:05:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a05e4c0af490ca7c22fc77120aafebebdeaaf537'/>
<id>urn:sha1:a05e4c0af490ca7c22fc77120aafebebdeaaf537</id>
<content type='text'>
Convert all Ethernet drivers from memcpy(... dev-&gt;addr_len)
to eth_hw_addr_set():

  @@
  expression dev, np;
  @@
  - memcpy(dev-&gt;dev_addr, np, dev-&gt;addr_len)
  + eth_hw_addr_set(dev, np)

In theory addr_len may not be ETH_ALEN, but we don't expect
non-Ethernet devices to live under this directory, and only
the following cases of setting addr_len exist:
 - cxgb4 for mgmt device,
and the drivers which set it to ETH_ALEN: s2io, mlx4, vxge.

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>ethtool: extend coalesce setting uAPI with CQE mode</title>
<updated>2021-08-24T14:38:29Z</updated>
<author>
<name>Yufeng Mo</name>
</author>
<published>2021-08-20T07:35:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f3ccfda1931977b80267ba54070a1aeafa18f6ca'/>
<id>urn:sha1:f3ccfda1931977b80267ba54070a1aeafa18f6ca</id>
<content type='text'>
In order to support more coalesce parameters through netlink,
add two new parameter kernel_coal and extack for .set_coalesce
and .get_coalesce, then some extra info can return to user with
the netlink API.

Signed-off-by: Yufeng Mo &lt;moyufeng@huawei.com&gt;
Signed-off-by: Huazhong Tan &lt;tanhuazhong@huawei.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>dev_ioctl: split out ndo_eth_ioctl</title>
<updated>2021-07-27T19:11:45Z</updated>
<author>
<name>Arnd Bergmann</name>
</author>
<published>2021-07-27T13:45:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a76053707dbf0dc020a73b4d90cd952409ef3691'/>
<id>urn:sha1:a76053707dbf0dc020a73b4d90cd952409ef3691</id>
<content type='text'>
Most users of ndo_do_ioctl are ethernet drivers that implement
the MII commands SIOCGMIIPHY/SIOCGMIIREG/SIOCSMIIREG, or hardware
timestamping with SIOCSHWTSTAMP/SIOCGHWTSTAMP.

Separate these from the few drivers that use ndo_do_ioctl to
implement SIOCBOND, SIOCBR and SIOCWANDEV commands.

This is a purely cosmetic change intended to help readers find
their way through the implementation.

Cc: Doug Ledford &lt;dledford@redhat.com&gt;
Cc: Jason Gunthorpe &lt;jgg@ziepe.ca&gt;
Cc: Jay Vosburgh &lt;j.vosburgh@gmail.com&gt;
Cc: Veaceslav Falico &lt;vfalico@gmail.com&gt;
Cc: Andy Gospodarek &lt;andy@greyhouse.net&gt;
Cc: Andrew Lunn &lt;andrew@lunn.ch&gt;
Cc: Vivien Didelot &lt;vivien.didelot@gmail.com&gt;
Cc: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Cc: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Cc: Leon Romanovsky &lt;leon@kernel.org&gt;
Cc: linux-rdma@vger.kernel.org
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>igb: Avoid memcpy() over-reading of ETH_SS_STATS</title>
<updated>2021-07-23T16:08:11Z</updated>
<author>
<name>Kees Cook</name>
</author>
<published>2021-06-16T19:53:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c9183f45e4ac1ff0f1140186cf8a6666c5f1277f'/>
<id>urn:sha1:c9183f45e4ac1ff0f1140186cf8a6666c5f1277f</id>
<content type='text'>
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally reading across neighboring array fields.

The memcpy() is copying the entire structure, not just the first array.
Adjust the source argument so the compiler can do appropriate bounds
checking.

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Tested-by: Tony Brelinski &lt;tonyx.brelinski@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
<entry>
<title>igb: Add counter to i21x doublecheck</title>
<updated>2021-07-23T16:08:11Z</updated>
<author>
<name>Grzegorz Siwik</name>
</author>
<published>2021-04-30T12:41:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=07be39e32d0aedef3a0155874b92dd7227aa94d7'/>
<id>urn:sha1:07be39e32d0aedef3a0155874b92dd7227aa94d7</id>
<content type='text'>
Add failed_counter to i21x_doublecheck(). There is possibility that
loop will never end.
With this patch the loop will stop after maximum 3 retries
to write to MTA_REGISTER

Signed-off-by: Grzegorz Siwik &lt;grzegorz.siwik@intel.com&gt;
Tested-by: Tony Brelinski &lt;tonyx.brelinski@intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
</content>
</entry>
</feed>
