[PATCH v7 0/2] mfd: add X-Powers AC200 support

[PATCH v7 0/2] mfd: add X-Powers AC200 support

[James Hilliard]

This submission contains only the AC200 binding and I2C register provider
and is intended for the MFD tree. The Ethernet PHY binding and driver are
submitted separately to net-next. Neither series has a compile-time
dependency or required merge order. Their shared design point is the DT
representation: the MDIO PHY-package node references the separately
described AC200 I2C node for access to package-control registers.

The X-Powers AC200 is an I2C-controlled mixed-signal companion IC with a
paged register map shared by its audio, video, RTC and Fast Ethernet PHY
functions. Its shared input clock must remain enabled while the chip is in
use.

The provider enables and rate-locks that clock, matches the vendor
driver's 40 ms delay before the first register access, initializes the
paged regmap, reports the chip revision and applies common reset. The
regmap remains attached to the AC200 I2C device. A separately enumerated
function can resolve that device, establish its lifetime relationship and
retrieve the regmap through the generic device and regmap interfaces.

The two patches add the minimal AC200 binding and I2C register provider.
They do not add syscon registration or a private cross-subsystem API.

The AC200 work builds on earlier work by Jernej Skrabec and Andre
Przywara:

  https://github.com/jernejsk/linux-1/commits/ac200-v4

Public AC200 documentation is linked from:

  https://linux-sunxi.org/AC200

Validation completed for v7:

  - an x86_64 defconfig object build of the AC200 provider with W=1;
  - dt_binding_check for the AC200 schema; and
  - strict checkpatch checks with no errors and only the generic new-file
    MAINTAINERS prompts.

The provider initialization was hardware-tested on an H616 board, where
it reported AC200 revision 0x101 in package 1. The direct device/regmap
lookup used by the separately submitted PHY driver was previously tested
on the same hardware, including supplier unbind and rebind.

Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
Changes in v7:
- drop the managed external-syscon helper and AC200 syscon registration
- leave the regmap attached to the I2C provider for direct device lookup
- reduce the MFD series from three patches to two
- Link to v6: https://patch.msgid.link/20260811-submit-ac200-mfd-v6-0-c5b1292c8498@gmail.com

Changes in v6:
- split the MFD work from the independently mergeable networking series
- put the merge routing and shared DT design at the start of the cover letter
- rebase onto the current MFD for-mfd-next branch
- Link to v5: https://patch.msgid.link/20260809-submit-acx00-of-dynamic-v1-v5-0-bfa1f8518b28@gmail.com

To: Lee Jones <lee@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: James Hilliard <james.hilliard1@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: "Jagielski, Jedrzej" <jedrzej.jagielski@intel.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Chen-Yu Tsai <wens@kernel.org>
Cc: Jernej Škrabec <jernej.skrabec@gmail.com>
Cc: linux-sunxi@lists.linux.dev
Cc: mfd@lists.linux.dev
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

---
James Hilliard (2):
      dt-bindings: mfd: x-powers: Add AC200
      mfd: ac200: Add X-Powers AC200 support

 .../devicetree/bindings/mfd/x-powers,ac200.yaml    |  49 +++++++
 drivers/mfd/Kconfig                                |  11 ++
 drivers/mfd/Makefile                               |   1 +
 drivers/mfd/ac200.c                                | 163 +++++++++++++++++++++
 4 files changed, 224 insertions(+)
---
base-commit: ffc63a677b60247738b02a2520c6bfa740523c2b
change-id: 20260811-submit-ac200-mfd-8bad6d09e285

Best regards,
--  
James Hilliard <james.hilliard1@gmail.com>

[PATCH v7 1/2] dt-bindings: mfd: x-powers: Add AC200

[James Hilliard]

The AC200 is an I2C-controlled mixed-signal companion IC containing
audio, video, RTC and Fast Ethernet PHY functions.

Describe the parent device and its shared input clock. The Ethernet PHY
is represented by a PHY package on its MDIO bus, with a phandle back to
this device for access to the package control registers, so it does not
require an MFD child node. Function-specific supplies belong to their
consumer bindings rather than the shared parent.

The input clock must run at 24 or 27 MHz when the Ethernet PHY is used,
matching the rates encoded by its documented clock selector.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
 .../devicetree/bindings/mfd/x-powers,ac200.yaml    | 49 ++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/x-powers,ac200.yaml b/Documentation/devicetree/bindings/mfd/x-powers,ac200.yaml
new file mode 100644
index 000000000000..609831b15c80
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/x-powers,ac200.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/x-powers,ac200.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: X-Powers AC200 mixed-signal IC
+
+maintainers:
+  - James Hilliard <james.hilliard1@gmail.com>
+
+description:
+  The AC200 is a mixed-signal companion IC containing audio, video, RTC and
+  Fast Ethernet PHY functions. Its control registers are accessed over I2C.
+
+properties:
+  compatible:
+    const: x-powers,ac200
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+    description:
+      AC200 input clock. When using the Ethernet PHY, its configured rate must
+      be 24 or 27 MHz, matching the rates encoded by the documented EPHY clock
+      selector.
+
+required:
+  - compatible
+  - reg
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        mixed-signal@10 {
+            compatible = "x-powers,ac200";
+            reg = <0x10>;
+            clocks = <&pwm 5>;
+        };
+    };
+...

-- 
2.53.0

Re: [PATCH v7 1/2] dt-bindings: mfd: x-powers: Add AC200

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Potential incomplete Device Tree Binding Schema for AC200 hardware functions
--

--- Patch [1]: [PATCH v7 1/2] dt-bindings: mfd: x-powers: Add AC200 ---
commit edf03c82fb970a30013a24a5a03b1e0de64b8288
Author: James Hilliard <james.hilliard1@gmail.com>

