All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
	linus.walleij@linaro.org, gnurou@gmail.com, broonie@kernel.org,
	a.zummo@towertech.it, alexandre.belloni@free-electrons.com,
	lgirdwood@gmail.com, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	rtc-linux@googlegroups.com, swarren@nvidia.com,
	treding@nvidia.com, k.kozlowski@samsung.com,
	Chaitanya Bandi <bandik@nvidia.com>,
	Mallikarjun Kasoju <mkasoju@nvidia.com>
Subject: Re: [PATCH V6 2/8] mfd: max77620: add core driver for MAX77620/MAX20024
Date: Mon, 1 Feb 2016 08:59:50 +0000	[thread overview]
Message-ID: <20160201085950.GA3368@x1> (raw)
In-Reply-To: <56AB462A.8090307@nvidia.com>

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
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
	linus.walleij@linaro.org, gnurou@gmail.com, broonie@kernel.org,
	a.zummo@towertech.it, alexandre.belloni@free-electrons.com,
	lgirdwood@gmail.com, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	rtc-linux@googlegroups.com, swarren@nvidia.com,
	treding@nvidia.com, k.kozlowski@samsung.com,
	Chaitanya Bandi <bandik@nvidia.com>,
	Mallikarjun Kasoju <mkasoju@nvidia.com>
Subject: Re: [PATCH V6 2/8] mfd: max77620: add core driver for MAX77620/MAX20024
Date: Mon, 1 Feb 2016 08:59:50 +0000	[thread overview]
Message-ID: <20160201085950.GA3368@x1> (raw)
In-Reply-To: <56AB462A.8090307@nvidia.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Laxman Dewangan <ldewangan@nvidia.com>
Cc: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
	linus.walleij@linaro.org, gnurou@gmail.com, broonie@kernel.org,
	a.zummo@towertech.it, alexandre.belloni@free-electrons.com,
	lgirdwood@gmail.com, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	rtc-linux@googlegroups.com, swarren@nvidia.com,
	treding@nvidia.com, k.kozlowski@samsung.com,
	Chaitanya Bandi <bandik@nvidia.com>,
	Mallikarjun Kasoju <mkasoju@nvidia.com>
