All of lore.kernel.org
 help / color / mirror / Atom feed
From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/5] net: macb updates
Date: Thu, 12 Dec 2013 15:28:43 +0100	[thread overview]
Message-ID: <52A9C81B.7050007@atmel.com> (raw)
In-Reply-To: <CAOesGMjcmeiBfc=EOvWazebg-9vnMuQtRC0aeHJy7Q=02RdRPA@mail.gmail.com>

On 12/12/2013 08:00, Olof Johansson :
> Hi Soren,
>
> On Tue, Dec 10, 2013 at 4:07 PM, Soren Brinkmann
> <soren.brinkmann@xilinx.com> wrote:
>
>> Soren Brinkmann (5):
>>    net: macb: Adjust tx_clk when link speed changes
>
> This patch causes build issues on some at91 platforms, namely
> at91sam9263 that lacks programmable clocks. So it doesn't implement
> clk_set_rate() and clk_round_rate().
>
> I don't know if there's any reasonable config option to check for
> (that wouldn't add at91-specific stuff to the driver which we don't
> want). So I suspect the best way would be to implement dummy versions
> for at91 when CONFIG_AT91_PROGRAMMABLE_CLOCKS isn't set.
>
> Nicolas, you OK with that? It'd be something like the below
> (copy-paste, whitespace damage, just RFC):

Well, in fact I am thinking about simply removing this 
AT91_PROGRAMMABLE_CLOCKS option out of the AT91 Kconfig.

After all, when not specified, it only removes a few lines of code... 
and that's it! For a so little benefit, I suspect it is sensible to 
remove this option.
I continue to discuss with AT91 active developers and write a patch soon.

Thanks for the heads-up on this issue Olof.

Bye,


> diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
> index 6b2630a..17c52a7 100644
> --- a/arch/arm/mach-at91/clock.c
> +++ b/arch/arm/mach-at91/clock.c
> @@ -459,6 +459,22 @@ static void __init init_programmable_clock(struct clk *clk)
>          clk->rate_hz = parent->rate_hz / pmc_prescaler_divider(pckr);
>   }
>
> +#else  /* CONFIG_AT91_PROGRAMMABLE_CLOCKS */
> +
> +int clk_set_rate(struct clk *clk, unsigned long rate)
> +{
> +       if (rate == clk_get_rate(clk))
> +               return 0;
> +
> +       return -EINVAL;
> +}
> +
> +long clk_round_rate(struct clk *clk, unsigned long rate)
> +{
> +       /* There's really nothing sane to return here. */
> +       return clk_get_rate(clk);
> +}
> +
>   #endif /* CONFIG_AT91_PROGRAMMABLE_CLOCKS */
>


-- 
Nicolas Ferre

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Olof Johansson <olof@lixom.net>,
	Soren Brinkmann <soren.brinkmann@xilinx.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	boris brezillon <b.brezillon@overkiz.com>
Cc: David Miller <davem@davemloft.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	Michal Simek <michal.simek@xilinx.com>
Subject: Re: [PATCH v2 0/5] net: macb updates
Date: Thu, 12 Dec 2013 15:28:43 +0100	[thread overview]
Message-ID: <52A9C81B.7050007@atmel.com> (raw)
In-Reply-To: <CAOesGMjcmeiBfc=EOvWazebg-9vnMuQtRC0aeHJy7Q=02RdRPA@mail.gmail.com>

On 12/12/2013 08:00, Olof Johansson :
> Hi Soren,
>
> On Tue, Dec 10, 2013 at 4:07 PM, Soren Brinkmann
> <soren.brinkmann@xilinx.com> wrote:
>
>> Soren Brinkmann (5):
>>    net: macb: Adjust tx_clk when link speed changes
>
> This patch causes build issues on some at91 platforms, namely
> at91sam9263 that lacks programmable clocks. So it doesn't implement
> clk_set_rate() and clk_round_rate().
>
> I don't know if there's any reasonable config option to check for
> (that wouldn't add at91-specific stuff to the driver which we don't
> want). So I suspect the best way would be to implement dummy versions
> for at91 when CONFIG_AT91_PROGRAMMABLE_CLOCKS isn't set.
>
> Nicolas, you OK with that? It'd be something like the below
> (copy-paste, whitespace damage, just RFC):

Well, in fact I am thinking about simply removing this 
AT91_PROGRAMMABLE_CLOCKS option out of the AT91 Kconfig.

After all, when not specified, it only removes a few lines of code... 
and that's it! For a so little benefit, I suspect it is sensible to 
remove this option.
I continue to discuss with AT91 active developers and write a patch soon.

Thanks for the heads-up on this issue Olof.

Bye,


> diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
> index 6b2630a..17c52a7 100644
> --- a/arch/arm/mach-at91/clock.c
> +++ b/arch/arm/mach-at91/clock.c
> @@ -459,6 +459,22 @@ static void __init init_programmable_clock(struct clk *clk)
>          clk->rate_hz = parent->rate_hz / pmc_prescaler_divider(pckr);
>   }
>
> +#else  /* CONFIG_AT91_PROGRAMMABLE_CLOCKS */
> +
> +int clk_set_rate(struct clk *clk, unsigned long rate)
> +{
> +       if (rate == clk_get_rate(clk))
> +               return 0;
> +
> +       return -EINVAL;
> +}
> +
> +long clk_round_rate(struct clk *clk, unsigned long rate)
> +{
> +       /* There's really nothing sane to return here. */
> +       return clk_get_rate(clk);
> +}
> +
>   #endif /* CONFIG_AT91_PROGRAMMABLE_CLOCKS */
>


-- 
Nicolas Ferre

  reply	other threads:[~2013-12-12 14:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-11  0:07 [PATCH v2 0/5] net: macb updates Soren Brinkmann
2013-12-11  0:07 ` [PATCH v2 1/5] net: macb: Migrate to dev_pm_ops Soren Brinkmann
2013-12-11  0:07 ` [PATCH v2 2/5] net: macb: Migrate to devm clock interface Soren Brinkmann
2013-12-11  0:07 ` [PATCH v2 3/5] net: macb: Use devm_ioremap() Soren Brinkmann
2013-12-11  0:07 ` [PATCH v2 4/5] net: macb: Use devm_request_irq() Soren Brinkmann
2013-12-11  0:07 ` [PATCH v2 5/5] net: macb: Adjust tx_clk when link speed changes Soren Brinkmann
2013-12-11  3:57 ` [PATCH v2 0/5] net: macb updates David Miller
2013-12-12  7:00 ` Olof Johansson
2013-12-12 14:28   ` Nicolas Ferre [this message]
2013-12-12 14:28     ` Nicolas Ferre
2013-12-12 16:00     ` [PATCH] ARM: at91: remove AT91_PROGRAMMABLE_CLOCKS configuration option Nicolas Ferre
2013-12-12 16:00       ` Nicolas Ferre
2013-12-12 18:38       ` Kevin Hilman
2013-12-12 18:38         ` Kevin Hilman
2013-12-13 15:18       ` Jean-Christophe PLAGNIOL-VILLARD
2013-12-13 15:18         ` Jean-Christophe PLAGNIOL-VILLARD

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=52A9C81B.7050007@atmel.com \
    --to=nicolas.ferre@atmel.com \
    --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 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.