* [PATCH 3/3] dt-bindings: oxnas: Update Pinctrl and GPIO for OX820 Support
From: Linus Walleij @ 2016-10-20 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004134148.23028-4-narmstrong@baylibre.com>
On Tue, Oct 4, 2016 at 3:41 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 3/6] ARM: at91: Add armv7m support
From: Arnd Bergmann @ 2016-10-20 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020102621.od7kkgpndooy25kz@piout.net>
On Thursday, October 20, 2016 12:26:21 PM CEST Alexandre Belloni wrote:
>
> On 20/10/2016 at 11:52:20 +0200, Arnd Bergmann wrote :
> > On Thursday, October 20, 2016 11:41:32 AM CEST Alexandre Belloni wrote:
> > > +
> > > +static void __init samx7_dt_device_init(void)
> > > +{
> > > + struct soc_device *soc;
> > > + struct device *soc_dev = NULL;
> > > +
> > > + soc = at91_soc_init(samx7_socs);
> > > + if (soc)
> > > + soc_dev = soc_device_to_device(soc);
> > > +
> > > + of_platform_populate(NULL, of_default_bus_match_table, NULL, soc_dev);
> > > +}
> >
> > This was initially the idea for the soc_device, but we've stopped
> > using it as the parent for the on-chip devices a while ago.
> >
> > Just register the device for identification here, and use
> > of_platform_default_populate with a NULL parent as most others do.
> >
> > We should also investigate whether we can convert the three other
> > at91 variants to do the same without breaking expectations in user space.
> >
>
> My opinion is that we could just remove the whole at91_soc_init stuff
> but I think Nicolas still wants the two info lines to be printed for
> debugging/support purposes. I'm not sure how much this is used anyway
> and I don't find the sysfs attributes to be particularly useful.
>
> Also, removing soc.c is a 10% reduction of the code in mach-at91
>
Having the soc_device driver is very valuable in order to have
an interface to be used from user space (and soon from the kernel)
to look up the exact SoC type in a generic way, so I'd definitely
want to keep that, though we may want to move that driver to
drivers/soc/.
Arnd
^ permalink raw reply
* [PATCH 2/3] pinctrl: oxnas: Add support for OX820
From: Linus Walleij @ 2016-10-20 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004134148.23028-3-narmstrong@baylibre.com>
On Tue, Oct 4, 2016 at 3:41 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Add support for the Oxford Semiconductor OX820 which is similar as OX810 but
> has 50 pins and two registers banks to setup alternate functions.
> Add specific pins, groups and functions structures.
> Add DT match data to select corresponding support.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/3] pinctrl: oxnas: Move OX810SE specific function and structure as separate
From: Linus Walleij @ 2016-10-20 13:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004134148.23028-2-narmstrong@baylibre.com>
On Tue, Oct 4, 2016 at 3:41 PM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Add refactoring to move ox810se specific functions into specific ops structures
> an add support for the dt match data to get soc specific structures.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 0/3] ARM-OMAP2+: Fine-tuning for five function implementations
From: Tony Lindgren @ 2016-10-20 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e86a5ded-a6e9-1b40-be1a-98fffef0abb5@users.sourceforge.net>
* SF Markus Elfring <elfring@users.sourceforge.net> [161015 13:51]:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 15 Oct 2016 22:44:22 +0200
>
> A few update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (3):
> mux: Replace three seq_printf() calls by seq_puts()
> mux: Use seq_putc() in omap_mux_dbg_signal_show()
> pm-debug: Use seq_putc() in two functions
Thanks will be applying for v4.10 merge window. FYI, chances
are that arch/arm/mach-map2/mux.c will get dropped for v4.10
unless we run into regressions.
Regards,
Tony
^ permalink raw reply
* [PATCH 0/3] pinctrl: sunxi: Support generic pinconf functions
From: Linus Walleij @ 2016-10-20 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161004015112.20833-1-wens@csie.org>
On Tue, Oct 4, 2016 at 3:51 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> This series fixes up generic pinconf support for the sunxi pinctrl driver
> library. The driver was doing some bits wrong, like a) storing the pinconf
> config value in its struct, and not actually reading the hardware to get
> the current config, and b) not using the right arguments for the bias
> parameters.
Looks OK to me, Maxime are you OK with me applying this, or
are we waiting for a new iteration of this patch set?
I have started to apply Maxime's generic binding rework, will it
clash with these?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv4 03/15] dt-bindings: clock: add omap4 hwmod clock IDs
From: Tony Lindgren @ 2016-10-20 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <051e2a14-8fb9-fd0f-99e0-decc5c02ae75@ti.com>
* Tero Kristo <t-kristo@ti.com> [161020 06:00]:
> On 20/10/16 15:47, Tony Lindgren wrote:
> > * Tero Kristo <t-kristo@ti.com> [161018 08:47]:
> > > Add IDs for omap4 hwmod clocks. These are basically register offsets
> > > from the beginning of the clockdomain address space.
> >
> > Looks like you have a wrong subject for this patch?
>
> What is the correct one? There seems to be multiple approaches in place.
Oh sorry yeah never mind, I somehow thought these defines
we for drivers/clk, not for dt-bindings.. Sorry for the noise.
Tony
^ permalink raw reply
* [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Tony Lindgren @ 2016-10-20 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476805568-19264-12-git-send-email-t-kristo@ti.com>
* Tero Kristo <t-kristo@ti.com> [161018 08:47]:
> Clockdomains can now be used as clock providers in the system. This
> patch initializes the provider data during init, and parses the clocks
> while they are being registered. An xlate function for the provider
> is also given.
Good to see this happen:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCHv3 4/4] arm64: dump: Add checking for writable and exectuable pages
From: Laura Abbott @ 2016-10-20 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-jmocWVRgRzd10VBD9+E_w33DfLm-zj_=iVGodczsnmw@mail.gmail.com>
On 10/20/2016 03:32 AM, Ard Biesheuvel wrote:
> On 18 October 2016 at 23:01, Laura Abbott <labbott@redhat.com> wrote:
>>
>> Page mappings with full RWX permissions are a security risk. x86
>> has an option to walk the page tables and dump any bad pages.
>> (See e1a58320a38d ("x86/mm: Warn on W^X mappings")). Add a similar
>> implementation for arm64.
>>
>> Reviewed-by: Kees Cook <keescook@chromium.org>
>> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
>> Tested-by: Mark Rutland <mark.rutland@arm.com>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> v3: Rebased for header guard fixup, whitespace fixes
>> ---
>> arch/arm64/Kconfig.debug | 29 +++++++++++++++++++++++
>> arch/arm64/include/asm/ptdump.h | 8 +++++++
>> arch/arm64/mm/dump.c | 52 +++++++++++++++++++++++++++++++++++++++++
>> arch/arm64/mm/mmu.c | 2 ++
>> 4 files changed, 91 insertions(+)
>>
>> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
>> index 21a5b74..d1ebd46 100644
>> --- a/arch/arm64/Kconfig.debug
>> +++ b/arch/arm64/Kconfig.debug
>> @@ -42,6 +42,35 @@ config ARM64_RANDOMIZE_TEXT_OFFSET
>> of TEXT_OFFSET and platforms must not require a specific
>> value.
>>
>> +config DEBUG_WX
>> + bool "Warn on W+X mappings at boot"
>> + select ARM64_PTDUMP_CORE
>> + ---help---
>> + Generate a warning if any W+X mappings are found at boot.
>> +
>> + This is useful for discovering cases where the kernel is leaving
>> + W+X mappings after applying NX, as such mappings are a security risk.
>> + This check also includes UXN, which should be set on all kernel
>> + mappings.
>> +
>> + Look for a message in dmesg output like this:
>> +
>> + arm64/mm: Checked W+X mappings: passed, no W+X pages found.
>> +
>> + or like this, if the check failed:
>> +
>> + arm64/mm: Checked W+X mappings: FAILED, <N> W+X pages found.
>> +
>> + Note that even if the check fails, your kernel is possibly
>> + still fine, as W+X mappings are not a security hole in
>> + themselves, what they do is that they make the exploitation
>> + of other unfixed kernel bugs easier.
>> +
>> + There is no runtime or memory usage effect of this option
>> + once the kernel has booted up - it's a one time check.
>> +
>> + If in doubt, say "Y".
>> +
>> config DEBUG_SET_MODULE_RONX
>> bool "Set loadable kernel module data as NX and text as RO"
>> depends on MODULES
>> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
>> index f72ee69..6afd847 100644
>> --- a/arch/arm64/include/asm/ptdump.h
>> +++ b/arch/arm64/include/asm/ptdump.h
>> @@ -42,5 +42,13 @@ static inline int ptdump_debugfs_register(struct ptdump_info *info,
>> return 0;
>> }
>> #endif
>> +void ptdump_check_wx(void);
>> #endif /* CONFIG_ARM64_PTDUMP_CORE */
>> +
>> +#ifdef CONFIG_DEBUG_WX
>> +#define debug_checkwx() ptdump_check_wx()
>> +#else
>> +#define debug_checkwx() do { } while (0)
>> +#endif
>> +
>> #endif /* __ASM_PTDUMP_H */
>> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
>> index bb36649..4913af5 100644
>> --- a/arch/arm64/mm/dump.c
>> +++ b/arch/arm64/mm/dump.c
>> @@ -74,6 +74,8 @@ struct pg_state {
>> unsigned long start_address;
>> unsigned level;
>> u64 current_prot;
>> + bool check_wx;
>> + unsigned long wx_pages;
>> };
>>
>> struct prot_bits {
>> @@ -202,6 +204,35 @@ static void dump_prot(struct pg_state *st, const struct prot_bits *bits,
>> }
>> }
>>
>> +static void note_prot_uxn(struct pg_state *st, unsigned long addr)
>> +{
>> + if (!st->check_wx)
>> + return;
>> +
>> + if ((st->current_prot & PTE_UXN) == PTE_UXN)
>> + return;
>> +
>> + WARN_ONCE(1, "arm64/mm: Found non-UXN mapping at address %p/%pS\n",
>> + (void *)st->start_address, (void *)st->start_address);
>> +
>> + st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
>> +}
>> +
>> +static void note_prot_wx(struct pg_state *st, unsigned long addr)
>> +{
>> + if (!st->check_wx)
>> + return;
>> + if ((st->current_prot & PTE_RDONLY) == PTE_RDONLY)
>> + return;
>> + if ((st->current_prot & PTE_PXN) == PTE_PXN)
>> + return;
>> +
>> + WARN_ONCE(1, "arm64/mm: Found insecure W+X mapping at address %p/%pS\n",
>> + (void *)st->start_address, (void *)st->start_address);
>> +
>> + st->wx_pages += (addr - st->start_address) / PAGE_SIZE;
>> +}
>> +
>
> Why are these separate functions, and why is wx_pages increased twice,
> potentially?
>
> Given how rare non-UXN kernel mappings should be, could we not just add
>
> if ((st->current_prot & PTE_UXN) == 0)
> WARN(xxx)
>
> (without the _ONCE) to note_prot_wx(), and drop note_prot_uxn() entirely?
>
>
UXN is a separate bit from PTE_PXN/PTE_RDONLY and both pairs need to
be checked. The current return == 0 logic means that one set or the
other may not get checked. Rather than complicate the logic, it seemed
better to have separate functions. I see your point about the wx_pages
double counting so I can fix that.
>> static void note_page(struct pg_state *st, unsigned long addr, unsigned level,
>> u64 val)
>> {
>> @@ -219,6 +250,8 @@ static void note_page(struct pg_state *st, unsigned long addr, unsigned level,
>> unsigned long delta;
>>
>> if (st->current_prot) {
>> + note_prot_uxn(st, addr);
>> + note_prot_wx(st, addr);
>> pt_dump_seq_printf(st->seq, "0x%016lx-0x%016lx ",
>> st->start_address, addr);
>>
>> @@ -344,6 +377,25 @@ static struct ptdump_info kernel_ptdump_info = {
>> .base_addr = VA_START,
>> };
>>
>> +void ptdump_check_wx(void)
>> +{
>> + struct pg_state st = {
>> + .seq = NULL,
>> + .marker = (struct addr_marker[]) {
>> + { -1, NULL},
>> + },
>> + .check_wx = true,
>> + };
>> +
>> + walk_pgd(&st, &init_mm, 0);
>> + note_page(&st, 0, 0, 0);
>> + if (st.wx_pages)
>> + pr_info("Checked W+X mappings: FAILED, %lu W+X pages found\n",
>> + st.wx_pages);
>
> Could we upgrade this to pr_warn?
>
Sure
>> + else
>> + pr_info("Checked W+X mappings: passed, no W+X pages found\n");
>> +}
>> +
>> static int ptdump_init(void)
>> {
>> ptdump_initialize();
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index 05615a3..2cbe2fe 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -42,6 +42,7 @@
>> #include <asm/tlb.h>
>> #include <asm/memblock.h>
>> #include <asm/mmu_context.h>
>> +#include <asm/ptdump.h>
>>
>> u64 idmap_t0sz = TCR_T0SZ(VA_BITS);
>>
>> @@ -396,6 +397,7 @@ void mark_rodata_ro(void)
>> section_size = (unsigned long)__init_begin - (unsigned long)__start_rodata;
>> create_mapping_late(__pa(__start_rodata), (unsigned long)__start_rodata,
>> section_size, PAGE_KERNEL_RO);
>> + debug_checkwx();
>> }
>>
>> static void __init map_kernel_segment(pgd_t *pgd, void *va_start, void *va_end,
>> --
>> 2.7.4
>>
^ permalink raw reply
* [PATCH v2 9/9] ARM: sunxi: Convert pinctrl nodes to generic bindings
From: Linus Walleij @ 2016-10-20 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e32d044d2d967f24f12d83eea50e7f14f2ae1073.1476200742.git-series.maxime.ripard@free-electrons.com>
On Tue, Oct 11, 2016 at 5:46 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Now that we can handle the generic pinctrl bindings, convert our DT to it.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Awesome work.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Please merge this through the ARM SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO
From: Maxime Ripard @ 2016-10-20 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020034344.14154-2-wens@csie.org>
On Thu, Oct 20, 2016 at 11:43:37AM +0800, Chen-Yu Tsai wrote:
> Some rgb-to-vga bridges have an enable GPIO, either directly tied to
> an enable pin on the bridge IC, or indirectly controlling a power
> switch.
>
> Add support for it.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/5175074f/attachment-0001.sig>
^ permalink raw reply
* [PATCH] arm/arm64: KVM: Map the BSS at HYP
From: Marc Zyngier @ 2016-10-20 13:00 UTC (permalink / raw)
To: linux-arm-kernel
When used with a compiler that doesn't implement "asm goto"
(such as the AArch64 port of GCC 4.8), jump labels generate a
memory access to find out about the value of the key (instead
of just patching the code). The key itself is likely to be
stored in the BSS.
This is perfectly fine, except that we don't map the BSS at HYP,
leading to an exploding kernel at the first access. The obvious
fix is simply to map the BSS there (which should have been done
a long while ago, but hey...).
Reported-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
arch/arm/kvm/arm.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 09942f0..14adf40 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1345,6 +1345,13 @@ static int init_hyp_mode(void)
goto out_err;
}
+ err = create_hyp_mappings(kvm_ksym_ref(__bss_start),
+ kvm_ksym_ref(__bss_stop), PAGE_HYP_RO);
+ if (err) {
+ kvm_err("Cannot map bss section\n");
+ goto out_err;
+ }
+
/*
* Map the Hyp stack pages
*/
--
2.1.4
^ permalink raw reply related
* [PATCHv4 03/15] dt-bindings: clock: add omap4 hwmod clock IDs
From: Tero Kristo @ 2016-10-20 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020124742.7b65l5lz6kcfsysl@atomide.com>
On 20/10/16 15:47, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [161018 08:47]:
>> Add IDs for omap4 hwmod clocks. These are basically register offsets
>> from the beginning of the clockdomain address space.
>
> Looks like you have a wrong subject for this patch?
What is the correct one? There seems to be multiple approaches in place.
-Tero
^ permalink raw reply
* [PATCHv4 09/15] clk: ti: move omap2_init_clk_clkdm under TI clock driver
From: Tony Lindgren @ 2016-10-20 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476805568-19264-10-git-send-email-t-kristo@ti.com>
* Tero Kristo <t-kristo@ti.com> [161018 08:47]:
> This is not needed outside the driver, so move it inside it and remove
> the prototype from the public header also.
Looks safe to merge along with the other clock patches:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH] drivers: psci: Allow PSCI node to be disabled
From: Lorenzo Pieralisi @ 2016-10-20 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020123907.GF10234@leverpostej>
On Thu, Oct 20, 2016 at 01:39:07PM +0100, Mark Rutland wrote:
> On Mon, Oct 17, 2016 at 12:46:53PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Allow disabling PSCI support (mostly for testing purposes) by setting
> > the status property to "disabled". This makes the node behave in much
> > the same way as proper device nodes.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> This looks sensible to me; FWIW:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>
> Lorenzo, do we need to batch this up with other PSCI patches, or should
> this go direct to arm-soc?
I am aiming at getting the PSCI checker merged too so that we can send
both patches (and others that may turn up) in one go to arm-soc, I will
handle it.
Thanks !
Lorenzo
> Thanks,
> Mark.
>
> > ---
> > drivers/firmware/psci.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> > index 8263429e21b8..6c60a5087caf 100644
> > --- a/drivers/firmware/psci.c
> > +++ b/drivers/firmware/psci.c
> > @@ -630,7 +630,7 @@ int __init psci_dt_init(void)
> >
> > np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> >
> > - if (!np)
> > + if (!np || !of_device_is_available(np))
> > return -ENODEV;
> >
> > init_fn = (psci_initcall_t)matched_np->data;
> > --
> > 2.10.0
> >
>
^ permalink raw reply
* [PATCH v2 8/9] ARM: sunxi: Remove useless allwinner, pull property
From: Linus Walleij @ 2016-10-20 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b643d1e525835365a6ae63bcd065cb3650a839d6.1476200742.git-series.maxime.ripard@free-electrons.com>
On Tue, Oct 11, 2016 at 5:46 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The allwinner,pull property set to NO_PULL was really considered our
> default (and wasn't even changing the default value in the code).
>
> Remove these properties to make it obvious that we do not set anything in
> such a case.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Please merge this through the ARM SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 7/9] ARM: sunxi: Remove useless allwinner, drive property
From: Linus Walleij @ 2016-10-20 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <076406072c137a50df41c4acb0c582a688792976.1476200742.git-series.maxime.ripard@free-electrons.com>
On Tue, Oct 11, 2016 at 5:46 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The allwinner,drive property set to 10mA was really considered as our
> default. Remove all those properties entirely to make that obvious.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Please merge this through the ARM SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] kernel: irq: fix build failure
From: Thomas Gleixner @ 2016-10-20 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57FBBA0B.9070500@gmail.com>
On Mon, 10 Oct 2016, Sudip Mukherjee wrote:
> On Thursday 06 October 2016 11:06 PM, Sudip Mukherjee wrote:
> > The allmodconfig build of powerpc is failing with the error:
> > ERROR: ".irq_set_parent" [drivers/mfd/tps65217.ko] undefined!
> >
> > export the symbol to fix the failure.
>
> Hi Thomas,
> powerpc and arm allmodconfig builds still fails with the same error.
> Build logs of next-20161010 are at:
> arm at https://travis-ci.org/sudipm-mukherjee/parport/jobs/166321467
> powerpc at https://travis-ci.org/sudipm-mukherjee/parport/jobs/166321473
I know. This is under discussion with the driver folks as we are not going
to blindly export stuff just because someone slapped a irq_set_parent()
into the code w/o knowing why.
Thanks,
tglx
^ permalink raw reply
* [PATCH 2/2] arm64/numa: fix incorrect print of end_pfn
From: Mark Rutland @ 2016-10-20 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5808B6D1.809@huawei.com>
On Thu, Oct 20, 2016 at 08:21:37PM +0800, Hanjun Guo wrote:
> On 2016/10/20 18:51, Will Deacon wrote:
> > On Thu, Oct 20, 2016 at 11:52:56AM +0800, Hanjun Guo wrote:
> >> From: Hanjun Guo <hanjun.guo@linaro.org>
> >>
> >> When booting on NUMA system with memory-less node (no
> >> memory dimm on this memory controller), the print
> >> for setup_node_data() is incorrect:
> >>
> >> NUMA: Initmem setup node 2 [mem 0x00000000-0xffffffffffffffff]
> >>
> >> It should be 0, not 0xffffffffffffffff as there is
> >> no memory on that node.
> > Wouldn't it make more sense to print something useful, like "memory-less
> > node"?
>
> in the log,
>
> [ 0.000000] NUMA: Initmem setup node 0 [mem 0x00000000-0x13fbffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x13fbffe500-0x13fbffffff]
> [ 0.000000] NUMA: Initmem setup node 1 [mem 0x1400000000-0x17fbffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x17fbfec500-0x17fbfedfff]
> [ 0.000000] NUMA: Initmem setup node 2 [mem 0x00000000-0xffffffffffffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x17fbfeaa00-0x17fbfec4ff]
> [ 0.000000] NUMA: NODE_DATA(2) on node 1
> [ 0.000000] NUMA: Initmem setup node 3 [mem 0x00000000-0xffffffffffffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x17fbfe8f00-0x17fbfea9ff]
> [ 0.000000] NUMA: NODE_DATA(3) on node 1
>
> if printing "NUMA: Initmem setup node 2 [mem 0x00000000-0x00000000]",
Seeing "NUMA: Initmem setup node 2 [<memoryless node>]" would be far
more obvious as a memoryless node, and I don't see that this would be
inconsistent.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2 4/9] pinctrl: sunxi: Deal with configless pins
From: Linus Walleij @ 2016-10-20 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019121614.3crr76qyexhamjiy@lukather>
On Wed, Oct 19, 2016 at 2:16 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Tue, Oct 18, 2016 at 03:47:03PM +0800, Chen-Yu Tsai wrote:
>> > @@ -342,6 +365,8 @@ static void sunxi_pctrl_dt_free_map(struct pinctrl_dev *pctldev,
>> > struct pinctrl_map *map,
>> > unsigned num_maps)
>> > {
>> > + unsigned long *pinconfig;
>>
>> This looks out of place and context?
>
> Yeah, sorry, it's just a leftover from the previous version. This has
> been removed.
Do you mean you will send a v3 of this series?
OK stopping to apply then.
But I have already applied patches 1, 2 and 3 so just resend the rest :)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] arm64/numa: fix incorrect print of end_pfn
From: Will Deacon @ 2016-10-20 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5808B6D1.809@huawei.com>
On Thu, Oct 20, 2016 at 08:21:37PM +0800, Hanjun Guo wrote:
> On 2016/10/20 18:51, Will Deacon wrote:
> > On Thu, Oct 20, 2016 at 11:52:56AM +0800, Hanjun Guo wrote:
> >> From: Hanjun Guo <hanjun.guo@linaro.org>
> >>
> >> When booting on NUMA system with memory-less node (no
> >> memory dimm on this memory controller), the print
> >> for setup_node_data() is incorrect:
> >>
> >> NUMA: Initmem setup node 2 [mem 0x00000000-0xffffffffffffffff]
> >>
> >> It should be 0, not 0xffffffffffffffff as there is
> >> no memory on that node.
> > Wouldn't it make more sense to print something useful, like "memory-less
> > node"?
>
> in the log,
>
> [ 0.000000] NUMA: Initmem setup node 0 [mem 0x00000000-0x13fbffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x13fbffe500-0x13fbffffff]
> [ 0.000000] NUMA: Initmem setup node 1 [mem 0x1400000000-0x17fbffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x17fbfec500-0x17fbfedfff]
> [ 0.000000] NUMA: Initmem setup node 2 [mem 0x00000000-0xffffffffffffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x17fbfeaa00-0x17fbfec4ff]
> [ 0.000000] NUMA: NODE_DATA(2) on node 1
> [ 0.000000] NUMA: Initmem setup node 3 [mem 0x00000000-0xffffffffffffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x17fbfe8f00-0x17fbfea9ff]
> [ 0.000000] NUMA: NODE_DATA(3) on node 1
>
> if printing "NUMA: Initmem setup node 2 [mem 0x00000000-0x00000000]",
> it will make the log consistent with others, and obvious it's a memory-less
> node as memory range 0x00000000-0x00000000, what do you think?
How is that more obvious than printing the string "memory-less node"?
Is this data parsed by something?
Will
^ permalink raw reply
* [PATCH v2 3/9] pinctrl: sunxi: Handle bias disable
From: Linus Walleij @ 2016-10-20 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6f9d91647b9f05a1df5d655a49965b671ba04b71.1476200742.git-series.maxime.ripard@free-electrons.com>
On Tue, Oct 11, 2016 at 5:46 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> So far, putting NO_PULL in allwinner,pull was ignored, behaving like if
> that property was not there at all.
>
> Obviously, this is not the right thing to do, and in that case, we really
> need to just disable the bias.
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/9] pinctrl: sunxi: Use macros from bindings header file for DT parsing
From: Linus Walleij @ 2016-10-20 12:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5de3087f625d6d4a4d552d4a85faafac689f5f54.1476200742.git-series.maxime.ripard@free-electrons.com>
On Tue, Oct 11, 2016 at 5:46 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Since we have some bindings header for our hardcoded flags, let's use them
> when we can.
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/9] pinctrl: sunxi: Rework the pin config building code
From: Linus Walleij @ 2016-10-20 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <709f95f6725453af12bc989ce9039df5aa252ea5.1476200742.git-series.maxime.ripard@free-electrons.com>
On Tue, Oct 11, 2016 at 5:45 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> In order to support more easily the generic pinctrl properties, rework the
> pinctrl maps configuration and split it into several sub-functions.
>
> One of the side-effects from that rework is that we only parse the pin
> configuration once, since it's going to be common to every pin, instead of
> having to parsing once for each pin.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCHv4 03/15] dt-bindings: clock: add omap4 hwmod clock IDs
From: Tony Lindgren @ 2016-10-20 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476805568-19264-4-git-send-email-t-kristo@ti.com>
* Tero Kristo <t-kristo@ti.com> [161018 08:47]:
> Add IDs for omap4 hwmod clocks. These are basically register offsets
> from the beginning of the clockdomain address space.
Looks like you have a wrong subject for this patch?
Tony
^ 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