From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: rtc-linux@googlegroups.com, ldewangan@nvidia.com
Cc: k.kozlowski.k@gmail.com, robh+dt@kernel.org, pawel.moll@arm.com,
mark.rutland@arm.com, ijc+devicetree@hellion.org.uk,
galak@codeaurora.org, linus.walleij@linaro.org, gnurou@gmail.com,
lee.jones@linaro.org, broonie@kernel.org, a.zummo@towertech.it,
alexandre.belloni@free-electrons.com, lgirdwood@gmail.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, swarren@nvidia.com,
treding@nvidia.com, Chaitanya Bandi <bandik@nvidia.com>,
Mallikarjun Kasoju <mkasoju@nvidia.com>
Subject: Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024
Date: Fri, 8 Jan 2016 22:14:20 +0900 [thread overview]
Message-ID: <568FB62C.9020109@samsung.com> (raw)
In-Reply-To: <568F7E7B.1010501@nvidia.com>
W dniu 08.01.2016 o 18:16, Laxman Dewangan pisze:
> Hi Krzysztof,
> Thanks for review.
> I will fix most of your comment on my next patch.
>
> Answering to some of comment/query.
>
> On Friday 08 January 2016 07:05 AM, Krzysztof Kozlowski wrote:
>> ()2016-01-07 23:38 GMT+09:00 Laxman Dewangan <ldewangan@nvidia.com>:
>> + dev_err(dev,
>> + "FPS enable-input %u is not
>> supported\n",
>> + pval);
>> Indentation of arguments does not seem equal here or maybe this is
>> just my email client. Have you run this through checkpatch? And
>> sparse? And coccicheck (that one definitely not because kbuild is
>> complaining)?
> I ran checkpatch before I sent.
Anyway please be sure that indentation is consistent.
>
>> + chip->rmap[i] = devm_regmap_init_i2c(chip->clients[i],
>> + (const struct regmap_config
>> *)&max77620_regmap_config[i]);
>> Indentation looks weird here (or again this is my email client...).
>> The cast is even weirder?!? Why casting?
> There is some parameter difference for MAX77620 and MAX20024. I have
> only one structure for it and changing tun time so I have not define
> this structure as constant.
> Now API needs const type structure and hence casting it.
I don't quite get... usually there is no need of casting pointer to a
writable memory when function accepts pointer to const.
>
> However, I have define different structure for MAX77620 and MAX20024
> which are const type and hence no need to explicitly casting here. This
> will be in my next patch.
You mean v2? Okay, let's wait for that...
>
> +static inline int max77620_reg_update(struct device *dev, int sid,
> + unsigned int reg, unsigned int mask, unsigned int val)
> +{
> + struct max77620_chip *chip = dev_get_drvdata(dev);
> +
> + return regmap_update_bits(chip->rmap[sid], reg, mask, val);
> +}
>
>> I think all these shouldn't be static inlines in header. Although some
>> of them are one-liners but rest are not. Let the compiler decide what
>> to do with these wrappers.
>
> If I dont make inline from header then this will complain as unused
> static function on related C compilation if it is not used on C. This
> header included from all sub module driver and they are not using all
> these APIs.
>
> To avoid compilation warning, I need to use inline here.
Because this shouldn't be defined in header at the first place. Instead
define it in main MFD driver with EXPORT_SYMBOL() and put in headers
just declaration.
Best regards,
Krzysztof
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: rtc-linux@googlegroups.com, ldewangan@nvidia.com
Cc: k.kozlowski.k@gmail.com, robh+dt@kernel.org, pawel.moll@arm.com,
mark.rutland@arm.com, ijc+devicetree@hellion.org.uk,
galak@codeaurora.org, linus.walleij@linaro.org, gnurou@gmail.com,
lee.jones@linaro.org, broonie@kernel.org, a.zummo@towertech.it,
alexandre.belloni@free-electrons.com, lgirdwood@gmail.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, swarren@nvidia.com,
treding@nvidia.com, Chaitanya Bandi <bandik@nvidia.com>,
Mallikarjun Kasoju <mkasoju@nvidia.com>
Subject: Re: [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024
Date: Fri, 8 Jan 2016 22:14:20 +0900 [thread overview]
Message-ID: <568FB62C.9020109@samsung.com> (raw)
In-Reply-To: <568F7E7B.1010501@nvidia.com>
W dniu 08.01.2016 o 18:16, Laxman Dewangan pisze:
> Hi Krzysztof,
> Thanks for review.
> I will fix most of your comment on my next patch.
>
> Answering to some of comment/query.
>
> On Friday 08 January 2016 07:05 AM, Krzysztof Kozlowski wrote:
>> ()2016-01-07 23:38 GMT+09:00 Laxman Dewangan <ldewangan@nvidia.com>:
>> + dev_err(dev,
>> + "FPS enable-input %u is not
>> supported\n",
>> + pval);
>> Indentation of arguments does not seem equal here or maybe this is
>> just my email client. Have you run this through checkpatch? And
>> sparse? And coccicheck (that one definitely not because kbuild is
>> complaining)?
> I ran checkpatch before I sent.
Anyway please be sure that indentation is consistent.
>
>> + chip->rmap[i] = devm_regmap_init_i2c(chip->clients[i],
>> + (const struct regmap_config
>> *)&max77620_regmap_config[i]);
>> Indentation looks weird here (or again this is my email client...).
>> The cast is even weirder?!? Why casting?
> There is some parameter difference for MAX77620 and MAX20024. I have
> only one structure for it and changing tun time so I have not define
> this structure as constant.
> Now API needs const type structure and hence casting it.
I don't quite get... usually there is no need of casting pointer to a
writable memory when function accepts pointer to const.
>
> However, I have define different structure for MAX77620 and MAX20024
> which are const type and hence no need to explicitly casting here. This
> will be in my next patch.
You mean v2? Okay, let's wait for that...
>
> +static inline int max77620_reg_update(struct device *dev, int sid,
> + unsigned int reg, unsigned int mask, unsigned int val)
> +{
> + struct max77620_chip *chip = dev_get_drvdata(dev);
> +
> + return regmap_update_bits(chip->rmap[sid], reg, mask, val);
> +}
>
>> I think all these shouldn't be static inlines in header. Although some
>> of them are one-liners but rest are not. Let the compiler decide what
>> to do with these wrappers.
>
> If I dont make inline from header then this will complain as unused
> static function on related C compilation if it is not used on C. This
> header included from all sub module driver and they are not using all
> these APIs.
>
> To avoid compilation warning, I need to use inline here.
Because this shouldn't be defined in header at the first place. Instead
define it in main MFD driver with EXPORT_SYMBOL() and put in headers
just declaration.
Best regards,
Krzysztof
--
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
next prev parent reply other threads:[~2016-01-08 13:14 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-07 14:38 [PATCH 0/6] Add support for MAXIM MAX77620/MAX20024 PMIC Laxman Dewangan
2016-01-07 14:38 ` Laxman Dewangan
2016-01-07 14:38 ` [rtc-linux] " Laxman Dewangan
2016-01-07 14:38 ` [PATCH 1/6] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024 Laxman Dewangan
2016-01-07 14:38 ` Laxman Dewangan
2016-01-07 14:38 ` [rtc-linux] " Laxman Dewangan
2016-01-07 23:12 ` Rob Herring
2016-01-07 23:12 ` [rtc-linux] " Rob Herring
2016-01-08 6:06 ` Laxman Dewangan
2016-01-08 6:06 ` Laxman Dewangan
2016-01-08 6:06 ` [rtc-linux] " Laxman Dewangan
2016-01-08 14:19 ` Rob Herring
2016-01-08 14:19 ` [rtc-linux] " Rob Herring
2016-01-07 14:38 ` [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024 Laxman Dewangan
2016-01-07 14:38 ` Laxman Dewangan
2016-01-07 14:38 ` [rtc-linux] " Laxman Dewangan
2016-01-07 15:56 ` [PATCH] mfd: max77620: fix platform_no_drv_owner.cocci warnings kbuild test robot
2016-01-07 15:56 ` kbuild test robot
2016-01-07 15:56 ` [rtc-linux] " kbuild test robot
2016-01-07 15:56 ` [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024 kbuild test robot
2016-01-07 15:56 ` kbuild test robot
2016-01-07 15:56 ` [rtc-linux] " kbuild test robot
2016-01-11 5:48 ` Lee Jones
2016-01-11 5:48 ` [rtc-linux] " Lee Jones
2016-01-08 1:35 ` [rtc-linux] " Krzysztof Kozlowski
2016-01-08 1:35 ` Krzysztof Kozlowski
[not found] ` <CAJKOXPfa0jjRWE6LKvNmwCRcG9Es7=36_03kTqCx-aB1wENx0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-08 9:16 ` Laxman Dewangan
2016-01-08 9:16 ` Laxman Dewangan
2016-01-08 9:16 ` Laxman Dewangan
2016-01-08 13:14 ` Krzysztof Kozlowski [this message]
2016-01-08 13:14 ` Krzysztof Kozlowski
2016-01-08 13:19 ` Laxman Dewangan
2016-01-08 13:19 ` Laxman Dewangan
2016-01-08 13:19 ` Laxman Dewangan
2016-01-08 13:32 ` Krzysztof Kozlowski
2016-01-08 13:32 ` Krzysztof Kozlowski
2016-01-11 5:46 ` Lee Jones
2016-01-11 5:46 ` Lee Jones
2016-01-11 5:46 ` Lee Jones
2016-01-11 6:26 ` Krzysztof Kozlowski
2016-01-11 6:26 ` Krzysztof Kozlowski
2016-01-11 9:05 ` Lee Jones
2016-01-11 9:05 ` Lee Jones
2016-01-07 14:38 ` [PATCH 3/6] pinctrl: max77620: add pincontrol " Laxman Dewangan
2016-01-07 14:38 ` Laxman Dewangan
2016-01-07 14:38 ` [rtc-linux] " Laxman Dewangan
2016-01-07 14:38 ` [PATCH 4/6] gpio: max77620: add gpio " Laxman Dewangan
2016-01-07 14:38 ` Laxman Dewangan
2016-01-07 14:38 ` [rtc-linux] " Laxman Dewangan
2016-01-07 14:38 ` [PATCH 5/6] rtc: max77620: add support for max77620/max20024 RTC driver Laxman Dewangan
2016-01-07 14:38 ` Laxman Dewangan
2016-01-07 14:38 ` [rtc-linux] " Laxman Dewangan
2016-01-08 1:07 ` Linux Kernel
2016-01-08 1:07 ` [rtc-linux] " Linux Kernel
2016-01-11 5:46 ` Lee Jones
2016-01-11 5:46 ` Lee Jones
2016-01-11 5:46 ` [rtc-linux] " Lee Jones
2016-01-14 9:06 ` Linus Walleij
2016-01-14 9:06 ` [rtc-linux] " Linus Walleij
2016-01-08 2:03 ` [rtc-linux] " Krzysztof Kozlowski
2016-01-08 2:03 ` Krzysztof Kozlowski
2016-01-08 10:20 ` Laxman Dewangan
2016-01-08 10:20 ` Laxman Dewangan
2016-01-08 10:20 ` Laxman Dewangan
2016-01-08 12:51 ` Mark Brown
2016-01-08 12:51 ` Mark Brown
2016-01-08 13:04 ` Laxman Dewangan
2016-01-08 13:04 ` Laxman Dewangan
2016-01-08 13:04 ` Laxman Dewangan
2016-01-08 13:36 ` Mark Brown
2016-01-08 13:36 ` Mark Brown
2016-01-08 13:36 ` Laxman Dewangan
2016-01-08 13:36 ` Laxman Dewangan
2016-01-08 13:36 ` Laxman Dewangan
2016-01-11 13:17 ` Laxman Dewangan
2016-01-11 13:17 ` Laxman Dewangan
2016-01-11 13:17 ` Laxman Dewangan
2016-01-11 16:04 ` Alexandre Belloni
2016-01-11 16:04 ` Alexandre Belloni
2016-01-11 17:07 ` Laxman Dewangan
2016-01-11 17:07 ` Laxman Dewangan
2016-01-11 17:07 ` Laxman Dewangan
2016-01-12 0:13 ` Krzysztof Kozlowski
2016-01-12 0:13 ` Krzysztof Kozlowski
2016-01-12 2:32 ` Laxman Dewangan
2016-01-12 2:32 ` Laxman Dewangan
2016-01-12 2:32 ` Laxman Dewangan
2016-01-12 3:51 ` Krzysztof Kozlowski
2016-01-12 3:51 ` Krzysztof Kozlowski
2016-01-08 13:05 ` Krzysztof Kozlowski
2016-01-08 13:05 ` Krzysztof Kozlowski
[not found] ` <568FB423.7030108-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-01-08 13:13 ` Laxman Dewangan
2016-01-08 13:13 ` Laxman Dewangan
2016-01-08 13:13 ` Laxman Dewangan
2016-01-07 14:38 ` [PATCH 6/6] regulator: max77620: add regulator driver for max77620/max20024 Laxman Dewangan
2016-01-07 14:38 ` Laxman Dewangan
2016-01-07 14:38 ` [rtc-linux] " Laxman Dewangan
2016-01-10 12:40 ` Mark Brown
2016-01-10 12:40 ` [rtc-linux] " Mark Brown
[not found] ` <20160110124014.GZ6588-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-01-11 10:16 ` Laxman Dewangan
2016-01-11 10:16 ` Laxman Dewangan
2016-01-11 10:16 ` [rtc-linux] " Laxman Dewangan
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=568FB62C.9020109@samsung.com \
--to=k.kozlowski@samsung.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@free-electrons.com \
--cc=bandik@nvidia.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=gnurou@gmail.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=k.kozlowski.k@gmail.com \
--cc=ldewangan@nvidia.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mkasoju@nvidia.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=rtc-linux@googlegroups.com \
--cc=swarren@nvidia.com \
--cc=treding@nvidia.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.