* [Xen-devel] [PATCH net v6] xen-netfront: fix resource leak in netfront
From: Annie Li @ 2014-01-28 3:35 UTC (permalink / raw)
To: xen-devel, netdev
Cc: konrad.wilk, ian.campbell, wei.liu2, david.vrabel, annie.li
From: Annie Li <annie.li@oracle.com>
This patch removes grant transfer releasing code from netfront, and uses
gnttab_end_foreign_access to end grant access since
gnttab_end_foreign_access_ref may fail when the grant entry is
currently used for reading or writing.
* clean up grant transfer code kept from old netfront(2.6.18) which grants
pages for access/map and transfer. But grant transfer is deprecated in current
netfront, so remove corresponding release code for transfer.
* fix resource leak, release grant access (through gnttab_end_foreign_access)
and skb for tx/rx path, use get_page to ensure page is released when grant
access is completed successfully.
Xen-blkfront/xen-tpmfront/xen-pcifront also have similar issue, but patches
for them will be created separately.
V6: Correct subject line and commit message.
V5: Remove unecessary change in xennet_end_access.
V4: Revert put_page in gnttab_end_foreign_access, and keep netfront change in
single patch.
V3: Changes as suggestion from David Vrabel, ensure pages are not freed untill
grant acess is ended.
V2: Improve patch comments.
Signed-off-by: Annie Li <annie.li@oracle.com>
---
drivers/net/xen-netfront.c | 88 +++++++++++++-------------------------------
1 files changed, 26 insertions(+), 62 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index d7bee8a..6ddf1e6 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -117,6 +117,7 @@ struct netfront_info {
} tx_skbs[NET_TX_RING_SIZE];
grant_ref_t gref_tx_head;
grant_ref_t grant_tx_ref[NET_TX_RING_SIZE];
+ struct page *grant_tx_page[NET_TX_RING_SIZE];
unsigned tx_skb_freelist;
spinlock_t rx_lock ____cacheline_aligned_in_smp;
@@ -396,6 +397,7 @@ static void xennet_tx_buf_gc(struct net_device *dev)
gnttab_release_grant_reference(
&np->gref_tx_head, np->grant_tx_ref[id]);
np->grant_tx_ref[id] = GRANT_INVALID_REF;
+ np->grant_tx_page[id] = NULL;
add_id_to_freelist(&np->tx_skb_freelist, np->tx_skbs, id);
dev_kfree_skb_irq(skb);
}
@@ -452,6 +454,7 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
gnttab_grant_foreign_access_ref(ref, np->xbdev->otherend_id,
mfn, GNTMAP_readonly);
+ np->grant_tx_page[id] = virt_to_page(data);
tx->gref = np->grant_tx_ref[id] = ref;
tx->offset = offset;
tx->size = len;
@@ -497,6 +500,7 @@ static void xennet_make_frags(struct sk_buff *skb, struct net_device *dev,
np->xbdev->otherend_id,
mfn, GNTMAP_readonly);
+ np->grant_tx_page[id] = page;
tx->gref = np->grant_tx_ref[id] = ref;
tx->offset = offset;
tx->size = bytes;
@@ -596,6 +600,7 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev)
mfn = virt_to_mfn(data);
gnttab_grant_foreign_access_ref(
ref, np->xbdev->otherend_id, mfn, GNTMAP_readonly);
+ np->grant_tx_page[id] = virt_to_page(data);
tx->gref = np->grant_tx_ref[id] = ref;
tx->offset = offset;
tx->size = len;
@@ -1085,10 +1090,11 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
continue;
skb = np->tx_skbs[i].skb;
- gnttab_end_foreign_access_ref(np->grant_tx_ref[i],
- GNTMAP_readonly);
- gnttab_release_grant_reference(&np->gref_tx_head,
- np->grant_tx_ref[i]);
+ get_page(np->grant_tx_page[i]);
+ gnttab_end_foreign_access(np->grant_tx_ref[i],
+ GNTMAP_readonly,
+ (unsigned long)page_address(np->grant_tx_page[i]));
+ np->grant_tx_page[i] = NULL;
np->grant_tx_ref[i] = GRANT_INVALID_REF;
add_id_to_freelist(&np->tx_skb_freelist, np->tx_skbs, i);
dev_kfree_skb_irq(skb);
@@ -1097,78 +1103,35 @@ static void xennet_release_tx_bufs(struct netfront_info *np)
static void xennet_release_rx_bufs(struct netfront_info *np)
{
- struct mmu_update *mmu = np->rx_mmu;
- struct multicall_entry *mcl = np->rx_mcl;
- struct sk_buff_head free_list;
- struct sk_buff *skb;
- unsigned long mfn;
- int xfer = 0, noxfer = 0, unused = 0;
int id, ref;
- dev_warn(&np->netdev->dev, "%s: fix me for copying receiver.\n",
- __func__);
- return;
-
- skb_queue_head_init(&free_list);
-
spin_lock_bh(&np->rx_lock);
for (id = 0; id < NET_RX_RING_SIZE; id++) {
- ref = np->grant_rx_ref[id];
- if (ref == GRANT_INVALID_REF) {
- unused++;
- continue;
- }
+ struct sk_buff *skb;
+ struct page *page;
skb = np->rx_skbs[id];
- mfn = gnttab_end_foreign_transfer_ref(ref);
- gnttab_release_grant_reference(&np->gref_rx_head, ref);
- np->grant_rx_ref[id] = GRANT_INVALID_REF;
-
- if (0 == mfn) {
- skb_shinfo(skb)->nr_frags = 0;
- dev_kfree_skb(skb);
- noxfer++;
+ if (!skb)
continue;
- }
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- /* Remap the page. */
- const struct page *page =
- skb_frag_page(&skb_shinfo(skb)->frags[0]);
- unsigned long pfn = page_to_pfn(page);
- void *vaddr = page_address(page);
+ ref = np->grant_rx_ref[id];
+ if (ref == GRANT_INVALID_REF)
+ continue;
- MULTI_update_va_mapping(mcl, (unsigned long)vaddr,
- mfn_pte(mfn, PAGE_KERNEL),
- 0);
- mcl++;
- mmu->ptr = ((u64)mfn << PAGE_SHIFT)
- | MMU_MACHPHYS_UPDATE;
- mmu->val = pfn;
- mmu++;
+ page = skb_frag_page(&skb_shinfo(skb)->frags[0]);
- set_phys_to_machine(pfn, mfn);
- }
- __skb_queue_tail(&free_list, skb);
- xfer++;
- }
-
- dev_info(&np->netdev->dev, "%s: %d xfer, %d noxfer, %d unused\n",
- __func__, xfer, noxfer, unused);
+ /* gnttab_end_foreign_access() needs a page ref until
+ * foreign access is ended (which may be deferred).
+ */
+ get_page(page);
+ gnttab_end_foreign_access(ref, 0,
+ (unsigned long)page_address(page));
+ np->grant_rx_ref[id] = GRANT_INVALID_REF;
- if (xfer) {
- if (!xen_feature(XENFEAT_auto_translated_physmap)) {
- /* Do all the remapping work and M2P updates. */
- MULTI_mmu_update(mcl, np->rx_mmu, mmu - np->rx_mmu,
- NULL, DOMID_SELF);
- mcl++;
- HYPERVISOR_multicall(np->rx_mcl, mcl - np->rx_mcl);
- }
+ kfree_skb(skb);
}
- __skb_queue_purge(&free_list);
-
spin_unlock_bh(&np->rx_lock);
}
@@ -1339,6 +1302,7 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
for (i = 0; i < NET_RX_RING_SIZE; i++) {
np->rx_skbs[i] = NULL;
np->grant_rx_ref[i] = GRANT_INVALID_REF;
+ np->grant_tx_page[i] = NULL;
}
/* A grant for every tx ring slot */
--
1.7.3.4
^ permalink raw reply related
* Re: [Xen-devel] [PATCH net-next v5] xen-netfront: clean up code in xennet_release_rx_bufs
From: annie li @ 2014-01-28 3:29 UTC (permalink / raw)
To: David Miller; +Cc: david.vrabel, wei.liu2, ian.campbell, netdev, xen-devel
In-Reply-To: <20140127.130921.7056971883805642.davem@davemloft.net>
On 2014/1/28 5:09, David Miller wrote:
> From: David Vrabel <david.vrabel@citrix.com>
> Date: Mon, 27 Jan 2014 10:22:58 +0000
>
>> I think this should be applied to net (and tagged as a stable candidate)
>> rather than net-next as this fixes are very big resource leak.
> Then this subject line and commit message must be fixed to make it clear
> that this is a BUG fix, rather then just a "clean up".
>
I will post a new patch with correct subject and commit message.
Thanks
Annie
^ permalink raw reply
* Re: [PATCH RFC 00/73] tree-wide: clean up some no longer required #include <linux/init.h>
From: Benjamin Herrenschmidt @ 2014-01-28 3:13 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Stephen Rothwell, linux-arch, linux-mips, linux-m68k, rusty,
linux-ia64, kvm, linux-s390, netdev, x86, linux-kernel, torvalds,
gregkh, linux-alpha, sparclinux, akpm, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20140123003838.GA10182@windriver.com>
On Wed, 2014-01-22 at 19:38 -0500, Paul Gortmaker wrote:
> Thanks, it was a great help as it uncovered a few issues in fringe arch
> that I didn't have toolchains for, and I've fixed all of those up.
>
> I've noticed that powerpc has been un-buildable for a while now; I have
> used this hack patch locally so I could run the ppc defconfigs to check
> that I didn't break anything. Maybe useful for linux-next in the
> interim? It is a hack patch -- Not-Signed-off-by: Paul Gortmaker. :)
Can you and/or Aneesh submit that as a proper patch (with S-O-B
etc...) ?
Thanks !
Cheers,
Ben.
> Paul.
> --
>
> diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
> index d27960c89a71..d0f070a2b395 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> @@ -560,9 +560,9 @@ extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
> pmd_t *pmdp);
>
> #define pmd_move_must_withdraw pmd_move_must_withdraw
> -typedef struct spinlock spinlock_t;
> -static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
> - spinlock_t *old_pmd_ptl)
> +struct spinlock;
> +static inline int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl,
> + struct spinlock *old_pmd_ptl)
> {
> /*
> * Archs like ppc64 use pgtable to store per pmd
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] AF_PACKET: Add documentation for queue mapping fanout mode
From: Neil Horman @ 2014-01-28 2:15 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev, David S. Miller, Daniel Borkmann
In-Reply-To: <87d2jdqepa.fsf@tassilo.jf.intel.com>
On Mon, Jan 27, 2014 at 01:48:01PM -0800, Andi Kleen wrote:
> Neil Horman <nhorman@tuxdriver.com> writes:
>
> > Recently I added a new AF_PACKET fanout operation mode in commit
> > 2d36097, but I forgot to document it. Add PACKET_FANOUT_QM as an available mode
> > in the af_packet documentation. Applies to net-next.
>
> Please also send a man page patch.
>
> -Andi
>
I'll take care of it in the am. Thanks for the reminder!
Neil
> --
> ak@linux.intel.com -- Speaking for myself only
>
^ permalink raw reply
* Hi
From: a8kef58kbi @ 2014-01-28 1:25 UTC (permalink / raw)
To: a8kef58kbi
Diploma?
http://tiny.cc/2ww2cz4evf
^ permalink raw reply
* Re: Freescale FEC packet loss
From: Marek Vasut @ 2014-01-28 1:01 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev@vger.kernel.org, Frank Li, fugang.duan,
fabio.estevam@freescale.com, Hector Palacios, linux-arm-kernel,
Detlev Zundel, Eric Nelson, Matthew Garrett
In-Reply-To: <1390772013.2735.47.camel@deadeye.wl.decadent.org.uk>
On Sunday, January 26, 2014 at 10:33:33 PM, Ben Hutchings wrote:
> On Sun, 2014-01-26 at 20:12 +0100, Marek Vasut wrote:
> > On Sunday, January 26, 2014 at 07:56:30 PM, Ben Hutchings wrote:
> > > On Wed, 2014-01-22 at 22:55 +0100, Marek Vasut wrote:
> > > > Hi guys,
> > > >
> > > > I am running stock Linux 3.13 on i.MX6Q SabreLite board. The CPU is
> > > > i.MX6Q TO 1.0 .
> > > >
> > > > I am hitting a WARNING when I use the FEC ethernet to transfer data,
> > > > thus I started investigating this problem. TL;DR I am not able to
> > > > figure this problem out, so I am not attaching a patch :-(
> > > >
> > > > Steps to reproduce:
> > > > -------------------
> > > > 1) Boot stock Linux 3.13 on i.MX6Q SabreLite board
> > > > 2) Plug in an SD card into one of the SD slots (I use the full-size
> > > > one) 3) Plug in an USB stick into one of the USB ports (I use the
> > > > upper one) 4) Plug in an ethernet cable into the board
> > > >
> > > > -> Connect the other side into a gigabit-capable PC
> > >
> > > [...]
> > >
> > > I think there are known problems with 1000BASE-T on the Sabre Lite
> > > board.
> >
> > This is MX6-wide thing, not sabrelite specific actually.
> >
> > > Two possible workarounds are to limit the PHY to 100BASE-TX
> > > (should be doable with ethtool) or force it to be clock master for
> > > 1000BASE-T (requires a driver patch).
> >
> > Can you please elaborate on the later ? I don't quite understand that.
>
> 1000BASE-T uses all 4 pairs in both directions at the same time, which
> requires that both ends transmit symbols synchronously. As part of the
> autonegotiation protocol, they decide which is the clock master (using a
> local clock generator) and which is the clock slave (generating a clock
> from the received signal). A PHY can be configured to support only one
> of these roles.
I checked the patch you pointed me to. The patch basically messes with the
CTL1000 (0x9) register of the PHY, right ? I did the adjustments to the PHY
register manually , but the result is still the same (backtrace).
I did two different kinds of adjustment:
1) reg 0x9 |= 0x1800;
2) reg 0x9 |= 0x1000;
In both cases, the crash did happen. I verified the PHY register was configured
as necessary. The KSZ9021 PHY bit 12 configures the master/slave override, same
as the patch does. The bit 11 forces either master or slave mode for the PHY. In
both cases the crash was there.
I think this patch won't help in this case, sorry.
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH V2 0/4] misc: xgene: Add support for APM X-Gene SoC Queue Manager/Traffic Manager
From: Ravi Patel @ 2014-01-28 0:58 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg KH, Loc Ho, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Jon Masters, patches-qTEPVZfXA3Y@public.gmane.org, Keyur Chudgar
In-Reply-To: <201401141615.55820.arnd-r2nGTMty4D4@public.gmane.org>
On Tue, Jan 14, 2014 at 7:15 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> Now that I have a better understanding of what the driver is good for and
> how it's used, let's have a look at how we can make it fit into the Linux
> driver APIs and the DT bindings. We don't have anything exactly like this
> yet, but I think the "mailbox" framework is a close enough match that we
> can fit it in there, with some extensions. This framework is still in the
> process of being created (so far there is only a TI OMAP specific driver,
> and one for pl320), and I've not seen any mailboxes that support IRQ
> mitigation or multiple software interfaces per hardware mailbox, but those
> should be easy enough to add.
OK. We will put Queue Manager driver under drivers/mailbox directory along
with TI OMAP and pl320 drivers.
> For the DT binding, I would suggest using something along the lines of
> what we have for clocks, pinctrl and dmaengine. OMAP doesn't use this
> (yet), but now would be a good time to standardize it. The QMTM node
> should define a "#mailbox-cells" property that indicates how many
> 32-bit cells a qmtm needs to describe the connection between the
> controller and the slave. My best guess is that this would be hardcoded
> to <3>, using two cells for a 64-bit FIFO bus address, and a 32-bit cell
> for the slave-id signal number. All other parameters that you have in
> the big table in the qmtm driver at the moment can then get moved into
> the slave drivers, as they are constant per type of slave. This will
> simplify the QMTM driver.
>
> In the slave, you should have a "mailboxes" property with a phandle
> to the qmtm followed by the three cells to identify the actual
> queue. If it's possible that a device uses more than one rx and
> one tx queue, we also need a "mailbox-names" property to identify
> the individual queues.
We explored on DT bindings suggestion given by you. We have come
up with a sample DT binding for how it will look like. Herewith we have
provided the same. Would you please review and give us your
comments before we change our driver and DTS file to accomodate it?
Sample DTS node for QM:
qmlite: qmtm@17030000 {
compatible = "apm,xgene-qmtm-lite";
reg = <0x0 0x17030000 0x0 0x10000>,
<0x0 0x10000000 0x0 0x400000>;
interrupts = <0x0 0x40 0x4>,
<0x0 0x3c 0x4>;
status = "ok";
#clock-cells = <1>;
clocks = <&qmlclk 0>;
#mailbox-cells = <3>;
};
Sample DTS node for Ethernet:
menet: ethernet@17020000 {
compatible = "apm,xgene-enet";
status = "disabled";
reg = <0x0 0x17020000 0x0 0x30>,
<0x0 0x17020000 0x0 0x10000>,
<0x0 0x17020000 0x0 0x20>;
mailboxes = <&qmlite 0x0 0x1000002c 0x0000>,
<&qmlite 0x0 0x10000052 0x0020>,
<&qmlite 0x0 0x10000060 0x0f00>
mailbox-names = "mb-tx", "mb-fp", "mb-rx";
interrupts = <0x0 0x38 0x4>,
<0x0 0x39 0x4>,
<0x0 0x3a 0x4>;
#clock-cells = <1>;
clocks = <ð8clk 0>;
local-mac-address = <0x0 0x11 0x3a 0x8a 0x5a 0x78>;
max-frame-size = <0x233a>;
phyid = <3>;
phy-mode = "rgmii";
};
The mailbox node in DTS has following format:
mailbox = <&parent 'higher 32 bit bus address' 'lower 32 bit bus
address' 'signal id'>
Ethernet driver will call following function in platform_probe:
mailbox_get(dev, "mb-tx");
mailbox_get API will return the the context of allocated and configured mailbox.
For now, mailbox_get API will be implemented in xgene QMTM driver.
Eventually when mailbox framework in Linux will be standardized, we
will use it instead.
> For the in-kernel interfaces, we should probably start a conversation
> with the owners of the mailbox drivers to get a common API, for now
> I'd suggest you just leave it as it is, and only adapt for the new
> binding.
Sure. For now we will put our driver mostly as is in the
drivers/mailbox. Can you please help us identify the owners of the
mailbox drivers? As you suggested, we can start conversation with them
to define common in kernel APIs.
Ravi
On Tue, Jan 14, 2014 at 7:15 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Monday 13 January 2014, Ravi Patel wrote:
>> > Examples for local resource management (I had to think about this
>> > a long time, but probably some of these are wrong) would be
>> > * balancing between multiple non-busmaster devices connected to
>> > a dma-engine
>> > * distributing incoming ethernet data to the available CPUs based on
>> > a flow classifier in the MAC, e.g. by IOV MAC address, VLAN tag
>> > or even individual TCP connection depending on the NIC's capabilities.
>> > * 802.1p flow control for incoming ethernet data based on the amount
>> > of data queued up between the MAC and the driver
>> > * interrupt mitigation for both inbound data and outbound completion,
>> > by delaying the IRQ to the OS until multiple messages have arrived
>> > or a queue specific amount of time has passed.
>> > * controlling the amount of outbound buffer space per flow to minimize
>> > buffer-bloat between an ethernet driver and the NIC hardware.
>> > * reordering data from outbound flows based on priority.
>> >
>> > This is basically my current interpretation, I hope I got at least
>> > some of it right this time ;-)
>>
>> You have got them right. Although we have taken Ethernet examples here,
>> most of the local resource management apply to other slave devices also.
>
> I'm very suprised I got all those right, it seems it's a quite sophisticated
> piece of hardware then. I guess most other slave devices only use a subset
> of the capabilities that ethernet wants.
>
> Now that I have a better understanding of what the driver is good for and
> how it's used, let's have a look at how we can make it fit into the Linux
> driver APIs and the DT bindings. We don't have anything exactly like this
> yet, but I think the "mailbox" framework is a close enough match that we
> can fit it in there, with some extensions. This framework is still in the
> process of being created (so far there is only a TI OMAP specific driver,
> and one for pl320), and I've not seen any mailboxes that support IRQ
> mitigation or multiple software interfaces per hardware mailbox, but those
> should be easy enough to add.
>
> For the DT binding, I would suggest using something along the lines of
> what we have for clocks, pinctrl and dmaengine. OMAP doesn't use this
> (yet), but now would be a good time to standardize it. The QMTM node
> should define a "#mailbox-cells" property that indicates how many
> 32-bit cells a qmtm needs to describe the connection between the
> controller and the slave. My best guess is that this would be hardcoded
> to <3>, using two cells for a 64-bit FIFO bus address, and a 32-bit cell
> for the slave-id signal number. All other parameters that you have in
> the big table in the qmtm driver at the moment can then get moved into
> the slave drivers, as they are constant per type of slave. This will
> simplify the QMTM driver.
>
> In the slave, you should have a "mailboxes" property with a phandle
> to the qmtm followed by the three cells to identify the actual
> queue. If it's possible that a device uses more than one rx and
> one tx queue, we also need a "mailbox-names" property to identify
> the individual queues.
>
> For the in-kernel interfaces, we should probably start a conversation
> with the owners of the mailbox drivers to get a common API, for now
> I'd suggest you just leave it as it is, and only adapt for the new
> binding.
>
> Arnd
--
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: linux-next: manual merge of the bluetooth tree with the net/net-next trees
From: David Miller @ 2014-01-28 0:43 UTC (permalink / raw)
To: sfr; +Cc: gustavo, netdev, linux-next, linux-kernel, dborkman,
jukka.rissanen
In-Reply-To: <20140128095415.8382335c33545ad14d4be067@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 28 Jan 2014 09:54:15 +1100
> On Tue, 7 Jan 2014 12:54:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
...
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Tue, 7 Jan 2014 12:52:43 +1100
>> Subject: [PATCH] net: 6lowpan: fixup for code movement
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
...
> I think this fix patch got missed when bluetooth was merged ... so it
> should probably go into the net tree.
Good catch, applied, thanks Stephen!
^ permalink raw reply
* Re: [PATCH net-next] hyperv: Add support for physically discontinuous receive buffer
From: David Miller @ 2014-01-28 0:41 UTC (permalink / raw)
To: haiyangz; +Cc: olaf, netdev, jasowang, driverdev-devel, linux-kernel
In-Reply-To: <1390863822-3509-1-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Mon, 27 Jan 2014 15:03:42 -0800
> This will allow us to use bigger receive buffer, and prevent allocation failure
> due to fragmented memory.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] sky2: initialize napi before registering device
From: David Miller @ 2014-01-28 0:40 UTC (permalink / raw)
To: stf_xl; +Cc: netdev, mlindner, stephen
In-Reply-To: <20140125103454.GA2490@localhost.localdomain>
From: Stanislaw Gruszka <stf_xl@wp.pl>
Date: Sat, 25 Jan 2014 11:34:54 +0100
> There is race condition when call netif_napi_add() after
> register_netdevice(), as ->open() can be called without napi initialized
> and trigger BUG_ON() on napi_enable(), like on below messages:
...
> To fix the problem patch changes the order of initialization.
>
> Bug report:
> https://bugzilla.kernel.org/show_bug.cgi?id=67151
>
> Reported-and-tested-by: ebrahim.azarisooreh@gmail.com
> Signed-off-by: Stanislaw Gruszka <stf_xl@wp.pl>
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH RFC v3 0/12] vti4: prepare namespace and interfamily support.
From: David Miller @ 2014-01-28 0:35 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev, christophe.gouault, saurabh.mohan
In-Reply-To: <1390818577-19589-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Mon, 27 Jan 2014 11:29:25 +0100
> This patchset prepares vti4 for proper namespace and interfamily
> support.
No major objections from me, this looks good.
^ permalink raw reply
* Re: [PATCH 2/2] net: ip, ipv6: handle gso skbs in forwarding path
From: Hannes Frederic Sowa @ 2014-01-28 0:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Florian Westphal, netdev
In-Reply-To: <1390846967.27806.75.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Jan 27, 2014 at 10:22:47AM -0800, Eric Dumazet wrote:
> On Mon, 2014-01-27 at 09:22 +0100, Florian Westphal wrote:
>
> > +/* called if GSO skb needs to be fragmented on forward. */
> > +static int ip_forward_finish_gso(struct sk_buff *skb)
> > +{
> > + netdev_features_t features = netif_skb_features(skb);
netif_skb_features uses skb->dev for determination of offloading features but
we actually need rt->dst.dev, no?
> > + struct sk_buff *segs;
> > + int ret = 0;
> > +
> > + segs = skb_gso_segment(skb, features & ~NETIF_F_GSO_MASK);
> > + if (IS_ERR(segs)) {
> > + kfree_skb(skb);
> > + return -ENOMEM;
> > + }
> > +
> > + consume_skb(skb);
> > +
> > + do {
> > + struct sk_buff *nskb = segs->next;
> > + int err;
> > +
> > + segs->next = NULL;
> > + err = dst_output(segs);
> > +
> > + if (err && ret == 0)
> > + ret = err;
> > + segs = nskb;
> > + } while (segs);
> > +
> > + return ret;
> > +}
> > +
>
> Its still unclear if this is the best strategy.
>
> TCP stream not using DF flag are very unlikely to care if we adjust
> their MTU (lowering gso_size) at this point ?
UDP shouldn't be a problem, too.
Greetings,
Hannes
^ permalink raw reply
* Re: [BUG PATCH] Memory leak on tcp_prot slab with TPROXY and TCP early demux
From: David Miller @ 2014-01-28 0:23 UTC (permalink / raw)
To: holger; +Cc: netdev, netfilter-devel, fw
In-Reply-To: <20140127093317.GU7176@imap.eitzenberger.org>
From: Holger Eitzenberger <holger@eitzenberger.org>
Date: Mon, 27 Jan 2014 10:33:18 +0100
> Please have a look, there could be smarter ways of fixing that.
Looks good, applied and queued up for -stable.
Thanks!
^ permalink raw reply
* Re: [PATCH 2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
From: Sergei Shtylyov @ 2014-01-27 23:59 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
In-Reply-To: <201401280249.40451.sergei.shtylyov@cogentembedded.com>
Hello.
On 01/28/2014 02:49 AM, Sergei Shtylyov wrote:
> The "ti,davinci-no-bd-ram" property for the DaVinci EMAC binding simply can't be
> required one, as it's boolean (which means it's absent if false).
> While at it, document the property better...
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
> Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
> ===================================================================
> --- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
> +++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
> @@ -10,7 +10,6 @@ Required properties:
> - ti,davinci-ctrl-mod-reg-offset: offset to control module register
> - ti,davinci-ctrl-ram-offset: offset to control module ram
> - ti,davinci-ctrl-ram-size: size of control module ram
> -- ti,davinci-no-bd-ram: has the emac controller BD RAM
> - interrupts: interrupt mapping for the davinci emac interrupts sources:
> 4 sources: <Receive Threshold Interrupt
> Receive Interrupt
> @@ -22,6 +21,7 @@ Optional properties:
> If absent, davinci_emac driver defaults to 100/FULL.
> - local-mac-address : 6 bytes, mac address
> - ti,davinci-rmii-en: 1 byte, 1 means use RMII
> +- ti,davinci-no-bd-ram: boolean, does EMAC has BD RAM?
Too hasty, s/has/have/. Do I need to resend or this could be fixed when
applying?
WBR, Sergei
^ permalink raw reply
* [PATCH 2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
From: Sergei Shtylyov @ 2014-01-27 23:49 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
The "ti,davinci-no-bd-ram" property for the DaVinci EMAC binding simply can't be
required one, as it's boolean (which means it's absent if false).
While at it, document the property better...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
===================================================================
--- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -10,7 +10,6 @@ Required properties:
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
- ti,davinci-ctrl-ram-offset: offset to control module ram
- ti,davinci-ctrl-ram-size: size of control module ram
-- ti,davinci-no-bd-ram: has the emac controller BD RAM
- interrupts: interrupt mapping for the davinci emac interrupts sources:
4 sources: <Receive Threshold Interrupt
Receive Interrupt
@@ -22,6 +21,7 @@ Optional properties:
If absent, davinci_emac driver defaults to 100/FULL.
- local-mac-address : 6 bytes, mac address
- ti,davinci-rmii-en: 1 byte, 1 means use RMII
+- ti,davinci-no-bd-ram: boolean, does EMAC has BD RAM?
Example (enbw_cmc board):
eth0: emac@1e20000 {
^ permalink raw reply
* [PATCH 1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
From: Sergei Shtylyov @ 2014-01-27 23:47 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
Though described as required, the "ti,davinci-rmii-en" property for the DaVinci
EMAC binding seems actually optional, as the driver should happily work without
it; the property is not specified either in the example device node or in the
actual EMAC device node for DA850 device tree, only AM3517 one.
While at it, document the property better...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Actually I think this property should have been boolean...
Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
===================================================================
--- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -10,7 +10,6 @@ Required properties:
- ti,davinci-ctrl-mod-reg-offset: offset to control module register
- ti,davinci-ctrl-ram-offset: offset to control module ram
- ti,davinci-ctrl-ram-size: size of control module ram
-- ti,davinci-rmii-en: use RMII
- ti,davinci-no-bd-ram: has the emac controller BD RAM
- interrupts: interrupt mapping for the davinci emac interrupts sources:
4 sources: <Receive Threshold Interrupt
@@ -22,6 +21,7 @@ Optional properties:
- phy-handle: Contains a phandle to an Ethernet PHY.
If absent, davinci_emac driver defaults to 100/FULL.
- local-mac-address : 6 bytes, mac address
+- ti,davinci-rmii-en: 1 byte, 1 means use RMII
Example (enbw_cmc board):
eth0: emac@1e20000 {
^ permalink raw reply
* [PATCH 0/2] DT: net: davinci_emac: couple more properties actually optional
From: Sergei Shtylyov @ 2014-01-27 23:45 UTC (permalink / raw)
To: netdev, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
rob, devicetree
Cc: linux-doc, davinci-linux-open-source
Hello.
Though described as required, couple more properties in the DaVinci EMAC
binding are actually optional, as the driver will happily function without them.
The patchset is against DaveM's 'net.git' tree this time.
[1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
[2/2] DT: net: davinci_emac: "ti,davinci-no-bd-ram" property is actually optional
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 3/3] net: via-rhine: add OF bus binding
From: Ben Hutchings @ 2014-01-27 23:40 UTC (permalink / raw)
To: Alexey Charkov
Cc: netdev, Tony Prisk, devicetree, Roger Luethi,
linux-kernel@vger.kernel.org
In-Reply-To: <CABjd4Yz2Kfed_qBfSAEXoAcVxfsmhTBA-83YJ9_iSwPZ+r1qYQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
On Mon, 2014-01-27 at 19:34 +0400, Alexey Charkov wrote:
> 2014/1/27 Ben Hutchings <ben@decadent.org.uk>:
> > On Mon, 2014-01-27 at 15:51 +0400, Alexey Charkov wrote:
> >> This should make the driver usable with VIA/WonderMedia ARM-based
> >> Systems-on-Chip integrated Rhine III adapters. Note that these
> >> are always in MMIO mode, and don't have any known EEPROM.
> > [...]
> >> --- a/drivers/net/ethernet/via/Kconfig
> >> +++ b/drivers/net/ethernet/via/Kconfig
> >> @@ -19,7 +19,7 @@ if NET_VENDOR_VIA
> >>
> >> config VIA_RHINE
> >> tristate "VIA Rhine support"
> >> - depends on PCI
> >> + depends on (PCI || USE_OF)
> >> select CRC32
> >> select MII
> >> ---help---
> >
> > This seems like the right thing to do, but it means you need to add
> > #ifdef CONFIG_PCI and #ifdef CONFIG_USE_OF around the driver structures
> > and related functions.
>
> Frankly, I would like to avoid that if possible (as pointed out in the
> cover email), as I believe we would get a cleaner driver without
> #ifdef. This is also the way it was done in via-velocity, and it works
> just fine.
OK, I'm surprised that all the PCI functions have dummy definitions.
> > You should compile-test in configurations that have just one of those
> > dependencies enabled.
>
> This has been compile-tested and runtime-tested in OF-only
> configuration on WM8950, and Roger also tested it in PCI-only
> configuration, so it seems to work fine.
[...]
Good, then I have no objection.
Ben.
--
Ben Hutchings
If at first you don't succeed, you're doing about average.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Many USB ethernet devices are broken over xhci
From: Greg KH @ 2014-01-27 23:33 UTC (permalink / raw)
To: David Laight
Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org, Sarah Sharp
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D46624F@AcuExch.aculab.com>
On Mon, Jan 27, 2014 at 04:06:22PM +0000, David Laight wrote:
> Many of the net/usb ethernet drivers (including common ones like
> the smsc95xx) will fail to transmit all packet length properly
> when connected to a USB3 port (ie using the xhci driver).
That's odd, as I've never had a problem with my USB 3.0 ethernet device
(sorry, don't remember what driver it uses), and I stress it all the
time.
I've also run two different USB 2 ethernet devices on xhci with no
issues at all, so perhaps the "many" statement might not be true?
> The underlying problem is that they assume the host controller
> will honour the URB_ZERO_PACKET flag - which usbnet sets because
> they specify FLAG_SEND_ZLP.
>
> However no one has ever added support for URB_ZERO_PACKET to
> the xhci driver - so packets that need padding (probably 512
> bytes after any header is added) will not be sent correctly
> and may have very adverse effects on the usb target.
Really? How has things been working so well up to now without this
support? Doesn't the hardware automatically add this padding with no
explicit need for the xhci driver to do something?
> The ax179_178a driver avoids this by not setting FLAG_SEND_ZLP,
> modifying the packet header, and appending an extra zero byte.
> (Which has been responsible for its own set of panics.)
>
> I don't think this can be fixed by just clearing (or ignoring)
> FLAG_SEND_ZLP as the extra byte will also confuse things.
>
> It needs to be fixed in the xhci code.
>
> I wrote this patch a while ago - worked for me with the ax179_178a
> driver. http://www.spinics.net/lists/linux-usb/msg97370.html
Doing multiple things in a patch is generally considered bad-form, and
this is quite hard to follow.
> The patch is a bit difficult to read, the v1 version contained a copy of
> the new function. http://www.spinics.net/lists/linux-usb/msg97183.html
That's not helpful to the people having to review the v2 patch :)
> I don't think anything significant has changed (in the main kernel
> sources) since I wrote the patch.
Then resubmit it, don't post links to it on the web, there's nothing we
can do with them, sorry.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next 0/7] qlcnic: Refactoring and enhancements for all adapters.
From: David Miller @ 2014-01-27 23:24 UTC (permalink / raw)
To: zoltan.kiss; +Cc: himanshu.madhani, netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <52E6D7E1.90204@citrix.com>
From: Zoltan Kiss <zoltan.kiss@citrix.com>
Date: Mon, 27 Jan 2014 22:04:17 +0000
> On 24/01/14 00:14, David Miller wrote:
>> From: Himanshu Madhani <himanshu.madhani@qlogic.com>
>> Date: Thu, 23 Jan 2014 17:18:27 -0500
>>
>>> This patch series contains following patches.
>>>
>>> o Enhanced debug data collection when we are in Tx-timeout situation.
>>> o Enhanced MSI-x vector calculation for defualt load path as well
>>> as for TSS/RSS ring change path.
>>> o Refactored interrupt coalescing code for all adapters.
>>> o Refactored interrupt handling as well as cleanup of poll controller
>>> code patch for all adapters.
>>> o changed rx_mac_learn type to boolean.
>>>
>>> Please apply to net-next.
>>
>> Series applied, thanks.
>
> Not that I reject fame, but the commit message contains my name as
> sign-off, while I've never seen a bit of that code :)
Sorry about that. What happens is that I build the merge commit
messages from a template, and I used a template for a previous
serious with your signoff by accident :-/
^ permalink raw reply
* Re: Many USB ethernet devices are broken over xhci
From: Sarah Sharp @ 2014-01-27 23:16 UTC (permalink / raw)
To: David Laight; +Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D46624F@AcuExch.aculab.com>
David, you are overwhelming my capacity to handle patches right now. I
appreciate that you would like to clean up the driver, but the bug fixes
you're sending me are getting lost in the noise of random cleanup
patches.
Can you please limit the xHCI patches you send to bug fixes for now?
Also, can you resend all the patches you consider to be serious bug
fixes in one single patchset?
Thanks,
Sarah Sharp
On Mon, Jan 27, 2014 at 04:06:22PM +0000, David Laight wrote:
> Many of the net/usb ethernet drivers (including common ones like
> the smsc95xx) will fail to transmit all packet length properly
> when connected to a USB3 port (ie using the xhci driver).
>
> The underlying problem is that they assume the host controller
> will honour the URB_ZERO_PACKET flag - which usbnet sets because
> they specify FLAG_SEND_ZLP.
>
> However no one has ever added support for URB_ZERO_PACKET to
> the xhci driver - so packets that need padding (probably 512
> bytes after any header is added) will not be sent correctly
> and may have very adverse effects on the usb target.
>
> The ax179_178a driver avoids this by not setting FLAG_SEND_ZLP,
> modifying the packet header, and appending an extra zero byte.
> (Which has been responsible for its own set of panics.)
>
> I don't think this can be fixed by just clearing (or ignoring)
> FLAG_SEND_ZLP as the extra byte will also confuse things.
>
> It needs to be fixed in the xhci code.
>
> I wrote this patch a while ago - worked for me with the ax179_178a
> driver. http://www.spinics.net/lists/linux-usb/msg97370.html
>
> The patch is a bit difficult to read, the v1 version contained a copy of
> the new function. http://www.spinics.net/lists/linux-usb/msg97183.html
>
> I don't think anything significant has changed (in the main kernel
> sources) since I wrote the patch.
>
> David
>
>
>
>
^ permalink raw reply
* [PATCH net-next] hyperv: Add support for physically discontinuous receive buffer
From: Haiyang Zhang @ 2014-01-27 23:03 UTC (permalink / raw)
To: davem, netdev; +Cc: olaf, jasowang, driverdev-devel, linux-kernel, haiyangz
This will allow us to use bigger receive buffer, and prevent allocation failure
due to fragmented memory.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
---
drivers/hv/channel.c | 14 ++++++++------
drivers/net/hyperv/hyperv_net.h | 2 +-
drivers/net/hyperv/netvsc.c | 7 ++-----
3 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index cea623c..69ea36f 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -209,7 +209,6 @@ static int create_gpadl_header(void *kbuffer, u32 size,
{
int i;
int pagecount;
- unsigned long long pfn;
struct vmbus_channel_gpadl_header *gpadl_header;
struct vmbus_channel_gpadl_body *gpadl_body;
struct vmbus_channel_msginfo *msgheader;
@@ -219,7 +218,6 @@ static int create_gpadl_header(void *kbuffer, u32 size,
int pfnsum, pfncount, pfnleft, pfncurr, pfnsize;
pagecount = size >> PAGE_SHIFT;
- pfn = virt_to_phys(kbuffer) >> PAGE_SHIFT;
/* do we need a gpadl body msg */
pfnsize = MAX_SIZE_CHANNEL_MESSAGE -
@@ -248,7 +246,8 @@ static int create_gpadl_header(void *kbuffer, u32 size,
gpadl_header->range[0].byte_offset = 0;
gpadl_header->range[0].byte_count = size;
for (i = 0; i < pfncount; i++)
- gpadl_header->range[0].pfn_array[i] = pfn+i;
+ gpadl_header->range[0].pfn_array[i] = slow_virt_to_phys(
+ kbuffer + PAGE_SIZE * i) >> PAGE_SHIFT;
*msginfo = msgheader;
*messagecount = 1;
@@ -301,7 +300,9 @@ static int create_gpadl_header(void *kbuffer, u32 size,
* so the hypervisor gurantees that this is ok.
*/
for (i = 0; i < pfncurr; i++)
- gpadl_body->pfn[i] = pfn + pfnsum + i;
+ gpadl_body->pfn[i] = slow_virt_to_phys(
+ kbuffer + PAGE_SIZE * (pfnsum + i)) >>
+ PAGE_SHIFT;
/* add to msg header */
list_add_tail(&msgbody->msglistentry,
@@ -327,7 +328,8 @@ static int create_gpadl_header(void *kbuffer, u32 size,
gpadl_header->range[0].byte_offset = 0;
gpadl_header->range[0].byte_count = size;
for (i = 0; i < pagecount; i++)
- gpadl_header->range[0].pfn_array[i] = pfn+i;
+ gpadl_header->range[0].pfn_array[i] = slow_virt_to_phys(
+ kbuffer + PAGE_SIZE * i) >> PAGE_SHIFT;
*msginfo = msgheader;
*messagecount = 1;
@@ -344,7 +346,7 @@ nomem:
* vmbus_establish_gpadl - Estabish a GPADL for the specified buffer
*
* @channel: a channel
- * @kbuffer: from kmalloc
+ * @kbuffer: from kmalloc or vmalloc
* @size: page-size multiple
* @gpadl_handle: some funky thing
*/
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index a26eecb..7b594ce 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -462,7 +462,7 @@ struct nvsp_message {
#define NETVSC_MTU 65536
-#define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*2) /* 2MB */
+#define NETVSC_RECEIVE_BUFFER_SIZE (1024*1024*16) /* 16MB */
#define NETVSC_RECEIVE_BUFFER_ID 0xcafe
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 93b485b..03a2c6e 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -136,8 +136,7 @@ static int netvsc_destroy_recv_buf(struct netvsc_device *net_device)
if (net_device->recv_buf) {
/* Free up the receive buffer */
- free_pages((unsigned long)net_device->recv_buf,
- get_order(net_device->recv_buf_size));
+ vfree(net_device->recv_buf);
net_device->recv_buf = NULL;
}
@@ -163,9 +162,7 @@ static int netvsc_init_recv_buf(struct hv_device *device)
return -ENODEV;
ndev = net_device->ndev;
- net_device->recv_buf =
- (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
- get_order(net_device->recv_buf_size));
+ net_device->recv_buf = vzalloc(net_device->recv_buf_size);
if (!net_device->recv_buf) {
netdev_err(ndev, "unable to allocate receive "
"buffer of size %d\n", net_device->recv_buf_size);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually optional
From: Florian Fainelli @ 2014-01-27 22:57 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Rob Landley, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, davinci-linux-open-source
In-Reply-To: <201401280247.42415.sergei.shtylyov@cogentembedded.com>
2014-01-27 Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>:
> Though described as required, the "ti,davinci-rmii-en" property for the DaVinci
> EMAC binding seems actually optional, as the driver should happily work without
> it; the property is not specified either in the example device node or in the
> actual EMAC device node for DA850 device tree, only AM3517 one.
>
> While at it, document the property better...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> Actually I think this property should have been boolean...
>
> Documentation/devicetree/bindings/net/davinci_emac.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: net/Documentation/devicetree/bindings/net/davinci_emac.txt
> ===================================================================
> --- net.orig/Documentation/devicetree/bindings/net/davinci_emac.txt
> +++ net/Documentation/devicetree/bindings/net/davinci_emac.txt
> @@ -10,7 +10,6 @@ Required properties:
> - ti,davinci-ctrl-mod-reg-offset: offset to control module register
> - ti,davinci-ctrl-ram-offset: offset to control module ram
> - ti,davinci-ctrl-ram-size: size of control module ram
> -- ti,davinci-rmii-en: use RMII
> - ti,davinci-no-bd-ram: has the emac controller BD RAM
> - interrupts: interrupt mapping for the davinci emac interrupts sources:
> 4 sources: <Receive Threshold Interrupt
> @@ -22,6 +21,7 @@ Optional properties:
> - phy-handle: Contains a phandle to an Ethernet PHY.
> If absent, davinci_emac driver defaults to 100/FULL.
> - local-mac-address : 6 bytes, mac address
> +- ti,davinci-rmii-en: 1 byte, 1 means use RMII
This just made me look at the actual DT binding documentation and the
driver, but there is support for specifying a PHY device tree node,
but no corresponding 'phy-connection-type' property which would tell
whether the connection is Reduced MII, MII or something else.
'phy-connection-type' would convey much more information about what is
happening, and once know, should also make the driver automatically
configure for Reduced MII or anything else, hence making
"ti,davinc-rmii-en" obsolete.
--
Florian
^ permalink raw reply
* Re: linux-next: manual merge of the bluetooth tree with the net/net-next trees
From: Stephen Rothwell @ 2014-01-27 22:54 UTC (permalink / raw)
To: Gustavo Padovan, David Miller, netdev
Cc: linux-next, linux-kernel, Daniel Borkmann, Jukka Rissanen
In-Reply-To: <20140107125418.986ae20298ddc55e5e657447@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
Hi all,
On Tue, 7 Jan 2014 12:54:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bluetooth tree got a conflict in
> net/ieee802154/6lowpan.c between commit 965801e1eb62 ("net: 6lowpan: fix
> lowpan_header_create non-compression memcpy call") from the tree and
> commit 8df8c56a5abc ("6lowpan: Moving generic compression code into
> 6lowpan_iphc.c") from the bluetooth tree.
>
> I fixed it up (I applied the following patch to move the fix into
> 6lowpan_iphc.c) and can carry the fix as necessary (no action is
> required).
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 7 Jan 2014 12:52:43 +1100
> Subject: [PATCH] net: 6lowpan: fixup for code movement
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> net/ieee802154/6lowpan_iphc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ieee802154/6lowpan_iphc.c b/net/ieee802154/6lowpan_iphc.c
> index 11840f9e46da..e14fe8b2c054 100644
> --- a/net/ieee802154/6lowpan_iphc.c
> +++ b/net/ieee802154/6lowpan_iphc.c
> @@ -677,7 +677,7 @@ int lowpan_header_compress(struct sk_buff *skb, struct net_device *dev,
> hc06_ptr += 3;
> } else {
> /* compress nothing */
> - memcpy(hc06_ptr, &hdr, 4);
> + memcpy(hc06_ptr, hdr, 4);
> /* replace the top byte with new ECN | DSCP format */
> *hc06_ptr = tmp;
> hc06_ptr += 4;
> --
> 1.8.5.2
I think this fix patch got missed when bluetooth was merged ... so it
should probably go into the net tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] net: ethoc: don't advertise gigabit speed on attached PHY
From: Florian Fainelli @ 2014-01-27 22:31 UTC (permalink / raw)
To: Max Filippov
Cc: Ben Hutchings, linux-xtensa@linux-xtensa.org, netdev,
devicetree@vger.kernel.org, LKML, Chris Zankel, Marc Gauthier,
David S. Miller, Grant Likely, Rob Herring
In-Reply-To: <CAMo8BfLx9iVTqW9fQonF=7C=oDG1RpU5iyGUXf_wFnk7TEvShA@mail.gmail.com>
(fixing Rob's email)
2014-01-27 Max Filippov <jcmvbkbc@gmail.com>:
> On Mon, Jan 27, 2014 at 11:36 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> 2014-01-27 Max Filippov <jcmvbkbc@gmail.com>:
>>> On Mon, Jan 27, 2014 at 2:18 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
>>>> On Mon, 2014-01-27 at 07:59 +0400, Max Filippov wrote:
>>>>> OpenCores 10/100 Mbps MAC does not support speeds above 100 Mbps, but does
>>>>> not disable advertisement when PHY supports them. This results in
>>>>> non-functioning network when the MAC is connected to a gigabit PHY connected
>>>>> to a gigabit switch.
>>>>>
>>>>> The fix is to disable gigabit speed advertisement on attached PHY
>>>>> unconditionally.
>>>>>
>>>>> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
>>>>> ---
>>>>> drivers/net/ethernet/ethoc.c | 2 ++
>>>>> 1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/ethoc.c b/drivers/net/ethernet/ethoc.c
>>>>> index 4de8cfd..0aa1a05 100644
>>>>> --- a/drivers/net/ethernet/ethoc.c
>>>>> +++ b/drivers/net/ethernet/ethoc.c
>>>>> @@ -712,6 +712,8 @@ static int ethoc_open(struct net_device *dev)
>>>>> netif_start_queue(dev);
>>>>> }
>>>>>
>>>>> + priv->phy->advertising &= ~(ADVERTISED_1000baseT_Full |
>>>>> + ADVERTISED_1000baseT_Half);
>>>>> phy_start(priv->phy);
>>>>> napi_enable(&priv->napi);
>>>>>
>>>>
>>>> This is not sufficient to disable gigabit speeds; the supported mask
>>>> should also be limited. And it should be done even before the net
>>>
>>> I tried that, but when I also limit supported mask the phy driver doesn't
>>> touch gigabit advertising register int the genphy_config_advert at all.
>>> That's probably right for ethtool interface, but ethoc doesn't support
>>> ethtool.
>>
>> This is not right for libphy either, phydev->supported must reflect
>> that you support Gigabit or not.
>
> I'm sorry, does that mean that I must not touch phydev->supported,
> or that I must update it too and somehow fix genphy_config_advert?
What I meant is that your driver has to set both phydev->advertising
and phydev->supported. genphy_config_advert() is doing
phdev->advertising &= phydev->supported, leaving phydev->supported to
something more restrictive will produce unexpected results. This is
also important if phy_driver::config_aneg() is not using the generic
implementation and directly uses/modifies phydev->advertising and
phydev->supported.
It seems like there is room for improvements in that area regardless
of how we access things. For instance, specifying the PHY interface
mode (MII, GMII etc...) should already provide a hint of what
phydev->supported should look like. You cannot do Gigabit with MII for
instance.
>
>> Since ethoc supports libphy, there really is no reason not to
>> implement the ethtool_{get,set}_settings callbacks using
>> phy_mii_ioctl().
>
> Ok, I'll add that.
>
>>>> device is registered.
>>>>
>>>> Rather than poking into the phy_device structure directly from this
>>>> driver, I think you should add a function in phylib for this purpose.
>>
>> All drivers are currently modifying phydev->advertising and
>> phydev->supported directly, most of them do it correctly as far as I
>> checked. It does make some sense to add a helper function though.
>
> [...]
>
>>> diff --git a/include/linux/phy.h b/include/linux/phy.h
>>> index 48a4dc3..0282a8d 100644
>>> --- a/include/linux/phy.h
>>> +++ b/include/linux/phy.h
>>> @@ -559,6 +559,11 @@ static inline int phy_read_status(struct phy_device *phydev) {
>>> return phydev->drv->read_status(phydev);
>>> }
>>>
>>> +static inline void phy_update_adv(struct phy_device *phydev, u32 mask, u32 set)
>>> +{
>>> + phydev->advertising = (phydev->advertising & mask) | set;
>>> +}
>>> +
>>
>> This should be a preliminary patch to this patchset, so you first
>> introduce the function, then use it in the driver, but the idea looks
>> good. There is room for updating quite some drivers out there since
>> those used to modify phydev->advertising and phydev->supported
>> directly without using an accessor.
>
> What about those that do something like this:
>
> phydev->advertising = phydev->supported;
>
> leave them as is, or provide read accessor for phydev->supported?
Those should be just fine since genphy_config_advert() does
phydev->advertising &= phydev->supported, so the end result will be
identical. You mean a write accessor instead of a read accessor?
--
Florian
^ 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