On 3/13/23 15:29, Andy Shevchenko wrote:
On Mon, Mar 13, 2023 at 03:11:52PM +0200, Matti Vaittinen wrote:
On 3/13/23 14:40, Andy Shevchenko wrote:
On Sun, Mar 12, 2023 at 05:08:48PM +0000, Jonathan Cameron wrote:
On Sun, 12 Mar 2023 17:06:38 +0000
Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
...
Ah. I forgot the tests that don't have a device so can't use devm.
Why not? I have seen, IIRC, test cases inside the kernel that fakes the device
for that.
I'd appreciated any pointer for such an example if you have one at hand. (I
can do the digging if you don't though!)
I am not a fan of unit tests. They add huge amount of inertia to
development, and in worst case, they stop people from contributing where
improving a feature requires test code modification(s). And harder the test
code is to understand, worse the unwanted side-effects. Also, harder the
test code is to read, more time and effort it requires to analyze a test
failure... Hence, I am _very_ conservative what comes to adding size of test
code with anything that is not strictly required.
After that being said, unit tests are a great tool when carefully used - and
I assume/hope stubbing a device for devm_ tests does not add much extra...
But let me see if I can find an example :)
drivers/gpu/drm/tests/drm_managed_test.c ?
(somewhere underneath:
ret = platform_driver_register(&fake_platform_driver);
which suggests... what exactly? :-)
Thanks!
--Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
