On Thu, Oct 22, 2015 at 12:37:44AM +0800, Lan Tianyu wrote:
> Migration relies on tracking dirty page to migrate memory.
> Hardware can't automatically mark a page as dirty after DMA
> memory access. VF descriptor rings and data buffers are modified
> by hardware when receive and transmit data. To
On 2015-10-22 14:14, Prarit Bhargava wrote:
> On 10/22/2015 08:06 AM, Michal Marek wrote:
>> It used to require a closing parenthesis, so it would not match the
>> multiline macro invocations at all. Now it matches them, but ctags
>> correctly warns that the empty string is probably not what we int
New device IDs shamelessly lifted from the vendor driver.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 355842b85ee9..2a7c1be23c4f 100644
--- a/drivers/net/usb/qmi_wwa
On 10/22/2015 08:06 AM, Michal Marek wrote:
> On 2015-10-22 13:31, Prarit Bhargava wrote:
>>
>>
>> On 10/21/2015 03:52 PM, Michal Marek wrote:
>>> Dne 21.10.2015 v 21:27 Prarit Bhargava napsal(a):
On 10/15/2015 04:16 PM, Michal Marek wrote:
> Otherwise make tags can't parse them:
>
>
On Thu, 2015-10-22 at 12:58 +0100, Alan Burlison wrote:
> On 22/10/2015 12:30, Eric Dumazet wrote:
>
> > We absolutely do not _want_ to do this just so that linux becomes slower
> > to the point Solaris can compete, or you guys can avoid some work.
>
> Sentiments such as that really have no place
>
> On Wed, 2015-10-21 at 21:34 +0300, Emmanuel Grumbach wrote:
> > +
> > + if (skb->protocol == htons(ETH_P_IP)) {
> > + ip_hdr(tmp)->id = ip_hdr(skb)->id;
>
> Too late, you already called consume_skb(skb).
> So this is a potential use after free.
Ouch - thanks for c
On 2015-10-22 13:31, Prarit Bhargava wrote:
>
>
> On 10/21/2015 03:52 PM, Michal Marek wrote:
>> Dne 21.10.2015 v 21:27 Prarit Bhargava napsal(a):
>>> On 10/15/2015 04:16 PM, Michal Marek wrote:
Otherwise make tags can't parse them:
ctags: Warning: arch/ia64/kernel/smp.c:60: null e
> Well, mdio-mux also calls switch_fn inside the mdio_lock, clean refactoring
> would introduce a separate lock and call the nested variants.
> Is that ok ? Can someone test mdio-mux if I make the change ?
Hi Neil
I would not touch mdio-mux. As you said, it does more than lock, read,
unlock. It i
On Wed, 2015-10-21 at 21:34 +0300, Emmanuel Grumbach wrote:
> +
> + if (skb->protocol == htons(ETH_P_IP)) {
> + ip_hdr(tmp)->id = ip_hdr(skb)->id;
Too late, you already called consume_skb(skb).
So this is a potential use after free.
> + be16_add
On 22/10/2015 12:30, Eric Dumazet wrote:
We absolutely do not _want_ to do this just so that linux becomes slower
to the point Solaris can compete, or you guys can avoid some work.
Sentiments such as that really have no place in a discussion that's been
focussed primarily on the behaviour of
On 10/21/2015 03:52 PM, Michal Marek wrote:
> Dne 21.10.2015 v 21:27 Prarit Bhargava napsal(a):
>> On 10/15/2015 04:16 PM, Michal Marek wrote:
>>> Otherwise make tags can't parse them:
>>>
>>> ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern
>>> "\1"
>>> ctags: Warning:
On Thu, 2015-10-22 at 08:15 +0200, casper@oracle.com wrote:
> >It's been said that the current mechanisms in Linux & some BSD variants
> >can be subject to races, and the behaviour exhibited doesn't conform to
> >POSIX, for example requiring the use of shutdown() on unconnected
> >sockets be
On 22/10/2015 07:51, casper@oracle.com wrote:
It would more fruitful to have such a discussion in one of the OpenGroup
mailing lists; people gathered there have a lot of experience and it is
also possible to fix the standard when it turns out that it indeed as
vague as you claim it is (I don
On 22/10/2015 05:44, Al Viro wrote:
It's been said that the current mechanisms in Linux & some BSD
variants can be subject to races
You do realize that it goes for the entire area? And the races found
in this thread are in the BSD variant that tries to do something similar
to what you guys sa
Hi Dave,
Here's probably the last bluetooth-next pull request for 4.4. Among
several other changes it contains the rest of the fixes & cleanups from
the Bluetooth UnplugFest (that didn't need to be hurried to 4.3).
- Refactoring & cleanups to 6lowpan code
- New USB ids for two Atheros controlle
On 22/10/2015 05:21, Al Viro wrote:
Most of the work on using a file descriptor is local to the thread.
Using - sure, but what of cacheline dirtied every time you resolve a
descriptor to file reference?
Don't you have to do that anyway, to do anything useful with the file?
How much does it
On 2015/10/22 17:06, Peter Zijlstra wrote:
On Wed, Oct 21, 2015 at 02:19:49PM -0700, Alexei Starovoitov wrote:
Urgh, that's still horridly inconsistent. Can we please come up with a
consistent interface to perf?
My suggestion was to do ioctl(enable/disable) of events from userspace
after rec
On 19/10/15 02:20, Roopa Prabhu wrote:
@@ -159,6 +137,7 @@ static int mpls_forward(struct sk_buff *skb, struct
net_device *dev,
struct net *net = dev_net(dev);
struct mpls_shim_hdr *hdr;
struct mpls_route *rt;
+ struct mpls_nh *nh;
struct mpls_entry_decoded
On 10/22/2015 11:02 AM, Arnd Bergmann wrote:
> On Thursday 22 October 2015 08:34:53 Appana Durga Kedareswara Rao wrote:
>>> On Thursday 22 October 2015 10:16:02 Kedareswara rao Appana wrote:
The driver only supports memory-mapped I/O [by ioremap()], so
readl/writel is actually the right t
On Thu, Oct 22, 2015 at 11:12:16AM +0800, Wangnan (F) wrote:
> On 2015/10/22 11:09, Alexei Starovoitov wrote:
> >On 10/21/15 6:56 PM, Wangnan (F) wrote:
> >>>One alternative solution I can image is to attach a BPF program
> >>>at sampling like kprobe, and return 0 if we don't want sampling
> >>>tak
These patches add support for Intel's FieldsPeak NFC solution.
Fields Peak complies with the ISO/IEC 14443A/B, 15693, 18092,
and JIS X 6319-4. It is an NCI based controller.
RF Protocols supported:
- NFC Forum Type 1 Tags (Jewel, Topaz)
- NFC Forum Type 2 Tags (Mifare UL)
- NFC Forum Type 3 Ta
FDP driver needs to send the firmware as regular packets
(not fragmented). The driver should have a way to
get the max packet size for a given connection.
Signed-off-by: Robert Dolca
---
include/net/nfc/nci_core.h | 1 +
net/nfc/nci/data.c | 12
2 files changed, 13 insertio
For the firmware update the driver may use nci_send_data.
Signed-off-by: Robert Dolca
---
net/nfc/nci/data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
index 566466d..83acd18 100644
--- a/net/nfc/nci/data.c
+++ b/net/nfc/nci/data.c
@@ -203,6 +203,
This allows sending core commands from the driver. The driver should be
able to send NCI core commands like CORE_GET_CONFIG_CMD.
Signed-off-by: Robert Dolca
---
include/net/nfc/nci_core.h | 1 +
net/nfc/nci/core.c | 24 +++-
2 files changed, 20 insertions(+), 5 delet
The driver may be required to act when some responses or notifications
arrive. For example the NCI core does not have a handler for
NCI_OP_CORE_GET_CONFIG_RSP. The NFCC can send a config response that has
to be read by the driver and the packet may contain vendor specific data.
The Fields Peak dri
Add NCI_OP_CORE_GET_CONFIG_CMD, NCI_OP_CORE_GET_CONFIG_RSP
and NCI_OP_CORE_RESET_NTF.
Signed-off-by: Robert Dolca
---
include/net/nfc/nci.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/net/nfc/nci.h b/include/net/nfc/nci.h
index 75d2e18..b495825 100644
--- a/include/net/nfc
Initially it was used to create hooks in the driver for proprietary
operations. Currently it is being used for hooks for both proprietary
and generic operations.
Signed-off-by: Robert Dolca
---
drivers/nfc/s3fwrn5/nci.c | 4 ++--
drivers/nfc/st-nci/core.c | 2 +-
include/net/nfc/nci_core.h |
On Thu, Oct 22, 2015 at 01:27:29AM -0400, Jason Wang wrote:
> This patch tries to poll for new added tx buffer for a while at the
> end of tx processing. The maximum time spent on polling were limited
> through a module parameter. To avoid block rx, the loop will end it
> there's new other works qu
The driver should know that it can continue with post setup where
setup left off. Being able to execute post_setup when setup fails may
force the developer to keep this state in the driver.
Signed-off-by: Robert Dolca
---
net/nfc/nci/core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
On Thu, Oct 22, 2015 at 03:51:37PM +0800, Wangnan (F) wrote:
> Because I'm not very sure what the meaning of "inconsistent" in
> Peter's words...
What's inconsistent is that some perf actions can be done only on local
events while others can be done on !local.
And I can't say I particularly like
If the number of destination speific parameters supplied is 0 the call
will fail. If the first destination specific parameter does not have a
value, curr_id will be set to 0.
Signed-off-by: Robert Dolca
---
net/nfc/nci/core.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --
This functin takes as a parameter a pointer to the nci_dev struct and
the first byte from the values of the first domain specific parameter that
was used for the connection creation.
Signed-off-by: Robert Dolca
---
include/net/nfc/nci_core.h | 1 +
net/nfc/nci/core.c | 13 +
Fields Peak complies with the ISO/IEC 14443A/B, 15693, 18092,
and JIS X 6319-4. It is an NCI based controller.
RF Protocols supported:
- NFC Forum Type 1 Tags (Jewel, Topaz)
- NFC Forum Type 2 Tags (Mifare UL)
- NFC Forum Type 3 Tags (FeliCa)
- NFC Forum Type 4A (ISO/IEC 14443 A-4 106kbps to 8
On Wed, Oct 21, 2015 at 02:19:49PM -0700, Alexei Starovoitov wrote:
> >Urgh, that's still horridly inconsistent. Can we please come up with a
> >consistent interface to perf?
> My suggestion was to do ioctl(enable/disable) of events from userspace
> after receiving notification from kernel via my
On Thursday 22 October 2015 08:34:53 Appana Durga Kedareswara Rao wrote:
> > On Thursday 22 October 2015 10:16:02 Kedareswara rao Appana wrote:
> > > The driver only supports memory-mapped I/O [by ioremap()], so
> > > readl/writel is actually the right thing to do, IMO.
> > > During the validation
On Thursday 22 October 2015 10:21:58 Marc Kleine-Budde wrote:
> On 10/22/2015 10:14 AM, Arnd Bergmann wrote:
> > On Thursday 22 October 2015 10:16:02 Kedareswara rao Appana wrote:
> >> The driver only supports memory-mapped I/O [by ioremap()],
> >> so readl/writel is actually the right thing to do,
In order to avoid locked signal false positive for nested mdiobus
read/write calls, nested code was introduced in mv88e6xxx and
mdio-mux.
But mv88e6060 also needs such nested mdiobus read/write calls.
For sake of refactoring, introduce nested variants of mdiobus read/write
and make them used by mv8
Since nested variants of mdiobus_read/write are used in multiple
drivers, add nested variants in the mdiobus core.
Suggested-by: Andrew Lunn
Signed-off-by: Neil Armstrong
---
drivers/net/phy/mdio_bus.c | 55 ++
include/linux/phy.h| 2 ++
2 fi
Hi Marc,
> -Original Message-
> From: Marc Kleine-Budde [mailto:m...@pengutronix.de]
> Sent: Thursday, October 22, 2015 1:52 PM
> To: Arnd Bergmann; linux-arm-ker...@lists.infradead.org
> Cc: Appana Durga Kedareswara Rao; Anirudha Sarangi; w...@grandegger.com;
> Michal Simek; Soren Brinkma
Make the mv88e6xxx driver use the previously introduced nested
variants of mdiobus_read/write functions.
Signed-off-by: Neil Armstrong
---
drivers/net/dsa/mv88e6xxx.c | 46 +
1 file changed, 9 insertions(+), 37 deletions(-)
diff --git a/drivers/net/ds
Like mv88e6xxx and mdio-mux, to avoid lockdep give false positives
because of nested MDIO busses, switch to previously introduced
nested mdiobus_read/write variants.
Signed-off-by: Neil Armstrong
---
drivers/net/dsa/mv88e6060.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
On Thu, Oct 22, 2015 at 01:27:28AM -0400, Jason Wang wrote:
> This path introduces a helper which can give a hint for whether or not
> there's a work queued in the work list.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vhost/vhost.c | 6 ++
> drivers/vhost/vhost.h | 1 +
> 2 files changed,
Hi Arnd,
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Thursday, October 22, 2015 1:45 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Appana Durga Kedareswara Rao; Anirudha Sarangi; w...@grandegger.com;
> m...@pengutronix.de; Michal Simek; Soren Bri
Kernel allows for zero IPv4 peer addresses (IFA_ADDRESS):
ip address add 192.168.5.1 peer 0.0.0.0/24 dev dummy
which is distinct from a usual address like:
ip address add 192.168.5.1/24 dev dummy
ip address add 192.168.5.1 peer 192.168.5.1/24 dev dummy
For IPv4, a missing IFA_ADDRESS a
On 10/22/2015 10:14 AM, Arnd Bergmann wrote:
> On Thursday 22 October 2015 10:16:02 Kedareswara rao Appana wrote:
>> The driver only supports memory-mapped I/O [by ioremap()],
>> so readl/writel is actually the right thing to do, IMO.
>> During the validation of this driver or IP on ARM 64-bit proc
On Thursday 22 October 2015 10:16:02 Kedareswara rao Appana wrote:
> The driver only supports memory-mapped I/O [by ioremap()],
> so readl/writel is actually the right thing to do, IMO.
> During the validation of this driver or IP on ARM 64-bit processor
> while sending lot of packets observed that
On 10/21/2015 06:14 PM, Andrew Lunn wrote:
> On Wed, Oct 21, 2015 at 05:37:45PM +0200, Neil Armstrong wrote:
>> Like the change made for mv88e6xxx, use mutex_lock_nested() to avoid
>> lockdep to give false positives because of nested MDIO busses.
>
> Hi Neil
>
> We now have three instances of thi
On 10/21/2015 06:14 PM, Andrew Lunn wrote:
> On Wed, Oct 21, 2015 at 05:37:45PM +0200, Neil Armstrong wrote:
>> Like the change made for mv88e6xxx, use mutex_lock_nested() to avoid
>> lockdep to give false positives because of nested MDIO busses.
>
> Hi Neil
>
> We now have three instances of thi
On 2015/10/22 15:39, Ingo Molnar wrote:
* Wangnan (F) wrote:
[SNIP]
In summary, your either-or logic doesn't hold in BPF world. A BPF
program can only access perf event in a highly restricted way. We
don't allow it calling perf_event_read_local() across core, so it
can't.
Urgh, that's sti
Hello,
> diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h
> index ff0b981..87de343 100644
> --- a/include/linux/eventfd.h
> +++ b/include/linux/eventfd.h
>
> -/*
> - * CAREFUL: Check include/uapi/asm-generic/fcntl.h when defining
> - * new flags, since they might collide with O_*
On 2015/10/22 14:21, Alexei Starovoitov wrote:
On 10/21/15 10:31 PM, Wangnan (F) wrote:
+if ((attr->type != PERF_TYPE_RAW &&
+ !(attr->type == PERF_TYPE_SOFTWARE &&
+ attr->config == PERF_COUNT_SW_BPF_OUTPUT) &&
+ attr->type != PERF_TYPE_HARDWARE) ||
+attr
* Wangnan (F) wrote:
>
>
> On 2015/10/22 0:57, Peter Zijlstra wrote:
> >On Wed, Oct 21, 2015 at 11:06:47PM +0800, pi3orama wrote:
> >>>So explain; how does this eBPF stuff work.
> >>I think I get your point this time, and let me explain the eBPF stuff to
> >>you.
> >>
> >>You are aware that B
Hi Andrew,
On 10/21/2015 06:14 PM, Andrew Lunn wrote:
> On Wed, Oct 21, 2015 at 05:37:45PM +0200, Neil Armstrong wrote:
>> Like the change made for mv88e6xxx, use mutex_lock_nested() to avoid
>> lockdep to give false positives because of nested MDIO busses.
>
> Hi Neil
>
> We now have three inst
From: Al Viro
>Except that in this case "correctness" is the matter of rather obscure and
>ill-documented areas in POSIX. Don't get me wrong - this semantics isn't
>inherently bad, but it's nowhere near being an absolute requirement.
It would more fruitful to have such a discussion in one of t
201 - 254 of 254 matches
Mail list logo
