As I understand it the Meson GXL PHY driver is only useful on one
architecture so only make it visible on that architecture.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Fixes: 7334b3e47aee ("net: phy: Add Meson GXL Internal PHY driver")
Cc: Neil Armstrong <narmstr...@baylib
t was 92.
Would it make sense to explicitly set the enum values, or add them as
comments, to make such look-ups easier?
--
Jean Delvare
SUSE L3 Support
The mdio-xgene driver is only useful on X-Gene SoC.
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Cc: Iyappan Subramanian <isubraman...@apm.com>
Cc: David S. Miller <da...@davemloft.net>
---
drivers/net/phy/Kconfig |1 +
1 file changed, 1 insertion(+)
--- linux-4.8-rc5.or
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Fixes: a6d6786452 ("net: mdio-octeon: Modify driver to work on both ThunderX
and Octeon")
Cc: Florian Fainelli <f.faine...@gmail.com>
Cc: Sunil Goutham <sgout...@cavium.com>
Cc: Radha Mohan Chintakuntla <rchintakun
re")
Signed-off-by: Jean Delvare <jdelv...@suse.de>
Cc: Prashant Sreedharan <prash...@broadcom.com>
Cc: Michael Chan <mc...@broadcom.com>
Cc: sta...@vger.kernel.org [v3.6+]
---
drivers/net/ethernet/broadcom/tg3.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-
=14095865642r=1w=2
The idea was great IMHO but it did not work out, and I can't remember
why.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line unsubscribe netdev in
!CPU_LITTLE_ENDIAN)))
+ depends on PCI (BROKEN || !(PPC || PARISC || M68K || (MIPS
!CPU_LITTLE_ENDIAN) || FRV || (XTENSA !CPU_LITTLE_ENDIAN) || MICROBLAZE))
depends on VIRT_TO_BUS
help
This enables HiSax support for the Netspider U interface ISDN card
Acked-by: Jean Delvare jdelv
The xgene_enet driver is only useful on X-Gene SoC.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Iyappan Subramanian isubraman...@apm.com
Cc: Keyur Chudgar kchud...@apm.com
---
drivers/net/ethernet/apm/xgene/Kconfig |1 +
1 file changed, 1 insertion(+)
--- linux-4.1-rc2.orig/drivers
a better approach would be to not create the files at all when
they make no sense for a given type of bond.
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
Hi David,
Le mardi 30 octobre 2007, David Miller a écrit :
From: Andi Kleen [EMAIL PROTECTED]
Date: Fri, 26 Oct 2007 17:34:17 +0200
On Fri, Oct 26, 2007 at 05:21:31PM +0200, Jean Delvare wrote:
I propose 2 millions of entries as the arbitrary high limit. This
It's probably still far
, I
would welcome the proposals of alternatives.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
net/ipv4/tcp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.24-rc1.orig/net/ipv4/tcp.c2007-10-24 09:59:58.0
+0200
+++ linux-2.6.24-rc1/net/ipv4/tcp.c
Hi Herbert,
On Sun, 14 Oct 2007 18:09:12 +0800, Herbert Xu wrote:
Jean Delvare [EMAIL PROTECTED] wrote:
inet_diag is the preferred interface.
How does it work? Is there some documentation available? I see
net/ipv4/inet_diag.c but I have no idea how to use it.
Have a look
By adding module aliases to inet_diag, tcp_diag and dccp_diag, we let
them load automatically as needed. This makes tools like ss run
faster.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Cc: Alexey Kuznetsov [EMAIL PROTECTED]
---
The alias naming scheme for tcp_diag and dccp_diag follows what
Now that we have this new MODULE_ALIAS_NET_PF_PROTO_TYPE macro, use it
where possible.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Cc: Arnaldo Carvalho de Melo [EMAIL PROTECTED]
---
net/dccp/ipv4.c |4 ++--
net/dccp/ipv6.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions
* Say that this interface is deprecated.
* Update function name references to match the current code.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
Second version, updated based on Rick Jones' comments.
Documentation/networking/proc_net_tcp.txt |5 +++--
1 file changed, 3 insertions
Hi Herbert,
On Sat, 13 Oct 2007 20:49:56 +0800, Herbert Xu wrote:
Jean Delvare [EMAIL PROTECTED] wrote:
I didn't know that, sorry. What is the new interface to access the
TCP information?
inet_diag is the preferred interface.
How does it work? Is there some documentation available? I
Hi Rick,
On Fri, 12 Oct 2007 16:13:32 -0700, Rick Jones wrote:
Jean Delvare wrote:
Update function name references to match the current code.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
Documentation/networking/proc_net_tcp.txt |4 ++--
1 file changed, 2 insertions(+), 2
Update function name references to match the current code.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
Documentation/networking/proc_net_tcp.txt |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.23.orig/Documentation/networking/proc_net_tcp.txt 2007-02-04
19:44
Le Mardi 20 Mars 2007 08:19, Jean Delvare a écrit :
I noticed recently that, in skb_checksum(), offset and start are
essentially the same thing and have the same value throughout the
function, despite being computed differently. Using a single variable
allows some cleanups and makes
/xfrm_algo.c:skb_to_sgvec()
OTOH, I admit I'm a bit surprised, the cleanup is rather obvious so I'm
really wondering if I am missing something. Can anyone please comment
on this?
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
net/appletalk/ddp.c | 25 +
net/core/datagram.c | 50
Hi Stephen,
On 10/11/06, Stephen Hemminger wrote:
On Wed, 11 Oct 2006, Jesse Brandeburg wrote:
On 10/11/06, Jean Delvare wrote:
Let the e1000 driver report the most important statistics (rx/tx_bytes
and rx/tx_packets) in real time, rather than every other second. This
is similar
Hi Jesse,
On 10/11/06, Jesse Brandeburg wrote:
On 10/11/06, Jean Delvare wrote:
Let the e1000 driver report the most important statistics (rx/tx_bytes
and rx/tx_packets) in real time, rather than every other second. This
is similar to what the e100 driver is doing.
The current
bytes on some TX frames, which
I am not able to explain. It's probably small and rare enough not to
be considered a problem, but if someone can explain it, I would be
grateful.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c | 14 ++
1 file changed, 10
drivers are right? Are we counting the emitted
and received bytes at software level or at hardware level? Or do we just
not care about the 4-byte/packet difference and both are acceptable?
Thanks,
--
Jean Delvare
Suse L3
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body
24 matches
Mail list logo
