Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.

[Andrew Lunn]

> >>+static char *mix_port;
> >>+module_param(mix_port, charp, 0444);
> >>+MODULE_PARM_DESC(mix_port, "Specifies which ports connect to MIX 
> >>interfaces.");
> >
> >Can you derive this from Device Tree /platform data configuration?
> >
> >>+
> >>+static char *pki_port;
> >>+module_param(pki_port, charp, 0444);
> >>+MODULE_PARM_DESC(pki_port, "Specifies which ports connect to the PKI.");
> >
> >Likewise
> 
> The SoC is flexible in how it is configured.  Technically the device tree
> should only be used to specify information about the physical configuration
> of the system that cannot be probed for, and this is about policy rather
> that physical wiring.  That said, we do take the default configuration from
> the device tree, but give the option here to override via the module command
> line.

Module parameters are pretty much frowned upon. 

You should really try to remove them all, if possible.

> >>+/* Registers are accessed via xkphys */
> >>+#define SSO_BASE   0x16700ull
> >>+#define SSO_ADDR(node) (SET_XKPHYS + NODE_OFFSET(node) 
> >>+  \
> >>+SSO_BASE)
> >>+#define GRP_OFFSET(grp)((grp) << 16)
> >>+#define GRP_ADDR(n, g) (SSO_ADDR(n) + GRP_OFFSET(g))
> >>+#define SSO_GRP_AQ_CNT(n, g)   (GRP_ADDR(n, g)+ 
> >>0x2700)
> >>+
> >>+#define MIO_PTP_BASE   0x10700ull
> >>+#define MIO_PTP_ADDR(node) (SET_XKPHYS + NODE_OFFSET(node) +  \
> >>+MIO_PTP_BASE)
> >>+#define MIO_PTP_CLOCK_CFG(node)(MIO_PTP_ADDR(node) 
> >>+ 0xf00)
> >>+#define MIO_PTP_CLOCK_HI(node) (MIO_PTP_ADDR(node) 
> >>+ 0xf10)
> >>+#define MIO_PTP_CLOCK_COMP(node)   (MIO_PTP_ADDR(node) + 0xf18)
> >
> >I am sure this will work great on anything but MIPS64 ;)
> 
> Sarcasm duly noted.
> 
> That said, by definition it is exactly an OCTEON-III/MIPS64, and can never
> be anything else.  It is known a priori that the hardware and this driver
> will never be used anywhere else.

Please make sure your Kconfig really enforces this. Generally, we
suggest allowing the driver to be compiled when COMPILE_TEST is set.
That gives you better compiler test coverage. But it seems like this
driver won't compile under such conditions.

> >>+static int num_packet_buffers = 768;
> >>+module_param(num_packet_buffers, int, 0444);
> >>+MODULE_PARM_DESC(num_packet_buffers,
> >>+"Number of packet buffers to allocate per port.");
> >
> >Consider implementing ethtool -g/G for this.
> 
> That may be work for a follow-on patch.

Then please remove the module parameter now.

> >>+static int rx_queues = 1;
> >>+module_param(rx_queues, int, 0444);
> >>+MODULE_PARM_DESC(rx_queues, "Number of RX threads per port.");
> >
> >Same thing, can you consider using an ethtool knob for that?
> 
> Also may be work for a follow-on patch.

Ditto

> >>+/**
> >>+ * Reads a 64 bit value from the processor local scratchpad memory.
> >>+ *
> >>+ * @param offset byte offset into scratch pad to read
> >>+ *
> >>+ * @return value read
> >>+ */
> >>+static inline u64 scratch_read64(u64 offset)
> >>+{
> >>+   return *(u64 *)((long)SCRATCH_BASE + offset);
> >>+}
> >
> >No barriers needed whatsoever?
> 
> Nope.

Then it would be good to add a comment about why no barrier is
needed. Otherwise people are going to ask why there is no barrier,
submit patches adding barriers, etc.

   Andrew

Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.

[David Daney]

On 11/02/2017 12:13 PM, Florian Fainelli wrote:

On 11/01/2017 05:36 PM, David Daney wrote:

From: Carlos Munoz 

The Cavium OCTEON cn78xx and cn73xx SoCs have network packet I/O
hardware that is significantly different from previous generations of
the family.

Add a new driver for this hardware.  The Ethernet MAC is called BGX on
these devices.  Common code for the MAC is in octeon3-bgx-port.c.
Four of these BGX MACs are grouped together and managed as a group by
octeon3-bgx-nexus.c.  Ingress packet classification is done by the PKI
unit initialized in octeon3-pki.c.  Queue management is done in the
SSO, initialized by octeon3-sso.c.  Egress is handled by the PKO,
initialized in octeon3-pko.c.

Signed-off-by: Carlos Munoz 
Signed-off-by: Steven J. Hill 
Signed-off-by: David Daney 
---



+static char *mix_port;
+module_param(mix_port, charp, 0444);
+MODULE_PARM_DESC(mix_port, "Specifies which ports connect to MIX interfaces.");


Can you derive this from Device Tree /platform data configuration?


+
+static char *pki_port;
+module_param(pki_port, charp, 0444);
+MODULE_PARM_DESC(pki_port, "Specifies which ports connect to the PKI.");


Likewise


The SoC is flexible in how it is configured.  Technically the device 
tree should only be used to specify information about the physical 
configuration of the system that cannot be probed for, and this is about 
policy rather that physical wiring.  That said, we do take the default 
configuration from the device tree, but give the option here to override 
via the module command line.





+
+#define MAX_MIX_PER_NODE   2
+
+#define MAX_MIX(MAX_NODES * MAX_MIX_PER_NODE)
+
+/**
+ * struct mix_port_lmac - Describes a lmac that connects to a mix
+ *   port. The lmac must be on the same node as
+ *   the mix.
+ * @node:  Node of the lmac.
+ * @bgx:   Bgx of the lmac.
+ * @lmac:  Lmac index.
+ */
+struct mix_port_lmac {
+   int node;
+   int bgx;
+   int lmac;
+};
+
+/* mix_ports_lmacs contains all the lmacs connected to mix ports */
+static struct mix_port_lmac mix_port_lmacs[MAX_MIX];
+
+/* pki_ports keeps track of the lmacs connected to the pki */
+static bool pki_ports[MAX_NODES][MAX_BGX_PER_NODE][MAX_LMAC_PER_BGX];
+
+/* Created platform devices get added to this list */
+static struct list_head pdev_list;
+static struct mutex pdev_list_lock;
+
+/* Created platform device use this structure to add themselves to the list */
+struct pdev_list_item {
+   struct list_headlist;
+   struct platform_device  *pdev;
+};


Don't you have a top-level platform device that you could use which
would hold this data instead of having it here?


This is the top-level platform device.




[snip]


+/* Registers are accessed via xkphys */
+#define SSO_BASE   0x16700ull
+#define SSO_ADDR(node) (SET_XKPHYS + NODE_OFFSET(node) +  \
+SSO_BASE)
+#define GRP_OFFSET(grp)((grp) << 16)
+#define GRP_ADDR(n, g) (SSO_ADDR(n) + GRP_OFFSET(g))
+#define SSO_GRP_AQ_CNT(n, g)   (GRP_ADDR(n, g)+ 0x2700)
+
+#define MIO_PTP_BASE   0x10700ull
+#define MIO_PTP_ADDR(node) (SET_XKPHYS + NODE_OFFSET(node) +  \
+MIO_PTP_BASE)
+#define MIO_PTP_CLOCK_CFG(node)(MIO_PTP_ADDR(node) 
+ 0xf00)
+#define MIO_PTP_CLOCK_HI(node) (MIO_PTP_ADDR(node) + 0xf10)
+#define MIO_PTP_CLOCK_COMP(node)   (MIO_PTP_ADDR(node) + 0xf18)


I am sure this will work great on anything but MIPS64 ;)


Sarcasm duly noted.

That said, by definition it is exactly an OCTEON-III/MIPS64, and can 
never be anything else.  It is known a priori that the hardware and this 
driver will never be used anywhere else.





+
+struct octeon3_ethernet;
+
+struct octeon3_rx {
+   struct napi_struct  napi;
+   struct octeon3_ethernet *parent;
+   int rx_grp;
+   int rx_irq;
+   cpumask_t rx_affinity_hint;
+} cacheline_aligned_in_smp;
+
+struct octeon3_ethernet {
+   struct bgx_port_netdev_priv bgx_priv; /* Must be first element. */
+   struct list_head list;
+   struct net_device *netdev;
+   enum octeon3_mac_type mac_type;
+   struct octeon3_rx rx_cxt[MAX_RX_QUEUES];
+   struct ptp_clock_info ptp_info;
+   struct ptp_clock *ptp_clock;
+   struct cyclecounter cc;
+   struct timecounter tc;
+   spinlock_t ptp_lock;/* Serialize ptp clock adjustments */
+   int num_rx_cxt;
+   int pki_aura;
+   int pknd;
+   int pko_queue;
+   int node;
+   int interface;
+   int index;
+   int rx_buf_count;
+   int tx_complete_grp;
+   int rx_timestamp_hw:1;
+   

Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.

[Florian Fainelli]

On 11/01/2017 05:36 PM, David Daney wrote:
> From: Carlos Munoz 
> 
> The Cavium OCTEON cn78xx and cn73xx SoCs have network packet I/O
> hardware that is significantly different from previous generations of
> the family.
> 
> Add a new driver for this hardware.  The Ethernet MAC is called BGX on
> these devices.  Common code for the MAC is in octeon3-bgx-port.c.
> Four of these BGX MACs are grouped together and managed as a group by
> octeon3-bgx-nexus.c.  Ingress packet classification is done by the PKI
> unit initialized in octeon3-pki.c.  Queue management is done in the
> SSO, initialized by octeon3-sso.c.  Egress is handled by the PKO,
> initialized in octeon3-pko.c.
> 
> Signed-off-by: Carlos Munoz 
> Signed-off-by: Steven J. Hill 
> Signed-off-by: David Daney 
> ---

> +static char *mix_port;
> +module_param(mix_port, charp, 0444);
> +MODULE_PARM_DESC(mix_port, "Specifies which ports connect to MIX 
> interfaces.");

Can you derive this from Device Tree /platform data configuration?

> +
> +static char *pki_port;
> +module_param(pki_port, charp, 0444);
> +MODULE_PARM_DESC(pki_port, "Specifies which ports connect to the PKI.");

Likewise

> +
> +#define MAX_MIX_PER_NODE 2
> +
> +#define MAX_MIX  (MAX_NODES * MAX_MIX_PER_NODE)
> +
> +/**
> + * struct mix_port_lmac - Describes a lmac that connects to a mix
> + * port. The lmac must be on the same node as
> + * the mix.
> + * @node:Node of the lmac.
> + * @bgx: Bgx of the lmac.
> + * @lmac:Lmac index.
> + */
> +struct mix_port_lmac {
> + int node;
> + int bgx;
> + int lmac;
> +};
> +
> +/* mix_ports_lmacs contains all the lmacs connected to mix ports */
> +static struct mix_port_lmac mix_port_lmacs[MAX_MIX];
> +
> +/* pki_ports keeps track of the lmacs connected to the pki */
> +static bool pki_ports[MAX_NODES][MAX_BGX_PER_NODE][MAX_LMAC_PER_BGX];
> +
> +/* Created platform devices get added to this list */
> +static struct list_head pdev_list;
> +static struct mutex pdev_list_lock;
> +
> +/* Created platform device use this structure to add themselves to the list 
> */
> +struct pdev_list_item {
> + struct list_headlist;
> + struct platform_device  *pdev;
> +};

Don't you have a top-level platform device that you could use which
would hold this data instead of having it here?

[snip]

> +/* Registers are accessed via xkphys */
> +#define SSO_BASE 0x16700ull
> +#define SSO_ADDR(node)   (SET_XKPHYS + NODE_OFFSET(node) 
> +  \
> +  SSO_BASE)
> +#define GRP_OFFSET(grp)  ((grp) << 16)
> +#define GRP_ADDR(n, g)   (SSO_ADDR(n) + GRP_OFFSET(g))
> +#define SSO_GRP_AQ_CNT(n, g) (GRP_ADDR(n, g)+ 0x2700)
> +
> +#define MIO_PTP_BASE 0x10700ull
> +#define MIO_PTP_ADDR(node)   (SET_XKPHYS + NODE_OFFSET(node) +  \
> +  MIO_PTP_BASE)
> +#define MIO_PTP_CLOCK_CFG(node)  (MIO_PTP_ADDR(node) 
> + 0xf00)
> +#define MIO_PTP_CLOCK_HI(node)   (MIO_PTP_ADDR(node) 
> + 0xf10)
> +#define MIO_PTP_CLOCK_COMP(node) (MIO_PTP_ADDR(node) + 0xf18)

I am sure this will work great on anything but MIPS64 ;)

> +
> +struct octeon3_ethernet;
> +
> +struct octeon3_rx {
> + struct napi_struct  napi;
> + struct octeon3_ethernet *parent;
> + int rx_grp;
> + int rx_irq;
> + cpumask_t rx_affinity_hint;
> +} cacheline_aligned_in_smp;
> +
> +struct octeon3_ethernet {
> + struct bgx_port_netdev_priv bgx_priv; /* Must be first element. */
> + struct list_head list;
> + struct net_device *netdev;
> + enum octeon3_mac_type mac_type;
> + struct octeon3_rx rx_cxt[MAX_RX_QUEUES];
> + struct ptp_clock_info ptp_info;
> + struct ptp_clock *ptp_clock;
> + struct cyclecounter cc;
> + struct timecounter tc;
> + spinlock_t ptp_lock;/* Serialize ptp clock adjustments */
> + int num_rx_cxt;
> + int pki_aura;
> + int pknd;
> + int pko_queue;
> + int node;
> + int interface;
> + int index;
> + int rx_buf_count;
> + int tx_complete_grp;
> + int rx_timestamp_hw:1;
> + int tx_timestamp_hw:1;
> + spinlock_t stat_lock;   /* Protects stats counters */
> + u64 last_packets;
> + u64 last_octets;
> + u64 last_dropped;
> + atomic64_t rx_packets;
> + atomic64_t rx_octets;
> + atomic64_t rx_dropped;
> + atomic64_t rx_errors;
> + atomic64_t rx_length_errors;
> + atomic64_t rx_crc_errors;
> + atomic64_t tx_packets;
> + atomic64_t tx_octets;
> + atomic64_t tx_dropped;

Do you really need those to be truly atomic64_t types, can't you use u64
and use the helpers from 

Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.

[Florian Fainelli]

On 11/02/2017 11:31 AM, David Daney wrote:
> On 11/02/2017 09:56 AM, Andrew Lunn wrote:
>>> OK, now I think I understand.  Yes, the MAC can be hardwired to a
>>> switch.
>>> In fact, there are system designs that do exactly that.
>>>
>>> We try to handle this case by not having a "phy-handle" property in the
>>> device tree.  The link to the remote device (switch IC in this case) is
>>> brought up on ndo_open()
>>
>> O.K, so you totally ignore the Linux way of doing this and hack
>> together your own proprietary solution.
> 
> I am going to add handling of the "phy-mode" property, but other than
> that I don't know what the "Linux way" of specifying a hard MAC-to-MAC
> connection with no intervening phy devices is.  Wether the remote MAC is
> a switch, or something else, would seem to be irrelevant.  All we are
> concerned about in this code is putting the thing into a state where
> data flows in both directions through the MAC.

The canonical way to support that type of connections is to use use a
fixed-link property describing the link between the two MACs, ideally
putting the same fixed-link property on both sides.

> 
> A pointer to an existing device tree binding for an Ethernet device that
> has no (or an optional) phy device would be useful, we can try to do the
> same.
> 
> 
>>  
>>> There may be opportunities to improve how this works in the future,
>>> but the
>>> current code is serviceable.
>>
>> It might be serviceable, but it will never get into mainline. For
>> mainline, you need to use DSA.
>>
>> http://elixir.free-electrons.com/linux/v4.9.60/source/Documentation/networking/dsa/dsa.txt
>>
> 
> 
> I am truly at a loss here.  That DSA document states:
> 
>  Master network devices are regular, unmodified Linux
>  network device drivers for the CPU/management Ethernet
>  interface.
> 
> What modification do you suggest I make?

If you support normal phy_device and fixed-link devices, you should be
good as far as using PHYLIB and interfacing with Ethernet switchses
using DSA for instance. What Andrew is asking you though is to make sure
that the platform device dance between the bgx drivers and the other
modules preserves the Device Tree parenting, of_node pointers such that
a DSA switch, which needs to reference a CPU/management port, has a
chance to successfully look up that node via of_find_net_device_by_node().

> 
> 
>>
>> Getting back to my original point, having these platform devices can
>> cause issues for DSA. Freescale FMAN has a similar architecture, and
>> it took a while to restructure it to make DSA work.
>>
>> https://www.spinics.net/lists/netdev/msg459394.html
>>
>> Andrew
>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Florian

Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.

[David Daney]

On 11/02/2017 09:56 AM, Andrew Lunn wrote:

OK, now I think I understand.  Yes, the MAC can be hardwired to a switch.
In fact, there are system designs that do exactly that.

We try to handle this case by not having a "phy-handle" property in the
device tree.  The link to the remote device (switch IC in this case) is
brought up on ndo_open()


O.K, so you totally ignore the Linux way of doing this and hack
together your own proprietary solution.


I am going to add handling of the "phy-mode" property, but other than 
that I don't know what the "Linux way" of specifying a hard MAC-to-MAC 
connection with no intervening phy devices is.  Wether the remote MAC is 
a switch, or something else, would seem to be irrelevant.  All we are 
concerned about in this code is putting the thing into a state where 
data flows in both directions through the MAC.


A pointer to an existing device tree binding for an Ethernet device that 
has no (or an optional) phy device would be useful, we can try to do the 
same.



  

There may be opportunities to improve how this works in the future, but the
current code is serviceable.


It might be serviceable, but it will never get into mainline. For
mainline, you need to use DSA.

http://elixir.free-electrons.com/linux/v4.9.60/source/Documentation/networking/dsa/dsa.txt



I am truly at a loss here.  That DSA document states:

 Master network devices are regular, unmodified Linux
 network device drivers for the CPU/management Ethernet
 interface.

What modification do you suggest I make?




Getting back to my original point, having these platform devices can
cause issues for DSA. Freescale FMAN has a similar architecture, and
it took a while to restructure it to make DSA work.

https://www.spinics.net/lists/netdev/msg459394.html

Andrew

Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.

[Andrew Lunn]

> OK, now I think I understand.  Yes, the MAC can be hardwired to a switch.
> In fact, there are system designs that do exactly that.
> 
> We try to handle this case by not having a "phy-handle" property in the
> device tree.  The link to the remote device (switch IC in this case) is
> brought up on ndo_open()

O.K, so you totally ignore the Linux way of doing this and hack
together your own proprietary solution.
 
> There may be opportunities to improve how this works in the future, but the
> current code is serviceable.

It might be serviceable, but it will never get into mainline. For
mainline, you need to use DSA.

http://elixir.free-electrons.com/linux/v4.9.60/source/Documentation/networking/dsa/dsa.txt

Getting back to my original point, having these platform devices can
cause issues for DSA. Freescale FMAN has a similar architecture, and
it took a while to restructure it to make DSA work.

https://www.spinics.net/lists/netdev/msg459394.html

Andrew

Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.

[David Daney]

On 11/02/2017 09:10 AM, Andrew Lunn wrote:

On Thu, Nov 02, 2017 at 08:55:33AM -0700, David Daney wrote:

On 11/02/2017 05:43 AM, Andrew Lunn wrote:
[...]

+
+   i = atomic_inc_return(_id);
+   pki_dev = platform_device_register_data(_dev->dev,
+   is_mix ? "octeon_mgmt" : 
"ethernet-mac-pki",
+   i, _data, 
sizeof(platform_data));
+   dev_info(>dev, "Created %s %u: %p\n",
+is_mix ? "MIX" : "PKI", pki_dev->id, pki_dev);


Is there any change of these ethernet ports being used to connect to
an Ethernet switch. We have had issues in the past with these sort of
platform devices combined with DSA.



There are only two possibilities.  The BGX MACs have a multiplexer that
allows them to be connected to either the "octeon_mgmt" MIX packet
processor, or to the "ethernet-mac-pki" PKI/PKO packet processor.  The SoCs
supported by these drivers do not contain any hardware that would be
considered an "Ethernet switch".


Hi David

I was thinking of an external Ethernet switch. You generally connect
via RGMII to a port of the switch.



OK, now I think I understand.  Yes, the MAC can be hardwired to a 
switch.  In fact, there are system designs that do exactly that.


We try to handle this case by not having a "phy-handle" property in the 
device tree.  The link to the remote device (switch IC in this case) is 
brought up on ndo_open()


There may be opportunities to improve how this works in the future, but 
the current code is serviceable.



http://elixir.free-electrons.com/linux/v4.9.60/source/Documentation/networking/dsa/dsa.txt

Andrew

Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.

[Andrew Lunn]

On Thu, Nov 02, 2017 at 08:55:33AM -0700, David Daney wrote:
> On 11/02/2017 05:43 AM, Andrew Lunn wrote:
> [...]
> >>+
> >>+   i = atomic_inc_return(_id);
> >>+   pki_dev = platform_device_register_data(_dev->dev,
> >>+   is_mix ? "octeon_mgmt" 
> >>: "ethernet-mac-pki",
> >>+   i, _data, 
> >>sizeof(platform_data));
> >>+   dev_info(>dev, "Created %s %u: %p\n",
> >>+is_mix ? "MIX" : "PKI", pki_dev->id, pki_dev);
> >
> >Is there any change of these ethernet ports being used to connect to
> >an Ethernet switch. We have had issues in the past with these sort of
> >platform devices combined with DSA.
> >
> 
> There are only two possibilities.  The BGX MACs have a multiplexer that
> allows them to be connected to either the "octeon_mgmt" MIX packet
> processor, or to the "ethernet-mac-pki" PKI/PKO packet processor.  The SoCs
> supported by these drivers do not contain any hardware that would be
> considered an "Ethernet switch".

Hi David

I was thinking of an external Ethernet switch. You generally connect
via RGMII to a port of the switch.

http://elixir.free-electrons.com/linux/v4.9.60/source/Documentation/networking/dsa/dsa.txt

Andrew

Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.

[David Daney]

On 11/02/2017 05:43 AM, Andrew Lunn wrote:
[...]

+
+   i = atomic_inc_return(_id);
+   pki_dev = platform_device_register_data(_dev->dev,
+   is_mix ? "octeon_mgmt" : 
"ethernet-mac-pki",
+   i, _data, 
sizeof(platform_data));
+   dev_info(>dev, "Created %s %u: %p\n",
+is_mix ? "MIX" : "PKI", pki_dev->id, pki_dev);


Is there any change of these ethernet ports being used to connect to
an Ethernet switch. We have had issues in the past with these sort of
platform devices combined with DSA.



There are only two possibilities.  The BGX MACs have a multiplexer that 
allows them to be connected to either the "octeon_mgmt" MIX packet 
processor, or to the "ethernet-mac-pki" PKI/PKO packet processor.  The 
SoCs supported by these drivers do not contain any hardware that would 
be considered an "Ethernet switch".


I'm not sure I fully understand what your question is though, so I may 
not have answered it.


David Daney

Re: [PATCH 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.

[Andrew Lunn]

> +static int bgx_probe(struct platform_device *pdev)
> +{
> + struct mac_platform_data platform_data;
> + const __be32 *reg;
> + u32 port;
> + u64 addr;
> + struct device_node *child;
> + struct platform_device *new_dev;
> + struct platform_device *pki_dev;
> + int numa_node, interface;
> + int i;
> + int r = 0;
> + char id[64];
> + u64 data;
> +
> + reg = of_get_property(pdev->dev.of_node, "reg", NULL);
> + addr = of_translate_address(pdev->dev.of_node, reg);
> + interface = (addr >> 24) & 0xf;
> + numa_node = (addr >> 36) & 0x7;
> +
> + /* Assign 8 CAM entries per LMAC */
> + for (i = 0; i < 32; i++) {
> + data = i >> 3;
> + oct_csr_write(data, BGX_CMR_RX_ADRX_CAM(numa_node, interface, 
> i));
> + }
> +
> + for_each_available_child_of_node(pdev->dev.of_node, child) {
> + snprintf(id, sizeof(id), "%llx.%u.ethernet-mac",
> +  (unsigned long long)addr, port);
> + new_dev = of_platform_device_create(child, id, >dev);
> + if (!new_dev) {
> + dev_err(>dev, "Error creating %s\n", id);
> + continue;
> + }
> + platform_data.mac_type = BGX_MAC;
> + platform_data.numa_node = numa_node;
> + platform_data.interface = interface;
> + platform_data.port = port;
> + if (is_xcv)
> + platform_data.src_type = XCV;
> + else
> + platform_data.src_type = QLM;
> +
> + /* Add device to the list of created devices so we can remove it
> +  * on exit.
> +  */
> + pdev_item = kmalloc(sizeof(*pdev_item), GFP_KERNEL);
> + pdev_item->pdev = new_dev;
> + mutex_lock(_list_lock);
> + list_add(_item->list, _list);
> + mutex_unlock(_list_lock);
> +
> + i = atomic_inc_return(_id);
> + pki_dev = platform_device_register_data(_dev->dev,
> + is_mix ? "octeon_mgmt" 
> : "ethernet-mac-pki",
> + i, _data, 
> sizeof(platform_data));
> + dev_info(>dev, "Created %s %u: %p\n",
> +  is_mix ? "MIX" : "PKI", pki_dev->id, pki_dev);

Is there any change of these ethernet ports being used to connect to
an Ethernet switch. We have had issues in the past with these sort of
platform devices combined with DSA.

 Andrew