Hi,
I'm seeing some odd behaviour with the netdev trigger and some WiFi
interfaces.
When the WiFi interface has never been brought up (so is in an
operationally disabled state), if I bind a LED to the netdev
trigger, setting the device_name to the WiFi interface name and
enable the "link" propert
Hi Andrew,
On Tue, Apr 13, 2021 at 03:12:05PM +0200, Andrew Lunn wrote:
> Is there something like this in the marvell10 driver?
No, it doesn't seem to be necessary there - I haven't seen spontaneous
link-ups with the 88x3310 there. Even if we did, that would cause other
issues beyond a nusience l
On Tue, Apr 13, 2021 at 11:59:20AM +0800, DENG Qingfang wrote:
> Within 12 hours, I got some spontaneous link down/ups when EEE is enabled:
>
> [16334.236233] mt7530 mdio-bus:1f wan: Link is Down
> [16334.241340] br-lan: port 3(wan) entered disabled state
> [16337.355988] mt7530 mdio-bus:1f wan: L
On Tue, Apr 13, 2021 at 12:00:45PM +0200, Lucas Stach wrote:
> I agree with the opinion that those PHY fixups introduce more harm than
> good. Essentially they are pushing board specific configuration values
> into the PHY, without any checks that the fixup is even running on the
> specific board i
On Tue, Apr 13, 2021 at 10:19:30AM +0300, Ivan Bornyakov wrote:
> On Tue, Apr 13, 2021 at 01:40:32AM +0200, Andrew Lunn wrote:
> > On Mon, Apr 12, 2021 at 03:16:59PM +0300, Ivan Bornyakov wrote:
> > > Some SFP modules uses RX_LOS for link indication. In such cases link
> > > will be always up, even
On Tue, Apr 13, 2021 at 11:45:31AM +0300, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> Add parser entries for different IPv4 IHL values.
> Each entry will set the L4 header offset according to the IPv4 IHL field.
> L3 header offset will set during the parsing of the IPv4 protocol.
What
On Fri, Apr 09, 2021 at 09:41:06PM +0300, Radu Pirea (NXP OSS) wrote:
> +#define B100T1_PMAPMD_CTL0x0834
> +#define B100T1_PMAPMD_CONFIG_EN BIT(15)
> +#define B100T1_PMAPMD_MASTER BIT(14)
> +#define MASTER_MODE (B100T1_PMAPMD_CONFIG_EN |
> B100T1_P
On Sat, Apr 10, 2021 at 03:06:52PM +0100, Matthew Wilcox wrote:
> How about moving the flags into the union? A bit messy, but we don't
> have to play games with __packed__.
Yes, that is probably the better solution, avoiding the games to try
and get the union appropriately placed on 32-bit system
On Wed, Apr 07, 2021 at 02:44:39PM +0200, Andrew Lunn wrote:
> > Intel mgbe is flexible to pair with any PHY. Only Aquantia/Marvell
> > multi-gige PHY can do rate adaption right?
>
> The Marvell/Marvell multi-gige PHY can also do rate
> adaptation. Marvell buying Aquantia made naming messy :-(
> I
On Sat, Apr 03, 2021 at 10:54:18AM +0100, Russell King - ARM Linux admin wrote:
> Hi,
>
> This question has probably come up several times before, but there
> doesn't seem to be a solution yet.
>
> Scenario: a network interface, such as a wireless adapter or a
> networ
On Mon, Apr 05, 2021 at 08:58:07PM +0200, Danilo Krummrich wrote:
> On Mon, Apr 05, 2021 at 03:33:55PM +0200, Andrew Lunn wrote:
> However, this was about something else - Russell wrote:
> > > > We have established that MDIO drivers need to reject accesses for
> > > > reads/writes that they do not
On Sat, Apr 03, 2021 at 10:54:18AM +0100, Russell King - ARM Linux admin wrote:
> Hi,
>
> This question has probably come up several times before, but there
> doesn't seem to be a solution yet.
>
> Scenario: a network interface, such as a wireless adapter or a
> networ
Hi,
This question has probably come up several times before, but there
doesn't seem to be a solution yet.
Scenario: a network interface, such as a wireless adapter or a
network interface supporting PTP, is part of a bridge. Userspace
wishes to capture packets sent using a specific Ethernet protoc
On Fri, Apr 02, 2021 at 03:10:49AM +0200, Danilo Krummrich wrote:
> On Thu, Apr 01, 2021 at 09:48:58AM +0100, Russell King - ARM Linux admin
> wrote:
> > Do you actually have a requirement for this?
> >
> Yes, the Marvell 88Q2112 1000Base-T1 PHY. But actually, I just recogniz
Hi,
I hadn't responded earlier because I wanted to think about it more,
but then forgot about this email.
On Thu, Mar 25, 2021 at 11:36:26AM -0500, George McCollister wrote:
> When I set port 9 on an mv88e6390, a cpu facing port to use 1000base-x
> (it also supports 2500base-x) in device-tree I f
On Thu, Apr 01, 2021 at 11:01:51PM +0800, Michael Sit Wei Hong wrote:
> + /* 2.5G mode only support 2500baseT full duplex only */
> + if (priv->plat->has_gmac4 && priv->plat->speed_2500_en) {
> + phylink_set(mac_supported, 2500baseT_Full);
> + phylink_set(mask, 10bas
On Thu, Apr 01, 2021 at 03:23:05AM +0200, danilokrummr...@dk-develop.de wrote:
> On 2021-03-31 20:35, Russell King - ARM Linux admin wrote:
> > On Wed, Mar 31, 2021 at 07:58:33PM +0200, danilokrummr...@dk-develop.de
> > wrote:
> > > For this cited change the only th
On Wed, Mar 31, 2021 at 07:58:33PM +0200, danilokrummr...@dk-develop.de wrote:
> For this cited change the only thing happening is that if get_phy_device()
> already failed for probing with is_c45==false (C22 devices) it tries to
> probe with is_c45==true (C45 devices) which then either results int
On Thu, Mar 25, 2021 at 09:54:14PM +0100, Marek Behún wrote:
> On Thu, 25 Mar 2021 21:44:21 +0100
> Heiner Kallweit wrote:
>
> > On 25.03.2021 21:29, Marek Behún wrote:
> > > On Thu, 25 Mar 2021 15:54:52 +0000
> > > Russell King - ARM Linux admin wrote:
> &
On Thu, Mar 25, 2021 at 02:12:49PM +0100, Marek Behún wrote:
> @@ -443,12 +446,24 @@ static int mv3310_probe(struct phy_device *phydev)
>
> switch (phydev->drv->phy_id) {
> case MARVELL_PHY_ID_88X3310:
> + ret = phy_read_mmd(phydev, MDIO_MMD_PMAPMD, MV_PMA_XGSTAT);
> +
On Thu, Mar 25, 2021 at 04:38:06PM +0800, Michael Sit Wei Hong wrote:
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 12a047d47dec..c95dfe4e5310 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -290,6 +290,8 @@ static int phylink_parse_mod
On Wed, Mar 24, 2021 at 05:11:25PM -0700, Florian Fainelli wrote:
> > And if you use rate matching mode, and the copper side is
> > linked in lower speed (2.5g for example), and the MAC will start
> > sending too many packets, the internal buffer in the PHY is only 16 KB,
> > so it will fill up qui
On Thu, Mar 25, 2021 at 12:45:25AM +0100, Marek Behún wrote:
> On Wed, 24 Mar 2021 16:16:41 -0700
> Florian Fainelli wrote:
>
> > On 3/24/2021 4:00 PM, Marek Behún wrote:
> > > On Wed, 24 Mar 2021 14:19:28 -0700
> > > Florian Fainelli wrote:
> > >
> > >>> Another problem is that if lower mode
On Wed, Mar 24, 2021 at 06:09:09PM +, Marek Behún wrote:
> On Wed, 24 Mar 2021 16:58:36 +
> Russell King - ARM Linux admin wrote:
>
> > On Wed, Mar 24, 2021 at 05:50:20PM +0100, Marek Behún wrote:
> > > Add all MACTYPE definitions for 88X3310/88X3310P.
>
On Wed, Mar 24, 2021 at 05:50:21PM +0100, Marek Behún wrote:
> Save MACTYPE instead of rate_matching boolean. We will need this for
> other configurations.
This could lead us to having to test for multiple different mactype
values depending on the PHY type in mv3310_update_interface() which
is som
On Wed, Mar 24, 2021 at 05:50:20PM +0100, Marek Behún wrote:
> Add all MACTYPE definitions for 88X3310/88X3310P.
>
> In order to have consistent naming, rename
> MV_V2_PORT_CTRL_MACTYPE_RATE_MATCH to
> MV_V2_PORT_CTRL_MACTYPE_10GR_RATE_MATCH.
We probably ought to note that the 88x3310 and 88x3340
On Mon, Mar 22, 2021 at 08:49:59PM +0100, Marek Behún wrote:
> diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> index 2766fe45bb98..4c5b8fabbec3 100644
> --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
On Fri, Mar 19, 2021 at 08:40:45AM +0100, Heiner Kallweit wrote:
> Is there a specific reason why c22 is probed first? Reversing the order
> would solve the issue we speak about here.
> c45-probing of c22-only PHY's shouldn't return false positives
> (at least at a first glance).
That would likely
On Thu, Mar 18, 2021 at 09:02:22AM -0700, Florian Fainelli wrote:
> On 3/18/2021 6:25 AM, Heiner Kallweit wrote:
> > On 18.03.2021 10:09, Wong Vee Khee wrote:
> >> When using Clause-22 to probe for PHY devices such as the Marvell
> >> 88E2110, PHY ID with value 0 is read from the MII PHYID register
On Tue, Mar 16, 2021 at 03:28:51PM +, Stefan Chulski wrote:
> No XDP doesn't require this. One of the use cases of the port reservation
> feature is the Marvell User Space SDK (MUSDK) which its latest code is
> publicly available here:
> https://github.com/MarvellEmbeddedProcessors/musdk-marv
On Fri, Mar 12, 2021 at 10:33:06AM -0800, Florian Fainelli wrote:
> On 3/11/21 4:04 AM, Joakim Zhang wrote:
> > I have a question about PHY framework, please point me if something I
> > misunderstanding.
> > There are many scenarios from PHY framework would trigger auto-nego, such
> > as switch f
On Wed, Mar 10, 2021 at 11:42:09AM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> According to Armada SoC architecture and design, all the PPv2 ports
> which are populated on the same communication processor silicon die
> (CP11x) share the same Classifier and Parser engines.
>
> Ar
On Wed, Mar 03, 2021 at 09:53:38AM -0800, Paul E. McKenney wrote:
> drivers/net: #ifdef mdio_bus_phy_suspend() and mdio_bus_phy_suspend()
>
> The following build error is emitted by rcutorture builds of v5.12-rc1:
>
> drivers/net/phy/phy_device.c:293:12: warning: ‘mdio_bus_phy_resume’ defined
>
Hi,
Mostly great, but just a couple more points.
On Wed, Mar 03, 2021 at 01:57:57PM +0300, Ivan Bornyakov wrote:
> + adv = 0;
> +
> + if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseX_Full_BIT,
> + priv->supported))
> + adv |= ADVERTISE_1000XFULL;
> +
On Thu, Feb 25, 2021 at 02:18:35PM +0200, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The ENETC port 0 MAC supports in-band status signaling coming from a PHY
> when operating in RGMII mode, and this feature is enabled by default.
>
> It has been reported that RGMII is broken in fixed-lin
On Thu, Feb 25, 2021 at 01:23:57PM +0200, Vladimir Oltean wrote:
> static void enetc_pl_mac_link_up(struct phylink_config *config,
>struct phy_device *phy, unsigned int mode,
>phy_interface_t interface, int speed,
> @@ -945,6 +981,10
On Sat, Feb 20, 2021 at 12:46:23PM +0300, Ivan Bornyakov wrote:
> Add basic support for the Marvell 88X multi-speed ethernet
> transceiver.
>
> This PHY provides data transmission over fiber-optic as well as Twinax
> copper links. The 88X supports 2 ports of 10GBase-R and 1000Base-X
> on t
On Fri, Feb 19, 2021 at 01:10:44PM +0300, Dan Carpenter wrote:
> The comments to phy_select_page() say that "phy_restore_page() must
> always be called after this, irrespective of success or failure of this
> call." If we don't call phy_restore_page() then we are still holding
> the phy_lock_mdio_
On Wed, Feb 17, 2021 at 03:06:21PM +, Russell King - ARM Linux admin wrote:
> On Wed, Feb 17, 2021 at 05:28:38PM +0300, Dan Carpenter wrote:
> > On Wed, Feb 17, 2021 at 09:17:59AM +0300, Dan Carpenter wrote:
> > > Smatch warns that there is a locking issu
On Wed, Feb 17, 2021 at 05:28:38PM +0300, Dan Carpenter wrote:
> On Wed, Feb 17, 2021 at 09:17:59AM +0300, Dan Carpenter wrote:
> > Smatch warns that there is a locking issue in this function:
> >
> > drivers/net/phy/icplus.c:273 ip101a_g_config_intr_pin()
> > warn: inconsistent returns '&phydev->
On Wed, Feb 17, 2021 at 04:58:26AM +0100, Andrew Lunn wrote:
> On Tue, Feb 16, 2021 at 04:54:53PM -0600, Robert Hancock wrote:
> > Add a flag and helper function to indicate that a PHY device is part of
> > an SFP module, which is set on attach. This can be used by PHY drivers
> > to handle SFP-spe
On Wed, Feb 17, 2021 at 11:12:11AM +0100, Michael Walle wrote:
> Am 2021-02-17 11:04, schrieb Russell King - ARM Linux admin:
> > On Wed, Feb 17, 2021 at 09:17:59AM +0300, Dan Carpenter wrote:
> > > Smatch warns that there is a locking issue in this function:
> > >
>
On Wed, Feb 17, 2021 at 09:17:59AM +0300, Dan Carpenter wrote:
> Smatch warns that there is a locking issue in this function:
>
> drivers/net/phy/icplus.c:273 ip101a_g_config_intr_pin()
> warn: inconsistent returns '&phydev->mdio.bus->mdio_lock'.
> Locked on : 242
> Unlocked on: 273
>
> It t
On Tue, Feb 16, 2021 at 04:52:13PM +, Robert Hancock wrote:
> On Sat, 2021-02-13 at 10:45 +0000, Russell King - ARM Linux admin wrote:
> > On Fri, Feb 12, 2021 at 08:18:40PM -0600, Robert Hancock wrote:
> > > + if (!phydev->sfp_bus &&
> > > + (!phydev-
On Mon, Feb 15, 2021 at 04:19:19PM +, Stefan Chulski wrote:
> > > > I discussed it with Andrew earlier last year, and his response was:
> > > >
> > > > DT configuration of pause for fixed link probably is sufficient. I
> > > > don't remember it ever been really discussed for DSA. It was a
> >
On Mon, Feb 15, 2021 at 04:16:27PM +0100, Marek Behun wrote:
> On Mon, 15 Feb 2021 14:57:57 +
> Russell King - ARM Linux admin wrote:
>
> > On Mon, Feb 15, 2021 at 02:47:56PM +0100, Marek Behun wrote:
> > > On Mon, 15 Feb 2021 06:15:59 +
> > > Nathan Ro
On Mon, Feb 15, 2021 at 02:47:56PM +0100, Marek Behun wrote:
> On Mon, 15 Feb 2021 06:15:59 +
> Nathan Rossi wrote:
>
> > diff --git a/drivers/net/dsa/mv88e6xxx/chip.c
> > b/drivers/net/dsa/mv88e6xxx/chip.c
> > index 54aa942eed..5c52906b29 100644
> > --- a/drivers/net/dsa/mv88e6xxx/chip.c
>
On Sun, Feb 14, 2021 at 03:16:23PM +0100, Heiner Kallweit wrote:
> Some internal PHY's have their events like link change reported by the
> MAC interrupt. We have PHY_IGNORE_INTERRUPT to deal with this scenario.
> I'm not too happy with this name. We don't ignore interrupts, typically
> there is no
On Sun, Feb 14, 2021 at 01:10:14PM +0200, Vladimir Oltean wrote:
> On Sun, Feb 14, 2021 at 10:35:29AM +0000, Russell King - ARM Linux admin
> wrote:
> > As mentioned in this thread, we have at least one PHY which is unable
> > to provide the inband signalling in any mode (BC
On Fri, Feb 12, 2021 at 07:23:40PM +0200, Vladimir Oltean wrote:
> + ret = phy_config_inband_aneg(phy,
> + (pl->cur_link_an_mode == MLO_AN_INBAND));
Please use phylink_autoneg_inband(pl->cur_link_an_mode) here.
> + if (ret && ret != -EOPNOTSUPP) {
> +
On Sat, Feb 13, 2021 at 08:57:46PM +0100, Michael Walle wrote:
> But then why bother with config_inband_aneg() at all and just enable
> it unconditionally in config_init(). [and maybe keep the return -EINVAL].
> Which then begs the question, does it makes sense on (Q)SGMII links at
> all?
There ar
On Sat, Feb 13, 2021 at 05:41:55PM +0100, Michael Walle wrote:
> Am 2021-02-13 01:18, schrieb Russell King - ARM Linux admin:
> > That is a function of the interface mode and the PHY capabilities.
> >
> > 1) if the PHY supports rate adaption, and is programmed for that, the
On Sun, Jan 31, 2021 at 12:19:50PM +, Russell King - ARM Linux admin wrote:
> On Sun, Jan 31, 2021 at 11:12:14AM +0000, Russell King - ARM Linux admin
> wrote:
> > I discussed it with Andrew earlier last year, and his response was:
> >
> > DT configuration of pause
On Fri, Feb 12, 2021 at 08:18:40PM -0600, Robert Hancock wrote:
> + if (!phydev->sfp_bus &&
> + (!phydev->attached_dev || !phydev->attached_dev->sfp_bus)) {
First, do we want this to be repeated in every driver?
Second, are you sure this is the correct condition to be using for
this?
On Fri, Feb 12, 2021 at 06:26:29PM -0600, Robert Hancock wrote:
> When 88E111 is operating in SGMII mode, auto-negotiation should be enabled
88E.
> on the SGMII side so that the link will come up properly with PCSes which
> normally have auto-negotiation enabled. This is normally the case whe
On Fri, Feb 12, 2021 at 11:40:59PM +0100, Michael Walle wrote:
> Fun fact, now it may be the other way around. If the bootloader doesn't
> configure it and the PHY isn't reset by the hardware, it won't work in
> the bootloader after a reboot ;)
If we start messing around with the configuration of
On Thu, Feb 11, 2021 at 05:13:19PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> The condition should be skipped if CPU ID equal to nthreads.
> The patch doesn't fix any actual issue since
> nthreads = min_t(unsigned int, num_present_cpus(), MVPP2_MAX_THREADS).
> On all current Arm
On Thu, Feb 11, 2021 at 01:22:35PM +, Stefan Chulski wrote:
> > Ditto.
> >
> > I don't think these need to be fixed in the net tree, but it would still be
> > nice
> > to fix the problem. Please do so, as an initial patch in your series - so
> > we can
> > then backport if it turns out to ev
On Thu, Feb 11, 2021 at 01:02:14PM +, Stefan Chulski wrote:
> > On Thu, Feb 11, 2021 at 12:48:55PM +0200, stef...@marvell.com wrote:
> > > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > index 761f745..8b4073c 100644
> >
On Thu, Feb 11, 2021 at 12:49:01PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> This patch fix GMAC TX flow control autoneg.
> Flow control autoneg wrongly were disabled with enabled TX
> flow control.
>
> Signed-off-by: Stefan Chulski
> Acked-by: Marcin Wojtas
Should this pat
On Thu, Feb 11, 2021 at 12:49:00PM +0200, stef...@marvell.com wrote:
> +/* Configure Rx FIFO Flow control thresholds */
> +void mvpp23_rx_fifo_fc_en(struct mvpp2 *priv, int port, bool en)
> +{
> + int val;
u32 ?
> +
> + val = mvpp2_read(priv, MVPP2_RX_FC_REG(port));
> +
> + if
On Thu, Feb 11, 2021 at 12:48:56PM +0200, stef...@marvell.com wrote:
> +static void mvpp2_cm3_write(struct mvpp2 *priv, u32 offset, u32 data)
> +{
> + writel(data, priv->cm3_base + offset);
> +}
> +
> +static u32 mvpp2_cm3_read(struct mvpp2 *priv, u32 offset)
> +{
> + return readl(priv->cm3
On Thu, Feb 11, 2021 at 12:48:55PM +0200, stef...@marvell.com wrote:
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 761f745..8b4073c 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethern
On Thu, Feb 11, 2021 at 12:48:54PM +0200, stef...@marvell.com wrote:
> @@ -751,6 +760,10 @@
> #define MVPP2_TX_FIFO_THRESHOLD(kb) \
> ((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
>
> +/* MSS Flow control */
> +#define FC_QUANTA0x
> +#define FC_CLK_DIVIDER
On Thu, Feb 11, 2021 at 12:48:52PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> This patch add PPv23 version definition.
> PPv23 is new packet processor in CP115.
> Everything that supported by PPv22, also supported by PPv23.
> No functional changes in this stage.
>
> Signed-off-
On Thu, Feb 11, 2021 at 12:48:53PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> BM pool and RXQ size increased to support Firmware Flow Control.
> Minimum depletion thresholds to support FC are 1024 buffers.
> BM pool size increased to 2048 to have some 1024 buffers
> space betwee
On Thu, Feb 11, 2021 at 12:48:51PM +0200, stef...@marvell.com wrote:
> @@ -1199,7 +1199,7 @@ static bool mvpp2_port_supports_xlg(struct mvpp2_port
> *port)
>
> static bool mvpp2_port_supports_rgmii(struct mvpp2_port *port)
> {
> - return !(port->priv->hw_version == MVPP22 && port->gop_id =
On Thu, Feb 11, 2021 at 12:48:50PM +0200, stef...@marvell.com wrote:
> +static int mvpp2_get_sram(struct platform_device *pdev,
> + struct mvpp2 *priv)
> +{
> + struct resource *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> + if (!res) {
> +
On Thu, Feb 11, 2021 at 12:48:48PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> Patch adds CM3 address space and PPv2.3 description.
>
> Signed-off-by: Stefan Chulski
> Acked-by: Marcin Wojtas
It seems this is missing the ack that you got from Rob in your previous
posting. You
On Wed, Feb 10, 2021 at 07:47:20PM +0300, Serge Semin wrote:
> On Tue, Feb 09, 2021 at 10:56:46AM +0000, Russell King - ARM Linux admin
> wrote:
> > On Tue, Feb 09, 2021 at 11:37:29AM +0100, Heiner Kallweit wrote:
> > > Right, adding something like a genphy_{read,writ
On Wed, Feb 10, 2021 at 12:20:02PM +0100, Michael Walle wrote:
>
> Am 2021-02-09 17:38, schrieb Michael Walle:
> > --- a/drivers/net/phy/phy.c
> > +++ b/drivers/net/phy/phy.c
> > @@ -308,7 +308,7 @@ void phy_ethtool_ksettings_get(struct phy_device
> > *phydev,
> > if (phydev->interface == PHY_
On Wed, Feb 10, 2021 at 12:14:35PM +0100, Michael Walle wrote:
> Am 2021-02-10 11:49, schrieb Russell King - ARM Linux admin:
> The PHY doesn't support fiber and register 0..15 are always available
> regardless of the selected page for the IP101G.
>
> genphy_() stuff will work
On Wed, Feb 10, 2021 at 02:51:34AM +0100, Andrew Lunn wrote:
> This is a general comment, not a problem specific to this patch.
>
> There is some interesting race conditions here. The marvell driver
> first checks the fibre page and gets the status of the fiber port. As
> you can see from the hunk
On Wed, Feb 10, 2021 at 11:38:18AM +0100, Michael Walle wrote:
> Am 2021-02-10 11:30, schrieb Russell King - ARM Linux admin:
> > On Wed, Feb 10, 2021 at 08:03:07AM +0100, Heiner Kallweit wrote:
> > > On 09.02.2021 17:40, Michael Walle wrote:
> > > > +out:
> >
On Wed, Feb 10, 2021 at 08:03:07AM +0100, Heiner Kallweit wrote:
> On 09.02.2021 17:40, Michael Walle wrote:
> > +out:
> > + return phy_restore_page(phydev, oldpage, err);
>
> If a random page was set before entering config_init, do we actually want
> to restore it? Or wouldn't it be better to s
On Tue, Feb 09, 2021 at 10:42:31AM +0200, stef...@marvell.com wrote:
> if (priv->global_tx_fc && priv->hw_version != MVPP21) {
> - val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
> - val |= FLOW_CONTROL_ENABLE_BIT;
> - mvpp2_cm3_write(priv, MSS_FC_COM_REG, val)
On Tue, Feb 09, 2021 at 11:37:29AM +0100, Heiner Kallweit wrote:
> Right, adding something like a genphy_{read,write}_mmd() doesn't make
> too much sense for now. What I meant is just exporting mmd_phy_indirect().
> Then you don't have to open-code the first three steps of a mmd read/write.
> And i
On Tue, Feb 09, 2021 at 01:15:28PM +0300, Serge Semin wrote:
> On Mon, Feb 08, 2021 at 09:14:02PM +0100, Heiner Kallweit wrote:
> > Nice analysis. Alternatively to duplicating this code piece we could
> > export mmd_phy_indirect(). But up to you.
>
> I also considered creating a generic method to
On Mon, Feb 08, 2021 at 08:42:36PM +0530, Calvin Johnson wrote:
> +int fwnode_mdiobus_register_phy(struct mii_bus *bus,
> + struct fwnode_handle *child, u32 addr)
> +{
> + struct mii_timestamper *mii_ts;
If you initialise this to NULL...
> + struct phy_device *
On Mon, Feb 08, 2021 at 08:42:44PM +0530, Calvin Johnson wrote:
> Modify dpaa2_mac_connect() to support ACPI along with DT.
> Modify dpaa2_mac_get_node() to get the dpmac fwnode from either
> DT or ACPI.
>
> Replace of_get_phy_mode with fwnode_get_phy_mode to get
> phy-mode for a dpmac_node.
>
>
On Mon, Feb 08, 2021 at 08:42:42PM +0530, Calvin Johnson wrote:
> Define phylink_fwnode_phy_connect() to connect phy specified by
> a fwnode to a phylink instance.
>
> Signed-off-by: Calvin Johnson
Also, the subject line should be "net: phylink: ..." Consistency is
really appreciated.
Thanks.
On Mon, Feb 08, 2021 at 08:42:42PM +0530, Calvin Johnson wrote:
> +int phylink_fwnode_phy_connect(struct phylink *pl,
> +struct fwnode_handle *fwnode,
> +u32 flags)
> +{
> + struct fwnode_handle *phy_fwnode;
> + struct phy_device *phy_
On Mon, Feb 08, 2021 at 10:20:38AM +0100, Oleksij Rempel wrote:
> On Wed, Feb 03, 2021 at 09:56:28AM +0000, Russell King - ARM Linux admin
> wrote:
> > That is the historical fix for this problem, but there is a better
> > solution now in net-next - configuring the Tw par
Hi,
This patch series adds 1000base-X support to pcs-lynx and DPAA2,
allowing runtime switching between SGMII and 1000base-X. This is
a pre-requisit for SFP module support on the SolidRun ComExpress 7.
v2: updated with Ioana's r-b's, and comment on backplane support
drivers/net/ethernet/freesca
On Wed, Jan 20, 2021 at 10:19:01PM +, Ioana Ciornei wrote:
> On Tue, Jan 19, 2021 at 03:36:09PM +, Russell King wrote:
> > Add support for backplane link mode, which is, according to discussions
> > with NXP earlier in the year, is a mode where the OS (Linux) is able to
> > manage the PCS a
On Wed, Feb 03, 2021 at 10:18:55AM +0100, Oleksij Rempel wrote:
> This fixup removes the Lpi_en bit.
>
> If this patch breaks functionality of your board, use following device
> tree properties:
>
> ethernet-phy@X {
> reg = <0xX>;
> eee-broken-1000t;
>
On Wed, Feb 03, 2021 at 10:18:50AM +0100, Oleksij Rempel wrote:
> This patch series tries to remove most of the imx6 and imx7 board
> specific PHY configuration via fixup, as this breaks the PHYs when
> connected to switch chips or USB Ethernet MACs.
>
> Each patch has the possibility to break boa
On Mon, Feb 01, 2021 at 10:22:51PM +0300, Ivan Bornyakov wrote:
> +/* PMD Transmit Disable */
> +#define MV_TX_DISABLE 0x0009
> +#define MV_TX_DISABLE_GLOBALBIT(0)
Please use MDIO_PMA_TXDIS and MDIO_PMD_TXDIS_GLOBAL; this is an
IEEE802.3 defined register.
> +/* 10GBASE-R P
On Sun, Jan 31, 2021 at 02:45:24PM +, Russell King - ARM Linux admin wrote:
> On Sun, Jan 31, 2021 at 02:23:20PM +, Stefan Chulski wrote:
> > I still don't see all patches in
> > https://patchwork.kernel.org/project/netdevbpf/list/?series=424949
> > I would
On Sun, Jan 31, 2021 at 02:23:20PM +, Stefan Chulski wrote:
> I still don't see all patches in
> https://patchwork.kernel.org/project/netdevbpf/list/?series=424949
> I would reduce patch series to 15 patches and repost again.
kernel.org email is currently broken for everyone due to the
spamco
On Sun, Jan 31, 2021 at 11:12:14AM +, Russell King - ARM Linux admin wrote:
> I discussed it with Andrew earlier last year, and his response was:
>
> DT configuration of pause for fixed link probably is sufficient. I don't
> remember it ever been really discussed for DSA.
On Sun, Jan 31, 2021 at 10:51:46AM +, Stefan Chulski wrote:
>
> > > Hi,
> > >
> > > Armada has options for 1G/10G ports without PHY's(for example
> > community board Macchiato single shot).
> > > This port doesn't have PHY's and cannot negotiate Flow Control support,
> > but we can for example
On Sun, Jan 31, 2021 at 10:12:25AM +, Stefan Chulski wrote:
> Hi,
>
> Armada has options for 1G/10G ports without PHY's(for example community board
> Macchiato single shot).
> This port doesn't have PHY's and cannot negotiate Flow Control support, but
> we can for example connect two ports w
NOTE: not all recipients will have received this, because kernel.org
is using bl.spamcop.net, and that currently lists the universe (the
domain has due for renewal and the registry has made *.spamcop.net
resolve to their parking webserver.)
On Sun, Jan 31, 2021 at 10:58:15AM +, Russell King wr
On Wed, Jan 27, 2021 at 01:43:16PM +0200, stef...@marvell.com wrote:
> Armada hardware has a pause generation mechanism in GOP (MAC).
> The GOP generate flow control frames based on an indication programmed in
> Ports Control 0 Register. There is a bit per port.
> However assertion of the PortX Pa
On Wed, Jan 27, 2021 at 06:41:32PM +, Stefan Chulski wrote:
>
> >
> > > From: Stefan Chulski
> > >
> > > RXQ non occupied descriptor threshold would be used by Flow Control
> > > Firmware feature to move to the XOFF mode.
> > > RXQ non occupied threshold would change interrupt cause that pol
On Thu, Jan 28, 2021 at 01:00:57AM +0100, Andrew Lunn wrote:
> On Tue, Jan 26, 2021 at 01:49:38PM +0000, Russell King - ARM Linux admin
> wrote:
> > On Tue, Jan 26, 2021 at 02:14:40PM +0100, Andrew Lunn wrote:
> > > On Tue, Jan 26, 2021 at 08:33:37AM +0100, Mike Looijma
On Wed, Jan 27, 2021 at 02:37:34PM +, Stefan Chulski wrote:
> Your mcbin-ss is A8K AX or A8K B0? On AX revisions we do not have FC support
> in firmware.
How do I tell? I don't want to remove the heatsink, and I don't see
anything in MV-S88-00E. I didn't grab a copy of the Errata before
I
On Wed, Jan 27, 2021 at 03:10:11PM +, Stefan Chulski wrote:
> You can devmem 0xF2400240(Device ID Status Register).
> #define A8040_B0_DEVICE_ID 0x8045
> #define A8040_AX_DEVICE_ID 0x8040
> #define A7040_B0_DEVICE_ID 0x7045
> #define A7040_AX_DEVICE_ID 0x7040
> #define A3900
On Wed, Jan 27, 2021 at 01:43:35PM +0200, stef...@marvell.com wrote:
> if (priv->global_tx_fc && priv->hw_version != MVPP21) {
> - val = mvpp2_cm3_read(priv, MSS_FC_COM_REG);
> - val |= FLOW_CONTROL_ENABLE_BIT;
> - mvpp2_cm3_write(priv, MSS_FC_COM_REG, val)
1 - 100 of 1138 matches
Mail list logo
