* [PATCH 05/10] net: hisilicon: HI13X1_GMAX need dreq reset at first
From: Jiangfeng Xiao @ 2019-07-05 6:11 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, dingtianhong, xiaojiangfeng
Cc: davem, robh+dt, mark.rutland, netdev, devicetree, linux-kernel,
leeyou.li, xiekunxun, jianping.liu, nixiaoming
HI13X1_GMAC delete request for soft reset at first,
otherwise, the subsequent initialization will not
take effect.
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index fe61b01..19d8cfd 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -16,6 +16,8 @@
#include <linux/mfd/syscon.h>
#include <linux/regmap.h>
+#define SC_PPE_RESET_DREQ 0x026C
+
#define PPE_CFG_RX_ADDR 0x100
#define PPE_CFG_POOL_GRP 0x300
#define PPE_CFG_RX_BUF_SIZE 0x400
@@ -61,6 +63,8 @@
#define PPE_HIS_RX_PKT_CNT 0x804
+#define RESET_DREQ_ALL 0xffffffff
+
/* REG_INTERRUPT */
#define RCV_INT BIT(10)
#define RCV_NOBUF BIT(8)
@@ -168,6 +172,9 @@ struct rx_desc {
struct hip04_priv {
void __iomem *base;
+#if defined(CONFIG_HI13X1_GMAC)
+ void __iomem *sysctrl_base;
+#endif
int phy_mode;
int chan;
unsigned int port;
@@ -244,6 +251,13 @@ static void hip04_config_port(struct net_device *ndev, u32 speed, u32 duplex)
writel_relaxed(val, priv->base + GE_MODE_CHANGE_REG);
}
+static void hip04_reset_dreq(struct hip04_priv *priv)
+{
+#if defined(CONFIG_HI13X1_GMAC)
+ writel_relaxed(RESET_DREQ_ALL, priv->sysctrl_base + SC_PPE_RESET_DREQ);
+#endif
+}
+
static void hip04_reset_ppe(struct hip04_priv *priv)
{
u32 val, tmp, timeout = 0;
@@ -853,6 +867,15 @@ static int hip04_mac_probe(struct platform_device *pdev)
goto init_fail;
}
+#if defined(CONFIG_HI13X1_GMAC)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ priv->sysctrl_base = devm_ioremap_resource(d, res);
+ if (IS_ERR(priv->sysctrl_base)) {
+ ret = PTR_ERR(priv->sysctrl_base);
+ goto init_fail;
+ }
+#endif
+
ret = of_parse_phandle_with_fixed_args(node, "port-handle", 2, 0, &arg);
if (ret < 0) {
dev_warn(d, "no port-handle\n");
@@ -921,6 +944,7 @@ static int hip04_mac_probe(struct platform_device *pdev)
ndev->irq = irq;
netif_napi_add(ndev, &priv->napi, hip04_rx_poll, NAPI_POLL_WEIGHT);
+ hip04_reset_dreq(priv);
hip04_reset_ppe(priv);
if (priv->phy_mode == PHY_INTERFACE_MODE_MII)
hip04_config_port(ndev, SPEED_100, DUPLEX_FULL);
--
1.8.5.6
^ permalink raw reply related
* [PATCH 0/2] forcedeth: recv cache support
From: Zhu Yanjun @ 2019-07-05 6:19 UTC (permalink / raw)
To: yanjun.zhu, netdev, davem
This recv cache is to make NIC work steadily when the system memory is
not enough.
From long time testing, the NIC worked very well when the system memory
is not enough. And the NIC performance is better from about 920M to
about 940M.
Some simple tests are made:
ip link set forcedeth_nic down/up
modprobe/rmmod forcedeth
ip link set mtu 1500 dev forcedeth_nic
ethtool -G forcedeth_nic tx 512 rx 1024
And other tests, the NIC with the recv cache can work well.
Since the recv cache will reserve 125M memory for NIC, normally this recv
cache is disabled by default.
Zhu Yanjun (2):
forcedeth: add recv cache make nic work steadily
forcedeth: disable recv cache by default
drivers/net/ethernet/nvidia/Kconfig | 11 +++
drivers/net/ethernet/nvidia/Makefile | 1 +
drivers/net/ethernet/nvidia/forcedeth.c | 128 +++++++++++++++++++++++++++++++-
3 files changed, 138 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 04/10] net: hisilicon: HI13X1_GMAX skip write LOCAL_PAGE_REG
From: Jiangfeng Xiao @ 2019-07-05 6:11 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, dingtianhong, xiaojiangfeng
Cc: davem, robh+dt, mark.rutland, netdev, devicetree, linux-kernel,
leeyou.li, xiekunxun, jianping.liu, nixiaoming
HI13X1_GMAC changed the offsets and bitmaps for
GE_TX_LOCAL_PAGE_REG registers in the same peripheral
device on different models of the hip04_eth. With the
default configuration, HI13X1_GMAC can also work without
any writes to the GE_TX_LOCAL_PAGE_REG register.
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index d8f0619..fe61b01 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -308,8 +308,10 @@ static void hip04_config_fifo(struct hip04_priv *priv)
val |= GE_RX_STRIP_PAD | GE_RX_PAD_EN;
writel_relaxed(val, priv->base + GE_RECV_CONTROL_REG);
+#ifndef CONFIG_HI13X1_GMAC
val = GE_AUTO_NEG_CTL;
writel_relaxed(val, priv->base + GE_TX_LOCAL_PAGE_REG);
+#endif
}
static void hip04_mac_enable(struct net_device *ndev)
--
1.8.5.6
^ permalink raw reply related
* [PATCH 1/2] forcedeth: add recv cache make nic work steadily
From: Zhu Yanjun @ 2019-07-05 6:19 UTC (permalink / raw)
To: yanjun.zhu, netdev, davem
In-Reply-To: <1562307568-21549-1-git-send-email-yanjun.zhu@oracle.com>
A recv cache is added. The size of recv cache is 1000Mb / skb_length.
When the system memory is not enough, this recv cache can make nic work
steadily.
When nic is up, this recv cache and work queue are created. When nic
is down, this recv cache will be destroyed and delayed workqueue is
canceled.
When nic is polled or rx interrupt is triggerred, rx handler will
get a skb from recv cache. Then the state of recv cache is checked.
If recv cache is not in filling up state, a work is queued to fill
up recv cache.
When skb size is changed, the old recv cache is destroyed and new recv
cache is created.
When the system memory is not enough, the allocation of skb failed.
recv cache will continue allocate skb until the recv cache is filled up.
When the system memory is not enough, this can make nic work steadily.
Becase of recv cache, the performance of nic is enhanced.
CC: Joe Jin <joe.jin@oracle.com>
CC: Junxiao Bi <junxiao.bi@oracle.com>
Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
---
drivers/net/ethernet/nvidia/forcedeth.c | 100 +++++++++++++++++++++++++++++++-
1 file changed, 98 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/nvidia/forcedeth.c b/drivers/net/ethernet/nvidia/forcedeth.c
index b327b29..a673005 100644
--- a/drivers/net/ethernet/nvidia/forcedeth.c
+++ b/drivers/net/ethernet/nvidia/forcedeth.c
@@ -674,6 +674,11 @@ struct nv_ethtool_stats {
u64 tx_broadcast;
};
+/* 1000Mb is 125M bytes, 125 * 1024 * 1024 bytes
+ * The length of recv cache is 125M / skb_length
+ */
+#define RECV_CACHE_LIST_LENGTH (125 * 1024 * 1024 / np->rx_buf_sz)
+
#define NV_DEV_STATISTICS_V3_COUNT (sizeof(struct nv_ethtool_stats)/sizeof(u64))
#define NV_DEV_STATISTICS_V2_COUNT (NV_DEV_STATISTICS_V3_COUNT - 3)
#define NV_DEV_STATISTICS_V1_COUNT (NV_DEV_STATISTICS_V2_COUNT - 6)
@@ -844,8 +849,18 @@ struct fe_priv {
char name_rx[IFNAMSIZ + 3]; /* -rx */
char name_tx[IFNAMSIZ + 3]; /* -tx */
char name_other[IFNAMSIZ + 6]; /* -other */
+
+ /* This is to schedule work */
+ struct delayed_work recv_cache_work;
+ /* This list is to store skb queue for recv */
+ struct sk_buff_head recv_list;
+ unsigned long nv_recv_list_state;
};
+/* This is recv list state to fill up recv cache */
+enum recv_list_state {
+ RECV_LIST_ALLOCATE
+};
/*
* Maximum number of loops until we assume that a bit in the irq mask
* is stuck. Overridable with module param.
@@ -1804,7 +1819,11 @@ static int nv_alloc_rx(struct net_device *dev)
less_rx = np->last_rx.orig;
while (np->put_rx.orig != less_rx) {
- struct sk_buff *skb = netdev_alloc_skb(dev, np->rx_buf_sz + NV_RX_ALLOC_PAD);
+ struct sk_buff *skb = skb_dequeue(&np->recv_list);
+
+ if (!test_bit(RECV_LIST_ALLOCATE, &np->nv_recv_list_state))
+ schedule_delayed_work(&np->recv_cache_work, 0);
+
if (likely(skb)) {
np->put_rx_ctx->skb = skb;
np->put_rx_ctx->dma = dma_map_single(&np->pci_dev->dev,
@@ -1845,7 +1864,11 @@ static int nv_alloc_rx_optimized(struct net_device *dev)
less_rx = np->last_rx.ex;
while (np->put_rx.ex != less_rx) {
- struct sk_buff *skb = netdev_alloc_skb(dev, np->rx_buf_sz + NV_RX_ALLOC_PAD);
+ struct sk_buff *skb = skb_dequeue(&np->recv_list);
+
+ if (!test_bit(RECV_LIST_ALLOCATE, &np->nv_recv_list_state))
+ schedule_delayed_work(&np->recv_cache_work, 0);
+
if (likely(skb)) {
np->put_rx_ctx->skb = skb;
np->put_rx_ctx->dma = dma_map_single(&np->pci_dev->dev,
@@ -1957,6 +1980,40 @@ static void nv_init_tx(struct net_device *dev)
}
}
+static void nv_init_recv_cache(struct net_device *dev)
+{
+ struct fe_priv *np = netdev_priv(dev);
+
+ skb_queue_head_init(&np->recv_list);
+ while (skb_queue_len(&np->recv_list) < RECV_CACHE_LIST_LENGTH) {
+ struct sk_buff *skb = netdev_alloc_skb(dev,
+ np->rx_buf_sz + NV_RX_ALLOC_PAD);
+ /* skb is null. This indicates that memory is not
+ * enough.
+ */
+ if (unlikely(!skb)) {
+ ndelay(3);
+ continue;
+ }
+
+ skb_queue_tail(&np->recv_list, skb);
+ }
+}
+
+static void nv_destroy_recv_cache(struct net_device *dev)
+{
+ struct sk_buff *skb;
+ struct fe_priv *np = netdev_priv(dev);
+
+ cancel_delayed_work_sync(&np->recv_cache_work);
+ WARN_ON(delayed_work_pending(&np->recv_cache_work));
+
+ while ((skb = skb_dequeue(&np->recv_list)))
+ kfree_skb(skb);
+
+ WARN_ON(skb_queue_len(&np->recv_list));
+}
+
static int nv_init_ring(struct net_device *dev)
{
struct fe_priv *np = netdev_priv(dev);
@@ -3047,6 +3104,8 @@ static int nv_change_mtu(struct net_device *dev, int new_mtu)
nv_drain_rxtx(dev);
/* reinit driver view of the rx queue */
set_bufsize(dev);
+ nv_destroy_recv_cache(dev);
+ nv_init_recv_cache(dev);
if (nv_init_ring(dev)) {
if (!np->in_shutdown)
mod_timer(&np->oom_kick, jiffies + OOM_REFILL);
@@ -4074,6 +4133,32 @@ static void nv_free_irq(struct net_device *dev)
}
}
+static void nv_recv_cache_worker(struct work_struct *work)
+{
+ struct fe_priv *np = container_of(work, struct fe_priv,
+ recv_cache_work.work);
+
+ set_bit(RECV_LIST_ALLOCATE, &np->nv_recv_list_state);
+ while (skb_queue_len(&np->recv_list) < RECV_CACHE_LIST_LENGTH) {
+ struct sk_buff *skb = netdev_alloc_skb(np->dev,
+ np->rx_buf_sz + NV_RX_ALLOC_PAD);
+ /* skb is null. This indicates that memory is not
+ * enough.
+ * When the system memory is not enough, the kernel
+ * will compact memory or drop caches. At that time,
+ * if memory allocation fails, it had better wait some
+ * time for memory.
+ */
+ if (unlikely(!skb)) {
+ ndelay(3);
+ continue;
+ }
+
+ skb_queue_tail(&np->recv_list, skb);
+ }
+ clear_bit(RECV_LIST_ALLOCATE, &np->nv_recv_list_state);
+}
+
static void nv_do_nic_poll(struct timer_list *t)
{
struct fe_priv *np = from_timer(np, t, nic_poll);
@@ -4129,6 +4214,8 @@ static void nv_do_nic_poll(struct timer_list *t)
nv_drain_rxtx(dev);
/* reinit driver view of the rx queue */
set_bufsize(dev);
+ nv_destroy_recv_cache(dev);
+ nv_init_recv_cache(dev);
if (nv_init_ring(dev)) {
if (!np->in_shutdown)
mod_timer(&np->oom_kick, jiffies + OOM_REFILL);
@@ -4681,6 +4768,8 @@ static int nv_set_ringparam(struct net_device *dev, struct ethtool_ringparam* ri
if (netif_running(dev)) {
/* reinit driver view of the queues */
set_bufsize(dev);
+ nv_destroy_recv_cache(dev);
+ nv_init_recv_cache(dev);
if (nv_init_ring(dev)) {
if (!np->in_shutdown)
mod_timer(&np->oom_kick, jiffies + OOM_REFILL);
@@ -5402,6 +5491,10 @@ static int nv_open(struct net_device *dev)
/* initialize descriptor rings */
set_bufsize(dev);
+ nv_init_recv_cache(dev);
+
+ INIT_DELAYED_WORK(&np->recv_cache_work, nv_recv_cache_worker);
+ clear_bit(RECV_LIST_ALLOCATE, &np->nv_recv_list_state);
oom = nv_init_ring(dev);
writel(0, base + NvRegLinkSpeed);
@@ -5583,6 +5676,9 @@ static int nv_close(struct net_device *dev)
nv_txrx_gate(dev, true);
}
+ /* free all SKBs in recv cache */
+ nv_destroy_recv_cache(dev);
+
/* FIXME: power down nic */
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH 03/10] net: hisilicon: Cleanup for cast to restricted __be32
From: Jiangfeng Xiao @ 2019-07-05 6:10 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, dingtianhong, xiaojiangfeng
Cc: davem, robh+dt, mark.rutland, netdev, devicetree, linux-kernel,
leeyou.li, xiekunxun, jianping.liu, nixiaoming
This patch fixes the following warning from sparse:
hip04_eth.c:533:23: warning: cast to restricted __be16
hip04_eth.c:533:23: warning: cast to restricted __be16
hip04_eth.c:533:23: warning: cast to restricted __be16
hip04_eth.c:533:23: warning: cast to restricted __be16
hip04_eth.c:534:23: warning: cast to restricted __be32
hip04_eth.c:534:23: warning: cast to restricted __be32
hip04_eth.c:534:23: warning: cast to restricted __be32
hip04_eth.c:534:23: warning: cast to restricted __be32
hip04_eth.c:534:23: warning: cast to restricted __be32
hip04_eth.c:534:23: warning: cast to restricted __be32
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 31f13cf..d8f0619 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -530,8 +530,8 @@ static int hip04_rx_poll(struct napi_struct *napi, int budget)
priv->rx_phys[priv->rx_head] = 0;
desc = (struct rx_desc *)skb->data;
- len = be16_to_cpu(desc->pkt_len);
- err = be32_to_cpu(desc->pkt_err);
+ len = be16_to_cpu((__force __be16)desc->pkt_len);
+ err = be32_to_cpu((__force __be32)desc->pkt_err);
if (0 == len) {
dev_kfree_skb_any(skb);
--
1.8.5.6
^ permalink raw reply related
* [PATCH 02/10] net: hisilicon: Cleanup for got restricted __be32
From: Jiangfeng Xiao @ 2019-07-05 6:10 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, dingtianhong, xiaojiangfeng
Cc: davem, robh+dt, mark.rutland, netdev, devicetree, linux-kernel,
leeyou.li, xiekunxun, jianping.liu, nixiaoming
This patch fixes the following warning from sparse:
hip04_eth.c:468:25: warning: incorrect type in assignment
hip04_eth.c:468:25: expected unsigned int [usertype] send_addr
hip04_eth.c:468:25: got restricted __be32 [usertype]
hip04_eth.c:469:25: warning: incorrect type in assignment
hip04_eth.c:469:25: expected unsigned int [usertype] send_size
hip04_eth.c:469:25: got restricted __be32 [usertype]
hip04_eth.c:470:19: warning: incorrect type in assignment
hip04_eth.c:470:19: expected unsigned int [usertype] cfg
hip04_eth.c:470:19: got restricted __be32 [usertype]
hip04_eth.c:472:23: warning: incorrect type in assignment
hip04_eth.c:472:23: expected unsigned int [usertype] wb_addr
hip04_eth.c:472:23: got restricted __be32 [usertype]
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 2b5112b..31f13cf 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -465,11 +465,11 @@ static void hip04_start_tx_timer(struct hip04_priv *priv)
priv->tx_skb[tx_head] = skb;
priv->tx_phys[tx_head] = phys;
- desc->send_addr = cpu_to_be32(phys);
- desc->send_size = cpu_to_be32(skb->len);
- desc->cfg = cpu_to_be32(TX_CLEAR_WB | TX_FINISH_CACHE_INV);
+ desc->send_addr = (__force u32)cpu_to_be32(phys);
+ desc->send_size = (__force u32)cpu_to_be32(skb->len);
+ desc->cfg = (__force u32)cpu_to_be32(TX_CLEAR_WB | TX_FINISH_CACHE_INV);
phys = priv->tx_desc_dma + tx_head * sizeof(struct tx_desc);
- desc->wb_addr = cpu_to_be32(phys);
+ desc->wb_addr = (__force u32)cpu_to_be32(phys);
skb_tx_timestamp(skb);
hip04_set_xmit_desc(priv, phys);
--
1.8.5.6
^ permalink raw reply related
* [PATCH 01/10] net: hisilicon: Add support for HI13X1 to hip04_eth
From: Jiangfeng Xiao @ 2019-07-05 6:10 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, dingtianhong, xiaojiangfeng
Cc: davem, robh+dt, mark.rutland, netdev, devicetree, linux-kernel,
leeyou.li, xiekunxun, jianping.liu, nixiaoming
Extend the hip04_eth driver to support HI13X1_GMAC.
Enable it with CONFIG_HI13X1_GMAC option.
HI13X1 changed the offsets and bitmaps for registers
in the same peripheral device on different models of
the hip04_eth.
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
---
drivers/net/ethernet/hisilicon/Kconfig | 10 ++++++++
drivers/net/ethernet/hisilicon/hip04_eth.c | 37 ++++++++++++++++++++++++------
2 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/Kconfig b/drivers/net/ethernet/hisilicon/Kconfig
index a0d780c..3892a20 100644
--- a/drivers/net/ethernet/hisilicon/Kconfig
+++ b/drivers/net/ethernet/hisilicon/Kconfig
@@ -46,6 +46,16 @@ config HIP04_ETH
If you wish to compile a kernel for a hardware with hisilicon p04 SoC and
want to use the internal ethernet then you should answer Y to this.
+config HI13X1_GMAC
+ bool "Hisilicon HI13X1 Network Device Support"
+ depends on HIP04_ETH
+ help
+ If you wish to compile a kernel for a hardware with hisilicon hi13x1_gamc
+ then you should answer Y to this. This makes this driver suitable for use
+ on certain boards such as the HI13X1.
+
+ If you are unsure, say N.
+
config HNS_MDIO
tristate
select PHYLIB
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index e1f2978..2b5112b 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -33,10 +33,23 @@
#define GE_MODE_CHANGE_REG 0x1b4
#define GE_RECV_CONTROL_REG 0x1e0
#define GE_STATION_MAC_ADDRESS 0x210
-#define PPE_CFG_CPU_ADD_ADDR 0x580
-#define PPE_CFG_MAX_FRAME_LEN_REG 0x408
+
#define PPE_CFG_BUS_CTRL_REG 0x424
#define PPE_CFG_RX_CTRL_REG 0x428
+
+#if defined(CONFIG_HI13X1_GMAC)
+#define PPE_CFG_CPU_ADD_ADDR 0x6D0
+#define PPE_CFG_MAX_FRAME_LEN_REG 0x500
+#define PPE_CFG_RX_PKT_MODE_REG 0x504
+#define PPE_CFG_QOS_VMID_GEN 0x520
+#define PPE_CFG_RX_PKT_INT 0x740
+#define PPE_INTEN 0x700
+#define PPE_INTSTS 0x708
+#define PPE_RINT 0x704
+#define PPE_CFG_STS_MODE 0x880
+#else
+#define PPE_CFG_CPU_ADD_ADDR 0x580
+#define PPE_CFG_MAX_FRAME_LEN_REG 0x408
#define PPE_CFG_RX_PKT_MODE_REG 0x438
#define PPE_CFG_QOS_VMID_GEN 0x500
#define PPE_CFG_RX_PKT_INT 0x538
@@ -44,6 +57,8 @@
#define PPE_INTSTS 0x608
#define PPE_RINT 0x604
#define PPE_CFG_STS_MODE 0x700
+#endif /* CONFIG_HI13X1_GMAC */
+
#define PPE_HIS_RX_PKT_CNT 0x804
/* REG_INTERRUPT */
@@ -93,18 +108,26 @@
#define GE_RX_PORT_EN BIT(1)
#define GE_TX_PORT_EN BIT(2)
-#define PPE_CFG_STS_RX_PKT_CNT_RC BIT(12)
-
#define PPE_CFG_RX_PKT_ALIGN BIT(18)
-#define PPE_CFG_QOS_VMID_MODE BIT(14)
+
+#if defined(CONFIG_HI13X1_GMAC)
+#define PPE_CFG_QOS_VMID_GRP_SHIFT 4
+#define PPE_CFG_RX_CTRL_ALIGN_SHIFT 7
+#define PPE_CFG_STS_RX_PKT_CNT_RC BIT(0)
+#define PPE_CFG_QOS_VMID_MODE BIT(15)
+#define PPE_CFG_BUS_LOCAL_REL (BIT(9) | BIT(15) | BIT(19) | BIT(23))
+#else
#define PPE_CFG_QOS_VMID_GRP_SHIFT 8
+#define PPE_CFG_RX_CTRL_ALIGN_SHIFT 11
+#define PPE_CFG_STS_RX_PKT_CNT_RC BIT(12)
+#define PPE_CFG_QOS_VMID_MODE BIT(14)
+#define PPE_CFG_BUS_LOCAL_REL BIT(14)
+#endif /* CONFIG_HI13X1_GMAC */
#define PPE_CFG_RX_FIFO_FSFU BIT(11)
#define PPE_CFG_RX_DEPTH_SHIFT 16
#define PPE_CFG_RX_START_SHIFT 0
-#define PPE_CFG_RX_CTRL_ALIGN_SHIFT 11
-#define PPE_CFG_BUS_LOCAL_REL BIT(14)
#define PPE_CFG_BUS_BIG_ENDIEN BIT(0)
#define RX_DESC_NUM 128
--
1.8.5.6
^ permalink raw reply related
* [PATCH] net: hisilicon: Add an tx_desc to adapt HI13X1_GMAC
From: Jiangfeng Xiao @ 2019-07-05 6:10 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, dingtianhong, xiaojiangfeng
Cc: davem, robh+dt, mark.rutland, netdev, devicetree, linux-kernel,
leeyou.li, xiekunxun, jianping.liu, nixiaoming
HI13X1 changed the offsets and bitmaps for tx_desc
registers in the same peripheral device on different
models of the hip04_eth.
Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
---
drivers/net/ethernet/hisilicon/hip04_eth.c | 34 +++++++++++++++++++++++++++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
index 780fc46..6256357 100644
--- a/drivers/net/ethernet/hisilicon/hip04_eth.c
+++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
@@ -76,8 +76,15 @@
/* TX descriptor config */
#define TX_FREE_MEM BIT(0)
#define TX_READ_ALLOC_L3 BIT(1)
-#define TX_FINISH_CACHE_INV BIT(2)
+#if defined(CONFIG_HI13X1_GMAC)
+#define TX_CLEAR_WB BIT(7)
+#define TX_RELEASE_TO_PPE BIT(4)
+#define TX_FINISH_CACHE_INV BIT(6)
+#define TX_POOL_SHIFT 16
+#else
#define TX_CLEAR_WB BIT(4)
+#define TX_FINISH_CACHE_INV BIT(2)
+#endif
#define TX_L3_CHECKSUM BIT(5)
#define TX_LOOP_BACK BIT(11)
@@ -124,6 +131,7 @@
/* buf unit size is cache_line_size, which is 64, so the shift is 6 */
#define PPE_BUF_SIZE_SHIFT 6
#define PPE_TX_BUF_HOLD BIT(31)
+#define CACHE_LINE_MASK 0x3F
#else
#define PPE_CFG_QOS_VMID_GRP_SHIFT 8
#define PPE_CFG_RX_CTRL_ALIGN_SHIFT 11
@@ -163,11 +171,22 @@
#define HIP04_MIN_TX_COALESCE_FRAMES 100
struct tx_desc {
+#if defined(CONFIG_HI13X1_GMAC)
+ u32 reserved1[2];
+ u32 send_addr;
+ u16 send_size;
+ u16 data_offset;
+ u32 reserved2[7];
+ u32 cfg;
+ u32 wb_addr;
+ u32 reserved3[3];
+#else
u32 send_addr;
u32 send_size;
u32 next_addr;
u32 cfg;
u32 wb_addr;
+#endif
} __aligned(64);
struct rx_desc {
@@ -505,11 +524,20 @@ static void hip04_start_tx_timer(struct hip04_priv *priv)
priv->tx_skb[tx_head] = skb;
priv->tx_phys[tx_head] = phys;
- desc->send_addr = (__force u32)cpu_to_be32(phys);
+
desc->send_size = (__force u32)cpu_to_be32(skb->len);
+#if defined(CONFIG_HI13X1_GMAC)
+ desc->cfg = (__force u32)cpu_to_be32(TX_CLEAR_WB | TX_FINISH_CACHE_INV
+ | TX_RELEASE_TO_PPE | priv->port << TX_POOL_SHIFT);
+ desc->data_offset = (__force u32)cpu_to_be32(phys & CACHE_LINE_MASK);
+ desc->send_addr = (__force u32)cpu_to_be32(phys & ~CACHE_LINE_MASK);
+#else
desc->cfg = (__force u32)cpu_to_be32(TX_CLEAR_WB | TX_FINISH_CACHE_INV);
+ desc->send_addr = (__force u32)cpu_to_be32(phys);
+#endif
phys = priv->tx_desc_dma + tx_head * sizeof(struct tx_desc);
- desc->wb_addr = (__force u32)cpu_to_be32(phys);
+ desc->wb_addr = (__force u32)cpu_to_be32(phys +
+ offsetof(struct tx_desc, send_addr));
skb_tx_timestamp(skb);
hip04_set_xmit_desc(priv, phys);
--
1.8.5.6
^ permalink raw reply related
* RE: [PATCH v2] let proc net directory inodes reflect to active net namespace
From: Hallsmark, Per @ 2019-07-05 6:02 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: David S. Miller, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20190704073200.GA2165@avx2>
Hello Alexey,
Sounds excellent! Could you please drop a notifier of such?
For our usecase, the ipv6 is statically linked (=y) and then this happens way before
userland starts (thus no access to procfs) so I believe we should be able to continue
as is until we can replace with your proper patch. Agree?
Also still wonder about the others that creates directories in procfs net, that do not
call proc_net_mkdir().
My second patch changed to use proc_net_mkdir for dev_snmp6 directory, so if proc_net_mkdir is fixed
it should cover at least the ipv6 snmp counters. But I think there's other that could benefit of same?
Like :
net/netfilter/xt_hashlimit.c: hashlimit_net->ipt_hashlimit = proc_mkdir("ipt_hashlimit", net->proc_net);
net/netfilter/xt_hashlimit.c: hashlimit_net->ip6t_hashlimit = proc_mkdir("ip6t_hashlimit", net->proc_net);
Wouldn't those also want to be reflected by a net namespace change?
Just an example, there are others too.
BR,
Per
--
Per Hallsmark per.hallsmark@windriver.com
Senior Member Technical Staff Wind River AB
Mobile: +46733249340 Office: +46859461127
Torshamnsgatan 27 164 40 Kista
________________________________________
From: Alexey Dobriyan [adobriyan@gmail.com]
Sent: Thursday, July 04, 2019 09:32
To: Hallsmark, Per
Cc: David S. Miller; linux-kernel@vger.kernel.org; netdev@vger.kernel.org
Subject: Re: [PATCH v2] let proc net directory inodes reflect to active net namespace
On Mon, Jul 01, 2019 at 11:06:34AM +0000, Hallsmark, Per wrote:
> +struct proc_dir_entry *proc_net_mkdir(struct net *net, const char *name,
> + struct proc_dir_entry *parent)
> +{
> + struct proc_dir_entry *pde;
> +
> + pde = proc_mkdir_data(name, 0, parent, net);
> + if (!pde)
> + return NULL;
> + pde->proc_dops = &proc_net_dentry_ops;
OK, this is buggy in a different way:
once proc_mkdir_data() returns, proc entry is live and should be fully
ready, so dentry operations should be glued before that.
I'll send proper patch.
^ permalink raw reply
* Re: [PATCH bpf-next] tools: bpftool: add "prog run" subcommand to test-run programs
From: Y Song @ 2019-07-05 5:49 UTC (permalink / raw)
To: Quentin Monnet
Cc: Alexei Starovoitov, Daniel Borkmann, bpf, netdev, oss-drivers
In-Reply-To: <20190704085646.12406-1-quentin.monnet@netronome.com>
On Thu, Jul 4, 2019 at 1:58 AM Quentin Monnet
<quentin.monnet@netronome.com> wrote:
>
> Add a new "bpftool prog run" subcommand to run a loaded program on input
> data (and possibly with input context) passed by the user.
>
> Print output data (and output context if relevant) into a file or into
> the console. Print return value and duration for the test run into the
> console.
>
> A "repeat" argument can be passed to run the program several times in a
> row.
>
> The command does not perform any kind of verification based on program
> type (Is this program type allowed to use an input context?) or on data
> consistency (Can I work with empty input data?), this is left to the
> kernel.
>
> Example invocation:
>
> # perl -e 'print "\x0" x 14' | ./bpftool prog run \
> pinned /sys/fs/bpf/sample_ret0 \
> data_in - data_out - repeat 5
> 0000000 0000 0000 0000 0000 0000 0000 0000 | ........ ......
> Return value: 0, duration (average): 260ns
>
> When one of data_in or ctx_in is "-", bpftool reads from standard input,
> in binary format. Other formats (JSON, hexdump) might be supported (via
> an optional command line keyword like "data_fmt_in") in the future if
> relevant, but this would require doing more parsing in bpftool.
>
> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> .../bpftool/Documentation/bpftool-prog.rst | 34 ++
> tools/bpf/bpftool/bash-completion/bpftool | 28 +-
> tools/bpf/bpftool/main.c | 29 ++
> tools/bpf/bpftool/main.h | 1 +
> tools/bpf/bpftool/prog.c | 348 +++++++++++++++++-
> tools/include/linux/sizes.h | 48 +++
> 6 files changed, 485 insertions(+), 3 deletions(-)
> create mode 100644 tools/include/linux/sizes.h
>
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-prog.rst b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> index 1df637f85f94..7a374b3c851d 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> @@ -29,6 +29,7 @@ PROG COMMANDS
> | **bpftool** **prog attach** *PROG* *ATTACH_TYPE* [*MAP*]
> | **bpftool** **prog detach** *PROG* *ATTACH_TYPE* [*MAP*]
> | **bpftool** **prog tracelog**
> +| **bpftool** **prog run** *PROG* **data_in** *FILE* [**data_out** *FILE* [**data_size_out** *L*]] [**ctx_in** *FILE* [**ctx_out** *FILE* [**ctx_size_out** *M*]]] [**repeat** *N*]
> | **bpftool** **prog help**
> |
> | *MAP* := { **id** *MAP_ID* | **pinned** *FILE* }
> @@ -146,6 +147,39 @@ DESCRIPTION
> streaming data from BPF programs to user space, one can use
> perf events (see also **bpftool-map**\ (8)).
>
> + **bpftool prog run** *PROG* **data_in** *FILE* [**data_out** *FILE* [**data_size_out** *L*]] [**ctx_in** *FILE* [**ctx_out** *FILE* [**ctx_size_out** *M*]]] [**repeat** *N*]
> + Run BPF program *PROG* in the kernel testing infrastructure
> + for BPF, meaning that the program works on the data and
> + context provided by the user, and not on actual packets or
> + monitored functions etc. Return value and duration for the
> + test run are printed out to the console.
> +
> + Input data is read from the *FILE* passed with **data_in**.
> + If this *FILE* is "**-**", input data is read from standard
> + input. Input context, if any, is read from *FILE* passed with
> + **ctx_in**. Again, "**-**" can be used to read from standard
> + input, but only if standard input is not already in use for
> + input data. If a *FILE* is passed with **data_out**, output
> + data is written to that file. Similarly, output context is
> + written to the *FILE* passed with **ctx_out**. For both
> + output flows, "**-**" can be used to print to the standard
> + output (as plain text, or JSON if relevant option was
> + passed). If output keywords are omitted, output data and
> + context are discarded. Keywords **data_size_out** and
> + **ctx_size_out** are used to pass the size (in bytes) for the
> + output buffers to the kernel, although the default of 32 kB
> + should be more than enough for most cases.
> +
> + Keyword **repeat** is used to indicate the number of
> + consecutive runs to perform. Note that output data and
> + context printed to files correspond to the last of those
> + runs. The duration printed out at the end of the runs is an
> + average over all runs performed by the command.
> +
> + Not all program types support test run. Among those which do,
> + not all of them can take the **ctx_in**/**ctx_out**
> + arguments. bpftool does not perform checks on program types.
> +
> **bpftool prog help**
> Print short help message.
>
> diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
> index ba37095e1f62..965a8658cca3 100644
> --- a/tools/bpf/bpftool/bash-completion/bpftool
> +++ b/tools/bpf/bpftool/bash-completion/bpftool
> @@ -408,10 +408,34 @@ _bpftool()
> tracelog)
> return 0
> ;;
> + run)
> + if [[ ${#words[@]} -lt 5 ]]; then
> + _filedir
> + return 0
> + fi
> + case $prev in
> + id)
> + _bpftool_get_prog_ids
> + return 0
> + ;;
> + data_in|data_out|ctx_in|ctx_out)
> + _filedir
> + return 0
> + ;;
> + repeat|data_size_out|ctx_size_out)
> + return 0
> + ;;
> + *)
> + _bpftool_once_attr 'data_in data_out data_size_out \
> + ctx_in ctx_out ctx_size_out repeat'
> + return 0
> + ;;
> + esac
> + ;;
> *)
> [[ $prev == $object ]] && \
> - COMPREPLY=( $( compgen -W 'dump help pin attach detach load \
> - show list tracelog' -- "$cur" ) )
> + COMPREPLY=( $( compgen -W 'dump help pin attach detach \
> + load show list tracelog run' -- "$cur" ) )
> ;;
> esac
> ;;
> diff --git a/tools/bpf/bpftool/main.c b/tools/bpf/bpftool/main.c
> index 4879f6395c7e..e916ff25697f 100644
> --- a/tools/bpf/bpftool/main.c
> +++ b/tools/bpf/bpftool/main.c
> @@ -117,6 +117,35 @@ bool is_prefix(const char *pfx, const char *str)
> return !memcmp(str, pfx, strlen(pfx));
> }
>
> +/* Last argument MUST be NULL pointer */
> +int detect_common_prefix(const char *arg, ...)
> +{
> + unsigned int count = 0;
> + const char *ref;
> + char msg[256];
> + va_list ap;
> +
> + snprintf(msg, sizeof(msg), "ambiguous prefix: '%s' could be '", arg);
> + va_start(ap, arg);
> + while ((ref = va_arg(ap, const char *))) {
> + if (!is_prefix(arg, ref))
> + continue;
> + count++;
> + if (count > 1)
> + strncat(msg, "' or '", sizeof(msg) - strlen(msg) - 1);
> + strncat(msg, ref, sizeof(msg) - strlen(msg) - 1);
> + }
> + va_end(ap);
> + strncat(msg, "'", sizeof(msg) - strlen(msg) - 1);
> +
> + if (count >= 2) {
> + p_err(msg);
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> void fprint_hex(FILE *f, void *arg, unsigned int n, const char *sep)
> {
> unsigned char *data = arg;
> diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
> index 9c5d9c80f71e..3ef0d9051e10 100644
> --- a/tools/bpf/bpftool/main.h
> +++ b/tools/bpf/bpftool/main.h
> @@ -101,6 +101,7 @@ void p_err(const char *fmt, ...);
> void p_info(const char *fmt, ...);
>
> bool is_prefix(const char *pfx, const char *str);
> +int detect_common_prefix(const char *arg, ...);
> void fprint_hex(FILE *f, void *arg, unsigned int n, const char *sep);
> void usage(void) __noreturn;
>
> diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
> index 9b0db5d14e31..8dcbaa0a8ab1 100644
> --- a/tools/bpf/bpftool/prog.c
> +++ b/tools/bpf/bpftool/prog.c
> @@ -15,6 +15,7 @@
> #include <sys/stat.h>
>
> #include <linux/err.h>
> +#include <linux/sizes.h>
>
> #include <bpf.h>
> #include <btf.h>
> @@ -748,6 +749,344 @@ static int do_detach(int argc, char **argv)
> return 0;
> }
>
> +static int check_single_stdin(char *file_in, char *other_file_in)
> +{
> + if (file_in && other_file_in &&
> + !strcmp(file_in, "-") && !strcmp(other_file_in, "-")) {
> + p_err("cannot use standard input for both data_in and ctx_in");
The error message says data_in and ctx_in.
Maybe the input parameter should be file_data_in and file_ctx_in?
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static int get_run_data(const char *fname, void **data_ptr, unsigned int *size)
> +{
> + size_t block_size = 256;
> + size_t buf_size = block_size;
> + size_t nb_read = 0;
> + void *tmp;
> + FILE *f;
> +
> + if (!fname) {
> + *data_ptr = NULL;
> + *size = 0;
> + return 0;
> + }
> +
> + if (!strcmp(fname, "-"))
> + f = stdin;
> + else
> + f = fopen(fname, "r");
> + if (!f) {
> + p_err("failed to open %s: %s", fname, strerror(errno));
> + return -1;
> + }
> +
> + *data_ptr = malloc(block_size);
> + if (!*data_ptr) {
> + p_err("failed to allocate memory for data_in/ctx_in: %s",
> + strerror(errno));
> + goto err_fclose;
> + }
> +
> + while ((nb_read += fread(*data_ptr + nb_read, 1, block_size, f))) {
> + if (feof(f))
> + break;
> + if (ferror(f)) {
> + p_err("failed to read data_in/ctx_in from %s: %s",
> + fname, strerror(errno));
> + goto err_free;
> + }
> + if (nb_read > buf_size - block_size) {
> + if (buf_size == UINT32_MAX) {
> + p_err("data_in/ctx_in is too long (max: %d)",
> + UINT32_MAX);
> + goto err_free;
> + }
> + /* No space for fread()-ing next chunk; realloc() */
> + buf_size *= 2;
> + tmp = realloc(*data_ptr, buf_size);
> + if (!tmp) {
> + p_err("failed to reallocate data_in/ctx_in: %s",
> + strerror(errno));
> + goto err_free;
> + }
> + *data_ptr = tmp;
> + }
> + }
> + if (f != stdin)
> + fclose(f);
> +
> + *size = nb_read;
> + return 0;
> +
> +err_free:
> + free(*data_ptr);
> + *data_ptr = NULL;
> +err_fclose:
> + if (f != stdin)
> + fclose(f);
> + return -1;
> +}
> +
> +static void hex_print(void *data, unsigned int size, FILE *f)
> +{
> + size_t i, j;
> + char c;
> +
> + for (i = 0; i < size; i += 16) {
> + /* Row offset */
> + fprintf(f, "%07zx\t", i);
> +
> + /* Hexadecimal values */
> + for (j = i; j < i + 16 && j < size; j++)
> + fprintf(f, "%02x%s", *(uint8_t *)(data + j),
> + j % 2 ? " " : "");
> + for (; j < i + 16; j++)
> + fprintf(f, " %s", j % 2 ? " " : "");
> +
> + /* ASCII values (if relevant), '.' otherwise */
> + fprintf(f, "| ");
> + for (j = i; j < i + 16 && j < size; j++) {
> + c = *(char *)(data + j);
> + if (c < ' ' || c > '~')
> + c = '.';
> + fprintf(f, "%c%s", c, j == i + 7 ? " " : "");
> + }
> +
> + fprintf(f, "\n");
> + }
> +}
> +
> +static int
> +print_run_output(void *data, unsigned int size, const char *fname,
> + const char *json_key)
> +{
> + size_t nb_written;
> + FILE *f;
> +
> + if (!fname)
> + return 0;
> +
> + if (!strcmp(fname, "-")) {
> + f = stdout;
> + if (json_output) {
> + jsonw_name(json_wtr, json_key);
> + print_data_json(data, size);
> + } else {
> + hex_print(data, size, f);
> + }
> + return 0;
> + }
> +
> + f = fopen(fname, "w");
> + if (!f) {
> + p_err("failed to open %s: %s", fname, strerror(errno));
> + return -1;
> + }
> +
> + nb_written = fwrite(data, 1, size, f);
> + fclose(f);
> + if (nb_written != size) {
> + p_err("failed to write output data/ctx: %s", strerror(errno));
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static int alloc_run_data(void **data_ptr, unsigned int size_out)
> +{
> + *data_ptr = calloc(size_out, 1);
> + if (!*data_ptr) {
> + p_err("failed to allocate memory for output data/ctx: %s",
> + strerror(errno));
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static int do_run(int argc, char **argv)
> +{
> + char *data_fname_in = NULL, *data_fname_out = NULL;
> + char *ctx_fname_in = NULL, *ctx_fname_out = NULL;
> + struct bpf_prog_test_run_attr test_attr = {0};
> + const unsigned int default_size = SZ_32K;
> + void *data_in = NULL, *data_out = NULL;
> + void *ctx_in = NULL, *ctx_out = NULL;
> + unsigned int repeat = 1;
> + int fd, err;
> +
> + if (!REQ_ARGS(4))
> + return -1;
> +
> + fd = prog_parse_fd(&argc, &argv);
> + if (fd < 0)
> + return -1;
> +
> + while (argc) {
> + if (detect_common_prefix(*argv, "data_in", "data_out",
> + "data_size_out", NULL))
> + return -1;
> + if (detect_common_prefix(*argv, "ctx_in", "ctx_out",
> + "ctx_size_out", NULL))
> + return -1;
> +
> + if (is_prefix(*argv, "data_in")) {
> + NEXT_ARG();
> + if (!REQ_ARGS(1))
> + return -1;
> +
> + data_fname_in = GET_ARG();
> + if (check_single_stdin(data_fname_in, ctx_fname_in))
> + return -1;
> + } else if (is_prefix(*argv, "data_out")) {
Here, we all use is_prefix() to match "data_in", "data_out",
"data_size_out" etc.
That means users can use "data_i" instead of "data_in" as below
... | ./bpftool prog run id 283 data_i - data_out - repeat 5
is this expected?
> + NEXT_ARG();
> + if (!REQ_ARGS(1))
> + return -1;
> +
> + data_fname_out = GET_ARG();
> + } else if (is_prefix(*argv, "data_size_out")) {
> + char *endptr;
> +
> + NEXT_ARG();
> + if (!REQ_ARGS(1))
> + return -1;
> +
> + test_attr.data_size_out = strtoul(*argv, &endptr, 0);
> + if (*endptr) {
> + p_err("can't parse %s as output data size",
> + *argv);
> + return -1;
> + }
> + NEXT_ARG();
> + } else if (is_prefix(*argv, "ctx_in")) {
> + NEXT_ARG();
> + if (!REQ_ARGS(1))
> + return -1;
> +
> + ctx_fname_in = GET_ARG();
> + if (check_single_stdin(ctx_fname_in, data_fname_in))
> + return -1;
> + } else if (is_prefix(*argv, "ctx_out")) {
> + NEXT_ARG();
> + if (!REQ_ARGS(1))
> + return -1;
> +
> + ctx_fname_out = GET_ARG();
> + } else if (is_prefix(*argv, "ctx_size_out")) {
> + char *endptr;
> +
> + NEXT_ARG();
> + if (!REQ_ARGS(1))
> + return -1;
> +
> + test_attr.ctx_size_out = strtoul(*argv, &endptr, 0);
> + if (*endptr) {
> + p_err("can't parse %s as output context size",
> + *argv);
> + return -1;
> + }
> + NEXT_ARG();
> + } else if (is_prefix(*argv, "repeat")) {
> + char *endptr;
> +
> + NEXT_ARG();
> + if (!REQ_ARGS(1))
> + return -1;
> +
> + repeat = strtoul(*argv, &endptr, 0);
> + if (*endptr) {
> + p_err("can't parse %s as repeat number",
> + *argv);
> + return -1;
> + }
> + NEXT_ARG();
> + } else {
> + p_err("expected no more arguments, 'data_in', 'data_out', 'data_size_out', 'ctx_in', 'ctx_out', 'ctx_size_out' or 'repeat', got: '%s'?",
> + *argv);
> + return -1;
> + }
> + }
> +
[...]
^ permalink raw reply
* Re: [PATCH v1 net-next] net: stmmac: enable clause 45 mdio support
From: Andrew Lunn @ 2019-07-05 4:52 UTC (permalink / raw)
To: Voon, Weifeng
Cc: David S. Miller, Maxime Coquelin, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Jose Abreu, Giuseppe Cavallaro,
Florian Fainelli, Alexandre Torgue, biao huang, Ong, Boon Leong,
Kweh, Hock Leong
In-Reply-To: <D6759987A7968C4889FDA6FA91D5CBC814738B36@PGSMSX103.gar.corp.intel.com>
> If the community prefers readability
Readability nearly always comes first. There is nothing performance
critical here, MDIO is a slow bus. So the code should be readable,
simple to understand.
, I will suggest to do the c45 setup in
> both stmmac_mdio_read() and stmmac_mdio_write() 's if(C45) condition rather
> than splitting into 2 new c45_read() and c45_write() functions.
Fine.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node
From: Andrew Lunn @ 2019-07-05 4:49 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Alexandre Belloni, Allan W. Nielsen, Claudiu Manoil,
David S . Miller, devicetree@vger.kernel.org,
netdev@vger.kernel.org, Alexandru Marginean,
linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com,
Allan Nielsen, Rob Herring, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CA+h21hqGtA5ou7a3wjSuHxa_4fXk4GZohTAxnUdfLZjV3nq5Eg@mail.gmail.com>
Hi Vladimir
> - DSA is typically used for discrete switches, switchdev is typically
> used for embedded ones.
Typically DSA is for discrete switches, but not exclusively. The
b53/SF2 is embedded in a number of Broadcom SoCs. So this is no
different to Ocelot, except ARM vs MIPS. Also, i would disagree that
switchdev is used for embedded ones. Mellonex devices are discrete, on
a PCIe bus. I believe Netronome devices are also discrete PCIe
devices. In fact, i think ocelot is the only embedded switchdev
switch.
So embedded vs discrete plays no role here at all.
> - The D in DSA is for cascaded switches. Apart from the absence of
> such a "Ocelot SoC" driver (which maybe can be written, I don't know),
> I think the switching core itself has some fundamental limitations
> that make a DSA implementation questionable:
There is no requirement to implement D in DSA. In fact, only Marvell
does. None of the other switches do. And you will also find that most
boards with a Marvell switch use a single device. D in DSA is totally
optional. In fact, DSA is built from the ground up that nearly
everything is optional. Take a look at mv88e6060, as an example. It
implements nearly nothing. It cannot even offload a bridge to the
switch.
> So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of
> sense if the whole purpose is to hide the CPU-facing netdev.
You actually convinced me the exact opposite. You described the
headers which are needed to implement DSA. The switch sounds like it
can do what DSA requires. So DSA is the correct model.
Andrew
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Chris Chiu @ 2019-07-05 4:37 UTC (permalink / raw)
To: Daniel Drake
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <CAD8Lp45rYuE5WHx4vSbUhF10hOHam1aBLd52_aDKP8z2eeL4vA@mail.gmail.com>
On Fri, Jul 5, 2019 at 11:41 AM Daniel Drake <drake@endlessm.com> wrote:
>
> On Thu, Jul 4, 2019 at 6:55 PM Chris Chiu <chiu@endlessm.com> wrote:
> > The WiFi tx power of RTL8723BU is extremely low after booting. So
> > the WiFi scan gives very limited AP list and it always fails to
> > connect to the selected AP. This module only supports 1x1 antenna
> > and the antenna is switched to bluetooth due to some incorrect
> > register settings.
> >
> > Compare with the vendor driver https://github.com/lwfinger/rtl8723bu,
> > we realized that the 8723bu's enable_rf() does the same thing as
> > rtw_btcoex_HAL_Initialize() in vendor driver. And it by default
> > sets the antenna path to BTC_ANT_PATH_BT which we verified it's
> > the cause of the wifi weak tx power. The vendor driver will set
> > the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist
> > mechanism, by the function halbtc8723b1ant_PsTdma.
>
> Checking these details in the vendor driver:
> EXhalbtc8723b1ant_PowerOnSetting sets:
> pBoardInfo->btdmAntPos = BTC_ANTENNA_AT_AUX_PORT;
>
> Following the code flow from rtw_btcoex_HAL_Initialize(), this has a
> bWifiOnly parameter which will ultimately influence the final register
> value.
> Continuing the flow, we reach halbtc8723b1ant_SetAntPath() with
> bInitHwCfg=TRUE, bWifiOff=FALSE. antPosType is set to WIFI in the
> bWifiOnly case, and BT otherwise.
>
> I'm assuming that bUseExtSwitch = FALSE (existing rtl8xxxu code also
> seems to make the same assumption).
> For the bWifiOnly=FALSE case, it uses BT,
> pBtCoexist->fBtcWrite4Byte(pBtCoexist, 0x948, 0x0);
> and rtl8xxxu seems to do the same - seemingly routing the antenna path
> for BT only.
>
> As for halbtc8723b1ant_PsTdma() then being called in a way that causes
> it to switch to the PTA path a little later, it's more difficult to
> point out how that happens in an email, but I thin kwe can trust you
> on that :) There are certainly many callsites that would pass those
> parameters.
>
> > + * Different settings per different antenna position.
> > + * Antenna Position: | Normal Inverse
> > + * --------------------------------------------------
> > + * Antenna switch to BT: | 0x280, 0x00
> > + * Antenna switch to WiFi: | 0x0, 0x280
> > + * Antenna switch to PTA: | 0x200, 0x80
> > */
> > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
>
> I don't really understand what we mean by an "inverse" antenna and my
> reading of the vendor driver leads me to another interpretation.
>
> The logic is based around an antenna position - btdmAntPos. It takes
> one of two values:
> BTC_ANTENNA_AT_MAIN_PORT = 0x1,
> BTC_ANTENNA_AT_AUX_PORT = 0x2,
>
> So the chip has pins to support two antennas - a "main" antenna and an
> "aux" one.
>
> We know we're dealing with a single antenna, so the actual module is
> going to only be using one of those antenna interfaces. If the chip
> tries to use the other antenna interface, it's effectively not using
> the antenna. So it's rather important to tell the chip to use the
> right interface.
>
> And that's exactly what happens here. btdmAntPos is hardcoded that the
> antenna is on the aux port for these devices, and this code is telling
> the chip that this is how things are wired up.
>
> The alternative way of calling this an antenna inverse (which the
> vendor driver also does in another section), i.e. "antenna is not
> connected to the main port but instead it's connected to the other
> one", seems less clear to me.
>
I agree with this part. From my past experience working on drivers for
WiFi access point, there's always a board config to describe how the
antenna wired up. The driver or firmware will select antennas from
something like txchainmask/rxchainmask to perform some smart
antenna and MIMO features. So The antenna position setting is quite
important for each wifi(MIMO) product because it could have impact on
the coverage and throughput. Back to the 1x1 rtl8723bu here, I think
it's the same thing. The antenna position is fixed in the factory and wired
to the AUX port. Maybe we can just take this antenna settings as the
default for 8723bu based on the assumption that there will be no other
antenna configuration.
Chris
> Even if we don't fully understand what's going on here, I'm convinced
> that your code change is fixing an inconsistency with the vendor
> driver, and most significantly, making the signal level actually
> usable on our devices. But if you agree with my interpretation of
> these values then maybe you could update the comment here!
>
> Daniel
^ permalink raw reply
* [PATCH] net: bpfilter: print umh messages to /dev/kmsg
From: Gary Lin @ 2019-07-05 3:54 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org, Alexei Starovoitov,
David S . Miller, Daniel Borkmann, Fabian Vogt, Gary Lin
bpfilter_umh currently printed all messages to /dev/console and this
might interfere the user activity(*).
This commit changes the output device to /dev/kmsg so that the messages
from bpfilter_umh won't show on the console directly.
(*) https://bugzilla.suse.com/show_bug.cgi?id=1140221
Signed-off-by: Gary Lin <glin@suse.com>
---
net/bpfilter/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bpfilter/main.c b/net/bpfilter/main.c
index 61ce8454a88e..77396a098fbe 100644
--- a/net/bpfilter/main.c
+++ b/net/bpfilter/main.c
@@ -55,7 +55,7 @@ static void loop(void)
int main(void)
{
- debug_fd = open("/dev/console", 00000002);
+ debug_fd = open("/dev/kmsg", 00000002);
dprintf(debug_fd, "Started bpfilter\n");
loop();
close(debug_fd);
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Daniel Drake @ 2019-07-05 3:44 UTC (permalink / raw)
To: Jes Sorensen
Cc: Chris Chiu, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team, Larry Finger
In-Reply-To: <89dbfb9d-a31a-9ecb-66bd-42ac0fc49e70@gmail.com>
On Wed, Jul 3, 2019 at 8:59 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
> My point is this seems to be very dongle dependent :( We have to be
> careful not breaking it for some users while fixing it for others.
Do you still have your device?
Once we get to the point when you are happy with Chris's two patches
here on a code review level, we'll reach out to other driver
contributors plus people who previously complained about these types
of problems, and see if we can get some wider testing.
Larry, do you have these devices, can you help with testing too?
Thanks
Daniel
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Daniel Drake @ 2019-07-05 3:41 UTC (permalink / raw)
To: Chris Chiu
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <20190704105528.74028-1-chiu@endlessm.com>
On Thu, Jul 4, 2019 at 6:55 PM Chris Chiu <chiu@endlessm.com> wrote:
> The WiFi tx power of RTL8723BU is extremely low after booting. So
> the WiFi scan gives very limited AP list and it always fails to
> connect to the selected AP. This module only supports 1x1 antenna
> and the antenna is switched to bluetooth due to some incorrect
> register settings.
>
> Compare with the vendor driver https://github.com/lwfinger/rtl8723bu,
> we realized that the 8723bu's enable_rf() does the same thing as
> rtw_btcoex_HAL_Initialize() in vendor driver. And it by default
> sets the antenna path to BTC_ANT_PATH_BT which we verified it's
> the cause of the wifi weak tx power. The vendor driver will set
> the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist
> mechanism, by the function halbtc8723b1ant_PsTdma.
Checking these details in the vendor driver:
EXhalbtc8723b1ant_PowerOnSetting sets:
pBoardInfo->btdmAntPos = BTC_ANTENNA_AT_AUX_PORT;
Following the code flow from rtw_btcoex_HAL_Initialize(), this has a
bWifiOnly parameter which will ultimately influence the final register
value.
Continuing the flow, we reach halbtc8723b1ant_SetAntPath() with
bInitHwCfg=TRUE, bWifiOff=FALSE. antPosType is set to WIFI in the
bWifiOnly case, and BT otherwise.
I'm assuming that bUseExtSwitch = FALSE (existing rtl8xxxu code also
seems to make the same assumption).
For the bWifiOnly=FALSE case, it uses BT,
pBtCoexist->fBtcWrite4Byte(pBtCoexist, 0x948, 0x0);
and rtl8xxxu seems to do the same - seemingly routing the antenna path
for BT only.
As for halbtc8723b1ant_PsTdma() then being called in a way that causes
it to switch to the PTA path a little later, it's more difficult to
point out how that happens in an email, but I thin kwe can trust you
on that :) There are certainly many callsites that would pass those
parameters.
> + * Different settings per different antenna position.
> + * Antenna Position: | Normal Inverse
> + * --------------------------------------------------
> + * Antenna switch to BT: | 0x280, 0x00
> + * Antenna switch to WiFi: | 0x0, 0x280
> + * Antenna switch to PTA: | 0x200, 0x80
> */
> - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
I don't really understand what we mean by an "inverse" antenna and my
reading of the vendor driver leads me to another interpretation.
The logic is based around an antenna position - btdmAntPos. It takes
one of two values:
BTC_ANTENNA_AT_MAIN_PORT = 0x1,
BTC_ANTENNA_AT_AUX_PORT = 0x2,
So the chip has pins to support two antennas - a "main" antenna and an
"aux" one.
We know we're dealing with a single antenna, so the actual module is
going to only be using one of those antenna interfaces. If the chip
tries to use the other antenna interface, it's effectively not using
the antenna. So it's rather important to tell the chip to use the
right interface.
And that's exactly what happens here. btdmAntPos is hardcoded that the
antenna is on the aux port for these devices, and this code is telling
the chip that this is how things are wired up.
The alternative way of calling this an antenna inverse (which the
vendor driver also does in another section), i.e. "antenna is not
connected to the main port but instead it's connected to the other
one", seems less clear to me.
Even if we don't fully understand what's going on here, I'm convinced
that your code change is fixing an inconsistency with the vendor
driver, and most significantly, making the signal level actually
usable on our devices. But if you agree with my interpretation of
these values then maybe you could update the comment here!
Daniel
^ permalink raw reply
* RE: [PATCH v1 net-next] net: stmmac: enable clause 45 mdio support
From: Voon, Weifeng @ 2019-07-05 3:02 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Maxime Coquelin, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Jose Abreu, Giuseppe Cavallaro,
Florian Fainelli, Alexandre Torgue, biao huang, Ong, Boon Leong,
Kweh, Hock Leong
In-Reply-To: <20190704155217.GI18473@lunn.ch>
> I think there is too much passing variables around by reference than by
> value, to make this code easy to understand.
>
> Maybe a better structure would be
>
> static int stmmac_mdion_c45_read(struct stmmac_priv *priv, int phyaddr,
> int phyreg) {
>
> unsigned int reg_shift = priv->hw->mii.reg_shift;
> unsigned int reg_mask = priv->hw->mii.reg_mask;
> u32 mii_addr_val, mii_data_val;
>
> mii_addr_val = MII_GMAC4_C45E |
> ((phyreg >> MII_DEVADDR_C45_SHIFT) << reg_shift)
> & reg_mask;
> mii_data_val = (phyreg & MII_REGADDR_C45_MASK) <<
> MII_GMAC4_REG_ADDR_SHIFT;
>
> writel(mii_data_val, priv->ioaddr + priv->hw->mii_data);
> writel(mii_addr_val, priv->ioaddr + priv->hw->mii_addrress);
>
> return (int)readl(priv->ioaddr + mii_data) & MII_DATA_MASK;
> }
>
> static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr, int phyreg)
> {
>
> ...
> if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v &
> MII_BUSY),
> 100, 10000))
> return -EBUSY;
>
> if (priv->plat->has_gmac4 && phyreg & MII_ADDR_C45)
> return stmmac_mdio_c45_read(priv, phyaddr, phyreg);
>
> Andrew
Both c45 read/write needs to set c45 enable bit(MII_ADDR_C45) in mii_adrress
and set the register address in mii_data. Besides this, the whole programming
flow will be the same as c22. With the current design, user can easily know
that the different between c22 and c45 is just in stmmac_mdio_c45_setup().
If the community prefers readability, I will suggest to do the c45 setup in
both stmmac_mdio_read() and stmmac_mdio_write() 's if(C45) condition rather
than splitting into 2 new c45_read() and c45_write() functions.
static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr, int phyreg)
{
...
if (phyreg & MII_ADDR_C45)
*val |= MII_GMAC4_C45E;
*val &= ~reg_mask;
*val |= ((phyreg >> MII_DEVADDR_C45_SHIFT) << reg_shift) & reg_mask;
*data |= (phyreg & MII_REGADDR_C45_MASK) << MII_GMAC4_REG_ADDR_SHIFT;
Weifeng
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Chris Chiu @ 2019-07-05 2:27 UTC (permalink / raw)
To: Jes Sorensen
Cc: Kalle Valo, David Miller, linux-wireless, netdev, Linux Kernel,
Linux Upstreaming Team
In-Reply-To: <8f1454ca-4610-03d0-82c4-06174083d463@gmail.com>
On Fri, Jul 5, 2019 at 12:43 AM Jes Sorensen <jes.sorensen@gmail.com> wrote:
>
> On 7/4/19 6:55 AM, Chris Chiu wrote:
> > The WiFi tx power of RTL8723BU is extremely low after booting. So
> > the WiFi scan gives very limited AP list and it always fails to
> > connect to the selected AP. This module only supports 1x1 antenna
> > and the antenna is switched to bluetooth due to some incorrect
> > register settings.
> >
> > Compare with the vendor driver https://github.com/lwfinger/rtl8723bu,
> > we realized that the 8723bu's enable_rf() does the same thing as
> > rtw_btcoex_HAL_Initialize() in vendor driver. And it by default
> > sets the antenna path to BTC_ANT_PATH_BT which we verified it's
> > the cause of the wifi weak tx power. The vendor driver will set
> > the antenna path to BTC_ANT_PATH_PTA in the consequent btcoexist
> > mechanism, by the function halbtc8723b1ant_PsTdma.
> >
> > This commit hand over the antenna control to PTA(Packet Traffic
> > Arbitration), which compares the weight of bluetooth/wifi traffic
> > then determine whether to continue current wifi traffic or not.
> > After PTA take control, The wifi signal will be back to normal and
> > the bluetooth scan can also work at the same time. However, the
> > btcoexist still needs to be handled under different circumstances.
> > If there's a BT connection established, the wifi still fails to
> > connect until BT disconnected.
> >
> > Signed-off-by: Chris Chiu <chiu@endlessm.com>
> > ---
> >
> >
> > Note:
> > v2:
> > - Replace BIT(11) with the descriptive definition
> > - Meaningful comment for the REG_S0S1_PATH_SWITCH setting
> >
> >
> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 11 ++++++++---
> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++-
> > 2 files changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > index 3adb1d3d47ac..ceffe05bd65b 100644
> > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> > /*
> > * WLAN action by PTA
> > */
> > - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04);
> > + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c);
> >
> > /*
> > * BT select S0/S1 controlled by WiFi
> > @@ -1568,9 +1568,14 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> > rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.ant_sel_rsv));
> >
> > /*
> > - * 0x280, 0x00, 0x200, 0x80 - not clear
> > + * Different settings per different antenna position.
> > + * Antenna Position: | Normal Inverse
> > + * --------------------------------------------------
> > + * Antenna switch to BT: | 0x280, 0x00
> > + * Antenna switch to WiFi: | 0x0, 0x280
> > + * Antenna switch to PTA: | 0x200, 0x80
> > */
> > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
>
> Per the documentation, shouldn't this be set to 0x200 then rather than 0x80?
>
Per the code before REG_S0S1_PATH_SWITCH setting, the driver has told
the co-processor the antenna is inverse.
memset(&h2c, 0, sizeof(struct h2c_cmd));
h2c.ant_sel_rsv.cmd = H2C_8723B_ANT_SEL_RSV;
h2c.ant_sel_rsv.ant_inverse = 1;
h2c.ant_sel_rsv.int_switch_type = 0;
rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.ant_sel_rsv));
At least the current modification is consistent with the antenna
inverse setting.
I'll verify on vendor driver about when/how the inverse be determined.
Chris
> We may need to put in place so
>
> Cheers,
> Jesme code to detect whether we have normal
> or inverse configuration of the dongle otherwise?
>
> I really appreciate you're digging into this!
^ permalink raw reply
* Re: [RFC v2] vhost: introduce mdev based hardware vhost backend
From: Tiwei Bie @ 2019-07-05 2:23 UTC (permalink / raw)
To: Jason Wang
Cc: mst, alex.williamson, maxime.coquelin, linux-kernel, kvm,
virtualization, netdev, dan.daly, cunming.liang, zhihong.wang
In-Reply-To: <513c62ba-3f44-f4cf-3b3d-e0e03b6a6de1@redhat.com>
On Fri, Jul 05, 2019 at 08:30:00AM +0800, Jason Wang wrote:
> On 2019/7/4 下午3:02, Tiwei Bie wrote:
> > On Thu, Jul 04, 2019 at 02:35:20PM +0800, Jason Wang wrote:
> > > On 2019/7/4 下午2:21, Tiwei Bie wrote:
> > > > On Thu, Jul 04, 2019 at 12:31:48PM +0800, Jason Wang wrote:
> > > > > On 2019/7/3 下午9:08, Tiwei Bie wrote:
> > > > > > On Wed, Jul 03, 2019 at 08:16:23PM +0800, Jason Wang wrote:
> > > > > > > On 2019/7/3 下午7:52, Tiwei Bie wrote:
> > > > > > > > On Wed, Jul 03, 2019 at 06:09:51PM +0800, Jason Wang wrote:
> > > > > > > > > On 2019/7/3 下午5:13, Tiwei Bie wrote:
> > > > > > > > > > Details about this can be found here:
> > > > > > > > > >
> > > > > > > > > > https://lwn.net/Articles/750770/
> > > > > > > > > >
> > > > > > > > > > What's new in this version
> > > > > > > > > > ==========================
> > > > > > > > > >
> > > > > > > > > > A new VFIO device type is introduced - vfio-vhost. This addressed
> > > > > > > > > > some comments from here:https://patchwork.ozlabs.org/cover/984763/
> > > > > > > > > >
> > > > > > > > > > Below is the updated device interface:
> > > > > > > > > >
> > > > > > > > > > Currently, there are two regions of this device: 1) CONFIG_REGION
> > > > > > > > > > (VFIO_VHOST_CONFIG_REGION_INDEX), which can be used to setup the
> > > > > > > > > > device; 2) NOTIFY_REGION (VFIO_VHOST_NOTIFY_REGION_INDEX), which
> > > > > > > > > > can be used to notify the device.
> > > > > > > > > >
> > > > > > > > > > 1. CONFIG_REGION
> > > > > > > > > >
> > > > > > > > > > The region described by CONFIG_REGION is the main control interface.
> > > > > > > > > > Messages will be written to or read from this region.
> > > > > > > > > >
> > > > > > > > > > The message type is determined by the `request` field in message
> > > > > > > > > > header. The message size is encoded in the message header too.
> > > > > > > > > > The message format looks like this:
> > > > > > > > > >
> > > > > > > > > > struct vhost_vfio_op {
> > > > > > > > > > __u64 request;
> > > > > > > > > > __u32 flags;
> > > > > > > > > > /* Flag values: */
> > > > > > > > > > #define VHOST_VFIO_NEED_REPLY 0x1 /* Whether need reply */
> > > > > > > > > > __u32 size;
> > > > > > > > > > union {
> > > > > > > > > > __u64 u64;
> > > > > > > > > > struct vhost_vring_state state;
> > > > > > > > > > struct vhost_vring_addr addr;
> > > > > > > > > > } payload;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > The existing vhost-kernel ioctl cmds are reused as the message
> > > > > > > > > > requests in above structure.
> > > > > > > > > Still a comments like V1. What's the advantage of inventing a new protocol?
> > > > > > > > I'm trying to make it work in VFIO's way..
> > > > > > > >
> > > > > > > > > I believe either of the following should be better:
> > > > > > > > >
> > > > > > > > > - using vhost ioctl, we can start from SET_VRING_KICK/SET_VRING_CALL and
> > > > > > > > > extend it with e.g notify region. The advantages is that all exist userspace
> > > > > > > > > program could be reused without modification (or minimal modification). And
> > > > > > > > > vhost API hides lots of details that is not necessary to be understood by
> > > > > > > > > application (e.g in the case of container).
> > > > > > > > Do you mean reusing vhost's ioctl on VFIO device fd directly,
> > > > > > > > or introducing another mdev driver (i.e. vhost_mdev instead of
> > > > > > > > using the existing vfio_mdev) for mdev device?
> > > > > > > Can we simply add them into ioctl of mdev_parent_ops?
> > > > > > Right, either way, these ioctls have to be and just need to be
> > > > > > added in the ioctl of the mdev_parent_ops. But another thing we
> > > > > > also need to consider is that which file descriptor the userspace
> > > > > > will do the ioctl() on. So I'm wondering do you mean let the
> > > > > > userspace do the ioctl() on the VFIO device fd of the mdev
> > > > > > device?
> > > > > >
> > > > > Yes.
> > > > Got it! I'm not sure what's Alex opinion on this. If we all
> > > > agree with this, I can do it in this way.
> > > >
> > > > > Is there any other way btw?
> > > > Just a quick thought.. Maybe totally a bad idea.
> > >
> > > It's not for sure :)
> > Thanks!
> >
> > >
> > > > I was thinking
> > > > whether it would be odd to do non-VFIO's ioctls on VFIO's device
> > > > fd. So I was wondering whether it's possible to allow binding
> > > > another mdev driver (e.g. vhost_mdev) to the supported mdev
> > > > devices. The new mdev driver, vhost_mdev, can provide similar
> > > > ways to let userspace open the mdev device and do the vhost ioctls
> > > > on it. To distinguish with the vfio_mdev compatible mdev devices,
> > > > the device API of the new vhost_mdev compatible mdev devices
> > > > might be e.g. "vhost-net" for net?
> > > >
> > > > So in VFIO case, the device will be for passthru directly. And
> > > > in VHOST case, the device can be used to accelerate the existing
> > > > virtualized devices.
> > > >
> > > > How do you think?
> > >
> > > If my understanding is correct, there will be no VFIO ioctl if we go for
> > > vhost_mdev?
> > Yeah, exactly. If we go for vhost_mdev, we may have some vhost nodes
> > in /dev similar to what /dev/vfio/* does to handle the $UUID and open
> > the device (e.g. similar to VFIO_GROUP_GET_DEVICE_FD in VFIO). And
> > to setup the device, we can try to reuse the ioctls of the existing
> > kernel vhost as much as possible.
>
>
> Interesting, actually, I've considered something similar. I think there
> should be no issues other than DMA:
Yeah, that's something we need to optimize to make it more
lightweight and efficient. How about allowing userspace to
do map/unmap operations like what VFIO provides?
>
> - Need to invent new API for DMA mapping other than SET_MEM_TABLE? (Which is
> too heavyweight).
>
> - Need to consider a way to co-work with both on chip IOMMU (your proposal
> should be fine) and scalable IOV.
Maybe we can make it possible to let the parent device know
the mappings (mapping events) if they need (it would be helpful
for software-based device as well).
Thanks,
Tiwei
>
> Thanks
>
>
> >
> > Thanks,
> > Tiwei
> >
> > > Thanks
> > >
> > >
> > > > Thanks,
> > > > Tiwei
> > > > > Thanks
> > > > >
^ permalink raw reply
* [PATCH net-next] gve: Fix error return code in gve_alloc_qpls()
From: Wei Yongjun @ 2019-07-05 1:16 UTC (permalink / raw)
To: Catherine Sullivan, Sagi Shahar, Jon Olson, Colin Ian King,
Willem de Bruijn, Luigi Rizzo
Cc: Wei Yongjun, netdev, kernel-janitors
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: f5cedc84a30d ("gve: Add transmit and receive support")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/google/gve/gve_main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
index eef500bd2ff7..b65f6b010a82 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -625,8 +625,10 @@ static int gve_alloc_qpls(struct gve_priv *priv)
sizeof(unsigned long) * BITS_PER_BYTE;
priv->qpl_cfg.qpl_id_map = kvzalloc(BITS_TO_LONGS(num_qpls) *
sizeof(unsigned long), GFP_KERNEL);
- if (!priv->qpl_cfg.qpl_id_map)
+ if (!priv->qpl_cfg.qpl_id_map) {
+ err = -ENOMEM;
goto free_qpls;
+ }
return 0;
^ permalink raw reply related
* Re: [RFC v2] vhost: introduce mdev based hardware vhost backend
From: Jason Wang @ 2019-07-05 0:30 UTC (permalink / raw)
To: Tiwei Bie
Cc: mst, alex.williamson, maxime.coquelin, linux-kernel, kvm,
virtualization, netdev, dan.daly, cunming.liang, zhihong.wang
In-Reply-To: <20190704070242.GA27369@___>
On 2019/7/4 下午3:02, Tiwei Bie wrote:
> On Thu, Jul 04, 2019 at 02:35:20PM +0800, Jason Wang wrote:
>> On 2019/7/4 下午2:21, Tiwei Bie wrote:
>>> On Thu, Jul 04, 2019 at 12:31:48PM +0800, Jason Wang wrote:
>>>> On 2019/7/3 下午9:08, Tiwei Bie wrote:
>>>>> On Wed, Jul 03, 2019 at 08:16:23PM +0800, Jason Wang wrote:
>>>>>> On 2019/7/3 下午7:52, Tiwei Bie wrote:
>>>>>>> On Wed, Jul 03, 2019 at 06:09:51PM +0800, Jason Wang wrote:
>>>>>>>> On 2019/7/3 下午5:13, Tiwei Bie wrote:
>>>>>>>>> Details about this can be found here:
>>>>>>>>>
>>>>>>>>> https://lwn.net/Articles/750770/
>>>>>>>>>
>>>>>>>>> What's new in this version
>>>>>>>>> ==========================
>>>>>>>>>
>>>>>>>>> A new VFIO device type is introduced - vfio-vhost. This addressed
>>>>>>>>> some comments from here:https://patchwork.ozlabs.org/cover/984763/
>>>>>>>>>
>>>>>>>>> Below is the updated device interface:
>>>>>>>>>
>>>>>>>>> Currently, there are two regions of this device: 1) CONFIG_REGION
>>>>>>>>> (VFIO_VHOST_CONFIG_REGION_INDEX), which can be used to setup the
>>>>>>>>> device; 2) NOTIFY_REGION (VFIO_VHOST_NOTIFY_REGION_INDEX), which
>>>>>>>>> can be used to notify the device.
>>>>>>>>>
>>>>>>>>> 1. CONFIG_REGION
>>>>>>>>>
>>>>>>>>> The region described by CONFIG_REGION is the main control interface.
>>>>>>>>> Messages will be written to or read from this region.
>>>>>>>>>
>>>>>>>>> The message type is determined by the `request` field in message
>>>>>>>>> header. The message size is encoded in the message header too.
>>>>>>>>> The message format looks like this:
>>>>>>>>>
>>>>>>>>> struct vhost_vfio_op {
>>>>>>>>> __u64 request;
>>>>>>>>> __u32 flags;
>>>>>>>>> /* Flag values: */
>>>>>>>>> #define VHOST_VFIO_NEED_REPLY 0x1 /* Whether need reply */
>>>>>>>>> __u32 size;
>>>>>>>>> union {
>>>>>>>>> __u64 u64;
>>>>>>>>> struct vhost_vring_state state;
>>>>>>>>> struct vhost_vring_addr addr;
>>>>>>>>> } payload;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> The existing vhost-kernel ioctl cmds are reused as the message
>>>>>>>>> requests in above structure.
>>>>>>>> Still a comments like V1. What's the advantage of inventing a new protocol?
>>>>>>> I'm trying to make it work in VFIO's way..
>>>>>>>
>>>>>>>> I believe either of the following should be better:
>>>>>>>>
>>>>>>>> - using vhost ioctl, we can start from SET_VRING_KICK/SET_VRING_CALL and
>>>>>>>> extend it with e.g notify region. The advantages is that all exist userspace
>>>>>>>> program could be reused without modification (or minimal modification). And
>>>>>>>> vhost API hides lots of details that is not necessary to be understood by
>>>>>>>> application (e.g in the case of container).
>>>>>>> Do you mean reusing vhost's ioctl on VFIO device fd directly,
>>>>>>> or introducing another mdev driver (i.e. vhost_mdev instead of
>>>>>>> using the existing vfio_mdev) for mdev device?
>>>>>> Can we simply add them into ioctl of mdev_parent_ops?
>>>>> Right, either way, these ioctls have to be and just need to be
>>>>> added in the ioctl of the mdev_parent_ops. But another thing we
>>>>> also need to consider is that which file descriptor the userspace
>>>>> will do the ioctl() on. So I'm wondering do you mean let the
>>>>> userspace do the ioctl() on the VFIO device fd of the mdev
>>>>> device?
>>>>>
>>>> Yes.
>>> Got it! I'm not sure what's Alex opinion on this. If we all
>>> agree with this, I can do it in this way.
>>>
>>>> Is there any other way btw?
>>> Just a quick thought.. Maybe totally a bad idea.
>>
>> It's not for sure :)
> Thanks!
>
>>
>>> I was thinking
>>> whether it would be odd to do non-VFIO's ioctls on VFIO's device
>>> fd. So I was wondering whether it's possible to allow binding
>>> another mdev driver (e.g. vhost_mdev) to the supported mdev
>>> devices. The new mdev driver, vhost_mdev, can provide similar
>>> ways to let userspace open the mdev device and do the vhost ioctls
>>> on it. To distinguish with the vfio_mdev compatible mdev devices,
>>> the device API of the new vhost_mdev compatible mdev devices
>>> might be e.g. "vhost-net" for net?
>>>
>>> So in VFIO case, the device will be for passthru directly. And
>>> in VHOST case, the device can be used to accelerate the existing
>>> virtualized devices.
>>>
>>> How do you think?
>>
>> If my understanding is correct, there will be no VFIO ioctl if we go for
>> vhost_mdev?
> Yeah, exactly. If we go for vhost_mdev, we may have some vhost nodes
> in /dev similar to what /dev/vfio/* does to handle the $UUID and open
> the device (e.g. similar to VFIO_GROUP_GET_DEVICE_FD in VFIO). And
> to setup the device, we can try to reuse the ioctls of the existing
> kernel vhost as much as possible.
Interesting, actually, I've considered something similar. I think there
should be no issues other than DMA:
- Need to invent new API for DMA mapping other than SET_MEM_TABLE?
(Which is too heavyweight).
- Need to consider a way to co-work with both on chip IOMMU (your
proposal should be fine) and scalable IOV.
Thanks
>
> Thanks,
> Tiwei
>
>> Thanks
>>
>>
>>> Thanks,
>>> Tiwei
>>>> Thanks
>>>>
^ permalink raw reply
* Re: [PATCH v2 1/3] vsock/virtio: use RCU to avoid use-after-free on the_virtio_vsock
From: Jason Wang @ 2019-07-05 0:18 UTC (permalink / raw)
To: Stefano Garzarella
Cc: Stefan Hajnoczi, netdev, kvm, virtualization, Michael S. Tsirkin,
David S. Miller, linux-kernel
In-Reply-To: <20190704092044.23gd5o2rhqarisgg@steredhat.homenet.telecomitalia.it>
On 2019/7/4 下午5:20, Stefano Garzarella wrote:
>>>> This is still suspicious, can we access the_virtio_vsock through vdev->priv?
>>>> If yes, we may still get use-after-free since it was not protected by RCU.
>>> We will free the object only after calling the del_vqs(), so we are sure
>>> that the vq_callbacks ended and will no longer be invoked.
>>> So, IIUC it shouldn't happen.
>> Yes, but any dereference that is not done in vq_callbacks will be very
>> dangerous in the future.
> Right.
>
> Do you think make sense to continue with this series in order to fix the
> hot-unplug issue, then I'll work to refactor the driver code to use the refcnt
> (as you suggested in patch 2) and singleton for the_virtio_vsock?
>
> Thanks,
> Stefano
Yes.
Thanks
^ permalink raw reply
* [PATCH bpf-next] Enable zext optimization for more RV64G ALU ops
From: Luke Nelson @ 2019-07-05 0:18 UTC (permalink / raw)
To: linux-kernel
Cc: Luke Nelson, Song Liu, Jiong Wang, Xi Wang, Björn Töpel,
Palmer Dabbelt, Albert Ou, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Song Liu, Yonghong Song, netdev, linux-riscv,
bpf
commit 66d0d5a854a6 ("riscv: bpf: eliminate zero extension code-gen")
added the new zero-extension optimization for some BPF ALU operations.
Since then, bugs in the JIT that have been fixed in the bpf tree require
this optimization to be added to other operations: commit 1e692f09e091
("bpf, riscv: clear high 32 bits for ALU32 add/sub/neg/lsh/rsh/arsh"),
and commit fe121ee531d1 ("bpf, riscv: clear target register high 32-bits
for and/or/xor on ALU32")
Now that these have been merged to bpf-next, the zext optimization can
be enabled for the fixed operations.
Cc: Song Liu <liu.song.a23@gmail.com>
Cc: Jiong Wang <jiong.wang@netronome.com>
Cc: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Luke Nelson <luke.r.nels@gmail.com>
---
arch/riscv/net/bpf_jit_comp.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/riscv/net/bpf_jit_comp.c b/arch/riscv/net/bpf_jit_comp.c
index 876cb9c705ce..5451ef3845f2 100644
--- a/arch/riscv/net/bpf_jit_comp.c
+++ b/arch/riscv/net/bpf_jit_comp.c
@@ -757,31 +757,31 @@ static int emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
case BPF_ALU | BPF_ADD | BPF_X:
case BPF_ALU64 | BPF_ADD | BPF_X:
emit(is64 ? rv_add(rd, rd, rs) : rv_addw(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_SUB | BPF_X:
case BPF_ALU64 | BPF_SUB | BPF_X:
emit(is64 ? rv_sub(rd, rd, rs) : rv_subw(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_AND | BPF_X:
case BPF_ALU64 | BPF_AND | BPF_X:
emit(rv_and(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_OR | BPF_X:
case BPF_ALU64 | BPF_OR | BPF_X:
emit(rv_or(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_XOR | BPF_X:
case BPF_ALU64 | BPF_XOR | BPF_X:
emit(rv_xor(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_MUL | BPF_X:
@@ -811,13 +811,13 @@ static int emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
case BPF_ALU | BPF_RSH | BPF_X:
case BPF_ALU64 | BPF_RSH | BPF_X:
emit(is64 ? rv_srl(rd, rd, rs) : rv_srlw(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
case BPF_ALU | BPF_ARSH | BPF_X:
case BPF_ALU64 | BPF_ARSH | BPF_X:
emit(is64 ? rv_sra(rd, rd, rs) : rv_sraw(rd, rd, rs), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
@@ -826,7 +826,7 @@ static int emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
case BPF_ALU64 | BPF_NEG:
emit(is64 ? rv_sub(rd, RV_REG_ZERO, rd) :
rv_subw(rd, RV_REG_ZERO, rd), ctx);
- if (!is64)
+ if (!is64 && !aux->verifier_zext)
emit_zext_32(rd, ctx);
break;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] docs: packing: move it to core-api book and adjust markups
From: Vladimir Oltean @ 2019-07-04 23:59 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, lkml,
Jonathan Corbet, Mike Rapoport, Andrew Morton, Randy Dunlap,
Matthew Wilcox, Kent Overstreet, Arnd Bergmann,
Jonathan Neuschäfer, David S. Miller, netdev
In-Reply-To: <46cb79dbc4bbff3e5a4e77b548df1e92c105ed0f.1561804613.git.mchehab+samsung@kernel.org>
On Sat, 29 Jun 2019 at 13:37, Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> The packing.txt file was misplaced, as docs should be part of
> a documentation book, and not at the root dir.
>
> So, move it to the core-api directory and add to its index.
>
> Also, ensure that the file will be properly parsed and the bitmap
> ascii artwork will use a monotonic font.
>
> Fixes: 554aae35007e ("lib: Add support for generic packing operations")
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Tested-by: Vladimir Oltean <olteanv@gmail.com>
> ---
> Documentation/core-api/index.rst | 1 +
> .../{packing.txt => core-api/packing.rst} | 81 +++++++++++--------
> 2 files changed, 50 insertions(+), 32 deletions(-)
> rename Documentation/{packing.txt => core-api/packing.rst} (61%)
>
> diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
> index d1e5b95bf86d..aebb16d7771f 100644
> --- a/Documentation/core-api/index.rst
> +++ b/Documentation/core-api/index.rst
> @@ -25,6 +25,7 @@ Core utilities
> librs
> genalloc
> errseq
> + packing
> printk-formats
> circular-buffers
> generic-radix-tree
> diff --git a/Documentation/packing.txt b/Documentation/core-api/packing.rst
> similarity index 61%
> rename from Documentation/packing.txt
> rename to Documentation/core-api/packing.rst
> index f830c98645f1..d8c341fe383e 100644
> --- a/Documentation/packing.txt
> +++ b/Documentation/core-api/packing.rst
> @@ -30,6 +30,7 @@ The solution
> ------------
>
> This API deals with 2 basic operations:
> +
> - Packing a CPU-usable number into a memory buffer (with hardware
> constraints/quirks)
> - Unpacking a memory buffer (which has hardware constraints/quirks)
> @@ -49,10 +50,12 @@ What the examples show is where the logical bytes and bits sit.
>
> 1. Normally (no quirks), we would do it like this:
>
> -63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
> -7 6 5 4
> -31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> -3 2 1 0
> +::
> +
> + 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
> + 7 6 5 4
> + 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> + 3 2 1 0
>
> That is, the MSByte (7) of the CPU-usable u64 sits at memory offset 0, and the
> LSByte (0) of the u64 sits at memory offset 7.
> @@ -63,10 +66,12 @@ comments as "logical" notation.
>
> 2. If QUIRK_MSB_ON_THE_RIGHT is set, we do it like this:
>
> -56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
> -7 6 5 4
> -24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
> -3 2 1 0
> +::
If this is not too stylistically different from the rest of the kernel
docs, the RST syntax actually allows you to do "we do it like this::"
(with the two colons coming right after the text and not on their own
line, which looks more natural). The same comment applies to the other
changes below.
> +
> + 56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
> + 7 6 5 4
> + 24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
> + 3 2 1 0
>
> That is, QUIRK_MSB_ON_THE_RIGHT does not affect byte positioning, but
> inverts bit offsets inside a byte.
> @@ -74,10 +79,12 @@ inverts bit offsets inside a byte.
>
> 3. If QUIRK_LITTLE_ENDIAN is set, we do it like this:
>
> -39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
> -4 5 6 7
> -7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
> -0 1 2 3
> +::
> +
> + 39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
> + 4 5 6 7
> + 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
> + 0 1 2 3
>
> Therefore, QUIRK_LITTLE_ENDIAN means that inside the memory region, every
> byte from each 4-byte word is placed at its mirrored position compared to
> @@ -86,18 +93,22 @@ the boundary of that word.
> 4. If QUIRK_MSB_ON_THE_RIGHT and QUIRK_LITTLE_ENDIAN are both set, we do it
> like this:
>
> -32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
> -4 5 6 7
> -0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
> -0 1 2 3
> +::
> +
> + 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
> + 4 5 6 7
> + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
> + 0 1 2 3
>
>
> 5. If just QUIRK_LSW32_IS_FIRST is set, we do it like this:
>
> -31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> -3 2 1 0
> -63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
> -7 6 5 4
> +::
> +
> + 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> + 3 2 1 0
> + 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32
> + 7 6 5 4
>
> In this case the 8 byte memory region is interpreted as follows: first
> 4 bytes correspond to the least significant 4-byte word, next 4 bytes to
> @@ -107,28 +118,34 @@ the more significant 4-byte word.
> 6. If QUIRK_LSW32_IS_FIRST and QUIRK_MSB_ON_THE_RIGHT are set, we do it like
> this:
>
> -24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
> -3 2 1 0
> -56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
> -7 6 5 4
> +::
> +
> + 24 25 26 27 28 29 30 31 16 17 18 19 20 21 22 23 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
> + 3 2 1 0
> + 56 57 58 59 60 61 62 63 48 49 50 51 52 53 54 55 40 41 42 43 44 45 46 47 32 33 34 35 36 37 38 39
> + 7 6 5 4
>
>
> 7. If QUIRK_LSW32_IS_FIRST and QUIRK_LITTLE_ENDIAN are set, it looks like
> this:
>
> -7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
> -0 1 2 3
> -39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
> -4 5 6 7
> +::
> +
> + 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24
> + 0 1 2 3
> + 39 38 37 36 35 34 33 32 47 46 45 44 43 42 41 40 55 54 53 52 51 50 49 48 63 62 61 60 59 58 57 56
> + 4 5 6 7
>
>
> 8. If QUIRK_LSW32_IS_FIRST, QUIRK_LITTLE_ENDIAN and QUIRK_MSB_ON_THE_RIGHT
> are set, it looks like this:
>
> -0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
> -0 1 2 3
> -32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
> -4 5 6 7
> +::
> +
> + 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
> + 0 1 2 3
> + 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
> + 4 5 6 7
>
>
> We always think of our offsets as if there were no quirk, and we translate
> --
> 2.21.0
>
^ permalink raw reply
* [PATCH 0/8] treewide: correct misuses of strscpy/strlcpy
From: Joe Perches @ 2019-07-04 23:57 UTC (permalink / raw)
To: Dan Murphy, linux-leds, linux-media, linux-arm-kernel,
linuxppc-dev, linux-nfs
Cc: linux-input, linux-kernel, netdev
These are all likely copy/paste defects where the field size of the
'copied to' array is incorrect.
Each patch in this series is independent.
Joe Perches (8):
Input: synaptics: Fix misuse of strlcpy
leds: as3645a: Fix misuse of strlcpy
media: m2m-deinterlace: Fix misuse of strscpy
media: go7007: Fix misuse of strscpy
net: ethernet: sun4i-emac: Fix misuse of strlcpy
net: nixge: Fix misuse of strlcpy
tty: hvcs: Fix odd use of strlcpy
nfsd: Fix misuse of strlcpy
drivers/input/mouse/synaptics.c | 2 +-
drivers/leds/leds-as3645a.c | 2 +-
drivers/media/platform/m2m-deinterlace.c | 2 +-
drivers/media/usb/go7007/snd-go7007.c | 2 +-
drivers/net/ethernet/allwinner/sun4i-emac.c | 4 ++--
drivers/net/ethernet/ni/nixge.c | 2 +-
drivers/tty/hvc/hvcs.c | 4 ++--
fs/nfsd/nfs4idmap.c | 2 +-
8 files changed, 10 insertions(+), 10 deletions(-)
--
2.15.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox