linux-kernel - Re: [RFC] clk: add flags to distinguish xtal clocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 5 Jul 2013 01:37:45 +0300
From:	Luciano Coelho <coelho@...com>
To:	Mike Turquette <mturquette@...aro.org>
CC:	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <balbi@...com>
Subject: Re: [RFC] clk: add flags to distinguish xtal clocks

On Thu, 2013-07-04 at 15:25 -0700, Mike Turquette wrote:
> Quoting Luciano Coelho (2013-07-04 14:05:12)
> > Add a flag that indicate whether the clock is a crystal or not.  Since
> > no clocks set this flag right now, include an additional flag that
> > indicates whether the type is set or not.  If the CLK_IS_TYPE_DEFINED
> > flag is not set, the value of the CLK_IS_TYPE_XTAL flag is undefined.
> > This ensures backwards compatibility.
> > 
> > Additionally, parse a new device tree binding in clk-fixed-rate to set
> > this flag.
> > 
> > Signed-off-by: Luciano Coelho <coelho@...com>
> > ---
> > 
> > I'm not  familiar with the common clock framework and I'm not
> > entirely sure the flags can be used in such a way, but to me it looks
> > reasonable, since some clock consumers may need to know what type of
> > clock is being provided.
> > 
> > Specifically, the wl12xx firmware needs to know if the clock is XTAL
> > or not to handle the stabilization and boosts properly.
> 
> Hi Luciano,

Hi Mike,

> I'd like clarification on one point. Is the same clock input signal used
> on the wifi chip? What I mean is, are there multiple clock inputs and
> XTAL is one, and not-XTAL is another?

This wifi chip can work with a few different clocks and some of them are
XTAL and others are not.  What the chip's firmware can use is one of
these:

19.2MHz (not XTAL)
26.0MHz (not XTAL)
26.0MHz (XTAL)
38.4MHz (not XTAL)
38.4MHz (XTAL)
52.0MHz (not XTAL)

It treats the XTAL clocks differently (but I don't really understand
enough of the details), so the driver needs to configure the firmware
according to these values.


> Or is it the same clock input and basically the problem is that you need
> to know what kind of waveform to expect (e.g. square versus sine)?

It's the same clock input in the chip's perspective.  One clock input
that can be any of the combinations I mentioned above.  Again, I'm not
familiar with clocks, so I guess the square vs. sine explanation is
plausible.  What I could see in the firmware is that it handles the
clocks differently if they're xtal or not.

--
Luca.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/