[PATCH v5 08/23] iommu/vt-d: support flushing more translation cache types

When Shared Virtual Memory is exposed to a guest via vIOMMU, extended IOTLB invalidation may be passed down from outside IOMMU subsystems. This patch adds invalidation functions that can be used for additional translation cache types. Signed-off-by: Jacob Pan --- drivers/iommu/dmar.c|

[PATCH v5 00/23] IOMMU and VT-d driver support for Shared Virtual Address (SVA)

Shared virtual address (SVA), a.k.a, Shared virtual memory (SVM) on Intel platforms allow address space sharing between device DMA and applications. SVA can reduce programming complexity and enhance security. To enable SVA in the guest, i.e. shared guest application address space and physical

[PATCH v5 11/23] driver core: add per device iommu param

DMA faults can be detected by IOMMU at device level. Adding a pointer to struct device allows IOMMU subsystem to report relevant faults back to the device driver for further handling. For direct assigned device (or user space drivers), guest OS holds responsibility to handle and respond per device

[PATCH v5 10/23] iommu: introduce device fault data

Device faults detected by IOMMU can be reported outside IOMMU subsystem for further processing. This patch intends to provide a generic device fault data such that device drivers can be communicated with IOMMU faults without model specific knowledge. The proposed format is the result of

[PATCH v5 11/23] driver core: add per device iommu param

DMA faults can be detected by IOMMU at device level. Adding a pointer to struct device allows IOMMU subsystem to report relevant faults back to the device driver for further handling. For direct assigned device (or user space drivers), guest OS holds responsibility to handle and respond per device

[PATCH v5 10/23] iommu: introduce device fault data

Device faults detected by IOMMU can be reported outside IOMMU subsystem for further processing. This patch intends to provide a generic device fault data such that device drivers can be communicated with IOMMU faults without model specific knowledge. The proposed format is the result of

[PATCH v5 02/23] iommu/vt-d: move device_domain_info to header

Allow both intel-iommu.c and dmar.c to access device_domain_info. Prepare for additional per device arch data used in TLB flush function Signed-off-by: Jacob Pan --- drivers/iommu/intel-iommu.c | 18 -- include/linux/intel-iommu.h | 19

[PATCH v5 02/23] iommu/vt-d: move device_domain_info to header

Allow both intel-iommu.c and dmar.c to access device_domain_info. Prepare for additional per device arch data used in TLB flush function Signed-off-by: Jacob Pan --- drivers/iommu/intel-iommu.c | 18 -- include/linux/intel-iommu.h | 19 +++ 2 files changed, 19

[PATCH v5 09/23] iommu/vt-d: add svm/sva invalidate function

When Shared Virtual Address (SVA) is enabled for a guest OS via vIOMMU, we need to provide invalidation support at IOMMU API and driver level. This patch adds Intel VT-d specific function to implement iommu passdown invalidate API for shared virtual address. The use case is for supporting caching

[PATCH v5 09/23] iommu/vt-d: add svm/sva invalidate function

When Shared Virtual Address (SVA) is enabled for a guest OS via vIOMMU, we need to provide invalidation support at IOMMU API and driver level. This patch adds Intel VT-d specific function to implement iommu passdown invalidate API for shared virtual address. The use case is for supporting caching

[PATCH v5 12/23] iommu: add a timeout parameter for prq response

When an IO page request is processed outside IOMMU subsystem, response can be delayed or lost. Add a tunable setup parameter such that user can chooose the timeout for IOMMU to track pending page requests. This timeout mechanism is a basic safty net which can be implemented in conjunction with

[PATCH v5 12/23] iommu: add a timeout parameter for prq response

When an IO page request is processed outside IOMMU subsystem, response can be delayed or lost. Add a tunable setup parameter such that user can chooose the timeout for IOMMU to track pending page requests. This timeout mechanism is a basic safty net which can be implemented in conjunction with

Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver

On Fri, May 11, 2018 at 01:17:04PM -0300, Paul Cercueil wrote: > Le 11 mai 2018 11:52, James Hogan a écrit : > > Otherwise > > Acked-by: James Hogan > > > > I'm happy to apply for 4.18 with that change if you want it to go > > through the MIPS tree. > >

[PATCH v5 16/23] iommu/config: add build dependency for dmar

