On 18-06-16 20:18, Rafał Miłecki wrote:
> So far when receiving event about in-firmware-interface removal we were
> notifying our listener and afterwards we were removing Linux interface.
>
[snip]
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
> b/drivers/net/wireless
On 17-06-16 14:30, Rafał Miłecki wrote:
> On 1 June 2016 at 21:00, Arend van Spriel
> wrote:
>> On 01-06-16 16:36, Rafał Miłecki wrote:
>>> We already support adding extra (AP) interfaces so it also makes an
>>> obvious sense to allow deleting them.
>>>
&g
On 14-06-16 13:44, Jakub Kicinski wrote:
> C bitfields are problematic and best avoided. Developers
> interacting with hardware registers find themselves searching
> for easy-to-use alternatives. Common approach is to define
> structures or sets of macros containing mask and shift pair.
> Operati
On 09-06-16 21:16, Arend van Spriel wrote:
> On 26-05-16 01:44, Rafał Miłecki wrote:
>> The old implementation was overcomplicated and slightly bugged in some
>> corner cases.
>>
[...]
>> New code is simpler, placed in file where it's really used, handles
&
On 26-05-16 01:44, Rafał Miłecki wrote:
> The old implementation was overcomplicated and slightly bugged in some
> corner cases.
>
> Consider following state of BSS-es (limited to 6 for simplification):
> drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, }
> drvr->iflist[1]: (null)
> drvr->iflist
nels
>before preparing limits).
> 3) It modifies mbss code to use i variable just like other combos do.
Acked-by: Arend van Spriel
> Signed-off-by: Rafał Miłecki
> ---
> .../broadcom/brcm80211/brcmfmac/cfg80211.c | 37
> ++
> 1 file changed,
On 31-5-2016 13:46, Grey Christoforo wrote:
> Hi,
>
> I found the following in my dmesg today when I tried out 4.7-rc1 on my
> Dell XPS15 9550. My WiFi doesn't work.
>
> Relevant bits of my lsusb & lspci are:
>
> $ lsusb
> ...
> Bus 001 Device 002: ID 0a5c:6410 Broadcom Corp.
> ...
> $ lspci
> .
On 01-06-16 16:36, Rafał Miłecki wrote:
> We already support adding extra (AP) interfaces so it also makes an
> obvious sense to allow deleting them.
>
> Adding a new interface is implemented by sending request to firmware for
> creating a new BSS and waiting for a proper event. Ideally deleting
>
On 01-06-16 11:01, Arend Van Spriel wrote:
>
>
> On 31-5-2016 22:58, Ard Biesheuvel wrote:
>> On 31 May 2016 at 22:24, Dmitry Shmidt wrote:
>>> On Mon, May 30, 2016 at 4:30 AM, Ard Biesheuvel
>>> wrote:
>>>> This is likely caused by the fact that t
?
For the module I noticed it uses command line parameter -mcmodel=large
so I suppose that could be how I ended up with PREL32.
In arch/arm64/Makefile there is this:
ifeq ($(CONFIG_ARM64_ERRATUM_843419), y)
KBUILD_CFLAGS_MODULE += -mcmodel=large
endif
And that Kconfig item is indeed set.
ile command line twice. To no avail so that ain't
working.
Regards,
Arend
>> On 30 mei 2016, at 12:21, Arend Van Spriel
>> wrote:
>>
>> I got myself an arm64 HiKey board from LeMaker and build an Android AOSP
>> image for it (see [1]). For development I would li
I got myself an arm64 HiKey board from LeMaker and build an Android AOSP
image for it (see [1]). For development I would like to use
CONFIG_MODULES. However, when I try to insmod the build module I get:
[ 287.903653] module cfg80211: overflow in relocation type 261 val
ffbffc006530
Looking A
On 26-5-2016 0:44, Rafał Miłecki wrote:
> This is helpful for debugging, without this all I was getting from "iw"
> command on device with BCM43602 was:
>> command failed: Too many open files in system (-23)
>
> Signed-off-by: Rafał Miłecki
> ---
> V2: s/in/if/ in commit message
> V3: Add one mor
On 24-05-16 11:09, Rafał Miłecki wrote:
> Firmware for new chipsets is based on a new major version of code
> internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for
> BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was
> based on 7.35.177.56.
>
> Currently
On 24-05-16 23:05, Rafał Miłecki wrote:
> This is helpful for debugging, without this all I was getting from "iw"
> command on device with BCM43602 was:
>> command failed: Too many open files in system (-23)
>
> Signed-off-by: Rafał Miłecki
> ---
> V2: s/in/if/ in commit message
> ---
> drivers/
On 19-5-2016 15:59, Muhammad Falak R Wani wrote:
> Use kmemdup when some other buffer is immediately copied into allocated
> region. It replaces call to allocation followed by memcpy, by a single
> call to kmemdup.
Acked-by: Arend van Spriel
> Signed-off-by: Muhammad
r control channel.
The need to "access all info" is probably the other patch so you might
hint here that this change is needed for the .get_channel() callback.
Reviewed-by: Arend van Spriel
> Signed-off-by: Rafał Miłecki
> ---
> .../broadcom/brcm80211/brcmfmac/cfg80211.c
On 19-5-2016 13:02, Rafał Miłecki wrote:
> This is important for brcmfmac as the firmware may pick different
> channel than requested. This has been tested with BCM4366B1 (in D-Link
> DIR-885L).
Can you elaborate? Is this for AP or STA mode?
> Signed-off-by: Rafał Miłecki
> ---
> .../broadcom/b
On 18-5-2016 2:57, Heinrich Schuchardt wrote:
> Simplify assignment in wlc_phy_rxcal_gainctrl_nphy_rev5.
Acked-by: Arend van Spriel
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 2 +-
> 1 file changed, 1 insertion
On 12-05-16 11:34, Wei-Ning Huang wrote:
> On Thu, May 12, 2016 at 2:33 AM, Dan Williams wrote:
>> On Wed, 2016-05-11 at 13:03 +0800, Wei-Ning Huang wrote:
>>> On Fri, May 6, 2016 at 4:19 PM, Wei-Ning Huang
>>> wrote:
On Fri, May 6, 2016 at 12:07 AM, Dan Williams
wrote:
>
On 13-4-2016 10:38, Johannes Berg wrote:
>
>> The patch was build-tested / debugged by removing the
>> "if VERBOSE > SHOW_ERROR_MESSAGES" guards.
>
> Stands to reason that we should just remove the (more or less) dead
> code, since I don't think anyone really ever touches this driver any
> more o
On 12-04-16 13:46, Sudip Mukherjee wrote:
> From: Sudip Mukherjee
>
> We have a check for card just after dereferencing it. So if it is NULL
> we have already dereferenced it before its check. Lets dereference it
> after checking card for NULL.
And you are changing the scope of the pdev variab
On 29-03-16 16:02, Al Viro wrote:
> On Tue, Mar 29, 2016 at 01:11:55PM +0200, Arend Van Spriel wrote:
>> Hi Al,
>>
>> Moved to 4.6-rc1 and found NFS mounts were failing moving to the new
>> kernel. The NFS mounts are done using autofs. Below is the bisect log
>>
On 26-01-16 00:41, Julian Calaby wrote:
> Hi Arend,
>
> On Tue, Jan 26, 2016 at 2:39 AM, Arend van Spriel wrote:
>> On 25-01-16 12:06, Julian Calaby wrote:
>>> Hi Sjoerd,
>>>
>>> On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons
>>> wrote:
>&g
On 25-1-2016 20:23, Doug Anderson wrote:
> Hi,
>
> On Mon, Jan 25, 2016 at 7:36 AM, Arend van Spriel wrote:
>> On 25-01-16 11:47, Sjoerd Simons wrote:
>>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
>>> the card responds very quickl
On 25-01-16 12:06, Julian Calaby wrote:
> Hi Sjoerd,
>
> On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons
> wrote:
>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
>> the card responds very quickly most of the time, unfortunately during
>> initialisation it sometimes seem
I guess we need this fix for
now so...
Acked-by: Arend van Spriel
> Signed-off-by: Sjoerd Simons
>
> ---
Still would like to know whether it is firmware initialization or some
mmc stack procedure. Any suggestions to debug this are welcome.
Regards,
Arend
---
>
> drivers/net/wir
On 03-01-16 16:18, Rafał Miłecki wrote:
> On 3 January 2016 at 10:36, Arend van Spriel wrote:
>> On 02-01-16 12:21, SF Markus Elfring wrote:
>>>> Did you look at the resulting assembly code for different target
>>>> architectures?
>>>
>>> N
On 02-01-16 12:21, SF Markus Elfring wrote:
>> I have never seen much evolution going on in this area.
>
> I can get an other impression from a specific document for example.
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/Documentation/CodingStyle
>
>
>> What the patch
On 02-01-16 10:08, SF Markus Elfring wrote:
>>> I assume that a software development taste can evolve, can't it?
>>
>> So far, you have gotten several down votes for this kind of change,
>
> I am curious when more contributors will share corresponding opinions.
Let's burn some cycles on this wh
ginning for one local variable
that is redefined before its first use.
That being said here is my....
Acked-by: Arend van Spriel
Signed-off-by: Markus Elfring
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
On 12/02/2015 12:45 PM, Colin King wrote:
From: Colin Ian King
There is a null ptr check for fws to set bcmc_credit_check, however,
there a lock and unlock on fws should only performed if fwts is
also not null to also avoid a potential null pointer deference.
Acked-by: Arend van Spriel
On 11/23/2015 11:28 AM, Arend van Spriel wrote:
On 11/22/2015 06:23 PM, Kalle Valo wrote:
Arend van Spriel writes:
On 11/19/2015 08:48 AM, Kalle Valo wrote:
Hauke Mehrtens writes:
On 11/18/2015 03:45 PM, Kalle Valo wrote:
Part of reorganising wireless drivers directory and Kconfig. Note
On 11/22/2015 06:23 PM, Kalle Valo wrote:
Arend van Spriel writes:
On 11/19/2015 08:48 AM, Kalle Valo wrote:
Hauke Mehrtens 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
On 11/19/2015 08:48 AM, Kalle Valo wrote:
Hauke Mehrtens 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
---
I would pref
On 11/19/2015 08:54 AM, Kalle Valo wrote:
Florian Fainelli writes:
On 18/11/15 11:19, Hauke Mehrtens wrote:
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.
S
On 11/14/2015 05:22 PM, Julia Lawall wrote:
The brcmf_bus_ops structures are never modified, so declare them as const.
Done with the help of Coccinelle.
Acked-by: Arend van Spriel
Signed-off-by: Julia Lawall
---
drivers/net/wireless/brcm80211/brcmfmac/bus.h |2 +-
drivers/net
Coccinelle software.
Acked-by: Arend van Spriel
Signed-off-by: Markus Elfring
---
drivers/net/wireless/brcm80211/brcmfmac/firmware.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/firmware.c
b/drivers/net/wireless/brcm80211/brcmfmac
On 10/16/2015 09:35 PM, Luis R. Rodriguez wrote:
On Thu, Sep 03, 2015 at 10:33:51AM -0700, Dmitry Torokhov wrote:
On Thu, Sep 3, 2015 at 10:23 AM, Arend van Spriel wrote:
On 09/03/2015 01:46 AM, Luis R. Rodriguez wrote:
On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov
wrote:
On Wed, Sep 2
On 10/09/2015 02:35 AM, Kosuke Tatsukawa wrote:
> brcmf_msgbuf_ioctl_resp_wake() seems to be missing a memory barrier
> which might cause the waker to not notice the waiter and miss sending a
> wake_up as in the following figure.
>
>brcmf_msgbuf_ioctl_resp_wake brcmf_msgbuf_i
On 10/09/2015 02:35 AM, Kosuke Tatsukawa wrote:
> brcmf_msgbuf_ioctl_resp_wake() seems to be missing a memory barrier
> which might cause the waker to not notice the waiter and miss sending a
> wake_up as in the following figure.
My mail reader treats this as HTML format or so. Can you resend it i
Hi Nick,
On 10/06/2015 04:36 AM, Nicholas Krause wrote:
This fixes error handling in the function brcmf_sdio_htclk to
properly check if the call to the function brcmf_sdio_regrb
fails in the else if condition where the clkstate is in the
CLK_PENDING state in order to avoid incorrect execution of
On 10/03/2015 06:24 AM, Nicholas Krause wrote:
This uses the proper skb wrapper function sk_unlink in the function
brcmf_sdio_txpkt_postp to properly protect against concurrent users
accessing this skb_buff pointer or skb_buff_head pointer by locking
the spinlock as part of the passed skb_buff_he
On 10/03/2015 06:19 PM, Nicholas Krause wrote:
This fixes the locking region in the function brcmf_sdio_sendfromq
to properly lock around the call to the function brcmrf_sdio_txpkt
in order to avoid concurrent access issues when calling this
function as stated in the function's comments about the
On 09/03/2015 01:46 AM, Luis R. Rodriguez wrote:
On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov
wrote:
On Wed, Sep 2, 2015 at 4:22 PM, Luis R. Rodriguez wrote:
On Wed, Sep 02, 2015 at 04:13:51PM -0700, Dmitry Torokhov wrote:
On Wed, Sep 2, 2015 at 2:03 PM, Arend van Spriel wrote:
Ok. So
On 09/02/2015 08:58 PM, Luis R. Rodriguez wrote:
On Wed, Sep 02, 2015 at 02:13:49PM +0200, Arend van Spriel wrote:
On 09/02/2015 02:09 PM, Arend van Spriel wrote:
On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote:
On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote:
On Sun, Aug 30, 2015
On 09/02/2015 02:09 PM, Arend van Spriel wrote:
On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote:
On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote:
On Sun, Aug 30, 2015 at 4:25 PM, Arend van Spriel
wrote:
Does this mean a built-in driver can not get firmware from initramfs or
built in
On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote:
On Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote:
On Sun, Aug 30, 2015 at 4:25 PM, Arend van Spriel wrote:
Does this mean a built-in driver can not get firmware from initramfs or
built in the kernel early. Seems a bit too aggressive
On 08/29/2015 12:38 PM, Ming Lei wrote:
On Sat, 29 Aug 2015 10:50:22 +0200
Arend van Spriel wrote:
On 08/29/2015 09:11 AM, Takashi Iwai wrote:
On Sat, 29 Aug 2015 06:09:01 +0200,
Ming Lei wrote:
On Sat, Aug 29, 2015 at 9:11 AM, Luis R. Rodriguez wrote:
On Thu, Aug 27, 2015 at 08:55:13AM
On 08/29/2015 09:11 AM, Takashi Iwai wrote:
On Sat, 29 Aug 2015 06:09:01 +0200,
Ming Lei wrote:
On Sat, Aug 29, 2015 at 9:11 AM, Luis R. Rodriguez wrote:
On Thu, Aug 27, 2015 at 08:55:13AM +0800, Ming Lei wrote:
On Thu, Aug 27, 2015 at 2:07 AM, Linus Torvalds
wrote:
On Wed, Aug 26, 2015 at
On 08/26/2015 10:23 PM, Arend van Spriel wrote:
On 08/26/2015 12:22 PM, Thierry Reding wrote:
From: Thierry Reding
The rate_control_cap_mask() function takes a parameter mcs_mask, which
GCC will take to be u8 * even though it was declared with a fixed size.
This causes the following warning
On 08/26/2015 12:22 PM, Thierry Reding wrote:
From: Thierry Reding
The rate_control_cap_mask() function takes a parameter mcs_mask, which
GCC will take to be u8 * even though it was declared with a fixed size.
This causes the following warning:
net/mac80211/rate.c: In function 'rate_co
On 08/20/2015 11:46 PM, Murali Karicheri wrote:
All,
Please help me understand the procedure to add a firmware ihex file to
kernel source tree under firmware/ folder. The README.AddingFirmware
file explains that file should be added to
git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux
On 08/17/2015 09:28 PM, Raphaël Beamonte wrote:
The MACRO_WILC_BUFFER() macro was using a return statement, and didn't
Probable MACRO_WILC_BUFFER should be MALLOC_WILC_BUFFER here.
take care of possible memory leaks and subsequent bugs when it was failing
after succeeding some allocations. Th
+ Rafael
On 08/17/2015 09:29 AM, Johannes Berg wrote:
On Mon, 2015-08-17 at 09:48 +0800, Fu, Zhonghui wrote:
The suspend/resume timing of wiphy device and related devices will be
ensured by their parent/child relationship. So, enabling wiphy device
to suspend/resume asynchronously does not cha
bit arches.
Assuming LP64 programming model for linux on say x86_64: atomic_or()
callers in this driver use long (sana 64 bit) storage and pass it to
atomic_orr/atomic_or which downcasts it to 32 bits. Is that OK ?
---
Cc: Brett Rudley
Cc: Arend van Spriel
Cc: "Franky (Zhenhui) Lin"
Cc
On 07/10/2015 06:49 AM, Vineet Gupta wrote:
On Thursday 09 July 2015 11:55 PM, Arend van Spriel wrote:
On 07/09/2015 10:13 AM, Vineet Gupta wrote:
There's already a generic implementation so use that instead.
There is or there was? If there is now I am fine with this patch, but if
it al
: Arend van Spriel
Signed-off-by: Christophe JAILLET
---
v2: fix the subject
drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/mac80211_if.c
b/drivers/net/wireless/brcm80211
On 07/09/2015 08:25 PM, Arend van Spriel wrote:
On 07/09/2015 10:13 AM, Vineet Gupta wrote:
There's already a generic implementation so use that instead.
There is or there was? If there is now I am fine with this patch, but if
it already was there the author might have had a reason for a
c_or which downcasts it to 32 bits. Is that OK ?
The function is used with 32bit register value from the device so I
think it is ok.
Regards,
Arend
---
Cc: Brett Rudley
Cc: Arend van Spriel
Cc: "Franky (Zhenhui) Lin"
Cc: Hante Meuleman
Cc: Kalle Valo
Cc: Pieter-Paul Giesberts
Cc: D
+ Marcel, wireless list, and bt list.
On 06/05/15 07:12, Jonas Thiem wrote:
Hi Jeremiah,
thanks for responding!
I did have my mobile phone very nearby also connected to the bluetooth
headphones while my laptop was still using 11n wifi. I didn't have any
noticeable issues with bluetooth there.
26 for today.
Crap. struct acpi_device details are only known when CONFIG_ACPI is set.
The attached patch should fix the issue.
Regards,
Arend
>From fd56b4446c613ceec15c11758ed817d13efb9bba Mon Sep 17 00:00:00 2001
From: Arend van Spriel
Date: Wed, 27 May 2015 10:48:46 +0200
Subject: [PATCH]
On 05/22/15 09:37, Arend van Spriel wrote:
On 05/22/15 02:21, Laura Abbott wrote:
On 05/21/2015 08:26 AM, Alan Stern wrote:
On Thu, 21 May 2015, Marcel Holtmann wrote:
Hi Alan,
Then avoiding the failed firmware is no solution, indeed.
If it's a new probe, it should be never executed d
On 05/22/15 02:21, Laura Abbott wrote:
On 05/21/2015 08:26 AM, Alan Stern wrote:
On Thu, 21 May 2015, Marcel Holtmann wrote:
Hi Alan,
Then avoiding the failed firmware is no solution, indeed.
If it's a new probe, it should be never executed during resume.
Can you expand this comment? What'
On 05/21/15 19:32, Takashi Iwai wrote:
At Thu, 21 May 2015 19:27:41 +0200,
Arend van Spriel wrote:
On 05/21/15 17:35, Takashi Iwai wrote:
At Thu, 21 May 2015 11:26:17 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 10:18:08 -0400 (EDT),
Alan
On 05/21/15 17:35, Takashi Iwai wrote:
At Thu, 21 May 2015 11:26:17 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 10:18:08 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
Then avoiding the failed firmware is no solution
uring suspend/resume
process on some tablet platforms(such as ASUS T100TA). This is
not supported by brcmfmac driver now, and the context of WiFi
chip will be damaged after resume. This patch informs ACPI not
to manage WiFi chip's power state.
Signed-off-by: Zhonghui Fu
Acked-by: Arend van Spriel
-
On 05/14/15 19:56, Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez"
Firmware licenses on linux-firmware should include an implicit
or explicit patent grant to end users for full device operation
otherwise it would start making linux-firmware useless for many
Linux distributions which have posi
On 05/13/15 21:19, Jonas Gorski wrote:
Hi Arend,
On Wed, May 13, 2015 at 8:43 PM, Arend van Spriel wrote:
For our upstream brcm80211 drivers we build for a number of architectures
including MIPS. In recent builds we get an error/warning:
CC [M] drivers/net/wireless/brcm80211/brcmfmac
For our upstream brcm80211 drivers we build for a number of
architectures including MIPS. In recent builds we get an error/warning:
CC [M] drivers/net/wireless/brcm80211/brcmfmac/cfg80211.o
In file included from ./arch/mips/include/asm/io.h:27:0,
from ./arch/mips/include/asm/
ading the
code wonder whether a mistake has been made. So I would prefer to have
the assignment separate for the if statement.
For the update patch you may add:
Acked-by: Arend van Spriel
Regards,
Arend
+ adev->flags.power_manageable = 0;
+
/* Consume f
On 04/27/15 07:00, Fu, Zhonghui wrote:
ACPI will manage WiFi chip's power state during suspend/resume
process on some tablet platforms(such as ASUS T100TA). This is
not supported by brcmfmac driver now, and the context of WiFi
chip will be damaged after resume. This patch disconnects the
relation
On 04/27/15 07:06, Fu, Zhonghui wrote:
Need to keep the power supply for WiFi chip during system suspension.
Otherwise, the context of WiFi chip will be lost.
I already submitted a patch doing exactly the same thing [1]
Regards,
Arend
[1] https://patchwork.kernel.org/patch/6217391/
Signed-o
On 04/24/15 21:03, Arend van Spriel wrote:
On 04/24/15 20:24, John Tobias wrote:
Hi Arend,
Apologize for the confusion. I am asking the repo for the device
driver for 43340. Looking at the link you sent, it's more userspace
support and didn't see the device driver there...
cra
You need a kernel
repo. There are some on the site I referred to, but you may need to
contact Freescale whether they provide it publicly like on github or so.
Regards,
Arend
Regards,
John
On Fri, Apr 24, 2015 at 11:14 AM, Arend van Spriel wrote:
On 04/24/15 19:49, John Tobias wrote:
Hi
your device.
Regards,
Arend
Regards,
John
On Fri, Apr 24, 2015 at 1:20 AM, Arend van Spriel wrote:
On 04/24/15 03:04, John Tobias wrote:
Btw, where I could get a copy of the latest driver?.
The open-source bcmdhd is in AOSP [1]. I would stick to the android release
branch you are
On 04/24/15 02:57, John Stultz wrote:
On Thu, Apr 23, 2015 at 12:00 PM, Arend van Spriel wrote:
By the name of the file I suspected you did. Personally, I verified the
firmware works on 43341. John Stultz tested both 43340 and 43341 with this
firmware.
Minor correction here, I only tested on
/
Regards,
John
On Thu, Apr 23, 2015 at 5:59 PM, John Tobias wrote:
Hi John,
Is it possible to have a copy of the firmware for 43340?.
Regards,
John
On Thu, Apr 23, 2015 at 5:57 PM, John Stultz wrote:
On Thu, Apr 23, 2015 at 12:00 PM, Arend van Spriel wrote:
By the name of the file I
log says: chip:0xa94c rev:0x2
I will have to check whether that is correct revision for this firmware.
I can check. You could try the brcmfmac4334-sdio.bin file instead. All
bets are off, but it can not get worse. ;-)
Gr. AvS
Regards,
John
On Thu, Apr 23, 2015 at 11:39 AM, Arend van Spr
On 04/23/15 20:10, John Tobias wrote:
Hello Guys,
I am trying to use the bcmdhd wifi driver 43340 module on iMX6DL
processor using kernel Freescale GA (3.10.53).
I am having an issue with the sdio registration. I would like to know
if anyone here had the same issue and how did you solve it?.
On 04/21/15 01:30, Luis R. Rodriguez wrote:
Suspect the subject line is screwed up here and should have been "[PATCH
v1 1/6] ".
Regards,
Arend
Most code already uses consts for the struct kernel_param_ops,
sweep the kernel for the last offending stragglers. Other than
include/linux/modul
#undef TRACE_SYSTEM
#define TRACE_SYSTEM brcmsmac_msg
Unfortunately, this broke new code in the ftrace infrastructure.
Moving each of these TRACE_SYSTEMs into their own trace file with
just one TRACE_SYSTEM per file fixes the issue.
Cc: Arend van Spriel
All right. Go ahead and change Cc: into
On 03/29/15 15:43, Michael S. Tsirkin wrote:
This file does not use any pci ids, drop
pci_ids.h include.
Acked-by: Arend van Spriel
Signed-off-by: Michael S. Tsirkin
---
drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless
On 03/29/15 15:43, Michael S. Tsirkin wrote:
This file does not use any pci APIs, drop
pci header includes.
Acked-by: Arend van Spriel
Signed-off-by: Michael S. Tsirkin
---
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net
On 03/29/15 15:41, Michael S. Tsirkin wrote:
Header moved from linux/pci_ids.h to uapi/linux/pci_ids.h,
use the new header directly so we can drop
the wrapper in include/linux/pci_ids.h.
Acked-by: Arend van Spriel
Signed-off-by: Michael S. Tsirkin
---
drivers/net/wireless/brcm80211/include
Patch was compile tested with x86_64_defconfig + CONFIG_BRCMFMAC=m
Patch is agianst 4.0-rc4 (localversion-next is -next-20150317)
It applies to wireless-drivers-next/master as well so
Acked-by: Arend van Spriel
Signed-off-by: Nicholas Mc Guire
---
drivers/net/wireless/brcm80211/brcmfmac/
On 03/02/15 16:08, Kalle Valo wrote:
Arend van Spriel writes:
Now that there is not 3.20 version. My understanding is that this
patch will be in linus' tree 4.1-rc1, right?
Yes. It will go into linux-next first, which you can consider to be an
incubator where all stuff for the next re
On 02/27/15 08:53, Fu, Zhonghui wrote:
On 2015/2/16 17:35, Arend van Spriel wrote:
On 02/16/15 08:34, Fu, Zhonghui wrote:
On 2015/2/15 22:54, Kalle Valo wrote:
Arend van Spriel writes:
On 02/15/15 04:27, Pat Erley wrote:
On 02/14/2015 08:40 PM, Fu, Zhonghui wrote:
Any comments to this
On 02/23/15 04:06, Linus Torvalds wrote:
On the other hand, the strongest argument for some people advocating
4.0 seems to have been a wish to see 4.1.15 - because "that was the
version of Linux skynet used for the T-800 terminator".
So they have changed our future already as we will likely hit
On 02/16/15 22:47, Adrian Hunter wrote:
On 16/02/2015 7:47 p.m., Philip Rakity wrote:
On Feb 16, 2015, at 5:39 PM, Arend van Spriel wrote:
On 02/16/15 15:25, Adrian Hunter wrote:
I am in the process of adding an ACPI Device Property to specify
the driver strength (aka drive strength
On 02/16/15 15:25, Adrian Hunter wrote:
I am in the process of adding an ACPI Device Property to specify
the driver strength (aka drive strength, driver type) for use
with eMMC/SD/SDIO cards, however the ACPI Specification Workgroup
requires that Device Properties be sufficiently generic. This
ra
On 02/16/15 08:34, Fu, Zhonghui wrote:
On 2015/2/15 22:54, Kalle Valo wrote:
Arend van Spriel writes:
On 02/15/15 04:27, Pat Erley wrote:
On 02/14/2015 08:40 PM, Fu, Zhonghui wrote:
Any comments to this patch? Can it be accepted?
I assume that patches are queued up until after the merge
do
the same things. This patch avoid this case.
Acked-by: Arend van Spriel
Signed-off-by: Fu Zhonghui
---
Changes in v3:
- Rebase to wireless-drivers-next/master branch
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff
On 02/06/15 11:26, Nicholas Mc Guire wrote:
This is only an API consolidation and should make things more readable
it replaces var * HZ / 1000 by msecs_to_jiffies(var).
Acked-by: Arend van Spriel
Signed-off-by: Nicholas Mc Guire
---
Patch was only compile tested with x86_64_defconfig
,
Arend
Acked-by: Arend van Spriel
Signed-off-by: Zhonghui Fu
---
Changes in v2:
- Remove two "Acked-by" lines
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfma
ations for one WiFi chip to do
the same things. This patch avoid this case.
Acked-by: Arend van Spriel
Signed-off-by: Zhonghui Fu
---
And when using version info a change log here is even better. Although
admittedly I lost track which version this would be ;-)
Regards,
Arend
---
drivers/ne
On 01/28/15 11:10, Javier Martinez Canillas wrote:
The Snow board has a MMC/SDIO wifi chip that is always powered but it
needs a power sequence involving a reset (active low) and an enable
(active high) pins. Both pins are marked as active low since the MMC
simple power sequence driver asserts th
On 01/27/15 18:38, Alexander Holler wrote:
Am 27.01.2015 um 18:24 schrieb Steven Rostedt:
For most people a message in dmesg is not very useful. What you are
asking for
is to print a characteristic of a device. Something that someone might
want to
check much later in boot, where, as Boris state
On 01/27/15 12:48, Alexander Holler wrote:
It's an interesting detail, so inform the user about it.
Signed-off-by: Alexander Holler
---
drivers/mmc/core/bus.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 8a1f124..4a60028 100644
On 01/23/15 16:29, Kalle Valo wrote:
Arend van Spriel writes:
On 01/22/15 14:54, Sergei Shtylyov wrote:
Hello.
On 1/22/2015 4:49 PM, Kalle Valo wrote:
> From 04d3fa673897ca4ccbea6c76836d0092dba2484a Mon Sep 17 00:00:00 2001
From: Zhonghui Fu
Date: Tue, 20 Jan 2015 11:14:13 +0800
Subj
201 - 300 of 545 matches
Mail list logo
