* Re: [PATCH] fbdev: udlfb: validate vendor descriptor items
From: Helge Deller @ 2026-07-18 18:26 UTC (permalink / raw)
To: Pengpeng Hou, Bernie Thompson; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260706093038.80131-1-pengpeng@iscas.ac.cn>
On 7/6/26 11:30, Pengpeng Hou wrote:
> dlfb_parse_vendor_descriptor() walks key-length-value items inside the
> DisplayLink vendor descriptor.
>
> Require each item to contain its key, length and declared value bytes
> before reading item-specific fields such as max_area.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/video/fbdev/udlfb.c | 22 ++++++++++++++++------
> 1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
> index fdbb8671a810..e78d6f95c9c5 100644
> --- a/drivers/video/fbdev/udlfb.c
> +++ b/drivers/video/fbdev/udlfb.c
> @@ -1586,19 +1586,29 @@ static int dlfb_parse_vendor_descriptor(struct dlfb_data *dlfb,
> desc += 5; /* the fixed header we've already parsed */
>
> while (desc < desc_end) {
> + char *value;
> u8 length;
> u16 key;
>
> - key = *desc++;
> - key |= (u16)*desc++ << 8;
> + if (desc_end - desc < sizeof(key) + sizeof(length))
> + goto unrecognized;
> +
> + key = get_unaligned_le16(desc);
Is there a reason why you switch to unconditional little-endian reads?
Is this "vendor descriptor" always little-endian?
If yes, then your patch is probably correct.
If not, I think your patch will most likely break big-endian machines.
Helge
> + desc += sizeof(key);
> length = *desc++;
>
> + if (length > desc_end - desc)
> + goto unrecognized;
> +
> + value = desc;
> switch (key) {
> case 0x0200: { /* max_area */
> - u32 max_area = *desc++;
> - max_area |= (u32)*desc++ << 8;
> - max_area |= (u32)*desc++ << 16;
> - max_area |= (u32)*desc++ << 24;
> + u32 max_area;
> +
> + if (length < sizeof(max_area))
> + goto unrecognized;
> +
> + max_area = get_unaligned_le32(value);
> dev_warn(&intf->dev,
> "DL chip limited to %d pixel modes\n",
> max_area);
^ permalink raw reply
* Re: [PATCH] fbdev: uvesafb: unregister connector callback on init failure
From: Helge Deller @ 2026-07-18 18:40 UTC (permalink / raw)
To: Myeonghun Pak, Michal Januszewski
Cc: linux-fbdev, dri-devel, linux-kernel, stable, Ijae Kim
In-Reply-To: <20260701111224.48646-1-mhun512@gmail.com>
On 7/1/26 13:12, Myeonghun Pak wrote:
> uvesafb_init() registers the v86d connector callback before registering
> the platform driver. If platform_driver_register() fails, the function
> returns the error directly and leaves the connector callback registered.
>
> The later platform-device failure path already unregisters the callback.
> Add the same cleanup before the final return when platform-driver
> registration fails.
>
> This issue was identified during our ongoing static-analysis research while
> reviewing kernel code.
>
> Fixes: 8bdb3a2d7df4 ("uvesafb: the driver core")
> Cc: stable@vger.kernel.org
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> ---
> drivers/video/fbdev/uvesafb.c | 2 ++
> 1 file changed, 2 insertions(+)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] fbdev: tdfxfb: fix PCI enable cleanup with pcim_enable_device()
From: Helge Deller @ 2026-07-18 18:48 UTC (permalink / raw)
To: Myeonghun Pak; +Cc: linux-fbdev, dri-devel, linux-kernel, Ijae Kim
In-Reply-To: <20260701112147.55048-1-mhun512@gmail.com>
On 7/1/26 13:21, Myeonghun Pak wrote:
> tdfxfb_probe() enables the PCI device with pci_enable_device(), but
> several failure paths after that point return without disabling it. The
> framebuffer_alloc() failure path returns -ENOMEM directly, and the later
> shared out_err path releases the framebuffer and returns -ENXIO without
> balancing the PCI enable state.
>
> The successful probe path has the same imbalance because tdfxfb_remove()
> releases the framebuffer, mappings and regions, but never calls
> pci_disable_device().
>
> Use pcim_enable_device() so the PCI device is disabled automatically on
> probe failure and driver detach.
>
> This issue was identified during our ongoing static-analysis research while
> reviewing kernel code.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
> ---
> drivers/video/fbdev/tdfxfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] fb: omap2: dsi: do not copy isr table
From: Helge Deller @ 2026-07-18 18:51 UTC (permalink / raw)
To: Andreas Kemnade
Cc: linux-omap, linux-fbdev, dri-devel, linux-kernel, sashiko-bot
In-Reply-To: <20260702-fbomap-uaf-fix-v1-1-6417edf9d3e7@kemnade.info>
On 7/2/26 17:50, Andreas Kemnade wrote:
> To te able to unregister stuff from isrs, the corresponding table was
> copied. Nobody seems to unregister stuff that way, so it does not help.
> But there are stack-allocated objects passed to these isrs giving chances
> of UAF of these objects if irqs are unregistered while they are handled,
> so better do not copy that table.
>
> Suggested-by: sashiko-bot@kernel.org
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> ---
> Fix for drm variant fo driver:
> https://lore.kernel.org/lkml/20260702-dsi-uaf-v2-1-dbb4aa0f0b8e@kemnade.info/
> ---
> drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 9 +--------
> 1 file changed, 1 insertion(+), 8 deletions(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] fbdev: sstfb: add missing MODULE_DEVICE_TABLE()
From: Helge Deller @ 2026-07-18 18:55 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <20260705001509.66078-1-pengpeng@iscas.ac.cn>
On 7/5/26 02:14, Pengpeng Hou wrote:
> The driver has a match table for the pci bus wired into its driver
> structure, but the table is not exported with MODULE_DEVICE_TABLE().
>
> Add the missing MODULE_DEVICE_TABLE() entry so module alias information
> is generated for automatic module loading.
>
> This is a source-level fix. It does not claim dynamic hardware
> reproduction; the evidence is the driver-owned match table, its use by
> the driver registration structure, and the missing module alias
> publication.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/video/fbdev/sstfb.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/sstfb.c b/drivers/video/fbdev/sstfb.c
> index 2ea947f57efb..2745557822f7 100644
> --- a/drivers/video/fbdev/sstfb.c
> +++ b/drivers/video/fbdev/sstfb.c
> @@ -1492,6 +1492,7 @@ static const struct pci_device_id sstfb_id_tbl[] = {
> .driver_data = ID_VOODOO2, },
> { 0 },
> };
> +MODULE_DEVICE_TABLE(pci, sstfb_id_tbl);
I'm not sure if it was intentionally not added, maybe because it's an
add-on card for which people should manually load the driver.
Anyway, I'm adding this patch now to the fbdev git tree and will find out if
someone reports a regression...
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] fbdev: udlfb: validate vendor descriptor items
From: Helge Deller @ 2026-07-18 18:59 UTC (permalink / raw)
To: Pengpeng Hou, Bernie Thompson; +Cc: linux-fbdev, dri-devel, linux-kernel
In-Reply-To: <db0698e3-9f45-4123-8b6d-ff59bcdcf25f@gmx.de>
On 7/18/26 20:26, Helge Deller wrote:
> On 7/6/26 11:30, Pengpeng Hou wrote:
>> dlfb_parse_vendor_descriptor() walks key-length-value items inside the
>> DisplayLink vendor descriptor.
>>
>> Require each item to contain its key, length and declared value bytes
>> before reading item-specific fields such as max_area.
>>
>> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
>> ---
>> drivers/video/fbdev/udlfb.c | 22 ++++++++++++++++------
>> 1 file changed, 16 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
>> index fdbb8671a810..e78d6f95c9c5 100644
>> --- a/drivers/video/fbdev/udlfb.c
>> +++ b/drivers/video/fbdev/udlfb.c
>> @@ -1586,19 +1586,29 @@ static int dlfb_parse_vendor_descriptor(struct dlfb_data *dlfb,
>> desc += 5; /* the fixed header we've already parsed */
>> while (desc < desc_end) {
>> + char *value;
>> u8 length;
>> u16 key;
>> - key = *desc++;
>> - key |= (u16)*desc++ << 8;
>> + if (desc_end - desc < sizeof(key) + sizeof(length))
>> + goto unrecognized;
>> +
>> + key = get_unaligned_le16(desc);
>
> Is there a reason why you switch to unconditional little-endian reads?
> Is this "vendor descriptor" always little-endian?
> If yes, then your patch is probably correct.
> If not, I think your patch will most likely break big-endian machines.
Please ignore my comments above.
I should have looked more closely.
Your patch is of course correct!
The patch is now added to fbdev git tree.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v2 0/7] vga_switcheroo, drm: Push fbcon handling into DRM clients
From: Helge Deller @ 2026-07-18 19:08 UTC (permalink / raw)
To: Thomas Zimmermann; +Cc: dri-devel, linux-fbdev
In-Reply-To: <20260709092215.168172-1-tzimmermann@suse.de>
Hi Thomas,
On 7/9/26 11:15, Thomas Zimmermann wrote:
> Vga_switcheroo currently invokes fb_switch_outputs() to inform fbcon
> about switching of the physical outputs among framebuffer devices. But
> new DRM clients to not use fbdev/fbcon and might require their own
> vga_switcheroo support. Let's strictly separate them from each other.
>
> Remove fbdev/fbcon from vga_switcheroo. Introduce a pre_switch callback
> for vga_switcheroo clients to do the fbcon update. Allows for removing
> all direct interactions between vga_switcheroo and fbdev/fbcon.
>
> There are only four drivers that support vga_switcheroo: amdgpu,
> radeon, i915 and nouveau. Update each of them with the new callback.
> When vga_switcheroo now invokes pre_switch, each DRM driver forwards
> to aquire_outputs and lets the DRM clients handle the new outputs.
>
> At the same time, push the fbcon update into DRM's client for fbdev
> emulation. Do this with the new DRM client callback acquire_outputs,
> so that other clients can have their own handling of vga_switcheroo.
>
> Also replace the existing reprobe hook with post_switch for symetry.
> For nouveau, this is merely a rename of the helper function. The other
> drivers dor not implement reprobe.
>
> Tested with radeon on a notebook with Radeon HD 4225 and HD 5430.
>
> v2:
> - implement all of pre_switch in a single commit to avoid possible
> deadlock in intermediate state (Sashiko)
> - fix erroneous docs (Sashiko)
>
> Thomas Zimmermann (7):
> drm/edid: Include <linux/fb.h>
> drm/client: Add acquire_outputs callback; implement for fbdev
> emulation
> vga_switcheroo: Add pre_switch callback to client ops
> vga_switcheroo: Add post_switch callback to client ops
> drm: Implement struct vga_switcheroo_client_ops.pre_switch
> drm: Implement vga_switcheroo_client_ops.post_switch
> vga-switcheroo: Remove unused interfaces
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 ++++-
> drivers/gpu/drm/clients/drm_fbdev_client.c | 23 ++++++++----
> drivers/gpu/drm/drm_client_event.c | 18 ++++++++++
> drivers/gpu/drm/drm_edid.c | 1 +
> drivers/gpu/drm/i915/i915_switcheroo.c | 11 +++++-
> drivers/gpu/drm/nouveau/nouveau_vga.c | 28 +++++++++------
> drivers/gpu/drm/radeon/radeon_device.c | 9 ++++-
> drivers/gpu/vga/vga_switcheroo.c | 41 +++++-----------------
> drivers/video/fbdev/core/fbcon.c | 8 -----
> include/drm/drm_client.h | 14 ++++++++
> include/drm/drm_client_event.h | 3 ++
> include/linux/vga_switcheroo.h | 29 ++++++++-------
> 12 files changed, 121 insertions(+), 73 deletions(-)
You may add a
Acked-by: Helge Deller <deller@gmx.de>
to the series.
Just in case you want me to take the series through the fbdev git tree,
please let me know.
Helge
^ permalink raw reply
* [PATCH] fonts: fixup font.h kernel-doc warnings
From: Randy Dunlap @ 2026-07-18 19:13 UTC (permalink / raw)
To: dri-devel; +Cc: Randy Dunlap, Helge Deller, Thomas Zimmermann, linux-fbdev
Use the typedef keyword when describing a typedef.
Add the missing function return value for font_glyph_size().
Warning: include/linux/font.h:84 cannot understand function prototype:
'typedef const unsigned char font_data_t;'
Warning: include/linux/font.h:53 No description found for return value
of 'font_glyph_size'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Helge Deller <deller@gmx.de>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: linux-fbdev@vger.kernel.org
include/linux/font.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-next-20260717.orig/include/linux/font.h
+++ linux-next-20260717/include/linux/font.h
@@ -49,6 +49,8 @@ static inline unsigned int font_glyph_pi
* scanlines, which is usually the glyph's height in scanlines. Fonts
* coming from user space can sometimes have a different vertical pitch
* with empty scanlines between two adjacent glyphs.
+ *
+ * Returns: the number of bytes per glyph
*/
static inline unsigned int font_glyph_size(unsigned int width, unsigned int vpitch)
{
@@ -60,7 +62,7 @@ static inline unsigned int font_glyph_si
*/
/**
- * font_data_t - Raw font data
+ * typedef font_data_t - Raw font data
*
* Values of type font_data_t store a pointer to raw font data. The format
* is monochrome. Each bit sets a pixel of a stored glyph. Font data does
^ permalink raw reply
* Re: [PATCH] fbdev: pvr2fb: correct user pointer annotation and sentinel initializer
From: Helge Deller @ 2026-07-18 19:33 UTC (permalink / raw)
To: Florian Fuchs, John Paul Adrian Glaubitz
Cc: Uwe Kleine-König, linux-fbdev, dri-devel, linux-kernel,
kernel test robot
In-Reply-To: <20260713101638.600333-1-fuchsfl@gmail.com>
On 7/13/26 12:16, Florian Fuchs wrote:
> Add __user annotation to buf, as it is passed as a user pointer in
> pin_user_pages_fast(). Use an empty initializer for the sentinel
> board-table entry to avoid initializing a function pointer with an
> integer literal.
>
> Fixes: 5f566c0ac51c ("fbdev: pvr2fb: Fix leftover reference to ONCHIP_NR_DMA_CHANNELS")
I think this Fixes tag is wrong.
The problem has been there forever.
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202607131247.fpQ6eTc7-lkp@intel.com/
> Signed-off-by: Florian Fuchs <fuchsfl@gmail.com>
> ---
> Not sure, if we do such changes, but as I received a test robot email, I
> leave it up to you all :) (I also compiled and tested the change)
>
> drivers/video/fbdev/pvr2fb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Patch applied to fbdev git tree.
Thanks for fixing!
Helge
^ permalink raw reply
* Re: [PATCH] fonts: fixup font.h kernel-doc warnings
From: Helge Deller @ 2026-07-18 19:39 UTC (permalink / raw)
To: Randy Dunlap, dri-devel; +Cc: Thomas Zimmermann, linux-fbdev
In-Reply-To: <20260718191326.1907423-1-rdunlap@infradead.org>
On 7/18/26 21:13, Randy Dunlap wrote:
> Use the typedef keyword when describing a typedef.
> Add the missing function return value for font_glyph_size().
>
> Warning: include/linux/font.h:84 cannot understand function prototype:
> 'typedef const unsigned char font_data_t;'
> Warning: include/linux/font.h:53 No description found for return value
> of 'font_glyph_size'
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Cc: Helge Deller <deller@gmx.de>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: linux-fbdev@vger.kernel.org
>
> include/linux/font.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
applied to fb-dev git tree.
Thanks for fixing, Randy!
Helge
^ permalink raw reply
* Re: [PATCH v3 1/3] fbdev: bound mode sysfs output to the sysfs buffer
From: Helge Deller @ 2026-07-18 20:04 UTC (permalink / raw)
To: Melbin K Mathew; +Cc: linux-fbdev, dri-devel, linux-kernel, stable
In-Reply-To: <20260701234248.236023-2-mlbnkm1@gmail.com>
On 7/2/26 01:42, Melbin K Mathew wrote:
> mode_string() uses snprintf() which can return a value larger than the
> remaining buffer space. show_modes() accumulates the return value into i
> without checking whether i has reached PAGE_SIZE, causing the offset to
> advance past the sysfs buffer if the modelist is long enough.
>
> Add a size parameter to mode_string() and use scnprintf() to return
> only the bytes actually written. Add an early return when offset
> already exceeds the buffer. In show_modes(), stop accumulating once
> the buffer is full.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Melbin K Mathew <mlbnkm1@gmail.com>
> ---
> drivers/video/fbdev/core/fbsysfs.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
I've applied the series to fbdev git tree for further testing.
Thanks!
Helge
^ permalink raw reply
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Markus Elfring @ 2026-07-18 20:34 UTC (permalink / raw)
To: Helge Deller, linux-fbdev, dri-devel, Kees Cook,
Uwe Kleine-König, kernel-janitors
Cc: LKML
In-Reply-To: <40d5e392-3f99-44c9-b30a-3481f60143ba@gmx.de>
>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “ics5342_init”.
>>
>> Thus avoid the risk for undefined behaviour by moving the assignment
>> for the variable “info” behind a condition check.
>>
>> This issue was detected by using the Coccinelle software.
>
> There is no "risk" here.
> It just adds an offset to a potential NULL value (which isn't then used afterwards).
Does your understanding of programming language details differ from the view of
SEI CERT C Coding Standard (from the Carnegie Mellon University)?
https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
Regards,
Markus
^ permalink raw reply
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Helge Deller @ 2026-07-18 20:59 UTC (permalink / raw)
To: Markus Elfring, linux-fbdev, dri-devel, Kees Cook,
Uwe Kleine-König, kernel-janitors
Cc: LKML
In-Reply-To: <550584cc-863d-48c3-813b-3a0cb45d9084@web.de>
On 7/18/26 22:34, Markus Elfring wrote:
>>> The address of a data structure member was determined before
>>> a corresponding null pointer check in the implementation of
>>> the function “ics5342_init”.
>>>
>>> Thus avoid the risk for undefined behaviour by moving the assignment
>>> for the variable “info” behind a condition check.
>>>
>>> This issue was detected by using the Coccinelle software.
>>
>> There is no "risk" here.
>> It just adds an offset to a potential NULL value (which isn't then used afterwards).
> Does your understanding of programming language details differ from the view of
> SEI CERT C Coding Standard (from the Carnegie Mellon University)?
> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
My statement still stands.
Try to find the difference between the code and the examples on that website yourself.
Tip: The relevant part is the "&" and in doubt look at the generated assembly code.
I will not discuss this further.
Helge
^ permalink raw reply
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Uwe Kleine-König @ 2026-07-18 21:47 UTC (permalink / raw)
To: Markus Elfring
Cc: Helge Deller, linux-fbdev, dri-devel, Kees Cook, kernel-janitors,
LKML
In-Reply-To: <550584cc-863d-48c3-813b-3a0cb45d9084@web.de>
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
Hallo Markus,
On Sat, Jul 18, 2026 at 10:34:33PM +0200, Markus Elfring wrote:
> >> The address of a data structure member was determined before
> >> a corresponding null pointer check in the implementation of
> >> the function “ics5342_init”.
> >>
> >> Thus avoid the risk for undefined behaviour by moving the assignment
> >> for the variable “info” behind a condition check.
> >>
> >> This issue was detected by using the Coccinelle software.
> >
> > There is no "risk" here.
> > It just adds an offset to a potential NULL value (which isn't then used afterwards).
> Does your understanding of programming language details differ from the view of
> SEI CERT C Coding Standard (from the Carnegie Mellon University)?
> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
We recently discussed a similar case where several people told you that
the "problem" you fixed wasn't actually a problem. This patch is in the
same category and your reference doesn't match the code touched here.
Please stop to absorb maintainer attention with useless stuff.
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: pvr2fb: correct user pointer annotation and sentinel initializer
From: Uwe Kleine-König @ 2026-07-18 21:57 UTC (permalink / raw)
To: Florian Fuchs
Cc: Helge Deller, John Paul Adrian Glaubitz, linux-fbdev, dri-devel,
linux-kernel, kernel test robot
In-Reply-To: <20260713101638.600333-1-fuchsfl@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
On Mon, Jul 13, 2026 at 12:16:38PM +0200, Florian Fuchs wrote:
> Add __user annotation to buf, as it is passed as a user pointer in
> pin_user_pages_fast(). Use an empty initializer for the sentinel
> board-table entry to avoid initializing a function pointer with an
> integer literal.
FTR: Using 0 in an initializer is covered by the C standard. Anyhow, I
agree that { } is nicer.
Having said that, I think the right thing to do here is to drop the
sentinel entry, because board_driver[] is only used in for loops that
iterate between 0 (inclusive) and ARRAY_SIZE(board_driver) (exclusive).
Also I would split this patch in two.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] backlight: ktd2801: fix unmet dependency on GPIOLIB
From: Julian Braha @ 2026-07-19 2:49 UTC (permalink / raw)
To: lee, danielt, jingoohan1, deller
Cc: rdunlap, duje, dri-devel, linux-fbdev, linux-kernel, arnd,
Julian Braha
LEDS_EXPRESSWIRE depends on GPIOLIB, so its selector, BACKLIGHT_KTD2801
also needs to ensure GPIOLIB is enabled. Otherwise:
WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=n]
Selected by [y]:
- BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y]
This unmet dependency was found by kconfirm, a static analysis tool for
Kconfig.
Fixes: d95963e309bc ("backlight: ktd2801: Depend on GPIOLIB")
Signed-off-by: Julian Braha <julianbraha@gmail.com>
---
drivers/video/backlight/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 7c66b8840d88..dbf4ca23a9b6 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -193,7 +193,7 @@ config BACKLIGHT_KTD253
config BACKLIGHT_KTD2801
tristate "Backlight Driver for Kinetic KTD2801"
- depends on GPIOLIB || COMPILE_TEST
+ depends on GPIOLIB
select LEDS_EXPRESSWIRE
help
Say Y to enable the backlight driver for the Kinetic KTD2801 1-wire
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] backlight: ktd2801: fix unmet dependency on GPIOLIB
From: Randy Dunlap @ 2026-07-19 3:31 UTC (permalink / raw)
To: Julian Braha, lee, danielt, jingoohan1, deller
Cc: duje, dri-devel, linux-fbdev, linux-kernel, arnd
In-Reply-To: <20260719024902.151710-1-julianbraha@gmail.com>
Hi,
On 7/18/26 7:49 PM, Julian Braha wrote:
> LEDS_EXPRESSWIRE depends on GPIOLIB, so its selector, BACKLIGHT_KTD2801
> also needs to ensure GPIOLIB is enabled. Otherwise:
>
> WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
> Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=n]
> Selected by [y]:
> - BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y]
>
> This unmet dependency was found by kconfirm, a static analysis tool for
> Kconfig.
or it can be hand-crafted and the warning seen by 'make oldconfig' etc.
> Fixes: d95963e309bc ("backlight: ktd2801: Depend on GPIOLIB")
> Signed-off-by: Julian Braha <julianbraha@gmail.com>
> ---
> drivers/video/backlight/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 7c66b8840d88..dbf4ca23a9b6 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -193,7 +193,7 @@ config BACKLIGHT_KTD253
>
> config BACKLIGHT_KTD2801
> tristate "Backlight Driver for Kinetic KTD2801"
> - depends on GPIOLIB || COMPILE_TEST
> + depends on GPIOLIB
> select LEDS_EXPRESSWIRE
> help
> Say Y to enable the backlight driver for the Kinetic KTD2801 1-wire
Well, ktd2801.ko is being built for me with no warnings and I have:
COMPILE_TEST=y
GPIOLIB=n
BACKLIGHT_KTD2801=m
but we do want to eliminate the warning, so:
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
thanks.
--
~Randy
^ permalink raw reply
* [PATCH] staging: sm750fb: rename CamelCase parameters in sm750_accel.h
From: Gabriel Changamire @ 2026-07-19 6:46 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sudip Mukherjee, Teddy Wang
Cc: linux-fbdev, linux-staging, linux-kernel, Gabriel Changamire
The prototypes and kernel-doc comments for sm750_hw_copyarea() and
sm750_hw_imageblit() still use the old CamelCase parameter names,
while the function definitions in sm750_accel.c already use
snake_case. Rename the header parameters to match the definitions.
Fixes 10 checkpatch "Avoid CamelCase" checks. No functional change.
Signed-off-by: Gabriel Changamire <gaberashawn@gmail.com>
---
drivers/staging/sm750fb/sm750_accel.h | 36 +++++++++++++--------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
index d15a40cacb84..3d3d93d4b308 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -196,12 +196,12 @@ int sm750_hw_fillrect(struct lynx_accel *accel,
/**
* sm750_hm_copyarea
- * @sBase: Address of source: offset in frame buffer
- * @sPitch: Pitch value of source surface in BYTE
+ * @source_base: Address of source: offset in frame buffer
+ * @source_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
+ * @dest_base: Address of destination: offset in frame buffer
+ * @dest_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
@@ -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 source_base, unsigned int source_pitch,
unsigned int sx, unsigned int sy,
- unsigned int dBase, unsigned int dPitch,
+ unsigned int dest_base, unsigned int dest_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
+ * @src_buf: 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
+ * @dest_base: Address of destination: offset in frame buffer
+ * @dest_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
+ * @fg_color: Foreground color (corresponding to a 1 in the monochrome data
+ * @bg_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 *src_buf,
+ u32 src_delta, u32 start_bit, u32 dest_base, u32 dest_pitch,
+ u32 byte_per_pixel, u32 dx, u32 dy, u32 width,
+ u32 height, u32 fg_color, u32 bg_color, u32 rop2);
#endif
--
2.47.3
^ permalink raw reply related
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Markus Elfring @ 2026-07-19 6:50 UTC (permalink / raw)
To: Helge Deller, linux-fbdev, dri-devel, Kees Cook,
Uwe Kleine-König, kernel-janitors
Cc: LKML
In-Reply-To: <5a13f19d-4ba0-40d4-b061-0d17156b1686@gmx.de>
>> Does your understanding of programming language details differ from the view of
>> SEI CERT C Coding Standard (from the Carnegie Mellon University)?
>> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
> My statement still stands.
> Try to find the difference between the code and the examples on that website yourself.
> Tip: The relevant part is the "&"
Which functionality would you expect for the operator “address of”?
Is it applied only after a pointer dereference attempt in this case?
https://en.cppreference.com/c/language/operator_member_access
> and in doubt look at the generated assembly code.
Can development interests grow also according to another clarification approach?
Does &((struct name *)NULL -> b) cause undefined behaviour in C11?
https://stackoverflow.com/questions/26906621/does-struct-name-null-b-cause-undefined-behaviour-in-c11
Regards,
Markus
^ permalink raw reply
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Markus Elfring @ 2026-07-19 7:24 UTC (permalink / raw)
To: Uwe Kleine-König, Helge Deller, linux-fbdev, dri-devel,
Kees Cook, kernel-janitors, linux-hardening
Cc: LKML
In-Reply-To: <alvzxjwBr1gxu3Eb@monoceros>
>> Does your understanding of programming language details differ from the view of
>> SEI CERT C Coding Standard (from the Carnegie Mellon University)?
>> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
>
> We recently discussed a similar case where several people told you that
> the "problem" you fixed wasn't actually a problem.
We came along possible adjustments according to an application of another
questionable sanity check.
> This patch is in the
> same category and your reference doesn't match the code touched here.
Will development interests grow if bug reports will follow by further known
source code analysis tools?
https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/#automated-detection
> Please stop to absorb maintainer attention with useless stuff.
Do we need to start negotiations for allocation of a corresponding CVE ID
(as something happened for similar control flows before)?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/cve.rst?h=v7.2-rc3#n16
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fix checkpatch errors in fbtft-bus.c
From: Andy Shevchenko @ 2026-07-19 8:00 UTC (permalink / raw)
To: Shivesh; +Cc: andy, gregkh, dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <6a5bc4a7.f1c1923d.2d2b59.05d9@mx.google.com>
On Sat, Jul 18, 2026 at 9:23 PM Shivesh <chanelshivesh@gmail.com> wrote:
>
> From 7e9684b26176644bc92c2285acc7444f3f7ddb4d Mon Sep 17 00:00:00 2001
> From: Shivesh <chanelshivesh@gmail.com>
> Date: Sat, 18 Jul 2026 18:08:04 +0000
> Subject: [PATCH] staging: fbtft: fix checkpatch errors in fbtft-bus.c
>
> Fix space-related checkpatch errors in macro invocations. When the
> modifier argument is empty, remove the trailing comma to avoid
> 'space required after comma' and 'space prohibited before close
> parenthesis' conflicting errors.
Format of the sending the patch is wrong, and you even haven't
compiled the code. NAK.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] staging: sm750fb: select FB_IOMEM_FOPS in Kconfig
From: MishraMohit21 @ 2026-07-19 19:58 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel, MishraMohit21
The driver uses the FB_DEFAULT_IOMEM_OPS macro in sm750.c to define its
framebuffer operations. This macro references core framebuffer operations
fb_io_read, fb_io_write, and fb_io_mmap. These symbols are defined in
fb_io_fops.c, which is compiled only under CONFIG_FB_IOMEM_FOPS.
Since config FB_SM750 does not currently select FB_IOMEM_FOPS, compiling
the driver on a config that has no other framebuffer drivers enabled
fails with undefined symbol link errors during MODPOST.
Add 'select FB_IOMEM_FOPS' to Kconfig to ensure the driver core helpers
build successfully in all configurations. Keep the select statements
sorted alphabetically.
Signed-off-by: MishraMohit21 <mishraloopmohit@gmail.com>
---
drivers/staging/sm750fb/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
index 08bcccdd0f1c..7d5ad423e41f 100644
--- a/drivers/staging/sm750fb/Kconfig
+++ b/drivers/staging/sm750fb/Kconfig
@@ -2,10 +2,11 @@
config FB_SM750
tristate "Silicon Motion SM750 framebuffer support"
depends on FB && PCI && HAS_IOPORT
- select FB_MODE_HELPERS
- select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
+ select FB_CFB_FILLRECT
select FB_CFB_IMAGEBLIT
+ select FB_IOMEM_FOPS
+ select FB_MODE_HELPERS
help
Frame buffer driver for the Silicon Motion SM750 chip
with 2D acceleration and dual head support.
--
2.43.0
^ permalink raw reply related
* [PATCH] staging: sm750fb: Refactor init_status to use initchip_param
From: MishraMohit21 @ 2026-07-19 19:58 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel, MishraMohit21
In-Reply-To: <20260719195839.24937-1-mishraloopmohit@gmail.com>
The driver initializes the hardware by casting 'struct init_status *' to
'struct initchip_param *' in ddk750_init_hw(). This is technically
undefined behavior, violates strict-aliasing rules, and is fragile.
Furthermore, 'struct init_status' defines the 'reset_memory' field as a
2-byte 'ushort', while 'struct initchip_param' defines it as a 1-byte
'unsigned char'. On little-endian architectures, reading the low byte
of the ushort happens to evaluate to the correct value (0 or 1) by accident.
However, on big-endian architectures, casting and reading this field
reads the high byte (0x00) instead, causing a silent failure where the
memory controller is never reset.
This endianness layout mismatch was empirically verified using a standalone
test harness (scratch/be_test.c) compiled under a mips-linux-gnu-gcc
cross-compiler and executed under qemu-mips.
Resolve this by removing the duplicate 'struct init_status' entirely and
using 'struct initchip_param' directly. This removes the unsafe pointer
cast and ensures endian-safe hardware initialization.
This change has been compile-tested only. No hardware was available to
verify runtime behavior.
Signed-off-by: MishraMohit21 <mishraloopmohit@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 8 ++++----
drivers/staging/sm750fb/sm750.h | 12 ++----------
drivers/staging/sm750fb/sm750_hw.c | 16 ++++++++--------
3 files changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 89c811e0806c..5986dbef67c0 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -844,11 +844,11 @@ static void sm750fb_setup(struct sm750_dev *sm750_dev, char *src)
swap = 0;
- 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.chip_clock = 0;
+ sm750_dev->init_parm.mem_clock = 0;
+ sm750_dev->init_parm.master_clock = 0;
sm750_dev->init_parm.power_mode = 0;
- sm750_dev->init_parm.setAllEngOff = 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 */
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index d2c522e67f26..313c2683bf6c 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -38,15 +38,7 @@ enum sm750_path {
sm750_pnc = 3, /* panel and crt */
};
-struct init_status {
- ushort power_mode;
- /* below three clocks are in unit of MHZ*/
- ushort chip_clk;
- ushort mem_clk;
- ushort master_clk;
- ushort setAllEngOff;
- ushort reset_memory;
-};
+#include "ddk750_chip.h"
struct lynx_accel {
/* base virtual address of DPR registers */
@@ -102,7 +94,7 @@ struct sm750_dev {
/* locks*/
spinlock_t slock;
- struct init_status init_parm;
+ struct initchip_param init_parm;
enum sm750_pnltype pnltype;
enum sm750_dataflow dataflow;
int nocrt;
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 34a837fb4b64..54c1b241ae6e 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -66,20 +66,20 @@ int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev)
{
- struct init_status *parm;
+ struct initchip_param *parm;
parm = &sm750_dev->init_parm;
- if (parm->chip_clk == 0)
- parm->chip_clk = (sm750_get_chip_type() == SM750LE) ?
+ if (parm->chip_clock == 0)
+ parm->chip_clock = (sm750_get_chip_type() == SM750LE) ?
DEFAULT_SM750LE_CHIP_CLOCK :
DEFAULT_SM750_CHIP_CLOCK;
- if (parm->mem_clk == 0)
- parm->mem_clk = parm->chip_clk;
- if (parm->master_clk == 0)
- parm->master_clk = parm->chip_clk / 3;
+ if (parm->mem_clock == 0)
+ parm->mem_clock = parm->chip_clock;
+ if (parm->master_clock == 0)
+ parm->master_clock = parm->chip_clock / 3;
- ddk750_init_hw((struct initchip_param *)&sm750_dev->init_parm);
+ ddk750_init_hw(&sm750_dev->init_parm);
/* for sm718, open pci burst */
if (sm750_dev->devid == 0x718) {
poke32(SYSTEM_CTRL,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] staging: sm750fb: select FB_IOMEM_FOPS in Kconfig
From: Ahmet Sezgin Duran @ 2026-07-20 7:50 UTC (permalink / raw)
To: MishraMohit21, Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman
Cc: linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260719195839.24937-1-mishraloopmohit@gmail.com>
On 7/19/26 10:58 PM, MishraMohit21 wrote:
> The driver uses the FB_DEFAULT_IOMEM_OPS macro in sm750.c to define its
> framebuffer operations. This macro references core framebuffer operations
> fb_io_read, fb_io_write, and fb_io_mmap. These symbols are defined in
> fb_io_fops.c, which is compiled only under CONFIG_FB_IOMEM_FOPS.
>
> Since config FB_SM750 does not currently select FB_IOMEM_FOPS, compiling
> the driver on a config that has no other framebuffer drivers enabled
> fails with undefined symbol link errors during MODPOST.
>
> Add 'select FB_IOMEM_FOPS' to Kconfig to ensure the driver core helpers
> build successfully in all configurations. Keep the select statements
> sorted alphabetically.
>
> Signed-off-by: MishraMohit21 <mishraloopmohit@gmail.com>
> ---
> drivers/staging/sm750fb/Kconfig | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
> index 08bcccdd0f1c..7d5ad423e41f 100644
> --- a/drivers/staging/sm750fb/Kconfig
> +++ b/drivers/staging/sm750fb/Kconfig
> @@ -2,10 +2,11 @@
> config FB_SM750
> tristate "Silicon Motion SM750 framebuffer support"
> depends on FB && PCI && HAS_IOPORT
> - select FB_MODE_HELPERS
> - select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> + select FB_CFB_FILLRECT
> select FB_CFB_IMAGEBLIT
> + select FB_IOMEM_FOPS
> + select FB_MODE_HELPERS
> help
> Frame buffer driver for the Silicon Motion SM750 chip
> with 2D acceleration and dual head support.
Does not apply to Greg's staging-testing branch. `FB_IOMEM_FOPS` already
exists in Kconfig.
Also you need to put a fullname in `Signed-off-by` part.
Regards,
Ahmet Sezgin Duran
^ permalink raw reply
* Re: fbdev: arkfb: Move a variable assignment behind a condition check in ics5342_init()
From: Markus Elfring @ 2026-07-20 9:52 UTC (permalink / raw)
To: Helge Deller, linux-fbdev, dri-devel, Kees Cook,
Uwe Kleine-König, kernel-janitors, linux-hardening
Cc: LKML
In-Reply-To: <5a13f19d-4ba0-40d4-b061-0d17156b1686@gmx.de>
>>>> The address of a data structure member was determined before
>>>> a corresponding null pointer check in the implementation of
>>>> the function “ics5342_init”.
>>>>
>>>> Thus avoid the risk for undefined behaviour by moving the assignment
>>>> for the variable “info” behind a condition check.
>>>>
>>>> This issue was detected by using the Coccinelle software.
>>>
>>> There is no "risk" here.
>>> It just adds an offset to a potential NULL value (which isn't then used afterwards).
>> Does your understanding of programming language details differ from the view of
>> SEI CERT C Coding Standard (from the Carnegie Mellon University)?
>> https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/expressions-exp/exp34-c/
> My statement still stands.
> Try to find the difference between the code and the examples on that website yourself.
> Tip: The relevant part is the "&" and in doubt look at the generated assembly code.
Do any more code reviewers take another look at results from undefined behaviour sanitizers?
* https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#introduction
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/dev-tools/ubsan.rst?h=v7.2-rc3#n6
See also:
https://stackoverflow.com/questions/79662603/why-do-compilers-not-warn-about-this-null-dereferencing-even-when-they-detect-i#answer-79663272
Regards,
Markus
^ 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