Intel VT-d interrupts come from both IRQ remapping and DMA remapping. In order to report non-recoverable faults back to device driver, we need to have access to IOMMU fault reporting APIs. This patch adds build depenency to DMAR code where fault IRQ handlers can selectively report faults.

Re: [PATCH v3 5/8] MIPS: jz4740: dts: Add bindings for the jz4740-wdt driver

On Fri, May 11, 2018 at 01:17:04PM -0300, Paul Cercueil wrote: > Le 11 mai 2018 11:52, James Hogan a écrit : > > Otherwise > > Acked-by: James Hogan > > > > I'm happy to apply for 4.18 with that change if you want it to go > > through the MIPS tree. > > Yes please! Done Thanks James

[PATCH v5 16/23] iommu/config: add build dependency for dmar

Intel VT-d interrupts come from both IRQ remapping and DMA remapping. In order to report non-recoverable faults back to device driver, we need to have access to IOMMU fault reporting APIs. This patch adds build depenency to DMAR code where fault IRQ handlers can selectively report faults.

[PATCH v5 15/23] iommu: handle page response timeout

When IO page faults are reported outside IOMMU subsystem, the page request handler may fail for various reasons. E.g. a guest received page requests but did not have a chance to run for a long time. The irresponsive behavior could hold off limited resources on the pending device. There can be

[PATCH v5 15/23] iommu: handle page response timeout

When IO page faults are reported outside IOMMU subsystem, the page request handler may fail for various reasons. E.g. a guest received page requests but did not have a chance to run for a long time. The irresponsive behavior could hold off limited resources on the pending device. There can be

[PATCH v5 13/23] iommu: introduce device fault report API

Traditionally, device specific faults are detected and handled within their own device drivers. When IOMMU is enabled, faults such as DMA related transactions are detected by IOMMU. There is no generic reporting mechanism to report faults back to the in-kernel device driver or the guest OS in case

[PATCH v5 13/23] iommu: introduce device fault report API

Traditionally, device specific faults are detected and handled within their own device drivers. When IOMMU is enabled, faults such as DMA related transactions are detected by IOMMU. There is no generic reporting mechanism to report faults back to the in-kernel device driver or the guest OS in case

[PATCH v5 17/23] iommu/vt-d: report non-recoverable faults to device

Currently, dmar fault IRQ handler does nothing more than rate limited printk, no critical hardware handling need to be done in IRQ context. For some use case such as vIOMMU, it might be useful to report non-recoverable faults outside host IOMMU subsystem. DMAR fault can come from both DMA and

[PATCH v5 14/23] iommu: introduce page response function

IO page faults can be handled outside IOMMU subsystem. For an example, when nested translation is turned on and guest owns the first level page tables, device page request can be forwared to the guest for handling faults. As the page response returns by the guest, IOMMU driver on the host need to

[PATCH v5 17/23] iommu/vt-d: report non-recoverable faults to device

Currently, dmar fault IRQ handler does nothing more than rate limited printk, no critical hardware handling need to be done in IRQ context. For some use case such as vIOMMU, it might be useful to report non-recoverable faults outside host IOMMU subsystem. DMAR fault can come from both DMA and

[PATCH v5 14/23] iommu: introduce page response function

IO page faults can be handled outside IOMMU subsystem. For an example, when nested translation is turned on and guest owns the first level page tables, device page request can be forwared to the guest for handling faults. As the page response returns by the guest, IOMMU driver on the host need to

[PATCH v5 19/23] iommu/intel-svm: replace dev ops with fault report API

With the introduction of generic IOMMU device fault reporting API, we can replace the private fault callback functions with standard function and event data. Signed-off-by: Jacob Pan --- drivers/iommu/intel-svm.c | 7 +-- include/linux/intel-svm.h | 20

[PATCH v5 19/23] iommu/intel-svm: replace dev ops with fault report API

With the introduction of generic IOMMU device fault reporting API, we can replace the private fault callback functions with standard function and event data. Signed-off-by: Jacob Pan --- drivers/iommu/intel-svm.c | 7 +-- include/linux/intel-svm.h | 20 +++- 2 files

[PATCH v5 22/23] trace/iommu: add sva trace events

Signed-off-by: Jacob Pan --- include/trace/events/iommu.h | 112 +++ 1 file changed, 112 insertions(+) diff --git a/include/trace/events/iommu.h b/include/trace/events/iommu.h index 72b4582..e64eb29 100644 ---

[PATCH v5 06/23] iommu/vt-d: add definitions for PFSID

When SRIOV VF device IOTLB is invalidated, we need to provide the PF source ID such that IOMMU hardware can gauge the depth of invalidation queue which is shared among VFs. This is needed when device invalidation throttle (DIT) capability is supported. This patch adds bit definitions for checking

[PATCH v5 06/23] iommu/vt-d: add definitions for PFSID

When SRIOV VF device IOTLB is invalidated, we need to provide the PF source ID such that IOMMU hardware can gauge the depth of invalidation queue which is shared among VFs. This is needed when device invalidation throttle (DIT) capability is supported. This patch adds bit definitions for checking

[PATCH v5 22/23] trace/iommu: add sva trace events

Signed-off-by: Jacob Pan --- include/trace/events/iommu.h | 112 +++ 1 file changed, 112 insertions(+) diff --git a/include/trace/events/iommu.h b/include/trace/events/iommu.h index 72b4582..e64eb29 100644 --- a/include/trace/events/iommu.h +++

[PATCH v5 18/23] iommu/intel-svm: report device page request

If the source device of a page request has its PASID table pointer bound to a guest, the first level page tables are owned by the guest. In this case, we shall let guest OS to manage page fault. This patch uses the IOMMU fault reporting API to send fault events, possibly via VFIO, to the guest

[PATCH v5 23/23] iommu: use sva invalidate and device fault trace event

For performance and debugging purposes, these trace events help analyzing device faults and passdown invalidations that interact with IOMMU subsystem. E.g. IOMMU::00:0a.0 type=2 reason=0 addr=0x007ff000 pasid=1 group=1 last=0 prot=1 Signed-off-by: Jacob Pan

[PATCH v5 21/23] iommu/vt-d: add intel iommu page response function

This patch adds page response support for Intel VT-d. Generic response data is taken from the IOMMU API then parsed into VT-d specific response descriptor format. Signed-off-by: Jacob Pan --- drivers/iommu/intel-iommu.c | 47

[PATCH v5 23/23] iommu: use sva invalidate and device fault trace event

For performance and debugging purposes, these trace events help analyzing device faults and passdown invalidations that interact with IOMMU subsystem. E.g. IOMMU::00:0a.0 type=2 reason=0 addr=0x007ff000 pasid=1 group=1 last=0 prot=1 Signed-off-by: Jacob Pan --- drivers/iommu/iommu.c

[PATCH v5 21/23] iommu/vt-d: add intel iommu page response function

This patch adds page response support for Intel VT-d. Generic response data is taken from the IOMMU API then parsed into VT-d specific response descriptor format. Signed-off-by: Jacob Pan --- drivers/iommu/intel-iommu.c | 47 +

[PATCH v5 18/23] iommu/intel-svm: report device page request

If the source device of a page request has its PASID table pointer bound to a guest, the first level page tables are owned by the guest. In this case, we shall let guest OS to manage page fault. This patch uses the IOMMU fault reporting API to send fault events, possibly via VFIO, to the guest

[PATCH v5 20/23] iommu/intel-svm: do not flush iotlb for viommu

vIOMMU passdown invalidation will be inclusive, PASID cache invalidation includes TLBs. See Intel VT-d Specification Ch 6.5.2.2 for details. Signed-off-by: Jacob Pan --- drivers/iommu/intel-svm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git

[PATCH v5 20/23] iommu/intel-svm: do not flush iotlb for viommu

vIOMMU passdown invalidation will be inclusive, PASID cache invalidation includes TLBs. See Intel VT-d Specification Ch 6.5.2.2 for details. Signed-off-by: Jacob Pan --- drivers/iommu/intel-svm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/intel-svm.c

[PATCH v5 07/23] iommu/vt-d: fix dev iotlb pfsid use

PFSID should be used in the invalidation descriptor for flushing device IOTLBs on SRIOV VFs. Signed-off-by: Jacob Pan --- drivers/iommu/dmar.c| 6 +++--- drivers/iommu/intel-iommu.c | 16 +++- include/linux/intel-iommu.h | 5 ++--- 3 files

[PATCH v5 05/23] iommu: introduce iommu invalidate API function

From: "Liu, Yi L" When an SVM capable device is assigned to a guest, the first level page tables are owned by the guest and the guest PASID table pointer is linked to the device context entry of the physical IOMMU. Host IOMMU driver has no knowledge of caching

[PATCH v5 07/23] iommu/vt-d: fix dev iotlb pfsid use

PFSID should be used in the invalidation descriptor for flushing device IOTLBs on SRIOV VFs. Signed-off-by: Jacob Pan --- drivers/iommu/dmar.c| 6 +++--- drivers/iommu/intel-iommu.c | 16 +++- include/linux/intel-iommu.h | 5 ++--- 3 files changed, 20 insertions(+), 7

[PATCH v5 05/23] iommu: introduce iommu invalidate API function

From: "Liu, Yi L" When an SVM capable device is assigned to a guest, the first level page tables are owned by the guest and the guest PASID table pointer is linked to the device context entry of the physical IOMMU. Host IOMMU driver has no knowledge of caching structure updates unless the guest

Re: INFO: rcu detected stall in kfree_skbmem

On Fri, May 11, 2018 at 12:08:33PM -0700, Eric Dumazet wrote: > > > On 05/11/2018 11:41 AM, Marcelo Ricardo Leitner wrote: > > > But calling ip6_xmit with rcu_read_lock is expected. tcp stack also > > does it. > > Thus I think this is more of an issue with IPv6 stack. If a host has > > an

Re: INFO: rcu detected stall in kfree_skbmem

On Fri, May 11, 2018 at 12:08:33PM -0700, Eric Dumazet wrote: > > > On 05/11/2018 11:41 AM, Marcelo Ricardo Leitner wrote: > > > But calling ip6_xmit with rcu_read_lock is expected. tcp stack also > > does it. > > Thus I think this is more of an issue with IPv6 stack. If a host has > > an

Re: [V2] sched/schedutil: Don't set next_freq to UINT_MAX

On Wed, May 09, 2018 at 04:05:24PM +0530, Viresh Kumar wrote: > The schedutil driver sets sg_policy->next_freq to UINT_MAX on certain > occasions to discard the cached value of next freq: > - In sugov_start(), when the schedutil governor is started for a group > of CPUs. > - And whenever we need

Re: [V2] sched/schedutil: Don't set next_freq to UINT_MAX

On Wed, May 09, 2018 at 04:05:24PM +0530, Viresh Kumar wrote: > The schedutil driver sets sg_policy->next_freq to UINT_MAX on certain > occasions to discard the cached value of next freq: > - In sugov_start(), when the schedutil governor is started for a group > of CPUs. > - And whenever we need

Re: [PATCH v3] net: phy: DP83TC811: Introduce support for the DP83TC811 phy

From: Dan Murphy Date: Fri, 11 May 2018 13:08:19 -0500 > Add support for the DP83811 phy. > > The DP83811 supports both rgmii and sgmii interfaces. > There are 2 part numbers for this the DP83TC811R does not > reliably support the SGMII interface but the DP83TC811S will. > >

Re: [PATCH v3] net: phy: DP83TC811: Introduce support for the DP83TC811 phy

From: Dan Murphy Date: Fri, 11 May 2018 13:08:19 -0500 > Add support for the DP83811 phy. > > The DP83811 supports both rgmii and sgmii interfaces. > There are 2 part numbers for this the DP83TC811R does not > reliably support the SGMII interface but the DP83TC811S will. > > There is not a way

Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver

Dan, On 05/11/2018 02:12 PM, Dan Murphy wrote: Jacek Thanks for the review On 05/10/2018 03:17 PM, Jacek Anaszewski wrote: Hi Dan, On 05/10/2018 09:10 PM, Dan Murphy wrote: On 05/10/2018 02:06 PM, Dan Murphy wrote: Pavel On 05/10/2018 01:54 PM, Pavel Machek wrote: Hi! Introduce the

Re: [PATCH v5 1/2] dt: bindings: lm3601x: Introduce the lm3601x driver

Dan, On 05/11/2018 02:12 PM, Dan Murphy wrote: Jacek Thanks for the review On 05/10/2018 03:17 PM, Jacek Anaszewski wrote: Hi Dan, On 05/10/2018 09:10 PM, Dan Murphy wrote: On 05/10/2018 02:06 PM, Dan Murphy wrote: Pavel On 05/10/2018 01:54 PM, Pavel Machek wrote: Hi! Introduce the

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

