From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 18/18] mfd: vexpress: Split sysreg functions into MFD cells
Date: Mon, 6 Jan 2014 10:40:30 +0000 [thread overview]
Message-ID: <20140106104030.GI23772@lee--X1> (raw)
In-Reply-To: <1387815830-8794-19-git-send-email-pawel.moll@arm.com>
> This patch splits individual sysreg functions into
> separate MFD cells, which then become individual
> platform devices with their own drivers.
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> ---
> .../devicetree/bindings/arm/vexpress-sysreg.txt | 37 ++-
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 76 ++++++-
> arch/arm/boot/dts/vexpress-v2m.dtsi | 76 ++++++-
> arch/arm/mach-vexpress/v2m.c | 23 +-
> drivers/mfd/Kconfig | 11 +
> drivers/mfd/Makefile | 2 +-
> drivers/mfd/vexpress-sysreg.c | 247 +++++++++++++++------
> include/linux/vexpress.h | 16 +-
> 8 files changed, 377 insertions(+), 111 deletions(-)
<snip>
> +static struct mfd_cell vexpress_sysreg_cells[] = {
> + {
> + .name = "syscon",
> + .of_compatible = "arm,vexpress-sysreg,sys_id",
> + .num_resources = 1,
> + .resources = (struct resource []) {
> + DEFINE_RES_MEM(SYS_ID, 0x4),
> + },
> + .platform_data = &vexpress_sysreg_sys_id_pdata,
> + .pdata_size = sizeof(vexpress_sysreg_sys_id_pdata),
Not sure how comfortable I am with using Device Tree and populating
platform_data with information which by the looks of it you're
planning to make persistent. What's stopping you from using a DT
property to name the block, or better yet, just use the compatible
string? Also, won't naming these blocks in DT also aid other OSes?
<snip>
> +static int vexpress_sysreg_probe(struct platform_device *pdev)
> {
> - vexpress_sysreg_base = base;
> - vexpress_sysreg_setup(NULL);
> + struct resource *mem;
> + void __iomem *base;
> + struct bgpio_chip *mmc_gpio_chip;
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!mem)
> + return -EINVAL;
> +
> + base = devm_ioremap(&pdev->dev, mem->start, resource_size(mem));
> + if (!base)
> + return -ENOMEM;
> +
> + vexpress_config_set_master(vexpress_sysreg_get_master(base));
> +
> + /*
> + * Duplicated SYS_MCI pseudo-GPIO controller for compatibility with
> + * older trees using sysreg node for MMC control lines.
> + */
> + mmc_gpio_chip = devm_kzalloc(&pdev->dev, sizeof(*mmc_gpio_chip),
> + GFP_KERNEL);
> + if (!mmc_gpio_chip)
> + return -ENOMEM;
> + bgpio_init(mmc_gpio_chip, &pdev->dev, 0x4, base + SYS_MCI, NULL,
> + NULL, NULL, NULL, 0);
> + mmc_gpio_chip->gc.ngpio = 2;
> + gpiochip_add(&mmc_gpio_chip->gc);
> +
> + return mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO,
> + vexpress_sysreg_cells,
> + ARRAY_SIZE(vexpress_sysreg_cells), mem, 0, 0);
Don't use 0 as NULL, you will cause a sparse error.
<snip>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Pawel Moll <pawel.moll@arm.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Samuel Ortiz <sameo@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>, Jon Medhurst <tixy@linaro.org>,
arm@kernel.org, Olof Johansson <olof@lixom.net>
Subject: Re: [RFC 18/18] mfd: vexpress: Split sysreg functions into MFD cells
Date: Mon, 6 Jan 2014 10:40:30 +0000 [thread overview]
Message-ID: <20140106104030.GI23772@lee--X1> (raw)
In-Reply-To: <1387815830-8794-19-git-send-email-pawel.moll@arm.com>
> This patch splits individual sysreg functions into
> separate MFD cells, which then become individual
> platform devices with their own drivers.
>
> Signed-off-by: Pawel Moll <pawel.moll@arm.com>
> ---
> .../devicetree/bindings/arm/vexpress-sysreg.txt | 37 ++-
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 76 ++++++-
> arch/arm/boot/dts/vexpress-v2m.dtsi | 76 ++++++-
> arch/arm/mach-vexpress/v2m.c | 23 +-
> drivers/mfd/Kconfig | 11 +
> drivers/mfd/Makefile | 2 +-
> drivers/mfd/vexpress-sysreg.c | 247 +++++++++++++++------
> include/linux/vexpress.h | 16 +-
> 8 files changed, 377 insertions(+), 111 deletions(-)
<snip>
> +static struct mfd_cell vexpress_sysreg_cells[] = {
> + {
> + .name = "syscon",
> + .of_compatible = "arm,vexpress-sysreg,sys_id",
> + .num_resources = 1,
> + .resources = (struct resource []) {
> + DEFINE_RES_MEM(SYS_ID, 0x4),
> + },
> + .platform_data = &vexpress_sysreg_sys_id_pdata,
> + .pdata_size = sizeof(vexpress_sysreg_sys_id_pdata),
Not sure how comfortable I am with using Device Tree and populating
platform_data with information which by the looks of it you're
planning to make persistent. What's stopping you from using a DT
property to name the block, or better yet, just use the compatible
string? Also, won't naming these blocks in DT also aid other OSes?
<snip>
> +static int vexpress_sysreg_probe(struct platform_device *pdev)
> {
> - vexpress_sysreg_base = base;
> - vexpress_sysreg_setup(NULL);
> + struct resource *mem;
> + void __iomem *base;
> + struct bgpio_chip *mmc_gpio_chip;
> +
> + mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!mem)
> + return -EINVAL;
> +
> + base = devm_ioremap(&pdev->dev, mem->start, resource_size(mem));
> + if (!base)
> + return -ENOMEM;
> +
> + vexpress_config_set_master(vexpress_sysreg_get_master(base));
> +
> + /*
> + * Duplicated SYS_MCI pseudo-GPIO controller for compatibility with
> + * older trees using sysreg node for MMC control lines.
> + */
> + mmc_gpio_chip = devm_kzalloc(&pdev->dev, sizeof(*mmc_gpio_chip),
> + GFP_KERNEL);
> + if (!mmc_gpio_chip)
> + return -ENOMEM;
> + bgpio_init(mmc_gpio_chip, &pdev->dev, 0x4, base + SYS_MCI, NULL,
> + NULL, NULL, NULL, 0);
> + mmc_gpio_chip->gc.ngpio = 2;
> + gpiochip_add(&mmc_gpio_chip->gc);
> +
> + return mfd_add_devices(&pdev->dev, PLATFORM_DEVID_AUTO,
> + vexpress_sysreg_cells,
> + ARRAY_SIZE(vexpress_sysreg_cells), mem, 0, 0);
Don't use 0 as NULL, you will cause a sparse error.
<snip>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-01-06 10:40 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-23 16:23 [RFC 00/18] Versatile Express config rework Pawel Moll
2013-12-23 16:23 ` Pawel Moll
[not found] ` < 1387815830-8794-7-git-send-email-pawel.moll@arm.com>
[not found] ` < 1387815830-8794-5-git-send-email-pawel.moll@arm.com>
2013-12-23 16:23 ` [RFC 01/18] mfd: syscon: Consider platform data a regmap config name Pawel Moll
2014-01-06 9:48 ` Lee Jones
2014-01-06 9:48 ` Lee Jones
2014-01-06 10:20 ` Lee Jones
2014-01-06 10:20 ` Lee Jones
2013-12-23 16:23 ` [RFC 02/18] power/reset: vexpress: Use sched_clock as the time source Pawel Moll
2013-12-23 19:28 ` John Stultz
2013-12-23 19:28 ` John Stultz
2014-01-08 16:01 ` Pawel Moll
2014-01-08 16:01 ` Pawel Moll
2013-12-23 16:23 ` [RFC 03/18] GPIO: gpio-generic: Add label to platform data Pawel Moll
2013-12-23 17:26 ` Linus Walleij
2013-12-23 17:26 ` Linus Walleij
2014-01-08 15:57 ` Pawel Moll
2014-01-08 15:57 ` Pawel Moll
2014-01-14 10:30 ` Linus Walleij
2014-01-14 10:30 ` Linus Walleij
2014-01-14 10:44 ` Pawel Moll
2014-01-14 10:44 ` Pawel Moll
[not found] ` <1387815830-8794-1-git-send-email-pawel.moll-5wv7dgnIgG8@public.gmane.org>
2013-12-23 16:23 ` [RFC 04/18] driver core & of: Mark of_nodes of added device as populated Pawel Moll
2013-12-23 16:23 ` Pawel Moll
2014-01-08 17:28 ` Rob Herring
2014-01-08 17:28 ` Rob Herring
2014-01-16 17:03 ` Grant Likely
2014-01-16 17:03 ` Grant Likely
2014-01-16 17:03 ` Grant Likely
2013-12-23 16:23 ` [RFC 05/18] driver core: Do not WARN when devres list is not empty at probe time Pawel Moll
2013-12-23 16:23 ` Pawel Moll
2013-12-23 16:23 ` [RFC 06/18] regmap: Formalise use of non-bus context Pawel Moll
2013-12-24 12:45 ` Mark Brown
2013-12-24 12:45 ` Mark Brown
2014-01-09 13:08 ` Pawel Moll
2014-01-09 13:08 ` Pawel Moll
2014-01-09 13:34 ` Mark Brown
2014-01-09 13:34 ` Mark Brown
2014-01-09 15:47 ` Pawel Moll
2014-01-09 15:47 ` Pawel Moll
2014-01-16 17:09 ` Grant Likely
2014-01-16 17:09 ` Grant Likely
2014-01-16 17:20 ` Pawel Moll
2014-01-16 17:20 ` Pawel Moll
2013-12-23 16:23 ` [RFC 07/18] regmap: debugfs: Always create "registers" & "access" files Pawel Moll
2013-12-24 12:19 ` Mark Brown
2013-12-24 12:19 ` Mark Brown
2014-01-08 17:31 ` Pawel Moll
2014-01-08 17:31 ` Pawel Moll
2014-01-08 18:00 ` Mark Brown
2014-01-08 18:00 ` Mark Brown
2013-12-23 16:23 ` [lm-sensors] [RFC 08/18] hwmon: vexpress: Use regmap instead of custom interface Pawel Moll
2013-12-23 16:23 ` Pawel Moll
2013-12-23 17:31 ` [lm-sensors] " Guenter Roeck
2013-12-23 17:31 ` Guenter Roeck
2013-12-23 17:31 ` Guenter Roeck
2014-01-08 15:57 ` [lm-sensors] " Pawel Moll
2014-01-08 15:57 ` Pawel Moll
2014-01-08 15:57 ` Pawel Moll
2013-12-23 16:23 ` [RFC 09/18] power/reset: " Pawel Moll
2013-12-23 16:23 ` [RFC 10/18] regulator: " Pawel Moll
2013-12-24 12:24 ` Mark Brown
2013-12-24 12:24 ` Mark Brown
2014-01-08 18:25 ` Pawel Moll
2014-01-08 18:25 ` Pawel Moll
2014-01-09 13:35 ` Mark Brown
2014-01-09 13:35 ` Mark Brown
2013-12-23 16:23 ` [RFC 11/18] clocksource: Sched clock source for Versatile Express Pawel Moll
2013-12-23 16:23 ` [RFC 12/18] clk: versatile: Split config options for sp810 and vexpress_osc Pawel Moll
2013-12-23 20:05 ` Mike Turquette
2013-12-23 20:05 ` Mike Turquette
2014-01-08 16:06 ` Pawel Moll
2014-01-08 16:06 ` Pawel Moll
2013-12-23 16:23 ` [RFC 13/18] clk: versatile: Use regmap instead of custom interface Pawel Moll
2013-12-23 16:23 ` [RFC 14/18] ARM: vexpress: remove redundant vexpress_dt_cpus_num to get cpu count Pawel Moll
2013-12-23 16:23 ` [RFC 15/18] ARM: vexpress: Simplify SMP operations for DT-powered system Pawel Moll
2013-12-23 16:23 ` [RFC 16/18] bus: Versatile Express configuration bus Pawel Moll
2013-12-23 16:23 ` [RFC 17/18] misc: Versatile Express System Config interface driver Pawel Moll
2013-12-23 16:23 ` [RFC 18/18] mfd: vexpress: Split sysreg functions into MFD cells Pawel Moll
2014-01-06 10:40 ` Lee Jones [this message]
2014-01-06 10:40 ` Lee Jones
2014-01-08 16:17 ` Pawel Moll
2014-01-08 16:17 ` Pawel Moll
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140106104030.GI23772@lee--X1 \
--to=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.