Re: [PATCH net-next] modules: allow modprobe load regular elf binaries

On 6 Mar 2018, at 11:12, Linus Torvalds wrote: On Mon, Mar 5, 2018 at 5:34 PM, Alexei Starovoitov wrote: As the first step in development of bpfilter project [1] the request_module() code is extended to allow user mode helpers to be invoked. Idea is that user mode helpers

Re: Waiting for the PHY to complete auto-negotiation

On 11/12/2017 15:36, Måns Rullgård wrote: > Mason writes: > >> I suppose I should test forcefully setting the enable bit to 0 in >> the driver, and see if hell breaks loose. > > You can't. When the enable bit is 1, writes to that register are > ignored. It goes b

Re: Waiting for the PHY to complete auto-negotiation

+ Mans On 09/12/2017 19:49, Florian Fainelli wrote: > Having any HW state machine requiring X number of clock cycles to > guarantee a full transition to a stopped state is not unusual, however, > the fact that you need to send 5 packets to guarantee an EOC descriptor > is hit is completely

Re: Waiting for the PHY to complete auto-negotiation

On 07/12/2017 00:00, Florian Fainelli wrote: > On 12/06/2017 11:25 AM, Mason wrote: > >> When we detect link down, we put the ethernet HW block in reset, >> and repeat initialization when the link comes back up. >> >> Hmmm, however, at the moment, I only reset

Re: Waiting for the PHY to complete auto-negotiation

On 06/12/2017 20:07, Andrew Lunn wrote: > By chip, you mean the Ethernet controller? Not the whole SoC? Doh! Yes. Let me rephrase. When we detect link down, we put the ethernet HW block in reset, and repeat initialization when the link comes back up. Hmmm, however, at the moment, I only reset

Re: Waiting for the PHY to complete auto-negotiation

On 06/12/2017 19:26, Andrew Lunn wrote: > On 06/12/2017 19:03, Mason wrote: > >> The problem with this is the following mind-boggling quirk of >> the hardware: once RX DMA is enabled, there is no supported >> way to disable it! Thus, I'm trying to find a clean way to

Re: Waiting for the PHY to complete auto-negotiation

On 06/12/2017 17:59, Andrew Lunn wrote: > On Wed, Dec 06, 2017 at 05:39:00PM +0100, Mason wrote: > >> I've been trying to wrap my head around Ethernet auto-negotiation, >> vs actual / real packets seen at the MAC layer. I found the relevant >> Wikipedia article

Waiting for the PHY to complete auto-negotiation

Hello, I've been trying to wrap my head around Ethernet auto-negotiation, vs actual / real packets seen at the MAC layer. I found the relevant Wikipedia article to be fairly informative: https://en.wikipedia.org/wiki/Autonegotiation The reason I care is that my Ethernet HW does not allow

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 06/09/2017 20:00, David Daney wrote: > On 08/31/2017 11:29 AM, Florian Fainelli wrote: >> On 08/31/2017 11:12 AM, Mason wrote: >>> On 31/08/2017 19:53, Florian Fainelli wrote: >>>> On 08/31/2017 10:49 AM, Mason wrote: >>>>> On 31/08/2017 18:57

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 31/08/2017 21:18, Florian Fainelli wrote: On 08/31/2017 12:09 PM, Mason wrote: On 31/08/2017 19:03, Florian Fainelli wrote: On 08/31/2017 05:29 AM, Marc Gonzalez wrote: On 31/08/2017 02:49, Florian Fainelli wrote: The original motivation for this change originated from Marc Gonzalez

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 31/08/2017 21:18, Florian Fainelli wrote: On 08/31/2017 12:09 PM, Mason wrote: 1) nb8800_link_reconfigure() calls phy_print_status() which prints the "Link down" and "Link up" messages to the console. With the patch reverted, nothing is printed when the link goes

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 31/08/2017 20:29, Florian Fainelli wrote: On 08/31/2017 11:12 AM, Mason wrote: On 31/08/2017 19:53, Florian Fainelli wrote: On 08/31/2017 10:49 AM, Mason wrote: On 31/08/2017 18:57, Florian Fainelli wrote: And the race is between phy_detach() setting phydev->attached_dev = N

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 31/08/2017 19:03, Florian Fainelli wrote: > On 08/31/2017 05:29 AM, Marc Gonzalez wrote: > >> On 31/08/2017 02:49, Florian Fainelli wrote: >> >>> The original motivation for this change originated from Marc Gonzalez >>> indicating that his network driver did not have its adjust_link callback

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 31/08/2017 19:53, Florian Fainelli wrote: > On 08/31/2017 10:49 AM, Mason wrote: >> On 31/08/2017 18:57, Florian Fainelli wrote: >>> And the race is between phy_detach() setting phydev->attached_dev = NULL >>> and phy_state_machine() running in PHY_HALTED state and

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 31/08/2017 18:57, Florian Fainelli wrote: > And the race is between phy_detach() setting phydev->attached_dev = NULL > and phy_state_machine() running in PHY_HALTED state and calling > netif_carrier_off(). I must be missing something. (Since a thread cannot race against itself.)

Re: [PATCH net] Revert "net: phy: Correctly process PHY_HALTED in phy_stop_machine()"

On 31/08/2017 18:36, David Daney wrote: > On 08/31/2017 05:29 AM, Marc Gonzalez wrote: >> On 31/08/2017 02:49, Florian Fainelli wrote: >> >>> This reverts commit 7ad813f208533cebfcc32d3d7474dc1677d1b09a ("net: phy: >>> Correctly process PHY_HALTED in phy_stop_machine()") because it is >>> creating

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 22:02, Mason wrote: > I need to run the test slightly slower, to prevent packet loss > at the sender. # iperf3 -c 172.27.64.45 -u -b 0 -l 1000 Connecting to host 172.27.64.45, port 5201 [ 4] local 172.27.64.1 port 42607 connected to 172.27.64.45 port 5201 [ ID] In

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 19:31, Mason wrote: > # iperf3 -c 172.27.64.45 -u -b 950M > Connecting to host 172.27.64.45, port 5201 > [ 4] local 172.27.64.1 port 55533 connected to 172.27.64.45 port 5201 > [ ID] Interval Transfer Bandwidth Total Datagrams > [ 4] 0.00-1

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 18:10, Måns Rullgård wrote: > ping -f is limited to 100 packets per second. > Use something like iperf in UDP mode instead. CLIENT: DESKTOP # iperf3 -c 172.27.64.45 -u -b 950M Connecting to host 172.27.64.45, port 5201 [ 4] local 172.27.64.1 port 55533 connected to 172.27.64.45

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 18:10, Måns Rullgård wrote: > Mason writes: > >> On 02/08/2017 17:56, Måns Rullgård wrote: >> >>> What does the tango5 do if you flood it with packets faster than the >>> kernel can keep up with? That would make it hit the end of the rx >&

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 17:56, Måns Rullgård wrote: > Mason writes: > >> From my perspective, the older method does not work on newer chips :-) > > It does work on tango4. Agreed. > What does the tango5 do if you flood it with packets faster than the > kernel can keep up with?

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 02/08/2017 17:36, Måns Rullgård wrote: > Mason wrote: > >> Looking at the tango-specific integration, I note this nugget: >> >> 1.5.4 Stopping & Starting the DMA >> >> This feature has been added to allow the software to stop and start >> the

Re: [RFC PATCH v2 0/2] nb8800 suspend/resume support

On 01/08/2017 18:32, Mason wrote: > I need suspend/resume support in the nb8800 driver. > On tango platforms, suspend loses all context (MMIO registers). > To make the task easy, we just close the device on suspend, > and open it again on resume. This requires properly resett

Re: [RFC PATCH v2 1/2] net: ethernet: nb8800: Reset HW block in ndo_open

On 02/08/2017 13:02, Måns Rullgård wrote: > Mason wrote: > >> Move all HW initializations to nb8800_init. >> This provides the basis for suspend/resume support. >> --- >> drivers/net/ethernet/aurora/nb8800.c | 50 >> +--- >

[RFC PATCH v2 2/2] net: ethernet: nb8800: Add suspend/resume support

Wrappers around nb8800_stop and nb8800_open. --- drivers/net/ethernet/aurora/nb8800.c | 23 ++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/aurora/nb8800.c b/drivers/net/ethernet/aurora/nb8800.c index aa18ea25d91f..607064a6d7a1 100644

[RFC PATCH v2 1/2] net: ethernet: nb8800: Reset HW block in ndo_open

Move all HW initializations to nb8800_init. This provides the basis for suspend/resume support. --- drivers/net/ethernet/aurora/nb8800.c | 50 +--- drivers/net/ethernet/aurora/nb8800.h | 1 + 2 files changed, 25 insertions(+), 26 deletions(-) diff --git

[RFC PATCH v2 0/2] nb8800 suspend/resume support

Hello, I need suspend/resume support in the nb8800 driver. On tango platforms, suspend loses all context (MMIO registers). To make the task easy, we just close the device on suspend, and open it again on resume. This requires properly resetting the HW on resume. Patch 1 moves all the HW init to

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 31/07/2017 16:08, Mason wrote: > Other things make no sense to me, for example in nb8800_dma_stop() > there is a polling loop: > > do { > mdelay(100); > nb8800_writel(priv, NB8800_TX_DESC_ADDR, txb->dma_desc); > wmb(); &g

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 31/07/2017 13:59, Måns Rullgård wrote: > Mason writes: > >> On 29/07/2017 17:18, Florian Fainelli wrote: >> >>> On 07/29/2017 05:02 AM, Mason wrote: >>> >>>> I have identified a 100% reproducible flaw. >>>> I have proposed a wor

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 29/07/2017 17:18, Florian Fainelli wrote: > On 07/29/2017 05:02 AM, Mason wrote: > >> I have identified a 100% reproducible flaw. >> I have proposed a work-around that brings this down to 0 >> (tested 1000 cycles of link up / ping / link down). > > Can you als

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 29/07/2017 22:15, Florian Fainelli wrote: > On 07/29/2017 05:44 AM, Mason wrote: > >> We tested 4 switches, and DHCP failed on 3 of them. >> Disabling pause frames "fixed" that. > > OK, so it is this problem that you reported about before? The "Ethe

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 29/07/2017 14:05, Måns Rullgård wrote: > Mason writes: > >> I'll take this opportunity to change flow control to >> off by default (it breaks several 100 Mbps switches). > > I was told to have it on by default. This is what most other drivers > do too. If you h

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 29/07/2017 13:24, Måns Rullgård wrote: > Until you figure out why it's getting stuck, we can't be sure > it isn't caused by something that could trigger at any time. Would you take a look at it, if I can reproduce on tango4? I have identified a 100% reproducible flaw. I have proposed a

Re: [RFC PATCH v1] net: ethernet: nb8800: Reset HW block in ndo_open

On 28/07/2017 20:56, Måns Rullgård wrote: > Marc Gonzalez writes: > >> On 28/07/2017 18:17, Måns Rullgård wrote: >> >>> Marc Gonzalez wrote: >>> ndo_stop breaks RX in a way that ndo_open is unable to undo. >>> >>> Please elaborate. Why can't it be fixed in a less heavy-handed way? >> >>

Re: Problem with PHY state machine when using interrupts

On 25/07/2017 12:51, Mason wrote: > Moving the call to phy_stop() down after all the MAC tear down > avoids the hang. > > As far as I understand, when we are shutting everything down, > we don't need the phy_state_machine to run asynchronously. > We can run it synchronously o

Re: Problem with PHY state machine when using interrupts

On 25/07/2017 00:39, Florian Fainelli wrote: > diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c > index d0626bf5c540..652e24b53f3f 100644 > --- a/drivers/net/phy/phy.c > +++ b/drivers/net/phy/phy.c > @@ -968,6 +968,8 @@ void phy_stop(struct phy_device *phydev) > * of

Re: Problem with PHY state machine when using interrupts

On 25/07/2017 00:36, Florian Fainelli wrote: > On 07/24/2017 02:20 PM, Mason wrote: >> On 24/07/2017 21:53, Florian Fainelli wrote: >> >>> Well now that I see the possible interrupts generated, I indeed don't >>> see how you can get a link down notification unle

Re: [PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup

On 24/07/2017 23:49, Florian Fainelli wrote: > On 07/24/2017 02:21 PM, Mason wrote: >> On 20/07/2017 14:33, Mason wrote: >> >>> As [Florian] pointed out, the spec states that the >>> "Data to Clock input Skew (at Receiver)" >>> must be within [

Re: [PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup

On 20/07/2017 14:33, Mason wrote: > As [Florian] pointed out, the spec states that the > "Data to Clock input Skew (at Receiver)" > must be within [ 1.0, 2.6 ] ns. > > I understand that 2 ns is 1/4 of a 125 MHz period, > but it's not clear to me why the above i

Re: Problem with PHY state machine when using interrupts

On 24/07/2017 21:53, Florian Fainelli wrote: > Well now that I see the possible interrupts generated, I indeed don't > see how you can get a link down notification unless you somehow force > the link down yourself, which would certainly happen in phy_suspend() > when we set BMCR.pwrdwn, but that

Re: Problem with PHY state machine when using interrupts

On 24/07/2017 18:49, Florian Fainelli wrote: > On 07/24/2017 08:01 AM, Mason wrote: > >>> When I set the link down via 'ip link set eth0 down' >>> (as opposed to pulling the Ethernet cable) things don't happen as expected: >>> >>> The driver's adjust_li

Re: Problem with PHY state machine when using interrupts

On 24/07/2017 13:07, Mason wrote: > When I set the link down via 'ip link set eth0 down' > (as opposed to pulling the Ethernet cable) things don't happen as expected: > > The driver's adjust_link() callback is never called, and doesn't > get a chance make some required changes.

Problem with PHY state machine when using interrupts

Hello, When I set the link down via 'ip link set eth0 down' (as opposed to pulling the Ethernet cable) things don't happen as expected: The driver's adjust_link() callback is never called, and doesn't get a chance make some required changes. And when I set the link up again, there is no network

Re: [PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup

On 19/07/2017 23:34, Florian Fainelli wrote: > How about you start reading the RGMII specification so we can at least, > if nothing else agree on the terminology? It's public: > > http://web.archive.org/web/20160303171328/http://www.hp.com/rnd/pdfs/RGMIIv2_0_final_hp.pdf Thanks for linking the

Re: [PATCH 1/2] net: phy: at803x: Fix RGMII RX and TX clock delays setup

On 19/07/2017 21:30, Florian Fainelli wrote: > On 07/19/2017 12:24 PM, Grygorii Strashko wrote: >> Hi >> >> On 07/19/2017 10:31 AM, Marc Gonzalez wrote: >>> The current code supports enabling RGMII RX and TX clock delays. >>> The unstated assumption is that these settings are disabled by >>>

Re: [PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup

On 19/07/2017 20:30, Florian Fainelli wrote: > On 07/19/2017 10:36 AM, Mason wrote: >> On 19/07/2017 19:17, Måns Rullgård wrote: >> >>> Marc Gonzalez writes: >>> >>>> According to commit e5f3a4a56ce2a707b2fb8ce37e4414dcac89c672 >>>> ("D

Re: [PATCH 2/2] net: ethernet: nb8800: Fix RGMII TX clock delay setup

On 19/07/2017 19:17, Måns Rullgård wrote: > Marc Gonzalez writes: > >> According to commit e5f3a4a56ce2a707b2fb8ce37e4414dcac89c672 >> ("Documentation: devicetree: clarify usage of the RGMII phy-modes") >> there are 4 RGMII phy-modes to handle: >> >> "rgmii" (RX and TX delays are added by the

Re: [PATCH 2/3] net: ethernet: bgmac: Make IDM register space optional

On Mon, Jul 17, 2017 at 2:37 PM, Abhishek Shah wrote: > Hi Jon, > >> This also will need to be added to >> drivers/net/ethernet/broadcom/bgmac-bcma.c. Otherwise, the driver >> will no longer work for those platforms. Since this was already >> accepted, please push

Re: [PATCH 2/3] net: ethernet: bgmac: Make IDM register space optional

On Thu, Jul 13, 2017 at 3:04 PM, Abhishek Shah wrote: > IDM operations are usually one time ops and should be done in > firmware itself. Driver is not supposed to touch IDM registers. > > However, for some SoCs', driver is performing IDM read/writes. > So this patch

Re: Quirks of the Atheros 8035 PHY

On 14/07/2017 23:28, Florian Fainelli wrote: > On 07/14/2017 02:08 PM, Mason wrote: > >> I've discussed this subject in the past, but we never reached >> a conclusion, AFAIR. >> >> The Atheros 8035 GigE PHY has IMO 2 quirks wrt to clock delays. >> >> htt

Re: Quirks of the Atheros 8035 PHY

Mugunthan's address bounces. Removing it. Adding Grygorii's address instead. On 14/07/2017 23:08, Mason wrote: > Hello, > > I've discussed this subject in the past, but we never reached > a conclusion, AFAIR. > > The Atheros 8035 GigE PHY has IMO 2 quirks wrt to clock

Quirks of the Atheros 8035 PHY

Hello, I've discussed this subject in the past, but we never reached a conclusion, AFAIR. The Atheros 8035 GigE PHY has IMO 2 quirks wrt to clock delays. https://www.redeszone.net/app/uploads/2014/04/AR8035.pdf 1) RX clock delay Commit 2e5f9f281ee8369f56d403b4a52942f19b6978f8 In fact, RX

Re: [PATCH net] mdio: mux: fix parsing mux registers outside of the PHY address range

On Mon, Jul 10, 2017 at 8:56 AM, Andrew Lunn wrote: > On Mon, Jul 10, 2017 at 02:35:23PM +0200, Martin Blumenstingl wrote: >> mdio_mux_init parses the child nodes of the MDIO mux. When using >> "mdio-mux-mmioreg" the child nodes are describing the register value >> that is written

Re: Toggling link state breaks network connectivity

On 15/06/2017 12:19, Måns Rullgård wrote: > Now I did notice one thing. When the interrupts from the loopback > frames are handled, the rx interrupt is all but disabled for NAPI poll > mode. Of course, NAPI isn't active, so the rx interrupt never gets > re-enabled. We should probably do this

Re: Toggling link state breaks network connectivity

On 13/06/2017 17:50, Florian Fainelli wrote: > On 06/13/2017 08:47 AM, Mason wrote: > >> If I unplug/replug the cable, ping still works afterward. >> (Packet RX appears to be *not* wedged) >> >> If I toggle the link state in SW (set link down/set link up), >

Re: Toggling link state breaks network connectivity

On 13/06/2017 17:36, Florian Fainelli wrote: > On 06/13/2017 08:07 AM, Mason wrote: > >> I did note something that seems important. >> If I toggle the link state in software, then connectivity breaks. >> If I unplug the ethernet cable, and replug, connectivity

Re: Toggling link state breaks network connectivity

On 13/06/2017 17:07, Mason wrote: > I did note something that seems important. > > If I toggle the link state in software, then connectivity breaks. > > If I unplug the ethernet cable, and replug, connectivity remains. > > The difference is that plugging/unplugging doesn't

Re: Toggling link state breaks network connectivity

On 12/06/2017 18:38, Florian Fainelli wrote: > On 06/12/2017 06:22 AM, Mason wrote: > >> I am using the following drivers for Ethernet connectivity. >> drivers/net/ethernet/aurora/nb8800.c >> drivers/net/phy/at803x.c >> >> Pulling the cable and plugging it ba

[PATCH net-next] of_mdio: move of_mdio_parse_addr to header file

-by: Liviu Dudau <li...@dudau.co.uk> Signed-off-by: Jon Mason <jon.ma...@broadcom.com> Fixes: 342fa1964439 ("mdio: mux: make child bus walking more permissive and errors more verbose") --- drivers/of/of_mdio.c| 22 -- include/linux/of_mdio.h | 24 +

Re: Toggling link state breaks network connectivity

On 13/06/2017 11:39, Matthias May wrote: > On 12/06/17 15:22, Mason wrote: >> Hello, >> >> I am using the following drivers for Ethernet connectivity. >> drivers/net/ethernet/aurora/nb8800.c >> drivers/net/phy/at803x.c >> >> Pulling the cable and plugg

Re: Toggling link state breaks network connectivity

Hello Florian, On 12/06/2017 18:38, Florian Fainelli wrote: > On 06/12/2017 06:22 AM, Mason wrote: > >> I am using the following drivers for Ethernet connectivity. >> drivers/net/ethernet/aurora/nb8800.c >> drivers/net/phy/at803x.c >> >> Pulling the cable an

Toggling link state breaks network connectivity

Hello, I am using the following drivers for Ethernet connectivity. drivers/net/ethernet/aurora/nb8800.c drivers/net/phy/at803x.c Pulling the cable and plugging it back works as expected. (I can ping both before and after.) However, if I toggle the link state in software (using ip link set), the

Re: [PATCH net-next] net: phy: use of_mdio_parse_addr

On Wed, Jun 7, 2017 at 12:18 PM, Liviu Dudau <li...@dudau.co.uk> wrote: > On Fri, Jun 02, 2017 at 02:22:51PM -0400, David Miller wrote: >> From: Jon Mason <jon.ma...@broadcom.com> >> Date: Wed, 31 May 2017 15:43:30 -0400 >> >> > use of_mdio_parse_addr()

[PATCH net-next] mdio: mux: make child bus walking more permissive and errors more verbose

of the MDIO bus be fatal for all entries. Instead, we should provide verbose errors describing the error and then attempt to continue if it all possible. Also, use of_mdio_parse_addr() Signed-off-by: Jon Mason <jon.ma...@broadcom.com> --- drivers/net/phy/mdio-mux.c | 24 +

[PATCH net-next] net: phy: use of_mdio_parse_addr

use of_mdio_parse_addr() in place of an OF read of reg and a bounds check (which is litterally the exact same thing that of_mdio_parse_addr() does) Signed-off-by: Jon Mason <jon.ma...@broadcom.com> --- drivers/net/phy/mdio_bus.c | 15 ++- 1 file changed, 2 insertions(+), 13 del

Re: [PATCH] mdio: mux: fix device_node_continue.cocci warnings

On Fri, May 12, 2017 at 6:52 PM, Florian Fainelli wrote: > On 05/12/2017 09:22 AM, David Miller wrote: >> From: Julia Lawall >> Date: Fri, 12 May 2017 22:54:23 +0800 (SGT) >> >>> Device node iterators put the previous value of the index variable, so an

[PATCH] mdio: mux: Correct mdio_mux_init error path issues

, I am adding it where necessary to make it uniform. Signed-off-by: Jon Mason <jon.ma...@broadcom.com> Fixes: f20e6657a875 ("mdio: mux: Enhanced MDIO mux framework for integrated multiplexers") Fixes: 0ca2997d1452 ("netdev/of/phy: Add MDIO bus multiplexer support.") ---

[PATCH] net: mdio-mux: bcm-iproc: call mdiobus_free() in error path

ath for mdio_mux_init() which calls mdiobus_unregister() prior to mdiobus_free(). Signed-off-by: Jon Mason <jon.ma...@broadcom.com> Fixes: 98bc865a1ec8 ("net: mdio-mux: Add MDIO mux driver for iProc SoCs") --- drivers/net/phy/mdio-mux-bcm-iproc.c | 5 - 1 file changed, 4 insertions(+),

Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.

On Tue, Apr 25, 2017 at 11:23 AM, Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> wrote: > Hello! > > On 04/25/2017 06:15 PM, Jon Mason wrote: > >>>> Cygnus has a single amac controller connected to the B53 switch with 2 >>>> PHYs. On the BCM911360

Re: [PATCH 2/2] ARM: dts: Add the ethernet and ethernet PHY to the cygnus core DT.

On Tue, Apr 25, 2017 at 5:40 AM, Sergei Shtylyov wrote: > Hello. > > On 4/25/2017 12:50 AM, Eric Anholt wrote: > >> Cygnus has a single amac controller connected to the B53 switch with 2 >> PHYs. On the BCM911360_EP platform, those two PHYs are connected to >>

Re: [PATCH] net: ethernet: bgmac: Allow MAC address to be specified in DTB

TCH > net-next] or [PATCH net] in the subject, see the netdev-FAQ.txt for > details: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/netdev-FAQ.txt I believe he wants this in net-next Acked-by: Jon Mason <jo

Re: Legacy features in PCI Express devices

On 13/03/2017 18:12, Robin Murphy wrote: > On 13/03/17 16:10, Mason wrote: > >> There are two revisions of our PCI Express controller. >> >> Rev 1 did not support the following features: >> >> 1) legacy PCI interrupt delivery (INTx signals) >> 2) I

Legacy features in PCI Express devices

Hello, There are two revisions of our PCI Express controller. Rev 1 did not support the following features: 1) legacy PCI interrupt delivery (INTx signals) 2) I/O address space Internally, someone stated that such missing support would prevent some PCIe cards from working with our

Re: [PATCH net v4 0/2] net: ethernet: bgmac: bug fixes

On Thu, Mar 02, 2017 at 12:56:05PM -0800, David Miller wrote: > From: David Miller <da...@davemloft.net> > Date: Thu, 02 Mar 2017 12:50:15 -0800 (PST) > > > From: Jon Mason <jon.ma...@broadcom.com> > > Date: Tue, 28 Feb 2017 13:41:49 -0500 > > > >&

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

it out of reset regardless of whether it was in reset or not). Also, removed unnecessary usleeps (as there is already a read present to flush the IDM writes). Signed-off-by: Zac Schroff <zschr...@broadcom.com> Signed-off-by: Jon Mason <jon.ma...@broadcom.com> Fixes: f6a95a24957 (&q

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

From: Hari Vyas <ha...@broadcom.com> 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 <ha...@broadcom.com> Signed-off-b

[PATCH net v5 0/2] net: ethernet: bgmac: bug fixes

preserved (Per Rafal Mileki) * Style change to reorder the function variables in patch 2 (per Sergei Shtylyov) Bug fixes for bgmac driver Hari Vyas (1): net: ethernet: bgmac: mac address change bug Jon Mason (1): net: ethernet: bgmac: init sequence bug drivers/net/ethernet/broadcom/bgmac

[PATCH net-next v3 0/3] net: ethernet: bgmac: PM support and clean-ups

Jon Mason (2): net: ethernet: bgmac: use #defines for MAX size net: ethernet: bgmac: unify code of the same family drivers/net/ethernet/broadcom/bgmac-bcma.c | 64 +++--- drivers/net/ethernet/broadcom/bgmac-platform.c | 34 ++ drivers/net/ethernet/broadcom

[PATCH net-next v3 1/3] net: ethernet: bgmac: use #defines for MAX size

The maximum frame size is really just the standard ethernet frame size and FCS. So use those existing defines to make the code a little more beautiful. Signed-off-by: Jon Mason <jon.ma...@broadcom.com> --- drivers/net/ethernet/broadcom/bgmac.h | 2 +- 1 file changed, 1 insertion(+), 1 de

[PATCH net-next v3 3/3] net: ethernet: bgmac: driver power manangement

From: Joey Zhong <zho...@broadcom.com> Implement suspend/resume callbacks in the bgmac driver. This makes sure that we de-initialize and re-initialize the hardware correctly before entering suspend and when resuming. Signed-off-by: Joey Zhong <zho...@broadcom.com> Signed-off-b

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

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. Signed-off-by: Jon Mason <jon

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

it out of reset regardless of whether it was in reset or not). Also, removed unnecessary usleeps (as there is already a read present to flush the IDM writes). Signed-off-by: Zac Schroff <zschr...@broadcom.com> Signed-off-by: Jon Mason <jon.ma...@broadcom.com> Fixes: f6a95a24957 (&q

[PATCH net v4 0/2] net: ethernet: bgmac: bug fixes

Hari Vyas (1): net: ethernet: bgmac: mac address change bug Jon Mason (1): net: ethernet: bgmac: init sequence bug drivers/net/ethernet/broadcom/bgmac-platform.c | 27 +- drivers/net/ethernet/broadcom/bgmac.c | 6 +- drivers/net/ethernet/broadcom/bgmac.h

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

From: Hari Vyas <ha...@broadcom.com> 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 <ha...@broadcom.com> Signed-off-b

Re: [PATCH] net: bgmac: store MAC address directly in netdev->dev_addr

_enet_probe(). Instead it can > directly be stored in netdev->dev_addr. > > Also use eth_hw_addr_random() instead of eth_random_addr() in case a > random MAC is nedded. This will make sure netdev->addr_assign_type will > be properly set. > > Signed-off-by: Tobias Klauser <

[PATCH net] net: phy: Initialize mdio clock at probe function

ed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.re...@broadcom.com> Fixes: ddc24ae1 ("net: phy: Broadcom iProc MDIO bus driver") Reviewed-by: Florian Fainelli <f.faine...@gmail.com> Signed-off-by: Jon Mason <jon.ma...@broadcom.com> --- drivers/net/phy/mdio-bcm-ipr

[PATCH net v3 0/2] net: ethernet: bgmac: bug fixes

the first match to make it more obvious what portions of the register were being preserved (Per Rafal Mileki) * Style change to reorder the function variables in patch 2 (per Sergei Shtylyov) Bug fixes for bgmac driver Hari Vyas (1): net: ethernet: bgmac: mac address change bug Jon Mason (1

[PATCH net-next v2 1/3] net: ethernet: bgmac: use #defines for MAX size

The maximum frame size is really just the standard ethernet frame size and FCS. So use those existing defines to make the code a little more beautiful. Signed-off-by: Jon Mason <jon.ma...@broadcom.com> --- drivers/net/ethernet/broadcom/bgmac.h | 2 +- 1 file changed, 1 insertion(+), 1 de

[PATCH net-next v2 0/3] net: ethernet: bgmac: PM support and clean-ups

Changes in v2: * Reworked the PM patch with Florian's suggestions Add code to support Power Management (only tested on NS2), and add some code clean-ups Joey Zhong (1): net: ethernet: bgmac: driver power manangement Jon Mason (2): net: ethernet: bgmac: use #defines for MAX size net

[PATCH net-next v2 3/3] net: ethernet: bgmac: driver power manangement

From: Joey Zhong <zho...@broadcom.com> Implement suspend/resume callbacks in the bgmac driver. This makes sure that we de-initialize and re-initialize the hardware correctly before entering suspend and when resuming. Signed-off-by: Joey Zhong <zho...@broadcom.com> Signed-off-b

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

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. Signed-off-by: Jon Mason <jon

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

From: Hari Vyas <ha...@broadcom.com> 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 <ha...@broadcom.com> Signed-off-b

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

it out of reset regardless of whether it was in reset or not). Also, removed unnecessary usleeps (as there is already a read present to flush the IDM writes). Signed-off-by: Zac Schroff <zschr...@broadcom.com> Signed-off-by: Jon Mason <jon.ma...@broadcom.com> Fixes: f6a95a24957 (&q

Re: [PATCH 3/3] net: ethernet: bgmac: driver power manangement

On Fri, Feb 3, 2017 at 9:16 PM, Florian Fainelli <f.faine...@gmail.com> wrote: > On 02/03/2017 01:39 PM, Jon Mason wrote: >> From: Joey Zhong <zho...@broadcom.com> >> >> Implements suspend/resume, external phy 54810 is assumed >> to remain powered up during

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

On Fri, Feb 3, 2017 at 4:41 PM, Rafał Miłecki <ra...@milecki.pl> wrote: > 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_cl

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

On Fri, Feb 3, 2017 at 4:48 PM, Rafał Miłecki <ra...@milecki.pl> wrote: > 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 &g

[PATCH net-next 0/3] net: ethernet: bgmac: PM support and clean-ups

Add code to support Power Management (only tested on NS2), and add some code clean-ups Joey Zhong (1): net: ethernet: bgmac: driver power manangement Jon Mason (2): net: ethernet: bgmac: use #defines for MAX size net: ethernet: bgmac: unify code of the same family drivers/net/ethernet

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

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. Signed-off-by: Jon Mason <jon

[PATCH 1/3] net: ethernet: bgmac: use #defines for MAX size

The maximum frame size is really just the standard ethernet frame size and FCS. So use those existing defines to make the code a little more beautiful. Signed-off-by: Jon Mason <jon.ma...@broadcom.com> --- drivers/net/ethernet/broadcom/bgmac.h | 2 +- 1 file changed, 1 insertion(+), 1 de

[PATCH 3/3] net: ethernet: bgmac: driver power manangement

From: Joey Zhong <zho...@broadcom.com> Implements suspend/resume, external phy 54810 is assumed to remain powered up during deep-sleep for wake-on-lane. Signed-off-by: Joey Zhong <zho...@broadcom.com> Signed-off-by: Jon Mason <jon.ma...@broadcom.com> --- drivers/net/ether

  1   2   3   >