Re: [PATCH] ARM: Don't oops when userspace executes kgdb break instructions.

[Omar Sandoval]

On Fri, Jul 18, 2014 at 03:51:31PM -0700, Omar Sandoval wrote:
> Don't break into kgdb when userspace executes the kernel break instructions
> (KGDB_BREAKINST and KGDB_COMPILED_BREAK). The kernel will oops in
> kgdb_handle_exception.
> 
> Signed-off-by: Omar Sandoval 
> ---
> The following program will immediately cause a kernel oops:
> .globl _start
> _start:
>   udf #65006  @ KGDB_BREAKINST
> 
>  arch/arm/kernel/kgdb.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
> index 778c2f7..a74b53c 100644
> --- a/arch/arm/kernel/kgdb.c
> +++ b/arch/arm/kernel/kgdb.c
> @@ -160,12 +160,16 @@ static int kgdb_compiled_brk_fn(struct pt_regs *regs, 
> unsigned int instr)
>  static struct undef_hook kgdb_brkpt_hook = {
>   .instr_mask = 0x,
>   .instr_val  = KGDB_BREAKINST,
> + .cpsr_mask  = MODE_MASK,
> + .cpsr_val   = SVC_MODE,
>   .fn = kgdb_brk_fn
>  };
>  
>  static struct undef_hook kgdb_compiled_brkpt_hook = {
>   .instr_mask = 0x,
>   .instr_val  = KGDB_COMPILED_BREAK,
> + .cpsr_mask  = MODE_MASK,
> + .cpsr_val   = SVC_MODE,
>   .fn = kgdb_compiled_brk_fn
>  };
>  
> -- 
> 2.0.1

-- 

Following up/clarifying this. This only happens when the kernel is compiled
with CONFIG_KGDB. When a userspace program executes KGDB_BREAKINST or
KGDB_COMPILED_BREAK, the undef_hook for kgdb catches it. The reason in kdb_stub
defaults to KDB_REASON_OOPS, so the bug manifests itself as an oops caused by
userspace (a better description for the patch would be "Don't enter KGDB when
userspace executes kgdb break instructions"). This means that a buggy/malicious
program can take down the system just by executing an instruction.

ARM64 might have the same issue, but I don't have a board to test that on.

I verified that breaking normally (e.g., with kgdbwait or through
/proc/sysrq-trigger) still works.
—
Omar
--
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] fs: umount on symlinlk leaks mnt count

[Vasily Averin]

Currently umount on symlink blocks following umount:

/vz is separate mount

# ls /vz/ -al | grep test
drwxr-xr-x.  2 root root   4096 Jul 19 01:14 testdir
lrwxrwxrwx.  1 root root 11 Jul 19 01:16 testlink -> /vz/testdir

# umount -l /vz/testlink
umount: /vz/testlink: not mounted (expected)

# lsof /vz
# umount /vz
umount: /vz: device is busy. (unexpected)

Looks like an extra refcount on mnt was taken in mountpoint_last()
Patch below fixes the problem on my test node.

Signed-off-by:  Vasily Averin 
diff --git a/fs/namei.c b/fs/namei.c
index 985c6f3..0d32a0f 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2305,6 +2305,7 @@ path_mountpoint(int dfd, const char *name, struct path 
*path, unsigned int flags
break;
err = mountpoint_last(, path);
put_link(, , cookie);
+   mntput(link.mnt);
}
 out:
if (base)

[PATCH] xen/pciback: Fix error return code in xen_pcibk_attach()

[weiyj_lk]

From: Wei Yongjun 

Fix to return -EFAULT from the error handling case instead of 0 when
version mismatch with pcifront.

Signed-off-by: Wei Yongjun 
---
 drivers/xen/xen-pciback/xenbus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c
index 4a7e6e0..c214daa 100644
--- a/drivers/xen/xen-pciback/xenbus.c
+++ b/drivers/xen/xen-pciback/xenbus.c
@@ -174,6 +174,7 @@ static int xen_pcibk_attach(struct xen_pcibk_device *pdev)
 "version mismatch (%s/%s) with pcifront - "
 "halting " DRV_NAME,
 magic, XEN_PCI_MAGIC);
+   err = -EFAULT;
goto out;
}
 

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

Re: [PATCH 0/2 v4] sched: Rewrite per entity runnable load average tracking

[Mike Galbraith]

On Fri, 2014-07-18 at 07:26 +0800, Yuyang Du wrote: 
> Thanks to Morten, Ben, and Fengguang.
> 
> v4 changes:
> 
> - Insert memory barrier before writing cfs_rq->load_last_update_copy.
> - Fix typos.

My little desktop box says lovely minus signs have had their usual
effect on the general case (cgroups enabled but not in use). 

pipe-test scheduling cross core - full fastpath
3.0.101-default3.753363 usecs/loop -- avg 3.770737 530.4 KHz   1.000
3.1.10-default 3.723843 usecs/loop -- avg 3.716058 538.2 KHz   1.014
3.2.51-default 3.728060 usecs/loop -- avg 3.710372 539.0 KHz   1.016
3.3.8-default  3.906174 usecs/loop -- avg 3.900399 512.8 KHz.966
3.4.97-default 3.864158 usecs/loop -- avg 3.865281 517.4 KHz.975
3.5.7-default  3.967481 usecs/loop -- avg 3.962757 504.7 KHz.951
3.6.11-default 3.851186 usecs/loop -- avg 3.845321 520.1 KHz.980
3.7.10-default 3.777869 usecs/loop -- avg 3.776913 529.5 KHz.998
3.8.13-default 4.049927 usecs/loop -- avg 4.041905 494.8 KHz.932
3.9.11-default 3.973046 usecs/loop -- avg 3.974208 503.2 KHz.948
3.10.27-default4.189598 usecs/loop -- avg 4.189298 477.4 KHz.900
3.11.10-default4.293870 usecs/loop -- avg 4.297979 465.3 KHz.877
3.12.24-default4.321570 usecs/loop -- avg 4.321961 462.8 KHz.872
3.13.11-default4.137845 usecs/loop -- avg 4.134863 483.7 KHz.911
3.14.10-default4.145348 usecs/loop -- avg 4.139987 483.1 KHz.910

3.15.4-default 4.355594 usecs/loop -- avg 4.351961 459.6 KHz.866
 
3.16.0-default 4.537279 usecs/loop -- avg 4.543532 440.2 KHz.829
 1.000   
3.16.0-default+v4  4.343542 usecs/loop -- avg 4.318803 463.1 KHz.873
 1.052

Extending max depth to 5, cost of depth++ seemingly did not change
despite repeatable dip at depth = 3 (gremlins at play).

mount -t cgroup o cpu none /cgroups
mkdir -p /cgroups/a/b/c/d/e

cgexec -g cpu:a pipe-test 1
3.16.0-default 5.016373 usecs/loop -- avg 5.021115 398.3 KHz   1.000
3.16.0-default+v4  4.978625 usecs/loop -- avg 4.977381 401.8 KHz   1.008

cgexec -g cpu:a/b pipe-test 1
3.16.0-default 5.543566 usecs/loop -- avg 5.565475 359.4 KHz   1.000
3.16.0-default+v4  5.597399 usecs/loop -- avg 5.570444 359.0 KHz.998

cgexec -g cpu:a/b/c pipe-test 1
3.16.0-default 6.092256 usecs/loop -- avg 6.094186 328.2 KHz   1.000
3.16.0-default+v4  6.294858 usecs/loop -- avg 6.338453 315.5 KHz.961

cgexec -g cpu:a/b/c/d pipe-test 1
3.16.0-default 6.719044 usecs/loop -- avg 6.717118 297.7 KHz   1.000
3.16.0-default+v4  6.788559 usecs/loop -- avg 6.710102 298.1 KHz   1.001

cgexec -g cpu:a/b/c/d/e pipe-test 1
3.16.0-default 7.186431 usecs/loop -- avg 7.194884 278.0 KHz   1.000
3.16.0-default+v4  7.368443 usecs/loop -- avg 7.250371 275.8 KHz.992


--
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: vt6655: remove redundant comments

[Igor Bezukh]

Clean redundant comments in the code.
Since I perform single fix type per patch, I've ignored the 80 line warning
when checking the patch against checkpatch.
I will fix the 80 line warnings on further patches.

Signed-off-by: Igor Bezukh 
---
 drivers/staging/vt6655/wcmd.c |   46 -
 1 file changed, 13 insertions(+), 33 deletions(-)

diff --git a/drivers/staging/vt6655/wcmd.c b/drivers/staging/vt6655/wcmd.c
index a689645..2456b30 100644
--- a/drivers/staging/vt6655/wcmd.c
+++ b/drivers/staging/vt6655/wcmd.c
@@ -54,13 +54,7 @@
 #include "iowpa.h"
 #include "channel.h"
 
-/*-  Static Definitions -*/
-
-/*-  Static Classes  */
-
-/*-  Static Variables  --*/
 static int msglevel = MSG_LEVEL_INFO;
-/*-  Static Functions  --*/
 
 static
 void
@@ -85,10 +79,6 @@ s_bCommandComplete(
PSDevice pDevice
 );
 
-/*-  Export Variables  --*/
-
-/*-  Export Functions  --*/
-
 /*
  * Description:
  *  Stop AdHoc beacon during scan process
@@ -134,7 +124,7 @@ vAdHocBeaconStop(PSDevice  pDevice)
 
if (bStop)
MACvRegBitsOff(pDevice->PortOffset, MAC_REG_TCR, TCR_AUTOBCNTX);
-} /* vAdHocBeaconStop */
+}
 
 /*
  * Description:
@@ -167,7 +157,7 @@ vAdHocBeaconRestart(PSDevice pDevice)
}
 }
 
-/*+
+/*
  *
  * Routine Description:
  *   Prepare and send probe request management frames.
@@ -176,7 +166,7 @@ vAdHocBeaconRestart(PSDevice pDevice)
  * Return Value:
  *none.
  *
- -*/
+ */
 
 static
 void
@@ -223,7 +213,7 @@ s_vProbeChannel(
}
 }
 
-/*+
+/*
  *
  * Routine Description:
  *  Constructs an probe request frame
@@ -232,7 +222,7 @@ s_vProbeChannel(
  * Return Value:
  *A ptr to Tx frame or NULL on allocation failure
  *
- -*/
+ */
 
 PSTxMgmtPacket
 s_MgrMakeProbeRequest(
@@ -292,7 +282,6 @@ vCommandTimerWait(
init_timer(>sTimerCommand);
pDevice->sTimerCommand.data = (unsigned long) pDevice;
pDevice->sTimerCommand.function = (TimerFunction)vCommandTimer;
-   // RUN_AT :1 msec ~= (HZ/1024)
pDevice->sTimerCommand.expires = (unsigned int)RUN_AT((MSecond * HZ) >> 
10);
add_timer(>sTimerCommand);
return;
@@ -366,9 +355,8 @@ vCommandTimer(
s_bCommandComplete(pDevice);
 
} else {
-//2008-8-4  by chester
if (!is_channel_valid(pMgmt->uScanChannel)) {
-   DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO "Invalid 
channel pMgmt->uScanChannel = %d \n", pMgmt->uScanChannel);
+   DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO "Invalid 
channel pMgmt->uScanChannel = %d\n", pMgmt->uScanChannel);
s_bCommandComplete(pDevice);
spin_unlock_irq(>lock);
return;
@@ -394,7 +382,6 @@ vCommandTimer(
 
CARDbSetBSSID(pMgmt->pAdapter, pMgmt->abyCurrBSSID, 
OP_MODE_UNKNOWN);
pMgmt->uScanChannel++;
-//2008-8-4  by chester
if (!is_channel_valid(pMgmt->uScanChannel) &&
pMgmt->uScanChannel <= pDevice->byMaxChannel) {
pMgmt->uScanChannel = pDevice->byMaxChannel + 1;
@@ -431,7 +418,6 @@ vCommandTimer(
 
pMgmt->eScanState = WMAC_NO_SCANNING;
vAdHocBeaconRestart(pDevice);
-//2008-0409-07,  by Einsn Liu
 #ifdef WPA_SUPPLICANT_DRIVER_WEXT_SUPPORT
if (pMgmt->eScanType == WMAC_SCAN_PASSIVE)
{//send scan event to wpa_Supplicant
@@ -471,7 +457,6 @@ vCommandTimer(
return;
}
DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO " CARDbRadioPowerOff\n");
-   //2008-09-02  by chester
s_bCommandComplete(pDevice);
break;
 
@@ -482,7 +467,6 @@ vCommandTimer(
spin_unlock_irq(>lock);
return;
}
-//2008-09-02   by chester
s_bCommandComplete(pDevice);
break;
 
@@ -615,7 +599,7 @@ vCommandTimer(
 
else if (pMgmt->eCurrState < WMAC_STATE_AUTHPENDING) {
printk("WLAN_AUTHENTICATE_WAIT:Authen Fail???\n");
-   } else if (pDevice->byLinkWaitCount <= 4) {//mike add:wait 
another 2 sec if authenticated_frame delay!
+   } else if (pDevice->byLinkWaitCount <= 4) {
pDevice->byLinkWaitCount++;
printk("WLAN_AUTHENTICATE_WAIT:wait %d times!!\n", 
pDevice->byLinkWaitCount);
spin_unlock_irq(>lock);
@@ -652,7 +636,7 @@ vCommandTimer(
init_timer(>sTimerTxData);
   

[PATCH -next] power_supply: Fix sparse non static symbol warning

[weiyj_lk]

From: Wei Yongjun 

Fixes the following sparse warnings:

drivers/power/power_supply_core.c:540:5: warning:
 symbol '__power_supply_register' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/power/power_supply_core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/power/power_supply_core.c 
b/drivers/power/power_supply_core.c
index 5a5a24e..078afd6 100644
--- a/drivers/power/power_supply_core.c
+++ b/drivers/power/power_supply_core.c
@@ -537,7 +537,8 @@ static void psy_unregister_cooler(struct power_supply *psy)
 }
 #endif
 
-int __power_supply_register(struct device *parent, struct power_supply *psy, 
bool ws)
+static int __power_supply_register(struct device *parent,
+  struct power_supply *psy, bool ws)
 {
struct device *dev;
int rc;

--
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 -next] misc: vexpress: Fix sparse non static symbol warnings

[weiyj_lk]

From: Wei Yongjun 

Fixes the following sparse warnings:

drivers/misc/vexpress-syscfg.c:133:22: warning:
 symbol 'vexpress_syscfg_regmap_config' was not declared. Should it be static?
drivers/misc/vexpress-syscfg.c:279:5: warning:
 symbol 'vexpress_syscfg_probe' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/misc/vexpress-syscfg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/vexpress-syscfg.c b/drivers/misc/vexpress-syscfg.c
index 3250fc1..b3a8123 100644
--- a/drivers/misc/vexpress-syscfg.c
+++ b/drivers/misc/vexpress-syscfg.c
@@ -130,7 +130,7 @@ static int vexpress_syscfg_write(void *context, unsigned 
int index,
return vexpress_syscfg_exec(func, index, true, );
 }
 
-struct regmap_config vexpress_syscfg_regmap_config = {
+static struct regmap_config vexpress_syscfg_regmap_config = {
.lock = vexpress_config_lock,
.unlock = vexpress_config_unlock,
.reg_bits = 32,
@@ -276,7 +276,7 @@ int vexpress_syscfg_device_register(struct platform_device 
*pdev)
 }
 
 
-int vexpress_syscfg_probe(struct platform_device *pdev)
+static int vexpress_syscfg_probe(struct platform_device *pdev)
 {
struct vexpress_syscfg *syscfg;
struct resource *res;

--
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 -next] HSI: ssi_protocol: Fix sparse non static symbol warning

[weiyj_lk]

From: Wei Yongjun 

Fixes the following sparse warning:

drivers/hsi/clients/ssi_protocol.c:904:6: warning:
 symbol 'ssip_port_event' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/hsi/clients/ssi_protocol.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hsi/clients/ssi_protocol.c 
b/drivers/hsi/clients/ssi_protocol.c
index 737fa2e..e5c7a96 100644
--- a/drivers/hsi/clients/ssi_protocol.c
+++ b/drivers/hsi/clients/ssi_protocol.c
@@ -901,7 +901,7 @@ out:
ssip_free_data(msg);
 }
 
-void ssip_port_event(struct hsi_client *cl, unsigned long event)
+static void ssip_port_event(struct hsi_client *cl, unsigned long event)
 {
switch (event) {
case HSI_EVENT_START_RX:

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

solos-pci.c: Fix me

[Nick Krause]

Hey Chas,
There seems to be a fix me in this file in the function, solos_bh.
Is the default statement correct and I remove the fix me or
does it need to be rewritten.
Cheers Nick
--
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] staging: lustre/lustre/lov: Remove unneeded 'if' statement in lov_request.c/lov_check_set()

[Dan Carpenter]

On Sat, Jul 19, 2014 at 09:34:56PM +0200, Riccardo Lucchese wrote:
> It is silly to go through an if statement to set a single boolean
> value in function of a single boolean expression. In the function
> lov_check_set, assign the return value directly.
> 
> Signed-off-by: Riccardo Lucchese 
> ---
>  drivers/staging/lustre/lustre/lov/lov_request.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/lov/lov_request.c 
> b/drivers/staging/lustre/lustre/lov/lov_request.c
> index ce830e4..90fc66a 100644
> --- a/drivers/staging/lustre/lustre/lov/lov_request.c
> +++ b/drivers/staging/lustre/lustre/lov/lov_request.c
> @@ -140,14 +140,13 @@ void lov_set_add_req(struct lov_request *req, struct 
> lov_request_set *set)
>  
>  static int lov_check_set(struct lov_obd *lov, int idx)
>  {
> - int rc = 0;
> + int rc;
>   mutex_lock(>lov_lock);
>  
> - if (lov->lov_tgts[idx] == NULL ||
> - lov->lov_tgts[idx]->ltd_active ||
> - (lov->lov_tgts[idx]->ltd_exp != NULL &&
> -  class_exp2cliimp(lov->lov_tgts[idx]->ltd_exp)->imp_connect_tried))
> - rc = 1;
> + rc = lov->lov_tgts[idx] == NULL ||
> + lov->lov_tgts[idx]->ltd_active ||
> + (lov->lov_tgts[idx]->ltd_exp != NULL &&
> +  
> class_exp2cliimp(lov->lov_tgts[idx]->ltd_exp)->imp_connect_tried);

I don't see how this makes the code more readable at all.

regards,
dan carpenter

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

cciss_scsi.c: Fix me

[Nick Krause]

Hey Mike,
I seem to be hitting a fix me message in this file in
function,cciss_scsi_queue_command_lck.
I am wondering what you want to do when C is Null?
Cheers Nick
--
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 -next] ALSA: bebob: Fix missing unlock on error in special_clk_ctl_put()

[weiyj_lk]

From: Wei Yongjun 

Add the missing unlock before return from function special_clk_ctl_put()
in the error handling case.

Signed-off-by: Wei Yongjun 
---
 sound/firewire/bebob/bebob_maudio.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sound/firewire/bebob/bebob_maudio.c 
b/sound/firewire/bebob/bebob_maudio.c
index 6af50eb..6748515 100644
--- a/sound/firewire/bebob/bebob_maudio.c
+++ b/sound/firewire/bebob/bebob_maudio.c
@@ -382,8 +382,10 @@ static int special_clk_ctl_put(struct snd_kcontrol *kctl,
mutex_lock(>mutex);
 
id = uval->value.enumerated.item[0];
-   if (id >= ARRAY_SIZE(special_clk_labels))
+   if (id >= ARRAY_SIZE(special_clk_labels)) {
+   mutex_unlock(>mutex);
return 0;
+   }
 
err = avc_maudio_set_special_clk(bebob, id,
 params->dig_in_fmt,

--
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/1] Staging: comedi: adv_pci1710: a line over 80 fixed

[Sam Asadi]

a line over 80 issue fixed by removing the cross-lined comment
to the previous line.

Signed-off-by: Sam Asadi 
---
 drivers/staging/comedi/drivers/adv_pci1710.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/adv_pci1710.c 
b/drivers/staging/comedi/drivers/adv_pci1710.c
index 602b7a1..040a5cb 100644
--- a/drivers/staging/comedi/drivers/adv_pci1710.c
+++ b/drivers/staging/comedi/drivers/adv_pci1710.c
@@ -722,8 +722,9 @@ static int pci171x_ai_cancel(struct comedi_device *dev,
default:
devpriv->CntrlReg &= Control_CNT0;
devpriv->CntrlReg |= Control_SW;
-
-   outw(devpriv->CntrlReg, dev->iobase + PCI171x_CONTROL); /*  
reset any operations */
+
+   /* reset any operations */
+   outw(devpriv->CntrlReg, dev->iobase + PCI171x_CONTROL);
pci171x_start_pacer(dev, false);
outb(0, dev->iobase + PCI171x_CLRFIFO);
outb(0, dev->iobase + PCI171x_CLRINT);
-- 
1.7.10.4

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

processor.c: Fix me to rewrite init_percpu_pro

[Nick Krause]

Hey James
I am wondering how you would like this function.init_percpu_pro
in processor.c.
Cheers Nick
--
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/

Edma.c: Fix Mes

[Nick Krause]

Hey Russell and others,
Sorry to bug you again but I have a fix questions before I clean up
the fix mes in this file.
Is edma_clean_channel needed or is edma_stop good enough?  And do  we
CCERR.BIT(16)
need to write this bit or not?
Cheers Nick
--
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: Arm Build Failing

[Nick Krause]

On Sun, Jul 20, 2014 at 12:10 AM, Roberto J. Dohnert
 wrote:
> It looks like its trying to invoke the native (x86) compiler, but passing it
> options that only make sense to an ARM compiler.
>
> Cheers
>
> Roberto J. Dohnert
> Roberto J. Dohnert
> Lead Developer
> Black Lab Software Inc.
> PO Box 698
> Franklinton NC 27525
> http://www.pc-opensystems.com
> http://www.blacklablinux.org
>
>
> On 07/20/2014 12:03 AM, Nick Krause wrote:
>>
>> arm-linux-gnueabihf-gcc: error: unrecognized command line option ‘-m64’
>> arm-linux-gnueabihf-gcc: error: unrecognized command line option
>> ‘-mno-mmx’
>> arm-linux-gnueabihf-gcc: error: unrecognized command line option
>> ‘-mno-sse’
>> arm-linux-gnueabihf-gcc: error: unrecognized command line option
>> ‘-mno-red-zone’
>> arm-linux-gnueabihf-gcc: error: unrecognized command line option
>> ‘-mcmodel=kernel’
>> This happens every time I try to build new arch code this week. Is there a
>> easy
>> fix for this?
>> Cheers Nick
>> --
>> 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/
>>
>
That was a stupid mistake :). I would like to known how to cross
compile only one directory
as I am primarily doing arm fix mes.
Cheers Nick
--
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: android: ion: ion_cma_heap.c: Fix checkpatch warning

[Phong Tran]

This patch fix coding style:

- Remove "fail memory allocation" waring
- Remove return of void function

Tested by compilation only

Signed-off-by: Phong Tran 
---
 drivers/staging/android/ion/ion_cma_heap.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index ce68ecf..f8cabcb 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -76,10 +76,8 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
return -EINVAL;
 
info = kzalloc(sizeof(struct ion_cma_buffer_info), GFP_KERNEL);
-   if (!info) {
-   dev_err(dev, "Can't allocate buffer info\n");
+   if (!info)
return ION_CMA_ALLOCATE_FAILED;
-   }
 
info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
GFP_HIGHUSER | __GFP_ZERO);
@@ -90,10 +88,8 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
}
 
info->table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
-   if (!info->table) {
-   dev_err(dev, "Fail to allocate sg table\n");
+   if (!info->table)
goto free_mem;
-   }
 
if (ion_cma_get_sgtable
(dev, info->table, info->cpu_addr, info->handle, len))
@@ -155,7 +151,6 @@ static struct sg_table *ion_cma_heap_map_dma(struct 
ion_heap *heap,
 static void ion_cma_heap_unmap_dma(struct ion_heap *heap,
   struct ion_buffer *buffer)
 {
-   return;
 }
 
 static int ion_cma_mmap(struct ion_heap *mapper, struct ion_buffer *buffer,
-- 
1.9.3

--
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: Arm Build Failing

[Roberto J. Dohnert]

It looks like its trying to invoke the native (x86) compiler, but 
passing it options that only make sense to an ARM compiler.


Cheers

Roberto J. Dohnert
Roberto J. Dohnert
Lead Developer
Black Lab Software Inc.
PO Box 698
Franklinton NC 27525
http://www.pc-opensystems.com
http://www.blacklablinux.org

On 07/20/2014 12:03 AM, Nick Krause wrote:

arm-linux-gnueabihf-gcc: error: unrecognized command line option ‘-m64’
arm-linux-gnueabihf-gcc: error: unrecognized command line option ‘-mno-mmx’
arm-linux-gnueabihf-gcc: error: unrecognized command line option ‘-mno-sse’
arm-linux-gnueabihf-gcc: error: unrecognized command line option ‘-mno-red-zone’
arm-linux-gnueabihf-gcc: error: unrecognized command line option
‘-mcmodel=kernel’
This happens every time I try to build new arch code this week. Is there a easy
fix for this?
Cheers Nick
--
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/2] Staging: comedi: adv_pci1710.c line over 80 fixed

[Greg KH]

On Sun, Jul 20, 2014 at 04:15:50AM +0300, Sam Asadi wrote:
> A line over 80 issue fixed, which is a comment.
> 
> Signed-off-by: Sam Asadi 
> ---
>  drivers/staging/comedi/drivers/adv_pci1710.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/comedi/drivers/adv_pci1710.c 
> b/drivers/staging/comedi/drivers/adv_pci1710.c
> index 602b7a1..13ff78c 100644
> --- a/drivers/staging/comedi/drivers/adv_pci1710.c
> +++ b/drivers/staging/comedi/drivers/adv_pci1710.c
> @@ -723,7 +723,8 @@ static int pci171x_ai_cancel(struct comedi_device *dev,
>   devpriv->CntrlReg &= Control_CNT0;
>   devpriv->CntrlReg |= Control_SW;
>  
> - outw(devpriv->CntrlReg, dev->iobase + PCI171x_CONTROL); /*  
> reset any operations */
> + outw(devpriv->CntrlReg, dev->iobase + PCI171x_CONTROL);
> + /* reset any operations */

That really doesn't make any sense now, does it?

Please put it _before_ the outw() call.

thanks,

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

[PATCH] arm: Fix me in bios32.c

[Nicholas Krause]

This fixs a fix me in bios32.c for pci_fixup_it8152 as this if
statement is incorrect needs to be checked against the class bits
not the whole address for the two or conditions and since they don't
have define statements outside of their numeratical value.

Signed-off-by: Nicholas Krause 
---
 arch/arm/kernel/bios32.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index 17a26c1..b2217af 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -254,11 +254,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CONTAQ, 
PCI_DEVICE_ID_CONTAQ_82C693, pci_
 static void pci_fixup_it8152(struct pci_dev *dev)
 {
int i;
-   /* fixup for ITE 8152 devices */
-   /* FIXME: add defines for class 0x68000 and 0x80103 */
if ((dev->class >> 8) == PCI_CLASS_BRIDGE_HOST ||
-   dev->class == 0x68000 ||
-   dev->class == 0x80103) {
+  (dev->class >> 8) == 0x680 ||
+  (dev->class >> 8) == 0x801) {
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
dev->resource[i].start = 0;
dev->resource[i].end   = 0;
-- 
1.9.1

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

Arm Build Failing

[Nick Krause]

arm-linux-gnueabihf-gcc: error: unrecognized command line option ‘-m64’
arm-linux-gnueabihf-gcc: error: unrecognized command line option ‘-mno-mmx’
arm-linux-gnueabihf-gcc: error: unrecognized command line option ‘-mno-sse’
arm-linux-gnueabihf-gcc: error: unrecognized command line option ‘-mno-red-zone’
arm-linux-gnueabihf-gcc: error: unrecognized command line option
‘-mcmodel=kernel’
This happens every time I try to build new arch code this week. Is there a easy
fix for this?
Cheers Nick
--
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 ftrace/core v3 2/3] ftrace, kprobes: Support IPMODIFY flag to find IP modify conflict

[Masami Hiramatsu]

(2014/07/18 22:51), Steven Rostedt wrote:
> On Fri, 18 Jul 2014 16:09:07 +0900
> Masami Hiramatsu  wrote:
> 
> 
>>> "The ops can modify the IP register. This can only be set along with
>>> SAVE_REGS. If another ops is already registered for any of the
>>> functions that this ops will be registered for, then this ops will fail
>>> to register."
>>
>> Not only register, but also set_filter_ip ;)
>> "...will fail to register or set_filter_ip."
> 
> Sure.
> 
> 
 diff --git a/kernel/kprobes.c b/kernel/kprobes.c
 index 3214289..e52d86f 100644
 --- a/kernel/kprobes.c
 +++ b/kernel/kprobes.c
>>>
>>> I think this should be split into two patches. One that adds the ftrace
>>> infrastructure, and the other that adds the kprobes user of the
>>> IPMODIFY flag.
>>
>> Hmm, I thought that it was natural to introduce new feature and its user
>> together, so that we could use git-bisect safely.
> 
> It should still be bisect friendly. That is, the feature is added
> before the user, not the user before the feature ;-)

Ah, I see.

> I know some people like the feature and user in one patch, but for me,
> when the user is in a different sub system (here it's kprobes) from the
> infrastructure that is changing (ftrace), I prefer separate patches.
> 
> The user patch shows me where the users are. When they are one patch, I
> tend to have them get lost.

OK, then I'll decouple it :)

Thanks!

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: [PATCH v2 1/3] perf/sdt : Listing of SDT markers by perf

[Masami Hiramatsu]

(2014/07/19 2:50), Andi Kleen wrote:
> Hemant Kumar  writes:
> 
> First I should say supporting these probes is very useful. Thanks for
> working on this.
> 
>> +
>> +#define SDT_CACHE_DIR "/var/cache/perf/"
> 
> This requires running perf as root, right?
> 
> It would be better to use the $HOME cache dir, like the recent JSON patches.

Even though, we have to enhance uprobe-tracer that allows non-root user
to add/remove events. :)
Anyway, I guess we can use ~/.debug for this purpose as buildid-cache does.

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: Re: [PATCH v2 0/3] perf/sdt : Support for SDT markers

[Masami Hiramatsu]

(2014/07/20 2:32), Hemant Kumar wrote:
>>> We have lots of applications which use SDT markers today, like:
>>> Postgresql, MySql, Mozilla, Perl, Python, Java, Ruby, libvirt, QEMU, glib
>>>
>>> To add SDT markers into user applications:
>>> We need to have this header sys/sdt.h present.
>>> sys/sdt.h used is version 3.
>>> If not present, install systemtap-sdt-devel package (for fedora-18).
>>>
>>> Please refer to the Documentation patch to see how the SDT markers are 
>>> added into
>>> a program.
>>>
>>> With this patchset,
>>> - Use perf to list the markers in the app:
>>> # perf list sdt ./user_app
>>>
>>> ./user_app :
>>> %user_app:foo_start
>>> %user_app:fun_start
>>>
>>> - Also, we can see the SDT markers present in our system in the usual 
>>> binaries.
>>> These usual binaries are libraries (dsos) listed by ldconfig --print-cache 
>>> and some
>>> binaries present in PATH environment variable.
>>>
>>> First, scan the binaries using :
>>> # perf list sdt --scan
>> At a glance, maybe we'd better have perf sdt-cache as like as perf 
>> buildid-cache
>> for manage sdt information. what would you think?
>>
> 
> I agree with you having perf sdt-cache similar to perf buildid-cache.
> But I think if the functionality of perf sdt-cache is only to build the 
> cache, then we can
> go with the perf list sdt --scan. Since, "perf list sdt" is used for 
> other purposes too, it
> should be less confusing for the users to just add another option 
> (--scan) to create/modify
> the cache. What do you suggest?

I think there may be some other cases, for example adding user local build
binary to the cache, or remove/update it locally. :)

And also, in user's mental model of perf-list, it doesn't take an "active"
action, that always does "passive" action. So adding such "active" scan option
will be more confusing.

But I also think it is OK that if the sdt is never scanned, the perf-list
automatically scans in background (without any option) or suggests user
to run "perf sdt-cache --scan". (it depends on how long time it may take)

To summarize it, I'd like to suggest adding below functions;

perf list sdt : shows all cached SDT events
perf list sdt  : shows SDT events in 
perf sdt-cache --scan/-s : scans all system binaries/libraries + added files
perf sdt-cache --add/-a  : add SDT events in  to cache
perf sdt-cache --remove/-r : remove SDT events in  from cache

And if perf list can't find sdt-cache, it would suggest to run
perf sdt-cache --scan or run it silently. :)

What would you think about this?

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


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

Re: Intel Graphics Drivers

[Nick Krause]

On Sat, Jul 19, 2014 at 8:45 PM, Roberto J. Dohnert  wrote:
> This would probably be a better question for the Intel developers than the
> kernel developers per say, but a great question nonetheless.  The Intel
> video drivers are perhaps the best supported on Linux. Most of the hardware
> I ship does ship with Intel cards so in regards to performance, this would
> be something I would like to see improve as well.
>
> Thanks,
>
> Roberto J. Dohnert
> Lead Developer
> Black Lab Software Inc.
> PO Box 698
> Franklinton NC 27525
> http://www.pc-opensystems.com
> http://www.blacklablinux.org
>
>
> On 07/19/2014 06:54 PM, Nick Krause wrote:
>>
>> On Sat, Jul 19, 2014 at 6:32 PM, Nick Krause  wrote:
>>   Hey Daniel and others ,
>>   If I am correct after asking around on the mailing list then  the
>> windows  Intel graphics drivers are faster then their Linux
>> counterparts.
>>   In addition , I  am wondering if we can improve this and try to
>> remove regressions in this area of graphics  support as this seems to
>> be
>>   the main issue and perhaps the hardware is hard to come by outside of
>> Intel or the board manufacturers as we seem to have no hardware
>>   for testing as I asked before . I don't have the hardware but if
>> people help do the hardware testing  and maybe a bit of advice and
>> guidance
>>   as I am new to the graphics stack in the kernel  I can help out  :).
>> If not that's Ok too just thought it may be of help.
>> Cheers Nick
>> P.S. Sorry about first email it wasn't edited. :(
>> --
>> 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/
>>
>

Our you sure there aren't Intel devolopers who do this on the lkml?
I do known however that the nvidia and amd drivers are being, while
not opened are being optimized for Linux and are now more stable
and faster in most benchmarks by like 20% only after four months
of development  on a gtx 780. I would like to see the same work
coming into the Intel drivers. Overall in terms of hardware support
we are way better then Windows expect for a few areas ,which
I will list below.
1. Nvidia Graphics can be faster then Windows( improving fast,
probably will happen in next few months)
Removed no overclocking support
2. Amd Graphics(same as above )
Removed no overclocking support
3.Intel Graphics(needs lots of work)
4. Printers and Scanners ( need more support from vendors)
5. Laptops( Mostly battery is shorter on a few laptops then in
Windows) and maybe hdmi and touchscreen  support?
   Otherwise we are good here and have removed are issues with  Nvidia
optimus not be supported
6. Gaming Mice and Keyboards

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

Re: [PATCH 5/7] firmware_class: extract start loading logic

[Ming Lei]

On Tue, Jul 15, 2014 at 5:38 AM, Kees Cook  wrote:
> Extract the logic performed when starting a new firmware load.
>
> Signed-off-by: Kees Cook 

Acked-by: Ming Lei 

> ---
>  drivers/base/firmware_class.c |   29 ++---
>  1 file changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 7399bab71ced..b38cbcd6ebb1 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -604,6 +604,23 @@ static int fw_map_pages_buf(struct firmware_buf *buf)
> return 0;
>  }
>
> +/* fw_lock must be held */
> +static void fw_load_start(struct firmware_buf *fw_buf)
> +{
> +   /* discarding any previous partial load */
> +   if (!test_bit(FW_STATUS_DONE, _buf->status)) {
> +   int i;
> +
> +   for (i = 0; i < fw_buf->nr_pages; i++)
> +   __free_page(fw_buf->pages[i]);
> +   kfree(fw_buf->pages);
> +   fw_buf->pages = NULL;
> +   fw_buf->page_array_size = 0;
> +   fw_buf->nr_pages = 0;
> +   set_bit(FW_STATUS_LOADING, _buf->status);
> +   }
> +}
> +
>  /**
>   * firmware_loading_store - set value in the 'loading' control file
>   * @dev: device pointer
> @@ -624,7 +641,6 @@ static ssize_t firmware_loading_store(struct device *dev,
> struct firmware_priv *fw_priv = to_firmware_priv(dev);
> struct firmware_buf *fw_buf;
> int loading = simple_strtol(buf, NULL, 10);
> -   int i;
>
> mutex_lock(_lock);
> fw_buf = fw_priv->buf;
> @@ -633,16 +649,7 @@ static ssize_t firmware_loading_store(struct device *dev,
>
> switch (loading) {
> case 1:
> -   /* discarding any previous partial load */
> -   if (!test_bit(FW_STATUS_DONE, _buf->status)) {
> -   for (i = 0; i < fw_buf->nr_pages; i++)
> -   __free_page(fw_buf->pages[i]);
> -   kfree(fw_buf->pages);
> -   fw_buf->pages = NULL;
> -   fw_buf->page_array_size = 0;
> -   fw_buf->nr_pages = 0;
> -   set_bit(FW_STATUS_LOADING, _buf->status);
> -   }
> +   fw_load_start(fw_buf);
> break;
> case 0:
> if (test_bit(FW_STATUS_LOADING, _buf->status)) {
> --
> 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/
--
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 6/7] firmware_class: add "fd" input file

[Ming Lei]

On Tue, Jul 15, 2014 at 5:38 AM, Kees Cook  wrote:
> As an alternative to loading bytes from the "data" blob when reading
> firmware, let kernel read from an fd, so that the LSM can reason about
> the origin of firmware contents during userspace on-demand loading.

>From user space view, maybe it is better to keep previous usage and just
check if loading is from 'data' blob or fd in 'echo 0 > loading' of
firmware_loading_store(), then the 'fd' usage becomes very similar with
before.

>
> Signed-off-by: Kees Cook 
> ---
>  Documentation/firmware_class/README |   10 +
>  drivers/base/firmware_class.c   |   77 
> ++-
>  2 files changed, 86 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/firmware_class/README 
> b/Documentation/firmware_class/README
> index 71f86859d7d8..d899bdacba1e 100644
> --- a/Documentation/firmware_class/README
> +++ b/Documentation/firmware_class/README
> @@ -59,6 +59,16 @@
>   8), kernel(driver): Driver code calls release_firmware(fw_entry) releasing
>  the firmware image and any related resource.
>
> + Alternative loading (via file descriptor):
> + ==
> + Instead of "loading", and "data" above, firmware can be loaded through
> + an open file descriptor as well, via the "fd" file:
> +
> + Replacing steps 2 thorugh 6 above with the following userspace actions,
> + performs the same loading:
> +   - open firmware image file (e.g. as fd 3).
> +   - write fd (e.g. "3") to /sys/class/firmware/xxx/fd.

Then as above, here should be just to replace step 4, 5 as
  - open image in user space
  - echo fd > /sys/class/firmware/xxx/fd

> +
>   High level behavior (driver code):
>   ==
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index b38cbcd6ebb1..eac996447d28 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -839,6 +839,70 @@ static struct bin_attribute firmware_attr_data = {
> .write = firmware_data_write,
>  };
>
> +/**
> + * fd_store - set value in the 'fd' control file
> + * @dev: device pointer
> + * @attr: device attribute pointer
> + * @buf: buffer to scan for loading fd value
> + * @count: number of bytes in @buf
> + *
> + * Parses an fd number from buf, and then loads firmware bytes from
> + * the current process's matching open fd.
> + *
> + **/
> +static ssize_t fd_store(struct device *dev,
> +struct device_attribute *attr,
> +const char *buf, size_t count)
> +{
> +   struct firmware_priv *fw_priv = to_firmware_priv(dev);
> +   struct firmware_buf *fw_buf = fw_priv->buf;
> +   ssize_t retval;
> +   int fd;
> +   struct fd f;
> +
> +   if (!capable(CAP_SYS_RAWIO))
> +   return -EPERM;
> +
> +   retval = kstrtoint(buf, 10, );
> +   if (retval)
> +   return retval;
> +
> +   f = fdget(fd);
> +   if (!f.file)
> +   return -EBADF;
> +
> +   mutex_lock(_lock);
> +   /* If we raced another loader, we must fail. */
> +   if (test_bit(FW_STATUS_DONE, _buf->status)) {
> +   retval = -EINVAL;
> +   goto unlock;
> +   }
> +
> +   fw_load_start(fw_buf);
> +   /* fw_read_file_contents uses vmalloc, not pages. */
> +   fw_buf->is_paged_buf = false;
> +   retval = fw_read_file_contents(f.file, fw_buf);
> +   if (retval) {
> +   /* If we called fw_load_start, we must abort on fail. */
> +   fw_load_abort(fw_priv);
> +   goto unlock;
> +   }
> +
> +   /* Success. */
> +   set_bit(FW_STATUS_DONE, _buf->status);
> +   list_del_init(_buf->pending_list);
> +   complete_all(_buf->completion);
> +
> +unlock:
> +   mutex_unlock(_lock);
> +   fdput(f);
> +
> +   if (retval)
> +   return retval;
> +   return count;
> +}
> +static DEVICE_ATTR_WO(fd);
> +
>  static void firmware_class_timeout_work(struct work_struct *work)
>  {
> struct firmware_priv *fw_priv = container_of(work,
> @@ -912,10 +976,19 @@ static int _request_firmware_load(struct firmware_priv 
> *fw_priv,
> mutex_lock(_lock);
> list_del_init(>pending_list);
> mutex_unlock(_lock);
> -   dev_err(f_dev, "%s: device_create_file failed\n", __func__);
> +   dev_err(f_dev, "%s: dev_attr_loading failed\n", __func__);
> goto err_del_bin_attr;
> }
>
> +   retval = device_create_file(f_dev, _attr_fd);
> +   if (retval) {
> +   mutex_lock(_lock);
> +   list_del_init(>pending_list);
> +   mutex_unlock(_lock);
> +   dev_err(f_dev, "%s: _attr_fd failed\n", __func__);
> +   goto err_del_loading;
> +   }
> +
> if (opt_flags & FW_OPT_UEVENT) {
> 

Re: [PATCH V3] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()

[Ethan Zhao]

hi,
   Regarding the r8169 chip, there is no other data fields exported to
user via ethtool
except for those dumped from hardware statistic counters in 8169 driver.

   But for Intel 82598 NIC and its driver ixgbe, it exports not only
those fields dumped from hardware statistic counters, like:

 {"rx_missed_errors", IXGB_NETDEV_STAT(stats.rx_missed_errors)},

also some info like following, these stats are collected from net core.

{"rx_packets", IXGB_NETDEV_STAT(stats.rx_packets)},
{"tx_packets", IXGB_NETDEV_STAT(stats.tx_packets)},
{"rx_bytes", IXGB_NETDEV_STAT(stats.rx_bytes)},
{"tx_bytes", IXGB_NETDEV_STAT(stats.tx_bytes)},
{"rx_errors", IXGB_NETDEV_STAT(stats.rx_errors)},
{"tx_errors", IXGB_NETDEV_STAT(stats.tx_errors)},
{"rx_dropped", IXGB_NETDEV_STAT(stats.rx_dropped)},
{"tx_dropped", IXGB_NETDEV_STAT(stats.tx_dropped)},


   As to netxen and its hardware.  does it have hardware statistic
counter ?  I don't care, As I know follow fields exported via ethtool
should be collected from software(net core / driver ):

{"xmit_called", NETXEN_NIC_STAT(stats.xmitcalled)},
{"xmit_finished", NETXEN_NIC_STAT(stats.xmitfinished)},
{"rx_dropped", NETXEN_NIC_STAT(stats.rxdropped)},
{"tx_dropped", NETXEN_NIC_STAT(stats.txdropped)},
{"csummed", NETXEN_NIC_STAT(stats.csummed)},

  So fix the rx_dropped field with my patch is the right way. the
patch is not intended to dump hardware statistic counters.


Thanks,
Ethan




On Sun, Jul 20, 2014 at 8:43 AM, Ethan Zhao  wrote:
>
>
>> 在 2014年7月20日，上午12:28，Francois Romieu  写道：
>>
>> Ethan Zhao  :
 On Sat, Jul 19, 2014 at 6:19 PM, Francois Romieu  
 wrote:
 Ethan Zhao  :
>> [...]
 I'd rather see ethtool stats provides one of those:
 1. hardware stats only
>>>  Sounds very clear, is it done clear, if so we need other tools ?
>>> Then why net core increase dev->dropped like
>>>
>>> atomic_long_inc(>dev->rx_dropped);
>>>
>>> and mess some of the info to dev. just let ifconfig report it without 
>>> detail ?
>>
>> (side note: ifconfig is a bit 90ish)
>>
>> Regarding the "without details" part, I don't expect ifconfig to tell users
>> that packets are dropped at net/core/dev.c:3279 because of empty softnet_data
>> queue in enqueue_to_backlog. More to the point below.
>>
>> [...]
 2. needs works. 1. hurts any requirement where it would priviously had
 been so easy to add a few lines of code in the driver and push the mess
 straight from kernel to the end user application.
>>>
>>>  Maybe some guys think that is enough to mess them together while not
>>> identify the information from net core or driver. that is better than
>>> lose info /no info.
>>
>> Probably.
>>
>>> My case is user could be confused when run 'ifconfig' and 'ethtool'
>>> to this netxen device. ifconfig reports packets dropped. but ethtool
>>> says zero. does that mean it is not issue of driver forever ?
>>
>> s/driver/hardware/
>>
>> Hardware correctly delivers packets if ethtool says zero [*]
>>
>> "correctly" must be understood in the context of said hardware abilities.
>>
>> [*] Of course we don't live in a world of unicorns and it's almost
>>unavoidable to check drivers's code to figure which stats are _really_
>>hardware only in ethtool output.
>>
>> A part of ethtool if close to bare metal abilities - including protocol
>> offloading related ones - whereas ifconfig provides a software oriented
>> vision of layer 2 operations.
>>
>> 
>> People at QLogic have not included *any* hardware counter in their
>> netxen ethtool stats code. Nada, keud. It's a bit deceptive for a gigabit
>> ethernet card and http://www.qlogic.com/Search/Pages/Search.aspx?k=NX2031
>> gives no hint.
>> 
>>
>> I won't claim it's intuitive. However:
>>
>> $ LANG=C man ifconfig
>> [...]
>> NOTE
>>   This  program  is obsolete!  For replacement check ip addr and ip link.
>>   For statistics use ip -s link.
>>
>> $ LANG=C man ip
>> [...]
>> -f, -family 
>>  Specifies the protocol family to use. The protocol family iden-
>>  tifier can be one of inet, inet6, bridge, ipx, dnet or link.  If
>>  this option is not present, the protocol family is guessed from
>>  other arguments.  If the rest of the command line does not give
>>  enough information to guess the family, ip falls back to the
>>  default one, usually inet or any.  link is a special family
>> 
>>  identifier meaning that no networking protocol is involved.
>>  ^^
>>
>> (huh, "special"...)
>>
>> $ LANG=C man ethtool
>> [...]
>>  -S --statistics
>>  Queries the specified network device for NIC- and driver-specif-
>>  ic statistics.
>>
>> Some code stands between drivers and the upper part of the topmost
>> no-networking-procol layer, whence the 

Re: [PATCH 1/7] doc: fix minor typos in firmware_class README

[Ming Lei]

On Tue, Jul 15, 2014 at 5:38 AM, Kees Cook  wrote:
> This is a tiny clean up for typos in the firmware_class README.
>
> Signed-off-by: Kees Cook 

Acked-by: Ming Lei 

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

[PATCH 2/2] Staging: comedi: adv_pci1710.c line over 80 fixed

[Sam Asadi]

A line over 80 issue fixed, which is a comment.

Signed-off-by: Sam Asadi 
---
 drivers/staging/comedi/drivers/adv_pci1710.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/adv_pci1710.c 
b/drivers/staging/comedi/drivers/adv_pci1710.c
index 602b7a1..13ff78c 100644
--- a/drivers/staging/comedi/drivers/adv_pci1710.c
+++ b/drivers/staging/comedi/drivers/adv_pci1710.c
@@ -723,7 +723,8 @@ static int pci171x_ai_cancel(struct comedi_device *dev,
devpriv->CntrlReg &= Control_CNT0;
devpriv->CntrlReg |= Control_SW;
 
-   outw(devpriv->CntrlReg, dev->iobase + PCI171x_CONTROL); /*  
reset any operations */
+   outw(devpriv->CntrlReg, dev->iobase + PCI171x_CONTROL);
+   /* reset any operations */
pci171x_start_pacer(dev, false);
outb(0, dev->iobase + PCI171x_CLRFIFO);
outb(0, dev->iobase + PCI171x_CLRINT);
-- 
1.9.1

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

Re: [PATCH 1/1] Staging: comedi: 8255.c Missing a blank line fixed

[Joe Perches]

On Sun, 2014-07-20 at 03:43 +0300, Sam Asadi wrote:
> A 'Missing a blank line after declarations' issue fixed and also tested
> by 'make M=...'. It seems that after 'unsigned long iobase' declaration
> a blank line is desperately needed.
[]
> diff --git a/drivers/staging/comedi/drivers/8255.c 
> b/drivers/staging/comedi/drivers/8255.c
[]
> @@ -94,6 +94,7 @@ I/O port base address can be found in the output of 'lspci 
> -v'.
>  
>  struct subdev_8255_private {
>   unsigned long iobase;
> +
>   int (*io)(int, int, int, unsigned long);
>  };
>  

You used an old version of checkpatch without a
modification to the "blank line after declarations"
test that supports function pointers.

Use the latest version from --next instead.

--
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 07/10] nohz: Enforce timekeeping on CPU 0

[Frederic Weisbecker]

On Sat, Jul 19, 2014 at 01:31:25PM -0400, Nicolas Pitre wrote:
> On Sat, 19 Jul 2014, Frederic Weisbecker wrote:
> 
> > The timekeeper gets initialized to the value of the CPU where the
> > first clockevent device is setup. This works well because the timekeeper
> > can be any online CPU in most configs.
> > 
> > Full dynticks has its own requirement though and needs the timekeeper
> > to always be 0. And this requirement seem to accomodate pretty well with
> > the above described boot timekeeper setting because the first clockevent
> > device happens to be initialized, most of the time, on the boot CPU
> > (which should be CPU 0).
> 
> This might have been discussed before... but this isn't ARM big.LITTLE 
> friendly at all.
> 
> Could we accommodate for any arbitrary CPU instead of making CPU 0 
> "special" other than its role as the boot CPU please?  It doesn't have 
> to be completely dynamic, but CPU 0 might be a really bad choice for 
> ongoing periodic duties in some configurations.  For example, we might 
> highly prefer to do this on CPU 4 for power efficiency reasons once it 
> is online and keep CPU 0 in a deep C-state as much as possible.

I can certainly arrange for setting user defined timekeeper on boot
time. Just one constraint: since the timekeeper is fixed, we can't
offline it. That's usually fine with CPU 0 but on other CPUs, rejecting
a CPU offlining blocks the suspend process.

I imagine I can handover the timekeeping to another CPU in this case
and accept the offlining. But there are chances that the only online
CPUs remaining are full dynticks and it's not tempting to give them
a timekeeping duty.
--
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 3/6] thermal: Added Bang-bang thermal governor

[Peter Feuerer]

The bang-bang thermal governor uses a hysteresis to switch abruptly on
or off a cooling device.  It is intended to control fans, which can
not be throttled but just switched on or off.
Bang-bang cannot be set as default governor as it is intended for
special devices only.  For those special devices the driver needs to
explicitely request it.

Cc: Andrew Morton 
Cc: Zhang Rui 
Cc: Andreas Mohr 
Cc: Borislav Petkov 
Cc: Javi Merino 
Signed-off-by: Peter Feuerer 
---
 drivers/thermal/Kconfig |  10 +++
 drivers/thermal/Makefile|   1 +
 drivers/thermal/gov_bang_bang.c | 131 
 drivers/thermal/thermal_core.c  |   5 ++
 drivers/thermal/thermal_core.h  |   8 +++
 5 files changed, 155 insertions(+)
 create mode 100644 drivers/thermal/gov_bang_bang.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index f9a1386..cdddf09 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -84,6 +84,16 @@ config THERMAL_GOV_STEP_WISE
  Enable this to manage platform thermals using a simple linear
  governor.
 
+config THERMAL_GOV_BANG_BANG
+   bool "Bang Bang thermal governor"
+   default y
+   help
+ Enable this to manage platform thermals using bang bang governor.
+
+ Say 'Y' here if you want to use two point temperature regulation
+ used for fans without throttling.  Some fan drivers depend on this
+ governor to be enabled (e.g. acerhdf).
+
 config THERMAL_GOV_USER_SPACE
bool "User_space thermal governor"
help
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index de0636a..a675980 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -11,6 +11,7 @@ thermal_sys-$(CONFIG_THERMAL_OF)  += of-thermal.o
 
 # governors
 thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE)   += fair_share.o
+thermal_sys-$(CONFIG_THERMAL_GOV_BANG_BANG)+= gov_bang_bang.o
 thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)+= step_wise.o
 thermal_sys-$(CONFIG_THERMAL_GOV_USER_SPACE)   += user_space.o
 
diff --git a/drivers/thermal/gov_bang_bang.c b/drivers/thermal/gov_bang_bang.c
new file mode 100644
index 000..c5dd76b
--- /dev/null
+++ b/drivers/thermal/gov_bang_bang.c
@@ -0,0 +1,131 @@
+/*
+ *  gov_bang_bang.c - A simple thermal throttling governor using hysteresis
+ *
+ *  Copyright (C) 2014 Peter Feuerer 
+ *
+ *  Based on step_wise.c with following Copyrights:
+ *  Copyright (C) 2012 Intel Corp
+ *  Copyright (C) 2012 Durgadoss R 
+ *
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
+ * the GNU General Public License for more details.
+ *
+ */
+
+#include 
+
+#include "thermal_core.h"
+
+static void thermal_zone_trip_update(struct thermal_zone_device *tz, int trip)
+{
+   long trip_temp;
+   unsigned long trip_hyst;
+   struct thermal_instance *instance;
+
+   tz->ops->get_trip_temp(tz, trip, _temp);
+   tz->ops->get_trip_hyst(tz, trip, _hyst);
+
+   dev_dbg(>device, "Trip%d[temp=%ld]:temp=%d:hyst=%ld\n",
+   trip, trip_temp, tz->temperature,
+   trip_hyst);
+
+   mutex_lock(>lock);
+
+   list_for_each_entry(instance, >thermal_instances, tz_node) {
+   if (instance->trip != trip)
+   continue;
+
+   /* in case fan is in initial state, switch the fan off */
+   if (instance->target == THERMAL_NO_TARGET)
+   instance->target = 0;
+
+   /* in case fan is neither on nor off set the fan to active */
+   if (instance->target != 0 && instance->target != 1) {
+   pr_warn("Thermal instance %s controlled by bang-bang 
has unexpected state: %ld\n",
+   instance->name, instance->target);
+   instance->target = 1;
+   }
+
+   /*
+* enable fan when temperature exceeds trip_temp and disable
+* the fan in case it falls below trip_temp minus hysteresis
+*/
+   if (instance->target == 0 && tz->temperature >= trip_temp)
+   instance->target = 1;
+   else if (instance->target == 1 &&
+   tz->temperature < trip_temp - trip_hyst)
+   instance->target = 0;
+
+   dev_dbg(>cdev->device, "target=%d\n",
+   (int)instance->target);
+
+   instance->cdev->updated = false; /* cdev needs update */
+   }
+
+   mutex_unlock(>lock);
+}
+
+/**
+ * 

[PATCH v4 5/6] acerhdf: added critical trip point

[Peter Feuerer]

added critical trip point which represents the temperature limit.
Added return -EINVAL in case wrong trip point is provided.

Cc: Andrew Morton 
Cc: Andreas Mohr 
Cc: Borislav Petkov 
Cc: Javi Merino 
Signed-off-by: Peter Feuerer 
---
 drivers/platform/x86/acerhdf.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index e8c3111..0d521ea 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -444,6 +444,10 @@ static int acerhdf_get_trip_type(struct 
thermal_zone_device *thermal, int trip,
 {
if (trip == 0)
*type = THERMAL_TRIP_ACTIVE;
+   else if (trip == 1)
+   *type = THERMAL_TRIP_CRITICAL;
+   else
+   return -EINVAL;
 
return 0;
 }
@@ -464,6 +468,10 @@ static int acerhdf_get_trip_temp(struct 
thermal_zone_device *thermal, int trip,
 {
if (trip == 0)
*temp = fanon;
+   else if (trip == 1)
+   *temp = ACERHDF_TEMP_CRIT;
+   else
+   return -EINVAL;
 
return 0;
 }
@@ -714,7 +722,7 @@ static int acerhdf_register_thermal(void)
if (IS_ERR(cl_dev))
return -EINVAL;
 
-   thz_dev = thermal_zone_device_register("acerhdf", 1, 0, NULL,
+   thz_dev = thermal_zone_device_register("acerhdf", 2, 0, NULL,
  _dev_ops,
  _zone_params, 0,
  (kernelmode) ? interval*1000 : 0);
-- 
2.0.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 v4 0/6] acerhdf/thermal: adding new models, appropriate governor and minor clean up

[Peter Feuerer]

Hi,

This patch series is intended to:

  * Introduce "manual mode" support (Patch 1 & 2), which is needed to control
the fan of a few new models.

  * Add an appropriate thermal governor (Patch 3 & 4).  Manipulating and
fiddling around with the step-wise governor has been a very fragile thing
in the past and as it broke again, I used the opportunity to add a two
point thermal governor which implements the actual fan handling required by
acerhdf and puts from my point of view things straight.

  * Do some minor clean up like:
  - adding second trip point for critical temperature (Patch 5)
  - removing _t suffix from struct which isn't typedef and replace unsigned
char by u8 (Patch 6)

Thanks and kind regards,
peter 

Peter Feuerer (6):
  acerhdf: Adding support for "manual mode"
  acerhdf: Adding support for new models
  thermal: Added Bang-bang thermal governor
  acerhdf: Use bang-bang thermal governor
  acerhdf: added critical trip point
  acerhdf: minor clean up

 drivers/platform/x86/Kconfig|   2 +-
 drivers/platform/x86/acerhdf.c  | 266 ++--
 drivers/thermal/Kconfig |  10 ++
 drivers/thermal/Makefile|   1 +
 drivers/thermal/gov_bang_bang.c | 131 
 drivers/thermal/thermal_core.c  |   5 +
 drivers/thermal/thermal_core.h  |   8 ++
 7 files changed, 327 insertions(+), 96 deletions(-)
 create mode 100644 drivers/thermal/gov_bang_bang.c

-- 
2.0.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 v4 6/6] acerhdf: minor clean up

[Peter Feuerer]

  * renamed bios_settings_t to bios_settings, as it is no typedef
  * replaced "unsigned char" by u8 in bios_settings struct for better
readability.

Cc: Andrew Morton 
Cc: Andreas Mohr 
Acked-by: Borislav Petkov 
Signed-off-by: Peter Feuerer 
---
 drivers/platform/x86/acerhdf.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 0d521ea..e608ef1 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -131,19 +131,19 @@ static const struct manualcmd mcmd = {
 };
 
 /* BIOS settings */
-struct bios_settings_t {
+struct bios_settings {
const char *vendor;
const char *product;
const char *version;
-   unsigned char fanreg;
-   unsigned char tempreg;
+   u8 fanreg;
+   u8 tempreg;
struct fancmd cmd;
int mcmd_enable;
 };
 
 
 /* Register addresses and values for different BIOS versions */
-static const struct bios_settings_t bios_tbl[] = {
+static const struct bios_settings bios_tbl[] = {
/* AOA110 */
{"Acer", "AOA110", "v0.3109", 0x55, 0x58, {0x1f, 0x00}, 0},
{"Acer", "AOA110", "v0.3114", 0x55, 0x58, {0x1f, 0x00}, 0},
@@ -257,7 +257,7 @@ static const struct bios_settings_t bios_tbl[] = {
{"", "", "", 0, 0, {0, 0}, 0}
 };
 
-static const struct bios_settings_t *bios_cfg __read_mostly;
+static const struct bios_settings *bios_cfg __read_mostly;
 
 /*
  * this struct is used to instruct thermal layer to use bang_bang instead of
@@ -620,7 +620,7 @@ static int str_starts_with(const char *str, const char 
*start)
 static int acerhdf_check_hardware(void)
 {
char const *vendor, *version, *product;
-   const struct bios_settings_t *bt = NULL;
+   const struct bios_settings *bt = NULL;
 
/* get BIOS data */
vendor  = dmi_get_system_info(DMI_SYS_VENDOR);
-- 
2.0.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 v4 4/6] acerhdf: Use bang-bang thermal governor

[Peter Feuerer]

acerhdf has been doing an on-off fan control using hysteresis by
post-manipulating the outcome of thermal subsystem trip point handling.
This patch enables acerhdf to use the bang-bang governor, which is
intended for on-off controlled fans.

Cc: Andrew Morton 
CC: Zhang Rui 
Cc: Andreas Mohr 
Cc: Borislav Petkov 
Cc: Javi Merino 
Signed-off-by: Peter Feuerer 
---
 drivers/platform/x86/Kconfig   |  2 +-
 drivers/platform/x86/acerhdf.c | 36 +++-
 2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 172f26c..d89252a 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -38,7 +38,7 @@ config ACER_WMI
 
 config ACERHDF
tristate "Acer Aspire One temperature and fan driver"
-   depends on THERMAL && ACPI
+   depends on ACPI && THERMAL_GOV_BANG_BANG
---help---
  This is a driver for Acer Aspire One netbooks. It allows to access
  the temperature sensor and to control the fan.
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 176edbd..e8c3111 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -50,7 +50,7 @@
  */
 #undef START_IN_KERNEL_MODE
 
-#define DRV_VER "0.5.30"
+#define DRV_VER "0.7.0"
 
 /*
  * According to the Atom N270 datasheet,
@@ -259,6 +259,14 @@ static const struct bios_settings_t bios_tbl[] = {
 
 static const struct bios_settings_t *bios_cfg __read_mostly;
 
+/*
+ * this struct is used to instruct thermal layer to use bang_bang instead of
+ * default governor for acerhdf
+ */
+static struct thermal_zone_params acerhdf_zone_params = {
+   .governor_name = "bang_bang",
+};
+
 static int acerhdf_get_temp(int *temp)
 {
u8 read_temp;
@@ -440,6 +448,17 @@ static int acerhdf_get_trip_type(struct 
thermal_zone_device *thermal, int trip,
return 0;
 }
 
+static int acerhdf_get_trip_hyst(struct thermal_zone_device *thermal, int trip,
+unsigned long *temp)
+{
+   if (trip != 0)
+   return -EINVAL;
+
+   *temp = fanon - fanoff;
+
+   return 0;
+}
+
 static int acerhdf_get_trip_temp(struct thermal_zone_device *thermal, int trip,
 unsigned long *temp)
 {
@@ -464,6 +483,7 @@ static struct thermal_zone_device_ops acerhdf_dev_ops = {
.get_mode = acerhdf_get_mode,
.set_mode = acerhdf_set_mode,
.get_trip_type = acerhdf_get_trip_type,
+   .get_trip_hyst = acerhdf_get_trip_hyst,
.get_trip_temp = acerhdf_get_trip_temp,
.get_crit_temp = acerhdf_get_crit_temp,
 };
@@ -516,9 +536,7 @@ static int acerhdf_set_cur_state(struct 
thermal_cooling_device *cdev,
}
 
if (state == 0) {
-   /* turn fan off only if below fanoff temperature */
-   if ((cur_state == ACERHDF_FAN_AUTO) &&
-   (cur_temp < fanoff))
+   if (cur_state == ACERHDF_FAN_AUTO)
acerhdf_change_fanstate(ACERHDF_FAN_OFF);
} else {
if (cur_state == ACERHDF_FAN_OFF)
@@ -697,11 +715,19 @@ static int acerhdf_register_thermal(void)
return -EINVAL;
 
thz_dev = thermal_zone_device_register("acerhdf", 1, 0, NULL,
- _dev_ops, NULL, 0,
+ _dev_ops,
+ _zone_params, 0,
  (kernelmode) ? interval*1000 : 0);
if (IS_ERR(thz_dev))
return -EINVAL;
 
+   if (strcmp(thz_dev->governor->name,
+   acerhdf_zone_params.governor_name)) {
+   pr_err("Didn't get thermal governor %s, perhaps not compiled 
into thermal subsystem.\n",
+   acerhdf_zone_params.governor_name);
+   return -EINVAL;
+   }
+
return 0;
 }
 
-- 
2.0.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 v4 1/6] acerhdf: Adding support for "manual mode"

[Peter Feuerer]

Some Acer models require an additional command to turn off the fan after
bios mode has been enabled.  Adding new section in bios table to allow
support for those models, by writing an extra "manual mode" register.

Cc: Andrew Morton 
Cc: Andreas Mohr 
Acked-by: Borislav Petkov 
Signed-off-by: Peter Feuerer 
---
 drivers/platform/x86/acerhdf.c | 187 +++--
 1 file changed, 103 insertions(+), 84 deletions(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index f94467c..dd63e93 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -50,7 +50,7 @@
  */
 #undef START_IN_KERNEL_MODE
 
-#define DRV_VER "0.5.26"
+#define DRV_VER "0.5.29"
 
 /*
  * According to the Atom N270 datasheet,
@@ -119,6 +119,17 @@ struct fancmd {
u8 cmd_auto;
 };
 
+struct manualcmd {
+   u8 mreg;
+   u8 moff;
+};
+
+/* default register and command to disable fan in manual mode */
+static const struct manualcmd mcmd = {
+   .mreg = 0x94,
+   .moff = 0xff,
+};
+
 /* BIOS settings */
 struct bios_settings_t {
const char *vendor;
@@ -127,105 +138,107 @@ struct bios_settings_t {
unsigned char fanreg;
unsigned char tempreg;
struct fancmd cmd;
+   int mcmd_enable;
 };
 
+
 /* Register addresses and values for different BIOS versions */
 static const struct bios_settings_t bios_tbl[] = {
/* AOA110 */
-   {"Acer", "AOA110", "v0.3109", 0x55, 0x58, {0x1f, 0x00} },
-   {"Acer", "AOA110", "v0.3114", 0x55, 0x58, {0x1f, 0x00} },
-   {"Acer", "AOA110", "v0.3301", 0x55, 0x58, {0xaf, 0x00} },
-   {"Acer", "AOA110", "v0.3304", 0x55, 0x58, {0xaf, 0x00} },
-   {"Acer", "AOA110", "v0.3305", 0x55, 0x58, {0xaf, 0x00} },
-   {"Acer", "AOA110", "v0.3307", 0x55, 0x58, {0xaf, 0x00} },
-   {"Acer", "AOA110", "v0.3308", 0x55, 0x58, {0x21, 0x00} },
-   {"Acer", "AOA110", "v0.3309", 0x55, 0x58, {0x21, 0x00} },
-   {"Acer", "AOA110", "v0.3310", 0x55, 0x58, {0x21, 0x00} },
+   {"Acer", "AOA110", "v0.3109", 0x55, 0x58, {0x1f, 0x00}, 0},
+   {"Acer", "AOA110", "v0.3114", 0x55, 0x58, {0x1f, 0x00}, 0},
+   {"Acer", "AOA110", "v0.3301", 0x55, 0x58, {0xaf, 0x00}, 0},
+   {"Acer", "AOA110", "v0.3304", 0x55, 0x58, {0xaf, 0x00}, 0},
+   {"Acer", "AOA110", "v0.3305", 0x55, 0x58, {0xaf, 0x00}, 0},
+   {"Acer", "AOA110", "v0.3307", 0x55, 0x58, {0xaf, 0x00}, 0},
+   {"Acer", "AOA110", "v0.3308", 0x55, 0x58, {0x21, 0x00}, 0},
+   {"Acer", "AOA110", "v0.3309", 0x55, 0x58, {0x21, 0x00}, 0},
+   {"Acer", "AOA110", "v0.3310", 0x55, 0x58, {0x21, 0x00}, 0},
/* AOA150 */
-   {"Acer", "AOA150", "v0.3114", 0x55, 0x58, {0x1f, 0x00} },
-   {"Acer", "AOA150", "v0.3301", 0x55, 0x58, {0x20, 0x00} },
-   {"Acer", "AOA150", "v0.3304", 0x55, 0x58, {0x20, 0x00} },
-   {"Acer", "AOA150", "v0.3305", 0x55, 0x58, {0x20, 0x00} },
-   {"Acer", "AOA150", "v0.3307", 0x55, 0x58, {0x20, 0x00} },
-   {"Acer", "AOA150", "v0.3308", 0x55, 0x58, {0x20, 0x00} },
-   {"Acer", "AOA150", "v0.3309", 0x55, 0x58, {0x20, 0x00} },
-   {"Acer", "AOA150", "v0.3310", 0x55, 0x58, {0x20, 0x00} },
+   {"Acer", "AOA150", "v0.3114", 0x55, 0x58, {0x1f, 0x00}, 0},
+   {"Acer", "AOA150", "v0.3301", 0x55, 0x58, {0x20, 0x00}, 0},
+   {"Acer", "AOA150", "v0.3304", 0x55, 0x58, {0x20, 0x00}, 0},
+   {"Acer", "AOA150", "v0.3305", 0x55, 0x58, {0x20, 0x00}, 0},
+   {"Acer", "AOA150", "v0.3307", 0x55, 0x58, {0x20, 0x00}, 0},
+   {"Acer", "AOA150", "v0.3308", 0x55, 0x58, {0x20, 0x00}, 0},
+   {"Acer", "AOA150", "v0.3309", 0x55, 0x58, {0x20, 0x00}, 0},
+   {"Acer", "AOA150", "v0.3310", 0x55, 0x58, {0x20, 0x00}, 0},
/* LT1005u */
-   {"Acer", "LT-10Q", "v0.3310", 0x55, 0x58, {0x20, 0x00} },
+   {"Acer", "LT-10Q", "v0.3310", 0x55, 0x58, {0x20, 0x00}, 0},
/* Acer 1410 */
-   {"Acer", "Aspire 1410", "v0.3108", 0x55, 0x58, {0x9e, 0x00} },
-   {"Acer", "Aspire 1410", "v0.3113", 0x55, 0x58, {0x9e, 0x00} },
-   {"Acer", "Aspire 1410", "v0.3115", 0x55, 0x58, {0x9e, 0x00} },
-   {"Acer", "Aspire 1410", "v0.3117", 0x55, 0x58, {0x9e, 0x00} },
-   {"Acer", "Aspire 1410", "v0.3119", 0x55, 0x58, {0x9e, 0x00} },
-   {"Acer", "Aspire 1410", "v0.3120", 0x55, 0x58, {0x9e, 0x00} },
-   {"Acer", "Aspire 1410", "v1.3204", 0x55, 0x58, {0x9e, 0x00} },
-   {"Acer", "Aspire 1410", "v1.3303", 0x55, 0x58, {0x9e, 0x00} },
-   {"Acer", "Aspire 1410", "v1.3308", 0x55, 0x58, {0x9e, 0x00} },
-   {"Acer", "Aspire 1410", "v1.3310", 0x55, 0x58, {0x9e, 0x00} },
-   {"Acer", "Aspire 1410", "v1.3314", 0x55, 0x58, {0x9e, 0x00} },
+   {"Acer", "Aspire 1410", "v0.3108", 0x55, 0x58, {0x9e, 0x00}, 0},
+   {"Acer", "Aspire 1410", "v0.3113", 0x55, 0x58, {0x9e, 0x00}, 0},
+   {"Acer", "Aspire 1410", "v0.3115", 0x55, 0x58, {0x9e, 0x00}, 0},
+   {"Acer", "Aspire 1410", "v0.3117", 0x55, 0x58, {0x9e, 0x00}, 0},
+  

[PATCH v4 2/6] acerhdf: Adding support for new models

[Peter Feuerer]

added following new models:
   * Aspire 5755G
   * AO521
   * AO751h
   * Aspire One 753
   * Extensa 5420
   * Aspire 5315
   * Aspire 5739G
   * TravelMate TM8573T

Cc: Andrew Morton 
Cc: Andreas Mohr 
Acked-by: Borislav Petkov 
Signed-off-by: Peter Feuerer 
---
 drivers/platform/x86/acerhdf.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index dd63e93..176edbd 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -50,7 +50,7 @@
  */
 #undef START_IN_KERNEL_MODE
 
-#define DRV_VER "0.5.29"
+#define DRV_VER "0.5.30"
 
 /*
  * According to the Atom N270 datasheet,
@@ -200,17 +200,33 @@ static const struct bios_settings_t bios_tbl[] = {
{"Acer", "Aspire 1810T",  "v1.3310", 0x55, 0x58, {0x9e, 0x00}, 0},
{"Acer", "Aspire 1810TZ", "v1.3314", 0x55, 0x58, {0x9e, 0x00}, 0},
{"Acer", "Aspire 1810T",  "v1.3314", 0x55, 0x58, {0x9e, 0x00}, 0},
+   /* Acer 5755G */
+   {"Acer", "Aspire 5755G",  "V1.20",   0xab, 0xb4, {0x00, 0x08}, 0},
+   {"Acer", "Aspire 5755G",  "V1.21",   0xab, 0xb3, {0x00, 0x08}, 0},
+   /* Acer 521 */
+   {"Acer", "AO521", "V1.11", 0x55, 0x58, {0x1f, 0x00}, 0},
/* Acer 531 */
{"Acer", "AO531h", "v0.3104", 0x55, 0x58, {0x20, 0x00}, 0},
{"Acer", "AO531h", "v0.3201", 0x55, 0x58, {0x20, 0x00}, 0},
{"Acer", "AO531h", "v0.3304", 0x55, 0x58, {0x20, 0x00}, 0},
/* Acer 751 */
+   {"Acer", "AO751h", "V0.3206", 0x55, 0x58, {0x21, 0x00}, 0},
{"Acer", "AO751h", "V0.3212", 0x55, 0x58, {0x21, 0x00}, 0},
+   /* Acer 753 */
+   {"Acer", "Aspire One 753", "V1.24", 0x93, 0xac, {0x14, 0x04}, 1},
/* Acer 1825 */
{"Acer", "Aspire 1825PTZ", "V1.3118", 0x55, 0x58, {0x9e, 0x00}, 0},
{"Acer", "Aspire 1825PTZ", "V1.3127", 0x55, 0x58, {0x9e, 0x00}, 0},
+   /* Acer Extensa 5420 */
+   {"Acer", "Extensa 5420", "V1.17", 0x93, 0xac, {0x14, 0x04}, 1},
+   /* Acer Aspire 5315 */
+   {"Acer", "Aspire 5315", "V1.19", 0x93, 0xac, {0x14, 0x04}, 1},
+   /* Acer Aspire 5739 */
+   {"Acer", "Aspire 5739G", "V1.3311", 0x55, 0x58, {0x20, 0x00}, 0},
/* Acer TravelMate 7730 */
{"Acer", "TravelMate 7730G", "v0.3509", 0x55, 0x58, {0xaf, 0x00}, 0},
+   /* Acer TravelMate TM8573T */
+   {"Acer", "TM8573T", "V1.13", 0x93, 0xa8, {0x14, 0x04}, 1},
/* Gateway */
{"Gateway", "AOA110", "v0.3103",  0x55, 0x58, {0x21, 0x00}, 0},
{"Gateway", "AOA150", "v0.3103",  0x55, 0x58, {0x20, 0x00}, 0},
@@ -742,9 +758,15 @@ MODULE_ALIAS("dmi:*:*Acer*:pnAOA*:");
 MODULE_ALIAS("dmi:*:*Acer*:pnAO751h*:");
 MODULE_ALIAS("dmi:*:*Acer*:pnAspire*1410*:");
 MODULE_ALIAS("dmi:*:*Acer*:pnAspire*1810*:");
+MODULE_ALIAS("dmi:*:*Acer*:pnAspire*5755G:");
 MODULE_ALIAS("dmi:*:*Acer*:pnAspire*1825PTZ:");
+MODULE_ALIAS("dmi:*:*Acer*:pnAO521*:");
 MODULE_ALIAS("dmi:*:*Acer*:pnAO531*:");
+MODULE_ALIAS("dmi:*:*Acer*:pnAspire*5739G:");
+MODULE_ALIAS("dmi:*:*Acer*:pnAspire*One*753:");
+MODULE_ALIAS("dmi:*:*Acer*:pnAspire*5315:");
 MODULE_ALIAS("dmi:*:*Acer*:TravelMate*7730G:");
+MODULE_ALIAS("dmi:*:*Acer*:TM8573T:");
 MODULE_ALIAS("dmi:*:*Gateway*:pnAOA*:");
 MODULE_ALIAS("dmi:*:*Gateway*:pnLT31*:");
 MODULE_ALIAS("dmi:*:*Packard*Bell*:pnAOA*:");
@@ -753,6 +775,7 @@ MODULE_ALIAS("dmi:*:*Packard*Bell*:pnDOTMU*:");
 MODULE_ALIAS("dmi:*:*Packard*Bell*:pnENBFT*:");
 MODULE_ALIAS("dmi:*:*Packard*Bell*:pnDOTMA*:");
 MODULE_ALIAS("dmi:*:*Packard*Bell*:pnDOTVR46*:");
+MODULE_ALIAS("dmi:*:*Acer*:pnExtensa 5420*:");
 
 module_init(acerhdf_init);
 module_exit(acerhdf_exit);
-- 
2.0.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: Intel Graphics Drivers

[Roberto J. Dohnert]

This would probably be a better question for the Intel developers than 
the kernel developers per say, but a great question nonetheless.  The 
Intel video drivers are perhaps the best supported on Linux. Most of the 
hardware I ship does ship with Intel cards so in regards to performance, 
this would be something I would like to see improve as well.


Thanks,

Roberto J. Dohnert
Lead Developer
Black Lab Software Inc.
PO Box 698
Franklinton NC 27525
http://www.pc-opensystems.com
http://www.blacklablinux.org

On 07/19/2014 06:54 PM, Nick Krause wrote:

On Sat, Jul 19, 2014 at 6:32 PM, Nick Krause  wrote:
  Hey Daniel and others ,
  If I am correct after asking around on the mailing list then  the
windows  Intel graphics drivers are faster then their Linux
counterparts.
  In addition , I  am wondering if we can improve this and try to
remove regressions in this area of graphics  support as this seems to
be
  the main issue and perhaps the hardware is hard to come by outside of
Intel or the board manufacturers as we seem to have no hardware
  for testing as I asked before . I don't have the hardware but if
people help do the hardware testing  and maybe a bit of advice and
guidance
  as I am new to the graphics stack in the kernel  I can help out  :).
If not that's Ok too just thought it may be of help.
Cheers Nick
P.S. Sorry about first email it wasn't edited. :(
--
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/

[PATCH 1/1] Staging: comedi: 8255.c Missing a blank line fixed

[Sam Asadi]

A 'Missing a blank line after declarations' issue fixed and also tested
by 'make M=...'. It seems that after 'unsigned long iobase' declaration
a blank line is desperately needed.

Signed-off-by: Sam Asadi 
---
 drivers/staging/comedi/drivers/8255.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/comedi/drivers/8255.c 
b/drivers/staging/comedi/drivers/8255.c
index 46113a3..e591441 100644
--- a/drivers/staging/comedi/drivers/8255.c
+++ b/drivers/staging/comedi/drivers/8255.c
@@ -94,6 +94,7 @@ I/O port base address can be found in the output of 'lspci 
-v'.
 
 struct subdev_8255_private {
unsigned long iobase;
+
int (*io)(int, int, int, unsigned long);
 };
 
-- 
1.9.1

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

Re: [PATCH V3] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()

[Ethan Zhao]

> 在 2014年7月20日，上午12:28，Francois Romieu  写道：
> 
> Ethan Zhao  :
>>> On Sat, Jul 19, 2014 at 6:19 PM, Francois Romieu  
>>> wrote:
>>> Ethan Zhao  :
> [...]
>>> I'd rather see ethtool stats provides one of those:
>>> 1. hardware stats only
>>  Sounds very clear, is it done clear, if so we need other tools ?
>> Then why net core increase dev->dropped like
>> 
>> atomic_long_inc(>dev->rx_dropped);
>> 
>> and mess some of the info to dev. just let ifconfig report it without detail 
>> ?
> 
> (side note: ifconfig is a bit 90ish)
> 
> Regarding the "without details" part, I don't expect ifconfig to tell users
> that packets are dropped at net/core/dev.c:3279 because of empty softnet_data
> queue in enqueue_to_backlog. More to the point below.
> 
> [...]
>>> 2. needs works. 1. hurts any requirement where it would priviously had
>>> been so easy to add a few lines of code in the driver and push the mess
>>> straight from kernel to the end user application.
>> 
>>  Maybe some guys think that is enough to mess them together while not
>> identify the information from net core or driver. that is better than
>> lose info /no info.
> 
> Probably.
> 
>> My case is user could be confused when run 'ifconfig' and 'ethtool'
>> to this netxen device. ifconfig reports packets dropped. but ethtool
>> says zero. does that mean it is not issue of driver forever ?
> 
> s/driver/hardware/
> 
> Hardware correctly delivers packets if ethtool says zero [*]
> 
> "correctly" must be understood in the context of said hardware abilities.
> 
> [*] Of course we don't live in a world of unicorns and it's almost
>unavoidable to check drivers's code to figure which stats are _really_
>hardware only in ethtool output.
> 
> A part of ethtool if close to bare metal abilities - including protocol
> offloading related ones - whereas ifconfig provides a software oriented
> vision of layer 2 operations.
> 
> 
> People at QLogic have not included *any* hardware counter in their
> netxen ethtool stats code. Nada, keud. It's a bit deceptive for a gigabit
> ethernet card and http://www.qlogic.com/Search/Pages/Search.aspx?k=NX2031
> gives no hint.
> 
> 
> I won't claim it's intuitive. However:
> 
> $ LANG=C man ifconfig
> [...]
> NOTE
>   This  program  is obsolete!  For replacement check ip addr and ip link.
>   For statistics use ip -s link.
> 
> $ LANG=C man ip
> [...]
> -f, -family 
>  Specifies the protocol family to use. The protocol family iden-
>  tifier can be one of inet, inet6, bridge, ipx, dnet or link.  If
>  this option is not present, the protocol family is guessed from
>  other arguments.  If the rest of the command line does not give
>  enough information to guess the family, ip falls back to the
>  default one, usually inet or any.  link is a special family
> 
>  identifier meaning that no networking protocol is involved.
>  ^^
> 
> (huh, "special"...)
> 
> $ LANG=C man ethtool
> [...]
>  -S --statistics
>  Queries the specified network device for NIC- and driver-specif-
>  ic statistics.
> 
> Some code stands between drivers and the upper part of the topmost
> no-networking-procol layer, whence the differing stats: they are not
> the same thing. Users can understand it.
> 
>> who could tell where the packets are dropped, and for what ?
> 
> One can't always answer beyond some coarse implementation level. There is
> no such thing as a kernel MIB for the net core internal details.
> 
> Would you disagree that some of those - rx_dropped locations for instance -
> are better kept in the scope of debug and trace utilities ?
> 
Of course I disagree it is the scope of debug and trace utilities. That is not 
fair or the original purpose the dropped info was collected into dev - >stat, 
it is dev specific


>> So I would like the name of the data fields that ethtool output is be
>> better defined. Instead of saying is not covered by ethtool.
> 
> I respectfully disagree.
> 
> ethtool and ip are two different tools.

you leave us without a tool to track the net core part. Would you like to hack 
the kernel code and rebuild just for peek the dropping packets ?
> 
> Regarding netxen driver, I do not want more ip / ifconfig stats in
> ethtool code. It's quite the opposite: netxen ethtool code has no
> business duplicating those and it should instead focus on real hardware
You are ignoring the implementation fact of many drivers' ethtool part.  You 
should persuade the authors of those drivers to delete those unrelated part in 
their ethtool code,
More radically, and maybe you should write patches to fix them to keep their 
focus. That is to prove you have principle and always fight for it.



Thanks,
Ethan
> stats. 
> 
> -- 
> Ueimor
--
To unsubscribe from this list: send the line 

Re: [PATCH tip/core/rcu] Do not keep timekeeping CPU tick running for non-nohz_full= CPUs

[Frederic Weisbecker]

2014-07-19 20:28 GMT+02:00 Peter Zijlstra :
> On Sat, Jul 19, 2014 at 08:01:24PM +0200, Frederic Weisbecker wrote:
>> This can be changed by allowing timekeeping duty from all non-nohz_full 
>> CPUs, that's
>> the initial direction I took, but it involved a lot of complications and 
>> scalability
>> issues.
>
> How so, currently any CPU can be timekeeper, how is any !nohz_full cpu
> different?

If timekeeping becomes a movable target in nohz full then we need to
make rcu_sys_is_idle() callable concurrently and we must send the
timekeeping-wakeup IPI to a possibly moving target. All that is a
predictable nightmare both in terms of complexity and scalability.

That's the direction I took initially
(https://lkml.org/lkml/2013/12/17/708) but I quickly resigned. The
changestat needed to be doubled to do it correctly. Moreover having
non-nohz-full CPUs other than CPU 0 is expected to be a corner case. A
corner case for a barely used feature (nohz full) as of today.

Also you might want to read tglx opinion on movable timekeepers in
nohz full: 
http://marc.info/?i=alpine.DEB.2.02.1405092358390.6261%40ionos.tec.linutronix.de
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] xen/setup: Remap Xen Identity Mapped RAM

[Matthew Rushton]

On 07/08/14 08:57, Konrad Rzeszutek Wilk wrote:

Responding :-)


@@ -797,10 +794,9 @@ unsigned long __init set_phys_range_identity(unsigned long 
pfn_s,
if (!__set_phys_to_machine(pfn, IDENTITY_FRAME(pfn)))
break;
-   if (!WARN((pfn - pfn_s) != (pfn_e - pfn_s),
+   WARN((pfn - pfn_s) != (pfn_e - pfn_s),
"Identity mapping failed. We are %ld short of 1-1 mappings!\n",
-   (pfn_e - pfn_s) - (pfn - pfn_s)))
-   printk(KERN_DEBUG "1-1 mapping on %lx->%lx\n", pfn_s, pfn);
+   (pfn_e - pfn_s) - (pfn - pfn_s));

I would leave that as is. If you really want to modify it - spin another
patch for it.

The problem is because we now call set_phys_range_identity() on small blocks
the number of these messages printed is large. I can split it out to a
separate patch if you'd like.

Please do. Also you would have to rebase all this code on the latest Linus's
tree as there are some changes there.


I posted a v2 which split this patch out, addressed feedback and rebased 
on Linus's tree.




return pfn - pfn_s;
  }
diff --git a/arch/x86/xen/p2m.h b/arch/x86/xen/p2m.h
new file mode 100644
index 000..9ce4d51
--- /dev/null
+++ b/arch/x86/xen/p2m.h
@@ -0,0 +1,15 @@
+#ifndef _XEN_P2M_H
+#define _XEM_P2M_H
+
+#define P2M_PER_PAGE(PAGE_SIZE / sizeof(unsigned long))
+#define P2M_MID_PER_PAGE(PAGE_SIZE / sizeof(unsigned long *))
+#define P2M_TOP_PER_PAGE(PAGE_SIZE / sizeof(unsigned long **))
+
+#define MAX_P2M_PFN (P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * 
P2M_PER_PAGE)
+
+#define MAX_REMAP_RANGES10

Could you mention why 10 please?

10 is simply what I thought a reasonable max could ever be for the number of
remapped ranges. A range here is defined as the combination of a contiguous
e820 I/O range and a contiguous e820 RAM range where the underlying I/O
memory will be remapped. I'm not really excited about this but I don't have
a better solution. Any ideas? I believe the original implementation has a
similar issue that it appears to ignore.

Is that based on a worst case scenario? As in could you write in the comment
an example of a worst case E820 and scenario and when would 10 be more than
enough to cover it?



I changed reserved brk space slightly in my updated patch. Really 
MAX_REMAP_RANGES in the worst case should be E820MAX. That seems like an 
unrealistic worst case though and a lot of space to reserve. I'm fairly 
certain the existing code also has a similar worst case which it doesn't 
take into account. It currently seems to assume there is only one E820 
I/O region that will be identity mapped? I think it works because in 
practice we don't come close to the worst case. I'm still not sure how 
to best handle this.



+   mod = remap_pfn % P2M_PER_PAGE;
+   remap_start_pfn_align =
+   mod ? (remap_pfn - mod + P2M_PER_PAGE):remap_pfn;
+   mod = (start_pfn + size) % P2M_PER_PAGE;
+   ident_end_pfn_align = start_pfn + size - mod;
+   mod = (remap_pfn + size) % P2M_PER_PAGE;
+   remap_end_pfn_align = remap_pfn + size - mod;

Should you do a check to make sure that 'ident_[start|end]_pfn_align'
don't overlap with 'remap_[start|end]_pfn_align' ?


+
+   /* Iterate over each p2m leaf node in each range */
+   for (ident_pfn_iter = ident_start_pfn_align, remap_pfn_iter = 
remap_start_pfn_align;
+ident_pfn_iter < ident_end_pfn_align && remap_pfn_iter < 
remap_end_pfn_align;
+ident_pfn_iter += P2M_PER_PAGE, remap_pfn_iter += P2M_PER_PAGE) {
+   /* Check we aren't past the end */
+   BUG_ON(ident_pfn_iter + P2M_PER_PAGE > start_pfn + size);
+   BUG_ON(remap_pfn_iter + P2M_PER_PAGE > remap_pfn + size);

Ah, here you check for it. But wouldn't it be easier to adjust the
remap_[start|end]_pfn_align above to check for this and make changes?

The ident_* and remap_* address ranges will never overlap each other unless
the e820 map is broken. I'm treating both ranges as independent and

Right.

iterating over each seperately at the same time. Each range will have
different boundary conditions potentially. Does that make sense? Am I
understanding the comment correctly?

I was thinking that if the E820 is broken then try our best (and stop
trying to remap) and continue. The E820 is guaranteed to be sane (no
overlapping regions), but the sizes could be bogus (zero size for example).


I think the current code does handle the zero case ok.


+
+   /* Save p2m mappings */
+   for (i = 0; i < P2M_PER_PAGE; i++)
+   xen_remap_buf[i] = pfn_to_mfn(ident_pfn_iter + i);
+
+   /* Set identity map which also frees a p2m leaf */

^- might

Under what conditions is this not true? The goal of processing these in
blocks is to guarantee that a leaf is freed.

Perhaps change it 'also frees' to 'MUST free'
and then 

Re: [PATCH] gpio:gpio-pl2303: add gpio driver for GPIOs on PL2303

[Greg KH]

On Sun, Jul 20, 2014 at 08:01:31AM +0800, Wang YanQing wrote:
> PL2303HX has two GPIOs, this patch add driver for it.
> 
> Signed-off-by: Wang YanQing 
> ---
>  MAINTAINERS |   5 +
>  drivers/gpio/Kconfig|   7 ++
>  drivers/gpio/Makefile   |   1 +
>  drivers/gpio/gpio-pl2303.c  | 238 
> 
>  drivers/usb/serial/pl2303.c |  19 
>  5 files changed, 270 insertions(+)
>  create mode 100644 drivers/gpio/gpio-pl2303.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 53feaaf..4a9d764 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6903,6 +6903,11 @@ F: drivers/i2c/busses/i2c-puv3.c
>  F:   drivers/video/fb-puv3.c
>  F:   drivers/rtc/rtc-puv3.c
>  
> +PL2303 GPIO DRIVER
> +M:   Wang YanQing 
> +S:   Maintained
> +F:   drivers/gpio/gpio-pl2303.c
> +
>  PMBUS HARDWARE MONITORING DRIVERS
>  M:   Guenter Roeck 
>  L:   lm-sens...@lm-sensors.org
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 4a1b511..0f90950 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -110,6 +110,13 @@ config GPIO_DA9055
>  config GPIO_MAX730X
>   tristate
>  
> +config GPIO_PL2303
> + tristate "USB Prolific 2303 gpio support"
> + depends on USB_SERIAL_PL2303
> + help
> +   Enable support for GPIOs on USB Prolific 2303
> +   It support two GPIOs on PL2303HX currently.
> +
>  comment "Memory mapped GPIO drivers:"
>  
>  config GPIO_CLPS711X
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index d10f6a9..4ff59f6 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -101,3 +101,4 @@ obj-$(CONFIG_GPIO_WM8994) += gpio-wm8994.o
>  obj-$(CONFIG_GPIO_XILINX)+= gpio-xilinx.o
>  obj-$(CONFIG_GPIO_XTENSA)+= gpio-xtensa.o
>  obj-$(CONFIG_GPIO_ZEVIO) += gpio-zevio.o
> +obj-$(CONFIG_GPIO_PL2303)+= gpio-pl2303.o
> diff --git a/drivers/gpio/gpio-pl2303.c b/drivers/gpio/gpio-pl2303.c
> new file mode 100644
> index 000..a703440
> --- /dev/null
> +++ b/drivers/gpio/gpio-pl2303.c
> @@ -0,0 +1,238 @@
> +/*
> + * PL2303 GPIO driver
> + *
> + * Copyright (C) 2014 Wang YanQing 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * Check pl2303.c for further details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define VENDOR_READ_REQUEST_TYPE 0xc0
> +#define VENDOR_READ_REQUEST  0x01
> +
> +#define VENDOR_WRITE_REQUEST_TYPE0x40
> +#define VENDOR_WRITE_REQUEST 0x01
> +
> +struct pl2303_gpio_data {
> + struct usb_device *pl2303;
> + /*
> +  * 0..3: unknown (zero)
> +  * 4: gp0 output enable (1: gp0 pin is output, 0: gp0 pin is input)
> +  * 5: gp1 output enable (1: gp1 pin is output, 0: gp1 pin is input)
> +  * 6: gp0 pin value
> +  * 7: gp1 pin value
> +  */
> + u8 index;
> + struct gpio_chip gpio_chip;
> +};
> +
> +static inline struct pl2303_gpio_data *to_pl2303_gpio(struct gpio_chip *chip)
> +{
> + return container_of(chip, struct pl2303_gpio_data, gpio_chip);
> +}
> +
> +static int pl2303_gpio_read(struct gpio_chip *chip, unsigned char buf[1])
> +{
> + struct pl2303_gpio_data *pl2303_gpio = to_pl2303_gpio(chip);
> + struct usb_device *pl2303 = pl2303_gpio->pl2303;
> + struct device *dev = chip->dev;
> + int res;
> +
> + res = usb_control_msg(pl2303, usb_rcvctrlpipe(pl2303, 0),
> + VENDOR_READ_REQUEST, VENDOR_READ_REQUEST_TYPE,
> + 0x0081, 0, buf, 1, 100);
> + if (res != 1) {
> + dev_err(dev, "%s - failed to read [%04x]: %d\n", __func__,
> + 0x0081, res);
> + if (res >= 0)
> + res = -EIO;
> +
> + return res;
> + }
> +
> + dev_dbg(dev, "%s - [%04x] = %02x\n", __func__, 0x0081, buf[0]);
> +
> + return 0;
> +}
> +
> +static int pl2303_gpio_write(struct gpio_chip *chip)
> +{
> + struct pl2303_gpio_data *pl2303_gpio = to_pl2303_gpio(chip);
> + struct usb_device *pl2303 = pl2303_gpio->pl2303;
> + struct device *dev = chip->dev;
> + int res;
> +
> + dev_dbg(dev, "%s - [%04x] = %02x\n", __func__, 1, pl2303_gpio->index);
> +
> + res = usb_control_msg(pl2303, usb_sndctrlpipe(pl2303, 0),
> + VENDOR_WRITE_REQUEST, VENDOR_WRITE_REQUEST_TYPE,
> + 1, pl2303_gpio->index, NULL, 0, 100);
> + if (res) {
> + dev_err(dev, "%s - failed to write [%04x] = %02x: %d\n", 
> __func__,
> + 1, pl2303_gpio->index, res);
> + return res;
> + }
> +
> + return 0;
> +}
> +
> +static int pl2303_gpio_direction_in(struct gpio_chip *chip, unsigned offset)
> +{
> + struct pl2303_gpio_data 

[PATCH v2 2/2] xen/setup: Remap Xen Identity Mapped RAM

[Matt Rushton]

Instead of ballooning up and down dom0 memory this remaps the existing mfns
that were replaced by the identity map. The reason for this is that the
existing implementation ballooned memory up and and down which caused dom0
to have discontiguous pages. In some cases this resulted in the use of bounce
buffers which reduced network I/O performance significantly. This change will
honor the existing order of the pages with the exception of some boundary
conditions.

To do this we need to update both the Linux p2m table and the Xen m2p table.
Particular care must be taken when updating the p2m table since it's important
to limit table memory consumption and reuse the existing leaf pages which get
freed when an entire leaf page is set to the identity map. To implement this,
mapping updates are grouped into blocks with table entries getting cached
temporarily and then released.

On my test system before:
Total pages: 2105014
Total contiguous: 1640635

After:
Total pages: 2105014
Total contiguous: 2098904

Signed-off-by: Matthew Rushton 
---
 arch/x86/xen/p2m.c   |   23 +---
 arch/x86/xen/p2m.h   |   15 ++
 arch/x86/xen/setup.c |  370 +++---
 3 files changed, 314 insertions(+), 94 deletions(-)
 create mode 100644 arch/x86/xen/p2m.h

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 3172692..9f5983b 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -173,6 +173,7 @@
 #include 
 #include 
 
+#include "p2m.h"
 #include "multicalls.h"
 #include "xen-ops.h"
 
@@ -180,12 +181,6 @@ static void __init m2p_override_init(void);
 
 unsigned long xen_max_p2m_pfn __read_mostly;
 
-#define P2M_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long))
-#define P2M_MID_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long *))
-#define P2M_TOP_PER_PAGE   (PAGE_SIZE / sizeof(unsigned long **))
-
-#define MAX_P2M_PFN(P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * 
P2M_PER_PAGE)
-
 /* Placeholders for holes in the address space */
 static RESERVE_BRK_ARRAY(unsigned long, p2m_missing, P2M_PER_PAGE);
 static RESERVE_BRK_ARRAY(unsigned long *, p2m_mid_missing, P2M_MID_PER_PAGE);
@@ -202,16 +197,12 @@ static RESERVE_BRK_ARRAY(unsigned long, 
p2m_mid_identity_mfn, P2M_MID_PER_PAGE);
 RESERVE_BRK(p2m_mid, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * 
P2M_MID_PER_PAGE)));
 RESERVE_BRK(p2m_mid_mfn, PAGE_SIZE * (MAX_DOMAIN_PAGES / (P2M_PER_PAGE * 
P2M_MID_PER_PAGE)));
 
-/* We might hit two boundary violations at the start and end, at max each
- * boundary violation will require three middle nodes. */
-RESERVE_BRK(p2m_mid_extra, PAGE_SIZE * 2 * 3);
-
-/* When we populate back during bootup, the amount of pages can vary. The
- * max we have is seen is 395979, but that does not mean it can't be more.
- * Some machines can have 3GB I/O holes even. With early_can_reuse_p2m_middle
- * it can re-use Xen provided mfn_list array, so we only need to allocate at
- * most three P2M top nodes. */
-RESERVE_BRK(p2m_populated, PAGE_SIZE * 3);
+/* For each I/O range remapped we may lose up to two leaf pages for the 
boundary
+ * violations and three mid pages to cover up to 3GB. With
+ * early_can_reuse_p2m_middle() most of the leaf pages will be reused by the
+ * remapped region.
+ */
+RESERVE_BRK(p2m_identity_remap, PAGE_SIZE * 2 * 3 * MAX_REMAP_RANGES);
 
 static inline unsigned p2m_top_index(unsigned long pfn)
 {
diff --git a/arch/x86/xen/p2m.h b/arch/x86/xen/p2m.h
new file mode 100644
index 000..ad8aee2
--- /dev/null
+++ b/arch/x86/xen/p2m.h
@@ -0,0 +1,15 @@
+#ifndef _XEN_P2M_H
+#define _XEN_P2M_H
+
+#define P2M_PER_PAGE(PAGE_SIZE / sizeof(unsigned long))
+#define P2M_MID_PER_PAGE(PAGE_SIZE / sizeof(unsigned long *))
+#define P2M_TOP_PER_PAGE(PAGE_SIZE / sizeof(unsigned long **))
+
+#define MAX_P2M_PFN (P2M_TOP_PER_PAGE * P2M_MID_PER_PAGE * 
P2M_PER_PAGE)
+
+#define MAX_REMAP_RANGES10
+
+extern unsigned long __init set_phys_range_identity(unsigned long pfn_s,
+  unsigned long pfn_e);
+
+#endif  /* _XEN_P2M_H */
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index 2e555163..a58f16a 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -29,6 +29,7 @@
 #include 
 #include "xen-ops.h"
 #include "vdso.h"
+#include "p2m.h"
 
 /* These are code, but not functions.  Defined in entry.S */
 extern const char xen_hypervisor_callback[];
@@ -46,6 +47,9 @@ struct xen_memory_region 
xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
 /* Number of pages released from the initial allocation. */
 unsigned long xen_released_pages;
 
+/* Buffer used to remap identity mapped pages */
+unsigned long xen_remap_buf[P2M_PER_PAGE] __initdata;
+
 /* 
  * The maximum amount of extra memory compared to the base size.  The
  * main scaling factor is the size of struct page.  At extreme ratios
@@ -151,107 +155,325 @@ static unsigned long __init xen_do_chunk(unsigned long 
start,
return len;
 }
 
-static unsigned long __init 

[PATCH v2 1/2] xen/setup: Remove Identity Map Debug Message

[Matt Rushton]

Removing a debug message for setting the identity map since it becomes
rather noisy after rework of the identity map code.

Signed-off-by: Matthew Rushton 
---
 arch/x86/xen/p2m.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 9bb3d82..3172692 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -841,10 +841,9 @@ unsigned long __init set_phys_range_identity(unsigned long 
pfn_s,
pfn = ALIGN(pfn, P2M_PER_PAGE);
}
 
-   if (!WARN((pfn - pfn_s) != (pfn_e - pfn_s),
+   WARN((pfn - pfn_s) != (pfn_e - pfn_s),
"Identity mapping failed. We are %ld short of 1-1 mappings!\n",
-   (pfn_e - pfn_s) - (pfn - pfn_s)))
-   printk(KERN_DEBUG "1-1 mapping on %lx->%lx\n", pfn_s, pfn);
+   (pfn_e - pfn_s) - (pfn - pfn_s));
 
return pfn - pfn_s;
 }
-- 
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/

[PATCHv2] block: Add support for Sony SxS cards

[Kieran Kunhya]

Signed-off-by: Kieran Kunhya 
---
 drivers/block/Kconfig  |9 +
 drivers/block/Makefile |1 +
 drivers/block/sxs.c|  491 
 3 files changed, 501 insertions(+)
 create mode 100644 drivers/block/sxs.c

diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 014a1cf..8ebb655 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -356,6 +356,15 @@ config BLK_DEV_SX8
 
  Use devices /dev/sx8/$N and /dev/sx8/$Np$M.
 
+config BLK_DEV_SXS
+   tristate "Sony SxS card support"
+   depends on PCI
+   ---help---
+ Saying Y or M here will enable support for reading
+ from Sony SxS cards.
+
+ It creates a device called /dev/sxs
+
 config BLK_DEV_RAM
tristate "RAM block device support"
---help---
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 02b688d..59b9c79 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_VIRTIO_BLK)  += virtio_blk.o
 
 obj-$(CONFIG_BLK_DEV_SX8)  += sx8.o
 obj-$(CONFIG_BLK_DEV_HD)   += hd.o
+obj-$(CONFIG_BLK_DEV_SXS)  += sxs.o
 
 obj-$(CONFIG_XEN_BLKDEV_FRONTEND)  += xen-blkfront.o
 obj-$(CONFIG_XEN_BLKDEV_BACKEND)   += xen-blkback/
diff --git a/drivers/block/sxs.c b/drivers/block/sxs.c
new file mode 100644
index 000..88ccd61
--- /dev/null
+++ b/drivers/block/sxs.c
@@ -0,0 +1,491 @@
+/*
+ *  sxs.c: Driver for Sony SxS cards
+ *
+ *  Copyright 2014 Kieran Kunhya
+ *
+ *  Author/maintainer:  Kieran Kunhya 
+ *
+ *  This file is subject to the terms and conditions of the GNU General Public
+ *  License.  See the file "COPYING" in the main directory of this archive
+ *  for more details.
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRV_NAME "sxs"
+
+#define PCI_DEVICE_ID_SXS_81CE 0x81ce
+#define PCI_DEVICE_ID_SXS_905C 0x905c
+
+#define SXS_MASTER_LINK_REG_L 0x10
+#define SXS_MASTER_LINK_REG_H 0x14
+#define SXS_MASTER_ADDR_REG_L 0x18
+#define SXS_MASTER_ADDR_REG_H 0x1c
+#define SXS_MASTER_SIZE_REG   0x20
+#define SXS_ENABLE_REG  0x28
+#define SXS_CONTROL_REG 0x2c
+#define SXS_STATUS_REG  0x6c
+#define SXS_RESPONSE_BUF 0x40
+
+#define KERNEL_SECTOR_SIZE 512
+
+static struct pci_device_id ids[] = {
+   { PCI_DEVICE(PCI_VENDOR_ID_SONY, PCI_DEVICE_ID_SXS_81CE), },
+   { PCI_DEVICE(PCI_VENDOR_ID_SONY, PCI_DEVICE_ID_SXS_905C), },
+   { 0, }
+};
+MODULE_DEVICE_TABLE(pci, ids);
+
+struct sxs_device {
+   struct pci_dev *pci_dev;
+   spinlock_t lock;
+   void __iomem *mmio;
+
+   intsxs_major;
+   struct gendisk *disk;
+   intsector_size;
+   intnum_sectors;
+   intsector_shift;
+   struct request_queue *queue;
+
+   struct completion irq_response;
+};
+
+static int sxs_getgeo(struct block_device *bdev, struct hd_geometry *geo)
+{
+   struct sxs_device *dev = bdev->bd_disk->private_data;
+   long size;
+
+   /* Make something up here */
+   size = dev->num_sectors*(dev->sector_size/KERNEL_SECTOR_SIZE);
+   geo->cylinders = (size & ~0x3f) >> 6;
+   geo->heads = 4;
+   geo->sectors = 16;
+
+   return 0;
+}
+
+static const struct block_device_operations sxs_opts = {
+   .owner  = THIS_MODULE,
+   .getgeo = sxs_getgeo
+};
+
+static void memcpy_read(struct sxs_device *dev, unsigned long sector,
+   unsigned long nsect, char 
*buffer)
+{
+   struct pci_dev *pdev = dev->pci_dev;
+   u32 status;
+   u32 data[4];
+   u16 *tmp;
+   u32 *tmp2;
+
+   void *dma2;
+   dma_addr_t dma2_handle;
+   void *dma3;
+   dma_addr_t dma3_handle;
+
+   sector >>= dev->sector_shift;
+   nsect >>= dev->sector_shift;
+
+   /* Read */
+   dma2 = pci_alloc_consistent(pdev, 8192, _handle);
+   memset(dma2, 0, 8192);
+
+   dma3 = pci_alloc_consistent(pdev, 8192, _handle);
+   memset(dma3, 0, 8192);
+
+   tmp = dma2;
+   tmp2 = dma3;
+   tmp2[0] = dma2_handle;
+   tmp2[2] = dma3_handle;
+
+   printk_ratelimited(KERN_DEBUG"CALL %lu %lu\n",
+  sector & 0x, nsect & 0x);
+
+   INIT_COMPLETION(dev->irq_response);
+   status = readl(dev->mmio+SXS_STATUS_REG);
+   data[0] = cpu_to_le32(0x00010028);
+   data[1] = cpu_to_le32(sector & 0x);
+   data[2] = 0x0;
+   data[3] = cpu_to_le32(nsect & 0x);
+   memcpy_toio(dev->mmio, data, sizeof(data));
+   writel(0xa0, dev->mmio+SXS_ENABLE_REG);
+   writel(0x80, dev->mmio+SXS_CONTROL_REG);
+
+   if (!wait_for_completion_timeout(>irq_response,
+msecs_to_jiffies(5000))) {
+   pr_debug("No IRQ\n");
+   }
+
+   INIT_COMPLETION(dev->irq_response);
+   

[PATCH] gpio:gpio-pl2303: add gpio driver for GPIOs on PL2303

[Wang YanQing]

PL2303HX has two GPIOs, this patch add driver for it.

Signed-off-by: Wang YanQing 
---
 MAINTAINERS |   5 +
 drivers/gpio/Kconfig|   7 ++
 drivers/gpio/Makefile   |   1 +
 drivers/gpio/gpio-pl2303.c  | 238 
 drivers/usb/serial/pl2303.c |  19 
 5 files changed, 270 insertions(+)
 create mode 100644 drivers/gpio/gpio-pl2303.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 53feaaf..4a9d764 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6903,6 +6903,11 @@ F:   drivers/i2c/busses/i2c-puv3.c
 F: drivers/video/fb-puv3.c
 F: drivers/rtc/rtc-puv3.c
 
+PL2303 GPIO DRIVER
+M: Wang YanQing 
+S: Maintained
+F: drivers/gpio/gpio-pl2303.c
+
 PMBUS HARDWARE MONITORING DRIVERS
 M: Guenter Roeck 
 L: lm-sens...@lm-sensors.org
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4a1b511..0f90950 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -110,6 +110,13 @@ config GPIO_DA9055
 config GPIO_MAX730X
tristate
 
+config GPIO_PL2303
+   tristate "USB Prolific 2303 gpio support"
+   depends on USB_SERIAL_PL2303
+   help
+ Enable support for GPIOs on USB Prolific 2303
+ It support two GPIOs on PL2303HX currently.
+
 comment "Memory mapped GPIO drivers:"
 
 config GPIO_CLPS711X
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index d10f6a9..4ff59f6 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -101,3 +101,4 @@ obj-$(CONFIG_GPIO_WM8994)   += gpio-wm8994.o
 obj-$(CONFIG_GPIO_XILINX)  += gpio-xilinx.o
 obj-$(CONFIG_GPIO_XTENSA)  += gpio-xtensa.o
 obj-$(CONFIG_GPIO_ZEVIO)   += gpio-zevio.o
+obj-$(CONFIG_GPIO_PL2303)  += gpio-pl2303.o
diff --git a/drivers/gpio/gpio-pl2303.c b/drivers/gpio/gpio-pl2303.c
new file mode 100644
index 000..a703440
--- /dev/null
+++ b/drivers/gpio/gpio-pl2303.c
@@ -0,0 +1,238 @@
+/*
+ * PL2303 GPIO driver
+ *
+ * Copyright (C) 2014 Wang YanQing 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Check pl2303.c for further details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define VENDOR_READ_REQUEST_TYPE   0xc0
+#define VENDOR_READ_REQUEST0x01
+
+#define VENDOR_WRITE_REQUEST_TYPE  0x40
+#define VENDOR_WRITE_REQUEST   0x01
+
+struct pl2303_gpio_data {
+   struct usb_device *pl2303;
+   /*
+* 0..3: unknown (zero)
+* 4: gp0 output enable (1: gp0 pin is output, 0: gp0 pin is input)
+* 5: gp1 output enable (1: gp1 pin is output, 0: gp1 pin is input)
+* 6: gp0 pin value
+* 7: gp1 pin value
+*/
+   u8 index;
+   struct gpio_chip gpio_chip;
+};
+
+static inline struct pl2303_gpio_data *to_pl2303_gpio(struct gpio_chip *chip)
+{
+   return container_of(chip, struct pl2303_gpio_data, gpio_chip);
+}
+
+static int pl2303_gpio_read(struct gpio_chip *chip, unsigned char buf[1])
+{
+   struct pl2303_gpio_data *pl2303_gpio = to_pl2303_gpio(chip);
+   struct usb_device *pl2303 = pl2303_gpio->pl2303;
+   struct device *dev = chip->dev;
+   int res;
+
+   res = usb_control_msg(pl2303, usb_rcvctrlpipe(pl2303, 0),
+   VENDOR_READ_REQUEST, VENDOR_READ_REQUEST_TYPE,
+   0x0081, 0, buf, 1, 100);
+   if (res != 1) {
+   dev_err(dev, "%s - failed to read [%04x]: %d\n", __func__,
+   0x0081, res);
+   if (res >= 0)
+   res = -EIO;
+
+   return res;
+   }
+
+   dev_dbg(dev, "%s - [%04x] = %02x\n", __func__, 0x0081, buf[0]);
+
+   return 0;
+}
+
+static int pl2303_gpio_write(struct gpio_chip *chip)
+{
+   struct pl2303_gpio_data *pl2303_gpio = to_pl2303_gpio(chip);
+   struct usb_device *pl2303 = pl2303_gpio->pl2303;
+   struct device *dev = chip->dev;
+   int res;
+
+   dev_dbg(dev, "%s - [%04x] = %02x\n", __func__, 1, pl2303_gpio->index);
+
+   res = usb_control_msg(pl2303, usb_sndctrlpipe(pl2303, 0),
+   VENDOR_WRITE_REQUEST, VENDOR_WRITE_REQUEST_TYPE,
+   1, pl2303_gpio->index, NULL, 0, 100);
+   if (res) {
+   dev_err(dev, "%s - failed to write [%04x] = %02x: %d\n", 
__func__,
+   1, pl2303_gpio->index, res);
+   return res;
+   }
+
+   return 0;
+}
+
+static int pl2303_gpio_direction_in(struct gpio_chip *chip, unsigned offset)
+{
+   struct pl2303_gpio_data *pl2303_gpio = to_pl2303_gpio(chip);
+
+   if (offset == 0)
+   pl2303_gpio->index &= ~0x10;
+   else if (offset == 1)
+   pl2303_gpio->index &= ~0x20;
+   else
+   return -EINVAL;
+
+   

[PATCH v2 1/2] xen/setup: Remove Identity Map Debug Message

[Matt Rushton]

Removing a debug message for setting the identity map since it becomes
rather noisy after rework of the identity map code.

Signed-off-by: Matthew Rushton 
---
 arch/x86/xen/p2m.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
index 9bb3d82..3172692 100644
--- a/arch/x86/xen/p2m.c
+++ b/arch/x86/xen/p2m.c
@@ -841,10 +841,9 @@ unsigned long __init set_phys_range_identity(unsigned long 
pfn_s,
pfn = ALIGN(pfn, P2M_PER_PAGE);
}
 
-   if (!WARN((pfn - pfn_s) != (pfn_e - pfn_s),
+   WARN((pfn - pfn_s) != (pfn_e - pfn_s),
"Identity mapping failed. We are %ld short of 1-1 mappings!\n",
-   (pfn_e - pfn_s) - (pfn - pfn_s)))
-   printk(KERN_DEBUG "1-1 mapping on %lx->%lx\n", pfn_s, pfn);
+   (pfn_e - pfn_s) - (pfn - pfn_s));
 
return pfn - pfn_s;
 }
-- 
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] Input: fix defuzzing logic

[Dmitry Torokhov]

We attempt to remove noise from coordinates reported by devices in
input_handle_abs_event(), unfortunately, unless we were dropping the
event altogether, we were ignoring the adjusted value and were passing
on the original value instead.

Reviewed-by: Andrew de los Reyes 
Reviewed-by: Benson Leung 
Signed-off-by: Dmitry Torokhov 
---
 drivers/input/input.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 1c4c0db..29ca0bb 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -257,9 +257,10 @@ static int input_handle_abs_event(struct input_dev *dev,
 }
 
 static int input_get_disposition(struct input_dev *dev,
- unsigned int type, unsigned int code, int value)
+ unsigned int type, unsigned int code, int *pval)
 {
int disposition = INPUT_IGNORE_EVENT;
+   int value = *pval;
 
switch (type) {
 
@@ -357,6 +358,7 @@ static int input_get_disposition(struct input_dev *dev,
break;
}
 
+   *pval = value;
return disposition;
 }
 
@@ -365,7 +367,7 @@ static void input_handle_event(struct input_dev *dev,
 {
int disposition;
 
-   disposition = input_get_disposition(dev, type, code, value);
+   disposition = input_get_disposition(dev, type, code, );
 
if ((disposition & INPUT_PASS_TO_DEVICE) && dev->event)
dev->event(dev, type, code, value);

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

Re: [PATCH 0/2] shmem: fix faulting into a hole while it's punched, take 3

[Hugh Dickins]

On Fri, 18 Jul 2014, Sasha Levin wrote:
> On 07/17/2014 12:12 PM, Sasha Levin wrote:
> > On 07/17/2014 12:10 PM, Vlastimil Babka wrote:
> >> > On 07/15/2014 12:28 PM, Hugh Dickins wrote:
> >>> >> In the end I decided that we had better look at it as two problems,
> >>> >> the trinity faulting starvation, and the indefinite punching loop,
> >>> >> so 1/2 and 2/2 present both solutions: belt and braces.
> >> > 
> >> > I tested that with my reproducer and it was OK, but as I already said, 
> >> > it's not trinity so I didn't observe the new problems in the first place.
> > I've started seeing a new hang in the lru code, but I'm not sure if
> > it's related to this patch or not (the locks are the same ones, but
> > the location is very different).
> > 
> > I'm looking into that.
> 
> Hi Hugh,
> 
> The new hang I'm seeing is much simpler to analyse (compared to 
> shmem_fallocate) and
> doesn't seem to be related. I'll send a separate mail and Cc you just in 
> case, but
> I don't think that this patchset has anything to do with it.

Thanks for testing and following up, Sasha.  I agree, that one is
unrelated.  I've just sent a suggestion in your lru_add_drain_all thread.

> 
> Otherwise, I've been unable to reproduce the shmem_fallocate hang.

Great.  Andrew, I think we can say that it's now safe to send
1/2 shmem: fix faulting into a hole, not taking i_mutex
2/2 shmem: fix splicing from a hole while it's punched
on to Linus whenever suits you.

(You have some other patches in the mainline-later section of the
mmotm/series file: they're okay too, but not in doubt as these two were.)

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

Re: [PATCH v3 2/7] ACPICA: Linux: Add stub implementation of ACPICA 64-bit mathematics.

[Rafael J. Wysocki]

On Wednesday, July 16, 2014 04:58:00 PM Lv Zheng wrote:
> This patch adds default 64-bit mathematics in aclinux.h using do_div(). As
> do_div() can be used for all Linux architectures, this can also be used as
> stub macros for ACPICA 64-bit mathematics.
> 
> But this is not a performance friendly way, as ACPICA's architecture
> specific division OSL only requires a dividing 64-bit number with a 32-bit
> number implementation, while Linux __div64_32() is not available for all
> build environments. So currently, if an architecture really wants to
> support ACPICA, it must implement its own division OSL.

What does this mean for i386, in particular?

> This is required by the ACPICA header stub support. ACPICA header stubs are
> useful to protect CONFIG_ACPI=n Linux kernel builds where ACPICA headers
> are included. Lv Zheng.
> 
> Signed-off-by: Lv Zheng 
> ---
>  include/acpi/platform/aclinuxex.h |   22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/include/acpi/platform/aclinuxex.h 
> b/include/acpi/platform/aclinuxex.h
> index 191e741..568d4b8 100644
> --- a/include/acpi/platform/aclinuxex.h
> +++ b/include/acpi/platform/aclinuxex.h
> @@ -46,6 +46,28 @@
>  
>  #ifdef __KERNEL__
>  
> +#ifndef ACPI_USE_NATIVE_DIVIDE
> +
> +#ifndef ACPI_DIV_64_BY_32
> +#define ACPI_DIV_64_BY_32(n_hi, n_lo, d32, q32, r32) \
> + do { \
> + u64 (__n) = ((u64) n_hi) << 32 | (n_lo); \
> + (r32) = do_div ((__n), (d32)); \
> + (q32) = (u32) (__n); \
> + } while (0)
> +#endif
> +
> +#ifndef ACPI_SHIFT_RIGHT_64
> +#define ACPI_SHIFT_RIGHT_64(n_hi, n_lo) \
> + do { \
> + (n_lo) >>= 1; \
> + (n_lo) |= (((n_hi) & 1) << 31); \
> + (n_hi) >>= 1; \
> + } while (0)
> +#endif
> +
> +#endif
> +
>  /*
>   * Overrides for in-kernel ACPICA
>   */
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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 v6 4/4] iio: hid-sensor-magn-3d: Add support for rotation from north

[Srinivas Pandruvada]

On 07/17/2014 11:18 AM, Reyad Attiyat wrote:

Add the HID usage attribute ID's and IIO channel info for rotation
from north support.

Signed-off-by: Reyad Attiyat 

Acked-by: Srinivas Pandruvada 

---
  drivers/iio/magnetometer/hid-sensor-magn-3d.c | 53 ++-
  1 file changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c 
b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index d3b9114..3ec777a 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -35,6 +35,10 @@ enum magn_3d_channel {
CHANNEL_SCAN_INDEX_X,
CHANNEL_SCAN_INDEX_Y,
CHANNEL_SCAN_INDEX_Z,
+   CHANNEL_SCAN_INDEX_NORTH_MAGN_TILT_COMP,
+   CHANNEL_SCAN_INDEX_NORTH_TRUE_TILT_COMP,
+   CHANNEL_SCAN_INDEX_NORTH_MAGN,
+   CHANNEL_SCAN_INDEX_NORTH_TRUE,
MAGN_3D_CHANNEL_MAX,
  };
  
@@ -57,7 +61,11 @@ struct magn_3d_state {

  static const u32 magn_3d_addresses[MAGN_3D_CHANNEL_MAX] = {
HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS,
HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS,
-   HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS
+   HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS,
+   HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH,
+   HID_USAGE_SENSOR_ORIENT_COMP_TRUE_NORTH,
+   HID_USAGE_SENSOR_ORIENT_MAGN_NORTH,
+   HID_USAGE_SENSOR_ORIENT_TRUE_NORTH,
  };
  
  /* Channel definitions */

@@ -89,6 +97,42 @@ static const struct iio_chan_spec magn_3d_channels[] = {
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_HYSTERESIS),
+   }, {
+   .type = IIO_ROT,
+   .modified = 1,
+   .channel2 = IIO_MOD_NORTH_MAGN_TILT_COMP,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+   BIT(IIO_CHAN_INFO_SCALE) |
+   BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+   BIT(IIO_CHAN_INFO_HYSTERESIS),
+   }, {
+   .type = IIO_ROT,
+   .modified = 1,
+   .channel2 = IIO_MOD_NORTH_TRUE_TILT_COMP,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+   BIT(IIO_CHAN_INFO_SCALE) |
+   BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+   BIT(IIO_CHAN_INFO_HYSTERESIS),
+   }, {
+   .type = IIO_ROT,
+   .modified = 1,
+   .channel2 = IIO_MOD_NORTH_MAGN,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+   BIT(IIO_CHAN_INFO_SCALE) |
+   BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+   BIT(IIO_CHAN_INFO_HYSTERESIS),
+   }, {
+   .type = IIO_ROT,
+   .modified = 1,
+   .channel2 = IIO_MOD_NORTH_TRUE,
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+   BIT(IIO_CHAN_INFO_SCALE) |
+   BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+   BIT(IIO_CHAN_INFO_HYSTERESIS),
}
  };
  
@@ -245,6 +289,13 @@ static int magn_3d_capture_sample(struct hid_sensor_hub_device *hsdev,

offset = (usage_id - HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS)
+ CHANNEL_SCAN_INDEX_X;
break;
+   case HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH:
+   case HID_USAGE_SENSOR_ORIENT_COMP_TRUE_NORTH:
+   case HID_USAGE_SENSOR_ORIENT_MAGN_NORTH:
+   case HID_USAGE_SENSOR_ORIENT_TRUE_NORTH:
+   offset = (usage_id - HID_USAGE_SENSOR_ORIENT_COMP_MAGN_NORTH)
+   + CHANNEL_SCAN_INDEX_NORTH_MAGN_TILT_COMP;
+   break;
default:
return -EINVAL;
}


--
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 v6 3/4] iio: hid-sensor-magn-3d: Scan for usage attributes before setting up iio channels

[Srinivas Pandruvada]

On 07/17/2014 11:18 AM, Reyad Attiyat wrote:

Scan for and count the HID usage attributes supported by the driver.
This allows for the driver to only setup the IIO channels for the
sensor usages present in the HID USB reports.

Changes from v5
-Fixed kernel panic from invalid pointer dereference
-Fixed variable assignment style

Signed-off-by: Reyad Attiyat 

Acked-by: Srinivas Pandruvada 

---
  drivers/iio/magnetometer/hid-sensor-magn-3d.c | 149 ++
  1 file changed, 105 insertions(+), 44 deletions(-)

diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c 
b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index b2b0937..d3b9114 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -42,7 +42,12 @@ struct magn_3d_state {
struct hid_sensor_hub_callbacks callbacks;
struct hid_sensor_common common_attributes;
struct hid_sensor_hub_attribute_info magn[MAGN_3D_CHANNEL_MAX];
-   u32 magn_val[MAGN_3D_CHANNEL_MAX];
+
+   /* dynamically sized array to hold sensor values */
+   u32 *iio_vals;
+   /* array of pointers to sensor value */
+   u32 *magn_val_addr[MAGN_3D_CHANNEL_MAX];
+
int scale_pre_decml;
int scale_post_decml;
int scale_precision;
@@ -66,7 +71,6 @@ static const struct iio_chan_spec magn_3d_channels[] = {
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_HYSTERESIS),
-   .scan_index = CHANNEL_SCAN_INDEX_X,
}, {
.type = IIO_MAGN,
.modified = 1,
@@ -76,7 +80,6 @@ static const struct iio_chan_spec magn_3d_channels[] = {
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_HYSTERESIS),
-   .scan_index = CHANNEL_SCAN_INDEX_Y,
}, {
.type = IIO_MAGN,
.modified = 1,
@@ -86,7 +89,6 @@ static const struct iio_chan_spec magn_3d_channels[] = {
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_HYSTERESIS),
-   .scan_index = CHANNEL_SCAN_INDEX_Z,
}
  };
  
@@ -126,8 +128,8 @@ static int magn_3d_read_raw(struct iio_dev *indio_dev,

msleep_interruptible(poll_value * 2);
  
  		report_id =

-   magn_state->magn[chan->scan_index].report_id;
-   address = magn_3d_addresses[chan->scan_index];
+   magn_state->magn[chan->address].report_id;
+   address = magn_3d_addresses[chan->address];
if (report_id >= 0)
*val = sensor_hub_input_attr_get_raw_value(
magn_state->common_attributes.hsdev,
@@ -218,8 +220,8 @@ static int magn_3d_proc_event(struct hid_sensor_hub_device 
*hsdev,
dev_dbg(_dev->dev, "magn_3d_proc_event\n");
if (atomic_read(_state->common_attributes.data_ready))
hid_sensor_push_data(indio_dev,
-   magn_state->magn_val,
-   sizeof(magn_state->magn_val));
+   magn_state->iio_vals,
+   sizeof(magn_state->iio_vals));
  
  	return 0;

  }
@@ -233,52 +235,119 @@ static int magn_3d_capture_sample(struct 
hid_sensor_hub_device *hsdev,
struct iio_dev *indio_dev = platform_get_drvdata(priv);
struct magn_3d_state *magn_state = iio_priv(indio_dev);
int offset;
-   int ret = -EINVAL;
+   int ret = 0;
+   u32 *iio_val = NULL;
  
  	switch (usage_id) {

case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS:
case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS:
case HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS:
-   offset = usage_id - HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS;
-   magn_state->magn_val[CHANNEL_SCAN_INDEX_X + offset] =
-   *(u32 *)raw_data;
-   ret = 0;
+   offset = (usage_id - HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_X_AXIS)
+   + CHANNEL_SCAN_INDEX_X;
break;
default:
-   break;
+   return -EINVAL;
}
  
+	iio_val = magn_state->magn_val_addr[offset];

+
+   if (iio_val != NULL)
+   *iio_val = *((u32 *)raw_data);
+   else
+   ret = -EINVAL;
+
return ret;
  }
  
  /* Parse report which is specific to an usage id*/

  static int magn_3d_parse_report(struct platform_device *pdev,
struct hid_sensor_hub_device *hsdev,
-   struct iio_chan_spec *channels,
+   struct iio_chan_spec **channels,
+   int *chan_count,
unsigned usage_id,

Re: [PATCH v3 0/3] Clean up ACPI core to prepare for running ACPI on ARM64

[Rafael J. Wysocki]

On Friday, July 18, 2014 06:02:51 PM Hanjun Guo wrote:
> This patch set have no function change for x86 and ia64 and
> just do some clean up to prepare for running ACPI on ARM64.
> 
> This patch set is splited out from the patch set [1]
> "[PATCH v4 00/13] Enable ACPI on ARM64 in Kconfig" and hope it
> can be merged first before ARM64 ACPI core patches.
> 
> [1]: https://lkml.org/lkml/2014/6/26/627
> 
> update from v2:
> Don not select ACPI_LEGACY_TABLES_LOOKUP on IA64 which
> is catched by Peter.
> 
> update from v1:
> 1. Drop "Make EC debugfs depend on X86 || IA64 in Kconfig";
> 2. Rename ACPI_SCAN_BIOS_NOT_EFI to ACPI_LEGACY_TABLES_LOOKUP
>suggested by Rafael;
> 3. Rename ARCH_HAS_ACPI_PDC to ARCH_MIGHT_HAVE_ACPI_PDC suggested by Rafael;
> 4. Remove the help for ARCH_MIGHT_HAVE_ACPI_PDC because it can't be selected;
> 5. Rename acpi_arch_is_smp() to acpi_has_cpu_in_madt() to be more
>explicit and easy understanding.
> 
> Graeme Gregory (2):
>   ACPI: ARM64 does not have a BIOS add config for BIOS table scan.
>   ACPI: Don't use acpi_lapic in ACPI core code
> 
> Hanjun Guo (1):
>   ACPI / processor: Introduce ARCH_HAS_ACPI_PDC

Series queued up for 3.17 with minor changes of patch subjects.  Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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: mm: swap: hang in lru_add_drain_all

[Hugh Dickins]

On Fri, 18 Jul 2014, Sasha Levin wrote:

> Hi all,
> 
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on the following spew:
> 
> [  729.682257] INFO: task trinity-c158:13508 blocked for more than 120 
> seconds.
> [  729.683191]   Not tainted 
> 3.16.0-rc5-next-20140718-sasha-00052-g4d34feb #902
> [  729.683843] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [  729.684633] trinity-c158D 880d32169000 12520 13508   8729 
> 0x
> [  729.685323]  880de6d3fe38 0002 0006 
> 880c6c33b000
> [  729.686039]  00785eb36cd1 880de6d3c010 880de6d3c000 
> 880e2b27
> [  729.686761]  880c6c33b000  b070b908 
> 26e426e2
> [  729.687483] Call Trace:
> [  729.687736] schedule_preempt_disabled (kernel/sched/core.c:2874)
> [  729.688544] mutex_lock_nested (kernel/locking/mutex.c:532 
> kernel/locking/mutex.c:584)
> [  729.689127] ? lru_add_drain_all (mm/swap.c:867)
> [  729.689666] ? lru_add_drain_all (mm/swap.c:867)
> [  729.690334] lru_add_drain_all (mm/swap.c:867)
> [  729.690946] SyS_mlockall (./arch/x86/include/asm/current.h:14 
> include/linux/sched.h:2978 mm/mlock.c:813 mm/mlock.c:798)
> [  729.691437] tracesys (arch/x86/kernel/entry_64.S:541)
> [  729.691883] 1 lock held by trinity-c158/13508:
> [  729.692333] #0: (lock#3){+.+...}, at: lru_add_drain_all (mm/swap.c:867)
> 
> There are quite a few tasks with the same stacktrace. Since the lock we're 
> blocking
> on is static local to the function it's easy to figure out which task 
> actually has it:
> 
> [  739.587839] trinity-c135D 880e1318c000 13096 21051   8729 
> 0x
> [  739.589080]  880bf659fcc0 0002 880c74223cf0 
> 880c74223000
> [  739.590544]  00781c3378ed 880bf659c010 880bf659c000 
> 880e2b153000
> [  739.591815]  880c74223000  7fff 
> 880bf659fe80
> [  739.593165] Call Trace:
> [  739.593588] schedule (kernel/sched/core.c:2847)
> [  739.594396] schedule_timeout (kernel/time/timer.c:1476)
> [  739.595354] ? mark_lock (kernel/locking/lockdep.c:2894)
> [  739.596229] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
> [  739.597297] ? get_parent_ip (kernel/sched/core.c:2561)
> [  739.598185] wait_for_completion (include/linux/spinlock.h:328 
> kernel/sched/completion.c:76 kernel/sched/completion.c:93 
> kernel/sched/completion.c:101 kernel/sched/completion.c:122)
> [  739.599191] ? wake_up_state (kernel/sched/core.c:2942)
> [  739.600246] flush_work (kernel/workqueue.c:503 kernel/workqueue.c:2762)
> [  739.601171] ? flush_work (kernel/workqueue.c:2733 kernel/workqueue.c:2760)
> [  739.602084] ? destroy_worker (kernel/workqueue.c:2348)
> [  739.603035] ? wait_for_completion (kernel/sched/completion.c:64 
> kernel/sched/completion.c:93 kernel/sched/completion.c:101 
> kernel/sched/completion.c:122)
> [  739.604043] lru_add_drain_all (include/linux/cpumask.h:180 mm/swap.c:883)
> [  739.605076] SyS_mlockall (./arch/x86/include/asm/current.h:14 
> include/linux/sched.h:2978 mm/mlock.c:813 mm/mlock.c:798)
> [  739.605943] tracesys (arch/x86/kernel/entry_64.S:541)
> 
> Now, you'd expect to see lru_add_drain_per_cpu in one of the tasks, but
> that's not the case.
> 
> Full log attched.

I'm happy to find no "shmem" and no "fallocate" in that log: I agree
that this hang is something different, and I'll sound the all-clear
on that one, once I've made a suggestion on this one.

I know next to nothing about scheduler matters, so the less I say, the
less I'll make a fool of myself.  But I believe this problem may be
self-inflicted by trinity, that it may be using its privilege to abuse
RT priority in a way to hang the system here.

Appended below are relevant cpu#13 lines from your log.txt.  You took
10 watchdog dumps across 20 seconds: here's the first trace and stats,
eight intervening "rt_time" lines, and the last trace and stats.

Bear in mind that I know nothing about RT, and "rt_time", but it seems
fair to show it cycling around in between the first and last.  And it
seems interesting that "nr_switches" is 49357 in the first and 49357
in the last, and the three cpu#13 runnable kworkers show the same
"switches" in the first and the last stats.

I've not checked whether "switches" means what I'd expect it to mean,
but I'm guessing trinity-c13 is looping at RT priority on cpu#13,
and locking out everything else.

In particular, locking out the kworker which would just love to get
in and drain cpu#13's lru_add pagevec, then wake up trinity-c135 to
say the drain is completed, whereupon trinity-c135 can drop the mutex,
to let trinity-c158 and many others in to do... much the same again.

Hugh

[  739.534086] trinity-c13 R  running task13312 20846   8729 0x0008
[  739.534875]  024e a9ffc7f7 880ba796bd28 
0001
[  739.535696]  880ba796b000 

Re: [PATCH v6 1/4] iio: Documentation: Add documentation for rotation from north sensor usage attributes

[Srinivas Pandruvada]

On 07/17/2014 11:18 AM, Reyad Attiyat wrote:

Added documentation for the sysfs attributes supported by the rotation from 
north
sensor.

Signed-off-by: Reyad Attiyat 

Acked-by: Srinivas Pandruvada 

---
  Documentation/ABI/testing/sysfs-bus-iio | 82 +
  1 file changed, 82 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index a9757dc..995642f 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -260,6 +260,10 @@ What:  
/sys/bus/iio/devices/iio:deviceX/in_magn_scale
  What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
  What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
  What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale
+What:  
/sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_scale
+What:  /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_scale
+What:  
/sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_scale
+What:  
/sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale
  What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
  What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale
  KernelVersion:2.6.35
@@ -447,6 +451,14 @@ What:  
/sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en
  What: /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en
  What: /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en
  What: /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_falling_en
  What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
  What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
  What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
@@ -492,6 +504,14 @@ What:  
/sys/.../iio:deviceX/events/in_magn_y_roc_rising_en
  What: /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en
  What: /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en
  What: /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_falling_en
+What:  /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_roc_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_falling_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_rising_en
+What:  
/sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_falling_en
  What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_rising_en
  What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_falling_en
  What: /sys/.../iio:deviceX/events/in_voltageY_roc_rising_en
@@ -538,6 +558,14 @@ What:  
/sys/.../events/in_magn_y_raw_thresh_rising_value
  What: /sys/.../events/in_magn_y_raw_thresh_falling_value
  What: /sys/.../events/in_magn_z_raw_thresh_rising_value
  What: /sys/.../events/in_magn_z_raw_thresh_falling_value
+What:  
/sys/.../events/in_rot_from_north_magnetic_raw_thresh_rising_value
+What:  
/sys/.../events/in_rot_from_north_magnetic_raw_thresh_falling_value
+What:  /sys/.../events/in_rot_from_north_true_raw_thresh_rising_value
+What:  /sys/.../events/in_rot_from_north_true_raw_thresh_falling_value
+What:  
/sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_rising_value
+What:  
/sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_falling_value
+What:  
/sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_rising_value
+What:  
/sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_falling_value
  What: /sys/.../events/in_voltageY_supply_raw_thresh_rising_value
  What: /sys/.../events/in_voltageY_supply_raw_thresh_falling_value
 

Re: [PATCH v6 2/4] iio: types: Added support for rotation from north usage attributes

[Srinivas Pandruvada]

On 07/17/2014 11:18 AM, Reyad Attiyat wrote:

Added the rotation from north usage attributes to the iio modifier enum and to 
the iio modifier names array.

Signed-off-by: Reyad Attiyat 

Acked-by: Srinivas Pandruvada 

---
  drivers/iio/industrialio-core.c | 4 
  include/linux/iio/types.h   | 4 
  2 files changed, 8 insertions(+)

diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
index 4b1f375..af3e76d 100644
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -87,6 +87,10 @@ static const char * const iio_modifier_names[] = {
[IIO_MOD_QUATERNION] = "quaternion",
[IIO_MOD_TEMP_AMBIENT] = "ambient",
[IIO_MOD_TEMP_OBJECT] = "object",
+   [IIO_MOD_NORTH_MAGN] = "from_north_magnetic",
+   [IIO_MOD_NORTH_TRUE] = "from_north_true",
+   [IIO_MOD_NORTH_MAGN_TILT_COMP] = "from_north_magnetic_tilt_comp",
+   [IIO_MOD_NORTH_TRUE_TILT_COMP] = "from_north_true_tilt_comp",
  };
  
  /* relies on pairs of these shared then separate */

diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
index d480631..d09c40d 100644
--- a/include/linux/iio/types.h
+++ b/include/linux/iio/types.h
@@ -56,6 +56,10 @@ enum iio_modifier {
IIO_MOD_QUATERNION,
IIO_MOD_TEMP_AMBIENT,
IIO_MOD_TEMP_OBJECT,
+   IIO_MOD_NORTH_MAGN,
+   IIO_MOD_NORTH_TRUE,
+   IIO_MOD_NORTH_MAGN_TILT_COMP,
+   IIO_MOD_NORTH_TRUE_TILT_COMP
  };
  
  enum iio_event_type {


--
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] Input: max7359 - Introduce the use of managed interfaces

[Dmitry Torokhov]

On Sat, Jul 19, 2014 at 03:36:54PM +0530, Himangi Saraogi wrote:
> This patch introduces the use of managed interfaces like devm_kzalloc,
> devm_input_allocate_device, devm_request_threaded_irq etc. and does away
> with the calls to free the allocated memory. The remove function is no
> longer required and is completely done away with. Also, the labels in
> the probe function are removed.
> 
> Signed-off-by: Himangi Saraogi 
> Acked-by: Julia Lawall 

Applied, thank you.

> ---
>  drivers/input/keyboard/max7359_keypad.c | 38 
> +
>  1 file changed, 10 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/input/keyboard/max7359_keypad.c 
> b/drivers/input/keyboard/max7359_keypad.c
> index 430b545..b0ef607 100644
> --- a/drivers/input/keyboard/max7359_keypad.c
> +++ b/drivers/input/keyboard/max7359_keypad.c
> @@ -203,12 +203,12 @@ static int max7359_probe(struct i2c_client *client,
>  
>   dev_dbg(>dev, "keys FIFO is 0x%02x\n", ret);
>  
> - keypad = kzalloc(sizeof(struct max7359_keypad), GFP_KERNEL);
> - input_dev = input_allocate_device();
> + keypad = devm_kzalloc(>dev, sizeof(struct max7359_keypad),
> +   GFP_KERNEL);
> + input_dev = devm_input_allocate_device(>dev);
>   if (!keypad || !input_dev) {
>   dev_err(>dev, "failed to allocate memory\n");
> - error = -ENOMEM;
> - goto failed_free_mem;
> + return -ENOMEM;
>   }
>  
>   keypad->client = client;
> @@ -230,19 +230,20 @@ static int max7359_probe(struct i2c_client *client,
>  
>   max7359_build_keycode(keypad, keymap_data);
>  
> - error = request_threaded_irq(client->irq, NULL, max7359_interrupt,
> -  IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> -  client->name, keypad);
> + error = devm_request_threaded_irq(>dev, client->irq, NULL,
> +   max7359_interrupt,
> +   IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> +   client->name, keypad);
>   if (error) {
>   dev_err(>dev, "failed to register interrupt\n");
> - goto failed_free_mem;
> + return error;
>   }
>  
>   /* Register the input device */
>   error = input_register_device(input_dev);
>   if (error) {
>   dev_err(>dev, "failed to register input device\n");
> - goto failed_free_irq;
> + return error;
>   }
>  
>   /* Initialize MAX7359 */
> @@ -252,24 +253,6 @@ static int max7359_probe(struct i2c_client *client,
>   device_init_wakeup(>dev, 1);
>  
>   return 0;
> -
> -failed_free_irq:
> - free_irq(client->irq, keypad);
> -failed_free_mem:
> - input_free_device(input_dev);
> - kfree(keypad);
> - return error;
> -}
> -
> -static int max7359_remove(struct i2c_client *client)
> -{
> - struct max7359_keypad *keypad = i2c_get_clientdata(client);
> -
> - free_irq(client->irq, keypad);
> - input_unregister_device(keypad->input_dev);
> - kfree(keypad);
> -
> - return 0;
>  }
>  
>  #ifdef CONFIG_PM_SLEEP
> @@ -313,7 +296,6 @@ static struct i2c_driver max7359_i2c_driver = {
>   .pm   = _pm,
>   },
>   .probe  = max7359_probe,
> - .remove = max7359_remove,
>   .id_table   = max7359_ids,
>  };
>  
> -- 
> 1.9.1
> 

-- 
Dmitry
--
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] net/netfilter/ipvs/ip_vs_ctl.c: drop argument range check just before the check for equality

[Andrey Utkin]

2014-07-20 1:59 GMT+03:00 Andrey Utkin :
> This approach doesn't work, looks because sizeof() values are not
> calculated at preprocessing stage.

What about adding equivalent BUG_ON() statement to __init
ip_vs_register_nl_ioctl(), which "registers" do_ip_vs_set_ctl()
callback?

-- 
Andrey Utkin
--
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: bios32.c: Fix me in pci_fixup_it8152

[Russell King - ARM Linux]

On Sat, Jul 19, 2014 at 06:47:37PM -0400, Nick Krause wrote:
> Hey Russell and others,
> Before I clean this fix me up I wanted to known how to define the values
> as stated in the fix me in this function or if this is invalid as of the
> latest kernel trees.

If you would like to fix it properly, then that's fine.  The comment
there says:

/* FIXME: add defines for class 0x68000 and 0x80103 */
if ((dev->class >> 8) == PCI_CLASS_BRIDGE_HOST ||
dev->class == 0x68000 ||
dev->class == 0x80103) {

The thing that's slightly confusing here is that dev->class contains
the class in bits 24..8, but also the programming interface in bits
7..0.

So, the comment is slightly wrong in that it's actually meaning
class 0x0680 with a programming interface of 0x00, and a class of
0x0801 with a programming interface of 0x03.

Your challenge is to _not_ add defines for these, but to use the
existing defines for these classes, and modify the code to use those
defines /without/ changing the effect of the checks.  Ignore that
there's no definitions of the programming interfaces - they can
stay as raw numbers.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] net/netfilter/ipvs/ip_vs_ctl.c: drop argument range check just before the check for equality

[Andrey Utkin]

2014-07-19 0:06 GMT+03:00 Andrey Utkin :
> What about static check at compilation time?
>
> #if (DAEMON_ARG_LEN > MAX_ARG_LEN) \
>  || (SERVICE_ARG_LEN > MAX_ARG_LEN) \
>  || (SVCDEST_ARG_LEN > MAX_ARG_LEN)
> #error MAX_ARG_LEN exceeded in set_arglen table
> #endif

This approach doesn't work, looks because sizeof() values are not
calculated at preprocessing stage.

-- 
Andrey Utkin
--
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: Intel Graphics Drivers

[Nick Krause]

On Sat, Jul 19, 2014 at 6:32 PM, Nick Krause  wrote:
 Hey Daniel and others ,
 If I am correct after asking around on the mailing list then  the
windows  Intel graphics drivers are faster then their Linux
counterparts.
 In addition , I  am wondering if we can improve this and try to
remove regressions in this area of graphics  support as this seems to
be
 the main issue and perhaps the hardware is hard to come by outside of
Intel or the board manufacturers as we seem to have no hardware
 for testing as I asked before . I don't have the hardware but if
people help do the hardware testing  and maybe a bit of advice and
guidance
 as I am new to the graphics stack in the kernel  I can help out  :).
If not that's Ok too just thought it may be of help.
Cheers Nick
P.S. Sorry about first email it wasn't edited. :(
--
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/

bios32.c: Fix me in pci_fixup_it8152

[Nick Krause]

Hey Russell and others,
Before I clean this fix me up I wanted to known how to define the values
as stated in the fix me in this function or if this is invalid as of the latest
kernel trees.
Cheers Nick
--
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/

Intel Graphics Drivers

[Nick Krause]

Hey Daniel and others ,
I am correct after asking around on the mailing list that the intel
graphics drivers are faster.
I am wondering if we can improve this and try to remove regressions in
this area of graphics
support. I don't have the hardware but if people help doing the
testing and maybe a bit of
advice I can help do this if that's OK:).
Cheers Nick
--
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] ACPI / PNP: Use ACPI_COMPANION() instead of ACPI_HANDLE()

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The ACPI_HANDLE() macro evaluates ACPI_COMPANION() internally to
return the handle of the device's ACPI companion, so it is much
more straightforward and efficient to use ACPI_COMPANION()
directly to obtain the device's ACPI companion object instead of
using ACPI_HANDLE() and acpi_bus_get_device() on the returned
handle for the same thing.

Do that in several places in the ACPI PNP core code.

Also use acpi_device_set_power() and acpi_device_power_manageable()
instead of acpi_bus_set_power() and acpi_bus_power_manageable(),
respectively, because the former two are more efficient if the
ACPI device object is already available.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/pnp/pnpacpi/core.c |   51 -
 1 file changed, 23 insertions(+), 28 deletions(-)

Index: linux-pm/drivers/pnp/pnpacpi/core.c
===
--- linux-pm.orig/drivers/pnp/pnpacpi/core.c
+++ linux-pm/drivers/pnp/pnpacpi/core.c
@@ -67,8 +67,8 @@ static int pnpacpi_set_resources(struct
 
pnp_dbg(>dev, "set resources\n");
 
-   handle = ACPI_HANDLE(>dev);
-   if (!handle || acpi_bus_get_device(handle, _dev)) {
+   acpi_dev = ACPI_COMPANION(>dev);
+   if (!acpi_dev) {
dev_dbg(>dev, "ACPI device not found in %s!\n", __func__);
return -ENODEV;
}
@@ -76,6 +76,7 @@ static int pnpacpi_set_resources(struct
if (WARN_ON_ONCE(acpi_dev != dev->data))
dev->data = acpi_dev;
 
+   handle = acpi_dev->handle;
if (acpi_has_method(handle, METHOD_NAME__SRS)) {
struct acpi_buffer buffer;
 
@@ -93,8 +94,8 @@ static int pnpacpi_set_resources(struct
}
kfree(buffer.pointer);
}
-   if (!ret && acpi_bus_power_manageable(handle))
-   ret = acpi_bus_set_power(handle, ACPI_STATE_D0);
+   if (!ret && acpi_device_power_manageable(acpi_dev))
+   ret = acpi_device_set_power(acpi_dev, ACPI_STATE_D0);
 
return ret;
 }
@@ -102,23 +103,22 @@ static int pnpacpi_set_resources(struct
 static int pnpacpi_disable_resources(struct pnp_dev *dev)
 {
struct acpi_device *acpi_dev;
-   acpi_handle handle;
acpi_status status;
 
dev_dbg(>dev, "disable resources\n");
 
-   handle = ACPI_HANDLE(>dev);
-   if (!handle || acpi_bus_get_device(handle, _dev)) {
+   acpi_dev = ACPI_COMPANION(>dev);
+   if (!acpi_dev) {
dev_dbg(>dev, "ACPI device not found in %s!\n", __func__);
return 0;
}
 
/* acpi_unregister_gsi(pnp_irq(dev, 0)); */
-   if (acpi_bus_power_manageable(handle))
-   acpi_bus_set_power(handle, ACPI_STATE_D3_COLD);
+   if (acpi_device_power_manageable(acpi_dev))
+   acpi_device_set_power(acpi_dev, ACPI_STATE_D3_COLD);
 
-   /* continue even if acpi_bus_set_power() fails */
-   status = acpi_evaluate_object(handle, "_DIS", NULL, NULL);
+   /* continue even if acpi_device_set_power() fails */
+   status = acpi_evaluate_object(acpi_dev->handle, "_DIS", NULL, NULL);
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND)
return -ENODEV;
 
@@ -128,26 +128,22 @@ static int pnpacpi_disable_resources(str
 #ifdef CONFIG_ACPI_SLEEP
 static bool pnpacpi_can_wakeup(struct pnp_dev *dev)
 {
-   struct acpi_device *acpi_dev;
-   acpi_handle handle;
+   struct acpi_device *acpi_dev = ACPI_COMPANION(>dev);
 
-   handle = ACPI_HANDLE(>dev);
-   if (!handle || acpi_bus_get_device(handle, _dev)) {
+   if (!acpi_dev) {
dev_dbg(>dev, "ACPI device not found in %s!\n", __func__);
return false;
}
 
-   return acpi_bus_can_wakeup(handle);
+   return acpi_bus_can_wakeup(acpi_dev->handle);
 }
 
 static int pnpacpi_suspend(struct pnp_dev *dev, pm_message_t state)
 {
-   struct acpi_device *acpi_dev;
-   acpi_handle handle;
+   struct acpi_device *acpi_dev = ACPI_COMPANION(>dev);
int error = 0;
 
-   handle = ACPI_HANDLE(>dev);
-   if (!handle || acpi_bus_get_device(handle, _dev)) {
+   if (!acpi_dev) {
dev_dbg(>dev, "ACPI device not found in %s!\n", __func__);
return 0;
}
@@ -159,7 +155,7 @@ static int pnpacpi_suspend(struct pnp_de
return error;
}
 
-   if (acpi_bus_power_manageable(handle)) {
+   if (acpi_device_power_manageable(acpi_dev)) {
int power_state = acpi_pm_device_sleep_state(>dev, NULL,
ACPI_STATE_D3_COLD);
if (power_state < 0)
@@ -167,12 +163,12 @@ static int pnpacpi_suspend(struct pnp_de
ACPI_STATE_D0 : ACPI_STATE_D3_COLD;
 
/*
-* acpi_bus_set_power() often fails (keyboard port can't be
+ 

Re: [PATCH 2/4] ARM: add IPI tracepoints

[Nicolas Pitre]

On Sat, 19 Jul 2014, Ard Biesheuvel wrote:

> On 18 July 2014 23:22, Steven Rostedt  wrote:
> > On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
> > Nicolas Pitre  wrote:
> >
> >>
> >> Here's the patch I have at the head of the series now, with the above
> >> ugliness changed to an unconditional __tracepoint_string attribute.
> >>
> >
> > I was thinking of something like this. Feel free to add this to your
> > series.
> >
> > -- Steve
> >
> 
> Nico,
> 
> If this patch addresses the issue where 3 RCU related tracepoint
> strings turn up /after/ _edata on !CONFIG_TRACING, there is already a
> patch queued up here
> 
> http://marc.info/?l=linux-kernel=140518452623148=2

No, that doesn't help my case.  Please see the initial comment from 
Steven in this thread and you'll understand.


Nicolas
--
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/4] ARM: add IPI tracepoints

[Steven Rostedt]

On Sat, 19 Jul 2014 22:50:16 +0200
Ard Biesheuvel  wrote:

 
> OK, so if the general case has been fixed, perhaps we should ask Paul
> to drop my patch?
> 

No, for a few reasons. One, this patch still needs to get in to fix the
problem for RCU. Two, RCU basically open codes the creation of the
string, thus this wont solve it for RCU.

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

[RESEND PATCH] powerpc/mpic_msgr: Use kcalloc and correct the argument to sizeof

[Himangi Saraogi]

mpic_msgrs has type struct mpic_msgr **, not struct mpic_msgr *, so the
elements of the array should have pointer type, not structure type.
The advantage of kcalloc is, that will prevent integer overflows which
could result from the multiplication of number of elements and size and
it is also a bit nicer to read.

The Coccinelle semantic patch that makes the first change is as follows:

// 
@disable sizeof_type_expr@
type T;
T **x;
@@

  x =
  <+...sizeof(
- T
+ *x
  )...+>
// 

Signed-off-by: Himangi Saraogi 
Acked-by: Julia Lawall 
---
 arch/powerpc/sysdev/mpic_msgr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
index 2c9b52a..7bdf3cc 100644
--- a/arch/powerpc/sysdev/mpic_msgr.c
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -184,7 +184,7 @@ static int mpic_msgr_probe(struct platform_device *dev)
dev_info(>dev, "Found %d message registers\n",
mpic_msgr_count);
 
-   mpic_msgrs = kzalloc(sizeof(struct mpic_msgr) * mpic_msgr_count,
+   mpic_msgrs = kcalloc(mpic_msgr_count, sizeof(*mpic_msgrs),
 GFP_KERNEL);
if (!mpic_msgrs) {
dev_err(>dev,
-- 
1.9.1

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

[RESEND PATCH] cpupower: mperf monitor: Correct use of ! and

[Himangi Saraogi]

In commit ae91d60ba88ef0bdb1b5e9b2363bd52fc45d2af7, a bug was fixed that
involved converting !x & y to !(x & y).  The code below shows the same
pattern, and thus should perhaps be fixed in the same way.

The Coccinelle semantic patch that makes this change is as follows:

// 
@@ expression E1,E2; @@
(
  !E1 & !E2
|
- !E1 & E2
+ !(E1 & E2)
)
// 

Signed-off-by: Himangi Saraogi 
---
This is not tested and clearly changes the semantics, so it is only
something to consider.
 tools/power/cpupower/utils/idle_monitor/mperf_monitor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c 
b/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c
index 5650ab5..90a8c4f 100644
--- a/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c
+++ b/tools/power/cpupower/utils/idle_monitor/mperf_monitor.c
@@ -237,7 +237,7 @@ static int init_maxfreq_mode(void)
unsigned long long hwcr;
unsigned long min;
 
-   if (!cpupower_cpu_info.caps & CPUPOWER_CAP_INV_TSC)
+   if (!(cpupower_cpu_info.caps & CPUPOWER_CAP_INV_TSC))
goto use_sysfs;
 
if (cpupower_cpu_info.vendor == X86_VENDOR_AMD) {
-- 
1.9.1

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

Re: [PULL] seccomp update (3.17)

[Theodore Ts'o]

On Sat, Jul 19, 2014 at 07:49:55AM -0700, Kees Cook wrote:
> 
> No worries -- the only user of the seccomp syscall that I know of is
> the seccomp regression testing suite, and that'd be trivially to fix.
> 
> I would note that the seccomp series includes adding the syscall also
> to ARM and MIPS, so from a collision fixing perspective, it may be
> fewer edits to fix getrandom instead. :)

I've only wired up x86 and x86_64 for getrandom(2) so far.  I had
assumed the ARM and MIPS folks would prefer to wire up new syscalls on
their own...

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

[RESEND PATCH] powerpc/fsl-pci: Correct use of ! and

[Himangi Saraogi]

In commit ae91d60ba88ef0bdb1b5e9b2363bd52fc45d2af7, a bug was fixed that
involved converting !x & y to !(x & y).  The code below shows the same
pattern, and thus should perhaps be fixed in the same way.

This is not tested and clearly changes the semantics, so it is only
something to consider.

The Coccinelle semantic patch that makes this change is as follows:

// 
@@ expression E1,E2; @@
(
  !E1 & !E2
|
- !E1 & E2
+ !(E1 & E2)
)
// 

Signed-off-by: Himangi Saraogi 
---
 arch/powerpc/sysdev/fsl_pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4bd091a..c507767 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -853,8 +853,8 @@ u64 fsl_pci_immrbar_base(struct pci_controller *hose)
in = pcie->cfg_type0 + PEX_RC_INWIN_BASE;
for (i = 0; i < 4; i++) {
/* not enabled, skip */
-   if (!in_le32([i].ar) & PEX_RCIWARn_EN)
-continue;
+   if (!(in_le32([i].ar) & PEX_RCIWARn_EN))
+   continue;
 
if (get_immrbase() == in_le32([i].tar))
return (u64)in_le32([i].barh) << 32 |
-- 
1.9.1

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

[PATCH] ACPI / PM: Use ACPI_COMPANION() instead of ACPI_HANDLE()

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The ACPI_HANDLE() macro evaluates ACPI_COMPANION() internally to
return the handle of the device's ACPI companion, so it is much
more straightforward and efficient to use ACPI_COMPANION()
directly to obtain the device's ACPI companion object instead of
using ACPI_HANDLE() and acpi_bus_get_device() on the returned
handle for the same thing.

Do that in three places in the ACPI device PM code.

Signed-off-by: Rafael J. Wysocki 
---

On top of https://patchwork.kernel.org/patch/4589941/

---
 drivers/acpi/device_pm.c |   21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -558,7 +558,6 @@ static int acpi_dev_pm_get_state(struct
  */
 int acpi_pm_device_sleep_state(struct device *dev, int *d_min_p, int d_max_in)
 {
-   acpi_handle handle = ACPI_HANDLE(dev);
struct acpi_device *adev;
int ret, d_min, d_max;
 
@@ -573,8 +572,9 @@ int acpi_pm_device_sleep_state(struct de
d_max_in = ACPI_STATE_D3_HOT;
}
 
-   if (!handle || acpi_bus_get_device(handle, )) {
-   dev_dbg(dev, "ACPI handle without context in %s!\n", __func__);
+   adev = ACPI_COMPANION(dev);
+   if (!adev) {
+   dev_dbg(dev, "ACPI companion missing in %s!\n", __func__);
return -ENODEV;
}
 
@@ -664,15 +664,13 @@ static void acpi_device_pm_event(acpi_ha
 int acpi_pm_device_run_wake(struct device *phys_dev, bool enable)
 {
struct acpi_device *adev;
-   acpi_handle handle;
 
if (!device_run_wake(phys_dev))
return -EINVAL;
 
-   handle = ACPI_HANDLE(phys_dev);
-   if (!handle || acpi_bus_get_device(handle, )) {
-   dev_dbg(phys_dev, "ACPI handle without context in %s!\n",
-   __func__);
+   adev = ACPI_COMPANION(phys_dev);
+   if (!adev) {
+   dev_dbg(phys_dev, "ACPI companion missing in %s!\n", __func__);
return -ENODEV;
}
 
@@ -692,16 +690,15 @@ static inline void acpi_device_pm_event(
  */
 int acpi_pm_device_sleep_wake(struct device *dev, bool enable)
 {
-   acpi_handle handle;
struct acpi_device *adev;
int error;
 
if (!device_can_wakeup(dev))
return -EINVAL;
 
-   handle = ACPI_HANDLE(dev);
-   if (!handle || acpi_bus_get_device(handle, )) {
-   dev_dbg(dev, "ACPI handle without context in %s!\n", __func__);
+   adev = ACPI_COMPANION(dev);
+   if (!adev) {
+   dev_dbg(dev, "ACPI companion missing in %s!\n", __func__);
return -ENODEV;
}
 

--
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] drm intel fixes

[Dave Airlie]

Hi Linus,

Intel fixes came in late, but since I debugged one of them I'll send them 
on,

two reverts, a quirk and one warn regression.

Dave.

The following changes since commit b579fcca32b7eaef7c346dff55adc953b56bb1a8:

  Merge tag 'rdma-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband (2014-07-18 
20:39:34 -1000)

are available in the git repository at:


  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to e898c791e1a4c27fa1f221058b29b0ad06ddf8b0:

  Merge tag 'drm-intel-fixes-2014-07-18' of 
git://anongit.freedesktop.org/drm-intel (2014-07-19 16:48:38 +1000)



Daniel Vetter (2):
  Revert "drm/i915: Don't set the 8to6 dither flag when not scaling"
  drm/i915: Track the primary plane correctly when reassigning planes

Dave Airlie (2):
  Revert "drm/i915: reverse dp link param selection, prefer fast over wide 
again"
  Merge tag 'drm-intel-fixes-2014-07-18' of 
git://anongit.freedesktop.org/drm-intel

Scot Doyle (1):
  drm/i915: Ignore VBT backlight presence check on HP Chromebook 14

 drivers/gpu/drm/i915/intel_display.c | 4 
 drivers/gpu/drm/i915/intel_dp.c  | 4 ++--
 drivers/gpu/drm/i915/intel_lvds.c| 7 +++
 drivers/gpu/drm/i915/intel_panel.c   | 8 
 4 files changed, 17 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mips: Remove uneeded line in cmp_smp_finish

[Nick Krause]

On Sat, Jul 19, 2014 at 8:05 AM, Paul Bolle  wrote:
> On Sat, 2014-07-19 at 01:10 -0400, Nicholas Krause wrote:
>> This patch removes a unneeded line from this file as stated by the
>> fix me in this file.
>>
>> Signed-off-by: Nicholas Krause 
>> ---
>>  arch/mips/kernel/smp-cmp.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/mips/kernel/smp-cmp.c b/arch/mips/kernel/smp-cmp.c
>> index fc8a515..61bfa20 100644
>> --- a/arch/mips/kernel/smp-cmp.c
>> +++ b/arch/mips/kernel/smp-cmp.c
>> @@ -60,8 +60,6 @@ static void cmp_smp_finish(void)
>>  {
>>   pr_debug("SMPCMP: CPU%d: %s\n", smp_processor_id(), __func__);
>>
>> - /* CDFIXME: remove this? */
>> - write_c0_compare(read_c0_count() + (8 * mips_hpt_frequency / HZ));
>
> That comment ends in a question mark. I wonder why...
>
>>  #ifdef CONFIG_MIPS_MT_FPAFF
>>   /* If we have an FPU, enroll ourselves in the FPU-full mask */
>
>
> Paul Bolle
>
If we need it then can I remove the FIx me comment.
Cheers Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] Input - wacom: battery enhancements and unifying hid-wacom and wacom

[Przemo Firszt]

Dnia 2014-07-10, czw o godzinie 14:44 -0400, Benjamin Tissoires pisze:
> Hi guys,
> 
> Continuing on the Wacom cleanup, here are 5 patches.
> 
> The first two enhance the battery reporting for the Wireless receiver by
> adding the status of the battery (discharging, full, charging) - inspired by
> the code found in hid-wacom.c, and also by adding notifications to the power
> system so that upower knows when the battery changed.
> 
> The last three are the handling of the two Wacom Bluetooth devices in 
> wacom.ko.
> Some enhancements here:
> - Intuos4 now supports other tools than just the plain stylus (mouse, artpen, 
> ...)
> - one less driver for Wacom (~700 lines of code less in total)
> - unifying access to LEDs/OLEDs from Bluetooth and USB devices
> 
> However, I did not backport the speed attribute and the ac power device (which
> is infered by the battery status). I don't know if there are users of those 
> two,
> so I let them aside for now. Przemo, any ideas if this is actually used?
> 
> This whole code is based on top of the previous HID conversion patches.
> I pushed a branch with all I have queued on the list here:
> https://github.com/bentiss/linux/commits/hid-wacom-legacy-3.16-rc4
> 
> Again, given that there has been no answer on how this can be merged upstream
> (Jiri? Dmitry?), I just piled those on top of the previous.
> I wouldn't to resplit the input and hid specific changes if this is the choice
> that is made.
> 
> Cheers,
> Benjamin
> 
> Benjamin Tissoires (5):
>   Input - wacom: enhance Wireless Receiver battery reporting
>   Input - wacom: use a specific name for the battery device
>   Input - wacom: handle Graphire BT tablets in wacom.ko
>   Input - wacom: handle Intuos 4 BT in wacom.ko
>   HID: remove hid-wacom Bluetooth driver
> 
>  drivers/hid/Kconfig  |   8 -
>  drivers/hid/Makefile |   1 -
>  drivers/hid/hid-core.c   |   2 -
>  drivers/hid/hid-wacom.c  | 973 
> ---
>  drivers/input/tablet/wacom.h |   6 +
>  drivers/input/tablet/wacom_sys.c | 114 -
>  drivers/input/tablet/wacom_wac.c | 189 +++-
>  drivers/input/tablet/wacom_wac.h |   8 +
>  8 files changed, 303 insertions(+), 998 deletions(-)
>  delete mode 100644 drivers/hid/hid-wacom.c
> 
Benjamin,
I think we might try to fix that [1] as well when making changes to the
sysfs entries. Currently every tablet connected wirelessly will trigger
creating new sysfs entries:

/sys/class/power_supply/wacom_ac
/sys/class/power_supply/wacom_battery

so sysfs is not happy about attempts to create duplicates. We need to
distinguish between devices using consecutive numbers or something else.

[1] https://sourceforge.net/p/linuxwacom/bugs/248/
-- 
Kind regards,
Przemo Firszt


--
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:iio:ad7280a: Use managed interfaces

[Julia Lawall]

On Sat, 19 Jul 2014, Jonathan Cameron wrote:

> On 19/07/14 21:46, Julia Lawall wrote:
> > 
> > 
> > On Sat, 19 Jul 2014, Jonathan Cameron wrote:
> > 
> > > On 19/07/14 11:33, Himangi Saraogi wrote:
> > > > This patch moves data allocated using unmanaged interfaces to managed
> > > > interfaces like devm_kzalloc, devm_iio_device_register, devm_kasprintf,
> > > > devm_request_threaded_irq and does away with the calls to free the
> > > > allocated memory in the probe and remove functions. Some labels in the
> > > > probe function are also removed.
> > > > 
> > > > Signed-off-by: Himangi Saraogi 
> > > cc'ing Lars who tends to look after Analog Devices drivers
> > > and more specifically was involved in the thread that lead to this
> > > patch.
> > > 
> > > Also, the devm_kasprintf does not appear to be in upstream so this
> > > patch should have made an dependency clear.
> > > 
> > > https://lkml.org/lkml/2014/7/16/667
> > > 
> > > What is the intended merge path for that patch?
> > 
> > Greg said that he would be taking it.  He already took the devm_kasprintf
> > patch.
> Cool.  That's fine (and now you mention it - he did say that in the thread
> I just forgot).  Still, it did want mentioning in the description for this
> patch as well.

Indeed.  Sorry about that.

julia

> > 
> > julia
> > 
> > > 
> > > 
> > > > ---
> > > > I am not very sure if devmifying request_irq is a good idea as it
> > > > leads to the freeing of the interrupt after the ad7280_write.
> > > Agreed. I wouldn't do it!
> > > 
> > > Otherwise, all looks fine.
> > > >drivers/staging/iio/adc/ad7280a.c | 57
> > > > ++-
> > > >1 file changed, 20 insertions(+), 37 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/iio/adc/ad7280a.c
> > > > b/drivers/staging/iio/adc/ad7280a.c
> > > > index d215edf..3706b3e 100644
> > > > --- a/drivers/staging/iio/adc/ad7280a.c
> > > > +++ b/drivers/staging/iio/adc/ad7280a.c
> > > > @@ -486,8 +486,8 @@ static int ad7280_channel_init(struct ad7280_state
> > > > *st)
> > > >{
> > > > int dev, ch, cnt;
> > > > 
> > > > -   st->channels = kcalloc((st->slave_num + 1) * 12 + 2,
> > > > -  sizeof(*st->channels), GFP_KERNEL);
> > > > +   st->channels = devm_kcalloc(>spi->dev, (st->slave_num + 1) 
> > > > * 12 +
> > > > 2,
> > > > +   sizeof(*st->channels), GFP_KERNEL);
> > > > if (st->channels == NULL)
> > > > return -ENOMEM;
> > > > 
> > > > @@ -547,8 +547,9 @@ static int ad7280_attr_init(struct ad7280_state *st)
> > > >{
> > > > int dev, ch, cnt;
> > > > 
> > > > -   st->iio_attr = kzalloc(sizeof(*st->iio_attr) * (st->slave_num + 
> > > > 1) *
> > > > -   AD7280A_CELLS_PER_DEV * 2, GFP_KERNEL);
> > > > +   st->iio_attr = devm_kzalloc(>spi->dev, 
> > > > sizeof(*st->iio_attr) *
> > > > +   (st->slave_num + 1) *
> > > > +   AD7280A_CELLS_PER_DEV * 2, 
> > > > GFP_KERNEL);
> > > > if (st->iio_attr == NULL)
> > > > return -ENOMEM;
> > > > 
> > > > @@ -564,7 +565,7 @@ static int ad7280_attr_init(struct ad7280_state *st)
> > > > st->iio_attr[cnt].dev_attr.store =
> > > > ad7280_store_balance_sw;
> > > > st->iio_attr[cnt].dev_attr.attr.name =
> > > > -   kasprintf(GFP_KERNEL,
> > > > +   devm_kasprintf(>spi->dev, 
> > > > GFP_KERNEL,
> > > > "in%d-in%d_balance_switch_en",
> > > > (dev * AD7280A_CELLS_PER_DEV)
> > > > + ch,
> > > > (dev * AD7280A_CELLS_PER_DEV)
> > > > + ch +
> > > > 1);
> > > > @@ -581,7 +582,8 @@ static int ad7280_attr_init(struct ad7280_state *st)
> > > > st->iio_attr[cnt].dev_attr.store =
> > > > ad7280_store_balance_timer;
> > > > st->iio_attr[cnt].dev_attr.attr.name =
> > > > -   kasprintf(GFP_KERNEL,
> > > > "in%d-in%d_balance_timer",
> > > > +   devm_kasprintf(>spi->dev, 
> > > > GFP_KERNEL,
> > > > +   "in%d-in%d_balance_timer",
> > > > (dev * AD7280A_CELLS_PER_DEV)
> > > > + ch,
> > > > (dev * AD7280A_CELLS_PER_DEV)
> > > > + ch +
> > > > 1);
> > > > ad7280_attributes[cnt] =
> > > > @@ -900,48 +902,36 @@ static int ad7280_probe(struct spi_device *spi)
> > > > 
> > > > ret = ad7280_attr_init(st);
> > > > if (ret < 0)
> > > > -   goto error_free_channels;
> > > > +   return ret;
> > > > 
> > > > -   ret = iio_device_register(indio_dev);
> > > > 

Re: [PATCH] staging:iio:ad7280a: Use managed interfaces

[Jonathan Cameron]

On 19/07/14 21:46, Julia Lawall wrote:



On Sat, 19 Jul 2014, Jonathan Cameron wrote:


On 19/07/14 11:33, Himangi Saraogi wrote:

This patch moves data allocated using unmanaged interfaces to managed
interfaces like devm_kzalloc, devm_iio_device_register, devm_kasprintf,
devm_request_threaded_irq and does away with the calls to free the
allocated memory in the probe and remove functions. Some labels in the
probe function are also removed.

Signed-off-by: Himangi Saraogi 

cc'ing Lars who tends to look after Analog Devices drivers
and more specifically was involved in the thread that lead to this
patch.

Also, the devm_kasprintf does not appear to be in upstream so this
patch should have made an dependency clear.

https://lkml.org/lkml/2014/7/16/667

What is the intended merge path for that patch?


Greg said that he would be taking it.  He already took the devm_kasprintf
patch.

Cool.  That's fine (and now you mention it - he did say that in the thread
I just forgot).  Still, it did want mentioning in the description for this
patch as well.


julia





---
I am not very sure if devmifying request_irq is a good idea as it
leads to the freeing of the interrupt after the ad7280_write.

Agreed. I wouldn't do it!

Otherwise, all looks fine.

   drivers/staging/iio/adc/ad7280a.c | 57
++-
   1 file changed, 20 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7280a.c
b/drivers/staging/iio/adc/ad7280a.c
index d215edf..3706b3e 100644
--- a/drivers/staging/iio/adc/ad7280a.c
+++ b/drivers/staging/iio/adc/ad7280a.c
@@ -486,8 +486,8 @@ static int ad7280_channel_init(struct ad7280_state *st)
   {
int dev, ch, cnt;

-   st->channels = kcalloc((st->slave_num + 1) * 12 + 2,
-  sizeof(*st->channels), GFP_KERNEL);
+   st->channels = devm_kcalloc(>spi->dev, (st->slave_num + 1) * 12 +
2,
+   sizeof(*st->channels), GFP_KERNEL);
if (st->channels == NULL)
return -ENOMEM;

@@ -547,8 +547,9 @@ static int ad7280_attr_init(struct ad7280_state *st)
   {
int dev, ch, cnt;

-   st->iio_attr = kzalloc(sizeof(*st->iio_attr) * (st->slave_num + 1) *
-   AD7280A_CELLS_PER_DEV * 2, GFP_KERNEL);
+   st->iio_attr = devm_kzalloc(>spi->dev, sizeof(*st->iio_attr) *
+   (st->slave_num + 1) *
+   AD7280A_CELLS_PER_DEV * 2, GFP_KERNEL);
if (st->iio_attr == NULL)
return -ENOMEM;

@@ -564,7 +565,7 @@ static int ad7280_attr_init(struct ad7280_state *st)
st->iio_attr[cnt].dev_attr.store =
ad7280_store_balance_sw;
st->iio_attr[cnt].dev_attr.attr.name =
-   kasprintf(GFP_KERNEL,
+   devm_kasprintf(>spi->dev, GFP_KERNEL,
"in%d-in%d_balance_switch_en",
(dev * AD7280A_CELLS_PER_DEV) + ch,
(dev * AD7280A_CELLS_PER_DEV) + ch +
1);
@@ -581,7 +582,8 @@ static int ad7280_attr_init(struct ad7280_state *st)
st->iio_attr[cnt].dev_attr.store =
ad7280_store_balance_timer;
st->iio_attr[cnt].dev_attr.attr.name =
-   kasprintf(GFP_KERNEL,
"in%d-in%d_balance_timer",
+   devm_kasprintf(>spi->dev, GFP_KERNEL,
+   "in%d-in%d_balance_timer",
(dev * AD7280A_CELLS_PER_DEV) + ch,
(dev * AD7280A_CELLS_PER_DEV) + ch +
1);
ad7280_attributes[cnt] =
@@ -900,48 +902,36 @@ static int ad7280_probe(struct spi_device *spi)

ret = ad7280_attr_init(st);
if (ret < 0)
-   goto error_free_channels;
+   return ret;

-   ret = iio_device_register(indio_dev);
+   ret = devm_iio_device_register(>dev, indio_dev);
if (ret)
-   goto error_free_attr;
+   return ret;

if (spi->irq > 0) {
ret = ad7280_write(st, AD7280A_DEVADDR_MASTER,
   AD7280A_ALERT, 1,
   AD7280A_ALERT_RELAY_SIG_CHAIN_DOWN);
if (ret)
-   goto error_unregister;
+   return ret;

ret = ad7280_write(st, AD7280A_DEVADDR(st->slave_num),
   AD7280A_ALERT, 0,
   AD7280A_ALERT_GEN_STATIC_HIGH |
   (pdata->chain_last_alert_ignore & 0xF));
if (ret)
-   goto error_unregister;
-
-   ret = request_threaded_irq(spi->irq,
-  

Re: [PATCH 2/4] ARM: add IPI tracepoints

[Ard Biesheuvel]

On 19 July 2014 22:28, Steven Rostedt  wrote:
> On Sat, 19 Jul 2014 21:10:37 +0200
> Ard Biesheuvel  wrote:
>
>> On 18 July 2014 23:22, Steven Rostedt  wrote:
>> > On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
>> > Nicolas Pitre  wrote:
>> >
>> >>
>> >> Here's the patch I have at the head of the series now, with the above
>> >> ugliness changed to an unconditional __tracepoint_string attribute.
>> >>
>> >
>> > I was thinking of something like this. Feel free to add this to your
>> > series.
>> >
>> > -- Steve
>> >
>>
>> Nico,
>>
>> If this patch addresses the issue where 3 RCU related tracepoint
>> strings turn up /after/ _edata on !CONFIG_TRACING, there is already a
>> patch queued up here
>>
>> http://marc.info/?l=linux-kernel=140518452623148=2
>>
>> As far as In know, these were the only occurrences using a __used
>> modifier, which is why they weren't dropped by the compiler in the
>> !CONFIG_TRACING case.
>>
>
> Ard,
>
> Similar but different problem. Nicolas's problem was with new use cases
> for tracepoint_string. My patch fixes the issue for the general case.
>

OK, so if the general case has been fixed, perhaps we should ask Paul
to drop my patch?

-- 
Ard.
--
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:iio:ad7280a: Use managed interfaces

[Julia Lawall]

On Sat, 19 Jul 2014, Jonathan Cameron wrote:

> On 19/07/14 11:33, Himangi Saraogi wrote:
> > This patch moves data allocated using unmanaged interfaces to managed
> > interfaces like devm_kzalloc, devm_iio_device_register, devm_kasprintf,
> > devm_request_threaded_irq and does away with the calls to free the
> > allocated memory in the probe and remove functions. Some labels in the
> > probe function are also removed.
> > 
> > Signed-off-by: Himangi Saraogi 
> cc'ing Lars who tends to look after Analog Devices drivers
> and more specifically was involved in the thread that lead to this
> patch.
> 
> Also, the devm_kasprintf does not appear to be in upstream so this
> patch should have made an dependency clear.
> 
> https://lkml.org/lkml/2014/7/16/667
> 
> What is the intended merge path for that patch?

Greg said that he would be taking it.  He already took the devm_kasprintf 
patch.

julia

> 
> 
> > ---
> > I am not very sure if devmifying request_irq is a good idea as it
> > leads to the freeing of the interrupt after the ad7280_write.
> Agreed. I wouldn't do it!
> 
> Otherwise, all looks fine.
> >   drivers/staging/iio/adc/ad7280a.c | 57
> > ++-
> >   1 file changed, 20 insertions(+), 37 deletions(-)
> > 
> > diff --git a/drivers/staging/iio/adc/ad7280a.c
> > b/drivers/staging/iio/adc/ad7280a.c
> > index d215edf..3706b3e 100644
> > --- a/drivers/staging/iio/adc/ad7280a.c
> > +++ b/drivers/staging/iio/adc/ad7280a.c
> > @@ -486,8 +486,8 @@ static int ad7280_channel_init(struct ad7280_state *st)
> >   {
> > int dev, ch, cnt;
> > 
> > -   st->channels = kcalloc((st->slave_num + 1) * 12 + 2,
> > -  sizeof(*st->channels), GFP_KERNEL);
> > +   st->channels = devm_kcalloc(>spi->dev, (st->slave_num + 1) * 12 +
> > 2,
> > +   sizeof(*st->channels), GFP_KERNEL);
> > if (st->channels == NULL)
> > return -ENOMEM;
> > 
> > @@ -547,8 +547,9 @@ static int ad7280_attr_init(struct ad7280_state *st)
> >   {
> > int dev, ch, cnt;
> > 
> > -   st->iio_attr = kzalloc(sizeof(*st->iio_attr) * (st->slave_num + 1) *
> > -   AD7280A_CELLS_PER_DEV * 2, GFP_KERNEL);
> > +   st->iio_attr = devm_kzalloc(>spi->dev, sizeof(*st->iio_attr) *
> > +   (st->slave_num + 1) *
> > +   AD7280A_CELLS_PER_DEV * 2, GFP_KERNEL);
> > if (st->iio_attr == NULL)
> > return -ENOMEM;
> > 
> > @@ -564,7 +565,7 @@ static int ad7280_attr_init(struct ad7280_state *st)
> > st->iio_attr[cnt].dev_attr.store =
> > ad7280_store_balance_sw;
> > st->iio_attr[cnt].dev_attr.attr.name =
> > -   kasprintf(GFP_KERNEL,
> > +   devm_kasprintf(>spi->dev, GFP_KERNEL,
> > "in%d-in%d_balance_switch_en",
> > (dev * AD7280A_CELLS_PER_DEV) + ch,
> > (dev * AD7280A_CELLS_PER_DEV) + ch +
> > 1);
> > @@ -581,7 +582,8 @@ static int ad7280_attr_init(struct ad7280_state *st)
> > st->iio_attr[cnt].dev_attr.store =
> > ad7280_store_balance_timer;
> > st->iio_attr[cnt].dev_attr.attr.name =
> > -   kasprintf(GFP_KERNEL,
> > "in%d-in%d_balance_timer",
> > +   devm_kasprintf(>spi->dev, GFP_KERNEL,
> > +   "in%d-in%d_balance_timer",
> > (dev * AD7280A_CELLS_PER_DEV) + ch,
> > (dev * AD7280A_CELLS_PER_DEV) + ch +
> > 1);
> > ad7280_attributes[cnt] =
> > @@ -900,48 +902,36 @@ static int ad7280_probe(struct spi_device *spi)
> > 
> > ret = ad7280_attr_init(st);
> > if (ret < 0)
> > -   goto error_free_channels;
> > +   return ret;
> > 
> > -   ret = iio_device_register(indio_dev);
> > +   ret = devm_iio_device_register(>dev, indio_dev);
> > if (ret)
> > -   goto error_free_attr;
> > +   return ret;
> > 
> > if (spi->irq > 0) {
> > ret = ad7280_write(st, AD7280A_DEVADDR_MASTER,
> >AD7280A_ALERT, 1,
> >AD7280A_ALERT_RELAY_SIG_CHAIN_DOWN);
> > if (ret)
> > -   goto error_unregister;
> > +   return ret;
> > 
> > ret = ad7280_write(st, AD7280A_DEVADDR(st->slave_num),
> >AD7280A_ALERT, 0,
> >AD7280A_ALERT_GEN_STATIC_HIGH |
> >(pdata->chain_last_alert_ignore & 0xF));
> > if (ret)
> > -   goto error_unregister;
> > -
> > -   ret = request_threaded_irq(spi->irq,
> > -  NULL,
> > -

Re: [PATCH] staging:iio:ad7280a: Use managed interfaces

[Jonathan Cameron]

On 19/07/14 11:33, Himangi Saraogi wrote:

This patch moves data allocated using unmanaged interfaces to managed
interfaces like devm_kzalloc, devm_iio_device_register, devm_kasprintf,
devm_request_threaded_irq and does away with the calls to free the
allocated memory in the probe and remove functions. Some labels in the
probe function are also removed.

Signed-off-by: Himangi Saraogi 

cc'ing Lars who tends to look after Analog Devices drivers
and more specifically was involved in the thread that lead to this
patch.

Also, the devm_kasprintf does not appear to be in upstream so this
patch should have made an dependency clear.

https://lkml.org/lkml/2014/7/16/667

What is the intended merge path for that patch?



---
I am not very sure if devmifying request_irq is a good idea as it
leads to the freeing of the interrupt after the ad7280_write.

Agreed. I wouldn't do it!

Otherwise, all looks fine.

  drivers/staging/iio/adc/ad7280a.c | 57 ++-
  1 file changed, 20 insertions(+), 37 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7280a.c 
b/drivers/staging/iio/adc/ad7280a.c
index d215edf..3706b3e 100644
--- a/drivers/staging/iio/adc/ad7280a.c
+++ b/drivers/staging/iio/adc/ad7280a.c
@@ -486,8 +486,8 @@ static int ad7280_channel_init(struct ad7280_state *st)
  {
int dev, ch, cnt;

-   st->channels = kcalloc((st->slave_num + 1) * 12 + 2,
-  sizeof(*st->channels), GFP_KERNEL);
+   st->channels = devm_kcalloc(>spi->dev, (st->slave_num + 1) * 12 + 2,
+   sizeof(*st->channels), GFP_KERNEL);
if (st->channels == NULL)
return -ENOMEM;

@@ -547,8 +547,9 @@ static int ad7280_attr_init(struct ad7280_state *st)
  {
int dev, ch, cnt;

-   st->iio_attr = kzalloc(sizeof(*st->iio_attr) * (st->slave_num + 1) *
-   AD7280A_CELLS_PER_DEV * 2, GFP_KERNEL);
+   st->iio_attr = devm_kzalloc(>spi->dev, sizeof(*st->iio_attr) *
+   (st->slave_num + 1) *
+   AD7280A_CELLS_PER_DEV * 2, GFP_KERNEL);
if (st->iio_attr == NULL)
return -ENOMEM;

@@ -564,7 +565,7 @@ static int ad7280_attr_init(struct ad7280_state *st)
st->iio_attr[cnt].dev_attr.store =
ad7280_store_balance_sw;
st->iio_attr[cnt].dev_attr.attr.name =
-   kasprintf(GFP_KERNEL,
+   devm_kasprintf(>spi->dev, GFP_KERNEL,
"in%d-in%d_balance_switch_en",
(dev * AD7280A_CELLS_PER_DEV) + ch,
(dev * AD7280A_CELLS_PER_DEV) + ch + 1);
@@ -581,7 +582,8 @@ static int ad7280_attr_init(struct ad7280_state *st)
st->iio_attr[cnt].dev_attr.store =
ad7280_store_balance_timer;
st->iio_attr[cnt].dev_attr.attr.name =
-   kasprintf(GFP_KERNEL, "in%d-in%d_balance_timer",
+   devm_kasprintf(>spi->dev, GFP_KERNEL,
+   "in%d-in%d_balance_timer",
(dev * AD7280A_CELLS_PER_DEV) + ch,
(dev * AD7280A_CELLS_PER_DEV) + ch + 1);
ad7280_attributes[cnt] =
@@ -900,48 +902,36 @@ static int ad7280_probe(struct spi_device *spi)

ret = ad7280_attr_init(st);
if (ret < 0)
-   goto error_free_channels;
+   return ret;

-   ret = iio_device_register(indio_dev);
+   ret = devm_iio_device_register(>dev, indio_dev);
if (ret)
-   goto error_free_attr;
+   return ret;

if (spi->irq > 0) {
ret = ad7280_write(st, AD7280A_DEVADDR_MASTER,
   AD7280A_ALERT, 1,
   AD7280A_ALERT_RELAY_SIG_CHAIN_DOWN);
if (ret)
-   goto error_unregister;
+   return ret;

ret = ad7280_write(st, AD7280A_DEVADDR(st->slave_num),
   AD7280A_ALERT, 0,
   AD7280A_ALERT_GEN_STATIC_HIGH |
   (pdata->chain_last_alert_ignore & 0xF));
if (ret)
-   goto error_unregister;
-
-   ret = request_threaded_irq(spi->irq,
-  NULL,
-  ad7280_event_handler,
-  IRQF_TRIGGER_FALLING |
-  IRQF_ONESHOT,
-  indio_dev->name,
-  indio_dev);
+   return ret;
+
+   

Re: [PATCH 2/4] ARM: add IPI tracepoints

[Steven Rostedt]

On Sat, 19 Jul 2014 21:10:37 +0200
Ard Biesheuvel  wrote:

> On 18 July 2014 23:22, Steven Rostedt  wrote:
> > On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
> > Nicolas Pitre  wrote:
> >
> >>
> >> Here's the patch I have at the head of the series now, with the above
> >> ugliness changed to an unconditional __tracepoint_string attribute.
> >>
> >
> > I was thinking of something like this. Feel free to add this to your
> > series.
> >
> > -- Steve
> >
> 
> Nico,
> 
> If this patch addresses the issue where 3 RCU related tracepoint
> strings turn up /after/ _edata on !CONFIG_TRACING, there is already a
> patch queued up here
> 
> http://marc.info/?l=linux-kernel=140518452623148=2
> 
> As far as In know, these were the only occurrences using a __used
> modifier, which is why they weren't dropped by the compiler in the
> !CONFIG_TRACING case.
> 

Ard,

Similar but different problem. Nicolas's problem was with new use cases
for tracepoint_string. My patch fixes the issue for the general case.

-- Steve


--
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: ls -l /proc/1/exe -> Permission denied

[Andreas Schwab]

Joakim Tjernlund  writes:

> Trying to real /proc//exe I noticed I could not read links not 
> belonging to my user such as:
> jocke >  ls -l /proc/1/exe
>  ls: cannot read symbolic link /proc/1/exe: Permission denied
>
> Is this expected?

Yes.  This information is considered private.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] ACPI / PM: Make ACPI-based PCI wakeup work for the "freeze" sleep state

[Rafael J. Wysocki]

Hi,

As per the subject, this is to make ACPI-based PCI wakeup (such as WoL on some
systems among other things) work with the "freeze" sleep state.  For this
purpose ACPI wakeup GPEs need to be enabled for wakeup devices before
freeze_enter() is called and it is best to do that when configuring devices
for wakeup.

[1/2] Always enable wakeup GPEs when configuring devices for wakeup
[2/2] Rename one static function to avoid possible future confusion

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] ACPI / PM: Always enable wakeup GPEs when enabling device wakeup

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Wakeup GPEs are currently only enabled when setting up devices for
remote wakeup at run time.  During system-wide transitions they are
enabled by ACPICA at the very last stage of suspend (before asking
the BIOS to take over).  Of course, that only works for system
sleep states supported by ACPI, so in particular it doesn't work
for the "freeze" sleep state.

For this reason, modify the ACPI core device PM code to enable wakeup
GPEs for devices when setting them up for wakeup regardless of whether
that is remote wakeup at runtime or system wakeup.  That allows the
same device wakeup setup routine to be used for both runtime PM and
system-wide PM and makes it possible to reduce code size quite a bit.

That should make things like ACPI-based PCI Wake-on-LAN work with
the "freeze" sleep state among other things.

Tested-on: Toshiba Portege R500
Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/device_pm.c |   80 +++
 include/acpi/acpi_bus.h  |   11 --
 2 files changed, 34 insertions(+), 57 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -600,26 +600,10 @@ int acpi_pm_device_sleep_state(struct de
 }
 EXPORT_SYMBOL(acpi_pm_device_sleep_state);
 
-#ifdef CONFIG_PM_RUNTIME
-/**
- * acpi_wakeup_device - Wakeup notification handler for ACPI devices.
- * @handle: ACPI handle of the device the notification is for.
- * @event: Type of the signaled event.
- * @context: Device corresponding to @handle.
- */
-static void acpi_wakeup_device(acpi_handle handle, u32 event, void *context)
-{
-   struct device *dev = context;
-
-   if (event == ACPI_NOTIFY_DEVICE_WAKE && dev) {
-   pm_wakeup_event(dev, 0);
-   pm_runtime_resume(dev);
-   }
-}
-
 /**
- * __acpi_device_run_wake - Enable/disable runtime remote wakeup for device.
- * @adev: ACPI device to enable/disable the remote wakeup for.
+ * acpi_device_wakeup - Enable/disable wakeup functionality for device.
+ * @adev: ACPI device to enable/disable wakeup functionality for.
+ * @target_state: State the system is transitioning into.
  * @enable: Whether to enable or disable the wakeup functionality.
  *
  * Enable/disable the GPE associated with @adev so that it can generate
@@ -629,7 +613,8 @@ static void acpi_wakeup_device(acpi_hand
  * Callers must ensure that @adev is a valid ACPI device node before executing
  * this function.
  */
-int __acpi_device_run_wake(struct acpi_device *adev, bool enable)
+static int acpi_device_wakeup(struct acpi_device *adev, u32 target_state,
+ bool enable)
 {
struct acpi_device_wakeup *wakeup = >wakeup;
 
@@ -637,7 +622,7 @@ int __acpi_device_run_wake(struct acpi_d
acpi_status res;
int error;
 
-   error = acpi_enable_wakeup_device_power(adev, ACPI_STATE_S0);
+   error = acpi_enable_wakeup_device_power(adev, target_state);
if (error)
return error;
 
@@ -653,6 +638,24 @@ int __acpi_device_run_wake(struct acpi_d
return 0;
 }
 
+#ifdef CONFIG_PM_RUNTIME
+/**
+ * acpi_wakeup_device - Wakeup notification handler for ACPI devices.
+ * @handle: ACPI handle of the device the notification is for.
+ * @event: Type of the signaled event.
+ * @context: Device corresponding to @handle.
+ */
+static void acpi_wakeup_device(acpi_handle handle, u32 event, void *context)
+{
+   struct device *dev = context;
+
+   if (event == ACPI_NOTIFY_DEVICE_WAKE && dev) {
+   pm_wakeup_event(dev, 0);
+   if (acpi_target_system_state() == ACPI_STATE_S0)
+   pm_runtime_resume(dev);
+   }
+}
+
 /**
  * acpi_pm_device_run_wake - Enable/disable remote wakeup for given device.
  * @dev: Device to enable/disable the platform to wake up.
@@ -673,7 +676,7 @@ int acpi_pm_device_run_wake(struct devic
return -ENODEV;
}
 
-   return __acpi_device_run_wake(adev, enable);
+   return acpi_device_wakeup(adev, enable, ACPI_STATE_S0);
 }
 EXPORT_SYMBOL(acpi_pm_device_run_wake);
 #else
@@ -683,20 +686,6 @@ static inline void acpi_wakeup_device(ac
 
 #ifdef CONFIG_PM_SLEEP
 /**
- * __acpi_device_sleep_wake - Enable or disable device to wake up the system.
- * @dev: Device to enable/desible to wake up the system.
- * @target_state: System state the device is supposed to wake up from.
- * @enable: Whether to enable or disable @dev to wake up the system.
- */
-int __acpi_device_sleep_wake(struct acpi_device *adev, u32 target_state,
-bool enable)
-{
-   return enable ?
-   acpi_enable_wakeup_device_power(adev, target_state) :
-   acpi_disable_wakeup_device_power(adev);
-}
-
-/**
  * acpi_pm_device_sleep_wake - Enable or disable device to wake up the 

[PATCH 2/2] ACPI / PM: Rename acpi_wakeup_device() to acpi_device_pm_event()

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

To avoid confusion with acpi_device_wakeup(), rename the default
ACPI device PM notify handler from acpi_wakeup_device() to
acpi_device_pm_event().

No functional changes.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/device_pm.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -640,12 +640,12 @@ static int acpi_device_wakeup(struct acp
 
 #ifdef CONFIG_PM_RUNTIME
 /**
- * acpi_wakeup_device - Wakeup notification handler for ACPI devices.
+ * acpi_device_pm_event - Wakeup notification handler for ACPI devices.
  * @handle: ACPI handle of the device the notification is for.
  * @event: Type of the signaled event.
  * @context: Device corresponding to @handle.
  */
-static void acpi_wakeup_device(acpi_handle handle, u32 event, void *context)
+static void acpi_device_pm_event(acpi_handle handle, u32 event, void *context)
 {
struct device *dev = context;
 
@@ -680,7 +680,7 @@ int acpi_pm_device_run_wake(struct devic
 }
 EXPORT_SYMBOL(acpi_pm_device_run_wake);
 #else
-static inline void acpi_wakeup_device(acpi_handle handle, u32 event,
+static inline void acpi_device_pm_event(acpi_handle handle, u32 event,
  void *context) {}
 #endif /* CONFIG_PM_RUNTIME */
 
@@ -1036,7 +1036,7 @@ int acpi_dev_pm_attach(struct device *de
if (dev->pm_domain)
return -EEXIST;
 
-   acpi_add_pm_notifier(adev, acpi_wakeup_device, dev);
+   acpi_add_pm_notifier(adev, acpi_device_pm_event, dev);
dev->pm_domain = _general_pm_domain;
if (power_on) {
acpi_dev_pm_full_power(adev);
@@ -1064,7 +1064,7 @@ void acpi_dev_pm_detach(struct device *d
 
if (adev && dev->pm_domain == _general_pm_domain) {
dev->pm_domain = NULL;
-   acpi_remove_pm_notifier(adev, acpi_wakeup_device);
+   acpi_remove_pm_notifier(adev, acpi_device_pm_event);
if (power_off) {
/*
 * If the device's PM QoS resume latency limit or flags

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

Re: [PATCH 1/5] tools/power/cpupower/utils/helpers/sysfs.c: drop negativity check on unsigned value

[Rafael J. Wysocki]

On Saturday, July 19, 2014 10:14:04 PM Andrey Utkin wrote:
> Resubmitting to send also to linux...@vger.kernel.org as requested by
> Rafael J. Wysocki 
> 
> ---8<---
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80621
> Reported-by: David Binderman 
> Signed-off-by: Andrey Utkin 

Queued up for 3.17, thanks!

> ---
>  tools/power/cpupower/utils/helpers/sysfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/power/cpupower/utils/helpers/sysfs.c 
> b/tools/power/cpupower/utils/helpers/sysfs.c
> index 851c7a1..09afe5d 100644
> --- a/tools/power/cpupower/utils/helpers/sysfs.c
> +++ b/tools/power/cpupower/utils/helpers/sysfs.c
> @@ -81,7 +81,7 @@ int sysfs_is_cpu_online(unsigned int cpu)
>   close(fd);
>  
>   value = strtoull(linebuf, , 0);
> - if (value > 1 || value < 0)
> + if (value > 1)
>   return -EINVAL;
>  
>   return value;
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] Please pull NFS client changes

[Trond Myklebust]

Hi Linus,

Apologies for the relative lateness of this pull request, however the
commits fix some issues with the NFS read/write code updates in 3.16-rc1
that can cause serious Oopsing when using small r/wsize. The delay was
mainly due to extra testing to make sure that the fixes behave
correctly.

The following changes since commit 66b068604903849c5dee3842eb72564064c64c72:

  NFSv4: test SECINFO RPC_AUTH_GSS pseudoflavors for support (2014-06-24 
18:46:58 -0400)

are available in the git repository at:

  git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-3.16-3

for you to fetch changes up to f563b89b182594f827b4100bd34f916339785a77:

  NFS: Don't reset pg_moreio in __nfs_pageio_add_request (2014-07-13 15:18:44 
-0400)


NFS client fixes for Linux 3.16

Highlights include;
- Stable fix for an NFSv3 posix ACL regression
- Multiple fixes for regressions to the NFS generic read/write code
  - Fix page splitting bugs that come into play when a small rsize/wsize
read/write needs to be sent again (due to error conditions or page
redirty).
  - Fix nfs_wb_page_cancel, which is called by the "invalidatepage" method
- Fix 2 compile warnings about unused variables.
- Fix a performance issue affecting unstable writes.


Christoph Hellwig (1):
  nfs: only show Posix ACLs in listxattr if actually present

Trond Myklebust (2):
  NFS: Remove 2 unused variables
  NFS: Don't reset pg_moreio in __nfs_pageio_add_request

Weston Andros Adamson (5):
  nfs: mark nfs_page reqs with flag for extra ref
  nfs: nfs_page should take a ref on the head req
  nfs: change find_request to find_head_request
  nfs: handle multiple reqs in nfs_page_async_flush
  nfs: handle multiple reqs in nfs_wb_page_cancel

 fs/nfs/direct.c   |   2 -
 fs/nfs/internal.h |   1 +
 fs/nfs/nfs3acl.c  |  43 +++
 fs/nfs/nfs3proc.c |   4 +-
 fs/nfs/pagelist.c |  20 +++-
 fs/nfs/write.c| 335 +-
 6 files changed, 343 insertions(+), 62 deletions(-)



-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.mykleb...@primarydata.com



signature.asc
Description: This is a digitally signed message part

Re: ls -l /proc/1/exe -> Permission denied

[Richard Weinberger]

Am 18.07.2014 17:05, schrieb Joakim Tjernlund:
> Joakim Tjernlund/Transmode wrote on 2014/07/18 15:49:17:
>>
>> Richard Weinberger  wrote on 2014/07/18 
> 14:58:30:
>>>
>>> On Thu, Jul 17, 2014 at 1:18 PM, Joakim Tjernlund
>>>  wrote:
 Trying to real /proc//exe I noticed I could not read links not
 belonging to my user such as:
 jocke >  ls -l /proc/1/exe
  ls: cannot read symbolic link /proc/1/exe: Permission 
> denied

 Is this expected?
>>>
>>> Why do you think this is unexpected?
> 
>> It only shows the full path to the executable, compare with comm which 
> shows basename(app).
>>
>> I have an idea for qemu-user which needs to identify which processes
>> are running /usr/bin/qemu- and which are not so it knows how
>> to munge different /proc/ files.
> 
> Just to be clear, I expect to read where /proc/1/exe points, not the 
> contents of the file
> pointed to.
> 
> It seems that any and all symlinks are forbidden:
>> ls -l /proc/1
> ls: cannot read symbolic link /proc/1/cwd: Permission denied
> ls: cannot read symbolic link /proc/1/root: Permission denied
> ls: cannot read symbolic link /proc/1/exe: Permission denied

Because they all share the same implementation.
See proc_pid_link_inode_operations() in fs/proc/base.c

Happy hacking. :-)

Thanks,
//richard
--
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: Power-managing devices that are not of interest at some point in time

[Rafael J. Wysocki]

On Saturday, July 19, 2014 11:21:52 AM Dmitry Torokhov wrote:
> On Saturday, July 19, 2014 01:59:01 PM Alan Stern wrote:
> > On Sat, 19 Jul 2014, Benson Leung wrote:
> > > > This raises an interesting question.  Suppose the system gets suspended
> > > > while the lid is closed.  At that point, shouldn't wakeup devices be
> > > > enabled, even if they were already inhibited?
> > > 
> > > It's possible that this could be a policy decision, ie, whether
> > > power/wakeup is set to enabled for those devices or not.
> > > However, I'd say that there's only one policy that makes sense in that
> > > case : wakeups should be disabled while suspended.
> > > 
> > > If we inhibited the device during runtime to prevent stray input
> > > events from being generated, it wouldn't make sense to allow the
> > > device to potentially generate an accidental wakeup while suspended.
> > 
> > That doesn't really make sense.  If you're afraid of a device
> > generating spurious wakeup events when the lid is closed, you should
> > never enable it for wakeup.  After all, one of the first things that
> > people often do after suspending their laptop is close the lid.
> 
> That's a fair point, and I think should be done by default. But that does not 
> change what Benson said - I think if we inhibited the device it should stay 
> inhibited across system suspend, including being disabled as wakeup source 
> even if it could be enabled as such.

This seems to be the best approach to me too.

Rafael

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

Re: [PATCH 1/3] staging: lustre/lustre/lov: Remove unneeded 'if' statement in lov_request.c/lov_check_set()

[Joe Perches]

On Sat, 2014-07-19 at 21:34 +0200, Riccardo Lucchese wrote:
> It is silly to go through an if statement to set a single boolean
> value in function of a single boolean expression. In the function
> lov_check_set, assign the return value directly.
[]
> diff --git a/drivers/staging/lustre/lustre/lov/lov_request.c 
> b/drivers/staging/lustre/lustre/lov/lov_request.c
[]
> @@ -140,14 +140,13 @@ void lov_set_add_req(struct lov_request *req, struct 
> lov_request_set *set)
>  
>  static int lov_check_set(struct lov_obd *lov, int idx)
>  {
> - int rc = 0;
> + int rc;
>   mutex_lock(>lov_lock);
>  
> - if (lov->lov_tgts[idx] == NULL ||
> - lov->lov_tgts[idx]->ltd_active ||
> - (lov->lov_tgts[idx]->ltd_exp != NULL &&
> -  class_exp2cliimp(lov->lov_tgts[idx]->ltd_exp)->imp_connect_tried))
> - rc = 1;
> + rc = lov->lov_tgts[idx] == NULL ||
> + lov->lov_tgts[idx]->ltd_active ||
> + (lov->lov_tgts[idx]->ltd_exp != NULL &&
> +  
> class_exp2cliimp(lov->lov_tgts[idx]->ltd_exp)->imp_connect_tried);
>  
>   mutex_unlock(>lov_lock);
>   return rc;

Maybe consider using a temporary for lov->lov_tgtx[idx] like:

---

 drivers/staging/lustre/lustre/lov/lov_request.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lov/lov_request.c
b/drivers/staging/lustre/lustre/lov/lov_request.c
index ce830e4..53a4575 100644
--- a/drivers/staging/lustre/lustre/lov/lov_request.c
+++ b/drivers/staging/lustre/lustre/lov/lov_request.c
@@ -140,16 +140,18 @@ void lov_set_add_req(struct lov_request *req,
struct lov_request_set *set)
 
 static int lov_check_set(struct lov_obd *lov, int idx)
 {
-   int rc = 0;
+   int rc;
+   struct lmv_tgt_desc *tgt;
+
mutex_lock(>lov_lock);
 
-   if (lov->lov_tgts[idx] == NULL ||
-   lov->lov_tgts[idx]->ltd_active ||
-   (lov->lov_tgts[idx]->ltd_exp != NULL &&
-class_exp2cliimp(lov->lov_tgts[idx]->ltd_exp)->imp_connect_tried))
-   rc = 1;
+   tgt = lov->lov_tgts[idx];
+   rc = (!tgt || tgt->ltd_active ||
+ (tgt->ltd_exp &&
+  class_exp2cliimp(tgt->ltd_exp)->imp_connect_tried));
 
mutex_unlock(>lov_lock);
+
return rc;
 }
 


--
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 07/10] nohz: Enforce timekeeping on CPU 0

[Peter Zijlstra]

On Sat, Jul 19, 2014 at 02:46:56PM -0400, Nicolas Pitre wrote:
> People think all sorts of things.  And it becomes very irritating when 
> thoughtful assumptions get burned into ROM for example.  We should be 
> able to do better in the kernel.

Agreed. There used to be an x86 subarch where the boot cpu wasn't cpu0,
that always gave a lot of 'joy' too :-)
--
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 3/3] staging: lustre/lustre/lov: Add a space before open braces '{' in lov_request.c

[Riccardo Lucchese]

Fix the following checkpatch.pl issue in lov_request.c:
ERROR: space required before the open brace '{'

Signed-off-by: Riccardo Lucchese 
---
 drivers/staging/lustre/lustre/lov/lov_request.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lov/lov_request.c 
b/drivers/staging/lustre/lustre/lov/lov_request.c
index d9344c7..57ee94d 100644
--- a/drivers/staging/lustre/lustre/lov/lov_request.c
+++ b/drivers/staging/lustre/lustre/lov/lov_request.c
@@ -477,7 +477,7 @@ int lov_prep_match_set(struct obd_export *exp, struct 
obd_info *oinfo,
GOTO(out_set, rc = -ENOMEM);
lockh->cookie = set->set_lockh->llh_handle.h_cookie;
 
-   for (i = 0; i < lsm->lsm_stripe_count; i++){
+   for (i = 0; i < lsm->lsm_stripe_count; i++) {
struct lov_oinfo *loi;
struct lov_request *req;
obd_off start, end;
@@ -565,7 +565,7 @@ int lov_prep_cancel_set(struct obd_export *exp, struct 
obd_info *oinfo,
}
lockh->cookie = set->set_lockh->llh_handle.h_cookie;
 
-   for (i = 0; i < lsm->lsm_stripe_count; i++){
+   for (i = 0; i < lsm->lsm_stripe_count; i++) {
struct lov_request *req;
struct lustre_handle *lov_lockhp;
struct lov_oinfo *loi = lsm->lsm_oinfo[i];
@@ -733,7 +733,7 @@ int lov_prep_brw_set(struct obd_export *exp, struct 
obd_info *oinfo,
 
/* alloc and initialize lov request */
shift = 0;
-   for (i = 0; i < oinfo->oi_md->lsm_stripe_count; i++){
+   for (i = 0; i < oinfo->oi_md->lsm_stripe_count; i++) {
struct lov_oinfo *loi = NULL;
struct lov_request *req;
 
-- 
1.9.1

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

[PATCH 2/3] staging: lustre/lustre/lov: Add a blank line after declarations in lov_request.c

[Riccardo Lucchese]

Fix the following checkpatch.pl issue in lov_request.c:
WARNING: Missing a blank line after declarations

Signed-off-by: Riccardo Lucchese 
---
 drivers/staging/lustre/lustre/lov/lov_request.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lov/lov_request.c 
b/drivers/staging/lustre/lustre/lov/lov_request.c
index 90fc66a..d9344c7 100644
--- a/drivers/staging/lustre/lustre/lov/lov_request.c
+++ b/drivers/staging/lustre/lustre/lov/lov_request.c
@@ -141,14 +141,14 @@ void lov_set_add_req(struct lov_request *req, struct 
lov_request_set *set)
 static int lov_check_set(struct lov_obd *lov, int idx)
 {
int rc;
-   mutex_lock(>lov_lock);
 
+   mutex_lock(>lov_lock);
rc = lov->lov_tgts[idx] == NULL ||
lov->lov_tgts[idx]->ltd_active ||
(lov->lov_tgts[idx]->ltd_exp != NULL &&
 
class_exp2cliimp(lov->lov_tgts[idx]->ltd_exp)->imp_connect_tried);
-
mutex_unlock(>lov_lock);
+
return rc;
 }
 
@@ -835,6 +835,7 @@ static int cb_getattr_update(void *cookie, int rc)
 {
struct obd_info *oinfo = cookie;
struct lov_request *lovreq;
+
lovreq = container_of(oinfo, struct lov_request, rq_oi);
return lov_update_common_set(lovreq->rq_rqset, lovreq, rc);
 }
@@ -1017,6 +1018,7 @@ static int cb_setattr_update(void *cookie, int rc)
 {
struct obd_info *oinfo = cookie;
struct lov_request *lovreq;
+
lovreq = container_of(oinfo, struct lov_request, rq_oi);
return lov_update_setattr_set(lovreq->rq_rqset, lovreq, rc);
 }
@@ -1140,6 +1142,7 @@ static int cb_update_punch(void *cookie, int rc)
 {
struct obd_info *oinfo = cookie;
struct lov_request *lovreq;
+
lovreq = container_of(oinfo, struct lov_request, rq_oi);
return lov_update_punch_set(lovreq->rq_rqset, lovreq, rc);
 }
-- 
1.9.1

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

staging: lustre/lustre/lov: Cleanup style issues in lov_request.c

[Riccardo Lucchese]

Hello,

This patch series fixes two coding style issues and removes an unneeded
'if' statement in lov_request.c.

Thanks,
riccardo

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

[PATCH 1/3] staging: lustre/lustre/lov: Remove unneeded 'if' statement in lov_request.c/lov_check_set()

[Riccardo Lucchese]

It is silly to go through an if statement to set a single boolean
value in function of a single boolean expression. In the function
lov_check_set, assign the return value directly.

Signed-off-by: Riccardo Lucchese 
---
 drivers/staging/lustre/lustre/lov/lov_request.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lov/lov_request.c 
b/drivers/staging/lustre/lustre/lov/lov_request.c
index ce830e4..90fc66a 100644
--- a/drivers/staging/lustre/lustre/lov/lov_request.c
+++ b/drivers/staging/lustre/lustre/lov/lov_request.c
@@ -140,14 +140,13 @@ void lov_set_add_req(struct lov_request *req, struct 
lov_request_set *set)
 
 static int lov_check_set(struct lov_obd *lov, int idx)
 {
-   int rc = 0;
+   int rc;
mutex_lock(>lov_lock);
 
-   if (lov->lov_tgts[idx] == NULL ||
-   lov->lov_tgts[idx]->ltd_active ||
-   (lov->lov_tgts[idx]->ltd_exp != NULL &&
-class_exp2cliimp(lov->lov_tgts[idx]->ltd_exp)->imp_connect_tried))
-   rc = 1;
+   rc = lov->lov_tgts[idx] == NULL ||
+   lov->lov_tgts[idx]->ltd_active ||
+   (lov->lov_tgts[idx]->ltd_exp != NULL &&
+
class_exp2cliimp(lov->lov_tgts[idx]->ltd_exp)->imp_connect_tried);
 
mutex_unlock(>lov_lock);
return rc;
-- 
1.9.1

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

[PATCH 1/5] tools/power/cpupower/utils/helpers/sysfs.c: drop negativity check on unsigned value

[Andrey Utkin]

Resubmitting to send also to linux...@vger.kernel.org as requested by
Rafael J. Wysocki 

---8<---

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80621
Reported-by: David Binderman 
Signed-off-by: Andrey Utkin 
---
 tools/power/cpupower/utils/helpers/sysfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/power/cpupower/utils/helpers/sysfs.c 
b/tools/power/cpupower/utils/helpers/sysfs.c
index 851c7a1..09afe5d 100644
--- a/tools/power/cpupower/utils/helpers/sysfs.c
+++ b/tools/power/cpupower/utils/helpers/sysfs.c
@@ -81,7 +81,7 @@ int sysfs_is_cpu_online(unsigned int cpu)
close(fd);
 
value = strtoull(linebuf, , 0);
-   if (value > 1 || value < 0)
+   if (value > 1)
return -EINVAL;
 
return value;
-- 
1.8.5.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 2/4] ARM: add IPI tracepoints

[Ard Biesheuvel]

On 18 July 2014 23:22, Steven Rostedt  wrote:
> On Fri, 18 Jul 2014 16:55:42 -0400 (EDT)
> Nicolas Pitre  wrote:
>
>>
>> Here's the patch I have at the head of the series now, with the above
>> ugliness changed to an unconditional __tracepoint_string attribute.
>>
>
> I was thinking of something like this. Feel free to add this to your
> series.
>
> -- Steve
>

Nico,

If this patch addresses the issue where 3 RCU related tracepoint
strings turn up /after/ _edata on !CONFIG_TRACING, there is already a
patch queued up here

http://marc.info/?l=linux-kernel=140518452623148=2

As far as In know, these were the only occurrences using a __used
modifier, which is why they weren't dropped by the compiler in the
!CONFIG_TRACING case.

Regards,
Ard.



> From: Steven Rostedt 
> Subject: [PATCH] tracing: Do not do anything special with tracepoint_string 
> when tracing is disabled
>
> When CONFIG_TRACING is not enabled, there's no reason to save the trace
> strings either by the linker or as a static variable that can be
> referenced later. Simply pass back the string that is given to
> tracepoint_string().
>
> Signed-off-by: Steven Rostedt 
> ---
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index cff3106..b296363 100644
> --- a/include/linux/ftrace_event.h
> +++ b/include/linux/ftrace_event.h
> @@ -574,6 +574,7 @@ do {  
>   \
> __trace_printk(ip, fmt, ##args);\
>  } while (0)
>
> +#ifdef CONFIG_TRACING
>  /**
>   * tracepoint_string - register constant persistent string to trace system
>   * @str - a constant persistent string that will be referenced in tracepoints
> @@ -607,6 +608,15 @@ do { 
>   \
> ___tp_str;  \
> })
>  #define __tracepoint_string__attribute__((section("__tracepoint_str")))
> +#else
> +/*
> + * tracepoint_string() is used to save the string address for userspace
> + * tracing tools. When tracing isn't configured, there's no need to save
> + * anything.
> + */
> +# define tracepoint_string(str) str
> +# define __tracepoint_string
> +#endif
>
>  #ifdef CONFIG_PERF_EVENTS
>  struct perf_event;
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 07/10] nohz: Enforce timekeeping on CPU 0

[Nicolas Pitre]

On Sat, 19 Jul 2014, Peter Zijlstra wrote:

> On Sat, Jul 19, 2014 at 01:31:25PM -0400, Nicolas Pitre wrote:
> > On Sat, 19 Jul 2014, Frederic Weisbecker wrote:
> > 
> > > The timekeeper gets initialized to the value of the CPU where the
> > > first clockevent device is setup. This works well because the timekeeper
> > > can be any online CPU in most configs.
> > > 
> > > Full dynticks has its own requirement though and needs the timekeeper
> > > to always be 0. And this requirement seem to accomodate pretty well with
> > > the above described boot timekeeper setting because the first clockevent
> > > device happens to be initialized, most of the time, on the boot CPU
> > > (which should be CPU 0).
> > 
> > This might have been discussed before... but this isn't ARM big.LITTLE 
> > friendly at all.
> > 
> > Could we accommodate for any arbitrary CPU instead of making CPU 0 
> > "special" other than its role as the boot CPU please?  It doesn't have 
> > to be completely dynamic, but CPU 0 might be a really bad choice for 
> > ongoing periodic duties in some configurations.  For example, we might 
> > highly prefer to do this on CPU 4 for power efficiency reasons once it 
> > is online and keep CPU 0 in a deep C-state as much as possible.
> 
> This is because CPU0 can be a big core, right? IIRC this is done because
> a big core as boot cpu, boots faster and some people think boot time is
> relevant.

People think all sorts of things.  And it becomes very irritating when 
thoughtful assumptions get burned into ROM for example.  We should be 
able to do better in the kernel.


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