Hello Ioana,
On Thu, 23 May 2019 01:20:36 +
Ioana Ciornei wrote:
>Following two separate discussion threads in:
> https://www.spinics.net/lists/netdev/msg569087.html
>and:
> https://www.spinics.net/lists/netdev/msg570450.html
>
>PHYLINK was reworked in order to add a new "raw" interface, a
0, who both have the same
register at the same location, at are potentially subject to the same
issue.
Tested-by: Maxime Chevallier
Thanks,
Maxime
p2, is
there a reason for that ?
Other than that, for the mvpp2 part,
Reviewed-by: Maxime Chevallier
Tested-by: Maxime Chevallier
Thanks,
Maxime
gt;@@ -5107,7 +5137,6 @@ static int mvpp2_port_probe(struct platform_device *pdev,
> dev->netdev_ops = &mvpp2_netdev_ops;
> dev->ethtool_ops = &mvpp2_eth_tool_ops;
>
>- port = netdev_priv(dev);
> port->dev = dev;
> port->fwnode = port_fwnode;
> port->has_phy = !!of_find_property(port_node, "phy", NULL);
>@@ -5144,7 +5173,6 @@ static int mvpp2_port_probe(struct platform_device *pdev,
>
> port->of_node = port_node;
> port->phy_interface = phy_mode;
>- port->comphy = comphy;
>
> if (priv->hw_version == MVPP21) {
> port->base = devm_platform_ioremap_resource(pdev, 2 + id);
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Hello everyone,
I'm reaching out to discuss an issue I'm currently having, while working
on a Marvell 88E1543 PHY.
This PHY is very similar to the 88E1545 we already support upstream, but
with an added "dual-port mode" feature that I'm currently using in a
project, and that might be interesting t
Hello Russell,
On Thu, 19 Nov 2020 14:55:00 +
Russell King - ARM Linux admin wrote:
>On Thu, Nov 19, 2020 at 03:22:46PM +0100, Maxime Chevallier wrote:
>> Hello everyone,
>>
>> I'm reaching out to discuss an issue I'm currently having, while working
>>
the MUX in the MAC?
No, it's my schematic that is misleading in that case :) The 2
ports are independent of each other. There isn't any configuration on
the MAC part for that setup.
Thanks,
Maxime
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Hi Tobias,
On Fri, 20 Nov 2020 01:11:12 +0100
Tobias Waldekranz wrote:
>On Thu, Nov 19, 2020 at 23:16, Russell King - ARM Linux admin
> wrote:
>> On Thu, Nov 19, 2020 at 11:43:39PM +0100, Tobias Waldekranz wrote:
>>> On Thu, Nov 19, 2020 at 16:24, Maxime Chevallier
Hi Russell, Andrew,
On Fri, 20 Nov 2020 14:55:17 +0100
Andrew Lunn wrote:
>On Fri, Nov 20, 2020 at 10:25:38AM +, Russell King - ARM Linux admin wrote:
>> On Fri, Nov 20, 2020 at 10:36:01AM +0100, Maxime Chevallier wrote:
>> > So maybe we could be a bit more generic, wi
the CPUs in
the system, both in the init path and in the cpu_hotplug path.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvneta.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c
b/drivers/net/ethernet/marvell
Implement a basic MQPrio support, inserting rules in RX that translate
the TC to prio mapping into vlan prio to queues.
The TX logic stays the same as when we don't offload the qdisc.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvneta.c | 65 +
ements the MQPrio offloading for the receive path.
Thanks !
Maxime
Maxime Chevallier (2):
net: mvneta: Remove per-cpu queue mapping for Armada 3700
net: mvneta: Implement mqprio support
drivers/net/ethernet/marvell/mvneta.c | 74 ++-
1 file changed, 73 insertions(+),
arking
>this commit with Fixes line? E.g.:
>
>Fixes: 2636ac3cc2b4 ("net: mvneta: Add network support for Armada 3700
> SoC")
Yes you're correct, I'll add that to the V2 !
Thanks for the review,
Maxime
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Hi Andrew,
On Sat, 13 Feb 2021 20:45:25 +0100
Andrew Lunn wrote:
>On Fri, Feb 12, 2021 at 04:12:20PM +0100, Maxime Chevallier wrote:
>> +static void mvneta_setup_rx_prio_map(struct mvneta_port *pp)
>> +{
>> +int i;
>> +u32 val = 0;
>
>Hi Maxime
>
the CPUs in
the system, both in the init path and in the cpu_hotplug path.
Fixes: 2636ac3cc2b4 ("net: mvneta: Add network support for Armada 3700 SoC")
Signed-off-by: Maxime Chevallier
---
V2: Added Fixes tag, as per Pali's review
drivers/net/ethernet/marvell/mvneta.c | 9 -
left to be dealt with.
The second patch implements the MQPrio offloading for the receive path.
Changes in V2 :
- Add a Fixes tag for the first patch
- Fix some warnings and the xmas tree in the second patch
Thanks,
Maxime
Maxime Chevallier (2):
net: mvneta: Remove per-cpu queue mapping for A
Implement a basic MQPrio support, inserting rules in RX that translate
the TC to prio mapping into vlan prio to queues.
The TX logic stays the same as when we don't offload the qdisc.
Signed-off-by: Maxime Chevallier
---
V2 : Fixed the reverse xmas tree, as per Andrew's review.
Hello Nathan,
On Thu, 13 Jun 2019 10:53:05 -0700
Nathan Huckleberry wrote:
>Hey all,
>
>I'm looking into cleaning up ignored warnings in the kernel so we can
>remove compiler flags to ignore warnings.
>
>There's an unused variable 'mvpp2_dbgfs_prs_pmap_fops' in
>mvpp2_debugfs.c. It looks like th
PPv2 TX/RX descriptors uses 40bits DMA addresses, but 41 bits masks were
used (GENMASK_ULL(40, 0)).
This commit fixes that by using the correct mask.
Fixes: e7c5359f2eed ("net: mvpp2: introduce PPv2.2 HW descriptors and adapt
accessors")
Signed-off-by: Maxime Chevallier
---
d
ment for finding the root cause of this bug.
Maxime Chevallier (3):
net: mvpp2: Fix clk error path in mvpp2_probe
net: mvpp2: Fix clock resource by adding missing mg_core_clk
ARM64: dts: marvell: armada-cp110: Add clocks for the xmdio node
.../devicetree/bindings/net/marvell-pp2.txt
ation")
Signed-off-by: Maxime Chevallier
---
arch/arm64/boot/dts/marvell/armada-cp110.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110.dtsi
b/arch/arm64/boot/dts/marvell/armada-cp110.dtsi
index 6c137ac656e9..ed2f1237ea1e 100644
--- a/arch/arm6
f4 ("clk: mvebu: cp110: Fix clock tree representation")
Signed-off-by: Maxime Chevallier
---
.../devicetree/bindings/net/marvell-pp2.txt | 9 +
arch/arm64/boot/dts/marvell/armada-cp110.dtsi| 5 +++--
drivers/net/ethernet/marvell/mvpp2.c | 20
When clk_prepare_enable fails for the axi_clk, the mg_clk isn't properly
cleaned up. Add another jump label to handle that case, and make sure we
jump to it in the later error cases.
Fixes: 4792ea04bcd0 ("net: mvpp2: Fix clock resource by adding an optional bus
clock")
Signed
Hi Gregory,
On Wed, 25 Apr 2018 13:43:14 +0200
Gregory CLEMENT wrote:
>Hi Maxime,
>
> On mer., avril 25 2018, Maxime Chevallier
> wrote:
>
>> Marvell's PPv2.2 IP needs an additional clock named "MG Core clock".
>> This is required on Armada 7K and 8K.
Marvell's PPv2.2 IP needs an additional clock named "MG Core clock".
This is required on Armada 7K and 8K.
This commit adds the required clock in mvpp2, making sure it's only
used on PPv2.2.
Fixes: c7e92def1ef4 ("clk: mvebu: cp110: Fix clock tree representation")
Si
V2 : Remove all DT patches from this series, they will be merged through
the mvebu tree.
Maxime Chevallier (2):
net: mvpp2: Fix clk error path in mvpp2_probe
net: mvpp2: Fix clock resource by adding missing mg_core_clk
drivers/net/ethernet/marvell/mvpp2.c | 30 +++---
When clk_prepare_enable fails for the axi_clk, the mg_clk isn't properly
cleaned up. Add another jump label to handle that case, and make sure we
jump to it in the later error cases.
Fixes: 4792ea04bcd0 ("net: mvpp2: Fix clock resource by adding an optional bus
clock")
Signed
TCAM entry, we simply return the TCAM id that matches
the requested entry.
Signed-off-by: Maxime Chevallier
---
V2: Remove unnecessary brackets, following Antoine Tenart's review.
drivers/net/ethernet/marvell/mvpp2.c | 289 +++
1 file changed, 127 insertio
Hello Yan,
On Wed, 21 Mar 2018 19:57:47 +,
Yan Markman wrote :
> Hi Maxime
Please avoid top-posting on this list.
> Please check the TWO points:
>
> 1). The mvpp2_prs_flow_find() returns TID if found
> The TID=0 is valid FOUND value
> For Not-found use -ENOENT (just like your mvpp
Hello David,
On Thu, 22 Mar 2018 14:47:09 -0400 (EDT),
David Miller wrote :
> From: Maxime Chevallier
> Date: Wed, 21 Mar 2018 16:14:00 +0100
>
> > diff --git a/drivers/net/ethernet/marvell/mvpp2.c
> > b/drivers/net/ethernet/marvell/mvpp2.c index
> > 9bd35f
On Thu, 22 Mar 2018 15:43:08 -0400 (EDT),
David Miller wrote :
> From: Maxime Chevallier
> Date: Thu, 22 Mar 2018 20:14:53 +0100
>
> > Hello David,
> >
> > On Thu, 22 Mar 2018 14:47:09 -0400 (EDT),
> > David Miller wrote :
> >
> >> From: M
TCAM entry, we simply return the TCAM id that matches
the requested entry.
Signed-off-by: Maxime Chevallier
---
V2: Remove unnecessary brackets, following Antoine Tenart's review.
V3: Make sure prs_entry objects are zeroed before using them, following
David Miller and Yan Markman's re
r prs_entry, by passing it the
index as a parameter. The function now zeroes the entry, and sets the
index field before doing all other init from HW.
The function is renamed 'mvpp2_prs_init_from_hw' to make that clear.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethe
into mvpp2_prs_init_from_hw,
make it zero-out the struct and take the index as a parameter. That's what's
done in the first patch of the series.
The second patch is the V3 of
("net: mvpp2: Don't use dynamic allocs for local variables"), making use of
mvpp2_prs_init_from_hw and taking previous
-by: Maxime Chevallier
---
David, this patch should not conflict with other the pending PPv2 series I sent
earlier ("[PATCH net-next 0/2] net: mvpp2: Remove unnecessary dynamic allocs")
drivers/net/ethernet/marvell/mvpp2.c | 43 +---
1 file changed, 30
Hello Russell,
On Thu, 7 Feb 2019 23:48:24 +
Russell King - ARM Linux admin wrote:
>On Thu, Feb 07, 2019 at 10:49:36AM +0100, Maxime Chevallier wrote:
>> The Marvell Alaska family of PHYs supports 2.5GBaseT and 5GBaseT modes,
>> as defined in the 802.3bz specification.
>&
The PPv2 controller is able to support 2.5G speeds, allowing to use
2.5GBASET in conjunction with PHYs that use 2500BASEX as their MII
interface when using this mode.
Signed-off-by: Maxime Chevallier
Reviewed-by: Andrew Lunn
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 +
1 file
The PHY ID corresponding to the 88X3310 is also used for other PHYs in
the same family, such as the 88E2010. Use a #define for the PHY id, that
ignores the last nibble.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 4 ++--
include/linux/marvell_phy.h | 1 +
2 files
g the correct helper to set a linkmode bit and adding macros for the
PHY ids.
We also add support for the 88E2110 PHY, which doesn't require the
quirk, and support for 2500BaseT in the PPv2 driver, in order to have a
fully working setup on the MacchiatoBin board.
Maxime Chevallier (7):
Cosmetic patch making use of helpers dedicated to linkmodes handling.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 65ef469adf58
adding autoneg ability based on what's reported by the AN
MMD.
.config_init is still used to validate the interface_mode.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/marvell10
ue as the 88x3310 regarding 2.5/5G
abilities, and correctly follows the 802.3bz standard to list the
supported abilities.
Signed-off-by: Maxime Chevallier
Suggested-by: Antoine Tenart
---
drivers/net/phy/marvell10g.c | 13 +
include/linux/marvell_phy.h | 1 +
2 files changed, 14 inser
1.11.14 bit set, as it should.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 9323bcf15dbd..c48669d50653 100644
--- a/driv
x27;t supported by any MAC for now.
This was tested with :
- The 88X3310, which is on the MacchiatoBin
- The 88E2010, an Alaska PHY that has no fiber interfaces, and is
limited to 5G maximum speed.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 26 +++
Hello Russell,
On Thu, 21 Feb 2019 10:22:15 +
Russell King - ARM Linux admin wrote:
>> +return 0;
>> +}
>> +
>> +static int mv3310_get_features(struct phy_device *phydev)
>> +{
>> +int ret, val;
>
>Please try to keep the formatting/style consistent in the file you are
>editing. A
: 20b2af32ff3f ("net: phy: add Marvell Alaska X 88X3310 10Gigabit PHY
support")
Signed-off-by: Maxime Chevallier
Reported-by: Russell King
---
Dave,
This patch will conflict when merging net into net-next, and is actually
not needed there. In net-next, this issue is fixed by the recent wo
;*phydev)
This makes the helper not reading PMA-only registers, so the naming
isn't really relevant anymore, but that's a small detail.
Other than that,
Reviewed-by: Maxime Chevallier
Thanks,
Maxime
On Fri, 22 Feb 2019 19:42:29 +0100
Heiner Kallweit wrote:
>After my just submitted patch to include the aneg capability checking in
>genphy_c45_pma_read_abilities() function mv3310_get_features() isn't
>needed any longer and can be replaced with the generic one.
I'll still need it to handle the
formatting issue in patch 01, rebased.
Maxime Chevallier (7):
net: phy: marvell10g: Use get_features to get the PHY abilities
net: phy: marvell10g: Use linkmode_set_bit helper instead of __set_bit
net: phy: marvell10g: Use 2500BASEX when using 2.5GBASET
net: phy: marvell10g: Use a #define f
1.11.14 bit set, as it should.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 9c0b8f16cec5..8f354c3f3876 100644
--- a/driv
Cosmetic patch making use of helpers dedicated to linkmodes handling.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index 89920b10d75b
adding autoneg ability based on what's reported by the AN
MMD.
.config_init is still used to validate the interface_mode.
Signed-off-by: Maxime Chevallier
---
V2: Added missing blank line
drivers/net/phy/marvell10g.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --
The PPv2 controller is able to support 2.5G speeds, allowing to use
2.5GBASET in conjunction with PHYs that use 2500BASEX as their MII
interface when using this mode.
Signed-off-by: Maxime Chevallier
Reviewed-by: Andrew Lunn
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 +
1 file
x27;t supported by any MAC for now.
This was tested with :
- The 88X3310, which is on the MacchiatoBin
- The 88E2010, an Alaska PHY that has no fiber interfaces, and is
limited to 5G maximum speed.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 26 +++
ue as the 88x3310 regarding 2.5/5G
abilities, and correctly follows the 802.3bz standard to list the
supported abilities.
Signed-off-by: Maxime Chevallier
Suggested-by: Antoine Tenart
---
drivers/net/phy/marvell10g.c | 13 +
include/linux/marvell_phy.h | 1 +
2 files changed, 14 inser
The PHY ID corresponding to the 88X3310 is also used for other PHYs in
the same family, such as the 88E2010. Use a #define for the PHY id, that
ignores the last nibble.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 4 ++--
include/linux/marvell_phy.h | 1 +
2 files
really is that the -net patch
also masks the 2.5/5G Fast Retrain abilities, but this should make no
difference given that 2.5/5G are masked-out in both cases.
I'm sorry for the confusion, I wasn't sure how to deal with such a
scenario.
Thanks,
Maxime
--
Maxime Chevallier, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
Contrary to the 3310, the 2110 PHY correctly reports it's 2.5G/5G
abilities. We can therefore use the genphy_c45_pma_read_abilities helper
to build the list of features.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
, since it doesn't have the
issue with the wrong abilities being reported.
Maxime Chevallier (2):
net: phy: marvell10g: Let genphy_c45_pma_read_abilities set Aneg bit
net: phy: marvell10g: Use the generic C45 helper to read the 2110
features
drivers/net/phy/marvell10g.c | 12 +-
The genphy_c45_pma_read_abilities helper now sets the Autoneg ability
in phydev->supported according to what the AN MMD reports.
We therefore don't need to manually do that in mv3310_get_features().
Signed-off-by: Maxime Chevallier
Suggested-by: Heiner Kallweit
---
drivers
ports but the 9 and 10, and because modes supported by 6390
ports 9 and 10 are a subset of those supported on 6390X.
This was tested on 6390X using RXAUI mode.
Fixes: 364e9d7776a3 ("net: dsa: mv88e6xxx: Power on/off SERDES on cmode change")
Signed-off-by: Maxime Chevallier
---
drive
Hi Petr,
On Mon, 6 May 2019 10:32:07 +0200
Petr Štetiar wrote:
>David Miller [2019-05-05 21:47:27]:
>
>Hi David,
>
>> Series applied, thank you.
>
>I did probably something terribly wrong, but patch "[PATCH v4 05/10] net:
>ethernet: support of_get_mac_address new ERR_PTR error" has not reache
on offload support")
Reported-by: Jakub Kicinski
Acked-by: Jakub Kicinski
Signed-off-by: Maxime Chevallier
---
V2: Rebased on latest -net, added Jakub's Ack, gave more details in the
commit log about not adding the flag in hw_features.
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
Hi Yanko,
>On Tue, 14 May 2019 10:29:31 +0300
>Yanko Kaneti wrote:
>
>> Hello,
>>
>> I am trying to get some Fedora working on the MACCHIATObin SingleShot
>> and I am getting an OOPS on what seems to be the first received packet
>> on the gigabit port.
>>
>> I've tried both 5.0.x stable and 5.1
Hello everyone,
I'm working on a setup where I have a 88e6390X DSA switch connected to
a CPU (an armada 8040) with 2500BaseX and RXAUI interfaces (we only use
one at a time).
I'm facing a limitation with the current way to represent that link,
where we use a fixed-link description in the CPU port
Hi Andrew,
On Wed, 15 May 2019 15:27:01 +0200
Andrew Lunn wrote:
>I think you are getting your terminology wrong. 'master' is eth0 in
>the example you gave above. CPU and DSA ports don't have netdev
>structures, and so any PHY used with them is not corrected to a
>netdev.
Ah yes sorry, I'm stil
Hi everyone,
On Wed, 15 May 2019 09:09:26 -0700
Florian Fainelli wrote:
>On 5/15/19 7:02 AM, Maxime Chevallier wrote:
>> Hi Andrew,
>>
>> On Wed, 15 May 2019 15:27:01 +0200
>> Andrew Lunn wrote:
>>
>>> I think you are getting your terminology wron
Hello Andrew,
Thanks for your feedback !
>> I'm currently working on adding support for 2.5GBaseT on some Marvell
>> PHYs (the marvell10g family, including the 88X3310).
>>
>> However, phylib doesn't quite support these modes yet. Its stores the
>> different supported and advertised modes in u32
The PPv2 controller always expect descriptors to be in little endian. We
must therefore force descriptors to use that format, and convert to the
host endianness when necessary.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 56
Hello Andrew,
On Tue, 19 Jun 2018 17:21:55 +0200
Andrew Lunn wrote:
>> What I propose is that we add 3 link_mode fields in phy_device, and keep
>> the legacy fields for now. It would be up to the driver to fill the new
>> "supported" field in config_init, kind of like what's done in the
>> marve
lpers, making it easier to
>update. It might make sense to add a couple of more helpers, for what
>remains.
Wow indeed that will help a lot. Just so that we're in sync, do you
plan to add those helpers, or should I take this branch as a base for
the conversion and go on ?
Thanks for
On Fri, 29 Jun 2018 17:34:41 +0200
Andrew Lunn wrote:
>> Wow indeed that will help a lot. Just so that we're in sync, do you
>> plan to add those helpers, or should I take this branch as a base for
>> the conversion and go on ?
>
>I'm still working on it. I can probably push again in the next f
TCAM entry, we simply return the TCAM id that matches
the requested entry.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2.c | 282 +++
1 file changed, 124 insertions(+), 158 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2
Boundary check in mvpp2_prs_init_from_hw must be done according to the
passed "tid" parameter, not the mvpp2_prs_entry index, which is not yet
initialized at the time of the check.
Fixes: 47e0e14eb1a6 ("net: mvpp2: Make mvpp2_prs_hw_read a parser entry init
function")
S
allowed
before switching to promiscuous mode.
Fixes: 10fea26ce2aa ("net: mvpp2: Add support for unicast filtering")
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.
patch implements the ndo_set_features to allow for disabling of VLAN
filtering using ethtool.
The default config has VLAN filtering disabled.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2.c | 414 ---
1 file changed, 380 insertions(+
patch implements the ndo_set_features to allow for disabling of VLAN
filtering using ethtool.
The default config has VLAN filtering disabled.
Signed-off-by: Maxime Chevallier
---
V2: Use correct order for local variable declarations
drivers/net/ethernet/marvell/mvpp2.c
ever unicast or multicast range for one port is full, the filtering
is disabled and port goes into promiscuous mode for the given type of
addresses.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2.c | 296 +++
1 file changed, 161 insertions(+)
addresses to the per-port filter.
This commit changes the function so that it takes struct mvpp2_port as
a parameter instead.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a
icast promiscuous mode.
The first patch reworks the function that adds and removes addresses to the
filter. This is preparatory work to ease UC filter implementation.
The second patch adds the UC filtering feature.
Maxime Chevallier (2):
net: mvpp2: Simplify MAC filtering function parameters
net:
On Fri, 14 Sep 2018 23:38:49 +0200
Andrew Lunn wrote:
>phylink has some useful helpers to working with linkmode bitmaps.
>Move them to there own header so other code can use them.
>
>Signed-off-by: Andrew Lunn
Reviewed-by: Maxime Chevallier
On Fri, 14 Sep 2018 23:38:50 +0200
Andrew Lunn wrote:
>Not all new style LINK_MODE bits can be converted into old style
>SUPPORTED bits. We need to warn when such a conversion is attempted.
>Add a helper for this.
>
>Signed-off-by: Andrew Lunn
Reviewed-by: Maxime Chevallier
register value to a linkmode.
>
>Signed-off-by: Andrew Lunn
Reviewed-by: Maxime Chevallier
On Fri, 14 Sep 2018 23:38:52 +0200
Andrew Lunn wrote:
>Add a helper to convert the local advertising to an LCL capabilities,
>which is then used to resolve pause flow control settings.
>
>Signed-off-by: Andrew Lunn
Reviewed-by: Maxime Chevallier
On Fri, 14 Sep 2018 23:38:53 +0200
Andrew Lunn wrote:
>Add helpers which take a linkmode rather than a u32 ethtool for
>advertising settings.
>
>Signed-off-by: Andrew Lunn
Reviewed-by: Maxime Chevallier
Hi Andrew,
On Fri, 14 Sep 2018 23:38:48 +0200
Andrew Lunn wrote:
>These patches contain some further cleanup and helpers, and the first
>real patch towards using linkmode bitmaps in phylink.
>
>It is RFC because i don't like patch #7 and maybe somebody has a
>better idea how to do this. Ideally,
ource/include/linux/phy.h#L441
[2]
https://elixir.bootlin.com/linux/v4.18-rc1/source/include/linux/phy.h#L512
--
Maxime Chevallier, Bootlin (formerly Free Electrons)
Embedded Linux and kernel engineering
https://bootlin.com
the "steer to rxq" action.
Signed-off-by: Maxime Chevallier
---
V2: - Re-arranged struct mvpp2_rfs_rule to minimize gaps on 64 bits systems,
as suggested by David.
- Fixed a smatch error indicating a possible out-of-bound array access
when accessing the internal lis
t fine.
Thanks,
Tested-by: Maxime Chevallier
>Signed-off-by: Grygorii Strashko
>---
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +-
> drivers/phy/marvell/phy-mvebu-cp110-comphy.c| 83 ++---
> 2 files changed, 48 insertions(+), 54 deletions(-)
&g
-off-by: Maxime Chevallier
---
drivers/net/phy/phy-c45.c | 22 ++
include/uapi/linux/mdio.h | 10 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
index 31806b432734..61ca4f89e94a 100644
--- a/drivers/net/phy/phy-c45
bove-mentionned 1.21 register should be taken
into account.
This commit adds that logic into the genphy_c45_read_abilities function.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/phy-c45.c | 14 ++
include/uapi/linux/mdio.h | 6 ++
2 files changed, 20 insertions(+)
diff --g
The PPv2 controller is able to support 2.5G speeds, allowing to use
2.5GBASET in conjunction with PHYs that use 2500BASEX as their MII
interface when using this mode.
Signed-off-by: Maxime Chevallier
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 1 +
1 file changed, 1 insertion(+)
diff
ue as the 88x3310 regarding 2.5/5G
abilities, and correctly follows the 802.3bz standard to list the
supported abilities.
Signed-off-by: Maxime Chevallier
Suggested-by: Antoine Tenart
---
drivers/net/phy/marvell10g.c | 37
1 file changed, 37 insertions(+)
diff
1.11.14 bit set, as it should.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index f45ddf3bc138..0a35bf0fac47 100644
--- a/driv
this
mode isn't supported by any MAC for now.
This was tested with :
- The 88X3310, which is on the MacchiatoBin
- The 88E2010, an Alaska PHY that has no fiber interfaces, and is
limited to 5G maximum speed.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/ma
nect to the
MAC in that case.
Thanks to Andrew for doing the rework of the link_mode representation
this series depends on.
Maxime Chevallier (7):
net: phy: Extract genphy_c45_read_abilities from marvell10g
net: phy: Add generic support for 2.5GBaseT and 5GBaseT
net: phy: Read 2.5G and 5G ext
g and uses it to introduce the genphy_c45_read_abilities
function.
Signed-off-by: Maxime Chevallier
---
drivers/net/phy/marvell10g.c | 80 ++
drivers/net/phy/phy-c45.c| 96
include/linux/phy.h | 1 +
3 files changed
Hello Andrew,
On Sun, 20 Jan 2019 20:08:09 +0100
Andrew Lunn wrote:
>On Fri, Jan 18, 2019 at 04:23:50PM +0100, Maxime Chevallier wrote:
>> As per 802.3bz, if bit 14 of (1.11) "PMA Extended Abilities" indicates
>> whether or not we should read register (1.21) "2.5
Hello Russell,
On Mon, 21 Jan 2019 10:52:06 +
Russell King - ARM Linux admin wrote:
>On Mon, Jan 21, 2019 at 11:35:31AM +0100, Maxime Chevallier wrote:
>> Hello Andrew,
>>
>> On Sun, 20 Jan 2019 20:08:09 +0100
>> Andrew Lunn wrote:
>>
>> &g
Hello Andrew,
On Sun, 20 Jan 2019 19:51:07 +0100
Andrew Lunn wrote:
>On Fri, Jan 18, 2019 at 04:23:46PM +0100, Maxime Chevallier wrote:
>> Marvell 10G PHY driver has a generic way of initializing the supported
>> link modes by reading the PHY's C45 PMA abilities. This ca
1 - 100 of 132 matches
Mail list logo
