From: Ahmad Byagowi <ahmadexp@gmail.com>
To: linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-i2c@vger.kernel.org, netdev@vger.kernel.org
Cc: Lee Jones <lee@kernel.org>, Pavel Machek <pavel@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Andi Shyti <andi.shyti@kernel.org>,
Peter Rosin <peda@lysator.liu.se>,
Nam Tran <trannamatk@gmail.com>,
Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Richard Cochran <richardcochran@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Kees Cook <kees@kernel.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC net-next v2 0/6] ptp: ocp: Add R4006 and V9 I2C peripheral support
Date: Mon, 3 Aug 2026 13:50:05 -0700 [thread overview]
Message-ID: <20260803205011.1249-1-ahmadexp@gmail.com> (raw)
R4006 and Time Card V9 place an I2C mux behind the FPGA XIIC
controller. The current ptp_ocp driver exposes the root adapter but does
not describe the peripherals behind the mux.
This series adds the generic infrastructure and board profiles needed
for existing subsystem drivers to bind to those peripherals:
1. A binding for the Lumissil IS32FL3207 18-channel LED controller.
2. An IS32FL3207 LED class driver with individual and multicolor LED
support and per-output current limits.
3. Software-node propagation from an I2C mux to its channel adapters.
4. Validation of the fixed-width EEPROM board identifier.
5. An R4006 profile for its sensors and GNSS/SMA LEDs.
6. A Time Card V9 profile for its BME280, BNO055, GNSS1, GNSS2, and
four SMA LEDs.
Profile selection is deliberately fail-closed. PCI IDs are shared by
multiple PCB revisions, so only a validated EEPROM board identifier may
select a topology. Erased, malformed, and unknown identifiers leave the
downstream devices unconfigured. R4006 identifiers are matched by their
R4006 prefix, while Time Card V9 requires the exact "TIMECARD-V9"
identifier.
The R4006 BNO08x is intentionally not instantiated because no upstream
driver exists for it. LED status policy remains in userspace; this
series exposes standard multicolor LED class devices.
The EEPROM validation patch fixes a pre-existing out-of-bounds string
read and carries Fixes and stable trailers. It is included because safe
board identification is a prerequisite for the profiles. That patch can
travel separately through the net tree if preferred.
Validation performed:
- dt_binding_check, including YAML lint and example compilation
- x86-64 and arm64 W=1 builds of the modified driver objects
- strict checkpatch and git diff --check
- R4006 addresses and LED routing exercised with the downstream
implementation
- Time Card V9 BME280, BNO055, mux, and LED-controller addresses
verified directly on hardware
The complete upstream series has not yet been boot-tested on an R4006.
The V9 test card has an erased EEPROM and was intentionally left
unchanged, so automatic V9 profile selection was not exercised. Its LED
controller responded, but the outputs reported open-load status on that
board, so physical LED illumination could not be validated. The test
distribution also lacked the BME280 and BNO055 modules.
Questions for this RFC:
- Should IS32FL3207 remain a standalone multicolor driver, or be
integrated into the existing is31fl32xx driver?
- Is assigning software-node channel children in the generic I2C mux
core the preferred representation for PCI-card mux topologies?
- Should net-next carry the complete series after DT, LED, and I2C
review, or should the prerequisite patches travel separately?
Changes since RFC v1:
- Correct the documented PWM resolution and support standard LED
startup and retained-shutdown state properties.
- Use a named I2C ID initializer and fix MAINTAINERS ordering.
- Move EEPROM validation into a separate prerequisite fix.
- Select profiles only from validated EEPROM identifiers.
- Rework the R4006 implementation into reusable board profiles.
- Bound asynchronous retries and serialize topology population with
controller and mux driver bind/unbind.
- Avoid repeated managed allocations during retry.
- Add the Time Card V9 profile, including the second GNSS LED.
- Leave the I2C mux software-node propagation patch unchanged.
RFC v1:
https://lore.kernel.org/r/cover.1785684064.git.ahmadexp@gmail.com/
Ahmad Byagowi (6):
dt-bindings: leds: Add IS32FL3207 controller
leds: rgb: Add IS32FL3207 controller driver
i2c: mux: Propagate software nodes to channel adapters
ptp: ocp: Validate EEPROM board IDs
ptp: ocp: Add R4006 I2C peripheral topology
ptp: ocp: Add Time Card V9 I2C peripheral topology
.../bindings/leds/issi,is32fl3207.yaml | 208 +++++
MAINTAINERS | 7 +
drivers/i2c/i2c-mux.c | 55 ++
drivers/leds/rgb/Kconfig | 11 +
drivers/leds/rgb/Makefile | 1 +
drivers/leds/rgb/leds-is32fl3207.c | 580 ++++++++++++
drivers/ptp/ptp_ocp.c | 871 +++++++++++++++++-
7 files changed, 1687 insertions(+), 46 deletions(-)
create mode 100644 Documentation/devicetree/bindings/leds/issi,is32fl3207.yaml
create mode 100644 drivers/leds/rgb/leds-is32fl3207.c
base-commit: 69963a0678a347d57c4ac8b16939dba216eb95ce
--
2.50.1 (Apple Git-155)
next reply other threads:[~2026-08-03 20:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 20:50 Ahmad Byagowi [this message]
2026-08-03 20:50 ` [RFC net-next v2 1/6] dt-bindings: leds: Add IS32FL3207 controller Ahmad Byagowi
2026-08-03 20:50 ` [RFC net-next v2 2/6] leds: rgb: Add IS32FL3207 controller driver Ahmad Byagowi
2026-08-03 20:50 ` [RFC net-next v2 3/6] i2c: mux: Propagate software nodes to channel adapters Ahmad Byagowi
2026-08-03 20:50 ` [RFC net-next v2 4/6] ptp: ocp: Validate EEPROM board IDs Ahmad Byagowi
2026-08-03 20:50 ` [RFC net-next v2 5/6] ptp: ocp: Add R4006 I2C peripheral topology Ahmad Byagowi
2026-08-03 20:50 ` [RFC net-next v2 6/6] ptp: ocp: Add Time Card V9 " Ahmad Byagowi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260803205011.1249-1-ahmadexp@gmail.com \
--to=ahmadexp@gmail.com \
--cc=andi.shyti@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=gustavoars@kernel.org \
--cc=kees@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=lee@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavel@kernel.org \
--cc=peda@lysator.liu.se \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
--cc=trannamatk@gmail.com \
--cc=vadim.fedorenko@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox