Date:   Fri, 11 Dec 2020 16:20:55 +0100
From:   Wilken Gottwalt <wilken.gottwalt@...teo.net>
To:     unlisted-recipients:; (no To-header on input)
Cc:     linux-kernel@...r.kernel.org, Ohad Ben-Cohen <ohad@...ery.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Baolin Wang <baolin.wang7@...il.com>,
        Rob Herring <robh+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        Jernej Skrabec <jernej.skrabec@...l.net>
Subject: Re: [PATCH v4 2/2] hwspinlock: add sun8i hardware spinlock support

On Fri, 11 Dec 2020 10:03:12 +0100
Maxime Ripard <maxime@...no.tech> wrote:

> Hi,
> 
> On Fri, Dec 11, 2020 at 09:24:15AM +0100, Wilken Gottwalt wrote:
> > Adds the sun8i_hwspinlock driver for the hardware spinlock unit found in
> > most of the sun8i compatible SoCs.
> > 
> > This unit provides at least 32 spinlocks in hardware. The implementation
> > supports 32, 64, 128 or 256 32bit registers. A lock can be taken by
> > reading a register and released by writing a 0 to it. This driver
> > supports all 4 spinlock setups, but for now only the first setup (32
> > locks) seem to exist in available devices. This spinlock unit is shared
> > between all ARM cores and the embedded OpenRisc AR100 core. All of them
> > can take/release a lock with a single cycle operation. It can be used to
> > sync access to devices shared by the ARM cores and the OpenRisc core.
> > 
> > There are two ways to check if a lock is taken. The first way is to read
> > a lock. If a 0 is returned, the lock was free and is taken now. If an 1
> > is returned, the caller has to try again. Which means the lock is taken.
> > The second way is to read a 32bit wide status register where every bit
> > represents one of the 32 first locks. According to the datasheets this
> > status register supports only the 32 first locks. This is the reason the
> > first way (lock read/write) approach is used to be able to cover all 256
> > locks in future devices. The driver also reports the amount of supported
> > locks via debugfs.
> > 
> > Signed-off-by: Wilken Gottwalt <wilken.gottwalt@...teo.net>
> > ---
> > Changes in v4:
> >   - further simplified driver
> >   - fixed an add_action_and_reset_ function issue
> >   - changed bindings from sun8i-hwspinlock to sun8i-a33-hwspinlock
> > 
> > Changes in v3:
> >   - moved test description to cover letter
> >   - changed name and symbols from sunxi to sun8i
> >   - improved driver description
> >   - further simplified driver
> >   - fully switched to devm_* and devm_add_action_* functions
> > 
> > Changes in v2:
> >   - added suggestions from Bjorn Andersson and Maxime Ripard
> >   - provided better driver and test description
> > ---
> >  MAINTAINERS                           |   6 +
> >  drivers/hwspinlock/Kconfig            |   9 ++
> >  drivers/hwspinlock/Makefile           |   1 +
> >  drivers/hwspinlock/sun8i_hwspinlock.c | 197 ++++++++++++++++++++++++++
> >  4 files changed, 213 insertions(+)
> >  create mode 100644 drivers/hwspinlock/sun8i_hwspinlock.c
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index ebe4829cdd4d..46846113f1eb 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -722,6 +722,12 @@ L:	linux-crypto@...r.kernel.org
> >  S:	Maintained
> >  F:	drivers/crypto/allwinner/
> >  
> > +ALLWINNER HARDWARE SPINLOCK SUPPORT
> > +M:	Wilken Gottwalt <wilken.gottwalt@...teo.net>
> > +S:	Maintained
> > +F:	Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml
> > +F:	drivers/hwspinlock/sun8i_hwspinlock.c
> > +
> >  ALLWINNER THERMAL DRIVER
> >  M:	Vasily Khoruzhick <anarsoul@...il.com>
> >  M:	Yangtao Li <tiny.windzz@...il.com>
> > diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
> > index 32cd26352f38..b03fd99aab32 100644
> > --- a/drivers/hwspinlock/Kconfig
> > +++ b/drivers/hwspinlock/Kconfig
> > @@ -55,6 +55,15 @@ config HWSPINLOCK_STM32
> >  
> >  	  If unsure, say N.
> >  
> > +config HWSPINLOCK_SUN8I
> > +	tristate "SUN8I Hardware Spinlock device"
> > +	depends on ARCH_SUNXI || COMPILE_TEST
> > +	help
> > +	  Say y here to support the SUN8I Hardware Spinlock device which can be
> > +	  found in most of the sun8i compatible Allwinner SoCs.
> > +
> > +	  If unsure, say N.
> > +
> >  config HSEM_U8500
> >  	tristate "STE Hardware Semaphore functionality"
> >  	depends on ARCH_U8500 || COMPILE_TEST
> > diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
> > index ed053e3f02be..3496648d9257 100644
> > --- a/drivers/hwspinlock/Makefile
> > +++ b/drivers/hwspinlock/Makefile
> > @@ -9,4 +9,5 @@ obj-$(CONFIG_HWSPINLOCK_QCOM)		+= qcom_hwspinlock.o
> >  obj-$(CONFIG_HWSPINLOCK_SIRF)		+= sirf_hwspinlock.o
> >  obj-$(CONFIG_HWSPINLOCK_SPRD)		+= sprd_hwspinlock.o
> >  obj-$(CONFIG_HWSPINLOCK_STM32)		+= stm32_hwspinlock.o
> > +obj-$(CONFIG_HWSPINLOCK_SUN8I)		+= sun8i_hwspinlock.o
> >  obj-$(CONFIG_HSEM_U8500)		+= u8500_hsem.o
> > diff --git a/drivers/hwspinlock/sun8i_hwspinlock.c b/drivers/hwspinlock/sun8i_hwspinlock.c
> > new file mode 100644
> > index 000000000000..878dae6f1763
> > --- /dev/null
> > +++ b/drivers/hwspinlock/sun8i_hwspinlock.c
> > @@ -0,0 +1,197 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * sun8i_hwspinlock.c - hardware spinlock driver for sun8i compatible Allwinner SoCs
> > + * Copyright (C) 2020 Wilken Gottwalt <wilken.gottwalt@...teo.net>
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/debugfs.h>
> > +#include <linux/errno.h>
> > +#include <linux/hwspinlock.h>
> > +#include <linux/io.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/reset.h>
> > +#include <linux/slab.h>
> > +#include <linux/spinlock.h>
> > +#include <linux/types.h>
> > +
> > +#include "hwspinlock_internal.h"
> > +
> > +#define DRIVER_NAME		"sun8i_hwspinlock"
> > +
> > +#define SPINLOCK_BASE_ID	0 /* there is only one hwspinlock device per SoC */
> > +#define SPINLOCK_SYSSTATUS_REG	0x0000
> > +#define SPINLOCK_LOCK_REGN	0x0100
> > +#define SPINLOCK_NOTTAKEN	0
> > +
> > +struct sun8i_hwspinlock_data {
> > +	struct hwspinlock_device *bank;
> > +	struct reset_control *reset;
> > +	struct clk *ahb_clk;
> > +	struct dentry *debugfs;
> > +	int nlocks;
> > +};
> > +
> > +#ifdef CONFIG_DEBUG_FS
> > +
> > +static int hwlocks_supported_show(struct seq_file *seqf, void *unused)
> > +{
> > +	struct sun8i_hwspinlock_data *priv = seqf->private;
> > +
> > +	seq_printf(seqf, "%d\n", priv->nlocks);
> > +
> > +	return 0;
> > +}
> > +DEFINE_SHOW_ATTRIBUTE(hwlocks_supported);
> > +
> > +static void sun8i_hwspinlock_debugfs_init(struct sun8i_hwspinlock_data *priv)
> > +{
> > +	priv->debugfs = debugfs_create_dir(DRIVER_NAME, NULL);
> 
> debugfs_create_dir can return an error pointer, you should check that
> and return the error code if it does
> 
> > +	debugfs_create_file("supported", 0444, priv->debugfs, priv, &hwlocks_supported_fops);
> 
> And debugfs_create_file can fail as well

Now I'm a bit confused. The hwmon subsystem maintainer states, that a following
check is discouraged and often gets a remove patch.

>> +	debugfs = debugfs_create_dir(name, NULL);
>> +	if (debugfs) {    
>
>Drop the if; it is discouraged to check the return value from
>debugfs_create_dir() (and if we were to keep it, I'd get a
>follow-up patch from branch watchers to remove it).

> > +}
> > +
> > +#else
> > +
> > +static void sun8i_hwspinlock_debugfs_init(struct sun8i_hwspinlock_data *priv)
> > +{
> > +}
> > +
> > +#endif
> > +
> > +static int sun8i_hwspinlock_trylock(struct hwspinlock *lock)
> > +{
> > +	void __iomem *lock_addr = lock->priv;
> > +
> > +	return (readl(lock_addr) == SPINLOCK_NOTTAKEN);
> > +}
> > +
> > +static void sun8i_hwspinlock_unlock(struct hwspinlock *lock)
> > +{
> > +	void __iomem *lock_addr = lock->priv;
> > +
> > +	writel(SPINLOCK_NOTTAKEN, lock_addr);
> > +}
> > +
> > +static const struct hwspinlock_ops sun8i_hwspinlock_ops = {
> > +	.trylock	= sun8i_hwspinlock_trylock,
> > +	.unlock		= sun8i_hwspinlock_unlock,
> > +};
> > +
> > +static void sun8i_hwspinlock_disable(void *data)
> > +{
> > +	struct sun8i_hwspinlock_data *priv = data;
> > +
> > +	debugfs_remove_recursive(priv->debugfs);
> > +	reset_control_assert(priv->reset);
> > +	clk_disable_unprepare(priv->ahb_clk);
> > +}
> > +
> > +static int sun8i_hwspinlock_probe(struct platform_device *pdev)
> > +{
> > +	struct sun8i_hwspinlock_data *priv;
> > +	struct hwspinlock *hwlock;
> > +	void __iomem *io_base;
> > +	u32 num_banks;
> > +	int err, i;
> > +
> > +	io_base = devm_platform_ioremap_resource(pdev, SPINLOCK_BASE_ID);
> > +	if (IS_ERR(io_base))
> > +		return PTR_ERR(io_base);
> > +
> > +	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> > +	if (!priv)
> > +		return -ENOMEM;
> > +
> > +	priv->ahb_clk = devm_clk_get(&pdev->dev, "ahb");
> > +	if (IS_ERR(priv->ahb_clk)) {
> > +		err = PTR_ERR(priv->ahb_clk);
> > +		dev_err(&pdev->dev, "unable to get AHB clock (%d)\n", err);
> > +		return err;
> > +	}
> > +
> > +	priv->reset = devm_reset_control_get(&pdev->dev, "ahb");
> > +	if (IS_ERR(priv->reset))
> > +		return dev_err_probe(&pdev->dev, PTR_ERR(priv->reset),
> > +				     "unable to get reset control\n");
> > +
> > +	err = reset_control_deassert(priv->reset);
> > +	if (err) {
> > +		dev_err(&pdev->dev, "deassert reset control failure (%d)\n", err);
> > +		return err;
> > +	}
> > +
> > +	err = clk_prepare_enable(priv->ahb_clk);
> > +	if (err) {
> > +		dev_err(&pdev->dev, "unable to prepare AHB clk (%d)\n", err);
> > +		return err;
> > +	}
> > +
> > +	sun8i_hwspinlock_debugfs_init(priv);
> > +
> > +	err = devm_add_action_or_reset(&pdev->dev, sun8i_hwspinlock_disable, priv);
> > +	if (err) {
> > +		dev_err(&pdev->dev, "unable to add disable action\n");
> > +		return err;
> > +	}
> 
> That part still doesn't really work: if clk_prepare_enable fails, you'll
> end up removing the debugfs files that haven't been added yet, and
> you'll disable the clock that hasn't been enabled.

Are you sure about this? The function is secured against error and null pointers.

debugfs_create_file and debugfs_create_dir both create ERR_ macro covered return
values which are checked against ERR_ macros throughout the whole debugfs
functions. I mean that may be the reason "extensive/double" checking is
discouraged. I just wonder why it is handled so different between subsystem
maintainers.

#define debugfs_remove_recursive debugfs_remove
void debugfs_remove(struct dentry *dentry)
{
	if (IS_ERR_OR_NULL(dentry))
		return;

> I'm not sure you need to be that smart: just add a label and a goto to
> the proper cleaning stuff
> 
> Maxime

Powered by blists - more mailing lists