* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S [not found] <20190730002532.85509-1-taoren@fb.com> @ 2019-07-30 3:35 ` Andrew Lunn 2019-07-30 5:05 ` Tao Ren 0 siblings, 1 reply; 9+ messages in thread From: Andrew Lunn @ 2019-07-30 3:35 UTC (permalink / raw) To: Tao Ren Cc: Florian Fainelli, Heiner Kallweit, David S . Miller, Arun Parameswaran, Justin Chen, Vladimir Oltean, netdev, linux-kernel, Andrew Jeffery, openbmc On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote: > BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc > ("net: phy: switch drivers to use dynamic feature detection"). As dynamic > feature detection doesn't work when BCM54616S is working in RGMII-Fiber > mode (different sets of MII Control/Status registers being used), let's > set "PHY_GBIT_FEATURES" for BCM54616S explicitly. Hi Tao What exactly does it get wrong? Thanks Andrew ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S 2019-07-30 3:35 ` [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S Andrew Lunn @ 2019-07-30 5:05 ` Tao Ren 2019-07-30 6:00 ` Heiner Kallweit 0 siblings, 1 reply; 9+ messages in thread From: Tao Ren @ 2019-07-30 5:05 UTC (permalink / raw) To: Andrew Lunn Cc: Florian Fainelli, Heiner Kallweit, David S . Miller, Arun Parameswaran, Justin Chen, Vladimir Oltean, netdev, linux-kernel, Andrew Jeffery, openbmc On 7/29/19 8:35 PM, Andrew Lunn wrote: > On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote: >> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc >> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic >> feature detection doesn't work when BCM54616S is working in RGMII-Fiber >> mode (different sets of MII Control/Status registers being used), let's >> set "PHY_GBIT_FEATURES" for BCM54616S explicitly. > > Hi Tao > > What exactly does it get wrong? > > Thanks > Andrew Hi Andrew, BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of the features (1000BaseT/100BaseT/10BaseT) can be detected by genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half ability in this mode. Thanks, Tao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S 2019-07-30 5:05 ` Tao Ren @ 2019-07-30 6:00 ` Heiner Kallweit 2019-07-31 0:12 ` Tao Ren 0 siblings, 1 reply; 9+ messages in thread From: Heiner Kallweit @ 2019-07-30 6:00 UTC (permalink / raw) To: Tao Ren, Andrew Lunn Cc: Florian Fainelli, David S . Miller, Arun Parameswaran, Justin Chen, Vladimir Oltean, netdev, linux-kernel, Andrew Jeffery, openbmc On 30.07.2019 07:05, Tao Ren wrote: > On 7/29/19 8:35 PM, Andrew Lunn wrote: >> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote: >>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc >>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic >>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber >>> mode (different sets of MII Control/Status registers being used), let's >>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly. >> >> Hi Tao >> >> What exactly does it get wrong? >> >> Thanks >> Andrew > > Hi Andrew, > > BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of the features (1000BaseT/100BaseT/10BaseT) can be detected by genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half ability in this mode. > Are you going to use the PHY in copper or fibre mode? In case you use fibre mode, why do you need the copper modes set as supported? Or does the PHY just start in fibre mode and you want to switch it to copper mode? > > Thanks, > > Tao > Heiner ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S 2019-07-30 6:00 ` Heiner Kallweit @ 2019-07-31 0:12 ` Tao Ren 2019-07-31 5:53 ` Heiner Kallweit 0 siblings, 1 reply; 9+ messages in thread From: Tao Ren @ 2019-07-31 0:12 UTC (permalink / raw) To: Heiner Kallweit, Andrew Lunn Cc: Florian Fainelli, David S . Miller, Arun Parameswaran, Justin Chen, Vladimir Oltean, netdev, linux-kernel, Andrew Jeffery, openbmc On 7/29/19 11:00 PM, Heiner Kallweit wrote: > On 30.07.2019 07:05, Tao Ren wrote: >> On 7/29/19 8:35 PM, Andrew Lunn wrote: >>> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote: >>>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc >>>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic >>>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber >>>> mode (different sets of MII Control/Status registers being used), let's >>>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly. >>> >>> Hi Tao >>> >>> What exactly does it get wrong? >>> >>> Thanks >>> Andrew >> >> Hi Andrew, >> >> BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of the features (1000BaseT/100BaseT/10BaseT) can be detected by genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half ability in this mode. >> > Are you going to use the PHY in copper or fibre mode? > In case you use fibre mode, why do you need the copper modes set as supported? > Or does the PHY just start in fibre mode and you want to switch it to copper mode? Hi Heiner, The phy starts in fiber mode and that's the mode I want. My observation is: phydev->link is always 0 (Link status bit is never set in MII_BMSR) by using dynamic ability detection on my machine. I checked phydev->supported and it's set to "AutoNeg | TP | MII | Pause | Asym_Pause" by dynamic ability detection. Is it normal/expected? Or maybe the fix should go to different places? Thank you for your help. Thanks, Tao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S 2019-07-31 0:12 ` Tao Ren @ 2019-07-31 5:53 ` Heiner Kallweit 2019-07-31 6:00 ` Tao Ren 0 siblings, 1 reply; 9+ messages in thread From: Heiner Kallweit @ 2019-07-31 5:53 UTC (permalink / raw) To: Tao Ren, Andrew Lunn Cc: Florian Fainelli, David S . Miller, Arun Parameswaran, Justin Chen, Vladimir Oltean, netdev, linux-kernel, Andrew Jeffery, openbmc On 31.07.2019 02:12, Tao Ren wrote: > On 7/29/19 11:00 PM, Heiner Kallweit wrote: >> On 30.07.2019 07:05, Tao Ren wrote: >>> On 7/29/19 8:35 PM, Andrew Lunn wrote: >>>> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote: >>>>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc >>>>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic >>>>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber >>>>> mode (different sets of MII Control/Status registers being used), let's >>>>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly. >>>> >>>> Hi Tao >>>> >>>> What exactly does it get wrong? >>>> >>>> Thanks >>>> Andrew >>> >>> Hi Andrew, >>> >>> BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of the features (1000BaseT/100BaseT/10BaseT) can be detected by genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half ability in this mode. >>> >> Are you going to use the PHY in copper or fibre mode? >> In case you use fibre mode, why do you need the copper modes set as supported? >> Or does the PHY just start in fibre mode and you want to switch it to copper mode? > > Hi Heiner, > > The phy starts in fiber mode and that's the mode I want. > My observation is: phydev->link is always 0 (Link status bit is never set in MII_BMSR) by using dynamic ability detection on my machine. I checked phydev->supported and it's set to "AutoNeg | TP | MII | Pause | Asym_Pause" by dynamic ability detection. Is it normal/expected? Or maybe the fix should go to different places? Thank you for your help. > Not sure whether you stated already which kernel version you're using. There's a brand-new extension to auto-detect 1000BaseX: f30e33bcdab9 ("net: phy: Add more 1000BaseX support detection") It's included in the 5.3-rc series. If a feature can be read from a vendor-specific register only, then the preferred way is: Implement callback get_features in the PHY driver, call genphy_read_abilities for the basic features and complement it with reading the vendor-specific register(s). > > Thanks, > > Tao > Heiner ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S 2019-07-31 5:53 ` Heiner Kallweit @ 2019-07-31 6:00 ` Tao Ren 2019-08-01 5:20 ` Tao Ren 0 siblings, 1 reply; 9+ messages in thread From: Tao Ren @ 2019-07-31 6:00 UTC (permalink / raw) To: Heiner Kallweit, Andrew Lunn Cc: Florian Fainelli, David S . Miller, Arun Parameswaran, Justin Chen, Vladimir Oltean, netdev, linux-kernel, Andrew Jeffery, openbmc On 7/30/19 10:53 PM, Heiner Kallweit wrote: > On 31.07.2019 02:12, Tao Ren wrote: >> On 7/29/19 11:00 PM, Heiner Kallweit wrote: >>> On 30.07.2019 07:05, Tao Ren wrote: >>>> On 7/29/19 8:35 PM, Andrew Lunn wrote: >>>>> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote: >>>>>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc >>>>>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic >>>>>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber >>>>>> mode (different sets of MII Control/Status registers being used), let's >>>>>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly. >>>>> >>>>> Hi Tao >>>>> >>>>> What exactly does it get wrong? >>>>> >>>>> Thanks >>>>> Andrew >>>> >>>> Hi Andrew, >>>> >>>> BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of the features (1000BaseT/100BaseT/10BaseT) can be detected by genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half ability in this mode. >>>> >>> Are you going to use the PHY in copper or fibre mode? >>> In case you use fibre mode, why do you need the copper modes set as supported? >>> Or does the PHY just start in fibre mode and you want to switch it to copper mode? >> >> Hi Heiner, >> >> The phy starts in fiber mode and that's the mode I want. >> My observation is: phydev->link is always 0 (Link status bit is never set in MII_BMSR) by using dynamic ability detection on my machine. I checked phydev->supported and it's set to "AutoNeg | TP | MII | Pause | Asym_Pause" by dynamic ability detection. Is it normal/expected? Or maybe the fix should go to different places? Thank you for your help. >> > > Not sure whether you stated already which kernel version you're using. > There's a brand-new extension to auto-detect 1000BaseX: > f30e33bcdab9 ("net: phy: Add more 1000BaseX support detection") > It's included in the 5.3-rc series. I'm running kernel 5.2.0. Thank you for the sharing and I didn't know the patch. Let me check it out. > If a feature can be read from a vendor-specific register only, > then the preferred way is: Implement callback get_features in > the PHY driver, call genphy_read_abilities for the basic features > and complement it with reading the vendor-specific register(s). Got it. Let me update my code and will come back soon. Thanks, Tao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S 2019-07-31 6:00 ` Tao Ren @ 2019-08-01 5:20 ` Tao Ren 2019-08-02 1:29 ` Tao Ren 2019-08-04 8:40 ` Heiner Kallweit 0 siblings, 2 replies; 9+ messages in thread From: Tao Ren @ 2019-08-01 5:20 UTC (permalink / raw) To: Heiner Kallweit, Andrew Lunn Cc: Florian Fainelli, David S . Miller, Arun Parameswaran, Justin Chen, Vladimir Oltean, netdev, linux-kernel, Andrew Jeffery, openbmc On 7/30/19 11:00 PM, Tao Ren wrote: > On 7/30/19 10:53 PM, Heiner Kallweit wrote: >> On 31.07.2019 02:12, Tao Ren wrote: >>> On 7/29/19 11:00 PM, Heiner Kallweit wrote: >>>> On 30.07.2019 07:05, Tao Ren wrote: >>>>> On 7/29/19 8:35 PM, Andrew Lunn wrote: >>>>>> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote: >>>>>>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc >>>>>>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic >>>>>>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber >>>>>>> mode (different sets of MII Control/Status registers being used), let's >>>>>>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly. >>>>>> >>>>>> Hi Tao >>>>>> >>>>>> What exactly does it get wrong? >>>>>> >>>>>> Thanks >>>>>> Andrew >>>>> >>>>> Hi Andrew, >>>>> >>>>> BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of the features (1000BaseT/100BaseT/10BaseT) can be detected by genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half ability in this mode. >>>>> >>>> Are you going to use the PHY in copper or fibre mode? >>>> In case you use fibre mode, why do you need the copper modes set as supported? >>>> Or does the PHY just start in fibre mode and you want to switch it to copper mode? >>> >>> Hi Heiner, >>> >>> The phy starts in fiber mode and that's the mode I want. >>> My observation is: phydev->link is always 0 (Link status bit is never set in MII_BMSR) by using dynamic ability detection on my machine. I checked phydev->supported and it's set to "AutoNeg | TP | MII | Pause | Asym_Pause" by dynamic ability detection. Is it normal/expected? Or maybe the fix should go to different places? Thank you for your help. >>> >> >> Not sure whether you stated already which kernel version you're using. >> There's a brand-new extension to auto-detect 1000BaseX: >> f30e33bcdab9 ("net: phy: Add more 1000BaseX support detection") >> It's included in the 5.3-rc series. > > I'm running kernel 5.2.0. Thank you for the sharing and I didn't know the patch. Let me check it out. I applied above patch and ca72efb6bdc7 ("net: phy: Add detection of 1000BaseX link mode support") to my 5.2.0 tree but got following warning when booting up my machine: "PHY advertising (0,00000200,000062c0) more modes than genphy supports, some modes not advertised". The BCM54616S PHY on my machine only reports 1000-X features in RGMII->1000Base-KX mode. Is it a known problem? Anyways let me see if I missed some dependency/follow-up patches.. Cheers, Tao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S 2019-08-01 5:20 ` Tao Ren @ 2019-08-02 1:29 ` Tao Ren 2019-08-04 8:40 ` Heiner Kallweit 1 sibling, 0 replies; 9+ messages in thread From: Tao Ren @ 2019-08-02 1:29 UTC (permalink / raw) To: Heiner Kallweit, Andrew Lunn Cc: Florian Fainelli, David S . Miller, Arun Parameswaran, Justin Chen, Vladimir Oltean, netdev, linux-kernel, Andrew Jeffery, openbmc On 7/31/19 10:20 PM, Tao Ren wrote: > On 7/30/19 11:00 PM, Tao Ren wrote: >> On 7/30/19 10:53 PM, Heiner Kallweit wrote: >>> On 31.07.2019 02:12, Tao Ren wrote: >>>> On 7/29/19 11:00 PM, Heiner Kallweit wrote: >>>>> On 30.07.2019 07:05, Tao Ren wrote: >>>>>> On 7/29/19 8:35 PM, Andrew Lunn wrote: >>>>>>> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote: >>>>>>>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc >>>>>>>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic >>>>>>>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber >>>>>>>> mode (different sets of MII Control/Status registers being used), let's >>>>>>>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly. >>>>>>> >>>>>>> Hi Tao >>>>>>> >>>>>>> What exactly does it get wrong? >>>>>>> >>>>>>> Thanks >>>>>>> Andrew >>>>>> >>>>>> Hi Andrew, >>>>>> >>>>>> BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of the features (1000BaseT/100BaseT/10BaseT) can be detected by genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half ability in this mode. >>>>>> >>>>> Are you going to use the PHY in copper or fibre mode? >>>>> In case you use fibre mode, why do you need the copper modes set as supported? >>>>> Or does the PHY just start in fibre mode and you want to switch it to copper mode? >>>> >>>> Hi Heiner, >>>> >>>> The phy starts in fiber mode and that's the mode I want. >>>> My observation is: phydev->link is always 0 (Link status bit is never set in MII_BMSR) by using dynamic ability detection on my machine. I checked phydev->supported and it's set to "AutoNeg | TP | MII | Pause | Asym_Pause" by dynamic ability detection. Is it normal/expected? Or maybe the fix should go to different places? Thank you for your help. >>>> >>> >>> Not sure whether you stated already which kernel version you're using. >>> There's a brand-new extension to auto-detect 1000BaseX: >>> f30e33bcdab9 ("net: phy: Add more 1000BaseX support detection") >>> It's included in the 5.3-rc series. >> >> I'm running kernel 5.2.0. Thank you for the sharing and I didn't know the patch. Let me check it out. > > I applied above patch and ca72efb6bdc7 ("net: phy: Add detection of 1000BaseX link mode support") to my 5.2.0 tree but got following warning when booting up my machine: > > "PHY advertising (0,00000200,000062c0) more modes than genphy supports, some modes not advertised". > > The BCM54616S PHY on my machine only reports 1000-X features in RGMII->1000Base-KX mode. Is it a known problem? > > Anyways let me see if I missed some dependency/follow-up patches.. Let's ignore the patch ("net: phy: broadcom: set features explicitly for BCM54616S"): as Heiner pointed out, it doesn't make sense to turn on copper features for fiber mode (even though it "works" in my environment). I will work out new patch if 1000bx-auto-detection patches cannot solve my problem. Thank you all for spending time on this. Cheers, Tao ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S 2019-08-01 5:20 ` Tao Ren 2019-08-02 1:29 ` Tao Ren @ 2019-08-04 8:40 ` Heiner Kallweit 1 sibling, 0 replies; 9+ messages in thread From: Heiner Kallweit @ 2019-08-04 8:40 UTC (permalink / raw) To: Tao Ren, Andrew Lunn Cc: Florian Fainelli, David S . Miller, Arun Parameswaran, Justin Chen, Vladimir Oltean, netdev, linux-kernel, Andrew Jeffery, openbmc On 01.08.2019 07:20, Tao Ren wrote: > On 7/30/19 11:00 PM, Tao Ren wrote: >> On 7/30/19 10:53 PM, Heiner Kallweit wrote: >>> On 31.07.2019 02:12, Tao Ren wrote: >>>> On 7/29/19 11:00 PM, Heiner Kallweit wrote: >>>>> On 30.07.2019 07:05, Tao Ren wrote: >>>>>> On 7/29/19 8:35 PM, Andrew Lunn wrote: >>>>>>> On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote: >>>>>>>> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc >>>>>>>> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic >>>>>>>> feature detection doesn't work when BCM54616S is working in RGMII-Fiber >>>>>>>> mode (different sets of MII Control/Status registers being used), let's >>>>>>>> set "PHY_GBIT_FEATURES" for BCM54616S explicitly. >>>>>>> >>>>>>> Hi Tao >>>>>>> >>>>>>> What exactly does it get wrong? >>>>>>> >>>>>>> Thanks >>>>>>> Andrew >>>>>> >>>>>> Hi Andrew, >>>>>> >>>>>> BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none of the features (1000BaseT/100BaseT/10BaseT) can be detected by genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half ability in this mode. >>>>>> >>>>> Are you going to use the PHY in copper or fibre mode? >>>>> In case you use fibre mode, why do you need the copper modes set as supported? >>>>> Or does the PHY just start in fibre mode and you want to switch it to copper mode? >>>> >>>> Hi Heiner, >>>> >>>> The phy starts in fiber mode and that's the mode I want. >>>> My observation is: phydev->link is always 0 (Link status bit is never set in MII_BMSR) by using dynamic ability detection on my machine. I checked phydev->supported and it's set to "AutoNeg | TP | MII | Pause | Asym_Pause" by dynamic ability detection. Is it normal/expected? Or maybe the fix should go to different places? Thank you for your help. >>>> >>> >>> Not sure whether you stated already which kernel version you're using. >>> There's a brand-new extension to auto-detect 1000BaseX: >>> f30e33bcdab9 ("net: phy: Add more 1000BaseX support detection") >>> It's included in the 5.3-rc series. >> >> I'm running kernel 5.2.0. Thank you for the sharing and I didn't know the patch. Let me check it out. > > I applied above patch and ca72efb6bdc7 ("net: phy: Add detection of 1000BaseX link mode support") to my 5.2.0 tree but got following warning when booting up my machine: > > "PHY advertising (0,00000200,000062c0) more modes than genphy supports, some modes not advertised". > It's genphy_config_advert complaining which is called from genphy_config_aneg. genphy_config_aneg deals with the standard Base-T modes. Therefore in your case most likely you want to provide an own config_aneg callback (in case autoneg is applicable at all). > The BCM54616S PHY on my machine only reports 1000-X features in RGMII->1000Base-KX mode. Is it a known problem? > > Anyways let me see if I missed some dependency/follow-up patches.. > > > Cheers, > > Tao > Heiner ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-08-04 8:40 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20190730002532.85509-1-taoren@fb.com>
2019-07-30 3:35 ` [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S Andrew Lunn
2019-07-30 5:05 ` Tao Ren
2019-07-30 6:00 ` Heiner Kallweit
2019-07-31 0:12 ` Tao Ren
2019-07-31 5:53 ` Heiner Kallweit
2019-07-31 6:00 ` Tao Ren
2019-08-01 5:20 ` Tao Ren
2019-08-02 1:29 ` Tao Ren
2019-08-04 8:40 ` Heiner Kallweit
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).