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 +
> > > 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 +, 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 +, 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 +, 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 +, 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 +, 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
one due to the
spamcop.net RBL domain having expired. Please don't resend until
this has been resolved. The problem has been reported to a
kernel.org admin (John Hawley) and others via IRC.
If you didn't get bounce messages from the attempt to send to
kernel.org email addresses, your email serv
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 +, 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 823 matches
Mail list logo
