linux-kernel - Re: [PATCH] gpiolib: Allow user-selection

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:	Thu, 3 Jul 2008 10:42:16 +0200
From:	Michael Buesch <mb@...sch.de>
To:	David Brownell <david-b@...bell.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpiolib: Allow user-selection

On Thursday 03 July 2008 10:25:08 David Brownell wrote:
> On Wednesday 02 July 2008, Andrew Morton wrote:
> > 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'
> 
> Should be addressed by the following, at least in
> terms of build problems aginst linux-next.
> 
> The resulting kernel doesn't seem bootable on any
> board I currently have set up for testing gpio calls.
> The build dies in the TTY stack.


Thanks a lot Dave.
I'm going to try this with my bt878 card, once I got linux-next pulled and built.

> - Dave
> 
> 
> =============	CUT HERE
> Cope with some backwards-incompatible driver model API changes
> now in the linux-next tree:
> 
>  - device_create() is going away, even for drivers using it safely,
>    in favor of device_create_drvdata().
>  - class->devices is gone, but testing class->p serves the same
>    purpose (non-null when class is usable with driver model calls).
>  - class_find_device() needs a new argument #2 (NULL)
> 
> Signed-off-by: David Brownell <dbrownell@...rs.sourceforge.net>
> ---
>  drivers/gpio/gpiolib.c |   16 +++++++---------
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 
> --- a/drivers/gpio/gpiolib.c	2008-07-02 23:29:58.000000000 -0700
> +++ b/drivers/gpio/gpiolib.c	2008-07-03 00:04:57.000000000 -0700
> @@ -429,7 +429,7 @@ int gpio_export(unsigned gpio, bool dire
>  	int			status = -EINVAL;
>  
>  	/* can't export until sysfs is available ... */
> -	if (!gpio_class.devices.next) {
> +	if (!gpio_class.p) {
>  		pr_debug("%s: called too early!\n", __func__);
>  		return -ENOENT;
>  	}
> @@ -453,10 +453,9 @@ int gpio_export(unsigned gpio, bool dire
>  	if (status == 0) {
>  		struct device	*dev;
>  
> -		dev = device_create(&gpio_class, desc->chip->dev, 0,
> -				"gpio%d", gpio);
> +		dev = device_create_drvdata(&gpio_class, desc->chip->dev, 0,
> +				desc, "gpio%d", gpio);
>  		if (dev) {
> -			dev_set_drvdata(dev, desc);
>  			if (direction_may_change)
>  				status = sysfs_create_group(&dev->kobj,
>  						&gpio_attr_group);
> @@ -506,7 +505,7 @@ void gpio_unexport(unsigned gpio)
>  	if (test_bit(FLAG_EXPORT, &desc->flags)) {
>  		struct device	*dev = NULL;
>  
> -		dev = class_find_device(&gpio_class, desc, match_export);
> +		dev = class_find_device(&gpio_class, NULL, desc, match_export);
>  		if (dev) {
>  			clear_bit(FLAG_EXPORT, &desc->flags);
>  			put_device(dev);
> @@ -533,15 +532,14 @@ static int gpiochip_export(struct gpio_c
>  	 * export this later, in gpiolib_sysfs_init() ... here we just
>  	 * verify that _some_ field of gpio_class got initialized.
>  	 */
> -	if (!gpio_class.devices.next)
> +	if (!gpio_class.p)
>  		return 0;
>  
>  	/* use chip->base for the ID; it's already known to be unique */
>  	mutex_lock(&sysfs_lock);
> -	dev = device_create(&gpio_class, chip->dev, 0,
> +	dev = device_create_drvdata(&gpio_class, chip->dev, 0, chip,
>  			"gpiochip%d", chip->base);
>  	if (dev) {
> -		dev_set_drvdata(dev, chip);
>  		status = sysfs_create_group(&dev->kobj,
>  				&gpiochip_attr_group);
>  	} else
> @@ -572,7 +570,7 @@ static void gpiochip_unexport(struct gpi
>  	struct device		*dev;
>  
>  	mutex_lock(&sysfs_lock);
> -	dev = class_find_device(&gpio_class, chip, match_export);
> +	dev = class_find_device(&gpio_class, NULL, chip, match_export);
>  	if (dev) {
>  		put_device(dev);
>  		device_unregister(dev);
> 
> 
> 



-- 
Greetings Michael.
--
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/