Hi,
I still remember you are helps to review the drm/lsdc patch one years
ago, see [1].
drm/lsdc is the former version of drm/loongson, originally drm/lsdc
are embedded SoCs of Loongson.
[1] https://patchwork.freedesktop.org/patch/471997/?series=99512&rev=5
I haven't forget about you.
On 2023/7/18 21:59, Dan Carpenter wrote:
Even if the fail happened, your patch is not fixing the root problem.
What is the correct fix then?
lsdc_bo_create_kernel_pinned() is intend to be used when you do the self
test (cat benchmark)
which is using to testing the hardware bandwidth via debugfs.
Another potential usage is to implement built in fbdev emulation.
I admit the error handling is necessary, but it's a kind of costuming.
To be honest, I have also post similar patches to other DRM drivers.:-)
So, that is okay.
But let's back to the technique, when the kzalloc() fails, who will
survives?
If the the kzalloc() fail, then I think the implement of kzalloc()
should be blamed first.
while developing this driver nearly about two years, it rare happens.
For my drivers, kzalloc() fails is one sort of error,
lsdc_bo_create() could fail when no enough VRAM is another.
The dumb_buffer test if IGT would helps to probe such failures.
But this is a kind of limitation of the hardware itself.
Its a resource limitation, even the drm/radeon could probably fail.
So, How does your patch could resolve the root problems that caused by
no enough resource available?