dt-bindings: mfd: x-powers: Add AC200

This commit introduces the device tree binding schema for the X-Powers AC200
mixed-signal IC. The device provides audio, video, RTC, and Fast Ethernet PHY
functions controlled over I2C.

> diff --git a/Documentation/devicetree/bindings/mfd/x-powers,ac200.yaml b/Documentation/devicetree/bindings/mfd/x-powers,ac200.yaml
> new file mode 100644
> index 0000000000000..609831b15c806
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/x-powers,ac200.yaml

[ ... ]

> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +
> +additionalProperties: false

[Severity: Medium]
Since the AC200 provides audio, video, and RTC functions as mentioned in the
commit message, will these require child nodes in the device tree?

With additionalProperties: false, any attempt to add child nodes for these
sub-devices, or a shared interrupts property for the parent, will fail schema
validation. If these functions are meant to be modeled as MFD child nodes,
should they be documented here to avoid validation failures when device trees
start describing the IC's full capabilities?

> +
> +examples:
> +  - |
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        mixed-signal@10 {
> +            compatible = "x-powers,ac200";
> +            reg = <0x10>;
> +            clocks = <&pwm 5>;
> +        };
> +    };
> +...

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260811-submit-ac200-mfd-v7-0-8b06f552a4d7@gmail.com?part=1

Re: [PATCH v7 1/2] dt-bindings: mfd: x-powers: Add AC200

[Krzysztof Kozlowski]

On Tue, Aug 11, 2026 at 05:11:30PM -0600, James Hilliard wrote:
> The AC200 is an I2C-controlled mixed-signal companion IC containing
> audio, video, RTC and Fast Ethernet PHY functions.
> 
> Describe the parent device and its shared input clock. The Ethernet PHY
> is represented by a PHY package on its MDIO bus, with a phandle back to
> this device for access to the package control registers, so it does not
> require an MFD child node. Function-specific supplies belong to their
> consumer bindings rather than the shared parent.

Other way to represent it is to put ethernet phy here - either as a
child or folded into MFD device node - and provide phandle to MDIO bus.
We do like this already for several devices for I2C case with "i2c-bus"
property. Here it would be "mdio-bus" for example. Such solution feels
more vendor-agnostic, easier to re-use, however I cannot find any actual
arguments against your approach.

Maybe Rob will have his preference, but this looks okay for me then:

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v7 1/2] dt-bindings: mfd: x-powers: Add AC200

[James Hilliard]

On Thu, Aug 13, 2026 at 12:49 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Tue, Aug 11, 2026 at 05:11:30PM -0600, James Hilliard wrote:
> > The AC200 is an I2C-controlled mixed-signal companion IC containing
> > audio, video, RTC and Fast Ethernet PHY functions.
> >
> > Describe the parent device and its shared input clock. The Ethernet PHY
> > is represented by a PHY package on its MDIO bus, with a phandle back to
> > this device for access to the package control registers, so it does not
> > require an MFD child node. Function-specific supplies belong to their
> > consumer bindings rather than the shared parent.
>
> Other way to represent it is to put ethernet phy here - either as a
> child or folded into MFD device node - and provide phandle to MDIO bus.
> We do like this already for several devices for I2C case with "i2c-bus"
> property. Here it would be "mdio-bus" for example. Such solution feels
> more vendor-agnostic, easier to re-use, however I cannot find any actual
> arguments against your approach.

The PHY package remains on the MDIO bus because the link PHY is addressed
and accessed through MDIO on both AC200 and AC300. Only the AC200
package-control registers require the additional I2C path; AC300 exposes
its package controls through MDIO as well. Keeping the package under MDIO
therefore gives both variants the same representation, with the AC200
phandle describing only its secondary control path.

>
> Maybe Rob will have his preference, but this looks okay for me then:
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Best regards,
> Krzysztof
>

Re: [PATCH v7 1/2] dt-bindings: mfd: x-powers: Add AC200

[Andrew Lunn]

On Thu, Aug 13, 2026 at 08:49:33AM +0200, Krzysztof Kozlowski wrote:
> On Tue, Aug 11, 2026 at 05:11:30PM -0600, James Hilliard wrote:
> > The AC200 is an I2C-controlled mixed-signal companion IC containing
> > audio, video, RTC and Fast Ethernet PHY functions.
> > 
> > Describe the parent device and its shared input clock. The Ethernet PHY
> > is represented by a PHY package on its MDIO bus, with a phandle back to
> > this device for access to the package control registers, so it does not
> > require an MFD child node. Function-specific supplies belong to their
> > consumer bindings rather than the shared parent.
> 
> Other way to represent it is to put ethernet phy here - either as a
> child or folded into MFD device node - and provide phandle to MDIO bus.

That would be odd. IEEE 802.3 specified that the PHY should be on an
MDIO bus. And this PHY is on an MDIO bus, that is its primary
management interface. I2C is just for ancillary configuration.

The only kind of sort of an exception we have in the current MDIO
subsystem is for SFP modules. They only have an I2C bus, not
MDIO. However, SFP vendors have various protocols for MDIO over
I2C. So the SFP does appear in the I2C tree, but we then instantiate
an MDIO bus as an I2C client, and then the PHY is then just a normal
PHY on an emulated MDIO bus.

	Andrew

[PATCH v7 2/2] mfd: ac200: Add X-Powers AC200 support

[James Hilliard]

The X-Powers AC200 is a mixed-signal companion IC with a paged register
map accessed over I2C.

