| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Use updated printk format for OF node names
- Fix TI code to only search DT subnodes
- Various static analysis finds
* clk-dt-name:
clk: Convert to using %pOFn instead of device_node.name
* clk-ti-of-node:
clk: ti: fix OF child-node lookup
* clk-sa:
clk: mvebu: armada-37xx-tbg: Switch to clk_get and balance it in probe
reset: hisilicon: fix potential NULL pointer dereference
clk: cdce925: release child device nodes
clk: qcom: clk-branch: Use true and false for boolean values
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
of_get_child_by_name() returns device node with refcount incremented,
but there is no decrement in cdce925_probe(). The patch adds one.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
The check for a non-null parent_name is always true as there is an
earlier check for a null parent_name that returns -ENODEV. Remove this
redundant check and always set init.num_parents to 1.
Detected by CoverityScan CID#1309477 ("Logically dead code")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CDCE925 is a member of the CDCE(L)9xx programmable clock generator
family. There are also CDCE913, CDCE937, CDCE949 which have different
number of PLLs and outputs.
The clk-cdce925 driver supports only CDCE925 in the family. This adds
support for the CDCE913, CDCE937, CDCE949, too.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Cc: Mike Looijmans <mike.looijmans@topic.nl>
Cc: Michael Turquette <mturquette@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It is likely that instead of '1>64', 'q>64' was expected.
Moreover, according to datasheet,
http://www.ti.com/lit/ds/symlink/cdce925.pdf
SCAS847I - JULY 2007 - REVISED OCTOBER 2016
PLL settings limits are: 16 <= q <= 63
So change the upper limit check from 64 to 63.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Now that we have clk_hw based provider APIs to register clks, we
can get rid of struct clk pointers while registering clks in
these drivers, allowing us to move closer to a clear split of
consumer and provider clk APIs.
Cc: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
| |
|
|
|
|
|
|
| |
This clock provider uses the consumer API, so include clk.h
explicitly.
Cc: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
| |
|
|
|
|
|
|
|
| |
drivers/clk/clk-cdce925.c:550: warning: format ‘%u’ expects type
‘unsigned int’, but argument 6 has type ‘size_t’
Cc: Mike Looijmans <mike.looijmans@topic.nl>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
|
|
This driver supports the TI CDCE925 programmable clock synthesizer.
The chip contains two PLLs with spread-spectrum clocking support and
five output dividers. The driver only supports the following setup,
and uses a fixed setting for the output muxes:
Y1 is derived from the input clock
Y2 and Y3 derive from PLL1
Y4 and Y5 derive from PLL2
Given a target output frequency, the driver will set the PLL and
divider to best approximate the desired output.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
|
