mesa-demo: runtime PHY-only mode with optional SPI-proxy client

[vjardin]

Support the MEPA PHYs (LAN80xx) without a switch instance.

It can be used with 2 modes: either thru direct access to a /dev/spidev or thru a proxy that centralize the access to the /dev/spidev in order to support many users of the same MEPA PHY.

Signed-off-by: Vincent Jardin vjardin@free.fr

[vjardin]

see
microchip-ung/sw-mepa#11

[vjardin]

optional: it can use this proxy, https://github.com/vjardin/mepa-spidev-proxy

[vjardin]

Please, @HoratiuVultur, how would you consider such feature for your next 2026.09 release ? It is the only mean I found about to have many users of mepa PHYs.

[HoratiuVultur]

Hi @vjardin,

I am not sure about this, we will need to talk more internally about this. Because I can see that you are kind of change the mesa-demo to talk only with PHYs if I understand correctly. This is just a demo APP on how to use the MESA and MEPA libraries and I think it would be best if you create your own APP that does exactly what you need and then just use the libraries.

Thanks,
/Horatiu

[vjardin]

It allows to support any applications with 3rd parties apps combined like a ptp (zls) daemon.

[HoratiuVultur]

It wouldn't make more sense to integrate the libraries in 3rd party apps?

[vjardin]

Which one ? It needs to be legacy to be used for any mepa's consumers (boards + zls + debug tools).

[vjardin]

draft notes of the upcoming updates

The purpose of the following update is to handle a PHY-only operation case: having
MEPA PHYs (for instance the LAN80xx 1G/10G/25G family) on a system that
has no Microchip switch such as evaluation boards, PTP daemons, debug
tooling, or a host SoC whose Ethernet MACs face the PHY directly.

This design is made of 3 layers:

1. the runtime PHY-only mode of mesa-demo (phy_only.c): PHY
   register access over /dev/spidev or a SPI proxy daemon;
2. the void MEBA board (meba/src/void/): a board layer with no
   switch and no fixed PHY population;
3. the optional MESA_PHY_ONLY build flavor: the application is
   built without any MESA switch chip library at all.

Each piece works with the previous ones:

• 1+2 alone still link a MESA chip library for its API symbols
• 1+2+3 remove it.

Design

Runtime PHY-only mode (mesa/demo/phy_only.c)

At startup mesa-demo probes for a switch UIO device. When none is
found (and a -P option is given), it enters PHY-only mode:

• the switch-only CLI/RPC modules are not initialized: only the PHY
  command set (PHY Dev Create/Del/Attach/conf, PHY EYE_DIAG,
  PHY TX_EQA/RX_EQA, PHY PRBS_*, PHY MCU *, serdes_get,
  Dev reset, ...);
• MESA register access is stubbed (phy_only_reg_read/write return an
  error: there is no switch);
• PHY register access is routed to the transport named by -P:
  • -P /dev/spidevB.C[@pad[@freq]][:ports] — for direct spidev;
  • -P proxy:<socket>[:ports] — then through the lan80xx-spid SPI
    proxy daemon (github.com/vjardin/mepa-spidev-proxy), which serializes
    concurrent users of the same PHY (the demo, a PTP daemon, debug
    tools) over one spidev.

The -P slot demultiplexes ports onto SPI channels. Several -P
options may be given if you have multiple PHYs.

The void board (meba/src/void/)

A MEBA board for PHY-only setups. It has no switch and no fixed PHY
population:

• port_cnt MEPA port slots (from the conf_get tag, default 4), all
  with phy_base_port = 0 (single-package anchor for mepa_link_base_port)

• MEBA_PHY_INITIALIZE wires the (empty) device table and the MEPA
  callouts, but it does not probe: with no fixed population there is
  nothing to detect, and the application creates each device
  explicitly (PHY Dev Create is the only path running the
  PRE/DEFAULT/POST reset sequence and SKU detection)

• PHY SPI register access is forwarded to the application-provided
  board_info accessors (meba_phy_spi_read/write), so the transport
  choice (spidev, proxy) stays in the application;

• MIIM/MMD go through the standard meba_generic callouts.

The callout wiring is shared with the probing boards through
meba_phy_callout_init(), factored out of meba_phy_driver_init().

The MESA_PHY_ONLY build flavor

Without it, the PHY-only app still links a MESA switch chip library purely to
satisfy the linker. -DMESA_PHY_ONLY=ON removes it.

The major benefit: the binary size shrinks of about 50%.

Build notes

For a basic build with PHY-only app with a MESA chip library
(as symbol filler):

cmake -B build -S . -DBUILD_MESA_DEMO=ON -Dapp_void=ON
cmake --build build --target app_void --target cli

For a MESA-less build:

cmake -B build -S . -DBUILD_MESA_DEMO=ON -DMESA_PHY_ONLY=ON -Dapp_void=ON
cmake --build build --target app_void --target cli

It produces build/mesa/demo/mesa-demo-void and build/mesa/demo/mesa-cmd.

Note: for static linkage, add -DCMAKE_EXE_LINKER_FLAGS=-static.

If needex, the external dependencies are the spidev header files and
the json library.

Run

Direct spidev (one user of the PHY):

./mesa-demo-void -f -P /dev/spidev0.1@2@5000000:4

Through the SPI proxy (many users of the PHY — demo + PTP daemon +
debug tools):

lan80xx-spid -d /dev/spidev0.1 -p 2 -s /var/run/spid.sock -r <reset-gpio-line>
./mesa-demo-void -f -P proxy:/var/run/spid.sock:4

At startup the demo prints the mode and the port span:

No switch UIO device found: PHY-only mode (MEPA slots over SPI only)
PHY-only board conf: port_cnt=4 (from the '-P' slots)

Then drive the PHY with mesa-cmd (CLI ports are 1-based; port 0 is
reserved). For example, the bring-up of one port, with a JSON port
configuration is:

mesa-cmd PHY Dev Create 1
mesa-cmd PHY Dev Attach 1 sfi
mesa-cmd PHY Dev conf 1 -f ch0.json
mesa-cmd PHY STATE 1
mesa-cmd PHY EYE_DIAG 1 fast host   # RX eye scan, host side