* [PATCH v2 net 1/7] net: aquantia: Fix hardware reset when SPI may rarely hangup
From: Igor Russkikh @ 2018-03-20 11:40 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, David Arcari, Pavel Belous, Igor Russkikh
In-Reply-To: <cover.1521544563.git.igor.russkikh@aquantia.com>
Under some circumstances (notably using thunderbolt interface) SPI
on chip reset may be in active transaction.
Here we forcibly cleanup SPI to prevent possible hangups.
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
---
.../ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
index 967f0fd..fcb3279 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
@@ -79,16 +79,15 @@ int hw_atl_utils_initfw(struct aq_hw_s *self, const struct aq_fw_ops **fw_ops)
static int hw_atl_utils_soft_reset_flb(struct aq_hw_s *self)
{
+ u32 gsr, val;
int k = 0;
- u32 gsr;
aq_hw_write_reg(self, 0x404, 0x40e1);
AQ_HW_SLEEP(50);
/* Cleanup SPI */
- aq_hw_write_reg(self, 0x534, 0xA0);
- aq_hw_write_reg(self, 0x100, 0x9F);
- aq_hw_write_reg(self, 0x100, 0x809F);
+ val = aq_hw_read_reg(self, 0x53C);
+ aq_hw_write_reg(self, 0x53C, val | 0x10);
gsr = aq_hw_read_reg(self, HW_ATL_GLB_SOFT_RES_ADR);
aq_hw_write_reg(self, HW_ATL_GLB_SOFT_RES_ADR, (gsr & 0xBFFF) | 0x8000);
@@ -97,7 +96,14 @@ static int hw_atl_utils_soft_reset_flb(struct aq_hw_s *self)
aq_hw_write_reg(self, 0x404, 0x80e0);
aq_hw_write_reg(self, 0x32a8, 0x0);
aq_hw_write_reg(self, 0x520, 0x1);
+
+ /* Reset SPI again because of possible interrupted SPI burst */
+ val = aq_hw_read_reg(self, 0x53C);
+ aq_hw_write_reg(self, 0x53C, val | 0x10);
AQ_HW_SLEEP(10);
+ /* Clear SPI reset state */
+ aq_hw_write_reg(self, 0x53C, val & ~0x10);
+
aq_hw_write_reg(self, 0x404, 0x180e0);
for (k = 0; k < 1000; k++) {
@@ -147,7 +153,7 @@ static int hw_atl_utils_soft_reset_flb(struct aq_hw_s *self)
static int hw_atl_utils_soft_reset_rbl(struct aq_hw_s *self)
{
- u32 gsr, rbl_status;
+ u32 gsr, val, rbl_status;
int k;
aq_hw_write_reg(self, 0x404, 0x40e1);
@@ -157,6 +163,10 @@ static int hw_atl_utils_soft_reset_rbl(struct aq_hw_s *self)
/* Alter RBL status */
aq_hw_write_reg(self, 0x388, 0xDEAD);
+ /* Cleanup SPI */
+ val = aq_hw_read_reg(self, 0x53C);
+ aq_hw_write_reg(self, 0x53C, val | 0x10);
+
/* Global software reset*/
hw_atl_rx_rx_reg_res_dis_set(self, 0U);
hw_atl_tx_tx_reg_res_dis_set(self, 0U);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 net 2/7] net: aquantia: Fix a regression with reset on old firmware
From: Igor Russkikh @ 2018-03-20 11:40 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, David Arcari, Pavel Belous, Igor Russkikh
In-Reply-To: <cover.1521544563.git.igor.russkikh@aquantia.com>
FW 1.5.58 and below needs a fixed delay even after 0x18 register
is filled. Otherwise, setting MPI_INIT state too fast causes
traffic hang.
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
---
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
index fcb3279..dcb27bc 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
@@ -147,6 +147,8 @@ static int hw_atl_utils_soft_reset_flb(struct aq_hw_s *self)
aq_pr_err("FW kickstart failed\n");
return -EIO;
}
+ /* Old FW requires fixed delay after init */
+ AQ_HW_SLEEP(15);
return 0;
}
@@ -214,6 +216,8 @@ static int hw_atl_utils_soft_reset_rbl(struct aq_hw_s *self)
aq_pr_err("FW kickstart failed\n");
return -EIO;
}
+ /* Old FW requires fixed delay after init */
+ AQ_HW_SLEEP(15);
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 net 3/7] net: aquantia: Change inefficient wait loop on fw data reads
From: Igor Russkikh @ 2018-03-20 11:40 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, David Arcari, Pavel Belous, Igor Russkikh
In-Reply-To: <cover.1521544563.git.igor.russkikh@aquantia.com>
B1 hardware changes behavior of mailbox interface, it has busy bit
always raised. Data ready condition should be detected by increment
of address register.
Old code has empty `for` loop, and that caused cpu overloads on B1
hardware. aq_nic_service_timer_cb consumed ~100ms because of that.
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
---
.../aquantia/atlantic/hw_atl/hw_atl_utils.c | 42 ++++++++++++++--------
.../aquantia/atlantic/hw_atl/hw_atl_utils.h | 1 +
2 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
index dcb27bc..d3b847e 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
@@ -21,6 +21,10 @@
#define HW_ATL_UCP_0X370_REG 0x0370U
+#define HW_ATL_MIF_CMD 0x0200U
+#define HW_ATL_MIF_ADDR 0x0208U
+#define HW_ATL_MIF_VAL 0x020CU
+
#define HW_ATL_FW_SM_RAM 0x2U
#define HW_ATL_MPI_FW_VERSION 0x18
#define HW_ATL_MPI_CONTROL_ADR 0x0368U
@@ -269,18 +273,22 @@ int hw_atl_utils_fw_downld_dwords(struct aq_hw_s *self, u32 a,
}
}
- aq_hw_write_reg(self, 0x00000208U, a);
-
- for (++cnt; --cnt;) {
- u32 i = 0U;
+ aq_hw_write_reg(self, HW_ATL_MIF_ADDR, a);
- aq_hw_write_reg(self, 0x00000200U, 0x00008000U);
+ for (++cnt; --cnt && !err;) {
+ aq_hw_write_reg(self, HW_ATL_MIF_CMD, 0x00008000U);
- for (i = 1024U;
- (0x100U & aq_hw_read_reg(self, 0x00000200U)) && --i;) {
- }
+ if (IS_CHIP_FEATURE(REVISION_B1))
+ AQ_HW_WAIT_FOR(a != aq_hw_read_reg(self,
+ HW_ATL_MIF_ADDR),
+ 1, 1000U);
+ else
+ AQ_HW_WAIT_FOR(!(0x100 & aq_hw_read_reg(self,
+ HW_ATL_MIF_CMD)),
+ 1, 1000U);
- *(p++) = aq_hw_read_reg(self, 0x0000020CU);
+ *(p++) = aq_hw_read_reg(self, HW_ATL_MIF_VAL);
+ a += 4;
}
hw_atl_reg_glb_cpu_sem_set(self, 1U, HW_ATL_FW_SM_RAM);
@@ -676,14 +684,18 @@ void hw_atl_utils_hw_chip_features_init(struct aq_hw_s *self, u32 *p)
u32 val = hw_atl_reg_glb_mif_id_get(self);
u32 mif_rev = val & 0xFFU;
- if ((3U & mif_rev) == 1U) {
- chip_features |=
- HAL_ATLANTIC_UTILS_CHIP_REVISION_A0 |
+ if ((0xFU & mif_rev) == 1U) {
+ chip_features |= HAL_ATLANTIC_UTILS_CHIP_REVISION_A0 |
HAL_ATLANTIC_UTILS_CHIP_MPI_AQ |
HAL_ATLANTIC_UTILS_CHIP_MIPS;
- } else if ((3U & mif_rev) == 2U) {
- chip_features |=
- HAL_ATLANTIC_UTILS_CHIP_REVISION_B0 |
+ } else if ((0xFU & mif_rev) == 2U) {
+ chip_features |= HAL_ATLANTIC_UTILS_CHIP_REVISION_B0 |
+ HAL_ATLANTIC_UTILS_CHIP_MPI_AQ |
+ HAL_ATLANTIC_UTILS_CHIP_MIPS |
+ HAL_ATLANTIC_UTILS_CHIP_TPO2 |
+ HAL_ATLANTIC_UTILS_CHIP_RPF2;
+ } else if ((0xFU & mif_rev) == 0xAU) {
+ chip_features |= HAL_ATLANTIC_UTILS_CHIP_REVISION_B1 |
HAL_ATLANTIC_UTILS_CHIP_MPI_AQ |
HAL_ATLANTIC_UTILS_CHIP_MIPS |
HAL_ATLANTIC_UTILS_CHIP_TPO2 |
diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
index 2c69094..cd8f18f 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.h
@@ -161,6 +161,7 @@ struct __packed hw_aq_atl_utils_mbox {
#define HAL_ATLANTIC_UTILS_CHIP_MPI_AQ 0x00000010U
#define HAL_ATLANTIC_UTILS_CHIP_REVISION_A0 0x01000000U
#define HAL_ATLANTIC_UTILS_CHIP_REVISION_B0 0x02000000U
+#define HAL_ATLANTIC_UTILS_CHIP_REVISION_B1 0x04000000U
#define IS_CHIP_FEATURE(_F_) (HAL_ATLANTIC_UTILS_CHIP_##_F_ & \
self->chip_features)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 net 4/7] net: aquantia: Add tx clean budget and valid budget handling logic
From: Igor Russkikh @ 2018-03-20 11:40 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, David Arcari, Pavel Belous, Igor Russkikh
In-Reply-To: <cover.1521544563.git.igor.russkikh@aquantia.com>
We should report to napi full budget only when we have more job to do.
Before this fix, on any tx queue cleanup we forced napi to do poll again.
Thats a waste of cpu resources and caused storming with napi polls when
there was at least one tx on each interrupt.
With this fix we report full budget only when there is more job on TX
to do. Or, as before, when rx budget was fully consumed.
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
---
drivers/net/ethernet/aquantia/atlantic/aq_cfg.h | 2 ++
drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 7 +++++--
drivers/net/ethernet/aquantia/atlantic/aq_ring.h | 2 +-
drivers/net/ethernet/aquantia/atlantic/aq_vec.c | 11 +++++------
4 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_cfg.h b/drivers/net/ethernet/aquantia/atlantic/aq_cfg.h
index 0b49f1a..fc73831 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_cfg.h
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_cfg.h
@@ -36,6 +36,8 @@
#define AQ_CFG_TX_FRAME_MAX (16U * 1024U)
#define AQ_CFG_RX_FRAME_MAX (4U * 1024U)
+#define AQ_CFG_TX_CLEAN_BUDGET 256U
+
/* LRO */
#define AQ_CFG_IS_LRO_DEF 1U
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
index 0be6a11..b5f1f62 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
@@ -136,11 +136,12 @@ void aq_ring_queue_stop(struct aq_ring_s *ring)
netif_stop_subqueue(ndev, ring->idx);
}
-void aq_ring_tx_clean(struct aq_ring_s *self)
+bool aq_ring_tx_clean(struct aq_ring_s *self)
{
struct device *dev = aq_nic_get_dev(self->aq_nic);
+ unsigned int budget = AQ_CFG_TX_CLEAN_BUDGET;
- for (; self->sw_head != self->hw_head;
+ for (; self->sw_head != self->hw_head && budget--;
self->sw_head = aq_ring_next_dx(self, self->sw_head)) {
struct aq_ring_buff_s *buff = &self->buff_ring[self->sw_head];
@@ -167,6 +168,8 @@ void aq_ring_tx_clean(struct aq_ring_s *self)
buff->pa = 0U;
buff->eop_index = 0xffffU;
}
+
+ return !!budget;
}
#define AQ_SKB_ALIGN SKB_DATA_ALIGN(sizeof(struct skb_shared_info))
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ring.h b/drivers/net/ethernet/aquantia/atlantic/aq_ring.h
index 965fae0..ac1329f 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_ring.h
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_ring.h
@@ -153,7 +153,7 @@ void aq_ring_free(struct aq_ring_s *self);
void aq_ring_update_queue_state(struct aq_ring_s *ring);
void aq_ring_queue_wake(struct aq_ring_s *ring);
void aq_ring_queue_stop(struct aq_ring_s *ring);
-void aq_ring_tx_clean(struct aq_ring_s *self);
+bool aq_ring_tx_clean(struct aq_ring_s *self);
int aq_ring_rx_clean(struct aq_ring_s *self,
struct napi_struct *napi,
int *work_done,
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_vec.c b/drivers/net/ethernet/aquantia/atlantic/aq_vec.c
index f890b8a..d335c33 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_vec.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_vec.c
@@ -35,12 +35,12 @@ struct aq_vec_s {
static int aq_vec_poll(struct napi_struct *napi, int budget)
{
struct aq_vec_s *self = container_of(napi, struct aq_vec_s, napi);
+ unsigned int sw_tail_old = 0U;
struct aq_ring_s *ring = NULL;
+ bool was_tx_cleaned = true;
+ unsigned int i = 0U;
int work_done = 0;
int err = 0;
- unsigned int i = 0U;
- unsigned int sw_tail_old = 0U;
- bool was_tx_cleaned = false;
if (!self) {
err = -EINVAL;
@@ -57,9 +57,8 @@ static int aq_vec_poll(struct napi_struct *napi, int budget)
if (ring[AQ_VEC_TX_ID].sw_head !=
ring[AQ_VEC_TX_ID].hw_head) {
- aq_ring_tx_clean(&ring[AQ_VEC_TX_ID]);
+ was_tx_cleaned = aq_ring_tx_clean(&ring[AQ_VEC_TX_ID]);
aq_ring_update_queue_state(&ring[AQ_VEC_TX_ID]);
- was_tx_cleaned = true;
}
err = self->aq_hw_ops->hw_ring_rx_receive(self->aq_hw,
@@ -90,7 +89,7 @@ static int aq_vec_poll(struct napi_struct *napi, int budget)
}
}
- if (was_tx_cleaned)
+ if (!was_tx_cleaned)
work_done = budget;
if (work_done < budget) {
--
2.7.4
^ permalink raw reply related
* [PATCH v2 net 5/7] net: aquantia: Allow live mac address changes
From: Igor Russkikh @ 2018-03-20 11:40 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, David Arcari, Pavel Belous, Igor Russkikh
In-Reply-To: <cover.1521544563.git.igor.russkikh@aquantia.com>
There is nothing prevents us from changing MAC on the running interface.
Allow this with ndev priv flag.
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
---
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
index ebbaf63..34120d5 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
@@ -247,6 +247,8 @@ void aq_nic_ndev_init(struct aq_nic_s *self)
self->ndev->hw_features |= aq_hw_caps->hw_features;
self->ndev->features = aq_hw_caps->hw_features;
self->ndev->priv_flags = aq_hw_caps->hw_priv_flags;
+ self->ndev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+
self->ndev->mtu = aq_nic_cfg->mtu - ETH_HLEN;
self->ndev->max_mtu = aq_hw_caps->mtu - ETH_FCS_LEN - ETH_HLEN;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 net 6/7] net: aquantia: Implement pci shutdown callback
From: Igor Russkikh @ 2018-03-20 11:40 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, David Arcari, Pavel Belous, Igor Russkikh
In-Reply-To: <cover.1521544563.git.igor.russkikh@aquantia.com>
We should close link and all NIC operations during shutdown.
On some systems graceful reboot never closes NIC interface on its own,
but only indicates pci device shutdown. Without explicit handler, NIC
rx rings continued to transfer DMA data into prepared buffers while CPU
rebooted already. That caused memory corruptions on soft reboot.
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
---
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 20 ++++++++++++++++++++
drivers/net/ethernet/aquantia/atlantic/aq_nic.h | 1 +
drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c | 15 +++++++++++++++
3 files changed, 36 insertions(+)
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
index 34120d5..c96a921 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
@@ -939,3 +939,23 @@ int aq_nic_change_pm_state(struct aq_nic_s *self, pm_message_t *pm_msg)
out:
return err;
}
+
+void aq_nic_shutdown(struct aq_nic_s *self)
+{
+ int err = 0;
+
+ if (!self->ndev)
+ return;
+
+ rtnl_lock();
+
+ netif_device_detach(self->ndev);
+
+ err = aq_nic_stop(self);
+ if (err < 0)
+ goto err_exit;
+ aq_nic_deinit(self);
+
+err_exit:
+ rtnl_unlock();
+}
\ No newline at end of file
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.h b/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
index d16b0f1..219b550 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
@@ -118,5 +118,6 @@ struct aq_nic_cfg_s *aq_nic_get_cfg(struct aq_nic_s *self);
u32 aq_nic_get_fw_version(struct aq_nic_s *self);
int aq_nic_change_pm_state(struct aq_nic_s *self, pm_message_t *pm_msg);
int aq_nic_update_interrupt_moderation_settings(struct aq_nic_s *self);
+void aq_nic_shutdown(struct aq_nic_s *self);
#endif /* AQ_NIC_H */
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c b/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
index 87c4308..ecc6306 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_pci_func.c
@@ -323,6 +323,20 @@ static void aq_pci_remove(struct pci_dev *pdev)
pci_disable_device(pdev);
}
+static void aq_pci_shutdown(struct pci_dev *pdev)
+{
+ struct aq_nic_s *self = pci_get_drvdata(pdev);
+
+ aq_nic_shutdown(self);
+
+ pci_disable_device(pdev);
+
+ if (system_state == SYSTEM_POWER_OFF) {
+ pci_wake_from_d3(pdev, false);
+ pci_set_power_state(pdev, PCI_D3hot);
+ }
+}
+
static int aq_pci_suspend(struct pci_dev *pdev, pm_message_t pm_msg)
{
struct aq_nic_s *self = pci_get_drvdata(pdev);
@@ -345,6 +359,7 @@ static struct pci_driver aq_pci_ops = {
.remove = aq_pci_remove,
.suspend = aq_pci_suspend,
.resume = aq_pci_resume,
+ .shutdown = aq_pci_shutdown,
};
module_pci_driver(aq_pci_ops);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 net 7/7] net: aquantia: driver version bump
From: Igor Russkikh @ 2018-03-20 11:40 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, David Arcari, Pavel Belous, Igor Russkikh
In-Reply-To: <cover.1521544563.git.igor.russkikh@aquantia.com>
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
---
drivers/net/ethernet/aquantia/atlantic/ver.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/ver.h b/drivers/net/ethernet/aquantia/atlantic/ver.h
index 5265b93..a445de6 100644
--- a/drivers/net/ethernet/aquantia/atlantic/ver.h
+++ b/drivers/net/ethernet/aquantia/atlantic/ver.h
@@ -13,7 +13,7 @@
#define NIC_MAJOR_DRIVER_VERSION 2
#define NIC_MINOR_DRIVER_VERSION 0
#define NIC_BUILD_DRIVER_VERSION 2
-#define NIC_REVISION_DRIVER_VERSION 0
+#define NIC_REVISION_DRIVER_VERSION 1
#define AQ_CFG_DRV_VERSION_SUFFIX "-kern"
--
2.7.4
^ permalink raw reply related
* Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?
From: Frantisek Rysanek @ 2018-03-20 12:02 UTC (permalink / raw)
To: Andrew Lunn, netdev
In-Reply-To: <20180318144053.GA1188@lunn.ch>
I've taken a look inside the two SFP's.
http://support.fccps.cz/download/adv/frr/ptp/inside_sfps.zip
The uglier, bigger and likely older model (my SFP#2) contains two
PCB's sandwiched, and the key chips are inside the sandwich.
Thus, the photoes don't show much.
The sexier SFP#1 = the one with the Broadcom chip... I believe it's
what it says on the tin:
- the BCM5461SA is directly interfaced to a laser driver chip (pretty
much analog, found a datasheet from Maxim)
- the RX direction seems equally simple, I haven't identified the
chip by the marking, but by pinout it's undoubtedly an RX amplifier
(they're called transimpedance amps, are they?) and, looking at the
PCB traces, its output is directly interfaced to the BCM5461SA.
- there's another BGA chip on the board, smaller than the BCM PHY.
I believe that this is an "SFP MCU". Might be from Maxim or from
someone completely different :-) Not sure whose trademark the "+"
sign is in the chip marking.
I've found a *slightly* more promising "data brief" from Broadcom
for the BCM5461S:
http://infiber.ru/assets/files/products/phy/BCM5461S_Product_Brief.pdf
This one mentions 100Base-FX among the interface formats supported.
I don't believe that the SFP maker would pipe copper MLT3 into the
fiber driver+receiver :-) Note that the block diagram in the Broadcom
PDF contains other minor errors. God knows what the true
functionality is.
The SFP#1 PCB still doesn't look fake to me.
Frank
^ permalink raw reply
* Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?
From: Andrew Lunn @ 2018-03-20 12:09 UTC (permalink / raw)
To: Frantisek Rysanek; +Cc: netdev
In-Reply-To: <5AB0CE14.3307.431B163E@Frantisek.Rysanek.post.cz>
> i2cdetect has found three i2c slaves (identical layout in both SFP's)
> at addresses 0x50, 0x51 and 0x56.
> What are they? EEPROM, DDM and "MDIO over i2c" ?
> The SFP's likely lack a proper SFP MSA data structure.
0x50 and 0x51 are EEPROM like. See drivers/net/phy/sfp.c. The standard
at24 EEPROM driver can also read it. And so should the SFP code in the
igb driver!
> Does this make sense as some sort of proprietary standard
> (Cisco, if I should take the vendor's label at face value),
> or is this likely some "3rd-party innovation thinko", not worth
> implementing?
See if drivers/net/phy/mdio-i2c.c is useful. I'm just guessing here.
Andrew
^ permalink raw reply
* Re: HW question: i210 vs. BCM5461S over SGMII: no response from PHY to MDIO requests?
From: Frantisek Rysanek @ 2018-03-20 12:23 UTC (permalink / raw)
To: Andrew Lunn, netdev
In-Reply-To: <20180320120936.GA19142@lunn.ch>
On 20 Mar 2018 at 13:09, Andrew Lunn wrote:
> > i2cdetect has found three i2c slaves (identical layout in both SFP's)
> > at addresses 0x50, 0x51 and 0x56.
> > What are they? EEPROM, DDM and "MDIO over i2c" ?
> > The SFP's likely lack a proper SFP MSA data structure.
>
> 0x50 and 0x51 are EEPROM like. See drivers/net/phy/sfp.c. The standard
> at24 EEPROM driver can also read it. And so should the SFP code in the
> igb driver!
>
Yes - "should" is the right way to put it.
Looking around, I'm wondering how much general-purpose hardware gets
sold with an Intel gigabit chip and SFP sockets. Note: sockets for
actual SFP's, rather than SFP-size transceivers soldered onboard (and
hardwired in the i210 config EEPROM). It took me quite a while to
find such a board from DeLock.
I mean to say that I doubt how much actual testing on humans this i2c
code has enjoyed :-) but admittedly I'm being cheeky here, I haven't
reviewed that part of the driver.
Frank
^ permalink raw reply
* Re: [PATCH] netfilter: cttimeout: remove VLA usage
From: Pablo Neira Ayuso @ 2018-03-20 12:36 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Jozsef Kadlecsik, Florian Westphal, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel, Kernel Hardening,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20180312231442.GA22071@embeddedgus>
On Mon, Mar 12, 2018 at 06:14:42PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation.
>
> From a security viewpoint, the use of Variable Length Arrays can be
> a vector for stack overflow attacks. Also, in general, as the code
> evolves it is easy to lose track of how big a VLA can get. Thus, we
> can end up having segfaults that are hard to debug.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: nfnetlink_cthelper: Remove VLA usage
From: Pablo Neira Ayuso @ 2018-03-20 12:36 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Jozsef Kadlecsik, Florian Westphal, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel, Kernel Hardening,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20180313002138.GA27280@embeddedgus>
On Mon, Mar 12, 2018 at 07:21:38PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation.
>
> From a security viewpoint, the use of Variable Length Arrays can be
> a vector for stack overflow attacks. Also, in general, as the code
> evolves it is easy to lose track of how big a VLA can get. Thus, we
> can end up having segfaults that are hard to debug.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
also applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] netfilter: nf_tables: remove VLA usage
From: Pablo Neira Ayuso @ 2018-03-20 12:37 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Jozsef Kadlecsik, Florian Westphal, David S. Miller,
netfilter-devel, coreteam, netdev, linux-kernel,
Gustavo A. R. Silva
In-Reply-To: <20180313031617.GA2204@embeddedgus>
On Mon, Mar 12, 2018 at 10:16:17PM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with dynamic memory allocation.
>
> From a security viewpoint, the use of Variable Length Arrays can be
> a vector for stack overflow attacks. Also, in general, as the code
> evolves it is easy to lose track of how big a VLA can get. Thus, we
> can end up having segfaults that are hard to debug.
>
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
Applied, thanks.
^ permalink raw reply
* Re: DTS for our Configuration
From: Andrew Lunn @ 2018-03-20 12:38 UTC (permalink / raw)
To: Alayev Michael; +Cc: netdev@vger.kernel.org, Efter Yoram, Dror Alon
In-Reply-To: <48F7D4389F30BA4383F214EE802BA471017065554B@EXS10.iai.co.il>
On Tue, Mar 20, 2018 at 09:12:18AM +0000, Alayev Michael wrote:
> Hello Andrew,
>
> Please see my comments below in red with some important highlights.
Hi Michael
Please don't use html encrypted emails. Please use quoting as
everybody else does on this list.
> I added the ethernet parameter referencing to gem0. Still cant detect the internal phys and I get kernel panic:
> mdio_bus e000b000.ethernet-ffffffff: /amba/ethernet@e000b000/fixed-link has invalid PHY address
I think this is a problem with the macb driver. To me, it looks like
you are going to have to make some changes to the driver to make this
work. Normally the MDIO bus children are placed within a container
node, often called 'mdio-bus' or simply 'mdio'. See for example
Documentation/devicetree/bindings/net/fsl-fec.txt. The macb driver
does not do this. It passed the main DT node of the device to
of_mdiobus_register(). It then walks all the children assuming they
devices on the MDIO bus. But the first child it finds is the
'fixed-link'. This is not supposed to be a child of the bus, which is
why it goes wrong.
> mv88e6085 e000b000.ethernet-ffffffff:1d: switch 0xa10 detected: Marvell 88E6390X, revision 1
> libphy: mv88e6xxx SMI: probed
> mv88e6085 e000b000.ethernet-ffffffff:1c: switch 0xa10 detected: Marvell 88E6390X, revision 1
> libphy: mv88e6xxx SMI: probed
> mv88e6085: probe of e000b000.ethernet-ffffffff:1c failed with error -16
> mdio_bus e000b000.ethernet-ffffffff: scan phy fixed-link at address 1
> Unable to handle kernel NULL pointer dereference at virtual address 00000004
> pgd = c0004000
> [00000004] *pgd=00000000
> Internal error: Oops - BUG: 17 [#1] PREEMPT SMP ARM
Please include the fill panic details. The stack trace can be very
useful.
Andrew
^ permalink raw reply
* Re: [PATCH] mlx5: Remove call to ida_pre_get
From: Maor Gottlieb @ 2018-03-20 12:41 UTC (permalink / raw)
To: Saeed Mahameed, willy@infradead.org
Cc: Matan Barak, netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
leon@kernel.org
In-Reply-To: <1521516573.32324.63.camel@mellanox.com>
On 3/20/2018 5:29 AM, Saeed Mahameed wrote:
> On Thu, 2018-03-15 at 18:30 -0700, Matthew Wilcox wrote:
>> On Thu, Mar 15, 2018 at 11:58:07PM +0000, Saeed Mahameed wrote:
>>> On Wed, 2018-03-14 at 19:57 -0700, Matthew Wilcox wrote:
>>>> From: Matthew Wilcox <mawilcox@microsoft.com>
>>>>
>>>> The mlx5 driver calls ida_pre_get() in a loop for no readily
>>>> apparent
>>>> reason. The driver uses ida_simple_get() which will call
>>>> ida_pre_get()
>>>> by itself and there's no need to use ida_pre_get() unless using
>>>> ida_get_new().
>>>>
>>> Hi Matthew,
>>>
>>> Is this is causing any issues ? or just a simple cleanup ?
>> I'm removing the API. At the end of this cleanup, there will be no
>> more
>> preallocation; instead we will rely on the slab allocator not
>> sucking.
>>
> Ok, Seems reasonable, I am ok with this.
>
>>> Adding Maor, the author of this change,
>>>
>>> I believe the idea is to speed up insert_fte (which calls
>>> ida_simple_get) since insert_fte runs under the FTE write
>>> semaphore,
>>> in this case if ida_pre_get was successful before taking the
>>> semaphore
>>> for all the FTE nodes in the loop, this will be a huge win for
>>> ida_simple_get which will immediately return success without even
>>> trying to allocate.
>> I think that's misguided. The IDA allocator is only going to
>> allocate
>> memory once in every 1024 allocations. Also, it does try to
>> allocate,
>> even if there are preallocated nodes. So you're just wasting time,
>> unfortunately.
>>
> Well just by looking at the code you can tell for sure that
> two consecutive calls to ida_pre_get will result in one allocation
> only.
> due to "if (!this_cpu_read(ida_bitmap))"
>
> but i didn't dig into details and didn't go through the whole
> ida_get_new_above, so i will count on your judgment here.
>
> Still i would like to wait for Maor's input here, the author..
> I Will ping him today.
>
> Thanks,
> Saeed.
Saeed, Matan and I okay with this fix as well, it looks like it
shouldn't impact on the insertion rate.
^ permalink raw reply
* [PATCH] test_bpf: Fix testing with CONFIG_BPF_JIT_ALWAYS_ON=y on other arches
From: Thadeu Lima de Souza Cascardo @ 2018-03-20 12:58 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Yonghong Song, Daniel Borkmann, Alexei Starovoitov
Function bpf_fill_maxinsns11 is designed to not be able to be JITed on
x86_64. So, it fails when CONFIG_BPF_JIT_ALWAYS_ON=y, and
commit 09584b406742 ("bpf: fix selftests/bpf test_kmod.sh failure when
CONFIG_BPF_JIT_ALWAYS_ON=y") makes sure that failure is detected on that
case.
However, it does not fail on other architectures, which have a different
JIT compiler design. So, test_bpf has started to fail to load on those.
After this fix, test_bpf loads fine on both x86_64 and ppc64el.
Fixes: 09584b406742 ("bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y")
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
---
lib/test_bpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index 2efb213716faa..3e9335493fe49 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -5467,7 +5467,7 @@ static struct bpf_test tests[] = {
{
"BPF_MAXINSNS: Jump, gap, jump, ...",
{ },
-#ifdef CONFIG_BPF_JIT_ALWAYS_ON
+#if defined(CONFIG_BPF_JIT_ALWAYS_ON) && defined(CONFIG_X86)
CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
#else
CLASSIC | FLAG_NO_DATA,
--
2.15.1
^ permalink raw reply related
* Re: linux-next on x60: network manager often complains "network is disabled" after resume
From: Dan Williams @ 2018-03-20 13:12 UTC (permalink / raw)
To: Pavel Machek
Cc: Woody Suwalski, Rafael J. Wysocki, kernel list,
Linux-pm mailing list, Netdev list
In-Reply-To: <20180320080334.GA31772@amd>
On Tue, 2018-03-20 at 09:03 +0100, Pavel Machek wrote:
> On Mon 2018-03-19 12:45:49, Dan Williams wrote:
> > On Mon, 2018-03-19 at 18:33 +0100, Pavel Machek wrote:
> > > On Mon 2018-03-19 10:40:08, Dan Williams wrote:
> > > > On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> > > > > On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > > > > > Pavel Machek wrote:
> > > > > > > Hi!
> > > > > > >
> > > > > > > With recent linux-next, after resume networkmanager often
> > > > > > > claims
> > > > > > > that
> > > > > > > "network is disabled". Sometimes suspend/resume clears
> > > > > > > that.
> > > > > > >
> > > > > > > Any ideas? Does it work for you?
> > > > > > >
> > > > > > >
> > > > > > > Pavel
> > > > > >
> > > > > > Tried the 4.16-rc6 with nm 1.4.4 - I do not see the issue.
> > > > >
> > > > > Thanks for testing... but yes, 4.16 should be ok. If not
> > > > > fixed,
> > > > > problem will appear in 4.17-rc1.
> > > >
> > > > Where does the complaint occur? In the GUI, or with nmcli, or
> > > > somewhere else? Also, what's the output of "nmcli dev" after
> > > > resume?
> > >
> > > In the GUI. I click in place where I'd select access point, and
> > > menu
> > > does not show up, telling me that "network is disabled".
> >
> > Ok, what does 'nmcli dev' and 'nmcli radio' show?
>
> Broken state.
>
> pavel@amd:~$ nmcli dev
> DEVICE TYPE STATE CONNECTION
> eth1 ethernet unavailable --
> lo loopback unmanaged --
> wlan0 wifi unmanaged --
If the state is "unmanaged" on resume, that would indicate a problem
with sleep/wake and likely not a kernel network device issue.
We should probably move this discussion to the NM lists to debug
further. Before you suspend, run "nmcli gen log level trace" to turn
on full debug logging, then reproduce the issue, and send a pointer to
those logs (scrubbed for anything you consider sensitive) to the NM
mailing list.
Dan
> pavel@amd:~$ nmcli radio
> WIFI-HW WIFI WWAN-HW WWAN
> enabled enabled enabled enabled
> pavel@amd:~$ uname -a
> Linux amd 4.16.0-rc5-next-20180314+ #31 SMP Thu Mar 15 14:27:19 CET
> 2018 i686 GNU/Linux
>
> Let me suspend/resume. I was lucky and got it into working state:
>
> pavel@amd:~$ nmcli dev
> DEVICE TYPE STATE CONNECTION
> wlan0 wifi connected openwireless.org
> eth1 ethernet unavailable --
> lo loopback unmanaged --
> pavel@amd:~$ nmcli radio
> WIFI-HW WIFI WWAN-HW WWAN
> enabled enabled enabled enabled
> paveamd:~$
>
> Best regards,
>
> Pavel
>
^ permalink raw reply
* Re: [rds-devel] [PATCH RFC RFC] rds: Use NETDEV_UNREGISTER in rds_tcp_dev_event() (then kill NETDEV_UNREGISTER_FINAL)
From: Sowmini Varadhan @ 2018-03-20 13:29 UTC (permalink / raw)
To: H??kon Bugge
Cc: Kirill Tkhai, rds-devel, OFED mailing list, netdev, edumazet,
davem
In-Reply-To: <CBB6A644-8650-41F5-800B-A34DEFBB2C4C@oracle.com>
On (03/20/18 12:37), H??kon Bugge wrote:
>
> A little nit below. And some spelling issues in existing commentary
> you can consider fixing, since you reshuffle this file considerable.
> > + if (net != &init_net && rtn->ctl_table)
> > + kfree(rtn->ctl_table);
>
> Well, this comes from the existing code, but as pointed out by Linus
> recently, kfree() handles NULL pointers. So, if rtn->ctl_table is
> NULL most likely, the code is OK _if_ you add an unlikely() around the
> if-clause. Otherwise, the ??? && rtn->ctl_table??? can simply be removed.
As you observe correctly, this comes from the existing code,
and is unrelated to the contents of the commit comment.
So if we feel passionately about htis, let us please fix this
separately, with its own ceremony.
> s/when/When/
> s/parameters,this/parameters, this/
>
> Well, not part of your commit.
As above.
>
>
> > * function resets the RDS connections in that netns so that we can
>
> Two double spaces incidents above
>
> Not part of your commit
As above.
Thanks much.
--Sowmini
^ permalink raw reply
* Re: [RFC v2 0/2] kernel: add support to collect hardware logs in crash recovery kernel
From: Rahul Lakkireddy @ 2018-03-20 13:30 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Indranil Choudhury,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
Nirranjan Kirubaharan,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org, Ganesh GR
In-Reply-To: <20180319082211.6651b45a@xeon-e3>
On Monday, March 03/19/18, 2018 at 20:52:11 +0530, Stephen Hemminger wrote:
> On Mon, 19 Mar 2018 13:25:56 +0530
> Rahul Lakkireddy <rahul.lakkireddy-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org> wrote:
>
> > On Friday, March 03/16/18, 2018 at 16:42:03 +0530, Rahul Lakkireddy wrote:
> > > On production servers running variety of workloads over time, kernel
> > > panic can happen sporadically after days or even months. It is
> > > important to collect as much debug logs as possible to root cause
> > > and fix the problem, that may not be easy to reproduce. Snapshot of
> > > underlying hardware/firmware state (like register dump, firmware
> > > logs, adapter memory, etc.), at the time of kernel panic will be very
> > > helpful while debugging the culprit device driver.
> > >
> > > This series of patches add new generic framework that enable device
> > > drivers to collect device specific snapshot of the hardware/firmware
> > > state of the underlying device in the crash recovery kernel. In crash
> > > recovery kernel, the collected logs are exposed via /proc/crashdd/
> > > directory, which is copied by user space scripts for post-analysis.
> > >
> > > A kernel module crashdd is newly added. In crash recovery kernel,
> > > crashdd exposes /proc/crashdd/ directory containing device specific
> > > hardware/firmware logs.
> > >
> > > The sequence of actions done by device drivers to append their device
> > > specific hardware/firmware logs to /proc/crashdd/ directory are as
> > > follows:
> > >
> > > 1. During probe (before hardware is initialized), device drivers
> > > register to the crashdd module (via crashdd_add_dump()), with
> > > callback function, along with buffer size and log name needed for
> > > firmware/hardware log collection.
> > >
> > > 2. Crashdd creates a driver's directory under /proc/crashdd/<driver>.
> > > Then, it allocates the buffer with requested size and invokes the
> > > device driver's registered callback function.
> > >
> > > 3. Device driver collects all hardware/firmware logs into the buffer
> > > and returns control back to crashdd.
> > >
> > > 4. Crashdd exposes the buffer as a file via
> > > /proc/crashdd/<driver>/<dump_file>.
> > >
> > > 5. User space script (/usr/lib/kdump/kdump-lib-initramfs.sh) copies
> > > the entire /proc/crashdd/ directory to /var/crash/ directory.
> > >
> > > Patch 1 adds crashdd module to allow drivers to register callback to
> > > collect the device specific hardware/firmware logs. The module also
> > > exports /proc/crashdd/ directory containing the hardware/firmware logs.
> > >
> > > Patch 2 shows a cxgb4 driver example using the API to collect
> > > hardware/firmware logs in crash recovery kernel, before hardware is
> > > initialized. The logs for the devices are made available under
> > > /proc/crashdd/cxgb4/ directory.
> > >
> > > Suggestions and feedback will be much appreciated.
> > >
> > > Thanks,
> > > Rahul
> > >
> > > RFC v1: https://www.spinics.net/lists/netdev/msg486562.html
> > >
> > > ---
> > > v2:
> > > - Added new crashdd module that exports /proc/crashdd/ containing
> > > driver's registered hardware/firmware logs in patch 1.
> > > - Replaced the API to allow drivers to register their hardware/firmware
> > > log collect routine in crash recovery kernel in patch 1.
> > > - Updated patch 2 to use the new API in patch 1.
> > >
> > > Rahul Lakkireddy (2):
> > > proc/crashdd: add API to collect hardware dump in second kernel
> > > cxgb4: collect hardware dump in second kernel
> > >
> > > drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 4 +
> > > drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c | 25 +++
> > > drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.h | 3 +
> > > drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 12 ++
> > > fs/proc/Kconfig | 11 +
> > > fs/proc/Makefile | 1 +
> > > fs/proc/crashdd.c | 263 +++++++++++++++++++++++
> > > include/linux/crashdd.h | 43 ++++
> > > 8 files changed, 362 insertions(+)
> > > create mode 100644 fs/proc/crashdd.c
> > > create mode 100644 include/linux/crashdd.h
> > >
> > > --
> > > 2.14.1
> > >
> >
> > Does anyone have any comments with this approach? If there are no
> > comments, then I'll re-spin this RFC to Patch series.
> >
> > Thanks,
> > Rahul
>
> This does look like it gives useful data, but it is not clear that this can
> not already be done with existing API's or small extensions.
>
> Introducing a new /proc interface and one that is mostly device specific is
> unlikely to be greeted with a warm reception by the current Linux kernel community.
>
> For example, getting firmware logs seems like something more related to
> ethtool or sysfs.
The /proc/crashdd/ is only exposed in 2nd (crash recovery) kernel.
This is similar to /proc/vmcore. Since vmcore is exported via
/proc/ interface, I've exported the device specific logs also via
/proc/crashdd/.
I can change to sysfs if that is the preferred approach. Does
/sys/crashdd/ sound good?
Thanks,
Rahul
^ permalink raw reply
* RE: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
From: David Laight @ 2018-03-20 13:30 UTC (permalink / raw)
To: 'Ingo Molnar', Thomas Gleixner
Cc: 'Rahul Lakkireddy', x86@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
mingo@redhat.com, hpa@zytor.com, davem@davemloft.net,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
ganeshgr@chelsio.com, nirranjan@chelsio.com, indranil@chelsio.com,
Andy Lutomirski, Peter Zijlstra, Fenghua Yu, Eric Biggers
In-Reply-To: <20180320105427.bm4od7cpessbraag@gmail.com>
From: Ingo Molnar
> Sent: 20 March 2018 10:54
...
> Note that a generic version might still be worth trying out, if and only if it's
> safe to access those vector registers directly: modern x86 CPUs will do their
> non-constant memcpy()s via the common memcpy_erms() function - which could in
> theory be an easy common point to be (cpufeatures-) patched to an AVX2 variant, if
> size (and alignment, perhaps) is a multiple of 32 bytes or so.
>
> Assuming it's correct with arbitrary user-space FPU state and if it results in any
> measurable speedups, which might not be the case: ERMS is supposed to be very
> fast.
>
> So even if it's possible (which it might not be), it could end up being slower
> than the ERMS version.
Last I checked memcpy() was implemented as 'rep movsb' on the latest Intel cpus.
Since memcpy_to/fromio() get aliased to memcpy() this generates byte copies.
The previous 'fastest' version of memcpy() was ok for uncached locations.
For PCIe I suspect that the actual instructions don't make a massive difference.
I'm not even sure interleaving two transfers makes any difference.
What makes a huge difference for memcpy_fromio() is the size of the register.
The time taken for a read will be largely independent of the width of the
register used.
David
^ permalink raw reply
* Re: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write
From: Rahul Lakkireddy @ 2018-03-20 13:32 UTC (permalink / raw)
To: Thomas Gleixner
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
davem@davemloft.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <alpine.DEB.2.21.1803191525010.2010@nanos.tec.linutronix.de>
On Monday, March 03/19/18, 2018 at 20:13:10 +0530, Thomas Gleixner wrote:
> On Mon, 19 Mar 2018, Rahul Lakkireddy wrote:
>
> > Use VMOVDQU AVX CPU instruction when available to do 256-bit
> > IO read and write.
>
> That's not what the patch does. See below.
>
> > Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> > Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
>
> That Signed-off-by chain is wrong....
>
> > +#ifdef CONFIG_AS_AVX
> > +#include <asm/fpu/api.h>
> > +
> > +static inline u256 __readqq(const volatile void __iomem *addr)
> > +{
> > + u256 ret;
> > +
> > + kernel_fpu_begin();
> > + asm volatile("vmovdqu %0, %%ymm0" :
> > + : "m" (*(volatile u256 __force *)addr));
> > + asm volatile("vmovdqu %%ymm0, %0" : "=m" (ret));
> > + kernel_fpu_end();
> > + return ret;
>
> You _cannot_ assume that the instruction is available just because
> CONFIG_AS_AVX is set. The availability is determined by the runtime
> evaluated CPU feature flags, i.e. X86_FEATURE_AVX.
>
Ok. Will add boot_cpu_has(X86_FEATURE_AVX) check as well.
> Aside of that I very much doubt that this is faster than 4 consecutive
> 64bit reads/writes as you have the full overhead of
> kernel_fpu_begin()/end() for each access.
>
> You did not provide any numbers for this so its even harder to
> determine.
>
Sorry about that. Here are the numbers with and without this series.
When reading up to 2 GB on-chip memory via MMIO, the time taken:
Without Series With Series
(64-bit read) (256-bit read)
52 seconds 26 seconds
As can be seen, we see good improvement with doing 256-bits at a
time.
> As far as I can tell the code where you are using this is a debug
> facility. What's the point? Debug is hardly a performance critical problem.
>
On High Availability Server, the logs of the failing system must be
collected as quickly as possible. So, we're concerned with the amount
of time taken to collect our large on-chip memory. We see improvement
in doing 256-bit reads at a time.
Thanks,
Rahul
^ permalink raw reply
* Re: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write
From: Andy Shevchenko @ 2018-03-20 13:44 UTC (permalink / raw)
To: Rahul Lakkireddy
Cc: Thomas Gleixner, x86@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
davem@davemloft.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <20180320133206.GB25574@chelsio.com>
On Tue, Mar 20, 2018 at 3:32 PM, Rahul Lakkireddy
<rahul.lakkireddy@chelsio.com> wrote:
> On Monday, March 03/19/18, 2018 at 20:13:10 +0530, Thomas Gleixner wrote:
>> On Mon, 19 Mar 2018, Rahul Lakkireddy wrote:
>> Aside of that I very much doubt that this is faster than 4 consecutive
>> 64bit reads/writes as you have the full overhead of
>> kernel_fpu_begin()/end() for each access.
>>
>> You did not provide any numbers for this so its even harder to
>> determine.
>>
>
> Sorry about that. Here are the numbers with and without this series.
>
> When reading up to 2 GB on-chip memory via MMIO, the time taken:
>
> Without Series With Series
> (64-bit read) (256-bit read)
>
> 52 seconds 26 seconds
>
> As can be seen, we see good improvement with doing 256-bits at a
> time.
But this is kinda synthetic test, right?
If you run in a normal use case where kernel not only collecting logs,
but doing something else, especially with frequent userspace
interaction, would be trend the same?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [RFC PATCH 0/3] kernel: add support for 256-bit IO access
From: Rahul Lakkireddy @ 2018-03-20 13:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, davem@davemloft.net, akpm@linux-foundation.org,
torvalds@linux-foundation.org, Ganesh GR, Nirranjan Kirubaharan,
Indranil Choudhury
In-Reply-To: <20180319152722.GA31104@infradead.org>
On Monday, March 03/19/18, 2018 at 20:57:22 +0530, Christoph Hellwig wrote:
> On Mon, Mar 19, 2018 at 07:50:33PM +0530, Rahul Lakkireddy wrote:
> > This series of patches add support for 256-bit IO read and write.
> > The APIs are readqq and writeqq (quad quadword - 4 x 64), that read
> > and write 256-bits at a time from IO, respectively.
>
> What a horrible name. please encode the actual number of bits instead.
Ok. Will change it to read256() and write256().
Thanks,
Rahul
^ permalink raw reply
* [RFC PATCH] net: phy: Added device tree binding for dev-addr and dev-addr code check-up and usage
From: Vicentiu Galanopulo @ 2018-03-20 13:46 UTC (permalink / raw)
To: andrew, f.fainelli, netdev, linux-kernel, robh+dt, mark.rutland,
davem, marcel, devicetree
Cc: madalin.bucur, alexandru.marginean
Reason for this patch is that the Inphi PHY
has a vendor specific address space for accessing
the C45 MDIO registers - starting from 0x1e.
A new function has been added, get_phy_c45_dev_addr,
which loops through all the PHY device nodes under
a MDIO bus node and looks for the <dev-addr> property. If
it's not set/found, the get_phy_c45_devs_in_pkg,
will be called with the value 0 as dev_addr parameter,
else it will be called with the dev-addr property
value from the device tree.
As a plus to this patch, num_ids in get_phy_c45_ids,
has the value 8 (ARRAY_SIZE(c45_ids->device_ids)), but
the u32 *devs can store 32 devices in the bitfield. If
a device is stored in *devs, in bits 32 to 9, it
will not be found. This is the reason for changing in phy.h,
the size of device_ids array.
Signed-off-by: Vicentiu Galanopulo <vicentiu.galanopulo@nxp.com>
---
Documentation/devicetree/bindings/net/phy.txt | 6 ++
drivers/net/phy/phy_device.c | 80 ++++++++++++++++++++++++++-
include/linux/phy.h | 2 +-
3 files changed, 84 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index d2169a5..82692e2 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -61,6 +61,11 @@ Optional Properties:
- reset-deassert-us: Delay after the reset was deasserted in microseconds.
If this property is missing the delay will be skipped.
+- dev-addr: If set, it indicates the device address of the PHY to be used
+ when accessing the C45 PHY registers over MDIO. It is used for vendor specific
+ register space addresses that do no conform to standard address for the MDIO
+ registers (e.g. MMD30)
+
Example:
ethernet-phy@0 {
@@ -72,4 +77,5 @@ ethernet-phy@0 {
reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
reset-assert-us = <1000>;
reset-deassert-us = <2000>;
+ dev-addr = <0x1e>;
};
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index b285323..35b9a2b 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -442,6 +442,52 @@ static int get_phy_c45_devs_in_pkg(struct mii_bus *bus, int addr, int dev_addr,
}
/**
+ * get_phy_c45_dev_addr - reads the C45 PHY device register address
+ * from the PHY device tree node
+ * @bus: the target MII bus
+ * @addr: PHY address on the MII bus
+ * @dev_addr: where to store the device address of the C45 PHY.
+ *
+ * Description: reads the PHY device address in @dev_addr
+ * from PHY at @addr on @bus.
+ *
+ * Returns: 0 on success, -EIO and -ENODEV on failure.
+ */
+static int get_phy_c45_dev_addr(struct mii_bus *bus,
+ int addr, int *dev_addr)
+{
+ struct device_node *child;
+ u32 reg_addr;
+ int ret;
+
+ if (!bus->dev.of_node)
+ return -ENODEV;
+
+ for_each_available_child_of_node(bus->dev.of_node, child) {
+ ret = of_property_read_u32(child, "reg", ®_addr);
+ if (ret < 0) {
+ dev_err(&bus->dev, "%s has invalid PHY address\n",
+ child->full_name);
+ *dev_addr = 0;
+ return -EINVAL;
+ }
+
+ /* match the device address with the device tree address */
+ if (reg_addr == addr) {
+ ret = of_property_read_u32(child, "dev-addr", dev_addr);
+ if (ret < 0) {
+ dev_warn(&bus->dev, "No PHY device address defined for %s\n",
+ child->full_name);
+ *dev_addr = 0;
+ }
+ break;
+ }
+ }
+
+ return 0;
+}
+
+/**
* get_phy_c45_ids - reads the specified addr for its 802.3-c45 IDs.
* @bus: the target MII bus
* @addr: PHY address on the MII bus
@@ -458,6 +504,9 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
struct phy_c45_device_ids *c45_ids) {
int phy_reg;
int i, reg_addr;
+ int dev_addr = 0;
+ int ret;
+ int dev_reg_addr;
const int num_ids = ARRAY_SIZE(c45_ids->device_ids);
u32 *devs = &c45_ids->devices_in_package;
@@ -475,9 +524,27 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
* 10G PHYs have zero Devices In package,
* e.g. Cortina CS4315/CS4340 PHY.
*/
- phy_reg = get_phy_c45_devs_in_pkg(bus, addr, 0, devs);
+
+ /* Check if the device address
+ * is set in the device tree
+ */
+ ret = get_phy_c45_dev_addr(bus, addr, &dev_addr);
+ /* Exit only when MDIO querying fails
+ * or <reg> property is not set in the
+ * PHY device tree node.
+ */
+ if (ret < 0)
+ return -EIO;
+
+ /* If the device tree property (dev-addr)
+ * is not set, the default value for
+ * dev_addr is 0.
+ */
+ phy_reg = get_phy_c45_devs_in_pkg(bus, addr,
+ dev_addr, devs);
if (phy_reg < 0)
return -EIO;
+
/* no device there, let's get out of here */
if ((*devs & 0x1fffffff) == 0x1fffffff) {
*phy_id = 0xffffffff;
@@ -493,13 +560,20 @@ static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
if (!(c45_ids->devices_in_package & (1 << i)))
continue;
- reg_addr = MII_ADDR_C45 | i << 16 | MII_PHYSID1;
+ /* If dev-addr is set in the device tree,
+ * use that property value for querying
+ * the PHY device ID.
+ */
+
+ dev_reg_addr = (!!dev_addr ? dev_addr : i) << 16;
+ reg_addr = MII_ADDR_C45 | dev_reg_addr | MII_PHYSID1;
phy_reg = mdiobus_read(bus, addr, reg_addr);
if (phy_reg < 0)
return -EIO;
c45_ids->device_ids[i] = (phy_reg & 0xffff) << 16;
- reg_addr = MII_ADDR_C45 | i << 16 | MII_PHYSID2;
+ dev_reg_addr = (!!dev_addr ? dev_addr : i) << 16;
+ reg_addr = MII_ADDR_C45 | dev_reg_addr | MII_PHYSID2;
phy_reg = mdiobus_read(bus, addr, reg_addr);
if (phy_reg < 0)
return -EIO;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 5a9b175..c3b3633 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -360,7 +360,7 @@ enum phy_state {
*/
struct phy_c45_device_ids {
u32 devices_in_package;
- u32 device_ids[8];
+ u32 device_ids[32];
};
/* phy_device: An instance of a PHY
--
2.7.4
^ permalink raw reply related
* RE: interdependencies with cxgb4 and iw_cxgb4
From: Steve Wise @ 2018-03-20 13:47 UTC (permalink / raw)
To: 'David Miller'
Cc: rajur, dledford, linux-rdma, jgg, netdev, bharat, ganeshgr,
rahul.lakkireddy
In-Reply-To: <20180319.193440.1570733225238398675.davem@davemloft.net>
> From: Steve Wise <swise@opengridcomputing.com>
> Date: Mon, 19 Mar 2018 14:50:57 -0500
>
> > Let me ask a dumb question:� Why cannot one of the maintaners pull the
> > commit from the other mainainer's git repo directly?� IE why have this
> > third trusted/signed git repo that has to be on k.o, from which both
> > maintainers pull?� If one of you can pull it in via a patch series,
> > like you do for all other patches, and then notify the other
> > maintainer to pull it from the first maintainers' repo if the series
> > meets the requirements that it needs to be in both maintainers'
> > repositories?� This avoids adding more staging git repos on k.o.� But
> > probably I'm missing something...
>
> Tree A may not want all of tree B's changes, and vice versa.
I was thinking the special commit would go into a branch that was based on,
say rc1 or rc2 of one of the maintainers. Then both maintainers pull that
into their -next branch. Would that work?
^ 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