Hi,
I am currently working on an project that aims to provide multiple 802.11ac
radio support on a single node for mesh network. In this both the radios will
operate in different channel and will talk to different nodes in mesh network.
I need to work with kernel mac80211 driver subsystem for t
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Tuesday, January 26, 2016 18:24
> To: Dexuan Cui
> Cc: gre...@linuxfoundation.org; da...@davemloft.net;
> step...@networkplumber.org; netdev@vger.kernel.org; linux-
> ker...@vger.kernel.org; driverdev-de...@linuxdriverproject.org;
> a...@canonica
On 25 January 2016 at 17:11, Joe Stringer wrote:
> On 22 January 2016 at 17:22, Eric Dumazet wrote:
>> On Fri, 2016-01-22 at 15:49 -0800, Joe Stringer wrote:
>>> Later parts of the stack (including fragmentation) expect that there is
>>> never a socket attached to frag in a frag_list, however thi
On Tue, 2016-01-26 at 15:12 -0800, Cong Wang wrote:
> On Tue, Jan 26, 2016 at 2:55 PM, Julian Calaby
> wrote:
> > Hi Cong,
> >
> > On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang wrote:
> >
> > A commit message would be nice. A brief rundown of how this is called
> > from userspace would be nice (I'm
> Well, we do now, since that is one of the results used by
> of_mdiobus_child_is_phy(),
It uses it, but do not rely on it, since for backwards compatibility,
we cannot assume it is there.
You can never change an optional parameter to a mandatory parameter in
DT. To do so breaks backwards compati
From: Dan Streetman
Date: Mon, 25 Jan 2016 12:36:57 -0500
> David, can you queue commit a8a572a for stable please? It fixes
> commit d7c7544c3d from 2010, and without it anyone using multiple
> ipsec net namespaces can find one (or more) of their netns incorrectly
> reach the ipsec dst limit and
On Tue, Jan 26, 2016 at 10:00:34PM +0300, Sergei Shtylyov wrote:
> Hello.
>
>Yoshihiro-san, there was no need to hurry -- net-next is still closed and
> by posting this patch to netdev you're only making DaveM upset...
True.
> On 01/26/2016 03:23 AM, Simon Horman wrote:
>
> >> From: Kazuya
From: Ian Campbell
Date: Thu, 21 Jan 2016 11:58:10 +
> Please could you queue these three:
>
> 32a8440 xen-netfront: respect user provided max_queues
> 4c82ac3 xen-netback: respect user provided max_queues
> ca88ea1 xen-netfront: update num_queues to real created
>
> for stable backports to
On 26/01/16 17:06, Andrew Lunn wrote:
> On Tue, Jan 26, 2016 at 04:33:11PM -0800, Florian Fainelli wrote:
>> On 26/01/16 16:11, Andrew Lunn wrote:
>>> PHY devices may only list clause 22, 45, and their PHY identifier
>>> values as compatible values. No other compatible strings are allowed.
>>> Make
On Tue, Jan 26, 2016 at 04:33:11PM -0800, Florian Fainelli wrote:
> On 26/01/16 16:11, Andrew Lunn wrote:
> > PHY devices may only list clause 22, 45, and their PHY identifier
> > values as compatible values. No other compatible strings are allowed.
> > Make this clear in the documentation, and rem
From: Eric Dumazet
We should not assume a valid protocol header is present,
as this is not the case for IPv4 fragments.
Lets avoid extra cache line misses and potential bugs
if we actually find a socket and incorrectly uses its dst.
Signed-off-by: Eric Dumazet
---
net/ipv4/ip_input.c |5 +
On 26/01/16 16:11, Andrew Lunn wrote:
> PHY devices may only list clause 22, 45, and their PHY identifier
> values as compatible values. No other compatible strings are allowed.
> Make this clear in the documentation, and remove examples where
> make/model compatible strings are listed.
Humm, shou
On Tue, Jan 26, 2016 at 03:54:13PM -0800, Florian Fainelli wrote:
> On 26/01/16 14:09, Andrew Lunn wrote:
> >>> Nope, not an option. Only a small number of DTB actually use c22 or
> >>> c45. The majority of devices have no compatible at all. Why should
> >>> they, the binding documentation says it
PHY devices may only list clause 22, 45, and their PHY identifier
values as compatible values. No other compatible strings are allowed.
Make this clear in the documentation, and remove examples where
make/model compatible strings are listed.
Signed-off-by: Andrew Lunn
---
Documentation/devicetre
Some phy nodes list a compatible value indicating the PHY make/model.
This is never used to match the device to the driver. However it does
confuse the code to separate a PHY from a generic MDIO device like a
switch. Generic MDIO devices must have a compatible value, PHYs can
list clause 22 or 45,
White list PHY compatible values which indicate PHYs. Issue a warning
when one is encountered.
Update the documentation to make it clear what is expected in the
compatible string.
Andrew Lunn (2):
of: of_mdio: Add a whitelist of PHY compatibilities.
DT: phy.txt: Clarify expected compatible v
On 26/01/16 14:09, Andrew Lunn wrote:
>>> Nope, not an option. Only a small number of DTB actually use c22 or
>>> c45. The majority of devices have no compatible at all. Why should
>>> they, the binding documentation says it is optional!
>>
>> So one thing that can be done is to just have a whiteli
From: Richard Weinberger
Sent: Tuesday, January 26, 2016 12:24 AM
>Not every arch has io memory.
>So, unbreak the build by fixing the dependencies.
>Signed-off-by: Richard Weinberger
>---
> drivers/net/ethernet/ezchip/Kconfig | 1 +
> drivers/net/phy/Kconfig | 1 +
> 2 files changed,
Hi Cong,
On Wed, Jan 27, 2016 at 10:12 AM, Cong Wang wrote:
> On Tue, Jan 26, 2016 at 2:55 PM, Julian Calaby
> wrote:
>> Hi Cong,
>>
>> On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang wrote:
>>
>> A commit message would be nice. A brief rundown of how this is called
>> from userspace would be nice
On Tue, Jan 26, 2016 at 2:55 PM, Julian Calaby wrote:
> Hi Cong,
>
> On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang wrote:
>
> A commit message would be nice. A brief rundown of how this is called
> from userspace would be nice (I'm talking a single sentence here, e.g.
> "this is allocated when submi
Hi Cong,
On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang wrote:
A commit message would be nice. A brief rundown of how this is called
from userspace would be nice (I'm talking a single sentence here, e.g.
"this is allocated when submitting a nfc packet") and what issue
__GFP_NOWARN is fixing. (I'm gu
> > Nope, not an option. Only a small number of DTB actually use c22 or
> > c45. The majority of devices have no compatible at all. Why should
> > they, the binding documentation says it is optional!
>
> So one thing that can be done is to just have a whitelist in the
> driver that we add the know
When CONFIG_OPTIMIZE_INLINING is set, the sta_info_insert_finish
function consumes more stack than normally, exceeding the
1024 byte limit on ARM:
net/mac80211/sta_info.c: In function 'sta_info_insert_finish':
net/mac80211/sta_info.c:561:1: error: the frame size of 1080 bytes is larger
than 1024
On Tue, Jan 26, 2016 at 1:36 PM, Andrew Lunn wrote:
> On Tue, Jan 26, 2016 at 12:46:31PM -0800, Florian Fainelli wrote:
>> On 26/01/16 10:14, Olof Johansson wrote:
>> > +devicet...@vger.kernel.org instead.
>> >
>> > On Tue, Jan 26, 2016 at 10:08 AM, Olof Johansson wrote:
>> >> On Tue, Jan 26, 201
On Tue, Jan 26, 2016 at 01:21:00PM -0800, David Miller wrote:
> From: Jarod Wilson
> Date: Tue, 26 Jan 2016 16:14:53 -0500
>
> > # ethtool -S bond0
> > no stats available
>
> ethtool -S is for device specific stats.
Okay, good, that was what it looked like to me. Glad I'm not completely
lost he
On Tue, 2016-01-26 at 20:45 +0100, Toralf Förster wrote:
> at a 32 nbit KVM image of a Gentoo Linux runniogn v4.5-rc1 - attached is
> /var/log/messages
>
Jan 26 20:40:04 n22kvm-clone kernel:
Jan 26 20:40:04 n22kvm-
On Tue, Jan 26, 2016 at 12:46:31PM -0800, Florian Fainelli wrote:
> On 26/01/16 10:14, Olof Johansson wrote:
> > +devicet...@vger.kernel.org instead.
> >
> > On Tue, Jan 26, 2016 at 10:08 AM, Olof Johansson wrote:
> >> On Tue, Jan 26, 2016 at 9:53 AM, Andrew Lunn wrote:
> I hate to bikeshed
On Tue, Jan 26, 2016 at 01:24:59PM -0800, Eric Dumazet wrote:
> On Tue, Jan 26, 2016 at 1:14 PM, Jarod Wilson wrote:
> > On Sat, Jan 23, 2016 at 07:23:09AM -0800, Eric Dumazet wrote:
> >> On Fri, 2016-01-22 at 14:11 -0500, Jarod Wilson wrote:
> >>
> >> > ---
> >> > net/core/dev.c | 3 +++
> >> >
On Tue, Jan 26, 2016 at 1:14 PM, Jarod Wilson wrote:
> On Sat, Jan 23, 2016 at 07:23:09AM -0800, Eric Dumazet wrote:
>> On Fri, 2016-01-22 at 14:11 -0500, Jarod Wilson wrote:
>>
>> > ---
>> > net/core/dev.c | 3 +++
>> > 1 file changed, 3 insertions(+)
>> >
>> > diff --git a/net/core/dev.c b/net/
From: Jarod Wilson
Date: Tue, 26 Jan 2016 16:14:53 -0500
> # ethtool -S bond0
> no stats available
ethtool -S is for device specific stats.
Some drivers use this facility to provide per-RX-queue and per-TX-queue
versions of the existing core netdev stats.
On Sat, Jan 23, 2016 at 07:23:09AM -0800, Eric Dumazet wrote:
> On Fri, 2016-01-22 at 14:11 -0500, Jarod Wilson wrote:
>
> > ---
> > net/core/dev.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 8cba3d8..1354c7b 100644
> > --- a/net/co
On 26/01/16 10:14, Olof Johansson wrote:
> +devicet...@vger.kernel.org instead.
>
> On Tue, Jan 26, 2016 at 10:08 AM, Olof Johansson wrote:
>> On Tue, Jan 26, 2016 at 9:53 AM, Andrew Lunn wrote:
I hate to bikeshed, but I'm not sure if "generic-mdio" is too...
generic? Will someone writ
I'm running into a relatively easily reproducible kernel panic related to the
all_adj_list handling for netdevs
in recent kernels.
The following sequence of commands will reproduce the issue:
ip link add link eth0 name eth0.100 type vlan id 100
ip link add link eth0 name eth0.200 type vlan id 2
Em Tue, Jan 26, 2016 at 08:27:48PM +0100, Dmitry Vyukov escreveu:
> On Fri, Jan 22, 2016 at 10:16 PM, Arnaldo Carvalho de Melo
> wrote:
> > Em Fri, Jan 22, 2016 at 09:39:53PM +0100, Dmitry Vyukov escreveu:
> >> I am on commit 30f05309bde49295e02e45c7e615f73aa4e0ccc2 (Jan 20).
> >> Seems to be add
On Fri, Jan 22, 2016 at 10:16 PM, Arnaldo Carvalho de Melo
wrote:
> Em Fri, Jan 22, 2016 at 09:39:53PM +0100, Dmitry Vyukov escreveu:
>> While running syzkaller fuzzer I've hit the following use-after-free:
>
>
>
>> Call Trace:
>> [] __asan_report_load8_noabort+0x3e/0x40
>> mm/kasan/report.c:295
Folks
I have a doubt about the behaviour of a Linux IPv4 raw socket, with the
IP_HDRINCL option set, rejecting a packet bigger than the outgoing interface’s
MTU size with EMSGSIZE. Please take a look at the following and let me know if
I should make a kernel code change to remove this behaviou
Hello.
Yoshihiro-san, there was no need to hurry -- net-next is still closed and
by posting this patch to netdev you're only making DaveM upset...
On 01/26/2016 03:23 AM, Simon Horman wrote:
>> From: Kazuya Mizuguchi
This patch supports the following interrupts.
- One interrupt for mul
Remove unnecassary casts in the argument to kfree.
Found using Coccinelle. The semantic patch used to find this is as follows:
//
@@
type T;
expression *f;
@@
- kfree((T *)(f));
+ kfree(f);
//
Signed-off-by: Amitoj Kaur Chawla
---
drivers/isdn/hisax/fsm.c | 2 +-
drivers/isdn/mISDN/fsm.c | 2
On Mon, Jan 25, 2016 at 7:59 AM, Dmitry Vyukov wrote:
> It seems that skb can be freed after skb_put() and spinlock unlock,
> but ircomm_param_request reads skb->len afterwards:
>
> int ircomm_param_request(struct ircomm_tty_cb *self, __u8 pi, int flush)
> {
> ...
> skb_put(skb, count);
>
+devicet...@vger.kernel.org instead.
On Tue, Jan 26, 2016 at 10:08 AM, Olof Johansson wrote:
> On Tue, Jan 26, 2016 at 9:53 AM, Andrew Lunn wrote:
>>> I hate to bikeshed, but I'm not sure if "generic-mdio" is too...
>>> generic? Will someone writing a DT be thinking "well, this is a
>>> generic
Brauchen Sie ein Geschäft oder einen persönlichen Kredit?
Wir haben die Fähigkeit zur Geschäfts- und persönlichen Kredit /
Darlehen an Unternehmen und Individuum zu 3 % Zins.
Unser Firmensitz ist in China, Europa und Amerika.
Für weitere Informationen Kontakt E-Mail: premsfinancial...@outlook.com
On Tue, Jan 26, 2016 at 9:53 AM, Andrew Lunn wrote:
>> I hate to bikeshed, but I'm not sure if "generic-mdio" is too...
>> generic? Will someone writing a DT be thinking "well, this is a
>> generic mdio PHY, I should set it"? "mdio-device"?
>> "generic-nonphy-mdio"? Neither of those seem much bet
On Mon, Jan 25, 2016 at 7:51 PM, Bernie Harris
wrote:
> There are cases where qdisc_dequeue_peeked can return NULL, and the result
> is dereferenced later on in the function.
>
> Similarly to the other qdisc dequeue functions, check whether the skb
> pointer is NULL and if it is, goto out.
>
> Sig
Reported-by: Dmitry Vyukov
Cc: Lauro Ramos Venancio
Cc: Aloisio Almeida Jr
Cc: Samuel Ortiz
Signed-off-by: Cong Wang
---
net/nfc/llcp_commands.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c
index 3621a90..5d94055 100644
> I hate to bikeshed, but I'm not sure if "generic-mdio" is too...
> generic? Will someone writing a DT be thinking "well, this is a
> generic mdio PHY, I should set it"? "mdio-device"?
> "generic-nonphy-mdio"? Neither of those seem much better.
How about 'not-a-phy'?
Andrew
Tue, Jan 26, 2016 at 06:44:24PM CET, f...@sysclose.org wrote:
>On Tue, 26 Jan 2016 18:30:41 +0100
>Jiri Pirko wrote:
>
>> Tue, Jan 26, 2016 at 06:26:30PM CET, f...@sysclose.org wrote:
>> >
>> >Hi,
>> >
>> >After the commit[1] below, we can't set ageing on a Linux bridge
>> >device to zero. It see
On Tue, 26 Jan 2016 18:30:41 +0100
Jiri Pirko wrote:
> Tue, Jan 26, 2016 at 06:26:30PM CET, f...@sysclose.org wrote:
> >
> >Hi,
> >
> >After the commit[1] below, we can't set ageing on a Linux bridge
> >device to zero. It seems rocker needs the minimum value, but we
> >can't break an old and val
Tue, Jan 26, 2016 at 06:26:30PM CET, f...@sysclose.org wrote:
>
>Hi,
>
>After the commit[1] below, we can't set ageing on a Linux bridge device
>to zero. It seems rocker needs the minimum value, but we can't break
>an old and valid Linux bridge behavior.
The commit below adds check if the value
Hi,
After the commit[1] below, we can't set ageing on a Linux bridge device
to zero. It seems rocker needs the minimum value, but we can't break
an old and valid Linux bridge behavior.
[1] commit c62987bbd8a1a1664f99e89e3959339350a6131e
Author: Scott Feldman
Date: Thu Oct 8 19:23:19 2015 -0
On Tue, Jan 26, 2016 at 5:34 AM, Andrew Lunn wrote:
> On Tue, Jan 26, 2016 at 02:14:35PM +0200, Aaro Koskinen wrote:
>> Hi,
>>
>> On Tue, Jan 26, 2016 at 05:46:24AM +0100, Andrew Lunn wrote:
>> > On Mon, Jan 25, 2016 at 05:45:21PM +0200, Aaro Koskinen wrote:
>> > > I get the below crash on OCTEON
From: Malcolm Crossley
Trying to batch Tx response events results in poor performance because
this delays freeing the transmitted skbs.
Instead use the standard RING_FINAL_CHECK_FOR_RESPONSES() macro to be
notified once the next Tx response is placed on the ring.
Signed-off-by: Malcolm Crossley
Hello.
On 24/01/16 14:18, Herbert Xu wrote:
This patch replaces uses of blkcipher with skcipher.
Signed-off-by: Herbert Xu
---
net/mac802154/llsec.c | 41 +++--
net/mac802154/llsec.h |3 +--
2 files changed, 24 insertions(+), 20 deletions(-)
Hi,
On Tue, Jan 26, 2016 at 03:12:30PM +0100, Andrew Lunn wrote:
> of_phy_find_device() is used to find the phy device associated with a
> device node. It is expected the node is for a PHY device, but in fact
> it could of been probed as a generic MDIO device. Ensure the device is
> a PHY before r
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Tuesday, 26 January, 2016 09:01
> To: da...@davemloft.net
> Cc: netdev@vger.kernel.org; tipc-discuss...@lists.sourceforge.net; Jon
> Maloy; ma...@donjonn.com; Ying Xue; Richard Alpe; Anders Widell
> Subject: [PATCH net] tipc: f
The code in txq_put_data() would use txq->tx_curr_desc to index the
tso_hdrs/tso_hdrs_dma buffers, for less than 8 bytes unaligned
fragments, which is already moved to the next descriptor at the
beginning of the function.
If that fragment was the last of the the skb, the next skb would use
that sa
In 'commit 7fe8097cef5f ("tipc: fix nullpointer bug when subscribing
to events")', we terminate the connection if the subscription
creation fails.
In the same commit, the subscription creation result was based on
the value of subscription pointer (set in the function) instead of
the return code.
U
of_phy_find_device() is used to find the phy device associated with a
device node. It is expected the node is for a PHY device, but in fact
it could of been probed as a generic MDIO device. Ensure the device is
a PHY before returning it.
Fixes: a9049e0c513c ("mdio: Add support for mdio drivers.")
On Tue, Jan 26, 2016 at 02:14:35PM +0200, Aaro Koskinen wrote:
> Hi,
>
> On Tue, Jan 26, 2016 at 05:46:24AM +0100, Andrew Lunn wrote:
> > On Mon, Jan 25, 2016 at 05:45:21PM +0200, Aaro Koskinen wrote:
> > > I get the below crash on OCTEON (with octeon_mgmt interface, genphy)
> > > always during sy
On Mon, Jan 25, 2016 at 6:52 PM, Marcelo Ricardo Leitner
wrote:
> Great. Dmitry, please give this a run. Local tests looked good but who
> knows what syzkaller may find.
Now running with this patch.
> Thanks
>
> --8<--
>
> Dmitry reported that sctp_add_bind_addr may read more bytes than
> expect
On Thu, 2016-01-21 at 11:06 +0530, Sunil Shahu wrote:
> Remove unnecessory "if" statement and club it with previos "if"
> block.
>
Applied.
johannes
Hi,
On Tue, 2016-01-19 at 10:42 -0500, João Paulo Rechi Vita wrote:
> This series contains a few general improvements to the RFKill code,
> found while
> I was writing the rfkill-all / airplane mode LED trigger. All were
> points where
> I had to read twice or do some other kind of extra effort to
On Tue, Jan 26, 2016 at 12:53 PM, Dmitry Vyukov wrote:
> Hello,
>
> I've hit the following warning while running syzkaller fuzzer:
>
> [ cut here ]
> WARNING: CPU: 2 PID: 17409 at kernel/workqueue.c:3968
> destroy_workqueue+0x172/0x550()
> Modules linked in:
> CPU: 2 PID: 1
Hi,
On Tue, Jan 26, 2016 at 05:46:24AM +0100, Andrew Lunn wrote:
> On Mon, Jan 25, 2016 at 05:45:21PM +0200, Aaro Koskinen wrote:
> > I get the below crash on OCTEON (with octeon_mgmt interface, genphy)
> > always during systemd boot.
>
> I think i know what is going on now.
>
> What does your p
Hello,
I've hit the following warning while running syzkaller fuzzer:
[ cut here ]
WARNING: CPU: 2 PID: 17409 at kernel/workqueue.c:3968
destroy_workqueue+0x172/0x550()
Modules linked in:
CPU: 2 PID: 17409 Comm: syz-executor Not tainted 4.5.0-rc1+ #283
Hardware name: QEMU
On Tue, Jan 26, 2016 at 12:29:57PM +0100, Ilya Dryomov wrote:
>
> LGTM. You want to take it through crypto?
That's probably the easiest route since I'd like to take the first
patch through cryptodev.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://g
On Tue, Jan 26, 2016 at 11:54 AM, Herbert Xu
wrote:
> On Mon, Jan 25, 2016 at 05:18:47PM +0100, Ilya Dryomov wrote:
>>
>> Could you get rid of ivsize instead of assigning to it - see the
>> attached diff?
>
> How about an incremental patch like this? Thanks!
>
> ---8<---
> From: Ilya Dryomov
> Su
4.5.0-rc1 another UBSAN error:
[ 4845.229441]
[ 4845.229454] UBSAN: Undefined behaviour in net/mac80211/rx.c:924:18
[ 4845.229458] load of value 2 is not a valid value for type '_Bool'
[ 4845.229464] CPU: 1 PID: 6266
4.5.0-rc1 with the new UBSAN checker:
[ 2624.978741]
[ 2624.978749] UBSAN: Undefined behaviour in
net/mac80211/rc80211_minstrel.h:47:34
[ 2624.978752] signed integer overflow:
[ 2624.978754] -32768 * 100 cannot
Hi Dave,
After split up the patches from the previous pull request that was
lost in the process, here's a new one with fixes for the current
cycle (I'll follow up with a -next one later.)
I've also scripted my pull-request sending process a bit more, so
hopefully the emails will no longer have an
On Mon, Jan 25, 2016 at 05:18:47PM +0100, Ilya Dryomov wrote:
>
> Could you get rid of ivsize instead of assigning to it - see the
> attached diff?
How about an incremental patch like this? Thanks!
---8<---
From: Ilya Dryomov
Subject: libceph: Remove unnecessary ivsize variables
This patch rem
On Tue, Jan 26, Dexuan Cui wrote:
> +#define AF_MAX 42 /* For now.. */
Maybe net/core/sock.c needs additional strings for the new socket?
Olaf
On Tue, 2016-01-26 at 10:55 +0100, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers WARNING message in rfkill_fop_read:
>
> [ cut here ]
> WARNING: CPU: 2 PID: 6975 at kernel/sched/core.c:7663
> __might_sleep+0x138/0x1a0()
> do not call blocking ops when !T
Hello,
The following program triggers WARNING message in rfkill_fop_read:
[ cut here ]
WARNING: CPU: 2 PID: 6975 at kernel/sched/core.c:7663
__might_sleep+0x138/0x1a0()
do not call blocking ops when !TASK_RUNNING; state=1 set at
[] prepare_to_wait_event+0x141/0x410
kernel/
On Mon, 2016-01-25 at 21:07 +0100, Arend van Spriel wrote:
> On 25-1-2016 20:23, Doug Anderson wrote:
> > Kinda curious: do we get one or two really slow responses on every
> > bootup, or just some bootups? Do we ever succeed even with a slow
> > (like 1.8 or 1.9 seconds) response, or is it always
On Tue, 26 Jan 2016, Hannes Reinecke wrote:
> dfx_get_bars() allocates the various bars, depending on the
> bus type. But as the function itself returns void and there
> is no default selection there is a risk of the function
> returning without allocating any bars.
> This patch moves the entries
Am Dienstag, 26. Januar 2016, 09:46:56 CET schrieb Johannes Berg:
> On Mon, 2016-01-25 at 21:59 +0100, Marc Dietrich wrote:
> >
> >
> > seems to work fine. I wish we could instantiate this from device-tree
> > so we can finially get rid of this file.
>
> That'd be nice - anyone want to propose rf
On Mon, 2016-01-25 at 21:59 +0100, Marc Dietrich wrote:
>
> seems to work fine. I wish we could instantiate this from device-tree
> so we can finially get rid of this file.
That'd be nice - anyone want to propose rfkill DT bindings? :)
johannes
On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote:
>
> Johannes, I assume that you'll want to take this through your tree
> because of the dependency? In that case:
>
> Acked-by: Thierry Reding
I can, but I don't really care - perhaps you'd rather take the entire
series through your tree
When the hvsock channel's outbound ringbuffer is full (i.e.,
hv_ringbuffer_write() returns -EAGAIN), we should avoid the unnecessary
signaling the host.
Signed-off-by: Dexuan Cui
---
drivers/hv/channel.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/hv/channel.
A function to send the type of message is also added.
The coming net/hvsock driver will use this function to proactively request
the host to offer a VMBus channel for a new hvsock connection.
Signed-off-by: Dexuan Cui
---
drivers/hv/channel.c | 15 +++
drivers/hv/channel_mgmt.c
Only the coming hv_sock driver has a "true" value for this flag.
We treat the hvsock offers/channels as special VMBus devices.
Since the hv_sock driver handles all the hvsock offers/channels, we need to
tweak vmbus_match() for hv_sock driver, so we introduce this flag.
Signed-off-by: Dexuan Cui
This will be used by the coming hv_sock driver.
Signed-off-by: Dexuan Cui
---
drivers/hv/channel_mgmt.c | 11 +++
include/linux/hyperv.h| 9 +
2 files changed, 20 insertions(+)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 4611b50..b782944 100644
Hyper-V socket (hvsock) supplies a byte-stream based communication
mechanism between the host and a guest. It's kind of like TCP over VMBus,
but the transportation layer (VMBus) is much simpler than IP. With
Hyper-V Socket, applications between the host and a guest can talk
to each other directly b
The hvsock driver needs this API to release all the resources related
to the channel.
Signed-off-by: Dexuan Cui
---
drivers/hv/channel_mgmt.c | 33 -
drivers/hv/connection.c | 4 ++--
include/linux/hyperv.h| 2 ++
3 files changed, 32 insertions(+), 7 delet
A helper function is also added.
Signed-off-by: Dexuan Cui
---
include/linux/hyperv.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index e4867a7..c0eddd7 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -235,6 +235,
This will be used by the coming net/hvsock driver.
Signed-off-by: Dexuan Cui
---
include/linux/hyperv.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 753dbad..e4867a7 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.
Changes since v1:
- updated "[PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature"
- added __init and __exit for the module init/exit functions
- net/hv_sock/Kconfig: "default m" -> "default m if HYPERV"
- MODULE_LICENSE: "Dual MIT/GPL" -> "Dual BSD/GPL"
Changes since v2:
- fixed various codi
87 matches
Mail list logo
