linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@openwrt.org>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Kalle Valo <kvalo@codeaurora.org>,
	Hauke Mehrtens <hauke@hauke-m.de>
Subject: Re: [PATCH 1/2] bcma: use absolute base for SoC GPIO pins
Date: Wed, 15 Apr 2015 16:36:17 +0200	[thread overview]
Message-ID: <552E7761.2040902@openwrt.org> (raw)
In-Reply-To: <CACna6ryFjs+YHKUx2WTe5j5xctzD1Aru2qwP=F63TRpMd+FbZQ@mail.gmail.com>

On 2015-04-15 16:33, Rafał Miłecki wrote:
> On 15 April 2015 at 15:07, Felix Fietkau <nbd@openwrt.org> wrote:
>> @@ -235,16 +235,17 @@ int bcma_gpio_init(struct bcma_drv_cc *cc)
>>         }
>>
>>         /*
>> -        * On MIPS we register GPIO devices (LEDs, buttons) using absolute GPIO
>> -        * pin numbers. We don't have Device Tree there and we can't really use
>> -        * relative (per chip) numbers.
>> -        * So let's use predictable base for BCM47XX and "random" for all other.
>> +        * Register SoC GPIO devices with absolute GPIO pin base.
>> +        * On MIPS, we don't have Device Tree and we can't use relative (per chip)
>> +        * GPIO numbers.
>> +        * On some ARM devices, user space may want to access some system GPIO
>> +        * pins directly, which is easier to do with a predictable GPIO base.
>>          */
>> -#if IS_BUILTIN(CONFIG_BCM47XX)
>> -       chip->base              = bus->num * BCMA_GPIO_MAX_PINS;
>> -#else
>> -       chip->base              = -1;
>> -#endif
>> +       if (IS_BUILTIN(CONFIG_BCM47XX) ||
>> +           cc->core->bus->hosttype == BCMA_HOSTTYPE_SOC)
>> +               chip->base              = bus->num * BCMA_GPIO_MAX_PINS;
>> +       else
>> +               chip->base              = -1;
> 
> Is there any chance you will need predictable GPIO numbers of extra
> bcma buses on ARM? Like accessing GPIO of PCIe card from user space?
> Then you could prefer IS_BUILTIN(CONFIG_ARCH_BCM_5301X)
> 
> Anyway, I'm OK with this patch.
I don't think I need it, and I didn't want this change to produce
conflicts on multi-arch builds, so I limited it to the SoC bus only.

- Felix

  reply	other threads:[~2015-04-15 14:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-15 13:07 [PATCH 1/2] bcma: use absolute base for SoC GPIO pins Felix Fietkau
2015-04-15 13:07 ` [PATCH 2/2] bcma: enable 32 GPIO pins for BCM4707 Felix Fietkau
2015-04-15 14:33   ` Rafał Miłecki
2015-04-15 14:33 ` [PATCH 1/2] bcma: use absolute base for SoC GPIO pins Rafał Miłecki
2015-04-15 14:36   ` Felix Fietkau [this message]
2015-04-15 14:53     ` Rafał Miłecki
2015-05-09 13:31 ` [1/2] " Kalle Valo

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=552E7761.2040902@openwrt.org \
    --to=nbd@openwrt.org \
    --cc=hauke@hauke-m.de \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=zajec5@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).