with
polled IO")
Signed-off-by: Greg Ungerer
---
drivers/net/ethernet/freescale/fec.h | 6 +
drivers/net/ethernet/freescale/fec_main.c | 29 +--
2 files changed, 22 insertions(+), 13 deletions(-)
v2: use quirk for imx28 as well
Resending for consideration based
Hi Andy,
On 22/10/20 7:04 pm, Andy Duan wrote:
From: Greg Ungerer Sent: Thursday, October 22, 2020 9:14
AM
Hi Andrew,
On 21/10/20 11:37 pm, Andrew Lunn wrote:
+if (fep->quirks & FEC_QUIRK_CLEAR_SETUP_MII) {
+/* Clear MMFR to avoid to generate MII event by writin
Hi Andrew,
On 21/10/20 11:37 pm, Andrew Lunn wrote:
+ if (fep->quirks & FEC_QUIRK_CLEAR_SETUP_MII) {
+ /* Clear MMFR to avoid to generate MII event by writing MSCR.
+* MII event generation condition:
+* - writing MSCR:
+* -
Hi Andy,
On 21/10/20 12:19 pm, Andy Duan wrote:
From: Greg Ungerer Sent: Wednesday, October 21, 2020 9:52
AM
Hi Andrew,
Thanks for the quick response.
On 20/10/20 12:40 pm, Andrew Lunn wrote:
On Tue, Oct 20, 2020 at 12:14:04PM +1000, Greg Ungerer wrote:
Hi Andrew,
Commit f166f890c8f0
Hi Andrew,
Thanks for the quick response.
On 20/10/20 12:40 pm, Andrew Lunn wrote:
On Tue, Oct 20, 2020 at 12:14:04PM +1000, Greg Ungerer wrote:
Hi Andrew,
Commit f166f890c8f0 ("[PATCH] net: ethernet: fec: Replace interrupt driven
MDIO with polled IO") breaks the FEC driver on at
Hi Andrew,
Commit f166f890c8f0 ("[PATCH] net: ethernet: fec: Replace interrupt
driven MDIO with polled IO") breaks the FEC driver on at least one of
the ColdFire platforms (the 5208). Maybe others, that is all I have
tested on so far.
Specifically the driver no longer finds any PHY devices whe
Hi Andrew,
On 28/5/19 11:17 pm, Andrew Lunn wrote:
My hardware has the CPU port on 9, and it is SGMII. The existing working
devicetree setup I used is:
port@9 {
reg = <9>;
label = "cpu";
Hi Andrew,
Thanks for the quick response.
On 24/5/19 11:44 pm, Andrew Lunn wrote:
On Fri, May 24, 2019 at 11:25:03AM +1000, Greg Ungerer wrote:
Hi Andrew,
I have a problem with a Marvell 6390 switch that I have bisected
back to commit 7cbbee050c95, "[PATCH] net: dsa: mv88e6xxx: Set co
Hi Andrew,
I have a problem with a Marvell 6390 switch that I have bisected
back to commit 7cbbee050c95, "[PATCH] net: dsa: mv88e6xxx: Set correct
interface mode for CPU/DSA ports".
I have a Marvell 380 SoC based platform with a Marvell 6390 10 port
switch, everything works with kernel 5.0 and o
; netdev@vger.kernel.org
Cc: r...@vdorst.com; j...@phrozen.org; n...@brown.name; Greg Ungerer
Subject: [PATCHv3 2/3] net: dsa: mt7530: support the 7530 switch on the
Mediatek MT7621 SoC
From: Greg Ungerer
The MediaTek MT7621 SoC device contains a 7530 switch, and the existing linux
kernel 7530
On 22/1/19 3:04 am, Andrew Lunn wrote:
On Mon, Jan 21, 2019 at 05:11:39PM +1000, g...@kernel.org wrote:
From: Greg Ungerer
The MediaTek MT7621 SoC device contains a 7530 switch, and the existing
linux kernel 7530 DSA switch driver can be used with it.
The bulk of the changes required stem
Hi Andrew,
On 17/1/19 2:12 am, Andrew Lunn wrote:
On Wed, Jan 16, 2019 at 11:14:30PM +1000, Greg Ungerer wrote:
Hi Andrew,
On 15/1/19 11:18 pm, Andrew Lunn wrote:
[snip]
As i said, it is a bit messy. I would probably have a section:
Required properties
which lists all common required
Hi Andrew,
On 15/1/19 11:18 pm, Andrew Lunn wrote:
[snip]
As i said, it is a bit messy. I would probably have a section:
Required properties
which lists all common required properties. And then a section
Required properties mediatek,mt7530
With those which are required by that device.
Ok,
Hi Andrew,
On 15/1/19 12:07 am, Andrew Lunn wrote:
On Mon, Jan 14, 2019 at 05:03:34PM +1000, g...@kernel.org wrote:
From: Greg Ungerer
Add devicetree binding to support the compatible mt7530 switch as used
in the MediaTek MT7621 SoC.
Hi Gerg
It gets messy, but could you try to indicate
Hi René,
On 14/1/19 10:55 pm, René van Dorst wrote:
Quoting g...@kernel.org:
From: Greg Ungerer
Do not attempt to force a port phy auto-ngeotiation during the driver
init phase. It is not necessary and results in a warning at system
boot up:
mtk_soc_eth 1e10.ethernet: generated random
Hi John,
On 4/12/18 12:02 am, John Crispin wrote:
On 03/12/2018 15:00, René van Dorst wrote:
Quoting Bjørn Mork :
Greg Ungerer writes:
The following change helped alot, but I still get some problems under
sustained load and some types of port setups. Still trying to figure
out what exactly
Hi Bjorn,
On 3/12/18 9:34 pm, Bjørn Mork wrote:
[ fixed Johns address - the openwrt.org email was apparently never restored? ]
Greg Ungerer writes:
The following change helped alot, but I still get some problems under
sustained load and some types of port setups. Still trying to figure
out
Hi Bjorn,
On 30/11/18 10:16 pm, Bjørn Mork wrote:
g...@kernel.org writes:
I have been working towards supporting the MT7530 switch as used in the
MediaTek MT7621 SoC. Unlike the MediaTek MT7623 the MT7621 is built around
a dual core MIPS CPU architecture. But underneath it is what appears to
b
Hi Florian,
On 1/12/18 3:41 am, Florian Fainelli wrote:
Hi Greg,
On 11/29/2018 11:57 PM, g...@kernel.org wrote:
From: Greg Ungerer
Add descriptive entries for the new bindings introduced to support the
MT7530 implementation in the MediaTek MT7621 SoC.
New bindings added for:
mediatek
Hi Andrew,
On 30/11/18 11:33 pm, Andrew Lunn wrote:
2. Maximal sized RX packets get silently dropped. So receive side packets
that are large (perfect case is the all-but-last packets in a fragemented
larger packet) appear to be dropped at the mt7621 ethernet MAC level.
The 7530 MIB s
Hi Andrew,
On 30/11/18 11:37 pm, Andrew Lunn wrote:
1. TX packets are not getting an IP header checksum via the normal
off-loaded checksumming when in DSA mode. I have to switch off
NETIF_F_IP_CSUM, so the software stack generates the checksum.
That checksum offloading works ok when
Hi Bjorn,
On 30/11/18 10:16 pm, Bjørn Mork wrote:
g...@kernel.org writes:
I have been working towards supporting the MT7530 switch as used in the
MediaTek MT7621 SoC. Unlike the MediaTek MT7623 the MT7621 is built around
a dual core MIPS CPU architecture. But underneath it is what appears to
b
Hi Rene,
On 30/11/18 9:27 pm, René van Dorst wrote:
Quoting g...@kernel.org:
I have been working towards supporting the MT7530 switch as used in the
MediaTek MT7621 SoC. Unlike the MediaTek MT7623 the MT7621 is built around
a dual core MIPS CPU architecture. But underneath it is what appears t
iver and the system continue to function normally.
As per the warning the coherent_dma_mask is not set on this device.
There is nothing special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits in the platform data for the FEC
ethernet devices.
Signed-off-by: Greg Un
Hi Geert,
On 27/03/18 22:59, Geert Uytterhoeven wrote:
> On Mon, Mar 26, 2018 at 3:36 PM, Greg Ungerer wrote:
>> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>> coherent_dma_mask") the Freescale FEC driver is issuing the following
>> warning on dr
l about the DMA memory coherency on this hardware
so we can just set the mask to 32bits during probe.
Signed-off-by: Greg Ungerer
---
drivers/net/ethernet/freescale/fec_main.c | 2 ++
1 file changed, 2 insertions(+)
Is this the best way to handle this problem?
Comments welcome...
diff --git a/driv
h has no effect on the module binaries.
>
> The superfluous additions of 8390.o were introduced in
> commit 644570b83026 ("8390: Move the 8390 related drivers").
>
> Cc: Greg Ungerer
Looks right for mcf8390.c.
Acked-by: Greg Ungerer
Regards
Greg
> Cc: Geert Uyt
On 09/10/17 14:00, Florian Fainelli wrote:
> Le 10/08/17 à 20:23, Greg Ungerer a écrit :
>> On 07/10/17 13:04, Florian Fainelli wrote:
>>> Le 10/03/17 à 23:20, Greg Ungerer a écrit :
>>>> On Wed, Mar 29, 2017 at 04:30:16PM -0400, Vivien Didelot wrote:
>>>>
Hi Florian,
On 07/10/17 13:04, Florian Fainelli wrote:
> Le 10/03/17 à 23:20, Greg Ungerer a écrit :
>> On Wed, Mar 29, 2017 at 04:30:16PM -0400, Vivien Didelot wrote:
>>> All ports -- internal and external, for chips featuring a PVT -- have a
>>> mask restricting to w
(s) */
> - if (dsa_is_cpu_port(ds, i) || dsa_is_dsa_port(ds, i))
> - output_ports |= BIT(i);
> - }
> - }
> + u16 output_ports = mv88e6xxx_port_vlan(chip, chip->ds->index, port);
>
>
stats64. Note that the other stats fields remain as 32bit
sized values (error counts, etc).
The motivation to add this is that it is not particularly difficult to
get the RX and TX byte counts to wrap on 32bit platforms.
Signed-off-by: Greg Ungerer
---
drivers/net/usb/asix_devices.c| 3
Hi Oliver,
On 31/03/17 19:39, Oliver Neukum wrote:
Am Freitag, den 31.03.2017, 10:48 +0200 schrieb Bjørn Mork:
You get *all* the "0" line drivers for free, not only "qmi_wwan". No
code changes needed, except for adding the single .ndo line to drivers
overriding the usbnet default net_device_op
Hi Bjorn,
On 31/03/17 18:48, Bjørn Mork wrote:
Greg Ungerer writes:
Add support for the net stats64 counters to the usbnet core and then to
the qmi_wwan driver.
This is a strait forward addition of 64bit counters for RX and TX packets
and byte counts. It is done in the same style as for the
to use 64bit stats we can remove the code to increment those.
The motivation to add this is that it is not particularly difficult to
get the RX and TX byte counts to wrap on 32bit platforms.
Signed-off-by: Greg Ungerer
---
drivers/net/usb/qmi_wwan.c | 1 +
drivers/net/usb/usbnet.c | 52
Hi Eric,
On 24/03/17 14:59, Eric Dumazet wrote:
> On Fri, 2017-03-24 at 11:27 +1000, Greg Ungerer wrote:
>> Add support for the net stats64 counters to the usbnet core and then to
>> the qmi_wwan driver.
>>
>> This is a strait forward addition of 64bit counters for RX
usbnet core. Then it is trivial to use
that in the qmi_wwan.c driver. It would be very simple to extend this
support to other usbnet based drivers.
The motivation to add this is that it is not particularly difficult to
get the RX and TX byte counts to wrap on 32bit platforms.
Signed-off-by: Greg
Hi Oliver,
On 23/03/17 18:46, Oliver Neukum wrote:
Am Donnerstag, den 23.03.2017, 11:25 +1000 schrieb Greg Ungerer:
Add support for the net stats64 counters to the usbnet core and then to
the qmi_wwan driver.
This is a strait forward addition of 64bit counters for RX and TX packets
and byte
Hi Bjorn,
On 23/03/17 18:33, Bjørn Mork wrote:
Greg Ungerer writes:
Add support for the net stats64 counters to the usbnet core and then to
the qmi_wwan driver.
This is a strait forward addition of 64bit counters for RX and TX packets
and byte counts. It is done in the same style as for the
usbnet core. Then it is trivial to use
that in the qmi_wwan.c driver. It would be very simple to extend this
support to other usbnet based drivers.
The motivation to add this is that it is not particularly difficult to
get the RX and TX byte counts to wrap on 32bit platforms.
Signed-off-by: Greg
t; Coldfire.
>
> Move the FEC_FTRL register access inside the FEC_QUIRK_HAS_RACC 'if' block,
> so that we guarantee it will not be used on Coldfire CPUs.
>
> Reported-by: Greg Ungerer
> Signed-off-by: Fabio Estevam
> ---
> drivers/net/ethernet/freescale/fec_mai
Hi Andy,
On 31/03/16 11:41, Fugang Duan wrote:
> From: Fabio Estevam Sent: Thursday, March 31, 2016 2:37
> AM
>> To: Greg Ungerer
>> Cc: Troy Kisky ; netdev@vger.kernel.org
>> Subject: Re: [PATCH] net: fec: stop the "rcv is not +last, " error messages
>>
Hi Fabio,
On 31/03/16 04:37, Fabio Estevam wrote:
> Hi Greg,
>
> On Wed, Mar 30, 2016 at 12:24 AM, Greg Ungerer wrote:
>> Hi Troy,
>>
>> Commit 55cd48c8 ('net: fec: stop the "rcv is not +last, " error
>> messages') adds a write to a register
Hi Troy,
Commit 55cd48c8 ('net: fec: stop the "rcv is not +last, " error
messages') adds a write to a register that is not present in all
implementations of the FEC hardware module. None of the ColdFire
SoC parts with the FEC module have the FTRL (0x1b0) register.
Does this need a quirk flag to k
Hi Johannes,
On 25/01/16 01:52, Johannes Berg wrote:
> The driver treats the device descriptors as CPU-endian, which appears
> to be correct with the default endianness on both ARM (typically LE)
> and PowerPC (typically BE) SoCs, indicating that the hardware block
> is generated differently. Add
>From 8969de63989b8814a6db9d00b9d1ceabe40e8b11 Mon Sep 17 00:00:00 2001
From: Greg Ungerer
Date: Sat, 20 Jun 2015 15:51:57 +1000
Subject: [PATCH] net: fec: don't access RACC register when not available
Not all silicon implementations of the Freescale FEC hardware module
have the RACC
bject: [PATCH] [NET]: Remove PowerPC code from fec.c
>
> fec.c is only used on M68k Coldfire CPUs. Remove leftover
> PowerPC code from this driver.
I was always hoping that this driver would be supported on both
architectures. After all the underlying eth device is essentially
the same on bot
46 matches
Mail list logo
