[PATCH v3 02/10] dt-bindings: pincfg-node: Add properties 'skew-delay-{in,out}put'

Linus Walleij linus.walleij at linaro.org
Thu Oct 16 15:41:21 PDT 2025


On Wed, Oct 15, 2025 at 6:37 PM Andrew Lunn <andrew at lunn.ch> wrote:

> > I don't recall the reason for this way of defining things, but one reason
> > could be that the skew-delay incurred by two inverters is very
> > dependent on the production node of the silicon, and can be
> > nanoseconds or picoseconds, these days mostly picoseconds.
> > Example: Documentation/devicetree/bindings/net/adi,adin.yaml
>
>
> I'm missing the big picture here, and i don't see an example of these
> properties being used. However, since you reference an old networking
> example, for RGMII delays....
>
> adi,rx-internal-delay-ps should be deprecated, we now have the generic
> rx-internal-delay-ps. The point about using -ps is however still
> valid.
>
> However, i would not like to see pinctl DT properties used in place of
> rx-internal-delay-ps. How the Ethernet MAC driver implements
> rx-internal-delay-ps is left open, so calling a pinctl API to set the
> skew is fine by me. And if the real use case has nothing to do with
> networking, then i don't care.

The scope here is to describe skewing the timing of any line
connected to a pin, no matter the purpose. Could be an MMC
card for example, or something else, but the point is that
the control registers are general and inside the SoC perimeter,
i.e. around the pins, not necessarily related to any specific
hardware block.

But I guess it could be used for a line used by some ethernet
interface.

But the config here happens on the pin controller, so a specific
hardware block distinct from e.g. an MMC controller or Ethernet
MAC, the latter just have their lines routed through it.

The pin controller will handle some pin named "TX", which is
just a string, a pin controller does not know what this means,
if it is a UART TX or a MAC TX but it can configure the skew
delay of the pin named like so.

Yours,
Linus Walleij



More information about the linux-arm-kernel mailing list