All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] video: exynos: fix modular build
Date: Mon, 29 Feb 2016 16:55:39 +0000	[thread overview]
Message-ID: <56D4780B.2070406@ti.com> (raw)
In-Reply-To: <6291541.7IMAnfX0g2@wuerfel>


[-- Attachment #1.1: Type: text/plain, Size: 3081 bytes --]

On 29/02/16 18:39, Arnd Bergmann wrote:
> On Monday 29 February 2016 18:12:45 Tomi Valkeinen wrote:
>> Hi,
>>
>> On 26/02/16 14:38, Arnd Bergmann wrote:
>>> The s6e8ax0 driver has a dependency on BACKLIGHT_CLASS_DEVICE,
>>> which can be configured as a loadable module, so we have to
>>> make the driver a tristate symbol as well, to avoid this error:
>>>
>>> drivers/built-in.o: In function `s6e8ax0_probe':
>>> :(.text+0x23a48): undefined reference to `devm_backlight_device_register'
>>
>> If a 'bool' Kconfig option depends on BACKLIGHT_CLASS_DEVICE, shouldn't
>> the Kconfig dependency take care of having BACKLIGHT_CLASS_DEVICE as
>> built-in?
> 
> No, that's not how Kconfig interprets it. There are many bool option
> that depend on tristate options but can be enabled if the dependency
> is built-in.
> 
> Take this one for example:
> 
> config FIRMWARE_EDID
>        bool "Enable firmware EDID"
>        depends on FB
> 
> We clearly want to be able to turn this on even for FB=m.

Right.

>>> This also means we get another error from a missing export, which
>>> this fixes as well:
>>>
>>> ERROR: "exynos_mipi_dsi_register_lcd_driver" [drivers/video/fbdev/exynos/s6e8ax0.ko] undefined!
>>>
>>> The drivers are all written to be loadable modules already,
>>> except the Kconfig options for that are missing, which makes
>>> the patch really easy.
>>
>> Looks and sound fine, except doesn't this tell that the drivers have
>> never been tested as modules? Did you or someone else actually test these?
> 
> No, this is not runtime tested. Generally there is very little that
> can go wrong here though.
> 
> An alternative would be to change the dependency to
> 
> 	depends on BACKLIGHT_CLASS_DEVICE=y
> 
> which doesn't allow the driver to be turned on for the =m case.
> However, no other framebuffer driver does this.

No, I think it's clearly better to make them tristate. I think all
drivers should be buildable as modules. It just makes me a bit
uncomfortable to enable code that has never been ran.

>>> diff --git a/drivers/video/fbdev/exynos/Makefile b/drivers/video/fbdev/exynos/Makefile
>>> index b5b1bd228abb..02d8dc522fea 100644
>>> --- a/drivers/video/fbdev/exynos/Makefile
>>> +++ b/drivers/video/fbdev/exynos/Makefile
>>> @@ -2,6 +2,8 @@
>>>  # Makefile for the exynos video drivers.
>>>  #
>>>  
>>> -obj-$(CONFIG_EXYNOS_MIPI_DSI)		+= exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
>>> -				     	exynos_mipi_dsi_lowlevel.o
>>> +obj-$(CONFIG_EXYNOS_MIPI_DSI)		+= exynos-mipi-dsi-mod.o
>>> +
>>> +exynos-mipi-dsi-mod-objs		+= exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
>>> +					   exynos_mipi_dsi_lowlevel.o
>>
>> Hmm, why is this makefile change needed?
> 
> The original Makefile would link each file into a separate module, but that
> cannot work, because they reference symbols from each other that are not
> exported to other modules.
> 
> With my change, all the files get linked into a single module.

Yes, of course.

Thanks, I'll queue this up for 4.6.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org
Cc: Paul Bolle <pebolle@tiscali.nl>,
	linux-samsung-soc@vger.kernel.org,
	Donghwa Lee <dh09.lee@samsung.com>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	linux-kernel@vger.kernel.org, Inki Dae <inki.dae@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Kukjin Kim <kgene@kernel.org>,
	linux-fbdev@vger.kernel.org,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Subject: Re: [PATCH v2] video: exynos: fix modular build
Date: Mon, 29 Feb 2016 18:55:39 +0200	[thread overview]
Message-ID: <56D4780B.2070406@ti.com> (raw)
In-Reply-To: <6291541.7IMAnfX0g2@wuerfel>


[-- Attachment #1.1: Type: text/plain, Size: 3081 bytes --]

On 29/02/16 18:39, Arnd Bergmann wrote:
> On Monday 29 February 2016 18:12:45 Tomi Valkeinen wrote:
>> Hi,
>>
>> On 26/02/16 14:38, Arnd Bergmann wrote:
>>> The s6e8ax0 driver has a dependency on BACKLIGHT_CLASS_DEVICE,
>>> which can be configured as a loadable module, so we have to
>>> make the driver a tristate symbol as well, to avoid this error:
>>>
>>> drivers/built-in.o: In function `s6e8ax0_probe':
>>> :(.text+0x23a48): undefined reference to `devm_backlight_device_register'
>>
>> If a 'bool' Kconfig option depends on BACKLIGHT_CLASS_DEVICE, shouldn't
>> the Kconfig dependency take care of having BACKLIGHT_CLASS_DEVICE as
>> built-in?
> 
> No, that's not how Kconfig interprets it. There are many bool option
> that depend on tristate options but can be enabled if the dependency
> is built-in.
> 
> Take this one for example:
> 
> config FIRMWARE_EDID
>        bool "Enable firmware EDID"
>        depends on FB
> 
> We clearly want to be able to turn this on even for FB=m.

Right.

>>> This also means we get another error from a missing export, which
>>> this fixes as well:
>>>
>>> ERROR: "exynos_mipi_dsi_register_lcd_driver" [drivers/video/fbdev/exynos/s6e8ax0.ko] undefined!
>>>
>>> The drivers are all written to be loadable modules already,
>>> except the Kconfig options for that are missing, which makes
>>> the patch really easy.
>>
>> Looks and sound fine, except doesn't this tell that the drivers have
>> never been tested as modules? Did you or someone else actually test these?
> 
> No, this is not runtime tested. Generally there is very little that
> can go wrong here though.
> 
> An alternative would be to change the dependency to
> 
> 	depends on BACKLIGHT_CLASS_DEVICE=y
> 
> which doesn't allow the driver to be turned on for the =m case.
> However, no other framebuffer driver does this.

No, I think it's clearly better to make them tristate. I think all
drivers should be buildable as modules. It just makes me a bit
uncomfortable to enable code that has never been ran.

>>> diff --git a/drivers/video/fbdev/exynos/Makefile b/drivers/video/fbdev/exynos/Makefile
>>> index b5b1bd228abb..02d8dc522fea 100644
>>> --- a/drivers/video/fbdev/exynos/Makefile
>>> +++ b/drivers/video/fbdev/exynos/Makefile
>>> @@ -2,6 +2,8 @@
>>>  # Makefile for the exynos video drivers.
>>>  #
>>>  
>>> -obj-$(CONFIG_EXYNOS_MIPI_DSI)		+= exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
>>> -				     	exynos_mipi_dsi_lowlevel.o
>>> +obj-$(CONFIG_EXYNOS_MIPI_DSI)		+= exynos-mipi-dsi-mod.o
>>> +
>>> +exynos-mipi-dsi-mod-objs		+= exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
>>> +					   exynos_mipi_dsi_lowlevel.o
>>
>> Hmm, why is this makefile change needed?
> 
> The original Makefile would link each file into a separate module, but that
> cannot work, because they reference symbols from each other that are not
> exported to other modules.
> 
> With my change, all the files get linked into a single module.

Yes, of course.

Thanks, I'll queue this up for 4.6.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: tomi.valkeinen@ti.com (Tomi Valkeinen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] video: exynos: fix modular build
Date: Mon, 29 Feb 2016 18:55:39 +0200	[thread overview]
Message-ID: <56D4780B.2070406@ti.com> (raw)
In-Reply-To: <6291541.7IMAnfX0g2@wuerfel>

On 29/02/16 18:39, Arnd Bergmann wrote:
> On Monday 29 February 2016 18:12:45 Tomi Valkeinen wrote:
>> Hi,
>>
>> On 26/02/16 14:38, Arnd Bergmann wrote:
>>> The s6e8ax0 driver has a dependency on BACKLIGHT_CLASS_DEVICE,
>>> which can be configured as a loadable module, so we have to
>>> make the driver a tristate symbol as well, to avoid this error:
>>>
>>> drivers/built-in.o: In function `s6e8ax0_probe':
>>> :(.text+0x23a48): undefined reference to `devm_backlight_device_register'
>>
>> If a 'bool' Kconfig option depends on BACKLIGHT_CLASS_DEVICE, shouldn't
>> the Kconfig dependency take care of having BACKLIGHT_CLASS_DEVICE as
>> built-in?
> 
> No, that's not how Kconfig interprets it. There are many bool option
> that depend on tristate options but can be enabled if the dependency
> is built-in.
> 
> Take this one for example:
> 
> config FIRMWARE_EDID
>        bool "Enable firmware EDID"
>        depends on FB
> 
> We clearly want to be able to turn this on even for FB=m.

Right.

>>> This also means we get another error from a missing export, which
>>> this fixes as well:
>>>
>>> ERROR: "exynos_mipi_dsi_register_lcd_driver" [drivers/video/fbdev/exynos/s6e8ax0.ko] undefined!
>>>
>>> The drivers are all written to be loadable modules already,
>>> except the Kconfig options for that are missing, which makes
>>> the patch really easy.
>>
>> Looks and sound fine, except doesn't this tell that the drivers have
>> never been tested as modules? Did you or someone else actually test these?
> 
> No, this is not runtime tested. Generally there is very little that
> can go wrong here though.
> 
> An alternative would be to change the dependency to
> 
> 	depends on BACKLIGHT_CLASS_DEVICE=y
> 
> which doesn't allow the driver to be turned on for the =m case.
> However, no other framebuffer driver does this.

No, I think it's clearly better to make them tristate. I think all
drivers should be buildable as modules. It just makes me a bit
uncomfortable to enable code that has never been ran.

>>> diff --git a/drivers/video/fbdev/exynos/Makefile b/drivers/video/fbdev/exynos/Makefile
>>> index b5b1bd228abb..02d8dc522fea 100644
>>> --- a/drivers/video/fbdev/exynos/Makefile
>>> +++ b/drivers/video/fbdev/exynos/Makefile
>>> @@ -2,6 +2,8 @@
>>>  # Makefile for the exynos video drivers.
>>>  #
>>>  
>>> -obj-$(CONFIG_EXYNOS_MIPI_DSI)		+= exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
>>> -				     	exynos_mipi_dsi_lowlevel.o
>>> +obj-$(CONFIG_EXYNOS_MIPI_DSI)		+= exynos-mipi-dsi-mod.o
>>> +
>>> +exynos-mipi-dsi-mod-objs		+= exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
>>> +					   exynos_mipi_dsi_lowlevel.o
>>
>> Hmm, why is this makefile change needed?
> 
> The original Makefile would link each file into a separate module, but that
> cannot work, because they reference symbols from each other that are not
> exported to other modules.
> 
> With my change, all the files get linked into a single module.

Yes, of course.

Thanks, I'll queue this up for 4.6.

 Tomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160229/cf158edd/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Arnd Bergmann <arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Cc: Paul Bolle <pebolle@tiscali.nl>,
	<linux-samsung-soc@vger.kernel.org>,
	Donghwa Lee <dh09.lee@samsung.com>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	<linux-kernel@vger.kernel.org>, Inki Dae <inki.dae@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Kukjin Kim <kgene@kernel.org>, <linux-fbdev@vger.kernel.org>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Subject: Re: [PATCH v2] video: exynos: fix modular build
Date: Mon, 29 Feb 2016 18:55:39 +0200	[thread overview]
Message-ID: <56D4780B.2070406@ti.com> (raw)
In-Reply-To: <6291541.7IMAnfX0g2@wuerfel>


[-- Attachment #1.1: Type: text/plain, Size: 3081 bytes --]

On 29/02/16 18:39, Arnd Bergmann wrote:
> On Monday 29 February 2016 18:12:45 Tomi Valkeinen wrote:
>> Hi,
>>
>> On 26/02/16 14:38, Arnd Bergmann wrote:
>>> The s6e8ax0 driver has a dependency on BACKLIGHT_CLASS_DEVICE,
>>> which can be configured as a loadable module, so we have to
>>> make the driver a tristate symbol as well, to avoid this error:
>>>
>>> drivers/built-in.o: In function `s6e8ax0_probe':
>>> :(.text+0x23a48): undefined reference to `devm_backlight_device_register'
>>
>> If a 'bool' Kconfig option depends on BACKLIGHT_CLASS_DEVICE, shouldn't
>> the Kconfig dependency take care of having BACKLIGHT_CLASS_DEVICE as
>> built-in?
> 
> No, that's not how Kconfig interprets it. There are many bool option
> that depend on tristate options but can be enabled if the dependency
> is built-in.
> 
> Take this one for example:
> 
> config FIRMWARE_EDID
>        bool "Enable firmware EDID"
>        depends on FB
> 
> We clearly want to be able to turn this on even for FB=m.

Right.

>>> This also means we get another error from a missing export, which
>>> this fixes as well:
>>>
>>> ERROR: "exynos_mipi_dsi_register_lcd_driver" [drivers/video/fbdev/exynos/s6e8ax0.ko] undefined!
>>>
>>> The drivers are all written to be loadable modules already,
>>> except the Kconfig options for that are missing, which makes
>>> the patch really easy.
>>
>> Looks and sound fine, except doesn't this tell that the drivers have
>> never been tested as modules? Did you or someone else actually test these?
> 
> No, this is not runtime tested. Generally there is very little that
> can go wrong here though.
> 
> An alternative would be to change the dependency to
> 
> 	depends on BACKLIGHT_CLASS_DEVICE=y
> 
> which doesn't allow the driver to be turned on for the =m case.
> However, no other framebuffer driver does this.

No, I think it's clearly better to make them tristate. I think all
drivers should be buildable as modules. It just makes me a bit
uncomfortable to enable code that has never been ran.

>>> diff --git a/drivers/video/fbdev/exynos/Makefile b/drivers/video/fbdev/exynos/Makefile
>>> index b5b1bd228abb..02d8dc522fea 100644
>>> --- a/drivers/video/fbdev/exynos/Makefile
>>> +++ b/drivers/video/fbdev/exynos/Makefile
>>> @@ -2,6 +2,8 @@
>>>  # Makefile for the exynos video drivers.
>>>  #
>>>  
>>> -obj-$(CONFIG_EXYNOS_MIPI_DSI)		+= exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
>>> -				     	exynos_mipi_dsi_lowlevel.o
>>> +obj-$(CONFIG_EXYNOS_MIPI_DSI)		+= exynos-mipi-dsi-mod.o
>>> +
>>> +exynos-mipi-dsi-mod-objs		+= exynos_mipi_dsi.o exynos_mipi_dsi_common.o \
>>> +					   exynos_mipi_dsi_lowlevel.o
>>
>> Hmm, why is this makefile change needed?
> 
> The original Makefile would link each file into a separate module, but that
> cannot work, because they reference symbols from each other that are not
> exported to other modules.
> 
> With my change, all the files get linked into a single module.

Yes, of course.

Thanks, I'll queue this up for 4.6.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-02-29 16:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26 12:38 [PATCH v2] video: exynos: fix modular build Arnd Bergmann
2016-02-26 12:38 ` Arnd Bergmann
2016-02-26 12:38 ` Arnd Bergmann
2016-02-26 12:38 ` Arnd Bergmann
2016-02-29 16:12 ` Tomi Valkeinen
2016-02-29 16:12   ` Tomi Valkeinen
2016-02-29 16:12   ` Tomi Valkeinen
2016-02-29 16:12   ` Tomi Valkeinen
2016-02-29 16:39   ` Arnd Bergmann
2016-02-29 16:39     ` Arnd Bergmann
2016-02-29 16:39     ` Arnd Bergmann
2016-02-29 16:55     ` Tomi Valkeinen [this message]
2016-02-29 16:55       ` Tomi Valkeinen
2016-02-29 16:55       ` Tomi Valkeinen
2016-02-29 16:55       ` Tomi Valkeinen

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=56D4780B.2070406@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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.