Re: [RFC PATCH 0/8] EDAC, mce_amd: Add a tracepoint for the decoded error

On Fri, Jul 28, 2017 at 08:37:53AM +0200, Ingo Molnar wrote: > Yeah, structured, append-only ABIs are elegant - that's what perf uses too. Yeah. > Had do vent my (non kernel tree integrated) Linux tooling frustration!! ;-) I know *exactly* what you mean! :-) -- Regards/Gruss, Boris. ECO

Re: [RFC PATCH 0/8] EDAC, mce_amd: Add a tracepoint for the decoded error

On Fri, Jul 28, 2017 at 08:37:53AM +0200, Ingo Molnar wrote: > Yeah, structured, append-only ABIs are elegant - that's what perf uses too. Yeah. > Had do vent my (non kernel tree integrated) Linux tooling frustration!! ;-) I know *exactly* what you mean! :-) -- Regards/Gruss, Boris. ECO

[PATCH V2 03/12] spmi: pmic-arb: clean up pmic_arb_find_apid function

Clean up the pmic_arb_find_apid() by using the local variables to improve the code readability. Signed-off-by: Kiran Gunda Reviewed-by: Stephen Boyd --- drivers/spmi/spmi-pmic-arb.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-)

[PATCH V2 03/12] spmi: pmic-arb: clean up pmic_arb_find_apid function

Clean up the pmic_arb_find_apid() by using the local variables to improve the code readability. Signed-off-by: Kiran Gunda Reviewed-by: Stephen Boyd --- drivers/spmi/spmi-pmic-arb.c | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/spmi/spmi-pmic-arb.c

RE: [PATCH v2] qe: fix compile issue for arm64

Fri 7/28/2017 2:14 PM, Michael Ellerman wrote: > -Original Message- > From: Michael Ellerman [mailto:m...@ellerman.id.au] > Sent: Friday, July 28, 2017 2:14 PM > To: Qiang Zhao ; o...@buserror.net > Cc: valentin.longch...@keymile.com;

RE: [PATCH v2] qe: fix compile issue for arm64

Fri 7/28/2017 2:14 PM, Michael Ellerman wrote: > -Original Message- > From: Michael Ellerman [mailto:m...@ellerman.id.au] > Sent: Friday, July 28, 2017 2:14 PM > To: Qiang Zhao ; o...@buserror.net > Cc: valentin.longch...@keymile.com; linuxppc-...@lists.ozlabs.org; linux- >

[PATCH V2 06/12] spmi: pmic-arb: replace the writel_relaxed with __raw_writel

Replace the writel_relaxed with __raw_writel to avoid byte swapping in pmic_arb_write_data() function. That way the code is independent of the CPU endianness. Fixes: 111a10bf3e53 ("spmi: pmic-arb: rename spmi_pmic_arb_dev to spmi_pmic_arb") Signed-off-by: Kiran Gunda

[PATCH V2 06/12] spmi: pmic-arb: replace the writel_relaxed with __raw_writel

Replace the writel_relaxed with __raw_writel to avoid byte swapping in pmic_arb_write_data() function. That way the code is independent of the CPU endianness. Fixes: 111a10bf3e53 ("spmi: pmic-arb: rename spmi_pmic_arb_dev to spmi_pmic_arb") Signed-off-by: Kiran Gunda Reviewed-by: Stephen Boyd

[PATCH V2 04/12] spmi: pmic-arb: optimize qpnpint_irq_set_type function

Optimize the qpnpint_irq_set_type() by using a local variable to hold the handler type. Also clean up other variable usage. Signed-off-by: Kiran Gunda Reviewed-by: Stephen Boyd --- drivers/spmi/spmi-pmic-arb.c | 24 1 file

Re: [RFC PATCH 6/8] EDAC, mce_amd: Convert to seq_buf

On Thu, Jul 27, 2017 at 09:47:08PM -0400, Steven Rostedt wrote: > What happens if two CPUs have mce's at the same time? Wouldn't one > corrupt the other buffer. 128 isn't too big to put on the stack is it? Yeah, putting it on the stack is probably safer, just in case. What is even better,

[PATCH 2/2] KVM: nVMX: fixes to nested virt interrupt injection

There are three issues in nested_vmx_check_exception: 1) it is not taking PFEC_MATCH/PFEC_MASK into account, as reported by Wanpeng Li; 2) it should rebuild the interruption info and exit qualification fields from scratch, as reported by Jim Mattson, because the values from the L2->L0 vmexit may

