public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: David Brownell <david-b@pacbell.net>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	sfr@canb.auug.org.au, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gpiolib: Allow user-selection
Date: Thu, 3 Jul 2008 10:42:16 +0200	[thread overview]
Message-ID: <200807031042.16296.mb@bu3sch.de> (raw)
In-Reply-To: <200807030125.08247.david-b@pacbell.net>

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@users.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.

      reply	other threads:[~2008-07-03 12:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-02 21:46 [PATCH] gpiolib: Allow user-selection Michael Buesch
2008-07-03  0:04 ` Andrew Morton
2008-07-03  0:26   ` Michael Buesch
2008-07-03  5:00   ` David Brownell
2008-07-03  5:08     ` Andrew Morton
2008-07-03  5:41       ` David Brownell
2008-07-03 19:37         ` Greg KH
2008-07-03 21:28           ` David Brownell
2008-07-03 23:08             ` Greg KH
2008-07-12  5:32               ` David Brownell
2008-07-03  8:36       ` Rene Herman
2008-07-03  9:01         ` Andrew Morton
2008-07-03 10:19           ` Rene Herman
2008-07-03  8:25   ` David Brownell
2008-07-03  8:42     ` Michael Buesch [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200807031042.16296.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=akpm@linux-foundation.org \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox