On Mon, Feb 03, 2025 at 11:24:50AM +0100, Thomas Zimmermann wrote:
> Hi
>
>
> Am 14.01.25 um 00:15 schrieb Lorenzo Stoakes:
> [...]
> >
> > *** REVIEWERS NOTES: ***
> >
> > I do not have any hardware that uses fb_defio, so I'm asking for help with
> > testing this series from those who do :) I have
Hi
Am 14.01.25 um 00:15 schrieb Lorenzo Stoakes:
[...]
*** REVIEWERS NOTES: ***
I do not have any hardware that uses fb_defio, so I'm asking for help with
testing this series from those who do :) I have tested the mm side of this,
and done a quick compile smoke test of the fb_defio side but t
> +cc Kajtar, who has kindly smoke tested this series on real hardware and
> confirmed things are working ostensibly the same as before.
>
> On this basis I will be un-RFC'ing this and, if Kajtar can reply to
> confirm, will add a Tested-by tag to patch 3/3.
No problem, I'm glad I could help. Usi
+cc Kajtar, who has kindly smoke tested this series on real hardware and
confirmed things are working ostensibly the same as before.
On this basis I will be un-RFC'ing this and, if Kajtar can reply to
confirm, will add a Tested-by tag to patch 3/3.
Again to emphasise - there is some urgency here
Hi guys,
It'd be good if somebody from the drm side could look at this as you are
using fields that are deprecated and will be made unavailable (in a
non-optional fashion), and relatively soon :)
It'd be good to confirm this works on real hardware (none of mine supports
this sadly, I tried 3 sepa
Right now the only means by which we can write-protect a range using the
reverse mapping is via folio_mkclean().
However this is not always the appropriate means of doing so, specifically
in the case of the framebuffer deferred I/O logic (fb_defio enabled by
CONFIG_FB_DEFERRED_IO). There, kernel p
