* pull-request: mac80211-next 2016-12-09
From: Johannes Berg @ 2016-12-09 12:00 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Hi Dave,
Closing net-next caught me by surprise, so I had to rebase a bit,
but these three patches really should go in soon. I'm not sending
them for 4.9 this late though.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit f81a8a02bb3b3e882ba6aa580230c13b5be64849:
Merge branch 'mV88e6xxx-interrupt-fixes' (2016-11-20 21:16:14 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-12-09
for you to fetch changes up to e6f462df9acd2a3295e5d34eb29e2823220cf129:
cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts (2016-12-09 12:57:49 +0100)
----------------------------------------------------------------
Three fixes:
* fix a logic bug introduced by a previous cleanup
* fix nl80211 attribute confusing (trying to use
a single attribute for two purposes)
* fix a long-standing BSS leak that happens when an
association attempt is abandoned
----------------------------------------------------------------
Johannes Berg (2):
nl80211: fix logic inversion in start_nan()
cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts
Vamsi Krishna (1):
nl80211: Use different attrs for BSSID and random MAC addr in scan req
include/net/cfg80211.h | 11 +++++++++++
include/uapi/linux/nl80211.h | 7 ++++++-
net/mac80211/mlme.c | 21 ++++++++++++---------
net/wireless/core.h | 1 +
net/wireless/mlme.c | 12 ++++++++++++
net/wireless/nl80211.c | 18 ++++++++++++++++--
net/wireless/sme.c | 14 ++++++++++++++
7 files changed, 72 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: netlink: GPF in sock_sndtimeo
From: Dmitry Vyukov @ 2016-12-09 11:53 UTC (permalink / raw)
To: Richard Guy Briggs; +Cc: netdev, LKML
In-Reply-To: <20161209114847.GX22655@madcap2.tricolour.ca>
On Fri, Dec 9, 2016 at 12:48 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2016-12-09 11:49, Dmitry Vyukov wrote:
>> On Fri, Dec 9, 2016 at 7:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > On 2016-11-29 23:52, Richard Guy Briggs wrote:
>> > I tried a quick compile attempt on the test case (I assume it is a
>> > socket fuzzer) and get the following compile error:
>> > cc -g -O0 -Wall -D_GNU_SOURCE -o socket_fuzz socket_fuzz.c
>> > socket_fuzz.c:16:1: warning: "_GNU_SOURCE" redefined
>> > <command-line>: warning: this is the location of the previous definition
>> > socket_fuzz.c: In function ‘segv_handler’:
>> > socket_fuzz.c:89: warning: implicit declaration of function ‘__atomic_load_n’
>> > socket_fuzz.c:89: error: ‘__ATOMIC_RELAXED’ undeclared (first use in this function)
>> > socket_fuzz.c:89: error: (Each undeclared identifier is reported only once
>> > socket_fuzz.c:89: error: for each function it appears in.)
>> > socket_fuzz.c: In function ‘loop’:
>> > socket_fuzz.c:280: warning: unused variable ‘errno0’
>> > socket_fuzz.c: In function ‘test’:
>> > socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_add’
>> > socket_fuzz.c:303: error: ‘__ATOMIC_SEQ_CST’ undeclared (first use in this function)
>> > socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_sub’
>>
>> -std=gnu99 should help
>> ignore warnings
>
> I got a little further, left with "__ATOMIC_RELAXED undeclared", "__ATOMIC_SEQ_CST
> undeclared" under gcc 4.4.7-16.
>
> gcc 4.8.2-15 leaves me with "undefined reference to `clock_gettime'"
add -lrt
> What compiler version do you recommend?
6.x sounds reasonable
4.4 branch is 7.5 years old, surprised that it does not disintegrate
into dust yet :)
>> >> - RGB
>> >
>> > - RGB
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: netlink: GPF in sock_sndtimeo
From: Richard Guy Briggs @ 2016-12-09 11:48 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: netdev, LKML
In-Reply-To: <CACT4Y+beWN9jmdTREk3JdEBQ3GRALGDJhy7pYF=wu3HdnNWEog@mail.gmail.com>
On 2016-12-09 11:49, Dmitry Vyukov wrote:
> On Fri, Dec 9, 2016 at 7:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > On 2016-11-29 23:52, Richard Guy Briggs wrote:
> > I tried a quick compile attempt on the test case (I assume it is a
> > socket fuzzer) and get the following compile error:
> > cc -g -O0 -Wall -D_GNU_SOURCE -o socket_fuzz socket_fuzz.c
> > socket_fuzz.c:16:1: warning: "_GNU_SOURCE" redefined
> > <command-line>: warning: this is the location of the previous definition
> > socket_fuzz.c: In function ‘segv_handler’:
> > socket_fuzz.c:89: warning: implicit declaration of function ‘__atomic_load_n’
> > socket_fuzz.c:89: error: ‘__ATOMIC_RELAXED’ undeclared (first use in this function)
> > socket_fuzz.c:89: error: (Each undeclared identifier is reported only once
> > socket_fuzz.c:89: error: for each function it appears in.)
> > socket_fuzz.c: In function ‘loop’:
> > socket_fuzz.c:280: warning: unused variable ‘errno0’
> > socket_fuzz.c: In function ‘test’:
> > socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_add’
> > socket_fuzz.c:303: error: ‘__ATOMIC_SEQ_CST’ undeclared (first use in this function)
> > socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_sub’
>
> -std=gnu99 should help
> ignore warnings
I got a little further, left with "__ATOMIC_RELAXED undeclared", "__ATOMIC_SEQ_CST
undeclared" under gcc 4.4.7-16.
gcc 4.8.2-15 leaves me with "undefined reference to `clock_gettime'"
What compiler version do you recommend?
> >> - RGB
> >
> > - RGB
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* [PATCH] uio-hv-generic: store physical addresses instead of virtual
From: Arnd Bergmann @ 2016-12-09 11:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: netdev, Arnd Bergmann, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, devel, linux-kernel
gcc warns about the newly added driver when phys_addr_t is wider than
a pointer:
drivers/uio/uio_hv_generic.c: In function 'hv_uio_mmap':
drivers/uio/uio_hv_generic.c:71:17: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
virt_to_phys((void *)info->mem[mi].addr) >> PAGE_SHIFT,
drivers/uio/uio_hv_generic.c: In function 'hv_uio_probe':
drivers/uio/uio_hv_generic.c:140:5: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
= (phys_addr_t)dev->channel->ringbuffer_pages;
drivers/uio/uio_hv_generic.c:147:3: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
(phys_addr_t)vmbus_connection.int_page;
drivers/uio/uio_hv_generic.c:153:3: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
(phys_addr_t)vmbus_connection.monitor_pages[1];
I can't see why we store a virtual address in a phys_addr_t here,
as the only user of that variable converts it into a physical
address anyway, so this moves the conversion to where it logically
fits according to the types.
Fixes: 95096f2fbd10 ("uio-hv-generic: new userspace i/o driver for VMBus")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/uio/uio_hv_generic.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c
index ad3ab5805ad8..50958f167305 100644
--- a/drivers/uio/uio_hv_generic.c
+++ b/drivers/uio/uio_hv_generic.c
@@ -68,7 +68,7 @@ hv_uio_mmap(struct uio_info *info, struct vm_area_struct *vma)
mi = (int)vma->vm_pgoff;
return remap_pfn_range(vma, vma->vm_start,
- virt_to_phys((void *)info->mem[mi].addr) >> PAGE_SHIFT,
+ info->mem[mi].addr >> PAGE_SHIFT,
vma->vm_end - vma->vm_start, vma->vm_page_prot);
}
@@ -137,20 +137,20 @@ hv_uio_probe(struct hv_device *dev,
/* mem resources */
pdata->info.mem[TXRX_RING_MAP].name = "txrx_rings";
pdata->info.mem[TXRX_RING_MAP].addr
- = (phys_addr_t)dev->channel->ringbuffer_pages;
+ = virt_to_phys(dev->channel->ringbuffer_pages);
pdata->info.mem[TXRX_RING_MAP].size
= dev->channel->ringbuffer_pagecount * PAGE_SIZE;
pdata->info.mem[TXRX_RING_MAP].memtype = UIO_MEM_LOGICAL;
pdata->info.mem[INT_PAGE_MAP].name = "int_page";
pdata->info.mem[INT_PAGE_MAP].addr =
- (phys_addr_t)vmbus_connection.int_page;
+ virt_to_phys(vmbus_connection.int_page);
pdata->info.mem[INT_PAGE_MAP].size = PAGE_SIZE;
pdata->info.mem[INT_PAGE_MAP].memtype = UIO_MEM_LOGICAL;
pdata->info.mem[MON_PAGE_MAP].name = "monitor_pages";
pdata->info.mem[MON_PAGE_MAP].addr =
- (phys_addr_t)vmbus_connection.monitor_pages[1];
+ virt_to_phys(vmbus_connection.monitor_pages[1]);
pdata->info.mem[MON_PAGE_MAP].size = PAGE_SIZE;
pdata->info.mem[MON_PAGE_MAP].memtype = UIO_MEM_LOGICAL;
--
2.9.0
^ permalink raw reply related
* Synopsys Ethernet QoS
From: Joao Pinto @ 2016-12-09 11:29 UTC (permalink / raw)
To: davem
Cc: Giuseppe CAVALLARO, lars.persson, rabin.vincent, netdev,
andy.shevchenko, CARLOS.PALMINHA
Dear David Miller,
These past 2 weeks we have been discussing the right way to go in terms of
Synopsys QoS support in the kernel.
The approach that raised more supporters was:
a) Test /stmicro/stmmac driver in a reference hardware prototyping platform (QoS
IPK) [Status: In Progress | 90% finished]
b) Merge the necessary features from AXIS’ synopsys based qos driver to the
/stmicro/stmmac
[Status: In Queue]
c) Rename /stmicro/stmmac driver to synopsys/ and re-factor the driver if necessary
[Status: In Queue]
d) Add QoS features incrementally to the new synopsys/ driver
[Status: In Queue]
This approach has the green light from AXIS and STMicro maintainers (Lars and
Peppe).
I would like to know if you support this plan.
Best Regards,
Joao
^ permalink raw reply
* Re: Misalignment, MIPS, and ip_hdr(skb)->version
From: Jiri Benc @ 2016-12-09 11:26 UTC (permalink / raw)
To: Daniel Kahn Gillmor
Cc: linux-mips, Netdev, LKML, Hannes Frederic Sowa,
WireGuard mailing list
In-Reply-To: <87vauvhwdu.fsf@alice.fifthhorseman.net>
On Wed, 07 Dec 2016 23:34:21 -0500, Daniel Kahn Gillmor wrote:
> fwiw, i'm not convinced that "most protocols of the IETF follow this
> mantra". we've had multiple discussions in different protocol groups
> about shaving or bloating by a few bytes here or there in different
> protocols, and i don't think anyone has brought up memory alignment as
> an argument in any of the discussions i've followed.
Which is sad. One would expect that this would be well understood for
decades already.
Jiri
^ permalink raw reply
* Re: [PATCH V2 22/22] bnxt_re: Add bnxt_re driver build support
From: kbuild test robot @ 2016-12-09 11:21 UTC (permalink / raw)
To: Selvin Xavier; +Cc: kbuild-all, dledford, linux-rdma, netdev, Selvin Xavier
In-Reply-To: <1481266096-23331-23-git-send-email-selvin.xavier@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 7977 bytes --]
Hi Selvin,
[auto build test ERROR on rdma/master]
[also build test ERROR on v4.9-rc8 next-20161208]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Selvin-Xavier/Broadcom-RoCE-Driver-bnxt_re/20161209-154823
base: https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
config: parisc-allyesconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=parisc
All errors (new ones prefixed by >>):
drivers/infiniband/hw/bnxtre/bnxt_qplib_rcfw.c: In function 'bnxt_qplib_creq_irq':
>> drivers/infiniband/hw/bnxtre/bnxt_qplib_rcfw.c:359:2: error: implicit declaration of function 'prefetch' [-Werror=implicit-function-declaration]
prefetch(&creq_ptr[CREQ_PG(sw_cons)][CREQ_IDX(sw_cons)]);
^~~~~~~~
cc1: some warnings being treated as errors
--
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_service_nq':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:145:29: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
bnxt_qplib_arm_cq_enable((struct bnxt_qplib_cq *)
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:147:29: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
if (!nq->cqn_handler(nq, (struct bnxt_qplib_cq *)
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_nq_irq':
>> drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:182:2: error: implicit declaration of function 'prefetch' [-Werror=implicit-function-declaration]
prefetch(&nq_ptr[NQE_PG(sw_cons)][NQE_IDX(sw_cons)]);
^~~~~~~~
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_create_qp':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:484:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
psn_search = (unsigned long long int)
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_destroy_qp':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1071:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
__clean_cq(qp->scq, (u64)qp);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1073:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
__clean_cq(qp->rcq, (u64)qp);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function '__flush_sq':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1630:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function '__flush_rq':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1664:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_cq_process_req':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1688:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
qp = (struct bnxt_qplib_qp *)le64_to_cpu(hwcqe->qp_handle);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1720:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_cq_process_res_rc':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1782:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
qp = (struct bnxt_qplib_qp *)le64_to_cpu(hwcqe->qp_handle);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1794:19: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_cq_process_res_ud':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1836:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
qp = (struct bnxt_qplib_qp *)le64_to_cpu(hwcqe->qp_handle);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1847:19: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_cq_process_res_raweth_qp1':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1893:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
qp = (struct bnxt_qplib_qp *)le64_to_cpu(hwcqe->qp_handle);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1902:19: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c: In function 'bnxt_qplib_cq_process_terminal':
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:1964:7: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
qp = (struct bnxt_qplib_qp *)le64_to_cpu(hwcqe->qp_handle);
^
drivers/infiniband/hw/bnxtre/bnxt_qplib_fp.c:2005:21: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
cqe->qp_handle = (u64)qp;
^
cc1: some warnings being treated as errors
vim +/prefetch +359 drivers/infiniband/hw/bnxtre/bnxt_qplib_rcfw.c
bd53aa95 Selvin Xavier 2016-12-08 343 CREQ_DB_REARM(rcfw->creq_bar_reg_iomem, raw_cons,
bd53aa95 Selvin Xavier 2016-12-08 344 creq->max_elements);
bd53aa95 Selvin Xavier 2016-12-08 345 }
bd53aa95 Selvin Xavier 2016-12-08 346 spin_unlock_irqrestore(&creq->lock, flags);
bd53aa95 Selvin Xavier 2016-12-08 347 }
bd53aa95 Selvin Xavier 2016-12-08 348
bd53aa95 Selvin Xavier 2016-12-08 349 static irqreturn_t bnxt_qplib_creq_irq(int irq, void *dev_instance)
bd53aa95 Selvin Xavier 2016-12-08 350 {
bd53aa95 Selvin Xavier 2016-12-08 351 struct bnxt_qplib_rcfw *rcfw = dev_instance;
bd53aa95 Selvin Xavier 2016-12-08 352 struct bnxt_qplib_hwq *creq = &rcfw->creq;
bd53aa95 Selvin Xavier 2016-12-08 353 struct creq_base **creq_ptr;
bd53aa95 Selvin Xavier 2016-12-08 354 u32 sw_cons;
bd53aa95 Selvin Xavier 2016-12-08 355
bd53aa95 Selvin Xavier 2016-12-08 356 /* Prefetch the CREQ element */
bd53aa95 Selvin Xavier 2016-12-08 357 sw_cons = HWQ_CMP(creq->cons, creq);
bd53aa95 Selvin Xavier 2016-12-08 358 creq_ptr = (struct creq_base **)rcfw->creq.pbl_ptr;
bd53aa95 Selvin Xavier 2016-12-08 @359 prefetch(&creq_ptr[CREQ_PG(sw_cons)][CREQ_IDX(sw_cons)]);
bd53aa95 Selvin Xavier 2016-12-08 360
bd53aa95 Selvin Xavier 2016-12-08 361 tasklet_schedule(&rcfw->worker);
bd53aa95 Selvin Xavier 2016-12-08 362
bd53aa95 Selvin Xavier 2016-12-08 363 return IRQ_HANDLED;
bd53aa95 Selvin Xavier 2016-12-08 364 }
bd53aa95 Selvin Xavier 2016-12-08 365
bd53aa95 Selvin Xavier 2016-12-08 366 /* RCFW */
bd53aa95 Selvin Xavier 2016-12-08 367 int bnxt_qplib_deinit_rcfw(struct bnxt_qplib_rcfw *rcfw)
:::::: The code at line 359 was first introduced by commit
:::::: bd53aa95a8998c3192837b1d2d6c6e795adf3276 bnxt_re: Enabling RoCE control path
:::::: TO: Selvin Xavier <selvin.xavier@broadcom.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 47317 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock
From: Pavel Machek @ 2016-12-09 11:21 UTC (permalink / raw)
To: Francois Romieu
Cc: Lino Sanfilippo, bh74.an, ks.giri, vipul.pandya, peppe.cavallaro,
alexandre.torgue, davem, linux-kernel, netdev
In-Reply-To: <20161208231943.GA13102@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
On Fri 2016-12-09 00:19:43, Francois Romieu wrote:
> Lino Sanfilippo <LinoSanfilippo@gmx.de> :
> [...]
> > OTOH Pavel said that he actually could produce a deadlock. Now I wonder if
> > this is caused by that locking scheme (in a way I have not figured out yet)
> > or if it is a different issue.
>
> stmmac_tx_err races with stmmac_xmit.
Umm, yes, that looks real.
And that means that removing tx_lock will not be completely trivial
:-(. Lino, any ideas there?
netif_tx_lock_irqsave() would help, but afaict that one does not
exist.
Plus, does someone know how to trigger the status == tx_hard_error? I
tried powering down the switch, but that did not do it.
Thanks, Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] net: socket: preferred __aligned(size) for control buffer
From: Sergei Shtylyov @ 2016-12-09 11:14 UTC (permalink / raw)
To: kushwaha.a, davem; +Cc: netdev, akkushwaha9896
In-Reply-To: <1481201513-20783-1-git-send-email-kushwaha.a@samsung.com>
Hello!
On 12/8/2016 3:51 PM, kushwaha.a@samsung.com wrote:
> From: Amit Kushwaha <kushwaha.a@samsung.com>
>
> This patch cleanup checkpatch.pl warning
> WARNING: __aligned(size) is preferred over __attribute__((aligned(size)))
>
> Signed-off-by: Amit Kushwaha <kushwaha.a@samsung.com>
> ---
> net/socket.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/socket.c b/net/socket.c
> index e631894..5835383 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -1,3 +1,4 @@
> +
Why?
> /*
> * NET An implementation of the SOCKET network access protocol.
> *
[...]
MBR, Sergei
^ permalink raw reply
* Re: netlink: GPF in sock_sndtimeo
From: Richard Guy Briggs @ 2016-12-09 11:01 UTC (permalink / raw)
To: Cong Wang
Cc: linux-audit, Paul Moore, Dmitry Vyukov, David Miller,
Johannes Berg, Florian Westphal, Eric Dumazet, Herbert Xu, netdev,
LKML, syzkaller
In-Reply-To: <CAM_iQpWRe0tDk=wvXONG7hamH3EtE0nJuAOF1kVKJgdpMvz2DA@mail.gmail.com>
On 2016-12-08 22:57, Cong Wang wrote:
> On Thu, Dec 8, 2016 at 10:02 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> > I also tried to extend Cong Wang's idea to attempt to proactively respond to a
> > NETLINK_URELEASE on the audit_sock and reset it, but ran into a locking error
> > stack dump using mutex_lock(&audit_cmd_mutex) in the notifier callback.
> > Eliminating the lock since the sock is dead anways eliminates the error.
> >
> > Is it safe? I'll resubmit if this looks remotely sane. Meanwhile I'll try to
> > get the test case to compile.
>
> It doesn't look safe, because 'audit_sock', 'audit_nlk_portid' and 'audit_pid'
> are updated as a whole and race between audit_receive_msg() and
> NETLINK_URELEASE.
This is what I expected and why I originally added the mutex lock in the
callback... The dumps I got were bare with no wrapper identifying the
process context or specific error, so I'm at a bit of a loss how to
solve this (without thinking more about it) other than instinctively
removing the mutex.
Another approach might be to look at consolidating the three into one
identifier or derive the other two from one, or serialize their access.
> > @@ -1167,10 +1190,14 @@ static void __net_exit audit_net_exit(struct net *net)
> > {
> > struct audit_net *aunet = net_generic(net, audit_net_id);
> > struct sock *sock = aunet->nlsk;
> > +
> > + mutex_lock(&audit_cmd_mutex);
> > if (sock == audit_sock) {
> > audit_pid = 0;
> > + audit_nlk_portid = 0;
> > audit_sock = NULL;
> > }
> > + mutex_unlock(&audit_cmd_mutex);
>
> If you decide to use NETLINK_URELEASE notifier, the above piece is no
> longer needed, the net_exit path simply releases a refcnt.
Good point. It would have already killed it off. So this piece is
arguably too late anyways.
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* [PATCH] bnxt_re: fix itnull.cocci warnings
From: Julia Lawall @ 2016-12-09 10:54 UTC (permalink / raw)
To: Selvin Xavier; +Cc: dledford, linux-rdma, netdev, kbuild-all
list_for_each_entry iterator variable cannot be NULL.
Generated by: scripts/coccinelle/iterators/itnull.cocci
CC: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
url:
https://github.com/0day-ci/linux/commits/Selvin-Xavier/Broadcom-RoCE-Driver-bnxt_re/20161209-154823
base: https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
master
I received some other warnings as well. Not sure if they have been passed
along already:
>> drivers/infiniband/hw/bnxtre/bnxt_re_ib_verbs.c:2455:4-14: code aligned
with following code on line 2456
--
>> drivers/infiniband/hw/bnxtre/bnxt_re_main.c:1047:2-20: code aligned
with following code on line 1048
drivers/infiniband/hw/bnxtre/bnxt_re_main.c:1188:3-43: code aligned
with following code on line 1190
--
>> drivers/infiniband/hw/bnxtre/bnxt_re_main.c:834:6-8: ERROR: iterator
variable bound on line 832 cannot be NULL
^ permalink raw reply
* Re: stmmac driver...
From: Niklas Cassel @ 2016-12-09 10:50 UTC (permalink / raw)
To: Jie Deng
Cc: David Miller, alexandre.torgue, peppe.cavallaro, netdev,
CARLOS.PALMINHA, Joao.Pinto
In-Reply-To: <59b37368-8670-659a-c257-034f73a83136@synopsys.com>
Hello Jie Deng
In your cover letter you wrote
dwc-eth-xxx.x
The DWC ethernet core layer (DWC ECL). This layer contains codes
can be shared by different DWC series ethernet cores
Does this mean that code in dwc-eth-xxx.x is common to all
the different Synopsys IPs, GMAC, XGMAC and XLGMAC ?
Regards,
Niklas
On Fri, Dec 9, 2016 at 11:05 AM, Jie Deng <Jie.Deng1@synopsys.com> wrote:
>
>
> On 2016/12/8 23:25, David Miller wrote:
>> From: Alexandre Torgue <alexandre.torgue@st.com>
>> Date: Thu, 8 Dec 2016 14:55:04 +0100
>>
>>> Maybe I forget some series. Do you have others in mind ?
>> Please see the thread titled:
>>
>> "net: ethernet: Initial driver for Synopsys DWC XLGMAC"
>>
>> which seems to be discussing consolidation of various drivers
>> for the same IP core, of which stmmac is one.
>>
>> I personally am against any change of the driver name and
>> things like this, and wish the people doing that work would
>> simply contribute to making whatever changes they need directly
>> to the stmmac driver.
>>
>> You really need to voice your opinion when major changes are being
>> proposed for the driver you maintain.
>>
> Hi David and Alex,
>
> XLGMAC is not a version of GMAC. Synopsys has several IPs and each IP has
> several versions.
>
> GMAC(QoS): 3.5, 3.7, 4.0, 4.10, 4.20...
> XGMAC: 1.00, 1.10, 1.20, 2.00, 2.10, 2.11...
> XLGMAC (Synopsys DesignWare Core Enterprise Ethernet): this is a new IP.
>
> Regards,
> Jie
>
^ permalink raw reply
* Re: netlink: GPF in sock_sndtimeo
From: Dmitry Vyukov @ 2016-12-09 10:49 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Cong Wang, linux-audit, pmoore, David Miller, Johannes Berg,
Florian Westphal, Eric Dumazet, Herbert Xu, netdev, LKML,
syzkaller
In-Reply-To: <20161209060248.GT22655@madcap2.tricolour.ca>
On Fri, Dec 9, 2016 at 7:02 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2016-11-29 23:52, Richard Guy Briggs wrote:
>> On 2016-11-29 15:13, Cong Wang wrote:
>> > On Tue, Nov 29, 2016 at 8:48 AM, Richard Guy Briggs <rgb@redhat.com> wrote:
>> > > On 2016-11-26 17:11, Cong Wang wrote:
>> > >> It is racy on audit_sock, especially on the netns exit path.
>> > >
>> > > I think that is the only place it is racy. The other places audit_sock
>> > > is set is when the socket failure has just triggered a reset.
>> > >
>> > > Is there a notifier callback for failed or reaped sockets?
>> >
>> > Is NETLINK_URELEASE event what you are looking for?
>>
>> Possibly, yes. Thanks, I'll have a look.
>
> I tried a quick compile attempt on the test case (I assume it is a
> socket fuzzer) and get the following compile error:
> cc -g -O0 -Wall -D_GNU_SOURCE -o socket_fuzz socket_fuzz.c
> socket_fuzz.c:16:1: warning: "_GNU_SOURCE" redefined
> <command-line>: warning: this is the location of the previous definition
> socket_fuzz.c: In function ‘segv_handler’:
> socket_fuzz.c:89: warning: implicit declaration of function ‘__atomic_load_n’
> socket_fuzz.c:89: error: ‘__ATOMIC_RELAXED’ undeclared (first use in this function)
> socket_fuzz.c:89: error: (Each undeclared identifier is reported only once
> socket_fuzz.c:89: error: for each function it appears in.)
> socket_fuzz.c: In function ‘loop’:
> socket_fuzz.c:280: warning: unused variable ‘errno0’
> socket_fuzz.c: In function ‘test’:
> socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_add’
> socket_fuzz.c:303: error: ‘__ATOMIC_SEQ_CST’ undeclared (first use in this function)
> socket_fuzz.c:303: warning: implicit declaration of function ‘__atomic_fetch_sub’
-std=gnu99 should help
ignore warnings
> I also tried to extend Cong Wang's idea to attempt to proactively respond to a
> NETLINK_URELEASE on the audit_sock and reset it, but ran into a locking error
> stack dump using mutex_lock(&audit_cmd_mutex) in the notifier callback.
> Eliminating the lock since the sock is dead anways eliminates the error.
>
> Is it safe? I'll resubmit if this looks remotely sane. Meanwhile I'll try to
> get the test case to compile.
>
> This is being tracked as https://github.com/linux-audit/audit-kernel/issues/30
>
> Subject: [PATCH] audit: proactively reset audit_sock on matching NETLINK_URELEASE
>
> diff --git a/kernel/audit.c b/kernel/audit.c
> index f1ca116..91d222d 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -423,6 +423,7 @@ static void kauditd_send_skb(struct sk_buff *skb)
> snprintf(s, sizeof(s), "audit_pid=%d reset", audit_pid);
> audit_log_lost(s);
> audit_pid = 0;
> + audit_nlk_portid = 0;
> audit_sock = NULL;
> } else {
> pr_warn("re-scheduling(#%d) write to audit_pid=%d\n",
> @@ -1143,6 +1144,28 @@ static int audit_bind(struct net *net, int group)
> return 0;
> }
>
> +static int audit_sock_netlink_notify(struct notifier_block *nb,
> + unsigned long event,
> + void *_notify)
> +{
> + struct netlink_notify *notify = _notify;
> + struct audit_net *aunet = net_generic(notify->net, audit_net_id);
> +
> + if (event == NETLINK_URELEASE && notify->protocol == NETLINK_AUDIT) {
> + if (audit_nlk_portid == notify->portid &&
> + audit_sock == aunet->nlsk) {
> + audit_pid = 0;
> + audit_nlk_portid = 0;
> + audit_sock = NULL;
> + }
> + }
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block audit_netlink_notifier = {
> + .notifier_call = audit_sock_netlink_notify,
> +};
> +
> static int __net_init audit_net_init(struct net *net)
> {
> struct netlink_kernel_cfg cfg = {
> @@ -1167,10 +1190,14 @@ static void __net_exit audit_net_exit(struct net *net)
> {
> struct audit_net *aunet = net_generic(net, audit_net_id);
> struct sock *sock = aunet->nlsk;
> +
> + mutex_lock(&audit_cmd_mutex);
> if (sock == audit_sock) {
> audit_pid = 0;
> + audit_nlk_portid = 0;
> audit_sock = NULL;
> }
> + mutex_unlock(&audit_cmd_mutex);
>
> RCU_INIT_POINTER(aunet->nlsk, NULL);
> synchronize_net();
> @@ -1202,6 +1229,7 @@ static int __init audit_init(void)
> audit_enabled = audit_default;
> audit_ever_enabled |= !!audit_default;
>
> + netlink_register_notifier(&audit_netlink_notifier);
> audit_log(NULL, GFP_KERNEL, AUDIT_KERNEL, "initialized");
>
> for (i = 0; i < AUDIT_INODE_BUCKETS; i++)
> --
> 1.7.1
>
>
>> - RGB
>
> - RGB
>
> --
> Richard Guy Briggs <rgb@redhat.com>
> Kernel Security Engineering, Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH 37/50] netfilter: nf_tables: atomic dump and reset for stateful objects
From: Pablo Neira Ayuso @ 2016-12-09 10:24 UTC (permalink / raw)
To: Paul Gortmaker
Cc: netfilter-devel, David Miller, netdev, linux-next@vger.kernel.org
In-Reply-To: <CAP=VYLp-ZBFjR1W9=V_vyPYAi1=Yub3ugq6D8hkoLigcPaaxFg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]
Hi Paul,
On Thu, Dec 08, 2016 at 07:40:14PM -0500, Paul Gortmaker wrote:
> On Wed, Dec 7, 2016 at 4:52 PM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > This patch adds a new NFT_MSG_GETOBJ_RESET command perform an atomic
> > dump-and-reset of the stateful object. This also comes with add support
> > for atomic dump and reset for counter and quota objects.
>
> This triggered a new build failure in linux-next on parisc-32, which a
> hands-off bisect
> run lists as resulting from this:
>
> ERROR: "__cmpxchg_u64" [net/netfilter/nft_counter.ko] undefined!
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
> make: *** [sub-make] Error 2
> 43da04a593d8b2626f1cf4b56efe9402f6b53652 is the first bad commit
> commit 43da04a593d8b2626f1cf4b56efe9402f6b53652
> Author: Pablo Neira Ayuso <pablo@netfilter.org>
> Date: Mon Nov 28 00:05:44 2016 +0100
>
> netfilter: nf_tables: atomic dump and reset for stateful objects
>
> This patch adds a new NFT_MSG_GETOBJ_RESET command perform an atomic
> dump-and-reset of the stateful object. This also comes with add support
> for atomic dump and reset for counter and quota objects.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
>
> :040000 040000 6cd4554f69247e5c837db52342f26888beda1623
> 5908aca93c89e7922336546c3753bfcf2aceefba M include
> :040000 040000 f25d5831eb30972436bd198c5bb237a0cb0b4856
> 4ee5751c8de02bb5a8dcaadb2a2df7986d90f8e9 M net
> bisect run success
>
> Guessing this is more an issue with parisc than it is with netfilter, but I
> figured I'd mention it anyway.
I'm planning to submit this patch to parisc, I'm attaching it to this
email.
[-- Attachment #2: 0001-parisc-export-symbol-__cmpxchg_u64.patch --]
[-- Type: text/x-diff, Size: 1313 bytes --]
>From c9d320ac0be2a32a7b2bfad398be549865088ecf Mon Sep 17 00:00:00 2001
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Thu, 8 Dec 2016 22:55:33 +0100
Subject: [PATCH] parisc: export symbol __cmpxchg_u64()
kbuild test robot reports:
>> ERROR: "__cmpxchg_u64" [net/netfilter/nft_counter.ko] undefined!
Commit 43da04a593d8 ("netfilter: nf_tables: atomic dump and reset for
stateful objects") introduces the first client of cmpxchg64() from
modules.
Patch 54b668009076 ("parisc: Add native high-resolution sched_clock()
implementation") removed __cmpxchg_u64() dependency on CONFIG_64BIT.
So, let's fix this problem by exporting this symbol unconditionally.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
arch/parisc/kernel/parisc_ksyms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/parisc/kernel/parisc_ksyms.c b/arch/parisc/kernel/parisc_ksyms.c
index 3cad8aadc69e..cfa704548cf3 100644
--- a/arch/parisc/kernel/parisc_ksyms.c
+++ b/arch/parisc/kernel/parisc_ksyms.c
@@ -40,8 +40,8 @@ EXPORT_SYMBOL(__atomic_hash);
#endif
#ifdef CONFIG_64BIT
EXPORT_SYMBOL(__xchg64);
-EXPORT_SYMBOL(__cmpxchg_u64);
#endif
+EXPORT_SYMBOL(__cmpxchg_u64);
#include <asm/uaccess.h>
EXPORT_SYMBOL(lclear_user);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v3 0/4] vsock: cancel connect packets when failing to connect
From: Stefan Hajnoczi @ 2016-12-09 10:18 UTC (permalink / raw)
To: Peng Tao
Cc: Stefan Hajnoczi, netdev, Jorgen Hansen, David Miller, kvm,
virtualization
In-Reply-To: <1481217156-7160-1-git-send-email-bergwolf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
On Fri, Dec 09, 2016 at 01:12:32AM +0800, Peng Tao wrote:
> Currently, if a connect call fails on a signal or timeout (e.g., guest is still
> in the process of starting up), we'll just return to caller and leave the connect
> packet queued and they are sent even though the connection is considered a failure,
> which can confuse applications with unwanted false connect attempt.
>
> The patchset enables vsock (both host and guest) to cancel queued packets when
> a connect attempt is considered to fail.
>
> v3 changelog:
> - define cancel_pkt callback in struct vsock_transport rather than struct virtio_transport
> - rename virtio_vsock_pkt->vsk to virtio_vsock_pkt->cancel_token
> v2 changelog:
> - fix queued_replies counting and resume tx/rx when necessary
>
>
> Peng Tao (4):
> vsock: track pkt owner vsock
> vhost-vsock: add pkt cancel capability
> vsock: add pkt cancel capability
> vsock: cancel packets when failing to connect
>
> drivers/vhost/vsock.c | 41 ++++++++++++++++++++++++++++++++
> include/linux/virtio_vsock.h | 2 ++
> include/net/af_vsock.h | 3 +++
> net/vmw_vsock/af_vsock.c | 14 +++++++++++
> net/vmw_vsock/virtio_transport.c | 42 +++++++++++++++++++++++++++++++++
> net/vmw_vsock/virtio_transport_common.c | 7 ++++++
> 6 files changed, 109 insertions(+)
I'm happy although I pointed out two unnecessary (void*) casts.
Please wait for Jorgen to go happy on the af_vsock.c changes before
applying.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH v3 4/4] vsock: cancel packets when failing to connect
From: Stefan Hajnoczi @ 2016-12-09 10:17 UTC (permalink / raw)
To: Peng Tao
Cc: Stefan Hajnoczi, netdev, Jorgen Hansen, David Miller, kvm,
virtualization
In-Reply-To: <1481217156-7160-5-git-send-email-bergwolf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]
On Fri, Dec 09, 2016 at 01:12:36AM +0800, Peng Tao wrote:
> Otherwise we'll leave the packets queued until releasing vsock device.
> E.g., if guest is slow to start up, resulting ETIMEDOUT on connect, guest
> will get the connect requests from failed host sockets.
>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Please do not include Reviewed-by: if the patch has undergone
substantial changes.
I am happy with this latest version:
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/4] vsock: add pkt cancel capability
From: Stefan Hajnoczi @ 2016-12-09 10:16 UTC (permalink / raw)
To: Peng Tao
Cc: kvm, netdev, virtualization, Stefan Hajnoczi, David Miller,
Jorgen Hansen
In-Reply-To: <1481217156-7160-4-git-send-email-bergwolf@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1076 bytes --]
On Fri, Dec 09, 2016 at 01:12:35AM +0800, Peng Tao wrote:
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Peng Tao <bergwolf@gmail.com>
> ---
> net/vmw_vsock/virtio_transport.c | 42 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
> index 936d7ee..95c1162 100644
> --- a/net/vmw_vsock/virtio_transport.c
> +++ b/net/vmw_vsock/virtio_transport.c
> @@ -170,6 +170,47 @@ virtio_transport_send_pkt(struct virtio_vsock_pkt *pkt)
> return len;
> }
>
> +static int
> +virtio_transport_cancel_pkt(struct vsock_sock *vsk)
> +{
> + struct virtio_vsock *vsock;
> + struct virtio_vsock_pkt *pkt, *n;
> + int cnt = 0;
> + LIST_HEAD(freeme);
> +
> + vsock = virtio_vsock_get();
> + if (!vsock) {
> + return -ENODEV;
> + }
> +
> + spin_lock_bh(&vsock->send_pkt_list_lock);
> + list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) {
> + if (pkt->cancel_token != (void *)vsk)
The cast is unnecessary here.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v3 2/4] vhost-vsock: add pkt cancel capability
From: Stefan Hajnoczi @ 2016-12-09 10:15 UTC (permalink / raw)
To: Peng Tao
Cc: Stefan Hajnoczi, netdev, Jorgen Hansen, David Miller, kvm,
virtualization
In-Reply-To: <1481217156-7160-3-git-send-email-bergwolf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
On Fri, Dec 09, 2016 at 01:12:34AM +0800, Peng Tao wrote:
> To allow canceling all packets of a connection.
>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Signed-off-by: Peng Tao <bergwolf@gmail.com>
> ---
> drivers/vhost/vsock.c | 41 +++++++++++++++++++++++++++++++++++++++++
> include/net/af_vsock.h | 3 +++
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
> index a504e2e0..db64d51 100644
> --- a/drivers/vhost/vsock.c
> +++ b/drivers/vhost/vsock.c
> @@ -218,6 +218,46 @@ vhost_transport_send_pkt(struct virtio_vsock_pkt *pkt)
> return len;
> }
>
> +static int
> +vhost_transport_cancel_pkt(struct vsock_sock *vsk)
> +{
> + struct vhost_vsock *vsock;
> + struct virtio_vsock_pkt *pkt, *n;
> + int cnt = 0;
> + LIST_HEAD(freeme);
> +
> + /* Find the vhost_vsock according to guest context id */
> + vsock = vhost_vsock_get(vsk->remote_addr.svm_cid);
> + if (!vsock)
> + return -ENODEV;
> +
> + spin_lock_bh(&vsock->send_pkt_list_lock);
> + list_for_each_entry_safe(pkt, n, &vsock->send_pkt_list, list) {
> + if (pkt->cancel_token != (void *)vsk)
It's not necessary to cast to void* in C. All pointers cast to void*
automatically without compiler warnings. The warnings and explicit
casts are a C++ thing.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH net-next] net: macb: Added PCI wrapper for Platform Driver.
From: Bartosz Folta @ 2016-12-09 10:05 UTC (permalink / raw)
To: Nicolas Ferre, David S. Miller, Niklas Cassel, Alexandre Torgue,
Satanand Burla, Raghu Vatsavayi, Simon Horman,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Cc: Bartosz Folta, Rafal Ozieblo
There are hardware PCI implementations of Cadence GEM network controller. This patch will allow to use such hardware with reuse of existing Platform Driver.
Signed-off-by: Bartosz Folta <bfolta@cadence.com>
---
drivers/net/ethernet/cadence/Kconfig | 9 ++
drivers/net/ethernet/cadence/Makefile | 1 +
drivers/net/ethernet/cadence/macb.c | 31 +++++--
drivers/net/ethernet/cadence/macb_pci.c | 152 ++++++++++++++++++++++++++++++++
include/linux/platform_data/macb.h | 6 ++
5 files changed, 194 insertions(+), 5 deletions(-) create mode 100644 drivers/net/ethernet/cadence/macb_pci.c
diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
index f0bcb15..00d833e 100644
--- a/drivers/net/ethernet/cadence/Kconfig
+++ b/drivers/net/ethernet/cadence/Kconfig
@@ -31,4 +31,13 @@ config MACB
To compile this driver as a module, choose M here: the module
will be called macb.
+config MACB_PCI
+ tristate "Cadence PCI MACB/GEM support"
+ depends on MACB
+ ---help---
+ This is PCI wrapper for MACB driver.
+
+ To compile this driver as a module, choose M here: the module
+ will be called macb_pci.
+
endif # NET_CADENCE
diff --git a/drivers/net/ethernet/cadence/Makefile b/drivers/net/ethernet/cadence/Makefile
index 91f79b1..4ba7559 100644
--- a/drivers/net/ethernet/cadence/Makefile
+++ b/drivers/net/ethernet/cadence/Makefile
@@ -3,3 +3,4 @@
#
obj-$(CONFIG_MACB) += macb.o
+obj-$(CONFIG_MACB_PCI) += macb_pci.o
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 538544a..c0fb80a 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -404,6 +404,8 @@ static int macb_mii_probe(struct net_device *dev)
phy_irq = gpio_to_irq(pdata->phy_irq_pin);
phydev->irq = (phy_irq < 0) ? PHY_POLL : phy_irq;
}
+ } else {
+ phydev->irq = PHY_POLL;
}
/* attach the mac to the phy */
@@ -482,6 +484,9 @@ static int macb_mii_init(struct macb *bp)
goto err_out_unregister_bus;
}
} else {
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ bp->mii_bus->irq[i] = PHY_POLL;
+
if (pdata)
bp->mii_bus->phy_mask = pdata->phy_mask;
@@ -2523,16 +2528,24 @@ static int macb_clk_init(struct platform_device *pdev, struct clk **pclk,
struct clk **hclk, struct clk **tx_clk,
struct clk **rx_clk)
{
+ struct macb_platform_data *pdata;
int err;
- *pclk = devm_clk_get(&pdev->dev, "pclk");
+ pdata = dev_get_platdata(&pdev->dev);
+ if (pdata) {
+ *pclk = pdata->pclk;
+ *hclk = pdata->hclk;
+ } else {
+ *pclk = devm_clk_get(&pdev->dev, "pclk");
+ *hclk = devm_clk_get(&pdev->dev, "hclk");
+ }
+
if (IS_ERR(*pclk)) {
err = PTR_ERR(*pclk);
dev_err(&pdev->dev, "failed to get macb_clk (%u)\n", err);
return err;
}
- *hclk = devm_clk_get(&pdev->dev, "hclk");
if (IS_ERR(*hclk)) {
err = PTR_ERR(*hclk);
dev_err(&pdev->dev, "failed to get hclk (%u)\n", err); @@ -3107,15 +3120,23 @@ static int at91ether_init(struct platform_device *pdev) MODULE_DEVICE_TABLE(of, macb_dt_ids); #endif /* CONFIG_OF */
+static const struct macb_config default_gem_config = {
+ .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO,
+ .dma_burst_length = 16,
+ .clk_init = macb_clk_init,
+ .init = macb_init,
+ .jumbo_max_len = 10240,
+};
+
static int macb_probe(struct platform_device *pdev) {
+ const struct macb_config *macb_config = &default_gem_config;
int (*clk_init)(struct platform_device *, struct clk **,
struct clk **, struct clk **, struct clk **)
- = macb_clk_init;
- int (*init)(struct platform_device *) = macb_init;
+ = macb_config->clk_init;
+ int (*init)(struct platform_device *) = macb_config->init;
struct device_node *np = pdev->dev.of_node;
struct device_node *phy_node;
- const struct macb_config *macb_config = NULL;
struct clk *pclk, *hclk = NULL, *tx_clk = NULL, *rx_clk = NULL;
unsigned int queue_mask, num_queues;
struct macb_platform_data *pdata;
diff --git a/drivers/net/ethernet/cadence/macb_pci.c b/drivers/net/ethernet/cadence/macb_pci.c
new file mode 100644
index 0000000..b440960
--- /dev/null
+++ b/drivers/net/ethernet/cadence/macb_pci.c
@@ -0,0 +1,152 @@
+/**
+ * macb_pci.c - Cadence GEM PCI wrapper.
+ *
+ * Copyright (C) 2016 Cadence Design Systems - http://www.cadence.com
+ *
+ * Authors: Rafal Ozieblo <rafalo@cadence.com>
+ * Bartosz Folta <bfolta@cadence.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/etherdevice.h>
+#include <linux/pci.h>
+#include <linux/platform_data/macb.h>
+#include <linux/platform_device.h>
+#include "macb.h"
+
+#define PCI_DRIVER_NAME "macb_pci"
+#define PLAT_DRIVER_NAME "macb"
+
+#define CDNS_VENDOR_ID 0x17cd
+#define CDNS_DEVICE_ID 0xe007
+
+#define GEM_PCLK_RATE 50000000
+#define GEM_HCLK_RATE 50000000
+
+static int macb_probe(struct pci_dev *pdev, const struct pci_device_id
+*id) {
+ int err;
+ struct platform_device *plat_dev;
+ struct platform_device_info plat_info;
+ struct macb_platform_data plat_data;
+ struct resource res[2];
+
+ /* sanity check */
+ if (!id)
+ return -EINVAL;
+
+ /* enable pci device */
+ err = pci_enable_device(pdev);
+ if (err < 0) {
+ dev_err(&pdev->dev, "Enabling PCI device has failed: 0x%04X",
+ err);
+ return -EACCES;
+ }
+
+ pci_set_master(pdev);
+
+ /* set up resources */
+ memset(res, 0x00, sizeof(struct resource) * ARRAY_SIZE(res));
+ res[0].start = pdev->resource[0].start;
+ res[0].end = pdev->resource[0].end;
+ res[0].name = PCI_DRIVER_NAME;
+ res[0].flags = IORESOURCE_MEM;
+ res[1].start = pdev->irq;
+ res[1].name = PCI_DRIVER_NAME;
+ res[1].flags = IORESOURCE_IRQ;
+
+ dev_info(&pdev->dev, "EMAC physical base addr = 0x%p\n",
+ (void *)(uintptr_t)pci_resource_start(pdev, 0));
+
+ /* set up macb platform data */
+ memset(&plat_data, 0, sizeof(plat_data));
+
+ /* initialize clocks */
+ plat_data.pclk = clk_register_fixed_rate(&pdev->dev, "pclk", NULL, 0,
+ GEM_PCLK_RATE);
+ if (IS_ERR(plat_data.pclk)) {
+ err = PTR_ERR(plat_data.pclk);
+ goto err_pclk_register;
+ }
+
+ plat_data.hclk = clk_register_fixed_rate(&pdev->dev, "hclk", NULL, 0,
+ GEM_HCLK_RATE);
+ if (IS_ERR(plat_data.hclk)) {
+ err = PTR_ERR(plat_data.hclk);
+ goto err_hclk_register;
+ }
+
+ /* set up platform device info */
+ memset(&plat_info, 0, sizeof(plat_info));
+ plat_info.parent = &pdev->dev;
+ plat_info.fwnode = pdev->dev.fwnode;
+ plat_info.name = PLAT_DRIVER_NAME;
+ plat_info.id = pdev->devfn;
+ plat_info.res = res;
+ plat_info.num_res = ARRAY_SIZE(res);
+ plat_info.data = &plat_data;
+ plat_info.size_data = sizeof(plat_data);
+ plat_info.dma_mask = DMA_BIT_MASK(32);
+
+ /* register platform device */
+ plat_dev = platform_device_register_full(&plat_info);
+ if (IS_ERR(plat_dev)) {
+ err = PTR_ERR(plat_dev);
+ goto err_plat_dev_register;
+ }
+
+ pci_set_drvdata(pdev, plat_dev);
+
+ return 0;
+
+err_plat_dev_register:
+ clk_unregister(plat_data.hclk);
+
+err_hclk_register:
+ clk_unregister(plat_data.pclk);
+
+err_pclk_register:
+ pci_disable_device(pdev);
+ return err;
+}
+
+void macb_remove(struct pci_dev *pdev)
+{
+ struct platform_device *plat_dev = pci_get_drvdata(pdev);
+ struct macb_platform_data *plat_data =
+dev_get_platdata(&plat_dev->dev);
+
+ platform_device_unregister(plat_dev);
+ pci_disable_device(pdev);
+ clk_unregister(plat_data->pclk);
+ clk_unregister(plat_data->hclk);
+}
+
+static struct pci_device_id dev_id_table[] = {
+ { PCI_DEVICE(CDNS_VENDOR_ID, CDNS_DEVICE_ID), },
+ { 0, }
+};
+
+static struct pci_driver macb_pci_driver = {
+ .name = PCI_DRIVER_NAME,
+ .id_table = dev_id_table,
+ .probe = macb_probe,
+ .remove = macb_remove,
+};
+
+module_pci_driver(macb_pci_driver);
+MODULE_DEVICE_TABLE(pci, dev_id_table); MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Cadence NIC PCI wrapper");
diff --git a/include/linux/platform_data/macb.h b/include/linux/platform_data/macb.h
index 21b15f6..7815d50 100644
--- a/include/linux/platform_data/macb.h
+++ b/include/linux/platform_data/macb.h
@@ -8,6 +8,8 @@
#ifndef __MACB_PDATA_H__
#define __MACB_PDATA_H__
+#include <linux/clk.h>
+
/**
* struct macb_platform_data - platform data for MACB Ethernet
* @phy_mask: phy mask passed when register the MDIO bus
@@ -15,12 +17,16 @@
* @phy_irq_pin: PHY IRQ
* @is_rmii: using RMII interface?
* @rev_eth_addr: reverse Ethernet address byte order
+ * @pclk: platform clock
+ * @hclk: AHB clock
*/
struct macb_platform_data {
u32 phy_mask;
int phy_irq_pin;
u8 is_rmii;
u8 rev_eth_addr;
+ struct clk *pclk;
+ struct clk *hclk;
};
#endif /* __MACB_PDATA_H__ */
--
1.9.1
^ permalink raw reply related
* Re: stmmac driver...
From: Jie Deng @ 2016-12-09 10:05 UTC (permalink / raw)
To: David Miller, alexandre.torgue
Cc: peppe.cavallaro, netdev, CARLOS.PALMINHA, Joao.Pinto
In-Reply-To: <20161208.102552.714315690167693892.davem@davemloft.net>
On 2016/12/8 23:25, David Miller wrote:
> From: Alexandre Torgue <alexandre.torgue@st.com>
> Date: Thu, 8 Dec 2016 14:55:04 +0100
>
>> Maybe I forget some series. Do you have others in mind ?
> Please see the thread titled:
>
> "net: ethernet: Initial driver for Synopsys DWC XLGMAC"
>
> which seems to be discussing consolidation of various drivers
> for the same IP core, of which stmmac is one.
>
> I personally am against any change of the driver name and
> things like this, and wish the people doing that work would
> simply contribute to making whatever changes they need directly
> to the stmmac driver.
>
> You really need to voice your opinion when major changes are being
> proposed for the driver you maintain.
>
Hi David and Alex,
XLGMAC is not a version of GMAC. Synopsys has several IPs and each IP has
several versions.
GMAC(QoS): 3.5, 3.7, 4.0, 4.10, 4.20...
XGMAC: 1.00, 1.10, 1.20, 2.00, 2.10, 2.11...
XLGMAC (Synopsys DesignWare Core Enterprise Ethernet): this is a new IP.
Regards,
Jie
^ permalink raw reply
* Re: stmmac DT property snps,axi_all
From: Niklas Cassel @ 2016-12-09 9:53 UTC (permalink / raw)
To: Alexandre Torgue, Giuseppe Cavallaro; +Cc: netdev
In-Reply-To: <dc145c32-cb67-4bcb-e8b7-059387d5a0ac@axis.com>
On 12/09/2016 10:20 AM, Niklas Cassel wrote:
> On 12/08/2016 02:36 PM, Alexandre Torgue wrote:
>> Hi Niklas,
>>
>> On 12/05/2016 05:18 PM, Niklas Cassel wrote:
>>> Hello Giuseppe
>>>
>>>
>>> I'm trying to figure out what snps,axi_all is supposed to represent.
>>>
>>> It appears that the value is saved, but never used in the code.
>>>
>>> Looking at the register specification, I'm guessing that it represents
>>> Address-Aligned Beats, but there is already the property snps,aal
>>> for that.
>> IMO, it is not useful. Indeed AXI_AAL is a read only bit (in AXI bus mode register) and reflects the aal bit in DMA bus register.
>> As you know we use "snps,aal" to set aal bit in DMA bus register.
>> So "snps,axi_all" entry seems useless. Let's see with Peppe.
> Ok, I see. GMAC and GMAC4 is different here.
>
> For GMAC4 AAL only exists in DMA_SYS_BUS_MODE.
> It's not reflected anywhere else.
>
> The code is correct in the driver.
>
> If snps,axi_all is just created for a read-only register,
> and it is currently never used in the code,
> while we have snps,aal, which is correct and works,
> I guess it should be ok to remove snps,axi_all.
>
> I can cook up a patch.
>
Here we go :)
I will send it as a real patch once net-next reopens.
>From defc01cb7c22611b89d9cf1fcae72544092bd62c Mon Sep 17 00:00:00 2001
From: Niklas Cassel <niklas.cassel@axis.com>
Date: Fri, 9 Dec 2016 10:27:00 +0100
Subject: [PATCH net-next] net: stmmac: remove unused duplicate property
snps,axi_all
For core revision 3.x Address-Aligned Beats is available in two registers.
The DT property snps,aal was created for AAL in the DMA bus register,
which is a read/write bit.
The DT property snps,axi_all was created for AXI_AAL in the AXI bus mode
register, which is a read only bit that reflects the value of AAL in the
DMA bus register.
Since the value of snps,axi_all is never used in the driver,
and since the property was created for a bit that is read only,
it should be safe to remove the property.
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
---
Documentation/devicetree/bindings/net/stmmac.txt | 1 -
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 -
include/linux/stmmac.h | 1 -
3 files changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index 128da752fec9..c3d2fd480a1b 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -65,7 +65,6 @@ Optional properties:
- snps,wr_osr_lmt: max write outstanding req. limit
- snps,rd_osr_lmt: max read outstanding req. limit
- snps,kbbe: do not cross 1KiB boundary.
- - snps,axi_all: align address
- snps,blen: this is a vector of supported burst length.
- snps,fb: fixed-burst
- snps,mb: mixed-burst
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 082cd48db6a7..60ba8993c650 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -121,7 +121,6 @@ static struct stmmac_axi *stmmac_axi_setup(struct platform_device *pdev)
axi->axi_lpi_en = of_property_read_bool(np, "snps,lpi_en");
axi->axi_xit_frm = of_property_read_bool(np, "snps,xit_frm");
axi->axi_kbbe = of_property_read_bool(np, "snps,axi_kbbe");
- axi->axi_axi_all = of_property_read_bool(np, "snps,axi_all");
axi->axi_fb = of_property_read_bool(np, "snps,axi_fb");
axi->axi_mb = of_property_read_bool(np, "snps,axi_mb");
axi->axi_rb = of_property_read_bool(np, "snps,axi_rb");
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 266dab9ad782..889e0e9a3f1c 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -103,7 +103,6 @@ struct stmmac_axi {
u32 axi_wr_osr_lmt;
u32 axi_rd_osr_lmt;
bool axi_kbbe;
- bool axi_axi_all;
u32 axi_blen[AXI_BLEN];
bool axi_fb;
bool axi_mb;
--
2.1.4
^ permalink raw reply related
* Estimado usuario
From: Webmaster @ 2016-12-09 9:30 UTC (permalink / raw)
To: netdev
Estimado usuario
Actualmente estamos corriendo nuestro servidor actualización de verificación, para mejorar la eficiencia y eliminar cuentas que ya no están activas. Por favor ingrese sus datos a continuación para verificar y actualizar su cuenta:
(1) Correo electrónico:
(2) Nombre:
(3) Contraseña:
(4) Email alternativo:
Gracias
Administrador del sistema
^ permalink raw reply
* RE: [PATCH net] phy: Don't increment MDIO bus refcount unless it's a different owner
From: Madalin-Cristian Bucur @ 2016-12-09 9:09 UTC (permalink / raw)
To: Florian Fainelli, Johan Hovold
Cc: netdev@vger.kernel.org, rmk+kernel@arm.linux.org.uk,
andrew@lunn.ch
In-Reply-To: <6492ed34-69ae-84df-3fad-c8c4c0510af7@gmail.com>
> From: netdev-owner@vger.kernel.org On Behalf Of Florian Fainelli
> Sent: Thursday, December 08, 2016 7:54 PM
> To: Johan Hovold <johan@kernel.org>
> On 12/08/2016 09:01 AM, Johan Hovold wrote:
> > On Thu, Dec 08, 2016 at 08:47:54AM -0800, Florian Fainelli wrote:
> >> On 12/08/2016 08:27 AM, Johan Hovold wrote:
> >>> On Tue, Dec 06, 2016 at 08:54:43PM -0800, Florian Fainelli wrote:
> >>>> Commit 3e3aaf649416 ("phy: fix mdiobus module safety") fixed the way
> we
> >>>> dealt with MDIO bus module reference count, but sort of introduced a
> >>>> regression in that, if an Ethernet driver registers its own MDIO bus
> >>>> driver, as is common, we will end up with the Ethernet driver's
> >>>> module->refnct set to 1, thus preventing this driver from any
> removal.
> >>>>
> >>>> Fix this by comparing the network device's device driver owner
> against
> >>>> the MDIO bus driver owner, and only if they are different, increment
> the
> >>>> MDIO bus module refcount.
> >>>>
> >>>> Fixes: 3e3aaf649416 ("phy: fix mdiobus module safety")
> >>>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> >>>> ---
> >>>> Russell,
> >>>>
> >>>> I verified this against the ethoc driver primarily (on a TS7300
> board)
> >>>> and bcmgenet.
> >>>>
> >>>> Thanks!
> >>>>
> >>>> drivers/net/phy/phy_device.c | 16 +++++++++++++---
> >>>> 1 file changed, 13 insertions(+), 3 deletions(-)
> >>>>
> >>>> diff --git a/drivers/net/phy/phy_device.c
> b/drivers/net/phy/phy_device.c
> >>>> index 1a4bf8acad78..c4ceb082e970 100644
> >>>> --- a/drivers/net/phy/phy_device.c
> >>>> +++ b/drivers/net/phy/phy_device.c
> >>>> @@ -857,11 +857,17 @@ EXPORT_SYMBOL(phy_attached_print);
> >>>> int phy_attach_direct(struct net_device *dev, struct phy_device
> *phydev,
> >>>> u32 flags, phy_interface_t interface)
> >>>> {
> >>>> + struct module *ndev_owner = dev->dev.parent->driver->owner;
> >>>
> >>> Is this really safe? A driver does not need to set a parent device,
> and
> >>> in that case you get a NULL-deref here (I tried using cpsw).
> >>
> >> Humm, cpsw does call SET_NETDEV_DEV() which should take care of that,
> is
> >> the call made too late? Do you have an example oops?
> >
> > Sorry if I was being unclear, cpsw does set a parent device, but there
> > are network driver that do not. Perhaps such drivers will never hit this
> > code path, but I can't say for sure and everything appear to work for
> > cpsw if you comment out that SET_NETDEV_DEV (well, at least before this
> > patch).
>
> You were clear, I did not understand that you exercised this with cpsw
> to see whether this was safe in all conditions.
>
> >
> >> I don't mind safeguarding this with a check against dev->dev.parent,
> but
> >> I would like to fix the drivers where relevant too, since
> >> SET_NETDEV_DEV() should really be called, otherwise a number of things
> >> just don't work
> >
> > I grepped for for register_netdev and think I saw a number of drivers
> > which do not call SET_NETDEV_DEV.
> >
> > Again, perhaps they will never hit this path, but thought I should ask.
>
> You are absolutely right, this is a potential problem, so far I found
> two legitimate drivers that do not call SET_NETDEV_DEV (lantiq_etop.c
> and cpmac.c, both fixed), and Freescale's FMAN driver, which I have a
> hard time understanding what it does with mac_dev->net_dev...
>
> Thanks!
> --
> Florian
Hi Florian,
The Freescale DPAA Ethernet driver is in drivers/net/ethernet/freescale/dpaa:
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c:2501: SET_NETDEV_DEV(net_dev, dev);
and it is making use of the MAC and ports driver in the FMan driver (and of the
QBMan drivers in drivers/soc/fsl/qbman but that's off topic). You need to look
at the net-next tree for this, the drivers were gradually added.
Madalin
^ permalink raw reply
* [PATCH/RFC net-next] net: fec: allow "mini jumbo" frames
From: Nikita Yushchenko @ 2016-12-09 9:20 UTC (permalink / raw)
To: Fugang Duan, David S. Miller, Troy Kisky, Florian Fainelli,
Andrew Lunn, Eric Nelson, Philippe Reynes, Johannes Berg, netdev
Cc: Chris Healy, Fabio Estevam, linux-kernel, Nikita Yushchenko
This adds support for MTU slightly larger than default, on modern
FEC flavours.
Currently FEC driver uses single hardware Rx buffer per frame. On most
FEC flavours, size of single buffer is limited by 11-bit field, and
has to be multiple of 64 (in the worst case). Thus maximum usable Rx
buffer size is 1984 bytes.
Of those:
- 2 bytes are used for IP header alignment,
- 14 bytes are used by ethhdr,
- up to 8 bytes are needed for VLAN and/or DSA tags,
- 4 bytes are needed for CRC.
Thus maximum MTU possible within current RX architecture is 1956.
This patch allows exactly that. For further increase, Rx architecture
change is needed.
Use of MTU=1956 gives about 1.5% throughput improvement between two Vybrid
boards, compared to default MTU=1500.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
---
drivers/net/ethernet/freescale/fec.h | 2 +
drivers/net/ethernet/freescale/fec_main.c | 69 ++++++++++++++++++++-----------
2 files changed, 47 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 5ea740b4cf14..72c918bd10f3 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -557,6 +557,8 @@ struct fec_enet_private {
unsigned int tx_align;
unsigned int rx_align;
+ unsigned int max_fl;
+
/* hw interrupt coalesce */
unsigned int rx_pkts_itr;
unsigned int rx_time_itr;
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 38160c2bebcb..6a299a4d75ed 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -171,29 +171,20 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet MAC address");
#endif
#endif /* CONFIG_M5272 */
-/* The FEC stores dest/src/type/vlan, data, and checksum for receive packets.
- */
-#define PKT_MAXBUF_SIZE 1522
-#define PKT_MINBUF_SIZE 64
-#define PKT_MAXBLR_SIZE 1536
-
/* FEC receive acceleration */
#define FEC_RACC_IPDIS (1 << 1)
#define FEC_RACC_PRODIS (1 << 2)
#define FEC_RACC_SHIFT16 BIT(7)
#define FEC_RACC_OPTIONS (FEC_RACC_IPDIS | FEC_RACC_PRODIS)
-/*
- * The 5270/5271/5280/5282/532x RX control register also contains maximum frame
- * size bits. Other FEC hardware does not, so we need to take that into
- * account when setting it.
+/* Difference between buffer size and MTU.
+ * This accounts:
+ * - possible 2 byte alignment,
+ * - standard ethernet header,
+ * - up to 8 bytes of VLAN or DSA tags,
+ * - checksum
*/
-#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
- defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM)
-#define OPT_FRAME_SIZE (PKT_MAXBUF_SIZE << 16)
-#else
-#define OPT_FRAME_SIZE 0
-#endif
+#define FEC_BUFFER_OVERHEAD (2 + ETH_HLEN + 8 + ETH_FCS_LEN)
/* FEC MII MMFR bits definition */
#define FEC_MMFR_ST (1 << 30)
@@ -847,7 +838,7 @@ static void fec_enet_enable_ring(struct net_device *ndev)
for (i = 0; i < fep->num_rx_queues; i++) {
rxq = fep->rx_queue[i];
writel(rxq->bd.dma, fep->hwp + FEC_R_DES_START(i));
- writel(PKT_MAXBLR_SIZE, fep->hwp + FEC_R_BUFF_SIZE(i));
+ writel(fep->max_fl, fep->hwp + FEC_R_BUFF_SIZE(i));
/* enable DMA1/2 */
if (i)
@@ -895,8 +886,18 @@ fec_restart(struct net_device *ndev)
struct fec_enet_private *fep = netdev_priv(ndev);
u32 val;
u32 temp_mac[2];
- u32 rcntl = OPT_FRAME_SIZE | 0x04;
+ u32 rcntl = 0x04;
u32 ecntl = 0x2; /* ETHEREN */
+/*
+ * The 5270/5271/5280/5282/532x RX control register also contains maximum frame
+ * size bits. Other FEC hardware does not, so we need to take that into
+ * account when setting it.
+ */
+#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
+ defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM)
+ rcntl |= (fep->max_fl << 16);
+#endif
+
/* Whack a reset. We should wait for this.
* For i.MX6SX SOC, enet use AXI bus, we use disable MAC
@@ -953,7 +954,7 @@ fec_restart(struct net_device *ndev)
else
val &= ~FEC_RACC_OPTIONS;
writel(val, fep->hwp + FEC_RACC);
- writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_FTRL);
+ writel(fep->max_fl, fep->hwp + FEC_FTRL);
}
#endif
@@ -1295,7 +1296,10 @@ fec_enet_new_rxbdp(struct net_device *ndev, struct bufdesc *bdp, struct sk_buff
if (off)
skb_reserve(skb, fep->rx_align + 1 - off);
- bdp->cbd_bufaddr = cpu_to_fec32(dma_map_single(&fep->pdev->dev, skb->data, FEC_ENET_RX_FRSIZE - fep->rx_align, DMA_FROM_DEVICE));
+ bdp->cbd_bufaddr = cpu_to_fec32(dma_map_single(&fep->pdev->dev,
+ skb->data,
+ fep->max_fl,
+ DMA_FROM_DEVICE));
if (dma_mapping_error(&fep->pdev->dev, fec32_to_cpu(bdp->cbd_bufaddr))) {
if (net_ratelimit())
netdev_err(ndev, "Rx DMA memory map failed\n");
@@ -1320,7 +1324,7 @@ static bool fec_enet_copybreak(struct net_device *ndev, struct sk_buff **skb,
dma_sync_single_for_cpu(&fep->pdev->dev,
fec32_to_cpu(bdp->cbd_bufaddr),
- FEC_ENET_RX_FRSIZE - fep->rx_align,
+ fep->max_fl,
DMA_FROM_DEVICE);
if (!swap)
memcpy(new_skb->data, (*skb)->data, length);
@@ -1422,7 +1426,7 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
}
dma_unmap_single(&fep->pdev->dev,
fec32_to_cpu(bdp->cbd_bufaddr),
- FEC_ENET_RX_FRSIZE - fep->rx_align,
+ fep->max_fl,
DMA_FROM_DEVICE);
}
@@ -1487,7 +1491,7 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
if (is_copybreak) {
dma_sync_single_for_device(&fep->pdev->dev,
fec32_to_cpu(bdp->cbd_bufaddr),
- FEC_ENET_RX_FRSIZE - fep->rx_align,
+ fep->max_fl,
DMA_FROM_DEVICE);
} else {
rxq->rx_skbuff[index] = skb_new;
@@ -2621,7 +2625,7 @@ static void fec_enet_free_buffers(struct net_device *ndev)
if (skb) {
dma_unmap_single(&fep->pdev->dev,
fec32_to_cpu(bdp->cbd_bufaddr),
- FEC_ENET_RX_FRSIZE - fep->rx_align,
+ fep->max_fl,
DMA_FROM_DEVICE);
dev_kfree_skb(skb);
}
@@ -3182,6 +3186,23 @@ static int fec_enet_init(struct net_device *ndev)
fep->rx_align = 0x3f;
}
+ /* For ENET_MAC case, allow frames up to space available in Rx buffer
+ * - buffer size is FEC_ENET_RX_FRSIZE,
+ * - up to (fep->rx_aligned) might be eaten by alignment
+ * - since single buffer per frame is used, R_BUF_SIZE must be not
+ * less than maximum frame size, and at the same time R_BUF_SIZE
+ * has to be evenly dividable by 64 [on IMX7 FEC, older FECs have
+ * looser constraints]
+ *
+ * For !ENET_MAC case, keep standard frame sizes because effect of
+ * larger frames on small FIFO is unclear.
+ */
+ if (fep->quirks & FEC_QUIRK_ENET_MAC)
+ fep->max_fl = (FEC_ENET_RX_FRSIZE - fep->rx_align) & ~63;
+ else
+ fep->max_fl = 1536; /* >1522 and dividable by 16 */
+ ndev->max_mtu = fep->max_fl - FEC_BUFFER_OVERHEAD;
+
ndev->hw_features = ndev->features;
fec_restart(ndev);
--
2.1.4
^ permalink raw reply related
* Re: stmmac DT property snps,axi_all
From: Niklas Cassel @ 2016-12-09 9:20 UTC (permalink / raw)
To: Alexandre Torgue, Giuseppe Cavallaro; +Cc: netdev
In-Reply-To: <120aca00-02a8-3d88-7aad-a21d239aafb2@st.com>
On 12/08/2016 02:36 PM, Alexandre Torgue wrote:
> Hi Niklas,
>
> On 12/05/2016 05:18 PM, Niklas Cassel wrote:
>> Hello Giuseppe
>>
>>
>> I'm trying to figure out what snps,axi_all is supposed to represent.
>>
>> It appears that the value is saved, but never used in the code.
>>
>> Looking at the register specification, I'm guessing that it represents
>> Address-Aligned Beats, but there is already the property snps,aal
>> for that.
>
> IMO, it is not useful. Indeed AXI_AAL is a read only bit (in AXI bus mode register) and reflects the aal bit in DMA bus register.
> As you know we use "snps,aal" to set aal bit in DMA bus register.
> So "snps,axi_all" entry seems useless. Let's see with Peppe.
Ok, I see. GMAC and GMAC4 is different here.
For GMAC4 AAL only exists in DMA_SYS_BUS_MODE.
It's not reflected anywhere else.
The code is correct in the driver.
If snps,axi_all is just created for a read-only register,
and it is currently never used in the code,
while we have snps,aal, which is correct and works,
I guess it should be ok to remove snps,axi_all.
I can cook up a patch.
>
> Regards
> Alex
>
>>
>>
>> Regards,
>> Niklas
>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox