* Essential get_user fix missing from 3.10 aarch64
From: Willy Tarreau @ 2017-12-01 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHmME9qtH1ywCS+4ebg8myxWsAUbcqG6Rcus+Nt0DBLLaMu4wQ@mail.gmail.com>
Hi Jason,
On Fri, Dec 01, 2017 at 04:57:26PM +0100, Jason A. Donenfeld wrote:
> Not sure if there's ever going to be another stable 3.10 release, but
> if so, this would be an important one to backport.
Thanks for the heads up but unfortunately there's not going to be any
more 3.10, it's been announced as EOL soon since last January or so,
and definitely so with 3.10.108.
Your finding may interest distros still maintaining their own 3.10 though.
Thanks,
Willy
^ permalink raw reply
* [PATCH v2 18/18] perf: arm_spe: Disallow userspace profiling when arm_kernel_unmapped_at_el0()
From: Stephen Boyd @ 2017-12-01 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512059986-21325-19-git-send-email-will.deacon@arm.com>
On 11/30, Will Deacon wrote:
> When running with the kernel unmapped whilst at EL0, the virtually-addressed
> SPE buffer is also unmapped, which can lead to buffer faults if userspace
> profiling is enabled.
>
> This patch prohibits SPE profiling of userspace when
> arm_kernel_unmapped_at_el0().
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> drivers/perf/arm_spe_pmu.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
> index 8ce262fc2561..c028db8973a4 100644
> --- a/drivers/perf/arm_spe_pmu.c
> +++ b/drivers/perf/arm_spe_pmu.c
> @@ -675,6 +675,13 @@ static int arm_spe_pmu_event_init(struct perf_event *event)
> return -EOPNOTSUPP;
>
> /*
> + * If kernelspace is unmapped when running at EL0, then the SPE
> + * buffer will fault and prematurely terminate the AUX session.
> + */
> + if (arm64_kernel_unmapped_at_el0() && !attr->exclude_user)
> + dev_warn_once(&spe_pmu->pdev->dev, "unable to write to profiling buffer from EL0. Try passing \"kaiser=off\" on the kernel command line");
Missing newline on that print?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH] arm64: dts: allwinner: a64: bananapi-m64: Add LED device node
From: Chen-Yu Tsai @ 2017-12-01 16:27 UTC (permalink / raw)
To: linux-arm-kernel
The Bananapi-M64 has 3 LEDS in red, green, and blue. These are toggled
via GPIO lines, which drive transistors that control current across the
LEDS. The red LED is by default on, via an additional pull-up on the
control line. We consider this means that it is a power indicator.
So we set the "default-on" property for it.
The pingroups the GPIO lines belong to require external regulators be
enabled to be able to drive the GPIO high. These regulators also have
other purposes. However the pin controller does not have bindings for
regulators. Here we just set them to always-on.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 36 ++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 4a8d3f83a36e..a6975670cd1c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -60,6 +60,26 @@
stdout-path = "serial0:115200n8";
};
+ leds {
+ compatible = "gpio-leds";
+
+ pwr-led {
+ label = "bananapi-m64:red:pwr";
+ gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ default-state = "on";
+ };
+
+ green {
+ label = "bananapi-m64:green:user";
+ gpios = <&pio 4 14 GPIO_ACTIVE_HIGH>; /* PE14 */
+ };
+
+ blue {
+ label = "bananapi-m64:blue:user";
+ gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* PE15 */
+ };
+ };
+
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
@@ -153,6 +173,17 @@
#include "axp803.dtsi"
+®_aldo1 {
+ /*
+ * This regulator also drives the PE pingroup GPIOs,
+ * which also controls two LEDs.
+ */
+ regulator-always-on;
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-name = "afvcc-csi";
+};
+
®_aldo2 {
regulator-always-on;
regulator-min-microvolt = <1800000>;
@@ -168,6 +199,11 @@
};
®_dc1sw {
+ /*
+ * This regulator also indirectly drives the PD pingroup GPIOs,
+ * which also controls the power LED.
+ */
+ regulator-always-on;
regulator-name = "vcc-phy";
};
--
2.15.0
^ permalink raw reply related
* [PATCH v3 3/3] arm64: dts: meson-axg: add clock DT info for Meson AXG SoC
From: Stephen Boyd @ 2017-12-01 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8353c264-3253-0268-91fc-8d42fbe82611@amlogic.com>
On 11/30, Yixun Lan wrote:
> Hi Stephen
>
> On 11/30/17 03:35, Stephen Boyd wrote:
> > On 11/28, Yixun Lan wrote:
> >> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> >> index b932a784b02a..36a2e98338a8 100644
> >> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> >> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> >> @@ -7,6 +7,7 @@
> >> #include <dt-bindings/gpio/gpio.h>
> >> #include <dt-bindings/interrupt-controller/irq.h>
> >> #include <dt-bindings/interrupt-controller/arm-gic.h>
> >> +#include <dt-bindings/clock/axg-clkc.h>
> >>
> >> / {
> >> compatible = "amlogic,meson-axg";
> >> @@ -148,6 +149,20 @@
> >> #address-cells = <0>;
> >> };
> >>
> >> + hiubus: hiubus at ff63c000 {
> >
> > Maybe just call the node "bus at ff63c000"?
> >
> isn't this just a name? what's the benefits to change?
> personally, I tend to keep it this way, because it's better map to the
> data sheet
>
> we also has 'aobus', 'cbus' scattered there..
Per the ePAPR node names are supposed to be generic, like disk,
cpu, display-controller, gpu, etc. I've never heard of a hiubus,
so probably it's some vendor specific thing? We have the phandle
anyway so it's not like we're losing much information here.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 0/2] serial: stm32: fix name conflict
From: Ludovic Barre @ 2017-12-01 16:36 UTC (permalink / raw)
To: linux-arm-kernel
From: Ludovic Barre <ludovic.barre@st.com>
This patch series:
-fix name conflict, when both driver 8250/stm32-usart
are activated. Replace stm32 tty name "ttyS" by "ttySTM".
-by default add stm32 console when SERIAL_STM32 is selected.
Ludovic Barre (2):
serial: stm32: add default console
serial: stm32: fix name conflict with 8250
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/stm32-usart.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] serial: stm32: add default console
From: Ludovic Barre @ 2017-12-01 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512146211-29086-1-git-send-email-ludovic.Barre@st.com>
From: Ludovic Barre <ludovic.barre@st.com>
This patch adds by default the console support
on stm32.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/tty/serial/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index b788fee..969e598 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1664,6 +1664,7 @@ config SERIAL_STM32_CONSOLE
bool "Support for console on STM32"
depends on SERIAL_STM32=y
select SERIAL_CORE_CONSOLE
+ default y
config SERIAL_MVEBU_UART
bool "Marvell EBU serial port support"
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] serial: stm32: fix name conflict with 8250
From: Ludovic Barre @ 2017-12-01 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512146211-29086-1-git-send-email-ludovic.Barre@st.com>
From: Ludovic Barre <ludovic.barre@st.com>
This patch replaces stm32 tty name ttyS by ttySTM
to avoid a name conflict when Serial: 8250/16550 driver
is activated.
sysfs: cannot create duplicate filename '/class/tty/ttyS3'
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-12903-gb392521-dirty #1
[<c03118dc>] (unwind_backtrace) from [<c030c950>] (show_stack+0x10/0x14)
[<c030c950>] (show_stack) from [<c0d31e18>] (dump_stack+0x90/0xa4)
[<c0d31e18>] (dump_stack) from [<c03430a0>] (__warn+0xf8/0x110)
[<c03430a0>] (__warn) from [<c03430f0>] (warn_slowpath_fmt+0x38/0x48)
[<c03430f0>] (warn_slowpath_fmt) from [<c04ce574>] (sysfs_warn_dup+0x68/0x78)
[<c04ce574>] (sysfs_warn_dup) from [<c04ce824>] (sysfs_do_create_link_sd+0xb4/0xc4)
[<c04ce824>] (sysfs_do_create_link_sd) from [<c08c60ec>] (device_add+0x204/0x574)
[<c08c60ec>] (device_add) from [<c07a7ddc>] (tty_register_device_attr+0xc8/0x1bc)
[<c07a7ddc>] (tty_register_device_attr) from [<c07c6530>] (uart_add_one_port+0x22c/0x4f4)
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/tty/serial/stm32-usart.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/stm32-usart.h b/drivers/tty/serial/stm32-usart.h
index 8a5ff54..2294d0f 100644
--- a/drivers/tty/serial/stm32-usart.h
+++ b/drivers/tty/serial/stm32-usart.h
@@ -236,7 +236,7 @@ struct stm32_usart_info stm32h7_info = {
#define USART_ICR_CMCF BIT(17) /* F7 */
#define USART_ICR_WUCF BIT(20) /* H7 */
-#define STM32_SERIAL_NAME "ttyS"
+#define STM32_SERIAL_NAME "ttySTM"
#define STM32_MAX_PORTS 8
#define RX_BUF_L 200 /* dma rx buffer length */
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] clk: meson-axg: add clock controller drivers
From: Stephen Boyd @ 2017-12-01 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d2b58c06-93dc-4368-501e-4b8bdc9a4c34@amlogic.com>
On 11/30, Yixun Lan wrote:
> Hi Stephen
>
> On 11/30/17 03:34, Stephen Boyd wrote:
> > On 11/28, Yixun Lan wrote:
> >> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
> >> new file mode 100644
> >> index 000000000000..51c5b4062715
> >> --- /dev/null
> >> +++ b/drivers/clk/meson/axg.c
> >> @@ -0,0 +1,948 @@
> >> +/*
> >> + * AmLogic Meson-AXG Clock Controller Driver
> >> + *
> >> + * Copyright (c) 2016 Baylibre SAS.
> >> + * Author: Michael Turquette <mturquette@baylibre.com>
> >> + *
> >> + * Copyright (c) 2017 Amlogic, inc.
> >> + * Author: Qiufang Dai <qiufang.dai@amlogic.com>
> >> + *
> >> + * SPDX-License-Identifier: GPL-2.0+
> >> + */
> >> +
> >> +#include <linux/clk.h>
> >> +#include <linux/clk-provider.h>
> >> +#include <linux/of_address.h>
> >> +#include <linux/of_device.h>
> >> +#include <linux/platform_device.h>
> >> +#include <linux/init.h>
> >> +
> >> +#include "clkc.h"
> >> +#include "axg.h"
> >> +
> >> +static DEFINE_SPINLOCK(clk_lock);
> >
> > meson_axg_clk_lock?
> >
> em... I'd leave it unchanged
>
> because the spinlock will be used at macro MESON_GATE() [1] which
> defined at drivers/clk/meson/clkc.h, and it assume using the generic
> name 'clk_lock', change name will break the code..
>
> and besides it's already defined as static, so I see no problem here
The problem is lockdep debugging and ctags/grep on the source
code. clk_lock is very generic when it should be more specific so
we can find this lock later on from a lockdep report with a
simple search of the code.
Maybe make another patch to rename it to meson_clk_lock so the
macro doesn't have to change too much, and we get it slightly
more unique. Looks like v4l2 also has a clk_lock.
>
> >> +};
> >> +
> >> +static int axg_clkc_probe(struct platform_device *pdev)
> >> +{
> >> + const struct clkc_data *clkc_data;
> >> + void __iomem *clk_base;
> >> + int ret, clkid, i;
> >> + struct device *dev = &pdev->dev;
> >> +
> >> + clkc_data = of_device_get_match_data(&pdev->dev);
> >> + if (!clkc_data)
> >> + return -EINVAL;
> >> +
> >> + /* Generic clocks and PLLs */
> >> + clk_base = of_iomap(dev->of_node, 0);
> >
> > Use platform device APIs for ioremapping?
> >
> I assume you are referring to 'platform_get_resource +
> devm_ioremap_resource' ?
>
> the idea sounds good to me.
Yes.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 18/18] perf: arm_spe: Disallow userspace profiling when arm_kernel_unmapped_at_el0()
From: Will Deacon @ 2017-12-01 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201121505.5k2rif5hxsh4nu7f@lakrids.cambridge.arm.com>
On Fri, Dec 01, 2017 at 12:15:06PM +0000, Mark Rutland wrote:
> On Thu, Nov 30, 2017 at 04:39:46PM +0000, Will Deacon wrote:
> > When running with the kernel unmapped whilst at EL0, the virtually-addressed
> > SPE buffer is also unmapped, which can lead to buffer faults if userspace
> > profiling is enabled.
> >
> > This patch prohibits SPE profiling of userspace when
> > arm_kernel_unmapped_at_el0().
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> > drivers/perf/arm_spe_pmu.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
> > index 8ce262fc2561..c028db8973a4 100644
> > --- a/drivers/perf/arm_spe_pmu.c
> > +++ b/drivers/perf/arm_spe_pmu.c
> > @@ -675,6 +675,13 @@ static int arm_spe_pmu_event_init(struct perf_event *event)
> > return -EOPNOTSUPP;
> >
> > /*
> > + * If kernelspace is unmapped when running at EL0, then the SPE
> > + * buffer will fault and prematurely terminate the AUX session.
> > + */
> > + if (arm64_kernel_unmapped_at_el0() && !attr->exclude_user)
> > + dev_warn_once(&spe_pmu->pdev->dev, "unable to write to profiling buffer from EL0. Try passing \"kaiser=off\" on the kernel command line");
>
> The commit messages sats this prohibits profiling, but we simply log a
> message.
>
> I take it you meant to return an error code, too?
To be honest with you, I've been changing my mind a lot about what to do
here and the code has ended up being a bit of a mess after I've butchered
it repeatedly.
The fact remains that there aren't any SPE-capable CPUs shipping at the
moment, so I'm inclined just to fail the probe for now and we can look
at whether or not we can do better when we've got some hardware to play
with.
And I'll add the missing newline.
Thanks,
Will
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: meson-axg: add clock DT info for Meson AXG SoC
From: Jerome Brunet @ 2017-12-01 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201163437.GE19419@codeaurora.org>
On Fri, 2017-12-01 at 08:34 -0800, Stephen Boyd wrote:
> On 11/30, Yixun Lan wrote:
> > Hi Stephen
> >
> > On 11/30/17 03:35, Stephen Boyd wrote:
> > > On 11/28, Yixun Lan wrote:
> > > > diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > > > b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > > > index b932a784b02a..36a2e98338a8 100644
> > > > --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > > > +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> > > > @@ -7,6 +7,7 @@
> > > > #include <dt-bindings/gpio/gpio.h>
> > > > #include <dt-bindings/interrupt-controller/irq.h>
> > > > #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > +#include <dt-bindings/clock/axg-clkc.h>
> > > >
> > > > / {
> > > > compatible = "amlogic,meson-axg";
> > > > @@ -148,6 +149,20 @@
> > > > #address-cells = <0>;
> > > > };
> > > >
> > > > + hiubus: hiubus at ff63c000 {
> > >
> > > Maybe just call the node "bus at ff63c000"?
> > >
> >
> > isn't this just a name? what's the benefits to change?
> > personally, I tend to keep it this way, because it's better map to the
> > data sheet
> >
> > we also has 'aobus', 'cbus' scattered there..
>
> Per the ePAPR node names are supposed to be generic, like disk,
> cpu, display-controller, gpu, etc. I've never heard of a hiubus,
> so probably it's some vendor specific thing? We have the phandle
> anyway so it's not like we're losing much information here.
Stephen, there is a lot of busses on platform. We can't just call them all
'bus'.
I don't get the problem with this name.
We are re-using the name from the datasheet here, no fancy invention. It seems
to be quite common.
>
^ permalink raw reply
* [PATCH RT] arm*: disable NEON in kernel mode
From: Peter Zijlstra @ 2017-12-01 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201143648.GK1612@linutronix.de>
On Fri, Dec 01, 2017 at 03:36:48PM +0100, Sebastian Andrzej Siewior wrote:
> On 2017-12-01 14:18:28 [+0000], Mark Rutland wrote:
> > [Adding Ard, who wrote the NEON crypto code]
> >
> > On Fri, Dec 01, 2017 at 02:45:06PM +0100, Sebastian Andrzej Siewior wrote:
> > > +arm folks, to let you know
> > >
> > > On 2017-12-01 11:43:32 [+0100], To linux-rt-users at vger.kernel.org wrote:
> > > > NEON in kernel mode is used by the crypto algorithms and raid6 code.
> > > > While the raid6 code looks okay, the crypto algorithms do not: NEON
> > > > is enabled on first invocation and may allocate/free/map memory before
> > > > the NEON mode is disabled again.
> >
> > Could you elaborate on why this is a problem?
> >
> > I guess this is because kernel_neon_{begin,end}() disable preemption?
> >
> > ... is this specific to RT?
>
> It is RT specific, yes. One thing are the unbounded latencies since
> everything in this preempt_disable section can take time depending on
> the size of the request.
Well, PREEMPT cares about that too.
^ permalink raw reply
* [PATCH 2/4] gpiolib: add bitmask for valid GPIO lines
From: Timur Tabi @ 2017-12-01 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <68a11ee4-d0c6-0f4e-3631-125cc4e7a1bd@codeaurora.org>
On 12/01/2017 05:38 AM, Archit Taneja wrote:
>
> We're hitting an issue here ^ when a consumer calls the devm_gpiod_get()
> API. This API
> internally sets idx in gpiod_get_index to always 0. For example, in the
> call sequence
> below, the idx argument to gpiochip_irqchip_line_valid is always 0:
>
> devm_gpiod_get(dev, con_id, flags)
> ?? devm_gpiod_get_index(dev, con_id, 0, flags)
> ????? gpiod_get_index(dev, con_id, 0, flags)
> ???????? if (!gpiochip_irqchip_line_valid(desc->gdev->chip, 0))
> ???????????? return ERR_PTR(-EACCES);
>
> Therefore, with these patches, if we create a sparse gpio map, and the
> 0th gpio is set to "not accessible", all gpio requests end up failing
> with EACCESS
> because idx is always passed as 0.
Ok, I can see the problem, but I don't know how to fix it.
struct gpio_desc *__must_check devm_gpiod_get(struct device *dev,
const char *con_id,
enum gpiod_flags flags)
{
return devm_gpiod_get_index(dev, con_id, 0, flags);
}
I thought that by putting the check for "availability" inside of the
GPIO request, it would handle all situations where a client (whether
kernel or user-space) tries to access a specific GPIO.
However, this doesn't work with [devm_]gpiod_get. This function
attempts to claim the entire GPIO block by claiming only the first GPIO.
This is straining my understanding of gpiolib. Maybe we need to do
something like this:
struct gpio_desc *__must_check gpiod_get(struct device *dev, const char
*con_id,
enum gpiod_flags flags)
{
return gpiod_get_index(dev, con_id, -1, flags);
}
Where idx == -1 is a special-case for gpiod_get_index() where it returns
the gpio_desc without actually requesting it?
> In gpiochip_irqchip_line_valid, shouldn't we test the nth bit (that
> corresponds to
> this gpio_desc) in chip->line_valid_mask instead of idx passed above,
> which is always
> 0?
The code has changed upstream, so I need to refactor that function. But
I think it's already testing the nth bit:
static bool gpiochip_irqchip_line_valid(const struct gpio_chip gpiochip,
unsigned int offset)
{
/* No mask means all valid */
if (likely(!gpiochip->line_valid_mask))
return true;
return test_bit(offset, gpiochip->line_valid_mask);
'offset' is the nth bit.
--
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 0/4] Fixes for omapdrm on OpenPandora and GTA04
From: Bartlomiej Zolnierkiewicz @ 2017-12-01 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <27b12bc8-2c3a-6caa-c800-158b75f80d3f@ti.com>
On Thursday, November 30, 2017 12:54:07 PM Tomi Valkeinen wrote:
> On 28/11/17 17:48, H. Nikolaus Schaller wrote:
> > Changes V3:
> > * stay compatible with old DTB files which still use "toppoly" (suggested by Tomi Valkeinen)
> > * replaced MODULE_ALIAS entries by MODULE_DEVICE_TABLE (suggested by Andrew F. Davis)
> > * removed DSI VDDS patch as it has already been accepted
> >
> > 2017-11-16 09:50:22: Changes V2:
> > * replaced patch to fix DSI VDDS for OMAP3 by equivalent patch from Laurent Pinchart
> > * keep previous compatibility option in panel driver to handle older device tree binaries
> >
> > 2017-11-08 22:09:36:
> > This patch set fixes vendor names of the panels
> > and fixes a problem on omapdrm with enabling
> > VDD_DSI for OMAP3 which is needed for displaying
> > the Red and Green channel on OMAP3530 (Pandora).
> >
> > H. Nikolaus Schaller (4):
> > omapdrm: panel: fix compatible vendor string for td028ttec1
> > omapdrm: panel: td028ttec1: replace MODULE_ALIAS by
> > MODULE_DEVICE_TABLE
> > DTS: GTA04: fix panel compatibility string
> > DTS: Pandora: fix panel compatibility string
> >
> > .../panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} | 4 ++--
> > arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
> > arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
> > drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 13 ++++++++++++-
> > .../fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c | 12 +++++++++++-
> > 5 files changed, 27 insertions(+), 6 deletions(-)
> > rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt} (84%)
> >
>
> Thanks. I have picked up patches 1 and 2.
Thanks for taking care of them (they both look fine to me).
> 3 can be applied when 1 & 2 are in. The change in 4 could be applied
> independently, but it conflicts with 3.
>
> Tony, how do you want to handle 3 and 4? I will push 1 and 2 to v4.16. I
> don't think they are real issues, so I don't see a reason to push them
> as fixes to v4.15. I think they are mostly just cleanups, and we might
> as well wait until v4.17, but that's quite far away...
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH] arm64: mm: Fix pte_mkclean, pte_mkdirty semantics
From: Steve Capper @ 2017-12-01 17:22 UTC (permalink / raw)
To: linux-arm-kernel
On systems with hardware dirty bit management, the ltp madvise09 unit
test fails due to dirty bit information being lost and pages being
incorrectly freed.
This was bisected to:
arm64: Ignore hardware dirty bit updates in ptep_set_wrprotect()
Reverting this commit leads to a separate problem, that the unit test
retains pages that should have been dropped due to the function
madvise_free_pte_range(.) not cleaning pte's properly.
Currently pte_mkclean only clears the software dirty bit, thus the
following code sequence can appear:
pte = pte_mkclean(pte);
if (pte_dirty(pte))
// this condition can return true with HW DBM!
This patch also adjusts pte_mkclean to set PTE_RDONLY thus effectively
clearing both the SW and HW dirty information.
In order for this to function on systems without HW DBM, we need to
also adjust pte_mkdirty to remove the read only bit from writable pte's
to avoid infinite fault loops.
Reported-by: Bhupinder Thakur <bhupinder.thakur@linaro.org>
Fixes: 64c26841b349 ("arm64: Ignore hardware dirty bit updates in
ptep_set_wrprotect()")
Signed-off-by: Steve Capper <steve.capper@arm.com>
---
arch/arm64/include/asm/pgtable.h | 33 ++++++++++++++++++---------------
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index b46e54c2399b..0fa7305765ab 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -135,12 +135,20 @@ static inline pte_t pte_mkwrite(pte_t pte)
static inline pte_t pte_mkclean(pte_t pte)
{
- return clear_pte_bit(pte, __pgprot(PTE_DIRTY));
+ pte = clear_pte_bit(pte, __pgprot(PTE_DIRTY));
+ pte = set_pte_bit(pte, __pgprot(PTE_RDONLY));
+
+ return pte;
}
static inline pte_t pte_mkdirty(pte_t pte)
{
- return set_pte_bit(pte, __pgprot(PTE_DIRTY));
+ pte = set_pte_bit(pte, __pgprot(PTE_DIRTY));
+
+ if (pte_write(pte))
+ pte = clear_pte_bit(pte, __pgprot(PTE_RDONLY));
+
+ return pte;
}
static inline pte_t pte_mkold(pte_t pte)
@@ -628,28 +636,23 @@ static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
/*
- * ptep_set_wrprotect - mark read-only while preserving the hardware update of
- * the Access Flag.
+ * ptep_set_wrprotect - mark read-only while trasferring potential hardware
+ * dirty status (PTE_DBM && !PTE_RDONLY) to the software PTE_DIRTY bit.
*/
#define __HAVE_ARCH_PTEP_SET_WRPROTECT
static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long address, pte_t *ptep)
{
pte_t old_pte, pte;
- /*
- * ptep_set_wrprotect() is only called on CoW mappings which are
- * private (!VM_SHARED) with the pte either read-only (!PTE_WRITE &&
- * PTE_RDONLY) or writable and software-dirty (PTE_WRITE &&
- * !PTE_RDONLY && PTE_DIRTY); see is_cow_mapping() and
- * protection_map[]. There is no race with the hardware update of the
- * dirty state: clearing of PTE_RDONLY when PTE_WRITE (a.k.a. PTE_DBM)
- * is set.
- */
- VM_WARN_ONCE(pte_write(*ptep) && !pte_dirty(*ptep),
- "%s: potential race with hardware DBM", __func__);
pte = READ_ONCE(*ptep);
do {
old_pte = pte;
+ /*
+ * If hardware-dirty (PTE_WRITE/DBM bit set and PTE_RDONLY
+ * clear), set the PTE_DIRTY bit.
+ */
+ if (pte_hw_dirty(pte))
+ pte = pte_mkdirty(pte);
pte = pte_wrprotect(pte);
pte_val(pte) = cmpxchg_relaxed(&pte_val(*ptep),
pte_val(old_pte), pte_val(pte));
--
2.11.0
^ permalink raw reply related
* [PATCH 09/37] KVM: arm64: Move debug dirty flag calculation out of world switch
From: Christoffer Dall @ 2017-12-01 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171107140919.p6act55ubmzlv66b@kamzik.brq.redhat.com>
On Tue, Nov 07, 2017 at 03:09:19PM +0100, Andrew Jones wrote:
> On Thu, Oct 12, 2017 at 12:41:13PM +0200, Christoffer Dall wrote:
> > There is no need to figure out inside the world-switch if we should
> > save/restore the debug registers or not, we can might as well do that in
> > the higher level debug setup code, making it easier to optimize down the
> > line.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > arch/arm64/kvm/debug.c | 9 +++++++++
> > arch/arm64/kvm/hyp/debug-sr.c | 6 ------
> > 2 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> > index dbadfaf..62550de19 100644
> > --- a/arch/arm64/kvm/debug.c
> > +++ b/arch/arm64/kvm/debug.c
> > @@ -193,6 +193,15 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
> > if (trap_debug)
> > vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA;
> >
> > + /*
> > + * If any of KDE, MDE or KVM_ARM64_DEBUG_DIRTY is set, perform
> > + * a full save/restore cycle.
>
> The commit message implies testing KVM_ARM64_DEBUG_DIRTY, but it only
> tests KDE and MDE.
>
You meant the comment, right?
> > + */
> > + if ((vcpu_sys_reg(vcpu, MDSCR_EL1) & DBG_MDSCR_KDE) ||
> > + (vcpu_sys_reg(vcpu, MDSCR_EL1) & DBG_MDSCR_MDE))
>
> nit: could also write as
>
> if (vcpu_sys_reg(vcpu, MDSCR_EL1) & (DBG_MDSCR_KDE | DBG_MDSCR_MDE))
>
I actually prefer it the other way, and I think the compiler will figure
out what to do in terms of efficiency.
> > + vcpu->arch.debug_flags |= KVM_ARM64_DEBUG_DIRTY;
> > +
>
> It looks like there's only one flag for debug_flags - this dirty flag,
> which I guess is also used to trigger trapping. So maybe this could be a
> second flag of a "lazy state" field, as I suggested earlier?
>
I'm going to leave this one for now, but we can improve that later on if
we want to save a little space in the vcpu struct, or rather if we want
to rearrange things to make frequently accessed fields fit in the same
cache line.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH RT] arm*: disable NEON in kernel mode
From: Russell King - ARM Linux @ 2017-12-01 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201171458.3a2acsltiq54gvuu@hirez.programming.kicks-ass.net>
On Fri, Dec 01, 2017 at 06:14:58PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 01, 2017 at 03:36:48PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2017-12-01 14:18:28 [+0000], Mark Rutland wrote:
> > > [Adding Ard, who wrote the NEON crypto code]
> > >
> > > On Fri, Dec 01, 2017 at 02:45:06PM +0100, Sebastian Andrzej Siewior wrote:
> > > > +arm folks, to let you know
> > > >
> > > > On 2017-12-01 11:43:32 [+0100], To linux-rt-users at vger.kernel.org wrote:
> > > > > NEON in kernel mode is used by the crypto algorithms and raid6 code.
> > > > > While the raid6 code looks okay, the crypto algorithms do not: NEON
> > > > > is enabled on first invocation and may allocate/free/map memory before
> > > > > the NEON mode is disabled again.
> > >
> > > Could you elaborate on why this is a problem?
> > >
> > > I guess this is because kernel_neon_{begin,end}() disable preemption?
> > >
> > > ... is this specific to RT?
> >
> > It is RT specific, yes. One thing are the unbounded latencies since
> > everything in this preempt_disable section can take time depending on
> > the size of the request.
>
> Well, PREEMPT cares about that too.
Preempt may care, but it's the hit you take to use neon in the kernel.
The neon register set shares with the FPU, so preempting during that
path means that the normal FPU register saving would corrupt the
already saved user FPU context - and even worse would result in the
kernel's crypto function register contents being leaked to userspace.
If you care about preempt deeply, the only solution is to avoid using
kernel mode neon.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [clk:clk-next 9/11] include/linux/clk.h:637:1: error: expected identifier or '(' before '{' token
From: kbuild test robot @ 2017-12-01 17:37 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
head: 20697052ae1dc0aad45f72eaed791edb7579ee4f
commit: b833533133b209e89f4d652e0c7f001adda81f96 [9/11] clk: add clk_rate_exclusive api
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b833533133b209e89f4d652e0c7f001adda81f96
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All error/warnings (new ones prefixed by >>):
In file included from drivers/media/platform/qcom/camss-8x16/camss.c:18:0:
include/linux/clk.h: In function 'clk_exclusive_get':
>> include/linux/clk.h:636:44: warning: no return statement in function returning non-void [-Wreturn-type]
static inline int clk_exclusive_get(struct clk *clk) {}
^~~
include/linux/clk.h: At top level:
>> include/linux/clk.h:637:1: error: expected identifier or '(' before '{' token
{
^
--
In file included from drivers//net/ethernet/hisilicon/hix5hd2_gmac.c:18:0:
include/linux/clk.h: In function 'clk_exclusive_get':
>> include/linux/clk.h:636:44: warning: no return statement in function returning non-void [-Wreturn-type]
static inline int clk_exclusive_get(struct clk *clk) {}
^~~
include/linux/clk.h: At top level:
>> include/linux/clk.h:637:1: error: expected identifier or '(' before '{' token
{
^
drivers//net/ethernet/hisilicon/hix5hd2_gmac.c:26:0: warning: "PORT_EN" redefined
#define PORT_EN 0x0044
In file included from arch/blackfin/mach-bf533/include/mach/blackfin.h:16:0,
from arch/blackfin/include/asm/irqflags.h:11,
from include/linux/irqflags.h:16,
from arch/blackfin/include/asm/bitops.h:33,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers//net/ethernet/hisilicon/hix5hd2_gmac.c:10:
arch/blackfin/mach-bf533/include/mach/defBF532.h:431:0: note: this is the location of the previous definition
#define PORT_EN 0x00000001 /* PPI Port Enable */
--
In file included from drivers/usb/musb/ux500.c:11:0:
include/linux/clk.h: In function 'clk_exclusive_get':
>> include/linux/clk.h:636:44: warning: no return statement in function returning non-void [-Wreturn-type]
static inline int clk_exclusive_get(struct clk *clk) {}
^~~
include/linux/clk.h: At top level:
>> include/linux/clk.h:637:1: error: expected identifier or '(' before '{' token
{
^
In file included from drivers/usb/musb/musb_core.h:439:0,
from drivers/usb/musb/ux500.c:18:
drivers/usb/musb/ux500.c: In function 'ux500_musb_set_vbus':
drivers/usb/musb/musb_regs.h:443:33: error: 'USB_OTG_DEV_CTL' undeclared (first use in this function)
#define MUSB_DEVCTL USB_OFFSET(USB_OTG_DEV_CTL) /* 8 bit */
^
drivers/usb/musb/musb_regs.h:422:27: note: in definition of macro 'USB_OFFSET'
#define USB_OFFSET(reg) (reg - USB_BASE)
^~~
drivers/usb/musb/ux500.c:43:35: note: in expansion of macro 'MUSB_DEVCTL'
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
^~~~~~~~~~~
drivers/usb/musb/musb_regs.h:443:33: note: each undeclared identifier is reported only once for each function it appears in
#define MUSB_DEVCTL USB_OFFSET(USB_OTG_DEV_CTL) /* 8 bit */
^
drivers/usb/musb/musb_regs.h:422:27: note: in definition of macro 'USB_OFFSET'
#define USB_OFFSET(reg) (reg - USB_BASE)
^~~
drivers/usb/musb/ux500.c:43:35: note: in expansion of macro 'MUSB_DEVCTL'
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
^~~~~~~~~~~
drivers/usb/musb/musb_regs.h:421:19: error: 'USB_FADDR' undeclared (first use in this function)
#define USB_BASE USB_FADDR
^
drivers/usb/musb/musb_regs.h:422:33: note: in expansion of macro 'USB_BASE'
#define USB_OFFSET(reg) (reg - USB_BASE)
^~~~~~~~
drivers/usb/musb/musb_regs.h:443:22: note: in expansion of macro 'USB_OFFSET'
#define MUSB_DEVCTL USB_OFFSET(USB_OTG_DEV_CTL) /* 8 bit */
^~~~~~~~~~
drivers/usb/musb/ux500.c:43:35: note: in expansion of macro 'MUSB_DEVCTL'
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
^~~~~~~~~~~
drivers/usb/musb/ux500.c: In function 'ux500_musb_interrupt':
drivers/usb/musb/musb_regs.h:433:34: error: 'USB_INTRUSB' undeclared (first use in this function)
#define MUSB_INTRUSB USB_OFFSET(USB_INTRUSB) /* 8 bit */
^
drivers/usb/musb/musb_regs.h:422:27: note: in definition of macro 'USB_OFFSET'
#define USB_OFFSET(reg) (reg - USB_BASE)
^~~
drivers/usb/musb/ux500.c:134:42: note: in expansion of macro 'MUSB_INTRUSB'
musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB);
^~~~~~~~~~~~
drivers/usb/musb/musb_regs.h:421:19: error: 'USB_FADDR' undeclared (first use in this function)
#define USB_BASE USB_FADDR
^
drivers/usb/musb/musb_regs.h:422:33: note: in expansion of macro 'USB_BASE'
#define USB_OFFSET(reg) (reg - USB_BASE)
^~~~~~~~
drivers/usb/musb/musb_regs.h:433:23: note: in expansion of macro 'USB_OFFSET'
#define MUSB_INTRUSB USB_OFFSET(USB_INTRUSB) /* 8 bit */
^~~~~~~~~~
drivers/usb/musb/ux500.c:134:42: note: in expansion of macro 'MUSB_INTRUSB'
musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB);
^~~~~~~~~~~~
drivers/usb/musb/musb_regs.h:429:33: error: 'USB_INTRTX' undeclared (first use in this function)
#define MUSB_INTRTX USB_OFFSET(USB_INTRTX) /* 16-bit */
^
drivers/usb/musb/musb_regs.h:422:27: note: in definition of macro 'USB_OFFSET'
#define USB_OFFSET(reg) (reg - USB_BASE)
^~~
drivers/usb/musb/ux500.c:135:41: note: in expansion of macro 'MUSB_INTRTX'
musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX);
^~~~~~~~~~~
drivers/usb/musb/musb_regs.h:430:33: error: 'USB_INTRRX' undeclared (first use in this function)
#define MUSB_INTRRX USB_OFFSET(USB_INTRRX)
^
drivers/usb/musb/musb_regs.h:422:27: note: in definition of macro 'USB_OFFSET'
#define USB_OFFSET(reg) (reg - USB_BASE)
^~~
drivers/usb/musb/ux500.c:136:41: note: in expansion of macro 'MUSB_INTRRX'
musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX);
^~~~~~~~~~~
--
In file included from drivers/net/ethernet/hisilicon/hix5hd2_gmac.c:18:0:
include/linux/clk.h: In function 'clk_exclusive_get':
>> include/linux/clk.h:636:44: warning: no return statement in function returning non-void [-Wreturn-type]
static inline int clk_exclusive_get(struct clk *clk) {}
^~~
include/linux/clk.h: At top level:
>> include/linux/clk.h:637:1: error: expected identifier or '(' before '{' token
{
^
drivers/net/ethernet/hisilicon/hix5hd2_gmac.c:26:0: warning: "PORT_EN" redefined
#define PORT_EN 0x0044
In file included from arch/blackfin/mach-bf533/include/mach/blackfin.h:16:0,
from arch/blackfin/include/asm/irqflags.h:11,
from include/linux/irqflags.h:16,
from arch/blackfin/include/asm/bitops.h:33,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/net/ethernet/hisilicon/hix5hd2_gmac.c:10:
arch/blackfin/mach-bf533/include/mach/defBF532.h:431:0: note: this is the location of the previous definition
#define PORT_EN 0x00000001 /* PPI Port Enable */
--
In file included from drivers/clocksource/timer-oxnas-rps.c:26:0:
include/linux/clk.h: In function 'clk_exclusive_get':
>> include/linux/clk.h:636:44: warning: no return statement in function returning non-void [-Wreturn-type]
static inline int clk_exclusive_get(struct clk *clk) {}
^~~
include/linux/clk.h: At top level:
>> include/linux/clk.h:637:1: error: expected identifier or '(' before '{' token
{
^
drivers/clocksource/timer-oxnas-rps.c:50:0: warning: "TIMER_ENABLE" redefined
#define TIMER_ENABLE BIT(7)
In file included from arch/blackfin/mach-bf533/include/mach/blackfin.h:16:0,
from arch/blackfin/include/asm/irqflags.h:11,
from include/linux/irqflags.h:16,
from arch/blackfin/include/asm/bitops.h:33,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/smp.h:12,
from include/linux/irq.h:13,
from drivers/clocksource/timer-oxnas-rps.c:24:
arch/blackfin/mach-bf533/include/mach/defBF532.h:97:0: note: this is the location of the previous definition
#define TIMER_ENABLE 0xFFC00640 /* Timer Enable Register */
--
In file included from drivers//clocksource/timer-oxnas-rps.c:26:0:
include/linux/clk.h: In function 'clk_exclusive_get':
>> include/linux/clk.h:636:44: warning: no return statement in function returning non-void [-Wreturn-type]
static inline int clk_exclusive_get(struct clk *clk) {}
^~~
include/linux/clk.h: At top level:
>> include/linux/clk.h:637:1: error: expected identifier or '(' before '{' token
{
^
drivers//clocksource/timer-oxnas-rps.c:50:0: warning: "TIMER_ENABLE" redefined
#define TIMER_ENABLE BIT(7)
In file included from arch/blackfin/mach-bf533/include/mach/blackfin.h:16:0,
from arch/blackfin/include/asm/irqflags.h:11,
from include/linux/irqflags.h:16,
from arch/blackfin/include/asm/bitops.h:33,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/smp.h:12,
from include/linux/irq.h:13,
from drivers//clocksource/timer-oxnas-rps.c:24:
arch/blackfin/mach-bf533/include/mach/defBF532.h:97:0: note: this is the location of the previous definition
#define TIMER_ENABLE 0xFFC00640 /* Timer Enable Register */
--
In file included from drivers/media/i2c/tc358743.c:32:0:
include/linux/clk.h: In function 'clk_exclusive_get':
>> include/linux/clk.h:636:44: warning: no return statement in function returning non-void [-Wreturn-type]
static inline int clk_exclusive_get(struct clk *clk) {}
^~~
include/linux/clk.h: At top level:
>> include/linux/clk.h:637:1: error: expected identifier or '(' before '{' token
{
^
In file included from drivers/media/i2c/tc358743.c:50:0:
drivers/media/i2c/tc358743_regs.h:32:0: warning: "CHIPID" redefined
#define CHIPID 0x0000
In file included from arch/blackfin/mach-bf533/include/mach/blackfin.h:16:0,
from arch/blackfin/include/asm/irqflags.h:11,
from include/linux/irqflags.h:16,
from arch/blackfin/include/asm/bitops.h:33,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from drivers/media/i2c/tc358743.c:28:
arch/blackfin/mach-bf533/include/mach/defBF532.h:22:0: note: this is the location of the previous definition
#define CHIPID 0xFFC00014 /* Chip ID Register */
--
In file included from drivers/rtc/rtc-xgene.c:29:0:
include/linux/clk.h: In function 'clk_exclusive_get':
>> include/linux/clk.h:636:44: warning: no return statement in function returning non-void [-Wreturn-type]
static inline int clk_exclusive_get(struct clk *clk) {}
^~~
include/linux/clk.h: At top level:
>> include/linux/clk.h:637:1: error: expected identifier or '(' before '{' token
{
^
drivers/rtc/rtc-xgene.c:42:0: warning: "RTC_STAT" redefined
#define RTC_STAT 0x10
In file included from arch/blackfin/mach-bf533/include/mach/blackfin.h:16:0,
from arch/blackfin/include/asm/irqflags.h:11,
from include/linux/irqflags.h:16,
from arch/blackfin/include/asm/bitops.h:33,
from include/linux/bitops.h:38,
from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/rtc/rtc-xgene.c:24:
arch/blackfin/mach-bf533/include/mach/defBF532.h:41:0: note: this is the location of the previous definition
#define RTC_STAT 0xFFC00300 /* RTC Status Register */
vim +637 include/linux/clk.h
634
635
> 636 static inline int clk_exclusive_get(struct clk *clk) {}
> 637 {
638 return 0;
639 }
640
---
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: 46936 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171202/ddc81e38/attachment-0001.gz>
^ permalink raw reply
* [PATCH RT] arm*: disable NEON in kernel mode
From: Peter Zijlstra @ 2017-12-01 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201173120.GL10595@n2100.armlinux.org.uk>
On Fri, Dec 01, 2017 at 05:31:20PM +0000, Russell King - ARM Linux wrote:
> On Fri, Dec 01, 2017 at 06:14:58PM +0100, Peter Zijlstra wrote:
> > Well, PREEMPT cares about that too.
>
> Preempt may care, but it's the hit you take to use neon in the kernel.
> The neon register set shares with the FPU, so preempting during that
> path means that the normal FPU register saving would corrupt the
> already saved user FPU context - and even worse would result in the
> kernel's crypto function register contents being leaked to userspace.
Same thing on x86.
> If you care about preempt deeply, the only solution is to avoid using
> kernel mode neon.
Not quite, you can write the code such that it drops out of neon mode
regularly to allow preemption.
So setup a crypto block, enter neon, transform the block, drop out of
neon, rinse repeat.
^ permalink raw reply
* [PATCH v2 13/18] arm64: entry: Hook up entry trampoline to exception vectors
From: Will Deacon @ 2017-12-01 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201135300.novwsr5yxveeeq7m@lakrids.cambridge.arm.com>
On Fri, Dec 01, 2017 at 01:53:01PM +0000, Mark Rutland wrote:
> On Thu, Nov 30, 2017 at 04:39:41PM +0000, Will Deacon wrote:
> > .macro kernel_ventry, el, label, regsize = 64
> > .align 7
> > +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> > + .if \el == 0
> > + .if \regsize == 64
> > + mrs x30, tpidrro_el0
> > + msr tpidrro_el0, xzr
> > + .else
> > + mov x30, xzr
>
> I guess that's just to prevent acccidental leaks if we dump registers
> somewhere, since we used x30 as a scratch register?
Indeed. I don't have a concrete example, but I was worried about things
like perf and ptrace, which might allow you to get at the AArch64 register
state for a compat task so it felt like a good idea to zero this.
Will
^ permalink raw reply
* [PATCH v6 00/13] Add STM32 DFSDM support
From: Arnaud Pouliquen @ 2017-12-01 17:40 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Here is a new version to fix kbuild test warnings
Main deltas V6 vs V5:
- Fix warning reported by kbuild test in :
include/linux/iio/consumer.h
sound/soc/stm/stm32_adfsdm.c
Main deltas V5 vs V4:
- Integrate ASOC DAI as a subnode of the DFSDM.
- Add in kernel consumer interface to allow to manipulate attribute.
Context reminder:
-----------------
DFSDM peripheral is a peripheral that allows to connect some sigma delta ADCs
or PDM microphones via a SPI or Manchester bus.
DFSDM integrates digital filters to offer up to 24 bits final resolution.
In term of SW architecture. 2 use-cases have to be supported:
1) Sigma delta ADC conversion through IIO framework.
Sigma delta ADC is handled by generic sigma delta modulator driver.
DFSDM peripheral is binded to a SD modulator ADC using the IIO HW consumer interface.
Please notice that IIO HW consumer interface has be proposed by Lars, but is
part of this patchset with Lars's agreement.
User interface is IIO one.
Notice that this patch-set propose only a raw conversion, to simplify review.
Buffer and trigger management will be added in next patch-sets.
2) PDM microphone record through ALSA framework.
PDM microphone is handled by ASOC Generic DMIC codec driver.
ADFSDM ASOC DAI driver is binded to IIO driver using the IIO consumer interface
ADFSDM ASOC DAI driver is binded to a PDM microphone ASOC component using ASOC Of_graph.
User interface is ALSA one.
As IIO DMA management is not adapted to an audio realtime stream. A specific DMA
management has been implemented in IIO driver for audio purposes.
Regards,
Arnaud
Arnaud Pouliquen (12):
docs: driver-api: add iio hw consumer section
IIO: hw_consumer: add devm_iio_hw_consumer_alloc
IIO: inkern: API for manipulating channel attributes
IIO: Add DT bindings for sigma delta adc modulator
IIO: ADC: add sigma delta modulator support
IIO: add DT bindings for stm32 DFSDM filter
IIO: ADC: add stm32 DFSDM core support
IIO: ADC: add STM32 DFSDM sigma delta ADC support
IIO: ADC: add stm32 DFSDM support for PDM microphone
IIO: consumer: allow to set buffer sizes
ASoC: add bindings for stm32 DFSDM filter
ASoC: stm32: add DFSDM DAI support
Lars-Peter Clausen (1):
iio: Add hardware consumer buffer support
.../ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 | 16 +
.../bindings/iio/adc/sigma-delta-modulator.txt | 13 +
.../bindings/iio/adc/st,stm32-dfsdm-adc.txt | 127 ++
.../devicetree/bindings/sound/st,stm32-adfsdm.txt | 62 +
Documentation/driver-api/iio/hw-consumer.rst | 51 +
Documentation/driver-api/iio/index.rst | 1 +
drivers/iio/adc/Kconfig | 37 +
drivers/iio/adc/Makefile | 3 +
drivers/iio/adc/sd_adc_modulator.c | 81 ++
drivers/iio/adc/stm32-dfsdm-adc.c | 1232 ++++++++++++++++++++
drivers/iio/adc/stm32-dfsdm-core.c | 318 +++++
drivers/iio/adc/stm32-dfsdm.h | 319 +++++
drivers/iio/buffer/Kconfig | 10 +
drivers/iio/buffer/Makefile | 1 +
drivers/iio/buffer/industrialio-buffer-cb.c | 11 +
drivers/iio/buffer/industrialio-hw-consumer.c | 248 ++++
drivers/iio/inkern.c | 18 +-
include/linux/iio/adc/stm32-dfsdm-adc.h | 28 +
include/linux/iio/consumer.h | 39 +-
include/linux/iio/hw-consumer.h | 22 +
sound/soc/stm/Kconfig | 11 +
sound/soc/stm/Makefile | 3 +
sound/soc/stm/stm32_adfsdm.c | 386 ++++++
23 files changed, 3031 insertions(+), 6 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
create mode 100644 Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt
create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.txt
create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt
create mode 100644 Documentation/driver-api/iio/hw-consumer.rst
create mode 100644 drivers/iio/adc/sd_adc_modulator.c
create mode 100644 drivers/iio/adc/stm32-dfsdm-adc.c
create mode 100644 drivers/iio/adc/stm32-dfsdm-core.c
create mode 100644 drivers/iio/adc/stm32-dfsdm.h
create mode 100644 drivers/iio/buffer/industrialio-hw-consumer.c
create mode 100644 include/linux/iio/adc/stm32-dfsdm-adc.h
create mode 100644 include/linux/iio/hw-consumer.h
create mode 100644 sound/soc/stm/stm32_adfsdm.c
--
2.7.4
^ permalink raw reply
* [PATCH v6 01/13] iio: Add hardware consumer buffer support
From: Arnaud Pouliquen @ 2017-12-01 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512150020-20335-1-git-send-email-arnaud.pouliquen@st.com>
From: Lars-Peter Clausen <lars@metafoo.de>
Hardware consumer interface can be used when one IIO device has
a direct connection to another device in hardware.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
---
drivers/iio/buffer/Kconfig | 10 ++
drivers/iio/buffer/Makefile | 1 +
drivers/iio/buffer/industrialio-hw-consumer.c | 182 ++++++++++++++++++++++++++
include/linux/iio/hw-consumer.h | 20 +++
4 files changed, 213 insertions(+)
create mode 100644 drivers/iio/buffer/industrialio-hw-consumer.c
create mode 100644 include/linux/iio/hw-consumer.h
diff --git a/drivers/iio/buffer/Kconfig b/drivers/iio/buffer/Kconfig
index 4ffd3db..338774c 100644
--- a/drivers/iio/buffer/Kconfig
+++ b/drivers/iio/buffer/Kconfig
@@ -29,6 +29,16 @@ config IIO_BUFFER_DMAENGINE
Should be selected by drivers that want to use this functionality.
+config IIO_BUFFER_HW_CONSUMER
+ tristate "Industrial I/O HW buffering"
+ help
+ Provides a way to bonding when an IIO device has a direct connection
+ to another device in hardware. In this case buffers for data transfers
+ are handled by hardware.
+
+ Should be selected by drivers that want to use the generic Hw consumer
+ interface.
+
config IIO_KFIFO_BUF
tristate "Industrial I/O buffering based on kfifo"
help
diff --git a/drivers/iio/buffer/Makefile b/drivers/iio/buffer/Makefile
index 85beaae..324a36b 100644
--- a/drivers/iio/buffer/Makefile
+++ b/drivers/iio/buffer/Makefile
@@ -6,5 +6,6 @@
obj-$(CONFIG_IIO_BUFFER_CB) += industrialio-buffer-cb.o
obj-$(CONFIG_IIO_BUFFER_DMA) += industrialio-buffer-dma.o
obj-$(CONFIG_IIO_BUFFER_DMAENGINE) += industrialio-buffer-dmaengine.o
+obj-$(CONFIG_IIO_BUFFER_HW_CONSUMER) += industrialio-hw-consumer.o
obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
diff --git a/drivers/iio/buffer/industrialio-hw-consumer.c b/drivers/iio/buffer/industrialio-hw-consumer.c
new file mode 100644
index 0000000..0253be1
--- /dev/null
+++ b/drivers/iio/buffer/industrialio-hw-consumer.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright 2017 Analog Devices Inc.
+ * Author: Lars-Peter Clausen <lars@metafoo.de>
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/consumer.h>
+#include <linux/iio/hw-consumer.h>
+#include <linux/iio/buffer_impl.h>
+
+/**
+ * struct iio_hw_consumer - IIO hw consumer block
+ * @buffers: hardware buffers list head.
+ * @channels: IIO provider channels.
+ */
+struct iio_hw_consumer {
+ struct list_head buffers;
+ struct iio_channel *channels;
+};
+
+struct hw_consumer_buffer {
+ struct list_head head;
+ struct iio_dev *indio_dev;
+ struct iio_buffer buffer;
+ long scan_mask[];
+};
+
+static struct hw_consumer_buffer *iio_buffer_to_hw_consumer_buffer(
+ struct iio_buffer *buffer)
+{
+ return container_of(buffer, struct hw_consumer_buffer, buffer);
+}
+
+static void iio_hw_buf_release(struct iio_buffer *buffer)
+{
+ struct hw_consumer_buffer *hw_buf =
+ iio_buffer_to_hw_consumer_buffer(buffer);
+ kfree(hw_buf);
+}
+
+static const struct iio_buffer_access_funcs iio_hw_buf_access = {
+ .release = &iio_hw_buf_release,
+ .modes = INDIO_BUFFER_HARDWARE,
+};
+
+static struct hw_consumer_buffer *iio_hw_consumer_get_buffer(
+ struct iio_hw_consumer *hwc, struct iio_dev *indio_dev)
+{
+ size_t mask_size = BITS_TO_LONGS(indio_dev->masklength) * sizeof(long);
+ struct hw_consumer_buffer *buf;
+
+ list_for_each_entry(buf, &hwc->buffers, head) {
+ if (buf->indio_dev == indio_dev)
+ return buf;
+ }
+
+ buf = kzalloc(sizeof(*buf) + mask_size, GFP_KERNEL);
+ if (!buf)
+ return NULL;
+
+ buf->buffer.access = &iio_hw_buf_access;
+ buf->indio_dev = indio_dev;
+ buf->buffer.scan_mask = buf->scan_mask;
+
+ iio_buffer_init(&buf->buffer);
+ list_add_tail(&buf->head, &hwc->buffers);
+
+ return buf;
+}
+
+/**
+ * iio_hw_consumer_alloc() - Allocate IIO hardware consumer
+ * @dev: Pointer to consumer device.
+ *
+ * Returns a valid iio_hw_consumer on success or a ERR_PTR() on failure.
+ */
+struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev)
+{
+ struct hw_consumer_buffer *buf;
+ struct iio_hw_consumer *hwc;
+ struct iio_channel *chan;
+ int ret;
+
+ hwc = kzalloc(sizeof(*hwc), GFP_KERNEL);
+ if (!hwc)
+ return ERR_PTR(-ENOMEM);
+
+ INIT_LIST_HEAD(&hwc->buffers);
+
+ hwc->channels = iio_channel_get_all(dev);
+ if (IS_ERR(hwc->channels)) {
+ ret = PTR_ERR(hwc->channels);
+ goto err_free_hwc;
+ }
+
+ chan = &hwc->channels[0];
+ while (chan->indio_dev) {
+ buf = iio_hw_consumer_get_buffer(hwc, chan->indio_dev);
+ if (!buf) {
+ ret = -ENOMEM;
+ goto err_put_buffers;
+ }
+ set_bit(chan->channel->scan_index, buf->buffer.scan_mask);
+ chan++;
+ }
+
+ return hwc;
+
+err_put_buffers:
+ list_for_each_entry(buf, &hwc->buffers, head)
+ iio_buffer_put(&buf->buffer);
+ iio_channel_release_all(hwc->channels);
+err_free_hwc:
+ kfree(hwc);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(iio_hw_consumer_alloc);
+
+/**
+ * iio_hw_consumer_free() - Free IIO hardware consumer
+ * @hwc: hw consumer to free.
+ */
+void iio_hw_consumer_free(struct iio_hw_consumer *hwc)
+{
+ struct hw_consumer_buffer *buf, *n;
+
+ iio_channel_release_all(hwc->channels);
+ list_for_each_entry_safe(buf, n, &hwc->buffers, head)
+ iio_buffer_put(&buf->buffer);
+ kfree(hwc);
+}
+EXPORT_SYMBOL_GPL(iio_hw_consumer_free);
+
+/**
+ * iio_hw_consumer_enable() - Enable IIO hardware consumer
+ * @hwc: iio_hw_consumer to enable.
+ *
+ * Returns 0 on success.
+ */
+int iio_hw_consumer_enable(struct iio_hw_consumer *hwc)
+{
+ struct hw_consumer_buffer *buf;
+ int ret;
+
+ list_for_each_entry(buf, &hwc->buffers, head) {
+ ret = iio_update_buffers(buf->indio_dev, &buf->buffer, NULL);
+ if (ret)
+ goto err_disable_buffers;
+ }
+
+ return 0;
+
+err_disable_buffers:
+ list_for_each_entry_continue_reverse(buf, &hwc->buffers, head)
+ iio_update_buffers(buf->indio_dev, NULL, &buf->buffer);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(iio_hw_consumer_enable);
+
+/**
+ * iio_hw_consumer_disable() - Disable IIO hardware consumer
+ * @hwc: iio_hw_consumer to disable.
+ */
+void iio_hw_consumer_disable(struct iio_hw_consumer *hwc)
+{
+ struct hw_consumer_buffer *buf;
+
+ list_for_each_entry(buf, &hwc->buffers, head)
+ iio_update_buffers(buf->indio_dev, NULL, &buf->buffer);
+}
+EXPORT_SYMBOL_GPL(iio_hw_consumer_disable);
+
+MODULE_AUTHOR("Lars-Peter Clausen <lars@metafoo.de>");
+MODULE_DESCRIPTION("Hardware consumer buffer the IIO framework");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/iio/hw-consumer.h b/include/linux/iio/hw-consumer.h
new file mode 100644
index 0000000..f16791b
--- /dev/null
+++ b/include/linux/iio/hw-consumer.h
@@ -0,0 +1,20 @@
+/*
+ * Industrial I/O in kernel hardware consumer interface
+ *
+ * Copyright 2017 Analog Devices Inc.
+ * Author: Lars-Peter Clausen <lars@metafoo.de>
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#ifndef LINUX_IIO_HW_CONSUMER_H
+#define LINUX_IIO_HW_CONSUMER_H
+
+struct iio_hw_consumer;
+
+struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev);
+void iio_hw_consumer_free(struct iio_hw_consumer *hwc);
+int iio_hw_consumer_enable(struct iio_hw_consumer *hwc);
+void iio_hw_consumer_disable(struct iio_hw_consumer *hwc);
+
+#endif
--
2.7.4
^ permalink raw reply related
* [PATCH v6 02/13] docs: driver-api: add iio hw consumer section
From: Arnaud Pouliquen @ 2017-12-01 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512150020-20335-1-git-send-email-arnaud.pouliquen@st.com>
This adds a section about the Hardware consumer
API of the IIO subsystem to the driver API
documentation.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
---
Documentation/driver-api/iio/hw-consumer.rst | 51 ++++++++++++++++++++++++++++
Documentation/driver-api/iio/index.rst | 1 +
2 files changed, 52 insertions(+)
create mode 100644 Documentation/driver-api/iio/hw-consumer.rst
diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst
new file mode 100644
index 0000000..8facce6
--- /dev/null
+++ b/Documentation/driver-api/iio/hw-consumer.rst
@@ -0,0 +1,51 @@
+===========
+HW consumer
+===========
+An IIO device can be directly connected to another device in hardware. in this
+case the buffers between IIO provider and IIO consumer are handled by hardware.
+The Industrial I/O HW consumer offers a way to bond these IIO devices without
+software buffer for data. The implementation can be found under
+:file:`drivers/iio/buffer/hw-consumer.c`
+
+
+* struct :c:type:`iio_hw_consumer` ? Hardware consumer structure
+* :c:func:`iio_hw_consumer_alloc` ? Allocate IIO hardware consumer
+* :c:func:`iio_hw_consumer_free` ? Free IIO hardware consumer
+* :c:func:`iio_hw_consumer_enable` ? Enable IIO hardware consumer
+* :c:func:`iio_hw_consumer_disable` ? Disable IIO hardware consumer
+
+
+HW consumer setup
+=================
+
+As standard IIO device the implementation is based on IIO provider/consumer.
+A typical IIO HW consumer setup looks like this::
+
+ static struct iio_hw_consumer *hwc;
+
+ static const struct iio_info adc_info = {
+ .read_raw = adc_read_raw,
+ };
+
+ static int adc_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+ {
+ ret = iio_hw_consumer_enable(hwc);
+
+ /* Acquire data */
+
+ ret = iio_hw_consumer_disable(hwc);
+ }
+
+ static int adc_probe(struct platform_device *pdev)
+ {
+ hwc = devm_iio_hw_consumer_alloc(&iio->dev);
+ }
+
+More details
+============
+.. kernel-doc:: include/linux/iio/hw-consumer.h
+.. kernel-doc:: drivers/iio/buffer/industrialio-hw-consumer.c
+ :export:
+
diff --git a/Documentation/driver-api/iio/index.rst b/Documentation/driver-api/iio/index.rst
index e5c3922..7fba341 100644
--- a/Documentation/driver-api/iio/index.rst
+++ b/Documentation/driver-api/iio/index.rst
@@ -15,3 +15,4 @@ Contents:
buffers
triggers
triggered-buffers
+ hw-consumer
--
2.7.4
^ permalink raw reply related
* [PATCH v6 03/13] IIO: hw_consumer: add devm_iio_hw_consumer_alloc
From: Arnaud Pouliquen @ 2017-12-01 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512150020-20335-1-git-send-email-arnaud.pouliquen@st.com>
Add devm_iio_hw_consumer_alloc function that calls iio_hw_consumer_free
when the device is unbound from the bus.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
---
drivers/iio/buffer/industrialio-hw-consumer.c | 66 +++++++++++++++++++++++++++
include/linux/iio/hw-consumer.h | 2 +
2 files changed, 68 insertions(+)
diff --git a/drivers/iio/buffer/industrialio-hw-consumer.c b/drivers/iio/buffer/industrialio-hw-consumer.c
index 0253be1..e980a79 100644
--- a/drivers/iio/buffer/industrialio-hw-consumer.c
+++ b/drivers/iio/buffer/industrialio-hw-consumer.c
@@ -138,6 +138,72 @@ void iio_hw_consumer_free(struct iio_hw_consumer *hwc)
}
EXPORT_SYMBOL_GPL(iio_hw_consumer_free);
+static void devm_iio_hw_consumer_release(struct device *dev, void *res)
+{
+ iio_hw_consumer_free(*(struct iio_hw_consumer **)res);
+}
+
+static int devm_iio_hw_consumer_match(struct device *dev, void *res, void *data)
+{
+ struct iio_hw_consumer **r = res;
+
+ if (!r || !*r) {
+ WARN_ON(!r || !*r);
+ return 0;
+ }
+ return *r == data;
+}
+
+/**
+ * devm_iio_hw_consumer_alloc - Resource-managed iio_hw_consumer_alloc()
+ * @dev: Pointer to consumer device.
+ *
+ * Managed iio_hw_consumer_alloc. iio_hw_consumer allocated with this function
+ * is automatically freed on driver detach.
+ *
+ * If an iio_hw_consumer allocated with this function needs to be freed
+ * separately, devm_iio_hw_consumer_free() must be used.
+ *
+ * returns pointer to allocated iio_hw_consumer on success, NULL on failure.
+ */
+struct iio_hw_consumer *devm_iio_hw_consumer_alloc(struct device *dev)
+{
+ struct iio_hw_consumer **ptr, *iio_hwc;
+
+ ptr = devres_alloc(devm_iio_hw_consumer_release, sizeof(*ptr),
+ GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ iio_hwc = iio_hw_consumer_alloc(dev);
+ if (IS_ERR(iio_hwc)) {
+ devres_free(ptr);
+ } else {
+ *ptr = iio_hwc;
+ devres_add(dev, ptr);
+ }
+
+ return iio_hwc;
+}
+EXPORT_SYMBOL_GPL(devm_iio_hw_consumer_alloc);
+
+/**
+ * devm_iio_hw_consumer_free - Resource-managed iio_hw_consumer_free()
+ * @dev: Pointer to consumer device.
+ * @hwc: iio_hw_consumer to free.
+ *
+ * Free iio_hw_consumer allocated with devm_iio_hw_consumer_alloc().
+ */
+void devm_iio_hw_consumer_free(struct device *dev, struct iio_hw_consumer *hwc)
+{
+ int rc;
+
+ rc = devres_release(dev, devm_iio_hw_consumer_release,
+ devm_iio_hw_consumer_match, hwc);
+ WARN_ON(rc);
+}
+EXPORT_SYMBOL_GPL(devm_iio_hw_consumer_free);
+
/**
* iio_hw_consumer_enable() - Enable IIO hardware consumer
* @hwc: iio_hw_consumer to enable.
diff --git a/include/linux/iio/hw-consumer.h b/include/linux/iio/hw-consumer.h
index f16791b..90ecfce 100644
--- a/include/linux/iio/hw-consumer.h
+++ b/include/linux/iio/hw-consumer.h
@@ -14,6 +14,8 @@ struct iio_hw_consumer;
struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev);
void iio_hw_consumer_free(struct iio_hw_consumer *hwc);
+struct iio_hw_consumer *devm_iio_hw_consumer_alloc(struct device *dev);
+void devm_iio_hw_consumer_free(struct device *dev, struct iio_hw_consumer *hwc);
int iio_hw_consumer_enable(struct iio_hw_consumer *hwc);
void iio_hw_consumer_disable(struct iio_hw_consumer *hwc);
--
2.7.4
^ permalink raw reply related
* [PATCH v6 04/13] IIO: inkern: API for manipulating channel attributes
From: Arnaud Pouliquen @ 2017-12-01 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512150020-20335-1-git-send-email-arnaud.pouliquen@st.com>
Extend the inkern API with functions for reading and writing
attribute of iio channels.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
---
V5 to V6 update:
Replace include type.h with iio.h to fix build warning
drivers/iio/inkern.c | 18 +++++++++++++-----
include/linux/iio/consumer.h | 28 +++++++++++++++++++++++++++-
2 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 069defc..f2e7824 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -664,9 +664,8 @@ int iio_convert_raw_to_processed(struct iio_channel *chan, int raw,
}
EXPORT_SYMBOL_GPL(iio_convert_raw_to_processed);
-static int iio_read_channel_attribute(struct iio_channel *chan,
- int *val, int *val2,
- enum iio_chan_info_enum attribute)
+int iio_read_channel_attribute(struct iio_channel *chan, int *val, int *val2,
+ enum iio_chan_info_enum attribute)
{
int ret;
@@ -682,6 +681,8 @@ static int iio_read_channel_attribute(struct iio_channel *chan,
return ret;
}
+EXPORT_SYMBOL_GPL(iio_read_channel_attribute);
+
int iio_read_channel_offset(struct iio_channel *chan, int *val, int *val2)
{
@@ -850,7 +851,8 @@ static int iio_channel_write(struct iio_channel *chan, int val, int val2,
chan->channel, val, val2, info);
}
-int iio_write_channel_raw(struct iio_channel *chan, int val)
+int iio_write_channel_attribute(struct iio_channel *chan, int val, int val2,
+ enum iio_chan_info_enum attribute)
{
int ret;
@@ -860,12 +862,18 @@ int iio_write_channel_raw(struct iio_channel *chan, int val)
goto err_unlock;
}
- ret = iio_channel_write(chan, val, 0, IIO_CHAN_INFO_RAW);
+ ret = iio_channel_write(chan, val, val2, attribute);
err_unlock:
mutex_unlock(&chan->indio_dev->info_exist_lock);
return ret;
}
+EXPORT_SYMBOL_GPL(iio_write_channel_attribute);
+
+int iio_write_channel_raw(struct iio_channel *chan, int val)
+{
+ return iio_write_channel_attribute(chan, val, 0, IIO_CHAN_INFO_RAW);
+}
EXPORT_SYMBOL_GPL(iio_write_channel_raw);
unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan)
diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
index 5e347a9..70658b1 100644
--- a/include/linux/iio/consumer.h
+++ b/include/linux/iio/consumer.h
@@ -11,7 +11,7 @@
#define _IIO_INKERN_CONSUMER_H_
#include <linux/types.h>
-#include <linux/iio/types.h>
+#include <linux/iio/iio.h>
struct iio_dev;
struct iio_chan_spec;
@@ -216,6 +216,32 @@ int iio_read_channel_average_raw(struct iio_channel *chan, int *val);
int iio_read_channel_processed(struct iio_channel *chan, int *val);
/**
+ * iio_write_channel_attribute() - Write values to the device attribute.
+ * @chan: The channel being queried.
+ * @val: Value being written.
+ * @val2: Value being written.val2 use depends on attribute type.
+ * @attribute: info attribute to be read.
+ *
+ * Returns an error code or 0.
+ */
+int iio_write_channel_attribute(struct iio_channel *chan, int val,
+ int val2, enum iio_chan_info_enum attribute);
+
+/**
+ * iio_read_channel_attribute() - Read values from the device attribute.
+ * @chan: The channel being queried.
+ * @val: Value being written.
+ * @val2: Value being written.Val2 use depends on attribute type.
+ * @attribute: info attribute to be written.
+ *
+ * Returns an error code if failed. Else returns a description of what is in val
+ * and val2, such as IIO_VAL_INT_PLUS_MICRO telling us we have a value of val
+ * + val2/1e6
+ */
+int iio_read_channel_attribute(struct iio_channel *chan, int *val,
+ int *val2, enum iio_chan_info_enum attribute);
+
+/**
* iio_write_channel_raw() - write to a given channel
* @chan: The channel being queried.
* @val: Value being written.
--
2.7.4
^ permalink raw reply related
* [PATCH v6 05/13] IIO: Add DT bindings for sigma delta adc modulator
From: Arnaud Pouliquen @ 2017-12-01 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512150020-20335-1-git-send-email-arnaud.pouliquen@st.com>
Add documentation of device tree bindings to support
sigma delta modulator in IIO framework.
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/iio/adc/sigma-delta-modulator.txt | 13 +++++++++++++
1 file changed, 13 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt
new file mode 100644
index 0000000..e9ebb8a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.txt
@@ -0,0 +1,13 @@
+Device-Tree bindings for sigma delta modulator
+
+Required properties:
+- compatible: should be "ads1201", "sd-modulator". "sd-modulator" can be use
+ as a generic SD modulator if modulator not specified in compatible list.
+- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers".
+
+Example node:
+
+ ads1202: adc at 0 {
+ compatible = "sd-modulator";
+ #io-channel-cells = <1>;
+ };
--
2.7.4
^ permalink raw reply related
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