linux-kernel - Re: [PATCH v2] mfd: syscon: add child device support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 24 Nov 2014 12:11:10 +0100
From:	Philipp Zabel <p.zabel@...gutronix.de>
To:	Rob Herring <robh+dt@...nel.org>
Cc:	Lee Jones <lee.jones@...aro.org>, Arnd Bergmann <arnd@...db.de>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Flora Fu <flora.fu@...iatek.com>, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [PATCH v2] mfd: syscon: add child device support

Hi,

On Mon, 2014-11-03 at 10:16 +0100, Philipp Zabel wrote:
> For devices which have a complete register for themselves, it is possible to
> place them next to the syscon device with overlapping reg ranges. The same is
> not possible for devices which only occupy bitfields in registers shared with
> other users.
> For devices that are completely controlled by bitfields in the syscon address
> range, such as multiplexers or voltage regulators, allow to put child devices
> into the syscon device node.

Could I please get an ack for the device tree binding change so the MFD
maintainers can take this patch? I'd like to queue the Mediatek reset
driver, which depends on this.

regards
Philipp

> Signed-off-by: Philipp Zabel <p.zabel@...gutronix.de>
> ---
> Changes since v1:
>  - Reworded binding documentation to allow #size-cells = <1>, which is useful
>    for syscon children that are controlled through a (possibly shared) register
>    range.
> ---
>  Documentation/devicetree/bindings/mfd/syscon.txt | 13 +++++++++++++
>  drivers/mfd/syscon.c                             |  3 +++
>  2 files changed, 16 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt b/Documentation/devicetree/bindings/mfd/syscon.txt
> index fe8150b..0c6b497 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> @@ -9,12 +9,25 @@ using a specific compatible value), interrogate the node (or associated
>  OS driver) to determine the location of the registers, and access the
>  registers directly.
>  
> +Optionally, devices that are controlled exclusively through syscon registers,
> +or even bitfields in shared syscon registers, can also be added as child nodes
> +to the syscon device node. These devices can implicitly assume their parent
> +node is a syscon provider without referencing it explicitly via phandle.
> +In this case, the syscon node should have #address-cells = <1> and
> +#size-cells = <0> or <1> and no ranges property.
> +
>  Required properties:
>  - compatible: Should contain "syscon".
>  - reg: the register region can be accessed from syscon
>  
> +Optional properties:
> +- #address-cells: Should be 1.
> +- #size-cells: Should be 0 or 1.
> +
>  Examples:
>  gpr: iomuxc-gpr@...e0000 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
>  	compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
>  	reg = <0x020e0000 0x38>;
>  };
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index ca15878..38da178 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -155,6 +155,9 @@ static int syscon_probe(struct platform_device *pdev)
>  
>  	dev_dbg(dev, "regmap %pR registered\n", res);
>  
> +	if (!of_device_is_compatible(pdev->dev.of_node, "simple-bus"))
> +		of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
> +
>  	return 0;
>  }
>  


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/