Netdev List
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	lars.povlsen@microchip.com, Steen.Hegelund@microchip.com,
	daniel.machon@microchip.com, richardcochran@gmail.com,
	UNGLinuxDriver@microchip.com
Subject: Re: [PATCH net-next 4/4] net: lan966x: Add ptp trap rules
Date: Wed, 30 Nov 2022 18:54:43 +0200	[thread overview]
Message-ID: <20221130165443.ewjwm3z7nbwmktcv@skbuf> (raw)
In-Reply-To: <20221130143525.934906-5-horatiu.vultur@microchip.com> <20221130143525.934906-5-horatiu.vultur@microchip.com>

Hello Horatiu,

On Wed, Nov 30, 2022 at 03:35:25PM +0100, Horatiu Vultur wrote:
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_ptp.c b/drivers/net/ethernet/microchip/lan966x/lan966x_ptp.c
> index e5a2bbe064f8f..1f6614ee83169 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_ptp.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_ptp.c
> @@ -3,6 +3,8 @@
>  #include <linux/ptp_classify.h>
>  
>  #include "lan966x_main.h"
> +#include "vcap_api.h"
> +#include "vcap_api_client.h"
>  
>  #define LAN966X_MAX_PTP_ID	512
>  
> @@ -18,6 +20,17 @@
>  
>  #define TOD_ACC_PIN		0x7
>  
> +/* This represents the base rule ID for the PTP rules that are added in the
> + * VCAP to trap frames to CPU. This number needs to be bigger than the maximum
> + * number of entries that can exist in the VCAP.
> + */
> +#define LAN966X_VCAP_PTP_RULE_ID	1000000
> +#define LAN966X_VCAP_L2_PTP_TRAP	(LAN966X_VCAP_PTP_RULE_ID + 0)
> +#define LAN966X_VCAP_IPV4_EV_PTP_TRAP	(LAN966X_VCAP_PTP_RULE_ID + 1)
> +#define LAN966X_VCAP_IPV4_GEN_PTP_TRAP	(LAN966X_VCAP_PTP_RULE_ID + 2)
> +#define LAN966X_VCAP_IPV6_EV_PTP_TRAP	(LAN966X_VCAP_PTP_RULE_ID + 3)
> +#define LAN966X_VCAP_IPV6_GEN_PTP_TRAP	(LAN966X_VCAP_PTP_RULE_ID + 4)
> +
>  enum {
>  	PTP_PIN_ACTION_IDLE = 0,
>  	PTP_PIN_ACTION_LOAD,
> @@ -35,19 +48,229 @@ static u64 lan966x_ptp_get_nominal_value(void)
>  	return 0x304d4873ecade305;
>  }
>  
> +static int lan966x_ptp_add_trap(struct lan966x_port *port,
> +				int (*add_ptp_key)(struct vcap_rule *vrule,
> +						   struct lan966x_port*),
> +				u32 rule_id,
> +				u16 proto)
> +{
> +	struct lan966x *lan966x = port->lan966x;
> +	struct vcap_rule *vrule;
> +	int err;
> +
> +	vrule = vcap_get_rule(lan966x->vcap_ctrl, rule_id);
> +	if (vrule) {
> +		u32 value, mask;
> +
> +		/* Just modify the ingress port mask and exit */
> +		vcap_rule_get_key_u32(vrule, VCAP_KF_IF_IGR_PORT_MASK,
> +				      &value, &mask);
> +		mask &= ~BIT(port->chip_port);
> +		vcap_rule_mod_key_u32(vrule, VCAP_KF_IF_IGR_PORT_MASK,
> +				      value, mask);
> +
> +		err = vcap_mod_rule(vrule);
> +		goto free_rule;
> +	}
> +
> +	vrule = vcap_alloc_rule(lan966x->vcap_ctrl, port->dev,
> +				LAN966X_VCAP_CID_IS2_L0,
> +				VCAP_USER_PTP, 0, rule_id);
> +	if (!vrule)
> +		return -ENOMEM;
> +	if (IS_ERR(vrule))
> +		return PTR_ERR(vrule);
> +
> +	err = add_ptp_key(vrule, port);
> +	if (err)
> +		goto free_rule;
> +
> +	err = vcap_set_rule_set_actionset(vrule, VCAP_AFS_BASE_TYPE);
> +	err |= vcap_rule_add_action_bit(vrule, VCAP_AF_CPU_COPY_ENA, VCAP_BIT_1);
> +	err |= vcap_rule_add_action_u32(vrule, VCAP_AF_MASK_MODE, LAN966X_PMM_REPLACE);
> +	err |= vcap_val_rule(vrule, proto);
> +	if (err)
> +		goto free_rule;
> +
> +	err = vcap_add_rule(vrule);
> +
> +free_rule:
> +	/* Free the local copy of the rule */
> +	vcap_free_rule(vrule);
> +	return err;
> +}
> +
> +static int lan966x_ptp_del_trap(struct lan966x_port *port,
> +				u32 rule_id)
> +{
> +	struct lan966x *lan966x = port->lan966x;
> +	struct vcap_rule *vrule;
> +	u32 value, mask;
> +	int err;
> +
> +	vrule = vcap_get_rule(lan966x->vcap_ctrl, rule_id);
> +	if (!vrule)
> +		return -EEXIST;
> +
> +	vcap_rule_get_key_u32(vrule, VCAP_KF_IF_IGR_PORT_MASK, &value, &mask);
> +	mask |= BIT(port->chip_port);

Does the VCAP API not abstract away the negative mask representation of
the IGR_PORT_MASK field? I guess someone will stumble upon this in the
future and introduce a bug. In ocelot, struct ocelot_vcap_filter ::
ingress_port_mask ended being used quite in a wide variety of places.
It would be quite messy, unintuitive and tiring to treat it like a
reverse port mask everywhere it is used. In ocelot_vcap.c, it is just
reversed in the vcap_key_set() call.

> +
> +	/* No other port requires this trap, so it is safe to remove it */
> +	if (mask == GENMASK(lan966x->num_phys_ports, 0)) {
> +		err = vcap_del_rule(lan966x->vcap_ctrl, port->dev, rule_id);
> +		goto free_rule;
> +	}
> +
> +	vcap_rule_mod_key_u32(vrule, VCAP_KF_IF_IGR_PORT_MASK, value, mask);
> +	err = vcap_mod_rule(vrule);
> +
> +free_rule:
> +	vcap_free_rule(vrule);
> +	return err;
> +}
> +
> +static int lan966x_ptp_add_l2_key(struct vcap_rule *vrule,
> +				  struct lan966x_port *port)
> +{
> +	return vcap_rule_add_key_u32(vrule, VCAP_KF_ETYPE, ETH_P_1588, ~0);
> +}
> +
> +static int lan966x_ptp_add_ip_event_key(struct vcap_rule *vrule,
> +					struct lan966x_port *port)
> +{
> +	return vcap_rule_add_key_u32(vrule, VCAP_KF_L4_DPORT, 319, ~0) ||

s/319/PTP_EV_PORT/

> +	       vcap_rule_add_key_bit(vrule, VCAP_KF_TCP_IS, VCAP_BIT_0);
> +}
> +
> +static int lan966x_ptp_add_ip_general_key(struct vcap_rule *vrule,
> +					  struct lan966x_port *port)
> +{
> +	return vcap_rule_add_key_u32(vrule, VCAP_KF_L4_DPORT, 320, ~0) ||

s/320/PTP_GEN_PORT/

> +		vcap_rule_add_key_bit(vrule, VCAP_KF_TCP_IS, VCAP_BIT_0);
> +}
> +
> +static int lan966x_ptp_add_l2_rule(struct lan966x_port *port)
> +{
> +	return lan966x_ptp_add_trap(port, lan966x_ptp_add_l2_key,
> +				    LAN966X_VCAP_L2_PTP_TRAP, ETH_P_ALL);
> +}
> +
> +static int lan966x_ptp_add_ipv4_rules(struct lan966x_port *port)
> +{
> +	int err;
> +
> +	err = lan966x_ptp_add_trap(port, lan966x_ptp_add_ip_event_key,
> +				   LAN966X_VCAP_IPV4_EV_PTP_TRAP, ETH_P_IP);
> +	if (err)
> +		return err;
> +
> +	err = lan966x_ptp_add_trap(port, lan966x_ptp_add_ip_general_key,
> +				   LAN966X_VCAP_IPV4_GEN_PTP_TRAP, ETH_P_IP);
> +	if (err)
> +		lan966x_ptp_del_trap(port, LAN966X_VCAP_IPV4_EV_PTP_TRAP);
> +
> +	return err;
> +}

There's a comical amount of code duplication between this and ocelot_ptp.c,
save for the fact that it was written by different people. Is there any
possibility to reuse code with ocelot?

  reply	other threads:[~2022-11-30 16:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-30 14:35 [PATCH net-next 0/4] net: lan966x: Enable PTP on bridge interfaces Horatiu Vultur
2022-11-30 14:35 ` [PATCH net-next 1/4] net: microchip: vcap: Add vcap_get_rule Horatiu Vultur
2022-11-30 14:35 ` [PATCH net-next 2/4] net: microchip: vcap: Add vcap_mod_rule Horatiu Vultur
2022-11-30 14:35 ` [PATCH net-next 3/4] net: microchip: vcap: Add vcap_rule_get_key_u32 Horatiu Vultur
2022-11-30 14:35 ` [PATCH net-next 4/4] net: lan966x: Add ptp trap rules Horatiu Vultur
2022-11-30 16:54   ` Vladimir Oltean [this message]
2022-12-01  9:53     ` Horatiu Vultur

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221130165443.ewjwm3z7nbwmktcv@skbuf \
    --to=olteanv@gmail.com \
    --cc=Steen.Hegelund@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=daniel.machon@microchip.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=kuba@kernel.org \
    --cc=lars.povlsen@microchip.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=richardcochran@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox