All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <rob.herring@calxeda.com>,
	Rob Landley <rob@landley.net>,
	Mike Turquette <mturquette@linaro.org>,
	Stephen Warren <swarren@nvidia.com>,
	Thierry Reding <thierry.reding@avionic-design.de>,
	Dom Cobley <popcornmix@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Pawel Moll <pawel.moll@arm.com>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Rabeeh Khoury <rabeeh@solid-run.com>,
	Daniel Mack <zonque@gmail.com>,
	Jean-Francois Moine <moinejf@free.fr>,
	Lars-Peter Clausen <lars@metafoo.de>,
	devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [v5] clk: add si5351 i2c common clock driver
Date: Mon, 8 Apr 2013 07:54:07 -0700	[thread overview]
Message-ID: <20130408145407.GA12243@roeck-us.net> (raw)
In-Reply-To: <51625F9A.1050308@gmail.com>

On Mon, Apr 08, 2013 at 08:11:38AM +0200, Sebastian Hesselbarth wrote:
> On 04/08/2013 02:17 AM, Guenter Roeck wrote:
> >On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
> >>On 04/08/2013 12:50 AM, Guenter Roeck wrote:
> >>>On Fri, Apr 05, 2013 at 05:23:35AM -0000, Sebastian Hesselbarth wrote:
> >>>>This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> >>>>i2c programmable clock generators. Currently, the driver supports
> >>>>DT kernels only and VXCO feature of si5351b is not implemented. DT
> >>>>bindings selectively allow to overwrite stored Si5351 configuration
> >>>>which is very helpful for clock generators with empty eeprom
> >>>>configuration. Corresponding device tree binding documentation is
> >>>>also added.
> >>>>
> >>>>Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth@gmail.com>
> >>>>Tested-by: Daniel Mack<zonque@gmail.com>
> >>>>
> >>>[ ... ]
> >>>
> >>>>+static inline void _si5351_msynth_set_pll_master(
> >>>>+	struct si5351_driver_data *drvdata, unsigned char num, int is_master)
> >>>>+{
> >>>>+	unsigned long flags;
> >>>>+
> >>>>+	if (num>   8 ||
> >>>>+	    (drvdata->variant == SI5351_VARIANT_A3&&   num>   3))
> >>>>+		return;
> >>>>+
> >>>>+	flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
> >>>>+	if (is_master)
> >>>>+		flags |= CLK_SET_RATE_PARENT;
> >>>>+	else
> >>>>+		flags&= ~CLK_SET_RATE_PARENT;
> >>>>+	__clk_set_flags(drvdata->msynth[num].hw.clk, flags);
> >>>>+}
> >>>>+
> >>>Unless I am missing something, neither __clk_get_flags() nor the new
> >>>__clk_set_flags is exported.
> >>>
> >>>Did you try to build and load the driver as module ?
> >>
> >>Well, good catch. I didn't try to build v5 as a module, but I guess it
> >>will fail. But I consider this as something that has to be addressed in
> >>clk framework itself, not in this patch. There will be other
> >>clk-providers built as module in the future for sure.
> >>
> >Sure, but you provided the patch to make __clk_set_flags global. To avoid
> >build failures, I would suggest to either submit a patch to export the
> >missing functions, or to remove the ability to build the driver as module.
> 
> Actually, I knew that __clk_set_flags patch will not be accepted
> before posting it ;)
> 
Ah, but part of that is to get you to think about it again, and to defend it if
it is really needed. After all, "it can be abused" applies to pretty much every
API.

Key question is if you _really_ need run-time flag modifications, or if you can
live with initialization-time settings. If you really need it, you'll have to
explain the reasons.

> >On a side note, do you happen to know anyone working on drivers for Si5319 or
> >Si5368 ?
> 
> No.

Too bad ... I may have to write that code myself then.

Thanks,
Guenter

WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
To: Sebastian Hesselbarth
	<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Jean-Francois Moine <moinejf-GANU6spQydw@public.gmane.org>,
	Mark Brown
	<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>,
	Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	Russell King - ARM Linux
	<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Dom Cobley <popcornmix-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Mike Turquette
	<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>,
	Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [v5] clk: add si5351 i2c common clock driver