Enable the shared input clock and prevent its rate from changing. Match
the vendor driver's 40 ms wait before the first register access,
initialize the paged regmap, report the chip and package revision, and
apply common reset.

The Ethernet PHY link endpoint is independently enumerated on its MDIO
bus rather than created as an MFD platform child. Keep the regmap attached
to the AC200 I2C device so a separately enumerated function can resolve
that device, establish its required lifetime relationship and retrieve
the regmap from the provider.

Cache only the common page selector. Individual functions can reset
independently and invalidate their other registers without regmap's
knowledge, so leave all functional registers volatile.

Reset the chip during managed teardown and system shutdown.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
 drivers/mfd/Kconfig  |  11 ++++
 drivers/mfd/Makefile |   1 +
 drivers/mfd/ac200.c  | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 175 insertions(+)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index e4fd4572472f..cac3fff5aee9 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -205,6 +205,17 @@ config MFD_AC100
 	  This driver include only the core APIs. You have to select individual
 	  components like codecs or RTC under the corresponding menus.
 
+config MFD_AC200
+	tristate "X-Powers AC200"
+	depends on I2C
+	depends on OF
+	select REGMAP_I2C
+	help
+	  Support for the X-Powers AC200 mixed-signal companion IC. The AC200
+	  contains audio, video, RTC and Fast Ethernet PHY functions and is
+	  co-packaged with some Allwinner H6 and H616 SoCs. This driver provides
+	  the shared register access used by the individual function drivers.
+
 config MFD_AXP20X
 	tristate
 	select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 72d3944b0ad8..f8101d2a9ce9 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -150,6 +150,7 @@ obj-$(CONFIG_MFD_DA9052_SPI)	+= da9052-spi.o
 obj-$(CONFIG_MFD_DA9052_I2C)	+= da9052-i2c.o
 
 obj-$(CONFIG_MFD_AC100)		+= ac100.o
+obj-$(CONFIG_MFD_AC200)		+= ac200.o
 obj-$(CONFIG_MFD_AXP20X)	+= axp20x.o
 obj-$(CONFIG_MFD_AXP20X_I2C)	+= axp20x-i2c.o
 obj-$(CONFIG_MFD_AXP20X_RSB)	+= axp20x-rsb.o
