This was added in commit ce973b141dfa ("[PATCH] Freescale QE UCC gigabit
ethernet driver") but doesn't appear to have been used. Remove it now.
Signed-off-by: Chris Packham
---
drivers/net/ethernet/freescale/ucc_geth.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drive
-by: Chris Packham
Reviewed-by: Andrew Lunn
---
Changes in v5:
- Add review from Andrew.
Changes in v4:
- new
drivers/net/dsa/mv88e6xxx/serdes.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c
b/drivers/net/dsa/mv88e6xxx
interrupts for serdes events so unlike
earlier commits the functions added here are specific to the MV88E6097.
Signed-off-by: Chris Packham
---
Changes in v5:
- New
drivers/net/dsa/mv88e6xxx/chip.c | 3 ++
drivers/net/dsa/mv88e6xxx/serdes.c | 47 ++
drivers/net
ink state
changes because we're forcing the link.
To address this introduce a new device specific op port_sync_link() and
push the logic from mv88e6xxx_mac_link_up() into that. Provide an
implementation for the 88E6185 like devices which doesn't force the
link.
Signed-off-by: Chris P
Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for
the MV88E6097/6095/6185 so that ports 8 & 9 can be supported as serdes
ports and directly connected to other network interfaces or to SFPs
without a PHY.
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
Change
ing a new device specific op either this series will
need updating to cover the mv88e6393x or the mv88e6393x series will need
updating for the new op depenting on which lands first.
Chris Packham (4):
net: dsa: mv88e6xxx: Don't force link when using in-band-status
net: dsa: mv88e6xxx: Supp
Hi Vadym,
We (Allied Telesis) have got some funding for a university student (i.e.
an intern) over the southern hemisphere summer (~ Nov-Feb). I was going
to have them do a little research into switchdev, specifically the
Prestera AC3x support you recently landed upstream.
We've got a Marvell
On 24/10/20 11:42 am, Andrew Lunn wrote:
>> +int mv88e6123_serdes_get_regs_len(struct mv88e6xxx_chip *chip, int port)
>> +{
>> +if (mv88e6xxx_serdes_get_lane(chip, port) == 0)
>> +return 0;
>> +
>> +return 26 * sizeof(u16);
>> +}
> Hi Chris
>
> Where did 26 come from?
In the 88
Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for
the MV88E6097/6095/6185 so that ports 8 & 9 can be supported as serdes
ports and directly connected to other network interfaces or to SFPs
without a PHY.
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
Change
patch #4 in this series but I don't have anything to test it on.
It's just a guess based on the datasheets. I'd suggest applying patch 1, 2 & 3
and leaving 4 for the mailing list archives.
Chris Packham (4):
net: dsa: mv88e6xxx: Don't force link when using in-band
-by: Chris Packham
---
Changes in v4:
- new
drivers/net/dsa/mv88e6xxx/serdes.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c
b/drivers/net/dsa/mv88e6xxx/serdes.c
index d4f40a739b17..ec9ca7210bb0 100644
--- a/drivers/net/dsa
e link link state
changes because we're forcing the link.
To address this introduce a new device specific op port_sync_link() and
push the logic from mv88e6xxx_mac_link_up() into that. Provide an
implementation for the 88E6185 like devices which doesn't force the
link.
Signed-off-by: Chris Pack
.
Signed-off-by: Chris Packham
---
This is untested (apart from compilation) it assumes the SERDES "phy"
address corresponds to the port number but I'm not confident that is a
valid assumption.
Changes in v4:
- Error handling in mv88e6123_serdes_get_regs
Changes in v3:
- None
Chang
On 21/10/20 10:18 am, Russell King - ARM Linux admin wrote:
> On Tue, Oct 20, 2020 at 09:06:32PM +0000, Chris Packham wrote:
>> On 21/10/20 3:51 am, Marek Behun wrote:
>>> On Tue, 20 Oct 2020 15:15:25 +0100
>>> Russell King - ARM Linux admin wrote:
>>>
>
On 20/10/20 11:18 pm, Russell King - ARM Linux admin wrote:
> On Tue, Oct 20, 2020 at 04:45:58PM +1300, Chris Packham wrote:
>> +void mv88e6123_serdes_get_regs(struct mv88e6xxx_chip *chip, int port, void
>> *_p)
>> +{
>> +u16 *p = _p;
>> +u16 re
; On Tue, 20 Oct 2020 11:15:52 +0100
>>>> Russell King - ARM Linux admin wrote:
>>>>
>>>>> On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote:
>>>>>> When a port is configured with 'managed = "in-band-status"'
On 21/10/20 3:58 am, Andrew Lunn wrote:
>>> It's still there. The speed/duplex etc are read from the serdes PHY
>>> via mv88e6390_serdes_pcs_get_state(). When the link comes up, we
>>> pass the negotiated link parameters read from there to the link_up()
>>> functions. For ports where mv88e6xxx_por
patch #3 in this series but I don't have anything to test it on.
It's just a guess based on the datasheets. I'd suggest applying patch 1 & 2
and leaving 3 for the mailing list archives.
Chris Packham (3):
net: dsa: mv88e6xxx: Don't force link when using in-band-status
Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for
the MV88E6097/6095/6185 so that ports 8 & 9 can be supported as serdes
ports and directly connected to other network interfaces or to SFPs
without a PHY.
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
Change
When a port is configured with 'managed = "in-band-status"' don't force
the link up, the switch MAC will detect the link status correctly.
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
Changes in v3:
- None
Changes in v2:
- Add review from Andrew
drivers
.
Signed-off-by: Chris Packham
---
This is untested (apart from compilation) it assumes the SERDES "phy"
address corresponds to the port number but I'm not confident that is a
valid assumption.
Changes in v3:
- None
Changes in v2:
- new
drivers/net/dsa/mv88e6xxx/chip.c | 10 +
On 19/10/20 11:31 am, Chris Packham wrote:
>
> On 19/10/20 11:08 am, Andrew Lunn wrote:
>> On Sun, Oct 18, 2020 at 09:15:52PM +, Chris Packham wrote:
>>> On 19/10/20 9:25 am, Andrew Lunn wrote:
>>>>> I assume you're talking about the PHY Control Reg
.
Signed-off-by: Chris Packham
---
This is untested (apart from compilation) it assumes the SERDES "phy"
address corresponds to the port number but I'm not confident that is a
valid assumption.
Changes in v2:
- new
drivers/net/dsa/mv88e6xxx/chip.c | 10 +++
drivers/ne
When a port is configured with 'managed = "in-band-status"' don't force
the link up, the switch MAC will detect the link status correctly.
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
Changes in v2:
- Add review from Andrew
drivers/net/dsa/mv88e6xxx/c
patch #3 in this series but I don't have anything to test it on.
It's just a guess based on the datasheets.
Chris Packham (3):
net: dsa: mv88e6xxx: Don't force link when using in-band-status
net: dsa: mv88e6xxx: Support serdes ports on MV88E6097/6095/6185
net: dsa: mv88
Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for
the MV88E6097/6095/6185 so that ports 8 & 9 can be supported as serdes
ports and directly connected to other network interfaces or to SFPs
without a PHY.
Signed-off-by: Chris Packham
---
Changes in v2:
- expand suppor
On 19/10/20 11:08 am, Andrew Lunn wrote:
> On Sun, Oct 18, 2020 at 09:15:52PM +0000, Chris Packham wrote:
>> On 19/10/20 9:25 am, Andrew Lunn wrote:
>>>> I assume you're talking about the PHY Control Register 0 bit 11. If so
>>>> that's for the internal
On 19/10/20 9:25 am, Andrew Lunn wrote:
>> I assume you're talking about the PHY Control Register 0 bit 11. If so
>> that's for the internal PHYs on ports 0-7. Ports 8, 9 and 10 don't have
>> PHYs.
> Hi Chris
>
> I have a datasheet for the 6122/6121, from some corner of the web,
> Part 3 of 3, Gig
On 19/10/20 5:16 am, Andrew Lunn wrote:
> On Tue, Oct 13, 2020 at 03:18:58PM +1300, Chris Packham wrote:
>> Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for
>> the MV88E6097 so that ports 8 & 9 can be supported as serdes ports and
>> directly c
When a port is configured with 'managed = "in-band-status"' don't force
the link up, the switch MAC will detect the link status correctly.
Signed-off-by: Chris Packham
---
drivers/net/dsa/mv88e6xxx/chip.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
dif
Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for
the MV88E6097 so that ports 8 & 9 can be supported as serdes ports and
directly connected to other network interfaces or to SFPs without a PHY.
Signed-off-by: Chris Packham
---
This should be usable for all variants of
This small series gets my hardware into a working state. The key points are to
make sure we don't force the link and that we ask the MAC for the link status.
I also have updated my dts to say `phy-mode = "1000base-x";` and `managed =
"in-band-status";`
Chris Packham (
On 2/10/20 1:36 am, Andrew Lunn wrote:
>>> Can you run 1000Base-X over these links?
>> With some reading "1000base-x" does seem the right thing to say here.
>> It's even what is reflected in the CMODE field for those ports.
> One more thing you might need is
>
> managed = "in-band-status";
>
>>> I
On 1/10/20 2:24 pm, Andrew Lunn wrote:
>> port@8 {
>> reg = <8>;
>> label = "internal8";
>> phy-mode = "rgmii-id";
>> fixed-link {
>>
Hi,
We have a chassis platform that (ab)uses an Ethernet backplane
consisting of MV88E6097 on the line cards connecting to a MV98DX160 on
the chassis controller(s).
I'm attempting to update the line cards to a modern kernel trying to do
away with a lot of custom hackery from our older kernel.
Hi Vadym,
On 26/08/20 12:20 am, Vadym Kochan wrote:
> Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8
> ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely
> wireless SMB deployment.
I think there's a typo here or possibly in patch 1. The AC3x family has
model nu
Some of the chips in the mv88e6xxx family don't support jumbo
configuration per port. But they do have a chip-wide max frame size that
can be used. Use this to approximate the behaviour of configuring a port
based MTU.
Signed-off-by: Chris Packham
---
The only hardware I have access to u
: dsa: mv88e6xxx: Refactor setting of jumbo frames")
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
Changes in v2:
- Add review from Andrew
drivers/net/dsa/mv88e6xxx/chip.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6
ch 1 and 2 are unchanged (aside from adding
Andrew's Reviewed-by). Patch 3 is reworked to make use of the existing mtu
support.
Chris Packham (3):
net: dsa: mv88e6xxx: MV88E6097 does not support jumbo configuration
net: dsa: mv88e6xxx: Support jumbo configuration on 6190/6190X
net: dsa:
The MV88E6190 and MV88E6190X both support per port jumbo configuration
just like the other GE switches. Install the appropriate ops.
Signed-off-by: Chris Packham
Reviewed-by: Andrew Lunn
---
I'm including this change in my series for completeness. Looking at the
datasheets I think this
Hi Marek,
On 24/07/20 2:46 am, Marek Behún wrote:
> Hi,
>
> a customer of ours filed a ticket saying that when using upstream kernel
> (5.8.0-rc6 on Debian 10) on Turris MOX (88e6190 switch) with DSA with
> default configuration, the switch is losing DHCPv6 solicit packets /
> IPv6 multicast packe
On 24/07/20 9:02 am, Andrew Lunn wrote:
> On Thu, Jul 23, 2020 at 08:50:27PM +0000, Chris Packham wrote:
>> On 24/07/20 1:31 am, Andrew Lunn wrote:
>>> On Thu, Jul 23, 2020 at 03:59:41PM +1200, Chris Packham wrote:
>>>> Add implementations for the mv88e6xx
On 24/07/20 1:34 am, Andrew Lunn wrote:
> On Thu, Jul 23, 2020 at 03:59:42PM +1200, Chris Packham wrote:
>> Some of the chips in the mv88e6xxx family don't support jumbo
>> configuration per port. But they do have a chip-wide max frame size that
>> can be used. U
On 24/07/20 1:31 am, Andrew Lunn wrote:
> On Thu, Jul 23, 2020 at 03:59:41PM +1200, Chris Packham wrote:
>> Add implementations for the mv88e6xxx switches to connect with the
>> generic dsa operations for configuring the port MTU.
> Hi Chris
>
> What tree is th
Some of the chips in the mv88e6xxx family don't support jumbo
configuration per port. But they do have a chip-wide max frame size that
can be used. Use this to approximate the behaviour of configuring a port
based MTU.
Signed-off-by: Chris Packham
---
The only hardware I have access to u
This series connects up the mv88e6xxx switches to the dsa infrastructure for
configuring the port MTU. The first patch is also a bug fix which might be a
candiatate for stable.
Chris Packham (4):
net: dsa: mv88e6xxx: MV88E6097 does not support jumbo configuration
net: dsa: mv88e6xxx: Support
The MV88E6190 and MV88E6190X both support per port jumbo configuration
just like the other GE switches. Install the appropriate ops.
Signed-off-by: Chris Packham
---
I'm including this change in my series for completeness. Looking at the
datasheets I think this is an unintentional omissio
Add implementations for the mv88e6xxx switches to connect with the
generic dsa operations for configuring the port MTU.
Signed-off-by: Chris Packham
---
drivers/net/dsa/mv88e6xxx/chip.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx
: dsa: mv88e6xxx: Refactor setting of jumbo frames")
Signed-off-by: Chris Packham
---
drivers/net/dsa/mv88e6xxx/chip.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 7627ea61e0ea..fbfa4087eb7b 100644
--- a/drive
e tried again later.
>
> Cc: Sunil Goutham
> Cc: Robert Richter
> Cc: Chris Packham
> Cc: Greg Kroah-Hartman
> Signed-off-by: Andrew Lunn
Gave this a quick spin on one of our boards using the Octeon SoC. Looks
good to me
Tested-by: Chris Packham
> ---
> d
Change 'handeled' to 'handled'.
Signed-off-by: Chris Packham
---
kernel/bpf/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 916f5132a984..1ff8e73e9b12 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.
Change 'handeled' to 'handled' in the Kconfig help for SCTP.
Signed-off-by: Chris Packham
---
net/sctp/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/Kconfig b/net/sctp/Kconfig
index 6e2eb1dd64ed..68934438ee19 100644
--- a/net/sctp/Kc
Hi,
I'm exercising a bit of paranoia trying to find the canonical source for
iputils.
Our internal build system is currently been pointing to skbuff.net[1].
This appears to now be out of date there hasn't been a new tarball since
December 2015.
It looks like the tarballs have moved to github[
On 7/03/19 9:20 AM, Brodie Greenfield wrote:
> We want to be able to keep more spaces available in our queue for
> processing incoming IPv6 multicast traffic (adding (S,G) entries) - this
> lets us learn more groups faster, rather than dropping them at this stage.
>
> Signed-off-by: Brodie Greenfi
a PonCat3 platform build on nativ linux instead of using Marvell:s
>> CPSS suite (beast).
>>
>> But have some problems regarding the network.
>>
>> We also have the DB-XC3-24G4XG development board from Marvell.
>
> I'm adding Chris Packham in Cc, who added t
Two typos in switchdev.txt
Signed-off-by: Chris Packham
---
Documentation/networking/switchdev.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/switchdev.txt
b/Documentation/networking/switchdev.txt
index 3e7b946dea27..5e40e1f68873 100644
Hi Gregory,
On 08/03/17 06:10, Gregory CLEMENT wrote:
> Hi Chris,
>
> On jeu., févr. 16 2017, Chris Packham
> wrote:
>
>> Shortly after I posted my last series I got access to a more recent
>> Marvell SDK which had some device tree support for the switch SoCs I'
retain a backwards compatible binding.
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- none
Changes in v3:
- update commit message to indicate backwards incompatible change and
why it's OK
- retain dfx-server compatible string
Documentation/devicetree/bin
use I need to use the coreclk label on a different node. It
also means I don't have to disable nodes for blocks that only exist on
the Armada-XP.
Patch 4/6, 5/6 are split from the previous versions.
Patch 6/6 is the device tree portion of a change already in clk-next.
Chris Packham (6):
ARM
use I need to use the coreclk label on a different node. It
also means I don't have to disable nodes for blocks that only exist on
the Armada-XP.
Patch 4/6, 5/6 and 6/6 are ported from the Marvell Linux kernel. I've tested
them on the hardware I have access to and things look pretty good.
C
Rather than having a separate node for the dfx server add a reg property
to the parent node. This give somes compatibility with the Marvell
supplied SDK.
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- none
Documentation/devicetree/bindings/net/marvell,prestera.txt | 13
ans I don't have to disable nodes for blocks that only exist on
the Armada-XP.
Patch 3/4 and 4/4 are ported from the Marvell Linux kernel. I've tested
them on the hardware I have access to and things look pretty good.
Chris Packham (4):
ARM: dts: armada-xp-98dx3236: combine dfx server n
Rather than having a separate node for the dfx server add a reg property
to the parent node. This give somes compatibility with the Marvell
supplied SDK.
Signed-off-by: Chris Packham
---
Documentation/devicetree/bindings/net/marvell,prestera.txt | 13 +
arch/arm/boot/dts/armada-xp
The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
with integrated CPUs. They are similar to the Armada XP SoCs but have
different I/O interfaces.
Signed-off-by: Chris Packham
Acked-by: Rob Herring
---
Notes:
Changes in v2:
- Update devicetree binding documentation
The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
with integrated CPUs. They are similar to the Armada XP SoCs but have
different I/O interfaces.
Signed-off-by: Chris Packham
Acked-by: Rob Herring
---
Notes:
Changes in v2:
- Update devicetree binding documentation
On 27/01/17 09:24, Chris Packham wrote:
> On 27/01/17 04:10, Gregory CLEMENT wrote:
>>> + internal-regs {
>
> [snip]
>
>>> +
>>> + dfx-registers {
>> node label
>>
>
> [snip]
>
>>> + switch {
>>
On 27/01/17 04:10, Gregory CLEMENT wrote:
>> +internal-regs {
[snip]
>> +
>> +dfx-registers {
> node label
>
[snip]
>> +switch {
> node label
>
These are peers to the internal-regs, i.e. parts of the SoC with
mappable windows in the address space. Do they r
On 27/01/17 04:10, Gregory CLEMENT wrote:
> Hi Chris,
>
> On ven., janv. 06 2017, Chris Packham
> wrote:
>
>> The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
>> with integrated CPUs. They are similar to the Armada XP SoCs but have
>> dif
The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
with integrated CPUs. They are similar to the Armada XP SoCs but have
different I/O interfaces.
Signed-off-by: Chris Packham
Acked-by: Rob Herring
---
Notes:
Changes in v2:
- Update devicetree binding documentation
The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
with integrated CPUs. They are similar to the Armada XP SoCs but have
different I/O interfaces.
Signed-off-by: Chris Packham
---
Changes in v2:
- Update devicetree binding documentation to reflect that 98DX3336 and
package as the switch.
Chris Packham (4):
clk: mvebu: support for 98DX3236 SoC
Changes in v2:
- Update devicetree binding documentation for new compatible string
Changes in v3:
- Add 98dx3236 support to mvebu/clk-corediv.c rather than creating a
new driver.
- Document
The assignment of rth->dst.output in vrf_rt6_create() and
vrf_rtable_create() used a hard tab before the '='. The neighboring
assignments did not. Make the assignment of rth->dst.output consistent
with the surrounding code.
Signed-off-by: Chris Packham
---
drivers/net/vrf.c
Hi Florian,
On 07/31/2015 01:51 PM, Florian Fainelli wrote:
> On 30/07/15 15:51, David Miller wrote:
>> From: David Miller
>> Date: Thu, 30 Jul 2015 14:19:35 -0700 (PDT)
>>
>>> This looks fine, series applied, thanks.
>>
>> I think your control block is too large, you'll need to rework this
>> so
73 matches
Mail list logo
