linux-kernel - Re: [PATCH v6 08/12] arm64: dts: nuvoton: Add initial ma35d1 device tree

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1d379f28f54fd025f687bfcb71e4bae5.sboyd@kernel.org>
Date:   Tue, 28 Mar 2023 20:25:50 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Jacky Huang <ychuang570808@...il.com>, gregkh@...uxfoundation.org,
        jirislaby@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        lee@...nel.org, mturquette@...libre.com, p.zabel@...gutronix.de,
        robh+dt@...nel.org
Cc:     devicetree@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
        arnd@...db.de, schung@...oton.com, mjchen@...oton.com,
        Jacky Huang <ychuang3@...oton.com>
Subject: Re: [PATCH v6 08/12] arm64: dts: nuvoton: Add initial ma35d1 device tree

Quoting Jacky Huang (2023-03-28 20:13:11)
> Dear Stephen,
> 
> 
> On 2023/3/29 上午 10:46, Stephen Boyd wrote:
> > Quoting Jacky Huang (2023-03-28 19:39:36)
> >> On 2023/3/29 上午 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 controller.
> >> 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 controller.
> >> 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?  If yes, we can remove the <&sys> from
> >> clock controller.
> >>
> > You can implement the lock and unlock in the hwspinlock framework. See
> > drivers/hwspinlock.
> 
> I may not explain clearly enough. The lock/unlock register of system 
> controller is more like
> a kind of write protection for specific registers, rather than 
> 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 
> 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.

> 
> So, should we implement a system controller driver to provide 
> 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 
> protect registers.
> 

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.