* Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets
From: David Miller @ 2016-09-28 12:16 UTC (permalink / raw)
To: jhs
Cc: gorcunov, eric.dumazet, dsa, netdev, linux-kernel, kuznet,
jmorris, yoshfuji, kaber, avagin, stephen
In-Reply-To: <60b2e075-e852-f0c2-c188-631f547791d5@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Wed, 28 Sep 2016 08:09:28 -0400
> On 16-09-28 08:07 AM, David Miller wrote:
>
>> Right, it would be legal for an existing user to have code that
>> explicitly initializes every member of the structure, including 'pad'.
>> So we have to keep that member around, at a minimum, for their sake.
>>
>
> I think we need to start labelling any new pad fields added as
> "Not UAPI. Do not fsck fondle this".
They must initialize it to zero.
^ permalink raw reply
* Re: [PATCH RFC 3/6] net: phy: Threaded interrupts allow some simplification
From: Sergei Shtylyov @ 2016-09-28 12:13 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot; +Cc: netdev
In-Reply-To: <7997d337-cd0f-ab39-1f53-df996063932b@cogentembedded.com>
On 9/28/2016 2:46 PM, Sergei Shtylyov wrote:
>> The PHY interrupts are now handled in a threaded interrupt handler,
>> which can sleep. The work queue is no longer needed, phy_change() can
>> be called directly. Additionally, none of the callers of
>> phy_mac_interrupt() did so in interrupt context, so fully remove the
>
> I did intend to call it from interrupt context (from the ravb driver).
>
>> work queue, and document that phy_mac_interrupt() should not be called
>> in interrupt context.
>
> It was intentionally made callable from the interrupt context, I'd prefer
> if you wouldn't change that.
OTOH, it's still not very handy to call because of the 'new_link'
parameter which I'm not sure I can provide...
>> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> [...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCHv2 net 0/5] sctp: some fixes of prsctp polices
From: David Miller @ 2016-09-28 12:13 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, vyasevich, daniel
In-Reply-To: <cover.1475059350.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 28 Sep 2016 18:46:27 +0800
> This patchset is to improve some codes about prsctp polices, and also
> to fix some issues.
>
> v1->v2:
> - wrap the check of chunk->sent_count in a macro:
> sctp_chunk_retransmitted in patch 2/5.
This series is a mix of bug fixes (patch #1) which should be targetting
'net' and simplifications/cleanups (patch #2-5) which should be targetting
'net-next'.
Please do not mix things up like this, and submit patches targetting
the appropriate tree.
^ permalink raw reply
* Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets
From: Jamal Hadi Salim @ 2016-09-28 12:09 UTC (permalink / raw)
To: David Miller, gorcunov
Cc: eric.dumazet, dsa, netdev, linux-kernel, kuznet, jmorris,
yoshfuji, kaber, avagin, stephen
In-Reply-To: <20160928.080701.1194277590163223525.davem@davemloft.net>
On 16-09-28 08:07 AM, David Miller wrote:
> Right, it would be legal for an existing user to have code that
> explicitly initializes every member of the structure, including 'pad'.
> So we have to keep that member around, at a minimum, for their sake.
>
I think we need to start labelling any new pad fields added as
"Not UAPI. Do not fsck fondle this".
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets
From: David Miller @ 2016-09-28 12:09 UTC (permalink / raw)
To: jhs
Cc: gorcunov, eric.dumazet, dsa, netdev, linux-kernel, kuznet,
jmorris, yoshfuji, kaber, avagin, stephen
In-Reply-To: <696ed966-991c-30f7-9a1c-d91a94c9304c@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Wed, 28 Sep 2016 08:06:51 -0400
> I understood well your point;-> Maybe my response was not clear:
> _nobody should be fscking fondling pad fields_ setting them or
> otherwise.
Especially considering potential future uses of the field, existing
users absolutely must zero out the field.
Whether this is via a memset() of the entire structure or via
an explicit initialization to zero is their choice.
So setting 'pad' is in fact valid.
^ permalink raw reply
* Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets
From: David Miller @ 2016-09-28 12:07 UTC (permalink / raw)
To: gorcunov
Cc: jhs, eric.dumazet, dsa, netdev, linux-kernel, kuznet, jmorris,
yoshfuji, kaber, avagin, stephen
In-Reply-To: <20160928112703.GW1876@uranus.lan>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Wed, 28 Sep 2016 14:27:03 +0300
> On Wed, Sep 28, 2016 at 07:06:26AM -0400, Jamal Hadi Salim wrote:
>> >
>> > This structure is uapi, so anyone has complete rights to reference
>> > @pad in the userspace programs. Sure it would be more clear to remove
>> > the @pad completely, but if we choose so I think it's better to do
>> > on top instead and then if someone complain we can easily revert
>> > the single trivial commit instead of this big patch.
>>
>> I am conflicted.
>> A field labelled "pad" does not appear to be valid as "UAPI". It is
>> a cosmetic indicator. If you did sizeof() with or without it being
>> present the value doesnt change.
>
> I think you miss the point what I'm trying to say: currently end-user
> may have reference to this member (for any reason) and his program
> will compile and run. If we change the name the compilation procedure
> fails and this will break API. Yes, referrning @pad is bad idea for
> userspace code, and yes (!) better to simply rename it but lets do
> that later, on top, so that if we break something in userspace
> we could easily revert the oneline change.
Right, it would be legal for an existing user to have code that
explicitly initializes every member of the structure, including 'pad'.
So we have to keep that member around, at a minimum, for their sake.
>> BTW: There is at least one major structure in inet diag has a hole
>> today and doesnt have a padding indicator.
>>
>> > If protocol goes over u8 then complete inet_diag_req_v2 structure will
>> > have to be reworked becaue @sdiag_protocol is u8 as well. IOW, once
>> > someone liftup IPPROTO_MAX > 255, he will notice the problem immediately
>> > because diag for such module simply stop working properly.
>> >
>>
>> ok.
Indeed, we need a 16-bit value here.
^ permalink raw reply
* Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets
From: Jamal Hadi Salim @ 2016-09-28 12:06 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Eric Dumazet, David Ahern, netdev, linux-kernel, David Miller,
kuznet, jmorris, yoshfuji, kaber, avagin, stephen
In-Reply-To: <20160928112703.GW1876@uranus.lan>
On 16-09-28 07:27 AM, Cyrill Gorcunov wrote:
> On Wed, Sep 28, 2016 at 07:06:26AM -0400, Jamal Hadi Salim wrote:
>>>
>>> This structure is uapi, so anyone has complete rights to reference
>>> @pad in the userspace programs. Sure it would be more clear to remove
>>> the @pad completely, but if we choose so I think it's better to do
>>> on top instead and then if someone complain we can easily revert
>>> the single trivial commit instead of this big patch.
>>
>> I am conflicted.
>> A field labelled "pad" does not appear to be valid as "UAPI". It is
>> a cosmetic indicator. If you did sizeof() with or without it being
>> present the value doesnt change.
>
> I think you miss the point what I'm trying to say: currently end-user
> may have reference to this member (for any reason) and his program
> will compile and run. If we change the name the compilation procedure
> fails and this will break API. Yes, referrning @pad is bad idea for
> userspace code, and yes (!) better to simply rename it but lets do
> that later, on top, so that if we break something in userspace
> we could easily revert the oneline change.
>
I understood well your point;-> Maybe my response was not clear:
_nobody should be fscking fondling pad fields_ setting them or
otherwise.
Maybe let these programs fail. I asked if you knew any such app which
did anything with a pad field.
cheers,
jamal
^ permalink raw reply
* [PATCH net-next 2/2] net: phy: Add PHY Auto/Mdi/Mdix set driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-09-28 12:01 UTC (permalink / raw)
To: netdev; +Cc: f.fainelli, Allan.Nielsen, andrew, Raju Lakkaraju
In-Reply-To: <1475064078-22310-1-git-send-email-Raju.Lakkaraju@microsemi.com>
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
To connect two ports of the same configuration (MDI to MDI or
MDI-X to MDI-X) with a 10/100/1000 Mbit/s connection, an
Ethernet crossover cable is needed to cross over the transmit
and receive signals in the cable, so that they are matched at
the connector level.
When connecting an MDI port to an MDI-X port a straight through
cable is used while to connect two MDI ports or two MDI-X ports
a crossover cable must be used. Conventionally MDI is used on end
devices while MDI-X is used on hubs and switches
Auto MDI-X automatically detects the required cable connection
type and configures the connection appropriately, removing the
need for crossover cables to interconnect switches or connecting
PCs peer-to-peer.
VSC8531 PHY supports Auto MDI-x, MDI and MDI-X configuraion by
driver set mdix function.
Tested on Beaglebone Black with VSC 8531 PHY.
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
---
drivers/net/phy/mscc.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index ca6ea23..dbf8434 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -26,6 +26,11 @@ enum rgmii_rx_clock_delay {
/* Microsemi VSC85xx PHY registers */
/* IEEE 802. Std Registers */
+#define MSCC_PHY_BYPASS_CONTROL 18
+#define DISABLE_HP_AUTO_MDIX_MASK 0x0080
+#define DISABLE_PAIR_SWAP_CORR_MASK 0x0020
+#define DISABLE_POLARITY_CORR_MASK 0x0010
+
#define MSCC_PHY_EXT_PHY_CNTL_1 23
#define MAC_IF_SELECTION_MASK 0x1800
#define MAC_IF_SELECTION_GMII 0
@@ -41,8 +46,16 @@ enum rgmii_rx_clock_delay {
#define MSCC_EXT_PAGE_ACCESS 31
#define MSCC_PHY_PAGE_STANDARD 0x0000 /* Standard registers */
+#define MSCC_PHY_PAGE_EXTENDED 0x0001 /* Extended registers */
#define MSCC_PHY_PAGE_EXTENDED_2 0x0002 /* Extended reg - page 2 */
+/* Extended Page 1 Registers */
+#define MSCC_PHY_EXT_MODE_CNTL 19
+#define FORCE_MDI_CROSSOVER_MASK 0x000C
+#define FORCE_MDI_CROSSOVER_MDIX 0x000C
+#define FORCE_MDI_CROSSOVER_MDI 0x0008
+#define FORCE_MDI_CROSSOVER_NORMAL 0x0000
+
/* Extended Page 2 Registers */
#define MSCC_PHY_RGMII_CNTL 20
#define RGMII_RX_CLK_DELAY_MASK 0x0070
@@ -73,6 +86,47 @@ static int vsc85xx_phy_page_set(struct phy_device *phydev, u8 page)
return rc;
}
+static int vsc85xx_mdix_set(struct phy_device *phydev,
+ u8 mdix)
+{
+ int rc;
+ u16 reg_val;
+
+ reg_val = phy_read(phydev, MSCC_PHY_BYPASS_CONTROL);
+ if ((mdix == ETH_TP_MDI) || (mdix == ETH_TP_MDI_X)) {
+ reg_val |= (DISABLE_PAIR_SWAP_CORR_MASK |
+ DISABLE_POLARITY_CORR_MASK |
+ DISABLE_HP_AUTO_MDIX_MASK);
+ } else {
+ reg_val &= ~(DISABLE_PAIR_SWAP_CORR_MASK |
+ DISABLE_POLARITY_CORR_MASK |
+ DISABLE_HP_AUTO_MDIX_MASK);
+ }
+ rc = phy_write(phydev, MSCC_PHY_BYPASS_CONTROL, reg_val);
+ if (rc != 0)
+ goto out_unlock;
+
+ rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_EXTENDED);
+ if (rc != 0)
+ goto out_unlock;
+
+ reg_val = phy_read(phydev, MSCC_PHY_EXT_MODE_CNTL);
+ reg_val &= ~(FORCE_MDI_CROSSOVER_MASK);
+ if (mdix == ETH_TP_MDI)
+ reg_val |= FORCE_MDI_CROSSOVER_MDI;
+ else if (mdix == ETH_TP_MDI_X)
+ reg_val |= FORCE_MDI_CROSSOVER_MDIX;
+ rc = phy_write(phydev, MSCC_PHY_EXT_MODE_CNTL, reg_val);
+ if (rc != 0)
+ goto out_unlock;
+
+ rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_STANDARD);
+
+out_unlock:
+
+ return rc;
+}
+
static int vsc85xx_wol_set(struct phy_device *phydev,
struct ethtool_wolinfo *wol)
{
@@ -227,6 +281,7 @@ static int vsc85xx_default_config(struct phy_device *phydev)
int rc;
u16 reg_val;
+ phydev->mdix = ETH_TP_MDI_AUTO;
mutex_lock(&phydev->lock);
rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_EXTENDED_2);
if (rc != 0)
@@ -288,6 +343,19 @@ static int vsc85xx_config_intr(struct phy_device *phydev)
return rc;
}
+static int vsc85xx_config_aneg(struct phy_device *phydev)
+{
+ int rc;
+
+ rc = vsc85xx_mdix_set(phydev, phydev->mdix);
+ if (rc < 0)
+ return rc;
+
+ rc = genphy_config_aneg(phydev);
+
+ return rc;
+}
+
/* Microsemi VSC85xx PHYs */
static struct phy_driver vsc85xx_driver[] = {
{
@@ -298,7 +366,7 @@ static struct phy_driver vsc85xx_driver[] = {
.flags = PHY_HAS_INTERRUPT,
.soft_reset = &genphy_soft_reset,
.config_init = &vsc85xx_config_init,
- .config_aneg = &genphy_config_aneg,
+ .config_aneg = &vsc85xx_config_aneg,
.aneg_done = &genphy_aneg_done,
.read_status = &genphy_read_status,
.ack_interrupt = &vsc85xx_ack_interrupt,
@@ -316,7 +384,7 @@ static struct phy_driver vsc85xx_driver[] = {
.flags = PHY_HAS_INTERRUPT,
.soft_reset = &genphy_soft_reset,
.config_init = &vsc85xx_config_init,
- .config_aneg = &genphy_config_aneg,
+ .config_aneg = &vsc85xx_config_aneg,
.aneg_done = &genphy_aneg_done,
.read_status = &genphy_read_status,
.ack_interrupt = &vsc85xx_ack_interrupt,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/2] net: phy: Add Wake-on-LAN driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-09-28 12:01 UTC (permalink / raw)
To: netdev; +Cc: f.fainelli, Allan.Nielsen, andrew, Raju Lakkaraju
In-Reply-To: <1475064078-22310-1-git-send-email-Raju.Lakkaraju@microsemi.com>
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Wake-on-LAN (WoL) is an Ethernet networking standard that allows
a computer/device to be turned on or awakened by a network message.
VSC8531 PHY can support this feature configure by driver set function.
WoL status get by driver get function.
Tested on Beaglebone Black with VSC 8531 PHY.
Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
---
drivers/net/phy/mscc.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 132 insertions(+)
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index d350deb..ca6ea23 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -11,6 +11,7 @@
#include <linux/mdio.h>
#include <linux/mii.h>
#include <linux/phy.h>
+#include <linux/netdevice.h>
enum rgmii_rx_clock_delay {
RGMII_RX_CLK_DELAY_0_2_NS = 0,
@@ -35,6 +36,7 @@ enum rgmii_rx_clock_delay {
#define MII_VSC85XX_INT_MASK 25
#define MII_VSC85XX_INT_MASK_MASK 0xa000
+#define MII_VSC85XX_INT_MASK_WOL 0x0040
#define MII_VSC85XX_INT_STATUS 26
#define MSCC_EXT_PAGE_ACCESS 31
@@ -46,6 +48,19 @@ enum rgmii_rx_clock_delay {
#define RGMII_RX_CLK_DELAY_MASK 0x0070
#define RGMII_RX_CLK_DELAY_POS 4
+#define MSCC_PHY_WOL_LOWER_MAC_ADDR 21
+#define MSCC_PHY_WOL_MID_MAC_ADDR 22
+#define MSCC_PHY_WOL_UPPER_MAC_ADDR 23
+#define MSCC_PHY_WOL_LOWER_PASSWD 24
+#define MSCC_PHY_WOL_MID_PASSWD 25
+#define MSCC_PHY_WOL_UPPER_PASSWD 26
+
+#define MSCC_PHY_WOL_MAC_CONTROL 27
+#define EDGE_RATE_CNTL_POS 5
+#define EDGE_RATE_CNTL_MASK 0x00E0
+#define SECURE_ON_ENABLE 0x8000
+#define SECURE_ON_PASSWD_LEN_4 0x4000
+
/* Microsemi PHY ID's */
#define PHY_ID_VSC8531 0x00070570
#define PHY_ID_VSC8541 0x00070770
@@ -58,6 +73,119 @@ static int vsc85xx_phy_page_set(struct phy_device *phydev, u8 page)
return rc;
}
+static int vsc85xx_wol_set(struct phy_device *phydev,
+ struct ethtool_wolinfo *wol)
+{
+ int rc;
+ u16 reg_val;
+ struct ethtool_wolinfo *wol_conf = wol;
+
+ mutex_lock(&phydev->lock);
+ rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_EXTENDED_2);
+ if (rc != 0)
+ goto out_unlock;
+
+ if (wol->wolopts & WAKE_MAGIC) {
+ /* Store the device address for the magic packet */
+ reg_val = phydev->attached_dev->dev_addr[4] << 8;
+ reg_val |= phydev->attached_dev->dev_addr[5];
+ phy_write(phydev, MSCC_PHY_WOL_LOWER_MAC_ADDR, reg_val);
+ reg_val = phydev->attached_dev->dev_addr[2] << 8;
+ reg_val |= phydev->attached_dev->dev_addr[3];
+ phy_write(phydev, MSCC_PHY_WOL_MID_MAC_ADDR, reg_val);
+ reg_val = phydev->attached_dev->dev_addr[0] << 8;
+ reg_val |= phydev->attached_dev->dev_addr[1];
+ phy_write(phydev, MSCC_PHY_WOL_UPPER_MAC_ADDR, reg_val);
+ } else {
+ phy_write(phydev, MSCC_PHY_WOL_LOWER_MAC_ADDR, 0);
+ phy_write(phydev, MSCC_PHY_WOL_MID_MAC_ADDR, 0);
+ phy_write(phydev, MSCC_PHY_WOL_UPPER_MAC_ADDR, 0);
+ }
+
+ reg_val = phy_read(phydev, MSCC_PHY_WOL_MAC_CONTROL);
+ if (wol_conf->wolopts & WAKE_MAGICSECURE)
+ reg_val |= SECURE_ON_ENABLE;
+ else
+ reg_val &= ~SECURE_ON_ENABLE;
+ phy_write(phydev, MSCC_PHY_WOL_MAC_CONTROL, reg_val);
+
+ if (wol_conf->wolopts & WAKE_MAGICSECURE) {
+ reg_val = wol_conf->sopass[4] << 8;
+ reg_val |= wol_conf->sopass[5];
+ phy_write(phydev, MSCC_PHY_WOL_LOWER_PASSWD, reg_val);
+ reg_val = wol_conf->sopass[2] << 8;
+ reg_val |= wol_conf->sopass[3];
+ phy_write(phydev, MSCC_PHY_WOL_MID_PASSWD, reg_val);
+ reg_val = wol_conf->sopass[0] << 8;
+ reg_val |= wol_conf->sopass[1];
+ phy_write(phydev, MSCC_PHY_WOL_UPPER_PASSWD, reg_val);
+ } else {
+ phy_write(phydev, MSCC_PHY_WOL_LOWER_PASSWD, 0);
+ phy_write(phydev, MSCC_PHY_WOL_MID_PASSWD, 0);
+ phy_write(phydev, MSCC_PHY_WOL_UPPER_PASSWD, 0);
+ }
+
+ rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_STANDARD);
+ if (rc != 0)
+ goto out_unlock;
+
+ if (wol->wolopts & WAKE_MAGIC) {
+ /* Enable the WOL interrupt */
+ reg_val = phy_read(phydev, MII_VSC85XX_INT_MASK);
+ reg_val |= MII_VSC85XX_INT_MASK_WOL;
+ rc = phy_write(phydev, MII_VSC85XX_INT_MASK, reg_val);
+ if (rc != 0)
+ goto out_unlock;
+ } else {
+ /* Disable the WOL interrupt */
+ reg_val = phy_read(phydev, MII_VSC85XX_INT_MASK);
+ reg_val &= (~MII_VSC85XX_INT_MASK_WOL);
+ rc = phy_write(phydev, MII_VSC85XX_INT_MASK, reg_val);
+ if (rc != 0)
+ goto out_unlock;
+ }
+ /* Clear WOL iterrupt status */
+ reg_val = phy_read(phydev, MII_VSC85XX_INT_STATUS);
+
+out_unlock:
+ mutex_unlock(&phydev->lock);
+
+ return rc;
+}
+
+static void vsc85xx_wol_get(struct phy_device *phydev,
+ struct ethtool_wolinfo *wol)
+{
+ int rc;
+ u16 reg_val;
+ struct ethtool_wolinfo *wol_conf = wol;
+
+ mutex_lock(&phydev->lock);
+ rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_EXTENDED_2);
+ if (rc != 0)
+ goto out_unlock;
+
+ reg_val = phy_read(phydev, MSCC_PHY_WOL_MAC_CONTROL);
+ if (reg_val & SECURE_ON_ENABLE)
+ wol_conf->wolopts |= WAKE_MAGICSECURE;
+ if (wol_conf->wolopts & WAKE_MAGICSECURE) {
+ reg_val = phy_read(phydev, MSCC_PHY_WOL_LOWER_PASSWD);
+ wol_conf->sopass[5] = reg_val & 0x00ff;
+ wol_conf->sopass[4] = (reg_val & 0xff00) >> 8;
+ reg_val = phy_read(phydev, MSCC_PHY_WOL_MID_PASSWD);
+ wol_conf->sopass[3] = reg_val & 0x00ff;
+ wol_conf->sopass[2] = (reg_val & 0xff00) >> 8;
+ reg_val = phy_read(phydev, MSCC_PHY_WOL_UPPER_PASSWD);
+ wol_conf->sopass[1] = reg_val & 0x00ff;
+ wol_conf->sopass[0] = (reg_val & 0xff00) >> 8;
+ }
+
+ rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_STANDARD);
+
+out_unlock:
+ mutex_unlock(&phydev->lock);
+}
+
static int vsc85xx_mac_if_set(struct phy_device *phydev,
phy_interface_t interface)
{
@@ -177,6 +305,8 @@ static struct phy_driver vsc85xx_driver[] = {
.config_intr = &vsc85xx_config_intr,
.suspend = &genphy_suspend,
.resume = &genphy_resume,
+ .set_wol = &vsc85xx_wol_set,
+ .get_wol = &vsc85xx_wol_get,
},
{
.phy_id = PHY_ID_VSC8541,
@@ -193,6 +323,8 @@ static struct phy_driver vsc85xx_driver[] = {
.config_intr = &vsc85xx_config_intr,
.suspend = &genphy_suspend,
.resume = &genphy_resume,
+ .set_wol = &vsc85xx_wol_set,
+ .get_wol = &vsc85xx_wol_get,
}
};
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 0/2] net: phy: Add WoL and Auto Mdix drivers for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-09-28 12:01 UTC (permalink / raw)
To: netdev; +Cc: f.fainelli, Allan.Nielsen, andrew, Raju Lakkaraju
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
This series adds support to the Wake-on-LAN and Auto/Mdi-x set drivers
for Microsemi PHYs.
Patch 1/2:
Wake-on-LAN (WoL) is an Ethernet networking standard that allows
a computer/device to be turned on or awakened by a network message.
VSC8531 PHY can support this feature configure by driver set function.
WoL status get by driver get function.
Patch 2/2:
To connect two ports of the same configuration (MDI to MDI or
MDI-X to MDI-X) with a 10/100/1000 Mbit/s connection, an
Ethernet crossover cable is needed to cross over the transmit
and receive signals in the cable, so that they are matched at
the connector level.
When connecting an MDI port to an MDI-X port a straight through
cable is used while to connect two MDI ports or two MDI-X ports
a crossover cable must be used. Conventionally MDI is used on end
devices while MDI-X is used on hubs and switches
Auto MDI-X automatically detects the required cable connection
type and configures the connection appropriately, removing the
need for crossover cables to interconnect switches or connecting
PCs peer-to-peer.
VSC8531 PHY supports Auto MDI-x, MDI and MDI-X configuraion by
driver set loopback function.
Tested on Beaglebone Black with VSC 8531 PHY.
Raju Lakkaraju (2):
net: phy: Add Wake-on-LAN driver for Microsemi PHYs.
net: phy: Add PHY Auto/Mdi/Mdix set driver for Microsemi PHYs.
drivers/net/phy/mscc.c | 204 ++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 202 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH v2 net] net: skbuff: skb_vlan_push: Fix wrong unwinding of skb->data after __vlan_insert_tag call
From: Shmulik Ladkani @ 2016-09-28 11:56 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David S. Miller, Pravin Shelar, netdev, Shmulik Ladkani,
Jiri Pirko
In-Reply-To: <57EB9BE0.4080903@iogearbox.net>
Hi,
On Wed, 28 Sep 2016 12:30:56 +0200, daniel@iogearbox.net wrote:
> > @@ -4608,6 +4608,8 @@ int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
> >
> > skb->protocol = skb->vlan_proto;
> > skb->mac_len += VLAN_HLEN;
> > + if (offset)
> > + offset += VLAN_HLEN;
> >
> > skb_postpush_rcsum(skb, skb->data + (2 * ETH_ALEN), VLAN_HLEN);
> > __skb_pull(skb, offset);
>
> This looks much better indeed than your v1 of this patch.
Yep, after some meditation and history digging I happened to notice I
was barking at the wrong tree.
> So the issue might only be visible to act_vlan as the other remaining user of
> skb_vlan_push().
Yes, this is correct. I'll amend the log message to express that.
The bug occurs for callers of skb_vlan_push() whose data is not
pointing at mac_header.
> My only question would be:
> what about __skb_vlan_pop(), wouldn't that then need the same adjustment
> a la offset -= VLAN_HLEN?
Well, theoretically, yes; but caller may expect 2 different things:
(assuming tags are in-payload)
(1) suppose upon entry we have
DA,SA,0x8100,TCI,0x0800,
^ ^
mac_hdr data
initial offset is 18, and after current unwinding code we'll get
DA,SA,0x0800,4_bytes,
^ ^
mac_hdr data
which is probably incorrect, adjustment 'offset -= VLAN_HLEN' is needed.
(2) suppose upon entry we have
DA,SA,0x8100,TCI,0x0800
^ ^
mac_hdr data
initial offset is 14, and after current unwinding code we'll get
DA,SA,0x0800,
^ ^
mac_hdr data
which is probably what user has intended.
(had we adjusted offset to be 10, 'data' would point into SA)
From test I've made using act_vlan upon ingress on QinQ tags, existing call
provides data as in (2).
Thoughts?
Should we adjust "offset" back, only if resulting offset is >=14 ?
Thanks,
Shmulik
^ permalink raw reply
* Re: [PATCH 0/5] ISDN-Gigaset: Fine-tuning for three function implementations
From: Paul Bolle @ 2016-09-28 11:56 UTC (permalink / raw)
To: SF Markus Elfring
Cc: gigaset307x-common, netdev, Karsten Keil, LKML, kernel-janitors,
Julia Lawall
In-Reply-To: <6d4bbb77-914f-19b8-a1a9-2731d1158612@users.sourceforge.net>
On Mon, 2016-09-26 at 17:37 +0200, SF Markus Elfring wrote:
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (5):
> Use kmalloc_array() in two functions
> Improve another size determination in gigaset_initcs()
> Delete an error message for a failed memory allocation
> Release memory in gigaset_initcs() after an allocation failure
> Enclose two expressions for the sizeof operator by parentheses
>
> drivers/isdn/gigaset/common.c | 31 ++++++++++++++++---------------
> 1 file changed, 16 insertions(+), 15 deletions(-)
Two of the five patches introduced bugs. The rest of the series isn't
free of various nits either. Of course, I was in no mood to be lenient
when I looked at those three patches.
I won't take any of these patches, sorry.
Paul Bolle
^ permalink raw reply
* Re: [PATCH v4 net-next] tcp: Change txhash on every SYN and RTO retransmit
From: David Miller @ 2016-09-28 11:52 UTC (permalink / raw)
To: brakmo; +Cc: netdev, kernel-team, eric.dumazet, ycheng, ncardwell
In-Reply-To: <20160928020337.3057238-1-brakmo@fb.com>
From: Lawrence Brakmo <brakmo@fb.com>
Date: Tue, 27 Sep 2016 19:03:37 -0700
> The current code changes txhash (flowlables) on every retransmitted
> SYN/ACK, but only after the 2nd retransmitted SYN and only after
> tcp_retries1 RTO retransmits.
>
> With this patch:
> 1) txhash is changed with every SYN retransmits
> 2) txhash is changed with every RTO.
>
> The result is that we can start re-routing around failed (or very
> congested paths) as soon as possible. Otherwise application health
> checks may fail and the connection may be terminated before we start
> to change txhash.
>
> v4: Removed sysctl, txhash is changed for all RTOs
> v3: Removed text saying default value of sysctl is 0 (it is 100)
> v2: Added sysctl documentation and cleaned code
>
> Tested with packetdrill tests
>
> Signed-off-by: Lawrence Brakmo <brakmo@fb.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6 addrconf: enable use of proc_dointvec_minmax in addrconf_sysctl
From: David Miller @ 2016-09-28 11:52 UTC (permalink / raw)
To: zenczykowski; +Cc: maze, netdev, ek, lorenzo, hannes
In-Reply-To: <20160928.074901.901607987499248966.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 28 Sep 2016 07:49:01 -0400 (EDT)
> From: Maciej Żenczykowski <zenczykowski@gmail.com>
> Date: Tue, 27 Sep 2016 05:16:45 -0700
>
>> From: Maciej Żenczykowski <maze@google.com>
>>
>> Signed-off-by: Maciej Żenczykowski <maze@google.com>
>
> I was about to ask you to submit this patch alongside an actual
> addition of a proc_dointvec_minmax user to the table.
>
> But upon second checking there is one, indirectly via
> addrconf_sysctl_mtu().
And actually these cases use a dummy sysctl blob on the stack to
provide the min/max values to proc_dointvec_minmax. And they do
it _EXACTLY_ because the extra pointers are for the netns pointer
and a pointer to the idev.
And any user envisioned can do the same thing, use a trampoline
like the existing cases do.
^ permalink raw reply
* Re: [PATCH] ipv6 addrconf: enable use of proc_dointvec_minmax in addrconf_sysctl
From: David Miller @ 2016-09-28 11:49 UTC (permalink / raw)
To: zenczykowski; +Cc: maze, netdev, ek, lorenzo, hannes
In-Reply-To: <1474978605-28116-1-git-send-email-zenczykowski@gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Tue, 27 Sep 2016 05:16:45 -0700
> From: Maciej Żenczykowski <maze@google.com>
>
> Signed-off-by: Maciej Żenczykowski <maze@google.com>
I was about to ask you to submit this patch alongside an actual
addition of a proc_dointvec_minmax user to the table.
But upon second checking there is one, indirectly via
addrconf_sysctl_mtu().
I should never have to search and figure things out like that. It
should be obvious or explained in the commit message.
You must explain in detail what the dependency is, why you
have to make this change, how you made it, and why you made
it that way.
Especially in this case, your empty commit message is really
not appropriate.
Thanks.
^ permalink raw reply
* Re: [PATCH RFC 3/6] net: phy: Threaded interrupts allow some simplification
From: Sergei Shtylyov @ 2016-09-28 11:46 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot; +Cc: netdev
In-Reply-To: <1475051544-18561-4-git-send-email-andrew@lunn.ch>
Hello.
On 9/28/2016 11:32 AM, Andrew Lunn wrote:
> The PHY interrupts are now handled in a threaded interrupt handler,
> which can sleep. The work queue is no longer needed, phy_change() can
> be called directly. Additionally, none of the callers of
> phy_mac_interrupt() did so in interrupt context, so fully remove the
I did intend to call it from interrupt context (from the ravb driver).
> work queue, and document that phy_mac_interrupt() should not be called
> in interrupt context.
It was intentionally made callable from the interrupt context, I'd prefer
if you wouldn't change that.
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/5] ISDN-Gigaset: Delete an error message for a failed memory allocation
From: Paul Bolle @ 2016-09-28 11:42 UTC (permalink / raw)
To: Tilman Schmidt, SF Markus Elfring
Cc: gigaset307x-common, netdev, Karsten Keil, LKML, kernel-janitors,
Julia Lawall, Wolfram Sang
In-Reply-To: <1474973851.1608488.738293513.6CA62927@webmail.messagingengine.com>
On Tue, 2016-09-27 at 12:57 +0200, Tilman Schmidt wrote:
> On Mon, Sep 26, 2016, at 17:42, SF Markus Elfring wrote:
> > Omit an extra message for a memory allocation failure in this
> > function.
> >
> > Link:
> > http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-R
> > efactor_Strings-WSang_0.pdf
> >
> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
>
> The patch is fine but the link in the commit message is irrelevant.
> Please remove it.
> (Yes, I read through the whole presentation to verify that. It was fun,
> even.)
Agree.
Except this patch assumes the superfluous braces would be removed in
4/5. But it turns out that other patch must be dropped. It would have
been better to remove the braces in this patch.
Paul Bolle
^ permalink raw reply
* Re: [PATCH RFC 2/6] net: phy: Use threaded IRQ, to allow IRQ from sleeping devices
From: Sergei Shtylyov @ 2016-09-28 11:38 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot; +Cc: netdev
In-Reply-To: <1475051544-18561-3-git-send-email-andrew@lunn.ch>
Hello.
On 9/28/2016 11:32 AM, Andrew Lunn wrote:
> The interrupt lines from PHYs maybe connected to I2C bus expanders, or
> from switches on MDIO busses. Such interrupts are sourced from devices
> which sleep, so use threaded interrupts. Threaded interrupts require
> that the interrupt requester also uses the threaded API. Change the
> phylib to use the threaded API, which is backwards compatible with
> none-threaded IRQs.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> drivers/net/phy/phy.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index c6f66832a1a6..5c29ed72f721 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -722,10 +722,9 @@ phy_err:
> int phy_start_interrupts(struct phy_device *phydev)
> {
> atomic_set(&phydev->irq_disable, 0);
> - if (request_irq(phydev->irq, phy_interrupt,
> - IRQF_SHARED,
> - "phy_interrupt",
> - phydev) < 0) {
> + if (request_threaded_irq(phydev->irq, NULL, phy_interrupt,
> + IRQF_ONESHOT, "phy_interrupt",
What about IRQF_SHARED?
> + phydev) < 0) {
> pr_warn("%s: Can't get IRQ %d (PHY)\n",
> phydev->mdio.bus->name, phydev->irq);
> phydev->irq = PHY_POLL;
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/5] ISDN-Gigaset: Use kmalloc_array() in two functions
From: Paul Bolle @ 2016-09-28 11:37 UTC (permalink / raw)
To: SF Markus Elfring
Cc: gigaset307x-common, netdev, Karsten Keil, LKML, kernel-janitors,
Julia Lawall
In-Reply-To: <4fb300f1-ff02-7983-464f-fcbca5919dac@users.sourceforge.net>
On Mon, 2016-09-26 at 17:38 +0200, SF Markus Elfring wrote:
> * Multiplications for the size determination of memory allocations
> indicated that array data structures should be processed.
> Thus use the corresponding function "kmalloc_array".
Was the current code incorrect? What makes kmalloc_array() better? None
of this is obvious to me.
I'm not going to change code just because some checker suggests to do
so.
> This issue was detected by using the Coccinelle software.
So? And which coccinelle script was actually used? I couldn't spot a
coccinelle script doing that in the current tree.
> * Replace the specification of a data structure by a pointer dereference
> to make the corresponding size determination a bit safer according to
> the Linux coding style convention.
I'm not happy with you mixing this with the above, less trivial,
change.
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> --- a/drivers/isdn/gigaset/common.c
> +++ b/drivers/isdn/gigaset/common.c
> @@ -709,8 +709,7 @@ struct cardstate *gigaset_initcs(struct gigaset_driver *drv, int channels,
>
> cs->mode = M_UNKNOWN;
> cs->mstate = MS_UNINITIALIZED;
> -
Unrelated whitespace change.
> - cs->bcs = kmalloc(channels * sizeof(struct bc_state), GFP_KERNEL);
> + cs->bcs = kmalloc_array(channels, sizeof(*cs->bcs), GFP_KERNEL);
For the record: "channels" is basically hardcoded in the three gigaset
hardware drivers.
> cs->inbuf = kmalloc(sizeof(struct inbuf_t), GFP_KERNEL);
> if (!cs->bcs || !cs->inbuf) {
> pr_err("out of memory\n");
> @@ -1089,8 +1088,7 @@ struct gigaset_driver
> *gigaset_initdriver(unsigned minor, unsigned minors,
> drv->ops = ops;
> drv->owner = owner;
> INIT_LIST_HEAD(&drv->list);
> -
Again unrelated whitespace change.
> - drv->cs = kmalloc(minors * sizeof *drv->cs, GFP_KERNEL);
> + drv->cs = kmalloc_array(minors, sizeof(*drv->cs), GFP_KERNEL);
For "minors" the same holds as for "channels", above.
And you snuck in a parentheses change. That should have probably been
merged with 5/5.
> if (!drv->cs)
> goto error;
Paul Bolle
^ permalink raw reply
* [PATCH v4 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-09-28 11:34 UTC (permalink / raw)
To: netdev, devicetree; +Cc: f.fainelli, Allan.Nielsen, andrew, Raju Lakkaraju
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-slowdowni)
added.
---
.../devicetree/bindings/net/mscc-phy-vsc8531.txt | 58 ++++++++++
drivers/net/phy/mscc.c | 125 +++++++++++++++++++++
include/dt-bindings/net/mscc-phy-vsc8531.h | 21 ++++
3 files changed, 204 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
create 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
new file mode 100644
index 0000000..951043e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
@@ -0,0 +1,58 @@
+* Microsemi - vsc8531 Giga bit ethernet phy
+
+Required properties:
+- compatible : Should contain phy id as "ethernet-phy-idAAAA.BBBB"
+ The PHY device uses the binding described in
+ Documentation/devicetree/bindings/net/phy.txt
+
+Optional properties:
+- vsc8531,vddmac : The vddmac in mV.
+- vsc8531,edge-slowdown : % the edge should be slowed down relative to
+ the fastest possible edge time. Native sign
+ need not enter.
+ Edge rate sets the drive strength of the MAC
+ interface output signals. Changing the drive
+ strength will affect the edge rate of the output
+ signal. The goal of this setting is to help
+ reduce electrical emission (EMI) by being able
+ to reprogram drive strength and in effect slow
+ down the edge rate if desired. Table 5 shows the
+ impact to the edge rate per VDDMAC supply for each
+ drive strength setting.
+ Ref: Table:1 - Edge rate change below.
+
+Note: see dt-bindings/net/mscc-phy-vsc8531.h for applicable values
+
+Table: 1 - Edge rate change
+----------------------------------------------------------------|
+| Edge Rate Change (VDDMAC) |
+| |
+| 3300 mV 2500 mV 1800 mV 1500 mV |
+|---------------------------------------------------------------|
+| Default Deafult Default Default |
+| (Fastest) (recommended) (recommended) |
+|---------------------------------------------------------------|
+| -2% -3% -5% -6% |
+|---------------------------------------------------------------|
+| -4% -6% -9% -14% |
+|---------------------------------------------------------------|
+| -7% -10% -16% -21% |
+|(recommended) (recommended) |
+|---------------------------------------------------------------|
+| -10% -14% -23% -29% |
+|---------------------------------------------------------------|
+| -17% -23% -35% -42% |
+|---------------------------------------------------------------|
+| -29% -37% -52% -58% |
+|---------------------------------------------------------------|
+| -53% -63% -76% -77% |
+| (slowest) |
+|---------------------------------------------------------------|
+
+Example:
+
+ vsc8531_0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id0007.0570";
+ vsc8531,vddmac = /bits/ 16 <MSCC_VDDMAC_3300>;
+ vsc8531,edge-slowdown = /bits/ 8 <17>;
+ };
diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index d350deb..a17573e 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -11,6 +11,8 @@
#include <linux/mdio.h>
#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,
@@ -37,6 +39,10 @@ enum rgmii_rx_clock_delay {
#define MII_VSC85XX_INT_MASK_MASK 0xa000
#define MII_VSC85XX_INT_STATUS 26
+#define MSCC_PHY_WOL_MAC_CONTROL 27
+#define EDGE_RATE_CNTL_POS 5
+#define EDGE_RATE_CNTL_MASK 0x00E0
+
#define MSCC_EXT_PAGE_ACCESS 31
#define MSCC_PHY_PAGE_STANDARD 0x0000 /* Standard registers */
#define MSCC_PHY_PAGE_EXTENDED_2 0x0002 /* Extended reg - page 2 */
@@ -50,6 +56,23 @@ enum rgmii_rx_clock_delay {
#define PHY_ID_VSC8531 0x00070570
#define PHY_ID_VSC8541 0x00070770
+struct edge_rate_table {
+ u16 vddmac;
+ int slowdown[MSCC_SLOWDOWN_MAX];
+};
+
+struct edge_rate_table edge_table[MSCC_VDDMAC_MAX] = {
+ {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} },
+ {1500, { 0, -6, -14, -21, -29, -42, -58, -77} },
+};
+
+struct vsc8531_private {
+ u8 edge_slowdown;
+ u16 vddmac;
+};
+
static int vsc85xx_phy_page_set(struct phy_device *phydev, u8 page)
{
int rc;
@@ -58,6 +81,51 @@ static int vsc85xx_phy_page_set(struct phy_device *phydev, u8 page)
return rc;
}
+static u8 edge_rate_magic_get(u16 vddmac,
+ int slowdown)
+{
+ int rc = (MSCC_SLOWDOWN_MAX - 1);
+ u8 vdd;
+ u8 sd;
+
+ for (vdd = 0; vdd < MSCC_VDDMAC_MAX; vdd++) {
+ if (edge_table[vdd].vddmac == vddmac) {
+ for (sd = 0; sd < MSCC_SLOWDOWN_MAX; sd++) {
+ if (edge_table[vdd].slowdown[sd] <= slowdown) {
+ rc = (MSCC_SLOWDOWN_MAX - sd - 1);
+ break;
+ }
+ }
+ }
+ }
+
+ return rc;
+}
+
+static int vsc85xx_edge_rate_cntl_set(struct phy_device *phydev,
+ u8 edge_rate)
+{
+ int rc;
+ u16 reg_val;
+
+ mutex_lock(&phydev->lock);
+ rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_EXTENDED_2);
+ if (rc != 0)
+ goto out_unlock;
+ reg_val = phy_read(phydev, MSCC_PHY_WOL_MAC_CONTROL);
+ reg_val &= ~(EDGE_RATE_CNTL_MASK);
+ reg_val |= (edge_rate << EDGE_RATE_CNTL_POS);
+ rc = phy_write(phydev, MSCC_PHY_WOL_MAC_CONTROL, reg_val);
+ if (rc != 0)
+ goto out_unlock;
+ rc = vsc85xx_phy_page_set(phydev, MSCC_PHY_PAGE_STANDARD);
+
+out_unlock:
+ mutex_unlock(&phydev->lock);
+
+ return rc;
+}
+
static int vsc85xx_mac_if_set(struct phy_device *phydev,
phy_interface_t interface)
{
@@ -116,9 +184,45 @@ out_unlock:
return rc;
}
+#ifdef CONFIG_OF_MDIO
+static int vsc8531_of_init(struct phy_device *phydev)
+{
+ int rc;
+ struct vsc8531_private *vsc8531 = phydev->priv;
+ struct device *dev = &phydev->mdio.dev;
+ struct device_node *of_node = dev->of_node;
+
+ if (!of_node)
+ return -ENODEV;
+
+ rc = of_property_read_u16(of_node, "vsc8531,vddmac",
+ &vsc8531->vddmac);
+ if (rc == -EINVAL)
+ vsc8531->vddmac = MSCC_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;
+}
+#else
+static int vsc8531_of_init(struct phy_device *phydev)
+{
+ return 0;
+}
+#endif /* CONFIG_OF_MDIO */
+
static int vsc85xx_config_init(struct phy_device *phydev)
{
int rc;
+ struct vsc8531_private *vsc8531 = phydev->priv;
+ u8 edge_rate;
+
+ rc = vsc8531_of_init(phydev);
+ if (rc)
+ return rc;
rc = vsc85xx_default_config(phydev);
if (rc)
@@ -128,6 +232,12 @@ 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);
+ rc = vsc85xx_edge_rate_cntl_set(phydev, edge_rate);
+ if (rc)
+ return rc;
+
rc = genphy_config_init(phydev);
return rc;
@@ -160,6 +270,19 @@ static int vsc85xx_config_intr(struct phy_device *phydev)
return rc;
}
+static int vsc85xx_probe(struct phy_device *phydev)
+{
+ struct vsc8531_private *vsc8531;
+
+ vsc8531 = devm_kzalloc(&phydev->mdio.dev, sizeof(*vsc8531), GFP_KERNEL);
+ if (!vsc8531)
+ return -ENOMEM;
+
+ phydev->priv = vsc8531;
+
+ return 0;
+}
+
/* Microsemi VSC85xx PHYs */
static struct phy_driver vsc85xx_driver[] = {
{
@@ -177,6 +300,7 @@ static struct phy_driver vsc85xx_driver[] = {
.config_intr = &vsc85xx_config_intr,
.suspend = &genphy_suspend,
.resume = &genphy_resume,
+ .probe = &vsc85xx_probe,
},
{
.phy_id = PHY_ID_VSC8541,
@@ -193,6 +317,7 @@ static struct phy_driver vsc85xx_driver[] = {
.config_intr = &vsc85xx_config_intr,
.suspend = &genphy_suspend,
.resume = &genphy_resume,
+ .probe = &vsc85xx_probe,
}
};
diff --git a/include/dt-bindings/net/mscc-phy-vsc8531.h b/include/dt-bindings/net/mscc-phy-vsc8531.h
new file mode 100644
index 0000000..2383dd2
--- /dev/null
+++ b/include/dt-bindings/net/mscc-phy-vsc8531.h
@@ -0,0 +1,21 @@
+/*
+ * 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
^ permalink raw reply related
* Re: [v3,net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-09-28 11:12 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20160927211436.GA11602@lunn.ch>
Hi Andrew,
Thank you for review and valuable comments.
I will implement below suggestion and resend for review.
Thanks,
Raju.
On Tue, Sep 27, 2016 at 11:14:36PM +0200, Andrew Lunn wrote:
> EXTERNAL EMAIL
>
>
> I just realised the possibly correct binding was starring me in the
> face.
>
> --------------------------------------------------------------|
> | 3.3V 2.5V 1.8V 1.5V |
> |-------------------------------------------------------------|
> |-2% -3% -5% -6% |
> |-------------------------------------------------------------|
> |-4% -6% -9% -14% |
> |-------------------------------------------------------------|
> |-7% -10% -16% -21% |
> |-------------------------------------------------------------|
> |-10% -14% -23% -29% |
> |-------------------------------------------------------------|
> |-17% -23% -35% -42% |
> |-------------------------------------------------------------|
> |-29% -37% -52% -58% |
> |-------------------------------------------------------------|
> |-53% -63% -76% -77% |
> |-------------------------------------------------------------|
>
> So the binding is:
>
> vsc8531,vddmac : The vddmac in mV.
> vsc8531,edge-slowdown : % the edge should be slowed down relative to
> the fastest possible edge time.
>
> Given those two values, the driver can work out the magic value to put
> into the register that nobody knows the true meaning of.
>
Accepted.
> Andrew
---
Raju.
^ permalink raw reply
* Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets
From: Cyrill Gorcunov @ 2016-09-28 11:27 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Eric Dumazet, David Ahern, netdev, linux-kernel, David Miller,
kuznet, jmorris, yoshfuji, kaber, avagin, stephen
In-Reply-To: <484dedaf-4e81-9a5a-ffb8-2c65b373c3a0@mojatatu.com>
On Wed, Sep 28, 2016 at 07:06:26AM -0400, Jamal Hadi Salim wrote:
> >
> > This structure is uapi, so anyone has complete rights to reference
> > @pad in the userspace programs. Sure it would be more clear to remove
> > the @pad completely, but if we choose so I think it's better to do
> > on top instead and then if someone complain we can easily revert
> > the single trivial commit instead of this big patch.
>
> I am conflicted.
> A field labelled "pad" does not appear to be valid as "UAPI". It is
> a cosmetic indicator. If you did sizeof() with or without it being
> present the value doesnt change.
I think you miss the point what I'm trying to say: currently end-user
may have reference to this member (for any reason) and his program
will compile and run. If we change the name the compilation procedure
fails and this will break API. Yes, referrning @pad is bad idea for
userspace code, and yes (!) better to simply rename it but lets do
that later, on top, so that if we break something in userspace
we could easily revert the oneline change.
> BTW: There is at least one major structure in inet diag has a hole
> today and doesnt have a padding indicator.
>
> > If protocol goes over u8 then complete inet_diag_req_v2 structure will
> > have to be reworked becaue @sdiag_protocol is u8 as well. IOW, once
> > someone liftup IPPROTO_MAX > 255, he will notice the problem immediately
> > because diag for such module simply stop working properly.
> >
>
> ok.
>
> cheers,
> jamal
>
Cyrill
^ permalink raw reply
* Re: [PATCHv2 net 0/5] sctp: some fixes of prsctp polices
From: Marcelo Ricardo Leitner @ 2016-09-28 11:22 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Vlad Yasevich, daniel
In-Reply-To: <cover.1475059350.git.lucien.xin@gmail.com>
On Wed, Sep 28, 2016 at 06:46:27PM +0800, Xin Long wrote:
> This patchset is to improve some codes about prsctp polices, and also
> to fix some issues.
>
> v1->v2:
> - wrap the check of chunk->sent_count in a macro:
> sctp_chunk_retransmitted in patch 2/5.
>
> Xin Long (5):
> sctp: move sent_count to the memory hole in sctp_chunk
> sctp: reuse sent_count to avoid retransmitted chunks for RTT
> measurements
> sctp: remove prsctp_param from sctp_chunk
> sctp: change to check peer prsctp_capable when using prsctp polices
> sctp: remove the old ttl expires policy
>
> include/net/sctp/structs.h | 16 ++++------------
> net/sctp/chunk.c | 31 ++++++++++---------------------
> net/sctp/output.c | 6 ++----
> net/sctp/outqueue.c | 16 +++++++---------
> net/sctp/sm_make_chunk.c | 15 ---------------
> 5 files changed, 23 insertions(+), 61 deletions(-)
>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Thanks
^ permalink raw reply
* Re: [PATCH v3 net-next] net: phy: Add Edge-rate driver for Microsemi PHYs.
From: Raju Lakkaraju @ 2016-09-28 11:09 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, devicetree, f.fainelli, Allan.Nielsen
In-Reply-To: <20160927141633.GJ28432@lunn.ch>
Hi Andrew,
Thank you for review and valuable comments.
Thanks,
Raju.
On Tue, Sep 27, 2016 at 04:16:33PM +0200, Andrew Lunn wrote:
> EXTERNAL EMAIL
>
>
> > index 0000000..7ba3855
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/mscc-phy-vsc8531.txt
> > @@ -0,0 +1,61 @@
> > +* Microsemi - vsc8531 Giga bit ethernet phy
> > +
> > +Required properties:
> > +- compatible : Should contain phy id as "ethernet-phy-idAAAA.BBBB"
> > + If the phy's identifier is known then the list may contain an entry
> > + of the form: "ethernet-phy-idAAAA.BBBB" where
> > + AAAA - The value of the 16 bit Phy Identifier 1 register as
> > + 4 hex digits. This is the chip vendor OUI bits 3:18
> > + BBBB - The value of the 16 bit Phy Identifier 2 register as
> > + 4 hex digits. This is the chip vendor OUI bits 19:24,
> > + followed by 10 bits of a vendor specific ID.
> > +- reg : The ID number for the phy, usually a small integer
>
> Please don't copy phy.txt. Just refer to it. Use text like:
>
> The PHY device uses the binding described in
> Documentation/devicetree/bindings/net/phy.txt
>
> It may additionally have the following properties
>
Accepted.
> > +Optional properties:
> > +- vsc8531,edge-rate : Edge rate sets the drive strength of the MAC
> > + interface output signals. Changing the drive
> > + strength will affect the edge rate of the output
> > + signal.
>
> Are we specifying a rate or a strength? It is called edge-rate, so it
> expect it to be a rate, mV/pS or something similar.
>
Accepted.
> Andrew
^ permalink raw reply
* Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets
From: Jamal Hadi Salim @ 2016-09-28 11:06 UTC (permalink / raw)
To: Cyrill Gorcunov
Cc: Eric Dumazet, David Ahern, netdev, linux-kernel, David Miller,
kuznet, jmorris, yoshfuji, kaber, avagin, stephen
In-Reply-To: <20160928105147.GV1876@uranus.lan>
On 16-09-28 06:51 AM, Cyrill Gorcunov wrote:
> On Wed, Sep 28, 2016 at 06:43:01AM -0400, Jamal Hadi Salim wrote:
[..]
>> I dont know how compilation will fail but you may be right with note:
>> that is not how pads have been used in the past. They are supposed to
>> cosmetic annotation which indicates "here's a hole; use it in the
>> future if you are looking to add something". And someone in the
>> future can claim them. I am not sure if MBZ philosophy applies.
>
> This structure is uapi, so anyone has complete rights to reference
> @pad in the userspace programs. Sure it would be more clear to remove
> the @pad completely, but if we choose so I think it's better to do
> on top instead and then if someone complain we can easily revert
> the single trivial commit instead of this big patch.
I am conflicted.
A field labelled "pad" does not appear to be valid as "UAPI". It is
a cosmetic indicator. If you did sizeof() with or without it being
present the value doesnt change.
BTW: There is at least one major structure in inet diag has a hole
today and doesnt have a padding indicator.
> If protocol goes over u8 then complete inet_diag_req_v2 structure will
> have to be reworked becaue @sdiag_protocol is u8 as well. IOW, once
> someone liftup IPPROTO_MAX > 255, he will notice the problem immediately
> because diag for such module simply stop working properly.
>
ok.
cheers,
jamal
^ 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