On 28 Jul 2020, at 13:27, Christoph Hellwig wrote:
On Tue, Jul 28, 2020 at 01:18:48PM -0400, Chris Mason wrote:
come after in the future.
Jonathan, I think we need to do a better job talking about patches
that are
just meant to enable possible users vs patches that we actually hope
the
On 28 Jul 2020, at 12:31, Greg KH wrote:
On Mon, Jul 27, 2020 at 03:44:44PM -0700, Jonathan Lemon wrote:
From: Jonathan Lemon
This provides the interface between the netgpu core module and the
nvidia kernel driver. This should be built as an external module,
pointing to the nvidia build. Fo
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 are built as part of
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 g
+ 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 unusua
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
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 o
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 w
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 art
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 cha
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, F
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
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 dow
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 = NULL
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
>>
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
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.)
phy_disconnect
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
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
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
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 por
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
>>
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?
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
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 resetting
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
>> +---
>
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
---
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 a/drivers/
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 n
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
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 work-a
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
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 "Etherne
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
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 work-ar
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?
>>
>> I'm
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 synchronou
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 rtnl_lock()
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
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 [
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 ab
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 m
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 dri
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 ma
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 c
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 s
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
>>> defaul
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
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 MAC
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 out a fix ASAP.
>>
> I do not s
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 masks IDM operations in case fi
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.
>>
>>
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 quirk
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 clo
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 to switch betwee
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 in
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),
>
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 rema
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&#
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
-by: Liviu Dudau
Signed-off-by: Jon Mason
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 +++-
2 files changed, 23 inserti
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
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
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
On Wed, Jun 7, 2017 at 12:18 PM, Liviu Dudau wrote:
> On Fri, Jun 02, 2017 at 02:22:51PM -0400, David Miller wrote:
>> From: Jon Mason
>> Date: Wed, 31 May 2017 15:43:30 -0400
>>
>> > use of_mdio_parse_addr() in place of an OF read of reg and a bounds
>> &g
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
---
drivers/net/phy/mdio-mux.c | 24 +---
1 file changed, 17
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
---
drivers/net/phy/mdio_bus.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a
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
>>> explicit put causes a double put.
>> ..
on. So, I am adding it where necessary to make it uniform.
Signed-off-by: Jon Mason
Fixes: f20e6657a875 ("mdio: mux: Enhanced MDIO mux framework for integrated
multiplexers")
Fixes: 0ca2997d1452 ("netdev/of/phy: Add MDIO bus multiplexer support.")
---
drivers/net/phy/mdio-m
for mdio_mux_init() which calls mdiobus_unregister() prior to
mdiobus_free().
Signed-off-by: Jon Mason
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(+), 1 deletion(-)
diff --git a/dr
On Tue, Apr 25, 2017 at 11:23 AM, Sergei Shtylyov
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_EP platform, those two PHYs are connected
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
>> the external ethernet jacks.
>
>
>
gt; 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
>> ---
>> drivers/net/ethernet/broadcom/bgmac-bcma.c | 39
>> ++
>> 1 fil
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
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 controlle
On Thu, Mar 02, 2017 at 12:56:05PM -0800, David Miller wrote:
> From: David Miller
> Date: Thu, 02 Mar 2017 12:50:15 -0800 (PST)
>
> > From: Jon Mason
> > Date: Tue, 28 Feb 2017 13:41:49 -0500
> >
> >> Changes in v4:
> >> * Added the ude
e to bring 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
Signed-off-by: Jon Mason
Fixes: f6a95a24957 ("net: ethernet: bgmac: Add platform device support
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
Signed-off-by: Jon Mason
Fixes: 4e209001b86 ("bgmac: writ
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):
net: ethernet: bgmac: init sequence bug
drivers/net/ethernet/broa
ement
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/bro
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
---
drivers/net/ethernet/broadcom/bgmac.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
From: Joey Zhong
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
Signed-off-by: Jon Mason
Reviewed-by: Florian Fainelli
---
drivers/net
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
---
drivers/net
e to bring 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
Signed-off-by: Jon Mason
Fixes: f6a95a24957 ("net: ethernet: bgmac: Add platform device support
mac 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-platform.c | 27 +-
drivers/net/ethernet/broadcom/bgmac.c | 6 +-
drivers/net/ethernet/broadc
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
Signed-off-by: Jon Mason
Fixes: 4e209001b86 ("bgmac: writ
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
Looks sane to me
Acked
Reddy
Fixes: ddc24ae1 ("net: phy: Broadcom iProc MDIO bus driver")
Reviewed-by: Florian Fainelli
Signed-off-by: Jon Mason
---
drivers/net/phy/mdio-bcm-iproc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/mdio-bcm-iproc.c b/drivers/net/phy/mdio-b
worked 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
Jo
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
---
drivers/net/ethernet/broadcom/bgmac.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
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
From: Joey Zhong
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
Signed-off-by: Jon Mason
---
drivers/net/ethernet/broadcom/bgmac
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
---
drivers/net
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
Signed-off-by: Jon Mason
Fixes: 4e209001b86 ("bgmac: writ
e to bring 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
Signed-off-by: Jon Mason
Fixes: f6a95a24957 ("net: ethernet: bgmac: Add platform device support
On Fri, Feb 3, 2017 at 9:16 PM, Florian Fainelli wrote:
> On 02/03/2017 01:39 PM, Jon Mason wrote:
>> From: Joey Zhong
>>
>> Implements suspend/resume, external phy 54810 is assumed
>> to remain powered up during deep-sleep for wake-on-lane.
>
> s/wake-on-l
On Fri, Feb 3, 2017 at 4:41 PM, Rafał Miłecki 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_clk_enable(struct bgmac *bgmac, u32 flags)
On Fri, Feb 3, 2017 at 4:48 PM, Rafał Miłecki 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
>> results in more
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
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
---
drivers/net
1 - 100 of 293 matches
Mail list logo
