[PATCH] x86 tsc: Add the Intel Denverton Processor to native_calibrate_tsc()

From: Len Brown The Intel Denverton microserver uses a 25 MHz TSC crystal, so we can derive its exact * TSC frequency using CPUID and some arithmetic, eg. TSC: 1800 MHz (2500 Hz * 216 / 3 / 100) * 'exact' is only as good as the crystal, which should be +/- 20ppm

[PATCH] x86 tsc: Add the Intel Denverton Processor to native_calibrate_tsc()

From: Len Brown The Intel Denverton microserver uses a 25 MHz TSC crystal, so we can derive its exact * TSC frequency using CPUID and some arithmetic, eg. TSC: 1800 MHz (2500 Hz * 216 / 3 / 100) * 'exact' is only as good as the crystal, which should be +/- 20ppm Signed-off-by: Len

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

Hi Sylwester, 2017-01-21 16:42 GMT+09:00 Sylwester Nawrocki : > Hi Chanwoo, > > On 01/21/2017 06:08 AM, Chanwoo Choi wrote: >> I add reveiwed-by tag from this patch. But, on you tree, this patch[1] >> doesn’t >> include the my reviewed-by tag. > > My apologies for this

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

Hi Sylwester, 2017-01-21 16:42 GMT+09:00 Sylwester Nawrocki : > Hi Chanwoo, > > On 01/21/2017 06:08 AM, Chanwoo Choi wrote: >> I add reveiwed-by tag from this patch. But, on you tree, this patch[1] >> doesn’t >> include the my reviewed-by tag. > > My apologies for this omission, I'll make sure I

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

Hi Chanwoo, On 01/21/2017 06:08 AM, Chanwoo Choi wrote: > I add reveiwed-by tag from this patch. But, on you tree, this patch[1] doesn’t > include the my reviewed-by tag. My apologies for this omission, I'll make sure I use patchwork in future so no tags are lost. It's already pulled and that

Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone

- And I got flood of traces shown below. It seems to be consuming memory reserves until the size passed to write() request is stored to the page cache even after OOM-killed. Complete log is at http://I-love.SAKURA.ne.jp/tmp/serial-20170121.txt.xz . --

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

Hi Chanwoo, On 01/21/2017 06:08 AM, Chanwoo Choi wrote: > I add reveiwed-by tag from this patch. But, on you tree, this patch[1] doesn’t > include the my reviewed-by tag. My apologies for this omission, I'll make sure I use patchwork in future so no tags are lost. It's already pulled and that

Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone

- And I got flood of traces shown below. It seems to be consuming memory reserves until the size passed to write() request is stored to the page cache even after OOM-killed. Complete log is at http://I-love.SAKURA.ne.jp/tmp/serial-20170121.txt.xz . --

Re: [PATCH 07/12] PM / OPP: Update OPP users to put reference

Hi Viresh, For devfreq part, Looks good to me. Reviewed-by: Chanwoo Choi 2016-12-08 13:00 GMT+09:00 Viresh Kumar : > On 07-12-16, 22:23, Chanwoo Choi wrote: >> I think that the dev_pm_opp_put(opp) should be called after if statement >> If

Re: [PATCH 07/12] PM / OPP: Update OPP users to put reference

Hi Viresh, For devfreq part, Looks good to me. Reviewed-by: Chanwoo Choi 2016-12-08 13:00 GMT+09:00 Viresh Kumar : > On 07-12-16, 22:23, Chanwoo Choi wrote: >> I think that the dev_pm_opp_put(opp) should be called after if statement >> If dev_pm_opp_find_freq_ceil() return error, I think the

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

On Fri, 20 Jan 2017, Michael Schmitz wrote: > Am 15.01.2017 um 17:42 schrieb Finn Thain: > > >> No, we can't check either FDC or SCSI interrupts (or indeed any chip > >> registers) without touching the ST-DMA. The moment we select a FDC or > >> SCSI register for read, DMA is terminated no

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

