On Fri, Oct 15, 2021 at 5:48 PM Vladimir Oltean [off-list ref] wrote:

On Fri, Oct 15, 2021 at 12:55:27PM -0700, Jakub Kicinski wrote:

quoted

On Thu, 14 Oct 2021 09:31:04 -0500 Rob Herring wrote:

quoted

On Thu, 14 Oct 2021 01:23:12 +0300, Vladimir Oltean wrote:

quoted

Add a schema validator to nxp,sja1105.yaml and to dsa.yaml for explicit
MAC-level RGMII delays. These properties must be per port and must be
present only for a phy-mode that represents RGMII.

We tell dsa.yaml that these port properties might be present, we also
define their valid values for SJA1105. We create a common definition for
the RX and TX valid range, since it's quite a mouthful.

We also modify the example to include the explicit RGMII delay properties.
On the fixed-link ports (in the example, port 4), having these explicit
delays is actually mandatory, since with the new behavior, the driver
shouts that it is interpreting what delays to apply based on phy-mode.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

FWIW I dropped the set from pw based on Rob's report, I see a mention
of possible issues with fsl-lx2160a-bluebox3.dts, but it's not clear
to me which DT is disagreeing with the schema.. or is the schema itself
not 100?

I am only saying that I am introducing a new DT binding scheme and
warning all users of the old one. That's also why I am updating the
device trees, to silence the newly introduced warnings. I would like
this series to go through net-next, but fsl-lx2160a-bluebox3.dts isn't
in net-next.

.dts changes should go in via the sub-arch's tree, not a subsystem tree.

Rob