mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Tobias Müller" <Tobias_Mueller@twam.info>
To: Andres Salomon <dilinger@collabora.co.uk>
Cc: akpm@linux-foundation.org, Randy Dunlap <randy.dunlap@oracle.com>,
	deepak@laptop.org, Takashi Iwai <tiwai@suse.de>,
	linux-kernel@vger.kernel.org, linux-geode@lists.infradead.org,
	jordan@cosmicpenguin.net, cjb@laptop.org
Subject: Re: [PATCH 1/2] cs5535-gpio: add AMD CS5535/CS5536 GPIO driver  support
Date: Thu, 11 Jun 2009 22:11:58 +0200	[thread overview]
Message-ID: <17be05570906111311s717f126cyd4edf0847b839eef@mail.gmail.com> (raw)
In-Reply-To: <20090611160059.6d70f54a@mycelium.queued.net>

>>  #define DRV_NAME "cs5535-gpio"
>>  #define GPIO_BAR 1
>> +#define GPIO_DEFAULT_MASK 0x0B003C66
>
> Where does this mask of available GPIOs originate from?

I had a comment in my original patch:

/**
* Some GPIO pins
*  31-29,23 : reserved (always mask out)
*  28       : Power Button
*  26       : PME#
*  22-16    : LPC
*  14,15    : SMBus
*  9,8      : UART1
*  7        : PCI INTB
*  3,4      : UART2/DDC
*  2        : IDE_IRQ0
*  1        : AC_BEEP
*  0        : PCI INTA
*
* If a mask was not specified, be conservative and only allow:
*  1,2,5,6,10-13,24,25,27
*/

I'll add this in my patch to clear it out.

>> +     spin_lock_irqsave(&chip->lock, flags);
>> +
>> +     /* check if this pin is available */
>> +     if ((mask & (1 << offset)) == 0) {
>> +             printk(KERN_INFO DRV_NAME
>> +                    ": pin %u is not available (check mask)\n",
>> offset);
>> +             return -EINVAL;
>
> There's a locking error here; you really want to spin_unlock_irqrestore
> before returning.

Thanks.

>> +     /* disable output aux 1 & 2 on this pin */
>> +     __cs5535_gpio_clear(chip, offset, GPIO_OUTPUT_AUX1);
>> +     __cs5535_gpio_clear(chip, offset, GPIO_OUTPUT_AUX2);
>> +
>> +     /* disable input aux 1 on this pin */
>> +     __cs5535_gpio_clear(chip, offset, GPIO_INPUT_AUX1);
>> +
>> +     /* disable output */
>> +     __cs5535_gpio_clear(chip, offset, GPIO_OUTPUT_ENABLE);
>> +
>> +     /* enable input */
>> +     __cs5535_gpio_set(chip, offset, GPIO_INPUT_ENABLE);
>
> I don't think this is the right place for all of this.  Your earlier
> email mentioned disabling OUT_AUX{1,2} for outputs, and IN_AUX for
> inputs.  I'm fine with doing that here, but I don't see why you're also
> disabling output and enabling input by default.

I mentioned this in an ealier mail too. When I request the GPIO from
userspace the direction file always contains "in", so I thought
this is the standard direction after resetting as I should be in a
defined state after requesting. But I didn't found anything
about this in GPIO lib documentation, so I would be fine to change
this if there is any common default behavoir.

>> -             .ngpio = 28,
>> +             .ngpio = 32,
>
> Since GPIOs 29-31 aren't externally available, and 28 is
> unavailable anyways, shouldn't we just set ngpio to 28?
I thought that 32 is in consistency with the datasheet as it always
talks about 32 GPIO pins.

  reply	other threads:[~2009-06-11 20:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-10  4:10 Andres Salomon
2009-06-11 14:46 ` Tobias Müller
2009-06-11 15:16   ` Andres Salomon
2009-06-11 18:52 ` Tobias Müller
2009-06-11 20:00   ` Andres Salomon
2009-06-11 20:11     ` Tobias Müller [this message]
2009-06-11 21:28       ` Andres Salomon
2009-06-11 21:35         ` Tobias Müller
2009-06-13  0:23           ` Andres Salomon
2009-06-20 10:20             ` Tobias Müller
2009-07-01 22:32         ` David Brownell
2009-08-15 10:59           ` Tobias Müller
2009-08-18  4:43             ` Andres Salomon
2009-08-18  8:32               ` Tobias Müller

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=17be05570906111311s717f126cyd4edf0847b839eef@mail.gmail.com \
    --to=tobias_mueller@twam.info \
    --cc=akpm@linux-foundation.org \
    --cc=cjb@laptop.org \
    --cc=deepak@laptop.org \
    --cc=dilinger@collabora.co.uk \
    --cc=jordan@cosmicpenguin.net \
    --cc=linux-geode@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=randy.dunlap@oracle.com \
    --cc=tiwai@suse.de \
    /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

all inboxes | Powered by JetHome®