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:
On Mon, 6 Mar 2023 11:17:15 +0200
Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote:
...
Given most modern IIO drivers use fully devm_ based probing, for now I would not
expose anything else. That will reduce the interface a lot which I think
is probably a good thing at this stage.
Probably at any stage :)
Keep the non devm stuff internally though as it is a nice structure to have
an I can see we may want some of these in non devm form in the future.
Ok. I was pondering this while writing these APIs. I was just thinking
that _maybe_ someone has an driver where they do not use devm for a
reason. Allowing a "non devm" variants for such is likely to be needed.
Hence, I was thinking that having a non devm version could be beneficial
from the start to avoid someone being tempted to just mix the readily
available devm with manual unwinding...
Similarly - for now don't expose the individual table building functions
as we may never need them in drivers. We (more or less) only support interfaces
that are used and so far they aren't.
I was thinking of this too. It was just the small 'avoid extra
operations [like unnecessary endianess conversions :p] when
needed'-voice in me that started screaming when I though of exporting
only the 'build all' and 'purge all' APIs...
For other functions it's worth thinking about whether to not export them
initially. I haven't been through them all to figure out what is not currently used.
I think I can go through them. There are a few that aren't currently used.
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 :)
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
