[PATCH 1/2] mfd: da9052: fix broken regulator probe

[PATCH 1/2] mfd: da9052: fix broken regulator probe

[Johan Hovold]

Fix broken probe of da9052 regulators, which since commit b3f6c73db732
("mfd: da9052-core: Fix platform-device id collision") use a
non-deterministic platform-device id to retrieve static regulator
information. Fortunately, adequate error handling was in place so probe
would simply fail with an error message.

Update the mfd-cell ids to be zero-based and use those to identify the
cells when probing the regulator devices.

Fixes: b3f6c73db732 ("mfd: da9052-core: Fix platform-device id collision")
Cc: stable <stable@vger.kernel.org>	# v3.19
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/mfd/da9052-core.c            | 8 ++++----
 drivers/regulator/da9052-regulator.c | 5 +++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
index ae498b53ee40..46e3840c7a37 100644
--- a/drivers/mfd/da9052-core.c
+++ b/drivers/mfd/da9052-core.c
@@ -433,6 +433,10 @@ EXPORT_SYMBOL_GPL(da9052_adc_read_temp);
 static const struct mfd_cell da9052_subdev_info[] = {
 	{
 		.name = "da9052-regulator",
+		.id = 0,
+	},
+	{
+		.name = "da9052-regulator",
 		.id = 1,
 	},
 	{
@@ -484,10 +488,6 @@ static const struct mfd_cell da9052_subdev_info[] = {
 		.id = 13,
 	},
 	{
-		.name = "da9052-regulator",
-		.id = 14,
-	},
-	{
 		.name = "da9052-onkey",
 	},
 	{
diff --git a/drivers/regulator/da9052-regulator.c b/drivers/regulator/da9052-regulator.c
index 8a4df7a1f2ee..e628d4c2f2ae 100644
--- a/drivers/regulator/da9052-regulator.c
+++ b/drivers/regulator/da9052-regulator.c
@@ -394,6 +394,7 @@ static inline struct da9052_regulator_info *find_regulator_info(u8 chip_id,
 
 static int da9052_regulator_probe(struct platform_device *pdev)
 {
+	const struct mfd_cell *cell = mfd_get_cell(pdev);
 	struct regulator_config config = { };
 	struct da9052_regulator *regulator;
 	struct da9052 *da9052;
@@ -409,7 +410,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
 	regulator->da9052 = da9052;
 
 	regulator->info = find_regulator_info(regulator->da9052->chip_id,
-					      pdev->id);
+					      cell->id);
 	if (regulator->info == NULL) {
 		dev_err(&pdev->dev, "invalid regulator ID specified\n");
 		return -EINVAL;
@@ -419,7 +420,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
 	config.driver_data = regulator;
 	config.regmap = da9052->regmap;
 	if (pdata && pdata->regulators) {
-		config.init_data = pdata->regulators[pdev->id];
+		config.init_data = pdata->regulators[cell->id];
 	} else {
 #ifdef CONFIG_OF
 		struct device_node *nproot = da9052->dev->of_node;
-- 
2.0.5

[PATCH 2/2] mfd: core: fix platform-device name collisions

[Johan Hovold]

Since commit 6e3f62f0793e ("mfd: core: Fix platform-device id
generation") we honour PLATFORM_DEVID_AUTO and PLATFORM_DEVID_NONE when
registering mfd-devices.

Unfortunately, some mfd-drivers rely on the old behaviour of generating
platform-device ids by adding the cell id also to the special value of
PLATFORM_DEVID_NONE. The resulting platform ids are not only used to
generate device-unique names, but are also used instead of the cell id
to identify cells when probing subdevices.

These drivers should be updated to use PLATFORM_DEVID_AUTO, which would
also allow more than one device to be registered without resorting to
hacks (see for example wm831x), but lets fix the regression first by
partially reverting the above mentioned commit with respect to
PLATFORM_DEVID_NONE.

Fixes: 6e3f62f0793e ("mfd: core: Fix platform-device id generation")
Cc: stable <stable@vger.kernel.org>	# v3.19
Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/mfd/mfd-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 2a87f69be53d..1aed3b7b8d9b 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -128,7 +128,7 @@ static int mfd_add_device(struct device *parent, int id,
 	int platform_id;
 	int r;
 
-	if (id < 0)
+	if (id == PLATFORM_DEVID_AUTO)
 		platform_id = id;
 	else
 		platform_id = id + cell->id;
-- 
2.0.5

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Bartlomiej Zolnierkiewicz]

Hi,

On Wednesday, March 25, 2015 12:07:04 PM Johan Hovold wrote:
> Fix broken probe of da9052 regulators, which since commit b3f6c73db732
> ("mfd: da9052-core: Fix platform-device id collision") use a
> non-deterministic platform-device id to retrieve static regulator
> information. Fortunately, adequate error handling was in place so probe
> would simply fail with an error message.
> 
> Update the mfd-cell ids to be zero-based and use those to identify the
> cells when probing the regulator devices.
> 
> Fixes: b3f6c73db732 ("mfd: da9052-core: Fix platform-device id collision")
> Cc: stable <stable@vger.kernel.org>	# v3.19
> Signed-off-by: Johan Hovold <johan@kernel.org>

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/mfd/da9052-core.c            | 8 ++++----
>  drivers/regulator/da9052-regulator.c | 5 +++--
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> index ae498b53ee40..46e3840c7a37 100644
> --- a/drivers/mfd/da9052-core.c
> +++ b/drivers/mfd/da9052-core.c
> @@ -433,6 +433,10 @@ EXPORT_SYMBOL_GPL(da9052_adc_read_temp);
>  static const struct mfd_cell da9052_subdev_info[] = {
>  	{
>  		.name = "da9052-regulator",
> +		.id = 0,
> +	},
> +	{
> +		.name = "da9052-regulator",
>  		.id = 1,
>  	},
>  	{
> @@ -484,10 +488,6 @@ static const struct mfd_cell da9052_subdev_info[] = {
>  		.id = 13,
>  	},
>  	{
> -		.name = "da9052-regulator",
> -		.id = 14,
> -	},
> -	{
>  		.name = "da9052-onkey",
>  	},
>  	{
> diff --git a/drivers/regulator/da9052-regulator.c b/drivers/regulator/da9052-regulator.c
> index 8a4df7a1f2ee..e628d4c2f2ae 100644
> --- a/drivers/regulator/da9052-regulator.c
> +++ b/drivers/regulator/da9052-regulator.c
> @@ -394,6 +394,7 @@ static inline struct da9052_regulator_info *find_regulator_info(u8 chip_id,
>  
>  static int da9052_regulator_probe(struct platform_device *pdev)
>  {
> +	const struct mfd_cell *cell = mfd_get_cell(pdev);
>  	struct regulator_config config = { };
>  	struct da9052_regulator *regulator;
>  	struct da9052 *da9052;
> @@ -409,7 +410,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
>  	regulator->da9052 = da9052;
>  
>  	regulator->info = find_regulator_info(regulator->da9052->chip_id,
> -					      pdev->id);
> +					      cell->id);
>  	if (regulator->info == NULL) {
>  		dev_err(&pdev->dev, "invalid regulator ID specified\n");
>  		return -EINVAL;
> @@ -419,7 +420,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
>  	config.driver_data = regulator;
>  	config.regmap = da9052->regmap;
>  	if (pdata && pdata->regulators) {
> -		config.init_data = pdata->regulators[pdev->id];
> +		config.init_data = pdata->regulators[cell->id];
>  	} else {
>  #ifdef CONFIG_OF
>  		struct device_node *nproot = da9052->dev->of_node;

Re: [PATCH 2/2] mfd: core: fix platform-device name collisions

[Bartlomiej Zolnierkiewicz]

Hi,

On Wednesday, March 25, 2015 12:07:05 PM Johan Hovold wrote:
> Since commit 6e3f62f0793e ("mfd: core: Fix platform-device id
> generation") we honour PLATFORM_DEVID_AUTO and PLATFORM_DEVID_NONE when
> registering mfd-devices.
> 
> Unfortunately, some mfd-drivers rely on the old behaviour of generating
> platform-device ids by adding the cell id also to the special value of
> PLATFORM_DEVID_NONE. The resulting platform ids are not only used to
> generate device-unique names, but are also used instead of the cell id
> to identify cells when probing subdevices.
> 
> These drivers should be updated to use PLATFORM_DEVID_AUTO, which would
> also allow more than one device to be registered without resorting to
> hacks (see for example wm831x), but lets fix the regression first by
> partially reverting the above mentioned commit with respect to
> PLATFORM_DEVID_NONE.
> 
> Fixes: 6e3f62f0793e ("mfd: core: Fix platform-device id generation")
> Cc: stable <stable@vger.kernel.org>	# v3.19
> Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Signed-off-by: Johan Hovold <johan@kernel.org>

Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

> ---
>  drivers/mfd/mfd-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 2a87f69be53d..1aed3b7b8d9b 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -128,7 +128,7 @@ static int mfd_add_device(struct device *parent, int id,
>  	int platform_id;
>  	int r;
>  
> -	if (id < 0)
> +	if (id == PLATFORM_DEVID_AUTO)
>  		platform_id = id;
>  	else
>  		platform_id = id + cell->id;

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Lee Jones]

On Wed, 25 Mar 2015, Johan Hovold wrote:

> Fix broken probe of da9052 regulators, which since commit b3f6c73db732
> ("mfd: da9052-core: Fix platform-device id collision") use a
> non-deterministic platform-device id to retrieve static regulator
> information. Fortunately, adequate error handling was in place so probe
> would simply fail with an error message.
> 
> Update the mfd-cell ids to be zero-based and use those to identify the
> cells when probing the regulator devices.
> 
> Fixes: b3f6c73db732 ("mfd: da9052-core: Fix platform-device id collision")
> Cc: stable <stable@vger.kernel.org>	# v3.19
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
>  drivers/mfd/da9052-core.c            | 8 ++++----
>  drivers/regulator/da9052-regulator.c | 5 +++--

Need an Ack from Mark, but looks good to me.

Acked-by: Lee Jones <lee.jones@linaro.org>

>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> index ae498b53ee40..46e3840c7a37 100644
> --- a/drivers/mfd/da9052-core.c
> +++ b/drivers/mfd/da9052-core.c
> @@ -433,6 +433,10 @@ EXPORT_SYMBOL_GPL(da9052_adc_read_temp);
>  static const struct mfd_cell da9052_subdev_info[] = {
>  	{
>  		.name = "da9052-regulator",
> +		.id = 0,
> +	},
> +	{
> +		.name = "da9052-regulator",
>  		.id = 1,
>  	},
>  	{
> @@ -484,10 +488,6 @@ static const struct mfd_cell da9052_subdev_info[] = {
>  		.id = 13,
>  	},
>  	{
> -		.name = "da9052-regulator",
> -		.id = 14,
> -	},
> -	{
>  		.name = "da9052-onkey",
>  	},
>  	{
> diff --git a/drivers/regulator/da9052-regulator.c b/drivers/regulator/da9052-regulator.c
> index 8a4df7a1f2ee..e628d4c2f2ae 100644
> --- a/drivers/regulator/da9052-regulator.c
> +++ b/drivers/regulator/da9052-regulator.c
> @@ -394,6 +394,7 @@ static inline struct da9052_regulator_info *find_regulator_info(u8 chip_id,
>  
>  static int da9052_regulator_probe(struct platform_device *pdev)
>  {
> +	const struct mfd_cell *cell = mfd_get_cell(pdev);
>  	struct regulator_config config = { };
>  	struct da9052_regulator *regulator;
>  	struct da9052 *da9052;
> @@ -409,7 +410,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
>  	regulator->da9052 = da9052;
>  
>  	regulator->info = find_regulator_info(regulator->da9052->chip_id,
> -					      pdev->id);
> +					      cell->id);
>  	if (regulator->info == NULL) {
>  		dev_err(&pdev->dev, "invalid regulator ID specified\n");
>  		return -EINVAL;
> @@ -419,7 +420,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
>  	config.driver_data = regulator;
>  	config.regmap = da9052->regmap;
>  	if (pdata && pdata->regulators) {
> -		config.init_data = pdata->regulators[pdev->id];
> +		config.init_data = pdata->regulators[cell->id];
>  	} else {
>  #ifdef CONFIG_OF
>  		struct device_node *nproot = da9052->dev->of_node;

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

Re: [PATCH 2/2] mfd: core: fix platform-device name collisions

[Lee Jones]

On Wed, 25 Mar 2015, Johan Hovold wrote:

> Since commit 6e3f62f0793e ("mfd: core: Fix platform-device id
> generation") we honour PLATFORM_DEVID_AUTO and PLATFORM_DEVID_NONE when
> registering mfd-devices.
> 
> Unfortunately, some mfd-drivers rely on the old behaviour of generating
> platform-device ids by adding the cell id also to the special value of
> PLATFORM_DEVID_NONE. The resulting platform ids are not only used to
> generate device-unique names, but are also used instead of the cell id
> to identify cells when probing subdevices.
> 
> These drivers should be updated to use PLATFORM_DEVID_AUTO, which would
> also allow more than one device to be registered without resorting to
> hacks (see for example wm831x), but lets fix the regression first by
> partially reverting the above mentioned commit with respect to
> PLATFORM_DEVID_NONE.
> 
> Fixes: 6e3f62f0793e ("mfd: core: Fix platform-device id generation")
> Cc: stable <stable@vger.kernel.org>	# v3.19
> Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
>  drivers/mfd/mfd-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 2a87f69be53d..1aed3b7b8d9b 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -128,7 +128,7 @@ static int mfd_add_device(struct device *parent, int id,
>  	int platform_id;
>  	int r;
>  
> -	if (id < 0)
> +	if (id == PLATFORM_DEVID_AUTO)
>  		platform_id = id;
>  	else
>  		platform_id = id + cell->id;

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

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Lee Jones]

FAO Mark:

> Fix broken probe of da9052 regulators, which since commit b3f6c73db732
> ("mfd: da9052-core: Fix platform-device id collision") use a
> non-deterministic platform-device id to retrieve static regulator
> information. Fortunately, adequate error handling was in place so probe
> would simply fail with an error message.
> 
> Update the mfd-cell ids to be zero-based and use those to identify the
> cells when probing the regulator devices.
> 
> Fixes: b3f6c73db732 ("mfd: da9052-core: Fix platform-device id collision")
> Cc: stable <stable@vger.kernel.org>	# v3.19
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
>  drivers/mfd/da9052-core.c            | 8 ++++----
>  drivers/regulator/da9052-regulator.c | 5 +++--
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> index ae498b53ee40..46e3840c7a37 100644
> --- a/drivers/mfd/da9052-core.c
> +++ b/drivers/mfd/da9052-core.c
> @@ -433,6 +433,10 @@ EXPORT_SYMBOL_GPL(da9052_adc_read_temp);
>  static const struct mfd_cell da9052_subdev_info[] = {
>  	{
>  		.name = "da9052-regulator",
> +		.id = 0,
> +	},
> +	{
> +		.name = "da9052-regulator",
>  		.id = 1,
>  	},
>  	{
> @@ -484,10 +488,6 @@ static const struct mfd_cell da9052_subdev_info[] = {
>  		.id = 13,
>  	},
>  	{
> -		.name = "da9052-regulator",
> -		.id = 14,
> -	},
> -	{
>  		.name = "da9052-onkey",
>  	},
>  	{
> diff --git a/drivers/regulator/da9052-regulator.c b/drivers/regulator/da9052-regulator.c
> index 8a4df7a1f2ee..e628d4c2f2ae 100644
> --- a/drivers/regulator/da9052-regulator.c
> +++ b/drivers/regulator/da9052-regulator.c
> @@ -394,6 +394,7 @@ static inline struct da9052_regulator_info *find_regulator_info(u8 chip_id,
>  
>  static int da9052_regulator_probe(struct platform_device *pdev)
>  {
> +	const struct mfd_cell *cell = mfd_get_cell(pdev);
>  	struct regulator_config config = { };
>  	struct da9052_regulator *regulator;
>  	struct da9052 *da9052;
> @@ -409,7 +410,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
>  	regulator->da9052 = da9052;
>  
>  	regulator->info = find_regulator_info(regulator->da9052->chip_id,
> -					      pdev->id);
> +					      cell->id);
>  	if (regulator->info == NULL) {
>  		dev_err(&pdev->dev, "invalid regulator ID specified\n");
>  		return -EINVAL;
> @@ -419,7 +420,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
>  	config.driver_data = regulator;
>  	config.regmap = da9052->regmap;
>  	if (pdata && pdata->regulators) {
> -		config.init_data = pdata->regulators[pdev->id];
> +		config.init_data = pdata->regulators[cell->id];
>  	} else {
>  #ifdef CONFIG_OF
>  		struct device_node *nproot = da9052->dev->of_node;

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

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Johan Hovold]

Hi Mark and Lee,

On Thu, Mar 26, 2015 at 08:32:09AM +0000, Lee Jones wrote:
> On Wed, 25 Mar 2015, Johan Hovold wrote:
> 
> > Fix broken probe of da9052 regulators, which since commit b3f6c73db732
> > ("mfd: da9052-core: Fix platform-device id collision") use a
> > non-deterministic platform-device id to retrieve static regulator
> > information. Fortunately, adequate error handling was in place so probe
> > would simply fail with an error message.
> > 
> > Update the mfd-cell ids to be zero-based and use those to identify the
> > cells when probing the regulator devices.
> > 
> > Fixes: b3f6c73db732 ("mfd: da9052-core: Fix platform-device id collision")
> > Cc: stable <stable@vger.kernel.org>	# v3.19
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > ---
> >  drivers/mfd/da9052-core.c            | 8 ++++----
> >  drivers/regulator/da9052-regulator.c | 5 +++--
> 
> Need an Ack from Mark, but looks good to me.
> 
> Acked-by: Lee Jones <lee.jones@linaro.org>

Mark, did you have a chance to look at this one?

It fixes a regression due to an mfd commit, but not sure who of you that
wants to take it.

Thanks,
Johan

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Johan Hovold]

On Tue, Apr 14, 2015 at 03:04:06PM +0200, Johan Hovold wrote:
> Hi Mark and Lee,
> 
> On Thu, Mar 26, 2015 at 08:32:09AM +0000, Lee Jones wrote:
> > On Wed, 25 Mar 2015, Johan Hovold wrote:
> > 
> > > Fix broken probe of da9052 regulators, which since commit b3f6c73db732
> > > ("mfd: da9052-core: Fix platform-device id collision") use a
> > > non-deterministic platform-device id to retrieve static regulator
> > > information. Fortunately, adequate error handling was in place so probe
> > > would simply fail with an error message.
> > > 
> > > Update the mfd-cell ids to be zero-based and use those to identify the
> > > cells when probing the regulator devices.
> > > 
> > > Fixes: b3f6c73db732 ("mfd: da9052-core: Fix platform-device id collision")
> > > Cc: stable <stable@vger.kernel.org>	# v3.19
> > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > ---
> > >  drivers/mfd/da9052-core.c            | 8 ++++----
> > >  drivers/regulator/da9052-regulator.c | 5 +++--
> > 
> > Need an Ack from Mark, but looks good to me.
> > 
> > Acked-by: Lee Jones <lee.jones@linaro.org>
> 
> Mark, did you have a chance to look at this one?
> 
> It fixes a regression due to an mfd commit, but not sure who of you that
> wants to take it.

It's now been over a month and this still hasn't been applied even
though it fixes a regression.

Lee, perhaps you should take it through MFD as it was an MFD commit that
broke it?

Johan

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Lee Jones]

On Wed, 29 Apr 2015, Johan Hovold wrote:

> On Tue, Apr 14, 2015 at 03:04:06PM +0200, Johan Hovold wrote:
> > Hi Mark and Lee,
> > 
> > On Thu, Mar 26, 2015 at 08:32:09AM +0000, Lee Jones wrote:
> > > On Wed, 25 Mar 2015, Johan Hovold wrote:
> > > 
> > > > Fix broken probe of da9052 regulators, which since commit b3f6c73db732
> > > > ("mfd: da9052-core: Fix platform-device id collision") use a
> > > > non-deterministic platform-device id to retrieve static regulator
> > > > information. Fortunately, adequate error handling was in place so probe
> > > > would simply fail with an error message.
> > > > 
> > > > Update the mfd-cell ids to be zero-based and use those to identify the
> > > > cells when probing the regulator devices.
> > > > 
> > > > Fixes: b3f6c73db732 ("mfd: da9052-core: Fix platform-device id collision")
> > > > Cc: stable <stable@vger.kernel.org>	# v3.19
> > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > ---
> > > >  drivers/mfd/da9052-core.c            | 8 ++++----
> > > >  drivers/regulator/da9052-regulator.c | 5 +++--
> > > 
> > > Need an Ack from Mark, but looks good to me.
> > > 
> > > Acked-by: Lee Jones <lee.jones@linaro.org>
> > 
> > Mark, did you have a chance to look at this one?
> > 
> > It fixes a regression due to an mfd commit, but not sure who of you that
> > wants to take it.
> 
> It's now been over a month and this still hasn't been applied even
> though it fixes a regression.
> 
> Lee, perhaps you should take it through MFD as it was an MFD commit that
> broke it?

I'm in the same situation -- can't do anything without an Ack from Mark.

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

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Lee Jones]

On Wed, 29 Apr 2015, Lee Jones wrote:

> On Wed, 29 Apr 2015, Johan Hovold wrote:
> 
> > On Tue, Apr 14, 2015 at 03:04:06PM +0200, Johan Hovold wrote:
> > > Hi Mark and Lee,
> > > 
> > > On Thu, Mar 26, 2015 at 08:32:09AM +0000, Lee Jones wrote:
> > > > On Wed, 25 Mar 2015, Johan Hovold wrote:
> > > > 
> > > > > Fix broken probe of da9052 regulators, which since commit b3f6c73db732
> > > > > ("mfd: da9052-core: Fix platform-device id collision") use a
> > > > > non-deterministic platform-device id to retrieve static regulator
> > > > > information. Fortunately, adequate error handling was in place so probe
> > > > > would simply fail with an error message.
> > > > > 
> > > > > Update the mfd-cell ids to be zero-based and use those to identify the
> > > > > cells when probing the regulator devices.
> > > > > 
> > > > > Fixes: b3f6c73db732 ("mfd: da9052-core: Fix platform-device id collision")
> > > > > Cc: stable <stable@vger.kernel.org>	# v3.19
> > > > > Signed-off-by: Johan Hovold <johan@kernel.org>
> > > > > ---
> > > > >  drivers/mfd/da9052-core.c            | 8 ++++----
> > > > >  drivers/regulator/da9052-regulator.c | 5 +++--
> > > > 
> > > > Need an Ack from Mark, but looks good to me.
> > > > 
> > > > Acked-by: Lee Jones <lee.jones@linaro.org>
> > > 
> > > Mark, did you have a chance to look at this one?
> > > 
> > > It fixes a regression due to an mfd commit, but not sure who of you that
> > > wants to take it.
> > 
> > It's now been over a month and this still hasn't been applied even
> > though it fixes a regression.
> > 
> > Lee, perhaps you should take it through MFD as it was an MFD commit that
> > broke it?
> 
> I'm in the same situation -- can't do anything without an Ack from Mark.

I happen to know that Mark regularly deletes his mail.

Can you re-sent this complete with collected Acks please?

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

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

On Wed, May 13, 2015 at 04:43:33PM +0100, Lee Jones wrote:
> On Wed, 29 Apr 2015, Lee Jones wrote:

> > I'm in the same situation -- can't do anything without an Ack from Mark.

> I happen to know that Mark regularly deletes his mail.

> Can you re-sent this complete with collected Acks please?

If you're looking for me to review something you need to send it to me,
and the chances of me looking at it are very much increased if there's a
relevant subject line.  I'm CCed (not even on the to list) on endless
large threads and reposts of patch serieses about MFD drivers most of
which are of very little relevance to me so they get ignored very
easily.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Lee Jones]

On Wed, 13 May 2015, Mark Brown wrote:

> On Wed, May 13, 2015 at 04:43:33PM +0100, Lee Jones wrote:
> > On Wed, 29 Apr 2015, Lee Jones wrote:
> 
> > > I'm in the same situation -- can't do anything without an Ack from Mark.
> 
> > I happen to know that Mark regularly deletes his mail.
> 
> > Can you re-sent this complete with collected Acks please?
> 
> If you're looking for me to review something you need to send it to me,
> and the chances of me looking at it are very much increased if there's a
> relevant subject line.  I'm CCed (not even on the to list) on endless
> large threads and reposts of patch serieses about MFD drivers most of
> which are of very little relevance to me so they get ignored very
> easily.

Calm down dear, it's only a commercial.

I wasn't having a pop.  Rather empathising with your situation and
facilitating a resend that you're likely to see.

I'm sure Johan will do the right thing.

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

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Wed, May 13, 2015 at 05:54:19PM +0100, Lee Jones wrote:
> On Wed, 13 May 2015, Mark Brown wrote:

> > If you're looking for me to review something you need to send it to me,
> > and the chances of me looking at it are very much increased if there's a
> > relevant subject line.  I'm CCed (not even on the to list) on endless
> > large threads and reposts of patch serieses about MFD drivers most of
> > which are of very little relevance to me so they get ignored very
> > easily.

> Calm down dear, it's only a commercial.

> I wasn't having a pop.  Rather empathising with your situation and
> facilitating a resend that you're likely to see.

> I'm sure Johan will do the right thing.

My point is that a simple resend has a reasonable chance of getting
dropped on the floor.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Lee Jones]

On Wed, 13 May 2015, Mark Brown wrote:

> On Wed, May 13, 2015 at 05:54:19PM +0100, Lee Jones wrote:
> > On Wed, 13 May 2015, Mark Brown wrote:
> 
> > > If you're looking for me to review something you need to send it to me,
> > > and the chances of me looking at it are very much increased if there's a
> > > relevant subject line.  I'm CCed (not even on the to list) on endless
> > > large threads and reposts of patch serieses about MFD drivers most of
> > > which are of very little relevance to me so they get ignored very
> > > easily.
> 
> > Calm down dear, it's only a commercial.
> 
> > I wasn't having a pop.  Rather empathising with your situation and
> > facilitating a resend that you're likely to see.
> 
> > I'm sure Johan will do the right thing.
> 
> My point is that a simple resend has a reasonable chance of getting
> dropped on the floor.

As I say, I'm sure Johan will do what's required for that not to
happen.

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

[PATCH RESEND] mfd: da9052: fix broken regulator probe

[Johan Hovold]

Fix broken probe of da9052 regulators, which since commit b3f6c73db732
("mfd: da9052-core: Fix platform-device id collision") use a
non-deterministic platform-device id to retrieve static regulator
information. Fortunately, adequate error handling was in place so probe
would simply fail with an error message.

Update the mfd-cell ids to be zero-based and use those to identify the
cells when probing the regulator devices.

Fixes: b3f6c73db732 ("mfd: da9052-core: Fix platform-device id collision")
Cc: stable <stable@vger.kernel.org>	# v3.19
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---

Resending per Lee's request to get an ack from Mark Brown.

Johan


 drivers/mfd/da9052-core.c            | 8 ++++----
 drivers/regulator/da9052-regulator.c | 5 +++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
index ae498b53ee40..46e3840c7a37 100644
--- a/drivers/mfd/da9052-core.c
+++ b/drivers/mfd/da9052-core.c
@@ -433,6 +433,10 @@ EXPORT_SYMBOL_GPL(da9052_adc_read_temp);
 static const struct mfd_cell da9052_subdev_info[] = {
 	{
 		.name = "da9052-regulator",
+		.id = 0,
+	},
+	{
+		.name = "da9052-regulator",
 		.id = 1,
 	},
 	{
@@ -484,10 +488,6 @@ static const struct mfd_cell da9052_subdev_info[] = {
 		.id = 13,
 	},
 	{
-		.name = "da9052-regulator",
-		.id = 14,
-	},
-	{
 		.name = "da9052-onkey",
 	},
 	{
diff --git a/drivers/regulator/da9052-regulator.c b/drivers/regulator/da9052-regulator.c
index 8a4df7a1f2ee..e628d4c2f2ae 100644
--- a/drivers/regulator/da9052-regulator.c
+++ b/drivers/regulator/da9052-regulator.c
@@ -394,6 +394,7 @@ static inline struct da9052_regulator_info *find_regulator_info(u8 chip_id,
 
 static int da9052_regulator_probe(struct platform_device *pdev)
 {
+	const struct mfd_cell *cell = mfd_get_cell(pdev);
 	struct regulator_config config = { };
 	struct da9052_regulator *regulator;
 	struct da9052 *da9052;
@@ -409,7 +410,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
 	regulator->da9052 = da9052;
 
 	regulator->info = find_regulator_info(regulator->da9052->chip_id,
-					      pdev->id);
+					      cell->id);
 	if (regulator->info == NULL) {
 		dev_err(&pdev->dev, "invalid regulator ID specified\n");
 		return -EINVAL;
@@ -419,7 +420,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
 	config.driver_data = regulator;
 	config.regmap = da9052->regmap;
 	if (pdata && pdata->regulators) {
-		config.init_data = pdata->regulators[pdev->id];
+		config.init_data = pdata->regulators[cell->id];
 	} else {
 #ifdef CONFIG_OF
 		struct device_node *nproot = da9052->dev->of_node;
-- 
2.3.6

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Johan Hovold]

On Thu, May 14, 2015 at 08:19:43AM +0100, Lee Jones wrote:
> On Wed, 13 May 2015, Mark Brown wrote:
> 
> > On Wed, May 13, 2015 at 05:54:19PM +0100, Lee Jones wrote:
> > > On Wed, 13 May 2015, Mark Brown wrote:
> > 
> > > > If you're looking for me to review something you need to send it to me,
> > > > and the chances of me looking at it are very much increased if there's a
> > > > relevant subject line.  I'm CCed (not even on the to list) on endless
> > > > large threads and reposts of patch serieses about MFD drivers most of
> > > > which are of very little relevance to me so they get ignored very
> > > > easily.
> > 
> > > Calm down dear, it's only a commercial.
> > 
> > > I wasn't having a pop.  Rather empathising with your situation and
> > > facilitating a resend that you're likely to see.
> > 
> > > I'm sure Johan will do the right thing.
> > 
> > My point is that a simple resend has a reasonable chance of getting
> > dropped on the floor.
> 
> As I say, I'm sure Johan will do what's required for that not to
> happen.

Seriously? *Me* do the right thing?

We have a regression in your subsystems (mfd/regulator) with a fix
that's been sitting in both your mailboxes since March 25th.

And now that Mark finally responds to a mail after repeated reminders
from both me and Lee, he still doesn't care enough to look up the
original mail or at least make sure that a resend does not get lost
again.

You two even work for the same organisation. Just pick up the phone or
find a way to get a message across that mail filter instead of wasting
everyone else's time.

I have resent the patch now. Please make sure it gets applied.

Johan

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Lee Jones]

On Fri, 15 May 2015, Johan Hovold wrote:
> On Thu, May 14, 2015 at 08:19:43AM +0100, Lee Jones wrote:
> > On Wed, 13 May 2015, Mark Brown wrote:
> > 
> > > On Wed, May 13, 2015 at 05:54:19PM +0100, Lee Jones wrote:
> > > > On Wed, 13 May 2015, Mark Brown wrote:
> > > 
> > > > > If you're looking for me to review something you need to send it to me,
> > > > > and the chances of me looking at it are very much increased if there's a
> > > > > relevant subject line.  I'm CCed (not even on the to list) on endless
> > > > > large threads and reposts of patch serieses about MFD drivers most of
> > > > > which are of very little relevance to me so they get ignored very
> > > > > easily.
> > > 
> > > > Calm down dear, it's only a commercial.
> > > 
> > > > I wasn't having a pop.  Rather empathising with your situation and
> > > > facilitating a resend that you're likely to see.
> > > 
> > > > I'm sure Johan will do the right thing.
> > > 
> > > My point is that a simple resend has a reasonable chance of getting
> > > dropped on the floor.
> > 
> > As I say, I'm sure Johan will do what's required for that not to
> > happen.
> 
> Seriously? *Me* do the right thing?

Yes, *you*.  If a patch slips though a Maintainer's net, which does
happen every so often [*], I'm sure even you are not infallible to
that, a submitter must issue a RESEND (as you have now just done so).

> We have a regression in your subsystems (mfd/regulator) with a fix
> that's been sitting in both your mailboxes since March 25th.

Fully aware and ready to apply once the correct process has been
carried out.  I get shirty when people submit MFD patches without
permission, and I refuse to be a hypocrite.

> And now that Mark finally responds to a mail after repeated reminders
> from both me and Lee, he still doesn't care enough to look up the
> original mail or at least make sure that a resend does not get lost
> again.

See [*] about how Mark deals with his torrent of daily mail.

> You two even work for the same organisation. 

Irrelevant.

> Just pick up the phone or
> find a way to get a message across that mail filter instead of wasting
> everyone else's time.
> 
> I have resent the patch now. Please make sure it gets applied.

[*] Especially when you receive as much email as Mark does.  To cope
he has a brain-highpass-filter on the subject line and purges his
inbox regularly.

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

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Johan Hovold]

On Mon, May 18, 2015 at 10:10:49AM +0100, Lee Jones wrote:
> On Fri, 15 May 2015, Johan Hovold wrote:
> > On Thu, May 14, 2015 at 08:19:43AM +0100, Lee Jones wrote:
> > > On Wed, 13 May 2015, Mark Brown wrote:
> > > 
> > > > On Wed, May 13, 2015 at 05:54:19PM +0100, Lee Jones wrote:
> > > > > On Wed, 13 May 2015, Mark Brown wrote:
> > > > 
> > > > > > If you're looking for me to review something you need to send it to me,
> > > > > > and the chances of me looking at it are very much increased if there's a
> > > > > > relevant subject line.  I'm CCed (not even on the to list) on endless
> > > > > > large threads and reposts of patch serieses about MFD drivers most of
> > > > > > which are of very little relevance to me so they get ignored very
> > > > > > easily.
> > > > 
> > > > > Calm down dear, it's only a commercial.
> > > > 
> > > > > I wasn't having a pop.  Rather empathising with your situation and
> > > > > facilitating a resend that you're likely to see.
> > > > 
> > > > > I'm sure Johan will do the right thing.
> > > > 
> > > > My point is that a simple resend has a reasonable chance of getting
> > > > dropped on the floor.
> > > 
> > > As I say, I'm sure Johan will do what's required for that not to
> > > happen.
> > 
> > Seriously? *Me* do the right thing?
> 
> Yes, *you*.  If a patch slips though a Maintainer's net, which does
> happen every so often [*], I'm sure even you are not infallible to
> that, a submitter must issue a RESEND (as you have now just done so).

As you know, five reminders asking for an ack from Mark was sent by the
two of us combined without even an indication that the messages had been
noted over a period of almost two months.

If Mark feels that he is getting spammed with unrelated MFD patches,
then *you* and Mark need to figure out a way to get a message across
when there actually is something he needs to look at.

I don't care if it's with a special [Lee-wants-Marks-ack] subject
prefix, an irc message on Linaro's channels or a phone call, but it's not
something that a patch submitter for MFD should need to know about
(it obviously isn't even documented).

> > We have a regression in your subsystems (mfd/regulator) with a fix
> > that's been sitting in both your mailboxes since March 25th.
> 
> Fully aware and ready to apply once the correct process has been
> carried out.  I get shirty when people submit MFD patches without
> permission, and I refuse to be a hypocrite.

That's perfectly fine. Your subsystems intersect and you two need to
figure out how you communicate. That's all.

Johan

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Lee Jones]

On Mon, 18 May 2015, Johan Hovold wrote:

> On Mon, May 18, 2015 at 10:10:49AM +0100, Lee Jones wrote:
> > On Fri, 15 May 2015, Johan Hovold wrote:
> > > On Thu, May 14, 2015 at 08:19:43AM +0100, Lee Jones wrote:
> > > > On Wed, 13 May 2015, Mark Brown wrote:
> > > > 
> > > > > On Wed, May 13, 2015 at 05:54:19PM +0100, Lee Jones wrote:
> > > > > > On Wed, 13 May 2015, Mark Brown wrote:
> > > > > 
> > > > > > > If you're looking for me to review something you need to send it to me,
> > > > > > > and the chances of me looking at it are very much increased if there's a
> > > > > > > relevant subject line.  I'm CCed (not even on the to list) on endless
> > > > > > > large threads and reposts of patch serieses about MFD drivers most of
> > > > > > > which are of very little relevance to me so they get ignored very
> > > > > > > easily.
> > > > > 
> > > > > > Calm down dear, it's only a commercial.
> > > > > 
> > > > > > I wasn't having a pop.  Rather empathising with your situation and
> > > > > > facilitating a resend that you're likely to see.
> > > > > 
> > > > > > I'm sure Johan will do the right thing.
> > > > > 
> > > > > My point is that a simple resend has a reasonable chance of getting
> > > > > dropped on the floor.
> > > > 
> > > > As I say, I'm sure Johan will do what's required for that not to
> > > > happen.
> > > 
> > > Seriously? *Me* do the right thing?
> > 
> > Yes, *you*.  If a patch slips though a Maintainer's net, which does
> > happen every so often [*], I'm sure even you are not infallible to
> > that, a submitter must issue a RESEND (as you have now just done so).
> 
> As you know, five reminders asking for an ack from Mark was sent by the
> two of us combined without even an indication that the messages had been
> noted over a period of almost two months.
> 
> If Mark feels that he is getting spammed with unrelated MFD patches,
> then *you* and Mark need to figure out a way to get a message across
> when there actually is something he needs to look at.
> 
> I don't care if it's with a special [Lee-wants-Marks-ack] subject
> prefix, an irc message on Linaro's channels or a phone call, but it's not
> something that a patch submitter for MFD should need to know about
> (it obviously isn't even documented).
> 
> > > We have a regression in your subsystems (mfd/regulator) with a fix
> > > that's been sitting in both your mailboxes since March 25th.
> > 
> > Fully aware and ready to apply once the correct process has been
> > carried out.  I get shirty when people submit MFD patches without
> > permission, and I refuse to be a hypocrite.
> 
> That's perfectly fine. Your subsystems intersect and you two need to
> figure out how you communicate. That's all.

This issue is out of the ordinary.  Normally Mark is pretty good at
providing me with the Acks I need.  More commonly I have issues such
as the one you are experiencing with non-responsive/inactive
Maintainers.

In future, for yourself and anyone else who is following this thread
for 'fun', if a patch crosses multiple subsystems (which I try to keep
to a minimum) it's probably best to indicate that in the subject line.

mfd: regulator: <blah>

... would definitely get Marks attention.  And yes, I know 'regulator'
is mentioned in the subject line of the particular patch. :)

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

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

On Mon, May 18, 2015 at 11:51:59AM +0200, Johan Hovold wrote:
> On Mon, May 18, 2015 at 10:10:49AM +0100, Lee Jones wrote:

> > Yes, *you*.  If a patch slips though a Maintainer's net, which does
> > happen every so often [*], I'm sure even you are not infallible to
> > that, a submitter must issue a RESEND (as you have now just done so).

> As you know, five reminders asking for an ack from Mark was sent by the
> two of us combined without even an indication that the messages had been
> noted over a period of almost two months.

The reason that there was no indication that the message had been noted
was that the message had in fact not been seen, nor had any of your
pings; one of the big problems here is that you are sending pings
instead of resending (which is something that does get frequent
pushback, Lee did advise you to resend).

> If Mark feels that he is getting spammed with unrelated MFD patches,
> then *you* and Mark need to figure out a way to get a message across
> when there actually is something he needs to look at.

Like I say, resending is the main advice here.

> I don't care if it's with a special [Lee-wants-Marks-ack] subject
> prefix, an irc message on Linaro's channels or a phone call, but it's not
> something that a patch submitter for MFD should need to know about
> (it obviously isn't even documented).

Resending is something that is pretty standard.  Most of the things that
can result in something not getting looked at also involve no longer
having a copy of the patch (so a resend will be needed anyway), and
often many of the others will result in the ping not being seen either
(for example it gets threaded in with the patch buried in the mailbox,
or it looks like the patch is generating lots of discussion and will
need a new version anyway).  At best it's going to require going and
finding the original mail, and they can be actively unhelpful.

A fresh copy of the patch in contrast fits naturally into the standard
workflow with no extra barriers.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

On Mon, May 18, 2015 at 11:13:55AM +0100, Lee Jones wrote:

> In future, for yourself and anyone else who is following this thread
> for 'fun', if a patch crosses multiple subsystems (which I try to keep
> to a minimum) it's probably best to indicate that in the subject line.

> mfd: regulator: <blah>

> ... would definitely get Marks attention.  And yes, I know 'regulator'
> is mentioned in the subject line of the particular patch. :)

Yeah, sadly it's not visible in the thread view in mutt here since it's
too late in the subject line.  That is good advice, though - the
standard thing is either like you describe or "mfd/regulator: ".

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Johan Hovold]

On Mon, May 18, 2015 at 05:24:05PM +0100, Mark Brown wrote:
> On Mon, May 18, 2015 at 11:51:59AM +0200, Johan Hovold wrote:

> > If Mark feels that he is getting spammed with unrelated MFD patches,
> > then *you* and Mark need to figure out a way to get a message across
> > when there actually is something he needs to look at.
> 
> Like I say, resending is the main advice here.
> 
> > I don't care if it's with a special [Lee-wants-Marks-ack] subject
> > prefix, an irc message on Linaro's channels or a phone call, but it's not
> > something that a patch submitter for MFD should need to know about
> > (it obviously isn't even documented).
> 
> Resending is something that is pretty standard.  Most of the things that
> can result in something not getting looked at also involve no longer
> having a copy of the patch (so a resend will be needed anyway), and
> often many of the others will result in the ping not being seen either
> (for example it gets threaded in with the patch buried in the mailbox,
> or it looks like the patch is generating lots of discussion and will
> need a new version anyway).  At best it's going to require going and
> finding the original mail, and they can be actively unhelpful.
> 
> A fresh copy of the patch in contrast fits naturally into the standard
> workflow with no extra barriers.

Yes, resending is sometimes needed, but what set me off here was your
comment that resending might not be enough even after you've now become
aware of a several-month old regression in your subsystem.

I know you process a lot of mail, but perhaps some (further) filtering
could help avoid situations like this. The patch touches
drivers/regulator/ and has a stable tag for example.

Johan

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

On Mon, May 18, 2015 at 06:46:30PM +0200, Johan Hovold wrote:

> Yes, resending is sometimes needed, but what set me off here was your
> comment that resending might not be enough even after you've now become
> aware of a several-month old regression in your subsystem.

If you're referring to my original reply I'm afraid to disappoint you
but I hadn't read far enough in the backtrace to see anything except
that people wanted me to look at a patch I didn't have a copy of (I
didn't even know if I'd been CCed on the original posting).  I was
simply trying to say that it might be worth looking at other aspects of
how the patch was sent - what you got there was basically a form letter
type response to contentless pings.

> I know you process a lot of mail, but perhaps some (further) filtering
> could help avoid situations like this. The patch touches
> drivers/regulator/ and has a stable tag for example.

Neither of those is reliable enough for mechanical filtering for the
things I'm doing here I'm afraid, and I especially don't think it would
be a good idea people to get the idea that adding a stable tag is a good
way of jumping the queue and it's not that reliable an indication of
urgency (some development only issues that cause widespread breakage are
much more urgent, some stable patches are for things that are definite
issues with clear fixes but relatively low risk/impact).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH RESEND] mfd: da9052: fix broken regulator probe

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

On Fri, May 15, 2015 at 04:27:40PM +0200, Johan Hovold wrote:
> Fix broken probe of da9052 regulators, which since commit b3f6c73db732
> ("mfd: da9052-core: Fix platform-device id collision") use a
> non-deterministic platform-device id to retrieve static regulator
> information. Fortunately, adequate error handling was in place so probe
> would simply fail with an error message.

Reviewed-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH RESEND] mfd: da9052: fix broken regulator probe

[Lee Jones]

On Fri, 15 May 2015, Johan Hovold wrote:

> Fix broken probe of da9052 regulators, which since commit b3f6c73db732
> ("mfd: da9052-core: Fix platform-device id collision") use a
> non-deterministic platform-device id to retrieve static regulator
> information. Fortunately, adequate error handling was in place so probe
> would simply fail with an error message.
> 
> Update the mfd-cell ids to be zero-based and use those to identify the
> cells when probing the regulator devices.
> 
> Fixes: b3f6c73db732 ("mfd: da9052-core: Fix platform-device id collision")
> Cc: stable <stable@vger.kernel.org>	# v3.19
> Signed-off-by: Johan Hovold <johan@kernel.org>
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Acked-by: Lee Jones <lee.jones@linaro.org>
> ---
> 
> Resending per Lee's request to get an ack from Mark Brown.
> 
> Johan
> 
> 
>  drivers/mfd/da9052-core.c            | 8 ++++----
>  drivers/regulator/da9052-regulator.c | 5 +++--
>  2 files changed, 7 insertions(+), 6 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> index ae498b53ee40..46e3840c7a37 100644
> --- a/drivers/mfd/da9052-core.c
> +++ b/drivers/mfd/da9052-core.c
> @@ -433,6 +433,10 @@ EXPORT_SYMBOL_GPL(da9052_adc_read_temp);
>  static const struct mfd_cell da9052_subdev_info[] = {
>  	{
>  		.name = "da9052-regulator",
> +		.id = 0,
> +	},
> +	{
> +		.name = "da9052-regulator",
>  		.id = 1,
>  	},
>  	{
> @@ -484,10 +488,6 @@ static const struct mfd_cell da9052_subdev_info[] = {
>  		.id = 13,
>  	},
>  	{
> -		.name = "da9052-regulator",
> -		.id = 14,
> -	},
> -	{
>  		.name = "da9052-onkey",
>  	},
>  	{
> diff --git a/drivers/regulator/da9052-regulator.c b/drivers/regulator/da9052-regulator.c
> index 8a4df7a1f2ee..e628d4c2f2ae 100644
> --- a/drivers/regulator/da9052-regulator.c
> +++ b/drivers/regulator/da9052-regulator.c
> @@ -394,6 +394,7 @@ static inline struct da9052_regulator_info *find_regulator_info(u8 chip_id,
>  
>  static int da9052_regulator_probe(struct platform_device *pdev)
>  {
> +	const struct mfd_cell *cell = mfd_get_cell(pdev);
>  	struct regulator_config config = { };
>  	struct da9052_regulator *regulator;
>  	struct da9052 *da9052;
> @@ -409,7 +410,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
>  	regulator->da9052 = da9052;
>  
>  	regulator->info = find_regulator_info(regulator->da9052->chip_id,
> -					      pdev->id);
> +					      cell->id);
>  	if (regulator->info == NULL) {
>  		dev_err(&pdev->dev, "invalid regulator ID specified\n");
>  		return -EINVAL;
> @@ -419,7 +420,7 @@ static int da9052_regulator_probe(struct platform_device *pdev)
>  	config.driver_data = regulator;
>  	config.regmap = da9052->regmap;
>  	if (pdata && pdata->regulators) {
> -		config.init_data = pdata->regulators[pdev->id];
> +		config.init_data = pdata->regulators[cell->id];
>  	} else {
>  #ifdef CONFIG_OF
>  		struct device_node *nproot = da9052->dev->of_node;

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

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Johan Hovold]

On Mon, May 18, 2015 at 07:46:54PM +0100, Mark Brown wrote:
> On Mon, May 18, 2015 at 06:46:30PM +0200, Johan Hovold wrote:
> 
> > Yes, resending is sometimes needed, but what set me off here was your
> > comment that resending might not be enough even after you've now become
> > aware of a several-month old regression in your subsystem.
> 
> If you're referring to my original reply I'm afraid to disappoint you
> but I hadn't read far enough in the backtrace to see anything except
> that people wanted me to look at a patch I didn't have a copy of (I
> didn't even know if I'd been CCed on the original posting).  I was
> simply trying to say that it might be worth looking at other aspects of
> how the patch was sent - what you got there was basically a form letter
> type response to contentless pings.

I might have read too much into that response, but the pings were hardly
contentless (they all included the commit message and some the full patch).

Anyway, glad to see the issue resolved now. Thanks for the review.

Johan

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

On Tue, May 19, 2015 at 12:01:03PM +0200, Johan Hovold wrote:

> I might have read too much into that response, but the pings were hardly
> contentless (they all included the commit message and some the full patch).

It's the new content that is important here - if it boils down to "have
you looked at this yet" that's not really adding anything and if it's a
patch to be applied then it really needs to not be quoted.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Johan Hovold]

On Tue, May 19, 2015 at 11:38:08AM +0100, Mark Brown wrote:
> On Tue, May 19, 2015 at 12:01:03PM +0200, Johan Hovold wrote:
> 
> > I might have read too much into that response, but the pings were hardly
> > contentless (they all included the commit message and some the full patch).
> 
> It's the new content that is important here - if it boils down to "have
> you looked at this yet" that's not really adding anything and if it's a
> patch to be applied then it really needs to not be quoted.

My reminders sent directly to you explicitly mentioned it being a
regression every time. That should trigger a maintainer's interest
enough to look at the quoted context or ask for a resend.

How should a patch submitter know that you simply drop mails with an mfd
prefix even if it's directed to you? Unless documented somewhere, that's
were Lee can help through being familiar with the quirks of your work flow.

Johan

Re: [PATCH 1/2] mfd: da9052: fix broken regulator probe

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

On Tue, May 19, 2015 at 01:01:19PM +0200, Johan Hovold wrote:

> My reminders sent directly to you explicitly mentioned it being a
> regression every time. That should trigger a maintainer's interest
> enough to look at the quoted context or ask for a resend.

Sadly what I actually ended up reading was Lee's reply not one of your
mails.

> How should a patch submitter know that you simply drop mails with an mfd
> prefix even if it's directed to you? Unless documented somewhere, that's
> were Lee can help through being familiar with the quirks of your work flow.

I don't drop *all* such mails, this isn't a rules based thing but rather
something that depends on a bunch of factors including how busy I am at
that particular moment.  MFD discussions (even more so than patches) are
certainly a bit of a warning sign here but that's not the only factor
and there are positives as well as negatives.  For example very broad CC
lists on driver specific patches usually indicate that someone just sent
the mail to everyone that get_maintainers --git pulled out (which tends
to generate a lot of false positives), but on the other hand something
like syscon (which is broadly used) or DT bindings (which often affect
subfunctions too) is more likely to be relevant.

About the only hard and fast rule for this sort of thing is that if
someone wants specific people to look at a patch it's usually a good
idea to send the actual patch directly to them with a relevant subject
line.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]