> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Wednesday, December 28, 2016 12:34 AM
> To: Kweh, Hock Leong
> Cc: joao.pi...@synopsys.com; peppe.cavall...@st.com;
> seraphin.bonna...@st.com; f.faine...@gmail.com;
> alexandre.tor...@gmail.com; manab...@gmail.
Hello,
On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote:
> Hannes Frederic Sowa wrote:
> > On 24.12.2016 00:39, George Spelvin wrote:
> > > We just finished discussing why 8 bytes isn't enough. If you only
> > > feed back 8 bytes, an attacker who can do 2^64 computation can find it
> > > (
On 12/27/2016 08:47 PM, Rami Rosen wrote:
Hi, David,
For the Makefile, you should follow the pattern which is common in
Linux Kernel Ethernet drivers, for example,
http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/i40e/Makefile or
http://lxr.free-electrons.com/source/drivers/net/et
Hi, David,
Several nitpicks and comments, from a brief overview:
The commented label //err_exit: should be removed
> +++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
> @@ -0,0 +1,993 @@
> +//err_exit:
> +//err_exit:
Shouldn't aq_nic_rss_init() be static? isn't it called only from
aq_nic_cf
Hi, David,
For the Makefile, you should follow the pattern which is common in
Linux Kernel Ethernet drivers, for example,
http://lxr.free-electrons.com/source/drivers/net/ethernet/intel/i40e/Makefile or
http://lxr.free-electrons.com/source/drivers/net/ethernet/mellanox/mlx5/core/Makefile
Don't t
I know you are all chomping at the bit to bomb me with net-next
changes. :-)
From: Hannes Frederic Sowa
Date: Thu, 08 Dec 2016 15:04:17 +0100
> Hello David,
>
> On Mon, Nov 28, 2016, at 22:13, David Miller wrote:
>> From: David Ahern
>> Date: Sun, 27 Nov 2016 18:52:53 -0800
>>
>> > Andrey reported the following while fuzzing the kernel with syzkaller:
>> ...
>> > icmp
From: Florian Fainelli
Date: Tue, 27 Dec 2016 18:23:06 -0800
> There is currently a small window during which the network device registered
> by
> stmmac can be made visible, yet all resources, including and clock and MDIO
> bus
> have not had a chance to be set up, this can lead to the followi
There is currently a small window during which the network device registered by
stmmac can be made visible, yet all resources, including and clock and MDIO bus
have not had a chance to be set up, this can lead to the following error to
occur:
[ 473.919358] stmmaceth :01:00.0 (unnamed net_devi
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Wednesday, December 28, 2016 12:34 AM
> To: Kweh, Hock Leong
> Cc: joao.pi...@synopsys.com; peppe.cavall...@st.com;
> seraphin.bonna...@st.com; f.faine...@gmail.com;
> alexandre.tor...@gmail.com; manab...@gmail.
Just noticed this on 4.9. Will try and repro on 4.10rc1 later, but hitting
unrelated boot problems on that machine right now.
===
[ INFO: suspicious RCU usage. ]
4.9.0-backup-debug+ #1 Not tainted
---
./include/linux/rcupdate.h:557 Illegal co
Applied.
From: Joe Perches
Date: Wed, 21 Dec 2016 16:41:52 -0800
> Logging macros should allow format and argument validation.
> The DB_TX, DB_RX, and DB_GEN macros did not.
>
> Update the macros and uses and add no_printk validation to the
> previously compiled away #ifndef DEBUG variants.
>
> Done wit
From: Shyam Saini
Date: Sat, 24 Dec 2016 00:44:58 +0530
> when some other buffer is immediately copied into allocated region.
> Replace calls to kmalloc followed by a memcpy with a direct
> call to kmemdup.
>
> Signed-off-by: Shyam Saini
Applied.
> -Original Message-
> From: tndave [mailto:tushar.n.d...@oracle.com]
> Sent: Wednesday, December 28, 2016 6:28 AM
> To: maowenan; jeffrey.t.kirs...@intel.com; intel-wired-...@lists.osuosl.org
> Cc: netdev@vger.kernel.org; weiyongjun (A); Dingtianhong
> Subject: Re: [RFC PATCH] i40e: enab
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Alexander Duyck
> Sent: Tuesday, December 06, 2016 5:55 AM
> To: Tushar Dave
> Cc: Jeff Kirsher; intel-wired-lan; Netdev
> Subject: Re: [Intel-wired-lan] [RFC PATCH] i40e: enable
Robert Grasso :
[...]
> So, what is your opinion :
> - should I broaden my request for help to other teams than yours (kernel
> maintainers) ?
If I had to untangle this mess, I would check that my router is not
configured with an empty dhcp range. Then I would put each and every
interface facing
On 12/26/2016 03:39 AM, maowenan wrote:
-Original Message-
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
On Behalf Of Tushar Dave
Sent: Tuesday, December 06, 2016 1:07 AM
To: jeffrey.t.kirs...@intel.com; intel-wired-...@lists.osuosl.org
Cc: netdev@vger.kern
On 12/20/2016 07:20 PM, David Miller wrote:
> From: Florian Fainelli
> Date: Tue, 20 Dec 2016 17:02:37 -0800
>
>> On 12/14/2016 05:13 PM, Florian Fainelli wrote:
>>> The Octeon driver calls into PHYLIB which now checks for
>>> net_device->dev.parent, so make sure we do set it before calling into
On Sun, 2016-12-25 at 01:30 +0100, Thomas Preisner wrote:
> In some cases the return value of a failing function is not being used
> and the function typhoon_init_one() returns another negative error
> code instead.
I'm not sure these changes are especially valuable, since we'll need to
look at th
On Sun, 2016-12-25 at 01:30 +0100, Thomas Preisner wrote:
> Those spaces were actually left out purposely: The file in question
> (typhoon.c)
> is missing those spaces between the statements (if, for, while) and the
> following opening bracket pretty much always (except 2-3 times) and we figured
>
1) Various ipvlan fixes from Eric Dumazet and Mahesh Bandewar. The most
important is to not assume the packet is RX just because the destination
address matches that of the device. Such an assumption causes problems
when an interface is put into loopback mode.
2) If we retry when creat
Hello,
I have some unexpected (and interesting) news. I did not run the test
yet. While I was investigating my issue, I ordered a fast
Ethernet-to-USB3 converter, able to reach 1000Mbit/s, in order to
recover my broadband quickly : here is the chip as reported by dmesg :
[8.114327] ax881
From: Wei Zhang
Date: Tue, 27 Dec 2016 17:52:24 +0800
> When we send a packet for our own local address on a non-loopback
> interface (e.g. eth0), due to the change had been introduced from
> commit 0b922b7a829c ("net: original ingress device index in PKTINFO"), the
> original ingress device inde
On Tue, Dec 27, 2016 at 6:16 AM, Daniel Borkmann wrote:
> On 12/27/2016 10:58 AM, Herbert Xu wrote:
>>
>> On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote:
>>>
>>>
>>> According to Daniel, the networking folks want to let embedded systems
>>> include BPF without requiring the crypto
From: Alexander Duyck
Date: Tue, 27 Dec 2016 10:54:14 -0800
> Dave, I was wondering if you would be okay with me trying to push the
> three patches though net-next. I'm thinking I might scale back the
> first patch so that it is just a rename instead of making any
> functional changes. The main
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't currently harmful.
However, for some new features (e.g. K
On Fri, Dec 23, 2016 at 9:50 AM, David Miller wrote:
> From: Alexander Duyck
> Date: Fri, 23 Dec 2016 09:16:39 -0800
>
>> I tried to get in touch with Andrew about this fix but I haven't heard any
>> reply to the email I sent out on Tuesday. The last comment I had from
>> Andrew against v1 was "
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't currently harmful.
However, for some new features (e.g. K
For several reasons, it would be beneficial to kill off ACCESS_ONCE()
tree-wide, in favour of {READ,WRITE}_ONCE(). These work with aggregate
types, more obviously document their intended behaviour, and are
necessary for tools like KTSAN to work correctly (as otherwise reads and
writes cannot be ins
On Mon, Dec 26, 2016 at 3:39 AM, maowenan wrote:
>
>
>> -Original Message-
>> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
>> On Behalf Of Tushar Dave
>> Sent: Tuesday, December 06, 2016 1:07 AM
>> To: jeffrey.t.kirs...@intel.com; intel-wired-...@lists.osuosl.or
On 12/27/2016 05:47 PM, Marcelo Ricardo Leitner wrote:
> On Tue, Dec 27, 2016 at 09:25:47AM +0100, Matthias Tafelmeier wrote:
>> Oftenly, introducing side effects on packet processing on the other half
>> of the stack by adjusting one of TX/RX via sysctl is not desirable.
>> There are cases of dema
From: "Kweh, Hock Leong"
Date: Wed, 28 Dec 2016 04:07:41 +0800
> From: "Kweh, Hock Leong"
>
> Fixing the gmac4 mdio write access to use MII_GMAC4_WRITE only instead of
> OR together with MII_WRITE.
>
> Signed-off-by: Kweh, Hock Leong
Applied.
From: Jason Wang
Date: Tue, 27 Dec 2016 10:49:54 +0800
> After commit 73b62bd085f4737679ea9afc7867fa5f99ba7d1b ("virtio-net:
> remove the warning before XDP linearizing"), there's no users for
> bpf_warn_invalid_xdp_buffer(), so remove it. This is a revert for
> commit f23bc46c30ca5ef58b854943489
From: Chun-Hao Lin
Date: Tue, 27 Dec 2016 16:29:43 +0800
> This chip is the same as RTL8168, but its device id is 0x8161.
>
> Signed-off-by: Chun-Hao Lin
Applied.
From: Haishuang Yan
Date: Sun, 25 Dec 2016 14:33:16 +0800
> Different namespaces might have different requirements to reuse
> TIME-WAIT sockets for new connections. This might be required in
> cases where different namespace applications are in place which
> require TIME_WAIT socket connections t
From: Pravin B Shelar
Date: Mon, 26 Dec 2016 08:31:27 -0800
> Networking stack accelerate vlan tag handling by
> keeping topmost vlan header in skb. This works as
> long as packet remains in OVS datapath. But during
> OVS upcall vlan header is pushed on to the packet.
> When such packet is sent b
From: Marcelo Ricardo Leitner
Date: Tue, 27 Dec 2016 15:08:27 -0200
> Some cleanups/simplifications I've been collecting.
Please resubmit these when I open the net-next tree back up.
Thank you.
There is no reason to use this cascading. It doesn't add anything.
Let's remove it and simplify.
Signed-off-by: Marcelo Ricardo Leitner
---
include/net/sctp/structs.h | 7 +++
net/sctp/output.c | 14 +-
net/sctp/sm_statefuns.c| 5 +++--
3 files changed, 11 insertio
Signed-off-by: Marcelo Ricardo Leitner
---
net/sctp/sm_statefuns.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index
9a223d5b2314ff166be0446462c33219b7eec1b9..3382ef254e7b41ae4723f2e72e5aca30d46a4a8e
10064
Make it a bit easier to read.
Signed-off-by: Marcelo Ricardo Leitner
---
net/sctp/ipv6.c | 16 +++-
net/sctp/protocol.c | 18 +++---
2 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index
176af3080a2b8f8ffc56b55f3ccb1
Some cleanups/simplifications I've been collecting.
Marcelo Ricardo Leitner (5):
sctp: reduce indent level at sctp_sf_tabort_8_4_8
sctp: reduce indent level in sctp_sf_shut_8_4_5
sctp: simplify addr copy
sctp: remove return value from sctp_packet_init/config
sctp: sctp_chunk_length_valid
Signed-off-by: Marcelo Ricardo Leitner
---
net/sctp/sm_statefuns.c | 44 +---
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index
8ec20a64a3f8055a0c3576627c5ec5dad7e99ca8..32587b1f84e72922
Signed-off-by: Marcelo Ricardo Leitner
---
net/sctp/sm_statefuns.c | 58 -
1 file changed, 28 insertions(+), 30 deletions(-)
diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index
32587b1f84e729221965e270607fea7ef93a7430..a95915ef9db
This commit adjusts the allocation and freeing of BM pools to support
PPv2.2. This involves:
- Checking that the number of buffer pointers is a multiple of 16, as
required by the hardware.
- Adjusting the size of the DMA coherent area allocated for buffer
pointers. Indeed, PPv2.2 needs sp
net-next is still closed, please do not submit cleanups and new features
This commit modifies the mvpp2_defaults_set() function to not do the
loopback and FIFO threshold initialization, which are not needed for
PPv2.2.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-
In PPv2.1, we have a maximum of 8 RXQs per port, with a default of 4
RXQs per port, and we were assigning RXQs 0->3 to the first port, 4->7
to the second port, 8->11 to the third port, etc.
In PPv2.2, we have a maximum of 32 RXQs per port, and we must allocate
RXQs from the range of 32 RXQs availa
This commit adjusts the mvpp2 driver register mapping and access logic
to support PPv2.2, to handle a number of differences.
Due to how the registers are laid out in memory, the Device Tree binding
for the "reg" property is different:
- On PPv2.1, we had a first area for the common registers, an
The PPv2.2 IP has a different TX and RX descriptor layout compared to
PPv2.1. In order to prepare for the introduction of PPv2.2 support in
mvpp2, this commit adds accessors for the different fields of the TX
and RX descriptors, and changes the code to use them.
For now, the mvpp2_port argument pa
In PPv2.2, the MVPP2_RXQ_DESC_ADDR_REG and MVPP2_TXQ_DESC_ADDR_REG
registers have a slightly different layout, because they need to contain
a 64-bit address for the RX and TX descriptor arrays. This commit
adjusts those functions accordingly.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ether
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 | 45
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git
The Marvell PPv2 Device Tree binding was so far only used to describe
the PPv2.1 network controller, used in the Marvell Armada 375.
A new version of this IP block, PPv2.2 is used in the Marvell Armada
7K/8K processor. This commit extends the existing binding so that it can
also be used to describ
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/ethernet
This commit adds the definition of the PPv2.2 HW descriptors, adjusts
the mvpp2_tx_desc and mvpp2_rx_desc structures accordingly, and adapts
the accessors to work on both PPv2.1 and PPv2.2.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 109 +++
The mvpp2_bm_bufs_add() currently creates a fake cookie by calling
mvpp2_bm_cookie_pool_set(), just to be able to call
mvpp2_pool_refill(). But all what mvpp2_pool_refill() does is extract
the pool ID from the cookie, and call mvpp2_bm_pool_put() with this ID.
Instead of doing this convoluted thin
This commit handles a few miscellaneous differences between PPv2.1 and
PPv2.2 in different areas, where code done for PPv2.1 doesn't apply for
PPv2.2 or needs to be adjusted (getting the MAC address, disabling PHY
polling, etc.).
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/m
This commit drops dead code from the mvpp2 driver. The 'in_use' and
'in_use_thresh' fields of 'struct mvpp2_bm_pool' are
incremented/decremented/initialized in various places. But they are only
used in one place:
if (is_recycle &&
(atomic_read(&bm_pool->in_use) < bm_pool->in_use_
This commit adapts the mvpp2 RX path to use the build_skb() method. Not
only build_skb() is now the recommended mechanism, but it also
simplifies the addition of support for the PPv2.2 variant.
Indeed, without build_skb(), we have to keep track for each RX
descriptor of the physical address of the
The PPv2.2 variant of the network controller needs an additional
clock, the "MG clock" in order for the IP block to operate
properly. This commit adds support for this additional clock to the
driver, reworking as needed the error handling path.
Signed-off-by: Thomas Petazzoni
---
drivers/net/eth
The MVPP2_RXQ_CONFIG_REG register has a slightly different layout
between PPv2.1 and PPv2.2, so this commit adapts the functions modifying
this register to accommodate for both the PPv2.1 and PPv2.2 cases.
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 32
The mvpp2 is going to be extended to support the Marvell Armada 7K/8K
platform, which is ARM64. As a preparation to this work, this commit
enables building the mvpp2 driver on ARM64, by:
- Adjusting the Kconfig dependency
- Fixing the types used in the driver so that they are 32/64-bits
comp
Currently, mvpp2_rx_pkts_coal_set() does the following to avoid setting
a too large value for the RX coalescing by packet number:
val = (pkts & MVPP2_OCCUPIED_THRESH_MASK);
This means that if you set a value that is slightly higher the the
maximum number of packets, you in fact get a very low v
In preparation to the introduction for the support of PPv2.2 in the
mvpp2 driver, this commit adds a hw_version field to the struct
mvpp2, and uses the .data field of the DT match table to fill it in.
Having the MVPP21 and MVPP22 definitions available will allow to start
adding the necessary condi
Hello,
The goal of this patch series is to add basic support for PPv2.2 in
the existing mvpp2 driver. mvpp2 currently supported the PPv2.1
version of the IP, used in the 32 bits Marvell Armada 375 SoC. PPv2.2
is an evolution of this IP block, used in the 64 bits Marvell Armada
7K/8K SoCs.
In orde
When configuring the MVPP2_ISR_RX_THRESHOLD_REG with the RX coalescing
time threshold, we do not check for the maximum allowed value supported
by the driver, which means we might overflow and use a bogus value. This
commit adds a check for this situation, and if a value higher than what
is supporte
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/drive
Some of the MVPP2_PRS_RI_* definitions use the ~(value) syntax, which
doesn't compile nicely on 64-bit. Moreover, those definitions are in
fact unneeded, since they are always used in combination with a bit
mask that ensures only the appropriate bits are modified.
Therefore, such definitions shoul
Since the format of the HW descriptors is different between PPv2.1 and
PPv2.2, this commit introduces an intermediate union, with for now
only the PPv2.1 descriptors. The bulk of the driver code only
manipulates opaque mvpp2_tx_desc and mvpp2_rx_desc pointers, and the
descriptors can only be access
The mvpp2_txq_bufs_free() function is called upon TX completion to DMA
unmap TX buffers, and free the corresponding SKBs. It gets the
references to the SKB to free and the DMA buffer to unmap from a per-CPU
txq_pcpu data structure.
However, the code currently increments the pointer to the next ent
Hello,
This series contains a number of misc improvements and preparation
patches for an upcoming series that adds support for the new PPv2.2
network controller to the mvpp2 driver.
The most significant improvements are:
- Switching to using build_skb(), which is necessary for the upcoming
P
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index edffcc1..36c73dc 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/
Signed-off-by: Thomas Petazzoni
---
drivers/net/ethernet/marvell/mvpp2.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2.c
b/drivers/net/ethernet/marvell/mvpp2.c
index 8174f40..edffcc1 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/e
This commit remove a field of 'struct mvpp2_tx_queue' that is not used
anywhere.
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
b/drivers/net/ethernet/marvell/mvpp2.c
index d098c
On Tue, Dec 27, 2016 at 09:25:47AM +0100, Matthias Tafelmeier wrote:
> Oftenly, introducing side effects on packet processing on the other half
> of the stack by adjusting one of TX/RX via sysctl is not desirable.
> There are cases of demand for asymmetric, orthogonal configurability.
>
> This hol
From: "Kweh, Hock Leong"
Date: Tue, 27 Dec 2016 22:42:36 +0800
> From: "Kweh, Hock Leong"
You are not the author of this change, do not take credit for it.
You have copied Florian's patch character by character, therefore
he is the author.
You also didn't CC: the netdev mailing list pr
Hello David,
A few days ago you told me to resend a patch
(https://lkml.org/lkml/2016/12/20/416) when the next-net git tree opened.
Is this a good time to resend?
Thanks,
Joao
Hello David,
A few days ago you told me to resend a patch
(https://lkml.org/lkml/2016/12/20/416) when the next-net git tree opened.
Is this a good time to resend?
Thanks,
Joao
On Tue, 2016-12-27 at 05:17 -0800, David VomLehn wrote:
> Patches to create the make and configuration files.
A few small things about this patch series that adds a
new driver:
These should be sent with a cover letter [0/N] so that
the reason this series is useful can be added to the
merge log.
Hi Dear !
How are you doing today,hope fine, My name is Lina and i am a girl. I saw your
profile today and decided to extend my greetings to you. But I do have the mind
that you could be a nice person is my believe and there are nice people out
there who can appreciate the value of friendship.a
Mark - I will split this off soon.
In the meantime - here is some more info about how we use it.
We do use NFC structures.I did find an interesting clue in that
there are certain bottles that cause neard to segfault, I'm not sure
what is different about them. We write a string, like
"coppol
On 12/27/2016 10:58 AM, Herbert Xu wrote:
On Mon, Dec 26, 2016 at 10:08:48AM -0800, Andy Lutomirski wrote:
According to Daniel, the networking folks want to let embedded systems
include BPF without requiring the crypto core.
Last I checked the IPv4 stack depended on the crypto API so this
sou
Add definitions of functions that interface directly with the hardware.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
.../ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.c | 1033
.../ethernet/aquantia/atlantic/hw_atl/hw_atl_llh.h
Add Atlantic A0-specific functions.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
.../ethernet/aquantia/atlantic/hw_atl/hw_atl_a0.c | 934 +
.../ethernet/aquantia/atlantic/hw_atl/hw_atl_a0.h | 35 +
.../aquantia/a
Add files containing the functions and definitions used in common in
different functional areas.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
drivers/net/ethernet/aquantia/atlantic/aq_cfg.h| 83 ++
drivers/net/e
Add support for code specific to the Atlantic NIC.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
drivers/net/ethernet/aquantia/atlantic/aq_nic.c| 993 +
drivers/net/ethernet/aquantia/atlantic/aq_nic.h| 111 ++
Add common functions for Atlantic hardware abstraction layer.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
.../aquantia/atlantic/hw_atl/hw_atl_utils.c| 545 +
.../aquantia/atlantic/hw_atl/hw_atl_utils.h
Patches to create the make and configuration files.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
drivers/net/ethernet/aquantia/atlantic/Kconfig | 9 ++
drivers/net/ethernet/aquantia/atlantic/Makefile | 40
Add the driver interfaces required for support by the ethtool utility.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
.../net/ethernet/aquantia/atlantic/aq_ethtool.c| 254 +
.../net/ethernet/aquantia/atlantic/aq_e
Add functions that handle the PCI bus interface.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
.../net/ethernet/aquantia/atlantic/aq_pci_func.c | 356 +
.../net/ethernet/aquantia/atlantic/aq_pci_func.h | 36 +++
Patches to create the make and configuration files.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
drivers/net/ethernet/aquantia/atlantic/Kconfig | 9 ++
drivers/net/ethernet/aquantia/atlantic/Makefile | 40
Add functions to interface with the hardware and some utility functions.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
drivers/net/ethernet/aquantia/atlantic/aq_hw.h | 170 +
.../net/ethernet/aquantia/atlantic/aq
Add definitions that support receive side scaling.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
drivers/net/ethernet/aquantia/atlantic/aq_rss.h | 35 +
1 file changed, 35 insertions(+)
create mode 100644 driver
Add code to support the firmware transmit and receive ring buffers.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 383 +++
drivers/net/ethernet/aquantia/atlantic/aq_
Add functions to manululate the vector of receive and transmit rings.
Signed-off-by: Dmitrii Tarakanov
Signed-off-by: Alexander Loktionov
Signed-off-by: David M. VomLehn
---
drivers/net/ethernet/aquantia/atlantic/aq_vec.c | 375
drivers/net/ethernet/aquantia/atlantic/a
Às 8:07 PM de 12/27/2016, Kweh, Hock Leong escreveu:
> From: "Kweh, Hock Leong"
>
> Fixing the gmac4 mdio write access to use MII_GMAC4_WRITE only instead of
> OR together with MII_WRITE.
>
> Signed-off-by: Kweh, Hock Leong
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |4 +++-
From: "Kweh, Hock Leong"
Fixing the gmac4 mdio write access to use MII_GMAC4_WRITE only instead of
OR together with MII_WRITE.
Signed-off-by: Kweh, Hock Leong
---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers
Hello,
I spotted in stmmac_main.c, *_dvr_probe() function, some clocks initializations
that are related with platform based setups:
priv->pclk = devm_clk_get(priv->device, "pclk");
if (IS_ERR(priv->pclk)) {
if (PTR_ERR(priv->pclk) == -EPROBE_DEFER) {
On Tue 2016-12-27 22:42:36, Kweh, Hock Leong wrote:
> From: "Kweh, Hock Leong"
>
> If kernel module stmmac driver being loaded after OS booted, there is a
> race condition between stmmac_open() and stmmac_mdio_register(), which is
> invoked inside stmmac_dvr_probe(), and the error is showed in dm
Hello!
On 12/27/2016 10:52 AM, Wei Zhang wrote:
When we send a packet for our own local address on a non-loopback interface
(e.g. eth0), due to the change had been introduced from commit 0b922b7a829c
("net: original ingress device index in PKTINFO"), the original ingress
device index would be s
1 - 100 of 106 matches
Mail list logo
