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>
next prev parent 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: linkBe 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.