> -Original Message-
> From: Marcin Wojtas
> Sent: Tuesday, April 13, 2021 12:59 PM
> To: Stefan Chulski
> Cc: Russell King - ARM Linux admin ;
> net...@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: net...@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: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linux-kernel@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
> > 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)
> 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.
> >
> > Ar
> -Original Message-
> From: Andrew Lunn
> Sent: Wednesday, March 10, 2021 5:51 PM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linux-kernel@vger.kernel.org;
> > > 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
> > +/* 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;
> > +
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Thursday, February 11, 2021 2:50 PM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linux-kernel
> --
> 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.
> 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 &&
>
> --
> 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
> > 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
> > }
> >
> > +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(>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
>
> 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=DwICAg=nKjWec2b6R0mOyPaz7xtfQ=DDQ3dKwkTIx
> >
>
>
> 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=DwICAg=nKjWec2b6R0mOyPaz7xtfQ=DDQ3dKwkTIx
>
>
> > 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
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Wednesday, January 27, 2021 5:00 PM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linux-kernel
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Wednesday, January 27, 2021 4:06 PM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan
> Markman ; linux-kernel@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
> > 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
> > #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
>
> --
> 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
> > 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,
>
>
> --
> 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
> > 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.
> > Extend
>
> 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
> 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 &&
> >
> > +/* 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() >=
> > > > + } else {
> > > > + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > > > + if (!priv->sram_pool) {
> > > > + dev_warn(>dev, "DT is too old, TX FC
> > > disabled\n");
> > >
> > > I don't see anything in this patch that
> > + } else {
> > + priv->sram_pool = of_gen_pool_get(dn, "cm3-mem", 0);
> > + if (!priv->sram_pool) {
> > + dev_warn(>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 &&
>
> > > 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:
>
> +
> 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: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@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 with i
> 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
> >
> 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'
> > fie
> 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: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@vger.kernel.org;
>
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Monday, November 23, 2020 7:30 PM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@vger.kernel
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Monday, November 23, 2020 5:52 PM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@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: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@vger.kernel.org;
> -Original Message-
> From: stef...@marvell.com
> Sent: Wednesday, November 18, 2020 8:21 PM
> To: net...@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
> Hi all,
>
> probably dev->vlan_features is safe to keep the CSUM features to avoid
> unnecessary calculation in some cases, but I have another question.
> Does the PP2 hardware support checksumming within any offset? I replaced
> 'NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM' with NETIF_F_HW_CSUM and
>
> -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;
> net...@vger.kernel.org; linux-kernel@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
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
>
> On T
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, March 19, 2018 3:08 PM
> To: Stefan Chulski <stef...@marvell.com>
> Cc: Antoine Tenart <antoine.ten...@bootlin.com>; Russell King - ARM Linux
> <li...@armlinux.org.uk>
> -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;
gory.clem...@bootlin.com;
> ja...@lakedaemon.net; sebastian.hesselba...@gmail.com;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> thomas.petazz...@bootlin.com; maxime.chevall...@bootlin.com;
> miquel.ray...@bootlin.com; Nadav Haklai <nad...@marvell.com>; Stefan
>
a...@gmail.com;
> net...@vger.kernel.org; linux-kernel@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
> > > 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
> > 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
> > 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 <stef...@marvell.com>
> Cc: Antoine Tenart <antoine.ten...@bootlin.com>; da...@davemloft.net;
> Yan Markm
> -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 ; net...@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] = {
>
> 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] = {
>
> > 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;
> > +
> > 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;
> > +
> 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,
> 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,
> 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
> 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
> > > -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
> > > -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
rg.uk; m...@semihalf.com; Stefan Chulski
> <stef...@marvell.com>; Yan Markman <ymark...@marvell.com>;
> thomas.petazz...@free-electrons.com; miquel.ray...@free-electrons.com;
> Nadav Haklai <nad...@marvell.com>; net...@vger.kernel.org; linux-
> ker...@vger.kernel
> -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
.@ti.com; gregory.clem...@free-electrons.com;
> li...@armlinux.org.uk; m...@semihalf.com; Stefan Chulski
> <stef...@marvell.com>; Yan Markman <ymark...@marvell.com>;
> thomas.petazz...@free-electrons.com; miquel.ray...@free-electrons.com;
> Nadav Haklai <nad...@marvell.com&
..@armlinux.org.uk; m...@semihalf.com; Stefan Chulski
> ; Yan Markman ;
> thomas.petazz...@free-electrons.com; miquel.ray...@free-electrons.com;
> Nadav Haklai ; net...@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 <li...@armlinux.org.uk>
> Cc: Stefan Chulski <stef...@marvell.com>; Thomas Petazzoni
> <thomas.petazz...
> -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
> > .--- 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,
> > .--- 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,
> 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.
> 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
> >
> > 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
> >
1 - 100 of 102 matches
Mail list logo
