Re: [PATCH v3 32/51] resources: Split out __allocate_resource()

[Yinghai Lu]

On Mon, Aug 17, 2015 at 9:14 PM, Bjorn Helgaas  wrote:
> On Mon, Jul 27, 2015 at 04:29:50PM -0700, Yinghai Lu wrote:
>> It will not hold lock, so we could use it in other functions that
>> hold the resource lock already.
>
> What's the benefit of this patch?  Does it fix something?  Does it add some
> functionality we need?

will use it in following patch.
--
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 2/4] ASoC: rockchip: Add rockchip SPDIF transceiver driver

[Sjoerd Simons]

Hey Heiko,

Thanks for the comments, i'm hoping to address them and Marks comments
in a next patch series next week.

On Tue, 2015-08-18 at 20:25 +0200, Heiko Stuebner wrote:

> > +
> > + spdif->hclk = devm_clk_get(&pdev->dev, "spdif_hclk");

> I guess this could be named just "hclk" - as it is the identifier 
> local to the spdif-ip. (Of course in the binding too)

I'm entirely happy to change that, just wanted to note that the reason
i used spdif_hclk and spidf_clk is for consistency with the rockchip
-i2s binding which uses i2s_hclk ans i2s_mclk. 

However i guess we could update the i2s binding at some poit as well to
follow similar names (with fallbacks to the old one). In general a lot
of the comments yourself and Mark have given actually apply to the
rockchip-i2s code as well so there is some cleanup to do there :)

-- 
Sjoerd Simons
Collabora Ltd.
--
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] x86, ACPI, irq: Add a quirk to override SCI polarity for HyperV

[Jiang Liu]

On 2015/8/19 14:45, Rafael J. Wysocki wrote:
> Hi,
> 
> On Wed, Aug 19, 2015 at 8:26 AM, Jiang Liu  wrote:
>> On 2015/8/19 14:04, Rafael J. Wysocki wrote:
>>> Hi,
>>>
>>> On Wed, Aug 19, 2015 at 7:53 AM, Jiang Liu  
>>> wrote:
 Nick Meier reported a regression with HyperV that "
   After rebooting the VM, the following messages are logged in syslog
   when trying to load the tulip driver:
 tulip: Linux Tulip drivers version 1.1.15 (Feb 27, 2007)
 tulip: :00:0a.0: PCI INT A: failed to register GSI
 tulip: Cannot enable tulip board #0, aborting
 tulip: probe of :00:0a.0 failed with error -16
   Errors occur in 3.19.0 kernel
   Works in 3.17 kernel.
 "

 According to the ACPI dump file posted by Nick at
 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072

 The ACPI MADT table includes an interrupt source overridden entry for
 ACPI SCI:
 [236h 0566  1]Subtable Type : 02 >>> Override>
 [237h 0567  1]   Length : 0A
 [238h 0568  1]  Bus : 00
 [239h 0569  1]   Source : 09
 [23Ah 0570  4]Interrupt : 0009
 [23Eh 0574  2]Flags (decoded below) : 000D
Polarity : 1
Trigger Mode : 3

 And in DSDT table, we have _PRT method to define PCI interrupts, which
 eventually goes to:
 Name (PRSA, ResourceTemplate ()
 {
 IRQ (Level, ActiveLow, Shared, )
 {3,4,5,7,9,10,11,12,14,15}
 })
 Name (PRSB, ResourceTemplate ()
 {
 IRQ (Level, ActiveLow, Shared, )
 {3,4,5,7,9,10,11,12,14,15}
 })
 Name (PRSC, ResourceTemplate ()
 {
 IRQ (Level, ActiveLow, Shared, )
 {3,4,5,7,9,10,11,12,14,15}
 })
 Name (PRSD, ResourceTemplate ()
 {
 IRQ (Level, ActiveLow, Shared, )
 {3,4,5,7,9,10,11,12,14,15}
 })

 According to the MADT and DSDT tables above, IRQ 9 may be used for:
 1) ACPI SCI in level, high mode
 2) PCI legacy IRQ in level, low mode
 So there's a possible conflict in polarity setting for IRQ 9.

 Prior to commit cd68f6bd53cf ("x86, irq, acpi: Get rid of special
 handling of GSI for ACPI SCI"), ACPI SCI is handled specially and
 there's no check for conflicts between ACPI SCI and PCI legagy IRQ.
 And it seems that the HyperV hypervisor doesn't make use of the
 polarity configuration in IOAPIC entry, so it just works.
>>>
>>> That likely means the previous behavior was the same as (or at least
>>> analogous to) what happens on Windows which is what the firmware has
>>> been tested against and that's why the bug in it has not been caught.
>>> That in turn indicates that there may be more systems having this kind
>>> of problems, possibly from other vendors too, so I'm wondering if we
>>> can do something more generic than using a quirk here?
>> Hi Rafael,
>> Good question. I was thought only virtual machines may generate
>> such fake ACPI tables with conflicting pin attribute settings. For bare
>> metal systems, I guess BIOS writers should report the correct hardware
>> configurations, otherwise wrong pin attributes may cause hardware
>> malfunction.
>> If that's not the case, we may try to revert cd68f6bd53cf
> 
> Well, the regression at hand has just shown that the assertion in the
> changelog of that commit ("no need for for special treatment for GSI
> used by ACPI SCI") does not really hold.  So, if the only motivation
> for it was to get rid of one extra check in mp_unregister_gsi()
> (mp_register_gsi() still needs to check if it is dealing with the SCI
> anyway), I'd vote for reverting it.
Hi Rafael,
The motivation is to treat SCI as normal IOAPIC interrupt so
we could enforce stricter pin attribute checking. Now it does reveal
flaws in ACPI BIOS implementations, but we ran into trouble about how to
handle those flaws:(
Thanks!
Gerry
ACPI bios with flaws:(
> 
> Thanks,
> Rafael
> 
--
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] x86 fixes

[Ingo Molnar]

* Ingo Molnar  wrote:

> 
> * H. Peter Anvin  wrote:
> 
> > On 08/17/2015 10:17 AM, Linus Torvalds wrote:
> > > On Mon, Aug 17, 2015 at 9:58 AM, H. Peter Anvin  wrote:
> > >>
> > >> That is not true.  It *does* work, and I have tested it fairly recently.
> > > 
> > > Ok, so it's not too badly broken. Good.
> > > 
> > > Also, while it's been a long time since we needed FPU emulation on the
> > > i486sx, I don't recall the details of any of the (much more modern)
> > > IoT small cores. I *think* the base platforms are all at a Pentium
> > > level (ie not just FPU, but MMX), but maybe there's some reason to
> > > keep FP emulation alive for some platforms.
> > > 
> > 
> > I just went back and looked at my records... I can guarantee that it
> > worked as of 743aa456c1834f76982af44e8b71d1a0b2a82e21.
> 
> So I went and built 743aa456c1834f76 with ARCH=i386 defconfig 
> +MATH_EMULATION=y 
> and booted it on real hardware with and without 'no387':
> 
>   - 743aa456c1834f76: boots fine to a generic distro
>   - 743aa456c1834f76 + no387: early crash

Ah, so I was able to make math-emu work with the 'no387 nofxsr' boot options.

It turns out that the crash happens due 'no387' not turning off all modern FPU 
features in cpufeatures, which confuses the FPU code. (This is a far less 
severe 
bug than math emu not working at all.)

I get some instances of:

   /etc/rc3.d/S99local: line 26:  1626 Illegal instruction 

due to user-space presuming modern FPU capabilities:

  Program received signal SIGILL, Illegal instruction.  


  0xb76be371 in RAND_SSLeay () from /lib/libcrypto.so.6

  0xb76be371 :  fucomip %st(1),%st

FUCOMPIP is a P6+ FPU instruction.

but otherwise it boots up to a shell prompt.

So I take back my claim, math-emu works. If math-emu grew support for some P6 
era 
FPU instructions it might even boot up generic distros without too much trouble.

Thanks,

Ingo
--
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 v3 1/5] sched: add two functions adjusting cfs_rq's load when att(det)aching a se

[byungchul . park]

From: Byungchul Park 

this patch introduces two functions adjusting cfs_rq's average load when
att(det)aching a se to(from) the cfs_rq, and let them use these functions.

Signed-off-by: Byungchul Park 
---
 kernel/sched/fair.c |   58 +++
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4d5f97b..7475a40 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2709,6 +2709,31 @@ static inline void update_load_avg(struct sched_entity 
*se, int update_tg)
update_tg_load_avg(cfs_rq, 0);
 }
 
+static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
+{
+   se->avg.last_update_time = cfs_rq->avg.last_update_time;
+   cfs_rq->avg.load_avg += se->avg.load_avg;
+   cfs_rq->avg.load_sum += se->avg.load_sum;
+   cfs_rq->avg.util_avg += se->avg.util_avg;
+   cfs_rq->avg.util_sum += se->avg.util_sum;
+}
+
+static void detach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
+{
+   __update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq_of(cfs_rq)),
+   &se->avg, se->on_rq * scale_load_down(se->load.weight),
+   cfs_rq->curr == se, NULL);
+
+   cfs_rq->avg.load_avg =
+   max_t(long, cfs_rq->avg.load_avg - se->avg.load_avg, 0);
+   cfs_rq->avg.load_sum =
+   max_t(s64, cfs_rq->avg.load_sum - se->avg.load_sum, 0);
+   cfs_rq->avg.util_avg =
+   max_t(long, cfs_rq->avg.util_avg - se->avg.util_avg, 0);
+   cfs_rq->avg.util_sum =
+   max_t(s32, cfs_rq->avg.util_sum - se->avg.util_sum, 0);
+}
+
 /* Add the load generated by se into cfs_rq's load average */
 static inline void
 enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity *se)
@@ -2717,27 +2742,20 @@ enqueue_entity_load_avg(struct cfs_rq *cfs_rq, struct 
sched_entity *se)
u64 now = cfs_rq_clock_task(cfs_rq);
int migrated = 0, decayed;
 
-   if (sa->last_update_time == 0) {
-   sa->last_update_time = now;
+   if (sa->last_update_time == 0)
migrated = 1;
-   }
-   else {
+   else
__update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa,
se->on_rq * scale_load_down(se->load.weight),
cfs_rq->curr == se, NULL);
-   }
 
decayed = update_cfs_rq_load_avg(now, cfs_rq);
 
cfs_rq->runnable_load_avg += sa->load_avg;
cfs_rq->runnable_load_sum += sa->load_sum;
 
-   if (migrated) {
-   cfs_rq->avg.load_avg += sa->load_avg;
-   cfs_rq->avg.load_sum += sa->load_sum;
-   cfs_rq->avg.util_avg += sa->util_avg;
-   cfs_rq->avg.util_sum += sa->util_sum;
-   }
+   if (migrated)
+   attach_entity_load_avg(cfs_rq, se);
 
if (decayed || migrated)
update_tg_load_avg(cfs_rq, 0);
@@ -7911,17 +7929,7 @@ static void switched_from_fair(struct rq *rq, struct 
task_struct *p)
 
 #ifdef CONFIG_SMP
/* Catch up with the cfs_rq and remove our load when we leave */
-   __update_load_avg(cfs_rq->avg.last_update_time, cpu_of(rq), &se->avg,
-   se->on_rq * scale_load_down(se->load.weight), cfs_rq->curr == 
se, NULL);
-
-   cfs_rq->avg.load_avg =
-   max_t(long, cfs_rq->avg.load_avg - se->avg.load_avg, 0);
-   cfs_rq->avg.load_sum =
-   max_t(s64, cfs_rq->avg.load_sum - se->avg.load_sum, 0);
-   cfs_rq->avg.util_avg =
-   max_t(long, cfs_rq->avg.util_avg - se->avg.util_avg, 0);
-   cfs_rq->avg.util_sum =
-   max_t(s32, cfs_rq->avg.util_sum - se->avg.util_sum, 0);
+   detach_entity_load_avg(cfs_rq, se);
 #endif
 }
 
@@ -8042,11 +8050,7 @@ static void task_move_group_fair(struct task_struct *p, 
int queued)
 
 #ifdef CONFIG_SMP
/* Virtually synchronize task with its new cfs_rq */
-   p->se.avg.last_update_time = cfs_rq->avg.last_update_time;
-   cfs_rq->avg.load_avg += p->se.avg.load_avg;
-   cfs_rq->avg.load_sum += p->se.avg.load_sum;
-   cfs_rq->avg.util_avg += p->se.avg.util_avg;
-   cfs_rq->avg.util_sum += p->se.avg.util_sum;
+   attach_entity_load_avg(cfs_rq, se);
 #endif
}
 }
-- 
1.7.9.5

--
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 v3 5/5] sched: add two functions for att(det)aching a task to(from) a cfs_rq

[byungchul . park]

From: Byungchul Park 

this patch introduces two functions for adjusting a task's vruntime
and the target cfs_rq's average load so that redundancy code doing
same things can be simplified. and it provides better readability.

switched_from_fair, switched_to_fair and task_move_group_fair can
use introduced functions and get simplified.

Signed-off-by: Byungchul Park 
---
 kernel/sched/fair.c |  143 +++
 1 file changed, 63 insertions(+), 80 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3419f6c..242f0d3 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7915,21 +7915,29 @@ prio_changed_fair(struct rq *rq, struct task_struct *p, 
int oldprio)
check_preempt_curr(rq, p, 0);
 }
 
-static void switched_from_fair(struct rq *rq, struct task_struct *p)
+static void detach_task_cfs_rq(struct task_struct *p, int queued)
 {
struct sched_entity *se = &p->se;
struct cfs_rq *cfs_rq = cfs_rq_of(se);
 
/*
-* Ensure the task's vruntime is normalized, so that when it's
-* switched back to the fair class the enqueue_entity(.flags=0) will
-* do the right thing.
+* Ensure the task's vruntime is normalized, so that after attaching
+* back it to a cfs_rq the enqueue_entity() will do the right thing.
 *
 * If it's queued, then the dequeue_entity(.flags=0) will already
 * have normalized the vruntime, if it's !queued, then only when
-* the task is sleeping will it still have non-normalized vruntime.
+* the task is sleeping it still has a non-normalized vruntime.
+*
+* When !queued, vruntime of the task has usually NOT been normalized.
+* But there are some cases where it has already been normalized:
+*
+* - Moving a forked child which is waiting for being woken up by
+*   wake_up_new_task().
+* - Moving a task which has been woken up by try_to_wake_up() and
+*   waiting for actually being woken up by sched_ttwu_pending().
 */
-   if (!task_on_rq_queued(p) && p->state != TASK_RUNNING) {
+   if (!queued && p->state != TASK_RUNNING &&
+   se->sum_exec_runtime && p->state != TASK_WAKING) {
/*
 * Fix up our vruntime so that the current sleep doesn't
 * cause 'unlimited' sleep bonus.
@@ -7944,12 +7952,10 @@ static void switched_from_fair(struct rq *rq, struct 
task_struct *p)
 #endif
 }
 
-/*
- * We switched to the sched_fair class.
- */
-static void switched_to_fair(struct rq *rq, struct task_struct *p)
+static void attach_task_cfs_rq(struct task_struct *p, int queued)
 {
struct sched_entity *se = &p->se;
+   struct cfs_rq *cfs_rq = cfs_rq_of(se);
 
 #ifdef CONFIG_FAIR_GROUP_SCHED
/*
@@ -7961,34 +7967,57 @@ static void switched_to_fair(struct rq *rq, struct 
task_struct *p)
 
 #ifdef CONFIG_SMP
/* synchronize task with its cfs_rq */
-   attach_entity_load_avg(cfs_rq_of(&p->se), &p->se);
+   attach_entity_load_avg(cfs_rq, se);
 #endif
 
-   if (!task_on_rq_queued(p)) {
+   /*
+* Ensure the task has a non-normalized vruntime when attaching it
+* to a cfs_rq, so that enqueue_entity() at wake-up time will do
+* the right thing.
+*
+* If it's queued, then the enqueue_entity(.flags=0) makes the task
+* has non-normalized vruntime, if it's !queued, then it still has
+* a normalized vruntime.
+*
+* When !queued, a task usually should have a non-normalized vruntime
+* after being attached to a cfs_rq. But there are some cases where
+* we should keep it normalized:
+*
+* - Moving a forked child which is waiting for being woken up by
+*   wake_up_new_task().
+* - Moving a task which has been woken up by try_to_wake_up() and
+*   waiting for actually being woken up by sched_ttwu_pending().
+*/
+   if (!queued && p->state != TASK_RUNNING &&
+   se->sum_exec_runtime && p->state != TASK_WAKING)
+   se->vruntime += cfs_rq->min_vruntime;
+}
+
+static void switched_from_fair(struct rq *rq, struct task_struct *p)
+{
+   detach_task_cfs_rq(p, task_on_rq_queued(p));
+}
 
+/*
+ * We switched to the sched_fair class.
+ */
+static void switched_to_fair(struct rq *rq, struct task_struct *p)
+{
+   int queued = task_on_rq_queued(p);
+
+   attach_task_cfs_rq(p, queued);
+
+   if (queued) {
/*
-* Ensure the task has a non-normalized vruntime when it is 
switched
-* back to the fair class with !queued, so that 
enqueue_entity() at
-* wake-up time will do the right thing.
-*
-* If it's queued, then the enqueue_entity(.flags=0) makes the 
task
-* has non-normalized vruntime, if it's !queued, then it still

[PATCH v3 2/5] sched: make task_move_group_fair adjust cfs_rq's load in case of queued

[byungchul . park]

From: Byungchul Park 

se's average load should be added to new cfs_rq, not only in case of
!queued but also in case of queued.

of course, older code managed cfs_rq's blocked load separately. in that
case, the blocked load was meaningful only in case that the se is in
!queued. but now load tracking code is changed, it is not true. code
adjusting cfs_rq's average load should be changed.

Signed-off-by: Byungchul Park 
---
 kernel/sched/fair.c |   10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7475a40..191d9be 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8044,15 +8044,13 @@ static void task_move_group_fair(struct task_struct *p, 
int queued)
se->vruntime -= cfs_rq_of(se)->min_vruntime;
set_task_rq(p, task_cpu(p));
se->depth = se->parent ? se->parent->depth + 1 : 0;
-   if (!queued) {
-   cfs_rq = cfs_rq_of(se);
+   cfs_rq = cfs_rq_of(se);
+   if (!queued)
se->vruntime += cfs_rq->min_vruntime;
-
 #ifdef CONFIG_SMP
-   /* Virtually synchronize task with its new cfs_rq */
-   attach_entity_load_avg(cfs_rq, se);
+   /* Virtually synchronize task with its new cfs_rq */
+   attach_entity_load_avg(cfs_rq, se);
 #endif
-   }
 }
 
 void free_fair_sched_group(struct task_group *tg)
-- 
1.7.9.5

--
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 v3 3/5] sched: sync a se with prev cfs_rq when changing cgroup

[byungchul . park]

From: Byungchul Park 

current code is wrong with cfs_rq's average load when changing a task's
cfs_rq to another. i tested with "echo pid > cgroup" and found that
e.g. cfs_rq->avg.load_avg became larger and larger whenever changing
cgroup to another again and again. we have to sync se's average load
with both *prev* cfs_rq and next cfs_rq when changing its cgroup.

Signed-off-by: Byungchul Park 
---
 kernel/sched/fair.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 191d9be..1be042a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8040,8 +8040,14 @@ static void task_move_group_fair(struct task_struct *p, 
int queued)
if (!queued && (!se->sum_exec_runtime || p->state == TASK_WAKING))
queued = 1;
 
+   cfs_rq = cfs_rq_of(se);
if (!queued)
-   se->vruntime -= cfs_rq_of(se)->min_vruntime;
+   se->vruntime -= cfs_rq->min_vruntime;
+
+#ifdef CONFIG_SMP
+   /* synchronize task with its prev cfs_rq */
+   detach_entity_load_avg(cfs_rq, se);
+#endif
set_task_rq(p, task_cpu(p));
se->depth = se->parent ? se->parent->depth + 1 : 0;
cfs_rq = cfs_rq_of(se);
-- 
1.7.9.5

--
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] scripts: Extract kernel headers for out of tree modules build

[Daniel Baluta]

scripts/package/builddeb already creates a linux-keader .deb
package, but we need this feature also for non-Debian distros
(e.g. Android or LFS).

Signed-off-by: Daniel Baluta 
---
 Makefile   | 10 +-
 scripts/modules_headers_install.sh | 40 ++
 2 files changed, 49 insertions(+), 1 deletion(-)
 create mode 100755 scripts/modules_headers_install.sh

diff --git a/Makefile b/Makefile
index 35b4c19..839416d 100644
--- a/Makefile
+++ b/Makefile
@@ -1042,6 +1042,7 @@ firmware_install: FORCE
 
 #Default location for installed headers
 export INSTALL_HDR_PATH = $(objtree)/usr
+export INSTALL_MODULES_HDR_PATH = $(objtree)/usr/src
 
 # If we do an all arch process set dst to asm-$(hdr-arch)
 hdr-dst = $(if $(KBUILD_HEADERS), dst=include/asm-$(hdr-arch), dst=include/asm)
@@ -1076,6 +1077,10 @@ headers_check: headers_install
$(Q)$(MAKE) $(hdr-inst)=include/uapi HDRCHECK=1
$(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/asm $(hdr-dst) 
HDRCHECK=1
 
+PHONY += modules_headers_install
+modules_headers_install:
+   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/modules_headers_install.sh
+
 # ---
 # Kernel selftest
 
@@ -1274,7 +1279,10 @@ help:
@echo  '  kernelversion   - Output the version stored in Makefile (use 
with make -s)'
@echo  '  image_name  - Output the image name (use with make -s)'
@echo  '  headers_install - Install sanitised kernel headers to 
INSTALL_HDR_PATH'; \
-echo  '(default: $(INSTALL_HDR_PATH))'; \
+echo  '(default: $(INSTALL_HDR_PATH))';
+   @echo  '  modules_headers_install - Install kernel headers to 
INSTALL_MODULES_HDR_PATH'; \
+echo  'to be used for out of tree modules 
build'; \
+echo  '(default: 
$(INSTALL_MODULES_HDR_PATH))'; \
 echo  ''
@echo  'Static analysers'
@echo  '  checkstack  - Generate a list of stack hogs'
diff --git a/scripts/modules_headers_install.sh 
b/scripts/modules_headers_install.sh
new file mode 100755
index 000..ebced17
--- /dev/null
+++ b/scripts/modules_headers_install.sh
@@ -0,0 +1,40 @@
+#!/bin/sh
+
+# modules_headers_install.sh
+#
+# Simple script to extract linux headers and friends needed to build
+# out of tree modules without having the all source tree around.
+#
+# Inspired from scripts/package/builddeb
+
+HDR_SRC_FILES=$objtree/hdrsrcfiles
+HDR_OBJ_FILES=$objtree/hdrobjfiles
+DEST_DIR=linux-modules-headers
+
+if [ -n "$INSTALL_MODULES_HDR_PATH" ]; then
+   DEST_DIR="$INSTALL_MODULES_HDR_PATH"
+fi
+
+#fresh start
+rm -f $HDR_SRC_FILES
+rm -f $HDR_OBJ_FILES
+
+#build list of headers and friends
+(cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl) \
+   > "$HDR_SRC_FILES"
+(cd $srctree; find arch/$SRCARCH/include include scripts -type f) \
+   >> "$HDR_SRC_FILES"
+(cd $srctree; find arch/$SRCARCH -name module.lds -o -name Kbuild.platforms \
+   -o -name Platform) >> "$HDR_SRC_FILES"
+(cd $srctree; find $(find arch/$SRCARCH -name include -o -name scripts \
+   -type d) -type f) >> "$HDR_SRC_FILES"
+(cd $objtree; find arch/$SRCARCH/include Module.symvers include scripts \
+   -type f) >> "$HDR_OBJ_FILES"
+
+mkdir -p "$DEST_DIR"
+
+(cd $srctree; tar -c -f - -T -) < "$HDR_SRC_FILES" | (cd $DEST_DIR; tar -xf -)
+(cd $objtree; tar -c -f - -T -) < "$HDR_OBJ_FILES" | (cd $DEST_DIR; tar -xf -)
+
+# copy .config manually to be where it's expected to be
+(cd $objtree; cp $KCONFIG_CONFIG $DEST_DIR/.config)
-- 
1.9.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/

[PATCH v3 0/5] sync a se with its cfs_rq when att(det)aching it

[byungchul . park]

From: Byungchul Park 

hello,

there are 3 problems when att(det)aching a se to(from) its cfs_rq.

problem 1. se's average load is not accounted with new cfs_rq in queued case,
when a task changes its cgroup.

problem 2. cfs_rq->avg.load_avg becomes larger and larger whenever changing
cgroup to another. we have to sync se's average load with prev cfs_rq.

problem 3. current code does not sync it with its cfs_rq when switching
sched class to fair class. if we can always assume that a se has been
detached from fair class for a long time enough for its average load to
become useless, at the time attaching it to its fair class cfs_rq, then
current code is acceptable. but the assumption is not always true.

patch 1/5, does code refactoring for further patches.
patch 2/5, solves the problem 1.
patch 3/5, solves the problem 2.
patch 4/5, solves the problem 3.
patch 5/5, does code refactoring for better readability.

change from v2 to v1 (logic is not changed at all)
* fix up my poor english in commit message and comment
* break down big patches into more patches for being reviewed easily
* supplement cover letter messages

change from v1 to v2
* introduce two functions for adjusting vruntime and load when attaching
  and detaching.
* call the introduced functions instead of switched_from(to)_fair() directly
  in task_move_group_fair().
* add decaying logic for a se which has detached from a cfs_rq.

thanks,
byungchul

Byungchul Park (5):
  sched: add two functions adjusting cfs_rq's load when att(det)aching
a se
  sched: make task_move_group_fair adjust cfs_rq's load in case of
queued
  sched: sync a se with prev cfs_rq when changing cgroup
  sched: sync a se with its cfs_rq when switching sched class to fair
class
  sched: add two functions for att(det)aching a task to(from) a cfs_rq

 kernel/sched/fair.c |  209 +++
 1 file changed, 110 insertions(+), 99 deletions(-)

-- 
1.7.9.5

--
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 v3 4/5] sched: sync a se with its cfs_rq when switching sched class to fair class

[byungchul . park]

From: Byungchul Park 

we have to sync a se with its cfs_rq, when switching sched class to
fair class.

current code does not sync it because the se average load won't be
valid any more if it has been detached for a long time. however the
se's average load would be valid just after being detached from cfs_rq,
so we need to sync it in that case, e.g. priority inheritance.

to solve the problem that a se average load becomes more useless over
time, this patch decays its average load even for the duration that
the se has been detached, when it gets attached to the cfs_rq.

Signed-off-by: Byungchul Park 
---
 kernel/sched/fair.c |   20 
 1 file changed, 20 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 1be042a..3419f6c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2711,6 +2711,17 @@ static inline void update_load_avg(struct sched_entity 
*se, int update_tg)
 
 static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
 {
+   /*
+* in case of migration and cgroup-change, more care should be taken
+* because se's cfs_rq was changed, that means calling __update_load_avg
+* with new cfs_rq->avg.last_update_time is meaningless. so we skip the
+* update here. we have to update it with prev cfs_rq just before 
changing
+* se's cfs_rq, and get here soon.
+*/
+   if (se->avg.last_update_time)
+   __update_load_avg(cfs_rq->avg.last_update_time, 
cpu_of(rq_of(cfs_rq)),
+   &se->avg, 0, 0, NULL);
+
se->avg.last_update_time = cfs_rq->avg.last_update_time;
cfs_rq->avg.load_avg += se->avg.load_avg;
cfs_rq->avg.load_sum += se->avg.load_sum;
@@ -7948,6 +7959,11 @@ static void switched_to_fair(struct rq *rq, struct 
task_struct *p)
se->depth = se->parent ? se->parent->depth + 1 : 0;
 #endif
 
+#ifdef CONFIG_SMP
+   /* synchronize task with its cfs_rq */
+   attach_entity_load_avg(cfs_rq_of(&p->se), &p->se);
+#endif
+
if (!task_on_rq_queued(p)) {
 
/*
@@ -8049,6 +8065,10 @@ static void task_move_group_fair(struct task_struct *p, 
int queued)
detach_entity_load_avg(cfs_rq, se);
 #endif
set_task_rq(p, task_cpu(p));
+
+   /* tell se's cfs_rq has been changed */
+   p->se.avg.last_update_time = 0;
+
se->depth = se->parent ? se->parent->depth + 1 : 0;
cfs_rq = cfs_rq_of(se);
if (!queued)
-- 
1.7.9.5

--
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] staging: lustre: fix whitespace errors reported by checkpatch.pl

[Mike Rapoport]

Added/removed spaces and replaced '+1' with '1' in several places to eliminate
SPACING and POINTER_LOCATION errors reported by checkpatch.pl

Signed-off-by: Mike Rapoport 
---

This time with more elaborate changelog...

 .../staging/lustre/lnet/klnds/socklnd/socklnd_cb.c |   4 +-
 drivers/staging/lustre/lnet/selftest/conrpc.h  |   4 +-
 drivers/staging/lustre/lnet/selftest/console.c |  16 +--
 drivers/staging/lustre/lnet/selftest/selftest.h|   2 +-
 drivers/staging/lustre/lustre/include/cl_object.h  |  14 +-
 drivers/staging/lustre/lustre/include/lu_object.h  |  16 +--
 .../lustre/lustre/include/lustre/lustre_idl.h  |  12 +-
 .../lustre/lustre/include/lustre/lustre_user.h |   4 +-
 .../staging/lustre/lustre/include/lustre_capa.h|   2 +-
 .../staging/lustre/lustre/include/lustre_disk.h|   2 +-
 drivers/staging/lustre/lustre/include/lustre_dlm.h |   6 +-
 .../lustre/lustre/include/lustre_dlm_flags.h   | 152 ++---
 drivers/staging/lustre/lustre/include/lustre_lib.h |   6 +-
 drivers/staging/lustre/lustre/include/lustre_net.h |   2 +-
 drivers/staging/lustre/lustre/include/obd.h|   2 +-
 .../staging/lustre/lustre/include/obd_support.h|   2 +-
 drivers/staging/lustre/lustre/libcfs/tracefile.c   |   4 +-
 drivers/staging/lustre/lustre/llite/file.c |   4 +-
 .../staging/lustre/lustre/llite/llite_internal.h   |   2 +-
 drivers/staging/lustre/lustre/llite/lproc_llite.c  |   2 +-
 drivers/staging/lustre/lustre/llite/rw.c   |   6 +-
 drivers/staging/lustre/lustre/llite/statahead.c|   4 +-
 drivers/staging/lustre/lustre/llite/vvp_io.c   |   2 +-
 drivers/staging/lustre/lustre/lmv/lmv_obd.c|   2 +-
 drivers/staging/lustre/lustre/lov/lov_obd.c|   4 +-
 drivers/staging/lustre/lustre/obdclass/cl_io.c |  10 +-
 drivers/staging/lustre/lustre/obdclass/cl_lock.c   |   6 +-
 drivers/staging/lustre/lustre/obdclass/cl_object.c |   2 +-
 drivers/staging/lustre/lustre/obdclass/class_obd.c |   4 +-
 drivers/staging/lustre/lustre/obdclass/genops.c|   6 +-
 drivers/staging/lustre/lustre/obdclass/llog.c  |   4 +-
 .../staging/lustre/lustre/obdclass/obd_config.c|   2 +-
 drivers/staging/lustre/lustre/osc/osc_request.c|   6 +-
 .../staging/lustre/lustre/ptlrpc/lproc_ptlrpc.c|   2 +-
 34 files changed, 159 insertions(+), 159 deletions(-)

diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c 
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
index 0d5aac6..4f9c5c8 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_cb.c
@@ -714,7 +714,7 @@ ksocknal_queue_tx_locked (ksock_tx_t *tx, ksock_conn_t 
*conn)
LASSERT(tx->tx_resid == tx->tx_nob);
 
CDEBUG (D_NET, "Packet %p type %d, nob %d niov %d nkiov %d\n",
-   tx, (tx->tx_lnetmsg != NULL) ? tx->tx_lnetmsg->msg_hdr.type:
+   tx, (tx->tx_lnetmsg != NULL) ? tx->tx_lnetmsg->msg_hdr.type :
   KSOCK_MSG_NOOP,
tx->tx_nob, tx->tx_niov, tx->tx_nkiov);
 
@@ -1092,7 +1092,7 @@ ksocknal_new_packet (ksock_conn_t *conn, int nob_to_skip)
conn->ksnc_rx_iov[niov].iov_len  = nob;
niov++;
skipped += nob;
-   nob_to_skip -=nob;
+   nob_to_skip -= nob;
 
} while (nob_to_skip != 0 &&/* mustn't overflow conn's rx iov */
 niov < sizeof(conn->ksnc_rx_iov_space) / sizeof (struct 
iovec));
diff --git a/drivers/staging/lustre/lnet/selftest/conrpc.h 
b/drivers/staging/lustre/lnet/selftest/conrpc.h
index 7d33cf9..ae7ed75 100644
--- a/drivers/staging/lustre/lnet/selftest/conrpc.h
+++ b/drivers/staging/lustre/lnet/selftest/conrpc.h
@@ -105,8 +105,8 @@ typedef struct lstcon_rpc_trans {
 
 #define LST_TRANS_STATQRY   0x21
 
-typedef int (* lstcon_rpc_cond_func_t)(int, struct lstcon_node *, void *);
-typedef int (* lstcon_rpc_readent_func_t)(int, srpc_msg_t *, lstcon_rpc_ent_t 
*);
+typedef int (*lstcon_rpc_cond_func_t)(int, struct lstcon_node *, void *);
+typedef int (*lstcon_rpc_readent_func_t)(int, srpc_msg_t *, lstcon_rpc_ent_t 
*);
 
 int  lstcon_sesrpc_prep(struct lstcon_node *nd, int transop,
unsigned version, lstcon_rpc_t **crpc);
diff --git a/drivers/staging/lustre/lnet/selftest/console.c 
b/drivers/staging/lustre/lnet/selftest/console.c
index f47c8f2..5c624e1 100644
--- a/drivers/staging/lustre/lnet/selftest/console.c
+++ b/drivers/staging/lustre/lnet/selftest/console.c
@@ -308,7 +308,7 @@ lstcon_group_ndlink_release(lstcon_group_t *grp, 
lstcon_ndlink_t *ndl)
 {
list_del_init(&ndl->ndl_link);
lstcon_ndlink_release(ndl);
-   grp->grp_nnode --;
+   grp->grp_nnode--;
 }
 
 static void
@@ -320,7 +320,7 @@ lstcon_group_ndlink_move(lstcon_group_t *old,
 
list_del(&ndl->ndl_hlink);
list_del(&ndl->ndl_link);
-   old->grp_nnode --;
+   old-

Re: [Patch v2] x86, ACPI, irq: Add a quirk to override SCI polarity for HyperV

[Rafael J. Wysocki]

Hi,

On Wed, Aug 19, 2015 at 8:26 AM, Jiang Liu  wrote:
> On 2015/8/19 14:04, Rafael J. Wysocki wrote:
>> Hi,
>>
>> On Wed, Aug 19, 2015 at 7:53 AM, Jiang Liu  wrote:
>>> Nick Meier reported a regression with HyperV that "
>>>   After rebooting the VM, the following messages are logged in syslog
>>>   when trying to load the tulip driver:
>>> tulip: Linux Tulip drivers version 1.1.15 (Feb 27, 2007)
>>> tulip: :00:0a.0: PCI INT A: failed to register GSI
>>> tulip: Cannot enable tulip board #0, aborting
>>> tulip: probe of :00:0a.0 failed with error -16
>>>   Errors occur in 3.19.0 kernel
>>>   Works in 3.17 kernel.
>>> "
>>>
>>> According to the ACPI dump file posted by Nick at
>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072
>>>
>>> The ACPI MADT table includes an interrupt source overridden entry for
>>> ACPI SCI:
>>> [236h 0566  1]Subtable Type : 02 
>>> [237h 0567  1]   Length : 0A
>>> [238h 0568  1]  Bus : 00
>>> [239h 0569  1]   Source : 09
>>> [23Ah 0570  4]Interrupt : 0009
>>> [23Eh 0574  2]Flags (decoded below) : 000D
>>>Polarity : 1
>>>Trigger Mode : 3
>>>
>>> And in DSDT table, we have _PRT method to define PCI interrupts, which
>>> eventually goes to:
>>> Name (PRSA, ResourceTemplate ()
>>> {
>>> IRQ (Level, ActiveLow, Shared, )
>>> {3,4,5,7,9,10,11,12,14,15}
>>> })
>>> Name (PRSB, ResourceTemplate ()
>>> {
>>> IRQ (Level, ActiveLow, Shared, )
>>> {3,4,5,7,9,10,11,12,14,15}
>>> })
>>> Name (PRSC, ResourceTemplate ()
>>> {
>>> IRQ (Level, ActiveLow, Shared, )
>>> {3,4,5,7,9,10,11,12,14,15}
>>> })
>>> Name (PRSD, ResourceTemplate ()
>>> {
>>> IRQ (Level, ActiveLow, Shared, )
>>> {3,4,5,7,9,10,11,12,14,15}
>>> })
>>>
>>> According to the MADT and DSDT tables above, IRQ 9 may be used for:
>>> 1) ACPI SCI in level, high mode
>>> 2) PCI legacy IRQ in level, low mode
>>> So there's a possible conflict in polarity setting for IRQ 9.
>>>
>>> Prior to commit cd68f6bd53cf ("x86, irq, acpi: Get rid of special
>>> handling of GSI for ACPI SCI"), ACPI SCI is handled specially and
>>> there's no check for conflicts between ACPI SCI and PCI legagy IRQ.
>>> And it seems that the HyperV hypervisor doesn't make use of the
>>> polarity configuration in IOAPIC entry, so it just works.
>>
>> That likely means the previous behavior was the same as (or at least
>> analogous to) what happens on Windows which is what the firmware has
>> been tested against and that's why the bug in it has not been caught.
>> That in turn indicates that there may be more systems having this kind
>> of problems, possibly from other vendors too, so I'm wondering if we
>> can do something more generic than using a quirk here?
> Hi Rafael,
> Good question. I was thought only virtual machines may generate
> such fake ACPI tables with conflicting pin attribute settings. For bare
> metal systems, I guess BIOS writers should report the correct hardware
> configurations, otherwise wrong pin attributes may cause hardware
> malfunction.
> If that's not the case, we may try to revert cd68f6bd53cf

Well, the regression at hand has just shown that the assertion in the
changelog of that commit ("no need for for special treatment for GSI
used by ACPI SCI") does not really hold.  So, if the only motivation
for it was to get rid of one extra check in mp_unregister_gsi()
(mp_register_gsi() still needs to check if it is dealing with the SCI
anyway), I'd vote for reverting it.

Thanks,
Rafael
--
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] Watchdog: Fix parent of watchdog_devices

[Uwe Kleine-König]

Hello,

On Wed, Aug 19, 2015 at 08:58:24AM +0530, Pratyush Anand wrote:
> /sys/class/watchdog/watchdogn/device/modalias can help to identify the
> driver/module for a given watchdog node. However, many wdt devices does not 
> set

s/es//

> its parent and so, we do not see an entry for device in sysfs for such 
> devices.
> 
> This patch fixes parent of watchdog_device so that
> /sys/class/watchdog/watchdogn/device is populated.
> 
> Exceptions: booke, diag288, mpc8xxx, octeon, softdog and w83627hf -- They do 
> not
> have any parent. Not sure, how we can we identify driver for these devices.

I don't see why you don't use the platform device as parent for mpc8xxx.

Note however that I did several updates to the mpc8xxx driver which
probably conflict with setting the parent. I'll take care of that.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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/5] KVM: add KVM_USER_EXIT vcpu ioctl for userspace exit

[Avi Kivity]

On 08/18/2015 10:57 PM, Paolo Bonzini wrote:


On 18/08/2015 11:30, Avi Kivity wrote:

KVM_USER_EXIT in practice should be so rare (at least with in-kernel
LAPIC) that I don't think this matters.  KVM_USER_EXIT is relatively
uninteresting, it only exists to provide an alternative to signals that
doesn't require expensive atomics on each and every KVM_RUN. :(

Ah, so the idea is to remove the cost of changing the signal mask?

Yes, it's explained in the cover letter.


Yes, although it looks like a thread-local operation, it takes a
process-wide lock.

IIRC the lock was only task-wide and uncontended.  Problem is, it's on
the node that created the thread rather than the node that is running
it, and inter-node atomics are really, really slow.


Cached inter-node atomics are (relatively) fast, but I think it really 
is a process-wide lock:


sigprocmask calls:

void __set_current_blocked(const sigset_t *newset)
{
struct task_struct *tsk = current;

spin_lock_irq(&tsk->sighand->siglock);
__set_task_blocked(tsk, newset);
spin_unlock_irq(&tsk->sighand->siglock);
}

struct sighand_struct {
atomic_tcount;
struct k_sigactionaction[_NSIG];
spinlock_tsiglock;
wait_queue_head_tsignalfd_wqh;
};

Since sigaction is usually process-wide, I conclude that so will 
tsk->sighand.






For guests spanning >1 host NUMA nodes it's not really practical to
ensure that the thread is created on the right node.  Even for guests
that fit into 1 host node, if you rely on AutoNUMA the VCPUs are created
too early for AutoNUMA to have any effect.  And newer machines have
frighteningly small nodes (two nodes per socket, so it's something like
7 pCPUs if you don't have hyper-threading enabled).  True, the NUMA
penalty within the same socket is not huge, but it still costs a few
thousand clock cycles on vmexit.flat and this feature sweeps it away
completely.


I expect most user wakeups are via irqfd, so indeed the performance of
KVM_USER_EXIT is uninteresting.

Yup, either irqfd or KVM_SET_SIGNAL_MSI.

Paolo


--
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 0/7] gpio: omap: fixes and improvements

[Tony Lindgren]

Hi,

* Grygorii Strashko  [150818 04:14]:
> Hi,
> 
> This patch series contains set of trivial fixes and improvements, and also
> patches which fixes wrong APIs usage in atomic context as for -RT as for
> non-RT kernel. The final goal of this series is to make TI OMAP GPIO
> driver compatible with -RT kernel as much as possible.
> 
> Patch 1-4: trivial fixes and improvements
> Patch 5: fixes wrong CLK clk_prepare/unprepare APIs usage in atomic contexet
> Patch 6(rfc): required to be compatible with -RT kernel, because PM runtime
>  can't be used in atimic context on -RT.
> Patch 7(rfc): This patch converts TI OMAP GPIO driver to use generic irq
>  handler instead of chained IRQ handler. This way OMAP GPIO driver will be
>  compatible with RT kernel where it will be forced thread IRQ handler
>  while in non-RT kernel it still will be executed in HW IRQ context.

Based on quick testing this series breaks at least core off idle for omap3.
You probably should add a beagle xm to your test devices so you can
properly test PM features.

Regards,

Tony
--
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 28/51] PCI: Unifiy calculate_size for io port and mmio

[Yinghai Lu]

On Mon, Aug 17, 2015 at 9:13 PM, Bjorn Helgaas  wrote:
> On Mon, Jul 27, 2015 at 04:29:46PM -0700, Yinghai Lu wrote:
>> We should check size+size1 with min_size for io port.
>> For example, when hotplug bridge has two children bridges,
>> every child bridge will need 0x1000, so size1 will be 0x2000
>> and size is 0. The min_size for the hotplug bridge is 0x100.
>
> A min_size of 0x100?  Is that a typo?

yes, it is 0x100.

#define DEFAULT_HOTPLUG_IO_SIZE (256)
/* pci=hpmemsize=nnM,hpiosize=nn can override this */
unsigned long pci_hotplug_io_size  = DEFAULT_HOTPLUG_IO_SIZE;

and we have

if (bus->self->is_hotplug_bridge) {
min_io_size  = pci_hotplug_io_size;

>
>> with old version calculate_iosize, we get 0x3000 for final
>> size because we are using size to compare with min_size. That is
>> not right, we should use 0x2000 instead.
>
> If this fixes a bug, please make one patch that *only* fixes the bug,
> and a separate one that unifies but doesn't change the behavior.

ok, will separate it into two.
--
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: Kill E820_RESERVED_KERN

[Yu Chen]

Hi,
On 07/29/2015 03:21 AM, Yinghai Lu wrote:

E820_RESERVED_KERN was introduced to do early allocation for
setup_data when we were using original early_res with e820 map.

Now we are using memblock to do early resource reserve/allocation, and
setup_data is reserved in memblock early already.

For kexec path, kexec generate setup_data (Now kexec-tools create SETUP_EFI
and SETUP_E820_EXT), and pass pointer to second kernel, and
second kernel reserve setup_data by their own without using e820 map.

So we do not need to touch e820 map at all, and we can kill
E820_RESERVED_KERN.

That make the code simpler, and at same time that will fix bug with
hibernation:
   mark_nonsave_region that can not handle that case:
 E820_RAM and E820_RESERVED_KERN ranges are continuous and
 boundary is not page aligned.

Link: https://bugzilla.opensuse.org/show_bug.cgi?id=913885
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96111


I've tested Hibernation on latest 4.2.-rc7 and encountered panic when
resuming, so I guess this patch has not been merged upstream:

BUG: unable to handle kernel paging request at 880085894000
IP: [] load_image_lzo+0x8c2/0xe70

With current patch and Lee, Chun-Yi's patch applied, the panic
disappeared, would someone please have a look at this patch,
thanks a lot.

Best Regards,
Yu


--
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 27/51] PCI: Move ISA ioport align out of calculate_iosize

[Yinghai Lu]

On Mon, Aug 17, 2015 at 9:11 PM, Bjorn Helgaas  wrote:
> On Mon, Jul 27, 2015 at 04:29:45PM -0700, Yinghai Lu wrote:
>> So we could unify calculate_iosize and calculate_memsize later.
>
> Please make this a complete sentence, not just a continuation of the
> summary line.
>
>> when one bridge have several children devices, and every devices
>> have several io port resources and resource size < 0x400.
>
> This isn't a sentence either, so I'm not sure what this is supposed to
> mean.

will change to:

Subject: [PATCH] PCI: Move ISA io port align out of calculate_iosize()

We can move ISA io port align out of calculate_iosize(),
so we could unify calculate_iosize and calculate_memsize later.

That extra aligning or offset is to work around ISA devices:
When one bridge have several children devices, and every device
has several io port resources and resource size < 0x400.
We need to check size, and add extra size to make sure bit8/9
to be zero.
--
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 Aug 18 (drivers/media/i2c/tc358743.c)

[Hans Verkuil]

On 08/18/2015 05:26 PM, Randy Dunlap wrote:
> On 08/18/15 04:40, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20150817:
>>
> 
> on i386:
> 
> when CONFIG_MEDIA_CONTROLLER is not enabled:
> 
> ../drivers/media/i2c/tc358743.c: In function 'tc358743_probe':
> ../drivers/media/i2c/tc358743.c:1890:29: error: 'struct v4l2_subdev' has no 
> member named 'entity'
>   err = media_entity_init(&sd->entity, 1, &state->pad, 0);
>  ^
> ../drivers/media/i2c/tc358743.c:1940:26: error: 'struct v4l2_subdev' has no 
> member named 'entity'
>   media_entity_cleanup(&sd->entity);
>   ^
> ../drivers/media/i2c/tc358743.c: In function 'tc358743_remove':
> ../drivers/media/i2c/tc358743.c:1955:26: error: 'struct v4l2_subdev' has no 
> member named 'entity'
>   media_entity_cleanup(&sd->entity);
>   ^
> 
> 
> 

tc358743: add missing Kconfig dependency/select

This driver depends on VIDEO_V4L2_SUBDEV_API and needs to select HDMI.

Signed-off-by: Hans Verkuil 
Reported-by: Randy Dunlap 

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index d669547..521bbf1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -289,7 +289,8 @@ config VIDEO_SAA711X
 
 config VIDEO_TC358743
tristate "Toshiba TC358743 decoder"
-   depends on VIDEO_V4L2 && I2C
+   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+   select HDMI
---help---
  Support for the Toshiba TC358743 HDMI to MIPI CSI-2 bridge.
 

--
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] x86, ACPI, irq: Add a quirk to override SCI polarity for HyperV

[Jiang Liu]

On 2015/8/19 14:04, Rafael J. Wysocki wrote:
> Hi,
> 
> On Wed, Aug 19, 2015 at 7:53 AM, Jiang Liu  wrote:
>> Nick Meier reported a regression with HyperV that "
>>   After rebooting the VM, the following messages are logged in syslog
>>   when trying to load the tulip driver:
>> tulip: Linux Tulip drivers version 1.1.15 (Feb 27, 2007)
>> tulip: :00:0a.0: PCI INT A: failed to register GSI
>> tulip: Cannot enable tulip board #0, aborting
>> tulip: probe of :00:0a.0 failed with error -16
>>   Errors occur in 3.19.0 kernel
>>   Works in 3.17 kernel.
>> "
>>
>> According to the ACPI dump file posted by Nick at
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072
>>
>> The ACPI MADT table includes an interrupt source overridden entry for
>> ACPI SCI:
>> [236h 0566  1]Subtable Type : 02 
>> [237h 0567  1]   Length : 0A
>> [238h 0568  1]  Bus : 00
>> [239h 0569  1]   Source : 09
>> [23Ah 0570  4]Interrupt : 0009
>> [23Eh 0574  2]Flags (decoded below) : 000D
>>Polarity : 1
>>Trigger Mode : 3
>>
>> And in DSDT table, we have _PRT method to define PCI interrupts, which
>> eventually goes to:
>> Name (PRSA, ResourceTemplate ()
>> {
>> IRQ (Level, ActiveLow, Shared, )
>> {3,4,5,7,9,10,11,12,14,15}
>> })
>> Name (PRSB, ResourceTemplate ()
>> {
>> IRQ (Level, ActiveLow, Shared, )
>> {3,4,5,7,9,10,11,12,14,15}
>> })
>> Name (PRSC, ResourceTemplate ()
>> {
>> IRQ (Level, ActiveLow, Shared, )
>> {3,4,5,7,9,10,11,12,14,15}
>> })
>> Name (PRSD, ResourceTemplate ()
>> {
>> IRQ (Level, ActiveLow, Shared, )
>> {3,4,5,7,9,10,11,12,14,15}
>> })
>>
>> According to the MADT and DSDT tables above, IRQ 9 may be used for:
>> 1) ACPI SCI in level, high mode
>> 2) PCI legacy IRQ in level, low mode
>> So there's a possible conflict in polarity setting for IRQ 9.
>>
>> Prior to commit cd68f6bd53cf ("x86, irq, acpi: Get rid of special
>> handling of GSI for ACPI SCI"), ACPI SCI is handled specially and
>> there's no check for conflicts between ACPI SCI and PCI legagy IRQ.
>> And it seems that the HyperV hypervisor doesn't make use of the
>> polarity configuration in IOAPIC entry, so it just works.
> 
> That likely means the previous behavior was the same as (or at least
> analogous to) what happens on Windows which is what the firmware has
> been tested against and that's why the bug in it has not been caught.
> That in turn indicates that there may be more systems having this kind
> of problems, possibly from other vendors too, so I'm wondering if we
> can do something more generic than using a quirk here?
Hi Rafael,
Good question. I was thought only virtual machines may generate
such fake ACPI tables with conflicting pin attribute settings. For bare
metal systems, I guess BIOS writers should report the correct hardware
configurations, otherwise wrong pin attributes may cause hardware
malfunction.
If that's not the case, we may try to revert cd68f6bd53cf
instead.
Thanks!
Gerry
--
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] mtd: nand: pxa3xx-nand: fix random command timeouts

[Robert Jarzmik]

Brian Norris  writes:

> Hi Robert,
>
> On Mon, Aug 17, 2015 at 09:15:48PM +0200, Robert Jarzmik wrote:
>> Ezequiel Garcia  writes:
>> > So unless I'm completely off, the current patch is right, and a comment
>> > would be helpful.
>> Ok Ezequiel, I'll wait for your Tested-by, and respin with something like :
>> 
>>  /* Clear all status bit before issuing the next command, which can and
>>  * will alter the status bits and will deserve a new interrupt on its
>>  * own.
>>  */
>
> To be clear: I should hold off on this patch?
If you can hold until this evening (ie. in 12h), I'll post the same version of
the patch with Ezequiel's comment, and Ack/Test if he provides it.

If you have to decide in the next few hours, take it, this fix should land in
v4.3.

> I'm going to try to clear my queue of things that are simple/obvious
> and/or fix bugs (I think you spoke up about a different pxa3xx_nand
> bugfix which I will try to find). There's too big a backlog for me to
> get through everything for the merge window...

I'll resend my pxa3xx-nand backlog this evening for fixes I have on mind which
are simple fixes :
 - this one (random command timeouts)
 - Antoine's one (resent yesterday)
 - my fix for probe (mtd: nand: pxa3xx_nand: fix early spurious interrupt)
If you can wait this evening it will spare you digging through your mails.

Or alternatively Ezequiel, if you want to aggregate the patches because you have
others on mind also, please feel free to overtake this from me before my 
evening :)

Cheers.

-- 
Robert
--
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 03/13] twl4030_charger: correctly handle -EPROBE_DEFER from devm_usb_get_phy_by_node

[Tony Lindgren]

* NeilBrown  [150818 17:32]:
> On Tue, 18 Aug 2015 01:07:58 -0700 Tony Lindgren 
> wrote:
> 
> > * NeilBrown  [150729 17:29]:
> > > Now that twl4030_bci_probe can safely return -EPROBE_DEFER,
> > > do so when devm_usb_get_phy_by_node returns that error.
> > > 
> > > Signed-off-by: NeilBrown 
> > > ---
> > >  drivers/power/twl4030_charger.c |6 +-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/power/twl4030_charger.c 
> > > b/drivers/power/twl4030_charger.c
> > > index 045238370d3f..ffc123fb7158 100644
> > > --- a/drivers/power/twl4030_charger.c
> > > +++ b/drivers/power/twl4030_charger.c
> > > @@ -636,9 +636,13 @@ static int twl4030_bci_probe(struct platform_device 
> > > *pdev)
> > >  
> > >   phynode = of_find_compatible_node(bci->dev->of_node->parent,
> > > NULL, "ti,twl4030-usb");
> > > - if (phynode)
> > > + if (phynode) {
> > >   bci->transceiver = devm_usb_get_phy_by_node(
> > >   bci->dev, phynode, &bci->usb_nb);
> > > + if (IS_ERR(bci->transceiver) &&
> > > + PTR_ERR(bci->transceiver) == -EPROBE_DEFER)
> > > + return -EPROBE_DEFER;
> > > + }
> > >   }
> > 
> > Neil, the return with -EPROBE_DEFER here causes flakeyness booting
> > for me somehow at least on my logicpd-torpedo-37xx-devkit using
> > omap2plus_defconfig.
> > 
> > It seems that the twl4030_bci_probe keeps looping or something about
> > 1/3 of the boots and that probably prevents the other twl modules
> > from loading? Reverting this patch alone seems to fix the issue.
> > 
> > I don't think I have a battery wired on this board the USB is wired
> > the same way as on beagle-xm. So I'd assume also flakeyness on beagle
> > xm with this patch.
> 
> What dts file are you using?
> I'm guessing that it doesn't have something like:
> 
> &usb_otg_hs {
> interface-type = <0>;
> usb-phy = <&usb2_phy>;
> phys = <&usb2_phy>;
> phy-names = "usb2-phy";
> mode = <3>;
> power = <50>;
> };

It's the logicpd-torpedo-37xx-devkit.dts like I mentioned above,
and yes it has the same entry above like beagle xm.
 
> ? i.e. with a usb-phy=<&usb2_phy> ?
> 
> What if you add
> 
> &usb2_phy {
>  status = "disabled";
> }
> 
> to your dts file?

Yes then the PHY driver won't get probed and modprobe of the
charger won't hang with -EPROBE_DEFER.. The USB is working on this
one like on beagle xm so that's not a solution.
 
> Should the 'status' be disabled in twl4030.dtsi, and then marked OK in
> any dts that uses it?  I'm not at all clear on how 'status' is meant to
> be used.

Well status = "disabled" makes kernel completely ignore the
hardware, so the struct device is never created. I'd stay away from
using that in general for proper runtime idling of devices.. The
hardware is there for sure :)

Can you check if something like the the following allows you to
reproduce the hang of modprobe twl4030_charger:

# rmmod phy-twl4030-usb
# modprobe twl4030_charger

So just don't probe phy-twl4030-usb before twl4030_charger and
then modprobe of twl4030_charger hangs?

That is with proper usb2_phy configured in .dts file and not
set to status = "disabled".

Regards,

Tony
--
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 25/51] PCI: Fix size calculation with old_size on rescan path

[Yinghai Lu]

On Mon, Aug 17, 2015 at 9:09 PM, Bjorn Helgaas  wrote:
> On Mon, Jul 27, 2015 at 04:29:43PM -0700, Yinghai Lu wrote:
>> On booting path, we don't pass realloc at first, and treat all optional just
>> as must, in some case we can smaller size/align with optional than must only.
>>
>> 04:00.0 has four child bridges: 05:01.0, 05:02.0, 05:03.0, 05:04.0
>> pref layout after booting path like followings:
>>
>> pci :04:00.0: BAR 9: assigned [mem 0x8400-0x9fff 64bit pref]
>> pci :05:04.0: BAR 9: assigned [mem 0x8800-0x9fff 64bit pref]
>> pci :05:03.0: BAR 9: assigned [mem 0x8400-0x841f 64bit pref]
>> pci :07:00.0: BAR 0: assigned [mem 0x8120-0x8123 64bit]
>> pci :05:03.0: PCI bridge to [bus 08-0f]
>> pci :05:03.0:   bridge window [mem 0x8400-0x841f 64bit pref]
>> pci :10:00.0: BAR 0: assigned [mem 0x9000-0x9fff 64bit pref]
>> pci :10:00.0: BAR 2: assigned [mem 0x8800-0x8800 64bit pref]
>> pci :05:04.0: PCI bridge to [bus 10]
>> pci :05:04.0:   bridge window [mem 0x8800-0x9fff 64bit pref]
>> pci :04:00.0: PCI bridge to [bus 05-10]
>> pci :04:00.0:   bridge window [mem 0x8400-0x9fff 64bit pref]
>
> Unless 07:00.0 and 10:00.0 are relevant, please remove them.

ok

>
>> so the old size in rescan for 04:00.0 would be 0x1c00, and align is 
>> 0x400
>>
>> during remove and rescan:
>>
>> pci :05:03.0: bridge window [mem 0x-0x 64bit 
>> pref] to [bus 08-0f] add_size 20 add_align 10 alt_size 0 alt_align 0 
>> must_size 0 must_align 0
>
> What is "[mem 0x-0x 64bit pref]" telling us?
> Surely that's not an actual aperture, is it?

required size is 0, the optional only resources.
--
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] thermal: cpu_cooling: Remove usage of devm functions

[Vaishali Thakkar]

In the function cpufreq_get_requested_power, the memory allocated
for load_cpu is live within the function only. And after the
allocation it is immediately freed with devm_kfree. There is no
need to allocate memory for load_cpu with devm function so replace
devm_kcalloc with kcalloc and devm_kfree with kfree.

Signed-off-by: Vaishali Thakkar 
---
This patch is having one checkpatch.pl warning which suggests that
kfree(NULL) is safe. But I think leaving code with if is nice
because it reflects the fact that kcalloc was under an if. So, I
have ignored checkpatch. If maintainer wants me to go for changing
things, I am fine with it too.
---
 drivers/thermal/cpu_cooling.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 620dcd4..babf8b3 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -584,8 +584,7 @@ static int cpufreq_get_requested_power(struct 
thermal_cooling_device *cdev,
if (trace_thermal_power_cpu_get_power_enabled()) {
u32 ncpus = cpumask_weight(&cpufreq_device->allowed_cpus);
 
-   load_cpu = devm_kcalloc(&cdev->device, ncpus, sizeof(*load_cpu),
-   GFP_KERNEL);
+   load_cpu = kcalloc(ncpus, sizeof(*load_cpu), GFP_KERNEL);
}
 
for_each_cpu(cpu, &cpufreq_device->allowed_cpus) {
@@ -609,7 +608,7 @@ static int cpufreq_get_requested_power(struct 
thermal_cooling_device *cdev,
ret = get_static_power(cpufreq_device, tz, freq, &static_power);
if (ret) {
if (load_cpu)
-   devm_kfree(&cdev->device, load_cpu);
+   kfree(load_cpu);
return ret;
}
 
@@ -618,7 +617,7 @@ static int cpufreq_get_requested_power(struct 
thermal_cooling_device *cdev,
&cpufreq_device->allowed_cpus,
freq, load_cpu, i, dynamic_power, static_power);
 
-   devm_kfree(&cdev->device, load_cpu);
+   kfree(load_cpu);
}
 
*power = static_power + dynamic_power;
-- 
1.9.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/

Re: [PATCH 2/2] ARM: dts: rockchip: correct regulator PM properties

[Heiko Stuebner]

Am Dienstag, 18. August 2015, 16:28:06 schrieb Brian Norris:
> Now that I'm looking a little closer, it seems like other existing DTS's
> are broken too, then. Jerry looks like it was converted to the
> regulator-state-mem node binding, but the conversion doesn't seem to
> make sense when I compare the chromium DTS sources with the for-next
> source I see in your tree.
> 
> In -next:
> 
>  regulators {
>  mic_vcc: LDO_REG2 {
> regulator-name = "mic_vcc";
> regulator-always-on;
> regulator-boot-on;
> regulator-min-microvolt = <180>;
> regulator-max-microvolt = <180>;
> regulator-state-mem {
> regulator-on-in-suspend;
> };
> };
>  };
> 
> But chromium had:
> 
>regulators {
> mic_vcc: LDO_REG2 {
> regulator-always-on;
> regulator-boot-on;
> regulator-min-microvolt = <180>;
> regulator-max-microvolt = <180>;
> regulator-name = "mic_vcc";
> regulator-suspend-mem-disabled;
> };
>};
> 
> So I guess I'll make the proper conversion for all the veyron variants I
> see.

great, just take into account the deep vs. shallow suspend modes :-)

The original regulator-state changes did happen when we had this suspend 
instability (counter and gpioint stuff) and I did go with the values similar to 
the rk3288-evb, as this was the only one resuming at all at the time. So I 
guess I never looked to closesly what it did, as long as the system came out 
of suspend sucessfully again :-)


Heiko
--
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] x86 fixes

[Ingo Molnar]

* Ingo Molnar  wrote:

> So I went and built 743aa456c1834f76 with ARCH=i386 defconfig 
> +MATH_EMULATION=y 
> and booted it on real hardware with and without 'no387':
> 
>   - 743aa456c1834f76: boots fine to a generic distro
>   - 743aa456c1834f76 + no387: early crash
> 
> the early crash is similar to what I saw when doing the recent FPU changes 
> (and 
> which crash I fixed):

Hm, so that crash is back again with the latest kernel:

[0.00] EIP is at kmem_cache_alloc+0x25/0x110

  
...
[0.00]  [] init_fpu+0x7f/0xc0 

  
[0.00]  [] math_emulate+0x6b5/0xc90   

  
[0.00]  [] ? early_serial_putc+0x60/0x60  

  
[0.00]  [] ? call_console_drivers.constprop.14+0x8c/0xe0  

  
[0.00]  [] ? up+0x25/0x50 

  
[0.00]  [] ? console_unlock+0x305/0x4d0   

  
[0.00]  [] ? process_srcu+0x56/0xb0   

  
[0.00]  [] ? do_debug+0x160/0x160 

  
[0.00]  [] do_device_not_available+0x38/0x60  

  
[0.00]  [] error_code+0x5a/0x60   

  
[0.00]  [] ? do_debug+0x160/0x160 

  
[0.00]  [] ? fpu_init+0xd9/0xf7   

  
[0.00]  [] cpu_init+0x237/0x23f   

  
[0.00]  [] trap_init+0x243/0x24b  

  
[0.00]  [] start_kernel+0x143/0x2d4   

  
[0.00]  [] i386_start_kernel+0x76/0x7b

I suspect due to:

  5aaeb5c01c5b x86/fpu, sched: Introduce CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT 
and use it on x86
  0c8c0f03e3a2 x86/fpu, sched: Dynamically allocate 'struct fpu'

Thanks,

Ingo
--
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] x86, ACPI, irq: Add a quirk to override SCI polarity for HyperV

[Rafael J. Wysocki]

Hi,

On Wed, Aug 19, 2015 at 7:53 AM, Jiang Liu  wrote:
> Nick Meier reported a regression with HyperV that "
>   After rebooting the VM, the following messages are logged in syslog
>   when trying to load the tulip driver:
> tulip: Linux Tulip drivers version 1.1.15 (Feb 27, 2007)
> tulip: :00:0a.0: PCI INT A: failed to register GSI
> tulip: Cannot enable tulip board #0, aborting
> tulip: probe of :00:0a.0 failed with error -16
>   Errors occur in 3.19.0 kernel
>   Works in 3.17 kernel.
> "
>
> According to the ACPI dump file posted by Nick at
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072
>
> The ACPI MADT table includes an interrupt source overridden entry for
> ACPI SCI:
> [236h 0566  1]Subtable Type : 02 
> [237h 0567  1]   Length : 0A
> [238h 0568  1]  Bus : 00
> [239h 0569  1]   Source : 09
> [23Ah 0570  4]Interrupt : 0009
> [23Eh 0574  2]Flags (decoded below) : 000D
>Polarity : 1
>Trigger Mode : 3
>
> And in DSDT table, we have _PRT method to define PCI interrupts, which
> eventually goes to:
> Name (PRSA, ResourceTemplate ()
> {
> IRQ (Level, ActiveLow, Shared, )
> {3,4,5,7,9,10,11,12,14,15}
> })
> Name (PRSB, ResourceTemplate ()
> {
> IRQ (Level, ActiveLow, Shared, )
> {3,4,5,7,9,10,11,12,14,15}
> })
> Name (PRSC, ResourceTemplate ()
> {
> IRQ (Level, ActiveLow, Shared, )
> {3,4,5,7,9,10,11,12,14,15}
> })
> Name (PRSD, ResourceTemplate ()
> {
> IRQ (Level, ActiveLow, Shared, )
> {3,4,5,7,9,10,11,12,14,15}
> })
>
> According to the MADT and DSDT tables above, IRQ 9 may be used for:
> 1) ACPI SCI in level, high mode
> 2) PCI legacy IRQ in level, low mode
> So there's a possible conflict in polarity setting for IRQ 9.
>
> Prior to commit cd68f6bd53cf ("x86, irq, acpi: Get rid of special
> handling of GSI for ACPI SCI"), ACPI SCI is handled specially and
> there's no check for conflicts between ACPI SCI and PCI legagy IRQ.
> And it seems that the HyperV hypervisor doesn't make use of the
> polarity configuration in IOAPIC entry, so it just works.

That likely means the previous behavior was the same as (or at least
analogous to) what happens on Windows which is what the firmware has
been tested against and that's why the bug in it has not been caught.
That in turn indicates that there may be more systems having this kind
of problems, possibly from other vendors too, so I'm wondering if we
can do something more generic than using a quirk here?

Rafael
--
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] x86 fixes

[Ingo Molnar]

* H. Peter Anvin  wrote:

> On 08/17/2015 10:17 AM, Linus Torvalds wrote:
> > On Mon, Aug 17, 2015 at 9:58 AM, H. Peter Anvin  wrote:
> >>
> >> That is not true.  It *does* work, and I have tested it fairly recently.
> > 
> > Ok, so it's not too badly broken. Good.
> > 
> > Also, while it's been a long time since we needed FPU emulation on the
> > i486sx, I don't recall the details of any of the (much more modern)
> > IoT small cores. I *think* the base platforms are all at a Pentium
> > level (ie not just FPU, but MMX), but maybe there's some reason to
> > keep FP emulation alive for some platforms.
> > 
> 
> I just went back and looked at my records... I can guarantee that it
> worked as of 743aa456c1834f76982af44e8b71d1a0b2a82e21.

So I went and built 743aa456c1834f76 with ARCH=i386 defconfig +MATH_EMULATION=y 
and booted it on real hardware with and without 'no387':

  - 743aa456c1834f76: boots fine to a generic distro
  - 743aa456c1834f76 + no387: early crash

the early crash is similar to what I saw when doing the recent FPU changes (and 
which crash I fixed):

[0.00] Linux version 3.7.0+ (mingo@fomalhaut) (gcc version 4.9.2 
20150212 (Red Hat 4.9.2-6) (GCC) ) #284 SMP Wed Aug 19 07:51:05 CEST 2015   
 
...
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)   

  
[0.00] __ex_table already sorted, skipping sort 

  
[0.00] Initializing CPU#0   

  
[0.00] BUG: unable to handle kernel NULL pointer dereference at   
(null)  
...
[0.00] EIP is at kmem_cache_alloc+0x25/0x110

  
[0.00] Call Trace:  

  
[0.00]  [] ? sprintf+0x1c/0x20

  
[0.00]  [] ? init_fpu+0x7f/0xc0   

  
[0.00]  [] ? print_prefix+0xcf/0x130  

  
[0.00]  [] ? do_debug+0x160/0x160 

  
[0.00]  [] init_fpu+0x7f/0xc0 

  
[0.00]  [] math_emulate+0x6b5/0xc90
[0.00]  [] do_device_not_available+0x38/0x60  

  
[0.00]  [] error_code+0x5a/0x60   

  
[0.00]  [] ? do_debug+0x160/0x160 

  
[0.00]  [] ? fpu_init+0xd9/0xf7   

  
[0.00]  [] cpu_init+0x237/0x23f   

  
[0.00]  [] trap_init+0x243/0x24b  

  
[0.00]  [] start_kernel+0x143/0x2d4   

  
[0.00]  [] i386_start_kernel+0x76/0x7b


And I think this early crash bug was introduced 7+ years ago in March 2008, 
when 
the FPU context area was separated from the task struct and its allocation went 
dynamic:

  61c4628b5386 ("x86, fpu: split FPU state from task struct - v5")

... but that's just a guess, I couldn't check that as kernels that far back 
don't 
build and boot anymore with modern tooling.

Thanks,

Ingo
--
To unsubscribe from this li

Re: kexec, x86: Need a new e820 type support for kexec

[Baoquan He]

On 08/18/15 at 11:36pm, Toshi Kani wrote:
> On 8/18/2015 8:53 PM, Baoquan He wrote:
> >On 08/18/15 at 09:01am, Toshi Kani wrote:
> >>On Tue, 2015-08-18 at 16:53 +0800, Baoquan He wrote:
> >>>Rethink it again, maybe it's better to pass PMEM as PRAM to kdump
> >>>kernel if user really want to use memmap way by specifying
> >>>--pass-memmap-cmdline. Then I need add the PMEM and PRAM checking here
> >>>you pointed out. Will repost with them.
> >>No, you should not report PMEM as PRAM.  They are different things.  The
> >>kdump kernel does not need to support memmap cmdline for PMEM, as the
> >>regular kernel does not -- memmap cmdline cannot emulate PMEM.
> >OK. Then it will be wrong if people intend to specify
> >--pass-memmap-cmdline. There might be 3 ways to fix this:
> >
> >1) add PMEM support in kernel. memmap cmdline is not only used for
> >emulating, but for kexec/kdump using.
> >
> >2) Delete --pass-memmap-cmdline option in kexec-tools since people
> >rarely use it.
> >
> >3) Add a note in kexec-tools that option --pass-memmap-cmdline can't
> >work together with PMEM, people should not use it.
> 
> 3) is fine, and I do not think we need a note either.  It does not
> make sense to add an memmap cmdline for PMEM since PMEM ranges
> require ACPI NFIT table.

OK, got it. Let me repost without PMEM memmap adding. In fact I am
a little confused that E820_PMEM is got by EFI in linux, seems in
do_add_efi_memmap() though later ACPI NFIT need be read and more
information about nvdimm will be got for nvdimm device. e820 memory map
need be got from uefi/bios/kexec, this doesn't conflict with ACPI NFIT
processing.

Thanks
Baoquan
--
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 2/5] Documentation: Detail permitted DT properties for the imx6ul_tsc

[Markus Pargmann]

Hi,

On Tue, Jul 28, 2015 at 05:58:38PM +0800, Haibo Chen wrote:
> Here we apply required documentation for the imx6ul touch screen
> controller driver which describe available properties and how to
> use them.
> 
> Signed-off-by: Haibo Chen 
> ---
>  .../bindings/input/touchscreen/imx6ul_tsc.txt  | 36 
> ++
>  1 file changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt 
> b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> new file mode 100644
> index 000..ac41c32
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt
> @@ -0,0 +1,36 @@
> +* Freescale i.MX6UL Touch Controller
> +
> +Required properties:
> +- compatible: must be "fsl,imx6ul-tsc".
> +- reg: this touch controller address and the ADC2 address.

This suggests that this driver is using a unit ADC2. Which also means
that there are more than one ADC which are probably identical?

Shouldn't these ADCs be properly described by their own device nodes
instead of these two register ranges, two interrupts and two clocks?

Is 'ADC2' usable without tsc? Then ADC1/ADC2 should perhaps get a proper
IIO driver.

Unfortunately I don't have the reference manual to have a look how this
all works.

Best regards,

Markus

> +- interrupts: the interrupt of this touch controller and ADC2.
> +- clocks: the root clock of touch controller and ADC2.
> +- clock-names; must be "tsc" and "adc".
> +- xnur-gpio: the X- gpio this controller connect to.
> +  This xnur-gpio returns to high once the finger leave the touch screen (The
> +  last touch event the touch controller capture).
> +
> +Optional properties:
> +- measure-delay-time: the value of measure delay time.
> +  Before X-axis or Y-axis measurement, the screen need some time before
> +  even potential distribution ready.
> +  This value depends on the touch screen.
> +- pre-charge-time: the touch screen need some time to precharge.
> +  This value depends on the touch screen.
> +
> +Example:
> + tsc: tsc@0204 {
> + compatible = "fsl,imx6ul-tsc";
> + reg = <0x0204 0x4000>, <0x0219c000 0x4000>;
> + interrupts = ,
> +  ;
> + clocks = <&clks IMX6UL_CLK_IPG>,
> +  <&clks IMX6UL_CLK_ADC2>;
> + clock-names = "tsc", "adc";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_tsc>;
> + xnur-gpio = <&gpio1 3 GPIO_ACTIVE_HIGH>;
> + measure-delay-time = <0xfff>;
> + pre-charge-time = <0x>;
> + status = "okay";
> + };
> -- 
> 1.9.1
> 
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


signature.asc
Description: Digital signature

[PATCH] [SCSI] bnx2fc: Convert use of __constant_htons to htons

[Vaishali Thakkar]

In little endian cases, the macro htons unfolds to __swab16 which
provides special case for constants. In big endian cases,
__constant_htons and htons expand directly to the same expression.
So, replace __constant_htons with htons with the goal of getting
rid of the definition of __constant_htons completely.

The semantic patch that performs this transformation is as follows:

@@expression x;@@

- __constant_htons(x)
+ htons(x)

Signed-off-by: Vaishali Thakkar 
---
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index d5cdc47..99f801c 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -1201,7 +1201,7 @@ static int bnx2fc_interface_setup(struct bnx2fc_interface 
*interface)
dev_add_pack(&interface->fip_packet_type);
 
interface->fcoe_packet_type.func = bnx2fc_rcv;
-   interface->fcoe_packet_type.type = __constant_htons(ETH_P_FCOE);
+   interface->fcoe_packet_type.type = htons(ETH_P_FCOE);
interface->fcoe_packet_type.dev = netdev;
dev_add_pack(&interface->fcoe_packet_type);
 
-- 
1.9.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/

[Patch v2] x86, ACPI, irq: Add a quirk to override SCI polarity for HyperV

[Jiang Liu]

Nick Meier reported a regression with HyperV that "
  After rebooting the VM, the following messages are logged in syslog
  when trying to load the tulip driver:
tulip: Linux Tulip drivers version 1.1.15 (Feb 27, 2007)
tulip: :00:0a.0: PCI INT A: failed to register GSI
tulip: Cannot enable tulip board #0, aborting
tulip: probe of :00:0a.0 failed with error -16
  Errors occur in 3.19.0 kernel
  Works in 3.17 kernel.
"

According to the ACPI dump file posted by Nick at
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072

The ACPI MADT table includes an interrupt source overridden entry for
ACPI SCI:
[236h 0566  1]Subtable Type : 02 
[237h 0567  1]   Length : 0A
[238h 0568  1]  Bus : 00
[239h 0569  1]   Source : 09
[23Ah 0570  4]Interrupt : 0009
[23Eh 0574  2]Flags (decoded below) : 000D
   Polarity : 1
   Trigger Mode : 3

And in DSDT table, we have _PRT method to define PCI interrupts, which
eventually goes to:
Name (PRSA, ResourceTemplate ()
{
IRQ (Level, ActiveLow, Shared, )
{3,4,5,7,9,10,11,12,14,15}
})
Name (PRSB, ResourceTemplate ()
{
IRQ (Level, ActiveLow, Shared, )
{3,4,5,7,9,10,11,12,14,15}
})
Name (PRSC, ResourceTemplate ()
{
IRQ (Level, ActiveLow, Shared, )
{3,4,5,7,9,10,11,12,14,15}
})
Name (PRSD, ResourceTemplate ()
{
IRQ (Level, ActiveLow, Shared, )
{3,4,5,7,9,10,11,12,14,15}
})

According to the MADT and DSDT tables above, IRQ 9 may be used for:
1) ACPI SCI in level, high mode
2) PCI legacy IRQ in level, low mode
So there's a possible conflict in polarity setting for IRQ 9.

Prior to commit cd68f6bd53cf ("x86, irq, acpi: Get rid of special
handling of GSI for ACPI SCI"), ACPI SCI is handled specially and
there's no check for conflicts between ACPI SCI and PCI legagy IRQ.
And it seems that the HyperV hypervisor doesn't make use of the
polarity configuration in IOAPIC entry, so it just works.

Commit cd68f6bd53cf gets rid of the specially handling of ACPI SCI,
and then the pin attribute checking logic discloses the conflicts
between ACPI SCI and PCI legacy IRQ on HyperV virtual machine,
and rejects the request to assign IRQ9 to PCI devices.

Since HyperV doesn't make use of the IOAPIC polarity setting,
add a quirk to enforce ACPI SCI as level, low on HyperV guests,
so IRQ9 could be used for both ACPI SCI and PCI legacy IRQ.

Nick reports the proposed patch fixes the regression as "
  Applied the above proposed patch with the DMI values substituted.
  The tulip driver loaded, and an address was assigned via DHCP.
"
Please refer to following links for more information:
https://bugzilla.kernel.org/show_bug.cgi?id=101301
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1440072

Fixes: cd68f6bd53cf ("x86, irq, acpi: Get rid of special handling of GSI for 
ACPI SCI")
Reported-and-tested-by: Nick Meier 
Cc:  # 3.19
Signed-off-by: Jiang Liu 
---
Hi Thomas,
I have refined the commit message to explain why it works with
the old code.
Thanks!
Gerry
---
 arch/x86/kernel/acpi/boot.c |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index e49ee24da85e..47d95a86d56d 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1308,6 +1308,13 @@ static int __init dmi_ignore_irq0_timer_override(const 
struct dmi_system_id *d)
return 0;
 }
 
+static int __init acpi_force_hyperv_sci_attr(const struct dmi_system_id *d)
+{
+   acpi_sci_flags = ACPI_MADT_POLARITY_ACTIVE_LOW |
+   (acpi_sci_flags & ~ACPI_MADT_POLARITY_MASK);
+   return 0;
+}
+
 /*
  * ACPI offers an alternative platform interface model that removes
  * ACPI hardware requirements for platforms that do not implement
@@ -1458,6 +1465,14 @@ static struct dmi_system_id __initdata 
acpi_dmi_table_late[] = {
 DMI_MATCH(DMI_PRODUCT_NAME, "AMILO PRO V2030"),
 },
 },
+   {
+.callback = acpi_force_hyperv_sci_attr,
+.ident = "HyperV",
+.matches = {
+DMI_MATCH(DMI_SYS_VENDOR, "Microsoft Corporation"),
+DMI_MATCH(DMI_PRODUCT_NAME, "Virtual Machine"),
+},
+},
{}
 };
 
-- 
1.7.10.4

--
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: UniPhier: fix PPI interrupt CPU mask of timer nodes

[Masahiro Yamada]

2015-08-19 14:45 GMT+09:00 Masahiro Yamada :
> This SoC is integrated with 4 Cortex-A9 cores.  The GIC bindings
> says that the bits[15:8] of the 3rd cell of the interrupts property
> represents PPI interrupt CPU mask.  Because the timer interrupts are
> wired to all of the 4 cores, bits[15:8] should be set to 0xf.
>
> Signed-off-by: Masahiro Yamada 

This has been superseded by v2.

-- 
Best Regards
Masahiro Yamada
--
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] ARM: dts: UniPhier: fix PPI interrupt CPU mask of timer nodes

[Masahiro Yamada]

This SoC is integrated with 4 Cortex-A9 cores.  The GIC bindings
document says that the bits[15:8] of the 3rd cell of the interrupts
property represents PPI interrupt CPU mask.  Because the timer
interrupts are wired to all of the 4 cores, bits[15:8] should be set
to 0xf.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Fix git-description

 arch/arm/boot/dts/uniphier-proxstream2.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-proxstream2.dtsi 
b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
index ccf795a..4c7b246 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
+++ b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
@@ -249,14 +249,14 @@
timer@6200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x6200 0x20>;
-   interrupts = <1 11 0x304>;
+   interrupts = <1 11 0xf04>;
clocks = <&arm_timer_clk>;
};
 
timer@6600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x6600 0x20>;
-   interrupts = <1 13 0x304>;
+   interrupts = <1 13 0xf04>;
clocks = <&arm_timer_clk>;
};
 
-- 
1.9.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/

[PATCH] scsi: fcoe: Convert use of __constant_htons to htons

[Vaishali Thakkar]

In little endian cases, the macro htons unfolds to __swab16 which
provides special case for constants. In big endian cases,
__constant_htons and htons expand directly to the same expression.
So, replace __constant_htons with htons with the goal of getting
rid of the definition of __constant_htons completely.

The semantic patch that performs this transformation is as follows:

@@expression x;@@

- __constant_htons(x)
+ htons(x)

Signed-off-by: Vaishali Thakkar 
---
 drivers/scsi/fcoe/fcoe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index ec193a8..d3eb80c 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -364,7 +364,7 @@ static int fcoe_interface_setup(struct fcoe_interface *fcoe,
 * on the ethertype for the given device
 */
fcoe->fcoe_packet_type.func = fcoe_rcv;
-   fcoe->fcoe_packet_type.type = __constant_htons(ETH_P_FCOE);
+   fcoe->fcoe_packet_type.type = htons(ETH_P_FCOE);
fcoe->fcoe_packet_type.dev = netdev;
dev_add_pack(&fcoe->fcoe_packet_type);
 
-- 
1.9.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/

[GIT PULL] target fixes for v4.2-rc7

[Nicholas A. Bellinger]

Hi Linus,

Here are the outstanding target-pending fixes for v4.2-rc7 code.

Please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master

It contains a v4.2-rc specific RCU module unload regression bug-fix, a
long-standing iscsi-target bug-fix for duplicate target_xfer_tags during
NOP processing from Alexei, and two more small REPORT_LUNs emulation
related patches to make Solaris FC host LUN scanning happy from Roland.

There is also one patch not included that allows target-core to limit
the number of fabric driver SGLs per I/O request using residuals, that
is currently required as a work-around for FC hosts which don't honor
EVPD block-limits settings.  At this point, it will most likely become
for-next material.

Thank you,

--nab

Alexei Potashnik (1):
  target/iscsi: Fix double free of a TUR followed by a solicited NOPOUT

Nicholas Bellinger (1):
  target: Perform RCU callback barrier before backend/fabric unload

Roland Dreier (2):
  target: REPORT LUNS should return LUN 0 even for dynamic ACLs
  target: Fix handling of small allocation lengths in REPORT LUNS

 drivers/target/iscsi/iscsi_target.c   |  4 ++--
 drivers/target/target_core_configfs.c |  9 ++-
 drivers/target/target_core_hba.c  | 10 +++-
 drivers/target/target_core_spc.c  | 44 ---
 4 files changed, 44 insertions(+), 23 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] ARM: dts: UniPhier: fix PPI interrupt CPU mask of timer nodes

[Masahiro Yamada]

This SoC is integrated with 4 Cortex-A9 cores.  The GIC bindings
says that the bits[15:8] of the 3rd cell of the interrupts property
represents PPI interrupt CPU mask.  Because the timer interrupts are
wired to all of the 4 cores, bits[15:8] should be set to 0xf.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/boot/dts/uniphier-proxstream2.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/uniphier-proxstream2.dtsi 
b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
index ccf795a..4c7b246 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
+++ b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
@@ -249,14 +249,14 @@
timer@6200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x6200 0x20>;
-   interrupts = <1 11 0x304>;
+   interrupts = <1 11 0xf04>;
clocks = <&arm_timer_clk>;
};
 
timer@6600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x6600 0x20>;
-   interrupts = <1 13 0x304>;
+   interrupts = <1 13 0xf04>;
clocks = <&arm_timer_clk>;
};
 
-- 
1.9.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/

[PATCH] Staging: most: Use NULL instead of zero

[Ronit Halder]

This patch fixes the warning generated by sparse
"Using plain integer as NULL pointer" by using NULL
instead of zero.

Signed-off-by: Ronit halder 
---
 drivers/staging/most/aim-network/networking.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/most/aim-network/networking.c 
b/drivers/staging/most/aim-network/networking.c
index c8ab239..a1e1bce 100644
--- a/drivers/staging/most/aim-network/networking.c
+++ b/drivers/staging/most/aim-network/networking.c
@@ -295,7 +295,7 @@ static void most_net_rm_netdev_safe(struct net_dev_context 
*nd)
 
unregister_netdev(nd->dev);
free_netdev(nd->dev);
-   nd->dev = 0;
+   nd->dev = NULL;
 }
 
 static struct net_dev_context *get_net_dev_context(
-- 
2.4.0.GIT

--
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: fs: out of bounds on stack in iov_iter_advance

[Al Viro]

On Mon, Aug 17, 2015 at 12:18:12PM +0300, Andrey Ryabinin wrote:

> This bug is similar to recently found bug in 9p: 
> http://thread.gmane.org/gmane.linux.kernel/1931799/focus=1936542

Ow.  For those who'd missed that fun: the bug in question had turned out to
be caused by improper reuse of request ids, _not_ in the call chain of
the triggering syscall.

>   if (!retval) {
>   struct iov_iter data = *iter;
>   retval = mapping->a_ops->direct_IO(iocb, &data, pos);
>   }
> 
>   if (retval > 0) {
>   *ppos = pos + retval;
>   iov_iter_advance(iter, retval);
> 
> 
> So either filemap_write_and_wait_range()
Shouldn't - it's supposed to return 0 or -E...

> or mapping->a_ops->direct_IO() returned more
> than 'count'.

Was there DAX involved?  ->direct_IO() in there is blkdev_direct_IO(),
which takes rather different paths in those cases...

> > Also too the file and line number
> > (lib/iov_iter.c:511) are completely useless because of inlining,
> > though that's not kasan's fault.

Might make sense to slap
if (WARN_ON(size > iov_iter_count(i)))
print size and *i
and see if it triggers...
--
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 v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver

[Viresh Kumar]

On 19-08-15, 10:05, Pi-Cheng Chen wrote:
> Mediatek MT8173 is an ARMv8 based quad-core (2*Cortex-A53 and
> 2*Cortex-A72) SoC with duall clusters. For each cluster, two voltage
> inputs, Vproc and Vsram are supplied by two regulators. For the big
> cluster, two regulators come from different PMICs. In this case, when
> scaling voltage inputs of the cluster, the voltages of two regulator
> inputs need to be controlled by software explicitly under the SoC
> specific limitation:
> 
>   100mV < Vsram - Vproc < 200mV
> 
> which is called 'voltage tracking' mechanism. And when scaling the
> frequency of cluster clock input, the input MUX need to be parented to
> another "intermediate" stable PLL first and reparented to the original
> PLL once the original PLL is stable at the target frequency. This patch
> implements those mechanisms to enable CPU DVFS support for Mediatek
> MT8173 SoC.
> 
> Signed-off-by: Pi-Cheng Chen 
> Acked-by: Viresh Kumar 
> ---
> 
> Changes in v7:
> - add of_machine_is_compatible() check to be multiplatform friendly

Looks fine, thanks.

-- 
viresh
--
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: kexec, x86: Need a new e820 type support for kexec

[Toshi Kani]

On 8/18/2015 8:53 PM, Baoquan He wrote:

On 08/18/15 at 09:01am, Toshi Kani wrote:

On Tue, 2015-08-18 at 16:53 +0800, Baoquan He wrote:

Rethink it again, maybe it's better to pass PMEM as PRAM to kdump
kernel if user really want to use memmap way by specifying
--pass-memmap-cmdline. Then I need add the PMEM and PRAM checking here
you pointed out. Will repost with them.

No, you should not report PMEM as PRAM.  They are different things.  The
kdump kernel does not need to support memmap cmdline for PMEM, as the
regular kernel does not -- memmap cmdline cannot emulate PMEM.

OK. Then it will be wrong if people intend to specify
--pass-memmap-cmdline. There might be 3 ways to fix this:

1) add PMEM support in kernel. memmap cmdline is not only used for
emulating, but for kexec/kdump using.

2) Delete --pass-memmap-cmdline option in kexec-tools since people
rarely use it.

3) Add a note in kexec-tools that option --pass-memmap-cmdline can't
work together with PMEM, people should not use it.


3) is fine, and I do not think we need a note either.  It does not make 
sense to add an memmap cmdline for PMEM since PMEM ranges require ACPI 
NFIT table.


Thanks,
-Toshi

--
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] selftests/zram: Adding zram tests

[Naresh Kamboju]

Hi Shuah Khan,

On 18 August 2015 at 03:14, Shuah Khan  wrote:
> On 08/17/2015 02:39 PM, naresh.kamb...@linaro.org wrote:
>> From: Naresh Kamboju 
>
> Are you using git send-email to send this patch? Not sure why
> I see this From and the one below.


I do use git send-email to send this patch.
From: Naresh is generated from git send-patch.

>
>>
>> zram.sh: sanity check of CONFIG_ZRAM and run zram01.sh and zram02.sh
>> zram01.sh: creates general purpose ram disks with different filesystems
>> zram02.sh: creates block device for swap
>> zram_lib.sh: create library with initialization/cleanup functions
>> README: ZRAM introduction and Kconfig required.
>> Makefile: To run zram tests
>
> Could please write a proper commit message instead of list of files
> and description.

Done and sent v3 patch.

>
>>
>> From: Alexey Kodanev 
>
> Same comment here.

The original author of this patch is "Alexey Kodanev". who submitted
patch on LTP.
I have updated and modified to fit into selftests.
That is the reason for adding From: Alexey Kodanev again in commit message.
However, I have added him in CC for v3 patch set.

Best regards
Naresh Kamboju

>
>> CC: Shuah Khan 
>> CC: Tyler Baker 
>> CC: Milosz Wasilewski 
>> Signed-off-by: Naresh Kamboju 
>> Signed-off-by: Alexey Kodanev 
>> ---
>>  tools/testing/selftests/Makefile |   1 +
>>  tools/testing/selftests/zram/Makefile|  12 ++
>>  tools/testing/selftests/zram/README  |  40 ++
>>  tools/testing/selftests/zram/zram.sh |  22 +++
>>  tools/testing/selftests/zram/zram01.sh   |  98 ++
>>  tools/testing/selftests/zram/zram02.sh   |  53 
>>  tools/testing/selftests/zram/zram_lib.sh | 222 
>> +++
>>  7 files changed, 448 insertions(+)
>>  create mode 100644 tools/testing/selftests/zram/Makefile
>>  create mode 100644 tools/testing/selftests/zram/README
>>  create mode 100755 tools/testing/selftests/zram/zram.sh
>>  create mode 100755 tools/testing/selftests/zram/zram01.sh
>>  create mode 100755 tools/testing/selftests/zram/zram02.sh
>>  create mode 100755 tools/testing/selftests/zram/zram_lib.sh
>>
>> diff --git a/tools/testing/selftests/Makefile 
>> b/tools/testing/selftests/Makefile
>> index 24ae9e8..9763dd9 100644
>> --- a/tools/testing/selftests/Makefile
>> +++ b/tools/testing/selftests/Makefile
>> @@ -22,6 +22,7 @@ endif
>>  TARGETS += user
>>  TARGETS += vm
>>  TARGETS += x86
>> +TARGETS += zram
>>  #Please keep the TARGETS list alphabetically sorted
>>  # Run "make quicktest=1 run_tests" or
>>  # "make quicktest=1 kselftest from top level Makefile
>> diff --git a/tools/testing/selftests/zram/Makefile 
>> b/tools/testing/selftests/zram/Makefile
>> new file mode 100644
>> index 000..ec45513
>> --- /dev/null
>> +++ b/tools/testing/selftests/zram/Makefile
>> @@ -0,0 +1,12 @@
>> +all:
>> +
>> +TEST_PROGS := zram.sh
>> +TEST_FILES := zram01.sh zram02.sh zram_lib.sh
>> +
>> +include ../lib.mk
>> +
>> +run_tests:
>> + @/bin/bash ./zram.sh
>> +
>> +clean:
>> + $(RM) err.log
>> diff --git a/tools/testing/selftests/zram/README 
>> b/tools/testing/selftests/zram/README
>> new file mode 100644
>> index 000..eb17917
>> --- /dev/null
>> +++ b/tools/testing/selftests/zram/README
>> @@ -0,0 +1,40 @@
>> +zram: Compressed RAM based block devices
>> +
>> +* Introduction
>> +
>> +The zram module creates RAM based block devices named /dev/zram
>> +( = 0, 1, ...). Pages written to these disks are compressed and stored
>> +in memory itself. These disks allow very fast I/O and compression provides
>> +good amounts of memory savings. Some of the usecases include /tmp storage,
>> +use as swap disks, various caches under /var and maybe many more :)
>> +
>> +Statistics for individual zram devices are exported through sysfs nodes at
>> +/sys/block/zram/
>> +
>> +Kconfig required:
>> +CONFIG_ZRAM=y
>> +CONFIG_ZRAM_LZ4_COMPRESS=y
>> +CONFIG_ZPOOL=y
>> +CONFIG_ZSMALLOC=y
>> +
>> +ZRAM Testcases
>> +--
>> +zram_lib.sh: create library with initialization/cleanup functions
>> +zram.sh: For sanity check of CONFIG_ZRAM and to run zram01 and zram02
>> +
>> +Two functional tests: zram01 and zram02:
>> +zram01.sh: creates general purpose ram disks with ext4 filesystems
>> +zram02.sh: creates block device for swap
>> +
>> +Commands required for testing:
>> + - bc
>> + - dd
>> + - free
>> + - awk
>> + - mkswap
>> + - swapon
>> + - swapoff
>> + - mkfs/ mkfs.ext4
>> +
>> +For more information please refer:
>> +kernel-source-tree/Documentation/blockdev/zram.txt
>> diff --git a/tools/testing/selftests/zram/zram.sh 
>> b/tools/testing/selftests/zram/zram.sh
>> new file mode 100755
>> index 000..be219fd
>> --- /dev/null
>> +++ b/tools/testing/selftests/zram/zram.sh
>> @@ -0,0 +1,22 @@
>> +#!/bin/bash
>> +TCID="zram.sh"
>> +
>> +run_zram () {
>> +echo ""
>> +echo "running zram tests"
>> +echo ""
>> +./zram01.sh
>> +./zram02.sh
>> +}
>> +

Re: [PATCH 2/2] cxl: add set/get private data to context struct

[Michael Ellerman]

On Wed, 2015-08-19 at 15:12 +1000, Ian Munsie wrote:
> Excerpts from Michael Ellerman's message of 2015-08-19 14:49:30 +1000:
> > Do we really need the accessors? They don't buy anything I can see over just
> > using ctx->priv directly.
> 
> The reasoning there is because we don't currently expose the contents of
> stuct cxl_context to afu drivers, rather they just treat it as an opaque
> type.
> 
> We could potentially change this to expose the details, but there's a
> lot of junk in there that's just internal details of the cxl driver that
> isn't of interest to an afu driver that I'd rather not expose.
> 
> We also already have another accessor function (cxl_process_element) in
> the api, so it's not out of place.
> 
> FWIW I'm not opposed to changing how this api works if it ultimately
> makes things better, but I want to wait until the cxlflash superpipe
> support is merged so any patches that change the api can change it at
> the same time.

OK. I saw struct cxl_context in cxl.h and figured it was public, but it's in
drivers/misc/cxl/cxl.h, so yes other drivers have no business poking in there,
even though they *could*.

So that's fine.

cheers


--
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: gadget: f_uac1: Convert use of __constant_cpu_to_le16 to cpu_to_le16

[Vaishali Thakkar]

In big endian cases, macro cpu_to_le16 unfolds to __swab16 which
provides special case for constants. In little endian cases,
__constant_cpu_to_le16 and cpu_to_le16 expand directly to the
same expression. So, replace __constant_cpu_to_le16 with
cpu_to_le16 with the goal of getting rid of the definition of
__constant_cpu_to_le16 completely.

The semantic patch that performs this transformation is as follows:

@@expression x;@@

- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)

Signed-off-by: Vaishali Thakkar 
---
 drivers/usb/gadget/function/f_uac1.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/function/f_uac1.c 
b/drivers/usb/gadget/function/f_uac1.c
index 7856b33..5aa8d8a 100644
--- a/drivers/usb/gadget/function/f_uac1.c
+++ b/drivers/usb/gadget/function/f_uac1.c
@@ -57,8 +57,8 @@ static struct uac1_ac_header_descriptor_1 ac_header_desc = {
.bLength =  UAC_DT_AC_HEADER_LENGTH,
.bDescriptorType =  USB_DT_CS_INTERFACE,
.bDescriptorSubtype =   UAC_HEADER,
-   .bcdADC =   __constant_cpu_to_le16(0x0100),
-   .wTotalLength = __constant_cpu_to_le16(UAC_DT_TOTAL_LENGTH),
+   .bcdADC =   cpu_to_le16(0x0100),
+   .wTotalLength = cpu_to_le16(UAC_DT_TOTAL_LENGTH),
.bInCollection =F_AUDIO_NUM_INTERFACES,
.baInterfaceNr = {
/* Interface number of the first AudioStream interface */
@@ -186,7 +186,7 @@ static struct uac_iso_endpoint_descriptor as_iso_out_desc = 
{
.bDescriptorSubtype =   UAC_EP_GENERAL,
.bmAttributes = 1,
.bLockDelayUnits =  1,
-   .wLockDelay =   __constant_cpu_to_le16(1),
+   .wLockDelay =   cpu_to_le16(1),
 };
 
 static struct usb_descriptor_header *f_audio_desc[] = {
-- 
1.9.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/

Re: [PATCH 1/2] cxl: Add mechanism for delivering AFU driver specific events

[Michael Ellerman]

On Wed, 2015-08-19 at 14:19 +1000, Ian Munsie wrote:
> From: Ian Munsie 
> 
> This adds an afu_driver_ops structure with event_pending and
> deliver_event callbacks. An AFU driver can fill these out and associate
> it with a context to enable passing custom AFU specific events to
> userspace.

What's an AFU driver? Give me an example.

> The cxl driver will call event_pending() during poll, select, read, etc.
> calls to check if an AFU driver specific event is pending, and will call
> deliver_event() to deliver that event. This way, the cxl driver takes
> care of all the usual locking semantics around these calls and handles
> all the generic cxl events, so that the AFU driver only needs to worry
> about it's own events.
> 
> The deliver_event() call is passed a struct cxl_event buffer to fill in.
> The header will already be filled in for an AFU driver event, and the
> AFU driver is expected to expand the header.size as necessary (up to
> max_size, defined by struct cxl_event_afu_driver_reserved) and fill out
> it's own information.
> 
> Conflicts between AFU specific events are not expected, due to the fact
> that each AFU specific driver has it's own mechanism to deliver an AFU
> file descriptor to userspace.

I don't grok this bit.

> Signed-off-by: Ian Munsie 
> ---
>  drivers/misc/cxl/Kconfig |  5 +
>  drivers/misc/cxl/api.c   |  7 +++
>  drivers/misc/cxl/cxl.h   |  6 +-
>  drivers/misc/cxl/file.c  | 37 +++--
>  include/misc/cxl.h   | 29 +
>  include/uapi/misc/cxl.h  | 13 +
>  6 files changed, 86 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig
> index 8756d06..560412c 100644
> --- a/drivers/misc/cxl/Kconfig
> +++ b/drivers/misc/cxl/Kconfig
> @@ -15,12 +15,17 @@ config CXL_EEH
>   bool
>   default n
>  
> +config CXL_AFU_DRIVER_OPS
> + bool
> + default n
> +
>  config CXL
>   tristate "Support for IBM Coherent Accelerators (CXL)"
>   depends on PPC_POWERNV && PCI_MSI && EEH
>   select CXL_BASE
>   select CXL_KERNEL_API
>   select CXL_EEH
> + select CXL_AFU_DRIVER_OPS
>   default m
>   help
> Select this option to enable driver support for IBM Coherent
> diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
> index 6a768a9..e0f0c78 100644
> --- a/drivers/misc/cxl/api.c
> +++ b/drivers/misc/cxl/api.c
> @@ -267,6 +267,13 @@ struct cxl_context *cxl_fops_get_context(struct file 
> *file)
>  }
>  EXPORT_SYMBOL_GPL(cxl_fops_get_context);
>  
> +void cxl_set_driver_ops(struct cxl_context *ctx,
> + struct cxl_afu_driver_ops *ops)
> +{
> + ctx->afu_driver_ops = ops;
> +}
> +EXPORT_SYMBOL_GPL(cxl_set_driver_ops);

This is pointless.

BUT, it wouldn't be if you actually checked the ops. Which you should do,
because then later you can avoid checking them on every event.

IIUI you should never have one op set but not the other, so you check in here
that both are set and error out otherwise.

Then in afu_read() you can change this:

> + if (ctx->afu_driver_ops
> + && ctx->afu_driver_ops->event_pending
> + && ctx->afu_driver_ops->deliver_event
> + && ctx->afu_driver_ops->event_pending(ctx)) {

to:

> + if (ctx->afu_driver_ops && ctx->afu_driver_ops->event_pending(ctx)) {


> diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
> index 6f53866..30e44a8 100644
> --- a/drivers/misc/cxl/cxl.h
> +++ b/drivers/misc/cxl/cxl.h
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  
>  extern uint cxl_verbose;
> @@ -34,7 +35,7 @@ extern uint cxl_verbose;
>   * Bump version each time a user API change is made, whether it is
>   * backwards compatible ot not.
>   */
> -#define CXL_API_VERSION 1
> +#define CXL_API_VERSION 2

I'm not clear on why we're bumping the API version?

Isn't this purely about in-kernel drivers?

I see below you're touching the uapi header, so I guess it's that simple. But
if you can explain it better that would be great.

>  #define CXL_API_VERSION_COMPATIBLE 1
>  
>  /*
> @@ -462,6 +463,9 @@ struct cxl_context {
>   bool pending_fault;
>   bool pending_afu_err;
>  
> + /* Used by AFU drivers for driver specific event delivery */
> + struct cxl_afu_driver_ops *afu_driver_ops;
> +
>   struct rcu_head rcu;
>  };
>  
> diff --git a/drivers/misc/cxl/file.c b/drivers/misc/cxl/file.c
> index 57bdb47..2ebaca3 100644
> --- a/drivers/misc/cxl/file.c
> +++ b/drivers/misc/cxl/file.c
> @@ -279,6 +279,22 @@ int afu_mmap(struct file *file, struct vm_area_struct 
> *vm)
>   return cxl_context_iomap(ctx, vm);
>  }
>  
> +static inline int _ctx_event_pending(struct cxl_context *ctx)

Why isn't this returning bool?

> +{
> + bool afu_driver_event_pending = false;
> +
> + if (ctx->afu_driver_ops && ctx->afu_driver_ops->event_pending)
> + afu_driver_event_pen

Re: [PATCH v3 22/51] PCI: Add alt_size allocation support

[Yinghai Lu]

On Mon, Aug 17, 2015 at 5:03 PM, Bjorn Helgaas  wrote:
> On Mon, Jul 27, 2015 at 04:29:40PM -0700, Yinghai Lu wrote:
>> On system with several pcie switches, BIOS allocate very tight resources
>> to the bridge bar, and it is not aligned to min_align as kernel allocation
>> code.
>
> I can't parse this.

BIOS allocate resource in different way.

kernel is trying to find smallest align (min_align) and use it to get
aligned min_size.

>
>> For example:
>>   02:03.0---0c:00.0---0d:04.0---18:00.0
>> 18:00.0 need 0x1000, and 0x0001.
>> BIOS only allocate 0x1010 to 0d:04.0 and above bridges.
>
> Do you mean the BIOS only allocated 0x1001?

I can not find the exact bus layout on hand. only one similar ...

23 13:15:49  kernel: pci_bus :10: scanning bus
Jun 23 13:15:49  kernel: pci :10:00.0: [:] type 00 class 0x028000
Jun 23 13:15:49  kernel: pci :10:00.0: reg 0x10: [mem
0xb000-0xbfff 64bit pref]
Jun 23 13:15:49  kernel: pci :10:00.0: reg 0x18: [mem
0xc000-0xc000 64bit pref]
Jun 23 13:15:49  kernel: pci_bus :10: fixups for bus
Jun 23 13:15:49  kernel: pci :05:04.0: PCI bridge to [bus 10-17]
Jun 23 13:15:49  kernel: pci :05:04.0:   bridge window [mem
0xb000-0xc00f]
Jun 23 13:15:49  kernel: pci_bus :10: bus scan returning with max=10

so device is using 0x1000 and 0x0001
and bridge is 0x1010

As the bridge MMIO need to be aligned to 1M.

>
>> Later after using /sys/bus/pci/devices/:0c:00.0/remove to remove 0c:00.0,
>> rescan with /sys/bus/pci/rescan can not allocate 0x1800 to 0c:00.0.
>>
>> another example:
>> 00:1c.0-[02-21]00.0-[03-21]--+-01.0-[04-12]00.0-[05-12]19.0-[06-12]00.0
>>  +-05.0-[13]--
>>  
>> +-07.0-[14-20]00.0-[15-20]--+-08.0-[16]--+-00.0
>>  |   |   
>>  \-00.1
>>  |   
>> +-14.0-[17]00.0
>>  |   
>> \-19.0-[18-20]00.0
>>  \-09.0-[21]--
>> 06:00.0 need 0x400 and 0x80.
>> BIOS only allocate 0x480 to 05:19.0 and 04:00.0.
>> when 05:19.0 get removed via /sys/bus/pci/devices/:05:19.0/remove,
>> rescan with /sys/bus/pci/rescan will fail.
>>  pci :05:19.0: BAR 14: no space for [mem size 0x0600]
>>  pci :05:19.0: BAR 14: failed to assign [mem size 0x0600]
>>  pci :06:00.0: BAR 2: no space for [mem size 0x0400 64bit]
>>  pci :06:00.0: BAR 2: failed to assign [mem size 0x0400 64bit]
>>  pci :06:00.0: BAR 0: no space for [mem size 0x0080]
>>  pci :06:00.0: BAR 0: failed to assign [mem size 0x0080]
>> current code try to use align 0x200 and size 0x600, but parent
>> bridge only have 0x480.
>
> I *think* you're saying:
>   - BIOS assigned space for device X
>   - We remove X via sysfs
>   - We rescan via sysfs and discover X
>   - We try to assign space for X
>   - We fail because we don't use the same algorithm as BIOS did
>
> If there is an optimal way to assign space for an arbitrary number of
> BARs, we could just adopt it.  I don't know what that is, and I don't
> know whether an optimal algorithm exists even in principle.
>
> If there is no single optimal algorithm, there will always be cases where
> we fail because we use a different algorithm than the firmware did.

That is what this patch try to do.

alt_size solution that is preferring smaller size and big alignment.

Use it together with min_align solution that is used in kernel.

>
>> Introduce alt_align/alt_size and store them in realloc list in addition
>> to addon info, and will try it after min_align/min_size allocation fails.
>
> What does "alt" mean?
>

alternative
--
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] usbip: vhci_hcd: Convert use of __constant_cpu_to_le16 to cpu_to_le16

[Vaishali Thakkar]

In big endian cases, macro cpu_to_le16 unfolds to __swab16 which
provides special case for constants. In little endian cases,
__constant_cpu_to_le16 and cpu_to_le16 expand directly to the
same expression. So, replace __constant_cpu_to_le16 with
cpu_to_le16 with the goal of getting rid of the definition of
__constant_cpu_to_le16 completely.

The semantic patch that performs this transformation is as follows:

@@expression x;@@

- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)

Signed-off-by: Vaishali Thakkar 
---
 drivers/usb/usbip/vhci_hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index e9ef1ec..42c8231 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -218,7 +218,7 @@ static inline void hub_descriptor(struct usb_hub_descriptor 
*desc)
memset(desc, 0, sizeof(*desc));
desc->bDescriptorType = USB_DT_HUB;
desc->bDescLength = 9;
-   desc->wHubCharacteristics = __constant_cpu_to_le16(
+   desc->wHubCharacteristics = cpu_to_le16(
HUB_CHAR_INDV_PORT_LPSM | HUB_CHAR_COMMON_OCPM);
desc->bNbrPorts = VHCI_NPORTS;
desc->u.hs.DeviceRemovable[0] = 0xff;
-- 
1.9.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/

Re: [PATCH 2/2] cxl: add set/get private data to context struct

[Ian Munsie]

Excerpts from Michael Ellerman's message of 2015-08-19 14:49:30 +1000:
> Do we really need the accessors? They don't buy anything I can see over just
> using ctx->priv directly.

The reasoning there is because we don't currently expose the contents of
stuct cxl_context to afu drivers, rather they just treat it as an opaque
type.

We could potentially change this to expose the details, but there's a
lot of junk in there that's just internal details of the cxl driver that
isn't of interest to an afu driver that I'd rather not expose.

We also already have another accessor function (cxl_process_element) in
the api, so it's not out of place.

FWIW I'm not opposed to changing how this api works if it ultimately
makes things better, but I want to wait until the cxlflash superpipe
support is merged so any patches that change the api can change it at
the same time.

Cheers,
-Ian

--
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 1/5] input: touchscreen: add imx6ul_tsc driver support

[Dmitry Torokhov]

Hi Haibo,

On Tue, Jul 28, 2015 at 05:58:37PM +0800, Haibo Chen wrote:
> Freescale i.MX6UL contains a internal touchscreen controller,
> this patch add a driver to support this controller.
> 

This looks pretty reasonable; just a few comments below.

> Signed-off-by: Haibo Chen 
> ---
>  drivers/input/touchscreen/Kconfig  |  12 +
>  drivers/input/touchscreen/Makefile |   1 +
>  drivers/input/touchscreen/imx6ul_tsc.c | 504 
> +
>  3 files changed, 517 insertions(+)
>  create mode 100644 drivers/input/touchscreen/imx6ul_tsc.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 5b272ba..32c300d 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -479,6 +479,18 @@ config TOUCHSCREEN_MTOUCH
> To compile this driver as a module, choose M here: the
> module will be called mtouch.
>  
> +config TOUCHSCREEN_IMX6UL_TSC
> + tristate "Freescale i.MX6UL touchscreen controller"
> + depends on OF
> + help
> +   Say Y here if you have a Freescale i.MX6UL, and want to
> +   use the internal touchscreen controller.
> +
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   moduel will be called imx6ul_tsc.
> +
>  config TOUCHSCREEN_INEXIO
>   tristate "iNexio serial touchscreens"
>   select SERIO
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index c85aae2..9379b32 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_TOUCHSCREEN_EGALAX)+= egalax_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_FUJITSU)+= fujitsu_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_GOODIX) += goodix.o
>  obj-$(CONFIG_TOUCHSCREEN_ILI210X)+= ili210x.o
> +obj-$(CONFIG_TOUCHSCREEN_IMX6UL_TSC) += imx6ul_tsc.o
>  obj-$(CONFIG_TOUCHSCREEN_INEXIO) += inexio.o
>  obj-$(CONFIG_TOUCHSCREEN_INTEL_MID)  += intel-mid-touch.o
>  obj-$(CONFIG_TOUCHSCREEN_IPROC)  += bcm_iproc_tsc.o
> diff --git a/drivers/input/touchscreen/imx6ul_tsc.c 
> b/drivers/input/touchscreen/imx6ul_tsc.c
> new file mode 100644
> index 000..807f1db
> --- /dev/null
> +++ b/drivers/input/touchscreen/imx6ul_tsc.c
> @@ -0,0 +1,504 @@
> +/*
> + * Freescale i.MX6UL touchscreen controller driver
> + *
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

I do not think you need of_irq and of_device.

> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* ADC configuration registers field define */
> +#define ADC_AIEN (0x1 << 7)
> +#define ADC_CONV_DISABLE 0x1F
> +#define ADC_CAL  (0x1 << 7)
> +#define ADC_CALF 0x2
> +#define ADC_12BIT_MODE   (0x2 << 2)
> +#define ADC_IPG_CLK  0x00
> +#define ADC_CLK_DIV_8(0x03 << 5)
> +#define ADC_SHORT_SAMPLE_MODE(0x0 << 4)
> +#define ADC_HARDWARE_TRIGGER (0x1 << 13)
> +#define SELECT_CHANNEL_4 0x04
> +#define SELECT_CHANNEL_1 0x01
> +#define DISABLE_CONVERSION_INT   (0x0 << 7)
> +
> +/* ADC registers */
> +#define REG_ADC_HC0  0x00
> +#define REG_ADC_HC1  0x04
> +#define REG_ADC_HC2  0x08
> +#define REG_ADC_HC3  0x0C
> +#define REG_ADC_HC4  0x10
> +#define REG_ADC_HS   0x14
> +#define REG_ADC_R0   0x18
> +#define REG_ADC_CFG  0x2C
> +#define REG_ADC_GC   0x30
> +#define REG_ADC_GS   0x34
> +
> +#define ADC_TIMEOUT  msecs_to_jiffies(100)
> +
> +/* TSC registers */
> +#define REG_TSC_BASIC_SETING 0x00
> +#define REG_TSC_PRE_CHARGE_TIME  0x10
> +#define REG_TSC_FLOW_CONTROL 0x20
> +#define REG_TSC_MEASURE_VALUE0x30
> +#define REG_TSC_INT_EN   0x40
> +#define REG_TSC_INT_SIG_EN   0x50
> +#define REG_TSC_INT_STATUS   0x60
> +#define REG_TSC_DEBUG_MODE   0x70
> +#define REG_TSC_DEBUG_MODE2  0x80
> +
> +/* TSC configuration registers field define */
> +#define DETECT_4_WIRE_MODE   (0x0 << 4)
> +#define AUTO_MEASURE 0x1
> +#define MEASURE_SIGNAL   0x1
> +#define DETECT_SIGNAL(0x1 << 4)
> +#define VALID_SIGNAL (0x1 << 8)
> +#define MEASURE_INT_EN   0x1
> +#define MEASURE_SIG_EN   0x1
> +#define VALID_SIG_EN (0x1 << 8)
> +#define DE_GLITCH_2  (0x2 << 29)
> +#define START_SENSE  (0x1 << 12)
> +#define TSC_DISABLE  (0x1 << 16)
> +#define DETECT_MODE  0x2
> +
> +struct imx6ul_tsc {
> + struct device *dev;
> + struct input_dev *input;
>

Re: [RFC 0/2] drm/dsi: DSI for devices with different control bus

[Archit Taneja]

Hi,

On 06/30/2015 10:54 AM, Archit Taneja wrote:

We are currently restricted when it comes to supporting DSI on devices
that have a non-DSI control bus. For example, DSI encoder chips are
available in the market that are configured via i2c. Configuring their
registers via DSI bus is either optional or not available at all.

These devices still need to pass DSI parameters (data lanes, mode flags
etc) to the DSI host they are connected to. We don't have a way to do
that at the moment.

The method presented in these patches is to provide an API to create a
'dummy' mipi_dsi_device. This device is populated with the desired DSI
params, which are passed on to the host via mipi_dsi_attach().

This method will require the device driver to get a phandle to the DSI
host since there is no parent-child relation between the two.

Is there a better way to do this? Please let me know!


Any comments on this?

Archit



Archit Taneja (2):
   drm/dsi: Create dummy DSI devices
   drm/dsi: Get DSI host by DT device node

  drivers/gpu/drm/drm_mipi_dsi.c | 108 -
  include/drm/drm_mipi_dsi.h |   4 ++
  2 files changed, 110 insertions(+), 2 deletions(-)



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] qeth: Convert use of __constant_htons to htons

[Vaishali Thakkar]

On Fri, Jun 12, 2015 at 1:12 PM, Ursula Braun  wrote:
> Thanks Vaishali. I have added your patch to our local kernel git, and
> will submit it within a following upstream shipment.

Hi Ursula,

Can you please tell me when this patch is going to be added in
linux-next? I don't see them in linux-next and they are blocking
removal of these macros.

Do inform me in case there is any problem with this patch.

Thank You.

> Regards, Ursula Braun
>
> On Wed, 2015-06-10 at 16:22 +0530, Vaishali Thakkar wrote:
>> In little endian cases, the macro htons unfolds to __swab16 which
>> provides special case for constants. In big endian cases,
>> __constant_htons and htons expand directly to the same expression.
>> So, replace __constant_htons with htons with the goal of getting
>> rid of the definition of __constant_htons completely.
>>
>> The semantic patch that performs this transformation is as follows:
>>
>> @@expression x;@@
>>
>> - __constant_htons(x)
>> + htons(x)
>>
>> Signed-off-by: Vaishali Thakkar 
>> ---
>>  drivers/s390/net/qeth_l2_main.c | 2 +-
>>  drivers/s390/net/qeth_l3_main.c | 6 +++---
>>  2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/s390/net/qeth_l2_main.c 
>> b/drivers/s390/net/qeth_l2_main.c
>> index 0ea0869..a124f59 100644
>> --- a/drivers/s390/net/qeth_l2_main.c
>> +++ b/drivers/s390/net/qeth_l2_main.c
>> @@ -272,7 +272,7 @@ static void qeth_l2_fill_header(struct qeth_card *card, 
>> struct qeth_hdr *hdr,
>>   /* VSWITCH relies on the VLAN
>>* information to be present in
>>* the QDIO header */
>> - if (veth->h_vlan_proto == __constant_htons(ETH_P_8021Q)) {
>> + if (veth->h_vlan_proto == htons(ETH_P_8021Q)) {
>>   hdr->hdr.l2.flags[2] |= QETH_LAYER2_FLAG_VLAN;
>>   hdr->hdr.l2.vlan_id = ntohs(veth->h_vlan_TCI);
>>   }
>> diff --git a/drivers/s390/net/qeth_l3_main.c 
>> b/drivers/s390/net/qeth_l3_main.c
>> index 04e42c6..bd6b5a9 100644
>> --- a/drivers/s390/net/qeth_l3_main.c
>> +++ b/drivers/s390/net/qeth_l3_main.c
>> @@ -1887,13 +1887,13 @@ static inline int qeth_l3_rebuild_skb(struct 
>> qeth_card *card,
>>   case QETH_CAST_MULTICAST:
>>   switch (prot) {
>>  #ifdef CONFIG_QETH_IPV6
>> - case __constant_htons(ETH_P_IPV6):
>> + case htons(ETH_P_IPV6):
>>   ndisc_mc_map((struct in6_addr *)
>>skb->data + 24,
>>tg_addr, card->dev, 0);
>>   break;
>>  #endif
>> - case __constant_htons(ETH_P_IP):
>> + case htons(ETH_P_IP):
>>   ip_hdr = (struct iphdr *)skb->data;
>>   ip_eth_mc_map(ip_hdr->daddr, tg_addr);
>>   break;
>> @@ -3015,7 +3015,7 @@ static int qeth_l3_hard_start_xmit(struct sk_buff 
>> *skb, struct net_device *dev)
>>   skb_copy_to_linear_data_offset(new_skb, 8,
>>   new_skb->data + 12, 4);
>>   tag = (u16 *)(new_skb->data + 12);
>> - *tag = __constant_htons(ETH_P_8021Q);
>> + *tag = htons(ETH_P_8021Q);
>>   *(tag + 1) = htons(skb_vlan_tag_get(new_skb));
>>   }
>>   }
>
>



-- 
Vaishali
--
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 v4 2/5] mtd: nand: Qualcomm NAND controller driver

[Archit Taneja]

The Qualcomm NAND controller is found in SoCs like IPQ806x, MSM7xx,
MDM9x15 series.

It exists as a sub block inside the IPs EBI2 (External Bus Interface 2)
and QPIC (Qualcomm Parallel Interface Controller). These IPs provide a
broader interface for external slow peripheral devices such as LCD and
NAND/NOR flash memory or SRAM like interfaces.

We add support for the NAND controller found within EBI2. For the SoCs
of our interest, we only use the NAND controller within EBI2. Therefore,
it's safe for us to assume that the NAND controller is a standalone block
within the SoC.

The controller supports 512B, 2kB, 4kB and 8kB page 8-bit and 16-bit NAND
flash devices. It contains a HW ECC block that supports BCH ECC (4, 8 and
16 bit correction/step) and RS ECC(4 bit correction/step) that covers main
and spare data. The controller contains an internal 512 byte page buffer
to which we read/write via DMA. The EBI2 type NAND controller uses ADM DMA
for register read/write and data transfers. The controller performs page
reads and writes at a codeword/step level of 512 bytes. It can support up
to 2 external chips of different configurations.

The driver prepares register read and write configuration descriptors for
each codeword, followed by data descriptors to read or write data from the
controller's internal buffer. It uses a single ADM DMA channel that we get
via dmaengine API. The controller requires 2 ADM CRCIs for command and
data flow control. These are passed via DT.

The ecc layout used by the controller is syndrome like, but we can't use
the standard syndrome ecc ops because of several reasons. First, the amount
of data bytes covered by ecc isn't same in each step. Second, writing to
free oob space requires us writing to the entire step in which the oob
lies. This forces us to create our own ecc ops.

One more difference is how the controller accesses the bad block marker.
The controller ignores reading the marker when ECC is enabled. ECC needs
to be explicity disabled to read or write to the bad block marker. For
this reason, we use the newly created flag NAND_BBT_ACCESS_BBM_RAW to
read the factory provided bad block markers.

v4:
- Shrink submit_descs
- add desc list node at the end of dma_prep_desc
- Endianness and warning fixes

Signed-off-by: Stephen Boyd 

v3:
- Refactor dma functions for maximum reuse
- Use dma_slave_confing on stack
- optimize and clean upempty_page_fixup using memchr_inv
- ensure portability with dma register reads using le32_* funcs
- use NAND_USE_BOUNCE_BUFFER instead of doing it ourselves
- fix handling of return values of dmaengine funcs
- constify wherever possible
- Remove dependency on ADM DMA in Kconfig
- Misc fixes and clean ups

v2:
- Use new BBT flag that allows us to read BBM in raw mode
- reduce memcpy-s in the driver
- some refactor and clean ups because of above changes

Reviewed-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
 drivers/mtd/nand/Kconfig  |7 +
 drivers/mtd/nand/Makefile |1 +
 drivers/mtd/nand/qcom_nandc.c | 1910 +
 3 files changed, 1918 insertions(+)
 create mode 100644 drivers/mtd/nand/qcom_nandc.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 5b2806a..6085b8a 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -538,4 +538,11 @@ config MTD_NAND_HISI504
help
  Enables support for NAND controller on Hisilicon SoC Hip04.
 
+config MTD_NAND_QCOM
+   tristate "Support for NAND on QCOM SoCs"
+   depends on ARCH_QCOM
+   help
+ Enables support for NAND flash chips on SoCs containing the EBI2 NAND
+ controller. This controller is found on IPQ806x SoC.
+
 endif # MTD_NAND
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 1f897ec..87b6a1d 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -53,5 +53,6 @@ obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)  += bcm47xxnflash/
 obj-$(CONFIG_MTD_NAND_SUNXI)   += sunxi_nand.o
 obj-$(CONFIG_MTD_NAND_HISI504) += hisi504_nand.o
 obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/
+obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o
 
 nand-objs := nand_base.o nand_bbt.o nand_timings.o
diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
new file mode 100644
index 000..2337731
--- /dev/null
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -0,0 +1,1910 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#i

[PATCH v2] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

[Dan Williams]

We currently register a platform device for e820 type-12 memory and
register a nvdimm bus beneath it.  Registering the platform device
triggers the device-core machinery to probe for a driver, but that
search currently comes up empty.  Building the nvdimm-bus registration
into the e820_pmem platform device registration in this way forces
libnvdimm to be built-in.  Instead, convert the built-in portion of
CONFIG_X86_PMEM_LEGACY to simply register a platform device and move the
rest of the logic to the driver for e820_pmem, for the following
reasons:

1/ Letting e820_pmem support be a module allows building and testing
   libnvdimm.ko changes without rebooting

2/ All the normal policy around modules can be applied to e820_pmem
   (unbind to disable and/or blacklisting the module from loading by
   default)

3/ Moving the driver to a generic location and converting it to scan
   "iomem_resource" rather than "e820.map" means any other architecture can
   take advantage of this simple nvdimm resource discovery mechanism by
   registering a resource named "Persistent Memory (legacy)"

Cc: Christoph Hellwig 
Signed-off-by: Dan Williams 
---

No code changes since v1, just a revised changelog.

 arch/x86/Kconfig |6 ++-
 arch/x86/include/uapi/asm/e820.h |2 -
 arch/x86/kernel/Makefile |2 -
 arch/x86/kernel/pmem.c   |   79 ---
 drivers/nvdimm/Makefile  |3 +
 drivers/nvdimm/e820.c|   86 ++
 tools/testing/nvdimm/Kbuild  |4 ++
 7 files changed, 108 insertions(+), 74 deletions(-)
 create mode 100644 drivers/nvdimm/e820.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b3a1a5d77d92..76c61154ed50 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1426,10 +1426,14 @@ config ILLEGAL_POINTER_VALUE
 
 source "mm/Kconfig"
 
+config X86_PMEM_LEGACY_DEVICE
+   bool
+
 config X86_PMEM_LEGACY
-   bool "Support non-standard NVDIMMs and ADR protected memory"
+   tristate "Support non-standard NVDIMMs and ADR protected memory"
depends on PHYS_ADDR_T_64BIT
depends on BLK_DEV
+   select X86_PMEM_LEGACY_DEVICE
select LIBNVDIMM
help
  Treat memory marked using the non-standard e820 type of 12 as used
diff --git a/arch/x86/include/uapi/asm/e820.h b/arch/x86/include/uapi/asm/e820.h
index 0f457e6eab18..9dafe59cf6e2 100644
--- a/arch/x86/include/uapi/asm/e820.h
+++ b/arch/x86/include/uapi/asm/e820.h
@@ -37,7 +37,7 @@
 /*
  * This is a non-standardized way to represent ADR or NVDIMM regions that
  * persist over a reboot.  The kernel will ignore their special capabilities
- * unless the CONFIG_X86_PMEM_LEGACY=y option is set.
+ * unless the CONFIG_X86_PMEM_LEGACY option is set.
  *
  * ( Note that older platforms also used 6 for the same type of memory,
  *   but newer versions switched to 12 as 6 was assigned differently.  Some
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 0f15af41bd80..ac2bb7e28ba2 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -92,7 +92,7 @@ obj-$(CONFIG_KVM_GUEST)   += kvm.o kvmclock.o
 obj-$(CONFIG_PARAVIRT) += paravirt.o paravirt_patch_$(BITS).o
 obj-$(CONFIG_PARAVIRT_SPINLOCKS)+= paravirt-spinlocks.o
 obj-$(CONFIG_PARAVIRT_CLOCK)   += pvclock.o
-obj-$(CONFIG_X86_PMEM_LEGACY)  += pmem.o
+obj-$(CONFIG_X86_PMEM_LEGACY_DEVICE) += pmem.o
 
 obj-$(CONFIG_PCSPKR_PLATFORM)  += pcspeaker.o
 
diff --git a/arch/x86/kernel/pmem.c b/arch/x86/kernel/pmem.c
index 64f90f53bb85..4f00b63d7ff3 100644
--- a/arch/x86/kernel/pmem.c
+++ b/arch/x86/kernel/pmem.c
@@ -3,80 +3,17 @@
  * Copyright (c) 2015, Intel Corporation.
  */
 #include 
-#include 
 #include 
-#include 
-
-static void e820_pmem_release(struct device *dev)
-{
-   struct nvdimm_bus *nvdimm_bus = dev->platform_data;
-
-   if (nvdimm_bus)
-   nvdimm_bus_unregister(nvdimm_bus);
-}
-
-static struct platform_device e820_pmem = {
-   .name = "e820_pmem",
-   .id = -1,
-   .dev = {
-   .release = e820_pmem_release,
-   },
-};
-
-static const struct attribute_group *e820_pmem_attribute_groups[] = {
-   &nvdimm_bus_attribute_group,
-   NULL,
-};
-
-static const struct attribute_group *e820_pmem_region_attribute_groups[] = {
-   &nd_region_attribute_group,
-   &nd_device_attribute_group,
-   NULL,
-};
 
 static __init int register_e820_pmem(void)
 {
-   static struct nvdimm_bus_descriptor nd_desc;
-   struct device *dev = &e820_pmem.dev;
-   struct nvdimm_bus *nvdimm_bus;
-   int rc, i;
-
-   rc = platform_device_register(&e820_pmem);
-   if (rc)
-   return rc;
-
-   nd_desc.attr_groups = e820_pmem_attribute_groups;
-   nd_desc.provider_name = "e820";
-   nvdimm_bus = nvdimm_bus_register(dev, &nd_desc);
-   if (!nvdimm_bus)
-   goto err;
-   dev->platform_data = nvdimm_bus;
-

[PATCH v4 3/5] dt/bindings: qcom_nandc: Add DT bindings

[Archit Taneja]

Add DT bindings document for the Qualcomm NAND controller driver.

Cc: devicet...@vger.kernel.org

v4:
- No changes

v3:
- Don't use '0x' when specifying nand controller address space
- Add optional property for on-flash bbt usage

Acked-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
 .../devicetree/bindings/mtd/qcom_nandc.txt | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt

diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt 
b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
new file mode 100644
index 000..1de4643
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
@@ -0,0 +1,49 @@
+* Qualcomm NAND controller
+
+Required properties:
+- compatible:  should be "qcom,ebi2-nand" for IPQ806x
+- reg: MMIO address range
+- clocks:  must contain core clock and always on clock
+- clock-names: must contain "core" for the core clock and "aon" for the
+   always on clock
+- dmas:DMA specifier, consisting of a phandle to the 
ADM DMA
+   controller node and the channel number to be used for
+   NAND. Refer to dma.txt and qcom_adm.txt for more details
+- dma-names:   must be "rxtx"
+- qcom,cmd-crci:   must contain the ADM command type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+- qcom,data-crci:  must contain the ADM data type CRCI block instance
+   number specified for the NAND controller on the given
+   platform
+
+Optional properties:
+- nand-bus-width:  bus width. Must be 8 or 16. If not present, 8 is chosen
+   as default
+
+- nand-ecc-strength:   number of bits to correct per ECC step. Must be 4 or 8
+   bits. If not present, 4 is chosen as default
+- nand-on-flash-bbt:   Create/use on-flash bad block table
+
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+
+Example:
+
+nand@1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   partition@0 {
+   ...
+   };
+};
-- 
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 v4 5/5] arm: qcom: dts: Enable NAND node on IPQ8064 AP148 platform

[Archit Taneja]

Enable the NAND controller node on the AP148 platform. Provide pinmux
information.

v4:
- Move bias-disable out of mux and create a separate group for it.
- Place the dma node inside soc node and give the full path with address.

v3, v2, v1:
- No changes

Cc: devicet...@vger.kernel.org

Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts 
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index 7f9ea50..648994c 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -30,6 +30,32 @@
bias-none;
};
};
+   nand_pins: nand_pins {
+   mux {
+   pins = "gpio34", "gpio35", "gpio36",
+  "gpio37", "gpio38", "gpio39",
+  "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   function = "nand";
+   drive-strength = <10>;
+   };
+   disable {
+   pins = "gpio34", "gpio35", "gpio36",
+  "gpio37", "gpio38";
+   bias-disable;
+   };
+   pullups {
+   pins = "gpio39";
+   bias-pull-up;
+   };
+   hold {
+   pins = "gpio40", "gpio41", "gpio42",
+  "gpio43", "gpio44", "gpio45",
+  "gpio46", "gpio47";
+   bias-bus-hold;
+   };
+   };
};
 
gsbi@1630 {
@@ -93,5 +119,19 @@
sata@2900 {
status = "ok";
};
+
+   dma@1830 {
+   status = "ok";
+   };
+
+   nand@1ac0 {
+   status = "ok";
+
+   pinctrl-0 = <&nand_pins>;
+   pinctrl-names = "default";
+
+   nand-ecc-strength = <4>;
+   nand-bus-width = <8>;
+   };
};
 };
-- 
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 2/2] cxl: add set/get private data to context struct

[Michael Ellerman]

On Wed, 2015-08-19 at 14:19 +1000, Ian Munsie wrote:
> From: Michael Neuling 
> 
> This provides AFU drivers a means to associate private data with a cxl
> context. This is particularly intended for make the new callbacks for
> driver specific events easier for AFU drivers to use, as they can easily
> get back to any private data structures they may use.
> 
> Signed-off-by: Michael Neuling 
> Signed-off-by: Ian Munsie 
> ---
>  drivers/misc/cxl/api.c | 21 +
>  drivers/misc/cxl/cxl.h |  3 +++
>  include/misc/cxl.h |  7 +++
>  3 files changed, 31 insertions(+)
> 
> diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
> index e0f0c78..5f0b22e 100644
> --- a/drivers/misc/cxl/api.c
> +++ b/drivers/misc/cxl/api.c
> @@ -70,6 +70,27 @@ int cxl_release_context(struct cxl_context *ctx)
>  }
>  EXPORT_SYMBOL_GPL(cxl_release_context);
>  
> +
> +int cxl_set_priv(struct cxl_context *ctx, void *priv)
> +{
> + if (!ctx)
> + return -EINVAL;
> +
> + ctx->priv = priv;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(cxl_set_priv);
> +
> +void *cxl_get_priv(struct cxl_context *ctx)
> +{
> + if (!ctx)
> + return ERR_PTR(-EINVAL);
> +
> + return ctx->priv;
> +}
> +EXPORT_SYMBOL_GPL(cxl_get_priv);


Do we really need the accessors? They don't buy anything I can see over just
using ctx->priv directly.

cheers


--
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 v4 4/5] arm: qcom: dts: Add NAND controller node for ipq806x

[Archit Taneja]

The nand controller in IPQ806x is of the 'EBI2 type'. Use the corresponding
compatible string.

Cc: devicet...@vger.kernel.org

Reviewed-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 1e1b3f0..a7f0ee5 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -350,5 +350,20 @@
status = "disabled";
};
 
+   nand@1ac0 {
+   compatible = "qcom,ebi2-nandc";
+   reg = <0x1ac0 0x800>;
+
+   clocks = <&gcc EBI2_CLK>,
+<&gcc EBI2_AON_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <&adm_dma 3>;
+   dma-names = "rxtx";
+   qcom,cmd-crci = <15>;
+   qcom,data-crci = <3>;
+
+   status = "disabled";
+   };
};
 };
-- 
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 v4 1/5] mtd: nand: Create a BBT flag to access bad block markers in raw mode

[Archit Taneja]

Some controllers can access the factory bad block marker from OOB only
when they read it in raw mode. When ECC is enabled, these controllers
discard reading/writing bad block markers, preventing access to them
altogether.

The bbt driver assumes MTD_OPS_PLACE_OOB when scanning for bad blocks.
This results in the nand driver's ecc->read_oob() op to be called, which
works with ECC enabled.

Create a new BBT option flag that tells nand_bbt to force the mode to
MTD_OPS_RAW. This would result in the correct op being called for the
underlying nand controller driver.

Reviewed-by: Andy Gross 
Signed-off-by: Archit Taneja 
---
 drivers/mtd/nand/nand_base.c | 6 +-
 drivers/mtd/nand/nand_bbt.c  | 6 +-
 include/linux/mtd/bbm.h  | 7 +++
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ceb68ca..0a0c524 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -394,7 +394,11 @@ static int nand_default_block_markbad(struct mtd_info 
*mtd, loff_t ofs)
} else {
ops.len = ops.ooblen = 1;
}
-   ops.mode = MTD_OPS_PLACE_OOB;
+
+   if (unlikely(chip->bbt_options & NAND_BBT_ACCESS_BBM_RAW))
+   ops.mode = MTD_OPS_RAW;
+   else
+   ops.mode = MTD_OPS_PLACE_OOB;
 
/* Write to first/last page(s) if necessary */
if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 63a1a36..f2d89c9 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
@@ -420,7 +420,11 @@ static int scan_block_fast(struct mtd_info *mtd, struct 
nand_bbt_descr *bd,
ops.oobbuf = buf;
ops.ooboffs = 0;
ops.datbuf = NULL;
-   ops.mode = MTD_OPS_PLACE_OOB;
+
+   if (unlikely(bd->options & NAND_BBT_ACCESS_BBM_RAW))
+   ops.mode = MTD_OPS_RAW;
+   else
+   ops.mode = MTD_OPS_PLACE_OOB;
 
for (j = 0; j < numpages; j++) {
/*
diff --git a/include/linux/mtd/bbm.h b/include/linux/mtd/bbm.h
index 36bb6a5..f67f84a 100644
--- a/include/linux/mtd/bbm.h
+++ b/include/linux/mtd/bbm.h
@@ -116,6 +116,13 @@ struct nand_bbt_descr {
 #define NAND_BBT_NO_OOB_BBM0x0008
 
 /*
+ * Force MTD_OPS_RAW mode when trying to access bad block markes from OOB. To
+ * be used by controllers which can access BBM only when ECC is disabled, i.e,
+ * when in RAW access mode
+ */
+#define NAND_BBT_ACCESS_BBM_RAW0x0010
+
+/*
  * Flag set by nand_create_default_bbt_descr(), marking that the nand_bbt_descr
  * was allocated dynamicaly and must be freed in nand_release(). Has no meaning
  * in nand_chip.bbt_options.
-- 
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 v4 0/5] mtd: Qualcomm NAND controller driver

[Archit Taneja]

Add support for the NAND controller driver for SoC's that contain EBI2.
For now, the only SoC upstream that has EBI2 is IPQ806x.

The original version was posted a while back. The main comments were
about the driver not being able to use nand_bbt. This was because the
controller could read factory bad block markers only in RAW mode. This
forced us to implement our own versions of chip->block_bad and
chip->blobk_markbad, and also we had to skip creating a BBT.

Discussions with Kevin Cernekee concluded that having a new BBT flag
that incorporates this controller's special requirement is a possible
option.

The new version makes use of this flag and now uses nand_bbt, at the
cost of implement read_oob_raw and write_oob_raw ops.

The patchset requires the v6 ADM dmaengine patches posted by Andy:

https://lkml.org/lkml/2015/3/17/19

v4:
- Some more fixes. Mentioned in patch's changelog.

v3:
- Various fixes and clean ups suggested by Stephen Boyd.

v2:
- Added a new BBT flag that allows us to read BBM in raw mode
- reduce memcpy-s in the driver
- some refactor and clean ups because of above changes

v1:
- original series:
  https://lkml.org/lkml/2015/1/16/317

Archit Taneja (5):
  mtd: nand: Create a BBT flag to access bad block markers in raw mode
  mtd: nand: Qualcomm NAND controller driver
  dt/bindings: qcom_nandc: Add DT bindings
  arm: qcom: dts: Add NAND controller node for ipq806x
  arm: qcom: dts: Enable NAND node on IPQ8064 AP148 platform

 .../devicetree/bindings/mtd/qcom_nandc.txt |   49 +
 arch/arm/boot/dts/qcom-ipq8064-ap148.dts   |   40 +
 arch/arm/boot/dts/qcom-ipq8064.dtsi|   15 +
 drivers/mtd/nand/Kconfig   |7 +
 drivers/mtd/nand/Makefile  |1 +
 drivers/mtd/nand/nand_base.c   |6 +-
 drivers/mtd/nand/nand_bbt.c|6 +-
 drivers/mtd/nand/qcom_nandc.c  | 1910 
 include/linux/mtd/bbm.h|7 +
 9 files changed, 2039 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt
 create mode 100644 drivers/mtd/nand/qcom_nandc.c

-- 
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] cxl: add set/get private data to context struct

[Ian Munsie]

From: Michael Neuling 

This provides AFU drivers a means to associate private data with a cxl
context. This is particularly intended for make the new callbacks for
driver specific events easier for AFU drivers to use, as they can easily
get back to any private data structures they may use.

Signed-off-by: Michael Neuling 
Signed-off-by: Ian Munsie 
---
 drivers/misc/cxl/api.c | 21 +
 drivers/misc/cxl/cxl.h |  3 +++
 include/misc/cxl.h |  7 +++
 3 files changed, 31 insertions(+)

diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
index e0f0c78..5f0b22e 100644
--- a/drivers/misc/cxl/api.c
+++ b/drivers/misc/cxl/api.c
@@ -70,6 +70,27 @@ int cxl_release_context(struct cxl_context *ctx)
 }
 EXPORT_SYMBOL_GPL(cxl_release_context);
 
+
+int cxl_set_priv(struct cxl_context *ctx, void *priv)
+{
+   if (!ctx)
+   return -EINVAL;
+
+   ctx->priv = priv;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(cxl_set_priv);
+
+void *cxl_get_priv(struct cxl_context *ctx)
+{
+   if (!ctx)
+   return ERR_PTR(-EINVAL);
+
+   return ctx->priv;
+}
+EXPORT_SYMBOL_GPL(cxl_get_priv);
+
 int cxl_allocate_afu_irqs(struct cxl_context *ctx, int num)
 {
if (num == 0)
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index 30e44a8..93db76a 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -431,6 +431,9 @@ struct cxl_context {
/* Only used in PR mode */
u64 process_token;
 
+   /* driver private data */
+   void *priv;
+
unsigned long *irq_bitmap; /* Accessed from IRQ context */
struct cxl_irq_ranges irqs;
struct list_head irq_names;
diff --git a/include/misc/cxl.h b/include/misc/cxl.h
index 73e03a6..3f5edbe 100644
--- a/include/misc/cxl.h
+++ b/include/misc/cxl.h
@@ -89,6 +89,13 @@ struct cxl_context *cxl_dev_context_init(struct pci_dev 
*dev);
 int cxl_release_context(struct cxl_context *ctx);
 
 /*
+ * Set and get private data associated with a context. Allows drivers to have a
+ * back pointer to some useful structure.
+ */
+int cxl_set_priv(struct cxl_context *ctx, void *priv);
+void *cxl_get_priv(struct cxl_context *ctx);
+
+/*
  * Allocate AFU interrupts for this context. num=0 will allocate the default
  * for this AFU as given in the AFU descriptor. This number doesn't include the
  * interrupt 0 (CAIA defines AFU IRQ 0 for page faults). Each interrupt to be
-- 
2.1.4

--
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 v3 1/8] rsb: Add generic Reduced Serial Bus (RSB) controller binding documentation

[Chen-Yu Tsai]

Reduced Serial Bus is a proprietary 2-line push-pull serial bus
supporting multiple slave devices.

It was developed by Allwinner, Inc. and used by Allwinner and X-Powers,
Inc. for their line of PMICs and other peripheral ICs.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/rsb/rsb.txt | 50 +++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rsb/rsb.txt

diff --git a/Documentation/devicetree/bindings/rsb/rsb.txt 
b/Documentation/devicetree/bindings/rsb/rsb.txt
new file mode 100644
index ..0b027948ca9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/rsb/rsb.txt
@@ -0,0 +1,50 @@
+Reduced Serial Bus (RSB) Controller
+
+This document defines a generic set of bindings for use by RSB controllers.
+A controller is modelled in device tree as a node with zero or more child
+nodes, each representing a unique slave device on the bus.
+
+Required properties:
+
+ - #address-cells : must be 2
+ - #size-cells : must be 0
+
+Optional properties:
+
+ - clock-frequency : Desired bus clock frequency in Hz. Maximum is 20 MHz.
+
+Child nodes:
+
+An RSB controller node can contain zero or more child nodes representing
+slave devices on the bus.  Child 'reg' properties are specified as a
+runtime address, hardware address pair. The hardware address is hardwired
+in the device, which can normally be found in the datasheet. The runtime
+address is set by software. No 2 devices on the same bus shall have the
+same runtime address.
+
+Valid runtime addresses - There are only 15 valid runtime addresses:
+
+0x17, 0x2d, 0x3a, 0x4e, 0x59, 0x63, 0x74, 0x8b,
+0x9c, 0xa6, 0xb1, 0xc5, 0xd2, 0xe8, 0xff
+
+It is highly recommended that one choose the same runtime addresses as
+vendor BSPs use so that a) the addresses remain the same across different
+software systems, and b) addresses of supported and listed slave devices
+don't conflict with unsupported or not yet listed devices.
+
+Example:
+
+   rsb@... {
+   compatible = "...";
+   reg = <...>;
+   /* ... */
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   pmic@2d {
+   compatible = "...";
+   reg = <0x2d 0x3e3>;
+
+   /* ... */
+   };
+   };
-- 
2.5.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 v3 6/8] ARM: dts: sun8i: Add Reduced Serial Bus controller device node to A23/A33 dtsi

[Chen-Yu Tsai]

This patch adds a device node for the Reduced Serial Bus (RSB)
controller and the defacto pinmux setting to the A23/A33 dtsi.

Since there is only one possible pinmux setting for RSB, just
set it in the dtsi.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a23-a33.dtsi | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 27a925ec17d2..db3671382cb2 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -661,6 +661,13 @@
#size-cells = <0>;
#gpio-cells = <3>;
 
+   r_rsb_pins: r_rsb {
+   allwinner,pins = "PL0", "PL1";
+   allwinner,function = "s_rsb";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
r_uart_pins_a: r_uart@0 {
allwinner,pins = "PL2", "PL3";
allwinner,function = "s_uart";
@@ -668,5 +675,19 @@
allwinner,pull = ;
};
};
+
+   r_rsb: i2c@01f03400 {
+   compatible = "allwinner,sun8i-a23-rsb";
+   reg = <0x01f03400 0x400>;
+   interrupts = ;
+   clocks = <&apb0_gates 3>;
+   clock-frequency = <300>;
+   resets = <&apb0_rst 3>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&r_rsb_pins>;
+   status = "disabled";
+   #address-cells = <2>;
+   #size-cells = <0>;
+   };
};
 };
-- 
2.5.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 v3 8/8] ARM: dts: sun8i: sinlinx-sina33: Enable Reduced Serial Bus controller

[Chen-Yu Tsai]

The Reduced Serial Bus controller is used to talk to the onboard PMIC.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts 
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 1d5390d4e03a..13ce68f06dd6 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -130,6 +130,10 @@
};
 };
 
+&r_rsb {
+   status = "okay";
+};
+
 &uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_b>;
-- 
2.5.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 v3 5/8] regmap: rsb: Add support for Reduced Serial Bus (RSB) based regmaps

[Chen-Yu Tsai]

Signed-off-by: Chen-Yu Tsai 
---
 drivers/base/regmap/Kconfig  |   6 +-
 drivers/base/regmap/Makefile |   1 +
 drivers/base/regmap/regmap-rsb.c | 121 +++
 include/linux/regmap.h   |  36 
 4 files changed, 163 insertions(+), 1 deletion(-)
 create mode 100644 drivers/base/regmap/regmap-rsb.c

diff --git a/drivers/base/regmap/Kconfig b/drivers/base/regmap/Kconfig
index db9d00c36a3e..afb41994c51e 100644
--- a/drivers/base/regmap/Kconfig
+++ b/drivers/base/regmap/Kconfig
@@ -3,7 +3,7 @@
 # subsystems should select the appropriate symbols.
 
 config REGMAP
-   default y if (REGMAP_I2C || REGMAP_SPI || REGMAP_SPMI || REGMAP_AC97 || 
REGMAP_MMIO || REGMAP_IRQ)
+   default y if (REGMAP_I2C || REGMAP_SPI || REGMAP_SPMI || REGMAP_RSB || 
REGMAP_AC97 || REGMAP_MMIO || REGMAP_IRQ)
select LZO_COMPRESS
select LZO_DECOMPRESS
select IRQ_DOMAIN if REGMAP_IRQ
@@ -24,6 +24,10 @@ config REGMAP_SPMI
tristate
depends on SPMI
 
+config REGMAP_RSB
+   tristate
+   depends on RSB
+
 config REGMAP_MMIO
tristate
 
diff --git a/drivers/base/regmap/Makefile b/drivers/base/regmap/Makefile
index 609e4c84f485..dad32b3903d4 100644
--- a/drivers/base/regmap/Makefile
+++ b/drivers/base/regmap/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_REGMAP_AC97) += regmap-ac97.o
 obj-$(CONFIG_REGMAP_I2C) += regmap-i2c.o
 obj-$(CONFIG_REGMAP_SPI) += regmap-spi.o
 obj-$(CONFIG_REGMAP_SPMI) += regmap-spmi.o
+obj-$(CONFIG_REGMAP_RSB) += regmap-rsb.o
 obj-$(CONFIG_REGMAP_MMIO) += regmap-mmio.o
 obj-$(CONFIG_REGMAP_IRQ) += regmap-irq.o
diff --git a/drivers/base/regmap/regmap-rsb.c b/drivers/base/regmap/regmap-rsb.c
new file mode 100644
index ..e82aa980abe1
--- /dev/null
+++ b/drivers/base/regmap/regmap-rsb.c
@@ -0,0 +1,121 @@
+/*
+ * Register map access API - RSB support
+ *
+ * Copyright 2015 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai 
+ *
+ * Based on regmap-i2c.c
+ *
+ * Copyright 2011 Wolfson Microelectronics plc
+ *
+ * Author: Mark Brown 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "internal.h"
+
+struct rsb_context {
+   struct rsb_device *rsb;
+   int size;
+};
+
+static int regmap_rsb_reg_read(void *context, unsigned int reg,
+  unsigned int *val)
+{
+   struct rsb_context *ctx = context;
+   struct rsb_device *rsb = ctx->rsb;
+
+   if (reg > 0xff)
+   return -EINVAL;
+
+   return rsb_register_read(rsb, reg, val, ctx->size);
+}
+
+static int regmap_rsb_reg_write(void *context, unsigned int reg,
+   unsigned int val)
+{
+   struct rsb_context *ctx = context;
+   struct rsb_device *rsb = ctx->rsb;
+
+   return rsb_register_write(rsb, reg, val, ctx->size);
+}
+
+static void regmap_rsb_free_context(void *context)
+{
+   struct rsb_context *ctx = context;
+
+   kfree(ctx);
+}
+
+static struct regmap_bus regmap_rsb = {
+   .reg_write = regmap_rsb_reg_write,
+   .reg_read = regmap_rsb_reg_read,
+   .free_context = regmap_rsb_free_context,
+   .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
+   .val_format_endian_default = REGMAP_ENDIAN_NATIVE,
+};
+
+static struct rsb_context *regmap_rsb_init_context(struct rsb_device *rsb,
+   const struct regmap_config *config)
+{
+   struct rsb_context *ctx;
+
+   switch (config->val_bits) {
+   case 8:
+   case 16:
+   case 32:
+   break;
+   default:
+   return ERR_PTR(-EINVAL);
+   }
+
+   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+   if (!ctx)
+   return ERR_PTR(-ENOMEM);
+
+   ctx->rsb = rsb;
+   ctx->size = config->val_bits / 8;
+
+   return ctx;
+}
+
+struct regmap *__regmap_init_rsb(struct rsb_device *rsb,
+const struct regmap_config *config,
+struct lock_class_key *lock_key,
+const char *lock_name)
+{
+   struct rsb_context *ctx = regmap_rsb_init_context(rsb, config);
+
+   if (IS_ERR(ctx))
+   return ERR_CAST(ctx);
+
+   return __regmap_init(&rsb->dev, ®map_rsb, ctx, config,
+lock_key, lock_name);
+}
+EXPORT_SYMBOL_GPL(__regmap_init_rsb);
+
+struct regmap *__devm_regmap_init_rsb(struct rsb_device *rsb,
+ const struct regmap_config *config,
+ struct lock_class_key *lock_key,
+ const char *lock_name)
+{
+   struct rsb_context *ctx = regmap_rsb_init_context(rsb, config);
+
+   if (IS_ERR(ctx))
+   return ERR_CAST(ctx);
+
+   return __devm_regmap_init(&rsb->dev,

[PATCH v3 7/8] ARM: dts: sun8i: ippo-q8h-v5: Enable Reduced Serial Bus controller

[Chen-Yu Tsai]

The Reduced Serial Bus controller is used to talk to the onboard PMIC.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts 
b/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
index 8d9da6886a4c..2e45a82c8981 100644
--- a/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
+++ b/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
@@ -120,6 +120,10 @@
};
 };
 
+&r_rsb {
+   status = "okay";
+};
+
 &r_uart {
pinctrl-names = "default";
pinctrl-0 = <&r_uart_pins_a>;
-- 
2.5.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 v3 0/8] ARM: sunxi: Add Reduced Serial Bus support

[Chen-Yu Tsai]

Hi everyone,

This is my third attempt at adding support for Allwinner's Reduced
Serial Bus (RSB), which is used to communicate with PMICs and other
peripherals on their newer SoCs, such as the A23/A33/A80.

RSB is a simplified two wire interface using push-pull outputs,
supporting multiple slaves, address and data parity checks, and
clock speeds up to 20 MHz. The bus only supports simple register
read/writes, with possible register sizes of 8/16/32 bits. Access
sizes not matching the slave device register sizes result in NACKs
or errors. 32 bit registers in devices have yet to be seen.

Previous attempts to add support through the I2C subsystem have
been rejected, as the bus line protocol is too different to even
consider. In this version, RSB is implemented as a new bus type,
much like SPMI.

Even though there will almost certainly be only one RSB driver,
it's still split into the bus core framework and vendor specific
driver, like other subsystems. Theoretically someone could
implement a bit-banging driver for it.


Patches 1 & 2 add the DT bindings for common RSB properties and
the controller.

Patches 3 & 4 add the RSB framework core and sunxi driver.

Patch 5 (based on regmap/for-next) adds an RSB regmap driver.

Patch 6 adds the RSB nodes for A23/A33 dtsi.

Patch 7 & 8 enable the RSB controller on the boards I have.


Still to come are axp20x driver support for the RSB based AXP223.
The complete series can be found at:

https://github.com/wens/linux/tree/sunxi-rsb-v3

Since this is a new subsystem, I'm not sure who should pick up
the first 4 patches, or whether they are even in the right place.
Any suggestions?


Regards,
ChenYu


Chen-Yu Tsai (8):
  rsb: Add generic Reduced Serial Bus (RSB) controller binding
documentation
  rsb: sunxi: Add Allwinner Reduced Serial Bus (RSB) controller bindings
  rsb: Linux driver framework for Reduced Serial Bus (RSB)
  rsb: sunxi: Add driver for Allwinner Reduced Serial Bus controller
  regmap: rsb: Add support for Reduced Serial Bus (RSB) based regmaps
  ARM: dts: sun8i: Add Reduced Serial Bus controller device node to
A23/A33 dtsi
  ARM: dts: sun8i: ippo-q8h-v5: Enable Reduced Serial Bus controller
  ARM: dts: sun8i: sinlinx-sina33: Enable Reduced Serial Bus controller

 .../devicetree/bindings/rsb/rsb-sunxi.txt  |  34 ++
 Documentation/devicetree/bindings/rsb/rsb.txt  |  50 ++
 arch/arm/boot/dts/sun8i-a23-a33.dtsi   |  21 +
 arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts|   4 +
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts |   4 +
 drivers/Kconfig|   2 +
 drivers/Makefile   |   1 +
 drivers/base/regmap/Kconfig|   6 +-
 drivers/base/regmap/Makefile   |   1 +
 drivers/base/regmap/regmap-rsb.c   | 121 +
 drivers/rsb/Kconfig|  26 ++
 drivers/rsb/Makefile   |   6 +
 drivers/rsb/rsb-core.c | 511 +
 drivers/rsb/rsb-sunxi.c| 441 ++
 include/linux/regmap.h |  36 ++
 include/linux/rsb.h| 144 ++
 16 files changed, 1407 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/rsb/rsb-sunxi.txt
 create mode 100644 Documentation/devicetree/bindings/rsb/rsb.txt
 create mode 100644 drivers/base/regmap/regmap-rsb.c
 create mode 100644 drivers/rsb/Kconfig
 create mode 100644 drivers/rsb/Makefile
 create mode 100644 drivers/rsb/rsb-core.c
 create mode 100644 drivers/rsb/rsb-sunxi.c
 create mode 100644 include/linux/rsb.h

-- 
2.5.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 1/2] cxl: Add mechanism for delivering AFU driver specific events

[Ian Munsie]

From: Ian Munsie 

This adds an afu_driver_ops structure with event_pending and
deliver_event callbacks. An AFU driver can fill these out and associate
it with a context to enable passing custom AFU specific events to
userspace.

The cxl driver will call event_pending() during poll, select, read, etc.
calls to check if an AFU driver specific event is pending, and will call
deliver_event() to deliver that event. This way, the cxl driver takes
care of all the usual locking semantics around these calls and handles
all the generic cxl events, so that the AFU driver only needs to worry
about it's own events.

The deliver_event() call is passed a struct cxl_event buffer to fill in.
The header will already be filled in for an AFU driver event, and the
AFU driver is expected to expand the header.size as necessary (up to
max_size, defined by struct cxl_event_afu_driver_reserved) and fill out
it's own information.

Conflicts between AFU specific events are not expected, due to the fact
that each AFU specific driver has it's own mechanism to deliver an AFU
file descriptor to userspace.

Signed-off-by: Ian Munsie 
---
 drivers/misc/cxl/Kconfig |  5 +
 drivers/misc/cxl/api.c   |  7 +++
 drivers/misc/cxl/cxl.h   |  6 +-
 drivers/misc/cxl/file.c  | 37 +++--
 include/misc/cxl.h   | 29 +
 include/uapi/misc/cxl.h  | 13 +
 6 files changed, 86 insertions(+), 11 deletions(-)

diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig
index 8756d06..560412c 100644
--- a/drivers/misc/cxl/Kconfig
+++ b/drivers/misc/cxl/Kconfig
@@ -15,12 +15,17 @@ config CXL_EEH
bool
default n
 
+config CXL_AFU_DRIVER_OPS
+   bool
+   default n
+
 config CXL
tristate "Support for IBM Coherent Accelerators (CXL)"
depends on PPC_POWERNV && PCI_MSI && EEH
select CXL_BASE
select CXL_KERNEL_API
select CXL_EEH
+   select CXL_AFU_DRIVER_OPS
default m
help
  Select this option to enable driver support for IBM Coherent
diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
index 6a768a9..e0f0c78 100644
--- a/drivers/misc/cxl/api.c
+++ b/drivers/misc/cxl/api.c
@@ -267,6 +267,13 @@ struct cxl_context *cxl_fops_get_context(struct file *file)
 }
 EXPORT_SYMBOL_GPL(cxl_fops_get_context);
 
+void cxl_set_driver_ops(struct cxl_context *ctx,
+   struct cxl_afu_driver_ops *ops)
+{
+   ctx->afu_driver_ops = ops;
+}
+EXPORT_SYMBOL_GPL(cxl_set_driver_ops);
+
 int cxl_start_work(struct cxl_context *ctx,
   struct cxl_ioctl_start_work *work)
 {
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index 6f53866..30e44a8 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 extern uint cxl_verbose;
@@ -34,7 +35,7 @@ extern uint cxl_verbose;
  * Bump version each time a user API change is made, whether it is
  * backwards compatible ot not.
  */
-#define CXL_API_VERSION 1
+#define CXL_API_VERSION 2
 #define CXL_API_VERSION_COMPATIBLE 1
 
 /*
@@ -462,6 +463,9 @@ struct cxl_context {
bool pending_fault;
bool pending_afu_err;
 
+   /* Used by AFU drivers for driver specific event delivery */
+   struct cxl_afu_driver_ops *afu_driver_ops;
+
struct rcu_head rcu;
 };
 
diff --git a/drivers/misc/cxl/file.c b/drivers/misc/cxl/file.c
index 57bdb47..2ebaca3 100644
--- a/drivers/misc/cxl/file.c
+++ b/drivers/misc/cxl/file.c
@@ -279,6 +279,22 @@ int afu_mmap(struct file *file, struct vm_area_struct *vm)
return cxl_context_iomap(ctx, vm);
 }
 
+static inline int _ctx_event_pending(struct cxl_context *ctx)
+{
+   bool afu_driver_event_pending = false;
+
+   if (ctx->afu_driver_ops && ctx->afu_driver_ops->event_pending)
+   afu_driver_event_pending = 
ctx->afu_driver_ops->event_pending(ctx);
+
+   return (ctx->pending_irq || ctx->pending_fault ||
+   ctx->pending_afu_err || afu_driver_event_pending);
+}
+
+static inline int ctx_event_pending(struct cxl_context *ctx)
+{
+   return _ctx_event_pending(ctx) || (ctx->status == CLOSED);
+}
+
 unsigned int afu_poll(struct file *file, struct poll_table_struct *poll)
 {
struct cxl_context *ctx = file->private_data;
@@ -291,8 +307,7 @@ unsigned int afu_poll(struct file *file, struct 
poll_table_struct *poll)
pr_devel("afu_poll wait done pe: %i\n", ctx->pe);
 
spin_lock_irqsave(&ctx->lock, flags);
-   if (ctx->pending_irq || ctx->pending_fault ||
-   ctx->pending_afu_err)
+   if (_ctx_event_pending(ctx))
mask |= POLLIN | POLLRDNORM;
else if (ctx->status == CLOSED)
/* Only error on closed when there are no futher events pending
@@ -305,12 +320,6 @@ unsigned int afu_poll(struct file *file, struct 
poll_table_struct *poll)
return mask;
 }
 
-static inline int ctx_event_pending(s

[PATCH v3 4/8] rsb: sunxi: Add driver for Allwinner Reduced Serial Bus controller

[Chen-Yu Tsai]

Signed-off-by: Chen-Yu Tsai 
---
 drivers/rsb/Kconfig |  15 ++
 drivers/rsb/Makefile|   2 +
 drivers/rsb/rsb-sunxi.c | 441 
 3 files changed, 458 insertions(+)
 create mode 100644 drivers/rsb/rsb-sunxi.c

diff --git a/drivers/rsb/Kconfig b/drivers/rsb/Kconfig
index 6642e1db6d98..54a28a39e0e2 100644
--- a/drivers/rsb/Kconfig
+++ b/drivers/rsb/Kconfig
@@ -9,3 +9,18 @@ menuconfig RSB
  Integrated Circuits (PMIC) or other peripherals.
 
  These are commonly seen on newer Allwinner SoCs and X-Powers ICs.
+
+if RSB
+
+config RSB_SUNXI
+   tristate "Allwinner RSB Controller"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   default MACH_SUN8I || MACH_SUN9I
+   help
+ If you say yes to this option, support will be included for the
+ built-in RSB controller on Allwinner sun8i/sun9i family SoCs.
+
+ This is required for communicating with X-Powers PMICs and other
+ devices that have the RSB interface.
+
+endif
diff --git a/drivers/rsb/Makefile b/drivers/rsb/Makefile
index 6fe56526fbf3..31cd615f7e58 100644
--- a/drivers/rsb/Makefile
+++ b/drivers/rsb/Makefile
@@ -2,3 +2,5 @@
 # Makefile for kernel RSB framework.
 #
 obj-$(CONFIG_RSB)  += rsb-core.o
+
+obj-$(CONFIG_RSB_SUNXI)+= rsb-sunxi.o
diff --git a/drivers/rsb/rsb-sunxi.c b/drivers/rsb/rsb-sunxi.c
new file mode 100644
index ..07b24291fe4d
--- /dev/null
+++ b/drivers/rsb/rsb-sunxi.c
@@ -0,0 +1,441 @@
+/*
+ * RSB (Reduced Serial Bus) driver.
+ *
+ * Author: Chen-Yu Tsai 
+ *
+ * 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.
+ *
+ * The RSB controller looks like an SMBus controller which only supports
+ * byte and word data transfers. But, it differs from standard SMBus
+ * protocol on several aspects:
+ * - it uses addresses set at runtime to address slaves. Runtime addresses
+ *   are sent to slaves using their 12bit hardware addresses. Up to 15
+ *   runtime addresses are available.
+ * - it adds a parity bit every 8bits of data and address for read and
+ *   write accesses; this replaces the ack bit
+ * - only one read access is required to read a byte (instead of a write
+ *   followed by a read access in standard SMBus protocol)
+ * - there's no Ack bit after each read access
+ *
+ * This means this bus cannot be used to interface with standard SMBus
+ * devices. Devices known to support this interface include the AXP223,
+ * AXP809, and AXP806 PMICs, and the AC100 audio codec, all from X-Powers.
+ *
+ * A description of the operation and wire protocol can be found in the
+ * RSB section of Allwinner's A80 user manual, which can be found at
+ *
+ * https://github.com/allwinner-zh/documents/tree/master/A80
+ *
+ * This document is officially released by Allwinner.
+ *
+ * This driver is based on i2c-sun6i-p2wi.c, the P2WI bus driver.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* RSB registers */
+#define RSB_CTRL   0x0 /* Global control */
+#define RSB_CCR0x4 /* Clock control */
+#define RSB_INTE   0x8 /* Interrupt controls */
+#define RSB_INTS   0xc /* Interrupt status */
+#define RSB_ADDR   0x10/* Address to send with read/write command */
+#define RSB_DATA   0x1c/* Data to read/write */
+#define RSB_LCR0x24/* Line control */
+#define RSB_DMCR   0x28/* Device mode (init) control */
+#define RSB_CMD0x2c/* RSB Command */
+#define RSB_DAR0x30/* Device address / runtime address */
+
+/* CTRL fields */
+#define RSB_CTRL_START_TRANS   BIT(7)
+#define RSB_CTRL_ABORT_TRANS   BIT(6)
+#define RSB_CTRL_GLOBAL_INT_ENBBIT(1)
+#define RSB_CTRL_SOFT_RST  BIT(0)
+
+/* CLK CTRL fields */
+#define RSB_CCR_SDA_OUT_DELAY(v)   (((v) & 0x7) << 8)
+#define RSB_CCR_MAX_CLK_DIV0xff
+#define RSB_CCR_CLK_DIV(v) ((v) & RSB_CCR_MAX_CLK_DIV)
+
+/* STATUS fields */
+#define RSB_INTS_TRANS_ERR_ACK BIT(16)
+#define RSB_INTS_TRANS_ERR_DATA_BIT(v) (((v) >> 8) & 0xf)
+#define RSB_INTS_TRANS_ERR_DATAGENMASK(11, 8)
+#define RSB_INTS_LOAD_BSY  BIT(2)
+#define RSB_INTS_TRANS_ERR BIT(1)
+#define RSB_INTS_TRANS_OVERBIT(0)
+
+/* LINE CTRL fields*/
+#define RSB_LCR_SCL_STATE  BIT(5)
+#define RSB_LCR_SDA_STATE  BIT(4)
+#define RSB_LCR_SCL_CTLBIT(3)
+#define RSB_LCR_SCL_CTL_EN BIT(2)
+#define RSB_LCR_SDA_CTLBIT(1)
+#define RSB_LCR_SDA_CTL_EN BIT(0)
+
+/* DEVICE MODE CTRL field values */
+#define RSB_DMCR_DEVICE_START  BIT(31)
+#define RSB_DMCR_MODE_DATA (0x7c << 16)
+#define RSB_DMCR_MODE_R

[PATCH v3 3/8] rsb: Linux driver framework for Reduced Serial Bus (RSB)

[Chen-Yu Tsai]

Reduced Serial Bus (RSB) is an Allwinner proprietery interface
used to communicate with PMICs and other peripheral ICs.

RSB is a two-wire push-pull serial bus that supports 1 master
device and up to 15 active slave devices.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/Kconfig|   2 +
 drivers/Makefile   |   1 +
 drivers/rsb/Kconfig|  11 ++
 drivers/rsb/Makefile   |   4 +
 drivers/rsb/rsb-core.c | 511 +
 include/linux/rsb.h| 144 ++
 6 files changed, 673 insertions(+)
 create mode 100644 drivers/rsb/Kconfig
 create mode 100644 drivers/rsb/Makefile
 create mode 100644 drivers/rsb/rsb-core.c
 create mode 100644 include/linux/rsb.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 6e973b8e3a3b..4ada2d3eb832 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -54,6 +54,8 @@ source "drivers/spi/Kconfig"
 
 source "drivers/spmi/Kconfig"
 
+source "drivers/rsb/Kconfig"
+
 source "drivers/hsi/Kconfig"
 
 source "drivers/pps/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index e4b260ecec15..75e0fc8fe28c 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_TARGET_CORE) += target/
 obj-$(CONFIG_MTD)  += mtd/
 obj-$(CONFIG_SPI)  += spi/
 obj-$(CONFIG_SPMI) += spmi/
+obj-$(CONFIG_RSB)  += rsb/
 obj-y  += hsi/
 obj-y  += net/
 obj-$(CONFIG_ATM)  += atm/
diff --git a/drivers/rsb/Kconfig b/drivers/rsb/Kconfig
new file mode 100644
index ..6642e1db6d98
--- /dev/null
+++ b/drivers/rsb/Kconfig
@@ -0,0 +1,11 @@
+#
+# RSB driver configuration
+#
+menuconfig RSB
+   tristate "RSB support"
+   help
+ RSB (Reduced Serial Bus) is a two-wire serial interface between
+ baseband and application processors and Power Management
+ Integrated Circuits (PMIC) or other peripherals.
+
+ These are commonly seen on newer Allwinner SoCs and X-Powers ICs.
diff --git a/drivers/rsb/Makefile b/drivers/rsb/Makefile
new file mode 100644
index ..6fe56526fbf3
--- /dev/null
+++ b/drivers/rsb/Makefile
@@ -0,0 +1,4 @@
+#
+# Makefile for kernel RSB framework.
+#
+obj-$(CONFIG_RSB)  += rsb-core.o
diff --git a/drivers/rsb/rsb-core.c b/drivers/rsb/rsb-core.c
new file mode 100644
index ..6682d827aebb
--- /dev/null
+++ b/drivers/rsb/rsb-core.c
@@ -0,0 +1,511 @@
+/*
+ * Copyright (c) 2015, Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai 
+ *
+ * Allwinner Reduced Serial Bus (RSB) driver
+ *
+ * based on spmi/spmi.c
+ *
+ * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_IDA(ctrl_ida);
+
+static void rsb_dev_release(struct device *dev)
+{
+   struct rsb_device *rdev = to_rsb_device(dev);
+
+   kfree(rdev);
+}
+
+static const struct device_type rsb_dev_type = {
+   .release= rsb_dev_release,
+};
+
+static void rsb_ctrl_release(struct device *dev)
+{
+   struct rsb_controller *ctrl = to_rsb_controller(dev);
+
+   ida_simple_remove(&ctrl_ida, ctrl->nr);
+   kfree(ctrl);
+}
+
+static const struct device_type rsb_ctrl_type = {
+   .release= rsb_ctrl_release,
+};
+
+static int rsb_device_match(struct device *dev, struct device_driver *drv)
+{
+   if (of_driver_match_device(dev, drv))
+   return 1;
+
+   return strcmp(dev_name(dev), drv->name) == 0;
+}
+
+static inline int rsb_init_cmd(struct rsb_controller *ctrl)
+{
+   int ret;
+
+   if (!ctrl || !ctrl->init_cmd || ctrl->dev.type != &rsb_ctrl_type)
+   return -EINVAL;
+
+   mutex_lock(&ctrl->lock);
+   ret = ctrl->init_cmd(ctrl);
+   mutex_unlock(&ctrl->lock);
+
+   return ret;
+}
+
+static inline int rsb_rtsaddr_cmd(struct rsb_controller *ctrl, u16 hwaddr,
+ u8 rtaddr)
+{
+   int ret;
+
+   if (!ctrl || !ctrl->rtsaddr_cmd || ctrl->dev.type != &rsb_ctrl_type)
+   return -EINVAL;
+
+   mutex_lock(&ctrl->lock);
+   ret = ctrl->rtsaddr_cmd(ctrl, hwaddr, rtaddr);
+   mutex_unlock(&ctrl->lock);
+
+   return ret;
+}
+
+static inline int rsb_read_cmd(struct rsb_controller *ctrl, u8 rtaddr,
+  u8 addr, u32 *buf, size_t len)
+{
+   int ret;
+
+   if (!ctrl || !ctrl->read_cmd || ctrl->dev.type != &rsb_ctrl_type)

[PATCH v3 2/8] rsb: sunxi: Add Allwinner Reduced Serial Bus (RSB) controller bindings

[Chen-Yu Tsai]

Recent Allwinner SoCs, starting with the A23, have a Reduced Serial Bus
(RSB) controller. This is used to talk to the PMIC, and later with the
A80 and A83 platform, the audio codec IC.

Signed-off-by: Chen-Yu Tsai 
---
 .../devicetree/bindings/rsb/rsb-sunxi.txt  | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rsb/rsb-sunxi.txt

diff --git a/Documentation/devicetree/bindings/rsb/rsb-sunxi.txt 
b/Documentation/devicetree/bindings/rsb/rsb-sunxi.txt
new file mode 100644
index ..057d24b84628
--- /dev/null
+++ b/Documentation/devicetree/bindings/rsb/rsb-sunxi.txt
@@ -0,0 +1,34 @@
+
+* Allwinner RSB (Reduced Serial Bus) controller
+
+Required properties :
+
+ - reg : Offset and length of the register set for the controller.
+ - compatible  : Shall be "allwinner,sun8i-a23-rsb".
+ - interrupts  : The interrupt line associated to the RSB controller.
+ - clocks  : The gate clk associated to the RSB controller.
+ - resets  : The reset line associated to the RSB controller.
+ - #address-cells  : shall be 2
+ - #size-cells : shall be 0
+
+Optional properties :
+
+ - clock-frequency : Desired RSB bus clock frequency in Hz. Maximum is 20MHz.
+If not set the current hardware setting shall be used.
+
+See rsb.txt for the generic RSB bindings for RSB slaves / child nodes.
+
+Example:
+
+   rsb@01f03400 {
+   compatible = "allwinner,sun8i-a23-rsb";
+   reg = <0x01f03400 0x400>;
+   interrupts = <0 39 4>;
+   clocks = <&apb0_gates 3>;
+   clock-frequency = <300>;
+   resets = <&apb0_rst 3>;
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   /* child nodes ... */
+   };
-- 
2.5.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/

[GIT PULL] clk: mediatek: New clocks support and fixes

[James Liao]

This is a collection of new Mediatek clocks support and fixes. These
patches come from Joe [1], Pi-cheng [2] and me [3], including clock
support for subsystems, CPU, GPT and some minor fixes.

[1] https://patchwork.kernel.org/patch/6777041/
[2] https://patchwork.kernel.org/patch/7023951/
[3] https://lkml.org/lkml/2015/8/10/194



The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:

  Linux 4.2-rc2 (2015-07-12 15:10:30 -0700)

are available in the git repository at:

  https://github.com/jamesjjliao/linux.git v4.2-rc2-clk

for you to fetch changes up to f4f5326e99f951c8dfed9c3f4d027a3246cb7a8b:

  clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS (2015-05-20 
15:59:21 +0800)



James Liao (8):
  clk: mediatek: Removed unused dpi_ck clock from MT8173
  clk: mediatek: Remove unused code from MT8173.
  clk: mediatek: Add __initdata and __init for data and functions
  clk: mediatek: Add fixed clocks support for Mediatek SoC.
  clk: mediatek: Fix rate and dependency of MT8173 clocks
  dt-bindings: ARM: Mediatek: Document devicetree bindings for clock
controllers
  clk: mediatek: Add subsystem clocks of MT8173
  clk: mediatek: Add USB clock support in MT8173 APMIXEDSYS

Joe.C (1):
  clk: mediatek: add 13mhz clock for MT8173

pi-cheng.chen (1):
  clk: mediatek: Export CPU mux clocks for CPU frequency control

 .../bindings/arm/mediatek/mediatek,imgsys.txt  |   22 ++
 .../bindings/arm/mediatek/mediatek,mmsys.txt   |   22 ++
 .../bindings/arm/mediatek/mediatek,vdecsys.txt |   22 ++
 .../bindings/arm/mediatek/mediatek,vencltsys.txt   |   22 ++
 .../bindings/arm/mediatek/mediatek,vencsys.txt |   22 ++
 drivers/clk/mediatek/Makefile  |2 +-
 drivers/clk/mediatek/clk-apmixed.c |  107 ++
 drivers/clk/mediatek/clk-cpumux.c  |  127 +++
 drivers/clk/mediatek/clk-cpumux.h  |   22 ++
 drivers/clk/mediatek/clk-gate.c|2 +-
 drivers/clk/mediatek/clk-mt8173.c  |  370 +++-
 drivers/clk/mediatek/clk-mtk.c |   36 +-
 drivers/clk/mediatek/clk-mtk.h |   24 +-
 drivers/clk/mediatek/clk-pll.c |7 +-
 include/dt-bindings/clock/mt8173-clk.h |  106 +-
 15 files changed, 879 insertions(+), 34 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt
 create mode 100644 drivers/clk/mediatek/clk-apmixed.c
 create mode 100644 drivers/clk/mediatek/clk-cpumux.c
 create mode 100644 drivers/clk/mediatek/clk-cpumux.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: [BUG/RFC] perf test fails on AMD CPUs

[Borislav Petkov]

On Tue, Aug 18, 2015 at 12:10:25PM +0200, Jiri Olsa wrote:
> buut anyway, it looks like latest AMD firmware issue:
> 
> [root@amd-pike-07 ~]# cat /sys/devices/system/cpu/cpu0/microcode/version
> 0x6000822
> [root@amd-pike-07 perf]# ./perf test 18
> 18: Test breakpoint overflow signal handler  : Ok
> 
> [root@amd-pike-07 perf]# cat /sys/devices/system/cpu/cpu0/microcode/version
> 0x6000832
> [root@amd-pike-07 perf]# ./perf test 18
> 18: Test breakpoint overflow signal handler  : FAILED!
> 
> 
> [root@amd-pike-07 ~]# cat /proc/cpuinfo 
> processor   : 7
> vendor_id   : AuthenticAMD
> cpu family  : 21
> model   : 2
> model name  : AMD Opteron(tm) Processor 3380
> stepping: 0
> microcode   : 0x6000832
> 
> SNIP

Whoops.

Can you please confirm with your debugging code that with version
0x6000822 EFLAGS.RF is set and with 0x6000832 it isn't when running the
aforementioned test?

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--
--
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 0/3] Fixup mediatek spi driver

[Leilk Liu]

Change in this patch:
1. revise coding styles.
2. delete redundant clock in prepare/unprepare_hardware.
3. fix incorrect endian usage on big-endian system.

Leilk Liu (3):
  spi: mediatek: revise coding style
  spi: mediatek: remove redundant clock in
prepare_hardware/unprepare_hardware
  spi: mediatek: fix spi incorrect endian usage

 drivers/spi/spi-mt65xx.c | 169 +--
 include/linux/platform_data/spi-mt65xx.h |   2 -
 2 files changed, 73 insertions(+), 98 deletions(-)

--
1.8.1.1.dirty

--
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/3] spi: mediatek: remove redundant clock in prepare_hardware/unprepare_hardware

[Leilk Liu]

clock in prepare_hardware/unprepare_hardware is redundant
with pm_runtime, so remove them.

Signed-off-by: Leilk Liu 
---
 drivers/spi/spi-mt65xx.c | 17 -
 1 file changed, 17 deletions(-)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 814bca4..1c2b215 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -181,13 +181,6 @@ static int mtk_spi_prepare_hardware(struct spi_master 
*master)
struct spi_transfer *trans;
struct mtk_spi *mdata = spi_master_get_devdata(master);
struct spi_message *msg = master->cur_msg;
-   int ret;
-
-   ret = clk_prepare_enable(mdata->spi_clk);
-   if (ret < 0) {
-   dev_err(&master->dev, "failed to enable clock (%d)\n", ret);
-   return ret;
-   }
 
trans = list_first_entry(&msg->transfers, struct spi_transfer,
 transfer_list);
@@ -196,15 +189,6 @@ static int mtk_spi_prepare_hardware(struct spi_master 
*master)
mtk_spi_reset(mdata);
}
 
-   return ret;
-}
-
-static int mtk_spi_unprepare_hardware(struct spi_master *master)
-{
-   struct mtk_spi *mdata = spi_master_get_devdata(master);
-
-   clk_disable_unprepare(mdata->spi_clk);
-
return 0;
 }
 
@@ -537,7 +521,6 @@ static int mtk_spi_probe(struct platform_device *pdev)
 
master->set_cs = mtk_spi_set_cs;
master->prepare_transfer_hardware = mtk_spi_prepare_hardware;
-   master->unprepare_transfer_hardware = mtk_spi_unprepare_hardware;
master->prepare_message = mtk_spi_prepare_message;
master->transfer_one = mtk_spi_transfer_one;
master->can_dma = mtk_spi_can_dma;
-- 
1.8.1.1.dirty

--
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] spi: mediatek: revise coding style

[Leilk Liu]

This patch revises mediatek spi driver coding styles.

Signed-off-by: Leilk Liu 
---
 drivers/spi/spi-mt65xx.c | 125 ---
 1 file changed, 65 insertions(+), 60 deletions(-)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index c467ce0..814bca4 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -48,15 +49,8 @@
 #define SPI_CFG1_PACKET_LOOP_MASK 0xff00
 #define SPI_CFG1_PACKET_LENGTH_MASK   0x3ff
 
-#define SPI_CMD_ACT_OFFSET0
-#define SPI_CMD_RESUME_OFFSET 1
-#define SPI_CMD_CPHA_OFFSET   8
-#define SPI_CMD_CPOL_OFFSET   9
-#define SPI_CMD_TXMSBF_OFFSET 12
-#define SPI_CMD_RXMSBF_OFFSET 13
-#define SPI_CMD_RX_ENDIAN_OFFSET  14
-#define SPI_CMD_TX_ENDIAN_OFFSET  15
-
+#define SPI_CMD_ACT  BIT(0)
+#define SPI_CMD_RESUME   BIT(1)
 #define SPI_CMD_RST  BIT(2)
 #define SPI_CMD_PAUSE_EN BIT(4)
 #define SPI_CMD_DEASSERT BIT(5)
@@ -71,12 +65,10 @@
 #define SPI_CMD_FINISH_IEBIT(16)
 #define SPI_CMD_PAUSE_IE BIT(17)
 
-#define MTK_SPI_QUIRK_PAD_SELECT 1
-/* Must explicitly send dummy Tx bytes to do Rx only transfer */
-#define MTK_SPI_QUIRK_MUST_TX 1
-
 #define MT8173_SPI_MAX_PAD_SEL 3
 
+#define MTK_SPI_PAUSE_INT_STATUS 0x2
+
 #define MTK_SPI_IDLE 0
 #define MTK_SPI_PAUSED 1
 
@@ -84,8 +76,9 @@
 #define MTK_SPI_PACKET_SIZE 1024
 
 struct mtk_spi_compatible {
-   u32 need_pad_sel;
-   u32 must_tx;
+   bool need_pad_sel;
+   /* Must explicitly send dummy Tx bytes to do Rx only transfer */
+   bool must_tx;
 };
 
 struct mtk_spi {
@@ -100,19 +93,11 @@ struct mtk_spi {
const struct mtk_spi_compatible *dev_comp;
 };
 
-static const struct mtk_spi_compatible mt6589_compat = {
-   .need_pad_sel = 0,
-   .must_tx = 0,
-};
-
-static const struct mtk_spi_compatible mt8135_compat = {
-   .need_pad_sel = 0,
-   .must_tx = 0,
-};
-
+static const struct mtk_spi_compatible mt6589_compat;
+static const struct mtk_spi_compatible mt8135_compat;
 static const struct mtk_spi_compatible mt8173_compat = {
-   .need_pad_sel = MTK_SPI_QUIRK_PAD_SELECT,
-   .must_tx = MTK_SPI_QUIRK_MUST_TX,
+   .need_pad_sel = true,
+   .must_tx = true,
 };
 
 /*
@@ -156,14 +141,24 @@ static void mtk_spi_config(struct mtk_spi *mdata,
reg_val = readl(mdata->base + SPI_CMD_REG);
 
/* set the mlsbx and mlsbtx */
-   reg_val &= ~(SPI_CMD_TXMSBF | SPI_CMD_RXMSBF);
-   reg_val |= (chip_config->tx_mlsb << SPI_CMD_TXMSBF_OFFSET);
-   reg_val |= (chip_config->rx_mlsb << SPI_CMD_RXMSBF_OFFSET);
+   if (chip_config->tx_mlsb)
+   reg_val |= SPI_CMD_TXMSBF;
+   else
+   reg_val &= ~SPI_CMD_TXMSBF;
+   if (chip_config->rx_mlsb)
+   reg_val |= SPI_CMD_RXMSBF;
+   else
+   reg_val &= ~SPI_CMD_RXMSBF;
 
/* set the tx/rx endian */
-   reg_val &= ~(SPI_CMD_TX_ENDIAN | SPI_CMD_RX_ENDIAN);
-   reg_val |= (chip_config->tx_endian << SPI_CMD_TX_ENDIAN_OFFSET);
-   reg_val |= (chip_config->rx_endian << SPI_CMD_RX_ENDIAN_OFFSET);
+   if (chip_config->tx_endian)
+   reg_val |= SPI_CMD_TX_ENDIAN;
+   else
+   reg_val &= ~SPI_CMD_TX_ENDIAN;
+   if (chip_config->rx_endian)
+   reg_val |= SPI_CMD_RX_ENDIAN;
+   else
+   reg_val &= ~SPI_CMD_RX_ENDIAN;
 
/* set finish and pause interrupt always enable */
reg_val |= SPI_CMD_FINISH_IE | SPI_CMD_PAUSE_EN;
@@ -196,7 +191,7 @@ static int mtk_spi_prepare_hardware(struct spi_master 
*master)
 
trans = list_first_entry(&msg->transfers, struct spi_transfer,
 transfer_list);
-   if (trans->cs_change == 0) {
+   if (!trans->cs_change) {
mdata->state = MTK_SPI_IDLE;
mtk_spi_reset(mdata);
}
@@ -226,9 +221,14 @@ static int mtk_spi_prepare_message(struct spi_master 
*master,
cpol = spi->mode & SPI_CPOL ? 1 : 0;
 
reg_val = readl(mdata->base + SPI_CMD_REG);
-   reg_val &= ~(SPI_CMD_CPHA | SPI_CMD_CPOL);
-   reg_val |= (cpha << SPI_CMD_CPHA_OFFSET);
-   reg_val |= (cpol << SPI_CMD_CPOL_OFFSET);
+   if (cpha)
+   reg_val |= SPI_CMD_CPHA;
+   else
+   reg_val &= ~SPI_CMD_CPHA;
+   if (cpol)
+   reg_val |= SPI_CMD_CPOL;
+   else
+   reg_val &= ~SPI_CMD_CPOL;
writel(reg_val, mdata->base + SPI_CMD_REG);
 
chip_config = spi->controller_data;
@@ -257,8 +257,7 @@ static void mtk_spi_set_cs(struct spi_device *spi, bool 
enable)
 static void mtk_spi_prepare_transfer(struct spi_master *master,
 struct spi_transfer *xfer)
 

[PATCH 3/3] spi: mediatek: fix spi incorrect endian usage

[Leilk Liu]

TX_ENDIAN/RX_ENDIAN bits define whether to reverse the endian
order of the data DMA from/to memory. The endian order should
keep the same with cpu endian.

Signed-off-by: Leilk Liu 
---
 drivers/spi/spi-mt65xx.c | 43 
 include/linux/platform_data/spi-mt65xx.h |  2 --
 2 files changed, 16 insertions(+), 29 deletions(-)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 1c2b215..eaadc7e 100644
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -107,8 +107,6 @@ static const struct mtk_spi_compatible mt8173_compat = {
 static const struct mtk_chip_config mtk_default_chip_info = {
.rx_mlsb = 1,
.tx_mlsb = 1,
-   .tx_endian = 0,
-   .rx_endian = 0,
 };
 
 static const struct of_device_id mtk_spi_of_match[] = {
@@ -151,14 +149,13 @@ static void mtk_spi_config(struct mtk_spi *mdata,
reg_val &= ~SPI_CMD_RXMSBF;
 
/* set the tx/rx endian */
-   if (chip_config->tx_endian)
-   reg_val |= SPI_CMD_TX_ENDIAN;
-   else
-   reg_val &= ~SPI_CMD_TX_ENDIAN;
-   if (chip_config->rx_endian)
-   reg_val |= SPI_CMD_RX_ENDIAN;
-   else
-   reg_val &= ~SPI_CMD_RX_ENDIAN;
+#ifdef __LITTLE_ENDIAN
+   reg_val &= ~SPI_CMD_TX_ENDIAN;
+   reg_val &= ~SPI_CMD_RX_ENDIAN;
+#else
+   reg_val |= SPI_CMD_TX_ENDIAN;
+   reg_val |= SPI_CMD_RX_ENDIAN;
+#endif
 
/* set finish and pause interrupt always enable */
reg_val |= SPI_CMD_FINISH_IE | SPI_CMD_PAUSE_EN;
@@ -348,7 +345,7 @@ static int mtk_spi_fifo_transfer(struct spi_master *master,
 struct spi_device *spi,
 struct spi_transfer *xfer)
 {
-   int cnt, i;
+   int cnt;
struct mtk_spi *mdata = spi_master_get_devdata(master);
 
mdata->cur_transfer = xfer;
@@ -360,10 +357,7 @@ static int mtk_spi_fifo_transfer(struct spi_master *master,
cnt = xfer->len / 4 + 1;
else
cnt = xfer->len / 4;
-
-   for (i = 0; i < cnt; i++)
-   writel(*((u32 *)xfer->tx_buf + i),
-  mdata->base + SPI_TX_DATA_REG);
+   iowrite32_rep(mdata->base + SPI_TX_DATA_REG, xfer->tx_buf, cnt);
 
mtk_spi_enable_transfer(master);
 
@@ -433,7 +427,7 @@ static bool mtk_spi_can_dma(struct spi_master *master,
 
 static irqreturn_t mtk_spi_interrupt(int irq, void *dev_id)
 {
-   u32 cmd, reg_val, i;
+   u32 cmd, reg_val, cnt;
struct spi_master *master = dev_id;
struct mtk_spi *mdata = spi_master_get_devdata(master);
struct spi_transfer *trans = mdata->cur_transfer;
@@ -445,18 +439,13 @@ static irqreturn_t mtk_spi_interrupt(int irq, void 
*dev_id)
mdata->state = MTK_SPI_IDLE;
 
if (!master->can_dma(master, master->cur_msg->spi, trans)) {
-   /* xfer len is not N*4 bytes every time in a transfer,
-* but SPI_RX_DATA_REG must reads 4 bytes once,
-* so rx buffer byte by byte.
-*/
if (trans->rx_buf) {
-   for (i = 0; i < mdata->xfer_len; i++) {
-   if (i % 4 == 0)
-   reg_val =
-   readl(mdata->base + SPI_RX_DATA_REG);
-   *((u8 *)(trans->rx_buf + i)) =
-   (reg_val >> ((i % 4) * 8)) & 0xff;
-   }
+   if (mdata->xfer_len % 4)
+   cnt = mdata->xfer_len / 4 + 1;
+   else
+   cnt = mdata->xfer_len / 4;
+   ioread32_rep(mdata->base + SPI_RX_DATA_REG,
+trans->rx_buf, cnt);
}
spi_finalize_current_transfer(master);
return IRQ_HANDLED;
diff --git a/include/linux/platform_data/spi-mt65xx.h 
b/include/linux/platform_data/spi-mt65xx.h
index 7512255..54b0448 100644
--- a/include/linux/platform_data/spi-mt65xx.h
+++ b/include/linux/platform_data/spi-mt65xx.h
@@ -16,7 +16,5 @@
 struct mtk_chip_config {
u32 tx_mlsb;
u32 rx_mlsb;
-   u32 tx_endian;
-   u32 rx_endian;
 };
 #endif
-- 
1.8.1.1.dirty

--
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: core: hub: Removed some warnings generated by checkpatch.pl

[Chase Metzger]

Removed some checkpatch.pl warnings saying there was an unwanted space
between function names and their arguments.

Signed-off-by: Chase Metzger 
---
 drivers/usb/core/hub.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 431839b..169e3d8 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4222,7 +4222,7 @@ static int hub_enable_device(struct usb_device *udev)
  * but it is still necessary to lock the port.
  */
 static int
-hub_port_init (struct usb_hub *hub, struct usb_device *udev, int port1,
+hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1,
int retry_counter)
 {
struct usb_device   *hdev = hub->hdev;
@@ -4526,7 +4526,7 @@ fail:
 }
 
 static void
-check_highspeed (struct usb_hub *hub, struct usb_device *udev, int port1)
+check_highspeed(struct usb_hub *hub, struct usb_device *udev, int port1)
 {
struct usb_qualifier_descriptor *qual;
int status;
@@ -4534,11 +4534,11 @@ check_highspeed (struct usb_hub *hub, struct usb_device 
*udev, int port1)
if (udev->quirks & USB_QUIRK_DEVICE_QUALIFIER)
return;
 
-   qual = kmalloc (sizeof *qual, GFP_KERNEL);
+   qual = kmalloc(sizeof *qual, GFP_KERNEL);
if (qual == NULL)
return;
 
-   status = usb_get_descriptor (udev, USB_DT_DEVICE_QUALIFIER, 0,
+   status = usb_get_descriptor(udev, USB_DT_DEVICE_QUALIFIER, 0,
qual, sizeof *qual);
if (status == sizeof *qual) {
dev_info(&udev->dev, "not running at top speed; "
@@ -4554,7 +4554,7 @@ check_highspeed (struct usb_hub *hub, struct usb_device 
*udev, int port1)
 }
 
 static unsigned
-hub_power_remaining (struct usb_hub *hub)
+hub_power_remaining(struct usb_hub *hub)
 {
struct usb_device *hdev = hub->hdev;
int remaining;
@@ -4741,7 +4741,7 @@ static void hub_port_connect(struct usb_hub *hub, int 
port1, u16 portstatus,
if (le16_to_cpu(udev->descriptor.bcdUSB) >= 0x0200
&& udev->speed == USB_SPEED_FULL
&& highspeed_hubs != 0)
-   check_highspeed (hub, udev, port1);
+   check_highspeed(hub, udev, port1);
 
/* Store the parent's children[] pointer.  At this point
 * udev becomes globally accessible, although presumably
@@ -5115,7 +5115,7 @@ static const struct usb_device_id hub_id_table[] = {
 { }/* Terminating entry */
 };
 
-MODULE_DEVICE_TABLE (usb, hub_id_table);
+MODULE_DEVICE_TABLE(usb, hub_id_table);
 
 static struct usb_driver hub_driver = {
.name = "hub",
@@ -5227,7 +5227,7 @@ static int descriptors_changed(struct usb_device *udev,
changed = 1;
break;
}
-   if (memcmp (buf, udev->rawdescriptors[index], old_length)
+   if (memcmp(buf, udev->rawdescriptors[index], old_length)
!= 0) {
dev_dbg(&udev->dev, "config index %d changed (#%d)\n",
index,
-- 
2.1.4

--
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 V3] Watchdog: Fix parent of watchdog_devices

[Pratyush Anand]

/sys/class/watchdog/watchdogn/device/modalias can help to identify the
driver/module for a given watchdog node. However, many wdt devices does not set
its parent and so, we do not see an entry for device in sysfs for such devices.

This patch fixes parent of watchdog_device so that
/sys/class/watchdog/watchdogn/device is populated.

Exceptions: booke, diag288, mpc8xxx, octeon, softdog and w83627hf -- They do not
have any parent. Not sure, how we can we identify driver for these devices.

Signed-off-by: Pratyush Anand 
---
Changes since v2:
Fixed drivers/watchdog/txx9wdt.c:134:20: error: 'pdev' undeclared
Reported-by: kbuild test robot 
Changes since v1:
Squash all commits of V1 into a single patch.
V1 was here:
http://www.spinics.net/lists/linux-watchdog/msg07220.html

 drivers/misc/mei/wd.c   | 1 +
 drivers/watchdog/bcm2835_wdt.c  | 1 +
 drivers/watchdog/bcm47xx_wdt.c  | 1 +
 drivers/watchdog/bcm_kona_wdt.c | 1 +
 drivers/watchdog/coh901327_wdt.c| 1 +
 drivers/watchdog/da9052_wdt.c   | 1 +
 drivers/watchdog/da9055_wdt.c   | 1 +
 drivers/watchdog/da9062_wdt.c   | 1 +
 drivers/watchdog/da9063_wdt.c   | 1 +
 drivers/watchdog/davinci_wdt.c  | 1 +
 drivers/watchdog/digicolor_wdt.c| 1 +
 drivers/watchdog/ep93xx_wdt.c   | 1 +
 drivers/watchdog/gpio_wdt.c | 1 +
 drivers/watchdog/ie6xx_wdt.c| 1 +
 drivers/watchdog/intel-mid_wdt.c| 1 +
 drivers/watchdog/jz4740_wdt.c   | 1 +
 drivers/watchdog/mena21_wdt.c   | 1 +
 drivers/watchdog/menf21bmc_wdt.c| 1 +
 drivers/watchdog/omap_wdt.c | 1 +
 drivers/watchdog/orion_wdt.c| 1 +
 drivers/watchdog/pnx4008_wdt.c  | 1 +
 drivers/watchdog/qcom-wdt.c | 1 +
 drivers/watchdog/retu_wdt.c | 1 +
 drivers/watchdog/rt2880_wdt.c   | 1 +
 drivers/watchdog/s3c2410_wdt.c  | 1 +
 drivers/watchdog/shwdt.c| 1 +
 drivers/watchdog/sirfsoc_wdt.c  | 1 +
 drivers/watchdog/sp805_wdt.c| 1 +
 drivers/watchdog/st_lpc_wdt.c   | 1 +
 drivers/watchdog/stmp3xxx_rtc_wdt.c | 1 +
 drivers/watchdog/tegra_wdt.c| 1 +
 drivers/watchdog/twl4030_wdt.c  | 1 +
 drivers/watchdog/txx9wdt.c  | 1 +
 drivers/watchdog/ux500_wdt.c| 1 +
 drivers/watchdog/via_wdt.c  | 1 +
 drivers/watchdog/wm831x_wdt.c   | 1 +
 drivers/watchdog/wm8350_wdt.c   | 1 +
 37 files changed, 37 insertions(+)

diff --git a/drivers/misc/mei/wd.c b/drivers/misc/mei/wd.c
index 2bc0f5089f82..b346638833b0 100644
--- a/drivers/misc/mei/wd.c
+++ b/drivers/misc/mei/wd.c
@@ -364,6 +364,7 @@ int mei_watchdog_register(struct mei_device *dev)
 
int ret;
 
+   amt_wd_dev.parent = dev->dev;
/* unlock to perserve correct locking order */
mutex_unlock(&dev->device_lock);
ret = watchdog_register_device(&amt_wd_dev);
diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
index 7116968dee12..66c3e656a616 100644
--- a/drivers/watchdog/bcm2835_wdt.c
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -182,6 +182,7 @@ static int bcm2835_wdt_probe(struct platform_device *pdev)
watchdog_set_drvdata(&bcm2835_wdt_wdd, wdt);
watchdog_init_timeout(&bcm2835_wdt_wdd, heartbeat, dev);
watchdog_set_nowayout(&bcm2835_wdt_wdd, nowayout);
+   bcm2835_wdt_wdd.parent = &pdev->dev;
err = watchdog_register_device(&bcm2835_wdt_wdd);
if (err) {
dev_err(dev, "Failed to register watchdog device");
diff --git a/drivers/watchdog/bcm47xx_wdt.c b/drivers/watchdog/bcm47xx_wdt.c
index b28a072abf78..4064a43f1360 100644
--- a/drivers/watchdog/bcm47xx_wdt.c
+++ b/drivers/watchdog/bcm47xx_wdt.c
@@ -209,6 +209,7 @@ static int bcm47xx_wdt_probe(struct platform_device *pdev)
 
wdt->wdd.info = &bcm47xx_wdt_info;
wdt->wdd.timeout = WDT_DEFAULT_TIME;
+   wdt->wdd.parent = &pdev->dev;
ret = wdt->wdd.ops->set_timeout(&wdt->wdd, timeout);
if (ret)
goto err_timer;
diff --git a/drivers/watchdog/bcm_kona_wdt.c b/drivers/watchdog/bcm_kona_wdt.c
index 22d8ae65772a..e0c98423f2c9 100644
--- a/drivers/watchdog/bcm_kona_wdt.c
+++ b/drivers/watchdog/bcm_kona_wdt.c
@@ -319,6 +319,7 @@ static int bcm_kona_wdt_probe(struct platform_device *pdev)
spin_lock_init(&wdt->lock);
platform_set_drvdata(pdev, wdt);
watchdog_set_drvdata(&bcm_kona_wdt_wdd, wdt);
+   bcm_kona_wdt_wdd.parent = &pdev->dev;
 
ret = bcm_kona_wdt_set_timeout_reg(&bcm_kona_wdt_wdd, 0);
if (ret) {
diff --git a/drivers/watchdog/coh901327_wdt.c b/drivers/watchdog/coh901327_wdt.c
index ce12f437f195..a099b77fc0b9 100644
--- a/drivers/watchdog/coh901327_wdt.c
+++ b/drivers/watchdog/coh901327_wdt.c
@@ -358,6 +358,7 @@ static int __init coh901327_probe(struct platform_device 
*pdev)
if (ret < 0)
coh901327_wdt.timeout = 60;
 
+   coh901327_wdt.parent = &pdev->dev;
ret = watchdog_register_device(&coh901327_wdt);
if (ret == 0)
  

Re: __sb_start_write() && force_trylock hack

[Dave Chinner]

On Tue, Aug 18, 2015 at 05:18:16PM +0200, Oleg Nesterov wrote:
> On 08/18, Oleg Nesterov wrote:
> >
> > When I tried to run all tests, I
> > got the new reports from lockdep.
> 
> Just in case... when I run all tests I see misc failures (with or without
> the changes above) which I didn't try to interpret. In particular xfs/073
> just hangs, "shutdown -r" doesn't work, the serial console continues to
> print
> 
>   [10784.605139] XFS (loop2): metadata I/O error: block 0x7d4948 
> ("xfs_buf_iodone_callbacks") error 5 numblks 8

EIO from the loop device.

>   [10784.605207] loop: Write error at byte offset 26843578368, length 
> 4096.
>   [10784.605222] loop: Write error at byte offset 26843578368, length 
> 4096.
>   [10784.605235] loop: Write error at byte offset 26843578368, length 
> 4096.
>   [10784.605248] loop: Write error at byte offset 26843578368, length 
> 4096.
>   [10784.605261] loop: Write error at byte offset 26843578368, length 
> 4096.

That makes me think the underlying filesystem (i.e. the fs the loop
image file is hosted on) ran out of space. Everything will go to
shit if that happens.

> again and again.
> 
> Plus some tests need a lot of time (for example generic/127 more than 70 
> minutes!),

Yup, that one only does about 50,000 synchronous writes via fsx.

If you want to run fast, use a virtual machine with 10GB RAM and use
a pair of 4GB ramdisks as the storage.

Or expunge the long running tests (look up the -X option) so they
are skipped.

> Also, tests/generic/078 on 4.2.0-rc6 (without other changes) triggered
> 
>   [ 2100.404545] BUG: looking up invalid subclass: 8
>   [ 2100.409600] turning off the locking correctness validator.

That's another lockdep annotation limitation I've had to work
around. The RENAME_WHITEOUT changes caused that by introducing the
need to lock 5 inodes at the same time (src/dst dir, src/dst file,
whiteout inode) instead of only 4.

> perhaps this was fixed by Dave's ILOCK patches.

It greatly complicated those patches, you mean?

But, yes, those patches should have fixed it - I had to shoehorn
about 15 different XFS inode locking subclasses into the 8
subclasses that lockdep supports. And I used all 8 subclasses for
the ILOCK annotations, so if theres some other annotation we need to
add (e.g more than one level of ILOCK_PARENT lock nesting) then,
well, we will need at least 16 subclasses to annotate everything.

I hate lockdep.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
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 3/3] sched: Implement interface for cgroup unified hierarchy

[Mike Galbraith]

On Tue, 2015-08-18 at 13:31 -0700, Tejun Heo wrote:

> So, this is a trade-off we're consciously making.  If there are
> common-enough use cases which require jumping across different cgroup
> domains, we'll try to figure out a way to accomodate those but by
> default migration is a very cold and expensive path.

Hm.  I know of a big data outfit to which attach/detach performance was
important enough for them to have plucked an old experimental overhead
reduction hack (mine) off lkml, and shipped it.  It must have mattered a
LOT for them (not suicidal crash test dummies) to have done that.

-Mike

--
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] regulator: qcom_smd: Set n_voltages for pm8941_lnldo

[Axel Lin]

Just setting fixed_uV is not enough, the regulator core will also check
n_voltages setting. The fixed_uV only works when n_voltages is 1.

Signed-off-by: Axel Lin 
---
 drivers/regulator/qcom_smd-regulator.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/qcom_smd-regulator.c 
b/drivers/regulator/qcom_smd-regulator.c
index 9d093ae..9c6167d 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -203,6 +203,7 @@ static const struct regulator_desc pm8941_nldo = {
 
 static const struct regulator_desc pm8941_lnldo = {
.fixed_uV = 174,
+   .n_voltages = 1,
.ops = &rpm_smps_ldo_ops,
 };
 
-- 
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/

[PATCHv4 2/2] staging: wilc1000: replace MALLOC_WILC_BUFFER() macro to avoid possible memory leak

[Raphaël Beamonte]

The MALLOC_WILC_BUFFER() macro was using a return statement, and didn't
take care of possible memory leaks and subsequent bugs when it was failing
after succeeding some allocations. This patch corrects this behavior.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/wilc1000/wilc_exported_buf.c | 31 +++-
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_exported_buf.c 
b/drivers/staging/wilc1000/wilc_exported_buf.c
index 44db496..e617b77 100644
--- a/drivers/staging/wilc1000/wilc_exported_buf.c
+++ b/drivers/staging/wilc1000/wilc_exported_buf.c
@@ -8,13 +8,6 @@
 #define LINUX_TX_SIZE  (64 * 1024)
 #define WILC1000_FW_SIZE (4 * 1024)
 
-#define MALLOC_WILC_BUFFER(name, size) \
-   exported_ ## name = kmalloc(size, GFP_KERNEL);\
-   if (!exported_ ## name) {   \
-   printk("fail to alloc: %s memory\n", exported_ ## name);  \
-   return -ENOBUFS;\
-   }
-
 /*
  * Add necessary buffer pointers
  */
@@ -46,11 +39,29 @@ static int __init wilc_module_init(void)
/*
 * alloc necessary memory
 */
-   MALLOC_WILC_BUFFER(g_tx_buf, LINUX_TX_SIZE)
-   MALLOC_WILC_BUFFER(g_rx_buf, LINUX_RX_SIZE)
-   MALLOC_WILC_BUFFER(g_fw_buf, WILC1000_FW_SIZE)
+   exported_g_tx_buf = kmalloc(LINUX_TX_SIZE, GFP_KERNEL);
+   if (!exported_g_tx_buf)
+   return -ENOMEM;
+
+   exported_g_rx_buf = kmalloc(LINUX_RX_SIZE, GFP_KERNEL);
+   if (!exported_g_rx_buf)
+   goto free_g_tx_buf;
+
+   exported_g_fw_buf = kmalloc(WILC1000_FW_SIZE, GFP_KERNEL);
+   if (!exported_g_fw_buf)
+   goto free_g_rx_buf;
 
return 0;
+
+free_g_rx_buf:
+   kfree(exported_g_rx_buf);
+   exported_g_rx_buf = NULL;
+
+free_g_tx_buf:
+   kfree(exported_g_tx_buf);
+   exported_g_tx_buf = NULL;
+
+   return -ENOMEM;
 }
 
 static void __exit wilc_module_deinit(void)
-- 
2.1.4

--
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] Clean up whitespace in vfs.txt

[Raymond Jennings]

On 08/10/15 02:31, Raymond Jennings wrote:

I noticed that vfs.txt looked kinda funky, so I went ahead and
reformatted it.

Signed-off-by: Raymond Jennings
Cc: Andrew Morton 

---

diff --git a/Documentation/filesystems/vfs.txt
b/Documentation/filesystems/vfs.txt
index 5eb8456..8ddfe06 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -114,12 +114,12 @@ members are defined:
  struct file_system_type {
const char *name;
int fs_flags;
-struct dentry *(*mount) (struct file_system_type *, int,
-   const char *, void *);
-void (*kill_sb) (struct super_block *);
-struct module *owner;
-struct file_system_type * next;
-struct list_head fs_supers;
+   struct dentry *(*mount) (struct file_system_type *, int,
+   const char *, void *);
+   void (*kill_sb) (struct super_block *);
+   struct module *owner;
+   struct file_system_type * next;
+   struct list_head fs_supers;
struct lock_class_key s_lock_key;
struct lock_class_key s_umount_key;
  };
@@ -136,7 +136,7 @@ struct file_system_type {
should be shut down
  
owner: for internal VFS use: you should initialize this to

THIS_MODULE in
-   most cases.
+   most cases.
  
next: for internal VFS use: you should initialize this to NULL
  
@@ -145,7 +145,7 @@ struct file_system_type {

  The mount() method has the following arguments:
  
struct file_system_type *fs_type: describes the filesystem, partly

initialized
-   by the specific filesystem code
+   by the specific filesystem code
  
int flags: mount flags
  
@@ -182,12 +182,12 @@ and provides a fill_super() callback instead. The

generic variants are:
mount_nodev: mount a filesystem that is not backed by a device
  
mount_single: mount a filesystem which shares the instance between

-   all mounts
+   all mounts
  
  A fill_super() callback implementation has the following arguments:
  
struct super_block *sb: the superblock structure. The callback

-   must initialize this properly.
+   must initialize this properly.
  
void *data: arbitrary mount options, usually comes as an ASCII

string (see "Mount Options" section)
@@ -208,26 +208,26 @@ This describes how the VFS can manipulate the
superblock of your
  filesystem. As of kernel 2.6.22, the following members are defined:
  
  struct super_operations {

-struct inode *(*alloc_inode)(struct super_block *sb);
-void (*destroy_inode)(struct inode *);
-
-void (*dirty_inode) (struct inode *, int flags);
-int (*write_inode) (struct inode *, int);
-void (*drop_inode) (struct inode *);
-void (*delete_inode) (struct inode *);
-void (*put_super) (struct super_block *);
-int (*sync_fs)(struct super_block *sb, int wait);
-int (*freeze_fs) (struct super_block *);
-int (*unfreeze_fs) (struct super_block *);
-int (*statfs) (struct dentry *, struct kstatfs *);
-int (*remount_fs) (struct super_block *, int *, char *);
-void (*clear_inode) (struct inode *);
-void (*umount_begin) (struct super_block *);
-
-int (*show_options)(struct seq_file *, struct dentry *);
-
-ssize_t (*quota_read)(struct super_block *, int, char *,
size_t, loff_t);
-ssize_t (*quota_write)(struct super_block *, int, const char *,
size_t, loff_t);
+   struct inode *(*alloc_inode)(struct super_block *sb);
+   void (*destroy_inode)(struct inode *);
+
+   void (*dirty_inode) (struct inode *, int flags);
+   int (*write_inode) (struct inode *, int);
+   void (*drop_inode) (struct inode *);
+   void (*delete_inode) (struct inode *);
+   void (*put_super) (struct super_block *);
+   int (*sync_fs)(struct super_block *sb, int wait);
+   int (*freeze_fs) (struct super_block *);
+   int (*unfreeze_fs) (struct super_block *);
+   int (*statfs) (struct dentry *, struct kstatfs *);
+   int (*remount_fs) (struct super_block *, int *, char *);
+   void (*clear_inode) (struct inode *);
+   void (*umount_begin) (struct super_block *);
+
+   int (*show_options)(struct seq_file *, struct dentry *);
+
+   ssize_t (*quota_read)(struct super_block *, int, char *, size_t,
loff_t);
+   ssize_t (*quota_write)(struct super_block *, int, const char *,
size_t, loff_t);
int (*nr_cached_objects)(struct super_block *);
void (*free_cached_objects)(struct super_block *, int);
  };
@@ -238,14 +238,14 @@ only called from a process context (i.e. not from
an interrupt handler
  or bottom half).
  
alloc_inode: this method is called by alloc_inode() to allocate

memory
-   for struct inode and initialize it.  If this function is not
-   defined, a simple 'struct inode' is allocated.  Normally
-   alloc_inode will be used to allocate a larger structure which
-   contains a

[PATCHv4 1/2] staging: wilc1000: remove FREE_WILC_BUFFER()

[Raphaël Beamonte]

It was just a wrapper around kfree(), so call that instead.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/wilc1000/wilc_exported_buf.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_exported_buf.c 
b/drivers/staging/wilc1000/wilc_exported_buf.c
index c3f6a0a..44db496 100644
--- a/drivers/staging/wilc1000/wilc_exported_buf.c
+++ b/drivers/staging/wilc1000/wilc_exported_buf.c
@@ -15,9 +15,6 @@
return -ENOBUFS;\
}
 
-#define FREE_WILC_BUFFER(name) \
-   kfree(exported_ ## name);
-
 /*
  * Add necessary buffer pointers
  */
@@ -59,9 +56,9 @@ static int __init wilc_module_init(void)
 static void __exit wilc_module_deinit(void)
 {
printk("wilc_module_deinit\n");
-   FREE_WILC_BUFFER(g_tx_buf)
-   FREE_WILC_BUFFER(g_rx_buf)
-   FREE_WILC_BUFFER(g_fw_buf)
+   kfree(exported_g_tx_buf);
+   kfree(exported_g_rx_buf);
+   kfree(exported_g_fw_buf);
 }
 
 MODULE_LICENSE("Dual BSD/GPL");
-- 
2.1.4

--
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/

[PATCHv4 0/2] staging: wilc1000: code improvements

[Raphaël Beamonte]

Hi,

As requested, here are the two remaining ready patches of this
patchset. I pulled and rebased against staging-testing just now.
They should thus be usable without problem!

Thanks,
Raphaël


Raphaël Beamonte (2):
  staging: wilc1000: remove FREE_WILC_BUFFER()
  staging: wilc1000: replace MALLOC_WILC_BUFFER() macro to avoid
possible memory leak

 drivers/staging/wilc1000/wilc_exported_buf.c | 40 +---
 1 file changed, 24 insertions(+), 16 deletions(-)

-- 
2.1.4

--
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: 0be964be0 "module: Sanitize RCU usage and locking" breaks symbol_put_addr?

[Rusty Russell]

Peter Zijlstra  writes:
> On Mon, Aug 17, 2015 at 04:20:09PM -0700, Laura Abbott wrote:
>> Hi,
>> 
>> We received a few bug backtraces:
>> 
>> [   41.536933] [ cut here ]
>> [   41.537545] WARNING: CPU: 1 PID: 813 at kernel/module.c:291 
>> module_assert_mutex_or_preempt+0x49/0x90()
>> [   41.538174] Modules linked in: mxl5007t af9013 ... dvb_usb_af9015(+) ... 
>> dvb_usb_v2 dvb_core rc_core ...
>> [   41.542457] CPU: 1 PID: 813 Comm: systemd-udevd Not tainted 
>> 4.2.0-0.rc6.git0.1.fc24.x86_64+debug #1
>> ...
>> [   41.549994]  [] module_assert_mutex_or_preempt+0x49/0x90
>> [   41.550664]  [] __module_address+0x32/0x150
>> [   41.552684]  [] __module_text_address+0x16/0x70
>> [   41.554701]  [] symbol_put_addr+0x29/0x40
>> [   41.555392]  [] dvb_frontend_detach+0x7d/0x90 [dvb_core]
>
>> Based on my understanding, this is spitting a warning that the module_mutex
>> isn't held. There's a nice comment in symbol_put_addr right before the call:
>> 
>> /* module_text_address is safe here: we're supposed to have reference
>>  * to module from symbol_get, so it can't go away. */
>> modaddr = __module_text_address(a);
>> 
>> so it looks like this is an erroneous warning which shouldn't need the mutex 
>> held.
>> Any ideas or am I off base here?
>
> That comment is wrong, you still need either preempt disabled or hold
> the module mutex because you're going to iterate the data structure in
> order to look up the module.

Indeed!  That comment is wrong, and your fix is good.

Care to S-O-B on it?

Thanks,
Rusty.

>
> The fact that you hold a reference on the module you're going to
> (hopefully) find, doesn't stabilize the data structure.
>
> So I think maybe symbol_put_addr() is broken and it wants something
> like:
>
> ---
>  kernel/module.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index b86b7bf1be38..8f051a106676 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1063,11 +1063,15 @@ void symbol_put_addr(void *addr)
>   if (core_kernel_text(a))
>   return;
>  
> - /* module_text_address is safe here: we're supposed to have reference
> -  * to module from symbol_get, so it can't go away. */
> + /*
> +  * Even though we hold a reference on the module; we still need to
> +  * disable preemption in order to safely traverse the data structure.
> +  */
> + preempt_disable();
>   modaddr = __module_text_address(a);
>   BUG_ON(!modaddr);
>   module_put(modaddr);
> + preempt_enable();
>  }
>  EXPORT_SYMBOL_GPL(symbol_put_addr);
>  
--
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: __sb_start_write() && force_trylock hack

[Dave Chinner]

On Tue, Aug 18, 2015 at 04:49:00PM +0200, Oleg Nesterov wrote:
> Jan, Dave, perhaps you can take a look...
> 
> On 08/14, Oleg Nesterov wrote:
> >
> > Plus another patch which removes the "trylock"
> > hack in __sb_start_write().
> 
> I meant the patch we already discussed (attached at the end). And yes,
> previously I reported it passed the tests. However, I only ran the same
> 'grep -il freeze tests/*/???' tests. When I tried to run all tests, I
> got the new reports from lockdep.
> 
>   [ 2098.281171]  May be due to missing lock nesting notation



>   [ 2098.288744] 4 locks held by fsstress/50971:
>   [ 2098.293408]  #0:  (sb_writers#13){++}, at: [] 
> __sb_start_write+0x32/0x40
>   [ 2098.303085]  #1:  (&type->i_mutex_dir_key#4/1){+.+.+.}, at: 
> [] filename_create+0x7f/0x170
>   [ 2098.314038]  #2:  (sb_internal#2){++}, at: [] 
> __sb_start_write+0x32/0x40
>   [ 2098.323711]  #3:  (&type->s_umount_key#54){++}, at: 
> [] xfs_flush_inodes+0x1c/0x40 [xfs]
>   [ 2098.334898]
>  stack backtrace:
>   [ 2098.339762] CPU: 3 PID: 50971 Comm: fsstress Not tainted 4.2.0-rc6+ 
> #27
>   [ 2098.347143] Hardware name: Intel Corporation S2600CP/S2600CP, BIOS 
> RMLSDP.86I.R3.27.D685.1305151734 05/15/2013
>   [ 2098.358303]   e70ee864 880c05a2b9c8 
> 817ee692
>   [ 2098.366603]   826f8030 880c05a2bab8 
> 810f45be
>   [ 2098.374900]   880c05a2bb20  
> 
>   [ 2098.383197] Call Trace:
>   [ 2098.385930]  [] dump_stack+0x45/0x57
>   [ 2098.391667]  [] __lock_acquire+0x1e9e/0x2040
>   [ 2098.398177]  [] ? __lock_acquire+0x9ed/0x2040
>   [ 2098.404787]  [] ? pagevec_lookup_entries+0x22/0x30
>   [ 2098.411879]  [] ? 
> truncate_inode_pages_range+0x2b2/0x7e0
>   [ 2098.419551]  [] lock_acquire+0xbe/0x150
>   [ 2098.425566]  [] ? __sb_start_write+0x32/0x40
>   [ 2098.432079]  [] percpu_down_read+0x51/0xa0
>   [ 2098.438396]  [] ? __sb_start_write+0x32/0x40
>   [ 2098.444905]  [] __sb_start_write+0x32/0x40
>   [ 2098.451244]  [] xfs_trans_alloc+0x24/0x40 [xfs]
>   [ 2098.458076]  [] xfs_inactive_truncate+0x32/0x110 
> [xfs]
>   [ 2098.465580]  [] xfs_inactive+0x102/0x120 [xfs]
>   [ 2098.472308]  [] xfs_fs_evict_inode+0x7b/0xc0 [xfs]
>   [ 2098.479401]  [] evict+0xab/0x170
>   [ 2098.484748]  [] iput+0x1a8/0x230
>   [ 2098.490100]  [] sync_inodes_sb+0x14c/0x1d0
>   [ 2098.496439]  [] xfs_flush_inodes+0x28/0x40 [xfs]
>   [ 2098.503361]  [] xfs_create+0x5c3/0x6d0 [xfs]

Another false positive.  We have a transaction handle here, but
we've failed to reserve space for it so it's not an active
transaction yet. i.e. the filesystem is operating at ENOSPC.

On an ENOSPC error, we flush out dirty data to free up reserved
delalloc space, which obviously is obviously then racing with an
unlink of an inode in another thread and so drops the final
reference to the inode, and it goes down the eviction path that runs
transactions.

But there is no deadlock here - while we have a transaction handle
allocated at xfs_create() context, it is not yet active and holds no
reservation, so it is safe for eviction here to run new transactions
as there is no active transaction in progress.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
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 v4 1/2] Add the driver of mbigen interrupt controller

[MaJun]

From: Ma Jun 

Mbigen means Message Based Interrupt Generator(MBIGEN).

Its a kind of interrupt controller that collects

the interrupts from external devices and generate msi interrupt.

Mbigen is applied to reduce the number of wire connected interrupts.

As the peripherals increasing, the interrupts lines needed is 
increasing much, especially on the Arm64 server soc.

Therefore, the interrupt pin in gic is not enough to cover so
many peripherals.

Mbigen is designed to fix this problem.

Mbigen chip locates in ITS or outside of ITS.

Mbigen chip hardware structure shows as below:

mbigen chip
|-|---|
mgn_node0 mgn_node1 mgn_node2
 |   |---|  |---|--|
dev1dev1dev2dev1   dev3   dev4

Each mbigen chip contains several mbigen nodes.

External devices can connects to mbigen node through wire connecting way.

Because a mbigen node only can support 128 interrupt maximum, depends
on the interrupt lines number of devices, a device can connects to one
more mbigen nodes.

Also, several different devices can connect to a same mbigen node.

When devices triggered interrupt,mbigen chip detects and collects 
the interrupts and generates the MBI interrupts by writing the ITS
Translator register.


Signed-off-by: Ma Jun 
---
 drivers/irqchip/Kconfig  |8 +
 drivers/irqchip/Makefile |1 +
 drivers/irqchip/irq-mbigen.c |  732 ++
 3 files changed, 741 insertions(+), 0 deletions(-)
 create mode 100644 drivers/irqchip/irq-mbigen.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 120d815..356507f 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -27,6 +27,14 @@ config ARM_GIC_V3_ITS
bool
select PCI_MSI_IRQ_DOMAIN
 
+config HISILICON_IRQ_MBIGEN
+   bool "Support mbigen interrupt controller"
+   default n
+   depends on ARM_GIC_V3 && ARM_GIC_V3_ITS
+   help
+Enable the mbigen interrupt controller used on
+Hisilicon platform.
+
 config ARM_NVIC
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 11d08c9..c6f3d66 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_ARM_GIC) += irq-gic.o 
irq-gic-common.o
 obj-$(CONFIG_ARM_GIC_V2M)  += irq-gic-v2m.o
 obj-$(CONFIG_ARM_GIC_V3)   += irq-gic-v3.o irq-gic-common.o
 obj-$(CONFIG_ARM_GIC_V3_ITS)   += irq-gic-v3-its.o 
irq-gic-v3-its-pci-msi.o irq-gic-v3-its-platform-msi.o
+obj-$(CONFIG_HISILICON_IRQ_MBIGEN) += irq-mbigen.o
 obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
 obj-$(CONFIG_ARM_VIC)  += irq-vic.o
 obj-$(CONFIG_ATMEL_AIC_IRQ)+= irq-atmel-aic-common.o 
irq-atmel-aic.o
diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
new file mode 100644
index 000..4bbbd76
--- /dev/null
+++ b/drivers/irqchip/irq-mbigen.c
@@ -0,0 +1,732 @@
+/*
+ * Copyright (C) 2014 Hisilicon Limited, All Rights Reserved.
+ * Author: Jun Ma 
+ * Author: Yun Wu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "irqchip.h"
+
+#defineMBIGEN_NODE_SHIFT   (8)
+#define MBIGEN_DEV_SHIFT   (12)
+
+/*
+ * To avoid the duplicate hwirq number problem
+ * we use device id, mbigen node number and interrupt
+ * pin offset to generate a new hwirq number in mbigen
+ * domain.
+ *
+ * hwirq[32:12]: did. device id
+ * hwirq[11:8]: nid. mbigen node number
+ * hwirq[7:0]: pin. hardware pin offset of this interrupt
+ */
+#defineCOMPOSE_MBIGEN_HWIRQ(did, nid, pin) \
+   (((did) << MBIGEN_DEV_SHIFT) | \
+   ((nid) << MBIGEN_NODE_SHIFT) | (pin))
+
+/* get the interrupt pin offset from mbigen hwirq */
+#defineGET_IRQ_PIN_OFFSET(hwirq)   ((hwirq) & 0xff)
+/* get the mbigen node number from mbigen hwirq */
+#define GET_MBIGEN_NODE_NUM(hwirq) (((hwirq) >> MBIGEN_NODE_SHIFT) & 0xf)
+/* get the mbigen device id from mbigen hwirq */
+#define GET_MBIGEN_DEVICE_ID(hwirq)\
+   (((hwirq) >> MBIGEN_DEV_SHIFT) & 0xf)
+
+/*
+ * In mbigen vector register
+ * bit[21:12]: event id value
+ 

Re: [RFC PATCH v6 0/2] Make eBPF programs output data to perf

[Wangnan (F)]

On 2015/8/14 5:49, Alexei Starovoitov wrote:

On 8/13/15 2:35 PM, pi3orama wrote:
I was thinking about whether to add a "type" field there, so we will 
have an explicit
mov const instruction before the call instruction, which can act as a 
mark. Also, if
we generate the type code automatically, a type field in this API can 
make things
easier since we don't need wrap the user structure in BPF stack. 
However, the

LLVM side is not ready yet, so we haven't post the new version.


I think the helper was clean enough. Any type info probably needs to be
done as a side channel and not part of the helper anyway.
But, ok, let's figure out the type stuff first.
Also I don't think you can rely on extra insn in front of a call insn.
Compiler can freely insert other insns there. You don't want to
introduce data flow analysis in elf parser.

I agree with you. I think we can rely on user providing correct type 
information.


Then we should make this two patches go into kernel. Both 1/2 and 2/2 are
required.

The bug mentioned in patch 1/3 of v5 series
(http://lkml.kernel.org/r/1436839171-31527-2-git-send-email-heku...@huawei.com)
has already been fixed by adjusting sample
(d6726c8145290bef950ae2538ea6ae1d96a1944b)

So we only need these two patches. Currently they can be applied to 
mainline master

clearly since you haven't add new BPF functions.

Thank you.

--
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: wilc1000: Set all options in region debugfs file

[Greg KH]

On Tue, Aug 18, 2015 at 10:32:17PM +0530, Chandra S Gorentla wrote:
> This patch allows setting all options in the module's debug region
> options file 'wilc_debug_region'.  This functionality allows the user
> to enable logging from all regions (initialization, locks, firmware
> etc.) of the driver.  Logging from the following regions is enabled
> during the driver initialization:
> 
> INIT_DBG, GENERIC_DBG, CFG80211_DBG, FIRM_DBG and HOSTAPD_DBG
> 
> Before this change, the numerical value set is equal first byte of 
> input minus 0x30 (ASCII value of '0').  Because of this, after a write 
> to this debugfs file, it is difficult to predict the regions on which
> logging is enabled.
> 
> The DBG_REGION_ALL now includes 3 additional regions TCP_ENH, SPIN_DEBUG
> and FIRM_DBG.

Why did you add these extra ones?

All of this should eventually just be deleted, as network drivers need
to use the networking driver debug interfaces, not their own crazy ones.

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: [PATCHv3] staging: wilc1000: replace MALLOC_WILC_BUFFER() macro to avoid possible memory leak

[Greg Kroah-Hartman]

On Tue, Aug 18, 2015 at 01:06:39PM -0400, Raphaël Beamonte wrote:
> 2015-08-18 5:15 GMT-04:00 Dan Carpenter :
> > To be honest, I have lost track of this patchset.  If you are planning
> > to redo the other patches can you send it in a new thread?
> 
> Actually, Greg already included the "return statement" and
> "DECLARE_WILC_BUFFER" ones.
> The replacement of printk by netdev_* needs more work on my side to
> get the net_device to be able to use the netdev_* functions.
> And apparently Greg already received another patch with the
> "FREE_WILC_BUFFER" replacement, though I don't see it in the
> staging-testing tree yet.

Maybe it was something else, but it would not apply.  Please use git
rebase to figure it out and resend all of your outstanding patches, I
too am confused at this point.

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: [PATCHv3] staging: wilc1000: use netdev_* instead of printk

[Greg Kroah-Hartman]

On Mon, Aug 17, 2015 at 07:06:40PM -0400, Raphaël Beamonte wrote:
> Signed-off-by: Raphaël Beamonte 

You can't submit a patch with no changelog information, sorry.

Always build your patches, otherwise you make maintainers really grumpy
as it breaks their build.

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/

[PATCH v4 0/2] Support Mbigen interrupt controller

[MaJun]

From: Ma Jun 

This patch adds the driver of mbigen and binding document for Hisilicon
Mbigen chips.

Compared with previous version, this version changed much.

Because during the time between V3 and V4 of my patch, there are two
related patches were committed by Mr.Marc Zyngier and Mr. Mark Rutland.

First, Mr. Marc Zyngier changed MSI frame and added supporting for
platform MSI.

https://lkml.org/lkml/2015/7/28/552

Second, Mr.Mark Rutland changed Generic PCI MSI + IOMMU topology bindings

https://lkml.org/lkml/2015/7/23/558 

Changes since v3:
--- Re-based mbigen driver on kernel 4.2.0-rc2 and Marc's patch
--- Changed the binding document based on Mark's patch.


Ma Jun (2):
  Add the driver of mbigen interrupt controller
  dt-binding:Documents of the mbigen bindings

 Documentation/devicetree/bindings/arm/mbigen.txt |   97 +++
 drivers/irqchip/Kconfig  |8 +
 drivers/irqchip/Makefile |1 +
 drivers/irqchip/irq-mbigen.c |  732 ++
 4 files changed, 838 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/mbigen.txt
 create mode 100644 drivers/irqchip/irq-mbigen.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/

[PATCH v4 2/2] dt-binding:Documents of the mbigen bindings

[MaJun]

From: Ma Jun 

Add the mbigen msi interrupt controller bindings document.

Change since v3:
--- Change the interrupt cells definition.
--- Change the mbigen node definition.
--- Add mbigen device node as sub node of mbigen.


Signed-off-by: Ma Jun 
---
 Documentation/devicetree/bindings/arm/mbigen.txt |   97 ++
 1 files changed, 97 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/mbigen.txt

diff --git a/Documentation/devicetree/bindings/arm/mbigen.txt 
b/Documentation/devicetree/bindings/arm/mbigen.txt
new file mode 100644
index 000..8e1203b
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mbigen.txt
@@ -0,0 +1,97 @@
+Hisilicon mbigen device tree bindings.
+===
+
+Mbigen means: message based interrupt generator.
+
+MBI is kind of msi interrupt only used on Non-PCI devices.
+
+To reduce the wired interrupt number connected to GIC,
+Hisilicon designed mbigen to collect and generate interrupt.
+
+
+Non-pci devices can connect to mbigen and generate the
+interrupt by writing ITS register.
+
+The mbigen chip and devices connect to mbigen have the following properties:
+
+Mbigen main node required properties:
+---
+- compatible: Should be "hisilicon,mbigen-v2"
+- interrupt controller: Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value is 4 now.
+
+  The 1st cell is the device id.
+  The 2nd cell is the mbigen node number. This value should refer to the
+  vendor Soc specification.
+  The 3rd cell is the hardware pin number of the interrupt.
+  This value depends on the Soc design.
+  The 4th cell is the interrupt trigger type, encoded as follows:
+   1 = edge triggered
+   4 = level triggered
+
+- #mbigen-node-cells :Specifies the number of cells needed to encode an
+  mbigen node information. The value is 3 now.
+
+  The 1st cell is the mbigen node number.
+  The 2nd cell is the interrupt numbers connected to.
+  The 3rd cell is the start value of pin offset.
+
+- reg: Specifies the base physical address and size of the Mbigen
+  registers.
+
+Sub-nodes:
+
+Mbigen has one or more mbigen device nodes which represents the devices
+connected to this mbigen chip.
+
+These nodes must have the following properties:
+- msi-parent: This property has two cells.
+   The 1st cell specifies the ITS this device connected.
+   The 2nd cell specifies the device id.
+- nr-interrupts:Specifies the total number of interrupt this device has.
+- mbigen_node: Specifies the information of mbigen nodes this device
+  connected.Some devices with many interrupts maybe connects with several
+  mbigen nodes.
+
+Examples:
+
+   mbigen_dsa: interrupt-controller@c008 {
+   compatible = "hisilicon,mbigen-v2";
+   interrupt-controller;
+   #interrupt-cells = <5>;
+   #mbigen-node-cells = <3>;
+   reg = <0xc008 0x1>;
+
+   mbigen_device_01 {
+   msi-parent = <&its 0x40b1c>;
+   nr-interrupts = <9>;
+   mbigen_node = <1 2 0>,
+   <3 2 4>,
+   <4 5 0>;
+   }
+
+   mbigen_device_02 {
+   msi-parent = <&its 0x40b1d>;
+   nr-interrupts = <3>;
+   mbigen_node = <6 3 0>;
+   interrupt-controller;
+   }
+   };
+
+Device connect to mbigen required properties:
+
+-interrupt-parent: Specifies the mbigen node which device connected.
+-interrupts:specifies the interrupt source.The first cell is hwirq num, the
+  second number is trigger type.
+
+Examples:
+   smmu_dsa {
+   compatible = "arm,smmu-v3";
+   reg = <0x0 0xc004 0x0 0x2>;
+   interrupt-parent  = <&mbigen_dsa>;
+   interrupts = <0x40b20 6 78 1>,
+   <0x40b20 6 79 1>,
+   <0x40b20 6 80 1>;
+   };
+
-- 
1.7.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/

Re: kexec, x86: Need a new e820 type support for kexec

[Baoquan He]

On 08/18/15 at 09:01am, Toshi Kani wrote:
> On Tue, 2015-08-18 at 16:53 +0800, Baoquan He wrote:
> > Rethink it again, maybe it's better to pass PMEM as PRAM to kdump
> > kernel if user really want to use memmap way by specifying
> > --pass-memmap-cmdline. Then I need add the PMEM and PRAM checking here
> > you pointed out. Will repost with them.
> 
> No, you should not report PMEM as PRAM.  They are different things.  The
> kdump kernel does not need to support memmap cmdline for PMEM, as the
> regular kernel does not -- memmap cmdline cannot emulate PMEM.

OK. Then it will be wrong if people intend to specify
--pass-memmap-cmdline. There might be 3 ways to fix this:

1) add PMEM support in kernel. memmap cmdline is not only used for
emulating, but for kexec/kdump using.

2) Delete --pass-memmap-cmdline option in kexec-tools since people
rarely use it.

3) Add a note in kexec-tools that option --pass-memmap-cmdline can't
work together with PMEM, people should not use it.

Thanks
Baoquan
--
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/o2iblnd: remove references to ib_reg_phsy_mr()

[Greg KH]

On Tue, Aug 18, 2015 at 09:04:35PM -0400, gr...@linuxhacker.ru wrote:
> From: Oleg Drokin 
> 
> Removed references to ib_reg_phsy_mr() and PMR which was added
> to deal with some Chelsio specific scenario, but no longer needed
> now.
> 
> Signed-off-by: Amir Shehata 
> Signed-off-by: Oleg Drokin 
> ---
> This fixes a build failure in Lustre due to ib_reg_phys_mr being removed.

You forgot a reported-by line :(

I'll go add it...

--
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] mtd: denali: Use module_pci_driver

[Vaishali Thakkar]

On Wed, Aug 19, 2015 at 6:02 AM, Brian Norris
 wrote:
>
> On Tue, Jul 07, 2015 at 12:53:45PM +0530, Vaishali Thakkar wrote:
> > Use module_pci_driver for drivers whose init and exit functions
> > only register and unregister, respectively.
> >
> > A simplified version of the Coccinelle semantic patch that performs
> > this transformation is as follows:
> >
> > @a@
> > identifier f, x;
> > @@
> > -static f(...) { return pci_register_driver(&x); }
> >
> > @b depends on a@
> > identifier e, a.x;
> > @@
> > -static e(...) { pci_unregister_driver(&x); }
> >
> > @c depends on a && b@
> > identifier a.f;
> > declarer name module_init;
> > @@
> > -module_init(f);
> >
> > @d depends on a && b && c@
> > identifier b.e, a.x;
> > declarer name module_exit;
> > declarer name module_pci_driver;
> > @@
> > -module_exit(e);
> > +module_pci_driver(x);
> >
> > Signed-off-by: Vaishali Thakkar 
>
> It seems I got 3 independent versions of the same patch... I pushed the
> most recent one, then noticed this one. Thanks anyway.

No problem. It's fine with me.

> Brian




-- 
Vaishali
--
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] zpool: define and use max type length

[Dan Streetman]

On Tue, Aug 18, 2015 at 6:38 PM, Andrew Morton
 wrote:
> On Tue, 18 Aug 2015 16:06:00 -0400 Dan Streetman  wrote:
>
>> Add ZPOOL_MAX_TYPE_NAME define, and change zpool_driver *type field to
>> type[ZPOOL_MAX_TYPE_NAME].  Remove redundant type field from struct zpool
>> and use zpool->driver->type instead.
>>
>> The define will be used by zswap for its zpool param type name length.
>>
>
> Patchset is fugly.  All this putzing around with fixed-length strings,
> worrying about overflow and is-it-null-terminated-or-isnt-it.  Shudder.
>
> It's much better to use variable-length strings everywhere.  We're not
> operating in contexts which can't use kmalloc, we're not
> performance-intensive and these strings aren't being written to
> fixed-size fields on disk or anything.  Why do we need any fixed-length
> strings?
>
> IOW, why not just replace that alloca with a kstrdup()?

for the zpool drivers (zbud and zsmalloc), the type is actually just
statically assigned, e.g. .type = "zbud", so you're right the *type is
better than type[].  I'll update it.

>
>> --- a/include/linux/zpool.h
>> +++ b/include/linux/zpool.h
>>
>> ...
>>
>> @@ -79,7 +77,7 @@ static struct zpool_driver *zpool_get_driver(char *type)
>>
>>   spin_lock(&drivers_lock);
>>   list_for_each_entry(driver, &drivers_head, list) {
>> - if (!strcmp(driver->type, type)) {
>> + if (!strncmp(driver->type, type, ZPOOL_MAX_TYPE_NAME)) {
>
> Why strncmp?  Please tell me these strings are always null-terminated.

Yep, you're right.  The driver->type always is, and the type param is
passed in from sysfs, which we can rely on to be null-terminated.

>
>
--
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 v7 2/3] cpufreq: mediatek: Add MT8173 cpufreq driver

[Pi-Cheng Chen]

Mediatek MT8173 is an ARMv8 based quad-core (2*Cortex-A53 and
2*Cortex-A72) SoC with duall clusters. For each cluster, two voltage
inputs, Vproc and Vsram are supplied by two regulators. For the big
cluster, two regulators come from different PMICs. In this case, when
scaling voltage inputs of the cluster, the voltages of two regulator
inputs need to be controlled by software explicitly under the SoC
specific limitation:

100mV < Vsram - Vproc < 200mV

which is called 'voltage tracking' mechanism. And when scaling the
frequency of cluster clock input, the input MUX need to be parented to
another "intermediate" stable PLL first and reparented to the original
PLL once the original PLL is stable at the target frequency. This patch
implements those mechanisms to enable CPU DVFS support for Mediatek
MT8173 SoC.

Signed-off-by: Pi-Cheng Chen 
Acked-by: Viresh Kumar 
---

Changes in v7:
- add of_machine_is_compatible() check to be multiplatform friendly

---
 drivers/cpufreq/Kconfig.arm  |   7 +
 drivers/cpufreq/Makefile |   1 +
 drivers/cpufreq/mt8173-cpufreq.c | 527 +++
 3 files changed, 535 insertions(+)
 create mode 100644 drivers/cpufreq/mt8173-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index cc8a71c..2bacf24 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -130,6 +130,13 @@ config ARM_KIRKWOOD_CPUFREQ
  This adds the CPUFreq driver for Marvell Kirkwood
  SoCs.
 
+config ARM_MT8173_CPUFREQ
+   bool "Mediatek MT8173 CPUFreq support"
+   depends on ARCH_MEDIATEK && REGULATOR
+   select PM_OPP
+   help
+ This adds the CPUFreq driver support for Mediatek MT8173 SoC.
+
 config ARM_OMAP2PLUS_CPUFREQ
bool "TI OMAP2+"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 2169bf7..9c75faf 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_ARM_HISI_ACPU_CPUFREQ)   += hisi-acpu-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
 obj-$(CONFIG_ARM_INTEGRATOR)   += integrator-cpufreq.o
 obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
+obj-$(CONFIG_ARM_MT8173_CPUFREQ)   += mt8173-cpufreq.o
 obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)   += pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA3xx)   += pxa3xx-cpufreq.o
diff --git a/drivers/cpufreq/mt8173-cpufreq.c b/drivers/cpufreq/mt8173-cpufreq.c
new file mode 100644
index 000..49caed2
--- /dev/null
+++ b/drivers/cpufreq/mt8173-cpufreq.c
@@ -0,0 +1,527 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Author: Pi-Cheng Chen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MIN_VOLT_SHIFT (10)
+#define MAX_VOLT_SHIFT (20)
+#define MAX_VOLT_LIMIT (115)
+#define VOLT_TOL   (1)
+
+/*
+ * The struct mtk_cpu_dvfs_info holds necessary information for doing CPU DVFS
+ * on each CPU power/clock domain of Mediatek SoCs. Each CPU cluster in
+ * Mediatek SoCs has two voltage inputs, Vproc and Vsram. In some cases the two
+ * voltage inputs need to be controlled under a hardware limitation:
+ * 100mV < Vsram - Vproc < 200mV
+ *
+ * When scaling the clock frequency of a CPU clock domain, the clock source
+ * needs to be switched to another stable PLL clock temporarily until
+ * the original PLL becomes stable at target frequency.
+ */
+struct mtk_cpu_dvfs_info {
+   struct device *cpu_dev;
+   struct regulator *proc_reg;
+   struct regulator *sram_reg;
+   struct clk *cpu_clk;
+   struct clk *inter_clk;
+   struct thermal_cooling_device *cdev;
+   int intermediate_voltage;
+   bool need_voltage_tracking;
+};
+
+static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
+   int new_vproc)
+{
+   struct regulator *proc_reg = info->proc_reg;
+   struct regulator *sram_reg = info->sram_reg;
+   int old_vproc, old_vsram, new_vsram, vsram, vproc, ret;
+
+   old_vproc = regulator_get_voltage(proc_reg);
+   old_vsram = regulator_get_voltage(sram_reg);
+   /* Vsram should not exceed the maximum allowed voltage of SoC. */
+   new_vsram = min(new_vproc + MIN_VOLT_SHIFT, MAX_VOLT_LIMIT);
+
+   if (old_vproc < new_vproc) {
+   /*
+