LKML Archive on
help / color / mirror / Atom feed
From: Stathis Voukelatos <>
To: Mark Rutland <>
Cc: "" <>,
	"" <>,
	"" <>,
	"" <>
Subject: Re: [PATCH v2 1/3] Ethernet packet sniffer: Device tree binding and vendor prefix
Date: Tue, 17 Feb 2015 17:13:19 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20150217163527.GR8994@leverpostej>

Hi Mark,

On 17/02/15 16:35, Mark Rutland wrote:
>>>> +- tstamp-hz : frequency of the timestamp counter
> Is this the frequency the clock is running at, or a frequency that it
> should be programmed to in order to be used?
> The former can be queried from the common clock framework, and if you
> intended the latter the wording shuold be a little more explicit about
> that being the case.

It is the frequency of the timestamp values supplied to the sniffer
module. It is used by the driver to convert to nanoseconds.
I was trying to be somewhat generic here and not assume that it
is necessarily the same as the 'tstamp' clock below, in which case we
could indeed obtain it using the common clock framework.

>> See: include/linux/clocksource.h
>> The driver uses a cyclecounter and timecounter to convert raw timestamps
>> to nanoseconds. 'tstamp-shift' refers to the 'shift' field of the
>> cyclecounter structure, that can be used to improve the precision of
>> the conversion
> Sure, but the very concept of a cyclecounter is a Linux implementation
> detail. If we have the frequency of the timer we should be able to
> dynamically generate this, so there's no need for this to be in the DT.

Most networking driver use hard-coded values for that, but in my case
I did not want to assume a certain fixed clock frequency. I will remove
it from the DT and generate it dynamically. There is a kernel function
clocks_calc_mult_shift() to do it but unfortunately it is not exported,
so I guess I will need to replicate the code.

>>> As mentioned previously, I think the relation between this unit and the
>>> MAC and/or PHY needs to be explicitly described in the DT.
>> Do you suggest a field along the lines of:
>> mac = <&eth_controller_0>;
>> The driver could check that it exists and is valid but does
>> not need to make use of it.
> I would expect some level of the software stack to make use of it, or
> you have no idea which ethernet interface is related to this monitoring
> interface. Perhaps current systems only have one interface, but that
> shouldn't be relied upon.

Yes, but the sniffer module is hard-wired to a certain Ethernet Mii
interface. We can add an entry to tie it to an Ethernet controller, but
apart of a sanity check I am not sure what else the S/W can do.

> Thanks,
> Mark.

Thank you,

  reply	other threads:[~2015-02-17 17:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-17 14:03 [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver Stathis Voukelatos
2015-02-17 14:03 ` [PATCH v2 1/3] Ethernet packet sniffer: Device tree binding and vendor prefix Stathis Voukelatos
2015-02-17 14:16   ` Sergei Shtylyov
2015-02-17 14:51   ` Mark Rutland
2015-02-17 16:22     ` Stathis Voukelatos
2015-02-17 16:35       ` Mark Rutland
2015-02-17 17:13         ` Stathis Voukelatos [this message]
2015-02-17 17:30           ` Mark Rutland
2015-02-18  9:40             ` Stathis Voukelatos
2015-02-18 12:11               ` Mark Rutland
2015-02-18 13:56                 ` Stathis Voukelatos
2015-02-17 14:03 ` [PATCH v2 2/3] Packet sniffer core framework Stathis Voukelatos
2015-02-18 15:42   ` Daniel Borkmann
2015-02-18 16:44     ` Stathis Voukelatos
2015-02-17 14:03 ` [PATCH v2 3/3] Linn Ethernet packet sniffer driver Stathis Voukelatos
2015-02-18 21:08 ` [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver Richard Cochran
2015-02-23  9:37   ` Stathis Voukelatos
2015-02-25  9:50     ` Richard Cochran
2015-02-25 10:53       ` Stathis Voukelatos
2015-02-25 14:21         ` Richard Cochran

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:

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

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2 1/3] Ethernet packet sniffer: Device tree binding and vendor prefix' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).