* [PATCH] net: hns: qdd missing \n to end of dev_err messages
From: Colin King @ 2016-10-04 11:06 UTC (permalink / raw)
To: Salil Mehta, David S . Miller, Kejian Yan, Daode Huang, lipeng,
Lisheng, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trival fix, dev_err messages are missing a \n, so add it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index a834774..7aeed08 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -547,7 +547,7 @@ int hns_mac_set_autoneg(struct hns_mac_cb *mac_cb, u8 enable)
struct mac_driver *mac_ctrl_drv = hns_mac_get_drv(mac_cb);
if (mac_cb->phy_if == PHY_INTERFACE_MODE_XGMII && enable) {
- dev_err(mac_cb->dev, "enable autoneg is not allowed!");
+ dev_err(mac_cb->dev, "enable autoneg is not allowed!\n");
return -ENOTSUPP;
}
@@ -571,7 +571,7 @@ int hns_mac_set_pauseparam(struct hns_mac_cb *mac_cb, u32 rx_en, u32 tx_en)
if (mac_cb->mac_type == HNAE_PORT_DEBUG) {
if (is_ver1 && (tx_en || rx_en)) {
- dev_err(mac_cb->dev, "macv1 cann't enable tx/rx_pause!");
+ dev_err(mac_cb->dev, "macv1 cann't enable tx/rx_pause!\n");
return -EINVAL;
}
}
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v2] phy: micrel.c: Enable ksz9031 energy-detect power-down mode
From: Florian Fainelli @ 2016-10-04 11:09 UTC (permalink / raw)
To: Mike Looijmans, netdev; +Cc: linux-kernel
In-Reply-To: <1475560324-23346-1-git-send-email-mike.looijmans@topic.nl>
On 10/03/2016 10:52 PM, Mike Looijmans wrote:
> Set bit 0 in register 1C.23 to enable the EDPD feature of the
> KSZ9031 PHY. This reduces power consumption when the link is
> down.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com
--
Florian
^ permalink raw reply
* [PATCH] net: axienet: Add missing \n to end of dev_err messages
From: Colin King @ 2016-10-04 11:11 UTC (permalink / raw)
To: Anirudha Sarangi, John Linn, Michal Simek, Sören Brinkmann,
netdev, linux-arm-kernel
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trival fix, dev_err messages are missing a \n, so add it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 69e2a83..35f9f97 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -818,7 +818,7 @@ static irqreturn_t axienet_tx_irq(int irq, void *_ndev)
goto out;
}
if (!(status & XAXIDMA_IRQ_ALL_MASK))
- dev_err(&ndev->dev, "No interrupts asserted in Tx path");
+ dev_err(&ndev->dev, "No interrupts asserted in Tx path\n");
if (status & XAXIDMA_IRQ_ERROR_MASK) {
dev_err(&ndev->dev, "DMA Tx error 0x%x\n", status);
dev_err(&ndev->dev, "Current BD is at: 0x%x\n",
@@ -867,7 +867,7 @@ static irqreturn_t axienet_rx_irq(int irq, void *_ndev)
goto out;
}
if (!(status & XAXIDMA_IRQ_ALL_MASK))
- dev_err(&ndev->dev, "No interrupts asserted in Rx path");
+ dev_err(&ndev->dev, "No interrupts asserted in Rx path\n");
if (status & XAXIDMA_IRQ_ERROR_MASK) {
dev_err(&ndev->dev, "DMA Rx error 0x%x\n", status);
dev_err(&ndev->dev, "Current BD is at: 0x%x\n",
--
2.9.3
^ permalink raw reply related
* [PATCH] net: ps3_gelic: Add missing \n to end of deb_dbg message
From: Colin King @ 2016-10-04 11:15 UTC (permalink / raw)
To: Geoff Levand, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, netdev, linuxppc-dev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trival fix, dev_dbg message is missing a \n, so add it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
index bc258d7..272f2b1 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
@@ -1769,7 +1769,7 @@ static int ps3_gelic_driver_probe(struct ps3_system_bus_device *dev)
gelic_ether_setup_netdev_ops(netdev, &card->napi);
result = gelic_net_setup_netdev(netdev, card);
if (result) {
- dev_dbg(&dev->core, "%s: setup_netdev failed %d",
+ dev_dbg(&dev->core, "%s: setup_netdev failed %d\n",
__func__, result);
goto fail_setup_netdev;
}
--
2.9.3
^ permalink raw reply related
* [PATCH] i40e: Add missing \n to end of dev_err message
From: Colin King @ 2016-10-04 11:20 UTC (permalink / raw)
To: Jeff Kirsher, intel-wired-lan, netdev; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trival fix, dev_err message is missing a \n, so add it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 54b8ee2..64e54a5 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -2940,7 +2940,7 @@ int i40e_ndo_set_vf_bw(struct net_device *netdev, int vf_id, int min_tx_rate,
}
if (max_tx_rate > speed) {
- dev_err(&pf->pdev->dev, "Invalid max tx rate %d specified for VF %d.",
+ dev_err(&pf->pdev->dev, "Invalid max tx rate %d specified for VF %d.\n",
max_tx_rate, vf->vf_id);
ret = -EINVAL;
goto error;
--
2.9.3
^ permalink raw reply related
* [PATCH v6 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-10-04 11:41 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
Allan.Nielsen-dzo6w/eZyo2tG0bUXCXiUA, andrew-g2DYL2Zd6BY,
Raju Lakkaraju
From: Raju Lakkaraju <Raju.Lakkaraju-dzo6w/eZyo2tG0bUXCXiUA@public.gmane.org>
Edge-rate:
As system and networking speeds increase, a signal's output transition,
also know as the edge rate or slew rate (V/ns), takes on greater importance
because high-speed signals come with a price. That price is an assortment of
interference problems like ringing on the line, signal overshoot and
undershoot, extended signal settling times, crosstalk noise, transmission
line reflections, false signal detection by the receiving device and
electromagnetic interference (EMI) -- all of which can negate the potential
gains designers are seeking when they try to increase system speeds through
the use of higher performance logic devices. The fact is, faster signaling
edge rates can cause a higher level of electrical noise or other type of
interference that can actually lead to slower line speeds and lower maximum
system frequencies. This parameter allow the board designers to change the
driving strange, and thereby change the EMI behavioral.
Edge-rate parameters (vddmac, edge-slowdown) get from Device Tree.
Tested on Beaglebone Black with VSC 8531 PHY.
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju-dzo6w/eZyo2tG0bUXCXiUA@public.gmane.org>
---
All the review comments updated and resending for review.
Change set:
v1:
- Initial version of Edge-rate driver add by using IOCTL.
v2:
- Changed edge-rate parameter to Device Tree with magic number.
v3:
- Added Device Tree documentati0n and edge-rate parameter table.
Added probe function initialize the vsc8531 private data structure.
v4:
- As per review comment, Device Tree parameters (vddmac, edge-slowdown)
added.
v5:
- As per review comment, Device Tree Document parameters (vddmac,
edge-slowdown) real numbers added. Table number changed from 5 to 1.
v6:
- As per review comment, Removed Device Tree header file. Removed MACROs
and add ARRAYSIZE
---
.../devicetree/bindings/net/mscc-phy-vsc8531.txt | 3 ++-
drivers/net/phy/mscc.c | 29 ++++++++++++----------
include/dt-bindings/net/mscc-phy-vsc8531.h | 21 ----------------
3 files changed, 18 insertions(+), 35 deletions(-)
delete mode 100644 include/dt-bindings/net/mscc-phy-vsc8531.h
diff --git a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
index 99c7eb0..241841c 100644
--- a/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
+++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
@@ -18,7 +18,8 @@ Optional properties:
to reprogram drive strength and in effect slow
down the edge rate if desired. Table 1 shows the
impact to the edge rate per VDDMAC supply for each
- drive strength setting.
+ drive strength setting. VDDMAC supply voltage
+ should be one of the value in Table-1 first row.
Ref: Table:1 - Edge rate change below.
Note: see dt-bindings/net/mscc-phy-vsc8531.h for applicable values
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index a17573e..e25786e 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -12,7 +12,6 @@
#include <linux/mii.h>
#include <linux/phy.h>
#include <linux/of.h>
-#include <dt-bindings/net/mscc-phy-vsc8531.h>
enum rgmii_rx_clock_delay {
RGMII_RX_CLK_DELAY_0_2_NS = 0,
@@ -56,12 +55,14 @@ enum rgmii_rx_clock_delay {
#define PHY_ID_VSC8531 0x00070570
#define PHY_ID_VSC8541 0x00070770
+#define MSCC_SLOWDOWN_MAX 8
+
struct edge_rate_table {
u16 vddmac;
int slowdown[MSCC_SLOWDOWN_MAX];
};
-struct edge_rate_table edge_table[MSCC_VDDMAC_MAX] = {
+static const struct edge_rate_table edge_table[] = {
{3300, { 0, -2, -4, -7, -10, -17, -29, -53} },
{2500, { 0, -3, -6, -10, -14, -23, -37, -63} },
{1800, { 0, -5, -9, -16, -23, -35, -52, -76} },
@@ -81,18 +82,21 @@ static int vsc85xx_phy_page_set(struct phy_device *phydev, u8 page)
return rc;
}
-static u8 edge_rate_magic_get(u16 vddmac,
- int slowdown)
+static u8 vsc85xx_edge_rate_magic_get(u16 vddmac,
+ int slowdown)
{
- int rc = (MSCC_SLOWDOWN_MAX - 1);
+ int rc = (ARRAY_SIZE(edge_table[0].slowdown) - 1);
u8 vdd;
u8 sd;
- for (vdd = 0; vdd < MSCC_VDDMAC_MAX; vdd++) {
+ for (vdd = 0; vdd < ARRAY_SIZE(edge_table); vdd++) {
if (edge_table[vdd].vddmac == vddmac) {
- for (sd = 0; sd < MSCC_SLOWDOWN_MAX; sd++) {
+ for (sd = 0;
+ sd < ARRAY_SIZE(edge_table[0].slowdown);
+ sd++) {
if (edge_table[vdd].slowdown[sd] <= slowdown) {
- rc = (MSCC_SLOWDOWN_MAX - sd - 1);
+ rc = (ARRAY_SIZE(edge_table[0].slowdown)
+ - sd - 1);
break;
}
}
@@ -198,14 +202,13 @@ static int vsc8531_of_init(struct phy_device *phydev)
rc = of_property_read_u16(of_node, "vsc8531,vddmac",
&vsc8531->vddmac);
if (rc == -EINVAL)
- vsc8531->vddmac = MSCC_VDDMAC_3300;
+ vsc8531->vddmac = 3300;
rc = of_property_read_u8(of_node, "vsc8531,edge-slowdown",
&vsc8531->edge_slowdown);
if (rc == -EINVAL)
vsc8531->edge_slowdown = 0;
- rc = 0;
- return rc;
+ return 0;
}
#else
static int vsc8531_of_init(struct phy_device *phydev)
@@ -232,8 +235,8 @@ static int vsc85xx_config_init(struct phy_device *phydev)
if (rc)
return rc;
- edge_rate = edge_rate_magic_get(vsc8531->vddmac,
- -(int)vsc8531->edge_slowdown);
+ edge_rate = vsc85xx_edge_rate_magic_get(vsc8531->vddmac,
+ -(int)vsc8531->edge_slowdown);
rc = vsc85xx_edge_rate_cntl_set(phydev, edge_rate);
if (rc)
return rc;
diff --git a/include/dt-bindings/net/mscc-phy-vsc8531.h b/include/dt-bindings/net/mscc-phy-vsc8531.h
deleted file mode 100644
index 2383dd2..0000000
--- a/include/dt-bindings/net/mscc-phy-vsc8531.h
+++ /dev/null
@@ -1,21 +0,0 @@
-/*
- * Device Tree constants for Microsemi VSC8531 PHY
- *
- * Author: Nagaraju Lakkaraju
- *
- * License: Dual MIT/GPL
- * Copyright (c) 2016 Microsemi Corporation
- */
-
-#ifndef _DT_BINDINGS_MSCC_VSC8531_H
-#define _DT_BINDINGS_MSCC_VSC8531_H
-
-/* MAC interface Edge rate control VDDMAC in milli Volts */
-#define MSCC_VDDMAC_3300 3300
-#define MSCC_VDDMAC_2500 2500
-#define MSCC_VDDMAC_1800 1800
-#define MSCC_VDDMAC_1500 1500
-#define MSCC_VDDMAC_MAX 4
-#define MSCC_SLOWDOWN_MAX 8
-
-#endif
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v6 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: Andrew Lunn @ 2016-10-04 11:51 UTC (permalink / raw)
To: Raju Lakkaraju; +Cc: netdev, devicetree, f.fainelli, Allan.Nielsen
In-Reply-To: <1475581272-12093-1-git-send-email-Raju.Lakkaraju@microsemi.com>
On Tue, Oct 04, 2016 at 05:11:12PM +0530, Raju Lakkaraju wrote:
> From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
>
> Edge-rate:
> As system and networking speeds increase, a signal's output transition,
> also know as the edge rate or slew rate (V/ns), takes on greater importance
> because high-speed signals come with a price. That price is an assortment of
> interference problems like ringing on the line, signal overshoot and
> undershoot, extended signal settling times, crosstalk noise, transmission
> line reflections, false signal detection by the receiving device and
> electromagnetic interference (EMI) -- all of which can negate the potential
> gains designers are seeking when they try to increase system speeds through
> the use of higher performance logic devices. The fact is, faster signaling
> edge rates can cause a higher level of electrical noise or other type of
> interference that can actually lead to slower line speeds and lower maximum
> system frequencies. This parameter allow the board designers to change the
> driving strange, and thereby change the EMI behavioral.
>
> Edge-rate parameters (vddmac, edge-slowdown) get from Device Tree.
>
> Tested on Beaglebone Black with VSC 8531 PHY.
>
> Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
>
> ---
> All the review comments updated and resending for review.
>
> Change set:
> v1:
> - Initial version of Edge-rate driver add by using IOCTL.
> v2:
> - Changed edge-rate parameter to Device Tree with magic number.
> v3:
> - Added Device Tree documentati0n and edge-rate parameter table.
> Added probe function initialize the vsc8531 private data structure.
> v4:
> - As per review comment, Device Tree parameters (vddmac, edge-slowdown)
> added.
> v5:
> - As per review comment, Device Tree Document parameters (vddmac,
> edge-slowdown) real numbers added. Table number changed from 5 to 1.
> v6:
> - As per review comment, Removed Device Tree header file. Removed MACROs
> and add ARRAYSIZE
But you ignored my request to make the table values positive, and to
enforce an exact match in the table.
NACK
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/7] qed*: Add qedr infrastructure support
From: Doug Ledford @ 2016-10-04 12:04 UTC (permalink / raw)
To: David Miller, Yuval.Mintz
Cc: netdev, linux-rdma, Ram.Amrani, Michal.Kalderon, Ariel.Elior
In-Reply-To: <20161003.232446.1827173235395776859.davem@davemloft.net>
[-- Attachment #1.1: Type: text/plain, Size: 2088 bytes --]
On 10/3/2016 11:24 PM, David Miller wrote:
> From: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
> Date: Sat, 1 Oct 2016 21:59:54 +0300
>
>> In the last couple of weeks we've been sending RFCs for the qedr
>> driver - the RoCE driver for QLogic FastLinQ 4xxxx line of adapters.
>> Latest RFC can be found at [1].
>>
>> At Doug's advice [2], we've decided to split the series into two:
>> - first part contains the qed backbone that's necessary for all the
>> configurations relating to the qedr driver, as well as the qede
>> infrastructure that is used for communication between the qedr and qede.
>> - Second part consists of the actual qedr driver and introduces almost
>> no changes to qed/qede.
>>
>> This is the first of said two parts. The second half would be sent
>> later this week.
>>
>> The only 'oddity' in the devision are the Kconfig options -
>> As this series introduces both LL2 and QEDR-based logic in qed/qede,
>> I wanted to add the CONFIG_INFINIBAND_QEDR option here [with default n].
>> Otherwise, a lot of the code introduced would be dead-code [won't even
>> be compiled] until qedr is accepted.
>> As a result I've placed the config option in an odd place - under
>> qlogic's Kconfig. The second series would then remove that option
>> and add it in its correct place under the infiniband Kconfig.
>> [I'm fine with pushing it there to begin with, but I didn't want to
>> 'contaminate' non-qlogic configuration files with half-baked options].
>>
>> Dave - I don't think you were E-mailed with Doug's suggestion.
>> I think the notion was to have the two halves accepted side-by-side,
>> but actually the first has no dependency issues, so it's also
>> possible to simply take this first to net-next, and push the qedr
>> into rdma once it's merged. But it's basically up to you and Doug;
>> We'd align with whatever suits you best.
>
> I'll take this, series applied, thanks.
>
Are you going to merge this in 4.9 or is this going into net-next?
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* RE: [PATCH net-next 1/3] net: ethernet: mediatek: get the chip id by ETHDMASYS registers
From: Nelson Chang @ 2016-10-04 12:12 UTC (permalink / raw)
To: john, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw
Hi John,
Thanks for your review!
I will modify that as below. Would you think it is okay?
static int mtk_get_chip_id(struct mtk_eth *eth, u32 *chip_id)
{
u32 val[2], id[4];
regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, &val[0]);
regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, &val[1]);
id[3] = ((val[0] >> 16) & 0xff) - '0';
id[2] = ((val[0] >> 24) & 0xff) - '0';
id[1] = (val[1] & 0xff) - '0';
id[0] = ((val[1] >> 8) & 0xff) - '0';
*chip_id = (id[3] * 1000) + (id[2] * 100) +
(id[1] * 10) + id[0];
if (!(*chip_id)) {
dev_err(eth->dev, "failed to get chip id\n");
return -ENODEV;
}
dev_info(eth->dev, "chip id = %d\n", *chip_id);
return 0;
}
...
static int mtk_probe(struct platform_device *pdev)
{
...
err = mtk_get_chip_id(eth, ð->chip_id);
if (err)
return err;
...
}
Nelson
-----Original Message-----
From: John Crispin [mailto:john@phrozen.org]
Sent: Tuesday, October 04, 2016 3:17 AM
To: Nelson Chang (張家祥); davem@davemloft.net
Cc: nbd@openwrt.org; netdev@vger.kernel.org;
linux-mediatek@lists.infradead.org; nelsonch.tw@gmail.com
Subject: Re: [PATCH net-next 1/3] net: ethernet: mediatek: get the chip
id by ETHDMASYS registers
Hi Nelson,
comments inline
On 03/10/2016 09:18, Nelson Chang wrote:
> The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7
> registers in mtk_probe().
>
> Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 27
> +++++++++++++++++++++++++++
> drivers/net/ethernet/mediatek/mtk_eth_soc.h | 5 +++++
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index ad4ab97..a3e4ae6 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2323,6 +2323,27 @@ free_netdev:
> return err;
> }
>
> +static u32 mtk_get_chip_id(struct mtk_eth *eth) {
> + u32 val[2], id[4];
> + u32 chip_id;
> +
> + regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, &val[0]);
> + regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, &val[1]);
> +
> + id[3] = ((val[0] >> 16) & 0xff) - '0';
> + id[2] = ((val[0] >> 24) & 0xff) - '0';
> + id[1] = (val[1] & 0xff) - '0';
> + id[0] = ((val[1] >> 8) & 0xff) - '0';
> +
> + chip_id = (id[3] * 1000) + (id[2] * 100) +
> + (id[1] * 10) + id[0];
> +
> + dev_info(eth->dev, "chip id = %d\n", chip_id);
the chip id is printed here
> + return chip_id;
> +}
> +
> static int mtk_probe(struct platform_device *pdev) {
> struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM,
> 0); @@ -2388,6 +2409,12 @@ static int mtk_probe(struct platform_device
*pdev)
> if (err)
> return err;
>
> + eth->chip_id = mtk_get_chip_id(eth);
> + if (!eth->chip_id) {
> + dev_err(&pdev->dev, "failed to get chip id\n");
> + return -ENODEV;
> + }
> +
and the error check happens here. maybe you could move the dev_err to
the above function.
John
> for_each_child_of_node(pdev->dev.of_node, mac_np) {
> if (!of_device_is_compatible(mac_np,
> "mediatek,eth-mac"))
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index 3003195..a5b422b 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -342,6 +342,10 @@
> #define GPIO_BIAS_CTRL 0xed0
> #define GPIO_DRV_SEL10 0xf00
>
> +/* ethernet subsystem chip id register */
> +#define ETHSYS_CHIPID0_3 0x0
> +#define ETHSYS_CHIPID4_7 0x4
> +
> /* ethernet subsystem config register */
> #define ETHSYS_SYSCFG0 0x14
> #define SYSCFG0_GE_MASK 0x3
> @@ -534,6 +538,7 @@ struct mtk_eth {
> unsigned long sysclk;
> struct regmap *ethsys;
> struct regmap *pctl;
> + u32 chip_id;
> bool hwlro;
> atomic_t dma_refcnt;
> struct mtk_tx_ring tx_ring;
>
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: ethernet: mediatek: get the chip id by ETHDMASYS registers
From: John Crispin @ 2016-10-04 12:14 UTC (permalink / raw)
To: Nelson Chang, davem; +Cc: nbd, netdev, linux-mediatek, nelsonch.tw
In-Reply-To: <1475583160.7983.4.camel@mtksdaap41>
On 04/10/2016 14:12, Nelson Chang wrote:
> Hi John,
>
> Thanks for your review!
> I will modify that as below. Would you think it is okay?
>
> static int mtk_get_chip_id(struct mtk_eth *eth, u32 *chip_id)
> {
> u32 val[2], id[4];
>
> regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, &val[0]);
> regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, &val[1]);
>
> id[3] = ((val[0] >> 16) & 0xff) - '0';
> id[2] = ((val[0] >> 24) & 0xff) - '0';
> id[1] = (val[1] & 0xff) - '0';
> id[0] = ((val[1] >> 8) & 0xff) - '0';
>
> *chip_id = (id[3] * 1000) + (id[2] * 100) +
> (id[1] * 10) + id[0];
>
> if (!(*chip_id)) {
> dev_err(eth->dev, "failed to get chip id\n");
> return -ENODEV;
> }
>
> dev_info(eth->dev, "chip id = %d\n", *chip_id);
>
> return 0;
> }
> ...
> static int mtk_probe(struct platform_device *pdev)
> {
> ...
> err = mtk_get_chip_id(eth, ð->chip_id);
> if (err)
> return err;
> ...
> }
>
>
> Nelson
Hi Nelson,
I think that looks nicer, thanks !
John
>
> -----Original Message-----
> From: John Crispin [mailto:john@phrozen.org]
> Sent: Tuesday, October 04, 2016 3:17 AM
> To: Nelson Chang (張家祥); davem@davemloft.net
> Cc: nbd@openwrt.org; netdev@vger.kernel.org;
> linux-mediatek@lists.infradead.org; nelsonch.tw@gmail.com
> Subject: Re: [PATCH net-next 1/3] net: ethernet: mediatek: get the chip
> id by ETHDMASYS registers
>
> Hi Nelson,
>
> comments inline
>
> On 03/10/2016 09:18, Nelson Chang wrote:
>> The driver gets the chip id by ETHSYS_CHIPID0_3/ETHSYS_CHIPID4_7
>> registers in mtk_probe().
>>
>> Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
>> ---
>> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 27
>> +++++++++++++++++++++++++++
>> drivers/net/ethernet/mediatek/mtk_eth_soc.h | 5 +++++
>> 2 files changed, 32 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> index ad4ab97..a3e4ae6 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
>> @@ -2323,6 +2323,27 @@ free_netdev:
>> return err;
>> }
>>
>> +static u32 mtk_get_chip_id(struct mtk_eth *eth) {
>> + u32 val[2], id[4];
>> + u32 chip_id;
>> +
>> + regmap_read(eth->ethsys, ETHSYS_CHIPID0_3, &val[0]);
>> + regmap_read(eth->ethsys, ETHSYS_CHIPID4_7, &val[1]);
>> +
>> + id[3] = ((val[0] >> 16) & 0xff) - '0';
>> + id[2] = ((val[0] >> 24) & 0xff) - '0';
>> + id[1] = (val[1] & 0xff) - '0';
>> + id[0] = ((val[1] >> 8) & 0xff) - '0';
>> +
>> + chip_id = (id[3] * 1000) + (id[2] * 100) +
>> + (id[1] * 10) + id[0];
>> +
>> + dev_info(eth->dev, "chip id = %d\n", chip_id);
>
> the chip id is printed here
>
>> + return chip_id;
>> +}
>> +
>> static int mtk_probe(struct platform_device *pdev) {
>> struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM,
>> 0); @@ -2388,6 +2409,12 @@ static int mtk_probe(struct platform_device
> *pdev)
>> if (err)
>> return err;
>>
>> + eth->chip_id = mtk_get_chip_id(eth);
>> + if (!eth->chip_id) {
>> + dev_err(&pdev->dev, "failed to get chip id\n");
>> + return -ENODEV;
>> + }
>> +
>
> and the error check happens here. maybe you could move the dev_err to
> the above function.
>
> John
>
>> for_each_child_of_node(pdev->dev.of_node, mac_np) {
>> if (!of_device_is_compatible(mac_np,
>> "mediatek,eth-mac"))
>> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
>> b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
>> index 3003195..a5b422b 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
>> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
>> @@ -342,6 +342,10 @@
>> #define GPIO_BIAS_CTRL 0xed0
>> #define GPIO_DRV_SEL10 0xf00
>>
>> +/* ethernet subsystem chip id register */
>> +#define ETHSYS_CHIPID0_3 0x0
>> +#define ETHSYS_CHIPID4_7 0x4
>> +
>> /* ethernet subsystem config register */
>> #define ETHSYS_SYSCFG0 0x14
>> #define SYSCFG0_GE_MASK 0x3
>> @@ -534,6 +538,7 @@ struct mtk_eth {
>> unsigned long sysclk;
>> struct regmap *ethsys;
>> struct regmap *pctl;
>> + u32 chip_id;
>> bool hwlro;
>> atomic_t dma_refcnt;
>> struct mtk_tx_ring tx_ring;
>>
>
>
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: ethernet: mediatek: get hw lro capability by the chip id instead of by the dtsi
From: Nelson Chang @ 2016-10-04 12:22 UTC (permalink / raw)
To: john, davem; +Cc: netdev, nbd, linux-mediatek, nelsonch.tw
Hi John,
do you plan to add more chips to the mtk_is_hwlro_supporte() function ?
=> yes, there will be more chips with hw lro in the future, so i think
using mtk_is_hwlro_supporte() function can have the scalability.
Thanks.
Nelson
-----Original Message-----
From: John Crispin [mailto:john@phrozen.org]
Sent: Tuesday, October 04, 2016 3:19 AM
To: Nelson Chang (張家祥); davem@davemloft.net
Cc: netdev@vger.kernel.org; nbd@openwrt.org;
linux-mediatek@lists.infradead.org; nelsonch.tw@gmail.com
Subject: Re: [PATCH net-next 2/3] net: ethernet: mediatek: get hw lro
capability by the chip id instead of by the dtsi
Hi Nelson,
comment inline
On 03/10/2016 09:18, Nelson Chang wrote:
> Because hw lro started to be supported from MT7623, the proper way to
> check if the feature is capable is to judge by the chip id instead of
by the dtsi.
>
> Signed-off-by: Nelson Chang <nelson.chang@mediatek.com>
> ---
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 12 ++++++++++--
> drivers/net/ethernet/mediatek/mtk_eth_soc.h | 1 +
> 2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index a3e4ae6..3d16a0c 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -2344,6 +2344,14 @@ static u32 mtk_get_chip_id(struct mtk_eth *eth)
> return chip_id;
> }
>
> +static bool mtk_is_hwlro_supported(struct mtk_eth *eth) {
> + if (eth->chip_id == MT7623_ETH)
> + return true;
> + else
> + return false;
> +}
> +
> static int mtk_probe(struct platform_device *pdev) {
> struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM,
> 0); @@ -2383,8 +2391,6 @@ static int mtk_probe(struct platform_device
*pdev)
> return PTR_ERR(eth->pctl);
> }
>
> - eth->hwlro = of_property_read_bool(pdev->dev.of_node,
"mediatek,hwlro");
> -
> for (i = 0; i < 3; i++) {
> eth->irq[i] = platform_get_irq(pdev, i);
> if (eth->irq[i] < 0) {
> @@ -2415,6 +2421,8 @@ static int mtk_probe(struct platform_device
*pdev)
> return -ENODEV;
> }
>
> + eth->hwlro = mtk_is_hwlro_supported(eth);
> +
do you plan to add more chips to the mtk_is_hwlro_supporte() function ?
if not a simple
eth->hwlro = (eth->chip_id == MT7623_ETH);
might be enough
John
> for_each_child_of_node(pdev->dev.of_node, mac_np) {
> if (!of_device_is_compatible(mac_np,
> "mediatek,eth-mac"))
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> index a5b422b..58738fd 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
> @@ -345,6 +345,7 @@
> /* ethernet subsystem chip id register */
> #define ETHSYS_CHIPID0_3 0x0
> #define ETHSYS_CHIPID4_7 0x4
> +#define MT7623_ETH (7623)
>
> /* ethernet subsystem config register */
> #define ETHSYS_SYSCFG0 0x14
>
^ permalink raw reply
* Re: [PATCH v6 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-10-04 12:26 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, devicetree, f.fainelli, Allan.Nielsen
In-Reply-To: <20161004115132.GG11677@lunn.ch>
Hi Andrew,
Thank you for review comment.
In another thread, I wrote my comment as below.
-----------------------------------------------------------------
> In edge_table, remove the -'s and call edge_rate_magic_get with
> positive values. The table is also missing "static const".
> edge_rate_magic_get is missing its prefix, so keeping the name space
> clean.
>
I will add "static const" to table and also add prefix vsc85xx_ to edge_rate_magic_get function.
Regarding remove the -'s in table, PHY data sheet descript the concept of edge rate with table. I would like to keep the same table in driver.
> Since you are using real values, you can remove mscc-phy-vsc8531.h.
-------------------------------------------------------------------------
But I did not see your comment. I though you accepted to keep the table
as in PHY Data sheet.
Is any thing wrong if i keep in table with '-' (minus) values?
Thanks,
Raju.
On Tue, Oct 04, 2016 at 01:51:32PM +0200, Andrew Lunn wrote:
> EXTERNAL EMAIL
>
>
> On Tue, Oct 04, 2016 at 05:11:12PM +0530, Raju Lakkaraju wrote:
> > From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
> >
> > Edge-rate:
> > As system and networking speeds increase, a signal's output transition,
> > also know as the edge rate or slew rate (V/ns), takes on greater importance
> > because high-speed signals come with a price. That price is an assortment of
> > interference problems like ringing on the line, signal overshoot and
> > undershoot, extended signal settling times, crosstalk noise, transmission
> > line reflections, false signal detection by the receiving device and
> > electromagnetic interference (EMI) -- all of which can negate the potential
> > gains designers are seeking when they try to increase system speeds through
> > the use of higher performance logic devices. The fact is, faster signaling
> > edge rates can cause a higher level of electrical noise or other type of
> > interference that can actually lead to slower line speeds and lower maximum
> > system frequencies. This parameter allow the board designers to change the
> > driving strange, and thereby change the EMI behavioral.
> >
> > Edge-rate parameters (vddmac, edge-slowdown) get from Device Tree.
> >
> > Tested on Beaglebone Black with VSC 8531 PHY.
> >
> > Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
> >
> > ---
> > All the review comments updated and resending for review.
> >
> > Change set:
> > v1:
> > - Initial version of Edge-rate driver add by using IOCTL.
> > v2:
> > - Changed edge-rate parameter to Device Tree with magic number.
> > v3:
> > - Added Device Tree documentati0n and edge-rate parameter table.
> > Added probe function initialize the vsc8531 private data structure.
> > v4:
> > - As per review comment, Device Tree parameters (vddmac, edge-slowdown)
> > added.
> > v5:
> > - As per review comment, Device Tree Document parameters (vddmac,
> > edge-slowdown) real numbers added. Table number changed from 5 to 1.
> > v6:
> > - As per review comment, Removed Device Tree header file. Removed MACROs
> > and add ARRAYSIZE
>
> But you ignored my request to make the table values positive, and to
> enforce an exact match in the table.
>
> NACK
>
> Andrew
^ permalink raw reply
* [PATCH net-next 0/2] openvswitch: vlan fixes
From: Jiri Benc @ 2016-10-04 12:30 UTC (permalink / raw)
To: netdev; +Cc: pravin shelar, Eric Garver
Fix a bug and inefficiency in the vlan handling code introduced by the
802.1AD set. Strictly speaking, both were present even before that set
but it made them more prominent.
Jiri Benc (2):
openvswitch: remove nonreachable code in vlan parsing
openvswitch: fix vlan subtraction from packet length
net/openvswitch/flow.c | 28 ++++++++--------------------
net/openvswitch/vport.c | 10 +++-------
2 files changed, 11 insertions(+), 27 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net-next 1/2] openvswitch: remove nonreachable code in vlan parsing
From: Jiri Benc @ 2016-10-04 12:30 UTC (permalink / raw)
To: netdev; +Cc: pravin shelar, Eric Garver
In-Reply-To: <cover.1475583870.git.jbenc@redhat.com>
It can never happen that there's a vlan tag in the packet but not in
skb->vlan_tci. This is ensured in __netif_receive_skb_core and honored by
skb_vlan_push and skb_vlan_pop. The code dealing with such case is a dead
code.
Moreover, the likely() statement around skb_vlan_tag_present is bogus. This
code is called whenever flow key is being extracted from the packet. The
packet may be as likely vlan tagged as not.
Fixes: 018c1dda5ff1 ("openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink attributes")
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
net/openvswitch/flow.c | 28 ++++++++--------------------
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index c8c82e109c68..d88c0a55b783 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -308,9 +308,7 @@ static bool icmp6hdr_ok(struct sk_buff *skb)
/**
* Parse vlan tag from vlan header.
- * Returns ERROR on memory error.
- * Returns 0 if it encounters a non-vlan or incomplete packet.
- * Returns 1 after successfully parsing vlan tag.
+ * Returns ERROR on memory error, 0 otherwise.
*/
static int parse_vlan_tag(struct sk_buff *skb, struct vlan_head *key_vh)
{
@@ -331,34 +329,24 @@ static int parse_vlan_tag(struct sk_buff *skb, struct vlan_head *key_vh)
key_vh->tpid = vh->tpid;
__skb_pull(skb, sizeof(struct vlan_head));
- return 1;
+ return 0;
}
static int parse_vlan(struct sk_buff *skb, struct sw_flow_key *key)
{
- int res;
-
key->eth.vlan.tci = 0;
key->eth.vlan.tpid = 0;
key->eth.cvlan.tci = 0;
key->eth.cvlan.tpid = 0;
- if (likely(skb_vlan_tag_present(skb))) {
- key->eth.vlan.tci = htons(skb->vlan_tci);
- key->eth.vlan.tpid = skb->vlan_proto;
- } else {
- /* Parse outer vlan tag in the non-accelerated case. */
- res = parse_vlan_tag(skb, &key->eth.vlan);
- if (res <= 0)
- return res;
- }
+ if (!skb_vlan_tag_present(skb))
+ return 0;
- /* Parse inner vlan tag. */
- res = parse_vlan_tag(skb, &key->eth.cvlan);
- if (res <= 0)
- return res;
+ key->eth.vlan.tci = htons(skb->vlan_tci);
+ key->eth.vlan.tpid = skb->vlan_proto;
- return 0;
+ /* Parse inner vlan tag. */
+ return parse_vlan_tag(skb, &key->eth.cvlan);
}
static __be16 parse_ethertype(struct sk_buff *skb)
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 2/2] openvswitch: fix vlan subtraction from packet length
From: Jiri Benc @ 2016-10-04 12:30 UTC (permalink / raw)
To: netdev; +Cc: pravin shelar, Eric Garver
In-Reply-To: <cover.1475583870.git.jbenc@redhat.com>
When the packet has its vlan tag in skb->vlan_tci, the length of the VLAN
header is not counted in skb->len. It doesn't make sense to subtract it.
In addition, to honor the comment below the code, the VLAN header length
should not be subtracted if there's a vlan tag in skb->vlan_tci. This leads
to the code simply subtracting the Ethernet header length.
Fixes: 018c1dda5ff1 ("openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink attributes")
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
net/openvswitch/vport.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 8f198437c724..210bafc09bd8 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -483,17 +483,13 @@ EXPORT_SYMBOL_GPL(ovs_vport_deferred_free);
static unsigned int packet_length(const struct sk_buff *skb)
{
- unsigned int length = skb->len - ETH_HLEN;
-
- if (skb_vlan_tagged(skb))
- length -= VLAN_HLEN;
-
/* Don't subtract for multiple VLAN tags. Most (all?) drivers allow
* (ETH_LEN + VLAN_HLEN) in addition to the mtu value, but almost none
* account for 802.1ad. e.g. is_skb_forwardable().
+ * Note that the first VLAN tag is always in skb->vlan_tci, thus not
+ * accounted for in skb->len.
*/
-
- return length;
+ return skb->len - ETH_HLEN;
}
void ovs_vport_send(struct vport *vport, struct sk_buff *skb)
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] net: hns: qdd missing \n to end of dev_err messages
From: Sergei Shtylyov @ 2016-10-04 12:31 UTC (permalink / raw)
To: Colin King, Salil Mehta, David S . Miller, Kejian Yan,
Daode Huang, lipeng, Lisheng, netdev
Cc: linux-kernel
In-Reply-To: <20161004110618.11615-1-colin.king@canonical.com>
Hello.
On 10/04/2016 02:06 PM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trival fix, dev_err messages are missing a \n, so add it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
> index a834774..7aeed08 100644
> --- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
> +++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
> @@ -547,7 +547,7 @@ int hns_mac_set_autoneg(struct hns_mac_cb *mac_cb, u8 enable)
> struct mac_driver *mac_ctrl_drv = hns_mac_get_drv(mac_cb);
>
> if (mac_cb->phy_if == PHY_INTERFACE_MODE_XGMII && enable) {
> - dev_err(mac_cb->dev, "enable autoneg is not allowed!");
> + dev_err(mac_cb->dev, "enable autoneg is not allowed!\n");
Enabling, perhaps?
> return -ENOTSUPP;
> }
>
> @@ -571,7 +571,7 @@ int hns_mac_set_pauseparam(struct hns_mac_cb *mac_cb, u32 rx_en, u32 tx_en)
>
> if (mac_cb->mac_type == HNAE_PORT_DEBUG) {
> if (is_ver1 && (tx_en || rx_en)) {
> - dev_err(mac_cb->dev, "macv1 cann't enable tx/rx_pause!");
> + dev_err(mac_cb->dev, "macv1 cann't enable tx/rx_pause!\n");
Perhaps a good time to fix this "cann't"?
[...]
MBR, Sergei
^ permalink raw reply
* Re: [v2] mwifiex: report wakeup for wowlan
From: Kalle Valo @ 2016-10-04 12:46 UTC (permalink / raw)
To: Rajat Jain
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
Wei-Ning Huang, Brian Norris, Eric Caruso, Rajat Jain
In-Reply-To: <CACK8Z6Fe34xdvd5-=3dNmqKXYC=Qr9+kpG46eCV7uFArLW+yyQ@mail.gmail.com>
Rajat Jain <rajatja@google.com> writes:
> Hello Kalie,
>
> On Mon, Oct 3, 2016 at 6:04 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Rajat Jain <rajatja@google.com> wrote:
>>> Enable notifying wakeup source to the PM core in case of
>>> a wake on wireless LAN event.
>>>
>>> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
>>> Signed-off-by: Rajat Jain <rajatja@google.com>
>>> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
>>> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
>>> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
>>
>> The commit log doesn't give any background info. Does this fix a bug or
>> why is it needed?
>
> Some of chromeos' features (called "darkresume" in chromeos
> terminology) use and track the wake up sources using the wakeup
> attributes in sysfs. Since the wireless device can wake up the host,
> hence we wanted to add it as a wakeup source to the system, and in the
> case of an actual wakeup event, trigger to the PM core that it was
> indeed caused by the device and it increments the different counters
> etc. In the absence of this patch, the feature wasn't working very
> well (as it was apparently confused about the cause of wake up).
Thanks, makes sense. Please add that to the commit and send v3.
--
Kalle Valo
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2 net-next 5/7] xen-netback: process guest rx packets in batches
From: Konrad Rzeszutek Wilk @ 2016-10-04 12:47 UTC (permalink / raw)
To: Paul Durrant; +Cc: netdev, xen-devel, Wei Liu, David Vrabel
In-Reply-To: <1475573358-32414-6-git-send-email-paul.durrant@citrix.com>
On Tue, Oct 04, 2016 at 10:29:16AM +0100, Paul Durrant wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> Instead of only placing one skb on the guest rx ring at a time, process
> a batch of up-to 64. This improves performance by ~10% in some tests.
And does it regress latency workloads?
What are those 'some tests' you speak off?
Thanks.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> [re-based]
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> ---
> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
> drivers/net/xen-netback/rx.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
> index 9548709..ae822b8 100644
> --- a/drivers/net/xen-netback/rx.c
> +++ b/drivers/net/xen-netback/rx.c
> @@ -399,7 +399,7 @@ static void xenvif_rx_extra_slot(struct xenvif_queue *queue,
> BUG();
> }
>
> -void xenvif_rx_action(struct xenvif_queue *queue)
> +void xenvif_rx_skb(struct xenvif_queue *queue)
> {
> struct xenvif_pkt_state pkt;
>
> @@ -425,6 +425,19 @@ void xenvif_rx_action(struct xenvif_queue *queue)
> xenvif_rx_complete(queue, &pkt);
> }
>
> +#define RX_BATCH_SIZE 64
> +
> +void xenvif_rx_action(struct xenvif_queue *queue)
> +{
> + unsigned int work_done = 0;
> +
> + while (xenvif_rx_ring_slots_available(queue) &&
> + work_done < RX_BATCH_SIZE) {
> + xenvif_rx_skb(queue);
> + work_done++;
> + }
> +}
> +
> static bool xenvif_rx_queue_stalled(struct xenvif_queue *queue)
> {
> RING_IDX prod, cons;
> --
> 2.1.4
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2 net-next 4/7] xen-netback: immediately wake tx queue when guest rx queue has space
From: Konrad Rzeszutek Wilk @ 2016-10-04 12:48 UTC (permalink / raw)
To: Paul Durrant; +Cc: netdev, xen-devel, Wei Liu, David Vrabel
In-Reply-To: <1475573358-32414-5-git-send-email-paul.durrant@citrix.com>
On Tue, Oct 04, 2016 at 02:29:15AM -0700, Paul Durrant wrote:
> From: David Vrabel <david.vrabel@citrix.com>
>
> When an skb is removed from the guest rx queue, immediately wake the
> tx queue, instead of after processing them.
Please, could the description explain why?
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> [re-based]
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> ---
> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
> drivers/net/xen-netback/rx.c | 24 ++++++++----------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
> index b0ce4c6..9548709 100644
> --- a/drivers/net/xen-netback/rx.c
> +++ b/drivers/net/xen-netback/rx.c
> @@ -92,27 +92,21 @@ static struct sk_buff *xenvif_rx_dequeue(struct xenvif_queue *queue)
> spin_lock_irq(&queue->rx_queue.lock);
>
> skb = __skb_dequeue(&queue->rx_queue);
> - if (skb)
> + if (skb) {
> queue->rx_queue_len -= skb->len;
> + if (queue->rx_queue_len < queue->rx_queue_max) {
> + struct netdev_queue *txq;
> +
> + txq = netdev_get_tx_queue(queue->vif->dev, queue->id);
> + netif_tx_wake_queue(txq);
> + }
> + }
>
> spin_unlock_irq(&queue->rx_queue.lock);
>
> return skb;
> }
>
> -static void xenvif_rx_queue_maybe_wake(struct xenvif_queue *queue)
> -{
> - spin_lock_irq(&queue->rx_queue.lock);
> -
> - if (queue->rx_queue_len < queue->rx_queue_max) {
> - struct net_device *dev = queue->vif->dev;
> -
> - netif_tx_wake_queue(netdev_get_tx_queue(dev, queue->id));
> - }
> -
> - spin_unlock_irq(&queue->rx_queue.lock);
> -}
> -
> static void xenvif_rx_queue_purge(struct xenvif_queue *queue)
> {
> struct sk_buff *skb;
> @@ -585,8 +579,6 @@ int xenvif_kthread_guest_rx(void *data)
> */
> xenvif_rx_queue_drop_expired(queue);
>
> - xenvif_rx_queue_maybe_wake(queue);
> -
> cond_resched();
> }
>
> --
> 2.1.4
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [Xen-devel] [PATCH v2 net-next 2/7] xen-netback: retire guest rx side prefix GSO feature
From: Konrad Rzeszutek Wilk @ 2016-10-04 12:52 UTC (permalink / raw)
To: Paul Durrant, annie.li, joao.m.martins; +Cc: netdev, xen-devel, Wei Liu
In-Reply-To: <1475573358-32414-3-git-send-email-paul.durrant@citrix.com>
On Tue, Oct 04, 2016 at 10:29:13AM +0100, Paul Durrant wrote:
> As far as I am aware only very old Windows network frontends make use of
> this style of passing GSO packets from backend to frontend. These
> frontends can easily be replaced by the freely available Xen Project
> Windows PV network frontend, which uses the 'default' mechanism for
> passing GSO packets, which is also used by all Linux frontends.
It is not that simple. Some companies have extra juice in their Windows
frontends so can't easily swap over to the Xen Project one.
Either way CC-ing Annie
Also would it make sense to CC the FreeBSD and NetBSD maintainers of
their PV drivers just to make sure? (Or has that been confirmed)
>
> NOTE: Removal of this feature will not cause breakage in old Windows
> frontends. They simply will no longer receive GSO packets - the
> packets instead being fragmented in the backend.
Did you also test this with SuSE/Novell Windows PV drivers?
Thanks.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
> ---
> Cc: Wei Liu <wei.liu2@citrix.com>
> ---
> drivers/net/xen-netback/common.h | 1 -
> drivers/net/xen-netback/interface.c | 4 ++--
> drivers/net/xen-netback/rx.c | 26 --------------------------
> drivers/net/xen-netback/xenbus.c | 21 ---------------------
> 4 files changed, 2 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index b38fb2c..0ba5910 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -260,7 +260,6 @@ struct xenvif {
>
> /* Frontend feature information. */
> int gso_mask;
> - int gso_prefix_mask;
>
> u8 can_sg:1;
> u8 ip_csum:1;
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index fb50c6d..211d542 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -319,9 +319,9 @@ static netdev_features_t xenvif_fix_features(struct net_device *dev,
>
> if (!vif->can_sg)
> features &= ~NETIF_F_SG;
> - if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV4))
> + if (~(vif->gso_mask) & GSO_BIT(TCPV4))
> features &= ~NETIF_F_TSO;
> - if (~(vif->gso_mask | vif->gso_prefix_mask) & GSO_BIT(TCPV6))
> + if (~(vif->gso_mask) & GSO_BIT(TCPV6))
> features &= ~NETIF_F_TSO6;
> if (!vif->ip_csum)
> features &= ~NETIF_F_IP_CSUM;
> diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
> index 03836aa..6bd7d6e 100644
> --- a/drivers/net/xen-netback/rx.c
> +++ b/drivers/net/xen-netback/rx.c
> @@ -347,16 +347,6 @@ static int xenvif_gop_skb(struct sk_buff *skb,
> gso_type = XEN_NETIF_GSO_TYPE_TCPV6;
> }
>
> - /* Set up a GSO prefix descriptor, if necessary */
> - if ((1 << gso_type) & vif->gso_prefix_mask) {
> - RING_COPY_REQUEST(&queue->rx, queue->rx.req_cons++, &req);
> - meta = npo->meta + npo->meta_prod++;
> - meta->gso_type = gso_type;
> - meta->gso_size = skb_shinfo(skb)->gso_size;
> - meta->size = 0;
> - meta->id = req.id;
> - }
> -
> RING_COPY_REQUEST(&queue->rx, queue->rx.req_cons++, &req);
> meta = npo->meta + npo->meta_prod++;
>
> @@ -511,22 +501,6 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
> while ((skb = __skb_dequeue(&rxq)) != NULL) {
> struct xen_netif_extra_info *extra = NULL;
>
> - if ((1 << queue->meta[npo.meta_cons].gso_type) &
> - vif->gso_prefix_mask) {
> - resp = RING_GET_RESPONSE(&queue->rx,
> - queue->rx.rsp_prod_pvt++);
> -
> - resp->flags = XEN_NETRXF_gso_prefix |
> - XEN_NETRXF_more_data;
> -
> - resp->offset = queue->meta[npo.meta_cons].gso_size;
> - resp->id = queue->meta[npo.meta_cons].id;
> - resp->status = XENVIF_RX_CB(skb)->meta_slots_used;
> -
> - npo.meta_cons++;
> - XENVIF_RX_CB(skb)->meta_slots_used--;
> - }
> -
> queue->stats.tx_bytes += skb->len;
> queue->stats.tx_packets++;
>
> diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
> index daf4c78..7056404 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -1135,7 +1135,6 @@ static int read_xenbus_vif_flags(struct backend_info *be)
> vif->can_sg = !!val;
>
> vif->gso_mask = 0;
> - vif->gso_prefix_mask = 0;
>
> if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4",
> "%d", &val) < 0)
> @@ -1143,32 +1142,12 @@ static int read_xenbus_vif_flags(struct backend_info *be)
> if (val)
> vif->gso_mask |= GSO_BIT(TCPV4);
>
> - if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv4-prefix",
> - "%d", &val) < 0)
> - val = 0;
> - if (val)
> - vif->gso_prefix_mask |= GSO_BIT(TCPV4);
> -
> if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv6",
> "%d", &val) < 0)
> val = 0;
> if (val)
> vif->gso_mask |= GSO_BIT(TCPV6);
>
> - if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-gso-tcpv6-prefix",
> - "%d", &val) < 0)
> - val = 0;
> - if (val)
> - vif->gso_prefix_mask |= GSO_BIT(TCPV6);
> -
> - if (vif->gso_mask & vif->gso_prefix_mask) {
> - xenbus_dev_fatal(dev, err,
> - "%s: gso and gso prefix flags are not "
> - "mutually exclusive",
> - dev->otherend);
> - return -EOPNOTSUPP;
> - }
> -
> if (xenbus_scanf(XBT_NIL, dev->otherend, "feature-no-csum-offload",
> "%d", &val) < 0)
> val = 0;
> --
> 2.1.4
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v6 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: Andrew Lunn @ 2016-10-04 12:53 UTC (permalink / raw)
To: Raju Lakkaraju; +Cc: netdev, devicetree, f.fainelli, Allan.Nielsen
In-Reply-To: <20161004122648.GA12301@microsemi.com>
> Regarding remove the -'s in table, PHY data sheet descript the
> concept of edge rate with table. I would like to keep the same table
> in driver.
The double negative makes the code ugly. Plus a negative slowdown is a
speed up! The kernel maintainability and sanity comes first, and if
the data sheet is crazy, because it uses negative slows downs, it
should be ignored. Get the data sheet fixed....
Andrew
^ permalink raw reply
* [PATCH v2 0/4] add support for impedance control for TI dp83867 phy and fix 2nd ethernet on dra72 rev C evm
From: Mugunthan V N @ 2016-10-04 12:56 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Mark Rutland, Tony Lindgren, Russell King, Florian Fainelli,
David Miller, Sekhar Nori, Mugunthan V N
Add support for configurable impedance control for TI dp83867
phy via devicetree. More documentation in [1].
CPSW second ethernet is not working, fix it by enabling
impedance configuration on the phy.
Verified the patch on DRA72 Rev C evm, logs at [2]. Also pushed
a branch [3] for others to test.
Changes from initial version:
* As per Sekhar's comment, instead of passing impedance values,
change to max and min impedance from DT
* Adopted phy_read_mmd_indirect() to cunnrent implementation.
* Corrected the phy delay timings to the optimal value.
[1] - http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
[2] - http://pastebin.ubuntu.com/23274616/
[3] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git dp83867-v2
Mugunthan V N (4):
net: phy: dp83867: Add documentation for optional impedance control
net: phy: dp83867: add support for MAC impedance configuration
ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings
ARM: dts: dra72-evm-revc: fix correct phy delay
.../devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++
arch/arm/boot/dts/dra72-evm-revc.dts | 10 ++++----
drivers/net/phy/dp83867.c | 28 ++++++++++++++++++++++
3 files changed, 46 insertions(+), 4 deletions(-)
--
2.10.0.372.g6fe1b14
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 1/4] net: phy: dp83867: Add documentation for optional impedance control
From: Mugunthan V N @ 2016-10-04 12:56 UTC (permalink / raw)
To: netdev
Cc: Mark Rutland, devicetree, Florian Fainelli, Mugunthan V N,
Tony Lindgren, Sekhar Nori, linux-kernel, Russell King,
Rob Herring, linux-omap, David Miller, linux-arm-kernel
In-Reply-To: <20161004125607.10569-1-mugunthanvnm@ti.com>
Add documention of ti,impedance-control which can be used to
correct MAC impedance mismatch using phy extended registers.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Documentation/devicetree/bindings/net/ti,dp83867.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt
index 5d21141..85bf945 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83867.txt
+++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt
@@ -9,6 +9,18 @@ Required properties:
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
+Optional property:
+ - ti,min-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ minimum value (35 ohms).
+ - ti,max-output-impedance - MAC Interface Impedance control to set
+ the programmable output impedance to
+ maximum value (70 ohms).
+
+Note: ti,min-output-impedance and ti,max-output-impedance are mutually
+ exclusive. When both properties are present ti,max-output-impedance
+ takes precedence.
+
Default child nodes are standard Ethernet PHY device
nodes as described in Documentation/devicetree/bindings/net/phy.txt
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v2 3/4] ARM: dts: dra72-evm-revc: fix correct phy delay and impedance settings
From: Mugunthan V N @ 2016-10-04 12:56 UTC (permalink / raw)
To: netdev
Cc: devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori, Mugunthan V N
In-Reply-To: <20161004125607.10569-1-mugunthanvnm@ti.com>
The default impedance settings of the phy is not the optimal
value, due to this the second ethernet is not working. Fix it
with correct values which makes the second ethernet port to work.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index f9cfd3b..d626cd7 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -62,6 +62,7 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-imepdance;
};
dp83867_1: ethernet-phy@3 {
@@ -69,5 +70,6 @@
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,min-output-imepdance;
};
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
* [PATCH v2 4/4] ARM: dts: dra72-evm-revc: fix correct phy delay
From: Mugunthan V N @ 2016-10-04 12:56 UTC (permalink / raw)
To: netdev
Cc: devicetree, linux-kernel, linux-omap, linux-arm-kernel,
Rob Herring, Mark Rutland, Tony Lindgren, Russell King,
Florian Fainelli, David Miller, Sekhar Nori, Mugunthan V N
In-Reply-To: <20161004125607.10569-1-mugunthanvnm@ti.com>
The current delay settings of the phy are not the optimal value,
fix it with correct values.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
arch/arm/boot/dts/dra72-evm-revc.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index d626cd7..8472a8c 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -59,16 +59,16 @@
&davinci_mdio {
dp83867_0: ethernet-phy@2 {
reg = <2>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
dp83867_1: ethernet-phy@3 {
reg = <3>;
- ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
- ti,tx-internal-delay = <DP83867_RGMIIDCTL_1_NS>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
ti,min-output-imepdance;
};
--
2.10.0.372.g6fe1b14
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox