[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+h21hq1pVEJCZHzM4mCPEWhOL-_ugJ5h=EA4g=Lv5sweXGnAA@mail.gmail.com>
Date: Wed, 11 Mar 2020 11:50:17 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: David Miller <davem@...emloft.net>,
Networking <netdev@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Vladimir Oltean <vladimir.oltean@....com>
Subject: Re: linux-next: manual merge of the net-next tree with the net tree
Hi Stephen,
On Wed, 11 Mar 2020 at 03:34, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/mscc/ocelot.c
>
> between commit:
>
> a8015ded89ad ("net: mscc: ocelot: properly account for VLAN header length when setting MRU")
>
> from the net tree and commit:
>
> 69df578c5f4b ("net: mscc: ocelot: eliminate confusion between CPU and NPI port")
>
> from the net-next tree.
>
> I fixed it up (I think - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/mscc/ocelot.c
> index d3b7373c5961,06f9d013f807..000000000000
> --- a/drivers/net/ethernet/mscc/ocelot.c
> +++ b/drivers/net/ethernet/mscc/ocelot.c
> @@@ -2310,27 -2323,34 +2329,34 @@@ void ocelot_configure_cpu(struct ocelo
> ANA_PORT_PORT_CFG_PORTID_VAL(cpu),
> ANA_PORT_PORT_CFG, cpu);
>
> - /* If the CPU port is a physical port, set up the port in Node
> - * Processor Interface (NPI) mode. This is the mode through which
> - * frames can be injected from and extracted to an external CPU.
> - * Only one port can be an NPI at the same time.
> - */
> - if (cpu < ocelot->num_phys_ports) {
> + if (npi >= 0 && npi < ocelot->num_phys_ports) {
> - int mtu = VLAN_ETH_FRAME_LEN + OCELOT_TAG_LEN;
> + int sdu = ETH_DATA_LEN + OCELOT_TAG_LEN;
>
> ocelot_write(ocelot, QSYS_EXT_CPU_CFG_EXT_CPUQ_MSK_M |
> - QSYS_EXT_CPU_CFG_EXT_CPU_PORT(cpu),
> + QSYS_EXT_CPU_CFG_EXT_CPU_PORT(npi),
> QSYS_EXT_CPU_CFG);
>
> if (injection == OCELOT_TAG_PREFIX_SHORT)
> - mtu += OCELOT_SHORT_PREFIX_LEN;
> + sdu += OCELOT_SHORT_PREFIX_LEN;
> else if (injection == OCELOT_TAG_PREFIX_LONG)
> - mtu += OCELOT_LONG_PREFIX_LEN;
> + sdu += OCELOT_LONG_PREFIX_LEN;
>
> - ocelot_port_set_maxlen(ocelot, cpu, sdu);
> - ocelot_port_set_mtu(ocelot, npi, mtu);
> ++ ocelot_port_set_maxlen(ocelot, npi, sdu);
> +
> + /* Enable NPI port */
> + ocelot_write_rix(ocelot,
> + QSYS_SWITCH_PORT_MODE_INGRESS_DROP_MODE |
> + QSYS_SWITCH_PORT_MODE_SCH_NEXT_CFG(1) |
> + QSYS_SWITCH_PORT_MODE_PORT_ENA,
> + QSYS_SWITCH_PORT_MODE, npi);
> + /* NPI port Injection/Extraction configuration */
> + ocelot_write_rix(ocelot,
> + SYS_PORT_MODE_INCL_XTR_HDR(extraction) |
> + SYS_PORT_MODE_INCL_INJ_HDR(injection),
> + SYS_PORT_MODE, npi);
> }
>
> - /* CPU port Injection/Extraction configuration */
> + /* Enable CPU port module */
> ocelot_write_rix(ocelot, QSYS_SWITCH_PORT_MODE_INGRESS_DROP_MODE |
> QSYS_SWITCH_PORT_MODE_SCH_NEXT_CFG(1) |
> QSYS_SWITCH_PORT_MODE_PORT_ENA,
What would be the takeaway here? I did bring the fact that it will
conflict to David's attention here, not sure what else should have
been done:
https://www.spinics.net/lists/netdev/msg636207.html
The conflict resolution looks fine btw, I've tested linux-next and it
also works.
Thanks,
-Vladimir
Powered by blists - more mailing lists