devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Richard Cochran <richardcochran@gmail.com>
Cc: netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
	devicetree@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jacob Keller <jacob.e.keller@intel.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Miroslav Lichvar <mlichvar@redhat.com>,
	Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH V5 net-next 4/6] dt-bindings: ptp: Introduce MII time stamping devices.
Date: Mon, 8 Jul 2019 15:38:37 -0600	[thread overview]
Message-ID: <20190708213837.GA28934@bogus> (raw)
In-Reply-To: <d786656435c64160d50014beb3d3d9d1aaf6f22d.1559281985.git.richardcochran@gmail.com>

On Thu, May 30, 2019 at 10:56:24PM -0700, Richard Cochran wrote:
> This patch add a new binding that allows non-PHY MII time stamping
> devices to find their buses.  The new documentation covers both the
> generic binding and one upcoming user.
> 
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
>  Documentation/devicetree/bindings/ptp/ptp-ines.txt | 35 ++++++++++++++++++
>  .../devicetree/bindings/ptp/timestamper.txt        | 41 ++++++++++++++++++++++
>  2 files changed, 76 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/ptp/ptp-ines.txt
>  create mode 100644 Documentation/devicetree/bindings/ptp/timestamper.txt
> 
> diff --git a/Documentation/devicetree/bindings/ptp/ptp-ines.txt b/Documentation/devicetree/bindings/ptp/ptp-ines.txt
> new file mode 100644
> index 000000000000..4dee9eb89455
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ptp/ptp-ines.txt
> @@ -0,0 +1,35 @@
> +ZHAW InES PTP time stamping IP core
> +
> +The IP core needs two different kinds of nodes.  The control node
> +lives somewhere in the memory map and specifies the address of the
> +control registers.  There can be up to three port handles placed as
> +attributes of PHY nodes.  These associate a particular MII bus with a
> +port index within the IP core.
> +
> +Required properties of the control node:
> +
> +- compatible:		"ines,ptp-ctrl"

This is an IP block that gets integrated into SoCs? It's not very 
specific given that there could be different versions of the IP block 
and SoC vendors can integrate various versions of the IP block in their 
own unique (i.e. buggy) way.

> +- reg:			physical address and size of the register bank
> +
> +Required format of the port handle within the PHY node:
> +
> +- timestamper:		provides control node reference and
> +			the port channel within the IP core
> +
> +Example:
> +
> +	tstamper: timestamper@60000000 {
> +		compatible = "ines,ptp-ctrl";
> +		reg = <0x60000000 0x80>;
> +	};
> +
> +	ethernet@80000000 {
> +		...
> +		mdio {
> +			...
> +			phy@3 {

ethernet-phy is the correct node name.

> +				...
> +				timestamper = <&tstamper 0>;
> +			};
> +		};
> +	};
> diff --git a/Documentation/devicetree/bindings/ptp/timestamper.txt b/Documentation/devicetree/bindings/ptp/timestamper.txt
> new file mode 100644
> index 000000000000..88ea0bc7d662
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ptp/timestamper.txt
> @@ -0,0 +1,41 @@
> +Time stamps from MII bus snooping devices
> +
> +This binding supports non-PHY devices that snoop the MII bus and
> +provide time stamps.  In contrast to PHY time stamping drivers (which
> +can simply attach their interface directly to the PHY instance), stand
> +alone MII time stamping drivers use this binding to specify the
> +connection between the snooping device and a given network interface.
> +
> +Non-PHY MII time stamping drivers typically talk to the control
> +interface over another bus like I2C, SPI, UART, or via a memory mapped
> +peripheral.  This controller device is associated with one or more
> +time stamping channels, each of which snoops on a MII bus.
> +
> +The "timestamper" property lives in a phy node and links a time
> +stamping channel from the controller device to that phy's MII bus.
> +
> +Example:
> +
> +	tstamper: timestamper@10000000 {
> +		compatible = "bigcorp,ts-ctrl";

Would be better to use a real example here.

> +	};
> +
> +	ethernet@20000000 {
> +		mdio {
> +			phy@1 {
> +				timestamper = <&tstamper 0>;
> +			};
> +		};
> +	};
> +
> +	ethernet@30000000 {
> +		mdio {
> +			phy@2 {
> +				timestamper = <&tstamper 1>;
> +			};
> +		};
> +	};
> +
> +In this example, time stamps from the MII bus attached to phy@1 will
> +appear on time stamp channel 0 (zero), and those from phy@2 appear on
> +channel 1.
> -- 
> 2.11.0
> 

  reply	other threads:[~2019-07-08 21:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-31  5:56 [PATCH V5 net-next 0/6] Peer to Peer One-Step time stamping Richard Cochran
2019-05-31  5:56 ` [PATCH V5 net-next 1/6] net: Introduce peer to peer one step PTP " Richard Cochran
2019-05-31  5:56 ` [PATCH V5 net-next 2/6] net: Introduce a new MII time stamping interface Richard Cochran
2019-05-31  5:56 ` [PATCH V5 net-next 3/6] net: Add a layer for non-PHY MII time stamping drivers Richard Cochran
2019-05-31  5:56 ` [PATCH V5 net-next 4/6] dt-bindings: ptp: Introduce MII time stamping devices Richard Cochran
2019-07-08 21:38   ` Rob Herring [this message]
2019-07-09  5:11     ` Richard Cochran
2019-05-31  5:56 ` [PATCH V5 net-next 5/6] net: mdio: of: Register discovered MII time stampers Richard Cochran
2019-05-31 17:24   ` kbuild test robot
2019-05-31 17:24   ` [RFC PATCH] net: mdio: of: of_find_mii_timestamper() can be static kbuild test robot
2019-05-31  5:56 ` [PATCH V5 net-next 6/6] ptp: Add a driver for InES time stamping IP core Richard Cochran
2019-05-31 20:22   ` kbuild test robot
2019-05-31 20:22   ` [RFC PATCH] ptp: ines_ptp_probe_channel() can be static kbuild test robot
2019-05-31 21:54 ` [PATCH V5 net-next 0/6] Peer to Peer One-Step time stamping David Miller
2019-06-01  0:13   ` David Miller
2019-06-01  5:09     ` 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=20190708213837.GA28934@bogus \
    --to=robh@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=jacob.e.keller@intel.com \
    --cc=mark.rutland@arm.com \
    --cc=mlichvar@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=willemb@google.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 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).