From: Andrew Morton <akpm@linux-foundation.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/2] backlight: lcd: add driver for raster-type lcd's with gpio controlled panel reset
Date: Fri, 06 Apr 2012 23:17:20 +0000 [thread overview]
Message-ID: <20120406161720.cf464c39.akpm@linux-foundation.org> (raw)
In-Reply-To: <1332751600-11371-2-git-send-email-thomas.abraham@linaro.org>
> Cc: rpurdie@rpsys.net, florianSchandinat@gmx.de, devicetree-discuss@lists.ozlabs.org, linux-fbdev@vger.kernel.org, linux-samsung-soc@vger.kernel.org, grant.likely@secretlab.ca, rob.herring@calxeda.com, kgene.kim@samsung.com, jg1.han@samsung.com, broonie@opensource.wolfsonmicro.com, kyungmin.park@samsung.com, augulis.darius@gmail.com, ben-linux@fluff.org, lars@metafoo.de, patches@linaro.org
Poor me. When someone sends a patch like this, I need to go and hunt
down everyone's real names to nicely add them to the changelog's Cc:
list. I prefer that you do this ;)
You can add Cc:'s to the changelog yourself, of course. Often that
works out better than having me try to work out who might be
interested in the patch.
On Mon, 26 Mar 2012 14:16:39 +0530
Thomas Abraham <thomas.abraham@linaro.org> wrote:
> Add a lcd panel driver for simple raster-type lcd's which uses a gpio
> controlled panel reset. The driver controls the nRESET line of the panel
> using a gpio connected from the host system. The Vcc supply to the panel
> is (optionally) controlled using a voltage regulator. This driver excludes
> support for lcd panels that use a serial command interface or direct
> memory mapped IO interface.
>
>
> ...
>
> +struct lcd_pwrctrl {
> + struct device *dev;
> + struct lcd_device *lcd;
> + struct lcd_pwrctrl_data *pdata;
> + struct regulator *regulator;
> + unsigned int power;
> + bool suspended;
> + bool pwr_en;
Generally kernel code will avoid these unpronounceable abbreviations.
So we do
pwr -> power
en -> enable
ctrl -> control
etc. It results in longer identifiers, but the code is more readable
and, more importantly, more *rememberable*.
> +};
> +
> +static int lcd_pwrctrl_get_power(struct lcd_device *lcd)
> +{
> + struct lcd_pwrctrl *lp = lcd_get_data(lcd);
> + return lp->power;
> +}
> +
> +static int lcd_pwrctrl_set_power(struct lcd_device *lcd, int power)
See, shouldn't that have been lcd_pwrctrl_set_pwr?
If we avoid the abbreviations, such issues do not arise.
> +{
> + struct lcd_pwrctrl *lp = lcd_get_data(lcd);
> + struct lcd_pwrctrl_data *pd = lp->pdata;
> + bool lcd_enable;
> + int lcd_reset, ret = 0;
> +
> + lcd_enable = (power = FB_BLANK_POWERDOWN || lp->suspended) ? 0 : 1;
This isn't how to use `bool'. We can use
lcd_enable = (power = FB_BLANK_POWERDOWN) || lp->suspended;
> + lcd_reset = (pd->invert) ? !lcd_enable : lcd_enable;
> +
> + if (lp->pwr_en = lcd_enable)
> + return 0;
> +
> + if (!IS_ERR_OR_NULL(lp->regulator)) {
> + if (lcd_enable) {
> + if (regulator_enable(lp->regulator)) {
> + dev_info(lp->dev, "regulator enable failed\n");
> + ret = -EPERM;
> + }
> + } else {
> + if (regulator_disable(lp->regulator)) {
> + dev_info(lp->dev, "regulator disable failed\n");
> + ret = -EPERM;
> + }
> + }
> + }
> +
> + gpio_direction_output(lp->pdata->gpio, lcd_reset);
> + lp->power = power;
> + lp->pwr_en = lcd_enable;
Again, this could have been any of
lp->[power|pwr] = [power|pwr];
lp->[power|pwr]_[en|enable] = lcd_[en|enable];
zillions of combinations! If we just avoid the abbreviations, there is
only one combination.
> + return ret;
> +}
> +
>
> ...
>
> +static int __devinit lcd_pwrctrl_probe(struct platform_device *pdev)
> +{
> + struct lcd_pwrctrl *lp;
> + struct lcd_pwrctrl_data *pdata = pdev->dev.platform_data;
> + struct device *dev = &pdev->dev;
> + int err;
> +
> +#ifdef CONFIG_OF
> + if (dev->of_node) {
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + dev_err(dev, "memory allocation for pdata failed\n");
> + return -ENOMEM;
> + }
> + lcd_pwrctrl_parse_dt(dev, pdata);
> + }
> +#endif
> +
> + if (!pdata) {
> + dev_err(dev, "platform data not available\n");
> + return -EINVAL;
> + }
> +
> + lp = devm_kzalloc(dev, sizeof(struct lcd_pwrctrl), GFP_KERNEL);
Nit: I prefer sizeof(*lp) here, so I don't have to scroll back and
check the type of lp.
> + if (!lp) {
> + dev_err(dev, "memory allocation failed for private data\n");
> + return -ENOMEM;
> + }
> +
> + err = gpio_request(pdata->gpio, "LCD-nRESET");
> + if (err) {
> + dev_err(dev, "gpio [%d] request failed\n", pdata->gpio);
> + return err;
> + }
> +
>
> ...
>
The code looks OK to me, but I do think the naming decisions should be
revisited, please.
next prev parent reply other threads:[~2012-04-06 23:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-26 8:58 [PATCH v3 0/2] Add lcd driver for panels with gpio controlled panel reset Thomas Abraham
2012-03-26 8:58 ` [PATCH v3 1/2] backlight: lcd: add driver for raster-type lcd's " Thomas Abraham
2012-04-06 23:17 ` Andrew Morton [this message]
2012-03-26 8:58 ` [PATCH v3 2/2] ARM: Exynos: Use lcd power control driver for lcd panel Thomas Abraham
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=20120406161720.cf464c39.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).