Re: [RFC PATCH 6/8] EDAC, mce_amd: Convert to seq_buf

On Thu, Jul 27, 2017 at 09:47:08PM -0400, Steven Rostedt wrote: > What happens if two CPUs have mce's at the same time? Wouldn't one > corrupt the other buffer. 128 isn't too big to put on the stack is it? Yeah, putting it on the stack is probably safer, just in case. What is even better,

[PATCH 2/2] KVM: nVMX: fixes to nested virt interrupt injection

There are three issues in nested_vmx_check_exception: 1) it is not taking PFEC_MATCH/PFEC_MASK into account, as reported by Wanpeng Li; 2) it should rebuild the interruption info and exit qualification fields from scratch, as reported by Jim Mattson, because the values from the L2->L0 vmexit may

[PATCH V2 04/12] spmi: pmic-arb: optimize qpnpint_irq_set_type function

Optimize the qpnpint_irq_set_type() by using a local variable to hold the handler type. Also clean up other variable usage. Signed-off-by: Kiran Gunda Reviewed-by: Stephen Boyd --- drivers/spmi/spmi-pmic-arb.c | 24 1 file changed, 12 insertions(+), 12 deletions(-)

[PATCH V2 08/12] spmi: pmic-arb: use irq_chip callback to set spmi irq wakeup capability

Currently the driver sets the pmic arbiter core interrupt as wakeup capable irrespective of the child irqs which causes the system to wakeup unnecessarily. To fix this, set the core interrupt as wakeup capable only if any of the child irqs request for it. Do this by marking it as wakeup capable in

[PATCH V2 08/12] spmi: pmic-arb: use irq_chip callback to set spmi irq wakeup capability

Currently the driver sets the pmic arbiter core interrupt as wakeup capable irrespective of the child irqs which causes the system to wakeup unnecessarily. To fix this, set the core interrupt as wakeup capable only if any of the child irqs request for it. Do this by marking it as wakeup capable in

[PATCH V2 12/12] spmi: pmic-arb: Remove checking opc value not less than 0

From: Fenglin Wu The opc parameter in pmic_arb_write_cmd() function is defined with type u8 and it's always greater than or equal to 0. Checking that it's not less than 0 is redundant and it can cause a forbidden warning during compilation. Remove the check.

[PATCH V2 12/12] spmi: pmic-arb: Remove checking opc value not less than 0

From: Fenglin Wu The opc parameter in pmic_arb_write_cmd() function is defined with type u8 and it's always greater than or equal to 0. Checking that it's not less than 0 is redundant and it can cause a forbidden warning during compilation. Remove the check. Signed-off-by: Fenglin Wu

[PATCH V3] init:main.c: Fix:Issues in Block comment & if block

This patch Fixes the improper block comments and if block where it is unnecessary to add single line of code in curly braces Signed-off-by: Janani S --- init/main.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/init/main.c b/init/main.c index

[PATCH V3] init:main.c: Fix:Issues in Block comment & if block

This patch Fixes the improper block comments and if block where it is unnecessary to add single line of code in curly braces Signed-off-by: Janani S --- init/main.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/init/main.c b/init/main.c index 052481f..f8eb4966

[PATCH V2 11/12] spmi: pmic-arb: add support for HW version 5

From: David Collins Add support for version 5 of the SPMI PMIC arbiter. It utilizes different offsets for registers than those found on version 3. Also, the procedure to determine if writing and IRQ access is allowed for a given PPID changes for version 5.

[PATCH V2 00/12]: spmi: pmic-arb: Support for HW v5 and other fixes

v2: * [PATCH V2 04/12] spmi: pmic-arb: optimize qpnpint_irq_set_type function Added Stephen's Reviewed-by tag. * [PATCH V2 05/12] spmi: pmic-arb: fix memory allocation for mapping_table Added Fixes tag and Stephen's Reviewed-by tag. * [PATCH V2 02/12] spmi: pmic-arb: rename pa_xx to

Re: [RFC PATCH 7/8] EDAC, mce_amd: Add a simple tracepoint dumping a decoded string

On Thu, Jul 27, 2017 at 09:47:59PM -0400, Steven Rostedt wrote: > On Tue, 25 Jul 2017 17:46:00 +0200 > Borislav Petkov wrote: > > > From: Borislav Petkov > > > > It is a single string which gets dynamically generated when the error > > gets decoded. Dump it to

[PATCH V2 11/12] spmi: pmic-arb: add support for HW version 5

From: David Collins Add support for version 5 of the SPMI PMIC arbiter. It utilizes different offsets for registers than those found on version 3. Also, the procedure to determine if writing and IRQ access is allowed for a given PPID changes for version 5. Signed-off-by: David Collins

[PATCH V2 00/12]: spmi: pmic-arb: Support for HW v5 and other fixes

v2: * [PATCH V2 04/12] spmi: pmic-arb: optimize qpnpint_irq_set_type function Added Stephen's Reviewed-by tag. * [PATCH V2 05/12] spmi: pmic-arb: fix memory allocation for mapping_table Added Fixes tag and Stephen's Reviewed-by tag. * [PATCH V2 02/12] spmi: pmic-arb: rename pa_xx to

Re: [RFC PATCH 7/8] EDAC, mce_amd: Add a simple tracepoint dumping a decoded string

On Thu, Jul 27, 2017 at 09:47:59PM -0400, Steven Rostedt wrote: > On Tue, 25 Jul 2017 17:46:00 +0200 > Borislav Petkov wrote: > > > From: Borislav Petkov > > > > It is a single string which gets dynamically generated when the error > > gets decoded. Dump it to userspace through that tracepoint

[PATCH V2 05/12] spmi: pmic-arb: fix memory allocation for mapping_table

Allocate the correct memory size (max_pmic_peripherals) for the mapping_table that holds the apid to ppid mapping. Also use a local variable for mapping_table for better alignment of the code. Fixes: 987a9f128b8a ("spmi: pmic-arb: Support more than 128 peripherals") Signed-off-by: Kiran Gunda

[PATCH V2 07/12] spmi: pmic-arb: return the value instead of passing by pointer

Returning the output value from a function, when it is possible, is the better and cleaner way than passing it by the pointer. Hence, modify the ppid_to_apid mapping function to return apid instead of passing it by a pointer. While at it, pass the ppid as function parameter to ppid_to_apid mapping

[PATCH V2 10/12] spmi: pmic-arb: fix a possible null pointer dereference

If "core" memory resource is not specified, then the driver could end up dereferencing a null pointer. Fix this issue. Signed-off-by: Kiran Gunda Reviewed-by: Stephen Boyd --- drivers/spmi/spmi-pmic-arb.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH V2 05/12] spmi: pmic-arb: fix memory allocation for mapping_table

Allocate the correct memory size (max_pmic_peripherals) for the mapping_table that holds the apid to ppid mapping. Also use a local variable for mapping_table for better alignment of the code. Fixes: 987a9f128b8a ("spmi: pmic-arb: Support more than 128 peripherals") Signed-off-by: Kiran Gunda

[PATCH V2 07/12] spmi: pmic-arb: return the value instead of passing by pointer

Returning the output value from a function, when it is possible, is the better and cleaner way than passing it by the pointer. Hence, modify the ppid_to_apid mapping function to return apid instead of passing it by a pointer. While at it, pass the ppid as function parameter to ppid_to_apid mapping

[PATCH V2 10/12] spmi: pmic-arb: fix a possible null pointer dereference

If "core" memory resource is not specified, then the driver could end up dereferencing a null pointer. Fix this issue. Signed-off-by: Kiran Gunda Reviewed-by: Stephen Boyd --- drivers/spmi/spmi-pmic-arb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH V2 09/12] spmi: pmic-arb: return __iomem pointer instead of offset

Modify the pmic_arb version ops to return an __iomem pointer to the address instead of an offset. That way we do not need to care about the base address changes in the new HW version. Signed-off-by: Kiran Gunda Reviewed-by: Stephen Boyd ---

Re: [PATCH v3] cpu_pm: replace raw_notifier to atomic_notifier

On 07/28/2017 02:44 PM, Tony Lindgren wrote: > * Alex Shi [170727 18:42]: >> Tony Lezcano found a miss use that rcu_read_lock used after rcu_idle_enter >> Paul E. McKenney suggested trying RCU_NONIDLE. > > Hmm I think you have a hybrid name typo above in case you mean me

Re: [PATCH v3] cpu_pm: replace raw_notifier to atomic_notifier

