Re: NAPI: Polling function requesting extra calls - difference between 3.18.11 and 4.0.0

On 23 April 2015 at 20:33, Eric Dumazet eric.duma...@gmail.com wrote: On Thu, 2015-04-23 at 11:28 -0700, Eric Dumazet wrote: On Thu, 2015-04-23 at 20:18 +0200, Rafał Miłecki wrote: Can you help us with this, please? Does bgmac use NAPI incorrectly? Were there some important changes

NAPI: Polling function requesting extra calls - difference between 3.18.11 and 4.0.0

Hi, Recently Felix improved bgmac driver to be smarter in situation where new packets were Tx/Rx-ed during bgmac_poll execution. It was handled in: eb64e29 bgmac: leave interrupts disabled as long as there is work to do

[PATCH][FIX 4.1] bgmac: fix requests for extra polling calls from NAPI

After d75b1ade567f (net: less interrupt masking in NAPI) polling function has to return whole budget when it wants NAPI to call it again. Signed-off-by: Rafał Miłecki zaj...@gmail.com Cc: Felix Fietkau n...@openwrt.org Fixes: eb64e2923a886 (bgmac: leave interrupts disabled as long

Re: NAPI: Polling function requesting extra calls - difference between 3.18.11 and 4.0.0

On 23 April 2015 at 20:28, Eric Dumazet eric.duma...@gmail.com wrote: On Thu, 2015-04-23 at 20:18 +0200, Rafał Miłecki wrote: Can you help us with this, please? Does bgmac use NAPI incorrectly? Were there some important changes in 3.19 or 4.0? Right they were important changes in NAPI

Re: [RFC PATCH] bgmac: Fix build error seen if BCM47XX is not configured

: implicit declaration of function 'bcm47xx_nvram_getenv' Fixes: fc300dc3733f (bgmac: allow enabling on ARCH_BCM_5301X) Cc: Rafał Miłecki zaj...@gmail.com Signed-off-by: Guenter Roeck li...@roeck-us.net --- Seen in today's upstream kernel. I don't like this fix too much (I think

Re: [PATCH net-next 0/5] net: phy: broadcom: define pseudo-PHY address

On 11 June 2015 at 03:07, Florian Fainelli f.faine...@gmail.com wrote: This patch series converts existing in-tree users of the Broadcom pseudo-PHY address (30) used to configure MDIO-connected switches to share a constant in a shared header files. Looks OK, thanks. -- Rafał -- To

Re: [PATCH] Logically DeadCode

On 3 July 2015 at 06:52, Rahul Jain rahul.j...@samsung.com wrote: From 0c34030166a150d6d9f1ab52e7bb40a5440a68c2 Mon Sep 17 00:00:00 2001 From: Rahul Jain rahul.j...@samsung.com Date: Fri, 3 Jul 2015 10:19:12 +0530 Subject: [PATCH] Logically DeadCode You didn't use any prefix for the commit

Re: [PATCH 3/3] net: wireless: b43: statics Don't init to 0

On 18 October 2015 at 01:01, Paul McQuade wrote: > Don't turn statics to 0 or NULL Same request as Michael's in 2/3. Your "statics Don't init to 0" message sounds strange, statics *are* initialized to 0 by default (as you probably know but described it in a unclear way). --

[PATCH] bgmac: support up to 3 cores (devices) on a bus

interfaces are for some kind of offloading). Signed-off-by: Rafał Miłecki zaj...@gmail.com --- drivers/net/ethernet/broadcom/bgmac.c | 28 +++- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom

Re: net-libertas: Better exception handling in if_spi_host_to_card_worker()

On 4 January 2016 at 11:05, Arend van Spriel <aspr...@gmail.com> wrote: > On 03-01-16 16:18, Rafał Miłecki wrote: >> On 3 January 2016 at 10:36, Arend van Spriel <aspr...@gmail.com> wrote: >>> On 02-01-16 12:21, SF Markus Elfring wrote: >>>>>

Re: net-libertas: Better exception handling in if_spi_host_to_card_worker()

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? >> >> Not yet. - Which execution system variants would you recommend for >> further

[PATCH] brcmfmac: include required headers in cfg80211.h

; ^ drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h:317:28: error: field ‘assoclist’ has incomplete type struct brcmf_assoclist_le assoclist; Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h | 3 +++ 1 file chan

[PATCH] brcmfmac: slightly simplify building interface combinations

combos do. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 37 ++ 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/br

[PATCH] brcmfmac: drop unused pm_block vif attribute

This attribute was added 3 years ago by commit 3eacf866559c ("brcmfmac: introduce brcmf_cfg80211_vif structure") but it remains unused since then. It seems we can safely drop it. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfma

Re: brcmfmac: rework function picking free BSS index

On 9 June 2016 at 18:30, Kalle Valo <kv...@codeaurora.org> wrote: > Kalle Valo <kv...@codeaurora.org> writes: > >> Rafał Miłecki wrote: >>> The old implementation was overcomplicated and slightly bugged in some >>> corner cases. >>> &

Re: [PATCH] brcmfmac: fix setting AP channel with new firmwares

On 25 May 2016 at 23:08, Arend van Spriel <arend.vanspr...@broadcom.com> wrote: > 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 &

[PATCH V3] brcmfmac: print error if p2p_ifadd firmware command fails

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 <zaj...@gmail.com> --- V2: s/in/if/ in commit message V3: Add one more error m

Re: [PATCH] brcmfmac: rework function picking free BSS index

On 13 June 2016 at 21:30, Arend van Spriel <arend.vanspr...@broadcom.com> wrote: > 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 ca

[PATCH] brcmfmac: rework function picking free BSS index

ould be future proof (if we ever allow deleting). Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 17 ++- .../wireless/broadcom/brcm80211/brcmfmac/core.c| 24 -- .../wireless/broadcom/brcm80211/b

[PATCH V2] brcmfmac: fix setting AP channel with new firmwares

and tested for regressions on BCM43602. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- V2: Avoid checking AP vs. P2P at two different places, just add code setting "chanspec" to existing paths. --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 36 +++-

[PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

as it always assumes rtnl to be unlocked. Fix it by adding an extra rtnl_locked parameter to functions and calling unregister_netdevice when needed. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +- .../wireless/broadcom/brc

[PATCH V4] brcmfmac: print errors if creating interface fails

This is helpful for debugging. Without this all I was getting from "iw" command on failed creating of P2P interface was: > command failed: Too many open files in system (-23) Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- V2: s/in/if/ in commit message V3: Add one

[PATCH RFC] brcmfmac: support deleting MBSS AP interfaces

present in a firmware. If there is request for adding a new interface this code is capable of reusing existing BSS-es. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 84 +++--- .../wireless/broadcom/brcm80211/brcmfmac/

[PATCH next] brcmfmac: don't remove interface on link down firmware event

nux interface while firmware keeps BSS. Thanks to this we keep a consistent states of host driver and device firmware. Further improvement should be to mark BSS as disabled and remove interface on BRCMF_E_LINK. Then we should add support for reusing BSS-es. Signed-off-by: Rafał Miłecki &

[PATCH V2 next] brcmfmac: don't remove interface on link down firmware event

nux interface while firmware keeps BSS. Thanks to this we keep a consistent states of host driver and device firmware. Further improvement should be to mark BSS as disabled and remove interface on BRCMF_E_LINK. Then we should add support for reusing BSS-es. Signed-off-by: Rafał Miłecki &

Re: [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces

On 1 June 2016 at 21:00, Arend van Spriel <arend.vanspr...@broadcom.com> 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. >> >> Adding a new interface

[PATCH REBASED] brcmfmac: fix lockup when removing P2P interface after event timeout

as it always assumes rtnl to be unlocked. Fix it by adding an extra rtnl_locked parameter to functions and calling unregister_netdevice when needed. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- REBASED on top of wireless-drivers-next. This bug isn't very common and changes may co

Re: [PATCH RFC 1/2] brcmfmac: remove interface before notifying listener

On 18 June 2016 at 21:26, Arend van Spriel <arend.vanspr...@broadcom.com> wrote: > 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 in

[PATCH V2 RFC 2/2] brcmfmac: support removing AP interfaces with "interface_remove"

y behavior. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- V2: Add extra chcek for ndev. Thanks Arend. --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 39 +- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/br

[PATCH V2 RFC 1/2] brcmfmac: delete interface directly in code that sent fw request

and will block process holding rtnl lock. This can be simply solved by unregistering interface in a proper callback, right after receiving confirmation event from firmware. This only required modifying worker to don't unregister on its own if there is someone waiting for the event. Signed-off-by: Rafał

Re: [PATCH RFC 1/2] brcmfmac: remove interface before notifying listener

On 18 June 2016 at 23:58, Rafał Miłecki <zaj...@gmail.com> wrote: > On 18 June 2016 at 21:26, Arend van Spriel <arend.vanspr...@broadcom.com> > wrote: >> On 18-06-16 20:18, Rafał Miłecki wrote: >>> So far when receiving event about in-firmware-interface removal w

[PATCH] brcmfmac: add missing break when deleting P2P_DEVICE

We obviously don't want to fall through in that switch. With this change 1) We wait for event (triggered by p2p_disc) as expected 2) We remove interface manually on timeout 3) We return 0 on success instead of -ENOTSUPP Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/net/wi

[PATCH RFC 1/2] brcmfmac: remove interface before notifying listener

our event. Moreover this changes makes sure we call unregister_netdevice before del_virtual_intf leaves which isn't critical but it makes a bit more of sense to handle it this way. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.

[PATCH] brcmfmac: include also core.h header in cfg80211.h

igned-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h index 04bfc7e.

[PATCH RFC 2/2] brcmfmac: support removing AP interfaces with "interface_remove"

y behavior. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 37 +- 1 file changed, 36 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/br

Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

On 16 June 2016 at 17:10, Kalle Valo <kv...@codeaurora.org> wrote: > Rafał Miłecki <zaj...@gmail.com> writes: > >> Removing P2P interface is handled by sending a proper request to the >> firmware. On success firmware triggers an event and driver's handler &

Re: [PATCH RFC] brcmfmac: support deleting MBSS AP interfaces

On 17 June 2016 at 21:00, Arend van Spriel <arend.vanspr...@broadcom.com> wrote: > On 17-06-16 14:30, Rafał Miłecki wrote: >> On 1 June 2016 at 21:00, Arend van Spriel <arend.vanspr...@broadcom.com> >> wrote: >>> On 01-06-16 16:36, Rafał Miłecki wrote: >

Re: [PATCH 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout

On 17 June 2016 at 07:13, Kalle Valo <kv...@codeaurora.org> wrote: > Rafał Miłecki <zaj...@gmail.com> writes: > >> On 16 June 2016 at 17:10, Kalle Valo <kv...@codeaurora.org> wrote: >>> Rafał Miłecki <zaj...@gmail.com> writes: >>> >>>

[PATCH] brcmfmac: use const char * for interface name in brcmf_add_if

. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 2 +- drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cor

[PATCH] bgmac: add helper checking for BCM4707 / BCM53018 chip id

Chipsets with BCM4707 / BCM53018 ID require special handling at a few places in the code. It's likely there will be more IDs to check in the future. To simplify it add this trivial helper. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/net/ethernet/broadcom/bgmac.

Re: [PATCH] bgmac: add helper checking for BCM4707 / BCM53018 chip id

On 30 January 2016 at 08:03, David Miller <da...@davemloft.net> wrote: > From: Rafał Miłecki <zaj...@gmail.com> > Date: Sat, 30 Jan 2016 00:41:07 +0100 > >> Chipsets with BCM4707 / BCM53018 ID require special handling at a few >> places in the code. It's likel

[PATCH] bgmac: add helper checking for BCM4707 / BCM53018 chip id

Chipsets with BCM4707 / BCM53018 ID require special handling at a few places in the code. It's likely there will be more IDs to check in the future. To simplify it add this trivial helper. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- It's the same change as sent few days ago

[PATCH net-next] bgmac: support Ethernet device on BCM47094 SoC

It needs very similar workarounds to the one on BCM4707. It was tested on D-Link DIR-885L home router. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- It's the same patch as last time, just with a proper prefix ("net-next") --- drivers/net/ethernet/broadcom/bgmac.c | 6 --

Regression: netlink fail (triggered by iw) removes extra wlan (phy) interface

Hi, After updating kernel in OpenWrt from 4.1.6 to 4.1.10 I noticed that if "iw" command fails (which happens very rarely) my wlan0-1 interface disappears. To trigger this problem easily I'm using this trivial script: while [ 1 ] do iw phy phy0 interface add mon0 type monitor

[PATCH] bgmac: support Ethernet device on BCM47094 SoC

It needs very similar workarounds to the one on BCM4707. It was tested on D-Link DIR-885L home router. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/net/ethernet/broadcom/bgmac.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/br

Re: [PATCH] b43: fix memory leak

On 18 February 2016 at 13:34, Sudip Mukherjee wrote: > From: Sudip Mukherjee > > On error we jumped to the label bcma_out and returned the error code but > we missed freeing dev. What if b43_one_core_attach fails? Won't we miss kfree then as

Re: [PATCH] bgmac: support Ethernet device on BCM47094 SoC

On 19 February 2016 at 21:37, David Miller <da...@davemloft.net> wrote: > From: Rafał Miłecki <zaj...@gmail.com> > Date: Wed, 17 Feb 2016 07:48:28 +0100 > >> It needs very similar workarounds to the one on BCM4707. It was tested >> on D-Link DIR-885L home router. &

[PATCH 4.6 fix] bgmac: fix MAC soft-reset bit for corerev > 4

oesn't seem to care which bit gets used. Signed-off-by: Felix Fietkau <n...@openwrt.org> Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- If it's OK for everyone, I suggest taking this patch into net.git repo. It obviously can't regress old devices and was well tested on new one

[PATCH 4.6 fix] bgmac: reset & enable Ethernet core before using it

This fixes Ethernet on D-Link DIR-885L with BCM47094 SoC. Felix reported similar fix was needed for his BCM4709 device (Buffalo WXR-1900DHP?). I tested this for regressions on BCM4706, BCM4708A0 and BCM47081A0. Cc: Felix Fietkau <n...@openwrt.org> Signed-off-by: Rafał Miłecki <zaj...@

Re: Regression: netlink fail (triggered by iw) removes extra wlan (phy) interface

On 25 February 2016 at 14:22, Rafał Miłecki <zaj...@gmail.com> wrote: > After updating kernel in OpenWrt from 4.1.6 to 4.1.10 I noticed that > if "iw" command fails (which happens very rarely) my wlan0-1 interface > disappears. To trigger this problem easily I'm us

[PATCH V2 4.8 1/2] brcmutil: add field storing control channel to the struct brcmu_chan

mbers, e.g. cfg80211 callback getting current channel. Solve this by adding a separated field for control channel. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> Reviewed-by: Arend van Spriel <arend.vanspr...@broadcom.com> --- V2: Update commit description message. --- .../broadc

Re: [PATCH 4.8 2/2] brcmfmac: support get_channel cfg80211 callback

On 20 May 2016 at 09:42, Arend Van Spriel <arend.vanspr...@broadcom.com> wrote: > 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 >

[PATCH V2 4.8 2/2] brcmfmac: support get_channel cfg80211 callback

This is important for brcmfmac as some of released firmwares (e.g. brcmfmac4366b-pcie.bin) may pick different channel than requested. This has been tested with BCM4366B1 in D-Link DIR-885L. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- V2: Check if ndev isn't NULL, update descr

[PATCH 4.8 2/2] brcmfmac: support get_channel cfg80211 callback

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). Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 59 ++ 1 file c

[PATCH 4.8 1/2] brcmutil: add field storing control channel to the struct brcmu_chan

owever when decoding chanspec the same field is filled with a *control* channel number. This can be confusing and doesn't allow accessing all info when decoding. Solve it by adding a separated field for control channel. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- .../broadcom/brc

[PATCH] brcmfmac: fix setting AP channel with new firmwares

it leaves this code unaffected. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- .../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drive

Re: Regression: netlink fail (triggered by iw) removes extra wlan (phy) interface

Hi again and sorry for the late reply. On 16 March 2016 at 17:00, Cong Wang <xiyou.wangc...@gmail.com> wrote: > On Thu, Feb 25, 2016 at 5:22 AM, Rafał Miłecki <zaj...@gmail.com> wrote: >> After updating kernel in OpenWrt from 4.1.6 to 4.1.10 I noticed that >> if "

[PATCH] brcmfmac: print error in p2p_ifadd firmware command fails

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 <zaj...@gmail.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 2 +-

[PATCH V2] brcmfmac: print error if p2p_ifadd firmware command fails

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 <zaj...@gmail.com> --- V2: s/in/if/ in commit message --- drivers/net/wireless

Re: [BUGFIX PATCH 1/2] brcmfmac: Check rtnl_lock is locked when removing interface

On 15 August 2016 at 12:57, Kalle Valo <kv...@codeaurora.org> wrote: > Rafał Miłecki <zaj...@gmail.com> writes: > >>> Signed-off-by: Masami Hiramatsu <mhira...@kernel.org> >> >> Fixes: a63b09872c1d ("brcmfmac: delete interface directly in code tha

[PATCH] brcmfmac: respect hidden_ssid for AP interfaces

This was succesfully tested with 4366B1. A small workaround is needed for the main interface otherwise it would stuck at the hidden state. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 13 + 1 file chang

[PATCH 1/2] brcmfmac: delete interface directly in code that sent fw request

and will block process holding rtnl lock. This can be simply solved by unregistering interface in a proper callback, right after receiving confirmation event from firmware. This only required modifying worker to don't unregister on its own if there is someone waiting for the event. Signed-off-by: Rafał

Re: [PATCH 0/2] brcmfmac: support removing AP interfaces with new fw

On 29 June 2016 at 21:54, Rafał Miłecki <zaj...@gmail.com> wrote: > This is the latest patchset needed to get brcmfmac working reasonably well > with BCM4366. > > Both patches were already sent as V2 RFC (10 days ago), there were no more > comments since then and this is the s

[PATCH 2/2] brcmfmac: support removing AP interfaces with "interface_remove"

y behavior. Signed-off-by: Rafał Miłecki <zaj...@gmail.com> --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 39 +- 1 file changed, 38 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/br

Re: [PATCH v2 4/6] net: ethernet: bgmac: convert to feature flags

On 8 July 2016 at 01:08, Jon Mason wrote: > mode = (bgmac_read(bgmac, BGMAC_DEV_STATUS) & BGMAC_DS_MM_MASK) >> > BGMAC_DS_MM_SHIFT; > - if (ci->id != BCMA_CHIP_ID_BCM47162 || mode != 0) > + if (bgmac->feature_flags & BGMAC_FEAT_CLKCTLST

[PATCH net] net: bgmac: fix reversed check for MII registration error

From: Rafał Miłecki <ra...@milecki.pl> It was failing on successful registration returning meaningless errors. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> Fixes: 55954f3bfdac ("net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file") --- This fix is intend

[PATCH net-next] net: bgmac: make it clear when setting interface type to RMII

From: Rafał Miłecki <ra...@milecki.pl> It doesn't really change anything as BGMAC_CHIPCTL_1_IF_TYPE_RMII is equal to 0. It make code a bit clener, so far when reading it one could think we forgot to set a proper mode. It also keeps this mode code in sync with other ones. Signed-off-by:

[PATCH net-next] net: bgmac: support Ethernet core on BCM53573 SoCs

From: Rafał Miłecki <ra...@milecki.pl> BCM53573 is a new series of Broadcom's SoCs. It's based on ARM and can be found in two packages (versions): BCM53573 and BCM47189. It shares some code with the Northstar family, but also requires some new quirks. First of all there can be up to 2 Et

Re: [PATCH 1/2] net: ethernet: bgmac: init sequence bug

On 02/01/2017 11:39 PM, Jon Mason wrote: From: Zac Schroff Fix a bug in the 'bgmac' driver init sequence that blind writes for init sequence where it should preserve most bits other than the ones it is deliberately manipulating. Signed-off-by: Zac Schroff

Re: [PATCH 1/2] net: ethernet: bgmac: init sequence bug

On 2017-02-02 01:31, Zac Schroff wrote: How about BCMA_IOCTL_PRESERVE_ACROSS_INIT? I think wireless drivers may still set some these bits during init. I've a simpler idea: make it bgmac specific. Call it sth like BGMAC_BCMA_IOCTL_PRESERVE BGMAC_BCMA_IOCTL_RESERVED BGMAC_BCMA_IOCTL_DONT_TOUCH

Re: [PATCH v2 3/4] phy: Add USB3 PHY support for Broadcom NSP SoC

[Resending with fixed/complete Cc-s] On Tue, 17 Jan 2017 11:14:29 -0500, Yendapally Reddy Dhananjaya Reddy wrote:> This patch adds support for Broadcom NSP USB3 PHY > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy

Re: [PATCH 2/2] net: ethernet: bgmac: mac address change bug

On 02/01/2017 11:39 PM, Jon Mason wrote: From: Hari Vyas ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to bgmac_set_mac_address() but code assumed u8 *. This caused two bytes chopping and the wrong mac address was configured. Signed-off-by: Hari Vyas

Re: [PATCH v2 2/2] net: ethernet: bgmac: mac address change bug

On 02/03/2017 10:08 PM, Jon Mason wrote: From: Hari Vyas ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to bgmac_set_mac_address() but code assumed u8 *. This caused two bytes chopping and the wrong mac address was configured. Signed-off-by: Hari Vyas

Re: [PATCH v2 1/2] net: ethernet: bgmac: init sequence bug

On 02/03/2017 10:08 PM, Jon Mason wrote: @@ -61,15 +60,20 @@ static bool platform_bgmac_clk_enabled(struct bgmac *bgmac) static void platform_bgmac_clk_enable(struct bgmac *bgmac, u32 flags) { - bgmac_idm_write(bgmac, BCMA_IOCTL, - (BCMA_IOCTL_CLK | BCMA_IOCTL_FGC

Re: [PATCH 2/3] net: ethernet: bgmac: unify code of the same family

On 2017-02-03 22:39, Jon Mason wrote: BCM471X and BCM535X are of the same family (from what I can derive from internal documents). Group them into the case statement together, which results in more code reuse. Also, use existing helper variables to make the code a little more readable too.

Re: [PATCH 4.10-rc3 05/13] net: bgmac: fix build errors when linux/phy*.h is removed from net/dsa.h

-off-by: Russell King <rmk+ker...@armlinux.org.uk> Acked-by: Rafał Miłecki <ra...@milecki.pl>

Re: [PATCH V2 3/3] net: bgmac: use PHY subsystem for initializing PHY

On 31 January 2017 at 19:16, David Miller wrote: > From: David Miller > Date: Tue, 31 Jan 2017 13:14:52 -0500 (EST) > >> From: Florian Fainelli >> Date: Tue, 31 Jan 2017 10:06:34 -0800 >> >>> On 01/31/2017 10:04 AM, David Miller

[PATCH V3 1/3] net: bgmac: allocate struct bgmac just once & don't copy it

From: Rafał Miłecki <ra...@milecki.pl> So far were were allocating struct bgmac in 3 places: platform code, bcma code and shared bgmac_enet_probe function. The reason for this was bgmac_enet_probe: 1) Requiring early-filled struct bgmac 2) Calling alloc_etherdev on its own in order

[PATCH V3 2/3] net: bgmac: drop struct bcma_mdio we don't need anymore

From: Rafał Miłecki <ra...@milecki.pl> Adding struct bcma_mdio was a workaround for bcma code not having access to the struct bgmac used in the core code. Now we don't duplicate this struct we can just use it internally in bcma code. This simplifies code & allows access to all bg

[PATCH V3 0/3] net-next: use one struct bgmac & add PHY support

From: Rafał Miłecki <ra...@milecki.pl> This patchset adds support for initializing PHY using PHY subsystem. It's required e.g. for wireless access point devices that use bgmac supported Ethernet device connected to some external PHY. Implementing this required accessing phydev in bcma sp

[PATCH V3 3/3] net: bgmac: use PHY subsystem for initializing PHY

From: Rafał Miłecki <ra...@milecki.pl> This adds support for using bgmac with PHYs supported by standalone PHY drivers. Having any PHY initialization in bgmac is hacky and shouldn't be extended but rather removed if anyone has hardware to test it. Signed-off-by: Rafał Miłecki <ra...@m

[PATCH] net: phy: broadcom: rehook BCM54612E specific init

From: Rafał Miłecki <ra...@milecki.pl> This extra BCM54612E code in PHY driver isn't really aneg specific. Even without it aneg works OK but the problem is no packets pass through PHY. Moreover putting this code inside config_aneg callback didn't allow resuming PHY correctly. When driver

Re: [PATCH 1/3] net: bgmac: allocate struct bgmac just once & don't copy it

On 27 January 2017 at 17:14, David Miller <da...@davemloft.net> wrote: > From: Felix Fietkau <n...@nbd.name> > Date: Fri, 27 Jan 2017 17:02:33 +0100 > >> On 2017-01-27 10:20, Rafał Miłecki wrote: >>> From: Rafał Miłecki <ra...@milecki.pl> >>> >

[PATCH net-next] net: add devm version of alloc_etherdev_mqs function

From: Rafał Miłecki <ra...@milecki.pl> This patch adds devm_alloc_etherdev_mqs function and devm_alloc_etherdev macro. These can be used for simpler netdev allocation without having to care about calling free_netdev. Thanks to this change drivers, their error paths and removal paths m

[PATCH V2 1/3] net: bgmac: allocate struct bgmac just once & don't copy it

From: Rafał Miłecki <ra...@milecki.pl> So far were were allocating struct bgmac in 3 places: platform code, bcma code and shared bgmac_enet_probe function. The reason for this was bgmac_enet_probe: 1) Requiring early-filled struct bgmac 2) Calling alloc_etherdev on its own in order

[PATCH V2 0/3] net-next: use one struct bgmac & add PHY support

From: Rafał Miłecki <ra...@milecki.pl> This patchset adds support for initializing PHY using PHY subsystem. It's required e.g. for wireless access point devices that use bgmac supported Ethernet device connected to some external PHY. Implementing this required accessing phydev in bcma sp

[PATCH V2 3/3] net: bgmac: use PHY subsystem for initializing PHY

From: Rafał Miłecki <ra...@milecki.pl> This adds support for using bgmac with PHYs supported by standalone PHY drivers. Having any PHY initialization in bgmac is hacky and shouldn't be extended but rather removed if anyone has hardware to test it. Signed-off-by: Rafał Miłecki <ra...@m

[PATCH V2 2/3] net: bgmac: drop struct bcma_mdio we don't need anymore

From: Rafał Miłecki <ra...@milecki.pl> Adding struct bcma_mdio was a workaround for bcma code not having access to the struct bgmac used in the core code. Now we don't duplicate this struct we can just use it internally in bcma code. This simplifies code & allows access to all bg

Re: [PATCH V2 3/3] net: bgmac: use PHY subsystem for initializing PHY

On 01/29/2017 04:08 AM, Florian Fainelli wrote: On 01/28/2017 01:08 PM, Rafał Miłecki wrote: From: Rafał Miłecki <ra...@milecki.pl> This adds support for using bgmac with PHYs supported by standalone PHY drivers. Having any PHY initialization in bgmac is hacky and shouldn't be ex

Re: [PATCH V2 1/3] net: bgmac: allocate struct bgmac just once & don't copy it

On 01/29/2017 12:40 AM, kbuild test robot wrote: [auto build test ERROR on net-next/master] [also build test ERROR on v4.10-rc5 next-20170125] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH V2 3/3] net: bgmac: use PHY subsystem for initializing PHY

On 29 January 2017 at 21:22, Florian Fainelli <f.faine...@gmail.com> wrote: > On 01/29/2017 12:14 PM, Rafał Miłecki wrote: >> On 01/29/2017 04:08 AM, Florian Fainelli wrote: >>> On 01/28/2017 01:08 PM, Rafał Miłecki wrote: >>>> From: Rafał Miłecki <ra...@

Re: [PATCH V2 3/3] net: bgmac: use PHY subsystem for initializing PHY

On 29 January 2017 at 23:36, Florian Fainelli <f.faine...@gmail.com> wrote: > Le 01/29/17 à 13:31, Rafał Miłecki a écrit : >> On 29 January 2017 at 21:22, Florian Fainelli <f.faine...@gmail.com> wrote: >>> On 01/29/2017 12:14 PM, Rafał Miłecki wrote: >>>>

[PATCH 2/3] net: phy: broadcom: drop duplicated define for RXD to RXC delay

From: Rafał Miłecki <ra...@milecki.pl> We had two defines for the same bit (both were used with the MII_BCM54XX_AUXCTL_SHDWSEL_MISC register). Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- drivers/net/phy/broadcom.c | 2 +- include/linux/brcmphy.h| 1 - 2 files changed,

[PATCH 1/3] net: phy: broadcom: use auxctl reading helper in BCM54612E code

From: Rafał Miłecki <ra...@milecki.pl> Starting with commit 5b4e29005123 ("net: phy: broadcom: add bcm54xx_auxctl_read") we have a reading helper so use it and avoid code duplication. It also means we don't need MII_BCM54XX_AUXCTL_SHDWSEL_MISC define

[PATCH 3/3] net: phy: bcm-phy-lib: clean up remaining AUXCTL register defines

From: Rafał Miłecki <ra...@milecki.pl> 1) Use 0x%02x format for register number. This follows some other defines and makes it easier to distinct register from values. 2) Put register define above values and sort the values. It makes reading header code easier. 3) Drop SHDWSEL_ nam

[PATCH 3/3] net: bgmac: use PHY subsystem for initializing PHY

From: Rafał Miłecki <ra...@milecki.pl> This adds support for using bgmac with PHYs supported by standalone PHY drivers. Having any PHY initialization in bgmac is hacky and shouldn't be extended but rather removed if anyone has hardware to test it. Signed-off-by: Rafał Miłecki <ra...@m

[PATCH 0/3] net-next: use one struct bgmac & add PHY support

From: Rafał Miłecki <ra...@milecki.pl> This patchset adds support for initializing PHY using PHY subsystem. It's required e.g. for wireless access point devices that use bgmac supported Ethernet device connected to some external PHY. Implementing this required accessing phydev in bcma sp

[PATCH 2/3] net: bgmac: drop struct bcma_mdio we don't need anymore

From: Rafał Miłecki <ra...@milecki.pl> Adding struct bcma_mdio was a workaround for bcma code not having access to the struct bgmac used in the core code. Now we don't duplicate this struct we can just use it internally in bcma code. This simplifies code & allows access to all bg

[PATCH 1/3] net: bgmac: allocate struct bgmac just once & don't copy it

From: Rafał Miłecki <ra...@milecki.pl> To share as much code as possible in bgmac we call alloc_etherdev from bgmac.c which is used by both: platform and bcma code. The easiest solution was to use it for allocating whole struct bgmac but it doesn't work well as we already get early-filled

[PATCH] net: phy: broadcom: add support for BCM54210E

From: Rafał Miłecki <ra...@milecki.pl> It's Broadcom PHY simply described as single-port RGMII 10/100/1000BASE-T PHY. It requires disabling delay skew and GTXCLK bits. Signed-off-by: Rafał Miłecki <ra...@milecki.pl> --- drivers/net/phy/broadcom.c | 34 ++

  1   2   >