Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <1d379f28f54fd025f687bfcb71e4bae5.sboyd@kernel.org>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <ad908782-8291-4240-d88e-61dff5a05ef7@gmail.com>
References: <20230328021912.177301-1-ychuang570808@gmail.com> <20230328021912.177301-9-ychuang570808@gmail.com> <ab4e0bc8834b7e618e9a88ea6a1c30cc.sboyd@kernel.org> <b7977069-4f82-76a1-10c1-b6400862c2c4@gmail.com> <c37e1f3a40c404acd81c2c9d5b28b340.sboyd@kernel.org> <129cf4b6-b3b5-2a12-5911-37e70a624812@gmail.com> <e5221cd020bc60513df6a1c1859e1acc.sboyd@kernel.org> <ad908782-8291-4240-d88e-61dff5a05ef7@gmail.com>
Subject: Re: [PATCH v6 08/12] arm64: dts: nuvoton: Add initial ma35d1 device tree
From:   Stephen Boyd <sboyd@kernel.org>
Cc:     devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
        arnd@arndb.de, schung@nuvoton.com, mjchen@nuvoton.com,
        Jacky Huang <ychuang3@nuvoton.com>
To:     Jacky Huang <ychuang570808@gmail.com>, gregkh@linuxfoundation.org,
        jirislaby@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        lee@kernel.org, mturquette@baylibre.com, p.zabel@pengutronix.de,
        robh+dt@kernel.org
Date:   Tue, 28 Mar 2023 20:25:50 -0700
User-Agent: alot/0.10
Precedence: bulk

Quoting Jacky Huang (2023-03-28 20:13:11)
> Dear Stephen,
>=20
>=20
> On 2023/3/29 =E4=B8=8A=E5=8D=88 10:46, Stephen Boyd wrote:
> > Quoting Jacky Huang (2023-03-28 19:39:36)
> >> On 2023/3/29 =E4=B8=8A=E5=8D=88 10:19, Stephen Boyd wrote:
> >>> What do you use the syscon for then? The clock driver must want to use
> >>> the syscon for something, implying that they are the same device.
> >> The register lock mechanism is applied to protect many critical
> >> registers from false written.
> >> The register lock control register is one register in system controlle=
r.
> >> Some registers of the clock controller are lock protected. Not only
> >> clock controller, but other
> >> IP such as RTC, PWM, ADC, etc, also have lock protected registers. All
> >> these IP requires
> >> syscon to access the lock/unlock control register in the system contro=
ller.
> >> That's why we add a <&sys> to the clock controller.
> >>
> >> Should we implement a ma35d1-sysctl driver to protect register_lock()
> >> and register_unlock()
> >> and export to those drivers?=C2=A0 If yes, we can remove the <&sys> fr=
om
> >> clock controller.
> >>
> > You can implement the lock and unlock in the hwspinlock framework. See
> > drivers/hwspinlock.
>=20
> I may not explain clearly enough. The lock/unlock register of system=20
> controller is more like
> a kind of write protection for specific registers, rather than=20
> preventing hetero-core CPU access.
> In many different IP of ma35d1 contain write protected registers.
> In fact, ma35d1 has a "hardware semaphore" IP, and we have implemented=20
> the driver in drivers/hwspinlock.
> Even the control register of "hardware semaphore" is also write protected.

What's the need to lock and unlock the registers? Is some other
processor also writing to the registers that we need to synchronize
against? Or is Linux the only entity reading and writing the registers?
I'm wondering if we should simply unlock the registers and never lock
them.

>=20
> So, should we implement a system controller driver to provide=20
> register_unlock() function?
> Is it OK to have such a driver in drivers/mfd?
> Or, just use syscon in device tree for those devices that have write=20
> protect registers.
>=20

The hwspinlock framework doesn't require there to be another entity
accessing some resource. It's there to implement hardware locks. I don't
see why it can't be used here.