On 07/28/2017 02:44 PM, Tony Lindgren wrote: > * Alex Shi [170727 18:42]: >> Tony Lezcano found a miss use that rcu_read_lock used after rcu_idle_enter >> Paul E. McKenney suggested trying RCU_NONIDLE. > > Hmm I think you have a hybrid name typo above in case you mean me :) Sorry. Resent. >

[PATCH V2 09/12] spmi: pmic-arb: return __iomem pointer instead of offset

Modify the pmic_arb version ops to return an __iomem pointer to the address instead of an offset. That way we do not need to care about the base address changes in the new HW version. Signed-off-by: Kiran Gunda Reviewed-by: Stephen Boyd --- drivers/spmi/spmi-pmic-arb.c | 93

[PATCH] cpu_pm: replace raw_notifier to atomic_notifier

This patch replace a rwlock and raw notifier by atomic notifier which protected by spin_lock and rcu. The first to reason to have this replace is due to a 'scheduling while atomic' bug of RT kernel on arm/arm64 platform. On arm/arm64, rwlock cpu_pm_notifier_lock in cpu_pm cause a potential

[PATCH] cpu_pm: replace raw_notifier to atomic_notifier

This patch replace a rwlock and raw notifier by atomic notifier which protected by spin_lock and rcu. The first to reason to have this replace is due to a 'scheduling while atomic' bug of RT kernel on arm/arm64 platform. On arm/arm64, rwlock cpu_pm_notifier_lock in cpu_pm cause a potential

[PATCH 0/2] KVM: nVMX: fixes to nested virt interrupt injection

With these two patches, KVM does not blindly pass the exit interruption info and exit qualification from the vmcs02 and vmcs12 when injecting an exception. There were two spots where this was done, namely nested_vmx_check_exception and vmx_inject_page_fault_nested. Patch 1 avoids writing the

[PATCH 0/2] KVM: nVMX: fixes to nested virt interrupt injection

With these two patches, KVM does not blindly pass the exit interruption info and exit qualification from the vmcs02 and vmcs12 when injecting an exception. There were two spots where this was done, namely nested_vmx_check_exception and vmx_inject_page_fault_nested. Patch 1 avoids writing the

[PATCH 1/2] KVM: nVMX: do not fill vm_exit_intr_error_code in prepare_vmcs12

Do this in the caller of nested_vmx_vmexit instead. nested_vmx_check_exception was doing a vmwrite to the vmcs02's VM_EXIT_INTR_ERROR_CODE field, so that prepare_vmcs12 would move the field to vmcs12->vm_exit_intr_error_code. However that isn't possible on pre-Haswell machines. Moving the

[PATCH 1/2] KVM: nVMX: do not fill vm_exit_intr_error_code in prepare_vmcs12

Do this in the caller of nested_vmx_vmexit instead. nested_vmx_check_exception was doing a vmwrite to the vmcs02's VM_EXIT_INTR_ERROR_CODE field, so that prepare_vmcs12 would move the field to vmcs12->vm_exit_intr_error_code. However that isn't possible on pre-Haswell machines. Moving the

Re: [PATCH] ARM: Use WFI when possible when halting a core

On Thu, Jul 27, 2017 at 8:45 PM, Chen-Yu Tsai wrote: > On Thu, Jul 27, 2017 at 8:17 PM, Russell King - ARM Linux > wrote: >> On Thu, Jul 27, 2017 at 08:08:03PM +0800, Chen-Yu Tsai wrote: >>> On ARM, the kernel busy loops after cleaning up when a core is to

Re: [PATCH] ARM: Use WFI when possible when halting a core

On Thu, Jul 27, 2017 at 8:45 PM, Chen-Yu Tsai wrote: > On Thu, Jul 27, 2017 at 8:17 PM, Russell King - ARM Linux > wrote: >> On Thu, Jul 27, 2017 at 08:08:03PM +0800, Chen-Yu Tsai wrote: >>> On ARM, the kernel busy loops after cleaning up when a core is to be >>> halted. This may have the

Re: [PATCH] mm: memcontrol: Use int for event/state parameter in several functions

On Thu 27-07-17 14:10:04, Matthias Kaehlcke wrote: > Several functions use an enum type as parameter for an event/state, > but are called in some locations with an argument of a different enum > type. Adjust the interface of these functions to reality by changing the > parameter to int. enums are

Re: [PATCH] mm: memcontrol: Use int for event/state parameter in several functions

On Thu 27-07-17 14:10:04, Matthias Kaehlcke wrote: > Several functions use an enum type as parameter for an event/state, > but are called in some locations with an argument of a different enum > type. Adjust the interface of these functions to reality by changing the > parameter to int. enums are

Re: [PATCH] KVM: nVMX: do not pin the VMCS12

On 27/07/2017 19:20, David Matlack wrote: >> + kvm_vcpu_write_guest_page(>vcpu, >> + vmx->nested.current_vmptr >> PAGE_SHIFT, >> + vmx->nested.cached_vmcs12, 0, VMCS12_SIZE); > Have you hit any "suspicious RCU usage" error

Re: [PATCH] KVM: nVMX: do not pin the VMCS12

On 27/07/2017 19:20, David Matlack wrote: >> + kvm_vcpu_write_guest_page(>vcpu, >> + vmx->nested.current_vmptr >> PAGE_SHIFT, >> + vmx->nested.cached_vmcs12, 0, VMCS12_SIZE); > Have you hit any "suspicious RCU usage" error

[PATCH v6 02/14] spi: qup: Setup DMA mode correctly

To operate in DMA mode, the buffer should be aligned and the size of the transfer should be a multiple of block size (for v1). And the no. of words being transferred should be programmed in the count registers appropriately. Signed-off-by: Andy Gross Signed-off-by:

[PATCH v6 02/14] spi: qup: Setup DMA mode correctly

To operate in DMA mode, the buffer should be aligned and the size of the transfer should be a multiple of block size (for v1). And the no. of words being transferred should be programmed in the count registers appropriately. Signed-off-by: Andy Gross Signed-off-by: Varadarajan Narayanan ---

[PATCH v6 04/14] spi: qup: Place the QUP in run mode before DMA

Signed-off-by: Andy Gross Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c index fdd34c3..f1aa5c1 100644 ---

[PATCH v6 04/14] spi: qup: Place the QUP in run mode before DMA

Signed-off-by: Andy Gross Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c index fdd34c3..f1aa5c1 100644 --- a/drivers/spi/spi-qup.c +++ b/drivers/spi/spi-qup.c @@

[PATCH v6 06/14] spi: qup: Fix transaction done signaling

Wait to signal done until we get all of the interrupts we are expecting to get for a transaction. If we don't wait for the input done flag, we can be in between transactions when the done flag comes in and this can mess up the next transaction. While here cleaning up the code which sets

[PATCH v6 06/14] spi: qup: Fix transaction done signaling

Wait to signal done until we get all of the interrupts we are expecting to get for a transaction. If we don't wait for the input done flag, we can be in between transactions when the done flag comes in and this can mess up the next transaction. While here cleaning up the code which sets

[PATCH v6 05/14] spi: qup: Fix error handling in spi_qup_prep_sg

Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c index f1aa5c1..ef95294 100644 --- a/drivers/spi/spi-qup.c +++ b/drivers/spi/spi-qup.c @@

[PATCH v6 05/14] spi: qup: Fix error handling in spi_qup_prep_sg

Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c index f1aa5c1..ef95294 100644 --- a/drivers/spi/spi-qup.c +++ b/drivers/spi/spi-qup.c @@ -311,8 +311,8 @@ static

Re: [PATCH v2 05/11] net: stmmac: dwmac-rk: Add internal phy support

Hi Florian, 在 2017/7/28 0:54, Florian Fainelli 写道: - if you need knowledge about this PHY connection type prior to binding the PHY device and its driver (that is, before of_phy_connect()) we could add a boolean property e.g: "phy-is-internal" that allows us to know that, or we can have a new

Re: [PATCH v2 05/11] net: stmmac: dwmac-rk: Add internal phy support

Hi Florian, 在 2017/7/28 0:54, Florian Fainelli 写道: - if you need knowledge about this PHY connection type prior to binding the PHY device and its driver (that is, before of_phy_connect()) we could add a boolean property e.g: "phy-is-internal" that allows us to know that, or we can have a new

[PATCH v6 09/14] spi: qup: call io_config in mode specific function

DMA transactions should only only need to call io_config only once, but block mode might call it several times to setup several transactions so it can handle reads/writes larger than the max size per transaction, so we move the call to the do_ functions. This is just refactoring, there should be

[PATCH v6 09/14] spi: qup: call io_config in mode specific function

DMA transactions should only only need to call io_config only once, but block mode might call it several times to setup several transactions so it can handle reads/writes larger than the max size per transaction, so we move the call to the do_ functions. This is just refactoring, there should be

[PATCH v6 12/14] spi: qup: allow multiple DMA transactions per spi xfer

Much like the block mode changes, we are breaking up DMA transactions into 64K chunks so we can reset the QUP engine. Signed-off-by: Matthew McClintock Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 92

[PATCH v6 12/14] spi: qup: allow multiple DMA transactions per spi xfer

Much like the block mode changes, we are breaking up DMA transactions into 64K chunks so we can reset the QUP engine. Signed-off-by: Matthew McClintock Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 92 --- 1 file changed, 66

[PATCH v6 14/14] spi: qup: Fix QUP version identify method

Use of_device_get_match_data to identify QUP version instead of of_device_is_compatible. Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c

[PATCH v6 10/14] spi: qup: allow block mode to generate multiple transactions

This let's you write more to the SPI bus than 64K-1 which is important if the block size of a SPI device is >= 64K or some other device wants to do something larger. This has the benefit of completely removing spi_message from the spi-qup transactions Signed-off-by: Matthew McClintock

[PATCH v6 14/14] spi: qup: Fix QUP version identify method

Use of_device_get_match_data to identify QUP version instead of of_device_is_compatible. Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c index 4c3c938..1364516

[PATCH v6 10/14] spi: qup: allow block mode to generate multiple transactions

This let's you write more to the SPI bus than 64K-1 which is important if the block size of a SPI device is >= 64K or some other device wants to do something larger. This has the benefit of completely removing spi_message from the spi-qup transactions Signed-off-by: Matthew McClintock

[PATCH v6 13/14] spi: qup: Ensure done detection

This patch fixes an issue where a SPI transaction has completed, but the done condition is missed. This occurs because at the time of interrupt the MAX_INPUT_DONE_FLAG is not asserted. However, in the process of reading blocks of data from the FIFO, the last portion of data comes in. The

[PATCH v6 11/14] spi: qup: refactor spi_qup_prep_sg

Take specific sgl and nent to be prepared. This is in preparation for splitting DMA into multiple transacations, this contains no code changes just refactoring. Signed-off-by: Matthew McClintock Signed-off-by: Varadarajan Narayanan ---

[PATCH v6 13/14] spi: qup: Ensure done detection

This patch fixes an issue where a SPI transaction has completed, but the done condition is missed. This occurs because at the time of interrupt the MAX_INPUT_DONE_FLAG is not asserted. However, in the process of reading blocks of data from the FIFO, the last portion of data comes in. The

[PATCH v6 11/14] spi: qup: refactor spi_qup_prep_sg

Take specific sgl and nent to be prepared. This is in preparation for splitting DMA into multiple transacations, this contains no code changes just refactoring. Signed-off-by: Matthew McClintock Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 23 ++- 1

[PATCH v6 07/14] spi: qup: Do block sized read/write in block mode

This patch corrects the behavior of the BLOCK transactions. During block transactions, the controller must be read/written to in block size transactions. Signed-off-by: Andy Gross Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c |

[PATCH v6 07/14] spi: qup: Do block sized read/write in block mode

This patch corrects the behavior of the BLOCK transactions. During block transactions, the controller must be read/written to in block size transactions. Signed-off-by: Andy Gross Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 151

[PATCH v6 08/14] spi: qup: refactor spi_qup_io_config into two functions

This is in preparation for handling transactions larger than 64K-1 bytes in block mode, which is currently unsupported and quietly fails. We need to break these into two functions 1) prep is called once per spi_message and 2) io_config is called once per spi-qup bus transaction This is just

[PATCH v6 03/14] spi: qup: Add completion timeout

Add i/o completion timeout for DMA and PIO modes. Signed-off-by: Andy Gross Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-qup.c

[PATCH v6 08/14] spi: qup: refactor spi_qup_io_config into two functions

This is in preparation for handling transactions larger than 64K-1 bytes in block mode, which is currently unsupported and quietly fails. We need to break these into two functions 1) prep is called once per spi_message and 2) io_config is called once per spi-qup bus transaction This is just

[PATCH v6 03/14] spi: qup: Add completion timeout

Add i/o completion timeout for DMA and PIO modes. Signed-off-by: Andy Gross Signed-off-by: Varadarajan Narayanan --- drivers/spi/spi-qup.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c index abe799b..fdd34c3

[PATCH v6 01/14] spi: qup: Enable chip select support

Enable chip select support for QUP versions later than v1. The chip select support was broken in QUP version 1. Hence the chip select support was removed earlier in an earlier commit (4a8573abe "spi: qup: Remove chip select function"). Since the chip select support is functional in recent versions

[PATCH v6 01/14] spi: qup: Enable chip select support

Enable chip select support for QUP versions later than v1. The chip select support was broken in QUP version 1. Hence the chip select support was removed earlier in an earlier commit (4a8573abe "spi: qup: Remove chip select function"). Since the chip select support is functional in recent versions

[PATCH v6 00/14] spi: qup: Fixes and add support for >64k transfers

v6: Fix git bisect-ability issues in spi: qup: Add completion timeout spi: qup: call io_config in mode specific function spi: qup: allow multiple DMA transactions per spi xfer v5: Incorporate feedback from Mark Brown and Geert

[PATCH v6 00/14] spi: qup: Fixes and add support for >64k transfers

v6: Fix git bisect-ability issues in spi: qup: Add completion timeout spi: qup: call io_config in mode specific function spi: qup: allow multiple DMA transactions per spi xfer v5: Incorporate feedback from Mark Brown and Geert

Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

On Fri, Jul 28, 2017 at 06:25:55AM +0200, Willy Tarreau wrote: > Hi Leo, > > There was no upstream commit ID here but I found it in mainline here : > > commit 109704492ef637956265ec2eb72ae7b3b39eb6f4 > Author: Joel Fernandes > Date: Thu Oct 20 00:34:00 2016 -0700 > >

Re: [PATCH 3.10] pstore: Make spinlock per zone instead of global

On Fri, Jul 28, 2017 at 06:25:55AM +0200, Willy Tarreau wrote: > Hi Leo, > > There was no upstream commit ID here but I found it in mainline here : > > commit 109704492ef637956265ec2eb72ae7b3b39eb6f4 > Author: Joel Fernandes > Date: Thu Oct 20 00:34:00 2016 -0700 > > pstore: Make

Re: [PATCH v8 06/13] iommu/amd: copy old trans table from old kernel

