e link status. This is achieved using SFP+phylink+PPv2.
>
> And representing the SFP cage in the device tree, although it's a
> "dummy" one, helps describing the hardware.
Just to add to this: the board physically has a SFP cage, and a cable
can be connected to it, or not
t mvneta_txq_init(struct mvneta_port *pp,
> txq->tx_stop_threshold = txq->size - MVNETA_MAX_SKB_DESCS;
> txq->tx_wake_threshold = txq->tx_stop_threshold / 2;
>
> -
Spurious change.
Thanks!
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
w_init(pp, txq);
> + }
> +
> + if (!pp->neta_armada3700) {
> + spin_lock(&pp->lock);
> + pp->is_stopped = false;
> + spin_unlock(&pp->lock);
> + cpuhp_state_add_instance_nocalls(online_hpstate,
> + &pp->node_online);
> + cpuhp_state_add_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
> + &pp->node_dead);
> + }
> +
> + mvneta_set_rx_mode(dev);
> + mvneta_start_dev(pp);
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
e deasserting
reset, and then switched back to its original state so that the config
pin can be used for its normal (non-reset) purpose.
So the manipulation of the config signal is intertwined with the
assert/de-assert of the reset. So I don't see how your fourth option
would work for example. Am I missing something here ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
hen as the pin
for the PTP clock input.
Does that clarify why the CONFIG pin is not simply connected to some
static pull-up/pull-down ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
eed. It would have been nicer to have something symmetric,
with the hw/sw parts split in a similar way for the init and deinit of
both txqs and rxqs, but I agree that dropping the RX packets before
going into suspend involves both HW and SW operations.
Thanks!
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
t; Signed-off-by: Yelena Krivosheev
> Signed-off-by: Gregory CLEMENT
Acked-by: Thomas Petazzoni
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
mvpp2_pools[MVPP2_BM_LONG].pkt_size = MVPP2_BM_LONG_PKT_SIZE;
> +}
?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
dev->min_mtu = ETH_MIN_MTU;
> - /* 9676 == 9700 - 20 and rounding to 8 */
> - dev->max_mtu = 9676;
How come we already had a max_mtu of 9676 without Jumbo frame support ?
> + /* 9704 == 9728 - 20 and rounding to 8 */
> + dev->max_mtu = MVPP2_BM_JUMBO_PKT_SIZE;
Is this correct for all ports ? Shouldn't the maximum MTU be different
between port 0 (that supports Jumbo frames) and the other ports ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
ion a limit of the PPv2.2 IP, or of the CP110 ?
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
#x27;s just a
limitation of PPv2.2, and mentioning CP110 in the comment doesn't make
much sense, correct ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
bo frames) and the other ports ?
>
> This is correct for all ports. All ports can support Jumbo frames.
OK. With your explanation above, I understand better.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
ALIGN(X, SMP_CACHE_BYTES)
I don't really see a __max(...) call.
And if this value really expands depending on other values, then it
isn't really a constant, and should be considered as a constant, no?
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
iv->mg_clk);
> if (err < 0)
> goto err_gop_clk;
> +
> + priv->axi_clk = devm_clk_get(&pdev->dev, "axi_clk");
> + if (IS_ERR(priv->axi_clk)) {
> + err = PTR_ERR(priv->axi_clk);
> + priv->axi_clk = NULL;
You should handle -EPROBE_DEFER here. Indeed, if we have -EPROBE_DEFER,
we shouldn't treat it as "the clock doesn't exist, so let's skip it and
continue", but rather as "the clock exists, but isn't ready to use yet,
let's try later".
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
parison in operand of ‘|’ [-Wparentheses]
> if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX |
> ^~~~~~~
This is actually a very good warning: it should be a || and not |.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
of all unused
clocks at the end of the boot. When the driver is built-in, there is a
driver adding a reference to the clock before all unused clocks are
disabled. When the driver is compiled as a module, this does not
happen. So indeed, the correct solution here is to have U-Boot pass the
MAC address
ssing device_del() invocation in the
error path.
Fixes: 69226896ad636 ("mdio_bus: Issue GPIO RESET to PHYs")
Signed-off-by: Thomas Petazzoni
---
drivers/net/phy/mdio_bus.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 2e59a8419b1
should
always be called: "Always use put_device() to give up the reference
initialized in this function instead.".
What do you think?
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
proper reset/reinit of the HW ?
I.e, isn't the firmware fix papering over a bug that should be fixed in
Linux mvpp2 driver anyway ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
M on boot up that would avoid this issue ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
ng on XDP support in mvneta, and this work
also needs to change parts of the memory allocation strategy in this
driver. I'd suggest to get in touch with those folks. Antoine can give
you the contact details, I don't have them off-hand. Or perhaps they
will see this e-mail :-)
Best regards,
e net-next tree, all the
other patches should have gone through other trees.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
ch will be freed up by mdiobus_free()
So, if we were to use device_unregister() in the error path of
mdiobus_register() and in mdiobus_unregister(), it would break how
mdiobus_free() works.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
nd trace 0e5abdfc76ee83e5 ]---
> [ 1344.696733] Kernel panic - not syncing: Fatal exception in interrupt
> [ 1344.703310] SMP: stopping secondary CPUs
> [ 1344.707369] Kernel Offset: disabled
> [ 1344.710613] CPU features: 0x002008
> [ 1344.714294] Memory Limit: none
> [ 1344.717086] ---[ end Kernel panic - not syncing: Fatal exception in
> interrupt
>
> I you want more logs or some other details about my setup i'll be
> happy to help :-)
> Also with testing a possible fix.
>
> Thanks,
> Sean Nyekjaer
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Hello,
Here are two patches that fix how the sh_eth driver is using the DMA
mapping API: a bogus struct device is used in some places, or a NULL
struct device is used.
Best regards,
Thomas
Thomas Petazzoni (2):
net: sh_eth: use correct "struct device" when calling DMA mapping
uct device" representing the physical device on
its bus.
This commit fixes that by adjusting all calls to the DMA mapping API.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/renesas/sh_eth.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/d
Using NULL as argument for the DMA mapping API is bogus, as the DMA
mapping API may use information from the "struct device" to perform
the DMA mapping operation. Therefore, pass the appropriate "struct
device".
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/r
/s, even though the MAC
doesn't support it.
In order to avoid this, we mark phydev->supported if we're running a
non-Gigabit capable hardware.
Tested on a SH7786 platform, with a Gigabit PHY.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/renesas/sh_eth.c | 5 +
1 file
running
big-endian. Therefore, all the endianness conversion needs to be
removed for the sh_eth driver to work.
Signed-off-by: Thomas Petazzoni
---
Note: I see that Sergei Shtylyov has done some work around endianness
on this driver back in 2015. I am not sure if it's used on other
non-S
er. Indeed, my
change is based on the assumption that the DMA descriptors are in the
native endianness of the CPU.
Thanks,
Thomas
Thomas Petazzoni (2):
net: sh_eth: add support for SH7786
net: sh_eth: make work on big endian systems
drivers/net/ethernet/renesas/sh_
This commit adds the sh_eth_cpu_data structure that describes the
SH7786 variant of the IP.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/renesas/sh_eth.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c
b/drivers
Hello,
On Mon, 4 Dec 2017 19:56:35 +0300, Sergei Shtylyov wrote:
> On 12/04/2017 05:17 PM, Thomas Petazzoni wrote:
>
> > This commit adds the sh_eth_cpu_data structure that describes the
> > SH7786 variant of the IP.
>
> The manual seems to be unavailable, so I hav
h the MAC doesn't support it.
In order to avoid this, we use the recently introduced
phy_set_max_speed() to tell the PHY to not advertise speed higher than
100 MBit/s.
Tested on a SH7786 platform, with a Gigabit PHY.
Signed-off-by: Thomas Petazzoni
---
Changes since v1:
- Use phy_set_max_s
mp;mdp->pdev->dev);
pm_runtime_put_sync(&mdp->pdev->dev);
pm_runtime_put_sync(&mdp->pdev->dev);
struct device *dev = &mdp->pdev->dev;
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
tlin have
> remained quiet.
Unfortunately, we are no longer actively working on Marvell platform
support at the moment. We might have a look on a best effort basis, but
this is potentially a non-trivial issue, so I'm not sure when we will
have the chance to investigate and fix this.
Best regards,
t; 5.7-final?
Since 5.7 is really close, I would suggest to disable the functionality.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
orrupted packets are given to the upper layers.
>
> Does this ring a bell for you? I didn't start to debug that yet.
I think I do remember seeing reports about this, but I don't remember
if it ended up being fixed (and what we're seeing is some other
problem), or if it
A previous commit modified a number of smp_processor_id() used in
migration-enabled contexts into get_cpu/put_cpu sections. However, a few
smp_processor_id() calls remain in the driver, and this commit adds
comments explaining why they can be kept.
Signed-off-by: Thomas Petazzoni
---
drivers
This function is not used in the driver, remove it.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index 4b3bf37..aad763c 100644
David,
Here are a few patches making various small improvements/refactoring
in the mvpp2 driver. They are based on today's net-next.
Thanks!
Thomas
Thomas Petazzoni (3):
net: mvpp2: add comments about smp_processor_id() usage
net: mvpp2: remove unused mvpp2_bm_cookie_pool_set() fun
When all a function does is calling another function with the exact same
arguments, in the exact same order, you know it's time to remove said
function. Which is exactly what this commit does.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 14 +++---
1
Hello Giuseppe,
On Mon, 15 May 2017 16:27:34 +0200, Thomas Petazzoni wrote:
> On Wed, 10 May 2017 09:18:17 +0200, Thomas Petazzoni wrote:
>
> > On Wed, 10 May 2017 09:03:12 +0200, Giuseppe CAVALLARO wrote:
> >
> > > > Please, read again my patch and the des
path and in the remove path.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
to the
GIC directly.
Signed-off-by: Thomas Petazzoni
---
.../devicetree/bindings/net/marvell-pp2.txt| 33 +-
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt
b/Documentation/devicetree/bindings/net
Antoine's.
- Please do not apply the last patch of this series "arm64: dts:
marvell: add TX interrupts for PPv2.2", it will be taken by the ARM
mvebu maintainers.
Thanks!
Thomas
Thomas Petazzoni (8):
net: mvpp2: fix MVPP21_ISR_RXQ_GROUP_REG definition
net: mvpp2: remove RX que
s a single queue_vector, so there are
no changes in behavior, but it paves the way for additional
queue_vector in the next commits.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 250 +--
1 file changed, 178 insertions(+), 72 deletions(-)
di
This commit updates the Marvell Armada 7K/8K Device Tree to describe
the TX interrupts of the Ethernet controllers, in both the master and
slave CP110s.
Signed-off-by: Thomas Petazzoni
---
Dave: please do *not* apply this patch. It will go through the ARM
mvebu maintainers. Thanks!
.../arm64
nge, it makes sense to change the naming
from MVPP2_MAX_CPUS to MVPP2_MAX_THREADS, and plan for 8 software
threads instead of 4 currently.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
d
The RX queue group allocation is anyway re-done later in
mvpp2_port_init(), so resetting it in mvpp2_init() is not very useful,
and will be annoying as we are going to rework the RX queue group
allocation logic.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 17
, with only one RX interrupt, and TX completion being handled
by an hrtimer.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 275 +++
1 file changed, 246 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b
The MVPP21_ISR_RXQ_GROUP_REG register is not indexed by rxq, but by
port, so we fix the parameter name accordingly. There are no
functional changes.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
per-port count of RXQ and
TXQ.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 83 ++--
1 file changed, 41 insertions(+), 42 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index e
y are really related. It's very common to have patch series
that contain patches that will be merged by different maintainers.
> don't bother adding them to the series. That way you don't have to
> give me special instructions, and I don't have the possibility of
>
h the MAC doesn't support it.
In order to avoid this, we use the recently introduced
phy_set_max_speed() to tell the PHY to not advertise speed higher than
100 MBit/s.
Tested on a SH7786 platform, with a Gigabit PHY.
Signed-off-by: Thomas Petazzoni
---
Changes since v2:
- Drop goto constructi
e sent a v3 that takes into account this
comment.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
patible with SH_ETH_REG_FAST_SH4 layout ?
Note that my patch makes Ethernet work in practice on SH7784, I have
root over NFS working as we speak. This certainly doesn't mean that the
patch is entirely correct, but it definitely means that the
SH_ETH_REG_FAST_SH4 is close enough to what the SH7786 is using :-)
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
consider the RMII and (R)GMII cases.
Have you had the chance to cook a different proposal? Alternatively, do
you have some specific hints to give me to make a new proposal that
would be acceptable for you ?
Thanks a lot,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and
The MVPP21_ISR_RXQ_GROUP_REG register is not indexed by rxq, but by
port, so we fix the parameter name accordingly. There are no
functional changes.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
t go through the net
tree.
Thanks!
Thomas
Thomas Petazzoni (7):
net: mvpp2: fix MVPP21_ISR_RXQ_GROUP_REG definition
net: mvpp2: remove RX queue group reset code
net: mvpp2: introduce per-port nrxqs/ntxqs variables
net: mvpp2: move from cpu-centric naming to "software thread"
The RX queue group allocation is anyway re-done later in
mvpp2_port_init(), so resetting it in mvpp2_init() is not very useful,
and will be annoying as we are going to rework the RX queue group
allocation logic.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 17
s a single queue_vector, so there are
no changes in behavior, but it paves the way for additional
queue_vector in the next commits.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 223 ++-
1 file changed, 169 insertions(+), 54 deletions(-)
di
nge, it makes sense to change the naming
from MVPP2_MAX_CPUS to MVPP2_MAX_THREADS, and plan for 8 software
threads instead of 4 currently.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
d
, with only one RX interrupt, and TX completion being handled
by an hrtimer.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 275 +++
1 file changed, 246 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b
per-port count of RXQ and
TXQ.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 83 ++--
1 file changed, 41 insertions(+), 42 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index 5
to the
GIC directly.
Signed-off-by: Thomas Petazzoni
---
.../devicetree/bindings/net/marvell-pp2.txt| 28 +++---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt
b/Documentation/devicetree/bindings/net
n to this problem
should be designed. I made an initial simple proposal to show what is
needed, but I'm definitely open to suggestions.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Hello Giuseppe,
On Wed, 10 May 2017 09:18:17 +0200, Thomas Petazzoni wrote:
> On Wed, 10 May 2017 09:03:12 +0200, Giuseppe CAVALLARO wrote:
>
> > > Please, read again my patch and the description of the problem that I
> > > have sent. But basically, any solution that d
gt;
> Signed-off-by: Antoine Tenart
Please add:
Fixes: 2697582144dd ("net: mvpp2: handle misc PPv2.1/PPv2.2 differences")
with this:
Acked-by: Thomas Petazzoni
I am wondering if we shouldn't Cc: stable as well. I don't think we
have seen issues on our side because
should be pushed to stable.
The last three patches are cleanups and not needed for stable, but
they stack on top of the fixes.
Thanks,
Thomas
Thomas Petazzoni (5):
net: mvpp2: remove mvpp2_bm_cookie_{build,pool_get}
net: mvpp2: use {get,put}_cpu() instead of smp_processor_id()
net: mvpp2
commit replaces the smp_processor_id() in
migration-enabled contexts by the appropriate get_cpu/put_cpu sections.
Reported-by: Marc Zyngier
Fixes: a786841df72e ("net: mvpp2: handle register mapping and access for
PPv2.2")
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mv
: 3f518509dedc9 ("ethernet: Add new driver for Marvell Armada 375 network
unit")
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 51 ++--
1 file changed, 14 insertions(+), 37 deletions(-)
diff --git a/drivers/net/ethernet/marvell/
A previous commit modified a number of smp_processor_id() used in
migration-enabled contexts into get_cpu/put_cpu sections. However, a few
smp_processor_id() calls remain in the driver, and this commit adds
comments explaining why they can be kept.
Signed-off-by: Thomas Petazzoni
---
drivers
This function is not used in the driver, remove it.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index 037f6bd..4ca1639 100644
When all a function does is calling another function with the exact same
arguments, in the exact same order, you know it's time to remove said
function. Which is exactly what this commit does.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 14 +++---
1
: 3f518509dedc9 ("ethernet: Add new driver for Marvell Armada 375 network
unit")
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 47 +++-
1 file changed, 14 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/marvell/
the kbuild
report on the first submission.
- Added Tested-by from Marc Zyngier on PATCH 2.
Thanks!
Thomas
Thomas Petazzoni (2):
net: mvpp2: remove mvpp2_bm_cookie_{build,pool_get}
net: mvpp2: use {get,put}_cpu() instead of smp_processor_id()
drivers/net/ethernet/marvell/mv
commit replaces the smp_processor_id() in
migration-enabled contexts by the appropriate get_cpu/put_cpu sections.
Reported-by: Marc Zyngier
Fixes: a786841df72e ("net: mvpp2: handle register mapping and access for
PPv2.2")
Signed-off-by: Thomas Petazzoni
Tested-by: Marc Zyngier
---
d
napi_complete_done()
a29b6235560a1ed10c8e1a73bfc616a66b802b90 net: mvneta: add BQL support
2a90f7e1d5d04e4f1060268e0b55a2c702bbd67a net: mvneta: add xmit_more support
Could you try to take mvneta* from Linux 4.10, put that in Linux 4.12,
and see if you can still produce the problem? I'd li
nce. So let's focus on those 3 commits for the moment.
Assuming you're using Git, to revert a commit just do: "git revert
".
Thanks again!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
g stability
issues with this patch applied.
Do you think you will have some time to look into this ?
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
ck look, I wonder what is happening if
> "txq->pending + frags > MVNETA_TXQ_DEC_SENT_MASK" ? Because IIUC
> mvneta_txq_pend_desc_add() is called anyway. And according to the
> comment inside the function, it assumes there is less than 255
> descriptors to send... It look
uses
cache_line_size(), see:
"[PATCH v2] net: mvneta: replace MVNETA_CPU_D_CACHE_LINE_SIZE with
cache_line_size"
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
Hello,
On Thu, 9 Mar 2017 15:56:31 +0100, Giuseppe CAVALLARO wrote:
> On 3/9/2017 10:32 AM, Thomas Petazzoni wrote:
>
> > OK, I'll have a look. However, I'm still confused by this DMA_RESET bit
> > that never clears, contrary to what the datasheet says. Are ther
he LAN8700 PHY ? Was it on a
SPEAr600 based platform ?
If you tested on SPEAr600, what is the GMAC clock configuration (i.e
the value of the GMAC_CFG_CTR and GMAC_CFG_SYNT registers) ?
Regarding the PHY reset time, our PHY reset pin is not connected to a
GPIO, but to the system reset logic, so Linux ca
local variable.
Anyway, I think it's worth investigating a different solution than
blindly converting to a GFP_ATOMIC allocation.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
. Again, we see the same behavior in U-Boot (DMA reset bit never
clears), but Ethernet does work in U-Boot.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
PHY is not coming in through the same pin when in GMII
and MII mode it seems. Does this needs some special configuration?
Any hint/idea would definitely be welcome.
Thanks a lot!
Thomas
On Wed, 12 Apr 2017 15:05:58 +0200, Thomas Petazzoni wrote:
> Hello,
>
> Thanks again for your answe
n]
>
> Add linux/phy_fixed.h to mvneta.c
>
> Signed-off-by: Russell King
Acked-by: Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index e7d0da6..ef68780 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index ef68780..b219b0c 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b
This commit remove a field of 'struct mvpp2_tx_queue' that is not used
anywhere.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvp
thing, just call mvpp2_bm_pool_put()
directly, since we have the BM pool ID.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
been completely unmapped/released.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index d938996..30aaff8 100644
--- a
tting them again in the mvpp2_rx_queue
structure is useles.
This commit therefore gets rid of this additional argument, assuming the
caller has assigned the appropriate value to rxq->pkts_coal or
rxq->time_coal before calling the respective functions.
Signed-off-by: Thomas Petazzoni
implementation.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index 3fd5a9f..d938996 100644
--- a
tomic_read(&bm_pool->in_use) < bm_pool->in_use_thresh))
return 0;
However 'is_recycle', passed as argument to mvpp2_rx_refill() is always
false. So in fact, this code is never reached, and the 'is_recycle'
argument is useless. So let's drop this code.
buffers in mvpp2_bm_bufs_add() as well
as the refill of the RX buffers in mvpp2_rx_refill() is adjusted
accordingly.
- Finally, the mvpp2_rx() is modified to use build_skb().
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 77
low value. It makes a
lot more sense to simply check if the value is too high, and if it's too
high, limit it to the maximum possible value.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/dr
UCAST’
mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L2_UCAST,
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index b219b0c..ec8f4
compliant. We use dma_addr_t for DMA addresses, and unsigned long
for virtual addresses.
It is worth mentioning that after this commit, the driver is for now
still only used on 32-bits platforms, and will only work on 32-bits
platforms.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet
1 - 100 of 288 matches
Mail list logo
