* [PATCH v3 3/5] arm64: mm: set the contiguous bit for kernel mappings where appropriate
From: Catalin Marinas @ 2016-10-13 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476271425-19401-4-git-send-email-ard.biesheuvel@linaro.org>
On Wed, Oct 12, 2016 at 12:23:43PM +0100, Ard Biesheuvel wrote:
> Now that we no longer allow live kernel PMDs to be split, it is safe to
> start using the contiguous bit for kernel mappings. So set the contiguous
> bit in the kernel page mappings for regions whose size and alignment are
> suitable for this.
>
> This enables the following contiguous range sizes for the virtual mapping
> of the kernel image, and for the linear mapping:
>
> granule size | cont PTE | cont PMD |
> -------------+------------+------------+
> 4 KB | 64 KB | 32 MB |
> 16 KB | 2 MB | 1 GB* |
> 64 KB | 2 MB | 16 GB* |
>
> * only when built for 3 or more levels of translation
I assume the limitation to have contiguous PMD only with 3 or move
levels is because of the way p*d folding was implemented in the kernel.
With nopmd, looping over pmds is done in __create_pgd_mapping() rather
than alloc_init_pmd().
A potential solution would be to replicate the contiguous pmd code to
the pud and pgd level, though we probably won't benefit from any
contiguous entries at higher level (when more than 2 levels).
Alternatively, with an #ifdef __PGTABLE_PMD_FOLDED, we could set the
PMD_CONT in prot in __create_pgd_mapping() directly (if the right
addr/phys alignment).
Anyway, it's probably not worth the effort given that 42-bit VA with 64K
pages is becoming a less likely configuration (36-bit VA with 16K pages
is even less likely, also depending on EXPERT).
--
Catalin
^ permalink raw reply
* [PATCH] perf: xgene: Remove bogus IS_ERR() check
From: Tai Tri Nguyen @ 2016-10-13 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013102939.GA22356@remoulade>
Hi Mark,
On Thu, Oct 13, 2016 at 3:29 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Oct 12, 2016 at 09:39:27AM -0700, Tai Nguyen wrote:
>> This patch fixes the warning issue with static checker.
>> The bug is reported in [1]
>>
>> [1] https://www.spinics.net/lists/arm-kernel/msg535957.html
>>
>> Signed-off-by: Tai Nguyen <ttnguyen@apm.com>
>
> Please put the problem description in the commit message:
>
> In acpi_get_pmu_hw_inf we pass the address of a local variable to IS_ERR(),
> which doesn't make sense, as the pointer must be a real, valid pointer. This
> doesn't cause a functional problem, as IS_ERR() will evaluate as false, but
> the check is bogus and causes static checkers to complain.
>
> Remove the bogus check.
>
> Please also add a Reported-by for Dan.
>
> The patch itself is fine, so with the above, you can add:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>
> Please Cc Will Deacon when sending that, I expect that he will pick it up
> (though perhaps not until rc1 given this is not a critical issue).
>
Thanks. I'll send the updated patch shortly.
Regards,
Tai
[...]
>> ---
>> drivers/perf/xgene_pmu.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
>> index c2ac764..a8ac4bc 100644
>> --- a/drivers/perf/xgene_pmu.c
>> +++ b/drivers/perf/xgene_pmu.c
>> @@ -1011,7 +1011,7 @@ xgene_pmu_dev_ctx *acpi_get_pmu_hw_inf(struct xgene_pmu *xgene_pmu,
>> rc = acpi_dev_get_resources(adev, &resource_list,
>> acpi_pmu_dev_add_resource, &res);
>> acpi_dev_free_resource_list(&resource_list);
>> - if (rc < 0 || IS_ERR(&res)) {
>> + if (rc < 0) {
>> dev_err(dev, "PMU type %d: No resource address found\n", type);
>> goto err;
>> }
>> --
>> 1.9.1
>>
--
Tai
^ permalink raw reply
* [PATCH 2/2] power/reset: at91-poweroff: timely shitdown LPDDR memories
From: Jean-Jacques Hiblot @ 2016-10-13 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013134710.rbvsiyu6ala673g4@piout.net>
2016-10-13 15:47 GMT+02:00 Alexandre Belloni
<alexandre.belloni@free-electrons.com>:
> On 13/10/2016 at 14:27:15 +0200, Jean-Jacques Hiblot wrote :
>> 2016-10-13 13:03 GMT+02:00 Alexandre Belloni
>> <alexandre.belloni@free-electrons.com>:
>> > On 12/10/2016 at 14:48:27 +0200, Jean-Jacques Hiblot wrote :
>> >> > +static void at91_lpddr_poweroff(void)
>> >> > +{
>> >> > + asm volatile(
>> >> > + /* Align to cache lines */
>> >> > + ".balign 32\n\t"
>> >> > +
>> >> > + " ldr r6, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
>> >> At first sight, it looks useless. I assume it's used to preload the
>> >> TLB before the LPDDR is turned off.
>> >> A comment to explain why this line is useful would prevent its removal.
>> >
>> > Yes, this is the case. I can add a comment.
>> >
>> > Anyway, I would prefer the whole thing to run from SRAM, as a PIE
>> > instead of relying on the cache.
>>
>> Instead of copying into the SRAM, you can make the cache reliable by
>> preloading it, much like the TLB.
>> LDI is probably not available for most of atmel's SOC, so the only way
>> I can think of, is to execute code from the targeted area. here is an
>> example:
>> + /*
>> + * Jump to the end of the sequence to preload instruction cache
>> + * It only works because the sequence is short enough not to
>> + * sit accross more than 2 cache lines
>> + */
>> + " b end_of_sequence\n\t"
>> + "start_of_sequence:\n\t"
>> +
>> /* Power down SDRAM0 */
>> " str %1, [%0, #"
>> __stringify(AT91_DDRSDRC_LPR) "]\n\t"
>> /* Shutdown CPU */
>> " str %3, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
>>
>> " b .\n\t"
>> +
>> + /*
>> + * we're now 100% sure that the code to shutdown the LPDDR and
>> + * the CPU is in cache, go back to do the actual job
>> + */
>> + "end_of_sequence:\n\t"
>> + " b start_of_sequence\n\t"
>> :
>>
>
> I don't think this is necessary. By aligning the instructions properly,
> we are already sure the whole code is loaded into the cache.
right I didn't see the align directive.
>
> My plan is to get rid of the assembly and use PIE so it is written in C
> and we can properly separate the RAM stuff in the ddrc driver.
>
> The mpddrc driver could load its shutdown function in SRAM. The reset
> controller driver would load the reset function in SRAM and the shutdown
> controller would load the poweroff function in SRAM. It would e quite
> cleaner than what we have here.
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH v3 1/5] arm64: mm: BUG on unsupported manipulations of live kernel mappings
From: Ard Biesheuvel @ 2016-10-13 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013144450.GG21592@e104818-lin.cambridge.arm.com>
On 13 October 2016 at 15:44, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Thu, Oct 13, 2016 at 01:25:53PM +0100, Ard Biesheuvel wrote:
>
> (fixing up alignment to make it readable)
>
I apologise on Gmail's behalf
>> """
>> /*
>> * Returns whether updating a live page table entry is safe:
>> * - if the old and new values are identical,
>> * - if an invalid mapping is turned into a valid one (or vice versa),
>> * - if the entry is a block or page mapping, and the old and new values
>> * only differ in the PXN/RDONLY/WRITE bits.
>> *
>> * NOTE: 'safe' does not imply that no TLB maintenance is required, it only
>> * means that no TLB conflicts should occur as a result of the update.
>> */
>> #define __set_pgattr_is_safe(type, old, new, blocktype) \
>> (type ## _val(old) == type ## _val(new) || \
>> ((type ## _val(old) ^ type ## _val(new)) & PTE_VALID) != 0 || \
>> (((type ## _val(old) & PTE_TYPE_MASK) == blocktype) && \
>> (((type ## _val(old) ^ type ## _val(new)) & \
>> ~(PTE_PXN | PTE_RDONLY | PTE_WRITE)) == 0)))
>>
>> static inline bool set_live_pte_is_safe(pte_t old, pte_t new)
>> {
>> return __set_pgattr_is_safe(pte, old, new, PTE_TYPE_PAGE);
>> }
>>
>> static inline bool set_live_pmd_is_safe(pmd_t old, pmd_t new)
>> {
>> return __set_pgattr_is_safe(pmd, old, new, PMD_TYPE_SECT);
>> }
>>
>> static inline bool set_live_pud_is_safe(pud_t old, pud_t new)
>> {
>> return __set_pgattr_is_safe(pud, old, new, PUD_TYPE_SECT);
>> }
>
> The set_ prefix is slightly confusing as it suggests (to me) having a
> side effect. Maybe pgattr_set_is_safe()?
>
> But it looks like we make it more complicated needed by using pte_t
> instead of pteval_t as argument. How about just using the pteval_t as
> argument (and it's fine to call it with pmdval_t, pudval_t as well):
>
> #define pgattr_set_is_safe(oldval, newval) \
> ...
>
Well, the only problem there is that the permission bit check should
only apply to level 3 page mappings (bit[1] == 1) and level 1/2 block
mappings (bit[1] == 0), so we would still need two versions
^ permalink raw reply
* [PATCH v3 1/5] arm64: mm: BUG on unsupported manipulations of live kernel mappings
From: Catalin Marinas @ 2016-10-13 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8p06DBaDgmJ3KSSfNVDox=wOTav48kti+Y0gYtQhEC_g@mail.gmail.com>
On Thu, Oct 13, 2016 at 01:25:53PM +0100, Ard Biesheuvel wrote:
> On 12 October 2016 at 16:04, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Wed, Oct 12, 2016 at 12:23:41PM +0100, Ard Biesheuvel wrote:
> >> +/*
> >> + * The following mapping attributes may be updated in live
> >> + * kernel mappings without the need for break-before-make.
> >> + */
> >> +static const pteval_t modifiable_attr_mask = PTE_PXN | PTE_RDONLY | PTE_WRITE;
> >> +
> >> static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
> >> unsigned long end, unsigned long pfn,
> >> pgprot_t prot,
> >> @@ -115,8 +119,18 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
> >>
> >> pte = pte_set_fixmap_offset(pmd, addr);
> >> do {
> >> + pte_t old_pte = *pte;
> >> +
> >> set_pte(pte, pfn_pte(pfn, prot));
> >> pfn++;
> >> +
> >> + /*
> >> + * After the PTE entry has been populated once, we
> >> + * only allow updates to the permission attributes.
> >> + */
> >> + BUG_ON(pte_val(old_pte) != 0 &&
> >> + ((pte_val(old_pte) ^ pte_val(*pte)) &
> >> + ~modifiable_attr_mask) != 0);
> >
> > Please turn this check into a single macro. You have it in three places
> > already (though with different types but a macro would do). Something
> > like below (feel free to come up with a better macro name):
> >
> > BUG_ON(!safe_pgattr_change(old_pte, *pte));
>
> Something like below? With that, I can also fold the PMD and PUD
> versions of the BUG() together.
(fixing up alignment to make it readable)
> """
> /*
> * Returns whether updating a live page table entry is safe:
> * - if the old and new values are identical,
> * - if an invalid mapping is turned into a valid one (or vice versa),
> * - if the entry is a block or page mapping, and the old and new values
> * only differ in the PXN/RDONLY/WRITE bits.
> *
> * NOTE: 'safe' does not imply that no TLB maintenance is required, it only
> * means that no TLB conflicts should occur as a result of the update.
> */
> #define __set_pgattr_is_safe(type, old, new, blocktype) \
> (type ## _val(old) == type ## _val(new) || \
> ((type ## _val(old) ^ type ## _val(new)) & PTE_VALID) != 0 || \
> (((type ## _val(old) & PTE_TYPE_MASK) == blocktype) && \
> (((type ## _val(old) ^ type ## _val(new)) & \
> ~(PTE_PXN | PTE_RDONLY | PTE_WRITE)) == 0)))
>
> static inline bool set_live_pte_is_safe(pte_t old, pte_t new)
> {
> return __set_pgattr_is_safe(pte, old, new, PTE_TYPE_PAGE);
> }
>
> static inline bool set_live_pmd_is_safe(pmd_t old, pmd_t new)
> {
> return __set_pgattr_is_safe(pmd, old, new, PMD_TYPE_SECT);
> }
>
> static inline bool set_live_pud_is_safe(pud_t old, pud_t new)
> {
> return __set_pgattr_is_safe(pud, old, new, PUD_TYPE_SECT);
> }
The set_ prefix is slightly confusing as it suggests (to me) having a
side effect. Maybe pgattr_set_is_safe()?
But it looks like we make it more complicated needed by using pte_t
instead of pteval_t as argument. How about just using the pteval_t as
argument (and it's fine to call it with pmdval_t, pudval_t as well):
#define pgattr_set_is_safe(oldval, newval) \
...
--
Catalin
^ permalink raw reply
* [PATCH 3/4] arm64: Allow hw watchpoint of length 3,5,6 and 7
From: Pavel Labath @ 2016-10-13 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1bc0dce6-eb26-dbf5-dd0c-d36055f5f1fe@redhat.com>
On 13 October 2016 at 11:22, Pratyush Anand <panand@redhat.com> wrote:
>
>
> On Wednesday 12 October 2016 04:46 PM, Yao Qi wrote:
>>
>> On Wed, Oct 12, 2016 at 6:58 AM, Pratyush Anand <panand@redhat.com> wrote:
>>>
>>> Since, arm64 can support all offset within a double word limit.
>>> Therefore,
>>> now support other lengths within that range as well.
>>
>>
>> How does ptracer (like GDB) detect kernel has already supported all byte
>> address select values? I suppose ptrace(NT_ARM_HW_WATCH, ) with
>> len is 3 or 5 fail on current kernel but is of success after your patches
>> applied.
>>
>
> Thanks for testing these patches.
>
> I do not know if we can know that other than the failure of
> ptrace(PTRACE_SETREGSET, .., NT_ARM_HW_WATCH, ..). I do not see any such
> option in `man ptrace`.
That's how I intend to implement support for this in LLDB.
if (setExactWatchpoint())
return true; // watchpoint set, new kernel
if (setApproxWatchpoint())
return true; // watchpoint set, old kernel
return false; // watchpoints not working
seems straight-forward enough to me.
^ permalink raw reply
* [PATCH V3 05/10] acpi: apei: handle SEA notification type for ARMv8
From: Baicar, Tyler @ 2016-10-13 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87shs1sb1b.fsf@e105922-lin.cambridge.arm.com>
Hello Punit,
On 10/12/2016 12:00 PM, Punit Agrawal wrote:
> Tyler Baicar <tbaicar@codeaurora.org> writes:
>
>> ARM APEI extension proposal added SEA (Synchrounous External
>> Abort) notification type for ARMv8.
>> Add a new GHES error source handling function for SEA. If an error
>> source's notification type is SEA, then this function can be registered
>> into the SEA exception handler. That way GHES will parse and report
>> SEA exceptions when they occur.
>>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
> This patch fails to apply for me on v4.8. Is there a different tree this
> is based on?
This patch was giving me some grief as well. I'm not sure why that is
because this patchset was based on the 4.8 kernel with the dependent
patch for initial APEI support.
> One comment below.
>
> [...]
>
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index c8488f1..28d5a09 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -50,6 +50,10 @@
>> #include <acpi/apei.h>
>> #include <asm/tlbflush.h>
>>
>> +#ifdef CONFIG_HAVE_ACPI_APEI_SEA
>> +#include <asm/system_misc.h>
>> +#endif
>> +
>> #include "apei-internal.h"
>>
>> #define GHES_PFX "GHES: "
>> @@ -779,6 +783,62 @@ static struct notifier_block ghes_notifier_sci = {
>> .notifier_call = ghes_notify_sci,
>> };
>>
>> +#ifdef CONFIG_HAVE_ACPI_APEI_SEA
>> +static LIST_HEAD(ghes_sea);
>> +
>> +static int ghes_notify_sea(struct notifier_block *this,
>> + unsigned long event, void *data)
>> +{
>> + struct ghes *ghes;
>> + int ret = NOTIFY_DONE;
>> +
>> + rcu_read_lock();
>> + list_for_each_entry_rcu(ghes, &ghes_sea, list) {
>> + if (!ghes_proc(ghes))
>> + ret = NOTIFY_OK;
> Not something you've introduced but it looks like ghes_proc erroneously
> never returns anything other than 0. I plan to post the below fix to
> address it.
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 60746ef..caea575 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -662,7 +662,7 @@ static int ghes_proc(struct ghes *ghes)
> ghes_do_proc(ghes, ghes->estatus);
> out:
> ghes_clear_estatus(ghes);
> - return 0;
> + return rc;
> }
Yes, this definitely should be fixed :)
Thanks,
Tyler
>> + }
>> + rcu_read_unlock();
>> +
>> + return ret;
>> +}
>> +
> [...]
>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V3 04/10] arm64: exception: handle Synchronous External Abort
From: Baicar, Tyler @ 2016-10-13 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y41tsboh.fsf@e105922-lin.cambridge.arm.com>
Hello Punit,
On 10/12/2016 11:46 AM, Punit Agrawal wrote:
> Hi Tyler,
>
> A couple of hopefully not bike shedding comments below.
>
> Tyler Baicar <tbaicar@codeaurora.org> writes:
>
>> SEA exceptions are often caused by an uncorrected hardware
>> error, and are handled when data abort and instruction abort
>> exception classes have specific values for their Fault Status
>> Code.
>> When SEA occurs, before killing the process, go through
>> the handlers registered in the notification list.
>> Update fault_info[] with specific SEA faults so that the
>> new SEA handler is used.
>>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
>> ---
>> arch/arm64/include/asm/system_misc.h | 13 ++++++++
>> arch/arm64/mm/fault.c | 58 +++++++++++++++++++++++++++++-------
>> 2 files changed, 61 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
>> index 57f110b..90daf4a 100644
>> --- a/arch/arm64/include/asm/system_misc.h
>> +++ b/arch/arm64/include/asm/system_misc.h
>> @@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
>>
>> #endif /* __ASSEMBLY__ */
>>
>> +/*
>> + * The functions below are used to register and unregister callbacks
>> + * that are to be invoked when a Synchronous External Abort (SEA)
>> + * occurs. An SEA is raised by certain fault status codes that have
>> + * either data or instruction abort as the exception class, and
>> + * callbacks may be registered to parse or handle such hardware errors.
>> + *
>> + * Registered callbacks are run in an interrupt/atomic context. They
>> + * are not allowed to block or sleep.
>> + */
>> +int sea_register_handler_chain(struct notifier_block *nb);
>> +void sea_unregister_handler_chain(struct notifier_block *nb);
>> +
>> #endif /* __ASM_SYSTEM_MISC_H */
>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
>> index 05d2bd7..81cb7ad 100644
>> --- a/arch/arm64/mm/fault.c
>> +++ b/arch/arm64/mm/fault.c
>> @@ -39,6 +39,22 @@
>> #include <asm/pgtable.h>
>> #include <asm/tlbflush.h>
>>
>> +/*
>> + * GHES SEA handler code may register a notifier call here to
>> + * handle HW error record passed from platform.
>> + */
>> +static ATOMIC_NOTIFIER_HEAD(sea_handler_chain);
>> +
>> +int sea_register_handler_chain(struct notifier_block *nb)
>> +{
>> + return atomic_notifier_chain_register(&sea_handler_chain, nb);
>> +}
>> +
>> +void sea_unregister_handler_chain(struct notifier_block *nb)
>> +{
>> + atomic_notifier_chain_unregister(&sea_handler_chain, nb);
>> +}
>> +
> What do you think of naming the above functions as
> [un]register_synchonous_ext_abort_notifier?
>
> For an API, I find "sea" doesn't quite convey the message.
>
> One more comment below.
Yes, those names seem easier to understand.
>> static const char *fault_name(unsigned int esr);
>>
>> #ifdef CONFIG_KPROBES
>> @@ -480,6 +496,28 @@ static int do_bad(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>> return 1;
>> }
>>
>> +/*
>> + * This abort handler deals with Synchronous External Abort.
>> + * It calls notifiers, and then returns "fault".
>> + */
>> +static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
>> +{
>> + struct siginfo info;
>> +
>> + atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
>> +
>> + pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
>> + fault_name(esr), esr, addr);
>> +
>> + info.si_signo = SIGBUS;
>> + info.si_errno = 0;
>> + info.si_code = 0;
>> + info.si_addr = (void __user *)addr;
>> + arm64_notify_die("", regs, &info, esr);
>> +
>> + return 0;
>> +}
>> +
>> static const struct fault_info {
>> int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
>> int sig;
>> @@ -502,22 +540,22 @@ static const struct fault_info {
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
>> - { do_bad, SIGBUS, 0, "synchronous external abort" },
>> + { do_sea, SIGBUS, 0, "synchronous external abort" },
>> { do_bad, SIGBUS, 0, "unknown 17" },
>> { do_bad, SIGBUS, 0, "unknown 18" },
>> { do_bad, SIGBUS, 0, "unknown 19" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous parity error" },
>> + { do_sea, SIGBUS, 0, "level 0 SEA (trans tbl walk)" },
>> + { do_sea, SIGBUS, 0, "level 1 SEA (trans tbl walk)" },
>> + { do_sea, SIGBUS, 0, "level 2 SEA (trans tbl walk)" },
>> + { do_sea, SIGBUS, 0, "level 3 SEA (trans tbl walk)" },
> ^^^
> The comment about naming applies here as well.
>
> Thanks,
> Punit
I'll expand sea here as well. This should make it easier to understand
without knowing the code.
Thanks,
Tyler
>
> [...]
>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V3 01/10] acpi: apei: read ack upon ghes record consumption
From: Baicar, Tyler @ 2016-10-13 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8760oxtw42.fsf@e105922-lin.cambridge.arm.com>
Hello Punit,
Thank you for the feedback! Responses below
On 10/12/2016 9:39 AM, Punit Agrawal wrote:
> Hi Tyler,
>
> A few comments below.
>
> Tyler Baicar <tbaicar@codeaurora.org> writes:
>
>> A RAS (Reliability, Availability, Serviceability) controller
>> may be a separate processor running in parallel with OS
>> execution, and may generate error records for consumption by
>> the OS. If the RAS controller produces multiple error records,
>> then they may be overwritten before the OS has consumed them.
>>
>> The Generic Hardware Error Source (GHES) v2 structure
>> introduces the capability for the OS to acknowledge the
>> consumption of the error record generated by the RAS
>> controller. A RAS controller supporting GHESv2 shall wait for
>> the acknowledgment before writing a new error record, thus
>> eliminating the race condition.
>>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>> Signed-off-by: Richard Ruigrok <rruigrok@codeaurora.org>
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
>> ---
>> drivers/acpi/apei/ghes.c | 41 +++++++++++++++++++++++++++++++++++++++++
>> drivers/acpi/apei/hest.c | 7 +++++--
>> include/acpi/ghes.h | 1 +
>> 3 files changed, 47 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 60746ef..3021f0e 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -45,6 +45,7 @@
>> #include <linux/aer.h>
>> #include <linux/nmi.h>
>>
>> +#include <acpi/actbl1.h>
>> #include <acpi/ghes.h>
>> #include <acpi/apei.h>
>> #include <asm/tlbflush.h>
>> @@ -244,10 +245,22 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
>> struct ghes *ghes;
>> unsigned int error_block_length;
>> int rc;
>> + struct acpi_hest_header *hest_hdr;
>>
>> ghes = kzalloc(sizeof(*ghes), GFP_KERNEL);
>> if (!ghes)
>> return ERR_PTR(-ENOMEM);
>> +
>> + hest_hdr = (struct acpi_hest_header *)generic;
>> + if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR_V2) {
>> + ghes->generic_v2 = (struct acpi_hest_generic_v2 *)generic;
>> + rc = apei_map_generic_address(
>> + &ghes->generic_v2->read_ack_register);
>> + if (rc)
>> + goto err_unmap;
>> + } else
>> + ghes->generic_v2 = NULL;
> Since you kzalloc ghes, shouldn't ghes->generic_v2 be NULL already?
Yes, the documentation says kzalloc returns memory set to zero, so I
will remove this else statement.
>> +
>> ghes->generic = generic;
>> rc = apei_map_generic_address(&generic->error_status_address);
>> if (rc)
>> @@ -270,6 +283,9 @@ static struct ghes *ghes_new(struct acpi_hest_generic *generic)
>>
>> err_unmap:
>> apei_unmap_generic_address(&generic->error_status_address);
>> + if (ghes->generic_v2)
>> + apei_unmap_generic_address(
>> + &ghes->generic_v2->read_ack_register);
>> err_free:
>> kfree(ghes);
>> return ERR_PTR(rc);
>> @@ -279,6 +295,9 @@ static void ghes_fini(struct ghes *ghes)
>> {
>> kfree(ghes->estatus);
>> apei_unmap_generic_address(&ghes->generic->error_status_address);
>> + if (ghes->generic_v2)
>> + apei_unmap_generic_address(
>> + &ghes->generic_v2->read_ack_register);
>> }
>>
>> static inline int ghes_severity(int severity)
>> @@ -648,6 +667,22 @@ static void ghes_estatus_cache_add(
>> rcu_read_unlock();
>> }
>>
>> +static int ghes_do_read_ack(struct acpi_hest_generic_v2 *generic_v2)
>> +{
>> + int rc;
>> + u64 val = 0;
>> +
>> + rc = apei_read(&val, &generic_v2->read_ack_register);
>> + if (rc)
>> + return rc;
>> + val &= generic_v2->read_ack_preserve <<
>> + generic_v2->read_ack_register.bit_offset;
>> + val |= generic_v2->read_ack_write;
> Reading the spec, it is not clear whether you need the left shift
> above.
>
> Having said that, if you do it for read_ack_preserve, do you also need
> to left shift read_ack_write by read_ack_register.bit_offset?
Good catch, it looks like the read_ack_write should also get this shift.
I'm using a shift of 0 so I didn't catch this in testing :)
>> + rc = apei_write(val, &generic_v2->read_ack_register);
>> +
>> + return rc;
>> +}
>> +
>> static int ghes_proc(struct ghes *ghes)
>> {
>> int rc;
>> @@ -660,6 +695,12 @@ static int ghes_proc(struct ghes *ghes)
>> ghes_estatus_cache_add(ghes->generic, ghes->estatus);
>> }
>> ghes_do_proc(ghes, ghes->estatus);
>> +
>> + if (ghes->generic_v2) {
>> + rc = ghes_do_read_ack(ghes->generic_v2);
>> + if (rc)
>> + return rc;
>> + }
>> out:
>> ghes_clear_estatus(ghes);
>> return 0;
>> diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
>> index 792a0d9..ef725a9 100644
>> --- a/drivers/acpi/apei/hest.c
>> +++ b/drivers/acpi/apei/hest.c
>> @@ -52,6 +52,7 @@ static const int hest_esrc_len_tab[ACPI_HEST_TYPE_RESERVED] = {
>> [ACPI_HEST_TYPE_AER_ENDPOINT] = sizeof(struct acpi_hest_aer),
>> [ACPI_HEST_TYPE_AER_BRIDGE] = sizeof(struct acpi_hest_aer_bridge),
>> [ACPI_HEST_TYPE_GENERIC_ERROR] = sizeof(struct acpi_hest_generic),
>> + [ACPI_HEST_TYPE_GENERIC_ERROR_V2] = sizeof(struct acpi_hest_generic_v2),
>> };
>>
>> static int hest_esrc_len(struct acpi_hest_header *hest_hdr)
>> @@ -146,7 +147,8 @@ static int __init hest_parse_ghes_count(struct acpi_hest_header *hest_hdr, void
>> {
>> int *count = data;
>>
>> - if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR)
>> + if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR ||
>> + hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR_V2)
>> (*count)++;
>> return 0;
>> }
>> @@ -157,7 +159,8 @@ static int __init hest_parse_ghes(struct acpi_hest_header *hest_hdr, void *data)
>> struct ghes_arr *ghes_arr = data;
>> int rc, i;
>>
>> - if (hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR)
>> + if (hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR &&
>> + hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR_V2)
>> return 0;
>>
>> if (!((struct acpi_hest_generic *)hest_hdr)->enabled)
>> diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
>> index 720446c..d0108b6 100644
>> --- a/include/acpi/ghes.h
>> +++ b/include/acpi/ghes.h
>> @@ -14,6 +14,7 @@
>>
>> struct ghes {
>> struct acpi_hest_generic *generic;
>> + struct acpi_hest_generic_v2 *generic_v2;
> You either have a GHES or a GHESv2 structure. Instead of duplication,
> could this be represented as a union?
>
> Thanks,
> Punit
I think that should be doable. I'll make these changes in the next version.
Thanks,
Tyler
>> struct acpi_hest_generic_status *estatus;
>> u64 buffer_paddr;
>> unsigned long flags;
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 2/2] power/reset: at91-poweroff: timely shitdown LPDDR memories
From: Alexandre Belloni @ 2016-10-13 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5PgwXsCoMROO+Vftx8bbhTXP1V-JdZmdwWJ0tgOUW1Axw@mail.gmail.com>
On 13/10/2016 at 14:27:15 +0200, Jean-Jacques Hiblot wrote :
> 2016-10-13 13:03 GMT+02:00 Alexandre Belloni
> <alexandre.belloni@free-electrons.com>:
> > On 12/10/2016 at 14:48:27 +0200, Jean-Jacques Hiblot wrote :
> >> > +static void at91_lpddr_poweroff(void)
> >> > +{
> >> > + asm volatile(
> >> > + /* Align to cache lines */
> >> > + ".balign 32\n\t"
> >> > +
> >> > + " ldr r6, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
> >> At first sight, it looks useless. I assume it's used to preload the
> >> TLB before the LPDDR is turned off.
> >> A comment to explain why this line is useful would prevent its removal.
> >
> > Yes, this is the case. I can add a comment.
> >
> > Anyway, I would prefer the whole thing to run from SRAM, as a PIE
> > instead of relying on the cache.
>
> Instead of copying into the SRAM, you can make the cache reliable by
> preloading it, much like the TLB.
> LDI is probably not available for most of atmel's SOC, so the only way
> I can think of, is to execute code from the targeted area. here is an
> example:
> + /*
> + * Jump to the end of the sequence to preload instruction cache
> + * It only works because the sequence is short enough not to
> + * sit accross more than 2 cache lines
> + */
> + " b end_of_sequence\n\t"
> + "start_of_sequence:\n\t"
> +
> /* Power down SDRAM0 */
> " str %1, [%0, #"
> __stringify(AT91_DDRSDRC_LPR) "]\n\t"
> /* Shutdown CPU */
> " str %3, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
>
> " b .\n\t"
> +
> + /*
> + * we're now 100% sure that the code to shutdown the LPDDR and
> + * the CPU is in cache, go back to do the actual job
> + */
> + "end_of_sequence:\n\t"
> + " b start_of_sequence\n\t"
> :
>
I don't think this is necessary. By aligning the instructions properly,
we are already sure the whole code is loaded into the cache.
My plan is to get rid of the assembly and use PIE so it is written in C
and we can properly separate the RAM stuff in the ddrc driver.
The mpddrc driver could load its shutdown function in SRAM. The reset
controller driver would load the reset function in SRAM and the shutdown
controller would load the poweroff function in SRAM. It would e quite
cleaner than what we have here.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v4 03/10] ARM: sun8i: dt: Add DT bindings documentation for Allwinner sun8i-emac
From: LABBE Corentin @ 2016-10-13 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010151335.GA3111@rob-hp-laptop>
On Mon, Oct 10, 2016 at 10:13:35AM -0500, Rob Herring wrote:
> On Fri, Oct 07, 2016 at 10:25:50AM +0200, Corentin Labbe wrote:
> > This patch adds documentation for Device-Tree bindings for the
> > Allwinner sun8i-emac driver.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > .../bindings/net/allwinner,sun8i-emac.txt | 70 ++++++++++++++++++++++
> > 1 file changed, 70 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
> > new file mode 100644
> > index 0000000..92e4ef3b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
> > @@ -0,0 +1,70 @@
> > +* Allwinner sun8i EMAC ethernet controller
> > +
> > +Required properties:
> > +- compatible: should be one of the following string:
> > + "allwinner,sun8i-a83t-emac"
> > + "allwinner,sun8i-h3-emac"
> > + "allwinner,sun50i-a64-emac"
> > +- reg: address and length of the register for the device.
> > +- syscon: A phandle to the syscon of the SoC
> > +- interrupts: interrupt for the device
> > +- clocks: A phandle to the reference clock for this device
> > +- clock-names: should be "ahb"
> > +- resets: A phandle to the reset control for this device
> > +- reset-names: should be "ahb"
> > +- phy-mode: See ethernet.txt
> > +- phy-handle: See ethernet.txt
> > +- #address-cells: shall be 1
> > +- #size-cells: shall be 0
> > +
> > +Optional properties:
> > +- allwinner,tx-delay: TX clock delay chain value. Range value is 0-0x07. Default is 0)
> > +- allwinner,rx-delay: RX clock delay chain value. Range value is 0-0x1F. Default is 0)
> > +Both delay properties does not have units, there are arbitrary value.
>
> They have to have some sort of units. Some number of clocks perhaps. Or
> just say what register field they correspond to.
>
I have re-read all 3 datasheets (A64/H3/A83T) and made string search for finding any information.
But still found nothing, no unit, no more informations than I already wrote in this file.
For the register field, just saying that it is used in the syscon register EMAC_CLK_REG is sufficient ?
> > +The TX/RX clock delay chain settings are board specific and could be found
> > +in vendor FEX files.
> > +
Regards
Corentin Labbe
^ permalink raw reply
* [arm-soc:to-build 4/4] include/linux/buffer_head.h:340:16: warning: 'bno' may be used uninitialized in this function
From: kbuild test robot @ 2016-10-13 13:26 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git to-build
head: 346c22ea9cb8d0ee331c73529b205414e43a4655
commit: 346c22ea9cb8d0ee331c73529b205414e43a4655 [4/4] Revert "Disable "maybe-uninitialized" warning globally"
config: blackfin-BF526-EZBRD_defconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 346c22ea9cb8d0ee331c73529b205414e43a4655
# save the attached .config to linux build tree
make.cross ARCH=blackfin
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
In file included from fs/ext2/inode.c:32:0:
fs/ext2/inode.c: In function 'ext2_get_block':
>> include/linux/buffer_head.h:340:16: warning: 'bno' may be used uninitialized in this function [-Wmaybe-uninitialized]
bh->b_blocknr = block;
~~~~~~~~~~~~~~^~~~~~~
fs/ext2/inode.c:783:6: note: 'bno' was declared here
u32 bno;
^~~
vim +/bno +340 include/linux/buffer_head.h
bd7ade3c Nikolay Borisov 2015-07-02 324 sb_getblk_gfp(struct super_block *sb, sector_t block, gfp_t gfp)
bd7ade3c Nikolay Borisov 2015-07-02 325 {
bd7ade3c Nikolay Borisov 2015-07-02 326 return __getblk_gfp(sb->s_bdev, block, sb->s_blocksize, gfp);
bd7ade3c Nikolay Borisov 2015-07-02 327 }
bd7ade3c Nikolay Borisov 2015-07-02 328
^1da177e Linus Torvalds 2005-04-16 329 static inline struct buffer_head *
^1da177e Linus Torvalds 2005-04-16 330 sb_find_get_block(struct super_block *sb, sector_t block)
^1da177e Linus Torvalds 2005-04-16 331 {
^1da177e Linus Torvalds 2005-04-16 332 return __find_get_block(sb->s_bdev, block, sb->s_blocksize);
^1da177e Linus Torvalds 2005-04-16 333 }
^1da177e Linus Torvalds 2005-04-16 334
^1da177e Linus Torvalds 2005-04-16 335 static inline void
^1da177e Linus Torvalds 2005-04-16 336 map_bh(struct buffer_head *bh, struct super_block *sb, sector_t block)
^1da177e Linus Torvalds 2005-04-16 337 {
^1da177e Linus Torvalds 2005-04-16 338 set_buffer_mapped(bh);
^1da177e Linus Torvalds 2005-04-16 339 bh->b_bdev = sb->s_bdev;
^1da177e Linus Torvalds 2005-04-16 @340 bh->b_blocknr = block;
b0cf2321 Badari Pulavarty 2006-03-26 341 bh->b_size = sb->s_blocksize;
^1da177e Linus Torvalds 2005-04-16 342 }
^1da177e Linus Torvalds 2005-04-16 343
^1da177e Linus Torvalds 2005-04-16 344 static inline void wait_on_buffer(struct buffer_head *bh)
^1da177e Linus Torvalds 2005-04-16 345 {
^1da177e Linus Torvalds 2005-04-16 346 might_sleep();
a9877cc2 Richard Kennedy 2010-08-09 347 if (buffer_locked(bh))
^1da177e Linus Torvalds 2005-04-16 348 __wait_on_buffer(bh);
:::::: The code at line 340 was first introduced by commit
:::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:::::: TO: Linus Torvalds <torvalds@ppc970.osdl.org>
:::::: CC: Linus Torvalds <torvalds@ppc970.osdl.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 14504 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161013/085a2c6b/attachment-0001.gz>
^ permalink raw reply
* [arm-soc:to-build 4/4] arch/s390/pci/pci_dma.c:309:13: warning: 'pa' may be used uninitialized in this function
From: kbuild test robot @ 2016-10-13 13:25 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git to-build
head: 346c22ea9cb8d0ee331c73529b205414e43a4655
commit: 346c22ea9cb8d0ee331c73529b205414e43a4655 [4/4] Revert "Disable "maybe-uninitialized" warning globally"
config: s390-default_defconfig (attached as .config)
compiler: s390x-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 346c22ea9cb8d0ee331c73529b205414e43a4655
# save the attached .config to linux build tree
make.cross ARCH=s390
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
arch/s390/pci/pci_dma.c: In function '__s390_dma_map_sg':
>> arch/s390/pci/pci_dma.c:309:13: warning: 'pa' may be used uninitialized in this function [-Wmaybe-uninitialized]
} __packed data = {rc, addr};
^~~~
arch/s390/pci/pci_dma.c:426:16: note: 'pa' was declared here
unsigned long pa;
^~
vim +/pa +309 arch/s390/pci/pci_dma.c
828b35f6 Jan Glauber 2012-11-29 293 goto out;
13954fd6 Sebastian Ott 2016-09-08 294
13954fd6 Sebastian Ott 2016-09-08 295 if (zdev->tlb_refresh || s390_iommu_strict)
828b35f6 Jan Glauber 2012-11-29 296 bitmap_clear(zdev->iommu_bitmap, offset, size);
13954fd6 Sebastian Ott 2016-09-08 297 else
13954fd6 Sebastian Ott 2016-09-08 298 bitmap_set(zdev->lazy_bitmap, offset, size);
13954fd6 Sebastian Ott 2016-09-08 299
828b35f6 Jan Glauber 2012-11-29 300 out:
828b35f6 Jan Glauber 2012-11-29 301 spin_unlock_irqrestore(&zdev->iommu_bitmap_lock, flags);
828b35f6 Jan Glauber 2012-11-29 302 }
828b35f6 Jan Glauber 2012-11-29 303
52d43d81 Sebastian Ott 2015-10-26 304 static inline void zpci_err_dma(unsigned long rc, unsigned long addr)
52d43d81 Sebastian Ott 2015-10-26 305 {
52d43d81 Sebastian Ott 2015-10-26 306 struct {
52d43d81 Sebastian Ott 2015-10-26 307 unsigned long rc;
52d43d81 Sebastian Ott 2015-10-26 308 unsigned long addr;
52d43d81 Sebastian Ott 2015-10-26 @309 } __packed data = {rc, addr};
52d43d81 Sebastian Ott 2015-10-26 310
52d43d81 Sebastian Ott 2015-10-26 311 zpci_err_hex(&data, sizeof(data));
52d43d81 Sebastian Ott 2015-10-26 312 }
52d43d81 Sebastian Ott 2015-10-26 313
828b35f6 Jan Glauber 2012-11-29 314 static dma_addr_t s390_dma_map_pages(struct device *dev, struct page *page,
828b35f6 Jan Glauber 2012-11-29 315 unsigned long offset, size_t size,
828b35f6 Jan Glauber 2012-11-29 316 enum dma_data_direction direction,
00085f1e Krzysztof Kozlowski 2016-08-03 317 unsigned long attrs)
:::::: The code at line 309 was first introduced by commit
:::::: 52d43d8184b1840c7cf6136724223585f51a1074 s390/pci_dma: improve debugging of errors during dma map
:::::: TO: Sebastian Ott <sebott@linux.vnet.ibm.com>
:::::: CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 16396 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161013/6b7b2883/attachment-0001.gz>
^ permalink raw reply
* [arm-soc:to-build 4/4] drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:4586:10: warning: 'is_11d' may be used uninitialized in this function
From: kbuild test robot @ 2016-10-13 13:17 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git to-build
head: 346c22ea9cb8d0ee331c73529b205414e43a4655
commit: 346c22ea9cb8d0ee331c73529b205414e43a4655 [4/4] Revert "Disable "maybe-uninitialized" warning globally"
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 346c22ea9cb8d0ee331c73529b205414e43a4655
# save the attached .config to linux build tree
make.cross ARCH=powerpc
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function 'brcmf_cfg80211_start_ap':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:4586:10: warning: 'is_11d' may be used uninitialized in this function [-Wmaybe-uninitialized]
err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_REGULATORY,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
is_11d);
~~~~~~~
vim +/is_11d +4586 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
a44aa400 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c Hante Meuleman 2014-12-03 4570
1a873342 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Hante Meuleman 2012-09-27 4571 /* RSN IE */
a44aa400 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c Hante Meuleman 2014-12-03 4572 err = brcmf_configure_wpaie(ifp, tmp_ie, true);
1a873342 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Hante Meuleman 2012-09-27 4573 if (err < 0)
1a873342 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Hante Meuleman 2012-09-27 4574 goto exit;
1a873342 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Hante Meuleman 2012-09-27 4575 }
1a873342 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Hante Meuleman 2012-09-27 4576 } else {
d96b801f drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Arend van Spriel 2012-12-05 4577 brcmf_dbg(TRACE, "No WPA(2) IEs found\n");
1f170110 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Hante Meuleman 2013-02-06 4578 brcmf_configure_opensecurity(ifp);
1a873342 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Hante Meuleman 2012-09-27 4579 }
1a873342 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Hante Meuleman 2012-09-27 4580
a0f07959 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Hante Meuleman 2013-02-08 4581 brcmf_config_ap_mgmt_ie(ifp->vif, &settings->beacon);
1a873342 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Hante Meuleman 2012-09-27 4582
8707e08d drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c Rafa? Mi?ecki 2016-05-27 4583 /* Parameters shared by all radio interfaces */
a44aa400 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c Hante Meuleman 2014-12-03 4584 if (!mbss) {
b3589dfe drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c Hante Meuleman 2016-09-19 4585 if ((supports_11d) && (is_11d != ifp->vif->is_11d)) {
98027769 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c Arend van Spriel 2014-12-21 @4586 err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_REGULATORY,
98027769 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c Arend van Spriel 2014-12-21 4587 is_11d);
98027769 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c Arend van Spriel 2014-12-21 4588 if (err < 0) {
98027769 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c Arend van Spriel 2014-12-21 4589 brcmf_err("Regulatory Set Error, %d\n", err);
98027769 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c Arend van Spriel 2014-12-21 4590 goto exit;
98027769 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c Arend van Spriel 2014-12-21 4591 }
98027769 drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c Arend van Spriel 2014-12-21 4592 }
1a873342 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Hante Meuleman 2012-09-27 4593 if (settings->beacon_interval) {
ac24be6f drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c Arend van Spriel 2012-10-22 4594 err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_BCNPRD,
:::::: The code at line 4586 was first introduced by commit
:::::: 98027769828f772c7ce69b6e58d37b78ebe8ab28 brcmfmac: enable 802.11d support in firmware
:::::: TO: Arend van Spriel <arend@broadcom.com>
:::::: CC: Kalle Valo <kvalo@codeaurora.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 50804 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161013/18fc4945/attachment-0001.gz>
^ permalink raw reply
* [PATCH V3 10/10] arm64: KVM: add guest SEA support
From: Punit Agrawal @ 2016-10-13 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475875882-2604-11-git-send-email-tbaicar@codeaurora.org>
Hi Tyler,
I know I've had my last comment already ;), but I thought I'd rather
raise the question than stay confused...
Tyler Baicar <tbaicar@codeaurora.org> writes:
> Currently external aborts are unsupported by the guest abort
> handling. Add handling for SEAs so that the host kernel reports
> SEAs which occur in the guest kernel.
>
> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
> ---
> arch/arm/include/asm/kvm_arm.h | 1 +
> arch/arm/include/asm/system_misc.h | 5 +++++
> arch/arm/kvm/mmu.c | 15 +++++++++++++--
> arch/arm64/include/asm/kvm_arm.h | 1 +
> arch/arm64/include/asm/system_misc.h | 2 ++
> arch/arm64/mm/fault.c | 13 +++++++++++++
> 6 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
> index e22089f..33a77509 100644
> --- a/arch/arm/include/asm/kvm_arm.h
> +++ b/arch/arm/include/asm/kvm_arm.h
> @@ -187,6 +187,7 @@
> #define FSC_FAULT (0x04)
> #define FSC_ACCESS (0x08)
> #define FSC_PERM (0x0c)
> +#define FSC_EXTABT (0x10)
>
> /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
> #define HPFAR_MASK (~0xf)
> diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
> index a3d61ad..86e1faa 100644
> --- a/arch/arm/include/asm/system_misc.h
> +++ b/arch/arm/include/asm/system_misc.h
> @@ -24,4 +24,9 @@ extern unsigned int user_debug;
>
> #endif /* !__ASSEMBLY__ */
>
> +inline int handle_guest_sea(unsigned long addr, unsigned int esr)
> +{
> + return -1;
> +}
> +
> #endif /* __ASM_ARM_SYSTEM_MISC_H */
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index e9a5c0e..24cde84 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -29,6 +29,7 @@
> #include <asm/kvm_asm.h>
> #include <asm/kvm_emulate.h>
> #include <asm/virt.h>
> +#include <asm/system_misc.h>
>
> #include "trace.h"
>
> @@ -1441,8 +1442,18 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
>
> /* Check the stage-2 fault is trans. fault or write fault */
> fault_status = kvm_vcpu_trap_get_fault_type(vcpu);
> - if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
> - fault_status != FSC_ACCESS) {
> +
> + if (fault_status == FSC_EXTABT) {
> + if(handle_guest_sea((unsigned long)fault_ipa,
> + kvm_vcpu_get_hsr(vcpu))) {
> + kvm_err("Failed to handle guest SEA, FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
> + kvm_vcpu_trap_get_class(vcpu),
> + (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
> + (unsigned long)kvm_vcpu_get_hsr(vcpu));
> + return -EFAULT;
> + }
> + } else if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
> + fault_status != FSC_ACCESS) {
> kvm_err("Unsupported FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
> kvm_vcpu_trap_get_class(vcpu),
> (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
> diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
> index 4b5c977..be0efb6 100644
> --- a/arch/arm64/include/asm/kvm_arm.h
> +++ b/arch/arm64/include/asm/kvm_arm.h
> @@ -201,6 +201,7 @@
> #define FSC_FAULT ESR_ELx_FSC_FAULT
> #define FSC_ACCESS ESR_ELx_FSC_ACCESS
> #define FSC_PERM ESR_ELx_FSC_PERM
> +#define FSC_EXTABT ESR_ELx_FSC_EXTABT
>
> /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
> #define HPFAR_MASK (~UL(0xf))
> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
> index 90daf4a..8522fff 100644
> --- a/arch/arm64/include/asm/system_misc.h
> +++ b/arch/arm64/include/asm/system_misc.h
> @@ -77,4 +77,6 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
> int sea_register_handler_chain(struct notifier_block *nb);
> void sea_unregister_handler_chain(struct notifier_block *nb);
>
> +int handle_guest_sea(unsigned long addr, unsigned int esr);
> +
> #endif /* __ASM_SYSTEM_MISC_H */
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index 81cb7ad..d714432 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -597,6 +597,19 @@ static const char *fault_name(unsigned int esr)
> }
>
> /*
> + * Handle Synchronous External Aborts that occur in a guest kernel.
> + */
> +int handle_guest_sea(unsigned long addr, unsigned int esr)
> +{
> + atomic_notifier_call_chain(&sea_handler_chain, 0, NULL);
> +
> + pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
> + fault_name(esr), esr, addr);
> +
> + return 0;
> +}
Don't we need to pass the abort to the guest?
Thanks,
Punit
> +
> +/*
> * Dispatch a data abort to the relevant handler.
> */
> asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
^ permalink raw reply
* [PATCH V3 06/10] acpi: apei: panic OS with fatal error status block
From: Suzuki K Poulose @ 2016-10-13 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475875882-2604-7-git-send-email-tbaicar@codeaurora.org>
On 07/10/16 22:31, Tyler Baicar wrote:
> From: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>
>
> Even if an error status block's severity is fatal, the kernel does not
> honor the severity level and panic.
>
> With the firmware first model, the platform could inform the OS about a
> fatal hardware error through the non-NMI GHES notification type. The OS
> should panic when a hardware error record is received with this
> severity.
>
> Call panic() after CPER data in error status block is printed if
> severity is fatal, before each error section is handled.
>
> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> ---
> drivers/acpi/apei/ghes.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 28d5a09..36894c8 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -141,6 +141,8 @@ static unsigned long ghes_estatus_pool_size_request;
> static struct ghes_estatus_cache *ghes_estatus_caches[GHES_ESTATUS_CACHES_SIZE];
> static atomic_t ghes_estatus_cache_alloced;
>
> +static int ghes_panic_timeout __read_mostly = 30;
> +
> static int ghes_ioremap_init(void)
> {
> ghes_ioremap_area = __get_vm_area(PAGE_SIZE * GHES_IOREMAP_PAGES,
> @@ -715,6 +717,12 @@ static int ghes_proc(struct ghes *ghes)
> if (ghes_print_estatus(NULL, ghes->generic, ghes->estatus))
> ghes_estatus_cache_add(ghes->generic, ghes->estatus);
> }
> + if (ghes_severity(ghes->estatus->error_severity) >= GHES_SEV_PANIC) {
> + if (panic_timeout == 0)
> + panic_timeout = ghes_panic_timeout;
> + panic("Fatal hardware error!");
I think there is a chance that we might miss the o/p of ghes_print_estatus() as we use
no pfx, and it could default to the normal loglevel and would never get printed
if panic() is encountered before it. On the other hand, there is already a
__ghes_panic() which does similar stuff. Is there a way we could reuse
(may be even parts of) it ? Or at least use KERN_EMERG for the ghes_print_estatus(),
if the severity could result in panic() ?
Cheers
Suzuki
^ permalink raw reply
* [PATCH 1/3] binding: irqchip: mtk-cirq: Add binding document
From: Matthias Brugger @ 2016-10-13 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476335194-26604-2-git-send-email-youlin.pei@mediatek.com>
On 10/13/2016 07:06 AM, Youlin Pei wrote:
> This commit adds the device tree binding document for
> the mediatek cirq.
>
> Signed-off-by: Youlin Pei <youlin.pei@mediatek.com>
>
> ---
> base on v4.8-rc1
> ---
> .../interrupt-controller/mediatek,cirq.txt | 30 ++++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
> new file mode 100644
> index 0000000..ad16953
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,cirq.txt
> @@ -0,0 +1,30 @@
> +* Mediatek 27xx cirq
> +
> +In Mediatek SOCs, the CIRQ is a low power interrupt controller designed to
> +works outside MCUSYS which comprises with Cortex-Ax cores,CCI and GIC.
> +The external interrupts (outside MCUSYS) will feed through CIRQ and connect
> +to GIC in MCUSYS. When CIRQ is enabled, it will record the edge-sensitive
> +interrupts and generated a pulse signal to parent interrupt controller when
> +flush command is executed. With CIRQ, MCUSYS can be completely turned off
> +to improve the system power consumption without losing interrupts.
> +
> +Required properties:
> +- compatible: should be: "mediatek,mt2701-cirq".
The cirq is present in several SoCs. I suppose it is the same core in
all of them. So we can name it mediatek,mtk-cirq and add a
mediatek,mtXXXX-cirq for every SoC, just in case we will need it.
Thanks,
Matthias
^ permalink raw reply
* [PATCH 1/1 v8] ARM: imx: Added perf functionality to mmdc driver
From: Shawn Guo @ 2016-10-13 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHrpEqQ2H7FZVbn_A3VPCs3aA7AekT7k+Z++js_iCTw346z9Sw@mail.gmail.com>
On Mon, Oct 10, 2016 at 03:17:36PM -0500, Zhi Li wrote:
> On Mon, Sep 26, 2016 at 11:40 AM, Zhi Li <lznuaa@gmail.com> wrote:
> > On Mon, Sep 19, 2016 at 12:57 PM, Frank Li <Frank.Li@nxp.com> wrote:
> >> From: Zhengyu Shen <zhengyu.shen@nxp.com>
> >>
> >> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64
> >> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high
> >> performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6
> >> QuadPlus devices, but this driver only supports i.MX6 Quad at the moment.
> >> MMDC provides registers for performance counters which read via this
> >> driver to help debug memory throughput and similar issues.
> >>
> >> $ perf stat -a -e mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/ dd if=/dev/zero of=/dev/null bs=1M count=5000
> >> Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
> >>
> >> 898021787 mmdc/busy-cycles/
> >> 14819600 mmdc/read-accesses/
> >> 471.30 MB mmdc/read-bytes/
> >> 2815419216 mmdc/total-cycles/
> >> 13367354 mmdc/write-accesses/
> >> 427.76 MB mmdc/write-bytes/
> >>
> >> 5.334757334 seconds time elapsed
> >>
> >> Signed-off-by: Zhengyu Shen <zhengyu.shen@nxp.com>
> >> Signed-off-by: Frank Li <frank.li@nxp.com>
> >> ---
> >
> > Mark:
> > Any additional comments for this version?
> >
>
> Shawn:
> No any new comment for more than 2 weeks.
> Did you plan accept this patch?
We normally do not apply patches in the middle of a merge window. I
plan to apply it when 4.9-rc1 comes out. But I still would like to get
a Reviewed-by tag from Mark before doing that.
@Mark,
Are you happy with this version?
Shawn
^ permalink raw reply
* [PATCH 2/2] power/reset: at91-poweroff: timely shitdown LPDDR memories
From: Richard Genoud @ 2016-10-13 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5PgwXsCoMROO+Vftx8bbhTXP1V-JdZmdwWJ0tgOUW1Axw@mail.gmail.com>
2016-10-13 14:27 GMT+02:00 Jean-Jacques Hiblot <jjhiblot@traphandler.com>:
> 2016-10-13 13:03 GMT+02:00 Alexandre Belloni
> <alexandre.belloni@free-electrons.com>:
>> On 12/10/2016 at 14:48:27 +0200, Jean-Jacques Hiblot wrote :
>>> > +static void at91_lpddr_poweroff(void)
>>> > +{
>>> > + asm volatile(
>>> > + /* Align to cache lines */
>>> > + ".balign 32\n\t"
>>> > +
>>> > + " ldr r6, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
>>> At first sight, it looks useless. I assume it's used to preload the
>>> TLB before the LPDDR is turned off.
>>> A comment to explain why this line is useful would prevent its removal.
>>
>> Yes, this is the case. I can add a comment.
>>
>> Anyway, I would prefer the whole thing to run from SRAM, as a PIE
>> instead of relying on the cache.
>
> Instead of copying into the SRAM, you can make the cache reliable by
> preloading it, much like the TLB.
> LDI is probably not available for most of atmel's SOC, so the only way
> I can think of, is to execute code from the targeted area. here is an
> example:
> + /*
> + * Jump to the end of the sequence to preload instruction cache
> + * It only works because the sequence is short enough not to
> + * sit accross more than 2 cache lines
> + */
> + " b end_of_sequence\n\t"
> + "start_of_sequence:\n\t"
> +
> /* Power down SDRAM0 */
> " str %1, [%0, #"
> __stringify(AT91_DDRSDRC_LPR) "]\n\t"
> /* Shutdown CPU */
> " str %3, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
>
> " b .\n\t"
> +
> + /*
> + * we're now 100% sure that the code to shutdown the LPDDR and
> + * the CPU is in cache, go back to do the actual job
> + */
> + "end_of_sequence:\n\t"
> + " b start_of_sequence\n\t"
> :
My 2c: I think you may want to change your subject :)
Richard.
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: zx: Add clock controller nodes
From: Jun Nie @ 2016-10-13 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476361881-19685-1-git-send-email-jun.nie@linaro.org>
Add clock controller nodes, including one top controller
two low speed controllers and one audio controller.
Signed-off-by: Jun Nie <jun.nie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 6b239a3..e419eff 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -279,9 +279,33 @@
dma-requests = <32>;
};
+ lsp0crm: clock-controller at 1420000 {
+ compatible = "zte,zx296718-lsp0crm";
+ reg = <0x01420000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ lsp1crm: clock-controller at 1430000 {
+ compatible = "zte,zx296718-lsp1crm";
+ reg = <0x01430000 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ topcrm: clock-controller at 1461000 {
+ compatible = "zte,zx296718-topcrm";
+ reg = <0x01461000 0x1000>;
+ #clock-cells = <1>;
+ };
+
sysctrl: sysctrl at 1463000 {
compatible = "zte,zx296718-sysctrl", "syscon";
reg = <0x1463000 0x1000>;
};
+
+ audiocrm: clock-controller at 1480000 {
+ compatible = "zte,zx296718-audiocrm";
+ reg = <0x01480000 0x1000>;
+ #clock-cells = <1>;
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: zx: Fix gic GICR property
From: Jun Nie @ 2016-10-13 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476361881-19685-1-git-send-email-jun.nie@linaro.org>
GICR for multiple CPU can be described with start address and stride,
or with multiple address. Current multiple address and stride are
both used. Fix it.
vmalloc patch 727a7f5a9 triggered this bug:
[ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
[ 0.097150] pgd = ffff000008602000
[ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
[ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
[ 0.097170] Modules linked in:
[ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
[ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
[ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
[ 0.097197] PC is at gic_populate_rdist+0x74/0x15c
[ 0.097202] LR is at gic_starting_cpu+0xc/0x20
[ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
Signed-off-by: Jun Nie <jun.nie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index a223066..6b239a3 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -239,16 +239,11 @@
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
#address-cells = <0>;
- #redistributor-regions = <6>;
- redistributor-stride = <0x0 0x40000>;
+ #redistributor-regions = <1>;
+ redistributor-stride = <0x20000>;
interrupt-controller;
reg = <0x02a00000 0x10000>,
- <0x02b00000 0x20000>,
- <0x02b20000 0x20000>,
- <0x02b40000 0x20000>,
- <0x02b60000 0x20000>,
- <0x02b80000 0x20000>,
- <0x02ba0000 0x20000>;
+ <0x02b00000 0xc0000>;
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/2] Fix and add more zx dt nodes
From: Jun Nie @ 2016-10-13 12:31 UTC (permalink / raw)
To: linux-arm-kernel
Changes vs V1:
- Add more background information for the GIC fix.
- Fix minor coding style issue.
Jun Nie (2):
arm64: dts: zx: Fix gic GICR property
arm64: dts: zx: Add clock controller nodes
arch/arm64/boot/dts/zte/zx296718.dtsi | 35 +++++++++++++++++++++++++++--------
1 file changed, 27 insertions(+), 8 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 2/2] power/reset: at91-poweroff: timely shitdown LPDDR memories
From: Jean-Jacques Hiblot @ 2016-10-13 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161013110317.ee6by6njrvs53ztx@piout.net>
2016-10-13 13:03 GMT+02:00 Alexandre Belloni
<alexandre.belloni@free-electrons.com>:
> On 12/10/2016 at 14:48:27 +0200, Jean-Jacques Hiblot wrote :
>> > +static void at91_lpddr_poweroff(void)
>> > +{
>> > + asm volatile(
>> > + /* Align to cache lines */
>> > + ".balign 32\n\t"
>> > +
>> > + " ldr r6, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
>> At first sight, it looks useless. I assume it's used to preload the
>> TLB before the LPDDR is turned off.
>> A comment to explain why this line is useful would prevent its removal.
>
> Yes, this is the case. I can add a comment.
>
> Anyway, I would prefer the whole thing to run from SRAM, as a PIE
> instead of relying on the cache.
Instead of copying into the SRAM, you can make the cache reliable by
preloading it, much like the TLB.
LDI is probably not available for most of atmel's SOC, so the only way
I can think of, is to execute code from the targeted area. here is an
example:
+ /*
+ * Jump to the end of the sequence to preload instruction cache
+ * It only works because the sequence is short enough not to
+ * sit accross more than 2 cache lines
+ */
+ " b end_of_sequence\n\t"
+ "start_of_sequence:\n\t"
+
/* Power down SDRAM0 */
" str %1, [%0, #"
__stringify(AT91_DDRSDRC_LPR) "]\n\t"
/* Shutdown CPU */
" str %3, [%2, #" __stringify(AT91_SHDW_CR) "]\n\t"
" b .\n\t"
+
+ /*
+ * we're now 100% sure that the code to shutdown the LPDDR and
+ * the CPU is in cache, go back to do the actual job
+ */
+ "end_of_sequence:\n\t"
+ " b start_of_sequence\n\t"
:
>
>> > + ddr_type = readl(mpddrc_base + AT91_DDRSDRC_MDR) & AT91_DDRSDRC_MD;
>> > + if ((ddr_type == AT91_DDRSDRC_MD_LPDDR2) ||
>> > + (ddr_type == AT91_DDRSDRC_MD_LPDDR3))
>> Souldn't there be something like "pm_power_off = at91_lpddr_poweroff;" here ?
>>
>
> Indeed
>
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH v3 1/5] arm64: mm: BUG on unsupported manipulations of live kernel mappings
From: Ard Biesheuvel @ 2016-10-13 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161012150428.s4gajqlnnivo6bld@localhost>
On 12 October 2016 at 16:04, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Wed, Oct 12, 2016 at 12:23:41PM +0100, Ard Biesheuvel wrote:
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -28,8 +28,6 @@
>> #include <linux/memblock.h>
>> #include <linux/fs.h>
>> #include <linux/io.h>
>> -#include <linux/slab.h>
>> -#include <linux/stop_machine.h>
>>
>> #include <asm/barrier.h>
>> #include <asm/cputype.h>
>> @@ -95,6 +93,12 @@ static phys_addr_t __init early_pgtable_alloc(void)
>> return phys;
>> }
>>
>> +/*
>> + * The following mapping attributes may be updated in live
>> + * kernel mappings without the need for break-before-make.
>> + */
>> +static const pteval_t modifiable_attr_mask = PTE_PXN | PTE_RDONLY | PTE_WRITE;
>> +
>> static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
>> unsigned long end, unsigned long pfn,
>> pgprot_t prot,
>> @@ -115,8 +119,18 @@ static void alloc_init_pte(pmd_t *pmd, unsigned long addr,
>>
>> pte = pte_set_fixmap_offset(pmd, addr);
>> do {
>> + pte_t old_pte = *pte;
>> +
>> set_pte(pte, pfn_pte(pfn, prot));
>> pfn++;
>> +
>> + /*
>> + * After the PTE entry has been populated once, we
>> + * only allow updates to the permission attributes.
>> + */
>> + BUG_ON(pte_val(old_pte) != 0 &&
>> + ((pte_val(old_pte) ^ pte_val(*pte)) &
>> + ~modifiable_attr_mask) != 0);
>
> Please turn this check into a single macro. You have it in three places
> already (though with different types but a macro would do). Something
> like below (feel free to come up with a better macro name):
>
> BUG_ON(!safe_pgattr_change(old_pte, *pte));
>
Something like below? With that, I can also fold the PMD and PUD
versions of the BUG() together.
"""
/*
* Returns whether updating a live page table entry is safe:
* - if the old and new values are identical,
* - if an invalid mapping is turned into a valid one (or vice versa),
* - if the entry is a block or page mapping, and the old and new values
* only differ in the PXN/RDONLY/WRITE bits.
*
* NOTE: 'safe' does not imply that no TLB maintenance is required, it only
* means that no TLB conflicts should occur as a result of the update.
*/
#define __set_pgattr_is_safe(type, old, new, blocktype) \
(type ## _val(old) == type ## _val(new) || \
((type ## _val(old) ^ type ## _val(new)) & PTE_VALID) != 0 || \
(((type ## _val(old) & PTE_TYPE_MASK) == blocktype) && \
(((type ## _val(old) ^ type ## _val(new)) & \
~(PTE_PXN | PTE_RDONLY | PTE_WRITE)) == 0)))
static inline bool set_live_pte_is_safe(pte_t old, pte_t new)
{
return __set_pgattr_is_safe(pte, old, new, PTE_TYPE_PAGE);
}
static inline bool set_live_pmd_is_safe(pmd_t old, pmd_t new)
{
return __set_pgattr_is_safe(pmd, old, new, PMD_TYPE_SECT);
}
static inline bool set_live_pud_is_safe(pud_t old, pud_t new)
{
return __set_pgattr_is_safe(pud, old, new, PUD_TYPE_SECT);
}
"""
^ permalink raw reply
* [PATCH v2 1/2] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Daniel Lezcano @ 2016-10-13 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475604730-140264-1-git-send-email-briannorris@chromium.org>
On 04/10/2016 20:12, Brian Norris wrote:
> The ARM ARM specifies that the system counter "must be implemented in an
> always-on power domain," and so we try to use the counter as a source of
> timekeeping across suspend/resume. Unfortunately, some SoCs (e.g.,
> Rockchip's RK3399) do not keep the counter ticking properly when
> switched from their high-power clock to the lower-power clock used in
> system suspend. Support this quirk by adding a new device tree property.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
Both patches applied for 4.10.
Thanks !
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ 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