From: Andrew Lunn <andrew@lunn.ch>
To: Simon Horman <horms+renesas@verge.net.au>
Cc: David Miller <davem@davemloft.net>,
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
Magnus Damm <magnus.damm@gmail.com>,
netdev@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>
Subject: Re: [PATCH v2 net-next] ravb: Avoid unsupported internal delay mode for R-Car E3/D3
Date: Wed, 10 Apr 2019 18:19:06 +0200 [thread overview]
Message-ID: <20190410161906.GD8916@lunn.ch> (raw)
In-Reply-To: <20190410114502.30362-1-horms+renesas@verge.net.au>
On Wed, Apr 10, 2019 at 01:45:02PM +0200, Simon Horman wrote:
> According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the
> TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3
> (r8a77995). And by extension it is also not supported by RZ/G2E (r9a774c0).
>
> This matches all ES versions of the affected SoCs as it is
> not clear if this problem will be resolved in newer chips.
> This can be revisited, as necessary.
>
> This patch does not error-out if PHY_INTERFACE_MODE_RGMII_ID or
> PHY_INTERFACE_MODE_RGMII_TXID are used on SoCs where TX clock delay
> mode is not supported as there is a risk of introducing a regression
> when used in conjunction with older DT blobs present in the field.
Hi Simon
I think it should at least WARN_ON(). Such blobs are broken, even if
they do kind of work.
Andrew
next prev parent reply other threads:[~2019-04-10 16:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 11:45 [PATCH v2 net-next] ravb: Avoid unsupported internal delay mode for R-Car E3/D3 Simon Horman
2019-04-10 12:17 ` Wolfram Sang
2019-04-10 16:19 ` Andrew Lunn [this message]
2019-04-10 17:17 ` Sergei Shtylyov
2019-04-11 8:40 ` Simon Horman
2019-04-11 9:20 ` Simon Horman
2019-04-11 13:33 ` Andrew Lunn
2019-04-11 16:36 ` Sergei Shtylyov
2019-04-15 11:45 ` Simon Horman
2019-04-15 16:49 ` Andrew Lunn
2019-04-15 17:10 ` Sergei Shtylyov
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=20190410161906.GD8916@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=horms+renesas@verge.net.au \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=wsa+renesas@sang-engineering.com \
--cc=yoshihiro.shimoda.uh@renesas.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 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.