[PATCH 01/11] media: vsp1: drm: Fix minor grammar error

The pixel format is 'unsupported'. Fix the small debug message which incorrectly declares this. Signed-off-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 01/11] media: vsp1: drm: Fix minor grammar error

The pixel format is 'unsupported'. Fix the small debug message which incorrectly declares this. Signed-off-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/vsp1/vsp1_drm.c

Re: [PATCH 2/2] watchdog: aspeed: Allow configuring for alternate boot

On Fri, Mar 09, 2018 at 03:58:20PM -0600, Eddie James wrote: > From: Milton Miller > > Allow the device tree to specify a watchdog to fallover to > the alternate boot source. > > The aspeeed watchdog can set a latch directing flash chip select 0 to > chip select 1, allowing

Re: [PATCH 2/2] watchdog: aspeed: Allow configuring for alternate boot

On Fri, Mar 09, 2018 at 03:58:20PM -0600, Eddie James wrote: > From: Milton Miller > > Allow the device tree to specify a watchdog to fallover to > the alternate boot source. > > The aspeeed watchdog can set a latch directing flash chip select 0 to > chip select 1, allowing boot from an

[PATCH 06/11] media: vsp1: Provide VSP1 feature helper macro

The VSP1 devices define their specific capabilities through features marked in their device info structure. Various parts of the code read this info structure to infer if the features are available. Wrap this into a more readable vsp1_feature(vsp1, f) macro to ensure that usage is consistent

[PATCH 06/11] media: vsp1: Provide VSP1 feature helper macro

The VSP1 devices define their specific capabilities through features marked in their device info structure. Various parts of the code read this info structure to infer if the features are available. Wrap this into a more readable vsp1_feature(vsp1, f) macro to ensure that usage is consistent

[PATCH 07/11] media: vsp1: Use header display lists for all WPF outputs linked to the DU

Header mode display lists are now supported on all WPF outputs. To support extended headers and auto-fld capabilities for interlaced mode handling only header mode display lists can be used. Disable the headerless display list configuration, and remove the dead code. Signed-off-by: Kieran

[PATCH 07/11] media: vsp1: Use header display lists for all WPF outputs linked to the DU

Header mode display lists are now supported on all WPF outputs. To support extended headers and auto-fld capabilities for interlaced mode handling only header mode display lists can be used. Disable the headerless display list configuration, and remove the dead code. Signed-off-by: Kieran

Re: [PATCH v2] ARM: dts: BCM5301X: Add support for Linksys EA9500

Date: Fri, 9 Mar 2018 16:56:11 -0500 From: Vivek Unune To: Florian Fainelli Cc: ha...@hauke-m.de, zaj...@gmail.com, jonma...@broadcom.com, bcm-kernel-feedback-l...@broadcom.com, robh...@kernel.org, mark.rutl...@arm.com,

Re: [PATCH v2] ARM: dts: BCM5301X: Add support for Linksys EA9500

Date: Fri, 9 Mar 2018 16:56:11 -0500 From: Vivek Unune To: Florian Fainelli Cc: ha...@hauke-m.de, zaj...@gmail.com, jonma...@broadcom.com, bcm-kernel-feedback-l...@broadcom.com, robh...@kernel.org, mark.rutl...@arm.com, li...@armlinux.org.uk,

[PATCH 05/11] media: vsp1: Clean up DLM objects on error

If there is an error allocating a display list within a DLM object the existing display lists are not free'd, and neither is the DL body pool. Use the existing vsp1_dlm_destroy() function to clean up on error. Signed-off-by: Kieran Bingham ---

[PATCH 08/11] media: vsp1: Add support for extended display list headers

