From: Keerthy
The 32k clocksource is NONSTOP for non-am43 SoCs. Hence
add the flag for all the other SoCs.
Reported-by: Tony Lindgren
Signed-off-by: Keerthy
Acked-by: Tony Lindgren
Signed-off-by: Daniel Lezcano
---
drivers/clocksource/timer-ti-32k.c | 3 +++
1 file changed, 3 insertions(+)
From: Keerthy
The 32k clocksource is NONSTOP for non-am43 SoCs. Hence
add the flag for all the other SoCs.
Reported-by: Tony Lindgren
Signed-off-by: Keerthy
Acked-by: Tony Lindgren
Signed-off-by: Daniel Lezcano
---
drivers/clocksource/timer-ti-32k.c | 3 +++
1 file changed, 3 insertions(+)
From: Tao Ren
Currently, the aspeed MATCH1 register is updated to in set_next_event handler, with the assumption that COUNT
register value is preserved when the timer is disabled and it continues
decrementing after the timer is enabled. But the assumption is wrong:
RELOAD register is loaded
From: Tao Ren
Currently, the aspeed MATCH1 register is updated to in set_next_event handler, with the assumption that COUNT
register value is preserved when the timer is disabled and it continues
decrementing after the timer is enabled. But the assumption is wrong:
RELOAD register is loaded
Thomas, Ingo,
This pull request for clockevents / clocksource contains two fixes and
is based on tip/timers/urgent:
- Add the CLOCK_SOURCE_SUSPEND_NONSTOP for non-am43 SoCs (Keerthy)
- Fix set_next_event handler for the fttmr010 (Tao Ren)
Thanks !
-- Daniel
The following changes
Thomas, Ingo,
This pull request for clockevents / clocksource contains two fixes and
is based on tip/timers/urgent:
- Add the CLOCK_SOURCE_SUSPEND_NONSTOP for non-am43 SoCs (Keerthy)
- Fix set_next_event handler for the fttmr010 (Tao Ren)
Thanks !
-- Daniel
The following changes
Hi all,
Changes since 20180921:
Dropped trees: xarray, ida (temporarily)
The bpf-next tree gained a conflict against Linus' tree.
The staging tree gained a conflict against the jc_docs tree.
The userns tree gained conflicts against the tip tree.
The akpm-current tree gained a conflict
Hi all,
Changes since 20180921:
Dropped trees: xarray, ida (temporarily)
The bpf-next tree gained a conflict against Linus' tree.
The staging tree gained a conflict against the jc_docs tree.
The userns tree gained conflicts against the tip tree.
The akpm-current tree gained a conflict
On Mon, Sep 24, 2018 at 10:05:55AM +0530, Silesh C V wrote:
> Some drivers need to find the device on a bus having a specific firmware
> node. Currently, such drivers have their own implementations to do this.
> Provide a helper similar to bus_find_device_by_name so that each driver
> does not
On Mon, Sep 24, 2018 at 10:05:55AM +0530, Silesh C V wrote:
> Some drivers need to find the device on a bus having a specific firmware
> node. Currently, such drivers have their own implementations to do this.
> Provide a helper similar to bus_find_device_by_name so that each driver
> does not
On Mon, Sep 24, 2018 at 12:50:16PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in:
>
> Documentation/filesystems/00-INDEX
>
> between commit:
>
> a7ddcea58ae2 ("Drop all 00-INDEX files from Documentation/")
>
> from the jc_docs
On Mon, Sep 24, 2018 at 12:50:16PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in:
>
> Documentation/filesystems/00-INDEX
>
> between commit:
>
> a7ddcea58ae2 ("Drop all 00-INDEX files from Documentation/")
>
> from the jc_docs
While sending patches around, Joachim Eastwood was Cc'ed but I got an error
its mailbox was full and the mail can not be delivered which makes me think
there is no body at the other end of the line.
After doing some statistics, it appears the latest commit as author/commiter
is:
commit
While sending patches around, Joachim Eastwood was Cc'ed but I got an error
its mailbox was full and the mail can not be delivered which makes me think
there is no body at the other end of the line.
After doing some statistics, it appears the latest commit as author/commiter
is:
commit
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/arm64/Kconfig
between commit:
8a695a587333 ("arm64: Kconfig: Remove ARCH_HAS_HOLES_MEMORYMODEL")
from the arm64 tree and commit:
e1405baa7db1 ("arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID")
from
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/arm64/Kconfig
between commit:
8a695a587333 ("arm64: Kconfig: Remove ARCH_HAS_HOLES_MEMORYMODEL")
from the arm64 tree and commit:
e1405baa7db1 ("arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID")
from
Some drivers need to find the device on a bus having a specific firmware
node. Currently, such drivers have their own implementations to do this.
Provide a helper similar to bus_find_device_by_name so that each driver
does not have to reinvent this.
Signed-off-by: Silesh C V
---
Some drivers need to find the device on a bus having a specific firmware
node. Currently, such drivers have their own implementations to do this.
Provide a helper similar to bus_find_device_by_name so that each driver
does not have to reinvent this.
Signed-off-by: Silesh C V
---
The macro CLOCKSOURCE_OF_DECLARE was renamed more TIMER_OF_DECLARE, and we
kept an alias CLOCKSOURCE_OF_DECLARE in order to smooth the transition for
drivers.
This change was done 1.5 year ago, we can reasonably remove this backward
compatible macro as it is no longer used anywhere.
The macro CLOCKSOURCE_OF_DECLARE was renamed more TIMER_OF_DECLARE, and we
kept an alias CLOCKSOURCE_OF_DECLARE in order to smooth the transition for
drivers.
This change was done 1.5 year ago, we can reasonably remove this backward
compatible macro as it is no longer used anywhere.
> They're basically the same concept, it's a subtle difference.
>
> FRMR = Fast Register Memory Region
> FRWR = Fast Register Work Request
>
> The memory region is the mr itself, this is created early on.
>
> The work request is built when actually binding the physical
> pages to the region,
> They're basically the same concept, it's a subtle difference.
>
> FRMR = Fast Register Memory Region
> FRWR = Fast Register Work Request
>
> The memory region is the mr itself, this is created early on.
>
> The work request is built when actually binding the physical
> pages to the region,
On 9/23/2018 2:24 PM, Stefan Metzmacher wrote:
Hi Tom,
I just tested that setting:
mr->iova &= (PAGE_SIZE - 1);
mr->iova |= 0x;
after the ib_map_mr_sg() and before doing the IB_WR_REG_MR, seems to
work.
Good! As you know, we were concerned about it after seeing that
the
On 9/23/2018 2:24 PM, Stefan Metzmacher wrote:
Hi Tom,
I just tested that setting:
mr->iova &= (PAGE_SIZE - 1);
mr->iova |= 0x;
after the ib_map_mr_sg() and before doing the IB_WR_REG_MR, seems to
work.
Good! As you know, we were concerned about it after seeing that
the
Rob Herring writes:
> On Thu, Sep 20, 2018 at 4:18 AM Stephen Rothwell
> wrote:
>> On Thu, 20 Sep 2018 21:10:08 +1000 Stephen Rothwell
>> wrote:
>> > On Thu, 20 Sep 2018 20:37:37 +1000 Michael Ellerman
>> > wrote:
>> > > Oodles of:
>> > >
>> > > # < make -s -j 48 ARCH=arm64
>> > >
Rob Herring writes:
> On Thu, Sep 20, 2018 at 4:18 AM Stephen Rothwell
> wrote:
>> On Thu, 20 Sep 2018 21:10:08 +1000 Stephen Rothwell
>> wrote:
>> > On Thu, 20 Sep 2018 20:37:37 +1000 Michael Ellerman
>> > wrote:
>> > > Oodles of:
>> > >
>> > > # < make -s -j 48 ARCH=arm64
>> > >
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in:
arch/x86/kernel/traps.c
between commits:
76dee4a72849 ("x86/kprobes: Inline kprobe_exceptions_notify() into
do_general_protection()")
81fd9c18444e ("x86/fault: Plumb error code and fault address through to fault
Hi Eric,
Today's linux-next merge of the userns tree got a conflict in:
arch/x86/kernel/traps.c
between commits:
76dee4a72849 ("x86/kprobes: Inline kprobe_exceptions_notify() into
do_general_protection()")
81fd9c18444e ("x86/fault: Plumb error code and fault address through to fault
Dear Well Wishers,
Greetings to all of you and we Thank you, who have work with my late brother
before in various capacities during his term as the UN Sec General and after,
once again on behalf of the entire family of Late Kofi Annan, we thank you all
for all the support and comfort you show
Dear Well Wishers,
Greetings to all of you and we Thank you, who have work with my late brother
before in various capacities during his term as the UN Sec General and after,
once again on behalf of the entire family of Late Kofi Annan, we thank you all
for all the support and comfort you show
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in:
Documentation/filesystems/00-INDEX
between commit:
a7ddcea58ae2 ("Drop all 00-INDEX files from Documentation/")
from the jc_docs tree and commit:
a779df303b05 ("Documentation: filesystems: remove reminiscences of
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in:
Documentation/filesystems/00-INDEX
between commit:
a7ddcea58ae2 ("Drop all 00-INDEX files from Documentation/")
from the jc_docs tree and commit:
a779df303b05 ("Documentation: filesystems: remove reminiscences of
On Sun, Sep 23, 2018 at 7:54 PM Paul E. McKenney wrote:
>
> On Sun, Sep 23, 2018 at 07:30:30PM -0400, Joel Fernandes wrote:
> > Hi Paul,
> >
> > I was parsing the Data-Structures document and had a question about
> > the following "Important note" text.
> >
> > Could it be clarified in the below
On Sun, Sep 23, 2018 at 7:54 PM Paul E. McKenney wrote:
>
> On Sun, Sep 23, 2018 at 07:30:30PM -0400, Joel Fernandes wrote:
> > Hi Paul,
> >
> > I was parsing the Data-Structures document and had a question about
> > the following "Important note" text.
> >
> > Could it be clarified in the below
On 13/09/2018 13:30, Alexandre Belloni wrote:
> Add a driver for the Atmel Timer Counter Blocks. This driver provides a
> clocksource and two clockevent devices.
>
> One of the clockevent device is linked to the clocksource counter and so it
> will run at the same frequency. This will be used
On 13/09/2018 13:30, Alexandre Belloni wrote:
> Add a driver for the Atmel Timer Counter Blocks. This driver provides a
> clocksource and two clockevent devices.
>
> One of the clockevent device is linked to the clocksource counter and so it
> will run at the same frequency. This will be used
On Fri, Sep 21, 2018 at 05:42:00PM -0600, Shuah Khan wrote:
> Hi Jerry,
>
> Thanks for the patch. A few comments below:
Replies inline.
>
> On 09/21/2018 04:55 PM, Jerry Hoemann wrote:
> > Add command line arguments to call ioctl WDIOC_GETTIMEOUT,
> > WDIOC_GETPRETIMEOUT and
On Fri, Sep 21, 2018 at 05:42:00PM -0600, Shuah Khan wrote:
> Hi Jerry,
>
> Thanks for the patch. A few comments below:
Replies inline.
>
> On 09/21/2018 04:55 PM, Jerry Hoemann wrote:
> > Add command line arguments to call ioctl WDIOC_GETTIMEOUT,
> > WDIOC_GETPRETIMEOUT and
Due to the electrical design of the A/DC circuits on LEGO MINDSTORMS EV3,
if we are reading analog values as fast as possible (i.e. using DMA to
service the SPI) the A/DC chip will read incorrect values - as much as
0.1V off when the SPI is running at 10MHz. (This has to do with the
capacitor
Due to the electrical design of the A/DC circuits on LEGO MINDSTORMS EV3,
if we are reading analog values as fast as possible (i.e. using DMA to
service the SPI) the A/DC chip will read incorrect values - as much as
0.1V off when the SPI is running at 10MHz. (This has to do with the
capacitor
On Sat, Sep 22, 2018 at 08:58:34AM +1000, Stephen Rothwell wrote:
> Hi Liviu,
Hi Stephen,
>
> Commit
>
> fd75f5726f65 ("drm/mali-dp: Implement plane alpha and pixel blend on
> malidp")
>
> is missing a Signed-off-by from its committer.
My bad, I cherry picked-it from a staging tree and
On Sat, Sep 22, 2018 at 08:58:34AM +1000, Stephen Rothwell wrote:
> Hi Liviu,
Hi Stephen,
>
> Commit
>
> fd75f5726f65 ("drm/mali-dp: Implement plane alpha and pixel blend on
> malidp")
>
> is missing a Signed-off-by from its committer.
My bad, I cherry picked-it from a staging tree and
On Wed, Sep 19, 2018 at 05:38:51PM -0700, Vinod wrote:
>On 15-09-18, 01:34, Sasha Levin wrote:
>> From: Andy Shevchenko
>>
>> [ Upstream commit 2abc66cd499aa16876e45c6438788902f7d1ce22 ]
>>
>> It appears that the driver misses the support of dmaengine_terminate_sync().
>> Since many of callers
On Wed, Sep 19, 2018 at 05:38:51PM -0700, Vinod wrote:
>On 15-09-18, 01:34, Sasha Levin wrote:
>> From: Andy Shevchenko
>>
>> [ Upstream commit 2abc66cd499aa16876e45c6438788902f7d1ce22 ]
>>
>> It appears that the driver misses the support of dmaengine_terminate_sync().
>> Since many of callers
On Sun, Sep 23, 2018 at 07:31:37PM -0400, Joel Fernandes wrote:
> On Sun, Sep 23, 2018 at 7:30 PM Joel Fernandes wrote:
> >
> > Hi Paul,
> >
> > I was parsing the Data-Structures document and had a question about
> > the following "Important note" text.
> >
> > Could it be clarified in the below
On Sun, Sep 23, 2018 at 07:31:37PM -0400, Joel Fernandes wrote:
> On Sun, Sep 23, 2018 at 7:30 PM Joel Fernandes wrote:
> >
> > Hi Paul,
> >
> > I was parsing the Data-Structures document and had a question about
> > the following "Important note" text.
> >
> > Could it be clarified in the below
On Sun, Sep 23, 2018 at 07:30:30PM -0400, Joel Fernandes wrote:
> Hi Paul,
>
> I was parsing the Data-Structures document and had a question about
> the following "Important note" text.
>
> Could it be clarified in the below text better why "remaining
> callbacks are placed back on the
On Sun, Sep 23, 2018 at 07:30:30PM -0400, Joel Fernandes wrote:
> Hi Paul,
>
> I was parsing the Data-Structures document and had a question about
> the following "Important note" text.
>
> Could it be clarified in the below text better why "remaining
> callbacks are placed back on the
On Sun, Sep 23, 2018 at 7:30 PM Joel Fernandes wrote:
>
> Hi Paul,
>
> I was parsing the Data-Structures document and had a question about
> the following "Important note" text.
>
> Could it be clarified in the below text better why "remaining
> callbacks are placed back on the RCU_DONE_TAIL
On Sun, Sep 23, 2018 at 7:30 PM Joel Fernandes wrote:
>
> Hi Paul,
>
> I was parsing the Data-Structures document and had a question about
> the following "Important note" text.
>
> Could it be clarified in the below text better why "remaining
> callbacks are placed back on the RCU_DONE_TAIL
Hi Paul,
I was parsing the Data-Structures document and had a question about
the following "Important note" text.
Could it be clarified in the below text better why "remaining
callbacks are placed back on the RCU_DONE_TAIL segment", is a reason
for not depending on ->head for determining if no
Hi Paul,
I was parsing the Data-Structures document and had a question about
the following "Important note" text.
Could it be clarified in the below text better why "remaining
callbacks are placed back on the RCU_DONE_TAIL segment", is a reason
for not depending on ->head for determining if no
On Sun, Sep 23, 2018 at 11:45:17PM +0100, David Howells wrote:
> Christian Brauner wrote:
>
> > Of course, I'm not sure what the reasons for all of the other arguments to
> > this function are since it's not yet implemented.
>
> Well, dfd, path and atflags are pretty standard. atflags conveys
On Sun, Sep 23, 2018 at 11:45:17PM +0100, David Howells wrote:
> Christian Brauner wrote:
>
> > Of course, I'm not sure what the reasons for all of the other arguments to
> > this function are since it's not yet implemented.
>
> Well, dfd, path and atflags are pretty standard. atflags conveys
From: Colin Ian King
Trivial fix to spelling mistake in dbg_verbose message
Signed-off-by: Colin Ian King
---
drivers/memstick/core/ms_block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memstick/core/ms_block.c b/drivers/memstick/core/ms_block.c
index
From: Colin Ian King
Trivial fix to spelling mistake in dbg_verbose message
Signed-off-by: Colin Ian King
---
drivers/memstick/core/ms_block.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memstick/core/ms_block.c b/drivers/memstick/core/ms_block.c
index
Christian Brauner wrote:
> Of course, I'm not sure what the reasons for all of the other arguments to
> this function are since it's not yet implemented.
Well, dfd, path and atflags are pretty standard. atflags conveys things like
AT_EMPTY_PATH or AT_SYMLINK_NOFOLLOW and dfd conveys a file
Christian Brauner wrote:
> Of course, I'm not sure what the reasons for all of the other arguments to
> this function are since it's not yet implemented.
Well, dfd, path and atflags are pretty standard. atflags conveys things like
AT_EMPTY_PATH or AT_SYMLINK_NOFOLLOW and dfd conveys a file
From: Colin Ian King
Trivial fix to spelling mistake in dev_err messages and comments
Signed-off-by: Colin Ian King
---
drivers/soc/ti/knav_dma.c | 4 ++--
drivers/soc/ti/knav_qmss.h | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/ti/knav_dma.c
From: Colin Ian King
Trivial fix to spelling mistake in dev_err messages and comments
Signed-off-by: Colin Ian King
---
drivers/soc/ti/knav_dma.c | 4 ++--
drivers/soc/ti/knav_qmss.h | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/ti/knav_dma.c
On 09/23/18 17:19, Thomas Gleixner wrote:
What is that value for the second Athlon core (seems extremely bogus), and
would/could that be the reason for the schedule_timeouts? This bogus value
also shows up in the bootup log when the second core is activated. Seems to
be AMD specific, as
On 09/23/18 17:19, Thomas Gleixner wrote:
What is that value for the second Athlon core (seems extremely bogus), and
would/could that be the reason for the schedule_timeouts? This bogus value
also shows up in the bootup log when the second core is activated. Seems to
be AMD specific, as
On Tue, Sep 11, 2018 at 01:29:32PM +, Song Liu wrote:
SNIP
> >>>
> >>> jirka
> >>
> >> I am not sure I am following. The pmu is disabled when we call
> >> event_pmu_add(). Why do we need to read before calling pmu->add()?
> >> And this is the first added dup event for this master, so we
On Tue, Sep 11, 2018 at 01:29:32PM +, Song Liu wrote:
SNIP
> >>>
> >>> jirka
> >>
> >> I am not sure I am following. The pmu is disabled when we call
> >> event_pmu_add(). Why do we need to read before calling pmu->add()?
> >> And this is the first added dup event for this master, so we
Hi Jakub,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 6bf4ca7fbc85d80446ac01c0d1d77db4d91a6d84
commit: 0c26159352ba1cdc5a8c8d74131cc19cdfdf9371 nfp: bpf: xdp_adjust_tail
support
date: 7 weeks ago
config:
Hi Jakub,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 6bf4ca7fbc85d80446ac01c0d1d77db4d91a6d84
commit: 0c26159352ba1cdc5a8c8d74131cc19cdfdf9371 nfp: bpf: xdp_adjust_tail
support
date: 7 weeks ago
config:
Hi Tom,
>> I just tested that setting:
>>
>> mr->iova &= (PAGE_SIZE - 1);
>> mr->iova |= 0x;
>>
>> after the ib_map_mr_sg() and before doing the IB_WR_REG_MR, seems to
>> work.
>
> Good! As you know, we were concerned about it after seeing that
> the ib_dma_map_sg() code was
Hi Tom,
>> I just tested that setting:
>>
>> mr->iova &= (PAGE_SIZE - 1);
>> mr->iova |= 0x;
>>
>> after the ib_map_mr_sg() and before doing the IB_WR_REG_MR, seems to
>> work.
>
> Good! As you know, we were concerned about it after seeing that
> the ib_dma_map_sg() code was
On Sun, 23 Sep 2018, Rob Prowel wrote:
> Sep 23 01:51:28 files kernel: INFO: rcu_sched detected stalls on CPUs/tasks:
> Sep 23 01:51:28 files kernel: 1-...!: (0 ticks this GP) idle=27c/0/0
> softirq=35425/35425 fqs=0
> Sep 23 01:51:28 files kernel: (detected by 0, t=60009 jiffies,
On Sun, 23 Sep 2018, Rob Prowel wrote:
> Sep 23 01:51:28 files kernel: INFO: rcu_sched detected stalls on CPUs/tasks:
> Sep 23 01:51:28 files kernel: 1-...!: (0 ticks this GP) idle=27c/0/0
> softirq=35425/35425 fqs=0
> Sep 23 01:51:28 files kernel: (detected by 0, t=60009 jiffies,
From: Dexuan Cui
We don't need to call process_ib_ipinfo() if message->kvp_hdr.operation is
KVP_OP_GET_IP_INFO in kvp_send_key(), because here we just need to pass on
the op code from the host to the userspace; when the userspace returns
the info requested by the host, we pass the info on to the
From: Dexuan Cui
We don't need to call process_ib_ipinfo() if message->kvp_hdr.operation is
KVP_OP_GET_IP_INFO in kvp_send_key(), because here we just need to pass on
the op code from the host to the userspace; when the userspace returns
the info requested by the host, we pass the info on to the
From: Dexuan Cui
No functional change.
Added descriptions for some parameters.
Fixed some typos.
Removed some out-of-date comments.
Signed-off-by: Dexuan Cui
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Signed-off-by: K. Y.
From: Dexuan Cui
No functional change.
Added descriptions for some parameters.
Fixed some typos.
Removed some out-of-date comments.
Signed-off-by: Dexuan Cui
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Signed-off-by: K. Y.
From: Dexuan Cui
A cpumask structure on the stack can cause a warning with
CONFIG_NR_CPUS=8192 (e.g. Ubuntu 16.04 and 18.04 use this):
drivers/hv//channel_mgmt.c: In function ‘init_vp_index’:
drivers/hv//channel_mgmt.c:702:1: warning: the frame size of 1032 bytes
is larger than 1024 bytes
From: Dexuan Cui
A cpumask structure on the stack can cause a warning with
CONFIG_NR_CPUS=8192 (e.g. Ubuntu 16.04 and 18.04 use this):
drivers/hv//channel_mgmt.c: In function ‘init_vp_index’:
drivers/hv//channel_mgmt.c:702:1: warning: the frame size of 1032 bytes
is larger than 1024 bytes
From: Dexuan Cui
No functional change.
Signed-off-by: Dexuan Cui
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_kvp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/hv/hv_kvp.c
From: Dexuan Cui
No functional change.
Signed-off-by: Dexuan Cui
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/hv_kvp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/hv/hv_kvp.c
From: "K. Y. Srinivasan"
Miscellaneous fixes.
Dexuan Cui (4):
Drivers: hv: vmbus: Fix the descriptions of some function parameters
Drivers: hv: kvp: Fix the indentation of some "break" statements
Drivers: hv: kvp: Fix two "this statement may fall through" warnings
Drivers: hv: vmbus:
From: "K. Y. Srinivasan"
Miscellaneous fixes.
Dexuan Cui (4):
Drivers: hv: vmbus: Fix the descriptions of some function parameters
Drivers: hv: kvp: Fix the indentation of some "break" statements
Drivers: hv: kvp: Fix two "this statement may fall through" warnings
Drivers: hv: vmbus:
Most of you know that I have spent more than a quarter century
analyzing the folkways of the hacker culture as a historian,
ethnographer, and game theorist. That analysis has had large
consequences, including a degree of business and mainstream acceptance
of the open source way that was difficult
Most of you know that I have spent more than a quarter century
analyzing the folkways of the hacker culture as a historian,
ethnographer, and game theorist. That analysis has had large
consequences, including a degree of business and mainstream acceptance
of the open source way that was difficult
I updated to a 3.7ghz cpu some time ago. XP required re-authentication,
but had no further suport so it did not work. Despite having purchased
the pro version (1000nok)I had to trick myself into the system again.
A few months later the mouseport started crashing the PC. I installed a
PCI-e
I updated to a 3.7ghz cpu some time ago. XP required re-authentication,
but had no further suport so it did not work. Despite having purchased
the pro version (1000nok)I had to trick myself into the system again.
A few months later the mouseport started crashing the PC. I installed a
PCI-e
Dear Sir/Madam,
My name is Rybak Ahmed from Syria. I am a miner and i wish to introduce my
Gold/Diamonds funds which I and my partner sold. Because of the constant war
going on in our country my partner and his family are all dead.Hence i take
this upon myself to find trustworthy partners
Dear Sir/Madam,
My name is Rybak Ahmed from Syria. I am a miner and i wish to introduce my
Gold/Diamonds funds which I and my partner sold. Because of the constant war
going on in our country my partner and his family are all dead.Hence i take
this upon myself to find trustworthy partners
This device reports SDHCI_CLOCK_INT_STABLE even though it's not
ready to take SDHCI_CLOCK_CARD_EN. The symptom is that reading
SDHCI_CLOCK_CONTROL after enabling the clock shows absence of the
bit from the register (e.g. expecting 0xfa07 = 0xfa03 |
SDHCI_CLOCK_CARD_EN but only observed the
This device reports SDHCI_CLOCK_INT_STABLE even though it's not
ready to take SDHCI_CLOCK_CARD_EN. The symptom is that reading
SDHCI_CLOCK_CONTROL after enabling the clock shows absence of the
bit from the register (e.g. expecting 0xfa07 = 0xfa03 |
SDHCI_CLOCK_CARD_EN but only observed the
Please CC me on comments.
I'm seeing a lot of these errors on my dual core fileserver:
---
Sep 23 01:51:28 files kernel: INFO: rcu_sched detected stalls on CPUs/tasks:
Sep 23 01:51:28 files kernel: 1-...!: (0 ticks
Please CC me on comments.
I'm seeing a lot of these errors on my dual core fileserver:
---
Sep 23 01:51:28 files kernel: INFO: rcu_sched detected stalls on CPUs/tasks:
Sep 23 01:51:28 files kernel: 1-...!: (0 ticks
Hi,
when enabling CONFIG_WW_MUTEX_SELFTEST on arm64 or x86_64,
I get the following traceback.
[3.111852] [ cut here ]
[3.112100] DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
[3.112753] WARNING: CPU: 1 PID: 771 at kernel/locking/mutex.c:1211
Hi,
when enabling CONFIG_WW_MUTEX_SELFTEST on arm64 or x86_64,
I get the following traceback.
[3.111852] [ cut here ]
[3.112100] DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current)
[3.112753] WARNING: CPU: 1 PID: 771 at kernel/locking/mutex.c:1211
On Tue, Sep 18, 2018 at 05:54:50PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Sep 13, 2018 at 02:54:11PM +0200, Jiri Olsa escreveu:
> > It will be used outside of util object in following patches.
>
> Had to add fcntl.h to have loff_t to fix the build in some systems,
> moved the prototype
On Tue, Sep 18, 2018 at 05:54:50PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Sep 13, 2018 at 02:54:11PM +0200, Jiri Olsa escreveu:
> > It will be used outside of util object in following patches.
>
> Had to add fcntl.h to have loff_t to fix the build in some systems,
> moved the prototype
On Tue, Sep 18, 2018 at 05:56:09PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Sep 13, 2018 at 02:54:04PM +0200, Jiri Olsa escreveu:
> > Now when we keep perf_tool pointer inside perf_session,
> > there's no need to have perf_tool argument in the
> > event_op3 callback. Removing it.
> >
> >
On Tue, Sep 18, 2018 at 05:56:09PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Sep 13, 2018 at 02:54:04PM +0200, Jiri Olsa escreveu:
> > Now when we keep perf_tool pointer inside perf_session,
> > there's no need to have perf_tool argument in the
> > event_op3 callback. Removing it.
> >
> >
On Mon, Sep 17, 2018 at 08:40:48PM +0900, Namhyung Kim wrote:
> On Thu, Sep 13, 2018 at 02:54:49PM +0200, Jiri Olsa wrote:
> > Currently we assign all maps to main thread. Adding
> > code that spreads maps for --threads option.
> >
> > For --thread option we create as many threads as there
> >
On Mon, Sep 17, 2018 at 08:40:48PM +0900, Namhyung Kim wrote:
> On Thu, Sep 13, 2018 at 02:54:49PM +0200, Jiri Olsa wrote:
> > Currently we assign all maps to main thread. Adding
> > code that spreads maps for --threads option.
> >
> > For --thread option we create as many threads as there
> >
On Mon, Sep 17, 2018 at 08:31:31PM +0900, Namhyung Kim wrote:
> On Thu, Sep 13, 2018 at 02:54:41PM +0200, Jiri Olsa wrote:
> > We need to keep global number of 'waking' now.
> >
> > TODO: make this multiple threads safe.
>
> Why not using atomic APIs?
that would solve it, will check
thanks,
On Mon, Sep 17, 2018 at 08:31:31PM +0900, Namhyung Kim wrote:
> On Thu, Sep 13, 2018 at 02:54:41PM +0200, Jiri Olsa wrote:
> > We need to keep global number of 'waking' now.
> >
> > TODO: make this multiple threads safe.
>
> Why not using atomic APIs?
that would solve it, will check
thanks,
1 - 100 of 334 matches
Mail list logo