On Fri, 20 Jan 2017, Michael Schmitz wrote: > Am 15.01.2017 um 17:42 schrieb Finn Thain: > > >> No, we can't check either FDC or SCSI interrupts (or indeed any chip > >> registers) without touching the ST-DMA. The moment we select a FDC or > >> SCSI register for read, DMA is terminated no

Re: [tip:timers/core] x86/timer: Make delay() during early bootup

On 01/20/2017, 03:40 PM, tip-bot for Jiri Slaby wrote: > Commit-ID: bf3304d996fbb993bad6be09cafde39cc2db72bb > Gitweb: http://git.kernel.org/tip/bf3304d996fbb993bad6be09cafde39cc2db72bb > Author: Jiri Slaby > AuthorDate: Thu, 19 Jan 2017 12:47:30 +0100 > Committer: Ingo

Re: [tip:timers/core] x86/timer: Make delay() during early bootup

On 01/20/2017, 03:40 PM, tip-bot for Jiri Slaby wrote: > Commit-ID: bf3304d996fbb993bad6be09cafde39cc2db72bb > Gitweb: http://git.kernel.org/tip/bf3304d996fbb993bad6be09cafde39cc2db72bb > Author: Jiri Slaby > AuthorDate: Thu, 19 Jan 2017 12:47:30 +0100 > Committer: Ingo Molnar >

Re: BUG: rcu_sched detected stalls on CPUs

On 2017-01-20 17:19, Steven Rostedt wrote: On Fri, 20 Jan 2017 10:43:50 +0200 mi...@stz-bg.com wrote: [1.] One line summary of the problem: rcu_sched detected stalls on CPUs and few minutes server not respond. Is this reproducible? Or was this a one time ordeal? It's happened usual once

Re: BUG: rcu_sched detected stalls on CPUs

On 2017-01-20 17:19, Steven Rostedt wrote: On Fri, 20 Jan 2017 10:43:50 +0200 mi...@stz-bg.com wrote: [1.] One line summary of the problem: rcu_sched detected stalls on CPUs and few minutes server not respond. Is this reproducible? Or was this a one time ordeal? It's happened usual once

Re: [PATCH v2] jump_label: reduce the size of struct static_key

* Jason Baron wrote: > >For example the last line could sure be written as: > > > > key->entries = jlm->entries; > > key->type |= static_key_type(key); > > > >right? > > Hi, > > So that is going to over-write the static_key_type(key)

Re: [PATCH v2] jump_label: reduce the size of struct static_key

* Jason Baron wrote: > >For example the last line could sure be written as: > > > > key->entries = jlm->entries; > > key->type |= static_key_type(key); > > > >right? > > Hi, > > So that is going to over-write the static_key_type(key) in the first >

[PATCH v2] net: xilinx: constify net_device_ops structure

Declare net_device_ops structure as const as it is only stored in the netdev_ops field of a net_device structure. This field is of type const, so net_device_ops structures having same properties can be made const too. Done using Coccinelle: @r1 disable optional_qualifier@ identifier i; position

[PATCH v2] net: xilinx: constify net_device_ops structure

Declare net_device_ops structure as const as it is only stored in the netdev_ops field of a net_device structure. This field is of type const, so net_device_ops structures having same properties can be made const too. Done using Coccinelle: @r1 disable optional_qualifier@ identifier i; position

[PATCH v2] net: moxa: constify net_device_ops structures

Declare net_device_ops structure as const as it is only stored in the netdev_ops field of a net_device structure. This field is of type const, so net_device_ops structures having same properties can be made const too. Done using Coccinelle: @r1 disable optional_qualifier@ identifier i; position

[PATCH v2] net: moxa: constify net_device_ops structures

Declare net_device_ops structure as const as it is only stored in the netdev_ops field of a net_device structure. This field is of type const, so net_device_ops structures having same properties can be made const too. Done using Coccinelle: @r1 disable optional_qualifier@ identifier i; position

Re: [PATCH 09/11] KVM: PPC: Book3S: Improve a size determination in two functions

Hi Markus, [auto build test ERROR on next-20170119] [also build test ERROR on v4.10-rc4] [cannot apply to v4.9-rc8 v4.9-rc7 v4.9-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 09/11] KVM: PPC: Book3S: Improve a size determination in two functions

Hi Markus, [auto build test ERROR on next-20170119] [also build test ERROR on v4.10-rc4] [cannot apply to v4.9-rc8 v4.9-rc7 v4.9-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

On Sat, Jan 21, 2017 at 01:16:56AM +0100, Jason A. Donenfeld wrote: > On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o wrote: > > But there is a shared pointer, which is used both for the dedicated > > u32 array and the dedicated u64 array. So when you increment the > > pointer for

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

On Sat, Jan 21, 2017 at 01:16:56AM +0100, Jason A. Donenfeld wrote: > On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o wrote: > > But there is a shared pointer, which is used both for the dedicated > > u32 array and the dedicated u64 array. So when you increment the > > pointer for the

Re: [PATCH 09/11] KVM: PPC: Book3S: Improve a size determination in two functions

Hi Markus, [auto build test ERROR on next-20170119] [also build test ERROR on v4.10-rc4] [cannot apply to v4.9-rc8 v4.9-rc7 v4.9-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 09/11] KVM: PPC: Book3S: Improve a size determination in two functions

Hi Markus, [auto build test ERROR on next-20170119] [also build test ERROR on v4.10-rc4] [cannot apply to v4.9-rc8 v4.9-rc7 v4.9-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] omit POSIX timer stuff from task_struct when disabled

On Fri, 20 Jan 2017, John Stultz wrote: > On Fri, Jan 20, 2017 at 2:46 PM, Nicolas Pitre > wrote: > > Just tell me if you prefer that I respin the patch and I'll do it. > > Yea. I'm not so finicky but I'm sure I'll probably get yelled at if I > pass it on, so if you

Re: [PATCH] omit POSIX timer stuff from task_struct when disabled

On Fri, 20 Jan 2017, John Stultz wrote: > On Fri, Jan 20, 2017 at 2:46 PM, Nicolas Pitre > wrote: > > Just tell me if you prefer that I respin the patch and I'll do it. > > Yea. I'm not so finicky but I'm sure I'll probably get yelled at if I > pass it on, so if you don't mind respinning it,

[PATCH] net: moxa: constify net_device_ops structures

Declare net_device_ops structures as const as they are only stored in the netdev_ops field of a net_device structure. This field is of type const, so net_device_ops structures having same properties can be made const too. Done using Coccinelle: @r1 disable optional_qualifier@ identifier i;

[PATCH] net: moxa: constify net_device_ops structures

Declare net_device_ops structures as const as they are only stored in the netdev_ops field of a net_device structure. This field is of type const, so net_device_ops structures having same properties can be made const too. Done using Coccinelle: @r1 disable optional_qualifier@ identifier i;

[PATCH] net: xilinx: constify net_device_ops structures

Declare net_device_ops structures as const as they are only stored in the netdev_ops field of a net_device structure. This field is of type const, so net_device_ops structures having same properties can be made const too. Done using Coccinelle: @r1 disable optional_qualifier@ identifier i;

[PATCH] net: xilinx: constify net_device_ops structures

Declare net_device_ops structures as const as they are only stored in the netdev_ops field of a net_device structure. This field is of type const, so net_device_ops structures having same properties can be made const too. Done using Coccinelle: @r1 disable optional_qualifier@ identifier i;

[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

Allow power sequencing for the Marvell SD8787 Wifi/BT chip. This can be abstracted to other chipsets if needed in the future. Cc: Tony Lindgren Cc: Ulf Hansson Signed-off-by: Matt Ranostay --- drivers/mmc/core/Kconfig

[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

Allow power sequencing for the Marvell SD8787 Wifi/BT chip. This can be abstracted to other chipsets if needed in the future. Cc: Tony Lindgren Cc: Ulf Hansson Signed-off-by: Matt Ranostay --- drivers/mmc/core/Kconfig | 10 drivers/mmc/core/Makefile| 1 +

[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

Cc: devicet...@vger.kernel.org Signed-off-by: Matt Ranostay --- .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 ++ .../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++- 2 files changed, 20 insertions(+), 1 deletion(-)

[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

Cc: devicet...@vger.kernel.org Signed-off-by: Matt Ranostay --- .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 ++ .../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++- 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Changes from v2: * update device tree bindings to powerdown-gpios and document active state Matt Ranostay (2): devicetree: document new marvell-8xxx and

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

Changes from v1: * split devictree docs from pwrseq changes * rebase devicetree documents due to filename change * rebase pwrseq patchset Changes from v2: * update device tree bindings to powerdown-gpios and document active state Matt Ranostay (2): devicetree: document new marvell-8xxx and

Re: [PATCH 1/2] nilfs2: use i_blocksize()

Hi Geliang, [auto build test ERROR on v4.9-rc8] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Geliang-Tang/nilfs2-use-i_blocksize/20170121-114142 config: x86_64-randconfig-n0-01211226

Re: [PATCH 1/2] nilfs2: use i_blocksize()

Hi Geliang, [auto build test ERROR on v4.9-rc8] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Geliang-Tang/nilfs2-use-i_blocksize/20170121-114142 config: x86_64-randconfig-n0-01211226

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

Hi Sylwester, I add reveiwed-by tag from this patch. But, on you tree, this patch[1] doesn’t include the my reviewed-by tag. [1] https://git.linuxtv.org/snawrocki/samsung.git/commit/?h=for-v4.11/clk/next=cb4ac949ea14416a2d57b7a343bc4b571074e3bd 2017-01-16 19:32 GMT+09:00 Sylwester Nawrocki

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

Hi Sylwester, I add reveiwed-by tag from this patch. But, on you tree, this patch[1] doesn’t include the my reviewed-by tag. [1] https://git.linuxtv.org/snawrocki/samsung.git/commit/?h=for-v4.11/clk/next=cb4ac949ea14416a2d57b7a343bc4b571074e3bd 2017-01-16 19:32 GMT+09:00 Sylwester Nawrocki : >

[patch] orangefs: silence harmless integer overflow warning

The issue here is that in orangefs_bufmap_alloc() we do: bufmap->buffer_index_array = kzalloc(DIV_ROUND_UP(bufmap->desc_count, BITS_PER_LONG), GFP_KERNEL); If we choose a bufmap->desc_count like -31 then it means the DIV_ROUND_UP ends up having an integer overflow. The

[patch] orangefs: silence harmless integer overflow warning

The issue here is that in orangefs_bufmap_alloc() we do: bufmap->buffer_index_array = kzalloc(DIV_ROUND_UP(bufmap->desc_count, BITS_PER_LONG), GFP_KERNEL); If we choose a bufmap->desc_count like -31 then it means the DIV_ROUND_UP ends up having an integer overflow. The

[patch] samples/bpf: silence shift wrapping warning

max_key is a value in the 0-63 range, so on 32 bit systems the shift could wrap. Signed-off-by: Dan Carpenter diff --git a/samples/bpf/lwt_len_hist_user.c b/samples/bpf/lwt_len_hist_user.c index ec8f3bb..bd06eef 100644 --- a/samples/bpf/lwt_len_hist_user.c +++

[patch] samples/bpf: silence shift wrapping warning

max_key is a value in the 0-63 range, so on 32 bit systems the shift could wrap. Signed-off-by: Dan Carpenter diff --git a/samples/bpf/lwt_len_hist_user.c b/samples/bpf/lwt_len_hist_user.c index ec8f3bb..bd06eef 100644 --- a/samples/bpf/lwt_len_hist_user.c +++ b/samples/bpf/lwt_len_hist_user.c

Re: [PATCH RESEND 2/2] ARM: da850: add the nand dev_id to the clock lookup table

On Friday 13 January 2017 03:30 PM, Bartosz Golaszewski wrote: > The aemif driver can now access struct of_dev_auxdata (using platform > data). > > Add the device id to the clock lookup table for the nand clock and > create a separate lookup table for aemif subnodes. > > Signed-off-by: Bartosz

Re: [PATCH RESEND 2/2] ARM: da850: add the nand dev_id to the clock lookup table

On Friday 13 January 2017 03:30 PM, Bartosz Golaszewski wrote: > The aemif driver can now access struct of_dev_auxdata (using platform > data). > > Add the device id to the clock lookup table for the nand clock and > create a separate lookup table for aemif subnodes. > > Signed-off-by: Bartosz

Re: [PATCH v1 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

Hi Thomas, [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.10-rc4 next-20170120] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Thomas

Re: [PATCH v1 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

Hi Thomas, [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.10-rc4 next-20170120] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Thomas

Re: [PATCH v1 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

Hi Thomas, [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.10-rc4 next-20170120] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Thomas

Re: [PATCH v1 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

Hi Thomas, [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.10-rc4 next-20170120] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Thomas

Re: [PATCH 0/4] HID: wacom: fixes for next

Patches 1/3 look reasonable to me, though I've not run into the bugs they aim to fix. For those: Acked-by: Jason Gerecke As for patch 4, I have some additional reservations about hiding the message... We can discuss that further in its thread. Jason --- Now instead of

Re: [PATCH 0/4] HID: wacom: fixes for next

Patches 1/3 look reasonable to me, though I've not run into the bugs they aim to fix. For those: Acked-by: Jason Gerecke As for patch 4, I have some additional reservations about hiding the message... We can discuss that further in its thread. Jason --- Now instead of four in the eights place

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

Hi Thomas, [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.10-rc4 next-20170120] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Thomas

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

Hi Thomas, [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.10-rc4 next-20170120] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Thomas

Re: [PATCH 4/4] HID: wacom: do not shout an error on LED control

I'm not super comfortable with hiding this error. If the tablet reacts appropriately, I wouldn't think we'd get an EPIPE. Although its not fatal, it still might be a symptom of something deeper... Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That

Re: [PATCH 4/4] HID: wacom: do not shout an error on LED control

I'm not super comfortable with hiding this error. If the tablet reacts appropriately, I wouldn't think we'd get an EPIPE. Although its not fatal, it still might be a symptom of something deeper... Jason --- Now instead of four in the eights place / you’ve got three, ‘Cause you added one / (That

Re: [PATCH 2/3] ftrace: Expose ftrace_hash_empty and ftrace_lookup_ip

On Fri, Jan 20, 2017 at 09:13:17PM -0500, Steven Rostedt wrote: > On Sat, 21 Jan 2017 09:27:06 +0900 > Namhyung Kim wrote: > > > > > Note, I had to modify this patch and move this declaration outside of > > > the #ifdef CONFIG_FUNCTION_GRAPH_TRACER, as it failed to build

Re: [PATCH 2/3] ftrace: Expose ftrace_hash_empty and ftrace_lookup_ip

On Fri, Jan 20, 2017 at 09:13:17PM -0500, Steven Rostedt wrote: > On Sat, 21 Jan 2017 09:27:06 +0900 > Namhyung Kim wrote: > > > > > Note, I had to modify this patch and move this declaration outside of > > > the #ifdef CONFIG_FUNCTION_GRAPH_TRACER, as it failed to build when > > > function

[PATCH v2] clk: hisilicon: fix lock assignment

In clock driver initialize phase the spinlock is missed to assignment to struct clkgate_separated, finally there have no locking to protect exclusive accessing for clock registers. This bug introduces the console has no output after enable coresight driver on 96boards Hikey; this is because

[PATCH v2] clk: hisilicon: fix lock assignment

In clock driver initialize phase the spinlock is missed to assignment to struct clkgate_separated, finally there have no locking to protect exclusive accessing for clock registers. This bug introduces the console has no output after enable coresight driver on 96boards Hikey; this is because

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

Hi Thomas, [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.10-rc4 next-20170120] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Thomas

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

Hi Thomas, [auto build test ERROR on tip/auto-latest] [also build test ERROR on v4.10-rc4 next-20170120] [cannot apply to tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Thomas

Re: [PATCH] clk: hisilicon: fix lock assignment

On Fri, Jan 20, 2017 at 02:58:27PM -0800, Stephen Boyd wrote: > On 01/18, Leo Yan wrote: > > In clock driver initialize phase the spinlock is missed to assignment > > to struct clkgate_separated, finally there have no locking to protect > > exclusive accessing for clock registers. > > > > This

Re: [PATCH] clk: hisilicon: fix lock assignment

On Fri, Jan 20, 2017 at 02:58:27PM -0800, Stephen Boyd wrote: > On 01/18, Leo Yan wrote: > > In clock driver initialize phase the spinlock is missed to assignment > > to struct clkgate_separated, finally there have no locking to protect > > exclusive accessing for clock registers. > > > > This

Re: [PATCH 2/3] ftrace: Expose ftrace_hash_empty and ftrace_lookup_ip

On Sat, 21 Jan 2017 09:27:06 +0900 Namhyung Kim wrote: > > Note, I had to modify this patch and move this declaration outside of > > the #ifdef CONFIG_FUNCTION_GRAPH_TRACER, as it failed to build when > > function graph wasn't enabled. Function tracer uses this too. > >

Re: [PATCH 2/3] ftrace: Expose ftrace_hash_empty and ftrace_lookup_ip

On Sat, 21 Jan 2017 09:27:06 +0900 Namhyung Kim wrote: > > Note, I had to modify this patch and move this declaration outside of > > the #ifdef CONFIG_FUNCTION_GRAPH_TRACER, as it failed to build when > > function graph wasn't enabled. Function tracer uses this too. > > Oops, my bad. > >

Re: [PATCH v7] tpm: Check size of response before accessing data

On 01/20/2017 03:14 PM, Jarkko Sakkinen wrote: On Fri, Jan 20, 2017 at 07:55:22PM +0200, Jarkko Sakkinen wrote: On Fri, Jan 20, 2017 at 06:21:58PM +0200, Jarkko Sakkinen wrote: On Fri, Jan 20, 2017 at 03:36:30PM +0200, Jarkko Sakkinen wrote: On Thu, Jan 19, 2017 at 07:19:12AM -0500, Stefan

Re: [PATCH v7] tpm: Check size of response before accessing data

On 01/20/2017 03:14 PM, Jarkko Sakkinen wrote: On Fri, Jan 20, 2017 at 07:55:22PM +0200, Jarkko Sakkinen wrote: On Fri, Jan 20, 2017 at 06:21:58PM +0200, Jarkko Sakkinen wrote: On Fri, Jan 20, 2017 at 03:36:30PM +0200, Jarkko Sakkinen wrote: On Thu, Jan 19, 2017 at 07:19:12AM -0500, Stefan

Re: [PATCH v3 perf/core] perf script: fix a use after free crash.

Hey Arnaldo, On Thu, Jan 05, 2017 at 10:23:31PM -0800, Krister Johansen wrote: > If dso__load_kcore frees all of the existing maps, but one has already > been attached to a callchain cursor node, then we can get a SIGSEGV in > any function that happens to try to use this invalid cursor. Use the

Re: [PATCH v3 perf/core] perf script: fix a use after free crash.

Hey Arnaldo, On Thu, Jan 05, 2017 at 10:23:31PM -0800, Krister Johansen wrote: > If dso__load_kcore frees all of the existing maps, but one has already > been attached to a callchain cursor node, then we can get a SIGSEGV in > any function that happens to try to use this invalid cursor. Use the

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

On Fri, Jan 20, 2017 at 4:57 PM, Andy Lutomirski wrote: > On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier wrote: >> Each processor holds a GDT in its per-cpu structure. The sgdt >> instruction gives the base address of the current GDT. This address can

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

On Fri, Jan 20, 2017 at 4:57 PM, Andy Lutomirski wrote: > On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier wrote: >> Each processor holds a GDT in its per-cpu structure. The sgdt >> instruction gives the base address of the current GDT. This address can >> be used to bypass KASLR memory

Re: [PATCH v1 3/3] x86: Make the GDT remapping read-only on 64 bit

On Fri, Jan 20, 2017 at 5:06 PM, Andy Lutomirski wrote: > On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier wrote: >> This patch makes the GDT remapped pages read-only to prevent corruption. >> This change is done only on 64 bit. >> >> The

Re: [PATCH v1 3/3] x86: Make the GDT remapping read-only on 64 bit

On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier wrote: > This patch makes the GDT remapped pages read-only to prevent corruption. > This change is done only on 64 bit. > > The native_load_tr_desc function was adapted to correctly handle a > read-only GDT. The LTR instruction

Re: [PATCH v1 3/3] x86: Make the GDT remapping read-only on 64 bit

On Fri, Jan 20, 2017 at 5:06 PM, Andy Lutomirski wrote: > On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier wrote: >> This patch makes the GDT remapped pages read-only to prevent corruption. >> This change is done only on 64 bit. >> >> The native_load_tr_desc function was adapted to correctly

Re: [PATCH v1 3/3] x86: Make the GDT remapping read-only on 64 bit

On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier wrote: > This patch makes the GDT remapped pages read-only to prevent corruption. > This change is done only on 64 bit. > > The native_load_tr_desc function was adapted to correctly handle a > read-only GDT. The LTR instruction always writes to the

Re: [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs

Hi, On Thu, Jan 12, 2017 at 5:28 PM, Maxime Ripard wrote: > On Fri, Dec 09, 2016 at 12:04:08PM +0100, Quentin Schulz wrote: >> The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the >> VBUS power supply for both max current and min voltage

Re: [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs

Hi, On Thu, Jan 12, 2017 at 5:28 PM, Maxime Ripard wrote: > On Fri, Dec 09, 2016 at 12:04:08PM +0100, Quentin Schulz wrote: >> The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the >> VBUS power supply for both max current and min voltage supplied. This >> series of patch adds the

[PATCH RESEND] staging: media: lirc: use new parport device model

From: Sudip Mukherjee Modify lirc_parallel driver to use the new parallel port device model. Signed-off-by: Sudip Mukherjee --- Resending after more than one year. Prevoius patch is at

[PATCH RESEND] staging: media: lirc: use new parport device model

From: Sudip Mukherjee Modify lirc_parallel driver to use the new parallel port device model. Signed-off-by: Sudip Mukherjee --- Resending after more than one year. Prevoius patch is at https://patchwork.kernel.org/patch/7883591/ drivers/staging/media/lirc/lirc_parallel.c | 93

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier wrote: > Each processor holds a GDT in its per-cpu structure. The sgdt > instruction gives the base address of the current GDT. This address can > be used to bypass KASLR memory randomization. With another bug, an > attacker

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier wrote: > Each processor holds a GDT in its per-cpu structure. The sgdt > instruction gives the base address of the current GDT. This address can > be used to bypass KASLR memory randomization. With another bug, an > attacker could target other

Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

On Fri, Jan 20, 2017 at 8:33 AM, Djalal Harouni wrote: > On Thu, Jan 19, 2017 at 8:52 PM, Andy Lutomirski wrote: >> On Thu, Jan 19, 2017 at 5:53 AM, Djalal Harouni wrote: > [...] >>> Sure, the hidepid mount option is old enough, and this

Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

On Fri, Jan 20, 2017 at 8:33 AM, Djalal Harouni wrote: > On Thu, Jan 19, 2017 at 8:52 PM, Andy Lutomirski wrote: >> On Thu, Jan 19, 2017 at 5:53 AM, Djalal Harouni wrote: > [...] >>> Sure, the hidepid mount option is old enough, and this per-task >>> hidepid is clearly defined only for procfs

Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div

On 01/18, Markus Mayer wrote: > diff --git > a/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt > b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt > new file mode 100644 > index 000..c4acb53 > --- /dev/null > +++

Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div

On 01/18, Markus Mayer wrote: > diff --git > a/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt > b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt > new file mode 100644 > index 000..c4acb53 > --- /dev/null > +++

Re: [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC

On 01/13, Chris Packham wrote: > @@ -158,6 +170,14 @@ static const struct coreclk_soc_desc axp_coreclks = { > .num_ratios = ARRAY_SIZE(axp_coreclk_ratios), > }; > > +static const struct coreclk_soc_desc mv98dx3236_coreclks = { > + .get_tclk_freq = mv98dx3236_get_tclk_freq, > +

Re: [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC

On 01/13, Chris Packham wrote: > @@ -158,6 +170,14 @@ static const struct coreclk_soc_desc axp_coreclks = { > .num_ratios = ARRAY_SIZE(axp_coreclk_ratios), > }; > > +static const struct coreclk_soc_desc mv98dx3236_coreclks = { > + .get_tclk_freq = mv98dx3236_get_tclk_freq, > +

Re: [PATCH v2 1/3] dt-bindings: mfd: stm32f4: Fix STM32F4_X_CLOCK() macro

On 01/09, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > Macro to select a clock was not correct. > > Offset of enable register starts at 0x30, then calculation to select a bit is: > (@enable_reg - 0x30) / 4 * 32 + bit_to_select > > Signed-off-by:

Re: [PATCH v2 1/3] dt-bindings: mfd: stm32f4: Fix STM32F4_X_CLOCK() macro

On 01/09, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > Macro to select a clock was not correct. > > Offset of enable register starts at 0x30, then calculation to select a bit is: > (@enable_reg - 0x30) / 4 * 32 + bit_to_select > > Signed-off-by: Gabriel Fernandez > Tested-by:

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o wrote: > But there is a shared pointer, which is used both for the dedicated > u32 array and the dedicated u64 array. So when you increment the > pointer for the get_random_u32, the corresponding entry in the u64 > array is wasted,

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o wrote: > But there is a shared pointer, which is used both for the dedicated > u32 array and the dedicated u64 array. So when you increment the > pointer for the get_random_u32, the corresponding entry in the u64 > array is wasted, no? No, it is

Re: [PATCH 2/4] clk: stm32f7: Introduce stm32f7 clocks for STM32F746 boards

On 01/06, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > This patch enables clocks for STM32F746 boards. > > Signed-off-by: Gabriel Fernandez > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code

Re: [PATCH 2/4] clk: stm32f7: Introduce stm32f7 clocks for STM32F746 boards

On 01/06, gabriel.fernan...@st.com wrote: > From: Gabriel Fernandez > > This patch enables clocks for STM32F746 boards. > > Signed-off-by: Gabriel Fernandez > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative

[GIT PULL] libnvdimm fixes for 4.10-rc5

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive: * A regression fix for the multiple-pmem-namespace-per-region support added in 4.9. Even if an existing environment is not using that feature the act of creating and a

[GIT PULL] libnvdimm fixes for 4.10-rc5

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes ...to receive: * A regression fix for the multiple-pmem-namespace-per-region support added in 4.9. Even if an existing environment is not using that feature the act of creating and a

  1   2   3   4   5   6   7   8   9   10   >