Date: Mon, 8 Apr 2013 07:54:07 -0700	[thread overview]
Message-ID: <20130408145407.GA12243@roeck-us.net> (raw)
In-Reply-To: <51625F9A.1050308-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Mon, Apr 08, 2013 at 08:11:38AM +0200, Sebastian Hesselbarth wrote:
> On 04/08/2013 02:17 AM, Guenter Roeck wrote:
> >On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
> >>On 04/08/2013 12:50 AM, Guenter Roeck wrote:
> >>>On Fri, Apr 05, 2013 at 05:23:35AM -0000, Sebastian Hesselbarth wrote:
> >>>>This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> >>>>i2c programmable clock generators. Currently, the driver supports
> >>>>DT kernels only and VXCO feature of si5351b is not implemented. DT
> >>>>bindings selectively allow to overwrite stored Si5351 configuration
> >>>>which is very helpful for clock generators with empty eeprom
> >>>>configuration. Corresponding device tree binding documentation is
> >>>>also added.
> >>>>
> >>>>Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>>>Tested-by: Daniel Mack<zonque-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>>>
> >>>[ ... ]
> >>>
> >>>>+static inline void _si5351_msynth_set_pll_master(
> >>>>+	struct si5351_driver_data *drvdata, unsigned char num, int is_master)
> >>>>+{
> >>>>+	unsigned long flags;
> >>>>+
> >>>>+	if (num>   8 ||
> >>>>+	    (drvdata->variant == SI5351_VARIANT_A3&&   num>   3))
> >>>>+		return;
> >>>>+
> >>>>+	flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
> >>>>+	if (is_master)
> >>>>+		flags |= CLK_SET_RATE_PARENT;
> >>>>+	else
> >>>>+		flags&= ~CLK_SET_RATE_PARENT;
> >>>>+	__clk_set_flags(drvdata->msynth[num].hw.clk, flags);
> >>>>+}
> >>>>+
> >>>Unless I am missing something, neither __clk_get_flags() nor the new
> >>>__clk_set_flags is exported.
> >>>
> >>>Did you try to build and load the driver as module ?
> >>
> >>Well, good catch. I didn't try to build v5 as a module, but I guess it
> >>will fail. But I consider this as something that has to be addressed in
> >>clk framework itself, not in this patch. There will be other
> >>clk-providers built as module in the future for sure.
> >>
> >Sure, but you provided the patch to make __clk_set_flags global. To avoid
> >build failures, I would suggest to either submit a patch to export the
> >missing functions, or to remove the ability to build the driver as module.
> 
> Actually, I knew that __clk_set_flags patch will not be accepted
> before posting it ;)
> 
Ah, but part of that is to get you to think about it again, and to defend it if
it is really needed. After all, "it can be abused" applies to pretty much every
API.

Key question is if you _really_ need run-time flag modifications, or if you can
live with initialization-time settings. If you really need it, you'll have to
explain the reasons.

> >On a side note, do you happen to know anyone working on drivers for Si5319 or
> >Si5368 ?
> 
> No.

Too bad ... I may have to write that code myself then.

Thanks,
Guenter

WARNING: multiple messages have this Message-ID (diff)
From: linux@roeck-us.net (Guenter Roeck)
To: linux-arm-kernel@lists.infradead.org
Subject: [v5] clk: add si5351 i2c common clock driver
Date: Mon, 8 Apr 2013 07:54:07 -0700	[thread overview]
Message-ID: <20130408145407.GA12243@roeck-us.net> (raw)
In-Reply-To: <51625F9A.1050308@gmail.com>

On Mon, Apr 08, 2013 at 08:11:38AM +0200, Sebastian Hesselbarth wrote:
> On 04/08/2013 02:17 AM, Guenter Roeck wrote:
> >On Mon, Apr 08, 2013 at 01:49:24AM +0200, Sebastian Hesselbarth wrote:
> >>On 04/08/2013 12:50 AM, Guenter Roeck wrote:
> >>>On Fri, Apr 05, 2013 at 05:23:35AM -0000, Sebastian Hesselbarth wrote:
> >>>>This patch adds a common clock driver for Silicon Labs Si5351a/b/c
> >>>>i2c programmable clock generators. Currently, the driver supports
> >>>>DT kernels only and VXCO feature of si5351b is not implemented. DT
> >>>>bindings selectively allow to overwrite stored Si5351 configuration
> >>>>which is very helpful for clock generators with empty eeprom
> >>>>configuration. Corresponding device tree binding documentation is
> >>>>also added.
> >>>>
> >>>>Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth@gmail.com>
> >>>>Tested-by: Daniel Mack<zonque@gmail.com>
> >>>>
> >>>[ ... ]
> >>>
> >>>>+static inline void _si5351_msynth_set_pll_master(
> >>>>+	struct si5351_driver_data *drvdata, unsigned char num, int is_master)
> >>>>+{
> >>>>+	unsigned long flags;
> >>>>+
> >>>>+	if (num>   8 ||
> >>>>+	    (drvdata->variant == SI5351_VARIANT_A3&&   num>   3))
> >>>>+		return;
> >>>>+
> >>>>+	flags = __clk_get_flags(drvdata->msynth[num].hw.clk);
> >>>>+	if (is_master)
> >>>>+		flags |= CLK_SET_RATE_PARENT;
> >>>>+	else
> >>>>+		flags&= ~CLK_SET_RATE_PARENT;
> >>>>+	__clk_set_flags(drvdata->msynth[num].hw.clk, flags);
> >>>>+}
> >>>>+
> >>>Unless I am missing something, neither __clk_get_flags() nor the new
> >>>__clk_set_flags is exported.
> >>>
> >>>Did you try to build and load the driver as module ?
> >>
> >>Well, good catch. I didn't try to build v5 as a module, but I guess it
> >>will fail. But I consider this as something that has to be addressed in
> >>clk framework itself, not in this patch. There will be other
> >>clk-providers built as module in the future for sure.
> >>
> >Sure, but you provided the patch to make __clk_set_flags global. To avoid
> >build failures, I would suggest to either submit a patch to export the
> >missing functions, or to remove the ability to build the driver as module.
> 
> Actually, I knew that __clk_set_flags patch will not be accepted
> before posting it ;)
> 
Ah, but part of that is to get you to think about it again, and to defend it if
it is really needed. After all, "it can be abused" applies to pretty much every
API.

Key question is if you _really_ need run-time flag modifications, or if you can
live with initialization-time settings. If you really need it, you'll have to
explain the reasons.

> >On a side note, do you happen to know anyone working on drivers for Si5319 or
> >Si5368 ?
> 
> No.

Too bad ... I may have to write that code myself then.

