[PATCH] drivers:staging:ozwpan Replaced wrapper functions with actual spin lock function

[Surendra Patil]

* Replaced all the spin lock/unlock wrappers from oz_polling_lock_bh()
and oz_polllin_unlock_bh() with spin_lock_bh(_polling_lock) and
spin_unlock_bh(_polling_lock).Completely erased the wrappers defination
and declaration.
* declared g_polling_lock as global variable in header file and added comments 
to it.
Module builded successfully with sparse without warnings.

Signed-off-by: Surendra Patil 
---
 drivers/staging/ozwpan/ozpd.c| 28 ++--
 drivers/staging/ozwpan/ozpd.h|  5 +
 drivers/staging/ozwpan/ozproto.c | 15 +--
 drivers/staging/ozwpan/ozproto.h |  2 --
 4 files changed, 24 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/ozwpan/ozpd.c b/drivers/staging/ozwpan/ozpd.c
index 7436950..29a23a3 100644
--- a/drivers/staging/ozwpan/ozpd.c
+++ b/drivers/staging/ozwpan/ozpd.c
@@ -284,11 +284,11 @@ int oz_services_start(struct oz_pd *pd, u16 apps, int 
resume)
  ai->app_id);
break;
}
-   oz_polling_lock_bh();
+   spin_lock_bh(_polling_lock);
pd->total_apps |= (1paused_apps &= ~(1paused_apps |= (1total_apps &= ~(1paused_apps &= ~(1stop(pd, pause);
}
}
@@ -349,17 +349,17 @@ void oz_pd_stop(struct oz_pd *pd)
 
oz_dbg(ON, "oz_pd_stop() State = 0x%x\n", pd->state);
oz_pd_indicate_farewells(pd);
-   oz_polling_lock_bh();
+   spin_lock_bh(_polling_lock);
stop_apps = pd->total_apps;
pd->total_apps = 0;
pd->paused_apps = 0;
-   oz_polling_unlock_bh();
+   spin_unlock_bh(_polling_lock);
oz_services_stop(pd, stop_apps, 0);
-   oz_polling_lock_bh();
+   spin_lock_bh(_polling_lock);
oz_pd_set_state(pd, OZ_PD_S_STOPPED);
/* Remove from PD list.*/
list_del(>link);
-   oz_polling_unlock_bh();
+   spin_unlock_bh(_polling_lock);
oz_dbg(ON, "pd ref count = %d\n", atomic_read(>ref_count));
oz_pd_put(pd);
 }
@@ -372,9 +372,9 @@ int oz_pd_sleep(struct oz_pd *pd)
int do_stop = 0;
u16 stop_apps;
 
-   oz_polling_lock_bh();
+   spin_lock_bh(_polling_lock);
if (pd->state & (OZ_PD_S_SLEEP | OZ_PD_S_STOPPED)) {
-   oz_polling_unlock_bh();
+   spin_unlock_bh(_polling_lock);
return 0;
}
if (pd->keep_alive && pd->session_id)
@@ -383,7 +383,7 @@ int oz_pd_sleep(struct oz_pd *pd)
do_stop = 1;
 
stop_apps = pd->total_apps;
-   oz_polling_unlock_bh();
+   spin_unlock_bh(_polling_lock);
if (do_stop) {
oz_pd_stop(pd);
} else {
@@ -999,15 +999,15 @@ void oz_pd_indicate_farewells(struct oz_pd *pd)
const struct oz_app_if *ai = _app_if[OZ_APPID_USB-1];
 
while (1) {
-   oz_polling_lock_bh();
+   spin_lock_bh(_polling_lock);
if (list_empty(>farewell_list)) {
-   oz_polling_unlock_bh();
+   spin_unlock_bh(_polling_lock);
break;
}
f = list_first_entry(>farewell_list,
struct oz_farewell, link);
list_del(>link);
-   oz_polling_unlock_bh();
+   spin_unlock_bh(_polling_lock);
if (ai->farewell)
ai->farewell(pd, f->ep_num, f->report, f->len);
kfree(f);
diff --git a/drivers/staging/ozwpan/ozpd.h b/drivers/staging/ozwpan/ozpd.h
index 12c7129..56e6fdf 100644
--- a/drivers/staging/ozwpan/ozpd.h
+++ b/drivers/staging/ozwpan/ozpd.h
@@ -22,6 +22,11 @@
 #define OZ_TIMER_HEARTBEAT 2
 #define OZ_TIMER_STOP  3
 
+/* 
+ *External spinlock variable
+ */
+extern spinlock_t g_polling_lock;
+
 /* Data structure that hold information on a frame for transmisson. This is
  * built when the frame is first transmitted and is used to 

[PATCH 1/3] perf tests: Introduce perf_regs_load function on ARM

[Jean Pihet]

Introducing perf_regs_load function, which is going
to be used for dwarf unwind test in following patches.

It takes single argument as a pointer to the regs dump
buffer and populates it with current registers values.

Signed-off-by: Jean Pihet 
Cc: Steve Capper 
Cc: Corey Ashford 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Arnaldo Carvalho de Melo 
Cc: David Ahern 
Cc: Jiri Olsa 
---
 tools/perf/arch/arm/Makefile|  1 +
 tools/perf/arch/arm/include/perf_regs.h |  2 ++
 tools/perf/arch/arm/tests/regs_load.S   | 47 +
 3 files changed, 50 insertions(+)
 create mode 100644 tools/perf/arch/arm/tests/regs_load.S

diff --git a/tools/perf/arch/arm/Makefile b/tools/perf/arch/arm/Makefile
index 67e9b3d..9b8f87e 100644
--- a/tools/perf/arch/arm/Makefile
+++ b/tools/perf/arch/arm/Makefile
@@ -4,4 +4,5 @@ LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
 endif
 ifndef NO_LIBUNWIND
 LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/unwind-libunwind.o
+LIB_OBJS += $(OUTPUT)arch/$(ARCH)/tests/regs_load.o
 endif
diff --git a/tools/perf/arch/arm/include/perf_regs.h 
b/tools/perf/arch/arm/include/perf_regs.h
index 2a1cfde..1476ae7 100644
--- a/tools/perf/arch/arm/include/perf_regs.h
+++ b/tools/perf/arch/arm/include/perf_regs.h
@@ -5,6 +5,8 @@
 #include "../../util/types.h"
 #include 
 
+void perf_regs_load(u64 *regs);
+
 #define PERF_REGS_MASK ((1ULL << PERF_REG_ARM_MAX) - 1)
 #define PERF_REG_IPPERF_REG_ARM_PC
 #define PERF_REG_SPPERF_REG_ARM_SP
diff --git a/tools/perf/arch/arm/tests/regs_load.S 
b/tools/perf/arch/arm/tests/regs_load.S
new file mode 100644
index 000..916d268
--- /dev/null
+++ b/tools/perf/arch/arm/tests/regs_load.S
@@ -0,0 +1,47 @@
+#include 
+
+#define R0 0x00
+#define R1 0x08
+#define R2 0x10
+#define R3 0x18
+#define R4 0x20
+#define R5 0x28
+#define R6 0x30
+#define R7 0x38
+#define R8 0x40
+#define R9 0x48
+#define SL 0x50
+#define FP 0x58
+#define IP 0x60
+#define SP 0x68
+#define LR 0x70
+#define PC 0x78
+
+@ Implementation of void perf_regs_load(u64 *regs);
+@
+@ This functions fills in the 'regs' buffer from the actual registers values.
+@ Note that the return value (i.e. caller values) of pc is retrieved
+@ and stored, in order to skip the call to this function.
+
+.text
+.type perf_regs_load,%function
+ENTRY(perf_regs_load)
+   str r0, [r0, #R0]
+   str r1, [r0, #R1]
+   str r2, [r0, #R2]
+   str r3, [r0, #R3]
+   str r4, [r0, #R4]
+   str r5, [r0, #R5]
+   str r6, [r0, #R6]
+   str r7, [r0, #R7]
+   str r8, [r0, #R8]
+   str r9, [r0, #R9]
+   str sl, [r0, #SL]
+   str fp, [r0, #FP]
+   str ip, [r0, #IP]
+   str sp, [r0, #SP]
+   str lr, [r0, #LR]
+   str lr, [r0, #PC]   @ Save caller PC
+
+   bx lr
+ENDPROC(perf_regs_load)
-- 
1.8.1.2

--
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: Question on vhost_has_feature()

[Michael S. Tsirkin]

On Mon, Mar 03, 2014 at 11:44:23AM -0800, Paul E. McKenney wrote:
> Hello, Michael,
> 
> Just curious about the purpose of the rcu_dereference_index_check() in
> vhost_has_feature().  I don't see how it fits in.  The closest thing
> I see if the use in handle_rx(), where it selects vq->log or NULL.  But
> in that case, I would expect the usual RCU usage pattern to wrap an
> rcu_dereference() around the vq->log.
> 
> Enlightenment?
> 
>   Thanx, Paul

Hi Paul,

Yes, it's weird.  As you say the use is in handle_rx.
The way it's supposed to work is that readers take vq mutex, and
writers change the value and then take and release
vq mutex.
We did it like this because there are thinkably multiple vqs.

I tried to document it in vhost.h :
/* Readers use RCU to access memory table pointer
 * log base pointer and features.
 * Writers use mutex below.*/

If this is a problem, it's possible to restructure the code to avoid
this pattern for vhost_has_feature, pls let me know.

Thanks a lot for paying attention!


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

linux-next: Tree for Mar 4

[Stephen Rothwell]

Hi all,

This tree fails (more than usual) the powerpc allyesconfig build.

Changes since 20140303:

The powerpc tree still had its build failure.

The mfd-lj tree lost its build failure but gained another so I used the
version from next-20140210.

The wireless-next tree still had its build failure so I used the version
from next-20140224.

The omap_dss2 tree gained a build failure for which I fixed a staging
driver.

The tip tree gained a conflict against the omap_dss2 tree.

The char-misc tree still had its 2 build failures for which I reverted 2
commits.

Non-merge commits (relative to Linus' tree): 5485
 6189 files changed, 512427 insertions(+), 434892 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 210 trees (counting Linus' and 28 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (0c0bd34a1429 Merge branch 'sched-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8)
Merging arm-current/fixes (b36345759308 ARM: 7980/1: kernel: improve error 
message when LPAE config doesn't match CPU)
Merging m68k-current/for-linus (7247f55381d5 m68k: Wire up sched_setattr and 
sched_getattr)
Merging metag-fixes/fixes (f229006ec6be irq-metag*: stop set_affinity vectoring 
to offline cpus)
Merging powerpc-merge/merge (e0cf95761497 powerpc/powernv: Fix indirect XSCOM 
unmangling)
Merging sparc/master (10527106abec Merge tag 'dt-for-linus' of 
git://git.secretlab.ca/git/linux)
Merging net/master (8b4703e9bd11 macvlan: Add support for 'always_on' offload 
features)
Merging ipsec/master (3a9016f97fdc xfrm: Fix unlink race when policies are 
deleted.)
Merging sound-current/for-linus (a6b92b6650d0 ALSA: hda - Added inverted 
digital-mic handling for Acer TravelMate 8371)
Merging pci-current/for-linus (fc40363b2140 ahci: Fix broken fallback to single 
MSI mode)
Merging wireless/master (adb07df1e039 mwifiex: do not advertise usb autosuspend 
support)
Merging driver-core.current/driver-core-linus (0414855fdc4a Linux 3.14-rc5)
Merging tty.current/tty-linus (0414855fdc4a Linux 3.14-rc5)
Merging usb.current/usb-linus (0414855fdc4a Linux 3.14-rc5)
Merging staging.current/staging-linus (0414855fdc4a Linux 3.14-rc5)
Merging char-misc.current/char-misc-linus (0414855fdc4a Linux 3.14-rc5)
Merging input-current/for-linus (70b0052425ff Input: da9052_onkey - use correct 
register bit for key status)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (ee97dc7db4cb crypto: s390 - fix des and des3_ede 
ctr concurrency issue)
Merging ide/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of 
git://git.monstr.eu/linux-2.6-microblaze)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (1f42e5dd5065 of: Add self test for 
of_match_node())
Merging rr-fixes/fixes (7122c3e9154b scripts/link-vmlinux.sh: only filter 
kernel symbols for arm)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before 
cancelling delayed works)
Merging vfio

Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

[Mike Galbraith]

(boing boing boing... hell with it, today doesn't exist;)

On Tue, 2014-03-04 at 08:31 +0100, Mike Galbraith wrote: 
> On Tue, 2014-03-04 at 08:20 +0100, Henrik Austad wrote: 
> > On Tue, Mar 04, 2014 at 06:20:09AM +0100, Mike Galbraith wrote:
> > > Greetings,
> > > 
> > > While rummaging around looking for HTH a gaggle of weird a$$ machines
> > > can manage to timewarp back and forth by exactly 208 days, I stumbled
> > > across $subject which looks like it may want to borrow Salman's fix.
> > > 
> > > clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()
> > > 
> > > As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in 
> > > sched_clock",
> > > cycles * mult >> shift is overflow prone. so give it the same treatment.
> > > 
> > > Cc: Salman Qazi 
> > > Cc: John Stultz 
> > > Signed-off-by: Mike Galbraith 
> > > ---
> > >  include/linux/clocksource.h |   11 ---
> > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > > 
> > > --- a/include/linux/clocksource.h
> > > +++ b/include/linux/clocksource.h
> > > @@ -77,13 +77,18 @@ struct timecounter {
> > >   *
> > >   * XXX - This could use some mult_lxl_ll() asm optimization. Same code
> > >   * as in cyc2ns, but with unsigned result.
> > > + *
> > > + * Because it is the same as x86 __cycles_2_ns, give it the same 
> > > treatment as
> > > + * commit 4cecf6d401a "sched, x86: Avoid unnecessary overflow in 
> > > sched_clock"
> > > + * to avoid a potential cycles * mult overflow.
> > 
> > Do we normally reference a particular commit in a comment? Why not just 
> > grab the same comment and add a "this is grabbed from arch/x86/... ?
> 
> Fewer '+' signs?  History doesn't go away, so seems fine to me.
> 
> -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/


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] soc: keystone: add QMSS driver

[Santosh Shilimkar]

On Tuesday 04 March 2014 12:41 AM, Kumar Gala wrote:
> 
> On Feb 28, 2014, at 5:18 PM, Santosh Shilimkar  
> wrote:
> 
>> From: Sandeep Nair 
>>
>> The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
>> the main hardware sub system which forms the backbone of the Keystone
>> Multi-core Navigator. QMSS consist of queue managers, packed-data structure
>> processors(PDSP), linking RAM, descriptor pools and infrastructure
>> Packet DMA.
>>
>> The Queue Manager is a hardware module that is responsible for accelerating
>> management of the packet queues. Packets are queued/de-queued by writing or
>> reading descriptor address to a particular memory mapped location. The PDSPs
>> perform QMSS related functions like accumulation, QoS, or event management.
>> Linking RAM registers are used to link the descriptors which are stored in
>> descriptor RAM. Descriptor RAM is configurable as internal or external 
>> memory.
>>
>> The QMSS driver manages the PDSP setups, linking RAM regions,
>> queue pool management (allocation, push, pop and notify) and descriptor
>> pool management. The specifics on the device tree bindings for
>> QMSS can be found in:
>>Documentation/devicetree/bindings/soc/keystone-qmss.txt
>>
>> Cc: Greg Kroah-Hartman 
>> Cc: Kumar Gala 
>> Cc: Olof Johansson 
>> Cc: Arnd Bergmann 
>> Cc: Grant Likely 
>> Cc: Rob Herring 
>> Cc: Mark Rutland 
>> Signed-off-by: Sandeep Nair 
>> Signed-off-by: Santosh Shilimkar 
>> ---
>> .../devicetree/bindings/soc/keystone-qmss.txt  |  209 +++
>> drivers/Kconfig|2 +
>> drivers/Makefile   |3 +
>> drivers/soc/Kconfig|2 +
>> drivers/soc/Makefile   |5 +
>> drivers/soc/keystone/Kconfig   |   15 +
>> drivers/soc/keystone/Makefile  |5 +
>> drivers/soc/keystone/qmss_acc.c|  591 
>> drivers/soc/keystone/qmss_queue.c  | 1533 
>> 
>> drivers/soc/keystone/qmss_queue.h  |  236 +++
> 
> So this should be drivers/soc/ti, much like we use vendor in 
> drivers/net/ethernet
> 
Agree. I will change that.

>> include/linux/soc/keystone_qmss.h  |  390 +
> 
> include/linux/soc/ti/
> 
>> 11 files changed, 2991 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/soc/keystone-qmss.txt
>> create mode 100644 drivers/soc/Makefile
>> create mode 100644 drivers/soc/keystone/Kconfig
>> create mode 100644 drivers/soc/keystone/Makefile
>> create mode 100644 drivers/soc/keystone/qmss_acc.c
>> create mode 100644 drivers/soc/keystone/qmss_queue.c
>> create mode 100644 drivers/soc/keystone/qmss_queue.h
>> create mode 100644 include/linux/soc/keystone_qmss.h
> 
> [snip]
> 
>> diff --git a/drivers/Kconfig b/drivers/Kconfig
>> index 37f955f..3220516 100644
>> --- a/drivers/Kconfig
>> +++ b/drivers/Kconfig
>> @@ -146,6 +146,8 @@ source "drivers/remoteproc/Kconfig"
>>
>> source "drivers/rpmsg/Kconfig"
>>
>> +source "drivers/soc/Kconfig"
>> +
>> source "drivers/devfreq/Kconfig"
>>
>> source "drivers/extcon/Kconfig"
>> diff --git a/drivers/Makefile b/drivers/Makefile
>> index 0d8e2a4..0c22db8 100644
>> --- a/drivers/Makefile
>> +++ b/drivers/Makefile
>> @@ -146,6 +146,9 @@ obj-$(CONFIG_IOMMU_SUPPORT)  += iommu/
>> obj-$(CONFIG_REMOTEPROC) += remoteproc/
>> obj-$(CONFIG_RPMSG)  += rpmsg/
>>
>> +# SOC specific drivers
>> +obj-y   += soc/
>> +
>> # Virtualization drivers
>> obj-$(CONFIG_VIRT_DRIVERS)   += virt/
>> obj-$(CONFIG_HYPERV) += hv/
>> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
>> index 2f9d7d0..59980bd 100644
>> --- a/drivers/soc/Kconfig
>> +++ b/drivers/soc/Kconfig
>> @@ -1,3 +1,5 @@
>> menu "SOC specific Drivers"
>>
>> +source "drivers/soc/keystone/Kconfig"
>> +
>> endmenu
>> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
>> new file mode 100644
>> index 000..c5d141e
>> --- /dev/null
>> +++ b/drivers/soc/Makefile
>> @@ -0,0 +1,5 @@
>> +#
>> +# Makefile for the Linux kernel SOC specific device drivers.
>> +#
>> +
>> +obj-$(CONFIG_ARCH_KEYSTONE) += keystone/
>> diff --git a/drivers/soc/keystone/Kconfig b/drivers/soc/keystone/Kconfig
>> new file mode 100644
>> index 000..0b3131b
>> --- /dev/null
>> +++ b/drivers/soc/keystone/Kconfig
>> @@ -0,0 +1,15 @@
>> +#
>> +# TI Keystone Soc drivers
>> +#
>> +
> 
> We should have this be something like:
> 
> menuconfig SOC_TI
>   bool “TI SoC support”
>   
> 
> if SOC_TI
> 
>> +config KEYSTONE_QMSS
>> +tristate "Keystone Queue Manager Sub System"
>> +depends on ARCH_KEYSTONE
>> +help
>> +  Say y here to support the Keystone Hardware Queue Manager support.
>> +  The Queue Manager is a hardware module that is responsible for
>> +  accelerating management of the packet queues. Packets are queued/
>> +  de-queued by 

Re: [PATCH 1/3] perf tests: Introduce perf_regs_load function on ARM

[Jean Pihet]

A new version is coming asap after a review of the code with Steve.

Thx,
Jean

On 3 March 2014 10:53, Jean Pihet  wrote:
> Introducing perf_regs_load function, which is going
> to be used for dwarf unwind test in following patches.
>
> It takes single argument as a pointer to the regs dump
> buffer and populates it with current registers values.
>
> Signed-off-by: Jean Pihet 
> Cc: Corey Ashford 
> Cc: Frederic Weisbecker 
> Cc: Ingo Molnar 
> Cc: Namhyung Kim 
> Cc: Paul Mackerras 
> Cc: Peter Zijlstra 
> Cc: Arnaldo Carvalho de Melo 
> Cc: David Ahern 
> Cc: Jiri Olsa 
> ---
>  tools/perf/arch/arm/Makefile|  1 +
>  tools/perf/arch/arm/include/perf_regs.h |  2 ++
>  tools/perf/arch/arm/tests/regs_load.S   | 51 
> +
>  3 files changed, 54 insertions(+)
>  create mode 100644 tools/perf/arch/arm/tests/regs_load.S
>
> diff --git a/tools/perf/arch/arm/Makefile b/tools/perf/arch/arm/Makefile
> index 67e9b3d..9b8f87e 100644
> --- a/tools/perf/arch/arm/Makefile
> +++ b/tools/perf/arch/arm/Makefile
> @@ -4,4 +4,5 @@ LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
>  endif
>  ifndef NO_LIBUNWIND
>  LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/unwind-libunwind.o
> +LIB_OBJS += $(OUTPUT)arch/$(ARCH)/tests/regs_load.o
>  endif
> diff --git a/tools/perf/arch/arm/include/perf_regs.h 
> b/tools/perf/arch/arm/include/perf_regs.h
> index 2a1cfde..1476ae7 100644
> --- a/tools/perf/arch/arm/include/perf_regs.h
> +++ b/tools/perf/arch/arm/include/perf_regs.h
> @@ -5,6 +5,8 @@
>  #include "../../util/types.h"
>  #include 
>
> +void perf_regs_load(u64 *regs);
> +
>  #define PERF_REGS_MASK ((1ULL << PERF_REG_ARM_MAX) - 1)
>  #define PERF_REG_IPPERF_REG_ARM_PC
>  #define PERF_REG_SPPERF_REG_ARM_SP
> diff --git a/tools/perf/arch/arm/tests/regs_load.S 
> b/tools/perf/arch/arm/tests/regs_load.S
> new file mode 100644
> index 000..241c6df
> --- /dev/null
> +++ b/tools/perf/arch/arm/tests/regs_load.S
> @@ -0,0 +1,51 @@
> +#include 
> +
> +#define R0 0x00
> +#define R1 0x08
> +#define R2 0x10
> +#define R3 0x18
> +#define R4 0x20
> +#define R5 0x28
> +#define R6 0x30
> +#define R7 0x38
> +#define R8 0x40
> +#define R9 0x48
> +#define SL 0x50
> +#define FP 0x58
> +#define IP 0x60
> +#define SP 0x68
> +#define LR 0x70
> +#define PC 0x78
> +
> +@ Implementation of void perf_regs_load(u64 *regs);
> +@
> +@ This functions fills in the 'regs' buffer from the actual registers values.
> +@ Note that the return values (i.e. caller values) of sp and lr
> +@ are retrieved and stored, in order to skip the call to this function.
> +
> +.text
> +.type perf_regs_load,%function
> +ENTRY(perf_regs_load)
> +   push {r1}
> +
> +   str r0, [r0, #R0]
> +   str r1, [r0, #R1]
> +   str r2, [r0, #R2]
> +   str r3, [r0, #R3]
> +   str r4, [r0, #R4]
> +   str r5, [r0, #R5]
> +   str r6, [r0, #R6]
> +   str r7, [r0, #R7]
> +   str r8, [r0, #R8]
> +   str r9, [r0, #R9]
> +   str sl, [r0, #SL]
> +   str fp, [r0, #FP]
> +   str ip, [r0, #IP]
> +   add r1, sp, #4  @ Retrieve and save sp at entry time
> +   str r1, [r0, #SP]
> +   str lr, [r0, #LR]
> +   str lr, [r0, #PC]   @ Save caller PC
> +
> +   pop {r1}
> +   bx lr
> +ENDPROC(perf_regs_load)
> --
> 1.7.11.7
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] android: convert sync to fence api, v4

[Maarten Lankhorst]

op 03-03-14 22:11, Daniel Vetter schreef:

On Mon, Feb 17, 2014 at 04:57:19PM +0100, Maarten Lankhorst wrote:

Android syncpoints can be mapped to a timeline. This removes the need
to maintain a separate api for synchronization. I've left the android
trace events in place, but the core fence events should already be
sufficient for debugging.

v2:
- Call fence_remove_callback in sync_fence_free if not all fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.
v4:
- Merge with the upstream fixes.

Signed-off-by: Maarten Lankhorst 
---

Snipped everything but headers - Ian Lister from our android team is
signed up to have a more in-depth look at proper integration with android
syncpoints. Adding him to cc.


diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index 62e2255b1c1e..6036dbdc8e6f 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -21,6 +21,7 @@
  #include 
  #include 
  #include 
+#include 

  struct sync_timeline;
  struct sync_pt;
@@ -40,8 +41,6 @@ struct sync_fence;
   * -1 if a will signal before b
   * @free_pt: called before sync_pt is freed
   * @release_obj: called before sync_timeline is freed
- * @print_obj: deprecated
- * @print_pt: deprecated
   * @fill_driver_data: write implementation specific driver data to data.
   *  should return an error if there is not enough room
   *  as specified by size.  This information is returned
@@ -67,13 +66,6 @@ struct sync_timeline_ops {
   /* optional */
   void (*release_obj)(struct sync_timeline *sync_timeline);

- /* deprecated */
- void (*print_obj)(struct seq_file *s,
-  struct sync_timeline *sync_timeline);
-
- /* deprecated */
- void (*print_pt)(struct seq_file *s, struct sync_pt *sync_pt);
-
   /* optional */
   int (*fill_driver_data)(struct sync_pt *syncpt, void *data, int size);

@@ -104,42 +96,48 @@ struct sync_timeline {

   /* protected by child_list_lock */
   bool destroyed;
+ int context, value;

   struct list_head child_list_head;
   spinlock_t child_list_lock;

   struct list_head active_list_head;
- spinlock_t active_list_lock;

+#ifdef CONFIG_DEBUG_FS
   struct list_head sync_timeline_list;
+#endif
  };

  /**
   * struct sync_pt - sync point
- * @parent: sync_timeline to which this sync_pt belongs
+ * @fence: base fence class
   * @child_list: membership in sync_timeline.child_list_head
   * @active_list: membership in sync_timeline.active_list_head
+<<< current
   * @signaled_list: membership in temporary signaled_list on stack
   * @fence: sync_fence to which the sync_pt belongs
   * @pt_list: membership in sync_fence.pt_list_head
   * @status: 1: signaled, 0:active, <0: error
   * @timestamp: time which sync_pt status transitioned from active to
   *  signaled or error.
+===
+>>> patched

Conflict markers ...

Oops.

   */
  struct sync_pt {
- struct sync_timeline *parent;
- struct list_head child_list;
+ struct fence base;

Hm, embedding feels wrong, since that still means that I'll need to
implement two kinds of fences in i915 - one using the seqno fence to make
dma-buf sync work, and one to implmenent sync_pt to make the android folks
happy.

If I can dream I think we should have a pointer to an underlying fence
here, i.e. a struct sync_pt would just be a userspace interface wrapper to
do explicit syncing using native fences, instead of implicit syncing like
with dma-bufs. But this is all drive-by comments from a very cursory
high-level look. I might be full of myself again ;-)
-Daniel


No, the idea is that because android syncpoint is simply another type of 
dma-fence, that if you deal with normal fences then android can automatically
be handled too. The userspace fence api android exposes could be very easily 
made to work for dma-fence, just pass a dma-fence to sync_fence_create.
So exposing dma-fence would probably work for android too.

~Maarten
--
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 06/22] Add helper functions used by arm/arm64

[Roy Franz]

On Mon, Mar 3, 2014 at 6:08 AM, Matt Fleming  wrote:
> On Fri, 14 Feb, at 11:02:49AM, Roy Franz wrote:
>>
>> The get_dram_base() function is only used by arm/arm64, but
>> there is nothing architecture specific about it, which is why I put it
>> here to begin with.  I don't feel strongly about this either way.
>
> Sorry Roy, I just realised that you probably wanted a response from me
> about this last point.
>
> OK, leaving get_dram_base() in efi-stub-helper.c is fine.
>
> FYI, "NUL" isn't a typo,
>
>> - options_size++;  /* NUL termination */
> [...]
>> + options_size++;  /* NULL termination */
>
> http://en.wikipedia.org/wiki/Null_character
>
> --
> Matt Fleming, Intel Open Source Technology Center

Thanks - I'll take care of this in the next revision.

Roy
--
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] usb: gadget: return the right length in ffs_epfile_io()

[Liu, Chuansheng]

Hello Balbi,

> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Tuesday, March 04, 2014 12:30 AM
> To: Liu, Chuansheng
> Cc: ba...@ti.com; gre...@linuxfoundation.org; min...@mina86.com;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Cohen, David A;
> Zhuang, Jin Can; Wang, Yu Y
> Subject: Re: [PATCH] usb: gadget: return the right length in ffs_epfile_io()
> 
> Hi,
> 
> On Thu, Feb 27, 2014 at 02:49:31PM +0800, Chuansheng Liu wrote:
> > When the request length is aligned to maxpacketsize, sometimes
> > the return length ret > the user space requested len.
> >
> > At that time, we will use min_t(size_t, ret, len) to limit the
> > size in case of user data buffer overflow.
> >
> > But we need return the min_t(size_t, ret, len) to tell the user
> > space rightly also.
> >
> > Signed-off-by: Chuansheng Liu 

> please rebase on my "testing/next" branch

Based on your branch "testing/next", I have sent patch v2 with some ack
and reviewing, thanks.

[PATCH v2] usb: gadget: return the right length in ffs_epfile_io()


Best Regards
Chuansheng

--
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] usb: gadget: return the right length in ffs_epfile_io()

[Chuansheng Liu]

When the request length is aligned to maxpacketsize, sometimes
the return length ret > the user space requested len.

At that time, we will use min_t(size_t, ret, len) to limit the
size in case of user data buffer overflow.

But we need return the min_t(size_t, ret, len) to tell the user
space rightly also.

Acked-by: Michal Nazarewicz 
Reviewed-by: David Cohen 
Signed-off-by: Chuansheng Liu 
---
 drivers/usb/gadget/f_fs.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 42f7a0e..780f877 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -845,12 +845,14 @@ static ssize_t ffs_epfile_io(struct file *file, struct 
ffs_io_data *io_data)
 * we may end up with more data then user space has
 * space for.
 */
-   ret = ep->status;
-   if (io_data->read && ret > 0 &&
-   unlikely(copy_to_user(io_data->buf, data,
- min_t(size_t, ret,
- io_data->len
-   ret = -EFAULT;
+   ret = ep->status;
+   if (io_data->read && ret > 0) {
+   ret = min_t(size_t, ret, io_data->len);
+
+   if (unlikely(copy_to_user(io_data->buf,
+   data, ret)))
+   ret = -EFAULT;
+   }
}
kfree(data);
}
-- 
1.9.rc0

--
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] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

This patch fixes the following BUG:

> kernel BUG at mm/vmalloc.c:1132!
> PC is at vm_area_add_early+0x20/0x84
> LR is at add_static_vm_early+0xc/0x60
>
> The problem is cns3xxx_pcie_init() (device_initcall) calls the "early"
> iotable_init().

Instead of merely calling the PCIe iotable_init() from
machine_desc->map_io(), this patch adds the required mappings to the
main CNS3xxx mapping table. This means we don't convert .pfn back to
virtual addresses in pcie.c. The size of the address space consumed for
PCIe control is reduced from 96 MiB (6 * 16 MiB) to about 32 MiB (this
doesn't include MMIO address space required by PCI devices):

- Size of the PCIe "host" mapping is reduced from 16 MiB to 4 KiB.
  It's a PCI configuration address space for the local (on-chip) PCIe
  bridge.

- Size of the "CFG0" mapping is reduced from 16 MiB to 64 KiB. It's for
  Type 0 Configuration accesses, i.e., accesses to the single device
  (with possible "functions") on the other end of the PCIe link.
  We really only need a 4 KiB page at 0x8000 (see the offset
  calculation in cns3xxx_pci_cfg_base()). There is still a potential
  problem with PCI bus numbers > 0xF, are they supported?

- The code in cns3xxx_pci_cfg_base() and cns3xxx_pcie_hw_init() should
  be clearer now.

- The maximum address space allocated for PCI MMIO is now correctly
  shown in /proc/iomem as 176 MiB (per each of the two PCI "domains"
  - previously only 16 MiB were reserved).

This patch has been tested on Gateworks Laguna board, masqueraded as
CNS3420VB.

--- a/arch/arm/mach-cns3xxx/core.c
+++ b/arch/arm/mach-cns3xxx/core.c
@@ -47,6 +47,38 @@ static struct map_desc cns3xxx_io_desc[] __initdata = {
.pfn= __phys_to_pfn(CNS3XXX_PM_BASE),
.length = SZ_4K,
.type   = MT_DEVICE,
+#ifdef CONFIG_PCI
+   }, {
+   .virtual= CNS3XXX_PCIE0_HOST_BASE_VIRT,
+   .pfn= __phys_to_pfn(CNS3XXX_PCIE0_HOST_BASE),
+   .length = SZ_4K,
+   .type   = MT_DEVICE,
+   }, {
+   .virtual= CNS3XXX_PCIE0_CFG0_BASE_VIRT,
+   .pfn= __phys_to_pfn(CNS3XXX_PCIE0_CFG0_BASE),
+   .length = SZ_64K, /* really 4 KiB at offset 32 KiB */
+   .type   = MT_DEVICE,
+   }, {
+   .virtual= CNS3XXX_PCIE0_CFG1_BASE_VIRT,
+   .pfn= __phys_to_pfn(CNS3XXX_PCIE0_CFG1_BASE),
+   .length = SZ_16M,
+   .type   = MT_DEVICE,
+   }, {
+   .virtual= CNS3XXX_PCIE1_HOST_BASE_VIRT,
+   .pfn= __phys_to_pfn(CNS3XXX_PCIE1_HOST_BASE),
+   .length = SZ_4K,
+   .type   = MT_DEVICE,
+   }, {
+   .virtual= CNS3XXX_PCIE1_CFG0_BASE_VIRT,
+   .pfn= __phys_to_pfn(CNS3XXX_PCIE1_CFG0_BASE),
+   .length = SZ_64K, /* really 4 KiB at offset 32 KiB */
+   .type   = MT_DEVICE,
+   }, {
+   .virtual= CNS3XXX_PCIE1_CFG1_BASE_VIRT,
+   .pfn= __phys_to_pfn(CNS3XXX_PCIE1_CFG1_BASE),
+   .length = SZ_16M,
+   .type   = MT_DEVICE,
+#endif
},
 };
 
--- a/arch/arm/mach-cns3xxx/pcie.c
+++ b/arch/arm/mach-cns3xxx/pcie.c
@@ -23,15 +23,10 @@
 #include "cns3xxx.h"
 #include "core.h"
 
-enum cns3xxx_access_type {
-   CNS3XXX_HOST_TYPE = 0,
-   CNS3XXX_CFG0_TYPE,
-   CNS3XXX_CFG1_TYPE,
-   CNS3XXX_NUM_ACCESS_TYPES,
-};
-
 struct cns3xxx_pcie {
-   struct map_desc cfg_bases[CNS3XXX_NUM_ACCESS_TYPES];
+   void __iomem *host_regs; /* PCI config registers for host bridge */
+   void __iomem *cfg0_regs; /* PCI Type 0 config registers */
+   void __iomem *cfg1_regs; /* PCI Type 1 config registers */
unsigned int irqs[2];
struct resource res_io;
struct resource res_mem;
@@ -66,7 +61,6 @@ static void __iomem *cns3xxx_pci_cfg_base(struct pci_bus *bus,
int busno = bus->number;
int slot = PCI_SLOT(devfn);
int offset;
-   enum cns3xxx_access_type type;
void __iomem *base;
 
/* If there is no link, just show the CNS PCI bridge. */
@@ -78,17 +72,21 @@ static void __iomem *cns3xxx_pci_cfg_base(struct pci_bus 
*bus,
 * we still want to access it. For this to work, we must place
 * the first device on the same bus as the CNS PCI bridge.
 */
-   if (busno == 0) {
-   if (slot > 1)
-   return NULL;
-   type = slot;
-   } else {
-   type = CNS3XXX_CFG1_TYPE;
-   }
+   if (busno == 0) { /* directly connected PCIe bus */
+   switch (slot) {
+   case 0: /* host bridge device, function 0 only */
+   base = cnspci->host_regs;
+ 

Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

[Mike Galbraith]

On Tue, 2014-03-04 at 08:20 +0100, Henrik Austad wrote: 
> On Tue, Mar 04, 2014 at 06:20:09AM +0100, Mike Galbraith wrote:
> > Greetings,
> > 
> > While rummaging around looking for HTH a gaggle of weird a$$ machines
> > can manage to timewarp back and forth by exactly 208 days, I stumbled
> > across $subject which looks like it may want to borrow Salman's fix.
> > 
> > clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()
> > 
> > As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock",
> > cycles * mult >> shift is overflow prone. so give it the same treatment.
> > 
> > Cc: Salman Qazi 
> > Cc: John Stultz 
> > Signed-off-by: Mike Galbraith 
> > ---
> >  include/linux/clocksource.h |   11 ---
> >  1 file changed, 8 insertions(+), 3 deletions(-)
> > 
> > --- a/include/linux/clocksource.h
> > +++ b/include/linux/clocksource.h
> > @@ -77,13 +77,18 @@ struct timecounter {
> >   *
> >   * XXX - This could use some mult_lxl_ll() asm optimization. Same code
> >   * as in cyc2ns, but with unsigned result.
> > + *
> > + * Because it is the same as x86 __cycles_2_ns, give it the same treatment 
> > as
> > + * commit 4cecf6d401a "sched, x86: Avoid unnecessary overflow in 
> > sched_clock"
> > + * to avoid a potential cycles * mult overflow.
> 
> Do we normally reference a particular commit in a comment? Why not just 
> grab the same comment and add a "this is grabbed from arch/x86/... ?

Fewer '+' signs?  History doesn't go away, so seems fine to me.

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

[GIT PULL] regulator fixes for v3.14

[Mark Brown]

The following changes since commit acc3d5cec84f82ebea535fa0bd9500ac3df2aee9:

  regulator: core: Change dummy supplies error message to a warning (2014-02-21 
08:35:31 +0900)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
tags/regulator-v3.14-rc5

for you to fetch changes up to 66fda75f47dc583f1c187556e9a2c082dd64f8c6:

  regulator: core: Replace direct ops->disable usage (2014-02-25 10:31:45 +0900)


regulator: Fixes for v3.14-rc5

A couple of fixes here which ensure that regulators using the core
support for GPIO enables work in all cases by ensuring that helpers are
used consistently rather than open coding in places and hence not having
GPIO support in some of them.


Markus Pargmann (2):
  regulator: core: Replace direct ops->enable usage
  regulator: core: Replace direct ops->disable usage

 drivers/regulator/core.c | 48 
 1 file changed, 20 insertions(+), 28 deletions(-)


signature.asc
Description: Digital signature

Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

[Henrik Austad]

On Tue, Mar 04, 2014 at 06:20:09AM +0100, Mike Galbraith wrote:
> Greetings,
> 
> While rummaging around looking for HTH a gaggle of weird a$$ machines
> can manage to timewarp back and forth by exactly 208 days, I stumbled
> across $subject which looks like it may want to borrow Salman's fix.
> 
> clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()
> 
> As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock",
> cycles * mult >> shift is overflow prone. so give it the same treatment.
> 
> Cc: Salman Qazi 
> Cc: John Stultz 
> Signed-off-by: Mike Galbraith 
> ---
>  include/linux/clocksource.h |   11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> --- a/include/linux/clocksource.h
> +++ b/include/linux/clocksource.h
> @@ -77,13 +77,18 @@ struct timecounter {
>   *
>   * XXX - This could use some mult_lxl_ll() asm optimization. Same code
>   * as in cyc2ns, but with unsigned result.
> + *
> + * Because it is the same as x86 __cycles_2_ns, give it the same treatment as
> + * commit 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock"
> + * to avoid a potential cycles * mult overflow.

Do we normally reference a particular commit in a comment? Why not just 
grab the same comment and add a "this is grabbed from arch/x86/... ?

>   */
>  static inline u64 cyclecounter_cyc2ns(const struct cyclecounter *cc,
> cycle_t cycles)
>  {
> - u64 ret = (u64)cycles;
> - ret = (ret * cc->mult) >> cc->shift;
> - return ret;
> + u64 quot = (u64)cycles >> cc->shift;
> + u64 rem = (u64)cycles & ((1ULL << cc->shift) - 1);
> +
> + return  quot * cc->mult + ((rem * cc->mult) >> cc->shift);
>  }

Makes sense to me, for whatever that's worth :)

Also, tile could probably do with a similar approach for ns2cycles (not 
that I have observed any problems, but in the sense of being consistent and 
all). I'll send a patch in a separate email as not to clutter this thread 
too much :)

-- 
Henrik Austad
--
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: Add 32 bit VDSO time function support

[H. Peter Anvin]

Pretty much... contact the glibc maintainers.  However, with glibc being a GNU 
project you will have to sign a copyright transfer. 

On March 3, 2014 11:02:08 PM PST, Stefani Seibold  wrote:
>Hi,
>
>i want ask if there is a change to bring the patch back to tip?
>
>As requested the glibc patch is now available at 
>
>http://seibold.net/glibc.patch
>
>Any idea how to bring this patch into glibc? Is the process similar to
>the kernel?
>
>- Stefani

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 00/10] perf report: Add -F option for specifying output fields

[Ingo Molnar]

* Namhyung Kim  wrote:

> Hello,
> 
> This is a patchset implementing -F/--field option to setup output
> field/column as Ingo requested.
> 
> The -F option can receive any sort keys that -s option recognize, plus
> following fields (name can be changed):
> 
>   overhead, overhead_sys, overhead_us, sample, period
> 
> The overhead_guest_sys and overhead_guest_us might be avaiable when
> you profile guest machines.
> 
> Output will be sorted by in order of fields and sort keys passed by 
> -s option will be added to the output field list automatically.  If 
> you want to change the order of sorting you can give -s option in 
> addition to -F option.  To support old behavior, it'll also prepend 
> 'overhead' field to the sort keys unless you give -F option 
> explicitly.

Very nice!

For the concept:

  Acked-by: Ingo Molnar 

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] regulator: pfuze100: add pfuze200 support

[Yibin Gong]

Hi Mark,
Thanks for your reminding, PFUZE200 is currently validated on the same 
board(i.MX6Q Sabresd) which mounted with PFUZE100 before. So the patch only 
adding driver level support to let others can easily add PFUZE200 support once 
they have the PFUZE200 board. 

-Original Message-
From: Mark Brown [mailto:broo...@kernel.org] 
Sent: Tuesday, March 04, 2014 2:47 PM
To: Gong Yibin-B38343
Cc: lgirdw...@gmail.com; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] regulator: pfuze100: add pfuze200 support

On Tue, Mar 04, 2014 at 01:45:33PM +0800, Robin Gong wrote:
> support pfuze200 chip which remove SW1C and SW4 based on pfuze100.

Applied, thanks - however I just noticed that you forgot to add the compatible 
string for the new part to the DT binding, please send a followup doing that.
--
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] regulator: pfuze100: add pfuze200 support

[Mark Brown]

On Tue, Mar 04, 2014 at 07:00:26AM +, Yibin Gong wrote:

>   Thanks for your reminding, PFUZE200 is currently validated on
>   the same board(i.MX6Q Sabresd) which mounted with PFUZE100
>   before. So the patch only adding driver level support to let
>   others can easily add PFUZE200 support once they have the
>   PFUZE200 board. 

You've added a new compatible string to the driver, it's very important
that this is reflected in the binding document.


signature.asc
Description: Digital signature

[PATCH v2 4/9] drivers: staging: rtl8187se: wrap excessively long lines

[Axel Rasmussen]

Signed-off-by: Axel Rasmussen 
---
 drivers/staging/rtl8187se/r8180_core.c | 73 --
 1 file changed, 44 insertions(+), 29 deletions(-)

diff --git a/drivers/staging/rtl8187se/r8180_core.c 
b/drivers/staging/rtl8187se/r8180_core.c
index 344ef74..8681099 100644
--- a/drivers/staging/rtl8187se/r8180_core.c
+++ b/drivers/staging/rtl8187se/r8180_core.c
@@ -1021,7 +1021,8 @@ inline u16 ieeerate2rtlrate(int rate)
}
 }
 
-static u16 rtl_rate[] = {10, 20, 55, 110, 60, 90, 120, 180, 240, 360, 480, 
540, 720};
+static u16 rtl_rate[] = {10, 20, 55, 110, 60,
+   90, 120, 180, 240, 360, 480, 540, 720};
 
 inline u16 rtl8180_rate2rate(short rate)
 {
@@ -1236,7 +1237,8 @@ static void rtl8180_rx(struct net_device *dev)
tmp = priv->rxringtail;
do {
if (tmp == priv->rxring)
-   tmp  = priv->rxring + (priv->rxringcount - 
1)*rx_desc_size;
+   tmp  = priv->rxring + (priv->rxringcount - 1) *
+   rx_desc_size;
else
tmp -= rx_desc_size;
 
@@ -1322,21 +1324,26 @@ static void rtl8180_rx(struct net_device *dev)
priv->rx_skb_complete = 1;
}
 
-   signal = (unsigned char)(((*(priv->rxringtail+3)) & 
(0x00ff))>>16);
+   signal = (unsigned char)(*(priv->rxringtail + 3) &
+   0x00ff) >> 16;
signal = (signal & 0xfe) >> 1;
 
quality = (unsigned char)((*(priv->rxringtail+3)) & (0xff));
 
stats.mac_time[0] = *(priv->rxringtail+1);
stats.mac_time[1] = *(priv->rxringtail+2);
-   rxpower = ((char)(((*(priv->rxringtail+4)) & 
(0x00ff))>>16))/2 - 42;
-   RSSI = ((u8)(((*(priv->rxringtail+3)) & (0xff00))>>8)) & 
(0x7f);
+
+   rxpower = ((char)((*(priv->rxringtail + 4) &
+   0x00ff) >> 16)) / 2 - 42;
+
+   RSSI = ((u8)((*(priv->rxringtail + 3) &
+   0xff00) >> 8)) & 0x7f;
 
rate = ((*(priv->rxringtail)) &
((1<<23)|(1<<22)|(1<<21)|(1<<20)))>>20;
 
stats.rate = rtl8180_rate2rate(rate);
-   Antenna = (((*(priv->rxringtail+3)) & (0x8000)) == 0) ? 0 : 
1;
+   Antenna = (*(priv->rxringtail + 3) & 0x8000) == 0 ? 0 : 1;
if (!rtl8180_IsWirelessBMode(stats.rate)) { /* OFDM rate. */
RxAGC_dBm = rxpower+1;  /* bias */
} else { /* CCK rate. */
@@ -1345,7 +1352,8 @@ static void rtl8180_rx(struct net_device *dev)
LNA = (u8) (RxAGC_dBm & 0x60) >> 5; /* bit 6~ bit 5 */
BB  = (u8) (RxAGC_dBm & 0x1F); /* bit 4 ~ bit 0 */
 
-   RxAGC_dBm = -(LNA_gain[LNA] + (BB*2)); /* 
Pin_11b=-(LNA_gain+BB_gain) (dBm) */
+   /* Pin_11b=-(LNA_gain+BB_gain) (dBm) */
+   RxAGC_dBm = -(LNA_gain[LNA] + (BB * 2));
 
RxAGC_dBm += 4; /* bias */
}
@@ -1373,23 +1381,25 @@ static void rtl8180_rx(struct net_device *dev)
priv->RSSI = RSSI;
/* SQ translation formula is provided by SD3 DZ. 2006.06.27 */
if (quality >= 127)
-   quality = 1; /*0; */ /* 0 will cause epc to show signal 
zero , walk around now; */
+   /* 0 causes epc to show signal zero, walk around now */
+   quality = 1;
else if (quality < 27)
quality = 100;
else
quality = 127 - quality;
priv->SignalQuality = quality;
 
-   stats.signal = (u8)quality; /* priv->wstats.qual.level = priv->
-* SignalStrength;
-*/
+   /*priv->wstats.qual.level = priv->SignalStrength; */
+   stats.signal = (u8) quality;
+
stats.signalstrength = RXAGC;
if (stats.signalstrength > 100)
stats.signalstrength = 100;
-   stats.signalstrength = (stats.signalstrength * 70)/100 + 30;
+   stats.signalstrength = (stats.signalstrength * 70) / 100 + 30;
/* printk("==>rx : RXAGC is 
%d,signalstrength is %d\n",RXAGC,stats.signalstrength); */
stats.rssi = priv->wstats.qual.qual = priv->SignalQuality;
-   stats.noise = priv->wstats.qual.noise = 100 - 
priv->wstats.qual.qual;
+   stats.noise = priv->wstats.qual.noise =
+   100 - priv->wstats.qual.qual;
bHwError = (((*(priv->rxringtail)) & (0x0fff)) == 4080) |
   (((*(priv->rxringtail)) & 

[PATCH v2 3/9] drivers: staging: rtl8187se: wrap excessively long lines

[Axel Rasmussen]

Signed-off-by: Axel Rasmussen 
---
 drivers/staging/rtl8187se/r8180_core.c | 40 ++
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rtl8187se/r8180_core.c 
b/drivers/staging/rtl8187se/r8180_core.c
index 67c2583..344ef74 100644
--- a/drivers/staging/rtl8187se/r8180_core.c
+++ b/drivers/staging/rtl8187se/r8180_core.c
@@ -258,7 +258,9 @@ static int proc_get_stats_tx(struct seq_file *m, void *v)
struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
unsigned long totalOK;
 
-   totalOK = 
priv->stats.txnpokint+priv->stats.txhpokint+priv->stats.txlpokint;
+   totalOK = priv->stats.txnpokint + priv->stats.txhpokint +
+   priv->stats.txlpokint;
+
seq_printf(m,
"TX OK: %lu\n"
"TX Error: %lu\n"
@@ -468,9 +470,11 @@ static short check_nic_enought_desc(struct net_device 
*dev, int priority)
 {
struct r8180_priv *priv = ieee80211_priv(dev);
struct ieee80211_device *ieee = netdev_priv(dev);
-   int requiredbyte, required;
+   int requiredbyte;
+   int required;
 
-   requiredbyte = priv->ieee80211->fts + sizeof(struct 
ieee80211_header_data);
+   requiredbyte = priv->ieee80211->fts +
+   sizeof(struct ieee80211_header_data);
 
if (ieee->current_network.QoS_Enable)
requiredbyte += 2;
@@ -484,7 +488,7 @@ static short check_nic_enought_desc(struct net_device *dev, 
int priority)
 * between the tail and the head
 */
 
-   return (required+2 < get_curr_tx_free_desc(dev, priority));
+   return required + 2 < get_curr_tx_free_desc(dev, priority);
 }
 
 void fix_tx_fifo(struct net_device *dev)
@@ -742,43 +746,50 @@ static short alloc_tx_desc_ring(struct net_device *dev, 
int bufsize, int count,
 
switch (addr) {
case TX_MANAGEPRIORITY_RING_ADDR:
-   if (-1 == buffer_add(&(priv->txmapbufs), buf, dma_tmp, 
NULL)) {
+   if (-1 == buffer_add(>txmapbufs,
+   buf, dma_tmp, NULL)) {
DMESGE("Unable to allocate mem for buffer NP");
return -ENOMEM;
}
break;
case TX_BKPRIORITY_RING_ADDR:
-   if (-1 == buffer_add(&(priv->txbkpbufs), buf, dma_tmp, 
NULL)) {
+   if (-1 == buffer_add(>txbkpbufs,
+   buf, dma_tmp, NULL)) {
DMESGE("Unable to allocate mem for buffer LP");
return -ENOMEM;
}
break;
case TX_BEPRIORITY_RING_ADDR:
-   if (-1 == buffer_add(&(priv->txbepbufs), buf, dma_tmp, 
NULL)) {
+   if (-1 == buffer_add(>txbepbufs,
+   buf, dma_tmp, NULL)) {
DMESGE("Unable to allocate mem for buffer NP");
return -ENOMEM;
}
break;
case TX_VIPRIORITY_RING_ADDR:
-   if (-1 == buffer_add(&(priv->txvipbufs), buf, dma_tmp, 
NULL)) {
+   if (-1 == buffer_add(>txvipbufs,
+   buf, dma_tmp, NULL)) {
DMESGE("Unable to allocate mem for buffer LP");
return -ENOMEM;
}
break;
case TX_VOPRIORITY_RING_ADDR:
-   if (-1 == buffer_add(&(priv->txvopbufs), buf, dma_tmp, 
NULL)) {
+   if (-1 == buffer_add(>txvopbufs,
+   buf, dma_tmp, NULL)) {
DMESGE("Unable to allocate mem for buffer NP");
return -ENOMEM;
}
break;
case TX_HIGHPRIORITY_RING_ADDR:
-   if (-1 == buffer_add(&(priv->txhpbufs), buf, dma_tmp, 
NULL)) {
+   if (-1 == buffer_add(>txhpbufs,
+   buf, dma_tmp, NULL)) {
DMESGE("Unable to allocate mem for buffer HP");
return -ENOMEM;
}
break;
case TX_BEACON_RING_ADDR:
-   if (-1 == buffer_add(&(priv->txbeaconbufs), buf, 
dma_tmp, NULL)) {
+   if (-1 == buffer_add(>txbeaconbufs,
+   buf, dma_tmp, NULL)) {
DMESGE("Unable to allocate mem for buffer BP");
return -ENOMEM;
}
@@ -897,8 +908,8 @@ static short alloc_rx_desc_ring(struct net_device *dev, u16 
bufsize, int count)
   

[PATCH v2 0/9] drivers: staging: rtl8187se: various code cleanups

[Axel Rasmussen]

This set of patches fixes a substantial number of checkpatch.pl errors and 
warnings, and additionally it refactors some sections of code where lines were 
far too long due to organizational problems.

This second version of the patch set addresses some embarrassingly obvious 
issues in the original set of patches.

Axel Rasmussen (9):
  drivers: staging: rtl8187se: use netdev_* instead of prink
  drivers: staging: rtl8187se: refactor/clean signal smoothing
  drivers: staging: rtl8187se: wrap excessively long lines
  drivers: staging: rtl8187se: wrap excessively long lines
  drivers: staging: rtl8187se: wrap excessively long lines
  drivers: staging: rtl8187se: fixed broken indentation
  drivers: staging: rtl8187se: fixed checkpatch.pl errors
  drivers: staging: rtl8187se: wrap excessively long lines
  drivers: staging: rtl8187se: refactor wmm_param_update

 drivers/staging/rtl8187se/Module.symvers |   0
 drivers/staging/rtl8187se/r8180.h|   2 +-
 drivers/staging/rtl8187se/r8180_core.c   | 638 ++-
 3 files changed, 372 insertions(+), 268 deletions(-)
 create mode 100644 drivers/staging/rtl8187se/Module.symvers

-- 
1.8.3.2

--
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 6/9] drivers: staging: rtl8187se: fixed broken indentation

[Axel Rasmussen]

A section of code in the function rtl8180_tx was indented for no reason,
causing numerous checkpatch.pl warnings.

Signed-off-by: Axel Rasmussen 
---
 drivers/staging/rtl8187se/r8180_core.c | 132 +
 1 file changed, 69 insertions(+), 63 deletions(-)

diff --git a/drivers/staging/rtl8187se/r8180_core.c 
b/drivers/staging/rtl8187se/r8180_core.c
index fc0b6d3..d29a6d9 100644
--- a/drivers/staging/rtl8187se/r8180_core.c
+++ b/drivers/staging/rtl8187se/r8180_core.c
@@ -1750,74 +1750,80 @@ short rtl8180_tx(struct net_device *dev, u8 *txbuf, int 
len, int priority,
break;
}
 
-   memcpy(, frag_hdr->addr1, ETH_ALEN);
-   if (is_multicast_ether_addr(dest)) {
-   Duration = 0;
-   RtsDur = 0;
-   bRTSEnable = 0;
+   memcpy(, frag_hdr->addr1, ETH_ALEN);
+   if (is_multicast_ether_addr(dest)) {
+   Duration = 0;
+   RtsDur = 0;
+   bRTSEnable = 0;
+   bCTSEnable = 0;
+
+   ThisFrameTime = ComputeTxTime(len + sCrcLng,
+   rtl8180_rate2rate(rate), 0, bUseShortPreamble);
+   TxDescDuration = ThisFrameTime;
+   } else { /* Unicast packet */
+   u16 AckTime;
+
+   /* YJ,add,080828,for Keep alive */
+   priv->NumTxUnicast++;
+
+   /* Figure out ACK rate according to BSS basic rate
+* and Tx rate.
+* AckCTSLng = 14 use 1M bps send
+*/
+   AckTime = ComputeTxTime(14, 10, 0, 0);
+
+   if (((len + sCrcLng) > priv->rts) && priv->rts) { /* RTS/CTS. */
+   u16 RtsTime, CtsTime;
+   /* u16 CtsRate; */
+   bRTSEnable = 1;
bCTSEnable = 0;
 
-   ThisFrameTime = ComputeTxTime(len + sCrcLng, 
rtl8180_rate2rate(rate),
- 0, bUseShortPreamble);
-   TxDescDuration = ThisFrameTime;
-   } else { /* Unicast packet */
-   u16 AckTime;
-
-   /* YJ,add,080828,for Keep alive */
-   priv->NumTxUnicast++;
-
-   /* Figure out ACK rate according to BSS basic rate
-* and Tx rate. */
-   AckTime = ComputeTxTime(14, 10, 0, 0);  /* AckCTSLng = 
14 use 1M bps send */
-
-   if (((len + sCrcLng) > priv->rts) && priv->rts) { /* 
RTS/CTS. */
-   u16 RtsTime, CtsTime;
-   /* u16 CtsRate; */
-   bRTSEnable = 1;
-   bCTSEnable = 0;
-
-   /* Rate and time required for RTS. */
-   RtsTime = ComputeTxTime(sAckCtsLng/8, 
priv->ieee80211->basic_rate, 0, 0);
-   /* Rate and time required for CTS. */
-   CtsTime = ComputeTxTime(14, 10, 0, 0);  /* 
AckCTSLng = 14 use 1M bps send */
-
-   /* Figure out time required to transmit this 
frame. */
-   ThisFrameTime = ComputeTxTime(len + sCrcLng,
-   rtl8180_rate2rate(rate),
-   0,
-   bUseShortPreamble);
-
-   /* RTS-CTS-ThisFrame-ACK. */
-   RtsDur = CtsTime + ThisFrameTime + AckTime + 
3*aSifsTime;
-
-   TxDescDuration = RtsTime + RtsDur;
-   } else { /* Normal case. */
-   bCTSEnable = 0;
-   bRTSEnable = 0;
-   RtsDur = 0;
-
-   ThisFrameTime = ComputeTxTime(len + sCrcLng, 
rtl8180_rate2rate(rate),
- 0, 
bUseShortPreamble);
-   TxDescDuration = ThisFrameTime + aSifsTime + 
AckTime;
-   }
+   /* Rate and time required for RTS. */
+   RtsTime = ComputeTxTime(sAckCtsLng / 8,
+   priv->ieee80211->basic_rate, 0, 0);
 
-   if (!(frag_hdr->frame_control & 
IEEE80211_FCTL_MOREFRAGS)) {
-   /* ThisFrame-ACK. */
-   Duration = aSifsTime + AckTime;
-   } else { /* One or more fragments remained. */
-   u16 NextFragTime;
-   NextFragTime = ComputeTxTime(len + sCrcLng, /* 
pretend following packet length equal current packet */
-   rtl8180_rate2rate(rate),
-   

[PATCH v2 7/9] drivers: staging: rtl8187se: fixed checkpatch.pl errors

[Axel Rasmussen]

The definition of the driver's ChannelPlan array produced a large number
of checkpatch.pl errors. This patch fixes all of them by adding spaces
and wrapping the resulting overly-long lines.

Signed-off-by: Axel Rasmussen 
---
 drivers/staging/rtl8187se/r8180_core.c | 49 ++
 1 file changed, 38 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/rtl8187se/r8180_core.c 
b/drivers/staging/rtl8187se/r8180_core.c
index d29a6d9..efe1c6e 100644
--- a/drivers/staging/rtl8187se/r8180_core.c
+++ b/drivers/staging/rtl8187se/r8180_core.c
@@ -2239,17 +2239,44 @@ static void watch_dog_adaptive(unsigned long data)
 }
 
 static struct rtl8187se_channel_list channel_plan_list[] = {
-   {{1,2,3,4,5,6,7,8,9,10,11,36,40,44,48,52,56,60,64},19}, /* FCC 
*/
-   {{1,2,3,4,5,6,7,8,9,10,11},11}, /* IC */
-   {{1,2,3,4,5,6,7,8,9,10,11,12,13,36,40,44,48,52,56,60,64},21},   /* ETSI 
*/
-   {{1,2,3,4,5,6,7,8,9,10,11,12,13,36,40,44,48,52,56,60,64},21},   /* 
Spain. Change to ETSI. */
-   {{1,2,3,4,5,6,7,8,9,10,11,12,13,36,40,44,48,52,56,60,64},21},   /* 
France. Change to ETSI. */
-   {{14,36,40,44,48,52,56,60,64},9},   /* MKK 
*/
-   {{1,2,3,4,5,6,7,8,9,10,11,12,13,14, 36,40,44,48,52,56,60,64},22},/* 
MKK1 */
-   {{1,2,3,4,5,6,7,8,9,10,11,12,13,36,40,44,48,52,56,60,64},21},   /* 
Israel. */
-   {{1,2,3,4,5,6,7,8,9,10,11,12,13,34,38,42,46},17},   /* For 
11a , TELEC */
-   {{1,2,3,4,5,6,7,8,9,10,11,12,13,14},14},  /* For Global Domain. 
1-11:active scan, 12-14 passive scan. //+YJ, 080626 */
-   {{1,2,3,4,5,6,7,8,9,10,11,12,13},13} /* world wide 13: ch1~ch11 active 
scan, ch12~13 passive //lzm add 080826 */
+   /* FCC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40,
+   44, 48, 52, 56, 60, 64}, 19},
+
+   /* IC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11},
+
+   /* ETSI */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40,
+   44, 48, 52, 56, 60, 64}, 21},
+
+   /* Spain. Change to ETSI. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40,
+   44, 48, 52, 56, 60, 64}, 21},
+
+   /* France. Change to ETSI. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40,
+   44, 48, 52, 56, 60, 64}, 21},
+
+   /* MKK */
+   {{14, 36, 40, 44, 48, 52, 56, 60, 64}, 9},
+
+   /* MKK1 */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36,
+   40, 44, 48, 52, 56, 60, 64}, 22},
+
+   /* Israel. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40,
+   44, 48, 52, 56, 60, 64}, 21},
+
+   /* For 11a , TELEC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 34, 38, 42, 46}, 17},
+
+   /* For Global Domain. 1-11 active, 12-14 passive. //+YJ, 080626 */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14},
+
+   /* world wide 13: ch1~ch11 active, ch12~13 passive //lzm add 080826 */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}
 };
 
 static void rtl8180_set_channel_map(u8 channel_plan,
-- 
1.8.3.2

--
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 8/9] drivers: staging: rtl8187se: wrap excessively long lines

[Axel Rasmussen]

Signed-off-by: Axel Rasmussen 
---
 drivers/staging/rtl8187se/r8180_core.c | 125 ++---
 1 file changed, 83 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/rtl8187se/r8180_core.c 
b/drivers/staging/rtl8187se/r8180_core.c
index efe1c6e..e89907c 100644
--- a/drivers/staging/rtl8187se/r8180_core.c
+++ b/drivers/staging/rtl8187se/r8180_core.c
@@ -1996,7 +1996,8 @@ static void rtl8180_rq_tx_ack(struct net_device *dev)
 
struct r8180_priv *priv = ieee80211_priv(dev);
 
-   write_nic_byte(dev, CONFIG4, read_nic_byte(dev, CONFIG4) | 
CONFIG4_PWRMGT);
+   write_nic_byte(dev, CONFIG4,
+   read_nic_byte(dev, CONFIG4) | CONFIG4_PWRMGT);
priv->ack_tx_to_ieee = 1;
 }
 
@@ -2044,7 +2045,8 @@ static void rtl8180_hw_wakeup(struct net_device *dev)
struct r8180_priv *priv = ieee80211_priv(dev);
 
spin_lock_irqsave(>ps_lock, flags);
-   write_nic_byte(dev, CONFIG4, read_nic_byte(dev, CONFIG4) & 
~CONFIG4_PWRMGT);
+   write_nic_byte(dev, CONFIG4,
+   read_nic_byte(dev, CONFIG4) & ~CONFIG4_PWRMGT);
if (priv->rf_wakeup)
priv->rf_wakeup(dev);
spin_unlock_irqrestore(>ps_lock, flags);
@@ -2091,7 +2093,8 @@ static void rtl8180_hw_sleep(struct net_device *dev, u32 
th, u32 tl)
 
priv->DozePeriodInPast2Sec += jiffies_to_msecs(tmp);
/* as tl may be less than rb */
-   queue_delayed_work(priv->ieee80211->wq, 
>ieee80211->hw_wakeup_wq, tmp);
+   queue_delayed_work(priv->ieee80211->wq,
+   >ieee80211->hw_wakeup_wq, tmp);
}
/*
 * If we suspect the TimerInt is gone beyond tl
@@ -2221,7 +2224,8 @@ static void watch_dog_adaptive(unsigned long data)
 
/* Tx High Power Mechanism. */
if (CheckHighPower((struct net_device *)data))
-   queue_work(priv->ieee80211->wq, (void 
*)>ieee80211->tx_pw_wq);
+   queue_work(priv->ieee80211->wq,
+   (void *)>ieee80211->tx_pw_wq);
 
/* Tx Power Tracking on 87SE. */
if (CheckTxPwrTracking((struct net_device *)data))
@@ -2229,12 +2233,17 @@ static void watch_dog_adaptive(unsigned long data)
 
/* Perform DIG immediately. */
if (CheckDig((struct net_device *)data))
-   queue_work(priv->ieee80211->wq, (void 
*)>ieee80211->hw_dig_wq);
+   queue_work(priv->ieee80211->wq,
+   (void *)>ieee80211->hw_dig_wq);
+
rtl8180_watch_dog((struct net_device *)data);
 
-   queue_work(priv->ieee80211->wq, (void 
*)>ieee80211->GPIOChangeRFWorkItem);
+   queue_work(priv->ieee80211->wq,
+   (void *)>ieee80211->GPIOChangeRFWorkItem);
+
+   priv->watch_dog_timer.expires = jiffies +
+   MSECS(IEEE80211_WATCH_DOG_TIME);
 
-   priv->watch_dog_timer.expires = jiffies + 
MSECS(IEEE80211_WATCH_DOG_TIME);
add_timer(>watch_dog_timer);
 }
 
@@ -2425,7 +2434,8 @@ static short rtl8180_init(struct net_device *dev)
rtl8180_link_detect_init(>link_detect);
 
priv->ack_tx_to_ieee = 0;
-   priv->ieee80211->current_network.beacon_interval = 
DEFAULT_BEACONINTERVAL;
+   priv->ieee80211->current_network.beacon_interval =
+   DEFAULT_BEACONINTERVAL;
priv->ieee80211->iw_mode = IW_MODE_INFRA;
priv->ieee80211->softmac_features  = IEEE_SOFTMAC_SCAN |
IEEE_SOFTMAC_ASSOCIATE | IEEE_SOFTMAC_PROBERQ |
@@ -2471,7 +2481,8 @@ static short rtl8180_init(struct net_device *dev)
priv->AdRxSsBeforeSwitched = 0;
init_timer(>SwAntennaDiversityTimer);
priv->SwAntennaDiversityTimer.data = (unsigned long)dev;
-   priv->SwAntennaDiversityTimer.function = (void 
*)SwAntennaDiversityTimerCallback;
+   priv->SwAntennaDiversityTimer.function =
+   (void *)SwAntennaDiversityTimerCallback;
priv->bDigMechanism = true;
priv->InitialGain = 6;
priv->bXtalCalibration = false;
@@ -2480,7 +2491,8 @@ static short rtl8180_init(struct net_device *dev)
priv->bTxPowerTrack = false;
priv->ThermalMeter = 0;
priv->FalseAlarmRegValue = 0;
-   priv->RegDigOfdmFaUpTh = 0xc; /* Upper threshold of OFDM false alarm, 
which is used in DIG. */
+   priv->RegDigOfdmFaUpTh = 0xc; /* Upper threshold of OFDM false alarm,
+   which is used in DIG. */
priv->DIG_NumberFallbackVote = 0;
priv->DIG_NumberUpgradeVote = 0;
priv->LastSignalStrengthInPercent = 0;
@@ -2625,7 +2637,8 @@ static short rtl8180_init(struct net_device *dev)
priv->bSwAntennaDiverity = priv->EEPROMSwAntennaDiversity;
else
/* 1:disable antenna diversity, 2: enable antenna diversity. */
-   priv->bSwAntennaDiverity = priv->RegSwAntennaDiversityMechanism 
== 2;
+   priv->bSwAntennaDiverity =
+   

[PATCH v2 5/9] drivers: staging: rtl8187se: wrap excessively long lines

[Axel Rasmussen]

Signed-off-by: Axel Rasmussen 
---
 drivers/staging/rtl8187se/r8180_core.c | 63 +-
 1 file changed, 40 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/rtl8187se/r8180_core.c 
b/drivers/staging/rtl8187se/r8180_core.c
index 8681099..fc0b6d3 100644
--- a/drivers/staging/rtl8187se/r8180_core.c
+++ b/drivers/staging/rtl8187se/r8180_core.c
@@ -1578,7 +1578,7 @@ static void rtl8180_hard_data_xmit(struct sk_buff *skb, 
struct net_device *dev,
 {
struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
int mode;
-   struct ieee80211_hdr_3addr *h = (struct ieee80211_hdr_3addr *) 
skb->data;
+   struct ieee80211_hdr_3addr *h = (struct ieee80211_hdr_3addr *)skb->data;
short morefrag = (h->frame_control) & IEEE80211_FCTL_MOREFRAGS;
unsigned long flags;
int priority;
@@ -1659,7 +1659,10 @@ static void rtl8180_prepare_beacon(struct net_device 
*dev)
 
u16 word  = read_nic_word(dev, BcnItv);
word &= ~BcnItv_BcnItv; /* clear Bcn_Itv */
-   word |= cpu_to_le16(priv->ieee80211->current_network.beacon_interval); 
/* 0x64; */
+
+   /* word |= 0x64; */
+   word |= cpu_to_le16(priv->ieee80211->current_network.beacon_interval);
+
write_nic_word(dev, BcnItv, word);
 
skb = ieee80211_get_beacon(priv->ieee80211);
@@ -1687,16 +1690,17 @@ short rtl8180_tx(struct net_device *dev, u8 *txbuf, int 
len, int priority,
int buflen;
int count;
struct buffer *buflist;
-   struct ieee80211_hdr_3addr *frag_hdr = (struct ieee80211_hdr_3addr 
*)txbuf;
+   struct ieee80211_hdr_3addr *frag_hdr =
+   (struct ieee80211_hdr_3addr *)txbuf;
u8 dest[ETH_ALEN];
-   u8  bUseShortPreamble = 0;
-   u8  bCTSEnable = 0;
-   u8  bRTSEnable = 0;
-   u16 Duration = 0;
-   u16 RtsDur = 0;
-   u16 ThisFrameTime = 0;
-   u16 TxDescDuration = 0;
-   boolownbit_flag = false;
+   u8 bUseShortPreamble = 0;
+   u8 bCTSEnable = 0;
+   u8 bRTSEnable = 0;
+   u16 Duration = 0;
+   u16 RtsDur = 0;
+   u16 ThisFrameTime = 0;
+   u16 TxDescDuration = 0;
+   bool ownbit_flag = false;
 
switch (priority) {
case MANAGE_PRIORITY:
@@ -1822,7 +1826,8 @@ short rtl8180_tx(struct net_device *dev, u8 *txbuf, int 
len, int priority,
while (remain != 0) {
mb();
if (!buflist) {
-   DMESGE("TX buffer error, cannot TX frames. pri %d.", 
priority);
+   DMESGE("TX buffer error, cannot TX frames. pri %d.",
+   priority);
return -1;
}
buf = buflist->buf;
@@ -1841,43 +1846,54 @@ short rtl8180_tx(struct net_device *dev, u8 *txbuf, int 
len, int priority,
*(tail+6) = 0;
*(tail+7) = 0;
 
-   /* FIXME: this should be triggered by HW encryption 
parameters.*/
+   /* FIXME: should be triggered by HW encryption parameters.*/
*tail |= (1<<15); /* no encrypt */
 
if (remain == len && !descfrag) {
ownbit_flag = false;
-   *tail = *tail | (1<<29); /* fist segment of the packet 
*/
+   *tail = *tail | (1 << 29); /* first segment of packet */
*tail = *tail | (len);
} else {
ownbit_flag = true;
}
 
for (i = 0; i < buflen && remain > 0; i++, remain--) {
-   ((u8 *)buf)[i] = txbuf[i]; /* copy data into descriptor 
pointed DMAble buffer */
+   /* copy data into descriptor pointed DMAble buffer */
+   ((u8 *)buf)[i] = txbuf[i];
+
if (remain == 4 && i+4 >= buflen)
break;
/* ensure the last desc has at least 4 bytes payload */
-
}
txbuf = txbuf + i;
*(tail+3) = *(tail+3) & ~0xfff;
*(tail+3) = *(tail+3) | i; /* buffer length */
-   /* Use short preamble or not */
-   if 
(priv->ieee80211->current_network.capability_CAPABILITY_SHORT_PREAMBLE)
-   if (priv->plcp_preamble_mode == 1 && rate != 0) /*  
short mode now, not long! */
-   ; /* *tail |= (1<<16); */   
/* enable short preamble mode. */
+
+   /* Use short preamble or not - if true, enable short preamble */
+   /*
+   if (priv->ieee80211->current_network.capability &
+   WLAN_CAPABILITY_SHORT_PREAMBLE &&
+   priv->plcp_preamble_mode == 1 && rate != 0) {
+ 

[PATCH v2 1/9] drivers: staging: rtl8187se: use netdev_* instead of prink

[Axel Rasmussen]

Signed-off-by: Axel Rasmussen 
---
 drivers/staging/rtl8187se/Module.symvers | 0
 drivers/staging/rtl8187se/r8180_core.c   | 8 
 2 files changed, 4 insertions(+), 4 deletions(-)
 create mode 100644 drivers/staging/rtl8187se/Module.symvers

diff --git a/drivers/staging/rtl8187se/Module.symvers 
b/drivers/staging/rtl8187se/Module.symvers
new file mode 100644
index 000..e69de29
diff --git a/drivers/staging/rtl8187se/r8180_core.c 
b/drivers/staging/rtl8187se/r8180_core.c
index 7480a39..e5f8a56 100644
--- a/drivers/staging/rtl8187se/r8180_core.c
+++ b/drivers/staging/rtl8187se/r8180_core.c
@@ -649,7 +649,7 @@ void rtl8180_set_chan(struct net_device *dev, short ch)
struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
 
if ((ch > 14) || (ch < 1)) {
-   printk("In %s: Invalid chnanel %d\n", __func__, ch);
+   netdev_err(dev, "In %s: Invalid channel %d\n", __func__, ch);
return;
}
 
@@ -2019,13 +2019,13 @@ static void rtl8180_hw_sleep(struct net_device *dev, 
u32 th, u32 tl)
tl -= MSECS(4+16+7);
 
/*
-* If the interval in witch we are requested to sleep is too
+* If the interval in which we are requested to sleep is too
 * short then give up and remain awake
 */
if (((tl >= rb) && (tl-rb) <= MSECS(MIN_SLEEP_TIME))
|| ((rb > tl) && (rb-tl) < MSECS(MIN_SLEEP_TIME))) {
spin_unlock_irqrestore(>ps_lock, flags);
-   printk("too short to sleep\n");
+   netdev_warn(dev, "too short to sleep\n");
return;
}
 
@@ -2316,7 +2316,7 @@ static short rtl8180_init(struct net_device *dev)
eeprom_93cx6_read(, EEPROM_COUNTRY_CODE>>1, _val);
priv->channel_plan = eeprom_val & 0xFF;
if (priv->channel_plan > COUNTRY_CODE_GLOBAL_DOMAIN) {
-   printk("rtl8180_init:Error channel plan! Set to default.\n");
+   netdev_err(dev, "rtl8180_init: Invalid channel plan! Set to 
default.\n");
priv->channel_plan = 0;
}
 
-- 
1.8.3.2

--
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 9/9] drivers: staging: rtl8187se: refactor wmm_param_update

[Axel Rasmussen]

The function rtl8180_wmm_param_update contained two blocks of code which
were nearly identical. This patch combines those two blocks into a
single function, to reduce code duplication, and do fix some
checkpatch.pl warnings about excessively long lines due to the large
number of indents that were needed for the original blocks of code.

Signed-off-by: Axel Rasmussen 
---
 drivers/staging/rtl8187se/r8180_core.c | 119 ++---
 1 file changed, 49 insertions(+), 70 deletions(-)

diff --git a/drivers/staging/rtl8187se/r8180_core.c 
b/drivers/staging/rtl8187se/r8180_core.c
index e89907c..dc434b8 100644
--- a/drivers/staging/rtl8187se/r8180_core.c
+++ b/drivers/staging/rtl8187se/r8180_core.c
@@ -2111,16 +2111,49 @@ static void rtl8180_hw_sleep(struct net_device *dev, 
u32 th, u32 tl)
spin_unlock_irqrestore(>ps_lock, flags);
 }
 
+static void rtl8180_wmm_single_param_update(struct net_device *dev,
+   u8 mode, AC_CODING eACI, PAC_PARAM param)
+{
+   u8 u1bAIFS;
+   u32 u4bAcParam;
+
+   /* Retrieve parameters to update. */
+   /* Mode G/A: slotTimeTimer = 9; Mode B: 20 */
+   u1bAIFS = param->f.AciAifsn.f.AIFSN * ((mode & IEEE_G) == IEEE_G ?
+   9 : 20) + aSifsTime;
+   u4bAcParam = (((u32)param->f.TXOPLimit << AC_PARAM_TXOP_LIMIT_OFFSET) |
+   ((u32)param->f.Ecw.f.ECWmax << AC_PARAM_ECW_MAX_OFFSET) |
+   ((u32)param->f.Ecw.f.ECWmin << AC_PARAM_ECW_MIN_OFFSET) |
+   ((u32)u1bAIFS << AC_PARAM_AIFS_OFFSET));
+
+   switch (eACI) {
+   case AC1_BK:
+   write_nic_dword(dev, AC_BK_PARAM, u4bAcParam);
+   return;
+   case AC0_BE:
+   write_nic_dword(dev, AC_BE_PARAM, u4bAcParam);
+   return;
+   case AC2_VI:
+   write_nic_dword(dev, AC_VI_PARAM, u4bAcParam);
+   return;
+   case AC3_VO:
+   write_nic_dword(dev, AC_VO_PARAM, u4bAcParam);
+   return;
+   default:
+   pr_warn("SetHwReg8185(): invalid ACI: %d!\n", eACI);
+   return;
+   }
+}
+
 static void rtl8180_wmm_param_update(struct work_struct *work)
 {
-   struct ieee80211_device *ieee = container_of(work, struct 
ieee80211_device, wmm_param_update_wq);
+   struct ieee80211_device *ieee = container_of(work,
+   struct ieee80211_device, wmm_param_update_wq);
struct net_device *dev = ieee->dev;
u8 *ac_param = (u8 *)(ieee->current_network.wmm_param);
u8 mode = ieee->current_network.mode;
-   AC_CODING   eACI;
-   AC_PARAMAcParam;
-   PAC_PARAM   pAcParam;
-   u8 i;
+   AC_CODING eACI;
+   AC_PARAM AcParam;
 
if (!ieee->current_network.QoS_Enable) {
/* legacy ac_xx_param update */
@@ -2130,78 +2163,24 @@ static void rtl8180_wmm_param_update(struct work_struct 
*work)
AcParam.f.Ecw.f.ECWmin = 3; /* Follow 802.11 CWmin. */
AcParam.f.Ecw.f.ECWmax = 7; /* Follow 802.11 CWmax. */
AcParam.f.TXOPLimit = 0;
+
for (eACI = 0; eACI < AC_MAX; eACI++) {
AcParam.f.AciAifsn.f.ACI = (u8)eACI;
-   {
-   u8  u1bAIFS;
-   u32 u4bAcParam;
-   pAcParam = (PAC_PARAM)();
-   /* Retrieve parameters to update. */
-   u1bAIFS = pAcParam->f.AciAifsn.f.AIFSN * 
(((mode_G) == IEEE_G) ? 9 : 20) + aSifsTime;
-   u4bAcParam = 
u32)(pAcParam->f.TXOPLimit))f.AciAifsn.f.AIFSN * 
(((mode_G) == IEEE_G) ? 9 : 20) + aSifsTime;
-   u4bAcParam = u32)(pAcParam->f.TXOPLimit)) << 
AC_PARAM_TXOP_LIMIT_OFFSET)|
-   (((u32)(pAcParam->f.Ecw.f.ECWmax)) << 
AC_PARAM_ECW_MAX_OFFSET)  |
-   (((u32)(pAcParam->f.Ecw.f.ECWmin)) << 
AC_PARAM_ECW_MIN_OFFSET)  |
-   (((u32)u1bAIFS) << 
AC_PARAM_AIFS_OFFSET));
-
-   switch (eACI) {
-   case AC1_BK:
-   write_nic_dword(dev, AC_BK_PARAM, u4bAcParam);
-   break;
-   case AC0_BE:
-   write_nic_dword(dev, AC_BE_PARAM, u4bAcParam);
-   break;
-   case AC2_VI:
-   write_nic_dword(dev, AC_VI_PARAM, u4bAcParam);
-   break;
-   case AC3_VO:
-   write_nic_dword(dev, AC_VO_PARAM, u4bAcParam);
-   break;
-   

[PATCH v2 2/9] drivers: staging: rtl8187se: refactor/clean signal smoothing

[Axel Rasmussen]

Signed-off-by: Axel Rasmussen 
---
 drivers/staging/rtl8187se/r8180.h  |  2 +-
 drivers/staging/rtl8187se/r8180_core.c | 29 ++---
 2 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/rtl8187se/r8180.h 
b/drivers/staging/rtl8187se/r8180.h
index f81e6b5..5ac4673 100644
--- a/drivers/staging/rtl8187se/r8180.h
+++ b/drivers/staging/rtl8187se/r8180.h
@@ -586,7 +586,7 @@ typedef struct r8180_priv {
/* High Power Mechanism. Added by amy, 080312. */
bool bToUpdateTxPwr;
long UndecoratedSmoothedSS;
-   long UndercorateSmoothedRxPower;
+   long UndecoratedSmoothedRxPower;
u8 RSSI;
char RxPower;
u8 InitialGain;
diff --git a/drivers/staging/rtl8187se/r8180_core.c 
b/drivers/staging/rtl8187se/r8180_core.c
index e5f8a56..67c2583 100644
--- a/drivers/staging/rtl8187se/r8180_core.c
+++ b/drivers/staging/rtl8187se/r8180_core.c
@@ -1143,23 +1143,30 @@ static long TranslateToDbm8185(u8 SignalStrengthIndex)
 /*
  * Perform signal smoothing for dynamic mechanism.
  * This is different with PerformSignalSmoothing8185 in smoothing formula.
- * No dramatic adjustion is apply because dynamic mechanism need some degree
- * of correctness. Ported from 8187B.
+ * No dramatic adjustment is applied because dynamic mechanism need some
+ * degree of correctness. Ported from 8187B.
  */
 static void PerformUndecoratedSignalSmoothing8185(struct r8180_priv *priv,
  bool bCckRate)
 {
-   /* Determin the current packet is CCK rate. */
+   long smoothedSS;
+   long smoothedRx;
+
+   /* Determine the current packet is CCK rate. */
priv->bCurCCKPkt = bCckRate;
 
+   smoothedSS = priv->SignalStrength * 10;
+
if (priv->UndecoratedSmoothedSS >= 0)
-   priv->UndecoratedSmoothedSS = ((priv->UndecoratedSmoothedSS * 
5) +
-  (priv->SignalStrength * 10)) / 6;
-   else
-   priv->UndecoratedSmoothedSS = priv->SignalStrength * 10;
+   smoothedSS = ((priv->UndecoratedSmoothedSS * 5) +
+   smoothedSS) / 6;
+
+   priv->UndecoratedSmoothedSS = smoothedSS;
+
+   smoothedRx = ((priv->UndecoratedSmoothedRxPower * 50) +
+   (priv->RxPower * 11)) / 60;
 
-   priv->UndercorateSmoothedRxPower = ((priv->UndercorateSmoothedRxPower * 
50) +
-   (priv->RxPower * 11)) / 60;
+   priv->UndecoratedSmoothedRxPower = smoothedRx;
 
if (bCckRate)
priv->CurCCKRSSI = priv->RSSI;
@@ -1399,8 +1406,8 @@ static void rtl8180_rx(struct net_device *dev)
 
/* For good-looking singal strength. */
SignalStrengthIndex = NetgearSignalStrengthTranslate(
-   
priv->LastSignalStrengthInPercent,
-   priv->SignalStrength);
+   priv->LastSignalStrengthInPercent,
+   priv->SignalStrength);
 
priv->LastSignalStrengthInPercent = SignalStrengthIndex;
priv->Stats_SignalStrength = 
TranslateToDbm8185((u8)SignalStrengthIndex);
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

[Mike Galbraith]

On Tue, 2014-03-04 at 14:40 +0800, John Stultz wrote: 
> On Tue, Mar 4, 2014 at 1:38 PM, Mike Galbraith  wrote:
> > (crap crap crap... M.A.I.N.T.A.I.N.E.R.S _dummy_)
> >
> > clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()
> >
> > As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock",
> > cycles * mult >> shift is overflow prone. so give it the same treatment.
> >
> > Cc: Salman Qazi 
> > Cc: John Stultz ,
> > Signed-off-by: Mike Galbraith 
> 
> Thanks for sending this in!  Curious exactly how the issue was being
> triggered?

Dunno that it is.  This is the result of me rummaging around, looking
for any excuse what-so-ever for a small and identical group of weird a$$
boxen running old 2.6.32 kernels (w. 208 day fix!) to manage to hop back
and forth in time by exactly 208 days.  Grep showed me that function, so
I scurried off and swiped the fix.

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

Re: linux-next: build failure after merge of the mfd-lj tree

[Lee Jones]

Stephen,

> > After merging the mfd-lj tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/mfd/tps65218: struct i2c_device_id is 32 bytes.  The last of 1 is:
> > 0x74 0x70 0x73 0x36 0x35 0x32 0x31 0x38 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
> > 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x00 0x00 0x00 0x00 0x00 
> > 0x00 0x00 
> > FATAL: drivers/mfd/tps65218: struct i2c_device_id is not terminated with a 
> > NULL entry!
> > 
> > Caused by commit cc493e30e3a1 ("mfd: tps65218: Add driver for the
> > TPS65218 PMIC").
> 
> Now that the otherproblem is fixed, I am getting this one again :-(

That's annoying. I thought I'd built all of the new drivers.

> > I have used the mfd-lj tree from next-20140210 for today.
> 
> Again.

Sorry, again.

/me investigates.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/

Add 32 bit VDSO time function support

[Stefani Seibold]

Hi,

i want ask if there is a change to bring the patch back to tip?

As requested the glibc patch is now available at 

http://seibold.net/glibc.patch

Any idea how to bring this patch into glibc? Is the process similar to
the kernel?

- Stefani

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

[sched

[kernel test robot]

TO: Alex Shi 
CC: Alex Shi 

FYI, we noticed the below changes on commit
815296e0446ff6c405ef64708 ("sched: unify imbalance bias for target group
")

test case: lkp-snb01/micro/aim7/compute

bf0607d57b0b3ef  815296e0446ff6c405ef64708  
---  -  
465050 ~ 9% -71.2% 134141 ~16%  TOTAL cpuidle.C3-SNB.time
 10109 ~33% -63.0%   3743 ~25%  TOTAL 
sched_debug.cfs_rq[20]:/.min_vruntime
  7163 ~31% -63.2%   2638 ~22%  TOTAL 
sched_debug.cfs_rq[20]:/.MIN_vruntime
  7166 ~31% -63.1%   2641 ~22%  TOTAL 
sched_debug.cfs_rq[20]:/.max_vruntime
  1722 ~10% -34.7%   1124 ~27%  TOTAL 
sched_debug.cfs_rq[13]:/.MIN_vruntime
  1725 ~10% -34.6%   1127 ~27%  TOTAL 
sched_debug.cfs_rq[13]:/.max_vruntime
  7774 ~18% +47.0%  11430 ~22%  TOTAL 
sched_debug.cfs_rq[9]:/.runnable_load_avg
  8117 ~18% +47.2%  11946 ~20%  TOTAL sched_debug.cfs_rq[9]:/.load
  8106 ~18% +47.4%  11946 ~20%  TOTAL sched_debug.cpu#9.load
  7787 ~18% +47.1%  11457 ~22%  TOTAL sched_debug.cpu#9.cpu_load
  7319 ~23% +42.4%  10420 ~21%  TOTAL sched_debug.cpu#30.cpu_load
  7287 ~23% +42.8%  10404 ~21%  TOTAL 
sched_debug.cfs_rq[30]:/.runnable_load_avg
  7757 ~19% +58.1%  12268 ~31%  TOTAL 
sched_debug.cfs_rq[26]:/.tg_load_contrib
  7821 ~21% +52.2%  11904 ~24%  TOTAL sched_debug.cpu#11.cpu_load
  7956 ~18% +49.0%  11856 ~24%  TOTAL 
sched_debug.cfs_rq[11]:/.runnable_load_avg
  1722 ~16% -42.6%989 ~24%  TOTAL 
sched_debug.cfs_rq[6]:/.MIN_vruntime
  1726 ~16% -42.5%991 ~24%  TOTAL 
sched_debug.cfs_rq[6]:/.max_vruntime
  8357 ~15% +44.4%  12068 ~19%  TOTAL 
sched_debug.cfs_rq[9]:/.tg_load_contrib
  8513 ~15% +48.6%  12648 ~22%  TOTAL 
sched_debug.cfs_rq[11]:/.tg_load_contrib
  2050 ~19% -34.7%   1339 ~24%  TOTAL 
sched_debug.cfs_rq[6]:/.min_vruntime
  7278 ~16% +46.6%  10667 ~21%  TOTAL sched_debug.cpu#25.cpu_load
 7 ~20% +48.6% 11 ~19%  TOTAL sched_debug.cpu#9.nr_running
 7 ~20% +48.6% 11 ~19%  TOTAL 
sched_debug.cfs_rq[9]:/.nr_running
  7285 ~16% +46.0%  10639 ~21%  TOTAL 
sched_debug.cfs_rq[25]:/.runnable_load_avg
  8495 ~18% +35.5%  11513 ~19%  TOTAL sched_debug.cpu#14.load
  8489 ~18% +35.6%  11513 ~19%  TOTAL sched_debug.cfs_rq[14]:/.load
  7985 ~24% +37.9%  11015 ~19%  TOTAL sched_debug.cpu#12.cpu_load
  7983 ~25% +38.3%  11043 ~20%  TOTAL 
sched_debug.cfs_rq[12]:/.runnable_load_avg
  7123 ~15% +52.4%  10853 ~22%  TOTAL sched_debug.cfs_rq[24]:/.load
  1671 ~10% -36.6%   1059 ~24%  TOTAL 
sched_debug.cfs_rq[7]:/.MIN_vruntime
  7128 ~15% +52.2%  10853 ~22%  TOTAL sched_debug.cpu#24.load
  1674 ~10% -36.6%   1062 ~24%  TOTAL 
sched_debug.cfs_rq[7]:/.max_vruntime
  7997 ~13% +48.2%  11852 ~20%  TOTAL 
sched_debug.cfs_rq[8]:/.tg_load_contrib
  2039 ~15% -31.0%   1408 ~19%  TOTAL 
sched_debug.cfs_rq[7]:/.min_vruntime
  8556 ~22% +38.2%  11821 ~18%  TOTAL 
sched_debug.cfs_rq[12]:/.tg_load_contrib
   952 ~12% +59.6%   1520 ~ 6%  TOTAL cpuidle.C1E-SNB.usage
  7553 ~14% +49.0%  11253 ~21%  TOTAL 
sched_debug.cfs_rq[24]:/.tg_load_contrib
  2013 ~11% -27.5%   1459 ~17%  TOTAL 
sched_debug.cfs_rq[13]:/.min_vruntime
   431 ~21% +68.8%727 ~26%  TOTAL 
sched_debug.cfs_rq[6]:/.blocked_load_avg
  8512 ~10% +31.5%  11197 ~14%  TOTAL 
sched_debug.cfs_rq[16]:/.tg_load_contrib
  9269 ~18% +21.2%  11234 ~12%  TOTAL 
sched_debug.cfs_rq[6]:/.tg_load_contrib
  7816 ~ 9% +29.7%  10139 ~15%  TOTAL sched_debug.cpu#22.cpu_load
  8023 ~ 5% +38.9%  11146 ~12%  TOTAL 
sched_debug.cfs_rq[7]:/.runnable_load_avg
  8054 ~ 6% +38.5%  11156 ~11%  TOTAL sched_debug.cpu#7.cpu_load
  2255 ~35% -44.4%   1253 ~28%  TOTAL 
sched_debug.cfs_rq[3]:/.MIN_vruntime
  3.46 ~ 9% -24.4%   2.61 ~ 9%  TOTAL sched_debug.cfs_rq[6]:/.spread
  2258 ~34% -44.4%   1256 ~28%  TOTAL 
sched_debug.cfs_rq[3]:/.max_vruntime
  7752 ~ 9% +30.2%  10091 ~15%  TOTAL 
sched_debug.cfs_rq[22]:/.runnable_load_avg
  8579 ~ 6% +37.4%  11791 ~11%  TOTAL 
sched_debug.cfs_rq[7]:/.tg_load_contrib
  9337 ~18% +17.7%  10992 ~13%  TOTAL sched_debug.cpu#6.load
  9337 ~18% +17.7%  10992 ~13%  TOTAL sched_debug.cfs_rq[6]:/.load
  8499 ~ 6% +37.1%  11654 ~10%  TOTAL sched_debug.cpu#7.load
  8499 ~ 6% +37.1%  11654 ~10%  TOTAL sched_debug.cfs_rq[7]:/.load
 7 ~ 5% +38.5% 10 ~10%  TOTAL sched_debug.cpu#7.nr_running
 7 ~ 5% +38.5% 10 ~10%  TOTAL 
sched_debug.cfs_rq[7]:/.nr_running
45 ~23% -38.4% 28 ~33%  

Re: [PATCH v3 03/11] perf: provide a common perf_event_nop_0() for use with .event_idx

[Cody P Schafer]

On 03/03/2014 09:19 PM, Michael Ellerman wrote:

On Thu, 2014-27-02 at 21:04:56 UTC, Cody P Schafer wrote:

Rather an having every pmu that needs a function that just returns 0 for
.event_idx define their own copy, reuse the one in kernel/events/core.c.

Rename from perf_swevent_event_idx() because we're no longer using it
for just software events. Naming is based on the perf_pmu_nop_*()
functions.


You could just use perf_pmu_nop_int() directly.


No, .event_idx needs something that takes a (struct perf_event *), 
perf_pmu_nop_int() takes a (struct pmu *).


--
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: build failure after merge of the omap_dss2 tree

[Tomi Valkeinen]

On 04/03/14 05:35, Stephen Rothwell wrote:
> Hi Tomi,
> 
> After merging the omap_dss2 tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from drivers/staging/xgifb/XGIfb.h:3:0,
>  from drivers/staging/xgifb/vb_init.c:4:
> drivers/staging/xgifb/vgatypes.h:5:38: fatal error: 
> ../../video/sis/vgatypes.h: No such file or directory
>  #include "../../video/sis/vgatypes.h"
>   ^
> In file included from drivers/staging/xgifb/XGIfb.h:3:0,
>  from drivers/staging/xgifb/vb_setmode.c:2:
> drivers/staging/xgifb/vgatypes.h:5:38: fatal error: 
> ../../video/sis/vgatypes.h: No such file or directory
>  #include "../../video/sis/vgatypes.h"
>   ^
> In file included from drivers/staging/xgifb/vb_util.c:1:0:
> drivers/staging/xgifb/vgatypes.h:5:38: fatal error: 
> ../../video/sis/vgatypes.h: No such file or directory
>  #include "../../video/sis/vgatypes.h"
>   ^
> In file included from drivers/staging/xgifb/XGIfb.h:3:0,
>  from drivers/staging/xgifb/XGI_main.h:4,
>  from drivers/staging/xgifb/XGI_main_26.c:16:
> drivers/staging/xgifb/vgatypes.h:5:38: fatal error: 
> ../../video/sis/vgatypes.h: No such file or directory
>  #include "../../video/sis/vgatypes.h"
>   ^
> 
> Caused by commit 08667731d1d4 ("video: move fbdev to
> drivers/video/fbdev").
> 
> I have applied this merge fix patch (you should add it to your tree):

Thanks. I forgot we may have fbdev drivers in staging... This is now
fixed in my for-next branch (along with a couple of others, found by the
kbuild bot).

 Tomi




signature.asc
Description: OpenPGP digital signature

[PATCHv7 4/4] power_supply: bq24261 charger driver

[Jenny TC]

This patch introduces BQ24261 charger driver. The driver makes use of power
supply charging driver to setup charging. So the driver does hardware
abstraction and handles h/w specific corner cases. The charging logic resides
with power supply charging driver

Signed-off-by: Jenny TC 
---
 drivers/power/Kconfig |   10 +
 drivers/power/Makefile|1 +
 drivers/power/bq24261-charger.c   | 1350 +
 include/linux/power/bq24261-charger.h |   25 +
 4 files changed, 1386 insertions(+)
 create mode 100644 drivers/power/bq24261-charger.c
 create mode 100644 include/linux/power/bq24261-charger.h

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 913ec36..a1c2780 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -409,6 +409,16 @@ config BATTERY_GOLDFISH
  Say Y to enable support for the battery and AC power in the
  Goldfish emulator.
 
+config CHARGER_BQ24261
+   tristate "BQ24261 charger driver"
+   select POWER_SUPPLY_CHARGER
+   depends on I2C
+   help
+ Say Y to include support for BQ24261 Charger driver. This driver
+ makes use of power supply charging driver. So the driver gives
+ the charger hardware abstraction only. Charging logic is abstracted
+ in the power supply charging driver.
+
 source "drivers/power/reset/Kconfig"
 
 endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 77535fd..9dde895 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -59,4 +59,5 @@ obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o
 obj-$(CONFIG_POWER_AVS)+= avs/
 obj-$(CONFIG_CHARGER_SMB347)   += smb347-charger.o
 obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
+obj-$(CONFIG_CHARGER_BQ24261)  += bq24261-charger.o
 obj-$(CONFIG_POWER_RESET)  += reset/
diff --git a/drivers/power/bq24261-charger.c b/drivers/power/bq24261-charger.c
new file mode 100644
index 000..187c1fe
--- /dev/null
+++ b/drivers/power/bq24261-charger.c
@@ -0,0 +1,1350 @@
+/*
+ * bq24261-charger.c - BQ24261 Charger I2C client driver
+ *
+ * Copyright (C) 2011 Intel Corporation
+ *
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ *
+ * ~~
+ * Author: Jenny TC 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define DEV_NAME "bq24261_charger"
+#define MODEL_NAME_SIZE 8
+
+#define EXCEPTION_MONITOR_DELAY (60 * HZ)
+#define WDT_RESET_DELAY (15 * HZ)
+
+/* BQ24261 registers */
+#define BQ24261_STAT_CTRL0_ADDR0x00
+#define BQ24261_CTRL_ADDR  0x01
+#define BQ24261_BATT_VOL_CTRL_ADDR 0x02
+#define BQ24261_VENDOR_REV_ADDR0x03
+#define BQ24261_TERM_FCC_ADDR  0x04
+#define BQ24261_VINDPM_STAT_ADDR   0x05
+#define BQ24261_ST_NTC_MON_ADDR0x06
+
+#define BQ24261_RESET_MASK (0x01 << 7)
+#define BQ24261_RESET_ENABLE   (0x01 << 7)
+
+#define BQ24261_FAULT_MASK 0x07
+#define BQ24261_STAT_MASK  (0x03 << 4)
+#define BQ24261_BOOST_MASK (0x01 << 6)
+#define BQ24261_TMR_RST_MASK   (0x01 << 7)
+#define BQ24261_TMR_RST(0x01 << 7)
+
+#define BQ24261_ENABLE_BOOST   (0x01 << 6)
+
+#define BQ24261_VOVP   0x01
+#define BQ24261_LOW_SUPPLY 0x02
+#define BQ24261_THERMAL_SHUTDOWN   0x03
+#define BQ24261_BATT_TEMP_FAULT0x04
+#define BQ24261_TIMER_FAULT0x05
+#define BQ24261_BATT_OVP   0x06
+#define BQ24261_NO_BATTERY 0x07
+#define BQ24261_STAT_READY 0x00
+
+#define BQ24261_STAT_CHRG_PRGRSS   (0x01 << 4)
+#define BQ24261_STAT_CHRG_DONE (0x02 << 4)
+#define BQ24261_STAT_FAULT (0x03 << 4)
+
+#define BQ24261_CE_MASK(0x01 << 1)
+#define BQ24261_CE_DISABLE (0x01 << 1)
+
+#define BQ24261_HZ_MASK(0x01)
+#define BQ24261_HZ_ENABLE  (0x01)
+
+#define BQ24261_ICHRG_MASK (0x1F << 3)
+#define BQ24261_MIN_CC 500 /* 500mA */
+#define BQ24261_MAX_CC 3000 /* 3A */
+
+#define BQ24261_ITERM_MASK (0x03)
+#define BQ24261_MIN_ITERM 50 /* 50 mA */
+#define BQ24261_MAX_ITERM 300 /* 

[PATCHv7 3/4] power_supply: Introduce PSE compliant algorithm

[Jenny TC]

As per Product Safety Engineering (PSE) specification for battery charging, the
battery characteristics and thereby the charging rates can vary on different
temperature zones. This patch introduces a PSE compliant charging algorithm with
maintenance charging support. The algorithm can be selected by the power supply
charging driver based on the type of the battery charging profile.

Signed-off-by: Jenny TC 
---
 drivers/power/Kconfig  |   13 ++
 drivers/power/Makefile |1 +
 drivers/power/charging_algo_pse.c  |  204 
 include/linux/power/power_supply_charger.h |   63 +
 4 files changed, 281 insertions(+)
 create mode 100644 drivers/power/charging_algo_pse.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index f679f82..913ec36 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -22,6 +22,19 @@ config POWER_SUPPLY_CHARGER
  drivers to keep the charging logic outside and the charger driver
  just need to abstract the charger hardware.
 
+config POWER_SUPPLY_CHARGING_ALGO_PSE
+   bool "PSE compliant charging algorithm"
+   help
+ Say Y here to select Product Safety Engineering (PSE) compliant
+ charging algorithm. As per PSE standard the battery characteristics
+ and thereby the charging rates can vary on different temperature
+ zones. This config will enable PSE compliant charging algorithm with
+ maintenance charging support. At runtime the algorithm will be
+ selected by the psy charger driver based on the type of the battery
+ charging profile.
+
+   depends on POWER_SUPPLY_CHARGER
+
 config PDA_POWER
tristate "Generic PDA/phone power driver"
depends on !S390
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 405f0f4..77535fd 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_POWER_SUPPLY)  += power_supply.o
 obj-$(CONFIG_GENERIC_ADC_BATTERY)  += generic-adc-battery.o
 
 obj-$(CONFIG_POWER_SUPPLY_CHARGER) += power_supply_charger.o
+obj-$(CONFIG_POWER_SUPPLY_CHARGING_ALGO_PSE) += charging_algo_pse.o
 obj-$(CONFIG_PDA_POWER)+= pda_power.o
 obj-$(CONFIG_APM_POWER)+= apm_power.o
 obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
diff --git a/drivers/power/charging_algo_pse.c 
b/drivers/power/charging_algo_pse.c
new file mode 100644
index 000..ac95885
--- /dev/null
+++ b/drivers/power/charging_algo_pse.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2012 Intel Corporation
+ *
+ * ~~
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ *
+ * ~~
+ * Author: Jenny TC 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "power_supply.h"
+#include "power_supply_charger.h"
+
+/* 98% of CV is considered as voltage to detect Full */
+#define FULL_CV_MIN 98
+
+/*
+ * Offset to exit from maintenance charging. In maintenance charging
+ * if the volatge is less than the (maintenance_lower_threshold -
+ * MAINT_EXIT_OFFSET) then system can switch to normal charging
+ */
+
+#define MAINT_EXIT_OFFSET 50  /* mV */
+
+static int get_tempzone(struct psy_pse_chrg_prof *pse_mod_bprof,
+   int temp)
+{
+   int i = 0;
+   int temp_range_cnt = min_t(u16, pse_mod_bprof->temp_mon_ranges,
+   BATT_TEMP_NR_RNG);
+
+   if ((temp < pse_mod_bprof->temp_low_lim) ||
+   (temp > pse_mod_bprof->temp_mon_range[0].temp_up_lim))
+   return -EINVAL;
+
+   for (i = 0; i < temp_range_cnt; ++i)
+   if (temp > pse_mod_bprof->temp_mon_range[i].temp_up_lim)
+   break;
+   return i-1;
+}
+
+static inline bool is_charge_terminated(long volt, long cur,
+   long iterm, unsigned long cv)
+{
+   pr_devel("%s:current=%ld pse_mod_bprof->chrg_term_mA =%ld 
voltage_now=%ld full_cond=%ld",
+   __func__, cur, iterm, volt * 100, (FULL_CV_MIN * cv));
+
+   return (cur > 0) && (cur <= iterm) &&
+   ((volt * 100)  >= (FULL_CV_MIN * cv));
+
+}
+
+static inline bool is_battery_full(struct psy_batt_props bat_prop,
+   struct psy_pse_chrg_prof *pse_mod_bprof, unsigned long cv)
+{
+
+   int i;
+
+   /*
+   * Software full detection. 

[PATCH v7 1/4] power_supply: Add inlmt,iterm, min/max temp props

[Jenny TC]

Add new power supply properties for input current, charge termination
current, min and max temperature

POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature
POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature

POWER_SUPPLY_PROP_INLMT - input current limit programmed by charger. Indicates
the input current for a charging source.

POWER_SUPPLY_PROP_CHARGE_TERM_CUR - Charge termination current used to detect
the end of charge condition

Signed-off-by: Jenny TC 
---
 Documentation/power/power_supply_class.txt |6 ++
 drivers/power/power_supply_sysfs.c |4 
 include/linux/power_supply.h   |4 
 3 files changed, 14 insertions(+)

diff --git a/Documentation/power/power_supply_class.txt 
b/Documentation/power/power_supply_class.txt
index 89a8816..48cff88 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -118,6 +118,10 @@ relative, time-based measurements.
 CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
 CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
 power supply object.
+INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates
+the current drawn from a charging source.
+CHARGE_TERM_CURRENT - Charge termination current used to detect the end of 
charge
+condition.
 
 CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
 CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
@@ -140,6 +144,8 @@ TEMP_ALERT_MAX - maximum battery temperature alert.
 TEMP_AMBIENT - ambient temperature.
 TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert.
 TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert.
+TEMP_MIN - minimum operatable temperature
+TEMP_MAX - maximum operatable temperature
 
 TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
 while battery powers a load)
diff --git a/drivers/power/power_supply_sysfs.c 
b/drivers/power/power_supply_sysfs.c
index 44420d1..750a202 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -167,6 +167,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(constant_charge_voltage_max),
POWER_SUPPLY_ATTR(charge_control_limit),
POWER_SUPPLY_ATTR(charge_control_limit_max),
+   POWER_SUPPLY_ATTR(input_current_limit),
POWER_SUPPLY_ATTR(energy_full_design),
POWER_SUPPLY_ATTR(energy_empty_design),
POWER_SUPPLY_ATTR(energy_full),
@@ -178,6 +179,8 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(capacity_alert_max),
POWER_SUPPLY_ATTR(capacity_level),
POWER_SUPPLY_ATTR(temp),
+   POWER_SUPPLY_ATTR(temp_max),
+   POWER_SUPPLY_ATTR(temp_min),
POWER_SUPPLY_ATTR(temp_alert_min),
POWER_SUPPLY_ATTR(temp_alert_max),
POWER_SUPPLY_ATTR(temp_ambient),
@@ -189,6 +192,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(time_to_full_avg),
POWER_SUPPLY_ATTR(type),
POWER_SUPPLY_ATTR(scope),
+   POWER_SUPPLY_ATTR(charge_term_current),
/* Properties of type `const char *' */
POWER_SUPPLY_ATTR(model_name),
POWER_SUPPLY_ATTR(manufacturer),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index c9dc4e0..0278600 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -120,6 +120,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
+   POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
POWER_SUPPLY_PROP_ENERGY_FULL,
@@ -131,6 +132,8 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CAPACITY_ALERT_MAX, /* in percents! */
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
POWER_SUPPLY_PROP_TEMP,
+   POWER_SUPPLY_PROP_TEMP_MAX,
+   POWER_SUPPLY_PROP_TEMP_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MAX,
POWER_SUPPLY_PROP_TEMP_AMBIENT,
@@ -142,6 +145,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_TIME_TO_FULL_AVG,
POWER_SUPPLY_PROP_TYPE, /* use power_supply.type instead */
POWER_SUPPLY_PROP_SCOPE,
+   POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
/* Properties of type `const char *' */
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
-- 
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/

[PATCHv7 0/4] power_supply: Introduce power supply charging driver

[Jenny TC]

v1: introduced feature as a framework within power supply class driver with
separate files for battid framework and charging framework
v2: fixed review comments, moved macros and inline functions to power_supply.h
v3: moved the feature as a separate driver, combined battid framework and
charging framework inside the power supply charging driver. Moved
charger specific properties to power_supply_charger.h and plugged the
driver with power supply subsystem using power_supply_notifier
introduced in my previous patch. Also a sample charger chip driver
(bq24261) patch added to give more idea on the psy charging driver
usage
v4: Fixed review comments, no major design changes.
v5: Fixed makefile inconsistencies, removed unused pdata callbacks
v6: Fixed nested loops, commenting style
v7: added kerneldocs for structs and minor fixes

The Power Supply charging driver connects multiple subsystems
to do charging in a generic way. The subsystems involves power_supply,
thermal and battery communication subsystems (1wire).With this the charging is
handled in a generic way.

The driver makes use of different new features - Battery Identification
interfaces, pluggable charging algorithms, charger cable arbitrations etc.
The patch also introduces generic interface for charger cable notifications.
Charger cable events and capabilities can be notified using the generic
power_supply_notifier chain.

Overall this driver removes the charging logic out of the charger chip driver
and the charger chip driver can just listen to the request from the power
supply charging driver to set the charger properties. This can be implemented
by exposing get_property and set property callbacks.

Jenny TC (4):
  power_supply: Add inlmt,iterm, min/max temp props
  power_supply: Introduce generic psy charging driver
  power_supply: Introduce PSE compliant algorithm
  power_supply: bq24261 charger driver

 Documentation/power/power_supply_charger.txt |  353 +++
 Documentation/power/power_supply_class.txt   |6 +
 drivers/power/Kconfig|   31 +
 drivers/power/Makefile   |3 +
 drivers/power/bq24261-charger.c  | 1350 ++
 drivers/power/charging_algo_pse.c|  204 
 drivers/power/power_supply_charger.c | 1186 ++
 drivers/power/power_supply_charger.h |  218 +
 drivers/power/power_supply_core.c|3 +
 drivers/power/power_supply_sysfs.c   |4 +
 include/linux/power/bq24261-charger.h|   25 +
 include/linux/power/power_supply_charger.h   |  341 +++
 include/linux/power_supply.h |  164 
 13 files changed, 3888 insertions(+)
 create mode 100644 Documentation/power/power_supply_charger.txt
 create mode 100644 drivers/power/bq24261-charger.c
 create mode 100644 drivers/power/charging_algo_pse.c
 create mode 100644 drivers/power/power_supply_charger.c
 create mode 100644 drivers/power/power_supply_charger.h
 create mode 100644 include/linux/power/bq24261-charger.h
 create mode 100644 include/linux/power/power_supply_charger.h

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

Re: [PATCH v2] regulator: pfuze100: add pfuze200 support

[Mark Brown]

On Tue, Mar 04, 2014 at 01:45:33PM +0800, Robin Gong wrote:
> support pfuze200 chip which remove SW1C and SW4 based on pfuze100.

Applied, thanks - however I just noticed that you forgot to add the
compatible string for the new part to the DT binding, please send a
followup doing that.


signature.asc
Description: Digital signature

Re: [PATCH] CNS3xxx: Fix PCIe early iotable_init().

[Krzysztof Hałasa]

Arnd Bergmann  writes:

> Patch looks good, but please add the changeset description from
> your first patch.

I wonder if another approach would be better. I don't like the .pfn
messing and the bugs that function introduces.
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
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/5 v2] Staging: cxt1e1: Fix line length over 80 characters in hwprobe.c

[Krzysztof Hałasa]

DaeSeok Youn  writes:

>>> -  * match with board's first found interface, otherwise this 
>>> is first
>>> -  * found
>>> +  * match with board's first found interface, otherwise this is
>>> +  * fisrt found
>>^
>> I wonder what's your exact procedure for doing such changes :-)
> "first" word is over 80 line character after applying my previous patch(2/5)
> (previous patch is already merged to staging-next tree :-))

Sure, I meant I'd just break the line without re-typing the first/fisrt
word manually... Never mind.

Anyway, I'd rather aim for improving overall code quality, not just
silence 80-char warning. I'm not a big fan of this warning.
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

[John Stultz]

On Tue, Mar 4, 2014 at 1:38 PM, Mike Galbraith  wrote:
> (crap crap crap... M.A.I.N.T.A.I.N.E.R.S _dummy_)
>
> clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()
>
> As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock",
> cycles * mult >> shift is overflow prone. so give it the same treatment.
>
> Cc: Salman Qazi 
> Cc: John Stultz ,
> Signed-off-by: Mike Galbraith 

Thanks for sending this in!  Curious exactly how the issue was being
triggered?  To some extent the cyclecounter/timecounter code never got
the adoption I expected, so I've sort of had it on my list to see
about killing that code off and merging its users w/ clocksources
(since the clocksource has been simplified since cyclecounters
landed). So curious to see what its actually being used for..
particularly since the timecounter code does have accumulation logic
which should avoid overflows (and deal with hardware counters that
wrap).

I'll put this in my 3.15 queue.

thanks
-john
--
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: [Update PATCH 2/2] aio, mem-hotplug: Add memory barrier to aio ring page migration.

[Miao Xie]

On  thu, 27 Feb 2014 21:44:23 +0900, Yasuaki Ishimatsu wrote:
> When doing aio ring page migration, we migrated the page, and update
> ctx->ring_pages[]. Like the following:
> 
> aio_migratepage()
>  |-> migrate_page_copy(new, old)
>  |   ..   /* Need barrier here */
>  |-> ctx->ring_pages[idx] = new
> 
> Actually, we need a memory barrier between these two operations.
> Otherwise, if ctx->ring_pages[] is updated before memory copy due to
> the compiler optimization, other processes may have an opportunity
> to access to the not fully initialized new ring page.
> 
> So add a wmb and rmb to synchronize them.
> 
> Signed-off-by: Tang Chen 
> Signed-off-by: Yasuaki Ishimatsu 
> 
> ---
>  fs/aio.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/fs/aio.c b/fs/aio.c
> index 50c089c..8d9b82b 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -327,6 +327,14 @@ static int aio_migratepage(struct address_space 
> *mapping, struct page *new,
>   pgoff_t idx;
>   spin_lock_irqsave(>completion_lock, flags);
>   migrate_page_copy(new, old);
> +
> + /*
> +  * Ensure memory copy is finished before updating
> +  * ctx->ring_pages[]. Otherwise other processes may access to
> +  * new ring pages which are not fully initialized.
> +  */
> + smp_wmb();
> +
>   idx = old->index;
>   if (idx < (pgoff_t)ctx->nr_pages) {
>   /* And only do the move if things haven't changed */
> @@ -1074,6 +1082,12 @@ static long aio_read_events_ring(struct kioctx *ctx,
>   page = ctx->ring_pages[pos / AIO_EVENTS_PER_PAGE];
>   pos %= AIO_EVENTS_PER_PAGE;
> 
> + /*
> +  * Ensure that the page's data was copied from old one by
> +  * aio_migratepage().
> +  */
> + smp_rmb();
> +

smp_read_barrier_depends() is better.

"One could place an A smp_rmb() primitive between the pointer fetch and
 dereference. However, this imposes unneeded overhead on systems (such as
 i386, IA64, PPC, and SPARC) that respect data dependencies on the read side.
 A smp_read_barrier_depends() primitive has been added to the Linux 2.6 kernel
 to eliminate overhead on these systems."
-- From Chapter 7.1 of 
   Written by Paul E. McKenney

Thanks
Miao

>   ev = kmap(page);
>   copy_ret = copy_to_user(event + ret, ev + pos,
>   sizeof(*ev) * avail);
> 
> --
> 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/
> 

--
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: Re: [PATCH] x86: set Pentium M as PAE capable

[Chris Bainbridge]

On Mon, Mar 03, 2014 at 09:04:19PM -0800, H. Peter Anvin wrote:
> forcepae is descriptive.

Back to forcepae.

Signed-off-by: Chris Bainbridge 
---
diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 580a60c..67755ea 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1011,6 +1011,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
parameter will force ia64_sal_cache_flush to call
ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
 
+   forcepae [X86-32]
+   Forcefully enable Physical Address Extension (PAE).
+   Many Pentium M systems disable PAE but may have a
+   functionally usable PAE implementation.
+   Warning: use of this parameter will taint the kernel
+   and may cause unknown problems.
+
ftrace=[tracer]
[FTRACE] will set and start the specified tracer
as early as possible in order to facilitate early
diff --git a/arch/x86/boot/cpucheck.c b/arch/x86/boot/cpucheck.c
index 100a9a1..f0d0b20 100644
--- a/arch/x86/boot/cpucheck.c
+++ b/arch/x86/boot/cpucheck.c
@@ -67,6 +67,13 @@ static int is_transmeta(void)
   cpu_vendor[2] == A32('M', 'x', '8', '6');
 }
 
+static int is_intel(void)
+{
+   return cpu_vendor[0] == A32('G', 'e', 'n', 'u') &&
+  cpu_vendor[1] == A32('i', 'n', 'e', 'I') &&
+  cpu_vendor[2] == A32('n', 't', 'e', 'l');
+}
+
 /* Returns a bitmask of which words we have error bits in */
 static int check_cpuflags(void)
 {
@@ -153,6 +160,19 @@ int check_cpu(int *cpu_level_ptr, int *req_level_ptr, u32 
**err_flags_ptr)
asm("wrmsr" : : "a" (eax), "d" (edx), "c" (ecx));
 
err = check_cpuflags();
+   } else if (err == 0x01 &&
+  !(err_flags[0] & ~(1 << X86_FEATURE_PAE)) &&
+  is_intel() && cpu.level == 6 &&
+  (cpu.model == 9 || cpu.model == 13)) {
+   /* PAE is disabled on this Pentium M but can be forced */
+   if (cmdline_find_option_bool("forcepae")) {
+   puts("WARNING: Forcing PAE in CPU flags\n");
+   set_bit(X86_FEATURE_PAE, cpu.flags);
+   err = check_cpuflags();
+   }
+   else {
+   puts("WARNING: PAE disabled. Use parameter 'forcepae' 
to enable at your own risk!\n");
+   }
}
 
if (err_flags_ptr)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index c67ffa6..7ec4119 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -218,7 +218,7 @@ static void amd_k7_smp_check(struct cpuinfo_x86 *c)
 */
WARN_ONCE(1, "WARNING: This combination of AMD"
" processors is not suitable for SMP.\n");
-   add_taint(TAINT_UNSAFE_SMP, LOCKDEP_NOW_UNRELIABLE);
+   add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_NOW_UNRELIABLE);
 }
 
 static void init_amd_k7(struct cpuinfo_x86 *c)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index ea56e7c..053cb59 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -195,6 +195,14 @@ static void intel_smp_check(struct cpuinfo_x86 *c)
}
 }
 
+static int forcepae;
+static int __init forcepae_setup(char *__unused)
+{
+   forcepae = 1;
+   return 1;
+}
+__setup("forcepae", forcepae_setup);
+
 static void intel_workarounds(struct cpuinfo_x86 *c)
 {
unsigned long lo, hi;
@@ -225,6 +233,17 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
clear_cpu_cap(c, X86_FEATURE_SEP);
 
/*
+* PAE CPUID issue: many Pentium M report no PAE but may have a
+* functionally usable PAE implementation.
+* Forcefully enable PAE if kernel parameter "forcepae" is present.
+*/
+   if (forcepae) {
+   printk(KERN_WARNING "PAE forced!\n");
+   set_cpu_cap(c, X86_FEATURE_PAE);
+   add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_NOW_UNRELIABLE);
+   }
+
+   /*
 * P4 Xeon errata 037 workaround.
 * Hardware prefetcher may cause stale data to be loaded into the cache.
 */
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 196d1ea..08fb024 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -458,7 +458,7 @@ extern enum system_states {
 
 #define TAINT_PROPRIETARY_MODULE   0
 #define TAINT_FORCED_MODULE1
-#define TAINT_UNSAFE_SMP   2
+#define TAINT_CPU_OUT_OF_SPEC  2
 #define TAINT_FORCED_RMMOD 3
 #define TAINT_MACHINE_CHECK4
 #define TAINT_BAD_PAGE 5
diff --git a/kernel/module.c b/kernel/module.c
index b99e801..8dc7f5e 100644
--- a/kernel/module.c
+++ 

[PATCH 2/2] regulator: s2mps11: Add missing of_node_put

[Sachin Kamat]

Add of_node_put to decrement the ref count.

Signed-off-by: Sachin Kamat 
---
 drivers/regulator/s2mps11.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 0f6177b..6eaf69b 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -446,6 +446,7 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
}
 
of_regulator_match(>dev, reg_np, rdata, s2mps11->rdev_num);
+   of_node_put(reg_np);
 
 common_reg:
platform_set_drvdata(pdev, s2mps11);
-- 
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 1/2] regulator: s2mps11: Use of_get_child_by_name

[Sachin Kamat]

of_find_node_by_name walks the allnodes list, and can thus walk
outside of the parent node. Use of_get_child_by_name instead.

Signed-off-by: Sachin Kamat 
---
 drivers/regulator/s2mps11.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index b51ccf5..0f6177b 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -438,7 +438,7 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
for (i = 0; i < s2mps11->rdev_num; i++)
rdata[i].name = regulators[i].name;
 
-   reg_np = of_find_node_by_name(iodev->dev->of_node, "regulators");
+   reg_np = of_get_child_by_name(iodev->dev->of_node, "regulators");
if (!reg_np) {
dev_err(>dev, "could not find regulators sub-node\n");
ret = -EINVAL;
-- 
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/

RE: [PATCH] mm, oom: normalize the adj to ensure oom_badness return a positive number

[He, Bo]

Sorry, the title is confusing. Change it to: mm, oom: normalize the adj to 
ensure oom_badness returns a positive number
We are enabling android mobiles. When running stress memory test, there is a 
bad issue. Some critical processes such as Healthd and watchdogd are killed, 
while some other processes are still alive.
OOM should kill the tasks whose oom_score are biggest. Many processes use a 
minus oom_score_adj. oom_badness returns 1 for all of them and their oom_score 
are all 0.

The patch tries to convert the minus oom_score_adj to a positive number when 
calculating oom_score. oom_score can keep right process priority sequence.

Without the patch, almost all the processes' oom_score are equal to 0. (cat 
/proc/XXX/oom_*)
Healthd-15 0 -941
Servicemanager -15 0 -941
Vold   -15 0 -941
ia_watchdogd  -15 0 -941
surfaceflinger   -15 0 -941
zygote-15 0 -941
system_server -15 0 -941
ndroid.systemui-11 0 -705

With the patch, we can get different oom_score:
Healthd-15 59 -941
Servicemanager -15 89 -941
Vold   -15 60 -941
ia_watchdogd  -15 89 -941
surfaceflinger   -15 145 -941
zygote-15 122 -941
system_server -15 166 -941
ndroid.systemui-11 419 -705


-Original Message-
From: David Rientjes [mailto:rient...@google.com] 
Sent: Tuesday, March 04, 2014 1:05 PM
To: He, Bo
Cc: linux-kernel@vger.kernel.org; Ingo Molnar; han...@cmpxchg.org; 
o...@redhat.com; kirill.shute...@linux.intel.com; Zhang, Yanmin; 
yanmin_zh...@intel.linux.com; Wang, Biao
Subject: Re: [PATCH] mm, oom: normalize the adj to ensure oom_badness return one

On Mon, 3 Mar 2014, He, Bo wrote:

> if oom_score_adj is a big negative number, such as -941, adj *= 
> totalpages / 1000 will be a big negative number, finally the 
> oom_badness will get 0 points, here normalize the oom_score_adj to 
> ensure oom_badness return the positive number.
> 

Sorry, I have no clue what you're talking about or trying to fix.

A /proc/pid/oom_score_adj of -941 would mean discounting 94.1% of system 
memory from pid's resident memory usage for a system oom condition.  This 
is the effect of adj *= totalpages / 1000 and is working as intended per 
Documentation/filesystems/proc.txt.

oom_badness() will then return the smallest integer possible, 1 (not 0), 
that still allows the process to be killed, that's the effect of 
"return points > 0 ? points : 1".  It never returns 0 as you state, you're 
either not reading the code correctly or not working on any recent kernel.

> Change-Id: I1c56a948ce48b65a1bb63b56ffef07d5d76d7ec8
> Signed-off-by: he, bo 
> Signed-off-by: wang, biao 
> Reviewed-by: Yanmin Zhang 
> ---
>  mm/oom_kill.c |3 +++ 
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 3291e82..5a93986 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -181,6 +181,9 @@ unsigned long oom_badness(struct task_struct *p, struct 
> mem_cgroup *memcg,
> points -= (points * 3) / 100;
>  
> /* Normalize to oom_score_adj units */
> +   if(OOM_SCORE_ADJ_MIN < 0)
> +   adj -= OOM_SCORE_ADJ_MIN;
> +
> adj *= totalpages / 1000;
> points += adj;
>  
--
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] Revert "X86 platform: New BayTrail IOSF-SB MBI driver"

[David E. Box]

From: "David E. Box" 

This reverts commit 997ab407d2b4e7d7ce2788d2de68435eb94fcfec. This driver is
replaced by the more general SOC IOSF driver in commit 46184415368a.

Signed-off-by: David E. Box 
---
 drivers/platform/x86/Kconfig  |8 --
 drivers/platform/x86/Makefile |1 -
 drivers/platform/x86/intel_baytrail.c |  224 -
 drivers/platform/x86/intel_baytrail.h |   90 -
 4 files changed, 323 deletions(-)
 delete mode 100644 drivers/platform/x86/intel_baytrail.c
 delete mode 100644 drivers/platform/x86/intel_baytrail.h

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 5ae65c1..aee5f72 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -819,12 +819,4 @@ config PVPANIC
  a paravirtualized device provided by QEMU; it lets a virtual machine
  (guest) communicate panic events to the host.
 
-config INTEL_BAYTRAIL_MBI
-   tristate
-   depends on PCI
-   ---help---
- Needed on Baytrail platforms for access to the IOSF Sideband Mailbox
- Interface. This is a requirement for systems that need to configure
- the PUNIT for power management features such as RAPL.
-
 endif # X86_PLATFORM_DEVICES
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 9b87cfc..b8c36f7 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -55,4 +55,3 @@ obj-$(CONFIG_INTEL_RST)   += intel-rst.o
 obj-$(CONFIG_INTEL_SMARTCONNECT)   += intel-smartconnect.o
 
 obj-$(CONFIG_PVPANIC)   += pvpanic.o
-obj-$(CONFIG_INTEL_BAYTRAIL_MBI)   += intel_baytrail.o
diff --git a/drivers/platform/x86/intel_baytrail.c 
b/drivers/platform/x86/intel_baytrail.c
deleted file mode 100644
index f96626b..000
--- a/drivers/platform/x86/intel_baytrail.c
+++ /dev/null
@@ -1,224 +0,0 @@
-/*
- * Baytrail IOSF-SB MailBox Interface Driver
- * Copyright (c) 2013, Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- *
- * The IOSF-SB is a fabric bus available on Atom based SOC's that uses a
- * mailbox interface (MBI) to communicate with mutiple devices. This
- * driver implements BayTrail-specific access to this interface.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include "intel_baytrail.h"
-
-static DEFINE_SPINLOCK(iosf_mbi_lock);
-
-static inline u32 iosf_mbi_form_mcr(u8 op, u8 port, u8 offset)
-{
-   return (op << 24) | (port << 16) | (offset << 8) | BT_MBI_ENABLE;
-}
-
-static struct pci_dev *mbi_pdev;   /* one mbi device */
-
-/* Hold lock before calling */
-static int iosf_mbi_pci_read_mdr(u32 mcrx, u32 mcr, u32 *mdr)
-{
-   int result;
-
-   if (!mbi_pdev)
-   return -ENODEV;
-
-   if (mcrx) {
-   result = pci_write_config_dword(mbi_pdev,
-   BT_MBI_MCRX_OFFSET, mcrx);
-   if (result < 0)
-   goto iosf_mbi_read_err;
-   }
-
-   result = pci_write_config_dword(mbi_pdev,
-   BT_MBI_MCR_OFFSET, mcr);
-   if (result < 0)
-   goto iosf_mbi_read_err;
-
-   result = pci_read_config_dword(mbi_pdev,
-  BT_MBI_MDR_OFFSET, mdr);
-   if (result < 0)
-   goto iosf_mbi_read_err;
-
-   return 0;
-
-iosf_mbi_read_err:
-   dev_err(_pdev->dev, "error: PCI config operation returned %d\n",
-   result);
-   return result;
-}
-
-/* Hold lock before calling */
-static int iosf_mbi_pci_write_mdr(u32 mcrx, u32 mcr, u32 mdr)
-{
-   int result;
-
-   if (!mbi_pdev)
-   return -ENODEV;
-
-   result = pci_write_config_dword(mbi_pdev,
-   BT_MBI_MDR_OFFSET, mdr);
-   if (result < 0)
-   goto iosf_mbi_write_err;
-
-   if (mcrx) {
-   result = pci_write_config_dword(mbi_pdev,
-BT_MBI_MCRX_OFFSET, mcrx);
-   if (result < 0)
-   goto iosf_mbi_write_err;
-   }
-
-   result = pci_write_config_dword(mbi_pdev,
-   BT_MBI_MCR_OFFSET, mcr);
-   if (result < 0)
-   goto iosf_mbi_write_err;
-
-   return 0;
-
-iosf_mbi_write_err:
-   dev_err(_pdev->dev, "error: PCI config operation returned %d\n",
-   result);
-   return result;
-}
-
-int bt_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr)
-{
-   u32 mcr, mcrx;
-   

[PATCH v2] regulator: pfuze100: add pfuze200 support

[Robin Gong]

support pfuze200 chip which remove SW1C and SW4 based on pfuze100.

Signed-off-by: Robin Gong 
---
 drivers/regulator/pfuze100-regulator.c |  196 +++-
 include/linux/regulator/pfuze100.h |   14 +++
 2 files changed, 157 insertions(+), 53 deletions(-)

diff --git a/drivers/regulator/pfuze100-regulator.c 
b/drivers/regulator/pfuze100-regulator.c
index ab174f2..9bf0ee9 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -56,6 +56,8 @@
 #define PFUZE100_VGEN5VOL  0x70
 #define PFUZE100_VGEN6VOL  0x71
 
+enum chips {PFUZE100, PFUZE200, PFUZE_NUM};
+
 struct pfuze_regulator {
struct regulator_desc desc;
unsigned char stby_reg;
@@ -63,6 +65,7 @@ struct pfuze_regulator {
 };
 
 struct pfuze_chip {
+   int chip_id;
struct regmap *regmap;
struct device *dev;
struct pfuze_regulator regulator_descs[PFUZE100_MAX_REGULATOR];
@@ -77,15 +80,15 @@ static const int pfuze100_vsnvs[] = {
100, 110, 120, 130, 150, 180, 300,
 };
 
-static const struct i2c_device_id pfuze_device_id[] = {
-   {.name = "pfuze100"},
-   {},
+static const struct i2c_device_id pfuze_device_id[PFUZE_NUM] = {
+   {.name = "pfuze100", .driver_data = PFUZE100},
+   {.name = "pfuze200", .driver_data = PFUZE200},
 };
 MODULE_DEVICE_TABLE(i2c, pfuze_device_id);
 
-static const struct of_device_id pfuze_dt_ids[] = {
-   { .compatible = "fsl,pfuze100" },
-   {},
+static const struct of_device_id pfuze_dt_ids[PFUZE_NUM] = {
+   { .compatible = "fsl,pfuze100", .data = (void *)PFUZE100},
+   { .compatible = "fsl,pfuze200", .data = (void *)PFUZE200},
 };
 MODULE_DEVICE_TABLE(of, pfuze_dt_ids);
 
@@ -139,14 +142,14 @@ static struct regulator_ops pfuze100_swb_regulator_ops = {
 
 };
 
-#define PFUZE100_FIXED_REG(_name, base, voltage)   \
-   [PFUZE100_ ## _name] = {\
+#define PFUZE100_FIXED_REG(_chip, _name, base, voltage)\
+   [_chip ## _ ## _name] = {   \
.desc = {   \
.name = #_name, \
.n_voltages = 1,\
.ops = _fixed_regulator_ops,   \
.type = REGULATOR_VOLTAGE,  \
-   .id = PFUZE100_ ## _name,   \
+   .id = _chip ## _ ## _name,  \
.owner = THIS_MODULE,   \
.min_uV = (voltage),\
.enable_reg = (base),   \
@@ -154,14 +157,14 @@ static struct regulator_ops pfuze100_swb_regulator_ops = {
},  \
}
 
-#define PFUZE100_SW_REG(_name, base, min, max, step)   \
-   [PFUZE100_ ## _name] = {\
+#define PFUZE100_SW_REG(_chip, _name, base, min, max, step)\
+   [_chip ## _ ## _name] = {   \
.desc = {   \
.name = #_name,\
.n_voltages = ((max) - (min)) / (step) + 1, \
.ops = _sw_regulator_ops,  \
.type = REGULATOR_VOLTAGE,  \
-   .id = PFUZE100_ ## _name,   \
+   .id = _chip ## _ ## _name,  \
.owner = THIS_MODULE,   \
.min_uV = (min),\
.uV_step = (step),  \
@@ -172,14 +175,14 @@ static struct regulator_ops pfuze100_swb_regulator_ops = {
.stby_mask = 0x3f,  \
}
 
-#define PFUZE100_SWB_REG(_name, base, mask, voltages)  \
-   [PFUZE100_ ## _name] = {\
+#define PFUZE100_SWB_REG(_chip, _name, base, mask, voltages)   \
+   [_chip ## _ ##  _name] = {  \
.desc = {   \
.name = #_name, \
.n_voltages = ARRAY_SIZE(voltages), \
.ops = _swb_regulator_ops, \
.type = REGULATOR_VOLTAGE,  \
-   .id = PFUZE100_ ## _name,   \
+   .id = _chip ## _ ## _name,  \
.owner = THIS_MODULE,   \
.volt_table = voltages, \
.vsel_reg = (base), \
@@ -187,14 +190,14 @@ static struct regulator_ops pfuze100_swb_regulator_ops = {
},  \
}
 
-#define PFUZE100_VGEN_REG(_name, base, min, max, step) \
-   [PFUZE100_ ## _name] = {\
+#define PFUZE100_VGEN_REG(_chip, _name, base, min, max, step)  \
+   [_chip ## _ ## _name] = {   \
.desc = {   \
.name = #_name, \
.n_voltages = ((max) - (min)) / (step) + 1, \
.ops = _ldo_regulator_ops, \
.type = REGULATOR_VOLTAGE,  \
-   .id = PFUZE100_ ## _name,   \
+   .id = _chip ## _ ## _name,

[RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

[Mike Galbraith]

(crap crap crap... M.A.I.N.T.A.I.N.E.R.S _dummy_)

clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock",
cycles * mult >> shift is overflow prone. so give it the same treatment.

Cc: Salman Qazi 
Cc: John Stultz ,
Signed-off-by: Mike Galbraith 
---
 include/linux/clocksource.h |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -77,13 +77,18 @@ struct timecounter {
  *
  * XXX - This could use some mult_lxl_ll() asm optimization. Same code
  * as in cyc2ns, but with unsigned result.
+ *
+ * Because it is the same as x86 __cycles_2_ns, give it the same treatment as
+ * commit 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock"
+ * to avoid a potential cycles * mult overflow.
  */
 static inline u64 cyclecounter_cyc2ns(const struct cyclecounter *cc,
  cycle_t cycles)
 {
-   u64 ret = (u64)cycles;
-   ret = (ret * cc->mult) >> cc->shift;
-   return ret;
+   u64 quot = (u64)cycles >> cc->shift;
+   u64 rem = (u64)cycles & ((1ULL << cc->shift) - 1);
+
+   return  quot * cc->mult + ((rem * cc->mult) >> cc->shift);
 }
 
 /**




--
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] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Jason Cooper]

This reverts commit 40b367d95fb3d60fc1edb9ba8f6ef52272e48936.

Russell King has raised the idea of creating a proper PMU driver for
this SoC that would incorporate the functionality currently in this
driver.  It would also cover the use case for the graphics subsystem on
this SoC.

To prevent having to maintain the devicetree ABI for this limited
interrupt-handler driver, we revert the driver before it hits a mainline
tagged release (eg v3.15).

Signed-off-by: Jason Cooper 
---
Thomas,

Well, this is embarrassing.  It took so long to get this driver on the road to
mainline, only to realize today that we were going to paint ourselves into a
corner wrt the devicetree ABI this creates.

So, rather let a bad ABI make it to mainline, we revert the driver.  We'll sit
down with Russell, who's most familiar with the graphics subsystem on this SoC,
and hammer out a better longterm solution.

You can pick this, or I can send you an incremental pull request.  Whichever is
easiest for you.  I've already removed the DT node from the mvebu tree, so this
won't be used by anything.

thx,

Jason.

 .../interrupt-controller/marvell,dove-pmu-intc.txt |  17 ---
 drivers/irqchip/Makefile   |   1 -
 drivers/irqchip/irq-dove.c | 126 -
 3 files changed, 144 deletions(-)
 delete mode 100644 
Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt
 delete mode 100644 drivers/irqchip/irq-dove.c

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt
deleted file mode 100644
index 1feb5825d372..
--- 
a/Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Marvell Dove Power Management Unit interrupt controller
-
-Required properties:
-- compatible: shall be "marvell,dove-pmu-intc"
-- reg: base address of PMU interrupt registers starting with CAUSE register
-- interrupts: PMU interrupt of the main interrupt controller
-- interrupt-controller: identifies the node as an interrupt controller
-- #interrupt-cells: number of cells to encode an interrupt source, shall be 1
-
-Example:
-   pmu_intc: pmu-interrupt-ctrl@d0050 {
-   compatible = "marvell,dove-pmu-intc";
-   interrupt-controller;
-   #interrupt-cells = <1>;
-   reg = <0xd0050 0x8>;
-   interrupts = <33>;
-   };
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index f743006ce7ad..c60b9010b152 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -1,7 +1,6 @@
 obj-$(CONFIG_IRQCHIP)  += irqchip.o
 
 obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o
-obj-$(CONFIG_ARCH_DOVE)+= irq-dove.o
 obj-$(CONFIG_ARCH_EXYNOS)  += exynos-combiner.o
 obj-$(CONFIG_ARCH_MMP) += irq-mmp.o
 obj-$(CONFIG_ARCH_MVEBU)   += irq-armada-370-xp.o
diff --git a/drivers/irqchip/irq-dove.c b/drivers/irqchip/irq-dove.c
deleted file mode 100644
index 788acd89848a..
--- a/drivers/irqchip/irq-dove.c
+++ /dev/null
@@ -1,126 +0,0 @@
-/*
- * Marvell Dove SoCs PMU IRQ chip driver.
- *
- * Andrew Lunn 
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2.  This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "irqchip.h"
-
-#define DOVE_PMU_IRQ_CAUSE 0x00
-#define DOVE_PMU_IRQ_MASK  0x04
-
-static void dove_pmu_irq_handler(unsigned int irq, struct irq_desc *desc)
-{
-   struct irq_domain *d = irq_get_handler_data(irq);
-   struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0);
-   u32 stat = readl_relaxed(gc->reg_base + DOVE_PMU_IRQ_CAUSE) &
-  gc->mask_cache;
-
-   while (stat) {
-   u32 hwirq = ffs(stat) - 1;
-
-   generic_handle_irq(irq_find_mapping(d, gc->irq_base + hwirq));
-   stat &= ~(1 << hwirq);
-   }
-}
-
-static void pmu_irq_ack(struct irq_data *d)
-{
-   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-   struct irq_chip_type *ct = irq_data_get_chip_type(d);
-   u32 mask = ~d->mask;
-
-   /*
-* The PMU mask register is not RW0C: it is RW.  This means that
-* the bits take whatever value is written to them; if you write
-* a '1', you will set the interrupt.
-*
-* Unfortunately this means there is NO race free way to clear
-* these interrupts.
-*
-* So, let's structure the code so that the window is as small as
-* possible.
-*/
-   irq_gc_lock(gc);
-   mask &= irq_reg_readl(gc->reg_base +  ct->regs.ack);
-   irq_reg_writel(mask, gc->reg_base +  

Re: [PATCH v4] mm: per-thread vma caching

[Davidlohr Bueso]

On Mon, 2014-03-03 at 19:26 -0800, Linus Torvalds wrote:
> On Mon, Mar 3, 2014 at 7:13 PM, Davidlohr Bueso  wrote:
> >
> > Yes, I shortly realized that was silly... but I can say for sure it can
> > happen and a quick qemu run confirms it. So I see your point as to
> > asking why we need it, so now I'm looking for an explanation in the
> > code.
> 
> We definitely *do* have users.
> 
> One example would be ptrace -> access_process_vm -> __access_remote_vm
> -> get_user_pages() -> find_extend_vma() -> find_vma_prev -> find_vma.

And:

[4.274542] Call Trace:
[4.274747]  [] dump_stack+0x46/0x58
[4.275069]  [] vmacache_find+0xae/0xc0
[4.275425]  [] find_vma+0x20/0x80
[4.275625]  [] find_extend_vma+0x2b/0x90
[4.275982]  [] __get_user_pages+0x99/0x5a0
[4.276427]  [] ? follow_page_mask+0x32b/0x400
[4.276671]  [] get_user_pages+0x52/0x60
[4.276886]  [] copy_strings.isra.20+0x1a3/0x2f0
[4.277239]  [] copy_strings_kernel+0x3d/0x50
[4.277472]  [] load_script+0x1e8/0x280
[4.277692]  [] ? copy_strings.isra.20+0xea/0x2f0
[4.277931]  [] search_binary_handler+0x97/0x1d0
[4.278288]  [] do_execve_common.isra.28+0x4ef/0x650
[4.278544]  [] do_execve+0x18/0x20
[4.278754]  [] SyS_execve+0x2e/0x40
[4.278960]  [] stub_execve+0x69/0xa0


--
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:tidspbridge: Fixed braces, spaces and long line coding style

[Masood Mehmood]

This patch applies following code style changes to the whole driver.

- Removing braces from single statements following a 'if' statement.
- Removing unnessasary spaces and braces from files.
- Re-order statements crossing 80 columns limitation.
- Fixed one quoted string split across lines.

Signed-off-by: Masood Mehmood 
---
 drivers/staging/tidspbridge/core/io_sm.c  |  2 +-
 drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 15 +--
 drivers/staging/tidspbridge/rmgr/nldr.c   |  3 +--
 drivers/staging/tidspbridge/rmgr/node.c   | 14 +++---
 4 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/io_sm.c 
b/drivers/staging/tidspbridge/core/io_sm.c
index e322fb7..c2829aa 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -2127,7 +2127,7 @@ void dump_dl_modules(struct bridge_dev_context 
*bridge_context)
u32 module_size;
u32 module_struct_size = 0;
u32 sect_ndx;
-   char *sect_str ;
+   char *sect_str;
int status = 0;
 
status = dev_get_intf_fxns(dev_object, _fxns);
diff --git a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c 
b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
index 1862afd..657104f 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430_pwr.c
@@ -99,7 +99,8 @@ int handle_hibernation_from_dsp(struct bridge_dev_context 
*dev_context)
return -EPERM;
}
pwr_state = (*pdata->dsp_prm_read)(OMAP3430_IVA2_MOD,
-   OMAP2_PM_PWSTST) & 
OMAP_POWERSTATEST_MASK;
+  OMAP2_PM_PWSTST) &
+  OMAP_POWERSTATEST_MASK;
}
if (timeout == 0) {
pr_err("%s: Timed out waiting for DSP off mode\n", __func__);
@@ -209,7 +210,8 @@ int sleep_dsp(struct bridge_dev_context *dev_context, u32 
dw_cmd,
return -EPERM;
}
pwr_state = (*pdata->dsp_prm_read)(OMAP3430_IVA2_MOD,
-   OMAP2_PM_PWSTST) & 
OMAP_POWERSTATEST_MASK;
+  OMAP2_PM_PWSTST) &
+  OMAP_POWERSTATEST_MASK;
}
 
if (!timeout) {
@@ -355,7 +357,7 @@ int pre_scale_dsp(struct bridge_dev_context *dev_context, 
void *pargs)
(dev_context->brd_state == BRD_DSP_HIBERNATION)) {
dev_dbg(bridge, "OPP: %s IVA in sleep. No message to DSP\n");
return 0;
-   } else if ((dev_context->brd_state == BRD_RUNNING)) {
+   } else if (dev_context->brd_state == BRD_RUNNING) {
/* Send a prenotification to DSP */
dev_dbg(bridge, "OPP: %s sent notification to DSP\n", __func__);
sm_interrupt_dsp(dev_context, MBX_PM_SETPOINT_PRENOTIFY);
@@ -396,13 +398,14 @@ int post_scale_dsp(struct bridge_dev_context *dev_context,
io_sh_msetting(hio_mgr, SHM_CURROPP, );
dev_dbg(bridge, "OPP: %s IVA in sleep. Wrote to shm\n",
__func__);
-   } else if ((dev_context->brd_state == BRD_RUNNING)) {
+   } else if (dev_context->brd_state == BRD_RUNNING) {
/* Update the OPP value in shared memory */
io_sh_msetting(hio_mgr, SHM_CURROPP, );
/* Send a post notification to DSP */
sm_interrupt_dsp(dev_context, MBX_PM_SETPOINT_POSTNOTIFY);
-   dev_dbg(bridge, "OPP: %s wrote to shm. Sent post notification "
-   "to DSP\n", __func__);
+   dev_dbg(bridge,
+   "OPP: %s wrote to shm. Sent post notification to DSP\n",
+__func__);
} else {
status = -EPERM;
}
diff --git a/drivers/staging/tidspbridge/rmgr/nldr.c 
b/drivers/staging/tidspbridge/rmgr/nldr.c
index 7e10c95..5ac507c 100644
--- a/drivers/staging/tidspbridge/rmgr/nldr.c
+++ b/drivers/staging/tidspbridge/rmgr/nldr.c
@@ -1751,9 +1751,8 @@ static void unload_ovly(struct nldr_nodeobject 
*nldr_node_obj,
}
if (ref_count && (*ref_count > 0)) {
*ref_count -= 1;
-   if (other_ref) {
+   if (other_ref)
*other_ref -= 1;
-   }
}
 
if (ref_count && *ref_count == 0) {
diff --git a/drivers/staging/tidspbridge/rmgr/node.c 
b/drivers/staging/tidspbridge/rmgr/node.c
index c0211dd..9d3044a 100644
--- a/drivers/staging/tidspbridge/rmgr/node.c
+++ b/drivers/staging/tidspbridge/rmgr/node.c
@@ -406,7 +406,7 @@ int node_allocate(struct proc_object *hprocessor,
 
/* check for page aligned Heap size */
if (((attr_in->heap_size) & (PG_SIZE4K - 1))) {
-   pr_err("%s: node 

[RFC][PATCH] clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

[Mike Galbraith]

Greetings,

While rummaging around looking for HTH a gaggle of weird a$$ machines
can manage to timewarp back and forth by exactly 208 days, I stumbled
across $subject which looks like it may want to borrow Salman's fix.

clocksource: avoid unnecessary overflow in cyclecounter_cyc2ns()

As per 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock",
cycles * mult >> shift is overflow prone. so give it the same treatment.

Cc: Salman Qazi 
Cc: John Stultz 
Signed-off-by: Mike Galbraith 
---
 include/linux/clocksource.h |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -77,13 +77,18 @@ struct timecounter {
  *
  * XXX - This could use some mult_lxl_ll() asm optimization. Same code
  * as in cyc2ns, but with unsigned result.
+ *
+ * Because it is the same as x86 __cycles_2_ns, give it the same treatment as
+ * commit 4cecf6d401a "sched, x86: Avoid unnecessary overflow in sched_clock"
+ * to avoid a potential cycles * mult overflow.
  */
 static inline u64 cyclecounter_cyc2ns(const struct cyclecounter *cc,
  cycle_t cycles)
 {
-   u64 ret = (u64)cycles;
-   ret = (ret * cc->mult) >> cc->shift;
-   return ret;
+   u64 quot = (u64)cycles >> cc->shift;
+   u64 rem = (u64)cycles & ((1ULL << cc->shift) - 1);
+
+   return  quot * cc->mult + ((rem * cc->mult) >> cc->shift);
 }
 
 /**


--
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 02/11] perf: add PMU_FORMAT_RANGE() helper for use by sw-like pmus

[Michael Ellerman]

On Thu, 2014-27-02 at 21:04:55 UTC, Cody P Schafer wrote:
> Add PMU_FORMAT_RANGE() and PMU_FORMAT_RANGE_RESERVED() (for reserved
> areas) which generate functions to extract the relevent bits from
> event->attr.config{,1,2} for use by sw-like pmus where the
> 'config{,1,2}' values don't map directly to hardware registers.
> 
> Signed-off-by: Cody P Schafer 
> ---
>  include/linux/perf_event.h | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index e56b07f..3da5081 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -871,4 +871,21 @@ _name##_show(struct device *dev, 
> \
>   \
>  static struct device_attribute format_attr_##_name = __ATTR_RO(_name)
>  
> +#define PMU_FORMAT_RANGE(name, attr_var, bit_start, bit_end) \
> +PMU_FORMAT_ATTR(name, #attr_var ":" #bit_start "-" #bit_end);
> \
> +PMU_FORMAT_RANGE_RESERVED(name, attr_var, bit_start, bit_end)

I really think these should have event in the name.

Someone looking at the code is going to see event_get_foo() and wonder where
that is defined. Grep won't find a definition, tags won't find a definition,
the least you can do is have the macro name give some hint.

> +#define PMU_FORMAT_RANGE_RESERVED(name, attr_var, bit_start, bit_end)
> \

It doesn't generate a format attribute.

> +static u64 event_get_##name##_max(void)  
> \
> +{\
> + int bits = (bit_end) - (bit_start) + 1; \
> + return ((0x1ULL << (bits - 1ULL)) - 1ULL) | \
> + (0xFULL << (bits - 4ULL));  \

What's wrong with:

(0x1ULL << ((bit_end) - (bit_start) + 1)) - 1ULL;

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/

Re: [PATCH v3 03/11] perf: provide a common perf_event_nop_0() for use with .event_idx

[Michael Ellerman]

On Thu, 2014-27-02 at 21:04:56 UTC, Cody P Schafer wrote:
> Rather an having every pmu that needs a function that just returns 0 for
> .event_idx define their own copy, reuse the one in kernel/events/core.c.
> 
> Rename from perf_swevent_event_idx() because we're no longer using it
> for just software events. Naming is based on the perf_pmu_nop_*()
> functions.

You could just use perf_pmu_nop_int() directly.

Peterz, OK by you?

cheers

> Signed-off-by: Cody P Schafer 
> ---
>  include/linux/perf_event.h |  1 +
>  kernel/events/core.c   | 10 +-
>  2 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 3da5081..24a7b45 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -560,6 +560,7 @@ extern void perf_pmu_migrate_context(struct pmu *pmu,
>  extern u64 perf_event_read_value(struct perf_event *event,
>u64 *enabled, u64 *running);
>  
> +extern int perf_event_nop_0(struct perf_event *event);
>  
>  struct perf_sample_data {
>   u64 type;
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 56003c6..2938a77 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5816,7 +5816,7 @@ static int perf_swevent_init(struct perf_event *event)
>   return 0;
>  }
>  
> -static int perf_swevent_event_idx(struct perf_event *event)
> +int perf_event_nop_0(struct perf_event *event)
>  {
>   return 0;
>  }
> @@ -5831,7 +5831,7 @@ static struct pmu perf_swevent = {
>   .stop   = perf_swevent_stop,
>   .read   = perf_swevent_read,
>  
> - .event_idx  = perf_swevent_event_idx,
> + .event_idx  = perf_event_nop_0,
>  };
>  
>  #ifdef CONFIG_EVENT_TRACING
> @@ -5950,7 +5950,7 @@ static struct pmu perf_tracepoint = {
>   .stop   = perf_swevent_stop,
>   .read   = perf_swevent_read,
>  
> - .event_idx  = perf_swevent_event_idx,
> + .event_idx  = perf_event_nop_0,
>  };
>  
>  static inline void perf_tp_register(void)
> @@ -6177,7 +6177,7 @@ static struct pmu perf_cpu_clock = {
>   .stop   = cpu_clock_event_stop,
>   .read   = cpu_clock_event_read,
>  
> - .event_idx  = perf_swevent_event_idx,
> + .event_idx  = perf_event_nop_0,
>  };
>  
>  /*
> @@ -6257,7 +6257,7 @@ static struct pmu perf_task_clock = {
>   .stop   = task_clock_event_stop,
>   .read   = task_clock_event_read,
>  
> - .event_idx  = perf_swevent_event_idx,
> + .event_idx  = perf_event_nop_0,
>  };
>  
>  static void perf_pmu_nop_void(struct pmu *pmu)
> -- 
> 1.9.0
> 
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
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 net-next 1/3] Extended BPF interpreter and converter

[Alexei Starovoitov]

Extended BPF extends old BPF in the following ways:
- from 2 to 10 registers
  Original BPF has two registers (A and X) and hidden frame pointer.
  Extended BPF has ten registers and read-only frame pointer.
- from 32-bit registers to 64-bit registers
  semantics of old 32-bit ALU operations are preserved via 32-bit
  subregisters
- if (cond) jump_true; else jump_false;
  old BPF insns are replaced with:
  if (cond) jump_true; /* else fallthrough */
- adds signed > and >= insns
- 16 4-byte stack slots for register spill-fill replaced with
  up to 512 bytes of multi-use stack space
- introduces bpf_call insn and register passing convention for zero
  overhead calls from/to other kernel functions (not part of this patch)
- adds arithmetic right shift insn
- adds swab32/swab64 insns
- adds atomic_add insn
- old tax/txa insns are replaced with 'mov dst,src' insn

Extended BPF is designed to be JITed with one to one mapping, which
allows GCC/LLVM backends to generate optimized BPF code that performs
almost as fast as natively compiled code

sk_convert_filter() remaps old style insns into extended:
'sock_filter' instructions are remapped on the fly to
'sock_filter_ext' extended instructions when
sysctl net.core.bpf_ext_enable=1

Old filter comes through sk_attach_filter() or sk_unattached_filter_create()
 if (bpf_ext_enable) {
convert to new
sk_chk_filter() - check old bpf
use sk_run_filter_ext() - new interpreter
 } else {
sk_chk_filter() - check old bpf
if (bpf_jit_enable)
use old jit
else
use sk_run_filter() - old interpreter
 }

sk_run_filter_ext() interpreter is noticeably faster
than sk_run_filter() for two reasons:

1.fall-through jumps
  Old BPF jump instructions are forced to go either 'true' or 'false'
  branch which causes branch-miss penalty.
  Extended BPF jump instructions have one branch and fall-through,
  which fit CPU branch predictor logic better.
  'perf stat' shows drastic difference for branch-misses.

2.jump-threaded implementation of interpreter vs switch statement
  Instead of single tablejump at the top of 'switch' statement, GCC will
  generate multiple tablejump instructions, which helps CPU branch predictor

Performance of two BPF filters generated by libpcap was measured
on x86_64, i386 and arm32.

fprog #1 is taken from Documentation/networking/filter.txt:
tcpdump -i eth0 port 22 -dd

fprog #2 is taken from 'man tcpdump':
tcpdump -i eth0 'tcp port 22 and (((ip[2:2] - ((ip[0]&0xf)<<2)) -
   ((tcp[12]&0xf0)>>2)) != 0)' -dd

Other libpcap programs have similar performance differences.

Raw performance data from BPF micro-benchmark:
SK_RUN_FILTER on same SKB (cache-hit) or 10k SKBs (cache-miss)
time in nsec per call, smaller is better
--x86_64--
 fprog #1  fprog #1   fprog #2  fprog #2
 cache-hit cache-miss cache-hit cache-miss
old BPF 90   101   192   202
ext BPF 3171   47 97
old BPF jit 1234   17 44
ext BPF jit TBD

--i386--
 fprog #1  fprog #1   fprog #2  fprog #2
 cache-hit cache-miss cache-hit cache-miss
old BPF107136  227   252
ext BPF 40119   69   172

--arm32--
 fprog #1  fprog #1   fprog #2  fprog #2
 cache-hit cache-miss cache-hit cache-miss
old BPF202300  475   540
ext BPF139270  296   470
old BPF jit 26182   37   202
new BPF jit TBD

Tested with trinify BPF fuzzer

Future work:

0. seccomp

1. add extended BPF JIT for x86_64

2. add inband old/new demux and extended BPF verifier, so that new programs
   can be loaded through old sk_attach_filter() and 
sk_unattached_filter_create()
   interfaces

3. tracing filters systemtap-like with extended BPF

4. OVS with extended BPF

5. nftables with extended BPF

Signed-off-by: Alexei Starovoitov 
---
 include/linux/filter.h  |8 +-
 include/linux/netdevice.h   |1 +
 include/uapi/linux/filter.h |   34 +-
 net/core/filter.c   |  802 ++-
 net/core/sysctl_net_core.c  |7 +
 5 files changed, 830 insertions(+), 22 deletions(-)

diff --git a/include/linux/filter.h b/include/linux/filter.h
index e568c8ef896b..0e84ff6e991b 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -52,7 +52,13 @@ extern int sk_detach_filter(struct sock *sk);
 extern int sk_chk_filter(struct sock_filter *filter, unsigned int flen);
 extern int sk_get_filter(struct sock *sk, struct sock_filter __user *filter, 
unsigned len);
 extern void sk_decode_filter(struct sock_filter *filt, struct sock_filter *to);
+/* function remaps 'sock_filter' insns to 'sock_filter_ext' insns */
+int sk_convert_filter(struct sock_filter *old_prog, int len,
+ struct sock_filter_ext *new_prog, int *p_new_len);
+/* execute extended bpf program */
+unsigned int sk_run_filter_ext(void *ctx, const struct sock_filter_ext *insn);
 
+#define 

[PATCH v4 net-next 3/3] Extended BPF documentation

[Alexei Starovoitov]

Signed-off-by: Alexei Starovoitov 
---
 Documentation/networking/filter.txt |  181 +++
 1 file changed, 181 insertions(+)

diff --git a/Documentation/networking/filter.txt 
b/Documentation/networking/filter.txt
index a06b48d2f5cc..c3f687bf8e82 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -546,6 +546,186 @@ a0069c8f + :
 For BPF JIT developers, bpf_jit_disasm, bpf_asm and bpf_dbg provides a useful
 toolchain for developing and testing the kernel's JIT compiler.
 
+Extended BPF
+
+Extended BPF extends BPF in the following ways:
+- from 2 to 10 registers
+  Original BPF has two registers (A and X) and hidden frame pointer.
+  Extended BPF has ten registers and read-only frame pointer.
+- from 32-bit registers to 64-bit registers
+  semantics of old 32-bit ALU operations are preserved via 32-bit
+  subregisters
+- if (cond) jump_true; else jump_false;
+  old BPF insns are replaced with:
+  if (cond) jump_true; /* else fallthrough */
+- adds signed > and >= insns
+- 16 4-byte stack slots for register spill-fill replaced with
+  up to 512 bytes of multi-use stack space
+- introduces bpf_call insn and register passing convention for zero
+  overhead calls from/to other kernel functions (not part of this patch)
+- adds arithmetic right shift insn
+- adds swab32/swab64 insns
+- adds atomic_add insn
+- old tax/txa insns are replaced with 'mov dst,src' insn
+
+Extended BPF is designed to be JITed with one to one mapping, which
+allows GCC/LLVM compilers to generate optimized BPF code that performs
+almost as fast as natively compiled code
+
+sysctl net.core.bpf_ext_enable=1
+controls whether filters attached to sockets will be automatically
+converted to extended BPF or not.
+
+BPF is safe dynamically loadable program that can call fixed set
+of kernel functions and takes a pointer to data as an input,
+where data is skb, seccomp_data, kprobe function arguments or else.
+
+Extended Instruction Set was designed with these goals:
+- write programs in restricted C and compile into BPF with GCC/LLVM
+- just-in-time map to modern 64-bit CPU with minimal performance overhead
+  over two steps: C -> BPF -> native code
+- guarantee termination and safety of BPF program in kernel
+  with simple algorithm
+
+GCC/LLVM-bpf backend is optional.
+Extended BPF can be coded with macroses from filter.h just like original BPF,
+though the same filter done in C is easier to understand.
+sk_convert_filter() remaps original BPF insns into extended.
+
+Minimal performance overhead is achieved by having one to one mapping
+between BPF insns and native insns, and one to one mapping between BPF
+registers and native registers on 64-bit CPUs
+
+Extended BPF may allow jump forward and backward for two reasons:
+to reduce branch mispredict penalty compiler moves cold basic blocks out of
+fall-through path and to reduce code duplication that would be hard to avoid
+if only jump forward was available.
+To guarantee termination simple non-recursive depth-first-search verifies
+that there are no back-edges (no loops in the program), program is a DAG
+with root at the first insn, all branches end at the last RET insn and
+all instructions are reachable.
+Original BPF actually allows unreachable insns. Though it's safe, it will be
+fixed when extended BPF replaces BPF completely.
+
+Original BPF has two registers (A and X) and hidden frame pointer.
+Extended BPF has ten registers and read-only frame pointer.
+Since 64-bit CPUs are passing arguments to the functions via registers
+the number of args from BPF program to in-kernel function is restricted to 5
+and one register is used to accept return value from in-kernel function.
+x86_64 passes first 6 arguments in registers.
+aarch64/sparcv9/mips64 have 7-8 registers for arguments.
+x86_64 has 6 callee saved registers.
+aarch64/sparcv9/mips64 have 11 or more callee saved registers.
+
+Therefore extended BPF calling convention is defined as:
+R0 - return value from in-kernel function
+R1-R5 - arguments from BPF program to in-kernel function
+R6-R9 - callee saved registers that in-kernel function will preserve
+R10 - read-only frame pointer to access stack
+
+so that all BPF registers map one to one to HW registers on x86_64,aarch64,etc
+and BPF calling convention maps directly to ABIs used by kernel on 64-bit
+architectures.
+On 32-bit architectures JIT may map programs that use only 32-bit arithmetic
+and let more complex programs to be interpreted.
+
+R0-R5 are scratch registers and BPF program needs spill/fill them if necessary
+across calls.
+Note that there is only one BPF program == one BPF function and it cannot call
+other BPF functions. It can only call predefined in-kernel functions.
+
+All BPF registers are 64-bit with 32-bit lower subregister that zero-extends
+into 64-bit if written to. That behavior maps directly to x86_64 and arm64
+subregister defintion, but makes other JITs more 

[PATCH v4 net-next 2/3] RFC: convert seccomp to use extended BPF

[Alexei Starovoitov]

use sk_convert_filter() to convert seccomp BPF into extended BPF

05-sim-long_jumps.c of libseccomp was used as micro-benchmark:
  seccomp_rule_add_exact(ctx,...
  seccomp_rule_add_exact(ctx,...
  rc = seccomp_load(ctx);
  for (i = 0; i < 1000; i++)
 syscall(199, 100);

--x86_64--
old BPF: 8.6 seconds
73.38%bench  [kernel.kallsyms]  [k] sk_run_filter
10.70%bench  libc-2.15.so   [.] syscall
 5.09%bench  [kernel.kallsyms]  [k] seccomp_bpf_load
 1.97%bench  [kernel.kallsyms]  [k] system_call
ext BPF: 5.7 seconds
66.20%bench  [kernel.kallsyms]  [k] sk_run_filter_ext
16.75%bench  libc-2.15.so   [.] syscall
 3.31%bench  [kernel.kallsyms]  [k] system_call
 2.88%bench  [kernel.kallsyms]  [k] __secure_computing

--i386---
old BPF: 5.4 sec
ext BPF: 3.8 sec

BPF filters generated by seccomp are very branchy, so ext BPF
performance is better than old BPF.

Performance gains will be even higher when extended BPF JIT
is committed.

Signed-off-by: Alexei Starovoitov 

---
This patch is an RFC to use extended BPF in seccomp.
Change it to do it conditionally with bpf_ext_enable knob ?
---
 include/linux/seccomp.h |1 -
 kernel/seccomp.c|  112 +--
 net/core/filter.c   |5 ---
 3 files changed, 51 insertions(+), 67 deletions(-)

diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 6f19cfd1840e..4054b0994071 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -76,7 +76,6 @@ static inline int seccomp_mode(struct seccomp *s)
 #ifdef CONFIG_SECCOMP_FILTER
 extern void put_seccomp_filter(struct task_struct *tsk);
 extern void get_seccomp_filter(struct task_struct *tsk);
-extern u32 seccomp_bpf_load(int off);
 #else  /* CONFIG_SECCOMP_FILTER */
 static inline void put_seccomp_filter(struct task_struct *tsk)
 {
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index b7a10048a32c..346c597b44cc 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -55,60 +55,27 @@ struct seccomp_filter {
atomic_t usage;
struct seccomp_filter *prev;
unsigned short len;  /* Instruction count */
-   struct sock_filter insns[];
+   struct sock_filter_ext insns[];
 };
 
 /* Limit any path through the tree to 256KB worth of instructions. */
 #define MAX_INSNS_PER_PATH ((1 << 18) / sizeof(struct sock_filter))
 
-/**
- * get_u32 - returns a u32 offset into data
- * @data: a unsigned 64 bit value
- * @index: 0 or 1 to return the first or second 32-bits
- *
- * This inline exists to hide the length of unsigned long.  If a 32-bit
- * unsigned long is passed in, it will be extended and the top 32-bits will be
- * 0. If it is a 64-bit unsigned long, then whatever data is resident will be
- * properly returned.
- *
+/*
  * Endianness is explicitly ignored and left for BPF program authors to manage
  * as per the specific architecture.
  */
-static inline u32 get_u32(u64 data, int index)
-{
-   return ((u32 *))[index];
-}
-
-/* Helper for bpf_load below. */
-#define BPF_DATA(_name) offsetof(struct seccomp_data, _name)
-/**
- * bpf_load: checks and returns a pointer to the requested offset
- * @off: offset into struct seccomp_data to load from
- *
- * Returns the requested 32-bits of data.
- * seccomp_check_filter() should assure that @off is 32-bit aligned
- * and not out of bounds.  Failure to do so is a BUG.
- */
-u32 seccomp_bpf_load(int off)
+static void populate_seccomp_data(struct seccomp_data *sd)
 {
struct pt_regs *regs = task_pt_regs(current);
-   if (off == BPF_DATA(nr))
-   return syscall_get_nr(current, regs);
-   if (off == BPF_DATA(arch))
-   return syscall_get_arch(current, regs);
-   if (off >= BPF_DATA(args[0]) && off < BPF_DATA(args[6])) {
-   unsigned long value;
-   int arg = (off - BPF_DATA(args[0])) / sizeof(u64);
-   int index = !!(off % sizeof(u64));
-   syscall_get_arguments(current, regs, arg, 1, );
-   return get_u32(value, index);
-   }
-   if (off == BPF_DATA(instruction_pointer))
-   return get_u32(KSTK_EIP(current), 0);
-   if (off == BPF_DATA(instruction_pointer) + sizeof(u32))
-   return get_u32(KSTK_EIP(current), 1);
-   /* seccomp_check_filter should make this impossible. */
-   BUG();
+   int i;
+
+   sd->nr = syscall_get_nr(current, regs);
+   sd->arch = syscall_get_arch(current, regs);
+   for (i = 0; i < 6; i++)
+   syscall_get_arguments(current, regs, i, 1,
+ (unsigned long *)>args[i]);
+   sd->instruction_pointer = KSTK_EIP(current);
 }
 
 /**
@@ -133,17 +100,17 @@ static int seccomp_check_filter(struct sock_filter 
*filter, unsigned int flen)
 
switch (code) {
case BPF_S_LD_W_ABS:
-   ftest->code = BPF_S_ANC_SECCOMP_LD_W;
+   

[PATCH v4 net-next 0/3] Extended BPF, converter, seccomp, doc

[Alexei Starovoitov]

Hi All,

V1 patches:
http://thread.gmane.org/gmane.linux.kernel/1605783
V2 patches:
http://thread.gmane.org/gmane.linux.kernel/1642325
V3 patches:
http://thread.gmane.org/gmane.linux.kernel/1656538

V4 summary:
- addressed Daniel comments
- RFC for seccomp with extended BPF
- added extended BPF design doc

Please review.
Thanks!

Alexei Starovoitov (3):
  Extended BPF interpreter and converter
  RFC: convert seccomp to use extended BPF
  Extended BPF documentation

 Documentation/networking/filter.txt |  181 
 include/linux/filter.h  |8 +-
 include/linux/netdevice.h   |1 +
 include/linux/seccomp.h |1 -
 include/uapi/linux/filter.h |   34 +-
 kernel/seccomp.c|  112 +++--
 net/core/filter.c   |  807 ++-
 net/core/sysctl_net_core.c  |7 +
 8 files changed, 1062 insertions(+), 89 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/

linux-next: manual merge of the tip tree with the omap_dss2 tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got conflicts in
drivers/video/Kconfig, drivers/video/Makefile and drivers/video/sgivwfb.c
between commit 08667731d1d4 ("video: move fbdev to drivers/video/fbdev")
from the omap_dss2 tree and commit c5f9ee3d665a ("x86, platforms: Remove
SGI Visual Workstation") from the tip tree.

I removed drivers/video/fbdev/sgivwfb.c and added the following merge
fix patch and can carry the fix as necessary (no action is required).

From: Stephen Rothwell 
Date: Tue, 4 Mar 2014 16:11:12 +1100
Subject: [PATCH] video: fbdev: fix up fro removal of SGI Visual Workstation

Signed-off-by: Stephen Rothwell 
---
 drivers/video/fbdev/Kconfig  | 11 +--
 drivers/video/fbdev/Makefile |  1 -
 2 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 31c3f3ddfd38..6b1984c7f4e7 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -765,18 +765,9 @@ config FB_HGA
  As this card technology is at least 25 years old,
  most people will answer N here.
 
-config FB_SGIVW
-   tristate "SGI Visual Workstation framebuffer support"
-   depends on FB && X86_VISWS
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
-   help
- SGI Visual Workstation support for framebuffer graphics.
-
 config FB_GBE
bool "SGI Graphics Backend frame buffer support"
-   depends on (FB = y) && (SGI_IP32 || X86_VISWS)
+   depends on (FB = y) && SGI_IP32
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 6ef2c66110e3..0284f2a12538 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -55,7 +55,6 @@ obj-$(CONFIG_FB_CG14) += cg14.o sbuslib.o
 obj-$(CONFIG_FB_P9100)+= p9100.o sbuslib.o
 obj-$(CONFIG_FB_TCX)  += tcx.o sbuslib.o
 obj-$(CONFIG_FB_LEO)  += leo.o sbuslib.o
-obj-$(CONFIG_FB_SGIVW)+= sgivwfb.o
 obj-$(CONFIG_FB_ACORN)+= acornfb.o
 obj-$(CONFIG_FB_ATARI)+= atafb.o c2p_iplan2.o atafb_mfb.o \
  atafb_iplan2p2.o atafb_iplan2p4.o 
atafb_iplan2p8.o
-- 
1.9.0

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpVn7ZBj9KsB.pgp
Description: PGP signature

Re: [patch] x86, kmemcheck: Use kstrtoint() instead of sscanf()

[David Rientjes]

On Mon, 3 Mar 2014, Pekka Enberg wrote:

> > Kmemcheck should use the preferred interface for parsing command line
> > arguments, kstrto*(), rather than sscanf() itself.  Use it appropriately.
> > 
> > Signed-off-by: David Rientjes 
> 
> Acked-by: Pekka Enberg 
> 

Thanks!

> Andrew, can you pick this up?
> 

It's already picked up, see 
http://ozlabs.org/~akpm/mmotm/broken-out/arch-x86-mm-kmemcheck-kmemcheckc-use-kstrtoint-instead-of-sscanf.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] mm, oom: normalize the adj to ensure oom_badness return one

[David Rientjes]

On Mon, 3 Mar 2014, He, Bo wrote:

> if oom_score_adj is a big negative number, such as -941,
> adj *= totalpages / 1000 will be a big negative number, 
> finally the oom_badness will get 0 points, here normalize 
> the oom_score_adj to ensure oom_badness return the
> positive number.
> 

Sorry, I have no clue what you're talking about or trying to fix.

A /proc/pid/oom_score_adj of -941 would mean discounting 94.1% of system 
memory from pid's resident memory usage for a system oom condition.  This 
is the effect of adj *= totalpages / 1000 and is working as intended per 
Documentation/filesystems/proc.txt.

oom_badness() will then return the smallest integer possible, 1 (not 0), 
that still allows the process to be killed, that's the effect of 
"return points > 0 ? points : 1".  It never returns 0 as you state, you're 
either not reading the code correctly or not working on any recent kernel.

> Change-Id: I1c56a948ce48b65a1bb63b56ffef07d5d76d7ec8
> Signed-off-by: he, bo 
> Signed-off-by: wang, biao 
> Reviewed-by: Yanmin Zhang 
> ---
>  mm/oom_kill.c |3 +++ 
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 3291e82..5a93986 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -181,6 +181,9 @@ unsigned long oom_badness(struct task_struct *p, struct 
> mem_cgroup *memcg,
> points -= (points * 3) / 100;
>  
> /* Normalize to oom_score_adj units */
> +   if(OOM_SCORE_ADJ_MIN < 0)
> +   adj -= OOM_SCORE_ADJ_MIN;
> +
> adj *= totalpages / 1000;
> points += adj;
>  
--
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: Re: [PATCH] x86: set Pentium M as PAE capable

[H. Peter Anvin]

forcepae is descriptive.

On March 3, 2014 9:01:30 PM PST, Chris Bainbridge  
wrote:
>On Mon, Mar 03, 2014 at 08:29:39PM +0100, Borislav Petkov wrote:
>> On Mon, Mar 03, 2014 at 03:04:35PM +0700, Chris Bainbridge wrote:
>> > On 3 March 2014 02:05, Roland Kletzing  wrote:
>> > > i would recommend adding the newly introduced param to
>> > > Documentation/kernel-
>> > > parameters.txt , though.
>> > 
>> > Done.
>> > 
>> > Signed-off-by: Chris Bainbridge 
>> > ---
>> > diff --git a/Documentation/kernel-parameters.txt
>b/Documentation/kernel-parameters.txt
>> > index b9e9bd8..388b5e9 100644
>> > --- a/Documentation/kernel-parameters.txt
>> > +++ b/Documentation/kernel-parameters.txt
>> > @@ -962,6 +962,13 @@ bytes respectively. Such letter suffixes can
>also be entirely omitted.
>> >parameter will force ia64_sal_cache_flush to call
>> >ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
>> >  
>> > +  forcepae [X86-32]
>> > +  Forcefully enable Physical Address Extension (PAE).
>> > +  Many Pentium M systems disable PAE but may have a
>> > +  functionally usable PAE implementation.
>> > +  Note: This parameter is unsupported, may cause unknown
>> 
>> What does "unsupported" mean here exactly?
>
>It was supposed to have the dual meaning that neither the kernel
>developers or Intel are going to help you if it doesn't work. But
>perhaps it is unnecessary - being tainted implies that the kernel
>developers won't help, and Intel certainly won't be interested.
>
>> 
>> This function is called check_cpuflags() now. You probably want to
>redo
>> your patch against tip/master, i.e.:
>> 
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git#master
>> 
>
>Done, new patch is against tip.
>
>> > +  }
>> > +  else {
>> > +  puts("ERROR: PAE is disabled on this Pentium M\n"
>> > +  "(PAE can potentially be enabled with "
>> > +  "kernel parameter\n"
>> > +  "\"forcepae\" - this is unsupported, may "
>> > +  "cause unknown\n"
>> > +  "problems, and will taint the kernel)\n");
>> 
>> This string could definitely violate the 80 cols rule so that it is
>much
>> more readable:
>> 
>>  }
>>  else
>>  puts("WARNING: PAE disabled. Use \"forcepae\" to enable 
>> at your
>own risk!\n");
>> 
>> I've shortened it to the most relevant info only. No need to say
>we're
>> tainting the kernel because LOCKDEP_NOW_UNRELIABLE will cause that
>> anyway below.
>
>Ok I changed it to: "WARNING: PAE disabled. Use parameter 'pae' to
>enable at your own risk!\n""
>
>> > diff --git a/arch/x86/kernel/cpu/intel.c
>b/arch/x86/kernel/cpu/intel.c
>> > index bbe1b8b..271686d 100644
>> > --- a/arch/x86/kernel/cpu/intel.c
>> > +++ b/arch/x86/kernel/cpu/intel.c
>> > @@ -196,6 +196,14 @@ static void intel_smp_check(struct cpuinfo_x86
>*c)
>> >}
>> >  }
>> >  
>> > +static int forcepae;
>> > +static int __init forcepae_setup(char *__unused)
>> > +{
>> > +  forcepae = 1;
>> > +  return 1;
>> > +}
>> > +__setup("forcepae", forcepae_setup);
>> 
>> Yeah, why not simply call it "pae"? It is smaller and the letter
>> combination is not used yet and it means the same.
>
>I don't see any reason not to just use "pae" "forcepae" is perhaps a
>bit
>more descriptive but the other text in the patch clearly describes the
>parameter so it doesn't really matter.
>
>> >  static void intel_workarounds(struct cpuinfo_x86 *c)
>> >  {
>> >unsigned long lo, hi;
>> > @@ -226,6 +234,17 @@ static void intel_workarounds(struct
>cpuinfo_x86 *c)
>> >clear_cpu_cap(c, X86_FEATURE_SEP);
>> >  
>> >/*
>> > +   * PAE CPUID issue: many Pentium M report no PAE but may have a
>> > +   * functionally usable PAE implementation.
>> > +   * Forcefully enable PAE if kernel parameter "forcepae" is
>present.
>> > +   */
>> > +  if (forcepae) {
>> > +  printk(KERN_WARNING "PAE forced!\n");
>> > +  set_cpu_cap(c, X86_FEATURE_PAE);
>> > +  add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_NOW_UNRELIABLE);
>> 
>> Right, this implies Dave's patch is preceding yours. I guess hpa can
>> fish it out from the thread when applying.
>
>I will include Dave's patch, it is trivial. 
>
>New patch with all above changes follows.
>
>Signed-off-by: Chris Bainbridge 
>---
>
>diff --git a/Documentation/kernel-parameters.txt
>b/Documentation/kernel-parameters.txt
>index 580a60c..7d57a5a 100644
>--- a/Documentation/kernel-parameters.txt
>+++ b/Documentation/kernel-parameters.txt
>@@ -2307,6 +2307,13 @@ bytes respectively. Such letter suffixes can
>also be entirely omitted.
>   OSS [HW,OSS]
>   See Documentation/sound/oss/oss-parameters.txt
> 
>+  pae [X86-32]
>+  Forcefully enable Physical Address Extension (PAE).
>+   

Re: Re: [PATCH] x86: set Pentium M as PAE capable

[Chris Bainbridge]

On Mon, Mar 03, 2014 at 08:29:39PM +0100, Borislav Petkov wrote:
> On Mon, Mar 03, 2014 at 03:04:35PM +0700, Chris Bainbridge wrote:
> > On 3 March 2014 02:05, Roland Kletzing  wrote:
> > > i would recommend adding the newly introduced param to
> > > Documentation/kernel-
> > > parameters.txt , though.
> > 
> > Done.
> > 
> > Signed-off-by: Chris Bainbridge 
> > ---
> > diff --git a/Documentation/kernel-parameters.txt 
> > b/Documentation/kernel-parameters.txt
> > index b9e9bd8..388b5e9 100644
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -962,6 +962,13 @@ bytes respectively. Such letter suffixes can also be 
> > entirely omitted.
> > parameter will force ia64_sal_cache_flush to call
> > ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
> >  
> > +   forcepae [X86-32]
> > +   Forcefully enable Physical Address Extension (PAE).
> > +   Many Pentium M systems disable PAE but may have a
> > +   functionally usable PAE implementation.
> > +   Note: This parameter is unsupported, may cause unknown
> 
> What does "unsupported" mean here exactly?

It was supposed to have the dual meaning that neither the kernel
developers or Intel are going to help you if it doesn't work. But
perhaps it is unnecessary - being tainted implies that the kernel
developers won't help, and Intel certainly won't be interested.

> 
> This function is called check_cpuflags() now. You probably want to redo
> your patch against tip/master, i.e.:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git#master
> 

Done, new patch is against tip.

> > +   }
> > +   else {
> > +   puts("ERROR: PAE is disabled on this Pentium M\n"
> > +   "(PAE can potentially be enabled with "
> > +   "kernel parameter\n"
> > +   "\"forcepae\" - this is unsupported, may "
> > +   "cause unknown\n"
> > +   "problems, and will taint the kernel)\n");
> 
> This string could definitely violate the 80 cols rule so that it is much
> more readable:
> 
>   }
>   else
>   puts("WARNING: PAE disabled. Use \"forcepae\" to enable 
> at your own risk!\n");
> 
> I've shortened it to the most relevant info only. No need to say we're
> tainting the kernel because LOCKDEP_NOW_UNRELIABLE will cause that
> anyway below.

Ok I changed it to: "WARNING: PAE disabled. Use parameter 'pae' to
enable at your own risk!\n""

> > diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> > index bbe1b8b..271686d 100644
> > --- a/arch/x86/kernel/cpu/intel.c
> > +++ b/arch/x86/kernel/cpu/intel.c
> > @@ -196,6 +196,14 @@ static void intel_smp_check(struct cpuinfo_x86 *c)
> > }
> >  }
> >  
> > +static int forcepae;
> > +static int __init forcepae_setup(char *__unused)
> > +{
> > +   forcepae = 1;
> > +   return 1;
> > +}
> > +__setup("forcepae", forcepae_setup);
> 
> Yeah, why not simply call it "pae"? It is smaller and the letter
> combination is not used yet and it means the same.

I don't see any reason not to just use "pae" "forcepae" is perhaps a bit
more descriptive but the other text in the patch clearly describes the
parameter so it doesn't really matter.

> >  static void intel_workarounds(struct cpuinfo_x86 *c)
> >  {
> > unsigned long lo, hi;
> > @@ -226,6 +234,17 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
> > clear_cpu_cap(c, X86_FEATURE_SEP);
> >  
> > /*
> > +* PAE CPUID issue: many Pentium M report no PAE but may have a
> > +* functionally usable PAE implementation.
> > +* Forcefully enable PAE if kernel parameter "forcepae" is present.
> > +*/
> > +   if (forcepae) {
> > +   printk(KERN_WARNING "PAE forced!\n");
> > +   set_cpu_cap(c, X86_FEATURE_PAE);
> > +   add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_NOW_UNRELIABLE);
> 
> Right, this implies Dave's patch is preceding yours. I guess hpa can
> fish it out from the thread when applying.

I will include Dave's patch, it is trivial. 

New patch with all above changes follows.

Signed-off-by: Chris Bainbridge 
---

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 580a60c..7d57a5a 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2307,6 +2307,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
OSS [HW,OSS]
See Documentation/sound/oss/oss-parameters.txt
 
+   pae [X86-32]
+   Forcefully enable Physical Address Extension (PAE).
+   Many Pentium M systems disable PAE but may have a
+   functionally usable PAE implementation.
+   Warning: use of this 

Re: [PATCH 3/7] staging: cxt1e1: Fix line length over 80 characters in linux.c

[DaeSeok Youn]

Thanks for review.

How about fix it as your comment within another patch?

I sent many smaller patches for fixing coding style and other things.
And I think this patch has just fixed about long line length, so I
want to let it leave this change and
I will send a patch after fixing as your comment.

just my opinion.

Regards.
Daeseok Youn.

2014-03-04 12:24 GMT+09:00 Joe Perches :
> On Tue, 2014-03-04 at 11:08 +0900, Daeseok Youn wrote:
>> clean up checkpatch.pl warnings:
>>  WARNING: Line length over 80 characters
>
> Please run your patches through checkpatch.
>
>> diff --git a/drivers/staging/cxt1e1/linux.c b/drivers/staging/cxt1e1/linux.c
>
>> @@ -431,13 +432,15 @@ create_chan(struct net_device *ndev, ci_t *ci,
>>   priv = OS_kmalloc(sizeof(struct c4_priv));
>>   if (!priv)
>>   {
>> - pr_warning("%s: no memory for net_device !\n", 
>> ci->devname);
>> + pr_warning("%s: no memory for net_device !\n",
>> +ci->devname);
>
> pr_warn would be nice
>
>> @@ -458,10 +461,12 @@ create_chan(struct net_device *ndev, ci_t *ci,
>>   switch (hi->promfmt)
>>   {
>>   case PROM_FORMAT_TYPE1:
>> - memcpy(dev->dev_addr, (FLD_TYPE1 *) 
>> (hi->mfg_info.pft1.Serial), 6);
>> + memcpy(dev->dev_addr,
>> +(FLD_TYPE1 *) (hi->mfg_info.pft1.Serial), 6);
>
> Likely better to remove the (FLD_TYPE1 *) altogether.
>
>>   break;
>>   case PROM_FORMAT_TYPE2:
>> - memcpy(dev->dev_addr, (FLD_TYPE2 *) 
>> (hi->mfg_info.pft2.Serial), 6);
>> + memcpy(dev->dev_addr,
>> +(FLD_TYPE2 *) (hi->mfg_info.pft2.Serial), 6);
>
> Likely better to remove the (FLD_TYPE2 *) too.
> Maybe consolidate the blocks too.
>
>
>> @@ -1053,13 +1065,15 @@ c4_add_dev(hdw_info_t *hi, int brdno, unsigned long 
>> f0, unsigned long f1,
>>   switch (hi->promfmt)
>>   {
>>   case PROM_FORMAT_TYPE1:
>> - memcpy(ndev->dev_addr, (FLD_TYPE1 *) 
>> (hi->mfg_info.pft1.Serial), 6);
>> + memcpy(ndev->dev_addr,
>> +(FLD_TYPE1 *) (hi->mfg_info.pft1.Serial), 6);
>
> unnecessary casts?
>
>>   /* unaligned data acquisition */
>>   memcpy(, (FLD_TYPE1 *) (hi->mfg_info.pft1.Id), 4);
>
> here too.
>
>>   ci->brd_id = cpu_to_be32(tmp);
>>   break;
>>   case PROM_FORMAT_TYPE2:
>> - memcpy(ndev->dev_addr, (FLD_TYPE2 *) 
>> (hi->mfg_info.pft2.Serial), 6);
>> + memcpy(ndev->dev_addr,
>> +(FLD_TYPE2 *) (hi->mfg_info.pft2.Serial), 6);
>>   /* unaligned data acquisition */
>>   memcpy(, (FLD_TYPE2 *) (hi->mfg_info.pft2.Id), 4);
>
> etc.
>
>
--
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 1/3] ASoC: codec: Simplify ASoC probe code.

[Mark Brown]

On Mon, Mar 03, 2014 at 07:24:36AM +, li.xi...@freescale.com wrote:

> > >   /* Default to using ALC auto offset calibration mode. */
> > >   snd_soc_update_bits(codec, DA7213_ALC_CTRL1,
> > >   DA7213_ALC_CALIB_MODE_MAN, 0);

> > This one will fail.

> Sorry, I'm not very understand why will this fail ? Before the ASoC probe,
> the ASoC core will set the I/O. 
> :)

OK, that's now been refactored.


signature.asc
Description: Digital signature

Re: [PATCH] drivercore: deferral race condition fix

[Mark Brown]

On Mon, Mar 03, 2014 at 10:26:59AM +0200, Peter Ujfalusi wrote:

> I think it is correct to detect this situation without the need to have non
> related drivers to be probed.
> The patch is doing this exactly: detects if we had successful parallel driver
> probe(s) while another driver was probing which ends up requesting to be
> deferred. We only try the deferred list again if this condition has been
> detected, we do not loop on the deferred list, we do not try the list again if
> there were no other drivers loaded since nothing happened which could satisfy
> the driver asking to be deferred.

It's certainly the simplest approach I can think of - anything else
would seem to involve looking to see if we're running deferred probes
and trying to add things to the list while that's going on which seems
like it might be hairy.


signature.asc
Description: Digital signature

Re: [PATCH] ASoC: cache: Do the codec->reg_cache zero pionter check

[Mark Brown]

On Fri, Feb 28, 2014 at 10:48:19AM +0800, Xiubo Li wrote:
> For the snd_soc_cache_init(), the reg_size maybe zero and then the value
> of codec->reg_cache, which is alloced via kzalloc, maybe equal to
> ZERO_SIZE_PTR. If the reg parameter of snd_soc_cache_write() is large enough,
> the cache[idx] = val maybe cause the kernel crash...

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH v3 3/4] ARM: mvebu: move DT Dove to MVEBU

[Jason Cooper]

On Sat, Mar 01, 2014 at 09:39:38AM +0100, Sebastian Hesselbarth wrote:
> With all the DT support preparation done, we are able to move Dove
> to MVEBU easily. Legacy non-DT mach-dove is left untouched to rot
> for a while before removal.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Changelog:
> v1->v2:
> - just rename CONFIG_ARCH_DOVE to CONFIG_MACH_DOVE in dts/Makefile
>   (Suggested by Jason Cooper)
> v2->v3:
> - dropped drivers/phy/Kconfig change, which is now an individual
>   patch sent to Kishon.
> 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> Cc: Russell King 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: Kishon Vijay Abraham I 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/boot/dts/Makefile|  2 +-
>  arch/arm/mach-dove/Kconfig| 12 
>  arch/arm/mach-dove/Makefile   |  1 -
>  arch/arm/mach-dove/board-dt.c | 43 
> ---
>  arch/arm/mach-mvebu/Kconfig   | 12 
>  arch/arm/mach-mvebu/Makefile  |  1 +
>  arch/arm/mach-mvebu/dove.c| 39 +++
>  7 files changed, 53 insertions(+), 57 deletions(-)
>  delete mode 100644 arch/arm/mach-dove/board-dt.c
>  create mode 100644 arch/arm/mach-mvebu/dove.c

We'll see how it goes!

Applied to mvebu/soc

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] ARM: add Marvell Dove and some drivers to multi_v7 defconfig

[Jason Cooper]

Arnd, Olof, Kevin,

On Thu, Feb 27, 2014 at 10:28:05PM +0100, Sebastian Hesselbarth wrote:
> With Marvell Dove now being part of the multi_v7 family, add some Dove
> specific drivers to multi_v7 defconfig.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Russell King 
> Cc: Olof Johansson 
> Cc: Kevin Hilman 
> Cc: Arnd Bergmann 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/configs/multi_v7_defconfig | 4 
>  1 file changed, 4 insertions(+)

I'm taking the other part of this series in, so:

Acked-by: Jason Cooper 

thx,

Jason.
--
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: comedi: add timeouts to while loops in s626.c

[Chase Southwood]

>On Monday, March 3, 2014 8:13 AM, Ian Abbott  wrote:

>>On 2014-03-02 04:13, Chase Southwood wrote:
>>>On Friday, February 28, 2014 11:49 PM, Chase Southwood 
>>> wrote:
 On Friday, February 28, 2014 11:26 AM, Ian Abbott  
 wrote:
> On 2014-02-28 07:35, Chase Southwood wrote:
>>
>> [snip]
>>
 In the case of s626_send_dac(), it doesn't seem to be used in any
 critical sections, so it could make use of Hartley's comedi_timeout().

 Some of the timeout errors could be propagated, especially for
 s626_send_dac() which is only reachable from very few paths.
>>>
>>>
>>> Awesome, I'll swap all of my timeouts out for comedi_timeout() in 
>>> s626_send_dac().
>>
>> Actually, after taking another look at this, I don't think that using 
>> comedi_timeout()
>> here is going to work, actually.
>> The context from which s626_send_dac() is called allows sleep all right, but 
>> readl() isn't
>> a comedi function and therefore it doesn't behave (in parameters or return 
>> values) as
>> the callback function parameter to comedi_timeout() requires.  So unless I'm 
>> missing
>> something particularly large here, I believe we'll have to do the timeouts 
>> here manually
>> as well.  Am I correct here, and if so, would you like the iteration based 
>> timeouts here
>> as well, or a sleep-based timeout similar to that employed by 
>> comedi_timeout()?
>
>The readl() could be done in a small callback function.  As the 
>different while loops are checking for different results from readl(), 
>It would need a different callback functions for each case, or some 
>creative use of the callback function's 'context' parameter.
>

Oh, of course.  I'll see if there's a reasonably clear way that I can use the
context parameter to use a single callback, if not I'll just define a few of 
them.

I'll send a patch with the new callback(s), and the timeouts in s626_send_dac()
switched to comedi_timeout(), and I'll add the timeouts that were left out last
time, and then another patch or patchset propagating everything upwards.

Thanks,
Chase

>
>-- 
>-=( Ian Abbott @ MEV Ltd.    E-mail:         )=-
>-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587         )=-
>--

--
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 5/5] phy: mvebu-sata: prepare new Dove DT Kconfig variable

[Jason Cooper]

On Sat, Mar 01, 2014 at 09:33:21AM +0100, Sebastian Hesselbarth wrote:
> DT-enabled Dove will move over from ARCH_DOVE in mach-dove to MACH_DOVE in
> mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
> DT-only MACH_DOVE Kconfig.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Kishon,
> 
> Mark Brown requested to take the corresponding ASoC patch through
> his tree. Therefore, I have split the former patch into individual subsystem
> patches. This patch also received an update, to not break bisectability
> we add DT-enabled MACH_DOVE and maintain ARCH_DOVE, which is non-DT only
> after conversion. ARCH_DOVE will be removed, when legacy mach-dove will
> be removed.
> 
> Cc: Kishon Vijay Abraham I 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/phy/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Kishon,

fwiw:

Acked-by: Jason Cooper 

thx,

Jason.
--
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] mmc: dove: prepare new Dove DT Kconfig variable

[Jason Cooper]

On Sat, Mar 01, 2014 at 09:33:20AM +0100, Sebastian Hesselbarth wrote:
> DT-enabled Dove will move over from ARCH_DOVE in mach-dove to MACH_DOVE in
> mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
> DT-only MACH_DOVE Kconfig.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Chris,
> 
> Mark Brown requested to take the corresponding ASoC patch through
> his tree. Therefore, I have split the former patch into individual subsystem
> patches.
> 
> Cc: Chris Ball 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/mmc/host/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Jason Cooper 

thx,

Jason.
--
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] ASoC: kirkwood: prepare new Dove DT Kconfig variable

[Mark Brown]

On Sat, Mar 01, 2014 at 09:33:17AM +0100, Sebastian Hesselbarth wrote:
> DT-enabled Dove will move over from ARCH_DOVE in mach-dove to MACH_DOVE in
> mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
> DT-only MACH_DOVE Kconfig.

This doesn't apply against current ASoC, please check and resend.


signature.asc
Description: Digital signature

Re: [PATCH v2 3/5] thermal: dove: prepare new Dove DT Kconfig variable

[Jason Cooper]

On Sat, Mar 01, 2014 at 09:33:19AM +0100, Sebastian Hesselbarth wrote:
> DT-enabled Dove will move over from ARCH_DOVE in mach-dove to MACH_DOVE in
> mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
> DT-only MACH_DOVE Kconfig.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Rui, Eduardo,
> 
> Mark Brown requested to take the corresponding ASoC patch through
> his tree. Therefore, I have split the former patch into individual subsystem
> patches.  
> 
> Cc: Zhang Rui 
> Cc: Eduardo Valentin 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: linux...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/thermal/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Jason Cooper 

thx,

Jason.
--
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] watchdog: orion: prepare new Dove DT Kconfig variable

[Jason Cooper]

On Sat, Mar 01, 2014 at 09:33:18AM +0100, Sebastian Hesselbarth wrote:
> DT-enabled Dove will move over from ARCH_DOVE in mach-dove to MACH_DOVE in
> mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
> DT-only MACH_DOVE Kconfig.
> 
> Signed-off-by: Sebastian Hesselbarth 
> Acked-by: Wim Van Sebroeck 
> ---
> Wim, Mark Brown requested to take the corresponding ASoC patch through
> his tree. Therefore, I have split the former patch into individual subsystem
> patches.
> 
> Cc: Wim Van Sebroeck 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: linux-watch...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/watchdog/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Jason Cooper 

thx,

Jason.
--
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] ASoC: kirkwood: prepare new Dove DT Kconfig variable

[Jason Cooper]

On Sat, Mar 01, 2014 at 09:33:17AM +0100, Sebastian Hesselbarth wrote:
> DT-enabled Dove will move over from ARCH_DOVE in mach-dove to MACH_DOVE in
> mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
> DT-only MACH_DOVE Kconfig.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Mark, as requested, this is the ASoC only patch touching Kconfig for
> Marvell Dove to mach-mvebu conversion.
> 
> Cc: Mark Brown 
> Cc: Liam Girdwood 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: alsa-de...@alsa-project.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  sound/soc/kirkwood/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Jason Cooper 

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] ARM: dove: add system controller node

[Jason Cooper]

On Thu, Feb 27, 2014 at 10:28:02PM +0100, Sebastian Hesselbarth wrote:
> This adds a DT node for the system-controller found on Marvell Dove
> SoCs.
> 
> Signed-off-by: Sebastian Hesselbarth 
> ---
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> Cc: Russell King 
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  arch/arm/boot/dts/dove.dtsi | 5 +
>  1 file changed, 5 insertions(+)

Applied to mvebu/dt

thx,

Jason.
--
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] asoc: soc-core: fix coccinelle warnings

[Mark Brown]

On Mon, Mar 03, 2014 at 07:08:23PM +0800, Nenghua Cao wrote:
> From: Nenghua Cao 
> 
> sound/soc/soc-core.c:2708:6-13: WARNING: Assignment of
> bool to 0/1
> sound/soc/soc-core.c:2726:3-10: WARNING: Assignment of
> bool to 0/1

Applied, thanks.  Please use subject lines consistnt with the style for
the subsystem, CC the mailing list for the subsystem and send the patch
to the maintainers in MAINTAINERS (you've used Liam's work address but
he lists his kernel.org address for upstream).


signature.asc
Description: Digital signature

Re: SAA7134 warning during resume from S3: regression 3.8.13 -> 3.9.0

[valerio.va...@inwind.it]

>Messaggio originale
>Da: valerio.va...@inwind.it
>Data: 14/02/2014 16.29

>The full report is on bugzilla:
>https://bugzilla.kernel.org/show_bug.cgi?id=69581

>[1.] One line summary of the problem:
>
>Kernel gives a oops warning during resume
>from S3 sleep.
>
>[2.] Full description of the problem/report:
>
>OS is Debian Lenny, with vanilla kernel. It happens the same after upgrade to
>Squeeze.
>I've tried with kernels over kernels to find the point and I've found:
>the latest working kernel is 3.8.13, the first failing is 3.9.0
>
>I suspend the machine with s2ram and it goes off.
>During the resume it writes that warning, then it seem to work normally,
>except for serial redirection of console.



>[ cut here ]
>WARNING: CPU: 0 PID: 7928 at kernel/kmod.c:148 __request_module+0x34/0x1ae()
>Modules linked in: vmnet(O) vsock(O) vmci(O) vmmon(O) lp fbcon font bitblit
>softcursor i915 drm_kms_helper fb fbdev cfbcopyarea video backlight cfbimgblt
>cfbfillrect bnep nfsd lockd sunrpc fuse saa7134_alsa snd_seq_dummy 
snd_seq_oss
>snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_seq_device cifs 
rfcomm
>bluetooth rfkill it87 hwmon_vid isofs zlib_inflate nls_utf8 nls_iso8859_1
>nls_cp850 nls_cp437 nls_ascii cpuid vfat ntfs msdos fat udf nls_iso8859_15
>softdog loop tda1004x saa7134_dvb videobuf_dvb dvb_core tda827x mousedev
>tda8290 tuner snd_hda_codec_realtek snd_hda_intel snd_hda_codec saa7134
>v4l2_common usb_storage videodev r8169 snd_hwdep parport_pc snd_pcm_oss
>snd_mixer_oss videobuf_dma_sg mii ehci_pci parport videobuf_core snd_pcm
>uhci_hcd firewire_ohci firewire_core evdev crc_itu_t ehci_hcd psmouse 
rtc_cmos
>tveeprom pcspkr intel_agp intel_gtt snd_timer snd_page_alloc
>CPU: 0 PID: 7928 Comm: kworker/u8:12 Tainted: G   O 3.13.2 #1
>Hardware name: Gigabyte Technology Co., Ltd. G33M-S2/G33M-S2, BIOS F7f
>04/02/2008
>Workqueue: events_unbound async_run_entry_fn
>  c13534fe c103d476 c102e079 0009 f13ede00 f534f1a4
>f80630d0 f534f024 c102e099 0009  c103d476  01000282
>c1036a29 0282 f13edda4 c155c680 c155c680 c1036a5c 003a8aba c1353657
>Call Trace:
>[] ? dump_stack+0x3e/0x50
>[] ? __request_module+0x34/0x1ae
>[] ? warn_slowpath_common+0x66/0x7a
>[] ? warn_slowpath_null+0xc/0xf
>[] ? __request_module+0x34/0x1ae
>[] ? try_to_del_timer_sync+0x3a/0x41
>[] ? del_timer_sync+0x2c/0x36
>[] ? schedule_timeout+0x147/0x15d
>[] ? del_timer+0x40/0x40
>[] ? v4l2_i2c_new_subdev_board+0x23/0xa7 [v4l2_common]
>[] ? v4l2_i2c_new_subdev+0x49/0x51 [v4l2_common]
>[] ? saa7134_board_init2+0x869/0xb58 [saa7134]
>[] ? try_to_del_timer_sync+0x3a/0x41
>[] ? del_timer_sync+0x2c/0x36
>[] ? schedule_timeout+0x147/0x15d
>[] ? do_exit+0x51a/0x7ce
>[] ? saa7134_resume+0xbf/0x150 [saa7134]
>[] ? pci_legacy_resume+0x23/0x2c
>[] ? pci_pm_thaw+0x62/0x62
>[] ? dpm_run_callback+0x25/0x60
>[] ? device_resume+0x10f/0x12c
>[] ? async_resume+0x13/0x33
>[] ? async_run_entry_fn+0x52/0xf3
>[] ? process_one_work+0x200/0x331
>[] ? worker_thread+0x1ab/0x2e1
>[] ? process_one_work+0x331/0x331
>[] ? kthread+0xa1/0xaa
>[] ? ret_from_kernel_thread+0x1b/0x28
>[] ? kthread_freezable_should_stop+0x4d/0x4d
>---[ end trace d02ad8471166632e ]---

--
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] mm/slab.c: cleanup outdated comments and unify variables naming

[Zhan Jianyu]

On Sun, Mar 2, 2014 at 8:59 AM, Christoph Lameter  wrote:
> On Thu, 27 Feb 2014, Jianyu Zhan wrote:
>
>> As time goes, the code changes a lot, and this leads to that
>> some old-days comments scatter around , which instead of faciliating
>> understanding, but make more confusion. So this patch cleans up them.
>
> Acked-by: Christoph Lameter 


Thanks, Christoph Lameter.




--

Regards,
Zhan Jianyu
--
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: [alsa-devel] change kmalloc into vmalloc for large memory allocations

[Mark Brown]

On Mon, Mar 03, 2014 at 11:33:24PM +0800, Wang, Yalin wrote:
> Hi Takashi,
> 
> I see,
> 
> I just want to save low memory for kmalloc use,
> So I want to filter out large memory allocations
> To use vmalloc instead ,
> 
> It will be preferable, if there is a better solution :)
> 
> Thank you for your clarification.

Don't top post.  

Without having seen the earlier mails in the thread I'm not 100% sure on
the specifics here but wouldn't a more generic solution be to deal with
this in the memory management code?  

As far as I can tell the concern is that the runtime structures are
taking up too much memory when allocated using kzallloc?  We're also
doing lots of small allocations for things like DAPM which will
presumably also be burning this memory and will I expect for most
systems end up being more than that consumed by the runtime structures.


signature.asc
Description: Digital signature

[PATCH V2 2/3] cpufreq: Initialize policy before making it available for others to use

[Viresh Kumar]

Policy must be fully initialized before it is being made available for use by
others. Otherwise cpufreq_cpu_get() would be able to grab a half initialized
policy structure that might not have affected_cpus (for example) filled. And so
anybody accessing those fields will get the wrong value and hence the results
would be unpredictable.

So, in order to fix this lets do all the necessary initialization before we make
policy structure available via cpufreq_cpu_get(). With this we can guarantee
that any code accessing fields of policy would be stable enough, as policy would
be completely initialized by now.

Signed-off-by: Viresh Kumar 
---
V1->V2:
- Improved commit logs

 drivers/cpufreq/cpufreq.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index fff2968..3c6f9a5 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1114,6 +1114,20 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
goto err_set_policy_cpu;
}
 
+   /* related cpus should atleast have policy->cpus */
+   cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
+
+   /*
+* affected cpus must always be the one, which are online. We aren't
+* managing offline cpus here.
+*/
+   cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
+
+   if (!frozen) {
+   policy->user_policy.min = policy->min;
+   policy->user_policy.max = policy->max;
+   }
+
write_lock_irqsave(_driver_lock, flags);
for_each_cpu(j, policy->cpus)
per_cpu(cpufreq_cpu_data, j) = policy;
@@ -1167,20 +1181,6 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
}
}
 
-   /* related cpus should atleast have policy->cpus */
-   cpumask_or(policy->related_cpus, policy->related_cpus, policy->cpus);
-
-   /*
-* affected cpus must always be the one, which are online. We aren't
-* managing offline cpus here.
-*/
-   cpumask_and(policy->cpus, policy->cpus, cpu_online_mask);
-
-   if (!frozen) {
-   policy->user_policy.min = policy->min;
-   policy->user_policy.max = policy->max;
-   }
-
blocking_notifier_call_chain(_policy_notifier_list,
 CPUFREQ_START, policy);
 
-- 
1.7.12.rc2.18.g61b472e

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 3/3] cpufreq: initialize governor for a new policy under policy->rwsem

[Viresh Kumar]

policy->rwsem is used to lock access to all parts of code modifying struct
cpufreq_policy but wasn't used on a new policy created from __cpufreq_add_dev().

Because of which if we call cpufreq_update_policy() repeatedly on one CPU and do
offline/online of another CPU then we might see these crashes:

Unable to handle kernel NULL pointer dereference at virtual address 0020
pgd = c0003000
[0020] *pgd=804003, *pmd=
Internal error: Oops: 206 [#1] PREEMPT SMP ARM

PC is at __cpufreq_governor+0x10/0x1ac
LR is at cpufreq_update_policy+0x114/0x150

---[ end trace f23a8defea6cd706 ]---
Kernel panic - not syncing: Fatal exception
CPU0: stopping
CPU: 0 PID: 7136 Comm: mpdecision Tainted: G  D W
3.10.0-gd727407-00074-g979ede8 #396

[] (notifier_call_chain+0x40/0x68) from [] 
(__blocking_notifier_call_chain+0x40/0x58)
[] (__blocking_notifier_call_chain+0x40/0x58) from [] 
(blocking_notifier_call_chain+0x14/0x1c)
[] (blocking_notifier_call_chain+0x14/0x1c) from [] 
(cpufreq_set_policy+0xd4/0x2b8)
[] (cpufreq_set_policy+0xd4/0x2b8) from [] 
(cpufreq_init_policy+0x30/0x98)
[] (cpufreq_init_policy+0x30/0x98) from [] 
(__cpufreq_add_dev.isra.17+0x4dc/0x7a4)
[] (__cpufreq_add_dev.isra.17+0x4dc/0x7a4) from [] 
(cpufreq_cpu_callback+0x58/0x84)
[] (cpufreq_cpu_callback+0x58/0x84) from [] 
(notifier_call_chain+0x40/0x68)
[] (notifier_call_chain+0x40/0x68) from [] 
(__cpu_notify+0x28/0x44)
[] (__cpu_notify+0x28/0x44) from [] (_cpu_up+0xf4/0x1dc)
[] (_cpu_up+0xf4/0x1dc) from [] (cpu_up+0x5c/0x78)
[] (cpu_up+0x5c/0x78) from [] (store_online+0x44/0x74)
[] (store_online+0x44/0x74) from [] 
(sysfs_write_file+0x108/0x14c)
[] (sysfs_write_file+0x108/0x14c) from [] 
(vfs_write+0xd0/0x180)
[] (vfs_write+0xd0/0x180) from [] (SyS_write+0x38/0x68)
[] (SyS_write+0x38/0x68) from [] (ret_fast_syscall+0x0/0x30)

Fix these by taking locks at appropriate places in __cpufreq_add_dev() as well.

Reported-by: Saravana Kannan 
Suggested-by: Srivatsa S. Bhat 
Signed-off-by: Viresh Kumar 
---
V1->V2: No change

 drivers/cpufreq/cpufreq.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 3c6f9a5..e2a1e67 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1128,6 +1128,7 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
policy->user_policy.max = policy->max;
}
 
+   down_write(>rwsem);
write_lock_irqsave(_driver_lock, flags);
for_each_cpu(j, policy->cpus)
per_cpu(cpufreq_cpu_data, j) = policy;
@@ -1202,6 +1203,7 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
policy->user_policy.policy = policy->policy;
policy->user_policy.governor = policy->governor;
}
+   up_write(>rwsem);
 
kobject_uevent(>kobj, KOBJ_ADD);
up_read(_rwsem);
-- 
1.7.12.rc2.18.g61b472e

--
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/3] cpufreq: move call to __find_governor() to cpufreq_init_policy()

[Viresh Kumar]

On 1 March 2014 06:39, Rafael J. Wysocki  wrote:
> And while I'm at it, can we *please* avoid adding new #ifdef blocks into
> function bodies?
>
> Please introduce a wrapper around __find_governor() returning NULL for
> CONFIG_HOTPLUG_CPU unset.

I have tried fixing all the suggestions you gave for this series. Please have a
look at V2 set and let me know if I am still missing anything.
--
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 1/3] cpufreq: move call to __find_governor() to cpufreq_init_policy()

[Viresh Kumar]

We call __find_governor() during addition of first CPU of every policy from
__cpufreq_add_dev() to find the last governor used for this CPU before it was
hotplugged-out.

After that we call cpufreq_parse_governor() in cpufreq_init_policy() either with
this governor or default governor. And right after that policy->governor is set
to NULL.

There is no functional problem here with this code, but it is just that some of
the code required in cpufreq_init_policy() is being called by its caller, i.e.
__cpufreq_add_dev(). So, it would make more sense to get all these together at a
single place to make code more readable.

So, instead of doing this move the relevant parts to cpufreq_init_policy()
policy only and initialize policy->governor to NULL at the beginning.

In order to clean the code a bit more, some of the #ifdefs for
CONFIG_HOTPLUG_CPU are also removed which used to maintain the last governor
used for any CPU. Keeping that code wouldn't harm us much but would improve the
cleanliness of code.

Signed-off-by: Viresh Kumar 
---
V1->V2:
- Improved commit logs
- Removed unrelated whitespace changes
- Removed some #ifdef CONFIG_HOTPLUG_CPU to clean code a bit.

 drivers/cpufreq/cpufreq.c | 38 ++
 1 file changed, 14 insertions(+), 24 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 56b7b1b..fff2968 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -42,10 +42,8 @@ static DEFINE_RWLOCK(cpufreq_driver_lock);
 DEFINE_MUTEX(cpufreq_governor_lock);
 static LIST_HEAD(cpufreq_policy_list);
 
-#ifdef CONFIG_HOTPLUG_CPU
 /* This one keeps track of the previously set governor of a removed CPU */
 static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor);
-#endif
 
 static inline bool has_target(void)
 {
@@ -879,18 +877,25 @@ err_out_kobj_put:
 
 static void cpufreq_init_policy(struct cpufreq_policy *policy)
 {
+   struct cpufreq_governor *gov = NULL;
struct cpufreq_policy new_policy;
int ret = 0;
 
memcpy(_policy, policy, sizeof(*policy));
 
+   /* Update governor of new_policy to the governor used before hotplug */
+   gov = __find_governor(per_cpu(cpufreq_cpu_governor, policy->cpu));
+   if (gov)
+   pr_debug("Restoring governor %s for cpu %d\n",
+   policy->governor->name, policy->cpu);
+   else
+   gov = CPUFREQ_DEFAULT_GOVERNOR;
+
+   new_policy.governor = gov;
+
/* Use the default policy if its valid. */
if (cpufreq_driver->setpolicy)
-   cpufreq_parse_governor(policy->governor->name,
-   _policy.policy, NULL);
-
-   /* assure that the starting sequence is run in cpufreq_set_policy */
-   policy->governor = NULL;
+   cpufreq_parse_governor(gov->name, _policy.policy, NULL);
 
/* set default policy */
ret = cpufreq_set_policy(policy, _policy);
@@ -949,6 +954,8 @@ static struct cpufreq_policy 
*cpufreq_policy_restore(unsigned int cpu)
 
read_unlock_irqrestore(_driver_lock, flags);
 
+   policy->governor = NULL;
+
return policy;
 }
 
@@ -1036,7 +1043,6 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
unsigned long flags;
 #ifdef CONFIG_HOTPLUG_CPU
struct cpufreq_policy *tpolicy;
-   struct cpufreq_governor *gov;
 #endif
 
if (cpu_is_offline(cpu))
@@ -1094,7 +1100,6 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
else
policy->cpu = cpu;
 
-   policy->governor = CPUFREQ_DEFAULT_GOVERNOR;
cpumask_copy(policy->cpus, cpumask_of(cpu));
 
init_completion(>kobj_unregister);
@@ -1179,15 +1184,6 @@ static int __cpufreq_add_dev(struct device *dev, struct 
subsys_interface *sif,
blocking_notifier_call_chain(_policy_notifier_list,
 CPUFREQ_START, policy);
 
-#ifdef CONFIG_HOTPLUG_CPU
-   gov = __find_governor(per_cpu(cpufreq_cpu_governor, cpu));
-   if (gov) {
-   policy->governor = gov;
-   pr_debug("Restoring governor %s for cpu %d\n",
-  policy->governor->name, cpu);
-   }
-#endif
-
if (!frozen) {
ret = cpufreq_add_dev_interface(policy, dev);
if (ret)
@@ -1312,11 +1308,9 @@ static int __cpufreq_remove_dev_prepare(struct device 
*dev,
}
}
 
-#ifdef CONFIG_HOTPLUG_CPU
if (!cpufreq_driver->setpolicy)
strncpy(per_cpu(cpufreq_cpu_governor, cpu),
policy->governor->name, CPUFREQ_NAME_LEN);
-#endif
 
down_read(>rwsem);
cpus = cpumask_weight(policy->cpus);
@@ -1955,9 +1949,7 @@ EXPORT_SYMBOL_GPL(cpufreq_register_governor);
 
 void cpufreq_unregister_governor(struct cpufreq_governor *governor)
 {
-#ifdef CONFIG_HOTPLUG_CPU
int cpu;
-#endif
 

linux-next: build failure after merge of the omap_dss2 tree

[Stephen Rothwell]

Hi Tomi,

After merging the omap_dss2 tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from drivers/staging/xgifb/XGIfb.h:3:0,
 from drivers/staging/xgifb/vb_init.c:4:
drivers/staging/xgifb/vgatypes.h:5:38: fatal error: ../../video/sis/vgatypes.h: 
No such file or directory
 #include "../../video/sis/vgatypes.h"
  ^
In file included from drivers/staging/xgifb/XGIfb.h:3:0,
 from drivers/staging/xgifb/vb_setmode.c:2:
drivers/staging/xgifb/vgatypes.h:5:38: fatal error: ../../video/sis/vgatypes.h: 
No such file or directory
 #include "../../video/sis/vgatypes.h"
  ^
In file included from drivers/staging/xgifb/vb_util.c:1:0:
drivers/staging/xgifb/vgatypes.h:5:38: fatal error: ../../video/sis/vgatypes.h: 
No such file or directory
 #include "../../video/sis/vgatypes.h"
  ^
In file included from drivers/staging/xgifb/XGIfb.h:3:0,
 from drivers/staging/xgifb/XGI_main.h:4,
 from drivers/staging/xgifb/XGI_main_26.c:16:
drivers/staging/xgifb/vgatypes.h:5:38: fatal error: ../../video/sis/vgatypes.h: 
No such file or directory
 #include "../../video/sis/vgatypes.h"
  ^

Caused by commit 08667731d1d4 ("video: move fbdev to
drivers/video/fbdev").

I have applied this merge fix patch (you should add it to your tree):

From: Stephen Rothwell 
Date: Tue, 4 Mar 2014 14:28:03 +1100
Subject: [PATCH] video: staging fixup for drivers movement

Signed-off-by: Stephen Rothwell 
---
 drivers/staging/xgifb/vb_def.h| 2 +-
 drivers/staging/xgifb/vb_struct.h | 2 +-
 drivers/staging/xgifb/vgatypes.h  | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/xgifb/vb_def.h b/drivers/staging/xgifb/vb_def.h
index 5c739bebd8a5..949f0e5eed8d 100644
--- a/drivers/staging/xgifb/vb_def.h
+++ b/drivers/staging/xgifb/vb_def.h
@@ -1,6 +1,6 @@
 #ifndef _VB_DEF_
 #define _VB_DEF_
-#include "../../video/sis/initdef.h"
+#include "../../video/fbdev/sis/initdef.h"
 
 #define VB_XGI301C  0x0020 /* for 301C */
 
diff --git a/drivers/staging/xgifb/vb_struct.h 
b/drivers/staging/xgifb/vb_struct.h
index c08ff5b2d6ee..0d27594554ca 100644
--- a/drivers/staging/xgifb/vb_struct.h
+++ b/drivers/staging/xgifb/vb_struct.h
@@ -1,6 +1,6 @@
 #ifndef _VB_STRUCT_
 #define _VB_STRUCT_
-#include "../../video/sis/vstruct.h"
+#include "../../video/fbdev/sis/vstruct.h"
 
 struct XGI_LVDSCRT1HDataStruct {
unsigned char Reg[8];
diff --git a/drivers/staging/xgifb/vgatypes.h b/drivers/staging/xgifb/vgatypes.h
index ddf7776c295b..264351441f99 100644
--- a/drivers/staging/xgifb/vgatypes.h
+++ b/drivers/staging/xgifb/vgatypes.h
@@ -2,8 +2,8 @@
 #define _VGATYPES_
 
 #include   /* for struct fb_var_screeninfo for sis.h */
-#include "../../video/sis/vgatypes.h"
-#include "../../video/sis/sis.h"   /* for LCD_TYPE */
+#include "../../video/fbdev/sis/vgatypes.h"
+#include "../../video/fbdev/sis/sis.h" /* for LCD_TYPE */
 
 #ifndef XGI_VB_CHIP_TYPE
 enum XGI_VB_CHIP_TYPE {
-- 
1.9.0

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpbXhp8WfgLT.pgp
Description: PGP signature

Re: [PATCH v4] mm: per-thread vma caching

[Linus Torvalds]

On Mon, Mar 3, 2014 at 7:13 PM, Davidlohr Bueso  wrote:
>
> Yes, I shortly realized that was silly... but I can say for sure it can
> happen and a quick qemu run confirms it. So I see your point as to
> asking why we need it, so now I'm looking for an explanation in the
> code.

We definitely *do* have users.

One example would be ptrace -> access_process_vm -> __access_remote_vm
-> get_user_pages() -> find_extend_vma() -> find_vma_prev -> find_vma.

Linus
--
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/7] staging: cxt1e1: Fix line length over 80 characters in linux.c

[Joe Perches]

On Tue, 2014-03-04 at 11:08 +0900, Daeseok Youn wrote:
> clean up checkpatch.pl warnings:
>  WARNING: Line length over 80 characters

Please run your patches through checkpatch.

> diff --git a/drivers/staging/cxt1e1/linux.c b/drivers/staging/cxt1e1/linux.c

> @@ -431,13 +432,15 @@ create_chan(struct net_device *ndev, ci_t *ci,
>   priv = OS_kmalloc(sizeof(struct c4_priv));
>   if (!priv)
>   {
> - pr_warning("%s: no memory for net_device !\n", 
> ci->devname);
> + pr_warning("%s: no memory for net_device !\n",
> +ci->devname);

pr_warn would be nice

> @@ -458,10 +461,12 @@ create_chan(struct net_device *ndev, ci_t *ci,
>   switch (hi->promfmt)
>   {
>   case PROM_FORMAT_TYPE1:
> - memcpy(dev->dev_addr, (FLD_TYPE1 *) 
> (hi->mfg_info.pft1.Serial), 6);
> + memcpy(dev->dev_addr,
> +(FLD_TYPE1 *) (hi->mfg_info.pft1.Serial), 6);

Likely better to remove the (FLD_TYPE1 *) altogether.

>   break;
>   case PROM_FORMAT_TYPE2:
> - memcpy(dev->dev_addr, (FLD_TYPE2 *) 
> (hi->mfg_info.pft2.Serial), 6);
> + memcpy(dev->dev_addr,
> +(FLD_TYPE2 *) (hi->mfg_info.pft2.Serial), 6);

Likely better to remove the (FLD_TYPE2 *) too.
Maybe consolidate the blocks too.


> @@ -1053,13 +1065,15 @@ c4_add_dev(hdw_info_t *hi, int brdno, unsigned long 
> f0, unsigned long f1,
>   switch (hi->promfmt)
>   {
>   case PROM_FORMAT_TYPE1:
> - memcpy(ndev->dev_addr, (FLD_TYPE1 *) 
> (hi->mfg_info.pft1.Serial), 6);
> + memcpy(ndev->dev_addr,
> +(FLD_TYPE1 *) (hi->mfg_info.pft1.Serial), 6);

unnecessary casts?

>   /* unaligned data acquisition */
>   memcpy(, (FLD_TYPE1 *) (hi->mfg_info.pft1.Id), 4);

here too.

>   ci->brd_id = cpu_to_be32(tmp);
>   break;
>   case PROM_FORMAT_TYPE2:
> - memcpy(ndev->dev_addr, (FLD_TYPE2 *) 
> (hi->mfg_info.pft2.Serial), 6);
> + memcpy(ndev->dev_addr,
> +(FLD_TYPE2 *) (hi->mfg_info.pft2.Serial), 6);
>   /* unaligned data acquisition */
>   memcpy(, (FLD_TYPE2 *) (hi->mfg_info.pft2.Id), 4);

etc.


--
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] regulator: s2mps11: Fix section mismatch

[Mark Brown]

On Mon, Mar 03, 2014 at 04:53:51PM +0100, Krzysztof Kozlowski wrote:
> Remove __initconst from regulator_desc array because this array is used
> during probe and s2mps11_pmic_probe() is not in __init section. However
> still select the number of supported regulators according to device ID
> so the driver will be ready for adding support for S2MPS14 device.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH 8/8] evm: introduce EVM hmac xattr list

[Mimi Zohar]

On Mon, 2014-03-03 at 19:00 -0800, Casey Schaufler wrote: 
> On 3/3/2014 6:39 PM, Mimi Zohar wrote:
> > On Fri, 2014-02-28 at 16:59 +0200, Dmitry Kasatkin wrote: 
> >> EVM currently uses source hard coded list of xattrs which needs to be
> >> included into the HMAC calculation. This is very unflexible.
> >> Adding new attributes requires modifcation of the source code and
> >> prevents building the kernel which works with previously labeled
> >> filesystems.
> >>
> >> Early versions of Smack used only one xattr security.SMACK64,
> >> which is protected by EVM. Now Smack has a few more attributes and
> >> they are not protected. Adding support to the source code makes it
> >> impossible to use new kernel with previousely labeled filesystems.
> > I think this patch will break any existing filesystems labeled with
> > 'security.smack64'.  Details inline.
> >
> >> This patch replaces hardcoded xattr array with dynamic list which is
> >> initialized from CONFIG_EVM_HMAC_XATTRS variable. It allows to build
> >> kernel with with support of older and newer EVM HMAC formats.
> >>
> >> Possible future extension will be to read xattr list from the kernel
> >> command line or from securityfs entry.
> >>
> >> Signed-off-by: Dmitry Kasatkin 
> >> ---
> >>  security/integrity/evm/Kconfig  | 10 ++
> >>  security/integrity/evm/evm.h|  7 +++-
> >>  security/integrity/evm/evm_crypto.c |  8 ++---
> >>  security/integrity/evm/evm_main.c   | 69 
> >> +++--
> >>  4 files changed, 55 insertions(+), 39 deletions(-)
> >>
> >> diff --git a/security/integrity/evm/Kconfig 
> >> b/security/integrity/evm/Kconfig
> >> index 2be51fa..06237b8 100644
> >> --- a/security/integrity/evm/Kconfig
> >> +++ b/security/integrity/evm/Kconfig
> >> @@ -25,3 +25,13 @@ config EVM_HMAC_ATTRS
> >>  WARNING: changing the HMAC calculation method or adding 
> >>  additional info to the calculation, requires existing EVM
> >>  labeled file systems to be relabeled.
> >> +
> >> +config EVM_HMAC_XATTRS
> >> +  string "HMAC xattrs"
> >> +  default "security.selinux security.SMACK64 security.ima 
> >> security.capability"
> >> +  help
> >> +This options allows to specify list of extended attributes included 
> >> into HMAC
> >> +calculation. It makes it possible easily upgrade to newer kernels.
> >> +
> >> +Default value:
> >> +  security.selinux, security.SMACK64, security.ima, 
> >> security.capability
> >> diff --git a/security/integrity/evm/evm.h b/security/integrity/evm/evm.h
> >> index c8fa0aa..4d1c51e 100644
> >> --- a/security/integrity/evm/evm.h
> >> +++ b/security/integrity/evm/evm.h
> >> @@ -31,8 +31,13 @@ extern struct crypto_shash *hash_tfm;
> >>
> >>  #define EVM_HMAC_ATTR_FSUUID  0x0001
> >>
> >> +struct evm_hmac_xattr {
> >> +  struct list_head list;
> >> +  char *xattr;
> >> +};
> >> +
> >>  /* List of EVM protected security xattrs */
> >> -extern char *evm_config_xattrnames[];
> >> +extern struct list_head evm_hmac_xattrs;
> >>
> >>  int evm_init_key(void);
> >>  int evm_update_evmxattr(struct dentry *dentry,
> >> diff --git a/security/integrity/evm/evm_crypto.c 
> >> b/security/integrity/evm/evm_crypto.c
> >> index ab034e5..7e5bfb7 100644
> >> --- a/security/integrity/evm/evm_crypto.c
> >> +++ b/security/integrity/evm/evm_crypto.c
> >> @@ -133,7 +133,7 @@ static int evm_calc_hmac_or_hash(struct dentry *dentry,
> >>  {
> >>struct inode *inode = dentry->d_inode;
> >>struct shash_desc *desc;
> >> -  char **xattrname;
> >> +  struct evm_hmac_xattr *entry;
> >>size_t xattr_size = 0;
> >>char *xattr_value = NULL;
> >>int error;
> >> @@ -146,15 +146,15 @@ static int evm_calc_hmac_or_hash(struct dentry 
> >> *dentry,
> >>return PTR_ERR(desc);
> >>
> >>error = -ENODATA;
> >> -  for (xattrname = evm_config_xattrnames; *xattrname != NULL; 
> >> xattrname++) {
> >> +  list_for_each_entry(entry, _hmac_xattrs, list) {
> >>if ((req_xattr_name && req_xattr_value)
> >> -  && !strcmp(*xattrname, req_xattr_name)) {
> >> +  && !strcmp(entry->xattr, req_xattr_name)) {
> >>error = 0;
> >>crypto_shash_update(desc, (const u8 *)req_xattr_value,
> >> req_xattr_value_len);
> >>continue;
> >>}
> >> -  size = vfs_getxattr_alloc(dentry, *xattrname,
> >> +  size = vfs_getxattr_alloc(dentry, entry->xattr,
> >>  _value, xattr_size, GFP_NOFS);
> >>if (size == -ENOMEM) {
> >>error = -ENOMEM;
> >> diff --git a/security/integrity/evm/evm_main.c 
> >> b/security/integrity/evm/evm_main.c
> >> index 9c05929..13e03ad 100644
> >> --- a/security/integrity/evm/evm_main.c
> >> +++ b/security/integrity/evm/evm_main.c
> >> @@ -34,19 +34,7 @@ char *evm_hmac = "hmac(sha1)";
> >>  char *evm_hash = "sha1";
> >>  int evm_hmac_attrs;
> >>
> >> 

Re: [PATCH v9 2/3] mmc: sdhci-msm: Initial support for Qualcomm chipsets

[Bjorn Andersson]

On Fri, Feb 28, 2014 at 3:24 AM, Georgi Djakov  wrote:
> This platform driver adds the initial support of Secure
> Digital Host Controller Interface compliant controller
> found in Qualcomm chipsets.
>

Hi Georgi,

Sorry for reposting this, I have no idea how I managed to send this as an answer
to patch 1/3...


When testing this I was confused by the warnings from sdhci not finding vmmc
and vqmmc. Is the power irq something Qualcomm specific or is there any other
reason why the sdhci provided regulator functionality can't be used?

Regarding the usage of the regulator api here, I think you should call
regulator_set_voltage() with your default voltage when you acquire the
regulator handles; then your power enable/disable functions will be simpler and
you should be able to clean up the power irq function further.

>
[...]
> +/* This structure keeps information per regulator */
> +struct sdhci_msm_reg_data {
> +   struct regulator *reg;
> +   const char *name;
> +   /* Voltage level values */
> +   u32 low_vol_level;
> +   u32 high_vol_level;

Is there a reason why these should be different? In your example and the other
cases I've seen they are always 2.95V and 1.8V.

>
[...]
> +
> +static int sdhci_msm_vreg_enable(struct device *dev,
> +struct sdhci_msm_reg_data *vreg)
> +{
> +   int ret = 0;
> +
> +   if (!regulator_is_enabled(vreg->reg)) {
> +   /* Set voltage level */
> +   ret = regulator_set_voltage(vreg->reg, vreg->high_vol_level,
> +   vreg->high_vol_level);
> +   if (ret)
> +   return ret;

So when you enable voltage in the irq handler or in probe, you will go to "high
voltage", then you might lower this directly again.

> +   }
> +
> +   ret = regulator_enable(vreg->reg);
> +   if (ret) {
> +   dev_err(dev, "Failed to enable regulator %s (%d)\n",
> +   vreg->name, ret);
> +   }
> +
> +   return ret;
> +}
> +
> +static int sdhci_msm_vreg_disable(struct device *dev,
> + struct sdhci_msm_reg_data *vreg)
> +{
> +   int ret = 0;
> +
> +   if (!regulator_is_enabled(vreg->reg))
> +   return ret;
> +
> +   /* Set min. voltage to 0 */
> +   ret = regulator_set_voltage(vreg->reg, 0, vreg->high_vol_level);
> +   if (ret)
> +   return ret;

Why do you set the voltage to 0 here?

> +
> +   ret = regulator_disable(vreg->reg);
> +   if (ret) {
> +   dev_err(dev, "Failed to disable regulator %s (%d)\n",
> +   vreg->name, ret);
> +   }
> +
> +   return ret;
> +}
> +
> +static int sdhci_msm_setup_vreg(struct sdhci_msm_host *msm_host, bool enable)
> +{

Instead of having a function with one big if statement of which path you came
from you should have two functions for this.

> +   int ret, i;
> +   struct sdhci_msm_reg_data *vreg_table[2];
> +
> +   vreg_table[0] = _host->pdata.vdd;
> +   vreg_table[1] = _host->pdata.vdd_io;
> +
> +   for (i = 0; i < ARRAY_SIZE(vreg_table); i++) {
> +   if (enable)
> +   ret = sdhci_msm_vreg_enable(_host->pdev->dev,
> +   vreg_table[i]);
> +   else
> +   ret = sdhci_msm_vreg_disable(_host->pdev->dev,
> +vreg_table[i]);
> +   if (ret)
> +   return ret;
> +   }

This seems to a complicated way of saying:

if (enable) {
sdhci_msm_vreg_enable(vdd)
sdhci_msm_vreg_enable(vdd_io)
} else {
sdhci_msm_vreg_disable(vdd)
sdhci_msm_vreg_disable(vdd_io)
}

Do you plan to add more regulators here?

> +
> +   return 0;
> +}
> +
> +static int sdhci_msm_vreg_init(struct device *dev,
> +  struct sdhci_msm_pltfm_data *pdata)
> +{
> +   struct sdhci_msm_reg_data *vdd_reg = >vdd;
> +   struct sdhci_msm_reg_data *vdd_io_reg = >vdd_io;
> +
> +   vdd_reg->reg = devm_regulator_get(dev, vdd_reg->name);
> +   if (IS_ERR(vdd_reg->reg))
> +   return PTR_ERR(vdd_reg->reg);
> +
> +   vdd_io_reg->reg = devm_regulator_get(dev, vdd_io_reg->name);
> +   if (IS_ERR(vdd_io_reg->reg))
> +   return PTR_ERR(vdd_io_reg->reg);
> +
> +   return 0;
> +}
> +
> +static irqreturn_t sdhci_msm_pwr_irq(int irq, void *data)
> +{
> +   struct sdhci_host *host = (struct sdhci_host *)data;
> +   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> +   struct sdhci_msm_host *msm_host = pltfm_host->priv;
> +   u8 irq_status;
> +   u8 irq_ack = 0;
> +   int ret = 0;
> +
> +   irq_status = readb_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
> +   dev_dbg(mmc_dev(msm_host->mmc), "%s: Received IRQ(%d), status=0x%x\n",
> +   mmc_hostname(msm_host->mmc), irq, 

Re: [PATCH v4] mm: per-thread vma caching

[Davidlohr Bueso]

On Mon, 2014-03-03 at 19:12 -0800, Andrew Morton wrote:
> On Mon, 03 Mar 2014 18:42:33 -0800 Davidlohr Bueso  wrote:
> 
> > On Mon, 2014-03-03 at 17:23 -0800, Andrew Morton wrote:
> > > On Mon, 03 Mar 2014 16:59:38 -0800 Davidlohr Bueso  
> > > wrote:
> > > 
> > > > > >...
> > > > > >
> > > > > > +static bool vmacache_valid(struct mm_struct *mm)
> > > > > > +{
> > > > > > +   struct task_struct *curr = current;
> > > > > > +
> > > > > > +   if (mm != curr->mm)
> > > > > > +   return false;
> > > > > 
> > > > > What's going on here?  Handling a task poking around in someone else's
> > > > > mm?  I'm thinking "__access_remote_vm", but I don't know what you were
> > > > > thinking ;) An explanatory comment would be revealing.
> > > > 
> > > > I don't understand the doubt here. Seems like a pretty obvious thing to
> > > > check -- yes it's probably unlikely but we certainly don't want to be
> > > > validating the cache on an mm that's not ours... or are you saying it's
> > > > redundant??
> > > 
> > > Well it has to be here for a reason and I'm wondering that that reason
> > > is.  If nobody comes here with a foreign mm then let's remove it.
> > 
> > find_vma() can be called by concurrent threads sharing the mm->mmap_sem
> > for reading, thus this check needs to be there.
> 
> Confused.  If the threads share mm->mmap_sem then they share mm and the
> test will always be false?

Yes, I shortly realized that was silly... but I can say for sure it can
happen and a quick qemu run confirms it. So I see your point as to
asking why we need it, so now I'm looking for an explanation in the
code.

--
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 net-next] hyperv: Move state setting for link query

[Jason Wang]

On 03/04/2014 07:54 AM, Haiyang Zhang wrote:
> It moves the state setting for query into rndis_filter_receive_response().
> All callbacks including query-complete and status-callback are synchronized
> by channel->inbound_lock. This prevents pentential race between them.

This still looks racy to me. The problem is workqueue is not
synchronized with those here.

Consider the following case in netvsc_link_change():

if (rdev->link_state) {
... receive interrupt ...
rndis_filter_receice_response() which changes rdev->link_state
...
netif_carrier_off()
}

And also it need to schedule a work otherwise the link status is out of
sync.
> Signed-off-by: Haiyang Zhang 
> ---
>  drivers/net/hyperv/rndis_filter.c |   21 -
>  1 files changed, 20 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/hyperv/rndis_filter.c 
> b/drivers/net/hyperv/rndis_filter.c
> index f0cc8ef..6a9f602 100644
> --- a/drivers/net/hyperv/rndis_filter.c
> +++ b/drivers/net/hyperv/rndis_filter.c
> @@ -240,6 +240,22 @@ static int rndis_filter_send_request(struct rndis_device 
> *dev,
>   return ret;
>  }
>  
> +static void rndis_set_link_state(struct rndis_device *rdev,
> +  struct rndis_request *request)
> +{
> + u32 link_status;
> + struct rndis_query_complete *query_complete;
> +
> + query_complete = >response_msg.msg.query_complete;
> +
> + if (query_complete->status == RNDIS_STATUS_SUCCESS &&
> + query_complete->info_buflen == sizeof(u32)) {
> + memcpy(_status, (void *)((unsigned long)query_complete +
> +query_complete->info_buf_offset), sizeof(u32));
> + rdev->link_state = link_status != 0;
> + }
> +}
> +
>  static void rndis_filter_receive_response(struct rndis_device *dev,
>  struct rndis_message *resp)
>  {
> @@ -269,6 +285,10 @@ static void rndis_filter_receive_response(struct 
> rndis_device *dev,
>   sizeof(struct rndis_message) + RNDIS_EXT_LEN) {
>   memcpy(>response_msg, resp,
>  resp->msg_len);
> + if (request->request_msg.ndis_msg_type ==
> + RNDIS_MSG_QUERY && request->request_msg.msg.
> + query_req.oid == RNDIS_OID_GEN_MEDIA_CONNECT_STATUS)
> + rndis_set_link_state(dev, request);
>   } else {
>   netdev_err(ndev,
>   "rndis response buffer overflow "
> @@ -617,7 +637,6 @@ static int rndis_filter_query_device_link_status(struct 
> rndis_device *dev)
>   ret = rndis_filter_query_device(dev,
> RNDIS_OID_GEN_MEDIA_CONNECT_STATUS,
> _status, );
> - dev->link_state = (link_status != 0) ? true : false;
>  
>   return ret;
>  }

--
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] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

On Mon, Mar 03, 2014 at 05:24:06PM -0500, Jason Cooper wrote:
> I've no issue with reverting this driver.  I'll ask arm-soc to hold off
> on pulling the latest mvebu DT pull request which contains the DT node.
> I _really_ don't want to do a revert of a revert of a revert. :-/

Done.  I'll work on reverting the driver tomorrow.  It's currently in
tip/irq/core queued for v3.15.

thx,

Jason.
--
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: build failure after merge of the mfd-lj tree

[Stephen Rothwell]

Hi Lee,

On Tue, 11 Feb 2014 13:25:52 +1100 Stephen Rothwell  
wrote:
> 
> After merging the mfd-lj tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/mfd/tps65218: struct i2c_device_id is 32 bytes.  The last of 1 is:
> 0x74 0x70 0x73 0x36 0x35 0x32 0x31 0x38 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x00 0x00 0x00 0x00 0x00 
> 0x00 0x00 
> FATAL: drivers/mfd/tps65218: struct i2c_device_id is not terminated with a 
> NULL entry!
> 
> Caused by commit cc493e30e3a1 ("mfd: tps65218: Add driver for the
> TPS65218 PMIC").

Now that the otherproblem is fixed, I am getting this one again :-(

> I have used the mfd-lj tree from next-20140210 for today.

Again.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpgagTtcYr4f.pgp
Description: PGP signature

[PATCH V6 Resend 2/5] cpufreq: Implement cpufreq_generic_suspend()

[Viresh Kumar]

Multiple platforms need to set CPU to a particular frequency before suspending
system. And so they need a common infrastructure which is provided by this
patch. Those platforms just need to initialize their ->suspend() pointers with
the generic routine.

Tested-by: Stephen Warren 
Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 26 ++
 include/linux/cpufreq.h   |  3 +++
 2 files changed, 29 insertions(+)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 2e43c08..b6f8545 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1578,6 +1578,32 @@ static struct subsys_interface cpufreq_interface = {
.remove_dev = cpufreq_remove_dev,
 };
 
+/*
+ * In case platform wants some specific frequency to be configured
+ * during suspend..
+ */
+int cpufreq_generic_suspend(struct cpufreq_policy *policy)
+{
+   int ret;
+
+   if (!policy->suspend_freq) {
+   pr_err("%s: suspend_freq can't be zero\n", __func__);
+   return -EINVAL;
+   }
+
+   pr_debug("%s: Setting suspend-freq: %u\n", __func__,
+   policy->suspend_freq);
+
+   ret = __cpufreq_driver_target(policy, policy->suspend_freq,
+   CPUFREQ_RELATION_H);
+   if (ret)
+   pr_err("%s: unable to set suspend-freq: %u. err: %d\n",
+   __func__, policy->suspend_freq, ret);
+
+   return ret;
+}
+EXPORT_SYMBOL(cpufreq_generic_suspend);
+
 /**
  * cpufreq_suspend() - Suspend CPUFreq governors
  *
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 94ed907..325bab0 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -74,6 +74,8 @@ struct cpufreq_policy {
unsigned intmax;/* in kHz */
unsigned intcur;/* in kHz, only needed if cpufreq
 * governors are used */
+   unsigned intsuspend_freq; /* freq to set during suspend */
+
unsigned intpolicy; /* see above */
struct cpufreq_governor *governor; /* see below */
void*governor_data;
@@ -299,6 +301,7 @@ cpufreq_verify_within_cpu_limits(struct cpufreq_policy 
*policy)
 #ifdef CONFIG_CPU_FREQ
 void cpufreq_suspend(void);
 void cpufreq_resume(void);
+int cpufreq_generic_suspend(struct cpufreq_policy *policy);
 #else
 static inline void cpufreq_suspend(void) {}
 static inline void cpufreq_resume(void) {}
-- 
1.7.12.rc2.18.g61b472e

--
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 V6 Resend 1/5] cpufreq: suspend governors on system suspend/hibernate

[Viresh Kumar]

This patch adds cpufreq suspend/resume calls to dpm_{suspend|resume}() for
handling suspend/resume of cpufreq governors.

Lan Tianyu (Intel) & Jinhyuk Choi (Broadcom) found an issue where tunables
configuration for clusters/sockets with non-boot CPUs was getting lost after
suspend/resume, as we were notifying governors with CPUFREQ_GOV_POLICY_EXIT on
removal of the last cpu for that policy and so deallocating memory for tunables.
This is fixed by this patch as we don't allow any operation on governors after
device suspend and before device resume now.

We could have added these callbacks at dpm_{suspend|resume}_noirq() level but
the problem here is that most of the devices (i.e. devices with ->suspend()
callbacks) have already been suspended by now and so if drivers want to change
frequency before suspending, then it might not be possible for many platforms
(which depend on other peripherals like i2c, regulators, etc).

Reported-and-tested-by: Lan Tianyu 
Reported-by: Jinhyuk Choi 
Signed-off-by: Viresh Kumar 
---
V5->V6: 1-2-3/7 merged into 1/5

 drivers/base/power/main.c |   5 +++
 drivers/cpufreq/cpufreq.c | 111 +++---
 include/linux/cpufreq.h   |   8 
 3 files changed, 69 insertions(+), 55 deletions(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 42355e4..86d5e4f 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -866,6 +867,8 @@ void dpm_resume(pm_message_t state)
mutex_unlock(_list_mtx);
async_synchronize_full();
dpm_show_time(starttime, state, NULL);
+
+   cpufreq_resume();
 }
 
 /**
@@ -1434,6 +1437,8 @@ int dpm_suspend(pm_message_t state)
 
might_sleep();
 
+   cpufreq_suspend();
+
mutex_lock(_list_mtx);
pm_transition = state;
async_error = 0;
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 56b7b1b..2e43c08 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -47,6 +47,9 @@ static LIST_HEAD(cpufreq_policy_list);
 static DEFINE_PER_CPU(char[CPUFREQ_NAME_LEN], cpufreq_cpu_governor);
 #endif
 
+/* Flag to suspend/resume CPUFreq governors */
+static bool cpufreq_suspended;
+
 static inline bool has_target(void)
 {
return cpufreq_driver->target_index || cpufreq_driver->target;
@@ -1576,82 +1579,77 @@ static struct subsys_interface cpufreq_interface = {
 };
 
 /**
- * cpufreq_bp_suspend - Prepare the boot CPU for system suspend.
+ * cpufreq_suspend() - Suspend CPUFreq governors
  *
- * This function is only executed for the boot processor.  The other CPUs
- * have been put offline by means of CPU hotplug.
+ * Called during system wide Suspend/Hibernate cycles for suspending governors
+ * as some platforms can't change frequency after this point in suspend cycle.
+ * Because some of the devices (like: i2c, regulators, etc) they use for
+ * changing frequency are suspended quickly after this point.
  */
-static int cpufreq_bp_suspend(void)
+void cpufreq_suspend(void)
 {
-   int ret = 0;
-
-   int cpu = smp_processor_id();
struct cpufreq_policy *policy;
 
-   pr_debug("suspending cpu %u\n", cpu);
+   if (!cpufreq_driver)
+   return;
 
-   /* If there's no policy for the boot CPU, we have nothing to do. */
-   policy = cpufreq_cpu_get(cpu);
-   if (!policy)
-   return 0;
+   if (!has_target())
+   return;
 
-   if (cpufreq_driver->suspend) {
-   ret = cpufreq_driver->suspend(policy);
-   if (ret)
-   printk(KERN_ERR "cpufreq: suspend failed in ->suspend "
-   "step on CPU %u\n", policy->cpu);
+   pr_debug("%s: Suspending Governors\n", __func__);
+
+   list_for_each_entry(policy, _policy_list, policy_list) {
+   if (__cpufreq_governor(policy, CPUFREQ_GOV_STOP))
+   pr_err("%s: Failed to stop governor for policy: %p\n",
+   __func__, policy);
+   else if (cpufreq_driver->suspend
+   && cpufreq_driver->suspend(policy))
+   pr_err("%s: Failed to suspend driver: %p\n", __func__,
+   policy);
}
 
-   cpufreq_cpu_put(policy);
-   return ret;
+   cpufreq_suspended = true;
 }
 
 /**
- * cpufreq_bp_resume - Restore proper frequency handling of the boot CPU.
+ * cpufreq_resume() - Resume CPUFreq governors
  *
- * 1.) resume CPUfreq hardware support (cpufreq_driver->resume())
- * 2.) schedule call cpufreq_update_policy() ASAP as interrupts are
- * restored. It will verify that the current freq is in sync with
- * what we believe it to be. This is a bit later than when it
- *