similar to: [PATCH 4/10] drm/nouveau/bios/init: Use ARRAY_SIZE macro

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

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

As seen in at least one NV134 VBIOS (... that I obviously don't own myself). Signed-off-by: Roy Spliet <nouveau at spliet.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 27 +++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c index 38ed09f..a18f8b4 100644

Hi everyone, Using ARRAY_SIZE improves the code readability. I used coccinelle (I made a change to the array_size.cocci file [1]) to find several places where ARRAY_SIZE could be used instead of other macros or sizeof division. I tried to divide the changes into a patch per subsystem (excepted for staging). If one of the patch should be split into several patches, let me know. In order to reduce

Following a series of three patches, two of which have been sitting in my tree for a while, the third is the result of some inspection of an NV134 BIOS that seems to use the 0xaf upcode to upload training patterns. Please test! Roy Ps. Sorry they come from yet another e-mail address. My previous provider, eclipso, actively blocks users of git send-email. Inquiries fall on deaf ears, hence I

NVIDIA GPUs include a common scripting language (devinit) that can be interpreted by a number of "engines", e.g. within a kernel-mode software driver, the VGA BIOS or an on-board small microcontroller which provides certain security assertions (the 'PMU'). This system allows a GPU programming sequence to be shared by multiple entities that would not otherwise be able to execute

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function parameter or member 'init' not described in 'init_reserved' drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: expecting prototype for INIT_DONE(). Prototype was for init_done() instead [Snipped ~140 lines for brevity] Cc: Ben Skeggs <bskeggs at

Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function parameter or member 'init' not described in 'init_reserved' drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:611: warning: expecting prototype for INIT_DONE(). Prototype was for init_done() instead [Snipped ~140 lines for brevity] Signed-off-by: Lee Jones

https://bugs.freedesktop.org/show_bug.cgi?id=107069 Bug ID: 107069 Summary: trace in kernel.log on boot Product: xorg Version: 7.7 (2012.06) Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

It's equivalent to __printf, so prefer __scanf. Signed-off-by: Joe Perches <joe at perches.com> --- include/linux/compiler-gcc.h | 3 ++- include/linux/kernel.h | 8 ++++---- include/xen/xenbus.h | 4 ++-- scripts/checkpatch.pl | 6 ++++++ 4 files changed, 14 insertions(+), 7 deletions(-) diff --git a/include/linux/compiler-gcc.h

It's equivalent to __printf, so prefer __scanf. Signed-off-by: Joe Perches <joe at perches.com> --- include/linux/compiler-gcc.h | 3 ++- include/linux/kernel.h | 8 ++++---- include/xen/xenbus.h | 4 ++-- scripts/checkpatch.pl | 6 ++++++ 4 files changed, 14 insertions(+), 7 deletions(-) diff --git a/include/linux/compiler-gcc.h

The warning you included happens when we're trying to execute a VBIOS script as part of DP training. Can you include your vbios? It should be available at /sys/kernel/debug/dri/0/vbios.rom Also, can you confirm how your monitors are connected to the card (and e.g. what resolution they are, anything else "funny" about them)? Finally, this warning might not have anything to do with

https://bugs.freedesktop.org/show_bug.cgi?id=72943 Priority: medium Bug ID: 72943 Assignee: nouveau at lists.freedesktop.org Summary: NV98 [GeForce 9300 gs m] hangs on boot- all linux kernel versions > 3.2 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS:

I have a Nvidia NVS310 installed in my Linux computer for a few years. It works well with the Nvidia driver, and not so well with the Linux nouveau driver. The Nvidia NVS310 has never worked well with Linux. In the beginning (many years ago) I decided to install Nvidia proprietary drivers, but every kernel upgrade would require an additional effort to have the driver working. That was enough

Use macro definition Cc: Jeremy Fitzhardinge <jeremy at goop.org> Cc: Chris Wright <chrisw at sous-sol.org> Cc: virtualization at lists.linux-foundation.org Cc: linux-ia64 at vger.kernel.org Signed-off-by: Fabian Frederick <fabf at skynet.be> --- This is untested. arch/ia64/kernel/paravirt.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git

Use macro definition Cc: Jeremy Fitzhardinge <jeremy at goop.org> Cc: Chris Wright <chrisw at sous-sol.org> Cc: virtualization at lists.linux-foundation.org Cc: linux-ia64 at vger.kernel.org Signed-off-by: Fabian Frederick <fabf at skynet.be> --- This is untested. arch/ia64/kernel/paravirt.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git

On Mon, 2 Oct 2017 09:01:31 +1100 "Tobin C. Harding" <me at tobin.cc> wrote: > > In order to reduce the size of the To: and Cc: lines, each patch of the > > series is sent only to the maintainers and lists concerned by the patch. > > This cover letter is sent to every list concerned by this series. > > Why don't you just send individual patches for

On Mon, Oct 02, 2017 at 07:35:54AM +0200, Greg KH wrote: > On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote: > > On Mon, 2 Oct 2017 09:01:31 +1100 > > "Tobin C. Harding" <me at tobin.cc> wrote: > > > > > > In order to reduce the size of the To: and Cc: lines, each patch of the > > > > series is sent only to the maintainers

On Mon, Oct 02, 2017 at 09:33:12PM -0400, Jérémy Lefaure wrote: > On Mon, 2 Oct 2017 15:22:24 -0400 > bfields at fieldses.org (J. Bruce Fields) wrote: > > > Mainly I'd just like to know which you're asking for. Do you want me to > > apply this, or to ACK it so someone else can? If it's sent as a series > > I tend to assume the latter. > > > >

On Mon, 2 Oct 2017 15:22:24 -0400 bfields at fieldses.org (J. Bruce Fields) wrote: > Mainly I'd just like to know which you're asking for. Do you want me to > apply this, or to ACK it so someone else can? If it's sent as a series > I tend to assume the latter. > > But in this case I'm assuming it's the former, so I'll pick up the nfsd > one.... Could