All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Javier Martinez Canillas <javier@osg.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: Fri, 18 Mar 2016 12:29:49 +0900	[thread overview]
Message-ID: <56EB762D.9070200@samsung.com> (raw)
In-Reply-To: <56EB6AD6.7050407@osg.samsung.com>

On 18.03.2016 11:41, Javier Martinez Canillas wrote:
> 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".

Ah, that indeed makes sense. Thanks for careful explanation.

Best regards,
Krzysztof

  reply	other threads:[~2016-03-18  3:30 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
2016-03-18  3:29     ` Krzysztof Kozlowski [this message]
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=56EB762D.9070200@samsung.com \
    --to=k.kozlowski@samsung.com \
    --cc=broonie@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=javier@osg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.