[PATCH] mt76: Add missing include of linux/module.h

2018-12-02 Thread Hauke Mehrtens
MODULE_FIRMWARE() is used in usb_mcu.c and provided by linux/module.h,
but this header file is not directly included. This causes problems in
backports with some kernel versions.

Add the missing include.

Signed-off-by: Hauke Mehrtens 
---
 drivers/net/wireless/mediatek/mt76/mt76x0/usb_mcu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/mediatek/mt76/mt76x0/usb_mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt76x0/usb_mcu.c
index a9f14d5149d1..b2b3fd0db4bb 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x0/usb_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x0/usb_mcu.c
@@ -15,6 +15,7 @@
  */
 #include 
 #include 
+#include 
 
 #include "mt76x0.h"
 #include "mcu.h"
-- 
2.11.0



[PATCH 1/2] iw: Make input to mac_addr_n2a() const

2018-10-10 Thread Hauke Mehrtens
The parameter is not modified, so we can make it constant. This makes it
possible to provide other const parameters to this function.

Signed-off-by: Hauke Mehrtens 
---
 iw.h   | 2 +-
 util.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/iw.h b/iw.h
index 47aa27d..bdd39ee 100644
--- a/iw.h
+++ b/iw.h
@@ -175,7 +175,7 @@ int valid_handler(struct nl_msg *msg, void *arg);
 void register_handler(int (*handler)(struct nl_msg *, void *), void *data);
 
 int mac_addr_a2n(unsigned char *mac_addr, char *arg);
-void mac_addr_n2a(char *mac_addr, unsigned char *arg);
+void mac_addr_n2a(char *mac_addr, const unsigned char *arg);
 int parse_hex_mask(char *hexmask, unsigned char **result, size_t *result_len,
   unsigned char **mask);
 unsigned char *parse_hex(char *hex, size_t *outlen);
diff --git a/util.c b/util.c
index 5b286b7..796549e 100644
--- a/util.c
+++ b/util.c
@@ -5,7 +5,7 @@
 #include "iw.h"
 #include "nl80211.h"
 
-void mac_addr_n2a(char *mac_addr, unsigned char *arg)
+void mac_addr_n2a(char *mac_addr, const unsigned char *arg)
 {
int i, l;
 
-- 
2.11.0



[PATCH 2/2] iw: scan: parse OWE Transition Mode element

2018-10-10 Thread Hauke Mehrtens
This adds code to parse the Opportunistic Wireless Encryption Transition
Mode element.

Without this patch the output looks like this:
WFA 0x1c, data: 00 37 b7 36 dc 0c 08 4f 70 65 6e 57 72 74 34
With this patch it looks like this:
OWE Transition Mode:
BSSID: 00:37:b7:36:dc:0c
SSID: OpenWrt4

Signed-off-by: Hauke Mehrtens 
---
 scan.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/scan.c b/scan.c
index 7695216..a798c70 100644
--- a/scan.c
+++ b/scan.c
@@ -1950,10 +1950,39 @@ static inline void print_hs20_ind(const uint8_t type, 
uint8_t len,
printf("\t\tUnexpected length: %i\n", len);
 }
 
+static void print_wifi_owe_tarns(const uint8_t type, uint8_t len,
+const uint8_t *data,
+const struct print_ies_data *ie_buffer)
+{
+   char mac_addr[20];
+   int ssid_len;
+
+   printf("\n");
+   if (len < 7)
+   return;
+
+   mac_addr_n2a(mac_addr, data);
+   printf("\t\tBSSID: %s\n", mac_addr);
+
+   ssid_len = data[6];
+   if (ssid_len > len - 7)
+   return;
+   printf("\t\tSSID: ");
+   print_ssid_escaped(ssid_len, data + 7);
+   printf("\n");
+
+   /* optional elements */
+   if (len >= ssid_len + 9) {
+   printf("\t\tBand Info: %u\n", data[ssid_len + 7]);
+   printf("\t\tChannel Info: %u\n", data[ssid_len + 8]);
+   }
+}
+
 static const struct ie_print wfa_printers[] = {
[9] = { "P2P", print_p2p, 2, 255, BIT(PRINT_SCAN), },
[16] = { "HotSpot 2.0 Indication", print_hs20_ind, 1, 255, 
BIT(PRINT_SCAN), },
[18] = { "HotSpot 2.0 OSEN", print_wifi_osen, 1, 255, BIT(PRINT_SCAN), 
},
+   [28] = { "OWE Transition Mode", print_wifi_owe_tarns, 7, 255, 
BIT(PRINT_SCAN), },
 };
 
 static void print_vendor(unsigned char len, unsigned char *data,
-- 
2.11.0



[PATCH] wireless-regdb: remove dependency to python attr

2018-10-06 Thread Hauke Mehrtens
Commit 8607edfdb6568 ("wireless-regdb: Parse wmm rule data") introduced
a dependency to the python module attr which is not included by default
in all python installations. Replace the code with manually coding the
constructor instead of using attr. This makes the code also work on
systems without attr.

I would like to avoid an additional dependency in OpenWrt where we
compile the regulatory database inside of the build system.

Signed-off-by: Hauke Mehrtens 
---
 dbparse.py | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/dbparse.py b/dbparse.py
index 5fe752b..993f757 100755
--- a/dbparse.py
+++ b/dbparse.py
@@ -5,7 +5,6 @@ from functools import total_ordering
 import sys, math
 from math import ceil, log
 from collections import defaultdict, OrderedDict
-import attr
 
 # must match  enum nl80211_reg_rule_flags
 
@@ -32,16 +31,17 @@ dfs_regions = {
 
 @total_ordering
 
-@attr.s(frozen=True, cmp=False)
 class WmmRule(object):
-vo_c = attr.ib()
-vi_c = attr.ib()
-be_c = attr.ib()
-bk_c = attr.ib()
-vo_ap = attr.ib()
-vi_ap = attr.ib()
-be_ap = attr.ib()
-bk_ap = attr.ib()
+
+def __init__(self, vo_c, vi_c, be_c, bk_c, vo_ap, vi_ap, be_ap, bk_ap):
+self.vo_c = vo_c
+self.vi_c = vi_c
+self.be_c = be_c
+self.bk_c = bk_c
+self.vo_ap = vo_ap
+self.vi_ap = vi_ap
+self.be_ap = be_ap
+self.bk_ap = bk_ap
 
 def _as_tuple(self):
 return (self.vo_c, self.vi_c, self.be_c, self.bk_c,
-- 
2.11.0



[PATCH iw] scan: Decode additional Authentication types

2018-10-05 Thread Hauke Mehrtens
This adds some more authentication types, the constants are taken from
hostapd. I only tested SAE, FT/SAE and OWE.

Signed-off-by: Hauke Mehrtens 
---
 scan.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/scan.c b/scan.c
index a621813..7695216 100644
--- a/scan.c
+++ b/scan.c
@@ -808,6 +808,36 @@ static void print_auth(const uint8_t *data)
case 7:
printf("TDLS/TPK");
break;
+   case 8:
+   printf("SAE");
+   break;
+   case 9:
+   printf("FT/SAE");
+   break;
+   case 11:
+   printf("IEEE 802.1X/SUITE-B");
+   break;
+   case 12:
+   printf("IEEE 802.1X/SUITE-B-192");
+   break;
+   case 13:
+   printf("FT/IEEE 802.1X/SHA-384");
+   break;
+   case 14:
+   printf("FILS/SHA-256");
+   break;
+   case 15:
+   printf("FILS/SHA-384");
+   break;
+   case 16:
+   printf("FT/FILS/SHA-256");
+   break;
+   case 17:
+   printf("FT/FILS/SHA-384");
+   break;
+   case 18:
+   printf("OWE");
+   break;
default:
printf("%.02x-%.02x-%.02x:%d",
data[0], data[1] ,data[2], data[3]);
@@ -818,6 +848,9 @@ static void print_auth(const uint8_t *data)
case 1:
printf("OSEN");
break;
+   case 2:
+   printf("DPP");
+   break;
default:
printf("%.02x-%.02x-%.02x:%d",
data[0], data[1] ,data[2], data[3]);
-- 
2.11.0



[PATCH] mt76: use skb_pad() instead of __skb_pad()

2018-09-25 Thread Hauke Mehrtens
mt76 uses __skb_pad() with free_on_error set to true, this is the same
as calling skb_pad().
This patch does not change any functionality, but it makes it easier to
backport this driver in backports, because skb_pad() is also available
in older kernel versions.

Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer")
Signed-off-by: Hauke Mehrtens 
---
 drivers/net/wireless/mediatek/mt76/usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/usb.c 
b/drivers/net/wireless/mediatek/mt76/usb.c
index 7780b07543bb..e03de13f5afe 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -535,7 +535,7 @@ int mt76u_skb_dma_info(struct sk_buff *skb, int port, u32 
flags)
}
 
if (unlikely(pad)) {
-   if (__skb_pad(last, pad, true))
+   if (skb_pad(last, pad))
return -ENOMEM;
__skb_put(last, pad);
}
-- 
2.11.0



Re: [PATCH] bcma: use bcma_debug and pr_cont in MIPS driver

2017-10-16 Thread Hauke Mehrtens
On 10/16/2017 02:54 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <ra...@milecki.pl>
> 
> Using bcma_debug gives a device-specific prefix for messages and pr_cont
> is a common helper for continuing a line.
> 
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>

Acked-By: Hauke Mehrtens <ha...@hauke-m.de>

> ---
>  drivers/bcma/driver_mips.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/bcma/driver_mips.c b/drivers/bcma/driver_mips.c
> index 89af807cf29c..5904ef1aa624 100644
> --- a/drivers/bcma/driver_mips.c
> +++ b/drivers/bcma/driver_mips.c
> @@ -184,10 +184,11 @@ static void bcma_core_mips_print_irq(struct bcma_device 
> *dev, unsigned int irq)
>  {
>   int i;
>   static const char *irq_name[] = {"2(S)", "3", "4", "5", "6", "D", "I"};
> - printk(KERN_DEBUG KBUILD_MODNAME ": core 0x%04x, irq :", dev->id.id);
> +
> + bcma_debug(dev->bus, "core 0x%04x, irq :", dev->id.id);
>   for (i = 0; i <= 6; i++)
> - printk(" %s%s", irq_name[i], i == irq ? "*" : " ");
> - printk("\n");
> + pr_cont(" %s%s", irq_name[i], i == irq ? "*" : " ");
> + pr_cont("\n");
>  }
>  
>  static void bcma_core_mips_dump_irq(struct bcma_bus *bus)
> 



[PATCH] ath10k: activate user space firmware loading again

2017-08-24 Thread Hauke Mehrtens
In commit 9f5bcfe93315 ("ath10k: silence firmware file probing
warnings") the firmware loading was changed from request_firmware() to
request_firmware_direct() to silence some warnings in case it fails.
request_firmware_direct() directly searches in the file system only and
does not send a hotplug event to user space in case it could not find
the firmware directly.
In LEDE we use a user space script to extract the calibration data from
the flash memory which gets triggered by the hotplug event. This way the
firmware gets extracted from some vendor specific partition when the
driver requests this firmware. This mechanism does not work any more
after this change.

Fixes: 9f5bcfe93315 ("ath10k: silence firmware file probing warnings")
Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
Cc: Michal Kazior <michal.kaz...@tieto.com>
---
 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 75c5c903c8a6..1ff662d6a703 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -519,7 +519,7 @@ static const struct firmware *ath10k_fetch_fw_file(struct 
ath10k *ar,
dir = ".";
 
snprintf(filename, sizeof(filename), "%s/%s", dir, file);
-   ret = request_firmware_direct(, filename, ar->dev);
+   ret = request_firmware(, filename, ar->dev);
ath10k_dbg(ar, ATH10K_DBG_BOOT, "boot fw request '%s': %d\n",
   filename, ret);
 
-- 
2.11.0



Re: [PATCH] bcma: init serial console directly from ChipCommon code

2016-01-22 Thread Hauke Mehrtens
On 01/22/2016 06:02 PM, Rafał Miłecki wrote:
> UART is connected to and controlled over ChipCommon core. It doesn't
> have much to do with MIPS core (where we initialize it currently)
> except just existing on embedded systemms. There isn't point of such
> cross-core initialization (and we needed #ifdef anyway) so just handle
> it in ChipCommon.
> 
> Signed-off-by: Rafał Miłecki <zaj...@gmail.com>

Reviewed-by: Hauke Mehrtens <ha...@hauke-m.de>

This looks good.

We should probably also move the registration of the serial console from
arch/mips/bcm47xx to bcma and ssb.

Hauke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP

2015-12-22 Thread Hauke Mehrtens
On 12/22/2015 10:01 AM, Linus Walleij wrote:
> On Fri, Dec 18, 2015 at 7:01 PM, Hauke Mehrtens <ha...@hauke-m.de> wrote:
>> On 12/18/2015 07:27 AM, Rafał Miłecki wrote:
>>> I'm afraid it wasn't tested on BCM47XX (MIPS) :(
>>
>> Yes, you are probably right.
>>
>>> On 14 August 2015 at 00:21, Hauke Mehrtens <ha...@hauke-m.de> wrote:
>>>> @@ -218,9 +187,8 @@ int bcma_gpio_init(struct bcma_drv_cc *cc)
>>>> chip->set   = bcma_gpio_set_value;
>>>> chip->direction_input   = bcma_gpio_direction_input;
>>>> chip->direction_output  = bcma_gpio_direction_output;
>>>> -#if IS_BUILTIN(CONFIG_BCM47XX) || IS_BUILTIN(CONFIG_ARCH_BCM_5301X)
>>>> -   chip->to_irq= bcma_gpio_to_irq;
>>>> -#endif
>>>> +   chip->owner = THIS_MODULE;
>>>> +   chip->dev   = bcma_bus_get_host_dev(bus);
>>>
>>> This assigns >host_pdev->dev which is NULL.
>>
>> hmm, how do we fix this, as long as bcma does not have a device on mips
>> this is a problem. Should we create a new device for mips?
> 
> Yes I think MIPS should just create a host device. That
> makes things simple and nice. Is it complex to do so?
> 
> Yours,
> Linus Walleij
> 
Currently the documentation says this for the parent member on struct
gpio_chip:

 * @parent: optional parent device providing the GPIOs

I assume the optional is wrong here.

Hauke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 153/182] bcma: gpio: use gpiochip data pointer

2015-12-09 Thread Hauke Mehrtens
On 12/09/2015 02:43 PM, Linus Walleij wrote:
> This makes the driver use the data pointer added to the gpio_chip
> to store a pointer to the state container instead of relying on
> container_of().
> 
> Cc: Rafał Miłecki <zaj...@gmail.com>
> Cc: Hauke Mehrtens <ha...@hauke-m.de>
> Cc: Kalle Valo <kv...@codeaurora.org>
> Cc: linux-wireless@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
> ---
> BCMA maintainers: please ACK this so I can take it through the
> GPIO tree.
> ---

Acked-by: Hauke Mehrtens <ha...@hauke-m.de>

>  drivers/bcma/driver_gpio.c | 23 +--
>  1 file changed, 9 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c
> index 949754427ce2..98067f757fb0 100644
> --- a/drivers/bcma/driver_gpio.c
> +++ b/drivers/bcma/driver_gpio.c
> @@ -17,14 +17,9 @@
>  
>  #define BCMA_GPIO_MAX_PINS   32
>  
> -static inline struct bcma_drv_cc *bcma_gpio_get_cc(struct gpio_chip *chip)
> -{
> - return container_of(chip, struct bcma_drv_cc, gpio);
> -}
> -
>  static int bcma_gpio_get_value(struct gpio_chip *chip, unsigned gpio)
>  {
> - struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
> + struct bcma_drv_cc *cc = gpiochip_get_data(chip);
>  
>   return !!bcma_chipco_gpio_in(cc, 1 << gpio);
>  }
> @@ -32,14 +27,14 @@ static int bcma_gpio_get_value(struct gpio_chip *chip, 
> unsigned gpio)
>  static void bcma_gpio_set_value(struct gpio_chip *chip, unsigned gpio,
>   int value)
>  {
> - struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
> + struct bcma_drv_cc *cc = gpiochip_get_data(chip);
>  
>   bcma_chipco_gpio_out(cc, 1 << gpio, value ? 1 << gpio : 0);
>  }
>  
>  static int bcma_gpio_direction_input(struct gpio_chip *chip, unsigned gpio)
>  {
> - struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
> + struct bcma_drv_cc *cc = gpiochip_get_data(chip);
>  
>   bcma_chipco_gpio_outen(cc, 1 << gpio, 0);
>   return 0;
> @@ -48,7 +43,7 @@ static int bcma_gpio_direction_input(struct gpio_chip 
> *chip, unsigned gpio)
>  static int bcma_gpio_direction_output(struct gpio_chip *chip, unsigned gpio,
> int value)
>  {
> - struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
> + struct bcma_drv_cc *cc = gpiochip_get_data(chip);
>  
>   bcma_chipco_gpio_outen(cc, 1 << gpio, 1 << gpio);
>   bcma_chipco_gpio_out(cc, 1 << gpio, value ? 1 << gpio : 0);
> @@ -57,7 +52,7 @@ static int bcma_gpio_direction_output(struct gpio_chip 
> *chip, unsigned gpio,
>  
>  static int bcma_gpio_request(struct gpio_chip *chip, unsigned gpio)
>  {
> - struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
> + struct bcma_drv_cc *cc = gpiochip_get_data(chip);
>  
>   bcma_chipco_gpio_control(cc, 1 << gpio, 0);
>   /* clear pulldown */
> @@ -70,7 +65,7 @@ static int bcma_gpio_request(struct gpio_chip *chip, 
> unsigned gpio)
>  
>  static void bcma_gpio_free(struct gpio_chip *chip, unsigned gpio)
>  {
> - struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
> + struct bcma_drv_cc *cc = gpiochip_get_data(chip);
>  
>   /* clear pullup */
>   bcma_chipco_gpio_pullup(cc, 1 << gpio, 0);
> @@ -81,7 +76,7 @@ static void bcma_gpio_free(struct gpio_chip *chip, unsigned 
> gpio)
>  static void bcma_gpio_irq_unmask(struct irq_data *d)
>  {
>   struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> - struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
> + struct bcma_drv_cc *cc = gpiochip_get_data(gc);
>   int gpio = irqd_to_hwirq(d);
>   u32 val = bcma_chipco_gpio_in(cc, BIT(gpio));
>  
> @@ -92,7 +87,7 @@ static void bcma_gpio_irq_unmask(struct irq_data *d)
>  static void bcma_gpio_irq_mask(struct irq_data *d)
>  {
>   struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
> - struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
> + struct bcma_drv_cc *cc = gpiochip_get_data(gc);
>   int gpio = irqd_to_hwirq(d);
>  
>   bcma_chipco_gpio_intmask(cc, BIT(gpio), 0);
> @@ -216,7 +211,7 @@ int bcma_gpio_init(struct bcma_drv_cc *cc)
>   else
>   chip->base  = -1;
>  
> - err = gpiochip_add(chip);
> + err = gpiochip_add_data(chip, cc);
>   if (err)
>   return err;
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 06/27] brcm80211: move under broadcom vendor directory

2015-11-21 Thread Hauke Mehrtens
On 11/20/2015 10:53 PM, Arend van Spriel wrote:
> On 11/19/2015 08:48 AM, Kalle Valo wrote:
>> Hauke Mehrtens <ha...@hauke-m.de> writes:
>>
>>> On 11/18/2015 03:45 PM, Kalle Valo wrote:
>>>> Part of reorganising wireless drivers directory and Kconfig. Note
>>>> that I had to
>>>> edit Makefiles from subdirectories to use the new location.
>>>>
>>>> Signed-off-by: Kalle Valo <kv...@codeaurora.org>
>>>> ---
>>>
>>> I would prefer to remove the brcm80211 directory in this process and
>>> create:
>>> drivers/net/wireless/broadcom/brcmfmac
>>> drivers/net/wireless/broadcom/brcmsmac
>>> drivers/net/wireless/broadcom/brcmutil
>>> drivers/net/wireless/broadcom/include
>>>
>>> This way we have one directory less.
>>
>> I think this could be done separately. This patchset is big enough
>> already, I would not like to make it anymore complicated.
>>
>> And I actually like the brcm80211 directory, I would not mind keeping it
>> still.
> 
> I prefer to keep it as brcmsmac and brcmfmac rely on brcmutil module so
> I want to keep them together under brcm80211.
> 
> So does this patch go in before or after the patches I submitted before
> the merge window. I hope after :-p

Ok, then leave it like Kalle proposed. backports should work with both
versions.

Hauke

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 06/27] brcm80211: move under broadcom vendor directory

2015-11-18 Thread Hauke Mehrtens
On 11/18/2015 03:45 PM, Kalle Valo wrote:
> Part of reorganising wireless drivers directory and Kconfig. Note that I had 
> to
> edit Makefiles from subdirectories to use the new location.
> 
> Signed-off-by: Kalle Valo 
> ---

I would prefer to remove the brcm80211 directory in this process and create:
drivers/net/wireless/broadcom/brcmfmac
drivers/net/wireless/broadcom/brcmsmac
drivers/net/wireless/broadcom/brcmutil
drivers/net/wireless/broadcom/include

This way we have one directory less.

Hauke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] iwlwifi: fix requested firmware name for iwlwifi-3160

2015-09-22 Thread Hauke Mehrtens
On 09/22/2015 10:46 AM, Johannes Berg wrote:
> On Tue, 2015-09-22 at 10:44 +0200, Johannes Berg wrote:
>> On Sat, 2015-09-19 at 12:39 +0200, Hauke Mehrtens wrote:
>>> modinfo iwlwifi showed the following required firmware:
>>> firmware: iwlwifi-3160-IWL3160_UCODE_API_OK.ucode
>>
>> This is obviously wrong.
>>
>>>
>>>  MODULE_FIRMWARE(IWL7260_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
>>> -MODULE_FIRMWARE(IWL3160_MODULE_FIRMWARE(IWL3160_UCODE_API_OK));
>>> +MODULE_FIRMWARE(IWL3160_MODULE_FIRMWARE(IWL3165_UCODE_API_OK));
>>>
>> But this is also wrong, it should be 7260, and there should be a
>> separate entry for 3165. I'll get a patch on the way to fix it.
>>
> 
> Actually, no, there shouldn't be another entry since 3165 uses the same
> firmware as 7265-D.
> 
> johannes

Should I change something?

iwl3165 uses iwl3160 firmware, but support for that was added in rev 13
of that firmware. That's the information I got from the driver and the
linux-firmware commit messages.

Hauke
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] iwlwifi: fix requested firmware name for iwlwifi-3160

2015-09-19 Thread Hauke Mehrtens
modinfo iwlwifi showed the following required firmware:
firmware: iwlwifi-3160-IWL3160_UCODE_API_OK.ucode

Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
---
 drivers/net/wireless/iwlwifi/iwl-7000.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-7000.c 
b/drivers/net/wireless/iwlwifi/iwl-7000.c
index 6951aba..bccd2d2 100644
--- a/drivers/net/wireless/iwlwifi/iwl-7000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-7000.c
@@ -348,6 +348,6 @@ const struct iwl_cfg iwl7265d_n_cfg = {
 };
 
 MODULE_FIRMWARE(IWL7260_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
-MODULE_FIRMWARE(IWL3160_MODULE_FIRMWARE(IWL3160_UCODE_API_OK));
+MODULE_FIRMWARE(IWL3160_MODULE_FIRMWARE(IWL3165_UCODE_API_OK));
 MODULE_FIRMWARE(IWL7265_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
 MODULE_FIRMWARE(IWL7265D_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] brcmfmac: include linux/atomic.h

2015-09-19 Thread Hauke Mehrtens
brcmfmac uses atomic_or() and other atomic_* functions, but does not
include linux/atomic.h. This file gets included by some other header
file so this normally does not cause problems.

Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
---
 drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
index f990e3d..ea9150b 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
@@ -15,6 +15,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] bcma: add support for population subnodes also when build as module

2015-09-19 Thread Hauke Mehrtens
of_default_bus_match_table was not exported earlier, so it could only
be accessed by code compiled into the kernel. A new function
of_platform_default_populate() was added which uses
of_default_bus_match_table and this function is also exported. This way
it is possible to create a bus with the content of
of_default_bus_match_table and we can remove the hacks from bcma.

Signed-off-by: Hauke Mehrtens <ha...@hauke-m.de>
---
 drivers/bcma/main.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 24882c1..59d8d0d 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -436,13 +436,8 @@ int bcma_bus_register(struct bcma_bus *bus)
}
 
dev = bcma_bus_get_host_dev(bus);
-   /* TODO: remove check for IS_BUILTIN(CONFIG_BCMA) check when
-* of_default_bus_match_table is exported or in some other way
-* accessible. This is just a temporary workaround.
-*/
-   if (IS_BUILTIN(CONFIG_BCMA) && dev) {
-   of_platform_populate(dev->of_node, of_default_bus_match_table,
-NULL, dev);
+   if (dev) {
+   of_platform_default_populate(dev->of_node, NULL, dev);
}
 
/* Cores providing flash access go before SPROM init */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP

2015-08-13 Thread Hauke Mehrtens
From: Linus Walleij linus.wall...@linaro.org

This switches the BCMA GPIO driver to use GPIOLIB_IRQCHIP to
handle its interrupts instead of rolling its own copy of the
irqdomain handling etc.

Signed-off-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---

changes since:
v2:
 * use bcma_bus_get_host_dev()

v1:
 * I fixed some bugs in the original patch, some of them are compile 
   errors and others caused some runtime problems.

 drivers/bcma/Kconfig|  2 +-
 drivers/bcma/driver_gpio.c  | 92 ++---
 include/linux/bcma/bcma_driver_chipcommon.h |  1 -
 3 files changed, 31 insertions(+), 64 deletions(-)

diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index be5fffb..023d448 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -92,7 +92,7 @@ config BCMA_DRIVER_GMAC_CMN
 config BCMA_DRIVER_GPIO
bool BCMA GPIO driver
depends on BCMA  GPIOLIB
-   select IRQ_DOMAIN if BCMA_HOST_SOC
+   select GPIOLIB_IRQCHIP if BCMA_HOST_SOC
help
  Driver to provide access to the GPIO pins of the bcma bus.
 
diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c
index 5f6018e..504899a7 100644
--- a/drivers/bcma/driver_gpio.c
+++ b/drivers/bcma/driver_gpio.c
@@ -8,10 +8,8 @@
  * Licensed under the GNU/GPL. See COPYING for details.
  */
 
-#include linux/gpio.h
-#include linux/irq.h
+#include linux/gpio/driver.h
 #include linux/interrupt.h
-#include linux/irqdomain.h
 #include linux/export.h
 #include linux/bcma/bcma.h
 
@@ -79,19 +77,11 @@ static void bcma_gpio_free(struct gpio_chip *chip, unsigned 
gpio)
 }
 
 #if IS_BUILTIN(CONFIG_BCM47XX) || IS_BUILTIN(CONFIG_ARCH_BCM_5301X)
-static int bcma_gpio_to_irq(struct gpio_chip *chip, unsigned gpio)
-{
-   struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
-
-   if (cc-core-bus-hosttype == BCMA_HOSTTYPE_SOC)
-   return irq_find_mapping(cc-irq_domain, gpio);
-   else
-   return -EINVAL;
-}
 
 static void bcma_gpio_irq_unmask(struct irq_data *d)
 {
-   struct bcma_drv_cc *cc = irq_data_get_irq_chip_data(d);
+   struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+   struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
int gpio = irqd_to_hwirq(d);
u32 val = bcma_chipco_gpio_in(cc, BIT(gpio));
 
@@ -101,7 +91,8 @@ static void bcma_gpio_irq_unmask(struct irq_data *d)
 
 static void bcma_gpio_irq_mask(struct irq_data *d)
 {
-   struct bcma_drv_cc *cc = irq_data_get_irq_chip_data(d);
+   struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+   struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
int gpio = irqd_to_hwirq(d);
 
bcma_chipco_gpio_intmask(cc, BIT(gpio), 0);
@@ -116,6 +107,7 @@ static struct irq_chip bcma_gpio_irq_chip = {
 static irqreturn_t bcma_gpio_irq_handler(int irq, void *dev_id)
 {
struct bcma_drv_cc *cc = dev_id;
+   struct gpio_chip *gc = cc-gpio;
u32 val = bcma_cc_read32(cc, BCMA_CC_GPIOIN);
u32 mask = bcma_cc_read32(cc, BCMA_CC_GPIOIRQ);
u32 pol = bcma_cc_read32(cc, BCMA_CC_GPIOPOL);
@@ -125,81 +117,58 @@ static irqreturn_t bcma_gpio_irq_handler(int irq, void 
*dev_id)
if (!irqs)
return IRQ_NONE;
 
-   for_each_set_bit(gpio, irqs, cc-gpio.ngpio)
-   generic_handle_irq(bcma_gpio_to_irq(cc-gpio, gpio));
+   for_each_set_bit(gpio, irqs, gc-ngpio)
+   generic_handle_irq(irq_find_mapping(gc-irqdomain, gpio));
bcma_chipco_gpio_polarity(cc, irqs, val  irqs);
 
return IRQ_HANDLED;
 }
 
-static int bcma_gpio_irq_domain_init(struct bcma_drv_cc *cc)
+static int bcma_gpio_irq_init(struct bcma_drv_cc *cc)
 {
struct gpio_chip *chip = cc-gpio;
-   int gpio, hwirq, err;
+   int hwirq, err;
 
if (cc-core-bus-hosttype != BCMA_HOSTTYPE_SOC)
return 0;
 
-   cc-irq_domain = irq_domain_add_linear(NULL, chip-ngpio,
-  irq_domain_simple_ops, cc);
-   if (!cc-irq_domain) {
-   err = -ENODEV;
-   goto err_irq_domain;
-   }
-   for (gpio = 0; gpio  chip-ngpio; gpio++) {
-   int irq = irq_create_mapping(cc-irq_domain, gpio);
-
-   irq_set_chip_data(irq, cc);
-   irq_set_chip_and_handler(irq, bcma_gpio_irq_chip,
-handle_simple_irq);
-   }
-
hwirq = bcma_core_irq(cc-core, 0);
err = request_irq(hwirq, bcma_gpio_irq_handler, IRQF_SHARED, gpio,
  cc);
if (err)
-   goto err_req_irq;
+   return err;
 
bcma_chipco_gpio_intmask(cc, ~0, 0);
bcma_cc_set32(cc, BCMA_CC_IRQMASK, BCMA_CC_IRQ_GPIO);
 
-   return 0;
-
-err_req_irq:
-   for (gpio = 0; gpio  chip-ngpio; gpio++) {
-   int irq = irq_find_mapping(cc-irq_domain, gpio

Re: [PATCH] bcma: populate bus DT subnodes as platform_device-s

2015-08-02 Thread Hauke Mehrtens
On 06/28/2015 05:17 PM, Rafał Miłecki wrote:
 Our bus should allow defining children nodes as we may want to specify
 devices attached to the bus. This is required e.g. to specify NAND or
 ChipCommon cores and use bus's address and IRQ mappings.
 
 Signed-off-by: Rafał Miłecki zaj...@gmail.com
 ---
  drivers/bcma/main.c | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
 index 9635f10..5912847 100644
 --- a/drivers/bcma/main.c
 +++ b/drivers/bcma/main.c
 @@ -12,6 +12,7 @@
  #include linux/slab.h
  #include linux/of_address.h
  #include linux/of_irq.h
 +#include linux/of_platform.h
  
  MODULE_DESCRIPTION(Broadcom's specific AMBA driver);
  MODULE_LICENSE(GPL);
 @@ -409,6 +410,13 @@ int bcma_bus_register(struct bcma_bus *bus)
   bcma_core_pci_early_init(bus-drv_pci[0]);
   }
  
 + if (bus-host_pdev) {

Here is an other problem. So many bugs in this line. ;-)
host_pdev is in a union so this is also true for PCIe devices, but then
the offset of the dev structure probably is wrong. You should check for
the hosttype. I will send a patch.

 + struct device *dev = bus-host_pdev-dev;
 +
 + of_platform_populate(dev-of_node, of_default_bus_match_table,
 +  NULL, dev);
 + }
 +
   /* Cores providing flash access go before SPROM init */
   list_for_each_entry(core, bus-cores, list) {
   if (bcma_is_core_needed_early(core-id.id))
 

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP

2015-08-02 Thread Hauke Mehrtens
On 08/02/2015 08:00 PM, Hauke Mehrtens wrote:
 From: Linus Walleij linus.wall...@linaro.org
 
 This switches the BCMA GPIO driver to use GPIOLIB_IRQCHIP to
 handle its interrupts instead of rolling its own copy of the
 irqdomain handling etc.
 
 Signed-off-by: Linus Walleij linus.wall...@linaro.org
 Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
 ---
 
 I fixed some bugs in the original patch, some of them are compile 
 errors and others caused some runtime problems. This patch worked on my 
 BCM4708 based device, I was able to receive an IRQ for a GPIO change 
 (button press).
 
 I think this should go through the wireless tree.
 
 @Linus could you please check if the changes I did are correct?
 
  drivers/bcma/Kconfig|   2 +-
  drivers/bcma/driver_gpio.c  | 105 
 
  include/linux/bcma/bcma_driver_chipcommon.h |   1 -
  3 files changed, 44 insertions(+), 64 deletions(-)
 

.

 @@ -218,9 +190,18 @@ int bcma_gpio_init(struct bcma_drv_cc *cc)
   chip-set   = bcma_gpio_set_value;
   chip-direction_input   = bcma_gpio_direction_input;
   chip-direction_output  = bcma_gpio_direction_output;
 -#if IS_BUILTIN(CONFIG_BCM47XX) || IS_BUILTIN(CONFIG_ARCH_BCM_5301X)
 - chip-to_irq= bcma_gpio_to_irq;
 -#endif
 + chip-owner = THIS_MODULE;
 + switch (bus-hosttype) {
 + case BCMA_HOSTTYPE_PCI:
 + chip-dev   = bus-host_pci-dev;
 + break;
 + case BCMA_HOSTTYPE_SOC:
 + chip-dev   = bus-host_pdev-dev;
 + break;
 + case BCMA_HOSTTYPE_SDIO:
 + chip-dev   = bus-host_sdio-dev;
 + break;
 + }

I will replace this part with a call to the newly introduced function
bcma_bus_get_host_dev() in a new version of this patch.

This function was introduced in bcma: fix access to host_pdev for PCIe
devices

.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP

2015-08-02 Thread Hauke Mehrtens
From: Linus Walleij linus.wall...@linaro.org

This switches the BCMA GPIO driver to use GPIOLIB_IRQCHIP to
handle its interrupts instead of rolling its own copy of the
irqdomain handling etc.

Signed-off-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---

I fixed some bugs in the original patch, some of them are compile 
errors and others caused some runtime problems. This patch worked on my 
BCM4708 based device, I was able to receive an IRQ for a GPIO change 
(button press).

I think this should go through the wireless tree.

@Linus could you please check if the changes I did are correct?

 drivers/bcma/Kconfig|   2 +-
 drivers/bcma/driver_gpio.c  | 105 
 include/linux/bcma/bcma_driver_chipcommon.h |   1 -
 3 files changed, 44 insertions(+), 64 deletions(-)

diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index be5fffb..023d448 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -92,7 +92,7 @@ config BCMA_DRIVER_GMAC_CMN
 config BCMA_DRIVER_GPIO
bool BCMA GPIO driver
depends on BCMA  GPIOLIB
-   select IRQ_DOMAIN if BCMA_HOST_SOC
+   select GPIOLIB_IRQCHIP if BCMA_HOST_SOC
help
  Driver to provide access to the GPIO pins of the bcma bus.
 
diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c
index 5f6018e..6715090 100644
--- a/drivers/bcma/driver_gpio.c
+++ b/drivers/bcma/driver_gpio.c
@@ -8,12 +8,13 @@
  * Licensed under the GNU/GPL. See COPYING for details.
  */
 
-#include linux/gpio.h
-#include linux/irq.h
+#include linux/gpio/driver.h
 #include linux/interrupt.h
-#include linux/irqdomain.h
 #include linux/export.h
 #include linux/bcma/bcma.h
+#include linux/mmc/sdio_func.h
+#include linux/platform_device.h
+#include linux/pci.h
 
 #include bcma_private.h
 
@@ -79,19 +80,11 @@ static void bcma_gpio_free(struct gpio_chip *chip, unsigned 
gpio)
 }
 
 #if IS_BUILTIN(CONFIG_BCM47XX) || IS_BUILTIN(CONFIG_ARCH_BCM_5301X)
-static int bcma_gpio_to_irq(struct gpio_chip *chip, unsigned gpio)
-{
-   struct bcma_drv_cc *cc = bcma_gpio_get_cc(chip);
-
-   if (cc-core-bus-hosttype == BCMA_HOSTTYPE_SOC)
-   return irq_find_mapping(cc-irq_domain, gpio);
-   else
-   return -EINVAL;
-}
 
 static void bcma_gpio_irq_unmask(struct irq_data *d)
 {
-   struct bcma_drv_cc *cc = irq_data_get_irq_chip_data(d);
+   struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+   struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
int gpio = irqd_to_hwirq(d);
u32 val = bcma_chipco_gpio_in(cc, BIT(gpio));
 
@@ -101,7 +94,8 @@ static void bcma_gpio_irq_unmask(struct irq_data *d)
 
 static void bcma_gpio_irq_mask(struct irq_data *d)
 {
-   struct bcma_drv_cc *cc = irq_data_get_irq_chip_data(d);
+   struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
+   struct bcma_drv_cc *cc = bcma_gpio_get_cc(gc);
int gpio = irqd_to_hwirq(d);
 
bcma_chipco_gpio_intmask(cc, BIT(gpio), 0);
@@ -116,6 +110,7 @@ static struct irq_chip bcma_gpio_irq_chip = {
 static irqreturn_t bcma_gpio_irq_handler(int irq, void *dev_id)
 {
struct bcma_drv_cc *cc = dev_id;
+   struct gpio_chip *gc = cc-gpio;
u32 val = bcma_cc_read32(cc, BCMA_CC_GPIOIN);
u32 mask = bcma_cc_read32(cc, BCMA_CC_GPIOIRQ);
u32 pol = bcma_cc_read32(cc, BCMA_CC_GPIOPOL);
@@ -125,81 +120,58 @@ static irqreturn_t bcma_gpio_irq_handler(int irq, void 
*dev_id)
if (!irqs)
return IRQ_NONE;
 
-   for_each_set_bit(gpio, irqs, cc-gpio.ngpio)
-   generic_handle_irq(bcma_gpio_to_irq(cc-gpio, gpio));
+   for_each_set_bit(gpio, irqs, gc-ngpio)
+   generic_handle_irq(irq_find_mapping(gc-irqdomain, gpio));
bcma_chipco_gpio_polarity(cc, irqs, val  irqs);
 
return IRQ_HANDLED;
 }
 
-static int bcma_gpio_irq_domain_init(struct bcma_drv_cc *cc)
+static int bcma_gpio_irq_init(struct bcma_drv_cc *cc)
 {
struct gpio_chip *chip = cc-gpio;
-   int gpio, hwirq, err;
+   int hwirq, err;
 
if (cc-core-bus-hosttype != BCMA_HOSTTYPE_SOC)
return 0;
 
-   cc-irq_domain = irq_domain_add_linear(NULL, chip-ngpio,
-  irq_domain_simple_ops, cc);
-   if (!cc-irq_domain) {
-   err = -ENODEV;
-   goto err_irq_domain;
-   }
-   for (gpio = 0; gpio  chip-ngpio; gpio++) {
-   int irq = irq_create_mapping(cc-irq_domain, gpio);
-
-   irq_set_chip_data(irq, cc);
-   irq_set_chip_and_handler(irq, bcma_gpio_irq_chip,
-handle_simple_irq);
-   }
-
hwirq = bcma_core_irq(cc-core, 0);
err = request_irq(hwirq, bcma_gpio_irq_handler, IRQF_SHARED, gpio,
  cc);
if (err)
-   goto err_req_irq;
+   return

[PATCH] bcma: fix access to host_pdev for PCIe devices

2015-08-02 Thread Hauke Mehrtens
bus-host_pdev is part of a union so bus-host_pdev != NULL is probably
also true for PCIe devices, because there it accesses bus-host_pci. If
we access the dev member at the offset defined in struct
platform_device in struct pci_dev instead we probably get something
else.

This patch adds a new function which returns the host dev struct and
NULL if we do not have a host dev. When this gets registered on MIPS
brcm47xx we do not have a host dev in some situations.
This function could also be used in other places.

This problem was introduced in this commit:
commit cae761b5a6bdc597ba476a040fdcd5b4bc559b85
Author: Rafał Miłecki zaj...@gmail.com
Date:   Sun Jun 28 17:17:13 2015 +0200

bcma: populate bus DT subnodes as platform_device-s

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/bcma/bcma_private.h |  1 +
 drivers/bcma/main.c | 30 +++---
 2 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index 15f2b2e..38f1567 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
@@ -34,6 +34,7 @@ int __init bcma_bus_early_register(struct bcma_bus *bus);
 int bcma_bus_suspend(struct bcma_bus *bus);
 int bcma_bus_resume(struct bcma_bus *bus);
 #endif
+struct device *bcma_bus_get_host_dev(struct bcma_bus *bus);
 
 /* scan.c */
 void bcma_detect_chip(struct bcma_bus *bus);
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 8d973c4..24882c1 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -7,7 +7,9 @@
 
 #include bcma_private.h
 #include linux/module.h
+#include linux/mmc/sdio_func.h
 #include linux/platform_device.h
+#include linux/pci.h
 #include linux/bcma/bcma.h
 #include linux/slab.h
 #include linux/of_address.h
@@ -269,6 +271,28 @@ void bcma_prepare_core(struct bcma_bus *bus, struct 
bcma_device *core)
}
 }
 
+struct device *bcma_bus_get_host_dev(struct bcma_bus *bus)
+{
+   switch (bus-hosttype) {
+   case BCMA_HOSTTYPE_PCI:
+   if (bus-host_pci)
+   return bus-host_pci-dev;
+   else
+   return NULL;
+   case BCMA_HOSTTYPE_SOC:
+   if (bus-host_pdev)
+   return bus-host_pdev-dev;
+   else
+   return NULL;
+   case BCMA_HOSTTYPE_SDIO:
+   if (bus-host_sdio)
+   return bus-host_sdio-dev;
+   else
+   return NULL;
+   }
+   return NULL;
+}
+
 void bcma_init_bus(struct bcma_bus *bus)
 {
mutex_lock(bcma_buses_mutex);
@@ -388,6 +412,7 @@ int bcma_bus_register(struct bcma_bus *bus)
 {
int err;
struct bcma_device *core;
+   struct device *dev;
 
/* Scan for devices (cores) */
err = bcma_bus_scan(bus);
@@ -410,13 +435,12 @@ int bcma_bus_register(struct bcma_bus *bus)
bcma_core_pci_early_init(bus-drv_pci[0]);
}
 
+   dev = bcma_bus_get_host_dev(bus);
/* TODO: remove check for IS_BUILTIN(CONFIG_BCMA) check when
 * of_default_bus_match_table is exported or in some other way
 * accessible. This is just a temporary workaround.
 */
-   if (IS_BUILTIN(CONFIG_BCMA)  bus-host_pdev) {
-   struct device *dev = bus-host_pdev-dev;
-
+   if (IS_BUILTIN(CONFIG_BCMA)  dev) {
of_platform_populate(dev-of_node, of_default_bus_match_table,
 NULL, dev);
}
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] b43: fix extpa_gain check for 2GHz

2015-07-30 Thread Hauke Mehrtens
On 07/30/2015 08:54 AM, Rafał Miłecki wrote:
 On 30 July 2015 at 07:40, Kalle Valo kv...@codeaurora.org wrote:
 Hauke Mehrtens ha...@hauke-m.de writes:

 On the 2GHz and and on the 5GHZ band only the extpa_gain setting from
 the 5GHz band was checked. this patch makes it check the property from
 the correct band.

 Signed-off-by: Hauke Mehrtens ha...@hauke-m.de

 Is this a regression? If yes, please add a Fixes line.

 Should this go to 4.2?
 
 Not a regression. It's like this for a lng time.
 
 AFAIK PCI(e) cards don't have external power amplifier, so this code
 is most likely used for some fancy SoCs only. There are 3 known SoCs
 with N-PHY rev 5 or 6: BCM4717A1, BCM4718A1  BCM4716B0.
 
 So we may consider taking it for 4.2 without any Fixes:  line but I
 wouldn't care too much about Cc-ing stable.
 
 Hauke: do you agree?
 
Yes, I do not have a device I know of which is affected by this error, I
just saw this while looking at code close by. Just put this into the
next Linux version and not to stable.

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] b43: fix extpa_gain check for 2GHz

2015-07-29 Thread Hauke Mehrtens
On the 2GHz and and on the 5GHZ band only the extpa_gain setting from
the 5GHz band was checked. this patch makes it check the property from
the correct band.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/net/wireless/b43/tables_nphy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/b43/tables_nphy.c 
b/drivers/net/wireless/b43/tables_nphy.c
index 25d1cbd..b2f0d24 100644
--- a/drivers/net/wireless/b43/tables_nphy.c
+++ b/drivers/net/wireless/b43/tables_nphy.c
@@ -3728,7 +3728,7 @@ const u32 *b43_nphy_get_tx_gain_table(struct b43_wldev 
*dev)
switch (phy-rev) {
case 6:
case 5:
-   if (sprom-fem.ghz5.extpa_gain == 3)
+   if (sprom-fem.ghz2.extpa_gain == 3)
return b43_ntab_tx_gain_epa_rev3_hi_pwr_2g;
/* fall through */
case 4:
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP

2015-07-26 Thread Hauke Mehrtens
On 07/25/2015 10:07 PM, Hauke Mehrtens wrote:
 Hi,
 
 I found some compile problems in the code, but I haven't runtime tested
 it, but will do that.
 
 Hauke
 
Currently there is a NACK from me, but generally I like that this patch
removes some code.

I tested with patch on top of kernel 4.1.3 with OpenWrt trunk on a
Netgear r6250 and it results in this error message:


[7.488170] [ cut here ]
[7.492824] WARNING: CPU: 0 PID: 390 at drivers/gpio/gpiolib.c:86
gpio_to_desc+0xa4/0xbc()
[7.501058] invalid GPIO -517
[7.504011] Modules linked in: gpio_button_hotplug(+) usbcore
nls_base usb_common
[7.511518] CPU: 0 PID: 390 Comm: kmodloader Not tainted 4.1.3 #1
[7.517575] Hardware name: BCM5301X
[7.521050] Backtrace:
[7.523523] [c001612c] (dump_backtrace) from [c0016338]
(show_stack+0x18/0x1c)
[7.531072]  r6:c0362368 r5:0009 r4: r3:dc8ba303
[7.536748] [c0016320] (show_stack) from [c016a998]
(dump_stack+0x7c/0x98)
[7.543968] [c016a91c] (dump_stack) from [c00206e8]
(warn_slowpath_common+0x90/0xbc)
[7.552025]  r4:c717bbe0 r3:dc8ba303
[7.555612] [c0020658] (warn_slowpath_common) from [c002074c]
(warn_slowpath_fmt+0x38/0x40)
[7.564275]  r8:c71b3a10 r7:c78f7210 r6:fdfb r5:fdfb r4:c03da260
[7.570999] [c0020718] (warn_slowpath_fmt) from [c0199630]
(gpio_to_desc+0xa4/0xbc)
[7.578964]  r3:fdfb r2:c0362477
[7.582549] [c019958c] (gpio_to_desc) from [c019a4d4]
(gpio_request+0x18/0x3c)
[7.590091]  r5:fdfb r4:c053c7d0
[7.593676] [c019a4bc] (gpio_request) from [c0197ea4]
(devm_gpio_request+0x3c/0x74)
[7.601643]  r5:c053c7d0 r4:c79d3f50
[7.605228] [c0197e68] (devm_gpio_request) from [bf02d3e8]
(gpio_keys_remove+0x3e8/0x668 [gpio_button_hotplug])
[7.615615]  r7:c71b3a10 r6:002c r5:c78f7210 r4:c717e950
[7.621295] [bf02d04c] (gpio_keys_remove [gpio_button_hotplug])
from [bf02d834] (gpio_keys_probe+0x20/0x1b4 [gpio_button_hotplug])
[7.633326]  r10:c717bf40 r9:c03d0408 r8: r7:c78f7200
r6:bf02dfc0 r5:bf02dfc0
[7.641163]  r4:c78f7210
[7.643701] [bf02d814] (gpio_keys_probe [gpio_button_hotplug]) from
[c01cc698] (platform_drv_probe+0x34/0x64)
[7.653915]  r10:c717bf40 r9:c03d0408 r8: r7:0001
r6:bf02dfc0 r5:bf02dfc0
[7.661751]  r4:c78f7210
[7.664285] [c01cc664] (platform_drv_probe) from [c01cb0e0]
(driver_probe_device+0xf4/0x258)
[7.673034]  r5: r4:c78f7210
[7.676612] [c01cafec] (driver_probe_device) from [c01cb300]
(__driver_attach+0x70/0x94)
[7.685010]  r7: r6:bf02dfc0 r5:c78f7244 r4:c78f7210
[7.690696] [c01cb290] (__driver_attach) from [c01c9774]
(bus_for_each_dev+0x7c/0x90)
[7.698835]  r6:c01cb290 r5:bf02dfc0 r4: r3:c01cb290
[7.704511] [c01c96f8] (bus_for_each_dev) from [c01cabf0]
(driver_attach+0x20/0x28)
[7.712485]  r6:c03db6d4 r5:c792e600 r4:bf02dfc0
[7.717110] [c01cabd0] (driver_attach) from [c01ca890]
(bus_add_driver+0xe4/0x1d4)
[7.725006] [c01ca7ac] (bus_add_driver) from [c01cb784]
(driver_register+0xa4/0xe8)
[7.732984]  r7:c03d3468 r6:bf03 r5:c03d3468 r4:bf02dfc0
[7.738656] [c01cb6e0] (driver_register) from [c01cc650]
(__platform_driver_register+0x50/0x64)
[7.747668]  r5:c03d3468 r4:c78d7640
[7.751257] [c01cc600] (__platform_driver_register) from
[bf030018] (init_module+0x18/0x50 [gpio_button_hotplug])
[7.761837] [bf03] (init_module [gpio_button_hotplug]) from
[c001318c] (do_one_initcall+0x1a4/0x1e0)
[7.771627]  r4:c78d7640 r3:
[7.775216] [c0012fe8] (do_one_initcall) from [c006f9b0]
(do_init_module+0x60/0x1a8)
[7.783273]  r9:c006e734 r8:bf02e36c r7:0015 r6:c78d75c0
r5:c71b3d7c r4:bf02e36c
[7.791034] [c006f950] (do_init_module) from [c0070fac]
(load_module+0x13cc/0x1854)
[7.798998]  r6: r5:c71b3d7c r4:c71b3c00
[7.803631] [c006fbe0] (load_module) from [c007152c]
(SyS_init_module+0xf8/0x124)
[7.811430]  r10: r9:000122f7 r8:c717a000 r7:00acf500
r6:c8a734f0 r5:
[7.819258]  r4:24f0
[7.821802] [c0071434] (SyS_init_module) from [c0009680]
(ret_fast_syscall+0x0/0x3c)
[7.829860]  r9:c717a000 r8:c0009824 r7:0080 r6:
r5: r4:
[7.837604] ---[ end trace 2277938710cf7c41 ]---
[7.842209] gpiod_request: invalid GPIO
[7.846038] gpio-keys gpio-keys: unable to claim gpio 4294966779, err=-22
[7.852820] gpio-keys: probe of gpio-keys failed with error -22


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP

2015-07-26 Thread Hauke Mehrtens
On 07/26/2015 02:32 PM, Hauke Mehrtens wrote:
 On 07/25/2015 10:07 PM, Hauke Mehrtens wrote:
 Hi,

 I found some compile problems in the code, but I haven't runtime tested
 it, but will do that.

 Hauke

 Currently there is a NACK from me, but generally I like that this patch
 removes some code.
 
 I tested with patch on top of kernel 4.1.3 with OpenWrt trunk on a
 Netgear r6250 and it results in this error message:
 
 
 [7.488170] [ cut here ]
 [7.492824] WARNING: CPU: 0 PID: 390 at drivers/gpio/gpiolib.c:86
 gpio_to_desc+0xa4/0xbc()
 [7.501058] invalid GPIO -517
 [7.504011] Modules linked in: gpio_button_hotplug(+) usbcore
 nls_base usb_common
 [7.511518] CPU: 0 PID: 390 Comm: kmodloader Not tainted 4.1.3 #1
 [7.517575] Hardware name: BCM5301X
 [7.521050] Backtrace:
 [7.523523] [c001612c] (dump_backtrace) from [c0016338]
 (show_stack+0x18/0x1c)
 [7.531072]  r6:c0362368 r5:0009 r4: r3:dc8ba303
 [7.536748] [c0016320] (show_stack) from [c016a998]
 (dump_stack+0x7c/0x98)
 [7.543968] [c016a91c] (dump_stack) from [c00206e8]
 (warn_slowpath_common+0x90/0xbc)
 [7.552025]  r4:c717bbe0 r3:dc8ba303
 [7.555612] [c0020658] (warn_slowpath_common) from [c002074c]
 (warn_slowpath_fmt+0x38/0x40)
 [7.564275]  r8:c71b3a10 r7:c78f7210 r6:fdfb r5:fdfb r4:c03da260
 [7.570999] [c0020718] (warn_slowpath_fmt) from [c0199630]
 (gpio_to_desc+0xa4/0xbc)
 [7.578964]  r3:fdfb r2:c0362477
 [7.582549] [c019958c] (gpio_to_desc) from [c019a4d4]
 (gpio_request+0x18/0x3c)
 [7.590091]  r5:fdfb r4:c053c7d0
 [7.593676] [c019a4bc] (gpio_request) from [c0197ea4]
 (devm_gpio_request+0x3c/0x74)
 [7.601643]  r5:c053c7d0 r4:c79d3f50
 [7.605228] [c0197e68] (devm_gpio_request) from [bf02d3e8]
 (gpio_keys_remove+0x3e8/0x668 [gpio_button_hotplug])
 [7.615615]  r7:c71b3a10 r6:002c r5:c78f7210 r4:c717e950
 [7.621295] [bf02d04c] (gpio_keys_remove [gpio_button_hotplug])
 from [bf02d834] (gpio_keys_probe+0x20/0x1b4 [gpio_button_hotplug])
 [7.633326]  r10:c717bf40 r9:c03d0408 r8: r7:c78f7200
 r6:bf02dfc0 r5:bf02dfc0
 [7.641163]  r4:c78f7210
 [7.643701] [bf02d814] (gpio_keys_probe [gpio_button_hotplug]) from
 [c01cc698] (platform_drv_probe+0x34/0x64)
 [7.653915]  r10:c717bf40 r9:c03d0408 r8: r7:0001
 r6:bf02dfc0 r5:bf02dfc0
 [7.661751]  r4:c78f7210
 [7.664285] [c01cc664] (platform_drv_probe) from [c01cb0e0]
 (driver_probe_device+0xf4/0x258)
 [7.673034]  r5: r4:c78f7210
 [7.676612] [c01cafec] (driver_probe_device) from [c01cb300]
 (__driver_attach+0x70/0x94)
 [7.685010]  r7: r6:bf02dfc0 r5:c78f7244 r4:c78f7210
 [7.690696] [c01cb290] (__driver_attach) from [c01c9774]
 (bus_for_each_dev+0x7c/0x90)
 [7.698835]  r6:c01cb290 r5:bf02dfc0 r4: r3:c01cb290
 [7.704511] [c01c96f8] (bus_for_each_dev) from [c01cabf0]
 (driver_attach+0x20/0x28)
 [7.712485]  r6:c03db6d4 r5:c792e600 r4:bf02dfc0
 [7.717110] [c01cabd0] (driver_attach) from [c01ca890]
 (bus_add_driver+0xe4/0x1d4)
 [7.725006] [c01ca7ac] (bus_add_driver) from [c01cb784]
 (driver_register+0xa4/0xe8)
 [7.732984]  r7:c03d3468 r6:bf03 r5:c03d3468 r4:bf02dfc0
 [7.738656] [c01cb6e0] (driver_register) from [c01cc650]
 (__platform_driver_register+0x50/0x64)
 [7.747668]  r5:c03d3468 r4:c78d7640
 [7.751257] [c01cc600] (__platform_driver_register) from
 [bf030018] (init_module+0x18/0x50 [gpio_button_hotplug])
 [7.761837] [bf03] (init_module [gpio_button_hotplug]) from
 [c001318c] (do_one_initcall+0x1a4/0x1e0)
 [7.771627]  r4:c78d7640 r3:
 [7.775216] [c0012fe8] (do_one_initcall) from [c006f9b0]
 (do_init_module+0x60/0x1a8)
 [7.783273]  r9:c006e734 r8:bf02e36c r7:0015 r6:c78d75c0
 r5:c71b3d7c r4:bf02e36c
 [7.791034] [c006f950] (do_init_module) from [c0070fac]
 (load_module+0x13cc/0x1854)
 [7.798998]  r6: r5:c71b3d7c r4:c71b3c00
 [7.803631] [c006fbe0] (load_module) from [c007152c]
 (SyS_init_module+0xf8/0x124)
 [7.811430]  r10: r9:000122f7 r8:c717a000 r7:00acf500
 r6:c8a734f0 r5:
 [7.819258]  r4:24f0
 [7.821802] [c0071434] (SyS_init_module) from [c0009680]
 (ret_fast_syscall+0x0/0x3c)
 [7.829860]  r9:c717a000 r8:c0009824 r7:0080 r6:
 r5: r4:
 [7.837604] ---[ end trace 2277938710cf7c41 ]---
 [7.842209] gpiod_request: invalid GPIO
 [7.846038] gpio-keys gpio-keys: unable to claim gpio 4294966779, err=-22
 [7.852820] gpio-keys: probe of gpio-keys failed with error -22

I made my gpio-key driver compatible with EPROBE_DEFER, but then I saw this:
[3.943859] missing gpiochip .dev parent pointer

and I added this to my gpio driver:
chip-dev   = cc-core-dev;
chip-owner = THIS_MODULE;

And then I am getting this:

[3.936204] pci 0001:00:00.0:   bridge window [mem 0x4000-0x400f

[PATCH] bcma: fix build error when build as module

2015-07-25 Thread Hauke Mehrtens
Currently of_default_bus_match_table is not exported so we can only use
this feature when bcma is build into the kernel. This patch removes
support for child buses when bcma is build as a module as a temporary
fix for a build problem introduces in this commit:

commit cae761b5a6bdc597ba476a040fdcd5b4bc559b85
Author: Rafał Miłecki zaj...@gmail.com
Date:   Sun Jun 28 17:17:13 2015 +0200

bcma: populate bus DT subnodes as platform_device-s

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/bcma/main.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 5912847..8d973c4 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -410,7 +410,11 @@ int bcma_bus_register(struct bcma_bus *bus)
bcma_core_pci_early_init(bus-drv_pci[0]);
}
 
-   if (bus-host_pdev) {
+   /* TODO: remove check for IS_BUILTIN(CONFIG_BCMA) check when
+* of_default_bus_match_table is exported or in some other way
+* accessible. This is just a temporary workaround.
+*/
+   if (IS_BUILTIN(CONFIG_BCMA)  bus-host_pdev) {
struct device *dev = bus-host_pdev-dev;
 
of_platform_populate(dev-of_node, of_default_bus_match_table,
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] bcma: switch GPIO portions to use GPIOLIB_IRQCHIP

2015-07-25 Thread Hauke Mehrtens
Hi,

I found some compile problems in the code, but I haven't runtime tested
it, but will do that.

Hauke

On 07/21/2015 11:04 PM, Linus Walleij wrote:
 This switches the BCMA GPIO driver to use GPIOLIB_IRQCHIP to
 handle its interrupts instead of rolling its own copy of the
 irqdomain handling etc.
 
 Signed-off-by: Linus Walleij linus.wall...@linaro.org
 ---
 Hi BCMA people,
 
 if we can figure this out it would be great if you can test this
 and merge it through whatever GIT tree handles BCMA patches.
 Alternatively I can merge it into the GPIO tree with your ACK.
 
 This is not even compiled, I don't have the right cross compilers
 but the conversion is done like all other GPIOLIB_IRQCHIP conversions
 I've done, so it shouldn't be very far off. Maybe you can get it
 in shape in accordance with my idea if I screwed up? Thanks.
 ---
  drivers/bcma/Kconfig|  2 +-
  drivers/bcma/driver_gpio.c  | 88 
 +
  include/linux/bcma/bcma_driver_chipcommon.h |  1 -
  3 files changed, 28 insertions(+), 63 deletions(-)
 
 diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
 index be5fffb6da24..023d448ed3fa 100644
 --- a/drivers/bcma/Kconfig
 +++ b/drivers/bcma/Kconfig
 @@ -92,7 +92,7 @@ config BCMA_DRIVER_GMAC_CMN
  config BCMA_DRIVER_GPIO
   bool BCMA GPIO driver
   depends on BCMA  GPIOLIB
 - select IRQ_DOMAIN if BCMA_HOST_SOC
 + select GPIOLIB_IRQCHIP if BCMA_HOST_SOC
   help
 Driver to provide access to the GPIO pins of the bcma bus.
  
 diff --git a/drivers/bcma/driver_gpio.c b/drivers/bcma/driver_gpio.c
 index 5f6018e7cd4c..f436fb5b429c 100644
 --- a/drivers/bcma/driver_gpio.c
 +++ b/drivers/bcma/driver_gpio.c

 @@ -125,14 +117,14 @@ static irqreturn_t bcma_gpio_irq_handler(int irq, void 
 *dev_id)
   if (!irqs)
   return IRQ_NONE;
  
 - for_each_set_bit(gpio, irqs, cc-gpio.ngpio)
 - generic_handle_irq(bcma_gpio_to_irq(cc-gpio, gpio));
 + for_each_set_bit(gpio, irqs, gc-ngpio)
 + generic_handle_irq(irq_find_mapping(gc-irq_domain, gpio));

use gc-irqdomain instead

   bcma_chipco_gpio_polarity(cc, irqs, val  irqs);
  
   return IRQ_HANDLED;
  }
  
 -static int bcma_gpio_irq_domain_init(struct bcma_drv_cc *cc)
 +static int bcma_gpio_irq_init(struct bcma_drv_cc *cc)
  {
   struct gpio_chip *chip = cc-gpio;
   int gpio, hwirq, err;

gpio is unused now


 -err_req_irq:
 - for (gpio = 0; gpio  chip-ngpio; gpio++) {
 - int irq = irq_find_mapping(cc-irq_domain, gpio);
 -
 - irq_dispose_mapping(irq);
 + err =  gpiochip_irqchip_add(chip,
 + bcma_gpio_irq_chip,
 + 0,
 + handle_simple_irq,
 + IRQ_TYPE_NONE);
 + if (err) {
 + free_irq(hwirq);

use free_irq(hwirq, cc); instead



--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] bcma: populate bus DT subnodes as platform_device-s

2015-07-25 Thread Hauke Mehrtens
On 07/24/2015 06:11 PM, Joachim Eastwood wrote:
 On 23 July 2015 at 08:06, Kalle Valo kv...@codeaurora.org wrote:
 Rafał Miłecki zaj...@gmail.com writes:

 +   if (bus-host_pdev) {
 +   struct device *dev = bus-host_pdev-dev;
 +
 +   of_platform_populate(dev-of_node, 
 of_default_bus_match_table,
 +NULL, dev);
 +   }
 +

 This caused a compile error when using bcma as module:
 ERROR: of_default_bus_match_table [drivers/bcma/bcma.ko] undefined!
 
 I encountered the same problem with my modular memory controller driver.
 
 There are two options I guess:
 1) Export of_default_bus_match_table
 
 See link below for Rob Herring's take on that.
 http://marc.info/?l=linaro-kernelm=143766694414121w=2
 
 
 regards,
 Joachim Eastwood
 
Hi Joachim,

are you working on a patch which exports of_default_bus_match_table
or provides a wrapper function? If not then I will look into this. My
current plan for bcma is just to deactivate this when it is build as a
module as a temporary workaround

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] bcma: populate bus DT subnodes as platform_device-s

2015-06-30 Thread Hauke Mehrtens
On 06/28/2015 05:17 PM, Rafał Miłecki wrote:
 Our bus should allow defining children nodes as we may want to specify
 devices attached to the bus. This is required e.g. to specify NAND or
 ChipCommon cores and use bus's address and IRQ mappings.
 
 Signed-off-by: Rafał Miłecki zaj...@gmail.com
 ---
  drivers/bcma/main.c | 8 
  1 file changed, 8 insertions(+)

Rafał have you solved the IRQ problem? Is it possible to assign all the
sub devices the same IRQ number as the chipcommon core?

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Fwd: Fwd: lspci not working

2015-05-17 Thread Hauke Mehrtens
On 05/17/2015 06:49 PM, Arend van Spriel wrote:
 
 
 On 17-05-15 16:48, Schmirr Wurst wrote:
 -- Forwarded message --
 From: Schmirr Wurst schmirrwu...@gmail.com
 Date: 2015-05-17 16:47 GMT+02:00
 Subject: Re: Fwd: lspci not working
 To: Arend van Spriel aspr...@gmail.com


 2015-05-17 16:34 GMT+02:00 Arend van Spriel aspr...@gmail.com:
 On 17-05-15 16:08, Schmirr Wurst wrote:

 -- Forwarded message --
 From: Schmirr Wurst schmirrwu...@gmail.com
 Date: 2015-05-17 16:07 GMT+02:00
 Subject: Re: lspci not working
 To: Hauke Mehrtens ha...@hauke-m.de


 2015-05-17 15:17 GMT+02:00 Hauke Mehrtens ha...@hauke-m.de:

 On 05/17/2015 03:00 PM, Schmirr Wurst wrote:

 2015-05-17 14:57 GMT+02:00 Schmirr Wurst schmirrwu...@gmail.com:

 I'm not familiar with inline answers and mailing list, tried to put
 some order in my answer + log file

 2015-05-17 13:18 GMT+02:00 Rafał Miłecki zaj...@gmail.com:

 On 17 May 2015 at 12:23, Arend van Spriel ar...@broadcom.com
 wrote:

 On 05/17/15 02:21, Schmirr Wurst wrote:

 I tried as suggested to had a look at
 /sys/bus/sdio/devices, but the only devices around there a 3
 mmc1:0001:1 to :3, I guess it is something else...

 I already try to install brcmfmac_sdio , with some tutorial
 from the
 internet, but it didn't work...
 actually, I see under /sys/bus/sdio/drivers brcmfmac_sdio ...

 In that directory, I see a directory mmc1:0001:2
 under device I have 0xa94d

 I completly lost, maybe you understand that information, sorry..



 I do. The fact that you see a subdirectory mmc1:0001:2 in
 /sys/bus/sdio/drivers/brcmfmac_sdio means that the driver was
 probed
 for
 this device. Now would be a good time to share your (friends')
 kernel
 log,
 but my guess is you are either missing firmware or nvram data
 or both
 for
 this device.

 I ve attatched the kernel.log here
 https://drive.google.com/file/d/0B8gm4mLCCQAgMmNlVVFSYmNjOGs/view?usp=sharing

 In dmsg I see following linked with the brc driver :
 dmesg | grep brc
 [7.987661] brcmf_sdio_drivestrengthinit: No SDIO Drive strength
 init done for chip 43340 rev 2 pmurev 20
 [7.993487] usbcore: registered new interface driver brcmfmac
 [7.996318] brcmfmac_sdio mmc1:0001:1: Direct firmware load for
 brcm/brcmfmac43340-sdio.bin failed with error -2
 [9.011572] brcmf_sdio_htclk: HT Avail timeout (100): clkctl
 0x50
 [   10.037365] brcmf_sdio_htclk: HT Avail timeout (100): clkctl
 0x50


 It could also mean driver was loaded manually. So please also make
 sure the friend uses kernel 4.0 or newer.

 Kernel : 4.0.0 #3 SMP PREEMPT Wed Apr 22 17:52:53 MSK 2015
 Distro:
 Distributor ID:T100 Ubuntu 15.04
 Description:Ubuntu 15.04
 Release:15.04
 Codename:vivid
 I ve installed it from the magic stick here
 https://plus.google.com/communities/117853703024346186936


 The driver complains about missing firmware and Ubuntu 15.04 does not
 contain it.

 Please place this file

 https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/plain/brcm/brcmfmac43340-sdio.bin


 to /lib/firmware/brcm/brcmfmac43340-sdio.bin

 Hauke

Before that, the system was complaining about
 brcm/brcmfmac43340-sdio.bin, and now about brcm/brcmfmac43340-sdio.txt
 but errors are similar...


 I guess your system in jinxed because of the hostname you setup :-p

 Ok, more seriously now. This is the nvram data I mentioned earlier. This
 system may have that info stored in efi variable. You should be able
 to find
 it in /sys/firmware/efi/efivars/nvram-*.

 It may be necessary to run the following commands:

 # modprobe efivarfs
 # mount -t efivarfs efivarfs /sys/firmware/efi/efivars

 Regards,
 Arend

 I cant be kind with manufacturer like broadcom and nvidia and those
 that are builting in such hardware ;)
 
 You are talking to a broadcom employee (in disguise ;-) ).
 
 cat /sys/firmware/efi/efivars/nvram-74b00bd9-805a-4d61-b51f-43268123d113
 What am I supposed to do with this ?
 
 You are kidding? I'll chew it for you:
 
 $ cp /sys/firmware/efi/efivars/nvram-74b00bd9*
 /lib/firmware/brcm/brcmfmac43340-sdio.txt

Why can't the driver directly access this efi var? I haven't checked if
this is already done somewhere, but letting a user do this manually does
not seam nice.

 
 Regards,
 Arend
 

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/4] bcma: support bringing up bus hosted on PCIe Gen 2

2015-02-08 Thread Hauke Mehrtens
On 02/06/2015 07:56 AM, Kalle Valo wrote:
 Rafał Miłecki zaj...@gmail.com writes:
 
 +void bcma_core_pcie2_up(struct bcma_drv_pcie2 *pcie2)
 +{
 + struct bcma_bus *bus = pcie2-core-bus;
 + struct pci_dev *dev = bus-host_pci;
 +
 + pcie_capability_clear_and_set_word(dev, PCI_EXP_DEVCTL,
 +PCI_EXP_DEVCTL_READRQ,
 +pcie2-reqsize);

 Use pcie_set_readrq() if it is needed.

 What do you mean by if needed? Is there anything wrong?
 
 So what's the conclusion? Can I apply these?
 
Ah sorry,

The if needed referenced the comment above about if setting this is
needed at all, or if this should be done by the driver for the (broken?)
PCIe controller.

pcie_set_readrq() does the setting of this register in the Linux kernel
and does some additional checks, I would suggest using this function
instead of setting this register by yourself.

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/4] bcma: support bringing up bus hosted on PCIe Gen 2

2015-01-30 Thread Hauke Mehrtens


On 01/30/2015 06:22 PM, Rafał Miłecki wrote:
 Signed-off-by: Rafał Miłecki zaj...@gmail.com
 ---
  drivers/bcma/bcma_private.h|  3 +++
  drivers/bcma/driver_pcie2.c| 24 ++--
  drivers/bcma/host_pci.c|  2 +-
  include/linux/bcma/bcma_driver_pcie2.h |  2 ++
  4 files changed, 28 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
 index 351f4af..3692912 100644
 --- a/drivers/bcma/bcma_private.h
 +++ b/drivers/bcma/bcma_private.h
 @@ -104,6 +104,9 @@ u32 bcma_pcie_read(struct bcma_drv_pci *pc, u32 address);
  void bcma_core_pci_up(struct bcma_drv_pci *pc);
  void bcma_core_pci_down(struct bcma_drv_pci *pc);
  
 +/* driver_pcie2.c */
 +void bcma_core_pcie2_up(struct bcma_drv_pcie2 *pcie2);
 +
  extern int bcma_chipco_watchdog_register(struct bcma_drv_cc *cc);
  
  #ifdef CONFIG_BCMA_DRIVER_PCI_HOSTMODE
 diff --git a/drivers/bcma/driver_pcie2.c b/drivers/bcma/driver_pcie2.c
 index e4be537..c8913bc 100644
 --- a/drivers/bcma/driver_pcie2.c
 +++ b/drivers/bcma/driver_pcie2.c
 @@ -156,14 +156,20 @@ static void pciedev_reg_pm_clk_period(struct 
 bcma_drv_pcie2 *pcie2)
  
  void bcma_core_pcie2_init(struct bcma_drv_pcie2 *pcie2)
  {
 - struct bcma_chipinfo *ci = pcie2-core-bus-chipinfo;
 + struct bcma_bus *bus = pcie2-core-bus;
 + struct bcma_chipinfo *ci = bus-chipinfo;
   u32 tmp;
  
   tmp = pcie2_read32(pcie2, BCMA_CORE_PCIE2_SPROM(54));
   if ((tmp  0xe)  1 == 2)
   bcma_core_pcie2_cfg_write(pcie2, 0x4e0, 0x17);
  
 - /* TODO: Do we need pcie_reqsize? */
 + switch (bus-chipinfo.id) {
 + case BCMA_CHIP_ID_BCM4360:
 + case BCMA_CHIP_ID_BCM4352:
 + pcie2-reqsize = 0x3000; /* TODO: PCI_EXP_DEVCTL_READRQ_1024B */
 + break;
 + }

In the PCIe controller used in the BCM4706 there was a bug, so that it
did not support a request size bigger than 128 bytes. Broadcom fixed
that in the PCIe device driver code by decreasing the value, but we
fixed that in the PCIe controller code, see:

commit f4a83e578e0011ddcfdbe1c62d0916dadb4802aa
Author: Hauke Mehrtens ha...@hauke-m.de
Date:   Fri Aug 23 23:22:29 2013 +0200

bcma: change max PCI read request size to 128

It could be that the PCIe controller used on ARM SoCs has similar
problems but supports bigger sizes now, but not so big ones.

This is just an assumption.

What is the default value for pcie2-reqsize?

  
   if (ci-id == BCMA_CHIP_ID_BCM4360  ci-rev  3)
   bcma_core_pcie2_war_delay_perst_enab(pcie2, true);
 @@ -173,3 +179,17 @@ void bcma_core_pcie2_init(struct bcma_drv_pcie2 *pcie2)
   pciedev_crwlpciegen2_180(pcie2);
   pciedev_crwlpciegen2_182(pcie2);
  }
 +
 +/**
 + * Runtime ops.
 + **/
 +
 +void bcma_core_pcie2_up(struct bcma_drv_pcie2 *pcie2)
 +{
 + struct bcma_bus *bus = pcie2-core-bus;
 + struct pci_dev *dev = bus-host_pci;
 +
 + pcie_capability_clear_and_set_word(dev, PCI_EXP_DEVCTL,
 +PCI_EXP_DEVCTL_READRQ,
 +pcie2-reqsize);

Use pcie_set_readrq() if it is needed.

 +}
 diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c
 index 8dd37dc..5fb87a8 100644
 --- a/drivers/bcma/host_pci.c
 +++ b/drivers/bcma/host_pci.c
 @@ -322,7 +322,7 @@ void bcma_host_pci_up(struct bcma_bus *bus)
   return;
  
   if (bus-host_is_pcie2)
 - pr_warn(Bringing up bus with PCIe Gen 2 host is unsupported 
 yet\n);
 + bcma_core_pcie2_up(bus-drv_pcie2);
   else
   bcma_core_pci_up(bus-drv_pci[0]);
  }
 diff --git a/include/linux/bcma/bcma_driver_pcie2.h 
 b/include/linux/bcma/bcma_driver_pcie2.h
 index 5988b05..d8c4329 100644
 --- a/include/linux/bcma/bcma_driver_pcie2.h
 +++ b/include/linux/bcma/bcma_driver_pcie2.h
 @@ -143,6 +143,8 @@
  
  struct bcma_drv_pcie2 {
   struct bcma_device *core;
 +
 + u16 reqsize;
  };
  
  #define pcie2_read16(pcie2, offset)  bcma_read16((pcie2)-core, 
 offset)
 
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: cfg80211: Unknown symbol get_net_ns_by_fd (err 0)

2015-01-30 Thread Hauke Mehrtens


On 01/30/2015 07:18 PM, Arend van Spriel wrote:
 On 01/26/15 21:44, Arend van Spriel wrote:
 Hi Hauke,

 The commit below causes the error mentioned in the Subject: field. I
 would like to fix this, but could use a bit of help here how to do this
 type of things.

 commit 4b681c82d2f9bef121c912ffcaac89a004af3f2c
 Author: Vadim Kochan vadi...@gmail.com
 Date: Mon Jan 12 16:34:05 2015 +0200

 nl80211: Allow set network namespace by fd
 
 Hi Hauke,
 
 I looked into my issue a bit more. So my target kernel is
 3.11.1-200.fc19.x86_64 and checking lxr found that 3.11 has this
 function, but it does not have EXPORT_SYMBOL(). That was added by the
 same commit above. Any clues how to fix this?

Hi Arend

As Johannes said it is probably not possible to backport
get_net_ns_by_fd() correctly. You can not access any symbols which are
not exported in a kernel. To backport it we have to access
netns_operations which is also not exported.

We could  copy this function it into backports and remove this check
from the original function:
if (ei-ns_ops == netns_operations)
..


Or we just backport this version every time:

struct net *get_net_ns_by_fd(int fd)
{
return ERR_PTR(-EINVAL);
}

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcma: clean bus initialization code

2015-01-22 Thread Hauke Mehrtens
On 01/22/2015 03:01 PM, Kalle Valo wrote:
 Hauke Mehrtens ha...@hauke-m.de writes:
 
 On 01/16/2015 08:59 PM, Rafał Miłecki wrote:
 This moves main bus init code to the main.c and renames old function to
 make its purpose clear.
 Thanks to this change we'll also be able to separate scanning from
 registration (and support PCIe Gen 2 devices) in the future.

 Signed-off-by: Rafał Miłecki zaj...@gmail.com

 Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
 
 No need to change anything now, but I think that in cases like this you
 should use Acked-by:
 
   13) When to use Acked-by: and Cc:
 
   The Signed-off-by: tag indicates that the signer was involved in the
   development of the patch, or that he/she was in the patch's delivery
   path.
 
   If a person was not directly involved in the preparation or handling
   of a patch but wishes to signify and record their approval of it then
   they can arrange to have an Acked-by: line added to the patch's
   changelog.
 
   Acked-by: is often used by the maintainer of the affected code when
   that maintainer neither contributed to nor forwarded the patch.
 
 
Yes you are right I thought about that right after I send clicked on
send. Sorry.

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2] bcma: clean bus initialization code

2015-01-18 Thread Hauke Mehrtens
On 01/16/2015 08:59 PM, Rafał Miłecki wrote:
 This moves main bus init code to the main.c and renames old function to
 make its purpose clear.
 Thanks to this change we'll also be able to separate scanning from
 registration (and support PCIe Gen 2 devices) in the future.
 
 Signed-off-by: Rafał Miłecki zaj...@gmail.com

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de

This should also fix the problem that the bus number in the early init
part was wrongly set to 0. I saw this on a SoC with BCMA as main bus and
some PCIe cards with bcma on it.

 ---
 V2: Fix typo (s/initialiation/initialization/)
 Put bcma_detect_chip earlier in .h to match order in .c
 ---
  drivers/bcma/bcma_private.h |  3 ++-
  drivers/bcma/main.c | 16 
  drivers/bcma/scan.c |  5 +
  3 files changed, 15 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
 index 314ae40..59422b5 100644
 --- a/drivers/bcma/bcma_private.h
 +++ b/drivers/bcma/bcma_private.h
 @@ -25,6 +25,7 @@ struct bcma_bus;
  bool bcma_wait_value(struct bcma_device *core, u16 reg, u32 mask, u32 value,
int timeout);
  void bcma_prepare_core(struct bcma_bus *bus, struct bcma_device *core);
 +void bcma_init_bus(struct bcma_bus *bus);
  int bcma_bus_register(struct bcma_bus *bus);
  void bcma_bus_unregister(struct bcma_bus *bus);
  int __init bcma_bus_early_register(struct bcma_bus *bus,
 @@ -36,11 +37,11 @@ int bcma_bus_resume(struct bcma_bus *bus);
  #endif
  
  /* scan.c */
 +void bcma_detect_chip(struct bcma_bus *bus);
  int bcma_bus_scan(struct bcma_bus *bus);
  int __init bcma_bus_scan_early(struct bcma_bus *bus,
  struct bcma_device_id *match,
  struct bcma_device *core);
 -void bcma_init_bus(struct bcma_bus *bus);
  
  /* sprom.c */
  int bcma_sprom_get(struct bcma_bus *bus);
 diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
 index 534e133..c166d44 100644
 --- a/drivers/bcma/main.c
 +++ b/drivers/bcma/main.c
 @@ -268,6 +268,18 @@ void bcma_prepare_core(struct bcma_bus *bus, struct 
 bcma_device *core)
   }
  }
  
 +void bcma_init_bus(struct bcma_bus *bus)
 +{
 + mutex_lock(bcma_buses_mutex);
 + bus-num = bcma_bus_next_num++;
 + mutex_unlock(bcma_buses_mutex);
 +
 + INIT_LIST_HEAD(bus-cores);
 + bus-nr_cores = 0;
 +
 + bcma_detect_chip(bus);
 +}
 +
  static void bcma_register_core(struct bcma_bus *bus, struct bcma_device 
 *core)
  {
   int err;
 @@ -369,10 +381,6 @@ int bcma_bus_register(struct bcma_bus *bus)
   int err;
   struct bcma_device *core;
  
 - mutex_lock(bcma_buses_mutex);
 - bus-num = bcma_bus_next_num++;
 - mutex_unlock(bcma_buses_mutex);
 -
   /* Scan for devices (cores) */
   err = bcma_bus_scan(bus);
   if (err) {
 diff --git a/drivers/bcma/scan.c b/drivers/bcma/scan.c
 index 9175207..5328ee5 100644
 --- a/drivers/bcma/scan.c
 +++ b/drivers/bcma/scan.c
 @@ -435,15 +435,12 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 
 __iomem **eromptr,
   return 0;
  }
  
 -void bcma_init_bus(struct bcma_bus *bus)
 +void bcma_detect_chip(struct bcma_bus *bus)
  {
   s32 tmp;
   struct bcma_chipinfo *chipinfo = (bus-chipinfo);
   char chip_id[8];
  
 - INIT_LIST_HEAD(bus-cores);
 - bus-nr_cores = 0;
 -
   bcma_scan_switch_core(bus, BCMA_ADDR_BASE);
  
   tmp = bcma_scan_read32(bus, 0, BCMA_CC_ID);
 

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] bcma: use standard bus scanning during early register

2015-01-18 Thread Hauke Mehrtens
On 01/16/2015 10:08 PM, Rafał Miłecki wrote:
 Starting with kernel 3.19-rc1 early registration of bcma on MIPS is done
 a bit later, with memory allocator available. This allows us to simplify
 code by using standard bus scanning method.
 
 Signed-off-by: Rafał Miłecki zaj...@gmail.com

Thanks for changing the bcm47xx mips target and making this possible.
This patches looks good, just some small comments.
 ---
  drivers/bcma/bcma_private.h   |  7 +
  drivers/bcma/host_soc.c   |  2 +-
  drivers/bcma/main.c   | 33 +++
  drivers/bcma/scan.c   | 61 
 +++
  include/linux/bcma/bcma_soc.h |  2 --
  5 files changed, 14 insertions(+), 91 deletions(-)
 
 diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
 index 59422b5..3f314c9 100644
 --- a/drivers/bcma/bcma_private.h
 +++ b/drivers/bcma/bcma_private.h
 @@ -28,9 +28,7 @@ void bcma_prepare_core(struct bcma_bus *bus, struct 
 bcma_device *core);
  void bcma_init_bus(struct bcma_bus *bus);
  int bcma_bus_register(struct bcma_bus *bus);
  void bcma_bus_unregister(struct bcma_bus *bus);
 -int __init bcma_bus_early_register(struct bcma_bus *bus,
 -struct bcma_device *core_cc,
 -struct bcma_device *core_mips);
 +int __init bcma_bus_early_register(struct bcma_bus *bus);
  #ifdef CONFIG_PM
  int bcma_bus_suspend(struct bcma_bus *bus);
  int bcma_bus_resume(struct bcma_bus *bus);
 @@ -39,9 +37,6 @@ int bcma_bus_resume(struct bcma_bus *bus);
  /* scan.c */
  void bcma_detect_chip(struct bcma_bus *bus);
  int bcma_bus_scan(struct bcma_bus *bus);
 -int __init bcma_bus_scan_early(struct bcma_bus *bus,
 -struct bcma_device_id *match,
 -struct bcma_device *core);
  
  /* sprom.c */
  int bcma_sprom_get(struct bcma_bus *bus);
 diff --git a/drivers/bcma/host_soc.c b/drivers/bcma/host_soc.c
 index 335cbcf..2dce347 100644
 --- a/drivers/bcma/host_soc.c
 +++ b/drivers/bcma/host_soc.c
 @@ -193,7 +193,7 @@ int __init bcma_host_soc_init(struct bcma_soc *soc)
   int err;
  
   /* Scan bus and initialize it */
 - err = bcma_bus_early_register(bus, soc-core_cc, soc-core_mips);
 + err = bcma_bus_early_register(bus);
   if (err)
   iounmap(bus-mmio);
  
 diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
 index c166d44..c3c5e0a 100644
 --- a/drivers/bcma/main.c
 +++ b/drivers/bcma/main.c
 @@ -489,35 +489,20 @@ void bcma_bus_unregister(struct bcma_bus *bus)
   kfree(cores[0]);
  }
  
 -int __init bcma_bus_early_register(struct bcma_bus *bus,
 -struct bcma_device *core_cc,
 -struct bcma_device *core_mips)
 +/*
 + * This is a special version of bus registration function designed for SoCs.
 + * It scans bus and performs basic initialization of main cores only.
 + * Please note it requires memory allocation, however it won't try to sleep.
 + */
 +int __init bcma_bus_early_register(struct bcma_bus *bus)
  {
   int err;
   struct bcma_device *core;
 - struct bcma_device_id match;
 -
 - match.manuf = BCMA_MANUF_BCM;
 - match.id = bcma_cc_core_id(bus);
 - match.class = BCMA_CL_SIM;
 - match.rev = BCMA_ANY_REV;
 -
 - /* Scan for chip common core */
 - err = bcma_bus_scan_early(bus, match, core_cc);
 - if (err) {
 - bcma_err(bus, Failed to scan for common core: %d\n, err);
 - return -1;
 - }
 -
 - match.manuf = BCMA_MANUF_MIPS;
 - match.id = BCMA_CORE_MIPS_74K;
 - match.class = BCMA_CL_SIM;
 - match.rev = BCMA_ANY_REV;
  
 - /* Scan for mips core */
 - err = bcma_bus_scan_early(bus, match, core_mips);
 + /* Scan for devices (cores) */
 + err = bcma_bus_scan(bus);
   if (err) {
 - bcma_err(bus, Failed to scan for mips core: %d\n, err);
 + bcma_err(bus, Failed to scan bus: %d\n, err);
   return -1;
   }
  
 diff --git a/drivers/bcma/scan.c b/drivers/bcma/scan.c
 index 5328ee5..1138226 100644
 --- a/drivers/bcma/scan.c
 +++ b/drivers/bcma/scan.c
 @@ -461,6 +461,9 @@ int bcma_bus_scan(struct bcma_bus *bus)
  
   int err, core_num = 0;
  
add comment:
skip if the bus was already scanned
 + if (bus-nr_cores)
 + return 0;
 +
   erombase = bcma_scan_read32(bus, 0, BCMA_CC_EROM);
   if (bus-hosttype == BCMA_HOSTTYPE_SOC) {
   eromptr = ioremap_nocache(erombase, BCMA_CORE_SIZE);
 @@ -519,61 +522,3 @@ out:
  
   return err;
  }
 -
 -int __init bcma_bus_scan_early(struct bcma_bus *bus,
 -struct bcma_device_id *match,
 -struct bcma_device *core)
 -{
 - u32 erombase;
 - u32 __iomem *eromptr, *eromend;
 -
 - int err = -ENODEV;
 - int core_num = 0;
 -
 - erombase = bcma_scan_read32(bus, 0, BCMA_CC_EROM);
 - if (bus-hosttype == 

Re: [PATCH RFC] bcma: simplify freeing cores (internal devices structs)

2015-01-18 Thread Hauke Mehrtens
On 01/16/2015 10:47 PM, Rafał Miłecki wrote:
 Signed-off-by: Rafał Miłecki zaj...@gmail.com
 ---
 This code was introduced by Saul in
 ee91592711ed90a1abfbb1b2ceadded11d685164
 bcma: don't leak memory for PCIE, MIPS, GBIT cores
 
 I don't really see reason for making it in so complicated way.
 I tested my patch for crashes, but didn't really try kmemleak.
 Is my simple solution OK? Or am I missing something? Anyone?

Are you sure no device driver accesses the chipcommon, pcie or mips core
in the unregister part? If some device driver does something in his
remove function with e.g. chipcommon it will cause problems when the
chipcommon core was already freed.

Hauke

 ---
  drivers/bcma/main.c | 11 ++-
  1 file changed, 2 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
 index c3c5e0a..58dd582 100644
 --- a/drivers/bcma/main.c
 +++ b/drivers/bcma/main.c
 @@ -371,6 +371,8 @@ static void bcma_unregister_cores(struct bcma_bus *bus)
   list_del(core-list);
   if (core-dev_registered)
   device_unregister(core-dev);
 + else
 + kfree(core);
   }
   if (bus-hosttype == BCMA_HOSTTYPE_SOC)
   platform_device_unregister(bus-drv_cc.watchdog);
 @@ -467,7 +469,6 @@ int bcma_bus_register(struct bcma_bus *bus)
  
  void bcma_bus_unregister(struct bcma_bus *bus)
  {
 - struct bcma_device *cores[3];
   int err;
  
   err = bcma_gpio_unregister(bus-drv_cc);
 @@ -478,15 +479,7 @@ void bcma_bus_unregister(struct bcma_bus *bus)
  
   bcma_core_chipcommon_b_free(bus-drv_cc_b);
  
 - cores[0] = bcma_find_core(bus, BCMA_CORE_MIPS_74K);
 - cores[1] = bcma_find_core(bus, BCMA_CORE_PCIE);
 - cores[2] = bcma_find_core(bus, BCMA_CORE_4706_MAC_GBIT_COMMON);
 -
   bcma_unregister_cores(bus);
 -
 - kfree(cores[2]);
 - kfree(cores[1]);
 - kfree(cores[0]);
  }
  
  /*
 

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: backports-20141114 ath9k doesn't build for me on Ubuntu LTS 14.04

2014-11-17 Thread Hauke Mehrtens
On 11/18/2014 12:02 AM, ASIC Felix wrote:
 Hi,
 
 backports-20141114 ath9k doesn't build for me on Ubuntu LTS 14.04
 kernel 3.13.0-39
 
 ] make defconfig-ath9k  make -j4
 
 /home/me/Downloads/backports-20141114/drivers/net/wireless/ath/ath9k/common-spectral.c:40:5:
 error: redefinition of \u2018ath_cmn_process_fft\u2019
  int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv, struct
 ieee80211_hdr *hdr,
  ^
 In file included from
 /home/me/Downloads/backports-20141114/drivers/net/wireless/ath/ath9k/common.h:27:0,
  from
 /home/me/Downloads/backports-20141114/drivers/net/wireless/ath/ath9k/ath9k.h:27,
  from
 /home/me/Downloads/backports-20141114/drivers/net/wireless/ath/ath9k/common-spectral.c:18:
 /home/me/Downloads/backports-20141114/drivers/net/wireless/ath/ath9k/common-spectral.h:146:19:
 note: previous definition of \u2018ath_cmn_process_fft\u2019 was here
  static inline int ath_cmn_process_fft(struct ath_spec_scan_priv *spec_priv,
^
 make[8]: *** 
 [/home/me/Downloads/backports-20141114/drivers/net/wireless/ath/ath9k/common-spectral.o]
 Error 1
 
 Felix

There is a bug in upstream ath9k, you need this additional patch:

http://www.spinics.net/lists/linux-wireless/msg129456.html

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 3.18+] b43: fix NULL pointer dereference in b43_phy_copy()

2014-11-08 Thread Hauke Mehrtens
phy_read and phy_write are not set for every phy any more sine this:
commit d342b95dd735014a590f9051b1ba227eb54ca8f6
Author: Rafał Miłecki zaj...@gmail.com
Date:   Thu Jul 31 21:59:43 2014 +0200

b43: don't duplicate common PHY read/write ops

b43_phy_copy() accesses phy_read and phy_write directly and will fail
with some phys. This patch fixes the regression by using the
b43_phy_read() and b43_phy_write() functions which should be used for
read and write access.

This should fix this bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=87731

Reported-by: Volker Kempter v.kemp...@pe.tu-clausthal.de
Tested-by: Volker Kempter v.kemp...@pe.tu-clausthal.de
Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/net/wireless/b43/phy_common.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

This should go into wireless-testing and into 3.18 as it fixes a 
regression in 3.18.

changes since v1:
 - remove assert_mac_suspended(dev), it is already done in b43_phy_write()
   and b43_phy_read()

diff --git a/drivers/net/wireless/b43/phy_common.c 
b/drivers/net/wireless/b43/phy_common.c
index 1dfc682..ee27b06 100644
--- a/drivers/net/wireless/b43/phy_common.c
+++ b/drivers/net/wireless/b43/phy_common.c
@@ -300,9 +300,7 @@ void b43_phy_write(struct b43_wldev *dev, u16 reg, u16 
value)
 
 void b43_phy_copy(struct b43_wldev *dev, u16 destreg, u16 srcreg)
 {
-   assert_mac_suspended(dev);
-   dev-phy.ops-phy_write(dev, destreg,
-   dev-phy.ops-phy_read(dev, srcreg));
+   b43_phy_write(dev, destreg, b43_phy_read(dev, srcreg));
 }
 
 void b43_phy_mask(struct b43_wldev *dev, u16 offset, u16 mask)
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3.18+] b43: fix NULL pointer dereference in b43_phy_copy()

2014-11-05 Thread Hauke Mehrtens
phy_read and phy_write are not set for every phy any more sine this:
commit d342b95dd735014a590f9051b1ba227eb54ca8f6
Author: Rafał Miłecki zaj...@gmail.com
Date:   Thu Jul 31 21:59:43 2014 +0200

b43: don't duplicate common PHY read/write ops

b43_phy_copy() accesses phy_read and phy_write directly and will fail
with some phys. This patch fixes the regression by using the
b43_phy_read() and b43_phy_write() functions which should be used for
read and write access.

This should fix this bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=87731

Reported-by: Volker Kempter v.kemp...@pe.tu-clausthal.de
Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/net/wireless/b43/phy_common.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

This should go into wireless-testing and into 3.18 as it fixes a 
regression in 3.18.

diff --git a/drivers/net/wireless/b43/phy_common.c 
b/drivers/net/wireless/b43/phy_common.c
index 1dfc682..3f37401 100644
--- a/drivers/net/wireless/b43/phy_common.c
+++ b/drivers/net/wireless/b43/phy_common.c
@@ -301,8 +301,7 @@ void b43_phy_write(struct b43_wldev *dev, u16 reg, u16 
value)
 void b43_phy_copy(struct b43_wldev *dev, u16 destreg, u16 srcreg)
 {
assert_mac_suspended(dev);
-   dev-phy.ops-phy_write(dev, destreg,
-   dev-phy.ops-phy_read(dev, srcreg));
+   b43_phy_write(dev, destreg, b43_phy_read(dev, srcreg));
 }
 
 void b43_phy_mask(struct b43_wldev *dev, u16 offset, u16 mask)
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v7 2/2] bcma: get IRQ numbers from dt

2014-11-01 Thread Hauke Mehrtens
It is not possible to auto detect the irq numbers used by the cores on
an arm SoC. If bcma was registered with device tree it will search for
some device tree nodes with the irq number and add it to the core
configuration.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 Documentation/devicetree/bindings/bus/bcma.txt | 21 +++
 drivers/bcma/main.c| 52 +-
 2 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/bus/bcma.txt 
b/Documentation/devicetree/bindings/bus/bcma.txt
index 62a4834..edd44d8 100644
--- a/Documentation/devicetree/bindings/bus/bcma.txt
+++ b/Documentation/devicetree/bindings/bus/bcma.txt
@@ -8,6 +8,11 @@ Required properties:
 
 The cores on the AXI bus are automatically detected by bcma with the
 memory ranges they are using and they get registered afterwards.
+Automatic detection of the IRQ number is not working on
+BCM47xx/BCM53xx ARM SoCs. To assign IRQ numbers to the cores, provide
+them manually through device tree. Use an interrupt-map to specify the
+IRQ used by the devices on the bus. The first address is just an index,
+because we do not have any special register.
 
 The top-level axi bus may contain children representing attached cores
 (devices). This is needed since some hardware details can't be auto
@@ -22,6 +27,22 @@ Example:
ranges = 0x 0x1800 0x0010;
#address-cells = 1;
#size-cells = 1;
+   #interrupt-cells = 1;
+   interrupt-map-mask = 0x000f 0x;
+   interrupt-map =
+   /* Ethernet Controller 0 */
+   0x00024000 0 gic GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH,
+
+   /* Ethernet Controller 1 */
+   0x00025000 0 gic GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH;
+
+   /* PCIe Controller 0 */
+   0x00012000 0 gic GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH,
+   0x00012000 1 gic GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH,
+   0x00012000 2 gic GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH,
+   0x00012000 3 gic GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH,
+   0x00012000 4 gic GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH,
+   0x00012000 5 gic GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH;
 
chipcommon {
reg = 0x 0x1000;
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 03cd421..534e133 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -11,6 +11,7 @@
 #include linux/bcma/bcma.h
 #include linux/slab.h
 #include linux/of_address.h
+#include linux/of_irq.h
 
 MODULE_DESCRIPTION(Broadcom's specific AMBA driver);
 MODULE_LICENSE(GPL);
@@ -153,6 +154,46 @@ static struct device_node 
*bcma_of_find_child_device(struct platform_device *par
return NULL;
 }
 
+static int bcma_of_irq_parse(struct platform_device *parent,
+struct bcma_device *core,
+struct of_phandle_args *out_irq, int num)
+{
+   __be32 laddr[1];
+   int rc;
+
+   if (core-dev.of_node) {
+   rc = of_irq_parse_one(core-dev.of_node, num, out_irq);
+   if (!rc)
+   return rc;
+   }
+
+   out_irq-np = parent-dev.of_node;
+   out_irq-args_count = 1;
+   out_irq-args[0] = num;
+
+   laddr[0] = cpu_to_be32(core-addr);
+   return of_irq_parse_raw(laddr, out_irq);
+}
+
+static unsigned int bcma_of_get_irq(struct platform_device *parent,
+   struct bcma_device *core, int num)
+{
+   struct of_phandle_args out_irq;
+   int ret;
+
+   if (!parent || !parent-dev.of_node)
+   return 0;
+
+   ret = bcma_of_irq_parse(parent, core, out_irq, num);
+   if (ret) {
+   bcma_debug(core-bus, bcma_of_get_irq() failed with rc=%d\n,
+  ret);
+   return 0;
+   }
+
+   return irq_create_of_mapping(out_irq);
+}
+
 static void bcma_of_fill_device(struct platform_device *parent,
struct bcma_device *core)
 {
@@ -161,12 +202,19 @@ static void bcma_of_fill_device(struct platform_device 
*parent,
node = bcma_of_find_child_device(parent, core);
if (node)
core-dev.of_node = node;
+
+   core-irq = bcma_of_get_irq(parent, core, 0);
 }
 #else
 static void bcma_of_fill_device(struct platform_device *parent,
struct bcma_device *core)
 {
 }
+static inline unsigned int bcma_of_get_irq(struct platform_device *parent,
+  struct bcma_device *core, int num)
+{
+   return 0;
+}
 #endif /* CONFIG_OF */
 
 unsigned int bcma_core_irq(struct bcma_device *core, int num)
@@ -182,7 +230,9 @@ unsigned int bcma_core_irq(struct bcma_device *core, int 
num

Re: [PATCH] bcma: Add dependency on OF_ADDRESS

2014-10-09 Thread Hauke Mehrtens
On 10/09/2014 07:29 PM, Guenter Roeck wrote:
 On Thu, Oct 09, 2014 at 07:18:31PM +0200, Arend van Spriel wrote:
 On 10/09/14 19:15, Arend van Spriel wrote:
 On 10/09/14 18:54, Rafał Miłecki wrote:
 On 9 October 2014 18:41, Guenter Roeckli...@roeck-us.net wrote:
 Commit 2101e533f41a (bcma: register bcma as device tree driver)
 introduces a hard dependency on OF_ADDRESS into the bcma driver.
 OF_ADDRESS is specifically disabled for the sparc architecture.
 This results in the following error when building sparc64:allmodconfig.

 Does this mean on sparc (using allmodconfig) you will get CONFIG_OF and
 !CONFIG_OF_ADDRESS? Does that makes sense?

 Is CONFIG_OF is used on sparc to access OpenBoot information?

 I have no idea. All I know is that the driver doesn't build anymore with OF
 enabled and OF_ADDRESS disabled.

Device tree support in bcma is only needed on some SoC, when this is
used on a PCIe card it is not needed.

I would just deactivate the parts that are using device tree in bcma
when it is not available. I will send a patch after having something to eat.

Is there a better method which is compatible with SPARC than using
of_translate_address() to get the reg address and also take the ranges
attribute of the bus into account?

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] bcma: fix build when CONFIG_OF_ADDRESS is not set

2014-10-09 Thread Hauke Mehrtens
Commit 2101e533f41a (bcma: register bcma as device tree driver)
introduces a hard dependency on OF_ADDRESS into the bcma driver.
OF_ADDRESS is specifically disabled for the sparc architecture.
This results in the following error when building sparc64:allmodconfig.

drivers/bcma/main.c: In function 'bcma_of_find_child_device':
drivers/bcma/main.c:150:3: error: implicit declaration of function 
'of_translate_address'

Fixes: 2101e533f41a (bcma: register bcma as device tree driver)
Reported-by: Guenter Roeck li...@roeck-us.net
Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/bcma/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index d1656c2..1000955 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -132,7 +132,7 @@ static bool bcma_is_core_needed_early(u16 core_id)
return false;
 }
 
-#ifdef CONFIG_OF
+#if defined(CONFIG_OF)  defined(CONFIG_OF_ADDRESS)
 static struct device_node *bcma_of_find_child_device(struct platform_device 
*parent,
 struct bcma_device *core)
 {
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH][RFC] bcma: fill core details for every device

2014-10-03 Thread Hauke Mehrtens
On 10/02/2014 12:38 PM, Rafał Miłecki wrote:
 We were setting things like dma_dev, IRQ, etc. during core registration
 only. We need such info for cores handled internally (e.g. ChipCommon)
 as well.
 
 Signed-off-by: Rafał Miłecki zaj...@gmail.com

Acked-by: Hauke Mehrtens ha...@hauke-m.de

I already was preparing a patch doing similar things but this one looks
better.

 ---
  drivers/bcma/bcma_private.h | 1 +
  drivers/bcma/main.c | 9 ++---
  drivers/bcma/scan.c | 1 +
  3 files changed, 8 insertions(+), 3 deletions(-)
 

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] bcma: use device from DT (brcm,bus-gpio) for SoC GPIO chip

2014-09-27 Thread Hauke Mehrtens
On 09/27/2014 10:05 AM, Rafał Miłecki wrote:
 On 27 September 2014 00:03, Arnd Bergmann a...@arndb.de wrote:
 On Friday 26 September 2014 16:28:53 Rafał Miłecki wrote:
 +The top-level axi bus may contain following children:
 +
 +- gpio: GPIO chip on the SoC
 +
 +  Required properties:
 +  - compatible: brcm,bus-gpio
 +  - gpio-controller : makes the node a GPIO controller
 +  - #gpio-cells : size of the GPIO specifier, must be 2
 +


 I wonder if it would be better to avoid the subnode here and just
 make the parent itself the gpio controller.

 Is the gpio controller part of the bus itself in reality, or is it
 a device that gets probed on the bus?
 
 I'm not sure how to treat this chip.
 We control GPIOs using ChipCommon regs (and ChipCommon is one of
 cores/devices on the bus), so you could also consider GPIO chip a
 sub-device of ChipCommon.
 I believe every Broadcom bus has a GPIO chip. In the ancient (MIPS)
 times, even if we didn't have ChipCommon, there was an EXTIF core that
 used to provide access to the GPIO chip.
 
 What do you think? Should I make it separated device, even it if
 depends on the SoC and its ChipCommon core (device)?
 
I would make GPIO a subdevive of chipcommon. The chipcommon core has an
own IRQ which is also used for GPIO.

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] bcma: use device from DT (brcm,bus-gpio) for SoC GPIO chip

2014-09-27 Thread Hauke Mehrtens
On 09/27/2014 12:37 PM, Rafał Miłecki wrote:
 On 27 September 2014 10:33, Hauke Mehrtens ha...@hauke-m.de wrote:
 I would make GPIO a subdevive of chipcommon. The chipcommon core has an
 own IRQ which is also used for GPIO.
 
 Which ChipCommon do yo mean?
 1) chipcommonA (compatible = simple-bus)
 2) chipcommon@0 (child of axi@1800 AKA brcm,bus-axi)

We should combine this (both are describing the same core) I added
chipcommonA to get some serial without adding bcma support first. When
we have dts support added to bcma, I would like to remove chipcommonA
from dtsi and add a chipcommon as a child of axi.

 
 It seems that for some reason both of them use IRQ 85, while the IRQ
 for ChipCommon is 117 I believe.

That's the same.

In the dtsi file it says:
interrupts = GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH;
this will result in the IRQ number 117, when it is GIC_SPI you have to
add 32 to the irq number to get the actual number which will be given to
request_irq().

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v6] bcma: register bcma as device tree driver

2014-09-25 Thread Hauke Mehrtens
This driver is used by the bcm53xx ARM SoC code. Now it is possible to
give the address of the chipcommon core in device tree and bcma will
search for all the other cores.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 Documentation/devicetree/bindings/bus/bcma.txt | 20 +++
 drivers/bcma/bcma_private.h| 14 +
 drivers/bcma/host_soc.c| 81 ++
 drivers/bcma/main.c| 52 -
 include/linux/bcma/bcma.h  |  2 +
 5 files changed, 168 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/bus/bcma.txt

This is based on wireless-testing and should go into that tree.

changes since:
v5:
 - send this patch without the other patch, I will still work on the other one.

v4:
 - move the code adding the device tree to the child driver into this patch
 - remove all references to irq from this patch

v3:
 - remove .owner = THIS_MODULE,

v2:
 - fix description
 - use ranges dt in the example
 - always define a empty implementation of 
   bcma_host_soc_{un}register_driver() when it is build and remove some ifdefs

v1:
 - renamed aix to axi

RFC:
 - reworded the irq description
 - improved the example
 - hocked into bcma_modeinit() and bcma_modexit()

diff --git a/Documentation/devicetree/bindings/bus/bcma.txt 
b/Documentation/devicetree/bindings/bus/bcma.txt
new file mode 100644
index 000..e9070c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/bcma.txt
@@ -0,0 +1,20 @@
+Driver for ARM AXI Bus with Broadcom Plugins (bcma)
+
+Required properties:
+
+- compatible : brcm,bus-axi
+
+- reg : iomem address range of chipcommon core
+
+The cores on the AXI bus are automatically detected by bcma with the
+memory ranges they are using and they get registered afterwards.
+
+Example:
+
+   axi@1800 {
+   compatible = brcm,bus-axi;
+   reg = 0x1800 0x1000;
+   ranges = 0x 0x1800 0x0010;
+   #address-cells = 1;
+   #size-cells = 1;
+   };
diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index b40be43..b6412b2 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
@@ -88,6 +88,20 @@ extern int __init bcma_host_pci_init(void);
 extern void __exit bcma_host_pci_exit(void);
 #endif /* CONFIG_BCMA_HOST_PCI */
 
+/* host_soc.c */
+#if defined(CONFIG_BCMA_HOST_SOC)  defined(CONFIG_OF)
+extern int __init bcma_host_soc_register_driver(void);
+extern void __exit bcma_host_soc_unregister_driver(void);
+#else
+static inline int __init bcma_host_soc_register_driver(void)
+{
+   return 0;
+}
+static inline void __exit bcma_host_soc_unregister_driver(void)
+{
+}
+#endif /* CONFIG_BCMA_HOST_SOC  CONFIG_OF */
+
 /* driver_pci.c */
 u32 bcma_pcie_read(struct bcma_drv_pci *pc, u32 address);
 
diff --git a/drivers/bcma/host_soc.c b/drivers/bcma/host_soc.c
index 718e054..335cbcf 100644
--- a/drivers/bcma/host_soc.c
+++ b/drivers/bcma/host_soc.c
@@ -7,6 +7,9 @@
 
 #include bcma_private.h
 #include scan.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/of_address.h
 #include linux/bcma/bcma.h
 #include linux/bcma/bcma_soc.h
 
@@ -176,6 +179,7 @@ int __init bcma_host_soc_register(struct bcma_soc *soc)
/* Host specific */
bus-hosttype = BCMA_HOSTTYPE_SOC;
bus-ops = bcma_host_soc_ops;
+   bus-host_pdev = NULL;
 
/* Initialize struct, detect chip */
bcma_init_bus(bus);
@@ -195,3 +199,80 @@ int __init bcma_host_soc_init(struct bcma_soc *soc)
 
return err;
 }
+
+#ifdef CONFIG_OF
+static int bcma_host_soc_probe(struct platform_device *pdev)
+{
+   struct device *dev = pdev-dev;
+   struct device_node *np = dev-of_node;
+   struct bcma_bus *bus;
+   int err;
+
+   /* Alloc */
+   bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
+   if (!bus)
+   return -ENOMEM;
+
+   /* Map MMIO */
+   bus-mmio = of_iomap(np, 0);
+   if (!bus-mmio)
+   return -ENOMEM;
+
+   /* Host specific */
+   bus-hosttype = BCMA_HOSTTYPE_SOC;
+   bus-ops = bcma_host_soc_ops;
+   bus-host_pdev = pdev;
+
+   /* Initialize struct, detect chip */
+   bcma_init_bus(bus);
+
+   /* Register */
+   err = bcma_bus_register(bus);
+   if (err)
+   goto err_unmap_mmio;
+
+   platform_set_drvdata(pdev, bus);
+
+   return err;
+
+err_unmap_mmio:
+   iounmap(bus-mmio);
+   return err;
+}
+
+static int bcma_host_soc_remove(struct platform_device *pdev)
+{
+   struct bcma_bus *bus = platform_get_drvdata(pdev);
+
+   bcma_bus_unregister(bus);
+   iounmap(bus-mmio);
+   platform_set_drvdata(pdev, NULL);
+
+   return 0;
+}
+
+static const struct of_device_id bcma_host_soc_of_match[] = {
+   { .compatible = brcm,bus-axi, },
+   {},
+};
+MODULE_DEVICE_TABLE

Re: [PATCH v4 1/2] bcma: register bcma as device tree driver

2014-09-24 Thread Hauke Mehrtens
On 09/24/2014 11:48 AM, Arnd Bergmann wrote:
 On Wednesday 24 September 2014 00:04:18 Hauke Mehrtens wrote:
 I assume this should then look somehow like this:

 axi@1800 {
 compatible = brcm,bus-axi;
 reg = 0x1800 0x1000;
 ranges = 0x 0x1800 0x0010;
 #address-cells = 1;
 #size-cells = 1;

 #interrupt-cells = 1;
 interrupt-map = 
 /* ChipCommon */
 0x 0 gic  GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH

 /* PCIe Controller 0 */
 0x00012000 0 gic GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH
 0x00012000 1 gic GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH
 0x00012000 2 gic GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH
 0x00012000 3 gic GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH
 0x00012000 4 gic GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH
 0x00012000 5 gic GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH

 /* USB 2.0 Controller */
 0x00021000 0 gic GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH
 ;
 };
 
 Right, although I would add a few more '', '' and ',' for readability,
 separating each line with a comma.
 
 You are also missing an 'interrupt-map-mask' property that lists which
 bits of the address are significant.
 
 Are the interrupt numbers you have in the example (0, 0, 1, 2, ... 5, 0)
 the actual numbers that are present in the hw registers?

Some cores do have more than one IRQ. The NAND core uses 8 IRQs and the
PCIe controller uses 5 (the vendor code just uses the last one which
gets triggered always). How can I handle this cases where one device has
more than one IRQ? There is no hardware register these IRQ get mapped
to. As far as I know the driver just knows that this device needs more
IRQs. Should I just add a special device node entry for such devices?

 How does the mapping of these interrupts to the devices work?
 
 The same way that of_irq_parse_and_map_pci() works (the second half of it).
 It's a very similar situation: you have a discoverable bus on which the
 interrupts are listed in a different domain from which they are supposed to
 be on the parent. The trick is to make up your own address property
 and of_phandle_args on the stack and fill that with the data from
 the hw bus scan, so you can get into the middle of the normal DT
 irq code that gets them from device nodes.

Thanks for the description, that worked for me.

 Do I have to add a device tree entry for every device after all?
 
 No, unless you want to add other properties in the node, such as
 a MAC address, but then you still only need some of the devices.
 
 Do you have some example code where this is handled in code, I could not
 find the code doing this for PCI.
 
 drivers/of/of_pci_irq.c, though the hard part is done in drivers/of/irq.c,
 which parses the interrupt-map and interrupt-map-mask properties.


I will split this patch into two patches, one just adding the bcma
registration and an additional RFC patch adding the IRQ stuff.

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v5 1/2] bcma: register bcma as device tree driver

2014-09-24 Thread Hauke Mehrtens
This driver is used by the bcm53xx ARM SoC code. Now it is possible to
give the address of the chipcommon core in device tree and bcma will
search for all the other cores.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 Documentation/devicetree/bindings/bus/bcma.txt | 20 +++
 drivers/bcma/bcma_private.h| 14 +
 drivers/bcma/host_soc.c| 81 ++
 drivers/bcma/main.c| 52 -
 include/linux/bcma/bcma.h  |  2 +
 5 files changed, 168 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/bus/bcma.txt

This is based on wireless-testing and should go into that tree.

changes since:
v4:
 - move the code adding the device tree to the child driver into this patch
 - remove all references to irq from this patch

v3:
 - remove .owner = THIS_MODULE,

v2:
 - fix description
 - use ranges dt in the example
 - always define a empty implementation of 
   bcma_host_soc_{un}register_driver() when it is build and remove some ifdefs

v1:
 - renamed aix to axi

RFC:
 - reworded the irq description
 - improved the example
 - hocked into bcma_modeinit() and bcma_modexit()

diff --git a/Documentation/devicetree/bindings/bus/bcma.txt 
b/Documentation/devicetree/bindings/bus/bcma.txt
new file mode 100644
index 000..e9070c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/bcma.txt
@@ -0,0 +1,20 @@
+Driver for ARM AXI Bus with Broadcom Plugins (bcma)
+
+Required properties:
+
+- compatible : brcm,bus-axi
+
+- reg : iomem address range of chipcommon core
+
+The cores on the AXI bus are automatically detected by bcma with the
+memory ranges they are using and they get registered afterwards.
+
+Example:
+
+   axi@1800 {
+   compatible = brcm,bus-axi;
+   reg = 0x1800 0x1000;
+   ranges = 0x 0x1800 0x0010;
+   #address-cells = 1;
+   #size-cells = 1;
+   };
diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index b40be43..b6412b2 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
@@ -88,6 +88,20 @@ extern int __init bcma_host_pci_init(void);
 extern void __exit bcma_host_pci_exit(void);
 #endif /* CONFIG_BCMA_HOST_PCI */
 
+/* host_soc.c */
+#if defined(CONFIG_BCMA_HOST_SOC)  defined(CONFIG_OF)
+extern int __init bcma_host_soc_register_driver(void);
+extern void __exit bcma_host_soc_unregister_driver(void);
+#else
+static inline int __init bcma_host_soc_register_driver(void)
+{
+   return 0;
+}
+static inline void __exit bcma_host_soc_unregister_driver(void)
+{
+}
+#endif /* CONFIG_BCMA_HOST_SOC  CONFIG_OF */
+
 /* driver_pci.c */
 u32 bcma_pcie_read(struct bcma_drv_pci *pc, u32 address);
 
diff --git a/drivers/bcma/host_soc.c b/drivers/bcma/host_soc.c
index 718e054..335cbcf 100644
--- a/drivers/bcma/host_soc.c
+++ b/drivers/bcma/host_soc.c
@@ -7,6 +7,9 @@
 
 #include bcma_private.h
 #include scan.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/of_address.h
 #include linux/bcma/bcma.h
 #include linux/bcma/bcma_soc.h
 
@@ -176,6 +179,7 @@ int __init bcma_host_soc_register(struct bcma_soc *soc)
/* Host specific */
bus-hosttype = BCMA_HOSTTYPE_SOC;
bus-ops = bcma_host_soc_ops;
+   bus-host_pdev = NULL;
 
/* Initialize struct, detect chip */
bcma_init_bus(bus);
@@ -195,3 +199,80 @@ int __init bcma_host_soc_init(struct bcma_soc *soc)
 
return err;
 }
+
+#ifdef CONFIG_OF
+static int bcma_host_soc_probe(struct platform_device *pdev)
+{
+   struct device *dev = pdev-dev;
+   struct device_node *np = dev-of_node;
+   struct bcma_bus *bus;
+   int err;
+
+   /* Alloc */
+   bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
+   if (!bus)
+   return -ENOMEM;
+
+   /* Map MMIO */
+   bus-mmio = of_iomap(np, 0);
+   if (!bus-mmio)
+   return -ENOMEM;
+
+   /* Host specific */
+   bus-hosttype = BCMA_HOSTTYPE_SOC;
+   bus-ops = bcma_host_soc_ops;
+   bus-host_pdev = pdev;
+
+   /* Initialize struct, detect chip */
+   bcma_init_bus(bus);
+
+   /* Register */
+   err = bcma_bus_register(bus);
+   if (err)
+   goto err_unmap_mmio;
+
+   platform_set_drvdata(pdev, bus);
+
+   return err;
+
+err_unmap_mmio:
+   iounmap(bus-mmio);
+   return err;
+}
+
+static int bcma_host_soc_remove(struct platform_device *pdev)
+{
+   struct bcma_bus *bus = platform_get_drvdata(pdev);
+
+   bcma_bus_unregister(bus);
+   iounmap(bus-mmio);
+   platform_set_drvdata(pdev, NULL);
+
+   return 0;
+}
+
+static const struct of_device_id bcma_host_soc_of_match[] = {
+   { .compatible = brcm,bus-axi, },
+   {},
+};
+MODULE_DEVICE_TABLE(of, bcma_host_soc_of_match);
+
+static struct platform_driver bcma_host_soc_driver = {
+   .driver

[PATCH v5 2/2] bcma: get IRQ numbers from dt

2014-09-24 Thread Hauke Mehrtens
It is not possible to auto detect the irq numbers used by the cores on
an arm SoC. If bcma was registered with device tree it will search for
some device tree nodes with the irq number and add it to the core
configuration.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 Documentation/devicetree/bindings/bus/bcma.txt | 24 +++
 drivers/bcma/main.c| 42 ++
 2 files changed, 66 insertions(+)

This is based on wireless-testing and should go into that tree.

changes since:
v4:
 - make use of interrupt-map
 - only do the irq stuff here

v2:
 - use of_translate_address() to support ranges

RFC:
 - add #ifdef CONFIG_OF

diff --git a/Documentation/devicetree/bindings/bus/bcma.txt 
b/Documentation/devicetree/bindings/bus/bcma.txt
index e9070c1..1dc75d3 100644
--- a/Documentation/devicetree/bindings/bus/bcma.txt
+++ b/Documentation/devicetree/bindings/bus/bcma.txt
@@ -8,6 +8,10 @@ Required properties:
 
 The cores on the AXI bus are automatically detected by bcma with the
 memory ranges they are using and they get registered afterwards.
+Automatic detection of the IRQ number is not reliable on
+BCM47xx/BCM53xx ARM SoCs. To assign IRQ numbers to the cores, provide
+them manually through device tree. The IRQ number and the device tree
+child entry will get assigned to the core with the matching reg address.
 
 Example:
 
@@ -17,4 +21,24 @@ Example:
ranges = 0x 0x1800 0x0010;
#address-cells = 1;
#size-cells = 1;
+
+   #interrupt-cells = 0;
+   interrupt-map-mask = 0x000f;
+   interrupt-map =
+   /* Ethernet Controller 0 */
+   0x00024000 gic GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH,
+
+   /* Ethernet Controller 1 */
+   0x00025000 gic GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH;
+
+   pcie@12000 {
+   interrupt-parent = gic;
+   reg = 0x00012000 0x1000;
+   interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH;
+   };
};
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index d1656c2..870f01d 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -11,6 +11,7 @@
 #include linux/bcma/bcma.h
 #include linux/slab.h
 #include linux/of_address.h
+#include linux/of_irq.h
 
 MODULE_DESCRIPTION(Broadcom's specific AMBA driver);
 MODULE_LICENSE(GPL);
@@ -153,6 +154,45 @@ static struct device_node 
*bcma_of_find_child_device(struct platform_device *par
return NULL;
 }
 
+static int bcma_of_irq_parse(struct platform_device *parent,
+struct bcma_device *core,
+struct of_phandle_args *out_irq)
+{
+   __be32 laddr[1];
+   int rc;
+
+   if (core-dev.of_node) {
+   rc = of_irq_parse_one(core-dev.of_node, 0, out_irq);
+   if (!rc)
+   return rc;
+   }
+
+   out_irq-np = parent-dev.of_node;
+   out_irq-args_count = 0;
+
+   laddr[0] = cpu_to_be32(core-addr);
+   return of_irq_parse_raw(laddr, out_irq);
+}
+
+static int bcma_of_get_irq(struct platform_device *parent,
+  struct bcma_device *core)
+{
+   struct of_phandle_args out_irq;
+   int ret;
+
+   if (!parent || !parent-dev.of_node)
+   return 0;
+
+   ret = bcma_of_irq_parse(parent, core, out_irq);
+   if (ret) {
+   bcma_debug(core-bus, bcma_of_get_irq() failed with rc=%d\n,
+  ret);
+   return 0;
+   }
+
+   return irq_create_of_mapping(out_irq);
+}
+
 static void bcma_of_fill_device(struct platform_device *parent,
struct bcma_device *core)
 {
@@ -161,6 +201,8 @@ static void bcma_of_fill_device(struct platform_device 
*parent,
node = bcma_of_find_child_device(parent, core);
if (node)
core-dev.of_node = node;
+
+   core-irq = bcma_of_get_irq(parent, core);
 }
 #else
 static void bcma_of_fill_device(struct platform_device *parent,
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v4 1/2] bcma: register bcma as device tree driver

2014-09-21 Thread Hauke Mehrtens
This driver is used by the bcm53xx ARM SoC code. Now it is possible to
give the address of the chipcommon core in device tree and bcma will
search for all the other cores.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 Documentation/devicetree/bindings/bus/bcma.txt | 39 +
 drivers/bcma/bcma_private.h| 14 +
 drivers/bcma/host_soc.c| 81 ++
 drivers/bcma/main.c|  6 ++
 include/linux/bcma/bcma.h  |  2 +
 5 files changed, 142 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/bcma.txt

This is based on wireless-testing and should go into that tree.

changes since:
v3:
 - remove .owner = THIS_MODULE,

v2:
 - fix description
 - use ranges dt in the example
 - always define a empty implementation of 
   bcma_host_soc_{un}register_driver() when it is build and remove some ifdefs

v1:
 - renamed aix to axi

RFC:
 - reworded the irq description
 - improved the example
 - hocked into bcma_modeinit() and bcma_modexit()

diff --git a/Documentation/devicetree/bindings/bus/bcma.txt 
b/Documentation/devicetree/bindings/bus/bcma.txt
new file mode 100644
index 000..33fc6eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/bcma.txt
@@ -0,0 +1,39 @@
+Driver for ARM AXI Bus with Broadcom Plugins (bcma)
+
+Required properties:
+
+- compatible : brcm,bus-axi
+
+- reg : iomem address range of chipcommon core
+
+The cores on the AXI bus are automatically detected by bcma with the
+memory ranges they are using and they get registered afterwards.
+Automatic detection of the IRQ number is not reliable on
+BCM47xx/BCM53xx ARM SoCs. To assign IRQ numbers to the cores, provide
+them manually through device tree. The IRQ number and the device tree
+child entry will get assigned to the core with the matching reg address.
+
+Example:
+
+   axi@1800 {
+   compatible = brcm,bus-axi;
+   reg = 0x1800 0x1000;
+   ranges = 0x 0x1800 0x0010;
+   #address-cells = 1;
+   #size-cells = 1;
+
+   pcie@12000 {
+   reg = 0x00012000 0x1000;
+   interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH;
+   };
+
+   ethernet@24000 {
+   reg = 0x00024000 0x1000;
+   interrupts = GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH;
+   };
+
+   ethernet@25000 {
+   reg = 0x00025000 0x1000;
+   interrupts = GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH;
+   };
+   };
diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index b40be43..b6412b2 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
@@ -88,6 +88,20 @@ extern int __init bcma_host_pci_init(void);
 extern void __exit bcma_host_pci_exit(void);
 #endif /* CONFIG_BCMA_HOST_PCI */
 
+/* host_soc.c */
+#if defined(CONFIG_BCMA_HOST_SOC)  defined(CONFIG_OF)
+extern int __init bcma_host_soc_register_driver(void);
+extern void __exit bcma_host_soc_unregister_driver(void);
+#else
+static inline int __init bcma_host_soc_register_driver(void)
+{
+   return 0;
+}
+static inline void __exit bcma_host_soc_unregister_driver(void)
+{
+}
+#endif /* CONFIG_BCMA_HOST_SOC  CONFIG_OF */
+
 /* driver_pci.c */
 u32 bcma_pcie_read(struct bcma_drv_pci *pc, u32 address);
 
diff --git a/drivers/bcma/host_soc.c b/drivers/bcma/host_soc.c
index 718e054..335cbcf 100644
--- a/drivers/bcma/host_soc.c
+++ b/drivers/bcma/host_soc.c
@@ -7,6 +7,9 @@
 
 #include bcma_private.h
 #include scan.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/of_address.h
 #include linux/bcma/bcma.h
 #include linux/bcma/bcma_soc.h
 
@@ -176,6 +179,7 @@ int __init bcma_host_soc_register(struct bcma_soc *soc)
/* Host specific */
bus-hosttype = BCMA_HOSTTYPE_SOC;
bus-ops = bcma_host_soc_ops;
+   bus-host_pdev = NULL;
 
/* Initialize struct, detect chip */
bcma_init_bus(bus);
@@ -195,3 +199,80 @@ int __init bcma_host_soc_init(struct bcma_soc *soc)
 
return err;
 }
+
+#ifdef CONFIG_OF
+static int bcma_host_soc_probe(struct platform_device *pdev)
+{
+   struct device *dev = pdev-dev;
+   struct device_node *np = dev-of_node;
+   struct bcma_bus *bus;
+   int err;
+
+   /* Alloc */
+   bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
+   if (!bus)
+   return -ENOMEM;
+
+   /* Map MMIO */
+   bus-mmio = of_iomap(np, 0);
+   if (!bus-mmio)
+   return -ENOMEM;
+
+   /* Host specific */
+   bus-hosttype = BCMA_HOSTTYPE_SOC;
+   bus-ops = bcma_host_soc_ops;
+   bus-host_pdev = pdev;
+
+   /* Initialize struct, detect chip */
+   bcma_init_bus(bus);
+
+   /* Register */
+   err = bcma_bus_register(bus);
+   if (err)
+   goto err_unmap_mmio

[PATCH v4 2/2] bcma: get IRQ numbers from dt

2014-09-21 Thread Hauke Mehrtens
It is not possible to auto detect the irq numbers used by the cores on
an arm SoC. If bcma was registered with device tree it will search for
some device tree nodes with the irq number and add it to the core
configuration.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/bcma/main.c | 49 -
 1 file changed, 48 insertions(+), 1 deletion(-)

This is based on wireless-testing and should go into that tree.

changes since:
v2:
 - use of_translate_address() to support ranges

RFC:
 - add #ifdef CONFIG_OF

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 19ef685..5e7a3d4 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -10,6 +10,8 @@
 #include linux/platform_device.h
 #include linux/bcma/bcma.h
 #include linux/slab.h
+#include linux/of_irq.h
+#include linux/of_address.h
 
 MODULE_DESCRIPTION(Broadcom's specific AMBA driver);
 MODULE_LICENSE(GPL);
@@ -131,6 +133,45 @@ static bool bcma_is_core_needed_early(u16 core_id)
return false;
 }
 
+#ifdef CONFIG_OF
+static struct device_node *bcma_of_find_child_device(struct platform_device 
*parent,
+struct bcma_device *core)
+{
+   struct device_node *node;
+   u64 size;
+   const __be32 *reg;
+
+   if (!parent || !parent-dev.of_node)
+   return NULL;
+
+   for_each_child_of_node(parent-dev.of_node, node) {
+   reg = of_get_address(node, 0, size, NULL);
+   if (!reg)
+   continue;
+   if (of_translate_address(node, reg) == core-addr)
+   return node;
+   }
+   return NULL;
+}
+
+static void bcma_of_fill_device(struct platform_device *parent,
+   struct bcma_device *core)
+{
+   struct device_node *node;
+
+   node = bcma_of_find_child_device(parent, core);
+   if (!node)
+   return;
+   core-dev.of_node = node;
+   core-irq = irq_of_parse_and_map(node, 0);
+}
+#else
+static void bcma_of_fill_device(struct platform_device *parent,
+   struct bcma_device *core)
+{
+}
+#endif /* CONFIG_OF */
+
 static void bcma_register_core(struct bcma_bus *bus, struct bcma_device *core)
 {
int err;
@@ -147,7 +188,13 @@ static void bcma_register_core(struct bcma_bus *bus, 
struct bcma_device *core)
break;
case BCMA_HOSTTYPE_SOC:
core-dev.dma_mask = core-dev.coherent_dma_mask;
-   core-dma_dev = core-dev;
+   if (bus-host_pdev) {
+   core-dma_dev = bus-host_pdev-dev;
+   core-dev.parent = bus-host_pdev-dev;
+   bcma_of_fill_device(bus-host_pdev, core);
+   } else {
+   core-dma_dev = core-dev;
+   }
break;
case BCMA_HOSTTYPE_SDIO:
break;
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 2/2] bcma: get IRQ numbers from dt

2014-09-20 Thread Hauke Mehrtens
It is not possible to auto detect the irq numbers used by the cores on
an arm SoC. If bcma was registered with device tree it will search for
some device tree nodes with the irq number and add it to the core
configuration.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/bcma/main.c | 49 -
 1 file changed, 48 insertions(+), 1 deletion(-)


This is based on wireless-testing and should go into that tree.

changes since:
v2:
 - use of_translate_address() to support ranges

RFC:
 - add #ifdef CONFIG_OF
 
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 19ef685..5e7a3d4 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -10,6 +10,8 @@
 #include linux/platform_device.h
 #include linux/bcma/bcma.h
 #include linux/slab.h
+#include linux/of_irq.h
+#include linux/of_address.h
 
 MODULE_DESCRIPTION(Broadcom's specific AMBA driver);
 MODULE_LICENSE(GPL);
@@ -131,6 +133,45 @@ static bool bcma_is_core_needed_early(u16 core_id)
return false;
 }
 
+#ifdef CONFIG_OF
+static struct device_node *bcma_of_find_child_device(struct platform_device 
*parent,
+struct bcma_device *core)
+{
+   struct device_node *node;
+   u64 size;
+   const __be32 *reg;
+
+   if (!parent || !parent-dev.of_node)
+   return NULL;
+
+   for_each_child_of_node(parent-dev.of_node, node) {
+   reg = of_get_address(node, 0, size, NULL);
+   if (!reg)
+   continue;
+   if (of_translate_address(node, reg) == core-addr)
+   return node;
+   }
+   return NULL;
+}
+
+static void bcma_of_fill_device(struct platform_device *parent,
+   struct bcma_device *core)
+{
+   struct device_node *node;
+
+   node = bcma_of_find_child_device(parent, core);
+   if (!node)
+   return;
+   core-dev.of_node = node;
+   core-irq = irq_of_parse_and_map(node, 0);
+}
+#else
+static void bcma_of_fill_device(struct platform_device *parent,
+   struct bcma_device *core)
+{
+}
+#endif /* CONFIG_OF */
+
 static void bcma_register_core(struct bcma_bus *bus, struct bcma_device *core)
 {
int err;
@@ -147,7 +188,13 @@ static void bcma_register_core(struct bcma_bus *bus, 
struct bcma_device *core)
break;
case BCMA_HOSTTYPE_SOC:
core-dev.dma_mask = core-dev.coherent_dma_mask;
-   core-dma_dev = core-dev;
+   if (bus-host_pdev) {
+   core-dma_dev = bus-host_pdev-dev;
+   core-dev.parent = bus-host_pdev-dev;
+   bcma_of_fill_device(bus-host_pdev, core);
+   } else {
+   core-dma_dev = core-dev;
+   }
break;
case BCMA_HOSTTYPE_SDIO:
break;
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/2] bcma: register bcma as device tree driver

2014-09-20 Thread Hauke Mehrtens
On 09/20/2014 05:40 PM, Varka Bhadram wrote:
 On Saturday 20 September 2014 06:32 PM, Hauke Mehrtens wrote:
 This driver is used by the bcm53xx ARM SoC code. Now it is possible to
 give the address of the chipcommon core in device tree and bcma will
 search for all the other cores.
 
 (...)
 
 +
 +static const struct of_device_id bcma_host_soc_of_match[] = {
 +{ .compatible = brcm,bus-axi, },
 +{},
 +};
 +MODULE_DEVICE_TABLE(of, bcma_host_soc_of_match);
 +
 +static struct platform_driver bcma_host_soc_driver = {
 +.driver = {
 +.name = bcma-host-soc,
 +.owner = THIS_MODULE,
 
 This field updated automatically...

Ok, I will remove this line.

 +.of_match_table = bcma_host_soc_of_match,
 +},
 +.probe= bcma_host_soc_probe,
 +.remove= bcma_host_soc_remove,
 +};
 +
 +int __init bcma_host_soc_register_driver(void)
 +{
 +return platform_driver_register(bcma_host_soc_driver);
 +}
 +
 +void __exit bcma_host_soc_unregister_driver(void)
 +{
 +platform_driver_unregister(bcma_host_soc_driver);
 +}
 +#endif /* CONFIG_OF */
 
 Why dont you use module_platform_driver(...)...?

module_platform_driver() does not work, because we can only have one
module_init() method in a module and main.c already has one. This driver
can also be registered as an PCI device.

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] bcma: register bcma as device tree driver

2014-09-18 Thread Hauke Mehrtens
On 09/18/2014 11:42 AM, Arend van Spriel wrote:
 On 09/17/14 17:10, Rafał Miłecki wrote:
 On 16 September 2014 23:56, Hauke Mehrtensha...@hauke-m.de  wrote:
 This driver is used by the bcm53xx ARM SoC code. Now it is possible to
 give the address of the chipcommon core in device tree and bcma will
 search for all the other cores.

 Did you get any answer from Arend about detecting IRQs?

 If not:
 Arend: how much time it make take you to get an answer?
 
 I already discussed this with our chip architect. There is a chip design
 rule that core index corresponds to the irq number. This at least is
 true for the bcm43xx devices, but unsure about others. So that option
 does not seem to fit. That leaves the OOB_ROUTER core I mentioned
 earlier, but it is a chip designers nightmare as they told me. Did not
 sound encouraging enough to start digging in there to obtain the
 information.

Thanks for asking around.

I will go with specifying the IRQs in device tree then.

Hauke
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] bcma: register bcma as device tree driver

2014-09-18 Thread Hauke Mehrtens
On 09/18/2014 10:03 PM, Rafał Miłecki wrote:
 On 16 September 2014 23:56, Hauke Mehrtens ha...@hauke-m.de wrote:
 +The cores on the AXI bus are auto detected by bcma. bcma automatically
 +detects the cores
 
 I'm far from being an English expert, but above is kind of pleonasm to me ;)

Yes to me too. ;-)

 and the memory ranges they are using and they get
 +registered afterwards. Automatic detection of the IRQ number is not
 +possible on BCM47xx/BCM53xx ARM and MIPS SoCs.
 
 Should we replace not possible with something like not reliable?
 After the last info we got from Arend.

Yes that sounds good.

 
 
 +#ifdef CONFIG_BCMA_HOST_SOC
 +/* host_pci.c */
 
 s/pci/soc/
 
 
 +#ifdef CONFIG_OF
 +extern int __init bcma_host_soc_register_driver(void);
 +extern void __exit bcma_host_soc_unregister_driver(void);
 +#else
 +static inline int __init bcma_host_soc_register_driver(void)
 +{
 +   return 0;
 +}
 +static inline void __exit bcma_host_soc_unregister_driver(void)
 +{
 +}
 +#endif /* CONFIG_OF */
 +#endif /* CONFIG_BCMA_HOST_SOC */
 
 OK, so you just made bcma_host_soc_(un)register_driver calls safe above.
 
 
 diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
 index c421403..e5d578c 100644
 --- a/drivers/bcma/main.c
 +++ b/drivers/bcma/main.c
 @@ -528,6 +528,13 @@ static int __init bcma_modinit(void)
 if (err)
 return err;

 +#ifdef CONFIG_BCMA_HOST_SOC
 +   err = bcma_host_soc_register_driver();
 +   if (err) {
 +   pr_err(SoC host initialization failed\n);
 +   err = 0;
 +   }
 +#endif
 
 And above you check for CONFIG_ anyway.
 
Yes that sounds good.

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 1/2] bcma: register bcma as device tree driver

2014-09-16 Thread Hauke Mehrtens
This driver is used by the bcm53xx ARM SoC code. Now it is possible to
give the address of the chipcommon core in device tree and bcma will
search for all the other cores.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 Documentation/devicetree/bindings/bus/bcma.txt | 40 +
 drivers/bcma/bcma_private.h| 16 +
 drivers/bcma/host_soc.c| 82 ++
 drivers/bcma/main.c| 10 
 include/linux/bcma/bcma.h  |  2 +
 5 files changed, 150 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/bcma.txt

This is based on wireless-testing and should go into that tree.

changes since:
v1:
 - renamed aix to axi
RFC:
 - reworded the irq description
 - improved the example
 - hocked into bcma_modeinit() and bcma_modexit()

diff --git a/Documentation/devicetree/bindings/bus/bcma.txt 
b/Documentation/devicetree/bindings/bus/bcma.txt
new file mode 100644
index 000..f06f5c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/bcma.txt
@@ -0,0 +1,40 @@
+Driver for ARM AXI Bus with Broadcom Plugins (bcma)
+
+Required properties:
+
+- compatible : brcm,bus-axi
+
+- reg : iomem address range of chipcommon core
+
+The cores on the AXI bus are auto detected by bcma. bcma automatically 
+detects the cores and the memory ranges they are using and they get 
+registered afterwards. Automatic detection of the IRQ number is not 
+possible on BCM47xx/BCM53xx ARM and MIPS SoCs. To assign IRQ number to 
+the cores, provide them manually through device tree. The IRQ number 
+and the device tree child entry will get assigned to the core with the 
+matching reg address.
+
+Example:
+
+   axi@1800 {
+   compatible = brcm,bus-axi;
+   reg = 0x1800 0x1000;
+   ranges = 0x 0x1800 0x0010;
+   #address-cells = 1;
+   #size-cells = 1;
+
+   ethernet@18024000 {
+   reg = 0x18024000 0x1000;
+   interrupts = GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH;
+   };
+
+   ethernet@18025000 {
+   reg = 0x18025000 0x1000;
+   interrupts = GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH;
+   };
+
+   pcie@18012000 {
+   reg = 0x18012000 0x1000;
+   interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH;
+   };
+   };
diff --git a/drivers/bcma/bcma_private.h b/drivers/bcma/bcma_private.h
index b40be43..b8728f0 100644
--- a/drivers/bcma/bcma_private.h
+++ b/drivers/bcma/bcma_private.h
@@ -88,6 +88,22 @@ extern int __init bcma_host_pci_init(void);
 extern void __exit bcma_host_pci_exit(void);
 #endif /* CONFIG_BCMA_HOST_PCI */
 
+#ifdef CONFIG_BCMA_HOST_SOC
+/* host_pci.c */
+#ifdef CONFIG_OF
+extern int __init bcma_host_soc_register_driver(void);
+extern void __exit bcma_host_soc_unregister_driver(void);
+#else
+static inline int __init bcma_host_soc_register_driver(void)
+{
+   return 0;
+}
+static inline void __exit bcma_host_soc_unregister_driver(void)
+{
+}
+#endif /* CONFIG_OF */
+#endif /* CONFIG_BCMA_HOST_SOC */
+
 /* driver_pci.c */
 u32 bcma_pcie_read(struct bcma_drv_pci *pc, u32 address);
 
diff --git a/drivers/bcma/host_soc.c b/drivers/bcma/host_soc.c
index 718e054..cfbf3b3 100644
--- a/drivers/bcma/host_soc.c
+++ b/drivers/bcma/host_soc.c
@@ -7,6 +7,9 @@
 
 #include bcma_private.h
 #include scan.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/of_address.h
 #include linux/bcma/bcma.h
 #include linux/bcma/bcma_soc.h
 
@@ -176,6 +179,7 @@ int __init bcma_host_soc_register(struct bcma_soc *soc)
/* Host specific */
bus-hosttype = BCMA_HOSTTYPE_SOC;
bus-ops = bcma_host_soc_ops;
+   bus-host_pdev = NULL;
 
/* Initialize struct, detect chip */
bcma_init_bus(bus);
@@ -195,3 +199,81 @@ int __init bcma_host_soc_init(struct bcma_soc *soc)
 
return err;
 }
+
+#ifdef CONFIG_OF
+static int bcma_host_soc_probe(struct platform_device *pdev)
+{
+   struct device *dev = pdev-dev;
+   struct device_node *np = dev-of_node;
+   struct bcma_bus *bus;
+   int err;
+
+   /* Alloc */
+   bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
+   if (!bus)
+   return -ENOMEM;
+
+   /* Map MMIO */
+   bus-mmio = of_iomap(np, 0);
+   if (!bus-mmio)
+   return -ENOMEM;
+
+   /* Host specific */
+   bus-hosttype = BCMA_HOSTTYPE_SOC;
+   bus-ops = bcma_host_soc_ops;
+   bus-host_pdev = pdev;
+
+   /* Initialize struct, detect chip */
+   bcma_init_bus(bus);
+
+   /* Register */
+   err = bcma_bus_register(bus);
+   if (err)
+   goto err_unmap_mmio;
+
+   platform_set_drvdata(pdev, bus);
+
+   return err;
+
+err_unmap_mmio:
+   iounmap(bus-mmio);
+   return err;
+}
+
+static int

[PATCH v2 2/2] bcma: get IRQ numbers from dt

2014-09-16 Thread Hauke Mehrtens
It is not possible to auto detect the irq numbers used by the cores on
an arm SoC. If bcma was registered with device tree it will search for
some device tree nodes with the irq number and add it to the core
configuration.

Signed-off-by: Hauke Mehrtens ha...@hauke-m.de
---
 drivers/bcma/main.c | 49 -
 1 file changed, 48 insertions(+), 1 deletion(-)

This is based on wireless-testing and should go into that tree.

changes since:
RFC:
 - add #ifdef CONFIG_OF

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index e5d578c..b8731ee 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -10,6 +10,8 @@
 #include linux/platform_device.h
 #include linux/bcma/bcma.h
 #include linux/slab.h
+#include linux/of_irq.h
+#include linux/of_address.h
 
 MODULE_DESCRIPTION(Broadcom's specific AMBA driver);
 MODULE_LICENSE(GPL);
@@ -131,6 +133,45 @@ static bool bcma_is_core_needed_early(u16 core_id)
return false;
 }
 
+#ifdef CONFIG_OF
+static struct device_node *bcma_of_find_child_device(struct platform_device 
*parent,
+struct bcma_device *core)
+{
+   struct device_node *node;
+   u64 size;
+   const __be32 *reg;
+
+   if (!parent || !parent-dev.of_node)
+   return NULL;
+
+   for_each_child_of_node(parent-dev.of_node, node) {
+   reg = of_get_address(node, 0, size, NULL);
+   if (!reg)
+   continue;
+   if (be32_to_cpup(reg) == core-addr)
+   return node;
+   }
+   return NULL;
+}
+
+static void bcma_of_fill_device(struct platform_device *parent,
+   struct bcma_device *core)
+{
+   struct device_node *node;
+
+   node = bcma_of_find_child_device(parent, core);
+   if (!node)
+   return;
+   core-dev.of_node = node;
+   core-irq = irq_of_parse_and_map(node, 0);
+}
+#else
+static void bcma_of_fill_device(struct platform_device *parent,
+   struct bcma_device *core)
+{
+}
+#endif /* CONFIG_OF */
+
 static void bcma_register_core(struct bcma_bus *bus, struct bcma_device *core)
 {
int err;
@@ -147,7 +188,13 @@ static void bcma_register_core(struct bcma_bus *bus, 
struct bcma_device *core)
break;
case BCMA_HOSTTYPE_SOC:
core-dev.dma_mask = core-dev.coherent_dma_mask;
-   core-dma_dev = core-dev;
+   if (bus-host_pdev) {
+   core-dma_dev = bus-host_pdev-dev;
+   core-dev.parent = bus-host_pdev-dev;
+   bcma_of_fill_device(bus-host_pdev, core);
+   } else {
+   core-dma_dev = core-dev;
+   }
break;
case BCMA_HOSTTYPE_SDIO:
break;
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] bcma: use separated function to initialize bus on SoC

2014-09-03 Thread Hauke Mehrtens
On 09/01/2014 11:11 PM, Rafał Miłecki wrote:
 This is required to split SoC bus init into two phases. The later one
 (which includes scanning) should be called when kalloc is available.
 
 Cc: Ralf Baechle r...@linux-mips.org
 Signed-off-by: Rafał Miłecki zaj...@gmail.com

Acked-by: Hauke Mehrtens ha...@hauke-m.de

 ---
 John: please note this patch touches arch/mips/bcm47xx/setup.c
 
 This patches is a first step of simplifying MIPS booting process on
 Broadcom SoCs. My research described in:
 Booting bcm47xx (bcma  stuff), sharing code with bcm53xx
 e-mail thread explained how we could get rid of all these early scanning
 tricks. The main idea is to postpone bus initialization a bit and use
 all standard calls then. So far we were doing it so early we had to
 avoid kalloc.
 ---
  arch/mips/bcm47xx/setup.c |  4 
  drivers/bcma/host_soc.c   | 11 +--
  include/linux/bcma/bcma_soc.h |  1 +
  3 files changed, 14 insertions(+), 2 deletions(-)
 


--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html