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
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
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,
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
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
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
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
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
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
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
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,
M on boot up that would avoid this issue ?
Thanks,
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
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; 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
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
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
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
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
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
#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
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
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
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
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
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
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
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
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
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
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
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
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
/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
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
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
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
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
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
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
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
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
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
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
, 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
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
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
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
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 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
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
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
>
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
, 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
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
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
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
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
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
path and in the remove path.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
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
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
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
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
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
: 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/
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
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
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/
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
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
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
s not allow to set the
PS bit between asserting the DMA reset bit and polling for it to clear
will not work for MII PHYs.
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
was my original problem).
Am I missing something here?
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
GMII and MII platforms),
but not sure if the implementation is the most appropriate. Let me know
if you have better suggestions.
See: http://marc.info/?l=linux-netdev&m=149328635210461&w=2
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
e dwmac1000 case.
Signed-off-by: Thomas Petazzoni
Cc:
---
Do not hesitate to suggest ideas for alternative implementations, I'm
not sure if the current proposal is the one that fits best with the
current design of the driver.
---
drivers/net/ethernet/stmicro/stmmac/common.h |
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
. 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
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
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
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
k. However, I'm still confused by this DMA_RESET bit
that never clears, contrary to what the datasheet says. Are there some
erratas?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
rs (unless my tests
were wrong, which is very possible).
In terms of Device Tree, I'm simply using spear600.dtsi, and enabling
the gmac node, nothing else.
Has the stmmac driver been recently used/tested on spear600 ?
Thanks,
Thomas Petazzoni
--
Thomas Petazzoni, CTO, Free Electrons
Embe
coherent allocation will not span a
4G boundary?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Now that the mvpp2 driver has been modified to accommodate the support
for PPv2.2, we can finally advertise this support by adding the
appropriate compatible string.
At the same time, we update the Kconfig description of the MVPP2 driver.
Signed-off-by: Thomas Petazzoni
---
drivers/net
The PPv2.2 unit is connected to an AXI bus on Armada 7K/8K, so this
commit adds the necessary initialization of the AXI bridge.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 85
1 file changed, 85 insertions(+)
diff --git a
read() and mvpp2_percpu_write() are new accessors added to
access the registers for which the CPU window does matter, which is why
they take a "cpu" as argument.
The driver is then changed to use mvpp2_percpu_read() and
mvpp2_percpu_write() where it matters.
Signed-off-by: Thomas
This register is no longer used since commit edc660fa09e2 ("net: mvpp2:
replace TX coalescing interrupts with hrtimer").
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
nition MVPP2_TXQ_THRESH_REG
net: mvpp2: remove mvpp2_txq_pend_desc_num_get() function
- Fix a number of checkpatch warnings.
Changes between v1 and v2:
- Made a separate series from the set of patches doing preparation
changes/fixes to the mvpp2 driver.
- Rebased on top of v4.10-rc1.
This commit adjusts how the MVPP2_ISR_RXQ_GROUP_REG register is
configured, since it changed between PPv2.1 and PPv2.2.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 46
1 file changed, 42 insertions(+), 4 deletions(-)
diff
port. This was anyway used in only one place.
- In mvpp2_port_probe(), the calculation of port->first_rxq is adjusted
to cope with the different allocation strategy between PPv2.1 and
PPv2.2. Due to this change, the 'next_first_rxq' argument of this
function is no longer need
1 - 100 of 288 matches
Mail list logo
