* [PATCH v13 1/3] ioremap: Update pgtable free interfaces with addr
From: Will Deacon @ 2018-06-06 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528268481-19299-2-git-send-email-cpandya@codeaurora.org>
On Wed, Jun 06, 2018 at 12:31:19PM +0530, Chintan Pandya wrote:
> From: Chintan Pandya <cpandya@codeaurora.org>
>
> The following kernel panic was observed on ARM64 platform due to a stale
> TLB entry.
>
> 1. ioremap with 4K size, a valid pte page table is set.
> 2. iounmap it, its pte entry is set to 0.
> 3. ioremap the same address with 2M size, update its pmd entry with
> a new value.
> 4. CPU may hit an exception because the old pmd entry is still in TLB,
> which leads to a kernel panic.
>
> Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
> table") has addressed this panic by falling to pte mappings in the above
> case on ARM64.
>
> To support pmd mappings in all cases, TLB purge needs to be performed
> in this case on ARM64.
>
> Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
> so that TLB purge can be added later in seprate patches.
>
> [toshi at hpe.com: merge changes, rewrite patch description]
> Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
> Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
> Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: <stable@vger.kernel.org>
>
> ---
> arch/arm64/mm/mmu.c | 4 ++--
> arch/x86/mm/pgtable.c | 8 +++++---
> include/asm-generic/pgtable.h | 8 ++++----
> lib/ioremap.c | 4 ++--
> 4 files changed, 13 insertions(+), 11 deletions(-)
Reviewed-by: Will Deacon <will.deacon@arm.com>
Thanks,
Will
^ permalink raw reply
* [PATCH v13 2/3] arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable
From: Will Deacon @ 2018-06-06 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528268481-19299-3-git-send-email-cpandya@codeaurora.org>
On Wed, Jun 06, 2018 at 12:31:20PM +0530, Chintan Pandya wrote:
> Add an interface to invalidate intermediate page tables
> from TLB for kernel.
>
> Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
> ---
> arch/arm64/include/asm/tlbflush.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
> index dfc61d7..a4a1901 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -218,6 +218,13 @@ static inline void __flush_tlb_pgtable(struct mm_struct *mm,
> dsb(ish);
> }
>
> +static inline void __flush_tlb_kernel_pgtable(unsigned long kaddr)
> +{
> + unsigned long addr = __TLBI_VADDR(kaddr, 0);
> +
> + __tlbi(vaae1is, addr);
> + dsb(ish);
> +}
> #endif
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH v13 3/3] arm64: Implement page table free interfaces
From: Will Deacon @ 2018-06-06 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528268481-19299-4-git-send-email-cpandya@codeaurora.org>
On Wed, Jun 06, 2018 at 12:31:21PM +0530, Chintan Pandya wrote:
> arm64 requires break-before-make. Originally, before
> setting up new pmd/pud entry for huge mapping, in few
> cases, the modifying pmd/pud entry was still valid
> and pointing to next level page table as we only
> clear off leaf PTE in unmap leg.
>
> a) This was resulting into stale entry in TLBs (as few
> TLBs also cache intermediate mapping for performance
> reasons)
> b) Also, modifying pmd/pud was the only reference to
> next level page table and it was getting lost without
> freeing it. So, page leaks were happening.
>
> Implement pud_free_pmd_page() and pmd_free_pte_page() to
> enforce BBM and also free the leaking page tables.
>
> Implementation requires,
> 1) Clearing off the current pud/pmd entry
> 2) Invalidation of TLB
> 3) Freeing of the un-used next level page tables
>
> Signed-off-by: Chintan Pandya <cpandya@codeaurora.org>
> ---
> arch/arm64/mm/mmu.c | 48 ++++++++++++++++++++++++++++++++++++++++++++----
> 1 file changed, 44 insertions(+), 4 deletions(-)
Thanks, I think this looks really good now:
Reviewed-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH] arm64: alternative:flush cache with unpatched code
From: Will Deacon @ 2018-06-06 15:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528218506299.33619@nvidia.com>
On Tue, Jun 05, 2018 at 05:07:54PM +0000, Alexander Van Brunt wrote:
> > 1. Boot. This happens once, and we end up putting *all* secondary cores into
> > a tight loop anyway, so I don't see that the performance of
> > __flush_icache_all is relevant
>
> Native boot happens once. But, each VM that boots will slow down all of
> the other VM's on the system. A VM boot can happen thousands of times.
>
> I really don't want to cause the whole system to hiccup for a millisecond
> or more when there are only a few cache lines that need to be invalidated.
You know we already do this on boot, right? If it's a real issue, I'd argue
that it's the hypervisor's problem to solve.
Anyway, please can you back this up with some real numbers that show the
impact on a real use-case? It feels like we've quickly getting into
hypothetical territory here because you have a instinctive dislike for full
I-cache invalidation.
Will
^ permalink raw reply
* [PATCH][RFC] PCI: rcar: Add bus notifier so we can limit the DMA range
From: Will Deacon @ 2018-06-06 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180604223048.GC30381@bhelgaas-glaptop.roam.corp.google.com>
On Mon, Jun 04, 2018 at 05:30:48PM -0500, Bjorn Helgaas wrote:
> [+cc ARM64 folks, linux-kernel]
>
> The original patch under discussion is:
> https://lkml.kernel.org/r/20180521220514.30256-1-marek.vasut+renesas at gmail.com
>
> On Tue, May 22, 2018 at 11:52:21AM +0200, Marek Vasut wrote:
> > On 05/22/2018 10:10 AM, Arnd Bergmann wrote:
> > > On Tue, May 22, 2018 at 12:05 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> > >> From: Phil Edworthy <phil.edworthy@renesas.com>
> > >>
> > >> The PCIe DMA controller on RCar Gen2 and earlier is on 32bit bus,
> > >> so limit the DMA range to 32bit.
> > >>
> > >> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
> > >> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> > >> Cc: Arnd Bergmann <arnd@arndb.de>
> > >> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> > >> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> > >> Cc: Simon Horman <horms+renesas@verge.net.au>
> > >> Cc: Wolfram Sang <wsa@the-dreams.de>
> > >> Cc: linux-renesas-soc at vger.kernel.org
> > >> To: linux-pci at vger.kernel.org
> > >> ---
> > >> NOTE: I'm aware of https://patchwork.kernel.org/patch/9495895/ , but the
> > >> discussion seems to have gone way off, so I'm sending this as a
> > >> RFC. Any feedback on how to do this limiting properly would be nice.
> > >
> > > Doing it in the driver is clearly not appropriate, we must do this in
> > > common code. If I remember correctly, it's specifically ARM64 that is
> > > broken here, it incorrectly allows setting a DMA mask to 64 bit
> > > when that is not available.
> >
> > Yep, that's correct. ARM64 with devices mapping tremendous amounts of
> > memory. So did anything change since that discussion references in the NOTE?
Is it specifically arm64 that's broken here? If so, why and how do other
archs (e.g. riscv) handle this? I thought all of this behaviour was driven
by the DMA ops, and we're just using generic code for that afaict.
Will
^ permalink raw reply
* [PATCH 1/2] arm64: avoid alloc memory on offline node
From: Will Deacon @ 2018-06-06 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527768879-88161-2-git-send-email-xiexiuqi@huawei.com>
On Thu, May 31, 2018 at 08:14:38PM +0800, Xie XiuQi wrote:
> A numa system may return node which is not online.
> For example, a numa node:
> 1) without memory
> 2) NR_CPUS is very small, and the cpus on the node are not brought up
>
> In this situation, we use NUMA_NO_NODE to avoid oops.
>
> [ 25.732905] Unable to handle kernel NULL pointer dereference at virtual address 00001988
> [ 25.740982] Mem abort info:
> [ 25.743762] ESR = 0x96000005
> [ 25.746803] Exception class = DABT (current EL), IL = 32 bits
> [ 25.752711] SET = 0, FnV = 0
> [ 25.755751] EA = 0, S1PTW = 0
> [ 25.758878] Data abort info:
> [ 25.761745] ISV = 0, ISS = 0x00000005
> [ 25.765568] CM = 0, WnR = 0
> [ 25.768521] [0000000000001988] user address but active_mm is swapper
> [ 25.774861] Internal error: Oops: 96000005 [#1] SMP
> [ 25.779724] Modules linked in:
> [ 25.782768] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.17.0-rc6-mpam+ #115
> [ 25.789714] Hardware name: Huawei D06/D06, BIOS Hisilicon D06 EC UEFI Nemo 2.0 RC0 - B305 05/28/2018
> [ 25.798831] pstate: 80c00009 (Nzcv daif +PAN +UAO)
> [ 25.803612] pc : __alloc_pages_nodemask+0xf0/0xe70
> [ 25.808389] lr : __alloc_pages_nodemask+0x184/0xe70
> [ 25.813252] sp : ffff00000996f660
> [ 25.816553] x29: ffff00000996f660 x28: 0000000000000000
> [ 25.821852] x27: 00000000014012c0 x26: 0000000000000000
> [ 25.827150] x25: 0000000000000003 x24: ffff000008099eac
> [ 25.832449] x23: 0000000000400000 x22: 0000000000000000
> [ 25.837747] x21: 0000000000000001 x20: 0000000000000000
> [ 25.843045] x19: 0000000000400000 x18: 0000000000010e00
> [ 25.848343] x17: 000000000437f790 x16: 0000000000000020
> [ 25.853641] x15: 0000000000000000 x14: 6549435020524541
> [ 25.858939] x13: 20454d502067756c x12: 0000000000000000
> [ 25.864237] x11: ffff00000996f6f0 x10: 0000000000000006
> [ 25.869536] x9 : 00000000000012a4 x8 : ffff8023c000ff90
> [ 25.874834] x7 : 0000000000000000 x6 : ffff000008d73c08
> [ 25.880132] x5 : 0000000000000000 x4 : 0000000000000081
> [ 25.885430] x3 : 0000000000000000 x2 : 0000000000000000
> [ 25.890728] x1 : 0000000000000001 x0 : 0000000000001980
> [ 25.896027] Process swapper/0 (pid: 1, stack limit = 0x (ptrval))
> [ 25.902712] Call trace:
> [ 25.905146] __alloc_pages_nodemask+0xf0/0xe70
> [ 25.909577] allocate_slab+0x94/0x590
> [ 25.913225] new_slab+0x68/0xc8
> [ 25.916353] ___slab_alloc+0x444/0x4f8
> [ 25.920088] __slab_alloc+0x50/0x68
> [ 25.923562] kmem_cache_alloc_node_trace+0xe8/0x230
> [ 25.928426] pci_acpi_scan_root+0x94/0x278
> [ 25.932510] acpi_pci_root_add+0x228/0x4b0
> [ 25.936593] acpi_bus_attach+0x10c/0x218
> [ 25.940501] acpi_bus_attach+0xac/0x218
> [ 25.944323] acpi_bus_attach+0xac/0x218
> [ 25.948144] acpi_bus_scan+0x5c/0xc0
> [ 25.951708] acpi_scan_init+0xf8/0x254
> [ 25.955443] acpi_init+0x310/0x37c
> [ 25.958831] do_one_initcall+0x54/0x208
> [ 25.962653] kernel_init_freeable+0x244/0x340
> [ 25.966999] kernel_init+0x18/0x118
> [ 25.970474] ret_from_fork+0x10/0x1c
> [ 25.974036] Code: 7100047f 321902a4 1a950095 b5000602 (b9400803)
> [ 25.980162] ---[ end trace 64f0893eb21ec283 ]---
> [ 25.984765] Kernel panic - not syncing: Fatal exception
>
> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
> Tested-by: Huiqiang Wang <wanghuiqiang@huawei.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Tomasz Nowicki <Tomasz.Nowicki@caviumnetworks.com>
> Cc: Xishi Qiu <qiuxishi@huawei.com>
> ---
> arch/arm64/kernel/pci.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 0e2ea1c..e17cc45 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -170,6 +170,9 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> struct pci_bus *bus, *child;
> struct acpi_pci_root_ops *root_ops;
>
> + if (node != NUMA_NO_NODE && !node_online(node))
> + node = NUMA_NO_NODE;
> +
This really feels like a bodge, but it does appear to be what other
architectures do, so:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH v13 0/3] Fix issues with huge mapping in ioremap for ARM64
From: Will Deacon @ 2018-06-06 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528268481-19299-1-git-send-email-cpandya@codeaurora.org>
Hi Chintan,
Thanks for sticking with this. I've reviewed the series now and I'm keen
for it to land in mainline. Just a couple of things below.
On Wed, Jun 06, 2018 at 12:31:18PM +0530, Chintan Pandya wrote:
> This series of patches re-bring huge vmap back for arm64.
>
> Patch 1/3 has been taken by Toshi in his series of patches
> by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86"
> to avoid merge conflict with this series.
>
> These patches are tested on 4.16 kernel with Cortex-A75 based SoC.
>
> The test used for verifying these patches is a stress test on
> ioremap/unmap which tries to re-use same io-address but changes
> size of mapping randomly i.e. 4K to 2M to 1G etc. The same test
> used to reproduce 3rd level translation fault without these fixes
> (and also of course with Revert "arm64: Enforce BBM for huge IO/VMAP
> mappings" being part of the tree).
[...]
> These patches can also go into '-stable' branch (if accepted)
> for 4.6 onwards.
Not sure we need to target -stable, since we solved the crash by disabling
the use of huge io mappings.
> arch/arm64/include/asm/tlbflush.h | 7 ++++++
> arch/arm64/mm/mmu.c | 48 +++++++++++++++++++++++++++++++++++----
> arch/x86/mm/pgtable.c | 8 ++++---
> include/asm-generic/pgtable.h | 8 +++----
> lib/ioremap.c | 4 ++--
If you get an ack from the x86 folks, then I could take all of this via
arm64. Alternatively, now that I've reviewed the series this could happily
go via another tree (e.g. akpm).
Thanks,
Will
^ permalink raw reply
* [PATCH][next] pinctrl: pinctrl-single: add allocation failure checking of saved_vals
From: Andy Shevchenko @ 2018-06-06 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606134338.4645-1-colin.king@canonical.com>
On Wed, Jun 6, 2018 at 4:43 PM, Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Currently saved_vals is being allocated and there is no check for
> failed allocation (which is more likely than normal when using
> GFP_ATOMIC). Fix this by checking for a failed allocation and
> propagating this error return down the the caller chain.
>
> Detected by CoverityScan, CID#1469841 ("Dereference null return value")
>
> Fixes: 88a1dbdec682 ("pinctrl: pinctrl-single: Add functions to save and restore pinctrl context")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/pinctrl/pinctrl-single.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
> index 9c3c00515aa0..0905ee002041 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -1588,8 +1588,11 @@ static int pcs_save_context(struct pcs_device *pcs)
>
> mux_bytes = pcs->width / BITS_PER_BYTE;
>
> - if (!pcs->saved_vals)
> + if (!pcs->saved_vals) {
> pcs->saved_vals = devm_kzalloc(pcs->dev, pcs->size, GFP_ATOMIC);
> + if (!pcs->saved_vals)
> + return -ENOMEM;
Wouldn't make sense to move it out of the first condition?
Something like
if (!foo)
foo = ...malloc(...);
if (!foo)
return ...
> + }
>
> switch (pcs->width) {
> case 64:
> @@ -1649,8 +1652,13 @@ static int pinctrl_single_suspend(struct platform_device *pdev,
> if (!pcs)
> return -EINVAL;
>
> - if (pcs->flags & PCS_CONTEXT_LOSS_OFF)
> - pcs_save_context(pcs);
> + if (pcs->flags & PCS_CONTEXT_LOSS_OFF) {
> + int ret;
> +
> + ret = pcs_save_context(pcs);
> + if (ret < 0)
> + return ret;
> + }
>
> return pinctrl_force_sleep(pcs->pctl);
> }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Scott Branden @ 2018-06-06 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606093441.16483-1-peron.clem@gmail.com>
Hi Clement,
On 18-06-06 02:34 AM, Cl?ment P?ron wrote:
> From: Cl?ment Peron <clement.peron@devialet.com>
>
> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
Thanks for upstreaming some missing Cygnus components.
But, the problem is the tarball release from Broadcom you are extracting
these changes from does not contain git history; so, you are missing the
original authors and signed-off's.
I checked our internal git repository and for this commit the author is:
Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
Please adjust author and signed-off appropriately.? If there are other
changes you are extracting from the source tarballs you have please
contact me so we can construct patch appropriately.
Regards,
Scott
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 1cee40ac4613..b7178e84d56d 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -452,6 +452,11 @@
> status = "disabled";
> };
>
> + hwrng: hwrng at 18032000 {
> + compatible = "brcm,iproc-rng200";
> + reg = <0x18032000 0x28>;
> + };
> +
> sdhci0: sdhci at 18041000 {
> compatible = "brcm,sdhci-iproc-cygnus";
> reg = <0x18041000 0x100>;
^ permalink raw reply
* [PATCH] arm64: alternative:flush cache with unpatched code
From: Alexander Van Brunt @ 2018-06-06 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606154455.GH6631@arm.com>
> You know we already do this on boot, right? If it's a real issue, I'd argue
> that it's the hypervisor's problem to solve.
I am very aware. I would like to fix the rest of boot and change KVM to trap when the guest does something like that.
But, if you don't want the patch without using an invalidate all, I would rather get Rohit's patch in with an invalidate all than have a system that fails to boot.
^ permalink raw reply
* [PATCH v4 1/6] Documentation: DT: Consolidate SP805 binding docs
From: Guenter Roeck @ 2018-06-06 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605194124.GA26885@rob-hp-laptop>
On 06/05/2018 12:41 PM, Rob Herring wrote:
> On Mon, May 28, 2018 at 11:01:32AM -0700, Ray Jui wrote:
>> Consolidate two SP805 binding documents "arm,sp805.txt" and
>> "sp805-wdt.txt" into "arm,sp805.txt" that matches the naming of the
>> desired compatible string to be used
>>
>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>> ---
>> .../devicetree/bindings/watchdog/arm,sp805.txt | 27 ++++++++++++++-----
>> .../devicetree/bindings/watchdog/sp805-wdt.txt | 31 ----------------------
>> 2 files changed, 20 insertions(+), 38 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>
> Would be good to get a ACK from FSL/NXP person on this. It looks to me
> like the driver fetches the wrong clock as it gets the first one and the
> driver really wants 'wdog_clk'. In any case, their dts files should be
> updated.
>
This is really confusing, since he deleted file lists apb_pclk first.
Does the watchdog driver need apb_pclk or wdog_clk ? That isn't clear to me.
arch/arm64/boot/dts/hisilicon/hi3660.dtsi only provides apb_pclk, or at least
it says so. The fsl dts files all have apb_pclk first.
Either case, why are two clocks asked for in the first place ? Are there
situations where the second clock is actually used/useful ?
Guenter
> Reviewed-by: Rob Herring <robh@kernel.org>
>
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v4 1/6] Documentation: DT: Consolidate SP805 binding docs
From: Rob Herring @ 2018-06-06 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e91c75f3-f7a4-6f51-9911-7e22d5d05084@roeck-us.net>
On Wed, Jun 6, 2018 at 11:19 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> On 06/05/2018 12:41 PM, Rob Herring wrote:
>>
>> On Mon, May 28, 2018 at 11:01:32AM -0700, Ray Jui wrote:
>>>
>>> Consolidate two SP805 binding documents "arm,sp805.txt" and
>>> "sp805-wdt.txt" into "arm,sp805.txt" that matches the naming of the
>>> desired compatible string to be used
>>>
>>> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
>>> ---
>>> .../devicetree/bindings/watchdog/arm,sp805.txt | 27
>>> ++++++++++++++-----
>>> .../devicetree/bindings/watchdog/sp805-wdt.txt | 31
>>> ----------------------
>>> 2 files changed, 20 insertions(+), 38 deletions(-)
>>> delete mode 100644
>>> Documentation/devicetree/bindings/watchdog/sp805-wdt.txt
>>
>>
>> Would be good to get a ACK from FSL/NXP person on this. It looks to me
>> like the driver fetches the wrong clock as it gets the first one and the
>> driver really wants 'wdog_clk'. In any case, their dts files should be
>> updated.
>>
>
> This is really confusing, since he deleted file lists apb_pclk first.
> Does the watchdog driver need apb_pclk or wdog_clk ? That isn't clear to me.
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi only provides apb_pclk, or at
> least
> it says so.
Note that that clock source is 32KHz. That is obviously a mistake
because no one clocks their bus/register interface at 32KHz. Someone
just filled in something that happened to work.
> The fsl dts files all have apb_pclk first.
It's all kind of a mess, but fortunately one we should be able to clean-up.
The compatible string changes too, but AMBA bus devices don't actually
use the compatible string as they use the ID registers to match. I
suppose some other OS could do things differently. Worth the risk to
clean-up IMO.
>
> Either case, why are two clocks asked for in the first place ? Are there
> situations where the second clock is actually used/useful ?
For clocks, the bus needs "apb_pclk" and the driver just gets the
first clock. The driver is obviously going to want the functional
clock that determines the counter rate. That should
Primecell peripherals are about the only ones that have clear specs
WRT clock inputs. Yet we've still managed to screw them up. There are
2 clocks in the spec, so the DT has (or should have) 2 clocks.
Rob
^ permalink raw reply
* [PATCH v2] arm64: topology: Avoid checking numa mask for scheduler MC selection
From: Jeremy Linton @ 2018-06-06 16:38 UTC (permalink / raw)
To: linux-arm-kernel
The numa mask subset check can often lead to system hang or crash during
CPU hotplug and system suspend operation if NUMA is disabled. This is
mostly observed on HMP systems where the CPU compute capacities are
different and ends up in different scheduler domains. Since
cpumask_of_node is returned instead core_sibling, the scheduler is
confused with incorrect cpumasks(e.g. one CPU in two different sched
domains at the same time) on CPU hotplug.
Lets disable the NUMA siblings checks for the time being, as NUMA in
socket machines have LLC's that will assure that the scheduler topology
isn't "borken".
The NUMA check exists to assure that if a LLC within a socket crosses
NUMA nodes/chiplets the scheduler domains remain consistent. This code will
likely have to be re-enabled in the near future once the NUMA mask story
is sorted. At the moment its not necessary because the NUMA in socket
machines LLC's are contained within the NUMA domains.
Further, as a defensive mechanism during hot-plug, lets assure that the
LLC siblings are also masked.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/arm64/kernel/topology.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..f845a8617812 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -215,13 +215,8 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+ const cpumask_t *core_mask = &cpu_topology[cpu].core_sibling;
- /* Find the smaller of NUMA, core or LLC siblings */
- if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
- /* not numa in package, lets use the package siblings */
- core_mask = &cpu_topology[cpu].core_sibling;
- }
if (cpu_topology[cpu].llc_id != -1) {
if (cpumask_subset(&cpu_topology[cpu].llc_siblings, core_mask))
core_mask = &cpu_topology[cpu].llc_siblings;
@@ -239,8 +234,10 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
- if (cpuid_topo->llc_id == cpu_topo->llc_id)
+ if (cpuid_topo->llc_id == cpu_topo->llc_id) {
cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
+ cpumask_set_cpu(cpuid, &cpu_topo->llc_siblings);
+ }
if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
--
2.14.3
^ permalink raw reply related
* [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Florian Fainelli @ 2018-06-06 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c8836130-1d96-b813-4e87-5011db679ba8@broadcom.com>
On 06/06/2018 09:03 AM, Scott Branden wrote:
> Hi Clement,
>
>
> On 18-06-06 02:34 AM, Cl?ment P?ron wrote:
>> From: Cl?ment Peron <clement.peron@devialet.com>
>>
>> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>>
>> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> Thanks for upstreaming some missing Cygnus components.
>
> But, the problem is the tarball release from Broadcom you are extracting
> these changes from does not contain git history; so, you are missing the
> original authors and signed-off's.
> I checked our internal git repository and for this commit the author is:
> Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>
> Please adjust author and signed-off appropriately.? If there are other
> changes you are extracting from the source tarballs you have please
> contact me so we can construct patch appropriately.
If you want the original author's Signed-off-by to be preserved, why
don't you extract it from your internal git tree and submit the patch on
Mohamed's behalf?
AFAICT what Clement is doing here is permissible given the Linux
developer certificate of origin though I am not a lawyer of course.
--
Florian
^ permalink raw reply
* [PATCH v2 3/5] arm_pmu: Add support for 64bit event counters
From: Mark Rutland @ 2018-06-06 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527591356-10934-4-git-send-email-suzuki.poulose@arm.com>
On Tue, May 29, 2018 at 11:55:54AM +0100, Suzuki K Poulose wrote:
> Each PMU has a set of 32bit event counters. But in some
> special cases, the events could be counted using counters
> which are effectively 64bit wide.
>
> e.g, Arm V8 PMUv3 has a 64 bit cycle counter which can count
> only the CPU cycles. Also, the PMU can chain the event counters
> to effectively count as a 64bit counter.
>
> Add support for tracking the events that uses 64bit counters.
> This only affects the periods set for each counter in the core
> driver.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> Changes since v1:
> - Rename ARMPMU_EVT_LONG => ARMPMU_EVT_64BIT
> ---
> drivers/perf/arm_pmu.c | 14 ++++++++------
> include/linux/perf/arm_pmu.h | 6 ++++++
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> index 8962d26..ff858e6 100644
> --- a/drivers/perf/arm_pmu.c
> +++ b/drivers/perf/arm_pmu.c
> @@ -28,9 +28,10 @@
> static DEFINE_PER_CPU(struct arm_pmu *, cpu_armpmu);
> static DEFINE_PER_CPU(int, cpu_irq);
>
> -static inline u64 arm_pmu_max_period(void)
> +static inline u64 arm_pmu_event_max_period(struct perf_event *event)
> {
> - return (1ULL << 32) - 1;
> + return (event->hw.flags & ARMPMU_EVT_64BIT) ?
> + ~0ULL : (1ULL << 32) - 1;
> }
Could we please have:
static inline u64 arm_pmu_event_max_period(struct perf_event *event)
{
if (event->hw.flags & ARMPMU_EVT_64BIT)
return GENMASK_ULL(63, 0);
else
return GENMASK_ULL(31, 0);
}
... since that's obviously balanced, with both values generated in the
same way.
Otherwise this looks good to me.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 0/5] Add R8A77970/V3MSK LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-06 16:51 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180604-v4.17-rc7' tag. We're adding the R8A77980 FCPVD/VSPD/
DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
connected to the LVDS output. These patches depend on the Thine THC63LVD1024
driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO
DT patches in order to apply/compile...
[1/5] arm64: dts: renesas: r8a77980: add FCPVD support
[2/5] arm64: dts: renesas: r8a77980: add VSPD support
[3/5] arm64: dts: renesas: r8a77980: add DU support
[4/5] arm64: dts: renesas: r8a77980: add LVDS support
[5/5] arm64: dts: renesas: condor: add DU/LVDS/HDMI support
WBR, Sergei
^ permalink raw reply
* [PATCH 0/5] Add R8A77980/Condor LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-06 16:53 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
Reposting with the correct subject... Sorry! :-]
Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20180604-v4.17-rc7' tag. We're adding the R8A77980 FCPVD/VSPD/
DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
connected to the LVDS output. These patches depend on the Thine THC63LVD1024
driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO
DT patches in order to apply/compile...
[1/5] arm64: dts: renesas: r8a77980: add FCPVD support
[2/5] arm64: dts: renesas: r8a77980: add VSPD support
[3/5] arm64: dts: renesas: r8a77980: add DU support
[4/5] arm64: dts: renesas: r8a77980: add LVDS support
[5/5] arm64: dts: renesas: condor: add DU/LVDS/HDMI support
WBR, Sergei
^ permalink raw reply
* [PATCH 1/5] arm64: dts: renesas: r8a77980: add FCPVD support
From: Sergei Shtylyov @ 2018-06-06 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Describe FCPVD0 in the R8A77980 device tree; it will be used by VSPD0 in
the next patch...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,14 @@
resets = <&cpg 408>;
};
+ fcpvd0: fcp at fea27000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea27000 0 0x200>;
+ clocks = <&cpg CPG_MOD 603>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 603>;
+ };
+
prr: chipid at fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [PATCH 2/5] arm64: dts: renesas: r8a77980: add VSPD support
From: Sergei Shtylyov @ 2018-06-06 16:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Describe VSPD0 in the R8A77980 device tree; it will be used by DU in
the next patch...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,16 @@
resets = <&cpg 408>;
};
+ vspd0: vsp at fea20000 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea20000 0 0x4000>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 623>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 623>;
+ renesas,fcp = <&fcpvd0>;
+ };
+
fcpvd0: fcp at fea27000 {
compatible = "renesas,fcpv";
reg = <0 0xfea27000 0 0x200>;
^ permalink raw reply
* [PATCH 3/5] arm64: dts: renesas: r8a77980: add DU support
From: Sergei Shtylyov @ 2018-06-06 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Define the generic R8A77980 part of the DU device node.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -671,6 +671,36 @@
resets = <&cpg 603>;
};
+ du: display at feb00000 {
+ compatible = "renesas,du-r8a77980",
+ "renesas,du-r8a77970";
+ reg = <0 0xfeb00000 0 0x80000>;
+ interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 724>;
+ clock-names = "du.0";
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 724>;
+ vsps = <&vspd0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ du_out_lvds0: endpoint {
+ };
+ };
+ };
+ };
+
prr: chipid at fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [PATCH 4/5] arm64: dts: renesas: r8a77980: add LVDS support
From: Sergei Shtylyov @ 2018-06-06 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Define the generic R8A77980 part of the LVDS device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -696,6 +696,35 @@
port at 1 {
reg = <1>;
du_out_lvds0: endpoint {
+ remote-endpoint = <&lvds0_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds-encoder at feb90000 {
+ compatible = "renesas,r8a77980-lvds";
+ reg = <0 0xfeb90000 0 0x14>;
+ clocks = <&cpg CPG_MOD 727>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 727>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint =
+ <&du_out_lvds0>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ lvds0_out: endpoint {
};
};
};
^ permalink raw reply
* [PATCH 5/5] arm64: dts: renesas: condor: add DU/LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-06 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4fbd0895-c1ec-41fc-912d-8306dd933997@cogentembedded.com>
Define the Condor board dependent part of the DU and LVDS device nodes.
Also add the device nodes for Thine THC63LVD1024 LVDS decoder and Analog
Devices ADV7511W HDMI transmitter...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 106 ++++++++++++++++++++++++
1 file changed, 106 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
@@ -45,6 +45,56 @@
regulator-boot-on;
regulator-always-on;
};
+
+ d1_8v: regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "D1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&d3_3v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ x1_clk: x1-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <148500000>;
+ };
};
&avb {
@@ -74,6 +124,13 @@
};
};
+&du {
+ clocks = <&cpg CPG_MOD 724>,
+ <&x1_clk>;
+ clock-names = "du.0", "dclkin.0";
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <16666666>;
};
@@ -102,6 +159,55 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ hdmi at 39{
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&d1_8v>;
+ dvdd-supply = <&d1_8v>;
+ pvdd-supply = <&d1_8v>;
+ bgvdd-supply = <&d1_8v>;
+ dvdd-3v-supply = <&d3_3v>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
};
&mmc0 {
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Clément Péron @ 2018-06-06 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c7990001-00e6-d828-bafd-3d472fcfee20@gmail.com>
Hi Scott, Florian,
On Wed, 6 Jun 2018 at 18:47, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 06/06/201 8 09:03 AM, Scott Branden wrote:
> > Hi Clement,
> >
> >
> > On 18-06-06 02:34 AM, Cl?ment P?ron wrote:
> >> From: Cl?ment Peron <clement.peron@devialet.com>
> >>
> >> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
> >>
> >> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> > Thanks for upstreaming some missing Cygnus components.
> >
> > But, the problem is the tarball release from Broadcom you are extracting
> > these changes from does not contain git history; so, you are missing the
> > original authors and signed-off's.
> > I checked our internal git repository and for this commit the author is:
> > Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
> >
> > Please adjust author and signed-off appropriately. If there are other
> > changes you are extracting from the source tarballs you have please
> > contact me so we can construct patch appropriately.
>
> If you want the original author's Signed-off-by to be preserved, why
> don't you extract it from your internal git tree and submit the patch on
> Mohamed's behalf?
>
> AFAICT what Clement is doing here is permissible given the Linux
> developer certificate of origin though I am not a lawyer of course.
> --
> Florian
Totally not my goal to steal the author and agree to keep track of the
original author
as soon as it's possible. I didn't though it was important for this
patch as the same
code is available in the dt-bindings documentation.
Actually there are still some buggy components like DSA (Arun proposed
a patch this morning)
the PWM (config and delay aren't correct) and I2C. These are mainlined
but can't be used
and need a minimal effort to correctly work on Cygnus.
Also there are some important components like USB Phy or Mailbox that
were proposed and
almost made it, but just need a small modification to be accepted.
My idea was just to submit small patches that are trivial to review.
In order to avoid keeping
lots of patches in our kernel and also have something functional when
building a mainline kernel.
Regards,
Clement
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: Add HWRNG node
From: Scott Branden @ 2018-06-06 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c7990001-00e6-d828-bafd-3d472fcfee20@gmail.com>
On 18-06-06 09:47 AM, Florian Fainelli wrote:
> On 06/06/2018 09:03 AM, Scott Branden wrote:
>> Hi Clement,
>>
>>
>> On 18-06-06 02:34 AM, Cl?ment P?ron wrote:
>>> From: Cl?ment Peron <clement.peron@devialet.com>
>>>
>>> There is a HWRNG in Broadcom Cygnus SoC, so enable it.
>>>
>>> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
>> Thanks for upstreaming some missing Cygnus components.
>>
>> But, the problem is the tarball release from Broadcom you are extracting
>> these changes from does not contain git history; so, you are missing the
>> original authors and signed-off's.
>> I checked our internal git repository and for this commit the author is:
>> Mohamed Ismail Abdul Packir Mohamed <mohamed-ismail.abdul@broadcom.com>
>>
>> Please adjust author and signed-off appropriately.? If there are other
>> changes you are extracting from the source tarballs you have please
>> contact me so we can construct patch appropriately.
> If you want the original author's Signed-off-by to be preserved, why
> don't you extract it from your internal git tree and submit the patch on
> Mohamed's behalf?
Sure, I can submit the original patch to keep things simple and avoid
finding a lawyer right now.
>
> AFAICT what Clement is doing here is permissible given the Linux
> developer certificate of origin though I am not a lawyer of course.
But, It would be great to get some guidance and clarification on this
for sure.
I'm reading:
https://www.kernel.org/doc/html/v4.16/process/submitting-patches.html
The change was created entirely by Broadcom, so seems difficult for
somebody else to upstream change without appropriate authorship and
signed off from copyright holder.? Point a) and b) are not met in
Developer's Certificate of Origin while point c) is being attempted
(without a or b being certified).
^ permalink raw reply
* [PATCH v2] arm64: topology: Avoid checking numa mask for scheduler MC selection
From: Catalin Marinas @ 2018-06-06 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606163846.495725-1-jeremy.linton@arm.com>
On Wed, Jun 06, 2018 at 11:38:46AM -0500, Jeremy Linton wrote:
> The numa mask subset check can often lead to system hang or crash during
> CPU hotplug and system suspend operation if NUMA is disabled. This is
> mostly observed on HMP systems where the CPU compute capacities are
> different and ends up in different scheduler domains. Since
> cpumask_of_node is returned instead core_sibling, the scheduler is
> confused with incorrect cpumasks(e.g. one CPU in two different sched
> domains at the same time) on CPU hotplug.
>
> Lets disable the NUMA siblings checks for the time being, as NUMA in
> socket machines have LLC's that will assure that the scheduler topology
> isn't "borken".
>
> The NUMA check exists to assure that if a LLC within a socket crosses
> NUMA nodes/chiplets the scheduler domains remain consistent. This code will
> likely have to be re-enabled in the near future once the NUMA mask story
> is sorted. At the moment its not necessary because the NUMA in socket
> machines LLC's are contained within the NUMA domains.
>
> Further, as a defensive mechanism during hot-plug, lets assure that the
> LLC siblings are also masked.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Thanks for this. I queued it for this merging window.
--
Catalin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox