[PATCH 05/15] perf callchain: Create real callchain entries for inlined frames

From: Milian Wolff The inline_node structs are maintained by the new dso->inlines tree. This in turn keeps ownership of the fake symbols and srcline string representing an inline frame. This tree is sorted by address to allow quick lookups. All other entries of the symbol

[PATCH 05/15] perf callchain: Create real callchain entries for inlined frames

From: Milian Wolff The inline_node structs are maintained by the new dso->inlines tree. This in turn keeps ownership of the fake symbols and srcline string representing an inline frame. This tree is sorted by address to allow quick lookups. All other entries of the symbol beside the function

[PATCH 09/15] perf callchain: Compare symbol name for inlined frames when matching

From: Milian Wolff The fake symbols we create for inlined frames will represent different functions but can use the symbol start address. This leads to issues when different inline branches all lead to the same function. Before: ~ $ perf report -s sym -i

[PATCH 09/15] perf callchain: Compare symbol name for inlined frames when matching

From: Milian Wolff The fake symbols we create for inlined frames will represent different functions but can use the symbol start address. This leads to issues when different inline branches all lead to the same function. Before: ~ $ perf report -s sym -i perf.inlining.data --inline --stdio

[PATCH 08/15] perf script: Mark inlined frames and do not print DSO for them

From: Milian Wolff Instead of showing the (repeated) DSO name of the non-inlined frame, we now show the "(inlined)" suffix instead. Before: 214f7 __hypot_finite (/usr/lib/libm-2.25.so) ace3 hypot (/usr/lib/libm-2.25.so)

[PATCH 08/15] perf script: Mark inlined frames and do not print DSO for them

From: Milian Wolff Instead of showing the (repeated) DSO name of the non-inlined frame, we now show the "(inlined)" suffix instead. Before: 214f7 __hypot_finite (/usr/lib/libm-2.25.so) ace3 hypot (/usr/lib/libm-2.25.so) a4a

[PATCH 11/15] perf report: Properly handle branch count in match_chain()

From: Milian Wolff Some of the code paths I introduced before returned too early without running the code to handle a node's branch count. By refactoring match_chain to only have one exit point, this can be remedied. Signed-off-by: Milian Wolff

[PATCH 11/15] perf report: Properly handle branch count in match_chain()

From: Milian Wolff Some of the code paths I introduced before returned too early without running the code to handle a node's branch count. By refactoring match_chain to only have one exit point, this can be remedied. Signed-off-by: Milian Wolff Acked-by: Namhyung Kim Cc: David Ahern Cc: Jin

[PATCH 13/15] perf report: Cache srclines for callchain nodes

From: Milian Wolff On one hand this ensures that the memory is properly freed when the DSO gets freed. On the other hand this significantly speeds up the processing of the callchain nodes when lots of srclines are requested. For one of my data files e.g.: Before:

[PATCH 15/15] perf util: Enable handling of inlined frames by default

From: Milian Wolff Now that we have caches in place to speed up the process of finding inlined frames and srcline information repeatedly, we can enable this useful option by default. Suggested-by: Ingo Molnar Signed-off-by: Milian Wolff

[PATCH 13/15] perf report: Cache srclines for callchain nodes

From: Milian Wolff On one hand this ensures that the memory is properly freed when the DSO gets freed. On the other hand this significantly speeds up the processing of the callchain nodes when lots of srclines are requested. For one of my data files e.g.: Before: Performance counter stats for

[PATCH 15/15] perf util: Enable handling of inlined frames by default

From: Milian Wolff Now that we have caches in place to speed up the process of finding inlined frames and srcline information repeatedly, we can enable this useful option by default. Suggested-by: Ingo Molnar Signed-off-by: Milian Wolff Reviewed-by: Andi Kleen Cc: David Ahern Cc: Jin Yao

[PATCH 14/15] perf report: Use srcline from callchain for hist entries

From: Milian Wolff This also removes the symbol name from the srcline column, more on this below. This ensures we use the correct srcline, which could originate from a potentially inlined function. The hist entries used to query for the srcline based purely on the IP,

[PATCH 14/15] perf report: Use srcline from callchain for hist entries

From: Milian Wolff This also removes the symbol name from the srcline column, more on this below. This ensures we use the correct srcline, which could originate from a potentially inlined function. The hist entries used to query for the srcline based purely on the IP, which leads to wrong

[PATCH 12/15] perf report: Cache failed lookups of inlined frames

From: Milian Wolff When no inlined frames could be found for a given address, we did not store this information anywhere. That means we potentially do the costly inliner lookup repeatedly for cases where we know it can never succeed. This patch makes

[PATCH 12/15] perf report: Cache failed lookups of inlined frames

From: Milian Wolff When no inlined frames could be found for a given address, we did not store this information anywhere. That means we potentially do the costly inliner lookup repeatedly for cases where we know it can never succeed. This patch makes dso__parse_addr_inlines always return a

[PATCH 10/15] perf report: Compare symbol name for inlined frames when sorting

From: Milian Wolff Similar to the callstack frame matching, we also have to compare the symbol name when sorting hist entries. The reason is twofold: On one hand, multiple inlined functions will use the same symbol start/end values of the parent, non-inlined symbol. As

[PATCH 10/15] perf report: Compare symbol name for inlined frames when sorting

From: Milian Wolff Similar to the callstack frame matching, we also have to compare the symbol name when sorting hist entries. The reason is twofold: On one hand, multiple inlined functions will use the same symbol start/end values of the parent, non-inlined symbol. As such, all of these

[PATCH 01/15] perf report: Remove code to handle inline frames from browsers

From: Milian Wolff The follow-up commits will make inline frames first-class citizens in the callchain, thereby obsoleting all of this special code. Signed-off-by: Milian Wolff Reviewed-by: Jiri Olsa Reviewed-by: Namhyung Kim

[PATCH 01/15] perf report: Remove code to handle inline frames from browsers

From: Milian Wolff The follow-up commits will make inline frames first-class citizens in the callchain, thereby obsoleting all of this special code. Signed-off-by: Milian Wolff Reviewed-by: Jiri Olsa Reviewed-by: Namhyung Kim Cc: David Ahern Cc: Peter Zijlstra Cc: Yao Jin Link:

[PATCH 06/15] perf report: Fall-back to function name comparison for -g srcline

From: Milian Wolff When a callchain entry has no srcline available, we ended up comparing the instruction pointer. I consider this to be not too useful. Rather, I think we should group the entries by function name, which this patch adds. For people who want to split the

[PATCH 06/15] perf report: Fall-back to function name comparison for -g srcline

From: Milian Wolff When a callchain entry has no srcline available, we ended up comparing the instruction pointer. I consider this to be not too useful. Rather, I think we should group the entries by function name, which this patch adds. For people who want to split the data on the IP boundary,

[GIT PULL 00/15] perf/core inlining improvements

at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-4.15-20171025 for you to fetch changes up to d8a88dd243a170a226aba33e7c53704db2f82aa6: perf util: Enable handling of inlined frames by default (2017-10-25 10:50:47 -0300

[GIT PULL 00/15] perf/core inlining improvements

at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-4.15-20171025 for you to fetch changes up to d8a88dd243a170a226aba33e7c53704db2f82aa6: perf util: Enable handling of inlined frames by default (2017-10-25 10:50:47 -0300

Re: [PATCH 4/8] PCI: host: brcmstb: add dma-ranges for inbound traffic

On Wed, Oct 25, 2017 at 5:46 AM, David Laight wrote: > From: Jim QuinlanPCIE_IPROC_MSI >> Sent: 24 October 2017 19:16 >> The Broadcom STB PCIe host controller is intimately related to the >> memory subsystem. This close relationship adds complexity to how cpu >> system

Re: [PATCH 4/8] PCI: host: brcmstb: add dma-ranges for inbound traffic

On Wed, Oct 25, 2017 at 5:46 AM, David Laight wrote: > From: Jim QuinlanPCIE_IPROC_MSI >> Sent: 24 October 2017 19:16 >> The Broadcom STB PCIe host controller is intimately related to the >> memory subsystem. This close relationship adds complexity to how cpu >> system memory is mapped to PCIe

RE: [patch v9 1/4] drivers: jtag: Add JTAG core driver

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Friday, October 20, 2017 5:54 PM > To: Oleksandr Shamray > Cc: a...@arndb.de; linux-kernel@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; devicet...@vger.kernel.org; >

RE: [patch v9 1/4] drivers: jtag: Add JTAG core driver

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Friday, October 20, 2017 5:54 PM > To: Oleksandr Shamray > Cc: a...@arndb.de; linux-kernel@vger.kernel.org; linux-arm- > ker...@lists.infradead.org; devicet...@vger.kernel.org; > open...@lists.ozlabs.org;

[PATCH] staging: rtl8723bs: Fix space before '[' error.

Fix checkpatch.pl error: ERROR: space prohibited before open square bracket '['. Signed-off-by: Arvind Yadav --- drivers/staging/rtl8723bs/os_dep/rtw_proc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH] staging: rtl8723bs: Fix space before '[' error.

Fix checkpatch.pl error: ERROR: space prohibited before open square bracket '['. Signed-off-by: Arvind Yadav --- drivers/staging/rtl8723bs/os_dep/rtw_proc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rtl8723bs/os_dep/rtw_proc.c

Re: [PATCH] sound: Convert timers to use timer_setup()

On Wed, 25 Oct 2017 17:09:27 +0200, Kees Cook wrote: > > In preparation for unconditionally passing the struct timer_list > pointer to all timer callbacks, switch to using the new timer_setup() > and from_timer() to pass the timer pointer explicitly. These are all the > "mechanical" changes

Re: [PATCH] sound: Convert timers to use timer_setup()

On Wed, 25 Oct 2017 17:09:27 +0200, Kees Cook wrote: > > In preparation for unconditionally passing the struct timer_list > pointer to all timer callbacks, switch to using the new timer_setup() > and from_timer() to pass the timer pointer explicitly. These are all the > "mechanical" changes

Re: [PATCH] wimax/i2400m: Remove VLAIS

On Tue, 2017-10-24 at 21:00 +, Perez-Gonzalez, Inaky wrote: > > ping > > any comments on this? > > None from me; I don't have access to this HW anymore, so I can't > validate > if the change would work or not. I still have a 5350 around somewhere, I can make sure firmware loads if you like.

Re: [PATCH] iio/accel/bmc150: Improve unlocking of a mutex in two functions

Hi, On 25-10-17 16:33, SF Markus Elfring wrote: From: Markus Elfring Date: Wed, 25 Oct 2017 16:26:29 +0200 Add a jump target so that a call of the function "mutex_unlock" is mostly stored at the end of these function implementations. Replace five calls by goto

Re: [PATCH] wimax/i2400m: Remove VLAIS

On Tue, 2017-10-24 at 21:00 +, Perez-Gonzalez, Inaky wrote: > > ping > > any comments on this? > > None from me; I don't have access to this HW anymore, so I can't > validate > if the change would work or not. I still have a 5350 around somewhere, I can make sure firmware loads if you like.

Re: [PATCH] iio/accel/bmc150: Improve unlocking of a mutex in two functions

Hi, On 25-10-17 16:33, SF Markus Elfring wrote: From: Markus Elfring Date: Wed, 25 Oct 2017 16:26:29 +0200 Add a jump target so that a call of the function "mutex_unlock" is mostly stored at the end of these function implementations. Replace five calls by goto statements. This issue was

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

On Wed, Oct 25, 2017 at 9:22 AM, Bjorn Helgaas wrote: > On Tue, Oct 24, 2017 at 02:15:47PM -0400, Jim Quinlan wrote: >> This commit adds MSI to the Broadcom STB PCIe host controller. It does >> not add MSIX since that functiostbsrvnality is not in the HW. The MSI >>

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

On Wed, Oct 25, 2017 at 9:22 AM, Bjorn Helgaas wrote: > On Tue, Oct 24, 2017 at 02:15:47PM -0400, Jim Quinlan wrote: >> This commit adds MSI to the Broadcom STB PCIe host controller. It does >> not add MSIX since that functiostbsrvnality is not in the HW. The MSI >> controller is physically

Re: alpha boot hang - 4.14-rc* regression

> > > > > > removing libata modules and rebooting fixes it - so it seems to be > > > > > > loading of libata. > > > > > > > > > > Can you please cherry-pick: > > > > > > > > > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order > > > > > probing") > > > > > > > > > > from

Re: alpha boot hang - 4.14-rc* regression

> > > > > > removing libata modules and rebooting fixes it - so it seems to be > > > > > > loading of libata. > > > > > > > > > > Can you please cherry-pick: > > > > > > > > > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order > > > > > probing") > > > > > > > > > > from

Re: [PATCH] I2C-Octeon: Use common error handling code in octeon_i2c_probe()

On 10/25/2017 02:52 AM, SF Markus Elfring wrote: From: Markus Elfring NAK. We don't need any more Markus Elfring spam. Date: Wed, 25 Oct 2017 11:45:48 +0200 Add a jump target so that a specific error message is stored only once at the end of this function

Re: [PATCH] I2C-Octeon: Use common error handling code in octeon_i2c_probe()

On 10/25/2017 02:52 AM, SF Markus Elfring wrote: From: Markus Elfring NAK. We don't need any more Markus Elfring spam. Date: Wed, 25 Oct 2017 11:45:48 +0200 Add a jump target so that a specific error message is stored only once at the end of this function implementation. Please read C

Re: [PATCH v3] cpuset: Enable cpuset controller in default hierarchy

On 10/06/2017 05:10 PM, Waiman Long wrote: > Given the fact that thread mode had been merged into 4.14, it is now > time to enable cpuset to be used in the default hierarchy (cgroup v2) > as it is clearly threaded. > > The cpuset controller had experienced feature creep since its > introduction

Re: [PATCH v3] cpuset: Enable cpuset controller in default hierarchy

On 10/06/2017 05:10 PM, Waiman Long wrote: > Given the fact that thread mode had been merged into 4.14, it is now > time to enable cpuset to be used in the default hierarchy (cgroup v2) > as it is clearly threaded. > > The cpuset controller had experienced feature creep since its > introduction

RE: [PATCH net-next 2/2] net: dsa: lan9303: Learn addresses on CPU port when bridged

Hi Egil, > >> @@ -62,7 +80,10 @@ static struct sk_buff *lan9303_xmit(struct sk_buff > *skb, > >> struct net_device *dev) > >> > >>lan9303_tag = (u16 *)(skb->data + 2 * ETH_ALEN); > >>lan9303_tag[0] = htons(ETH_P_8021Q); > >> - lan9303_tag[1] = htons(dp->index | BIT(4)); > >> +

RE: [PATCH net-next 2/2] net: dsa: lan9303: Learn addresses on CPU port when bridged

Hi Egil, > >> @@ -62,7 +80,10 @@ static struct sk_buff *lan9303_xmit(struct sk_buff > *skb, > >> struct net_device *dev) > >> > >>lan9303_tag = (u16 *)(skb->data + 2 * ETH_ALEN); > >>lan9303_tag[0] = htons(ETH_P_8021Q); > >> - lan9303_tag[1] = htons(dp->index | BIT(4)); > >> +

Re: Re [PATCH v2] lib: optimize cpumask_next_and()

On Wed, Oct 25, 2017 at 05:28:41PM +0200, Clement Courbet wrote: > Thanks for the comments Yury. > > > But I'd like also to keep _find_next_bit() consistent with > > _find_next_bit_le() > > Not sure I understand what you're suggesting here: Do you want a > find_next_and_bit_le() or do you want

Re: Re [PATCH v2] lib: optimize cpumask_next_and()

On Wed, Oct 25, 2017 at 05:28:41PM +0200, Clement Courbet wrote: > Thanks for the comments Yury. > > > But I'd like also to keep _find_next_bit() consistent with > > _find_next_bit_le() > > Not sure I understand what you're suggesting here: Do you want a > find_next_and_bit_le() or do you want

Re: [RFC PATCH 0/9] V4L2 Jobs API WIP

Hello, On Monday, 23 October 2017 11:45:01 EEST Alexandre Courbot wrote: > On Thu, Oct 19, 2017 at 11:43 PM, Sakari Ailus wrote: > > On Thu, Sep 28, 2017 at 06:50:18PM +0900, Alexandre Courbot wrote: > >> Hi everyone, > >> > >> Here is a new attempt at the "request" (which

Re: [f2fs-dev] [PATCH 1/2] f2fs: add missing quota_initialize in f2fs_set_acl

On 2017/10/25 14:30, Jaegeuk Kim wrote: > On 10/25, Chao Yu wrote: >> On 2017/10/25 13:44, Jaegeuk Kim wrote: >>> On 10/24, Chao Yu wrote: On 2017/10/24 6:14, Jaegeuk Kim wrote: > This patch adds to call quota_intialize in f2fs_set_acl. > > Signed-off-by: Jaegeuk Kim

Re: [RFC PATCH 0/9] V4L2 Jobs API WIP

Hello, On Monday, 23 October 2017 11:45:01 EEST Alexandre Courbot wrote: > On Thu, Oct 19, 2017 at 11:43 PM, Sakari Ailus wrote: > > On Thu, Sep 28, 2017 at 06:50:18PM +0900, Alexandre Courbot wrote: > >> Hi everyone, > >> > >> Here is a new attempt at the "request" (which I propose to rename

Re: [f2fs-dev] [PATCH 1/2] f2fs: add missing quota_initialize in f2fs_set_acl

On 2017/10/25 14:30, Jaegeuk Kim wrote: > On 10/25, Chao Yu wrote: >> On 2017/10/25 13:44, Jaegeuk Kim wrote: >>> On 10/24, Chao Yu wrote: On 2017/10/24 6:14, Jaegeuk Kim wrote: > This patch adds to call quota_intialize in f2fs_set_acl. > > Signed-off-by: Jaegeuk Kim > ---

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

On 25/10/17 09:32 AM, sba...@raithlin.com wrote: From: Stephen Bates If the amount of resources allocated to a gen_pool exceeds 2^32 then the avail atomic overflows and this causes problems when clients try and borrow resources from the pool. Add the header to pull in

Re: [PATCH] genalloc: Make the avail variable an atomic64_t

On 25/10/17 09:32 AM, sba...@raithlin.com wrote: From: Stephen Bates If the amount of resources allocated to a gen_pool exceeds 2^32 then the avail atomic overflows and this causes problems when clients try and borrow resources from the pool. Add the header to pull in atomic64 operations

Re: [PATCH v3] f2fs: add cur_reserved_blocks to support soft block reservation

On 2017/10/25 22:06, Yunlong Song wrote: > Hi, Chao, >     Please see my comments below. > > On 2017/10/25 20:26, Chao Yu wrote: >> On 2017/10/25 18:02, Yunlong Song wrote: >>> ping... >> I've replied in this thread, check your email list please, or you can check >> the >> comments in below

Re: [PATCH v3] f2fs: add cur_reserved_blocks to support soft block reservation

On 2017/10/25 22:06, Yunlong Song wrote: > Hi, Chao, >     Please see my comments below. > > On 2017/10/25 20:26, Chao Yu wrote: >> On 2017/10/25 18:02, Yunlong Song wrote: >>> ping... >> I've replied in this thread, check your email list please, or you can check >> the >> comments in below

Re: [1/2] drivers: firmware: psci: Add psci_is_available()

On Wed, Oct 11, 2017 at 10:03:01AM +0200, Geert Uytterhoeven wrote: > PSCI support may be disabled at build time (by configuration) or at > run-time (PSCI firmware not present). While CONFIG_ARM_PSCI_FW can be > used to check for build time enablement, there is currently no simple > way to check

Re: [1/2] drivers: firmware: psci: Add psci_is_available()

On Wed, Oct 11, 2017 at 10:03:01AM +0200, Geert Uytterhoeven wrote: > PSCI support may be disabled at build time (by configuration) or at > run-time (PSCI firmware not present). While CONFIG_ARM_PSCI_FW can be > used to check for build time enablement, there is currently no simple > way to check

[PATCH] genalloc: Make the avail variable an atomic64_t

From: Stephen Bates If the amount of resources allocated to a gen_pool exceeds 2^32 then the avail atomic overflows and this causes problems when clients try and borrow resources from the pool. Add the header to pull in atomic64 operations on platforms that do not support

[PATCH] genalloc: Make the avail variable an atomic64_t

From: Stephen Bates If the amount of resources allocated to a gen_pool exceeds 2^32 then the avail atomic overflows and this causes problems when clients try and borrow resources from the pool. Add the header to pull in atomic64 operations on platforms that do not support them natively.

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli wrote: > Hi Jim, > > On 10/24/2017 11:15 AM, Jim Quinlan wrote: >> This commit adds MSI to the Broadcom STB PCIe host controller. It does >> not add MSIX since that functionality is not in the HW. The MSI >> controller is

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli wrote: > Hi Jim, > > On 10/24/2017 11:15 AM, Jim Quinlan wrote: >> This commit adds MSI to the Broadcom STB PCIe host controller. It does >> not add MSIX since that functionality is not in the HW. The MSI >> controller is physically located

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

V2 just sent to linuxppc-dev[0] list, with some simplifications. This one is then officially dropped! Thanks, Guilherme [0] http://patchwork.ozlabs.org/patch/830320

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

V2 just sent to linuxppc-dev[0] list, with some simplifications. This one is then officially dropped! Thanks, Guilherme [0] http://patchwork.ozlabs.org/patch/830320

Re [PATCH v2] lib: optimize cpumask_next_and()

Thanks for the comments Yury. > But I'd like also to keep _find_next_bit() consistent with > _find_next_bit_le() Not sure I understand what you're suggesting here: Do you want a find_next_and_bit_le() or do you want to make _find_next_bit_le() more like _find_next_bit() ? In the latter case we

Re [PATCH v2] lib: optimize cpumask_next_and()

Thanks for the comments Yury. > But I'd like also to keep _find_next_bit() consistent with > _find_next_bit_le() Not sure I understand what you're suggesting here: Do you want a find_next_and_bit_le() or do you want to make _find_next_bit_le() more like _find_next_bit() ? In the latter case we

[PATCH v8 1/2] crypto: s5p-sss: Change spaces to tabs

Change #define lines to use tabs consistently. Acked-by: Vladimir Zapolskiy Reviewed-by: Krzysztof Kozlowski Signed-off-by: Kamil Konieczny --- drivers/crypto/s5p-sss.c | 190 +++ 1

[PATCH v8 1/2] crypto: s5p-sss: Change spaces to tabs

Change #define lines to use tabs consistently. Acked-by: Vladimir Zapolskiy Reviewed-by: Krzysztof Kozlowski Signed-off-by: Kamil Konieczny --- drivers/crypto/s5p-sss.c | 190 +++ 1 file changed, 95 insertions(+), 95 deletions(-) diff --git

[PATCH v8 0/2] crypto: s5p-sss: Add HASH support for Exynos

First patch change spaces to tabs, second adds HASH support for Exynos. Changes: version 8: - fixes suggested by Vladimir Zapolskiy: drop first condition check in s5p_hash_import, delete unused include delay.h, fix typo in commit message, fix descriptions of struct s5p_hash_reqctx and

[PATCH v8 0/2] crypto: s5p-sss: Add HASH support for Exynos

First patch change spaces to tabs, second adds HASH support for Exynos. Changes: version 8: - fixes suggested by Vladimir Zapolskiy: drop first condition check in s5p_hash_import, delete unused include delay.h, fix typo in commit message, fix descriptions of struct s5p_hash_reqctx and

[PATCH v2] iommu: qcom: wire up fault handler

This is quite useful for debugging. Currently, always TERMINATE the translation when the fault handler returns (since this is all we need for debugging drivers). But I expect the SVM work should eventually let us do something more clever. Signed-off-by: Rob Clark --- v2:

[PATCH v2] iommu: qcom: wire up fault handler

This is quite useful for debugging. Currently, always TERMINATE the translation when the fault handler returns (since this is all we need for debugging drivers). But I expect the SVM work should eventually let us do something more clever. Signed-off-by: Rob Clark --- v2: add back a hunk that

[PATCH] iommu: qcom: wire up fault handler

This is quite useful for debugging. Currently, always TERMINATE the translation when the fault handler returns (since this is all we need for debugging drivers). But I expect the SVM work should eventually let us do something more clever. Signed-off-by: Rob Clark ---

[PATCH] iommu: qcom: wire up fault handler

This is quite useful for debugging. Currently, always TERMINATE the translation when the fault handler returns (since this is all we need for debugging drivers). But I expect the SVM work should eventually let us do something more clever. Signed-off-by: Rob Clark ---

[PATCH v8 2/2] crypto: s5p-sss: Add HASH support for Exynos

Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW. It uses the crypto framework asynchronous hash api. It is based on omap-sham.c driver. S5P has some HW differencies and is not implemented. Modifications in s5p-sss: - Add hash supporting structures and functions. - Modify irq

[PATCH v8 2/2] crypto: s5p-sss: Add HASH support for Exynos

Add support for MD5, SHA1, SHA256 hash algorithms for Exynos HW. It uses the crypto framework asynchronous hash api. It is based on omap-sham.c driver. S5P has some HW differencies and is not implemented. Modifications in s5p-sss: - Add hash supporting structures and functions. - Modify irq

Re: [PATCH 2/2] crypto: s5p-sss: Add HASH support for Exynos

Hi Vladimir, On 25.10.2017 17:09, Vladimir Zapolskiy wrote: > > thank you for updates, everything looks good from my point of view. > Thank you for your work, I am still newbie, I forgot 'v8' and to: linux-crypto :( So I will resend this patch series with improved title and your Ack added.

Re: [PATCH 2/2] crypto: s5p-sss: Add HASH support for Exynos

Hi Vladimir, On 25.10.2017 17:09, Vladimir Zapolskiy wrote: > > thank you for updates, everything looks good from my point of view. > Thank you for your work, I am still newbie, I forgot 'v8' and to: linux-crypto :( So I will resend this patch series with improved title and your Ack added.

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

Hi Jason, On 25 October 2017 at 20:48, Jason Gunthorpe wrote: > On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan > wrote: > >> > +static int tpm_add_hwrng(struct tpm_chip *chip) >> > +{ >> > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM)) >> >

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

Hi Jason, On 25 October 2017 at 20:48, Jason Gunthorpe wrote: > On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan > wrote: > >> > +static int tpm_add_hwrng(struct tpm_chip *chip) >> > +{ >> > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM)) >> > + return 0; >> >>

Re: [PATCH v2] tpm: use struct tpm_chip for tpm_chip_find_get()

On Wed, Oct 25, 2017 at 01:55:04PM +0200, Jarkko Sakkinen wrote: > Device number (the character device index) is not a stable identifier > for a TPM chip. That is the reason why every call site passes > TPM_ANY_NUM to tpm_chip_find_get(). > > This commit changes the API in a way that instead a

Re: [PATCH v2] tpm: use struct tpm_chip for tpm_chip_find_get()

On Wed, Oct 25, 2017 at 01:55:04PM +0200, Jarkko Sakkinen wrote: > Device number (the character device index) is not a stable identifier > for a TPM chip. That is the reason why every call site passes > TPM_ANY_NUM to tpm_chip_find_get(). > > This commit changes the API in a way that instead a

Re: [PATCH] thermal: cpu_cooling: pr_err() strings should end with newlines

On Tue, Oct 24, 2017 at 01:20:39PM +0530, Arvind Yadav wrote: > pr_err() messages should end with a new-line to avoid other messages > being concatenated. > > Signed-off-by: Arvind Yadav FWIW, Acked-by: Javi Merino > --- >

Re: [PATCH] thermal: cpu_cooling: pr_err() strings should end with newlines

On Tue, Oct 24, 2017 at 01:20:39PM +0530, Arvind Yadav wrote: > pr_err() messages should end with a new-line to avoid other messages > being concatenated. > > Signed-off-by: Arvind Yadav FWIW, Acked-by: Javi Merino > --- > drivers/thermal/cpu_cooling.c | 2 +- > 1 file changed, 1

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan wrote: > > +static int tpm_add_hwrng(struct tpm_chip *chip) > > +{ > > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM)) > > + return 0; > > Can #ifndef CONFIG_HW_RANDOM_TPM be used instead? That way an if >

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan wrote: > > +static int tpm_add_hwrng(struct tpm_chip *chip) > > +{ > > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM)) > > + return 0; > > Can #ifndef CONFIG_HW_RANDOM_TPM be used instead? That way an if >

Re: [PATCH v2] tpm: use struct tpm_chip for tpm_chip_find_get()

Hi Jarkko, On 25 October 2017 at 17:25, Jarkko Sakkinen wrote: > Device number (the character device index) is not a stable identifier > for a TPM chip. That is the reason why every call site passes > TPM_ANY_NUM to tpm_chip_find_get(). > > This commit changes

Re: [PATCH v2] tpm: use struct tpm_chip for tpm_chip_find_get()

Hi Jarkko, On 25 October 2017 at 17:25, Jarkko Sakkinen wrote: > Device number (the character device index) is not a stable identifier > for a TPM chip. That is the reason why every call site passes > TPM_ANY_NUM to tpm_chip_find_get(). > > This commit changes the API in a way that instead a

Re: [PATCH v2 0/7] fix fanotify issues with the series in v4.12

On Wed, Oct 25, 2017 at 5:31 PM, Miklos Szeredi wrote: > On Wed, Oct 25, 2017 at 10:41 AM, Miklos Szeredi wrote: >> We discovered some problems in the latest fsnotify/fanotify codebase with >> the help of a stress test (Xiong Zhou is working on

Re: [PATCH v2 0/7] fix fanotify issues with the series in v4.12

On Wed, Oct 25, 2017 at 5:31 PM, Miklos Szeredi wrote: > On Wed, Oct 25, 2017 at 10:41 AM, Miklos Szeredi wrote: >> We discovered some problems in the latest fsnotify/fanotify codebase with >> the help of a stress test (Xiong Zhou is working on upstreaming it to >> fstests). >> >> This series

Re: [PATCH 0/3] arm64: remove some unused defconfig options

On 10/25/2017 02:02 AM, Andy Gross wrote: > On Tue, Oct 24, 2017 at 05:20:20PM -0700, Stephen Boyd wrote: >> On 10/20, Alex Elder wrote: >>> This series deletes three config options related to USB on Qualcomm >>> SoCs from the arm64 "defconfig", along with the code that they >>> enable. The code

Re: [PATCH 0/3] arm64: remove some unused defconfig options

On 10/25/2017 02:02 AM, Andy Gross wrote: > On Tue, Oct 24, 2017 at 05:20:20PM -0700, Stephen Boyd wrote: >> On 10/20, Alex Elder wrote: >>> This series deletes three config options related to USB on Qualcomm >>> SoCs from the arm64 "defconfig", along with the code that they >>> enable. The code

[PATCH v6 0/6] Add MediaTek PMIC keys support

MediaTek PMIC are multi-function devices that can handle key interrupts, typically there are two keys attached to PMIC, which called pwrkey and homekey. PWRKEY usually used to wake up system from sleep. Homekey can used as volume down key due to board design. Long press keys can shutdown PMIC,

[PATCH v6 0/6] Add MediaTek PMIC keys support

MediaTek PMIC are multi-function devices that can handle key interrupts, typically there are two keys attached to PMIC, which called pwrkey and homekey. PWRKEY usually used to wake up system from sleep. Homekey can used as volume down key due to board design. Long press keys can shutdown PMIC,

Re: alpha boot hang - 4.14-rc* regression

On Wed, Oct 25, 2017 at 05:49:54PM +0300, Meelis Roos wrote: > > > > > removing libata modules and rebooting fixes it - so it seems to be > > > > > loading of libata. > > > > > > > > Can you please cherry-pick: > > > > > > > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order > >

Re: alpha boot hang - 4.14-rc* regression

On Wed, Oct 25, 2017 at 05:49:54PM +0300, Meelis Roos wrote: > > > > > removing libata modules and rebooting fixes it - so it seems to be > > > > > loading of libata. > > > > > > > > Can you please cherry-pick: > > > > > > > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order > >

Re: [PATCH v3 1/1] xen/time: do not decrease steal time after live migration on xen

On 10/25/2017 02:45 AM, Dongli Zhang wrote: > After guest live migration on xen, steal time in /proc/stat > (cpustat[CPUTIME_STEAL]) might decrease because steal returned by > xen_steal_lock() might be less than this_rq()->prev_steal_time which is > derived from previous return value of

Re: [PATCH v3 1/1] xen/time: do not decrease steal time after live migration on xen

On 10/25/2017 02:45 AM, Dongli Zhang wrote: > After guest live migration on xen, steal time in /proc/stat > (cpustat[CPUTIME_STEAL]) might decrease because steal returned by > xen_steal_lock() might be less than this_rq()->prev_steal_time which is > derived from previous return value of

[PATCH] xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()

In case gntdev_mmap() succeeds only partially in mapping grant pages it will leave some vital information uninitialized needed later for cleanup. This will lead to an out of bounds array access when unmapping the already mapped pages. So just initialize the data needed for unmapping the pages a

[PATCH] xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()

In case gntdev_mmap() succeeds only partially in mapping grant pages it will leave some vital information uninitialized needed later for cleanup. This will lead to an out of bounds array access when unmapping the already mapped pages. So just initialize the data needed for unmapping the pages a

<    2   3   4   5   6   7   8   9   10   11   >