* [PATCH net-next 08/12] net: hns3: remove dcb_ops->map_update in hclge_dcb
From: Huazhong Tan @ 2019-01-26 16:49 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, huangdaode, yisen.zhuang, salil.mehta,
linuxarm, Yunsheng Lin, Peng Li, Huazhong Tan
In-Reply-To: <20190126164921.3872-1-tanhuazhong@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
After doing down/uninit/init/up in hclge_dcb, it is not necessary
to call dcb_ops->map_update in enet, so hclge_map_update can be
called directly in hclge_dcb.
This is for preparing to call hns3_nic_set_real_num_queue with
netdev down when user changes mqprio configuration.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 -
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 10 +---------
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 9 +++++----
3 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index dc3db45361d3..585800e634e6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -477,7 +477,6 @@ struct hnae3_dcb_ops {
u8 (*getdcbx)(struct hnae3_handle *);
u8 (*setdcbx)(struct hnae3_handle *, u8);
- int (*map_update)(struct hnae3_handle *);
int (*setup_tc)(struct hnae3_handle *, u8, u8 *);
};
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 927a980fc211..0ecaeab2dad4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3737,7 +3737,6 @@ static int hns3_client_setup_tc(struct hnae3_handle *handle, u8 tc)
{
struct hnae3_knic_private_info *kinfo = &handle->kinfo;
struct net_device *ndev = kinfo->netdev;
- int ret;
if (tc > HNAE3_MAX_TC)
return -EINVAL;
@@ -3745,14 +3744,7 @@ static int hns3_client_setup_tc(struct hnae3_handle *handle, u8 tc)
if (!ndev)
return -ENODEV;
- ret = (kinfo->dcb_ops && kinfo->dcb_ops->map_update) ?
- kinfo->dcb_ops->map_update(handle) : -EOPNOTSUPP;
- if (ret)
- return ret;
-
- ret = hns3_nic_set_real_num_queue(ndev);
-
- return ret;
+ return hns3_nic_set_real_num_queue(ndev);
}
static int hns3_recover_hw_addr(struct net_device *ndev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
index 6c387b21f882..de8e38cca507 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
@@ -156,10 +156,8 @@ static int hclge_ets_validate(struct hclge_dev *hdev, struct ieee_ets *ets,
return 0;
}
-static int hclge_map_update(struct hnae3_handle *h)
+static int hclge_map_update(struct hclge_dev *hdev)
{
- struct hclge_vport *vport = hclge_get_vport(h);
- struct hclge_dev *hdev = vport->back;
int ret;
ret = hclge_tm_schd_setup_hw(hdev);
@@ -235,6 +233,10 @@ static int hclge_ieee_setets(struct hnae3_handle *h, struct ieee_ets *ets)
goto err_out;
if (map_changed) {
+ ret = hclge_map_update(hdev);
+ if (ret)
+ goto err_out;
+
ret = hclge_client_setup_tc(hdev);
if (ret)
goto err_out;
@@ -411,7 +413,6 @@ static const struct hnae3_dcb_ops hns3_dcb_ops = {
.ieee_setpfc = hclge_ieee_setpfc,
.getdcbx = hclge_getdcbx,
.setdcbx = hclge_setdcbx,
- .map_update = hclge_map_update,
.setup_tc = hclge_setup_tc,
};
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 07/12] net: hns3: do reinitialization while mqprio configuration changed
From: Huazhong Tan @ 2019-01-26 16:49 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, huangdaode, yisen.zhuang, salil.mehta,
linuxarm, Yunsheng Lin, Peng Li, Huazhong Tan
In-Reply-To: <20190126164921.3872-1-tanhuazhong@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
When user changes the mqprio configuration, enet need to be
uninited and inited besides down'ed and up'ed, because the queue
num may change when the TC num changes.
Also, it is more suitable to do the down/unint/init/up operation
in hclge module using hclge_notify_client, because this config
change may affect PF and its VF.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
.../net/ethernet/hisilicon/hns3/hns3_enet.c | 17 ++-------------
.../hisilicon/hns3/hns3pf/hclge_dcb.c | 21 +++++++++++++++++--
2 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 322af28ab4b5..927a980fc211 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1482,7 +1482,6 @@ static int hns3_setup_tc(struct net_device *netdev, void *type_data)
u8 tc = mqprio_qopt->qopt.num_tc;
u16 mode = mqprio_qopt->mode;
u8 hw = mqprio_qopt->qopt.hw;
- bool if_running;
int ret;
if (!((hw == TC_MQPRIO_HW_OFFLOAD_TCS &&
@@ -1495,24 +1494,12 @@ static int hns3_setup_tc(struct net_device *netdev, void *type_data)
if (!netdev)
return -EINVAL;
- if_running = netif_running(netdev);
- if (if_running) {
- hns3_nic_net_stop(netdev);
- msleep(100);
- }
-
ret = (kinfo->dcb_ops && kinfo->dcb_ops->setup_tc) ?
kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : -EOPNOTSUPP;
if (ret)
- goto out;
-
- ret = hns3_nic_set_real_num_queue(netdev);
-
-out:
- if (if_running)
- hns3_nic_net_open(netdev);
+ return ret;
- return ret;
+ return hns3_nic_set_real_num_queue(netdev);
}
static int hns3_nic_setup_tc(struct net_device *dev, enum tc_setup_type type,
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
index 90b566e8e454..6c387b21f882 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
@@ -370,12 +370,25 @@ static int hclge_setup_tc(struct hnae3_handle *h, u8 tc, u8 *prio_tc)
if (ret)
return -EINVAL;
+ ret = hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
+ if (ret)
+ return ret;
+
+ ret = hclge_notify_client(hdev, HNAE3_UNINIT_CLIENT);
+ if (ret)
+ return ret;
+
hclge_tm_schd_info_update(hdev, tc);
hclge_tm_prio_tc_info_update(hdev, prio_tc);
ret = hclge_tm_init_hw(hdev, false);
- if (ret)
+ if (ret) {
+ if (hclge_notify_client(hdev, HNAE3_INIT_CLIENT))
+ return ret;
+
+ hclge_notify_client(hdev, HNAE3_UP_CLIENT);
return ret;
+ }
hdev->flag &= ~HCLGE_FLAG_DCB_ENABLE;
@@ -384,7 +397,11 @@ static int hclge_setup_tc(struct hnae3_handle *h, u8 tc, u8 *prio_tc)
else
hdev->flag &= ~HCLGE_FLAG_MQPRIO_ENABLE;
- return 0;
+ ret = hclge_notify_client(hdev, HNAE3_INIT_CLIENT);
+ if (ret)
+ return ret;
+
+ return hclge_notify_client(hdev, HNAE3_UP_CLIENT);
}
static const struct hnae3_dcb_ops hns3_dcb_ops = {
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 06/12] net: hns3: After setting the loopback, add the status of getting MAC
From: Huazhong Tan @ 2019-01-26 16:49 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, huangdaode, yisen.zhuang, salil.mehta,
linuxarm, liuzhongzhu, Peng Li, Huazhong Tan
In-Reply-To: <20190126164921.3872-1-tanhuazhong@huawei.com>
From: liuzhongzhu <liuzhongzhu@huawei.com>
After setting the serdes loopback, you need to determine
the status of the MAC negotiation. If a status exception
is obtained after 200ms, a timeout error is returned.
Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
.../hisilicon/hns3/hns3pf/hclge_main.c | 23 ++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 558389a18353..ae8336c18264 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5237,8 +5237,15 @@ static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
{
#define HCLGE_SERDES_RETRY_MS 10
#define HCLGE_SERDES_RETRY_NUM 100
+
+#define HCLGE_MAC_LINK_STATUS_MS 20
+#define HCLGE_MAC_LINK_STATUS_NUM 10
+#define HCLGE_MAC_LINK_STATUS_DOWN 0
+#define HCLGE_MAC_LINK_STATUS_UP 1
+
struct hclge_serdes_lb_cmd *req;
struct hclge_desc desc;
+ int mac_link_ret = 0;
int ret, i = 0;
u8 loop_mode_b;
@@ -5261,8 +5268,10 @@ static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
if (en) {
req->enable = loop_mode_b;
req->mask = loop_mode_b;
+ mac_link_ret = HCLGE_MAC_LINK_STATUS_UP;
} else {
req->mask = loop_mode_b;
+ mac_link_ret = HCLGE_MAC_LINK_STATUS_DOWN;
}
ret = hclge_cmd_send(&hdev->hw, &desc, 1);
@@ -5294,7 +5303,19 @@ static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en,
}
hclge_cfg_mac_mode(hdev, en);
- return 0;
+
+ i = 0;
+ do {
+ /* serdes Internal loopback, independent of the network cable.*/
+ msleep(HCLGE_MAC_LINK_STATUS_MS);
+ ret = hclge_get_mac_link_status(hdev);
+ if (ret == mac_link_ret)
+ return 0;
+ } while (++i < HCLGE_MAC_LINK_STATUS_NUM);
+
+ dev_err(&hdev->pdev->dev, "config mac mode timeout\n");
+
+ return -EBUSY;
}
static int hclge_tqp_enable(struct hclge_dev *hdev, int tqp_id,
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 12/12] net: hns3: don't allow vf to enable promisc mode
From: Huazhong Tan @ 2019-01-26 16:49 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, huangdaode, yisen.zhuang, salil.mehta,
linuxarm, Jian Shen, Huazhong Tan
In-Reply-To: <20190126164921.3872-1-tanhuazhong@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
VF can receive packets of other functions when in promisc
mode. It's not safe, so don't allow VF to enable promisc
mode.
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
.../hisilicon/hns3/hns3pf/hclge_mbx.c | 7 ++--
.../hisilicon/hns3/hns3vf/hclgevf_main.c | 32 +++++++++++--------
2 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
index a1de451a85df..3603034aa45c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
@@ -203,12 +203,11 @@ static int hclge_map_unmap_ring_to_vf_vector(struct hclge_vport *vport, bool en,
static int hclge_set_vf_promisc_mode(struct hclge_vport *vport,
struct hclge_mbx_vf_to_pf_cmd *req)
{
- bool en_uc = req->msg[1] ? true : false;
- bool en_mc = req->msg[2] ? true : false;
+ bool en_bc = req->msg[1] ? true : false;
struct hclge_promisc_param param;
- /* always enable broadcast promisc bit */
- hclge_promisc_param_init(¶m, en_uc, en_mc, true, vport->vport_id);
+ /* vf is not allowed to enable unicast/multicast broadcast */
+ hclge_promisc_param_init(¶m, false, false, en_bc, vport->vport_id);
return hclge_cmd_set_promisc_mode(vport->back, ¶m);
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index 24b54083b5f9..fc99a0c70164 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -969,33 +969,29 @@ static int hclgevf_put_vector(struct hnae3_handle *handle, int vector)
}
static int hclgevf_cmd_set_promisc_mode(struct hclgevf_dev *hdev,
- bool en_uc_pmc, bool en_mc_pmc)
+ bool en_bc_pmc)
{
struct hclge_mbx_vf_to_pf_cmd *req;
struct hclgevf_desc desc;
- int status;
+ int ret;
req = (struct hclge_mbx_vf_to_pf_cmd *)desc.data;
hclgevf_cmd_setup_basic_desc(&desc, HCLGEVF_OPC_MBX_VF_TO_PF, false);
req->msg[0] = HCLGE_MBX_SET_PROMISC_MODE;
- req->msg[1] = en_uc_pmc ? 1 : 0;
- req->msg[2] = en_mc_pmc ? 1 : 0;
+ req->msg[1] = en_bc_pmc ? 1 : 0;
- status = hclgevf_cmd_send(&hdev->hw, &desc, 1);
- if (status)
+ ret = hclgevf_cmd_send(&hdev->hw, &desc, 1);
+ if (ret)
dev_err(&hdev->pdev->dev,
- "Set promisc mode fail, status is %d.\n", status);
+ "Set promisc mode fail, status is %d.\n", ret);
- return status;
+ return ret;
}
-static int hclgevf_set_promisc_mode(struct hnae3_handle *handle,
- bool en_uc_pmc, bool en_mc_pmc)
+static int hclgevf_set_promisc_mode(struct hclgevf_dev *hdev, bool en_bc_pmc)
{
- struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
-
- return hclgevf_cmd_set_promisc_mode(hdev, en_uc_pmc, en_mc_pmc);
+ return hclgevf_cmd_set_promisc_mode(hdev, en_bc_pmc);
}
static int hclgevf_tqp_enable(struct hclgevf_dev *hdev, int tqp_id,
@@ -2382,6 +2378,15 @@ static int hclgevf_init_hdev(struct hclgevf_dev *hdev)
if (ret)
goto err_config;
+ /* vf is not allowed to enable unicast/multicast promisc mode.
+ * For revision 0x20, default to disable broadcast promisc mode,
+ * firmware makes sure broadcast packets can be accepted.
+ * For revision 0x21, default to enable broadcast promisc mode.
+ */
+ ret = hclgevf_set_promisc_mode(hdev, true);
+ if (ret)
+ goto err_config;
+
/* Initialize RSS for this VF */
ret = hclgevf_rss_init_hw(hdev);
if (ret) {
@@ -2646,7 +2651,6 @@ static const struct hnae3_ae_ops hclgevf_ops = {
.get_vector = hclgevf_get_vector,
.put_vector = hclgevf_put_vector,
.reset_queue = hclgevf_reset_tqp,
- .set_promisc_mode = hclgevf_set_promisc_mode,
.get_mac_addr = hclgevf_get_mac_addr,
.set_mac_addr = hclgevf_set_mac_addr,
.add_uc_addr = hclgevf_add_uc_addr,
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 05/12] net: hns3: fix broadcast promisc issue for revision 0x20
From: Huazhong Tan @ 2019-01-26 16:49 UTC (permalink / raw)
To: davem
Cc: netdev, linux-kernel, huangdaode, yisen.zhuang, salil.mehta,
linuxarm, Jian Shen, Peng Li, Huazhong Tan
In-Reply-To: <20190126164921.3872-1-tanhuazhong@huawei.com>
From: Jian Shen <shenjian15@huawei.com>
For revision 0x20, vlan filter is always bypassed when enable
broadcast promisc mode. In this case, broadcast packets with
any vlan id can be accpeted. We should disable broadcast promisc
mode until user want enable it.
Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support")
Signed-off-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 4 ++--
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 10 +++++++++-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index cec09235b1ef..322af28ab4b5 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -506,7 +506,7 @@ static u8 hns3_get_netdev_flags(struct net_device *netdev)
u8 flags = 0;
if (netdev->flags & IFF_PROMISC) {
- flags = HNAE3_USER_UPE | HNAE3_USER_MPE;
+ flags = HNAE3_USER_UPE | HNAE3_USER_MPE | HNAE3_BPE;
} else {
flags |= HNAE3_VLAN_FLTR;
if (netdev->flags & IFF_ALLMULTI)
@@ -541,13 +541,13 @@ static void hns3_nic_set_rx_mode(struct net_device *netdev)
}
}
- hns3_update_promisc_mode(netdev, new_flags);
/* User mode Promisc mode enable and vlan filtering is disabled to
* let all packets in. MAC-VLAN Table overflow Promisc enabled and
* vlan fitering is enabled
*/
hns3_enable_vlan_filter(netdev, new_flags & HNAE3_VLAN_FLTR);
h->netdev_flags = new_flags;
+ hns3_update_promisc_mode(netdev, new_flags);
}
int hns3_update_promisc_mode(struct net_device *netdev, u8 promisc_flags)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index d5482f9c422c..558389a18353 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3843,8 +3843,16 @@ static int hclge_set_promisc_mode(struct hnae3_handle *handle, bool en_uc_pmc,
struct hclge_vport *vport = hclge_get_vport(handle);
struct hclge_dev *hdev = vport->back;
struct hclge_promisc_param param;
+ bool en_bc_pmc = true;
- hclge_promisc_param_init(¶m, en_uc_pmc, en_mc_pmc, true,
+ /* For revision 0x20, if broadcast promisc enabled, vlan filter is
+ * always bypassed. So broadcast promisc should be disabled until
+ * user enable promisc mode
+ */
+ if (handle->pdev->revision == 0x20)
+ en_bc_pmc = handle->netdev_flags & HNAE3_BPE ? true : false;
+
+ hclge_promisc_param_init(¶m, en_uc_pmc, en_mc_pmc, en_bc_pmc,
vport->vport_id);
return hclge_cmd_set_promisc_mode(hdev, ¶m);
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] Revert "net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x"
From: Russell King - ARM Linux admin @ 2019-01-26 16:23 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <20190126155834.GA24361@lunn.ch>
On Sat, Jan 26, 2019 at 04:58:34PM +0100, Andrew Lunn wrote:
> On Fri, Jan 25, 2019 at 11:27:57PM +0000, Russell King wrote:
> > This reverts commit 6623c0fba10ef45b64ca213ad5dec926f37fa9a0.
> >
> > The original diagnosis was incorrect: it appears that the NIC had
> > PHY polling mode enabled, which meant that it overwrote the PHYs
> > advertisement register during negotiation.
>
> Hi Russell
>
> The NIC wrote to PHY registers? The NIC reading the PHY in hardware is
> bad enough, but changing register as well is not good.
Yep, it seems so.
> What NIC is this? And do you have further patches to really disable
> PHY polling?
The PP2.2 in 8040 when used with the Marvell mvpp2x driver (that I
have in my mcbin branch) - mainline's mvpp2 driver doesn't suffer
from it as that disables polling mode.
What made the diagnosis hard is that disabling phy polling by poking
the SMI registers doesn't stop the PHY being polled, it seems to need
something extra - and not having the documentation doesn't help. As
I said, using a 'scope on the MDIO signal and noticing that the
hardware was still polling the PHY despite the poll bit disabled was
key to getting to the bottom of what was really going on. Once I
arranged to clear it during driver initialisation and rebooted the
platform, the PHY then had the expected behaviour.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next] Documentation: net: phy: switch documentation to rst format
From: Andrew Lunn @ 2019-01-26 16:03 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <326391fb-d6ed-31dc-147e-b4ee3914d82f@gmail.com>
On Sat, Jan 26, 2019 at 11:25:37AM +0100, Heiner Kallweit wrote:
> Switch phylib documentation to rst format.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] Revert "net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x"
From: Andrew Lunn @ 2019-01-26 15:58 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <E1gnAtB-0002Cz-Tr@rmk-PC.armlinux.org.uk>
On Fri, Jan 25, 2019 at 11:27:57PM +0000, Russell King wrote:
> This reverts commit 6623c0fba10ef45b64ca213ad5dec926f37fa9a0.
>
> The original diagnosis was incorrect: it appears that the NIC had
> PHY polling mode enabled, which meant that it overwrote the PHYs
> advertisement register during negotiation.
Hi Russell
The NIC wrote to PHY registers? The NIC reading the PHY in hardware is
bad enough, but changing register as well is not good.
What NIC is this? And do you have further patches to really disable
PHY polling?
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [RFC PATCH 2/6] net/sched: flower: add support for matching on ConnTrack
From: Marcelo Ricardo Leitner @ 2019-01-26 15:52 UTC (permalink / raw)
To: Simon Horman
Cc: Guy Shattah, Aaron Conole, John Hurley, Justin Pettit,
Gregory Rose, Eelco Chaudron, Flavio Leitner, Florian Westphal,
Jiri Pirko, Rashid Khan, Sushil Kulkarni, Andy Gospodarek,
Roi Dayan, Yossi Kuperman, Or Gerlitz, Rony Efraim,
davem@davemloft.net, netdev
In-Reply-To: <20190125133711.f3caew4d7osr5czg@netronome.com>
On Fri, Jan 25, 2019 at 02:37:13PM +0100, Simon Horman wrote:
> Hi Marcelo,
>
> On Fri, Jan 25, 2019 at 12:32:31AM -0200, Marcelo Ricardo Leitner wrote:
> > Hook on flow dissector's new interface on ConnTrack from previous patch.
> >
> > Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> > ---
> > include/uapi/linux/pkt_cls.h | 9 +++++++++
> > net/sched/cls_flower.c | 33 +++++++++++++++++++++++++++++++++
> > 2 files changed, 42 insertions(+)
> >
> > diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> > index 95d0db2a8350dffb1dd20816591f3b179913fb2e..ba1f3bc01b2fdfd810e37a2b3853a1da1f838acf 100644
> > --- a/include/uapi/linux/pkt_cls.h
> > +++ b/include/uapi/linux/pkt_cls.h
> > @@ -490,6 +490,15 @@ enum {
> > TCA_FLOWER_KEY_PORT_DST_MIN, /* be16 */
> > TCA_FLOWER_KEY_PORT_DST_MAX, /* be16 */
> >
> > + TCA_FLOWER_KEY_CT_ZONE, /* u16 */
> > + TCA_FLOWER_KEY_CT_ZONE_MASK, /* u16 */
> > + TCA_FLOWER_KEY_CT_STATE, /* u8 */
> > + TCA_FLOWER_KEY_CT_STATE_MASK, /* u8 */
>
> With the corresponding flow dissector patch this API is
> exposing the contents of an instance of enum ip_conntrack_info
> as an ABI for conntrack state.
>
> I believe (after getting similar review for my geneve options macthing
> patches for flower) that this exposes implementation details as an ABI
> to a degree that is not desirable.
>
> My suggested would be to define, say in the form of named bits,
> an ABI, that describes the state information that is exposed.
> These bits may not correspond directly to the implementation of
> ip_conntrack_info.
>
> I think there should also be some consideration of if a mask makes
> sense for the state as, f.e. in the implementation of enum
> ip_conntrack_info not all bit combinations are valid.
Right. ct_state must be handled differently. For conntrack it is a
linear enum and as we want to be able to OR match, we will have to
convert the states in a bitfield as you were saying or so.
I don't think the representation above wouldn't change, though: we have
8 bits wrapped under a u8. What would change is how we deal with it.
If iproute tc is able to parse the cmdline and set a corresponding bit
for each state, the flower-side of flow dissector here should be
mostly fine (need to consider the invalid bits as you mentioned, as
part of sanity checking).
Then just need to change on how flow dissector is reading ct_state
from the packet.
Is your comment only related to ct_state or other fields too? I'm
thinking only ct_state.
>
> > + TCA_FLOWER_KEY_CT_MARK, /* u32 */
> > + TCA_FLOWER_KEY_CT_MARK_MASK, /* u32 */
> > + TCA_FLOWER_KEY_CT_LABEL, /* 128 bits */
> > + TCA_FLOWER_KEY_CT_LABEL_MASK, /* 128 bits */
> > +
> > __TCA_FLOWER_MAX,
> > };
>
> ...
>
^ permalink raw reply
* Re: [net-next PATCH] MAINTAINERS: Add entry for XDP core code
From: Jesper Dangaard Brouer @ 2019-01-26 14:44 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev, David S. Miller, Daniel Borkmann, Jakub Kicinski,
Alexei Starovoitov, brouer, Toke Høiland-Jørgensen,
Ilias Apalodimas
In-Reply-To: <a588ab43-a61b-7106-589b-b3d6c92f42b4@iogearbox.net>
On Fri, 25 Jan 2019 23:10:51 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> Hi Jesper,
>
> On 01/25/2019 01:02 PM, Jesper Dangaard Brouer wrote:
> > Add myself as a maintainer for these parts, as I'm responsible
> > for adding most of this.
> >
> > Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > ---
> > MAINTAINERS | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index a0245fd1b09a..f66297853df7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -16686,6 +16686,15 @@ T: git git://linuxtv.org/media_tree.git
> > S: Maintained
> > F: drivers/media/tuners/tuner-xc2028.*
> >
> > +XDP
>
> Hm, I think this may be a bit misleading, XDP 'core' bits that are
> needed for XDP base operation are spread into many more places than
> just the ones listed below like net/core/dev.c, net/core/rtnetlink.c,
> net/core/filter.c to name a few,
It would likely be misleading to include those files, as they contain a
lot of other stuff. I would like to get Cc noticed if some of the
parts related to XDP change. I'm unsure of the effect on
get_maintainer.pl if a file is added in several entries?
> then obviously drivers themselves,
I would like to get Cc notified on drivers adding XDP or changing XDP
support. I did miss reviewing an ARM driver (before it got applied)
getting XDP support, but it doesn't implement the correct memory model,
which will break if they implement XDP_REDIRECT (which the driver
"fortunately" doesn't). I do want to catch these cases, but it is
unrealistic to add all the driver files to this entry.
> and also there's net/xdp/ etc.
Notice the next entry "XDP SOCKETS (AF_XDP)" covers net/xdp/.
> Depending on what you mean, it might
> make it probably more clear to split this into specific sub-topics
> like below XDP SOCKETS, e.g. XDP CPUMAP, XDP PAGE POOL or such for
> expert review,
The target files I choose to include, are primarily target for the
"XDP REDIRECT" feature. So, I you don't feel comfortable with a too
wide catch-all XDP, then I propose to rename it to "XDP REDIRECT".
> or if this should be some sort of catch-all (?)
I'm 100% ready to signup for a larger commitment to XDP in general.
So, I don't have a problem with this being a catch-all for XDP.
I have big plans for XDP this year. Red Hat have hired more resources
(Toke), and Linaro is also participating (Ilias). We are going to do
project management and design docs 100% in the open via github[1].
[1] https://github.com/xdp-project
> underneath general networking entry, then this should more accurately
> reflect core code so reviewers are properly Cc'ed on all the pieces
> if someone runs get_maintainer.pl to get a Cc list ...
The main purpose of this patch is exactly to get selected as Cc when
someone uses get_maintainer.pl. (e.g. today I'm not listed for
include/net/xdp.h, even-though I wrote 80% of that file).
> maybe also makes sense to add other XDP contributors as well.
I would love to see more XDP contributors to signup and be listed under
this entry.
> > +M: Jesper Dangaard Brouer <hawk@kernel.org>
> > +L: netdev@vger.kernel.org
> > +L: xdp-newbies@vger.kernel.org
> > +F: net/core/xdp.c
> > +F: include/net/xdp.h
> > +F: kernel/bpf/devmap.c
> > +F: kernel/bpf/cpumap.c
> > +
> > XDP SOCKETS (AF_XDP)
> > M: Björn Töpel <bjorn.topel@intel.com>
> > M: Magnus Karlsson <magnus.karlsson@intel.com>
Another reason for this patch was that I noticed Bjørn and Magnus had
an entry, so I though I should also signup to take some responsibility.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: WoL broken in r8169.c since kernel 4.19
From: Heiner Kallweit @ 2019-01-26 14:09 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev@vger.kernel.org
In-Reply-To: <47a81eb9-64bf-9477-f268-1fc35ee39cd9@gmail.com>
On 26.01.2019 15:08, Heiner Kallweit wrote:
> On 13.01.2019 17:01, Marc Haber wrote:
>> On Sat, Jan 12, 2019 at 09:28:48PM +0100, Heiner Kallweit wrote:
>>> On 12.01.2019 21:08, Marc Haber wrote:
>>>> I am writing to all people who have commits in r8169.c between the v4.18
>>>> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
>>>> you'd prefer that to be on a mailing list, please indicate on which list
>>>> you want to have that, and I'll resend.
>>>>
>>> It should be cc'ed to the netdev mailing list, as listed in MAINTAINERS.
>>
>> I have bounced the original message there. Sorry for missing that, I was
>> not aware that the MAINTAINERS file goes down on a single driver level.
>>
>>>> My desktop copmuter has the following network interface:
>>>>
>>>> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
>>>> Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards
>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>> Latency: 0, Cache Line Size: 64 bytes
>>>> Interrupt: pin A routed to IRQ 17
>>>> NUMA node: 0
>>>> Region 0: I/O ports at e800 [size=256]
>>>> Region 2: Memory at fdfff000 (64-bit, prefetchable) [size=4K]
>>>> Region 4: Memory at fdff8000 (64-bit, prefetchable) [size=16K]
>>>> Capabilities: <access denied>
>>>> Kernel driver in use: r8169
>>>> Kernel modules: r8169
>>>>
>>> Unfortunately there's different chip versions with the same description.
>>> Please provide the result of "dmesg | grep XID".
>>
>> [1/5004]mh@fan:~ $ dmesg | grep XID
>> [ 2.671004] r8169 0000:06:00.0 eth0: RTL8168evl/8111evl, 54:04:a6:82:21:00, XID 2c900800, IRQ 29
>>
>>>> I regularly buíld a VPN tunnel to my local network from 'on the road'
>>>> and use WoL to wake up the desktop box when I need it.
>>>>
>>>> Since kernel 4.19, that does not work any more, the desktop remains
>>>> suspended when I send it a magic packet. This still applies to 4.20.1,
>>>> and it still works with any 4.18 kernel.
>>>>
>>> WoL works perfectly fine here with r8169 from runtime-suspend and
>>> from S3. How do you enable WoL? And which WoL method do you use
>>> (magic packet or ..) ?
>>
>> I do enable WOL via systemd-networkd:
>> [7/5009]mh@fan:~ $ cat /etc/systemd/network/10-lanc0.link
>> [Match]
>> MACAddress=54:04:a6:82:21:00
>>
>> [Link]
>> Name=lanc0
>> WakeOnLan=magic
>>
>> and I wake up the box by calling
>>
>> sudo etherwake -i int182 54:04:a6:82:21:00
>>
>> on the router. int182 is the interface name of the correct interface,
>> this is proven correct by the fact that the box wakes up just fine with
>> older version of the driver.
>>
>>> Please provide a register dump (ethtool -d <if>).
>>
>> The register dump is here (obtained with 4.20.1 with the r8169.c from
>> 4.18):
>> [5/5008]mh@fan:~ $ sudo ethtool -d lanc0
>
> Just one more thing because this register dump was with the r8169 driver
> from 4.18 which is known to work.
> Can you provide a register dump from a 4.20 r8169 which suffers from the issue?
>
Sorry, just saw that you did so already.
^ permalink raw reply
* Re: WoL broken in r8169.c since kernel 4.19
From: Heiner Kallweit @ 2019-01-26 14:08 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190113160149.GG20268@torres.zugschlus.de>
On 13.01.2019 17:01, Marc Haber wrote:
> On Sat, Jan 12, 2019 at 09:28:48PM +0100, Heiner Kallweit wrote:
>> On 12.01.2019 21:08, Marc Haber wrote:
>>> I am writing to all people who have commits in r8169.c between the v4.18
>>> and v4.19 tags in the Linux kernel. Please ignore as appropriate. If
>>> you'd prefer that to be on a mailing list, please indicate on which list
>>> you want to have that, and I'll resend.
>>>
>> It should be cc'ed to the netdev mailing list, as listed in MAINTAINERS.
>
> I have bounced the original message there. Sorry for missing that, I was
> not aware that the MAINTAINERS file goes down on a single driver level.
>
>>> My desktop copmuter has the following network interface:
>>>
>>> 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
>>> Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>>> Latency: 0, Cache Line Size: 64 bytes
>>> Interrupt: pin A routed to IRQ 17
>>> NUMA node: 0
>>> Region 0: I/O ports at e800 [size=256]
>>> Region 2: Memory at fdfff000 (64-bit, prefetchable) [size=4K]
>>> Region 4: Memory at fdff8000 (64-bit, prefetchable) [size=16K]
>>> Capabilities: <access denied>
>>> Kernel driver in use: r8169
>>> Kernel modules: r8169
>>>
>> Unfortunately there's different chip versions with the same description.
>> Please provide the result of "dmesg | grep XID".
>
> [1/5004]mh@fan:~ $ dmesg | grep XID
> [ 2.671004] r8169 0000:06:00.0 eth0: RTL8168evl/8111evl, 54:04:a6:82:21:00, XID 2c900800, IRQ 29
>
>>> I regularly buíld a VPN tunnel to my local network from 'on the road'
>>> and use WoL to wake up the desktop box when I need it.
>>>
>>> Since kernel 4.19, that does not work any more, the desktop remains
>>> suspended when I send it a magic packet. This still applies to 4.20.1,
>>> and it still works with any 4.18 kernel.
>>>
>> WoL works perfectly fine here with r8169 from runtime-suspend and
>> from S3. How do you enable WoL? And which WoL method do you use
>> (magic packet or ..) ?
>
> I do enable WOL via systemd-networkd:
> [7/5009]mh@fan:~ $ cat /etc/systemd/network/10-lanc0.link
> [Match]
> MACAddress=54:04:a6:82:21:00
>
> [Link]
> Name=lanc0
> WakeOnLan=magic
>
> and I wake up the box by calling
>
> sudo etherwake -i int182 54:04:a6:82:21:00
>
> on the router. int182 is the interface name of the correct interface,
> this is proven correct by the fact that the box wakes up just fine with
> older version of the driver.
>
>> Please provide a register dump (ethtool -d <if>).
>
> The register dump is here (obtained with 4.20.1 with the r8169.c from
> 4.18):
> [5/5008]mh@fan:~ $ sudo ethtool -d lanc0
Just one more thing because this register dump was with the r8169 driver
from 4.18 which is known to work.
Can you provide a register dump from a 4.20 r8169 which suffers from the issue?
^ permalink raw reply
* Re: WoL broken in r8169.c since kernel 4.19
From: Heiner Kallweit @ 2019-01-26 14:04 UTC (permalink / raw)
To: Marc Haber; +Cc: netdev@vger.kernel.org
In-Reply-To: <20190126135640.GD27062@torres.zugschlus.de>
On 26.01.2019 14:56, Marc Haber wrote:
> On Fri, Jan 25, 2019 at 07:22:36PM +0100, Heiner Kallweit wrote:
>> Then I'm slowly running out of ideas. New in 4.19 is a check for invalid
>> WoL flags, but usually the caller should warn if -EINVAL is returned.
>> Nevertheless, could you try the following and check whether the warning
>> is triggered?
>
> Compiled the kernel, went through the motions:
>
> - boot
> - suspend
> - try unsuccessful WoL
> - wake up manually
> - do ethtool gymnastics
> - suspend
> - try successful WoL
> - grep syslog for "WoL", nothing found.
>
Thanks for testing. Then the only way to find the offending commit is bisecting.
Let me know if you need support.
I can't reproduce the issue on latest kernels even though RTL8168evl and RTL8168g
use the same WoL code path.
> Greetings
> Marc
>
Heiner
^ permalink raw reply
* Re: WoL broken in r8169.c since kernel 4.19
From: Marc Haber @ 2019-01-26 13:56 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: netdev@vger.kernel.org
In-Reply-To: <548c1682-ad7c-3a0a-b2ea-2207f328b070@gmail.com>
On Fri, Jan 25, 2019 at 07:22:36PM +0100, Heiner Kallweit wrote:
> Then I'm slowly running out of ideas. New in 4.19 is a check for invalid
> WoL flags, but usually the caller should warn if -EINVAL is returned.
> Nevertheless, could you try the following and check whether the warning
> is triggered?
Compiled the kernel, went through the motions:
- boot
- suspend
- try unsuccessful WoL
- wake up manually
- do ethtool gymnastics
- suspend
- try successful WoL
- grep syslog for "WoL", nothing found.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* [PATCH] iwlwifi: Use kmemdup instead of duplicating its function
From: YueHaibing @ 2019-01-26 12:42 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, linuxwifi,
kvalo
Cc: linux-kernel, netdev, linux-wireless, YueHaibing
Use kmemdup rather than duplicating its implementation
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
index d9afedc..569cc50 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
@@ -1196,13 +1196,9 @@ iwl_parse_nvm_mcc_info(struct device *dev, const struct iwl_cfg *cfg,
regd_to_copy = sizeof(struct ieee80211_regdomain) +
valid_rules * sizeof(struct ieee80211_reg_rule);
- copy_rd = kzalloc(regd_to_copy, GFP_KERNEL);
- if (!copy_rd) {
+ copy_rd = kmemdup(regd, regd_to_copy, GFP_KERNEL);
+ if (!copy_rd)
copy_rd = ERR_PTR(-ENOMEM);
- goto out;
- }
-
- memcpy(copy_rd, regd, regd_to_copy);
out:
kfree(regdb_ptrs);
--
2.7.4
^ permalink raw reply related
* Data entry service and data processing services
From: Linda @ 2019-01-26 8:53 UTC (permalink / raw)
To: netdev
We provide data entry service and data processing services.
We makes it easy for you to take the documents you have and turn them into
documents you can use.
If you have paper and image forms, directory listings, spreadsheets,
reports or any number of handwritten
or printed documents we can transcribe the required information using data
entry and other data capture
techniques into Excel, Access, or a text file database designed to meet the
specific needs of your business.
We can also enter information directly into your internet web site
application.
We provide complete data processing services including: data entry form
preparation, data form control,
manual data entry, automated data capture, data base production and
electronic data transmission
and delivery.
Our experienced data entry professionals are trained to capture data
efficiently and effectively.
So quit worrying about being understaffed during peak processing periods.
Let's start it today if you have needs.
Thanks,
Linda
^ permalink raw reply
* Re: [PATCH bpf-next v3 03/16] bpf: verifier support JMP32
From: Jiong Wang @ 2019-01-26 11:02 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Jiong Wang, ast, netdev, oss-drivers
In-Reply-To: <3e7a469a-8707-9d51-e1a9-0d57a489fcf7@iogearbox.net>
Daniel Borkmann writes:
> On 01/25/2019 01:10 AM, Jiong Wang wrote:
>> This patch teach verifier about the new BPF_JMP32 instruction class.
>> Verifier need to treat it similar as the existing BPF_JMP class.
>> A BPF_JMP32 insn needs to go through all checks that have been done on
>> BPF_JMP.
>>
>> Also, verifier is doing runtime optimizations based on the extra info
>> conditional jump instruction could offer, especially when the comparison is
>> between constant and register that the value range of the register could be
>> improved based on the comparison results. These code are updated
>> accordingly.
>>
>> Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>> Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
>
> Series looks good to me, but if I spot this correctly one thing that has
> not been addressed here is proper rebase on top of Jakub's dead code
> removal, e.g. in opt_hard_wire_dead_code_branches() where we check in
> insn_is_cond_jump() for jump opcodes it still only tests for BPF_JMP
> class whereas BPF_JMP32 handling needs to be taught here as well.
Thanks for catching this. Yes, insn_is_cond_jump() should be updated for
JMP32 as well. JMP32 is guaranteed to be with condition jump operation only
otherwise the earlier do_check will complain use of reserved encoding bits.
I am going to teach insn_is_cond_jump to return true for JMP32. And search
the commits, there is another similar new helper function in nfp driver
jit.
Will fix both places, and re-spin v4.
Thanks.
Regards,
Jiong
^ permalink raw reply
* Re: [RFC v4 00/19] batman-adv: netlink restructuring, part 2
From: Sven Eckelmann @ 2019-01-26 10:47 UTC (permalink / raw)
To: b.a.t.m.a.n; +Cc: Jiri Pirko, netdev, linus.luessing
In-Reply-To: <20190119155626.6414-1-sven@narfation.org>
[-- Attachment #1: Type: text/plain, Size: 4099 bytes --]
On Saturday, 19 January 2019 16.56.07 CET Sven Eckelmann wrote:
[...]
> There were also two topics which were not yet really discussed and thus
> these requests (from Linus) were not yet implemented:
@Jiri, @Linus maybe you can discuss these topics further and select the
correct solution.
> * convert BATADV_ATTR_MULTICAST_MODE_ENABLED to an u32 and let don't handle
> it like a boolean. Instead use it to select how multicast traffic has to
> be handled:
>
> - 0: ignore multicast optimization and just flood it like broadcast
> traffic
> - 1: enabled multicast optimization
> - 2: undefined but also some kind of multicast optimization
> - 3: undefined but also some kind of multicast of optimization
> - ...
Multicast mode is currently defined.
* according to batctl manpage:
multicast_mode|mm [0|1]
If no parameter is given the current multicast mode set‐
ting is displayed. Otherwise the parameter is used to en‐
able or disable multicast optimizations (i.e. disabling
means always sending own multicast frames via classic
flooding).
* according to sysfs ABI:
What: /sys/class/net/<mesh_iface>/mesh/multicast_mode
Date: Feb 2014
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Indicates whether multicast optimizations are enabled
or disabled. If set to zero then all nodes in the
mesh are going to use classic flooding for any
multicast packet with no optimizations.
Both define it as boolean value and therefore it was converted to a boolean
value (via u8) in netlink.
But Linus now suggested that it is actually an u32. Most likely 0 == to
something like BATADV_MULTICAST_MODE_FLOODING. But I have no idea what 1 is or
what 2, 3, 4, .. would be. So I need some input here.
And Jiri said that it should be renamed to BATADV_ATTR_MULTICAST_ENABLED -
which seems to suggest that he doesn't like the idea of a u32 for some reason
and prefers to use a boolean value.
And now Linus even said that it should be a bit field - which makes it even
more vague to me and I have now absolutely no idea what should be implemented.
* BIT 0 for flooding vs ?
* BIT 1 for ?
* ...
> * convert BATADV_ATTR_AGGREGATION_OGM_ENABLED to u32 and use it
> to mark which type of traffic should be aggregated:
>
> - bit 0: enable aggregation of OGM(2)s
> - bit 1: yet undefined packet type which allows some kind of aggregation
> - bit 2: yet undefined packet type which allows some kind of aggregation
> - ...
Aggregated OGM is currently defined as:
* according to batctl manpage:
aggregation|ag [0|1]
If no parameter is given the current aggregation setting
is displayed. Otherwise the parameter is used to enable or
disable OGM packet aggregation.
* according to sysfs ABI:
What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Indicates whether the batman protocol messages of the
mesh <mesh_iface> shall be aggregated or not.
So sysfs is only one possible backend for the batctl command. There is
currently nothing which I would assume to be aggregatable beside OGMs but let
us assume for now that there is now something and some way to aggregate things
beside OGMs in a save and backward compatible way. Let's call this FOO - so we
have BATADV_ATTR_AGGREGATION_OGM_ENABLED and
BATADV_ATTR_AGGREGATION_FOO_ENABLED. Or we have BATADV_ATTR_AGGREGATION as an
u32 and just use the second bit as marker for FOO (and of course the first bit
as marker for OGM).
Would it now be more preferable to use BATADV_ATTR_AGGREGATION_OGM_ENABLED as
u8 (boolean) or to to switch to BATADV_ATTR_AGGREGATION (u32) & assign single
bits to packet types.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net-next] Documentation: net: phy: switch documentation to rst format
From: Heiner Kallweit @ 2019-01-26 10:25 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
Switch phylib documentation to rst format.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
Documentation/networking/index.rst | 1 +
Documentation/networking/phy.rst | 447 +++++++++++++++++++++++++++++
Documentation/networking/phy.txt | 429 ---------------------------
3 files changed, 448 insertions(+), 429 deletions(-)
create mode 100644 Documentation/networking/phy.rst
delete mode 100644 Documentation/networking/phy.txt
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index 9c313958b..1266dc6d9 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -29,6 +29,7 @@ Contents:
msg_zerocopy
failover
net_failover
+ phy
alias
bridge
snmp_counter
diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst
new file mode 100644
index 000000000..37d10695f
--- /dev/null
+++ b/Documentation/networking/phy.rst
@@ -0,0 +1,447 @@
+=====================
+PHY Abstraction Layer
+=====================
+
+Purpose
+=======
+
+Most network devices consist of set of registers which provide an interface
+to a MAC layer, which communicates with the physical connection through a
+PHY. The PHY concerns itself with negotiating link parameters with the link
+partner on the other side of the network connection (typically, an ethernet
+cable), and provides a register interface to allow drivers to determine what
+settings were chosen, and to configure what settings are allowed.
+
+While these devices are distinct from the network devices, and conform to a
+standard layout for the registers, it has been common practice to integrate
+the PHY management code with the network driver. This has resulted in large
+amounts of redundant code. Also, on embedded systems with multiple (and
+sometimes quite different) ethernet controllers connected to the same
+management bus, it is difficult to ensure safe use of the bus.
+
+Since the PHYs are devices, and the management busses through which they are
+accessed are, in fact, busses, the PHY Abstraction Layer treats them as such.
+In doing so, it has these goals:
+
+#. Increase code-reuse
+#. Increase overall code-maintainability
+#. Speed development time for new network drivers, and for new systems
+
+Basically, this layer is meant to provide an interface to PHY devices which
+allows network driver writers to write as little code as possible, while
+still providing a full feature set.
+
+The MDIO bus
+============
+
+Most network devices are connected to a PHY by means of a management bus.
+Different devices use different busses (though some share common interfaces).
+In order to take advantage of the PAL, each bus interface needs to be
+registered as a distinct device.
+
+#. read and write functions must be implemented. Their prototypes are::
+
+ int write(struct mii_bus *bus, int mii_id, int regnum, u16 value);
+ int read(struct mii_bus *bus, int mii_id, int regnum);
+
+ mii_id is the address on the bus for the PHY, and regnum is the register
+ number. These functions are guaranteed not to be called from interrupt
+ time, so it is safe for them to block, waiting for an interrupt to signal
+ the operation is complete
+
+#. A reset function is optional. This is used to return the bus to an
+ initialized state.
+
+#. A probe function is needed. This function should set up anything the bus
+ driver needs, setup the mii_bus structure, and register with the PAL using
+ mdiobus_register. Similarly, there's a remove function to undo all of
+ that (use mdiobus_unregister).
+
+#. Like any driver, the device_driver structure must be configured, and init
+ exit functions are used to register the driver.
+
+#. The bus must also be declared somewhere as a device, and registered.
+
+As an example for how one driver implemented an mdio bus driver, see
+drivers/net/ethernet/freescale/fsl_pq_mdio.c and an associated DTS file
+for one of the users. (e.g. "git grep fsl,.*-mdio arch/powerpc/boot/dts/")
+
+(RG)MII/electrical interface considerations
+===========================================
+
+The Reduced Gigabit Medium Independent Interface (RGMII) is a 12-pin
+electrical signal interface using a synchronous 125Mhz clock signal and several
+data lines. Due to this design decision, a 1.5ns to 2ns delay must be added
+between the clock line (RXC or TXC) and the data lines to let the PHY (clock
+sink) have enough setup and hold times to sample the data lines correctly. The
+PHY library offers different types of PHY_INTERFACE_MODE_RGMII* values to let
+the PHY driver and optionally the MAC driver, implement the required delay. The
+values of phy_interface_t must be understood from the perspective of the PHY
+device itself, leading to the following:
+
+* PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any
+ internal delay by itself, it assumes that either the Ethernet MAC (if capable
+ or the PCB traces) insert the correct 1.5-2ns delay
+
+* PHY_INTERFACE_MODE_RGMII_TXID: the PHY should insert an internal delay
+ for the transmit data lines (TXD[3:0]) processed by the PHY device
+
+* PHY_INTERFACE_MODE_RGMII_RXID: the PHY should insert an internal delay
+ for the receive data lines (RXD[3:0]) processed by the PHY device
+
+* PHY_INTERFACE_MODE_RGMII_ID: the PHY should insert internal delays for
+ both transmit AND receive data lines from/to the PHY device
+
+Whenever possible, use the PHY side RGMII delay for these reasons:
+
+* PHY devices may offer sub-nanosecond granularity in how they allow a
+ receiver/transmitter side delay (e.g: 0.5, 1.0, 1.5ns) to be specified. Such
+ precision may be required to account for differences in PCB trace lengths
+
+* PHY devices are typically qualified for a large range of applications
+ (industrial, medical, automotive...), and they provide a constant and
+ reliable delay across temperature/pressure/voltage ranges
+
+* PHY device drivers in PHYLIB being reusable by nature, being able to
+ configure correctly a specified delay enables more designs with similar delay
+ requirements to be operate correctly
+
+For cases where the PHY is not capable of providing this delay, but the
+Ethernet MAC driver is capable of doing so, the correct phy_interface_t value
+should be PHY_INTERFACE_MODE_RGMII, and the Ethernet MAC driver should be
+configured correctly in order to provide the required transmit and/or receive
+side delay from the perspective of the PHY device. Conversely, if the Ethernet
+MAC driver looks at the phy_interface_t value, for any other mode but
+PHY_INTERFACE_MODE_RGMII, it should make sure that the MAC-level delays are
+disabled.
+
+In case neither the Ethernet MAC, nor the PHY are capable of providing the
+required delays, as defined per the RGMII standard, several options may be
+available:
+
+* Some SoCs may offer a pin pad/mux/controller capable of configuring a given
+ set of pins'strength, delays, and voltage; and it may be a suitable
+ option to insert the expected 2ns RGMII delay.
+
+* Modifying the PCB design to include a fixed delay (e.g: using a specifically
+ designed serpentine), which may not require software configuration at all.
+
+Common problems with RGMII delay mismatch
+-----------------------------------------
+
+When there is a RGMII delay mismatch between the Ethernet MAC and the PHY, this
+will most likely result in the clock and data line signals to be unstable when
+the PHY or MAC take a snapshot of these signals to translate them into logical
+1 or 0 states and reconstruct the data being transmitted/received. Typical
+symptoms include:
+
+* Transmission/reception partially works, and there is frequent or occasional
+ packet loss observed
+
+* Ethernet MAC may report some or all packets ingressing with a FCS/CRC error,
+ or just discard them all
+
+* Switching to lower speeds such as 10/100Mbits/sec makes the problem go away
+ (since there is enough setup/hold time in that case)
+
+Connecting to a PHY
+===================
+
+Sometime during startup, the network driver needs to establish a connection
+between the PHY device, and the network device. At this time, the PHY's bus
+and drivers need to all have been loaded, so it is ready for the connection.
+At this point, there are several ways to connect to the PHY:
+
+#. The PAL handles everything, and only calls the network driver when
+ the link state changes, so it can react.
+
+#. The PAL handles everything except interrupts (usually because the
+ controller has the interrupt registers).
+
+#. The PAL handles everything, but checks in with the driver every second,
+ allowing the network driver to react first to any changes before the PAL
+ does.
+
+#. The PAL serves only as a library of functions, with the network device
+ manually calling functions to update status, and configure the PHY
+
+
+Letting the PHY Abstraction Layer do Everything
+===============================================
+
+If you choose option 1 (The hope is that every driver can, but to still be
+useful to drivers that can't), connecting to the PHY is simple:
+
+First, you need a function to react to changes in the link state. This
+function follows this protocol::
+
+ static void adjust_link(struct net_device *dev);
+
+Next, you need to know the device name of the PHY connected to this device.
+The name will look something like, "0:00", where the first number is the
+bus id, and the second is the PHY's address on that bus. Typically,
+the bus is responsible for making its ID unique.
+
+Now, to connect, just call this function::
+
+ phydev = phy_connect(dev, phy_name, &adjust_link, interface);
+
+*phydev* is a pointer to the phy_device structure which represents the PHY.
+If phy_connect is successful, it will return the pointer. dev, here, is the
+pointer to your net_device. Once done, this function will have started the
+PHY's software state machine, and registered for the PHY's interrupt, if it
+has one. The phydev structure will be populated with information about the
+current state, though the PHY will not yet be truly operational at this
+point.
+
+PHY-specific flags should be set in phydev->dev_flags prior to the call
+to phy_connect() such that the underlying PHY driver can check for flags
+and perform specific operations based on them.
+This is useful if the system has put hardware restrictions on
+the PHY/controller, of which the PHY needs to be aware.
+
+*interface* is a u32 which specifies the connection type used
+between the controller and the PHY. Examples are GMII, MII,
+RGMII, and SGMII. For a full list, see include/linux/phy.h
+
+Now just make sure that phydev->supported and phydev->advertising have any
+values pruned from them which don't make sense for your controller (a 10/100
+controller may be connected to a gigabit capable PHY, so you would need to
+mask off SUPPORTED_1000baseT*). See include/linux/ethtool.h for definitions
+for these bitfields. Note that you should not SET any bits, except the
+SUPPORTED_Pause and SUPPORTED_AsymPause bits (see below), or the PHY may get
+put into an unsupported state.
+
+Lastly, once the controller is ready to handle network traffic, you call
+phy_start(phydev). This tells the PAL that you are ready, and configures the
+PHY to connect to the network. If the MAC interrupt of your network driver
+also handles PHY status changes, just set phydev->irq to PHY_IGNORE_INTERRUPT
+before you call phy_start and use phy_mac_interrupt() from the network
+driver. If you don't want to use interrupts, set phydev->irq to PHY_POLL.
+phy_start() enables the PHY interrupts (if applicable) and starts the
+phylib state machine.
+
+When you want to disconnect from the network (even if just briefly), you call
+phy_stop(phydev). This function also stops the phylib state machine and
+disables PHY interrupts.
+
+Pause frames / flow control
+===========================
+
+The PHY does not participate directly in flow control/pause frames except by
+making sure that the SUPPORTED_Pause and SUPPORTED_AsymPause bits are set in
+MII_ADVERTISE to indicate towards the link partner that the Ethernet MAC
+controller supports such a thing. Since flow control/pause frames generation
+involves the Ethernet MAC driver, it is recommended that this driver takes care
+of properly indicating advertisement and support for such features by setting
+the SUPPORTED_Pause and SUPPORTED_AsymPause bits accordingly. This can be done
+either before or after phy_connect() and/or as a result of implementing the
+ethtool::set_pauseparam feature.
+
+
+Keeping Close Tabs on the PAL
+=============================
+
+It is possible that the PAL's built-in state machine needs a little help to
+keep your network device and the PHY properly in sync. If so, you can
+register a helper function when connecting to the PHY, which will be called
+every second before the state machine reacts to any changes. To do this, you
+need to manually call phy_attach() and phy_prepare_link(), and then call
+phy_start_machine() with the second argument set to point to your special
+handler.
+
+Currently there are no examples of how to use this functionality, and testing
+on it has been limited because the author does not have any drivers which use
+it (they all use option 1). So Caveat Emptor.
+
+Doing it all yourself
+=====================
+
+There's a remote chance that the PAL's built-in state machine cannot track
+the complex interactions between the PHY and your network device. If this is
+so, you can simply call phy_attach(), and not call phy_start_machine or
+phy_prepare_link(). This will mean that phydev->state is entirely yours to
+handle (phy_start and phy_stop toggle between some of the states, so you
+might need to avoid them).
+
+An effort has been made to make sure that useful functionality can be
+accessed without the state-machine running, and most of these functions are
+descended from functions which did not interact with a complex state-machine.
+However, again, no effort has been made so far to test running without the
+state machine, so tryer beware.
+
+Here is a brief rundown of the functions::
+
+ int phy_read(struct phy_device *phydev, u16 regnum);
+ int phy_write(struct phy_device *phydev, u16 regnum, u16 val);
+
+Simple read/write primitives. They invoke the bus's read/write function
+pointers.
+::
+
+ void phy_print_status(struct phy_device *phydev);
+
+A convenience function to print out the PHY status neatly.
+::
+
+ void phy_request_interrupt(struct phy_device *phydev);
+
+Requests the IRQ for the PHY interrupts.
+::
+
+ struct phy_device * phy_attach(struct net_device *dev, const char *phy_id,
+ phy_interface_t interface);
+
+Attaches a network device to a particular PHY, binding the PHY to a generic
+driver if none was found during bus initialization.
+::
+
+ int phy_start_aneg(struct phy_device *phydev);
+
+Using variables inside the phydev structure, either configures advertising
+and resets autonegotiation, or disables autonegotiation, and configures
+forced settings.
+::
+
+ static inline int phy_read_status(struct phy_device *phydev);
+
+Fills the phydev structure with up-to-date information about the current
+settings in the PHY.
+::
+
+ int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);
+
+Ethtool convenience functions.
+::
+
+ int phy_mii_ioctl(struct phy_device *phydev,
+ struct mii_ioctl_data *mii_data, int cmd);
+
+The MII ioctl. Note that this function will completely screw up the state
+machine if you write registers like BMCR, BMSR, ADVERTISE, etc. Best to
+use this only to write registers which are not standard, and don't set off
+a renegotiation.
+
+PHY Device Drivers
+==================
+
+With the PHY Abstraction Layer, adding support for new PHYs is
+quite easy. In some cases, no work is required at all! However,
+many PHYs require a little hand-holding to get up-and-running.
+
+Generic PHY driver
+------------------
+
+If the desired PHY doesn't have any errata, quirks, or special
+features you want to support, then it may be best to not add
+support, and let the PHY Abstraction Layer's Generic PHY Driver
+do all of the work.
+
+Writing a PHY driver
+--------------------
+
+If you do need to write a PHY driver, the first thing to do is
+make sure it can be matched with an appropriate PHY device.
+This is done during bus initialization by reading the device's
+UID (stored in registers 2 and 3), then comparing it to each
+driver's phy_id field by ANDing it with each driver's
+phy_id_mask field. Also, it needs a name. Here's an example::
+
+ static struct phy_driver dm9161_driver = {
+ .phy_id = 0x0181b880,
+ .name = "Davicom DM9161E",
+ .phy_id_mask = 0x0ffffff0,
+ ...
+ }
+
+Next, you need to specify what features (speed, duplex, autoneg,
+etc) your PHY device and driver support. Most PHYs support
+PHY_BASIC_FEATURES, but you can look in include/mii.h for other
+features.
+
+Each driver consists of a number of function pointers, documented
+in include/linux/phy.h under the phy_driver structure.
+
+Of these, only config_aneg and read_status are required to be
+assigned by the driver code. The rest are optional. Also, it is
+preferred to use the generic phy driver's versions of these two
+functions if at all possible: genphy_read_status and
+genphy_config_aneg. If this is not possible, it is likely that
+you only need to perform some actions before and after invoking
+these functions, and so your functions will wrap the generic
+ones.
+
+Feel free to look at the Marvell, Cicada, and Davicom drivers in
+drivers/net/phy/ for examples (the lxt and qsemi drivers have
+not been tested as of this writing).
+
+The PHY's MMD register accesses are handled by the PAL framework
+by default, but can be overridden by a specific PHY driver if
+required. This could be the case if a PHY was released for
+manufacturing before the MMD PHY register definitions were
+standardized by the IEEE. Most modern PHYs will be able to use
+the generic PAL framework for accessing the PHY's MMD registers.
+An example of such usage is for Energy Efficient Ethernet support,
+implemented in the PAL. This support uses the PAL to access MMD
+registers for EEE query and configuration if the PHY supports
+the IEEE standard access mechanisms, or can use the PHY's specific
+access interfaces if overridden by the specific PHY driver. See
+the Micrel driver in drivers/net/phy/ for an example of how this
+can be implemented.
+
+Board Fixups
+============
+
+Sometimes the specific interaction between the platform and the PHY requires
+special handling. For instance, to change where the PHY's clock input is,
+or to add a delay to account for latency issues in the data path. In order
+to support such contingencies, the PHY Layer allows platform code to register
+fixups to be run when the PHY is brought up (or subsequently reset).
+
+When the PHY Layer brings up a PHY it checks to see if there are any fixups
+registered for it, matching based on UID (contained in the PHY device's phy_id
+field) and the bus identifier (contained in phydev->dev.bus_id). Both must
+match, however two constants, PHY_ANY_ID and PHY_ANY_UID, are provided as
+wildcards for the bus ID and UID, respectively.
+
+When a match is found, the PHY layer will invoke the run function associated
+with the fixup. This function is passed a pointer to the phy_device of
+interest. It should therefore only operate on that PHY.
+
+The platform code can either register the fixup using phy_register_fixup()::
+
+ int phy_register_fixup(const char *phy_id,
+ u32 phy_uid, u32 phy_uid_mask,
+ int (*run)(struct phy_device *));
+
+Or using one of the two stubs, phy_register_fixup_for_uid() and
+phy_register_fixup_for_id()::
+
+ int phy_register_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask,
+ int (*run)(struct phy_device *));
+ int phy_register_fixup_for_id(const char *phy_id,
+ int (*run)(struct phy_device *));
+
+The stubs set one of the two matching criteria, and set the other one to
+match anything.
+
+When phy_register_fixup() or \*_for_uid()/\*_for_id() is called at module,
+unregister fixup and free allocate memory are required.
+
+Call one of following function before unloading module::
+
+ int phy_unregister_fixup(const char *phy_id, u32 phy_uid, u32 phy_uid_mask);
+ int phy_unregister_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask);
+ int phy_register_fixup_for_id(const char *phy_id);
+
+Standards
+=========
+
+IEEE Standard 802.3: CSMA/CD Access Method and Physical Layer Specifications, Section Two:
+http://standards.ieee.org/getieee802/download/802.3-2008_section2.pdf
+
+RGMII v1.3:
+http://web.archive.org/web/20160303212629/http://www.hp.com/rnd/pdfs/RGMIIv1_3.pdf
+
+RGMII v2.0:
+http://web.archive.org/web/20160303171328/http://www.hp.com/rnd/pdfs/RGMIIv2_0_final_hp.pdf
diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt
deleted file mode 100644
index 7ecba4fd6..000000000
--- a/Documentation/networking/phy.txt
+++ /dev/null
@@ -1,429 +0,0 @@
-
--------
-PHY Abstraction Layer
-(Updated 2008-04-08)
-
-Purpose
-
- Most network devices consist of set of registers which provide an interface
- to a MAC layer, which communicates with the physical connection through a
- PHY. The PHY concerns itself with negotiating link parameters with the link
- partner on the other side of the network connection (typically, an ethernet
- cable), and provides a register interface to allow drivers to determine what
- settings were chosen, and to configure what settings are allowed.
-
- While these devices are distinct from the network devices, and conform to a
- standard layout for the registers, it has been common practice to integrate
- the PHY management code with the network driver. This has resulted in large
- amounts of redundant code. Also, on embedded systems with multiple (and
- sometimes quite different) ethernet controllers connected to the same
- management bus, it is difficult to ensure safe use of the bus.
-
- Since the PHYs are devices, and the management busses through which they are
- accessed are, in fact, busses, the PHY Abstraction Layer treats them as such.
- In doing so, it has these goals:
-
- 1) Increase code-reuse
- 2) Increase overall code-maintainability
- 3) Speed development time for new network drivers, and for new systems
-
- Basically, this layer is meant to provide an interface to PHY devices which
- allows network driver writers to write as little code as possible, while
- still providing a full feature set.
-
-The MDIO bus
-
- Most network devices are connected to a PHY by means of a management bus.
- Different devices use different busses (though some share common interfaces).
- In order to take advantage of the PAL, each bus interface needs to be
- registered as a distinct device.
-
- 1) read and write functions must be implemented. Their prototypes are:
-
- int write(struct mii_bus *bus, int mii_id, int regnum, u16 value);
- int read(struct mii_bus *bus, int mii_id, int regnum);
-
- mii_id is the address on the bus for the PHY, and regnum is the register
- number. These functions are guaranteed not to be called from interrupt
- time, so it is safe for them to block, waiting for an interrupt to signal
- the operation is complete
-
- 2) A reset function is optional. This is used to return the bus to an
- initialized state.
-
- 3) A probe function is needed. This function should set up anything the bus
- driver needs, setup the mii_bus structure, and register with the PAL using
- mdiobus_register. Similarly, there's a remove function to undo all of
- that (use mdiobus_unregister).
-
- 4) Like any driver, the device_driver structure must be configured, and init
- exit functions are used to register the driver.
-
- 5) The bus must also be declared somewhere as a device, and registered.
-
- As an example for how one driver implemented an mdio bus driver, see
- drivers/net/ethernet/freescale/fsl_pq_mdio.c and an associated DTS file
- for one of the users. (e.g. "git grep fsl,.*-mdio arch/powerpc/boot/dts/")
-
-(RG)MII/electrical interface considerations
-
- The Reduced Gigabit Medium Independent Interface (RGMII) is a 12-pin
- electrical signal interface using a synchronous 125Mhz clock signal and several
- data lines. Due to this design decision, a 1.5ns to 2ns delay must be added
- between the clock line (RXC or TXC) and the data lines to let the PHY (clock
- sink) have enough setup and hold times to sample the data lines correctly. The
- PHY library offers different types of PHY_INTERFACE_MODE_RGMII* values to let
- the PHY driver and optionally the MAC driver, implement the required delay. The
- values of phy_interface_t must be understood from the perspective of the PHY
- device itself, leading to the following:
-
- * PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any
- internal delay by itself, it assumes that either the Ethernet MAC (if capable
- or the PCB traces) insert the correct 1.5-2ns delay
-
- * PHY_INTERFACE_MODE_RGMII_TXID: the PHY should insert an internal delay
- for the transmit data lines (TXD[3:0]) processed by the PHY device
-
- * PHY_INTERFACE_MODE_RGMII_RXID: the PHY should insert an internal delay
- for the receive data lines (RXD[3:0]) processed by the PHY device
-
- * PHY_INTERFACE_MODE_RGMII_ID: the PHY should insert internal delays for
- both transmit AND receive data lines from/to the PHY device
-
- Whenever possible, use the PHY side RGMII delay for these reasons:
-
- * PHY devices may offer sub-nanosecond granularity in how they allow a
- receiver/transmitter side delay (e.g: 0.5, 1.0, 1.5ns) to be specified. Such
- precision may be required to account for differences in PCB trace lengths
-
- * PHY devices are typically qualified for a large range of applications
- (industrial, medical, automotive...), and they provide a constant and
- reliable delay across temperature/pressure/voltage ranges
-
- * PHY device drivers in PHYLIB being reusable by nature, being able to
- configure correctly a specified delay enables more designs with similar delay
- requirements to be operate correctly
-
- For cases where the PHY is not capable of providing this delay, but the
- Ethernet MAC driver is capable of doing so, the correct phy_interface_t value
- should be PHY_INTERFACE_MODE_RGMII, and the Ethernet MAC driver should be
- configured correctly in order to provide the required transmit and/or receive
- side delay from the perspective of the PHY device. Conversely, if the Ethernet
- MAC driver looks at the phy_interface_t value, for any other mode but
- PHY_INTERFACE_MODE_RGMII, it should make sure that the MAC-level delays are
- disabled.
-
- In case neither the Ethernet MAC, nor the PHY are capable of providing the
- required delays, as defined per the RGMII standard, several options may be
- available:
-
- * Some SoCs may offer a pin pad/mux/controller capable of configuring a given
- set of pins'strength, delays, and voltage; and it may be a suitable
- option to insert the expected 2ns RGMII delay.
-
- * Modifying the PCB design to include a fixed delay (e.g: using a specifically
- designed serpentine), which may not require software configuration at all.
-
-Common problems with RGMII delay mismatch
-
- When there is a RGMII delay mismatch between the Ethernet MAC and the PHY, this
- will most likely result in the clock and data line signals to be unstable when
- the PHY or MAC take a snapshot of these signals to translate them into logical
- 1 or 0 states and reconstruct the data being transmitted/received. Typical
- symptoms include:
-
- * Transmission/reception partially works, and there is frequent or occasional
- packet loss observed
-
- * Ethernet MAC may report some or all packets ingressing with a FCS/CRC error,
- or just discard them all
-
- * Switching to lower speeds such as 10/100Mbits/sec makes the problem go away
- (since there is enough setup/hold time in that case)
-
-
-Connecting to a PHY
-
- Sometime during startup, the network driver needs to establish a connection
- between the PHY device, and the network device. At this time, the PHY's bus
- and drivers need to all have been loaded, so it is ready for the connection.
- At this point, there are several ways to connect to the PHY:
-
- 1) The PAL handles everything, and only calls the network driver when
- the link state changes, so it can react.
-
- 2) The PAL handles everything except interrupts (usually because the
- controller has the interrupt registers).
-
- 3) The PAL handles everything, but checks in with the driver every second,
- allowing the network driver to react first to any changes before the PAL
- does.
-
- 4) The PAL serves only as a library of functions, with the network device
- manually calling functions to update status, and configure the PHY
-
-
-Letting the PHY Abstraction Layer do Everything
-
- If you choose option 1 (The hope is that every driver can, but to still be
- useful to drivers that can't), connecting to the PHY is simple:
-
- First, you need a function to react to changes in the link state. This
- function follows this protocol:
-
- static void adjust_link(struct net_device *dev);
-
- Next, you need to know the device name of the PHY connected to this device.
- The name will look something like, "0:00", where the first number is the
- bus id, and the second is the PHY's address on that bus. Typically,
- the bus is responsible for making its ID unique.
-
- Now, to connect, just call this function:
-
- phydev = phy_connect(dev, phy_name, &adjust_link, interface);
-
- phydev is a pointer to the phy_device structure which represents the PHY. If
- phy_connect is successful, it will return the pointer. dev, here, is the
- pointer to your net_device. Once done, this function will have started the
- PHY's software state machine, and registered for the PHY's interrupt, if it
- has one. The phydev structure will be populated with information about the
- current state, though the PHY will not yet be truly operational at this
- point.
-
- PHY-specific flags should be set in phydev->dev_flags prior to the call
- to phy_connect() such that the underlying PHY driver can check for flags
- and perform specific operations based on them.
- This is useful if the system has put hardware restrictions on
- the PHY/controller, of which the PHY needs to be aware.
-
- interface is a u32 which specifies the connection type used
- between the controller and the PHY. Examples are GMII, MII,
- RGMII, and SGMII. For a full list, see include/linux/phy.h
-
- Now just make sure that phydev->supported and phydev->advertising have any
- values pruned from them which don't make sense for your controller (a 10/100
- controller may be connected to a gigabit capable PHY, so you would need to
- mask off SUPPORTED_1000baseT*). See include/linux/ethtool.h for definitions
- for these bitfields. Note that you should not SET any bits, except the
- SUPPORTED_Pause and SUPPORTED_AsymPause bits (see below), or the PHY may get
- put into an unsupported state.
-
- Lastly, once the controller is ready to handle network traffic, you call
- phy_start(phydev). This tells the PAL that you are ready, and configures the
- PHY to connect to the network. If the MAC interrupt of your network driver
- also handles PHY status changes, just set phydev->irq to PHY_IGNORE_INTERRUPT
- before you call phy_start and use phy_mac_interrupt() from the network
- driver. If you don't want to use interrupts, set phydev->irq to PHY_POLL.
- phy_start() enables the PHY interrupts (if applicable) and starts the
- phylib state machine.
-
- When you want to disconnect from the network (even if just briefly), you call
- phy_stop(phydev). This function also stops the phylib state machine and
- disables PHY interrupts.
-
-Pause frames / flow control
-
- The PHY does not participate directly in flow control/pause frames except by
- making sure that the SUPPORTED_Pause and SUPPORTED_AsymPause bits are set in
- MII_ADVERTISE to indicate towards the link partner that the Ethernet MAC
- controller supports such a thing. Since flow control/pause frames generation
- involves the Ethernet MAC driver, it is recommended that this driver takes care
- of properly indicating advertisement and support for such features by setting
- the SUPPORTED_Pause and SUPPORTED_AsymPause bits accordingly. This can be done
- either before or after phy_connect() and/or as a result of implementing the
- ethtool::set_pauseparam feature.
-
-
-Keeping Close Tabs on the PAL
-
- It is possible that the PAL's built-in state machine needs a little help to
- keep your network device and the PHY properly in sync. If so, you can
- register a helper function when connecting to the PHY, which will be called
- every second before the state machine reacts to any changes. To do this, you
- need to manually call phy_attach() and phy_prepare_link(), and then call
- phy_start_machine() with the second argument set to point to your special
- handler.
-
- Currently there are no examples of how to use this functionality, and testing
- on it has been limited because the author does not have any drivers which use
- it (they all use option 1). So Caveat Emptor.
-
-Doing it all yourself
-
- There's a remote chance that the PAL's built-in state machine cannot track
- the complex interactions between the PHY and your network device. If this is
- so, you can simply call phy_attach(), and not call phy_start_machine or
- phy_prepare_link(). This will mean that phydev->state is entirely yours to
- handle (phy_start and phy_stop toggle between some of the states, so you
- might need to avoid them).
-
- An effort has been made to make sure that useful functionality can be
- accessed without the state-machine running, and most of these functions are
- descended from functions which did not interact with a complex state-machine.
- However, again, no effort has been made so far to test running without the
- state machine, so tryer beware.
-
- Here is a brief rundown of the functions:
-
- int phy_read(struct phy_device *phydev, u16 regnum);
- int phy_write(struct phy_device *phydev, u16 regnum, u16 val);
-
- Simple read/write primitives. They invoke the bus's read/write function
- pointers.
-
- void phy_print_status(struct phy_device *phydev);
-
- A convenience function to print out the PHY status neatly.
-
- void phy_request_interrupt(struct phy_device *phydev);
-
- Requests the IRQ for the PHY interrupts.
-
- struct phy_device * phy_attach(struct net_device *dev, const char *phy_id,
- phy_interface_t interface);
-
- Attaches a network device to a particular PHY, binding the PHY to a generic
- driver if none was found during bus initialization.
-
- int phy_start_aneg(struct phy_device *phydev);
-
- Using variables inside the phydev structure, either configures advertising
- and resets autonegotiation, or disables autonegotiation, and configures
- forced settings.
-
- static inline int phy_read_status(struct phy_device *phydev);
-
- Fills the phydev structure with up-to-date information about the current
- settings in the PHY.
-
- int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);
-
- Ethtool convenience functions.
-
- int phy_mii_ioctl(struct phy_device *phydev,
- struct mii_ioctl_data *mii_data, int cmd);
-
- The MII ioctl. Note that this function will completely screw up the state
- machine if you write registers like BMCR, BMSR, ADVERTISE, etc. Best to
- use this only to write registers which are not standard, and don't set off
- a renegotiation.
-
-
-PHY Device Drivers
-
- With the PHY Abstraction Layer, adding support for new PHYs is
- quite easy. In some cases, no work is required at all! However,
- many PHYs require a little hand-holding to get up-and-running.
-
-Generic PHY driver
-
- If the desired PHY doesn't have any errata, quirks, or special
- features you want to support, then it may be best to not add
- support, and let the PHY Abstraction Layer's Generic PHY Driver
- do all of the work.
-
-Writing a PHY driver
-
- If you do need to write a PHY driver, the first thing to do is
- make sure it can be matched with an appropriate PHY device.
- This is done during bus initialization by reading the device's
- UID (stored in registers 2 and 3), then comparing it to each
- driver's phy_id field by ANDing it with each driver's
- phy_id_mask field. Also, it needs a name. Here's an example:
-
- static struct phy_driver dm9161_driver = {
- .phy_id = 0x0181b880,
- .name = "Davicom DM9161E",
- .phy_id_mask = 0x0ffffff0,
- ...
- }
-
- Next, you need to specify what features (speed, duplex, autoneg,
- etc) your PHY device and driver support. Most PHYs support
- PHY_BASIC_FEATURES, but you can look in include/mii.h for other
- features.
-
- Each driver consists of a number of function pointers, documented
- in include/linux/phy.h under the phy_driver structure.
-
- Of these, only config_aneg and read_status are required to be
- assigned by the driver code. The rest are optional. Also, it is
- preferred to use the generic phy driver's versions of these two
- functions if at all possible: genphy_read_status and
- genphy_config_aneg. If this is not possible, it is likely that
- you only need to perform some actions before and after invoking
- these functions, and so your functions will wrap the generic
- ones.
-
- Feel free to look at the Marvell, Cicada, and Davicom drivers in
- drivers/net/phy/ for examples (the lxt and qsemi drivers have
- not been tested as of this writing).
-
- The PHY's MMD register accesses are handled by the PAL framework
- by default, but can be overridden by a specific PHY driver if
- required. This could be the case if a PHY was released for
- manufacturing before the MMD PHY register definitions were
- standardized by the IEEE. Most modern PHYs will be able to use
- the generic PAL framework for accessing the PHY's MMD registers.
- An example of such usage is for Energy Efficient Ethernet support,
- implemented in the PAL. This support uses the PAL to access MMD
- registers for EEE query and configuration if the PHY supports
- the IEEE standard access mechanisms, or can use the PHY's specific
- access interfaces if overridden by the specific PHY driver. See
- the Micrel driver in drivers/net/phy/ for an example of how this
- can be implemented.
-
-Board Fixups
-
- Sometimes the specific interaction between the platform and the PHY requires
- special handling. For instance, to change where the PHY's clock input is,
- or to add a delay to account for latency issues in the data path. In order
- to support such contingencies, the PHY Layer allows platform code to register
- fixups to be run when the PHY is brought up (or subsequently reset).
-
- When the PHY Layer brings up a PHY it checks to see if there are any fixups
- registered for it, matching based on UID (contained in the PHY device's phy_id
- field) and the bus identifier (contained in phydev->dev.bus_id). Both must
- match, however two constants, PHY_ANY_ID and PHY_ANY_UID, are provided as
- wildcards for the bus ID and UID, respectively.
-
- When a match is found, the PHY layer will invoke the run function associated
- with the fixup. This function is passed a pointer to the phy_device of
- interest. It should therefore only operate on that PHY.
-
- The platform code can either register the fixup using phy_register_fixup():
-
- int phy_register_fixup(const char *phy_id,
- u32 phy_uid, u32 phy_uid_mask,
- int (*run)(struct phy_device *));
-
- Or using one of the two stubs, phy_register_fixup_for_uid() and
- phy_register_fixup_for_id():
-
- int phy_register_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask,
- int (*run)(struct phy_device *));
- int phy_register_fixup_for_id(const char *phy_id,
- int (*run)(struct phy_device *));
-
- The stubs set one of the two matching criteria, and set the other one to
- match anything.
-
- When phy_register_fixup() or *_for_uid()/*_for_id() is called at module,
- unregister fixup and free allocate memory are required.
-
- Call one of following function before unloading module.
-
- int phy_unregister_fixup(const char *phy_id, u32 phy_uid, u32 phy_uid_mask);
- int phy_unregister_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask);
- int phy_register_fixup_for_id(const char *phy_id);
-
-Standards
-
- IEEE Standard 802.3: CSMA/CD Access Method and Physical Layer Specifications, Section Two:
- http://standards.ieee.org/getieee802/download/802.3-2008_section2.pdf
-
- RGMII v1.3:
- http://web.archive.org/web/20160303212629/http://www.hp.com/rnd/pdfs/RGMIIv1_3.pdf
-
- RGMII v2.0:
- http://web.archive.org/web/20160303171328/http://www.hp.com/rnd/pdfs/RGMIIv2_0_final_hp.pdf
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 2/2] r8169: enable EEE per default on RTL8168f
From: Heiner Kallweit @ 2019-01-26 9:36 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <55d17caf-5ff9-e888-b1af-dacc195b0eae@gmail.com>
Enable EEE per default on RTL8168f.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 35 ++--------------------------
1 file changed, 2 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 4572de170..3e650bd9e 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3388,23 +3388,7 @@ static void rtl8168e_2_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x1f, 0x0000);
rtl8168f_config_eee_phy(tp);
-
- /* EEE setting */
- rtl_w0w1_eri(tp, 0x1b0, ERIAR_MASK_1111, 0x0003, 0x0000, ERIAR_EXGMAC);
- rtl_writephy(tp, 0x1f, 0x0005);
- rtl_writephy(tp, 0x05, 0x8b85);
- rtl_w0w1_phy(tp, 0x06, 0x2000, 0x0000);
- rtl_writephy(tp, 0x1f, 0x0004);
- rtl_writephy(tp, 0x1f, 0x0007);
- rtl_writephy(tp, 0x1e, 0x0020);
- rtl_w0w1_phy(tp, 0x15, 0x0100, 0x0000);
- rtl_writephy(tp, 0x1f, 0x0002);
- rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, 0x0d, 0x0007);
- rtl_writephy(tp, 0x0e, 0x003c);
- rtl_writephy(tp, 0x0d, 0x4007);
- rtl_writephy(tp, 0x0e, 0x0006);
- rtl_writephy(tp, 0x0d, 0x0000);
+ rtl_enable_eee(tp);
/* Green feature */
rtl_writephy(tp, 0x1f, 0x0003);
@@ -3441,6 +3425,7 @@ static void rtl8168f_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x1f, 0x0000);
rtl8168f_config_eee_phy(tp);
+ rtl_enable_eee(tp);
}
static void rtl8168f_1_hw_phy_config(struct rtl8169_private *tp)
@@ -3574,22 +3559,6 @@ static void rtl8411_hw_phy_config(struct rtl8169_private *tp)
rtl_w0w1_phy(tp, 0x06, 0x8000, 0x0000);
rtl_writephy(tp, 0x1f, 0x0000);
- /* eee setting */
- rtl_w0w1_eri(tp, 0x1b0, ERIAR_MASK_0001, 0x00, 0x03, ERIAR_EXGMAC);
- rtl_writephy(tp, 0x1f, 0x0005);
- rtl_writephy(tp, 0x05, 0x8b85);
- rtl_w0w1_phy(tp, 0x06, 0x0000, 0x2000);
- rtl_writephy(tp, 0x1f, 0x0004);
- rtl_writephy(tp, 0x1f, 0x0007);
- rtl_writephy(tp, 0x1e, 0x0020);
- rtl_w0w1_phy(tp, 0x15, 0x0000, 0x0100);
- rtl_writephy(tp, 0x1f, 0x0000);
- rtl_writephy(tp, 0x0d, 0x0007);
- rtl_writephy(tp, 0x0e, 0x003c);
- rtl_writephy(tp, 0x0d, 0x4007);
- rtl_writephy(tp, 0x0e, 0x0000);
- rtl_writephy(tp, 0x0d, 0x0000);
-
/* Green feature */
rtl_writephy(tp, 0x1f, 0x0003);
rtl_w0w1_phy(tp, 0x19, 0x0000, 0x0001);
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 1/2] r8169: add EEE support for RTL8168f
From: Heiner Kallweit @ 2019-01-26 9:35 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <55d17caf-5ff9-e888-b1af-dacc195b0eae@gmail.com>
Add EEE support for RTL8168f to the recently added EEE handling
framework in the driver. This patch leaves the chip defaults, means
EEE typically is disabled initially and it's up to the user to enable
it via ethtool.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169.c | 47 ++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 9e335d2c7..4572de170 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -1990,6 +1990,12 @@ static int rtl_get_eee_supp(struct rtl8169_private *tp)
int ret;
switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_34:
+ case RTL_GIGA_MAC_VER_35:
+ case RTL_GIGA_MAC_VER_36:
+ case RTL_GIGA_MAC_VER_38:
+ ret = phy_read_mmd(phydev, MDIO_MMD_PCS, MDIO_PCS_EEE_ABLE);
+ break;
case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
phy_write(phydev, 0x1f, 0x0a5c);
ret = phy_read(phydev, 0x12);
@@ -2009,6 +2015,12 @@ static int rtl_get_eee_lpadv(struct rtl8169_private *tp)
int ret;
switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_34:
+ case RTL_GIGA_MAC_VER_35:
+ case RTL_GIGA_MAC_VER_36:
+ case RTL_GIGA_MAC_VER_38:
+ ret = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_LPABLE);
+ break;
case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
phy_write(phydev, 0x1f, 0x0a5d);
ret = phy_read(phydev, 0x11);
@@ -2028,6 +2040,12 @@ static int rtl_get_eee_adv(struct rtl8169_private *tp)
int ret;
switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_34:
+ case RTL_GIGA_MAC_VER_35:
+ case RTL_GIGA_MAC_VER_36:
+ case RTL_GIGA_MAC_VER_38:
+ ret = phy_read_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV);
+ break;
case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
phy_write(phydev, 0x1f, 0x0a5d);
ret = phy_read(phydev, 0x10);
@@ -2047,6 +2065,12 @@ static int rtl_set_eee_adv(struct rtl8169_private *tp, int val)
int ret = 0;
switch (tp->mac_version) {
+ case RTL_GIGA_MAC_VER_34:
+ case RTL_GIGA_MAC_VER_35:
+ case RTL_GIGA_MAC_VER_36:
+ case RTL_GIGA_MAC_VER_38:
+ ret = phy_write_mmd(phydev, MDIO_MMD_AN, MDIO_AN_EEE_ADV, val);
+ break;
case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
phy_write(phydev, 0x1f, 0x0a5d);
phy_write(phydev, 0x10, val);
@@ -2574,6 +2598,21 @@ static void rtl8168_config_eee_mac(struct rtl8169_private *tp)
rtl_w0w1_eri(tp, 0x1b0, ERIAR_MASK_1111, 0x0003, 0x0000, ERIAR_EXGMAC);
}
+static void rtl8168f_config_eee_phy(struct rtl8169_private *tp)
+{
+ struct phy_device *phydev = tp->phydev;
+
+ phy_write(phydev, 0x1f, 0x0007);
+ phy_write(phydev, 0x1e, 0x0020);
+ phy_set_bits(phydev, 0x15, BIT(8));
+
+ phy_write(phydev, 0x1f, 0x0005);
+ phy_write(phydev, 0x05, 0x8b85);
+ phy_set_bits(phydev, 0x06, BIT(13));
+
+ phy_write(phydev, 0x1f, 0x0000);
+}
+
static void rtl8168g_config_eee_phy(struct rtl8169_private *tp)
{
phy_write(tp->phydev, 0x1f, 0x0a43);
@@ -3348,6 +3387,8 @@ static void rtl8168e_2_hw_phy_config(struct rtl8169_private *tp)
rtl_w0w1_phy(tp, 0x06, 0x4000, 0x0000);
rtl_writephy(tp, 0x1f, 0x0000);
+ rtl8168f_config_eee_phy(tp);
+
/* EEE setting */
rtl_w0w1_eri(tp, 0x1b0, ERIAR_MASK_1111, 0x0003, 0x0000, ERIAR_EXGMAC);
rtl_writephy(tp, 0x1f, 0x0005);
@@ -3398,6 +3439,8 @@ static void rtl8168f_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x05, 0x8b86);
rtl_w0w1_phy(tp, 0x06, 0x0001, 0x0000);
rtl_writephy(tp, 0x1f, 0x0000);
+
+ rtl8168f_config_eee_phy(tp);
}
static void rtl8168f_1_hw_phy_config(struct rtl8169_private *tp)
@@ -5113,6 +5156,8 @@ static void rtl_hw_start_8168e_2(struct rtl8169_private *tp)
/* Adjust EEE LED frequency */
RTL_W8(tp, EEE_LED, RTL_R8(tp, EEE_LED) & ~0x07);
+ rtl8168_config_eee_mac(tp);
+
RTL_W8(tp, DLLPR, RTL_R8(tp, DLLPR) | PFM_EN);
RTL_W32(tp, MISC, RTL_R32(tp, MISC) | PWM_EN);
RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~Spi_en);
@@ -5145,6 +5190,8 @@ static void rtl_hw_start_8168f(struct rtl8169_private *tp)
RTL_W8(tp, DLLPR, RTL_R8(tp, DLLPR) | PFM_EN);
RTL_W32(tp, MISC, RTL_R32(tp, MISC) | PWM_EN);
RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~Spi_en);
+
+ rtl8168_config_eee_mac(tp);
}
static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH RFC 3/3] udp: Support UDP fraglist GRO/GSO.
From: Paolo Abeni @ 2019-01-26 9:36 UTC (permalink / raw)
To: Steffen Klassert; +Cc: netdev, Willem de Bruijn, Jason A. Donenfeld
In-Reply-To: <20190125075855.GT3581@gauss3.secunet.de>
On Fri, 2019-01-25 at 08:58 +0100, Steffen Klassert wrote:
> > Finally this will cause GRO/GSO for local UDP packets delivery to non
> > GSO_SEGMENT sockets. That could be possibly a win or a regression: we
> > save on netfilter/IP stack traversal, but we add additional work, some
> > performances figures would probably help.
>
> I did some tests for the local receive path with netperf and iperf, but
> in this case the sender that generates the packets is the bottleneck.
> So the benchmarks are not that meaningful for the receive path.
I think we can use GSO on the sender if we add some additional code on
the rx side - for testing purpose only - limiting the GRO aggregation
to an (user controlled via sysfs) value.
Beyond that, other options would be using multiple senders threads and
a single rx queue and/or asymmetric CPUs.
> Do you have some performance tests for UDP GRO receive?
I have a bunch of ansible(!!!) scripts I can share, if you dare. They
have a lot of hard-coded setting, so I'm not sure how much can be re-
used outside my testbed.
I also hope/wish/think/ I can allocate some time for benchmarking this
on my own in the next week[s], so I'll try to post some results for the
next iteration.
Cheers,
Paolo
^ permalink raw reply
* [PATCH net-next 0/2] r8169: add EEE support for RTL8168f
From: Heiner Kallweit @ 2019-01-26 9:34 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller; +Cc: netdev@vger.kernel.org
This series adds EEE support for RTL8168f. Again first patch adds the
support, and second patch enables EEE per default.
Heiner Kallweit (2):
r8169: add EEE support for RTL8168f
r8169: enable EEE per default on RTL8168f
drivers/net/ethernet/realtek/r8169.c | 80 +++++++++++++++++-----------
1 file changed, 48 insertions(+), 32 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH net 3/3] net: hns: Fix wrong read accesses via Clause 45 MDIO protocol
From: Peng Li @ 2019-01-26 9:18 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1548494307-63594-1-git-send-email-lipeng321@huawei.com>
From: Yonglong Liu <liuyonglong@huawei.com>
When reading phy registers via Clause 45 MDIO protocol, after write
address operation, the driver use another write address operation, so
can not read the right value of any phy registers. This patch fixes it.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns_mdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns_mdio.c b/drivers/net/ethernet/hisilicon/hns_mdio.c
index 017e084..baf5cc2 100644
--- a/drivers/net/ethernet/hisilicon/hns_mdio.c
+++ b/drivers/net/ethernet/hisilicon/hns_mdio.c
@@ -321,7 +321,7 @@ static int hns_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
}
hns_mdio_cmd_write(mdio_dev, is_c45,
- MDIO_C45_WRITE_ADDR, phy_id, devad);
+ MDIO_C45_READ, phy_id, devad);
}
/* Step 5: waitting for MDIO_COMMAND_REG 's mdio_start==0,*/
--
1.9.1
^ permalink raw reply related
* [PATCH net 2/3] net: hns: Restart autoneg need return failed when autoneg off
From: Peng Li @ 2019-01-26 9:18 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, linuxarm, yisen.zhuang, salil.mehta,
lipeng321
In-Reply-To: <1548494307-63594-1-git-send-email-lipeng321@huawei.com>
From: Yonglong Liu <liuyonglong@huawei.com>
The hns driver of earlier devices, when autoneg off, restart autoneg
will return -EINVAL, so make the hns driver for the latest devices
do the same.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
---
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
index 8e9b958..ce15d23 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
@@ -1157,16 +1157,18 @@ static int hns_get_regs_len(struct net_device *net_dev)
*/
static int hns_nic_nway_reset(struct net_device *netdev)
{
- int ret = 0;
struct phy_device *phy = netdev->phydev;
- if (netif_running(netdev)) {
- /* if autoneg is disabled, don't restart auto-negotiation */
- if (phy && phy->autoneg == AUTONEG_ENABLE)
- ret = genphy_restart_aneg(phy);
- }
+ if (!netif_running(netdev))
+ return 0;
- return ret;
+ if (!phy)
+ return -EOPNOTSUPP;
+
+ if (phy->autoneg != AUTONEG_ENABLE)
+ return -EINVAL;
+
+ return genphy_restart_aneg(phy);
}
static u32
--
1.9.1
^ permalink raw reply related
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