Re: [PATCH] Input: ims-pcu - remove unneeded get_unaligned_xxx
On Fri, Jan 03, 2014 at 10:49:07PM -0800, Andrey Smirnov wrote: > On Fri, Jan 3, 2014 at 10:16 PM, Dmitry Torokhov > wrote: > > On Fri, Jan 03, 2014 at 09:52:25PM -0800, Andrey Smirnov wrote: > >> On Fri, Jan 3, 2014 at 9:28 PM, Dmitry Torokhov > >> wrote: > >> > pcu->cmd_buf[IMS_PCU_DATA_OFFSET] is word aligned so we do not need to > >> > use > >> > get_unaligned_le16 to access it. > >> > > >> > Also let's add build time check to make sure it stays aligned. > >> > >> - AFAIK, there's no guarantee the "pcu" itself is aligned > > > > Yes. kmalloc returns aligned pointer, otherwise every access to members > > other than u8 would risk unaligned exception. > > OK, fair point. > > > > >> - This change assumes that aligning data on the 2-byte boundary is > >> sufficient for all architectures that do not allow unaligned data > >> access, which I don't think is a good assumption to make > > > > What arches require word access be double-word aligned? > > I don't know and neither do I care. Even if there aren't any in Linux > today do you expect it to never add a support to one that would impose > such a restriction? There is a lot of assumptions in kernel that might get broken by a random arch. For example, the assumption that pointer and long require the same storage. Anyway, it looks like gcc has __alignof__(type) construct that will make sure we ensure the right alignment for type. > > The whole point of get_unaligned_* "framework" is to provide drivers > with unified interface that would allow you not to care about > alignment. No, it is not that you do not care about alignment, it is so that you can safely access data that you know to be unaligned. Otherwise code would be littered with get_uanligned_*. > "Framework" in which architectures that support unaligned > access can fallback to good old functions like *_to_cpup and > architectures that do would provide the code to handle access in > whatever manner is best suited for them. > > > > >> - On x86 or any other architecture that allows unaligned access > >> get_unaligned_le16() is actually results to call to le16_to_cpup(), so > >> this change doesn't really save anything while imposing restrictions > >> on the arrangement of the fields in struct ims_pcu and causing > >> unnecessary build errors. > > > > Unless somebody changes the layout there won't be any new build errors, > > will there? > > So do you expect that code to never change from now on? I most likely > will be working on changes to support accelerometer data aggregation > and implementing associated with it input devices and this may or may > not require me to add fields to that structure, so what am I supposed > to do in that case? Juggle fields around until I find the right > combination that does not trigger build error?. > Umm, yes? And your juggling will be reduced to nothing if you add new fields at the end of the structure. > I honestly don't understand the purpose of this change, it doesn't > really save any performance, Technically it does as it does not require going through unaligned access on arches that can't do it. > IMHO decreases potability of the driver, I think that your concern can be solved with alignof. Thanks. -- 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/
[PATCH] slub: Fix possible format string bug.
I found an unapplied patch from https://lkml.org/lkml/2013/9/19/17 .
--
>From 38f01b48ae371058845274f4d7def4d81dbac4ea Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sat, 4 Jan 2014 16:26:00 +0900
Subject: [PATCH] slub: Fix possible format string bug.
The "name" is determined at runtime and is parsed as format string.
Signed-off-by: Tetsuo Handa
---
mm/slub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/slub.c b/mm/slub.c
index 545a170..058381e 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5163,7 +5163,7 @@ static int sysfs_slab_add(struct kmem_cache *s)
}
s->kobj.kset = slab_kset;
- err = kobject_init_and_add(>kobj, _ktype, NULL, name);
+ err = kobject_init_and_add(>kobj, _ktype, NULL, "%s", name);
if (err) {
kobject_put(>kobj);
return err;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCHv3 00/11] Intermix Lowmem and vmalloc
Hello, On Fri, Jan 03, 2014 at 02:08:52PM -0800, Laura Abbott wrote: > On 1/3/2014 10:23 AM, Dave Hansen wrote: > >On 01/02/2014 01:53 PM, Laura Abbott wrote: > >>The goal here is to allow as much lowmem to be mapped as if the block of > >>memory > >>was not reserved from the physical lowmem region. Previously, we had been > >>hacking up the direct virt <-> phys translation to ignore a large region of > >>memory. This did not scale for multiple holes of memory however. > > > >How much lowmem do these holes end up eating up in practice, ballpark? > >I'm curious how painful this is going to get. > > > > In total, the worst case can be close to 100M with an average case > around 70M-80M. The split and number of holes vary with the layout > but end up with 60M-80M one hole and the rest in the other. One more thing I'd like to know is how bad direct virt <->phys tranlsation in scale POV and how often virt<->phys tranlsation is called in your worload so what's the gain from this patch? 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 v2 1/8] staging/lustre/llite: remove ll_d_root_ops
From: Lai Siyao
Mnt root dentry will never be revalidated, but its d_op->d_compare
will be called for its children, to simplify code, we use the same
ll_d_ops as normal dentries.
But its attribute may be invalid before access, this won't cause
any issue because it always exists, and the only operation depends
on its attribute is .permission, which has revalidated it in lustre
code.
So it's okay to remove ll_d_root_ops, and remove unnecessary checks
in lookup/revalidate/statahead.
Lustre-change: http://review.whamcloud.com/6797
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3486
Signed-off-by: Lai Siyao
Reviewed-by: James Simmons
Reviewed-by: Peng Tao
Reviewed-by: Bobi Jam
Reviewed-by: Fan Yong
Reviewed-by: Alexey Shvetsov
Reviewed-by: Oleg Drokin
Signed-off-by: Peng Tao
Signed-off-by: Andreas Dilger
---
drivers/staging/lustre/lustre/llite/dcache.c | 40
.../staging/lustre/lustre/llite/llite_internal.h |5 +-
drivers/staging/lustre/lustre/llite/llite_lib.c| 11 +
drivers/staging/lustre/lustre/llite/llite_nfs.c|6 +-
drivers/staging/lustre/lustre/llite/namei.c| 28 ++---
drivers/staging/lustre/lustre/llite/statahead.c|7 ++-
6 files changed, 33 insertions(+), 64 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/dcache.c
b/drivers/staging/lustre/lustre/llite/dcache.c
index cbd663e..3907c87 100644
--- a/drivers/staging/lustre/lustre/llite/dcache.c
+++ b/drivers/staging/lustre/lustre/llite/dcache.c
@@ -176,7 +176,7 @@ static int ll_ddelete(const struct dentry *de)
return 0;
}
-static int ll_set_dd(struct dentry *de)
+int ll_d_init(struct dentry *de)
{
LASSERT(de != NULL);
@@ -190,40 +190,22 @@ static int ll_set_dd(struct dentry *de)
OBD_ALLOC_PTR(lld);
if (likely(lld != NULL)) {
spin_lock(>d_lock);
- if (likely(de->d_fsdata == NULL))
+ if (likely(de->d_fsdata == NULL)) {
de->d_fsdata = lld;
- else
+ __d_lustre_invalidate(de);
+ } else {
OBD_FREE_PTR(lld);
+ }
spin_unlock(>d_lock);
} else {
return -ENOMEM;
}
}
+ LASSERT(de->d_op == _d_ops);
return 0;
}
-int ll_dops_init(struct dentry *de, int block, int init_sa)
-{
- struct ll_dentry_data *lld = ll_d2d(de);
- int rc = 0;
-
- if (lld == NULL && block != 0) {
- rc = ll_set_dd(de);
- if (rc)
- return rc;
-
- lld = ll_d2d(de);
- }
-
- if (lld != NULL && init_sa != 0)
- lld->lld_sa_generation = 0;
-
- /* kernel >= 2.6.38 d_op is set in d_alloc() */
- LASSERT(de->d_op == _d_ops);
- return rc;
-}
-
void ll_intent_drop_lock(struct lookup_intent *it)
{
if (it->it_op && it->d.lustre.it_lock_mode) {
@@ -359,6 +341,8 @@ int ll_revalidate_it(struct dentry *de, int lookup_flags,
CDEBUG(D_VFSTRACE, "VFS Op:name=%s,intent=%s\n", de->d_name.name,
LL_IT2STR(it));
+ LASSERT(de != de->d_sb->s_root);
+
if (de->d_inode == NULL) {
__u64 ibits;
@@ -383,14 +367,6 @@ int ll_revalidate_it(struct dentry *de, int lookup_flags,
if (d_mountpoint(de))
GOTO(out_sa, rc = 1);
- /* need to get attributes in case root got changed from other client */
- if (de == de->d_sb->s_root) {
- rc = __ll_inode_revalidate_it(de, it, MDS_INODELOCK_LOOKUP);
- if (rc == 0)
- rc = 1;
- GOTO(out_sa, rc);
- }
-
exp = ll_i2mdexp(de->d_inode);
OBD_FAIL_TIMEOUT(OBD_FAIL_MDC_REVALIDATE_PAUSE, 5);
diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index 7ee5c02..28669ea 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -828,7 +828,7 @@ int ll_lease_close(struct obd_client_handle *och, struct
inode *inode,
/* llite/dcache.c */
-int ll_dops_init(struct dentry *de, int block, int init_sa);
+int ll_d_init(struct dentry *de);
extern struct dentry_operations ll_d_ops;
void ll_intent_drop_lock(struct lookup_intent *);
void ll_intent_release(struct lookup_intent *);
@@ -1320,7 +1320,8 @@ ll_statahead_mark(struct inode *dir, struct dentry
*dentry)
if (lli->lli_opendir_pid != current_pid())
return;
- if (sai != NULL && ldd != NULL)
+ LASSERT(ldd != NULL);
+ if (sai != NULL)
ldd->lld_sa_generation = sai->sai_generation;
}
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c
[PATCH v2 2/8] staging/lustre/llite: don't d_add for create only files
From: Lai Siyao
This is only part of the original Lustre commit. Splitted to remove
d_add() for create only files, because the dentry is fake,
and will be released right after use.
Lustre-change: http://review.whamcloud.com/6797
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3486
Signed-off-by: Lai Siyao
Reviewed-by: James Simmons
Reviewed-by: Peng Tao
Reviewed-by: Bobi Jam
Reviewed-by: Fan Yong
Reviewed-by: Alexey Shvetsov
Reviewed-by: Oleg Drokin
Signed-off-by: Peng Tao
Signed-off-by: Andreas Dilger
---
drivers/staging/lustre/lustre/llite/namei.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/namei.c
b/drivers/staging/lustre/lustre/llite/namei.c
index bc1a644..1d03a6f 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -583,11 +583,8 @@ static struct dentry *ll_lookup_nd(struct inode *parent,
struct dentry *dentry,
parent->i_generation, parent, flags);
/* Optimize away (CREATE && !OPEN). Let .create handle the race. */
- if ((flags & LOOKUP_CREATE ) && !(flags & LOOKUP_OPEN)) {
- __d_lustre_invalidate(dentry);
- d_add(dentry, NULL);
+ if ((flags & LOOKUP_CREATE) && !(flags & LOOKUP_OPEN))
return NULL;
- }
if (flags & (LOOKUP_PARENT|LOOKUP_OPEN|LOOKUP_CREATE))
itp = NULL;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 6/8] staging/lustre/obdclass: remove extra break in class_process_config
From: Artem Blagodarenko
This is only part of the original Lustre commit, splitted to do the
cleanup work.
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3155
Lustre-change: http://review.whamcloud.com/6025
Signed-off-by: Artem Blagodarenko
Reviewed-by: Andreas Dilger
Reviewed-by: Emoly Liu
Signed-off-by: Peng Tao
Signed-off-by: Andreas Dilger
---
.../staging/lustre/lustre/obdclass/obd_config.c|4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/obd_config.c
b/drivers/staging/lustre/lustre/obdclass/obd_config.c
index 27f56c0..fd08f1d 100644
--- a/drivers/staging/lustre/lustre/obdclass/obd_config.c
+++ b/drivers/staging/lustre/lustre/obdclass/obd_config.c
@@ -1226,24 +1226,20 @@ int class_process_config(struct lustre_cfg *lcfg)
case LCFG_POOL_NEW: {
err = obd_pool_new(obd, lustre_cfg_string(lcfg, 2));
GOTO(out, err = 0);
- break;
}
case LCFG_POOL_ADD: {
err = obd_pool_add(obd, lustre_cfg_string(lcfg, 2),
lustre_cfg_string(lcfg, 3));
GOTO(out, err = 0);
- break;
}
case LCFG_POOL_REM: {
err = obd_pool_rem(obd, lustre_cfg_string(lcfg, 2),
lustre_cfg_string(lcfg, 3));
GOTO(out, err = 0);
- break;
}
case LCFG_POOL_DEL: {
err = obd_pool_del(obd, lustre_cfg_string(lcfg, 2));
GOTO(out, err = 0);
- break;
}
default: {
err = obd_process_config(obd, sizeof(*lcfg), lcfg);
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 5/8] staging/lustre/mgs: set_param -P option that sets value permanently
From: Artem Blagodarenko
set_param and conf_param have different syntaxes. Also conf_param
has unimplemented paths and no wildcarding support.
This patch adds set_param -P option, that replaces the whole
conf_param "direct" proc access with a simple upcall-type mechanism
from the MGC. Option conf_param is saved now for compatibility.
Part of the original Lustre commit changes server code.
The patch only picks up client side change.
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3155
Lustre-change: http://review.whamcloud.com/6025
Signed-off-by: Artem Blagodarenko
Reviewed-by: Andreas Dilger
Reviewed-by: Emoly Liu
Signed-off-by: Peng Tao
Signed-off-by: Andreas Dilger
---
drivers/staging/lustre/lustre/include/lustre_cfg.h |2 +
.../staging/lustre/lustre/include/lustre_disk.h|2 +
drivers/staging/lustre/lustre/include/obd_class.h |9 ++-
drivers/staging/lustre/lustre/llite/llite_lib.c|5 +-
drivers/staging/lustre/lustre/mgc/mgc_request.c| 90 +---
.../staging/lustre/lustre/obdclass/obd_config.c| 47 ++-
6 files changed, 136 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_cfg.h
b/drivers/staging/lustre/lustre/include/lustre_cfg.h
index e14a5f6..3680668 100644
--- a/drivers/staging/lustre/lustre/include/lustre_cfg.h
+++ b/drivers/staging/lustre/lustre/include/lustre_cfg.h
@@ -88,6 +88,8 @@ enum lcfg_command_type {
LCFG_SET_LDLM_TIMEOUT = 0x00ce030, /**< set ldlm_timeout */
LCFG_PRE_CLEANUP= 0x00cf031, /**< call type-specific pre
* cleanup cleanup */
+ LCFG_SET_PARAM = 0x00ce032, /**< use set_param syntax to set
+ *a proc parameters */
};
struct lustre_cfg_bufs {
diff --git a/drivers/staging/lustre/lustre/include/lustre_disk.h
b/drivers/staging/lustre/lustre/include/lustre_disk.h
index 1de9a8b..ac08164 100644
--- a/drivers/staging/lustre/lustre/include/lustre_disk.h
+++ b/drivers/staging/lustre/lustre/include/lustre_disk.h
@@ -99,6 +99,8 @@
#define LDD_F_IR_CAPABLE0x2000
/** the MGS refused to register the target. */
#define LDD_F_ERROR 0x4000
+/** process at lctl conf_param */
+#define LDD_F_PARAM2 0x8000
/* opc for target register */
#define LDD_F_OPC_REG 0x1000
diff --git a/drivers/staging/lustre/lustre/include/obd_class.h
b/drivers/staging/lustre/lustre/include/obd_class.h
index 983718f..1c2ba19 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -175,9 +175,13 @@ enum {
CONFIG_T_CONFIG = 0,
CONFIG_T_SPTLRPC = 1,
CONFIG_T_RECOVER = 2,
- CONFIG_T_MAX = 3
+ CONFIG_T_PARAMS = 3,
+ CONFIG_T_MAX = 4
};
+#define PARAMS_FILENAME"params"
+#define LCTL_UPCALL"lctl"
+
/* list of active configuration logs */
struct config_llog_data {
struct ldlm_res_idcld_resid;
@@ -185,7 +189,8 @@ struct config_llog_data {
struct list_head cld_list_chain;
atomic_tcld_refcount;
struct config_llog_data*cld_sptlrpc;/* depended sptlrpc log */
- struct config_llog_data*cld_recover;/* imperative recover log */
+ struct config_llog_data*cld_params; /* common parameters log */
+ struct config_llog_data*cld_recover;/* imperative recover log */
struct obd_export *cld_mgcexp;
struct mutexcld_lock;
int cld_type;
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index 70a6808..3e4c292 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -1060,7 +1060,7 @@ out_free:
void ll_put_super(struct super_block *sb)
{
- struct config_llog_instance cfg;
+ struct config_llog_instance cfg, params_cfg;
struct obd_device *obd;
struct lustre_sb_info *lsi = s2lsi(sb);
struct ll_sb_info *sbi = ll_s2sbi(sb);
@@ -1074,6 +1074,9 @@ void ll_put_super(struct super_block *sb)
cfg.cfg_instance = sb;
lustre_end_log(sb, profilenm, );
+ params_cfg.cfg_instance = sb;
+ lustre_end_log(sb, PARAMS_FILENAME, _cfg);
+
if (sbi->ll_md_exp) {
obd = class_exp2obd(sbi->ll_md_exp);
if (obd)
diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c
b/drivers/staging/lustre/lustre/mgc/mgc_request.c
index b323820..4d2f6d2 100644
--- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
+++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
@@ -56,7 +56,7 @@ static int mgc_name2resid(char *name, int len, struct
ldlm_res_id *res_id,
{
__u64 resname = 0;
- if (len > 8) {
+ if (len > sizeof(resname)) {
CERROR("name too long:
[PATCH v2 3/8] staging/lustre/llite: pass correct pointer to obd_iocontrol()
From: "John L. Hammond"
In copy_and_ioctl() use the kernel space copy as the karg to
obd_iocontrol().
Lustre-change: http://review.whamcloud.com/6274
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3283
Signed-off-by: John L. Hammond
Reviewed-by: Sebastien Buisson
Reviewed-by: Oleg Drokin
Signed-off-by: Peng Tao
Signed-off-by: Andreas Dilger
---
drivers/staging/lustre/lustre/llite/dir.c | 23 ++-
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c
b/drivers/staging/lustre/lustre/llite/dir.c
index 22d0acc9..1b217c8 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -1048,20 +1048,25 @@ progress:
}
-static int copy_and_ioctl(int cmd, struct obd_export *exp, void *data, int len)
+static int copy_and_ioctl(int cmd, struct obd_export *exp,
+ const void __user *data, size_t size)
{
- void *ptr;
+ void *copy;
int rc;
- OBD_ALLOC(ptr, len);
- if (ptr == NULL)
+ OBD_ALLOC(copy, size);
+ if (copy == NULL)
return -ENOMEM;
- if (copy_from_user(ptr, data, len)) {
- OBD_FREE(ptr, len);
- return -EFAULT;
+
+ if (copy_from_user(copy, data, size)) {
+ rc = -EFAULT;
+ goto out;
}
- rc = obd_iocontrol(cmd, exp, len, data, NULL);
- OBD_FREE(ptr, len);
+
+ rc = obd_iocontrol(cmd, exp, size, copy, NULL);
+out:
+ OBD_FREE(copy, size);
+
return rc;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 7/8] staging/lustre/lustre_user.h: remove obsolete comments
From: JC Lafoucriere
This is only part of the original Lustre commit, main part of which changes
user space code. And now the comments above struct hsm_copy is no more true.
Lustre-change: http://review.whamcloud.com/4737
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2062
Signed-off-by: JC Lafoucriere
Signed-off-by: Henri Doreau
Reviewed-by: John L. Hammond
Reviewed-by: Andreas Dilger
Signed-off-by: Peng Tao
Signed-off-by: Andreas Dilger
---
.../lustre/lustre/include/lustre/lustre_user.h |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
index 6b6c0240..4d3c25f 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
@@ -1158,12 +1158,6 @@ struct hsm_progress {
__u32 padding;
};
-/**
- * Use by copytool during any hsm request they handled.
- * This structure is initialized by llapi_hsm_copy_start()
- * which is an helper over the ioctl() interface
- * Store Lustre, internal use only, data.
- */
struct hsm_copy {
__u64 hc_data_version;
__u16 hc_flags;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 8/8] staging/lustre/ptlrpc: flock deadlock detection does not work
From: Andriy Skulysh Flock deadlocks are checked on the first attempt to grant the flock only. If we try again to grant it after its blocking lock is cancelled, we don't check for deadlocks which also may exist. Perform deadlock detection during reprocess Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1715 Lustre-change: http://review.whamcloud.com/3553 Signed-off-by: Andriy Skulysh Reviewed-by: Vitaly Fertman Reviewed-by: Bruce Korb Reviewed-by: Keith Mannthey Reviewed-by: Oleg Drokin Signed-off-by: Peng Tao Signed-off-by: Andreas Dilger --- .../lustre/lustre/include/lustre/lustre_idl.h |5 ++- .../lustre/lustre/include/lustre_dlm_flags.h | 14 +- drivers/staging/lustre/lustre/ldlm/ldlm_flock.c| 41 ++-- drivers/staging/lustre/lustre/llite/llite_lib.c|4 +- .../lustre/lustre/obdclass/lprocfs_status.c|1 + drivers/staging/lustre/lustre/ptlrpc/wiretest.c|2 + 6 files changed, 58 insertions(+), 9 deletions(-) diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h index ac7fb37..05c77c0 100644 --- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h +++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h @@ -1304,6 +1304,8 @@ extern void lustre_swab_ptlrpc_body(struct ptlrpc_body *pb); #define OBD_CONNECT_LIGHTWEIGHT 0x1ULL/* lightweight connection */ #define OBD_CONNECT_SHORTIO 0x2ULL/* short io */ #define OBD_CONNECT_PINGLESS 0x4ULL/* pings not required */ +#define OBD_CONNECT_FLOCK_DEAD 0x8ULL/* flock deadlock detection */ + /* XXX README XXX: * Please DO NOT add flag values here before first ensuring that this same * flag value is not in use on some other branch. Please clear any such @@ -1341,7 +1343,8 @@ extern void lustre_swab_ptlrpc_body(struct ptlrpc_body *pb); OBD_CONNECT_EINPROGRESS | \ OBD_CONNECT_LIGHTWEIGHT | OBD_CONNECT_UMASK | \ OBD_CONNECT_LVB_TYPE | OBD_CONNECT_LAYOUTLOCK |\ - OBD_CONNECT_PINGLESS | OBD_CONNECT_MAX_EASIZE) + OBD_CONNECT_PINGLESS | OBD_CONNECT_MAX_EASIZE |\ + OBD_CONNECT_FLOCK_DEAD) #define OST_CONNECT_SUPPORTED (OBD_CONNECT_SRVLOCK | OBD_CONNECT_GRANT | \ OBD_CONNECT_REQPORTAL | OBD_CONNECT_VERSION | \ OBD_CONNECT_TRUNCLOCK | OBD_CONNECT_INDEX | \ diff --git a/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h b/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h index 75716f1..73fb38e 100644 --- a/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h +++ b/drivers/staging/lustre/lustre/include/lustre_dlm_flags.h @@ -35,10 +35,10 @@ #ifndef LDLM_ALL_FLAGS_MASK /** l_flags bits marked as "all_flags" bits */ -#define LDLM_FL_ALL_FLAGS_MASK 0x00FFC08F132FULL +#define LDLM_FL_ALL_FLAGS_MASK 0x00FFC08F932FULL /** l_flags bits marked as "ast" bits */ -#define LDLM_FL_AST_MASK0x8000ULL +#define LDLM_FL_AST_MASK0x80008000ULL /** l_flags bits marked as "blocked" bits */ #define LDLM_FL_BLOCKED_MASK0x000EULL @@ -56,7 +56,7 @@ #define LDLM_FL_LOCAL_ONLY_MASK 0x00FFULL /** l_flags bits marked as "on_wire" bits */ -#define LDLM_FL_ON_WIRE_MASK0xC08F132FULL +#define LDLM_FL_ON_WIRE_MASK0xC08F932FULL /** extent, mode, or resource changed */ #define LDLM_FL_LOCK_CHANGED0x0001ULL // bit 0 @@ -114,6 +114,12 @@ #define ldlm_set_has_intent(_l) LDLM_SET_FLAG(( _l), 1ULL << 12) #define ldlm_clear_has_intent(_l) LDLM_CLEAR_FLAG((_l), 1ULL << 12) +/** flock deadlock detected */ +#define LDLM_FL_FLOCK_DEADLOCK 0x8000ULL /* bit 15 */ +#define ldlm_is_flock_deadlock(_l) LDLM_TEST_FLAG((_l), 1ULL << 15) +#define ldlm_set_flock_deadlock(_l) LDLM_SET_FLAG((_l), 1ULL << 15) +#define ldlm_clear_flock_deadlock(_l) LDLM_CLEAR_FLAG((_l), 1ULL << 15) + /** discard (no writeback) on cancel */ #define LDLM_FL_DISCARD_DATA0x0001ULL // bit 16 #define ldlm_is_discard_data(_l)LDLM_TEST_FLAG(( _l), 1ULL << 16) @@ -390,6 +396,7 @@ static int hf_lustre_ldlm_fl_ast_sent= -1; static int hf_lustre_ldlm_fl_replay = -1; static int hf_lustre_ldlm_fl_intent_only = -1; static int hf_lustre_ldlm_fl_has_intent = -1; +static int hf_lustre_ldlm_fl_flock_deadlock = -1; static int hf_lustre_ldlm_fl_discard_data= -1; static int hf_lustre_ldlm_fl_no_timeout = -1; static int hf_lustre_ldlm_fl_block_nowait= -1; @@ -431,6 +438,7 @@ const value_string
[PATCH v2 0/8] staging/lustre: sync with external tree
Hi Greg, Happy New Year! I hope it is long enough to start sending you new patches. Here are the updated version of previous series. Each patch is checkpatch'ed and build-tested independently. Please see if it is OK to merge them. Thanks, Tao Cc: Andreas Dilger Andreas Dilger (1): staging/lustre/idl: remove LASSERT/CLASSERT from lustre_idl.h Andriy Skulysh (1): staging/lustre/ptlrpc: flock deadlock detection does not work Artem Blagodarenko (2): staging/lustre/mgs: set_param -P option that sets value permanently staging/lustre/obdclass: remove extra break in class_process_config JC Lafoucriere (1): staging/lustre/lustre_user.h: remove obsolete comments John L. Hammond (1): staging/lustre/llite: pass correct pointer to obd_iocontrol() Lai Siyao (2): staging/lustre/llite: remove ll_d_root_ops staging/lustre/llite: don't d_add for create only files .../lustre/lustre/include/lustre/lustre_idl.h | 48 +++ .../lustre/lustre/include/lustre/lustre_user.h |6 -- drivers/staging/lustre/lustre/include/lustre_cfg.h |2 + .../staging/lustre/lustre/include/lustre_disk.h|2 + .../lustre/lustre/include/lustre_dlm_flags.h | 14 +++- drivers/staging/lustre/lustre/include/obd_class.h |9 ++- drivers/staging/lustre/lustre/ldlm/ldlm_flock.c| 41 - drivers/staging/lustre/lustre/llite/dcache.c | 40 ++--- drivers/staging/lustre/lustre/llite/dir.c | 23 +++-- .../staging/lustre/lustre/llite/llite_internal.h |5 +- drivers/staging/lustre/lustre/llite/llite_lib.c| 20 ++--- drivers/staging/lustre/lustre/llite/llite_nfs.c|6 +- drivers/staging/lustre/lustre/llite/namei.c| 33 +++ drivers/staging/lustre/lustre/llite/statahead.c|7 +- drivers/staging/lustre/lustre/mgc/mgc_request.c| 90 +--- .../lustre/lustre/obdclass/lprocfs_status.c|1 + .../staging/lustre/lustre/obdclass/obd_config.c| 51 ++-- drivers/staging/lustre/lustre/ptlrpc/wiretest.c|2 + 18 files changed, 250 insertions(+), 150 deletions(-) -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/8] staging/lustre/idl: remove LASSERT/CLASSERT from lustre_idl.h
From: Andreas Dilger
Remove the usage of LASSERT() and CLASSERT() from lustre_idl.h, so
that it is usable from userspace programs if needed. These have
crept in over the years, but are not intended to be there.
The CLASSERT() checks for fid swabbing were largely redundant, and
have been moved to lustre/fid/fid_handler.c.
There are still a few LASSERTs that need to be removed when FID-on-OST
is landed, but I don't want to remove them before that code lands.
There are also uses of CERROR() that could be removed at that time.
Lustre-change: http://review.whamcloud.com/5682
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-1606
Signed-off-by: Andreas Dilger
Signed-off-by: John L. Hammond
Reviewed-by: Andreas Dilger
Reviewed-by: Christopher J. Morrone
Signed-off-by: Peng Tao
Signed-off-by: Andreas Dilger
---
.../lustre/lustre/include/lustre/lustre_idl.h | 43
1 files changed, 8 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
index 5da31c5..ac7fb37 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_idl.h
@@ -91,8 +91,8 @@
#ifndef _LUSTRE_IDL_H_
#define _LUSTRE_IDL_H_
-#if !defined(LASSERT) && !defined(LPU64)
-#include /* for LASSERT, LPUX64, etc */
+#if !defined(LPU64)
+#include /* for LPUX64, etc */
#endif
/* Defn's shared with user-space. */
@@ -232,7 +232,6 @@ static inline unsigned fld_range_is_any(const struct
lu_seq_range *range)
static inline void fld_range_set_type(struct lu_seq_range *range,
unsigned flags)
{
- LASSERT(!(flags & ~LU_SEQ_RANGE_MASK));
range->lsr_flags |= flags;
}
@@ -615,7 +614,6 @@ static inline obd_id fid_idif_id(obd_seq seq, __u32 oid,
__u32 ver)
/* extract ost index from IDIF FID */
static inline __u32 fid_idif_ost_idx(const struct lu_fid *fid)
{
- LASSERT(fid_is_idif(fid));
return (fid_seq(fid) >> 16) & 0x;
}
@@ -833,11 +831,6 @@ static inline void lu_igif_build(struct lu_fid *fid, __u32
ino, __u32 gen)
*/
static inline void fid_cpu_to_le(struct lu_fid *dst, const struct lu_fid *src)
{
- /* check that all fields are converted */
- CLASSERT(sizeof(*src) ==
-sizeof(fid_seq(src)) +
-sizeof(fid_oid(src)) +
-sizeof(fid_ver(src)));
dst->f_seq = cpu_to_le64(fid_seq(src));
dst->f_oid = cpu_to_le32(fid_oid(src));
dst->f_ver = cpu_to_le32(fid_ver(src));
@@ -845,11 +838,6 @@ static inline void fid_cpu_to_le(struct lu_fid *dst, const
struct lu_fid *src)
static inline void fid_le_to_cpu(struct lu_fid *dst, const struct lu_fid *src)
{
- /* check that all fields are converted */
- CLASSERT(sizeof(*src) ==
-sizeof(fid_seq(src)) +
-sizeof(fid_oid(src)) +
-sizeof(fid_ver(src)));
dst->f_seq = le64_to_cpu(fid_seq(src));
dst->f_oid = le32_to_cpu(fid_oid(src));
dst->f_ver = le32_to_cpu(fid_ver(src));
@@ -857,11 +845,6 @@ static inline void fid_le_to_cpu(struct lu_fid *dst, const
struct lu_fid *src)
static inline void fid_cpu_to_be(struct lu_fid *dst, const struct lu_fid *src)
{
- /* check that all fields are converted */
- CLASSERT(sizeof(*src) ==
-sizeof(fid_seq(src)) +
-sizeof(fid_oid(src)) +
-sizeof(fid_ver(src)));
dst->f_seq = cpu_to_be64(fid_seq(src));
dst->f_oid = cpu_to_be32(fid_oid(src));
dst->f_ver = cpu_to_be32(fid_ver(src));
@@ -869,11 +852,6 @@ static inline void fid_cpu_to_be(struct lu_fid *dst, const
struct lu_fid *src)
static inline void fid_be_to_cpu(struct lu_fid *dst, const struct lu_fid *src)
{
- /* check that all fields are converted */
- CLASSERT(sizeof(*src) ==
-sizeof(fid_seq(src)) +
-sizeof(fid_oid(src)) +
-sizeof(fid_ver(src)));
dst->f_seq = be64_to_cpu(fid_seq(src));
dst->f_oid = be32_to_cpu(fid_oid(src));
dst->f_ver = be32_to_cpu(fid_ver(src));
@@ -897,11 +875,6 @@ extern void lustre_swab_lu_seq_range(struct lu_seq_range
*range);
static inline int lu_fid_eq(const struct lu_fid *f0, const struct lu_fid *f1)
{
- /* Check that there is no alignment padding. */
- CLASSERT(sizeof(*f0) ==
-sizeof(f0->f_seq) +
-sizeof(f0->f_oid) +
-sizeof(f0->f_ver));
return memcmp(f0, f1, sizeof(*f0)) == 0;
}
@@ -3328,9 +3301,10 @@ struct obdo {
#define o_grant_used o_data_version
static inline void lustre_set_wire_obdo(struct obd_connect_data *ocd,
- struct obdo *wobdo, struct obdo *lobdo)
+ struct obdo *wobdo,
+ const struct obdo
Re: [PATCH] Input: ims-pcu - remove unneeded get_unaligned_xxx
On Fri, Jan 3, 2014 at 10:16 PM, Dmitry Torokhov wrote: > On Fri, Jan 03, 2014 at 09:52:25PM -0800, Andrey Smirnov wrote: >> On Fri, Jan 3, 2014 at 9:28 PM, Dmitry Torokhov >> wrote: >> > pcu->cmd_buf[IMS_PCU_DATA_OFFSET] is word aligned so we do not need to use >> > get_unaligned_le16 to access it. >> > >> > Also let's add build time check to make sure it stays aligned. >> >> - AFAIK, there's no guarantee the "pcu" itself is aligned > > Yes. kmalloc returns aligned pointer, otherwise every access to members > other than u8 would risk unaligned exception. OK, fair point. > >> - This change assumes that aligning data on the 2-byte boundary is >> sufficient for all architectures that do not allow unaligned data >> access, which I don't think is a good assumption to make > > What arches require word access be double-word aligned? I don't know and neither do I care. Even if there aren't any in Linux today do you expect it to never add a support to one that would impose such a restriction? The whole point of get_unaligned_* "framework" is to provide drivers with unified interface that would allow you not to care about alignment. "Framework" in which architectures that support unaligned access can fallback to good old functions like *_to_cpup and architectures that do would provide the code to handle access in whatever manner is best suited for them. > >> - On x86 or any other architecture that allows unaligned access >> get_unaligned_le16() is actually results to call to le16_to_cpup(), so >> this change doesn't really save anything while imposing restrictions >> on the arrangement of the fields in struct ims_pcu and causing >> unnecessary build errors. > > Unless somebody changes the layout there won't be any new build errors, > will there? So do you expect that code to never change from now on? I most likely will be working on changes to support accelerometer data aggregation and implementing associated with it input devices and this may or may not require me to add fields to that structure, so what am I supposed to do in that case? Juggle fields around until I find the right combination that does not trigger build error?. I honestly don't understand the purpose of this change, it doesn't really save any performance, IMHO decreases potability of the driver, so what is the gain. What does adding all the restrictions that this change imposes buy us? > > Thanks. > > -- > 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] Input: ims-pcu - remove unneeded get_unaligned_xxx
On Fri, Jan 03, 2014 at 09:52:25PM -0800, Andrey Smirnov wrote: > On Fri, Jan 3, 2014 at 9:28 PM, Dmitry Torokhov > wrote: > > pcu->cmd_buf[IMS_PCU_DATA_OFFSET] is word aligned so we do not need to use > > get_unaligned_le16 to access it. > > > > Also let's add build time check to make sure it stays aligned. > > - AFAIK, there's no guarantee the "pcu" itself is aligned Yes. kmalloc returns aligned pointer, otherwise every access to members other than u8 would risk unaligned exception. > - This change assumes that aligning data on the 2-byte boundary is > sufficient for all architectures that do not allow unaligned data > access, which I don't think is a good assumption to make What arches require word access be double-word aligned? > - On x86 or any other architecture that allows unaligned access > get_unaligned_le16() is actually results to call to le16_to_cpup(), so > this change doesn't really save anything while imposing restrictions > on the arrangement of the fields in struct ims_pcu and causing > unnecessary build errors. Unless somebody changes the layout there won't be any new build errors, will there? Thanks. -- 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: [BUG]NULL pointer dereference at 0000000000000008 __blkdev_put+0x17f/0x1d0
On Thu, Jan 02, 2014 at 10:36:30AM +0100, Jack Wang wrote: > > Bug happened at line 1486, looks disk->fops is NULL here for some > > reason, is it reasonable to add a check like: > > > > if (disk->fops) > > if (disk->fops->release) > > ret = disk->fops->release(disk, mode); > > > > > > Happy New Year and Best regards:) > > Jack > > > > Ping, could you share opnions on this, attached with patch I proposaled. Sorry, had been sick since mid-December ;-/ The patch is not a good idea - in the best case it's papering over a bug (and insufficiently so, at that, since there are other places where disk->fops->some_method is checked). gendisk->fops should never be assigned NULL; it starts life with NULL ->fops, but that should be assigned a non-NULL value (and never modified afterwards) before anyone can see it. Moreover, even if some driver has fscked up and forgot to initialize the damn thing, get_gendisk() would've refused to return such a thing to any callers (including __blkdev_get()). Note that __blkdev_get() would oops on such a thing if get_gendisk() somehow returned it. Looks like something is shitting over bdev->bd_disk or bdev->bd_disk->fops. The offsets in the disassembled code are all wrong (including that from beginning of function to oopsing instruction), but the code match is good, so I agree that we are hitting bdev->bd_disk->fops == NULL here. The question is how it has happened - that's where the real bug is... How reproducible it is? And which kernel, while we are at it? This area didn't get a lot of changes lately, but still... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[net-next v5 01/17] pci_regs.h: Add PCI bus link speed and width defines
Add missing PCI bus link speed 8.0 GT/s and bus link widths of x1, x2, x4 and x8. CC: CC: Bjorn Helgaas Signed-off-by: Jeff Kirsher Acked-by: Bjorn Helgaas --- include/uapi/linux/pci_regs.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h index 4a98e85..c870c2a 100644 --- a/include/uapi/linux/pci_regs.h +++ b/include/uapi/linux/pci_regs.h @@ -489,7 +489,12 @@ #define PCI_EXP_LNKSTA_CLS0x000f /* Current Link Speed */ #define PCI_EXP_LNKSTA_CLS_2_5GB 0x0001 /* Current Link Speed 2.5GT/s */ #define PCI_EXP_LNKSTA_CLS_5_0GB 0x0002 /* Current Link Speed 5.0GT/s */ +#define PCI_EXP_LNKSTA_CLS_8_0GB 0x0003 /* Current Link Speed 8.0GT/s */ #define PCI_EXP_LNKSTA_NLW0x03f0 /* Negotiated Link Width */ +#define PCI_EXP_LNKSTA_NLW_X1 0x0010 /* Current Link Width x1 */ +#define PCI_EXP_LNKSTA_NLW_X2 0x0020 /* Current Link Width x2 */ +#define PCI_EXP_LNKSTA_NLW_X4 0x0040 /* Current Link Width x4 */ +#define PCI_EXP_LNKSTA_NLW_X8 0x0080 /* Current Link Width x8 */ #define PCI_EXP_LNKSTA_NLW_SHIFT 4/* start of NLW mask in link status */ #define PCI_EXP_LNKSTA_LT 0x0800 /* Link Training */ #define PCI_EXP_LNKSTA_SLC0x1000 /* Slot Clock Configuration */ -- 1.8.3.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] Input: ims-pcu - remove unneeded get_unaligned_xxx
On Fri, Jan 3, 2014 at 9:28 PM, Dmitry Torokhov
wrote:
> pcu->cmd_buf[IMS_PCU_DATA_OFFSET] is word aligned so we do not need to use
> get_unaligned_le16 to access it.
>
> Also let's add build time check to make sure it stays aligned.
- AFAIK, there's no guarantee the "pcu" itself is aligned
- This change assumes that aligning data on the 2-byte boundary is
sufficient for all architectures that do not allow unaligned data
access, which I don't think is a good assumption to make
- On x86 or any other architecture that allows unaligned access
get_unaligned_le16() is actually results to call to le16_to_cpup(), so
this change doesn't really save anything while imposing restrictions
on the arrangement of the fields in struct ims_pcu and causing
unnecessary build errors.
So, for what its worth, NACK for this patch from me.
>
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/misc/ims-pcu.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
> index 513ecdf..b8f1029 100644
> --- a/drivers/input/misc/ims-pcu.c
> +++ b/drivers/input/misc/ims-pcu.c
> @@ -116,6 +116,8 @@ struct ims_pcu {
> bool setup_complete; /* Input and LED devices have been created */
> };
>
> +#define IMS_PCU_CHECK_CMD_BUF_ALIGNMENT(offset, alignment) \
> + IS_ALIGNED(offsetof(struct ims_pcu, cmd_buf[offset]), alignment)
>
> /*
> * Buttons Input device support *
> @@ -999,8 +1001,10 @@ ims_pcu_backlight_get_brightness(struct led_classdev
> *cdev)
> /* Assume the LED is OFF */
> brightness = LED_OFF;
> } else {
> - brightness =
> -
> get_unaligned_le16(>cmd_buf[IMS_PCU_DATA_OFFSET]);
> + BUILD_BUG_ON(!IMS_PCU_CHECK_CMD_BUF_ALIGNMENT(
> + IMS_PCU_DATA_OFFSET, 2));
> + brightness = le16_to_cpup(
> + (__le16 *)>cmd_buf[IMS_PCU_DATA_OFFSET]);
> }
>
> mutex_unlock(>cmd_mutex);
> --
> 1.8.4.2
>
>
> --
> 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 1/1] watchdog: Adding Merrifield watchdog driver support
On 01/02/2014 04:56 PM, eric.er...@linux.intel.com wrote:
From: Gabriel Touzeau
Added Merrifield watchdog driver support.
Based on initial implementation from prior Intel SCU-based platforms, this
driver has several changes specific to the Tangier SoC / Merrifield platform.
New watchdog drivers should be implemented using the watchdog subsystem.
Signed-off-by: Eric Ernst
Signed-off-by: Yann Puech
Signed-off-by: Jeremy Compostella
Signed-off-by: Gabriel Touzeau
Cc: David Cohen
---
drivers/watchdog/Kconfig | 12 +
drivers/watchdog/Makefile |1 +
drivers/watchdog/intel_scu_watchdog_evo.c | 587 +
drivers/watchdog/intel_scu_watchdog_evo.h | 54 +++
4 files changed, 654 insertions(+)
create mode 100644 drivers/watchdog/intel_scu_watchdog_evo.c
create mode 100644 drivers/watchdog/intel_scu_watchdog_evo.h
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index d1d53f301de7..bb3ef92d2788 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -616,6 +616,18 @@ config INTEL_SCU_WATCHDOG
To compile this driver as a module, choose M here.
+config INTEL_SCU_WATCHDOG_EVO
+ bool "Intel SCU Watchdog Evolution for Mobile Platforms"
+ depends on X86_INTEL_MID
+ ---help---
+ Hardware driver evolution for the watchdog timer built into the Intel
+ SCU for Intel Mobile Platforms.
+
+ This driver supports the watchdog evolution implementation in SCU,
"watchdog evolution" ... odd terminology.
+ available for Merrifield generation.
+
+ To compile this driver as a module, choose M here.
+
config ITCO_WDT
tristate "Intel TCO Timer/Watchdog"
depends on (X86 || IA64) && PCI
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 6c5bb274d3cd..e4b150efa938 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -112,6 +112,7 @@ obj-$(CONFIG_W83977F_WDT) += w83977f_wdt.o
obj-$(CONFIG_MACHZ_WDT) += machzwd.o
obj-$(CONFIG_SBC_EPX_C3_WATCHDOG) += sbc_epx_c3.o
obj-$(CONFIG_INTEL_SCU_WATCHDOG) += intel_scu_watchdog.o
+obj-$(CONFIG_INTEL_SCU_WATCHDOG_EVO) += intel_scu_watchdog_evo.o
# M32R Architecture
diff --git a/drivers/watchdog/intel_scu_watchdog_evo.c
b/drivers/watchdog/intel_scu_watchdog_evo.c
new file mode 100644
index ..fc9a37a33ddd
--- /dev/null
+++ b/drivers/watchdog/intel_scu_watchdog_evo.c
@@ -0,0 +1,587 @@
+/*
+ * intel_scu_watchdog_evo: An Intel SCU IOH Based Watchdog Device
+ * for Tangier SoC (Merrifield platform)
+ *
+ * Based on previous intel_scu based watchdog driver, intel_scu_watchdog.
+ *
+ * Copyright (C) 2009-2013 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General
+ * Public License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be
+ * useful, but WITHOUT ANY WARRANTY; without even the implied
+ * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
+ * PURPOSE. See the GNU General Public License for more details.
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the Free
+ * Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 02111-1307, USA.
+ * The full GNU General Public License is included in this
+ * distribution in the file called COPYING.
+ *
Providing the FSF address is discouraged, and using it results in checkpatch
errors.
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "intel_scu_watchdog_evo.h"
+
+/* Defines */
+#define STRING_RESET_TYPE_MAX_LEN 11
+#define STRING_COLD_OFF "COLD_OFF"
+#define STRING_COLD_RESET "COLD_RESET"
+#define STRING_COLD_BOOT"COLD_BOOT"
+
+#define EXT_TIMER0_MSI 15
+
+#define IPC_WATCHDOG 0xf8
+
+/* watchdog message options */
+enum {
+ SCU_WATCHDOG_START = 0,
+ SCU_WATCHDOG_STOP,
+ SCU_WATCHDOG_KEEPALIVE,
+ SCU_WATCHDOG_SET_ACTION_ON_TIMEOUT
+};
+
+/* watchdog reset options */
+enum {
+ SCU_COLD_OFF_ON_TIMEOUT = 0,
+ SCU_COLD_RESET_ON_TIMEOUT,
+ SCU_COLD_BOOT_ON_TIMEOUT,
+ SCU_DO_NOTHING_ON_TIMEOUT
+};
+
+/* Statics */
+static struct intel_scu_watchdog_dev watchdog_device;
+
+/* Module params */
+static bool disable_kernel_watchdog;
+module_param(disable_kernel_watchdog, bool, S_IRUGO);
+MODULE_PARM_DESC(disable_kernel_watchdog,
+ "Disable kernel watchdog"
+ "Set to 0, watchdog started at boot"
+ "and left running; Set to 1; watchdog"
+ "is not started until user space"
+
Re: [PATCH v2] ims-pcu: Add commands supported by the new version of the FW
On Fri, Jan 03, 2014 at 09:03:11PM -0800, Andrey Smirnov wrote: > On Fri, Jan 3, 2014 at 8:44 PM, Dmitry Torokhov > wrote: > > On Fri, Jan 03, 2014 at 08:24:17PM -0800, Andrey Smirnov wrote: > >> On Fri, Jan 3, 2014 at 5:39 PM, Dmitry Torokhov > >> wrote: > >> > Hi Andrey, > >> > > >> > On Wed, Jan 01, 2014 at 04:47:01PM -0800, Andrey Smirnov wrote: > >> >> New version of the PCU firmware supports two new commands: > >> >> - IMS_PCU_CMD_OFN_SET_CONFIG which allows to write data to the > >> >> registers of one finger navigation(OFN) chip present on the device > >> >> - IMS_PCU_CMD_OFN_GET_CONFIG which allows to read data form the > >> >> registers of said chip. > >> >> > >> >> This commit adds two helper functions to use those commands and sysfs > >> >> attributes to use them. It also exposes some OFN configuration > >> >> parameters via sysfs. > >> > > >> > Thank you for making the changes. I do not still quite like the games we > >> > play with the OFN attributes, how about the patch below (on top of > >> > yours)? > >> > > >> > >> Yeah, I agree I like it the "two separate sysfs groups" group approach > >> better. The only small nitpick about your patch is that I think we > >> should use "get_unaligned_le16" instead of "le16_to_cpup"(In case > >> anyone decides to run the driver on SuperH or C6x DSPs from TI :-)). > >> Let me test it and if everything works as expected I'll apply you > >> patch, convert it to "get_unaligned_le16", squash and send v3 of the > >> patch. > > > > Why do we need get_unaligned_le16()? As far as I can see pcu->cmd_buf is > > aligned and therefore pcu->cmd_buf[2] is also aligned on word boundary. > > * The "pcu" structure is allocated with kmalloc which doesn't give any > guarantees about address alignment. > * I am not sure if the cmd_buf field in that structure is aligned, and > even if it is, any future changes to that structure may shift its > offset. > * Also even if the data we are interested in is aligned on 2-byte > border, I think all those architectures require 4-byte border > alignment. As far as I know word access only requires word alignment. Please see the other patch I just posted that adds alignment check in balcklight handling code. Thanks. -- 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] x86, Fix do_IRQ interrupt warning for cpu hotplug retriggered irqs [v2]
On 12/29/13, Prarit Bhargava wrote:
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64831
>
> When downing a cpu it is possible that there are unhandled irqs left in
> the APIC IRR register. The following code path shows how the problem
> can occur:
>
> 1. CPU 5 is to go down.
> 2. CPU 5 IRQ 12 IRR is set to request service, but ISR is not set.
> 3. cpu_disable on CPU 5 executes via stop_machine()
Step2 should come after step3:
2. cpu_disable() on CPU 5 executes with interrupt flag cleared by
local_irq_save() via stop_machine().
3. IRQ 12 asserts on CPU 5, setting IRR but not ISR because interrupt
flag is cleared (CPU unabled to handle the irq)
(It'll turn into ISR after interrupt flag is set by local_irq_restore())
> 4. IRQs are migrated off of CPU 5, and the vectors' irqs are set to -1.
> 4. stop_machine() finishes cpu_disable()
> 5. cpu_die() for CPU 5 executes in normal context.
> 6. CPU 5 attempts to handle IRQ 12 because the IRR is set for IRQ 12. The
> code attempts to find the vector's IRQ and cannot because it has been set to
> -1.
> 7. do_IRQ warning displays warning about CPU 5 IRQ 12.
>
> When this happens, do_IRQ() spits out a warning like
>
> kernel: [ 614.414443] do_IRQ: 5.124 No irq handler for vector (irq -1)
>
> I added a debug printk to output which CPU & vector was retriggered and
> discovered that that we are getting bogus events. I see a 100% correlation
> between this debug printk in fixup_irqs() and the do_IRQ() warning.
>
> This patchset resolves this by adding definitions for VECTOR_UNDEFINED(-1)
> and
> VECTOR_RETRIGGERED(-2) and modifying the code to use them.
>
> [v2]: sent with more detailed commit message
>
> Signed-off-by: Prarit Bhargava
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: Michel Lespinasse
> Cc: Andi Kleen
> Cc: Seiji Aguchi
> Cc: Yang Zhang
> Cc: Paul Gortmaker
> Cc: janet.mor...@intel.com
> Cc: tony.l...@intel.com
> Cc: ruiv.w...@gmail.com
> ---
> arch/x86/include/asm/hw_irq.h |2 ++
> arch/x86/kernel/apic/io_apic.c | 13 +++--
> arch/x86/kernel/irq.c | 17 +++--
> arch/x86/kernel/irqinit.c |4 ++--
> 4 files changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
> index 92b3bae..22c425e 100644
> --- a/arch/x86/include/asm/hw_irq.h
> +++ b/arch/x86/include/asm/hw_irq.h
> @@ -188,6 +188,8 @@ extern __visible void smp_invalidate_interrupt(struct
> pt_regs *);
>
> extern void (*__initconst
> interrupt[NR_VECTORS-FIRST_EXTERNAL_VECTOR])(void);
>
> +#define VECTOR_UNDEFINED -1
> +#define VECTOR_RETRIGGERED -2
> typedef int vector_irq_t[NR_VECTORS];
> DECLARE_PER_CPU(vector_irq_t, vector_irq);
> extern void setup_vector_irq(int cpu);
> diff --git a/arch/x86/kernel/apic/io_apic.c
> b/arch/x86/kernel/apic/io_apic.c
> index e63a5bd..6e1541c 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -1143,7 +1143,8 @@ next:
> goto next;
>
> for_each_cpu_and(new_cpu, tmp_mask, cpu_online_mask)
> - if (per_cpu(vector_irq, new_cpu)[vector] != -1)
> + if (per_cpu(vector_irq, new_cpu)[vector] >
> + VECTOR_UNDEFINED)
> goto next;
> /* Found one! */
> current_vector = vector;
> @@ -1183,7 +1184,7 @@ static void __clear_irq_vector(int irq, struct irq_cfg
> *cfg)
>
> vector = cfg->vector;
> for_each_cpu_and(cpu, cfg->domain, cpu_online_mask)
> - per_cpu(vector_irq, cpu)[vector] = -1;
> + per_cpu(vector_irq, cpu)[vector] = VECTOR_UNDEFINED;
>
> cfg->vector = 0;
> cpumask_clear(cfg->domain);
> @@ -1195,7 +1196,7 @@ static void __clear_irq_vector(int irq, struct irq_cfg
> *cfg)
> vector++) {
> if (per_cpu(vector_irq, cpu)[vector] != irq)
> continue;
> - per_cpu(vector_irq, cpu)[vector] = -1;
> + per_cpu(vector_irq, cpu)[vector] = VECTOR_UNDEFINED;
> break;
> }
> }
> @@ -1228,12 +1229,12 @@ void __setup_vector_irq(int cpu)
> /* Mark the free vectors */
> for (vector = 0; vector < NR_VECTORS; ++vector) {
> irq = per_cpu(vector_irq, cpu)[vector];
> - if (irq < 0)
> + if (irq <= VECTOR_UNDEFINED)
> continue;
>
> cfg = irq_cfg(irq);
> if (!cpumask_test_cpu(cpu, cfg->domain))
> - per_cpu(vector_irq, cpu)[vector] = -1;
> + per_cpu(vector_irq, cpu)[vector] = VECTOR_UNDEFINED;
> }
> raw_spin_unlock(_lock);
> }
> @@ -2208,7 +2209,7 @@ asmlinkage void smp_irq_move_cleanup_interrupt(void)
>
Re: [PATCHv4 0/2] twl4030-keypad DT binding
Dmitry, What's the status of this patch? Can you queue this for 3.14? -- Sebastian signature.asc Description: Digital signature
Re: [PATCH] Input: ims-pcu - fix error unwinding path in application mode
On Fri, Jan 03, 2014 at 09:13:10PM -0800, Andrey Smirnov wrote: > Dmitry, > > Do you want this patch to go separatly or do you want me to bundle it > with my other changes(probably the first one)? I'll apply it separately. > Also, offtopic, do you want me to backport this changes to 2.6 kernel > that IMS uses or would you do it? It should apply as is, no backport needed as far as I can tell. -- 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/
[PATCH] Input: ims-pcu - remove unneeded get_unaligned_xxx
pcu->cmd_buf[IMS_PCU_DATA_OFFSET] is word aligned so we do not need to use
get_unaligned_le16 to access it.
Also let's add build time check to make sure it stays aligned.
Signed-off-by: Dmitry Torokhov
---
drivers/input/misc/ims-pcu.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
index 513ecdf..b8f1029 100644
--- a/drivers/input/misc/ims-pcu.c
+++ b/drivers/input/misc/ims-pcu.c
@@ -116,6 +116,8 @@ struct ims_pcu {
bool setup_complete; /* Input and LED devices have been created */
};
+#define IMS_PCU_CHECK_CMD_BUF_ALIGNMENT(offset, alignment) \
+ IS_ALIGNED(offsetof(struct ims_pcu, cmd_buf[offset]), alignment)
/*
* Buttons Input device support *
@@ -999,8 +1001,10 @@ ims_pcu_backlight_get_brightness(struct led_classdev
*cdev)
/* Assume the LED is OFF */
brightness = LED_OFF;
} else {
- brightness =
- get_unaligned_le16(>cmd_buf[IMS_PCU_DATA_OFFSET]);
+ BUILD_BUG_ON(!IMS_PCU_CHECK_CMD_BUF_ALIGNMENT(
+ IMS_PCU_DATA_OFFSET, 2));
+ brightness = le16_to_cpup(
+ (__le16 *)>cmd_buf[IMS_PCU_DATA_OFFSET]);
}
mutex_unlock(>cmd_mutex);
--
1.8.4.2
--
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] Input: ims-pcu - fix error unwinding path in application mode
Dmitry, Do you want this patch to go separatly or do you want me to bundle it with my other changes(probably the first one)? Also, offtopic, do you want me to backport this changes to 2.6 kernel that IMS uses or would you do it? Thanks, On Fri, Jan 3, 2014 at 9:00 PM, Dmitry Torokhov wrote: > We first create backlight and then input devices so we shoudl destroy them > in opposite order when handling errors. > > Signed-off-by: Dmitry Torokhov > --- > > Andrey, this fixup was split off from the patch I sent earlier today. > > drivers/input/misc/ims-pcu.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c > index 4244f47..513ecdf 100644 > --- a/drivers/input/misc/ims-pcu.c > +++ b/drivers/input/misc/ims-pcu.c > @@ -1929,10 +1929,10 @@ static int ims_pcu_init_application_mode(struct > ims_pcu *pcu) > > return 0; > > -err_destroy_backlight: > - ims_pcu_destroy_backlight(pcu); > err_destroy_buttons: > ims_pcu_destroy_buttons(pcu); > +err_destroy_backlight: > + ims_pcu_destroy_backlight(pcu); > return error; > } > > -- > 1.8.4.2 > > > -- > 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: linux-next: manual merge of the renesas tree with the arm-soc tree
On Mon, Dec 16, 2013 at 2:00 AM, Nicolas Ferre wrote:
> On 16/12/2013 00:47, Stephen Rothwell :
>> Hi Simon,
>>
>> Today's linux-next merge of the renesas tree got a conflict in
>> drivers/clk/Makefile between commit 0ad6125b1579 ("clk: at91: add PMC
>> base support") from the arm-soc tree and commit 10cdfe9f327a ("clk:
>> shmobile: Add R-Car Gen2 clocks support") from the renesas tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary (no action
>> is required).
>
> Fine for me.
Simon, Nicolas,
While a very minor issue, this should have been altogether avoided
with a little more attention when applying patches. The Makefile is
sorted, and you've appended new lines to the end instead of in the
place they're supposed to go. Sure, others have done the same mistake
in a few places but that doesn't mean we shouldn't try to keep it
sorted.
The very reason _to_ sort a Makefile is to avoid these needless
add-add conflicts when two people append to the same unsorted list.
Now I can't resolve it properly and move the entries when I do the
same merge (and get the same conflict), because that will cause a
third conflict for Stephen, and he's about to return from vacation and
is going to cuss at us if we cause too many new conflicts in one day.
:)
So, best choice is to keep the unsortedness now, and have Mike resort
his Makefile for us at the end of the merge window. And keep a little
closer eye on Makefile and Kconfig additions in the future. :)
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ims-pcu: Add commands supported by the new version of the FW
On Fri, Jan 3, 2014 at 8:44 PM, Dmitry Torokhov wrote: > On Fri, Jan 03, 2014 at 08:24:17PM -0800, Andrey Smirnov wrote: >> On Fri, Jan 3, 2014 at 5:39 PM, Dmitry Torokhov >> wrote: >> > Hi Andrey, >> > >> > On Wed, Jan 01, 2014 at 04:47:01PM -0800, Andrey Smirnov wrote: >> >> New version of the PCU firmware supports two new commands: >> >> - IMS_PCU_CMD_OFN_SET_CONFIG which allows to write data to the >> >> registers of one finger navigation(OFN) chip present on the device >> >> - IMS_PCU_CMD_OFN_GET_CONFIG which allows to read data form the >> >> registers of said chip. >> >> >> >> This commit adds two helper functions to use those commands and sysfs >> >> attributes to use them. It also exposes some OFN configuration >> >> parameters via sysfs. >> > >> > Thank you for making the changes. I do not still quite like the games we >> > play with the OFN attributes, how about the patch below (on top of >> > yours)? >> > >> >> Yeah, I agree I like it the "two separate sysfs groups" group approach >> better. The only small nitpick about your patch is that I think we >> should use "get_unaligned_le16" instead of "le16_to_cpup"(In case >> anyone decides to run the driver on SuperH or C6x DSPs from TI :-)). >> Let me test it and if everything works as expected I'll apply you >> patch, convert it to "get_unaligned_le16", squash and send v3 of the >> patch. > > Why do we need get_unaligned_le16()? As far as I can see pcu->cmd_buf is > aligned and therefore pcu->cmd_buf[2] is also aligned on word boundary. * The "pcu" structure is allocated with kmalloc which doesn't give any guarantees about address alignment. * I am not sure if the cmd_buf field in that structure is aligned, and even if it is, any future changes to that structure may shift its offset. * Also even if the data we are interested in is aligned on 2-byte border, I think all those architectures require 4-byte border alignment. > > Thanks. > > -- > 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/
[PATCH] Input: ims-pcu - fix error unwinding path in application mode
We first create backlight and then input devices so we shoudl destroy them in opposite order when handling errors. Signed-off-by: Dmitry Torokhov --- Andrey, this fixup was split off from the patch I sent earlier today. drivers/input/misc/ims-pcu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c index 4244f47..513ecdf 100644 --- a/drivers/input/misc/ims-pcu.c +++ b/drivers/input/misc/ims-pcu.c @@ -1929,10 +1929,10 @@ static int ims_pcu_init_application_mode(struct ims_pcu *pcu) return 0; -err_destroy_backlight: - ims_pcu_destroy_backlight(pcu); err_destroy_buttons: ims_pcu_destroy_buttons(pcu); +err_destroy_backlight: + ims_pcu_destroy_backlight(pcu); return error; } -- 1.8.4.2 -- 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 v2] ims-pcu: Add commands supported by the new version of the FW
On Fri, Jan 03, 2014 at 08:24:17PM -0800, Andrey Smirnov wrote: > On Fri, Jan 3, 2014 at 5:39 PM, Dmitry Torokhov > wrote: > > Hi Andrey, > > > > On Wed, Jan 01, 2014 at 04:47:01PM -0800, Andrey Smirnov wrote: > >> New version of the PCU firmware supports two new commands: > >> - IMS_PCU_CMD_OFN_SET_CONFIG which allows to write data to the > >> registers of one finger navigation(OFN) chip present on the device > >> - IMS_PCU_CMD_OFN_GET_CONFIG which allows to read data form the > >> registers of said chip. > >> > >> This commit adds two helper functions to use those commands and sysfs > >> attributes to use them. It also exposes some OFN configuration > >> parameters via sysfs. > > > > Thank you for making the changes. I do not still quite like the games we > > play with the OFN attributes, how about the patch below (on top of > > yours)? > > > > Yeah, I agree I like it the "two separate sysfs groups" group approach > better. The only small nitpick about your patch is that I think we > should use "get_unaligned_le16" instead of "le16_to_cpup"(In case > anyone decides to run the driver on SuperH or C6x DSPs from TI :-)). > Let me test it and if everything works as expected I'll apply you > patch, convert it to "get_unaligned_le16", squash and send v3 of the > patch. Why do we need get_unaligned_le16()? As far as I can see pcu->cmd_buf is aligned and therefore pcu->cmd_buf[2] is also aligned on word boundary. Thanks. -- 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 v2] ims-pcu: Add commands supported by the new version of the FW
On Fri, Jan 3, 2014 at 5:39 PM, Dmitry Torokhov wrote: > Hi Andrey, > > On Wed, Jan 01, 2014 at 04:47:01PM -0800, Andrey Smirnov wrote: >> New version of the PCU firmware supports two new commands: >> - IMS_PCU_CMD_OFN_SET_CONFIG which allows to write data to the >> registers of one finger navigation(OFN) chip present on the device >> - IMS_PCU_CMD_OFN_GET_CONFIG which allows to read data form the >> registers of said chip. >> >> This commit adds two helper functions to use those commands and sysfs >> attributes to use them. It also exposes some OFN configuration >> parameters via sysfs. > > Thank you for making the changes. I do not still quite like the games we > play with the OFN attributes, how about the patch below (on top of > yours)? > Yeah, I agree I like it the "two separate sysfs groups" group approach better. The only small nitpick about your patch is that I think we should use "get_unaligned_le16" instead of "le16_to_cpup"(In case anyone decides to run the driver on SuperH or C6x DSPs from TI :-)). Let me test it and if everything works as expected I'll apply you patch, convert it to "get_unaligned_le16", squash and send v3 of the patch. Thanks, Andrey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/mlock: fix BUG_ON unlocked page for nolinear VMAs
On 01/04/2014 04:52 AM, Linus Torvalds wrote: > On Fri, Jan 3, 2014 at 12:17 PM, Sasha Levin wrote: >> >> Ping? This BUG() is triggerable in 3.13-rc6 right now. > > So Andrew suggested just removing the BUG_ON(), but it's been there > for a *long* time. > > And I detest the patch that was sent out that said "Should I check?" > > Maybe we should just remove that mlock_vma_page() thing instead in > try_to_unmap_cluster()? Or maybe actually lock the page around calling I didn't get the reason why we have to call mlock_vma_page() in try_to_unmap_cluster() and I agree to just remove it. > it? > > Linus > -- Regards, -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/mlock: fix BUG_ON unlocked page for nolinear VMAs
On 01/03/2014 06:56 PM, Andrew Morton wrote: Nobody answered my question! Is this a new bug or is it a five-year-old bug which we only just discovered? I've rolled trinity back and was unable to reproduce this issue anymore. This seems to be a 5 year old bug. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: kernel BUG at include/linux/swapops.h:131!
On 01/02/2014 01:36 AM, Bob Liu wrote: I have no idea why this BUG_ON was triggered. And it looks like 'mm: kernel BUG at mm/huge_memory.c:1440!' have the same call trace with this one. Perhaps they were introduced by the same reason. Could you confirm whether those issues exist in v3.13-rc6? Yes, this is reproducible in 3.13-rc6. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V4 1/6] clk: exynos-audss: convert to platform device
Tomasz Figa wrote: > > Hi Kukjin, Mike, > > On Monday 02 of December 2013 07:43:42 Kukjin Kim wrote: > > On 11/28/13 03:41, Mike Turquette wrote: > > > Quoting Padma Venkat (2013-11-25 22:29:44) > > >> Hi Mike and Kukjin, > > >> > > >> On Tue, Oct 8, 2013 at 10:23 PM, Andrew Bresticker > > >> wrote: > > >>> Hi Mike and Kukjin, > > >>> > > >>> Any decisions regarding this patchset? I believe all comments have > > >>> been addressed. > > >>> > > >>> Thanks, > > >>> Andrew > > >> > > >> Any decisions on this patchset. These can be applied directly on > > >> linux-samsung tree. > > > > > > For all of the clk parts: > > > > > > Acked-by: Mike Turquette > > > > > > I'm happy to take them in as part of a pull request. > > > > > OK, Mike, I will take this series into samsung tree and let me send a > > pull request for your clk tree to avoid useless merge conflicts. > - some persons in Cc > Hmm, I can't find this series in any tree, so I guess it has been lost > in action. > Oops, sorry about that :-( > Should I take it through samsung-clk tree with your acks? > Tomasz, yes please take this series with my ack. Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 02/15] tpm/tpm_ppi: Check return value of acpi_get_name
From: Peter Huewe
If
status = acpi_get_name(handle, ACPI_FULL_PATHNAME, );
fails for whatever reason and does not return AE_OK
if (strstr(buffer.pointer, context) != NULL) {
does dereference a null pointer.
-> Check the return value and return the status to the caller
Found by coverity
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_ppi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/char/tpm/tpm_ppi.c b/drivers/char/tpm/tpm_ppi.c
index 18c5810..6ac9d27 100644
--- a/drivers/char/tpm/tpm_ppi.c
+++ b/drivers/char/tpm/tpm_ppi.c
@@ -30,6 +30,9 @@ static acpi_status ppi_callback(acpi_handle handle, u32
level, void *context,
acpi_status status;
struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
status = acpi_get_name(handle, ACPI_FULL_PATHNAME, );
+ if (ACPI_FAILURE(status))
+ return status;
+
if (strstr(buffer.pointer, context) != NULL) {
*return_value = handle;
kfree(buffer.pointer);
--
1.8.1.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 12/15] tpm: Use the ops structure instead of a copy in tpm_vendor_specific
From: Jason Gunthorpe
This builds on the last commit to use the ops structure in the core
and reduce the size of tpm_vendor_specific.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Joel Schopp
Reviewed-by: Ashley Lai
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm-interface.c| 34 --
drivers/char/tpm/tpm-sysfs.c| 2 +-
drivers/char/tpm/tpm.h | 9 +
drivers/char/tpm/tpm_i2c_stm_st33.c | 4 ++--
4 files changed, 16 insertions(+), 33 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 1b01246..62e10fd 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -353,7 +353,7 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
mutex_lock(>tpm_mutex);
- rc = chip->vendor.send(chip, (u8 *) buf, count);
+ rc = chip->ops->send(chip, (u8 *) buf, count);
if (rc < 0) {
dev_err(chip->dev,
"tpm_transmit: tpm_send: error %zd\n", rc);
@@ -365,12 +365,12 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char
*buf,
stop = jiffies + tpm_calc_ordinal_duration(chip, ordinal);
do {
- u8 status = chip->vendor.status(chip);
- if ((status & chip->vendor.req_complete_mask) ==
- chip->vendor.req_complete_val)
+ u8 status = chip->ops->status(chip);
+ if ((status & chip->ops->req_complete_mask) ==
+ chip->ops->req_complete_val)
goto out_recv;
- if (chip->vendor.req_canceled(chip, status)) {
+ if (chip->ops->req_canceled(chip, status)) {
dev_err(chip->dev, "Operation Canceled\n");
rc = -ECANCELED;
goto out;
@@ -380,13 +380,13 @@ ssize_t tpm_transmit(struct tpm_chip *chip, const char
*buf,
rmb();
} while (time_before(jiffies, stop));
- chip->vendor.cancel(chip);
+ chip->ops->cancel(chip);
dev_err(chip->dev, "Operation Timed out\n");
rc = -ETIME;
goto out;
out_recv:
- rc = chip->vendor.recv(chip, (u8 *) buf, bufsiz);
+ rc = chip->ops->recv(chip, (u8 *) buf, bufsiz);
if (rc < 0)
dev_err(chip->dev,
"tpm_transmit: tpm_recv: error %zd\n", rc);
@@ -807,12 +807,12 @@ EXPORT_SYMBOL_GPL(tpm_send);
static bool wait_for_tpm_stat_cond(struct tpm_chip *chip, u8 mask,
bool check_cancel, bool *canceled)
{
- u8 status = chip->vendor.status(chip);
+ u8 status = chip->ops->status(chip);
*canceled = false;
if ((status & mask) == mask)
return true;
- if (check_cancel && chip->vendor.req_canceled(chip, status)) {
+ if (check_cancel && chip->ops->req_canceled(chip, status)) {
*canceled = true;
return true;
}
@@ -828,7 +828,7 @@ int wait_for_tpm_stat(struct tpm_chip *chip, u8 mask,
unsigned long timeout,
bool canceled = false;
/* check current status */
- status = chip->vendor.status(chip);
+ status = chip->ops->status(chip);
if ((status & mask) == mask)
return 0;
@@ -855,7 +855,7 @@ again:
} else {
do {
msleep(TPM_TIMEOUT);
- status = chip->vendor.status(chip);
+ status = chip->ops->status(chip);
if ((status & mask) == mask)
return 0;
} while (time_before(jiffies, stop));
@@ -1027,9 +1027,6 @@ void tpm_dev_vendor_release(struct tpm_chip *chip)
if (!chip)
return;
- if (chip->vendor.release)
- chip->vendor.release(chip->dev);
-
clear_bit(chip->dev_num, dev_mask);
}
EXPORT_SYMBOL_GPL(tpm_dev_vendor_release);
@@ -1073,14 +1070,7 @@ struct tpm_chip *tpm_register_hardware(struct device
*dev,
mutex_init(>tpm_mutex);
INIT_LIST_HEAD(>list);
- chip->vendor.req_complete_mask = ops->req_complete_mask;
- chip->vendor.req_complete_val = ops->req_complete_val;
- chip->vendor.req_canceled = ops->req_canceled;
- chip->vendor.recv = ops->recv;
- chip->vendor.send = ops->send;
- chip->vendor.cancel = ops->cancel;
- chip->vendor.status = ops->status;
-
+ chip->ops = ops;
chip->dev_num = find_first_zero_bit(dev_mask, TPM_NUM_DEVICES);
if (chip->dev_num >= TPM_NUM_DEVICES) {
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index 506a07b..c3503cb 100644
--- a/drivers/char/tpm/tpm-sysfs.c
+++ b/drivers/char/tpm/tpm-sysfs.c
@@ -245,7 +245,7 @@ static ssize_t cancel_store(struct device *dev, struct
device_attribute *attr,
if (chip == NULL)
return 0;
[PATCH 04/15] tpm/tpm_ibmvtpm: fix unreachable code warning (smatch warning)
From: Peter Huewe
smatch complains:
drivers/char/tpm/tpm_ibmvtpm.c:510
ibmvtpm_crq_process() info: ignoring unreachable code.
-> The return is not necessary here, remove it
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_ibmvtpm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 2783a42..cab8d09 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -507,7 +507,6 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
dev_err(ibmvtpm->dev, "Unknown crq message type: %d\n",
crq->msg);
return;
}
- return;
case IBMVTPM_VALID_CMD:
switch (crq->msg) {
case VTPM_GET_RTCE_BUFFER_SIZE_RES:
--
1.8.1.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 14/15] tpm: tpm_tis: Fix compile problems with CONFIG_PM_SLEEP/CONFIG_PNP
From: Jason Gunthorpe
If CONFIG_PM_SLEEP=n, CONFIG_PNP=y we get this warning:
drivers/char/tpm/tpm_tis.c:706:13: warning: 'tpm_tis_reenable_interrupts'
defined but not used [-Wunused-function]
This seems to have been introduced in a2fa3fb0d 'tpm: convert tpm_tis driver
to use dev_pm_ops from legacy pm_ops'
Also, unpon reviewing, the #ifdefs around tpm_tis_pm are not right, the first
reference is protected, the second is not. tpm_tis_pm is always defined so we
can drop the #ifdef.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_tis.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index 8094b08..a9ed227 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -702,7 +702,7 @@ out_err:
return rc;
}
-#if defined(CONFIG_PNP) || defined(CONFIG_PM_SLEEP)
+#ifdef CONFIG_PM_SLEEP
static void tpm_tis_reenable_interrupts(struct tpm_chip *chip)
{
u32 intmask;
@@ -723,9 +723,7 @@ static void tpm_tis_reenable_interrupts(struct tpm_chip
*chip)
iowrite32(intmask,
chip->vendor.iobase + TPM_INT_ENABLE(chip->vendor.locality));
}
-#endif
-#ifdef CONFIG_PM_SLEEP
static int tpm_tis_resume(struct device *dev)
{
struct tpm_chip *chip = dev_get_drvdata(dev);
@@ -794,11 +792,9 @@ static struct pnp_driver tis_pnp_driver = {
.id_table = tpm_pnp_tbl,
.probe = tpm_tis_pnp_init,
.remove = tpm_tis_pnp_remove,
-#ifdef CONFIG_PM_SLEEP
.driver = {
.pm = _tis_pm,
},
-#endif
};
#define TIS_HID_USR_IDX sizeof(tpm_pnp_tbl)/sizeof(struct pnp_device_id) -2
--
1.8.1.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 13/15] tpm: Make tpm-dev allocate a per-file structure
From: Jason Gunthorpe
This consolidates everything that is only used within tpm-dev.c
into tpm-dev.c and out of the publicly visible struct tpm_chip.
The per-file allocation lays the ground work for someday fixing the
strange forced O_EXCL behaviour of the current code.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Joel Schopp
Reviewed-by: Ashley Lai
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm-dev.c | 100 ++---
drivers/char/tpm/tpm.h | 7
2 files changed, 57 insertions(+), 50 deletions(-)
diff --git a/drivers/char/tpm/tpm-dev.c b/drivers/char/tpm/tpm-dev.c
index 4f0cf2b..d9b774e 100644
--- a/drivers/char/tpm/tpm-dev.c
+++ b/drivers/char/tpm/tpm-dev.c
@@ -22,21 +22,34 @@
#include
#include "tpm.h"
+struct file_priv {
+ struct tpm_chip *chip;
+
+ /* Data passed to and from the tpm via the read/write calls */
+ atomic_t data_pending;
+ struct mutex buffer_mutex;
+
+ struct timer_list user_read_timer; /* user needs to claim result */
+ struct work_struct work;
+
+ u8 data_buffer[TPM_BUFSIZE];
+};
+
static void user_reader_timeout(unsigned long ptr)
{
- struct tpm_chip *chip = (struct tpm_chip *) ptr;
+ struct file_priv *priv = (struct file_priv *)ptr;
- schedule_work(>work);
+ schedule_work(>work);
}
static void timeout_work(struct work_struct *work)
{
- struct tpm_chip *chip = container_of(work, struct tpm_chip, work);
+ struct file_priv *priv = container_of(work, struct file_priv, work);
- mutex_lock(>buffer_mutex);
- atomic_set(>data_pending, 0);
- memset(chip->data_buffer, 0, TPM_BUFSIZE);
- mutex_unlock(>buffer_mutex);
+ mutex_lock(>buffer_mutex);
+ atomic_set(>data_pending, 0);
+ memset(priv->data_buffer, 0, sizeof(priv->data_buffer));
+ mutex_unlock(>buffer_mutex);
}
static int tpm_open(struct inode *inode, struct file *file)
@@ -44,6 +57,7 @@ static int tpm_open(struct inode *inode, struct file *file)
struct miscdevice *misc = file->private_data;
struct tpm_chip *chip = container_of(misc, struct tpm_chip,
vendor.miscdev);
+ struct file_priv *priv;
/* It's assured that the chip will be opened just once,
* by the check of is_open variable, which is protected
@@ -53,15 +67,20 @@ static int tpm_open(struct inode *inode, struct file *file)
return -EBUSY;
}
- chip->data_buffer = kzalloc(TPM_BUFSIZE, GFP_KERNEL);
- if (chip->data_buffer == NULL) {
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (priv == NULL) {
clear_bit(0, >is_open);
return -ENOMEM;
}
- atomic_set(>data_pending, 0);
+ priv->chip = chip;
+ atomic_set(>data_pending, 0);
+ mutex_init(>buffer_mutex);
+ setup_timer(>user_read_timer, user_reader_timeout,
+ (unsigned long)priv);
+ INIT_WORK(>work, timeout_work);
- file->private_data = chip;
+ file->private_data = priv;
get_device(chip->dev);
return 0;
}
@@ -69,28 +88,28 @@ static int tpm_open(struct inode *inode, struct file *file)
static ssize_t tpm_read(struct file *file, char __user *buf,
size_t size, loff_t *off)
{
- struct tpm_chip *chip = file->private_data;
+ struct file_priv *priv = file->private_data;
ssize_t ret_size;
int rc;
- del_singleshot_timer_sync(>user_read_timer);
- flush_work(>work);
- ret_size = atomic_read(>data_pending);
+ del_singleshot_timer_sync(>user_read_timer);
+ flush_work(>work);
+ ret_size = atomic_read(>data_pending);
if (ret_size > 0) { /* relay data */
ssize_t orig_ret_size = ret_size;
if (size < ret_size)
ret_size = size;
- mutex_lock(>buffer_mutex);
- rc = copy_to_user(buf, chip->data_buffer, ret_size);
- memset(chip->data_buffer, 0, orig_ret_size);
+ mutex_lock(>buffer_mutex);
+ rc = copy_to_user(buf, priv->data_buffer, ret_size);
+ memset(priv->data_buffer, 0, orig_ret_size);
if (rc)
ret_size = -EFAULT;
- mutex_unlock(>buffer_mutex);
+ mutex_unlock(>buffer_mutex);
}
- atomic_set(>data_pending, 0);
+ atomic_set(>data_pending, 0);
return ret_size;
}
@@ -98,7 +117,7 @@ static ssize_t tpm_read(struct file *file, char __user *buf,
static ssize_t tpm_write(struct file *file, const char __user *buf,
size_t size, loff_t *off)
{
- struct tpm_chip *chip = file->private_data;
+ struct file_priv *priv = file->private_data;
size_t in_size = size;
ssize_t out_size;
@@ -106,32 +125,33 @@ static
[PATCH 03/15] tpm/tpm_i2c_stm_st33: Check return code of get_burstcount
From: Peter Huewe
The 'get_burstcount' function can in some circumstances 'return -EBUSY' which
in tpm_stm_i2c_send is stored in an 'u32 burstcnt'
thus converting the signed value into an unsigned value, resulting
in 'burstcnt' being huge.
Changing the type to u32 only does not solve the problem as the signed
value is converted to an unsigned in I2C_WRITE_DATA, resulting in the
same effect.
Thus
-> Change type of burstcnt to u32 (the return type of get_burstcount)
-> Add a check for the return value of 'get_burstcount' and propagate a
potential error.
This makes also sense in the 'I2C_READ_DATA' case, where the there is no
signed/unsigned conversion.
found by coverity
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_i2c_stm_st33.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index a0d6ceb5..cf68403 100644
--- a/drivers/char/tpm/tpm_i2c_stm_st33.c
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -410,6 +410,8 @@ static int recv_data(struct tpm_chip *chip, u8 *buf, size_t
count)
>vendor.read_queue)
== 0) {
burstcnt = get_burstcount(chip);
+ if (burstcnt < 0)
+ return burstcnt;
len = min_t(int, burstcnt, count - size);
I2C_READ_DATA(client, TPM_DATA_FIFO, buf + size, len);
size += len;
@@ -451,7 +453,8 @@ static irqreturn_t tpm_ioserirq_handler(int irq, void
*dev_id)
static int tpm_stm_i2c_send(struct tpm_chip *chip, unsigned char *buf,
size_t len)
{
- u32 status, burstcnt = 0, i, size;
+ u32 status, i, size;
+ int burstcnt = 0;
int ret;
u8 data;
struct i2c_client *client;
@@ -482,6 +485,8 @@ static int tpm_stm_i2c_send(struct tpm_chip *chip, unsigned
char *buf,
for (i = 0; i < len - 1;) {
burstcnt = get_burstcount(chip);
+ if (burstcnt < 0)
+ return burstcnt;
size = min_t(int, len - i - 1, burstcnt);
ret = I2C_WRITE_DATA(client, TPM_DATA_FIFO, buf, size);
if (ret < 0)
--
1.8.1.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 15/15] tpm/tpm-sysfs: active_show() can be static
From: Fengguang Wu
so we make it static
CC: Jason Gunthorpe
CC: Peter Huewe
Signed-off-by: Fengguang Wu
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm-sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index c3503cb..01730a2 100644
--- a/drivers/char/tpm/tpm-sysfs.c
+++ b/drivers/char/tpm/tpm-sysfs.c
@@ -148,7 +148,7 @@ static ssize_t enabled_show(struct device *dev, struct
device_attribute *attr,
}
static DEVICE_ATTR_RO(enabled);
-ssize_t active_show(struct device *dev, struct device_attribute *attr,
+static ssize_t active_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
cap_t cap;
--
1.8.1.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 05/15] tpm/tpm_i2c_atmel: fix coccinelle warnings
From: Fengguang Wu
drivers/char/tpm/tpm_i2c_atmel.c:178:8-9: WARNING: return of 0/1 in function
'i2c_atmel_req_canceled' with return type bool
Return statements in functions returning bool should use
true/false instead of 1/0.
Generated by: coccinelle/misc/boolreturn.cocci
CC: Jason Gunthorpe
CC: Peter Huewe
Acked-by: Jason Gunthorpe
Signed-off-by: Fengguang Wu
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_i2c_atmel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
index c3cd7fe..af6805b 100644
--- a/drivers/char/tpm/tpm_i2c_atmel.c
+++ b/drivers/char/tpm/tpm_i2c_atmel.c
@@ -175,7 +175,7 @@ static struct attribute_group i2c_atmel_attr_grp = {
static bool i2c_atmel_req_canceled(struct tpm_chip *chip, u8 status)
{
- return 0;
+ return false;
}
static const struct tpm_vendor_specific i2c_atmel = {
--
1.8.1.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 06/15] tpm: MAINTAINERS: Cleanup TPM Maintainers file
From: Peter Huewe - removing stale/inactive maintainers - removing stale/outdated website - regrouped maintainers Signed-off-by: Peter Huewe --- MAINTAINERS | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d5e4ff3..3924b10 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8729,14 +8729,10 @@ S: Odd fixes F: drivers/media/usb/tm6000/ TPM DEVICE DRIVER -M: Leonidas Da Silva Barbosa -M: Ashley Lai M: Peter Huewe -M: Rajiv Andrade -W: http://tpmdd.sourceforge.net +M: Ashley Lai M: Marcel Selhorst -M: Sirrix AG -W: http://www.sirrix.com +W: http://tpmdd.sourceforge.net L: tpmdd-de...@lists.sourceforge.net (moderated for non-subscribers) S: Maintained F: drivers/char/tpm/ -- 1.8.1.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 08/15] tpm: Pull everything related to /dev/tpmX into tpm-dev.c
From: Jason Gunthorpe
CLASS-dev.c is a common idiom for Linux subsystems
This pulls all the code related to the miscdev into tpm-dev.c and makes it
static. The identical file_operation structs in the drivers are purged and the
tpm common code unconditionally creates the miscdev.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Joel Schopp
Reviewed-by: Ashley Lai
[phuewe:
tpm_dev_release is now used only in this file, thus the EXPORT_SYMBOL
can be dropped and the function be marked as static.
It has no other in-kernel users]
Signed-off-by: Peter Huewe
---
drivers/char/tpm/Makefile | 2 +-
drivers/char/tpm/tpm-dev.c | 199
drivers/char/tpm/tpm-interface.c| 181 +++-
drivers/char/tpm/tpm.h | 11 +-
drivers/char/tpm/tpm_atmel.c| 10 --
drivers/char/tpm/tpm_i2c_atmel.c| 10 --
drivers/char/tpm/tpm_i2c_infineon.c | 10 --
drivers/char/tpm/tpm_i2c_nuvoton.c | 10 --
drivers/char/tpm/tpm_i2c_stm_st33.c | 10 --
drivers/char/tpm/tpm_ibmvtpm.c | 10 --
drivers/char/tpm/tpm_infineon.c | 10 --
drivers/char/tpm/tpm_nsc.c | 10 --
drivers/char/tpm/tpm_tis.c | 11 --
drivers/char/tpm/xen-tpmfront.c | 12 ---
14 files changed, 217 insertions(+), 279 deletions(-)
create mode 100644 drivers/char/tpm/tpm-dev.c
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index b80a400..d835e87 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -2,7 +2,7 @@
# Makefile for the kernel tpm device drivers.
#
obj-$(CONFIG_TCG_TPM) += tpm.o
-tpm-y := tpm-interface.o
+tpm-y := tpm-interface.o tpm-dev.o
tpm-$(CONFIG_ACPI) += tpm_ppi.o
ifdef CONFIG_ACPI
diff --git a/drivers/char/tpm/tpm-dev.c b/drivers/char/tpm/tpm-dev.c
new file mode 100644
index 000..4f0cf2b
--- /dev/null
+++ b/drivers/char/tpm/tpm-dev.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright (C) 2004 IBM Corporation
+ * Authors:
+ * Leendert van Doorn
+ * Dave Safford
+ * Reiner Sailer
+ * Kylene Hall
+ *
+ * Copyright (C) 2013 Obsidian Research Corp
+ * Jason Gunthorpe
+ *
+ * Device file system interface to the TPM
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation, version 2 of the
+ * License.
+ *
+ */
+#include
+#include
+#include
+#include "tpm.h"
+
+static void user_reader_timeout(unsigned long ptr)
+{
+ struct tpm_chip *chip = (struct tpm_chip *) ptr;
+
+ schedule_work(>work);
+}
+
+static void timeout_work(struct work_struct *work)
+{
+ struct tpm_chip *chip = container_of(work, struct tpm_chip, work);
+
+ mutex_lock(>buffer_mutex);
+ atomic_set(>data_pending, 0);
+ memset(chip->data_buffer, 0, TPM_BUFSIZE);
+ mutex_unlock(>buffer_mutex);
+}
+
+static int tpm_open(struct inode *inode, struct file *file)
+{
+ struct miscdevice *misc = file->private_data;
+ struct tpm_chip *chip = container_of(misc, struct tpm_chip,
+vendor.miscdev);
+
+ /* It's assured that the chip will be opened just once,
+* by the check of is_open variable, which is protected
+* by driver_lock. */
+ if (test_and_set_bit(0, >is_open)) {
+ dev_dbg(chip->dev, "Another process owns this TPM\n");
+ return -EBUSY;
+ }
+
+ chip->data_buffer = kzalloc(TPM_BUFSIZE, GFP_KERNEL);
+ if (chip->data_buffer == NULL) {
+ clear_bit(0, >is_open);
+ return -ENOMEM;
+ }
+
+ atomic_set(>data_pending, 0);
+
+ file->private_data = chip;
+ get_device(chip->dev);
+ return 0;
+}
+
+static ssize_t tpm_read(struct file *file, char __user *buf,
+ size_t size, loff_t *off)
+{
+ struct tpm_chip *chip = file->private_data;
+ ssize_t ret_size;
+ int rc;
+
+ del_singleshot_timer_sync(>user_read_timer);
+ flush_work(>work);
+ ret_size = atomic_read(>data_pending);
+ if (ret_size > 0) { /* relay data */
+ ssize_t orig_ret_size = ret_size;
+ if (size < ret_size)
+ ret_size = size;
+
+ mutex_lock(>buffer_mutex);
+ rc = copy_to_user(buf, chip->data_buffer, ret_size);
+ memset(chip->data_buffer, 0, orig_ret_size);
+ if (rc)
+ ret_size = -EFAULT;
+
+ mutex_unlock(>buffer_mutex);
+ }
+
+ atomic_set(>data_pending, 0);
+
+ return ret_size;
+}
+
+static ssize_t tpm_write(struct file *file, const char __user *buf,
+size_t size, loff_t *off)
+{
+ struct tpm_chip *chip = file->private_data;
+ size_t in_size = size;
+ ssize_t out_size;
+
+ /* cannot perform a write until the read has cleared
+ either via
[PATCH 07/15] char: tpm: nuvoton: remove unused variable
From: Michal Nazarewicz
“wait” wait queue is defined but never used in the function, thus
it can be removed.
Signed-off-by: Michal Nazarewicz
Acked-by: Jason Gunthorpe
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_i2c_nuvoton.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c
b/drivers/char/tpm/tpm_i2c_nuvoton.c
index 6276fea..4f5ac25 100644
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
@@ -178,7 +178,6 @@ static int i2c_nuvoton_wait_for_stat(struct tpm_chip *chip,
u8 mask, u8 value,
{
if (chip->vendor.irq && queue) {
s32 rc;
- DEFINE_WAIT(wait);
struct priv_data *priv = chip->vendor.priv;
unsigned int cur_intrs = priv->intrs;
--
1.8.1.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 09/15] tpm: Move sysfs functions from tpm-interface to tpm-sysfs
From: Jason Gunthorpe
CLASS-sysfs.c is a common idiom for linux subsystems.
This is the first step to pulling all the sysfs support code from
the drivers into tpm-sysfs. This is a plain text copy from tpm-interface
with support changes to make it compile.
_tpm_pcr_read is made non-static and is called tpm_pcr_read_dev.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Peter Huewe
---
drivers/char/tpm/Makefile| 2 +-
drivers/char/tpm/tpm-interface.c | 275 +-
drivers/char/tpm/tpm-sysfs.c | 281 +++
drivers/char/tpm/tpm.h | 30 +
4 files changed, 314 insertions(+), 274 deletions(-)
create mode 100644 drivers/char/tpm/tpm-sysfs.c
diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index d835e87..4d85dd6 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -2,7 +2,7 @@
# Makefile for the kernel tpm device drivers.
#
obj-$(CONFIG_TCG_TPM) += tpm.o
-tpm-y := tpm-interface.o tpm-dev.o
+tpm-y := tpm-interface.o tpm-dev.o tpm-sysfs.o
tpm-$(CONFIG_ACPI) += tpm_ppi.o
ifdef CONFIG_ACPI
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 0b9e9ca..3f8bddf 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -32,13 +32,6 @@
#include "tpm.h"
#include "tpm_eventlog.h"
-enum tpm_duration {
- TPM_SHORT = 0,
- TPM_MEDIUM = 1,
- TPM_LONG = 2,
- TPM_UNDEFINED,
-};
-
#define TPM_MAX_ORDINAL 243
#define TSC_MAX_ORDINAL 12
#define TPM_PROTECTED_COMMAND 0x00
@@ -405,24 +398,6 @@ out:
#define TPM_DIGEST_SIZE 20
#define TPM_RET_CODE_IDX 6
-enum tpm_capabilities {
- TPM_CAP_FLAG = cpu_to_be32(4),
- TPM_CAP_PROP = cpu_to_be32(5),
- CAP_VERSION_1_1 = cpu_to_be32(0x06),
- CAP_VERSION_1_2 = cpu_to_be32(0x1A)
-};
-
-enum tpm_sub_capabilities {
- TPM_CAP_PROP_PCR = cpu_to_be32(0x101),
- TPM_CAP_PROP_MANUFACTURER = cpu_to_be32(0x103),
- TPM_CAP_FLAG_PERM = cpu_to_be32(0x108),
- TPM_CAP_FLAG_VOL = cpu_to_be32(0x109),
- TPM_CAP_PROP_OWNER = cpu_to_be32(0x111),
- TPM_CAP_PROP_TIS_TIMEOUT = cpu_to_be32(0x115),
- TPM_CAP_PROP_TIS_DURATION = cpu_to_be32(0x120),
-
-};
-
static ssize_t transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd,
int len, const char *desc)
{
@@ -442,7 +417,6 @@ static ssize_t transmit_cmd(struct tpm_chip *chip, struct
tpm_cmd_t *cmd,
}
#define TPM_INTERNAL_RESULT_SIZE 200
-#define TPM_TAG_RQU_COMMAND cpu_to_be16(193)
#define TPM_ORD_GET_CAP cpu_to_be32(101)
#define TPM_ORD_GET_RANDOM cpu_to_be32(70)
@@ -642,70 +616,6 @@ static int tpm_continue_selftest(struct tpm_chip *chip)
return rc;
}
-ssize_t tpm_show_enabled(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- cap_t cap;
- ssize_t rc;
-
- rc = tpm_getcap(dev, TPM_CAP_FLAG_PERM, ,
-"attempting to determine the permanent enabled state");
- if (rc)
- return 0;
-
- rc = sprintf(buf, "%d\n", !cap.perm_flags.disable);
- return rc;
-}
-EXPORT_SYMBOL_GPL(tpm_show_enabled);
-
-ssize_t tpm_show_active(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- cap_t cap;
- ssize_t rc;
-
- rc = tpm_getcap(dev, TPM_CAP_FLAG_PERM, ,
-"attempting to determine the permanent active state");
- if (rc)
- return 0;
-
- rc = sprintf(buf, "%d\n", !cap.perm_flags.deactivated);
- return rc;
-}
-EXPORT_SYMBOL_GPL(tpm_show_active);
-
-ssize_t tpm_show_owned(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- cap_t cap;
- ssize_t rc;
-
- rc = tpm_getcap(dev, TPM_CAP_PROP_OWNER, ,
-"attempting to determine the owner state");
- if (rc)
- return 0;
-
- rc = sprintf(buf, "%d\n", cap.owned);
- return rc;
-}
-EXPORT_SYMBOL_GPL(tpm_show_owned);
-
-ssize_t tpm_show_temp_deactivated(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- cap_t cap;
- ssize_t rc;
-
- rc = tpm_getcap(dev, TPM_CAP_FLAG_VOL, ,
-"attempting to determine the temporary state");
- if (rc)
- return 0;
-
- rc = sprintf(buf, "%d\n", cap.stclear_flags.deactivated);
- return rc;
-}
-EXPORT_SYMBOL_GPL(tpm_show_temp_deactivated);
-
/*
* tpm_chip_find_get - return tpm_chip for given chip number
*/
@@ -735,7 +645,7 @@ static struct tpm_input_header pcrread_header = {
.ordinal = TPM_ORDINAL_PCRREAD
};
-static int __tpm_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
+int tpm_pcr_read_dev(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
{
int rc;
struct tpm_cmd_t cmd;
@@ -770,7 +680,7 @@
[PATCH 11/15] tpm: Create a tpm_class_ops structure and use it in the drivers
From: Jason Gunthorpe
This replaces the static initialization of a tpm_vendor_specific
structure in the drivers with the standard Linux idiom of providing
a const structure of function pointers.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Joel Schopp
Reviewed-by: Ashley Lai
[phuewe: did apply manually due to commit
191ffc6bde3 tpm/tpm_i2c_atmel: fix coccinelle warnings]
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm-interface.c| 10 --
drivers/char/tpm/tpm.h | 6 +++---
drivers/char/tpm/tpm_atmel.c| 2 +-
drivers/char/tpm/tpm_i2c_atmel.c| 2 +-
drivers/char/tpm/tpm_i2c_infineon.c | 2 +-
drivers/char/tpm/tpm_i2c_nuvoton.c | 2 +-
drivers/char/tpm/tpm_i2c_stm_st33.c | 2 +-
drivers/char/tpm/tpm_ibmvtpm.c | 2 +-
drivers/char/tpm/tpm_infineon.c | 2 +-
drivers/char/tpm/tpm_nsc.c | 2 +-
drivers/char/tpm/tpm_tis.c | 2 +-
drivers/char/tpm/xen-tpmfront.c | 2 +-
include/linux/tpm.h | 12
13 files changed, 33 insertions(+), 15 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 389d483..1b01246 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -1060,7 +1060,7 @@ static void tpm_dev_release(struct device *dev)
* pci_disable_device
*/
struct tpm_chip *tpm_register_hardware(struct device *dev,
- const struct tpm_vendor_specific *entry)
+ const struct tpm_class_ops *ops)
{
struct tpm_chip *chip;
@@ -1073,7 +1073,13 @@ struct tpm_chip *tpm_register_hardware(struct device
*dev,
mutex_init(>tpm_mutex);
INIT_LIST_HEAD(>list);
- memcpy(>vendor, entry, sizeof(struct tpm_vendor_specific));
+ chip->vendor.req_complete_mask = ops->req_complete_mask;
+ chip->vendor.req_complete_val = ops->req_complete_val;
+ chip->vendor.req_canceled = ops->req_canceled;
+ chip->vendor.recv = ops->recv;
+ chip->vendor.send = ops->send;
+ chip->vendor.cancel = ops->cancel;
+ chip->vendor.status = ops->status;
chip->dev_num = find_first_zero_bit(dev_mask, TPM_NUM_DEVICES);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 14ba162..a56af2c 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -64,8 +64,8 @@ enum tpm_duration {
struct tpm_chip;
struct tpm_vendor_specific {
- const u8 req_complete_mask;
- const u8 req_complete_val;
+ u8 req_complete_mask;
+ u8 req_complete_val;
bool (*req_canceled)(struct tpm_chip *chip, u8 status);
void __iomem *iobase; /* ioremapped address */
unsigned long base; /* TPM base address */
@@ -336,7 +336,7 @@ extern void tpm_gen_interrupt(struct tpm_chip *);
extern int tpm_do_selftest(struct tpm_chip *);
extern unsigned long tpm_calc_ordinal_duration(struct tpm_chip *, u32);
extern struct tpm_chip* tpm_register_hardware(struct device *,
-const struct tpm_vendor_specific *);
+ const struct tpm_class_ops *ops);
extern void tpm_dev_vendor_release(struct tpm_chip *);
extern void tpm_remove_hardware(struct device *);
extern int tpm_pm_suspend(struct device *);
diff --git a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
index 7e665d0..6069d13 100644
--- a/drivers/char/tpm/tpm_atmel.c
+++ b/drivers/char/tpm/tpm_atmel.c
@@ -121,7 +121,7 @@ static bool tpm_atml_req_canceled(struct tpm_chip *chip, u8
status)
return (status == ATML_STATUS_READY);
}
-static const struct tpm_vendor_specific tpm_atmel = {
+static const struct tpm_class_ops tpm_atmel = {
.recv = tpm_atml_recv,
.send = tpm_atml_send,
.cancel = tpm_atml_cancel,
diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
index fe8bdce..7727292 100644
--- a/drivers/char/tpm/tpm_i2c_atmel.c
+++ b/drivers/char/tpm/tpm_i2c_atmel.c
@@ -140,7 +140,7 @@ static bool i2c_atmel_req_canceled(struct tpm_chip *chip,
u8 status)
return false;
}
-static const struct tpm_vendor_specific i2c_atmel = {
+static const struct tpm_class_ops i2c_atmel = {
.status = i2c_atmel_read_status,
.recv = i2c_atmel_recv,
.send = i2c_atmel_send,
diff --git a/drivers/char/tpm/tpm_i2c_infineon.c
b/drivers/char/tpm/tpm_i2c_infineon.c
index ac1218f..52b9b2b 100644
--- a/drivers/char/tpm/tpm_i2c_infineon.c
+++ b/drivers/char/tpm/tpm_i2c_infineon.c
@@ -566,7 +566,7 @@ static bool tpm_tis_i2c_req_canceled(struct tpm_chip *chip,
u8 status)
return (status == TPM_STS_COMMAND_READY);
}
-static struct tpm_vendor_specific tpm_tis_i2c = {
+static const struct tpm_class_ops tpm_tis_i2c = {
.status = tpm_tis_i2c_status,
.recv = tpm_tis_i2c_recv,
.send = tpm_tis_i2c_send,
diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c
[PATCH 10/15] tpm: Pull all driver sysfs code into tpm-sysfs.c
From: Jason Gunthorpe
The tpm core now sets up and controls all sysfs attributes, instead
of having each driver have a unique take on it.
All drivers now now have a uniform set of attributes, and no sysfs
related entry points are exported from the tpm core module.
This also uses the new method used to declare sysfs attributes
with DEVICE_ATTR_RO and 'struct attribute *'
Signed-off-by: Jason Gunthorpe
[phuewe: had to apply the tpm_i2c_atmel part manually due to commit
191ffc6bde3fc tpm/tpm_i2c_atmel: fix coccinelle warnings]
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm-interface.c| 4 +-
drivers/char/tpm/tpm-sysfs.c| 99 +
drivers/char/tpm/tpm.h | 24 +
drivers/char/tpm/tpm_atmel.c| 16 --
drivers/char/tpm/tpm_i2c_atmel.c| 30 ---
drivers/char/tpm/tpm_i2c_infineon.c | 30 ---
drivers/char/tpm/tpm_i2c_nuvoton.c | 30 ---
drivers/char/tpm/tpm_i2c_stm_st33.c | 25 --
drivers/char/tpm/tpm_ibmvtpm.c | 28 ---
drivers/char/tpm/tpm_infineon.c | 16 --
drivers/char/tpm/tpm_nsc.c | 16 --
drivers/char/tpm/tpm_tis.c | 30 ---
drivers/char/tpm/xen-tpmfront.c | 31
13 files changed, 72 insertions(+), 307 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 3f8bddf..389d483 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -879,7 +879,7 @@ void tpm_remove_hardware(struct device *dev)
synchronize_rcu();
tpm_dev_del_device(chip);
- sysfs_remove_group(>kobj, chip->vendor.attr_group);
+ tpm_sysfs_del_device(chip);
tpm_remove_ppi(>kobj);
tpm_bios_log_teardown(chip->bios_dir);
@@ -1095,7 +1095,7 @@ struct tpm_chip *tpm_register_hardware(struct device *dev,
if (tpm_dev_add_device(chip))
goto put_device;
- if (sysfs_create_group(>kobj, chip->vendor.attr_group))
+ if (tpm_sysfs_add_device(chip))
goto del_misc;
if (tpm_add_ppi(>kobj))
diff --git a/drivers/char/tpm/tpm-sysfs.c b/drivers/char/tpm/tpm-sysfs.c
index 310d960..506a07b 100644
--- a/drivers/char/tpm/tpm-sysfs.c
+++ b/drivers/char/tpm/tpm-sysfs.c
@@ -6,6 +6,9 @@
* Reiner Sailer
* Kylene Hall
*
+ * Copyright (C) 2013 Obsidian Research Corp
+ * Jason Gunthorpe
+ *
* sysfs filesystem inspection interface to the TPM
*
* This program is free software; you can redistribute it and/or
@@ -43,9 +46,8 @@ static struct tpm_input_header tpm_readpubek_header = {
.length = cpu_to_be32(30),
.ordinal = TPM_ORD_READPUBEK
};
-
-ssize_t tpm_show_pubek(struct device *dev, struct device_attribute *attr,
- char *buf)
+static ssize_t pubek_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
u8 *data;
struct tpm_cmd_t tpm_cmd;
@@ -99,10 +101,10 @@ out:
rc = str - buf;
return rc;
}
-EXPORT_SYMBOL_GPL(tpm_show_pubek);
+static DEVICE_ATTR_RO(pubek);
-ssize_t tpm_show_pcrs(struct device *dev, struct device_attribute *attr,
- char *buf)
+static ssize_t pcrs_show(struct device *dev, struct device_attribute *attr,
+char *buf)
{
cap_t cap;
u8 digest[TPM_DIGEST_SIZE];
@@ -128,10 +130,10 @@ ssize_t tpm_show_pcrs(struct device *dev, struct
device_attribute *attr,
}
return str - buf;
}
-EXPORT_SYMBOL_GPL(tpm_show_pcrs);
+static DEVICE_ATTR_RO(pcrs);
-ssize_t tpm_show_enabled(struct device *dev, struct device_attribute *attr,
- char *buf)
+static ssize_t enabled_show(struct device *dev, struct device_attribute *attr,
+char *buf)
{
cap_t cap;
ssize_t rc;
@@ -144,10 +146,10 @@ ssize_t tpm_show_enabled(struct device *dev, struct
device_attribute *attr,
rc = sprintf(buf, "%d\n", !cap.perm_flags.disable);
return rc;
}
-EXPORT_SYMBOL_GPL(tpm_show_enabled);
+static DEVICE_ATTR_RO(enabled);
-ssize_t tpm_show_active(struct device *dev, struct device_attribute *attr,
- char *buf)
+ssize_t active_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
cap_t cap;
ssize_t rc;
@@ -160,10 +162,10 @@ ssize_t tpm_show_active(struct device *dev, struct
device_attribute *attr,
rc = sprintf(buf, "%d\n", !cap.perm_flags.deactivated);
return rc;
}
-EXPORT_SYMBOL_GPL(tpm_show_active);
+static DEVICE_ATTR_RO(active);
-ssize_t tpm_show_owned(struct device *dev, struct device_attribute *attr,
- char *buf)
+static ssize_t owned_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
cap_t cap;
ssize_t rc;
@@ -176,10 +178,10 @@ ssize_t tpm_show_owned(struct device *dev, struct
[PATCH 01/15] tpm/tpm_ppi: Do not compare strcmp(a,b) == -1
From: Peter Huewe
Depending on the implementation strcmp might return the difference between
two strings not only -1,0,1 consequently
if (strcmp (a,b) == -1)
might lead to taking the wrong branch
-> compare with < 0 instead,
which in any case is more canonical.
Cc: sta...@vger.kernel.org
Signed-off-by: Peter Huewe
---
drivers/char/tpm/tpm_ppi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm_ppi.c b/drivers/char/tpm/tpm_ppi.c
index 8e562dc..18c5810 100644
--- a/drivers/char/tpm/tpm_ppi.c
+++ b/drivers/char/tpm/tpm_ppi.c
@@ -169,7 +169,7 @@ static ssize_t tpm_store_ppi_request(struct device *dev,
* is updated with function index from SUBREQ to SUBREQ2 since PPI
* version 1.1
*/
- if (strcmp(version, "1.1") == -1)
+ if (strcmp(version, "1.1") < 0)
params[2].integer.value = TPM_PPI_FN_SUBREQ;
else
params[2].integer.value = TPM_PPI_FN_SUBREQ2;
@@ -179,7 +179,7 @@ static ssize_t tpm_store_ppi_request(struct device *dev,
* string/package type. For PPI version 1.0 and 1.1, use buffer type
* for compatibility, and use package type since 1.2 according to spec.
*/
- if (strcmp(version, "1.2") == -1) {
+ if (strcmp(version, "1.2") < 0) {
params[3].type = ACPI_TYPE_BUFFER;
params[3].buffer.length = sizeof(req);
sscanf(buf, "%d", );
@@ -245,7 +245,7 @@ static ssize_t tpm_show_ppi_transition_action(struct device
*dev,
* (e.g. Capella with PPI 1.0) need integer/string/buffer type, so for
* compatibility, define params[3].type as buffer, if PPI version < 1.2
*/
- if (strcmp(version, "1.2") == -1) {
+ if (strcmp(version, "1.2") < 0) {
params[3].type = ACPI_TYPE_BUFFER;
params[3].buffer.length = 0;
params[3].buffer.pointer = NULL;
@@ -387,7 +387,7 @@ static ssize_t show_ppi_operations(char *buf, u32 start,
u32 end)
kfree(output.pointer);
output.length = ACPI_ALLOCATE_BUFFER;
output.pointer = NULL;
- if (strcmp(version, "1.2") == -1)
+ if (strcmp(version, "1.2") < 0)
return -EPERM;
params[2].integer.value = TPM_PPI_FN_GETOPR;
--
1.8.1.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/
[ANNOUNCE] 3.4.75-rt93
Dear RT Folks, I'm pleased to announce the 3.4.75-rt93 stable release. This release is just an update to the new stable 3.4.75 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.4-rt Head SHA1: 9d111c9c3814158097723d27029a9d214a8cd20e Or to build 3.4.75-rt93 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.75.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.75-rt93.patch.xz Enjoy, -- 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/
TPM Changes for 3.14
Hi James, since the next merge window approaches, can you please pull the following TPM Changes for 3.14? I'll send the patches as replies to this email. The following changes since commit 802eee95bde72fd0cd0f3a5b2098375a487d1eda: Linux 3.13-rc6 (2013-12-29 16:01:33 -0800) are available in the git repository at: https://github.com/PeterHuewe/linux-tpmdd for-james for you to fetch changes up to 34b720f8577f62ef7d9d06b46b7e3ad1a466bae5: tpm/tpm-sysfs: active_show() can be static (2014-01-04 03:24:00 +0100) Fengguang Wu (2): tpm/tpm_i2c_atmel: fix coccinelle warnings tpm/tpm-sysfs: active_show() can be static Jason Gunthorpe (7): tpm: Pull everything related to /dev/tpmX into tpm-dev.c tpm: Move sysfs functions from tpm-interface to tpm-sysfs tpm: Pull all driver sysfs code into tpm-sysfs.c tpm: Create a tpm_class_ops structure and use it in the drivers tpm: Use the ops structure instead of a copy in tpm_vendor_specific tpm: Make tpm-dev allocate a per-file structure tpm: tpm_tis: Fix compile problems with CONFIG_PM_SLEEP/CONFIG_PNP Michal Nazarewicz (1): char: tpm: nuvoton: remove unused variable Peter Huewe (5): tpm/tpm_ppi: Do not compare strcmp(a,b) == -1 tpm/tpm_ppi: Check return value of acpi_get_name tpm/tpm_i2c_stm_st33: Check return code of get_burstcount tpm/tpm_ibmvtpm: fix unreachable code warning (smatch warning) tpm: MAINTAINERS: Cleanup TPM Maintainers file MAINTAINERS | 8 +- drivers/char/tpm/Makefile | 2 +- drivers/char/tpm/tpm-dev.c | 213 drivers/char/tpm/tpm-interface.c| 488 +++- drivers/char/tpm/tpm-sysfs.c| 318 +++ drivers/char/tpm/tpm.h | 83 +++--- drivers/char/tpm/tpm_atmel.c| 28 +-- drivers/char/tpm/tpm_i2c_atmel.c| 44 +--- drivers/char/tpm/tpm_i2c_infineon.c | 42 +--- drivers/char/tpm/tpm_i2c_nuvoton.c | 43 +--- drivers/char/tpm/tpm_i2c_stm_st33.c | 48 +--- drivers/char/tpm/tpm_ibmvtpm.c | 41 +-- drivers/char/tpm/tpm_infineon.c | 28 +-- drivers/char/tpm/tpm_nsc.c | 28 +-- drivers/char/tpm/tpm_ppi.c | 11 +- drivers/char/tpm/tpm_tis.c | 49 +--- drivers/char/tpm/xen-tpmfront.c | 45 +--- include/linux/tpm.h | 12 + 18 files changed, 640 insertions(+), 891 deletions(-) create mode 100644 drivers/char/tpm/tpm-dev.c create mode 100644 drivers/char/tpm/tpm-sysfs.c Thanks, Peter signature.asc Description: This is a digitally signed message part.
[ANNOUNCE] 3.10.25-rt23
Dear RT Folks, I'm pleased to announce the 3.10.25-rt23 stable release. This release is just an update to the new stable 3.10.25 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.10-rt Head SHA1: ee85b05eecc9f13a1d8e104e1cdbadef1bfea75e Or to build 3.10.25-rt23 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.25.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.25-rt23.patch.xz Enjoy, -- 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: [PATCH v12 10/18] xen/pvh: Update E820 to work with PVH (v2)
On Fri, Jan 03, 2014 at 05:23:37PM -0800, Mukesh Rathor wrote: > On Thu, 2 Jan 2014 13:41:34 -0500 > Konrad Rzeszutek Wilk wrote: > > > On Thu, Jan 02, 2014 at 04:14:32PM +, David Vrabel wrote: > > > On 01/01/14 04:35, Konrad Rzeszutek Wilk wrote: > > > > From: Mukesh Rathor > > > > > > > > In xen_add_extra_mem() we can skip updating P2M as it's managed > > > > by Xen. PVH maps the entire IO space, but only RAM pages need > > > > to be repopulated. > > > > > > So this looks minimal but I can't work out what PVH actually needs > > > to do here. This code really doesn't need to be made any more > > > confusing. > > > > I gather you prefer Mukesh's original version? > > I think Konrad thats easier to follow as one can quickly spot > the PVH difference... but your call. I prefer the one that re-uses the existing logic. That has been - both in the hypervisor and in the Linux kernel for PVH - the path - just do nice little one-offs that do something simpler and easier than the old PV path. That way one can easily spot how PV vs PVH works for certain operations. It also from a testing coverage perspective means we end up using the same codepath for both PV and PVH - so we do get more testing exposure for different modes. > > thanks > mukesh > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] lib/vsprintf: add %pT[C012] format specifier
I'm planning to convert task_struct->comm to use RCU so that they always get
consistent result. Inconsistent result (e.g. trailing '\0' byte is emitted when
printing string argument) is caused by breaking a rule that the string argument
must not change during the function when it is passed as "const char *" (e.g.
strcmp() and printf("%s")).
Although task_struct->comm is not modified so frequently, task_struct->comm
passed as a "const char *" argument can change at any moment unless we pass
task_struct->comm via get_task_comm().
Since there are a lot of current->comm readers, Andrew Morton suggested that
we might be able to omit passing the argument and I wrote a patch that adds a
second format-start character for omit passing the argument.
Kees Cook wrote:
> I'm on board with the idea of embedding comm/pid/whatever, but I
> either missed or do not understand why a second format-start character
> is being added. I think this will complicate audits and maybe trigger
> weird info leaks (imagine printing a string that was %-escaped, but
> not 0x1A-escaped?)
The second format-start character applies to only format string.
If we use a dynamically generated string that was %-escaped at run-time as a
format string, we will leak globally accessible variables. But are there such
users? Such users are rare because they are already problematic since compilers
cannot check for safety using __printf() attributes at build-time.
> Hrmpf. Yeah, on the fence about this.
But I'm fine even if we cannot agree with the second format-start character.
Since my purpose is to make reading of task_struct->comm consistent, %pT-like
extension is what I want for centralizing pointer dereferences.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [net-next] pci_regs.h: Add PCI bus link speed and width defines
On Fri, 2014-01-03 at 20:48 -0500, David Miller wrote: > From: Jeff Kirsher > Date: Fri, 03 Jan 2014 17:27:39 -0800 > > > What do you want to do with the current series of patches > > (mainly the ixgbe LER patches) on my tree? I know that there is a > > thread going on between Joe Perches and Mark, but it sounded like Mark > > is working on a follow-on patch to address Joe's concerns. > > I want the LER config option removed. Ok. signature.asc Description: This is a digitally signed message part
Re: [net-next] pci_regs.h: Add PCI bus link speed and width defines
From: Jeff Kirsher Date: Fri, 03 Jan 2014 17:27:39 -0800 > What do you want to do with the current series of patches > (mainly the ixgbe LER patches) on my tree? I know that there is a > thread going on between Joe Perches and Mark, but it sounded like Mark > is working on a follow-on patch to address Joe's concerns. I want the LER config option removed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ims-pcu: Add commands supported by the new version of the FW
Hi Andrey,
On Wed, Jan 01, 2014 at 04:47:01PM -0800, Andrey Smirnov wrote:
> New version of the PCU firmware supports two new commands:
> - IMS_PCU_CMD_OFN_SET_CONFIG which allows to write data to the
> registers of one finger navigation(OFN) chip present on the device
> - IMS_PCU_CMD_OFN_GET_CONFIG which allows to read data form the
> registers of said chip.
>
> This commit adds two helper functions to use those commands and sysfs
> attributes to use them. It also exposes some OFN configuration
> parameters via sysfs.
Thank you for making the changes. I do not still quite like the games we
play with the OFN attributes, how about the patch below (on top of
yours)?
Thanks.
--
Dmitry
Input: ims-pci - misc changes
From: Dmitry Torokhov
Split OFN code into separate named attribute group, tidy up attribute
handling.
Signed-off-by: Dmitry Torokhov
---
drivers/input/misc/ims-pcu.c | 330 --
1 file changed, 156 insertions(+), 174 deletions(-)
diff --git a/drivers/input/misc/ims-pcu.c b/drivers/input/misc/ims-pcu.c
index 4244f47..bd25a78 100644
--- a/drivers/input/misc/ims-pcu.c
+++ b/drivers/input/misc/ims-pcu.c
@@ -1224,11 +1224,87 @@ ims_pcu_update_firmware_status_show(struct device *dev,
static DEVICE_ATTR(update_firmware_status, S_IRUGO,
ims_pcu_update_firmware_status_show, NULL);
-enum pcu_ofn_offsets {
- OFN_REG_RESULT_LSB_OFFSET = 2,
- OFN_REG_RESULT_MSB_OFFSET = 3,
+static struct attribute *ims_pcu_attrs[] = {
+ _pcu_attr_part_number.dattr.attr,
+ _pcu_attr_serial_number.dattr.attr,
+ _pcu_attr_date_of_manufacturing.dattr.attr,
+ _pcu_attr_fw_version.dattr.attr,
+ _pcu_attr_bl_version.dattr.attr,
+ _pcu_attr_reset_reason.dattr.attr,
+ _attr_reset_device.attr,
+ _attr_update_firmware.attr,
+ _attr_update_firmware_status.attr,
+ NULL,
+};
+
+static umode_t ims_pcu_is_attr_visible(struct kobject *kobj,
+ struct attribute *attr, int n)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct usb_interface *intf = to_usb_interface(dev);
+ struct ims_pcu *pcu = usb_get_intfdata(intf);
+ umode_t mode = attr->mode;
+
+ if (pcu->bootloader_mode) {
+ if (attr != _attr_update_firmware_status.attr &&
+ attr != _attr_update_firmware.attr &&
+ attr != _attr_reset_device.attr) {
+ mode = 0;
+ }
+ } else {
+ if (attr == _attr_update_firmware_status.attr)
+ mode = 0;
+ }
+
+ return mode;
+}
+
+static struct attribute_group ims_pcu_attr_group = {
+ .is_visible = ims_pcu_is_attr_visible,
+ .attrs = ims_pcu_attrs,
};
+/* Support for a separate OFN attribute group */
+
+#define OFN_REG_RESULT_OFFSET 2
+
+static int ims_pcu_read_ofn_config(struct ims_pcu *pcu, u8 addr, u8 *data)
+{
+ int error;
+ u16 result;
+
+ error = ims_pcu_execute_command(pcu, OFN_GET_CONFIG,
+ , sizeof(addr));
+ if (error)
+ return error;
+
+ result = le16_to_cpup((__le16 *)>cmd_buf[OFN_REG_RESULT_OFFSET]);
+ if ((s16)result < 0)
+ return -EIO;
+
+ /* We only need LSB */
+ *data = pcu->cmd_buf[OFN_REG_RESULT_OFFSET];
+ return 0;
+}
+
+static int ims_pcu_write_ofn_config(struct ims_pcu *pcu, u8 addr, u8 data)
+{
+ u8 buffer[] = { addr, data };
+ int error;
+ u16 result;
+
+ error = ims_pcu_execute_command(pcu, OFN_SET_CONFIG,
+ , sizeof(buffer));
+ if (error)
+ return error;
+
+ result = le16_to_cpup((__le16 *)>cmd_buf[OFN_REG_RESULT_OFFSET]);
+ if ((s16)result < 0)
+ return -EIO;
+
+ return 0;
+}
+
static ssize_t ims_pcu_ofn_reg_data_show(struct device *dev,
struct device_attribute *dattr,
char *buf)
@@ -1236,24 +1312,16 @@ static ssize_t ims_pcu_ofn_reg_data_show(struct device
*dev,
struct usb_interface *intf = to_usb_interface(dev);
struct ims_pcu *pcu = usb_get_intfdata(intf);
int error;
+ u8 data;
mutex_lock(>cmd_mutex);
-
- error = ims_pcu_execute_command(pcu, OFN_GET_CONFIG,
- >ofn_reg_addr,
- sizeof(pcu->ofn_reg_addr));
- if (error >= 0) {
- const s16 result = pcu->cmd_buf[OFN_REG_RESULT_MSB_OFFSET] << 8
|
- pcu->cmd_buf[OFN_REG_RESULT_LSB_OFFSET];
- if (result < 0)
- error = result;
- else
- error = scnprintf(buf, PAGE_SIZE, "%x\n", result);
- }
-
+ error =
Re: [PATCH net-next] r8152: fix the wrong return value
From: Hayes Wang Date: Fri, 3 Jan 2014 11:21:56 +0800 > The return value should be the boolean value, not the error code. > > Signed-off-by: Hayes Wang > Spotted-by: Dan Carpenter Applied, but I agree with others that it's more canonical to have the function return either an error code, or zero for success, rather than a boolean. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Personal Loan
Are you in any kind of financial difficulties? if yes,Contact hydena...@gmail.com now for more details. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [net-next] pci_regs.h: Add PCI bus link speed and width defines
On Fri, 2014-01-03 at 19:30 -0500, David Miller wrote: > From: Bjorn Helgaas > Date: Fri, 3 Jan 2014 17:00:42 -0700 > > > On Fri, Jan 3, 2014 at 4:56 PM, David Miller wrote: > >> From: Bjorn Helgaas > >> Date: Fri, 3 Jan 2014 15:15:57 -0700 > >> > >>> However, I do raise my eyebrows a bit at drivers that poke around in > >>> the PCIe capability. I would prefer to have PCI core interfaces that > >>> handle that instead. But I haven't seen Jeff's changes yet. > >> > >> The changes just read the link status to interpret the speed at which > >> the PCI-E link is running at. > > > > Several drivers want to do that. It'd be nice if somebody abstracted > > that out somehow. Jacob added pcie_get_minimum_link() which is > > similar. But maybe Jeff needs something more in this case. > > > > In any case, it's not a blocker for this patch. > > Ok. > > Jeff, please merge this via the Intel submission process and don't forget > to add Bjorn's ACK. > > Thanks. Ok, will do. What do you want to do with the current series of patches (mainly the ixgbe LER patches) on my tree? I know that there is a thread going on between Joe Perches and Mark, but it sounded like Mark is working on a follow-on patch to address Joe's concerns. Guess I want to know if I leave my tree alone for you to pull or toss the current pull request series and get the i40e series applied. Cheers, Jeff signature.asc Description: This is a digitally signed message part
Re: [PATCH v12 10/18] xen/pvh: Update E820 to work with PVH (v2)
On Thu, 2 Jan 2014 13:41:34 -0500 Konrad Rzeszutek Wilk wrote: > On Thu, Jan 02, 2014 at 04:14:32PM +, David Vrabel wrote: > > On 01/01/14 04:35, Konrad Rzeszutek Wilk wrote: > > > From: Mukesh Rathor > > > > > > In xen_add_extra_mem() we can skip updating P2M as it's managed > > > by Xen. PVH maps the entire IO space, but only RAM pages need > > > to be repopulated. > > > > So this looks minimal but I can't work out what PVH actually needs > > to do here. This code really doesn't need to be made any more > > confusing. > > I gather you prefer Mukesh's original version? I think Konrad thats easier to follow as one can quickly spot the PVH difference... but your call. thanks mukesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v12 03/18] xen/pvh: Early bootup changes in PV code (v2).
On Fri, 3 Jan 2014 12:35:55 -0500 Konrad Rzeszutek Wilk wrote: > On Thu, Jan 02, 2014 at 05:34:38PM -0800, Mukesh Rathor wrote: > > On Thu, 2 Jan 2014 13:32:21 -0500 > > Konrad Rzeszutek Wilk wrote: > > > > > On Thu, Jan 02, 2014 at 03:32:33PM +, David Vrabel wrote: > > > > On 01/01/14 04:35, Konrad Rzeszutek Wilk wrote: > > > > > From: Mukesh Rathor > > > > > > > > > > In the bootup code for PVH we can trap cpuid via vmexit, so > > > > > don't need to use emulated prefix call. We also check for > > > > > vector callback early on, as it is a required feature. PVH > > > > > also runs at default kernel IOPL. > > > > > > > > > > Finally, pure PV settings are moved to a separate function > > > > > that are only called for pure PV, ie, pv with pvmmu. They are > > > > > also #ifdef with CONFIG_XEN_PVMMU. > > > > [...] > > > > > @@ -331,12 +333,15 @@ static void xen_cpuid(unsigned int *ax, > > > > > unsigned int *bx, break; > > > > > } > > > > > > > > > > - asm(XEN_EMULATE_PREFIX "cpuid" > > > > > - : "=a" (*ax), > > > > > - "=b" (*bx), > > > > > - "=c" (*cx), > > > > > - "=d" (*dx) > > > > > - : "0" (*ax), "2" (*cx)); > > > > > + if (xen_pvh_domain()) > > > > > + native_cpuid(ax, bx, cx, dx); > > > > > + else > > > > > + asm(XEN_EMULATE_PREFIX "cpuid" > > > > > + : "=a" (*ax), > > > > > + "=b" (*bx), > > > > > + "=c" (*cx), > > > > > + "=d" (*dx) > > > > > + : "0" (*ax), "2" (*cx)); > > > > > > > > For this one off cpuid call it seems preferrable to me to use > > > > the emulate prefix rather than diverge from PV. > > > > > > This was before the PV cpuid was deemed OK to be used on PVH. > > > Will rip this out to use the same version. > > > > Whats wrong with using native cpuid? That is one of the benefits > > that cpuid can be trapped via vmexit, and also there is talk of > > making PV cpuid trap obsolete in the future. I suggest leaving it > > native. > > I chatted with David, Andrew and Roger on IRC about this. I like the > idea of using xen_cpuid because: > 1) It filters some of the CPUID flags that guests should not use. > There is the 'aperfmperf,'x2apic', 'xsave', and whether the MWAIT_LEAF > should be exposed (so that the ACPI AML code can call the right > initialization code to use the extended C3 states instead of the > legacy IOPORT ones). All of that is in xen_cpuid. > > 2) It works, while we can concentrate on making 1) work in the > hypervisor/toolstack. > > Meaning that the future way would be to use the native cpuid and have > the hypervisor/toolstack setup the proper cpuid. In other words - use > the xen_cpuid as is until that code for filtering is in the > hypervisor. > > > Except that PVH does not work the PV cpuid at all. I get a triple > fault. The instruction it fails at is at the 'XEN_EMULATE_PREFIX'. > > Mukesh, can you point me to the patch where the PV cpuid functionality > is enabled? > > Anyhow, as it stands, I will just use the native cpuid. I am referring to using "cpuid" instruction instead of XEN_EMULATE_PREFIX. cpuid is faster and long term better... there is no benefit using XEN_EMULATE_PREFIX IMO. We can look at removing xen_cpuid() altogether for PVH when/after pvh 32bit work gets done IMO. The triple fault seems to be a new bug... I can create a bug, but for now, with using cpuid instruction, that won't be an issue. thanks mukesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] smsc9420: use named constants for pci_power_t values
From: Julia Lawall Date: Fri, 3 Jan 2014 00:40:31 +0100 > From: Julia Lawall > > The semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) ... > Signed-off-by: Julia Lawall Applied, thanks Julia. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] usb: musb: add support for JZ4740 usb device controller
On Thu, Dec 19, 2013 at 9:42 PM, Apelete Seketeli wrote:
> Add support for Ingenic JZ4740 USB Device Controller through a
> specific musb glue layer.
>
> JZ4740 UDC not being OTG compatible and missing some hardware
> registers, this musb glue layer is written from scratch to be used in
> gadget mode only and take silicon design specifics into account.
>
> Signed-off-by: Apelete Seketeli
> Signed-off-by: Lars-Peter Clausen
> ---
> drivers/usb/musb/Kconfig |8 +-
> drivers/usb/musb/Makefile |1 +
> drivers/usb/musb/jz4740.c | 201
> +
> 3 files changed, 209 insertions(+), 1 deletion(-)
> create mode 100644 drivers/usb/musb/jz4740.c
>
> diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
> index 57dfc0c..14d7e72 100644
> --- a/drivers/usb/musb/Kconfig
> +++ b/drivers/usb/musb/Kconfig
> @@ -93,6 +93,12 @@ config USB_MUSB_BLACKFIN
> config USB_MUSB_UX500
> tristate "Ux500 platforms"
>
> +config USB_MUSB_JZ4740
> + tristate "JZ4740"
> + depends on MACH_JZ4740 || COMPILE_TEST
> + depends on USB_MUSB_GADGET
> + depends on USB_OTG_BLACKLIST_HUB
> +
> endchoice
>
> config USB_MUSB_AM335X_CHILD
> @@ -100,7 +106,7 @@ config USB_MUSB_AM335X_CHILD
>
> choice
> prompt 'MUSB DMA mode'
> - default MUSB_PIO_ONLY if ARCH_MULTIPLATFORM
> + default MUSB_PIO_ONLY if ARCH_MULTIPLATFORM || USB_MUSB_JZ4740
Just out of curiosity, why can't we use DMA?
> default USB_UX500_DMA if USB_MUSB_UX500
> default USB_INVENTRA_DMA if USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN
> default USB_TI_CPPI_DMA if USB_MUSB_DAVINCI
> diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
> index c5ea5c6..ba49501 100644
> --- a/drivers/usb/musb/Makefile
> +++ b/drivers/usb/musb/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_USB_MUSB_DAVINCI)+=
> davinci.o
> obj-$(CONFIG_USB_MUSB_DA8XX) += da8xx.o
> obj-$(CONFIG_USB_MUSB_BLACKFIN)+= blackfin.o
> obj-$(CONFIG_USB_MUSB_UX500) += ux500.o
> +obj-$(CONFIG_USB_MUSB_JZ4740) += jz4740.o
>
>
> obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
> diff --git a/drivers/usb/musb/jz4740.c b/drivers/usb/musb/jz4740.c
> new file mode 100644
> index 000..5f30537
> --- /dev/null
> +++ b/drivers/usb/musb/jz4740.c
> @@ -0,0 +1,201 @@
> +/*
> + * Ingenic JZ4740 "glue layer"
> + *
> + * Copyright (C) 2013, Apelete Seketeli
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "musb_core.h"
> +
> +struct jz4740_glue {
> + struct device *dev;
> + struct platform_device *musb;
> + struct clk *clk;
> +};
> +
> +static irqreturn_t jz4740_musb_interrupt(int irq, void *__hci)
> +{
> + unsigned long flags;
> + irqreturn_t retval = IRQ_NONE;
> + struct musb *musb = __hci;
> +
> + spin_lock_irqsave(>lock, flags);
> +
> + musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB);
> + musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX);
> + musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX);
> +
> + /*
> +* The controller is gadget only, the state of the host mode IRQ bits
> is
> +* undefined. Mask them to make sure that the musb driver core will
> +* never see them set
> +*/
> + musb->int_usb &= MUSB_INTR_SUSPEND | MUSB_INTR_RESUME |
> + MUSB_INTR_RESET | MUSB_INTR_SOF;
> +
> + if (musb->int_usb || musb->int_tx || musb->int_rx)
> + retval = musb_interrupt(musb);
> +
> + spin_unlock_irqrestore(>lock, flags);
> +
> + return retval;
> +}
> +
> +static struct musb_fifo_cfg jz4740_musb_fifo_cfg[] = {
> +{ .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, },
> +{ .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, },
> +{ .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 64, },
> +};
> +
> +static struct musb_hdrc_config jz4740_musb_config = {
> + /* Silicon does not implement USB OTG. */
> + .multipoint = 0,
> + /* Max EPs scanned, driver will decide which EP can be used. */
> + .num_eps= 4,
> + /* RAMbits needed to configure EPs from table */
> + .ram_bits = 9,
> + .fifo_cfg = jz4740_musb_fifo_cfg,
> + .fifo_cfg_size = ARRAY_SIZE(jz4740_musb_fifo_cfg),
> +};
> +
> +static struct musb_hdrc_platform_data
Re: [Xen-devel] [PATCH v11 09/12] xen/pvh: Piggyback on PVHVM XenBus and event channels for PVH.
On Wed, 18 Dec 2013 16:17:39 -0500
Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 18, 2013 at 06:31:43PM +, Stefano Stabellini wrote:
> > On Tue, 17 Dec 2013, Konrad Rzeszutek Wilk wrote:
> > > From: Mukesh Rathor
> > >
> > > PVH is a PV guest with a twist - there are certain things
> > > that work in it like HVM and some like PV. There is
> > > a similar mode - PVHVM where we run in HVM mode with
> > > PV code enabled - and this patch explores that.
> > >
> > > The most notable PV interfaces are the XenBus and event channels.
> > > For PVH, we will use XenBus and event channels.
> > >
> > > For the XenBus mechanism we piggyback on how it is done for
> > > PVHVM guests.
> > >
> > > Ditto for the event channel mechanism - we piggyback on PVHVM -
> > > by setting up a specific vector callback and that
> > > vector ends up calling the event channel mechanism to
> > > dispatch the events as needed.
> > >
> > > This means that from a pvops perspective, we can use
> > > native_irq_ops instead of the Xen PV specific. Albeit in the
> > > future we could support pirq_eoi_map. But that is
> > > a feature request that can be shared with PVHVM.
> > >
> > > Signed-off-by: Mukesh Rathor
> > > Signed-off-by: Konrad Rzeszutek Wilk
> > > ---
> > > arch/x86/xen/enlighten.c | 6 ++
> > > arch/x86/xen/irq.c | 5 -
> > > drivers/xen/events.c | 5 +
> > > drivers/xen/xenbus/xenbus_client.c | 3 ++-
> > > 4 files changed, 17 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
> > > index e420613..7fceb51 100644
> > > --- a/arch/x86/xen/enlighten.c
> > > +++ b/arch/x86/xen/enlighten.c
> > > @@ -1134,6 +1134,8 @@ void xen_setup_shared_info(void)
> > > /* In UP this is as good a place as any to set up shared
> > > info */ xen_setup_vcpu_info_placement();
> > > #endif
> > > + if (xen_pvh_domain())
> > > + return;
> > >
> > > xen_setup_mfn_list_list();
> > > }
> >
> > This is another one of those cases where I think we would benefit
> > from introducing xen_setup_shared_info_pvh instead of adding more
> > ifs here.
>
> Actually this one can be removed.
>
> >
> >
> > > @@ -1146,6 +1148,10 @@ void xen_setup_vcpu_info_placement(void)
> > > for_each_possible_cpu(cpu)
> > > xen_vcpu_setup(cpu);
> > >
> > > + /* PVH always uses native IRQ ops */
> > > + if (xen_pvh_domain())
> > > + return;
> > > +
> > > /* xen_vcpu_setup managed to place the vcpu_info within
> > > the percpu area for all cpus, so make use of it */
> > > if (have_vcpu_info_placement) {
> >
> > Same here?
>
> Hmmm, I wonder if the vcpu info placement could work with PVH.
It should now (after a patch I sent while ago)... the comment implies
that PVH uses native IRQs even case of vcpu info placlement...
perhaps it would be more clear to do:
for_each_possible_cpu(cpu)
xen_vcpu_setup(cpu);
/* PVH always uses native IRQ ops */
if (have_vcpu_info_placement && !xen_pvh_domain) {
pv_irq_ops.save_fl = __PV_IS_CALLEE_SAVE(xen_save_fl_direct);
.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: tulip: delete useless tests on netdev_priv
From: Grant Grundler Date: Thu, 2 Jan 2014 07:57:26 -0800 > On Thu, Jan 2, 2014 at 8:28 AM, Julia Lawall wrote: >> From: Julia Lawall >> >> Netdev_priv performs an addition, not a pointer dereference, so it seems >> quit unlikely that its result would ever be NULL. > > LGTM. > > > >> A semantic patch that makes this change is as follows: >> (http://coccinelle.lip6.fr/) >> >> // >> @@ >> statement S; >> @@ >> >> - if (!netdev_priv(...)) S >> // >> >> Signed-off-by: Julia Lawall > > Acked-by: Grant Grundler Applied, thanks everyone. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [net-next] pci_regs.h: Add PCI bus link speed and width defines
From: Bjorn Helgaas Date: Fri, 3 Jan 2014 17:00:42 -0700 > On Fri, Jan 3, 2014 at 4:56 PM, David Miller wrote: >> From: Bjorn Helgaas >> Date: Fri, 3 Jan 2014 15:15:57 -0700 >> >>> However, I do raise my eyebrows a bit at drivers that poke around in >>> the PCIe capability. I would prefer to have PCI core interfaces that >>> handle that instead. But I haven't seen Jeff's changes yet. >> >> The changes just read the link status to interpret the speed at which >> the PCI-E link is running at. > > Several drivers want to do that. It'd be nice if somebody abstracted > that out somehow. Jacob added pcie_get_minimum_link() which is > similar. But maybe Jeff needs something more in this case. > > In any case, it's not a blocker for this patch. Ok. Jeff, please merge this via the Intel submission process and don't forget to add Bjorn's ACK. 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/
Re: [Xen-devel] [PATCH v11 09/12] xen/pvh: Piggyback on PVHVM XenBus and event channels for PVH.
On Fri, 3 Jan 2014 15:04:27 +
Stefano Stabellini wrote:
> On Tue, 31 Dec 2013, Konrad Rzeszutek Wilk wrote:
> > > > --- a/drivers/xen/xenbus/xenbus_client.c
> > > > +++ b/drivers/xen/xenbus/xenbus_client.c
> > > > @@ -45,6 +45,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #include "xenbus_probe.h"
> > > >
> > > > @@ -743,7 +744,7 @@ static const struct xenbus_ring_ops
> > > > ring_ops_hvm = {
> > > > void __init xenbus_ring_ops_init(void)
> > > > {
> > > > - if (xen_pv_domain())
> > > > + if (xen_pv_domain()
> > > > && !xen_feature(XENFEAT_auto_translated_physmap))
> > >
> > > Can we just change this test to
> > >
> > > if (!xen_feature(XENFEAT_auto_translated_physmap))
> > >
> > > ?
> >
> > No. If we do then the HVM domains (which are also !auto-xlat)
> > will end up using the PV version of ring_ops.
>
> Actually HVM guests have XENFEAT_auto_translated_physmap, so in this
> case they would get _ops_hvm.
Right. Back then I was confused about all the other PV modes, like
shadow, supervisor, ... but looks like they are all obsolete. It could
just be:
if (!xen_feature(XENFEAT_auto_translated_physmap))
ring_ops = _ops_pv;
else
ring_ops = _ops_hvm;
thanks,
Mukesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND] netfilter: remove unused variable
On Sat, Jan 04 2014, Pablo Neira Ayuso wrote: > On Wed, Jan 01, 2014 at 06:27:19AM +0100, Michal Nazarewicz wrote: >> The nfmsg variable is not used (except in sizeof operator which does >> not care about its value) between the first and second time it is >> assigned the value. Furthermore, nlmsg_data has no side effects, so >> the assignment can be safely removed. > > Applied with minor glitch, see below. Thanks. > Thanks. > >> Signed-off-by: Michal Nazarewicz >> Cc: Patrick McHardy >> --- >> net/netfilter/nf_tables_api.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c >> index f93b7d0..9c56adc 100644 >> --- a/net/netfilter/nf_tables_api.c >> +++ b/net/netfilter/nf_tables_api.c >> @@ -2521,7 +2521,6 @@ static int nf_tables_dump_set(struct sk_buff *skb, >> struct netlink_callback *cb) >> u32 portid, seq; >> int event, err; >> >> -nfmsg = nlmsg_data(cb->nlh); >> err = nlmsg_parse(cb->nlh, sizeof(*nfmsg), nla, NFTA_SET_ELEM_LIST_MAX, > > mangled this patch to use sizeof(struct nfgenmsg) instead. That change > is not required from the semantic point of view, of course, but for > readability reasons I think it's better not to refer to a variable > that is not used in that context. Works for me, and err = nlmsg_parse(cb->nlh, sizeof(*nlmsg_data(cb->nlh)), nla, NFTA_SET_ELEM_LIST_MAX, nft_set_elem_list_policy); would probably be an overkill. ;) >> if (err < 0) >> -- >> 1.8.4 -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- signature.asc Description: PGP signature
Re: [PATCH] cxgb4: allow large buffer size to have page size
From: Thadeu Lima de Souza Cascardo
Date: Mon, 23 Dec 2013 15:34:29 -0200
> Since commit 52367a763d8046190754ab43743e42638564a2d1
> ("cxgb4/cxgb4vf: Code cleanup to enable T4 Configuration File support"),
> we have failures like this during cxgb4 probe:
>
> cxgb4 :01:00.4: bad SGE FL page buffer sizes [65536, 65536]
> cxgb4: probe of :01:00.4 failed with error -22
>
> This happens whenever software parameters are used, without a
> configuration file. That happens when the hardware was already
> initialized (after kexec, or after csiostor is loaded).
>
> It happens that these values are acceptable, rendering fl_pg_order equal
> to 0, which is the case of a hard init when the page size is equal or
> larger than 65536.
>
> Accepting fl_large_pg equal to fl_small_pg solves the issue, and
> shouldn't cause any trouble besides a possible performance reduction
> when smaller pages are used. And that can be fixed by a configuration
> file.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo
I've given the cxgb4 maintainers more than a week to get around to reviewing
this, but they haven't.
It's entirely unreasonable for you to have to wait just because they haven't
done so.
So I've applied your patch, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] seqlock: Use raw_ prefix instead of _no_lockdep
On 01/02/2014 04:50 PM, Linus Torvalds wrote: > On Thu, Jan 2, 2014 at 3:11 PM, John Stultz wrote: >> Linus disliked the _no_lockdep() naming, so instead >> use the more-consistent raw_* prefix to the non-lockdep >> enabled seqcount methods. >> >> This also adds raw_ methods for the write operations >> as well, which will be utilized in a following patch. > Ack on this and on 2/2. I'm assuming I'll get them through the -tip > tree, which is where the problem came from. No? It seems Peter or Ingo are still on holiday. Hopefully they will be back on Monday to queue these. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/4] Introduce pci_enable_msi/msix_range() interfaces
On Mon, Dec 30, 2013 at 08:28:12AM +0100, Alexander Gordeev wrote: > This series is against "next" branch in Bjorn's repo: > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git > > Changes from v4 to v5: > - pci_auto_enable_msi* functions renamed to pci_enable_msi* ones; > - pci_enable_msi_range() and pci_enable_msix_range() are the only > basic interfaces left to enable MSI/MSI-X operation; > - pci_enable_msi(), pci_enable_msi_block() and pci_enable_msix() old > interfaces deprecated in favour of pci_enable_msi/msix_range() ones; > description of the old interfaces is removed from the documentation; > - pci_get_msi_vec_count() renamed to pci_msi_vec_count() and > pci_get_msix_vec_count() renamed to pci_msix_vec_count(); > > Changes from v3 to v4: > - pcim_enable_msi* functions renamed to pci_auto_enable_msi* ones; > - PowerPC patches dropped; > - pci_get_msi_cap() renamed to pci_get_msi_vec_count() and > pci_msix_table_size() renamed to pci_get_msix_vec_count(); > > Changes from v2 to v3: > - new public interfaces commented in drivers/pci/msi.c; > - patch "Make quota traversing and requesting race-safe" explained; > - pci_enable_msi/msix() 'nvec' arg type changed from 'unsigned int' to > 'int'; > - pcim_enable_msi*() arg 'nvec' renamed to 'maxvec' when upper limit passed; > - pcim_enable_msi*(..., maxvec, minvec) arg order swapped to minvec, maxvec; > - "PCI: Fail MSI/MSI-X initialization if device is not in PCI_D0" commit > 869a161 and "PCI/MSI: Factor out pci_get_msi_cap() interface" patch > conflicts resolved; > > This update introduces pci_enable_msi_range() function which > supersedes pci_enable_msi() and pci_enable_msi_block() > interfaces for MSI and pci_enable_msi_range() function which > supersedes pci_enable_msix() interface for MSI-X interrupts. > > The plan is to convert all drivers to the new interfaces and > then remove existing pci_enable_msi(), pci_enable_msi_block() > and pci_enable_msix() functions. > > The newly introduced functions return either a negative error > code or a number of successfully allocated MSI/MSI-X interrupts. > > Unlike the old interfaces where the "third" state indicates > a possible number of MSI interrupts that could have been > allocated, the new interfaces allow device drivers not to deal > with tri-state return values and hide fallback logic behind > the implementation. > > As result, device drivers are expected to have more clearer > and straight code. > > The tree could be found in "pci-next-msi-v5" branch in repo: > https://github.com/a-gordeev/linux.git > > Alexander Gordeev (4): > PCI/MSI: Factor out pci_msi_vec_count() interface > PCI/MSI: Get rid of pci_enable_msi_block_auto() interface > PCI/MSI: Introduce pci_msix_vec_count() interface > PCI/MSI: Introduce pci_enable_msi/msix_range() interfaces I applied all four of these to my pci/msi branch for v3.14. Thanks a lot for all your work on this! I'm looking forward to the driver conversions and bug fixes :) Bjorn > Documentation/PCI/MSI-HOWTO.txt | 308 > ++- > drivers/ata/ahci.c | 56 +--- > drivers/pci/msi.c | 150 +++- > drivers/pci/pcie/portdrv_core.c |7 +- > include/linux/pci.h | 27 +++- > 5 files changed, 385 insertions(+), 163 deletions(-) > > -- > 1.7.7.6 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] Deferrable timers support for timerfd API
On 01/03/2014 09:45 AM, Alexey Perevalov wrote: > On 01/03/2014 03:17 AM, John Stultz wrote: >> On 01/02/2014 10:30 AM, Alexey Perevalov wrote: >>> This version introduces new clockid (CLOCK_DEFERRABLE) , for >>> timerfd_create, instead of >>> new flag (TFD_TIMER_DEFERRABLE) for timerfd_settime introduced in >>> previous version. >> So why did you make this change? >> >> thanks >> -john >> >> > > I looked at alarm timers and found approach of making timer behavior > persistent per file descriptor is better than > changeable by timerfd_settime. I think "end user wake up from suspend" > and "don't wake up in idle" is the same thing on the same abstraction > level. > > Yes Anton's previous patches worked with CLOCK_MONOTONIC only and I > didn't intend to use it with CLOCK_REALTIME, cause it's hard to me to > find such use case. > Another way - it's stay as was Anton's patch, I mean as flag for the > timerfd_settime, but in original patch set both hrtimer and deferrable > timers initialized in timerfd_create, I think it's not needed. Also > ability to change timer behavior looks not good if you couldn't change > alarm timer behavior, not unified API. So while the alarm timers are a reasonable precedent, I think they were introduced prior to the timerfd interface, so it seemed at the time having new clockids for the functionality was required to work with the existing syscalls that use the clockid (Though in retrospect, I question if it would have been better to use timer flags to introduce the alarm functionality rather then introducing it via a clockid, as it would simplify the clockid definitions). Now that we have the timerfd interface, and if this functionality is really limited to the timerfds, then we may want to consider what might be, at least to me, the cleaner approach of using the flag. Either way, I'd like to make sure we have a sound rational. My worry is that deferrable timers would be desired on more then just CLOCK_MONOTONIC, so we could quite likely end up with quite a few new clockids (ie: CLOCK_BOOTTIME_DEFERRED, CLOCK_TAI_DEFERRED, CLOCK_REALTIME_DEFERRED). > > If I'm right, only high resolution timer could be REALTIME, and there > is no deferrable behavior for hrtimer only for timer_list. > > I'm not sure I understood this part. Could you explain further? thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/mlock: fix BUG_ON unlocked page for nolinear VMAs
On Fri, Jan 3, 2014 at 3:36 PM, Vlastimil Babka wrote: > > I'm for going with the removal of BUG_ON. The TestSetPageMlocked should > provide enough > race protection. Maybe. But dammit, that's subtle, and I don't think you're even right. It basically depends on mlock_vma_page() and munlock_vma_page() being able to run CONCURRENTLY on the same page. In particular, you could have a mlock_vma_page() set the bit on one CPU, and munlock_vma_page() immediately clearing it on another, and then the rest of those functions could run with a totally arbitrary interleaving when working with the exact same page. They both do basically if (!isolate_lru_page(page)) putback_lru_page(page); but one or the other would randomly win the race (it's internally protected by the lru lock), and *if* the munlock_vma_page() wins it, it would also do try_to_munlock(page); but if mlock_vma_page() wins it, that wouldn't happen. That looks entirely broken - you end up with the PageMlocked bit clear, but try_to_munlock() was never called on that page, because mlock_vma_page() got to the page isolation before the "subsequent" munlock_vma_page(). And this is very much what the page lock serialization would prevent. So no, the PageMlocked in *no* way gives serialization. It's an atomic bit op, yes, but that only "serializes" in one direction, not when you can have a mix of bit setting and clearing. So quite frankly, I think you're wrong. The BUG_ON() is correct, or at least enforces some kind of ordering. And try_to_unmap_cluster() is just broken in calling that without the page being locked. That's my opinion. There may be some *other* reason why it all happens to work, but no, "TestSetPageMlocked should provide enough race protection" is simply not true, and even if it were, it's way too subtle and odd to be a good rule. So I really object to just removing the BUG_ON(). Not with a *lot* more explanation as to why these kinds of issues wouldn't matter. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] efi: Fix krealloc defect
krealloc should use a temporary pointer for allocations
and check the temporary pointer returned against NULL too.
Signed-off-by: Joe Perches
cc: Matthew Garrett
---
arch/x86/platform/efi/efi.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index cceb813..ef7b7b4 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -798,6 +798,8 @@ void __init efi_enter_virtual_mode(void)
}
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+ void *new_memmap2;
+
md = p;
if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
#ifdef CONFIG_X86_64
@@ -834,9 +836,13 @@ void __init efi_enter_virtual_mode(void)
systab += md->virt_addr - md->phys_addr;
efi.systab = (efi_system_table_t *) (unsigned long)
systab;
}
- new_memmap = krealloc(new_memmap,
- (count + 1) * memmap.desc_size,
- GFP_KERNEL);
+ new_memmap2 = krealloc(new_memmap,
+ (count + 1) * memmap.desc_size,
+ GFP_KERNEL);
+ if (!new_memmap2)
+ continue;
+
+ new_memmap = new_memmap2;
memcpy(new_memmap + (count * memmap.desc_size), md,
memmap.desc_size);
count++;
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] efi: Fix krealloc defect and misc neatening
Joe Perches (2): efi: Fix krealloc defect efi: style neatening arch/x86/platform/efi/efi.c | 42 ++ 1 file changed, 22 insertions(+), 20 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] efi: style neatening
Coalesce formats and remove spaces before tabs.
Move __initdata after the variable declaration.
Signed-off-by: Joe Perches
---
arch/x86/platform/efi/efi.c | 30 +-
1 file changed, 13 insertions(+), 17 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index ef7b7b4..69c6133 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -67,7 +67,7 @@ static efi_system_table_t efi_systab __initdata;
unsigned long x86_efi_facility;
-static __initdata efi_config_table_type_t arch_tables[] = {
+static efi_config_table_type_t arch_tables[] __initdata = {
#ifdef CONFIG_X86_UV
{UV_SYSTEM_TABLE_GUID, "UVsystab", _systab},
#endif
@@ -83,7 +83,7 @@ int efi_enabled(int facility)
}
EXPORT_SYMBOL(efi_enabled);
-static bool __initdata disable_runtime = false;
+static bool disable_runtime __initdata = false;
static int __init setup_noefi(char *arg)
{
disable_runtime = true;
@@ -271,9 +271,9 @@ static efi_status_t __init phys_efi_get_time(efi_time_t *tm,
int efi_set_rtc_mmss(const struct timespec *now)
{
unsigned long nowtime = now->tv_sec;
- efi_status_tstatus;
- efi_time_t eft;
- efi_time_cap_t cap;
+ efi_status_tstatus;
+ efi_time_t eft;
+ efi_time_cap_t cap;
struct rtc_time tm;
status = efi.get_time(, );
@@ -291,9 +291,8 @@ int efi_set_rtc_mmss(const struct timespec *now)
eft.second = tm.tm_sec;
eft.nanosecond = 0;
} else {
- printk(KERN_ERR
- "%s: Invalid EFI RTC value: write of %lx to EFI RTC
failed\n",
- __FUNCTION__, nowtime);
+ pr_err("%s: Invalid EFI RTC value: write of %lx to EFI RTC
failed\n",
+ __func__, nowtime);
return -1;
}
@@ -409,8 +408,7 @@ static void __init print_efi_memmap(void)
p < memmap.map_end;
p += memmap.desc_size, i++) {
md = p;
- pr_info("mem%02u: type=%u, attr=0x%llx, "
- "range=[0x%016llx-0x%016llx) (%lluMB)\n",
+ pr_info("mem%02u: type=%u, attr=0x%llx,
range=[0x%016llx-0x%016llx) (%lluMB)\n",
i, md->type, md->attribute, md->phys_addr,
md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT),
(md->num_pages >> (20 - EFI_PAGE_SHIFT)));
@@ -442,9 +440,8 @@ void __init efi_reserve_boot_services(void)
memblock_is_region_reserved(start, size)) {
/* Could not reserve, skip it */
md->num_pages = 0;
- memblock_dbg("Could not reserve boot range "
- "[0x%010llx-0x%010llx]\n",
- start, start+size-1);
+ memblock_dbg("Could not reserve boot range
[0x%010llx-0x%010llx]\n",
+start, start+size-1);
} else
memblock_reserve(start, size);
}
@@ -566,8 +563,7 @@ static int __init efi_systab_init(void *phys)
return -EINVAL;
}
if ((efi.systab->hdr.revision >> 16) == 0)
- pr_err("Warning: System table version "
- "%d.%02d, expected 1.00 or greater!\n",
+ pr_err("Warning: System table version %d.%02d, expected 1.00 or
greater!\n",
efi.systab->hdr.revision >> 16,
efi.systab->hdr.revision & 0x);
@@ -857,8 +853,8 @@ void __init efi_enter_virtual_mode(void)
(efi_memory_desc_t *)__pa(new_memmap));
if (status != EFI_SUCCESS) {
- pr_alert("Unable to switch EFI into virtual mode "
-"(status=%lx)!\n", status);
+ pr_alert("Unable to switch EFI into virtual mode
(status=%lx)!\n",
+status);
panic("EFI call to SetVirtualAddressMap() failed!");
}
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] regulator: anatop-regulator: Fix the error handling on probe
On Tue, Dec 24, 2013 at 01:03:57PM +, Mark Brown wrote: > On Mon, Dec 23, 2013 at 12:44:40PM -0200, Fabio Estevam wrote: > > From: Fabio Estevam > > > > Currently when of_get_parent() or syscon_node_to_regmap() fail > > 'kfree(sreg->name)' is not called, which is incorrect. > > Applied both, thanks. Sorry for being too later, but why are we making copy to begin with? It is not like DT data will disappear later on. Thanks. -- 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: [net-next] pci_regs.h: Add PCI bus link speed and width defines
On Fri, Jan 3, 2014 at 4:56 PM, David Miller wrote: > From: Bjorn Helgaas > Date: Fri, 3 Jan 2014 15:15:57 -0700 > >> However, I do raise my eyebrows a bit at drivers that poke around in >> the PCIe capability. I would prefer to have PCI core interfaces that >> handle that instead. But I haven't seen Jeff's changes yet. > > The changes just read the link status to interpret the speed at which > the PCI-E link is running at. Several drivers want to do that. It'd be nice if somebody abstracted that out somehow. Jacob added pcie_get_minimum_link() which is similar. But maybe Jeff needs something more in this case. In any case, it's not a blocker for this patch. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [net-next] pci_regs.h: Add PCI bus link speed and width defines
From: Bjorn Helgaas Date: Fri, 3 Jan 2014 15:15:57 -0700 > However, I do raise my eyebrows a bit at drivers that poke around in > the PCIe capability. I would prefer to have PCI core interfaces that > handle that instead. But I haven't seen Jeff's changes yet. The changes just read the link status to interpret the speed at which the PCI-E link is running at. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/mlock: fix BUG_ON unlocked page for nolinear VMAs
On Sat, 04 Jan 2014 00:36:18 +0100 Vlastimil Babka wrote: > On 01/03/2014 09:52 PM, Linus Torvalds wrote: > > On Fri, Jan 3, 2014 at 12:17 PM, Sasha Levin wrote: > >> > >> Ping? This BUG() is triggerable in 3.13-rc6 right now. > > > > So Andrew suggested just removing the BUG_ON(), but it's been there > > for a *long* time. > > Yes, Andrew also merged this patch for that: > > http://ozlabs.org/~akpm/mmots/broken-out/mm-remove-bug_on-from-mlock_vma_page.patch > > But there wasn't enough confidence in the fix to sent it to you yet, I guess. > > The related thread: http://www.spinics.net/lists/linux-mm/msg66972.html Yes, I'd taken the cowardly approach of scheduling it for 3.14, with a 3.13.x backport. Nobody answered my question! Is this a new bug or is it a five-year-old bug which we only just discovered? I guess it doesn't matter much - we should fix it in 3.13. I'll include it in the next for-3.13 batch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/cpu] x86, cpu: Detect more TLB configuration
Commit-ID: dd360393f4d948eb518372316e52101cf3b44212
Gitweb: http://git.kernel.org/tip/dd360393f4d948eb518372316e52101cf3b44212
Author: Kirill A. Shutemov
AuthorDate: Mon, 23 Dec 2013 14:16:58 +0200
Committer: H. Peter Anvin
CommitDate: Fri, 3 Jan 2014 14:35:42 -0800
x86, cpu: Detect more TLB configuration
The Intel Software Developer’s Manual covers few more TLB
configurations exposed as CPUID 2 descriptors:
61H Instruction TLB: 4 KByte pages, fully associative, 48 entries
63H Data TLB: 1 GByte pages, 4-way set associative, 4 entries
76H Instruction TLB: 2M/4M pages, fully associative, 8 entries
B5H Instruction TLB: 4KByte pages, 8-way set associative, 64 entries
B6H Instruction TLB: 4KByte pages, 8-way set associative, 128 entries
C1H Shared 2nd-Level TLB: 4 KByte/2MByte pages, 8-way associative, 1024 entries
C2H DTLB DTLB: 2 MByte/$MByte pages, 4-way associative, 16 entries
Let's detect them as well.
Signed-off-by: Kirill A. Shutemov
Link:
http://lkml.kernel.org/r/1387801018-14499-1-git-send-email-kirill.shute...@linux.intel.com
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/processor.h | 1 +
arch/x86/kernel/cpu/common.c | 7 ---
arch/x86/kernel/cpu/intel.c | 26 ++
3 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 7b034a4..1dd6260 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -72,6 +72,7 @@ extern u16 __read_mostly tlb_lli_4m[NR_INFO];
extern u16 __read_mostly tlb_lld_4k[NR_INFO];
extern u16 __read_mostly tlb_lld_2m[NR_INFO];
extern u16 __read_mostly tlb_lld_4m[NR_INFO];
+extern u16 __read_mostly tlb_lld_1g[NR_INFO];
extern s8 __read_mostly tlb_flushall_shift;
/*
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 6abc172..24b6fd1 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -472,6 +472,7 @@ u16 __read_mostly tlb_lli_4m[NR_INFO];
u16 __read_mostly tlb_lld_4k[NR_INFO];
u16 __read_mostly tlb_lld_2m[NR_INFO];
u16 __read_mostly tlb_lld_4m[NR_INFO];
+u16 __read_mostly tlb_lld_1g[NR_INFO];
/*
* tlb_flushall_shift shows the balance point in replacing cr3 write
@@ -486,13 +487,13 @@ void cpu_detect_tlb(struct cpuinfo_x86 *c)
if (this_cpu->c_detect_tlb)
this_cpu->c_detect_tlb(c);
- printk(KERN_INFO "Last level iTLB entries: 4KB %d, 2MB %d, 4MB %d\n" \
- "Last level dTLB entries: 4KB %d, 2MB %d, 4MB %d\n" \
+ printk(KERN_INFO "Last level iTLB entries: 4KB %d, 2MB %d, 4MB %d\n"
+ "Last level dTLB entries: 4KB %d, 2MB %d, 4MB %d, 1GB %d\n"
"tlb_flushall_shift: %d\n",
tlb_lli_4k[ENTRIES], tlb_lli_2m[ENTRIES],
tlb_lli_4m[ENTRIES], tlb_lld_4k[ENTRIES],
tlb_lld_2m[ENTRIES], tlb_lld_4m[ENTRIES],
- tlb_flushall_shift);
+ tlb_lld_1g[ENTRIES], tlb_flushall_shift);
}
void detect_ht(struct cpuinfo_x86 *c)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index ea04b34..5eb7ea5 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -506,6 +506,7 @@ static unsigned int intel_size_cache(struct cpuinfo_x86 *c,
unsigned int size)
#define TLB_DATA0_2M_4M0x23
#define STLB_4K0x41
+#define STLB_4K_2M 0x42
static const struct _tlb_table intel_tlb_table[] = {
{ 0x01, TLB_INST_4K,32, " TLB_INST 4 KByte pages, 4-way
set associative" },
@@ -526,13 +527,20 @@ static const struct _tlb_table intel_tlb_table[] = {
{ 0x5b, TLB_DATA_4K_4M, 64, " TLB_DATA 4 KByte and 4 MByte
pages" },
{ 0x5c, TLB_DATA_4K_4M, 128," TLB_DATA 4 KByte and 4 MByte
pages" },
{ 0x5d, TLB_DATA_4K_4M, 256," TLB_DATA 4 KByte and 4 MByte
pages" },
+ { 0x61, TLB_INST_4K,48, " TLB_INST 4 KByte pages, full
associative" },
+ { 0x63, TLB_DATA_1G,4, " TLB_DATA 1 GByte pages, 4-way
set associative" },
+ { 0x76, TLB_INST_2M_4M, 8, " TLB_INST 2-MByte or 4-MByte
pages, fully associative" },
{ 0xb0, TLB_INST_4K,128," TLB_INST 4 KByte pages, 4-way
set associative" },
{ 0xb1, TLB_INST_2M_4M, 4, " TLB_INST 2M pages, 4-way, 8
entries or 4M pages, 4-way entries" },
{ 0xb2, TLB_INST_4K,64, " TLB_INST 4KByte pages, 4-way
set associative" },
{ 0xb3, TLB_DATA_4K,128," TLB_DATA 4 KByte pages, 4-way
set associative" },
{ 0xb4, TLB_DATA_4K,256," TLB_DATA 4 KByte pages, 4-way
associative" },
+ { 0xb5, TLB_INST_4K,64, " TLB_INST 4 KByte pages, 8-way
set ssociative" },
+ { 0xb6, TLB_INST_4K,128," TLB_INST 4 KByte pages, 8-way
set ssociative" },
{ 0xba,
Re: [PATCH] ACPI/Battery: Add a _BIX quirk for NEC LZ750/LS
On Fri, Jan 03, 2014 at 05:01:11PM -0200, Leandro Dorileo wrote:
> On Thu, Jan 02, 2014 at 03:37:57PM +0800, Lan Tianyu wrote:
> > The aml method _BIX of NEC LZ750/LS returns a broken package which
> > skip the first member "Revision" according ACPI 5.0 spec Table 10-234.
> >
> > This patch is to add a quirk for this machine to skip member "Revision"
> > during parsing _BIX returned package.
> >
> > Reported-and-tested-by: Francisco Castro
> > Reference: https://bugzilla.kernel.org/show_bug.cgi?id=67351
> > Cc: 3.8+
> > Signed-off-by: Lan Tianyu
> > ---
> > drivers/acpi/battery.c | 28 +++-
> > 1 file changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
> > index fbf1ace..3d64a87 100644
> > --- a/drivers/acpi/battery.c
> > +++ b/drivers/acpi/battery.c
> > @@ -62,6 +62,7 @@ MODULE_AUTHOR("Alexey Starikovskiy
> > ");
> > MODULE_DESCRIPTION("ACPI Battery Driver");
> > MODULE_LICENSE("GPL");
> >
> > +static int battery_bix_broken_package;
> > static unsigned int cache_time = 1000;
> > module_param(cache_time, uint, 0644);
> > MODULE_PARM_DESC(cache_time, "cache time in milliseconds");
> > @@ -416,7 +417,12 @@ static int acpi_battery_get_info(struct acpi_battery
> > *battery)
> > ACPI_EXCEPTION((AE_INFO, status, "Evaluating %s", name));
> > return -ENODEV;
> > }
> > - if (test_bit(ACPI_BATTERY_XINFO_PRESENT, >flags))
> > +
> > + if (battery_bix_broken_package)
> > + result = extract_package(battery, buffer.pointer,
> > + extended_info_offsets + 1,
> > + ARRAY_SIZE(extended_info_offsets) - 1);
> > + else if (test_bit(ACPI_BATTERY_XINFO_PRESENT, >flags))
> > result = extract_package(battery, buffer.pointer,
> > extended_info_offsets,
> > ARRAY_SIZE(extended_info_offsets));
> > @@ -754,6 +760,24 @@ static int battery_notify(struct notifier_block *nb,
> > return 0;
> > }
> >
> > +static int battery_bix_package_quirk(const struct dmi_system_id *id)
> > +{
> > + battery_bix_broken_package = 1;
> > + return 0;
> > +}
> > +
>
>
> Do you really need this callback? Why don't you just do:
>
> if (dmi_check_system(bat_dmi_table))
>battery_bix_broken_package = 1;
>
Callback would be useful if we were to print the DMI data of the match,
otherwise not so much.
--
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: [PATCHv8 RFC] pwm: Add Freescale FTM PWM driver support
On Fri, Jan 03, 2014 at 09:16:06AM +, li.xi...@freescale.com wrote:
> Hi Dmitry,
>
> > Subject: Re: [PATCHv8 RFC] pwm: Add Freescale FTM PWM driver support
> >
> > Hi Xiubo,
> >
> > On Fri, Jan 03, 2014 at 01:24:21PM +0800, Xiubo Li wrote:
> > > +
> > > +static inline int fsl_pwm_calculate_default_ps(struct fsl_pwm_chip *fpc,
> > > +enum fsl_pwm_clk index)
> > > +{
> >
> > Why do you declare this (and other module-local) function as inline?
> > It is usually better let compiler decide if given function should be
> > inlined or not.
> >
>
> Could the compiler know when the given function should be inlined by
> not declare it?
Yes.
> And when will be inlined ?
When it makes sense to do so from compiler's point of view: i.e. it is
smallish or with single call site and there are enough registers, etc,
etc.
Thanks.
--
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 v4] cpufreq: Fix timer/workqueue corruption by protecting reading governor_enabled
On Fri, Jan 03, 2014 at 03:40:16PM +0530, Viresh Kumar wrote: > On 3 January 2014 14:47, wrote: > > From: Jane Li > > > > When a CPU is hot removed we'll cancel all the delayed work items via > > gov_cancel_work(). Sometimes the delayed work function determines that > > it should adjust the delay for all other CPUs that the policy is > > managing. If this scenario occurs, the canceling CPU will cancel its own > > work but queue up the other CPUs works to run. > > > > Commit 3617f2(cpufreq: Fix timer/workqueue corruption due to double > > queueing) has tried to fix this, but reading governor_enabled is not > > protected by cpufreq_governor_lock. Even though od_dbs_timer() checks > > governor_enabled before gov_queue_work(), this scenario may occur. For > > example: > > > > CPU0CPU1 > > > > cpu_down() > > ... > > __cpufreq_remove_dev() od_dbs_timer() > >__cpufreq_governor() policy->governor_enabled > > policy->governor_enabled = false; > > cpufreq_governor_dbs() > > case CPUFREQ_GOV_STOP: > > gov_cancel_work(dbs_data, policy); > >cpu0 work is canceled > > timer is canceled > > cpu1 work is canceled > > > > gov_queue_work(*, *, true); > >cpu0 work queued > >cpu1 work queued > >cpu2 work queued > >... > > cpu1 work is canceled > > cpu2 work is canceled > > ... > > > > At the end of the GOV_STOP case cpu0 still has a work queued to > > run although the code is expecting all of the works to be > > canceled. __cpufreq_remove_dev() will then proceed to > > re-initialize all the other CPUs works except for the CPU that is > > going down. The CPUFREQ_GOV_START case in cpufreq_governor_dbs() > > will trample over the queued work and debugobjects will spit out > > a warning: > > > > WARNING: at lib/debugobjects.c:260 debug_print_object+0x94/0xbc() > > ODEBUG: init active (active state 0) object type: timer_list hint: > > delayed_work_timer_fn+0x0/0x14 > > Modules linked in: > > CPU: 1 PID: 1205 Comm: sh Tainted: GW3.10.0 #200 > > [] (unwind_backtrace+0x0/0xf8) from [] > > (show_stack+0x10/0x14) > > [] (show_stack+0x10/0x14) from [] > > (warn_slowpath_common+0x4c/0x68) > > [] (warn_slowpath_common+0x4c/0x68) from [] > > (warn_slowpath_fmt+0x30/0x40) > > [] (warn_slowpath_fmt+0x30/0x40) from [] > > (debug_print_object+0x94/0xbc) > > [] (debug_print_object+0x94/0xbc) from [] > > (__debug_object_init+0xc8/0x3c0) > > [] (__debug_object_init+0xc8/0x3c0) from [] > > (init_timer_key+0x20/0x104) > > [] (init_timer_key+0x20/0x104) from [] > > (cpufreq_governor_dbs+0x1dc/0x68c) > > [] (cpufreq_governor_dbs+0x1dc/0x68c) from [] > > (__cpufreq_governor+0x80/0x1b0) > > [] (__cpufreq_governor+0x80/0x1b0) from [] > > (__cpufreq_remove_dev.isra.12+0x22c/0x380) > > [] (__cpufreq_remove_dev.isra.12+0x22c/0x380) from [] > > (cpufreq_cpu_callback+0x48/0x5c) > > [] (cpufreq_cpu_callback+0x48/0x5c) from [] > > (notifier_call_chain+0x44/0x84) > > [] (notifier_call_chain+0x44/0x84) from [] > > (__cpu_notify+0x2c/0x48) > > [] (__cpu_notify+0x2c/0x48) from [] > > (_cpu_down+0x80/0x258) > > [] (_cpu_down+0x80/0x258) from [] (cpu_down+0x28/0x3c) > > [] (cpu_down+0x28/0x3c) from [] (store_online+0x30/0x74) > > [] (store_online+0x30/0x74) from [] > > (dev_attr_store+0x18/0x24) > > [] (dev_attr_store+0x18/0x24) from [] > > (sysfs_write_file+0x100/0x180) > > [] (sysfs_write_file+0x100/0x180) from [] > > (vfs_write+0xbc/0x184) > > [] (vfs_write+0xbc/0x184) from [] (SyS_write+0x40/0x68) > > [] (SyS_write+0x40/0x68) from [] > > (ret_fast_syscall+0x0/0x48) > > > > In gov_queue_work(), lock cpufreq_governor_lock before gov_queue_work, > > and unlock it after __gov_queue_work(). In this way, governor_enabled > > is guaranteed not changed in gov_queue_work(). > > > > Signed-off-by: Jane Li > > --- > > drivers/cpufreq/cpufreq.c |2 +- > > drivers/cpufreq/cpufreq_governor.c |6 +- > > drivers/cpufreq/cpufreq_governor.h |2 ++ > > 3 files changed, 8 insertions(+), 2 deletions(-) > > Acked-by: Viresh Kumar Reviewed-by: Dmitry Torokhov -- 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] mm/mlock: fix BUG_ON unlocked page for nolinear VMAs
On 01/03/2014 09:52 PM, Linus Torvalds wrote: > On Fri, Jan 3, 2014 at 12:17 PM, Sasha Levin wrote: >> >> Ping? This BUG() is triggerable in 3.13-rc6 right now. > > So Andrew suggested just removing the BUG_ON(), but it's been there > for a *long* time. Yes, Andrew also merged this patch for that: http://ozlabs.org/~akpm/mmots/broken-out/mm-remove-bug_on-from-mlock_vma_page.patch But there wasn't enough confidence in the fix to sent it to you yet, I guess. The related thread: http://www.spinics.net/lists/linux-mm/msg66972.html > And I detest the patch that was sent out that said "Should I check?" > > Maybe we should just remove that mlock_vma_page() thing instead in You mean that it it's already undeterministic because it can be already skipped when mmap_sem can't be acquired for read? I think the assumption for this case is that mmap_sem is already held for write which means VM_LOCKED is unset anyway (per comments at try_to_unmap_file(), which calls try_to_unmap_cluster()). I'm however not sure how it is protected from somebody else holding the semaphore... > try_to_unmap_cluster()? Or maybe actually lock the page around calling > it? check_page is already locked, see try_to_munlock() which calls try_to_unmap_file(). So this might smell of potential deadlock? I'm for going with the removal of BUG_ON. The TestSetPageMlocked should provide enough race protection. > Linus > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
On Fri, Jan 03, 2014 at 01:21:18PM -0800, walt wrote: > I'm so sorry Sarah, that was another mistake. The mistake is so stupid I'm > not > going to publish it here :( > > Once I finally ran the kernel with debugging actually compiled in, dmesg > contains > xhci debugging messages. Wow :) > > It's a big file so I zipped and attached it, which I hope is acceptable in > lkml. Yep, that's fine. Sticking it in pastebin (or up on your server) is also fine, if it gets really big. > BTW, this dmesg is from a kernel with sg_tablesize = 31, which as I said > before > doesn't fix the problem. The cp stopped around 7GB just as before. > > Sorry for the noise... No worries! :) With the dmesg, I can finally see what happened: [ 188.703059] xhci_hcd :03:00.0: Cancel URB 8800b7d2e0c0, dev 1, ep 0x2, starting at offset 0xbb7b9000 [ 188.703072] xhci_hcd :03:00.0: // Ding dong! [ 193.711022] xhci_hcd :03:00.0: xHCI host not responding to stop endpoint command. [ 193.711029] xhci_hcd :03:00.0: Assuming host is dying, halting host. [ 193.711046] xhci_hcd :03:00.0: // Halt the HC [ 193.711060] xhci_hcd :03:00.0: Killing URBs for slot ID 1, ep index 0 [ 193.711066] xhci_hcd :03:00.0: Killing URBs for slot ID 1, ep index 2 [ 193.711078] xhci_hcd :03:00.0: Killing URBs for slot ID 1, ep index 3 [ 193.711096] xhci_hcd :03:00.0: Calling usb_hc_died() [ 193.711103] xhci_hcd :03:00.0: HC died; cleaning up [ 193.76] xhci_hcd :03:00.0: xHCI host controller is dead. It seems that the xHCI driver tried to stop the endpoint ring in order to cancel a SCSI transfer, and the driver never got a response for that. The offset is rather suspicious (0xbb7b9000), and it probably means the driver attempted to cancel a transfer that had been moved to the beginning of the ring segment, with no-op TRBs before the link TRB. I suspect David's patch triggers a bug in the command cancellation code. There's also the unlikely possibility that the no-op TRBs did indeed cause the host to hang. Either way, I'll have to look into it. I'll let you know when I have some diagnostic patches ready. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/boot: use .code16 instead of .code16gcc
On 01/03/2014 03:12 PM, David Woodhouse wrote: > On Fri, 2014-01-03 at 14:34 -0800, H. Peter Anvin wrote: >> >> Nice. I would really like a gcc option "-m16" even if all it did was >> emit .code16gcc first in any assembly file > > Is there a PR for that specific request? > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672 Just filed it. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/boot: use .code16 instead of .code16gcc
On Fri, 2014-01-03 at 14:34 -0800, H. Peter Anvin wrote: > > Nice. I would really like a gcc option "-m16" even if all it did was > emit .code16gcc first in any assembly file Is there a PR for that specific request? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: Sanitize FPU-state when switching tasks (was sanitize CPU-state when switching from virtual-8086 mode to other task)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 H. Peter Anvin wrote: > On 12/31/2013 11:21 AM, Konrad Rzeszutek Wilk wrote: >> >> So, I am wondering if this is related to " x86/fpu: CR0.TS should >> be set before trap into PV guest's #NM exception handle" which >> does have a similar pattern - you do enough of the task switches >> and the FPU is screwed. >> >> See >> http://mid.gmane.org/1383720072-6242-1-git-send-email-gaoyang@taobao.com >> >> >> (I thought there was a thread about this on LKML too but I can't >> find it). > > That would be a bug in Xen, so I guess you're surmising a similar > bug in VirtualBox? Not sure on that yet, but the whole thing is getting even more funnier, the longer I can play with it. Here is some more information from my latest tests: * Although first observed with virtual-8086 mode, the bug is not specific to virtual-8086 mode, it can be triggered with normal x86 userspace code also, even with better reproducibility. * It seems, that when changing the FPU control word with "fstcw" just before exit of the process, then another process could suffer when doing __do_switch * By having two rogue processes writing data to each other via a socket, time and code-position of OOPS can be influenced. * When deactivating mmap_min_addr, the NULL-dereferences during task-switch are exploitable, but I did not get full ring-0 code execution yet, putting EIP to the NULL-seg seem to have failed, perhaps wrong RPL? Hoping to fix that during next days. You can find the new improved test code at [1]. hd [1] http://www.halfdog.net/Security/2013/Vm86SyscallTaskSwitchKernelPanic/FpuStateTaskSwitchOops.c - -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlLHQrwACgkQxFmThv7tq+4C+wCfZ0a0LhaJqI7DW78ZFGbnzIyu 6H8AnROrUklhvdbAGV5+7/ELEzPikU7T =jKjH -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RESEND] netfilter: remove unused variable
On Wed, Jan 01, 2014 at 06:27:19AM +0100, Michal Nazarewicz wrote: > The nfmsg variable is not used (except in sizeof operator which does > not care about its value) between the first and second time it is > assigned the value. Furthermore, nlmsg_data has no side effects, so > the assignment can be safely removed. Applied with minor glitch, see below. Thanks. > Signed-off-by: Michal Nazarewicz > Cc: Patrick McHardy > --- > net/netfilter/nf_tables_api.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c > index f93b7d0..9c56adc 100644 > --- a/net/netfilter/nf_tables_api.c > +++ b/net/netfilter/nf_tables_api.c > @@ -2521,7 +2521,6 @@ static int nf_tables_dump_set(struct sk_buff *skb, > struct netlink_callback *cb) > u32 portid, seq; > int event, err; > > - nfmsg = nlmsg_data(cb->nlh); > err = nlmsg_parse(cb->nlh, sizeof(*nfmsg), nla, NFTA_SET_ELEM_LIST_MAX, mangled this patch to use sizeof(struct nfgenmsg) instead. That change is not required from the semantic point of view, of course, but for readability reasons I think it's better not to refer to a variable that is not used in that context. > nft_set_elem_list_policy); > if (err < 0) > -- > 1.8.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL violators (charging for a Linux kernel by itself and then charging again for source)
On Fri, Jan 3, 2014 at 11:25 PM, Phil Turmel wrote: > On 01/03/2014 05:07 PM, Richard Weinberger wrote: >> On Fri, Jan 3, 2014 at 7:56 PM, Eric Appleman wrote: > >>> Wasn't the whole idea of a fee being permitted an acknowledgment that >>> physical distribution of source was acceptable if electronic was not >>> possible (low bandwidth ISP, security concerns, etc). >> >> GPLv2 states: >> "You may charge a fee for the physical act of transferring a copy, and >> you may at your option offer warranty protection in exchange for a >> fee." > > Yeah, that's section #1. Charge all you want for general distribution. > > But you are forgetting section #3, which kicks in if you distribute in > compiled or executable form. It limits the fee for separate source code > delivery to "no more than your cost of physically performing source > distribution" > > Only your customers are entitled to that service, though. Not customers. Anyone who got an binary from you (no matter how). GPLv2 only cares about distribution of binaries not customers. But this kind of discussion should move to le...@gpl-violations.org. -- 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/
[tip:x86/build] x86, boot: Use .code16 instead of .code16gcc
Commit-ID: c86cd70a46c97b001dd9d8b3e925d2a38b88d3ca
Gitweb: http://git.kernel.org/tip/c86cd70a46c97b001dd9d8b3e925d2a38b88d3ca
Author: David Woodhouse
AuthorDate: Fri, 3 Jan 2014 22:30:42 +
Committer: H. Peter Anvin
CommitDate: Fri, 3 Jan 2014 14:40:09 -0800
x86, boot: Use .code16 instead of .code16gcc
This reverts commit 28b48688 ("x86, boot: use .code16gcc instead
of .code16").
Versions of binutils older than 2.16 are already not working, so this
workaround is no longer necessary either. At the same time, some of
the transformations that .code16gcc does can be *extremely*
counterintuitive to a human programmer.
Signed-off-by: David Woodhouse
Link: http://lkml.kernel.org/r/1388788242.2391.75.ca...@shinybook.infradead.org
Signed-off-by: H. Peter Anvin
---
arch/x86/boot/bioscall.S | 2 +-
arch/x86/boot/copy.S | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/bioscall.S b/arch/x86/boot/bioscall.S
index 1dfbf64..5077937 100644
--- a/arch/x86/boot/bioscall.S
+++ b/arch/x86/boot/bioscall.S
@@ -13,7 +13,7 @@
* touching registers they shouldn't be.
*/
- .code16gcc
+ .code16
.text
.globl intcall
.type intcall, @function
diff --git a/arch/x86/boot/copy.S b/arch/x86/boot/copy.S
index 11f272c..07a7a4a 100644
--- a/arch/x86/boot/copy.S
+++ b/arch/x86/boot/copy.S
@@ -14,7 +14,7 @@
* Memory copy routines
*/
- .code16gcc
+ .code16
.text
GLOBAL(memcpy)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 25/33] PCI, x86: Make ioapic hotplug support built-in
[fixed Rafael's email address; I imagine you got a few bounces :)]
On Thu, Jan 02, 2014 at 04:05:57PM -0800, Yinghai Lu wrote:
> ioapic hotplug should be built-in like pci root bus hotplug.
>
> Also need to make it depends on X86_IO_APIC.
>
> Signed-off-by: Yinghai Lu
Most of this series is x86-specific and outside the scope of PCI, so I
assume somebody else will deal with it.
This particular patch doesn't seem to depend on anything else, so I'll
merge it.
> ---
> drivers/pci/Kconfig | 3 ++-
> drivers/pci/ioapic.c | 6 +-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index b6a99f7..893503f 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -105,9 +105,10 @@ config PCI_PASID
> If unsure, say N.
>
> config PCI_IOAPIC
> - tristate "PCI IO-APIC hotplug support" if X86
> + bool "PCI IO-APIC hotplug support" if X86
> depends on PCI
> depends on ACPI
> + depends on X86_IO_APIC
> default !X86
>
> config PCI_LABEL
> diff --git a/drivers/pci/ioapic.c b/drivers/pci/ioapic.c
> index 50ce680..2c2930e 100644
> --- a/drivers/pci/ioapic.c
> +++ b/drivers/pci/ioapic.c
> @@ -113,6 +113,10 @@ static struct pci_driver ioapic_driver = {
> .remove = ioapic_remove,
> };
>
> -module_pci_driver(ioapic_driver);
> +static int __init ioapic_init(void)
> +{
> + return pci_register_driver(_driver);
> +}
> +module_init(ioapic_init);
>
> MODULE_LICENSE("GPL");
> --
> 1.8.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/
[tip:x86/build] x86, sparse: Do not force removal of __user when calling copy_to/from_user_nocheck()
Commit-ID: c7c4c8f1b828b550295f1d937578e3090f3b5d66
Gitweb: http://git.kernel.org/tip/c7c4c8f1b828b550295f1d937578e3090f3b5d66
Author: Steven Rostedt
AuthorDate: Fri, 3 Jan 2014 16:45:00 -0500
Committer: H. Peter Anvin
CommitDate: Fri, 3 Jan 2014 14:43:44 -0800
x86, sparse: Do not force removal of __user when calling
copy_to/from_user_nocheck()
Commit ff47ab4ff3cdd "x86: Add 1/2/4/8 byte optimization to 64bit
__copy_{from,to}_user_inatomic" added a "_nocheck" call in between
the copy_to/from_user() and copy_user_generic(). As both the
normal and nocheck versions of theses calls use the proper __user
annotation, a typecast to remove it should not be added.
This causes sparse to spin out the following warnings:
arch/x86/include/asm/uaccess_64.h:207:47: warning: incorrect type in argument 2
(different address spaces)
arch/x86/include/asm/uaccess_64.h:207:47:expected void const [noderef]
*src
arch/x86/include/asm/uaccess_64.h:207:47:got void const *
arch/x86/include/asm/uaccess_64.h:207:47: warning: incorrect type in argument 2
(different address spaces)
arch/x86/include/asm/uaccess_64.h:207:47:expected void const [noderef]
*src
arch/x86/include/asm/uaccess_64.h:207:47:got void const *
arch/x86/include/asm/uaccess_64.h:207:47: warning: incorrect type in argument 2
(different address spaces)
arch/x86/include/asm/uaccess_64.h:207:47:expected void const [noderef]
*src
arch/x86/include/asm/uaccess_64.h:207:47:got void const *
arch/x86/include/asm/uaccess_64.h:207:47: warning: incorrect type in argument 2
(different address spaces)
arch/x86/include/asm/uaccess_64.h:207:47:expected void const [noderef]
*src
arch/x86/include/asm/uaccess_64.h:207:47:got void const *
Cc: Andi Kleen
Signed-off-by: Steven Rostedt
Link: http://lkml.kernel.org/r/20140103164500.5f647...@gandalf.local.home
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/uaccess_64.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/uaccess_64.h
b/arch/x86/include/asm/uaccess_64.h
index 190413d..12a26b9 100644
--- a/arch/x86/include/asm/uaccess_64.h
+++ b/arch/x86/include/asm/uaccess_64.h
@@ -204,13 +204,13 @@ int __copy_in_user(void __user *dst, const void __user
*src, unsigned size)
static __must_check __always_inline int
__copy_from_user_inatomic(void *dst, const void __user *src, unsigned size)
{
- return __copy_from_user_nocheck(dst, (__force const void *)src, size);
+ return __copy_from_user_nocheck(dst, src, size);
}
static __must_check __always_inline int
__copy_to_user_inatomic(void __user *dst, const void *src, unsigned size)
{
- return __copy_to_user_nocheck((__force void *)dst, src, size);
+ return __copy_to_user_nocheck(dst, src, size);
}
extern long __copy_user_nocache(void *dst, const void __user *src,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Perf: Correct Assumptions about Sample Timestamps in Passes
On 1/3/14, 3:07 PM, Frederic Weisbecker wrote: On Wed, Jan 01, 2014 at 11:37:55AM -0700, David Ahern wrote: On 12/26/13, 8:30 AM, Frederic Weisbecker wrote: On Thu, Dec 26, 2013 at 10:24:03AM -0500, David Ahern wrote: On 12/26/13, 10:14 AM, Frederic Weisbecker wrote: I was carrying that patch while working on perf-kvm-stat-live last Fall. It does not solve the problem for live commands, so ended up dropping it and going with local (to the command) hacks. I still think for live commands getting a perf_clock timestamp at the start of a round and using that as the flush time will work best. For perf-kvm-stat-live using perf_clock value at the start of the round as the flush time works beautifully: https://github.com/dsahern/linux/commit/ba8b7b63d5dbdc95aedbbafa670c2232e0cc07a2 Never once failed with "Warning: Timestamp below last timeslice flush" error. I'm not sure I understand why we need that. Why doesn't it work by simply flushing events prior to the earliest timestamp among every CPUs last event? Here's one scenario. Consider N-mmaps: |- t_flush v 0 -|---x 1 -|| ... | N -|----|- t_start t_1 ... t_N You start a round at some time -- t_start. By starting a round it means you go to mmap 0 and check for events, then mmap 1, ..., mmap N. It takes a finite amount of time to move from one mmap to another. Assume there are no events on mmap 0, 1, ... N-1 but samples are generated in mmap N. In the time it takes to move forward from 0 to N, a sample can be generated for mmap 0 and written to the buffer - the 'x' above. It now contains a timestamp < than samples on any other mmap and out pops the flush error. perf-kvm can have over 650,000 events per second and those tend to come in bunches on a single mmap. So even if you go for a "max of the min times across mmaps" it is often wrong. The non-perf_clock logic in perf-kvm uses the min time across all mmaps and even it occasionally fails with the flush error. David I can see one remaining issue when an event interrupts another in a CPU. If the interrupt happens after perf_prepare_sample() -> perf_clock() and perf_output_begin(), we may have locally non-monotonic timestamps in a CPU buffer. That could be solved with a heuristic similar to yours: flush events prior a few millisecs before the barrier since interrupt are supposed to be short. Or we could move the perf_clock() event snapshot to perf_output_sample() to make sure that the event space is reserved before we get the timestamp, thus the interrupting events having superior timestamps are guaranteed to be past the interrupted event in the stream. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 30/33] PCI, x86, ACPI: Enable ioapic hotplug support with acpi host bridge.
On Thu, Jan 02, 2014 at 04:06:02PM -0800, Yinghai Lu wrote:
> We need to have ioapic setup before normal pci drivers.
> otherwise other pci driver can not setup irq.
>
> So we should not treat them as normal pci devices.
> Also we will need to support ioapic hotplug without pci device around.
>
> We need to call ioapic add/remove during host-bridge add/remove.
>
> Signed-off-by: Yinghai Lu
> ---
> drivers/acpi/pci_root.c | 4 ++
> drivers/pci/ioapic.c | 147
> ++-
> include/linux/pci-acpi.h | 8 +++
> 3 files changed, 106 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 20360e4..e666be3 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -599,6 +599,8 @@ static int acpi_pci_root_add(struct acpi_device *device,
> pci_assign_unassigned_root_bus_resources(root->bus);
> }
>
> + acpi_pci_ioapic_add(root);
> +
> pci_bus_add_devices(root->bus);
> return 1;
>
> @@ -613,6 +615,8 @@ static void acpi_pci_root_remove(struct acpi_device
> *device)
>
> pci_stop_root_bus(root->bus);
>
> + acpi_pci_ioapic_remove(root);
> +
> device_set_run_wake(root->bus->bridge, false);
> pci_acpi_remove_bus_pm_notifier(device);
>
> diff --git a/drivers/pci/ioapic.c b/drivers/pci/ioapic.c
> index 2c2930e..60351b2 100644
> --- a/drivers/pci/ioapic.c
> +++ b/drivers/pci/ioapic.c
The file comment:
* This driver manages PCI I/O APICs added by hotplug after boot. We try to
* claim all I/O APIC PCI devices, but those present at boot were registered
* when we parsed the ACPI MADT, so we'll fail when we try to re-register
* them.
is now incorrect because this no longer claims all PCI I/O APICs. As far
as I can tell, it now claims every ACPI Device below the host bridge that
has a _GSB method and an associated PCI device. If there is a PCI I/O APIC
that does not appear in the namespace, this driver will not claim it.
I don't have a problem with that, but the comment needs to be updated to
reflect the change.
> @@ -22,101 +22,142 @@
> #include
> #include
>
> -struct ioapic {
> - acpi_handle handle;
> +struct acpi_pci_ioapic {
> + acpi_handle root_handle;
> u32 gsi_base;
> + struct pci_dev *pdev;
> + struct list_head list;
> };
>
> -static int ioapic_probe(struct pci_dev *dev, const struct pci_device_id *ent)
> +static LIST_HEAD(ioapic_list);
> +static DEFINE_MUTEX(ioapic_list_lock);
> +
> +static void handle_ioapic_add(acpi_handle handle, struct pci_dev **pdev,
> + u32 *pgsi_base)
> {
> - acpi_handle handle;
> acpi_status status;
> unsigned long long gsb;
> - struct ioapic *ioapic;
> + struct pci_dev *dev;
> + u32 gsi_base;
> int ret;
> char *type;
> - struct resource *res;
> + struct resource r;
> + struct resource *res =
> + char objname[64];
> + struct acpi_buffer buffer = {sizeof(objname), objname};
You can avoid the hard-coded 64-byte buffer with:
struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER, NULL};
And of course the corresponding kfree in the exit path. The
acpi_get_name() could be done after all possible error exits, so you'd only
need the kfree in the success path.
> - handle = ACPI_HANDLE(>dev);
> - if (!handle)
> - return -EINVAL;
> + *pdev = NULL;
> + *pgsi_base = 0;
>
> status = acpi_evaluate_integer(handle, "_GSB", NULL, );
> - if (ACPI_FAILURE(status))
> - return -EINVAL;
> -
> - /*
> - * The previous code in acpiphp evaluated _MAT if _GSB failed, but
> - * ACPI spec 4.0 sec 6.2.2 requires _GSB for hot-pluggable I/O APICs.
> - */
> + if (ACPI_FAILURE(status) || !gsb)
> + return;
>
> - ioapic = kzalloc(sizeof(*ioapic), GFP_KERNEL);
> - if (!ioapic)
> - return -ENOMEM;
> + dev = acpi_get_pci_dev(handle);
> + if (!dev)
> + return;
>
> - ioapic->handle = handle;
> - ioapic->gsi_base = (u32) gsb;
> + acpi_get_name(handle, ACPI_FULL_PATHNAME, );
>
> - if (dev->class == PCI_CLASS_SYSTEM_PIC_IOAPIC)
> - type = "IOAPIC";
> - else
> - type = "IOxAPIC";
> + gsi_base = gsb;
> + type = "IOxAPIC";
>
> ret = pci_enable_device(dev);
> if (ret < 0)
> - goto exit_free;
> + goto exit_put;
>
> pci_set_master(dev);
>
> + if (dev->class == PCI_CLASS_SYSTEM_PIC_IOAPIC)
> + type = "IOAPIC";
Why not keep the 'type = "IOxAPIC"' assignment here as it was before? Then
all the "type" manipulation is in one place.
> if (pci_request_region(dev, 0, type))
> goto exit_disable;
>
> res = >resource[0];
> - if (acpi_register_ioapic(ioapic->handle, res->start, ioapic->gsi_base))
> +
> + if
Re: GPL violators (charging for a Linux kernel by itself and then charging again for source)
On 01/03/2014 05:07 PM, Richard Weinberger wrote: > On Fri, Jan 3, 2014 at 7:56 PM, Eric Appleman wrote: >> Wasn't the whole idea of a fee being permitted an acknowledgment that >> physical distribution of source was acceptable if electronic was not >> possible (low bandwidth ISP, security concerns, etc). > > GPLv2 states: > "You may charge a fee for the physical act of transferring a copy, and > you may at your option offer warranty protection in exchange for a > fee." Yeah, that's section #1. Charge all you want for general distribution. But you are forgetting section #3, which kicks in if you distribute in compiled or executable form. It limits the fee for separate source code delivery to "no more than your cost of physically performing source distribution" Only your customers are entitled to that service, though. But IANAL. Regards, Phil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/boot: use .code16 instead of .code16gcc
On 01/03/2014 02:30 PM, David Woodhouse wrote: > Since I just made .code16 work in LLVM, this removes one more barrier to > building the kernel with LLVM/clang. And it looks like 'clang -m16' for > the C code in arch/x86/boot shouldn't actually be that hard to do now > either. Nice. I would really like a gcc option "-m16" even if all it did was emit .code16gcc first in any assembly file (a bunch of the options we need for the 16-bit code is just so gcc doesn't emit code *before* the .code16gcc directive.) -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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_pstate divide error with v3.13-rc4-256-gb7000ad
On Friday, January 03, 2014 08:04:36 PM Gleb Natapov wrote: > On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote: > > Hi All, > > > > Sorry for being late to the party but I just got back from vacation. > > > > There is something deeply wrong here. We should have never gotten to > > intel_pstate_init_cpu(). The VM had to have returned value from the read > > of the max pstate at driver init time and 0 when the CPU was being brought > > up. > > > > intel_pstate_msrs_not_valid() was added to solve this issue early on > > if I remember correctly it was Josh that reported it then. Is there > > a definative way to detect whether we are running in a VM? > > > Checking for VM is a wrong thing to do here. KVM should behave like it > does not support p-state. > > > Can some one tell me how the nested environment differs in regards to > > reading MSRs? > > > It shouldn't differ, but there may be bug somewhere in nested emulation. > We shouldn't try and hind the bug by doing more checks in Linux but > rather fixing KVM bug that causes Linux to behave incorrectly. Well, fixing the KVM bug is surely welcome. That said, adding checks to ensure that your assumptions are valid is rarely wrong, especially if they are done once per kernel boot. And the kernel only should panic if it cannot continue to run, which isn't the case here. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] EFI kexec fixes
Peter, please pull these fixes for the EFI kexec patches sitting in tip/x86/efi-kexec - the kbuild bot reported some build breakage. The following changes since commit 518548abd61808ea1e31614ccbdae34d3c32dfa4: x86/efi: Delete superfluous global variables (2013-12-29 13:09:08 +) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git kexec for you to fetch changes up to 5c12af0c41e3417e1939095325920463b5f8e726: x86/efi: parse_efi_setup() build fix (2014-01-03 14:38:18 +) Dave Young (2): x86: ksysfs.c build fix x86/efi: parse_efi_setup() build fix arch/x86/include/asm/efi.h | 5 ++--- arch/x86/kernel/ksysfs.c | 1 + 2 files changed, 3 insertions(+), 3 deletions(-) -- Matt Fleming, 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/
