[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5036B4BD.70208@wwwdotorg.org>
Date: Thu, 23 Aug 2012 16:54:53 -0600
From: Stephen Warren <swarren@...dotorg.org>
To: Timur Tabi <timur@...escale.com>
CC: Andy Fleming <afleming@...escale.com>,
David Miller <davem@...emloft.net>, ddaney.cavm@...il.com,
netdev@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org
Subject: Re: [PATCH] [v2] netdev/phy: add MDIO bus multiplexer driven by a
memory-mapped device
On 08/23/2012 01:44 PM, Timur Tabi wrote:
> Add support for an MDIO bus multiplexer controlled by a simple memory-mapped
> device, like an FPGA. The device must be memory-mapped and contain only
> 8-bit registers (which keeps things simple).
> +++ b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt
> + /* The FPGA node */
> + fpga: board-control@3,0 {
> + compatible = "fsl,p5020ds-fpga", "fsl,fpga-ngpixis";
> + reg = <3 0 0x30>;
Why not add the following here:
#address-cells = <1>:
#size-cells = <1>;
ranges = <...>;
> +
> + mdio-mux-emi2 {
> + compatible = "mdio-mux-mmioreg", "mdio-mux";
> + mdio-parent-bus = <&xmdio0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <9>; // BRDCFG1
Then, that'd have to be <9 1>;
That way, ...
> diff --git a/drivers/net/phy/mdio-mux-mmioreg.c b/drivers/net/phy/mdio-mux-mmioreg.c
> +static int __devinit mdio_mux_mmioreg_probe(struct platform_device *pdev)
> + /* The MMIO device is the parent of this device */
> + np2 = of_get_parent(np);
> + if (!np2) {
> + dev_err(&pdev->dev, "could not find parent MMIO device\n");
> + return -ENODEV;
> + }
> +
> + ret = of_address_to_resource(np2, 0, &res);
> + if (ret) {
> + dev_err(&pdev->dev, "could not obtain memory map for node %s\n",
> + np2->full_name);
> + return ret;
> + }
> + s->phys = res.start;
You could simplify all that into just "of_iomap(np, 0)", and all the
address translation etc. happens entirely automatically, in the standard
fashion for DT.
The advantage here is that it completely decouples the mdio-mux-mmioreg
driver from any knowledge of its parent; you could just as easily use
this driver/binding as a device directly on some SoC bus, rather than
requiring there to be a parent device above it. After all, the mux
register might be some random standalone on-SoC register (although I
wonder if that case might not be better covered by a mdio-mux-pinctrl
driver instead; I guess it depends on how special-purpose the mux
register is).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists