Re: [PATCH 1/2] x86, gpio: Increase ARCH_NR_GPIOs to 512
On Sat, Sep 20, 2014 at 2:48 AM, Linus Walleij wrote: > On Fri, Sep 19, 2014 at 12:20 AM, Alexandre Courbot wrote: >> On Tue, Sep 9, 2014 at 4:24 PM, Linus Walleij >> wrote: > >>> This however makes it *impossible* to use things like desc_to_gpio() >>> and/or gpio_to_desc() so the code has to be augmented all over the >>> place to avoid any uses of GPIO numbers on that architecture, >>> but I am sure it *can* be done on pure ACPI or device tree >>> systems, and that's what we should aim for. >> >> desc_to_gpio()/gpio_to_desc() could still work even if we remove the >> big array of GPIO descriptors. Actually that's what I intended to do >> when I first submitted the gpiod patches some time ago but it was >> rejected for performance reasons. > > OK. I'm ready to revisit the subject. > >> desc_to_gpio() actually doesn't even access this array - it does its >> job using the chip base and the beginning address of its descriptors >> array. > > Right. > >> gpio_to_desc() would suffer a performance hit. What I initially >> proposed was to parse the linked list of GPIO chips and check if the >> requested number is in their assigned range. This is obviously slower >> than accessing an array, but if we consider that we generally don't >> have too many GPIO chips on a given hardware I don't think the hit >> would be that bad. It would also give some incentive for people to >> move to the gpiod interface. > > I think the performance hit is acceptable, because this should > not be on a hot path anyway. I would say go ahead with this refactoring. Great! I will come with something once my holidays are over. It should not be a complex change. > >> I also have a patch in my queue that enables multiple users on the >> same GPIO descriptor (something requested since some time already). >> What happens with it is that descriptors ownership is fully >> transferred to the gpio_chip instances, and the static array becomes a >> array of double-pointers, making it considerable smaller and reducing >> the impact of increasing its size. Maybe I should submit that change >> just for this case? > > Um I think that is an orthogonal thing, but honestly I'm > not following the double-pointers thing, so I guess I need to see > the patch. Yes, this is completely orthogonal, and actually this won't be needed if we decide to get rid of that array. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics
> Then, what made current->flags to unexpectedly preserve PF_USED_MATH flag?
> The user is running cgrulesengd process in order to utilize cpuset cgroup.
> Thus, cpuset_update_task_spread_flag() is called when cgrulesengd process
> writes someone's pid to /cgroup/cpuset/$group/tasks interface.
>
> cpuset_update_task_spread_flag() is updating other thread's
> "struct task_struct"->flags without exclusion control or atomic
> operations!
>
> -- linux-2.6.32-358.23.2.el6/kernel/cpuset.c --
> 300:/*
> 301: * update task's spread flag if cpuset's page/slab spread flag is set
> 302: *
> 303: * Called with callback_mutex/cgroup_mutex held
> 304: */
> 305:static void cpuset_update_task_spread_flag(struct cpuset *cs,
> 306:struct task_struct *tsk)
> 307:{
> 308:if (is_spread_page(cs))
> 309:tsk->flags |= PF_SPREAD_PAGE;
> 310:else
> 311:tsk->flags &= ~PF_SPREAD_PAGE;
> 312:if (is_spread_slab(cs))
> 313:tsk->flags |= PF_SPREAD_SLAB;
> 314:else
> 315:tsk->flags &= ~PF_SPREAD_SLAB;
> 316:}
We should make the updating of this flag atomic.
diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index 0d4e067..2f073db 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -94,12 +94,12 @@ extern int cpuset_slab_spread_node(void);
static inline int cpuset_do_page_mem_spread(void)
{
- return current->flags & PF_SPREAD_PAGE;
+ return task_spread_page(current);
}
static inline int cpuset_do_slab_mem_spread(void)
{
- return current->flags & PF_SPREAD_SLAB;
+ return task_spread_slab(current);
}
extern int current_cpuset_is_being_rebound(void);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5c2c885..1e448a3 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1903,8 +1903,6 @@ extern void thread_group_cputime_adjusted(struct
task_struct *p, cputime_t *ut,
#define PF_KTHREAD 0x0020 /* I am a kernel thread */
#define PF_RANDOMIZE 0x0040 /* randomize virtual address space */
#define PF_SWAPWRITE 0x0080 /* Allowed to write to swap */
-#define PF_SPREAD_PAGE 0x0100 /* Spread page cache over cpuset */
-#define PF_SPREAD_SLAB 0x0200 /* Spread some slab caches over cpuset
*/
#define PF_NO_SETAFFINITY 0x0400 /* Userland is not allowed to meddle
with cpus_allowed */
#define PF_MCE_EARLY0x0800 /* Early kill for mce process policy */
#define PF_MUTEX_TESTER0x2000 /* Thread belongs to the rt
mutex tester */
@@ -1958,6 +1956,8 @@ static inline void memalloc_noio_restore(unsigned int
flags)
/* Per-process atomic flags. */
#define PFA_NO_NEW_PRIVS 0x0001/* May not gain new privileges. */
+#define PFA_SPREAD_PAGE 0x0002/* Spread page cache over cpuset */
+#define PFA_SPREAD_SLAB 0x0004/* Spread some slab caches over cpuset
*/
static inline bool task_no_new_privs(struct task_struct *p)
{
@@ -1969,6 +1969,36 @@ static inline void task_set_no_new_privs(struct
task_struct *p)
set_bit(PFA_NO_NEW_PRIVS, >atomic_flags);
}
+static inline bool task_spread_page(struct task_struct *p)
+{
+ return test_bit(PFA_SPREAD_PAGE, >atomic_flags);
+}
+
+static inline void task_set_spread_page(struct task_struct *p)
+{
+ set_bit(PFA_SPREAD_PAGE, >atomic_flags);
+}
+
+static inline void task_clear_spread_page(struct task_struct *p)
+{
+ clear_bit(PFA_SPREAD_PAGE, >atomic_flags);
+}
+
+static inline bool task_spread_slab(struct task_struct *p)
+{
+ return test_bit(PFA_SPREAD_SLAB, >atomic_flags);
+}
+
+static inline void task_set_spread_slab(struct task_struct *p)
+{
+ set_bit(PFA_SPREAD_SLAB, >atomic_flags);
+}
+
+static inline void task_clear_spread_slab(struct task_struct *p)
+{
+ clear_bit(PFA_SPREAD_SLAB, >atomic_flags);
+}
+
/*
* task->jobctl flags
*/
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index a37f4ed..1f107c7 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -365,13 +365,14 @@ static void cpuset_update_task_spread_flag(struct cpuset
*cs,
struct task_struct *tsk)
{
if (is_spread_page(cs))
- tsk->flags |= PF_SPREAD_PAGE;
+ task_set_spread_page(tsk);
else
- tsk->flags &= ~PF_SPREAD_PAGE;
+ task_clear_spread_page(tsk);
+
if (is_spread_slab(cs))
- tsk->flags |= PF_SPREAD_SLAB;
+ task_set_spread_slab(tsk);
else
- tsk->flags &= ~PF_SPREAD_SLAB;
+ task_clear_spread_slab(tsk);
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
lening bieden
-- Goede dag, We zijn Diamond Zwitserse lening bedrijf geven van leningen per post advertentie. Wij bieden verschillende soorten leningen (korte en lange termijn leningen, persoonlijke leningen, leningen aan bedrijven etc.) met 3% rente. We geven leningen aan mensen in nood niet, ongeacht hun locatie, geslacht, burgerlijke staat, opleiding, status van de taak, maar moet een wettelijke middelen van terugbetaling hebben. Onze leningen variëren tussen 5.000,00 tot 10.000.000,00 Amerikaanse dollar of de euro of pond met een looptijd van maximaal 20 jaar. Als u geïnteresseerd bent in meer informatie, vul dan onderstaand formulier in en stuur deze naar ons e-mailadres: diamondswissloanscomp...@gmail.com Gelieve in te vullen: naam: Adres: Leeftijd: Geslacht: Contact-Phone: Beroep: Maandelijks inkomen: Het benodigde bedrag van de lening: Duur van de lening: Het doel van de lening: land: Postcode: "Wij tonen u een betere manier om uw financiële vrijheid" Met vriendelijke groet, Mr Diamond Peters (algemeen directeur). De heer Bill Anthony (Marketing Manager). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load
On Sep 19, 2014 8:46 PM, "Filipe Brandenburger" wrote: > > On Fri, Sep 19, 2014 at 8:27 PM, Andy Lutomirski wrote: > >> I thought of doing that from the prctl but AFAICT remap_pfn_range > >> requires that it's unmapped before the call (remap_pte_range has > >> BUG_ON(!pte_none(*pte));) and doing a zap_page_range followed by > >> remap_pfn_range might incur a race condition if another thread of the > >> same process is accessing the vvar page at that time... Am I wrong > >> about that race? > > > > No, you're right. Ugh. > > > > It might pay to add an explicit .fault callback to vm_special_mapping, > > but your approach will work, too. The main downside is more memory > > overhead per mm. > > One way to limit that overhead was to keep only two static > vm_special_mapping structs (one for the real vvar page and one for the > zero page) and then change the vma->vm_private_data to point to one or > the other when the prctl is called. I just thought of that recently > and haven't tried it yet so not sure if it will cause other > problems... Sneaky :) This might have interesting effects if someone races with you. mmap_sem could be enough. On the other hand, holding mmap_sem for write could be enough to let you zap the pte and remap it. > > >>> Changing out the text is a whole can of worms involving self-modifying > >>> code, although it may be completely safe if done through the page > >>> tables. But I don't think you can't use remap_pfn_range for that. > >> > >> No, I'm not planning to change the text, just replacing the vvar page > >> swapping the one where the vsyscall_gtod_data lives with a zero page > >> (and back depending on the parameter of the prctl.) > > > > Hmm. This will break the _COARSE timing functions as well as > > __vdso_time. That'll need fixing, either by swapping out the code > > (yuck!) or by adding a branch to all of those code paths. > > > > Maybe there's a non-branchy way, though. Let me think. > > So this is what I was thinking of extending the vvar region to include > one extra page (right now it's two pages, the one with the > vsyscall_gtod_data and the one with the hrtimer I/O mapping, so this > would be a third page.) This third page would be initially mapped to > the zero page, so it wouldn't cost an extra page of memory per process > or even globally. > > The prctl would swap that page with another page allocated as the > prctl is called. That one page that's allocated with the prctl would > be inherited over forks and execs, so if you have a bunch of processes > that need the same offset then they'd all share that one single page. > > The vdso clock routines would get the base clock information from > vsyscall_gtod_data, hpet, tsc, etc. and would simply add the offsets > from the task_vvar page (not too branch-y, just a few extra adds.) In > the regular case, that would be a zero page so it would be simply > adding zero. If we need to apply offsets, then we replace that page > with one that has a struct with the right offsets for each clock type. > > When running in kernel mode, the clock code (and timer code, etc.) > would find that page through the mm_struct and find the clock offsets > that way. This seems like a lot of complexity and non-negligible overhead (extra adds, cacheline misses, and even TLB misses) in the common case just to have fast timing under very unusual circumstances. I'd much rather do something to the vvar page that causes all the timing calls to turn into normal syscalls and then handle the offset in the timing syscalls. Are you really doing something that's performance-sensitive enough to justify all of the complexity of making this work without syscalls? To do that, the only real tricky part is handling the coarse timing calls. The could be done with extra branches, text patches, or trickery involving setting up an alternate vvar page that always fails the seqcount retry check. > > I was working on this approach before you suggested swapping the > actual vvar page (and not sure if you were actually looking at > hot-swapping the vdso itself.) I can go back to working on it and send > you a few commits since I still have some of that code around. > > Cheers, > Filipe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] percpu-refcount: make percpu_ref based on longs instead of ints
>From e625305b390790717cf2cccf61efb81299647028 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Sat, 20 Sep 2014 01:27:25 -0400
percpu_ref is currently based on ints and the number of refs it can
cover is (1 << 31). This makes it impossible to use a percpu_ref to
count memory objects or pages on 64bit machines as it may overflow.
This forces those users to somehow aggregate the references before
contributing to the percpu_ref which is often cumbersome and sometimes
challenging to get the same level of performance as using the
percpu_ref directly.
While using ints for the percpu counters makes them pack tighter on
64bit machines, the possible gain from using ints instead of longs is
extremely small compared to the overall gain from per-cpu operation.
This patch makes percpu_ref based on longs so that it can be used to
directly count memory objects or pages.
Signed-off-by: Tejun Heo
Cc: Kent Overstreet
Cc: Johannes Weiner
---
This is the version which got applied. Refreshed to reflect the
previous patch being dropped and a couple atomic_t references in
comments removed.
Thanks.
include/linux/percpu-refcount.h | 24
lib/percpu-refcount.c | 37 +++--
2 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index ee83251..5df6784 100644
--- a/include/linux/percpu-refcount.h
+++ b/include/linux/percpu-refcount.h
@@ -55,7 +55,7 @@ struct percpu_ref;
typedef void (percpu_ref_func_t)(struct percpu_ref *);
struct percpu_ref {
- atomic_tcount;
+ atomic_long_t count;
/*
* The low bit of the pointer indicates whether the ref is in percpu
* mode; if set, then get/put will manipulate the atomic_t.
@@ -97,7 +97,7 @@ static inline void percpu_ref_kill(struct percpu_ref *ref)
* branches as it can't assume that @ref->pcpu_count is not NULL.
*/
static inline bool __pcpu_ref_alive(struct percpu_ref *ref,
- unsigned __percpu **pcpu_countp)
+ unsigned long __percpu **pcpu_countp)
{
unsigned long pcpu_ptr = ACCESS_ONCE(ref->pcpu_count_ptr);
@@ -107,7 +107,7 @@ static inline bool __pcpu_ref_alive(struct percpu_ref *ref,
if (unlikely(pcpu_ptr & PCPU_REF_DEAD))
return false;
- *pcpu_countp = (unsigned __percpu *)pcpu_ptr;
+ *pcpu_countp = (unsigned long __percpu *)pcpu_ptr;
return true;
}
@@ -119,14 +119,14 @@ static inline bool __pcpu_ref_alive(struct percpu_ref
*ref,
*/
static inline void percpu_ref_get(struct percpu_ref *ref)
{
- unsigned __percpu *pcpu_count;
+ unsigned long __percpu *pcpu_count;
rcu_read_lock_sched();
if (__pcpu_ref_alive(ref, _count))
this_cpu_inc(*pcpu_count);
else
- atomic_inc(>count);
+ atomic_long_inc(>count);
rcu_read_unlock_sched();
}
@@ -142,7 +142,7 @@ static inline void percpu_ref_get(struct percpu_ref *ref)
*/
static inline bool percpu_ref_tryget(struct percpu_ref *ref)
{
- unsigned __percpu *pcpu_count;
+ unsigned long __percpu *pcpu_count;
int ret = false;
rcu_read_lock_sched();
@@ -151,7 +151,7 @@ static inline bool percpu_ref_tryget(struct percpu_ref *ref)
this_cpu_inc(*pcpu_count);
ret = true;
} else {
- ret = atomic_inc_not_zero(>count);
+ ret = atomic_long_inc_not_zero(>count);
}
rcu_read_unlock_sched();
@@ -175,7 +175,7 @@ static inline bool percpu_ref_tryget(struct percpu_ref *ref)
*/
static inline bool percpu_ref_tryget_live(struct percpu_ref *ref)
{
- unsigned __percpu *pcpu_count;
+ unsigned long __percpu *pcpu_count;
int ret = false;
rcu_read_lock_sched();
@@ -199,13 +199,13 @@ static inline bool percpu_ref_tryget_live(struct
percpu_ref *ref)
*/
static inline void percpu_ref_put(struct percpu_ref *ref)
{
- unsigned __percpu *pcpu_count;
+ unsigned long __percpu *pcpu_count;
rcu_read_lock_sched();
if (__pcpu_ref_alive(ref, _count))
this_cpu_dec(*pcpu_count);
- else if (unlikely(atomic_dec_and_test(>count)))
+ else if (unlikely(atomic_long_dec_and_test(>count)))
ref->release(ref);
rcu_read_unlock_sched();
@@ -219,11 +219,11 @@ static inline void percpu_ref_put(struct percpu_ref *ref)
*/
static inline bool percpu_ref_is_zero(struct percpu_ref *ref)
{
- unsigned __percpu *pcpu_count;
+ unsigned long __percpu *pcpu_count;
if (__pcpu_ref_alive(ref, _count))
return false;
- return !atomic_read(>count);
+ return !atomic_long_read(>count);
}
#endif
diff --git a/lib/percpu-refcount.c b/lib/percpu-refcount.c
index 70d28c9..559ee0b 100644
---
Re: [PATCH 3/3] percpu-refcount: make percpu_ref based on longs instead of ints
On Mon, Sep 08, 2014 at 11:12:22AM +0900, Tejun Heo wrote: > percpu_ref is currently based on ints and the number of refs it can > cover is (1 << 31). This makes it impossible to use a percpu_ref to > count memory objects or pages on 64bit machines as it may overflow. > This forces those users to somehow aggregate the references before > contributing to the percpu_ref which is often cumbersome and sometimes > challenging to get the same level of performance as using the > percpu_ref directly. > > While using ints for the percpu counters makes them pack tighter on > 64bit machines, the possible gain from using ints instead of longs is > extremely small compared to the overall gain from per-cpu operation. > This patch makes percpu_ref based on longs so that it can be used to > directly count memory objects or pages. > > Signed-off-by: Tejun Heo > Cc: Kent Overstreet > Cc: Johannes Weiner Applied 1 and 3 to percpu/for-3.18. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] percpu-refcount: implement percpu_ref_set_killed()
On Mon, Sep 08, 2014 at 11:12:21AM +0900, Tejun Heo wrote: > With the recent addition of percpu_ref_reinit(), percpu_ref now can be > used as a persistent switch which can be turned on and off repeatedly > where turning off maps to killing the ref and waiting for it to drain; > however, there currently isn't a way to initialize a percpu_ref in its > off (killed and drained) state, which can be inconvenient for certain > persistent switch use cases. > > This patch adds percpu_ref_set_killed() which forces the percpu_ref > into its killed and drained state. The caller is responsible for > ensuring that no one else is using the ref. This can be used to force > the percpu_ref into its off state after initialization. > > Signed-off-by: Tejun Heo > Cc: Kent Overstreet This turned out to be too limited. Dropping this one. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/6] mm: introduce common page state for ballooned memory
On Sat, Sep 20, 2014 at 1:35 AM, Andrew Morton
wrote:
> On Sat, 13 Sep 2014 12:22:23 +0400 Konstantin Khlebnikov
> wrote:
>
>> On Sat, Sep 13, 2014 at 9:42 AM, Andrew Morton
>> wrote:
>> > On Sat, 13 Sep 2014 09:26:49 +0400 Konstantin Khlebnikov
>> > wrote:
>> >
>> >> >
>> >> > Did we really need to put the BalloonPages count into per-zone vmstat,
>> >> > global vmstat and /proc/meminfo? Seems a bit overkillish - why so
>> >> > important?
>> >>
>> >> Balloon grabs random pages, their distribution among numa nodes might
>> >> be important.
>> >> But I know nobody who uses numa-aware vm together with ballooning.
>> >>
>> >> Probably it's better to drop per-zone vmstat and line from meminfo,
>> >> global vmstat counter should be enough.
>> >
>> > Yes, the less we add the better - we can always add stuff later if
>> > there is a demonstrated need.
>>
>> Ok. (I guess incremental patches are more convenient for you)
>> Here is two fixes which remove redundant per-zone counters and adds
>> three vmstat counters: "balloon_inflate", "balloon_deflate" and
>> "balloon_migrate".
>>
>> This statistic seems more useful than current state snapshot.
>> Size of balloon is just a difference between "inflate" and "deflate".
>
> This is a complete mess.
nod
>
> Your second patch (which is actually the first one) called "fix for
> mm-introduce-common-page-state-for-ballooned-memory-fix-v2" is indeed a
> fix for
> mm-introduce-common-page-state-for-ballooned-memory-fix-v2.patch and
> has a changelog.
>
> I eventually worked out that your first patch (whcih is actually the
> second one) called "fix for
> mm-balloon_compaction-use-common-page-ballooning-v2" assumes that
> mm-balloon_compaction-general-cleanup.patch has been applied. Does it
> actually fix mm-balloon_compaction-use-common-page-ballooning-v2.patch?
> I can't tell, because the "general cleanup" is in the way.
Oops I did it again.
>
> So I'm going to send "fix for
> mm-balloon_compaction-use-common-page-ballooning-v2" to Linus
> separately, but it has no changelog at all.
Probably it would be better if you drop everything except actually
fixes and stresstest. This is gone too far, now balloon won't compile
in the middle of patchset. Just tell me and I'll redo the rest.
>
> Please always write changelogs. Please never send more than one patch
> in a single email. Please be *consistent* in filenames, patch titles,
> email subjects, etc.
That patch is supposed to be merged into patch as a fix.
>
> Please send me a changelog for the below patch.
Ok, sure.
>
From: Konstantin Khlebnikov
Subject: mm/balloon_compaction: use vmstat counters
This is fix for "mm/balloon_compaction: use common page ballooning".
it reverts per-zone balloon counters and replaces them with vmstat counters:
"balloon_inflate", "balloon_deflate" and "balloon_migrate".
Per-zone balloon counters have been reverted after discussion but reverting
them from balloon_compaction conflicts with massive cleanup in this code.
Thus this change ends up as a separate patch. Sorry for the mess.
Signed-off-by: Konstantin Khlebnikov
Signed-off-by: Andrew Morton
> ---
>
> drivers/virtio/virtio_balloon.c|1 +
> include/linux/balloon_compaction.h |2 --
> mm/balloon_compaction.c|2 ++
> 3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff -puN
> drivers/virtio/virtio_balloon.c~mm-balloon_compaction-use-common-page-ballooning-v2-fix-1
> drivers/virtio/virtio_balloon.c
> ---
> a/drivers/virtio/virtio_balloon.c~mm-balloon_compaction-use-common-page-ballooning-v2-fix-1
> +++ a/drivers/virtio/virtio_balloon.c
> @@ -395,6 +395,7 @@ static int virtballoon_migratepage(struc
> /* balloon's page migration 1st step -- inflate "newpage" */
> spin_lock_irqsave(_dev_info->pages_lock, flags);
> balloon_page_insert(vb_dev_info, newpage);
> + __count_vm_event(BALLOON_MIGRATE);
> vb_dev_info->isolated_pages--;
> spin_unlock_irqrestore(_dev_info->pages_lock, flags);
> vb->num_pfns = VIRTIO_BALLOON_PAGES_PER_PAGE;
> diff -puN
> include/linux/balloon_compaction.h~mm-balloon_compaction-use-common-page-ballooning-v2-fix-1
> include/linux/balloon_compaction.h
> ---
> a/include/linux/balloon_compaction.h~mm-balloon_compaction-use-common-page-ballooning-v2-fix-1
> +++ a/include/linux/balloon_compaction.h
> @@ -87,7 +87,6 @@ static inline void
> balloon_page_insert(struct balloon_dev_info *b_dev_info, struct page *page)
> {
> __SetPageBalloon(page);
> - inc_zone_page_state(page, NR_BALLOON_PAGES);
> set_page_private(page, (unsigned long)b_dev_info);
> list_add(>lru, _dev_info->pages);
> }
> @@ -104,7 +103,6 @@ balloon_page_insert(struct balloon_dev_i
> static inline void balloon_page_delete(struct page *page, bool isolated)
> {
> __ClearPageBalloon(page);
> - dec_zone_page_state(page, NR_BALLOON_PAGES);
> set_page_private(page, 0);
> if (!isolated)
>
Re: [PATCH] printk: git rid of [sched_delayed] message for printk_deferred
On Thu 18-09-14 19:34:14, Peter Zijlstra wrote: > On Wed, Sep 17, 2014 at 08:31:35PM -0400, Steven Rostedt wrote: > > I totally didn't get what you wrote. > > :-) > > > We don't want to know if it got delayed, then the patch to remove that > > print seems correct. > > Why would you not want to know that? Also was that the actual argument? > Lemme go check the earlier emails -- I cannot find that argument in the > first few emails. Well, so what gets delayed is printing from kernel buffer to console. So this is the same as when you do printk() when console lock is taken by someone else. So it seems a bit strange to prepend [delayed] in some cases and not in others. Another question is what the [delayed] prefix would be useful for? If the message eventually gets printed to console I don't see why you would care it was printed few ms after it entered the kernel buffer (after all the time stamp before the line will be the time when it entered the kernel buffer). And if the kernel crashes in such a way that the message doesn't get printed, then bad luck but prefix in the kernel log buffer isn't going to make that any better :) This all feels like bikeshedding, I don't deeply care what gets done but I wanted to point out I don't really see a use for [delayed]... Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mtd: nand: support ONFI timings mode retrieval for non-ONFI NANDs
Since you were asking about this series, I have a comment:
On Mon, Jul 28, 2014 at 11:16:51AM +0200, Boris BREZILLON wrote:
> Add an onfi_timing_mode_ds field to nand_chip and nand_flash_dev in order
> to support NAND timings definition for non-ONFI NAND.
>
> NAND that support better timings mode than the default one (timings mode 0)
> have to define a new entry in the nand_ids table.
>
> The timings mode should be deduced from timings description from the
> datasheet and the ONFI specification
> (www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf, chapter 4.15
> "Timing Parameters").
> You should choose the closest mode that fit the timings requirements of
> your NAND chip.
>
> Signed-off-by: Boris BREZILLON
> ---
> drivers/mtd/nand/nand_base.c | 1 +
> include/linux/mtd/nand.h | 7 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index d8cdf06..c952c21 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -3576,6 +3576,7 @@ static bool find_full_id_nand(struct mtd_info *mtd,
> struct nand_chip *chip,
> chip->options |= type->options;
> chip->ecc_strength_ds = NAND_ECC_STRENGTH(type);
> chip->ecc_step_ds = NAND_ECC_STEP(type);
> + chip->onfi_timing_mode_ds = type->onfi_timing_mode_ds;
>
> *busw = type->options & NAND_BUSWIDTH_16;
>
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 3083c53..435c005 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -587,6 +587,7 @@ struct nand_buffers {
> * @ecc_step_ds: [INTERN] ECC step required by the @ecc_strength_ds,
> * also from the datasheet. It is the recommended ECC
> step
> * size, if known; if unknown, set to zero.
> + * @onfi_timing_mode_ds:[INTERN] ONFI timing mode deduced from datasheet.
Might want at least one space between '[INTERN]' and 'ONFI'?
> * @numchips:[INTERN] number of physical chips
> * @chipsize:[INTERN] the size of one chip for multichip
> arrays
> * @pagemask:[INTERN] page number mask = number of (pages /
> chip) - 1
> @@ -671,6 +672,7 @@ struct nand_chip {
> uint8_t bits_per_cell;
> uint16_t ecc_strength_ds;
> uint16_t ecc_step_ds;
> + int onfi_timing_mode_ds;
I'm not sure if we'll just want a field specific to non-ONFI chips,
faking an ONFI timing mode; can we make this into a more generally
useful field, that represents something consistent across all NAND
types? I was thinking a "highest mode supported", but that actually
isn't great, since for true ONFI modes (except mode 0) require a SET
FEATURES command to change to a higher mode.
Maybe just something like onfi_timing_mode_default, which we could then
use as mode 0 for ONFI chips.
Ideally, we could centralize as much of this as possible, so that a NAND
driver only has to know the mechanics of "how do I translate an ONFI
mode to a timing configuration for my NAND controller," instead of any
details of how to choose from one of many supported ONFI modes. i.e., it
could implement something like the following hook:
int (*set_timing_mode)(struct nand_sdr_timings *timing);
But anyway, that's out of the scope of this series, and it may be harder
than I make it sound. I just wanted to throw that out there.
> int badblockpos;
> int badblockbits;
>
> @@ -772,6 +774,10 @@ struct nand_chip {
> * @ecc_step_ds in nand_chip{}, also from the datasheet.
> * For example, the "4bit ECC for each 512Byte" can be set with
> * NAND_ECC_INFO(4, 512).
> + * @onfi_timing_mode_ds: the ONFI timing mode supported by this NAND chip.
> This
> + * should be deduced from timings described in the
> + * datasheet.
> + *
> */
> struct nand_flash_dev {
> char *name;
> @@ -792,6 +798,7 @@ struct nand_flash_dev {
> uint16_t strength_ds;
> uint16_t step_ds;
> } ecc;
> + int onfi_timing_mode_ds;
> };
>
> /**
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] mtd: nand: add sunxi NAND flash controller support
Hi Boris, On Mon, Aug 18, 2014 at 07:26:26PM +0200, Boris BREZILLON wrote: > This patch series adds support for the sunxi NAND Flash Controller (NFC) > block. > > These two patches only add support for the basic NAND stuff: > - NAND controller operations > - SW and HW ECC handling (with both syndrome and normal ECC scheme) > > If you want support for advanced features you can find it on my github > repo [1]: > - HW randomization support > - per partition ECC/Randomizer to handle bootloader partitions > > DMA transfers are not supported yet, but I have reworked the OOB layout > when using the HW ECC scheme to match the one used when accessing the NAND > with DMA transfers (the available OOB bytes are placed at the end of the > OOB area). > > This patch series depends on this other one [2] which adds support for ONFI > timing mode retrieval on non-ONFI NANDs. Were you planning to send v2 of your series [2]? I see you made a mistake you were planning on fixing: https://lkml.org/lkml/2014/7/30/423 Brian > Best Regards, > > Boris > > [1]https://github.com/bbrezillon/linux-sunxi/tree/sunxi-nand-v4 > [2]https://lkml.org/lkml/2014/7/28/156 > > Changes since v3: > - removed nand core code modifications from the patch series (submitted >separately) > - added documentation to the code > - forced timeout (a default timeout is used when none is provided by the >caller) on controller operations > - fixed coding style issues > - removed unneeded irq field from the sunxi_nfc struct > - fixed several memory leaks > - reworked the NFC reset code (to avoid potential garbage config from the >bootloader) > - made use of ECC_EXCEPTION flag to prevent erased page from generating >ECC errors > - changed the OOB layout for HW ECC scheme > > Changes since v2: > - merge HW ECC implementation in base implementation patch > - fix timing config when interfacing with an ONFI compatible chip > > Changes since v1: > - add HW ECC support > - rework NAND timings retrieval (use ONFI timing mode instead of raw timings) > - add nand-ecc-level property to specify NAND ECC requirements from DT > > Boris BREZILLON (2): > mtd: nand: add sunxi NAND flash controller support > mtd: nand: add sunxi NFC dt bindings doc > > .../devicetree/bindings/mtd/sunxi-nand.txt | 45 + > drivers/mtd/nand/Kconfig |6 + > drivers/mtd/nand/Makefile |1 + > drivers/mtd/nand/sunxi_nand.c | 1362 > > 4 files changed, 1414 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt > create mode 100644 drivers/mtd/nand/sunxi_nand.c > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/usb/host/ehci-xilinx-of.c: Include "linux/of_irq.h" to avoid compiling error
Hello Maintainers: Please help check this patch, when you have time. Thanks. On 09/08/2014 01:20 PM, Michal Simek wrote: > On 09/03/2014 05:50 PM, Chen Gang wrote: >> Need include it for irq_of_parse_and_map(), the related error with >> allmodconfig under microblaze: >> >> drivers/usb/host/ehci-xilinx-of.c: In function ‘ehci_hcd_xilinx_of_probe’: >> drivers/usb/host/ehci-xilinx-of.c:156:2: error: implicit declaration of >> function ‘irq_of_parse_and_map’ [-Werror=implicit-function-declaration] >> irq = irq_of_parse_and_map(dn, 0); >> ^ >> >> Signed-off-by: Chen Gang >> --- >> drivers/usb/host/ehci-xilinx-of.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/usb/host/ehci-xilinx-of.c >> b/drivers/usb/host/ehci-xilinx-of.c >> index fe57710..a232836 100644 >> --- a/drivers/usb/host/ehci-xilinx-of.c >> +++ b/drivers/usb/host/ehci-xilinx-of.c >> @@ -31,6 +31,7 @@ >> #include >> #include >> #include >> +#include >> >> /** >> * ehci_xilinx_port_handed_over - hand the port out if failed to enable it >> > > Acked-by: Michal Simek > > Thanks, > Michal > -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch/microblaze/kernel/setup.c: Add default 'screen_info" for fixing compiling break
On 09/15/2014 07:10 PM, Chen Gang wrote: > On 9/15/14 16:50, Jesper Nilsson wrote: >> On Sun, Sep 14, 2014 at 10:45:23AM +0200, Geert Uytterhoeven wrote: [...] >> >> Sounds reasonable, at least it can avoid the specific depends on !*arch* >> cruft. >> > > Thank you very much, next when I try the ARCH_MIGHT_HAVE_VGA, I shall > process it (remove useless "screen_info"). > Excuse me, after some trying, I guess, at present, I am not suitable to perform global architecture wide patches (e.g. ARCH_MIGHT_HAVE_VGA). So welcome any other members to help try. I guess, in the future, after I finish all architectures allmodconfig, I shall be suitable for sending global architecture wide patches. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Media: USB: usbtv: Fixed all coding style issues in usbtv source files.
Fixed various coding styles, ignoring coding style error on line 5 for all
files containing a link that is longer than 80 characters long.
Signed-off-by: Amber Thrall
---
drivers/media/usb/usbtv/usbtv-audio.c | 1 +
drivers/media/usb/usbtv/usbtv-core.c | 1 +
drivers/media/usb/usbtv/usbtv-video.c | 3 +++
3 files changed, 5 insertions(+)
diff --git a/drivers/media/usb/usbtv/usbtv-audio.c
b/drivers/media/usb/usbtv/usbtv-audio.c
index 2d8795f..78c12d2 100644
--- a/drivers/media/usb/usbtv/usbtv-audio.c
+++ b/drivers/media/usb/usbtv/usbtv-audio.c
@@ -311,6 +311,7 @@ static int snd_usbtv_card_trigger(struct snd_pcm_substream
*substream, int cmd)
static snd_pcm_uframes_t snd_usbtv_pointer(struct snd_pcm_substream *substream)
{
struct usbtv *chip = snd_pcm_substream_chip(substream);
+
return chip->snd_buffer_pos;
}
diff --git a/drivers/media/usb/usbtv/usbtv-core.c
b/drivers/media/usb/usbtv/usbtv-core.c
index bf25ecf..29428be 100644
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -108,6 +108,7 @@ usbtv_video_fail:
static void usbtv_disconnect(struct usb_interface *intf)
{
struct usbtv *usbtv = usb_get_intfdata(intf);
+
usb_set_intfdata(intf, NULL);
if (!usbtv)
diff --git a/drivers/media/usb/usbtv/usbtv-video.c
b/drivers/media/usb/usbtv/usbtv-video.c
index 3d6ed1f..9d3525f 100644
--- a/drivers/media/usb/usbtv/usbtv-video.c
+++ b/drivers/media/usb/usbtv/usbtv-video.c
@@ -263,6 +263,7 @@ static void usbtv_chunk_to_vbuf(u32 *frame, __be32 *src,
int chunk_no, int odd)
int part_index = (line * 2 + !odd) * 3 + (part_no % 3);
u32 *dst = [part_index * USBTV_CHUNK/2];
+
memcpy(dst, src, USBTV_CHUNK/2 * sizeof(*src));
src += USBTV_CHUNK/2;
}
@@ -407,6 +408,7 @@ static void usbtv_stop(struct usbtv *usbtv)
/* Cancel running transfers. */
for (i = 0; i < USBTV_ISOC_TRANSFERS; i++) {
struct urb *ip = usbtv->isoc_urbs[i];
+
if (ip == NULL)
continue;
usb_kill_urb(ip);
@@ -560,6 +562,7 @@ static int usbtv_g_input(struct file *file, void *priv,
unsigned int *i)
static int usbtv_s_input(struct file *file, void *priv, unsigned int i)
{
struct usbtv *usbtv = video_drvdata(file);
+
return usbtv_select_input(usbtv, i);
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load
On Fri, Sep 19, 2014 at 8:27 PM, Andy Lutomirski wrote: >> I thought of doing that from the prctl but AFAICT remap_pfn_range >> requires that it's unmapped before the call (remap_pte_range has >> BUG_ON(!pte_none(*pte));) and doing a zap_page_range followed by >> remap_pfn_range might incur a race condition if another thread of the >> same process is accessing the vvar page at that time... Am I wrong >> about that race? > > No, you're right. Ugh. > > It might pay to add an explicit .fault callback to vm_special_mapping, > but your approach will work, too. The main downside is more memory > overhead per mm. One way to limit that overhead was to keep only two static vm_special_mapping structs (one for the real vvar page and one for the zero page) and then change the vma->vm_private_data to point to one or the other when the prctl is called. I just thought of that recently and haven't tried it yet so not sure if it will cause other problems... >>> Changing out the text is a whole can of worms involving self-modifying >>> code, although it may be completely safe if done through the page >>> tables. But I don't think you can't use remap_pfn_range for that. >> >> No, I'm not planning to change the text, just replacing the vvar page >> swapping the one where the vsyscall_gtod_data lives with a zero page >> (and back depending on the parameter of the prctl.) > > Hmm. This will break the _COARSE timing functions as well as > __vdso_time. That'll need fixing, either by swapping out the code > (yuck!) or by adding a branch to all of those code paths. > > Maybe there's a non-branchy way, though. Let me think. So this is what I was thinking of extending the vvar region to include one extra page (right now it's two pages, the one with the vsyscall_gtod_data and the one with the hrtimer I/O mapping, so this would be a third page.) This third page would be initially mapped to the zero page, so it wouldn't cost an extra page of memory per process or even globally. The prctl would swap that page with another page allocated as the prctl is called. That one page that's allocated with the prctl would be inherited over forks and execs, so if you have a bunch of processes that need the same offset then they'd all share that one single page. The vdso clock routines would get the base clock information from vsyscall_gtod_data, hpet, tsc, etc. and would simply add the offsets from the task_vvar page (not too branch-y, just a few extra adds.) In the regular case, that would be a zero page so it would be simply adding zero. If we need to apply offsets, then we replace that page with one that has a struct with the right offsets for each clock type. When running in kernel mode, the clock code (and timer code, etc.) would find that page through the mm_struct and find the clock offsets that way. I was working on this approach before you suggested swapping the actual vvar page (and not sure if you were actually looking at hot-swapping the vdso itself.) I can go back to working on it and send you a few commits since I still have some of that code around. Cheers, Filipe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load
On Fri, Sep 19, 2014 at 8:10 PM, Filipe Brandenburger wrote: > Hi Andy, > > On Fri, Sep 19, 2014 at 3:31 PM, Andy Lutomirski wrote: >>> Sorry if I wasn't clear... That's the exact point of my patch, to make >>> vm_special_mapping local to the task. >>> >>> I started with an approach of keeping a struct vm_special_mapping + a >>> struct page * array per mm_struct. >>> >>> I was also looking at keeping two static vm_special_mapping structs, >>> one with the actual vvar page and the other with the zero page and >>> then swapping vma->vm_private_data to point to the appropriate one. >> >> This sounds like it may be more complicated than necessary. Is there >> any reason that just doing remap_pfn_range on the vvar page isn't >> enough? > > I thought of doing that from the prctl but AFAICT remap_pfn_range > requires that it's unmapped before the call (remap_pte_range has > BUG_ON(!pte_none(*pte));) and doing a zap_page_range followed by > remap_pfn_range might incur a race condition if another thread of the > same process is accessing the vvar page at that time... Am I wrong > about that race? No, you're right. Ugh. It might pay to add an explicit .fault callback to vm_special_mapping, but your approach will work, too. The main downside is more memory overhead per mm. > >> Changing out the text is a whole can of worms involving self-modifying >> code, although it may be completely safe if done through the page >> tables. But I don't think you can't use remap_pfn_range for that. > > No, I'm not planning to change the text, just replacing the vvar page > swapping the one where the vsyscall_gtod_data lives with a zero page > (and back depending on the parameter of the prctl.) Hmm. This will break the _COARSE timing functions as well as __vdso_time. That'll need fixing, either by swapping out the code (yuck!) or by adding a branch to all of those code paths. Maybe there's a non-branchy way, though. Let me think. > >> Maybe better: what exactly are you trying to do? > > Just replace the page mapped to the vvar address. > > But nevermind my ramblings here, looks like you're almost there so go > ahead and when you have a working patch I'll take a look at it. See: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=vdso/vma_tracking > > My offer to help still stands, so let me know if you'd like to see > some of my code (unfinished as it is now or if you'd like me to show > you something that works in a few days.) > > Cheers, > Filipe -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load
Hi Andy, On Fri, Sep 19, 2014 at 3:31 PM, Andy Lutomirski wrote: >> Sorry if I wasn't clear... That's the exact point of my patch, to make >> vm_special_mapping local to the task. >> >> I started with an approach of keeping a struct vm_special_mapping + a >> struct page * array per mm_struct. >> >> I was also looking at keeping two static vm_special_mapping structs, >> one with the actual vvar page and the other with the zero page and >> then swapping vma->vm_private_data to point to the appropriate one. > > This sounds like it may be more complicated than necessary. Is there > any reason that just doing remap_pfn_range on the vvar page isn't > enough? I thought of doing that from the prctl but AFAICT remap_pfn_range requires that it's unmapped before the call (remap_pte_range has BUG_ON(!pte_none(*pte));) and doing a zap_page_range followed by remap_pfn_range might incur a race condition if another thread of the same process is accessing the vvar page at that time... Am I wrong about that race? > Changing out the text is a whole can of worms involving self-modifying > code, although it may be completely safe if done through the page > tables. But I don't think you can't use remap_pfn_range for that. No, I'm not planning to change the text, just replacing the vvar page swapping the one where the vsyscall_gtod_data lives with a zero page (and back depending on the parameter of the prctl.) > Maybe better: what exactly are you trying to do? Just replace the page mapped to the vvar address. But nevermind my ramblings here, looks like you're almost there so go ahead and when you have a working patch I'll take a look at it. My offer to help still stands, so let me know if you'd like to see some of my code (unfinished as it is now or if you'd like me to show you something that works in a few days.) Cheers, Filipe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] watchdog: dw_wdt: add restart handler support
On 09/18/2014 11:29 PM, Jisheng Zhang wrote:
The kernel core now provides an API to trigger a system restart.
Register with it to support restarting the system via. watchdog.
Signed-off-by: Jisheng Zhang
---
drivers/watchdog/dw_wdt.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index ad0619d..4ca41e9 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -29,9 +29,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
#include
@@ -62,6 +64,7 @@ static struct {
unsigned long next_heartbeat;
struct timer_list timer;
int expect_close;
+ struct notifier_block restart_handler;
} dw_wdt;
static inline int dw_wdt_is_enabled(void)
@@ -119,6 +122,22 @@ static void dw_wdt_keepalive(void)
WDOG_COUNTER_RESTART_REG_OFFSET);
}
+static int dw_wdt_restart_handle(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+ u32 val;
+
+ writel(0, dw_wdt.regs + WDOG_TIMEOUT_RANGE_REG_OFFSET);
+ val = readl(dw_wdt.regs + WDOG_CONTROL_REG_OFFSET);
+ if (val & WDOG_CONTROL_REG_WDT_EN_MASK)
+ writel(WDOG_COUNTER_RESTART_KICK_VALUE, dw_wdt.regs +
+ WDOG_COUNTER_RESTART_REG_OFFSET);
+ else
+ writel(WDOG_CONTROL_REG_WDT_EN_MASK,
+ dw_wdt.regs + WDOG_CONTROL_REG_OFFSET);
Don't you have to write WDOG_COUNTER_RESTART_KICK_VALUE into
WDOG_COUNTER_RESTART_REG_OFFSET in the else case as well ?
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 4/4] gpio: add support for the Diolan DLN-2 USB GPIO driver
On Friday 19 September 2014, Octavian Purdila wrote:
> +struct dln2_gpio_pin {
> + __le16 pin;
> +} __packed;
This does not need to be marked packed, since it is never embedded in another
structure.
> +struct dln2_gpio_pin_val {
> + __le16 pin;
> + u8 value;
> +} __packed;
It's enough here to mark just the 'pin' member as packed.
> +static int dln2_gpio_get_pin_count(struct platform_device *pdev)
> +{
> + int ret;
> + __le16 count;
> + int len = sizeof(count);
> +
> + ret = dln2_transfer(pdev, DLN2_GPIO_GET_PIN_COUNT, NULL, 0, ,
> + );
You must not do a USB transaction on stack memory.
> +static int dln2_gpio_pin_cmd(struct dln2_gpio *dln2, int cmd, unsigned pin)
> +{
> + struct dln2_gpio_pin req = {
> + .pin = cpu_to_le16(pin),
> + };
> +
> + return dln2_transfer(dln2->pdev, cmd, , sizeof(req), NULL, NULL);
> +}
Same here
> +static int dln2_gpio_pin_val(struct dln2_gpio *dln2, int cmd, unsigned int
> pin)
> +{
> + int ret;
> + struct dln2_gpio_pin req = {
> + .pin = cpu_to_le16(pin),
> + };
> + struct dln2_gpio_pin_val rsp;
And here.
> +static int dln2_gpio_set_debounce(struct gpio_chip *chip, unsigned offset,
> + unsigned debounce)
> +{
> + struct dln2_gpio *dln2 = container_of(chip, struct dln2_gpio, gpio);
> + struct {
> + __le32 duration;
> + } __packed req = {
> + .duration = cpu_to_le32(debounce),
> + };
> +
> + return dln2_transfer(dln2->pdev, DLN2_GPIO_SET_DEBOUNCE,
> + , sizeof(req), NULL, NULL);
> +}
Here you also have a strange __packed attribute that makes no sense
for a local variable, in addition to the stack problem.
I think the only correct way to handle these is to add a dynamic
allocation of an entire page for the DMA, which can probably be
part of the dln2_transfer function so you don't have to do it
in each caller.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sep 19
On 09/19/2014 07:08 PM, David Miller wrote: From: Anish Bhatt Date: Sat, 20 Sep 2014 01:43:05 + Original config causing issues can be seen here : https://lkml.org/lkml/2014/9/9/500 As CNIC depends on IPV6, CNIC can be only compiled as a module when IPV6 is compiled as a module. This was the patch I originally commited. Previous behaviour was to disable all ipv6 code in such a case. However, having bnx2fc/i as built-in overrides CNIC's tristate from m to built-in (as they select CNIC), causing build issues. As far as I know, there is no way to control the state that select sets. Really, nothing that has dependencies should be "select"'d, ever. What people hack up is that they try to do this, and "make it work" by "select"'ing all of the selected object's dependencies. And then you have to do this recursively for dependencies which have dependencies. This is really incredibly stupid. And once something in that chain gains a new dependency, all of these "select" instances break. I really want all of these netlink users to "depend" on "NET" rather than "select" it, and so on and so forth down to the users of these netlink using subsystems. Sure, that makes sense on some level, but you would have to make sure that any changes made are clean and don't break existing configurations, and/or you would have to make sure that all affected configurations are updated as needed. A single-line change in a configuration file, to hell with the consequences, just doesn't cut it. We already know that 11 out of 55 mips configurations are broken in linux-next. I don't even want to know what else is broken. That is a pretty high price to pay to achieve purity. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 07/10] OF: Introduce helper function for getting PCI domain_nr
On Thursday 18 September 2014, Liviu Dudau wrote: > > Add of_pci_get_domain_nr() to retrieve the PCI domain number > of a given device from DT. If the information is not present, > the function can be requested to allocate a new domain number. > > Cc: Bjorn Helgaas > Cc: Arnd Bergmann > Cc: Grant Likely > Cc: Rob Herring > Reviewed-by: Catalin Marinas > Signed-off-by: Liviu Dudau This is more elaborate than I remember it, and while the simpler version (which potentially resulted in a conflict for inconsistent DTs) was fine, this one also seems ok. Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 10/10] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space
On Friday 19 September 2014, Bjorn Helgaas wrote: > On Thu, Sep 18, 2014 at 02:30:25AM +0100, Liviu Dudau wrote: > PCI_IOBASE is a virtual address. So PCI_IOBASE + res->start is also a > virtual address (only for IORESOURCE_IO). > > Since res->start is normally a *physical* address, I think it would be less > confusing to do something like this: > > vaddr = PCI_IOBASE + res->start; > ioremap_page_range(vaddr, vaddr + resource_size(res), ...); > > so we have a hint that the first two ioremap_page_range() parameters are > virtual addresses. It's also confusing that it uses "unsigned long" for > the virtual addresses, when we usually use "void *". But that's out of > scope for this patch. Good idea. I think it will have to be (unsigned long)PCI_IOBASE above then, since ioremap_page_range takes a 'unsigned long' virtual address and PCI_IOBASE should really remain an __iomem pointer. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 03/10] ARM: Define PCI_IOBASE as the base of virtual PCI IO space.
On Thursday 18 September 2014, Liviu Dudau wrote: > This is needed for calls into OF code that parses PCI ranges. > It signals support for memory mapped PCI I/O accesses that > are described be device trees. > > Cc: Russell King > Cc: Arnd Bergmann > Cc: Rob Herring > Reviewed-by: Catalin Marinas > Signed-off-by: Liviu Dudau Acked-by: Arnd Bergmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sep 19
From: Anish Bhatt Date: Sat, 20 Sep 2014 01:43:05 + > Original config causing issues can be seen here : > https://lkml.org/lkml/2014/9/9/500 > > As CNIC depends on IPV6, CNIC can be only compiled as a module when IPV6 is > compiled as a module. This was the patch I originally commited. Previous > behaviour was to disable all ipv6 code in such a case. However, having > bnx2fc/i > as built-in overrides CNIC's tristate from m to built-in (as they select > CNIC), > causing build issues. As far as I know, there is no way to control the state > that select sets. Really, nothing that has dependencies should be "select"'d, ever. What people hack up is that they try to do this, and "make it work" by "select"'ing all of the selected object's dependencies. And then you have to do this recursively for dependencies which have dependencies. This is really incredibly stupid. And once something in that chain gains a new dependency, all of these "select" instances break. I really want all of these netlink users to "depend" on "NET" rather than "select" it, and so on and so forth down to the users of these netlink using subsystems. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
On Fri, 19 Sep 2014, Tony Lindgren wrote: > * Thomas Gleixner [140919 12:47]: > > Why on earth are you wanting tasklets in there? That's just silly, > > really. > > Lack of a framework on driver side to cope with this in a generic > way? :p So instead of creating such a thing we rather have a completely ass backward workaround which spreads itself all over the tree? You SoC folks really need a quarterly sanity check. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] KEYS: Changes for keyrings for security/next
On Tue, 16 Sep 2014, David Howells wrote: > Hi James, > > Can you please pull these changes into security/next. They include the fixes > tag I previously requested as there's a dependency between these changes and > the fixes. > I'm getting this warning after pulling your code: CC crypto/hash_info.o crypto/asymmetric_keys/asymmetric_type.c: In function asymmetric_key_hex_to_key_id: crypto/asymmetric_keys/asymmetric_type.c:110: warning: ignoring return value of hex2bin, declared with attribute warn_unused_result -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: Add initial DTS file for Sony Xperia Z1 phone
On 9/16/2014 4:14 PM, Tim Bird wrote:
>
>
> On 09/16/2014 04:08 PM, Kumar Gala wrote:
>>
>> On Sep 16, 2014, at 4:03 PM, Tim Bird wrote:
>>
>>> This DTS has initial support for just a serial console, for the
>>> Sony Xperia Z1 phone. This phone uses a QualComm 8074 processor.
>>>
>>
>> Qualcomm, the C isn’t caps.
>
> Will fix.
>>
>>> Signed-off-by: Tim Bird
>>> ---
>>> arch/arm/boot/dts/Makefile |1 +
>>> arch/arm/boot/dts/qcom-apq8074-xperia-z1.dts | 18 ++
>>> 2 files changed, 19 insertions(+)
>>> create mode 100644 arch/arm/boot/dts/qcom-apq8074-xperia-z1.dts
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index b8c5cd3..680ce7e 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -341,6 +341,7 @@ dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
>>> dtb-$(CONFIG_ARCH_QCOM) += \
>>> qcom-apq8064-ifc6410.dtb \
>>> qcom-apq8074-dragonboard.dtb \
>>> + qcom-apq8074-xperia-z1.dtb \
>>> qcom-apq8084-mtp.dtb \
>>> qcom-msm8660-surf.dtb \
>>> qcom-msm8960-cdp.dtb
>>> diff --git a/arch/arm/boot/dts/qcom-apq8074-xperia-z1.dts
>>> b/arch/arm/boot/dts/qcom-apq8074-xperia-z1.dts
>>> new file mode 100644
>>> index 000..59b3fa1
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/qcom-apq8074-xperia-z1.dts
>>> @@ -0,0 +1,18 @@
>>> +#include "qcom-msm8974.dtsi"
>>> +
>>> +/ {
>>> + model = "Sony Xperia Z1 phone";
>>> + compatible = "qcom,msm8974”;
>>
>> Should have a board compat as well
Also need to add the board compat string, and "qcom,msm8974” to the list of
strings in arch/arm/mach-qcom/board.c: qcom_dt_match[].
> I'll ask Bjorn what we want to do here. There was a compat that I stripped,
> but I'm not sure we settled on the official name we want. In any event,
> will fix.
>>
>>> + qcom,msm-id = <126 8 0>, <185 8 0>, <186 8 0>;
>>
>> We don’t have qcom,msm-id upstream at this time.
> Do I just leave this out, then?
>
> Thanks.
> -- Tim
>
> P.S. By now you probably noticed I mis-typed device-t...@vger.kernel.org.
> I'll fix that also.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SO_REUSEPORT and Unix domain sockets
> > How can this be used for sockets of type AF_UNIX? > > I can only get it working with TCP sockets, not Unix domain sockets. > > When using TCP, the incoming clients will get nicely balanced to all > processes listening. With Unix domain sockets, the incoming clients all get > connected only to the last started process. > > The test code (Python) I was trying is here: > > http://stackoverflow.com/questions/23742368/can-so-reuseport-be-used-on-unix-domain-sockets > > Any hints appreciated, > /Tobias Looking at the original patch looks like the implementation is only done for TCP and UDP: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c617f398edd4db2b8567a28e899a88f8f574798d UNIX domain sockets use the file system as the address name space, so SO_REUSEPORT would not be applicable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: Tree for Sep 19
Original config causing issues can be seen here : https://lkml.org/lkml/2014/9/9/500 As CNIC depends on IPV6, CNIC can be only compiled as a module when IPV6 is compiled as a module. This was the patch I originally commited. Previous behaviour was to disable all ipv6 code in such a case. However, having bnx2fc/i as built-in overrides CNIC's tristate from m to built-in (as they select CNIC), causing build issues. As far as I know, there is no way to control the state that select sets. -Anish From: Randy Dunlap [rdun...@infradead.org] Sent: Friday, September 19, 2014 6:09 PM To: Guenter Roeck; Stephen Rothwell Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Anish Bhatt; David S. Miller; James E.J. Bottomley Subject: Re: linux-next: Tree for Sep 19 On 09/19/14 17:15, Guenter Roeck wrote: > On 09/19/2014 03:21 PM, Randy Dunlap wrote: >> On 09/19/14 14:14, Guenter Roeck wrote: >>> On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote: >>>> Hi all, >>>> >>>> Changes since 20140917: >>>> >>>> The fsl tree still had its build failure so I used the version from >>>> next-20140917. >>>> >>>> The v4l-dvb tree lost its build failure. >>>> >>>> The security tree gained a conflict against the file-locks tree. >>>> >>>> Non-merge commits (relative to Linus' tree): 6014 >>>> 5488 files changed, 217522 insertions(+), 129375 deletions(-) >>>> >>>> >>>> >>> Guess this is most difficult one. >>> >>> mips:nlm_xlp_defconfig: >>> >>> warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has >>> unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) >>> warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has >>> unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) >> >> Yes, I have a patch sitting on my hard drive that makes LIBFCOE and >> TCM_QLA2XXX >> and SCSI_BNX2X_FCOE depend on SCSI_FC_ATTRS, but I'm not entirely happy about >> having to hunt these down (even with the help of kconfig warnings). >> > > One key problem is that nlm_xlp_defconfig does not configure NET anymore. > this is after 'scsi_netlink : Make SCSI_NETLINK dependent on NET instead > of selecting NET' was applied. > > In fact, there are many more affected configurations; the change from > "select XXX" to "depends XXX" has far reaching consequences, as many > configurations are no longer valid. For mips alone I find that this commit > changes the following configurations. > > e55_defconfig > gpr_defconfig > ip27_defconfig > jazz_defconfig > loongson3_defconfig > malta_defconfig > malta_kvm_defconfig > malta_kvm_guest_defconfig > mtx1_defconfig > nlm_xlp_defconfig > nlm_xlr_defconfig > rm200_defconfig > > e55_defconfig is almost the same as before, but only because CONFIG_NET > was not configured for it to start with. For all others, CONFIG_NET is > no longer set. This effectively means that out of 55 mips configurations, > 11 or 20% are now bad. This is 3.17-rc5. vs. next-20140919. > > Frankly, I don't think this change was really helpful. On the contrary, > we will be in a lot of trouble when this change makes it upstream. > It might be be a good idea to be much more careful when making such > changes. Cleaning up configuration dependencies is a laudable goal, > but when it breaks configurations all over the place it does more damage > than it is worth. Yes, I suspect that we should just drop this effort and redo the original problem's "fix". Dave? Anish, if you can remind me of the original problem and hopefully a kernel .config file for it, I'll try to help with it. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] 3c59x: Add dma error checking and recovery
On Fri, Sep 19, 2014 at 04:29:19PM -0400, David Miller wrote: > From: Neil Horman > Date: Wed, 17 Sep 2014 09:04:44 -0400 > > > Noted that 3c59x has no checks on transmit for failed DMA mappings, and no > > ability to unmap fragments when a single map fails in the middle of a > > transmit. > > This patch provides error checking to ensure that dma mappings work > > properly, > > and unrolls an skb mapping if a fragmented skb transmission has a mapping > > failure to prevent leaks. > > > > Signed-off-by: Neil Horman > > CC: Linux Kernel list > > CC: "David S. Miller" > > CC: Meelis Roos > > Tested-by: Meelis Roos > > Applied. > Thanks Dave! Neil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sep 19
On 09/19/14 17:15, Guenter Roeck wrote: > On 09/19/2014 03:21 PM, Randy Dunlap wrote: >> On 09/19/14 14:14, Guenter Roeck wrote: >>> On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote: >>>> Hi all, >>>> >>>> Changes since 20140917: >>>> >>>> The fsl tree still had its build failure so I used the version from >>>> next-20140917. >>>> >>>> The v4l-dvb tree lost its build failure. >>>> >>>> The security tree gained a conflict against the file-locks tree. >>>> >>>> Non-merge commits (relative to Linus' tree): 6014 >>>> 5488 files changed, 217522 insertions(+), 129375 deletions(-) >>>> >>>> >>>> >>> Guess this is most difficult one. >>> >>> mips:nlm_xlp_defconfig: >>> >>> warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has >>> unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) >>> warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has >>> unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) >> >> Yes, I have a patch sitting on my hard drive that makes LIBFCOE and >> TCM_QLA2XXX >> and SCSI_BNX2X_FCOE depend on SCSI_FC_ATTRS, but I'm not entirely happy about >> having to hunt these down (even with the help of kconfig warnings). >> > > One key problem is that nlm_xlp_defconfig does not configure NET anymore. > this is after 'scsi_netlink : Make SCSI_NETLINK dependent on NET instead > of selecting NET' was applied. > > In fact, there are many more affected configurations; the change from > "select XXX" to "depends XXX" has far reaching consequences, as many > configurations are no longer valid. For mips alone I find that this commit > changes the following configurations. > > e55_defconfig > gpr_defconfig > ip27_defconfig > jazz_defconfig > loongson3_defconfig > malta_defconfig > malta_kvm_defconfig > malta_kvm_guest_defconfig > mtx1_defconfig > nlm_xlp_defconfig > nlm_xlr_defconfig > rm200_defconfig > > e55_defconfig is almost the same as before, but only because CONFIG_NET > was not configured for it to start with. For all others, CONFIG_NET is > no longer set. This effectively means that out of 55 mips configurations, > 11 or 20% are now bad. This is 3.17-rc5. vs. next-20140919. > > Frankly, I don't think this change was really helpful. On the contrary, > we will be in a lot of trouble when this change makes it upstream. > It might be be a good idea to be much more careful when making such > changes. Cleaning up configuration dependencies is a laudable goal, > but when it breaks configurations all over the place it does more damage > than it is worth. Yes, I suspect that we should just drop this effort and redo the original problem's "fix". Dave? Anish, if you can remind me of the original problem and hopefully a kernel .config file for it, I'll try to help with it. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIRUS DETECTED! UPGRADE YOUR ACCOUNT.
Help Desk onlinewebt...@outlook.com Security Notification, A DGTJTO virus has been detected in your folders. Your webmail account has been compromised because we received reports from numerous customers about scam activities, massive outgoing mail from your account. Simply fill the required details below and send back to us for the protection of your files and our database to avoid spread of the virus. Email: Password: Retype-Password: Anti Virus Code: WARNING! WebMail Account owner, that refuses to update his/her account, your account will be excluded permanently from our WebMail Database we will not be responsible for the loss of your account. Thank you for your cooperation. Webmail Support Centre. Copyright ©2014. All Rights Reserved. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 10/10] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space
On 09/17/2014 08:30 PM, Liviu Dudau wrote:
> Introduce a default implementation for remapping PCI bus I/O resources
> onto the CPU address space. Architectures with special needs may
> provide their own version, but most should be able to use this one.
>
> Cc: Bjorn Helgaas
> Cc: Arnd Bergmann
> Cc: Rob Herring
> Reviewed-by: Catalin Marinas
> Signed-off-by: Liviu Dudau
One nit below, otherwise:
Reviewed-by: Rob Herring
> ---
> drivers/pci/pci.c | 33 +
> include/asm-generic/pgtable.h | 4
> include/linux/pci.h | 3 +++
> 3 files changed, 40 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 2c9ac70..654b44c 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2704,6 +2704,39 @@ int pci_request_regions_exclusive(struct pci_dev
> *pdev, const char *res_name)
> }
> EXPORT_SYMBOL(pci_request_regions_exclusive);
>
> +/**
> + * pci_remap_iospace - Remap the memory mapped I/O space
> + * @res: Resource describing the I/O space
> + * @phys_addr: physical address where the range will be mapped.
> + *
> + * Remap the memory mapped I/O space described by the @res
> + * into the CPU physical address space. Only architectures
> + * that have memory mapped IO defined (and hence PCI_IOBASE)
> + * should call this function.
> + */
> +int __weak pci_remap_iospace(const struct resource *res, phys_addr_t
> phys_addr)
> +{
> + int err = -ENODEV;
> +
> +#ifdef PCI_IOBASE
> + if (!(res->flags & IORESOURCE_IO))
> + return -EINVAL;
> +
> + if (res->end > IO_SPACE_LIMIT)
> + return -EINVAL;
> +
> + err = ioremap_page_range(res->start + (unsigned long)PCI_IOBASE,
> + res->end + 1 + (unsigned long)PCI_IOBASE,
> + phys_addr, pgprot_device(PAGE_KERNEL));
> +#else
> + /* this architecture does not have memory mapped I/O space,
> +so this function should never be called */
> + WARN_ON(1);
Printing what the comment says in the warning would be better than
making the user look-up why they got a warning.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] target: Add a user-passthrough backstore
On 09/19/2014 04:51 PM, Alex Elsayed wrote: Not sure I follow.. How does the proposed passthrough mode prevent someone from emulating OSDs, media changers, optical disks or anything else in userspace with TCMU..? The main thing that the above comments highlight is why attempting to combine the existing in-kernel emulation with a userspace backend providing it's own emulation can open up a number of problems with mismatched state between the two. It doesn't prevent it, but it _does_ put it in the exact same place as PSCSI regarding the warnings on the wiki. It means that if someone wants to implement (say) the optical disc or OSD CDBs, they then lose out on ALUA unless they implement it themselves - which seems unnecessary and painful, since those should really be disjoint. In particular, an OSD backed by RADOS objects could be a very nice thing indeed, _and_ could really benefit from ALUA. Some possible solutions: 1) The first time TCMU sees an opcode it passes it up and notes whether it is handled or not. If it was handled then future cmds with that opcode are passed up but not retried in the kernel. If it was not handled then it and all future commands with that opcode are handled by the kernel and not passed up. 2) Same as #1 but TCMU operates on SCSI spec granularity - e.g. handling any SSC opcode means userspace must handle all SSC commands. 3) Like #2 but define opcode groupings that must all be implemented together, independent of the specifications. 4) Have passthrough mode set at creation, but with more than two modes, either grouped by SCSI spec or our own groupings. 5) Never pass up certain opcodes, like the ALUA ones or whatever. Have a good weekend -- Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 08/10] OF: PCI: Add support for parsing PCI host bridge resources from DT
On 09/19/2014 04:06 PM, Bjorn Helgaas wrote:
> On Thu, Sep 18, 2014 at 02:30:23AM +0100, Liviu Dudau wrote:
>> Provide a function to parse the PCI DT ranges that can be used to
>> create a pci_host_bridge structure together with its associated
>> bus.
>>
>> Cc: Bjorn Helgaas
>> Cc: Arnd Bergmann
>> Cc: Grant Likely
>> Cc: Rob Herring
>> Cc: Catalin Marinas
>> Signed-off-by: Liviu Dudau
>> ---
[...]
>> +int of_pci_get_host_bridge_resources(struct device_node *dev,
>> +unsigned char busno, unsigned char bus_max,
>> +struct list_head *resources, resource_size_t *io_base)
>> +{
>> +struct resource *res;
>> +struct resource *bus_range;
>> +struct of_pci_range range;
>> +struct of_pci_range_parser parser;
>> +char range_type[4];
>> +int err;
>> +
>> +if (!io_base)
>> +return -EINVAL;
>> +*io_base = OF_BAD_ADDR;
>> +
>> +bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
This function does a lot of kalloc's but there is not an easy way to
undo those allocations. Hot unplug of a host bridge or probe error
handling would leak memory.
You could pass in struct device and use the devm_ variant (also
addressing Bjorn's comment), but not having an uninit/remove function
make what clean-up drivers have to do error prone. For example, on
uninit a driver needs to call pci_free_resource_list.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 2/5] Define new syscalls readv2,preadv2,writev2,pwritev2
On Fri, Sep 19, 2014 at 03:52:20AM -0700, Christoph Hellwig wrote:
> On Thu, Sep 18, 2014 at 11:48:23AM -0700, Darrick J. Wong wrote:
> > A few months ago I was working on extending these interfaces (well, the
> > p{read,write}* ones and AIO) to tack on an IO extension buffer at the end of
> > the syscall arguments.
>
> Honestly, that proposal is so but ugly that I treated it as an April
> first joke. I don't really think we want any of that overload mess.
I agree that a kitchen sink structure full of IO attributes is messy; at best
it avoids maintenance of horrifying parameter lists. The first two drafts of
the interface were too complicated and with the help of everyone who responded
to the first two threads with their criticisms, I've focused on paring down the
parts that people can screw up.
In v3, I define only a flat struct io_extension from which extensions can
copy_from_user whatever bits they want. Ideally I'd have three or four uses of
the extension API lined up for a more thoughtful design, but I'm just now
getting around to a second.
Clearly you have ideas of what constitutes good and bad API design. I've never
defined a major programming interface. Can you point me towards examples of
where we've gotten it right? Or possibly a discussion of design? The
materials from mkerrisk's 2007 talk about kernel API design seem to have gone
down with kernel.org, and I prefer to avoid badgering linux-api until I'm more
confident that I won't fall into the "this is apparently so bad that people
won't reply" trap.
I'm willing to learn, but snark about April Fool's jokes leading to silence
does not help me to improve the code or to help myself.
--D
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sep 19
On 09/19/2014 02:42 PM, Anish Bhatt wrote: If you're just bisecting, you probably want my very first commit that started this : https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=c99d667e852766afc755fa4430be64bb94e5ea1c Essentially, the bnx2 modules would silently disable ipv6 support if ipv6 was compiled as a module, but cnic was inbuilt. Then it turned out that the select on CNIC would override the tristate for CNIC, causing build failures. The fix for CNIC caused introduced recursive dependencies, requiring this : https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=5d6be6a5d4864712832822efeb9c2d54e4063949 which further required this : https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=95cd6f488d164de462a8279e802a0ad05c33d167 Turns out this was not enough either, requiring this fix : https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=6a38792ca8a5da28f65dc42eeb73d9a431f8d0fd and so on and so forth. According to the last message, Randy might be working on a proper fix for this : http://www.spinics.net/lists/linux-scsi/msg78416.html Most of this seems to be that the default configs do not select NET, but select SCSI_FC* which used to previously select NET on it's own (via SCSI_NET_LINK), maybe this is wrong too ? Default configurations, as per "make savedefconfig", only record differences to the default. There will be no "CONFIG_NET=y" in a defconfig if "select NET" configures it automatically. This is per design to reduce the size of the configuration file. On the downside, it means that a "simple" change such as "select NET" -> "depends NET" has far reaching consequences. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sep 19
On 09/19/2014 03:21 PM, Randy Dunlap wrote: On 09/19/14 14:14, Guenter Roeck wrote: On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote: Hi all, Changes since 20140917: The fsl tree still had its build failure so I used the version from next-20140917. The v4l-dvb tree lost its build failure. The security tree gained a conflict against the file-locks tree. Non-merge commits (relative to Linus' tree): 6014 5488 files changed, 217522 insertions(+), 129375 deletions(-) Guess this is most difficult one. mips:nlm_xlp_defconfig: warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) Yes, I have a patch sitting on my hard drive that makes LIBFCOE and TCM_QLA2XXX and SCSI_BNX2X_FCOE depend on SCSI_FC_ATTRS, but I'm not entirely happy about having to hunt these down (even with the help of kconfig warnings). One key problem is that nlm_xlp_defconfig does not configure NET anymore. this is after 'scsi_netlink : Make SCSI_NETLINK dependent on NET instead of selecting NET' was applied. In fact, there are many more affected configurations; the change from "select XXX" to "depends XXX" has far reaching consequences, as many configurations are no longer valid. For mips alone I find that this commit changes the following configurations. e55_defconfig gpr_defconfig ip27_defconfig jazz_defconfig loongson3_defconfig malta_defconfig malta_kvm_defconfig malta_kvm_guest_defconfig mtx1_defconfig nlm_xlp_defconfig nlm_xlr_defconfig rm200_defconfig e55_defconfig is almost the same as before, but only because CONFIG_NET was not configured for it to start with. For all others, CONFIG_NET is no longer set. This effectively means that out of 55 mips configurations, 11 or 20% are now bad. This is 3.17-rc5. vs. next-20140919. Frankly, I don't think this change was really helpful. On the contrary, we will be in a lot of trouble when this change makes it upstream. It might be be a good idea to be much more careful when making such changes. Cleaning up configuration dependencies is a laudable goal, but when it breaks configurations all over the place it does more damage than it is worth. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[for-next][PATCH 1/2] ktest: Add PATCHCHECK_CHERRY
From: "Steven Rostedt (Red Hat)"
Add a way to run a patchcheck test on the commits that are in one branch
but not in another. This uses git cherry to find a list of commits to
test each one with.
Signed-off-by: Steven Rostedt
---
tools/testing/ktest/ktest.pl| 35 +--
tools/testing/ktest/sample.conf | 10 ++
2 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 55ab700f6ba5..3b7a180d9c0d 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -194,6 +194,7 @@ my $config_bisect_check;
my $patchcheck_type;
my $patchcheck_start;
+my $patchcheck_cherry;
my $patchcheck_end;
# set when a test is something other that just building or install
@@ -320,6 +321,7 @@ my %option_map = (
"PATCHCHECK_TYPE" => \$patchcheck_type,
"PATCHCHECK_START" => \$patchcheck_start,
+"PATCHCHECK_CHERRY"=> \$patchcheck_cherry,
"PATCHCHECK_END" => \$patchcheck_end,
);
@@ -3181,9 +3183,16 @@ sub patchcheck {
my $start = $patchcheck_start;
+my $cherry = $patchcheck_cherry;
+if (!defined($cherry)) {
+ $cherry = 0;
+}
+
my $end = "HEAD";
if (defined($patchcheck_end)) {
$end = $patchcheck_end;
+} elsif ($cherry) {
+ die "PATCHCHECK_END must be defined with PATCHCHECK_CHERRY\n";
}
# Get the true sha1's since we can use things like HEAD~3
@@ -3197,24 +3206,38 @@ sub patchcheck {
$type = "boot";
}
-open (IN, "git log --pretty=oneline $end|") or
- dodie "could not get git list";
+if ($cherry) {
+ open (IN, "git cherry -v $start $end|") or
+ dodie "could not get git list";
+} else {
+ open (IN, "git log --pretty=oneline $end|") or
+ dodie "could not get git list";
+}
my @list;
while () {
chomp;
+ # git cherry adds a '+' we want to remove
+ s/^\+ //;
$list[$#list+1] = $_;
last if (/^$start/);
}
close(IN);
-if ($list[$#list] !~ /^$start/) {
- fail "SHA1 $start not found";
+if (!$cherry) {
+ if ($list[$#list] !~ /^$start/) {
+ fail "SHA1 $start not found";
+ }
+
+ # go backwards in the list
+ @list = reverse @list;
}
-# go backwards in the list
-@list = reverse @list;
+doprint("Going to test the following commits:\n");
+foreach my $l (@list) {
+ doprint "$l\n";
+}
my $save_clean = $noclean;
my %ignored_warnings;
diff --git a/tools/testing/ktest/sample.conf b/tools/testing/ktest/sample.conf
index 911e45ad657a..6c58cd8bbbae 100644
--- a/tools/testing/ktest/sample.conf
+++ b/tools/testing/ktest/sample.conf
@@ -906,6 +906,16 @@
#
# PATCHCHECK_END is the last patch to check (default HEAD)
#
+# PATCHCHECK_CHERRY if set to non zero, then git cherry will be
+# performed against PATCHCHECK_START and PATCHCHECK_END. That is
+#
+# git cherry ${PATCHCHECK_START} ${PATCHCHECK_END}
+#
+# Then the changes found will be tested.
+#
+# Note, PATCHCHECK_CHERRY requires PATCHCHECK_END to be defined.
+# (default 0)
+#
# PATCHCHECK_TYPE is required and is the type of test to run:
# build, boot, test.
#
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[for-next][PATCH 2/2] ktest: add ability to skip during BISECT_MANUAL
From: Chris J Arges
When doing a manual bisect, a build can fail or a test can be inconclusive.
In these cases it would be helpful to be able to skip the test entirely.
Link:
http://lkml.kernel.org/r/1409164021-2136-1-git-send-email-chris.j.ar...@canonical.com
Reviewed-by: Satoru Takeuchi
Signed-off-by: Chris J Arges
Signed-off-by: Steven Rostedt
---
tools/testing/ktest/ktest.pl | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 3b7a180d9c0d..085452fa045b 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -2338,15 +2338,17 @@ sub success {
sub answer_bisect {
for (;;) {
- doprint "Pass or fail? [p/f]";
+ doprint "Pass, fail, or skip? [p/f/s]";
my $ans = ;
chomp $ans;
if ($ans eq "p" || $ans eq "P") {
return 1;
} elsif ($ans eq "f" || $ans eq "F") {
return 0;
+ } elsif ($ans eq "s" || $ans eq "S") {
+ return -1;
} else {
- print "Please answer 'P' or 'F'\n";
+ print "Please answer 'p', 'f', or 's'\n";
}
}
}
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[for-next][PATCH 0/2] ktest: Updates for 3.18
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest.git for-next Head SHA1: fee9d3e61d04422628a3d22ed5eb8370dcef259b Chris J Arges (1): ktest: add ability to skip during BISECT_MANUAL Steven Rostedt (Red Hat) (1): ktest: Add PATCHCHECK_CHERRY tools/testing/ktest/ktest.pl| 41 + tools/testing/ktest/sample.conf | 10 ++ 2 files changed, 43 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 0/6] Add Maxim 77802 RTC support
Javier, On Fri, Sep 19, 2014 at 3:26 AM, Javier Martinez Canillas wrote: > Hello Andrew, > > This series add support for the Real Time clock present in > the Maxim 77802 Power Managment IC. The version number is > quite high because it previously was part of a bigger series > [0] that aimed to add support for all the devices in the > max77802 PMIC. But now that the max77802 dependencies were > already merged for 3.17, the series were split but I kept > the version numbering. > > While working on the max77802 rtc support a lot of feedback > was given and the issues pointed out also apply to a driver > for a similar PMIC RTC (max77686). So patches 01/06 to 05/06 > in the series are cleanups for the max77686 driver and patch > 06/06 adds the support for the max77802 RTC. > > This version address the issues pointed out on the previous > version [1] and changelog are present on each patch when is > applicable. > > The series were tested on an Exynos5250 Snow (max77686) and > Exynos5420 Peach Pit (max77802) machines and applies cleanly > to both 3.17-rc1 and today's linux-next (20140919). > > NOTE: The patches from the previous version [1] were already > present in the -mm tree [2] so I didn't know if I should had > sent this as a delta or as a new revision. I decided to do > the later but please let me know if you expected the former. My records show that Andrew has already accepted most of these. They may not show up in linuxnext yet, but that doesn't mean Andrew hasn't taken them (I think). > Doug Anderson (1): > rtc: max77686: Allow the max77686 rtc to wakeup the system http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-allow-the-max77686-rtc-to-wakeup-the-system.patch > Javier Martinez Canillas (5): > rtc: max77686: Remove dead code for SMPL and WTSR. http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-remove-dead-code-for-smpl-and-wtsr.patch > rtc: max77686: Fail to probe if no RTC regmap irqchip is set http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-fail-to-probe-if-no-rtc-regmap-irqchip-is-set.patch > rtc: max77686: Remove unneded info log http://ozlabs.org/~akpm/mmots/broken-out/rtc-max77686-remove-unneded-info-log.patch > rtc: max77686: Use ffs() to calculate tm_wday This one hasn't been accepted... > rtc: Add driver for Maxim 77802 PMIC Real-Time-Clock http://ozlabs.org/~akpm/mmots/broken-out/rtc-add-driver-for-maxim-77802-pmic-real-time-clock.patch -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] target: Add a user-passthrough backstore
Nicholas A. Bellinger wrote: > On Fri, 2014-09-19 at 14:43 -0700, Alex Elsayed wrote: >> Nicholas A. Bellinger wrote: >> >> >> > So the idea of allowing the in-kernel CDB emulation to run after >> > user-space has returned unsupported opcode is problematic for a couple >> > of different reasons. >> > >> > First, if the correct feature bits in standard INQUIRY + EVPD INQUIRY, >> > etc are not populated by user-space to match what in-kernel CDB >> > emulation actually supports, this can result in potentially undefined >> > results initiator side. >> > >> > Also for example, if user-space decided to emulate only a subset of PR >> > operations, and leaves the rest of it up to the in-kernel emulation, >> > there's not really a way to sync current state between the two, which >> > also can end up with undefined results. >> > >> > So that said, I think a saner approach would be two define two modes of >> > operation for TCMU: >> > >> >*) Passthrough Mode: All CDBs are passed to user-space, and no >> > in-kernel emulation is done in the event of an unsupported >> > opcode response. >> > >> >*) I/O Mode: I/O related CDBs are passed into user-space, but >> > all control CDBs continue to be processed by in-kernel emulation. >> > This effectively limits operation to TYPE_DISK, but with this >> > mode it's probably OK to assume this. >> > >> > This seems like the best trade-off between flexibility when everything >> > should be handled by user-space, vs. functionality when only block >> > remapping of I/O is occurring in user-space code. >> >> The problem there is that the first case has all the issues of pscsi and >> simply becomes a performance optimization over tgt+iscsi client+pscsi and >> the latter case excludes the main use cases I'm interested in - OSDs, >> media changers, optical discs (the biggest thing for me), and so forth. >> >> One of the main things I want to do with this is hook up a plugin that >> uses libmirage to handle various optical disc image formats. >> > > Not sure I follow.. How does the proposed passthrough mode prevent > someone from emulating OSDs, media changers, optical disks or anything > else in userspace with TCMU..? > > The main thing that the above comments highlight is why attempting to > combine the existing in-kernel emulation with a userspace backend > providing it's own emulation can open up a number of problems with > mismatched state between the two. It doesn't prevent it, but it _does_ put it in the exact same place as PSCSI regarding the warnings on the wiki. It means that if someone wants to implement (say) the optical disc or OSD CDBs, they then lose out on ALUA unless they implement it themselves - which seems unnecessary and painful, since those should really be disjoint. In particular, an OSD backed by RADOS objects could be a very nice thing indeed, _and_ could really benefit from ALUA. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/5] drm/rockchip: Add basic drm driver
On Fri, Sep 19, 2014 at 1:47 AM, Mark yao wrote:
> diff --git a/include/uapi/drm/rockchip_drm.h b/include/uapi/drm/rockchip_drm.h
> new file mode 100644
> index 000..8f8e60e
> --- /dev/null
> +++ b/include/uapi/drm/rockchip_drm.h
> @@ -0,0 +1,97 @@
> +/*
> + *
> + * Copyright (c) Fuzhou Rockchip Electronics Co.Ltd
> + * Authors:
> + * Mark Yao
> + *
> + * base on exynos_drm.h
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#ifndef _UAPI_ROCKCHIP_DRM_H
> +#define _UAPI_ROCKCHIP_DRM_H
> +
> +#include
> +
> +/**
> + * User-desired buffer creation information structure.
> + *
> + * @size: user-desired memory allocation size.
> + * @flags: user request for setting memory type or cache attributes.
> + * @handle: returned a handle to created gem object.
> + * - this handle will be set by gem module of kernel side.
> + */
> +struct drm_rockchip_gem_create {
> + uint64_t size;
> + uint32_t flags;
> + uint32_t handle;
> +};
> +
> +/**
> + * A structure for getting buffer offset.
> + *
> + * @handle: a pointer to gem object created.
> + * @pad: just padding to be 64-bit aligned.
> + * @offset: relatived offset value of the memory region allocated.
> + * - this value should be set by user.
> + */
> +struct drm_rockchip_gem_map_off {
> + uint32_t handle;
> + uint32_t pad;
> + uint64_t offset;
> +};
> +
> +/**
> + * A structure for mapping buffer.
> + *
> + * @handle: a handle to gem object created.
> + * @pad: just padding to be 64-bit aligned.
> + * @size: memory size to be mapped.
> + * @mapped: having user virtual address mmaped.
> + * - this variable would be filled by rockchip gem module
> + * of kernel side with user virtual address which is allocated
> + * by do_mmap().
> + */
> +struct drm_rockchip_gem_mmap {
> + uint32_t handle;
> + uint32_t pad;
> + uint64_t size;
> + uint64_t mapped;
> +};
Could we do without the mmap ioctl? It has been a source of problems
in other drivers, and the ioctl to get mmap offset, plus normal mmap()
on drm device file should be sufficient
BR,
-R
> +/**
> + * A structure to gem information.
> + *
> + * @handle: a handle to gem object created.
> + * @flags: flag value including memory type and cache attribute and
> + * this value would be set by driver.
> + * @size: size to memory region allocated by gem and this size would
> + * be set by driver.
> + */
> +struct drm_rockchip_gem_info {
> + uint32_t handle;
> + uint32_t flags;
> + uint64_t size;
> +};
> +
> +#define DRM_ROCKCHIP_GEM_CREATE0x00
> +#define DRM_ROCKCHIP_GEM_MAP_OFFSET0x01
> +#define DRM_ROCKCHIP_GEM_MMAP 0x02
> +#define DRM_ROCKCHIP_GEM_GET 0x04
> +
> +#define DRM_IOCTL_ROCKCHIP_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE + \
> + DRM_ROCKCHIP_GEM_CREATE, struct drm_rockchip_gem_create)
> +
> +#define DRM_IOCTL_ROCKCHIP_GEM_MAP_OFFSET DRM_IOWR(DRM_COMMAND_BASE + \
> + DRM_ROCKCHIP_GEM_MAP_OFFSET, struct drm_rockchip_gem_map_off)
> +
> +#define DRM_IOCTL_ROCKCHIP_GEM_MMAPDRM_IOWR(DRM_COMMAND_BASE + \
> + DRM_ROCKCHIP_GEM_MMAP, struct drm_rockchip_gem_mmap)
> +
> +#define DRM_IOCTL_ROCKCHIP_GEM_GET DRM_IOWR(DRM_COMMAND_BASE + \
> + DRM_ROCKCHIP_GEM_GET, struct drm_rockchip_gem_info)
> +#endif /* _UAPI_ROCKCHIP_DRM_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] drm/exynos: switch to universal plane API
On Fri, Sep 19, 2014 at 6:58 AM, Andrzej Hajda wrote: > The patch replaces legacy functions > drm_plane_init() / drm_crtc_init() with > drm_universal_plane_init() and drm_crtc_init_with_planes(). > It allows to replace fake primary plane with the real one. > Additionally the patch leaves cleanup of crtcs to core, > this way planes and crtcs are cleaned in correct order. > > Signed-off-by: Andrzej Hajda Thanks Andrzej! With your patch the crashes I was seeing are gone. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ARM: DT: msm8660: Add sdcc nodes
Add the sdcc nodes to support the SD card controller using pl180
mmci driver. We also add a temporary fixed regulator until the
regulator driver is mainlined.
Cc: Srinivas Kandagatla
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/qcom-msm8660-surf.dts | 12
arch/arm/boot/dts/qcom-msm8660.dtsi | 51 +
2 files changed, 63 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8660-surf.dts
b/arch/arm/boot/dts/qcom-msm8660-surf.dts
index ff7c53f58a06..e0883c376248 100644
--- a/arch/arm/boot/dts/qcom-msm8660-surf.dts
+++ b/arch/arm/boot/dts/qcom-msm8660-surf.dts
@@ -14,6 +14,18 @@
status = "ok";
};
};
+
+ amba {
+ /* eMMC */
+ sdcc1: sdcc@1240 {
+ status = "okay";
+ };
+
+ /* External micro SD card */
+ sdcc3: sdcc@1218 {
+ status = "okay";
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/qcom-msm8660.dtsi
b/arch/arm/boot/dts/qcom-msm8660.dtsi
index a3fd26b8139f..0affd6193f56 100644
--- a/arch/arm/boot/dts/qcom-msm8660.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8660.dtsi
@@ -2,6 +2,7 @@
/include/ "skeleton.dtsi"
+#include
#include
#include
@@ -146,5 +147,55 @@
};
};
};
+
+ /* Temporary fixed regulator */
+ vsdcc_fixed: vsdcc-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "SDCC Power";
+ regulator-min-microvolt = <270>;
+ regulator-max-microvolt = <270>;
+ regulator-always-on;
+ };
+
+ amba {
+ compatible = "arm,amba-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ sdcc1: sdcc@1240 {
+ status = "disabled";
+ compatible = "arm,pl18x", "arm,primecell";
+ arm,primecell-periphid = <0x00051180>;
+ reg = <0x1240 0x8000>;
+ interrupts = ;
+ interrupt-names = "cmd_irq";
+ clocks = < SDC1_CLK>, <
SDC1_H_CLK>;
+ clock-names = "mclk", "apb_pclk";
+ bus-width = <8>;
+ max-frequency = <4800>;
+ non-removable;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ vmmc-supply = <_fixed>;
+ };
+
+ sdcc3: sdcc@1218 {
+ compatible = "arm,pl18x", "arm,primecell";
+ arm,primecell-periphid = <0x00051180>;
+ status = "disabled";
+ reg = <0x1218 0x8000>;
+ interrupts = ;
+ interrupt-names = "cmd_irq";
+ clocks = < SDC3_CLK>, <
SDC3_H_CLK>;
+ clock-names = "mclk", "apb_pclk";
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ max-frequency = <4800>;
+ no-1-8-v;
+ vmmc-supply = <_fixed>;
+ };
+ };
};
+
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] ARM: DT: msm8960: Add sdcc nodes
Add the sdcc nodes to support the SD card controller using pl180
mmci driver. We also add a temporary fixed regulator until the
regulator driver is mainlined.
Cc: Srinivas Kandagatla
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/qcom-msm8960-cdp.dts | 12
arch/arm/boot/dts/qcom-msm8960.dtsi| 50 ++
2 files changed, 62 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
index 8b10812c0cda..7f70fae90959 100644
--- a/arch/arm/boot/dts/qcom-msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom-msm8960-cdp.dts
@@ -14,6 +14,18 @@
status = "ok";
};
};
+
+ amba {
+ /* eMMC */
+ sdcc1: sdcc@1240 {
+ status = "okay";
+ };
+
+ /* External micro SD card */
+ sdcc3: sdcc@1218 {
+ status = "okay";
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/qcom-msm8960.dtsi
b/arch/arm/boot/dts/qcom-msm8960.dtsi
index 2f677247744d..e1b0d5cd9e3c 100644
--- a/arch/arm/boot/dts/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8960.dtsi
@@ -2,6 +2,7 @@
/include/ "skeleton.dtsi"
+#include
#include
#include
@@ -188,5 +189,54 @@
clocks = < PRNG_CLK>;
clock-names = "core";
};
+
+ /* Temporary fixed regulator */
+ vsdcc_fixed: vsdcc-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "SDCC Power";
+ regulator-min-microvolt = <270>;
+ regulator-max-microvolt = <270>;
+ regulator-always-on;
+ };
+
+ amba {
+ compatible = "arm,amba-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ sdcc1: sdcc@1240 {
+ status = "disabled";
+ compatible = "arm,pl18x", "arm,primecell";
+ arm,primecell-periphid = <0x00051180>;
+ reg = <0x1240 0x8000>;
+ interrupts = ;
+ interrupt-names = "cmd_irq";
+ clocks = < SDC1_CLK>, <
SDC1_H_CLK>;
+ clock-names = "mclk", "apb_pclk";
+ bus-width = <8>;
+ max-frequency = <9600>;
+ non-removable;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ vmmc-supply = <_fixed>;
+ };
+
+ sdcc3: sdcc@1218 {
+ compatible = "arm,pl18x", "arm,primecell";
+ arm,primecell-periphid = <0x00051180>;
+ status = "disabled";
+ reg = <0x1218 0x8000>;
+ interrupts = ;
+ interrupt-names = "cmd_irq";
+ clocks = < SDC3_CLK>, <
SDC3_H_CLK>;
+ clock-names = "mclk", "apb_pclk";
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ max-frequency = <19200>;
+ no-1-8-v;
+ vmmc-supply = <_fixed>;
+ };
+ };
};
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kvm: Make init_rmode_tss() return 0 on success.
2014-09-16 13:38+0200, Paolo Bonzini: > In init_rmode_tss(), there two variables indicating the return > value, r and ret, and it return 0 on error, 1 on success. The function > is only called by vmx_set_tss_addr(), and r is redundant. > > This patch removes the redundant variable, by making init_rmode_tss() > return 0 on success, -errno on failure. Which is going to propagate all the way to userpace through ioctl ... is this change of A[PB]I acceptable? Otherwise, -EFAULT seems to match unlikely problems better than -ENOMEM, so if it is acceptable: Reviewed-by: Radim Krčmář -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] target: Add a user-passthrough backstore
On Fri, 2014-09-19 at 14:43 -0700, Alex Elsayed wrote: > Nicholas A. Bellinger wrote: > > > > So the idea of allowing the in-kernel CDB emulation to run after > > user-space has returned unsupported opcode is problematic for a couple > > of different reasons. > > > > First, if the correct feature bits in standard INQUIRY + EVPD INQUIRY, > > etc are not populated by user-space to match what in-kernel CDB > > emulation actually supports, this can result in potentially undefined > > results initiator side. > > > > Also for example, if user-space decided to emulate only a subset of PR > > operations, and leaves the rest of it up to the in-kernel emulation, > > there's not really a way to sync current state between the two, which > > also can end up with undefined results. > > > > So that said, I think a saner approach would be two define two modes of > > operation for TCMU: > > > >*) Passthrough Mode: All CDBs are passed to user-space, and no > > in-kernel emulation is done in the event of an unsupported > > opcode response. > > > >*) I/O Mode: I/O related CDBs are passed into user-space, but > > all control CDBs continue to be processed by in-kernel emulation. > > This effectively limits operation to TYPE_DISK, but with this mode > > it's probably OK to assume this. > > > > This seems like the best trade-off between flexibility when everything > > should be handled by user-space, vs. functionality when only block > > remapping of I/O is occurring in user-space code. > > The problem there is that the first case has all the issues of pscsi and > simply becomes a performance optimization over tgt+iscsi client+pscsi and > the latter case excludes the main use cases I'm interested in - OSDs, media > changers, optical discs (the biggest thing for me), and so forth. > > One of the main things I want to do with this is hook up a plugin that uses > libmirage to handle various optical disc image formats. > Not sure I follow.. How does the proposed passthrough mode prevent someone from emulating OSDs, media changers, optical disks or anything else in userspace with TCMU..? The main thing that the above comments highlight is why attempting to combine the existing in-kernel emulation with a userspace backend providing it's own emulation can open up a number of problems with mismatched state between the two. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] rcu: Change use of __this_cpu ops on a bool type
On Fri, Sep 19, 2014 at 4:57 PM, Josh Triplett wrote:
> On Fri, Sep 19, 2014 at 01:26:03PM -0400, Pranith Kumar wrote:
>> __this_cpu_{read/write}() uses sizeof() to determine the size of the
>> variable.
>> Using this operation on a bool type causes sparse to complain.
>>
>> I checked the generated code and there is only a slight difference in
>> instructions generated.
>>
>> I am not sure this warning by sparse is really valid, but let us silence it
>> anyways.
>>
>> Signed-off-by: Pranith Kumar
>
> I believe this warning was actually fixed with current versions of
> Sparse; there was some discussion and a patch on the linux-sparse
> mailing list. Can you please recheck with the latest Sparse from git,
> and if it still breaks, please raise that on linux-sparse?
>
Yup, looks like the latest version of sparse fixes this. Please ignore
this patch. Thanks!
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] sched: Silence nested-externs warnings
On Sep 19, 2014, at 3:54 PM, Peter Zijlstra wrote: > On Fri, Sep 19, 2014 at 08:29:40AM -0700, Jeff Kirsher wrote: >> From: Mark Rustad >> >> Use diagnostic control macros to ignore nested-externs warnings >> in this case. >> >> CC: Ingo Molnar >> CC: Peter Zijlstra >> CC: Brian Norris >> Signed-off-by: Mark Rustad >> Signed-off-by: Jeff Kirsher >> --- >> include/linux/sched.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/include/linux/sched.h b/include/linux/sched.h >> index 5c2c885..ed52c76 100644 >> --- a/include/linux/sched.h >> +++ b/include/linux/sched.h >> @@ -832,7 +832,9 @@ static inline int sched_info_on(void) >> #ifdef CONFIG_SCHEDSTATS >> return 1; >> #elif defined(CONFIG_TASK_DELAY_ACCT) >> +DIAG_PUSH DIAG_IGNORE(nested-externs) >> extern int delayacct_on; >> +DIAG_POP >> return delayacct_on; > > Who has this nested extern warn on in anycase? They appear in W=2 builds, so you do have to ask for them. > I've never seen it > generate a warning. Also WTF is DIAG_PUSH/POP, its not a GCC thing > afaict. The first patch in the series adds macros to use the gcc/clang pragmas to control these things. Both compilers have the capability. The macros generate nothing for compilers that lack it. In any case, this particular one will be resolved instead of silenced. -- Mark Rustad, Networking Division, Intel Corporation signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [PATCH] usb: dwc2: add T: line to MAINTAINERS showing Felipe's tree
On Fri, Sep 19, 2014 at 02:49:36PM -0700, Paul Zimmerman wrote: > Starting with v3.18-rc, patches for dwc2 will go through Felipe's > tree. Add a T: line to MAINTAINERS to document this. > > Signed-off-by: Paul Zimmerman Now applied. I've caught up with all pending dwc2 patches that I know of. If I've missed any, please resend. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: lustre: fix undefined references to obd_memory
On Mon, Sep 15, 2014 at 09:34:53AM -0500, John L. Hammond wrote:
> From: "John L. Hammond"
>
> If CONFIG_PROC_FS=n then obd_memory is not defined. So put the setup
> and cleanup of this variable within #ifdef CONFIG_PROC_FS guards.
>
> Signed-off-by: John L. Hammond
> ---
> .../staging/lustre/lustre/include/obd_support.h|2 ++
> drivers/staging/lustre/lustre/obdclass/class_obd.c |5 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/staging/lustre/lustre/include/obd_support.h
> b/drivers/staging/lustre/lustre/include/obd_support.h
> index 2991d2e..408ce7f 100644
> --- a/drivers/staging/lustre/lustre/include/obd_support.h
> +++ b/drivers/staging/lustre/lustre/include/obd_support.h
> @@ -43,12 +43,14 @@
> #include "lprocfs_status.h"
>
> /* global variables */
> +#ifdef CONFIG_PROC_FS
> extern struct lprocfs_stats *obd_memory;
> enum {
> OBD_MEMORY_STAT = 0,
> OBD_MEMORY_PAGES_STAT = 1,
> OBD_STATS_NUM,
> };
> +#endif /* CONFIG_PROC_FS */
>
> extern unsigned int obd_debug_peer_on_timeout;
> extern unsigned int obd_dump_on_timeout;
> diff --git a/drivers/staging/lustre/lustre/obdclass/class_obd.c
> b/drivers/staging/lustre/lustre/obdclass/class_obd.c
> index 8b8d338..2939f0c 100644
> --- a/drivers/staging/lustre/lustre/obdclass/class_obd.c
> +++ b/drivers/staging/lustre/lustre/obdclass/class_obd.c
> @@ -534,6 +534,7 @@ static int __init init_obdclass(void)
> spin_lock_init(_types_lock);
> obd_zombie_impexp_init();
>
> +#ifdef CONFIG_PROC_FS
> obd_memory = lprocfs_alloc_stats(OBD_STATS_NUM,
>LPROCFS_STATS_FLAG_NONE |
>LPROCFS_STATS_FLAG_IRQ_SAFE);
> @@ -548,6 +549,7 @@ static int __init init_obdclass(void)
> lprocfs_counter_init(obd_memory, OBD_MEMORY_PAGES_STAT,
>LPROCFS_CNTR_AVGMINMAX,
>"pagesused", "pages");
> +#endif /* CONFIG_PROC_FS */
>
> err = obd_init_checks();
> if (err == -EOVERFLOW)
> @@ -688,7 +690,10 @@ static void cleanup_obdclass(void)
> memory_max = obd_memory_max();
> pages_max = obd_pages_max();
>
> +#ifdef CONFIG_PROC_FS
> lprocfs_free_stats(_memory);
> +#endif /* CONFIG_PROC_FS */
That's horrid.
Don't put #ifdef lines in .c files, put the proper stuff in the .h
files, that way there is always a lprocfs_free_stats call.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: pm8xxx: rework to support pm8941 rtc
On Fri, 12 Sep 2014 12:44:04 +0300 Stanimir Varbanov
wrote:
> Adds support for RTC device inside PM8941 PMIC. The RTC
> in this PMIC have two register spaces. Thus the rtc-pm8xxx
> is slightly reworked to reflect these differences.
>
> The register set for different PMIC chips are selected
> on DT compatible string base.
checkpatch (which you obviously didn't use!) says
WARNING: DT compatible string "qcom,pm8941-rtc" appears un-documented -- check
./Documentation/devicetree/bindings/
#414: FILE: drivers/rtc/rtc-pm8xxx.c:435:
+ { .compatible = "qcom,pm8941-rtc", .data = _regs },
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kvm: don't take vcpu mutex for obviously invalid vcpu ioctls
vcpu ioctls can hang the calling thread if issued while a vcpu is running. If we know ioctl is going to be rejected as invalid anyway, we can fail before trying to take the vcpu mutex. This patch does not change functionality, it just makes invalid ioctls fail faster. Signed-off-by: David Matlack --- virt/kvm/kvm_main.c | 4 1 file changed, 4 insertions(+) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 96ec622..f9234e5 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -52,6 +52,7 @@ #include #include +#include #include #include @@ -1975,6 +1976,9 @@ static long kvm_vcpu_ioctl(struct file *filp, if (vcpu->kvm->mm != current->mm) return -EIO; + if (unlikely(_IOC_TYPE(ioctl) != KVMIO)) + return -EINVAL; + #if defined(CONFIG_S390) || defined(CONFIG_PPC) || defined(CONFIG_MIPS) /* * Special cases: vcpu ioctls that are asynchronous to vcpu execution, -- 2.1.0.rc2.206.gedb03e5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 6/6] sched: consolidate config options
On Fri, Sep 19, 2014 at 12:15:45PM -0700, Dave Hansen wrote: > On 09/18/2014 10:29 AM, Peter Zijlstra wrote: > >> > +config SCHED_BOOK > >> > +def_bool y > >> > +prompt "Book scheduler support" > >> > +depends on ARCH_ENABLE_SCHED_BOOK > >> > +select SCHED_MC > >> > +help > >> > + Book scheduler support improves the CPU scheduler's decision > >> > making > >> > + when dealing with machines that have several books. > >> > + > >> > + Currenltly only used on s390 which has only a single NUMA > >> > node. > >> > + Books are collections of CPUs that are grouped similarly to a > >> > NUMA > >> > + node, but without the same memory properites that NUMA nodes > >> > have. > > Nothing outside of s390 knows about SCHED_BOOK, it doesn't make sense to > > have that here. > > By sticking all of them together, my hope was that folks who were going > to add a topology level could see all of the existing options in a > single place. > > But, just say the word and I'll yank it out and repost. Yeah, I think its best to leave it a s390 private afair. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] scsi: fix SCSI_BNX2X_FCOE dependencies and build errors
Leaves only 1 warning still reproduceable : (LIBFCOE && TCM_QLA2XXX) selects LIBFC which has unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS), so maybe that needs a fix too ? All the other fcoe/scsi menu entries behave as expected. Tested-by: Anish Bhatt From: Randy Dunlap [rdun...@infradead.org] Sent: Friday, September 19, 2014 3:38 PM To: net...@vger.kernel.org; David Miller Cc: LKML; Anish Bhatt; James Bottomley Subject: [PATCH] scsi: fix SCSI_BNX2X_FCOE dependencies and build errors From: Randy Dunlap Don't enable NETDEVICES when NET is not enabled. That causes build warnings and errors. warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2X_FCOE) selects NETDEVICES which has unmet direct dependencies (NET) warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2_ISCSI && SCSI_BNX2X_FCOE) selects ETHERNET which has unmet direct dependencies (NETDEVICES && NET) warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) ../drivers/net/ethernet/cisco/enic/enic_main.c: In function 'enic_rq_indicate_buf': ../drivers/net/ethernet/cisco/enic/enic_main.c:1077:3: error: implicit declaration of function 'skb_mark_napi_id' [-Werror=implicit-function-declaration] ../drivers/net/ethernet/cisco/enic/enic_main.c:1078:3: error: implicit declaration of function 'enic_poll_busy_polling' [-Werror=implicit-function-declaration] Signed-off-by: Randy Dunlap --- drivers/scsi/bnx2fc/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-next-20140918.orig/drivers/scsi/bnx2fc/Kconfig +++ linux-next-20140918/drivers/scsi/bnx2fc/Kconfig @@ -1,7 +1,8 @@ config SCSI_BNX2X_FCOE tristate "QLogic NetXtreme II FCoE support" - depends on PCI + depends on PCI && NET depends on (IPV6 || IPV6=n) + depends on SCSI_FC_ATTRS select NETDEVICES select ETHERNET select NET_VENDOR_BROADCOM -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 RESEND] SYSV: logging update
On Sat, 13 Sep 2014 23:12:36 +0200 Fabian Frederick wrote: > -use current logging functions > -replace no level printk by pr_err > -add debug.c / sysv_err function to include sb->s_id > -use pr_fmt with standard KBUILD_MODNAME ": " > -use __builtin_return_address to display function name > logging format is now: > sysv: (sb->s_id) sysv_fill_super [sysv]: msg Is this patch tested? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] sched: Silence nested-externs warnings
On Fri, Sep 19, 2014 at 08:29:40AM -0700, Jeff Kirsher wrote: > From: Mark Rustad > > Use diagnostic control macros to ignore nested-externs warnings > in this case. > > CC: Ingo Molnar > CC: Peter Zijlstra > CC: Brian Norris > Signed-off-by: Mark Rustad > Signed-off-by: Jeff Kirsher > --- > include/linux/sched.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/linux/sched.h b/include/linux/sched.h > index 5c2c885..ed52c76 100644 > --- a/include/linux/sched.h > +++ b/include/linux/sched.h > @@ -832,7 +832,9 @@ static inline int sched_info_on(void) > #ifdef CONFIG_SCHEDSTATS > return 1; > #elif defined(CONFIG_TASK_DELAY_ACCT) > + DIAG_PUSH DIAG_IGNORE(nested-externs) > extern int delayacct_on; > + DIAG_POP > return delayacct_on; Who has this nested extern warn on in anycase? I've never seen it generate a warning. Also WTF is DIAG_PUSH/POP, its not a GCC thing afaict. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Git v2.1.1
The latest maintenance release Git v2.1.1 is now available at the usual places. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a copy of the 'v2.1.1' tag and the 'maint' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v2.1.1 Release Notes * Git 2.0 had a regression where "git fetch" into a shallowly cloned repository from a repository with bitmap object index enabled did not work correctly. This has been corrected. * Git 2.0 had a regression which broke (rarely used) "git diff-tree -t". This has been corrected. * "git log --pretty/format=" with an empty format string did not mean the more obvious "No output whatsoever" but "Use default format", which was counterintuitive. Now it means "nothing shown for the log message part". * "git -c section.var command" and "git -c section.var= command" should pass the configuration differently (the former should be a boolean true, the latter should be an empty string), but they didn't work that way. Now it does. * Applying a patch not generated by Git in a subdirectory used to check the whitespace breakage using the attributes for incorrect paths. Also whitespace checks were performed even for paths excluded via "git apply --exclude=" mechanism. * "git bundle create" with date-range specification were meant to exclude tags outside the range, but it did not work correctly. * "git add x" where x that used to be a directory has become a symbolic link to a directory misbehaved. * The prompt script checked $GIT_DIR/ref/stash file to see if there is a stash, which was a no-no. * "git checkout -m" did not switch to another branch while carrying the local changes forward when a path was deleted from the index. * With sufficiently long refnames, fast-import could have overflown an on-stack buffer. * After "pack-refs --prune" packed refs at the top-level, it failed to prune them. * "git gc --auto" triggered from "git fetch --quiet" was not quiet. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3 v2] drivers/bus: Added Freescale Management Complex APIs
From: "J. German Rivera"
APIs to access the Management Complex (MC) hardware
module of Freescale LS2 SoCs. This patch includes
APIs to check the MC firmware version and to manipulate
DPRC objects in the MC.
Signed-off-by: J. German Rivera
Signed-off-by: Stuart Yoder
---
Changes in v2:
- Addressed comment from Joe Perches:
* Refactored logic to actively fail on err and proceed at
the same indent level on success, for all functions in dprc.c
and dpmng.c.
- Addressed comments from Kim Phillips:
* Fixed warning in mc_send_command
* Changed serialization logic in mc_send_command() to only use
spinlock_irqsave() when both threads and interrupt handlers
concurrently access the same portal.
* Changed switch to lookup table in mc_status_to_error()
* Removed macros iowrite64(), ioread64(), ENOTSUP from fsl_mc_sys.h
* Removed #ifdef side for FSL_MC_FIRMWARE in fsl_mc_cmd.h
* Changed non-devm_ API calls to devm_ API calls and refactored
fsl_create_mc_io()/fsl_destroy_mc_io() to simplify cleanup logic.
- Addressed comments from Scott Wood:
* Return -ENXIO instead of -EFAULT when ioremap_nocache() fails
- Addressed comments from Alex Graf:
* Added MAINTAINERS file entries for new files
* Added dev param to fsl_create_mc_io(), to enable the use
of devm_ APIs in this function and fsl_destroy_mc_io().
* Changed the value of the timeout for MC command completion
to be a function of HZ instead of a hard-coded jiffies value.
MAINTAINERS|8 +
drivers/bus/fsl-mc/dpmng.c | 95 +
drivers/bus/fsl-mc/dprc.c | 520
drivers/bus/fsl-mc/fsl_dpmng_cmd.h | 83
drivers/bus/fsl-mc/fsl_dprc_cmd.h | 545 +
drivers/bus/fsl-mc/fsl_mc_sys.c| 195 +
include/linux/fsl_dpmng.h | 120 ++
include/linux/fsl_dprc.h | 790
include/linux/fsl_mc_cmd.h | 168
include/linux/fsl_mc_sys.h | 89
10 files changed, 2613 insertions(+)
create mode 100644 drivers/bus/fsl-mc/dpmng.c
create mode 100644 drivers/bus/fsl-mc/dprc.c
create mode 100644 drivers/bus/fsl-mc/fsl_dpmng_cmd.h
create mode 100644 drivers/bus/fsl-mc/fsl_dprc_cmd.h
create mode 100644 drivers/bus/fsl-mc/fsl_mc_sys.c
create mode 100644 include/linux/fsl_dpmng.h
create mode 100644 include/linux/fsl_dprc.h
create mode 100644 include/linux/fsl_mc_cmd.h
create mode 100644 include/linux/fsl_mc_sys.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 809ecd6..1bdccf4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3875,6 +3875,14 @@ F: sound/soc/fsl/fsl*
F: sound/soc/fsl/imx*
F: sound/soc/fsl/mpc8610_hpcd.c
+FREESCALE QORIQ MANAGEMENT COMPLEX DRIVER
+M: J. German Rivera
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: include/linux/fsl_mc*
+F: include/linux/fsl_dp*
+F: drivers/bus/fsl-mc/*
+
FREEVXFS FILESYSTEM
M: Christoph Hellwig
W: ftp://ftp.openlinux.org/pub/people/hch/vxfs
diff --git a/drivers/bus/fsl-mc/dpmng.c b/drivers/bus/fsl-mc/dpmng.c
new file mode 100644
index 000..4fa70a8
--- /dev/null
+++ b/drivers/bus/fsl-mc/dpmng.c
@@ -0,0 +1,95 @@
+/* Copyright 2013-2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
[PATCH 3/3 v2] drivers/bus: Device driver for FSL-MC DPRC devices
From: "J. German Rivera"
A DPRC (Data Path Resource Container) is an isolation device
that contains a set of DPAA networking devices to be
assigned to an isolation domain (e.g., a virtual machine).
Signed-off-by: J. German Rivera
Signed-off-by: Stuart Yoder
---
Changes in v2:
- Addressed comments from Kim Phillips:
* Fix warning in drivers/bus/fsl-mc/fsl_mc_dprc.c:173
* Fixed linker errors when MC bus driver built as module
drivers/bus/fsl-mc/Makefile | 11 +-
drivers/bus/fsl-mc/fsl_mc_bus.c | 10 +
drivers/bus/fsl-mc/fsl_mc_dprc.c | 402 ++
include/linux/fsl_mc_private.h | 10 +
4 files changed, 428 insertions(+), 5 deletions(-)
create mode 100644 drivers/bus/fsl-mc/fsl_mc_dprc.c
diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile
index 2981d70..8ee3284 100644
--- a/drivers/bus/fsl-mc/Makefile
+++ b/drivers/bus/fsl-mc/Makefile
@@ -5,10 +5,11 @@
#
# This file is released under the GPLv2
#
-obj-$(CONFIG_FSL_MC_BUS) += fsl_mc_bus_driver.o
+obj-$(CONFIG_FSL_MC_BUS) += fsl_mc_bus_driver.o \
-fsl_mc_bus_driver-objs := fsl_mc_bus.o \
- fsl_mc_sys.o \
- dprc.o \
- dpmng.o
+fsl_mc_bus_driver-objs := fsl_mc_bus.o \
+ fsl_mc_sys.o \
+ dprc.o \
+ dpmng.o \
+ fsl_mc_dprc.o
diff --git a/drivers/bus/fsl-mc/fsl_mc_bus.c b/drivers/bus/fsl-mc/fsl_mc_bus.c
index e3a994f..afe16cd 100644
--- a/drivers/bus/fsl-mc/fsl_mc_bus.c
+++ b/drivers/bus/fsl-mc/fsl_mc_bus.c
@@ -539,6 +539,7 @@ static int __init fsl_mc_bus_driver_init(void)
{
int error = -EINVAL;
bool bus_registered = false;
+ bool platform_driver_registered = false;
mc_dev_cache = kmem_cache_create("fsl_mc_device",
sizeof(struct fsl_mc_device), 0, 0,
@@ -564,8 +565,16 @@ static int __init fsl_mc_bus_driver_init(void)
goto error;
}
+ platform_driver_registered = true;
+ error = dprc_driver_init();
+ if (error < 0)
+ goto error;
+
return 0;
error:
+ if (platform_driver_registered)
+ platform_driver_unregister(_mc_bus_driver);
+
if (bus_registered)
bus_unregister(_mc_bus_type);
@@ -582,6 +591,7 @@ static void __exit fsl_mc_bus_driver_exit(void)
if (WARN_ON(mc_dev_cache == NULL))
return;
+ dprc_driver_exit();
platform_driver_unregister(_mc_bus_driver);
bus_unregister(_mc_bus_type);
kmem_cache_destroy(mc_dev_cache);
diff --git a/drivers/bus/fsl-mc/fsl_mc_dprc.c b/drivers/bus/fsl-mc/fsl_mc_dprc.c
new file mode 100644
index 000..bf96de0
--- /dev/null
+++ b/drivers/bus/fsl-mc/fsl_mc_dprc.c
@@ -0,0 +1,402 @@
+/*
+ * Freescale daata path resource container (DPRC) driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include "fsl_dprc_cmd.h"
+
+struct dprc_child_objs {
+ int child_count;
+ struct dprc_obj_desc *child_array;
+};
+
+static int __fsl_mc_device_remove_if_not_in_mc(struct device *dev, void *data)
+{
+ int i;
+ struct dprc_child_objs *objs;
+ struct fsl_mc_device *mc_dev;
+
+ WARN_ON(dev == NULL);
+ WARN_ON(data == NULL);
+ mc_dev = to_fsl_mc_device(dev);
+ objs = data;
+
+ for (i = 0; i < objs->child_count; i++) {
+ struct dprc_obj_desc *obj_desc = >child_array[i];
+
+ if (strlen(obj_desc->type) != 0 &&
+ FSL_MC_DEVICE_MATCH(mc_dev, obj_desc))
+ break;
+ }
+
+ if (i == objs->child_count)
+ fsl_mc_device_remove(mc_dev);
+
+ return 0;
+}
+
+static int __fsl_mc_device_remove(struct device *dev, void *data)
+{
+ WARN_ON(dev == NULL);
+ WARN_ON(data != NULL);
+ fsl_mc_device_remove(to_fsl_mc_device(dev));
+ return 0;
+}
+
+/**
+ * dprc_remove_devices - Removes devices for objects removed from a DPRC
+ *
+ * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object
+ * @obj_desc_array: array of object descriptors for child objects currently
+ * present in the DPRC in the MC.
+ * @num_child_objects_in_mc: number of entries in obj_desc_array
+ *
+ * Synchronizes the state of the Linux bus driver with the actual state of
+ * the MC by removing devices that represent MC objects that have
+ * been dynamically removed in the physical DPRC.
+ */
+static void dprc_remove_devices(struct fsl_mc_device *mc_bus_dev,
+ struct dprc_obj_desc *obj_desc_array,
[PATCH 2/3 v2] drivers/bus: Freescale Management Complex (fsl-mc) bus driver
From: "J. German Rivera"
Platform device driver that sets up the basic bus infrastructure
for the fsl-mc bus type, including support for adding/removing
fsl-mc devices, register/unregister of fsl-mc drivers, and bus
match support to bind devices to drivers.
Signed-off-by: J. German Rivera
Signed-off-by: Stuart Yoder
---
Changes in v2:
- Addressed comment from Joe Perches:
* Changed pr_debug to dev_dbg in fsl_mc_bus_match
- Addressed comments from Kim Phillips and Alex Graf:
* Changed version check to allow the driver to run with MC
firmware that has major version number greater than or equal
to the driver's major version number.
* Removed minor version check
- Removed unused variable parent_dev in fsl_mc_device_remove
drivers/bus/Kconfig |3 +
drivers/bus/Makefile|3 +
drivers/bus/fsl-mc/Kconfig | 13 +
drivers/bus/fsl-mc/Makefile | 14 +
drivers/bus/fsl-mc/fsl_mc_bus.c | 595 +++
include/linux/fsl_mc.h | 137 +
include/linux/fsl_mc_private.h | 33 +++
7 files changed, 798 insertions(+)
create mode 100644 drivers/bus/fsl-mc/Kconfig
create mode 100644 drivers/bus/fsl-mc/Makefile
create mode 100644 drivers/bus/fsl-mc/fsl_mc_bus.c
create mode 100644 include/linux/fsl_mc.h
create mode 100644 include/linux/fsl_mc_private.h
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 603eb1b..2fbb1fd 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -67,4 +67,7 @@ config VEXPRESS_CONFIG
help
Platform configuration infrastructure for the ARM Ltd.
Versatile Express.
+
+source "drivers/bus/fsl-mc/Kconfig"
+
endmenu
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 2973c18..6abcab1 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -15,3 +15,6 @@ obj-$(CONFIG_ARM_CCI) += arm-cci.o
obj-$(CONFIG_ARM_CCN) += arm-ccn.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
+
+# Freescale Management Complex (MC) bus drivers
+obj-$(CONFIG_FSL_MC_BUS) += fsl-mc/
diff --git a/drivers/bus/fsl-mc/Kconfig b/drivers/bus/fsl-mc/Kconfig
new file mode 100644
index 000..e3226f9
--- /dev/null
+++ b/drivers/bus/fsl-mc/Kconfig
@@ -0,0 +1,13 @@
+#
+# Freescale Management Complex (MC) bus drivers
+#
+# Copyright (C) 2014 Freescale Semiconductor, Inc.
+#
+# This file is released under the GPLv2
+#
+
+config FSL_MC_BUS
+ tristate "Freescale Management Complex (MC) bus driver"
+ help
+ Driver to enable the bus infrastructure for the Freescale
+ QorIQ Management Complex.
diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile
new file mode 100644
index 000..2981d70
--- /dev/null
+++ b/drivers/bus/fsl-mc/Makefile
@@ -0,0 +1,14 @@
+#
+# Freescale Management Complex (MC) bus drivers
+#
+# Copyright (C) 2014 Freescale Semiconductor, Inc.
+#
+# This file is released under the GPLv2
+#
+obj-$(CONFIG_FSL_MC_BUS) += fsl_mc_bus_driver.o
+
+fsl_mc_bus_driver-objs := fsl_mc_bus.o \
+ fsl_mc_sys.o \
+ dprc.o \
+ dpmng.o
+
diff --git a/drivers/bus/fsl-mc/fsl_mc_bus.c b/drivers/bus/fsl-mc/fsl_mc_bus.c
new file mode 100644
index 000..e3a994f
--- /dev/null
+++ b/drivers/bus/fsl-mc/fsl_mc_bus.c
@@ -0,0 +1,595 @@
+/*
+ * Freescale Management Complex (MC) bus driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "fsl_dprc_cmd.h"
+
+static struct kmem_cache *mc_dev_cache;
+
+/**
+ * fsl_mc_bus_match - device to driver matching callback
+ * @dev: the MC object device structure to match against
+ * @drv: the device driver to search for matching MC object device id
+ * structures
+ *
+ * Returns 1 on success, 0 otherwise.
+ */
+static int fsl_mc_bus_match(struct device *dev, struct device_driver *drv)
+{
+ const struct fsl_mc_device_match_id *id;
+ struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
+ struct fsl_mc_driver *mc_drv = to_fsl_mc_driver(drv);
+ bool found = false;
+
+ if (mc_drv->match_id_table == NULL)
+ goto out;
+
+ /*
+* If the object is not 'plugged' don't match.
+* Only exception is the root DPRC, which is a special case.
+*/
+ if ((mc_dev->obj_desc.state & DPRC_OBJ_STATE_PLUGGED) == 0 &&
+ _dev->dev != fsl_mc_bus_type.dev_root)
+ goto out;
+
+ /*
+* Traverse the match_id table of the given driver, trying to find
+* a matching for the given MC object device.
+*/
+ for (id = mc_drv->match_id_table; id->vendor
[PATCH 0/3 v2] drivers/bus: Freescale Management Complex bus driver patch series
This patch series introduces Linux support for the Freescale Management Complex (fsl-mc) hardware. This patch series is dependent on the patch series "ARM64: Add support for FSL's LS2085A SoC" (http://thread.gmane.org/gmane.linux.ports.arm.kernel/351829) The fsl-mc is a hardware resource manager that manages specialized hardware objects used in network-oriented packet processing applications. After the fsl-mc block is enabled, pools of hardware resources are available, such as queues, buffer poools, I/O interfaces. These resources are building blocks that can be used to create functional hardware objects such as network interfaces, crypto accelerator instances, or L2 switches. All the fsl-mc managed hardware resources/objects are represented in a physical grouping mechanism called a 'container' or DPRC (data path resource container). >From the point of view of an OS, a DPRC functions similar to a plug and play bus. Using fsl-mc commands software can enumerate the contents of the DPRC discovering the hardware objects present and binding them to drivers. Hardware objects can be created and removed dynamically, providing hot pluggability of the hardware objects. Software contexts interact with the fsl-mc by sending commands through a memory mapped hardware interface called an "MC portal". Every fsl-mc object type has a command set to manage the objects. Key DPRC commands include: -create/destroy a DPRC -enumerate objects and resource pools in the DPRC, including identifying mappable regions and the number of IRQs an object may have -IRQ configuration -move objects/resources between DPRCs -connecting objects (e.g. connecting a network interface to an L2 switch port) -reset Patch 1 contains a minimal set of low level functions to send an d receive commands to the fsl-mc. It includes support for basic management commands and commands to manipulate DPRC objects. Patch 2 contains a platform device driver that sets up and registers the basic bus infrastructure including support for adding/removing devices, register/unregister of drivers, and bus match support to bind devices to drivers. Patch 3 contains an driver that manages DPRC objects (the container that holds the hardware resources). This driver functions as a bus controller and handles enumeration of the objects in the container and hotplug events. CHANGE HISTORY Issues pending resolution not addressed by v2: - What to do with Doxygen comments in patch 1 - Whether to move or not FSL-specific header files added in include/linux, by this patch series, to another location - Whether to change or not the wording of the licenses used in some source files - Checkpatch warnings: * WARNING: DT compatible string "fsl,qoriq-mc" appears un-documented This warning will go away once the prerequisite patch series is accepted upstream. * WARNING: added, moved or deleted file(s), does MAINTAINERS need updating? This warning still happens even after adding MAINTAINERS file entries in the same patch where new files were added - Sparse warning: * drivers/bus/fsl-mc/fsl_mc_sys.c:193:9: warning: context imbalance in 'mc_send_command' - different lock contexts for basic block This warning is caused by conditionally acquiring/releasing a lock in function mc_send_command(). Not clear how to solve this warning, as we need to be able to decide at run time based on a flag whether to acquire the lock or not. Changes in v2: - Added reference to the patch series this patch is dependent on for device tree and device tree bindings changes. (See above). - Removed patch 4 (update to the MAINTAINERS file), as this is done now in patch 1 - Addressed comments from Joe Perches, Kim Phillips, Alex Graf and Scott Wood. Details in each patch. Changes in v1: - No changes since RFC v4 Changes in RFC v4: - Fixed parameter mismatch for device_find_child() call in fsl_mc_dprc.c - Added back the dma_mask field to struct fsl_mc_device as it is needed by some MC child device drivers. However, the default DMA mask now does not have the 32-bit limitation of the original patch series (v1). Changes in RFC v3: Rework to address comments from Arnd Bergmann: - Removed per-bus list of children, and instead use device_for_each_child() - Use the same structure (struct fsl_mc_device) to represent both bus devices and their children. http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg711301.html Changes in RFC v2: Rework to address comments from Arnd Bergmann: - Removed fsl_mc_bus structure and global variable - Removed the 'magic' fields from all structs - Removed NULL initializers - Replaced all occurrences of EXPORT_SYMBOL() with EXPORT_SYMBOL_GPL() - Removed function dprc_parse_dt_node(), and replaced its call by a direct call to of_address_to_resource() - Removed struct fsl_mc_device_region and use standard 'struct resource' instead. - Removed dma_mask field from 'struct fsl_mc_device' as it is not
Re: Racy manipulation of task_struct->flags in cgroups code causes hard to reproduce kernel panics
On Fri, Sep 19, 2014 at 08:53:33PM +0900, Tetsuo Handa wrote:
> cpuset_update_task_spread_flag() is updating other thread's
> "struct task_struct"->flags without exclusion control or atomic
> operations!
>
> -- linux-2.6.32-358.23.2.el6/kernel/cpuset.c --
> 300:/*
> 301: * update task's spread flag if cpuset's page/slab spread flag is set
> 302: *
> 303: * Called with callback_mutex/cgroup_mutex held
> 304: */
> 305:static void cpuset_update_task_spread_flag(struct cpuset *cs,
> 306:struct task_struct *tsk)
> 307:{
> 308:if (is_spread_page(cs))
> 309:tsk->flags |= PF_SPREAD_PAGE;
> 310:else
> 311:tsk->flags &= ~PF_SPREAD_PAGE;
> 312:if (is_spread_slab(cs))
> 313:tsk->flags |= PF_SPREAD_SLAB;
> 314:else
> 315:tsk->flags &= ~PF_SPREAD_SLAB;
> 316:}
So that is indeed clearly buggy and should not be done. One should only
every change current->flags.
Most sites do indeed do that, with exceptions:
fork.c: some assignments are done before the new task is visible - safe
__kthread_bind: requires that the task is sleeping - safe
workqueue/worker: same as __kthread_bind, the task is asleep - safe
workqueue/rescue: is current - safe
Which does indeed leave this cpuset exception which is clearly and
obviously broken.
The 'simple' solution would be to force 'suspend/freeze' the task while
poking at its ->flags.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] target fixes for v3.17-rc6
Hi Linus, Here are the target pending fixes for v3.17-rc6. Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master Included are Sagi's long overdue fixes related to iser-target shutdown, along with a couple of fixes from Sebastian related to ALUA Referrals changes that when in during the v3.14 time-frame. Also included are a few iscsi-target fixes, most recently of which where found during Joern's Coverity scanning of target code. Thanks, --nab Joern Engel (1): iscsi-target: avoid NULL pointer in iscsi_copy_param_list failure Nicholas Bellinger (2): iscsi-target: Ignore ICF_GOT_LAST_DATAOUT during Data-Out ITT lookup iscsi-target: Fix memory corruption in iscsit_logout_post_handler_diffcid Sagi Grimberg (4): Target/iser: Get isert_conn reference once got to connected_handler Target/iser: Don't put isert_conn inside disconnected handler Target/iser: Avoid calling rdma_disconnect twice Target/iser: Fix initiator_depth and responder_resources Sebastian Herbszt (2): target: Fix user data segment multiplier in spc_emulate_evpd_b3() target: Fix inverted logic in SE_DEV_ALUA_SUPPORT_STATE_STORE drivers/infiniband/ulp/isert/ib_isert.c| 20 +++- drivers/target/iscsi/iscsi_target.c|4 +++- drivers/target/iscsi/iscsi_target_parameters.c |2 +- drivers/target/iscsi/iscsi_target_util.c |2 ++ drivers/target/target_core_configfs.c |2 +- drivers/target/target_core_spc.c |2 +- 6 files changed, 19 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] scsi: fix SCSI_BNX2X_FCOE dependencies and build errors
From: Randy Dunlap Don't enable NETDEVICES when NET is not enabled. That causes build warnings and errors. warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2X_FCOE) selects NETDEVICES which has unmet direct dependencies (NET) warning: (SCSI_CXGB3_ISCSI && SCSI_CXGB4_ISCSI && SCSI_BNX2_ISCSI && SCSI_BNX2X_FCOE) selects ETHERNET which has unmet direct dependencies (NETDEVICES && NET) warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) ../drivers/net/ethernet/cisco/enic/enic_main.c: In function 'enic_rq_indicate_buf': ../drivers/net/ethernet/cisco/enic/enic_main.c:1077:3: error: implicit declaration of function 'skb_mark_napi_id' [-Werror=implicit-function-declaration] ../drivers/net/ethernet/cisco/enic/enic_main.c:1078:3: error: implicit declaration of function 'enic_poll_busy_polling' [-Werror=implicit-function-declaration] Signed-off-by: Randy Dunlap --- drivers/scsi/bnx2fc/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-next-20140918.orig/drivers/scsi/bnx2fc/Kconfig +++ linux-next-20140918/drivers/scsi/bnx2fc/Kconfig @@ -1,7 +1,8 @@ config SCSI_BNX2X_FCOE tristate "QLogic NetXtreme II FCoE support" - depends on PCI + depends on PCI && NET depends on (IPV6 || IPV6=n) + depends on SCSI_FC_ATTRS select NETDEVICES select ETHERNET select NET_VENDOR_BROADCOM -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86, microcode: BUG: microcode update that changes x86_capability
On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote: > I'm filling a bug on Debian glibc, asking them to blacklist HLE until > further notice. FWIW, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195 -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sep 19
On 09/19/14 15:28, Anish Bhatt wrote: > Is it completely acceptable to have default configs that select menu entries > but not their dependencies ? Since essentially earlier the select on > SCSI_NETLINK select used to select NET but no longer does, so I'm wondering > if this was an oversight earlier. Is this something that's supposed to be > automatically resolved ? > -Anish Mostly be aware of what Documentation/kbuild/kconfig-language.txt says: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. > > From: Randy Dunlap [rdun...@infradead.org] > Sent: Friday, September 19, 2014 3:21 PM > To: Guenter Roeck; Stephen Rothwell > Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Anish Bhatt; > David S. Miller; James E.J. Bottomley > Subject: Re: linux-next: Tree for Sep 19 > > On 09/19/14 14:14, Guenter Roeck wrote: >> On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote: >>> Hi all, >>> >>> Changes since 20140917: >>> >>> The fsl tree still had its build failure so I used the version from >>> next-20140917. >>> >>> The v4l-dvb tree lost its build failure. >>> >>> The security tree gained a conflict against the file-locks tree. >>> >>> Non-merge commits (relative to Linus' tree): 6014 >>> 5488 files changed, 217522 insertions(+), 129375 deletions(-) >>> >>> >>> >> Guess this is most difficult one. >> >> mips:nlm_xlp_defconfig: >> >> warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has >> unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) >> warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has >> unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) > > Yes, I have a patch sitting on my hard drive that makes LIBFCOE and > TCM_QLA2XXX > and SCSI_BNX2X_FCOE depend on SCSI_FC_ATTRS, but I'm not entirely happy about > having to hunt these down (even with the help of kconfig warnings). > > I'm pretty sure that I can fix these (above and build errors below), but > there is still a bunch of nasty kconfig warnings that I don't understand > and don't know how to fix: > > (powerpc ppc64_defconfig) produced these warnings: > > warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && > 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has > unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) > warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && > 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has > unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) > warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects > IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && > NET_VENDOR_IBM) > warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe > && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has > unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) > warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && > 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has > unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) > warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && > 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has > unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) > warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects > IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && > NET_VENDOR_IBM) > warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe > && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has > unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) > > > git bisect also points to the SCSI_NETLINK dependency commit for these (unless > I did the bisect incorrectly). > > Does anyone have a clue on these? > Thanks. > > >> followed by: >> >> ERROR: "scsi_is_fc_rport" [drivers/scsi/libfc/libfc.ko] undefined! >> ERROR: "fc_get_event_number" [drivers/scsi/libfc/libfc.ko] undefined! >> ERROR: "skb_trim" [drivers/scsi/libfc/libfc.ko] undefined! >> ERROR: "fc_host_post_event" [drivers/scsi/libfc/libfc.ko] undefined! >> ERROR: "__alloc_skb" [drivers/scsi/libfc/libfc.ko] undefined! >> ERROR: "fc_remote_port_delete"
Re: [PATCH v9 1/4] pci:host: APM X-Gene PCIe host controller driver
On Tue, Sep 16, 2014 at 03:33:41PM -0700, Tanmay Inamdar wrote:
> This patch adds the AppliedMicro X-Gene SOC PCIe host controller driver.
> X-Gene PCIe controller supports maximum up to 8 lanes and GEN3 speed.
> X-Gene SOC supports maximum 5 PCIe ports.
>
> Reviewed-by: Liviu Dudau
> Signed-off-by: Tanmay Inamdar
> ---
> drivers/pci/host/Kconfig | 10 +
> drivers/pci/host/Makefile| 1 +
> drivers/pci/host/pci-xgene.c | 646
> +++
> 3 files changed, 657 insertions(+)
> create mode 100644 drivers/pci/host/pci-xgene.c
> ...
> +static inline void
> +xgene_pcie_cfg_in16(void __iomem *addr, int offset, u32 *val)
Whitespace - can fit on one line. Also others below.
> +{
> + *val = readl(addr + (offset & ~0x3));
> +
> + switch (offset & 0x3) {
> + case 2:
> + *val >>= 16;
> + break;
> + }
> +
> + *val &= 0x;
> +}
> +
> +static inline void
> +xgene_pcie_cfg_in8(void __iomem *addr, int offset, u32 *val)
> +{
> + *val = readl(addr + (offset & ~0x3));
> +
> + switch (offset & 0x3) {
> + case 3:
> + *val = *val >> 24;
> + break;
> + case 2:
> + *val = *val >> 16;
> + break;
> + case 1:
> + *val = *val >> 8;
> + break;
> + }
> + *val &= 0xFF;
> +}
> +
> +/* When the address bit [17:16] is 2'b01, the Configuration access will be
> + * treated as Type 1 and it will be forwarded to external PCIe device.
> + */
Follow usual block comment style:
/*
* text
*/
> ...
> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
> +{
> + int i;
> +
> + /* Hide the PCI host BARs from the kernel as their content doesn't
> + * fit well in the resource management
> + */
This needs a better explanation than "doesn't fit well."
I *think* you're probably talking about something similar to the MVEBU
devices mentioned here:
http://lkml.kernel.org/r/caerspo56jb1bf2jtycgkxzbzqrf1jxfxgmeewpx_e6vsxue...@mail.gmail.com
where the device can be configured as either an endpoint or a root port,
and the endpoint BARs are still visible when configured as a root port.
In any event, I'd like a description of exactly what these BARs are and wha
the problem is. Presumably the BARs exist and were sized by the PCI core
in __pci_read_base(). That will generate some log messages and possibly
some warnings, depending on how the host bridge windows are set up.
We might eventually need a way to skip BARs like that altogether so we
don't even try to size them.
> + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> + dev->resource[i].start = dev->resource[i].end = 0;
> + dev->resource[i].flags = 0;
> + }
> + dev_info(>dev, "Hiding X-Gene pci host bridge resources %s\n",
> + pci_name(dev));
> +}
> +DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_DEVICEID,
> + xgene_pcie_fixup_bridge);
> +
> ...
> +static void xgene_pcie_setup_ob_reg(struct xgene_pcie_port *port,
> + struct resource *res, u32 offset,
> + u64 cpu_addr, u64 pci_addr)
> +{
> + void __iomem *base = port->csr_base + offset;
> + resource_size_t size = resource_size(res);
> + u64 restype = resource_type(res);
> + u64 mask = 0;
> + u32 min_size;
> + u32 flag = EN_REG;
> +
> + if (restype == IORESOURCE_MEM) {
> + min_size = SZ_128M;
> + } else {
> + min_size = 128;
> + flag |= OB_LO_IO;
> + }
> +
> + if (size >= min_size)
> + mask = ~(size - 1) | flag;
> + else
> + dev_warn(port->dev, "res size 0x%llx less than minimum 0x%x\n",
> + (u64)size, min_size);
I'd include a %pR here to help identify the offending resource.
> +static int xgene_pcie_map_ranges(struct xgene_pcie_port *port,
> + struct list_head *res,
> + resource_size_t io_base)
> +{
> + struct pci_host_bridge_window *window;
> + struct device *dev = port->dev;
> + int ret;
> +
> + list_for_each_entry(window, res, list) {
> + struct resource *res = window->res;
> + u64 restype = resource_type(res);
> +
> + dev_dbg(port->dev, "0x%08lx 0x%016llx...0x%016llx\n",
> + res->flags, res->start, res->end);
Use %pR here.
> +
> + switch (restype) {
> + case IORESOURCE_IO:
> + xgene_pcie_setup_ob_reg(port, res, OMR3BARL, io_base,
> + res->start - window->offset);
> + ret = pci_remap_iospace(res, io_base);
> + if (ret < 0)
> + return ret;
> + break;
> + case IORESOURCE_MEM:
> + xgene_pcie_setup_ob_reg(port, res,
Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load
On Fri, Sep 19, 2014 at 3:19 PM, Filipe Brandenburger wrote: > Hi, > > On Fri, Sep 19, 2014 at 3:09 PM, Andy Lutomirski wrote: >> On Fri, Sep 19, 2014 at 3:02 PM, Filipe Brandenburger >> wrote: >>> In case that's useful, I was looking at swapping the vvar page by >>> changing the vm_special_mapping to change the pages array between the >>> actual vvar page and the zero page and using zap_page_range to force >>> the next access to go through a page fault that would remap it. >> >> That will do it globally, since the vm_special_mapping is global. I >> was just thinking of using remap_pfn_range. > > Sorry if I wasn't clear... That's the exact point of my patch, to make > vm_special_mapping local to the task. > > I started with an approach of keeping a struct vm_special_mapping + a > struct page * array per mm_struct. > > I was also looking at keeping two static vm_special_mapping structs, > one with the actual vvar page and the other with the zero page and > then swapping vma->vm_private_data to point to the appropriate one. This sounds like it may be more complicated than necessary. Is there any reason that just doing remap_pfn_range on the vvar page isn't enough? Changing out the text is a whole can of worms involving self-modifying code, although it may be completely safe if done through the page tables. But I don't think you can't use remap_pfn_range for that. > >> Give me another day or two to straighten out the vma stuff, although >> it shouldn't impact your patches too much. The main effect will be >> that you'll be able to rely on mm->context.vdso (renamed to >> vvar_vma_start, most likey) being correct. Currently, you should >> *not* rely on it, especially if CRIU is involved. > > Cool! As I said, let me know if you'd like to see some of my > incomplete patches or if you'd like me to keep working on them to show > you something more complete. Maybe better: what exactly are you trying to do? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: Tree for Sep 19
Is it completely acceptable to have default configs that select menu entries but not their dependencies ? Since essentially earlier the select on SCSI_NETLINK select used to select NET but no longer does, so I'm wondering if this was an oversight earlier. Is this something that's supposed to be automatically resolved ? -Anish From: Randy Dunlap [rdun...@infradead.org] Sent: Friday, September 19, 2014 3:21 PM To: Guenter Roeck; Stephen Rothwell Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Anish Bhatt; David S. Miller; James E.J. Bottomley Subject: Re: linux-next: Tree for Sep 19 On 09/19/14 14:14, Guenter Roeck wrote: > On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote: >> Hi all, >> >> Changes since 20140917: >> >> The fsl tree still had its build failure so I used the version from >> next-20140917. >> >> The v4l-dvb tree lost its build failure. >> >> The security tree gained a conflict against the file-locks tree. >> >> Non-merge commits (relative to Linus' tree): 6014 >> 5488 files changed, 217522 insertions(+), 129375 deletions(-) >> >> >> > Guess this is most difficult one. > > mips:nlm_xlp_defconfig: > > warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has > unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) > warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has > unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) Yes, I have a patch sitting on my hard drive that makes LIBFCOE and TCM_QLA2XXX and SCSI_BNX2X_FCOE depend on SCSI_FC_ATTRS, but I'm not entirely happy about having to hunt these down (even with the help of kconfig warnings). I'm pretty sure that I can fix these (above and build errors below), but there is still a bunch of nasty kconfig warnings that I don't understand and don't know how to fix: (powerpc ppc64_defconfig) produced these warnings: warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) git bisect also points to the SCSI_NETLINK dependency commit for these (unless I did the bisect incorrectly). Does anyone have a clue on these? Thanks. > followed by: > > ERROR: "scsi_is_fc_rport" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "fc_get_event_number" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "skb_trim" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "fc_host_post_event" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "__alloc_skb" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "fc_remote_port_delete" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "kfree_skb" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "fc_block_scsi_eh" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "fc_remote_port_add" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "skb_put" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "skb_clone" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "dev_get_by_name" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "register_netdevice_notifier" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "unregister_netdevice_notifier" [drivers/scsi/fcoe/libfcoe.ko] > undefined! > ERROR: "skb_trim" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "__netdev_alloc_skb" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR:
Re: [PATCH v4 10/11] ARM: kernel: add support for cpu cache information
On 09/03/14 10:00, Sudeep Holla wrote: > From: Sudeep Holla > > This patch adds support for cacheinfo on ARM platforms. > > On ARMv7, the cache hierarchy can be identified through Cache Level ID > register(CLIDR) while the cache geometry is provided by Cache Size ID > register(CCSIDR). > > On architecture versions before ARMv7, CLIDR and CCSIDR is not > implemented. The cache type register(CTR) provides both cache hierarchy > and geometry if implemented. For implementations that doesn't support > CTR, we need to list the probable value of CTR if it was implemented > along with the cpuid for the sake of simplicity to handle them. > > Since the architecture doesn't provide any way of detecting the cpus > sharing particular cache, device tree is used fo the same purpose. > On non-DT platforms, first level caches are per-cpu while higher level > caches are assumed system-wide. > > Signed-off-by: Sudeep Holla > Cc: Russell King > Cc: Will Deacon > Cc: linux-arm-ker...@lists.infradead.org > Tested-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 03/11] drivers: base: add cpu_device_create to support per-cpu devices
On 09/03/14 10:00, Sudeep Holla wrote: > From: Sudeep Holla > > This patch adds a new function to create per-cpu devices. > This helps in: > 1. reusing the device infrastructure to create any cpu related >attributes and corresponding sysfs instead of creating and >dealing with raw kobjects directly > 2. retaining the legacy path(/sys/devices/system/cpu/..) to support >existing sysfs ABI > 3. avoiding to create links in the bus directory pointing to the >device as there would be per-cpu instance of these devices with >the same name since dev->bus is not populated to cpu_sysbus on >purpose > > Signed-off-by: Sudeep Holla > Cc: Greg Kroah-Hartman > Cc: David Herrmann > Cc: Kay Sievers > Tested-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 04/11] drivers: base: support cpu cache information interface to userspace via sysfs
On 09/03/14 10:00, Sudeep Holla wrote: > From: Sudeep Holla > > This patch adds initial support for providing processor cache information > to userspace through sysfs interface. This is based on already existing > implementations(x86, ia64, s390 and powerpc) and hence the interface is > intended to be fully compatible. > > The main purpose of this generic support is to avoid further code > duplication to support new architectures and also to unify all the existing > different implementations. > > This implementation maintains the hierarchy of cache objects which reflects > the system's cache topology. Cache devices are instantiated as needed as > CPUs come online. The cache information is replicated per-cpu even if they are > shared. A per-cpu array of cache information maintained is used mainly for > sysfs-related book keeping. > > It also implements the shared_cpu_map attribute, which is essential for > enabling both kernel and user-space to discover the system's overall cache > topology. > > This patch also add the missing ABI documentation for the cacheinfo sysfs > interface already, which is well defined and widely used. > > Signed-off-by: Sudeep Holla > Cc: Greg Kroah-Hartman > Cc: Stephen Boyd > Cc: linux-...@vger.kernel.org > Cc: linux...@de.ibm.com > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-i...@vger.kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-s...@vger.kernel.org > Cc: x...@kernel.org > Reviewed-by: Stephen Boyd Tested-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 01/11 UPDATE] cpumask: factor out show_cpumap into separate helper function
On 09/04/14 08:46, Sudeep Holla wrote:
> From: Sudeep Holla
>
> Many sysfs *_show function use cpu{list,mask}_scnprintf to copy cpumap
> to the buffer aligned to PAGE_SIZE, append '\n' and '\0' to return null
> terminated buffer with newline.
>
> This patch creates a new helper function cpumap_print_to_pagebuf in
> cpumask.h using newly added bitmap_print_to_pagebuf and consolidates
> most of those sysfs functions using the new helper function.
>
> Signed-off-by: Sudeep Holla
> Suggested-by: Stephen Boyd
> Acked-by: "Rafael J. Wysocki"
> Acked-by: Bjorn Helgaas
> Cc: Greg Kroah-Hartman
> Cc: Peter Zijlstra
> Cc: x...@kernel.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
>
Tested-by: Stephen Boyd
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sep 19
On 09/19/14 14:14, Guenter Roeck wrote: > On Fri, Sep 19, 2014 at 04:58:17PM +1000, Stephen Rothwell wrote: >> Hi all, >> >> Changes since 20140917: >> >> The fsl tree still had its build failure so I used the version from >> next-20140917. >> >> The v4l-dvb tree lost its build failure. >> >> The security tree gained a conflict against the file-locks tree. >> >> Non-merge commits (relative to Linus' tree): 6014 >> 5488 files changed, 217522 insertions(+), 129375 deletions(-) >> >> >> > Guess this is most difficult one. > > mips:nlm_xlp_defconfig: > > warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has > unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) > warning: (SCSI_BNX2X_FCOE && LIBFCOE && TCM_QLA2XXX) selects LIBFC which has > unmet direct dependencies (SCSI_LOWLEVEL && SCSI && SCSI_FC_ATTRS) Yes, I have a patch sitting on my hard drive that makes LIBFCOE and TCM_QLA2XXX and SCSI_BNX2X_FCOE depend on SCSI_FC_ATTRS, but I'm not entirely happy about having to hunt these down (even with the help of kconfig warnings). I'm pretty sure that I can fix these (above and build errors below), but there is still a bunch of nasty kconfig warnings that I don't understand and don't know how to fix: (powerpc ppc64_defconfig) produced these warnings: warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && CANYONLANDS && GLACIER && 440EP && 440EPX && 440GRX && 440GP && 440GX && 460SX && 405GP) selects IBM_EMAC_ZMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && BLUESTONE && CANYONLANDS && GLACIER && EIGER && 440EPX && 440GRX && 440GX && 460SX && 405EX) selects IBM_EMAC_RGMII which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && 440GX && 460EX && 460SX && APM821xx) selects IBM_EMAC_TAH which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) warning: (PPC_CELL_NATIVE && AKEBONO && 440EPX && 440GRX && 440GX && 440SPe && 460EX && 460SX && APM821xx && 405EX) selects IBM_EMAC_EMAC4 which has unmet direct dependencies (NETDEVICES && ETHERNET && NET_VENDOR_IBM) git bisect also points to the SCSI_NETLINK dependency commit for these (unless I did the bisect incorrectly). Does anyone have a clue on these? Thanks. > followed by: > > ERROR: "scsi_is_fc_rport" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "fc_get_event_number" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "skb_trim" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "fc_host_post_event" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "__alloc_skb" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "fc_remote_port_delete" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "kfree_skb" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "fc_block_scsi_eh" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "fc_remote_port_add" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "skb_put" [drivers/scsi/libfc/libfc.ko] undefined! > ERROR: "skb_clone" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "dev_get_by_name" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "register_netdevice_notifier" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "unregister_netdevice_notifier" [drivers/scsi/fcoe/libfcoe.ko] > undefined! > ERROR: "skb_trim" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "__netdev_alloc_skb" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "__pskb_pull_tail" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "skb_queue_purge" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "__ethtool_get_settings" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "skb_push" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "skb_pull" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "init_net" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "skb_queue_tail" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "kfree_skb" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "skb_dequeue" [drivers/scsi/fcoe/libfcoe.ko] undefined! > ERROR: "consume_skb" [drivers/scsi/fcoe/libfcoe.ko] undefined!
Re: [GIT PULL v2] USB changes for v3.18 merge window
On Thu, Sep 18, 2014 at 09:46:11AM -0500, Felipe Balbi wrote: > Hi Greg, > > Here you go. This one should be good to go. Sorry for the last minute > change but it was better to revert those patches than having a broken > v3.17 final. Let me know if you want any changes. > > cheers > > The following changes since commit 9e82bf014195d6f0054982c463575cdce24292be: > > Linux 3.17-rc5 (2014-09-14 17:50:12 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/usb-for-v3.18 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load
Hi, On Fri, Sep 19, 2014 at 3:09 PM, Andy Lutomirski wrote: > On Fri, Sep 19, 2014 at 3:02 PM, Filipe Brandenburger > wrote: >> In case that's useful, I was looking at swapping the vvar page by >> changing the vm_special_mapping to change the pages array between the >> actual vvar page and the zero page and using zap_page_range to force >> the next access to go through a page fault that would remap it. > > That will do it globally, since the vm_special_mapping is global. I > was just thinking of using remap_pfn_range. Sorry if I wasn't clear... That's the exact point of my patch, to make vm_special_mapping local to the task. I started with an approach of keeping a struct vm_special_mapping + a struct page * array per mm_struct. I was also looking at keeping two static vm_special_mapping structs, one with the actual vvar page and the other with the zero page and then swapping vma->vm_private_data to point to the appropriate one. > Give me another day or two to straighten out the vma stuff, although > it shouldn't impact your patches too much. The main effect will be > that you'll be able to rely on mm->context.vdso (renamed to > vvar_vma_start, most likey) being correct. Currently, you should > *not* rely on it, especially if CRIU is involved. Cool! As I said, let me know if you'd like to see some of my incomplete patches or if you'd like me to keep working on them to show you something more complete. Cheers, Filipe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2 V7] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X)
Hi Suravee,
On Thu, Sep 18 2014 at 03:14:46 AM, "suravee.suthikulpa...@amd.com"
wrote:
> From: Suravee Suthikulpanit
>
> ARM GICv2m specification extends GICv2 to support MSI(-X) with
> a new set of register frame. This patch introduces support for
> the non-secure GICv2m register frame. Currently, GICV2m is available
> in certain version of GIC-400.
>
> The patch introduces a new property in ARM gic binding, the v2m subnode.
> It is optional.
>
> Signed-off-by: Suravee Suthikulpanit
> Cc: Mark Rutland
> Cc: Marc Zyngier
> Cc: Jason Cooper
> Cc: Catalin Marinas
> Cc: Will Deacon
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 55
> arch/arm64/Kconfig| 1 +
> drivers/irqchip/Kconfig | 7 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-gic-common.c | 12 +
> drivers/irqchip/irq-gic-common.h | 4 +
> drivers/irqchip/irq-gic-v2m.c | 356
> ++
> drivers/irqchip/irq-gic.c | 82 +++---
> drivers/irqchip/irq-gic.h | 54
> 9 files changed, 542 insertions(+), 30 deletions(-)
> create mode 100644 drivers/irqchip/irq-gic-v2m.c
> create mode 100644 drivers/irqchip/irq-gic.h
>
> diff --git a/Documentation/devicetree/bindings/arm/gic.txt
> b/Documentation/devicetree/bindings/arm/gic.txt
> index c7d2fa1..38b2156 100644
> --- a/Documentation/devicetree/bindings/arm/gic.txt
> +++ b/Documentation/devicetree/bindings/arm/gic.txt
> @@ -96,3 +96,58 @@ Example:
> <0x2c006000 0x2000>;
> interrupts = <1 9 0xf04>;
> };
> +
> +
> +* GICv2m extension for MSI/MSI-x support (Optional)
> +
> +Certain revision of GIC-400 supports MSI/MSI-x via V2M register frame.
> +This is enabled by specifying v2m sub-node.
> +
> +Required properties:
> +
> +- compatible: The value here should be "arm,gic-v2m-frame".
> +
> +- msi-controller: Identifies the node as an MSI controller.
> +
> +- reg : GICv2m MSI interface register base and size
> +
> +Optional properties:
> +
> +- arm,msi-base-spi : Specify base SPI the MSI frame.
> + The SPI base value can be from 32 to 1019.
> +
> +- arm,msi-num-spi : Returns the number of contiguous SPIs assigned
> + to the frame.
> +
> +Note: "arm,msi-base-spi" and "arm,msi-num-spi" are used mainly for
> + providing HW workaround in the case where the MSI_TYPER register
> + is corrupted.
> +
> +Example:
> +
> + interrupt-controller@e1101000 {
> + compatible = "arm,gic-400";
> + #interrupt-cells = <3>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + interrupt-controller;
> + interrupts = <1 8 0xf04>;
> + ranges = <0 0 0 0xe110 0 0x10>;
> + reg = <0x0 0xe111 0 0x01000>,
> + <0x0 0xe112f000 0 0x02000>,
> + <0x0 0xe114 0 0x1>,
> + <0x0 0xe116 0 0x1>;
> + v2m0: v2m@0x8000 {
> + compatible = "arm,gic-v2m-frame";
> + msi-controller;
> + reg = <0x0 0x8 0 0x1000>;
> + };
> +
> +
> +
> + v2mN: v2m@0x9000 {
> + compatible = "arm,gic-v2m-frame";
> + msi-controller;
> + reg = <0x0 0x9 0 0x1000>;
> + };
> + };
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index fd4e81a..83d5556 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -12,6 +12,7 @@ config ARM64
> select ARM_ARCH_TIMER
> select ARM_GIC
> select AUDIT_ARCH_COMPAT_GENERIC
> + select ARM_GIC_V2M
> select ARM_GIC_V3
> select BUILDTIME_EXTABLE_SORT
> select CLONE_BACKWARDS
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index b8632bf..ddb31ee 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -7,6 +7,13 @@ config ARM_GIC
> select IRQ_DOMAIN
> select MULTI_IRQ_HANDLER
>
> +config ARM_GIC_V2M
> + bool
> + select IRQ_DOMAIN
> + select MULTI_IRQ_HANDLER
These two selects are superfluous, as V2M already depend on ARM_GIC,
which selects them already.
> + depends on ARM_GIC
> + depends on PCI && PCI_MSI
> +
> config GIC_NON_BANKED
> bool
>
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 73052ba..3bda951 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_ARCH_SUNXI) += irq-sun4i.o
> obj-$(CONFIG_ARCH_SUNXI) += irq-sunxi-nmi.o
> obj-$(CONFIG_ARCH_SPEAR3XX)+= spear-shirq.o
> obj-$(CONFIG_ARM_GIC)
Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load
On Fri, Sep 19, 2014 at 3:02 PM, Filipe Brandenburger wrote: > Hi Andy, > > On Fri, Sep 19, 2014 at 12:27 PM, Andy Lutomirski wrote: >> I have this (special mapping tracking) 3/4 implemented. I'm planning >> on making it fully functional for 64-bit programs and almost correct >> for 32-bit. (You'll still crash if you have multiple threads, you use >> sysenter, and you remap the vdso, but I think that this is essentially >> unavoidable until someone lets mremap work on multiple vmas at once.) > > In case that's useful, I was looking at swapping the vvar page by > changing the vm_special_mapping to change the pages array between the > actual vvar page and the zero page and using zap_page_range to force > the next access to go through a page fault that would remap it. That will do it globally, since the vm_special_mapping is global. I was just thinking of using remap_pfn_range. > > I didn't have all the details figured out (I was closer to 1/4 of it > implemented) but I didn't see any issues on 32-bit programs. The 32-bit issue comes from mremap. > > Let me know if you'd like to see some of my patches or if you think I > should keep working on them. Give me another day or two to straighten out the vma stuff, although it shouldn't impact your patches too much. The main effect will be that you'll be able to rely on mm->context.vdso (renamed to vvar_vma_start, most likey) being correct. Currently, you should *not* rely on it, especially if CRIU is involved. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load
Hi Andy, On Fri, Sep 19, 2014 at 12:27 PM, Andy Lutomirski wrote: > I have this (special mapping tracking) 3/4 implemented. I'm planning > on making it fully functional for 64-bit programs and almost correct > for 32-bit. (You'll still crash if you have multiple threads, you use > sysenter, and you remap the vdso, but I think that this is essentially > unavoidable until someone lets mremap work on multiple vmas at once.) In case that's useful, I was looking at swapping the vvar page by changing the vm_special_mapping to change the pages array between the actual vvar page and the zero page and using zap_page_range to force the next access to go through a page fault that would remap it. I didn't have all the details figured out (I was closer to 1/4 of it implemented) but I didn't see any issues on 32-bit programs. Let me know if you'd like to see some of my patches or if you think I should keep working on them. Cheers, Filipe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 00/10] Support for creating generic PCI host bridges from DT
On Thu, Sep 18, 2014 at 02:30:15AM +0100, Liviu Dudau wrote: > This is my version 11 of the attempt at adding support for generic PCI host > bridge controllers that make use of device tree information to > configure themselves. It contains minor cleanups compared with v10 to address > the existing comments. > ... > Catalin Marinas (1): > PCI: Introduce generic domain handling for PCI busses. > > Liviu Dudau (9): > Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases. > PCI: Introduce helper functions to deal with PCI I/O ranges. > ARM: Define PCI_IOBASE as the base of virtual PCI IO space. > PCI: OF: Fix the conversion of IO ranges into IO resources. > PCI: Create pci_host_bridge before its associated bus in > pci_create_root_bus. > OF: Introduce helper function for getting PCI domain_nr > OF: PCI: Add support for parsing PCI host bridge resources from DT > PCI: Assign unassigned bus resources in pci_scan_root_bus() > PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources > into CPU space > > arch/arm/include/asm/io.h | 1 + > arch/arm/mach-integrator/pci_v3.c | 23 +++--- > drivers/of/address.c | 146 > drivers/of/of_pci.c | 170 > ++ > drivers/pci/host/pci-tegra.c | 10 ++- > drivers/pci/host/pcie-rcar.c | 21 +++-- > drivers/pci/pci.c | 33 > drivers/pci/probe.c | 46 +++ > include/asm-generic/io.h | 2 +- > include/asm-generic/pgtable.h | 4 + > include/linux/of_address.h| 15 +--- > include/linux/of_pci.h| 18 > include/linux/pci.h | 24 ++ > 13 files changed, 463 insertions(+), 50 deletions(-) I put this on a pci/liviu-generic-v11 branch. I mentioned a couple things in response to the individual patches, so I'm hoping you can send me incremental patches to address them. Then I'll update this branch, rename it, and get it into linux-next. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 0/3] PHY: Fixes for 3.17 -rc cycle
On Wed, Sep 17, 2014 at 09:19:47PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > On Friday 12 September 2014 07:36 PM, Kishon Vijay Abraham I wrote: > > Hi Greg, > > > > here's one more PULL REQUEST for this -rc cycle. It consists of only > > three fixes one in miphy365 PHY driver and the other two in Kconfig. > > > > Please consider merging this in ths -rc cycle. Let me know if I have to > > change something. > > ping on this.. Now pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v11 10/10] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space
On Thu, Sep 18, 2014 at 02:30:25AM +0100, Liviu Dudau wrote:
> Introduce a default implementation for remapping PCI bus I/O resources
> onto the CPU address space. Architectures with special needs may
> provide their own version, but most should be able to use this one.
I see that this is used by Tanmay's APM X-Gene PCIe host controller driver.
Since it's not used in this series, it'd be nice to mention where it *will*
be used.
> Cc: Bjorn Helgaas
> Cc: Arnd Bergmann
> Cc: Rob Herring
> Reviewed-by: Catalin Marinas
> Signed-off-by: Liviu Dudau
> ---
> drivers/pci/pci.c | 33 +
> include/asm-generic/pgtable.h | 4
> include/linux/pci.h | 3 +++
> 3 files changed, 40 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 2c9ac70..654b44c 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2704,6 +2704,39 @@ int pci_request_regions_exclusive(struct pci_dev
> *pdev, const char *res_name)
> }
> EXPORT_SYMBOL(pci_request_regions_exclusive);
>
> +/**
> + * pci_remap_iospace - Remap the memory mapped I/O space
> + * @res: Resource describing the I/O space
> + * @phys_addr: physical address where the range will be mapped.
> + *
> + * Remap the memory mapped I/O space described by the @res
> + * into the CPU physical address space.
This comment doesn't seem quite right. I think the space is already in the
CPU physical address space. ioremap() and friends normally map existing
physical space into the *virtual* address space, i.e., they create mappings
from a virtual address to a physical address.
> Only architectures
> + * that have memory mapped IO defined (and hence PCI_IOBASE)
> + * should call this function.
> + */
> +int __weak pci_remap_iospace(const struct resource *res, phys_addr_t
> phys_addr)
> +{
> + int err = -ENODEV;
> +
> +#ifdef PCI_IOBASE
> + if (!(res->flags & IORESOURCE_IO))
> + return -EINVAL;
> +
> + if (res->end > IO_SPACE_LIMIT)
> + return -EINVAL;
> +
PCI_IOBASE is a virtual address. So PCI_IOBASE + res->start is also a
virtual address (only for IORESOURCE_IO).
Since res->start is normally a *physical* address, I think it would be less
confusing to do something like this:
vaddr = PCI_IOBASE + res->start;
ioremap_page_range(vaddr, vaddr + resource_size(res), ...);
so we have a hint that the first two ioremap_page_range() parameters are
virtual addresses. It's also confusing that it uses "unsigned long" for
the virtual addresses, when we usually use "void *". But that's out of
scope for this patch.
> + err = ioremap_page_range(res->start + (unsigned long)PCI_IOBASE,
> + res->end + 1 + (unsigned long)PCI_IOBASE,
> + phys_addr, pgprot_device(PAGE_KERNEL));
> +#else
> + /* this architecture does not have memory mapped I/O space,
> +so this function should never be called */
> + WARN_ON(1);
> +#endif
> +
> + return err;
> +}
> +
> static void __pci_set_master(struct pci_dev *dev, bool enable)
> {
> u16 old_cmd, cmd;
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 53b2acc..977e545 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -249,6 +249,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
> #define pgprot_writecombine pgprot_noncached
> #endif
>
> +#ifndef pgprot_device
> +#define pgprot_device pgprot_noncached
> +#endif
> +
> /*
> * When walking page tables, get the address of the next boundary,
> * or the end address of the range if that comes earlier. Although no
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index a494e5d..fc8c529 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1100,6 +1100,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus
> *bus,
> resource_size_t),
> void *alignf_data);
>
> +
> +int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
> +
> static inline dma_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
> {
> struct pci_bus_region region;
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: dwc2: add T: line to MAINTAINERS showing Felipe's tree
Starting with v3.18-rc, patches for dwc2 will go through Felipe's tree. Add a T: line to MAINTAINERS to document this. Signed-off-by: Paul Zimmerman --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 809ecd6..bffd59c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2848,6 +2848,7 @@ F:drivers/platform/x86/dell-wmi.c DESIGNWARE USB2 DRD IP DRIVER M: Paul Zimmerman L: linux-...@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git S: Maintained F: drivers/usb/dwc2/ -- 2.1.0.24.g4109c28 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs
On 19.09.14 22:41, Scott Wood wrote: > On Fri, 2014-09-19 at 22:32 +0200, Alexander Graf wrote: >> >> On 19.09.14 22:24, Kim Phillips wrote: >>> On Fri, 19 Sep 2014 14:06:32 -0500 >>> Yoder Stuart-B08248 wrote: >>> >>> +/** >>> + * @briefManagement Complex firmware version information >>> + */ >>> +#define MC_VER_MAJOR 2 >>> +#define MC_VER_MINOR 0 >> >> code should be adjusted to run on all *compatible* versions of h/w, >> not strictly the one set in these defines. > This comment is not precise enough be actionable. > What exactly you want to be changed here? I think the easy thing to do is to convert the exact version check into a ranged version check: have > minimum and maximum versions you support. Or a list of exact versions you > support. Or not check for the > version at all - or only for the major version and guarantee that the > major version indicates backwards > compatibility. >>> >>> yes, this was my point: elsewhere I noticed the code denies to run >>> iff those defines are not matched exactly: that code should change >>> to run as Alex describes. >>> >> As I mentioned in the reply to Alex, I will remove the minor version >> check. > > the code should be able to run on all subsequent versions of the > h/w, even in the major version case. You're right, in the future if there are future major versions we would want this same driver to function on multiple versions of the hardware. But at this point in time we don't know what future evolutions there will be and we need the check to error out for now. >>> >>> why? We have to make the standard assumption that newer versions >>> will be backward compatible, in which case the driver should be left >>> to run. >> >> How much is the interface set in stone? Can we indicate to the MC that >> we want version x of the protocol? Then the MC can tell us whether it's >> compatible or not. > > I don't trust that new versions will be 100% backwards compatible > (though I hope they will be), but do we normally bother making a driver > refuse to run on newer versions? Sure, if we need to explicitly match a > comptible string or PCI ID, the match will be rejected if the driver > doesn't know about it, but if it's a version in a register we usually > only check for known issues with certain versions. If the major number is defined as "this interface is incompatible", it really is on the same lines as a PCI ID or a new compatible string, no? So IMHO having a version check on the major version is reasonable as a sanity check. > The driver will have to be changed in the future to dynamically deal with different versions. We could add a TODO in the driver to note that. >>> >>> "TODO: add support for new h/w versions" is almost universally true >>> for all drivers, we don't need to write that down. >>> >>> Support for new h/w versions with new features should be >>> incrementally added once they're known. >> >> The "version id" is basically the equivalent of the pci device id. We >> don't add wildcards there either for unknown pieces of hardware, so >> limiting to driver to "known good" devices is sane IMHO. > > How would you go about adding a wildcard to a PCI ID even if you wanted > to? Version information on PCI is not separate from device > identification. Yup. Hence you can't expect a new version of e1000 to work with an old driver for example - it will have a new PCI ID. So on most hardware, we do have major version checks through that interface. If you want, the "revision" config space field in PCI could be the equivalent of a minor version number here - drivers still match because the device ID itself still matches. The alternative to the approach taken here would be to have an "mc bridge device" that gets proper device tree compatible versioning. Overall the matching and compatibility decision would then lie in the device tree. Speaking of which, how does Linux find this new bus? I couldn't find anything that describes the device tree bindings, but maybe I just missed them. Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 5/6] rtc: max77686: Use ffs() to calculate tm_wday
Hello Joe, On 09/19/2014 09:52 PM, Joe Perches wrote: > On Fri, 2014-09-19 at 21:27 +0200, Javier Martinez Canillas wrote: >> On 09/19/2014 04:39 PM, Joe Perches wrote: >> > On Fri, 2014-09-19 at 12:26 +0200, Javier Martinez Canillas wrote: >> >> The function max77686_rtc_calculate_wday() is used to >> >> calculate the day of the week to be filled in struct >> >> rtc_time but that function only calculates the number >> >> of bits shifted. So the ffs() function can be used to >> >> find the first bit set instead of a special function. >> > >> > This isn't the same logic. Perhaps you want fls. >> > >> >> Right, the removed function has the same logic than fls() - 1 but the value >> stored in data[RTC_WEEKDAY] is: >> >> data[RTC_WEEKDAY] = 1 << tm->tm_wday; >> >> so for this particular case, it doesn't matter since ffs() == fls() always. > > I didn't look that far. > > I just wanted to show that the logic wasn't the same. > No worries, thanks a lot for your feedback. Probably it would had been good to mention that in the commit message. > Perhaps you can specify that ffs==fls in the changelog. > I won't say I'm thrilled to do a whole re-spin of the series just to change that ;) Specially since I already did too many revisions and this series have been floating around for months but is up to Andrew to decide if is worth it. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: Tree for Sep 19
route lookup functions',
the error is:
drivers/scsi/scsi_transport_fc.c: In function 'fc_host_post_event':
drivers/scsi/scsi_transport_fc.c:543:7: error: 'scsi_nl_sock' undeclared
drivers/scsi/scsi_transport_fc.c: In function 'fc_host_post_vendor_event':
drivers/scsi/scsi_transport_fc.c:611:7: error: 'scsi_nl_sock' undeclared
At commit 'bnx2i/bnx2fc : fix randconfig error in next-20140909' and
'scsi_netlink : Make SCSI_NETLINK dependent on NET instead of selecting NET',
the error is:
drivers/built-in.o: In function `scsi_nl_rcv_msg':
drivers/scsi/scsi_netlink.c:114: undefined reference to `netlink_ack'
drivers/scsi/scsi_netlink.c:116: undefined reference to `skb_pull'
drivers/scsi/scsi_netlink.c:80: undefined reference to `netlink_capable'
drivers/built-in.o: In function `netlink_kernel_create':
include/linux/netlink.h:60: undefined reference to `init_net'
include/linux/netlink.h:60: undefined reference to `init_net'
include/linux/netlink.h:60: undefined reference to `__netlink_kernel_create'
drivers/built-in.o: In function `scsi_netlink_exit':
drivers/scsi/scsi_netlink.c:153: undefined reference to `netlink_kernel_release'
---
Bisect reports commit 5d6be6a5d486 ('scsi_netlink : Make SCSI_NETLINK dependent
on NET instead of selecting NET') as first bad commit.
bisect log:
# bad: [6a10bca9b608df445baa23c3bfafc510d93d425b] Add linux-next specific files
for 20140919
# good: [9e82bf014195d6f0054982c463575cdce24292be] Linux 3.17-rc5
git bisect start 'HEAD' 'v3.17-rc5'
# bad: [fde058e2322b9098251d7cf798cac4327a29c004] Merge remote-tracking branch
'drm/drm-next'
git bisect bad fde058e2322b9098251d7cf798cac4327a29c004
# bad: [8fdb4a28beeda1e6626c43b70cd0575512173c3a] Merge remote-tracking branch
'v4l-dvb/master'
git bisect bad 8fdb4a28beeda1e6626c43b70cd0575512173c3a
# bad: [067cd6bcf6f5be3fd82b7e71cbc27f1e0695d673] Merge remote-tracking branch
'tegra/for-next'
git bisect bad 067cd6bcf6f5be3fd82b7e71cbc27f1e0695d673
# good: [37bd1119d8b2e8bdf4e211e096da6fb84c0af45e] arm-soc: document merges
git bisect good 37bd1119d8b2e8bdf4e211e096da6fb84c0af45e
# bad: [0f50dd028d3b77bd422df1f4609510a8f70c88c0] Merge remote-tracking branch
'ep93xx/ep93xx-for-next'
git bisect bad 0f50dd028d3b77bd422df1f4609510a8f70c88c0
# good: [bcca6923950b0d952dd03855dc6aadc0848d3e22] Merge remote-tracking branch
'sparc/master'
git bisect good bcca6923950b0d952dd03855dc6aadc0848d3e22
# bad: [99f3bddf52a8dc454ade167099a9e6d5b6dcd8f6] Merge remote-tracking branch
'ipsec/master'
git bisect bad 99f3bddf52a8dc454ade167099a9e6d5b6dcd8f6
# good: [a7f8289d1291a8e1b9d4e39c770467d3dac0d382] Merge tag
'linux-can-fixes-for-3.17-20140911' of git://gitorious.org/linux-can/linux-can
git bisect good a7f8289d1291a8e1b9d4e39c770467d3dac0d382
# good: [48c20407f49039d8da155ca00877ec5f057799e6] r8169: fix the default
setting of rx vlan
git bisect good 48c20407f49039d8da155ca00877ec5f057799e6
# good: [d6ce2628f32271c037a8c12e1994c9fba3a4af49] cxgb4: Don't allocate
adapter structure for all PF's
git bisect good d6ce2628f32271c037a8c12e1994c9fba3a4af49
# bad: [f92ee61982d6da15a9e49664ecd6405a15a2ee56] xfrm: Generate blackhole
routes only from route lookup functions
git bisect bad f92ee61982d6da15a9e49664ecd6405a15a2ee56
# bad: [23a3c99201954d8ffe92e599e3c3039985280f1b] bnx2i/bnx2fc : fix randconfig
error in next-20140909
git bisect bad 23a3c99201954d8ffe92e599e3c3039985280f1b
# bad: [5d6be6a5d4864712832822efeb9c2d54e4063949] scsi_netlink : Make
SCSI_NETLINK dependent on NET instead of selecting NET
git bisect bad 5d6be6a5d4864712832822efeb9c2d54e4063949
# first bad commit: [5d6be6a5d4864712832822efeb9c2d54e4063949] scsi_netlink :
Make SCSI_NETLINK dependent on NET instead of selecting NET--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v4 PATCH 1/1] init: fix race between rootfs mount and firmware loading
On Fri, Sep 19, 2014 at 09:44:24PM +0900, Roman Pen wrote: > The thing is that built-in modules are being inited before > rootfs mount. Some of the modules can request firmware loading > from another thread using async 'request_firmware_nowait' call > on inition, so we can catch this kind of race: >rootfs does not exist yet, but we are going to open and load >firmware file requesting it from the kernel thread. > > Solution is simple: before any rootfs access firmware loader > must wait for rootfs mount. Even simpler solution, don't do that :) If your hardware needs firmware this early, and you don't put the firmare into the initrd/initramfs, then it will just be loaded later on, when the root filesystem is needed and the driver asks for it again (your driver is failing "nicely" and allows the firmware to be loaded later, right? If not, that should be fixed...) Or, build the firmware into the kernel, I think we still have that option for some drivers that really wanted/needed this. What has changed recently that requires this type of patch? What is wrong with the above solutions? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v13 net-next 07/11] bpf: verifier (add ability to receive verification log)
From: Alexei Starovoitov Date: Fri, 19 Sep 2014 14:04:50 -0700 > the 'changes requested' status means that you want me to > address this forward compatibility now instead of later? I want you to address this now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs
> -Original Message- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Friday, September 19, 2014 3:33 PM > To: Phillips Kim-R1AAHA; Yoder Stuart-B08248 > Cc: Rivera Jose-B46482; ; ; > ; Wood > Scott-B07421; > Subject: Re: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs > > > > On 19.09.14 22:24, Kim Phillips wrote: > > On Fri, 19 Sep 2014 14:06:32 -0500 > > Yoder Stuart-B08248 wrote: > > > > +/** > > + * @briefManagement Complex firmware version information > > + */ > > +#define MC_VER_MAJOR 2 > > +#define MC_VER_MINOR 0 > > code should be adjusted to run on all *compatible* versions of h/w, > not strictly the one set in these defines. > >>> This comment is not precise enough be actionable. > >>> What exactly you want to be changed here? > >> > >> I think the easy thing to do is to convert the exact version check > >> into a ranged version check: have > >>> minimum and maximum versions you support. Or a list of exact versions you > >>> support. Or not check for the > >>> version at all - or only for the major version and guarantee that the > >>> major version indicates backwards > >>> compatibility. > > > > yes, this was my point: elsewhere I noticed the code denies to run > > iff those defines are not matched exactly: that code should change > > to run as Alex describes. > > > As I mentioned in the reply to Alex, I will remove the minor version > check. > >>> > >>> the code should be able to run on all subsequent versions of the > >>> h/w, even in the major version case. > >> > >> You're right, in the future if there are future major versions we would > >> want this > >> same driver to function on multiple versions of the hardware. But at this > >> point in time we don't know what future evolutions there will be and we > >> need the check to error out for now. > > > > why? We have to make the standard assumption that newer versions > > will be backward compatible, in which case the driver should be left > > to run. > > How much is the interface set in stone? It is set in stone, in that a particular version has an specific set of commands. > Can we indicate to the MC that > we want version x of the protocol? Then the MC can tell us whether it's > compatible or not. No, it's not that clever. For the DPRC object there is a set of commands with a binary interface. The major/minor version number tell us what version of the hw object we are dealing with...what commands are there, what version of the binary interface is there. Stuart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/6] mm: introduce common page state for ballooned memory
On Sat, 13 Sep 2014 12:22:23 +0400 Konstantin Khlebnikov
wrote:
> On Sat, Sep 13, 2014 at 9:42 AM, Andrew Morton
> wrote:
> > On Sat, 13 Sep 2014 09:26:49 +0400 Konstantin Khlebnikov
> > wrote:
> >
> >> >
> >> > Did we really need to put the BalloonPages count into per-zone vmstat,
> >> > global vmstat and /proc/meminfo? Seems a bit overkillish - why so
> >> > important?
> >>
> >> Balloon grabs random pages, their distribution among numa nodes might
> >> be important.
> >> But I know nobody who uses numa-aware vm together with ballooning.
> >>
> >> Probably it's better to drop per-zone vmstat and line from meminfo,
> >> global vmstat counter should be enough.
> >
> > Yes, the less we add the better - we can always add stuff later if
> > there is a demonstrated need.
>
> Ok. (I guess incremental patches are more convenient for you)
> Here is two fixes which remove redundant per-zone counters and adds
> three vmstat counters: "balloon_inflate", "balloon_deflate" and
> "balloon_migrate".
>
> This statistic seems more useful than current state snapshot.
> Size of balloon is just a difference between "inflate" and "deflate".
This is a complete mess.
Your second patch (which is actually the first one) called "fix for
mm-introduce-common-page-state-for-ballooned-memory-fix-v2" is indeed a
fix for
mm-introduce-common-page-state-for-ballooned-memory-fix-v2.patch and
has a changelog.
I eventually worked out that your first patch (whcih is actually the
second one) called "fix for
mm-balloon_compaction-use-common-page-ballooning-v2" assumes that
mm-balloon_compaction-general-cleanup.patch has been applied. Does it
actually fix mm-balloon_compaction-use-common-page-ballooning-v2.patch?
I can't tell, because the "general cleanup" is in the way.
So I'm going to send "fix for
mm-balloon_compaction-use-common-page-ballooning-v2" to Linus
separately, but it has no changelog at all.
Please always write changelogs. Please never send more than one patch
in a single email. Please be *consistent* in filenames, patch titles,
email subjects, etc.
Please send me a changelog for the below patch.
From: Konstantin Khlebnikov
Subject: mm-balloon_compaction-use-common-page-ballooning-v2-fix-1
Signed-off-by: Konstantin Khlebnikov
Signed-off-by: Andrew Morton
---
drivers/virtio/virtio_balloon.c|1 +
include/linux/balloon_compaction.h |2 --
mm/balloon_compaction.c|2 ++
3 files changed, 3 insertions(+), 2 deletions(-)
diff -puN
drivers/virtio/virtio_balloon.c~mm-balloon_compaction-use-common-page-ballooning-v2-fix-1
drivers/virtio/virtio_balloon.c
---
a/drivers/virtio/virtio_balloon.c~mm-balloon_compaction-use-common-page-ballooning-v2-fix-1
+++ a/drivers/virtio/virtio_balloon.c
@@ -395,6 +395,7 @@ static int virtballoon_migratepage(struc
/* balloon's page migration 1st step -- inflate "newpage" */
spin_lock_irqsave(_dev_info->pages_lock, flags);
balloon_page_insert(vb_dev_info, newpage);
+ __count_vm_event(BALLOON_MIGRATE);
vb_dev_info->isolated_pages--;
spin_unlock_irqrestore(_dev_info->pages_lock, flags);
vb->num_pfns = VIRTIO_BALLOON_PAGES_PER_PAGE;
diff -puN
include/linux/balloon_compaction.h~mm-balloon_compaction-use-common-page-ballooning-v2-fix-1
include/linux/balloon_compaction.h
---
a/include/linux/balloon_compaction.h~mm-balloon_compaction-use-common-page-ballooning-v2-fix-1
+++ a/include/linux/balloon_compaction.h
@@ -87,7 +87,6 @@ static inline void
balloon_page_insert(struct balloon_dev_info *b_dev_info, struct page *page)
{
__SetPageBalloon(page);
- inc_zone_page_state(page, NR_BALLOON_PAGES);
set_page_private(page, (unsigned long)b_dev_info);
list_add(>lru, _dev_info->pages);
}
@@ -104,7 +103,6 @@ balloon_page_insert(struct balloon_dev_i
static inline void balloon_page_delete(struct page *page, bool isolated)
{
__ClearPageBalloon(page);
- dec_zone_page_state(page, NR_BALLOON_PAGES);
set_page_private(page, 0);
if (!isolated)
list_del(>lru);
diff -puN
mm/balloon_compaction.c~mm-balloon_compaction-use-common-page-ballooning-v2-fix-1
mm/balloon_compaction.c
---
a/mm/balloon_compaction.c~mm-balloon_compaction-use-common-page-ballooning-v2-fix-1
+++ a/mm/balloon_compaction.c
@@ -36,6 +36,7 @@ struct page *balloon_page_enqueue(struct
BUG_ON(!trylock_page(page));
spin_lock_irqsave(_dev_info->pages_lock, flags);
balloon_page_insert(b_dev_info, page);
+ __count_vm_event(BALLOON_INFLATE);
spin_unlock_irqrestore(_dev_info->pages_lock, flags);
unlock_page(page);
return page;
@@ -67,6 +68,7 @@ struct page *balloon_page_dequeue(struct
if (trylock_page(page)) {
spin_lock_irqsave(_dev_info->pages_lock, flags);
balloon_page_delete(page, false);
+ __count_vm_event(BALLOON_DEFLATE);
RE: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs
> -Original Message- > From: Kim Phillips [mailto:kim.phill...@freescale.com] > Sent: Friday, September 19, 2014 3:25 PM > To: Yoder Stuart-B08248 > Cc: Rivera Jose-B46482; Alexander Graf; ; > ; ker...@vger.kernel.org>; Wood Scott-B07421; > > Subject: Re: [PATCH 1/4] drivers/bus: Added Freescale Management Complex APIs > > On Fri, 19 Sep 2014 14:06:32 -0500 > Yoder Stuart-B08248 wrote: > > > > > > +/** > > > > > + * @briefManagement Complex firmware version information > > > > > + */ > > > > > +#define MC_VER_MAJOR 2 > > > > > +#define MC_VER_MINOR 0 > > > > > > > > code should be adjusted to run on all *compatible* versions of h/w, > > > > not strictly the one set in these defines. > > > > >>> This comment is not precise enough be actionable. > > > > >>> What exactly you want to be changed here? > > > > >> > > > > >> I think the easy thing to do is to convert the exact version check > > > > >> into a ranged version check: have > > > minimum and maximum versions you support. Or a list of exact versions you > > > support. Or not check for the > > > version at all - or only for the major version and guarantee that the > > > major version indicates backwards > > > compatibility. > > > > > > > > > > yes, this was my point: elsewhere I noticed the code denies to run > > > > > iff those defines are not matched exactly: that code should change > > > > > to run as Alex describes. > > > > > > > > > As I mentioned in the reply to Alex, I will remove the minor version > > > > check. > > > > > > the code should be able to run on all subsequent versions of the > > > h/w, even in the major version case. > > > > You're right, in the future if there are future major versions we would > > want this > > same driver to function on multiple versions of the hardware. But at this > > point in time we don't know what future evolutions there will be and we > > need the check to error out for now. > > why? We have to make the standard assumption that newer versions > will be backward compatible, in which case the driver should be left > to run. If future changes are backward compatible then only the minor version changes. That is the explicit definition of the meaning of major/minor version for this device. If the major number changes, then it is not backward compatible and will require driver changes. So this "error out" check is temporary until we reach that future point, where it can be removed and we can hopefully implement dynamic handling of the incompatibility. Stuart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] tpm/tpm_ibmvtpm: Remove unnecessary casts
There is no need to cast from a void pointer to another pointer.
Signed-off-by: Anton Blanchard
---
Index: b/drivers/char/tpm/tpm_ibmvtpm.c
===
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -65,7 +65,7 @@ static struct ibmvtpm_dev *ibmvtpm_get_d
struct tpm_chip *chip = dev_get_drvdata(dev);
BUG_ON(!chip);
- return (struct ibmvtpm_dev *)TPM_VPRIV(chip);
+ return TPM_VPRIV(chip);
}
/**
@@ -83,7 +83,7 @@ static int tpm_ibmvtpm_recv(struct tpm_c
u16 len;
int sig;
- ibmvtpm = (struct ibmvtpm_dev *)TPM_VPRIV(chip);
+ ibmvtpm = TPM_VPRIV(chip);
if (!ibmvtpm->rtce_buf) {
dev_err(ibmvtpm->dev, "ibmvtpm device is not ready\n");
@@ -127,7 +127,7 @@ static int tpm_ibmvtpm_send(struct tpm_c
u64 *word = (u64 *)
int rc;
- ibmvtpm = (struct ibmvtpm_dev *)TPM_VPRIV(chip);
+ ibmvtpm = TPM_VPRIV(chip);
if (!ibmvtpm->rtce_buf) {
dev_err(ibmvtpm->dev, "ibmvtpm device is not ready\n");
@@ -521,7 +521,7 @@ static void ibmvtpm_crq_process(struct i
**/
static irqreturn_t ibmvtpm_interrupt(int irq, void *vtpm_instance)
{
- struct ibmvtpm_dev *ibmvtpm = (struct ibmvtpm_dev *) vtpm_instance;
+ struct ibmvtpm_dev *ibmvtpm = vtpm_instance;
struct ibmvtpm_crq *crq;
/* while loop is needed for initial setup (get version and
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] tpm/tpm_ibmvtpm: Fail in ibmvtpm_get_data if driver_data is bad
I'm looking at an oops in tpm_ibmvtpm_get_desired_dma:
28: 00 00 20 39 li r9,0
2c: 10 00 01 e8 ld r0,16(r1)
30: 28 00 69 80 lwz r3,40(r9)
We set r9 to 0 then load r9+40. The problem is actually in
ibmvtpm_get_data, it can return NULL but the rest of the driver
never expects it.
Add a BUG_ON in ibmvtpm_get_data. We still need to identify the root
cause but at least this makes it obvious what went wrong.
Cc: sta...@vger.kernel.org
Signed-off-by: Anton Blanchard
---
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index af74c57..0d1eeba 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -63,9 +63,9 @@ static int ibmvtpm_send_crq(struct vio_dev *vdev, u64 w1, u64
w2)
static struct ibmvtpm_dev *ibmvtpm_get_data(const struct device *dev)
{
struct tpm_chip *chip = dev_get_drvdata(dev);
- if (chip)
- return (struct ibmvtpm_dev *)TPM_VPRIV(chip);
- return NULL;
+
+ BUG_ON(!chip);
+ return (struct ibmvtpm_dev *)TPM_VPRIV(chip);
}
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] ARM: edma: unconditionally ack the error interrupt
On 09/18/2014 07:12 PM, Sebastian Andrzej Siewior wrote:
> * Peter Ujfalusi | 2014-09-18 12:42:24 [+0300]:
>
>> My hunch on what could be causing this that we might have unhandled dma event
>> and another comes. This will flag the EDMA_EMR register. Any change in this
>> register will assert error interrupt which can only be cleared by writing to
>> EDMA_EMRC register.
>> The EDMA_EMRC register bits also cleared on edma_start(), edma_stop() and
>> edma_clean_channel() apart from the error interrupt handler.
>> So it is possible that we have missed event on one of the channels but a stop
>> might clear the event so in the interrupt hander we do not see this.
>> I think it would be good to understand what is going on the backround...
>> Can you print out the EDMA_EMCR just before we clear it in the places I have
>> mentioned? We might get better understanding on which stage we clear it and
>> probably we can understand how to fix this properly so we are not going to
>> have missed events on channels.
>
> Okay. For the protocol I applied this patch:
>
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index 160460ae3a49..16598625a4d1 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -422,20 +422,24 @@ static irqreturn_t dma_ccerr_handler(int irq, void
> *data)
> int i;
> int ctlr;
> unsigned int cnt = 0;
> + u32 emr0;
>
> ctlr = irq2ctlr(irq);
> if (ctlr < 0)
> return IRQ_NONE;
>
> dev_dbg(data, "dma_ccerr_handler\n");
> + emr0 = edma_read_array(ctlr, EDMA_EMR, 0);
>
> - if ((edma_read_array(ctlr, EDMA_EMR, 0) == 0) &&
> + if ((emr0 == 0) &&
> (edma_read_array(ctlr, EDMA_EMR, 1) == 0) &&
> (edma_read(ctlr, EDMA_QEMR) == 0) &&
> (edma_read(ctlr, EDMA_CCERR) == 0)) {
> edma_write(ctlr, EDMA_EEVAL, 1);
> + trace_printk("Unhandled\n");
> return IRQ_NONE;
> }
> + trace_printk("emr0: %x\n", emr0);
>
> while (1) {
> int j = -1;
> @@ -1310,6 +1314,9 @@ int edma_start(unsigned channel)
> pr_debug("EDMA: ER%d %08x\n", j,
> edma_shadow0_read_array(ctlr, SH_ER, j));
> /* Clear any pending event or error */
> + trace_printk("j%d mask%x EDMA_EMCR: %x\n",
> + j, mask,
> + edma_read_array(ctlr, EDMA_EMCR, j));
> edma_write_array(ctlr, EDMA_ECR, j, mask);
> edma_write_array(ctlr, EDMA_EMCR, j, mask);
> /* Clear any SER */
> @@ -1347,6 +1354,9 @@ void edma_stop(unsigned channel)
> edma_shadow0_write_array(ctlr, SH_EECR, j, mask);
> edma_shadow0_write_array(ctlr, SH_ECR, j, mask);
> edma_shadow0_write_array(ctlr, SH_SECR, j, mask);
> + trace_printk("j%d mask%x EDMA_EMCR: %x\n",
> + j, mask,
> + edma_read_array(ctlr, EDMA_EMCR, j));
> edma_write_array(ctlr, EDMA_EMCR, j, mask);
>
> pr_debug("EDMA: EER%d %08x\n", j,
> @@ -1387,6 +1397,9 @@ void edma_clean_channel(unsigned channel)
> edma_read_array(ctlr, EDMA_EMR, j));
> edma_shadow0_write_array(ctlr, SH_ECR, j, mask);
> /* Clear the corresponding EMR bits */
> + trace_printk("j%d mask%x EDMA_EMCR: %x\n",
> + j, mask,
> + edma_read_array(ctlr, EDMA_EMCR, j));
> edma_write_array(ctlr, EDMA_EMCR, j, mask);
> /* Clear any SER */
> edma_shadow0_write_array(ctlr, SH_SECR, j, mask);
>
> --
>
> and the result is something like this:
>
>-0 [000] dnh. 303.356403: edma_start: j0 mask800
> EDMA_EMCR: 0
>-0 [000] d.h. 303.396721: edma_stop: j0 mask800
> EDMA_EMCR: 0
>-0 [000] dnh. 303.557103: edma_start: j0 mask800
> EDMA_EMCR: 0
>-0 [000] dnh. 303.557129: edma_stop: j0 mask400
> EDMA_EMCR: 0
>-0 [000] dnH. 303.557142: dma_ccerr_handler: Unhandled
> less-2612 [000] d... 303.557237: edma_start: j0 mask400
> EDMA_EMCR: 0
> less-2612 [000] d.h. 303.562491: edma_stop: j0 mask400
> EDMA_EMCR: 0
> less-2612 [000] d... 303.564475: edma_start: j0 mask400
> EDMA_EMCR: 0
>
> The full trace is at [0]. I haven't found a single entry where EDMA_EMCR
> was != 0 at those spots. *If* there is a edma_stop() before the
> interrupt then the interrupt remains unhandled. If there is a
> edma_start() with mask 800 then we have dma_ccerr_handler() with a
> mask of 400.
mask 800 means URXEVT0 (UART0 rx), 400 is UTXEVT0 (UART0 tx) events.
But it is clear that my theory was not even close to what's going on.
Do you have some tool which can be used to reproduce this issue?
[patch v2] mm: memcontrol: convert reclaim iterator to simple css refcounting
Eek, sent a stale version of this. Here is the right one:
---
From: Johannes Weiner
Date: Fri, 19 Sep 2014 12:39:18 -0400
Subject: [patch v2] mm: memcontrol: convert reclaim iterator to simple css
refcounting
The memcg reclaim iterators use a complicated weak reference scheme to
prevent pinning cgroups indefinitely in the absence of memory pressure.
However, during the ongoing cgroup core rework, css lifetime has been
decoupled such that a pinned css no longer interferes with removal of
the user-visible cgroup, and all this complexity is now unnecessary.
Signed-off-by: Johannes Weiner
---
mm/memcontrol.c | 201 ++--
1 file changed, 34 insertions(+), 167 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index dfd3b15a57e8..154161bb7d4c 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -253,18 +253,6 @@ struct mem_cgroup_stat_cpu {
unsigned long targets[MEM_CGROUP_NTARGETS];
};
-struct mem_cgroup_reclaim_iter {
- /*
-* last scanned hierarchy member. Valid only if last_dead_count
-* matches memcg->dead_count of the hierarchy root group.
-*/
- struct mem_cgroup *last_visited;
- int last_dead_count;
-
- /* scan generation, increased every round-trip */
- unsigned int generation;
-};
-
/*
* per-zone information in memory controller.
*/
@@ -272,7 +260,7 @@ struct mem_cgroup_per_zone {
struct lruvec lruvec;
unsigned long lru_size[NR_LRU_LISTS];
- struct mem_cgroup_reclaim_iter reclaim_iter[DEF_PRIORITY + 1];
+ struct mem_cgroup *reclaim_iter[DEF_PRIORITY + 1];
struct rb_node tree_node; /* RB tree node */
unsigned long usage_in_excess;/* Set to the value by which */
@@ -1174,111 +1162,6 @@ static struct mem_cgroup *get_mem_cgroup_from_mm(struct
mm_struct *mm)
return memcg;
}
-/*
- * Returns a next (in a pre-order walk) alive memcg (with elevated css
- * ref. count) or NULL if the whole root's subtree has been visited.
- *
- * helper function to be used by mem_cgroup_iter
- */
-static struct mem_cgroup *__mem_cgroup_iter_next(struct mem_cgroup *root,
- struct mem_cgroup *last_visited)
-{
- struct cgroup_subsys_state *prev_css, *next_css;
-
- prev_css = last_visited ? _visited->css : NULL;
-skip_node:
- next_css = css_next_descendant_pre(prev_css, >css);
-
- /*
-* Even if we found a group we have to make sure it is
-* alive. css && !memcg means that the groups should be
-* skipped and we should continue the tree walk.
-* last_visited css is safe to use because it is
-* protected by css_get and the tree walk is rcu safe.
-*
-* We do not take a reference on the root of the tree walk
-* because we might race with the root removal when it would
-* be the only node in the iterated hierarchy and mem_cgroup_iter
-* would end up in an endless loop because it expects that at
-* least one valid node will be returned. Root cannot disappear
-* because caller of the iterator should hold it already so
-* skipping css reference should be safe.
-*/
- if (next_css) {
- if ((next_css == >css) ||
- ((next_css->flags & CSS_ONLINE) &&
-css_tryget_online(next_css)))
- return mem_cgroup_from_css(next_css);
-
- prev_css = next_css;
- goto skip_node;
- }
-
- return NULL;
-}
-
-static void mem_cgroup_iter_invalidate(struct mem_cgroup *root)
-{
- /*
-* When a group in the hierarchy below root is destroyed, the
-* hierarchy iterator can no longer be trusted since it might
-* have pointed to the destroyed group. Invalidate it.
-*/
- atomic_inc(>dead_count);
-}
-
-static struct mem_cgroup *
-mem_cgroup_iter_load(struct mem_cgroup_reclaim_iter *iter,
-struct mem_cgroup *root,
-int *sequence)
-{
- struct mem_cgroup *position = NULL;
- /*
-* A cgroup destruction happens in two stages: offlining and
-* release. They are separated by a RCU grace period.
-*
-* If the iterator is valid, we may still race with an
-* offlining. The RCU lock ensures the object won't be
-* released, tryget will fail if we lost the race.
-*/
- *sequence = atomic_read(>dead_count);
- if (iter->last_dead_count == *sequence) {
- smp_rmb();
- position = iter->last_visited;
-
- /*
-* We cannot take a reference to root because we might race
-* with root removal and returning NULL would end up in
-* an endless loop on the iterator user level when root
-* would be returned all the time.
-
Re: [PATCH] x86/vdso: Add prctl to set per-process VDSO load
On Fri, Sep 19, 2014 at 12:27 PM, Andy Lutomirski wrote: > On Wed, Sep 17, 2014 at 7:28 AM, Andy Lutomirski wrote: >> On Sep 17, 2014 1:46 AM, "H. Peter Anvin" wrote: >>> >>> On 09/16/2014 11:21 PM, Filipe Brandenburger wrote: >>> > Hi Andy, >>> > >>> > On Tue, Sep 16, 2014 at 10:00 PM, Andy Lutomirski >>> > wrote: >>> >> I think that the patch should instead tweak the vvar mapping to tell >>> >> the vdso not to use rdtsc. It should be based on this: >>> > >>> > I've been working on this approach which extends the vvar from 2 to 3 >>> > pages. The third page would initially be mapped to a zero page but >>> > then through a prctl a task could replace it with a real page that >>> > could then be inherited through fork and exec. >>> > >>> > That would make it possible to have per-task vvar contents. >>> > >>> > We could use some of those values as flags to indicate whether vdso >>> > routines may use RDTSC or not. >>> > >>> > In the future, we're planning to also use that to store clock offsets >>> > so that we can ensure CLOCK_MONOTONIC works after CRIU migration >>> > without having to turn off the VDSO or have to always fallback to full >>> > syscalls on every case. >>> > >>> > Do you think that would be a reasonable way to accomplish that? >>> > >>> >>> Why would we need/want per process vvar contents? It seems better to >>> have the code swapped out. >> >> That seems messier from a build perspective. Also, if we ever want to >> switch this dynamically, swapping out data is much easier than >> swapping out code. I think we should be able to replace the vvar page >> with the zero page, though. >> >> One tricky bit: currently we can only easily do this on exec, but we >> should be able to do it immediately if we start tracking mremap of the >> vdso. Should we make that a prerequisite? I don't really want this >> to end up being permanently weird. > > I have this (special mapping tracking) 3/4 implemented. I'm planning > on making it fully functional for 64-bit programs and almost correct > for 32-bit. (You'll still crash if you have multiple threads, you use > sysenter, and you remap the vdso, but I think that this is essentially > unavoidable until someone lets mremap work on multiple vmas at once.) > Thanks! I look forward to seeing the result. I have some per-process clock offset patches that currently work only when the vDSO is disabled. It sounds like your patches will provide a clean solution to deal with that issue. I'll try to rebase my work on top of your changes when they're ready. We've also got some patches to apply an offset to the TSC that could benefit from your changes, but I guess there's not much appetite for merging them. That's fine with me. I don't see any need for that feature until we have a few examples of applications that could be broken by TSC changes during migration. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] signal: Silence nested-externs warnings
On Sep 19, 2014, at 2:21 PM, Josh Triplett wrote:
> On Fri, Sep 19, 2014 at 07:20:30PM +0200, Oleg Nesterov wrote:
>> On 09/19, Richard Weinberger wrote:
>>>
>>> Am 19.09.2014 17:37, schrieb Jeff Kirsher:
See patch 1 of the series.
>>>
>>> I was not CC'ed...
>>
>> Me too, and thus I don't understand this patch.
>>
>> But I have to admit it looks a bit ugly to me anyway.
>> Can't we simply kill _NSIG_WORDS_is_unsupported_size ?
>
> This looks quite preferable. Can you post that with a commit message
> and signoff? Also, the indentation on the second of the three BUILD_BUG
> calls has some spaces in it, which it shouldn't. With those fixed:
> Reviewed-by: Josh Triplett
I haven't tried this patch myself yet, but assuming that it works, it is a far
better way to go.
>> diff --git a/include/linux/signal.h b/include/linux/signal.h
>> index 750196f..679c9b4 100644
>> --- a/include/linux/signal.h
>> +++ b/include/linux/signal.h
>> @@ -67,7 +67,6 @@ static inline int sigismember(sigset_t *set, int _sig)
>>
>> static inline int sigisemptyset(sigset_t *set)
>> {
>> -extern void _NSIG_WORDS_is_unsupported_size(void);
>> switch (_NSIG_WORDS) {
>> case 4:
>> return (set->sig[3] | set->sig[2] |
>> @@ -77,7 +76,7 @@ static inline int sigisemptyset(sigset_t *set)
>> case 1:
>> return set->sig[0] == 0;
>> default:
>> -_NSIG_WORDS_is_unsupported_size();
>> +BUILD_BUG();
>> return 0;
>> }
>> }
>> @@ -90,7 +89,6 @@ static inline int sigisemptyset(sigset_t *set)
>> #define _SIG_SET_BINOP(name, op) \
>> static inline void name(sigset_t *r, const sigset_t *a, const sigset_t *b) \
>> {\
>> -extern void _NSIG_WORDS_is_unsupported_size(void); \
>> unsigned long a0, a1, a2, a3, b0, b1, b2, b3; \
>> \
>> switch (_NSIG_WORDS) { \
>> @@ -107,7 +105,7 @@ static inline void name(sigset_t *r, const sigset_t *a,
>> const sigset_t *b) \
>> r->sig[0] = op(a0, b0); \
>> break; \
>> default:\
>> -_NSIG_WORDS_is_unsupported_size(); \
>> +BUILD_BUG();\
>> } \
>> }
>>
>> @@ -128,8 +126,6 @@ _SIG_SET_BINOP(sigandnsets, _sig_andn)
>> #define _SIG_SET_OP(name, op)
>> \
>> static inline void name(sigset_t *set)
>> \
>> {\
>> -extern void _NSIG_WORDS_is_unsupported_size(void); \
>> -\
>> switch (_NSIG_WORDS) { \
>> case 4: set->sig[3] = op(set->sig[3]); \
>> set->sig[2] = op(set->sig[2]); \
>> @@ -137,7 +133,7 @@ static inline void name(sigset_t *set)
>> \
>> case 1: set->sig[0] = op(set->sig[0]); \
>> break; \
>> default:\
>> -_NSIG_WORDS_is_unsupported_size(); \
>> +BUILD_BUG();\
>> } \
>> }
--
Mark Rustad, Networking Division, Intel Corporation
signature.asc
Description: Message signed with OpenPGP using GPGMail
