All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Lee Jones <lee.jones@linaro.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-samsung-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Kukjin Kim <kgene@kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [PATCH v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings
Date: Thu, 27 Nov 2014 18:43:42 +0000	[thread overview]
Message-ID: <20141127184342.GC7712@sirena.org.uk> (raw)
In-Reply-To: <1417087253-12306-5-git-send-email-k.kozlowski@samsung.com>

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

On Thu, Nov 27, 2014 at 12:20:50PM +0100, Krzysztof Kozlowski wrote:
> Use ena_gpio from regulator constraints (filled by parsing generic
> bindings) to initialize the GPIO enable control. Support also the old
> way: ena_gpio supplied in regulator_config structure.
> 
> This also adds a new set_ena_gpio() callback in regulator_ops structure
> which driver may provide to actually enable the GPIO control in
> hardware.

This seems really confused like it's trying to work around some other
problem - this all feels like it's at the wrong abstraction level.  As
far as I can tell this is trying to fix bugs in the previous patch and
do some other refactorings (the "also add this other random op" bit
especially) but I'm really not clear what the goal is.

Please try to think if the code you're writing makes sense at the big
picture level rather than just band aiding specific problems you see.
It's also a good idea to keep random code motion separate from
functional changes since it makes it much easier to follow what each is
supposed to do.

> @@ -1044,6 +1045,14 @@ static int set_machine_constraints(struct regulator_dev *rdev,
>  		}
>  	}
>  
> +	if (rdev->constraints->use_ena_gpio && ops->set_ena_gpio) {
> +		ret = ops->set_ena_gpio(rdev);
> +		if (ret < 0) {
> +			rdev_err(rdev, "failed to set enable GPIO control\n");
> +			goto out;
> +		}
> +	}

Why do we need some special magic operation for GPIO based enables
that's separate to any other enable operation?  This seems really
confusing, if the constraint setting doesn't work somehow for GPIO based
enables we should fix that.  Though since this operation takes no
parameters it's hard to see how it's supposed to apply constraints
unless it reparses them which doesn't seem like a good idea...

>  static int regulator_ena_gpio_request(struct regulator_dev *rdev,
> -				const struct regulator_config *config)

> -	ret = gpio_request_one(config->ena_gpio,
> -				GPIOF_DIR_OUT | config->ena_gpio_flags,
> +	ret = gpio_request_one(gpio, GPIOF_DIR_OUT | gpio_flags,
>  				rdev_get_name(rdev));

> +/*
> + * Request GPIO for enable control from regulator_config
> + * or init_data->constraints.
> + */
> +static int regulator_ena_gpio_setup(struct regulator_dev *rdev,
> +			const struct regulator_config *config,
> +			const struct regulator_init_data *init_data)

Why is setting up the GPIO different to requesting it, especially given
that we have an existing function called _request() which still exists?

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

WARNING: multiple messages have this Message-ID (diff)
From: broonie@kernel.org (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings
Date: Thu, 27 Nov 2014 18:43:42 +0000	[thread overview]
Message-ID: <20141127184342.GC7712@sirena.org.uk> (raw)
In-Reply-To: <1417087253-12306-5-git-send-email-k.kozlowski@samsung.com>

On Thu, Nov 27, 2014 at 12:20:50PM +0100, Krzysztof Kozlowski wrote:
> Use ena_gpio from regulator constraints (filled by parsing generic
> bindings) to initialize the GPIO enable control. Support also the old
> way: ena_gpio supplied in regulator_config structure.
> 
> This also adds a new set_ena_gpio() callback in regulator_ops structure
> which driver may provide to actually enable the GPIO control in
> hardware.

This seems really confused like it's trying to work around some other
problem - this all feels like it's at the wrong abstraction level.  As
far as I can tell this is trying to fix bugs in the previous patch and
do some other refactorings (the "also add this other random op" bit
especially) but I'm really not clear what the goal is.

Please try to think if the code you're writing makes sense at the big
picture level rather than just band aiding specific problems you see.
It's also a good idea to keep random code motion separate from
functional changes since it makes it much easier to follow what each is
supposed to do.

> @@ -1044,6 +1045,14 @@ static int set_machine_constraints(struct regulator_dev *rdev,
>  		}
>  	}
>  
> +	if (rdev->constraints->use_ena_gpio && ops->set_ena_gpio) {
> +		ret = ops->set_ena_gpio(rdev);
> +		if (ret < 0) {
> +			rdev_err(rdev, "failed to set enable GPIO control\n");
> +			goto out;
> +		}
> +	}

Why do we need some special magic operation for GPIO based enables
that's separate to any other enable operation?  This seems really
confusing, if the constraint setting doesn't work somehow for GPIO based
enables we should fix that.  Though since this operation takes no
parameters it's hard to see how it's supposed to apply constraints
unless it reparses them which doesn't seem like a good idea...

>  static int regulator_ena_gpio_request(struct regulator_dev *rdev,
> -				const struct regulator_config *config)

> -	ret = gpio_request_one(config->ena_gpio,
> -				GPIOF_DIR_OUT | config->ena_gpio_flags,
> +	ret = gpio_request_one(gpio, GPIOF_DIR_OUT | gpio_flags,
>  				rdev_get_name(rdev));

> +/*
> + * Request GPIO for enable control from regulator_config
> + * or init_data->constraints.
> + */
> +static int regulator_ena_gpio_setup(struct regulator_dev *rdev,
> +			const struct regulator_config *config,
> +			const struct regulator_init_data *init_data)

Why is setting up the GPIO different to requesting it, especially given
that we have an existing function called _request() which still exists?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141127/cad8a8a4/attachment.sig>

  reply	other threads:[~2014-11-27 18:44 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-27 11:20 [PATCH v4 0/7] regulator: Parse ena_gpio in core, add GPIO to max77686 Krzysztof Kozlowski
2014-11-27 11:20 ` Krzysztof Kozlowski
2014-11-27 11:20 ` [PATCH v4 1/7] mfd: max77686/802: Remove support for board files Krzysztof Kozlowski
2014-11-27 11:20   ` Krzysztof Kozlowski
2014-11-27 13:03   ` Mark Brown
2014-11-27 13:03     ` Mark Brown
2014-11-27 13:08     ` Krzysztof Kozlowski
2014-11-27 13:08       ` Krzysztof Kozlowski
2014-11-27 11:20 ` [PATCH v4 2/7] regulator: dt-bindings: Document the ena-gpios property Krzysztof Kozlowski
2014-11-27 11:20   ` Krzysztof Kozlowski
2014-11-27 18:30   ` Mark Brown
2014-11-27 18:30     ` Mark Brown
2014-11-28  9:09     ` Krzysztof Kozlowski
2014-11-28  9:09       ` Krzysztof Kozlowski
2014-11-28  9:09       ` Krzysztof Kozlowski
2014-11-28 11:21       ` Mark Brown
2014-11-28 11:21         ` Mark Brown
2014-11-28 11:54         ` Krzysztof Kozlowski
2014-11-28 11:54           ` Krzysztof Kozlowski
2014-11-28 11:54           ` Krzysztof Kozlowski
2014-11-28 14:29           ` Mark Brown
2014-11-28 14:29             ` Mark Brown
2014-11-27 11:20 ` [PATCH v4 3/7] regulator: of: Parse ena-gpios property from DTS Krzysztof Kozlowski
2014-11-27 11:20   ` Krzysztof Kozlowski
2014-11-27 11:20   ` Krzysztof Kozlowski
2014-11-27 18:45   ` Mark Brown
2014-11-27 18:45     ` Mark Brown
2014-11-28  9:19     ` Krzysztof Kozlowski
2014-11-28  9:19       ` Krzysztof Kozlowski
2014-11-27 11:20 ` [PATCH v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings Krzysztof Kozlowski
2014-11-27 11:20   ` Krzysztof Kozlowski
2014-11-27 18:43   ` Mark Brown [this message]
2014-11-27 18:43     ` Mark Brown
2014-11-28 10:30     ` Krzysztof Kozlowski
2014-11-28 10:30       ` Krzysztof Kozlowski
2014-11-28 11:38       ` Mark Brown
2014-11-28 11:38         ` Mark Brown
2014-11-28 14:14         ` Krzysztof Kozlowski
2014-11-28 14:14           ` Krzysztof Kozlowski
2014-11-28 15:07           ` Mark Brown
2014-11-28 15:07             ` Mark Brown
2014-11-27 11:20 ` [PATCH v4 5/7] regulator: max77686: Add GPIO control Krzysztof Kozlowski
2014-11-27 11:20   ` Krzysztof Kozlowski
2014-11-27 11:20 ` [PATCH v4 6/7] mfd/regulator: dt-bindings: max77686: Document gpio properties Krzysztof Kozlowski
2014-11-27 11:20   ` Krzysztof Kozlowski
2014-11-27 11:20 ` [PATCH v4 7/7] ARM: dts: exynos4412-trats: Switch max77686 regulators to GPIO control Krzysztof Kozlowski
2014-11-27 11:20   ` Krzysztof Kozlowski

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=20141127184342.GC7712@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=k.kozlowski@samsung.com \
    --cc=kgene@kernel.org \
    --cc=kyungmin.park@samsung.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.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.