n opening attachments, clicking links, or responding.
> >
> >
> > Add testfile for lan743x network driver.
> > Testfile includes the verification of status of autonegotiation.
> > Ksft modules and ethtool are used for the testing.
> > net/lib libraries are includ
On 9/3/2024 3:15 PM, Mohan Prasad J wrote:
Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.
Add testfile for lan743x network driver.
Testfile includes the verification of status of autonegotiation.
Ksft
Add testfile for lan743x network driver.
Testfile includes the verification of status of autonegotiation.
Ksft modules and ethtool are used for the testing.
net/lib libraries are included for testing.
Add the __init__.py file.
Include /microchip/lan743x as a target in Makefile.
Updated MAINTAINERS
On 9/16/20 6:07 AM, Manivannan Sadhasivam wrote:
>>> Just a quick question: I don't see any activity on this specific driver for
>>> sometime (back in Martin days itself). Is it due to lack of reviewers or
>>> it is due to the patch size (lines of code) so that nobody is interested
>>> in reviewing
Hi,
On Tue, Sep 15, 2020 at 07:58:38PM +0200, Kurt Van Dijck wrote:
> On di, 15 sep 2020 21:49:25 +0530, Manivannan Sadhasivam wrote:
> > Hi,
> >
> > On Thu, Sep 10, 2020 at 07:08:00PM +0530, Manivannan Sadhasivam wrote:
> > > Hello,
> >
> > Just a quick question: I don't see any activity on thi
tps://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/log/?h=mcp25xxfd-47
>
> Kurt Van Dijck (1):
> can: mcp25xxfd: add listen-only mode
>
> Manivannan Sadhasivam (1):
> MAINTAINERS: Add entry for Microchip MCP25XXFD SPI-CAN network driver
>
> Marc Kl
On di, 15 sep 2020 21:49:25 +0530, Manivannan Sadhasivam wrote:
> Hi,
>
> On Thu, Sep 10, 2020 at 07:08:00PM +0530, Manivannan Sadhasivam wrote:
> > Hello,
>
> Just a quick question: I don't see any activity on this specific driver for
> sometime (back in Martin days itself). Is it due to lack of
(1):
MAINTAINERS: Add entry for Microchip MCP25XXFD SPI-CAN network driver
Marc Kleine-Budde (3):
can: rx-offload: can_rx_offload_add_manual(): add new initialization
function
can: mcp25xxfd: add regmap infrastructure
can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN
Oleksij
Add MAINTAINERS entry for Microchip MCP25XXFD SPI-CAN network driver.
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b5cfab015bd6..e4ddf908a8b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
On Wed, 2020-07-15 at 17:44 -0700, Jakub Kicinski wrote:
> On Thu, 9 Jul 2020 22:49:25 +0200 Alexander A. Klimov wrote:
> > Rationale:
> > Reduces attack surface on kernel devs opening the links for MITM
> > as HTTPS traffic is much harder to manipulate.
> >
> > Deterministic algorithm:
> > For e
On Thu, 9 Jul 2020 22:49:25 +0200 Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't cont
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
Add MAINTAINERS entry for Microchip MCP25XXFD CAN network driver.
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b816a453b10e..591b6fc2d83a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10360,6
Add MAINTAINERS entry for Microchip MCP25XXFD CAN network driver.
Signed-off-by: Manivannan Sadhasivam
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b816a453b10e..591b6fc2d83a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10360,6
On 5/20/2018 8:17 PM, santosh.shilim...@oracle.com wrote:
On 5/11/18 12:29 PM, Murali Karicheri wrote:
Now that NetCP driver patches for K2G SoC is merged to linux-next master
this series add patches to enable network driver on K2G ICE and GP EVMs.
Thanks
Applied the patches on top of
On 05/20/2018 11:17 PM, santosh.shilim...@oracle.com wrote:
> On 5/11/18 12:29 PM, Murali Karicheri wrote:
>> Now that NetCP driver patches for K2G SoC is merged to linux-next master
>> this series add patches to enable network driver on K2G ICE and GP EVMs.
>>
>> Thank
On 5/11/18 12:29 PM, Murali Karicheri wrote:
Now that NetCP driver patches for K2G SoC is merged to linux-next master
this series add patches to enable network driver on K2G ICE and GP EVMs.
Thanks
Applied the patches on top of latest linux-next master, built kernel and
booted up on both EVMs
Now that NetCP driver patches for K2G SoC is merged to linux-next master
this series add patches to enable network driver on K2G ICE and GP EVMs.
Thanks
Applied the patches on top of latest linux-next master, built kernel and
booted up on both EVMs. The logs are below
K2G GP EVM: https
Add dt bindings to enable netcp network driver on K2G GP EVM. This
consists of enabling bindings for nss qmss, pktdma, 2u ethss,
mdio, pinmux and netcp devices.
Signed-off-by: Murali Karicheri
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 53 ++
1 file changed, 53
This patch adds dt bindings to enable netcp network driver on K2G
ICE boards. This consists of enabling bindings for NSS qmss, pktdma,
2u ethss, mdio, pinmux and netcp devices as well as DP83867 phy.
EVM hardware spec recommends to add 0.25 nsec delay in the tx direction
and 2.25 nsec delay in
This patch add dt bindings to support network driver based on
Network Sub System (NSS) found on k2g SoC. This consists of
bindings for netcp node, nss qmss , pktdma, cpsw 2u version
of ethss and mdio.
In order to support transitioning between non-promiscuous
and promiscuous modes in K2G&#
On 04/02/2018 12:28 PM, David Miller wrote:
> From: Murali Karicheri
> Date: Mon, 2 Apr 2018 12:17:17 -0400
>
>> This patch adds support for promiscuous mode in network driver for K2G
>> SoC. This depends on v3 of my series at
>> https://www.spinics.net/lists/kernel/m
From: Murali Karicheri
Date: Mon, 2 Apr 2018 12:17:17 -0400
> This patch adds support for promiscuous mode in network driver for K2G
> SoC. This depends on v3 of my series at
> https://www.spinics.net/lists/kernel/msg2765942.html
The net-next tree is closed, please resubmit this ser
This patch adds support for promiscuous mode in network driver for K2G
SoC. This depends on v3 of my series at
https://www.spinics.net/lists/kernel/msg2765942.html
I plan to fold this to the above series and submit again when the net-next
merge windows opens. At this time, please review and let
> Date: Sun, 11 Mar 2018 16:06:16 +0100
>
> Some update suggestions were taken into account
> from static source code analysis.
…
> Delete unnecessary code in user_init_raw_fds()
> Less checks in user_init_raw_fds() after error detection
> Adjust an error message in user_init_socket_fds()
>
From: Markus Elfring
Date: Sun, 11 Mar 2018 16:06:16 +0100
Some update suggestions were taken into account
from static source code analysis.
Markus Elfring (9):
Delete unnecessary code in user_init_raw_fds()
Less checks in user_init_raw_fds() after error detection
Adjust an error message i
We want to add the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way? These are the
prerequisite patches that are n
We want to add the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way? These are the
prerequisite patches that are n
David,
On Fri, Dec 8, 2017 at 1:09 AM, David Daney wrote:
[]
> Changes in v5:
[]
> o Removed redundant licensing text boilerplate.
Thank you very much!
Acked-by: Philippe Ombredanne
--
Cordially
Philippe Ombredanne, the licensing scruffy
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first five patches add the SoC support need
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first five patches add the SoC support need
The net-next tree is closed, please resubmit this when the net-next
tree opens again.
Thank you.
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first six patches add the SoC support need
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first six patches add the SoC support need
I need to send v3. With this v2 set, there is a small bug in the RX
initialization that causes failure on little-endian kernels.
David.
On 11/08/2017 04:51 PM, David Daney wrote:
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first six patches add the SoC support need
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first five patches add the SoC support need
I will be maintaining the Thunderbolt network driver along with Michael
and Yehezkel.
Signed-off-by: Michael Jamet
Signed-off-by: Yehezkel Bernat
Signed-off-by: Mika Westerberg
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index
INERS
@@ -9128,6 +9128,13 @@ T: git
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
S: Supported
F: drivers/net/wireless/ath/ath10k/
+QUALCOMM TECHNOLOGIES EMAC NETWORK DRIVER
+M: Timur Tabi
+R: Gilad Avidov
+L: net...@vger.kernel.org
+S: Supported
+F: dr
Since ezchip network driver was adapted to little endian architecture
this patch provides the corresponding arch/arc/{boot/dts,configs}/ updates so
we can switch over to this device-model/driver for OSCI platform.
Signed-off-by: Lada Trimasova
Cc: Alexey Brodkin
Cc: Vineet Gupta :
---
arch/arc
On 07/20/2015 05:49 PM, Frederic Weisbecker wrote:
On Mon, Jul 20, 2015 at 05:22:12PM -0400, Chris Metcalf wrote:
On 07/11/2015 10:30 AM, Frederic Weisbecker wrote:
On Fri, Jul 10, 2015 at 03:05:02PM -0400, Chris Metcalf wrote:
The tilegx chips typically don't do cpu offlining anyway, since
we
On Mon, Jul 20, 2015 at 05:22:12PM -0400, Chris Metcalf wrote:
> On 07/11/2015 10:30 AM, Frederic Weisbecker wrote:
> >On Fri, Jul 10, 2015 at 03:05:02PM -0400, Chris Metcalf wrote:
> >>The tilegx chips typically don't do cpu offlining anyway, since
> >>we've never really found a usecase, so whatev
On 07/11/2015 10:30 AM, Frederic Weisbecker wrote:
On Fri, Jul 10, 2015 at 03:05:02PM -0400, Chris Metcalf wrote:
The tilegx chips typically don't do cpu offlining anyway, since
we've never really found a usecase, so whatever you boot with
you always have available. We do have support for a bar
From: Chris Metcalf
Normally the tilegx networking shim sends irqs to all the cores
to distribute the load of processing incoming-packet interrupts,
so that you can get to multiple Gb's of traffic inbound.
However, in nohz_full mode we don't want to interrupt the
nohz_full cores by default, so w
> On Jul 11, 2015, at 10:44 AM, Frederic Weisbecker wrote:
>
>> On Fri, Jul 10, 2015 at 03:37:25PM -0400, Chris Metcalf wrote:
>> Normally the tilegx networking shim sends irqs to all the cores
>> to distribute the load of processing incoming-packet interrupts,
>> so that you can get to multiple
On Fri, Jul 10, 2015 at 03:37:25PM -0400, Chris Metcalf wrote:
> Normally the tilegx networking shim sends irqs to all the cores
> to distribute the load of processing incoming-packet interrupts,
> so that you can get to multiple Gb's of traffic inbound.
>
> However, in nohz_full mode we don't wan
On Fri, Jul 10, 2015 at 03:05:02PM -0400, Chris Metcalf wrote:
> On 07/10/2015 02:24 PM, Frederic Weisbecker wrote:
> >Indeed we are doing more and more references on housekeeping_mask, so
> >we should probably think about an off-case.
> >
> >Now the nohz-full off-case should rather be cpu_possible
On Fri, Jul 10, 2015 at 07:06:23PM -0400, Chris Metcalf wrote:
> On 7/10/2015 6:45 PM, Josh Cartwright wrote:
> >>+static inline const struct cpumask *housekeeping_cpumask(void)
> >>>+{
> >>>+#ifdef CONFIG_NO_HZ_FULL
> >>>+ if (tick_nohz_full_enabled())
> >>>+ return housekeeping_mask;
>
On 7/10/2015 6:45 PM, Josh Cartwright wrote:
+static inline const struct cpumask *housekeeping_cpumask(void)
>+{
>+#ifdef CONFIG_NO_HZ_FULL
>+ if (tick_nohz_full_enabled())
>+ return housekeeping_mask;
>+#endif
Just a small comment:
We can take these checks out from under a #ifdef C
On Fri, Jul 10, 2015 at 03:37:25PM -0400, Chris Metcalf wrote:
> Normally the tilegx networking shim sends irqs to all the cores
> to distribute the load of processing incoming-packet interrupts,
> so that you can get to multiple Gb's of traffic inbound.
>
> However, in nohz_full mode we don't wan
Normally the tilegx networking shim sends irqs to all the cores
to distribute the load of processing incoming-packet interrupts,
so that you can get to multiple Gb's of traffic inbound.
However, in nohz_full mode we don't want to interrupt the
nohz_full cores by default, so we limit the set of cor
On 07/10/2015 02:24 PM, Frederic Weisbecker wrote:
On Fri, Jul 10, 2015 at 01:33:44PM -0400, Chris Metcalf wrote:
In nohz_full mode, by default distribute networking shim
interrupts across the housekeeping cores, not all the cores.
I can't really tell, I have no idea what this driver does. It s
On Fri, Jul 10, 2015 at 01:33:44PM -0400, Chris Metcalf wrote:
> In nohz_full mode, by default distribute networking shim
> interrupts across the housekeeping cores, not all the cores.
I can't really tell, I have no idea what this driver does. It seems
to be about networking CPUs but I have no ide
In nohz_full mode, by default distribute networking shim
interrupts across the housekeeping cores, not all the cores.
Signed-off-by: Chris Metcalf
---
The alternate approaches to this might be:
1. "#define housekeeping_mask cpu_online_mask" in the non-nohz_full
arm in , then just unconditiona
a (LIS)
Cc: KY Srinivasan; Кулешов Андрей Анатольевич; Mathieu Simon; Bernhard Walle
Sent: Wednesday, June 25, 2014 1:19 PM
Subject: Non-FIXed in Linux Kernel v3.14.8 2014-06-16 Fw: hyperv: Change the
receive buffer size for legacy hosts Re:
Regression in hyperv network driver in 3.14 Fw: Debian
> -Original Message-
> From: Bernhard Walle [mailto:bernh...@bwalle.de]
> Sent: Tuesday, May 27, 2014 10:42 AM
> To: KY Srinivasan
> Cc: Haiyang Zhang; linux-kernel@vger.kernel.org
> Subject: RE: Regression in hyperv network driver in 3.14
>
> Am 2014-05-27 15:4
Am 2014-05-27 15:43, schrieb KY Srinivasan:
Can I provide more information to track down the problem?
This bug has been fixed upstream. The issue is with regards to the
older hosts (ws2008 r2) not
Being able to handle the larger receive buffer currently used.
Can you point me to the commit t
> -Original Message-
> From: Bernhard Walle [mailto:bernh...@bwalle.de]
> Sent: Tuesday, May 27, 2014 4:10 AM
> To: Haiyang Zhang
> Cc: KY Srinivasan; linux-kernel@vger.kernel.org
> Subject: Regression in hyperv network driver in 3.14
>
> Hello,
>
> usi
Hello,
using a 3.14 kernel in a Linux VM running on HyperV (Windows Server 2008
R2) we get following error:
hv_netvsc: hv_netvsc channel opened successfully
hv_netvsc vmbus_0_9 (unregistered net_device): Unable to complete receive
buffer initialization with NetVsp - status 2
hv_netvsc v
Signed-off-by: Chris Metcalf
---
drivers/net/ethernet/tile/tilegx.c | 44 +-
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c
b/drivers/net/ethernet/tile/tilegx.c
index b80a91f..6d94d58 100644
--- a/drivers/net
The initial driver support was for a single mPIPE shim on the chip
(as is the case for the Gx36 hardware). The Gx72 chip has two mPIPE
shims, so we extend the driver to handle that case.
Signed-off-by: Chris Metcalf
---
arch/tile/gxio/iorpc_mpipe_info.c | 18 +
arch/tile/gxio/mpipe.c
Signed-off-by: Chris Metcalf
---
drivers/net/ethernet/tile/tilegx.c | 29 -
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c
b/drivers/net/ethernet/tile/tilegx.c
index 39c1e9e..e9eba2b 100644
--- a/drivers/net/ethernet/
Signed-off-by: Chris Metcalf
---
drivers/net/ethernet/tile/tilegx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c
b/drivers/net/ethernet/tile/tilegx.c
index 17bcf33..2b1c31f 100644
--- a/drivers/net/ethernet/tile/tilegx.c
+++ b/drivers/net
Signed-off-by: Chris Metcalf
---
arch/tile/gxio/iorpc_mpipe.c | 47 +
arch/tile/gxio/mpipe.c | 18 +-
arch/tile/include/gxio/iorpc_mpipe.h | 4 +
arch/tile/include/gxio/mpipe.h | 101 +-
drivers/net/ethernet/tile/tilegx.c | 347 +++
The code used to call napi_disable() in an interrupt handler
(from smp_call_function), which in turn could call msleep().
Unfortunately you can't sleep in an interrupt context.
Luckily it turns out all the NAPI support functions are
just operating on data structures and not on any deeply
per-cpu d
From: Chris Metcalf
Date: Wed, 31 Jul 2013 11:05:04 -0400
> @@ -1950,6 +1963,7 @@ static void tile_net_setup(struct net_device *dev)
> dev->features |= NETIF_F_HW_CSUM;
> dev->features |= NETIF_F_SG;
> dev->features |= NETIF_F_TSO;
> + dev->features |= NETIF_F_TSO6;
>
Signed-off-by: Chris Metcalf
---
drivers/net/ethernet/tile/tilegx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c
b/drivers/net/ethernet/tile/tilegx.c
index 58bd189..3a101b4 100644
--- a/drivers/net/ethernet/tile/tilegx.c
+++ b/drivers/net
The code used to call napi_disable() in an interrupt handler
(from smp_call_function), which in turn could call msleep().
Unfortunately you can't sleep in an interrupt context.
Luckily it turns out all the NAPI support functions are
just operating on data structures and not on any deeply
per-cpu d
Signed-off-by: Chris Metcalf
---
arch/tile/gxio/iorpc_mpipe.c | 47 +
arch/tile/gxio/mpipe.c | 18 +-
arch/tile/include/gxio/iorpc_mpipe.h | 4 +
arch/tile/include/gxio/mpipe.h | 101 +-
drivers/net/ethernet/tile/tilegx.c | 345 +++
The initial driver support was for a single mPIPE shim on the chip
(as is the case for the Gx36 hardware). The Gx72 chip has two mPIPE
shims, so we extend the driver to handle that case.
Signed-off-by: Chris Metcalf
---
arch/tile/gxio/iorpc_mpipe_info.c | 18 +
arch/tile/gxio/mpipe.c
Signed-off-by: Chris Metcalf
---
drivers/net/ethernet/tile/tilegx.c | 29 -
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c
b/drivers/net/ethernet/tile/tilegx.c
index f69f236..9ea88c8 100644
--- a/drivers/net/ethernet/
Signed-off-by: Chris Metcalf
---
drivers/net/ethernet/tile/tilegx.c | 44 +-
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c
b/drivers/net/ethernet/tile/tilegx.c
index 01068a9..ebc1b43 100644
--- a/drivers/net
From: Chris Metcalf
Date: Tue, 30 Jul 2013 20:34:52 -0400
> On 7/30/2013 7:16 PM, David Miller wrote:
>> From: Chris Metcalf
>> Date: Thu, 25 Jul 2013 12:41:15 -0400
>>
>>> Signed-off-by: Chris Metcalf
>> Applied, thanks.
>>
>> Your PTP patch for the Tile driver doesn't even come close to
>> ap
se respin it and report if
> you want me to apply it.
>
> Thanks.
It might be easiest to pull the whole series from:
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git
tile-net-next
Chris Metcalf (13):
tile: handle 64-bit statistics in tilepro network driver
From: Chris Metcalf
Date: Thu, 25 Jul 2013 12:41:15 -0400
> Signed-off-by: Chris Metcalf
Applied, thanks.
Your PTP patch for the Tile driver doesn't even come close to
applying properly to net-next, please respin it and report if
you want me to apply it.
Thanks.
--
To unsubscribe from this li
Signed-off-by: Chris Metcalf
---
v2: use primitives
drivers/net/ethernet/tile/tilepro.c | 77 ++---
1 file changed, 54 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilepro.c
b/drivers/net/ethernet/tile/tilepro.c
index 3643549..f66ac20 1
From: Chris Metcalf
Date: Tue, 23 Jul 2013 16:05:48 -0400
> Signed-off-by: Chris Metcalf
I'm pretty sure that you need to make use of the primitives in
include/linux/u64_stats_sync.h if you want to use 64-bit statistics
in this way.
--
To unsubscribe from this list: send the line "unsubscribe
On 7/23/2013 5:19 PM, Eric Dumazet wrote:
> On Tue, 2013-07-23 at 16:05 -0400, Chris Metcalf wrote:
>> Signed-off-by: Chris Metcalf
>> ---
>> drivers/net/ethernet/tile/tilegx.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/tile/tilegx.c
>> b/d
On Tue, 2013-07-23 at 16:05 -0400, Chris Metcalf wrote:
> Signed-off-by: Chris Metcalf
> ---
> drivers/net/ethernet/tile/tilegx.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/tile/tilegx.c
> b/drivers/net/ethernet/tile/tilegx.c
> index b34fd2c.
Signed-off-by: Chris Metcalf
---
drivers/net/ethernet/tile/tilepro.c | 42 ++---
1 file changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilepro.c
b/drivers/net/ethernet/tile/tilepro.c
index 3643549..0237031 100644
--- a/drivers/n
Signed-off-by: Chris Metcalf
---
drivers/net/ethernet/tile/tilegx.c | 29 -
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c
b/drivers/net/ethernet/tile/tilegx.c
index 8d1f748..a245858 100644
--- a/drivers/net/ethernet/
Signed-off-by: Chris Metcalf
---
arch/tile/gxio/iorpc_mpipe.c | 47 +
arch/tile/gxio/mpipe.c | 18 +-
arch/tile/include/gxio/iorpc_mpipe.h | 4 +
arch/tile/include/gxio/mpipe.h | 101 +-
drivers/net/ethernet/tile/tilegx.c | 349 +++
The initial driver support was for a single mPIPE shim on the chip
(as is the case for the Gx36 hardware). The Gx72 chip has two mPIPE
shims, so we extend the driver to handle that case.
Signed-off-by: Chris Metcalf
---
arch/tile/gxio/iorpc_mpipe_info.c | 18 +
arch/tile/gxio/mpipe.c
The code used to call napi_disable() in an interrupt handler
(from smp_call_function), which in turn could call msleep().
Unfortunately you can't sleep in an interrupt context.
Luckily it turns out all the NAPI support functions are
just operating on data structures and not on any deeply
per-cpu d
Signed-off-by: Chris Metcalf
---
drivers/net/ethernet/tile/tilegx.c | 44 +-
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c
b/drivers/net/ethernet/tile/tilegx.c
index 18eb7b9..04fe597 100644
--- a/drivers/net
Signed-off-by: Chris Metcalf
---
drivers/net/ethernet/tile/tilegx.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/tile/tilegx.c
b/drivers/net/ethernet/tile/tilegx.c
index b34fd2c..9c128ff 100644
--- a/drivers/net/ethernet/tile/tilegx.c
+++ b/drivers/n
Series applied, thanks Tony.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
v9 changes:
Code tidyup as requested by Francois Romieu.
v8 changes:
Remove velocity_choose_state from via-velocity.h: unused function.
v7 changes:
Forgot to merge a patch to fix an error with the pm ops changes. Apologies Dave.
v6 changes:
Remove more bus specific code from velocity_probe()
Mak
v8 changes:
Remove velocity_choose_state from via-velocity.h: unused function.
v7 changes:
Forgot to merge a patch to fix an error with the pm ops changes. Apologies Dave.
v6 changes:
Remove more bus specific code from velocity_probe()
Make velocity_(suspend/resume) accept a struct device *
Simpl
On 18/05/13 14:23, Tony Prisk wrote:
v7 changes:
Forgot to merge a patch to fix an error with the pm ops changes. Apologies Dave.
v6 changes:
Remove more bus specific code from velocity_probe()
Make velocity_(suspend/resume) accept a struct device *
Simplify PM code to use velocity_(suspend/resu
v7 changes:
Forgot to merge a patch to fix an error with the pm ops changes. Apologies Dave.
v6 changes:
Remove more bus specific code from velocity_probe()
Make velocity_(suspend/resume) accept a struct device *
Simplify PM code to use velocity_(suspend/resume) - remove the individual
pci and pla
On 18/05/13 12:36, David Miller wrote:
From: David Miller
Date: Fri, 17 May 2013 14:19:38 -0700 (PDT)
Series applied, thanks.
I'm reverting this, you're not using the correct types for the PM
functions you're hooking up.
drivers/net/ethernet/via/via-velocity.c:3238:8: warning: initialization
From: David Miller
Date: Fri, 17 May 2013 14:19:38 -0700 (PDT)
>
> Series applied, thanks.
I'm reverting this, you're not using the correct types for the PM
functions you're hooking up.
drivers/net/ethernet/via/via-velocity.c:3238:8: warning: initialization from
incompatible pointer type [ena
Series applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
v6 changes:
Remove more bus specific code from velocity_probe()
Make velocity_(suspend/resume) accept a struct device *
Simplify PM code to use velocity_(suspend/resume) - remove the individual
pci and platform functions.
Add a struct pci_dev variable to velocity_get_pci_info() to reduce churn
v5
v6 changes:
Remove more bus specific code from velocity_probe()
Make velocity_(suspend/resume) accept a struct device *
Simplify PM code to use velocity_(suspend/resume) - remove the individual
pci and platform functions.
Add a struct pci_dev variable to velocity_get_pci_info() to reduce churn
v5
Please resubmit this when the net-next tree opens again, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tu
v5 changes:
Remove velocity_info union. Change velocity_info->pdev back to struct pci_dev.
Remove more 'if (pci)' sections.
Remove 'void *pdev' function parameters.
Pass correct variable to velocity_choose_state()
v4 changes:
Code tidyup as requested by Francois Romieu
Removed '#ifdef PCI' around
On 02/05/13 06:52, David Miller wrote:
From: Tony Prisk
Date: Tue, 30 Apr 2013 18:16:57 +1200
I think it would be pertinent to get some tested-by's for PCI users.
Tony, this came in a bit late, and there hasn't been any PCI test
reports so I have to defer this to the next merge window, sorry.
From: Tony Prisk
Date: Tue, 30 Apr 2013 18:16:57 +1200
> I think it would be pertinent to get some tested-by's for PCI users.
Tony, this came in a bit late, and there hasn't been any PCI test
reports so I have to defer this to the next merge window, sorry.
--
To unsubscribe from this list: send
1 - 100 of 281 matches
Mail list logo
