[PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular distinctions

Scott Branden scott.branden at broadcom.com
Mon May 29 09:35:27 PDT 2017


Hi Linus,


On 17-05-29 01:31 AM, Linus Walleij wrote:
> On Mon, May 22, 2017 at 10:56 PM, Paul Gortmaker
> <paul.gortmaker at windriver.com> wrote:
>
>> Fixups here tend to be more of a conglomerate of some of the other
>> repeated/systematic ones we've seen in the earlier pinctrl cleanups.
>>
>> We remove module.h from code that isn't doing anything modular at
>> all;  if they have __init sections, then replace it with init.h
>>
>> One driver has a .remove that would be dispatched on module_exit,
>> and as that code is essentially orphaned, so we remove it.  In case
>> anyone was previously doing the (pointless) unbind to get to that
>> function, we disable unbind for this one driver as well.
>>
>> A couple bool drivers (hence non-modular) are converted over to
>> to builtin_platform_driver().
>>
>> Since module_platform_driver() uses the same init level priority as
>> builtin_platform_driver() the init ordering remains unchanged with
>> this commit.
>>
>> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>>
>> We also delete the MODULE_LICENSE tag etc. since all that information
>> was (or is now) contained at the top of the file in the comments.
>>
>> Cc: Eric Anholt <eric at anholt.net>
>> Cc: Florian Fainelli <f.fainelli at gmail.com>
>> Cc: Jon Mason <jonmason at broadcom.com>
>> Cc: Linus Walleij <linus.walleij at linaro.org>
>> Cc: Ray Jui <rjui at broadcom.com>
>> Cc: Scott Branden <sbranden at broadcom.com>
>> Cc: Stefan Wahren <stefan.wahren at i2se.com>
>> Cc: Sherman Yin <syin at broadcom.com>
>> Cc: bcm-kernel-feedback-list at broadcom.com
>> Cc: linux-gpio at vger.kernel.org
>> Cc: linux-rpi-kernel at lists.infradead.org
>> Signed-off-by: Paul Gortmaker <paul.gortmaker at windriver.com>
> Patch applied with Stefan Wahren's Tested-by tag.
>
> I can't take header standardization into account, header files are not
> ABI, further see
> Documentation/process/stable-api-nonsense.rst
It is a simple ask to place the new information in a new comment after 
the legal header.

An aim at consistency helps reduce confusion (internal and external)
of what license header template to apply to files.  Modifying these 
headers and placing
information in the middle of them does not help in this effort.

> Yours,
> Linus Walleij
Regards,
Scott



More information about the linux-rpi-kernel mailing list