* [PATCH AUTOSEL 4.19 13/26] sis900: fix TX completion
From: Sasha Levin @ 2019-07-03 2:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sergej Benilov, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190703021625.18116-1-sashal@kernel.org>
From: Sergej Benilov <sergej.benilov@googlemail.com>
[ Upstream commit 8ac8a01092b2added0749ef937037bf1912e13e3 ]
Since commit 605ad7f184b60cfaacbc038aa6c55ee68dee3c89 "tcp: refine TSO autosizing",
outbound throughput is dramatically reduced for some connections, as sis900
is doing TX completion within idle states only.
Make TX completion happen after every transmitted packet.
Test:
netperf
before patch:
> netperf -H remote -l -2000000 -- -s 1000000
MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 327680 327680 253.44 0.06
after patch:
> netperf -H remote -l -10000000 -- -s 1000000
MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to 95.223.112.76 () port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 327680 327680 5.38 14.89
Thx to Dave Miller and Eric Dumazet for helpful hints
Signed-off-by: Sergej Benilov <sergej.benilov@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/sis/sis900.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/sis/sis900.c b/drivers/net/ethernet/sis/sis900.c
index 4bb89f74742c..d5bcbc40a55f 100644
--- a/drivers/net/ethernet/sis/sis900.c
+++ b/drivers/net/ethernet/sis/sis900.c
@@ -1057,7 +1057,7 @@ sis900_open(struct net_device *net_dev)
sis900_set_mode(sis_priv, HW_SPEED_10_MBPS, FDX_CAPABLE_HALF_SELECTED);
/* Enable all known interrupts by setting the interrupt mask. */
- sw32(imr, RxSOVR | RxORN | RxERR | RxOK | TxURN | TxERR | TxIDLE);
+ sw32(imr, RxSOVR | RxORN | RxERR | RxOK | TxURN | TxERR | TxIDLE | TxDESC);
sw32(cr, RxENA | sr32(cr));
sw32(ier, IE);
@@ -1578,7 +1578,7 @@ static void sis900_tx_timeout(struct net_device *net_dev)
sw32(txdp, sis_priv->tx_ring_dma);
/* Enable all known interrupts by setting the interrupt mask. */
- sw32(imr, RxSOVR | RxORN | RxERR | RxOK | TxURN | TxERR | TxIDLE);
+ sw32(imr, RxSOVR | RxORN | RxERR | RxOK | TxURN | TxERR | TxIDLE | TxDESC);
}
/**
@@ -1618,7 +1618,7 @@ sis900_start_xmit(struct sk_buff *skb, struct net_device *net_dev)
spin_unlock_irqrestore(&sis_priv->lock, flags);
return NETDEV_TX_OK;
}
- sis_priv->tx_ring[entry].cmdsts = (OWN | skb->len);
+ sis_priv->tx_ring[entry].cmdsts = (OWN | INTR | skb->len);
sw32(cr, TxENA | sr32(cr));
sis_priv->cur_tx ++;
@@ -1674,7 +1674,7 @@ static irqreturn_t sis900_interrupt(int irq, void *dev_instance)
do {
status = sr32(isr);
- if ((status & (HIBERR|TxURN|TxERR|TxIDLE|RxORN|RxERR|RxOK)) == 0)
+ if ((status & (HIBERR|TxURN|TxERR|TxIDLE|TxDESC|RxORN|RxERR|RxOK)) == 0)
/* nothing intresting happened */
break;
handled = 1;
@@ -1684,7 +1684,7 @@ static irqreturn_t sis900_interrupt(int irq, void *dev_instance)
/* Rx interrupt */
sis900_rx(net_dev);
- if (status & (TxURN | TxERR | TxIDLE))
+ if (status & (TxURN | TxERR | TxIDLE | TxDESC))
/* Tx interrupt */
sis900_finish_xmit(net_dev);
@@ -1896,8 +1896,8 @@ static void sis900_finish_xmit (struct net_device *net_dev)
if (tx_status & OWN) {
/* The packet is not transmitted yet (owned by hardware) !
- * Note: the interrupt is generated only when Tx Machine
- * is idle, so this is an almost impossible case */
+ * Note: this is an almost impossible condition
+ * in case of TxDESC ('descriptor interrupt') */
break;
}
@@ -2473,7 +2473,7 @@ static int sis900_resume(struct pci_dev *pci_dev)
sis900_set_mode(sis_priv, HW_SPEED_10_MBPS, FDX_CAPABLE_HALF_SELECTED);
/* Enable all known interrupts by setting the interrupt mask. */
- sw32(imr, RxSOVR | RxORN | RxERR | RxOK | TxURN | TxERR | TxIDLE);
+ sw32(imr, RxSOVR | RxORN | RxERR | RxOK | TxURN | TxERR | TxIDLE | TxDESC);
sw32(cr, RxENA | sr32(cr));
sw32(ier, IE);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 12/26] net: stmmac: set IC bit when transmitting frames with HW timestamp
From: Sasha Levin @ 2019-07-03 2:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Roland Hii, Ong Boon Leong, Voon Weifeng, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20190703021625.18116-1-sashal@kernel.org>
From: Roland Hii <roland.king.guan.hii@intel.com>
[ Upstream commit d0bb82fd60183868f46c8ccc595a3d61c3334a18 ]
When transmitting certain PTP frames, e.g. SYNC and DELAY_REQ, the
PTP daemon, e.g. ptp4l, is polling the driver for the frame transmit
hardware timestamp. The polling will most likely timeout if the tx
coalesce is enabled due to the Interrupt-on-Completion (IC) bit is
not set in tx descriptor for those frames.
This patch will ignore the tx coalesce parameter and set the IC bit
when transmitting PTP frames which need to report out the frame
transmit hardware timestamp to user space.
Fixes: f748be531d70 ("net: stmmac: Rework coalesce timer and fix multi-queue races")
Signed-off-by: Roland Hii <roland.king.guan.hii@intel.com>
Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 22 ++++++++++++-------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 45e64d71a93f..5c18874614ba 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2938,12 +2938,15 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
/* Manage tx mitigation */
tx_q->tx_count_frames += nfrags + 1;
- if (priv->tx_coal_frames <= tx_q->tx_count_frames) {
+ if (likely(priv->tx_coal_frames > tx_q->tx_count_frames) &&
+ !(priv->synopsys_id >= DWMAC_CORE_4_00 &&
+ (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+ priv->hwts_tx_en)) {
+ stmmac_tx_timer_arm(priv, queue);
+ } else {
+ tx_q->tx_count_frames = 0;
stmmac_set_tx_ic(priv, desc);
priv->xstats.tx_set_ic_bit++;
- tx_q->tx_count_frames = 0;
- } else {
- stmmac_tx_timer_arm(priv, queue);
}
skb_tx_timestamp(skb);
@@ -3157,12 +3160,15 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
* element in case of no SG.
*/
tx_q->tx_count_frames += nfrags + 1;
- if (priv->tx_coal_frames <= tx_q->tx_count_frames) {
+ if (likely(priv->tx_coal_frames > tx_q->tx_count_frames) &&
+ !(priv->synopsys_id >= DWMAC_CORE_4_00 &&
+ (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+ priv->hwts_tx_en)) {
+ stmmac_tx_timer_arm(priv, queue);
+ } else {
+ tx_q->tx_count_frames = 0;
stmmac_set_tx_ic(priv, desc);
priv->xstats.tx_set_ic_bit++;
- tx_q->tx_count_frames = 0;
- } else {
- stmmac_tx_timer_arm(priv, queue);
}
skb_tx_timestamp(skb);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 11/26] net: stmmac: fixed new system time seconds value calculation
From: Sasha Levin @ 2019-07-03 2:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Roland Hii, Ong Boon Leong, Voon Weifeng, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20190703021625.18116-1-sashal@kernel.org>
From: Roland Hii <roland.king.guan.hii@intel.com>
[ Upstream commit a1e5388b4d5fc78688e5e9ee6641f779721d6291 ]
When ADDSUB bit is set, the system time seconds field is calculated as
the complement of the seconds part of the update value.
For example, if 3.000000001 seconds need to be subtracted from the
system time, this field is calculated as
2^32 - 3 = 4294967296 - 3 = 0x100000000 - 3 = 0xFFFFFFFD
Previously, the 0x100000000 is mistakenly written as 100000000.
This is further simplified from
sec = (0x100000000ULL - sec);
to
sec = -sec;
Fixes: ba1ffd74df74 ("stmmac: fix PTP support for GMAC4")
Signed-off-by: Roland Hii <roland.king.guan.hii@intel.com>
Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 8d9cc2157afd..7423262ce590 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -122,7 +122,7 @@ static int adjust_systime(void __iomem *ioaddr, u32 sec, u32 nsec,
* programmed with (2^32 – <new_sec_value>)
*/
if (gmac4)
- sec = (100000000ULL - sec);
+ sec = -sec;
value = readl(ioaddr + PTP_TCR);
if (value & PTP_TCR_TSCTRLSSR)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 15/26] qmi_wwan: Fix out-of-bounds read
From: Sasha Levin @ 2019-07-03 2:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Bjørn Mork, syzbot+b68605d7fadd21510de1, Kristian Evensen,
David S . Miller, Sasha Levin, netdev, linux-usb
In-Reply-To: <20190703021625.18116-1-sashal@kernel.org>
From: Bjørn Mork <bjorn@mork.no>
[ Upstream commit 904d88d743b0c94092c5117955eab695df8109e8 ]
The syzbot reported
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x67/0x231 mm/kasan/report.c:188
__kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
kasan_report+0xe/0x20 mm/kasan/common.c:614
qmi_wwan_probe+0x342/0x360 drivers/net/usb/qmi_wwan.c:1417
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x660 drivers/base/dd.c:509
driver_probe_device+0x104/0x210 drivers/base/dd.c:670
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
Caused by too many confusing indirections and casts.
id->driver_info is a pointer stored in a long. We want the
pointer here, not the address of it.
Thanks-to: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+b68605d7fadd21510de1@syzkaller.appspotmail.com
Cc: Kristian Evensen <kristian.evensen@gmail.com>
Fixes: e4bf63482c30 ("qmi_wwan: Add quirk for Quectel dynamic config")
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index d9a6699abe59..e657d8947125 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1412,7 +1412,7 @@ static int qmi_wwan_probe(struct usb_interface *intf,
* different. Ignore the current interface if the number of endpoints
* equals the number for the diag interface (two).
*/
- info = (void *)&id->driver_info;
+ info = (void *)id->driver_info;
if (info->data & QMI_WWAN_QUIRK_QUECTEL_DYNCFG) {
if (desc->bNumEndpoints == 2)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 09/26] be2net: fix link failure after ethtool offline test
From: Sasha Levin @ 2019-07-03 2:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Petr Oros, Ivan Vecera, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190703021625.18116-1-sashal@kernel.org>
From: Petr Oros <poros@redhat.com>
[ Upstream commit 2e5db6eb3c23e5dc8171eb8f6af7a97ef9fcf3a9 ]
Certain cards in conjunction with certain switches need a little more
time for link setup that results in ethtool link test failure after
offline test. Patch adds a loop that waits for a link setup finish.
Changes in v2:
- added fixes header
Fixes: 4276e47e2d1c ("be2net: Add link test to list of ethtool self tests.")
Signed-off-by: Petr Oros <poros@redhat.com>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/emulex/benet/be_ethtool.c | 28 +++++++++++++++----
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index bfb16a474490..d1905d50c26c 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -895,7 +895,7 @@ static void be_self_test(struct net_device *netdev, struct ethtool_test *test,
u64 *data)
{
struct be_adapter *adapter = netdev_priv(netdev);
- int status;
+ int status, cnt;
u8 link_status = 0;
if (adapter->function_caps & BE_FUNCTION_CAPS_SUPER_NIC) {
@@ -906,6 +906,9 @@ static void be_self_test(struct net_device *netdev, struct ethtool_test *test,
memset(data, 0, sizeof(u64) * ETHTOOL_TESTS_NUM);
+ /* check link status before offline tests */
+ link_status = netif_carrier_ok(netdev);
+
if (test->flags & ETH_TEST_FL_OFFLINE) {
if (be_loopback_test(adapter, BE_MAC_LOOPBACK, &data[0]) != 0)
test->flags |= ETH_TEST_FL_FAILED;
@@ -926,13 +929,26 @@ static void be_self_test(struct net_device *netdev, struct ethtool_test *test,
test->flags |= ETH_TEST_FL_FAILED;
}
- status = be_cmd_link_status_query(adapter, NULL, &link_status, 0);
- if (status) {
- test->flags |= ETH_TEST_FL_FAILED;
- data[4] = -1;
- } else if (!link_status) {
+ /* link status was down prior to test */
+ if (!link_status) {
test->flags |= ETH_TEST_FL_FAILED;
data[4] = 1;
+ return;
+ }
+
+ for (cnt = 10; cnt; cnt--) {
+ status = be_cmd_link_status_query(adapter, NULL, &link_status,
+ 0);
+ if (status) {
+ test->flags |= ETH_TEST_FL_FAILED;
+ data[4] = -1;
+ break;
+ }
+
+ if (link_status)
+ break;
+
+ msleep_interruptible(500);
}
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 19/39] net: stmmac: set IC bit when transmitting frames with HW timestamp
From: Sasha Levin @ 2019-07-03 2:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Roland Hii, Ong Boon Leong, Voon Weifeng, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20190703021514.17727-1-sashal@kernel.org>
From: Roland Hii <roland.king.guan.hii@intel.com>
[ Upstream commit d0bb82fd60183868f46c8ccc595a3d61c3334a18 ]
When transmitting certain PTP frames, e.g. SYNC and DELAY_REQ, the
PTP daemon, e.g. ptp4l, is polling the driver for the frame transmit
hardware timestamp. The polling will most likely timeout if the tx
coalesce is enabled due to the Interrupt-on-Completion (IC) bit is
not set in tx descriptor for those frames.
This patch will ignore the tx coalesce parameter and set the IC bit
when transmitting PTP frames which need to report out the frame
transmit hardware timestamp to user space.
Fixes: f748be531d70 ("net: stmmac: Rework coalesce timer and fix multi-queue races")
Signed-off-by: Roland Hii <roland.king.guan.hii@intel.com>
Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 22 ++++++++++++-------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 635d88d82610..a634054dcb11 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2957,12 +2957,15 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
/* Manage tx mitigation */
tx_q->tx_count_frames += nfrags + 1;
- if (priv->tx_coal_frames <= tx_q->tx_count_frames) {
+ if (likely(priv->tx_coal_frames > tx_q->tx_count_frames) &&
+ !(priv->synopsys_id >= DWMAC_CORE_4_00 &&
+ (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+ priv->hwts_tx_en)) {
+ stmmac_tx_timer_arm(priv, queue);
+ } else {
+ tx_q->tx_count_frames = 0;
stmmac_set_tx_ic(priv, desc);
priv->xstats.tx_set_ic_bit++;
- tx_q->tx_count_frames = 0;
- } else {
- stmmac_tx_timer_arm(priv, queue);
}
skb_tx_timestamp(skb);
@@ -3176,12 +3179,15 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
* element in case of no SG.
*/
tx_q->tx_count_frames += nfrags + 1;
- if (priv->tx_coal_frames <= tx_q->tx_count_frames) {
+ if (likely(priv->tx_coal_frames > tx_q->tx_count_frames) &&
+ !(priv->synopsys_id >= DWMAC_CORE_4_00 &&
+ (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+ priv->hwts_tx_en)) {
+ stmmac_tx_timer_arm(priv, queue);
+ } else {
+ tx_q->tx_count_frames = 0;
stmmac_set_tx_ic(priv, desc);
priv->xstats.tx_set_ic_bit++;
- tx_q->tx_count_frames = 0;
- } else {
- stmmac_tx_timer_arm(priv, queue);
}
skb_tx_timestamp(skb);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 18/39] net: stmmac: fixed new system time seconds value calculation
From: Sasha Levin @ 2019-07-03 2:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Roland Hii, Ong Boon Leong, Voon Weifeng, David S . Miller,
Sasha Levin, netdev
In-Reply-To: <20190703021514.17727-1-sashal@kernel.org>
From: Roland Hii <roland.king.guan.hii@intel.com>
[ Upstream commit a1e5388b4d5fc78688e5e9ee6641f779721d6291 ]
When ADDSUB bit is set, the system time seconds field is calculated as
the complement of the seconds part of the update value.
For example, if 3.000000001 seconds need to be subtracted from the
system time, this field is calculated as
2^32 - 3 = 4294967296 - 3 = 0x100000000 - 3 = 0xFFFFFFFD
Previously, the 0x100000000 is mistakenly written as 100000000.
This is further simplified from
sec = (0x100000000ULL - sec);
to
sec = -sec;
Fixes: ba1ffd74df74 ("stmmac: fix PTP support for GMAC4")
Signed-off-by: Roland Hii <roland.king.guan.hii@intel.com>
Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 8d9cc2157afd..7423262ce590 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -122,7 +122,7 @@ static int adjust_systime(void __iomem *ioaddr, u32 sec, u32 nsec,
* programmed with (2^32 – <new_sec_value>)
*/
if (gmac4)
- sec = (100000000ULL - sec);
+ sec = -sec;
value = readl(ioaddr + PTP_TCR);
if (value & PTP_TCR_TSCTRLSSR)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.1 16/39] be2net: fix link failure after ethtool offline test
From: Sasha Levin @ 2019-07-03 2:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Petr Oros, Ivan Vecera, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20190703021514.17727-1-sashal@kernel.org>
From: Petr Oros <poros@redhat.com>
[ Upstream commit 2e5db6eb3c23e5dc8171eb8f6af7a97ef9fcf3a9 ]
Certain cards in conjunction with certain switches need a little more
time for link setup that results in ethtool link test failure after
offline test. Patch adds a loop that waits for a link setup finish.
Changes in v2:
- added fixes header
Fixes: 4276e47e2d1c ("be2net: Add link test to list of ethtool self tests.")
Signed-off-by: Petr Oros <poros@redhat.com>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
.../net/ethernet/emulex/benet/be_ethtool.c | 28 +++++++++++++++----
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_ethtool.c b/drivers/net/ethernet/emulex/benet/be_ethtool.c
index 6e635debc7fd..cfa01efa5b48 100644
--- a/drivers/net/ethernet/emulex/benet/be_ethtool.c
+++ b/drivers/net/ethernet/emulex/benet/be_ethtool.c
@@ -895,7 +895,7 @@ static void be_self_test(struct net_device *netdev, struct ethtool_test *test,
u64 *data)
{
struct be_adapter *adapter = netdev_priv(netdev);
- int status;
+ int status, cnt;
u8 link_status = 0;
if (adapter->function_caps & BE_FUNCTION_CAPS_SUPER_NIC) {
@@ -906,6 +906,9 @@ static void be_self_test(struct net_device *netdev, struct ethtool_test *test,
memset(data, 0, sizeof(u64) * ETHTOOL_TESTS_NUM);
+ /* check link status before offline tests */
+ link_status = netif_carrier_ok(netdev);
+
if (test->flags & ETH_TEST_FL_OFFLINE) {
if (be_loopback_test(adapter, BE_MAC_LOOPBACK, &data[0]) != 0)
test->flags |= ETH_TEST_FL_FAILED;
@@ -926,13 +929,26 @@ static void be_self_test(struct net_device *netdev, struct ethtool_test *test,
test->flags |= ETH_TEST_FL_FAILED;
}
- status = be_cmd_link_status_query(adapter, NULL, &link_status, 0);
- if (status) {
- test->flags |= ETH_TEST_FL_FAILED;
- data[4] = -1;
- } else if (!link_status) {
+ /* link status was down prior to test */
+ if (!link_status) {
test->flags |= ETH_TEST_FL_FAILED;
data[4] = 1;
+ return;
+ }
+
+ for (cnt = 10; cnt; cnt--) {
+ status = be_cmd_link_status_query(adapter, NULL, &link_status,
+ 0);
+ if (status) {
+ test->flags |= ETH_TEST_FL_FAILED;
+ data[4] = -1;
+ break;
+ }
+
+ if (link_status)
+ break;
+
+ msleep_interruptible(500);
}
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next v6 11/15] ethtool: provide link mode names as a string set
From: Jakub Kicinski @ 2019-07-03 2:11 UTC (permalink / raw)
To: Michal Kubecek
Cc: David Miller, netdev, Jiri Pirko, Andrew Lunn, Florian Fainelli,
John Linville, Stephen Hemminger, Johannes Berg, linux-kernel
In-Reply-To: <20190702190419.1cb8a189@cakuba.netronome.com>
On Tue, 2 Jul 2019 19:04:19 -0700, Jakub Kicinski wrote:
> On Tue, 2 Jul 2019 13:50:34 +0200 (CEST), Michal Kubecek wrote:
> > +const char *const link_mode_names[] = {
> > + __DEFINE_LINK_MODE_NAME(10, T, Half),
> > + __DEFINE_LINK_MODE_NAME(10, T, Full),
> > + __DEFINE_LINK_MODE_NAME(100, T, Half),
> > + __DEFINE_LINK_MODE_NAME(100, T, Full),
> > + __DEFINE_LINK_MODE_NAME(1000, T, Half),
> > + __DEFINE_LINK_MODE_NAME(1000, T, Full),
> > + __DEFINE_SPECIAL_MODE_NAME(Autoneg, "Autoneg"),
> > + __DEFINE_SPECIAL_MODE_NAME(TP, "TP"),
> > + __DEFINE_SPECIAL_MODE_NAME(AUI, "AUI"),
> > + __DEFINE_SPECIAL_MODE_NAME(MII, "MII"),
> > + __DEFINE_SPECIAL_MODE_NAME(FIBRE, "FIBRE"),
> > + __DEFINE_SPECIAL_MODE_NAME(BNC, "BNC"),
>
> > + __DEFINE_LINK_MODE_NAME(10000, T, Full),
> > + __DEFINE_SPECIAL_MODE_NAME(Pause, "Pause"),
> > + __DEFINE_SPECIAL_MODE_NAME(Asym_Pause, "Asym_Pause"),
> > + __DEFINE_LINK_MODE_NAME(2500, X, Full),
> > + __DEFINE_SPECIAL_MODE_NAME(Backplane, "Backplane"),
> > + __DEFINE_LINK_MODE_NAME(1000, KX, Full),
> ...
> > + __DEFINE_LINK_MODE_NAME(5000, T, Full),
> > + __DEFINE_SPECIAL_MODE_NAME(FEC_NONE, "None"),
> > + __DEFINE_SPECIAL_MODE_NAME(FEC_RS, "RS"),
> > + __DEFINE_SPECIAL_MODE_NAME(FEC_BASER, "BASER"),
>
> Why are port types and FEC params among link mode strings?
Ah, FEC for autoneg, but port type?
> > + __DEFINE_LINK_MODE_NAME(50000, KR, Full),
> ...
> > + __DEFINE_LINK_MODE_NAME(1000, T1, Full),
> > +};
^ permalink raw reply
* RE: [PATCH net-next 1/3] devlink: Introduce PCI PF port flavour and port attribute
From: Parav Pandit @ 2019-07-03 2:08 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Jiri Pirko, netdev@vger.kernel.org, Saeed Mahameed
In-Reply-To: <20190702164252.6d4fe5e3@cakuba.netronome.com>
> -----Original Message-----
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
> Sent: Wednesday, July 3, 2019 5:13 AM
> To: Parav Pandit <parav@mellanox.com>
> Cc: Jiri Pirko <jiri@mellanox.com>; netdev@vger.kernel.org; Saeed
> Mahameed <saeedm@mellanox.com>
> Subject: Re: [PATCH net-next 1/3] devlink: Introduce PCI PF port flavour and
> port attribute
>
> On Tue, 2 Jul 2019 18:50:31 +0000, Parav Pandit wrote:
> > > > I didn't see any immediate need to report, at the same time didn't
> > > > find any reason to treat such port flavours differently than
> > > > existing one. It just gives a clear view of the device's eswitch.
> > > > Might find it useful during debugging while inspecting device internal
> tables..
> > >
> > > PFs and VFs ports are not tied to network ports in switchdev mode.
> > > You have only one network port under a devlink instance AFAIR, anyway.
> > >
> > I am not sure what do you mean by network port.
>
> DEVLINK_PORT_FLAVOUR_PHYSICAL
>
> > Do you intent to see a physical port that connects to physical network?
> >
> > As I described in the comment of the PF and VF flavour, it is an eswitch
> port.
> > I have shown the diagram also of the eswitch in the cover letter.
> > Port_number doesn't have to a physical port. Flavour describe what
> > port type is and number says what is the eswitch port number.
> > Hope it clarifies.
>
> I understand what you're doing.
o.k.
> If you want to expose some device specific
> eswitch port ID please add a new attribute for that.
> The fact that that ID may match port_number for your device today is
> coincidental. port_number, and split attributes should not be exposed for
> PCI ports.
So your concern is non mellanox hw has eswitch but there may not be a unique handle to identify a eswitch port?
Or that handle may be wider than 32-bit?
And instead of treating port_number as handle, there should be different attribute, is that the ask?
^ permalink raw reply
* Re: [PATCH net-next v6 11/15] ethtool: provide link mode names as a string set
From: Jakub Kicinski @ 2019-07-03 2:04 UTC (permalink / raw)
To: Michal Kubecek
Cc: David Miller, netdev, Jiri Pirko, Andrew Lunn, Florian Fainelli,
John Linville, Stephen Hemminger, Johannes Berg, linux-kernel
In-Reply-To: <1e1bf53de26780ecc0e448aa07dc429ef590798a.1562067622.git.mkubecek@suse.cz>
On Tue, 2 Jul 2019 13:50:34 +0200 (CEST), Michal Kubecek wrote:
> +const char *const link_mode_names[] = {
> + __DEFINE_LINK_MODE_NAME(10, T, Half),
> + __DEFINE_LINK_MODE_NAME(10, T, Full),
> + __DEFINE_LINK_MODE_NAME(100, T, Half),
> + __DEFINE_LINK_MODE_NAME(100, T, Full),
> + __DEFINE_LINK_MODE_NAME(1000, T, Half),
> + __DEFINE_LINK_MODE_NAME(1000, T, Full),
> + __DEFINE_SPECIAL_MODE_NAME(Autoneg, "Autoneg"),
> + __DEFINE_SPECIAL_MODE_NAME(TP, "TP"),
> + __DEFINE_SPECIAL_MODE_NAME(AUI, "AUI"),
> + __DEFINE_SPECIAL_MODE_NAME(MII, "MII"),
> + __DEFINE_SPECIAL_MODE_NAME(FIBRE, "FIBRE"),
> + __DEFINE_SPECIAL_MODE_NAME(BNC, "BNC"),
> + __DEFINE_LINK_MODE_NAME(10000, T, Full),
> + __DEFINE_SPECIAL_MODE_NAME(Pause, "Pause"),
> + __DEFINE_SPECIAL_MODE_NAME(Asym_Pause, "Asym_Pause"),
> + __DEFINE_LINK_MODE_NAME(2500, X, Full),
> + __DEFINE_SPECIAL_MODE_NAME(Backplane, "Backplane"),
> + __DEFINE_LINK_MODE_NAME(1000, KX, Full),
...
> + __DEFINE_LINK_MODE_NAME(5000, T, Full),
> + __DEFINE_SPECIAL_MODE_NAME(FEC_NONE, "None"),
> + __DEFINE_SPECIAL_MODE_NAME(FEC_RS, "RS"),
> + __DEFINE_SPECIAL_MODE_NAME(FEC_BASER, "BASER"),
Why are port types and FEC params among link mode strings?
> + __DEFINE_LINK_MODE_NAME(50000, KR, Full),
...
> + __DEFINE_LINK_MODE_NAME(1000, T1, Full),
> +};
^ permalink raw reply
* Re: [PATCH v5] net: netfilter: Fix rpfilter dropping vrf packets by mistake
From: linmiaohe @ 2019-07-03 1:59 UTC (permalink / raw)
To: David Ahern
Cc: pablo@netfilter.org, kadlec@blackhole.kfki.hu, fw@strlen.de,
davem@davemloft.net, kuznet@ms2.inr.ac.ru,
yoshfuji@linux-ipv6.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Mingfangsen
Add David Ahern. @David Ahern I'am so sorry but I rerun scripts/get_maintainer.pl .
You are not in the list , so I forgot to add you to the email-to list. I'am sorry again.
Have a good day.
Best wishes.
When firewalld is enabled with ipv4/ipv6 rpfilter, vrf
ipv4/ipv6 packets will be dropped. Vrf device will pass through netfilter hook twice. One with enslaved device and another one with l3 master device. So in device may dismatch witch out device because out device is always enslaved device.So failed with the check of the rpfilter and drop the packets by mistake.
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
---
net/ipv4/netfilter/ipt_rpfilter.c | 1 + net/ipv6/netfilter/ip6t_rpfilter.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/netfilter/ipt_rpfilter.c b/net/ipv4/netfilter/ipt_rpfilter.c
index 59031670b16a..cc23f1ce239c 100644
--- a/net/ipv4/netfilter/ipt_rpfilter.c
+++ b/net/ipv4/netfilter/ipt_rpfilter.c
@@ -78,6 +78,7 @@ static bool rpfilter_mt(const struct sk_buff *skb, struct xt_action_param *par)
flow.flowi4_mark = info->flags & XT_RPFILTER_VALID_MARK ? skb->mark : 0;
flow.flowi4_tos = RT_TOS(iph->tos);
flow.flowi4_scope = RT_SCOPE_UNIVERSE;
+ flow.flowi4_oif = l3mdev_master_ifindex_rcu(xt_in(par));
return rpfilter_lookup_reverse(xt_net(par), &flow, xt_in(par), info->flags) ^ invert; } diff --git a/net/ipv6/netfilter/ip6t_rpfilter.c b/net/ipv6/netfilter/ip6t_rpfilter.c
index 6bcaf7357183..d800801a5dd2 100644
--- a/net/ipv6/netfilter/ip6t_rpfilter.c
+++ b/net/ipv6/netfilter/ip6t_rpfilter.c
@@ -55,7 +55,9 @@ static bool rpfilter_lookup_reverse6(struct net *net, const struct sk_buff *skb,
if (rpfilter_addr_linklocal(&iph->saddr)) {
lookup_flags |= RT6_LOOKUP_F_IFACE;
fl6.flowi6_oif = dev->ifindex;
- } else if ((flags & XT_RPFILTER_LOOSE) == 0)
+ /* Set flowi6_oif for vrf devices to lookup route in l3mdev domain. */
+ } else if (netif_is_l3_master(dev) || netif_is_l3_slave(dev) ||
+ (flags & XT_RPFILTER_LOOSE) == 0)
fl6.flowi6_oif = dev->ifindex;
rt = (void *)ip6_route_lookup(net, &fl6, skb, lookup_flags); @@ -70,7 +72,9 @@ static bool rpfilter_lookup_reverse6(struct net *net, const struct sk_buff *skb,
goto out;
}
- if (rt->rt6i_idev->dev == dev || (flags & XT_RPFILTER_LOOSE))
+ if (rt->rt6i_idev->dev == dev ||
+ l3mdev_master_ifindex_rcu(rt->rt6i_idev->dev) == dev->ifindex ||
+ (flags & XT_RPFILTER_LOOSE))
ret = true;
out:
ip6_rt_put(rt);
--
2.21.GIT
^ permalink raw reply related
* Re: [PATCH net-next 1/3] macsec: remove superfluous function calls
From: Willem de Bruijn @ 2019-07-03 1:50 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Andreas Steinmetz, Network Development, Sabrina Dubroca
In-Reply-To: <CA+FuTSfih0pBbOnXxkw4UpmiqDnNLf4k8O-=7XW4m7fj5ogqXw@mail.gmail.com>
On Sun, Jun 30, 2019 at 9:57 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Sun, Jun 30, 2019 at 4:48 PM Andreas Steinmetz <ast@domdv.de> wrote:
> >
> > Remove superfluous skb_share_check() and skb_unshare().
> > macsec_decrypt is only called by macsec_handle_frame which
> > already does a skb_unshare().
>
> There is a subtle difference. skb_unshare() acts on cloned skbs, not
> shared skbs.
>
> It creates a private copy of data if clones may access it
> concurrently, which clearly is needed when modifying for decryption.
>
> At rx_handler, I don't think a shared skb happen (unlike clones, e.g.,
> from packet sockets). But it is peculiar that most, if not all,
> rx_handlers seem to test for it. That have started with the bridge
> device:
>
> commit 7b995651e373d6424f81db23f2ec503306dfd7f0
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Sun Oct 14 00:39:01 2007 -0700
>
> [BRIDGE]: Unshare skb upon entry
>
> Due to the special location of the bridging hook, it should never see a
> shared packet anyway (certainly not with any in-kernel code). So it
> makes sense to unshare the skb there if necessary as that will greatly
> simplify the code below it (in particular, netfilter).
>
> Anyway, remove the check only if certain.
Did you see this point? I notice the v2 without this mentioned. I
don't think you can remove an skb_share_check solely on the basis of a
previous skb_unshare. I agree that here a shared skb is unlikely, but
that is for a very different, less obvious, reason.
>
> >
> > Signed-off-by: Andreas Steinmetz <ast@domdv.de>
> >
> > --- a/drivers/net/macsec.c 2019-06-30 22:02:54.906908179 +0200
> > +++ b/drivers/net/macsec.c 2019-06-30 22:03:07.315785186 +0200
> > @@ -939,9 +939,6 @@
> > u16 icv_len = secy->icv_len;
> >
> > macsec_skb_cb(skb)->valid = false;
> > - skb = skb_share_check(skb, GFP_ATOMIC);
> > - if (!skb)
> > - return ERR_PTR(-ENOMEM);
> >
> > ret = skb_cow_data(skb, 0, &trailer);
> > if (unlikely(ret < 0)) {
> > @@ -973,11 +970,6 @@
> >
> > aead_request_set_crypt(req, sg, sg, len, iv);
> > aead_request_set_ad(req, macsec_hdr_len(macsec_skb_cb(skb)->has_sci));
> > - skb = skb_unshare(skb, GFP_ATOMIC);
> > - if (!skb) {
> > - aead_request_free(req);
> > - return ERR_PTR(-ENOMEM);
> > - }
> > } else {
> > /* integrity only: all headers + data authenticated */
> > aead_request_set_crypt(req, sg, sg, icv_len, iv);
> >
^ permalink raw reply
* Re: [PATCH] net: core: page_pool: add user refcnt and reintroduce page_pool_destroy
From: Ivan Khoronzhuk @ 2019-07-02 20:28 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev, Ilias Apalodimas,
grygorii.strashko, jakub.kicinski, daniel, john.fastabend, ast,
linux-kernel, linux-omap
In-Reply-To: <20190702185839.GH4510@khorivan>
On Tue, Jul 02, 2019 at 09:58:40PM +0300, Ivan Khoronzhuk wrote:
>On Tue, Jul 02, 2019 at 08:29:07PM +0200, Jesper Dangaard Brouer wrote:
>>On Tue, 2 Jul 2019 18:21:13 +0300
>>Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
>>
>>>On Tue, Jul 02, 2019 at 05:10:29PM +0200, Jesper Dangaard Brouer wrote:
>>>>On Tue, 2 Jul 2019 17:56:13 +0300
>>>>Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
>>>>
>>>>> On Tue, Jul 02, 2019 at 04:52:30PM +0200, Jesper Dangaard Brouer wrote:
>>>>> >On Tue, 2 Jul 2019 17:44:27 +0300
>>>>> >Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> wrote:
>>>>> >
>>>>> >> On Tue, Jul 02, 2019 at 04:31:39PM +0200, Jesper Dangaard Brouer wrote:
>>>>> >> >From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
>>>>> >> >
>>>>> >> >Jesper recently removed page_pool_destroy() (from driver invocation) and
>>>>> >> >moved shutdown and free of page_pool into xdp_rxq_info_unreg(), in-order to
>>>>> >> >handle in-flight packets/pages. This created an asymmetry in drivers
>>>>> >> >create/destroy pairs.
>>>>> >> >
>>>>> >> >This patch add page_pool user refcnt and reintroduce page_pool_destroy.
>>>>> >> >This serves two purposes, (1) simplify drivers error handling as driver now
>>>>> >> >drivers always calls page_pool_destroy() and don't need to track if
>>>>> >> >xdp_rxq_info_reg_mem_model() was unsuccessful. (2) allow special cases
>>>>> >> >where a single RX-queue (with a single page_pool) provides packets for two
>>>>> >> >net_device'es, and thus needs to register the same page_pool twice with two
>>>>> >> >xdp_rxq_info structures.
>>>>> >>
>>>>> >> As I tend to use xdp level patch there is no more reason to mention (2) case
>>>>> >> here. XDP patch serves it better and can prevent not only obj deletion but also
>>>>> >> pool flush, so, this one patch I could better leave only for (1) case.
>>>>> >
>>>>> >I don't understand what you are saying.
>>>>> >
>>>>> >Do you approve this patch, or do you reject this patch?
>>>>> >
>>>>> It's not reject, it's proposition to use both, XDP and page pool patches,
>>>>> each having its goal.
>>>>
>>>>Just to be clear, if you want this patch to get accepted you have to
>>>>reply with your Signed-off-by (as I wrote).
>>>>
>>>>Maybe we should discuss it in another thread, about why you want two
>>>>solutions to the same problem.
>>>
>>>If it solves same problem I propose to reject this one and use this:
>>>https://lkml.org/lkml/2019/7/2/651
>>
>>No, I propose using this one, and rejecting the other one.
>
>There is at least several arguments against this one (related (2) purpose)
>
>It allows:
>- avoid changes to page_pool/mlx5/netsec
>- save not only allocator obj but allocator "page/buffer flush"
>- buffer flush can be present not only in page_pool but for other allocators
> that can behave differently and not so simple solution.
>- to not limit cpsw/(potentially others) to use "page_pool" allocator only
>....
>
>This patch better leave also, as it simplifies error path for page_pool and
>have more error prone usage comparing with existent one.
>
>Please, don't limit cpsw and potentially other drivers to use only
>page_pool it can be zca or etc... I don't won't to modify each allocator.
>I propose to add both as by fact they solve different problems with common
>solution.
I can pick up this one but remove description related to (2) and add
appropriate modifications to cpsw.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* [PATCH v1 net-next] net: stmmac: enable clause 45 mdio support
From: Voon Weifeng @ 2019-07-03 9:50 UTC (permalink / raw)
To: David S. Miller, Maxime Coquelin
Cc: netdev, linux-kernel, Jose Abreu, Giuseppe Cavallaro, Andrew Lunn,
Florian Fainelli, Alexandre Torgue, biao huang, Ong Boon Leong,
Kweh Hock Leong, Voon Weifeng
From: Kweh Hock Leong <hock.leong.kweh@intel.com>
DWMAC4 is capable to support clause 45 mdio communication.
This patch enable the feature on stmmac_mdio_write() and
stmmac_mdio_read() by following phy_write_mmd() and
phy_read_mmd() mdiobus read write implementation format.
Reviewed-by: Li, Yifan <yifan2.li@intel.com>
Signed-off-by: Kweh Hock Leong <hock.leong.kweh@intel.com>
Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
Signed-off-by: Weifeng Voon <weifeng.voon@intel.com>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index 18cadf0b0d66..b9edb18769f2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -24,11 +24,27 @@
#define MII_BUSY 0x00000001
#define MII_WRITE 0x00000002
+#define MII_DATA_MASK GENMASK(15, 0)
/* GMAC4 defines */
#define MII_GMAC4_GOC_SHIFT 2
+#define MII_GMAC4_REG_ADDR_SHIFT 16
#define MII_GMAC4_WRITE (1 << MII_GMAC4_GOC_SHIFT)
#define MII_GMAC4_READ (3 << MII_GMAC4_GOC_SHIFT)
+#define MII_GMAC4_C45E BIT(1)
+
+static void stmmac_mdio_c45_setup(struct stmmac_priv *priv, int phyreg,
+ u32 *val, u32 *data)
+{
+ unsigned int reg_shift = priv->hw->mii.reg_shift;
+ unsigned int reg_mask = priv->hw->mii.reg_mask;
+
+ *val |= MII_GMAC4_C45E;
+ *val &= ~reg_mask;
+ *val |= ((phyreg >> MII_DEVADDR_C45_SHIFT) << reg_shift) & reg_mask;
+
+ *data |= (phyreg & MII_REGADDR_C45_MASK) << MII_GMAC4_REG_ADDR_SHIFT;
+}
/* XGMAC defines */
#define MII_XGMAC_SADDR BIT(18)
@@ -155,22 +171,26 @@ static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr, int phyreg)
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned int mii_address = priv->hw->mii.addr;
unsigned int mii_data = priv->hw->mii.data;
- u32 v;
- int data;
u32 value = MII_BUSY;
+ int data = 0;
+ u32 v;
value |= (phyaddr << priv->hw->mii.addr_shift)
& priv->hw->mii.addr_mask;
value |= (phyreg << priv->hw->mii.reg_shift) & priv->hw->mii.reg_mask;
value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
& priv->hw->mii.clk_csr_mask;
- if (priv->plat->has_gmac4)
+ if (priv->plat->has_gmac4) {
value |= MII_GMAC4_READ;
+ if (phyreg & MII_ADDR_C45)
+ stmmac_mdio_c45_setup(priv, phyreg, &value, &data);
+ }
if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
100, 10000))
return -EBUSY;
+ writel(data, priv->ioaddr + mii_data);
writel(value, priv->ioaddr + mii_address);
if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
@@ -178,7 +198,7 @@ static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr, int phyreg)
return -EBUSY;
/* Read the data from the MII data register */
- data = (int)readl(priv->ioaddr + mii_data);
+ data = (int)readl(priv->ioaddr + mii_data) & MII_DATA_MASK;
return data;
}
@@ -198,8 +218,9 @@ static int stmmac_mdio_write(struct mii_bus *bus, int phyaddr, int phyreg,
struct stmmac_priv *priv = netdev_priv(ndev);
unsigned int mii_address = priv->hw->mii.addr;
unsigned int mii_data = priv->hw->mii.data;
- u32 v;
u32 value = MII_BUSY;
+ int data = phydata;
+ u32 v;
value |= (phyaddr << priv->hw->mii.addr_shift)
& priv->hw->mii.addr_mask;
@@ -207,10 +228,13 @@ static int stmmac_mdio_write(struct mii_bus *bus, int phyaddr, int phyreg,
value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
& priv->hw->mii.clk_csr_mask;
- if (priv->plat->has_gmac4)
+ if (priv->plat->has_gmac4) {
value |= MII_GMAC4_WRITE;
- else
+ if (phyreg & MII_ADDR_C45)
+ stmmac_mdio_c45_setup(priv, phyreg, &value, &data);
+ } else {
value |= MII_WRITE;
+ }
/* Wait until any existing MII operation is complete */
if (readl_poll_timeout(priv->ioaddr + mii_address, v, !(v & MII_BUSY),
@@ -218,7 +242,7 @@ static int stmmac_mdio_write(struct mii_bus *bus, int phyaddr, int phyreg,
return -EBUSY;
/* Set the MII address register to write */
- writel(phydata, priv->ioaddr + mii_data);
+ writel(data, priv->ioaddr + mii_data);
writel(value, priv->ioaddr + mii_address);
/* Wait until any existing MII operation is complete */
diff --git a/include/linux/phy.h b/include/linux/phy.h
index d0af7d37fdf9..1739c6dc470e 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -195,6 +195,8 @@ static inline const char *phy_modes(phy_interface_t interface)
/* Or MII_ADDR_C45 into regnum for read/write on mii_bus to enable the 21 bit
IEEE 802.3ae clause 45 addressing mode used by 10GIGE phy chips. */
#define MII_ADDR_C45 (1<<30)
+#define MII_DEVADDR_C45_SHIFT 16
+#define MII_REGADDR_C45_MASK GENMASK(15, 0)
struct device;
struct phylink;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net 2/2] macsec: fix checksumming after decryption
From: Willem de Bruijn @ 2019-07-03 1:47 UTC (permalink / raw)
To: Andreas Steinmetz; +Cc: Willem de Bruijn, Network Development, Sabrina Dubroca
In-Reply-To: <a7c67e7e22103fc7cf02c520a8b42d9aa525700f.camel@domdv.de>
On Tue, Jul 2, 2019 at 3:48 PM Andreas Steinmetz <ast@domdv.de> wrote:
>
> On Tue, 2019-07-02 at 10:35 -0400, Willem de Bruijn wrote:
> > On Tue, Jul 2, 2019 at 12:25 AM Andreas Steinmetz <ast@domdv.de> wrote:
> > > On Sun, 2019-06-30 at 21:47 -0400, Willem de Bruijn wrote:
> > > > On Sun, Jun 30, 2019 at 4:48 PM Andreas Steinmetz <ast@domdv.de>
> > > > wrote:
> > > > > Fix checksumming after decryption.
> > > > >
> > > > > Signed-off-by: Andreas Steinmetz <ast@domdv.de>
> > > > >
> > > > > --- a/drivers/net/macsec.c 2019-06-30 22:14:10.250285314 +0200
> > > > > +++ b/drivers/net/macsec.c 2019-06-30 22:15:11.931230417 +0200
> > > > > @@ -869,6 +869,7 @@
> > > > >
> > > > > static void macsec_finalize_skb(struct sk_buff *skb, u8 icv_len,
> > > > > u8 hdr_len)
> > > > > {
> > > > > + skb->ip_summed = CHECKSUM_NONE;
> > > > > memmove(skb->data + hdr_len, skb->data, 2 * ETH_ALEN);
> > > > > skb_pull(skb, hdr_len);
> > > > > pskb_trim_unique(skb, skb->len - icv_len);
> > > >
> > > > Does this belong in macset_reset_skb?
> > >
> > > Putting this in macsec_reset_skb would then miss out the "nosci:" part
> > > of the RX path in macsec_handle_frame().
> >
> > It is called on each nskb before calling netif_rx.
> >
> > It indeed is not called when returning RX_HANDLER_PASS, but that is correct?
>
> This is correct. Packets passed on with RX_HANDLER_PASS are either not for this
> driver or the special case of being destined for a KaY and in this case being
> the MACsec ethernet protocol and thus not IP, so no checksumming.
So this could have been set in macsec_reset_skb, then? As all relevant cases
call it. Anyway, it's not very important and already merged.
^ permalink raw reply
* Validation of forward_delay seems wrong...
From: Andrew Lunn @ 2019-07-02 20:47 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: Roopa Prabhu, bridge, netdev
Hi Nikolay
The man page says that the bridge forward_delay is in units of
seconds, and should be between 2 and 30.
I've tested on a couple of different kernel versions, and this appears
to be not working correctly:
ip link set br0 type bridge forward_delay 2
RTNETLINK answers: Numerical result out of range
ip link set br0 type bridge forward_delay 199
RTNETLINK answers: Numerical result out of range
ip link set br0 type bridge forward_delay 200
#
ip link set br0 type bridge forward_delay 3000
#
ip link set br0 type bridge forward_delay 3001
RTNETLINK answers: Numerical result out of range
I've not checked what delay is actually being used here, but clearly
something is mixed up.
grep HZ .config
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HZ_FIXED=0
CONFIG_HZ_100=y
# CONFIG_HZ_200 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_500 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
Thanks
Andrew
^ permalink raw reply
* Re: Validation of forward_delay seems wrong...
From: Andrew Lunn @ 2019-07-02 21:35 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: Roopa Prabhu, bridge, netdev
In-Reply-To: <55f24bfb-4239-dda8-24f8-26b6b2fa9f9e@cumulusnetworks.com>
> Hi Andrew,
> The man page is wrong, these have been in USER_HZ scaled clock_t format from the beginning.
> TBH a lot of the time/delay bridge config options are messed up like that.
Hi Nikola
Yes, that is a mess.
arch/alpha/include/asm/param.h:# define USER_HZ 1024
arch/ia64/include/asm/param.h:# define USER_HZ HZ
include/asm-generic/param.h:# define USER_HZ 100
And ia64 does
# define HZ CONFIG_HZ
So it seems pretty hard for user space to get this right in a generic
fashion.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v6 05/15] ethtool: helper functions for netlink interface
From: Jakub Kicinski @ 2019-07-03 1:37 UTC (permalink / raw)
To: Michal Kubecek
Cc: David Miller, netdev, Jiri Pirko, Andrew Lunn, Florian Fainelli,
John Linville, Stephen Hemminger, Johannes Berg, linux-kernel
In-Reply-To: <44957b13e8edbced71aca893908d184eb9e57341.1562067622.git.mkubecek@suse.cz>
On Tue, 2 Jul 2019 13:50:04 +0200 (CEST), Michal Kubecek wrote:
> Add common request/reply header definition and helpers to parse request
> header and fill reply header. Provide ethnl_update_* helpers to update
> structure members from request attributes (to be used for *_SET requests).
>
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
> diff --git a/net/ethtool/netlink.c b/net/ethtool/netlink.c
> index 3c98b41f04e5..e13f29bbd625 100644
> --- a/net/ethtool/netlink.c
> +++ b/net/ethtool/netlink.c
> @@ -1,8 +1,181 @@
> // SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
>
> +#include <net/sock.h>
> #include <linux/ethtool_netlink.h>
> #include "netlink.h"
>
> +static struct genl_family ethtool_genl_family;
> +
> +static const struct nla_policy dflt_header_policy[ETHTOOL_A_HEADER_MAX + 1] = {
> + [ETHTOOL_A_HEADER_UNSPEC] = { .type = NLA_REJECT },
I think we want strict checking on all new netlink interfaces, and
unfortunately that feature is opt-in.. so you need to add:
.strict_start_type = ETHTOOL_A_HEADER_UNSPEC + 1
To the first attr.
> + [ETHTOOL_A_HEADER_DEV_INDEX] = { .type = NLA_U32 },
> + [ETHTOOL_A_HEADER_DEV_NAME] = { .type = NLA_NUL_STRING,
> + .len = IFNAMSIZ - 1 },
> + [ETHTOOL_A_HEADER_INFOMASK] = { .type = NLA_U32 },
> + [ETHTOOL_A_HEADER_GFLAGS] = { .type = NLA_U32 },
> + [ETHTOOL_A_HEADER_RFLAGS] = { .type = NLA_U32 },
> +};
^ permalink raw reply
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Kees Cook @ 2019-07-02 18:24 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Song Liu, linux-security@vger.kernel.org, Networking, bpf,
Alexei Starovoitov, Daniel Borkmann, Kernel Team, Lorenz Bauer,
Jann Horn, Greg KH, Linux API
In-Reply-To: <CALCETrWBWbNFJvsTCeUchu3BZJ3SH3dvtXLUB2EhnPrzFfsLNA@mail.gmail.com>
On Mon, Jul 01, 2019 at 06:59:13PM -0700, Andy Lutomirski wrote:
> I think I'm understanding your motivation. You're not trying to make
> bpf() generically usable without privilege -- you're trying to create
> a way to allow certain users to access dangerous bpf functionality
> within some limits.
>
> That's a perfectly fine goal, but I think you're reinventing the
> wheel, and the wheel you're reinventing is quite complicated and
> already exists. I think you should teach bpftool to be secure when
> installed setuid root or with fscaps enabled and put your policy in
> bpftool. If you want to harden this a little bit, it would seem
> entirely reasonable to add a new CAP_BPF_ADMIN and change some, but
> not all, of the capable() checks to check CAP_BPF_ADMIN instead of the
> capabilities that they currently check.
If finer grained controls are wanted, it does seem like the /dev/bpf
path makes the most sense. open, request abilities, use fd. The open can
be mediated by DAC and LSM. The request can be mediated by LSM. This
provides a way to add policy at the LSM level and at the tool level.
(i.e. For tool-level controls: leave LSM wide open, make /dev/bpf owned
by "bpfadmin" and bpftool becomes setuid "bpfadmin". For fine-grained
controls, leave /dev/bpf wide open and add policy to SELinux, etc.)
With only a new CAP, you don't get the fine-grained controls. (The
"request abilities" part is the key there.)
--
Kees Cook
^ permalink raw reply
* Re: [PATCH net-next 3/7] net/rds: Wait for the FRMR_IS_FREE (or FRMR_IS_STALE) transition after posting IB_WR_LOCAL_INV
From: Gerd Rausch @ 2019-07-02 21:05 UTC (permalink / raw)
To: santosh.shilimkar, netdev; +Cc: David Miller
In-Reply-To: <d7ab5505-92e5-888c-a230-77bce3540261@oracle.com>
On 02/07/2019 09.49, santosh.shilimkar@oracle.com wrote:
> On 7/1/19 10:11 PM, Gerd Rausch wrote:
>> For the registration work-requests there is a benefit to wait a short
>> amount of time only (the trade-off described in patch #1 of this series).
>>
> Actually we should just switch this code to what Avinash has
> finally made in downstream code. That keeps the RDS_GET_MR
> semantics and makes sure MR is really valid before handing over
> the key to userland. There is no need for any timeout
> for registration case.
>
What do you call "RDS_GET_MR" semantics?
The purpose of waiting for a IB_WR_REG_MR request to complete
(inside rds_ib_post_reg_frmr) is in fact to make sure
the memory region is valid.
Regardless of this being true after a specific time-out,
or an infinite timeout.
For the non-infinite time-out case, there is a check if the request
was handled by the firmware.
And if a time-out occurred and the firmware didn't handle the request,
function "rds_ib_post_reg_frmr" will return -EBUSY.
>> Actually, no:
>> Socket option RDS_GET_MR wasn't even in the code-path of the
>> tests I performed:
>>
>> It were there RDS_CMSG_RDMA_MAP / RDS_CMSG_RDMA_DEST control
>> messages that ended up calling '__rds_rdma_map".
>>
> What option did you use ? Default option with rds-stress is
> RDS_GET_MR and hence the question.
>
Not true!:
Socket option RDS_GET_MR is only used by "rds-stress"
if it is invoked with "--rdma-use-get-mr <non-zero-value>".
Verify this with the following patch applied to rds-tools-2.0.7-1.18:
--- a/rds-stress.c
+++ b/rds-stress.c
@@ -705,6 +705,7 @@ static uint64_t get_rdma_key(int fd, uint64_t addr, uint32_t size)
if (opt.rdma_use_once)
mr_args.flags |= RDS_RDMA_USE_ONCE;
+ abort();
if (setsockopt(fd, sol, RDS_GET_MR, &mr_args, sizeof(mr_args)))
die_errno("setsockopt(RDS_GET_MR) failed (%u allocated)", mrs_allocated);
And why is socket option RDS_GET_MR a subject of this discussion?
The proposed patch suggests to wait for a firmware response in handling
_all_ cases that end up in "rds_ib_post_reg_frmr", issuing a "IB_WR_REG_MR" request.
It doesn't matter where they came from:
Whether they came from an RDS_GET_MR socket option, or a RDS_CMSG_RDMA_MAP:
They all go through "__rds_rdma_map" and end up calling "rds_ib_get_mr".
How is socket option RDS_GET_MR special with regards to this proposed fix?
>> I don't understand, please elaborate:
>> a) Are you saying this issue should not be fixed?
>> b) Or are you suggesting to replace this fix with a different fix?
>> If it's the later, please point out what you have in mind.
>> c) ???
>>
> All am saying is the code got changed for good reason and that changed
> code makes some of these race conditions possibly not applicable.
I don't understand this. Please elaborate.
> So instead of these timeout fixes, am suggesting to use that
> code as fix. At least test it with those changes and see whats
> the behavior.
>
Are you suggesting to
a) Not fix this bug right now and wait until some later point in time
b) Use a different fix. If you've got a different fix, please share.
And besides these options, is there anything wrong with this fix
(other than the discussion of what the timeout value ought to be,
which we can address)?
Thanks,
Gerd
^ permalink raw reply
* Re: [PATCH net 0/6] gtp: fix several bugs
From: Taehee Yoo @ 2019-07-03 1:31 UTC (permalink / raw)
To: Harald Welte
Cc: David Miller, Pablo Neira Ayuso, Pau Espin, osmocom-net-gprs,
Netdev
In-Reply-To: <20190703010856.GA11901@nataraja>
Hi Harald,
On Wed, 3 Jul 2019 at 09:10, Harald Welte <laforge@gnumonks.org> wrote:
>
> Hi Taehee,
>
> On Wed, Jul 03, 2019 at 12:20:34AM +0900, Taehee Yoo wrote:
> > This patch series fixes several bugs in the gtp module.
>
> thanks a lot for your patches, they are much appreciated.
>
> They look valid to me after a brief initial review.
>
> However, I'm currently on holidays and don't have the ability to test
> any patches until my return on July 17. Maybe Pablo and/or Pau can have
> a look meanwhile? Thanks in advance.
>
Thank you for letting me know.
Thanks a lot!
> Regards,
> Harald
> --
> - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* Re: [PATCH net-next 3/7] net/rds: Wait for the FRMR_IS_FREE (or FRMR_IS_STALE) transition after posting IB_WR_LOCAL_INV
From: Gerd Rausch @ 2019-07-02 22:12 UTC (permalink / raw)
To: santosh.shilimkar, netdev; +Cc: David Miller
In-Reply-To: <1759bca6-4511-6cd9-ab5d-8c9c30e5db67@oracle.com>
On 02/07/2019 14.18, santosh.shilimkar@oracle.com wrote:
> On 7/2/19 2:05 PM, Gerd Rausch wrote:
>> What do you call "RDS_GET_MR" semantics?
>>
> Its a blocking socket call. Meaning after this call return to the
> user, the key must be valid. With async registration that can't be
> guaranteed.
>
If the "IB_WR_REG_MR" operation does not complete successfully within
the given (to-be-discussed?) timeout, "rds_ib_post_reg_frmr" will return
"-EBUSY".
And that should propagate up the entire stack and make its way into
"setsockopt" returning "-1" with "errno == EBUSY".
Do you see a problem with this approach?
Did you observe a situation where this did not work?
Are you saying that no timeout, no matter how large, is large enough?
If that's the case, we can consider turning the "wait_event_timeout"
into a "wait_event".
>> Are you suggesting to
>> a) Not fix this bug right now and wait until some later point in time
> When did I say that ? I said have you explored alternate approach to
> fix the issue and if not could you try it out.
>
Why explore an alternate approach?
Do you see a problem with the proposed patch (other than the choice of timeout)?
>> b) Use a different fix. If you've got a different fix, please share.
>>
> I don't but its a review of the fix and possible alternate needs to
> be discussed. It is not like take my fix or provide an alternate fix.
>
As it is, the upstream implementation of RDS does not work.
IMO, it is desirable to make it work.
If there are future and better implementation of existing functionality
that is fine.
That should not preclude us from fixing what is broken as soon as we can.
>> And besides these options, is there anything wrong with this fix
>> (other than the discussion of what the timeout value ought to be,
>> which we can address)?
>>
> That timeout is a problem because it doesn't guarantee the failure
> of operation since its an asyn operation for registration.
The fact that the work-request is asynchroneous is precisely what
makes it necessary to wait for the completion before moving on.
That is the proposed change of waiting for the completion
(or a time-out to put an upper bound to the wait)
does.
Replace the "wait_event_timeout" mentally with a "wait_event":
In that case, the process will be stuck in the corresponding function
(e.g. "rds_ib_post_reg_frmr") until the completion handler has occurred
and the "wake_up" call was issued.
It is the job of the "rds_ib_mr_cqe_handler" handler to inspect
the status of the work-completion and set the "fr_state" accordingly.
As far as I can tell, that is happening.
The debate on whether to use a "wait_event" or "wait_event_timeout"
is strictly a debate over whether or not there should
be an upper bound for the firmware to respond.
If there is not: It should be "wait_event".
If there is: It should be "wait_event_timeout", and we need to specify
what that upper bound is.
> Instead of timing out if you poll the CQ for that operation completion, it
> makes it full proof. That is the change Avinash has done iirc and
> am requesting to look at that fix.
>
The "wake_up" call is issued from within the completion handler.
The completion handler "rds_ib_mr_cqe_handler" is called upon
handling the work-completions coming out of "ib_poll_cq".
That is necessary in order to check the status of the completion.
There are many changes that were done in the Oracle internal repository
(including changes that Avinash had done),
that we will go through in order to see what needs to be fixed in the
upstream version of RDS.
But unless you can see something that is wrong with this proposed fix,
I would suggest we don't leave the upstream RDS broken for extended
periods of time, but rather fix it.
> Other 5 fixes from the series looks fine.
>
Thank you,
Gerd
^ permalink raw reply
* Re: [PATCH net-next v6 04/15] ethtool: introduce ethtool netlink interface
From: Jakub Kicinski @ 2019-07-03 1:29 UTC (permalink / raw)
To: Michal Kubecek
Cc: David Miller, netdev, Jiri Pirko, Andrew Lunn, Florian Fainelli,
John Linville, Stephen Hemminger, Johannes Berg, linux-kernel
In-Reply-To: <e7fa3ad7e9cf4d7a8f9a2085e3166f7260845b0a.1562067622.git.mkubecek@suse.cz>
On Tue, 2 Jul 2019 13:49:59 +0200 (CEST), Michal Kubecek wrote:
> diff --git a/Documentation/networking/ethtool-netlink.txt b/Documentation/networking/ethtool-netlink.txt
> new file mode 100644
> index 000000000000..97c369aa290b
> --- /dev/null
> +++ b/Documentation/networking/ethtool-netlink.txt
> @@ -0,0 +1,208 @@
> + Netlink interface for ethtool
> + =============================
> +
> +
> +Basic information
> +-----------------
Probably not a blocker for initial merging, but please note a TODO to
convert the documentation to ReST.
^ permalink raw reply
* Re: net: micrel: confusion about phyids used in driver
From: Uwe Kleine-König @ 2019-07-02 20:31 UTC (permalink / raw)
To: Yuiko Oshino
Cc: netdev, Andrew Lunn, Florian Fainelli, kernel, Heiner Kallweit
In-Reply-To: <20190510072243.h6h3bgvr2ovsh5g5@pengutronix.de>
Hello Yuiko Oshino,
On Fri, May 10, 2019 at 09:22:43AM +0200, Uwe Kleine-König wrote:
> On Thu, May 09, 2019 at 11:07:45PM +0200, Andrew Lunn wrote:
> > On Thu, May 09, 2019 at 10:55:29PM +0200, Heiner Kallweit wrote:
> > > On 09.05.2019 22:29, Uwe Kleine-König wrote:
> > > > I have a board here that has a KSZ8051MLL (datasheet:
> > > > http://ww1.microchip.com/downloads/en/DeviceDoc/ksz8051mll.pdf, phyid:
> > > > 0x0022155x) assembled. The actual phyid is 0x00221556.
> > >
> > > I think the datasheets are the source of the confusion. If the
> > > datasheets for different chips list 0x0022155x as PHYID each, and
> > > authors of support for additional chips don't check the existing code,
> > > then happens what happened.
> > >
> > > However it's not a rare exception and not Microchip-specific that
> > > sometimes vendors use the same PHYID for different chips.
>
> From the vendor's POV it is even sensible to reuse the phy IDs iff the
> chips are "compatible".
>
> Assuming that the last nibble of the phy ID actually helps to
> distinguish the different (not completely) compatible chips, we need
> some more detailed information than available in the data sheets I have.
> There is one person in the recipents of this mail with an @microchip.com
> address (hint, hint!).
can you give some input here or forward to a person who can?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox