All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
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>, <pabeni@redhat.com>,
	<Steen.Hegelund@microchip.com>, <lars.povlsen@microchip.com>,
	<daniel.machon@microchip.com>, <richardcochran@gmail.com>,
	<UNGLinuxDriver@microchip.com>, <olteanv@gmail.com>
Subject: Re: [PATCH net-next v2 0/4] net: lan966x: Enable PTP on bridge interfaces
Date: Fri, 2 Dec 2022 21:30:26 -0800	[thread overview]
Message-ID: <20221202213026.11d898d0@kernel.org> (raw)
In-Reply-To: <20221202075621.1504908-1-horatiu.vultur@microchip.com>

On Fri, 2 Dec 2022 08:56:17 +0100 Horatiu Vultur wrote:
> Before it was not allowed to run ptp on ports that are part of a bridge
> because in case of transparent clock the HW will still forward the frames
> so there would be duplicate frames.
> Now that there is VCAP support, it is possible to add entries in the VCAP
> to trap frames to the CPU and the CPU will forward these frames.
> The first part of the patch series, extends the VCAP support to be able to
> modify and get the rule, while the last patch uses the VCAP to trap the ptp
> frames.

This no longer applies, probably the fix from Dan..


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
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>, <pabeni@redhat.com>,
	<Steen.Hegelund@microchip.com>, <lars.povlsen@microchip.com>,
	<daniel.machon@microchip.com>, <richardcochran@gmail.com>,
	<UNGLinuxDriver@microchip.com>, <olteanv@gmail.com>
Subject: Re: [PATCH net-next v2 0/4] net: lan966x: Enable PTP on bridge interfaces
Date: Fri, 2 Dec 2022 21:30:26 -0800	[thread overview]
Message-ID: <20221202213026.11d898d0@kernel.org> (raw)
In-Reply-To: <20221202075621.1504908-1-horatiu.vultur@microchip.com>

On Fri, 2 Dec 2022 08:56:17 +0100 Horatiu Vultur wrote:
> Before it was not allowed to run ptp on ports that are part of a bridge
> because in case of transparent clock the HW will still forward the frames
> so there would be duplicate frames.
> Now that there is VCAP support, it is possible to add entries in the VCAP
> to trap frames to the CPU and the CPU will forward these frames.
> The first part of the patch series, extends the VCAP support to be able to
> modify and get the rule, while the last patch uses the VCAP to trap the ptp
> frames.

This no longer applies, probably the fix from Dan..


  parent reply	other threads:[~2022-12-03  5:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02  7:56 [PATCH net-next v2 0/4] net: lan966x: Enable PTP on bridge interfaces Horatiu Vultur
2022-12-02  7:56 ` Horatiu Vultur
2022-12-02  7:56 ` [PATCH net-next v2 1/4] net: microchip: vcap: Add vcap_get_rule Horatiu Vultur
2022-12-02  7:56   ` Horatiu Vultur
2022-12-02  7:56 ` [PATCH net-next v2 2/4] net: microchip: vcap: Add vcap_mod_rule Horatiu Vultur
2022-12-02  7:56   ` Horatiu Vultur
2022-12-02  7:56 ` [PATCH net-next v2 3/4] net: microchip: vcap: Add vcap_rule_get_key_u32 Horatiu Vultur
2022-12-02  7:56   ` Horatiu Vultur
2022-12-02  7:56 ` [PATCH net-next v2 4/4] net: lan966x: Add ptp trap rules Horatiu Vultur
2022-12-02  7:56   ` Horatiu Vultur
2022-12-03  5:30 ` Jakub Kicinski [this message]
2022-12-03  5:30   ` [PATCH net-next v2 0/4] net: lan966x: Enable PTP on bridge interfaces Jakub Kicinski

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=20221202213026.11d898d0@kernel.org \
    --to=kuba@kernel.org \
    --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=lars.povlsen@microchip.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.