From: "Tanwar, Rahul" <rahul.tanwar@linux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: u.kleine-koenig@pengutronix.de, linux-pwm@vger.kernel.org,
lee.jones@linaro.org, thierry.reding@gmail.com,
p.zabel@pengutronix.de, robh+dt@kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
songjun.Wu@intel.com, cheol.yong.kim@intel.com,
qi-ming.wu@intel.com, rahul.tanwar.linux@gmail.com,
rtanwar@maxlinear.com
Subject: Re: [PATCH v8 2/2] Add PWM fan controller driver for LGM SoC
Date: Fri, 21 Aug 2020 14:07:49 +0800 [thread overview]
Message-ID: <ae472e72-8727-b62b-4fc7-f62aa41cafbc@linux.intel.com> (raw)
In-Reply-To: <20200820105255.GB1891694@smile.fi.intel.com>
Hi Andy,
On 20/8/2020 6:52 pm, Andy Shevchenko wrote:
> On Thu, Aug 20, 2020 at 12:50:46PM +0800, Rahul Tanwar wrote:
>> Intel Lightning Mountain(LGM) SoC contains a PWM fan controller.
>> This PWM controller does not have any other consumer, it is a
>> dedicated PWM controller for fan attached to the system. Add
>> driver for this PWM fan controller.
> ...
>
>> +config PWM_INTEL_LGM
>> + tristate "Intel LGM PWM support"
>> + depends on OF && HAS_IOMEM
>> + depends on X86 || COMPILE_TEST
> For better test coverage you may rewrite this
>
> depends on HAS_IOMEM
> depends on (OF && X86) || COMPILE_TEST
Sure, will update.
>> + select REGMAP_MMIO
>> + help
>> + Generic PWM fan controller driver for LGM SoC.
>> +
>> + To compile this driver as a module, choose M here: the module
>> + will be called pwm-intel-lgm.
> ...
>
>> +#include <linux/bitfield.h>
>> +#include <linux/clk.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
> This should be mod_devicetable.h.
Well noted.
>> +#include <linux/pwm.h>
>> +#include <linux/regmap.h>
>> +#include <linux/reset.h>
> ...
>
>> +#define LGM_PWM_PERIOD_2WIRE_NSECS 40000000
> NSECS -> NS
> 40000000 -> (40 * NSEC_PER_MSEC)
Well noted.
> ...
>
>> + if (state->polarity != PWM_POLARITY_NORMAL ||
>> + state->period < pc->period)
> It can be one line.
Ok.
>> + return -EINVAL;
> ...
>
>> + if (!state->enabled) {
>> + ret = lgm_pwm_enable(chip, 0);
>> + return ret;
> What is the point?
I guess you mean to change it to return lgm_pwm_enable(chip, 0);
Will do, thanks.
>> + }
> ...
>
>> + ret = lgm_pwm_enable(chip, 1);
>> +
>> + return ret;
> Ditto.
>
> ...
>
>> + state->duty_cycle = DIV_ROUND_UP(duty * pc->period,
>> + LGM_PWM_MAX_DUTY_CYCLE);
> One line?
Ok.
> ...
>
>> + struct lgm_pwm_chip *pc;
>> + struct device *dev = &pdev->dev;
> Use reversed xmas tree order.
Sure, will update.
>> + void __iomem *io_base;
>> + int ret;
> ...
>
>> + pc->regmap = devm_regmap_init_mmio(dev, io_base, &lgm_pwm_regmap_config);
>> + if (IS_ERR(pc->regmap)) {
>> + ret = PTR_ERR(pc->regmap);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "failed to init register map: %pe\n",
>> + pc->regmap);
>> + return ret;
> dev_err_probe()
Will update. Thanks.
>> + }
> ...
>
>> + pc->clk = devm_clk_get(dev, NULL);
>> + if (IS_ERR(pc->clk)) {
>> + ret = PTR_ERR(pc->clk);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "failed to get clock: %pe\n", pc->clk);
>> + return ret;
> Ditto.
>
>> + }
>> +
>> + pc->rst = devm_reset_control_get_exclusive(dev, NULL);
>> + if (IS_ERR(pc->rst)) {
>> + ret = PTR_ERR(pc->rst);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "failed to get reset control: %pe\n",
>> + pc->rst);
>> + return ret;
> Ditto.
>
>> + }
>> +
>> + ret = reset_control_deassert(pc->rst);
>> + if (ret) {
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev, "cannot deassert reset control: %pe\n",
>> + ERR_PTR(ret));
>> + return ret;
> Ditto.
>
>> + }
> ...
>
>> + ret = clk_prepare_enable(pc->clk);
> Wrap it with devm_add_action_or_reset(). Same for reset_control_deassert().
> You probably can even put them under one function.
I did some study and research for using devm_add_action_or_reset(). But
still i have some doubts. Below steps is what i intend to do in order to
switch to using this API. Please do review and let me know it is ok and
i am not missing anything else. Thanks.
1. Call reset_control_assert()
2. Call clk_prepare_enable()
3. Call pwmchip_add()
4. Call devm_add_action_or_reset(dev, my_action, pc)
5. Remove explicit calls to unprepare/reset_control_assert from probe in
failure cases.
6. static void my_action(void *pc)
{
pwmchip_remove(&pc->chip);
clk_disable_upprepare(pc->clk);
reset_control_assert(pc->rst);
}
7. Remove platform_driver.remove() entirely.
>> + if (ret) {
>> + dev_err(dev, "failed to enable clock\n");
>> + reset_control_assert(pc->rst);
>> + return ret;
>> + }
> ...
>
>> + ret = pwmchip_add(&pc->chip);
>> + if (ret < 0) {
> Does ' < 0' have any meaning?
I use < 0 because this API's return code is mentioned as below:
Returns: 0 on success or a negative error code on failure.
Also, all other PWM drivers check for <0 for this call.
>> + dev_err(dev, "failed to add PWM chip: %pe\n", ERR_PTR(ret));
>> + clk_disable_unprepare(pc->clk);
>> + reset_control_assert(pc->rst);
>> + return ret;
>> + }
> ...
>
>> + ret = pwmchip_remove(&pc->chip);
>> + if (ret < 0)
> Ditto.
Same as above.
>> + return ret;
Thanks.
Regards,
Rahul
next prev parent reply other threads:[~2020-08-21 6:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-20 4:50 [PATCH v8 0/2] pwm: intel: Add PWM driver for a new SoC Rahul Tanwar
2020-08-20 4:50 ` [PATCH v8 1/2] Add DT bindings YAML schema for PWM fan controller of LGM SoC Rahul Tanwar
2020-08-20 4:50 ` [PATCH v8 2/2] Add PWM fan controller driver for " Rahul Tanwar
2020-08-20 10:52 ` Andy Shevchenko
2020-08-21 6:07 ` Tanwar, Rahul [this message]
2020-08-21 8:23 ` Andy Shevchenko
2020-08-21 9:14 ` Tanwar, Rahul
2020-08-21 10:52 ` Andy Shevchenko
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=ae472e72-8727-b62b-4fc7-f62aa41cafbc@linux.intel.com \
--to=rahul.tanwar@linux.intel.com \
--cc=andriy.shevchenko@intel.com \
--cc=cheol.yong.kim@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=qi-ming.wu@intel.com \
--cc=rahul.tanwar.linux@gmail.com \
--cc=robh+dt@kernel.org \
--cc=rtanwar@maxlinear.com \
--cc=songjun.Wu@intel.com \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/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).