diff --git a/drivers/mfd/ac200.c b/drivers/mfd/ac200.c
new file mode 100644
index 000000000000..0964e637afef
--- /dev/null
+++ b/drivers/mfd/ac200.c
@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * MFD core driver for the X-Powers AC200
+ *
+ * Copyright (C) 2019 Jernej Skrabec <jernej.skrabec@gmail.com>
+ * Copyright (C) 2026 James Hilliard <james.hilliard1@gmail.com>
+ *
+ * Based on the AC100 driver:
+ * Copyright (C) 2016 Chen-Yu Tsai
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+
+#define AC200_SYS_VERSION_REG			0x0000
+#define AC200_SYS_VERSION_PACKAGE_MASK		GENMASK(15, 14)
+#define AC200_SYS_VERSION_CHIP_MASK		GENMASK(11, 0)
+
+#define AC200_SYS_CONTROL_REG			0x0002
+#define AC200_SYS_CONTROL_CHIP_RESET_DEASSERT	BIT(0)
+
+/* Interface register accessible from every register page. */
+#define AC200_TWI_REG_ADDR_H	0x00fe
+#define AC200_MAX_REG		0xa1f2
+
+struct ac200 {
+	struct regmap *regmap;
+};
+
+static const struct regmap_range_cfg ac200_range_cfg[] = {
+	{
+		.range_max = AC200_MAX_REG,
+		.selector_reg = AC200_TWI_REG_ADDR_H,
+		.selector_mask = 0xff,
+		.window_len = 256,
+	},
+};
+
+/*
+ * Each AC200 sub-block can reset independently, invalidating its register
+ * contents without regmap's knowledge. Cache only the common page selector;
+ * this avoids a selector read-modify-write for every access on the same page
+ * without ever returning stale functional-register values.
+ */
+static bool ac200_volatile_reg(struct device *dev, unsigned int reg)
+{
+	return reg != AC200_TWI_REG_ADDR_H;
+}
+
+static const struct regmap_config ac200_regmap_config = {
+	.name = "ac200",
+	.reg_bits = 8,
+	.reg_stride = 2,
+	.val_bits = 16,
+	.ranges = ac200_range_cfg,
+	.num_ranges = ARRAY_SIZE(ac200_range_cfg),
+	.max_register = AC200_MAX_REG,
+	.volatile_reg = ac200_volatile_reg,
+	.cache_type = REGCACHE_MAPLE,
+};
+
+static void ac200_disable(void *data)
+{
+	struct ac200 *ddata = data;
+
+	regmap_write(ddata->regmap, AC200_SYS_CONTROL_REG, 0);
+}
+
+static int ac200_probe(struct i2c_client *client)
+{
+	struct device *dev = &client->dev;
+	unsigned int version;
+	struct ac200 *ddata;
+	struct clk *clk;
+	int ret;
+
+	ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
+	if (!ddata)
+		return -ENOMEM;
+
+	clk = devm_clk_get_enabled(dev, NULL);
+	if (IS_ERR(clk))
+		return dev_err_probe(dev, PTR_ERR(clk),
+				     "failed to enable input clock\n");
+
+	ret = devm_clk_rate_exclusive_get(dev, clk);
+	if (ret)
+		return dev_err_probe(dev, ret, "failed to lock clock rate\n");
+
+	ddata->regmap = devm_regmap_init_i2c(client, &ac200_regmap_config);
+	if (IS_ERR(ddata->regmap))
+		return dev_err_probe(dev, PTR_ERR(ddata->regmap),
+				     "failed to initialize regmap\n");
+
+	i2c_set_clientdata(client, ddata);
+
+	/*
+	 * No minimum delay is documented. Match the vendor driver's 40 ms delay
+	 * before its first AC200 register access after enabling the input clock.
+	 */
+	msleep(40);
+
+	ret = regmap_read(ddata->regmap, AC200_SYS_VERSION_REG, &version);
+	if (ret)
+		return dev_err_probe(dev, ret,
+				     "failed to read chip version\n");
+
+	dev_info(dev, "AC200 revision %#lx in package %lu\n",
+		 FIELD_GET(AC200_SYS_VERSION_CHIP_MASK, version),
+		 FIELD_GET(AC200_SYS_VERSION_PACKAGE_MASK, version));
+
+	/* Reset the chip after dependent function drivers have unbound. */
+	ret = devm_add_action_or_reset(dev, ac200_disable, ddata);
+	if (ret)
+		return ret;
+
+	ret = regmap_write(ddata->regmap, AC200_SYS_CONTROL_REG, 0);
+	if (ret)
+		return ret;
+
+	ret = regmap_write(ddata->regmap, AC200_SYS_CONTROL_REG,
+			   AC200_SYS_CONTROL_CHIP_RESET_DEASSERT);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+static void ac200_shutdown(struct i2c_client *client)
+{
+	ac200_disable(i2c_get_clientdata(client));
+}
+
+static const struct of_device_id ac200_of_match[] = {
+	{ .compatible = "x-powers,ac200" },
+	{ }
+};
+MODULE_DEVICE_TABLE(of, ac200_of_match);
+
+static const struct i2c_device_id ac200_i2c_ids[] = {
+	{ .name = "ac200" },
+	{ }
+};
+MODULE_DEVICE_TABLE(i2c, ac200_i2c_ids);
+
+static struct i2c_driver ac200_driver = {
+	.driver = {
+		.name = "ac200",
+		.of_match_table = ac200_of_match,
+	},
+	.probe = ac200_probe,
+	.shutdown = ac200_shutdown,
+	.id_table = ac200_i2c_ids,
+};
+module_i2c_driver(ac200_driver);
+
+MODULE_AUTHOR("James Hilliard <james.hilliard1@gmail.com>");
+MODULE_DESCRIPTION("X-Powers AC200 MFD core driver");
+MODULE_LICENSE("GPL");

-- 
2.53.0

Re: [PATCH v7 2/2] mfd: ac200: Add X-Powers AC200 support

[sashiko-bot]

> The X-Powers AC200 is a mixed-signal companion IC with a paged register
> map accessed over I2C.
> 
> Enable the shared input clock and prevent its rate from changing. Match
> the vendor driver's 40 ms wait before the first register access,
> initialize the paged regmap, report the chip and package revision, and
> apply common reset.
> 
> The Ethernet PHY link endpoint is independently enumerated on its MDIO
> bus rather than created as an MFD platform child. Keep the regmap attached
> to the AC200 I2C device so a separately enumerated function can resolve
> that device, establish its required lifetime relationship and retrieve
> the regmap from the provider.
> 
> Cache only the common page selector. Individual functions can reset
> independently and invalidate their other registers without regmap's
> knowledge, so leave all functional registers volatile.
> 
> Reset the chip during managed teardown and system shutdown.
> 
> Signed-off-by: James Hilliard <james.hilliard1@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260811-submit-ac200-mfd-v7-0-8b06f552a4d7@gmail.com?part=2

Re: [PATCH v7 2/2] mfd: ac200: Add X-Powers AC200 support

[Lee Jones]

On Tue, 11 Aug 2026, James Hilliard wrote:

> The X-Powers AC200 is a mixed-signal companion IC with a paged register
> map accessed over I2C.
> 
> Enable the shared input clock and prevent its rate from changing. Match
> the vendor driver's 40 ms wait before the first register access,
> initialize the paged regmap, report the chip and package revision, and
> apply common reset.
> 
> The Ethernet PHY link endpoint is independently enumerated on its MDIO
> bus rather than created as an MFD platform child. Keep the regmap attached
> to the AC200 I2C device so a separately enumerated function can resolve
> that device, establish its required lifetime relationship and retrieve
> the regmap from the provider.
> 
> Cache only the common page selector. Individual functions can reset
> independently and invalidate their other registers without regmap's
> knowledge, so leave all functional registers volatile.
> 
> Reset the chip during managed teardown and system shutdown.
> 
> Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> ---
>  drivers/mfd/Kconfig  |  11 ++++
>  drivers/mfd/Makefile |   1 +
>  drivers/mfd/ac200.c  | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 175 insertions(+)
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index e4fd4572472f..cac3fff5aee9 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -205,6 +205,17 @@ config MFD_AC100
>  	  This driver include only the core APIs. You have to select individual
>  	  components like codecs or RTC under the corresponding menus.
>  
> +config MFD_AC200
> +	tristate "X-Powers AC200"
> +	depends on I2C
> +	depends on OF
> +	select REGMAP_I2C
> +	help
> +	  Support for the X-Powers AC200 mixed-signal companion IC. The AC200
> +	  contains audio, video, RTC and Fast Ethernet PHY functions and is
> +	  co-packaged with some Allwinner H6 and H616 SoCs. This driver provides
> +	  the shared register access used by the individual function drivers.
> +
>  config MFD_AXP20X
>  	tristate
>  	select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 72d3944b0ad8..f8101d2a9ce9 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -150,6 +150,7 @@ obj-$(CONFIG_MFD_DA9052_SPI)	+= da9052-spi.o
>  obj-$(CONFIG_MFD_DA9052_I2C)	+= da9052-i2c.o
>  
>  obj-$(CONFIG_MFD_AC100)		+= ac100.o
> +obj-$(CONFIG_MFD_AC200)		+= ac200.o
>  obj-$(CONFIG_MFD_AXP20X)	+= axp20x.o
>  obj-$(CONFIG_MFD_AXP20X_I2C)	+= axp20x-i2c.o
>  obj-$(CONFIG_MFD_AXP20X_RSB)	+= axp20x-rsb.o
> diff --git a/drivers/mfd/ac200.c b/drivers/mfd/ac200.c
> new file mode 100644
> index 000000000000..0964e637afef
> --- /dev/null
> +++ b/drivers/mfd/ac200.c
> @@ -0,0 +1,163 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * MFD core driver for the X-Powers AC200
> + *
> + * Copyright (C) 2019 Jernej Skrabec <jernej.skrabec@gmail.com>
> + * Copyright (C) 2026 James Hilliard <james.hilliard1@gmail.com>
> + *
> + * Based on the AC100 driver:
> + * Copyright (C) 2016 Chen-Yu Tsai

Drop this.  Every driver tends to be based on something else.

> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>

Why aren't you using the MFD API?

If you don't need it, then why is this in drivers/mfd?

> +#define AC200_SYS_VERSION_REG			0x0000
> +#define AC200_SYS_VERSION_PACKAGE_MASK		GENMASK(15, 14)
> +#define AC200_SYS_VERSION_CHIP_MASK		GENMASK(11, 0)
> +
> +#define AC200_SYS_CONTROL_REG			0x0002
> +#define AC200_SYS_CONTROL_CHIP_RESET_DEASSERT	BIT(0)
> +
> +/* Interface register accessible from every register page. */
> +#define AC200_TWI_REG_ADDR_H	0x00fe
> +#define AC200_MAX_REG		0xa1f2
> +
> +struct ac200 {
> +	struct regmap *regmap;
> +};

Why not just pass 'regmap' directly?

> +static const struct regmap_range_cfg ac200_range_cfg[] = {
> +	{
> +		.range_max = AC200_MAX_REG,
> +		.selector_reg = AC200_TWI_REG_ADDR_H,
> +		.selector_mask = 0xff,
> +		.window_len = 256,
> +	},
> +};
> +
> +/*
> + * Each AC200 sub-block can reset independently, invalidating its register
> + * contents without regmap's knowledge. Cache only the common page selector;
> + * this avoids a selector read-modify-write for every access on the same page
> + * without ever returning stale functional-register values.
> + */
> +static bool ac200_volatile_reg(struct device *dev, unsigned int reg)
> +{
> +	return reg != AC200_TWI_REG_ADDR_H;
> +}
> +
> +static const struct regmap_config ac200_regmap_config = {
> +	.name = "ac200",
> +	.reg_bits = 8,
> +	.reg_stride = 2,
> +	.val_bits = 16,
> +	.ranges = ac200_range_cfg,
> +	.num_ranges = ARRAY_SIZE(ac200_range_cfg),
> +	.max_register = AC200_MAX_REG,
> +	.volatile_reg = ac200_volatile_reg,
> +	.cache_type = REGCACHE_MAPLE,
> +};
> +
> +static void ac200_disable(void *data)
> +{
> +	struct ac200 *ddata = data;
> +
> +	regmap_write(ddata->regmap, AC200_SYS_CONTROL_REG, 0);
> +}

You can't do this in .remove()?

> +static int ac200_probe(struct i2c_client *client)
> +{
> +	struct device *dev = &client->dev;
> +	unsigned int version;
> +	struct ac200 *ddata;
> +	struct clk *clk;
> +	int ret;
> +
> +	ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> +	if (!ddata)
> +		return -ENOMEM;
> +
> +	clk = devm_clk_get_enabled(dev, NULL);
> +	if (IS_ERR(clk))
> +		return dev_err_probe(dev, PTR_ERR(clk),
> +				     "failed to enable input clock\n");
> +
> +	ret = devm_clk_rate_exclusive_get(dev, clk);
> +	if (ret)
> +		return dev_err_probe(dev, ret, "failed to lock clock rate\n");
> +
> +	ddata->regmap = devm_regmap_init_i2c(client, &ac200_regmap_config);
> +	if (IS_ERR(ddata->regmap))
> +		return dev_err_probe(dev, PTR_ERR(ddata->regmap),
> +				     "failed to initialize regmap\n");
> +
> +	i2c_set_clientdata(client, ddata);
> +
> +	/*
> +	 * No minimum delay is documented. Match the vendor driver's 40 ms delay
> +	 * before its first AC200 register access after enabling the input clock.
> +	 */
> +	msleep(40);
> +
> +	ret = regmap_read(ddata->regmap, AC200_SYS_VERSION_REG, &version);
> +	if (ret)
> +		return dev_err_probe(dev, ret,
> +				     "failed to read chip version\n");
> +
> +	dev_info(dev, "AC200 revision %#lx in package %lu\n",
> +		 FIELD_GET(AC200_SYS_VERSION_CHIP_MASK, version),
> +		 FIELD_GET(AC200_SYS_VERSION_PACKAGE_MASK, version));

We support all versions, so why print it out at all?

> +	/* Reset the chip after dependent function drivers have unbound. */
> +	ret = devm_add_action_or_reset(dev, ac200_disable, ddata);
> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_write(ddata->regmap, AC200_SYS_CONTROL_REG, 0);
> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_write(ddata->regmap, AC200_SYS_CONTROL_REG,
> +			   AC200_SYS_CONTROL_CHIP_RESET_DEASSERT);
> +	if (ret)
> +		return ret;

Okay, now what?  What uses this regmap?

> +	return 0;
> +}
> +
> +static void ac200_shutdown(struct i2c_client *client)
> +{
> +	ac200_disable(i2c_get_clientdata(client));
> +}
> +
> +static const struct of_device_id ac200_of_match[] = {
> +	{ .compatible = "x-powers,ac200" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(of, ac200_of_match);
> +
> +static const struct i2c_device_id ac200_i2c_ids[] = {
> +	{ .name = "ac200" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(i2c, ac200_i2c_ids);
> +
> +static struct i2c_driver ac200_driver = {
> +	.driver = {
> +		.name = "ac200",
> +		.of_match_table = ac200_of_match,
> +	},
> +	.probe = ac200_probe,
> +	.shutdown = ac200_shutdown,
> +	.id_table = ac200_i2c_ids,
> +};
> +module_i2c_driver(ac200_driver);
> +
> +MODULE_AUTHOR("James Hilliard <james.hilliard1@gmail.com>");
> +MODULE_DESCRIPTION("X-Powers AC200 MFD core driver");
> +MODULE_LICENSE("GPL");
> 
> -- 
> 2.53.0
> 

-- 
Lee Jones

Re: [PATCH v7 2/2] mfd: ac200: Add X-Powers AC200 support

[James Hilliard]

On Wed, Sep 2, 2026 at 8:31 AM Lee Jones <lee@kernel.org> wrote:
>
> On Tue, 11 Aug 2026, James Hilliard wrote:
>
> > The X-Powers AC200 is a mixed-signal companion IC with a paged register
> > map accessed over I2C.
> >
> > Enable the shared input clock and prevent its rate from changing. Match
> > the vendor driver's 40 ms wait before the first register access,
> > initialize the paged regmap, report the chip and package revision, and
> > apply common reset.
> >
> > The Ethernet PHY link endpoint is independently enumerated on its MDIO
> > bus rather than created as an MFD platform child. Keep the regmap attached
> > to the AC200 I2C device so a separately enumerated function can resolve
> > that device, establish its required lifetime relationship and retrieve
> > the regmap from the provider.
> >
> > Cache only the common page selector. Individual functions can reset
> > independently and invalidate their other registers without regmap's
> > knowledge, so leave all functional registers volatile.
> >
> > Reset the chip during managed teardown and system shutdown.
> >
> > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> > ---
> >  drivers/mfd/Kconfig  |  11 ++++
> >  drivers/mfd/Makefile |   1 +
> >  drivers/mfd/ac200.c  | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 175 insertions(+)
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index e4fd4572472f..cac3fff5aee9 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -205,6 +205,17 @@ config MFD_AC100
> >         This driver include only the core APIs. You have to select individual
> >         components like codecs or RTC under the corresponding menus.
> >
> > +config MFD_AC200
> > +     tristate "X-Powers AC200"
> > +     depends on I2C
> > +     depends on OF
> > +     select REGMAP_I2C
> > +     help
> > +       Support for the X-Powers AC200 mixed-signal companion IC. The AC200
> > +       contains audio, video, RTC and Fast Ethernet PHY functions and is
> > +       co-packaged with some Allwinner H6 and H616 SoCs. This driver provides
> > +       the shared register access used by the individual function drivers.
> > +
> >  config MFD_AXP20X
> >       tristate
> >       select MFD_CORE
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 72d3944b0ad8..f8101d2a9ce9 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -150,6 +150,7 @@ obj-$(CONFIG_MFD_DA9052_SPI)      += da9052-spi.o
> >  obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
> >
> >  obj-$(CONFIG_MFD_AC100)              += ac100.o
> > +obj-$(CONFIG_MFD_AC200)              += ac200.o
> >  obj-$(CONFIG_MFD_AXP20X)     += axp20x.o
> >  obj-$(CONFIG_MFD_AXP20X_I2C) += axp20x-i2c.o
> >  obj-$(CONFIG_MFD_AXP20X_RSB) += axp20x-rsb.o
> > diff --git a/drivers/mfd/ac200.c b/drivers/mfd/ac200.c
> > new file mode 100644
> > index 000000000000..0964e637afef
> > --- /dev/null
> > +++ b/drivers/mfd/ac200.c
> > @@ -0,0 +1,163 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * MFD core driver for the X-Powers AC200
> > + *
> > + * Copyright (C) 2019 Jernej Skrabec <jernej.skrabec@gmail.com>
> > + * Copyright (C) 2026 James Hilliard <james.hilliard1@gmail.com>
> > + *
> > + * Based on the AC100 driver:
> > + * Copyright (C) 2016 Chen-Yu Tsai
>
> Drop this.  Every driver tends to be based on something else.

Dropped in v8.

>
> > + */
> > +
> > +#include <linux/bitfield.h>
> > +#include <linux/clk.h>
> > +#include <linux/delay.h>
> > +#include <linux/i2c.h>
> > +#include <linux/module.h>
> > +#include <linux/regmap.h>
>
> Why aren't you using the MFD API?
>
> If you don't need it, then why is this in drivers/mfd?

The EPHY remains enumerated on its primary MDIO bus, so it is not an MFD
child. For non-EPHY use cases, the AC200 audio, video and RTC functions
are intended to be added as MFD children.

There are no such child drivers in this series, so I have not added
unused MFD cells. Those can be introduced with their corresponding
bindings and drivers.

>
> > +#define AC200_SYS_VERSION_REG                        0x0000
> > +#define AC200_SYS_VERSION_PACKAGE_MASK               GENMASK(15, 14)
> > +#define AC200_SYS_VERSION_CHIP_MASK          GENMASK(11, 0)
> > +
> > +#define AC200_SYS_CONTROL_REG                        0x0002
> > +#define AC200_SYS_CONTROL_CHIP_RESET_DEASSERT        BIT(0)
> > +
> > +/* Interface register accessible from every register page. */
> > +#define AC200_TWI_REG_ADDR_H 0x00fe
> > +#define AC200_MAX_REG                0xa1f2
> > +
> > +struct ac200 {
> > +     struct regmap *regmap;
> > +};
>
> Why not just pass 'regmap' directly?

Changed to store the regmap directly as the I2C driver data.

>
> > +static const struct regmap_range_cfg ac200_range_cfg[] = {
> > +     {
> > +             .range_max = AC200_MAX_REG,
> > +             .selector_reg = AC200_TWI_REG_ADDR_H,
> > +             .selector_mask = 0xff,
> > +             .window_len = 256,
> > +     },
> > +};
> > +
> > +/*
> > + * Each AC200 sub-block can reset independently, invalidating its register
> > + * contents without regmap's knowledge. Cache only the common page selector;
> > + * this avoids a selector read-modify-write for every access on the same page
> > + * without ever returning stale functional-register values.
> > + */
> > +static bool ac200_volatile_reg(struct device *dev, unsigned int reg)
> > +{
> > +     return reg != AC200_TWI_REG_ADDR_H;
> > +}
> > +
> > +static const struct regmap_config ac200_regmap_config = {
> > +     .name = "ac200",
> > +     .reg_bits = 8,
> > +     .reg_stride = 2,
> > +     .val_bits = 16,
> > +     .ranges = ac200_range_cfg,
> > +     .num_ranges = ARRAY_SIZE(ac200_range_cfg),
> > +     .max_register = AC200_MAX_REG,
> > +     .volatile_reg = ac200_volatile_reg,
> > +     .cache_type = REGCACHE_MAPLE,
> > +};
> > +
> > +static void ac200_disable(void *data)
> > +{
> > +     struct ac200 *ddata = data;
> > +
> > +     regmap_write(ddata->regmap, AC200_SYS_CONTROL_REG, 0);
> > +}
>
> You can't do this in .remove()?

Changed to reset the chip from the I2C remove callback.

>
> > +static int ac200_probe(struct i2c_client *client)
> > +{
> > +     struct device *dev = &client->dev;
> > +     unsigned int version;
> > +     struct ac200 *ddata;
> > +     struct clk *clk;
> > +     int ret;
> > +
> > +     ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> > +     if (!ddata)
> > +             return -ENOMEM;
> > +
> > +     clk = devm_clk_get_enabled(dev, NULL);
> > +     if (IS_ERR(clk))
> > +             return dev_err_probe(dev, PTR_ERR(clk),
> > +                                  "failed to enable input clock\n");
> > +
> > +     ret = devm_clk_rate_exclusive_get(dev, clk);
> > +     if (ret)
> > +             return dev_err_probe(dev, ret, "failed to lock clock rate\n");
> > +
> > +     ddata->regmap = devm_regmap_init_i2c(client, &ac200_regmap_config);
> > +     if (IS_ERR(ddata->regmap))
> > +             return dev_err_probe(dev, PTR_ERR(ddata->regmap),
> > +                                  "failed to initialize regmap\n");
> > +
> > +     i2c_set_clientdata(client, ddata);
> > +
> > +     /*
> > +      * No minimum delay is documented. Match the vendor driver's 40 ms delay
> > +      * before its first AC200 register access after enabling the input clock.
> > +      */
> > +     msleep(40);
> > +
> > +     ret = regmap_read(ddata->regmap, AC200_SYS_VERSION_REG, &version);
> > +     if (ret)
> > +             return dev_err_probe(dev, ret,
> > +                                  "failed to read chip version\n");
> > +
> > +     dev_info(dev, "AC200 revision %#lx in package %lu\n",
> > +              FIELD_GET(AC200_SYS_VERSION_CHIP_MASK, version),
> > +              FIELD_GET(AC200_SYS_VERSION_PACKAGE_MASK, version));
>
> We support all versions, so why print it out at all?

Removed the revision read and log message.

> > +     /* Reset the chip after dependent function drivers have unbound. */
> > +     ret = devm_add_action_or_reset(dev, ac200_disable, ddata);
> > +     if (ret)
> > +             return ret;
> > +
> > +     ret = regmap_write(ddata->regmap, AC200_SYS_CONTROL_REG, 0);
> > +     if (ret)
> > +             return ret;
> > +
> > +     ret = regmap_write(ddata->regmap, AC200_SYS_CONTROL_REG,
> > +                        AC200_SYS_CONTROL_CHIP_RESET_DEASSERT);
> > +     if (ret)
> > +             return ret;
>
> Okay, now what?  What uses this regmap?

The current consumer is the separately submitted AC200/AC300 PHY driver.
It creates a managed device link to the AC200 I2C device and obtains the
regmap with dev_get_regmap() for ancillary package-control access.

v8:
https://patch.msgid.link/20260902-submit-ac200-mfd-v8-0-2aa06720b8ac@gmail.com

>
> > +     return 0;
> > +}
> > +
> > +static void ac200_shutdown(struct i2c_client *client)
> > +{
> > +     ac200_disable(i2c_get_clientdata(client));
> > +}
> > +
> > +static const struct of_device_id ac200_of_match[] = {
> > +     { .compatible = "x-powers,ac200" },
> > +     { }
> > +};
> > +MODULE_DEVICE_TABLE(of, ac200_of_match);
> > +
> > +static const struct i2c_device_id ac200_i2c_ids[] = {
> > +     { .name = "ac200" },
> > +     { }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, ac200_i2c_ids);
> > +
> > +static struct i2c_driver ac200_driver = {
> > +     .driver = {
> > +             .name = "ac200",
> > +             .of_match_table = ac200_of_match,
> > +     },
> > +     .probe = ac200_probe,
> > +     .shutdown = ac200_shutdown,
> > +     .id_table = ac200_i2c_ids,
> > +};
> > +module_i2c_driver(ac200_driver);
> > +
> > +MODULE_AUTHOR("James Hilliard <james.hilliard1@gmail.com>");
> > +MODULE_DESCRIPTION("X-Powers AC200 MFD core driver");
> > +MODULE_LICENSE("GPL");
> >
> > --
> > 2.53.0
> >
>
> --
> Lee Jones

Re: [PATCH v7 2/2] mfd: ac200: Add X-Powers AC200 support

[Lee Jones]

On Wed, 02 Sep 2026, James Hilliard wrote:

> On Wed, Sep 2, 2026 at 8:31 AM Lee Jones <lee@kernel.org> wrote:
> >
> > On Tue, 11 Aug 2026, James Hilliard wrote:
> >
> > > The X-Powers AC200 is a mixed-signal companion IC with a paged register
> > > map accessed over I2C.
> > >
> > > Enable the shared input clock and prevent its rate from changing. Match
> > > the vendor driver's 40 ms wait before the first register access,
> > > initialize the paged regmap, report the chip and package revision, and
> > > apply common reset.
> > >
> > > The Ethernet PHY link endpoint is independently enumerated on its MDIO
> > > bus rather than created as an MFD platform child. Keep the regmap attached
> > > to the AC200 I2C device so a separately enumerated function can resolve
> > > that device, establish its required lifetime relationship and retrieve
> > > the regmap from the provider.
> > >
> > > Cache only the common page selector. Individual functions can reset
> > > independently and invalidate their other registers without regmap's
> > > knowledge, so leave all functional registers volatile.
> > >
> > > Reset the chip during managed teardown and system shutdown.
> > >
> > > Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
> > > ---
> > >  drivers/mfd/Kconfig  |  11 ++++
> > >  drivers/mfd/Makefile |   1 +
> > >  drivers/mfd/ac200.c  | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > >  3 files changed, 175 insertions(+)
> > >
> > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > > index e4fd4572472f..cac3fff5aee9 100644
> > > --- a/drivers/mfd/Kconfig
> > > +++ b/drivers/mfd/Kconfig
> > > @@ -205,6 +205,17 @@ config MFD_AC100
> > >         This driver include only the core APIs. You have to select individual
> > >         components like codecs or RTC under the corresponding menus.
> > >
> > > +config MFD_AC200
> > > +     tristate "X-Powers AC200"
> > > +     depends on I2C
> > > +     depends on OF
> > > +     select REGMAP_I2C
> > > +     help
> > > +       Support for the X-Powers AC200 mixed-signal companion IC. The AC200
> > > +       contains audio, video, RTC and Fast Ethernet PHY functions and is
> > > +       co-packaged with some Allwinner H6 and H616 SoCs. This driver provides
> > > +       the shared register access used by the individual function drivers.
> > > +
> > >  config MFD_AXP20X
> > >       tristate
> > >       select MFD_CORE
> > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > > index 72d3944b0ad8..f8101d2a9ce9 100644
> > > --- a/drivers/mfd/Makefile
> > > +++ b/drivers/mfd/Makefile
> > > @@ -150,6 +150,7 @@ obj-$(CONFIG_MFD_DA9052_SPI)      += da9052-spi.o
> > >  obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
> > >
> > >  obj-$(CONFIG_MFD_AC100)              += ac100.o
> > > +obj-$(CONFIG_MFD_AC200)              += ac200.o
> > >  obj-$(CONFIG_MFD_AXP20X)     += axp20x.o
> > >  obj-$(CONFIG_MFD_AXP20X_I2C) += axp20x-i2c.o
> > >  obj-$(CONFIG_MFD_AXP20X_RSB) += axp20x-rsb.o
> > > diff --git a/drivers/mfd/ac200.c b/drivers/mfd/ac200.c
> > > new file mode 100644
> > > index 000000000000..0964e637afef
> > > --- /dev/null
> > > +++ b/drivers/mfd/ac200.c
> > > @@ -0,0 +1,163 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * MFD core driver for the X-Powers AC200
> > > + *
> > > + * Copyright (C) 2019 Jernej Skrabec <jernej.skrabec@gmail.com>
> > > + * Copyright (C) 2026 James Hilliard <james.hilliard1@gmail.com>
> > > + *
> > > + * Based on the AC100 driver:
> > > + * Copyright (C) 2016 Chen-Yu Tsai
> >
> > Drop this.  Every driver tends to be based on something else.
> 
> Dropped in v8.
> 
> >
> > > + */
> > > +
> > > +#include <linux/bitfield.h>
> > > +#include <linux/clk.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/i2c.h>
> > > +#include <linux/module.h>
> > > +#include <linux/regmap.h>
> >
> > Why aren't you using the MFD API?
> >
> > If you don't need it, then why is this in drivers/mfd?
> 
> The EPHY remains enumerated on its primary MDIO bus, so it is not an MFD
> child. For non-EPHY use cases, the AC200 audio, video and RTC functions
> are intended to be added as MFD children.
> 
> There are no such child drivers in this series, so I have not added
> unused MFD cells. Those can be introduced with their corresponding
> bindings and drivers.

The rule is that you must provide at least 2 MFD children before this
constitute as an MFD.  Please provide them in the same series.

-- 
Lee Jones