[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <54c19328-35e2-4506-aa3a-a0b08813d873@app.fastmail.com>
Date: Mon, 10 Jun 2024 08:24:51 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: José Expósito <jose.exposito89@...il.com>,
"Arnd Bergmann" <arnd@...nel.org>
Cc: "Jiri Kosina" <jikos@...nel.org>,
"Benjamin Tissoires" <bentiss@...nel.org>,
"Rahul Rameshbabu" <rrameshbabu@...dia.com>,
"Fabio Baltieri" <fabiobaltieri@...omium.org>,
"Ivan Gorinov" <linux-kernel@...imeter.info>,
"Johannes Roith" <johannes@...-linux.rocks>, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] HID: uclogic: avoid linking common code into multiple modules
On Sat, Jun 8, 2024, at 20:28, José Expósito wrote:
> On Wed, May 29, 2024 at 11:48:05AM +0200, Arnd Bergmann wrote:
>> @@ -154,10 +152,8 @@ obj-$(CONFIG_HID_WINWING) += hid-winwing.o
>> obj-$(CONFIG_HID_SENSOR_HUB) += hid-sensor-hub.o
>> obj-$(CONFIG_HID_SENSOR_CUSTOM_SENSOR) += hid-sensor-custom.o
>>
>> -hid-uclogic-test-objs := hid-uclogic-rdesc.o \
>> - hid-uclogic-params.o \
>> - hid-uclogic-rdesc-test.o
>> -obj-$(CONFIG_HID_KUNIT_TEST) += hid-uclogic-test.o
>> +hid-uclogic-test-objs := hid-uclogic-rdesc-test.o
>> +obj-$(CONFIG_HID_KUNIT_TEST) += hid-uclogic-test.o hid-uclogic-params.o hid-uclogic-params.o
>>
>> obj-$(CONFIG_USB_HID) += usbhid/
>> obj-$(CONFIG_USB_MOUSE) += usbhid/
>
> I tested your patch with:
>
> hid-uclogic-objs := hid-uclogic-core.o \
> hid-uclogic-rdesc.o \
> hid-uclogic-params.o
> obj-$(CONFIG_HID_UCLOGIC) += hid-uclogic.o
> [...]
> hid-uclogic-test-objs := hid-uclogic-rdesc-test.o
> obj-$(CONFIG_HID_KUNIT_TEST) += hid-uclogic.o hid-uclogic-test.o
>
> And I think it is a bit more clear and it looks like it does the trick
> removing the warning.
Right, that seems fine.
> Also, with that change only "EXPORT_SYMBOL_GPL(uclogic_rdesc_template_apply);"
> is required. The other EXPORT_SYMBOL_GPL can be removed.
>
> However, I'm not sure about what are the best practices using EXPORT_SYMBOL_GPL
> and if it should be used for each function/data in the .h file. Maybe that's
> why you added them.
No, having only the single export is better here, you should
have as few of them as possible. I did picked the more complicated
approach as I wasn't sure if loading the entire driver from the
test module caused any problems. Let's use your simpler patch
then.
Arnd
Powered by blists - more mailing lists