* [PATCH] ARM: dts: rockchip: add i2c-bus subnode to edp
From: Tomeu Vizoso @ 2016-10-20 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7604646.6yosK0XMNL@diego>
On 10/20/2016 03:45 PM, Heiko St?bner wrote:
> Am Donnerstag, 20. Oktober 2016, 10:07:25 schrieb Tomeu Vizoso:
>> Add an empty 'i2c-bus' subnode to the edp node just so that the I2C core
>> doesn't attemp to parse the 'ports' subnode as containing i2c devices.
>>
>> This is to avoid spurious failure messages such as:
>>
>> i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports
>
> On the one hand, the edp really has an i2c bus - with its only client the EDID
> listening at 0x50 (and maybe 0x30).
>
> On the other hand, adding an empty bus to the (implementation independent)
> devicetree just to make the Linux i2c subsystem happy sounds heavily like a
> implementation-specific hack, as the edp i2c bus doesn't leak into the outside
> world otherwise.
>
> I guess this empty i2c bus not being part of the binding document points
> heavily into the implementation-specific corner :-) .
>
> My short search on other patches touching this didn't reveal anything but
> maybe this was already discussed somewhere and found to be ok?
Here it is:
http://www.spinics.net/lists/linux-tegra/msg27862.html
Regards,
Tomeu
> Another option could be to just make of_i2c_register_device silent if
> of_modalias_node returns -ENODEV?
>
>
> Heiko
>
>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
>> Cc: Randy Li <randy.li@rock-chips.com>
>> Cc: Jon Hunter <jonathanh@nvidia.com>
>> ---
>> arch/arm/boot/dts/rk3288.dtsi | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
>> index 2f814ffeb605..94f4b7eecca2 100644
>> --- a/arch/arm/boot/dts/rk3288.dtsi
>> +++ b/arch/arm/boot/dts/rk3288.dtsi
>> @@ -1075,6 +1075,11 @@
>> };
>> };
>> };
>> +
>> + i2c-bus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> };
>>
>> hdmi: hdmi at ff980000 {
>
^ permalink raw reply
* [PATCH v2 4/9] pinctrl: sunxi: Deal with configless pins
From: Maxime Ripard @ 2016-10-20 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY3+OnQ6Oo_nx+BrWebeTa=kYhHWSzirk1MxfWWJ--0Sg@mail.gmail.com>
Hi Linus,
On Thu, Oct 20, 2016 at 02:52:54PM +0200, Linus Walleij wrote:
> 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?
Yes, I was waiting for your input to do that, but I guess you're ok
with it :)
> OK stopping to apply then.
>
> But I have already applied patches 1, 2 and 3 so just resend the rest :)
Ack, I'll send it in a moment.
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/2e925f92/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: rockchip: add i2c-bus subnode to edp
From: Heiko Stübner @ 2016-10-20 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476950845-28242-1-git-send-email-tomeu.vizoso@collabora.com>
Am Donnerstag, 20. Oktober 2016, 10:07:25 schrieb Tomeu Vizoso:
> Add an empty 'i2c-bus' subnode to the edp node just so that the I2C core
> doesn't attemp to parse the 'ports' subnode as containing i2c devices.
>
> This is to avoid spurious failure messages such as:
>
> i2c i2c-6: of_i2c: modalias failure on /dp at ff970000/ports
On the one hand, the edp really has an i2c bus - with its only client the EDID
listening at 0x50 (and maybe 0x30).
On the other hand, adding an empty bus to the (implementation independent)
devicetree just to make the Linux i2c subsystem happy sounds heavily like a
implementation-specific hack, as the edp i2c bus doesn't leak into the outside
world otherwise.
I guess this empty i2c bus not being part of the binding document points
heavily into the implementation-specific corner :-) .
My short search on other patches touching this didn't reveal anything but
maybe this was already discussed somewhere and found to be ok?
Another option could be to just make of_i2c_register_device silent if
of_modalias_node returns -ENODEV?
Heiko
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> Cc: Randy Li <randy.li@rock-chips.com>
> Cc: Jon Hunter <jonathanh@nvidia.com>
> ---
> arch/arm/boot/dts/rk3288.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index 2f814ffeb605..94f4b7eecca2 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -1075,6 +1075,11 @@
> };
> };
> };
> +
> + i2c-bus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> };
>
> hdmi: hdmi at ff980000 {
^ permalink raw reply
* [PATCH v2] drivers: psci: PSCI checker module
From: Kevin Brodsky @ 2016-10-20 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e57565e8-bec9-0460-32d5-fb9f868cc4f8@arm.com>
Hi Jean-Philippe,
On 18/10/16 20:21, Jean-Philippe Brucker wrote:
> Hi Kevin,
>
> On 21/09/16 15:39, Kevin Brodsky wrote:
>> On arm and arm64, PSCI is one of the possible firmware interfaces
>> used for power management. This includes both turning CPUs on and off,
>> and suspending them (entering idle states).
>>
>> This patch adds a PSCI checker module that enables basic testing of
>> PSCI operations during startup. There are two main tests: CPU
>> hotplugging and suspending.
>>
>> In the hotplug tests, the hotplug API is used to turn off and on again
>> all CPUs in the system, and then all CPUs in each cluster, checking
>> the consistency of the return codes.
>>
>> In the suspend tests, a high-priority thread is created on each core
>> and uses low-level cpuidle functionalities to enter suspend, in all
>> the possible states and multiple times. This should allow a maximum
>> number of CPUs to enter the same sleep state at the same or slightly
>> different time.
>>
>> In essence, the suspend tests use a principle similar to that of the
>> intel_powerclamp driver (drivers/thermal/intel_powerclamp.c), but the
>> threads are only kept for the duration of the test (they are already
>> gone when userspace is started).
>>
>> While in theory power management PSCI functions (CPU_{ON,OFF,SUSPEND})
>> could be directly called, this proved too difficult as it would imply
>> the duplication of all the logic used by the kernel to allow for a
>> clean shutdown/bringup/suspend of the CPU (the deepest sleep states
>> implying potentially the shutdown of the CPU).
>>
>> Note that this file cannot be compiled as a loadable module, since it
>> uses a number of non-exported identifiers (essentially for
>> PSCI-specific checks and direct use of cpuidle) and relies on the
>> absence of userspace to avoid races when calling hotplug and cpuidle
>> functions.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Kevin Hilman <khilman@kernel.org>
>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
>> ---
>> Changelog v1..v2:
>> * Do not count tick_broadcast_enter() failures as errors, as they may
>> be unavoidable. When it happens, fall back to WFI.
>> * Do not count unexpected sleep states as errors (currently, the only
>> case is when falling back to WFI). Instead, report the number of
>> times it happens before the suspend thread exits.
>> * Use usecs_to_jiffies() to compute the suspend timeout. The previous
>> version resulted in a zero timeout if the target residency was
>> shorter than a jiffy.
>> * Various cleanup.
>>
>> Thanks to Lorenzo for his help with improving this patch!
>>
>> Kevin
> [...]
>> +
>> +static int suspend_tests(void)
>> +{
>> + int i, cpu, err = 0;
>> + struct task_struct **threads;
>> + int nb_threads = 0;
>> +
>> + threads = kmalloc_array(nb_available_cpus, sizeof(*threads),
>> + GFP_KERNEL);
>> + if (!threads)
>> + return -ENOMEM;
>> +
>> + for_each_online_cpu(cpu) {
>> + struct task_struct *thread;
>> + /* Check that cpuidle is available on that CPU. */
>> + struct cpuidle_device *dev = per_cpu(cpuidle_devices, cpu);
>> + struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
>> +
>> + if (cpuidle_not_available(drv, dev)) {
>> + pr_warn("cpuidle not available on CPU %d, ignoring\n",
>> + cpu);
>> + continue;
>> + }
>> +
>> + thread = kthread_create_on_cpu(suspend_stress_thread,
>> + (void *)(long)cpu, cpu,
>> + "psci_suspend_stress");
>> + if (IS_ERR(thread))
>> + pr_err("Failed to create kthread on CPU %d\n", cpu);
>> + else
>> + threads[nb_threads++] = thread;
>> + }
>> + if (nb_threads < 1) {
>> + kfree(threads);
>> + return -ENODEV;
>> + }
>> +
>> + atomic_set(&nb_active_threads, nb_threads);
>> +
>> + /*
>> + * Stop cpuidle to prevent the idle tasks from entering a deep sleep
>> + * mode, as it might interfere with the suspend threads on other CPUs.
>> + * This does not prevent the suspend threads from using cpuidle (only
>> + * the idle tasks check this status).
>> + */
>> + cpuidle_pause();
>> +
>> + /*
>> + * Unpark the suspend threads. To avoid the main thread being preempted
>> + * before all the threads have been unparked, the suspend threads will
>> + * wait for the completion of suspend_threads_started.
>> + */
>> + for (i = 0; i < nb_threads; ++i)
>> + kthread_unpark(threads[i]);
> Just a heads up: this doesn't work anymore, since a65d4096
> (kthread/smpboot: do not park in kthread_create_on_cpu()), in 4.9-rc1. I
> think that the unpark call could be replaced by wake_up_process. The
> comment of kthread_create_on_cpu is now misleading.
>
> Thanks,
> Jean-Philippe
>
Thanks for the heads-up! I'll rebase on 4.9-rc1 and see what needs to be done.
Thanks,
Kevin
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH 2/2] arm64/numa: fix incorrect print of end_pfn
From: Hanjun Guo @ 2016-10-20 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020125511.GG10234@leverpostej>
On 2016/10/20 20:55, Mark Rutland wrote:
> 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.
I misunderstood Will's intention, I though printing "NUMA: memory-less node 2".
so do you mean code like below?
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 34415fc..bf4e39b 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -226,8 +226,11 @@ static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
void *nd;
int tnid;
- pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n",
- nid, start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);
+ if ((end_pfn - start_pfn) != 0)
+ pr_info("Initmem setup node %d [mem %#010Lx-%#010Lx]\n", nid,
+ start_pfn << PAGE_SHIFT, (end_pfn << PAGE_SHIFT) - 1);
+ else
+ pr_info("Initmem setup node %d [<memory-less node>]\n", nid);
nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
nd = __va(nd_pa);
Thanks
Hanjun
^ permalink raw reply related
* [PATCH 2/2] pinctrl: stm32: move gpio irqs binding to optional
From: Alexandre TORGUE @ 2016-10-20 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476970012-7838-1-git-send-email-alexandre.torgue@st.com>
stm32 pinctrl driver could be probed even if no interrupt controller
is defined to manage gpio irqs. Entries related to gpio irq management
are moved to optional.
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
index f9753c4..b24583a 100644
--- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
@@ -14,11 +14,6 @@ Required properies:
- #size-cells : The value of this property must be 1
- ranges : defines mapping between pin controller node (parent) to
gpio-bank node (children).
- - interrupt-parent: phandle of the interrupt parent to which the external
- GPIO interrupts are forwarded to.
- - st,syscfg: Should be phandle/offset pair. The phandle to the syscon node
- which includes IRQ mux selection register, and the offset of the IRQ mux
- selection register.
- pins-are-numbered: Specify the subnodes are using numbered pinmux to
specify pins.
@@ -37,6 +32,11 @@ Required properties:
Optional properties:
- reset: : Reference to the reset controller
+ - interrupt-parent: phandle of the interrupt parent to which the external
+ GPIO interrupts are forwarded to.
+ - st,syscfg: Should be phandle/offset pair. The phandle to the syscon node
+ which includes IRQ mux selection register, and the offset of the IRQ mux
+ selection register.
Example:
#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] pinctrl: stm32: remove dependency with interrupt controller
From: Alexandre TORGUE @ 2016-10-20 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476970012-7838-1-git-send-email-alexandre.torgue@st.com>
This patch allows to probe stm32 pinctrl driver even if no interrupt
controller is defined to manage gpio irqs.
Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 200667f..efc4371 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -1092,9 +1092,11 @@ int stm32_pctl_probe(struct platform_device *pdev)
return -EINVAL;
}
- ret = stm32_pctrl_dt_setup_irq(pdev, pctl);
- if (ret)
- return ret;
+ if (of_find_property(np, "interrupt-parent", NULL)) {
+ ret = stm32_pctrl_dt_setup_irq(pdev, pctl);
+ if (ret)
+ return ret;
+ }
for_each_child_of_node(np, child)
if (of_property_read_bool(child, "gpio-controller"))
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] STM32 pinctrl: remove dependency between pinctrl driver and device tree
From: Alexandre TORGUE @ 2016-10-20 13:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Currently 4.9-rc1 is not booting correctly on STM32F4.
By adding gpios irqs support to stm32 pinctrl, a dependency has been
added between pinctrl stm32 and stm32f4 device tree (my mistake).
This series breaks this dependency and has to be taken on 4.9_rcs.
Regards
Alex
Alexandre TORGUE (2):
pinctrl: stm32: remove dependency with interrupt controller
pinctrl: stm32: move gpio irqs binding to optional
Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt | 10 +++++-----
drivers/pinctrl/stm32/pinctrl-stm32.c | 8 +++++---
2 files changed, 10 insertions(+), 8 deletions(-)
--
1.9.1
^ permalink raw reply
* Bunch of CRC errors in next with arm: move exports to definitions
From: Tony Lindgren @ 2016-10-20 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5893445.41LAZjK8v5@wuerfel>
* Arnd Bergmann <arnd@arndb.de> [161018 03:02]:
> On Tuesday, October 18, 2016 10:36:28 AM CEST Russell King - ARM Linux wrote:
> > On Tue, Oct 18, 2016 at 11:13:31AM +0200, Arnd Bergmann wrote:
> > > On Tuesday, October 18, 2016 6:59:44 AM CEST Sebastian Reichel wrote:
> > > > Hi,
> > > >
> > > > On Mon, Aug 22, 2016 at 09:25:13AM -0700, Tony Lindgren wrote:
> > > > > Looks like starting with next-20160818 I'm now getting close to
> > > > > 800 lines of WARNINGs on ARM with omap2plus_defconfig while doing
> > > > > make modules:
> > > > >
> > > > > Building modules, stage 2.
> > > > > MODPOST 399 modules
> > > > > WARNING: "__memzero" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > > WARNING: "memset" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > > WARNING: "memcpy" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > > WARNING: "_set_bit" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > > WARNING: "_test_and_set_bit" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > > WARNING: "_clear_bit" [sound/usb/snd-usbmidi-lib.ko] has no CRC!
> > > > > WARNING: "__aeabi_uidivmod" [sound/usb/snd-usb-audio.ko] has no CRC!
> > > > > WARNING: "_test_and_clear_bit" [sound/usb/snd-usb-audio.ko] has no CRC!
> > > > > WARNING: "arm_copy_to_user" [sound/usb/snd-usb-audio.ko] has no CRC!
> > > > > WARNING: "__aeabi_uidiv" [sound/usb/snd-usb-audio.ko] has no CRC!
> > > > > ...
> > > > > WARNING: "memset" [crypto/drbg.ko] has no CRC!
> > > > > WARNING: "memcpy" [crypto/ctr.ko] has no CRC!
> > > > > WARNING: "memcpy" [crypto/cmac.ko] has no CRC!
> > > > > WARNING: "__memzero" [crypto/cmac.ko] has no CRC!
> > > > > WARNING: "memcpy" [crypto/ccm.ko] has no CRC!
> > > > > WARNING: "__memzero" [crypto/ccm.ko] has no CRC!
> > > >
> > > > Any update on this one? I just updated my power-supply next branch
> > > > to v4.9-rc1 and now get almost 18000 CRC warnings for allmodconfig.
> > > > (I use arm-linux-gnueabihf-gcc (Debian 6.1.1-9) 6.1.1 20160705)
> > >
> > > Nick did a patch to fix this in general, and in powerpc specifically,
> > > I sent a patch yesterday to fix the ARM specific symbols.
> >
> > Did you now? You failed to _at least_ copy me on that. This is clearly
> > about core ARM code and not arm-soc stuff, you should always copy me on
> > such changes, and if I were Lee Jones, I'd insist that it was merged
> > through my tree.
>
> Right, sorry for missing the Cc, this was one of many build-time
> bugfix patches I sent out recently.
>
> Nick's patch is still under discussion on linux-arch, and my patch
> is part of that discussion, but of course you should have been
> included in the discussion as well.
For reference, that thread seems to be at:
http://lkml.org/lkml/2016/10/19/221
Tony
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 0/3] pinctrl: sunxi: Support generic pinconf functions
From: Chen-Yu Tsai @ 2016-10-20 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZHTQqnsuHcm3+iYQJc2picLu95W2OKeMiXFq+XNzDV3g@mail.gmail.com>
On Thu, Oct 20, 2016 at 9:13 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> 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?
They will, as my patches also touch the pinconf .get/.set functions.
ChenYu
>
> Yours,
> Linus Walleij
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [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
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