On Mon, Sep 23, 2019 at 08:29:40AM +0200, Greg Kurz wrote:
> There's a bug in skiboot that causes the OPAL_XIVE_ALLOCATE_IRQ call
> to return the 32-bit value 0x when OPAL has run out of IRQs.
> Unfortunatelty, OPAL return values are signed 64-bit entities and
> errors are supposed to be ne
Currently it is not possible to distinguish the case when fadump is
supported by firmware and disabled in kernel and completely unsupported
using the kernel sysfs interface. User can investigate the devicetree
but it is more reasonable to provide sysfs files in case we get some
fadumpv2 in the fu
On 12/09/2019 15:29, Oliver O'Halloran wrote:
> Use the pnv_phb structure as the private data pointer for the debugfs
> files. This lets us delete some code and an open-coded use of
> hose->private_data.
>
> Signed-off-by: Oliver O'Halloran
Reviewed-by: Alexey Kardashevskiy
> ---
> arc
On 12/09/2019 15:29, Oliver O'Halloran wrote:
> Add a debugfs entry to dump the state of the active IODA PEs. The IODA PE
> state reflects how the PHB's internal concept of a PE is configured. This
> is separate to the EEH PE state and is managed power the PowerNV PCI
> backend rather than the E
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index 2874811a4398..9e303a5f4d85 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -738,7 +738,7 @@ int ocxl_link_add_lpc_mem(void *link_handle, u64 size)
}
EXPORT_SYMBOL_GPL(ocxl_link_add_lpc_mem);
On Tue, Sep 17, 2019 at 08:48:54PM +0800, Yunsheng Lin wrote:
> When passing the return value of dev_to_node() to cpumask_of_node()
> without checking if the device's node id is NUMA_NO_NODE, there is
> global-out-of-bounds detected by KASAN.
>
> From the discussion [1], NUMA_NO_NODE really means
On Mon 23-09-19 17:15:19, Peter Zijlstra wrote:
> On Tue, Sep 17, 2019 at 08:48:54PM +0800, Yunsheng Lin wrote:
> > When passing the return value of dev_to_node() to cpumask_of_node()
> > without checking if the device's node id is NUMA_NO_NODE, there is
> > global-out-of-bounds detected by KASAN.
Each vCPU of a VM allocates a XIVE VP in OPAL which is associated with
8 event queue (EQ) descriptors, one for each priority. A POWER9 socket
can handle a maximum of 1M event queues.
The powernv platform allocates NR_CPUS (== 2048) VPs for the hypervisor,
and each XIVE KVM device allocates KVM_MAX
From: Cédric Le Goater
Do not assign the device private pointer before making sure the XIVE
VPs are allocated in OPAL and test pointer validity when releasing
the device.
Fixes: 5422e95103cf ("KVM: PPC: Book3S HV: XIVE: Replace the 'destroy' method
by a 'release' method")
Signed-off-by: Cédric
If we cannot allocate the XIVE VPs in OPAL, the creation of a XIVE or
XICS-on-XIVE device is aborted as expected, but we leave kvm->arch.xive
set forever since the relase method isn't called in this case. Any
subsequent tentative to create a XIVE or XICS-on-XIVE for this VM will
thus always fail. T
We currently prevent userspace to connect a new vCPU if we already have
one with the same vCPU id. This is good but unfortunately not enough,
because VP ids derive from the packed vCPU ids, and kvmppc_pack_vcpu_id()
can return colliding values. For examples, 348 stays unchanged since it
is < KVM_MA
Reduce code duplication by consolidating the checking of vCPU ids and VP
ids to a common helper used by both legacy and native XIVE KVM devices.
And explain the magic with a comment.
Signed-off-by: Greg Kurz
---
arch/powerpc/kvm/book3s_xive.c| 42 ++---
arch
The XIVE VP is an internal structure which allow the XIVE interrupt
controller to maintain the interrupt context state of vCPUs non
dispatched on HW threads.
When a guest is started, the XIVE KVM device allocates a block of
XIVE VPs in OPAL, enough to accommodate the highest possible vCPU
id KVM_M
Add a new attribute to both legacy and native XIVE KVM devices so that
userspace can require less interrupt servers than the current default
(KVM_MAX_VCPUS, 2048). This will allow to allocate less VPs in OPAL,
and likely increase the number of VMs that can run with an in-kernel
XIVE implementation.
On Mon, Sep 23, 2019 at 05:28:56PM +0200, Michal Hocko wrote:
> On Mon 23-09-19 17:15:19, Peter Zijlstra wrote:
> > > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > > index 4123100e..9859acb 100644
> > > --- a/arch/x86/mm/numa.c
> > > +++ b/arch/x86/mm/numa.c
> > > @@ -861,6 +861,9 @@ vo
On 23/09/2019 17:44, Greg Kurz wrote:
> Add a new attribute to both legacy and native XIVE KVM devices so that
> userspace can require less interrupt servers than the current default
> (KVM_MAX_VCPUS, 2048). This will allow to allocate less VPs in OPAL,
> and likely increase the number of VMs that
On 23/09/2019 17:43, Greg Kurz wrote:
> We currently prevent userspace to connect a new vCPU if we already have
> one with the same vCPU id. This is good but unfortunately not enough,
> because VP ids derive from the packed vCPU ids, and kvmppc_pack_vcpu_id()
> can return colliding values. For exam
On 23/09/2019 17:43, Greg Kurz wrote:
> If we cannot allocate the XIVE VPs in OPAL, the creation of a XIVE or
> XICS-on-XIVE device is aborted as expected, but we leave kvm->arch.xive
> set forever since the relase method isn't called in this case. Any
release
> subsequent tentative to create a X
On Mon 23-09-19 17:48:52, Peter Zijlstra wrote:
> On Mon, Sep 23, 2019 at 05:28:56PM +0200, Michal Hocko wrote:
> > On Mon 23-09-19 17:15:19, Peter Zijlstra wrote:
>
> > > > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
> > > > index 4123100e..9859acb 100644
> > > > --- a/arch/x86/mm/numa.c
On Fri, 2019-09-20 at 17:48 -0700, John Hubbard wrote:
>
[...]
> So it seems that full memory barriers (not just compiler barriers) are
> required.
> If the irq enable/disable somehow provides that, then your new code just goes
> along for the ride and Just Works. (You don't have any memory barri
Sam Bobroff writes:
> Thanks, this does look like a bug to me. I couldn't replicate your crash
> (even with CONFIG_SLUB_DEBUG_ON) but I think I do see a bug there.
>
> Does the below patch also fix it for you?
Yes, this works as well, thanks.
> diff --git a/arch/powerpc/kernel/eeh.c b/arch/powe
On 9/23/19 10:25 AM, Leonardo Bras wrote:
> On Fri, 2019-09-20 at 17:48 -0700, John Hubbard wrote:
>>
> [...]
>> So it seems that full memory barriers (not just compiler barriers) are
>> required.
>> If the irq enable/disable somehow provides that, then your new code just goes
>> along for the rid
On Thu, 2019-09-19 at 23:47 -0300, Leonardo Bras wrote:
> Hello Paul,
> I sent this patch, but I have a question:
>
> > + mm = current->mm;
>
> Here, current->mm is not always the same as kvm->mm?
> Thanks
I have contacted Paul, who said it is equivalent. But I think I will
deal with that o
By replacing, we would reduce the use of 'global' current on code,
relying more in the contents of kvm struct.
On code, I found that in kvm_create_vm() there is:
kvm->mm = current->mm;
And that on every kvm_*_ioctl we have tests like that:
if (kvm->mm != current->mm)
return -EIO;
So this
Given that in kvm_create_vm() there is:
kvm->mm = current->mm;
And that on every kvm_*_ioctl we have:
if (kvm->mm != current->mm)
return -EIO;
I see no reason to keep using current->mm instead of kvm->mm.
By doing so, we would reduce the use of 'global' variables on code, relying
more in
Given that in kvm_create_vm() there is:
kvm->mm = current->mm;
And that on every kvm_*_ioctl we have:
if (kvm->mm != current->mm)
return -EIO;
I see no reason to keep using current->mm instead of kvm->mm.
By doing so, we would reduce the use of 'global' variables on code, relying
more in
Given that in kvm_create_vm() there is:
kvm->mm = current->mm;
And that on every kvm_*_ioctl we have:
if (kvm->mm != current->mm)
return -EIO;
I see no reason to keep using current->mm instead of kvm->mm.
By doing so, we would reduce the use of 'global' variables on code, relying
more in
On Mon, 2019-09-23 at 15:35 -0300, Leonardo Bras wrote:
> Could you please provide feedback on this patch?
I have done a very simple comparison with gcc disassemble:
By applying this patch, there was a reduction in the function size from
882 to 878 instructions.
signature.asc
Description: This i
On Mon, 2019-09-23 at 11:14 -0700, John Hubbard wrote:
> On 9/23/19 10:25 AM, Leonardo Bras wrote:
> [...]
> That part is all fine, but there are no run-time memory barriers in the
> atomic_inc() and atomic_dec() additions, which means that this is not
> safe, because memory operations on CPU 1 ca
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
drivers/acpi/Kconfig | 8 +-
drivers/ata/Kconfig | 12 +--
dri
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
certs/Kconfig | 14 ++---
init/Kconfig | 28 +-
Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^/\t/' -i */Kconfig
Signed-off-by: Krzysztof Kozlowski
---
arch/Kconfig | 4 ++--
arch/alpha/Kconfig | 2 +-
arch/arm/Kconfig
On older distributions like Sles12SP5 gcc does not recognize
-no-pie option making the powerpc selftests build to fail
Fixes the following:
gcc: error: unrecognized command line option ‘-no-pie’
Signed-off-by: Harish
---
tools/testing/selftests/powerpc/pmu/ebb/Makefile | 7 ++-
1 file chang
On 9/23/19 12:40 PM, Leonardo Bras wrote:
> On Mon, 2019-09-23 at 11:14 -0700, John Hubbard wrote:
>> On 9/23/19 10:25 AM, Leonardo Bras wrote:
>> [...]
>> That part is all fine, but there are no run-time memory barriers in the
>> atomic_inc() and atomic_dec() additions, which means that this is n
On Mon, 2019-09-23 at 12:58 -0700, John Hubbard wrote:
>
> CPU 0CPU 1
> -- --
>READ(pte) (re-ordered at run time)
>atomic_inc(val) (no run-time memory barrier!)
>
On 9/23/19 1:23 PM, Leonardo Bras wrote:
> On Mon, 2019-09-23 at 12:58 -0700, John Hubbard wrote:
>>
>> CPU 0CPU 1
>> -- --
>>READ(pte) (re-ordered at run time)
>>atom
On 9/20/19 12:50 PM, Leonardo Bras wrote:
> As decribed, gup_pgd_range is a lockless pagetable walk. So, in order to
> monitor against THP split/collapse with the couting method, it's necessary
> to bound it with {start,end}_lockless_pgtbl_walk.
>
> There are dummy functions, so it is not going to
On Mon, Sep 23, 2019 at 06:52:35PM +0200, Michal Hocko wrote:
> On Mon 23-09-19 17:48:52, Peter Zijlstra wrote:
> To the NUMA_NO_NODE itself. Your earlier email noted:
> : > +
> : > if ((unsigned)node >= nr_node_ids) {
> : > printk(KERN_WARNING
> : > "cpumask_of_node(
On 9/20/19 12:50 PM, Leonardo Bras wrote:
> There is a need to monitor lockless pagetable walks, in order to avoid
> doing THP splitting/collapsing during them.
>
> Some methods rely on local_irq_{save,restore}, but that can be slow on
> cases with a lot of cpus are used for the process.
>
> In o
On 9/20/19 12:50 PM, Leonardo Bras wrote:
> It's necessary to monitor lockless pagetable walks, in order to avoid doing
> THP splitting/collapsing during them.
>
> Some methods rely on local_irq_{save,restore}, but that can be slow on
> cases with a lot of cpus are used for the process.
>
> In or
On 9/20/19 12:50 PM, Leonardo Bras wrote:
> Applies the counting-based method for monitoring all book3s_hv related
> functions that do lockless pagetable walks.
>
> Signed-off-by: Leonardo Bras
> ---
> arch/powerpc/kvm/book3s_hv_nested.c | 8
> arch/powerpc/kvm/book3s_hv_rm_mmu.c | 9 ++
Thanks for the feedback,
On Mon, 2019-09-23 at 13:39 -0700, John Hubbard wrote:
> Please remember to include linux-mm if there is a v2.
Sure, I will include on v3.
> Nit: seems like it would be nicer to just put it all in one place, and use
> positive logic, and also I think people normally don'
On Mon, 2019-09-23 at 13:42 -0700, John Hubbard wrote:
> Somewhere, there should be a short comment that explains how the following
> functions
> are meant to be used. And it should include the interaction with irqs, so
> maybe
> if you end up adding that combined wrapper function that does both,
On 9/20/19 1:12 PM, Leonardo Bras wrote:
...
>> arch/powerpc/include/asm/book3s/64/mmu.h | 3 +++
>> arch/powerpc/include/asm/book3s/64/pgtable.h | 5 +
>> arch/powerpc/kernel/mce_power.c | 13 ++---
>> arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 ++
>> arch/po
On 9/23/19 1:48 PM, Leonardo Bras wrote:
> Thanks for the feedback,
>
> On Mon, 2019-09-23 at 13:39 -0700, John Hubbard wrote:
>> Please remember to include linux-mm if there is a v2.
>
> Sure, I will include on v3.
>
>> Nit: seems like it would be nicer to just put it all in one place, and use
On Mon, 2019-09-23 at 13:51 -0700, John Hubbard wrote:
> Also, which tree do these patches apply to, please?
>
> thanks,
They should apply on top of v5.3 + one patch:
https://patchwork.ozlabs.org/patch/1164925/
I was working on top of this patch, because I thought it would be
merged fast. But
On Mon, 2019-09-23 at 13:27 -0700, John Hubbard wrote:
> I'd also like a second opinion from the "core" -mm maintainers, but it seems
> like
> there is now too much code around the gup_pgd_range() call. Especially since
> there
> are two places where it's called--did you forget the other one in
On 9/23/19 2:01 PM, Leonardo Bras wrote:
> On Mon, 2019-09-23 at 13:27 -0700, John Hubbard wrote:
>> I'd also like a second opinion from the "core" -mm maintainers, but it seems
>> like
>> there is now too much code around the gup_pgd_range() call. Especially since
>> there
>> are two places wher
On Sun, Sep 22, 2019 at 5:04 AM Michael Ellerman wrote:
>
>
>
> On 21 September 2019 4:31:16 am AEST, Dan Williams
> wrote:
> >On Fri, Sep 20, 2019 at 11:18 AM Qian Cai wrote:
> >>
> >> On Fri, 2019-09-20 at 19:55 +0530, Aneesh Kumar K.V wrote:
> >> > Qian Cai writes:
> >> >
> >> > > The linux
Reduces the number of calls to get_current() in order to get the value of
current->mm by doing it once and storing the value, since it is not
supposed to change inside the same process).
Signed-off-by: Leonardo Bras
---
Re-sending to all lists involved. (I missed kvm ones)
arch/powerpc/kvm/book
On Wed, Sep 11, 2019 at 05:31:55PM -0500, Michael Roth wrote:
> On a 2-socket Power9 system with 32 cores/128 threads (SMT4) and 1TB
> of memory running the following guest configs:
>
> guest A:
> - 224GB of memory
> - 56 VCPUs (sockets=1,cores=28,threads=2), where:
> VCPUs 0-1 are
I have done a very simple comparison with gdb disassemble:
By applying this patch, there was a reduction in the function size from
882 to 878 instructions.
(It's a resend, due to not having all the correct lists on my previous
mail)
On Mon, 2019-09-23 at 18:30 -0300, Leonardo Bras wrote:
> Reduc
On 2019/9/24 4:34, Peter Zijlstra wrote:
> On Mon, Sep 23, 2019 at 06:52:35PM +0200, Michal Hocko wrote:
>> On Mon 23-09-19 17:48:52, Peter Zijlstra wrote:
>
>> To the NUMA_NO_NODE itself. Your earlier email noted:
>> : > +
>> : > if ((unsigned)node >= nr_node_ids) {
>> : >
Add the PCIe EP multiple PF support for DWC and Layerscape, add
the doorbell MSIX function for DWC, use list to manage the PF of
one PCIe controller, and refactor the Layerscape EP driver due to
some platforms difference.
Xiaowei Bao (11):
PCI: designware-ep: Add multiple PFs support for DWC
P
Add multiple PFs support for DWC, due to different PF have different
config space, we use func_conf_select callback function to access
the different PF's config space, the different chip company need to
implement this callback function when use the DWC IP core and intend
to support multiple PFs fea
Move the function of getting MSI capability to the front of init
function, because the init function of the EP platform driver will use
the return value by the function of getting MSI capability.
Signed-off-by: Xiaowei Bao
Reviewed-by: Andrew Murray
---
v2:
- No change.
v3:
- No change.
v4:
-
Each PF of EP device should have it's own MSI or MSIX capabitily
struct, so create a dw_pcie_ep_func struct and remove the msi_cap
and msix_cap to this struct from dw_pcie_ep, and manage the PFs
with a list.
Signed-off-by: Xiaowei Bao
---
v3:
- This is a new patch, to fix the issue of MSI and MS
Add the doorbell mode of MSI-X in DWC EP driver.
Signed-off-by: Xiaowei Bao
Reviewed-by: Andrew Murray
---
v2:
- Remove the macro of no used.
v3:
- No change.
v4:
- Modify the commit message.
drivers/pci/controller/dwc/pcie-designware-ep.c | 14 ++
drivers/pci/controller/dwc/pci
Add compatible strings for ls1088a and ls2088a.
Signed-off-by: Xiaowei Bao
---
v2:
- No change.
v3:
- Use one valid combination of compatible strings.
v4:
- Add the comma between the two compatible.
Documentation/devicetree/bindings/pci/layerscape-pci.txt | 2 ++
1 file changed, 2 insertions
Fix some format issue of the code in EP driver.
Signed-off-by: Xiaowei Bao
Reviewed-by: Andrew Murray
---
v2:
- No change.
v3:
- No change.
v4:
- No change.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/con
dw_pcie_ep_raise_msix_irq was never called in the exisitng driver
before, because the ls1046a platform don't support the MSIX feature
and msix_capable was always set to false.
Now that add the ls1088a platform with MSIX support, but the existing
dw_pcie_ep_raise_msix_irq doesn't work, so use the do
The different PCIe controller in one board may be have different
capability of MSI or MSIX, so change the way of getting the MSI
capability, make it more flexible.
Signed-off-by: Xiaowei Bao
---
v2:
- Remove the repeated assignment code.
v3:
- Use ep_func msi_cap and msix_cap to decide the msi_
Add PCIe EP node for ls1088a to support EP mode.
Signed-off-by: Xiaowei Bao
---
v2:
- Remove the pf-offset proparty.
v3:
- No change.
v4:
- No change.
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31 ++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/bo
Add PCIe EP mode support for ls1088a and ls2088a, there are some
difference between LS1 and LS2 platform, so refactor the code of
the EP driver.
Signed-off-by: Xiaowei Bao
---
v2:
- This is a new patch for supporting the ls1088a and ls2088a platform.
v3:
- Adjust the some struct assignment ord
Add LS1088a in pci_device_id table so that pci-epf-test can be used
for testing PCIe EP in LS1088a.
Signed-off-by: Xiaowei Bao
---
v2:
- No change.
v3:
- No change.
v4:
- Use a maco to define the LS1088a device ID.
drivers/misc/pci_endpoint_test.c | 2 ++
1 file changed, 2 insertions(+)
di
Description:
- Reading configuration register RCPM_IPPDEXPCR1
always return zero
Workaround:
- Save register RCPM_IPPDEXPCR1's value to
register SCFG_SPARECR8.(uboot's psci also
need reading value from the register SCFG_SPARECR8
to set regist
The patch fix a bug that FlexTimer cannot
wakeup system in deep sleep.
Signed-off-by: Biwen Li
---
Change in v3:
- update property name
fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
Change in v2:
- None
arch/arm/boot/dts/ls1021a.dtsi | 1 +
1 file changed
The 'fsl,ippdexpcr-alt-addr' property is used to handle an errata A-008646
on LS1021A
Signed-off-by: Biwen Li
---
Change in v3:
- rename property name
fsl,rcpm-scfg -> fsl,ippdexpcr-alt-addr
Change in v2:
- update desc of the property 'fsl,rcpm-scfg'
Documentation/dev
The store ordering vs tlbie issue mentioned in
commit a5d4b5891c2f ("powerpc/mm: Fixup tlbie vs store ordering issue on
POWER9") is fixed for Nimbus 2.3 and Cumulus 1.3 revisions. We don't need
to apply the fixup if we are running on them
We can only do this on PowerNV. On pseries guest with kvm w
Rename the #define to indicate this is related to store vs tlbie ordering issue.
In the next patch, we will be adding another feature flag that is used to
handles ERAT flush vs tlbie ordering issue.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/cputable.h| 4 ++--
arch/powerpc
Signed-off-by: Aneesh Kumar K.V
---
tools/testing/selftests/powerpc/mm/Makefile | 3 +
.../testing/selftests/powerpc/mm/tlbie_test.c | 739 ++
2 files changed, 742 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/mm/tlbie_test.c
diff --git a/tools/testing/sel
On POWER9, under some circumstances, a broadcast TLB invalidation
will fail to invalidate the ERAT cache on some threads when there are
parallel mtpidr/mtlpidr happening on other threads of the same core.
This can cause stores to continue to go to a page after it's unmapped.
The workaround is to f
Hi Fred,
what is this made against of? It does not apply on the master. Thanks,
On 10/09/2019 01:45, Frederic Barrat wrote:
> This is the linux part of the work to use the PCI hotplug framework to
> control an opencapi card so that it can be reset and re-read after
> flashing a new FPGA image. I
In later patch, we want to use hash_transparent_hugepage() in a kernel module.
Export two related functions.
Acked-by: Michael Ellerman
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/book3s/64/radix.h | 8 +++-
arch/powerpc/mm/book3s64/hash_pgtable.c| 2 ++
arch/powerpc/mm
On Mon, Sep 23, 2019 at 05:43:37PM +0200, Greg Kurz wrote:
> From: Cédric Le Goater
>
> Do not assign the device private pointer before making sure the XIVE
> VPs are allocated in OPAL and test pointer validity when releasing
> the device.
>
> Fixes: 5422e95103cf ("KVM: PPC: Book3S HV: XIVE: Rep
Hi Scott,
Can you test v7 to see if it works to load a kernel at a non-zero address?
Thanks,
On 2019/9/20 17:45, Jason Yan wrote:
This series implements KASLR for powerpc/fsl_booke/32, as a security
feature that deters exploit attempts relying on knowledge of the location
of kernel internals.
On Mon, Sep 23, 2019 at 05:43:48PM +0200, Greg Kurz wrote:
> We currently prevent userspace to connect a new vCPU if we already have
> one with the same vCPU id. This is good but unfortunately not enough,
> because VP ids derive from the packed vCPU ids, and kvmppc_pack_vcpu_id()
> can return colli
Le 24/09/2019 à 06:24, Alexey Kardashevskiy a écrit :
Hi Fred,
what is this made against of? It does not apply on the master. Thanks,
It applies on v5.3. And I can see there's a conflict with the current
state in the merge window. I'll resubmit.
Fred
On 10/09/2019 01:45, Frederic B
Hi all,
the linux patches depended by RCPM driver,FlexTimer driver and FlexTimer dts,
need apply these patches as follows:
1. RCPM driver:
https://patchwork.kernel.org/series/162731/mbox/(https://patchwork.kernel.org/patch/11105279/)
2. FlexTimer dts:
https://lore.kernel.org/patchwork/series/4
79 matches
Mail list logo