On 07/27/17 at 05:38pm, Joerg Roedel wrote: > On Fri, Jul 21, 2017 at 04:59:04PM +0800, Baoquan He wrote: > > @@ -2128,9 +2131,43 @@ static void early_enable_iommu(struct amd_iommu > > *iommu) > > static void early_enable_iommus(void) > > { > > struct amd_iommu *iommu; > > + bool

Re: [PATCH v8 06/13] iommu/amd: copy old trans table from old kernel

On 07/27/17 at 05:38pm, Joerg Roedel wrote: > On Fri, Jul 21, 2017 at 04:59:04PM +0800, Baoquan He wrote: > > @@ -2128,9 +2131,43 @@ static void early_enable_iommu(struct amd_iommu > > *iommu) > > static void early_enable_iommus(void) > > { > > struct amd_iommu *iommu; > > + bool

Re: [PATCH v7 16/26] x86/insn-eval: Support both signed 32-bit and 64-bit effective addresses

On Thu, Jul 27, 2017 at 07:04:52PM -0700, Ricardo Neri wrote: > However using the union could be less readable than having two almost > identical functions. So having some small duplication for the sake of clarity and readability is much better, if you ask me. And it's not like you're duplicating

Re: [PATCH v7 16/26] x86/insn-eval: Support both signed 32-bit and 64-bit effective addresses

On Thu, Jul 27, 2017 at 07:04:52PM -0700, Ricardo Neri wrote: > However using the union could be less readable than having two almost > identical functions. So having some small duplication for the sake of clarity and readability is much better, if you ask me. And it's not like you're duplicating

[PATCH] x86/boot: check overlap between kernel and EFI_BOOT_SERVICES_*

On Wed, Jul 26, 2017 at 09:34:32AM +0800, Baoquan He wrote: > On 07/26/17 at 09:13am, Baoquan He wrote: > > On 07/26/17 at 12:12am, Naoya Horiguchi wrote: > > > On Mon, Jul 24, 2017 at 02:20:44PM +0100, Matt Fleming wrote: > > > > On Mon, 10 Jul, at 02:51:36PM, Naoya Horiguchi wrote: > > > > >

[PATCH] x86/boot: check overlap between kernel and EFI_BOOT_SERVICES_*

On Wed, Jul 26, 2017 at 09:34:32AM +0800, Baoquan He wrote: > On 07/26/17 at 09:13am, Baoquan He wrote: > > On 07/26/17 at 12:12am, Naoya Horiguchi wrote: > > > On Mon, Jul 24, 2017 at 02:20:44PM +0100, Matt Fleming wrote: > > > > On Mon, 10 Jul, at 02:51:36PM, Naoya Horiguchi wrote: > > > > >

[PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU from policy-A can change frequency of CPUs belonging to policy-B. This is quite common in case of ARM platforms where we don't configure any per-cpu register. Add a flag to identify such platforms and update

[PATCH V5 2/2] cpufreq: Process remote callbacks from any CPU if the platform permits

On many platforms, CPUs can do DVFS across cpufreq policies. i.e CPU from policy-A can change frequency of CPUs belonging to policy-B. This is quite common in case of ARM platforms where we don't configure any per-cpu register. Add a flag to identify such platforms and update

[PATCH V5 0/2] sched: cpufreq: Allow remote callbacks

With Android UI and benchmarks the latency of cpufreq response to certain scheduling events can become very critical. Currently, callbacks into cpufreq governors are only made from the scheduler if the target CPU of the event is the same as the current CPU. This means there are certain situations

[PATCH V5 1/2] sched: cpufreq: Allow remote cpufreq callbacks

With Android UI and benchmarks the latency of cpufreq response to certain scheduling events can become very critical. Currently, callbacks into cpufreq governors are only made from the scheduler if the target CPU of the event is the same as the current CPU. This means there are certain situations

[PATCH V5 0/2] sched: cpufreq: Allow remote callbacks

With Android UI and benchmarks the latency of cpufreq response to certain scheduling events can become very critical. Currently, callbacks into cpufreq governors are only made from the scheduler if the target CPU of the event is the same as the current CPU. This means there are certain situations

[PATCH V5 1/2] sched: cpufreq: Allow remote cpufreq callbacks

With Android UI and benchmarks the latency of cpufreq response to certain scheduling events can become very critical. Currently, callbacks into cpufreq governors are only made from the scheduler if the target CPU of the event is the same as the current CPU. This means there are certain situations

Re: [PATCH v2 05/11] net: stmmac: dwmac-rk: Add internal phy support

Hi Andrew, 在 2017/7/27 21:48, Andrew Lunn 写道: I think we need to discuss this. This PHY appears to be on an MDIO bus, it uses a standard PHY driver, and it appears to be using an RMII interface. So it is just an ordinary PHY. Internal is supposed to be something which is not ordinary, does not

Re: [PATCH v2 05/11] net: stmmac: dwmac-rk: Add internal phy support

Hi Andrew, 在 2017/7/27 21:48, Andrew Lunn 写道: I think we need to discuss this. This PHY appears to be on an MDIO bus, it uses a standard PHY driver, and it appears to be using an RMII interface. So it is just an ordinary PHY. Internal is supposed to be something which is not ordinary, does not

Re: [PATCH v7] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

* Baoquan He wrote: > Currently KASLR will parse all e820 entries of RAM type and add all > candidate position into slots array. Then we will choose one slot > randomly as the new position which kernel will be decompressed into > and run at. > > On system with EFI enabled,

Re: [PATCH v7] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

* Baoquan He wrote: > Currently KASLR will parse all e820 entries of RAM type and add all > candidate position into slots array. Then we will choose one slot > randomly as the new position which kernel will be decompressed into > and run at. > > On system with EFI enabled, e820 memory regions

Re: [PATCH v3] cpu_pm: replace raw_notifier to atomic_notifier

* Alex Shi [170727 18:42]: > Tony Lezcano found a miss use that rcu_read_lock used after rcu_idle_enter > Paul E. McKenney suggested trying RCU_NONIDLE. Hmm I think you have a hybrid name typo above in case you mean me :) Tony

Re: [PATCH v3] cpu_pm: replace raw_notifier to atomic_notifier

* Alex Shi [170727 18:42]: > Tony Lezcano found a miss use that rcu_read_lock used after rcu_idle_enter > Paul E. McKenney suggested trying RCU_NONIDLE. Hmm I think you have a hybrid name typo above in case you mean me :) Tony

<    10   11   12   13   14   15   16   >