All of lore.kernel.org
 help / color / mirror / Atom feed
From: t-kristo@ti.com (Tero Kristo)
To: linux-arm-kernel@lists.infradead.org
Subject: Bug in clk_mux_set_parent for CLK_MUX_INDEX_BIT muxes ?
Date: Tue, 18 Nov 2014 14:30:34 +0200	[thread overview]
Message-ID: <546B3BEA.90002@ti.com> (raw)
In-Reply-To: <20141117185709.25314.61477@quantum>

On 11/17/2014 08:57 PM, Mike Turquette wrote:
> Quoting Hans de Goede (2014-11-16 04:34:46)
>> Hi,
>>
>> While looking at what I believe is a bug in the sunxi gmac clk code
>> (more on that later), I believe I've also found a bug in
>>
>> clk_mux_set_parent for the CLK_MUX_INDEX_BIT case.
>>
>> AFAIK if CLK_MUX_INDEX_BIT is set, then each bit turns
>> on / off a single parent, so theoretically multiple
>> parents could be enabled at the same time, but in practice
>> only one bit should ever be 1. So to select parent 0, set
>> the register (*) to 0x01, to select parent 1 set it 0x02,
>> parent 2, 0x04, parent 3, 0x08, etc.
>>
>> Correct ?
>>
>> Assuming I got that right, then this bit of code in
>> clk_mux_set_parent is wrong:
>>
>>                  if (mux->flags & CLK_MUX_INDEX_BIT)
>>                          index = (1 << ffs(index));
>>
>> For an input index of 0, ffs returns 0, so we set the register
>> to 0x01, ok.
>>
>> For an input index of 1, ffs returns 1, so we set the register
>> to 0x02, ok.
>>
>> For an input index of 2, ffs returns 2, so we set the register
>> to 0x04, ok.
>>
>> For an input index of 3, ffs returns 1, so we set the register
>> to 0x02, not good!
>>
>> I believe this code should simply be:
>>
>>                  if (mux->flags & CLK_MUX_INDEX_BIT)
>>                          index = 1 << index;
>>
>> I guess we've been getting away by this because the input index
>> so far has never gotten above 2.
>
> Good catch. I've Cc'd Tero Kristo from TI as the TI SoCs are the only
> other user of CLK_MUX_INDEX_BIT.
>
>>
>> If I'm right about this, I can whip up a patch to fix this. Note
>> I don't really have hardware to properly exercise this code-path
>> AFAIK.
>
> Please do. I think your change is reasonable and Tero can scream if
> something breaks for him.

TI SoC:s use a copy pasted version of the mux clock (with some 
additional tweaks), but we never set the CLK_MUX_INDEX_BIT flag, so we 
have been safe from this bug. Feel free to send a patch against the TI 
clock driver also if you want, I can ack that one. If not, I can craft a 
quick patch for this myself.

-Tero

  parent reply	other threads:[~2014-11-18 12:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-16 12:34 Bug in clk_mux_set_parent for CLK_MUX_INDEX_BIT muxes ? Hans de Goede
     [not found] ` <20141117185709.25314.61477@quantum>
2014-11-18 12:30   ` Tero Kristo [this message]
2014-11-19 13:49     ` Hans de Goede
2014-11-19 14:24       ` Tero Kristo

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=546B3BEA.90002@ti.com \
    --to=t-kristo@ti.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.