[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a4ff0a8571895c65ed5c20abd0c332b0d92defab.camel@pengutronix.de>
Date: Mon, 13 Jan 2020 10:15:58 +0100
From: Philipp Zabel <p.zabel@...gutronix.de>
To: Samuel Holland <samuel@...lland.org>,
Maxime Ripard <mripard@...nel.org>,
Chen-Yu Tsai <wens@...e.org>,
Jassi Brar <jassisinghbrar@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Ondrej Jirman <megous@...ous.com>,
Vasily Khoruzhick <anarsoul@...il.com>
Cc: devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-sunxi@...glegroups.com
Subject: Re: [PATCH v6 2/6] mailbox: sun6i-msgbox: Add a new mailbox driver
On Sun, 2020-01-12 at 23:18 -0600, Samuel Holland wrote:
> Allwinner sun6i, sun8i, sun9i, and sun50i SoCs contain a hardware
> message box used for communication between the ARM CPUs and the ARISC
> management coprocessor. This mailbox contains 8 unidirectional
> 4-message FIFOs.
>
> Add a driver for it, so it can be used for SCPI or other communication
> protocols.
>
> Signed-off-by: Samuel Holland <samuel@...lland.org>
> ---
> drivers/mailbox/Kconfig | 9 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/sun6i-msgbox.c | 332 +++++++++++++++++++++++++++++++++
> 3 files changed, 343 insertions(+)
> create mode 100644 drivers/mailbox/sun6i-msgbox.c
>
[...]
> diff --git a/drivers/mailbox/sun6i-msgbox.c b/drivers/mailbox/sun6i-msgbox.c
> new file mode 100644
> index 000000000000..15d6fd522dc5
> --- /dev/null
> +++ b/drivers/mailbox/sun6i-msgbox.c
> @@ -0,0 +1,332 @@
[...]
> + reset = devm_reset_control_get_exclusive(dev, NULL);
> + if (IS_ERR(reset)) {
> + ret = PTR_ERR(reset);
> + dev_err(dev, "Failed to get reset control: %d\n", ret);
> + goto err_disable_unprepare;
> + }
> +
> + /*
> + * NOTE: We rely on platform firmware to preconfigure the channel
> + * directions, and we share this hardware block with other firmware
> + * that runs concurrently with Linux (e.g. a trusted monitor).
> + *
> + * Therefore, we do *not* assert the reset line if probing fails or
> + * when removing the device.
> + */
> + ret = reset_control_deassert(reset);
> + if (ret) {
> + dev_err(dev, "Failed to deassert reset: %d\n", ret);
> + goto err_disable_unprepare;
> + }
Reviewed-by: Philipp Zabel <p.zabel@...gutronix.de>
regards
Philipp
Powered by blists - more mailing lists