RE: [PATCH net-next 0/8] net: dsa: microchip: DSA driver support for LAN937x switch

Hi Florian, Wish you a happy and safe new year. Thanks for your time to review new patches. > It is great to see a new switch from Microchip being submitted for > review. One thing that has bothered me as a DSA maintainer before though > is that we have seen Microchip contribute new DSA drivers

RE: [PATCH net-next v2 4/4] net: usb: smsc: fix warning reported by kbuild test robot

> This patch fixes following warning reported by kbuild test robot: > > In function ‘memcpy’, > inlined from ‘smsc75xx_init_mac_address’ at > drivers/net/usb/smsc75xx.c:778:3, > inlined from ‘smsc75xx_bind’ at drivers/net/usb/smsc75xx.c:1501:2: > ./include/linux/string.h:355:9:

RE: [PATCH] MAINTAINERS: normalize Woojung Huh's email address

> MAINTAINERS contains a lower-case and upper-case variant of > Woojung Huh' s email address. > > Only keep the lower-case variant in MAINTAINERS. > > Signed-off-by: Lukas Bulwahn Acked-by: Woojung Huh

RE: [PATCH] MAINTAINERS: Add a maintainer for MSCC MIPS SoCs

> -Original Message- > From: Alexandre Belloni > Sent: Tuesday, December 18, 2018 9:27 AM > To: James Hogan ; Paul Burton > Cc: Ralf Baechle ; linux-kernel@vger.kernel.org; > linux-m...@linux-mips.org; > UNGLinuxDriver ; Alexandre Belloni > > Subject: [PATCH] MAINTAINERS: Add a

RE: [PATCH net-next] MAINTAINERS: Add a maintainer for Microsemi switches

> -Original Message- > From: Alexandre Belloni > Sent: Tuesday, December 18, 2018 9:26 AM > To: David S . Miller > Cc: UNGLinuxDriver ; net...@vger.kernel.org; > linux- > ker...@vger.kernel.org; Alexandre Belloni > Subject: [PATCH net-next] MAINTAINERS: Add a maintainer for Microsemi

RE: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Hi Florian, > Well, the way the code is structure is that if you call that function > with a test mode value that is not part of the standard set, it returns > -EOPNOTSUPP, so if your particular PHY driver wants to "overlay" > standard and non-standard modes, it can by using that hint. > > This

RE: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Hi Florian, > Well, the way the code is structure is that if you call that function > with a test mode value that is not part of the standard set, it returns > -EOPNOTSUPP, so if your particular PHY driver wants to "overlay" > standard and non-standard modes, it can by using that hint. > > This

RE: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Hi Florian, > Not sure I completely understand your suggestion, do you mean that I > should break down the body of that function above such that there are > per-speed lower level functions? Something like the pseudo-code below: > > genphy_set_test() { > switch (mode) { > case

RE: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Hi Florian, > Not sure I completely understand your suggestion, do you mean that I > should break down the body of that function above such that there are > per-speed lower level functions? Something like the pseudo-code below: > > genphy_set_test() { > switch (mode) { > case

RE: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Hi Florian, > diff --git a/drivers/net/phy/phy-tests.c b/drivers/net/phy/phy-tests.c ... > +/* genphy_set_test - Make a PHY enter one of the standard IEEE defined > + * test modes > + * @phydev: the PHY device instance > + * @test: the desired test mode > + * @data: test specific data (none) > +

RE: [RFC net-next 4/5] net: phy: Add support for IEEE standard test modes

Hi Florian, > diff --git a/drivers/net/phy/phy-tests.c b/drivers/net/phy/phy-tests.c ... > +/* genphy_set_test - Make a PHY enter one of the standard IEEE defined > + * test modes > + * @phydev: the PHY device instance > + * @test: the desired test mode > + * @data: test specific data (none) > +

RE: [PATCH 3/4] lan78xx: Read LED modes from Device Tree

> > @@ -2097,6 +2098,25 @@ static int lan78xx_phy_init(struct lan78xx_net *dev) > > (void)lan78xx_set_eee(dev->net, ); > > } > > > > + if (!of_property_read_u32_array(dev->udev->dev.of_node, > > + "microchip,led-modes", > > +

RE: [PATCH 3/4] lan78xx: Read LED modes from Device Tree

> > @@ -2097,6 +2098,25 @@ static int lan78xx_phy_init(struct lan78xx_net *dev) > > (void)lan78xx_set_eee(dev->net, ); > > } > > > > + if (!of_property_read_u32_array(dev->udev->dev.of_node, > > + "microchip,led-modes", > > +

RE: [PATCH] lan78xx: Connect phy early

Hi Alexander, Thanks for patch. We will look into it if there is any corner case Such as plug in/out while operations. Woojung > -Original Message- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Wednesday, March 14, 2018 10:55 AM > To: Woojung Huh - C21699

RE: [PATCH] lan78xx: Connect phy early

Hi Alexander, Thanks for patch. We will look into it if there is any corner case Such as plug in/out while operations. Woojung > -Original Message- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Wednesday, March 14, 2018 10:55 AM > To: Woojung Huh - C21699 > Cc: UNGLinuxDriver ;

RE: [PATCH] lan78xx: Use common error handling code in lan78xx_phy_init()

> From: SF Markus Elfring [mailto:elfr...@users.sourceforge.net] > Sent: Saturday, October 28, 2017 4:57 PM > To: net...@vger.kernel.org; linux-...@vger.kernel.org; UNGLinuxDriver; > Woojung Huh - C21699 > Cc: LKML; kernel-janit...@vger.kernel.org > Subject: [PATCH] lan78xx: Use common error

RE: [PATCH] lan78xx: Use common error handling code in lan78xx_phy_init()

> From: SF Markus Elfring [mailto:elfr...@users.sourceforge.net] > Sent: Saturday, October 28, 2017 4:57 PM > To: net...@vger.kernel.org; linux-...@vger.kernel.org; UNGLinuxDriver; > Woojung Huh - C21699 > Cc: LKML; kernel-janit...@vger.kernel.org > Subject: [PATCH] lan78xx: Use common error

RE: [PATCH net-next 2/2] net: dsa: lan9303: Learn addresses on CPU port when bridged

Hi Egil, > >> @@ -62,7 +80,10 @@ static struct sk_buff *lan9303_xmit(struct sk_buff > *skb, > >> struct net_device *dev) > >> > >>lan9303_tag = (u16 *)(skb->data + 2 * ETH_ALEN); > >>lan9303_tag[0] = htons(ETH_P_8021Q); > >> - lan9303_tag[1] = htons(dp->index | BIT(4)); > >> +

RE: [PATCH net-next 2/2] net: dsa: lan9303: Learn addresses on CPU port when bridged

Hi Egil, > >> @@ -62,7 +80,10 @@ static struct sk_buff *lan9303_xmit(struct sk_buff > *skb, > >> struct net_device *dev) > >> > >>lan9303_tag = (u16 *)(skb->data + 2 * ETH_ALEN); > >>lan9303_tag[0] = htons(ETH_P_8021Q); > >> - lan9303_tag[1] = htons(dp->index | BIT(4)); > >> +

RE: [PATCH net-next 2/2] net: dsa: lan9303: Learn addresses on CPU port when bridged

Hi Egil, > +static inline int lan9303_tx_use_arl(struct dsa_port *dp, u8 *dest_addr) > +{ > + struct lan9303 *chip = dp->ds->priv; > + > + return chip->is_bridged && !ether_addr_equal(dest_addr, > eth_stp_addr); > +} > > static struct sk_buff *lan9303_xmit(struct sk_buff *skb, struct

RE: [PATCH net-next 2/2] net: dsa: lan9303: Learn addresses on CPU port when bridged

Hi Egil, > +static inline int lan9303_tx_use_arl(struct dsa_port *dp, u8 *dest_addr) > +{ > + struct lan9303 *chip = dp->ds->priv; > + > + return chip->is_bridged && !ether_addr_equal(dest_addr, > eth_stp_addr); > +} > > static struct sk_buff *lan9303_xmit(struct sk_buff *skb, struct

RE: [PATCH net] net: dsa: mv88e6060: fix switch MAC address

> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Vivien Didelot > Sent: Friday, October 13, 2017 1:39 PM > To: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; ker...@savoirfairelinux.com; David S. > Miller; Florian

RE: [PATCH net] net: dsa: mv88e6060: fix switch MAC address

> -Original Message- > From: netdev-ow...@vger.kernel.org [mailto:netdev- > ow...@vger.kernel.org] On Behalf Of Vivien Didelot > Sent: Friday, October 13, 2017 1:39 PM > To: net...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; ker...@savoirfairelinux.com; David S. > Miller; Florian

RE: [PATCH net-next v2 2/4] net: dsa: mv88e6060: setup random mac address

Hi Vivien, > >> > +REG_WRITE(REG_GLOBAL, GLOBAL_MAC_01, (addr[0] << 9) | > >> addr[1]); > >> > >> Is that supposed to be 9 ? > > > > Looks like it. > > Check > http://www.marvell.com/switching/assets/marvell_linkstreet_88E6060_data > sheet.pdf > > Hum, David is correct, there is a bug in

RE: [PATCH net-next v2 2/4] net: dsa: mv88e6060: setup random mac address

Hi Vivien, > >> > +REG_WRITE(REG_GLOBAL, GLOBAL_MAC_01, (addr[0] << 9) | > >> addr[1]); > >> > >> Is that supposed to be 9 ? > > > > Looks like it. > > Check > http://www.marvell.com/switching/assets/marvell_linkstreet_88E6060_data > sheet.pdf > > Hum, David is correct, there is a bug in

RE: [PATCH net-next v2 2/4] net: dsa: mv88e6060: setup random mac address

> From: Vivien Didelot > > Sent: 13 October 2017 02:41 > > As for mv88e6xxx, setup the switch from within the mv88e6060 driver with > > a random MAC address, and remove the .set_addr implementation. > > > > Signed-off-by: Vivien Didelot > > --- > >

RE: [PATCH net-next v2 2/4] net: dsa: mv88e6060: setup random mac address

> From: Vivien Didelot > > Sent: 13 October 2017 02:41 > > As for mv88e6xxx, setup the switch from within the mv88e6060 driver with > > a random MAC address, and remove the .set_addr implementation. > > > > Signed-off-by: Vivien Didelot > > --- > > drivers/net/dsa/mv88e6060.c | 30

RE: [PATCH v2 net-next 1/2] net: dsa: lan9303: Move tag setup to new lan9303_setup_tagging

> @@ -644,6 +648,10 @@ static int lan9303_setup(struct dsa_switch *ds) > return -EINVAL; > } > > +ret = lan9303_setup_tagging(chip); > +if (ret) > +dev_err(chip->dev, "failed to setup port tagging %d\n",

RE: [PATCH v2 net-next 1/2] net: dsa: lan9303: Move tag setup to new lan9303_setup_tagging

> @@ -644,6 +648,10 @@ static int lan9303_setup(struct dsa_switch *ds) > return -EINVAL; > } > > +ret = lan9303_setup_tagging(chip); > +if (ret) > +dev_err(chip->dev, "failed to setup port tagging %d\n",

RE: [PATCH v2 net-next 1/2] net: dsa: lan9303: Move tag setup to new lan9303_setup_tagging

> > Specific reason to use val then using > LAN9303_BM_EGRSS_PORT_TYPE_SPECIAL_TAG_PORT0 > > like previous line? > > > Specific reason was to please a reviewer that did not like my > indenting in first version. I did not agree with him, but since > nobody else spoke up, I changed the code. Got it.

RE: [PATCH v2 net-next 1/2] net: dsa: lan9303: Move tag setup to new lan9303_setup_tagging

> > Specific reason to use val then using > LAN9303_BM_EGRSS_PORT_TYPE_SPECIAL_TAG_PORT0 > > like previous line? > > > Specific reason was to please a reviewer that did not like my > indenting in first version. I did not agree with him, but since > nobody else spoke up, I changed the code. Got it.

RE: [PATCH v2 net-next 1/2] net: dsa: lan9303: Move tag setup to new lan9303_setup_tagging

> +/* forward special tagged packets from port 0 to port 1 *or* port 2 */ > +static int lan9303_setup_tagging(struct lan9303 *chip) > +{ > + int ret; > + u32 val; > + /* enable defining the destination port via special VLAN tagging > + * for port 0 > + */ > + ret =

RE: [PATCH v2 net-next 1/2] net: dsa: lan9303: Move tag setup to new lan9303_setup_tagging

> +/* forward special tagged packets from port 0 to port 1 *or* port 2 */ > +static int lan9303_setup_tagging(struct lan9303 *chip) > +{ > + int ret; > + u32 val; > + /* enable defining the destination port via special VLAN tagging > + * for port 0 > + */ > + ret =

RE: [PATCH v1 RFC 1/7] Replace license with GPL

> Subject: [PATCH v1 RFC 1/7] Replace license with GPL > > From: Tristram Ha > > Replace license with GPL. > > Signed-off-by: Tristram Ha Reviewed-by: Woojung Huh

RE: [PATCH v1 RFC 1/7] Replace license with GPL

> Subject: [PATCH v1 RFC 1/7] Replace license with GPL > > From: Tristram Ha > > Replace license with GPL. > > Signed-off-by: Tristram Ha Reviewed-by: Woojung Huh

RE: [PATCH RFC 3/5] Add KSZ8795 switch driver

> > > > @@ -0,0 +1,2066 @@ > > > > +/* > > > > + * Microchip KSZ8795 switch driver > > > > + * > > > > + * Copyright (C) 2017 Microchip Technology Inc. > > > > + * Tristram Ha > > > > + * > > > > + * Permission to use, copy, modify, and/or distribute this software

RE: [PATCH RFC 3/5] Add KSZ8795 switch driver

> > > > @@ -0,0 +1,2066 @@ > > > > +/* > > > > + * Microchip KSZ8795 switch driver > > > > + * > > > > + * Copyright (C) 2017 Microchip Technology Inc. > > > > + * Tristram Ha > > > > + * > > > > + * Permission to use, copy, modify, and/or distribute this software for > any > > > > + *

RE: [PATCH] DSA support for Micrel KSZ8895

Pavel, Thanks for update and sorry about email format (due to web-access version) I'll do review when getting back to office later this week. - Woojung From: Pavel Machek [pa...@denx.de] Sent: Sunday, August 27, 2017 8:36 AM To: Woojung Huh - C21699;

RE: [PATCH] DSA support for Micrel KSZ8895

Pavel, Thanks for update and sorry about email format (due to web-access version) I'll do review when getting back to office later this week. - Woojung From: Pavel Machek [pa...@denx.de] Sent: Sunday, August 27, 2017 8:36 AM To: Woojung Huh - C21699;

RE: DSA support for Micrel KSZ8895

Pavel, > > I'll forward your email to our support. > > AFAIK, KSZ8895 has different register mapping from KSZ9477, > > it will be more than ID changes in current driver. > > More than ID changes, indeed. As layout is completely different, it > looks like different source file will be needed for

RE: DSA support for Micrel KSZ8895

Pavel, > > I'll forward your email to our support. > > AFAIK, KSZ8895 has different register mapping from KSZ9477, > > it will be more than ID changes in current driver. > > More than ID changes, indeed. As layout is completely different, it > looks like different source file will be needed for

RE: DSA support for Micrel KSZ8895

> > Hi! > > > > I've got hardware with KSZ8895, and I'd like to use switch ports as > > separate ethernet cards. I believe that means DSA support. > > > > And there are even patches available from microchip... unfortunately > > they are in strange form and for v3.18. > > > > >

RE: DSA support for Micrel KSZ8895

> > Hi! > > > > I've got hardware with KSZ8895, and I'd like to use switch ports as > > separate ethernet cards. I believe that means DSA support. > > > > And there are even patches available from microchip... unfortunately > > they are in strange form and for v3.18. > > > > >

RE: [PATCH net-next 06/11] net: dsa: debugfs: add port registers

Vivien, > Subject: [PATCH net-next 06/11] net: dsa: debugfs: add port registers > > Add a debug filesystem "regs" entry to query a port's hardware registers > through the .get_regs_len and .get_regs_len switch operations. > > This is very convenient because it allows one to dump the registers

RE: [PATCH net-next 06/11] net: dsa: debugfs: add port registers

Vivien, > Subject: [PATCH net-next 06/11] net: dsa: debugfs: add port registers > > Add a debug filesystem "regs" entry to query a port's hardware registers > through the .get_regs_len and .get_regs_len switch operations. > > This is very convenient because it allows one to dump the registers

RE: [PATCH net] net: dsa: ksz: fix skb freeing

> The DSA layer frees the original skb when an xmit function returns NULL, > meaning an error occurred. But if the tagging code copied the original > skb, it is responsible of freeing the copy if an error occurs. > > The ksz tagging code currently has two issues: if skb_put_padto fails, > the skb

RE: [PATCH net] net: dsa: ksz: fix skb freeing

> The DSA layer frees the original skb when an xmit function returns NULL, > meaning an error occurred. But if the tagging code copied the original > skb, it is responsible of freeing the copy if an error occurs. > > The ksz tagging code currently has two issues: if skb_put_padto fails, > the skb

RE: [PATCH][net-next] net: dsa: make function ksz_rcv static

> function ksz_rcv can be made static as it does not need to be > in global scope. Reformat arguments to make it checkpatch warning > free too. > > Cleans up sparse warning: "symbol 'ksz_rcv' was not declared. Should > it be static?" > > Signed-off-by: Colin Ian King

RE: [PATCH][net-next] net: dsa: make function ksz_rcv static

> function ksz_rcv can be made static as it does not need to be > in global scope. Reformat arguments to make it checkpatch warning > free too. > > Cleans up sparse warning: "symbol 'ksz_rcv' was not declared. Should > it be static?" > > Signed-off-by: Colin Ian King Reviewed-by: Woojung Huh

RE: [PATCH 1/1] net: usb: set error code when usb_alloc_urb fails

> Signed-off-by: Pan Bian > --- > drivers/net/usb/lan78xx.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c > index db558b8..f33460c 100644 > --- a/drivers/net/usb/lan78xx.c > +++ b/drivers/net/usb/lan78xx.c >

RE: [PATCH 1/1] net: usb: set error code when usb_alloc_urb fails

> Signed-off-by: Pan Bian > --- > drivers/net/usb/lan78xx.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c > index db558b8..f33460c 100644 > --- a/drivers/net/usb/lan78xx.c > +++ b/drivers/net/usb/lan78xx.c > @@ -3395,6 +3395,7 @@

RE: [PATCH 15/15] net: usb: lan78xx: Utilize phy_ethtool_nway_reset

> Signed-off-by: Florian Fainelli > --- > drivers/net/usb/lan78xx.c | 7 +-- > 1 file changed, 1 insertion(+), 6 deletions(-) > > diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c > index bcd9010c1f27..cf2857fa938f 100644 > ---

RE: [PATCH 15/15] net: usb: lan78xx: Utilize phy_ethtool_nway_reset

> Signed-off-by: Florian Fainelli > --- > drivers/net/usb/lan78xx.c | 7 +-- > 1 file changed, 1 insertion(+), 6 deletions(-) > > diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c > index bcd9010c1f27..cf2857fa938f 100644 > --- a/drivers/net/usb/lan78xx.c > +++

RE: [PATCH 0/2] lan78xx: Remove trailing underscores from macros

> Joe Perches (2): > lan78xx: Remove locally defined trailing underscores from defines and uses > microchipphy.h and uses: Remove trailing underscores from defines and > uses > > drivers/net/phy/microchip.c |4 +- > drivers/net/usb/lan78xx.c| 368 +++ >

RE: [PATCH 0/2] lan78xx: Remove trailing underscores from macros

> Joe Perches (2): > lan78xx: Remove locally defined trailing underscores from defines and uses > microchipphy.h and uses: Remove trailing underscores from defines and > uses > > drivers/net/phy/microchip.c |4 +- > drivers/net/usb/lan78xx.c| 368 +++ >

RE: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG_PM

> > > But this leaves open the issue that querying the device too often will > > > prevent it from going into autosuspend. It seems to me that the best > > > way to deal with this is to make sure that the autosuspend timeout is > > > shorter than the interal between queries, not to make the

RE: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG_PM

> > > But this leaves open the issue that querying the device too often will > > > prevent it from going into autosuspend. It seems to me that the best > > > way to deal with this is to make sure that the autosuspend timeout is > > > shorter than the interal between queries, not to make the

RE: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG_PM

> But this leaves open the issue that querying the device too often will > prevent it from going into autosuspend. It seems to me that the best > way to deal with this is to make sure that the autosuspend timeout is > shorter than the interal between queries, not to make the querying >

RE: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG_PM

> But this leaves open the issue that querying the device too often will > prevent it from going into autosuspend. It seems to me that the best > way to deal with this is to make sure that the autosuspend timeout is > shorter than the interal between queries, not to make the querying >

RE: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG_PM

> -Original Message- > From: Guenter Roeck [mailto:li...@roeck-us.net] > Sent: Sunday, March 20, 2016 6:59 PM > To: Geert Uytterhoeven; Woojung Huh - C21699; UNGLinuxDriver; David S. > Miller > Cc: Rafael J. Wysocki; net...@vger.kernel.org; linux-...@vger.kernel.org; >

RE: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG_PM

> -Original Message- > From: Guenter Roeck [mailto:li...@roeck-us.net] > Sent: Sunday, March 20, 2016 6:59 PM > To: Geert Uytterhoeven; Woojung Huh - C21699; UNGLinuxDriver; David S. > Miller > Cc: Rafael J. Wysocki; net...@vger.kernel.org; linux-...@vger.kernel.org; >

RE: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG_PM

> -Original Message- > From: Oliver Neukum [mailto:oneu...@suse.com] > Sent: Monday, March 21, 2016 4:36 AM > To: Geert Uytterhoeven > Cc: Woojung Huh - C21699; UNGLinuxDriver; David S. Miller; Guenter Roeck; > Rafael J. Wysocki; net...@vger.kernel.org; linux-...@vger.kernel.org; >

RE: [PATCH] lan78xx: Protect runtime_auto check by #ifdef CONFIG_PM

> -Original Message- > From: Oliver Neukum [mailto:oneu...@suse.com] > Sent: Monday, March 21, 2016 4:36 AM > To: Geert Uytterhoeven > Cc: Woojung Huh - C21699; UNGLinuxDriver; David S. Miller; Guenter Roeck; > Rafael J. Wysocki; net...@vger.kernel.org; linux-...@vger.kernel.org; >