Re: marvell switch

[Ran Shalit]

On Thu, Apr 5, 2018 at 11:46 PM, Andrew Lunn  wrote:
>> > Hi Ran
>> >
>> > The Marvell driver makes each port act like a normal Linux network
>> > interface. So if you want to enable a port, do
>> >
>> > ip link set lan0 up
>> >
>> > Want to add an ip address to a port
>> >
>> > ip addr add 10.42.42.42/24 dev lan0
>> >

I would please like to ask one more about it, if I may.
I thought I understood it all, but seems not.
The switch ports are connected to other PCs (except for one port which
is connected to cpu).
What is therefore the purpose of adding ip address to such ports (the
ip is configured externally in PC).

Thank you for the time,
ranran

>> > Want to bridge two ports
>> >
>> > ip link add name br0 type bridge
>> > ip link set dev br0 up
>> > ip link set dev lan0 master br0
>> > ip link set dev lan1 master br0
>> >
>> > Just treat them as normal interfaces.
>> >
>>
>> If I may please ask,
>> What is the purpose of using bridge for configuring switch interfaces.
>> Is it in order to isolate some ports from others?
>> I ask because according to my understanding the default configuration of
>> the driver is to enable switch in "flat" configuration, i.e. as if all
>> ports are connected to each other.
>
> Please think about what i said. They are standard Linux network
> interfaces. Do standard Linux network interfaces bridge themselves
> together by default? No, you need to configure a bridge.
>
>  Andrew

Re: marvell switch

[Ran Shalit]

On Thu, Apr 5, 2018 at 11:46 PM, Andrew Lunn  wrote:
>> > Hi Ran
>> >
>> > The Marvell driver makes each port act like a normal Linux network
>> > interface. So if you want to enable a port, do
>> >
>> > ip link set lan0 up
>> >
>> > Want to add an ip address to a port
>> >
>> > ip addr add 10.42.42.42/24 dev lan0
>> >
>> > Want to bridge two ports
>> >
>> > ip link add name br0 type bridge
>> > ip link set dev br0 up
>> > ip link set dev lan0 master br0
>> > ip link set dev lan1 master br0
>> >
>> > Just treat them as normal interfaces.
>> >
>>
>> If I may please ask,
>> What is the purpose of using bridge for configuring switch interfaces.
>> Is it in order to isolate some ports from others?
>> I ask because according to my understanding the default configuration of
>> the driver is to enable switch in "flat" configuration, i.e. as if all
>> ports are connected to each other.
>
> Please think about what i said. They are standard Linux network
> interfaces. Do standard Linux network interfaces bridge themselves
> together by default? No, you need to configure a bridge.
>
>  Andrew

I understand now...
Thank you very much.
ranran

Re: marvell switch

[Andrew Lunn]

> > Hi Ran
> >
> > The Marvell driver makes each port act like a normal Linux network
> > interface. So if you want to enable a port, do
> >
> > ip link set lan0 up
> >
> > Want to add an ip address to a port
> >
> > ip addr add 10.42.42.42/24 dev lan0
> >
> > Want to bridge two ports
> >
> > ip link add name br0 type bridge
> > ip link set dev br0 up
> > ip link set dev lan0 master br0
> > ip link set dev lan1 master br0
> >
> > Just treat them as normal interfaces.
> >
> 
> If I may please ask,
> What is the purpose of using bridge for configuring switch interfaces.
> Is it in order to isolate some ports from others?
> I ask because according to my understanding the default configuration of
> the driver is to enable switch in "flat" configuration, i.e. as if all
> ports are connected to each other.

Please think about what i said. They are standard Linux network
interfaces. Do standard Linux network interfaces bridge themselves
together by default? No, you need to configure a bridge.

 Andrew

Re: marvell switch

[Andrew Lunn]

On Thu, Apr 05, 2018 at 05:26:37PM +, Ran Shalit wrote:
> בתאריך יום ה׳, 5 באפר׳ 2018, 19:09, מאת Andrew Lunn ‏:
> 
> > > Is there a wiki which explains switch configuration ?
> >
> > Nope. The whole idea is that they behave like normal linux
> > interfaces. So there is no need to document them. You already know how
> > to use them.
> >
> > > Is it possible to open socket and send/recieve on switch ports (lan0
> > > for example) ?
> >
> > Sure. It is as normal interface. Give is an IP address and then do
> > TCP/IP as usual.
> >
> 
> There is something I don't fully understand.
> I thought that ports in switch which are not connected to the manage cpu
> are only configured by cpu and then can coomunicate with each other.
> 
> What does it mean to open socket in such port (not the cpu port) and send
> data (ethernet frames) ? Does it mean that the cpu port is sending data
> directly to that port ?

The CPU port is configured to use {E}DSA tagging. Frames ingressing on
the CPU port contain an extra header. That header tells the switch
which port to send the frame out of. The switch can also send frames
received on a port out the CPU port to the host, again, with a
header. The host can tell from the header which port the frame
ingressed.

Using this, we can make ports look like normal Linux interfaces.

  Andrew

Re: marvell switch

[Andrew Lunn]

> Is there a wiki which explains switch configuration ?

Nope. The whole idea is that they behave like normal linux
interfaces. So there is no need to document them. You already know how
to use them.

> Is it possible to open socket and send/recieve on switch ports (lan0
> for example) ?

Sure. It is as normal interface. Give is an IP address and then do
TCP/IP as usual.

   Andrew

Re: marvell switch

[Ran Shalit]

On Thu, Apr 5, 2018 at 3:22 PM, Andrew Lunn <and...@lunn.ch> wrote:
> On Thu, Apr 05, 2018 at 05:47:24AM +0300, Ran Shalit wrote:
>> Hello,
>>
>> I am trying to use marvell switch in linux,
>> Is it that the kernel drivers from marvell switch are used just to
>> enable all ports, or do they also provide APIs to userspace to enable
>> specific ports only.
>> I have not find examples or wiki for marvell switch, so I am not too
>> sure as what are the drivers meant for.
>
> Hi Ran
>
> The Marvell driver makes each port act like a normal Linux network
> interface. So if you want to enable a port, do
>
> ip link set lan0 up
>
> Want to add an ip address to a port
>
> ip addr add 10.42.42.42/24 dev lan0
>
> Want to bridge two ports
>
> ip link add name br0 type bridge
> ip link set dev br0 up
> ip link set dev lan0 master br0
> ip link set dev lan1 master br0
>
> Just treat them as normal interfaces.
>

Is there a wiki which explains switch configuration ?
What does it mean that they are treated as normal interfaces ?
Is it possible to open socket and send/recieve on switch ports (lan0
for example) ?
My understanding is that these ports are not treated the same as eth0
interface for example.

Thanks for the assistance,
ranran

>  Andrew

Re: marvell switch

[Andrew Lunn]

On Thu, Apr 05, 2018 at 05:47:24AM +0300, Ran Shalit wrote:
> Hello,
> 
> I am trying to use marvell switch in linux,
> Is it that the kernel drivers from marvell switch are used just to
> enable all ports, or do they also provide APIs to userspace to enable
> specific ports only.
> I have not find examples or wiki for marvell switch, so I am not too
> sure as what are the drivers meant for.

Hi Ran

The Marvell driver makes each port act like a normal Linux network
interface. So if you want to enable a port, do

ip link set lan0 up

Want to add an ip address to a port

ip addr add 10.42.42.42/24 dev lan0

Want to bridge two ports

ip link add name br0 type bridge
ip link set dev br0 up
ip link set dev lan0 master br0
ip link set dev lan1 master br0

Just treat them as normal interfaces.

 Andrew

marvell switch

[Ran Shalit]

Hello,

I am trying to use marvell switch in linux,
Is it that the kernel drivers from marvell switch are used just to
enable all ports, or do they also provide APIs to userspace to enable
specific ports only.
I have not find examples or wiki for marvell switch, so I am not too
sure as what are the drivers meant for.

Thank you,
ranran

Re: [PATCH v2 0/6] Updates for Marvell Switch SoCs

[Chris Packham]

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'd
>> been wanting. It was still based on an older kernel but it was a huge
>> improvement over what came before.
>>
>> Patch 1/6 is a typo I noticed after my initial series was applied.
>>
>> Patch 2/6 is a bit of a cleanup. I did initially struggle with how to
>> access individual parts of the DFX block as well as retaining a handle on
>> the entire thing for the switch driver to use.
>>
>> Patch 3/6 is a re-jig of the dtsi files which is needed by 5/6. This is
>> required because 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.
>
>
> I applied patches 2, 3 and 6 on mvebu/dt with the acked-by from Rob when
> he gave it.
>
> Patch 1 is already part of 4.11-rc1.
>
> For patch 4 and 5 I understand that either we don't need it or it should
> be a updated version so I skipped them.
>

That's correct, thanks.

Re: [PATCH v2 0/6] Updates for Marvell Switch SoCs

[Gregory CLEMENT]

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'd
> been wanting. It was still based on an older kernel but it was a huge
> improvement over what came before.
>
> Patch 1/6 is a typo I noticed after my initial series was applied.
>
> Patch 2/6 is a bit of a cleanup. I did initially struggle with how to
> access individual parts of the DFX block as well as retaining a handle on
> the entire thing for the switch driver to use.
>
> Patch 3/6 is a re-jig of the dtsi files which is needed by 5/6. This is
> required because 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.


I applied patches 2, 3 and 6 on mvebu/dt with the acked-by from Rob when
he gave it.

Patch 1 is already part of 4.11-rc1.

For patch 4 and 5 I understand that either we don't need it or it should
be a updated version so I skipped them.

Thanks,

Gregory

>
> Chris Packham (6):
>   ARM: dts: Fix typo in armada-xp-98dx4251
> Changes in v2
> - new
> Changes in v3:
> - none
>   ARM: dts: armada-xp-98dx3236: combine dfx server nodes
> Changes in v2:
> - none
> Changes in v3:
> - none
>   ARM: dts: Use armada-370-xp as a base for armada-xp-98dx3236
> Changes in v2:
> - Update root compatible strings in armada-xp-98dx3336.dtsi,
>   armada-xp-98dx4251.dtsi, armada-xp-db-dxbc2.dts and
>   armada-xp-db-xc3-24g4xg.dts
> Changes in v3:
> - none
>   ARM: dts: mvebu: Add binding for mv98dx3236-soc-id
> Changes in v3:
> - new, split from driver
>   ARM: mvebu: Add driver for mv98dx3236-soc-id
> Changes in v2:
> - none
> Changes in v3:
> - split from dts changes
>   ARM: dts: mvebu: Move mv98dx3236 clock bindings
> Changes in v2:
> - New. Split out from "clk: mvebu: Expand mv98dx3236-core-clock support"
> Changes in v3:
> - Clarify why the old location was wrong (but worked).
>
>
>  .../bindings/arm/marvell/mv98dx3236-soc-id.txt |  14 ++
>  .../devicetree/bindings/clock/mvebu-core-clock.txt |   7 +
>  .../bindings/clock/mvebu-gated-clock.txt   |  11 ++
>  .../devicetree/bindings/net/marvell,prestera.txt   |  13 +-
>  arch/arm/boot/dts/armada-xp-98dx3236.dtsi  | 213 
> -
>  arch/arm/boot/dts/armada-xp-98dx3336.dtsi  |   2 +-
>  arch/arm/boot/dts/armada-xp-98dx4251.dtsi  |   2 +-
>  arch/arm/boot/dts/armada-xp-db-dxbc2.dts   |   2 +-
>  arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts  |   2 +-
>  arch/arm/mach-mvebu/mvebu-soc-id.c |  43 -
>  10 files changed, 242 insertions(+), 67 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/arm/marvell/mv98dx3236-soc-id.txt
>
> -- 
> 2.11.0.24.ge6920cf

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[PATCH v2 0/6] Updates for Marvell Switch SoCs

[Chris Packham]

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'd
been wanting. It was still based on an older kernel but it was a huge
improvement over what came before.

Patch 1/6 is a typo I noticed after my initial series was applied.

Patch 2/6 is a bit of a cleanup. I did initially struggle with how to
access individual parts of the DFX block as well as retaining a handle on
the entire thing for the switch driver to use.

Patch 3/6 is a re-jig of the dtsi files which is needed by 5/6. This is
required because 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: dts: Fix typo in armada-xp-98dx4251
Changes in v2
- new
Changes in v3:
- none
  ARM: dts: armada-xp-98dx3236: combine dfx server nodes
Changes in v2:
- none
Changes in v3:
- none
  ARM: dts: Use armada-370-xp as a base for armada-xp-98dx3236
Changes in v2:
- Update root compatible strings in armada-xp-98dx3336.dtsi,
  armada-xp-98dx4251.dtsi, armada-xp-db-dxbc2.dts and
  armada-xp-db-xc3-24g4xg.dts
Changes in v3:
- none
  ARM: dts: mvebu: Add binding for mv98dx3236-soc-id
Changes in v3:
- new, split from driver
  ARM: mvebu: Add driver for mv98dx3236-soc-id
Changes in v2:
- none
Changes in v3:
- split from dts changes
  ARM: dts: mvebu: Move mv98dx3236 clock bindings
Changes in v2:
- New. Split out from "clk: mvebu: Expand mv98dx3236-core-clock support"
Changes in v3:
- Clarify why the old location was wrong (but worked).


 .../bindings/arm/marvell/mv98dx3236-soc-id.txt |  14 ++
 .../devicetree/bindings/clock/mvebu-core-clock.txt |   7 +
 .../bindings/clock/mvebu-gated-clock.txt   |  11 ++
 .../devicetree/bindings/net/marvell,prestera.txt   |  13 +-
 arch/arm/boot/dts/armada-xp-98dx3236.dtsi  | 213 -
 arch/arm/boot/dts/armada-xp-98dx3336.dtsi  |   2 +-
 arch/arm/boot/dts/armada-xp-98dx4251.dtsi  |   2 +-
 arch/arm/boot/dts/armada-xp-db-dxbc2.dts   |   2 +-
 arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts  |   2 +-
 arch/arm/mach-mvebu/mvebu-soc-id.c |  43 -
 10 files changed, 242 insertions(+), 67 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/marvell/mv98dx3236-soc-id.txt

-- 
2.11.0.24.ge6920cf

[PATCH v2 0/6] Updates for Marvell Switch SoCs

[Chris Packham]

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'd
been wanting. It was still based on an older kernel but it was a huge
improvement over what came before.

Patch 1/6 is a typo I noticed after my initial series was applied.

Patch 2/6 is a bit of a cleanup. I did initially struggle with how to
access individual parts of the DFX block as well as retaining a handle on
the entire thing for the switch driver to use.

Patch 3/6 is a re-jig of the dtsi files which is needed by 5/6. This is
required because 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.

Chris Packham (6):
  ARM: dts: Fix typo in armada-xp-98dx4251
Changes in v2:
- new
  ARM: dts: armada-xp-98dx3236: combine dfx server nodes
Changes in v2:
- none
  ARM: dts: Use armada-370-xp as a base for armada-xp-98dx3236
Changes in v2:
- Update root compatible strings in armada-xp-98dx3336.dtsi,
  armada-xp-98dx4251.dtsi, armada-xp-db-dxbc2.dts and
  armada-xp-db-xc3-24g4xg.dts
  ARM: mvebu: Add mv98dx3236-soc-id
Changes in v2:
- none
  ARM: dts: mvebu: Move mv98dx3236 clock bindings
Changes in v2:
- New. Split out from "clk: mvebu: Expand mv98dx3236-core-clock support"
  clk: mvebu: Expand mv98dx3236-core-clock support
Changes in v2:
- split dts updates into separate patch
- add 98DX4251 specific support

 .../bindings/arm/marvell/mv98dx3236-soc-id.txt |  14 ++
 .../devicetree/bindings/clock/mvebu-core-clock.txt |   7 +
 .../bindings/clock/mvebu-gated-clock.txt   |  11 ++
 .../devicetree/bindings/net/marvell,prestera.txt   |  13 +-
 arch/arm/boot/dts/armada-xp-98dx3236.dtsi  | 211 -
 arch/arm/boot/dts/armada-xp-98dx3336.dtsi  |   2 +-
 arch/arm/boot/dts/armada-xp-98dx4251.dtsi  |   2 +-
 arch/arm/boot/dts/armada-xp-db-dxbc2.dts   |   2 +-
 arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts  |   2 +-
 arch/arm/mach-mvebu/mvebu-soc-id.c |  43 -
 drivers/clk/mvebu/Makefile |   2 +-
 drivers/clk/mvebu/armada-xp.c  |  13 --
 drivers/clk/mvebu/mv98dx3236.c | 180 ++
 13 files changed, 422 insertions(+), 80 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/marvell/mv98dx3236-soc-id.txt
 create mode 100644 drivers/clk/mvebu/mv98dx3236.c

-- 
2.11.0.24.ge6920cf

[PATCH 0/4] Updates for Marvell Switch SoCs

[Chris Packham]

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'd
been wanting. It was still based on an older kernel but it was a huge
improvement over what came before.

Patch 1/4 is a bit of a cleanup. I did initially struggle with how to
access individual parts of the DFX block as well as retaining a handle on
the entire thing for the switch driver to use.

Patch 2/4 is a re-jig of the dtsi files which is needed by 4/4. This is
required because 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 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 nodes
  ARM: dts: Use armada-370-xp as a base for armada-xp-98dx3236
  ARM: mvebu: Add mv98dx3236-soc-id
  clk: mvebu: Expand mv98dx3236-core-clock support

 .../bindings/arm/marvell/mv98dx3236-soc-id.txt |  14 ++
 .../devicetree/bindings/clock/mvebu-core-clock.txt |   7 +
 .../bindings/clock/mvebu-gated-clock.txt   |  11 ++
 .../devicetree/bindings/net/marvell,prestera.txt   |  13 +-
 arch/arm/boot/dts/armada-xp-98dx3236.dtsi  | 211 -
 arch/arm/mach-mvebu/mvebu-soc-id.c |  43 -
 drivers/clk/mvebu/Makefile |   2 +-
 drivers/clk/mvebu/armada-xp.c  |  13 --
 drivers/clk/mvebu/mv98dx3236.c | 144 ++
 9 files changed, 382 insertions(+), 76 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/marvell/mv98dx3236-soc-id.txt
 create mode 100644 drivers/clk/mvebu/mv98dx3236.c

-- 
2.11.0.24.ge6920cf