On 10/Apr/2024 Yuguo Pei wrote:
> Some screen sizes using st7789v chips are different from 240x320,
> and offsets need to be set to display all images properly.
>
> For those who use screens with offset, they only need to modify the values
> of size and offset, and do not need to a new set_addr_wi
On 2024-04-18 Patrik Jakobsson wrote:
> This sounds similar to the SUSE bug [1]. We fixed it by reverting [2]
> in the SUSE kernel. The problem seems to be that flush_delayed_work()
> kills the timer and re-queues the work but doesn't guarantee that it
> is finished when returning. So when the devi
On 2024-04-18 Harshit Mogalapalli wrote:
> While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
> bug in fb_deferred_io_work()
Which framebuffer device are you using exactly? It is possible that
the problem is with the device driver, not core framebuffer.
Best regards,
Nam
On 2024-04-18 Harshit Mogalapalli wrote:
> While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
> bug in fb_deferred_io_work()
I think the problem is because of improper offset address calculation.
The kernel calculate address offset with:
offset = vmf->address - vmf->
On 2024-04-18 Patrik Jakobsson wrote:
> On Thu, Apr 18, 2024 at 4:05 PM Nam Cao wrote:
> >
> > On 2024-04-18 Patrik Jakobsson wrote:
> > > This sounds similar to the SUSE bug [1]. We fixed it by reverting [2]
> > > in the SUSE kernel. The problem se
On 2024-04-19 Patrik Jakobsson wrote:
> Neither cancel_delayed_work_sync() or flush_delayed_work() prevent new
> work from being scheduled after they return.
flush_delayed_work() is called during device closing. And because no
writes are performed after the device has been closed, no new work
shou
On 2024-04-19 Harshit Mogalapalli wrote:
> +CC stable( heads up as this is a regression affecting 5.15.y and
> probably others, Greg: this was reproducible upstream so reported
> everything w.r.t upstream code but initially found on 5.15.y)
No worry about this, I will add a "Cc: " tag
to the pat
alli
Closes:
https://lore.kernel.org/linux-fbdev/271372d6-e665-4e7f-b088-dee5f4ab3...@oracle.com
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc: sta...@vger.kernel.org
Signed-off-by: Nam Cao
---
drivers/video/fbdev/core/fb_defio.c | 3 ++-
1 file changed, 2 inse
On Tue, Apr 23, 2024 at 10:37:41AM +0200, Thomas Zimmermann wrote:
> Hi,
>
> thanks for following through with the bug and sending the patch
>
> Am 19.04.24 um 21:00 schrieb Nam Cao:
> > With deferred IO enabled, a page fault happens when data is written to the
> &g
On Tue, Apr 23, 2024 at 01:27:09PM +0200, Thomas Zimmermann wrote:
> Am 23.04.24 um 11:55 schrieb Nam Cao:
...
> > > The page-fault handler at [1] use vm_fault.pgoff to retrieve the page
> > > structure. Can we do the same here and avoid that computation?
> > Yes
ab3...@oracle.com
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Cc:
Signed-off-by: Nam Cao
---
v2:
- simplify the patch by using vfg->pgoff
- remove tested-by tag, as the patch is now different
drivers/video/fbdev/core/fb_defio.c | 2 +-
1 file changed, 1 inser
On Tue, Apr 23, 2024 at 06:56:52PM +0530, Harshit Mogalapalli wrote:
> Thanks everyone!
>
> I have tested the patched kernel with the syzkaller reproducer and couldn't
> see a problem.
If you want to take credit for testing it, send us:
Tested-by: Your Name
And that tag will appear in
n be guaranteed that all previous writes make it to the
device.
Fixes: 5e841b88d23d ("fb: fsync() method for deferred I/O flush.")
Cc: sta...@vger.kernel.org
Signed-off-by: Nam Cao
Reviewed-by: Sebastian Andrzej Siewior
---
drivers/video/fbdev/core/fb_defio.c | 6 +-
1 file change
ed to do.
Nam Cao (2):
fb: flush deferred work in fb_deferred_io_fsync()
fb: flush deferred IO before closing
drivers/video/fbdev/core/fb_defio.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
--
2.39.2
deferred work. It is
not completely obvious whether it is okay to not clear the page mapping.
For a patch intended for stable trees, go with the simple and obvious
solution.
Fixes: 60b59beafba8 ("fbdev: mm: Deferred IO support")
Cc: sta...@vger.kernel.org
Signed-off-by: Nam Cao
R
On Sun, Sep 22, 2024 at 09:12:13AM -0300, Fabio wrote:
> Replaced two lines of calling udelays by usleep_range() functions, adding
> more efficiency due to the need of long-lasting delays of more than 10us.
>
> Signed-off-by: Fabio Bareiro
> ---
> drivers/staging/fbtft/fb_ra8875.c | 4 ++--
> 1
On Wed, May 28, 2025 at 05:42:30PM +0200, Bram Vlerick wrote:
> Add devicetree parameter to enable or disable the invert feature of the
> ili9341 display
Can't/shouldn't this be done by userspace application? Why would someone
want to invert the color by default.
Also, this driver is built on top
but you were blameless on this issue that I basically spent the
> last day on (I'd say "wasted" the last day on, but right now I feel
> good about finding it, so I guess it wasn't wasted time after all).
>
> Anyway, I think reverting that commit 8c44dac8add7 ("even
18 matches
Mail list logo
