<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/drivers/net/ethernet/sfc, branch linus/master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/drivers/net/ethernet/sfc?h=linus%2Fmaster</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/drivers/net/ethernet/sfc?h=linus%2Fmaster'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-06-02T00:47:17Z</updated>
<entry>
<title>sfc/siena: fix wrong tx channel offset with efx_separate_tx_channels</title>
<updated>2022-06-02T00:47:17Z</updated>
<author>
<name>Íñigo Huguet</name>
<email>ihuguet@redhat.com</email>
</author>
<published>2022-06-01T06:36:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=25bde571b4a83a73bb37beacb833bbd9c38b43c6'/>
<id>urn:sha1:25bde571b4a83a73bb37beacb833bbd9c38b43c6</id>
<content type='text'>
tx_channel_offset is calculated in efx_allocate_msix_channels, but it is
also calculated again in efx_set_channels because it was originally done
there, and when efx_allocate_msix_channels was introduced it was
forgotten to be removed from efx_set_channels.

Moreover, the old calculation is wrong when using
efx_separate_tx_channels because now we can have XDP channels after the
TX channels, so n_channels - n_tx_channels doesn't point to the first TX
channel.

Remove the old calculation from efx_set_channels, and add the
initialization of this variable if MSI or legacy interrupts are used,
next to the initialization of the rest of the related variables, where
it was missing.

This has been already done for sfc, do it also for sfc_siena.

Fixes: 3990a8fffbda ("sfc: allocate channels for XDP tx queues")
Reported-by: Tianhao Zhao &lt;tizhao@redhat.com&gt;
Signed-off-by: Íñigo Huguet &lt;ihuguet@redhat.com&gt;
Acked-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc/siena: fix considering that all channels have TX queues</title>
<updated>2022-06-02T00:47:16Z</updated>
<author>
<name>Martin Habets</name>
<email>habetsm.xilinx@gmail.com</email>
</author>
<published>2022-06-01T06:36:02Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=183614bff5fc1682240ab7604201e18afb118092'/>
<id>urn:sha1:183614bff5fc1682240ab7604201e18afb118092</id>
<content type='text'>
Normally, all channels have RX and TX queues, but this is not true if
modparam efx_separate_tx_channels=1 is used. In that cases, some
channels only have RX queues and others only TX queues (or more
preciselly, they have them allocated, but not initialized).

Fix efx_channel_has_tx_queues to return the correct value for this case
too.

This has been already done for sfc, do it also for sfc_siena.

Messages shown at probe time before the fix:
 sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0
 ------------[ cut here ]------------
 netdevice: ens6f0np0: failed to initialise TXQ -1
 WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc]
 [...] stripped
 RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc]
 [...] stripped
 Call Trace:
  efx_init_tx_queue+0xaa/0xf0 [sfc]
  efx_start_channels+0x49/0x120 [sfc]
  efx_start_all+0x1f8/0x430 [sfc]
  efx_net_open+0x5a/0xe0 [sfc]
  __dev_open+0xd0/0x190
  __dev_change_flags+0x1b3/0x220
  dev_change_flags+0x21/0x60
 [...] stripped

Messages shown at remove time before the fix:
 sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues
 sfc 0000:03:00.0 ens6f0np0: failed to flush queues

Fixes: 8700aff08984 ("sfc: fix channel allocation with brute force")
Reported-by: Tianhao Zhao &lt;tizhao@redhat.com&gt;
Signed-off-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Tested-by: Íñigo Huguet &lt;ihuguet@redhat.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: fix wrong tx channel offset with efx_separate_tx_channels</title>
<updated>2022-05-29T11:12:53Z</updated>
<author>
<name>Íñigo Huguet</name>
<email>ihuguet@redhat.com</email>
</author>
<published>2022-05-27T08:05:29Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c308dfd1b43ef0d4c3e57b741bb3462eb7a7f4a2'/>
<id>urn:sha1:c308dfd1b43ef0d4c3e57b741bb3462eb7a7f4a2</id>
<content type='text'>
tx_channel_offset is calculated in efx_allocate_msix_channels, but it is
also calculated again in efx_set_channels because it was originally done
there, and when efx_allocate_msix_channels was introduced it was
forgotten to be removed from efx_set_channels.

Moreover, the old calculation is wrong when using
efx_separate_tx_channels because now we can have XDP channels after the
TX channels, so n_channels - n_tx_channels doesn't point to the first TX
channel.

Remove the old calculation from efx_set_channels, and add the
initialization of this variable if MSI or legacy interrupts are used,
next to the initialization of the rest of the related variables, where
it was missing.

Fixes: 3990a8fffbda ("sfc: allocate channels for XDP tx queues")
Reported-by: Tianhao Zhao &lt;tizhao@redhat.com&gt;
Signed-off-by: Íñigo Huguet &lt;ihuguet@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sfc: fix considering that all channels have TX queues</title>
<updated>2022-05-29T11:12:53Z</updated>
<author>
<name>Martin Habets</name>
<email>habetsm.xilinx@gmail.com</email>
</author>
<published>2022-05-27T08:05:28Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=2e102b53f8a778f872dc137f4c7ac548705817aa'/>
<id>urn:sha1:2e102b53f8a778f872dc137f4c7ac548705817aa</id>
<content type='text'>
Normally, all channels have RX and TX queues, but this is not true if
modparam efx_separate_tx_channels=1 is used. In that cases, some
channels only have RX queues and others only TX queues (or more
preciselly, they have them allocated, but not initialized).

Fix efx_channel_has_tx_queues to return the correct value for this case
too.

Messages shown at probe time before the fix:
 sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0
 ------------[ cut here ]------------
 netdevice: ens6f0np0: failed to initialise TXQ -1
 WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc]
 [...] stripped
 RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc]
 [...] stripped
 Call Trace:
  efx_init_tx_queue+0xaa/0xf0 [sfc]
  efx_start_channels+0x49/0x120 [sfc]
  efx_start_all+0x1f8/0x430 [sfc]
  efx_net_open+0x5a/0xe0 [sfc]
  __dev_open+0xd0/0x190
  __dev_change_flags+0x1b3/0x220
  dev_change_flags+0x21/0x60
 [...] stripped

Messages shown at remove time before the fix:
 sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues
 sfc 0000:03:00.0 ens6f0np0: failed to flush queues

Fixes: 8700aff08984 ("sfc: fix channel allocation with brute force")
Reported-by: Tianhao Zhao &lt;tizhao@redhat.com&gt;
Signed-off-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Tested-by: Íñigo Huguet &lt;ihuguet@redhat.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sfc/siena: Remove duplicate check on segments</title>
<updated>2022-05-20T23:46:49Z</updated>
<author>
<name>Martin Habets</name>
<email>habetsm.xilinx@gmail.com</email>
</author>
<published>2022-05-19T07:17:15Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=cc398a34d16fd90a2dcc59b1105c634f038ea53b'/>
<id>urn:sha1:cc398a34d16fd90a2dcc59b1105c634f038ea53b</id>
<content type='text'>
Siena only supports software TSO. This means more code can be deleted,
as pointed out by the Smatch static checker warning:
	drivers/net/ethernet/sfc/siena/tx.c:184 __efx_siena_enqueue_skb()
	warn: duplicate check 'segments' (previous on line 158)

Fixes: 956f2d86cb37 ("sfc/siena: Remove build references to missing functionality")
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Link: https://lore.kernel.org/kernel-janitors/YoH5tJMnwuGTrn1Z@kili/
Signed-off-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Link: https://lore.kernel.org/r/165294463549.23865.4557617334650441347.stgit@palantir17.mph.net
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: siena: Have a unique wrapper ifndef for efx channels header</title>
<updated>2022-05-19T03:07:58Z</updated>
<author>
<name>Saeed Mahameed</name>
<email>saeedm@nvidia.com</email>
</author>
<published>2022-05-18T06:58:20Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=309ec443079b0c6fcfb93a62c2554a164ade3f3e'/>
<id>urn:sha1:309ec443079b0c6fcfb93a62c2554a164ade3f3e</id>
<content type='text'>
Both sfc/efx_channels.h and sfc/siena/efx_channels.h used the same
wrapper #ifndef EFX_CHANNELS_H, this patch changes the siena define to be
EFX_SIENA_CHANNELS_H to avoid build system confusion.

This fixes the following build break:
drivers/net/ethernet/sfc/ptp.c:2191:28:
error: ‘efx_copy_channel’ undeclared here (not in a function); did you mean ‘efx_ptp_channel’?
  2191 |  .copy                   = efx_copy_channel,

Fixes: 6e173d3b4af9 ("sfc: Copy shared files needed for Siena (part 1)")
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Cc: Edward Cree &lt;ecree.xilinx@gmail.com&gt;
Acked-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Link: https://lore.kernel.org/r/20220518065820.131611-1-saeed@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: allow gso_max_size to exceed 65536</title>
<updated>2022-05-16T09:18:55Z</updated>
<author>
<name>Alexander Duyck</name>
<email>alexanderduyck@fb.com</email>
</author>
<published>2022-05-13T18:33:57Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=7c4e983c4f3cf94fcd879730c6caa877e0768a4d'/>
<id>urn:sha1:7c4e983c4f3cf94fcd879730c6caa877e0768a4d</id>
<content type='text'>
The code for gso_max_size was added originally to allow for debugging and
workaround of buggy devices that couldn't support TSO with blocks 64K in
size. The original reason for limiting it to 64K was because that was the
existing limits of IPv4 and non-jumbogram IPv6 length fields.

With the addition of Big TCP we can remove this limit and allow the value
to potentially go up to UINT_MAX and instead be limited by the tso_max_size
value.

So in order to support this we need to go through and clean up the
remaining users of the gso_max_size value so that the values will cap at
64K for non-TCPv6 flows. In addition we can clean up the GSO_MAX_SIZE value
so that 64K becomes GSO_LEGACY_MAX_SIZE and UINT_MAX will now be the upper
limit for GSO_MAX_SIZE.

v6: (edumazet) fixed a compile error if CONFIG_IPV6=n,
               in a new sk_trim_gso_size() helper.
               netif_set_tso_max_size() caps the requested TSO size
               with GSO_MAX_SIZE.

Signed-off-by: Alexander Duyck &lt;alexanderduyck@fb.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>eth: sfc: remove remnants of the out-of-tree napi_weight module param</title>
<updated>2022-05-14T00:03:09Z</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2022-05-12T20:56:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c28678162b330c8d3bfc472db8c47c8e5e7726f1'/>
<id>urn:sha1:c28678162b330c8d3bfc472db8c47c8e5e7726f1</id>
<content type='text'>
Remove napi_weight statics which are set to 64 and never modified,
remnants of the out-of-tree napi_weight module param.

Acked-by: Edward Cree &lt;ecree.xilinx@gmail.com&gt;
Link: https://lore.kernel.org/r/20220512205603.1536771-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: siena: Fix Kconfig dependencies</title>
<updated>2022-05-13T17:18:57Z</updated>
<author>
<name>Ren Zhijie</name>
<email>renzhijie2@huawei.com</email>
</author>
<published>2022-05-13T01:27:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=f9a210c72d70c9a59cf989fb23fb01ff10d18136'/>
<id>urn:sha1:f9a210c72d70c9a59cf989fb23fb01ff10d18136</id>
<content type='text'>
If CONFIG_PTP_1588_CLOCK=m and CONFIG_SFC_SIENA=y, the siena driver will fail to link:

drivers/net/ethernet/sfc/siena/ptp.o: In function `efx_ptp_remove_channel':
ptp.c:(.text+0xa28): undefined reference to `ptp_clock_unregister'
drivers/net/ethernet/sfc/siena/ptp.o: In function `efx_ptp_probe_channel':
ptp.c:(.text+0x13a0): undefined reference to `ptp_clock_register'
ptp.c:(.text+0x1470): undefined reference to `ptp_clock_unregister'
drivers/net/ethernet/sfc/siena/ptp.o: In function `efx_ptp_pps_worker':
ptp.c:(.text+0x1d29): undefined reference to `ptp_clock_event'
drivers/net/ethernet/sfc/siena/ptp.o: In function `efx_siena_ptp_get_ts_info':
ptp.c:(.text+0x301b): undefined reference to `ptp_clock_index'

To fix this build error, make SFC_SIENA depends on PTP_1588_CLOCK.

Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Fixes: d48523cb88e0 ("sfc: Copy shared files needed for Siena (part 2)")
Signed-off-by: Ren Zhijie &lt;renzhijie2@huawei.com&gt;
Acked-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Link: https://lore.kernel.org/r/20220513012721.140871-1-renzhijie2@huawei.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc/siena: Reinstate SRIOV init/fini function calls</title>
<updated>2022-05-12T23:49:30Z</updated>
<author>
<name>Martin Habets</name>
<email>habetsm.xilinx@gmail.com</email>
</author>
<published>2022-05-11T16:20:25Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c374303969eac5639bd9230f1c7e7390cb92cc8e'/>
<id>urn:sha1:c374303969eac5639bd9230f1c7e7390cb92cc8e</id>
<content type='text'>
They were removed in the first series since they were not used for EF10.
Put that code back for Siena, with the prototypes in siena_sriov.h
since that file is a more applicable place for it.

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
</feed>
