On Thu, 1 Jun 2023 15:12:28 -0700 Justin Chen wrote:
> + ports_node = of_find_node_by_name(dev->of_node, "ethernet-ports");
> + if (!ports_node) {
> + dev_warn(dev, "No ports found\n");
> + return 0;
> + }
> +
> + for_each_available_child_of_node(ports_node, intf_node) {
> + of_property_read_u32(intf_node, "reg", &port);
> + if (!bcmasp_is_port_valid(priv, port)) {
> + dev_warn(dev, "%pOF: %d is an invalid port\n",
> + intf_node, port);
> + continue;
> + }
> +
> + priv->intf_count++;
> + }
I think that you're leaking ports_node,
/**
* of_find_node_by_name - Find a node by its "name" property
* @from: The node to start searching from or NULL; the node
* you pass will not be searched, only the next one
* will. Typically, you pass what the previous call
* returned. of_node_put() will be called on @from.
* @name: The name string to match against
*
* Return: A node pointer with refcount incremented, use
* of_node_put() on it when done.
*/
--
pw-bot: cr
On Thu, 1 Jun 2023 15:12:28 -0700 Justin Chen wrote:
> + /* general stats */
> + STAT_NETDEV(rx_packets),
> + STAT_NETDEV(tx_packets),
> + STAT_NETDEV(rx_bytes),
> + STAT_NETDEV(tx_bytes),
> + STAT_NETDEV(rx_errors),
> + STAT_NETDEV(tx_errors),
> + STAT_NETDEV(rx_dropped),
> + STAT_NETDEV(tx_dropped),
> + STAT_NETDEV(multicast),
please don't report standard interface stats in ethtool -S
> + /* UniMAC RSV counters */
> + STAT_BCMASP_MIB_RX("rx_64_octets", mib.rx.pkt_cnt.cnt_64),
> + STAT_BCMASP_MIB_RX("rx_65_127_oct", mib.rx.pkt_cnt.cnt_127),
> + STAT_BCMASP_MIB_RX("rx_128_255_oct", mib.rx.pkt_cnt.cnt_255),
> + STAT_BCMASP_MIB_RX("rx_256_511_oct", mib.rx.pkt_cnt.cnt_511),
> + STAT_BCMASP_MIB_RX("rx_512_1023_oct", mib.rx.pkt_cnt.cnt_1023),
> + STAT_BCMASP_MIB_RX("rx_1024_1518_oct", mib.rx.pkt_cnt.cnt_1518),
> + STAT_BCMASP_MIB_RX("rx_vlan_1519_1522_oct", mib.rx.pkt_cnt.cnt_mgv),
> + STAT_BCMASP_MIB_RX("rx_1522_2047_oct", mib.rx.pkt_cnt.cnt_2047),
> + STAT_BCMASP_MIB_RX("rx_2048_4095_oct", mib.rx.pkt_cnt.cnt_4095),
> + STAT_BCMASP_MIB_RX("rx_4096_9216_oct", mib.rx.pkt_cnt.cnt_9216),
these should also be removed, and you should implement @get_rmon_stats.
> + STAT_BCMASP_MIB_RX("rx_pkts", mib.rx.pkt),
> + STAT_BCMASP_MIB_RX("rx_bytes", mib.rx.bytes),
> + STAT_BCMASP_MIB_RX("rx_multicast", mib.rx.mca),
> + STAT_BCMASP_MIB_RX("rx_broadcast", mib.rx.bca),
> + STAT_BCMASP_MIB_RX("rx_fcs", mib.rx.fcs),
there's a FCS error statistic in the standard stats, no need to
duplicate
> + STAT_BCMASP_MIB_RX("rx_control", mib.rx.cf),
> + STAT_BCMASP_MIB_RX("rx_pause", mib.rx.pf),
@get_pause_stats
> + STAT_BCMASP_MIB_RX("rx_unknown", mib.rx.uo),
> + STAT_BCMASP_MIB_RX("rx_align", mib.rx.aln),
> + STAT_BCMASP_MIB_RX("rx_outrange", mib.rx.flr),
> + STAT_BCMASP_MIB_RX("rx_code", mib.rx.cde),
> + STAT_BCMASP_MIB_RX("rx_carrier", mib.rx.fcr),
> + STAT_BCMASP_MIB_RX("rx_oversize", mib.rx.ovr),
> + STAT_BCMASP_MIB_RX("rx_jabber", mib.rx.jbr),
these look like candidates from standard stats, too.
Please read thru:
https://docs.kernel.org/next/networking/statistics.html
> + STAT_BCMASP_MIB_RX("rx_mtu_err", mib.rx.mtue),
> + STAT_BCMASP_MIB_RX("rx_good_pkts", mib.rx.pok),
> + STAT_BCMASP_MIB_RX("rx_unicast", mib.rx.uc),
> + STAT_BCMASP_MIB_RX("rx_ppp", mib.rx.ppp),
> + STAT_BCMASP_MIB_RX("rx_crc", mib.rx.rcrc),
hm, what's the difference between rx_crc and rx_fcs ?
On 6/2/2023 11:58 PM, Jakub Kicinski wrote:
> On Thu, 1 Jun 2023 15:12:28 -0700 Justin Chen wrote:
>> + /* general stats */
>> + STAT_NETDEV(rx_packets),
>> + STAT_NETDEV(tx_packets),
>> + STAT_NETDEV(rx_bytes),
>> + STAT_NETDEV(tx_bytes),
>> + STAT_NETDEV(rx_errors),
>> + STAT_NETDEV(tx_errors),
>> + STAT_NETDEV(rx_dropped),
>> + STAT_NETDEV(tx_dropped),
>> + STAT_NETDEV(multicast),
>
> please don't report standard interface stats in ethtool -S
>
>> + /* UniMAC RSV counters */
>> + STAT_BCMASP_MIB_RX("rx_64_octets", mib.rx.pkt_cnt.cnt_64),
>> + STAT_BCMASP_MIB_RX("rx_65_127_oct", mib.rx.pkt_cnt.cnt_127),
>> + STAT_BCMASP_MIB_RX("rx_128_255_oct", mib.rx.pkt_cnt.cnt_255),
>> + STAT_BCMASP_MIB_RX("rx_256_511_oct", mib.rx.pkt_cnt.cnt_511),
>> + STAT_BCMASP_MIB_RX("rx_512_1023_oct", mib.rx.pkt_cnt.cnt_1023),
>> + STAT_BCMASP_MIB_RX("rx_1024_1518_oct", mib.rx.pkt_cnt.cnt_1518),
>> + STAT_BCMASP_MIB_RX("rx_vlan_1519_1522_oct", mib.rx.pkt_cnt.cnt_mgv),
>> + STAT_BCMASP_MIB_RX("rx_1522_2047_oct", mib.rx.pkt_cnt.cnt_2047),
>> + STAT_BCMASP_MIB_RX("rx_2048_4095_oct", mib.rx.pkt_cnt.cnt_4095),
>> + STAT_BCMASP_MIB_RX("rx_4096_9216_oct", mib.rx.pkt_cnt.cnt_9216),
>
> these should also be removed, and you should implement @get_rmon_stats.
>
>> + STAT_BCMASP_MIB_RX("rx_pkts", mib.rx.pkt),
>> + STAT_BCMASP_MIB_RX("rx_bytes", mib.rx.bytes),
>> + STAT_BCMASP_MIB_RX("rx_multicast", mib.rx.mca),
>> + STAT_BCMASP_MIB_RX("rx_broadcast", mib.rx.bca),
>> + STAT_BCMASP_MIB_RX("rx_fcs", mib.rx.fcs),
>
> there's a FCS error statistic in the standard stats, no need to
> duplicate
>
>> + STAT_BCMASP_MIB_RX("rx_control", mib.rx.cf),
>> + STAT_BCMASP_MIB_RX("rx_pause", mib.rx.pf),
>
> @get_pause_stats
>
>> + STAT_BCMASP_MIB_RX("rx_unknown", mib.rx.uo),
>> + STAT_BCMASP_MIB_RX("rx_align", mib.rx.aln),
>> + STAT_BCMASP_MIB_RX("rx_outrange", mib.rx.flr),
>> + STAT_BCMASP_MIB_RX("rx_code", mib.rx.cde),
>> + STAT_BCMASP_MIB_RX("rx_carrier", mib.rx.fcr),
>> + STAT_BCMASP_MIB_RX("rx_oversize", mib.rx.ovr),
>> + STAT_BCMASP_MIB_RX("rx_jabber", mib.rx.jbr),
>
> these look like candidates from standard stats, too.
> Please read thru:
>
> https://docs.kernel.org/next/networking/statistics.html
>
>> + STAT_BCMASP_MIB_RX("rx_mtu_err", mib.rx.mtue),
>> + STAT_BCMASP_MIB_RX("rx_good_pkts", mib.rx.pok),
>> + STAT_BCMASP_MIB_RX("rx_unicast", mib.rx.uc),
>> + STAT_BCMASP_MIB_RX("rx_ppp", mib.rx.ppp),
>> + STAT_BCMASP_MIB_RX("rx_crc", mib.rx.rcrc),
>
> hm, what's the difference between rx_crc and rx_fcs ?
Since you are going to respin to address Jakub's feedback, we should
also consider using the shared unimac.h header file. We could even make
a library out of it for standardized statistics once this driver gets
accepted.
--
Florian
On 6/2/23 11:58 PM, Jakub Kicinski wrote:
> On Thu, 1 Jun 2023 15:12:28 -0700 Justin Chen wrote:
>> + /* general stats */
>> + STAT_NETDEV(rx_packets),
>> + STAT_NETDEV(tx_packets),
>> + STAT_NETDEV(rx_bytes),
>> + STAT_NETDEV(tx_bytes),
>> + STAT_NETDEV(rx_errors),
>> + STAT_NETDEV(tx_errors),
>> + STAT_NETDEV(rx_dropped),
>> + STAT_NETDEV(tx_dropped),
>> + STAT_NETDEV(multicast),
>
> please don't report standard interface stats in ethtool -S
>
These are not netdev statistics but MAC block counters. Guess it is not
clear with the naming here, will fix this. We have a use case where the
MAC traffic may be redirected from the associated net dev, so the
counters may not be the same.
>> + /* UniMAC RSV counters */
>> + STAT_BCMASP_MIB_RX("rx_64_octets", mib.rx.pkt_cnt.cnt_64),
>> + STAT_BCMASP_MIB_RX("rx_65_127_oct", mib.rx.pkt_cnt.cnt_127),
>> + STAT_BCMASP_MIB_RX("rx_128_255_oct", mib.rx.pkt_cnt.cnt_255),
>> + STAT_BCMASP_MIB_RX("rx_256_511_oct", mib.rx.pkt_cnt.cnt_511),
>> + STAT_BCMASP_MIB_RX("rx_512_1023_oct", mib.rx.pkt_cnt.cnt_1023),
>> + STAT_BCMASP_MIB_RX("rx_1024_1518_oct", mib.rx.pkt_cnt.cnt_1518),
>> + STAT_BCMASP_MIB_RX("rx_vlan_1519_1522_oct", mib.rx.pkt_cnt.cnt_mgv),
>> + STAT_BCMASP_MIB_RX("rx_1522_2047_oct", mib.rx.pkt_cnt.cnt_2047),
>> + STAT_BCMASP_MIB_RX("rx_2048_4095_oct", mib.rx.pkt_cnt.cnt_4095),
>> + STAT_BCMASP_MIB_RX("rx_4096_9216_oct", mib.rx.pkt_cnt.cnt_9216),
>
> these should also be removed, and you should implement @get_rmon_stats.
>
>> + STAT_BCMASP_MIB_RX("rx_pkts", mib.rx.pkt),
>> + STAT_BCMASP_MIB_RX("rx_bytes", mib.rx.bytes),
>> + STAT_BCMASP_MIB_RX("rx_multicast", mib.rx.mca),
>> + STAT_BCMASP_MIB_RX("rx_broadcast", mib.rx.bca),
>> + STAT_BCMASP_MIB_RX("rx_fcs", mib.rx.fcs),
>
> there's a FCS error statistic in the standard stats, no need to
> duplicate
>
Same comment as above
>> + STAT_BCMASP_MIB_RX("rx_control", mib.rx.cf),
>> + STAT_BCMASP_MIB_RX("rx_pause", mib.rx.pf),
>
> @get_pause_stats
>
>> + STAT_BCMASP_MIB_RX("rx_unknown", mib.rx.uo),
>> + STAT_BCMASP_MIB_RX("rx_align", mib.rx.aln),
>> + STAT_BCMASP_MIB_RX("rx_outrange", mib.rx.flr),
>> + STAT_BCMASP_MIB_RX("rx_code", mib.rx.cde),
>> + STAT_BCMASP_MIB_RX("rx_carrier", mib.rx.fcr),
>> + STAT_BCMASP_MIB_RX("rx_oversize", mib.rx.ovr),
>> + STAT_BCMASP_MIB_RX("rx_jabber", mib.rx.jbr),
>
> these look like candidates from standard stats, too.
> Please read thru:
>
> https://docs.kernel.org/next/networking/statistics.html
>
Looks like the way we are doing stats are a bit outdated. Thanks for
pointing it out. I got a bit of refactoring to do.
>> + STAT_BCMASP_MIB_RX("rx_mtu_err", mib.rx.mtue),
>> + STAT_BCMASP_MIB_RX("rx_good_pkts", mib.rx.pok),
>> + STAT_BCMASP_MIB_RX("rx_unicast", mib.rx.uc),
>> + STAT_BCMASP_MIB_RX("rx_ppp", mib.rx.ppp),
>> + STAT_BCMASP_MIB_RX("rx_crc", mib.rx.rcrc),
>
> hm, what's the difference between rx_crc and rx_fcs ?
This looks like some debug feature that really has nothing to do with
verifying crcs. I will remove it.
Apologies, probably should have done my due diligence with each stats
instead of blindly including everything.
Thanks,
Justin
On Tue, 6 Jun 2023 15:58:21 -0700 Justin Chen wrote:
> On 6/2/23 11:58 PM, Jakub Kicinski wrote:
> > On Thu, 1 Jun 2023 15:12:28 -0700 Justin Chen wrote:
> >> + /* general stats */
> >> + STAT_NETDEV(rx_packets),
> >> + STAT_NETDEV(tx_packets),
> >> + STAT_NETDEV(rx_bytes),
> >> + STAT_NETDEV(tx_bytes),
> >> + STAT_NETDEV(rx_errors),
> >> + STAT_NETDEV(tx_errors),
> >> + STAT_NETDEV(rx_dropped),
> >> + STAT_NETDEV(tx_dropped),
> >> + STAT_NETDEV(multicast),
> >
> > please don't report standard interface stats in ethtool -S
> >
>
> These are not netdev statistics but MAC block counters. Guess it is not
> clear with the naming here, will fix this. We have a use case where the
> MAC traffic may be redirected from the associated net dev, so the
> counters may not be the same.
You seem to be dumping straight from the stats member of struct
net_device:
+ if (s->type == BCMASP_STAT_NETDEV)
+ p = (char *)&dev->stats;
No?
Also - can you describe how you can have multiple netdevs for
the same MAC?
On 6/6/2023 5:16 PM, Jakub Kicinski wrote:
> On Tue, 6 Jun 2023 15:58:21 -0700 Justin Chen wrote:
>> On 6/2/23 11:58 PM, Jakub Kicinski wrote:
>>> On Thu, 1 Jun 2023 15:12:28 -0700 Justin Chen wrote:
>>>> + /* general stats */
>>>> + STAT_NETDEV(rx_packets),
>>>> + STAT_NETDEV(tx_packets),
>>>> + STAT_NETDEV(rx_bytes),
>>>> + STAT_NETDEV(tx_bytes),
>>>> + STAT_NETDEV(rx_errors),
>>>> + STAT_NETDEV(tx_errors),
>>>> + STAT_NETDEV(rx_dropped),
>>>> + STAT_NETDEV(tx_dropped),
>>>> + STAT_NETDEV(multicast),
>>>
>>> please don't report standard interface stats in ethtool -S
>>>
>>
>> These are not netdev statistics but MAC block counters. Guess it is not
>> clear with the naming here, will fix this. We have a use case where the
>> MAC traffic may be redirected from the associated net dev, so the
>> counters may not be the same.
>
> You seem to be dumping straight from the stats member of struct
> net_device:
>
> + if (s->type == BCMASP_STAT_NETDEV)
> + p = (char *)&dev->stats;
>
> No?
>
Woops I got it mixed up. Yes these stats are redundant. What I was
describing is
+ STAT_BCMASP_MIB_RX("rx_pkts", mib.rx.pkt),
and equivalent.
> Also - can you describe how you can have multiple netdevs for
> the same MAC?
Not netdevs per se, but packets can be redirected to an offload
co-processor.
On Tue, 6 Jun 2023 18:35:51 -0700 Justin Chen wrote:
> > Also - can you describe how you can have multiple netdevs for
> > the same MAC?
>
> Not netdevs per se, but packets can be redirected to an offload
> co-processor.
How is the redirecting configured?
Could you split this patch into basic netdev datapath,
and then as separate patches support for ethtool configuration features,
each with its own patch? This will make it easier for area experts to
review.
The base patch can probably include these:
+ .get_drvinfo = bcmasp_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+ .get_link_ksettings = phy_ethtool_get_link_ksettings,
+ .set_link_ksettings = phy_ethtool_set_link_ksettings,
+ .get_msglevel = bcmasp_get_msglevel,
+ .set_msglevel = bcmasp_set_msglevel,
WoL can be a separate patch:
+ .get_wol = bcmasp_get_wol,
+ .set_wol = bcmasp_set_wol,
Stats a separate patch:
+ .get_strings = bcmasp_get_strings,
+ .get_ethtool_stats = bcmasp_get_ethtool_stats,
+ .get_sset_count = bcmasp_get_sset_count,
+ .nway_reset = phy_ethtool_nway_reset,
Flow steering separate:
+ .get_rxnfc = bcmasp_get_rxnfc,
+ .set_rxnfc = bcmasp_set_rxnfc,
EEE separate:
+ .set_eee = bcmasp_set_eee,
+ .get_eee = bcmasp_get_eee,
On 6/6/2023 6:54 PM, Jakub Kicinski wrote:
> On Tue, 6 Jun 2023 18:35:51 -0700 Justin Chen wrote:
>>> Also - can you describe how you can have multiple netdevs for
>>> the same MAC?
>>
>> Not netdevs per se, but packets can be redirected to an offload
>> co-processor.
>
> How is the redirecting configured?
>
Through filters that can be programmed by the Host cpu or co-processor.
> Could you split this patch into basic netdev datapath,
> and then as separate patches support for ethtool configuration features,
> each with its own patch? This will make it easier for area experts to
> review.
>
> The base patch can probably include these:
>
> + .get_drvinfo = bcmasp_get_drvinfo,
> + .get_link = ethtool_op_get_link,
> + .get_link_ksettings = phy_ethtool_get_link_ksettings,
> + .set_link_ksettings = phy_ethtool_set_link_ksettings,
> + .get_msglevel = bcmasp_get_msglevel,
> + .set_msglevel = bcmasp_set_msglevel,
>
> WoL can be a separate patch:
>
> + .get_wol = bcmasp_get_wol,
> + .set_wol = bcmasp_set_wol,
>
> Stats a separate patch:
>
> + .get_strings = bcmasp_get_strings,
> + .get_ethtool_stats = bcmasp_get_ethtool_stats,
> + .get_sset_count = bcmasp_get_sset_count,
> + .nway_reset = phy_ethtool_nway_reset,
>
> Flow steering separate:
>
> + .get_rxnfc = bcmasp_get_rxnfc,
> + .set_rxnfc = bcmasp_set_rxnfc,
>
> EEE separate:
>
> + .set_eee = bcmasp_set_eee,
> + .get_eee = bcmasp_get_eee,
Will do.
On Tue, 6 Jun 2023 19:33:13 -0700 Justin Chen wrote:
> >> Not netdevs per se, but packets can be redirected to an offload
> >> co-processor.
> >
> > How is the redirecting configured?
>
> Through filters that can be programmed by the Host cpu or co-processor.
How are the filter programmed by the host (in terms of user API)?
On 6/6/2023 8:45 PM, Jakub Kicinski wrote:
> On Tue, 6 Jun 2023 19:33:13 -0700 Justin Chen wrote:
>>>> Not netdevs per se, but packets can be redirected to an offload
>>>> co-processor.
>>>
>>> How is the redirecting configured?
>>
>> Through filters that can be programmed by the Host cpu or co-processor.
>
> How are the filter programmed by the host (in terms of user API)?
You are stumbling upon my next objective here. This patch set does not
support this because it wasn't clear how to do it. The plan was to get
the base driver merged first then introduce a way to specify an offload
channel.
If you must know, I introduced a rxnfc flow_spec ring cookie to specify
an offload filter. Not sure if this is the right way to do it or not,
but figured this would be a future discussion.
On Tue, 6 Jun 2023 21:22:45 -0700 Justin Chen wrote:
> >> Through filters that can be programmed by the Host cpu or co-processor.
> >
> > How are the filter programmed by the host (in terms of user API)?
>
> You are stumbling upon my next objective here. This patch set does not
> support this because it wasn't clear how to do it. The plan was to get
> the base driver merged first then introduce a way to specify an offload
> channel.
Alright.
> If you must know, I introduced a rxnfc flow_spec ring cookie to specify
> an offload filter. Not sure if this is the right way to do it or not,
> but figured this would be a future discussion.
We clean leave it for later indeed, but in case you're wondering -
that's unlikely to fly. My preference will be to expose the accelerator
port as a switch port, with a netdev and forward using TC flower etc.
With the netdev in place you'll have a place to report stats and all the
necessary diagnostics, which otherwise get crammed into random places.
I believe Florian asked about this in the past, I hope I'm being
consistent with my answer here :P
On Thu, Jun 01, 2023 at 03:12:27PM -0700, Justin Chen wrote:
> From: Florian Fainelli <[email protected]>
>
> Add a binding document for the Broadcom ASP 2.0 Ethernet
> controller.
>
> Reviewed-by: Conor Dooley <[email protected]>
> Signed-off-by: Florian Fainelli <[email protected]>
> Signed-off-by: Justin Chen <[email protected]>
> ---
> v6
> - Moved compatible to the top
> - Changed quotes to be consistent
> - Elaborated on brcm,channel description
>
> v5
> - Fix compatible string yaml format to properly capture what we want
>
> v4
> - Adjust compatible string example to reference SoC and HW ver
>
> v3
> - Minor formatting issues
> - Change channel prop to brcm,channel for vendor specific format
> - Removed redundant v2.0 from compat string
> - Fix ranges field
>
> v2
> - Minor formatting issues
>
> .../devicetree/bindings/net/brcm,asp-v2.0.yaml | 153 +++++++++++++++++++++
> 1 file changed, 153 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> new file mode 100644
> index 000000000000..3f2bf64b65c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
> @@ -0,0 +1,153 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom ASP 2.0 Ethernet controller
> +
> +maintainers:
> + - Justin Chen <[email protected]>
> + - Florian Fainelli <[email protected]>
> +
> +description: Broadcom Ethernet controller first introduced with 72165
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - brcm,bcm74165-asp
> + - const: brcm,asp-v2.1
> + - items:
> + - enum:
> + - brcm,bcm72165-asp
> + - const: brcm,asp-v2.0
> +
> + "#address-cells":
> + const: 1
> + "#size-cells":
> + const: 1
> +
> + reg:
> + maxItems: 1
> +
> + ranges: true
> +
> + interrupts:
> + minItems: 1
> + items:
> + - description: RX/TX interrupt
> + - description: Port 0 Wake-on-LAN
> + - description: Port 1 Wake-on-LAN
> +
> + clocks:
> + maxItems: 1
> +
> + ethernet-ports:
> + type: object
> + properties:
> + "#address-cells":
> + const: 1
> + "#size-cells":
> + const: 0
> +
> + patternProperties:
> + "^port@[0-9]+$":
> + type: object
> +
> + $ref: ethernet-controller.yaml#
unevaluatedProperties: false
> +
> + properties:
> + reg:
> + maxItems: 1
> + description: Port number
> +
> + brcm,channel:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> + ASP Channel Number
> +
> + The depacketizer channel that consumes packets from
> + the unimac/port.
> +
> + required:
> + - reg
> + - brcm,channel
> +
> + additionalProperties: false