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

On Tue, Feb 17, 2015 at 05:13:19PM +0000, Stathis Voukelatos wrote:
> 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.

In what cases would it _not_ be the same? From your description this is
that clock, no?

> >> 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.

Or submit a patch exporting it, along with the rationale for doing so?

> >>> 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.

Fundamentally, the use-case for this is monitoring an ethernet
interface. So regardless of which kernel framework this plumbs into,
there needs to be a way to go from ethN to whatever this is exposed as.

Exposing a completely separate interface makes no sense. Singleton stuff
like that inevitably gets broken as someone later builds a board with
multiple instances of some similar IP block.

So I would imagine that either the link between interface and monitoring
interface would be described somewhere in the filesystem, or there'd be
a syscall/ioctl/whatever to go from an interface to the appropriate
monitoring interface.

That all depends on exactly how this gets exposed in the end, however.


  reply	other threads:[~2015-02-17 17:30 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
2015-02-17 17:30           ` Mark Rutland [this message]
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 \
    --in-reply-to=20150217173000.GT8994@leverpostej \ \ \ \ \ \ \
    --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).