Add the generic LED and I2C-mux support needed to describe peripherals
behind the FPGA I2C controller, then use it to instantiate the R4006 and
Time Card V9 board topologies from software nodes.

Patches 1 and 2 add the binding and LED-class driver for the Lumissil
IS32FL3207. The driver supports individual and multicolor LEDs, enforces
per-output current limits, and keeps the controller shut down until every
channel has been configured.

Patch 3 propagates software-node channel descriptions to adapters created
by i2c-mux. It preserves an ACPI primary firmware node, makes I2C adapter
lookup recognize the attached secondary node, and keeps that node alive
through child-client teardown.

Patch 4 tracks the fixed-width board ID and serial number independently.
Profile selection can therefore proceed when the board ID is valid even
if the separate serial EEPROM is absent.

Patch 5 adds the reusable profile-driven topology and recovery lifecycle.
It stops topology work and removes the mux before the root I2C controller
unbinds, preventing new child creation after adapter teardown has begun.

Patch 6 adds the R4006 temperature, humidity, pressure, GNSS LED, and four
SMA LED groups. The BNO08x channel remains empty because no upstream driver
binds that device. Production R4006 IDs may carry a revision suffix.

Patch 7 adds the V9 BME280, BNO055, two GNSS LEDs, and four SMA LEDs. It
uses the exact fixed-width ID "TIMECARD-V9" because earlier revisions
expose the same detectable I2C devices with different LED routing.

The prerequisite patches touch DT bindings, LED, and I2C code. Reviews or
acks from those maintainers are requested so the complete dependency series
can be carried through net-next.

Hardware and build validation:
  - Exercised the R4006 LED routing on hardware.
  - Checked the V9 controller address, 4.7 kohm RISET, sequential RGB
    routing, and second GNSS LED against the V9 schematic.
  - Ran dt_binding_check for issi,is32fl3207.yaml.
  - Built i2c-core-base.o, i2c-mux.o, leds-is32fl3207.o, and ptp_ocp.o
    with W=1 for x86-64 and arm64 using defconfig and allmodconfig.
  - Ran strict checkpatch with an 80-column limit on all seven patches.
  - Applied the generated mailbox to the stated base and compared the
    resulting tree with the source branch.

Changes since v4:
  - Split EEPROM readiness, generic topology lifecycle, R4006, and V9 into
    separate patches.
  - Track board-ID and serial-number readiness independently and publish
    each field only after a successful EEPROM read.
  - Replace the atomic retry counter with worker-serialized state, bounded
    logging, and synchronized root-controller teardown.
  - Support multicolor groups whose final components use outputs 16 and 17,
    and document current limits relative to the RISET-derived full scale.
  - Serialize multicolor calculation, PWM updates, and controller shutdown.
  - Match secondary software nodes while preserving an ACPI primary, and
    balance software-node ownership on failure and teardown paths.
  - Clarify that the BNO08x and LM75B at address 0x4a occupy different mux
    channels.
  - Rebase onto current net-next.

v4:
https://lore.kernel.org/r/cover.1786543681.git.ahmadexp@gmail.com/

Review of v4 patch 4:
https://lore.kernel.org/r/62242142-0d27-425c-88d6-db65e80bbcea@linux.dev/

Ahmad Byagowi (7):
  dt-bindings: leds: Add IS32FL3207 controller
  leds: is32fl3207: Add controller driver
  i2c: mux: Propagate software nodes to channel adapters
  ptp: ocp: Track EEPROM fields independently
  ptp: ocp: Add profile-driven I2C topology support
  ptp: ocp: Add R4006 I2C peripheral topology
  ptp: ocp: Add Time Card V9 I2C peripheral topology

 .../bindings/leds/issi,is32fl3207.yaml        |  281 +++++
 MAINTAINERS                                   |    7 +
 drivers/i2c/i2c-core-base.c                   |   24 +-
 drivers/i2c/i2c-mux.c                         |   77 +-
 drivers/leds/rgb/Kconfig                      |   11 +
 drivers/leds/rgb/Makefile                     |    1 +
 drivers/leds/rgb/leds-is32fl3207.c            |  736 ++++++++++++
 drivers/ptp/ptp_ocp.c                         | 1025 +++++++++++++++--
 8 files changed, 2083 insertions(+), 79 deletions(-)
base-commit: e6a5d573d24cd375e09d24f136523cb3cc85c9d3
-- 
2.50.1 (Apple Git-155)

On Fri, 14 Aug 2026 16:10:48 -0700 Ahmad Byagowi wrote:
> Add the generic LED and I2C-mux support needed to describe peripherals
> behind the FPGA I2C controller, then use it to instantiate the R4006 and
> Time Card V9 board topologies from software nodes.

Ahmad, could you explain why? What are you going to do with these LEDs
as a end user?

The influx of the LLM generated patches has a hugely negative impact on
the community.

Hi Jakub,

These RGB LEDs have been part of the Time Card hardware since the
original design, beside the four SMA connectors and the GNSS inputs.
We never had the opportunity to add Linux driver support, so they have
remained unused under Linux.

There is recurring confusion about which logical SMA number
corresponds to which physical connector and how each connector is
configured. The LEDs address a similar operational need to ethtool -p:
they help an operator correlate a logical interface with the physical
connector. Their colors can also represent the SMA input/output
configuration and timing status, together with GNSS fix or lock
status.

This series exposes the LEDs through the standard LED class, avoiding
board-specific raw I2C commands. The generic LED controller driver
provides the standard interface, while the board-specific status
policy remains outside that driver. The second GNSS LED supports the
card variant with a second receiver.

I should have stated this existing hardware and end-user use case
explicitly in the cover letter. I will add it to the next revision.

On Tue, Aug 18, 2026 at 9:56 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 14 Aug 2026 16:10:48 -0700 Ahmad Byagowi wrote:
> > Add the generic LED and I2C-mux support needed to describe peripherals
> > behind the FPGA I2C controller, then use it to instantiate the R4006 and
> > Time Card V9 board topologies from software nodes.
>
> Ahmad, could you explain why? What are you going to do with these LEDs
> as a end user?
>
> The influx of the LLM generated patches has a hugely negative impact on
> the community.



-- 
73
With best wishes / Mit herzlichsten Grüßen
Ahmad Byagowi, Ph.D., Dr. Techn., P.Eng.
Phone: +1 (650) 924 6653

 Please consider the environment before printing this e-mail.

On Tue, 18 Aug 2026 11:12:35 -0700 Ahmad Byagowi wrote:
> I should have stated this existing hardware and end-user use case
> explicitly in the cover letter. I will add it to the next revision.

You need to send the leds and i2c patches to relevant trees first.
We won't take them via net-next.

Understood. I will split the series and send the IS32FL3207 binding
and driver through the LED tree, and the I2C mux changes through the
I2C tree. Once those prerequisites land, I will rebase and resend only
the ptp_ocp board-profile changes to net-next.

Thanks for the clarification.



On Thu, Aug 20, 2026 at 10:03 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 18 Aug 2026 11:12:35 -0700 Ahmad Byagowi wrote:
> > I should have stated this existing hardware and end-user use case
> > explicitly in the cover letter. I will add it to the next revision.
>
> You need to send the leds and i2c patches to relevant trees first.
> We won't take them via net-next.



--
73
With best wishes / Mit herzlichsten Grüßen
Ahmad Byagowi, Ph.D., Dr. Techn., P.Eng.
Phone: +1 (650) 924 6653

 Please consider the environment before printing this e-mail.