Thanks,
Guenter

  reply	other threads:[~2013-04-08 14:54 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-09 12:59 [PATCH] clk: add si5351 i2c common clock driver Sebastian Hesselbarth
2013-02-09 12:59 ` Sebastian Hesselbarth
2013-02-11  5:46 ` Mike Turquette
2013-02-11  5:46   ` Mike Turquette
2013-02-11  5:46   ` Mike Turquette
2013-02-11  9:52   ` Sebastian Hesselbarth
2013-02-11  9:52     ` Sebastian Hesselbarth
2013-02-18 10:19 ` Daniel Mack
2013-02-18 10:19   ` Daniel Mack
2013-02-19 19:15 ` Daniel Mack
2013-02-19 19:15   ` Daniel Mack
2013-02-19 19:15   ` Daniel Mack
2013-02-27 10:01   ` Sebastian Hesselbarth
2013-02-27 10:01     ` Sebastian Hesselbarth
2013-03-01 15:01     ` Daniel Mack
2013-03-01 15:01       ` Daniel Mack
2013-03-16 13:10 ` [PATCH v2] " Sebastian Hesselbarth
2013-03-16 13:10   ` Sebastian Hesselbarth
2013-03-16 15:10   ` Daniel Mack
2013-03-16 15:10     ` Daniel Mack
2013-03-18 10:43 ` [PATCH v3] " Sebastian Hesselbarth
2013-03-18 10:43   ` Sebastian Hesselbarth
2013-03-18 11:37   ` Daniel Mack
2013-03-18 11:37     ` Daniel Mack
2013-03-20  0:26   ` Mike Turquette
2013-03-20  0:26     ` Mike Turquette
2013-03-20  0:26     ` Mike Turquette
2013-03-20  8:20     ` Sebastian Hesselbarth
2013-03-20  8:20       ` Sebastian Hesselbarth
2013-03-21 18:09   ` Lars-Peter Clausen
2013-03-21 18:09     ` Lars-Peter Clausen
2013-03-21 21:32     ` Sebastian Hesselbarth
2013-03-21 21:32       ` Sebastian Hesselbarth
2013-03-23 10:07       ` Lars-Peter Clausen
2013-03-23 10:07         ` Lars-Peter Clausen
2013-03-23 14:46   ` [PATCH v4] " Sebastian Hesselbarth
2013-03-23 14:46     ` Sebastian Hesselbarth
2013-03-23 14:46     ` Sebastian Hesselbarth
2013-04-02 23:46     ` Mike Turquette
2013-04-02 23:46       ` Mike Turquette
2013-04-02 23:46       ` Mike Turquette
2013-04-03 11:10       ` Sebastian Hesselbarth
2013-04-03 11:10         ` Sebastian Hesselbarth
2013-04-05  5:23     ` [PATCH v5] " Sebastian Hesselbarth
2013-04-05  5:23       ` Sebastian Hesselbarth
2013-04-07 22:50       ` [v5] " Guenter Roeck
2013-04-07 22:50         ` Guenter Roeck
2013-04-07 23:49         ` Sebastian Hesselbarth
2013-04-07 23:49           ` Sebastian Hesselbarth
2013-04-08  0:17           ` Guenter Roeck
2013-04-08  0:17             ` Guenter Roeck
2013-04-08  6:11             ` Sebastian Hesselbarth
2013-04-08  6:11               ` Sebastian Hesselbarth
2013-04-08 14:54               ` Guenter Roeck [this message]
2013-04-08 14:54                 ` Guenter Roeck
2013-04-08 14:54                 ` Guenter Roeck
2013-04-08 15:38                 ` Sebastian Hesselbarth
2013-04-08 15:38                   ` Sebastian Hesselbarth
2013-04-08 15:38                   ` Sebastian Hesselbarth
2013-04-08 17:36                   ` Mike Turquette
2013-04-08 17:36                     ` Mike Turquette
2013-04-08 18:32                     ` Sebastian Hesselbarth
2013-04-08 18:32                       ` Sebastian Hesselbarth
2013-04-08 16:46       ` [PATCH v6] " Sebastian Hesselbarth
2013-04-08 16:46         ` Sebastian Hesselbarth
2013-04-08 17:46         ` Guenter Roeck
2013-04-08 17:46           ` Guenter Roeck
2013-04-08 18:24           ` Sebastian Hesselbarth
2013-04-08 18:24             ` Sebastian Hesselbarth
2013-04-10  9:40         ` [PATCH v7] " Sebastian Hesselbarth
2013-04-10  9:40           ` Sebastian Hesselbarth
2013-04-10  9:40           ` Sebastian Hesselbarth
2013-04-10 10:17           ` Daniel Mack
2013-04-10 10:17             ` Daniel Mack
2013-04-10 14:48             ` Michal Bachraty
2013-04-10 14:48               ` Michal Bachraty
2013-04-10 16:34               ` Sebastian Hesselbarth
2013-04-10 17:27               ` Sebastian Hesselbarth
2013-04-10 17:27                 ` Sebastian Hesselbarth
2013-04-10 17:27                 ` Sebastian Hesselbarth
2013-04-11  7:44                 ` Michal Bachraty
2013-04-11  7:44                   ` Michal Bachraty
2013-04-11  8:22                   ` Sebastian Hesselbarth
2013-04-11  8:22                     ` Sebastian Hesselbarth
2013-04-10 19:34           ` Guenter Roeck
2013-04-10 19:34             ` Guenter Roeck
2013-04-11 19:42           ` [PATCH v8] " Sebastian Hesselbarth
2013-04-11 19:42             ` Sebastian Hesselbarth
2013-04-11 19:42             ` Sebastian Hesselbarth
2013-04-12 11:43             ` Michal Bachraty
2013-04-12 11:43               ` Michal Bachraty
2013-04-12 11:43               ` Michal Bachraty
2013-04-12 18:19             ` Mike Turquette
2013-04-12 18:19               ` Mike Turquette
2013-04-12 18:19               ` Mike Turquette

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=20130408145407.GA12243@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=lars@metafoo.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=moinejf@free.fr \
    --cc=mturquette@linaro.org \
    --cc=pawel.moll@arm.com \
    --cc=popcornmix@gmail.com \
    --cc=rabeeh@solid-run.com \
    --cc=rob.herring@calxeda.com \
    --cc=rob@landley.net \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=swarren@nvidia.com \
    --cc=thierry.reding@avionic-design.de \
    --cc=zonque@gmail.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.