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]
Date:	Thu, 17 Mar 2016 13:57:08 -0300
From:	Javier Martinez Canillas <javier@....samsung.com>
To:	Chanwoo Choi <cw00.choi@...sung.com>, linux-kernel@...r.kernel.org
Cc:	Lee Jones <lee.jones@...aro.org>
Subject: Re: [RFC/RFT PATCH 2/2] mfd: max14577: Allow driver to be built as a
 module

Hello Chanwoo,

On 03/17/2016 12:37 PM, Javier Martinez Canillas wrote:
> 
> On 03/16/2016 10:58 PM, Chanwoo Choi wrote:
>> On 2016년 03월 17일 01:48, Javier Martinez Canillas wrote:

[snip]

>>>
>>
>> When I test the kernel build with these patch-set on next-20160316 tag,
>> the following errors happen. 
>>
> 
> You are absolutely right, there was an error on my test script and always
> built it as built-in instead of as a module. I'm so sorry about that...
> 
>> ERROR: "maxim_charger_calc_reg_current" [drivers/regulator/max14577.ko] undefined!
>> ERROR: "maxim_charger_currents" [drivers/regulator/max14577.ko] undefined!
>> ERROR: "maxim_charger_currents" [drivers/power/max14577_charger.ko] undefined!
>> ERROR: "maxim_charger_calc_reg_current" [drivers/power/max14577_charger.ko] undefined!
>>
> 
> This seems to be a latent bug that was exposed by making the max14577 MFD
> Kconfig symbol tristate. Since I'm able to reproduce it even without the
> patches by enabling the max14577 regulator and power drivers as a module.
>

Sorry again, this error goes away after I clean the build directory so it
does not happen without this patch-set. Now, I found what's the issue and
is that both the max14577 MFD and regulator drivers have the same object
file name so they both end being called max14577.ko.

This confuses Kbuild and so in the modpost step, the exported symbols by
the MFD driver don't end into Module.symvers. This doesn't happen when
the driver is not a module since symbols come from the vmlinux binary.

I'll post a patch to rename the regulator driver to max14577-regulator,
this will be necessary anyways to have max14577 as a module since Kbuild
also gets confused and don't copy both modules because have the same name.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