2024-04-29 17:35:38

by Sui Jingfeng

[permalink] [raw]
Subject: [PATCH] drm: drm_of.c: Using EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL

Linux kernel puts strict limits on which functions and data structures
are available to loadable kernel modules; only those that have been
explicitly exported with EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() are
accessible. In the case of EXPORT_SYMBOL_GPL(), only modules that declare
a GPL-compatible license will be able to see the symbol.

Since the whole drm_of.c file is declared with GPL-2.0-only license, so
let us keep functions in that source file consistently.

Signed-off-by: Sui Jingfeng <[email protected]>
---
drivers/gpu/drm/drm_of.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 177b600895d3..1ca36d654e61 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -44,7 +44,7 @@ uint32_t drm_of_crtc_port_mask(struct drm_device *dev,

return 0;
}
-EXPORT_SYMBOL(drm_of_crtc_port_mask);
+EXPORT_SYMBOL_GPL(drm_of_crtc_port_mask);

/**
* drm_of_find_possible_crtcs - find the possible CRTCs for an encoder port
@@ -77,7 +77,7 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,

return possible_crtcs;
}
-EXPORT_SYMBOL(drm_of_find_possible_crtcs);
+EXPORT_SYMBOL_GPL(drm_of_find_possible_crtcs);

/**
* drm_of_component_match_add - Add a component helper OF node match rule
@@ -181,7 +181,7 @@ int drm_of_component_probe(struct device *dev,

return component_master_add_with_match(dev, m_ops, match);
}
-EXPORT_SYMBOL(drm_of_component_probe);
+EXPORT_SYMBOL_GPL(drm_of_component_probe);

/*
* drm_of_encoder_active_endpoint - return the active encoder endpoint
--
2.34.1



2024-04-30 09:38:06

by Maxime Ripard

[permalink] [raw]
Subject: Re: [PATCH] drm: drm_of.c: Using EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL

Hi,

On Tue, Apr 30, 2024 at 01:35:21AM +0800, Sui Jingfeng wrote:
> Linux kernel puts strict limits on which functions and data structures
> are available to loadable kernel modules; only those that have been
> explicitly exported with EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() are
> accessible. In the case of EXPORT_SYMBOL_GPL(), only modules that declare
> a GPL-compatible license will be able to see the symbol.
>
> Since the whole drm_of.c file is declared with GPL-2.0-only license, so
> let us keep functions in that source file consistently.

You're conflating two things: the license of the code itself (GPL2
here), and the license of the users of the symbols exported in that
file (anything).

There's no relationship between the two, and you have to make an
argument for changing the latter other than just because the license is
GPL because, again, those are two different things.

Maxime


Attachments:
(No filename) (922.00 B)
signature.asc (281.00 B)
Download all attachments

2024-04-30 17:24:09

by Sui Jingfeng

[permalink] [raw]
Subject: Re: [PATCH] drm: drm_of.c: Using EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL

Hi,


On 2024/4/30 17:26, Maxime Ripard wrote:
> Hi,
>
> On Tue, Apr 30, 2024 at 01:35:21AM +0800, Sui Jingfeng wrote:
>> Linux kernel puts strict limits on which functions and data structures
>> are available to loadable kernel modules; only those that have been
>> explicitly exported with EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() are
>> accessible. In the case of EXPORT_SYMBOL_GPL(), only modules that declare
>> a GPL-compatible license will be able to see the symbol.
>>
>> Since the whole drm_of.c file is declared with GPL-2.0-only license, so
>> let us keep functions in that source file consistently.
> You're conflating two things: the license of the code itself (GPL2
> here), and the license of the users of the symbols exported in that
> file (anything).
>
> There's no relationship between the two, and you have to make an
> argument for changing the latter other than just because the license is
> GPL because, again, those are two different things.

Yeah, I think you might be correct.

It seems that it is valid to have EXPORT_SYMBOL() in GPL-2.0-only licensed file.


> Maxime

--
Best regards,
Sui