Re: [PATCH] gpiolib: Allow user-selection

On Wed, 2 Jul 2008 22:00:49 -0700 David Brownell <david-b@xxxxxxxxxxx> wrote:

On Wednesday 02 July 2008, Andrew Morton wrote:
On Wed, 2 Jul 2008 23:46:53 +0200
Michael Buesch <mb@xxxxxxxxx> wrote:

This patch adds functionality to the gpio-lib subsystem to
make it possible to enable the gpio-lib code even if the
architecture code didn't request to get it built in.

drivers/gpio/gpiolib.c: In function 'gpio_export':
drivers/gpio/gpiolib.c:432: error: 'struct class' has no member named 'devices'
drivers/gpio/gpiolib.c:456: error: implicit declaration of function 'device_create'
drivers/gpio/gpiolib.c:457: warning: assignment makes pointer from integer without a cast
drivers/gpio/gpiolib.c: In function 'gpio_unexport':
drivers/gpio/gpiolib.c:509: warning: passing argument 2 of 'class_find_device' from incompatible pointer type
drivers/gpio/gpiolib.c:509: error: too few arguments to function 'class_find_device'
drivers/gpio/gpiolib.c: In function 'gpiochip_export':
drivers/gpio/gpiolib.c:536: error: 'struct class' has no member named 'devices'
drivers/gpio/gpiolib.c:542: warning: assignment makes pointer from integer without a cast
drivers/gpio/gpiolib.c: In function 'gpiochip_unexport':
drivers/gpio/gpiolib.c:575: warning: passing argument 2 of 'class_find_device' from incompatible pointer type
drivers/gpio/gpiolib.c:575: error: too few arguments to function 'class_find_device'

I assume this patch was prepared against some ancient out-of-date
kernel such as current Linus mainline.

May be, but shuffling headers around would not have caused
that type of breakage.

I'm thinking some driver model changes broke the gpio sysfs
interface code, and this happens to show up right now because
that code wasn't previously getting built.

Grumph. I can easily switch the device_create() over to
use device_create_drvdata() -- didn't I already send in
a patch like that? -- but the other stuff is completely
backwards-incompatible.


beats me ididntdoitnobodysawmedoit.

But what I am repeatedly seeing is people cheerfully raising 2.6.27
patches against the 2.6.26 tree when we have a nice 2.6.27 tree for
developing against. Those days are over, guys.



I'm also seeing obvious signs that developers aren't _testing_ their
new code within the context of the 2.6.27 tree. They're obviously
testing their stuff against 2.6.26 and then hoping and praying, only it
doesn't always work out for them.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages