linux-kernel - Re: [RFC] Second OLPC Viafb series

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] [day] [month] [year] [list]

Message-ID: <4BD30944.6060302@gmx.de>
Date:	Sat, 24 Apr 2010 17:07:48 +0200
From:	Florian Tobias Schandinat <FlorianSchandinat@....de>
To:	Jonathan Corbet <corbet@....net>
CC:	linux-kernel@...r.kernel.org, Harald Welte <laforge@...monks.org>,
	Deepak Saxena <dsaxena@...top.org>,
	linux-fbdev@...r.kernel.org, JosephChan@....com.tw,
	ScottFang@...tech.com.cn
Subject: Re: [RFC] Second OLPC Viafb series

Hi,

Jonathan Corbet schrieb:
> So this is the second series of viafb patches - the stuff that I was really
> working toward since the beginning.  They depend on the previously-posted
> first series.  What's added here is a big refactoring of the driver to
> split its functions apart and the addition of code for GPIO, interrupt,
> DMA, and camera management.

this looks like a step in the right direction. But I have the feeling 
that it needs a lot of work before I'd consider it useful for mainline.

> Florian, I incorporated your indexed port I/O patch, since it was an
> obvious improvement and I was reworking that stuff anyway.

Thanks.
Could you please also take the proc fix (6) in your upstream branch as 
it is clearly a bugfix (and tainting the kernel is also something that 
should be avoided)

> The full series of patches can be pulled from:
> 
> 	git://git.lwn.net/linux-2.6.git viafb-posted

Probably I should use this the next time as this series again did not 
cleanly apply so I just fired patch on it (which worked as it was mostly 
due to a slight difference in our compile fixes).

So I wanted to runtime test it as you said that it might fix the 
I2C/GPIO issue I debugged. I gave up for now after hitting the following 
errors:

drivers/video/via/via-gpio.c:74: error: field 'gpio_chip' has incomplete 
type

so we should either select GPIOLIB or add ifdef's to avoid the dependency?

After that I hit

drivers/video/via/via_i2c.o: In function `init_module':
via_i2c.c:(.text+0x309): multiple definition of `init_module'
drivers/video/via/viafbdev.o:viafbdev.c:(.init.text+0x0): first defined here
drivers/video/via/via_i2c.o: In function `cleanup_module':
via_i2c.c:(.text+0x10): multiple definition of `cleanup_module'
drivers/video/via/viafbdev.o:viafbdev.c:(.exit.text+0x0): first defined here
drivers/video/via/via-gpio.o: In function `init_module':
via-gpio.c:(.text+0x1f6): multiple definition of `init_module'
drivers/video/via/viafbdev.o:viafbdev.c:(.init.text+0x0): first defined here
drivers/video/via/via-gpio.o: In function `cleanup_module':
via-gpio.c:(.text+0x0): multiple definition of `cleanup_module'
drivers/video/via/viafbdev.o:viafbdev.c:(.exit.text+0x0): first defined here

Guess that means you should only have one module init/exit per module. 
So either making via_i2c and via_gpio separate modules or calling these 
functions directly from the init/exit functions.

That's it for now as I'm really supposed to do some other stuff, too.

Thanks,

Florian Tobias Schandinat
--
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/