[10/21] net: phy: add X-Powers AC200 EPHY control driver
Commit Message
The AC200 Fast Ethernet PHY is powered and configured through registers
in the parent I2C regmap before its Clause 22 link registers become usable.
Add a control driver that prepares the calibration value and vendor
offset, interface mode and input-clock selection. Use an optional SoC SID
cell when supplied, otherwise read the AC200's internal calibration eFuse.
Derive the documented 24 or 27 MHz selector from the actual locked clock
rate. Although the feature summary also mentions 25 MHz, EPHY_CTL provides
no encoding for it, so reject that rate rather than silently selecting
27 MHz.
Program the link PHY MDIO address into EPHY_CTL.PHY_ADDR before bringing
the PHY out of its disabled state using the vendor initialization sequence.
Expose serialized, idempotent power-on and power-off operations so the
link-PHY driver can sequence the control block across resets and system
sleep. Also expose operations for the global LED polarity and package pad
enables. Initialize all three outputs active-low as in the vendor kernel,
while allowing an explicit link-PHY LED topology to replace that fallback.
Quiesce the block during probe failures, driver removal and system
shutdown.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
drivers/net/phy/Kconfig | 9 +
drivers/net/phy/Makefile | 1 +
drivers/net/phy/xpowers-ac200-ctl.c | 330 ++++++++++++++++++++++++++++++++++++
drivers/net/phy/xpowers-acx00.h | 25 +++
4 files changed, 365 insertions(+)
Comments
> +static int
> +ac200_ephy_ctl_set_led_outputs(struct acx00_ephy_control *control,
> + unsigned long outputs)
> +{
> +}
> +static int
> +ac200_ephy_ctl_set_led_polarity(struct acx00_ephy_control *control,
> + bool active_low)
> +{
> +}
I've not looked into the details, but these look like pinmux. Does
this I2C device have a GPIO controller? Can these pins be used for
other things than LEDs? Maybe you should be implementing a GPIO and
pinmux driver. The Ethernet PHY driver can then just select the
correct pinmux configuration.
> +static int ac200_ephy_ctl_power_off_locked(struct ac200_ephy_ctl *priv)
> +{
> +}
> +
> +static int ac200_ephy_ctl_power_off(struct acx00_ephy_control *control)
> +{
> +}
> +
> +static int ac200_ephy_ctl_power_on(struct acx00_ephy_control *control,
> + unsigned int phy_addr)
> +{
> +}
These look like a regulator? The phylib core has support for
regulators.
Maybe take a step back and look at the overall architecture, and how
Linux can represent these blocks.
Andrew
On Mon, Aug 3, 2026 at 7:51 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > +static int
> > +ac200_ephy_ctl_set_led_outputs(struct acx00_ephy_control *control,
> > + unsigned long outputs)
> > +{
> > +}
>
> > +static int
> > +ac200_ephy_ctl_set_led_polarity(struct acx00_ephy_control *control,
> > + bool active_low)
> > +{
> > +}
>
> I've not looked into the details, but these look like pinmux. Does
> this I2C device have a GPIO controller? Can these pins be used for
> other things than LEDs? Maybe you should be implementing a GPIO and
> pinmux driver. The Ethernet PHY driver can then just select the
> correct pinmux configuration.
These do not appear to be GPIO or muxable pins. The AC200
documentation describes them as three dedicated EPHY LED
outputs: link/activity, speed, and duplex. The bits in SYS_EPHY_CTL1
enable those output pads, while EPHY_CTL provides their shared
polarity setting. I have not found any documented GPIO data
registers or alternative functions for these pins.
Therefore, implementing a GPIO controller would expose capabilities
the hardware does not have, and a pinmux driver would only provide
a single fixed function. The callbacks exist because the LED function
belongs to the PHY, while the pad-enable and polarity registers are
reached through the AC200 I2C regmap rather than the PHY’s MDIO
registers.
>
> > +static int ac200_ephy_ctl_power_off_locked(struct ac200_ephy_ctl *priv)
> > +{
> > +}
> > +
> > +static int ac200_ephy_ctl_power_off(struct acx00_ephy_control *control)
> > +{
>
> > +}
> > +
> > +static int ac200_ephy_ctl_power_on(struct acx00_ephy_control *control,
> > + unsigned int phy_addr)
> > +{
> > +}
>
> These look like a regulator? The phylib core has support for
> regulators.
The external supplies are already represented as regulators. These callbacks
do more than enable a supply: they sequence the package clock, reset and
shutdown controls, then program the PHY address, calibration and interface
state required before the normal Clause 22 endpoint becomes usable.
> Maybe take a step back and look at the overall architecture, and how
> Linux can represent these blocks.
>
> Andrew
On Mon, Aug 03, 2026 at 10:09:01AM -0600, James Hilliard wrote:
> On Mon, Aug 3, 2026 at 7:51 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > > +static int
> > > +ac200_ephy_ctl_set_led_outputs(struct acx00_ephy_control *control,
> > > + unsigned long outputs)
> > > +{
> > > +}
> >
> > > +static int
> > > +ac200_ephy_ctl_set_led_polarity(struct acx00_ephy_control *control,
> > > + bool active_low)
> > > +{
> > > +}
> >
> > I've not looked into the details, but these look like pinmux. Does
> > this I2C device have a GPIO controller? Can these pins be used for
> > other things than LEDs? Maybe you should be implementing a GPIO and
> > pinmux driver. The Ethernet PHY driver can then just select the
> > correct pinmux configuration.
>
> These do not appear to be GPIO or muxable pins. The AC200
> documentation describes them as three dedicated EPHY LED
> outputs: link/activity, speed, and duplex. The bits in SYS_EPHY_CTL1
> enable those output pads, while EPHY_CTL provides their shared
> polarity setting. I have not found any documented GPIO data
> registers or alternative functions for these pins.
So what i'm trying to do with both of these is make it look more like
standard Linux building blocks.
If that is not possible, i would actually put all this code into the
PHY driver. You then have a regmap property to gain access to the I2C
registers.
Andrew
On Mon, Aug 3, 2026 at 11:57 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Mon, Aug 03, 2026 at 10:09:01AM -0600, James Hilliard wrote:
> > On Mon, Aug 3, 2026 at 7:51 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > > +static int
> > > > +ac200_ephy_ctl_set_led_outputs(struct acx00_ephy_control *control,
> > > > + unsigned long outputs)
> > > > +{
> > > > +}
> > >
> > > > +static int
> > > > +ac200_ephy_ctl_set_led_polarity(struct acx00_ephy_control *control,
> > > > + bool active_low)
> > > > +{
> > > > +}
> > >
> > > I've not looked into the details, but these look like pinmux. Does
> > > this I2C device have a GPIO controller? Can these pins be used for
> > > other things than LEDs? Maybe you should be implementing a GPIO and
> > > pinmux driver. The Ethernet PHY driver can then just select the
> > > correct pinmux configuration.
> >
> > These do not appear to be GPIO or muxable pins. The AC200
> > documentation describes them as three dedicated EPHY LED
> > outputs: link/activity, speed, and duplex. The bits in SYS_EPHY_CTL1
> > enable those output pads, while EPHY_CTL provides their shared
> > polarity setting. I have not found any documented GPIO data
> > registers or alternative functions for these pins.
>
> So what i'm trying to do with both of these is make it look more like
> standard Linux building blocks.
>
> If that is not possible, i would actually put all this code into the
> PHY driver. You then have a regmap property to gain access to the I2C
> registers.
I understand the goal of using standard Linux building blocks where they
fit, but I do not think folding these control paths into the common PHY
driver gives the right device model here.
The AC200 and AC300 expose the same Clause 22 PHY interface, but their
control functions are separate devices with different transports and
lifetimes. The AC200 control function is an MFD child accessed through
the parent I2C regmap. The AC300 control function is a separately
addressed non-PHY MDIO device. A regmap reference only describes the
AC200 transport; it does not represent the AC300 control device.
Folding both implementations into the common PHY driver would make that
driver manage AC200 MFD registers and resources as well as an AC300 MDIO
control endpoint. That would mix the package-specific control transports
with the otherwise common Clause 22 implementation.
The current split uses standard subsystems wherever they provide a
matching abstraction: MFD, regmap, MDIO devices, clocks, regulators,
NVMEM, device links, and the PHY LED framework. The narrow private
interface covers only the compound operation which those frameworks
cannot express: calibrating, addressing, configuring, and sequencing the
package control block before the Clause 22 interface becomes usable.
The link address is an important example. It is defined once by
phydev->mdio.addr. AC200 must program that value through its I2C control
interface, while AC300 must validate it against the address of its MDIO
control endpoint. Generic PHY operations do not carry a consumer MDIO
address. Encoding it in a phys specifier or control-node property would
duplicate the PHY node's reg value. Giving the common PHY driver a raw
regmap avoids passing the address only by moving the provider-specific
implementation across the driver boundary.
The LED pad-enable and polarity bits are similarly part of the package
control function. They control dedicated EPHY outputs rather than GPIOs
or muxable pins. The common PHY driver still owns the PHY LED semantics,
while the selected control driver performs the package-specific register
access.
For those reasons, I think keeping the transport-specific control drivers
and the common Clause 22 PHY driver separate is the cleaner division.
>
> Andrew
>
On Tue, Aug 4, 2026 at 2:45 AM James Hilliard <james.hilliard1@gmail.com> wrote:
>
> On Mon, Aug 3, 2026 at 11:57 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > On Mon, Aug 03, 2026 at 10:09:01AM -0600, James Hilliard wrote:
> > > On Mon, Aug 3, 2026 at 7:51 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > > >
> > > > > +static int
> > > > > +ac200_ephy_ctl_set_led_outputs(struct acx00_ephy_control *control,
> > > > > + unsigned long outputs)
> > > > > +{
> > > > > +}
> > > >
> > > > > +static int
> > > > > +ac200_ephy_ctl_set_led_polarity(struct acx00_ephy_control *control,
> > > > > + bool active_low)
> > > > > +{
> > > > > +}
> > > >
> > > > I've not looked into the details, but these look like pinmux. Does
> > > > this I2C device have a GPIO controller? Can these pins be used for
> > > > other things than LEDs? Maybe you should be implementing a GPIO and
> > > > pinmux driver. The Ethernet PHY driver can then just select the
> > > > correct pinmux configuration.
> > >
> > > These do not appear to be GPIO or muxable pins. The AC200
> > > documentation describes them as three dedicated EPHY LED
> > > outputs: link/activity, speed, and duplex. The bits in SYS_EPHY_CTL1
> > > enable those output pads, while EPHY_CTL provides their shared
> > > polarity setting. I have not found any documented GPIO data
> > > registers or alternative functions for these pins.
> >
> > So what i'm trying to do with both of these is make it look more like
> > standard Linux building blocks.
> >
> > If that is not possible, i would actually put all this code into the
> > PHY driver. You then have a regmap property to gain access to the I2C
> > registers.
>
> I understand the goal of using standard Linux building blocks where they
> fit, but I do not think folding these control paths into the common PHY
> driver gives the right device model here.
>
> The AC200 and AC300 expose the same Clause 22 PHY interface, but their
> control functions are separate devices with different transports and
> lifetimes. The AC200 control function is an MFD child accessed through
> the parent I2C regmap. The AC300 control function is a separately
> addressed non-PHY MDIO device. A regmap reference only describes the
> AC200 transport; it does not represent the AC300 control device.
>
> Folding both implementations into the common PHY driver would make that
> driver manage AC200 MFD registers and resources as well as an AC300 MDIO
> control endpoint. That would mix the package-specific control transports
> with the otherwise common Clause 22 implementation.
>
> The current split uses standard subsystems wherever they provide a
> matching abstraction: MFD, regmap, MDIO devices, clocks, regulators,
> NVMEM, device links, and the PHY LED framework. The narrow private
> interface covers only the compound operation which those frameworks
> cannot express: calibrating, addressing, configuring, and sequencing the
> package control block before the Clause 22 interface becomes usable.
>
> The link address is an important example. It is defined once by
> phydev->mdio.addr. AC200 must program that value through its I2C control
> interface, while AC300 must validate it against the address of its MDIO
> control endpoint. Generic PHY operations do not carry a consumer MDIO
> address. Encoding it in a phys specifier or control-node property would
> duplicate the PHY node's reg value. Giving the common PHY driver a raw
> regmap avoids passing the address only by moving the provider-specific
> implementation across the driver boundary.
>
> The LED pad-enable and polarity bits are similarly part of the package
> control function. They control dedicated EPHY outputs rather than GPIOs
> or muxable pins. The common PHY driver still owns the PHY LED semantics,
> while the selected control driver performs the package-specific register
> access.
>
> For those reasons, I think keeping the transport-specific control drivers
> and the common Clause 22 PHY driver separate is the cleaner division.
I think what Andrew is saying is that you can expose the regmap from the
MFD node, which you then reference from the PHY node with a custom phandle.
In the PHY driver, the first thing to do is retrieve the syscon, and if it
is not available yet, return -EPROBE_DEFER. Then you program all the bits
you currently do, just without going through a layer of redirection.
You can fetch the PHY address to program from the device tree. The downside
to doing all the setup in the PHY driver is that the PHY node has to have
the PHY ID in the compatible, as it is no longer generic. But you already
have that.
ChenYu
> > So what i'm trying to do with both of these is make it look more like
> > standard Linux building blocks.
> >
> > If that is not possible, i would actually put all this code into the
> > PHY driver. You then have a regmap property to gain access to the I2C
> > registers.
>
> I understand the goal of using standard Linux building blocks where they
> fit, but I do not think folding these control paths into the common PHY
> driver gives the right device model here.
>
> The AC200 and AC300 expose the same Clause 22 PHY interface, but their
> control functions are separate devices with different transports and
> lifetimes. The AC200 control function is an MFD child accessed through
> the parent I2C regmap. The AC300 control function is a separately
> addressed non-PHY MDIO device. A regmap reference only describes the
> AC200 transport; it does not represent the AC300 control device.
>
> Folding both implementations into the common PHY driver would make that
> driver manage AC200 MFD registers and resources as well as an AC300 MDIO
> control endpoint. That would mix the package-specific control transports
> with the otherwise common Clause 22 implementation.
Given how messy this hardware is, i doubt it is discoverable. We have
been pushing back on hacks to enable various things before probe in
order to make it discoverable. So you are going to end up putting IDs
in DT so that the driver probes without it being discovered. That
means you can put any ID you want in DT, and the driver. So you have
two different phy driver structs, two different probe functions, etc.
Andrew
On Mon, Aug 3, 2026 at 8:07 PM Chen-Yu Tsai <wens@kernel.org> wrote:
>
> On Tue, Aug 4, 2026 at 2:45 AM James Hilliard <james.hilliard1@gmail.com> wrote:
> >
> > On Mon, Aug 3, 2026 at 11:57 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > On Mon, Aug 03, 2026 at 10:09:01AM -0600, James Hilliard wrote:
> > > > On Mon, Aug 3, 2026 at 7:51 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > > > >
> > > > > > +static int
> > > > > > +ac200_ephy_ctl_set_led_outputs(struct acx00_ephy_control *control,
> > > > > > + unsigned long outputs)
> > > > > > +{
> > > > > > +}
> > > > >
> > > > > > +static int
> > > > > > +ac200_ephy_ctl_set_led_polarity(struct acx00_ephy_control *control,
> > > > > > + bool active_low)
> > > > > > +{
> > > > > > +}
> > > > >
> > > > > I've not looked into the details, but these look like pinmux. Does
> > > > > this I2C device have a GPIO controller? Can these pins be used for
> > > > > other things than LEDs? Maybe you should be implementing a GPIO and
> > > > > pinmux driver. The Ethernet PHY driver can then just select the
> > > > > correct pinmux configuration.
> > > >
> > > > These do not appear to be GPIO or muxable pins. The AC200
> > > > documentation describes them as three dedicated EPHY LED
> > > > outputs: link/activity, speed, and duplex. The bits in SYS_EPHY_CTL1
> > > > enable those output pads, while EPHY_CTL provides their shared
> > > > polarity setting. I have not found any documented GPIO data
> > > > registers or alternative functions for these pins.
> > >
> > > So what i'm trying to do with both of these is make it look more like
> > > standard Linux building blocks.
> > >
> > > If that is not possible, i would actually put all this code into the
> > > PHY driver. You then have a regmap property to gain access to the I2C
> > > registers.
> >
> > I understand the goal of using standard Linux building blocks where they
> > fit, but I do not think folding these control paths into the common PHY
> > driver gives the right device model here.
> >
> > The AC200 and AC300 expose the same Clause 22 PHY interface, but their
> > control functions are separate devices with different transports and
> > lifetimes. The AC200 control function is an MFD child accessed through
> > the parent I2C regmap. The AC300 control function is a separately
> > addressed non-PHY MDIO device. A regmap reference only describes the
> > AC200 transport; it does not represent the AC300 control device.
> >
> > Folding both implementations into the common PHY driver would make that
> > driver manage AC200 MFD registers and resources as well as an AC300 MDIO
> > control endpoint. That would mix the package-specific control transports
> > with the otherwise common Clause 22 implementation.
> >
> > The current split uses standard subsystems wherever they provide a
> > matching abstraction: MFD, regmap, MDIO devices, clocks, regulators,
> > NVMEM, device links, and the PHY LED framework. The narrow private
> > interface covers only the compound operation which those frameworks
> > cannot express: calibrating, addressing, configuring, and sequencing the
> > package control block before the Clause 22 interface becomes usable.
> >
> > The link address is an important example. It is defined once by
> > phydev->mdio.addr. AC200 must program that value through its I2C control
> > interface, while AC300 must validate it against the address of its MDIO
> > control endpoint. Generic PHY operations do not carry a consumer MDIO
> > address. Encoding it in a phys specifier or control-node property would
> > duplicate the PHY node's reg value. Giving the common PHY driver a raw
> > regmap avoids passing the address only by moving the provider-specific
> > implementation across the driver boundary.
> >
> > The LED pad-enable and polarity bits are similarly part of the package
> > control function. They control dedicated EPHY outputs rather than GPIOs
> > or muxable pins. The common PHY driver still owns the PHY LED semantics,
> > while the selected control driver performs the package-specific register
> > access.
> >
> > For those reasons, I think keeping the transport-specific control drivers
> > and the common Clause 22 PHY driver separate is the cleaner division.
>
> I think what Andrew is saying is that you can expose the regmap from the
> MFD node, which you then reference from the PHY node with a custom phandle.
>
> In the PHY driver, the first thing to do is retrieve the syscon, and if it
> is not available yet, return -EPROBE_DEFER. Then you program all the bits
> you currently do, just without going through a layer of redirection.
> You can fetch the PHY address to program from the device tree. The downside
> to doing all the setup in the PHY driver is that the PHY node has to have
> the PHY ID in the compatible, as it is no longer generic. But you already
> have that.
I agree that direct regmap access would be reasonable for an
AC200-only driver, but I do not think it is a good fit for the
combined AC200/AC300 case.
The proposed phandle only models AC200. AC300 has no corresponding
MFD regmap: its control block is a separate non-PHY Clause 22
endpoint, with its own clock, regulator and sequencing requirements.
Folding everything into the link-PHY driver would therefore still
require two transport-specific implementations -- raw AC200 I2C
regmap access and raw AC300 MDIO access -- plus conditional resource
acquisition and cleanup. It would remove the function-pointer calls,
but merely replace them with AC200/AC300 branches throughout the
common driver.
This also matters for boards sharing one board identity but
containing either package, as selected by SID. Fixed boards can
reference one control provider, while variant boards can reference
both and let the common link-PHY driver select exactly one. The
selected provider then owns its transport-specific resources and
lifetime. That avoids making an MDIO PHY driver directly manage an
I2C MFD function on one system and a second MDIO device on another.
The control interface is also used for more than initial probe. It
participates in suspend/resume and reset sequencing, interface-mode
changes once the MAC attaches, and package LED-pad configuration.
Consequently, exposing a raw regmap would not reduce this to a
one-time register setup; the common driver would still need
package-specific implementations of all those operations.
The PHY address should not be read from firmware again. The MDIO core
has already parsed reg, and the authoritative address is
phydev->mdio.addr. Passing that address to the selected provider
avoids duplicating or independently interpreting the firmware
description. Similarly, the forced ethernet-phy-id0044.1400
compatible is required in either design because the identification
registers are inaccessible until the package control block has been
initialized; it is not a consequence of using a separate control
driver.
Also, AC200 is an I2C MFD rather than a syscon. Exposing its regmap as
a syscon solely so another bus device can perform raw accesses would
blur the ownership of the AC200 function.
The private interface is intentionally narrow: it contains only the
operations whose implementation differs between the two packages,
while all normal Clause 22 behavior remains in one shared PHY driver.
Given the AC200-only, AC300-only and runtime-selected board
configurations, I think that separation provides a cleaner boundary
than moving both control backends into the common link-PHY driver.
On Mon, Aug 3, 2026 at 8:22 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > So what i'm trying to do with both of these is make it look more like
> > > standard Linux building blocks.
> > >
> > > If that is not possible, i would actually put all this code into the
> > > PHY driver. You then have a regmap property to gain access to the I2C
> > > registers.
> >
> > I understand the goal of using standard Linux building blocks where they
> > fit, but I do not think folding these control paths into the common PHY
> > driver gives the right device model here.
> >
> > The AC200 and AC300 expose the same Clause 22 PHY interface, but their
> > control functions are separate devices with different transports and
> > lifetimes. The AC200 control function is an MFD child accessed through
> > the parent I2C regmap. The AC300 control function is a separately
> > addressed non-PHY MDIO device. A regmap reference only describes the
> > AC200 transport; it does not represent the AC300 control device.
> >
> > Folding both implementations into the common PHY driver would make that
> > driver manage AC200 MFD registers and resources as well as an AC300 MDIO
> > control endpoint. That would mix the package-specific control transports
> > with the otherwise common Clause 22 implementation.
>
> Given how messy this hardware is, i doubt it is discoverable. We have
> been pushing back on hacks to enable various things before probe in
> order to make it discoverable. So you are going to end up putting IDs
> in DT so that the driver probes without it being discovered. That
> means you can put any ID you want in DT, and the driver. So you have
> two different phy driver structs, two different probe functions, etc.
I agree that the link PHY cannot be identified by reading its
registers before the package control sequence has run. I do not agree
that this means an arbitrary ID should be placed in DT, though.
The Ethernet PHY binding explicitly defines
ethernet-phy-idAAAA.BBBB as the correct contents of the PHY identifier
registers. It also documents using that compatible when clocks,
resets, supplies, or another initialization sequence must be applied
before those registers can be read. That is exactly our situation, so
ethernet-phy-id0044.1400 lets phylib create the phy_device without an
initial MDIO read. Once the selected control provider has powered the
hardware, the driver can read MII_PHYSID1 and MII_PHYSID2 and validate
that ID.
Both AC200 and AC300 expose the same link-side PHY ID and register
layout. The package choice changes how that PHY is initialized, not
the identity of the link PHY itself. Inventing separate IDs would turn
the compatible into a Linux driver selector and would describe values
which the hardware never reports.
The package variant is discoverable independently through the SID
configuration field. Fixed boards can reference one control provider,
while boards shipped with either package can use SID to select between
the AC200 I2C control provider and the AC300 MDIO control provider.
For that reason, I do not think two phy_driver structures and two PHY
probe functions model the hardware correctly. There is one common
link PHY, so its Clause 22 implementation should remain in one PHY
driver. The two different implementations belong at the control
endpoints, where AC200 and AC300 genuinely differ in transport,
resources, and lifetime.
> I agree that the link PHY cannot be identified by reading its
> registers before the package control sequence has run. I do not agree
> that this means an arbitrary ID should be placed in DT, though.
The ability to put the ID in DT is there for two reasons:
1) You cannot enumerate the PHY because of missing clocks etc.
2) The vendor messed up, and did not put a valid ID in registers 2 and 3.
2 does not happen very often, but this is one example. They are
different PHYs, they need different driver code, when you consider the
PHY as a whole.
I also wound not put in an arbitrary ID, pick an unused ID in the
vendors range.
> Both AC200 and AC300 expose the same link-side PHY ID and register
> layout.
No they don't. There are extra registers in different address domains.
Andrew
On Tue, Aug 4, 2026 at 8:54 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > I agree that the link PHY cannot be identified by reading its
> > registers before the package control sequence has run. I do not agree
> > that this means an arbitrary ID should be placed in DT, though.
>
> The ability to put the ID in DT is there for two reasons:
>
> 1) You cannot enumerate the PHY because of missing clocks etc.
> 2) The vendor messed up, and did not put a valid ID in registers 2 and 3.
>
> 2 does not happen very often, but this is one example. They are
> different PHYs, they need different driver code, when you consider the
> PHY as a whole.
>
> I also wound not put in an arbitrary ID, pick an unused ID in the
> vendors range.
The value currently used in DT is not arbitrary: 0x00441400 is exactly
what both link-side Clause 22 endpoints report from registers 2 and 3
after the corresponding package control sequence has run. This is case
(1), rather than case (2): the ID cannot initially be read because the
EPHY has not yet been clocked, configured and released from reset.
The reported ID does not distinguish the two packages, but replacing it
with a synthetic unused ID would make an ethernet-phy-idAAAA.BBBB
compatible disagree with the value actually reported by registers 2 and
3. If separate AC200 and AC300 PHY driver entries are needed to identify
the complete package variants, they can use package-specific match data
while sharing the common link-PHY implementation.
>
> > Both AC200 and AC300 expose the same link-side PHY ID and register
> > layout.
>
> No they don't. There are extra registers in different address domains.
The block diagrams make the distinction clearer. Both diagrams depict
an EPHY block with the same internal organization: MII/RMII, auto
negotiation, auto-MDIX, 10/100 TX and RX PCS/PMA blocks, LED logic,
clock/reset, PLL and EPHY AFE.
What differs is the surrounding top-level control path. In AC200,
E_MDC/E_MDIO connect directly to the EPHY, while the package control
logic and registers are reached separately through RSB/TWI. In AC300,
the external MDC/MDIO pins first enter a top-level MDIO slave and
register block, which then provides internal MDC/MDIO connections to
the EPHY. That top-level block also contains the AC300-specific reset,
clock, I/O and eFuse controls.
Therefore, I agree that saying the complete register layouts are the
same was too broad. The packages have different top-level control
registers in different address domains, but the diagrams indicate that
they contain the same link-facing EPHY implementation. That maps
naturally to shared link-PHY code with separate AC200 and AC300 control
backends, rather than two copies of the common EPHY implementation.
>
> Andrew
> > No they don't. There are extra registers in different address domains.
>
> The block diagrams make the distinction clearer. Both diagrams depict
> an EPHY block with the same internal organization: MII/RMII, auto
> negotiation, auto-MDIX, 10/100 TX and RX PCS/PMA blocks, LED logic,
> clock/reset, PLL and EPHY AFE.
The block diagram is a vendor diagram, the vendor can draw whatever
diagram they want. What does the Mainline Linux networking block
diagram look like?
O.K. I've somewhat had enough of this discussion.
For the Networking parts: NACK
To get that revoked, make the PHY driver drive the PHY.
Hide away as much of this bad networking design in the bootloader.
You are free to continue working on the MFD and other parts which are
not networking, because i'm not a Maintainer there.
Andrew
On Tue, Aug 4, 2026 at 12:04 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > No they don't. There are extra registers in different address domains.
> >
> > The block diagrams make the distinction clearer. Both diagrams depict
> > an EPHY block with the same internal organization: MII/RMII, auto
> > negotiation, auto-MDIX, 10/100 TX and RX PCS/PMA blocks, LED logic,
> > clock/reset, PLL and EPHY AFE.
>
> The block diagram is a vendor diagram, the vendor can draw whatever
> diagram they want. What does the Mainline Linux networking block
> diagram look like?
I agree that a vendor block diagram is not normative for the Linux
device model. I cited it as corroborating evidence, not as the sole
basis for the design.
The stronger evidence is the observable interface: after the required
control sequence, both link endpoints report PHY ID 0x00441400 and
provide the same link-side paged registers and behavior. The additional
registers are not extra registers at that Clause 22 endpoint. AC200
exposes the corresponding package controls through its MFD regmap,
whereas AC300 exposes them through a separately addressed non-PHY MDIO
device.
The Linux device model follows those addressable devices and their
dependencies rather than treating a physical package as one indivisible
driver. I think the relevant Linux diagram is:
MAC / phylink
|
| MDIO
v
+-----------------------+
| link phy_device |
| common ACx00 PHY |
| driver |
+-----------+-----------+
|
| required control provider
|
one of:
+-----------+-----------+
| |
+---------v----------+ +---------v----------+
| AC200 MFD child | | AC300 mdio_device |
| TWI/RSB regmap | | control address |
+--------------------+ +--------------------+
For AC200, the surrounding MFD topology is additionally:
+----------------------+
TWI/RSB ->| AC200 MFD core |
+----------+-----------+
|
+-------------+-------------+----------+
| | | |
EPHY ctl audio RTC TVE
Only the selected EPHY control provider is connected to the link
phy_device. With a fixed AC200 or AC300 description, that topology is
entirely static and does not require CONFIG_OF_DYNAMIC.
The common PHY driver already drives the PHY in the phylib sense: it
owns the link-side reset and initialization, auto-negotiation, link
status, MDI/MDI-X, analog tuning, interrupts, statistics, EEE, LEDs,
Wake-on-LAN and suspend/resume behavior. The provider owns only the
package-specific operation needed to make that MDIO endpoint usable
through the bus which actually exposes the relevant registers.
This is similar to other places in mainline where EPHY clocks, resets,
power and address selection are outside the link-PHY driver, including
dwmac-sun8i and dwmac-rk. It is also consistent with the general MFD
model, where a function driver accesses its portion of a parent regmap
without taking ownership of the entire multifunction device.
CONFIG_OF_DYNAMIC is not what motivates this split. It is only an
optional way to select which of the two provider devices exists on a
dual-source system. If runtime selection were removed and the
bootloader always selected the package, the Linux diagram above would
remain the same.
> O.K. I've somewhat had enough of this discussion.
>
> For the Networking parts: NACK
>
> To get that revoked, make the PHY driver drive the PHY.
I am not clear which concrete ownership problem in the diagram above
is resolved by moving the provider implementations into the link-PHY
driver.
The link-PHY driver already drives all common link-PHY functionality.
Making it directly access the other control devices would instead make
one driver bound to one MDIO address also operate:
- an AC200 MFD child and its parent regmap on fixed AC200 systems; or
- another mdio_device at a different address on fixed AC300 systems.
That does not remove either device. It bypasses their normal bus
ownership and combines different device lifetimes inside the driver
bound to the link endpoint.
It is especially problematic for AC200 because the AC200 is an MFD, not
an Ethernet PHY. Its parent clock, supplies, interrupt controller,
regmap and global state can be shared by audio, RTC and TVE children.
The link-PHY driver should not assume ownership of that parent or
perform operations which may affect its sibling functions.
If the objection is specifically to the private provider interface, I
am open to discussing whether some operations can instead use existing
clock, reset, power-sequencing or generic-PHY abstractions. That would
still leave the AC200 MFD child and AC300 MDIO control device as
separately owned devices, however.
Likewise, if the objection is specifically to the MDIO OF_DYNAMIC
changes, those can be reviewed or narrowed independently. Rejecting
runtime DT selection would mean that firmware must resolve dual-source
systems. It would not remove the justification for separate AC200 and
AC300 control drivers on fixed systems or justify duplicating their
common link-PHY implementation.
> Hide away as much of this bad networking design in the bootloader.
The bootloader can identify the package, perform the initial power-up
sequence and enable the selected provider node. That is fully compatible
with this model, but it cannot replace the Linux control path.
Linux still needs to reapply the package configuration after PHY reset,
system suspend, provider power loss or driver reprobe. It also needs to
coordinate Wake-on-LAN, interrupts, LEDs and power management with the
selected control device. Relying on undocumented bootloader state for
those operations would make the driver less self-contained and more
fragile.
Even when the bootloader resolves the variant, Linux still sees either
an AC200 MFD control function or an AC300 MDIO control endpoint plus the
common link PHY. The bootloader can select the left or right branch in
the diagram; it cannot make those devices become registers of the link
phy_device.
Again, this remains true with CONFIG_OF_DYNAMIC disabled. Dynamic OF
handling only allows Linux to make the same deterministic selection
from SID when firmware has not already done so.
> You are free to continue working on the MFD and other parts which are
> not networking, because i'm not a Maintainer there.
I can separate the MFD, fixed AC200 networking, fixed AC300 networking
and optional runtime-selection work so that each part can be reviewed
on its own merits.
However, the MFD and networking portions necessarily meet at the AC200
EPHY function. I do not think the correct way to avoid that
cross-subsystem dependency is to make a driver bound to an MDIO
phy_device take ownership of registers and resources belonging to an
MFD device.
I would therefore like clarification on whether the NACK is against:
- the common link-PHY implementation;
- the existence of separately bound control devices;
- the private interface between the PHY and those devices; or
- only the optional CONFIG_OF_DYNAMIC selection mechanism.
Those are independent design choices. In particular, removing
CONFIG_OF_DYNAMIC does not collapse the fixed AC200 MFD child or fixed
AC300 MDIO control endpoint into the link phy_device.
> Andrew
> However, the MFD and networking portions necessarily meet at the AC200
> EPHY function. I do not think the correct way to avoid that
> cross-subsystem dependency is to make a driver bound to an MDIO
> phy_device take ownership of registers and resources belonging to an
> MFD device.
We can pull the MFD Maintainer into this, but an MFD core driver
typically just provides methods to access the shared registers, and
instantiates drivers to make use of those shared registers. In this
case, we don't need the instantiate part, that happens via the MDIO
bus model. But we do need access to the shared registers. I personally
don't care too much how that is done, but regmap would be normal.
The PHY driver should then drive the whole, entire PHY, using both
MDIO and whatever method the MFD exports to give access to the
registers.
Andrew
@@ -469,6 +469,15 @@ config VITESSE_PHY
help
Currently supports the vsc8244
+config XPOWERS_AC200_PHY_CTL
+ tristate "X-Powers AC200 Ethernet PHY control"
+ depends on MFD_AC200
+ help
+ Enable the control driver for the Fast Ethernet PHY function in
+ the X-Powers AC200 mixed-signal companion IC. It programs the PHY
+ address, interface mode, calibration and I/O controls through the
+ parent AC200 I2C regmap.
+
config XILINX_GMII2RGMII
tristate "Xilinx GMII2RGMII converter driver"
help
@@ -99,4 +99,5 @@ obj-$(CONFIG_SMSC_PHY) += smsc.o
obj-$(CONFIG_STE10XP) += ste10Xp.o
obj-$(CONFIG_TERANETICS_PHY) += teranetics.o
obj-$(CONFIG_VITESSE_PHY) += vitesse.o
+obj-$(CONFIG_XPOWERS_AC200_PHY_CTL) += xpowers-ac200-ctl.o
obj-$(CONFIG_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
new file mode 100644
@@ -0,0 +1,330 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * X-Powers AC200 Ethernet PHY control driver
+ *
+ * Copyright (C) 2026 James Hilliard <james.hilliard1@gmail.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+
+#include "xpowers-acx00.h"
+
+#define AC200_EPHY_BPS_EFFUSE_OFFSET 3
+
+#define AC200_SYS_EPHY_CTL0_REG 0x0014
+#define AC200_EPHY_RESET_DEASSERT BIT(0)
+#define AC200_EPHY_SYSCLK_ENABLE BIT(1)
+
+#define AC200_SYS_EPHY_CTL1_REG 0x0016
+#define AC200_EPHY_MII_IO_ENABLE BIT(0)
+#define AC200_EPHY_LINK_LED_IO_ENABLE BIT(1)
+#define AC200_EPHY_SPEED_LED_IO_ENABLE BIT(2)
+#define AC200_EPHY_DUPLEX_LED_IO_ENABLE BIT(3)
+#define AC200_EPHY_LED_IO_ENABLE_MASK \
+ (AC200_EPHY_LINK_LED_IO_ENABLE | AC200_EPHY_SPEED_LED_IO_ENABLE | \
+ AC200_EPHY_DUPLEX_LED_IO_ENABLE)
+
+/* AC200-internal copy of the Ethernet PHY calibration eFuse. */
+#define AC200_EFUSE_EPHY_REG 0x8004
+
+#define AC200_EPHY_CTL_REG 0x6000
+#define AC200_EPHY_SHUTDOWN BIT(0)
+#define AC200_EPHY_LED_ACTIVE_LOW BIT(1)
+#define AC200_EPHY_CLK_SEL_24_MHZ BIT(2)
+#define AC200_EPHY_PHY_ADDR_MASK GENMASK(8, 4)
+#define AC200_EPHY_RMII_SEL BIT(11)
+#define AC200_EPHY_BPS_EFFUSE_MASK GENMASK(15, 12)
+
+struct ac200_ephy_ctl {
+ struct acx00_ephy_control control;
+ struct regmap *regmap;
+ struct mutex lock; /* Serializes power sequencing and state. */
+ u16 ephy_ctl;
+ u16 led_io_enable;
+ unsigned int phy_addr;
+ bool powered;
+};
+
+static int
+ac200_ephy_ctl_set_led_outputs(struct acx00_ephy_control *control,
+ unsigned long outputs)
+{
+ struct ac200_ephy_ctl *priv =
+ container_of(control, struct ac200_ephy_ctl, control);
+ u16 led_io_enable;
+ int ret = 0;
+
+ if (outputs & ~GENMASK(ACX00_EPHY_LED_COUNT - 1, 0))
+ return -EINVAL;
+
+ led_io_enable = (outputs << 1) & AC200_EPHY_LED_IO_ENABLE_MASK;
+
+ mutex_lock(&priv->lock);
+ if (priv->powered)
+ ret = regmap_update_bits(priv->regmap, AC200_SYS_EPHY_CTL1_REG,
+ AC200_EPHY_LED_IO_ENABLE_MASK,
+ led_io_enable);
+ if (!ret)
+ priv->led_io_enable = led_io_enable;
+ mutex_unlock(&priv->lock);
+
+ return ret;
+}
+
+static int
+ac200_ephy_ctl_set_led_polarity(struct acx00_ephy_control *control,
+ bool active_low)
+{
+ struct ac200_ephy_ctl *priv =
+ container_of(control, struct ac200_ephy_ctl, control);
+ u16 value = active_low ? AC200_EPHY_LED_ACTIVE_LOW : 0;
+ int ret = 0;
+
+ mutex_lock(&priv->lock);
+ if (priv->powered)
+ ret = regmap_update_bits(priv->regmap, AC200_EPHY_CTL_REG,
+ AC200_EPHY_LED_ACTIVE_LOW, value);
+ if (!ret) {
+ priv->ephy_ctl &= ~AC200_EPHY_LED_ACTIVE_LOW;
+ priv->ephy_ctl |= value;
+ }
+ mutex_unlock(&priv->lock);
+
+ return ret;
+}
+
+static int ac200_ephy_ctl_power_off_locked(struct ac200_ephy_ctl *priv)
+{
+ int err;
+ int ret;
+
+ if (!priv->powered)
+ return 0;
+
+ ret = regmap_write(priv->regmap, AC200_EPHY_CTL_REG,
+ priv->ephy_ctl |
+ FIELD_PREP(AC200_EPHY_PHY_ADDR_MASK,
+ priv->phy_addr) |
+ AC200_EPHY_SHUTDOWN);
+ err = regmap_write(priv->regmap, AC200_SYS_EPHY_CTL1_REG, 0);
+ if (!ret)
+ ret = err;
+ err = regmap_write(priv->regmap, AC200_SYS_EPHY_CTL0_REG, 0);
+ if (!ret)
+ ret = err;
+
+ priv->powered = false;
+
+ return ret;
+}
+
+static int ac200_ephy_ctl_power_off(struct acx00_ephy_control *control)
+{
+ struct ac200_ephy_ctl *priv =
+ container_of(control, struct ac200_ephy_ctl, control);
+ int ret;
+
+ mutex_lock(&priv->lock);
+ ret = ac200_ephy_ctl_power_off_locked(priv);
+ mutex_unlock(&priv->lock);
+
+ return ret;
+}
+
+static int ac200_ephy_ctl_power_on(struct acx00_ephy_control *control,
+ unsigned int phy_addr)
+{
+ struct ac200_ephy_ctl *priv =
+ container_of(control, struct ac200_ephy_ctl, control);
+ u16 ephy_ctl;
+ int ret;
+
+ if (phy_addr > FIELD_MAX(AC200_EPHY_PHY_ADDR_MASK))
+ return -EINVAL;
+
+ mutex_lock(&priv->lock);
+ if (priv->powered && priv->phy_addr == phy_addr) {
+ ret = 0;
+ goto out_unlock;
+ }
+ if (priv->powered) {
+ ret = ac200_ephy_ctl_power_off_locked(priv);
+ if (ret)
+ goto out_unlock;
+ }
+
+ ephy_ctl = priv->ephy_ctl |
+ FIELD_PREP(AC200_EPHY_PHY_ADDR_MASK, phy_addr);
+
+ /* Start from a disabled state before applying the configuration. */
+ ret = regmap_write(priv->regmap, AC200_SYS_EPHY_CTL0_REG, 0);
+ if (ret)
+ goto err_disable;
+
+ ret = regmap_write(priv->regmap, AC200_SYS_EPHY_CTL1_REG,
+ AC200_EPHY_MII_IO_ENABLE |
+ priv->led_io_enable);
+ if (ret)
+ goto err_disable;
+
+ ret = regmap_write(priv->regmap, AC200_EPHY_CTL_REG,
+ ephy_ctl | AC200_EPHY_SHUTDOWN);
+ if (ret)
+ goto err_disable;
+
+ ret = regmap_write(priv->regmap, AC200_SYS_EPHY_CTL0_REG,
+ AC200_EPHY_RESET_DEASSERT |
+ AC200_EPHY_SYSCLK_ENABLE);
+ if (ret)
+ goto err_disable;
+
+ fsleep(10000);
+
+ ret = regmap_write(priv->regmap, AC200_EPHY_CTL_REG, ephy_ctl);
+ if (ret)
+ goto err_disable;
+
+ priv->phy_addr = phy_addr;
+ priv->powered = true;
+ goto out_unlock;
+
+err_disable:
+ /* Mark it active so the cleanup sequence is always attempted. */
+ priv->phy_addr = phy_addr;
+ priv->powered = true;
+ ac200_ephy_ctl_power_off_locked(priv);
+out_unlock:
+ mutex_unlock(&priv->lock);
+
+ return ret;
+}
+
+static int ac200_ephy_ctl_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct ac200_ephy_ctl *priv;
+ phy_interface_t interface;
+ struct clk *clk;
+ unsigned long clk_rate;
+ unsigned int calibration;
+ u8 nvmem_calibration;
+ u8 bps_effuse_code;
+ u16 ephy_ctl;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ mutex_init(&priv->lock);
+
+ priv->regmap = dev_get_regmap(dev->parent, NULL);
+ if (!priv->regmap)
+ return dev_err_probe(dev, -EPROBE_DEFER,
+ "parent regmap is not ready\n");
+
+ if (device_property_present(dev, "nvmem-cells")) {
+ ret = nvmem_cell_read_u8(dev, "calibration",
+ &nvmem_calibration);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to read calibration data\n");
+ calibration = nvmem_calibration;
+ } else {
+ ret = regmap_read(priv->regmap, AC200_EFUSE_EPHY_REG,
+ &calibration);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to read on-chip calibration data\n");
+ }
+
+ ret = device_get_phy_mode(dev);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to read PHY mode\n");
+ interface = ret;
+
+ /* The vendor driver supplies no transfer function beyond this offset. */
+ bps_effuse_code = (calibration + AC200_EPHY_BPS_EFFUSE_OFFSET) &
+ FIELD_MAX(AC200_EPHY_BPS_EFFUSE_MASK);
+ ephy_ctl = FIELD_PREP(AC200_EPHY_BPS_EFFUSE_MASK, bps_effuse_code) |
+ AC200_EPHY_LED_ACTIVE_LOW;
+ /* EPHY_MODE and BIST_CLK_EN stay clear for normal operation. */
+
+ switch (interface) {
+ case PHY_INTERFACE_MODE_MII:
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ ephy_ctl |= AC200_EPHY_RMII_SEL;
+ break;
+ default:
+ return dev_err_probe(dev, -EINVAL,
+ "unsupported PHY mode %s\n",
+ phy_modes(interface));
+ }
+
+ clk = clk_get(dev->parent, NULL);
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk),
+ "failed to get input clock\n");
+
+ clk_rate = clk_get_rate(clk);
+ clk_put(clk);
+
+ switch (clk_rate) {
+ case 24000000:
+ ephy_ctl |= AC200_EPHY_CLK_SEL_24_MHZ;
+ break;
+ case 27000000:
+ break;
+ default:
+ return dev_err_probe(dev, -EINVAL,
+ "unsupported input clock rate %lu Hz\n",
+ clk_rate);
+ }
+
+ priv->control.power_on = ac200_ephy_ctl_power_on;
+ priv->control.power_off = ac200_ephy_ctl_power_off;
+ priv->control.set_led_outputs = ac200_ephy_ctl_set_led_outputs;
+ priv->control.set_led_polarity = ac200_ephy_ctl_set_led_polarity;
+ priv->control.interface = interface;
+ priv->ephy_ctl = ephy_ctl;
+ priv->led_io_enable = AC200_EPHY_LED_IO_ENABLE_MASK;
+ platform_set_drvdata(pdev, &priv->control);
+ return 0;
+}
+
+static void ac200_ephy_ctl_remove(struct platform_device *pdev)
+{
+ struct acx00_ephy_control *control = platform_get_drvdata(pdev);
+
+ control->power_off(control);
+}
+
+static const struct of_device_id ac200_ephy_ctl_of_match[] = {
+ { .compatible = "x-powers,ac200-ephy-ctl" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ac200_ephy_ctl_of_match);
+
+static struct platform_driver ac200_ephy_ctl_driver = {
+ .probe = ac200_ephy_ctl_probe,
+ .remove = ac200_ephy_ctl_remove,
+ .shutdown = ac200_ephy_ctl_remove,
+ .driver = {
+ .name = "ac200-ephy-ctl",
+ .of_match_table = ac200_ephy_ctl_of_match,
+ },
+};
+module_platform_driver(ac200_ephy_ctl_driver);
+
+MODULE_AUTHOR("James Hilliard <james.hilliard1@gmail.com>");
+MODULE_DESCRIPTION("X-Powers AC200 Ethernet PHY control driver");
+MODULE_LICENSE("GPL");
new file mode 100644
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef __DRIVERS_NET_PHY_XPOWERS_ACX00_H
+#define __DRIVERS_NET_PHY_XPOWERS_ACX00_H
+
+#include <linux/phy.h>
+
+enum acx00_ephy_led {
+ ACX00_EPHY_LED_LINK_ACTIVITY,
+ ACX00_EPHY_LED_SPEED,
+ ACX00_EPHY_LED_DUPLEX,
+ ACX00_EPHY_LED_COUNT,
+};
+
+struct acx00_ephy_control {
+ phy_interface_t interface;
+ int (*power_on)(struct acx00_ephy_control *control,
+ unsigned int phy_addr);
+ int (*power_off)(struct acx00_ephy_control *control);
+ int (*set_led_outputs)(struct acx00_ephy_control *control,
+ unsigned long outputs);
+ int (*set_led_polarity)(struct acx00_ephy_control *control,
+ bool active_low);
+};
+
+#endif