[PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq
On Sun, 27 Dec 2015, Sergei Shtylyov wrote:
> On 12/26/2015 11:58 PM, Julia Lawall wrote:
>
> > The error return value of platform_get_irq seems to often get dropped.
> >
> > Signed-off-by: Julia Lawall
> >
> > ---
> >
> > v2: Check for the direct return case also. Added some mailing lists of
> > common offenders.
> >
> > diff --git a/scripts/coccinelle/api/platform_get_irq_return.cocci
> > b/scripts/coccinelle/api/platform_get_irq_return.cocci
> > new file mode 100644
> > index 000..44680d0
> > --- /dev/null
> > +++ b/scripts/coccinelle/api/platform_get_irq_return.cocci
> > @@ -0,0 +1,58 @@
> > +/// Propagate the return value of platform_get_irq.
> > +//# Sometimes the return value of platform_get_irq is tested using <= 0,
> > but 0
> > +//# might not be an appropriate return value in an error case.
> > +///
> > +// Confidence: Moderate
> > +// Copyright: (C) 2015 Julia Lawall, Inria. GPLv2.
> > +// URL: http://coccinelle.lip6.fr/
> > +// Options: --no-includes --include-headers
> > +
> > +virtual context
> > +virtual org
> > +virtual report
> > +
> > +//
> >
> > +
> > + at r depends on context || org || report@
> > +constant C;
> > +statement S;
> > +expression e, ret;
> > +position j0, j1;
> > +@@
> > +
> > +* e at j0 = platform_get_irq(...);
> > +(
> > +if at j1 (...) {
> > + ...
> > + return -C;
> > +} else S
> > +|
> > +if at j1 (...) {
> > + ...
> > + ret = -C;
> > + ...
> > + return ret;
> > +} else S
>
>Well, this seems to also cover the (e <= 0) checks which do make same sense
> in the light of Linus considering IRQ0 invalid. So I'd be more specific about
> the checks here -- 0 should indeed be overridden with something if it's
> considered invalid.
That's what the limitations section says (lines with #). This doesn't
make any changes, it only makes warnings, which should include the
limitations information, so perhaps people can consider what it is that
they really intend to do.
If you think this is not a good idea, then I can make the test more
specific.
julia
[PATCH v2] coccinelle: api: check for propagation of error from platform_get_irq
The error return value of platform_get_irq seems to often get dropped.
Signed-off-by: Julia Lawall
---
v2: Check for the direct return case also. Added some mailing lists of
common offenders.
diff --git a/scripts/coccinelle/api/platform_get_irq_return.cocci
b/scripts/coccinelle/api/platform_get_irq_return.cocci
new file mode 100644
index 000..44680d0
--- /dev/null
+++ b/scripts/coccinelle/api/platform_get_irq_return.cocci
@@ -0,0 +1,58 @@
+/// Propagate the return value of platform_get_irq.
+//# Sometimes the return value of platform_get_irq is tested using <= 0, but 0
+//# might not be an appropriate return value in an error case.
+///
+// Confidence: Moderate
+// Copyright: (C) 2015 Julia Lawall, Inria. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Options: --no-includes --include-headers
+
+virtual context
+virtual org
+virtual report
+
+//
+
+ at r depends on context || org || report@
+constant C;
+statement S;
+expression e, ret;
+position j0, j1;
+@@
+
+* e at j0 = platform_get_irq(...);
+(
+if at j1 (...) {
+ ...
+ return -C;
+} else S
+|
+if at j1 (...) {
+ ...
+ ret = -C;
+ ...
+ return ret;
+} else S
+)
+
+//
+
+ at script:python r_org depends on org@
+j0 << r.j0;
+j1 << r.j1;
+@@
+
+msg = "Propagate return value of platform_get_irq."
+coccilib.org.print_todo(j0[0], msg)
+coccilib.org.print_link(j1[0], "")
+
+//
+
+ at script:python r_report depends on report@
+j0 << r.j0;
+j1 << r.j1;
+@@
+
+msg = "Propagate return value of platform_get_irq around line %s." %
(j1[0].line)
+coccilib.report.print_report(j0[0], msg)
+
[PATCH] include/linux/amd-iommu.h: Move to arch/x86/include/asm
From: Chen Gang
It is architecture specific mechanism header, not generic header, so
move it to arch/x86/include/asm.
ALso change all related contents for it.
Signed-off-by: Chen Gang
---
MAINTAINERS | 2 +-
{include/linux => arch/x86/include/asm}/amd-iommu.h | 0
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 +-
drivers/gpu/drm/amd/amdkfd/kfd_process.c| 2 +-
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/amd_iommu_init.c | 2 +-
drivers/iommu/amd_iommu_v2.c| 2 +-
7 files changed, 6 insertions(+), 6 deletions(-)
rename {include/linux => arch/x86/include/asm}/amd-iommu.h (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 44666b1..893cf07 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -656,7 +656,7 @@ L: iommu at lists.linux-foundation.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
S: Maintained
F: drivers/iommu/amd_iommu*.[ch]
-F: include/linux/amd-iommu.h
+F: arch/x86/include/asm/amd-iommu.h
AMD KFD
M: Oded Gabbay
diff --git a/include/linux/amd-iommu.h b/arch/x86/include/asm/amd-iommu.h
similarity index 100%
rename from include/linux/amd-iommu.h
rename to arch/x86/include/asm/amd-iommu.h
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
index 3f95f7c..bcbbabd 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c
@@ -20,7 +20,7 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include
+#include
#include
#include
#include
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 9be0070..a268799 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 8b2be1e..fea3056 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -28,7 +28,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 013bdff..f7eee70 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/iommu/amd_iommu_v2.c b/drivers/iommu/amd_iommu_v2.c
index c865737..e6584fe 100644
--- a/drivers/iommu/amd_iommu_v2.c
+++ b/drivers/iommu/amd_iommu_v2.c
@@ -17,7 +17,7 @@
*/
#include
-#include
+#include
#include
#include
#include
--
1.9.3
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #22 from Maxim Sheviakov --- Uhm, sorry for a noobish question, but... When will the fix for this issue be avalible? I don't fancy using git versions of %package%, so that's pretty important. Maybe 11.1.1? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151226/c4e7a7e4/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #101 from Maxim Sheviakov --- (In reply to Daniel Exner from comment #100) > If that worked for you you are lucky, but at least I won't flash a different > BIOS just to _downgrade_ my card, possibly breaking it completely. Alas the > already in place quirk results in exactly the same. That's not a _downgrade_, that's a way to change an ID. > > And yep, with its standard VBios card works with 1050MHz/1.2GHz > > (core/memory) clocks. I'm using those SMC patches + new firmware. Maybe they > > should be sent upstream, even to add that new firmware files and code to use > > them? > The new firmware files are fine for 370X it seems but still need work for > 270X. I guess most 270X users CC in this ticket will happily test possible > reworked ones as soon as they are available and we patiently wait for Alex. 1) No 370X :D 2)I guess everyone in this CC will happily test anything that is *supposed* to fix the issues =) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151226/a4d2941b/attachment.html>
Re: 答复: [RESEND 1/3] drm: fsl-dcu: Fix no fb check bug
Hi Meng,
The only situation I could observe that is when fsl,panel was not
valid...
However, I think with my patch "drm/fsl-dcu: Fix no fb check bug", this
situation can be avoided completely:
https://lkml.org/lkml/2015/11/18/950
With that patch applied, and a non-existing panel assigned, the DRM
driver already fails at probe time gracefully:
[0.488291] [drm] Initialized drm 1.1.0 20060810
[0.501576] fsl-dcu 40058000.dcu: failed to initialize mode setting
So I think that a state->fb check for NULL is not necessary at all...
Can you test my patch to see if it fixes the issue for you too?
--
Stefan
On 2015-12-23 21:28, Meng Yi wrote:
> Tested-by: Meng Yi
>
> -é®ä»¶å件-
> å件人: Dongsheng Wang [mailto:Dongsheng.Wang at freescale.com]
> åéæ¶é´: Tuesday, December 01, 2015 4:16 PM
> æ¶ä»¶äºº: airlied at linux.ie
> æé: stefan at agner.ch; dri-devel at lists.freedesktop.org; Jianwei Wang
> ; Yi Meng-B56799 ;
> Wang Dongsheng-B40534
> 主é¢: [RESEND 1/3] drm: fsl-dcu: Fix no fb check bug
>
> From: Jianwei Wang
>
> For state->fb may be NULL in fsl_dcu_drm_plane_atomic_check function,
> if so, return -EINVAL. No need check in
> fsl_dcu_drm_plane_atomic_update anymore.
>
> Signed-off-by: Jianwei Wang
> Signed-off-by: Yi Meng
> Signed-off-by: Wang Dongsheng
> Tested-by: Stefan Agner
>
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
> index 51daaea..a8932a8 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c
> @@ -41,6 +41,9 @@ static int fsl_dcu_drm_plane_atomic_check(struct
> drm_plane *plane, {
> struct drm_framebuffer *fb = state->fb;
>
> + if (!fb)
> + return -EINVAL;
> +
> switch (fb->pixel_format) {
> case DRM_FORMAT_RGB565:
> case DRM_FORMAT_RGB888:
> @@ -85,9 +88,6 @@ static void fsl_dcu_drm_plane_atomic_update(struct
> drm_plane *plane,
> unsigned int alpha, bpp;
> int index, ret;
>
> - if (!fb)
> - return;
> -
> index = fsl_dcu_drm_plane_index(plane);
> if (index < 0)
> return;
> --
> 2.1.0.27.g96db324
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #100 from Daniel Exner --- (In reply to Maxim Sheviakov from comment #99) > Interesting, but it got flashed 0_0 > Also, the problem is not in VBios or IDs. It's all about memory clock - > setting a value higher than 1.2GHz (in a quirk) makes the system hang after > Plymouth/before display server start. So, to my mind we have to do something > with DPM/PowerPlay code or make some userspace overclock support, as there's > no other way right now. By the way, is there such a tool that allows to > overclock memory of the card? If that worked for you you are lucky, but at least I won't flash a different BIOS just to _downgrade_ my card, possibly breaking it completely. Alas the already in place quirk results in exactly the same. > And yep, with its standard VBios card works with 1050MHz/1.2GHz > (core/memory) clocks. I'm using those SMC patches + new firmware. Maybe they > should be sent upstream, even to add that new firmware files and code to use > them? The new firmware files are fine for 370X it seems but still need work for 270X. I guess most 270X users CC in this ticket will happily test possible reworked ones as soon as they are available and we patiently wait for Alex. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151226/0939ab5e/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #99 from Maxim Sheviakov --- (In reply to Alex Deucher from comment #98) > (In reply to Tobias Droste from comment #95) > > Are you suggesting that Microsoft Windows 10 is delivering a different VBIOS > > for your card then what was originally installed on the graphics card? > > > > If so, who installs this? Windows itself? As far as I know is the driver > > only loading some binaries inside the VBIOS, but not replacing it. Or is > > this a new feature of the windows driver? > > Neither Windows nor the Windows driver flashes a new vbios. Flashing an > arbitrary vbios is not recommended, may render your card useless, and may > void your warranty. Interesting, but it got flashed 0_0 Also, the problem is not in VBios or IDs. It's all about memory clock - setting a value higher than 1.2GHz (in a quirk) makes the system hang after Plymouth/before display server start. So, to my mind we have to do something with DPM/PowerPlay code or make some userspace overclock support, as there's no other way right now. By the way, is there such a tool that allows to overclock memory of the card? And yep, with its standard VBios card works with 1050MHz/1.2GHz (core/memory) clocks. I'm using those SMC patches + new firmware. Maybe they should be sent upstream, even to add that new firmware files and code to use them? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151226/cea36151/attachment-0001.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #98 from Alex Deucher --- (In reply to Tobias Droste from comment #95) > Are you suggesting that Microsoft Windows 10 is delivering a different VBIOS > for your card then what was originally installed on the graphics card? > > If so, who installs this? Windows itself? As far as I know is the driver > only loading some binaries inside the VBIOS, but not replacing it. Or is > this a new feature of the windows driver? Neither Windows nor the Windows driver flashes a new vbios. Flashing an arbitrary vbios is not recommended, may render your card useless, and may void your warranty. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151226/8987caf9/attachment.html>
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #43 from Lauri Gustafsson --- (In reply to lainlives from comment #42) > I worked around this by setting performance & high BEFORE Xorg is able to > start. I seem to only have this problem if it switches power modes while X > is running. My card still hangs after a little use even when setting performance to power_dmp_state before startx. http://imgur.com/GQf2NJY -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151226/d3316224/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #97 from Maxim Sheviakov --- He-hey! Succeeded in booting and making the card work with 1050Mhz core clocks! So, I added the firmware, applied the pathes from Alex, modified quirk's values so that it's 1020MHz core + 1200MHz mem, compiled -zen kernel - got the X server working. Couldn't test anymore, but further info will arise at about 17:00 Moscow time. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151226/d1e1ed33/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #96 from Maxim Sheviakov --- 1) Thanks. 2) Nope. There's a tool - "ATIFlash" - from TechPowerUp. It allows you to A) Save your current VBios B) Flash another VBios I think we have to modify vendor/model IDs, or fix clocks to their normal values. Yup, no powersaving, but who cares? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151226/7798f5bc/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #95 from Tobias Droste --- $ cat /sys/kernel/debug/dri/0/radeon_pm_info If you have debugfs mounted on /sys/kernel/debug Are you suggesting that Microsoft Windows 10 is delivering a different VBIOS for your card then what was originally installed on the graphics card? If so, who installs this? Windows itself? As far as I know is the driver only loading some binaries inside the VBIOS, but not replacing it. Or is this a new feature of the windows driver? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151226/0280c4a6/attachment.html>
