* Re: EXTERNAL: [PATCH 0/2] backlight: mp3309c: Drop pwm_apply_args()
From: Uwe Kleine-König @ 2025-07-29 20:17 UTC (permalink / raw)
To: FLAVIO SULIGOI, Lee Jones, Daniel Thompson, Jingoo Han
Cc: Helge Deller, Daniel Thompson, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-pwm@vger.kernel.org
In-Reply-To: <PH0PR22MB37899F7A6262C599400AF912FA4FA@PH0PR22MB3789.namprd22.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
[Updating Daniel's email address as the linaro one stopped working]
Hello,
On Mon, Jul 07, 2025 at 03:44:25PM +0000, FLAVIO SULIGOI wrote:
> > the first patch of this series is what I really care about: There are
> > hardly any drivers left that use pwm_apply_args(). When all of them are
> > converted to not use it any more, I intend to drop that function.
> >
> > The 2nd patch is just a change that I noticed while editing the driver
> > that is IMHO nice. If you don't agree and only apply the first patch, I
> > won't argue. It's an alternative approach to what Daniel Thompson did in
> > commit 7ee6478d5aa9 ("backlight: mp3309c: Fully initialize
> > backlight_properties during probe").
>
> I've tested your patches on my board and all is ok.
@Flavio:
A Tested-by in this reply to the cover letter is understood by b4 (which
is the tool most maintainers use to apply patches from the mailing
list). So there wouldn't have been a need to reply to each mail
individually.
@backlight maintainers:
This patch didn't make it into next yet, I guess it's too late for
6.17-rc1 now?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] leds: Drop duplicate LEDS_EXPRESSWIRE config
From: Randy Dunlap @ 2025-07-29 23:31 UTC (permalink / raw)
To: Duje Mihanović, Lee Jones, Pavel Machek, Daniel Thompson,
Jingoo Han, Helge Deller
Cc: linux-leds, linux-kernel, dri-devel, linux-fbdev
In-Reply-To: <20250729-expresswire-dep-fix-v1-1-635cd4cc746b@dujemihanovic.xyz>
On 7/29/25 10:18 AM, Duje Mihanović wrote:
> While moving said config symbol out of the "if NEW_LEDS" block, I
> accidentally left a copy inside that block. Remove it.
>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Link: https://lore.kernel.org/all/b6c481bb-e854-405e-a428-90301789fe20@infradead.org/
s/Link/Closes/
> Fixes: 2cd0d1db31e7 ("leds: expresswire: Don't depend on NEW_LEDS")
> Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> drivers/leds/Kconfig | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 6e3dce7e35a490df050cb4cd8e98611028c8dce1..8098b7b49c9decb591a894fe514a7ee757da5b44 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -214,10 +214,6 @@ config LEDS_EL15203000
> To compile this driver as a module, choose M here: the module
> will be called leds-el15203000.
>
> -config LEDS_EXPRESSWIRE
> - bool
> - depends on GPIOLIB
> -
> config LEDS_TURRIS_OMNIA
> tristate "LED support for CZ.NIC's Turris Omnia"
> depends on LEDS_CLASS_MULTICOLOR
>
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/2] backlight: ktd2801: Depend on GPIOLIB
From: Randy Dunlap @ 2025-07-29 23:32 UTC (permalink / raw)
To: Duje Mihanović, Lee Jones, Pavel Machek, Daniel Thompson,
Jingoo Han, Helge Deller
Cc: linux-leds, linux-kernel, dri-devel, linux-fbdev
In-Reply-To: <20250729-expresswire-dep-fix-v1-2-635cd4cc746b@dujemihanovic.xyz>
On 7/29/25 10:18 AM, Duje Mihanović wrote:
> The LEDS_EXPRESSWIRE library used by the driver requires GPIOLIB. Make
> sure this dependency is not left unsatisfied.
>
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Link: https://lore.kernel.org/all/b6c481bb-e854-405e-a428-90301789fe20@infradead.org/
s/Link/Closes/
> Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> drivers/video/backlight/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index d9374d208ceebbf8b3c27976e9cb4d725939b942..37341474beb9982f7099711e5e2506081061df46 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -185,6 +185,7 @@ config BACKLIGHT_KTD253
>
> config BACKLIGHT_KTD2801
> tristate "Backlight Driver for Kinetic KTD2801"
> + depends on GPIOLIB || COMPILE_TEST
> select LEDS_EXPRESSWIRE
> help
> Say Y to enable the backlight driver for the Kinetic KTD2801 1-wire
>
--
~Randy
^ permalink raw reply
* Re: [syzbot] [fbdev?] KASAN: slab-out-of-bounds Read in fbcon_prepare_logo
From: syzbot @ 2025-07-30 20:34 UTC (permalink / raw)
To: deller, dri-devel, linux-fbdev, linux-kernel, simona,
syzkaller-bugs
In-Reply-To: <67bd6bef.050a0220.bbfd1.009d.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 4b290aae788e Merge tag 'sysctl-6.17-rc1' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10ff8834580000
kernel config: https://syzkaller.appspot.com/x/.config?x=eb654b6c0c63cccc
dashboard link: https://syzkaller.appspot.com/bug?extid=0c815b25cdb3678e7083
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=134389bc580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17a82ca2580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6d83c5020884/disk-4b290aae.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/91441dce0745/vmlinux-4b290aae.xz
kernel image: https://storage.googleapis.com/syzbot-assets/55d2e063b8a3/bzImage-4b290aae.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+0c815b25cdb3678e7083@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in scr_memcpyw include/linux/vt_buffer.h:38 [inline]
BUG: KASAN: slab-out-of-bounds in fbcon_prepare_logo+0xa03/0xc70 drivers/video/fbdev/core/fbcon.c:618
Read of size 256 at addr ffff8880331da860 by task syz.0.17/5996
CPU: 0 UID: 0 PID: 5996 Comm: syz.0.17 Not tainted 6.16.0-syzkaller-04405-g4b290aae788e #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0xcd/0x630 mm/kasan/report.c:482
kasan_report+0xe0/0x110 mm/kasan/report.c:595
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0x100/0x1b0 mm/kasan/generic.c:189
__asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105
scr_memcpyw include/linux/vt_buffer.h:38 [inline]
fbcon_prepare_logo+0xa03/0xc70 drivers/video/fbdev/core/fbcon.c:618
fbcon_init+0xd77/0x1900 drivers/video/fbdev/core/fbcon.c:1150
visual_init+0x31d/0x620 drivers/tty/vt/vt.c:1019
do_bind_con_driver.isra.0+0x57a/0xbf0 drivers/tty/vt/vt.c:3915
vt_bind drivers/tty/vt/vt.c:4071 [inline]
store_bind+0x61d/0x760 drivers/tty/vt/vt.c:4143
dev_attr_store+0x55/0x80 drivers/base/core.c:2437
sysfs_kf_write+0xef/0x150 fs/sysfs/file.c:145
kernfs_fop_write_iter+0x354/0x510 fs/kernfs/file.c:334
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x6c4/0x1150 fs/read_write.c:686
ksys_write+0x12a/0x250 fs/read_write.c:738
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f580578e9a9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffce73cfbb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f58059b5fa0 RCX: 00007f580578e9a9
RDX: 0000000000000081 RSI: 00002000000001c0 RDI: 0000000000000004
RBP: 00007f5805810d69 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f58059b5fa0 R14: 00007f58059b5fa0 R15: 0000000000000003
</TASK>
The buggy address belongs to the object at ffff8880331da000
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 96 bytes to the right of
allocated 2048-byte region [ffff8880331da000, ffff8880331da800)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x331d8
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000040 ffff88801b842000 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080080008 00000000f5000000 0000000000000000
head: 00fff00000000040 ffff88801b842000 dead000000000122 0000000000000000
head: 0000000000000000 0000000080080008 00000000f5000000 0000000000000000
head: 00fff00000000003 ffffea0000cc7601 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0x1d20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL), pid 5996, tgid 5996 (syz.0.17), ts 103546222970, free_ts 103072976762
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x1c0/0x230 mm/page_alloc.c:1704
prep_new_page mm/page_alloc.c:1712 [inline]
get_page_from_freelist+0x1321/0x3890 mm/page_alloc.c:3669
__alloc_frozen_pages_noprof+0x261/0x23f0 mm/page_alloc.c:4959
alloc_pages_mpol+0x1fb/0x550 mm/mempolicy.c:2419
alloc_slab_page mm/slub.c:2451 [inline]
allocate_slab mm/slub.c:2619 [inline]
new_slab+0x23b/0x330 mm/slub.c:2673
___slab_alloc+0xd9c/0x1940 mm/slub.c:3859
__slab_alloc.constprop.0+0x56/0xb0 mm/slub.c:3949
__slab_alloc_node mm/slub.c:4024 [inline]
slab_alloc_node mm/slub.c:4185 [inline]
__do_kmalloc_node mm/slub.c:4327 [inline]
__kmalloc_noprof+0x2f2/0x510 mm/slub.c:4340
kmalloc_noprof include/linux/slab.h:909 [inline]
kzalloc_noprof include/linux/slab.h:1039 [inline]
vc_do_resize+0x1de/0x10e0 drivers/tty/vt/vt.c:1182
vc_resize include/linux/vt_kern.h:49 [inline]
fbcon_startup+0x427/0xba0 drivers/video/fbdev/core/fbcon.c:1001
do_bind_con_driver.isra.0+0x20a/0xbf0 drivers/tty/vt/vt.c:3878
vt_bind drivers/tty/vt/vt.c:4071 [inline]
store_bind+0x61d/0x760 drivers/tty/vt/vt.c:4143
dev_attr_store+0x55/0x80 drivers/base/core.c:2437
sysfs_kf_write+0xef/0x150 fs/sysfs/file.c:145
kernfs_fop_write_iter+0x354/0x510 fs/kernfs/file.c:334
new_sync_write fs/read_write.c:593 [inline]
vfs_write+0x6c4/0x1150 fs/read_write.c:686
page last free pid 5947 tgid 5947 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
free_pages_prepare mm/page_alloc.c:1248 [inline]
__free_frozen_pages+0x7fe/0x1180 mm/page_alloc.c:2706
qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x4d/0x120 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x195/0x1e0 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x69/0x90 mm/kasan/common.c:329
kasan_slab_alloc include/linux/kasan.h:250 [inline]
slab_post_alloc_hook mm/slub.c:4148 [inline]
slab_alloc_node mm/slub.c:4197 [inline]
__do_kmalloc_node mm/slub.c:4327 [inline]
__kmalloc_noprof+0x1d4/0x510 mm/slub.c:4340
kmalloc_noprof include/linux/slab.h:909 [inline]
kzalloc_noprof include/linux/slab.h:1039 [inline]
fib6_info_alloc+0x40/0x160 net/ipv6/ip6_fib.c:155
ip6_route_info_create+0x14c/0x870 net/ipv6/route.c:3811
ip6_route_add.part.0+0x22/0x1d0 net/ipv6/route.c:3940
ip6_route_add+0x45/0x60 net/ipv6/route.c:3937
addrconf_prefix_route+0x2fd/0x510 net/ipv6/addrconf.c:2487
inet6_addr_add+0x589/0x960 net/ipv6/addrconf.c:3052
inet6_rtm_newaddr+0x1619/0x1c70 net/ipv6/addrconf.c:5058
rtnetlink_rcv_msg+0x95e/0xe90 net/core/rtnetlink.c:6944
netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552
netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
netlink_unicast+0x58a/0x850 net/netlink/af_netlink.c:1346
netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896
Memory state around the buggy address:
ffff8880331da700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880331da780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8880331da800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8880331da880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880331da900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply
* [PATCH] backlight: pwm_bl: apply the initial backlight state with sane defaults
From: Michael Grzeschik @ 2025-07-31 8:47 UTC (permalink / raw)
To: Uwe Kleine-König, Lee Jones, Daniel Thompson, Jingoo Han,
Helge Deller
Cc: Pengutronix, linux-pwm, dri-devel, linux-fbdev, linux-kernel,
Michael Grzeschik
Currently when calling pwm_apply_might_sleep in the probe routine
the pwm will be configured with an not fully defined state.
The duty_cycle is not yet set in that moment. There is a final
backlight_update_status call that will have a properly setup state.
However this change in the backlight can create a short flicker if the
backlight was already preinitialised.
We fix the flicker by moving the pwm_apply after the default duty_cycle
can be calculated.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
---
drivers/video/backlight/pwm_bl.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 237d3d3f3bb1a..5924e0b9f01e7 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -518,13 +518,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
if (!state.period && (data->pwm_period_ns > 0))
state.period = data->pwm_period_ns;
- ret = pwm_apply_might_sleep(pb->pwm, &state);
- if (ret) {
- dev_err_probe(&pdev->dev, ret,
- "failed to apply initial PWM state");
- goto err_alloc;
- }
-
memset(&props, 0, sizeof(struct backlight_properties));
if (data->levels) {
@@ -582,6 +575,15 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->lth_brightness = data->lth_brightness * (div_u64(state.period,
pb->scale));
+ state.duty_cycle = compute_duty_cycle(pb, data->dft_brightness, &state);
+
+ ret = pwm_apply_might_sleep(pb->pwm, &state);
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret,
+ "failed to apply initial PWM state");
+ goto err_alloc;
+ }
+
props.type = BACKLIGHT_RAW;
props.max_brightness = data->max_brightness;
bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, pb,
---
base-commit: 739a6c93cc755c0daf3a7e57e018a8c61047cd90
change-id: 20250731-blpwm-598ecad93c4d
Best regards,
--
Michael Grzeschik <m.grzeschik@pengutronix.de>
^ permalink raw reply related
* Re: [bug report] staging: sm750fb: Fix polarity assignment for vertical and horizontal mode
From: Dan Carpenter @ 2025-07-31 16:11 UTC (permalink / raw)
To: Alok Tiwari
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <20250723192528.77109-1-alok.a.tiwari@oracle.com>
On Wed, Jul 23, 2025 at 12:24:31PM -0700, Alok Tiwari wrote:
> In drivers/staging/sm750fb/sm750_hw.c,
> the vertical and horizontal sync polarity assignments were incorrectly
> ordered.
> The assignment for modparm.vertical_sync_polarity was mistakenly using
> the FB_SYNC_HOR_HIGH_ACT bit instead of FB_SYNC_VERT_HIGH_ACT,
> and the horizontal polarity line was commented out or missing.
>
> This patch corrects the logic by properly assigning:
>
> vertical_sync_polarity -> from FB_SYNC_VERT_HIGH_ACT
> horizontal_sync_polarity -> from FB_SYNC_HOR_HIGH_ACT
>
> Please let me know your feedback.
> Thanks,
> Alok
> ---
> Fixes: 81dee67e215b ("staging: sm750fb: add sm750 to staging")
> Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
> ---
Did you find this copy and paste bug by testing or reviewing the code?
How does this bug look like to a user? Please put that in your commit
message.
This looks reasonable to me, but the patch is badly formatted.
1) It should say [PATCH] in the subject.
2) The body of the email should be the commit message.
3) the --- should only come after the Signed-off-by line.
Try applying your patch with `git am` and review the log to see what I
mean.
regards,
dan carpenter
^ permalink raw reply
* Re: [External] : Re: [bug report] staging: sm750fb: Fix polarity assignment for vertical and horizontal mode
From: ALOK TIWARI @ 2025-07-31 16:33 UTC (permalink / raw)
To: Dan Carpenter
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <dbd2df69-27cc-4fd8-8e5b-78b6872d5d16@suswa.mountain>
On 7/31/2025 9:41 PM, Dan Carpenter wrote:
> On Wed, Jul 23, 2025 at 12:24:31PM -0700, Alok Tiwari wrote:
>> In drivers/staging/sm750fb/sm750_hw.c,
>> the vertical and horizontal sync polarity assignments were incorrectly
>> ordered.
>> The assignment for modparm.vertical_sync_polarity was mistakenly using
>> the FB_SYNC_HOR_HIGH_ACT bit instead of FB_SYNC_VERT_HIGH_ACT,
>> and the horizontal polarity line was commented out or missing.
>>
>> This patch corrects the logic by properly assigning:
>>
>> vertical_sync_polarity -> from FB_SYNC_VERT_HIGH_ACT
>> horizontal_sync_polarity -> from FB_SYNC_HOR_HIGH_ACT
>>
>> Please let me know your feedback.
>> Thanks,
>> Alok
>> ---
>> Fixes: 81dee67e215b ("staging: sm750fb: add sm750 to staging")
>> Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
>> ---
>
> Did you find this copy and paste bug by testing or reviewing the code?
> How does this bug look like to a user? Please put that in your commit
> message.
>
> This looks reasonable to me, but the patch is badly formatted.
>
> 1) It should say [PATCH] in the subject.
> 2) The body of the email should be the commit message.
> 3) the --- should only come after the Signed-off-by line.
>
> Try applying your patch with `git am` and review the log to see what I
> mean.
>
> regards,
> dan carpenter
>
Thanks Dan. By reviewing the code, I noticed some awkward assignment.
However, I was not sure about this code, so instead of sending a formal
patch, I just removed my SB and marked it as a [bug report].
I will send formal patch with proper SB.
Thanks,
Alok
^ permalink raw reply
* [PATCH] fbdev: core: Add checks for vc_resize failures
From: Zsolt Kajtar @ 2025-07-31 17:15 UTC (permalink / raw)
To: linux-fbdev; +Cc: Zsolt Kajtar
Whenever fbcon resizes the framebuffer the virtual console size is set
to match the new geometry. This ensures that the content won't end up
off-screen.
But in very rare cases vc_resize() can fail. If one follows the syzbot
monthly reports then this isn't all that rare because allocation
fault injection can do that reliably. Usually the one in
fbcon_set_disp.
Handling these failures gracefully and rolling back the resize isn't
trivial effort, at least for me. So the next best thing is to add
BUG_ON() checks.
In theory these checks shouldn't trigger normally. But when they do
memory corruption is prevented.
One check was left out in fbcon_startup.c, that's not a mistake. It
needs more investigation as it triggers on boot for me.
Signed-off-by: Zsolt Kajtar <soci@c64.rulez.org>
---
drivers/video/fbdev/core/fbcon.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2df480376..b9b65ae32 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1144,7 +1144,7 @@ static void fbcon_init(struct vc_data *vc, bool init)
vc->vc_cols = new_cols;
vc->vc_rows = new_rows;
} else
- vc_resize(vc, new_cols, new_rows);
+ BUG_ON(vc_resize(vc, new_cols, new_rows));
if (logo)
fbcon_prepare_logo(vc, info, cols, rows, new_cols, new_rows);
@@ -1412,7 +1412,7 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
cols /= vc->vc_font.width;
rows /= vc->vc_font.height;
- vc_resize(vc, cols, rows);
+ BUG_ON(vc_resize(vc, cols, rows));
if (con_is_visible(vc)) {
update_screen(vc);
@@ -2682,7 +2682,7 @@ static void fbcon_modechanged(struct fb_info *info)
rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
cols /= vc->vc_font.width;
rows /= vc->vc_font.height;
- vc_resize(vc, cols, rows);
+ BUG_ON(vc_resize(vc, cols, rows));
updatescrollmode(p, info, vc);
scrollback_max = 0;
scrollback_current = 0;
@@ -2725,7 +2725,7 @@ static void fbcon_set_all_vcs(struct fb_info *info)
rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
cols /= vc->vc_font.width;
rows /= vc->vc_font.height;
- vc_resize(vc, cols, rows);
+ BUG_ON(vc_resize(vc, cols, rows));
}
if (fg != -1)
--
2.30.2
^ permalink raw reply related
* Re: [External] : Re: [bug report] staging: sm750fb: Fix polarity assignment for vertical and horizontal mode
From: Dan Carpenter @ 2025-07-31 18:13 UTC (permalink / raw)
To: ALOK TIWARI
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, linux-staging,
linux-kernel
In-Reply-To: <25636f64-7b15-41d4-9ea6-216c22d84be4@oracle.com>
On Thu, Jul 31, 2025 at 10:03:46PM +0530, ALOK TIWARI wrote:
>
>
> On 7/31/2025 9:41 PM, Dan Carpenter wrote:
> > On Wed, Jul 23, 2025 at 12:24:31PM -0700, Alok Tiwari wrote:
> > > In drivers/staging/sm750fb/sm750_hw.c,
> > > the vertical and horizontal sync polarity assignments were incorrectly
> > > ordered.
> > > The assignment for modparm.vertical_sync_polarity was mistakenly using
> > > the FB_SYNC_HOR_HIGH_ACT bit instead of FB_SYNC_VERT_HIGH_ACT,
> > > and the horizontal polarity line was commented out or missing.
> > >
> > > This patch corrects the logic by properly assigning:
> > >
> > > vertical_sync_polarity -> from FB_SYNC_VERT_HIGH_ACT
> > > horizontal_sync_polarity -> from FB_SYNC_HOR_HIGH_ACT
> > >
> > > Please let me know your feedback.
> > > Thanks,
> > > Alok
> > > ---
> > > Fixes: 81dee67e215b ("staging: sm750fb: add sm750 to staging")
> > > Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
> > > ---
> >
> > Did you find this copy and paste bug by testing or reviewing the code?
> > How does this bug look like to a user? Please put that in your commit
> > message.
> >
> > This looks reasonable to me, but the patch is badly formatted.
> >
> > 1) It should say [PATCH] in the subject.
> > 2) The body of the email should be the commit message.
> > 3) the --- should only come after the Signed-off-by line.
> >
> > Try applying your patch with `git am` and review the log to see what I
> > mean.
> >
> > regards,
> > dan carpenter
> >
>
>
> Thanks Dan. By reviewing the code, I noticed some awkward assignment.
> However, I was not sure about this code, so instead of sending a formal
> patch, I just removed my SB and marked it as a [bug report].
> I will send formal patch with proper SB.
>
Good eye. Put "I noticed this in review and haven't tested under the
--- cut off line". If we apply it and it breaks then we've been
properly warned. Something needs to be changed, if it's only to rename
the variables or add a comment. But I think your patch is correct.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] fbdev: Fix vmalloc out-of-bounds write in fast_imageblit
From: Sravan Kumar Gundu @ 2025-07-31 20:36 UTC (permalink / raw)
To: deller, daniel
Cc: skhan, linux-fbdev, dri-devel, linux-kernel, linux-kernel-mentees,
Sravan Kumar Gundu, syzbot+c4b7aa0513823e2ea880
This issue triggers when a userspace program does an ioctl
FBIOPUT_CON2FBMAP by passing console number and frame buffer number.
Ideally this maps console to frame buffer and updates the screen if
console is visible.
As part of mapping it has to do resize of console according to frame
buffer info. if this resize fails and returns from vc_do_resize() and
continues further. At this point console and new frame buffer are mapped
and sets display vars. Despite failure still it continue to proceed
updating the screen at later stages where vc_data is related to previous
frame buffer and frame buffer info and display vars are mapped to new
frame buffer and eventully leading to out-of-bounds write in
fast_imageblit(). This bheviour is excepted only when fg_console is
equal to requested console which is a visible console and updates screen
with invalid struct references in fbcon_putcs().
Reported-and-tested-by: syzbot+c4b7aa0513823e2ea880@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c4b7aa0513823e2ea880
Signed-off-by: Sravan Kumar Gundu <sravankumarlpu@gmail.com>
---
drivers/video/fbdev/core/fbcon.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 3f7333dca508..2540d9046161 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -803,7 +803,8 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
fg_vc->vc_rows);
}
- update_screen(vc_cons[fg_console].d);
+ if (fg_console != unit)
+ update_screen(vc_cons[fg_console].d);
}
/**
@@ -1336,6 +1337,7 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
struct vc_data *svc;
struct fbcon_ops *ops = info->fbcon_par;
int rows, cols;
+ unsigned long ret = 0;
p = &fb_display[unit];
@@ -1386,11 +1388,10 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
cols /= vc->vc_font.width;
rows /= vc->vc_font.height;
- vc_resize(vc, cols, rows);
+ ret = vc_resize(vc, cols, rows);
- if (con_is_visible(vc)) {
+ if (con_is_visible(vc) && !ret)
update_screen(vc);
- }
}
static __inline__ void ywrap_up(struct vc_data *vc, int count)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] fbdev: core: Add checks for vc_resize failures
From: Helge Deller @ 2025-07-31 20:56 UTC (permalink / raw)
To: Zsolt Kajtar, linux-fbdev
In-Reply-To: <20250731171552.33585-1-soci@c64.rulez.org>
Hello Zsolt,
On 7/31/25 19:15, Zsolt Kajtar wrote:
> Whenever fbcon resizes the framebuffer the virtual console size is set
> to match the new geometry. This ensures that the content won't end up
> off-screen.
>
> But in very rare cases vc_resize() can fail. If one follows the syzbot
> monthly reports then this isn't all that rare because allocation
> fault injection can do that reliably. Usually the one in
> fbcon_set_disp.
Can you point to one such example?
> Handling these failures gracefully and rolling back the resize isn't
> trivial effort, at least for me. So the next best thing is to add
> BUG_ON() checks.
I understand that BUG_ON() seems handy, but it is not acceptable.
Having BUG_ON() makes it possible to trigger a complete kernel crash,
which we really need to avoid.
Helge
> In theory these checks shouldn't trigger normally. But when they do
> memory corruption is prevented.
>
> One check was left out in fbcon_startup.c, that's not a mistake. It
> needs more investigation as it triggers on boot for me.
>
> Signed-off-by: Zsolt Kajtar <soci@c64.rulez.org>
> ---
> drivers/video/fbdev/core/fbcon.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 2df480376..b9b65ae32 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1144,7 +1144,7 @@ static void fbcon_init(struct vc_data *vc, bool init)
> vc->vc_cols = new_cols;
> vc->vc_rows = new_rows;
> } else
> - vc_resize(vc, new_cols, new_rows);
> + BUG_ON(vc_resize(vc, new_cols, new_rows));
>
> if (logo)
> fbcon_prepare_logo(vc, info, cols, rows, new_cols, new_rows);
> @@ -1412,7 +1412,7 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
> rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> cols /= vc->vc_font.width;
> rows /= vc->vc_font.height;
> - vc_resize(vc, cols, rows);
> + BUG_ON(vc_resize(vc, cols, rows));
>
> if (con_is_visible(vc)) {
> update_screen(vc);
> @@ -2682,7 +2682,7 @@ static void fbcon_modechanged(struct fb_info *info)
> rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> cols /= vc->vc_font.width;
> rows /= vc->vc_font.height;
> - vc_resize(vc, cols, rows);
> + BUG_ON(vc_resize(vc, cols, rows));
> updatescrollmode(p, info, vc);
> scrollback_max = 0;
> scrollback_current = 0;
> @@ -2725,7 +2725,7 @@ static void fbcon_set_all_vcs(struct fb_info *info)
> rows = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> cols /= vc->vc_font.width;
> rows /= vc->vc_font.height;
> - vc_resize(vc, cols, rows);
> + BUG_ON(vc_resize(vc, cols, rows));
> }
>
> if (fg != -1)
^ permalink raw reply
* Re: [PATCH] backlight: pwm_bl: apply the initial backlight state with sane defaults
From: Uwe Kleine-König @ 2025-08-01 6:32 UTC (permalink / raw)
To: Michael Grzeschik
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Helge Deller, Pengutronix,
linux-pwm, dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20250731-blpwm-v1-1-0171fd31bff9@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]
Hallo Michael,
On Thu, Jul 31, 2025 at 10:47:18AM +0200, Michael Grzeschik wrote:
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index 237d3d3f3bb1a..5924e0b9f01e7 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -518,13 +518,6 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> if (!state.period && (data->pwm_period_ns > 0))
> state.period = data->pwm_period_ns;
>
> - ret = pwm_apply_might_sleep(pb->pwm, &state);
> - if (ret) {
> - dev_err_probe(&pdev->dev, ret,
> - "failed to apply initial PWM state");
> - goto err_alloc;
> - }
> -
> memset(&props, 0, sizeof(struct backlight_properties));
>
> if (data->levels) {
> @@ -582,6 +575,15 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> pb->lth_brightness = data->lth_brightness * (div_u64(state.period,
> pb->scale));
>
> + state.duty_cycle = compute_duty_cycle(pb, data->dft_brightness, &state);
> +
> + ret = pwm_apply_might_sleep(pb->pwm, &state);
> + if (ret) {
> + dev_err_probe(&pdev->dev, ret,
> + "failed to apply initial PWM state");
> + goto err_alloc;
> + }
> +
I wonder why the PWM is updated at all in .probe(). Wouldn't it be the
natural thing to keep the PWM configured as it was (in its reset default
state or how the bootloader set it up)?
Orthogonal to your change, while looking at the driver I wondered about:
bl = backlight_device_register(dev_name(&pdev->dev), &pdev->dev, pb,
&pwm_backlight_ops, &props);
if (IS_ERR(bl)) {
ret = dev_err_probe(&pdev->dev, PTR_ERR(bl),
"failed to register backlight\n");
goto err_alloc;
}
if (data->dft_brightness > data->max_brightness) {
dev_warn(&pdev->dev,
"invalid default brightness level: %u, using %u\n",
data->dft_brightness, data->max_brightness);
data->dft_brightness = data->max_brightness;
}
bl->props.brightness = data->dft_brightness;
bl->props.power = pwm_backlight_initial_power_state(pb);
backlight_update_status(bl);
Shoudn't setting data->dft_brightness, bl->props.brightness and
bl->props.power better happen before backlight_device_register()? Also
calling backlight_update_status() after backlight_device_register()
seems wrong to me, I'd claim the backend driver shouldn't call that.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [GIT PULL] fbdev fixes and updates for v6.17-rc1
From: Helge Deller @ 2025-08-02 11:04 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel, linux-fbdev, dri-devel
Hi Linus,
please pull the fbdev fixes and updates for 6.17-rc1:
One potential buffer overflow fix in the framebuffer registration function,
some fixes for the imxfb, nvidiafb and simplefb drivers, and a bunch of
cleanups for fbcon, kyrofb and svgalib.
Thanks,
Helge
----------------------------------------------------------------
The following changes since commit 89be9a83ccf1f88522317ce02f854f30d6115c41:
Linux 6.16-rc7 (2025-07-20 15:18:33 -0700)
are available in the Git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-6.17-rc1
for you to fetch changes up to 81b96e4aef9592493873507eec52eca68f0721ac:
fbcon: Use 'bool' where appopriate (2025-07-27 19:56:52 +0200)
----------------------------------------------------------------
fbdev fixes and cleanups for 6.17-rc1:
Framework fixes:
- fix potential buffer overflow in do_register_framebuffer() [Yongzhen Zhang]
Driver fixes:
- imxfb: prevent null-ptr-deref [Chenyuan Yang]
- nvidiafb: fix build on 32-bit ARCH=um [Johannes Berg]
- nvidiafb: add depends on HAS_IOPORT [Randy Dunlap]
- simplefb: Use of_reserved_mem_region_to_resource() for "memory-region" [Rob Herring]
Cleanups:
- fbcon: various code cleanups wrt blinking [Ville Syrjälä]
- kyrofb: Convert to devm_*() functions [Giovanni Di Santi]
- svgalib: Coding style cleanups [Darshan R.]
- Fix typo in Kconfig text for FB_DEVICE [Daniel Palmer]
----------------------------------------------------------------
Chenyuan Yang (1):
fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref
Daniel Palmer (1):
fbdev: Fix typo in Kconfig text for FB_DEVICE
Darshan R. (1):
fbdev: svgalib: Clean up coding style
Giovanni Di Santi (3):
fbdev: kyro: Add missing PCI memory region request
fbdev: kyro: Use devm_ioremap() for mmio registers
fbdev: kyro: Use devm_ioremap_wc() for screen mem
Johannes Berg (1):
fbdev: nvidiafb: fix build on 32-bit ARCH=um
Randy Dunlap (1):
fbdev: nvidiafb: add depends on HAS_IOPORT
Rob Herring (Arm) (1):
fbdev: simplefb: Use of_reserved_mem_region_to_resource() for "memory-region"
Ville Syrjälä (4):
fbcon: fbcon_cursor_noblink -> fbcon_cursor_blink
fbcon: fbcon_is_inactive() -> fbcon_is_active()
fbcon: Introduce get_{fg,bg}_color()
fbcon: Use 'bool' where appopriate
Yongzhen Zhang (1):
fbdev: fix potential buffer overflow in do_register_framebuffer()
drivers/video/fbdev/Kconfig | 2 +-
drivers/video/fbdev/core/Kconfig | 2 +-
drivers/video/fbdev/core/fbcon.c | 77 ++++++++++++++++------------
drivers/video/fbdev/core/fbmem.c | 3 ++
drivers/video/fbdev/core/svgalib.c | 95 ++++++++++++++++-------------------
drivers/video/fbdev/imxfb.c | 9 +++-
drivers/video/fbdev/kyro/fbdev.c | 24 ++++-----
drivers/video/fbdev/nvidia/nv_local.h | 2 +-
drivers/video/fbdev/simplefb.c | 17 ++-----
9 files changed, 116 insertions(+), 115 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] fbdev fixes and updates for v6.17-rc1
From: pr-tracker-bot @ 2025-08-02 17:02 UTC (permalink / raw)
To: Helge Deller; +Cc: Linus Torvalds, linux-kernel, linux-fbdev, dri-devel
In-Reply-To: <aI3wuBNWPyKhHbnC@p100>
The pull request you sent on Sat, 2 Aug 2025 13:04:24 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-6.17-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/eacf91b0c78a7113844830ed65ebf543eb9052c5
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH] fbdev: core: Add checks for vc_resize failures
From: Kajtár Zsolt @ 2025-08-02 17:24 UTC (permalink / raw)
To: Helge Deller, linux-fbdev
In-Reply-To: <59be2951-79a2-45c4-b59d-6b7fc500b4cc@gmx.de>
[-- Attachment #1.1: Type: text/plain, Size: 1136 bytes --]
Hello Helge!
>> But in very rare cases vc_resize() can fail. If one follows the syzbot
>> monthly reports then this isn't all that rare because allocation
>> fault injection can do that reliably. Usually the one in
>> fbcon_set_disp.
>
> Can you point to one such example?
https://syzkaller.appspot.com/text?tag=CrashLog&x=11742d63980000
>> Handling these failures gracefully and rolling back the resize isn't
>> trivial effort, at least for me. So the next best thing is to add
>> BUG_ON() checks.
>
> I understand that BUG_ON() seems handy, but it is not acceptable.
> Having BUG_ON() makes it possible to trigger a complete kernel crash,
> which we really need to avoid.
Yes, suspected that it's not the right approach (checkpatch.pl warned)
but haven't got a reply when I mentioned the idea a month ago and so
thought it's still better than the other alternative.
However I've just realized that there was a better solution only 20
minutes earlier by Sravan Kumar Gundu for the same problem.
Could have avoided sending mine, it was so close :( Please disregard my
patch.
--
-soci-
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: Fix vmalloc out-of-bounds write in fast_imageblit
From: Helge Deller @ 2025-08-02 19:30 UTC (permalink / raw)
To: Sravan Kumar Gundu, daniel
Cc: skhan, linux-fbdev, dri-devel, linux-kernel, linux-kernel-mentees,
syzbot+c4b7aa0513823e2ea880
In-Reply-To: <20250731203618.25973-1-sravankumarlpu@gmail.com>
On 7/31/25 22:36, Sravan Kumar Gundu wrote:
> This issue triggers when a userspace program does an ioctl
> FBIOPUT_CON2FBMAP by passing console number and frame buffer number.
> Ideally this maps console to frame buffer and updates the screen if
> console is visible.
>
> As part of mapping it has to do resize of console according to frame
> buffer info. if this resize fails and returns from vc_do_resize() and
> continues further. At this point console and new frame buffer are mapped
> and sets display vars. Despite failure still it continue to proceed
> updating the screen at later stages where vc_data is related to previous
> frame buffer and frame buffer info and display vars are mapped to new
> frame buffer and eventully leading to out-of-bounds write in
> fast_imageblit(). This bheviour is excepted only when fg_console is
> equal to requested console which is a visible console and updates screen
> with invalid struct references in fbcon_putcs().
>
> Reported-and-tested-by: syzbot+c4b7aa0513823e2ea880@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=c4b7aa0513823e2ea880
> Signed-off-by: Sravan Kumar Gundu <sravankumarlpu@gmail.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
applied to fbdev git tree.
Thanks!
Helge
^ permalink raw reply
* [PATCH] fbdev: Use vmalloc_array to simplify code
From: Qianfeng Rong @ 2025-08-04 7:24 UTC (permalink / raw)
To: Helge Deller, Qianfeng Rong, Thomas Zimmermann, Jason Andryuk,
Roger Pau Monné, linux-fbdev, dri-devel, linux-kernel
Use vmalloc_array() instead of vmalloc() to simplify the function
xenfb_probe().
Compile-tested only.
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
---
drivers/video/fbdev/xen-fbfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/xen-fbfront.c b/drivers/video/fbdev/xen-fbfront.c
index c90f48ebb15e..d8f3bfb2dd6c 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -390,7 +390,7 @@ static int xenfb_probe(struct xenbus_device *dev,
info->nr_pages = (fb_size + PAGE_SIZE - 1) >> PAGE_SHIFT;
- info->gfns = vmalloc(array_size(sizeof(unsigned long), info->nr_pages));
+ info->gfns = vmalloc_array(info->nr_pages, sizeof(unsigned long));
if (!info->gfns)
goto error_nomem;
--
2.34.1
^ permalink raw reply related
* [GIT PULL] fbdev last fixes for v6.17-rc1
From: Helge Deller @ 2025-08-07 11:21 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel, linux-fbdev, dri-devel
Hi Linus,
please pull two more fbdev fixes for 6.17-rc1:
One patch reverts a previous stable tree patch which broke the VGA console,
the other fixes an out-of-bounds access bug which may happen during console
resizing when a console is mapped to a frame buffer.
Both patches are tagged for stable series.
Thanks,
Helge
----------------------------------------------------------------
The following changes since commit 038d61fd642278bab63ee8ef722c50d10ab01e8f:
Linux 6.16 (2025-07-27 14:26:38 -0700)
are available in the Git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-6.17-rc1-2
for you to fetch changes up to e4fc307d8e24f122402907ebf585248cad52841d:
Revert "vgacon: Add check for vc_origin address range in vgacon_scroll()" (2025-08-02 21:47:33 +0200)
----------------------------------------------------------------
fbdev fixes for 6.17-rc1:
- Revert a patch which broke VGA console.
- Fix an out-of-bounds access bug which may happen during console
resizing when a console is mapped to a frame buffer.
----------------------------------------------------------------
Helge Deller (1):
Revert "vgacon: Add check for vc_origin address range in vgacon_scroll()"
Sravan Kumar Gundu (1):
fbdev: Fix vmalloc out-of-bounds write in fast_imageblit
drivers/video/console/vgacon.c | 2 +-
drivers/video/fbdev/core/fbcon.c | 9 +++++----
2 files changed, 6 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [GIT PULL] fbdev last fixes for v6.17-rc1
From: pr-tracker-bot @ 2025-08-08 3:59 UTC (permalink / raw)
To: Helge Deller; +Cc: Linus Torvalds, linux-kernel, linux-fbdev, dri-devel
In-Reply-To: <aJSMS8PhMMe0NL63@p100>
The pull request you sent on Thu, 7 Aug 2025 13:21:47 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git tags/fbdev-for-6.17-rc1-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2939a792c47e55fda4ae5b7f9ff47e34ddcef61a
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH] fbdev: Use vmalloc_array to simplify code
From: Helge Deller @ 2025-08-08 8:54 UTC (permalink / raw)
To: Qianfeng Rong, Thomas Zimmermann, Jason Andryuk,
Roger Pau Monné, linux-fbdev, dri-devel
In-Reply-To: <20250804072413.143154-1-rongqianfeng@vivo.com>
On 8/4/25 09:24, Qianfeng Rong wrote:
> Use vmalloc_array() instead of vmalloc() to simplify the function
> xenfb_probe().
>
> Compile-tested only.
>
> Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
> ---
> drivers/video/fbdev/xen-fbfront.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied.
Thanks!
Helge
^ permalink raw reply
* [PATCH] fbdev: s3fb: Implement powersave for S3 FB
From: Zsolt Kajtar @ 2025-08-10 15:47 UTC (permalink / raw)
To: linux-fbdev; +Cc: Zsolt Kajtar
This patch implements power saving for S3 cards by powering down the
RAMDAC and stopping MCLK and DCLK while the card is supposed to be
suspended.
The RAMDAC is also disabled while the screen is blanked and the DCLK
in stopped while in DPMS power off.
The practical difference it makes is that on a machine with such a
card the display will be placed in DPMS power off while standby is
activated (due to stopped DCLK). Same like when using other cards with
implemented power saving functionality.
Without it on my setup the connected display powers up and stays that
way showing VT63 while in standby. Sort of annoying as before standby
it's specifically placed into DPMS off in Xorg for a while.
The used functionality should exists for sure on Trio32 to Aurora64V
(according to the documentation) so I think it's generally applicable.
I'm using this on S3 Trio 3D and S3 Virge DX.
Signed-off-by: Zsolt Kajtar <soci@c64.rulez.org>
---
drivers/video/fbdev/s3fb.c | 37 +++++++++++++++++++------------------
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/video/fbdev/s3fb.c b/drivers/video/fbdev/s3fb.c
index ff84106ec..9b3fca9b3 100644
--- a/drivers/video/fbdev/s3fb.c
+++ b/drivers/video/fbdev/s3fb.c
@@ -988,34 +988,30 @@ static int s3fb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
static int s3fb_blank(int blank_mode, struct fb_info *info)
{
struct s3fb_info *par = info->par;
+ u8 data;
+
+ data = (blank_mode == FB_BLANK_UNBLANK) ? 0x00 : 0x20;
+ svga_wseq_mask(par->state.vgabase, 0x01, data, 0x20);
+ svga_wseq_mask(par->state.vgabase, 0x18, data, 0x20);
switch (blank_mode) {
- case FB_BLANK_UNBLANK:
- fb_dbg(info, "unblank\n");
- svga_wcrt_mask(par->state.vgabase, 0x56, 0x00, 0x06);
- svga_wseq_mask(par->state.vgabase, 0x01, 0x00, 0x20);
- break;
- case FB_BLANK_NORMAL:
- fb_dbg(info, "blank\n");
- svga_wcrt_mask(par->state.vgabase, 0x56, 0x00, 0x06);
- svga_wseq_mask(par->state.vgabase, 0x01, 0x20, 0x20);
+ default:
+ data = 0x00;
break;
case FB_BLANK_HSYNC_SUSPEND:
- fb_dbg(info, "hsync\n");
- svga_wcrt_mask(par->state.vgabase, 0x56, 0x02, 0x06);
- svga_wseq_mask(par->state.vgabase, 0x01, 0x20, 0x20);
+ data = 0x02;
break;
case FB_BLANK_VSYNC_SUSPEND:
- fb_dbg(info, "vsync\n");
- svga_wcrt_mask(par->state.vgabase, 0x56, 0x04, 0x06);
- svga_wseq_mask(par->state.vgabase, 0x01, 0x20, 0x20);
+ data = 0x04;
break;
case FB_BLANK_POWERDOWN:
- fb_dbg(info, "sync down\n");
- svga_wcrt_mask(par->state.vgabase, 0x56, 0x06, 0x06);
- svga_wseq_mask(par->state.vgabase, 0x01, 0x20, 0x20);
+ data = 0x06;
break;
}
+ svga_wcrt_mask(par->state.vgabase, 0x56, data, 0x06);
+
+ data = (blank_mode == FB_BLANK_POWERDOWN) ? 0x01 : 0x00;
+ svga_wseq_mask(par->state.vgabase, 0x14, data, 0x01);
return 0;
}
@@ -1445,6 +1441,8 @@ static int __maybe_unused s3_pci_suspend(struct device *dev)
}
fb_set_suspend(info, 1);
+ svga_wseq_mask(par->state.vgabase, 0x18, 0x20, 0x20);
+ svga_wseq_mask(par->state.vgabase, 0x14, 0x03, 0x03);
mutex_unlock(&(par->open_lock));
console_unlock();
@@ -1471,6 +1469,9 @@ static int __maybe_unused s3_pci_resume(struct device *dev)
return 0;
}
+ vga_wseq(par->state.vgabase, 0x08, 0x06);
+ svga_wseq_mask(par->state.vgabase, 0x18, 0x00, 0x20);
+ svga_wseq_mask(par->state.vgabase, 0x14, 0x00, 0x03);
s3fb_set_par(info);
fb_set_suspend(info, 0);
--
2.30.2
^ permalink raw reply related
* Re: [PATCH 2/4] backlight: add max25014atg backlight
From: Daniel Thompson @ 2025-08-11 14:15 UTC (permalink / raw)
To: maudspierings
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, dri-devel,
linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel, MaudSpieringsmaudspierings
In-Reply-To: <20250725-max25014-v1-2-0e8cce92078e@gocontroll.com>
On Fri, Jul 25, 2025 at 01:09:24PM +0200, Maud Spierings via B4 Relay wrote:
> From: Maud Spierings <maudspierings@gocontroll.com>
>
> The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> with intgrated boost controller.
>
> Signed-off-by: Maud Spierings maudspierings@gocontroll.com
> ---
> MAINTAINERS | 2 +
> drivers/video/backlight/Kconfig | 7 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/max25014.c | 449 +++++++++++++++++++++++++++++++++
> include/linux/platform_data/max25014.h | 24 ++
Who else included this header file? Can the code here simply be included
in the C file?
> diff --git a/drivers/video/backlight/max25014.c b/drivers/video/backlight/max25014.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..371b6017953ae5955f4dfef921980dfdedd65d85
> --- /dev/null
> +++ b/drivers/video/backlight/max25014.c
> @@ -0,0 +1,449 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Backlight driver for Maxim MAX25014
> + *
> + * Copyright (C) 2025 GOcontroll B.V.
> + * Author: Maud Spierings <maudspierings@gocontroll.com>
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/platform_data/max25014.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +#define MAX25014_ISET_DEFAULT_100 11U
> +#define MAX_BRIGHTNESS (100U)
> +#define MIN_BRIGHTNESS (0U)
> +#define TON_MAX (130720U) /* @153Hz */
> +#define TON_STEP (1307U) /* @153Hz */
> +#define TON_MIN (0U)
> +
> +#define MAX25014_DEV_ID (0x00U)
> +#define MAX25014_REV_ID (0x01U)
> +#define MAX25014_ISET (0x02U)
> +#define MAX25014_IMODE (0x03U)
> +#define MAX25014_TON1H (0x04U)
> +#define MAX25014_TON1L (0x05U)
> +#define MAX25014_TON2H (0x06U)
> +#define MAX25014_TON2L (0x07U)
> +#define MAX25014_TON3H (0x08U)
> +#define MAX25014_TON3L (0x09U)
> +#define MAX25014_TON4H (0x0AU)
> +#define MAX25014_TON4L (0x0BU)
> +#define MAX25014_TON_1_4_LSB (0x0CU)
> +#define MAX25014_SETTING (0x12U)
> +#define MAX25014_DISABLE (0x13U)
> +#define MAX25014_BSTMON (0x14U)
> +#define MAX25014_IOUT1 (0x15U)
> +#define MAX25014_IOUT2 (0x16U)
> +#define MAX25014_IOUT3 (0x17U)
> +#define MAX25014_IOUT4 (0x18U)
> +#define MAX25014_OPEN (0x1BU)
> +#define MAX25014_SHORT_GND (0x1CU)
> +#define MAX25014_SHORT_LED (0x1DU)
> +#define MAX25014_MASK (0x1EU)
> +#define MAX25014_DIAG (0x1FU)
Forcing all these constants to be unsigned is unusual. Is it really
needed?
> +#define MAX25014_IMODE_HDIM BIT(2)
> +#define MAX25014_ISET_ENABLE BIT(5)
> +#define MAX25014_ISET_PSEN BIT(4)
> +#define MAX25014_DIAG_HW_RST BIT(2)
> +#define MAX25014_SETTING_FPWM GENMASK(6, 4)
> +
> +struct max25014;
This is redundant. Remove.
> +
> +struct max25014 {
> + const char *chipname;
Why keep this value around? It is only used during the probe.
> + struct i2c_client *client;
> + struct backlight_device *bl;
> + struct device *dev;
It is necessary to cache this, is it just a copy of client->dev)?
> + struct regmap *regmap;
> + struct max25014_platform_data *pdata;
> + struct gpio_desc *enable;
> + struct regulator *vin; /* regulator for boost converter Vin rail */
> +};
> +
> +static const struct regmap_config max25014_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = MAX25014_DIAG,
> +};
> +
> +/**
> + * @brief get the bit mask for the DISABLE register.
> + *
> + * @param strings the led string configuration array.
> + * @return uint8_t bits to set in the register.
> + */
> +static uint8_t strings_mask(struct max25014 *maxim)
> +{
> + uint8_t res, i;
> +
> + for (i = 0; i < 4; i++) {
> + if (maxim->pdata->strings[i] == 0)
> + res |= 1 << i;
> + }
> + return res;
Could this converison have happened during DT parsing?
> +}
> +
> +/**
> + * @brief control the brightness with i2c registers
> + *
> + * @param regmap trivial
> + * @param brt brightness
> + * @return int
> + */
> +static int max25014_register_control(struct regmap *regmap, uint32_t brt)
> +{
> + uint32_t reg = TON_STEP * brt;
> + int ret;
> + /*
> + * 18 bit number lowest, 2 bits in first register,
> + * next lowest 8 in the L register, next 8 in the H register
> + * Seemingly setting the strength of only one string controls all of
> + * them, individual settings don't affect the outcome.
> + */
> +
> + ret = regmap_write(regmap, MAX25014_TON_1_4_LSB, reg & 0b00000011);
> + if (ret != 0)
> + return ret;
> + ret = regmap_write(regmap, MAX25014_TON1L, (reg >> 2) & 0b11111111);
> + if (ret != 0)
> + return ret;
> + return regmap_write(regmap, MAX25014_TON1H, (reg >> 10) & 0b11111111);
> +}
> +
> +static int max25014_check_errors(struct max25014 *maxim)
> +{
> + uint8_t i;
> + int ret;
> + uint32_t val;
> +
> + ret = regmap_read(maxim->regmap, MAX25014_OPEN, &val);
> + if (ret != 0)
> + return ret;
> + if (val > 0) {
> + dev_err(maxim->dev, "Open led strings detected on:\n");
> + for (i = 0; i < 4; i++) {
> + if (val & 1 << i)
> + dev_err(maxim->dev, "string %d\n", i + 1);
> + }
> + return -EIO;
> + }
> +
> + ret = regmap_read(maxim->regmap, MAX25014_SHORT_GND, &val);
> + if (ret != 0)
> + return ret;
> + if (val > 0) {
> + dev_err(maxim->dev, "Short to ground detected on:\n");
> + for (i = 0; i < 4; i++) {
> + if (val & 1 << i)
> + dev_err(maxim->dev, "string %d\n", i + 1);
> + }
> + return -EIO;
> + }
> +
> + ret = regmap_read(maxim->regmap, MAX25014_SHORT_GND, &val);
> + if (ret != 0)
> + return ret;
> + if (val > 0) {
> + dev_err(maxim->dev, "Shorted led detected on:\n");
> + for (i = 0; i < 4; i++) {
> + if (val & 1 << i)
> + dev_err(maxim->dev, "string %d\n", i + 1);
> + }
> + return -EIO;
> + }
> +
> + ret = regmap_read(maxim->regmap, MAX25014_DIAG, &val);
> + if (ret != 0)
> + return ret;
> + /*
> + * The HW_RST bit always starts at 1 after power up.
> + * It is reset on first read, does not indicate an error.
> + */
> + if (val > 0 && val != MAX25014_DIAG_HW_RST) {
> + if (val & 0b1)
> + dev_err(maxim->dev, "Overtemperature shutdown\n");
> + if (val & 0b10)
> + dev_warn(maxim->dev,
> + "Chip is getting too hot (>125C)\n");
> + if (val & 0b1000)
> + dev_err(maxim->dev, "Boost converter overvoltage\n");
> + if (val & 0b10000)
> + dev_err(maxim->dev, "Boost converter undervoltage\n");
> + if (val & 0b100000)
> + dev_err(maxim->dev, "IREF out of range\n");
> + return -EIO;
> + }
> + return 0;
> +}
> +
> +/*
> + * 1. disable unused strings
> + * 2. set dim mode
> + * 3. set initial brightness
> + * 4. set setting register
> + * 5. enable the backlight
> + */
> +static int max25014_configure(struct max25014 *maxim)
> +{
> + int ret;
> + uint32_t val;
> +
> + ret = regmap_write(maxim->regmap, MAX25014_DISABLE,
> + strings_mask(maxim));
> + if (ret != 0)
> + return ret;
> +
> + ret = regmap_write(maxim->regmap, MAX25014_IMODE, MAX25014_IMODE_HDIM);
> + if (ret != 0)
> + return ret;
> +
> + max25014_register_control(maxim->regmap,
> + maxim->pdata->initial_brightness);
> +
> + ret = regmap_read(maxim->regmap, MAX25014_SETTING, &val);
> + if (ret != 0)
> + return ret;
> +
> + ret = regmap_write(
> + maxim->regmap, MAX25014_SETTING,
> + val & ~MAX25014_SETTING_FPWM);
> + if (ret != 0)
> + return ret;
> +
> + ret = regmap_write(maxim->regmap, MAX25014_ISET,
> + maxim->pdata->iset | MAX25014_ISET_ENABLE | MAX25014_ISET_PSEN);
> + return ret;
> +}
> +
> +static int max25014_update_status(struct backlight_device *bl_dev)
> +{
> + struct max25014 *maxim = bl_get_data(bl_dev);
> +
> + if (bl_dev->props.state & BL_CORE_SUSPENDED)
> + bl_dev->props.brightness = 0;
> +
> + return max25014_register_control(maxim->regmap, bl_dev->props.brightness);
> +}
> +
> +static const struct backlight_ops max25014_bl_ops = {
> + .options = BL_CORE_SUSPENDRESUME,
> + .update_status = max25014_update_status,
> +};
> +
> +static int max25014_backlight_register(struct max25014 *maxim)
> +{
> + struct backlight_device *bl;
> + struct backlight_properties props;
> + struct max25014_platform_data *pdata = maxim->pdata;
> +
> + memset(&props, 0, sizeof(props));
> + props.type = BACKLIGHT_PLATFORM;
> + props.max_brightness = MAX_BRIGHTNESS;
> +
> + if (pdata->initial_brightness > props.max_brightness)
> + pdata->initial_brightness = props.max_brightness;
Handle this during DT parsing.
> +
> + props.brightness = pdata->initial_brightness;
> +
> + bl = devm_backlight_device_register(maxim->dev, maxim->chipname, maxim->dev,
> + maxim, &max25014_bl_ops, &props);
> + if (IS_ERR(bl))
> + return PTR_ERR(bl);
> +
> + maxim->bl = bl;
> +
> + return 0;
> +}
Can max25014_backlight_register() be moved into the probe function?
There is no special control flow here so this function doesn't make the
probe function any simpler.
> +
> +#ifdef CONFIG_OF
> +static int max25014_parse_dt(struct max25014 *maxim)
> +{
> + struct device *dev = maxim->dev;
> + struct device_node *node = dev->of_node;
> + struct max25014_platform_data *pdata;
> +
> + int res;
> +
> + if (!node) {
> + dev_err(dev, "no platform data\n");
> + return -EINVAL;
> + }
> +
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + res = of_property_count_u32_elems(node, "maxim,strings");
> + if (res == 4) {
> + of_property_read_u32_array(node, "maxim,strings", pdata->strings, 4);
> + } else {
> + dev_err(dev, "strings property not correctly defined\n");
> + return -EINVAL;
> + }
> +
> + pdata->initial_brightness = 50U;
> + of_property_read_u32(node, "default-brightness", &pdata->initial_brightness);
> + pdata->iset = MAX25014_ISET_DEFAULT_100;
> + of_property_read_u32(node, "maxim,iset", &pdata->iset);
> +
> + if (pdata->iset < 0 || pdata->iset > 15) {
> + dev_err(dev,
> + "Invalid iset, should be a value from 0-15, entered was %d\n",
> + pdata->iset);
> + return -EINVAL;
> + }
> +
> + if (pdata->initial_brightness < 0 || pdata->initial_brightness > 100) {
> + dev_err(dev,
> + "Invalid initial brightness, should be a value from 0-100, entered was %d\n",
> + pdata->initial_brightness);
> + return -EINVAL;
> + }
> +
> + maxim->pdata = pdata;
> +
> + return 0;
> +}
> +#else
> +static int max25014_parse_dt(struct max25014 *maxim)
> +{
> + dev_err(maxim->dev,
> + "CONFIG_OF not configured, unable to parse devicetree");
> + return -EINVAL;
> +}
What is the point of this method? New drivers shouldn't support platform
data so CONFIG_OF is required for this driver to work at all.
> +#endif
> +
> +static int max25014_probe(struct i2c_client *cl)
> ...
Daniel.
^ permalink raw reply
* [syzbot] Monthly fbdev report (Aug 2025)
From: syzbot @ 2025-08-12 12:44 UTC (permalink / raw)
To: deller, dri-devel, linux-fbdev, linux-kernel, syzkaller-bugs
Hello fbdev maintainers/developers,
This is a 31-day syzbot report for the fbdev subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/fbdev
During the period, 0 new issues were detected and 1 were fixed.
In total, 4 issues are still open and 27 have already been fixed.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 225 Yes KASAN: slab-out-of-bounds Read in fbcon_prepare_logo
https://syzkaller.appspot.com/bug?extid=0c815b25cdb3678e7083
<2> 47 No KASAN: vmalloc-out-of-bounds Write in fillrect
https://syzkaller.appspot.com/bug?extid=7a63ce155648954e749b
<3> 34 Yes KASAN: global-out-of-bounds Read in bit_putcs (3)
https://syzkaller.appspot.com/bug?extid=793cf822d213be1a74f2
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* [PATCH] Cleared out formatting warnings/errors for drivers/staging/sm750fb
From: Willem Grant @ 2025-08-15 1:17 UTC (permalink / raw)
To: linux-fbdev; +Cc: Willem Grant
Signed-off-by: Willem Grant <willemgrant@mailfence.com>
---
drivers/staging/sm750fb/sm750.c | 54 +++++-----
drivers/staging/sm750fb/sm750.h | 20 ++--
drivers/staging/sm750fb/sm750_accel.c | 148 +++++++++++++-------------
drivers/staging/sm750fb/sm750_accel.h | 42 ++++----
drivers/staging/sm750fb/sm750_hw.c | 28 ++---
5 files changed, 148 insertions(+), 144 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 3659af7e519d..321bc19f342c 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -33,7 +33,7 @@
static int g_hwcursor = 1;
static int g_noaccel;
static int g_nomtrr;
-static const char *g_fbmode[] = {NULL, NULL};
+static const char * const g_fbmode[] = {NULL, NULL};
static const char *g_def_fbmode = "1024x768-32@60";
static char *g_settings;
static int g_dualview;
@@ -121,8 +121,8 @@ static int lynxfb_ops_cursor(struct fb_info *info, struct fb_cursor *fbcursor)
sm750_hw_cursor_disable(cursor);
if (fbcursor->set & FB_CUR_SETSIZE)
sm750_hw_cursor_set_size(cursor,
- fbcursor->image.width,
- fbcursor->image.height);
+ fbcursor->image.width,
+ fbcursor->image.height);
if (fbcursor->set & FB_CUR_SETPOS)
sm750_hw_cursor_set_pos(cursor,
@@ -538,7 +538,11 @@ static int lynxfb_ops_setcolreg(unsigned int regno,
}
if (info->var.grayscale)
- red = green = blue = (red * 77 + green * 151 + blue * 28) >> 8;
+ int gray = (red * 77 + green * 151 + blue * 28) >> 8;
+
+ red = gray;
+ green = gray;
+ blue = gray;
if (var->bits_per_pixel == 8 &&
info->fix.visual == FB_VISUAL_PSEUDOCOLOR) {
@@ -619,27 +623,27 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
output->paths = sm750_pnc;
crtc->channel = sm750_primary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
pr_info("use simul primary mode\n");
break;
case sm750_simul_sec:
output->paths = sm750_pnc;
crtc->channel = sm750_secondary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
break;
case sm750_dual_normal:
if (par->index == 0) {
output->paths = sm750_panel;
crtc->channel = sm750_primary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
} else {
output->paths = sm750_crt;
crtc->channel = sm750_secondary;
/* not consider of padding stuffs for o_screen,need fix */
crtc->o_screen = sm750_dev->vidmem_size >> 1;
- crtc->v_screen = sm750_dev->pvMem + crtc->o_screen;
+ crtc->v_screen = sm750_dev->pv_mem + crtc->o_screen;
}
break;
case sm750_dual_swap:
@@ -647,7 +651,7 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
output->paths = sm750_panel;
crtc->channel = sm750_secondary;
crtc->o_screen = 0;
- crtc->v_screen = sm750_dev->pvMem;
+ crtc->v_screen = sm750_dev->pv_mem;
} else {
output->paths = sm750_crt;
crtc->channel = sm750_primary;
@@ -655,7 +659,7 @@ static int sm750fb_set_drv(struct lynxfb_par *par)
* need fix
*/
crtc->o_screen = sm750_dev->vidmem_size >> 1;
- crtc->v_screen = sm750_dev->pvMem + crtc->o_screen;
+ crtc->v_screen = sm750_dev->pv_mem + crtc->o_screen;
}
break;
default:
@@ -735,7 +739,7 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
"kernel HELPERS prepared vesa_modes",
};
- static const char *fixId[2] = {
+ static const char *fix_id[2] = {
"sm750_fb1", "sm750_fb2",
};
@@ -759,14 +763,14 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
* must be set after crtc member initialized
*/
crtc->cursor.offset = crtc->o_screen + crtc->vidmem_size - 1024;
- crtc->cursor.mmio = sm750_dev->pvReg +
+ crtc->cursor.mmio = sm750_dev->pv_reg +
0x800f0 + (int)crtc->channel * 0x140;
pr_info("crtc->cursor.mmio = %p\n", crtc->cursor.mmio);
crtc->cursor.max_h = 64;
crtc->cursor.max_w = 64;
crtc->cursor.size = crtc->cursor.max_h * crtc->cursor.max_w * 2 / 8;
- crtc->cursor.vstart = sm750_dev->pvMem + crtc->cursor.offset;
+ crtc->cursor.vstart = sm750_dev->pv_mem + crtc->cursor.offset;
memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
if (!g_hwcursor)
@@ -857,7 +861,7 @@ static int lynxfb_set_fbinfo(struct fb_info *info, int index)
fix->ywrapstep = crtc->ywrapstep;
fix->accel = FB_ACCEL_SMI;
- strscpy(fix->id, fixId[index], sizeof(fix->id));
+ strscpy(fix->id, fix_id[index], sizeof(fix->id));
fix->smem_start = crtc->o_screen + sm750_dev->vidmem_start;
pr_info("fix->smem_start = %lx\n", fix->smem_start);
@@ -913,12 +917,12 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
swap = 0;
- sm750_dev->initParm.chip_clk = 0;
- sm750_dev->initParm.mem_clk = 0;
- sm750_dev->initParm.master_clk = 0;
- sm750_dev->initParm.powerMode = 0;
- sm750_dev->initParm.setAllEngOff = 0;
- sm750_dev->initParm.resetMemory = 1;
+ sm750_dev->init_parm.chip_clk = 0;
+ sm750_dev->init_parm.mem_clk = 0;
+ sm750_dev->init_parm.master_clk = 0;
+ sm750_dev->init_parm.power_mode = 0;
+ sm750_dev->init_parm.set_all_eng_off = 0;
+ sm750_dev->init_parm.reset_memory = 1;
/* defaultly turn g_hwcursor on for both view */
g_hwcursor = 3;
@@ -937,9 +941,9 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
} else if (!strncmp(opt, "nocrt", strlen("nocrt"))) {
sm750_dev->nocrt = 1;
} else if (!strncmp(opt, "36bit", strlen("36bit"))) {
- sm750_dev->pnltype = sm750_doubleTFT;
+ sm750_dev->pnltype = sm750_double_tft;
} else if (!strncmp(opt, "18bit", strlen("18bit"))) {
- sm750_dev->pnltype = sm750_dualTFT;
+ sm750_dev->pnltype = sm750_dual_tft;
} else if (!strncmp(opt, "24bit", strlen("24bit"))) {
sm750_dev->pnltype = sm750_24TFT;
} else if (!strncmp(opt, "nohwc0", strlen("nohwc0"))) {
@@ -1085,7 +1089,7 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
sm750_dev->mtrr.vram = arch_phys_wc_add(sm750_dev->vidmem_start,
sm750_dev->vidmem_size);
- memset_io(sm750_dev->pvMem, 0, sm750_dev->vidmem_size);
+ memset_io(sm750_dev->pv_mem, 0, sm750_dev->vidmem_size);
pci_set_drvdata(pdev, sm750_dev);
@@ -1116,8 +1120,8 @@ static void lynxfb_pci_remove(struct pci_dev *pdev)
sm750fb_framebuffer_release(sm750_dev);
arch_phys_wc_del(sm750_dev->mtrr.vram);
- iounmap(sm750_dev->pvReg);
- iounmap(sm750_dev->pvMem);
+ iounmap(sm750_dev->pv_reg);
+ iounmap(sm750_dev->pv_mem);
kfree(g_settings);
}
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index d7f40efe3a2c..866353796b86 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -14,8 +14,8 @@
enum sm750_pnltype {
sm750_24TFT = 0, /* 24bit tft */
- sm750_dualTFT = 2, /* dual 18 bit tft */
- sm750_doubleTFT = 1, /* 36 bit double pixel tft */
+ sm750_dual_tft = 2, /* dual 18 bit tft */
+ sm750_double_tft = 1, /* 36 bit double pixel tft */
};
/* vga channel is not concerned */
@@ -39,20 +39,20 @@ enum sm750_path {
};
struct init_status {
- ushort powerMode;
+ ushort power_mode;
/* below three clocks are in unit of MHZ*/
ushort chip_clk;
ushort mem_clk;
ushort master_clk;
- ushort setAllEngOff;
- ushort resetMemory;
+ ushort set_all_eng_off;
+ ushort reset_memory;
};
struct lynx_accel {
/* base virtual address of DPR registers */
- volatile unsigned char __iomem *dprBase;
+ volatile unsigned char __iomem *dpr_base;
/* base virtual address of de data port */
- volatile unsigned char __iomem *dpPortBase;
+ volatile unsigned char __iomem *dp_port_base;
/* function pointers */
void (*de_init)(struct lynx_accel *accel);
@@ -97,12 +97,12 @@ struct sm750_dev {
unsigned long vidreg_start;
__u32 vidmem_size;
__u32 vidreg_size;
- void __iomem *pvReg;
- unsigned char __iomem *pvMem;
+ void __iomem *pv_reg;
+ unsigned char __iomem *pv_mem;
/* locks*/
spinlock_t slock;
- struct init_status initParm;
+ struct init_status init_parm;
enum sm750_pnltype pnltype;
enum sm750_dataflow dataflow;
int nocrt;
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 44b9e3fe3a41..b02b7b06d49c 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -17,19 +17,19 @@
#include "sm750.h"
#include "sm750_accel.h"
-static inline void write_dpr(struct lynx_accel *accel, int offset, u32 regValue)
+static inline void write_dpr(struct lynx_accel *accel, int offset, u32 reg_value)
{
- writel(regValue, accel->dprBase + offset);
+ writel(reg_value, accel->dpr_base + offset);
}
static inline u32 read_dpr(struct lynx_accel *accel, int offset)
{
- return readl(accel->dprBase + offset);
+ return readl(accel->dpr_base + offset);
}
-static inline void write_dpPort(struct lynx_accel *accel, u32 data)
+static inline void write_dp_port(struct lynx_accel *accel, u32 data)
{
- writel(data, accel->dpPortBase);
+ writel(data, accel->dp_port_base);
}
void sm750_hw_de_init(struct lynx_accel *accel)
@@ -85,11 +85,11 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt)
}
int sm750_hw_fillrect(struct lynx_accel *accel,
- u32 base, u32 pitch, u32 Bpp,
+ u32 base, u32 pitch, u32 bpp,
u32 x, u32 y, u32 width, u32 height,
u32 color, u32 rop)
{
- u32 deCtrl;
+ u32 de_ctrl;
if (accel->de_wait() != 0) {
/*
@@ -102,14 +102,14 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
write_dpr(accel, DE_PITCH,
- ((pitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((pitch / bpp << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (pitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (pitch / bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
write_dpr(accel, DE_WINDOW_WIDTH,
- ((pitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((pitch / bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (pitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
+ (pitch / bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr44 */
write_dpr(accel, DE_FOREGROUND, color); /* DPR14 */
@@ -121,24 +121,24 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
((width << DE_DIMENSION_X_SHIFT) & DE_DIMENSION_X_MASK) |
(height & DE_DIMENSION_Y_ET_MASK)); /* dpr8 */
- deCtrl = DE_CONTROL_STATUS | DE_CONTROL_LAST_PIXEL |
+ de_ctrl = DE_CONTROL_STATUS | DE_CONTROL_LAST_PIXEL |
DE_CONTROL_COMMAND_RECTANGLE_FILL | DE_CONTROL_ROP_SELECT |
(rop & DE_CONTROL_ROP_MASK); /* dpr0xc */
- write_dpr(accel, DE_CONTROL, deCtrl);
+ write_dpr(accel, DE_CONTROL, de_ctrl);
return 0;
}
/**
* sm750_hw_copyarea
* @accel: Acceleration device data
- * @sBase: Address of source: offset in frame buffer
- * @sPitch: Pitch value of source surface in BYTE
+ * @s_base: Address of source: offset in frame buffer
+ * @s_pitch: Pitch value of source surface in BYTE
* @sx: Starting x coordinate of source surface
* @sy: Starting y coordinate of source surface
- * @dBase: Address of destination: offset in frame buffer
- * @dPitch: Pitch value of destination surface in BYTE
- * @Bpp: Color depth of destination surface
+ * @d_base: Address of destination: offset in frame buffer
+ * @d_pitch: Pitch value of destination surface in BYTE
+ * @bpp: Color depth of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
* @width: width of rectangle in pixel value
@@ -146,21 +146,21 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @rop2: ROP value
*/
int sm750_hw_copyarea(struct lynx_accel *accel,
- unsigned int sBase, unsigned int sPitch,
+ unsigned int s_base, unsigned int s_pitch,
unsigned int sx, unsigned int sy,
- unsigned int dBase, unsigned int dPitch,
- unsigned int Bpp, unsigned int dx, unsigned int dy,
+ unsigned int d_base, unsigned int d_pitch,
+ unsigned int bpp, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2)
{
- unsigned int nDirection, de_ctrl;
+ unsigned int n_direction, de_ctrl;
- nDirection = LEFT_TO_RIGHT;
+ n_direction = LEFT_TO_RIGHT;
/* Direction of ROP2 operation: 1 = Left to Right, (-1) = Right to Left */
de_ctrl = 0;
/* If source and destination are the same surface, need to check for overlay cases */
- if (sBase == dBase && sPitch == dPitch) {
+ if (s_base == d_base && s_pitch == d_pitch) {
/* Determine direction of operation */
if (sy < dy) {
/* +----------+
@@ -173,7 +173,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* +----------+
*/
- nDirection = BOTTOM_TO_TOP;
+ n_direction = BOTTOM_TO_TOP;
} else if (sy > dy) {
/* +----------+
* |D |
@@ -185,7 +185,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* +----------+
*/
- nDirection = TOP_TO_BOTTOM;
+ n_direction = TOP_TO_BOTTOM;
} else {
/* sy == dy */
@@ -198,7 +198,7 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* +------+---+------+
*/
- nDirection = RIGHT_TO_LEFT;
+ n_direction = RIGHT_TO_LEFT;
} else {
/* sx > dx */
@@ -210,12 +210,12 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* +------+---+------+
*/
- nDirection = LEFT_TO_RIGHT;
+ n_direction = LEFT_TO_RIGHT;
}
}
}
- if ((nDirection == BOTTOM_TO_TOP) || (nDirection == RIGHT_TO_LEFT)) {
+ if ((n_direction == BOTTOM_TO_TOP) || (n_direction == RIGHT_TO_LEFT)) {
sx += width - 1;
sy += height - 1;
dx += width - 1;
@@ -234,14 +234,14 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* It is an address offset (128 bit aligned)
* from the beginning of frame buffer.
*/
- write_dpr(accel, DE_WINDOW_SOURCE_BASE, sBase); /* dpr40 */
+ write_dpr(accel, DE_WINDOW_SOURCE_BASE, s_base); /* dpr40 */
/*
* 2D Destination Base.
* It is an address offset (128 bit aligned)
* from the beginning of frame buffer.
*/
- write_dpr(accel, DE_WINDOW_DESTINATION_BASE, dBase); /* dpr44 */
+ write_dpr(accel, DE_WINDOW_DESTINATION_BASE, d_base); /* dpr44 */
/*
* Program pitch (distance between the 1st points of two adjacent lines).
@@ -249,9 +249,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* pixel values. Need Byte to pixel conversion.
*/
write_dpr(accel, DE_PITCH,
- ((dPitch / Bpp << DE_PITCH_DESTINATION_SHIFT) &
+ ((d_pitch / bpp << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (sPitch / Bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (s_pitch / bpp & DE_PITCH_SOURCE_MASK)); /* dpr10 */
/*
* Screen Window width in Pixels.
@@ -259,9 +259,9 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
* for a given point.
*/
write_dpr(accel, DE_WINDOW_WIDTH,
- ((dPitch / Bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((d_pitch / bpp << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (sPitch / Bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
+ (s_pitch / bpp & DE_WINDOW_WIDTH_SRC_MASK)); /* dpr3c */
if (accel->de_wait() != 0)
return -1;
@@ -277,14 +277,14 @@ int sm750_hw_copyarea(struct lynx_accel *accel,
(height & DE_DIMENSION_Y_ET_MASK)); /* dpr08 */
de_ctrl = (rop2 & DE_CONTROL_ROP_MASK) | DE_CONTROL_ROP_SELECT |
- ((nDirection == RIGHT_TO_LEFT) ? DE_CONTROL_DIRECTION : 0) |
+ ((n_direction == RIGHT_TO_LEFT) ? DE_CONTROL_DIRECTION : 0) |
DE_CONTROL_COMMAND_BITBLT | DE_CONTROL_STATUS;
write_dpr(accel, DE_CONTROL, de_ctrl); /* dpr0c */
return 0;
}
-static unsigned int deGetTransparency(struct lynx_accel *accel)
+static unsigned int de_get_transparency(struct lynx_accel *accel)
{
unsigned int de_ctrl;
@@ -299,38 +299,38 @@ static unsigned int deGetTransparency(struct lynx_accel *accel)
/**
* sm750_hw_imageblit
* @accel: Acceleration device data
- * @pSrcbuf: pointer to start of source buffer in system memory
- * @srcDelta: Pitch value (in bytes) of the source buffer, +ive means top down
+ * @p_srcbuf: pointer to start of source buffer in system memory
+ * @src_delta: Pitch value (in bytes) of the source buffer, +ive means top down
* and -ive mean button up
- * @startBit: Mono data can start at any bit in a byte, this value should be
+ * @start_bit: Mono data can start at any bit in a byte, this value should be
* 0 to 7
- * @dBase: Address of destination: offset in frame buffer
- * @dPitch: Pitch value of destination surface in BYTE
- * @bytePerPixel: Color depth of destination surface
+ * @d_base: Address of destination: offset in frame buffer
+ * @d_pitch: Pitch value of destination surface in BYTE
+ * @byte_per_pixel: Color depth of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
* @width: width of rectangle in pixel value
* @height: height of rectangle in pixel value
- * @fColor: Foreground color (corresponding to a 1 in the monochrome data
- * @bColor: Background color (corresponding to a 0 in the monochrome data
+ * @f_color: Foreground color (corresponding to a 1 in the monochrome data
+ * @b_color: Background color (corresponding to a 0 in the monochrome data
* @rop2: ROP value
*/
-int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
- u32 srcDelta, u32 startBit, u32 dBase, u32 dPitch,
- u32 bytePerPixel, u32 dx, u32 dy, u32 width,
- u32 height, u32 fColor, u32 bColor, u32 rop2)
+int sm750_hw_imageblit(struct lynx_accel *accel, const char *p_srcbuf,
+ u32 src_delta, u32 start_bit, u32 d_base, u32 d_pitch,
+ u32 byte_per_pixel, u32 dx, u32 dy, u32 width,
+ u32 height, u32 f_color, u32 b_color, u32 rop2)
{
- unsigned int ulBytesPerScan;
- unsigned int ul4BytesPerScan;
- unsigned int ulBytesRemain;
+ unsigned int ul_bytes_per_scan;
+ unsigned int ul_4bytes_per_scan;
+ unsigned int ul_bytes_remain;
unsigned int de_ctrl = 0;
- unsigned char ajRemain[4];
+ unsigned char aj_remain[4];
int i, j;
- startBit &= 7; /* Just make sure the start bit is within legal range */
- ulBytesPerScan = (width + startBit + 7) / 8;
- ul4BytesPerScan = ulBytesPerScan & ~3;
- ulBytesRemain = ulBytesPerScan & 3;
+ start_bit &= 7; /* Just make sure the start bit is within legal range */
+ ul_bytes_per_scan = (width + start_bit + 7) / 8;
+ ul_4bytes_per_scan = ul_bytes_per_scan & ~3;
+ ul_bytes_remain = ul_bytes_per_scan & 3;
if (accel->de_wait() != 0)
return -1;
@@ -345,7 +345,7 @@ int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
* It is an address offset (128 bit aligned)
* from the beginning of frame buffer.
*/
- write_dpr(accel, DE_WINDOW_DESTINATION_BASE, dBase);
+ write_dpr(accel, DE_WINDOW_DESTINATION_BASE, d_base);
/*
* Program pitch (distance between the 1st points of two adjacent
@@ -353,9 +353,9 @@ int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
* register uses pixel values. Need Byte to pixel conversion.
*/
write_dpr(accel, DE_PITCH,
- ((dPitch / bytePerPixel << DE_PITCH_DESTINATION_SHIFT) &
+ ((d_pitch / byte_per_pixel << DE_PITCH_DESTINATION_SHIFT) &
DE_PITCH_DESTINATION_MASK) |
- (dPitch / bytePerPixel & DE_PITCH_SOURCE_MASK)); /* dpr10 */
+ (d_pitch / byte_per_pixel & DE_PITCH_SOURCE_MASK)); /* dpr10 */
/*
* Screen Window width in Pixels.
@@ -363,17 +363,17 @@ int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
* in frame buffer for a given point.
*/
write_dpr(accel, DE_WINDOW_WIDTH,
- ((dPitch / bytePerPixel << DE_WINDOW_WIDTH_DST_SHIFT) &
+ ((d_pitch / byte_per_pixel << DE_WINDOW_WIDTH_DST_SHIFT) &
DE_WINDOW_WIDTH_DST_MASK) |
- (dPitch / bytePerPixel & DE_WINDOW_WIDTH_SRC_MASK));
+ (d_pitch / byte_per_pixel & DE_WINDOW_WIDTH_SRC_MASK));
/*
* Note: For 2D Source in Host Write, only X_K1_MONO field is needed,
* and Y_K2 field is not used.
- * For mono bitmap, use startBit for X_K1.
+ * For mono bitmap, use start_bit for X_K1.
*/
write_dpr(accel, DE_SOURCE,
- (startBit << DE_SOURCE_X_K1_SHIFT) &
+ (start_bit << DE_SOURCE_X_K1_SHIFT) &
DE_SOURCE_X_K1_MONO_MASK); /* dpr00 */
write_dpr(accel, DE_DESTINATION,
@@ -384,28 +384,28 @@ int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
((width << DE_DIMENSION_X_SHIFT) & DE_DIMENSION_X_MASK) |
(height & DE_DIMENSION_Y_ET_MASK)); /* dpr08 */
- write_dpr(accel, DE_FOREGROUND, fColor);
- write_dpr(accel, DE_BACKGROUND, bColor);
+ write_dpr(accel, DE_FOREGROUND, f_color);
+ write_dpr(accel, DE_BACKGROUND, b_color);
de_ctrl = (rop2 & DE_CONTROL_ROP_MASK) |
DE_CONTROL_ROP_SELECT | DE_CONTROL_COMMAND_HOST_WRITE |
DE_CONTROL_HOST | DE_CONTROL_STATUS;
- write_dpr(accel, DE_CONTROL, de_ctrl | deGetTransparency(accel));
+ write_dpr(accel, DE_CONTROL, de_ctrl | de_get_transparency(accel));
/* Write MONO data (line by line) to 2D Engine data port */
for (i = 0; i < height; i++) {
/* For each line, send the data in chunks of 4 bytes */
- for (j = 0; j < (ul4BytesPerScan / 4); j++)
- write_dpPort(accel, *(unsigned int *)(pSrcbuf + (j * 4)));
+ for (j = 0; j < (ul_4bytes_per_scan / 4); j++)
+ write_dp_port(accel, *(unsigned int *)(p_srcbuf + (j * 4)));
- if (ulBytesRemain) {
- memcpy(ajRemain, pSrcbuf + ul4BytesPerScan,
- ulBytesRemain);
- write_dpPort(accel, *(unsigned int *)ajRemain);
+ if (ul_bytes_remain) {
+ memcpy(aj_remain, p_srcbuf + ul_4bytes_per_scan,
+ ul_bytes_remain);
+ write_dp_port(accel, *(unsigned int *)aj_remain);
}
- pSrcbuf += srcDelta;
+ p_srcbuf += src_delta;
}
return 0;
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
index 2c79cb730a0a..dca5c14d2f8e 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -190,19 +190,19 @@ void sm750_hw_set2dformat(struct lynx_accel *accel, int fmt);
void sm750_hw_de_init(struct lynx_accel *accel);
int sm750_hw_fillrect(struct lynx_accel *accel,
- u32 base, u32 pitch, u32 Bpp,
+ u32 base, u32 pitch, u32 bpp,
u32 x, u32 y, u32 width, u32 height,
u32 color, u32 rop);
/**
* sm750_hm_copyarea
- * @sBase: Address of source: offset in frame buffer
- * @sPitch: Pitch value of source surface in BYTE
+ * @s_base: Address of source: offset in frame buffer
+ * @s_pitch: Pitch value of source surface in BYTE
* @sx: Starting x coordinate of source surface
* @sy: Starting y coordinate of source surface
- * @dBase: Address of destination: offset in frame buffer
- * @dPitch: Pitch value of destination surface in BYTE
- * @Bpp: Color depth of destination surface
+ * @d_base: Address of destination: offset in frame buffer
+ * @d_pitch: Pitch value of destination surface in BYTE
+ * @bpp: Color depth of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
* @width: width of rectangle in pixel value
@@ -210,34 +210,34 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
* @rop2: ROP value
*/
int sm750_hw_copyarea(struct lynx_accel *accel,
- unsigned int sBase, unsigned int sPitch,
+ unsigned int s_base, unsigned int s_pitch,
unsigned int sx, unsigned int sy,
- unsigned int dBase, unsigned int dPitch,
- unsigned int Bpp, unsigned int dx, unsigned int dy,
+ unsigned int d_base, unsigned int d_pitch,
+ unsigned int bpp, unsigned int dx, unsigned int dy,
unsigned int width, unsigned int height,
unsigned int rop2);
/**
* sm750_hw_imageblit
- * @pSrcbuf: pointer to start of source buffer in system memory
- * @srcDelta: Pitch value (in bytes) of the source buffer, +ive means top down
+ * @p_srcbuf: pointer to start of source buffer in system memory
+ * @src_delta: Pitch value (in bytes) of the source buffer, +ive means top down
*>----- and -ive mean button up
- * @startBit: Mono data can start at any bit in a byte, this value should be
+ * @start_bit: Mono data can start at any bit in a byte, this value should be
*>----- 0 to 7
- * @dBase: Address of destination: offset in frame buffer
- * @dPitch: Pitch value of destination surface in BYTE
- * @bytePerPixel: Color depth of destination surface
+ * @d_base: Address of destination: offset in frame buffer
+ * @d_pitch: Pitch value of destination surface in BYTE
+ * @byte_per_pixel: Color depth of destination surface
* @dx: Starting x coordinate of destination surface
* @dy: Starting y coordinate of destination surface
* @width: width of rectangle in pixel value
* @height: height of rectangle in pixel value
- * @fColor: Foreground color (corresponding to a 1 in the monochrome data
- * @bColor: Background color (corresponding to a 0 in the monochrome data
+ * @f_color: Foreground color (corresponding to a 1 in the monochrome data
+ * @b_color: Background color (corresponding to a 0 in the monochrome data
* @rop2: ROP value
*/
-int sm750_hw_imageblit(struct lynx_accel *accel, const char *pSrcbuf,
- u32 srcDelta, u32 startBit, u32 dBase, u32 dPitch,
- u32 bytePerPixel, u32 dx, u32 dy, u32 width,
- u32 height, u32 fColor, u32 bColor, u32 rop2);
+int sm750_hw_imageblit(struct lynx_accel *accel, const char *p_srcbuf,
+ u32 src_delta, u32 start_bit, u32 d_base, u32 d_pitch,
+ u32 byte_per_pixel, u32 dx, u32 dy, u32 width,
+ u32 height, u32 f_color, u32 b_color, u32 rop2);
#endif
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 7119b67efe11..9e69f3387e08 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -49,19 +49,19 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
}
/* now map mmio and vidmem */
- sm750_dev->pvReg =
+ sm750_dev->pv_reg =
ioremap(sm750_dev->vidreg_start, sm750_dev->vidreg_size);
- if (!sm750_dev->pvReg) {
+ if (!sm750_dev->pv_reg) {
pr_err("mmio failed\n");
ret = -EFAULT;
goto exit;
}
- pr_info("mmio virtual addr = %p\n", sm750_dev->pvReg);
+ pr_info("mmio virtual addr = %p\n", sm750_dev->pv_reg);
- sm750_dev->accel.dprBase = sm750_dev->pvReg + DE_BASE_ADDR_TYPE1;
- sm750_dev->accel.dpPortBase = sm750_dev->pvReg + DE_PORT_ADDR_TYPE1;
+ sm750_dev->accel.dpr_base = sm750_dev->pv_reg + DE_BASE_ADDR_TYPE1;
+ sm750_dev->accel.dp_port_base = sm750_dev->pv_reg + DE_PORT_ADDR_TYPE1;
- mmio750 = sm750_dev->pvReg;
+ mmio750 = sm750_dev->pv_reg;
sm750_set_chip_type(sm750_dev->devid, sm750_dev->revid);
sm750_dev->vidmem_start = pci_resource_start(pdev, 0);
@@ -76,15 +76,15 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
sm750_dev->vidmem_start, sm750_dev->vidmem_size);
/* reserve the vidmem space of smi adaptor */
- sm750_dev->pvMem =
+ sm750_dev->pv_mem =
ioremap_wc(sm750_dev->vidmem_start, sm750_dev->vidmem_size);
- if (!sm750_dev->pvMem) {
- iounmap(sm750_dev->pvReg);
+ if (!sm750_dev->pv_mem) {
+ iounmap(sm750_dev->pv_reg);
pr_err("Map video memory failed\n");
ret = -EFAULT;
goto exit;
}
- pr_info("video memory vaddr = %p\n", sm750_dev->pvMem);
+ pr_info("video memory vaddr = %p\n", sm750_dev->pv_mem);
exit:
return ret;
}
@@ -93,7 +93,7 @@ int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
{
struct init_status *parm;
- parm = &sm750_dev->initParm;
+ parm = &sm750_dev->init_parm;
if (parm->chip_clk == 0)
parm->chip_clk = (sm750_get_chip_type() == SM750LE) ?
DEFAULT_SM750LE_CHIP_CLOCK :
@@ -104,7 +104,7 @@ int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
if (parm->master_clk == 0)
parm->master_clk = parm->chip_clk / 3;
- ddk750_init_hw((struct initchip_param *)&sm750_dev->initParm);
+ ddk750_init_hw((struct initchip_param *)&sm750_dev->init_parm);
/* for sm718, open pci burst */
if (sm750_dev->devid == 0x718) {
poke32(SYSTEM_CTRL,
@@ -136,10 +136,10 @@ int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
switch (sm750_dev->pnltype) {
case sm750_24TFT:
break;
- case sm750_doubleTFT:
+ case sm750_double_tft:
val |= PANEL_DISPLAY_CTRL_DOUBLE_PIXEL;
break;
- case sm750_dualTFT:
+ case sm750_dual_tft:
val |= PANEL_DISPLAY_CTRL_DUAL_DISPLAY;
break;
}
--
2.50.1
^ permalink raw reply related
* Re: [PATCH] fbdev: s3fb: Implement powersave for S3 FB
From: Helge Deller @ 2025-08-15 9:09 UTC (permalink / raw)
To: Zsolt Kajtar, linux-fbdev
In-Reply-To: <20250810154754.16211-1-soci@c64.rulez.org>
On 8/10/25 17:47, Zsolt Kajtar wrote:
> This patch implements power saving for S3 cards by powering down the
> RAMDAC and stopping MCLK and DCLK while the card is supposed to be
> suspended.
>
> The RAMDAC is also disabled while the screen is blanked and the DCLK
> in stopped while in DPMS power off.
>
> The practical difference it makes is that on a machine with such a
> card the display will be placed in DPMS power off while standby is
> activated (due to stopped DCLK). Same like when using other cards with
> implemented power saving functionality.
>
> Without it on my setup the connected display powers up and stays that
> way showing VT63 while in standby. Sort of annoying as before standby
> it's specifically placed into DPMS off in Xorg for a while.
>
> The used functionality should exists for sure on Trio32 to Aurora64V
> (according to the documentation) so I think it's generally applicable.
> I'm using this on S3 Trio 3D and S3 Virge DX.
>
> Signed-off-by: Zsolt Kajtar <soci@c64.rulez.org>
> ---
> drivers/video/fbdev/s3fb.c | 37 +++++++++++++++++++------------------
> 1 file changed, 19 insertions(+), 18 deletions(-)
applied.
Thanks!
Helge
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox