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
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
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
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
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
Hi Geert,
On 27/03/18 22:59, Geert Uytterhoeven wrote:
> On Mon, Mar 26, 2018 at 3:36 PM, Greg Ungerer <g...@linux-m68k.org> wrote:
>> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>> coherent_dma_mask") the Freescale FEC driver is issuing the
g special about the DMA memory coherency on this hardware
so we can just set the mask to 32bits during probe.
Signed-off-by: Greg Ungerer <g...@linux-m68k.org>
---
drivers/net/ethernet/freescale/fec_main.c | 2 ++
1 file changed, 2 insertions(+)
Is this the best way to handle this problem?
Comments
is patch 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 <g...@linux-m68k.org>
Looks right for mcf8390.c.
Acked-by: Greg Ungerer <g...@linu
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:
>>&g
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
allow sending frames to CPU port and DSA link(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->d
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 <g...@linux-m68k.org>
---
drivers/n
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
Hi Bjorn,
On 31/03/17 18:48, Bjørn Mork wrote:
Greg Ungerer <g...@linux-m68k.org> 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 i
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 <g...@linux-m68k.org>
---
drivers/net/usb/qmi_wwan.c | 1 +
drivers/n
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
is to 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
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 <g...@linux-m68k.org> 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 i
is to 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
ster that does not exist in
> 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 <g...@uclinux.org>
> Signed-off-by: Fabio Estevam <fabio.est
Hi Andy,
On 31/03/16 11:41, Fugang Duan wrote:
> From: Fabio Estevam <feste...@gmail.com> Sent: Thursday, March 31, 2016 2:37
> AM
>> To: Greg Ungerer <g...@uclinux.org>
>> Cc: Troy Kisky <troy.ki...@boundarydevices.com>; netdev@vger.kernel.org
>> Su
Hi Fabio,
On 31/03/16 04:37, Fabio Estevam wrote:
> Hi Greg,
>
> On Wed, Mar 30, 2016 at 12:24 AM, Greg Ungerer <g...@uclinux.org> wrote:
>> Hi Troy,
>>
>> Commit 55cd48c8 ('net: fec: stop the "rcv is not +last, " error
>> messages') adds
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
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 g...@uclinux.org
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
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 both.
Anyway... I don't have a problem with this patch, looks ok
the me.
Acked-by: Greg Ungerer [EMAIL PROTECTED]
Regards
Greg
Signed
31 matches
Mail list logo
