> -Original Message-
> From: Marcin Wojtas
> Sent: Tuesday, April 13, 2021 12:59 PM
> To: Stefan Chulski
> Cc: Russell King - ARM Linux admin ;
> netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linu
> > -Original Message-
> > From: Russell King - ARM Linux admin
> > Sent: Tuesday, April 13, 2021 12:18 PM
> > To: Stefan Chulski
> > Cc: netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> > da...@davemloft.net; Nadav Haklai ; Yan
> Markman
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Tuesday, April 13, 2021 12:18 PM
> To: Stefan Chulski
> Cc: netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linux-ker...@vger.kernel.org;
> > CM3 won't use this interface till ethtool priv flag was set, it can be done
> > by
> communication over CM3 SRAM memory.
> >
> > > How does CM3 know the status of the link?
> >
> > CM3 has access to MAC registers and can read port status bit.
> >
> > > How does CM3 set its
> > > flow control d
> > 2. CM3 code has very small footprint requirement, we cannot
> > implement the complete Serdes and PHY infrastructure that kernel
> > provides as part of CM3 application. Therefore I would like to
> > continue relying on kernel configuration for that.
>
> How can that work? How does Linux
> I really, really hope that someone has thought this through:
>
> Packet Processor I/O Interface (PPIO)
>
>The MUSDK PPIO driver provides low-level network interface API for
>User-Space network drivers/applications. The PPIO infrastrcuture maps
>Marvell's Packet Processor (PPv2) co
> Hi Stefan
>
> Thanks for the strings change. Looks a lot better.
>
> Now i took a look at the bigger picture.
>
> > 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
> > 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.
> >
> > Armada is an
> -Original Message-
> From: Andrew Lunn
> Sent: Wednesday, March 10, 2021 5:51 PM
> To: Stefan Chulski
> Cc: netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linux-ker...@vger.kernel.org;
> > > > > 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 Melanox discussion about limiting pause for the
> > > 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
> > > Melanox discussion about limiting pause for the CPU. So I think it
>
> > 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
> > > Or we have also found out, that pushing back on parameters like
> > > this, the developers goes back and looks at the code, and sometimes
> > > figures out a way to automatically do the right thing, removing the
> > > configuration knob, and just making it all simpler for the user to
> > >
> --
> Hello:
>
> This series was applied to netdev/net-next.git (refs/heads/master):
>
> On Thu, 11 Feb 2021 12:48:47 +0200 you wrote:
> > From: Stefan Chulski
> >
> > Armada hardware has
> 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 eventually be necessary.
>
> Thanks.
My series already has 15 patches and patc
> > +/* Configure Rx FIFO Flow control thresholds */ void
> > +mvpp23_rx_fifo_fc_en(struct mvpp2 *priv, int port, bool en) {
> > + int val;
>
> u32 ?
OK.
> > +
> > + val = mvpp2_read(priv, MVPP2_RX_FC_REG(port));
> > +
> > + if (en)
> > + val |= MVPP2_RX_FC_EN;
> > + el
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Thursday, February 11, 2021 2:50 PM
> To: Stefan Chulski
> Cc: netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linux-ker...
> --
> 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.
&g
> 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
>
> --
> From:
> Date: Wed, 10 Feb 2021 11:48:17 +0200
>
> >
> > +static int bm_underrun_protect = 1;
> > +
> > +module_param(bm_underrun_protect, int, 0444);
> > +MODULE_PARM_DESC(bm_underrun_protect, "Set BM underrun protect
> > 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);
> > + err = mvpp2_enable_global_fc(priv);
> > +
> > @@ -12,7 +13,7 @@ Required properties:
> > - common controller registers
> > - LMS registers
> > - one register area per Ethernet port
> > - For "marvell,armada-7k-pp2", must contain the following register
> > + For "marvell,armada-7k-pp2" used by 7K/8K and CN913X, must contain
>
> > + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > + if (!priv->sram_pool) {
> > + if (!defer_once) {
> > + defer_once = true;
> > + /* Try defer once */
> > + return -EPR
> > }
> >
> > +static int mvpp2_get_sram(struct platform_device *pdev,
> > + struct mvpp2 *priv)
> > +{
> > + struct device_node *dn = pdev->dev.of_node;
> > + static bool defer_once;
> > + struct resource *res;
> > +
> > + if (has_acpi_companion(&pdev->dev)) {
> > +
> --
> On Sat, 6 Feb 2021 18:45:48 +0200 stef...@marvell.com wrote:
> > From: Konstantin Porotchkin
> >
> > CM3 SRAM address space would be used for Flow Control configuration.
> >
> > Signe
> On Sun, 31 Jan 2021 16:33:43 +0200 stef...@marvell.com wrote:
> > v6 --> v7
> > - Reduce patch set from 18 to 15 patches
> > - Documentation change combined into a single patch
> > - RXQ and BM size change combined into a single patch
> > - Ring size change check moved into "add RXQ flow contr
> > 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 without PHY's and manually(by
> ethtool) configure FC.
>
>
> Ok, kernel.org has now dropped spamcop.net, so email should flow normally
> now.
>
> Are you sure all your emails are being received by vger.kernel.org?
No, I get Undeliverable Email response. I probably would wait till tomorrow and
repost them again as v8.
Regards,
Stefan.
> >
> > Hi Stefan, looks like patchwork and lore didn't get all the emails:
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__lore.kernel.org_r_1611858682-2D9845-2D1-2Dgit-2Dsend-2Demail-
> > 2Dstefanc-
> >
> 40marvell.com&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DDQ3dKwkTIx
> >
> KAl6_B
>
> Hi Stefan, looks like patchwork and lore didn't get all the emails:
>
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lore.kernel.org_r_1611858682-2D9845-2D1-2Dgit-2Dsend-2Demail-
> 2Dstefanc-
> 40marvell.com&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=DDQ3dKwkTIx
> KAl6_Bs7GMx4zhJArrXKN2mD
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 without PHY's and manually(by ethtool)
configure FC.
Current phylink return
>
> > 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 polled by
> > CM3 Firmware.
> > A
> > index 9d8993f..f34e260 100644
> > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> > @@ -1021,6 +1021,11 @@ struct mvpp2 {
> >
> > /* CM3 SRAM pool */
> > struct gen_pool *sram_pool;
> > +
> > + bool custom_dma_mask;
>
> > 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_A1_DEVICE_ID 0x6025
> > #define CN9130_DEVICE_
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Wednesday, January 27, 2021 5:00 PM
> To: Stefan Chulski
> Cc: netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linux-ker...
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Wednesday, January 27, 2021 4:06 PM
> To: Stefan Chulski
> Cc: netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linux-ker...@vger.kernel.o
> > >
> > >
> > > -- On Sun, Jan 24, 2021 at 01:43:57PM +0200, stef...@marvell.com
> > > wrote:
> > > > +/* Set Flow Control timer x140 faster than pause quanta to ensure
> > > > +that link
> > > > + * partner won't send taffic if
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -91,6 +92,18 @@ static inline u32 mvpp2_cpu_to_thread(struct
> mvpp2 *priv, int cpu)
> > return cpu % priv->nthreads;
> > }
> >
> > +static inline
> > +void mvpp2_cm3_write(struct mv
> > We cannot access PPv2 register space before enabling clocks(done in
> mvpp2_probe) , PP21 and PP22/23 have different sets of clocks.
>
> > So diff between PP21 and PP22/23 should be stored in device tree(in
> > of_device_id), with MVPP22 and MVPP21 stored as .data
>
> Hi Stefan
>
> As far as
>
> --
> On Sun, Jan 24, 2021 at 01:43:57PM +0200, stef...@marvell.com wrote:
> > +/* Set Flow Control timer x140 faster than pause quanta to ensure
> > +that link
> > + * partner won't send taffic if port in XOFF mode.
>
> Can y
> > Signed-off-by: Stefan Chulski
> > ---
> > drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 24 --
> --
> > drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +-
> > 2 files changed, 25 insertions(+), 16 deletions(-)
> >
> > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > @@ -1154,6 +1154,9 @@ static void mvpp2_interrupts_mask(void *arg)
> > mvpp2_thread_write(port->priv,
> >mvpp2_cpu_to_thread(port->priv,
> smp_processo
>
> --
> On Sun, Jan 24, 2021 at 01:44:02PM +0200, stef...@marvell.com wrote:
> > @@ -6407,6 +6490,29 @@ static void mvpp2_mac_link_up(struct
> phylink_config *config,
> > val);
> > }
> >
> > + if (t
> > From: Stefan Chulski
> >
> > This patch doesn't change any functionality, but just extend MIB
> > counter register and ethtool-statistic names with "err".
> >
> > The counter MVPP2_MIB_FRAGMENTS_RCVD in fact is Error counter.
> > Ex
>
> On Sun, Jan 10, 2021 at 06:55:11PM +, Stefan Chulski wrote:
> > > > not connected to the GOP flow control generation mechanism.
> > > > To solve this issue Armada has firmware running on CM3 CPU
> > > > dedectated for Flow Control support.
> > not connected to the GOP flow control generation mechanism.
> > To solve this issue Armada has firmware running on CM3 CPU dedectated
> > for Flow Control support. Firmware monitors Packet Processor resources
> > and asserts XON/XOFF by writing to Ports Control 0 Register.
>
> What is the mini
> Sorry, but that is not really a decision the driver can make. It is part of a
> kernel
> that _does_ support CPU hotplug, and the online CPUs can be changed today.
>
> It is likely that every distro out there builds the kernel with CPU hotplug
> enabled.
>
> If changing the online CPUs causes
> > @@ -5373,6 +5402,30 @@ static int
> mvpp2_ethtool_set_pause_param(struct net_device *dev,
> > struct ethtool_pauseparam *pause) {
> > struct mvpp2_port *port = netdev_priv(dev);
> > + int i;
> > +
> > + if (pause->tx_pause && port->priv->global_tx_f
> >
> > +/* Routine calculate single queue shares address space */ static int
> > +mvpp22_calc_shared_addr_space(struct mvpp2_port *port) {
> > + /* If number of CPU's greater than number of threads, return last
> > +* address space
> > +*/
> > + if (num_active_cpus() >= MVPP2_MAX_THREA
> > > > + } else {
> > > > + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > > > + if (!priv->sram_pool) {
> > > > + dev_warn(&pdev->dev, "DT is too old, TX FC
> > > disabled\n");
> > >
> > > I don't see anything in this patch that di
> > + } else {
> > + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > + if (!priv->sram_pool) {
> > + dev_warn(&pdev->dev, "DT is too old, TX FC
> disabled\n");
>
> I don't see anything in this patch that disables TX flow control, which means
> this
> > @@ -5373,6 +5402,30 @@ static int
> mvpp2_ethtool_set_pause_param(struct net_device *dev,
> > struct ethtool_pauseparam *pause) {
> > struct mvpp2_port *port = netdev_priv(dev);
> > + int i;
> > +
> > + if (pause->tx_pause && port->priv->global_tx_f
>
> > > Should there be -EPROBE_DEFER handling in here somewhere? The SRAM
> > > is a device, so it might not of been probed yet?
> >
>
> > No, firmware probed during bootloader boot and we can use SRAM. SRAM
> > memory can be safely used.
>
> A previous patch added:
>
> + CP11X_L
> External Email
>
> --
> On Sun, Jan 10, 2021 at 05:30:10PM +0200, stef...@marvell.com wrote:
> > From: Stefan Chulski
> >
> > BM pool size increased to support Firmware Flow Control.
> > Min
> -Original Message-
> From: Andrew Lunn
> Sent: Sunday, January 10, 2021 7:05 PM
> To: Stefan Chulski
> Cc: netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-ker...@vger.kernel.org;
>
> --
> On Thu, 17 Dec 2020 18:07:58 +0200 stef...@marvell.com wrote:
> > From: Stefan Chulski
> >
> > Patch didn't fix any issue, just improve parse flow and align ipv4
> > parse flow w
> External Email
>
> --
> On Thu, 17 Dec 2020 14:37:28 +0200 stef...@marvell.com wrote:
> > From: Stefan Chulski
> >
> > During GoP port 2 Networking Complex Control mode of operation
> > con
> Quoting stef...@marvell.com (2020-12-17 18:45:06)
> > From: Stefan Chulski
> >
> > Issue:
> > Flow control frame used to pause GoP(MAC) was delivered to the CPU and
> > created a load on the CPU. Since XOFF/XON frames are used only by MAC,
> > th
> External Email
>
> --
> Hi Stefan,
>
> Quoting stef...@marvell.com (2020-12-17 18:23:11)
> > From: Stefan Chulski
> >
> > Current PPPoE+IPv6 entry is jumping to 'next-hdr'
>
> On Thu, Dec 17, 2020 at 12:00:49PM +0100, Marcin Wojtas wrote:
> > Hi Stefan,
> >
> > czw., 17 gru 2020 o 10:42 napisał(a):
> > >
> > > From: Stefan Chulski
> > >
> > > Force link UP can be enabled by bootloader during tftpboot and
>
> -Original Message-
> From: Jakub Kicinski
> Sent: Thursday, December 17, 2020 2:42 AM
> To: Stefan Chulski
> Cc: netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-ker...@vger.kernel.org;
>
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Monday, November 23, 2020 7:30 PM
> To: Stefan Chulski
> Cc: netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-ker...@vger.kernel
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Monday, November 23, 2020 5:52 PM
> To: Stefan Chulski
> Cc: netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-ker...@vger.kernel
> > > On Mon, Nov 23, 2020 at 04:52:40PM +0200, stef...@marvell.com wrote:
> > > > From: Stefan Chulski
> > > >
> > > > Tx/Rx FIFO is a HW resource limited by total size, but shared by
> > > > all ports of same CP110 and impacting port-pe
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Monday, November 23, 2020 5:11 PM
> To: Stefan Chulski
> Cc: netdev@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-ker...@vger.kernel.org;
> -Original Message-
> From: stef...@marvell.com
> Sent: Wednesday, November 18, 2020 8:21 PM
> To: netdev@vger.kernel.org
> Cc: thomas.petazz...@bootlin.com; da...@davemloft.net; Nadav Haklai
> ; Yan Markman ; linux-
> ker...@vger.kernel.org; Stefan Chulski
&
> -Original Message-
> From: Matteo Croce
> Sent: Saturday, May 9, 2020 3:16 PM
> To: Stefan Chulski
> Cc: David S . Miller ; Maxime Chevallier
> ; netdev ; LKML
> ; Antoine Tenart
> ; Thomas Petazzoni
> ; gregory.clem...@bootlin.com;
> miquel.ray...@boot
> -Original Message-
> From: Matteo Croce
> Sent: Saturday, May 9, 2020 3:13 AM
> To: David S . Miller
> Cc: Maxime Chevallier ; netdev
> ; LKML ; Antoine
> Tenart ; Thomas Petazzoni
> ; gregory.clem...@bootlin.com;
> miquel.ray...@bootlin.com; Nadav Haklai
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Monday, February 18, 2019 1:28 PM
> To: Stefan Chulski
> Cc: Antoine Tenart ; da...@davemloft.net;
> netdev@vger.kernel.org; linux-ker...@vger.kernel.org;
> thomas.petazz...@bootlin.com; maxime.c
hevall...@bootlin.com;
> gregory.clem...@bootlin.com; miquel.ray...@bootlin.com; Nadav Haklai
> ; Stefan Chulski ; Yan
> Markman ; m...@semihalf.com
> Subject: [EXT] Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while
> reconfiguring
> On Fri, Feb 15, 2019 at 04:32:38PM +0100, Antoine Tenart wrote:
> > The documentation advises to set the XPCS in reset while reconfiguring
> > the serdes lanes. This seems to be a good thing to do, but the PPv2
> > driver wasn't doing it. This patch fixes it.
>
> Hmm. That statment seems to h
petazz...@bootlin.com;
> maxime.chevall...@bootlin.com; gregory.clem...@bootlin.com;
> miquel.ray...@bootlin.com; Nadav Haklai ; Stefan
> Chulski ; Yan Markman ;
> m...@semihalf.com; Baruch Siach
> Subject: Re: [PATCH net] net: mvpp2: 10G modes aren't supported on all
> ports
>
>
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, March 19, 2018 3:08 PM
> To: Stefan Chulski
> Cc: Antoine Tenart ; Russell King - ARM Linux
> ; da...@davemloft.net; kis...@ti.com;
> gregory.clem...@bootlin.com; ja...@lakedaemon.net;
hesselba...@gmail.com;
> netdev@vger.kernel.org; linux-ker...@vger.kernel.org;
> thomas.petazz...@bootlin.com; maxime.chevall...@bootlin.com;
> miquel.ray...@bootlin.com; Nadav Haklai ; Stefan
> Chulski ; Yan Markman ;
> m...@semihalf.com; linux-arm-ker...@lists.infradead.org
> Subjec
> > > There is no inband negotiation like there is with 802.3z or SGMII,
> > > so this makes no sense.
> >
> > Oh, that's what I feared. I read some docs but probably will need more
> > :)
> >
> > Anyway, the reason to use in-band negotiation was also to avoid using
> > fixed-link. It would work bu
> > To perform checksum in HW, HW obviously should work in store and
> forward mode. Store all frame in TX FIFO and then check checksum.
> > If mtu 1500B, everything fine and all port can do this.
> >
> > If mtu is 9KB and 9KB frame transmitted, Port 0 still can do HW checksum.
> But ports 1 and 2
> -Original Message-
> From: Thomas Petazzoni [mailto:thomas.petazz...@bootlin.com]
> Sent: Sunday, March 04, 2018 11:25 AM
> To: Stefan Chulski
> Cc: Antoine Tenart ; da...@davemloft.net;
> Yan Markman ; netdev@vger.kernel.org; linux-
> ker...@vger.kerne
> Hello,
>
> On Fri, 2 Mar 2018 16:40:40 +0100, Antoine Tenart wrote:
> > +static struct {
> > + int pkt_size;
> > + int buf_num;
> > +} mvpp2_pools[MVPP2_BM_POOLS_NUM];
>
> Any reason for not doing:
>
> } mvpp2_pools[MVPP2_BM_POOLS_NUM] = {
> [MVPP2_BM_SHORT] = {
> .pkt
> > netdev_err(port->dev, "Invalid pool %d\n", pool);
> > return NULL;
> > }
> > @@ -4596,11 +4604,24 @@ mvpp2_bm_pool_use(struct mvpp2_port
> *port, int
> > pool, int pkt_size) static int mvpp2_swf_bm_pool_init(struct
> > mvpp2_port *port) {
> > int rxq;
> > + e
> On Fri, 2 Mar 2018 16:40:42 +0100, Antoine Tenart wrote:
>
> > -/* Initialize Tx FIFO's */
> > +/* Initialize Tx FIFO's
> > + * The CP110's total tx-fifo size is 19kB.
> > + * Use large-size 10kB for fast port but 3kB for others.
> > + */
>
> Is there a reason to hardcode 10KB for port 0, and
> Sorry, I find this very confusing.
>
> It seems we have some people telling me that when there's no PHY described
> in DT, we use this link interrupt, and have a functional network interface
> (presumably at whatever speed.)
I give you couple of examples when we have functional network interfac
> > > -Original Message-
> > > Hi Russell,
> > >
> > > Indeed. RGMII MAC behaves same way, although it shouldn't be named
> > > as 'in- band' to be on par with the specifications. Anyway - this
> > > one is rather a stub for being able to work with ACPI, so once the
> > > MDIO bus works the
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Wednesday, January 03, 2018 5:53 PM
> To: Antoine Tenart
> Cc: da...@davemloft.net; kis...@ti.com; gregory.clement@free-
> electrons.com; li...@armlinux.org.uk; m...@semihalf.com; Stefan Chuls
..@armlinux.org.uk; m...@semihalf.com; Stefan Chulski
> ; Yan Markman ;
> thomas.petazz...@free-electrons.com; miquel.ray...@free-electrons.com;
> Nadav Haklai ; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [EXT] Re: [PATCH net-next v2 4/4] net: mvpp2: 2
> -Original Message-
> From: Marcin Wojtas [mailto:m...@semihalf.com]
> Sent: Monday, January 01, 2018 12:18 PM
> To: Russell King - ARM Linux
> Cc: Stefan Chulski ; Thomas Petazzoni
> ; Andrew Lunn ;
> Florian Fainelli ; Yan Markman
> ; Jason Cooper ; n
> -Original Message-
> From: Miquel RAYNAL [mailto:miquel.ray...@free-electrons.com]
> Sent: Tuesday, November 07, 2017 12:45 AM
> To: Stefan Chulski
> Cc: Thomas Petazzoni ; Antoine Tenart
> ; David S. Miller
> ; netdev@vger.kernel.org
> Subject: [EXT] Re:
> > .--- RJ45
> > MVPP2 - 88x3310 PHY
> > `--- SFP+
>
> And the "MVPP2" part can be expended to:
>
> .-- GoP #0 --.
> MVPP2 - GoP #1 Comphy lane #X -- 88x3310
> `-- GoP #2 --'
>
> Thanks!
> Antoine
One more point, Al
> So maybe one confusion was to name them PHY_MODE_10GKR and
> PHY_MODE_SGMII. It could be PHY_MODE_10G and PHY_MODE_1G instead.
1G can be RGMII...
Regards,
Stefan.
> > Imagine phylib is using the copper Ethernet PHY, but the MAC is using
> > the SFP port. Somebody pulls out the copper cable, phylib says the
> > link is down, turns the carrier off and calls the callback. Not good,
> > since your SFP cable is still plugged in... Ethtool is
> > returning/settin
thomas.petazz...@free-electrons.com; Nadav Haklai ;
> li...@armlinux.org.uk; linux-ker...@vger.kernel.org; m...@semihalf.com;
> Stefan Chulski ; miquel.ray...@free-electrons.com;
> netdev@vger.kernel.org
> Subject: Re: [PATCH net-next 02/13] phy: add the mvebu cp110 comphy driver
>
> When the cable is connected (there is signal) and the serdes is in sync and AN
> succeeded.
>
> > With SFF/SFP ports, you generally need a gpio line the fibre module
> > can use to indicate if it has link. Fixed-phy has such support, and
> > your link_change function will get called when the lin
> In order to safely read/write the PHY, you need to hold the PHY mutex.
> Unless the hardware is very smart, please don't enable this. Let the phylib
> and
> the appropriate PHY driver do the work.
>
>Andrew
Hi Andrew,
This feature work only for Out-of-Band Auto-Negotiation in SGMII Mo
e-
> electrons.com; Nadav Haklai ; li...@armlinux.org.uk;
> m...@semihalf.com; Stefan Chulski ;
> netdev@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: [EXT] Re: [PATCH net-next 03/18] net: mvpp2: set the SMI PHY address
> when connecti
93 matches
Mail list logo
