* [PATCH 1/5] of: unittest: overlay: Keep track of created overlays
From: Pantelis Antoniou @ 2015-03-17 20:30 UTC (permalink / raw)
To: Grant Likely
Cc: Andrew Morton, Matt Porter, Koen Kooi, Guenter Roeck, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou,
Pantelis Antoniou
In-Reply-To: <1426624257-23003-1-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
During the course of the overlay selftests some of them remain
applied. While this does not pose a real problem, make sure you track
them and destroy them at the end of the test.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
---
drivers/of/unittest.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 4e60682..c711534 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -23,6 +23,8 @@
#include <linux/i2c.h>
#include <linux/i2c-mux.h>
+#include <linux/bitops.h>
+
#include "of_private.h"
static struct selftest_results {
@@ -1115,6 +1117,59 @@ static const char *overlay_path(int nr)
static const char *bus_path = "/testcase-data/overlay-node/test-bus";
+/* it is guaranteed that overlay ids are assigned in sequence */
+#define MAX_SELFTEST_OVERLAYS 256
+static unsigned long overlay_id_bits[BITS_TO_LONGS(MAX_SELFTEST_OVERLAYS)];
+static int overlay_first_id = -1;
+
+static void of_selftest_track_overlay(int id)
+{
+ if (overlay_first_id < 0)
+ overlay_first_id = id;
+ id -= overlay_first_id;
+
+ /* we shouldn't need that many */
+ BUG_ON(id >= MAX_SELFTEST_OVERLAYS);
+ overlay_id_bits[BIT_WORD(id)] |= BIT_MASK(id);
+}
+
+static void of_selftest_untrack_overlay(int id)
+{
+ if (overlay_first_id < 0)
+ return;
+ id -= overlay_first_id;
+ BUG_ON(id >= MAX_SELFTEST_OVERLAYS);
+ overlay_id_bits[BIT_WORD(id)] &= ~BIT_MASK(id);
+}
+
+static void of_selftest_destroy_tracked_overlays(void)
+{
+ int id, ret, defers;
+
+ if (overlay_first_id < 0)
+ return;
+
+ /* try until no defers */
+ do {
+ defers = 0;
+ /* remove in reverse order */
+ for (id = MAX_SELFTEST_OVERLAYS - 1; id >= 0; id--) {
+ if (!(overlay_id_bits[BIT_WORD(id)] & BIT_MASK(id)))
+ continue;
+
+ ret = of_overlay_destroy(id + overlay_first_id);
+ if (ret != 0) {
+ defers++;
+ pr_warn("%s: overlay destroy failed for #%d\n",
+ __func__, id + overlay_first_id);
+ continue;
+ }
+
+ overlay_id_bits[BIT_WORD(id)] &= ~BIT_MASK(id);
+ }
+ } while (defers > 0);
+}
+
static int of_selftest_apply_overlay(int selftest_nr, int overlay_nr,
int *overlay_id)
{
@@ -1136,6 +1191,7 @@ static int of_selftest_apply_overlay(int selftest_nr, int overlay_nr,
goto out;
}
id = ret;
+ of_selftest_track_overlay(id);
ret = 0;
@@ -1349,6 +1405,7 @@ static void of_selftest_overlay_6(void)
return;
}
ov_id[i] = ret;
+ of_selftest_track_overlay(ov_id[i]);
}
for (i = 0; i < 2; i++) {
@@ -1373,6 +1430,7 @@ static void of_selftest_overlay_6(void)
PDEV_OVERLAY));
return;
}
+ of_selftest_untrack_overlay(ov_id[i]);
}
for (i = 0; i < 2; i++) {
@@ -1417,6 +1475,7 @@ static void of_selftest_overlay_8(void)
return;
}
ov_id[i] = ret;
+ of_selftest_track_overlay(ov_id[i]);
}
/* now try to remove first overlay (it should fail) */
@@ -1439,6 +1498,7 @@ static void of_selftest_overlay_8(void)
PDEV_OVERLAY));
return;
}
+ of_selftest_untrack_overlay(ov_id[i]);
}
selftest(1, "overlay test %d passed\n", 8);
@@ -1861,6 +1921,8 @@ static void __init of_selftest_overlay(void)
of_selftest_overlay_i2c_cleanup();
#endif
+ of_selftest_destroy_tracked_overlays();
+
out:
of_node_put(bus_np);
}
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/5] of: overlay: Assorted fixes
From: Pantelis Antoniou @ 2015-03-17 20:30 UTC (permalink / raw)
To: Grant Likely
Cc: Andrew Morton, Matt Porter, Koen Kooi, Guenter Roeck, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou,
Pantelis Antoniou
The first patch makes sure that no overlays are being left over from
the unit tests.
The second puts the overlays as objects in the sysfs in
/sys/firmware/devicetree/overlays while the next one adds a master
overlay enable switch (that once is set to disabled can't be re-enabled)
The next updates the ABI docs and the final one adds me as the
maintainer for device tree overlays.
Pantelis Antoniou (5):
of: unittest: overlay: Keep track of created overlays
of: overlay: kobjectify overlay objects
of: overlay: Master enable switch
Documentation: ABI: /sys/firmware/devicetree/overlays
MAINTAINERS: Pantelis Antoniou device tree overlay maintainer
.../ABI/testing/sysfs-firmware-devicetree-overlays | 9 ++
MAINTAINERS | 9 ++
drivers/of/base.c | 5 +
drivers/of/of_private.h | 9 ++
drivers/of/overlay.c | 116 ++++++++++++++++++++-
drivers/of/unittest.c | 62 +++++++++++
6 files changed, 208 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-firmware-devicetree-overlays
--
1.7.12
^ permalink raw reply
* Re: [PATCH] add support for Freescale's MMA8653FC 10 bit accelerometer
From: Greg KH @ 2015-03-17 19:26 UTC (permalink / raw)
To: Martin Kepplinger
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
christoph.muellner-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Martin Kepplinger
In-Reply-To: <1426612146-7836-1-git-send-email-martink-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org>
On Tue, Mar 17, 2015 at 06:09:06PM +0100, Martin Kepplinger wrote:
> From: Martin Kepplinger <martin.kepplinger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
>
> Signed-off-by: Martin Kepplinger <martin.kepplinger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
> Signed-off-by: Christoph Muellner <christoph.muellner-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
> ---
> .../testing/sysfs-bus-i2c-devices-fsl-mma8653fc | 36 +
> .../devicetree/bindings/misc/fsl,mma8653fc.txt | 95 +++
> MAINTAINERS | 6 +
> drivers/input/misc/Kconfig | 11 +
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/mma8653fc.c | 907 +++++++++++++++++++++
> 6 files changed, 1056 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-fsl-mma8653fc
> create mode 100644 Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt
> create mode 100644 drivers/input/misc/mma8653fc.c
Please use scripts/get_maintainer.pl to determine that I am not the
person to send this to. Hint, it's an input device, send it to the
linux-input mailing list...
And you need a changelog entry it can't be blank.
good luck,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 00/14] Add kdbus implementation
From: Andy Lutomirski @ 2015-03-17 19:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Arnd Bergmann, Eric W. Biederman, One Thousand Gnomes,
Tom Gundersen, Jiri Kosina, Linux API,
linux-kernel@vger.kernel.org, Daniel Mack, David Herrmann,
Djalal Harouni
In-Reply-To: <1425906560-13798-1-git-send-email-gregkh@linuxfoundation.org>
On Mon, Mar 9, 2015 at 6:09 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> kdbus is a kernel-level IPC implementation that aims for resemblance to
> the the protocol layer with the existing userspace D-Bus daemon while
> enabling some features that couldn't be implemented before in userspace.
>
[...]
What changed from last time?
The discussion from last time about performance seems to have stalled.
kdbus is supposed to be fast -- that seems to be a large part of the
point. Can anyone comment on how fast it actually is. I'm curious
about:
- The time it takes to do the ioctl to send a message
- The time it takes to receive a message (poll + whatever ioctls)
- The time it takes to transfer a memfd (I don't care about how long
it takes to create or map a memfd -- that's exactly the same between
kdbus and any other memfds user, I imagine)
- The time it takes to connect
I'm also interested in whether the current design is actually amenable
to good performance. I'm told that it is, but ISTM there's a lot of
heavyweight stuff going on with each send operation that will be hard
to remove.
--Andy
^ permalink raw reply
* Re: [PATCH net-next] bpf: allow BPF programs access 'protocol' and 'vlan_tci' fields
From: David Miller @ 2015-03-17 19:06 UTC (permalink / raw)
To: ast-uqk4Ao+rVK5Wk0Htik3J/w
Cc: daniel-FeC+5ew28dpmcu3hnIyYJQ, tgraf-G/eBtMaohhA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1426554362-29991-1-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Mon, 16 Mar 2015 18:06:02 -0700
> as a follow on to patch 70006af95515 ("bpf: allow eBPF access skb fields")
> this patch allows 'protocol' and 'vlan_tci' fields to be accessible
> from extended BPF programs.
>
> The usage of 'protocol', 'vlan_present' and 'vlan_tci' fields is the same as
> corresponding SKF_AD_PROTOCOL, SKF_AD_VLAN_TAG_PRESENT and SKF_AD_VLAN_TAG
> accesses in classic BPF.
>
> Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] add support for Freescale's MMA8653FC 10 bit accelerometer
From: Paul Bolle @ 2015-03-17 19:00 UTC (permalink / raw)
To: Martin Kepplinger
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
linux-api-u79uwXL29TY76Z2rM5mHXA,
christoph.muellner-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Martin Kepplinger
In-Reply-To: <1426612146-7836-1-git-send-email-martink-1KBjaw7Xf1+zQB+pC5nmwQ@public.gmane.org>
Just a license nit.
On Tue, 2015-03-17 at 18:09 +0100, Martin Kepplinger wrote:
> --- /dev/null
> +++ b/drivers/input/misc/mma8653fc.c
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
This states the license is GPL v2.
> +MODULE_LICENSE("GPL");
And
MODULE_LICENSE("GPL v2");
would match that statement.
Paul Bolle
^ permalink raw reply
* Re: [PATCH net-next] bpf: allow BPF programs access 'protocol' and 'vlan_tci' fields
From: Daniel Borkmann @ 2015-03-17 18:14 UTC (permalink / raw)
To: Alexei Starovoitov, David S. Miller
Cc: Thomas Graf, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <55086AB3.9030405-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
On 03/17/2015 06:56 PM, Alexei Starovoitov wrote:
> On 3/17/15 2:22 AM, Daniel Borkmann wrote:
>> On 03/17/2015 02:06 AM, Alexei Starovoitov wrote:
...
>>> I was thinking to drop ntohs() from 'protocol' field for extended BPF,
>>> since
>>> the programs could do:
>>> if (skb->protocol == htons(ETH_P_IP))
>>> which would have saved one or two cpu cycles.
>>> But having similar behavior between classic and extended seems to be
>>> better.
>>
>> I'm thinking that skb->protocol == htons(ETH_P_IP) might actually
>> be more obvious, and, as you mentioned, the compiler can already
>> resolve the htons() during compile time instead of runtime, which
>> would be another plus.
>>
>> Either behavior we should document later anyway.
>>
>> The question to me here is, do we need to keep similar behavior?
>>
>> After all, the way of programming both from a user perspective is
>> quite different (i.e. bpf_asm versus C/LLVM).
>
> yeah. we don't have to. Somehow I felt that keeping ntohs will make
> it easier for folks moving from classic to extended, but I guess
> they're different enough, so no point wasting run time cycles.
Yes, I think that case seems reasonable in my opinion.
>> Similarly, I was wondering, if just exporting raw skb->vlan_tci is
>> already sufficient, and the user can e.g. write helpers to extract
>> bits himself from that protocol field?
>
> yes. I thought about the same. Currently VLAN_TAG_PRESENT bit is not
> officially exposed to user space, but implicitly, since that bit
> is always cleared when we return tci to user space and it's always
> set when drivers indicate that vlan header was present in the packet.
Right.
> So I think we can return skb->vlan_tci as-is, since it will save
> one load in bpf program which will be able to do
> if (skb->vlan_tci != 0) /* vlan header is present */
> vid = skb->vlan_tci & 0x0fff;
> compiler will optimize above two accesses into single load and will
> reuse the register in 2nd line.
Ok, I'm not sure what's best in the vlan_tci case. I think both
options are a possible way to move forward. If the compiler can
further optimize the latter, it might be the better option. I'll
leave that to you. ;)
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
From: Andy Shevchenko @ 2015-03-17 17:56 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Arnd Bergmann,
Stefan Agner, Peter Meerwald, Paul Bolle, Jonathan Corbet,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
Daniel Lezcano, Thomas Gleixner, Greg Kroah-Hartman, Jiri Slaby,
Andrew Morton, David S. Miller
In-Reply-To: <CALszF6BWuUYRh+3rWnSQLApkAHA5dQXw=6x6D_evRtb+5B_ukA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Mar 17, 2015 at 7:32 PM, Maxime Coquelin
<mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 2015-03-13 15:19 GMT+01:00 Andy Shevchenko <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>> +static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
>>> + struct ktermios *old)
>>> +{
>>> + unsigned int baud;
>>> + u32 usardiv, mantissa, fraction;
>>> + tcflag_t cflag;
>>> + u32 cr1, cr2, cr3;
>>> + unsigned long flags;
>>> +
>>> + baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 16);
>>> + cflag = termios->c_cflag;
>>> +
>>> + spin_lock_irqsave(&port->lock, flags);
>>> +
>>> + /* Stop serial port and reset value */
>>> + writel_relaxed(0, port->membase + USART_CR1);
>>> +
>>> + cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
>>> +
>>> + if (cflag & CSTOPB)
>>> + cr2 = USART_CR2_STOP_2B;
>>> +
>>> + if (cflag & PARENB) {
>>> + cr1 |= USART_CR1_PCE;
>>> + if ((cflag & CSIZE) == CS8)
>>> + cr1 |= USART_CR1_M;
>>> + }
>>> +
>>> + if (cflag & PARODD)
>>> + cr1 |= USART_CR1_PS;
>>> +
>>> + if (cflag & CRTSCTS)
>>> + cr3 = USART_CR3_RTSE | USART_CR3_CTSE;
>>> +
>>> + usardiv = (port->uartclk * 25) / (baud * 4);
>>> + mantissa = (usardiv / 100) << USART_BRR_DIV_M_SHIFT;
>>> + fraction = DIV_ROUND_CLOSEST((usardiv % 100) * 16, 100);
>>> + if (fraction & ~USART_BRR_DIV_F_MASK) {
>>> + fraction = 0;
>>> + mantissa += (1 << USART_BRR_DIV_M_SHIFT);
>>> + }
>>
>> So, it's a fractional divider. right? Could it be then fractional
>> divider clock in this first place (see
>> drivers/clk/clk-fractional-divider.c)?
>>
>
> I'm not sure it makes sense to represent this baudrate divider within
> the UART IP as a clock.
You have it already. I mean it should be fractional divider clock.
stm32port->clk = devm_clk_get(&pdev->dev, NULL);
+
+ if (WARN_ON(IS_ERR(stm32port->clk)))
+ return -EINVAL;
+
+ /* ensure that clk rate is correct by enabling the clk */
+ clk_prepare_enable(stm32port->clk);
+ stm32port->port.uartclk = clk_get_rate(stm32port->clk);
> What would be the gain?
Remove custom implementation of the calculations. It will be just one
line to refresh the baud rate. I think we have a lot of duplicates
here and there in the kernel. It would be nice not to bring another
one.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] bpf: allow BPF programs access 'protocol' and 'vlan_tci' fields
From: Alexei Starovoitov @ 2015-03-17 17:56 UTC (permalink / raw)
To: Daniel Borkmann, David S. Miller; +Cc: Thomas Graf, linux-api, netdev
In-Reply-To: <5507F253.9000806@iogearbox.net>
On 3/17/15 2:22 AM, Daniel Borkmann wrote:
> On 03/17/2015 02:06 AM, Alexei Starovoitov wrote:
>> as a follow on to patch 70006af95515 ("bpf: allow eBPF access skb
>> fields")
>> this patch allows 'protocol' and 'vlan_tci' fields to be accessible
>> from extended BPF programs.
>>
>> The usage of 'protocol', 'vlan_present' and 'vlan_tci' fields is the
>> same as
>> corresponding SKF_AD_PROTOCOL, SKF_AD_VLAN_TAG_PRESENT and
>> SKF_AD_VLAN_TAG
>> accesses in classic BPF.
>>
>> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
>
> Ok, code looks good to me.
>
>> 1.
>> I was thinking to drop ntohs() from 'protocol' field for extended BPF,
>> since
>> the programs could do:
>> if (skb->protocol == htons(ETH_P_IP))
>> which would have saved one or two cpu cycles.
>> But having similar behavior between classic and extended seems to be
>> better.
>
> I'm thinking that skb->protocol == htons(ETH_P_IP) might actually
> be more obvious, and, as you mentioned, the compiler can already
> resolve the htons() during compile time instead of runtime, which
> would be another plus.
>
> Either behavior we should document later anyway.
>
> The question to me here is, do we need to keep similar behavior?
>
> After all, the way of programming both from a user perspective is
> quite different (i.e. bpf_asm versus C/LLVM).
yeah. we don't have to. Somehow I felt that keeping ntohs will make
it easier for folks moving from classic to extended, but I guess
they're different enough, so no point wasting run time cycles.
> Similarly, I was wondering, if just exporting raw skb->vlan_tci is
> already sufficient, and the user can e.g. write helpers to extract
> bits himself from that protocol field?
yes. I thought about the same. Currently VLAN_TAG_PRESENT bit is not
officially exposed to user space, but implicitly, since that bit
is always cleared when we return tci to user space and it's always
set when drivers indicate that vlan header was present in the packet.
So I think we can return skb->vlan_tci as-is, since it will save
one load in bpf program which will be able to do
if (skb->vlan_tci != 0) /* vlan header is present */
vid = skb->vlan_tci & 0x0fff;
compiler will optimize above two accesses into single load and will
reuse the register in 2nd line.
^ permalink raw reply
* Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
From: Maxime Coquelin @ 2015-03-17 17:39 UTC (permalink / raw)
To: Paul Bolle
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Arnd Bergmann,
Stefan Agner, Peter Meerwald, Jonathan Corbet, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
Daniel Lezcano, Thomas Gleixner, Greg Kroah-Hartman, Jiri Slaby,
Andrew Morton, David S. Miller
In-Reply-To: <1426239683.5304.59.camel@x220>
2015-03-13 10:41 GMT+01:00 Paul Bolle <pebolle@tiscali.nl>:
> Just a license nit, I'm afraid.
Not a problem, it is not the last round anyway.
>
> On Thu, 2015-03-12 at 22:55 +0100, Maxime Coquelin wrote:
>> --- /dev/null
>> +++ b/drivers/tty/serial/stm32-usart.c
>> @@ -0,0 +1,695 @@
>> +/*
>> + * Copyright (C) Maxime Coquelin 2015
>> + * Author: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> + * License terms: GNU General Public License (GPL), version 2
>> + *
>> + * Inspired by st-asc.c from STMicroelectronics (c)
>> + */
>
> This states the license is GPL v2.
>
>> +MODULE_LICENSE("GPL");
>
> And
> MODULE_LICENSE("GPL v2");
>
> would match that statement.
Right, it will be fixed in the v4.
Thanks,
Maxime
>
>
> Paul Bolle
>
^ permalink raw reply
* Re: [PATCH v2 tip/core/rcu 01/22] smpboot: Add common code for notification from dying CPU
From: Paul E. McKenney @ 2015-03-17 17:32 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, mingo-DgEjT+Ai2ygdnm+yROfE0A,
laijs-BthXqXjhjHXQFUHtdCDX3A, dipankar-xthvdsQ13ZrQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
josh-iaAMLnmF4UmaiuxdJuQwMA, tglx-hfZtesqFncYOwBW4kG4KsQ,
rostedt-nx8X9YLhiw1AfugRpC6u6w, dhowells-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, dvhart-VuQAYsv1563Yd54FQh9/CA,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w, oleg-H+wXaHxf7aLQT0dZR+AlfA,
bobby.prani-Re5JQEeQqe8AvxtiuMwx3w,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arch-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150317165621.GF24151-ndre7Fmf5hadTX5a5knrm8zTDFooKrT+cvkQGrU6aU0@public.gmane.org>
On Tue, Mar 17, 2015 at 05:56:21PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 17, 2015 at 03:08:46PM +0100, Peter Zijlstra wrote:
> > On Tue, Mar 17, 2015 at 04:36:48AM -0700, Paul E. McKenney wrote:
> > > On Tue, Mar 17, 2015 at 09:18:07AM +0100, Peter Zijlstra wrote:
> > > > On Mon, Mar 16, 2015 at 11:37:45AM -0700, Paul E. McKenney wrote:
> > > > > From: "Paul E. McKenney" <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> > > > >
> > > > > RCU ignores offlined CPUs, so they cannot safely run RCU read-side code.
> > > > > (They -can- use SRCU, but not RCU.) This means that any use of RCU
> > > > > during or after the call to arch_cpu_idle_dead(). Unfortunately,
> > > > > commit 2ed53c0d6cc99 added a complete() call, which will contain RCU
> > > > > read-side critical sections if there is a task waiting to be awakened.
> > > >
> > > > Got a little more detail there?
> > >
> > > Quite possibly. But exactly what sort of detail are you looking for?
> >
> > What exact RCU usage you ran into that was problematic. It seems to
> > imply that calling complete() -- from a dead cpu -- which ends up in
> > try_to_wake_up() was the problem?
>
> Hmm, I'm thinking its select_task_rq_*(). And yes, 'fixing' this in the
> wake-up path will penalize everybody for the benefit of the very rare
> case someone is doing a hotplug.
>
> So yeah, maybe this is the best solution.. Ulgy though :/
Ugly indeed! I end up doing a polling loop for the generic code. For the
first round, I updated only architectures that were calling complete().
If that goes well, I will probably update some of the other architecture
as a code-consolidation measure. Some architectures have special hardware
and firmware hooks, for example, s390 uses a special instruction to do
the wakeup directly. Those will of course continue doing their own thing.
The ARM guys are trying to do something specific to their hardware, but
I have not heard from them lately. I should ping them...
Thanx, Paul
^ permalink raw reply
* Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver
From: Maxime Coquelin @ 2015-03-17 17:32 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Arnd Bergmann,
Stefan Agner, Peter Meerwald, Paul Bolle, Jonathan Corbet,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
Daniel Lezcano, Thomas Gleixner, Greg Kroah-Hartman, Jiri Slaby,
Andrew Morton, David S. Miller
In-Reply-To: <CAHp75Vd7+oLiLLuyocYh95TebtocWrRho6xNjuSUt8fYGp8npg@mail.gmail.com>
2015-03-13 15:19 GMT+01:00 Andy Shevchenko <andy.shevchenko@gmail.com>:
> On Thu, Mar 12, 2015 at 11:55 PM, Maxime Coquelin
> <mcoquelin.stm32@gmail.com> wrote:
>> From: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>
>> This drivers adds support to the STM32 USART controller, which is a
>> standard serial driver.
>
> My comment below.
>
>>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> ---
>> drivers/tty/serial/Kconfig | 17 +
>> drivers/tty/serial/Makefile | 1 +
>> drivers/tty/serial/stm32-usart.c | 695 +++++++++++++++++++++++++++++++++++++++
>> include/uapi/linux/serial_core.h | 3 +
>> 4 files changed, 716 insertions(+)
>> create mode 100644 drivers/tty/serial/stm32-usart.c
>>
>> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
>> index d2501f0..880cb4f 100644
>> --- a/drivers/tty/serial/Kconfig
>> +++ b/drivers/tty/serial/Kconfig
>> @@ -1611,6 +1611,23 @@ config SERIAL_SPRD_CONSOLE
>> with "earlycon" on the kernel command line. The console is
>> enabled when early_param is processed.
>>
>> +config SERIAL_STM32
>> + tristate "STMicroelectronics STM32 serial port support"
>> + select SERIAL_CORE
>> + depends on ARM || COMPILE_TEST
>> + help
>> + This driver is for the on-chip Serial Controller on
>> + STMicroelectronics STM32 MCUs.
>> + USART supports Rx & Tx functionality.
>> + It support all industry standard baud rates.
>> +
>> + If unsure, say N.
>> +
>> +config SERIAL_STM32_CONSOLE
>> + bool "Support for console on STM32"
>> + depends on SERIAL_STM32=y
>> + select SERIAL_CORE_CONSOLE
>> +
>> endmenu
>>
>> config SERIAL_MCTRL_GPIO
>> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
>> index 599be4b..67c5023 100644
>> --- a/drivers/tty/serial/Makefile
>> +++ b/drivers/tty/serial/Makefile
>> @@ -95,6 +95,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART) += fsl_lpuart.o
>> obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR) += digicolor-usart.o
>> obj-$(CONFIG_SERIAL_MEN_Z135) += men_z135_uart.o
>> obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
>> +obj-$(CONFIG_SERIAL_STM32) += stm32-usart.o
>>
>> # GPIOLIB helpers for modem control lines
>> obj-$(CONFIG_SERIAL_MCTRL_GPIO) += serial_mctrl_gpio.o
>> diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
>> new file mode 100644
>> index 0000000..61bb065
>> --- /dev/null
>> +++ b/drivers/tty/serial/stm32-usart.c
>> @@ -0,0 +1,695 @@
<snip>
>> +
>> +static void stm32_set_termios(struct uart_port *port, struct ktermios *termios,
>> + struct ktermios *old)
>> +{
>> + unsigned int baud;
>> + u32 usardiv, mantissa, fraction;
>> + tcflag_t cflag;
>> + u32 cr1, cr2, cr3;
>> + unsigned long flags;
>> +
>> + baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 16);
>> + cflag = termios->c_cflag;
>> +
>> + spin_lock_irqsave(&port->lock, flags);
>> +
>> + /* Stop serial port and reset value */
>> + writel_relaxed(0, port->membase + USART_CR1);
>> +
>> + cr1 = USART_CR1_TE | USART_CR1_RE | USART_CR1_UE | USART_CR1_RXNEIE;
>> +
>> + if (cflag & CSTOPB)
>> + cr2 = USART_CR2_STOP_2B;
>> +
>> + if (cflag & PARENB) {
>> + cr1 |= USART_CR1_PCE;
>> + if ((cflag & CSIZE) == CS8)
>> + cr1 |= USART_CR1_M;
>> + }
>> +
>> + if (cflag & PARODD)
>> + cr1 |= USART_CR1_PS;
>> +
>> + if (cflag & CRTSCTS)
>> + cr3 = USART_CR3_RTSE | USART_CR3_CTSE;
>> +
>> + usardiv = (port->uartclk * 25) / (baud * 4);
>> + mantissa = (usardiv / 100) << USART_BRR_DIV_M_SHIFT;
>> + fraction = DIV_ROUND_CLOSEST((usardiv % 100) * 16, 100);
>> + if (fraction & ~USART_BRR_DIV_F_MASK) {
>> + fraction = 0;
>> + mantissa += (1 << USART_BRR_DIV_M_SHIFT);
>> + }
>
> So, it's a fractional divider. right? Could it be then fractional
> divider clock in this first place (see
> drivers/clk/clk-fractional-divider.c)?
>
I'm not sure it makes sense to represent this baudrate divider within
the UART IP as a clock.
What would be the gain?
Kind regards,
Maxime
^ permalink raw reply
* Re: [PATCH v3 06/15] drivers: reset: Add STM32 reset driver
From: Maxime Coquelin @ 2015-03-17 17:23 UTC (permalink / raw)
To: Philipp Zabel
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Linus Walleij, Arnd Bergmann, Stefan Agner,
Peter Meerwald, Paul Bolle, Jonathan Corbet, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
Daniel Lezcano, Thomas Gleixner, Greg Kroah-Hartman, Jiri Slaby,
Andrew Morton, David S. Miller, Mauro Carvalho Chehab
In-Reply-To: <1426236895.3083.20.camel@pengutronix.de>
2015-03-13 9:54 GMT+01:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Am Donnerstag, den 12.03.2015, 22:55 +0100 schrieb Maxime Coquelin:
>> From: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>
>> The STM32 MCUs family IP can be reset by accessing some shared registers.
>>
>> The specificity is that some reset lines are used by the timers.
>> At timer initialization time, the timer has to be reset, that's why
>> we cannot use a regular driver.
>
> But this is a regular driver now, should this comment be updated?
>
Indeed, I changed in v4 to:
The STM32 MCUs family IPs can be reset by accessing some registers
from the RCC block.
The list of available reset lines is documented in the DT bindings.
Thanks,
Maxime
>
> regards
> Philipp
>
^ permalink raw reply
* Re: [PATCH v3 05/15] dt-bindings: Document the STM32 reset bindings
From: Maxime Coquelin @ 2015-03-17 17:13 UTC (permalink / raw)
To: Philipp Zabel
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Linus Walleij, Arnd Bergmann, Stefan Agner,
Peter Meerwald, Paul Bolle, Jonathan Corbet, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
Daniel Lezcano, Thomas Gleixner, Greg Kroah-Hartman, Jiri Slaby,
Andrew Morton, David S. Miller, Mauro Carvalho Chehab
In-Reply-To: <1426236654.3083.19.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hi Philipp,
2015-03-13 9:50 GMT+01:00 Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>:
> Hi Maxime,
>
> Am Donnerstag, den 12.03.2015, 22:55 +0100 schrieb Maxime Coquelin:
>> From: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>
>> This adds documentation of device tree bindings for the
>> STM32 reset controller.
>>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> .../devicetree/bindings/reset/st,stm32-rcc.txt | 102 +++++++++++++++++++++
>> 1 file changed, 102 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>> new file mode 100644
>> index 0000000..962f961
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>> @@ -0,0 +1,102 @@
>> +STMicroelectronics STM32 Peripheral Reset Controller
>> +====================================================
>> +
>> +The RCC IP is both a reset and a clock controller. This documentation only
>> +document the reset part.
>> +
>> +Please also refer to reset.txt in this directory for common reset
>> +controller binding usage.
>> +
>> +Required properties:
>> +- compatible: Should be "st,stm32-rcc"
>> +- reg: should be register base and length as documented in the
>> + datasheet
>> +- #reset-cells: 1, see below
>> +
>> +example:
>> +
>> +rcc: reset@40023800 {
>> + #reset-cells = <1>;
>> + compatible = "st,stm32-rcc";
>> + reg = <0x40023800 0x400>;
>> +};
>> +
>> +Specifying softreset control of devices
>> +=======================================
>> +
>> +Device nodes should specify the reset channel required in their "resets"
>> +property, containing a phandle to the reset device node and an index specifying
>> +which channel to use.
>
> Using a single value as index is ok, but it should be documented how
> this corresponds to the register and bit offsets in the reference
> manual.
> Maybe add a comment that the index is in fact the register offset / 4 *
> 32 + bit offset in that register and that not all registers are
> dedicated to the rest controller? Otherwise it is confusing (to me at
> least) that the indices start at some arbitrary value.
I agree to better document it. Are you ok with:
The index is the bit number within the RCC registers bank, starting from RCC
base address.
It is calculated as: index = register_offset / 4 * 32 + bit_offset.
Where bit_offset is the bit offset within the register.
For example, for CRC reset:
crc = AHB1RSTR_offset / 4 * 32 + CRCRST_bit_offset = 0x10 / 4 * 32 + 12 = 140
>
>> +example:
>> +
>> + timer2 {
>> + resets = <&rcc 256>;
>> + };
>> +
>> +List of indexes for STM32F429:
>
> "List of valid indices", to point out that any other index is invalid?
Right, it will be changed in v4.
>
>> + - gpioa: 128
>
> I had to look at the RM0090 Reference manual V8.0, Chapter 6, "Reset and
> clock control for STM32F42xx and STM32F43xxx (RCC)" to see that the
> reset registers indeed start at 0x10 (RCC_AHB1RSTR), ...
>
>> + - gpiob: 129
>> + - gpioc: 130
>> + - gpiod: 131
>> + - gpioe: 132
>> + - gpiof: 133
>> + - gpiog: 134
>> + - gpioh: 135
>> + - gpioi: 136
>> + - gpioj: 137
>> + - gpiok: 138
>> + - crc: 140
>> + - dma1: 149
>> + - dma2: 150
>> + - dma2d: 151
>> + - ethmac: 153
>> + - otghs: 157
>> + - dcmi: 160
>> + - cryp: 164
>> + - hash: 165
>> + - rng: 166
>> + - otgfs: 167
>> + - fmc: 192
>> + - tim2: 256
>> + - tim3: 257
>> + - tim4: 258
>> + - tim5: 259
>> + - tim6: 260
>> + - tim7: 261
>> + - tim12: 262
>> + - tim13: 263
>> + - tim14: 264
>> + - wwdg: 267
>> + - spi2: 270
>> + - spi3: 271
>> + - uart2: 273
>> + - uart3: 274
>> + - uart4: 275
>> + - uart5: 276
>> + - i2c1: 277
>> + - i2c2: 278
>> + - i2c3: 279
>> + - can1: 281
>> + - can2: 282
>> + - pwr: 284
>> + - dac: 285
>> + - uart7: 286
>> + - uart8: 287
>> + - tim1: 288
>> + - tim8: 289
>> + - usart1: 292
>> + - usart6: 293
>> + - adc: 296
>> + - sdio: 299
>> + - spi1: 300
>> + - spi4: 301
>> + - syscfg: 302
>> + - tim9: 304
>> + - tim10: 305
>> + - tim11: 306
>> + - spi5: 308
>> + - spi6: 309
>> + - sai1: 310
>> + - ltdc: 31
>
> That last one should say "ltdc: 314", right?
Thanks for catching this!
Just fixed it, it will be in v4.
Kind regards,
Maxime
>
> regards
> Philipp
>
^ permalink raw reply
* [PATCH] add support for Freescale's MMA8653FC 10 bit accelerometer
From: Martin Kepplinger @ 2015-03-17 17:09 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
christoph.muellner-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Martin Kepplinger
From: Martin Kepplinger <martin.kepplinger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
Signed-off-by: Martin Kepplinger <martin.kepplinger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
Signed-off-by: Christoph Muellner <christoph.muellner-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
---
.../testing/sysfs-bus-i2c-devices-fsl-mma8653fc | 36 +
.../devicetree/bindings/misc/fsl,mma8653fc.txt | 95 +++
MAINTAINERS | 6 +
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/mma8653fc.c | 907 +++++++++++++++++++++
6 files changed, 1056 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-fsl-mma8653fc
create mode 100644 Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt
create mode 100644 drivers/input/misc/mma8653fc.c
diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsl-mma8653fc b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsl-mma8653fc
new file mode 100644
index 0000000..beebd8d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsl-mma8653fc
@@ -0,0 +1,36 @@
+What: /sys/bus/i2c/drivers/mma8653fc/*/standby
+Date: March 2015
+Contact: Martin Kepplinger <martin.kepplinger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
+Description:
+ Write 0 to this in order to turn on the device, and 1 to turn
+ it off. Read to see if it is turned on or off.
+
+
+What: /sys/bus/i2c/drivers/mma8653fc/*/currentmode
+Date: March 2015
+Contact: Martin Kepplinger <martin.kepplinger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
+Description:
+ Reading this provides the current state of the device, read
+ directly from a register. This can be "standby", "wake" or
+ "sleep".
+
+
+What: /sys/bus/i2c/drivers/mma8653fc/*/position
+Date: March 2015
+Contact: Martin Kepplinger <martin.kepplinger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
+Description:
+ Read only. Without interrupts enabled gets current position
+ values by reading. Poll "position" with interrupt conditions
+ set, to get notified; see Documentation/.../fsl,mma8653fc.txt
+
+ position file format:
+ "x y z [landscape/portrait status] [front/back status]"
+ landscape/portrait status char:
+ r landscape right
+ d portrait down
+ u portrait up
+ l landscape left
+ front/back status char:
+ f front facing
+ b back facing
+
diff --git a/Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt b/Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt
new file mode 100644
index 0000000..9065550
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/fsl,mma8653fc.txt
@@ -0,0 +1,95 @@
+Freescale MMA8653FC 3-axis Accelerometer
+
+Required properties:
+- compatible
+ "fsl,mma8653fc"
+- reg
+ I2C address
+
+Optional properties:
+
+- interrupt-parent
+ GPIO interrupt line
+- interrupts
+ GPIO interrupt address
+- int1
+ set to use interrupt line 1 instead of 2
+- int_active_high
+ set interrupt line active high
+- ir_freefall_motion_x
+ activate freefall/motion interrupts on x axis
+- ir_freefall_motion_y
+ activate freefall/motion interrupts on y axis
+- ir_freefall_motion_z
+ activate freefall/motion interrupts on z axis
+- irq_threshold
+ 0 < value < 8000: threshold for motion interrupts in mg
+- ir_landscape_portrait
+ activate landscape/portrait interrupts
+- ir_data_ready:
+ activate data-ready interrupts
+ Interrupt events can be activated in any combination.
+- range
+ 2, 4, or 8: range in g, default: 2
+- auto_wake_sleep
+ auto sleep mode (lower frequency)
+- motion_mode
+ use motion mode instead of freefall mode (trigger if >threshold).
+ per default an interrupt occurs if motion values fall below the
+ value set in "threshold" and therefore can detect free fall on the
+ vertical axis (depending on the position of the device).
+ Setting this values inverts the behaviour and an interrupt occurs
+ above the threshold value, so usually activate horizontal axis in
+ this case.
+
+- x-offset
+ 0 < value < 500: calibration offset in mg
+ this value has an offset of 250 itself:
+ 0 is -250mg, 250 is 0 mg, 500 is 250mg
+- y-offset
+ see x-offset
+- z-offset
+ see x-offset
+
+Example 1:
+for a device laying on flat ground to recognize acceleration over 100mg.
+x-axis is calibrated to +10mg. Adapt interrupt line to your device.
+
+mma8653fc@1d {
+ compatible = "fsl,mma8653fc";
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 0>;
+ reg = <0x1d>;
+
+ range = <2>;
+ motion_mode;
+ ir_freefall_motion_x;
+ ir_freefall_motion_y;
+ irq_threshold = <100>;
+ x-offset = <160>;
+};
+
+Example 2:
+for a device mounted on a wall with y being the vertical axis. This recognizes
+y-acceleration below 800mg, so free fall or changing the orientation of the
+device (y not being the vertical axis and having ~1000mg anymore).
+
+mma8653fc@1d {
+ compatible = "fsl,mma8653fc";
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 0>;
+ reg = <0x1d>;
+
+ range = <2>;
+ ir_freefall_motion_y;
+ irq_threshold = <800>;
+};
+
+Example 3:
+minimal example. lets users read current acceleration values. No polling
+is available.
+
+mma8653fc@1d {
+ compatible = "fsl,mma8653fc";
+ reg = <0x1d>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 0e1abe8..b8c597b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4104,6 +4104,12 @@ S: Maintained
F: include/linux/platform_data/video-imxfb.h
F: drivers/video/fbdev/imxfb.c
+FREESCALE MMA8653FC ACCELEROMETER I2C DRIVER
+M: Martin Kepplinger <martin.kepplinger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
+S: Maintained
+F: drivers/input/misc/mma8653fc.c
+F: Documentation/devicetree/bindings/i2c/mma8653fc.txt
+
FREESCALE QUAD SPI DRIVER
M: Han Xu <han.xu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
L: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6deb8da..70d9bf5 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -208,6 +208,17 @@ config INPUT_MMA8450
To compile this driver as a module, choose M here: the
module will be called mma8450.
+config INPUT_MMA8653FC
+ tristate "MMA8653FC - Freescale's 3-Axis, 10-bit Digital Accelerometer"
+ depends on I2C
+ default n
+ help
+ Say Y here if you want to support Freescale's MMA8653FC Accelerometer
+ through I2C interface.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mma8653fc.
+
config INPUT_MPU3050
tristate "MPU3050 Triaxial gyroscope sensor"
depends on I2C
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 403a1a5..0bcd878 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_INPUT_MAX8925_ONKEY) += max8925_onkey.o
obj-$(CONFIG_INPUT_MAX8997_HAPTIC) += max8997_haptic.o
obj-$(CONFIG_INPUT_MC13783_PWRBUTTON) += mc13783-pwrbutton.o
obj-$(CONFIG_INPUT_MMA8450) += mma8450.o
+obj-$(CONFIG_INPUT_MMA8653FC) += mma8653fc.o
obj-$(CONFIG_INPUT_MPU3050) += mpu3050.o
obj-$(CONFIG_INPUT_PALMAS_PWRBUTTON) += palmas-pwrbutton.o
obj-$(CONFIG_INPUT_PCAP) += pcap_keys.o
diff --git a/drivers/input/misc/mma8653fc.c b/drivers/input/misc/mma8653fc.c
new file mode 100644
index 0000000..7938094
--- /dev/null
+++ b/drivers/input/misc/mma8653fc.c
@@ -0,0 +1,907 @@
+/*
+ * mma8653fc.c - Support for Freescale MMA8653FC 3-axis 10-bit accelerometer
+ *
+ * Copyright (c) 2014 Theobroma Systems Design and Consulting GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/device.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/i2c.h>
+#include <linux/types.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
+
+#define DRV_NAME "mma8653fc"
+#define MMA8653FC_DEVICE_ID 0x5a
+
+#define MMA8653FC_STATUS 0x00
+
+#define ZYXOW_MASK 0x80
+#define ZYXDR 0x08
+
+#define MMA8653FC_WHO_AM_I 0x0d
+
+#define MMA8653FC_SYSMOD 0x0b
+#define STATE_STANDBY 0x00
+#define STATE_WAKE 0x01
+#define STATE_SLEEP 0x02
+
+#define MMA8450_STATUS_ZXYDR 0x08
+
+/*
+ * 10 bit output data registers
+ * MSB: 7:0 bits 9:2 of data word
+ * LSB: 7:6 bits 1:0 of data word
+ */
+#define MMA8653FC_OUT_X_MSB 0x01
+#define MMA8653FC_OUT_X_LSB 0x02
+#define MMA8653FC_OUT_Y_MSB 0x03
+#define MMA8653FC_OUT_Y_LSB 0x04
+#define MMA8653FC_OUT_Z_MSB 0x05
+#define MMA8653FC_OUT_Z_LSB 0x06
+
+/*
+ * Portrait/Landscape Status
+ */
+#define MMA8653FC_PL_STATUS 0x10
+
+#define NEWLP 0x80
+#define LAPO_HIGH 0x04
+#define LAPO_LOW 0x02
+#define BAFRO 0x01
+
+/*
+ * Portrait/Landscape Configuration
+ */
+#define MMA8653FC_PL_CFG 0x11
+
+#define PL_EN (1 << 6)
+
+/*
+ * Data calibration registers
+ */
+#define MMA8653FC_OFF_X 0x2f
+#define MMA8653FC_OFF_Y 0x30
+#define MMA8653FC_OFF_Z 0x31
+
+/* 0 to 500 for dts, but -250 to 250 in mg */
+#define DEFAULT_OFF 250
+
+/*
+ * bits 1:0 dynamic range
+ * 00 +/- 2g
+ * 01 +/- 4g
+ * 10 +/- 8g
+ *
+ * HPF_Out bit 4 - data high pass or low pass filtered
+ */
+#define MMA8653FC_XYZ_DATA_CFG 0x0e
+
+#define RANGE_MASK 0x03
+#define RANGE2G 0x00
+#define RANGE4G 0x01
+#define RANGE8G 0x02
+/* values for calculation */
+#define SHIFT_2G 8
+#define INCR_2G 128
+#define SHIFT_4G 7
+#define INCR_4G 64
+#define SHIFT_8G 6
+#define INCR_8G 32
+#define DYN_RANGE_2G 2
+#define DYN_RANGE_4G 4
+#define DYN_RANGE_8G 8
+
+/*
+ * System Control Reg 1
+ */
+#define MMA8653FC_CTRL_REG1 0x2a
+
+#define ACTIVE_BIT (1 << 0)
+#define ODR_MASK 0x38
+#define ODR_DEFAULT 0x20 /* 50 Hz */
+#define ASLP_RATE_MASK 0xc0
+#define ASLP_RATE_DEFAULT 0x80 /* 6.25 Hz */
+
+/*
+ * Sys Control Reg 2
+ *
+ * auto-sleep enable, software reset
+ */
+#define MMA8653FC_CTRL_REG2 0x2b
+
+#define SLPE (1 << 2)
+#define SELFTEST (1 << 7)
+#define SOFT_RESET (1 << 6)
+
+/*
+ * Interrupt Source
+ */
+#define MMA8653FC_INT_SOURCE 0x0c
+
+#define SRC_ASLP (1 << 7)
+#define SRC_LNDPRT (1 << 4)
+#define SRC_FF_MT (1 << 2)
+#define SRC_DRDY (1 << 0)
+
+/*
+ * Interrupt Control Register
+ *
+ * default: active low
+ * default push-pull, not open-drain
+ */
+#define MMA8653FC_CTRL_REG3 0x2c
+
+#define WAKE_LNDPRT (1 << 5)
+#define WAKE_FF_MT (1 << 3)
+#define IPOL (1 << 1)
+#define PP_OD (1 << 0)
+
+/*
+ * Interrupt Enable Register
+ */
+#define MMA8653FC_CTRL_REG4 0x2d
+
+#define INT_EN_ASLP (1 << 7)
+#define INT_EN_LNDPRT (1 << 4)
+#define INT_EN_FF_MT (1 << 2)
+#define INT_EN_DRDY (1 << 0)
+
+/*
+ * Interrupt Configuration Register
+ * bit value 0 ... INT2 (default)
+ * bit value 1 ... INT1
+ */
+#define MMA8653FC_CTRL_REG5 0x2e
+
+#define INT_CFG_ASLP (1 << 7)
+#define INT_CFG_LNDPRT (1 << 4)
+#define INT_CFG_FF_MT (1 << 2)
+#define INT_CFG_DRDY (1 << 0)
+
+/*
+ * Freefall / Motion Configuration Register
+ *
+ * Event Latch enable/disable, motion or freefall mode
+ * and event flag enable per axis
+ */
+#define MMA8653FC_FF_MT_CFG 0x15
+
+#define FF_MT_CFG_ELE (1 << 7)
+#define FF_MT_CFG_OAE (1 << 6)
+#define FF_MT_CFG_ZEFE (1 << 5)
+#define FF_MT_CFG_YEFE (1 << 4)
+#define FF_MT_CFG_XEFE (1 << 3)
+
+/*
+ * Freefall / Motion Source Register
+ */
+#define MMA8653FC_FF_MT_SRC 0x16
+
+/*
+ * Freefall / Motion Threshold Register
+ *
+ * define motion threshold
+ * 0.063 g/LSB, 127 counts(0x7f) (7 bit from LSB)
+ * range: 0.063g - 8g
+ */
+#define MMA8653FC_FF_MT_THS 0x17
+
+struct axis_triple {
+ s16 x;
+ s16 y;
+ s16 z;
+};
+
+struct mma8653fc_pdata {
+ s8 x_axis_offset;
+ s8 y_axis_offset;
+ s8 z_axis_offset;
+ bool auto_wake_sleep;
+ u32 range;
+ bool int1;
+ bool int_active_high;
+ bool motion_mode;
+ u8 freefall_motion_thr;
+ bool int_src_data_ready;
+ bool int_src_ff_mt_x;
+ bool int_src_ff_mt_y;
+ bool int_src_ff_mt_z;
+ bool int_src_lndprt;
+ bool int_src_aslp;
+};
+
+struct mma8653fc {
+ struct i2c_client *client;
+ struct mutex mutex;
+ struct mma8653fc_pdata pdata;
+ struct axis_triple saved;
+ char orientation;
+ char bafro;
+ bool standby;
+ int irq;
+ unsigned int_mask;
+ u8 (*read)(struct mma8653fc *, unsigned char);
+ int (*write)(struct mma8653fc *, unsigned char, unsigned char);
+};
+
+/* defaults */
+static const struct mma8653fc_pdata mma8653fc_default_init = {
+ .range = 2,
+ .x_axis_offset = DEFAULT_OFF,
+ .y_axis_offset = DEFAULT_OFF,
+ .z_axis_offset = DEFAULT_OFF,
+ .auto_wake_sleep = false,
+ .int1 = false,
+ .int_active_high = false,
+ .motion_mode = false,
+ .freefall_motion_thr = 5,
+ .int_src_data_ready = false,
+ .int_src_ff_mt_x = false,
+ .int_src_ff_mt_y = false,
+ .int_src_ff_mt_z = false,
+ .int_src_lndprt = false,
+ .int_src_aslp = false,
+};
+
+static void mma8653fc_get_triple(struct mma8653fc *mma)
+{
+ u8 buf[6];
+ u8 status;
+
+ buf[0] = 0;
+
+ status = mma->read(mma, MMA8653FC_STATUS);
+ if (status & ZYXOW_MASK)
+ dev_dbg(&mma->client->dev, "previous read not completed\n");
+
+ buf[0] = mma->read(mma, MMA8653FC_OUT_X_MSB);
+ buf[1] = mma->read(mma, MMA8653FC_OUT_X_LSB);
+ buf[2] = mma->read(mma, MMA8653FC_OUT_Y_MSB);
+ buf[3] = mma->read(mma, MMA8653FC_OUT_Y_LSB);
+ buf[4] = mma->read(mma, MMA8653FC_OUT_Z_MSB);
+ buf[5] = mma->read(mma, MMA8653FC_OUT_Z_LSB);
+
+ mutex_lock(&mma->mutex);
+ /* move from registers to s16 */
+ mma->saved.x = (buf[1] | (buf[0] << 8)) >> 6;
+ mma->saved.y = (buf[3] | (buf[2] << 8)) >> 6;
+ mma->saved.z = (buf[5] | (buf[4] << 8)) >> 6;
+ mma->saved.x = sign_extend32(mma->saved.x, 9);
+ mma->saved.y = sign_extend32(mma->saved.y, 9);
+ mma->saved.z = sign_extend32(mma->saved.z, 9);
+
+ /* calc g, see data sheet and application note */
+ switch (mma->pdata.range) {
+ case DYN_RANGE_2G:
+ mma->saved.x = le16_to_cpu((1000 * mma->saved.x +
+ INCR_2G) >> SHIFT_2G);
+ mma->saved.y = le16_to_cpu((1000 * mma->saved.y +
+ INCR_2G) >> SHIFT_2G);
+ mma->saved.z = le16_to_cpu((1000 * mma->saved.z +
+ INCR_2G) >> SHIFT_2G);
+ break;
+ case DYN_RANGE_4G:
+ mma->saved.x = le16_to_cpu((1000 * mma->saved.x +
+ INCR_4G) >> SHIFT_4G);
+ mma->saved.y = le16_to_cpu((1000 * mma->saved.y +
+ INCR_4G) >> SHIFT_4G);
+ mma->saved.z = le16_to_cpu((1000 * mma->saved.z +
+ INCR_4G) >> SHIFT_4G);
+ break;
+ case DYN_RANGE_8G:
+ mma->saved.x = le16_to_cpu((1000 * mma->saved.x +
+ INCR_8G) >> SHIFT_8G);
+ mma->saved.y = le16_to_cpu((1000 * mma->saved.y +
+ INCR_8G) >> SHIFT_8G);
+ mma->saved.z = le16_to_cpu((1000 * mma->saved.z +
+ INCR_8G) >> SHIFT_8G);
+ break;
+ default:
+ dev_err(&mma->client->dev, "internal data corrupt\n");
+ }
+ mutex_unlock(&mma->mutex);
+}
+
+static void mma8653fc_get_orientation(struct mma8653fc *mma, u8 byte)
+{
+ if ((byte & LAPO_HIGH) && !(LAPO_LOW))
+ mma->orientation = 'r'; /* landscape right */
+ if (!(byte & LAPO_HIGH) && (byte & LAPO_LOW))
+ mma->orientation = 'd'; /* portrait down */
+ if (!(byte & LAPO_HIGH) && !(byte & LAPO_LOW))
+ mma->orientation = 'u'; /* portrait up */
+ if ((byte & LAPO_HIGH) && (byte & LAPO_LOW))
+ mma->orientation = 'l'; /* landscape left */
+
+ if (byte & BAFRO)
+ mma->bafro = 'b'; /* back facing */
+ else
+ mma->bafro = 'f'; /* front facing */
+}
+
+static irqreturn_t mma8653fc_irq(int irq, void *handle)
+{
+ struct mma8653fc *mma = handle;
+ u8 int_src;
+ u8 byte;
+
+ int_src = mma->read(mma, MMA8653FC_INT_SOURCE);
+ if (int_src & SRC_DRDY)
+ /* data ready handle */
+ if (int_src & SRC_FF_MT) {
+ /* freefall/motion change handle */
+ dev_dbg(&mma->client->dev,
+ "freefall or motion change\n");
+ byte = mma->read(mma, MMA8653FC_FF_MT_SRC);
+ }
+ if (int_src & SRC_LNDPRT) {
+ /* landscape/portrait change handle */
+ dev_dbg(&mma->client->dev,
+ "landscape / portrait change\n");
+ byte = mma->read(mma, MMA8653FC_PL_STATUS);
+ mma8653fc_get_orientation(mma, byte);
+ }
+ if (int_src & SRC_ASLP)
+ /* autosleep change handle */
+ mma8653fc_get_triple(mma);
+
+ sysfs_notify(&mma->client->dev.kobj, NULL, "position");
+
+ return IRQ_HANDLED;
+}
+
+static void __mma8653fc_enable(struct mma8653fc *mma)
+{
+ u8 byte;
+
+ byte = mma->read(mma, MMA8653FC_CTRL_REG1);
+ mma->write(mma, MMA8653FC_CTRL_REG1, byte | ACTIVE_BIT);
+}
+
+static void __mma8653fc_disable(struct mma8653fc *mma)
+{
+ u8 byte;
+
+ byte = mma->read(mma, MMA8653FC_CTRL_REG1);
+ mma->write(mma, MMA8653FC_CTRL_REG1, byte & ~ACTIVE_BIT);
+}
+
+static ssize_t mma8653fc_standby_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct mma8653fc *mma = i2c_get_clientdata(client);
+
+ return scnprintf(buf, PAGE_SIZE, "%u\n", mma->standby);
+}
+
+static ssize_t mma8653fc_standby_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct mma8653fc *mma = i2c_get_clientdata(client);
+ unsigned int val;
+ int error;
+
+ error = kstrtouint(buf, 10, &val);
+ if (error)
+ return error;
+
+ mutex_lock(&mma->mutex);
+
+ if (val) {
+ if (!mma->standby)
+ __mma8653fc_disable(mma);
+ } else {
+ if (mma->standby)
+ __mma8653fc_enable(mma);
+ }
+
+ mma->standby = !!val;
+
+ mutex_unlock(&mma->mutex);
+
+ return count;
+}
+
+static DEVICE_ATTR(standby, 0664, mma8653fc_standby_show,
+ mma8653fc_standby_store);
+
+static ssize_t mma8653fc_currentmode_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct mma8653fc *mma = i2c_get_clientdata(client);
+ ssize_t count;
+ u8 byte;
+
+ byte = mma->read(mma, MMA8653FC_SYSMOD);
+ if (byte < 0)
+ return byte;
+
+ switch (byte) {
+ case STATE_STANDBY:
+ count = scnprintf(buf, PAGE_SIZE, "standby\n");
+ break;
+ case STATE_WAKE:
+ count = scnprintf(buf, PAGE_SIZE, "wake\n");
+ break;
+ case STATE_SLEEP:
+ count = scnprintf(buf, PAGE_SIZE, "sleep\n");
+ break;
+ default:
+ count = scnprintf(buf, PAGE_SIZE, "unknown\n");
+ }
+ return count;
+}
+static DEVICE_ATTR(currentmode, S_IRUGO, mma8653fc_currentmode_show, NULL);
+
+static ssize_t mma8653fc_position_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct mma8653fc *mma = i2c_get_clientdata(client);
+ ssize_t count;
+ u8 byte;
+
+ if (!mma->irq) {
+ byte = mma->read(mma, MMA8653FC_PL_STATUS);
+ if (byte & NEWLP)
+ mma8653fc_get_orientation(mma, byte);
+
+ byte = mma->read(mma, MMA8653FC_STATUS);
+ if (byte & ZYXDR)
+ mma8653fc_get_triple(mma);
+
+ msleep(20);
+ dev_dbg(&client->dev, "data polled\n");
+ }
+ mutex_lock(&mma->mutex);
+ count = scnprintf(buf, PAGE_SIZE, "%d %d %d %c %c\n",
+ mma->saved.x, mma->saved.y, mma->saved.z,
+ mma->orientation, mma->bafro);
+ mutex_unlock(&mma->mutex);
+
+ return count;
+}
+static DEVICE_ATTR(position, S_IRUGO, mma8653fc_position_show, NULL);
+
+static struct attribute *mma8653fc_attributes[] = {
+ &dev_attr_position.attr,
+ &dev_attr_standby.attr,
+ &dev_attr_currentmode.attr,
+ NULL,
+};
+
+static const struct attribute_group mma8653fc_attr_group = {
+ .attrs = mma8653fc_attributes,
+};
+
+static u8 mma8653fc_read(struct mma8653fc *mma, unsigned char reg)
+{
+ u8 val;
+
+ val = i2c_smbus_read_byte_data(mma->client, reg);
+ if (val < 0) {
+ dev_err(&mma->client->dev,
+ "failed to read %x register\n", reg);
+ }
+ return val;
+}
+
+static int mma8653fc_write(struct mma8653fc *mma, unsigned char reg,
+ unsigned char val)
+{
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(mma->client, reg, val);
+ if (ret) {
+ dev_err(&mma->client->dev,
+ "failed to write %x register\n", reg);
+ }
+ return ret;
+}
+
+static const struct of_device_id mma8653fc_dt_ids[] = {
+ { .compatible = "fsl,mma8653fc", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, mma8653fc_dt_ids);
+
+static const struct mma8653fc_pdata *mma8653fc_probe_dt(struct device *dev)
+{
+ struct mma8653fc_pdata *pdata;
+ struct device_node *node = dev->of_node;
+ const struct of_device_id *match;
+ u32 testu32;
+ s32 tests32;
+
+ if (!node) {
+ dev_err(dev, "no associated DT data\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ match = of_match_device(mma8653fc_dt_ids, dev);
+ if (!match) {
+ dev_err(dev, "unknown device model\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ *pdata = mma8653fc_default_init;
+
+ /* overwrite from dts */
+ testu32 = pdata->x_axis_offset;
+ tests32 = 0;
+ of_property_read_u32(node, "x-offset", &testu32);
+ tests32 = testu32 - DEFAULT_OFF;
+ if ((tests32) && (tests32 <= DEFAULT_OFF) &&
+ (tests32 >= -DEFAULT_OFF)) {
+ dev_info(dev, "use %dmg offset on X axis\n", tests32);
+ /* calc register value, resolution: 1.96mg */
+ pdata->x_axis_offset = (s8) (tests32 / 2);
+ }
+ testu32 = pdata->y_axis_offset;
+ tests32 = 0;
+ of_property_read_u32(node, "y-offset", &testu32);
+ tests32 = testu32 - DEFAULT_OFF;
+ if ((tests32) && (tests32 <= DEFAULT_OFF) &&
+ (tests32 >= -DEFAULT_OFF)) {
+ dev_info(dev, "use %dmg offset on Y axis\n", tests32);
+ pdata->y_axis_offset = (s8) (tests32 / 2);
+ }
+ testu32 = pdata->z_axis_offset;
+ tests32 = 0;
+ of_property_read_u32(node, "z-offset", &testu32);
+ tests32 = testu32 - DEFAULT_OFF;
+ if ((tests32) && (tests32 <= DEFAULT_OFF) &&
+ (tests32 >= -DEFAULT_OFF)) {
+ dev_info(dev, "use %dmg offset on Z axis\n", tests32);
+ pdata->z_axis_offset = (s8) (tests32 / 2);
+ }
+
+ testu32 = 0;
+ of_property_read_u32(node, "range", &testu32);
+ if ((testu32) && (testu32 != 2) && (testu32 != 4) && (testu32 != 8)) {
+ dev_warn(dev, "wrong value for full scale range in dtb\n");
+ } else {
+ if (testu32)
+ pdata->range = testu32;
+ }
+
+ if (of_property_read_bool(node, "auto_wake_sleep"))
+ pdata->auto_wake_sleep = true;
+
+ if (of_property_read_bool(node, "int1"))
+ pdata->int1 = true;
+
+ if (of_property_read_bool(node, "int_active_high"))
+ pdata->int_active_high = true;
+
+ if (of_property_read_bool(node, "motion_mode"))
+ pdata->motion_mode = true;
+
+ if (of_property_read_bool(node, "ir_data_ready"))
+ pdata->int_src_data_ready = true;
+
+ if (of_property_read_bool(node, "ir_freefall_motion_x"))
+ pdata->int_src_ff_mt_x = true;
+
+ if (of_property_read_bool(node, "ir_freefall_motion_y"))
+ pdata->int_src_ff_mt_y = true;
+
+ if (of_property_read_bool(node, "ir_freefall_motion_z"))
+ pdata->int_src_ff_mt_z = true;
+
+ if (of_property_read_bool(node, "ir_auto_wake"))
+ pdata->int_src_aslp = true;
+
+ if (of_property_read_bool(node, "ir_landscape_portrait"))
+ pdata->int_src_lndprt = true;
+
+ testu32 = 0;
+ of_property_read_u32(node, "irq_threshold", &testu32);
+ /* always uses maximum range +/- 8000g, resolution 63mg */
+ if ((testu32 <= 8000) && (testu32 > 0)) {
+ dev_dbg(dev, "use freefall / motion threshold %dmg\n",
+ testu32);
+ /* calculate register value from mg */
+ pdata->freefall_motion_thr = (testu32 / 63) + 1;
+ }
+
+ return pdata;
+}
+static int mma8653fc_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct mma8653fc *mma;
+ const struct mma8653fc_pdata *pdata;
+ int err;
+ u8 byte;
+
+ err = i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_BYTE_DATA);
+ if (!err) {
+ dev_err(&client->dev, "SMBUS Byte Data not Supported\n");
+ return -EIO;
+ }
+
+ mma = kzalloc(sizeof(*mma), GFP_KERNEL);
+ if (!mma) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+
+ pdata = dev_get_platdata(&client->dev);
+ if (!pdata) {
+ pdata = mma8653fc_probe_dt(&client->dev);
+ if (IS_ERR(pdata)) {
+ err = PTR_ERR(pdata);
+ pr_err("pdata from DT failed\n");
+ goto err_free_mem;
+ }
+ }
+ mma->pdata = *pdata;
+ pdata = &mma->pdata;
+ mma->client = client;
+ mma->read = &mma8653fc_read;
+ mma->write = &mma8653fc_write;
+
+ mutex_init(&mma->mutex);
+
+ i2c_set_clientdata(client, mma);
+
+ err = sysfs_create_group(&client->dev.kobj, &mma8653fc_attr_group);
+ if (err)
+ goto err_free_mem;
+
+ mma->irq = irq_of_parse_and_map(client->dev.of_node, 0);
+ if (!mma->irq) {
+ dev_err(&client->dev, "Unable to parse or map IRQ\n");
+ goto no_irq;
+ }
+
+ err = irq_set_irq_type(mma->irq, IRQ_TYPE_EDGE_FALLING);
+ if (err) {
+ dev_err(&client->dev, "set_irq_type failed\n");
+ goto err_free_mem;
+ }
+
+ err = request_threaded_irq(mma->irq, NULL, mma8653fc_irq, IRQF_ONESHOT,
+ dev_name(&mma->client->dev), mma);
+ if (err) {
+ dev_err(&client->dev, "irq %d busy?\n", mma->irq);
+ goto err_free_mem;
+ }
+
+ if (mma->write(mma, MMA8653FC_CTRL_REG2, SOFT_RESET))
+ goto err_free_irq;
+
+ __mma8653fc_disable(mma);
+ mma->standby = true;
+
+ /* enable desired interrupts */
+ mma->orientation = '\0';
+ mma->bafro = '\0';
+ byte = 0;
+ if (pdata->int_src_data_ready) {
+ byte |= INT_EN_DRDY;
+ dev_dbg(&client->dev, "DATA READY interrupt source enabled\n");
+ }
+ if (pdata->int_src_ff_mt_x || pdata->int_src_ff_mt_y ||
+ pdata->int_src_ff_mt_z) {
+ byte |= INT_EN_FF_MT;
+ dev_dbg(&client->dev, "FF MT interrupt source enabled\n");
+ }
+ if (pdata->int_src_lndprt) {
+ if (mma->write(mma, MMA8653FC_PL_CFG, PL_EN))
+ goto err_free_irq;
+ byte |= INT_EN_LNDPRT;
+ dev_dbg(&client->dev, "LNDPRT interrupt source enabled\n");
+ }
+ if (pdata->int_src_aslp) {
+ byte |= INT_EN_ASLP;
+ dev_dbg(&client->dev, "ASLP interrupt source enabled\n");
+ }
+ if (mma->write(mma, MMA8653FC_CTRL_REG4, byte))
+ goto err_free_irq;
+
+ /* force everything to line 1 */
+ if (pdata->int1) {
+ if (mma->write(mma, MMA8653FC_CTRL_REG5,
+ (INT_CFG_ASLP | INT_CFG_LNDPRT |
+ INT_CFG_FF_MT | INT_CFG_DRDY)))
+ goto err_free_irq;
+ dev_dbg(&client->dev, "using interrupt line 1\n");
+ }
+
+ /* force active high */
+ if (pdata->int_active_high) {
+ byte = mma->read(mma, MMA8653FC_CTRL_REG3);
+ if (byte < 0)
+ goto err_free_irq;
+ byte |= IPOL;
+ if (mma->write(mma, MMA8653FC_CTRL_REG3, byte))
+ goto err_free_irq;
+ dev_dbg(&client->dev, "using active high on interrupt line\n");
+ }
+no_irq:
+ /* range mode */
+ byte = mma->read(mma, MMA8653FC_XYZ_DATA_CFG);
+ byte &= ~RANGE_MASK;
+ switch (pdata->range) {
+ case DYN_RANGE_2G:
+ byte |= RANGE2G;
+ dev_dbg(&client->dev, "use 2g range\n");
+ break;
+ case DYN_RANGE_4G:
+ byte |= RANGE4G;
+ dev_dbg(&client->dev, "use 4g range\n");
+ break;
+ case DYN_RANGE_8G:
+ byte |= RANGE8G;
+ dev_dbg(&client->dev, "use 8g range\n");
+ break;
+ default:
+ dev_err(&client->dev, "wrong range mode value\n");
+ goto err_free_irq;
+ }
+ if (mma->write(mma, MMA8653FC_XYZ_DATA_CFG, byte))
+ goto err_free_irq;
+
+ /* data calibration offsets */
+ if (pdata->x_axis_offset) {
+ if (mma->write(mma, MMA8653FC_OFF_X, pdata->x_axis_offset))
+ goto err_free_irq;
+ }
+ if (pdata->y_axis_offset) {
+ if (mma->write(mma, MMA8653FC_OFF_Y, pdata->y_axis_offset))
+ goto err_free_irq;
+ }
+ if (pdata->z_axis_offset) {
+ if (mma->write(mma, MMA8653FC_OFF_Z, pdata->z_axis_offset))
+ goto err_free_irq;
+ }
+
+ /* if autosleep, wake on both landscape and motion changes */
+ if (pdata->auto_wake_sleep) {
+ byte = 0;
+ byte |= WAKE_LNDPRT;
+ byte |= WAKE_FF_MT;
+ if (mma->write(mma, MMA8653FC_CTRL_REG3, byte))
+ goto err_free_irq;
+ if (mma->write(mma, MMA8653FC_CTRL_REG2, SLPE))
+ goto err_free_irq;
+ dev_dbg(&client->dev, "auto sleep enabled\n");
+ }
+
+ /* data rates */
+ byte = 0;
+ byte = mma->read(mma, MMA8653FC_CTRL_REG1);
+ if (byte < 0)
+ goto err_free_irq;
+ byte &= ~ODR_MASK;
+ byte |= ODR_DEFAULT;
+ byte &= ~ASLP_RATE_MASK;
+ byte |= ASLP_RATE_DEFAULT;
+ if (mma->write(mma, MMA8653FC_CTRL_REG1, byte))
+ goto err_free_irq;
+
+ /* freefall / motion config */
+ byte = 0;
+ if (pdata->motion_mode) {
+ byte |= FF_MT_CFG_OAE;
+ dev_dbg(&client->dev, "detect motion instead of freefall\n");
+ }
+ byte |= FF_MT_CFG_ELE;
+ if (pdata->int_src_ff_mt_x)
+ byte |= FF_MT_CFG_XEFE;
+ if (pdata->int_src_ff_mt_y)
+ byte |= FF_MT_CFG_YEFE;
+ if (pdata->int_src_ff_mt_z)
+ byte |= FF_MT_CFG_ZEFE;
+ if (mma->write(mma, MMA8653FC_FF_MT_CFG, byte))
+ goto err_free_irq;
+
+ if (pdata->freefall_motion_thr) {
+ if (mma->write(mma, MMA8653FC_FF_MT_THS,
+ pdata->freefall_motion_thr))
+ goto err_free_irq;
+ /* calculate back to mg */
+ dev_dbg(&client->dev, "threshold set to %dmg\n",
+ (63 * pdata->freefall_motion_thr) - 1);
+ }
+
+ byte = mma->read(mma, MMA8653FC_WHO_AM_I);
+ if (byte != MMA8653FC_DEVICE_ID) {
+ dev_err(&client->dev, "wrong device for driver\n");
+ goto err_free_irq;
+ }
+ dev_info(&client->dev,
+ "accelerometer driver loaded. device id %x\n", byte);
+
+ return 0;
+
+ err_free_irq:
+ if (mma->irq)
+ free_irq(mma->irq, mma);
+ err_free_mem:
+ kfree(mma);
+ err_out:
+ return err;
+}
+
+static int mma8653fc_remove(struct i2c_client *client)
+{
+ struct mma8653fc *mma = i2c_get_clientdata(client);
+
+ free_irq(mma->irq, mma);
+ dev_dbg(&client->dev, "unregistered accelerometer\n");
+ kfree(mma);
+
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int mma8653fc_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct mma8653fc *mma = i2c_get_clientdata(client);
+
+ __mma8653fc_disable(mma);
+
+ return 0;
+}
+
+static int mma8653fc_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct mma8653fc *mma = i2c_get_clientdata(client);
+
+ __mma8653fc_enable(mma);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(mma8653fc_pm_ops, mma8653fc_suspend, mma8653fc_resume);
+#define MMA8653FC_PM_OPS (&mma8653fc_pm_ops)
+#else
+#define MMA8653FC_PM_OPS NULL
+#endif
+
+static const struct i2c_device_id mma8653fc_id[] = {
+ { DRV_NAME, 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, mma8653fc_id);
+
+static struct i2c_driver mma8653fc_driver = {
+ .driver = {
+ .name = DRV_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = mma8653fc_dt_ids,
+ .pm = MMA8653FC_PM_OPS,
+ },
+ .probe = mma8653fc_i2c_probe,
+ .remove = mma8653fc_remove,
+ .id_table = mma8653fc_id,
+};
+
+module_i2c_driver(mma8653fc_driver);
+
+MODULE_AUTHOR("Martin Kepplinger <martin.kepplinger-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org");
+MODULE_DESCRIPTION("Freescale's MMA8653FC Three-Axis Accelerometer I2C Driver");
+MODULE_LICENSE("GPL");
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v3 05/15] dt-bindings: Document the STM32 reset bindings
From: Maxime Coquelin @ 2015-03-17 16:57 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Uwe Kleine-König, Andreas Färber, Geert Uytterhoeven,
Rob Herring, Philipp Zabel, Linus Walleij, Arnd Bergmann,
Stefan Agner, Peter Meerwald, Paul Bolle, Jonathan Corbet,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Russell King,
Daniel Lezcano, Thomas Gleixner, Greg Kroah-Hartman, Jiri Slaby,
Andrew Morton, David S. Miller
In-Reply-To: <55022AC0.7090403@samsung.com>
Hi Chanwoo,
2015-03-13 1:09 GMT+01:00 Chanwoo Choi <cw00.choi@samsung.com>:
> Hi Maxime,
>
> On 03/13/2015 06:55 AM, Maxime Coquelin wrote:
>> From: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>>
>> This adds documentation of device tree bindings for the
>> STM32 reset controller.
>>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> ---
>> .../devicetree/bindings/reset/st,stm32-rcc.txt | 102 +++++++++++++++++++++
>> 1 file changed, 102 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
>> new file mode 100644
>> index 0000000..962f961
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
<snip>
>> + - can1: 281
>> + - can2: 282
>> + - pwr: 284
>> + - dac: 285
>> + - uart7: 286
>> + - uart8: 287
>> + - tim1: 288
>> + - tim8: 289
>> + - usart1: 292
>> + - usart6: 293
>> + - adc: 296
>> + - sdio: 299
>> + - spi1: 300
>> + - spi4: 301
>> + - syscfg: 302
>> + - tim9: 304
>> + - tim10: 305
>> + - tim11: 306
>> + - spi5: 308
>> + - spi6: 309
>> + - sai1: 310
>> + - ltdc: 31
>> +
>>
>
> Last line is un-necessary. When I applied this patch for test
> "new blank line at EOF" happen.
Thanks, that will be fixed in v4.
Kind regards,
Maxime
>
> +++ b/Documentation/devicetree/bindings/reset/st,stm32-rcc.txt
> @@ -99,4 +99,3 @@ List of indexes for STM32F429:
> - spi6: 309
> - sai1: 310
> - ltdc: 31
> -
>
> Thanks,
> Chanwoo Choi
>
^ permalink raw reply
* Re: [PATCH v2 tip/core/rcu 01/22] smpboot: Add common code for notification from dying CPU
From: Peter Zijlstra @ 2015-03-17 16:56 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, mingo, laijs, dipankar, akpm, mathieu.desnoyers,
josh, tglx, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, linux-api, linux-arch
In-Reply-To: <20150317140846.GB23123@twins.programming.kicks-ass.net>
On Tue, Mar 17, 2015 at 03:08:46PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 17, 2015 at 04:36:48AM -0700, Paul E. McKenney wrote:
> > On Tue, Mar 17, 2015 at 09:18:07AM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 16, 2015 at 11:37:45AM -0700, Paul E. McKenney wrote:
> > > > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > > >
> > > > RCU ignores offlined CPUs, so they cannot safely run RCU read-side code.
> > > > (They -can- use SRCU, but not RCU.) This means that any use of RCU
> > > > during or after the call to arch_cpu_idle_dead(). Unfortunately,
> > > > commit 2ed53c0d6cc99 added a complete() call, which will contain RCU
> > > > read-side critical sections if there is a task waiting to be awakened.
> > >
> > > Got a little more detail there?
> >
> > Quite possibly. But exactly what sort of detail are you looking for?
>
> What exact RCU usage you ran into that was problematic. It seems to
> imply that calling complete() -- from a dead cpu -- which ends up in
> try_to_wake_up() was the problem?
Hmm, I'm thinking its select_task_rq_*(). And yes, 'fixing' this in the
wake-up path will penalize everybody for the benefit of the very rare
case someone is doing a hotplug.
So yeah, maybe this is the best solution.. Ulgy though :/
^ permalink raw reply
* Re: [PATCH v2 tip/core/rcu 01/22] smpboot: Add common code for notification from dying CPU
From: Paul E. McKenney @ 2015-03-17 16:34 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, mingo, laijs, dipankar, akpm, mathieu.desnoyers,
josh, tglx, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, linux-api, linux-arch
In-Reply-To: <20150317140846.GB23123@twins.programming.kicks-ass.net>
On Tue, Mar 17, 2015 at 03:08:46PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 17, 2015 at 04:36:48AM -0700, Paul E. McKenney wrote:
> > On Tue, Mar 17, 2015 at 09:18:07AM +0100, Peter Zijlstra wrote:
> > > On Mon, Mar 16, 2015 at 11:37:45AM -0700, Paul E. McKenney wrote:
> > > > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > > >
> > > > RCU ignores offlined CPUs, so they cannot safely run RCU read-side code.
> > > > (They -can- use SRCU, but not RCU.) This means that any use of RCU
> > > > during or after the call to arch_cpu_idle_dead(). Unfortunately,
> > > > commit 2ed53c0d6cc99 added a complete() call, which will contain RCU
> > > > read-side critical sections if there is a task waiting to be awakened.
> > >
> > > Got a little more detail there?
> >
> > Quite possibly. But exactly what sort of detail are you looking for?
>
> What exact RCU usage you ran into that was problematic. It seems to
> imply that calling complete() -- from a dead cpu -- which ends up in
> try_to_wake_up() was the problem?
Yep, that was the one. At that point, the CPU can disappear without
any chance to tell RCU anything, so RCU has to have started ignoring
it beforehand. This bug has existed for a long time, masked by RCU's
waiting a jiffy before ignoring already-offline CPUs. Which would be a
problem if the CPU took longer than one jiffy to get from stop_machine()
to arch_cpu_idle_dead(). Which could actually, happen, especially
in a guest OS.
In addition, any tracing or printk()s on that code path (for example,
via lockdep) can also result in RCU read-side critical sections from an
offline CPU that RCU is ignoring.
So you would like me to pull this info into the commit log? Easy to
do if so.
Or am I missing your point?
Thanx, Paul
^ permalink raw reply
* Re: [PATCHv3 xfstests 2/3] generic: test openat and new O_BENEATH flag
From: Kees Cook @ 2015-03-17 15:33 UTC (permalink / raw)
To: Dave Chinner
Cc: David Drysdale, LKML, Alexander Viro, Eric W. Biederman,
Greg Kroah-Hartman, Meredydd Luff, Will Drewry,
Jorge Lucangeli Obes, Ricky Zhou, Lee Campbell, Julien Tinnes,
Mike Depinet, James Morris, Andy Lutomirski, Paolo Bonzini,
Paul Moore, Christoph Hellwig, Michael Kerrisk, Linux API,
linux-security-module, fstests
In-Reply-To: <20150316232434.GJ28557@dastard>
On Mon, Mar 16, 2015 at 4:24 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Mon, Mar 09, 2015 at 02:00:11PM +0000, David Drysdale wrote:
>> Test basic openat(2) behaviour.
>>
>> Test that if O_BENEATH flag is set, openat() will only
>> open paths that have no .. component and do not start
>> with /. Symlinks are also checked for the same restrictions.
>>
>> Signed-off-by: David Drysdale <drysdale@google.com>
>> ---
>> .gitignore | 1 +
>> common/openat | 61 ++++++++++++++++++++++++++++++
>> src/Makefile | 3 +-
>> src/openat.c | 100 +++++++++++++++++++++++++++++++++++++++++++++++++
>
> This strikes me as something that shoul dbe added to xfs_io for
> testing, as it already supports a heap of other open flags and
> xfstests is already dependent on it.
While I don't see a problem adding this to xfs_io, I'd still like to
see this test live in the kernel tree too. Having it in the same
source means more testing, IMO.
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* Re: [PATCH v2 tip/core/rcu 01/22] smpboot: Add common code for notification from dying CPU
From: Peter Zijlstra @ 2015-03-17 14:08 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, mingo, laijs, dipankar, akpm, mathieu.desnoyers,
josh, tglx, rostedt, dhowells, edumazet, dvhart, fweisbec, oleg,
bobby.prani, linux-api, linux-arch
In-Reply-To: <20150317113648.GC3589@linux.vnet.ibm.com>
On Tue, Mar 17, 2015 at 04:36:48AM -0700, Paul E. McKenney wrote:
> On Tue, Mar 17, 2015 at 09:18:07AM +0100, Peter Zijlstra wrote:
> > On Mon, Mar 16, 2015 at 11:37:45AM -0700, Paul E. McKenney wrote:
> > > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > >
> > > RCU ignores offlined CPUs, so they cannot safely run RCU read-side code.
> > > (They -can- use SRCU, but not RCU.) This means that any use of RCU
> > > during or after the call to arch_cpu_idle_dead(). Unfortunately,
> > > commit 2ed53c0d6cc99 added a complete() call, which will contain RCU
> > > read-side critical sections if there is a task waiting to be awakened.
> >
> > Got a little more detail there?
>
> Quite possibly. But exactly what sort of detail are you looking for?
What exact RCU usage you ran into that was problematic. It seems to
imply that calling complete() -- from a dead cpu -- which ends up in
try_to_wake_up() was the problem?
^ permalink raw reply
* Re: [PATCH v2 tip/core/rcu 01/22] smpboot: Add common code for notification from dying CPU
From: Paul E. McKenney @ 2015-03-17 11:36 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, mingo-DgEjT+Ai2ygdnm+yROfE0A,
laijs-BthXqXjhjHXQFUHtdCDX3A, dipankar-xthvdsQ13ZrQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
josh-iaAMLnmF4UmaiuxdJuQwMA, tglx-hfZtesqFncYOwBW4kG4KsQ,
rostedt-nx8X9YLhiw1AfugRpC6u6w, dhowells-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, dvhart-VuQAYsv1563Yd54FQh9/CA,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w, oleg-H+wXaHxf7aLQT0dZR+AlfA,
bobby.prani-Re5JQEeQqe8AvxtiuMwx3w,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arch-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150317081807.GQ2896-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
On Tue, Mar 17, 2015 at 09:18:07AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 16, 2015 at 11:37:45AM -0700, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> >
> > RCU ignores offlined CPUs, so they cannot safely run RCU read-side code.
> > (They -can- use SRCU, but not RCU.) This means that any use of RCU
> > during or after the call to arch_cpu_idle_dead(). Unfortunately,
> > commit 2ed53c0d6cc99 added a complete() call, which will contain RCU
> > read-side critical sections if there is a task waiting to be awakened.
>
> Got a little more detail there?
Quite possibly. But exactly what sort of detail are you looking for?
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 1/2] drm_modes: videomode: add pos/neg pixel clock polarity flag
From: Philipp Zabel @ 2015-03-17 10:43 UTC (permalink / raw)
To: Sébastien Szymanski
Cc: David Airlie, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Steve Longerbeam
In-Reply-To: <1426526944-16762-1-git-send-email-sebastien.szymanski-d2DlULPkwbNWk0Htik3J/w@public.gmane.org>
Hi Sébastien,
Am Montag, den 16.03.2015, 18:29 +0100 schrieb Sébastien Szymanski:
> From: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
>
> [Sébastien - rebase, update drm_display_mode_to_videomode function]
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Thanks for bringing this up again. This is a very crucial bit of
information that somehow needs to be communicated from the panel driver
to the crtc/encoder drivers. I vaguely remember that an earlier attempt
to add this flag to the userspace visible DRM_MODE_FLAGs was met with
resistance before, but I can't find it right now.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v0 01/11] stm class: Introduce an abstraction for System Trace Module devices
From: Alexander Shishkin @ 2015-03-17 10:37 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Greg Kroah-Hartman, linux-kernel@vger.kernel.org, Pratik Patel,
peter.lachner, norbert.schulz, keven.boell, yann.fouassier,
laurent.fert, linux-api
In-Reply-To: <CANLsYkzmnHSbfoWSEWkDx-UTuypALZv42FsZ0XVWz2bfqdGWZQ@mail.gmail.com>
Mathieu Poirier <mathieu.poirier@linaro.org> writes:
> On 7 March 2015 at 04:35, Alexander Shishkin
> <alexander.shishkin@linux.intel.com> wrote:
>> A System Trace Module (STM) is a device exporting data in System Trace
>> Protocol (STP) format as defined by MIPI STP standards. Examples of such
>> devices are Intel Trace Hub and Coresight STM.
>>
>> This abstraction provides a unified interface for software trace sources
>> to send their data over an STM device to a debug host. In order to do
>> that, such a trace source needs to be assigned a pair of master/channel
>> identifiers that all the data from this source will be tagged with. The
>> STP decoder on the debug host side will use these master/channel tags to
>> distinguish different trace streams from one another inside one STP
>> stream.
>>
>> This abstraction provides a configfs-based policy management mechanism
>> for dynamic allocation of these master/channel pairs based on trace
>> source-supplied string identifier. It has the flexibility of being
>> defined at runtime and at the same time (provided that the policy
>> definition is aligned with the decoding end) consistency.
>>
>> For userspace trace sources, this abstraction provides write()-based and
>> mmap()-based (if the underlying stm device allows this) output mechanism.
>>
>> For kernel-side trace sources, we provide "stm_source" device class that
>> can be connected to an stm device at run time.
>>
>> Cc: linux-api@vger.kernel.org
>> Cc: Pratik Patel <pratikp@codeaurora.org>
>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
>> ---
>> Documentation/ABI/testing/configfs-stp-policy | 44 ++
>> Documentation/ABI/testing/sysfs-class-stm | 14 +
>> Documentation/ABI/testing/sysfs-class-stm_source | 11 +
>> Documentation/trace/stm.txt | 77 +++
>> drivers/Kconfig | 2 +
>> drivers/Makefile | 1 +
>> drivers/stm/Kconfig | 8 +
>> drivers/stm/Makefile | 3 +
>> drivers/stm/core.c | 839 +++++++++++++++++++++++
>> drivers/stm/policy.c | 470 +++++++++++++
>> drivers/stm/stm.h | 77 +++
>> include/linux/stm.h | 87 +++
>> include/uapi/linux/stm.h | 47 ++
>> 13 files changed, 1680 insertions(+)
>> create mode 100644 Documentation/ABI/testing/configfs-stp-policy
>> create mode 100644 Documentation/ABI/testing/sysfs-class-stm
>> create mode 100644 Documentation/ABI/testing/sysfs-class-stm_source
>> create mode 100644 Documentation/trace/stm.txt
>> create mode 100644 drivers/stm/Kconfig
>> create mode 100644 drivers/stm/Makefile
>> create mode 100644 drivers/stm/core.c
>> create mode 100644 drivers/stm/policy.c
>> create mode 100644 drivers/stm/stm.h
>> create mode 100644 include/linux/stm.h
>> create mode 100644 include/uapi/linux/stm.h
>>
>
> [Snip...]
>
>> +
>> +static int stm_output_assign(struct stm_device *stm, unsigned int width,
>> + struct stp_policy_node *policy_node,
>> + struct stm_output *output)
>> +{
>> + unsigned int midx, cidx, mend, cend;
>> + int ret = -EBUSY;
>> +
>> + if (width > stm->data->sw_nchannels)
>> + return -EINVAL;
>> +
>> + if (policy_node) {
>
> Where does this get set? All I found is code that is switching on it.
It comes from stp_policy_node_lookup() in stm_file_assign() or
stm_source_link_add().
>> + stp_policy_node_get_ranges(policy_node,
>> + &midx, &mend, &cidx, &cend);
>> + } else {
>> + midx = stm->data->sw_start;
>> + cidx = 0;
>> + mend = stm->data->sw_end;
>> + cend = stm->data->sw_nchannels - 1;
>> + }
>> +
>> + spin_lock(&stm->mc_lock);
>> + if (output->nr_chans)
>> + goto unlock;
>> +
>> + ret = stm_find_master_chan(stm, width, &midx, mend, &cidx, cend);
>> + if (ret)
>> + goto unlock;
>> +
>> + output->master = midx;
>> + output->channel = cidx;
>> + output->nr_chans = width;
>> + stm_output_claim(stm, output);
>> + dev_dbg(stm->dev, "assigned %u:%u (+%u)\n", midx, cidx, width);
>> +
>> + ret = 0;
>> +unlock:
>> + spin_unlock(&stm->mc_lock);
>> +
>> + return ret;
>> +}
>> +
>
> [Snip...]
>
>> +
>> +/**
>> + * stm_source_register_device() - register an stm_source device
>> + * @parent: parent device
>> + * @data: device description structure
>> + *
>> + * This will create a device of stm_source class that can write
>> + * data to an stm device once linked.
>> + *
>> + * Return: 0 on success, -errno otherwise.
>> + */
>> +int stm_source_register_device(struct device *parent,
>> + struct stm_source_data *data)
>> +{
>> + struct stm_source_device *src;
>> + struct device *dev;
>> +
>> + if (!stm_core_up)
>> + return -EPROBE_DEFER;
>> +
>> + src = kzalloc(sizeof(*src), GFP_KERNEL);
>> + if (!src)
>> + return -ENOMEM;
>> +
>> + dev = device_create(&stm_source_class, parent, MKDEV(0, 0), NULL, "%s",
>> + data->name);
>> + if (IS_ERR(dev)) {
>> + kfree(src);
>> + return PTR_ERR(dev);
>> + }
>> +
>> + spin_lock_init(&src->link_lock);
>> + INIT_LIST_HEAD(&src->link_entry);
>> + src->dev = dev;
>> + src->data = data;
>> + data->src = src;
>> + dev_set_drvdata(dev, src);
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(stm_source_register_device);
>> +
>
> [Snip...]
>
> It's really not clear (at least to me) how stm_source_device works.
> They make a bridge between the kernel and the STM devices but the
> "link" between them is not obvious. More documentation perhaps?
Sure, I need to elaborate on this a bit. The idea the stm_source device
gets "linked" to an stm device by way of writing that stm device name to
its stm_source_link attribute and if everything's fine, stm_sounrce's
.link callback is called, after which it can start sending data out with
stm_sounce_write().
>> +/**
>> + * struct stm_data - STM device description and callbacks
>> + * @name: device name
>> + * @stm: internal structure, only used by stm class code
>> + * @sw_start: first STP master
>> + * @sw_end: last STP master
>> + * @sw_nchannels: number of STP channels per master
>> + * @sw_mmiosz: size of one channel's IO space, for mmap, optional
>> + * @write: write callback
>> + * @mmio_addr: mmap callback, optional
>> + *
>> + * Fill out this structure before calling stm_register_device() to create
>> + * an STM device and stm_unregister_device() to destroy it. It will also be
>> + * passed back to write() and mmio_addr() callbacks.
>> + */
>> +struct stm_data {
>> + const char *name;
>> + struct stm_device *stm;
>> + unsigned int sw_start;
>> + unsigned int sw_end;
>
> The above kernel doc is the only place where "sw_start" and "sw_end"
> are described as first and last STP masters. Other than that it takes
> a really long time to figure out what they really are. I think a
> better naming convention can be chosen here.
The idea is that only a certain subset of masters is available for
software (others being statically assigned to different hw blocks or
otherwise unavailable to software). These two mark start and end of this
subset.
>
>> + unsigned int sw_nchannels;
>> + unsigned int sw_mmiosz;
>> + ssize_t (*write)(struct stm_data *, unsigned int,
>> + unsigned int, const char *, size_t);
>> + phys_addr_t (*mmio_addr)(struct stm_data *, unsigned int,
>> + unsigned int, unsigned int);
>> + void (*link)(struct stm_data *, unsigned int,
>> + unsigned int);
>> + void (*unlink)(struct stm_data *, unsigned int,
>> + unsigned int);
>
> It is really not clear to me what the "link" and "unlink" functions do
> - documenting what they're for and explain when to use them and (not
> use them) would be appreciated.
Will do.
> I think we should also add two things to this structure: 1) a private
> field and 2) a (*stm_drv_ioctl) stub.
> The private field would be filled by the registrant and left alone by
> the generic-stm core. When parsing the commands in
> "stm_char_ioctl()", data->stm_drv_ioctl(private, cmd, arg) could be
> called to let architecture specific drivers deal with it. That way
> applications can deal with a single configuration file descriptor.
Indeed, good idea.
>
>> +};
>> +
>> +int stm_register_device(struct device *parent, struct stm_data *stm_data,
>> + struct module *owner);
>> +void stm_unregister_device(struct stm_data *stm_data);
>> +
>> +struct stm_source_device;
>> +
>> +/**
>> + * struct stm_source_data - STM source device description and callbacks
>> + * @name: device name, will be used for policy lookup
>> + * @src: internal structure, only used by stm class code
>> + * @nr_chans: number of channels to allocate
>> + * @link: called when STM device gets linked to this source
>> + * @unlink: called when STH device is about to be unlinked
>> + *
>> + * Fill in this structure before calling stm_source_register_device() to
>> + * register a source device. Also pass it to unregister and write calls.
>> + */
>> +struct stm_source_data {
>> + const char *name;
>> + struct stm_source_device *src;
>> + unsigned int percpu;
>> + unsigned int nr_chans;
>> + int (*link)(struct stm_source_data *data);
>> + void (*unlink)(struct stm_source_data *data);
>> +};
>> +
>
> I didn't get the linking/unlinking process - it is also not clear as
> to why we need struct stm_data and struct stm_source_data. More
> explanation on this would be good.
My idea is that connecting stm to stm_source device is done via sysfs
attribute write like so:
$ echo dummy_stm > /sys/class/stm_source/stm_console/stm_source_link
This will result in stm_source's .link getting called, at which point
stm_console, for example, will do a register_console().
stm_data is there for stm devices to pass their parameters and callbacks
to stm_register_device(); stm_source data is that for stm_source
devices. I'll try to be more elaborate about these in my followup.
>> +int stm_source_register_device(struct device *parent,
>> + struct stm_source_data *data);
>> +void stm_source_unregister_device(struct stm_source_data *data);
>> +
>> +int stm_source_write(struct stm_source_data *data, unsigned int chan,
>> + const char *buf, size_t count);
>> +
>> +#endif /* _STM_H_ */
>> diff --git a/include/uapi/linux/stm.h b/include/uapi/linux/stm.h
>> new file mode 100644
>> index 0000000000..042b58b53b
>> --- /dev/null
>> +++ b/include/uapi/linux/stm.h
>> @@ -0,0 +1,47 @@
>> +/*
>> + * System Trace Module (STM) userspace interfaces
>> + * Copyright (c) 2014, Intel Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
>> + * more details.
>> + *
>> + * STM class implements generic infrastructure for System Trace Module devices
>> + * as defined in MIPI STPv2 specification.
>> + */
>> +
>> +#ifndef _UAPI_LINUX_STM_H
>> +#define _UAPI_LINUX_STM_H
>> +
>> +/**
>> + * struct stp_policy_id - identification for the STP policy
>> + * @size: size of the structure including real id[] length
>> + * @master: assigned master
>> + * @channel: first assigned channel
>> + * @width: number of requested channels
>> + * @id: identification string
>> + *
>> + * User must calculate the total size of the structure and put it into
>> + * @size field, fill out the @id and desired @width. In return, kernel
>> + * fills out @master, @channel and @width.
>> + */
>> +struct stp_policy_id {
>> + __u32 size;
>> + __u16 master;
>> + __u16 channel;
>> + __u16 width;
>> + /* padding */
>> + __u16 __reserved_0;
>> + __u32 __reserved_1;
>> + char id[0];
>> +};
>> +
>> +#define STP_POLICY_ID_SET _IOWR('%', 0, struct stp_policy_id)
>> +#define STP_POLICY_ID_GET _IOR('%', 1, struct stp_policy_id)
>> +
>> +#endif /* _UAPI_LINUX_STM_H */
>> --
>> 2.1.4
>>
>
> Aside from the above points I think this is all very good work. The
> patchset should likely be broken up in two sets, one for the generic
> STM architecture wrapper and another for the Intel TH part. That way
> things can be worked on independently.
The Intel TH part is very much dependent on the STM part; I could split
out the stm-dependant patch from Intel TH, but that just seems to make
it more complex for me and reviewers. I'd prefer to keep them together
unless there are strong objections.
> On my side I will get a prototype going that folds the current
> coresight-stm driver in this new mindset - I'll let you know how
> things go.
Thanks a lot!
Regards,
--
Alex
^ permalink raw reply
* Re: [PATCH v0 01/11] stm class: Introduce an abstraction for System Trace Module devices
From: Alexander Shishkin @ 2015-03-17 10:13 UTC (permalink / raw)
To: Paul Bolle
Cc: Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Pratik Patel, mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A,
peter.lachner-ral2JQCrhuEAvxtiuMwx3w,
norbert.schulz-ral2JQCrhuEAvxtiuMwx3w,
keven.boell-ral2JQCrhuEAvxtiuMwx3w,
yann.fouassier-ral2JQCrhuEAvxtiuMwx3w,
laurent.fert-ral2JQCrhuEAvxtiuMwx3w,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1425767192.2300.37.camel@x220>
Paul Bolle <pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org> writes:
> On Sat, 2015-03-07 at 13:35 +0200, Alexander Shishkin wrote:
>> Documentation/ABI/testing/configfs-stp-policy | 44 ++
>
> git am whined about this file when I tried to apply this patch:
> Applying: stm class: Introduce an abstraction for System Trace Module devices
> [...]/.git/rebase-apply/patch:77: new blank line at EOF.
>
>> Documentation/ABI/testing/sysfs-class-stm | 14 +
>> Documentation/ABI/testing/sysfs-class-stm_source | 11 +
>> Documentation/trace/stm.txt | 77 +++
>> drivers/Kconfig | 2 +
>> drivers/Makefile | 1 +
>> drivers/stm/Kconfig | 8 +
>> drivers/stm/Makefile | 3 +
>> drivers/stm/core.c | 839 +++++++++++++++++++++++
>> drivers/stm/policy.c | 470 +++++++++++++
>> drivers/stm/stm.h | 77 +++
>> include/linux/stm.h | 87 +++
>> include/uapi/linux/stm.h | 47 ++
>
>> --- /dev/null
>> +++ b/drivers/stm/Kconfig
>> @@ -0,0 +1,8 @@
>> +config STM
>> + tristate "System Trace Module devices"
>> + help
>> + A System Trace Module (STM) is a device exporting data in System
>> + Trace Protocol (STP) format as defined by MIPI STP standards.
>> + Examples of such devices are Intel Trace Hub and Coresight STM.
>> +
>> + Say Y here to enable System Trace Module device support.
>> diff --git a/drivers/stm/Makefile b/drivers/stm/Makefile
>> new file mode 100644
>> index 0000000000..adec701649
>> --- /dev/null
>> +++ b/drivers/stm/Makefile
>> @@ -0,0 +1,3 @@
>> +obj-$(CONFIG_STM) += stm_core.o
>> +
>> +stm_core-y := core.o policy.o
>
> I tried to compile this as a module:
> $ make -C ../.. M=$PWD CONFIG_STM=m stm_core.ko
> make: Entering directory `[...]'
> LD [M] [...]/drivers/stm/stm_core.o
> [...]/drivers/stm/policy.o: In function `stp_configfs_init':
> policy.c:(.text+0x5f0): multiple definition of `init_module'
> [...]/drivers/stm/core.o:core.c:(.init.text+0x0): first defined here
> make[1]: *** [[...]/drivers/stm/stm_core.o] Error 1
> make: *** [stm_core.ko] Error 2
> make: Leaving directory `[...]'
>
> I think that's because
> postcore_initcall(stm_core_init);
>
> in core.c becomes
> module_init(stm_core_init);
>
> if this driver is compiled as a module. And that will clash with
> module_init(stp_configfs_init);
>
> in policy.c. Am I missing something obvious or should STM not be a
> tristate symbol?
My mistake, I think I fancied the policy to be a separate module in the
beginning. But I don't see why STM shouldn't be a tristate after the
above is fixed.
Thanks,
--
Alex
^ permalink raw reply
* Re: [v9 1/5] vfs: adds general codes to enforces project quota limits
From: Jan Kara @ 2015-03-17 9:37 UTC (permalink / raw)
To: Dave Chinner
Cc: Jan Kara, Li Xi, linux-fsdevel, linux-ext4, linux-api, tytso,
adilger, viro, hch, dmonakhov, dchinner
In-Reply-To: <20150316214930.GE28557@dastard>
On Tue 17-03-15 08:49:30, Dave Chinner wrote:
> On Mon, Mar 16, 2015 at 03:29:44PM +0100, Jan Kara wrote:
> > On Wed 11-03-15 12:03:19, Li Xi wrote:
> > > This patch adds support for a new quota type PRJQUOTA for project quota
> > > enforcement. Also a new method get_projid() is added into dquot_operations
> > > structure.
> > >
> > > Signed-off-by: Li Xi <lixi@ddn.com>
> > > Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
> > > Reviewed-by: Jan Kara <jack@suse.cz>
> > ...
> > > diff --git a/fs/quota/quota.c b/fs/quota/quota.c
> > > index 2aa4151..c76b350 100644
> > > --- a/fs/quota/quota.c
> > > +++ b/fs/quota/quota.c
> > > @@ -30,11 +30,15 @@ static int check_quotactl_permission(struct super_block *sb, int type, int cmd,
> > > case Q_XGETQSTATV:
> > > case Q_XQUOTASYNC:
> > > break;
> > > - /* allow to query information for dquots we "own" */
> > > + /*
> > > + * allow to query information for dquots we "own"
> > > + * always allow querying project quota
> > > + */
> > > case Q_GETQUOTA:
> > > case Q_XGETQUOTA:
> > > if ((type == USRQUOTA && uid_eq(current_euid(), make_kuid(current_user_ns(), id))) ||
> > > - (type == GRPQUOTA && in_egroup_p(make_kgid(current_user_ns(), id))))
> > > + (type == GRPQUOTA && in_egroup_p(make_kgid(current_user_ns(), id))) ||
> > > + (type == PRJQUOTA))
> > > break;
> > I wanted to merge this patch but this hunk caught my eye. Why do we
> > suddently allow querying of project quotas? Traditionally that has been
> > allowed only with CAP_SYS_ADMIN. I agree it looks too restrictive to me but
> > unless that's a bug, I think we have to adhere to original behavior and
> > drop this hunk. Dave, was that behavior of project quotas intended?
>
> This is for quota reports, right?
Yes.
> Project quotas are managed by the administrator as individual users
> may not even have access to all the files under a project and hence
> often cannot do anything about running out of quota space. i.e. users
> don't own project quotas like they "own" user and group quotas.
> user/group quotas imply the user has permission to access/modify the
> files within the quota, whereas that is not true of project quotas.
>
> e.g. Think about a project that compartmentalises information along
> user acess bounds: even if a user can't access parts of the project
> quota space, allowing them to query the accounting of space used by
> the project is leaking information about how much data there is in
> the project they can't access....
OK, thanks for the explanation. So Q_GETQUOTA and Q_XGETQUOTA for
PRJQUOTA have to stay for CAP_SYS_ADMIN capable processes only (at least
for now).
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ 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