Re: [PATCH 14/40] rt2x00: rt2800lib: add MAC register initialization for RT3883

2017-01-14 Thread kbuild test robot 
Hi Gabor,

[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on next-20170113]
[cannot apply to v4.10-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Golle/rt2x00-patches-form-OpenWrt-org/20170115-102250
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: x86_64-allyesdebian (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: the 
linux-review/Daniel-Golle/rt2x00-patches-form-OpenWrt-org/20170115-102250 HEAD 
849367246e2b54e086e272ee2bd32b9983bc30fb builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function 
'rt2800_config_channel_rf3853':
   drivers/net/wireless/ralink/rt2x00/rt2800lib.c:2734:2: error: implicit 
declaration of function 'rt2800_adjust_freq_offset' 
[-Werror=implicit-function-declaration]
 rt2800_adjust_freq_offset(rt2x00dev);
 ^
   drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function 
'rt2800_init_registers':
>> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5027:36: error: 
>> 'TX_TXBF_CFG_0' undeclared (first use in this function)
  rt2800_register_write(rt2x00dev, TX_TXBF_CFG_0, 0x8000fc21);
   ^
   drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5027:36: note: each 
undeclared identifier is reported only once for each function it appears in
>> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5028:36: error: 
>> 'TX_TXBF_CFG_3' undeclared (first use in this function)
  rt2800_register_write(rt2x00dev, TX_TXBF_CFG_3, 0x9c40);
   ^
>> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5224:36: error: 
>> 'TX_FBK_CFG_3S_0' undeclared (first use in this function)
  rt2800_register_write(rt2x00dev, TX_FBK_CFG_3S_0, 0x12111008);
   ^~~
>> drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5225:36: error: 
>> 'TX_FBK_CFG_3S_1' undeclared (first use in this function)
  rt2800_register_write(rt2x00dev, TX_FBK_CFG_3S_1, 0x16151413);
   ^~~
   cc1: some warnings being treated as errors

vim +/TX_TXBF_CFG_0 +5027 drivers/net/wireless/ralink/rt2x00/rt2800lib.c

  50210x);
  5022  }
  5023  } else if (rt2x00_rt(rt2x00dev, RT3883)) {
  5024  rt2800_register_write(rt2x00dev, TX_SW_CFG0, 
0x0402);
  5025  rt2800_register_write(rt2x00dev, TX_SW_CFG1, 
0x);
  5026  rt2800_register_write(rt2x00dev, TX_SW_CFG2, 
0x0004);
> 5027  rt2800_register_write(rt2x00dev, TX_TXBF_CFG_0, 
> 0x8000fc21);
> 5028  rt2800_register_write(rt2x00dev, TX_TXBF_CFG_3, 
> 0x9c40);
  5029  } else if (rt2x00_rt(rt2x00dev, RT5390) ||
  5030 rt2x00_rt(rt2x00dev, RT5392)) {
  5031  rt2800_register_write(rt2x00dev, TX_SW_CFG0, 
0x0404);
  5032  rt2800_register_write(rt2x00dev, TX_SW_CFG1, 
0x00080606);
  5033  rt2800_register_write(rt2x00dev, TX_SW_CFG2, 
0x);
  5034  } else if (rt2x00_rt(rt2x00dev, RT5592)) {
  5035  rt2800_register_write(rt2x00dev, TX_SW_CFG0, 
0x0404);
  5036  rt2800_register_write(rt2x00dev, TX_SW_CFG1, 
0x);
  5037  rt2800_register_write(rt2x00dev, TX_SW_CFG2, 
0x);
  5038  } else {
  5039  rt2800_register_write(rt2x00dev, TX_SW_CFG0, 
0x);
  5040  rt2800_register_write(rt2x00dev, TX_SW_CFG1, 
0x00080606);
  5041  }
  5042  
  5043  rt2800_register_read(rt2x00dev, TX_LINK_CFG, );
  5044  rt2x00_set_field32(, TX_LINK_CFG_REMOTE_MFB_LIFETIME, 32);
  5045  rt2x00_set_field32(, TX_LINK_CFG_MFB_ENABLE, 0);
  5046  rt2x00_set_field32(, TX_LINK_CFG_REMOTE_UMFS_ENABLE, 0);
  5047  rt2x00_set_field32(, TX_LINK_CFG_TX_MRQ_EN, 0);
  5048  rt2x00_set_field32(, TX_LINK_CFG_TX_RDG_EN, 0);
  5049  rt2x00_set_field32(, TX_LINK_CFG_TX_CF_ACK_EN, 1);
  5050  rt2x00_set_field32(, TX_LINK_CFG_REMOTE_MFB, 0);
  5051  rt2x00_set_field32(, TX_LINK_CFG_REMOTE_MFS, 0);
  5052  rt2800_register_write(rt2x00dev, TX_LINK_CFG, reg);
  5053  
  5054  rt2800_register_read(rt2x00dev, TX_TIMEOUT_CFG, );
  5055  rt2x00_set_field32(, TX_TIMEOUT_CFG_MPDU_LIFETIME, 9);
  5056  rt2x00_set_field32(, TX_TIMEOUT_CFG_RX_ACK_TIMEOUT, 32);
  5057  rt2x00_set_field32(, TX_TIMEOUT_CFG_TX_OP_TIMEOUT, 10);
  5058