Hi Dan, On 05/11/2018 01:56 PM, Dan Murphy wrote: Jacek Thanks for the review On 05/10/2018 03:48 PM, Jacek Anaszewski wrote: Hi Dan, Thank you for the patch. On 05/10/2018 07:47 PM, Dan Murphy wrote: Introduce the family of LED devices that can drive a torch, strobe or IR LED. The LED

Re: [PATCH v5 2/2] leds: lm3601x: Introduce the lm3601x LED driver

Hi Dan, On 05/11/2018 01:56 PM, Dan Murphy wrote: Jacek Thanks for the review On 05/10/2018 03:48 PM, Jacek Anaszewski wrote: Hi Dan, Thank you for the patch. On 05/10/2018 07:47 PM, Dan Murphy wrote: Introduce the family of LED devices that can drive a torch, strobe or IR LED. The LED

[PATCH 24/23] LSM: Functions for dealing with struct secids

From: Casey Schaufler Date: Fri, 11 May 2018 13:18:11 -0700 Subject: [PATCH 24/23] LSM: Functions for deling with struct secids These are the functions that mainipulate the collection of secids. Signed-off-by: Casey Schaufler ---

[PATCH 24/23] LSM: Functions for dealing with struct secids

From: Casey Schaufler Date: Fri, 11 May 2018 13:18:11 -0700 Subject: [PATCH 24/23] LSM: Functions for deling with struct secids These are the functions that mainipulate the collection of secids. Signed-off-by: Casey Schaufler --- security/stacking.c | 119

Re: [PATCH v2] selftests/cgroup: memory controller self-tests

On 05/11/2018 02:02 PM, Tejun Heo wrote: > On Fri, May 11, 2018 at 01:33:26PM -0600, Shuah Khan wrote: >> Yeah. I see that. You have a switch for the KSFT_ values. Since there is no >> dependency on the cgroup tree, I would recommend having this patch go through >> kselftest tree which is the

Re: [PATCH v2] selftests/cgroup: memory controller self-tests

On 05/11/2018 02:02 PM, Tejun Heo wrote: > On Fri, May 11, 2018 at 01:33:26PM -0600, Shuah Khan wrote: >> Yeah. I see that. You have a switch for the KSFT_ values. Since there is no >> dependency on the cgroup tree, I would recommend having this patch go through >> kselftest tree which is the

Re: [PATCH v8 09/10] drivers: qcom: rpmh: add support for batch RPMH request

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > /** > @@ -77,12 +82,14 @@ struct rpmh_request { > * @cache: the list of cached requests > * @lock: synchronize access to the controller data > * @dirty: was the cache updated since flush > + * @batch_cache:

Re: [PATCH v8 09/10] drivers: qcom: rpmh: add support for batch RPMH request

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > /** > @@ -77,12 +82,14 @@ struct rpmh_request { > * @cache: the list of cached requests > * @lock: synchronize access to the controller data > * @dirty: was the cache updated since flush > + * @batch_cache: Cache sleep and wake

Re: [PATCH v8 07/10] drivers: qcom: rpmh: cache sleep/wake state requests

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > /** > * struct rpmh_request: the message to be sent to rpmh-rsc > * > @@ -54,9 +71,15 @@ struct rpmh_request { > * struct rpmh_ctrlr: our representation of the controller > * > * @drv: the controller

Re: [PATCH v8 07/10] drivers: qcom: rpmh: cache sleep/wake state requests

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > /** > * struct rpmh_request: the message to be sent to rpmh-rsc > * > @@ -54,9 +71,15 @@ struct rpmh_request { > * struct rpmh_ctrlr: our representation of the controller > * > * @drv: the controller instance > + * @cache: the

Re: [PATCH v8 10/10] drivers: qcom: rpmh-rsc: allow active requests from wake TCS

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > Some RSCs may only have sleep and wake TCS, i.e, there is no dedicated > TCS for active mode request, but drivers may still want to make active > requests from these RSCs. In such cases re-purpose the wake TCS to send

Re: [PATCH v8 10/10] drivers: qcom: rpmh-rsc: allow active requests from wake TCS

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > Some RSCs may only have sleep and wake TCS, i.e, there is no dedicated > TCS for active mode request, but drivers may still want to make active > requests from these RSCs. In such cases re-purpose the wake TCS to send > active state

Re: [PATCH v8 04/10] drivers: qcom: rpmh: add RPMH helper functions

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > +int rpmh_write(const struct device *dev, enum rpmh_state state, > + const struct tcs_cmd *cmd, u32 n) > +{ > + DECLARE_COMPLETION_ONSTACK(compl); > + DEFINE_RPMH_MSG_ONSTACK(dev, state, ,

Re: [PATCH v8 04/10] drivers: qcom: rpmh: add RPMH helper functions

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > +int rpmh_write(const struct device *dev, enum rpmh_state state, > + const struct tcs_cmd *cmd, u32 n) > +{ > + DECLARE_COMPLETION_ONSTACK(compl); > + DEFINE_RPMH_MSG_ONSTACK(dev, state, , rpm_msg); > + int

Re: [PATCH v8 08/10] drivers: qcom: rpmh: allow requests to be sent asynchronously

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > /** > @@ -137,6 +140,8 @@ void rpmh_tx_done(const struct tcs_request *msg, int r) > dev_err(rpm_msg->dev, "RPMH TX fail in msg addr=%#x, > err=%d\n", >

Re: [PATCH v8 08/10] drivers: qcom: rpmh: allow requests to be sent asynchronously

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > /** > @@ -137,6 +140,8 @@ void rpmh_tx_done(const struct tcs_request *msg, int r) > dev_err(rpm_msg->dev, "RPMH TX fail in msg addr=%#x, > err=%d\n", > rpm_msg->msg.cmds[0].addr, r); > > +

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

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > +int rpmh_rsc_send_data(struct rsc_drv *drv, const struct tcs_request *msg) > +{ > + int ret; > + > + if (!msg || !msg->cmds || !msg->num_cmds || > + msg->num_cmds > MAX_RPMH_PAYLOAD) { > +

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

Hi, On Wed, May 9, 2018 at 10:01 AM, Lina Iyer wrote: > +int rpmh_rsc_send_data(struct rsc_drv *drv, const struct tcs_request *msg) > +{ > + int ret; > + > + if (!msg || !msg->cmds || !msg->num_cmds || > + msg->num_cmds > MAX_RPMH_PAYLOAD) { > + WARN_ON(1); >

Re: [PATCH v7 04/10] drivers: qcom: rpmh: add RPMH helper functions

Hi, On Fri, May 11, 2018 at 8:06 AM, Lina Iyer wrote: >> As I've said I haven't reviewed RPMh in any amount of detail and so >> perhaps I don't understand something. >> >> OK, I dug a little more and coded up something for you. Basically >> you're doing a whole bunch of

Re: [PATCH v7 04/10] drivers: qcom: rpmh: add RPMH helper functions

Hi, On Fri, May 11, 2018 at 8:06 AM, Lina Iyer wrote: >> As I've said I haven't reviewed RPMh in any amount of detail and so >> perhaps I don't understand something. >> >> OK, I dug a little more and coded up something for you. Basically >> you're doing a whole bunch of iteration / extra work

Re: [PATCH 00/12] introduce support for early platform drivers

On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski wrote: > This series is a follow-up to the RFC[1] posted a couple days ago. > > NOTE: this series applies on top of my recent patches[2] that move the > previous > implementation of early platform devices to arch/sh. > >

Re: [PATCH 00/12] introduce support for early platform drivers

On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski wrote: > This series is a follow-up to the RFC[1] posted a couple days ago. > > NOTE: this series applies on top of my recent patches[2] that move the > previous > implementation of early platform devices to arch/sh. > > Problem: > > Certain

[PATCH v1 8/9] iommu: Introduce iotlb_sync_map callback

On 11.05.2018 16:02, Robin Murphy wrote: > On 08/05/18 19:16, Dmitry Osipenko wrote: >> Introduce iotlb_sync_map() callback that is invoked in the end of >> iommu_map(). This new callback allows IOMMU drivers to avoid syncing >> on mapping of each contiguous chunk and sync only when whole mapping

[PATCH v1 7/9] iommu/tegra: gart: Provide single domain and group for all devices

On 11.05.2018 15:32, Robin Murphy wrote: > On 08/05/18 19:16, Dmitry Osipenko wrote: >> GART aperture is shared by all devices, hence there is a single IOMMU >> domain and group shared by these devices. Allocation of a group per >> device only wastes resources and allowance of having more than one

[PATCH v1 8/9] iommu: Introduce iotlb_sync_map callback

On 11.05.2018 16:02, Robin Murphy wrote: > On 08/05/18 19:16, Dmitry Osipenko wrote: >> Introduce iotlb_sync_map() callback that is invoked in the end of >> iommu_map(). This new callback allows IOMMU drivers to avoid syncing >> on mapping of each contiguous chunk and sync only when whole mapping

[PATCH v1 7/9] iommu/tegra: gart: Provide single domain and group for all devices

On 11.05.2018 15:32, Robin Murphy wrote: > On 08/05/18 19:16, Dmitry Osipenko wrote: >> GART aperture is shared by all devices, hence there is a single IOMMU >> domain and group shared by these devices. Allocation of a group per >> device only wastes resources and allowance of having more than one

Re: [PATCH v3 1/3] big key: get rid of stack array allocation

On Tue, 24 Apr 2018, Tycho Andersen wrote: > We're interested in getting rid of all of the stack allocated arrays in the > kernel [1]. This patch simply hardcodes the iv length to match that of the > hardcoded cipher. > > [1]: https://lkml.org/lkml/2018/3/7/621 > > v2: hardcode the length of

Re: [PATCH v3 1/3] big key: get rid of stack array allocation

On Tue, 24 Apr 2018, Tycho Andersen wrote: > We're interested in getting rid of all of the stack allocated arrays in the > kernel [1]. This patch simply hardcodes the iv length to match that of the > hardcoded cipher. > > [1]: https://lkml.org/lkml/2018/3/7/621 > > v2: hardcode the length of

Re: [PATCH v1 6/9] iommu/tegra: gart: Ignore devices without IOMMU phandle in DT

Hi Robin, On 11.05.2018 14:34, Robin Murphy wrote: > Hi Dmitry, > > On 08/05/18 19:16, Dmitry Osipenko wrote: >> GART can't handle all devices, ignore devices that aren't related to GART. >> Device tree must explicitly assign GART IOMMU to the devices. >> >> Signed-off-by: Dmitry Osipenko

Re: [PATCH v1 6/9] iommu/tegra: gart: Ignore devices without IOMMU phandle in DT

Hi Robin, On 11.05.2018 14:34, Robin Murphy wrote: > Hi Dmitry, > > On 08/05/18 19:16, Dmitry Osipenko wrote: >> GART can't handle all devices, ignore devices that aren't related to GART. >> Device tree must explicitly assign GART IOMMU to the devices. >> >> Signed-off-by: Dmitry Osipenko >>

Re: [PATCH v2] selftests/cgroup: memory controller self-tests

On Fri, May 11, 2018 at 01:33:26PM -0600, Shuah Khan wrote: > Yeah. I see that. You have a switch for the KSFT_ values. Since there is no > dependency on the cgroup tree, I would recommend having this patch go through > kselftest tree which is the normal process for tests anyway. > > This version

Re: [PATCH v2] selftests/cgroup: memory controller self-tests

On Fri, May 11, 2018 at 01:33:26PM -0600, Shuah Khan wrote: > Yeah. I see that. You have a switch for the KSFT_ values. Since there is no > dependency on the cgroup tree, I would recommend having this patch go through > kselftest tree which is the normal process for tests anyway. > > This version

Re: [PATCH net 0/5] rxrpc: Fixes

From: David Howells Date: Thu, 10 May 2018 23:45:17 +0100 > Here are three fixes for AF_RXRPC and two tracepoints that were useful for > finding them: ... > The patches are tagged here: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git >

Re: [PATCH net 0/5] rxrpc: Fixes

From: David Howells Date: Thu, 10 May 2018 23:45:17 +0100 > Here are three fixes for AF_RXRPC and two tracepoints that were useful for > finding them: ... > The patches are tagged here: > > git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git > rxrpc-fixes-20180510

[RFC][PATCH 09/10] tracing: Allow histogram triggers to access ftrace internal events

From: "Steven Rostedt (VMware)" Now that trace_marker can have triggers, including a histogram triggers, the onmatch() and onmax() access the trace event. To do so, the search routine to find the event file needs to use the raw __find_event_file() that does not filter out

[RFC][PATCH 09/10] tracing: Allow histogram triggers to access ftrace internal events

From: "Steven Rostedt (VMware)" Now that trace_marker can have triggers, including a histogram triggers, the onmatch() and onmax() access the trace event. To do so, the search routine to find the event file needs to use the raw __find_event_file() that does not filter out ftrace events.

[RFC][PATCH 05/10] tracing: Do not show filter file for ftrace internal events

From: "Steven Rostedt (VMware)" The filter file in the ftrace internal events, like in /sys/kernel/tracing/events/ftrace/function/filter is not attached to any functionality. Do not create them as they are meaningless. In the future, if an ftrace internal event gets filter

[RFC][PATCH 04/10] tracing: Add brackets in ftrace event dynamic arrays

From: "Steven Rostedt (VMware)" The dynamic arrays defined for ftrace internal events, such as the buf field for trace_marker (ftrace/print) did not have brackets which makes the filter code not accept it as a string. This is not currently an issues because the filter code

[RFC][PATCH 04/10] tracing: Add brackets in ftrace event dynamic arrays

From: "Steven Rostedt (VMware)" The dynamic arrays defined for ftrace internal events, such as the buf field for trace_marker (ftrace/print) did not have brackets which makes the filter code not accept it as a string. This is not currently an issues because the filter code doesn't do anything

[RFC][PATCH 05/10] tracing: Do not show filter file for ftrace internal events

From: "Steven Rostedt (VMware)" The filter file in the ftrace internal events, like in /sys/kernel/tracing/events/ftrace/function/filter is not attached to any functionality. Do not create them as they are meaningless. In the future, if an ftrace internal event gets filter functionality, then

[RFC][PATCH 07/10] tracing: Have zero size length in filter logic be full string

From: "Steven Rostedt (VMware)" As strings in trace events may not have a nul terminating character, the filter string compares use the defined string length for the field for the compares. The trace_marker records data slightly different than do normal events. It's size is

[RFC][PATCH 07/10] tracing: Have zero size length in filter logic be full string

From: "Steven Rostedt (VMware)" As strings in trace events may not have a nul terminating character, the filter string compares use the defined string length for the field for the compares. The trace_marker records data slightly different than do normal events. It's size is zero, meaning that

[RFC][PATCH 06/10] tracing: Add trigger file for trace_markers tracefs/ftrace/print

From: "Steven Rostedt (VMware)" Allow writing to the trace_markers file initiate triggers defined in tracefs/ftrace/print/trigger file. This will allow of user space to trigger the same type of triggers (including histograms) that the trace events use. Cc: Tom Zanussi

[RFC][PATCH 06/10] tracing: Add trigger file for trace_markers tracefs/ftrace/print

From: "Steven Rostedt (VMware)" Allow writing to the trace_markers file initiate triggers defined in tracefs/ftrace/print/trigger file. This will allow of user space to trigger the same type of triggers (including histograms) that the trace events use. Cc: Tom Zanussi Cc: Clark Williams Cc:

[RFC][PATCH 08/10] tracing: Prevent further users of zero size static arrays in trace events

From: "Steven Rostedt (VMware)" A zero size static array has special meaning in the ftrace infrastructure. Trace events are for recording data in the trace buffers that is normally difficult to obtain via probes or function tracing. There is no reason for any trace event to

[RFC][PATCH 08/10] tracing: Prevent further users of zero size static arrays in trace events

From: "Steven Rostedt (VMware)" A zero size static array has special meaning in the ftrace infrastructure. Trace events are for recording data in the trace buffers that is normally difficult to obtain via probes or function tracing. There is no reason for any trace event to declare a zero size

[RFC][PATCH 10/10] tracing: Document trace_marker triggers

From: "Steven Rostedt (VMware)" Add documentation and an example on how to use trace_marker triggers. Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/events.rst| 6 +- Documentation/trace/ftrace.rst| 5 +

[RFC][PATCH 10/10] tracing: Document trace_marker triggers

From: "Steven Rostedt (VMware)" Add documentation and an example on how to use trace_marker triggers. Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/events.rst| 6 +- Documentation/trace/ftrace.rst| 5 + Documentation/trace/histogram.txt | 546

[RFC][PATCH 01/10] tracing: Do not reference event data in post call triggers

From: "Steven Rostedt (VMware)" Trace event triggers can be called before or after the event has been committed. If it has been called after the commit, there's a possibility that the event no longer exists. Currently, the two post callers is the trigger to disable tracing

[RFC][PATCH 01/10] tracing: Do not reference event data in post call triggers

From: "Steven Rostedt (VMware)" Trace event triggers can be called before or after the event has been committed. If it has been called after the commit, there's a possibility that the event no longer exists. Currently, the two post callers is the trigger to disable tracing (traceoff) and the one

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