linux-kernel - Re: [PATCH V6 2/8] mfd: max77620: add core driver for MAX77620/MAX20024

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]

Date:	Mon, 1 Feb 2016 08:59:50 +0000
From:	Lee Jones <lee.jones@...aro.org>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	robh+dt@...nel.org, pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	linus.walleij@...aro.org, gnurou@...il.com, broonie@...nel.org,
	a.zummo@...ertech.it, alexandre.belloni@...e-electrons.com,
	lgirdwood@...il.com, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
	rtc-linux@...glegroups.com, swarren@...dia.com, treding@...dia.com,
	k.kozlowski@...sung.com, Chaitanya Bandi <bandik@...dia.com>,
	Mallikarjun Kasoju <mkasoju@...dia.com>
Subject: Re: [PATCH V6 2/8] mfd: max77620: add core driver for
 MAX77620/MAX20024

On Fri, 29 Jan 2016, Laxman Dewangan wrote:

> Thanks Lee for review.
> I will take care of most of stuff on next version of patch.
> 
> However, I have some query form your comment.
> On Friday 29 January 2016 02:36 PM, Lee Jones wrote:
> >On Thu, 28 Jan 2016, Laxman Dewangan wrote:
> >
> >
> >>+	}
> >>+
> >>+#define MAX20024_SUB_MODULE_NO_RES(_name, _id)			\
> >>+	[_id] = {						\
> >>+		.name = "max20024-"#_name,			\
> >>+		.id = _id,					\
> >>+	}
> >I don't want people hand-rolling this stuff.  If it's useful to you,
> >it's useful to others, so great a generic implementation that lives in
> >the kernel headers directory.
> 
> yaah, generic implementation possible. I can put the new defines in
> the mfd/core.h.
> 
> This will be similar to
> +/* Define mfd cells with name and resource */
> +#define DEFINE_MFD_CELL_NAME_RESOURCE(_name, _res)             \
> +       {                                                       \
> +               .name = (_name),                                \
> +               .num_resources = ARRAY_SIZE((res)),             \
> +               .resources = (_res),                            \
> +       }
> +
> +/* Define mfd cells with name */
> +#define DEFINE_MFD_CELL_NAME(_name)                            \
> +       {                                                       \
> +               .name = (_name),                                \
> +       }
> +
> 
> This will be separate patch and should be applied before this series.
> Does it look fine?

Hmm... Actually, I have my own ideas of how this should look.  How do
you feel about me submitting my own patch.  I'll keep you on Cc, so
you can review and make use of it in your set.

> >>+static const struct i2c_device_id max77620_id[] = {
> >>+	{"max77620", MAX77620},
> >>+	{"max20024", MAX20024},
> >>+	{},
> >>+};
> >>+MODULE_DEVICE_TABLE(i2c, max77620_id);
> >>+
> >>+static const struct of_device_id max77620_of_match[] = {
> >>+	{
> >>+		.compatible = "maxim,max77620",
> >>+		.data = &max77620_cells,
> >>+	}, {
> >>+		.compatible = "maxim,max20024",
> >>+		.data = &max20024_cells,
> >>+	}, {
> >>+	},
> >>+};
> >>+MODULE_DEVICE_TABLE(of, max77620_of_match);
> >This is not acceptable.  EITHER use DT OR MFD methods of registering
> >devices, do not mix the two.
> 
> You mean I need to either provide the i2c_device_id table or the
> of_device_id table, not both?
> Do I need to protect it by CONFIG_OF?
> 
> This only support the DT method of registration. So do I need to
> remove i2c_device_id?

No, I mean I don't want you providing platform data via an MFD cell
and passing it through the OF .data attribute.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog