* Re: [Patch net-next] ipv6: fix redefinition of in6_pktinfo and ip6_mtuinfo
From: Carlos O'Donell @ 2015-01-09 16:27 UTC (permalink / raw)
To: David Miller, xiyou.wangcong; +Cc: netdev, vlee
In-Reply-To: <20150108.193819.258816805892789860.davem@davemloft.net>
On 01/08/2015 10:38 PM, David Miller wrote:
> From: Cong Wang <xiyou.wangcong@gmail.com>
> Date: Tue, 6 Jan 2015 15:45:31 -0800
>
>> Both netinet/in.h and linux/ipv6.h define these two structs,
>> if we include both of them, we got:
>>
>> /usr/include/linux/ipv6.h:19:8: error: redefinition of ‘struct in6_pktinfo’
>> struct in6_pktinfo {
>> ^
>> In file included from /usr/include/arpa/inet.h:22:0,
>> from txtimestamp.c:33:
>> /usr/include/netinet/in.h:524:8: note: originally defined here
>> struct in6_pktinfo
>> ^
>> In file included from txtimestamp.c:40:0:
>> /usr/include/linux/ipv6.h:24:8: error: redefinition of ‘struct ip6_mtuinfo’
>> struct ip6_mtuinfo {
>> ^
>> In file included from /usr/include/arpa/inet.h:22:0,
>> from txtimestamp.c:33:
>> /usr/include/netinet/in.h:531:8: note: originally defined here
>> struct ip6_mtuinfo
>> ^
>> So similarly to what we did for in6_addr, we need to sync with
>> libc header on their definitions.
>>
>> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
>
> Applied.
>
I'm reviewing the glibc side and will apply there if nobody has done so yet.
Cheers,
Carlos.
^ permalink raw reply
* RE: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of fdb entries learnt via br_fdb_external_learn_add()
From: Arad, Ronen @ 2015-01-09 16:15 UTC (permalink / raw)
To: Scott Feldman, Jiri Pirko; +Cc: Siva Mannem, Netdev
In-Reply-To: <CAE4R7bBRboCfhRKFKgVVAGt1f-m6wkXNfaej4RjuaCKPypABeA@mail.gmail.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Scott Feldman
>Sent: Friday, January 09, 2015 3:47 AM
>To: Jiri Pirko
>Cc: Siva Mannem; Netdev
>Subject: Re: Clarification regarding IFLA_BRPORT_LEARNING_SYNC and aging of
>fdb entries learnt via br_fdb_external_learn_add()
>
>On Wed, Jan 7, 2015 at 4:53 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Tue, Dec 30, 2014 at 07:20:21PM CET, siva.mannem.lnx@gmail.com wrote:
>>>Hi,
>>>
>>>I am trying to understand the ongoing switch device offload effort and
>>>am following the discussions. I have a question regarding
>>>IFLA_BRPORT_LEARNING_SYNC flag and how aging happens when this flag is
>>>enabled on a port that is attached to a bridge that has vlan filtering
>>>enabled.
>>>
>>>If I understand correctly, when IFLA_BRPORT_LEARNING_SYNC is set on a
>>>bridge port, fdb entries that are learnt externally(may be learnt by
>>>hardware and driver is notified) are synced to bridges fdb using
>>>br_fdb_external_learn_add(). The fdb
>>>entries(fdb->added_by_external_learn set to true) that are learnt via
>>>this method are also deleted by the aging logic after the aging time
>>>even though L2 data forwadring happens in hardware.
>
>This is correct...
>
>>> Is there a way
>>>where aging can be disabled for these entries? and let the entries be
>>>removed only via br_fdb_external_learn_delete()? or am I missing
>>>something?
>>
>> Currently extenaly learned fdb entries are indeed removed during aging
>> cleanup. I believe that br_fdb_cleanup should check added_by_external_learn
>> and not remove that fdbs. What do you think Scott?
>
>Something like that would work, if we added another brport flag to
>control that. With the current arrangement, using bridge for aging
>out entries, we want br_fdb_cleanup removing the external_learned
>fdbs, but if there was another brport flag we could fine tune that.
>Say new flag is IFLA_BRPORT_AGING_OFFLOAD or something like that. I'm
>not sure how aging settings for the bridge are pushed down to offload
>hw, or if there is a different set for hw.
>
>But, isn't it nice to let Linux bridge control aging? That way,
>bridge -s fdb dump shows nice statistics on fdb entries. Hardware
>isn't involved in the aging processes (other than being told to remove
>an entry). Simple hardware equals simple driver. Linux remains
>control point.
>
It is indeed simpler. However, if the overhead of reading hit bits from the HW
and updating freshness of entries using br_fdb_external_learn_add() is too
expensive, it would force such platforms to disable learning sync altogether.
Therefore, I believe aging offload flag (could be sufficient at bridge level)
and external aging interval (possibly longer than the software aging interval)
will encourage drivers to use leaning sync.
>-scott
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] net: unisys: adding unisys virtnic driver
From: Neil Horman @ 2015-01-09 16:13 UTC (permalink / raw)
To: earfvids; +Cc: netdev
In-Reply-To: <1418842340-29894-1-git-send-email-earfvids@redhat.com>
>The purpose of this patch is to add Unisys virtual network driver
>into the network directory and also to start a discussion about
>the requirements needed.
>
>Signed-off-by: Erik Arfvidson <earfvids@redhat.com>
>---
> drivers/net/virtnic.c | 2475 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 2475 insertions(+)
> create mode 100644 drivers/net/virtnic.c
><driver mostly snipped>
>+
>+/*****************************************************/
>+/* Module init & exit functions */
>+/*****************************************************/
>+
>+static int __init
>+virtnic_mod_init(void)
>+{
>+ int error, i;
>+
>+ LOGINF("entering virtnic_mod_init");
>+ /* ASSERT RCVPOST_BUF_SIZE < 4K */
>+ if (RCVPOST_BUF_SIZE > PI_PAGE_SIZE) {
>+ LOGERR("**** FAILED RCVPOST_BUF_SIZE:%d larger than a page\n",
>+ RCVPOST_BUF_SIZE);
>+ return -1;
>+ }
>+ /* ASSERT RCVPOST_BUF_SIZE is big enough to hold eth header */
>+ if (RCVPOST_BUF_SIZE < ETH_HEADER_SIZE) {
>+ LOGERR("**** FAILED RCVPOST_BUF_SIZE:%d is <
ETH_HEADER_SIZE:%d\n",
>+ RCVPOST_BUF_SIZE, ETH_HEADER_SIZE);
>+ return -1;
>+ }
>+
>+ /* clear out array */
>+ for (i = 0; i < VIRTNICSOPENMAX; i++) {
>+ num_virtnic_open[i].netdev = NULL;
>+ num_virtnic_open[i].vnicinfo = NULL;
>+ }
>+ /* create workqueue for serverdown completion */
>+ virtnic_serverdown_workqueue =
>+ create_singlethread_workqueue("virtnic_serverdown");
>+ if (virtnic_serverdown_workqueue == NULL) {
>+ LOGERR("**** FAILED virtnic_serverdown_workqueue creation\n");
>+ return -1;
>+ }
>+ /* create workqueue for tx timeout reset */
>+ virtnic_timeout_reset_workqueue =
>+ create_singlethread_workqueue("virtnic_timeout_reset");
>+ if (virtnic_timeout_reset_workqueue == NULL) {
>+ LOGERR
>+ ("**** FAILED virtnic_timeout_reset_workqueue creation\n");
>+ return -1;
>+ }
>+ virtnic_debugfs_dir = debugfs_create_dir("virtnic", NULL);
>+ debugfs_create_file("info", S_IRUSR, virtnic_debugfs_dir,
>+ NULL, &debugfs_info_fops);
>+ debugfs_create_file("enable_ints", S_IWUSR,
>+ virtnic_debugfs_dir, NULL,
>+ &debugfs_enable_ints_fops);
>+
>+ error = virtpci_register_driver(&virtnic_driver);
>+ if (error < 0) {
So, I've been trying to puzzle out what the architecture of this driver is.
>From what I've been able to gather:
1) The device this driver interfaces too is not a real device, but rather some
multipurpose chip that can expose network functions as well as several other
devices.
2) It's (the hardware's) device exposure is driven by some sideband interface
outside of the purview of the operating system
3) The virtpci driver that you have in the staging tree is responsible for
interfacing the root pci bridge to your hardware so that it (again your
hardware) can act like a pci bus to interface to these administratively plumbed
devices.
4) The net devices that this driver registers are typically meant (though not
required) to be used by guests via pci passthrough.
Is that all about correct? Just trying to get a handle on what all is going on
here.
Operating under the assumption that the above is correct (please correct me if
I'm wrong), I've got a few comments.
A) This isn't going to be accepted until the bus driver that provides access to
the pci interface for this hardware is merged. Without that bit, this driver
can't do anything.
B) Looking at the virtpci driver, it neds alot of cleanup before it has a hope
of going in. On the upside though, I think most of the code that needs cleaning
up, really just needs removal. 90% of that file in staging isn't called by
anything that I can tell. Thats not completely accrurate, in that you seem to
have a side band input path via virtpci_ctrlchan_func, which gets called from
the uisctrl library that appears to be used to create and manage devices, but it
all deadends there. See uislib_client_inject_add_vhba or
uislib_client_inject_add_vnic for examples. So I don't see a whole lot of need
for (at least not yet). I presume that, if this stuff works, theres some other
method of plumbing devices on the hardware asside from the uislib in staging.
As such, you can remove it for now. If thats not the case, then you have much
bigger problems, as I'm not sure how any of this works at all, since I don't see
a path for plumbing devices.
C) This isn't really a virtio driver, in the sense that virtio_net or veth is,
its more of an SRIOV device by another name, in that it drives real hardware, or
at least a virtual function on a real pci device.
I think, if you want to get it accepted, the fastest road forward would be to do
the following:
1) Gut virtpci.c. Remove anything non-functional from it. That would separate
you from your uislib, and make virtpci both fairly standalone and reasonably
small. That (I think) should make virtpci more amenable to mainline acceptance
if you repost it (I'll have to let the linux-pci list review that
more closely however). If thats accepted it should allow the pci core to
properly probe devices belonging to the above virtnic driver
2) rework virtnic to register with the pci core, not the redundant
virtpci_driver_register api. There should be no need for that. That will make
this a full fledged pci driver, which will be nice. Perhaps also rename it
(unisys_vfnic or something more indicative of its nature, so as to separate it
from the virtio family of devices. There may be other cleanups to do in the
driver as well (I've not looked at it in depth yet)
That should put you in a position where you have a functioning nic driver for
your hardware that you can either pass to a guest via pci passthrough, or use as
backing for a virtio_nic or veth device. It will be much more lean, and
maintainable, and from there you can start adding management bits back in.
Regards
Neil
^ permalink raw reply
* Re: [PATCH v2 1/3] dtb: xgene: fix: Backward compatibility with older firmware
From: Ian Campbell @ 2015-01-09 15:59 UTC (permalink / raw)
To: Iyappan Subramanian
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patches-qTEPVZfXA3Y, kchudgar-qTEPVZfXA3Y
In-Reply-To: <1415044796-5081-2-git-send-email-isubramanian-qTEPVZfXA3Y@public.gmane.org>
Hi Iyappan,
On Mon, 2014-11-03 at 11:59 -0800, Iyappan Subramanian wrote:
> The following kernel crash was reported when using older firmware (<= 1.13.28).
>
> [ 0.980000] libphy: APM X-Gene MDIO bus: probed
> [ 1.130000] Unhandled fault: synchronous external abort (0x96000010) at 0xffffff800009a17c
> [ 1.140000] Internal error: : 96000010 [#1] SMP
> [ 1.140000] Modules linked in:
> [ 1.140000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0+ #21
> [ 1.140000] task: ffffffc3f0110000 ti: ffffffc3f0064000 task.ti: ffffffc3f0064000
> [ 1.140000] PC is at ioread32+0x58/0x68
> [ 1.140000] LR is at xgene_enet_setup_ring+0x18c/0x1cc
I'm seeing what appears to be a similar crash (see the end) when booting
using UEFI firmware, which provides the DTB itself (as opposed to using
the kernel provided one like with u-boot).
Trying to boot using the kernel DTB instead of the firmware provided one
fails, I think because the UEFI firmware normally updates a bunch of
stuff at runtime in what it provides, but it can't in the external one.
(i.e. it has the wrong spintable stuff for cpu bringup)
This is running Debian's 3.16 kernel, which has the APM Ethernet related
stuff backported:
$ git log --oneline v3.16.7..debian/jessie/xgene
b2553d6 arm64: removed using of the mask attribute in the dts for reset bit.
2d209a4 arm64: add missing dts entry for X-Gene platform.
60651f8 dtb: Add SGMII based 1GbE node to APM X-Gene SoC device tree
3f3c3da dtb: Add 10GbE node to APM X-Gene SoC device tree
33b5408 drivers: net: xgene: fix: Use separate resources
092e35e drivers: net: xgene: Backward compatibility with older firmware
9f2bc2c drivers: net: xgene: Rewrite buggy loop in xgene_enet_ecc_init()
c566829 drivers: net: xgene: Add SGMII based 1GbE ethtool support
30bf224 drivers: net: xgene: Add SGMII based 1GbE support
0d03931 drivers: net: xgene: Preparing for adding SGMII based 1GbE
23a92cd drivers: net: xgene: Add 10GbE ethtool support
226068a drivers: net: xgene: Add 10GbE support
33f8dba drivers: net: xgene: Preparing for adding 10GbE support
a7b5fd0 dts: Add bindings for APM X-Gene SoC ethernet driver
82df3ba drivers: net: NET_XGENE should depend on HAS_DMA
0dcba55 net: xgene: fix possible NULL dereference in xgene_enet_free_desc_rings()
2aa3e0d net: xgene: Check negative return value of xgene_enet_get_ring_size()
589e045 drivers: net: Add APM X-Gene SoC ethernet driver support.
With the builtin DTB I see:
(initramfs) od -A x -t x4 /proc/device-tree/soc/ethernet@17020000/reg
000000 00000000 00000217 00000000 00d10000
000010 00000000 00000317 00000000 00040000
000020 00000000 00000010 00000000 00020000
Which seems to correspond to before your patch.
I'm running mustang_sw_1.13.29-beta, using the mustang_tianocore_ubt.fd
method to launch from u-boot.
Ian.
[ 7.662085] Unhandled fault: synchronous external abort (0x96000010) at 0xffffff800009a208
[ 7.670332] Internal error: : 96000010 [#1] SMP
[ 7.674839] Modules linked in: xgene_enet(+) of_mdio libphy dm_mod(+)
[ 7.681300] CPU: 0 PID: 97 Comm: systemd-udevd Not tainted 3.16.0-4-arm64 #1 Debian 3.16.7-ckt2-1
[ 7.690126] task: ffffffc3f9ca0c80 ti: ffffffc3f9d2c000 task.ti: ffffffc3f9d2c000
[ 7.697571] PC is at ioread32+0x58/0x68
[ 7.701388] LR is at xgene_ring_mgr_init+0x28/0x58 [xgene_enet]
[ 7.707276] pc : [<ffffffc0002e5318>] lr : [<ffffffbffc035d18>] pstate: a0000145
[ 7.714632] sp : ffffffc3f9d2f9c0
[ 7.717926] x29: ffffffc3f9d2f9c0 x28: 0000000000000001
[ 7.723229] x27: ffffffc0006fa000 x26: 0000000000000000
[ 7.728533] x25: ffffffc3f9ce9000 x24: ffffffc3f9ce9000
[ 7.733836] x23: ffffffc3eb876010 x22: ffffffc3eb876000
[ 7.739138] x21: ffffffc000763000 x20: ffffffc3f9ce98c0
[ 7.744443] x19: ffffffc3f9ce98c0 x18: 00000000c3663f63
[ 7.749745] x17: 00000000c14123be x16: 00000000ca92bd38
[ 7.755048] x15: 00000000d02a0bde x14: 0000000000000000
[ 7.760350] x13: 0000000000000000 x12: 0000000000000000
[ 7.765652] x11: 0000000000000000 x10: 0000000000000000
[ 7.770955] x9 : 0000000000000000 x8 : 0000000000000000
[ 7.776257] x7 : 0000000000000000 x6 : 0000000000000000
[ 7.781559] x5 : ffffffc00074b310 x4 : 0000000000000000
[ 7.786861] x3 : 0000000000000000 x2 : 000000000003ffff
[ 7.792165] x1 : ffffff800009a208 x0 : ffffff800009a208
[ 7.797467]
[ 7.798948] Process systemd-udevd (pid: 97, stack limit = 0xffffffc3f9d2c058)
[ 7.806046] Stack: (0xffffffc3f9d2f9c0 to 0xffffffc3f9d30000)
[ 7.811762] f9c0: f9d2f9d0 ffffffc3 fc035d18 ffffffbf f9d2f9f0 ffffffc3 fc035d6c ffffffbf
[ 7.819897] f9e0: f9ce98c0 ffffffc3 f9d2f9e0 ffffffc3 f9d2fa30 ffffffc3 fc038110 ffffffbf
[ 7.828032] fa00: f9ce98c0 ffffffc3 f9ce9000 ffffffc3 00763000 ffffffc0 f9ce9000 ffffffc3
[ 7.836167] fa20: 0000005c 00000000 00000000 00000000 f9d2fa80 ffffffc3 00343d24 ffffffc0
[ 7.844302] fa40: eb876010 ffffffc3 fc039f38 ffffffbf 0075d000 ffffffc0 00000000 00000000
[ 7.852436] fa60: fc039f60 ffffffbf 00000000 00000000 00000001 00000000 00000000 00000000
[ 7.860571] fa80: f9d2faa0 ffffffc3 00341ad0 ffffffc0 eb876010 ffffffc3 007cb000 ffffffc0
[ 7.868706] faa0: f9d2faf0 ffffffc3 00341edc ffffffc0 eb876010 ffffffc3 fc039f60 ffffffbf
[ 7.876840] fac0: eb876070 ffffffc3 00000000 00000000 0073d000 ffffffc0 00000000 00000000
[ 7.884974] fae0: fec449c0 ffffffc0 0033fa04 ffffffc0 f9d2fb20 ffffffc3 0033f9f8 ffffffc0
[ 7.893109] fb00: 00000000 00000000 fc039f60 ffffffbf 00341e30 ffffffc0 00000000 00000000
[ 7.901244] fb20: f9d2fb70 ffffffc3 003414f8 ffffffc0 fc039f60 ffffffbf f9c5d100 ffffffc3
[ 7.909378] fb40: 0073dd40 ffffffc0 ffffffe0 00000000 f9d2fb70 ffffffc3 00000000 00000000
[ 7.917512] fb60: eba48aa8 ffffffc3 ff4328e8 ffffffc3 f9d2fb90 ffffffc3 003410b4 ffffffc0
[ 7.925647] fb80: fc039f60 ffffffbf fc039f60 ffffffbf f9d2fbd0 ffffffc3 0034276c ffffffc0
[ 7.933781] fba0: fc039f60 ffffffbf fec4df00 ffffffc0 00000000 00000000 fc03d000 ffffffbf
[ 7.941916] fbc0: f9d2c000 ffffffc3 0073dd40 ffffffc0 f9d2fc00 ffffffc3 00343cec ffffffc0
[ 7.950050] fbe0: fc039f38 ffffffbf fec4df00 ffffffc0 006e07a0 ffffffc0 f9d2fc40 ffffffc3
[ 7.958185] fc00: f9d2fc30 ffffffc3 fc03d01c ffffffbf 006e07a0 ffffffc0 00081490 ffffffc0
[ 7.966319] fc20: 006e07a0 ffffffc0 fc03a240 ffffffbf f9d2fc40 ffffffc3 000814a0 ffffffc0
[ 7.974453] fc40: f9d2fcc0 ffffffc3 00109f30 ffffffc0 f9d2fe70 ffffffc3 00000001 00000000
[ 7.982588] fc60: fc03a258 ffffffbf f9d2c000 ffffffc3 fc03a290 ffffffbf fc03a240 ffffffbf
[ 7.990723] fc80: 0007d000 ffffff80 00000001 00000000 fc03a258 ffffffbf f9d2c000 ffffffc3
[ 7.998857] fca0: f9d2fcc0 ffffffc3 00109efc ffffffc0 f9d2fe70 ffffffc3 0010a264 ffffffc0
[ 8.006992] fcc0: f9d2fe40 ffffffc3 0010a8d8 ffffffc0 00000000 00000000 00000009 00000000
[ 8.015126] fce0: 94b29108 0000007f 94c78ee4 0000007f 60000000 00000000 00000015 00000000
[ 8.023261] fd00: 00000118 00000000 00000111 00000000 006e4000 ffffffc0 f9d2c000 ffffffc3
[ 8.031395] fd20: ff588500 ffffffc3 00106ad8 ffffffc0 fec449d0 ffffffc0 00000072 00000000
[ 8.039530] fd40: 0000006e 00000000 005e7140 ffffffc0 0000003f 00000000 0000feff 00000000
[ 8.047664] fd60: 0000fff1 00000000 0000001b 00000000 f9d2fde0 ffffffc3 0075a648 ffffffc0
[ 8.055799] fd80: 0075a3c8 ffffffc0 fc03d028 ffffffbf f9d2fec4 ffffffc3 000000f1 ffffff80
[ 8.063933] fda0: f9d2fe80 ffffffc3 94b29108 0000007f 006fa5b0 ffffffc0 007641a0 ffffffc0
[ 8.072068] fdc0: 60000000 00000000 00000015 00000000 00000010 00000000 0000138c 00000000
[ 8.080203] fde0: 00000001 ffff81a4 00000001 00000000 00000000 00000000 00000000 00000000
[ 8.088337] fe00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 8.096471] fe20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 8.104605] fe40: fb748da0 0000007f 0008421c ffffffc0 00000000 00000000 00000000 00000000
[ 8.112740] fe60: ffffffff ffffffff 00000009 00000000 0007d000 ffffff80 0000e3b8 00000000
[ 8.120874] fe80: 0008acb8 ffffff80 00083c8e ffffff80 00085428 ffffff80 00005478 00000000
[ 8.129009] fea0: 00005c40 00000000 fc03a178 ffffffbf 00000005 00000000 0000001a 0000001b
[ 8.137143] fec0: 00000012 0000000d 0000000c 00000000 00000009 00000000 94b29108 0000007f
[ 8.145278] fee0: 00000000 00000000 00000009 00000000 00000000 00000000 00000041 00000000
[ 8.153412] ff00: 00000001 00000000 00000001 00000000 00000111 00000000 6dff7364 644d3965
[ 8.161547] ff20: 00000000 00000000 0000000a 00000000 00000004 00000000 00000004 00000000
[ 8.169681] ff40: 67782f65 2d656e65 94cfa588 0000007f 94b3b290 0000007f 94c78ec0 0000007f
[ 8.177816] ff60: fb748b00 0000007f 74bd9070 00000055 00000000 00000000 94b29108 0000007f
[ 8.185950] ff80: 00020000 00000000 fb7493c8 0000007f 74bd9200 00000055 74be13e0 00000055
[ 8.194084] ffa0: 00000000 00000000 00000000 00000000 00020000 00000000 fb748da0 0000007f
[ 8.202219] ffc0: 94b22d44 0000007f fb748da0 0000007f 94c78ee4 0000007f 60000000 00000000
[ 8.210353] ffe0: 00000009 00000000 00000111 00000000 00000000 00000000 00000000 00000000
[ 8.218487] Call trace:
[ 8.220920] [<ffffffc0002e5318>] ioread32+0x58/0x68
[ 8.225773] [<ffffffbffc035d14>] xgene_ring_mgr_init+0x24/0x58 [xgene_enet]
[ 8.232699] [<ffffffbffc035d68>] xgene_enet_reset+0x20/0x17c [xgene_enet]
[ 8.239452] [<ffffffbffc03810c>] xgene_enet_probe+0x2c4/0x784 [xgene_enet]
[ 8.246292] [<ffffffc000343d20>] platform_drv_probe+0x28/0x60
[ 8.252008] [<ffffffc000341acc>] driver_probe_device+0xa4/0x3ac
[ 8.257896] [<ffffffc000341ed8>] __driver_attach+0xa8/0xb0
[ 8.263352] [<ffffffc00033f9f4>] bus_for_each_dev+0x68/0xac
[ 8.268895] [<ffffffc0003414f4>] driver_attach+0x2c/0x38
[ 8.274177] [<ffffffc0003410b0>] bus_add_driver+0x16c/0x248
[ 8.279720] [<ffffffc000342768>] driver_register+0x6c/0x138
[ 8.285262] [<ffffffc000343ce8>] __platform_driver_register+0x74/0x84
[ 8.291670] [<ffffffbffc03d018>] $x+0x18/0x24 [xgene_enet]
[ 8.297127] [<ffffffc00008149c>] do_one_initcall+0xcc/0x1bc
[ 8.302671] [<ffffffc000109f2c>] load_module+0x1a20/0x220c
[ 8.308127] [<ffffffc00010a8d4>] SyS_finit_module+0x94/0xc0
[ 8.313670] Code: 97ffffa5 12800000 a8c17bfd d65f03c0 (b9400000)
[ 8.319746] ---[ end trace f59ed15aa4f2049f ]---
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/1] csiostor:fix sparse warnings
From: Praveen Madhavan @ 2015-01-09 15:55 UTC (permalink / raw)
To: netdev, linux-scsi; +Cc: davem, JBottomley, hch, hariprasad, praveenm
This patch fixes sparse warning reported by kbuild.
Apply this on net-next since it depends on previous commit.
drivers/scsi/csiostor/csio_hw.c:259:17: sparse: cast to restricted __le32
drivers/scsi/csiostor/csio_hw.c:536:31: sparse: incorrect type in assignment
(different base types)
drivers/scsi/csiostor/csio_hw.c:536:31: expected unsigned int [unsigned]
[usertype] <noident>
drivers/scsi/csiostor/csio_hw.c:536:31: got restricted __be32 [usertype]
<noident>
>> drivers/scsi/csiostor/csio_hw.c:2012:5: sparse: symbol 'csio_hw_prep_fw' was
not declared. Should it be static?
Signed-off-by: Praveen Madhavan <praveenm@chelsio.com>
---
drivers/scsi/csiostor/csio_hw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/csiostor/csio_hw.c b/drivers/scsi/csiostor/csio_hw.c
index b70c15f..5c31fa6 100644
--- a/drivers/scsi/csiostor/csio_hw.c
+++ b/drivers/scsi/csiostor/csio_hw.c
@@ -256,7 +256,7 @@ csio_hw_seeprom_read(struct csio_hw *hw, uint32_t addr, uint32_t *data)
}
pci_read_config_dword(hw->pdev, base + PCI_VPD_DATA, data);
- *data = le32_to_cpu(*data);
+ *data = le32_to_cpu(*(__le32 *)data);
return 0;
}
@@ -533,7 +533,7 @@ csio_hw_read_flash(struct csio_hw *hw, uint32_t addr, uint32_t nwords,
if (ret)
return ret;
if (byte_oriented)
- *data = htonl(*data);
+ *data = (__force __u32) htonl(*data);
}
return 0;
}
@@ -2009,7 +2009,7 @@ static struct fw_info *find_fw_info(int chip)
return NULL;
}
-int csio_hw_prep_fw(struct csio_hw *hw, struct fw_info *fw_info,
+static int csio_hw_prep_fw(struct csio_hw *hw, struct fw_info *fw_info,
const u8 *fw_data, unsigned int fw_size,
struct fw_hdr *card_fw, enum csio_dev_state state,
int *reset)
--
2.0.2
^ permalink raw reply related
* Re: [PATCH net] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments
From: Hannes Frederic Sowa @ 2015-01-09 15:50 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Rahul Sharma, netdev, linux-kernel, netfilter-devel
In-Reply-To: <20150109114506.GA4857@salvia>
On Fr, 2015-01-09 at 12:45 +0100, Pablo Neira Ayuso wrote:
> Hi Hannes,
>
> On Fri, Jan 09, 2015 at 12:34:15PM +0100, Hannes Frederic Sowa wrote:
> > On Fri, Jan 9, 2015, at 08:18, Rahul Sharma wrote:
> > > Hi Pablo,
> > >
> > > On Fri, Jan 9, 2015 at 5:35 AM, Pablo Neira Ayuso <pablo@netfilter.org>
> > > wrote:
> > > > On Thu, Jan 08, 2015 at 11:39:16PM +0100, Hannes Frederic Sowa wrote:
> > > >> Hi Pablo,
> > > >>
> > > >> On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
> > > >> > I'm afraid we cannot just get rid of that !ipv6_ext_hdr() check. The
> > > >> > ipv6_find_hdr() function is designed to return the transport protocol.
> > > >> > After the proposed change, it will return extension header numbers.
> > > >> > This will break existing ip6tables rulesets since the `-p' option
> > > >> > relies on this function to match the transport protocol.
> > > >> >
> > > >> > Note that the AH header is skipped (see code a bit below this
> > > >> > problematic fragmentation handling) so the follow up header after the
> > > >> > AH header is returned as the transport header.
> > > >> >
> > > >> > We can probably return the AH protocol number for non-1st fragments.
> > > >> > However, that would be something new to ip6tables since nobody has
> > > >> > ever seen packet matching `-p ah' rules. Thus, we restore control to
> > > >> > the user to allow this, but we would accept all kind of fragmented AH
> > > >> > traffic through the firewall since we cannot know what transport
> > > >> > protocol contains from non-1st fragments (unless I'm missing anything,
> > > >> > I need to have a closer look at this again tomorrow with fresher
> > > >> > mind).
> > > >>
> > > >> The code in question is guarded by (_frag_off != 0), so we are
> > > >> definitely processing a non-1st fragment currently. The -p match would
> > > >> happen at the time when the packet is reassembled and thus ipv6_find_hdr
> > > >> will find the real transport (final) header at this point (I hope I
> > > >> followed the code correctly here).
> > > >
> > > > Then, Rahul should get things working by modprobing nf_defrag_ipv6.
> > >
> > > I already had nf_defrag_ipv6 installed when the issue occured. But I
> > > see ip6table_raw_hook returning NF_DROP for the second fragment.
> >
> > That's what I expected. I think the change only affects hooks before
> > reassembly.
>
> reassembly happens at NF_IP6_PRI_CONNTRACK_DEFRAG (-400), so that
> happens before NF_IP6_PRI_RAW (-300) in IPv6 which is where the raw
> table is placed.
I tried to reproduce it, but couldn't get non-1st fragments getting
dropped during traversal of the raw table. They get dropped earlier at
during reassembly or pass.
I agree with Pablo, I also would like to see more data.
Thanks,
Hannes
^ permalink raw reply
* Re: NULL pointer dereference at skb_queue_tail()
From: Eric Dumazet @ 2015-01-09 15:45 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: cwang, netdev
In-Reply-To: <201501092220.DIB43754.FFMQOSJLOOHVtF@I-love.SAKURA.ne.jp>
On Fri, 2015-01-09 at 22:20 +0900, Tetsuo Handa wrote:
> Would you tell me which versions to test?
Could you do a bisection ?
I do not see obvious bugs in af_unix.c, so it might be a corruption from
another part of the code, reusing a freed skb.
^ permalink raw reply
* Re: [PATCH] net: unisys: adding unisys virtnic driver
From: Jes Sorensen @ 2015-01-09 15:44 UTC (permalink / raw)
To: Erik Arfvidson
Cc: benjamin.romer, netdev, dzickus, davem, Bruce.Vessey,
sparmaintainer, prarit, Neil Horman
In-Reply-To: <1418842340-29894-1-git-send-email-earfvids@redhat.com>
Erik Arfvidson <earfvids@redhat.com> writes:
> The purpose of this patch is to add Unisys virtual network driver
> into the network directory and also to start a discussion about
> the requirements needed.
>
> Signed-off-by: Erik Arfvidson <earfvids@redhat.com>
Erik,
I was discussing this with colleagues and I want to give you some
general comments on this. My comments are not specific to virtnic.c
itself.
Looking over the logs of drivers/staging/unisys, I noticed a fair amount
of cleanups has been applied, but not a lot of fixes addressing what I
would consider the real issues.
The first thing you should work on is to get rid of
drivers/staging/unisys/uislib - it looks to provide a lot of wrappers
and utility functions which already exist. You need to address things
like:
- Custom atomic primitives (uisqueue.c)
- List handlers (use list.h) and all the utility functions we provide
- Functions for launching killing kernel threads (uisthread)
- There is most of a bus implementation in there - is this really
needed, ie. are the devices sitting on a PCI bus, or is this some
special bus type?
- Use proper data types - your code should contain no 'long long' ever!
If you need data types of a specific size, use u8/u16/u32/u64, and
please get rid of broken Windows stuff such as BOOL and #pragma.
- /proc handlers - you should most likely be using /sys
(configs/debugfs) and don't wrap things in libraries, do it near the
code using it.
Basically I recommend you start working your way through uislib, and
once you have eliminated 90% of it, you should be a lot closer to code
that can go into mainline.
I know my colleague Neil has some issues on this specific driver, which
I have less insight into, so I think he'll post some comments on that
too.
I hope this is helpful!
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH net-next v2 1/8] r8169:change rtl8168dp jumbo frame patch
From: Sergei Shtylyov @ 2015-01-09 15:41 UTC (permalink / raw)
To: Chunhao Lin, netdev; +Cc: nic_swsd, linux-kernel
In-Reply-To: <1420817166-9868-2-git-send-email-hau@realtek.com>
Hello.
On 1/9/2015 6:25 PM, Chunhao Lin wrote:
> RTL8168DP jumbo frame patch is the same as RTL8168C. So, for RTL8168DP,
> change to use RTL8168C jumbo frame patch. Also reomve uncessary function
s/reomve uncessary/remove unnecessary/.
> "r8168dp_hw_jumbo_enable" and "r8168dp_hw_jumbo_disable".
>
> Signed-off-by: Chunhao Lin <hau@realtek.com>
WBR, Sergei
^ permalink raw reply
* [PATCH net-next v2 6/8] r8169:update pcie ephy parameters to decrease the resume time from L0s to L0
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
For RTL8168EVL, RTL8168F, RTL8411, and RTL8105E, their pcie ephy will have bit
error check reset after receive FTS and cause pcie ephy enter recovery mode.
This will cause pcie ephy resume from L0s to L0 too slow.
This patch adjust the pcie ephy parameter to decrease the resume time from L0s
to L0.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index ade7144..483fa40 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5778,7 +5778,9 @@ static void rtl_hw_start_8168e_2(struct rtl8169_private *tp)
struct pci_dev *pdev = tp->pci_dev;
static const struct ephy_info e_info_8168e_2[] = {
{ 0x09, 0x0000, 0x0080 },
- { 0x19, 0x0000, 0x0224 }
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
};
rtl_csi_access_enable_1(tp);
@@ -5850,7 +5852,9 @@ static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
{ 0x06, 0x00c0, 0x0020 },
{ 0x08, 0x0001, 0x0002 },
{ 0x09, 0x0000, 0x0080 },
- { 0x19, 0x0000, 0x0224 }
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
};
rtl_hw_start_8168f(tp);
@@ -5865,17 +5869,19 @@ static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
static void rtl_hw_start_8411(struct rtl8169_private *tp)
{
- static const struct ephy_info e_info_8168f_1[] = {
+ static const struct ephy_info e_info_8411[] = {
{ 0x06, 0x00c0, 0x0020 },
{ 0x0f, 0xffff, 0x5200 },
{ 0x1e, 0x0000, 0x4000 },
- { 0x19, 0x0000, 0x0224 }
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
};
rtl_hw_start_8168f(tp);
rtl_pcie_state_l2l3_enable(tp, false);
- rtl_ephy_init(tp, e_info_8168f_1, ARRAY_SIZE(e_info_8168f_1));
+ rtl_ephy_init(tp, e_info_8411, ARRAY_SIZE(e_info_8411));
rtl_w0w1_eri(tp, 0x0d4, ERIAR_MASK_0011, 0x0c00, 0x0000, ERIAR_EXGMAC);
}
@@ -6397,7 +6403,8 @@ static void rtl_hw_start_8105e_1(struct rtl8169_private *tp)
{ 0x03, 0, 0x0001 },
{ 0x19, 0, 0x0100 },
{ 0x19, 0, 0x0004 },
- { 0x0a, 0, 0x0020 }
+ { 0x0a, 0, 0x0020 },
+ { 0x05, 0, 0x2000 }
};
/* Force LAN exit from ASPM if Rx/Tx are not idle */
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 4/8] r8169:rtl8168dp rev.c pcie ephy setting is the same as rtl8168dp rev.b
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
Thease two chips should use the same pcie ephy parameters. So only need
function rtl_hw_start_8168d_4. Function rtl_hw_start_8168dp is uncessary.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 540a6b8..928e35a 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5711,21 +5711,6 @@ static void rtl_hw_start_8168d(struct rtl8169_private *tp)
RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) & ~R8168_CPCMD_QUIRK_MASK);
}
-static void rtl_hw_start_8168dp(struct rtl8169_private *tp)
-{
- void __iomem *ioaddr = tp->mmio_addr;
- struct pci_dev *pdev = tp->pci_dev;
-
- rtl_csi_access_enable_1(tp);
-
- if (tp->dev->mtu <= ETH_DATA_LEN)
- rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
-
- RTL_W8(MaxTxPacketSize, TxPacketMax);
-
- rtl_disable_clock_request(pdev);
-}
-
static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -6271,11 +6256,8 @@ static void rtl_hw_start_8168(struct net_device *dev)
break;
case RTL_GIGA_MAC_VER_28:
- rtl_hw_start_8168d_4(tp);
- break;
-
case RTL_GIGA_MAC_VER_31:
- rtl_hw_start_8168dp(tp);
+ rtl_hw_start_8168d_4(tp);
break;
case RTL_GIGA_MAC_VER_32:
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 8/8] r8169:update rtl8168f rev.b pcie ephy parameter
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
RTL8168F rev.B does not have to set following two ephy parameters.
{ 0x06, 0x00c0, 0x0020 }
{ 0x08, 0x0001, 0x0002 }
Add function rtl_hw_start_8168f_2 to set RTL8168F rev.B ephy parameters,
instead of using function rtl_hw_start_8168f_1.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index aa12833..0c870f5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5867,6 +5867,26 @@ static void rtl_hw_start_8168f_1(struct rtl8169_private *tp)
RTL_W8(EEE_LED, RTL_R8(EEE_LED) & ~0x07);
}
+static void rtl_hw_start_8168f_2(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ static const struct ephy_info e_info_8168f_2[] = {
+ { 0x09, 0x0000, 0x0080 },
+ { 0x19, 0x0000, 0x0224 },
+ { 0x00, 0x0000, 0x0008 },
+ { 0x0c, 0x3df0, 0x0200 }
+ };
+
+ rtl_hw_start_8168f(tp);
+
+ rtl_ephy_init(tp, e_info_8168f_2, ARRAY_SIZE(e_info_8168f_2));
+
+ rtl_w0w1_eri(tp, 0x0d4, ERIAR_MASK_0011, 0x0c00, 0xff00, ERIAR_EXGMAC);
+
+ /* Adjust EEE LED frequency */
+ RTL_W8(EEE_LED, RTL_R8(EEE_LED) & ~0x07);
+}
+
static void rtl_hw_start_8411(struct rtl8169_private *tp)
{
static const struct ephy_info e_info_8411[] = {
@@ -6276,9 +6296,11 @@ static void rtl_hw_start_8168(struct net_device *dev)
break;
case RTL_GIGA_MAC_VER_35:
- case RTL_GIGA_MAC_VER_36:
rtl_hw_start_8168f_1(tp);
break;
+ case RTL_GIGA_MAC_VER_36:
+ rtl_hw_start_8168f_2(tp);
+ break;
case RTL_GIGA_MAC_VER_38:
rtl_hw_start_8411(tp);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 7/8] r8169:update rtl8402 pcie ephy parameter
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
Remove following unnecessary ephy parameter.
{ 0x1e, 0, 0x4000 }
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 483fa40..aa12833 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6431,8 +6431,7 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
static const struct ephy_info e_info_8402[] = {
- { 0x19, 0xffff, 0xff64 },
- { 0x1e, 0, 0x4000 }
+ { 0x19, 0xffff, 0xff64 }
};
rtl_csi_access_enable_2(tp);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 5/8] r8169:update rtl8168dp pcie ephy parameters to improve power consumption
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
The following parameter will disable more pcie ephy block (like pcie ephy
read/write clock.....etc ) to save more power when in aspm+clkreq mode.
{ 0x10, 0x0004, 0x0000 }
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 928e35a..ade7144 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5718,7 +5718,8 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
static const struct ephy_info e_info_8168d_4[] = {
{ 0x0b, 0x0000, 0x0048 },
{ 0x19, 0x0020, 0x0050 },
- { 0x0c, 0x0100, 0x0020 }
+ { 0x0c, 0x0100, 0x0020 },
+ { 0x10, 0x0004, 0x0000 }
};
rtl_csi_access_enable_1(tp);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 3/8] r8169:correct the way of setting rtl8168dp pcie ephy parameters
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
The original way is wrong, it always sets the ephy reg 0x03. Correct it
in this patch.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 991bda5..540a6b8 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5731,11 +5731,10 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
void __iomem *ioaddr = tp->mmio_addr;
struct pci_dev *pdev = tp->pci_dev;
static const struct ephy_info e_info_8168d_4[] = {
- { 0x0b, ~0, 0x48 },
- { 0x19, 0x20, 0x50 },
- { 0x0c, ~0, 0x20 }
+ { 0x0b, 0x0000, 0x0048 },
+ { 0x19, 0x0020, 0x0050 },
+ { 0x0c, 0x0100, 0x0020 }
};
- int i;
rtl_csi_access_enable_1(tp);
@@ -5744,13 +5743,7 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, TxPacketMax);
- for (i = 0; i < ARRAY_SIZE(e_info_8168d_4); i++) {
- const struct ephy_info *e = e_info_8168d_4 + i;
- u16 w;
-
- w = rtl_ephy_read(tp, e->offset);
- rtl_ephy_write(tp, 0x03, (w & e->mask) | e->bits);
- }
+ rtl_ephy_init(tp, e_info_8168d_4, ARRAY_SIZE(e_info_8168d_4));
rtl_enable_clock_request(pdev);
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 2/8] r8169:update rtl8168e and rtl8168evl jumbo frame patch
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
RTL8168E and RTL8168EVL do not need to change pcie max read request size
when jumbo frame is enabled. So remove setting pcie max read request
size from their jumbo frame patch.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 72d15b8..991bda5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4934,7 +4934,6 @@ static void r8168e_hw_jumbo_enable(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, 0x3f);
RTL_W8(Config3, RTL_R8(Config3) | Jumbo_En0);
RTL_W8(Config4, RTL_R8(Config4) | 0x01);
- rtl_tx_performance_tweak(tp->pci_dev, 0x2 << MAX_READ_REQUEST_SHIFT);
}
static void r8168e_hw_jumbo_disable(struct rtl8169_private *tp)
@@ -4944,7 +4943,6 @@ static void r8168e_hw_jumbo_disable(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, 0x0c);
RTL_W8(Config3, RTL_R8(Config3) & ~Jumbo_En0);
RTL_W8(Config4, RTL_R8(Config4) & ~0x01);
- rtl_tx_performance_tweak(tp->pci_dev, 0x5 << MAX_READ_REQUEST_SHIFT);
}
static void r8168b_0_hw_jumbo_enable(struct rtl8169_private *tp)
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 1/8] r8169:change rtl8168dp jumbo frame patch
From: Chunhao Lin @ 2015-01-09 15:25 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
RTL8168DP jumbo frame patch is the same as RTL8168C. So, for RTL8168DP,
change to use RTL8168C jumbo frame patch. Also reomve uncessary function
"r8168dp_hw_jumbo_enable" and "r8168dp_hw_jumbo_disable".
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 28 ++++++----------------------
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3a28059..72d15b8 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4927,20 +4927,6 @@ static void r8168c_hw_jumbo_disable(struct rtl8169_private *tp)
rtl_tx_performance_tweak(tp->pci_dev, 0x5 << MAX_READ_REQUEST_SHIFT);
}
-static void r8168dp_hw_jumbo_enable(struct rtl8169_private *tp)
-{
- void __iomem *ioaddr = tp->mmio_addr;
-
- RTL_W8(Config3, RTL_R8(Config3) | Jumbo_En0);
-}
-
-static void r8168dp_hw_jumbo_disable(struct rtl8169_private *tp)
-{
- void __iomem *ioaddr = tp->mmio_addr;
-
- RTL_W8(Config3, RTL_R8(Config3) & ~Jumbo_En0);
-}
-
static void r8168e_hw_jumbo_enable(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -5014,16 +5000,13 @@ static void rtl_init_jumbo_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_25:
case RTL_GIGA_MAC_VER_26:
- ops->disable = r8168c_hw_jumbo_disable;
- ops->enable = r8168c_hw_jumbo_enable;
- break;
case RTL_GIGA_MAC_VER_27:
case RTL_GIGA_MAC_VER_28:
- ops->disable = r8168dp_hw_jumbo_disable;
- ops->enable = r8168dp_hw_jumbo_enable;
+ case RTL_GIGA_MAC_VER_31:
+ ops->disable = r8168c_hw_jumbo_disable;
+ ops->enable = r8168c_hw_jumbo_enable;
break;
- case RTL_GIGA_MAC_VER_31: /* Wild guess. Needs info from Realtek. */
- case RTL_GIGA_MAC_VER_32:
+ case RTL_GIGA_MAC_VER_32: /* Wild guess. Needs info from Realtek. */
case RTL_GIGA_MAC_VER_33:
case RTL_GIGA_MAC_VER_34:
ops->disable = r8168e_hw_jumbo_disable;
@@ -5758,7 +5741,8 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
rtl_csi_access_enable_1(tp);
- rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
+ if (tp->dev->mtu <= ETH_DATA_LEN)
+ rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
RTL_W8(MaxTxPacketSize, TxPacketMax);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 0/8]r8169:update hardware parameter
From: Chunhao Lin @ 2015-01-09 15:25 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
These series of patch include the pcie ephy parameter update of
following adapters.
rtl8411
rtl8168f
rtl8168evl
rtl8168dp
rtl8105
rtl8402
And include jumbo frame patch update of following adapters.
rtl8168dp
rtl8168e
rtl8168evl
Also remove unnecessary function rtl_hw_start_8168dp and add function
rtl_hw_start_8168f_2 to set rtl8168f rev.b pcie ephy parameters.
In v2 patch, give more explanation about pcie ephy parameter update.
Chunhao Lin (8):
r8169:change rtl8168dp jumbo frame patch
r8169:update rtl8168e and rtl8168evl jumbo frame patch
r8169:correct the way of setting rtl8168dp pcie ephy parameters
r8169:rtl8168dp rev.c pcie ephy setting is the same as rtl8168dp rev.b
r8169:update rtl8168dp pcie ephy parameters to improve power
consumption
r8169:update pcie ephy parameters to decrease the resume time from L0s
to L0
r8169:update rtl8402 pcie ephy parameter
r8169:update rtl8168f rev.b pcie ephy parameter
drivers/net/ethernet/realtek/r8169.c | 112 +++++++++++++++--------------------
1 file changed, 49 insertions(+), 63 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 2/2] mdio-mux-gpio: use new gpiod_get_array and gpiod_put_array functions
From: Rojhalat Ibrahim @ 2015-01-09 15:19 UTC (permalink / raw)
To: linux-gpio@vger.kernel.org
Cc: Alexandre Courbot, Linus Walleij, David Miller, netdev
Use the new gpiod_get_array and gpiod_put_array functions for obtaining and
disposing of GPIO descriptors.
Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
---
This patch depends on my previous patch "gpiolib: add gpiod_get_array and
gpiod_put_array functions".
drivers/net/phy/mdio-mux-gpio.c | 28 ++++++++--------------------
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-gpio.c b/drivers/net/phy/mdio-mux-gpio.c
index 1eaf81e..35c37da 100644
--- a/drivers/net/phy/mdio-mux-gpio.c
+++ b/drivers/net/phy/mdio-mux-gpio.c
@@ -47,7 +47,6 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
{
struct mdio_mux_gpio_state *s;
int num_gpios;
- unsigned int n;
int r;
if (!pdev->dev.of_node)
@@ -63,16 +62,10 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
s->num_gpios = num_gpios;
- for (n = 0; n < num_gpios; ) {
- struct gpio_desc *gpio = gpiod_get_index(&pdev->dev, NULL, n,
- GPIOD_OUT_LOW);
- if (IS_ERR(gpio)) {
- r = PTR_ERR(gpio);
- goto err;
- }
- s->gpio[n] = gpio;
- n++;
- }
+ r = gpiod_get_array(&pdev->dev, NULL, s->gpio, num_gpios,
+ GPIOD_OUT_LOW);
+ if (r != num_gpios)
+ return r;
r = mdio_mux_init(&pdev->dev,
mdio_mux_gpio_switch_fn, &s->mux_handle, s);
@@ -80,22 +73,17 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
if (r == 0) {
pdev->dev.platform_data = s;
return 0;
+ } else {
+ gpiod_put_array(s->gpio, num_gpios);
+ return r;
}
-err:
- while (n) {
- n--;
- gpiod_put(s->gpio[n]);
- }
- return r;
}
static int mdio_mux_gpio_remove(struct platform_device *pdev)
{
- unsigned int n;
struct mdio_mux_gpio_state *s = dev_get_platdata(&pdev->dev);
mdio_mux_uninit(s->mux_handle);
- for (n = 0; n < s->num_gpios; n++)
- gpiod_put(s->gpio[n]);
+ gpiod_put_array(s->gpio, s->num_gpios);
return 0;
}
--
2.0.5
^ permalink raw reply related
* [PATCH 1/1] openvswitch: Remove unnecessary version.h inclusion
From: Syam Sidhardhan @ 2015-01-09 14:56 UTC (permalink / raw)
To: netdev, syamsidhardh, pshelar, davem, dev; +Cc: Syam Sidhardhan
version.h inclusion is not necessary as detected by versioncheck.
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
---
net/openvswitch/vport-geneve.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/openvswitch/vport-geneve.c b/net/openvswitch/vport-geneve.c
index 347fa23..70e2aae 100644
--- a/net/openvswitch/vport-geneve.c
+++ b/net/openvswitch/vport-geneve.c
@@ -9,8 +9,6 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include <linux/version.h>
-
#include <linux/in.h>
#include <linux/ip.h>
#include <linux/net.h>
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH iproute2 3/3] ip netns: Delete all netns
From: Nicolas Dichtel @ 2015-01-09 14:24 UTC (permalink / raw)
To: Vadim Kochan, Jiri Benc; +Cc: Brian Haley, netdev@vger.kernel.org
In-Reply-To: <CAMw6YJLx0O6dVnD2XcmF+qz+=m51TyZOqJWSYGKQ-XrMHP8z3w@mail.gmail.com>
Le 09/01/2015 10:54, Vadim Kochan a écrit :
> Ok,
>
> If I will re-work to use new option, would it be useful ? So it will look:
>
> $ ip -all netns del
> $ ip -all netns exec ip link
> $ ip -all netns exec ip route add ...
>
> Seems not so weird to me ?
What about making this new option only for the 'netns' subsystem?
Something like: 'ip netns -all exec'?
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH v3 4/4] can: kvaser_usb: Add support for the Usbcan-II family
From: Marc Kleine-Budde @ 2015-01-09 14:05 UTC (permalink / raw)
To: Ahmed S. Darwish
Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML
In-Reply-To: <20150109030657.GA1791@vivalin-002>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
On 01/09/2015 04:06 AM, Ahmed S. Darwish wrote:
>>>
>>> cf->can_id |= CAN_ERR_CRTL;
>>> cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
>>>
>>> stats->rx_over_errors++;
>>> stats->rx_errors++;
>>>
>>> netif_rx(skb);
>>>
>>> stats->rx_packets++;
>>> stats->rx_bytes += cf->can_dlc;
>>
>> Another patch would be not to touch cf after netif_rx(), please
>> move the stats handling before calling netif_rx(). Same applies to
>> the kvaser_usb_rx_can_msg() function.
> BTW, is it guaranteed from the SocketCAN stack that netif_rx()
netif_rx() is the generic networking stack already.
> will never return NET_RX_DROPPED? Because if no guarantee
> exists, I guess below fragment cannot be completely correct?
No, it's not guaranteed...
>
> stats->rx_packets++;
> stats->rx_bytes += cf->can_dlc;
> netif_rx(skb);
>
> On the other hand, I don't see evan a single CAN driver checking
> netif_rx() return value, so maybe such a check is an overkill...
A quick look shows that almost no ethernet or wireless drivers take care
about the return value. In case of a RX_DROPPED some increase a drop
counter, though.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] ethernet: atheros: Add nss-gmac driver
From: Mark Rutland @ 2015-01-09 13:50 UTC (permalink / raw)
To: Stephen Wang
Cc: jcliburn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1420754626-30121-1-git-send-email-wstephen-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Thu, Jan 08, 2015 at 10:03:46PM +0000, Stephen Wang wrote:
> This driver adds support for the internal GMACs on IPQ806x SoCs.
> It supports the device-tree and will register up to 4 ethernet
> interfaces.
>
> Signed-off-by: Stephen Wang <wstephen-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> drivers/net/ethernet/atheros/Kconfig | 10 +
> drivers/net/ethernet/atheros/Makefile | 1 +
> drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt | 14 +
> drivers/net/ethernet/atheros/nss-gmac/Makefile | 19 +
> .../atheros/nss-gmac/exports/nss_gmac_api_if.h | 126 ++
> .../atheros/nss-gmac/include/msm_nss_gmac.h | 338 ++++
> .../atheros/nss-gmac/include/msm_nss_macsec.h | 73 +
> .../atheros/nss-gmac/include/nss_gmac_clocks.h | 100 +
> .../atheros/nss-gmac/include/nss_gmac_dev.h | 2136 ++++++++++++++++++++
> .../nss-gmac/include/nss_gmac_network_interface.h | 63 +
> .../net/ethernet/atheros/nss-gmac/nss_gmac_ctrl.c | 1210 +++++++++++
> .../net/ethernet/atheros/nss-gmac/nss_gmac_dev.c | 1963 ++++++++++++++++++
> .../ethernet/atheros/nss-gmac/nss_gmac_ethtool.c | 526 +++++
> .../net/ethernet/atheros/nss-gmac/nss_gmac_init.c | 1131 +++++++++++
> .../ethernet/atheros/nss-gmac/nss_gmac_mdiobus.c | 187 ++
> .../atheros/nss-gmac/nss_gmac_tx_rx_offload.c | 1175 +++++++++++
Device tree bindings _must_ be documented, yet this standalone patch
adds nothing to Documentation/devicetree/bindings per the diffstat
above. So trivial NAK until there's a patch documenting that.
See Documentation/devicetree/bindings/submitting-patches.txt
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Winning Notification !!!
From: UK FREE LOTTO @ 2015-01-09 13:27 UTC (permalink / raw)
Your email ID has made you a bonafide winner of the sum of $2,000,000.00 USD, Provide your Name,Country,Occupation and Tel. So that your winning will be activate and open to your name.
^ permalink raw reply
* Re: [PATCH net-next 16/16] tipc: make netlink support net namespace
From: Sergei Shtylyov @ 2015-01-09 13:42 UTC (permalink / raw)
To: Ying Xue, davem
Cc: jon.maloy, Tero.Aho, Paul.Gortmaker, erik.hugne, richard.alpe,
netdev, tipc-discussion
In-Reply-To: <1420788433-17960-17-git-send-email-ying.xue@windriver.com>
Hello.
On 1/9/2015 10:27 AM, Ying Xue wrote:
> Currently tipc module only allows users sitting on "init_net" namespace
> to configure it through netlink interface. But now almost each tipc
> component is able to be aware of net namespace, so it's time to open
> the permission for users residing in other namespaces, allowing them
> to configure their own tipc stack instance through netlink interface.
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> Tested-by: Tero Aho <Tero.Aho@coriant.com>
> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
> ---
> net/tipc/netlink.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
> diff --git a/net/tipc/netlink.c b/net/tipc/netlink.c
> index 282b596..fe0f513 100644
> --- a/net/tipc/netlink.c
> +++ b/net/tipc/netlink.c
> @@ -54,7 +54,8 @@ static int handle_cmd(struct sk_buff *skb, struct genl_info *info)
> int hdr_space = nlmsg_total_size(GENL_HDRLEN + TIPC_GENL_HDRLEN);
> u16 cmd;
>
> - if ((req_userhdr->cmd & 0xC000) && (!netlink_capable(skb, CAP_NET_ADMIN)))
> + if ((req_userhdr->cmd & 0xC000) &&
> + (!netlink_net_capable(skb, CAP_NET_ADMIN)))
Why? Also, it seems like unrelated change...
[...]
WBR, Sergei
^ 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