On Sun, 23 Jul 2017, Gustavo A. R. Silva wrote:
> Hi Julia,
>
> On 07/23/2017 12:07 AM, Julia Lawall wrote:
> >
> >
> > On Sat, 22 Jul 2017, Gustavo A. R. Silva wrote:
> >
> > > Hi Julia, Borislav,
> > >
> > > On 07/22/2017 11:22 AM, Gustavo A. R. Silva wrote:
> > > > Hi all,
> > > >
> > > > On
On Sun, 23 Jul 2017, Gustavo A. R. Silva wrote:
> Hi Julia,
>
> On 07/23/2017 12:07 AM, Julia Lawall wrote:
> >
> >
> > On Sat, 22 Jul 2017, Gustavo A. R. Silva wrote:
> >
> > > Hi Julia, Borislav,
> > >
> > > On 07/22/2017 11:22 AM, Gustavo A. R. Silva wrote:
> > > > Hi all,
> > > >
> > > > On
Hi Julia,
On 07/23/2017 12:07 AM, Julia Lawall wrote:
On Sat, 22 Jul 2017, Gustavo A. R. Silva wrote:
Hi Julia, Borislav,
On 07/22/2017 11:22 AM, Gustavo A. R. Silva wrote:
Hi all,
On 07/22/2017 01:36 AM, Borislav Petkov wrote:
On Fri, Jul 21, 2017 at 10:08:12PM +0200, Julia Lawall
Hi Julia,
On 07/23/2017 12:07 AM, Julia Lawall wrote:
On Sat, 22 Jul 2017, Gustavo A. R. Silva wrote:
Hi Julia, Borislav,
On 07/22/2017 11:22 AM, Gustavo A. R. Silva wrote:
Hi all,
On 07/22/2017 01:36 AM, Borislav Petkov wrote:
On Fri, Jul 21, 2017 at 10:08:12PM +0200, Julia Lawall
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b162c530d9c101381500e586fedb1340595a6ff
commit: 468138d78510688fb5476f98d23f11ac6a63229a binfmt_flat:
flat_{get,put}_addr_from_rp() should be able to fail
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b162c530d9c101381500e586fedb1340595a6ff
commit: 468138d78510688fb5476f98d23f11ac6a63229a binfmt_flat:
flat_{get,put}_addr_from_rp() should be able to fail
On Sun, 23 Jul 2017 08:20:30 +0800
kbuild test robot wrote:
> Hi Nicholas,
>
> FYI, the error/warning still remains.
FYI, I still suspect it is this bug
https://sourceware.org/bugzilla/show_bug.cgi?id=21017
If so, then I'm not sure if it can be worked around in Linux.
On Sun, 23 Jul 2017 08:20:30 +0800
kbuild test robot wrote:
> Hi Nicholas,
>
> FYI, the error/warning still remains.
FYI, I still suspect it is this bug
https://sourceware.org/bugzilla/show_bug.cgi?id=21017
If so, then I'm not sure if it can be worked around in Linux.
Thanks,
Nick
>
>
On Sat, 22 Jul 2017, Gustavo A. R. Silva wrote:
> Hi Julia, Borislav,
>
> On 07/22/2017 11:22 AM, Gustavo A. R. Silva wrote:
> > Hi all,
> >
> > On 07/22/2017 01:36 AM, Borislav Petkov wrote:
> > > On Fri, Jul 21, 2017 at 10:08:12PM +0200, Julia Lawall wrote:
> > > > Someone pointed out that
On Sat, 22 Jul 2017, Gustavo A. R. Silva wrote:
> Hi Julia, Borislav,
>
> On 07/22/2017 11:22 AM, Gustavo A. R. Silva wrote:
> > Hi all,
> >
> > On 07/22/2017 01:36 AM, Borislav Petkov wrote:
> > > On Fri, Jul 21, 2017 at 10:08:12PM +0200, Julia Lawall wrote:
> > > > Someone pointed out that
Hi Ian,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 96080f697786e0a30006fcbcc5b53f350fcb3e9f
commit: c7acec713d14c6ce8a20154f9dfda258d6bcad3b kernel.h: handle pointers to
arrays better in container_of()
date:
Hi Ian,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 96080f697786e0a30006fcbcc5b53f350fcb3e9f
commit: c7acec713d14c6ce8a20154f9dfda258d6bcad3b kernel.h: handle pointers to
arrays better in container_of()
date:
On Sat, Jul 22, 2017 at 08:38:57AM +0900, Akira Yokosawa wrote:
> On 2017/07/20 16:07:14 -0700, Paul E. McKenney wrote:
> > On Fri, Jul 21, 2017 at 07:52:03AM +0900, Akira Yokosawa wrote:
> >> On 2017/07/20 14:42:34 -0700, Paul E. McKenney wrote:
> [...]
> >>> For the compilers I know about at the
On Sat, Jul 22, 2017 at 08:38:57AM +0900, Akira Yokosawa wrote:
> On 2017/07/20 16:07:14 -0700, Paul E. McKenney wrote:
> > On Fri, Jul 21, 2017 at 07:52:03AM +0900, Akira Yokosawa wrote:
> >> On 2017/07/20 14:42:34 -0700, Paul E. McKenney wrote:
> [...]
> >>> For the compilers I know about at the
On Sat, Jul 22, 2017 at 2:44 PM, Rafael J. Wysocki wrote:
> On Saturday, July 22, 2017 12:47:53 AM Joel Fernandes wrote:
>> Currently the iowait_boost feature in schedutil makes the frequency go to max
>> on iowait wakeups. This feature was added to handle a case that Peter
On Sat, Jul 22, 2017 at 2:44 PM, Rafael J. Wysocki wrote:
> On Saturday, July 22, 2017 12:47:53 AM Joel Fernandes wrote:
>> Currently the iowait_boost feature in schedutil makes the frequency go to max
>> on iowait wakeups. This feature was added to handle a case that Peter
>> described where
Make iowait_boost and iowait_boost_max as unsigned int since its unit is kHz
and this is consistent with struct cpufreq_policy. Also change the local
variables in sugov_iowait_boost to match this.
Cc: Srinivas Pandruvada
Cc: Len Brown
Cc:
Make iowait_boost and iowait_boost_max as unsigned int since its unit is kHz
and this is consistent with struct cpufreq_policy. Also change the local
variables in sugov_iowait_boost to match this.
Cc: Srinivas Pandruvada
Cc: Len Brown
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
Cc: Ingo Molnar
Currently the iowait_boost feature in schedutil makes the frequency go to max
on iowait wakeups. This feature was added to handle a case that Peter
described where the throughput of operations involving continuous I/O requests
[1] is reduced due to running at a lower frequency, however the lower
Currently the iowait_boost feature in schedutil makes the frequency go to max
on iowait wakeups. This feature was added to handle a case that Peter
described where the throughput of operations involving continuous I/O requests
[1] is reduced due to running at a lower frequency, however the lower
On 2017/7/23 3:02, Cong Wang wrote:
> Hello,
>
> On Sat, Jul 22, 2017 at 2:55 AM, liujian (CE) wrote:
>> I also hit this issue with trinity test:
>>
>> The call trace:
>> [exception RIP: prb_retire_rx_blk_timer_expired+70]
>> RIP: 81633be6 RSP:
On 2017/7/23 3:02, Cong Wang wrote:
> Hello,
>
> On Sat, Jul 22, 2017 at 2:55 AM, liujian (CE) wrote:
>> I also hit this issue with trinity test:
>>
>> The call trace:
>> [exception RIP: prb_retire_rx_blk_timer_expired+70]
>> RIP: 81633be6 RSP: 8801bec03dc0 RFLAGS: 00010246
Hi Daniel,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 96080f697786e0a30006fcbcc5b53f350fcb3e9f
commit: dc11bae78529526605c5c45c369c9512fd012093 clocksource/drivers: Add
timer-of common init routine
date: 6
Hi Daniel,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 96080f697786e0a30006fcbcc5b53f350fcb3e9f
commit: dc11bae78529526605c5c45c369c9512fd012093 clocksource/drivers: Add
timer-of common init routine
date: 6
Tetsuo Handa wrote:
> Log is at http://I-love.SAKURA.ne.jp/tmp/serial-20170722.txt.xz .
Oops, I forgot to remove mmput_async() in Patch2. Below is updated result.
Though, situation (i.e. we can't tell without Patch1 whether we raced with
OOM_MMF_SKIP) is same.
Pat
Tetsuo Handa wrote:
> Log is at http://I-love.SAKURA.ne.jp/tmp/serial-20170722.txt.xz .
Oops, I forgot to remove mmput_async() in Patch2. Below is updated result.
Though, situation (i.e. we can't tell without Patch1 whether we raced with
OOM_MMF_SKIP) is same.
Pat
Hi Ryder,
[auto build test WARNING on pci/next]
[also build test WARNING on v4.13-rc1 next-20170721]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Ryder,
[auto build test WARNING on pci/next]
[also build test WARNING on v4.13-rc1 next-20170721]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Julia, Borislav,
On 07/22/2017 11:22 AM, Gustavo A. R. Silva wrote:
Hi all,
On 07/22/2017 01:36 AM, Borislav Petkov wrote:
On Fri, Jul 21, 2017 at 10:08:12PM +0200, Julia Lawall wrote:
Someone pointed out that the rule is probably not OK when the address of
the static variable is taken,
Hi Julia, Borislav,
On 07/22/2017 11:22 AM, Gustavo A. R. Silva wrote:
Hi all,
On 07/22/2017 01:36 AM, Borislav Petkov wrote:
On Fri, Jul 21, 2017 at 10:08:12PM +0200, Julia Lawall wrote:
Someone pointed out that the rule is probably not OK when the address of
the static variable is taken,
We have hit an apparent kernel bug where a signal is not interrupting a
futex, leading to a deadlock in our code. Here is the relevant strace
output just before it blocks (complete strace log is attached):
14069 set_robust_list(0x7f7b3e7ee9e0, 24
14061 futex(0x7f7b46721fd8,
We have hit an apparent kernel bug where a signal is not interrupting a
futex, leading to a deadlock in our code. Here is the relevant strace
output just before it blocks (complete strace log is attached):
14069 set_robust_list(0x7f7b3e7ee9e0, 24
14061 futex(0x7f7b46721fd8,
On Fri, Jul 14, 2017 at 03:12:43PM +0800, Wei Wang wrote:
> On 07/14/2017 04:19 AM, Michael S. Tsirkin wrote:
> > On Thu, Jul 13, 2017 at 03:42:35PM +0800, Wei Wang wrote:
> > > On 07/12/2017 09:56 PM, Michael S. Tsirkin wrote:
> > > > So the way I see it, there are several issues:
> > > >
> > >
On Fri, Jul 14, 2017 at 03:12:43PM +0800, Wei Wang wrote:
> On 07/14/2017 04:19 AM, Michael S. Tsirkin wrote:
> > On Thu, Jul 13, 2017 at 03:42:35PM +0800, Wei Wang wrote:
> > > On 07/12/2017 09:56 PM, Michael S. Tsirkin wrote:
> > > > So the way I see it, there are several issues:
> > > >
> > >
So it looks like that suspend/resume has actually always been broken on
hid-rmi. The fact it worked was a rather silly coincidence that was
relying on the HID device to already be opened upon resume. This means
that so long as anything was reading the /dev/input/eventX node for for
an RMI device,
So it looks like that suspend/resume has actually always been broken on
hid-rmi. The fact it worked was a rather silly coincidence that was
relying on the HID device to already be opened upon resume. This means
that so long as anything was reading the /dev/input/eventX node for for
an RMI device,
I think the ancillary data for #DB and #PF should be added to
kvm_queued_exception and plumbed through to where it's needed. Vector
number and error code are not sufficient to describe a #DB or #PF.
On Sat, Jul 22, 2017 at 5:29 PM, Wanpeng Li wrote:
> 2017-07-22 22:25
I think the ancillary data for #DB and #PF should be added to
kvm_queued_exception and plumbed through to where it's needed. Vector
number and error code are not sufficient to describe a #DB or #PF.
On Sat, Jul 22, 2017 at 5:29 PM, Wanpeng Li wrote:
> 2017-07-22 22:25 GMT+08:00 Jim Mattson :
>>
From: Wanpeng Li
When generating #PF VM-exit, check equality:
(PFEC & PFEC_MASK) == PFEC_MATCH
If there is equality, the 14 bit of exception bitmap is used to take decision
about generating #PF VM-exit. If there is inequality, inverted 14 bit is used.
Reported-by: Jim
From: Wanpeng Li
When generating #PF VM-exit, check equality:
(PFEC & PFEC_MASK) == PFEC_MATCH
If there is equality, the 14 bit of exception bitmap is used to take decision
about generating #PF VM-exit. If there is inequality, inverted 14 bit is used.
Reported-by: Jim Mattson
Cc: Paolo Bonzini
On Fri, Jul 21, 2017 at 02:12:12PM +0200, Jiri Olsa wrote:
> Make perf stat use group read if there are groups
> defined. The group read will get the values for all
> member of groups within a single syscall instead of
> calling read syscall for every event.
>
> We can see considerable less
On Fri, Jul 21, 2017 at 02:12:12PM +0200, Jiri Olsa wrote:
> Make perf stat use group read if there are groups
> defined. The group read will get the values for all
> member of groups within a single syscall instead of
> calling read syscall for every event.
>
> We can see considerable less
ze >>= 1;
break;
}
buf = cp;
}
sleep(2);
/* Will cause OOM due to overcommit */
for (i = 0; i < size; i += 4096)
buf[i] = 0;
pause();
return 0;
}
ze >>= 1;
break;
}
buf = cp;
}
sleep(2);
/* Will cause OOM due to overcommit */
for (i = 0; i < size; i += 4096)
buf[i] = 0;
pause();
return 0;
}
Hi Chen-Yu,
[auto build test ERROR on next-20170719]
[cannot apply to clk/clk-next robh/for-next linus/master v4.13-rc1 v4.12
v4.12-rc7 v4.13-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
Hi Chen-Yu,
[auto build test ERROR on next-20170719]
[cannot apply to clk/clk-next robh/for-next linus/master v4.13-rc1 v4.12
v4.12-rc7 v4.13-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
2017-07-22 22:25 GMT+08:00 Jim Mattson :
> On Fri, Jul 21, 2017 at 1:39 AM, Wanpeng Li wrote:
>> Hi Jim,
>> 2017-07-21 3:16 GMT+08:00 Jim Mattson :
>>> On Wed, Jul 19, 2017 at 7:31 PM, Wanpeng Li wrote:
Hi
2017-07-22 22:25 GMT+08:00 Jim Mattson :
> On Fri, Jul 21, 2017 at 1:39 AM, Wanpeng Li wrote:
>> Hi Jim,
>> 2017-07-21 3:16 GMT+08:00 Jim Mattson :
>>> On Wed, Jul 19, 2017 at 7:31 PM, Wanpeng Li wrote:
Hi Jim,
2017-07-19 2:47 GMT+08:00 Jim Mattson :
> Why do we expect the
Hi Nicholas,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b162c530d9c101381500e586fedb1340595a6ff
commit: 799c43415442414b1032580c47684cb709dfed6d kbuild: thin archives make
default for all archs
date: 3
Hi Nicholas,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4b162c530d9c101381500e586fedb1340595a6ff
commit: 799c43415442414b1032580c47684cb709dfed6d kbuild: thin archives make
default for all archs
date: 3
Hi Stephen,
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, June 19, 2017 5:59 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
Hi Stephen,
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, June 19, 2017 5:59 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
Hi Stephen,
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, June 19, 2017 4:48 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
Hi Stephen,
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, June 19, 2017 4:48 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
Hi Andrew,
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, June 19, 2017 4:53 AM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
Hi Andrew,
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, June 19, 2017 4:53 AM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
Hi Bo Yu,
> -Original Message-
> From: Bo Yu [mailto:tsu.y...@gmail.com]
> Sent: Monday, June 19, 2017 1:57 AM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org;
Hi Richard,
> -Original Message-
> From: Richard Cochran [mailto:richardcoch...@gmail.com]
> Sent: Sunday, June 18, 2017 5:45 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
Hi Richard,
> -Original Message-
> From: Richard Cochran [mailto:richardcoch...@gmail.com]
> Sent: Sunday, June 18, 2017 5:45 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
Hi Bo Yu,
> -Original Message-
> From: Bo Yu [mailto:tsu.y...@gmail.com]
> Sent: Monday, June 19, 2017 1:40 AM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org;
Hi Bo Yu,
> -Original Message-
> From: Bo Yu [mailto:tsu.y...@gmail.com]
> Sent: Monday, June 19, 2017 1:40 AM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org;
Hi Bo Yu,
> -Original Message-
> From: Bo Yu [mailto:tsu.y...@gmail.com]
> Sent: Monday, June 19, 2017 1:18 AM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org;
Hi Bo Yu,
> -Original Message-
> From: Bo Yu [mailto:tsu.y...@gmail.com]
> Sent: Monday, June 19, 2017 1:18 AM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org;
Allow for MAINTAINERS to become a directory and if it is,
read all the files in the directory for maintained sections.
Miscellanea:
o Create a read_maintainer_file subroutine from the existing code
o Test only the existence of MAINTAINERS, not whether it's a file
Signed-off-by: Joe Perches
Allow for MAINTAINERS to become a directory and if it is,
read all the files in the directory for maintained sections.
Miscellanea:
o Create a read_maintainer_file subroutine from the existing code
o Test only the existence of MAINTAINERS, not whether it's a file
Signed-off-by: Joe Perches
---
Hi Andrew,
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Sunday, June 18, 2017 4:02 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org;
Hi Andrew,
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Sunday, June 18, 2017 4:02 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org;
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Sunday, June 18, 2017 3:53 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Linuxarm
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Sunday, June 18, 2017 3:53 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Linuxarm
Hi Andrew,
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Saturday, June 17, 2017 8:46 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
Hi Andrew,
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Saturday, June 17, 2017 8:46 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
Hi Andrew
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Saturday, June 17, 2017 6:54 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
Hi Andrew
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Saturday, June 17, 2017 6:54 PM
> To: Salil Mehta
> Cc: da...@davemloft.net; Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
>
On Fri, Jul 21, 2017 at 01:02:50PM -0700, David Carrillo-Cisneros wrote:
> On Fri, Jul 21, 2017 at 12:44 AM, Jiri Olsa wrote:
> > On Thu, Jul 20, 2017 at 10:11:57PM -0700, David Carrillo-Cisneros wrote:
> >> Fixes bug noted by Jiri in https://lkml.org/lkml/2017/6/13/755 and
On Fri, Jul 21, 2017 at 01:02:50PM -0700, David Carrillo-Cisneros wrote:
> On Fri, Jul 21, 2017 at 12:44 AM, Jiri Olsa wrote:
> > On Thu, Jul 20, 2017 at 10:11:57PM -0700, David Carrillo-Cisneros wrote:
> >> Fixes bug noted by Jiri in https://lkml.org/lkml/2017/6/13/755 and caused
> >> by commit
Hi Arnaldo and Taeung,
(+ Andi)
On Fri, Jul 21, 2017 at 11:47:48AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jul 20, 2017 at 06:36:55AM +0900, Taeung Song escreveu:
> > +++ b/tools/perf/builtin-annotate.c
> > @@ -177,14 +177,12 @@ static int perf_evsel__add_sample(struct perf_evsel
> >
Hi Arnaldo and Taeung,
(+ Andi)
On Fri, Jul 21, 2017 at 11:47:48AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jul 20, 2017 at 06:36:55AM +0900, Taeung Song escreveu:
> > +++ b/tools/perf/builtin-annotate.c
> > @@ -177,14 +177,12 @@ static int perf_evsel__add_sample(struct perf_evsel
> >
This patch adds the support of IMP (Integrated Management Processor)
command interface to the HNS3 driver.
Each PF/VF has support of CQP(Command Queue Pair) ring interface.
Each CQP consis of send queue CSQ and receive queue CRQ.
There are various commands a PF/VF may support, like for Flow Table
On Sun, Jul 23, 2017 at 12:13 AM, Andy Shevchenko
wrote:
> On Sun, Jul 23, 2017 at 1:02 AM, Rafael J. Wysocki wrote:
>> On Saturday, July 22, 2017 04:53:52 AM Andy Shevchenko wrote:
>>> On Sat, Jul 22, 2017 at 1:25 AM, Rafael J. Wysocki
This patch adds the support of IMP (Integrated Management Processor)
command interface to the HNS3 driver.
Each PF/VF has support of CQP(Command Queue Pair) ring interface.
Each CQP consis of send queue CSQ and receive queue CRQ.
There are various commands a PF/VF may support, like for Flow Table
On Sun, Jul 23, 2017 at 12:13 AM, Andy Shevchenko
wrote:
> On Sun, Jul 23, 2017 at 1:02 AM, Rafael J. Wysocki wrote:
>> On Saturday, July 22, 2017 04:53:52 AM Andy Shevchenko wrote:
>>> On Sat, Jul 22, 2017 at 1:25 AM, Rafael J. Wysocki
>>> wrote:
>>> > On Tuesday, July 18, 2017 06:04:19 PM
This patch adds the support of the HNAE3 (Hisilicon Network
Acceleration Engine 3) framework support to the HNS3 driver.
Framework facilitates clients like ENET(HNS3 Ethernet Driver), RoCE
and user-space Ethernet drivers (like ODP etc.) to register with HNAE3
devices and their associated
This patch adds the support of the HNAE3 (Hisilicon Network
Acceleration Engine 3) framework support to the HNS3 driver.
Framework facilitates clients like ENET(HNS3 Ethernet Driver), RoCE
and user-space Ethernet drivers (like ODP etc.) to register with HNAE3
devices and their associated
This patch adds the support of MDIO bus interface for HNS3 driver.
Code provides various interfaces to start and stop the PHY layer
and to read and write the MDIO bus or PHY.
Signed-off-by: Daode Huang
Signed-off-by: lipeng
Signed-off-by: Salil
On Sun, Jul 23, 2017 at 1:02 AM, Rafael J. Wysocki wrote:
> On Saturday, July 22, 2017 04:53:52 AM Andy Shevchenko wrote:
>> On Sat, Jul 22, 2017 at 1:25 AM, Rafael J. Wysocki
>> wrote:
>> > On Tuesday, July 18, 2017 06:04:19 PM Andy Shevchenko wrote:
>>
This patch adds the support of MDIO bus interface for HNS3 driver.
Code provides various interfaces to start and stop the PHY layer
and to read and write the MDIO bus or PHY.
Signed-off-by: Daode Huang
Signed-off-by: lipeng
Signed-off-by: Salil Mehta
Signed-off-by: Yisen Zhuang
---
Patch V4:
On Sun, Jul 23, 2017 at 1:02 AM, Rafael J. Wysocki wrote:
> On Saturday, July 22, 2017 04:53:52 AM Andy Shevchenko wrote:
>> On Sat, Jul 22, 2017 at 1:25 AM, Rafael J. Wysocki
>> wrote:
>> > On Tuesday, July 18, 2017 06:04:19 PM Andy Shevchenko wrote:
>> > I'd rather do it at the time when
This patch adds the support of Hisilicon Network Subsystem Accceleration
Engine and common operations to access it. This layer provides access to the
hardware configuration, hardware statistics. This layer is also
responsible for triggering the initialization of the PHY layer through
the below
This patch adds the support of Hisilicon Network Subsystem Accceleration
Engine and common operations to access it. This layer provides access to the
hardware configuration, hardware statistics. This layer is also
responsible for triggering the initialization of the PHY layer through
the below
This patch adds the support of the Ethtool interface to
the HNS3 Ethernet driver. Various commands to read the
statistics, configure the offloading, loopback selftest etc.
are supported.
Signed-off-by: Daode Huang
Signed-off-by: lipeng
This patch adds the support of the Ethtool interface to
the HNS3 Ethernet driver. Various commands to read the
statistics, configure the offloading, loopback selftest etc.
are supported.
Signed-off-by: Daode Huang
Signed-off-by: lipeng
Signed-off-by: Salil Mehta
Signed-off-by: Yisen Zhuang
THis patch adds the support of the Scheduling and Shaping
functionalities during the transmit leg. This also adds the
support of Pause at MAC level. (Pause at per-priority level
shall be added later along with the DCB feature).
Hardware as such consists of two types of cofiguration of 6 level
THis patch adds the support of the Scheduling and Shaping
functionalities during the transmit leg. This also adds the
support of Pause at MAC level. (Pause at per-priority level
shall be added later along with the DCB feature).
Hardware as such consists of two types of cofiguration of 6 level
This patch updates the MAINTAINERS file with HNS3 Ethernet driver
maintainers names and other details. This also introduces the new
Makefiles required to build the HNS3 Ethernet driver and updates
the existing Kconfig file in the hisilicon folder.
Signed-off-by: Salil Mehta
This patch updates the MAINTAINERS file with HNS3 Ethernet driver
maintainers names and other details. This also introduces the new
Makefiles required to build the HNS3 Ethernet driver and updates
the existing Kconfig file in the hisilicon folder.
Signed-off-by: Salil Mehta
---
Patch V3:
On Saturday, July 22, 2017 04:53:52 AM Andy Shevchenko wrote:
> On Sat, Jul 22, 2017 at 1:25 AM, Rafael J. Wysocki wrote:
> > On Tuesday, July 18, 2017 06:04:19 PM Andy Shevchenko wrote:
> >> Some platform might take care of legacy devices on theirs own.
> >> Let's allow them
On Saturday, July 22, 2017 04:53:52 AM Andy Shevchenko wrote:
> On Sat, Jul 22, 2017 at 1:25 AM, Rafael J. Wysocki wrote:
> > On Tuesday, July 18, 2017 06:04:19 PM Andy Shevchenko wrote:
> >> Some platform might take care of legacy devices on theirs own.
> >> Let's allow them to do that by
This patch adds the support of Hisilicon Network Subsystem 3
Ethernet driver to hip08 family of SoCs.
This driver includes basic Rx/Tx functionality. It also includes
the client registration code with the HNAE3(Hisilicon Network
Acceleration Engine 3) framework.
This work provides the initial
This patch adds the support of Hisilicon Network Subsystem 3
Ethernet driver to hip08 family of SoCs.
This driver includes basic Rx/Tx functionality. It also includes
the client registration code with the HNAE3(Hisilicon Network
Acceleration Engine 3) framework.
This work provides the initial
This patch-set contains the support of the HNS3 (Hisilicon Network Subsystem 3)
Ethernet driver for hip08 family of SoCs and future upcoming SoCs.
Hisilicon's new hip08 SoCs have integrated ethernet based on PCI Express and
hence there was a need of new driver over the previous HNS driver which
1 - 100 of 305 matches
Mail list logo