net: macb: add RP1 PHC GPIO timestamp input and PPS output

[ahmadexp]

Raspberry Pi 5's RP1 owns GPIO and PIO resources, while its Ethernet MAC
provides a PTP hardware clock (PHC). Linux currently does not expose those
GPIOs through that PHC's standard PTP pin interface, so it cannot timestamp a
reference PPS on a selected GPIO or generate a PHC-aligned PPS output on one.

This series connects the MACB PHC to RP1 PIO, DMA and pin control. Linux PTP
clients such as testptp can map an available GPIO to an external timestamp
input or periodic output. This provides a route for hardware timestamping a
reference PPS in the Ethernet PHC and for outputting a PHC-aligned PPS to
another device, using standard PTP ioctls and no private ABI.

The series:

• Adds a Device Tree binding for the RP1 GEM MACB instance.
• Adds device-scoped RP1 PIO consumer functions and GPIO reservation support.
• Adds MACB PHC callbacks for GPIO0 through GPIO27, two external timestamp
  channels and one periodic output channel.
• Documents the testptp configuration for PPS input, output and simultaneous
  operation.

The first external timestamp channel works without periodic output. A second
input channel needs PEROUT active to provide the PHC anchor. With PEROUT active,
both indexed rising-edge inputs can operate alongside the output on three
distinct GPIOs. The direct channel-0 input path also supports falling-edge and
both-edge requests. GPIOs are selected at runtime by GPIO number, not header
pin number. The kernel PTP UAPI is unchanged.

Validation:

• Built the full ARM64 kernel image, modules and device trees with the feature
  enabled. The counter conversion helper also compiles with W=1.
• Built the standard kernel PTP testptp selftest and validated the MACB
  binding with dt-doc-validate.
• testptp -c on a Pi 5 booted with the candidate reports two external
  timestamp channels, one periodic output and 28 programmable pins.
• The packaged CLI's non-actuating preflight selected GPIO18 on EXTS channel 0,
  GPIO24 on channel 1 and GPIO23 for PEROUT, and confirmed that the pins were
  initially unmapped.
• Earlier candidate tests exercised EXTS and PEROUT sequentially on Pi 5 GPIOs.
  The simultaneous two-input plus output path has not yet received a physical
  waveform test. No comparison against the standard pps-gpio driver has been
  run. These tests establish neither absolute accuracy nor a jitter bound.

The simultaneous input/output path still needs physical qualification with
separate PPS sources on both input GPIOs and a scope or logic analyzer on the
output. CM5, additional GPIO waveforms, sustained duplex operation, failure
recovery under hardware faults and independent timing calibration remain open.

[pelwell]

This is very TL;DR - why don't you start with brief, human-written description of the problem you are trying to solve, followed by a list of the elements involved in the solution. It's also not a good idea to let your AI randomly "improve" things, except in separate commits that are clearly described.

BTW, "BCM" has no part to play in the discussion of GPIOs in the kernel - everything uses GPIO numbers, never (header) pin numbers.

[pelwell]

Why would you not include the full output from pioasm, with the assembly language as comments?

[nbuchwitz]

Did you test this on HW? Ideally test the performance against pps-gpio