similar to: [PATCH 2/6] drm/nouveau: remove unused struct 'init_exec'

On 6/11/24 12:37, Dr. David Alan Gilbert wrote: > * Danilo Krummrich (dakr at redhat.com) wrote: >> On 5/18/24 01:26, linux at treblig.org wrote: >>> From: "Dr. David Alan Gilbert" <linux at treblig.org> >>> >>> 'init_exec' is unused since >>> commit cb75d97e9c77 ("drm/nouveau: implement devinit subdev, and new >>>

Hi, questions will follow. --- diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c index 99f7bd4..13b3fb1 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bios.c +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c @@ -40,8 +40,6 @@ #define BIOSLOG(sip, fmt, arg...) NV_DEBUG(sip->dev, fmt, ##arg) #define LOG_OLD_VALUE(x) //x -#define BIOS_USLEEP(n)

On Fri, 02 Oct 2009 00:07:07 +0100 Stuart Bennett <stuart at freedesktop.org> wrote: > Pekka Paalanen wrote: > > Hi Stuart, > > > > I'm not sure you know, but annarchy just lost all user homes. > > Could you push vbtracetool and whatever personal git repos you > > had, so we can clone them? > > Hey Pekka, I've re-upped vbtracetool and

From: Andrea Tacconi <tacconet at libero.it> Subject: [PATCH] drm/nouveau: fix vbios load and check functions on PowerPC On PowerPC the Bios signature reports a wrong lenght of video rom. Fix this by reading the correct size from Open Firmware. Set Pramin as primary vbios searching method, because it's the only working method on PowerPC. The nv_cksum function always fails. Fix this

--- drivers/gpu/drm/nouveau/nouveau_bios.c | 47 ++++++++++++++----------------- 1 files changed, 21 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c b/drivers/gpu/drm/nouveau/nouveau_bios.c index 5eec5ed..04ac564 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bios.c +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c @@ -181,43 +181,42 @@ struct methods { const char

We just need to clear the SBA and ENABLE bits to reset the AGP controller: If the AGP bridge was configured to use "fast writes", clearing the FW bit would break the subsequent MMIO writes and eventually end with a lockup. Note that all the BIOSes I've seen do the same as we did (it works for them because they don't use MMIO), OTOH the blob leaves FW untouched. Signed-off-by:

Using the ARRAY_SIZE macro improves the readability of the code. Also, it is useless to re-invent it. Found with Coccinelle with the following semantic patch: @r depends on (org || report)@ type T; T[] E; position p; @@ ( (sizeof(E)@p /sizeof(*E)) | (sizeof(E)@p /sizeof(E[...])) | (sizeof(E)@p /sizeof(T)) ) Reviewed-by: Thierry Reding <treding at nvidia.com> Signed-off-by: Jérémy

usleep() was being used without checking its return value. When the server receives SIGALRM or SIGIO the waits are shortened and random modesetting failures happen: Use nanosleep and loop around it until the requested time has elapsed. --- src/nouveau_hw.c | 2 +- src/nouveau_local.h | 6 ++++++ src/nv_bios.c | 2 +- src/nv_crtc.c | 2 +- src/nv_include.h | 1 +

Using the ARRAY_SIZE macro improves the readability of the code. Also, it is not always useful to use a variable to store this constant calculated at compile time nor to re-invent the ARRAY_SIZE macro. Found with Coccinelle with the following semantic patch: @r depends on (org || report)@ type T; T[] E; position p; @@ ( (sizeof(E)@p /sizeof(*E)) | (sizeof(E)@p /sizeof(E[...])) | (sizeof(E)@p

(It was suggested I send a copy of this to ext3-users, so here it is - note that I need this RAID going so I've rebuilt with reiser, but would still appreciate suggestions; the message was original sent to the lkml) Hi, I've just built an 800GB RAID5 array and built an ext3 file system on it; on trying to copy data off the 200GB RAID it is replacing I'm starting to see errors of the

Hi Ian, I've been going through some sparse scans of the kernel and it threw up: CHECK drivers/net/xen-netback/xenbus.c drivers/net/xen-netback/xenbus.c:29:40: error: dubious one-bit signed bitfield int have_hotplug_status_watch:1; from your patch f942dc2552b8bfdee607be867b12a8971bb9cd85 It does look like that should be an unsigned (given it's assigned 0 and 1) Dave

Hi Ian, I've been going through some sparse scans of the kernel and it threw up: CHECK drivers/net/xen-netback/xenbus.c drivers/net/xen-netback/xenbus.c:29:40: error: dubious one-bit signed bitfield int have_hotplug_status_watch:1; from your patch f942dc2552b8bfdee607be867b12a8971bb9cd85 It does look like that should be an unsigned (given it's assigned 0 and 1) Dave

Hi Ian, I've been going through some sparse scans of the kernel and it threw up: CHECK drivers/net/xen-netback/xenbus.c drivers/net/xen-netback/xenbus.c:29:40: error: dubious one-bit signed bitfield int have_hotplug_status_watch:1; from your patch f942dc2552b8bfdee607be867b12a8971bb9cd85 It does look like that should be an unsigned (given it's assigned 0 and 1) Dave

From: Colin Ian King <colin.king at canonical.com> Don't populate arrays hwsq_signature and edid_sig on the stack but instead make them static. Makes the object code smaller by over 190 bytes: Before: text data bss dec hex filename 35676 3312 64 39052 988c nouveau_bios.o After: text data bss dec hex filename 35319 3472 64

Absence of a TMDS Info Table is common on Optimus setups where the NVIDIA gpu is not connected directly to any outputs. Reporting an error in this scenario is too harsh. Accordingly, change the error message to an info message. By default the error message also causes a boot flicker for these sytems. Signed-off-by: Rhys Kidd <rhyskidd at gmail.com> ---

Optimus cards with no outputs trigger this message (NVD7, for example) This commit changes the warning into an informational message. The return value of the function is not used, so I left it at -EINVAL. Signed-off-by: Albert Pool <albertpool at solcon.nl> Cc: Emil Velikov <emil.l.velikov at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 3 ++- 1 file changed, 2

A 2 minute google search shows that this error is prevalent with mobile Nvidia GPUs. Since we can assume mobile parts have no fp table, demote the error to desktop cards. Also reword the comment since the error is not restricted to Apple hardware. Signed-off by: Rosen Penev <rosenp at gmail.com> --- drm/nouveau/nouveau_bios.c | 10 +++++----- 1 file changed, 5 insertions(+), 5

On Mon, Feb 15, 2010 at 03:40:56PM +0300, Dan Carpenter wrote: > This is the results from: > make C=1 CHECK="/path/to/smatch -p=kernel" bzImage modules | tee warns.txt > grep -w overflow warns.txt | uniq -f 3 | tee err-list > > I hacked on the buffer overflow check last weekend and these are the > results. It has way more false positives than the other bug

Hi, I've noticed that there are now lots of different files that determine keyboard layout: 1) xorg.conf 2) Gnome's gconf files 2a) A user local one b) System global one (used for new users?) 3) KDEs config files a) User local one b) Is there a system global one somewhere? (0) A config file for your text mode console So consider someone trying

Hi, I'm curious what work has been done on security desktop apps using things like SELinux and AppArmor or equivalents on other OSs. At the moment it seems to be the norm for apps to both read and change their config files if they have them and that seems to offer the potential for malware to exploit a bug in an app to make it easily propagate to the next invocation of the app. My general