* Re: [PATCH 00/11] locking/ww_mutex: Keep sorted wait list to avoid stampedes
From: Nicolai Hähnle @ 2016-11-30 13:40 UTC (permalink / raw)
To: Chris Wilson; +Cc: linux-kernel
In-Reply-To: <20161130122029.GP23336@nuc-i3427.alporthouse.com>
On 30.11.2016 13:20, Chris Wilson wrote:
> On Wed, Nov 30, 2016 at 12:52:28PM +0100, Nicolai Hähnle wrote:
>> On 30.11.2016 10:40, Chris Wilson wrote:
>>> On Mon, Nov 28, 2016 at 01:20:01PM +0100, Nicolai Hähnle wrote:
>>>> I've included timings taken from a contention-heavy stress test to some of
>>>> the patches. The stress test performs actual GPU operations which take a
>>>> good chunk of the wall time, but even so, the series still manages to
>>>> improve the wall time quite a bit.
>>>
>>> In looking at your contention scenarios, what was the average/max list
>>> size? Just wondering if it makes sense to use an rbtree + first_waiter
>>> instead of a sorted list from the start.
>>
>> I haven't measured this with the new series; previously, while I was
>> debugging the deadlock on older kernels, I occasionally saw wait
>> lists of up to ~20 tasks, spit-balling the average over all the
>> deadlock cases I'd say the average was not more than ~5. The average
>> _without_ deadlocks should be lower, if anything.
>
> Right, I wasn't expecting the list to be large, certainly no larger than
> cores typically. On the borderline of where a more complex tree starts
> to pay off.
>
>> I saw that your test cases go quite a bit higher, but even the
>> rather extreme load I was testing with -- which is not quite a load
>> from an actual application, though it is related to one -- has 40
>> threads and so a theoretical maximum of 40.
>
> The stress loads were just values plucked out of nowhere to try and have
> a reasonable stab at hitting the deadlock. Certainly if we were to wrap
> that up in a microbenchmark we would want to have wider coverage (so the
> graph against contention is more useful).
>
> Do you have a branch I can pull the patches for (or what did you use as
> the base)?
See git://people.freedesktop.org/~nh/linux mutex or
https://cgit.freedesktop.org/~nh/linux/log/?h=mutex.
It's based on tip/core/locking + agd5f's drm-next, the latter only
because I needed it for the test application.
Nicolai
^ permalink raw reply
* Re: [PATCH] IIO: Change msleep to usleep_range for small msecs
From: Lars-Peter Clausen @ 2016-11-30 13:35 UTC (permalink / raw)
To: Jonathan Cameron, Aniroop Mathur, knaack.h, pmeerw, linux-iio,
linux-kernel
Cc: s.samuel, r.mahale, aniroop.mathur, Naveen Krishna Chatradhi,
Linus Walleij, Vlad Dogaru
In-Reply-To: <fc667b4b-6d40-db6e-3855-7a181fa97458@kernel.org>
On 11/27/2016 11:51 AM, Jonathan Cameron wrote:
> On 26/11/16 03:47, Aniroop Mathur wrote:
>> msleep(1~20) may not do what the caller intends, and will often sleep longer.
>> (~20 ms actual sleep for any value given in the 1~20ms range)
>> This is not the desired behaviour for many cases like device resume time,
>> device suspend time, device enable time, data reading time, etc.
>> Thus, change msleep to usleep_range for precise wakeups.
>>
>> Signed-off-by: Aniroop Mathur <a.mathur@samsung.com>
> As these need individual review by the various original authors and driver maintainers to
> establish the intent of the sleep, it would have been better to have done a series of
> patches (one per driver) with the relevant maintainers cc'd on the ones that they care about.
>
> Most of these are ADI parts looked after by Lars though so perhaps wait for his comments
> before respining.
I agree with what Jonathan said. For most of these extending the maximum
sleep time a bit further is ok.
^ permalink raw reply
* Re: PROBLEM-PERSISTS: dmesg spam: alloc_contig_range: [XX, YY) PFNs busy
From: Michal Hocko @ 2016-11-30 13:28 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: Robin H. Johnson, linux-kernel, robbat2, linux-mm
In-Reply-To: <xa1ty4012k0f.fsf@mina86.com>
On Wed 30-11-16 14:08:00, Michal Nazarewicz wrote:
> On Wed, Nov 30 2016, Michal Hocko wrote:
> > [Let's CC linux-mm and Michal]
> >
> > On Tue 29-11-16 22:43:08, Robin H. Johnson wrote:
> >> I didn't get any responses to this.
> >>
> >> git bisect shows that the problem did actually exist in 4.5.0-rc6, but
> >> has gotten worse by many orders of magnitude (< 1/week to ~20M/hour).
> >>
> >> Presently with 4.9-rc5, it's now writing ~2.5GB/hour to syslog.
> >
> > This is really not helpful. I think we should simply make it pr_debug or
> > need some ratelimitting. AFAIU the message is far from serious
>
> On the other hand, if this didn’t happen and now happens all the time,
> this indicates a regression in CMA’s capability to allocate pages so
> just rate limiting the output would hide the potential actual issue.
Or there might be just a much larger demand on those large blocks, no?
But seriously, dumping those message again and again into the low (see
the 2.5_GB_/h to the log is just insane. So there really should be some
throttling.
Does the following help you Robin. At least to not get swamped by those
message.
---
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0fbfead6aa7d..96eb8d107582 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -7424,7 +7424,7 @@ int alloc_contig_range(unsigned long start, unsigned long end,
/* Make sure the range is really isolated. */
if (test_pages_isolated(outer_start, end, false)) {
- pr_info("%s: [%lx, %lx) PFNs busy\n",
+ printk_ratelimited(KERN_DEBUG "%s: [%lx, %lx) PFNs busy\n",
__func__, outer_start, end);
ret = -EBUSY;
goto done;
I would also suggest to add dump_stack() to that path to see who is
actually demanding so much large continuous blocks.
--
Michal Hocko
SUSE Labs
^ permalink raw reply related
* Re: [PATCH 1/1] mach-omap2: fixing wrong strcat for Non-NULL terminated string
From: Russell King - ARM Linux @ 2016-11-30 13:27 UTC (permalink / raw)
To: Maninder Singh
Cc: bcousson, paul, tony, linux-omap, linux-arm-kernel, linux-kernel,
ajeet.y, pankaj.m, Vaneet Narang
In-Reply-To: <1480502428-19509-1-git-send-email-maninder1.s@samsung.com>
On Wed, Nov 30, 2016 at 04:10:28PM +0530, Maninder Singh wrote:
> variable name can have Non NULL terminated string after cropping
> which may result strcat to fail, and cropping is not
> required if (strlen(oh->name) + 8 < MOD_CLK_MAX_NAME_LEN).
>
> Issue caught with static analysis tool:
> "Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)"
Maybe switch to strlcpy() ?
>
> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 759e1d4..8adf272 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -742,12 +742,15 @@ static int _init_main_clk(struct omap_hwmod *oh)
> char name[MOD_CLK_MAX_NAME_LEN];
> struct clk *clk;
>
> - /* +7 magic comes from '_mod_ck' suffix */
> - if (strlen(oh->name) + 7 > MOD_CLK_MAX_NAME_LEN)
> + /* +8 magic comes from strlen("_mod_ck") added as suffix */
> + if (strlen(oh->name) + 8 > MOD_CLK_MAX_NAME_LEN) {
> pr_warn("%s: warning: cropping name for %s\n", __func__,
> oh->name);
> + strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 8);
> + name[MOD_CLK_MAX_NAME_LEN - 8] = '\0';
> + } else
> + strcpy(name, oh->name);
>
> - strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
> strcat(name, "_mod_ck");
>
> clk = clk_get(NULL, name);
> --
> 1.9.1
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH net] tipc: check minimum bearer MTU
From: Michal Kubecek @ 2016-11-30 13:23 UTC (permalink / raw)
To: Ying Xue
Cc: Jon Maloy, David S. Miller, tipc-discussion, netdev, linux-kernel,
Ben Hutchings, Qian Zhang
In-Reply-To: <4a2da388-d798-11cf-bf2c-84207cae6159@windriver.com>
On Wed, Nov 30, 2016 at 06:28:14PM +0800, Ying Xue wrote:
...
> >diff --git a/net/tipc/bearer.h b/net/tipc/bearer.h
> >index 78892e2f53e3..1a0b7434ec24 100644
> >--- a/net/tipc/bearer.h
> >+++ b/net/tipc/bearer.h
> >@@ -39,6 +39,7 @@
> >
> > #include "netlink.h"
> > #include "core.h"
> >+#include "msg.h"
> > #include <net/genetlink.h>
> >
> > #define MAX_MEDIA 3
> >@@ -59,6 +60,9 @@
> > #define TIPC_MEDIA_TYPE_IB 2
> > #define TIPC_MEDIA_TYPE_UDP 3
> >
> >+/* minimum bearer MTU */
> >+#define TIPC_MIN_BEARER_MTU (MAX_H_SIZE + INT_H_SIZE)
> >+
> > /**
> > * struct tipc_media_addr - destination address used by TIPC bearers
> > * @value: address info (format defined by media)
> >@@ -215,4 +219,13 @@ void tipc_bearer_xmit(struct net *net, u32 bearer_id,
> > void tipc_bearer_bc_xmit(struct net *net, u32 bearer_id,
> > struct sk_buff_head *xmitq);
> >
> >+/* check if device MTU is sufficient for tipc headers */
> >+inline bool tipc_check_mtu(struct net_device *dev, unsigned int reserve)
>
> It's unnecessary to explicitly declare a function as inline, instead
> please let GCC smartly decide this.
This is a header file. But I just noticed the last change (adding
missing "static" keyword) is missing in the version I sent.
>
> >+{
> >+ if (dev->mtu >= TIPC_MIN_BEARER_MTU + reserve)
> >+ return false;
> >+ netdev_warn(dev, "MTU too low for tipc bearer\n");
> >+ return true;
> >+}
> >+
> > #endif /* _TIPC_BEARER_H */
> >diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
> >index 78cab9c5a445..376ed3e3ed46 100644
> >--- a/net/tipc/udp_media.c
> >+++ b/net/tipc/udp_media.c
> >@@ -697,6 +697,11 @@ static int tipc_udp_enable(struct net *net, struct tipc_bearer *b,
> > udp_conf.local_ip.s_addr = htonl(INADDR_ANY);
> > udp_conf.use_udp_checksums = false;
> > ub->ifindex = dev->ifindex;
> >+ if (tipc_check_mtu(dev, sizeof(struct iphdr) +
> >+ sizeof(struct udphdr))) {
> >+ err = -EINVAL;
> >+ goto err;
> >+ }
>
> For UDP bearer, it seems insufficient for us to check MTU size only
> when UDP bearer is enabled. Meanwhile, we should update MTU size for
> UDP bearer with Path MTU discovery protocol once MTU size is changed
> after bearer is enabled.
I should admit I'm not that familiar with tipc. Do you mean updating
b->mtu in response to PMTU updates of the route used for ub->ubsock?
The way I understand it, it would be certainly useful but it's not
directly related to the security issue this patch addresses as if there
are no updates, b->mtu cannot get too low and there is no risk of
a buffer overflow. In other words, reflecting PMTU updates is something
that can be IMHO left for later.
Michal Kubecek
^ permalink raw reply
* Add openrisc for-next branch to linux-next
From: Stafford Horne @ 2016-11-30 13:22 UTC (permalink / raw)
To: sfr; +Cc: linux-next, linux-kernel, openrisc
Hi Stephen,
I have been working on getting the OpenRISC backlog of fixes sorted out
for upstream. Can this branch be added to linux-next?
git://github.com/openrisc/linux.git for-next
These have been through a few reviews and we plan to ask Linus to pull in
the next merge window.
-Stafford
^ permalink raw reply
* Re: [RFC] pinctrl: imx: use radix trees for groups and functions
From: Fabio Estevam @ 2016-11-30 13:19 UTC (permalink / raw)
To: Gary Bisson
Cc: Linus Walleij, Shawn Guo, Peng Fan, linux-gpio@vger.kernel.org,
linux-kernel, Pantelis Antoniou, Vladimir Zapolskiy
In-Reply-To: <20161124233824.17424-1-gary.bisson@boundarydevices.com>
Hi Gary,
On Thu, Nov 24, 2016 at 9:38 PM, Gary Bisson
<gary.bisson@boundarydevices.com> wrote:
> This change is inspired from the pinctrl-single architecture.
>
> The problem with current implementation is that it isn't possible
> to add/remove functions and/or groups dynamically. The radix tree
> offers an easy way to do so. The intent is to offer a follow-up
> patch later that will enable the use of pinctrl nodes in dt-overlays.
Maybe you could re-post it including the follow-up patch that allows
the usage of pinctrl nodes in dt-overlays?
This way we can have a better picture of the final result.
Thanks
^ permalink raw reply
* [PATCH v2] ACPI / APEI: Fix NMI notification handling
From: Prarit Bhargava @ 2016-11-30 13:19 UTC (permalink / raw)
To: linux-kernel
Cc: Prarit Bhargava, Borislav Petkov, Rafael J. Wysocki, Len Brown,
Paul Gortmaker, Tyler Baicar, Punit Agrawal, Don Zickus
In-Reply-To: <20161129193624.krjz2bpinl2ioi7o@pd.tnic>
When removing and adding cpu 0 on a system with GHES NMI the following stack
trace is seen when re-adding the cpu:
WARNING: CPU: 0 PID: 0 at arch/x86/kernel/apic/apic.c:1349 setup_local_APIC+
Modules linked in: nfsv3 rpcsec_gss_krb5 nfsv4 nfs fscache coretemp intel_ra
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc6+ #2
Call Trace:
dump_stack+0x63/0x8e
__warn+0xd1/0xf0
warn_slowpath_null+0x1d/0x20
setup_local_APIC+0x275/0x370
apic_ap_setup+0xe/0x20
start_secondary+0x48/0x180
set_init_arg+0x55/0x55
early_idt_handler_array+0x120/0x120
x86_64_start_reservations+0x2a/0x2c
x86_64_start_kernel+0x13d/0x14c
During the cpu bringup, wakeup_cpu_via_init_nmi() is called and issues an
NMI on CPU 0. The GHES NMI handler, ghes_notify_nmi() runs the
ghes_proc_irq_work work queue which ends up setting IRQ_WORK_VECTOR
(0xf6). The "faulty" IR line set at arch/x86/kernel/apic/apic.c:1349 is also
0xf6 (specifically APIC IRR for irqs 255 to 224 is 0x400000) which confirms
that something has set the IRQ_WORK_VECTOR line prior to the APIC being
initialized.
Commit 2383844d4850 ("GHES: Elliminate double-loop in the NMI handler")
incorrectly modified the behavior such that the handler returns
NMI_HANDLED only if an error was processed, and incorrectly runs the ghes
work queue for every NMI.
This patch modifies the ghes_proc_irq_work() to run as it did prior to
2383844d4850 ("GHES: Elliminate double-loop in the NMI handler") by
properly returning NMI_HANDLED and only calling the work queue if
NMI_HANDLED has been set.
v2: Borislav, setting of NMI_HANDLED moved & cleaned up changelog.
Fixes: 2383844d4850 ("GHES: Elliminate double-loop in the NMI handler")
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Tyler Baicar <tbaicar@codeaurora.org>
Cc: Punit Agrawal <punit.agrawal@arm.com>
Cc: Don Zickus <dzickus@redhat.com>
---
drivers/acpi/apei/ghes.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 0d099a24f776..e53bef6cf53c 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -852,6 +852,8 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
if (ghes_read_estatus(ghes, 1)) {
ghes_clear_estatus(ghes);
continue;
+ } else {
+ ret = NMI_HANDLED;
}
sev = ghes_severity(ghes->estatus->error_severity);
@@ -863,12 +865,11 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
__process_error(ghes);
ghes_clear_estatus(ghes);
-
- ret = NMI_HANDLED;
}
#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
- irq_work_queue(&ghes_proc_irq_work);
+ if (ret == NMI_HANDLED)
+ irq_work_queue(&ghes_proc_irq_work);
#endif
atomic_dec(&ghes_in_nmi);
return ret;
--
1.7.9.3
^ permalink raw reply related
* Re: INFO: rcu_sched detected stalls on CPUs/tasks with `kswapd` and `mem_cgroup_shrink_node`
From: Michal Hocko @ 2016-11-30 13:19 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Donald Buczek, Paul Menzel, dvteam, linux-mm, linux-kernel,
Josh Triplett
In-Reply-To: <20161130115320.GO3924@linux.vnet.ibm.com>
On Wed 30-11-16 03:53:20, Paul E. McKenney wrote:
> On Wed, Nov 30, 2016 at 12:09:44PM +0100, Michal Hocko wrote:
> > [CCing Paul]
> >
> > On Wed 30-11-16 11:28:34, Donald Buczek wrote:
> > [...]
> > > shrink_active_list gets and releases the spinlock and calls cond_resched().
> > > This should give other tasks a chance to run. Just as an experiment, I'm
> > > trying
> > >
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -1921,7 +1921,7 @@ static void shrink_active_list(unsigned long
> > > nr_to_scan,
> > > spin_unlock_irq(&pgdat->lru_lock);
> > >
> > > while (!list_empty(&l_hold)) {
> > > - cond_resched();
> > > + cond_resched_rcu_qs();
> > > page = lru_to_page(&l_hold);
> > > list_del(&page->lru);
> > >
> > > and didn't hit a rcu_sched warning for >21 hours uptime now. We'll see.
> >
> > This is really interesting! Is it possible that the RCU stall detector
> > is somehow confused?
>
> No, it is not confused. Again, cond_resched() is not a quiescent
> state unless it does a context switch. Therefore, if the task running
> in that loop was the only runnable task on its CPU, cond_resched()
> would -never- provide RCU with a quiescent state.
Sorry for being dense here. But why cannot we hide the QS handling into
cond_resched()? I mean doesn't every current usage of cond_resched
suffer from the same problem wrt RCU stalls?
> In contrast, cond_resched_rcu_qs() unconditionally provides RCU
> with a quiescent state (hence the _rcu_qs in its name), regardless
> of whether or not a context switch happens.
>
> It is therefore expected behavior that this change might prevent
> RCU CPU stall warnings.
>
> Thanx, Paul
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] x86/boot: Fail the boot if !M486 and CPUID is missing
From: One Thousand Gnomes @ 2016-11-30 13:18 UTC (permalink / raw)
To: Andy Lutomirski
Cc: x86, Borislav Petkov, linux-kernel, Brian Gerst,
Matthew Whitehead
In-Reply-To: <70eac6639f23df8be5fe03fa1984aedd5d40077a.1479598603.git.luto@kernel.org>
> Rather than trying to work around these issues, just have the kernel
> fail loudly if it's running on a CPUID-less 486, doesn't have CPUID,
> and doesn't have CONFIG_M486 set.
NAK
This still breaks the Geode at the very least and I think the ELAN and
some of the other older socket 7 devices. These have their own config CPU
type (and in some cases *need* it selected) but do not have CPUID.
Given the cores without CPUID are often post 486 in other respects this
seems a bit odd. In fact I can't help thinking that the problem is that
sync_core tests CONFIG_M486 whereas we should have and test
HAVE_CPUID
and set this by processor type (M586/M486/GEODEGX1/GEODE_LX1/Cyrix plus I
think ELAN not having it)
I'd been wondering why Geode wasn't working on modern kernels, now I
think I know 8)
Alan
^ permalink raw reply
* Re: [PATCHv5 22/36] mm, hugetlb: switch hugetlbfs to multi-order radix-tree entries
From: Kirill A. Shutemov @ 2016-11-30 13:15 UTC (permalink / raw)
To: Hillf Danton
Cc: 'Theodore Ts'o', 'Andreas Dilger',
'Jan Kara', 'Andrew Morton',
'Alexander Viro', 'Hugh Dickins',
'Andrea Arcangeli', 'Dave Hansen',
'Vlastimil Babka', 'Matthew Wilcox',
'Ross Zwisler', linux-ext4, linux-fsdevel, linux-kernel,
linux-mm, linux-block, 'Naoya Horiguchi'
In-Reply-To: <017501d24aee$d9a189c0$8ce49d40$@alibaba-inc.com>
On Wed, Nov 30, 2016 at 05:48:05PM +0800, Hillf Danton wrote:
> On Tuesday, November 29, 2016 7:23 PM Kirill A. Shutemov wrote:
> > @@ -607,10 +605,10 @@ static long hugetlbfs_fallocate(struct file *file, int mode, loff_t offset,
> > }
> >
> > /* Set numa allocation policy based on index */
> > - hugetlb_set_vma_policy(&pseudo_vma, inode, index);
> > + hugetlb_set_vma_policy(&pseudo_vma, inode, index >> huge_page_order(h));
> >
> > /* addr is the offset within the file (zero based) */
> > - addr = index * hpage_size;
> > + addr = index << PAGE_SHIFT & ~huge_page_mask(h);
> >
> > /* mutex taken here, fault path and hole punch */
> > hash = hugetlb_fault_mutex_hash(h, mm, &pseudo_vma, mapping,
>
> Seems we can't use index in computing hash as long as it isn't in huge page size.
Look at changes in hugetlb_fault_mutex_hash(): we shift the index right by
huge_page_order(), before calculating the hash. I don't see a problem
here.
--
Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Javier Martinez Canillas @ 2016-11-30 13:11 UTC (permalink / raw)
To: Matt Ranostay
Cc: linux-wireless@vger.kernel.org, Linux Kernel,
devicetree@vger.kernel.org, linux-mmc@vger.kernel.org,
Tony Lindgren, Ulf Hansson, Mark Rutland, Srinivas Kandagatla
In-Reply-To: <CAJ_EiST_bpBm+spPuWH-a+47t4qVsDVFjUm=a+TtL-BWN3DHdw@mail.gmail.com>
Hello Matt,
On Tue, Nov 29, 2016 at 10:20 PM, Matt Ranostay
<matt@ranostay.consulting> wrote:
> On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
[snip]
>
>
>>> +- pwndn-gpio: contains a power down GPIO specifier.
>>> +- reset-gpio: contains a reset GPIO specifier.
>>> +
>>
>> I wonder if we really need a custom power sequence provider for just
>> this SDIO WiFI chip though. AFAICT the only missing piece in
>> mmc-pwrseq-simple is the power down GPIO property, so maybe
>> mmc-pwrseq-simple could be extended instead to have an optional
>> powerdown-gpios property and instead in the Marvell SD8787 DT binding
>> can be mentioned which mmc-pwrseq-simple properties are required for
>> the device.
>>
>
> The reason we didn't do that is we need delay between the two
> assertions/desertions of GPIOs. It wouldn't seems good practice to
> hack the pwrseq-simple for this...
>
Yes, I noticed that. I wouldn't say that it would be a hack for the
pwrseq-simple since it already has a "post-power-on-delay-ms" DT
property, so AFAICT it would just be adding a "pre-power-on-delay-ms"
property for your use case.
It would also be more consistent since it would support a delay for
pre and post power callbacks. It would also make you avoid hardcoding
the 300 msec wait, in case other device has a similar need but with a
different wait time.
In summary, I think that devices having a power (or power down) and
enable GPIO, and needing to wait between the GPIO toggling are common.
So I would prefer to make pwrseq-simple usable for these instead of
adding device specific power sequence providers. But it's just my
opinion and not my call :-)
>>> +Example:
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-sd8787";
>>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>>> + }
>>> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>
>> Does this patch depend on a previous posted series? I don't see this
>> file in today's linux-next...
>
> Got renamed to ->
> Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt it
> seems very recently.
>
I see, that's what I thought but I wasn't able to find the commit /
patch that did it.
>>
>>> index c421aba0a5bc..08fd65d35725 100644
>>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> @@ -32,6 +32,9 @@ Optional properties:
>>> so that the wifi chip can wakeup host platform under certain condition.
>>> during system resume, the irq will be disabled to make sure
>>> unnecessary interrupt is not received.
>>> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>>> + - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
>>> + for documentation of MMC power sequence bindings.
>>>
>>> Example:
>>>
>>> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side pin.
>>> &mmc3 {
>>> status = "okay";
>>> vmmc-supply = <&wlan_en_reg>;
>>> + mmc-pwrseq = <&wifi_pwrseq>;
>>> bus-width = <4>;
>>> cap-power-off-card;
>>> keep-power-in-suspend;
>>
>> I think this change should be split in a separate patch as well.
>>
You didn't answer about this, but I guess you agree it should be in a
separate patch.
Best regards,
Javier
^ permalink raw reply
* Re: PROBLEM-PERSISTS: dmesg spam: alloc_contig_range: [XX, YY) PFNs busy
From: Michal Nazarewicz @ 2016-11-30 13:08 UTC (permalink / raw)
To: Michal Hocko, Robin H. Johnson; +Cc: linux-kernel, robbat2, linux-mm
In-Reply-To: <20161130092239.GD18437@dhcp22.suse.cz>
On Wed, Nov 30 2016, Michal Hocko wrote:
> [Let's CC linux-mm and Michal]
>
> On Tue 29-11-16 22:43:08, Robin H. Johnson wrote:
>> I didn't get any responses to this.
>>
>> git bisect shows that the problem did actually exist in 4.5.0-rc6, but
>> has gotten worse by many orders of magnitude (< 1/week to ~20M/hour).
>>
>> Presently with 4.9-rc5, it's now writing ~2.5GB/hour to syslog.
>
> This is really not helpful. I think we should simply make it pr_debug or
> need some ratelimitting. AFAIU the message is far from serious
On the other hand, if this didn’t happen and now happens all the time,
this indicates a regression in CMA’s capability to allocate pages so
just rate limiting the output would hide the potential actual issue.
>
>> The list of addresses in that time is only ~80 unique ranges, each
>> appearing ~320K times. They don't appear exactly in order, so the kernel
>> does not squelch the log message for appearing too frequently.
>>
>> Could somebody at least make a suggestion on how to trace the printed
>> range to somewhere in the kernel?
>>
>> On Sat, Nov 19, 2016 at 03:25:32AM +0000, Robin H. Johnson wrote:
>> > (Replies CC to list and direct to me please)
>> >
>> > Summary:
>> > --------
>> > dmesg spammed with alloc_contig_range: [XX, YY) PFNs busy
>> >
>> > Description:
>> > ------------
>> > I recently upgrading 4.9-rc5, (previous kernel 4.5.0-rc6-00141-g6794402),
>> > and since then my dmesg has been absolutely flooded with 'PFNs busy'
>> > (>3GiB/day). My config did not change (all new options =n).
>> >
>> > It's not consistent addresses, so the squelch of identical printk lines
>> > hasn't helped.
>> > Eg output:
>> > [187487.621916] alloc_contig_range: [83f0a9, 83f0aa) PFNs busy
>> > [187487.621924] alloc_contig_range: [83f0ce, 83f0cf) PFNs busy
>> > [187487.621976] alloc_contig_range: [83f125, 83f126) PFNs busy
>> > [187487.622013] alloc_contig_range: [83f127, 83f128) PFNs busy
>> >
>> > Keywords:
>> > ---------
>> > mm, alloc_contig_range, CMA
>> >
>> > Most recent kernel version which did not have the bug:
>> > ------------------------------------------------------
>> > Known 4.5.0-rc6-00141-g6794402
>> >
>> > ver_linux:
>> > ----------
>> > Linux bohr-int 4.9.0-rc5-00177-g81bcfe5 #12 SMP Wed Nov 16 13:16:32 PST
>> > 2016 x86_64 Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz GenuineIntel
>> > GNU/Linux
>> >
>> > GNU C 5.3.0
>> > GNU Make 4.2.1
>> > Binutils 2.25.1
>> > Util-linux 2.29
>> > Mount 2.29
>> > Quota-tools 4.03
>> > Linux C Library 2.23
>> > Dynamic linker (ldd) 2.23
>> > readlink: missing operand
>> > Try 'readlink --help' for more information.
>> > Procps 3.3.12
>> > Net-tools 1.60
>> > Kbd 2.0.3
>> > Console-tools 2.0.3
>> > Sh-utils 8.25
>> > Udev 230
>> > Modules Loaded 3w_sas 3w_xxxx ablk_helper aesni_intel
>> > aes_x86_64 af_packet ahci aic79xx amdgpu async_memcpy async_pq
>> > async_raid6_recov async_tx async_xor ata_piix auth_rpcgss binfmt_misc
>> > bluetooth bnep bnx2 bonding btbcm btintel btrfs btrtl btusb button cdrom
>> > cn configs coretemp crc32c_intel crc32_pclmul crc_ccitt crc_itu_t
>> > crct10dif_pclmul cryptd dca dm_bio_prison dm_bufio dm_cache dm_cache_smq
>> > dm_crypt dm_delay dm_flakey dm_log dm_log_userspace dm_mirror dm_mod
>> > dm_multipath dm_persistent_data dm_queue_length dm_raid dm_region_hash
>> > dm_round_robin dm_service_time dm_snapshot dm_thin_pool dm_zero drm
>> > drm_kms_helper dummy e1000 e1000e evdev ext2 fat fb_sys_fops
>> > firewire_core firewire_ohci fjes fscache fuse ghash_clmulni_intel
>> > glue_helper grace hangcheck_timer hid_a4tech hid_apple hid_belkin
>> > hid_cherry hid_chicony hid_cypress hid_ezkey hid_generic hid_gyration
>> > hid_logitech hid_logitech_dj hid_microsoft hid_monterey hid_petalynx
>> > hid_pl hid_samsung hid_sony hid_sunplus hwmon_vid i2c_algo_bit i2c_i801
>> > i2c_smbus igb input_leds intel_rapl ip6_udp_tunnel ipv6 irqbypass
>> > iscsi_tcp iTCO_vendor_support iTCO_wdt ixgb ixgbe jfs kvm kvm_intel
>> > libahci libata libcrc32c libiscsi libiscsi_tcp linear lockd lpc_ich lpfc
>> > lrw macvlan mdio md_mod megaraid_mbox megaraid_mm megaraid_sas mii
>> > mptbase mptfc mptsas mptscsih mptspi multipath nfs nfs_acl nfsd
>> > nls_cp437 nls_iso8859_1 nvram ohci_hcd pata_jmicron pata_marvell
>> > pata_platform pcspkr psmouse qla1280 qla2xxx r8169 radeon raid0 raid10
>> > raid1 raid456 raid6_pq reiserfs rfkill sata_mv sata_sil24
>> > scsi_transport_fc scsi_transport_iscsi scsi_transport_sas
>> > scsi_transport_spi sd_mod sg sky2 snd snd_hda_codec
>> > snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec_realtek
>> > snd_hda_core snd_hda_intel snd_hwdep snd_pcm snd_timer soundcore sr_mod
>> > sunrpc syscopyarea sysfillrect sysimgblt tg3 ttm uas udp_tunnel
>> > usb_storage vfat virtio virtio_net virtio_ring vxlan w83627ehf
>> > x86_pkg_temp_thermal xfs xhci_hcd xhci_pci xor zlib_deflate
>>
>> --
>> Robin Hugh Johnson
>> E-Mail : robbat2@orbis-terrarum.net
>> Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
>> ICQ# : 30269588 or 41961639
>> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
>
>
>
> --
> Michal Hocko
> SUSE Labs
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
^ permalink raw reply
* Re: [PATCH net] vhost_net: don't continue to call the recvmsg when meet errors
From: Jason Wang @ 2016-11-30 13:07 UTC (permalink / raw)
To: Yunjian Wang, mst, netdev, linux-kernel; +Cc: caihe
In-Reply-To: <1480507857-22976-1-git-send-email-wangyunjian@huawei.com>
On 2016年11月30日 20:10, Yunjian Wang wrote:
> When we meet an error(err=-EBADFD) recvmsg, the error handling in vhost
> handle_rx() will continue. This will cause a soft CPU lockup in vhost thread.
>
> Signed-off-by: Yunjian Wang <wangyunjian@huawei.com>
> ---
> drivers/vhost/net.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 5dc128a..edc470b 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -717,6 +717,9 @@ static void handle_rx(struct vhost_net *net)
> pr_debug("Discarded rx packet: "
> " len %d, expected %zd\n", err, sock_len);
> vhost_discard_vq_desc(vq, headcount);
> + /* Don't continue to do, when meet errors. */
> + if (err < 0)
> + goto out;
> continue;
> }
> /* Supply virtio_net_hdr if VHOST_NET_F_VIRTIO_NET_HDR */
Acked-by: Jason Wang <jasowang@redhat.com>
We may want to rename vhost_discard_vq_desc() in the future, since it
does not discard the desc in fact.
^ permalink raw reply
* Re: [PATCH] mm: page_alloc: High-order per-cpu page allocator v3
From: Michal Hocko @ 2016-11-30 13:05 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, Christoph Lameter, Vlastimil Babka,
Johannes Weiner, Linux-MM, Linux-Kernel
In-Reply-To: <20161127131954.10026-1-mgorman@techsingularity.net>
On Sun 27-11-16 13:19:54, Mel Gorman wrote:
[...]
> @@ -2588,18 +2594,22 @@ struct page *buffered_rmqueue(struct zone *preferred_zone,
> struct page *page;
> bool cold = ((gfp_flags & __GFP_COLD) != 0);
>
> - if (likely(order == 0)) {
> + if (likely(order <= PAGE_ALLOC_COSTLY_ORDER)) {
> struct per_cpu_pages *pcp;
> struct list_head *list;
>
> local_irq_save(flags);
> do {
> + unsigned int pindex;
> +
> + pindex = order_to_pindex(migratetype, order);
> pcp = &this_cpu_ptr(zone->pageset)->pcp;
> - list = &pcp->lists[migratetype];
> + list = &pcp->lists[pindex];
> if (list_empty(list)) {
> - pcp->count += rmqueue_bulk(zone, 0,
> + int nr_pages = rmqueue_bulk(zone, order,
> pcp->batch, list,
> migratetype, cold);
> + pcp->count += (nr_pages << order);
> if (unlikely(list_empty(list)))
> goto failed;
just a nit, we can reorder the check and the count update because nobody
could have stolen pages allocated by rmqueue_bulk. I would also consider
nr_pages a bit misleading because we get a number or allocated elements.
Nothing to lose sleep over...
> }
But... Unless I am missing something this effectively means that we do
not exercise high order atomic reserves. Shouldn't we fallback to
the locked __rmqueue_smallest(zone, order, MIGRATE_HIGHATOMIC) for
order > 0 && ALLOC_HARDER ? Or is this just hidden in some other code
path which I am not seeing?
Other than that the patch looks reasonable to me. Keeping some portion
of !costly pages on pcp lists sounds useful from the fragmentation
point of view as well AFAICS because it would be normally dissolved for
order-0 requests while we push on the reclaim more right now.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v11 0/8] powerpc: Implement kexec_file_load()
From: Mimi Zohar @ 2016-11-30 13:03 UTC (permalink / raw)
To: Michael Ellerman
Cc: Andrew Morton, linuxppc-dev, linux-kernel, dyoung, stewart,
bauerman
In-Reply-To: <87inr5po0n.fsf@concordia.ellerman.id.au>
On Wed, 2016-11-30 at 15:52 +1100, Michael Ellerman wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
> > On Tue, 29 Nov 2016 23:45:46 +1100 Michael Ellerman <mpe@ellerman.id.au> wrote:
> >
> >> This is v11 of the kexec_file_load() for powerpc series.
> >>
> >> I've stripped this down to the minimum we need, so we can get this in for 4.10.
> >> Any additions can come later incrementally.
> >
> > This made a bit of a mess of Mimi's series "ima: carry the
> > measurement list across kexec v10".
>
> Urk, sorry about that. I didn't realise there was a big dependency
> between them, but I guess I should have tried to do the rebase.
>
> > powerpc-ima-get-the-kexec-buffer-passed-by-the-previous-kernel.patch
> > ima-on-soft-reboot-restore-the-measurement-list.patch
> > ima-permit-duplicate-measurement-list-entries.patch
> > ima-maintain-memory-size-needed-for-serializing-the-measurement-list.patch
> > powerpc-ima-send-the-kexec-buffer-to-the-next-kernel.patch
> > ima-on-soft-reboot-save-the-measurement-list.patch
> > ima-store-the-builtin-custom-template-definitions-in-a-list.patch
> > ima-support-restoring-multiple-template-formats.patch
> > ima-define-a-canonical-binary_runtime_measurements-list-format.patch
> > ima-platform-independent-hash-value.patch
> >
> > I made the syntactic fixes but I won't be testing it.
Dmitry Kasatkin's acked-by needs to be included for the IMA patches.
> Thanks.
>
> TBH I don't know how to test the IMA part, I'm relying on Thiago and
> Mimi to do that.
It should be straight forward. Enable CONFIG_IMA_KEXEC to carry the
measurements from one kernel to the next. Use a kexec_file_load version
of kexec to boot the next kernel. On the boot command line add
"ima_tcb" or "ima_policy=ima_tcb".
If the measurements were carried across kexec, the IMA measurement list
<securityfs>/ima/ascii_runtime_measurements should contain an initial
"boot_aggregate", as the first record, and a "boot_aggregate", as a
delimiter, for each subsequent kexec.
> >> If no one objects I'll merge this via the powerpc tree. The three kexec patches
> >> have been acked by Dave Young (since forever), and have been in linux-next (via
> >> akpm's tree) also for a long time.
> >
> > OK, I'll wait for these to appear in -next and I will await advice on
>
> Thanks. I'll let them stew for a few more hours and then put them in my
> next for tomorrows linux-next.
Thaigo tested the patches yesterday. Everything seemed fine. After
cherry picking the kexec_file_load() patches and rebasing the
restore_kexec patches on top of it in my tree, there were some problems.
Perhaps there is some dependencies that I'm missing.
Mimi
^ permalink raw reply
* Re: [PATCH 3/3] iio: st_pressure: Support i2c probe using acpi
From: Linus Walleij @ 2016-11-30 13:04 UTC (permalink / raw)
To: Shrirang Bagul
Cc: Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald, Denis CIOCCA, Tiberiu Breana, Lorenzo Bianconi,
Gregor Boirie, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1480393503.3233.5.camel@canonical.com>
On Tue, Nov 29, 2016 at 5:25 AM, Shrirang Bagul
<shrirang.bagul@canonical.com> wrote:
> Thank you Jonathan. I'll follow-up on Linus's suggestion and try and identify
> more of these sensors on some of the hardware we have in the lab. and try to add
> support for some more devices.
Thanks Shrirang, appreciated!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 0/2] Support for Axentia TSE-850
From: Peter Rosin @ 2016-11-30 12:48 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
linux-arm-kernel, devicetree
Hi!
changes v2 -> v3
- document the new compatible strings prefixed with "axentia,".
changes v1 -> v2
- squash the fixup into the correct patch, sorry for the noise.
After finally having all essintial drivers upstreamed (the
last ones are currently in -next) I would like to have the
dts and the defconfig also upstreamed.
Cheers,
Peter
Peter Rosin (2):
ARM: dts: add devicetree for the Axentia TSE-850
ARM: tse850_defconfig: add Axentia TSE-850
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/axentia-linea.dtsi | 53 +++++
arch/arm/boot/dts/axentia-tse850-3.dts | 276 ++++++++++++++++++++++
arch/arm/configs/tse850_defconfig | 223 +++++++++++++++++
6 files changed, 580 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/axentia-linea.dtsi
create mode 100644 arch/arm/boot/dts/axentia-tse850-3.dts
create mode 100644 arch/arm/configs/tse850_defconfig
--
2.1.4
^ permalink raw reply
* [PATCH v3 2/2] ARM: tse850_defconfig: add Axentia TSE-850
From: Peter Rosin @ 2016-11-30 12:48 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
linux-arm-kernel, devicetree
In-Reply-To: <1480510102-24587-1-git-send-email-peda@axentia.se>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
MAINTAINERS | 1 +
arch/arm/configs/tse850_defconfig | 223 ++++++++++++++++++++++++++++++++++++++
2 files changed, 224 insertions(+)
create mode 100644 arch/arm/configs/tse850_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 9dfe877f47e0..d8eb3843dbd4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2345,6 +2345,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/arm/axentia.txt
F: arch/arm/boot/dts/axentia-*
+F: arch/arm/configs/tse850_defconfig
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/arch/arm/configs/tse850_defconfig b/arch/arm/configs/tse850_defconfig
new file mode 100644
index 000000000000..f6076e7e1669
--- /dev/null
+++ b/arch/arm/configs/tse850_defconfig
@@ -0,0 +1,223 @@
+# CONFIG_LOCALVERSION_AUTO is not set
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+# CONFIG_FHANDLE is not set
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_EMBEDDED=y
+CONFIG_SLAB=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_AT91=y
+CONFIG_SOC_SAMA5D3=y
+# CONFIG_CACHE_L2X0 is not set
+CONFIG_AEABI=y
+CONFIG_UACCESS_WITH_MEMCPY=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x21100000,25165824 root=/dev/ram0 rw"
+CONFIG_KEXEC=y
+CONFIG_VFP=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_PACKET_DIAG=y
+CONFIG_UNIX=y
+CONFIG_UNIX_DIAG=y
+CONFIG_XFRM_USER=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_NET_IPGRE_DEMUX=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+CONFIG_INET_UDP_DIAG=y
+# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET6_XFRM_MODE_BEET is not set
+CONFIG_IPV6_SIT_6RD=y
+CONFIG_NETFILTER=y
+CONFIG_NF_CONNTRACK=y
+# CONFIG_NF_CONNTRACK_PROCFS is not set
+CONFIG_NF_CONNTRACK_SNMP=y
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_EXTHDR=y
+CONFIG_NFT_META=y
+CONFIG_NFT_NUMGEN=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_SET_RBTREE=y
+CONFIG_NFT_SET_HASH=y
+CONFIG_NFT_COUNTER=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_QUOTA=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_HASH=y
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_ATMEL=y
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_GLUEBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_BLK_DEV_RAM_SIZE=8192
+CONFIG_ATMEL_TCLIB=y
+CONFIG_ATMEL_SSC=y
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+# CONFIG_SCSI_LOWLEVEL is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_ARC is not set
+CONFIG_MACB=y
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_EZCHIP is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_HISILICON is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_SYNOPSYS is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+CONFIG_MICREL_PHY=y
+# CONFIG_USB_NET_DRIVERS is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_LEDS is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_LEGACY_PTY_COUNT=4
+CONFIG_SERIAL_ATMEL=y
+CONFIG_SERIAL_ATMEL_CONSOLE=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_AT91=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_POWER_RESET=y
+CONFIG_SENSORS_JC42=y
+CONFIG_WATCHDOG=y
+CONFIG_AT91SAM9X_WATCHDOG=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_PCM_OSS=y
+# CONFIG_SND_DRIVERS is not set
+# CONFIG_SND_ARM is not set
+# CONFIG_SND_USB is not set
+CONFIG_SND_SOC=y
+CONFIG_SND_ATMEL_SOC=y
+CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=y
+# CONFIG_HID_GENERIC is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_STORAGE_REALTEK=y
+CONFIG_USB_STORAGE_DATAFAB=y
+CONFIG_USB_STORAGE_FREECOM=y
+CONFIG_USB_STORAGE_ISD200=y
+CONFIG_USB_STORAGE_USBAT=y
+CONFIG_USB_STORAGE_SDDR09=y
+CONFIG_USB_STORAGE_SDDR55=y
+CONFIG_USB_STORAGE_JUMPSHOT=y
+CONFIG_USB_STORAGE_ALAUDA=y
+CONFIG_USB_STORAGE_ONETOUCH=y
+CONFIG_USB_STORAGE_KARMA=y
+CONFIG_USB_STORAGE_CYPRESS_ATACB=y
+CONFIG_USB_STORAGE_ENE_UB6250=y
+CONFIG_USB_UAS=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_ATMEL_USBA=y
+CONFIG_USB_G_SERIAL=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_AT91RM9200=y
+CONFIG_DMADEVICES=y
+CONFIG_AT_HDMAC=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_IIO=y
+CONFIG_AT91_ADC=y
+CONFIG_ENVELOPE_DETECTOR=y
+CONFIG_DPOT_DAC=y
+CONFIG_MCP4531=y
+CONFIG_PWM=y
+CONFIG_PWM_ATMEL=y
+CONFIG_PWM_ATMEL_TCB=y
+CONFIG_EXT4_FS=y
+CONFIG_FANOTIFY=y
+CONFIG_OVERLAY_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_UBIFS_FS=y
+CONFIG_UBIFS_FS_ADVANCED_COMPR=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_850=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DYNAMIC_DEBUG=y
+CONFIG_DEBUG_INFO=y
+CONFIG_STRIP_ASM_SYMS=y
+CONFIG_DEBUG_FS=y
+CONFIG_DEBUG_MEMORY_INIT=y
+CONFIG_LOCKUP_DETECTOR=y
+CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
+# CONFIG_DETECT_HUNG_TASK is not set
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_FTRACE is not set
+CONFIG_DEBUG_USER=y
+CONFIG_CRYPTO_CCM=y
+CONFIG_CRYPTO_GCM=y
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_SHA1=y
+CONFIG_CRYPTO_SHA512=y
+CONFIG_CRYPTO_ARC4=y
+CONFIG_CRYPTO_DEV_ATMEL_AES=y
+CONFIG_CRYPTO_DEV_ATMEL_TDES=y
+CONFIG_CRYPTO_DEV_ATMEL_SHA=y
--
2.1.4
^ permalink raw reply related
* [PATCH v3 1/2] ARM: dts: add devicetree for the Axentia TSE-850
From: Peter Rosin @ 2016-11-30 12:48 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
linux-arm-kernel, devicetree
In-Reply-To: <1480510102-24587-1-git-send-email-peda@axentia.se>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 7 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/axentia-linea.dtsi | 53 +++++
arch/arm/boot/dts/axentia-tse850-3.dts | 276 ++++++++++++++++++++++
5 files changed, 356 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/axentia-linea.dtsi
create mode 100644 arch/arm/boot/dts/axentia-tse850-3.dts
diff --git a/Documentation/devicetree/bindings/arm/axentia.txt b/Documentation/devicetree/bindings/arm/axentia.txt
new file mode 100644
index 000000000000..ea3fb96ae465
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axentia.txt
@@ -0,0 +1,19 @@
+Device tree bindings for Axentia ARM devices
+============================================
+
+Linea CPU module
+----------------
+
+Required root node properties:
+compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from atmel-at91.txt for a sama5d31 SoC.
+
+
+TSE-850 v3 board
+----------------
+
+Required root node properties:
+compatible = "axentia,tse850v3", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from above for the axentia,linea CPU module.
diff --git a/MAINTAINERS b/MAINTAINERS
index 130e927824b5..9dfe877f47e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2339,6 +2339,13 @@ S: Maintained
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXENTIA ARM DEVICES
+M: Peter Rosin <peda@axentia.se>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/arm/axentia.txt
+F: arch/arm/boot/dts/axentia-*
+
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
M: Mauro Carvalho Chehab <mchehab@kernel.org>
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 58a3024f7edc..8ca735b82891 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
+ axentia-tse850-3.dtb \
sama5d31ek.dtb \
sama5d33ek.dtb \
sama5d34ek.dtb \
diff --git a/arch/arm/boot/dts/axentia-linea.dtsi b/arch/arm/boot/dts/axentia-linea.dtsi
new file mode 100644
index 000000000000..5a47d847149c
--- /dev/null
+++ b/arch/arm/boot/dts/axentia-linea.dtsi
@@ -0,0 +1,53 @@
+/*
+ * axentia-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda@axentia.se>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ memory {
+ reg = <0x20000000 0x20000000>;
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&main {
+ clock-frequency = <12000000>;
+};
+
+&i2c0 {
+ status = "okay";
+
+ eeprom@51 {
+ compatible = "st,24c64";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+};
+
+&nand0 {
+ status = "okay";
+
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+};
diff --git a/arch/arm/boot/dts/axentia-tse850-3.dts b/arch/arm/boot/dts/axentia-tse850-3.dts
new file mode 100644
index 000000000000..4e7c8bea2873
--- /dev/null
+++ b/arch/arm/boot/dts/axentia-tse850-3.dts
@@ -0,0 +1,276 @@
+/*
+ * axentia-tse850-3.dts - Device Tree file for the Axentia TSE-850 3.0 board
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda@axentia.se>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include <dt-bindings/pwm/pwm.h>
+#include "axentia-linea.dtsi"
+
+/ {
+ model = "Axentia TSE-850 3.0";
+ compatible = "axentia,tse850v3", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
+ };
+
+ ahb {
+ apb {
+ pinctrl@fffff200 {
+ tse850 {
+ pinctrl_usba_vbus: usba-vbus {
+ atmel,pins =
+ <AT91_PIOC 31
+ AT91_PERIPH_GPIO
+ AT91_PINCTRL_DEGLITCH>;
+ };
+ };
+ };
+
+ watchdog@fffffe40 {
+ status = "okay";
+ };
+ };
+ };
+
+ sck: oscillator {
+ compatible = "fixed-clock";
+
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ clock-output-names = "sck";
+ };
+
+ reg_3v3: regulator {
+ compatible = "regulator-fixed";
+
+ regulator-name = "3v3-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ana: reg-ana {
+ compatible = "pwm-regulator";
+
+ regulator-name = "ANA";
+
+ pwms = <&pwm0 2 1000 PWM_POLARITY_INVERTED>;
+ pwm-dutycycle-unit = <1000>;
+ pwm-dutycycle-range = <100 1000>;
+
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <20000000>;
+ regulator-ramp-delay = <1000>;
+ };
+
+ sound {
+ compatible = "axentia,tse850-pcm5142";
+
+ axentia,ssc-controller = <&ssc0>;
+ axentia,audio-codec = <&pcm5142>;
+
+ axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
+ axentia,loop1-gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ axentia,loop2-gpios = <&pioA 11 GPIO_ACTIVE_LOW>;
+
+ axentia,ana-supply = <&ana>;
+ };
+
+ dac: dpot-dac {
+ compatible = "dpot-dac";
+ vref-supply = <®_3v3>;
+ io-channels = <&dpot 0>;
+ io-channel-names = "dpot";
+ #io-channel-cells = <1>;
+ };
+
+ envelope-detector {
+ compatible = "axentia,tse850-envelope-detector";
+ io-channels = <&dac 0>;
+ io-channel-names = "dac";
+
+ interrupt-parent = <&pioA>;
+ interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "comp";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ ch1-red {
+ label = "ch-1:red";
+ gpios = <&pioA 23 GPIO_ACTIVE_LOW>;
+ };
+ ch1-green {
+ label = "ch-1:green";
+ gpios = <&pioA 22 GPIO_ACTIVE_LOW>;
+ };
+ ch2-red {
+ label = "ch-2:red";
+ gpios = <&pioA 21 GPIO_ACTIVE_LOW>;
+ };
+ ch2-green {
+ label = "ch-2:green";
+ gpios = <&pioA 20 GPIO_ACTIVE_LOW>;
+ };
+ data-red {
+ label = "data:red";
+ gpios = <&pioA 19 GPIO_ACTIVE_LOW>;
+ };
+ data-green {
+ label = "data:green";
+ gpios = <&pioA 18 GPIO_ACTIVE_LOW>;
+ };
+ alarm-red {
+ label = "alarm:red";
+ gpios = <&pioA 17 GPIO_ACTIVE_LOW>;
+ };
+ alarm-green {
+ label = "alarm:green";
+ gpios = <&pioA 16 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&nand0 {
+ at91bootstrap@0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ barebox@40000 {
+ label = "bootloader";
+ reg = <0x40000 0x60000>;
+ };
+
+ bareboxenv@c0000 {
+ label = "bareboxenv";
+ reg = <0xc0000 0x40000>;
+ };
+
+ bareboxenv2@100000 {
+ label = "bareboxenv2";
+ reg = <0x100000 0x40000>;
+ };
+
+ oftree@180000 {
+ label = "oftree";
+ reg = <0x180000 0x20000>;
+ };
+
+ kernel@200000 {
+ label = "kernel";
+ reg = <0x200000 0x500000>;
+ };
+
+ rootfs@800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+
+ ovlfs@10000000 {
+ label = "ovlfs";
+ reg = <0x10000000 0x10000000>;
+ };
+};
+
+&ssc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ jc42@18 {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x18>;
+ };
+
+ dpot: mcp4651-104@28 {
+ compatible = "microchip,mcp4651-104";
+ reg = <0x28>;
+ #io-channel-cells = <1>;
+ };
+
+ pcm5142: pcm5142@4c {
+ compatible = "ti,pcm5142";
+
+ reg = <0x4c>;
+
+ AVDD-supply = <®_3v3>;
+ DVDD-supply = <®_3v3>;
+ CPVDD-supply = <®_3v3>;
+
+ clocks = <&sck>;
+
+ pll-in = <3>;
+ pll-out = <6>;
+ };
+
+ eeprom@50 {
+ compatible = "nxp,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
+
+&usart0 {
+ status = "okay";
+
+ atmel,use-dma-rx;
+};
+
+&pwm0 {
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_pwm0_pwml2_1>;
+ pinctrl-names = "default";
+};
+
+&macb1 {
+ status = "okay";
+
+ phy-mode = "rgmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@3 {
+ reg = <3>;
+
+ interrupt-parent = <&pioE>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioC 31 GPIO_ACTIVE_HIGH>;
+};
+
+&usb1 {
+ status = "okay";
+
+ num-ports = <1>;
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ atmel,oc-gpio = <&pioC 15 GPIO_ACTIVE_LOW>;
+};
+
+&usb2 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+};
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: Linus Walleij @ 2016-11-30 13:01 UTC (permalink / raw)
To: David Lechner
Cc: Rob Herring, Mark Rutland, Sekhar Nori, Kevin Hilman,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Axel Haslam,
Alexandre Bailon, Bartosz Gołaszewski
In-Reply-To: <1480351226-3332-4-git-send-email-david@lechnology.com>
On Mon, Nov 28, 2016 at 5:40 PM, David Lechner <david@lechnology.com> wrote:
> This SoC has a separate pin controller for configuring pullup/pulldown
> bias on groups of pins.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>
> v2 changes:
> * Moved pin-controller@22c00c device node after gpio@226000 (there seem to be
> more nodes in proper order here compared to the i2c@228000 node suggested by
> Sekhar)
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Take this through the ARM SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/3] pinctrl: New driver for TI DA850/OMAP-L138/AM18XX pinconf
From: Linus Walleij @ 2016-11-30 13:00 UTC (permalink / raw)
To: David Lechner
Cc: Rob Herring, Mark Rutland, Sekhar Nori, Kevin Hilman,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Axel Haslam,
Alexandre Bailon, Bartosz Gołaszewski
In-Reply-To: <1480351226-3332-3-git-send-email-david@lechnology.com>
On Mon, Nov 28, 2016 at 5:40 PM, David Lechner <david@lechnology.com> wrote:
> This adds a new driver for pinconf on TI DA850/OMAP-L138/AM18XX. These
> SoCs have a separate controller for controlling pullup/pulldown groups.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/3] devicetree: bindings: pinctrl: Add binding for ti,da850-pupd
From: Linus Walleij @ 2016-11-30 12:59 UTC (permalink / raw)
To: David Lechner
Cc: Rob Herring, Mark Rutland, Sekhar Nori, Kevin Hilman,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Axel Haslam,
Alexandre Bailon, Bartosz Gołaszewski
In-Reply-To: <1480351226-3332-2-git-send-email-david@lechnology.com>
On Mon, Nov 28, 2016 at 5:40 PM, David Lechner <david@lechnology.com> wrote:
> Device-tree bindings for TI DA850/OMAP-L138/AM18XX pullup/pulldown
> pinconf controller.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Totally uncontroversial standard bindings so patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3] Documentation: pinctrl: palmas: Add ti,palmas-powerhold-override property definition
From: Linus Walleij @ 2016-11-30 12:55 UTC (permalink / raw)
To: Keerthy
Cc: Tero Kristo, Rob Herring, ext Tony Lindgren,
devicetree@vger.kernel.org, Linux-OMAP,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1480305718-5127-1-git-send-email-j-keerthy@ti.com>
On Mon, Nov 28, 2016 at 5:01 AM, Keerthy <j-keerthy@ti.com> wrote:
> GPIO7 is configured in POWERHOLD mode which has higher priority
> over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
> bit is turned off. This property enables driver to over ride the
> POWERHOLD value to GPIO7 so as to turn off the PMIC in power off
> scenarios.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
>
> Remaining patches of the series are already queued.
>
> Changes in v3: Added Rob's Ack.
Patch applied to the pinctrl tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 4/4] locking: Add kselftests for ww_mutex stress
From: Chris Wilson @ 2016-11-30 12:52 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: linux-kernel, Peter Zijlstra, Nicolai Hähnle
In-Reply-To: <67628c55-e8a1-cc33-f99a-ec458c83657c@mblankhorst.nl>
On Wed, Nov 30, 2016 at 01:29:39PM +0100, Maarten Lankhorst wrote:
> > +static void stress_work(struct work_struct *work)
> > +{
> > + struct stress *stress = container_of(work, typeof(*stress), work);
> > + const int nlocks = stress->nlocks;
> > + struct ww_mutex *locks = stress->locks;
> > + struct ww_acquire_ctx ctx;
> > + int contended = -1;
> > + int *order;
> > + int n, ret;
> > +
> > + order = get_random_order(nlocks);
> > + if (!order)
> > + return;
> > +
> > + ww_acquire_init(&ctx, &ww_class);
> > +
> > +retry:
> > + ret = 0;
> > + for (n = 0; n < nlocks; n++) {
> > + if (n == contended)
> > + continue;
> > +
> > + ret = ww_mutex_lock(&locks[order[n]], &ctx);
> > + if (ret < 0)
> > + break;
> > + }
> What's wrong with attempting to lock the contended lock here?
> Who knows, this might find some more bugs than the functional tests already do.
I was trying to follow the guide, which was lock, backoff by unlocking
everything, slowlock the contended lock, then lock everything else.
I have now a second worker that follows the reordering method as well.
(As well as a test that slowlock after the ABBA deadlock detection
resolves the locking order.)
If you have a sketch of something else to try, I'll add it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ 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