[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <080600661d43e4c39ea4b20b05e3e141.sboyd@kernel.org>
Date: Wed, 11 Sep 2024 15:46:09 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Linus Walleij <linus.walleij@...aro.org>, Nikita Shubin <nikita.shubin@...uefel.me>, Nikita Shubin via B4 Relay <devnull+nikita.shubin.maquefel.me@...nel.org>, Thierry Reding <thierry.reding@...il.com>, Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v12 02/38] ARM: ep93xx: add regmap aux_dev
Quoting Nikita Shubin via B4 Relay (2024-09-09 01:10:27)
> diff --git a/include/linux/soc/cirrus/ep93xx.h b/include/linux/soc/cirrus/ep93xx.h
> index 56fbe2dc59b1..a27447971302 100644
> --- a/include/linux/soc/cirrus/ep93xx.h
> +++ b/include/linux/soc/cirrus/ep93xx.h
> @@ -3,6 +3,18 @@
> #define _SOC_EP93XX_H
>
> struct platform_device;
> +struct regmap;
> +struct spinlock_t;
> +
> +enum ep93xx_soc_model {
> + EP93XX_9301_SOC,
> + EP93XX_9307_SOC,
> + EP93XX_9312_SOC,
> +};
> +
> +#include <linux/auxiliary_bus.h>
> +#include <linux/compiler_types.h>
> +#include <linux/container_of.h>
>
> #define EP93XX_CHIP_REV_D0 3
> #define EP93XX_CHIP_REV_D1 4
> @@ -10,6 +22,20 @@ struct platform_device;
> #define EP93XX_CHIP_REV_E1 6
> #define EP93XX_CHIP_REV_E2 7
>
> +struct ep93xx_regmap_adev {
> + struct auxiliary_device adev;
> + struct regmap *map;
> + void __iomem *base;
> + spinlock_t *lock;
> + void (*write)(struct regmap *map, spinlock_t *lock, unsigned int reg,
> + unsigned int val);
> + void (*update_bits)(struct regmap *map, spinlock_t *lock,
> + unsigned int reg, unsigned int mask, unsigned int val);
> +};
Why can't the single 'struct regmap' be passed as the auxiliary device's
platform_data? The lock could be put into the regmap locking routines
and the write/update_bits would be standard regmap API calls. Doing that
would make the auxiliary device driver simpler because it wouldn't
depend on this struct.
The device name could encode the SoC number as well so the auxiliary
device driver could match different names and do different things.
Powered by blists - more mailing lists