All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stathis Voukelatos <stathis.voukelatos@linn.co.uk>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"abrestic@chromium.org" <abrestic@chromium.org>
Subject: Re: [PATCH v2 1/3] Ethernet packet sniffer: Device tree binding and vendor prefix
Date: Tue, 17 Feb 2015 16:22:04 +0000	[thread overview]
Message-ID: <54E36AAC.7010308@linn.co.uk> (raw)
In-Reply-To: <20150217145124.GM8994@leverpostej>

Hi Mark,

On 17/02/15 14:51, Mark Rutland wrote:

>> +Matched packet bytes and timestamp values are returned through a
>> +FIFO. Timestamps are provided to the module through an externally
>> +generated Gray-encoded counter.
>
> Does this counter unit need to be enabled (or have any input clocks
> enabled)?
>

Yes it does, that is the purpose of the 'tstamp' entry in the
'clock-names' property below.

>> +
>> +Required properties:
>> +- compatible : must be "linn,eth-sniffer"
>
> Is there not a more precise name for this IP block?

It is generally called 'ethernet packet sniffer', maybe
linn,eth-packet-sniffer would be a more descriptive name?

>
>> +- reg : physical addresses and sizes of registers. Must contain 3 entries:
>> +          - registers memory space
>> +          - TX command string memory
>> +          - RX command string memory
>> +- reg-names : must contain the following 3 entries:
>> +                  "regs", "tx-ram", "rx-ram"
>
> It would be nicer to format this as:
>
> - reg: A list of physical address and size pairs corresponding to each
>         entry in reg-names
>
> - reg-names: must contain:
>    * "regs" for the control registers
>    * "tx-ram" for the TX command string memory
>    * "rx-ram" for the RX command string memory
>
> Which avoids redundancy.
>

Will change formatting as suggested

> The phrase "command string" sounds a bit odd. What are these used for
> exactly?

In these two memory areas we program a sequence of bytes in the
format: [cmd][value][cmd][value] to configure the data patterns that
the sniffer should match for Ethernet TX and RX packets respectively.
Maybe 'command memory' would be clearer?

>
>> +- interrupts : sniffer interrupt specifier
>> +- clocks : specify the system clock for the peripheral and
>> +	   the enable clock for the timestamp counter
>> +- clock-names : must contain the "sys" and "tstamp" entries
>
> Similarly here clocks should just be defined in terms of clock-names.

Will reformat similar to the 'regs' field

>
>> +- fifo-block-words : number of words in one data FIFO entry
>
> I didn't see a data FIFO described. Is that dynamically allocated and
> handed to the sniffer, or does that correspond to one of the memory
> regions above?
>

It is a H/W FIFO internal to the module and accessed through
a register. It is divided in blocks and 'fifo-block-words'
specify the number of words in each block. It is needed by
the driver to make sure it reads an entire block, in order
to clear the 'data available' interrupt.

>> +- tstamp-hz : frequency of the timestamp counter
>> +- tstamp-shift : shift value for the timestamp cyclecounter struct
>
> What exactly is this used for?
>
> Are there any docs?

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

>
>> +- tstamp-bits : width in bits of the timestamp counter
>> +
>> +Example:
>> +
>> +sniffer@1814a000 {
>> +	compatible = "linn,eth-sniffer";
>> +	reg = <0x1814a000 0x100>, <0x1814a400 0x400>,
>> +	      <0x1814a800 0x400>;
>> +	reg-names = "regs", "tx-ram", "rx-ram";
>> +	interrupts = <GIC_SHARED 58 IRQ_TYPE_LEVEL_HIGH>;
>> +	clocks = <&clk_core CLK_AUDIO>,
>> +		 <&cr_periph SYS_CLK_EVENT_TIMER>;
>> +	clock-names = "sys", "tstamp";
>> +	fifo-block-words = <4>;
>> +	tstamp-hz = <52000000>;
>> +	tstamp-shift = <27>;
>> +	tstamp-bits = <30>;
>
> This property wasn't documented.
>
> 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.

>
>> +};
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index d443279..891c224 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -90,6 +90,7 @@ lacie	LaCie
>>   lantiq	Lantiq Semiconductor
>>   lenovo	Lenovo Group Ltd.
>>   lg	LG Corporation
>> +linn    Linn Products Ltd.
>
> This addition looks fine to me. For some reason it seems to be padded
> with spaces instead of tabs though; is my mail server corrupting things
> or is that the case in the original patch?

Sorry, it was spaces. Will be fixed
>
> Thanks,
> Mark.
>

Thank you,
Stathis

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

Thread overview: 34+ 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 ` Stathis Voukelatos
2015-02-17 14:03 ` 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:03   ` Stathis Voukelatos
2015-02-17 14:16   ` Sergei Shtylyov
2015-02-17 14:51   ` Mark Rutland
2015-02-17 16:22     ` Stathis Voukelatos [this message]
2015-02-17 16:35       ` Mark Rutland
2015-02-17 17:13         ` Stathis Voukelatos
2015-02-17 17:13           ` Stathis Voukelatos
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-18 13:56                   ` Stathis Voukelatos
2015-02-17 14:03 ` [PATCH v2 2/3] Packet sniffer core framework Stathis Voukelatos
2015-02-17 14:03   ` Stathis Voukelatos
2015-02-18 15:42   ` Daniel Borkmann
     [not found]     ` <54E4B2CE.2090104-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2015-02-18 16:44       ` Stathis Voukelatos
2015-02-18 16:44         ` Stathis Voukelatos
2015-02-18 16:44         ` Stathis Voukelatos
     [not found] ` <cover.1424181053.git.stathis.voukelatos-zgcZaY4qg+21Qrn1Bg8BZw@public.gmane.org>
2015-02-17 14:03   ` [PATCH v2 3/3] Linn Ethernet packet sniffer driver Stathis Voukelatos
2015-02-17 14:03     ` Stathis Voukelatos
2015-02-17 14:03     ` Stathis Voukelatos
2015-02-18 21:08   ` [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver Richard Cochran
2015-02-18 21:08     ` Richard Cochran
     [not found]     ` <20150218210830.GA7778-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2015-02-23  9:37       ` Stathis Voukelatos
2015-02-23  9:37         ` Stathis Voukelatos
2015-02-23  9:37         ` Stathis Voukelatos
2015-02-25  9:50         ` Richard Cochran
2015-02-25 10:53           ` Stathis Voukelatos
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:
  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=54E36AAC.7010308@linn.co.uk \
    --to=stathis.voukelatos@linn.co.uk \
    --cc=abrestic@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=netdev@vger.kernel.org \
    /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.