m1600-dirver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6RNK1
CVE: NA

--------------------------------

The m1600 smart NIC is a series of network interface card
for the Data Center Area. The m1600 network card supports
checksum, sriov and other hardware offloading.
Signed-off-by: NYi Chen <open@nebula-matrix.com>

mainlist inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I72OPH
CVE: NA

Reference: https://patchwork.kernel.org/project/netdevbpf/patch/20230512100014.2522-5-lanhao@huawei.com/

----------------------------------------------------------------------

The timeout of the cmdq reset command has been increased to
resolve the reset timeout issue in the full VF scenario.
The timeout of other cmdq commands remains unchanged.

Fixes: 8d307f8e ("net: hns3: create new set of unified hclge_comm_cmd_send APIs")
Signed-off-by: NJijie Shao <shaojijie@huawei.com>
Signed-off-by: NHao Lan <lanhao@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

mainlist inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I72OPH
CVE: NA

Reference: https://patchwork.kernel.org/project/netdevbpf/patch/20230512100014.2522-2-lanhao@huawei.com/

----------------------------------------------------------------------

In function hns3_dump_tx_queue_info, The print buffer is not enough when
the tx BD number is configured to 32760. As a result several BD
information wouldn't be displayed.

So fix it by increasing the tx queue print buffer length.

Fixes: 630a6738 ("net: hns3: adjust string spaces of some parameters of tx bd info in debugfs")
Signed-off-by: NJie Wang <wangjie125@huawei.com>
Signed-off-by: NHao Lan <lanhao@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I72OPH
CVE: NA

----------------------------------------------------------------------

After the wol is commit to the linux community,
the code is different from the openEuler.
This patch synchronizes the kernel differences to the openEuler.
Signed-off-by: NHao Lan <lanhao@huawei.com>

mainline inclusion
from mainline-v6.3-rc4
commit 6b6bc5b8
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6ZWOL
CVE: CVE-2023-2483

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b6bc5b8bd2d4ca9e1efa9ae0f98a0b0687ace75

---------------------------

In emac_probe, &adpt->work_thread is bound with
emac_work_thread. Then it will be started by timeout
handler emac_tx_timeout or a IRQ handler emac_isr.

If we remove the driver which will call emac_remove
  to make cleanup, there may be a unfinished work.

The possible sequence is as follows:

Fix it by finishing the work before cleanup in the emac_remove
and disable timeout response.

CPU0                  CPU1

                    |emac_work_thread
emac_remove         |
free_netdev         |
kfree(netdev);      |
                    |emac_reinit_locked
                    |emac_mac_down
                    |//use netdev
Fixes: b9b17deb ("net: emac: emac gigabit ethernet controller driver")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
(cherry picked from commit 6b6bc5b8)
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6X8PA
CVE: NA

Reference: NA

---------------------------------

When using allyesconfig to configure the kernel,
errors may occur during the linking process when making.
Signed-off-by: Nzhoujiadong <zhoujiadong5@huawei.com>
Reviewed-by: NWulike (Collin) <wulike1@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6BSMN

-----------------------------------------------------------------------

For ROH distributed scenario, EID is allocated by DHCP mode.
Driver needs to convert the origin MAC address to EID format,
and updates the destination MAC, chaddr and client id(if exists)
when transmit DHCP packets. Meantime, the chaddr field should
follow the source mac address, in order to make the dhcp
server reply to the right client. For the payload of
dhcp packet changed, so the checksum of L4 should be
calculated too.
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NKe Chen <chenke54@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6YE0O
CVE: NA

----------------------------------------------------------------------

Add extend interface support for read and write
phy register with page. Sofar it supports only
Phy RTL8211 and YT8521.
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6YE0O
CVE: NA

----------------------------------------------------------------------

The patch supports the configuration of the position indicator and
error indicator modes.
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6YE0O
CVE: NA

----------------------------------------------------------------------

The patch provides a customized interface to modify the MAC mode.
Signed-off-by: Nwangpeiyang <wangpeiyang1@huawei.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6YE0O
CVE: NA

----------------------------------------------------------------------

This patch add support to get port wire type.
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6YE0O
CVE: NA

----------------------------------------------------------------------

When the link status of the PF network port changes from up to down,
the IMP can quickly report the link down fault cause based on the
link status. If the hardware is faulty from the beginning and the
link is not up, the IMP does not report the link down event
because the status is not changed.

Therefore, an interface is provided to detect port faults.
Signed-off-by: NJie Wang <wangjie125@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W
CVE: NA

----------------------------------------------------------------------

Currently hns3 driver supports vf fault detect feature. Several ras caused
by VF resources don't need to do PF function reset for recovery. The driver
only needs to notify specified VF to do reset.

So this patch use VF reset notification API for recovery.
Signed-off-by: NJie Wang <wangjie125@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W
CVE: NA

----------------------------------------------------------------------

This patch adds a build check to guarantee enum value and avoid future
issues.
Signed-off-by: NJie Wang <wangjie125@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W
CVE: NA

----------------------------------------------------------------------

To prevent the system from abnormally sending PFC frames after an
abnormal reset. If the reset type is not imp reset or global reset,
the system notifies the firmware to disable pfc before the reset.
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W
CVE: NA

----------------------------------------------------------------------

The patch provides a customized interface to modify the pause trans time
and retains the configured parameters.
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W
CVE: NA

----------------------------------------------------------------------

The patch disables the clocks of the PPP, PPU, IGU_EGU, ROCE, and
TM modules by configuring the network subctrl register.
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W
CVE: NA

----------------------------------------------------------------------

The patch supports the function of disabling and status query of lane
channels on a port. The patch traverses all covered lanes on the
port and powers off the serdes ds power.
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W
CVE: NA

----------------------------------------------------------------------

The patch provides an interface for enabling or disabling
the optical module.
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W
CVE: NA

----------------------------------------------------------------------

The patch provides an interface to check whether the optical module
is inserted.
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W
CVE: NA

----------------------------------------------------------------------

The patch provides a customized interface to modify the tx timeout.
Signed-off-by: NHao Chen <chenhao418@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

stable inclusion
from stable-v5.10.150
commit 2a1c29dc9b7e8c5dbc96ee3c20bb620984b69474
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0XA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2a1c29dc9b7e8c5dbc96ee3c20bb620984b69474

--------------------------------

[ Upstream commit ec3f06b5 ]

Should check of_iomap return value 'fep->fec.fecp' instead of 'fep->fcc.fccp'

Fixes: 976de6a8 ("fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.")
Signed-off-by: NZheng Yongjun <zhengyongjun3@huawei.com>
Reviewed-by: NChristophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.176
commit bfeeb3aaad4ee8eaaefe5d9edd9b2ccb5d9b7505
category: bugfix
bugzilla: 188641, https://gitee.com/src-openeuler/kernel/issues/I6R4MM
CVE: CVE-2023-1670

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bfeeb3aaad4ee8eaaefe5d9edd9b2ccb5d9b7505

--------------------------------

[ Upstream commit e8d20c3d ]

In xirc2ps_probe, the local->tx_timeout_task was bounded
with xirc2ps_tx_timeout_task. When timeout occurs,
it will call xirc_tx_timeout->schedule_work to start the
work.

When we call xirc2ps_detach to remove the driver, there
may be a sequence as follows:

Stop responding to timeout tasks and complete scheduled
tasks before cleanup in xirc2ps_detach, which will fix
the problem.

CPU0                  CPU1

                    |xirc2ps_tx_timeout_task
xirc2ps_detach      |
  free_netdev       |
    kfree(dev);     |
                    |
                    | do_reset
                    |   //use dev

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6SLBO
CVE: NA

----------------------------------------------------------------------

Currently the vf function reset needs to delay 5000ms for stack recovery.
This is too long for product configurations and cause configuration
failures. According to the tests, 500ms delay is enough for reset process
except PF FLR. So this patch adapts this delay in these scenarios.
Signed-off-by: NJie Wang <wangjie125@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6QRKC
CVE: NA

----------------------------------------------------------------------

The patch supports the query of port ext information.
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6QRKC
CVE: NA

----------------------------------------------------------------------