support for Ampak AP6255 (bcm43455c0 with SDIO device ID 0xa9bf)

2017-01-14 Thread Martin Blumenstingl 
Hello,

I recently got a "Khadas VIM Pro" (see [0] for more information)
The "Pro" version comes with an AP6255 wifi chipset.
Looking at the vendor firmware this seems to be a bcm43455 device: [1]

To my surprise brcmfmac from a mainline 4.10-rc3 kernel did not pick
this device up.
So I started investigating:
$ grep "" 
/sys/class/mmc_host/mmc2/mmc2\:0001/mmc2\:0001\:*/{class,device,vendor}
/sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:1/class:0x00
/sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:2/class:0x00
/sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:3/class:0x02
/sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:1/device:0xa9bf
/sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:2/device:0xa9bf
/sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:3/device:0xa9bf
/sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:1/vendor:0x02d0
/sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:2/vendor:0x02d0
/sys/class/mmc_host/mmc2/mmc2:0001/mmc2:0001:3/vendor:0x02d0

I then went ahead and added the device ID to
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c (sample
patch attached)
as a result of that the device is now being detected.
it boots fine with the firmware found in linux-firmware: [2] (plus the
nvram.txt from the vendor repo [1] renamed to brcmfmac43455-sdio.txt)

$ cat /sys/kernel/debug/brcmfmac/mmc2\:0001\:1/revinfo
vendorid: 0x14e4
deviceid: 0x43ab
radiorev: 0.88.3.11
chipnum: 17221 (4345)
chiprev: 6
chippkg: 2
corerev: 54
boardid: 0x06e4
boardvendor: 0x14e4
boardrev: P304
driverrev: 7.45.18
ucoderev: 0
bus: 0
phytype: 11
phyrev: 20
anarev: 0
nvramrev: 00079ac5

downloading a random 100MB file from the internet using curl confirms this.
There are no hangs, connection drops, other devices are also working fine.

the problem I'm facing is very simply (but unfortunately a very common
development problem): naming things (the SDIO_DEVICE_ID_BROADCOM_TODO
constant)!
there's already a definition for SDIO_DEVICE_ID_BROADCOM_4345 with
value 0x4345, does that mean 0xa9bf should be
SDIO_DEVICE_ID_BROADCOM_43455?


Regards,
Martin


[0] http://khadas.com/vim/
[1] 
https://github.com/khadas/android_hardware_amlogic_wifi/tree/b6709758755568e4a0ff6e80993be0fc64c77fb9/bcm_ampak/config/6255
[2] 
https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/brcm/brcmfmac43455-sdio.bin?id=b9a38d041d38ac6cf47274e9933f8083e12fc601
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 72139b579b18..7206bb1f9908 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -1106,6 +1106,7 @@ static const struct sdio_device_id brcmf_sdmmc_ids[] = {
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4345),
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4354),
 	BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4356),
+	BRCMF_SDIO_DEVICE(0xa9bf),
 	{ /* end: all zeroes */ }
 };
 MODULE_DEVICE_TABLE(sdio, brcmf_sdmmc_ids);

Re: [PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

2017-01-14 Thread kbuild test robot 
Hi Matt,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc3 next-20170113]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Matt-Ranostay/mmc-pwrseq-add-support-for-Marvell-SD8787-chip/20170115-030459
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> make[4]: *** No rule to make target 'drivers/mmc/core/pwrseq_sd8787.c', 
>> needed by 'drivers/mmc/core/pwrseq_sd8787.o'.
   make[4]: Target '__build' not remade because of errors.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] ath10k: Search SMBIOS for OEM board file extension

2017-01-14 Thread kbuild test robot 
Hi Waldemar,

[auto build test WARNING on ath6kl/ath-next]
[also build test WARNING on v4.10-rc3 next-20170113]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Waldemar-Rymarkiewicz/ath10k-Search-SMBIOS-for-OEM-board-file-extension/20170115-005232
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   drivers/net/wireless/ath/ath10k/core.c: In function 
'ath10k_core_check_bdfext':
>> drivers/net/wireless/ath/ath10k/core.c:754:2: warning: ignoring return value 
>> of 'strscpy', declared with attribute warn_unused_result [-Wunused-result]
 strscpy(ar->id.bdf_ext, bdf_ext + strlen(magic),
 ^

vim +/strscpy +754 drivers/net/wireless/ath/ath10k/core.c

   738  
   739  if (memcmp(bdf_ext, magic, strlen(magic)) != 0) {
   740  ath10k_dbg(ar, ATH10K_DBG_BOOT,
   741 "bdf variant magic does not match.\n");
   742  return;
   743  }
   744  
   745  for (i = 0; i < strlen(bdf_ext); i++) {
   746  if (!isascii(bdf_ext[i]) || !isprint(bdf_ext[i])) {
   747  ath10k_dbg(ar, ATH10K_DBG_BOOT,
   748 "bdf variant name contains non ascii 
chars.\n");
   749  return;
   750  }
   751  }
   752  
   753  /* Copy extension name without magic suffix */
 > 754  strscpy(ar->id.bdf_ext, bdf_ext + strlen(magic),
   755  sizeof(ar->id.bdf_ext));
   756  
   757  ath10k_dbg(ar, ATH10K_DBG_BOOT,
   758 "found and validated bdf variant smbios_type 0x%x 
bdf %s\n",
   759 ATH10K_SMBIOS_BDF_EXT_TYPE, bdf_ext);
   760  }
   761  
   762  static int ath10k_core_check_smbios(struct ath10k *ar)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: pull-request: mac80211-next 2017-01-13

2017-01-14 Thread David Miller 
From: Johannes Berg 
Date: Fri, 13 Jan 2017 11:29:32 +0100

> This is my first pull request for net-next, and it seems a bit
> bigger than the past few releases. Detailed information below,
> as usual.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks Johannes.

Re: [PATCH 04/40] rt2x00: rt2800lib: fix beacon generation on RT3593

2017-01-14 Thread Kalle Valo 
Daniel Golle  writes:

> From: Gabor Juhos 
>
> On the RT3593 chipset, the beacon registers are located
> in the high 8KB part of the shared memory.
>
> The high part of the shared memory is only accessible
> if it is explicitly selected. Add a helper function
> in order to be able to control the SHR_MSEL bit in
> the PBF_SYS_CTRL register. Also add a few more helper
> functions and use those to select the correct part of
> the shared memory before and after accessing the beacon
> registers.
>
> The base addresses of the beacon registers are also
> different from the actually used values, so fix the
> 'rt2800_hw_beacon_base' function to return the correct
> values.
>
> Signed-off-by: Gabor Juhos 

Daniel, as you are submitting these patches you should add your
Signed-off-by after the author's line. Documentation/SubmittingPatches
contains more info about that and what Signed-off-by means. And also
take a look at how Luca does it:

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

-- 
Kalle Valo

Re: [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

2017-01-14 Thread Kalle Valo 
Stanislaw Gruszka  writes:

> Hi
>
> On Fri, Jan 13, 2017 at 04:50:32AM +0100, Daniel Golle wrote:
>> Please review and comment, so we can get those patches merged!
>
> As already pointed by Kalle posting patches to mailing list is better
> way for review. Posing patches is easy with git-format-patch and
> git-send-email. Ideally patch series should not be long, let say no more
> than 30 patches - I suggest to split this into two series: second one
> for RT3853 support and first one for other patches.

Even 30 patches in a set is quite a lot. I think the pain point is
somewhere about 10-12 patches, anything longer than that and most people
lost interest looking at the patches in detail.

-- 
Kalle Valo

Re: linux driver bcm4311 failure

2017-01-14 Thread Arend Van Spriel 
On 14-1-2017 11:15, message wrote:
> On 2017-01-02 20:04, Arend van Spriel wrote:
>> On 02-01-17 15:33, message wrote:
>>> On 2016-12-30 19:46, message wrote:
 On 2016-09-17 08:11, message wrote:
> On 2016-09-09 07:57, Arend Van Spriel wrote:
>>
>> The device is claimed by b43-pci-bridge so I would suggest:
>>
>> blacklist b43-pci-bridge
>>
>>>
>>> The wifi card indicator now appears to start after computer switch on
>>> (twice in a row now!)
>>>
>>> Neither networkmanager or wicd are accepting the password.
>>>
>>> Even:
>>>
>>> wicd-cli --wireless -c [wifihotspotname]
>>> done!
>>>
>>> is false and internet access not found.
>>>
>>> wpa_supplicant continues to report 'conn_failed' error.
>>>
>>> Connection to same network is successful using debian on chromebook
>>> (crouton)
>>
>> I am confused by all your messages. In the previous one you did a
>> 'modprobe b43'. So what driver do you intend to use here. b43 is not a
>> driver maintained by broadcom. You should ask for help on the b43
>> mailing list [1] if you want to use that driver.
>>
>> Regards,
>> Arend
>>
>> [1] http://lists.infradead.org/mailman/listinfo/b43-dev
> 
> After system upgrade, wifi card fails to be recognised.
> 
> For the benefit of other users: save your time and avoid broadcom
> products; they are terrible.

Why sending these types of messages hiding in anonymity without
responding to any of the questions in my email responses. Again what
driver are you using. If it is b43 you want you should not blacklist
b43-pci-bridge. Whether or not b43 supports your device can be found
here [2]. Supposedly it is. If not you might try your luck at the b43
mailing list I gave you in earlier email.

Regards,
Arend

[2] https://wireless.wiki.kernel.org/en/users/drivers/b43#list_of_hardware