This is a note to let you know that I've just added the patch titled
GFS2: Take inode off order_write list when setting jdata flag
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Bob Peterson <rpeterso(a)redhat.com>
Date: Wed, 20 Sep 2017 08:30:04 -0500
Subject: GFS2: Take inode off order_write list when setting jdata flag
From: Bob Peterson <rpeterso(a)redhat.com>
[ Upstream commit cc555b09d8c3817aeebda43a14ab67049a5653f7 ]
This patch fixes a deadlock caused when the jdata flag is set for
inodes that are already on the ordered write list. Since it is
on the ordered write list, log_flush calls gfs2_ordered_write which
calls filemap_fdatawrite. But since the inode had the jdata flag
set, that calls gfs2_jdata_writepages, which tries to start a new
transaction. A new transaction cannot be started because it tries
to acquire the log_flush rwsem which is already locked by the log
flush operation.
The bottom line is: We cannot switch an inode from ordered to jdata
until we eliminate any ordered data pages (via log flush) or any
log_flush operation afterward will create the circular dependency
above. So we need to flush the log before setting the diskflags to
switch the file mode, then we need to remove the inode from the
ordered writes list.
Before this patch, the log flush was done for jdata->ordered, but
that's wrong. If we're going from jdata to ordered, we don't need
to call gfs2_log_flush because the call to filemap_fdatawrite will
do it for us:
filemap_fdatawrite() -> __filemap_fdatawrite_range()
__filemap_fdatawrite_range() -> do_writepages()
do_writepages() -> gfs2_jdata_writepages()
gfs2_jdata_writepages() -> gfs2_log_flush()
This patch modifies function do_gfs2_set_flags so that if a file
has its jdata flag set, and it's already on the ordered write list,
the log will be flushed and it will be removed from the list
before setting the flag.
Signed-off-by: Bob Peterson <rpeterso(a)redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com>
Acked-by: Abhijith Das <adas(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/gfs2/file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -256,7 +256,7 @@ static int do_gfs2_set_flags(struct file
goto out;
}
if ((flags ^ new_flags) & GFS2_DIF_JDATA) {
- if (flags & GFS2_DIF_JDATA)
+ if (new_flags & GFS2_DIF_JDATA)
gfs2_log_flush(sdp, ip->i_gl, NORMAL_FLUSH);
error = filemap_fdatawrite(inode->i_mapping);
if (error)
@@ -264,6 +264,8 @@ static int do_gfs2_set_flags(struct file
error = filemap_fdatawait(inode->i_mapping);
if (error)
goto out;
+ if (new_flags & GFS2_DIF_JDATA)
+ gfs2_ordered_del_inode(ip);
}
error = gfs2_trans_begin(sdp, RES_DINODE, 0);
if (error)
Patches currently in stable-queue which might be from rpeterso(a)redhat.com are
queue-4.14/gfs2-take-inode-off-order_write-list-when-setting-jdata-flag.patch
This is a note to let you know that I've just added the patch titled
fbdev: controlfb: Add missing modes to fix out of bounds access
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Thu, 9 Nov 2017 18:09:33 +0100
Subject: fbdev: controlfb: Add missing modes to fix out of bounds access
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
[ Upstream commit ac831a379d34109451b3c41a44a20ee10ecb615f ]
Dan's static analysis says:
drivers/video/fbdev/controlfb.c:560 control_setup()
error: buffer overflow 'control_mac_modes' 20 <= 21
Indeed, control_mac_modes[] has only 20 elements, while VMODE_MAX is 22,
which may lead to an out of bounds read when parsing vmode commandline
options.
The bug was introduced in v2.4.5.6, when 2 new modes were added to
macmodes.h, but control_mac_modes[] wasn't updated:
https://kernel.opensuse.org/cgit/kernel/diff/include/video/macmodes.h?h=v2.…
Augment control_mac_modes[] with the two new video modes to fix this.
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Cc: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: Benjamin Herrenschmidt <benh(a)kernel.crashing.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/controlfb.h | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/video/fbdev/controlfb.h
+++ b/drivers/video/fbdev/controlfb.h
@@ -141,5 +141,7 @@ static struct max_cmodes control_mac_mod
{{ 1, 2}}, /* 1152x870, 75Hz */
{{ 0, 1}}, /* 1280x960, 75Hz */
{{ 0, 1}}, /* 1280x1024, 75Hz */
+ {{ 1, 2}}, /* 1152x768, 60Hz */
+ {{ 0, 1}}, /* 1600x1024, 60Hz */
};
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.14/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch
queue-4.14/mtd-spi-nor-stm32-quadspi-fix-uninitialized-error-return-code.patch
This is a note to let you know that I've just added the patch titled
drm/amdgpu: bypass lru touch for KIQ ring submission
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-amdgpu-bypass-lru-touch-for-kiq-ring-submission.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Pixel Ding <Pixel.Ding(a)amd.com>
Date: Wed, 8 Nov 2017 10:20:01 +0800
Subject: drm/amdgpu: bypass lru touch for KIQ ring submission
From: Pixel Ding <Pixel.Ding(a)amd.com>
[ Upstream commit dce1e131dd4dc68099ff1b70aa03cd2d0acf8639 ]
KIQ ring submission is used for register accessing on SRIOV
VF that could happen both in irq enabled and irq disabled cases.
Inversion lock could happen on adev->ring_lru_list_lock, while
this operation is useless and just adds overhead in this use
case.
Signed-off-by: Pixel Ding <Pixel.Ding(a)amd.com>
Reviewed-by: Monk Liu <Monk.Liu(a)amd.com>
Reviewed-by: Christian König <christian.koenig(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
@@ -136,7 +136,8 @@ void amdgpu_ring_commit(struct amdgpu_ri
if (ring->funcs->end_use)
ring->funcs->end_use(ring);
- amdgpu_ring_lru_touch(ring->adev, ring);
+ if (ring->funcs->type != AMDGPU_RING_TYPE_KIQ)
+ amdgpu_ring_lru_touch(ring->adev, ring);
}
/**
Patches currently in stable-queue which might be from Pixel.Ding(a)amd.com are
queue-4.14/drm-amdgpu-bypass-lru-touch-for-kiq-ring-submission.patch
This is a note to let you know that I've just added the patch titled
dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Date: Wed, 8 Nov 2017 12:02:25 +0200
Subject: dmaengine: ti-dma-crossbar: Correct am335x/am43xx mux value type
From: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
[ Upstream commit 288e7560e4d3e259aa28f8f58a8dfe63627a1bf6 ]
The used 0x1f mask is only valid for am335x family of SoC, different family
using this type of crossbar might have different number of electable
events. In case of am43xx family 0x3f mask should have been used for
example.
Instead of trying to handle each family's mask, just use u8 type to store
the mux value since the event offsets are aligned to byte offset.
Fixes: 42dbdcc6bf965 ("dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/ti-dma-crossbar.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -49,12 +49,12 @@ struct ti_am335x_xbar_data {
struct ti_am335x_xbar_map {
u16 dma_line;
- u16 mux_val;
+ u8 mux_val;
};
-static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u16 val)
+static inline void ti_am335x_xbar_write(void __iomem *iomem, int event, u8 val)
{
- writeb_relaxed(val & 0x1f, iomem + event);
+ writeb_relaxed(val, iomem + event);
}
static void ti_am335x_xbar_free(struct device *dev, void *route_data)
@@ -105,7 +105,7 @@ static void *ti_am335x_xbar_route_alloca
}
map->dma_line = (u16)dma_spec->args[0];
- map->mux_val = (u16)dma_spec->args[2];
+ map->mux_val = (u8)dma_spec->args[2];
dma_spec->args[2] = 0;
dma_spec->args_count = 2;
Patches currently in stable-queue which might be from peter.ujfalusi(a)ti.com are
queue-4.14/dmaengine-ti-dma-crossbar-correct-am335x-am43xx-mux-value-type.patch
This is a note to let you know that I've just added the patch titled
dev/dax: fix uninitialized variable build warning
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dev-dax-fix-uninitialized-variable-build-warning.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Date: Wed, 18 Oct 2017 12:21:55 -0600
Subject: dev/dax: fix uninitialized variable build warning
From: Ross Zwisler <ross.zwisler(a)linux.intel.com>
[ Upstream commit 0a3ff78699d1817e711441715d22665475466036 ]
Fix this build warning:
warning: 'phys' may be used uninitialized in this function
[-Wuninitialized]
As reported here:
https://lkml.org/lkml/2017/10/16/152http://kisskb.ellerman.id.au/kisskb/buildresult/13181373/log/
Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dax/device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/dax/device.c
+++ b/drivers/dax/device.c
@@ -222,7 +222,8 @@ __weak phys_addr_t dax_pgoff_to_phys(str
unsigned long size)
{
struct resource *res;
- phys_addr_t phys;
+ /* gcc-4.6.3-nolibc for i386 complains that this is uninitialized */
+ phys_addr_t uninitialized_var(phys);
int i;
for (i = 0; i < dev_dax->num_resources; i++) {
Patches currently in stable-queue which might be from ross.zwisler(a)linux.intel.com are
queue-4.14/dev-dax-fix-uninitialized-variable-build-warning.patch
This is a note to let you know that I've just added the patch titled
crypto: tcrypt - fix buffer lengths in test_aead_speed()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Robert Baronescu <robert.baronescu(a)nxp.com>
Date: Tue, 10 Oct 2017 13:22:00 +0300
Subject: crypto: tcrypt - fix buffer lengths in test_aead_speed()
From: Robert Baronescu <robert.baronescu(a)nxp.com>
[ Upstream commit 7aacbfcb331ceff3ac43096d563a1f93ed46e35e ]
Fix the way the length of the buffers used for
encryption / decryption are computed.
For e.g. in case of encryption, input buffer does not contain
an authentication tag.
Signed-off-by: Robert Baronescu <robert.baronescu(a)nxp.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/tcrypt.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -340,7 +340,7 @@ static void test_aead_speed(const char *
}
sg_init_aead(sg, xbuf,
- *b_size + (enc ? authsize : 0));
+ *b_size + (enc ? 0 : authsize));
sg_init_aead(sgout, xoutbuf,
*b_size + (enc ? authsize : 0));
@@ -348,7 +348,9 @@ static void test_aead_speed(const char *
sg_set_buf(&sg[0], assoc, aad_size);
sg_set_buf(&sgout[0], assoc, aad_size);
- aead_request_set_crypt(req, sg, sgout, *b_size, iv);
+ aead_request_set_crypt(req, sg, sgout,
+ *b_size + (enc ? 0 : authsize),
+ iv);
aead_request_set_ad(req, aad_size);
if (secs)
Patches currently in stable-queue which might be from robert.baronescu(a)nxp.com are
queue-4.14/crypto-tcrypt-fix-buffer-lengths-in-test_aead_speed.patch
This is a note to let you know that I've just added the patch titled
clk: tegra: Use readl_relaxed_poll_timeout_atomic() in tegra210_clock_init()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-tegra-use-readl_relaxed_poll_timeout_atomic-in-tegra210_clock_init.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Nicolin Chen <nicoleotsuka(a)gmail.com>
Date: Fri, 15 Sep 2017 12:10:13 -0700
Subject: clk: tegra: Use readl_relaxed_poll_timeout_atomic() in tegra210_clock_init()
From: Nicolin Chen <nicoleotsuka(a)gmail.com>
[ Upstream commit 22ef01a203d27fee8b7694020b7e722db7efd2a7 ]
Below is the call trace of tegra210_init_pllu() function:
start_kernel()
-> time_init()
--> of_clk_init()
---> tegra210_clock_init()
----> tegra210_pll_init()
-----> tegra210_init_pllu()
Because the preemption is disabled in the start_kernel before calling
time_init, tegra210_init_pllu is actually in an atomic context while
it includes a readl_relaxed_poll_timeout that might sleep.
So this patch just changes this readl_relaxed_poll_timeout() to its
atomic version.
Signed-off-by: Nicolin Chen <nicoleotsuka(a)gmail.com>
Acked-By: Peter De Schrijver <pdeschrijver(a)nvidia.com>
Signed-off-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/tegra/clk-tegra210.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/clk/tegra/clk-tegra210.c
+++ b/drivers/clk/tegra/clk-tegra210.c
@@ -2566,8 +2566,8 @@ static int tegra210_enable_pllu(void)
reg |= PLL_ENABLE;
writel(reg, clk_base + PLLU_BASE);
- readl_relaxed_poll_timeout(clk_base + PLLU_BASE, reg,
- reg & PLL_BASE_LOCK, 2, 1000);
+ readl_relaxed_poll_timeout_atomic(clk_base + PLLU_BASE, reg,
+ reg & PLL_BASE_LOCK, 2, 1000);
if (!(reg & PLL_BASE_LOCK)) {
pr_err("Timed out waiting for PLL_U to lock\n");
return -ETIMEDOUT;
Patches currently in stable-queue which might be from nicoleotsuka(a)gmail.com are
queue-4.14/clk-tegra-use-readl_relaxed_poll_timeout_atomic-in-tegra210_clock_init.patch
This is a note to let you know that I've just added the patch titled
clk: tegra: Fix cclk_lp divisor register
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-tegra-fix-cclk_lp-divisor-register.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl>
Date: Tue, 19 Sep 2017 04:48:10 +0200
Subject: clk: tegra: Fix cclk_lp divisor register
From: Michał Mirosław <mirq-linux(a)rere.qmqm.pl>
[ Upstream commit 54eff2264d3e9fd7e3987de1d7eba1d3581c631e ]
According to comments in code and common sense, cclk_lp uses its
own divisor, not cclk_g's.
Fixes: b08e8c0ecc42 ("clk: tegra: add clock support for Tegra30")
Signed-off-by: Michał Mirosław <mirq-linux(a)rere.qmqm.pl>
Acked-By: Peter De Schrijver <pdeschrijver(a)nvidia.com>
Signed-off-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/tegra/clk-tegra30.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -964,7 +964,7 @@ static void __init tegra30_super_clk_ini
* U71 divider of cclk_lp.
*/
clk = tegra_clk_register_divider("pll_p_out3_cclklp", "pll_p_out3",
- clk_base + SUPER_CCLKG_DIVIDER, 0,
+ clk_base + SUPER_CCLKLP_DIVIDER, 0,
TEGRA_DIVIDER_INT, 16, 8, 1, NULL);
clk_register_clkdev(clk, "pll_p_out3_cclklp", NULL);
Patches currently in stable-queue which might be from mirq-linux(a)rere.qmqm.pl are
queue-4.14/clk-tegra-fix-cclk_lp-divisor-register.patch
This is a note to let you know that I've just added the patch titled
clk: mediatek: add the option for determining PLL source clock
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-mediatek-add-the-option-for-determining-pll-source-clock.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Chen Zhong <chen.zhong(a)mediatek.com>
Date: Thu, 5 Oct 2017 11:50:23 +0800
Subject: clk: mediatek: add the option for determining PLL source clock
From: Chen Zhong <chen.zhong(a)mediatek.com>
[ Upstream commit c955bf3998efa3355790a4d8c82874582f1bc727 ]
Since the previous setup always sets the PLL using crystal 26MHz, this
doesn't always happen in every MediaTek platform. So the patch added
flexibility for assigning extra member for determining the PLL source
clock.
Signed-off-by: Chen Zhong <chen.zhong(a)mediatek.com>
Signed-off-by: Sean Wang <sean.wang(a)mediatek.com>
Signed-off-by: Stephen Boyd <sboyd(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/mediatek/clk-mtk.h | 1 +
drivers/clk/mediatek/clk-pll.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -216,6 +216,7 @@ struct mtk_pll_data {
uint32_t pcw_reg;
int pcw_shift;
const struct mtk_pll_div_table *div_table;
+ const char *parent_name;
};
void mtk_clk_register_plls(struct device_node *node,
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -303,7 +303,10 @@ static struct clk *mtk_clk_register_pll(
init.name = data->name;
init.flags = (data->flags & PLL_AO) ? CLK_IS_CRITICAL : 0;
init.ops = &mtk_pll_ops;
- init.parent_names = &parent_name;
+ if (data->parent_name)
+ init.parent_names = &data->parent_name;
+ else
+ init.parent_names = &parent_name;
init.num_parents = 1;
clk = clk_register(NULL, &pll->hw);
Patches currently in stable-queue which might be from chen.zhong(a)mediatek.com are
queue-4.14/clk-mediatek-add-the-option-for-determining-pll-source-clock.patch