mmit f0d4ba9eff75a79fccb7793f4d9f12303d458603
>> Author: Kamil Alkhouri
>> Date: Tue Nov 3 08:10:58 2020 +0100
>>
>> net: dsa: hellcreek: Add support for hardware timestamping
>>
>> The analysis is as follows:
>>
>> 323/*
te: Tue Nov 3 08:10:58 2020 +0100
>
> net: dsa: hellcreek: Add support for hardware timestamping
>
> The analysis is as follows:
>
> 323/* Get nanoseconds from ptp packet */
> 324type = SKB_PTP_TYPE(skb);
>
>4. returned_null: ptp_pars
Hi
Static analysis on linux-next with Coverity has detected a potential
null pointer dereference issue on the following commit:
commit f0d4ba9eff75a79fccb7793f4d9f12303d458603
Author: Kamil Alkhouri
Date: Tue Nov 3 08:10:58 2020 +0100
net: dsa: hellcreek: Add support for hardware
From: Kamil Alkhouri
The switch has the ability to take hardware generated time stamps per port for
PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed
time synchronization precision for TSN devices/switches. So add support for it.
There are two directions:
* RX
From: Kamil Alkhouri
The switch has the ability to take hardware generated time stamps per port for
PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed
time synchronization precision for TSN devices/switches. So add support for it.
There are two directions:
* RX
On Wed Oct 14 2020, Richard Cochran wrote:
> On Wed, Oct 14, 2020 at 12:57:47PM +0300, Vladimir Oltean wrote:
>> So the discussion is about how to have the cake and eat it at the same
>> time.
>
> And I wish for a pony. With sparkles. And a unicorn. And a rainbow.
>
>> Silicon vendors eager to f
On Wed, Oct 14, 2020 at 12:57:47PM +0300, Vladimir Oltean wrote:
> So the discussion is about how to have the cake and eat it at the same
> time.
And I wish for a pony. With sparkles. And a unicorn. And a rainbow.
> Silicon vendors eager to follow the latest trends in standards are
> implement
On Mon, Oct 12, 2020 at 02:42:54PM -0700, Richard Cochran wrote:
> If you want, you can run your PHC using the linuxptp "free_running"
> option. Then, you can use the TIME_STATUS_NP management request to
> use the remote time signal in your application.
I was expecting some sort of reaction to th
On Mon, Oct 12, 2020 at 02:53:58PM +0200, Kamil Alkhouri wrote:
> > By the way, how would you see the split between an unsynchronized and
> > a
> > synchronized PHC be implemented in the Linux kernel?
If you want, you can run your PHC using the linuxptp "free_running"
option. Then, you can use th
Hi Vladimir,
On Thu, 2020-10-08 at 18:09 +0300, Vladimir Oltean wrote:
> Hi Kamil,
>
> On Thu, Oct 08, 2020 at 02:55:57PM +0200, Kamil Alkhouri wrote:
> > Hello dears,
> >
> > On Thu, 2020-10-08 at 12:01 +0200, Kurt Kanzenbach wrote:
> > > On Thu Oct 08 2020, Vladimir Oltean wrote:
> > > > On Th
Hi Kamil,
On Thu, Oct 08, 2020 at 02:55:57PM +0200, Kamil Alkhouri wrote:
> Hello dears,
>
> On Thu, 2020-10-08 at 12:01 +0200, Kurt Kanzenbach wrote:
> > On Thu Oct 08 2020, Vladimir Oltean wrote:
> > > On Thu, Oct 08, 2020 at 10:34:11AM +0200, Kurt Kanzenbach wrote:
> > > > On Wed Oct 07 2020,
Hello dears,
On Thu, 2020-10-08 at 12:01 +0200, Kurt Kanzenbach wrote:
> On Thu Oct 08 2020, Vladimir Oltean wrote:
> > On Thu, Oct 08, 2020 at 10:34:11AM +0200, Kurt Kanzenbach wrote:
> > > On Wed Oct 07 2020, Vladimir Oltean wrote:
> > > > On Wed, Oct 07, 2020 at 12:39:49PM +0200, Kurt Kanzenbac
On Thu Oct 08 2020, Vladimir Oltean wrote:
> On Thu, Oct 08, 2020 at 10:34:11AM +0200, Kurt Kanzenbach wrote:
>> On Wed Oct 07 2020, Vladimir Oltean wrote:
>> > On Wed, Oct 07, 2020 at 12:39:49PM +0200, Kurt Kanzenbach wrote:
>> >> For instance the hellcreek switch has actually three ptp hardware
>
On Thu, Oct 08, 2020 at 10:34:11AM +0200, Kurt Kanzenbach wrote:
> On Wed Oct 07 2020, Vladimir Oltean wrote:
> > On Wed, Oct 07, 2020 at 12:39:49PM +0200, Kurt Kanzenbach wrote:
> >> For instance the hellcreek switch has actually three ptp hardware
> >> clocks and the time stamping can be configur
On Wed Oct 07 2020, Vladimir Oltean wrote:
> On Wed, Oct 07, 2020 at 12:39:49PM +0200, Kurt Kanzenbach wrote:
>> For instance the hellcreek switch has actually three ptp hardware
>> clocks and the time stamping can be configured to use either one of
>> them.
>
> The sja1105 also has a corrected and
On Wed, Oct 07, 2020 at 12:39:49PM +0200, Kurt Kanzenbach wrote:
> On Tue Oct 06 2020, Vladimir Oltean wrote:
> > On Tue, Oct 06, 2020 at 03:56:31PM +0200, Kurt Kanzenbach wrote:
> >> Yeah, sure. That use case makes sense. What's the problem exactly?
> >
> > The SO_TIMESTAMPING / SO_TIMESTAMPNS cms
On Tue Oct 06 2020, Vladimir Oltean wrote:
> On Tue, Oct 06, 2020 at 03:56:31PM +0200, Kurt Kanzenbach wrote:
>> On Tue Oct 06 2020, Vladimir Oltean wrote:
>> > On Tue, Oct 06, 2020 at 03:30:36PM +0200, Kurt Kanzenbach wrote:
>> >> That's the point. The user (or anybody else) cannot disable hardwar
On Tue, Oct 06, 2020 at 03:56:31PM +0200, Kurt Kanzenbach wrote:
> On Tue Oct 06 2020, Vladimir Oltean wrote:
> > On Tue, Oct 06, 2020 at 03:30:36PM +0200, Kurt Kanzenbach wrote:
> >> That's the point. The user (or anybody else) cannot disable hardware
> >> stamping, because it is always performed.
On Tue Oct 06 2020, Vladimir Oltean wrote:
> On Tue, Oct 06, 2020 at 03:30:36PM +0200, Kurt Kanzenbach wrote:
>> That's the point. The user (or anybody else) cannot disable hardware
>> stamping, because it is always performed. So, why should it be allowed
>> to disable it even when it cannot be dis
On Tue, Oct 06, 2020 at 03:30:36PM +0200, Kurt Kanzenbach wrote:
> That's the point. The user (or anybody else) cannot disable hardware
> stamping, because it is always performed. So, why should it be allowed
> to disable it even when it cannot be disabled?
Because your driver's user can attach a
On Tue Oct 06 2020, Vladimir Oltean wrote:
> On Tue, Oct 06, 2020 at 08:27:42AM +0200, Kurt Kanzenbach wrote:
>> On Sun Oct 04 2020, Vladimir Oltean wrote:
>> > On Sun, Oct 04, 2020 at 01:29:08PM +0200, Kurt Kanzenbach wrote:
>> >> +/* Enabling/disabling TX and RX HW timestamping for different PTP
On Tue, Oct 06, 2020 at 08:27:42AM +0200, Kurt Kanzenbach wrote:
> On Sun Oct 04 2020, Vladimir Oltean wrote:
> > On Sun, Oct 04, 2020 at 01:29:08PM +0200, Kurt Kanzenbach wrote:
> >> +/* Enabling/disabling TX and RX HW timestamping for different PTP
> >> messages is
> >> + * not available in the
On Sun Oct 04 2020, Vladimir Oltean wrote:
> On Sun, Oct 04, 2020 at 01:29:08PM +0200, Kurt Kanzenbach wrote:
>> +/* Enabling/disabling TX and RX HW timestamping for different PTP messages
>> is
>> + * not available in the switch. Thus, this function only serves as a check
>> if
>> + * the user r
On Sun, Oct 04, 2020 at 01:29:08PM +0200, Kurt Kanzenbach wrote:
> From: Kamil Alkhouri
>
> The switch has the ability to take hardware generated time stamps per port for
> PTPv2 event messages in Rx and Tx direction. That is useful for achieving
> needed
> time synchronization precision for TSN
From: Kamil Alkhouri
The switch has the ability to take hardware generated time stamps per port for
PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed
time synchronization precision for TSN devices/switches. So add support for it.
There are two directions:
* RX
From: Kamil Alkhouri
The switch has the ability to take hardware generated time stamps per port for
PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed
time synchronization precision for TSN devices/switches. So add support for it.
There are two directions:
* RX
From: Kamil Alkhouri
The switch has the ability to take hardware generated time stamps per port for
PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed
time synchronization precision for TSN devices/switches. So add support for it.
There are two directions:
* RX
From: Kamil Alkhouri
The switch has the ability to take hardware generated time stamps per port for
PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed
time synchronization precision for TSN devices/switches. So add support for it.
There are two directions:
* RX
Hi Kurt,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on net-next/master]
[also build test ERROR on next-20200723]
[cannot apply to robh/for-next sparc-next/master net/master linus/master
v5.8-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a not
From: Kamil Alkhouri
The switch has the ability to take hardware generated time stamps per port for
PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed
time synchronization precision for TSN devices/switches. So add support for it.
There are two directions:
* RX
On Mon, Jul 13, 2020 at 05:12:17PM +0300, Vladimir Oltean wrote:
> On Mon, Jul 13, 2020 at 07:01:12AM -0700, Richard Cochran wrote:
> > I don't think it makes sense for DSA drivers to set this bit, as it
> > serves no purpose in the DSA context.
> >
>
> For whom does this bit serve a purpose, tho
On Mon, Jul 13, 2020 at 07:01:12AM -0700, Richard Cochran wrote:
> On Mon, Jul 13, 2020 at 12:57:34PM +0200, Kurt Kanzenbach wrote:
> > > I would like to get some clarification on whether "SKBTX_IN_PROGRESS"
> > > should be set in shtx->tx_flags or not. On one hand, it's asking for
> > > trouble, o
On Mon, Jul 13, 2020 at 12:57:34PM +0200, Kurt Kanzenbach wrote:
> Hi Vladimir,
>
> On Mon Jul 13 2020, Vladimir Oltean wrote:
> >> +/* Get a pointer to the PTP header in this skb */
> >> +static u8 *parse_ptp_header(struct sk_buff *skb, unsigned int type)
> >
> > Maybe this and the function from
Hi Vladimir,
On Mon Jul 13 2020, Vladimir Oltean wrote:
> Hi Kurt,
>
> On Fri, Jul 10, 2020 at 01:36:07PM +0200, Kurt Kanzenbach wrote:
>> From: Kamil Alkhouri
>>
>> The switch has the ability to take hardware generated time stamps per port
>> for
>> PTPv2 event messages in Rx and Tx direction.
Hi Kurt,
On Fri, Jul 10, 2020 at 01:36:07PM +0200, Kurt Kanzenbach wrote:
> From: Kamil Alkhouri
>
> The switch has the ability to take hardware generated time stamps per port for
> PTPv2 event messages in Rx and Tx direction. That is useful for achieving
> needed
> time synchronization precisi
On Sat Jul 11 2020, Richard Cochran wrote:
> On Fri, Jul 10, 2020 at 01:36:07PM +0200, Kurt Kanzenbach wrote:
>> +static void hellcreek_get_rxts(struct hellcreek *hellcreek,
>> + struct hellcreek_port_hwtstamp *ps,
>> + struct sk_buff *skb, struct
On Fri, Jul 10, 2020 at 01:36:07PM +0200, Kurt Kanzenbach wrote:
> +static void hellcreek_get_rxts(struct hellcreek *hellcreek,
> +struct hellcreek_port_hwtstamp *ps,
> +struct sk_buff *skb, struct sk_buff_head *rxq,
> +
From: Kamil Alkhouri
The switch has the ability to take hardware generated time stamps per port for
PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed
time synchronization precision for TSN devices/switches. So add support for it.
There are two directions:
* RX
From: Kamil Alkhouri
The switch has the ability to take hardware generated time stamps per port for
PTPv2 event messages in Rx and Tx direction. That is useful for achieving needed
time synchronization precision for TSN devices/switches. So add support for it.
There are two directions:
* RX
39 matches
Mail list logo
