linux-kernel - Re: [PATCH 2/3] ARM: mxs: add gpio-mxs platform devices

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: <201105201223.00427.arnd@arndb.de>
Date:	Fri, 20 May 2011 12:23:00 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Shawn Guo <shawn.guo@...aro.org>, linux-kernel@...r.kernel.org,
	patches@...aro.org, linus.walleij@...aro.org,
	grant.likely@...retlab.ca, kernel@...gutronix.de
Subject: Re: [PATCH 2/3] ARM: mxs: add gpio-mxs platform devices

On Friday 20 May 2011 11:57:25 Shawn Guo wrote:

> --- /dev/null
> +++ b/arch/arm/mach-mxs/devices/platform-gpio-mxs.c
> @@ -0,0 +1,92 @@
> +/*
> + * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it under
> + * the terms of the GNU General Public License version 2 as published by the
> + * Free Software Foundation.
> + */

Hmm, I forgot to discuss this in Budapest, but I'm still not convinced about
the code ownership here, I think it should be Copyright Linaro Ltd when a
Linaro assignee writes it, not the member company that you work for.

If your manager thinks it should be copyright Freescale, I would suggest
we discuss it on the Linaro private mailing list so we can find a solution
that everyone is happy with. No need to bother the public with this.

> +#include <linux/compiler.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +
> +#include <mach/mx23.h>
> +#include <mach/mx28.h>
> +#include <mach/devices-common.h>
> +
> +struct mxs_gpio_data {
> +	int id;
> +	resource_size_t iobase;
> +	resource_size_t iosize;
> +	resource_size_t irq;
> +};

You don't use iosize anywhere.

> +#define mxs_gpio_data_entry_single(soc, _id)				\
> +	{								\
> +		.id = _id,						\
> +		.iobase = soc ## _PINCTRL ## _BASE_ADDR,		\
> +		.irq = soc ## _INT_GPIO ## _id,				\
> +	}
> +
> +#define mxs_gpio_data_entry(soc, _id)					\
> +	[_id] = mxs_gpio_data_entry_single(soc, _id)
> +
> +#ifdef CONFIG_SOC_IMX23
> +const struct mxs_gpio_data mx23_gpio_data[] __initconst = {
> +#define mx23_gpio_data_entry(_id)					\
> +	mxs_gpio_data_entry(MX23, _id)

I know it's tempting to use macros for these, but I think it obscures
the code a lot, especially when you use them to concatenate identifier
names. Why not just do:

	struct platform_device *gpios;
	gpios = platform_device_register_simple(mxs_host_bus, "mxs-gpio-master", 0, NULL, 0);

	mxs_register_gpio(gpios, 0, MX23_PINCTRL_BASE_ADDR, MX23_INT_GPIO_0);
	mxs_register_gpio(gpios, 1, MX23_PINCTRL_BASE_ADDR, MX23_INT_GPIO_1);
	mxs_register_gpio(gpios, 2, MX23_PINCTRL_BASE_ADDR, MX23_INT_GPIO_2);
	mxs_register_gpio(gpios, 3, MX23_PINCTRL_BASE_ADDR, MX23_INT_GPIO_3);

This is actually shorter and it makes it possible to grep for the
macros you use.

> +struct platform_device *__init mxs_add_gpio(
> +		const struct mxs_gpio_data *data)
> +{
> +	struct resource res[] = {
> +		{
> +			.start = data->iobase,
> +			.end = data->iobase + SZ_8K - 1,
> +			.flags = IORESOURCE_MEM,
> +		}, {
> +			.start = data->irq,
> +			.end = data->irq,
> +			.flags = IORESOURCE_IRQ,
> +		},
> +	};
> +
> +	return mxs_add_platform_device("mxs-gpio", data->id,
> +					res, ARRAY_SIZE(res), NULL, 0);
> +}

mxs_add_platform_device doesn't set the parent pointer correctly, I think you
should either fix that or open-code the platform device creation to do it
right.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/