public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Javier Martinez Canillas <javier@osg.samsung.com>
To: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	linux-kernel@vger.kernel.org
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH] regulator: Rename files for Maxim PMIC drivers
Date: Thu, 17 Mar 2016 23:41:26 -0300	[thread overview]
Message-ID: <56EB6AD6.7050407@osg.samsung.com> (raw)
In-Reply-To: <56EB46D7.5030807@samsung.com>

Hello Krzysztof,

Thanks a lot for your review.

On 03/17/2016 09:07 PM, Krzysztof Kozlowski wrote:
> On 18.03.2016 02:54, Javier Martinez Canillas wrote:
>> Most Maxim PMIC regulator drivers are for sub-devices of Multi-Function
>> Devices with drivers under drivers/mfd. But for many of these, the same
>> object file name was used for both the MFD and the regulator drivers.
>>
>> Having 2 different drivers with the same name causes a lot of confusion
>> to Kbuild, specially if these are built as module since only one module
>> will be installed and also exported symbols will be undefined due being
>> overwritten by the other module during modpost.
> 
> These regulator drivers do not export symbols. In case of max14577 only
> main MFD driver exports symbols so what do you mean by "overwriting by
> other module"?
>

That's correct, what I meant is that if only the MFD driver is built, then
Kbuild / modpost are able to obtain the exported symbols and add it to the
Module.symvers file.

But if the regulator driver is also built, then the build system isn't able
to handle that case and the exported symbols from Module.symvers disappear.

So IIUC what happens is that the build system gets the exported symbols from
the max14755 MFD module but then finds another module that has the same name
(with no exported symbols) and so discards the list of symbols that previously
had for that module. That's why I used the "overwriting by the other module".
 
> Beside that comment the patch itself is okay:
> 
> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> 
> 
> 
> Best regards,
> 
> Krzysztof
> 

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

  reply	other threads:[~2016-03-18  2:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-17 17:54 [PATCH] regulator: Rename files for Maxim PMIC drivers Javier Martinez Canillas
2016-03-18  0:07 ` Krzysztof Kozlowski
2016-03-18  2:41   ` Javier Martinez Canillas [this message]
2016-03-18  3:29     ` Krzysztof Kozlowski
2016-03-18  0:31 ` Chanwoo Choi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56EB6AD6.7050407@osg.samsung.com \
    --to=javier@osg.samsung.com \
    --cc=broonie@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=k.kozlowski@samsung.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox