[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5c137862-e8fa-abb4-d931-f5c63db50649@st.com>
Date: Mon, 3 Dec 2018 09:46:03 +0100
From: Alexandre Torgue <alexandre.torgue@...com>
To: Benjamin Gaignard <benjamin.gaignard@...aro.org>,
<ohad@...ery.com>, <bjorn.andersson@...aro.org>,
<robh+dt@...nel.org>, <mark.rutland@....com>
CC: <devicetree@...r.kernel.org>,
Benjamin Gaignard <benjamin.gaignard@...com>,
<linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<linux-stm32@...md-mailman.stormreply.com>,
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 0/4] Add support of STM32 hwspinlock
Hi Benjamin,
On 11/12/18 4:23 PM, Benjamin Gaignard wrote:
> This serie adds the support of the hardware semaphore block for stm32mp1 SoC.
>
> version 3:
> - fix clock name in properties description.
> - use postcore_initcall() instead of module_platform_driver()
>
> version 2:
> - fix comments done by Bjorn about clock naming, license terms in header,
> alphabetic ordering in Makefile and Kconfig and remove function
> - Do not push test module in this version while waiting for feedbacks about it
>
>
> Benjamin Gaignard (4):
> dt-bindings: hwlock: Document STM32 hwspinlock bindings
> hwspinlock: add STM32 hwspinlock device
> ARM: dts: stm32: Add hwspinlock node for stm32mp157 SoC
> ARM: dts: stm32: enable hwspinlock on stm32mp157c-ed1
>
> .../bindings/hwlock/st,stm32-hwspinlock.txt | 23 +++
> arch/arm/boot/dts/stm32mp157c-ed1.dts | 4 +
> arch/arm/boot/dts/stm32mp157c.dtsi | 9 ++
> drivers/hwspinlock/Kconfig | 9 ++
> drivers/hwspinlock/Makefile | 1 +
> drivers/hwspinlock/stm32_hwspinlock.c | 156 +++++++++++++++++++++
> 6 files changed, 202 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.txt
> create mode 100644 drivers/hwspinlock/stm32_hwspinlock.c
>
There is a (strong) dependency between pinctrl and hsem.
As our pin controller is enabled by default, it's better to enable also
your hwspinlock device by default. It will avoid pin controller probe
defer and a no stable behavior. So, I gonna remove DT patches from
stm32-next. Those Dt patches will not be included in my 4.20 pull-request.
regards
Alex
Powered by blists - more mailing lists