The patch provides a customized interface for configuring the interrupt
affinity of the hns3 network port.
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6QRKC
CVE: NA

----------------------------------------------------------------------

Some scenes use the standard tools ethtool and ifconfig to query traffic
statistics in a specified period.To facilitate calculation, the driver
needs to clear the original statistics first. The patch provides an
customized interface for clearing MAC statistics.
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6QRKC
CVE: NA

----------------------------------------------------------------------

Two network ports on a single chip can be physically connected to form
a 1d torus topology. TCP/UDP and RDMA communication between chip nodes
can be implemented without switches.The patch provide interfaces for
getting/setting 1d torus param.
Signed-off-by: NHao Chen <chenhao418@huawei.com>
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6QRKC
CVE: NA

----------------------------------------------------------------------

Services are switched only when no response is received within 10 seconds.
As a result, services cannot be switched quickly. Therefore, if the chip
is not suspended, the NIC sends a specific message to notify other nodes
of the event. In this way, the service switchover is performed quickly.
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6QRKC
CVE: NA

----------------------------------------------------------------------

To solve the problem of abnormal transmission of pauses or PFC frames,
the IMP periodically checks the transmission and reception status of
packets. If a pause frame storm occurs, the pause storm response of
the MAC address is disabled for a period of time.
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6QRKC
CVE: NA

----------------------------------------------------------------------

Establish a framework to support customization requirement. Provides
interfaces to register special processing functions. When the system
is reset due to an abnormal interrupt, the registered handler is
called first.
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I67J42
CVE: NA

-------------------------------------------------

The BMA software is a system management software offered by Huawei.
It supports the status monitoring, performance monitoring and
event monitoring of various components, including server CPUs,
memory hard disks, NICs, IB cards, PCIe cards,
RAID controller cards and optical modules.

In this version, the system resets due to the BMA spin lock
when the memory usage is too high, the vulnerability has been rectified.
Signed-off-by: NHuajingjing <huajingjing1@huawei.com>
Reviewed-by: NChenJiesong <chenjiesong@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.148
commit 73e1b27b58a6f5aa5a4955795a57d1613e58a61d
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0WL

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=73e1b27b58a6f5aa5a4955795a57d1613e58a61d

--------------------------------

[ Upstream commit 65e5d27d ]

If aq_nic_stop() fails, aq_ndev_close() returns err without calling
aq_nic_deinit() to release the relevant memory and resource, which
will lead to a memory leak.

We can fix it by deleting the if condition judgment and goto statement to
call aq_nic_deinit() directly after aq_nic_stop() to fix the memory leak.
Signed-off-by: NJianglei Nie <niejianglei2021@163.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.147
commit 84cab3531ff77583ef7e76cff025e76e2a748f3f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0W8

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=84cab3531ff77583ef7e76cff025e76e2a748f3f

--------------------------------

[ Upstream commit 49725ffc ]

This commit fixes DMA engine reset timeout issue in suspend/resume
with ADLink I-Pi SMARC Plus board which dmesg shows:
...
[   54.678271] PM: suspend exit
[   54.754066] intel-eth-pci 0000:00:1d.2 enp0s29f2: PHY [stmmac-3:01] driver [Maxlinear Ethernet GPY215B] (irq=POLL)
[   54.755808] intel-eth-pci 0000:00:1d.2 enp0s29f2: Register MEM_TYPE_PAGE_POOL RxQ-0
...
[   54.780482] intel-eth-pci 0000:00:1d.2 enp0s29f2: Register MEM_TYPE_PAGE_POOL RxQ-7
[   55.784098] intel-eth-pci 0000:00:1d.2: Failed to reset the dma
[   55.784111] intel-eth-pci 0000:00:1d.2 enp0s29f2: stmmac_hw_setup: DMA engine initialization failed
[   55.784115] intel-eth-pci 0000:00:1d.2 enp0s29f2: stmmac_open: Hw setup failed
...

The issue is related with serdes which impacts clock.  There is
serdes in ADLink I-Pi SMARC board ethernet controller. Please refer to
commit b9663b7c ("net: stmmac: Enable SERDES power up/down sequence")
for detial. When issue is reproduced, DMA engine clock is not ready
because serdes is not powered up.

To reproduce DMA engine reset timeout issue with hardware which has
serdes in GBE controller, install Ubuntu. In Ubuntu GUI, click
"Power Off/Log Out" -> "Suspend" menu, it disables network interface,
then goes to sleep mode. When it wakes up, it enables network
interface again. Stmmac driver is called in this way:

1. stmmac_release: Stop network interface. In this function, it
   disables DMA engine and network interface;
2. stmmac_suspend: It is called in kernel suspend flow. But because
   network interface has been disabled(netif_running(ndev) is
   false), it does nothing and returns directly;
3. System goes into S3 or S0ix state. Some time later, system is
   waken up by keyboard or mouse;
4. stmmac_resume: It does nothing because network interface has
   been disabled;
5. stmmac_open: It is called to enable network interace again. DMA
   engine is initialized in this API, but serdes is not power on so
   there will be DMA engine reset timeout issue.

Similarly, serdes powerdown should be added in stmmac_release.
Network interface might be disabled by cmd "ifconfig eth0 down",
DMA engine, phy and mac have been disabled in ndo_stop callback,
serdes should be powered down as well. It doesn't make sense that
serdes is on while other components have been turned off.

If ethernet interface is in enabled state(netif_running(ndev) is true)
before suspend/resume, the issue couldn't be reproduced  because serdes
could be powered up in stmmac_resume.

Because serdes_powerup is added in stmmac_open, it doesn't need to be
called in probe function.

Fixes: b9663b7c ("net: stmmac: Enable SERDES power up/down sequence")
Signed-off-by: NJunxiao Chang <junxiao.chang@intel.com>
Reviewed-by: NVoon Weifeng <weifeng.voon@intel.com>
Tested-by: NJimmy JS Chen <jimmyjs.chen@adlinktech.com>
Tested-by: NLooi, Hong Aun <hong.aun.looi@intel.com>
Link: https://lore.kernel.org/r/20220923050448.1220250-1-junxiao.chang@intel.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.147
commit 2c248c4681620e76d42ef16a14050e26bd07702d
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0W8

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2c248c4681620e76d42ef16a14050e26bd07702d

--------------------------------

[ Upstream commit c635ebe8 ]

The label passed to the QDESC_GET for the ETHOFLD TXQ, RXQ, and FLQ, is the
'out' one, which skips the 'out_unlock' label, and thus doesn't unlock the
'uld_mutex' before returning. Additionally, since commit 5148e595
("cxgb4: add EOTID tracking and software context dump"), the access to
these ETHOFLD hardware queues should be protected by the 'mqprio_mutex'
instead.

Fixes: 2d0cb84d ("cxgb4: add ETHOFLD hardware queue support")
Fixes: 5148e595 ("cxgb4: add EOTID tracking and software context dump")
Signed-off-by: NRafael Mendonca <rafaelmendsr@gmail.com>
Reviewed-by: NRahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Link: https://lore.kernel.org/r/20220922175109.764898-1-rafaelmendsr@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.146
commit 75ca7f44dab65b50c14e4838fc955fbcb6b87122
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=75ca7f44dab65b50c14e4838fc955fbcb6b87122

--------------------------------

[ Upstream commit 878e2405 ]

There is a separate receive path for small packets (under 256 bytes).
Instead of allocating a new dma-capable skb to be used for the next packet,
this path allocates a skb and copies the data into it (reusing the existing
sbk for the next packet). There are two bytes of junk data at the beginning
of every packet. I believe these are inserted in order to allow aligned DMA
and IP headers. We skip over them using skb_reserve. Before copying over
the data, we must use a barrier to ensure we see the whole packet. The
current code only synchronizes len bytes, starting from the beginning of
the packet, including the junk bytes. However, this leaves off the final
two bytes in the packet. Synchronize the whole packet.

To reproduce this problem, ping a HME with a payload size between 17 and
214

	$ ping -s 17 <hme_address>

which will complain rather loudly about the data mismatch. Small packets
(below 60 bytes on the wire) do not have this issue. I suspect this is
related to the padding added to increase the minimum packet size.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: NSean Anderson <seanga2@gmail.com>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20220920235018.1675956-1-seanga2@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.146
commit 8bd98cfbfcb031d1005ce9cc13a289908c045ef0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8bd98cfbfcb031d1005ce9cc13a289908c045ef0

--------------------------------

[ Upstream commit fed38e64 ]

The VF netdev driver shouldn't respond to changes in the NETIF_F_HW_TC
flag; only PFs should. Moreover, TSN-specific code should go to
enetc_qos.c, which should not be included in the VF driver.

Fixes: 79e49982 ("net: enetc: add hw tc hw offload features for PSPF capability")
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20220916133209.3351399-1-vladimir.oltean@nxp.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.146
commit b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7

--------------------------------

[ Upstream commit 0a242eb2 ]

Trying to get the channel from the tx_queue variable here is wrong
because we can only be here if tx_queue is NULL, so we shouldn't
dereference it. As the above comment in the code says, this is very
unlikely to happen, but it's wrong anyway so let's fix it.

I hit this issue because of a different bug that caused tx_queue to be
NULL. If that happens, this is the error message that we get here:
  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
  [...]
  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]

Fixes: 12804793 ("sfc: decouple TXQ type from label")
Reported-by: NTianhao Zhao <tizhao@redhat.com>
Signed-off-by: NÍñigo Huguet <ihuguet@redhat.com>
Acked-by: NEdward Cree <ecree.xilinx@gmail.com>
Link: https://lore.kernel.org/r/20220914111135.21038-1-ihuguet@redhat.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.146
commit b4afd3878f961d3517f27b3213730fceef77945c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b4afd3878f961d3517f27b3213730fceef77945c

--------------------------------

[ Upstream commit f232af42 ]

In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but
that's not correct if efx_sepparate_tx_channels is false. In that case,
the offset is 0 because the tx queues are in the single existing channel
at index 0, together with the rx queue.

Without this fix, as soon as you try to send any traffic, it tries to
get the tx queues from an uninitialized channel getting these errors:
  WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc]
  [...]
  RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc]
  [...]
  Call Trace:
   <IRQ>
   dev_hard_start_xmit+0xd7/0x230
   sch_direct_xmit+0x9f/0x360
   __dev_queue_xmit+0x890/0xa40
  [...]
  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
  [...]
  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]
  [...]
  Call Trace:
   <IRQ>
   dev_hard_start_xmit+0xd7/0x230
   sch_direct_xmit+0x9f/0x360
   __dev_queue_xmit+0x890/0xa40
  [...]

Fixes: c308dfd1 ("sfc: fix wrong tx channel offset with efx_separate_tx_channels")
Reported-by: NTianhao Zhao <tizhao@redhat.com>
Signed-off-by: NÍñigo Huguet <ihuguet@redhat.com>
Acked-by: NEdward Cree <ecree.xilinx@gmail.com>
Link: https://lore.kernel.org/r/20220914103648.16902-1-ihuguet@redhat.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.146
commit 2dbf487d6b381942665166be528fc06a61457206
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0VX

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2dbf487d6b381942665166be528fc06a61457206

--------------------------------

[ Upstream commit 198eb7e1 ]

While converting max_tx_rate from bytes to Mbps, this value was set to 0,
if the original value was lower than 125000 bytes (1 Mbps). This would
cause no transmission rate limiting to occur. This happened due to lack of
check of max_tx_rate against the 1 Mbps value for max_tx_rate and the
following division by 125000. Fix this issue by adding a helper
i40e_bw_bytes_to_mbits() which sets max_tx_rate to minimum usable value of
50 Mbps, if its value is less than 1 Mbps, otherwise do the required
conversion by dividing by 125000.

Fixes: 5ecae412 ("i40e: Refactor VF BW rate limiting")
Signed-off-by: NMichal Jaron <michalx.jaron@intel.com>
Signed-off-by: NAndrii Staikov <andrii.staikov@intel.com>
Tested-by: NBharathi Sreenivas <bharathi.sreenivas@intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: NZheng Zengkai <zhengzengkai@huawei.com>