linux-kernel - Re: rockchip_i2s_tdm.c:undefined reference to `clk_set

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <13326272.At7iLaMNiz@archbook>
Date:   Tue, 07 Dec 2021 12:32:52 +0100
From:   Nicolas Frattaroli <frattaroli.nicolas@...il.com>
To:     kernel test robot <lkp@...el.com>
Cc:     kbuild-all@...ts.01.org, linux-kernel@...r.kernel.org,
        Mark Brown <broonie@...nel.org>
Subject: Re: rockchip_i2s_tdm.c:undefined reference to `clk_set_parent'

On Montag, 6. Dezember 2021 23:46:38 CET kernel test robot wrote:
> [...]
> 
> All errors (new ones prefixed by >>):
> 
>    mips-linux-ld: sound/soc/jz4740/jz4740-i2s.o: in function `jz4740_i2s_set_sysclk':
>    jz4740-i2s.c:(.text+0x3ec): undefined reference to `clk_set_parent'
>    mips-linux-ld: jz4740-i2s.c:(.text+0x44c): undefined reference to `clk_set_parent'
>    mips-linux-ld: sound/soc/rockchip/rockchip_i2s_tdm.o: in function `rockchip_i2s_tdm_calibrate_mclk.isra.0':
> >> rockchip_i2s_tdm.c:(.text+0x10d4): undefined reference to `clk_set_parent'
> >> mips-linux-ld: rockchip_i2s_tdm.c:(.text+0x1180): undefined reference to `clk_set_parent'
> 

According to some previous conversations I've stumbled upon[1],
this appears to be due to certain MIPS configurations not
implementing the clock API properly, so they don't provide a
clk_set_parent despite advertising that they have support for
clocks.

So my question is: do I need to care about this? This hardware
will never be used on MIPS, and a lot of other drivers (as seen in
the errors snippet from the test robot) have the same issue, and
the problem is most likely not in my driver but in that specific
configuration's clock API implementation.

[1]: https://lore.kernel.org/lkml/8a41b718-a6f6-6b7f-1699-18ab619884c3@infradead.org/