Subject: [rtc-linux] Re: [PATCH V6 2/8] mfd: max77620: add core driver for MAX77620/MAX20024
Date: Mon, 1 Feb 2016 08:59:50 +0000	[thread overview]
Message-ID: <20160201085950.GA3368@x1> (raw)
In-Reply-To: <56AB462A.8090307@nvidia.com>

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.
>=20
> 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] =3D {						\
> >>+		.name =3D "max20024-"#_name,			\
> >>+		.id =3D _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.
>=20
> yaah, generic implementation possible. I can put the new defines in
> the mfd/core.h.
>=20
> This will be similar to
> +/* Define mfd cells with name and resource */
> +#define DEFINE_MFD_CELL_NAME_RESOURCE(_name, _res)             \
> +       {                                                       \
> +               .name =3D (_name),                                \
> +               .num_resources =3D ARRAY_SIZE((res)),             \
> +               .resources =3D (_res),                            \
> +       }
> +
> +/* Define mfd cells with name */
> +#define DEFINE_MFD_CELL_NAME(_name)                            \
> +       {                                                       \
> +               .name =3D (_name),                                \
> +       }
> +
>=20
> 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[] =3D {
> >>+	{"max77620", MAX77620},
> >>+	{"max20024", MAX20024},
> >>+	{},
> >>+};
> >>+MODULE_DEVICE_TABLE(i2c, max77620_id);
> >>+
> >>+static const struct of_device_id max77620_of_match[] =3D {
> >>+	{
> >>+		.compatible =3D "maxim,max77620",
> >>+		.data =3D &max77620_cells,
> >>+	}, {
> >>+		.compatible =3D "maxim,max20024",
> >>+		.data =3D &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.
>=20
> 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?
>=20
> 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.

--=20
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org =E2=94=82 Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

--=20
--=20
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---=20
You received this message because you are subscribed to the Google Groups "=
rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

  reply	other threads:[~2016-02-01  8:59 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28 13:37 [PATCH V6 0/8] Add support for MAXIM MAX77620/MAX20024 PMIC Laxman Dewangan
2016-01-28 13:37 ` [rtc-linux] " Laxman Dewangan
2016-01-28 13:37 ` Laxman Dewangan
2016-01-28 13:37 ` [PATCH V6 1/8] DT: mfd: add device-tree binding doc for PMIC max77620/max20024 Laxman Dewangan
2016-01-28 13:37   ` [rtc-linux] " Laxman Dewangan
2016-01-28 13:37   ` Laxman Dewangan
2016-01-28 13:37 ` [PATCH V6 2/8] mfd: max77620: add core driver for MAX77620/MAX20024 Laxman Dewangan
2016-01-28 13:37   ` [rtc-linux] " Laxman Dewangan
2016-01-28 13:37   ` Laxman Dewangan
2016-01-29  9:06   ` Lee Jones
2016-01-29  9:06     ` [rtc-linux] " Lee Jones
2016-01-29 10:59     ` Laxman Dewangan
2016-01-29 10:59       ` [rtc-linux] " Laxman Dewangan
2016-01-29 10:59       ` Laxman Dewangan
2016-02-01  8:59       ` Lee Jones [this message]
2016-02-01  8:59         ` [rtc-linux] " Lee Jones
2016-02-01  8:59         ` Lee Jones
2016-02-01  8:52         ` Laxman Dewangan
2016-02-01  8:52           ` [rtc-linux] " Laxman Dewangan
2016-02-01  8:52           ` Laxman Dewangan
2016-01-28 13:37 ` [PATCH V6 3/8] DT: pinctrl: add DT binding doc for pincontrol of PMIC max77620/max20024 Laxman Dewangan
2016-01-28 13:37   ` [rtc-linux] " Laxman Dewangan
2016-01-28 13:37   ` Laxman Dewangan
2016-01-28 13:37 ` [PATCH V6 4/8] pinctrl: max77620: add pincontrol driver for MAX77620/MAX20024 Laxman Dewangan
2016-01-28 13:37   ` [rtc-linux] " Laxman Dewangan
2016-01-28 13:37   ` Laxman Dewangan
2016-01-28 13:37 ` [PATCH V6 5/8] DT: gpio: add DT binding doc for gpio of PMIC max77620/max20024 Laxman Dewangan
2016-01-28 13:37   ` [rtc-linux] " Laxman Dewangan
2016-01-28 13:37   ` Laxman Dewangan
2016-01-28 13:37 ` [PATCH V6 6/8] gpio: max77620: add gpio driver for MAX77620/MAX20024 Laxman Dewangan
2016-01-28 13:37   ` [rtc-linux] " Laxman Dewangan
2016-01-28 13:37   ` Laxman Dewangan
2016-01-28 13:37 ` [PATCH V6 7/8] DT: regulator: add DT binding doc for regulator of PMIC max77620/max20024 Laxman Dewangan
2016-01-28 13:37   ` [rtc-linux] " Laxman Dewangan
2016-01-28 13:37   ` Laxman Dewangan
2016-01-28 23:28   ` Mark Brown
2016-01-28 23:28     ` [rtc-linux] " Mark Brown
2016-01-28 13:37 ` [PATCH V6 8/8] regulator: max77620: add regulator driver for max77620/max20024 Laxman Dewangan
2016-01-28 13:37   ` [rtc-linux] " Laxman Dewangan
2016-01-28 13:37   ` Laxman Dewangan

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=20160201085950.GA3368@x1 \
    --to=lee.jones@linaro.org \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=bandik@nvidia.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=gnurou@gmail.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=k.kozlowski@samsung.com \
    --cc=ldewangan@nvidia.com \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mkasoju@nvidia.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=rtc-linux@googlegroups.com \
    --cc=swarren@nvidia.com \
    --cc=treding@nvidia.com \
    /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.