lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 5 Jan 2009 22:02:47 +0100 (CET)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Dan Williams <dan.j.williams@...el.com>
cc:	linux-kernel@...r.kernel.org,
	linux-fbdev-devel@...ts.sourceforge.net, adaplas@...il.com,
	Sascha Hauer <s.hauer@...gutronix.de>,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH 0/4 v6] i.MX31: dmaengine and framebuffer drivers

On Mon, 5 Jan 2009, Dan Williams wrote:

> On Fri, Dec 26, 2008 at 10:11 AM, Guennadi Liakhovetski
> <g.liakhovetski@....de> wrote:
> > Hi,
> >
> > This is version 6 of dmaengine and framebuffer drivers for i.MX31.
> >
> 
> Tha drivers/dma/ bits look ok to me minus the new warnings:
> 
> drivers/dma/ipu/ipu_irq.c: In function 'ipu_irq_fn':
> drivers/dma/ipu/ipu_irq.c:328: warning: 'irq' may be used
> uninitialized in this function
> drivers/dma/ipu/ipu_irq.c: In function 'ipu_irq_err':
> drivers/dma/ipu/ipu_irq.c:290: warning: 'irq' may be used
> uninitialized in this function

Wow... with what gcc version? My 4.1.2 correctly recognises, that it 
_doesn't_ get used uninitialised.

> I can take patches 1 and 2 through the async_tx tree, or if you would
> rather, add my Acked-by to those and take 1-4 through the MXC tree.
> I'll be sending the async_tx pull request for 2.6.29 in the next few
> days.

Thanks, great! Don't know what's better, let's see what Sascha says. But 
there's one small problem with the patch 2/4: it breaks compilation on 
i.MX31 if IPU is _not_ set, so, default imx31 configs would break:-( The 
problem is, that I use CONFIG_MX3_IPU_IRQS unconditionally in calculation 
of NR_IRQ. The easiest for me is to fix it in mx31.h like

#ifdef CONFIG_MX3_IPU_IRQS
#define MX3_IPU_IRQS CONFIG_MX3_IPU_IRQS
#else
#define MX3_IPU_IRQS 0
#endif

but that's less than elegant:-) A probably better solution would be to fix 
this in Kconfig, best would be to show

config MX3_IPU_IRQS
	int "..."

if MX3_IPU is set and hide it otherwise, setting to 0... But I don't know 
off hand how to do this properly. Hm, looks like the following works:

config MX3_IPU_IRQS
	int "Number of dynamically mapped interrupts for IPU"
	depends on MX3_IPU
	range 2 137
	default 4
	help
	  Out of 137 interrupt sources on i.MX31 IPU only very few are used.
	  To avoid bloating the irq_desc[] array we allocate a sufficient
	  number of IRQ slots and map them dynamically to specific sources.

config MX3_IPU_IRQS
	int
	default 0
	depends on !MX3_IPU

Would it be considered a proper Kbuild (ab)use?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