Extended display list headers allow pre and post command lists to be executed by the VSP pipeline. This provides the base support for features such as AUTO_FLD (for interlaced support) and AUTO_DISP (for supporting continuous camera preview pipelines. Signed-off-by: Kieran Bingham

[PATCH 05/11] media: vsp1: Clean up DLM objects on error

If there is an error allocating a display list within a DLM object the existing display lists are not free'd, and neither is the DL body pool. Use the existing vsp1_dlm_destroy() function to clean up on error. Signed-off-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_dl.c | 4 +++- 1

[PATCH 08/11] media: vsp1: Add support for extended display list headers

Extended display list headers allow pre and post command lists to be executed by the VSP pipeline. This provides the base support for features such as AUTO_FLD (for interlaced support) and AUTO_DISP (for supporting continuous camera preview pipelines. Signed-off-by: Kieran Bingham ---

[PATCH 04/11] media: vsp1: Remove unused display list structure field

The vsp1 reference in the vsp1_dl_body structure is not used. Remove it. Signed-off-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_dl.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_dl.c

[PATCH 04/11] media: vsp1: Remove unused display list structure field

The vsp1 reference in the vsp1_dl_body structure is not used. Remove it. Signed-off-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_dl.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index

[PATCH 11/11] drm: rcar-du: Support interlaced video output through vsp1

Use the newly exposed VSP1 interface to enable interlaced frame support through the VSP1 lif pipelines. Signed-off-by: Kieran Bingham --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++ 2 files changed, 4

[PATCH 11/11] drm: rcar-du: Support interlaced video output through vsp1

Use the newly exposed VSP1 interface to enable interlaced frame support through the VSP1 lif pipelines. Signed-off-by: Kieran Bingham --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 3 +++ 2 files changed, 4 insertions(+) diff --git

[PATCH 10/11] media: vsp1: Support Interlaced display pipelines

Calculate the top and bottom fields for the interlaced frames and utilise the extended display list command feature to implement the auto-field operations. This allows the DU to update the VSP2 registers dynamically based upon the currently processing field. Signed-off-by: Kieran Bingham

Re: [PATCH 1/2] watchdog: aspeed: Fix translation of reset mode to ctrl register

On Fri, Mar 09, 2018 at 03:58:19PM -0600, Eddie James wrote: > From: Milton Miller > > Assert RESET_SYSTEM bit for any reset and set MODE field from reset > type. > > The watchdog control register has a RESET_SYSTEM bit that is really > closer to activate a reset, and

[PATCH 09/11] media: vsp1: Provide support for extended command pools

VSPD and VSP-DL devices can provide extended display lists supporting extended command display list objects. These extended commands require their own dma memory areas for a header and body specific to the command type. Implement a command pool to allocate all necessary memory in a single DMA

[PATCH 10/11] media: vsp1: Support Interlaced display pipelines

Calculate the top and bottom fields for the interlaced frames and utilise the extended display list command feature to implement the auto-field operations. This allows the DU to update the VSP2 registers dynamically based upon the currently processing field. Signed-off-by: Kieran Bingham ---

Re: [PATCH 1/2] watchdog: aspeed: Fix translation of reset mode to ctrl register

On Fri, Mar 09, 2018 at 03:58:19PM -0600, Eddie James wrote: > From: Milton Miller > > Assert RESET_SYSTEM bit for any reset and set MODE field from reset > type. > > The watchdog control register has a RESET_SYSTEM bit that is really > closer to activate a reset, and RESET_SYSTEM_MODE field

[PATCH 09/11] media: vsp1: Provide support for extended command pools

VSPD and VSP-DL devices can provide extended display lists supporting extended command display list objects. These extended commands require their own dma memory areas for a header and body specific to the command type. Implement a command pool to allocate all necessary memory in a single DMA

Re: [PATCH] Add an option to dm-verity to validate hashes at most once

Hi Milan, Yes, that is correct that the attacks it protects against is when the underlying storage is offline. We have discussed if we should reset the bitmap at certain events but decided against it. Cheers, Patrik On Thu, Mar 08, 2018 at 01:35:05PM +0100, Milan Broz wrote: > On 03/07/2018

Re: [PATCH] Add an option to dm-verity to validate hashes at most once

Hi Milan, Yes, that is correct that the attacks it protects against is when the underlying storage is offline. We have discussed if we should reset the bitmap at certain events but decided against it. Cheers, Patrik On Thu, Mar 08, 2018 at 01:35:05PM +0100, Milan Broz wrote: > On 03/07/2018

Re: Warning from swake_up_all in 4.14.15-rt13 non-RT

On 03/09/2018 11:46 AM, Peter Zijlstra wrote: On Fri, Mar 09, 2018 at 12:04:18PM +0100, Sebastian Andrzej Siewior wrote: +void swake_add_all_wq(struct swait_queue_head *q, struct wake_q_head *wq) { struct swait_queue *curr; while (!list_empty(>task_list)) { curr =

Re: Warning from swake_up_all in 4.14.15-rt13 non-RT

On 03/09/2018 11:46 AM, Peter Zijlstra wrote: On Fri, Mar 09, 2018 at 12:04:18PM +0100, Sebastian Andrzej Siewior wrote: +void swake_add_all_wq(struct swait_queue_head *q, struct wake_q_head *wq) { struct swait_queue *curr; while (!list_empty(>task_list)) { curr =

Re: [PATCH] pstore: use crypto compress API

On Fri, Mar 9, 2018 at 2:51 AM, Geliang Tang wrote: > In the pstore compression part, we use zlib/lzo/lz4/lz4hc/842 > compression algorithm API to implement pstore compression backends. But > there are many repeat codes in these implementations. This patch uses > crypto

Re: [PATCH] pstore: use crypto compress API

On Fri, Mar 9, 2018 at 2:51 AM, Geliang Tang wrote: > In the pstore compression part, we use zlib/lzo/lz4/lz4hc/842 > compression algorithm API to implement pstore compression backends. But > there are many repeat codes in these implementations. This patch uses > crypto compress API to simplify

Re: [PATCH v4 3/3 update] mm/free_pcppages_bulk: prefetch buddy while not holding lock

> > When a page is freed back to the global pool, its buddy will be checked > to see if it's possible to do a merge. This requires accessing buddy's > page structure and that access could take a long time if it's cache cold. > > This patch adds a prefetch to the to-be-freed page's buddy outside

Re: [PATCH v2] exec: Set file unwritable before LSM check

On Fri, 2018-03-09 at 11:54 -0800, Kees Cook wrote: > On Fri, Mar 9, 2018 at 11:47 AM, Linus Torvalds > wrote: > > On Fri, Mar 9, 2018 at 11:30 AM, Kees Cook wrote: > >> The LSM check should happen after the file has been confirmed to be > >>

Re: [PATCH v4 3/3 update] mm/free_pcppages_bulk: prefetch buddy while not holding lock

> > When a page is freed back to the global pool, its buddy will be checked > to see if it's possible to do a merge. This requires accessing buddy's > page structure and that access could take a long time if it's cache cold. > > This patch adds a prefetch to the to-be-freed page's buddy outside

Re: [PATCH v2] exec: Set file unwritable before LSM check

On Fri, 2018-03-09 at 11:54 -0800, Kees Cook wrote: > On Fri, Mar 9, 2018 at 11:47 AM, Linus Torvalds > wrote: > > On Fri, Mar 9, 2018 at 11:30 AM, Kees Cook wrote: > >> The LSM check should happen after the file has been confirmed to be > >> unchanging. Without this, we could have a race

[PATCH 2/2] watchdog: aspeed: Allow configuring for alternate boot

From: Milton Miller Allow the device tree to specify a watchdog to fallover to the alternate boot source. The aspeeed watchdog can set a latch directing flash chip select 0 to chip select 1, allowing boot from an alternate media if the watchdog is not reset in time. On the

[PATCH 2/2] watchdog: aspeed: Allow configuring for alternate boot

From: Milton Miller Allow the device tree to specify a watchdog to fallover to the alternate boot source. The aspeeed watchdog can set a latch directing flash chip select 0 to chip select 1, allowing boot from an alternate media if the watchdog is not reset in time. On the ast2400 bank 1 also

[PATCH 1/2] watchdog: aspeed: Fix translation of reset mode to ctrl register

From: Milton Miller Assert RESET_SYSTEM bit for any reset and set MODE field from reset type. The watchdog control register has a RESET_SYSTEM bit that is really closer to activate a reset, and RESET_SYSTEM_MODE field that chooses how much to reset. Before this patch, a

[PATCH 1/2] watchdog: aspeed: Fix translation of reset mode to ctrl register

From: Milton Miller Assert RESET_SYSTEM bit for any reset and set MODE field from reset type. The watchdog control register has a RESET_SYSTEM bit that is really closer to activate a reset, and RESET_SYSTEM_MODE field that chooses how much to reset. Before this patch, a node without these

[PATCH 0/2] aspeed: watchdog: fix system reset and read alt-boot option

This series provides a fix to correctly set the reset mode of the control register. Previously, configuring anything other than a full chip reset would not reset anything when the watchdog timer expires. The series also provides a patch to read in the existing aspeed,alt-boot boolean option from

[PATCH 0/2] aspeed: watchdog: fix system reset and read alt-boot option

This series provides a fix to correctly set the reset mode of the control register. Previously, configuring anything other than a full chip reset would not reset anything when the watchdog timer expires. The series also provides a patch to read in the existing aspeed,alt-boot boolean option from

Re: [PATCH] f2fs: avoid selinux denial on CAP_SYS_RESOURCE

On 03/09, Chao Yu wrote: > On 2018/3/9 12:49, Jaegeuk Kim wrote: > > This fixes CAP_SYS_RESOURCE denial of selinux when using resgid. > > A little confusion, if capable(CAP_SYS_RESOURCE) is false, we still have > chance > to return true for below resuid & resgid cases, right? I didn't dig it

Re: [PATCH] f2fs: avoid selinux denial on CAP_SYS_RESOURCE

On 03/09, Chao Yu wrote: > On 2018/3/9 12:49, Jaegeuk Kim wrote: > > This fixes CAP_SYS_RESOURCE denial of selinux when using resgid. > > A little confusion, if capable(CAP_SYS_RESOURCE) is false, we still have > chance > to return true for below resuid & resgid cases, right? I didn't dig it

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 1:10 PM, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote: >> When max() is used in stack array size calculations from literal values >> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]",

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 1:10 PM, Linus Torvalds wrote: > On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote: >> When max() is used in stack array size calculations from literal values >> (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler >> thinks this is a dynamic calculation

Re: [PATCH v3 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

On Fri, Mar 9, 2018 at 1:33 PM, Lina Iyer wrote: > Hi Stephen, > > I will address all the comments in the next spin of the patch. Here are > some responses to the questions. > > On Tue, Mar 06 2018 at 12:45 -0700, Stephen Boyd wrote: >> >> Quoting Lina Iyer (2018-03-02

Re: [PATCH v3 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

On Fri, Mar 9, 2018 at 1:33 PM, Lina Iyer wrote: > Hi Stephen, > > I will address all the comments in the next spin of the patch. Here are > some responses to the questions. > > On Tue, Mar 06 2018 at 12:45 -0700, Stephen Boyd wrote: >> >> Quoting Lina Iyer (2018-03-02 08:43:08) > > [...] >> >>

Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling

On Thu, Mar 08, 2018 at 05:28:44PM +, Marc Zyngier wrote: > On Thu, 08 Mar 2018 16:19:00 +, > Christoffer Dall wrote: > > > > On Thu, Mar 08, 2018 at 11:54:27AM +, Marc Zyngier wrote: > > > On 08/03/18 09:49, Marc Zyngier wrote: [...] > > > The state is now pending, we've really

Re: [RFC PATCH] KVM: arm/arm64: vgic: change condition for level interrupt resampling

On Thu, Mar 08, 2018 at 05:28:44PM +, Marc Zyngier wrote: > On Thu, 08 Mar 2018 16:19:00 +, > Christoffer Dall wrote: > > > > On Thu, Mar 08, 2018 at 11:54:27AM +, Marc Zyngier wrote: > > > On 08/03/18 09:49, Marc Zyngier wrote: [...] > > > The state is now pending, we've really

[PATCH v2] powerpc/64: Fix section mismatch warnings for early boot symbols

Some of the boot code located at the start of kernel text is "init" class, in that it only runs at boot time, however marking it as normal init code is problematic because that puts it into a different section located at the very end of kernel text. e.g., in case the TOC is not set up, we may not

[PATCH v2] powerpc/64: Fix section mismatch warnings for early boot symbols

Some of the boot code located at the start of kernel text is "init" class, in that it only runs at boot time, however marking it as normal init code is problematic because that puts it into a different section located at the very end of kernel text. e.g., in case the TOC is not set up, we may not

[GIT PULL] KVM fixes for Linux 4.16-rc5

Linus, The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1: Linux 4.16-rc4 (2018-03-04 14:54:11 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm tags/for-linus for you to fetch changes up to

[GIT PULL] KVM fixes for Linux 4.16-rc5

Linus, The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1: Linux 4.16-rc4 (2018-03-04 14:54:11 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm tags/for-linus for you to fetch changes up to

[PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp

While having the modeset_retry_work in intel_connector makes sense with SST, this paradigm doesn't make a whole ton of sense when it comes to MST since we have to deal with multiple connectors. In most cases, it's more useful to just use the intel_dp struct since it indicates whether or not we're

[PATCH v3 3/5] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate()

Unlike SST, MST can have far more then a single display hooked up on a single port. What this also means however, is that if the DisplayPort link to the top-level MST branch device becomes unstable then every single branch device also has an unstable link. Additionally, MST has a few more steps

[PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp

While having the modeset_retry_work in intel_connector makes sense with SST, this paradigm doesn't make a whole ton of sense when it comes to MST since we have to deal with multiple connectors. In most cases, it's more useful to just use the intel_dp struct since it indicates whether or not we're

[PATCH v3 3/5] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate()

Unlike SST, MST can have far more then a single display hooked up on a single port. What this also means however, is that if the DisplayPort link to the top-level MST branch device becomes unstable then every single branch device also has an unstable link. Additionally, MST has a few more steps

[PATCH v3 5/5] drm/i915: Implement proper fallback training for MST

For a while we actually haven't had any way of retraining MST links with fallback link parameters like we do with SST. While uncommon, certain setups such as my Caldigit TS3 + EVGA MST hub require this since otherwise, they end up getting stuck in an infinite MST retraining loop. MST retraining

[PATCH v3 5/5] drm/i915: Implement proper fallback training for MST

For a while we actually haven't had any way of retraining MST links with fallback link parameters like we do with SST. While uncommon, certain setups such as my Caldigit TS3 + EVGA MST hub require this since otherwise, they end up getting stuck in an infinite MST retraining loop. MST retraining

[PATCH v3 2/5] drm/i915: Only use one link bw config for MST topologies

When a DP MST link needs retraining, sometimes the hub will detect that the current link bw config is impossible and will update it's RX caps in the DPCD to reflect the new maximum link rate. Currently, we make the assumption that the RX caps in the dpcd will never change like this. This means if

[PATCH v3 2/5] drm/i915: Only use one link bw config for MST topologies

When a DP MST link needs retraining, sometimes the hub will detect that the current link bw config is impossible and will update it's RX caps in the DPCD to reflect the new maximum link rate. Currently, we make the assumption that the RX caps in the dpcd will never change like this. This means if

Re: [PATCH v3 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

Hi Stephen, I will address all the comments in the next spin of the patch. Here are some responses to the questions. On Tue, Mar 06 2018 at 12:45 -0700, Stephen Boyd wrote: Quoting Lina Iyer (2018-03-02 08:43:08) [...] +#include If the driver doesn't become tristate, this should become

Re: [PATCH v3 01/10] drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

Hi Stephen, I will address all the comments in the next spin of the patch. Here are some responses to the questions. On Tue, Mar 06 2018 at 12:45 -0700, Stephen Boyd wrote: Quoting Lina Iyer (2018-03-02 08:43:08) [...] +#include If the driver doesn't become tristate, this should become

[PATCH v3 4/5] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology()

Retraining MST is rather difficult. In order to do it properly while guaranteeing that we'll never run into a spot where we commit a physically impossible configuration, we have to do a lot of checks on atomic commits which affect MST topologies. All of this work is going to need to be repeated

[PATCH v3 4/5] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology()

Retraining MST is rather difficult. In order to do it properly while guaranteeing that we'll never run into a spot where we commit a physically impossible configuration, we have to do a lot of checks on atomic commits which affect MST topologies. All of this work is going to need to be repeated

Re: [PATCH 1/6] reset: qcom: AOSS (Always on subsystem) reset controller

Sibi, One cosmetic comment below. On 3/9/2018 6:55 AM, Sibi S wrote: + +This binding describes a reset-controller found on AOSS (Always on SubSysem) +for Qualcomm SDM845 SoCs. S/SubSysem/Subsytem ---Trilok Soni

Re: [PATCH 1/6] reset: qcom: AOSS (Always on subsystem) reset controller

Sibi, One cosmetic comment below. On 3/9/2018 6:55 AM, Sibi S wrote: + +This binding describes a reset-controller found on AOSS (Always on SubSysem) +for Qualcomm SDM845 SoCs. S/SubSysem/Subsytem ---Trilok Soni

Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

On Fri, Mar 09, 2018 at 10:54:27AM -0800, Palmer Dabbelt wrote: > On Fri, 09 Mar 2018 10:36:44 PST (-0800), parri.and...@gmail.com wrote: [...] > >This belongs to the "few style fixes" (in the specific, 80-chars lines) > >mentioned in the cover letter; I could not resist ;-), but I'll remove >

Re: [PATCH v2 2/2] riscv/atomic: Strengthen implementations with fences

On Fri, Mar 09, 2018 at 10:54:27AM -0800, Palmer Dabbelt wrote: > On Fri, 09 Mar 2018 10:36:44 PST (-0800), parri.and...@gmail.com wrote: [...] > >This belongs to the "few style fixes" (in the specific, 80-chars lines) > >mentioned in the cover letter; I could not resist ;-), but I'll remove >

[PATCH] net/9p: avoid -ERESTARTSYS leak to userspace

If it was interrupted by a signal, the 9p client may need to send some more requests to the server for cleanup before returning to userspace. To avoid such a last minute request to be interrupted right away, the client memorizes if a signal is pending, clears TIF_SIGPENDING, handles the request

[PATCH] net/9p: avoid -ERESTARTSYS leak to userspace

If it was interrupted by a signal, the 9p client may need to send some more requests to the server for cleanup before returning to userspace. To avoid such a last minute request to be interrupted right away, the client memorizes if a signal is pending, clears TIF_SIGPENDING, handles the request

Re: [PATCH v3] input: bcm5974 - Add driver for Apple Magic Trackpad 2

Hi Stephan, I would like to have Touchpad 2 properly supported. You will find proper prior support for Magic Trackpads in drivers/hid/hid-magicmouse.c. Henrik

Re: [PATCH v3] input: bcm5974 - Add driver for Apple Magic Trackpad 2

Hi Stephan, I would like to have Touchpad 2 properly supported. You will find proper prior support for Magic Trackpads in drivers/hid/hid-magicmouse.c. Henrik

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

On Fri, Mar 9, 2018 at 12:45 PM, Alan Cox wrote: > > If you want to be taken seriously then I think minimum you also need to > - Give a GPG key for messages to the list Oh, I don't want to be taken seriously by people who use gpg encrypted email. It's garbage and

Re: [PATCH] [v2] docs: clarify security-bugs disclosure policy

On Fri, Mar 9, 2018 at 12:45 PM, Alan Cox wrote: > > If you want to be taken seriously then I think minimum you also need to > - Give a GPG key for messages to the list Oh, I don't want to be taken seriously by people who use gpg encrypted email. It's garbage and should be shunned as such. I

94d3a25408: kernel_BUG_at_kernel/fork.c

FYI, we noticed the following commit (built with gcc-7): commit: 94d3a254089a7cd4f11b7071b4323afd98eea0a6 ("Detect early free of a live mm") url: https://github.com/0day-ci/linux/commits/Mark-Rutland/Detect-early-free-of-a-live-mm/20180303-144149 in testcase: boot on test machine:

94d3a25408: kernel_BUG_at_kernel/fork.c

FYI, we noticed the following commit (built with gcc-7): commit: 94d3a254089a7cd4f11b7071b4323afd98eea0a6 ("Detect early free of a live mm") url: https://github.com/0day-ci/linux/commits/Mark-Rutland/Detect-early-free-of-a-live-mm/20180303-144149 in testcase: boot on test machine:

[PATCH v4 1/7] interconnect: Add generic on-chip interconnect API

This patch introduce a new API to get requirements and configure the interconnect buses across the entire chipset to fit with the current demand. The API is using a consumer/provider-based model, where the providers are the interconnect buses and the consumers could be various drivers. The

[PATCH v4 1/7] interconnect: Add generic on-chip interconnect API

This patch introduce a new API to get requirements and configure the interconnect buses across the entire chipset to fit with the current demand. The API is using a consumer/provider-based model, where the providers are the interconnect buses and the consumers could be various drivers. The

[PATCH v4 0/7] Introduce on-chip interconnect API

Modern SoCs have multiple processors and various dedicated cores (video, gpu, graphics, modem). These cores are talking to each other and can generate a lot of data flowing through the on-chip interconnects. These interconnect buses could form different topologies such as crossbar, point to point

[PATCH v4 0/7] Introduce on-chip interconnect API

Modern SoCs have multiple processors and various dedicated cores (video, gpu, graphics, modem). These cores are talking to each other and can generate a lot of data flowing through the on-chip interconnects. These interconnect buses could form different topologies such as crossbar, point to point

[PATCH v4 4/7] interconnect: qcom: Add RPM communication

On some Qualcomm SoCs, there is a remote processor, which controls some of the Network-On-Chip interconnect resources. Other CPUs express their needs by communicating with this processor. Add a driver to handle comminication with this remote processor. Signed-off-by: Georgi Djakov

[PATCH v4 2/7] dt-bindings: Introduce interconnect provider bindings

This binding is intended to represent the interconnect hardware present in some of the modern SoCs. Currently it consists only of a binding for the interconnect hardware devices (provider). Signed-off-by: Georgi Djakov --- .../bindings/interconnect/interconnect.txt

[PATCH v4 3/7] interconnect: Add debugfs support

Add a functionality to provide information about the current constraints per each node and provider. Signed-off-by: Georgi Djakov --- drivers/interconnect/core.c | 70 + 1 file changed, 70 insertions(+) diff --git

[PATCH v4 4/7] interconnect: qcom: Add RPM communication

On some Qualcomm SoCs, there is a remote processor, which controls some of the Network-On-Chip interconnect resources. Other CPUs express their needs by communicating with this processor. Add a driver to handle comminication with this remote processor. Signed-off-by: Georgi Djakov ---

[PATCH v4 2/7] dt-bindings: Introduce interconnect provider bindings

This binding is intended to represent the interconnect hardware present in some of the modern SoCs. Currently it consists only of a binding for the interconnect hardware devices (provider). Signed-off-by: Georgi Djakov --- .../bindings/interconnect/interconnect.txt | 47

[PATCH v4 3/7] interconnect: Add debugfs support

Add a functionality to provide information about the current constraints per each node and provider. Signed-off-by: Georgi Djakov --- drivers/interconnect/core.c | 70 + 1 file changed, 70 insertions(+) diff --git a/drivers/interconnect/core.c

[PATCH v4 5/7] interconnect: qcom: Add msm8916 interconnect provider driver

Add driver for the Qualcomm interconnect buses found in msm8916 based platforms. Signed-off-by: Georgi Djakov --- drivers/interconnect/Kconfig| 5 + drivers/interconnect/Makefile | 1 + drivers/interconnect/qcom/Kconfig | 11 +

[PATCH v4 5/7] interconnect: qcom: Add msm8916 interconnect provider driver

Add driver for the Qualcomm interconnect buses found in msm8916 based platforms. Signed-off-by: Georgi Djakov --- drivers/interconnect/Kconfig| 5 + drivers/interconnect/Makefile | 1 + drivers/interconnect/qcom/Kconfig | 11 + drivers/interconnect/qcom/Makefile | 2 +

[PATCH v4 7/7] interconnect: Allow endpoints translation via DT

Currently we support only platform data for specifying the interconnect endpoints. As now the endpoints are hard-coded into the consumer driver this may leed to complications when a single driver is used by multiple SoCs, which may have different interconnect topology. To avoid cluttering the

[PATCH v4 7/7] interconnect: Allow endpoints translation via DT

Currently we support only platform data for specifying the interconnect endpoints. As now the endpoints are hard-coded into the consumer driver this may leed to complications when a single driver is used by multiple SoCs, which may have different interconnect topology. To avoid cluttering the

[PATCH v4 6/7] dt-bindings: Introduce interconnect consumers bindings

Add documentation for the interconnect consumer bindings, that will allow to link a device node (consumer) to its interconnect controller hardware. Tha aim is to enable drivers to request a framework API to configure an interconnect path by providing their struct device pointer and a name.

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote: > When max() is used in stack array size calculations from literal values > (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler > thinks this is a dynamic calculation due to the single-eval logic, which >

[PATCH v4 6/7] dt-bindings: Introduce interconnect consumers bindings

Add documentation for the interconnect consumer bindings, that will allow to link a device node (consumer) to its interconnect controller hardware. Tha aim is to enable drivers to request a framework API to configure an interconnect path by providing their struct device pointer and a name.

Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

On Fri, Mar 9, 2018 at 12:05 PM, Kees Cook wrote: > When max() is used in stack array size calculations from literal values > (e.g. "char foo[max(sizeof(struct1), sizeof(struct2))]", the compiler > thinks this is a dynamic calculation due to the single-eval logic, which > is not needed in the

Re: [PATCH v5 3/4] arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP

Hi, On Wed, Feb 21, 2018 at 10:12 PM, Rajendra Nayak wrote: > + gcc: clock-controller@10 { > + compatible = "qcom,gcc-sdm845"; > + reg = <0x10 0x1f>; > + #clock-cells = <1>; > +

Re: [PATCH v5 3/4] arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP

Hi, On Wed, Feb 21, 2018 at 10:12 PM, Rajendra Nayak wrote: > + gcc: clock-controller@10 { > + compatible = "qcom,gcc-sdm845"; > + reg = <0x10 0x1f>; > + #clock-cells = <1>; > +

Re: [PATCH][RFC] rslib: Remove VLAs by setting upper bound on nroots

On Fri, Mar 9, 2018 at 7:49 AM, Thomas Gleixner wrote: > On Fri, 9 Mar 2018, Kees Cook wrote: > >> Avoid VLAs[1] by always allocating the upper bound of stack space >> needed. The existing users of rslib appear to max out at 32 roots, >> so use that as the upper bound. > > I

Re: [PATCH][RFC] rslib: Remove VLAs by setting upper bound on nroots

On Fri, Mar 9, 2018 at 7:49 AM, Thomas Gleixner wrote: > On Fri, 9 Mar 2018, Kees Cook wrote: > >> Avoid VLAs[1] by always allocating the upper bound of stack space >> needed. The existing users of rslib appear to max out at 32 roots, >> so use that as the upper bound. > > I think 32 is plenty.

Re: [PATCH v2] perf machine: Fix load kernel symbol with '-k' option

On Fri, Mar 09, 2018 at 02:05:23PM +0800, Leo Yan wrote: > On Hikey arm64 octa A53 platform, when use command './perf report -v > -k vmlinux --stdio' it outputs below error info, and it skips to load > kernel symbol and doesn't print symbol for event: > Failed to open [kernel.kallsyms]_text,

Re: [PATCH v2] perf machine: Fix load kernel symbol with '-k' option

On Fri, Mar 09, 2018 at 02:05:23PM +0800, Leo Yan wrote: > On Hikey arm64 octa A53 platform, when use command './perf report -v > -k vmlinux --stdio' it outputs below error info, and it skips to load > kernel symbol and doesn't print symbol for event: > Failed to open [kernel.kallsyms]_text,

<    4   5   6   7   8   9   10   11   12   13   >