linux-next: manual merge of the akpm tree with the tip tree
Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in mm/huge_memory.c between various commits from the tip tree and commit "thp: fix update_mmu_cache_pmd() calls" from the akpm tree. It appears that the shed/numa patches in the tip tree have been changed in today's version of the tip tree and this akpm tree patch no longer applies. I dropped the akpm tree patch and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp1vECxGEKUv.pgp Description: PGP signature
[PATCH 6/6] fuse: optimize short direct reads
If user requested direct read beyond EOF, we can skip sending fuse requests
for positions beyond EOF because userspace would ACK them with zero bytes read
anyway. We can trust to i_size in fuse_direct_IO for such cases because it's
called from fuse_file_aio_read() and the latter updates fuse attributes
including i_size.
Signed-off-by: Maxim Patlasov
---
fs/fuse/file.c | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 3e0fdb7..d2094e1 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -1324,7 +1324,7 @@ EXPORT_SYMBOL_GPL(fuse_direct_io);
static ssize_t __fuse_direct_read(struct file *file, const struct iovec *iov,
unsigned long nr_segs, loff_t *ppos,
- struct kiocb *async)
+ struct kiocb *async, size_t count)
{
ssize_t res;
struct inode *inode = file->f_path.dentry->d_inode;
@@ -1332,8 +1332,7 @@ static ssize_t __fuse_direct_read(struct file *file,
const struct iovec *iov,
if (is_bad_inode(inode))
return -EIO;
- res = fuse_direct_io(file, iov, nr_segs, iov_length(iov, nr_segs),
-ppos, 0, async);
+ res = fuse_direct_io(file, iov, nr_segs, count, ppos, 0, async);
fuse_invalidate_attr(inode);
@@ -1344,7 +1343,7 @@ static ssize_t fuse_direct_read(struct file *file, char
__user *buf,
size_t count, loff_t *ppos)
{
struct iovec iov = { .iov_base = buf, .iov_len = count };
- return __fuse_direct_read(file, , 1, ppos, NULL);
+ return __fuse_direct_read(file, , 1, ppos, NULL, count);
}
static ssize_t __fuse_direct_write(struct file *file, const struct iovec *iov,
@@ -2405,8 +2404,15 @@ fuse_direct_IO(int rw, struct kiocb *iocb, const struct
iovec *iov,
inode = file->f_mapping->host;
i_size = i_size_read(inode);
+ /* optimization for short read */
+ if (rw != WRITE && offset + count > i_size) {
+ if (offset >= i_size)
+ return 0;
+ count = i_size - offset;
+ }
+
/* cannot write beyond eof asynchronously */
- if (is_sync_kiocb(iocb) || (offset + count <= i_size) || rw != WRITE) {
+ if (is_sync_kiocb(iocb) || (offset + count <= i_size)) {
struct fuse_io_priv *io;
io = kmalloc(sizeof(struct fuse_io_priv), GFP_KERNEL);
@@ -2429,7 +2435,8 @@ fuse_direct_IO(int rw, struct kiocb *iocb, const struct
iovec *iov,
if (rw == WRITE)
ret = __fuse_direct_write(file, iov, nr_segs, , async_cb);
else
- ret = __fuse_direct_read(file, iov, nr_segs, , async_cb);
+ ret = __fuse_direct_read(file, iov, nr_segs, , async_cb,
+count);
if (async_cb) {
fuse_aio_complete(async_cb->private, ret == count ? 0 : -EIO,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 5/6] fuse: truncate file if async dio failed
The patch improves error handling in fuse_direct_IO(): if we successfully
submitted several fuse requests on behalf of synchronous direct write
extending file and some of them failed, let's try to do our best to clean-up.
Signed-off-by: Maxim Patlasov
---
fs/fuse/file.c | 55 +--
1 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index ef6d3de..3e0fdb7 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -2341,6 +2341,53 @@ int fuse_notify_poll_wakeup(struct fuse_conn *fc,
return 0;
}
+static void fuse_do_truncate(struct file *file)
+{
+ struct fuse_file *ff = file->private_data;
+ struct inode *inode = file->f_mapping->host;
+ struct fuse_conn *fc = get_fuse_conn(inode);
+ struct fuse_req *req;
+ struct fuse_setattr_in inarg;
+ struct fuse_attr_out outarg;
+ int err;
+
+ req = fuse_get_req_nopages(fc);
+ if (IS_ERR(req)) {
+ printk(KERN_WARNING "failed to allocate req for truncate "
+ "(%ld)\n", PTR_ERR(req));
+ return;
+ }
+
+ memset(, 0, sizeof(inarg));
+ memset(, 0, sizeof(outarg));
+
+ inarg.valid |= FATTR_SIZE;
+ inarg.size = i_size_read(inode);
+
+ inarg.valid |= FATTR_FH;
+ inarg.fh = ff->fh;
+
+ req->in.h.opcode = FUSE_SETATTR;
+ req->in.h.nodeid = get_node_id(inode);
+ req->in.numargs = 1;
+ req->in.args[0].size = sizeof(inarg);
+ req->in.args[0].value =
+ req->out.numargs = 1;
+ if (fc->minor < 9)
+ req->out.args[0].size = FUSE_COMPAT_ATTR_OUT_SIZE;
+ else
+ req->out.args[0].size = sizeof(outarg);
+ req->out.args[0].value =
+
+ fuse_request_send(fc, req);
+ err = req->out.h.error;
+ fuse_put_request(fc, req);
+
+ if (err)
+ printk(KERN_WARNING "failed to truncate to %lld with error "
+ "%d\n", i_size_read(inode), err);
+}
+
static ssize_t
fuse_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
loff_t offset, unsigned long nr_segs)
@@ -2393,8 +2440,12 @@ fuse_direct_IO(int rw, struct kiocb *iocb, const struct
iovec *iov,
ret = wait_on_sync_kiocb(iocb);
- if (rw == WRITE && ret > 0)
- fuse_write_update_size(inode, pos);
+ if (rw == WRITE) {
+ if (ret > 0)
+ fuse_write_update_size(inode, pos);
+ else if (ret < 0 && offset + count > i_size)
+ fuse_do_truncate(file);
+ }
}
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC] cpufreq: Fix issues with hot-[un]plugging of cpus
Hi Rafael and other cpufreq masters,
I am really not sure if this patch is a HACK or a valid solution :)
Please have a look.
Setup:
-
- ARM big LITTLE Platform with 5 cpus. cpus 2, 3 & 4 share clock and hence are
part of policy->cpus. cpus 0 & 1 share clock but they aren't discussed here.
- Interactive governor: I know its not mainlined and will never be. Problem
should be same with all the governors we have. So, problem is not really
governor dependent. I have added few prints at start/stop cases of governor,
to see what policy->cpus is set to.
Problem Statement:
-
There are many issues :(
1) I couldn't understand what we really want the value of policy->cpus be? Only
the online cpus sharing clock? or all the possible cpus sharing clock?
When we offline a cpu, we remove it from cpus field: cpumask_clear_cpu(cpu,
data->cpus);
Which shows that it is mask of online cpus only. But there are many places
checking if a cpu is online or not (cpu in policy->cpus) in cpufreq.c. Which
shows something else.
2) Kernel crashes when hot-unplugging cpus
When we do: for i in 2 3 4; do echo 0 >
/sys/devices/system/cpu/cpu$i/online; done
We get:
cpufreq_governor_interactive: CPUFREQ_GOV_STOP cpu 2 policy->cpus 2-4
cpufreq_vexpress: CPUFreq for CPU 3 initialized
cpufreq_governor_interactive: CPUFREQ_GOV_START cpu 3 policy->cpus 2-4
CPU2: shutdown
cpufreq_governor_interactive: CPUFREQ_GOV_STOP cpu 3 policy->cpus 3-4
cpufreq_vexpress: CPUFreq for CPU 4 initialized
cpufreq_governor_interactive: CPUFREQ_GOV_START cpu 4 policy->cpus 2-4
And then crash from interactive governor.
Note the following lines:
cpufreq_governor_interactive: CPUFREQ_GOV_STOP cpu 2 policy->cpus 2-4
cpufreq_governor_interactive: CPUFREQ_GOV_START cpu 3 policy->cpus 2-4
cpufreq_governor_interactive: CPUFREQ_GOV_STOP cpu 3 policy->cpus 3-4
cpufreq_governor_interactive: CPUFREQ_GOV_START cpu 4 policy->cpus 2-4
So the governor is always started for CPUs 2 through 4 despite the fact
that CPU 2 is removed. This makes the governor unstable due to wrong info
passed.
FIX: keep only online cpus in policy->cpus
---
3) With above issue solved, i tried to run the same stuff again and look what i
got:
cpufreq_governor_interactive: CPUFREQ_GOV_STOP cpu 2 policy->cpus 2-4
cpufreq_vexpress: CPUFreq for CPU 3 initialized
cpufreq_governor_interactive: CPUFREQ_GOV_START cpu 3 policy->cpus 2-4
CPU2: shutdown
a) Because cpu 2 is still not completely hot unplugged and is still present in
cpu_online_mask.
b) If we try to remove cpu 3, governor wouldn't be notified of it, because cpu 3
wasn't policy->cpu.
FIX: Stop/Start governor on every non policy->cpu removal
---
4) Hot unplug is fine now, but not hotplug :(
for i in 2 3 4; do echo 1 > /sys/devices/system/cpu/cpu$i/online; done
CPU2: Booted secondary processor
cpufreq_vexpress: CPUFreq for CPU 2 initialized
cpufreq_governor_interactive: CPUFREQ_GOV_START cpu 2 policy->cpus 2
CPU3: Booted secondary processor
cpufreq_vexpress: CPUFreq for CPU 3 initialized
CPU4: Booted secondary processor
cpufreq_vexpress: CPUFreq for CPU 4 initialized
Hmmm, Governor is not informed about 3 and 4. :(
FIX: Stop/Start governor on every managed_policy cpu, i.e. cpu for which
--- policy struct exists
Please share your comments, i know there would be many :)
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0c3e29a..69bd739 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -749,11 +749,16 @@ static int cpufreq_add_dev_policy(unsigned int cpu,
return -EBUSY;
}
+ __cpufreq_governor(managed_policy, CPUFREQ_GOV_STOP);
+
spin_lock_irqsave(_driver_lock, flags);
cpumask_copy(managed_policy->cpus, policy->cpus);
per_cpu(cpufreq_cpu_data, cpu) = managed_policy;
spin_unlock_irqrestore(_driver_lock, flags);
+ __cpufreq_governor(managed_policy, CPUFREQ_GOV_START);
+ __cpufreq_governor(managed_policy, CPUFREQ_GOV_LIMITS);
+
pr_debug("CPU already managed, adding link\n");
ret = sysfs_create_link(>kobj,
_policy->kobj,
@@ -968,6 +973,13 @@ static int cpufreq_add_dev(struct device *dev, struct
subsys_interface *sif)
pr_debug("initialization failed\n");
goto err_unlock_policy;
}
+
+ /*
+* affected cpus must always be the one, which are online. We aren't
+* managing offline cpus here.
+*/
+
[PATCH 3/6] fuse: make fuse_direct_io() aware about AIO
The patch implements passing "struct kiocb *async" down the stack up to
fuse_send_read/write where it is used to submit request asynchronously.
async==NULL designates synchronous processing.
Non-trivial part of the patch is changes in fuse_direct_io(): resources
like fuse requests and user pages cannot be released immediately in async
case.
Signed-off-by: Maxim Patlasov
---
fs/fuse/cuse.c |4 ++--
fs/fuse/file.c | 58 --
fs/fuse/fuse_i.h |2 +-
3 files changed, 42 insertions(+), 22 deletions(-)
diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c
index 65ce10a..beb99e9 100644
--- a/fs/fuse/cuse.c
+++ b/fs/fuse/cuse.c
@@ -93,7 +93,7 @@ static ssize_t cuse_read(struct file *file, char __user *buf,
size_t count,
loff_t pos = 0;
struct iovec iov = { .iov_base = buf, .iov_len = count };
- return fuse_direct_io(file, , 1, count, , 0);
+ return fuse_direct_io(file, , 1, count, , 0, NULL);
}
static ssize_t cuse_write(struct file *file, const char __user *buf,
@@ -106,7 +106,7 @@ static ssize_t cuse_write(struct file *file, const char
__user *buf,
* No locking or generic_write_checks(), the server is
* responsible for locking and sanity checks.
*/
- return fuse_direct_io(file, , 1, count, , 1);
+ return fuse_direct_io(file, , 1, count, , 1, NULL);
}
static int cuse_open(struct inode *inode, struct file *file)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 634f54a..c585158 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -598,7 +598,8 @@ static size_t fuse_async_req_send(struct fuse_conn *fc,
struct fuse_req *req,
}
static size_t fuse_send_read(struct fuse_req *req, struct file *file,
-loff_t pos, size_t count, fl_owner_t owner)
+loff_t pos, size_t count, fl_owner_t owner,
+struct kiocb *async)
{
struct fuse_file *ff = file->private_data;
struct fuse_conn *fc = ff->fc;
@@ -610,6 +611,10 @@ static size_t fuse_send_read(struct fuse_req *req, struct
file *file,
inarg->read_flags |= FUSE_READ_LOCKOWNER;
inarg->lock_owner = fuse_lock_owner_id(fc, owner);
}
+
+ if (async)
+ return fuse_async_req_send(fc, req, count, async);
+
fuse_request_send(fc, req);
return req->out.args[0].size;
}
@@ -662,7 +667,7 @@ static int fuse_readpage(struct file *file, struct page
*page)
req->num_pages = 1;
req->pages[0] = page;
req->page_descs[0].length = count;
- num_read = fuse_send_read(req, file, pos, count, NULL);
+ num_read = fuse_send_read(req, file, pos, count, NULL, NULL);
err = req->out.h.error;
fuse_put_request(fc, req);
@@ -865,7 +870,8 @@ static void fuse_write_fill(struct fuse_req *req, struct
fuse_file *ff,
}
static size_t fuse_send_write(struct fuse_req *req, struct file *file,
- loff_t pos, size_t count, fl_owner_t owner)
+ loff_t pos, size_t count, fl_owner_t owner,
+ struct kiocb *async)
{
struct fuse_file *ff = file->private_data;
struct fuse_conn *fc = ff->fc;
@@ -877,6 +883,10 @@ static size_t fuse_send_write(struct fuse_req *req, struct
file *file,
inarg->write_flags |= FUSE_WRITE_LOCKOWNER;
inarg->lock_owner = fuse_lock_owner_id(fc, owner);
}
+
+ if (async)
+ return fuse_async_req_send(fc, req, count, async);
+
fuse_request_send(fc, req);
return req->misc.write.out.size;
}
@@ -904,7 +914,7 @@ static size_t fuse_send_write_pages(struct fuse_req *req,
struct file *file,
for (i = 0; i < req->num_pages; i++)
fuse_wait_on_page_writeback(inode, req->pages[i]->index);
- res = fuse_send_write(req, file, pos, count, NULL);
+ res = fuse_send_write(req, file, pos, count, NULL, NULL);
offset = req->page_descs[0].offset;
count = res;
@@ -1244,7 +1254,7 @@ static inline int fuse_iter_npages(const struct iov_iter
*ii_p)
ssize_t fuse_direct_io(struct file *file, const struct iovec *iov,
unsigned long nr_segs, size_t count, loff_t *ppos,
- int write)
+ int write, struct kiocb *async)
{
struct fuse_file *ff = file->private_data;
struct fuse_conn *fc = ff->fc;
@@ -1266,16 +1276,22 @@ ssize_t fuse_direct_io(struct file *file, const struct
iovec *iov,
size_t nbytes = min(count, nmax);
int err = fuse_get_user_pages(req, , , write);
if (err) {
+ if (async)
+ fuse_put_request(fc, req);
+
res = err;
break;
}
if (write)
- nres =
[PATCH 4/6] fuse: enable asynchronous processing direct IO
In case of synchronous DIO request (i.e. read(2) or write(2) for a file
opened with O_DIRECT), the patch submits fuse requests asynchronously, but
waits for their completions before return from fuse_direct_IO().
In case of asynchronous DIO request (i.e. libaio io_submit() or a file opened
with O_DIRECT), the patch submits fuse requests asynchronously and return
-EIOCBQUEUED immediately.
The only special case is async DIO extending file. Here the patch falls back
to old behaviour because we can't return -EIOCBQUEUED and update i_size later,
without i_mutex hold.
Signed-off-by: Maxim Patlasov
---
fs/fuse/file.c | 44 ++--
1 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index c585158..ef6d3de 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -2348,14 +2348,54 @@ fuse_direct_IO(int rw, struct kiocb *iocb, const struct
iovec *iov,
ssize_t ret = 0;
struct file *file = NULL;
loff_t pos = 0;
+ struct inode *inode;
+ loff_t i_size;
+ size_t count = iov_length(iov, nr_segs);
+ struct kiocb *async_cb = NULL;
file = iocb->ki_filp;
pos = offset;
+ inode = file->f_mapping->host;
+ i_size = i_size_read(inode);
+
+ /* cannot write beyond eof asynchronously */
+ if (is_sync_kiocb(iocb) || (offset + count <= i_size) || rw != WRITE) {
+ struct fuse_io_priv *io;
+
+ io = kmalloc(sizeof(struct fuse_io_priv), GFP_KERNEL);
+ if (!io)
+ return -ENOMEM;
+
+ spin_lock_init(>lock);
+ io->reqs = 1;
+ io->bytes = -1;
+ io->size = 0;
+ io->offset = offset;
+ io->write = (rw == WRITE);
+ io->err = 0;
+ io->iocb = iocb;
+ iocb->private = io;
+
+ async_cb = iocb;
+ }
if (rw == WRITE)
- ret = __fuse_direct_write(file, iov, nr_segs, , NULL);
+ ret = __fuse_direct_write(file, iov, nr_segs, , async_cb);
else
- ret = __fuse_direct_read(file, iov, nr_segs, , NULL);
+ ret = __fuse_direct_read(file, iov, nr_segs, , async_cb);
+
+ if (async_cb) {
+ fuse_aio_complete(async_cb->private, ret == count ? 0 : -EIO,
+ -1);
+
+ if (!is_sync_kiocb(iocb))
+ return -EIOCBQUEUED;
+
+ ret = wait_on_sync_kiocb(iocb);
+
+ if (rw == WRITE && ret > 0)
+ fuse_write_update_size(inode, pos);
+ }
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] fuse: add support of async IO
The patch implements a framework to process an IO request asynchronously. The
idea is to associate several fuse requests with a single kiocb by means of
fuse_io_priv structure. The structure plays the same role for FUSE as 'struct
dio' for direct-io.c.
The framework is supposed to be used like this:
- someone (who wants to process an IO asynchronously) allocates fuse_io_priv,
initializes and saves it in kiocb->private.
- as soon as fuse request is filled, it can be submitted (in non-blocking way)
by fuse_async_req_send()
- when all submitted requests are ACKed by userspace, io->reqs drops to zero
triggering aio_complete()
In case of IO initiated by libaio, aio_complete() will finish processing the
same way as in case of dio_complete() calling aio_complete(). But the
framework may be also used for internal FUSE use when initial IO request
was synchronous (from user perspective), but it's beneficial to process it
asynchronously. Then the caller should wait on kiocb explicitly and
aio_complete() will wake the caller up.
Signed-off-by: Maxim Patlasov
---
fs/fuse/file.c | 94 ++
fs/fuse/fuse_i.h | 15 +
2 files changed, 109 insertions(+), 0 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 6685cb0..634f54a 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -503,6 +503,100 @@ static void fuse_release_user_pages(struct fuse_req *req,
int write)
}
}
+/**
+ * In case of short read, the caller sets 'pos' to the position of
+ * actual end of fuse request in IO request. Otherwise, if bytes_requested
+ * == bytes_transferred or rw == WRITE, the caller sets 'pos' to -1.
+ *
+ * An example:
+ * User requested DIO read of 64K. It was splitted into two 32K fuse requests,
+ * both submitted asynchronously. The first of them was ACKed by userspace as
+ * fully completed (req->out.args[0].size == 32K) resulting in pos == -1. The
+ * second request was ACKed as short, e.g. only 1K was read, resulting in
+ * pos == 33K.
+ *
+ * Thus, when all fuse requests are completed, the minimal non-negative 'pos'
+ * will be equal to the length of the longest contiguous fragment of
+ * transferred data starting from the beginning of IO request.
+ */
+static void fuse_aio_complete(struct fuse_io_priv *io, int err, ssize_t pos)
+{
+ int left;
+
+ spin_lock(>lock);
+ if (err)
+ io->err = io->err ? : err;
+ else if (pos >= 0 && (io->bytes < 0 || pos < io->bytes))
+ io->bytes = pos;
+
+ left = --io->reqs;
+ spin_unlock(>lock);
+
+ if (!left) {
+ long res;
+
+ if (io->err)
+ res = io->err;
+ else if (io->bytes >= 0 && io->write)
+ res = -EIO;
+ else {
+ res = io->bytes < 0 ? io->size : io->bytes;
+
+ if (!is_sync_kiocb(io->iocb)) {
+ struct path *path = >iocb->ki_filp->f_path;
+ struct inode *inode = path->dentry->d_inode;
+ struct fuse_conn *fc = get_fuse_conn(inode);
+ struct fuse_inode *fi = get_fuse_inode(inode);
+
+ spin_lock(>lock);
+ fi->attr_version = ++fc->attr_version;
+ spin_unlock(>lock);
+ }
+ }
+
+ aio_complete(io->iocb, res, 0);
+ kfree(io);
+ }
+}
+
+static void fuse_aio_complete_req(struct fuse_conn *fc, struct fuse_req *req)
+{
+ struct fuse_io_priv *io = req->io;
+ ssize_t pos = -1;
+
+ fuse_release_user_pages(req, !io->write);
+
+ if (io->write) {
+ if (req->misc.write.in.size != req->misc.write.out.size)
+ pos = req->misc.write.in.offset - io->offset +
+ req->misc.write.out.size;
+ } else {
+ if (req->misc.read.in.size != req->out.args[0].size)
+ pos = req->misc.read.in.offset - io->offset +
+ req->out.args[0].size;
+ }
+
+ fuse_aio_complete(io, req->out.h.error, pos);
+}
+
+static size_t fuse_async_req_send(struct fuse_conn *fc, struct fuse_req *req,
+ size_t num_bytes, struct kiocb *iocb)
+{
+ struct fuse_io_priv *io = iocb->private;
+
+ spin_lock(>lock);
+ io->size += num_bytes;
+ io->reqs++;
+ spin_unlock(>lock);
+
+ req->io = io;
+ req->end = fuse_aio_complete_req;
+
+ fuse_request_send_background(fc, req);
+
+ return num_bytes;
+}
+
static size_t fuse_send_read(struct fuse_req *req, struct file *file,
loff_t pos, size_t count, fl_owner_t owner)
{
diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
index e4f70ea..618d48a 100644
--- a/fs/fuse/fuse_i.h
+++
[PATCH 1/6] fuse: move fuse_release_user_pages() up
fuse_release_user_pages() will be indirectly used by fuse_send_read/write
in future patches.
Signed-off-by: Maxim Patlasov
---
fs/fuse/file.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 19b50e7..6685cb0 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -491,6 +491,18 @@ void fuse_read_fill(struct fuse_req *req, struct file
*file, loff_t pos,
req->out.args[0].size = count;
}
+static void fuse_release_user_pages(struct fuse_req *req, int write)
+{
+ unsigned i;
+
+ for (i = 0; i < req->num_pages; i++) {
+ struct page *page = req->pages[i];
+ if (write)
+ set_page_dirty_lock(page);
+ put_page(page);
+ }
+}
+
static size_t fuse_send_read(struct fuse_req *req, struct file *file,
loff_t pos, size_t count, fl_owner_t owner)
{
@@ -1035,18 +1047,6 @@ out:
return written ? written : err;
}
-static void fuse_release_user_pages(struct fuse_req *req, int write)
-{
- unsigned i;
-
- for (i = 0; i < req->num_pages; i++) {
- struct page *page = req->pages[i];
- if (write)
- set_page_dirty_lock(page);
- put_page(page);
- }
-}
-
static inline void fuse_page_descs_length_init(struct fuse_req *req,
unsigned index, unsigned nr_pages)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] fuse: process direct IO asynchronously
Hi, Existing fuse implementation always processes direct IO synchronously: it submits next request to userspace fuse only when previous is completed. This is suboptimal because: 1) libaio DIO works in blocking way; 2) userspace fuse can't achieve parallelism processing several requests simultaneously (e.g. in case of distributed network storage); 3) userspace fuse can't merge requests before passing it to actual storage. The idea of the patch-set is to submit fuse requests in non-blocking way (where it's possible) and either return -EIOCBQUEUED or wait for their completion synchronously. The patch-set to be applied on top of for-next of Miklos' git repo. To estimate performance improvement I used slightly modified fusexmp over tmpfs (clearing O_DIRECT bit from fi->flags in xmp_open). For synchronous operations I used 'dd' like this: dd of=/dev/null if=/fuse/mnt/file bs=2M count=256 iflag=direct dd if=/dev/zero of=/fuse/mnt/file bs=2M count=256 oflag=direct conv=notrunc For AIO I used 'aio-stress' like this: aio-stress -s 512 -a 4 -b 1 -c 1 -O -o 1 /fuse/mnt/file aio-stress -s 512 -a 4 -b 1 -c 1 -O -o 0 /fuse/mnt/file The throughput on some commodity (rather feeble) server was (in MB/sec): original / patched dd reads:~322 / ~382 dd writes: ~277 / ~288 aio reads: ~380 / ~459 aio writes: ~319 / ~353 Thanks, Maxim --- Maxim V. Patlasov (6): fuse: move fuse_release_user_pages() up fuse: add support of async IO fuse: make fuse_direct_io() aware about AIO fuse: enable asynchronous processing direct IO fuse: truncate file if async dio failed fuse: optimize short direct reads fs/fuse/cuse.c |4 - fs/fuse/file.c | 276 -- fs/fuse/fuse_i.h | 17 +++ 3 files changed, 262 insertions(+), 35 deletions(-) -- 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: TIP tree's master branch failed to boot up
On 12/10/2012 12:50 PM, Michael Wang wrote: > Hi, Folks > > I'm testing with the latest tip tree's master branch 3.7.0-rc8 and > failed to boot up my server, it's hung at very beginning and I could not > catch any useful log, is there any one else got this problem or I'm the > only one?. And bisect catch below commit: commit 56e7dba100a50f674627a3764fd4da4a6ec93295 Merge: ea8432f 16544f8 Author: Ingo Molnar Date: Fri Dec 7 12:13:11 2012 +0100 Merge branch 'x86/microcode' Regards, Michael Wang > > Regards, > Michael Wang > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Sharing PCIE driver between Microblaze and Arm zynq
2012/12/7 Arnd Bergmann : > On Friday 07 December 2012, Michal Simek wrote: >> On 12/06/2012 10:27 PM, Bjorn Helgaas wrote: >> > [+cc linux-pci] >> > >> > On Thu, Dec 6, 2012 at 7:23 AM, Michal Simek >> > wrote: >> >> Hi guys, >> >> >> >> I have a question regarding to sharing generic OF pcie driver between >> >> two architectures MB and ARM Zynq. >> >> Is drivers/pci/pcie location good for it? >> >> Make no sense to have the same driver in two locations. >> > >> > I think you're talking about a PCI host bridge driver. It would >> > definitely be nice to move toward a generic, shared driver. Host >> > bridge drivers are responsible for enumerating the PCI hierarchy below >> > the bridge. Enumeration is not really PCIe-specific, so I wouldn't >> > put it in drivers/pci/pcie. >> >> Not a PCI expert, just trying to find out the proper location for this >> shared driver. > > I'd suggest creating a drivers/pci/host directory. We will have more of > these in the future. AFAIK, there is no fully generic (architecture > independent) way to interface a PCI host driver to the PCI subsystem, > but I think we are getting closer to that. You are probably fairly > free to modify the microblaze architecture specific code though if needed. yep. >> >> Is using readl/writel IO functions in this driver the best option >> >> which we can have? >> >> Or is there any other recommendation? >> > >> > I'm not really a driver person, but if you're writing a new driver, >> > wouldn't you use the iomap interfaces (ioremap(), ioread32(), etc) >> > rather than readl()? >> >> That driver exists but it is not in mainline and it is better to directly >> add it to proper location with correct io functions. >> The question is if ioread/iowrite functions are correct one. >> PowerPC io-defs.h suggests that readl/writel should be used for PCI. > > ioread32/iowrite32 are defined to behave the same way readl/writel regarding > addressing modes and barriers, but also allow operating on __iomem pointers > that were returned from ioport_map(). You probably don't need that. > > Some architectures like powerpc have their own accessors for on-chip MMIO > areas, but ARM does not. The PowerPC rule is that you must use either > readl/writel or ioread32/iowrite32 to access devices connected to a PCI > bus, but you would not necessarily do that for the PCI host controller > itself on PowerPC. ok. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Sharing PCIE driver between Microblaze and Arm zynq
2012/12/7 Grant Likely : > On Fri, 07 Dec 2012 10:45:01 +0100, Michal Simek wrote: >> On 12/06/2012 10:27 PM, Bjorn Helgaas wrote: >> > [+cc linux-pci] >> > >> > On Thu, Dec 6, 2012 at 7:23 AM, Michal Simek >> > wrote: >> >> Hi guys, >> >> >> >> I have a question regarding to sharing generic OF pcie driver between >> >> two architectures MB and ARM Zynq. >> >> Is drivers/pci/pcie location good for it? >> >> Make no sense to have the same driver in two locations. >> > >> > I think you're talking about a PCI host bridge driver. It would >> > definitely be nice to move toward a generic, shared driver. Host >> > bridge drivers are responsible for enumerating the PCI hierarchy below >> > the bridge. Enumeration is not really PCIe-specific, so I wouldn't >> > put it in drivers/pci/pcie. >> >> Not a PCI expert, just trying to find out the proper location for this >> shared driver. >> >> >> >> Is using readl/writel IO functions in this driver the best option >> >> which we can have? >> >> Or is there any other recommendation? >> > >> > I'm not really a driver person, but if you're writing a new driver, >> > wouldn't you use the iomap interfaces (ioremap(), ioread32(), etc) >> > rather than readl()? >> >> That driver exists but it is not in mainline and it is better to directly >> add it to proper location with correct io functions. >> The question is if ioread/iowrite functions are correct one. >> PowerPC io-defs.h suggests that readl/writel should be used for PCI. >> >> >> >> Also just want to check if it is correct to use pcie device_type. >> > >> > I don't know what you're asking here. Can you elaborate or give a >> > specific example? >> >> If node property device_type pcie should be used. >> device_type = "pcie"; >> >> For pci it is device_type = "pci"; >> For network it is device_type = "network" >> the same for serial, watchdogs. >> >> Do we have any list of device_types which we should use? > > Don't use them unless a binding requires it. PCI address lookup code > uses it, so we put it in those nodes. Otherwise device_type is > deprecated and has been for a long time now. You should not be using it > in .dts files. Thanks, Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-next] i915: intel_set_mode: Reduce stack allocation from 500 bytes to 2 pointers
On Fri, 07 Dec 2012, Tim Gardner wrote:
> smatch warning:
>
> drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function puts
> 500 bytes on stack
>
> Refactor so that saved_mode and saved_hwmode are dynamically allocated as
> opposed
> to being automatic variables. 500 bytes seems like it could run the potential
> for blowing
> the kernel stack.
Reviewed-by: Jani Nikula
>
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Tim Gardner
> ---
>
> V2 - spaces around '*', use kmalloc instead of kzalloc(). Missed
> error return that would have orphaned memory.
>
> drivers/gpu/drm/i915/intel_display.c | 22 --
> 1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index de51489..c15b21b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7739,11 +7739,18 @@ bool intel_set_mode(struct drm_crtc *crtc,
> {
> struct drm_device *dev = crtc->dev;
> drm_i915_private_t *dev_priv = dev->dev_private;
> - struct drm_display_mode *adjusted_mode, saved_mode, saved_hwmode;
> + struct drm_display_mode *adjusted_mode, *saved_mode, *saved_hwmode;
> struct intel_crtc *intel_crtc;
> unsigned disable_pipes, prepare_pipes, modeset_pipes;
> bool ret = true;
>
> + saved_mode = kmalloc(2 * sizeof(*saved_mode), GFP_KERNEL);
> + if (!saved_mode) {
> + DRM_ERROR("i915: Could not allocate saved display mode.\n");
> + return false;
> + }
> + saved_hwmode = saved_mode + 1;
> +
> intel_modeset_affected_pipes(crtc, _pipes,
>_pipes, _pipes);
>
> @@ -7753,8 +7760,8 @@ bool intel_set_mode(struct drm_crtc *crtc,
> for_each_intel_crtc_masked(dev, disable_pipes, intel_crtc)
> intel_crtc_disable(_crtc->base);
>
> - saved_hwmode = crtc->hwmode;
> - saved_mode = crtc->mode;
> + *saved_hwmode = crtc->hwmode;
> + *saved_mode = crtc->mode;
>
> /* Hack: Because we don't (yet) support global modeset on multiple
>* crtcs, we don't keep track of the new mode for more than one crtc.
> @@ -7765,7 +7772,8 @@ bool intel_set_mode(struct drm_crtc *crtc,
> if (modeset_pipes) {
> adjusted_mode = intel_modeset_adjusted_mode(crtc, mode);
> if (IS_ERR(adjusted_mode)) {
> - return false;
> + ret = false;
> + goto out;
> }
> }
>
> @@ -7817,12 +7825,14 @@ bool intel_set_mode(struct drm_crtc *crtc,
> done:
> drm_mode_destroy(dev, adjusted_mode);
> if (!ret && crtc->enabled) {
> - crtc->hwmode = saved_hwmode;
> - crtc->mode = saved_mode;
> + crtc->hwmode = *saved_hwmode;
> + crtc->mode = *saved_mode;
> } else {
> intel_modeset_check_state(dev);
> }
>
> +out:
> + kfree(saved_mode);
> return ret;
> }
>
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] sound/soc/soc-core.c: drop kfree of devm_kzalloc's data
On Sat, Dec 08, 2012 at 07:01:20PM +0100, Julia Lawall wrote: > From: Julia Lawall > > Using kfree to free data allocated with devm_kzalloc causes double frees. Ugh, actually this doesn't merge down very well against -next at all, can you regenerate against current code please? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sound/soc/soc-core.c: drop kfree of devm_kzalloc's data
On Mon, Dec 10, 2012 at 07:10:16AM +0100, Julia Lawall wrote: > Sorry, I just resent the patch as is. 1 and 2 were I guess applied, > because I odn't findthe problem any more. It looks like this is what happened the first time round as well - I only got patch 3 but it was flagged as part of a three patch series. Please don't do things like this, it makes the patch look like part of a series which has already been applied but didn't get deleted when it's sitting in an inbox. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] cpufreq: cpufreq_governor.
On 10.12.2012 3:08, Rafael J. Wysocki wrote: > On Sunday, December 09, 2012 09:17:04 PM Ilya Zykov wrote: >> On 05.12.2012 22:53, Ilya Zykov wrote: >>> What do I do wrong? >>> >>> After: modprobe cpufreq_ondemand >>> I have: >>> >>> WARNING: Error inserting freq_table >>> (/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/freq_table.ko): >>> Unknown symbol in module, or unknown parameter (see dmesg) >>> FATAL: Error inserting cpufreq_ondemand >>> (/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/cpufreq_ondemand.ko): >>> Unknown symbol in module, or unknown parameter (see dmesg) >>> >>> dmesg: >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> __cpufreq_driver_getavg (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> sysfs_create_group (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> sysfs_remove_group (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> __cpufreq_driver_target (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> get_cpu_idle_time_us (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> delayed_work_timer_fn (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> get_cpu_iowait_time_us (err 0) >>> >>> cat /proc/kallsyms |grep freq_dr >>> 814976e0 T __cpufreq_driver_target >>> 814987e0 T __cpufreq_driver_getavg >>> 81498850 T cpufreq_driver_target >>> 81881650 r __ksymtab___cpufreq_driver_getavg >>> 81881660 r __ksymtab___cpufreq_driver_target >>> 81883b40 r __ksymtab_cpufreq_driver_target >>> 81894290 r __kcrctab___cpufreq_driver_getavg >>> 81894298 r __kcrctab___cpufreq_driver_target >>> 81895508 r __kcrctab_cpufreq_driver_target >>> 818b3080 r __kstrtab___cpufreq_driver_getavg >>> 818b3098 r __kstrtab_cpufreq_driver_target >>> 818b30ae r __kstrtab___cpufreq_driver_target >>> 81e240c8 b cpufreq_driver_lock >>> 81e240d0 b cpufreq_driver >>> a0c42000 d acpi_cpufreq_driver [acpi_cpufreq] >> >> I managed to fix: >> >> git checkout 16642a2e7be23bb -- drivers/cpufreq >> git checkout 250f6715a4112d668 -- include/linux/cpufreq.h > > Can you please send your .config? > > Rafael > > gcc --version gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/49] Automatic NUMA Balancing v10
* Srikar Dronamraju [2012-12-10 10:37:10]: > > > > Either way, last night I applied a patch on top of latest tip/master to > > remove the nr_cpus_allowed check so that numacore would be enabled again > > and tested that. In some places it has indeed much improved. In others > > it is still regressing badly and in two case, it's corrupting memory -- > > specjbb when THP is enabled crashes when running for single or multiple > > JVMs. It is likely that a zero page is being inserted due to a race with > > migration and causes the JVM to throw a null pointer exception. Here is > > the comparison on the rough off-chance you actually read it this time. > > I see this failure when running with THP and KSM enabled on > Friday's Tip master. Not sure if Mel was talking about the same issue. > Even occurs with !THP but KSM enabled. > [ cut here ] > kernel BUG at ../kernel/sched/fair.c:2371! > invalid opcode: [#1] SMP > Modules linked in: ebtable_nat ebtables autofs4 sunrpc cpufreq_ondemand > acpi_cpufreq freq_table mperf bridge stp llc iptable_filter ip_tables > ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack > ip6table_filter ip6_tables ipv6 vhost_net macvtap macvlan tun iTCO_wdt > iTCO_vendor_support kvm_intel kvm microcode cdc_ether usbnet mii serio_raw > i2c_i801 i2c_core lpc_ich mfd_core shpchp ioatdma i7core_edac edac_core bnx2 > sg ixgbe dca mdio ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase > scsi_transport_sas dm_mirror dm_region_hash dm_log dm_mod > CPU 4 > Pid: 116, comm: ksmd Not tainted 3.7.0-rc8-tip_master+ #5 IBM BladeCenter > HS22V -[7871AC1]-/81Y5995 > RIP: 0010:[] [] > task_numa_fault+0x1a9/0x1e0 > RSP: 0018:880372237ba8 EFLAGS: 00010246 > RAX: 0074 RBX: 0001 RCX: 0001 > RDX: 12ae RSI: 0004 RDI: 7faf4fc01000 > RBP: 880372237be8 R08: R09: 8803657463f0 > R10: 0001 R11: 0001 R12: 0012 > R13: 880372210d00 R14: 00010088 R15: > FS: () GS:88037fc8() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 01d26fec CR3: 0169f000 CR4: 27e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process ksmd (pid: 116, threadinfo 880372236000, task 880372210d00) > Stack: > ea0016026c58 7faf4fc0 880372237c48 0001 > 7faf4fc01000 ea000d6df928 0001 ea00166e9268 > 880372237c48 8113cd0e 88030001 0002 > Call Trace: > [] __do_numa_page+0xde/0x160 > [] handle_pte_fault+0x32e/0xcd0 > [] ? drop_large_spte+0x30/0x30 [kvm] > [] ? kvm_set_spte_hva+0x25/0x30 [kvm] > [] handle_mm_fault+0x279/0x760 > [] break_ksm+0x74/0xa0 > [] break_cow+0xa2/0xb0 > [] ksm_scan_thread+0xb5c/0xd50 > [] ? wake_up_bit+0x40/0x40 > [] ? run_store+0x340/0x340 > [] kthread+0xce/0xe0 > [] ? kthread_freezable_should_stop+0x70/0x70 > [] ret_from_fork+0x7c/0xb0 > [] ? kthread_freezable_should_stop+0x70/0x70 > Code: 89 f0 41 bf 01 00 00 00 8b 1c 10 e9 d7 fe ff ff 8d 14 09 48 63 d2 eb bd > 66 2e 0f 1f 84 00 00 00 00 00 49 8b 85 98 07 00 00 eb 91 <0f> 0b eb fe 80 3d > 9c 3b 6b 00 01 0f 84 be fe ff ff be 42 09 00 > RIP [] task_numa_fault+0x1a9/0x1e0 > RSP > ---[ end trace 9584c9b03fc0dbc0 ]--- > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] cpufreq: cpufreq_governor.
On 10.12.2012 3:08, Rafael J. Wysocki wrote: > On Sunday, December 09, 2012 09:17:04 PM Ilya Zykov wrote: >> On 05.12.2012 22:53, Ilya Zykov wrote: >>> What do I do wrong? >>> >>> After: modprobe cpufreq_ondemand >>> I have: >>> >>> WARNING: Error inserting freq_table >>> (/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/freq_table.ko): >>> Unknown symbol in module, or unknown parameter (see dmesg) >>> FATAL: Error inserting cpufreq_ondemand >>> (/lib/modules/3.7.0-rc8-next-20121205-ttybuf.1+/kernel/drivers/cpufreq/cpufreq_ondemand.ko): >>> Unknown symbol in module, or unknown parameter (see dmesg) >>> >>> dmesg: >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> __cpufreq_driver_getavg (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> sysfs_create_group (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> sysfs_remove_group (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> __cpufreq_driver_target (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> get_cpu_idle_time_us (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> delayed_work_timer_fn (err 0) >>> Dec 5 22:26:11 bm kernel: cpufreq_governor: Unknown symbol >>> get_cpu_iowait_time_us (err 0) >>> >>> cat /proc/kallsyms |grep freq_dr >>> 814976e0 T __cpufreq_driver_target >>> 814987e0 T __cpufreq_driver_getavg >>> 81498850 T cpufreq_driver_target >>> 81881650 r __ksymtab___cpufreq_driver_getavg >>> 81881660 r __ksymtab___cpufreq_driver_target >>> 81883b40 r __ksymtab_cpufreq_driver_target >>> 81894290 r __kcrctab___cpufreq_driver_getavg >>> 81894298 r __kcrctab___cpufreq_driver_target >>> 81895508 r __kcrctab_cpufreq_driver_target >>> 818b3080 r __kstrtab___cpufreq_driver_getavg >>> 818b3098 r __kstrtab_cpufreq_driver_target >>> 818b30ae r __kstrtab___cpufreq_driver_target >>> 81e240c8 b cpufreq_driver_lock >>> 81e240d0 b cpufreq_driver >>> a0c42000 d acpi_cpufreq_driver [acpi_cpufreq] >> >> I managed to fix: >> >> git checkout 16642a2e7be23bb -- drivers/cpufreq >> git checkout 250f6715a4112d668 -- include/linux/cpufreq.h > > Can you please send your .config? > > Rafael > > CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_EXPERIMENTAL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="-debtty.1" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_FHANDLE=y CONFIG_HAVE_GENERIC_HARDIRQS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_TICK_CPU_ACCOUNTING=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TREE_RCU=y CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 CONFIG_LOG_BUF_SHIFT=20 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_NUMA_GENERIC_PGPROT=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y
Re: linux-next: manual merge of the arm-soc tree with the sound-asoc tree
On Sun, Dec 9, 2012 at 10:40 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/plat-samsung/include/plat/devs.h between commit a08485d8fdf6
> ("ASoC: Samsung: Do not register samsung audio dma device as pdev") from
> the sound-asoc tree and commit 0a9d5ac307ae ("ARM: EXYNOS: removing
> exynos-drm device registration from non-dt platforms") from the arm-soc
> tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good, thanks.
-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 3/7] uprobes: Kill the pointless inode/uc checks in register/unregister
* Oleg Nesterov [2012-11-23 21:28:06]:
> register/unregister verifies that inode/uc != NULL. For what?
> This really looks like "hide the potential problem", the caller
> should pass the valid data.
>
Agree that users should pass valid data.
I do understand that we expect the users to be knowledge-able.
Also users are routed thro in-kernel api that does this check.
However from an api perspective, if a user passes invalid data, do we
want the system to crash.
Esp if kernel can identify that users has indeed passed wrong info. I do agree
that users can still pass invalid data that kernel maynot be able to
identify in most cases.
> register() also checks uc->next == NULL, probably to prevent the
> double-register but the caller can do other stupid/wrong things.
Users can surely do more stupid things. But this is again something that
kernel can identify. By allowing a double-register of a consumer, thats
already registered, we might end up allowing circular loop of consumers.
> If we do this check, then we should document that uc->next should
> be cleared before register() and add BUG_ON().
>
> Also add the small comment about the i_size_read() check.
>
> Signed-off-by: Oleg Nesterov
> ---
> kernel/events/uprobes.c |7 +--
> 1 files changed, 1 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 13b247c..d8e930a 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -844,9 +844,7 @@ int uprobe_register(struct inode *inode, loff_t offset,
> struct uprobe_consumer *
> struct uprobe *uprobe;
> int ret;
>
> - if (!inode || !uc || uc->next)
> - return -EINVAL;
> -
> + /* Racy, just to catch the obvious mistakes */
> if (offset > i_size_read(inode))
> return -EINVAL;
>
> @@ -883,9 +881,6 @@ void uprobe_unregister(struct inode *inode, loff_t
> offset, struct uprobe_consume
> {
> struct uprobe *uprobe;
>
> - if (!inode || !uc)
> - return;
> -
> uprobe = find_uprobe(inode, offset);
> if (!uprobe)
> return;
> --
> 1.5.5.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 7/7] fs, notify: Add procfs fdinfo helper v6
On Mon, Dec 10, 2012 at 03:21:53AM +0100, Jan Engelhardt wrote: > > On Saturday 2012-11-17 00:56, Andrew Morton wrote: > >> | pos:0 > >> | flags: 0200 > >> | inotify wd:3 ino: 9e7e > >> | inotify wd:2 ino: a111 > >> | inotify wd:1 ino:6b149[...] > > > >This is a lousy output format. It's sort-of like a sensible set of > >name-value tuples: "name:value name:value name:value" but > > > >c) inotify-wd is secretly printed in decimal while everything else > > is in hex. Hi Jan, not secretly, actually, the patch for documentation in -mm tree, where the format is described. > > > >What happens if we do something like the below (which will require a > >changelog update)? It's already there :) Andrew pointed to same nit and we've updated the format. The final one, which sits in -mm is ret = seq_printf(m, "fhandle-bytes:%x fhandle-type:%x f_handle:", f.handle.handle_bytes, f.handle.handle_type); > > > >@@ -59,7 +59,7 @@ static int show_mark_fhandle(struct seq_ > > f.handle.handle_type = ret; > > f.handle.handle_bytes = size * sizeof(u32); > > > >-ret = seq_printf(m, "fhandle-bytes: %8x fhandle-type: %8x f_handle: ", > >+ret = seq_printf(m, "fhandle-bytes:%x fhandle-type:%x f_handle:", > > f.handle.handle_bytes, f.handle.handle_type); > > Why don't we actually make sure to print a 0x prefix when it's hex > and 0 on octal? Then it should be clear what base these lines are in. > (That would also be a good idea for the rest of procfs files, but I > reckon they cannot be easily changed.) Sounds good for me. If Andrew won't mind I'll update. Cyrill -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/3] regulator: max77686: Add support for various operating modes
On Mon, Dec 10, 2012 at 11:56:23AM +0530, Abhilash Kesavan wrote:
> + if (of_property_read_u32(rdata[i].of_node, "max77686-opmode",
> + [i].opmode)) {
> + dev_warn(iodev->dev, "no op_mode property property at
> %s\n",
> + rmatch.name);
> + rdata[i].opmode = regulators[i].enable_mask;
> + }
Binding documenation is mandatory for any new OF properties, please add
this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] mtd: nand: omap2: Update nerrors using ecc.strength
On Fri, Dec 07, 2012 at 16:10:04, Nori, Sekhar wrote: > On 12/5/2012 6:13 PM, Philip, Avinash wrote: > > On Wed, Dec 05, 2012 at 17:33:37, Nori, Sekhar wrote: > >> Hi Avinash, > >> > >> On 11/29/2012 5:16 PM, Philip, Avinash wrote: > >>> Update number of errors using nand ecc strength. > >>> Also add macro definitions BCH8_ERROR_MAX & BCH4_ERROR_MAX > >> > >> Can you please describe why the original method of setting nerrors was > >> incorrect? Was it causing any issues in any particular configuration? > > > > It affects the reusability of the code. For example BCH8 with AM335x RBL > > compatibility requires 14 bytes instead of 13 byte. So setting nerrors > > with > > nerrors = (info->nand.ecc.bytes == 13) ? 8 : 4; > > will break am335x RBL compatibility. > > This should be summarized in the patch description so the motivation is > clear to those who read the history later. Ok I will add the details in patch description in next version. Thanks Avinash > > Thanks, > Sekhar >
RE: linux-next: manual merge of the net-next tree with the pci tree
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/wireless/iwlwifi/pcie/trans.c between commit b9d146e30a2d
> ("iwlwifi: collapse wrapper for pcie_capability_read_word()") from the pci
> tree and commit 7afe3705cd4e ("iwlwifi: continue clean up -
> pcie/trans.c") from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action is
> required).
>
Looks right - thanks Stephen!
-
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 2/3] mtd: devices: elm: Add support for ELM error correction
On Fri, Dec 07, 2012 at 16:07:23, Nori, Sekhar wrote:
> On 11/29/2012 5:16 PM, Philip, Avinash wrote:
> > The ELM hardware module can be used to speedup BCH 4/8/16 ECC scheme
> > error correction.
> > For now only 4 & 8 bit support is added
> >
> > Signed-off-by: Philip, Avinash
> > Cc: Grant Likely
> > Cc: Rob Herring
> > Cc: Rob Landley
[...]
/**
> > + * elm_config - Configure ELM module
> > + * @info: elm info
> > + */
> > +static void elm_config(struct elm_info *info)
>
> This is called "config", but there is no configuration information
> passed which looks odd..
The config information is bch_type, encapsulated in struct elm_info.
>
> > +{
> > + u32 reg_val;
> > +
> > + reg_val = (info->bch_type & ECC_BCH_LEVEL_MASK) | (ELM_ECC_SIZE << 16);
> > + elm_write_reg(info, ELM_LOCATION_CONFIG, reg_val);
> > +}
>
> Is there a use case where BCH type needs to be changed after NAND has
> been probed?
No, I think kernel handles the entire NAND part with a single ecc layout.
Hence there is no run time BCH switching. But ELM driver should support BCH
4 & 8. Selection of BCH information comes from DT of NAND driver.
As NAND driver supporting BCH4 & 8 ecc scheme ELM module support
configuration of both. Configuration of ELM module should done as part
of NAND driver probing.
> You will have to erase any existing data written to NAND if
> you change the ECC type. That sounds destructive enough to avoid such a
> thing.
There is no support for BCH switching after NAND driver probing.
[...]
> > +struct device *elm_request(enum bch_ecc bch_type)
> > +{
> > + struct elm_info *info;
> > +
> > + list_for_each_entry(info, _devices, list) {
> > + if (info && info->dev) {
> > + info->bch_type = bch_type;
> > + elm_config(info);
> > + return info->dev;
> > + }
> > + }
>
> This will always return the first ELM device probed since you never
> remove the allocated device from the list.
But now I realized that, there is no mechanism of freeing the requested
resource.
So I will add mechanism to request ELM module successfully only if ELM
module is not requested already and add mechanism to free it, on NAND
driver module unload (loadable module support). This way ELM driver
can achieve multi instance support.
> I wonder why you really need a list?
The prime motivation for the list is the driver should support multi
instances of ELM by removing global symbols.
Thanks
Avinash
>
> Thanks,
> Sekhar
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
linux-next: manual merge of the arm-soc tree with the sound-asoc tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/plat-samsung/include/plat/devs.h between commit a08485d8fdf6
("ASoC: Samsung: Do not register samsung audio dma device as pdev") from
the sound-asoc tree and commit 0a9d5ac307ae ("ARM: EXYNOS: removing
exynos-drm device registration from non-dt platforms") from the arm-soc
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/plat-samsung/include/plat/devs.h
index c45f70c,f53beba..000
--- a/arch/arm/plat-samsung/include/plat/devs.h
+++ b/arch/arm/plat-samsung/include/plat/devs.h
@@@ -133,8 -132,7 +132,6 @@@ extern struct platform_device exynos4_d
extern struct platform_device exynos4_device_pcm2;
extern struct platform_device exynos4_device_spdif;
- extern struct platform_device exynos_device_drm;
-
-extern struct platform_device samsung_asoc_dma;
extern struct platform_device samsung_asoc_idma;
extern struct platform_device samsung_device_keypad;
pgpFDABxnel6H.pgp
Description: PGP signature
Re: [PATCH 2/7] uprobes: Kill the "uprobe != NULL" check in uprobe_unregister()
* Oleg Nesterov [2012-11-23 21:28:02]: > Trivial. uprobe can't be NULL after mutex_unlock(), it was already used. > > Signed-off-by: Oleg Nesterov Acked-by: Srikar Dronamraju > --- > kernel/events/uprobes.c |3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > index e9f22ed..13b247c 100644 > --- a/kernel/events/uprobes.c > +++ b/kernel/events/uprobes.c > @@ -900,8 +900,7 @@ void uprobe_unregister(struct inode *inode, loff_t > offset, struct uprobe_consume > } > > mutex_unlock(uprobes_hash(inode)); > - if (uprobe) > - put_uprobe(uprobe); > + put_uprobe(uprobe); > } > > static struct rb_node * > -- > 1.5.5.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 -next] drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()
> -Original Message- > From: 김승우 [mailto:sw0312@samsung.com] > Sent: Monday, December 10, 2012 3:14 PM > To: Wei Yongjun > Cc: inki@samsung.com; jy0922.s...@samsung.com; > kyungmin.p...@samsung.com; airl...@linux.ie; yongjun_...@trendmicro.com.cn; > linux-kernel@vger.kernel.org; dri-de...@lists.freedesktop.org; > sw0312@samsung.com > Subject: Re: [PATCH -next] drm/exynos/iommu: fix return value check in > drm_create_iommu_mapping() > > > > On 2012년 12월 07일 21:50, Wei Yongjun wrote: > > From: Wei Yongjun > > > > In case of error, function arm_iommu_create_mapping() returns > > ERR_PTR() and never returns NULL. The NULL test in the return > > value check should be replaced with IS_ERR(). > > > > Signed-off-by: Wei Yongjun > > --- > > drivers/gpu/drm/exynos/exynos_drm_iommu.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c > b/drivers/gpu/drm/exynos/exynos_drm_iommu.c > > index 09db198..3b3d3a6 100644 > > --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c > > +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c > > @@ -56,7 +56,7 @@ int drm_create_iommu_mapping(struct drm_device > *drm_dev) > > mapping = arm_iommu_create_mapping(_bus_type, priv- > >da_start, > > priv->da_space_size, > > priv->da_space_order); > > - if (!mapping) > > + if (IS_ERR(mapping)) > > return -ENOMEM; > > One more fix is needed here. > - return -ENOMEM; > + return PTR_ERR(mapping); Oh, good point, I missed. Please re-send it. Thanks, Inki Dae > > > > > dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms), > > > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Seung-Woo Kim > Samsung Software R Center > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] uprobes: Move __set_bit(UPROBE_SKIP_SSTEP) into alloc_uprobe()
> Cosmetic. __set_bit(UPROBE_SKIP_SSTEP) is the part of initialization, > it is not clear why it is set in insert_uprobe(). > > Signed-off-by: Oleg Nesterov Acked-by: Srikar Dronamraju > --- > kernel/events/uprobes.c |5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > index 5e22faf..e9f22ed 100644 > --- a/kernel/events/uprobes.c > +++ b/kernel/events/uprobes.c > @@ -430,9 +430,6 @@ static struct uprobe *insert_uprobe(struct uprobe *uprobe) > u = __insert_uprobe(uprobe); > spin_unlock(_treelock); > > - /* For now assume that the instruction need not be single-stepped */ > - __set_bit(UPROBE_SKIP_SSTEP, >flags); > - > return u; > } > > @@ -454,6 +451,8 @@ static struct uprobe *alloc_uprobe(struct inode *inode, > loff_t offset) > uprobe->offset = offset; > init_rwsem(>consumer_rwsem); > mutex_init(>copy_mutex); > + /* For now assume that the instruction need not be single-stepped */ > + __set_bit(UPROBE_SKIP_SSTEP, >flags); > > /* add to uprobes_tree, sorted on inode:offset */ > cur_uprobe = insert_uprobe(uprobe); > -- > 1.5.5.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/
Serial8250 doesn't populate in /proc/iomem?
Hi, list I found some io memory information is lost from /dev/iomem and want to find out why. I have a 2.6.16 kernel running on a ARM board (Samsung S3C2410). From the kernel log, I see 16 8250 serial ports were detected, and each of thoese ports has a memory address: Serial: 8250/16550 driver $Revision: 1.90 $ 16 ports, IRQ sharing enabled serial8250: tts0 at MMIO 0xe140 (irq = 16) is a 16550A serial8250: tts1 at MMIO 0xe148 (irq = 16) is a 16550A serial8250: tts2 at MMIO 0xe1400010 (irq = 17) is a 16550A serial8250: tts3 at MMIO 0xe1400018 (irq = 17) is a 16550A serial8250: tts4 at MMIO 0xe1400020 (irq = 18) is a 16550A serial8250: tts5 at MMIO 0xe1400028 (irq = 18) is a 16550A serial8250: tts6 at MMIO 0xe1400030 (irq = 19) is a 16550A serial8250: tts7 at MMIO 0xe1400038 (irq = 19) is a 16550A serial8250: tts8 at MMIO 0xe1400040 (irq = 48) is a 16550A serial8250: tts9 at MMIO 0xe1400048 (irq = 48) is a 16550A serial8250: tts10 at MMIO 0xe1400050 (irq = 49) is a 16550A serial8250: tts11 at MMIO 0xe1400058 (irq = 49) is a 16550A serial8250: tts12 at MMIO 0xe1400060 (irq = 60) is a 16550A serial8250: tts13 at MMIO 0xe1400068 (irq = 60) is a 16550A serial8250: tts14 at MMIO 0xe1400070 (irq = 61) is a 16550A serial8250: tts15 at MMIO 0xe1400078 (irq = 61) is a 16550A I can read/write these serial ports from /dev/ttys*, in other words, they do exist. I also can find the driver info from /proc/devices: Character devices: ... 4 /dev/vc/0 4 tty 4 tts 5 /dev/tty 5 /dev/console 5 /dev/ptmx 7 vcs ... The problem is, I don't understand why there is no information about these ports in /proc/iomem file. The 'iomem' file now contains: 1100-11000ffe : AX88796B 1900-19000ffe : AX88796B 3000-33ff : System RAM 3001c000-301e826b : Kernel text 301ea000-302234a3 : Kernel data 4900-490f : s3c2410-ohci 4900-490f : ohci_hcd 4e00-4e0f : s3c2410-nand 4e00-4e0f : s3c2410-nand 5000-50003fff : s3c2410-uart.0 5000-50ff : s3c2410-uart 50004000-50007fff : s3c2410-uart.1 50004000-500040ff : s3c2410-uart 50008000-5000bfff : s3c2410-uart.2 50008000-500080ff : s3c2410-uart 5300-530f : s3c2410-wdt 5400-540f : s3c2410-i2c 5a00-5a0f : s3c2410-sdi 5a00-5a0f : mmci-s3c2410 You see, there is no serial8250 informations. Can anyone here please tell me how this can happen? Does it mean the serial8250 driver don't populate or register in the /proc/iomem? -- woody I can't go back to yesterday - because I was a different person then. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/3] regulator: max77686: Add support for various operating modes
Currently, we cannot specify the regulator suspend state via device
tree. Add an optional operating mode property which can be used to
set initially the regulator mode.
We are currently bypassing the set_suspend_disable and set_suspend_mode
call-backs.
Signed-off-by: Abhilash Kesavan
---
drivers/regulator/max77686.c | 11 ++-
include/linux/mfd/max77686.h |1 +
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
index b85040c..7f16bc7 100644
--- a/drivers/regulator/max77686.c
+++ b/drivers/regulator/max77686.c
@@ -410,6 +410,12 @@ static int max77686_pmic_dt_parse_pdata(struct
max77686_dev *iodev,
of_regulator_match(iodev->dev, regulators_np, , 1);
rdata[i].initdata = rmatch.init_data;
rdata[i].of_node = rmatch.of_node;
+ if (of_property_read_u32(rdata[i].of_node, "max77686-opmode",
+ [i].opmode)) {
+ dev_warn(iodev->dev, "no op_mode property property at
%s\n",
+ rmatch.name);
+ rdata[i].opmode = regulators[i].enable_mask;
+ }
}
pdata->regulators = rdata;
@@ -465,7 +471,10 @@ static int max77686_pmic_probe(struct platform_device
*pdev)
config.init_data = pdata->regulators[i].initdata;
config.of_node = pdata->regulators[i].of_node;
- max77686->opmode[i] = regulators[i].enable_mask;
+ if (config.of_node)
+ max77686->opmode[i] = pdata->regulators[i].opmode;
+ else
+ max77686->opmode[i] = regulators[i].enable_mask;
max77686->rdev[i] = regulator_register([i], );
if (IS_ERR(max77686->rdev[i])) {
ret = PTR_ERR(max77686->rdev[i]);
diff --git a/include/linux/mfd/max77686.h b/include/linux/mfd/max77686.h
index 46c0f32..e8bd83b 100644
--- a/include/linux/mfd/max77686.h
+++ b/include/linux/mfd/max77686.h
@@ -73,6 +73,7 @@ enum max77686_regulators {
struct max77686_regulator_data {
int id;
+ int opmode;
struct regulator_init_data *initdata;
struct device_node *of_node;
};
--
1.7.8.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/
[RFC PATCH 3/3] dt: Document: Add optional MAX77686 operating mode bindings
Add documenatation for various operating mode capabilities of the MAX77686 PMIC. Signed-off-by: Abhilash Kesavan --- Documentation/devicetree/bindings/mfd/max77686.txt |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt b/Documentation/devicetree/bindings/mfd/max77686.txt index c6a3469..f2867a9 100644 --- a/Documentation/devicetree/bindings/mfd/max77686.txt +++ b/Documentation/devicetree/bindings/mfd/max77686.txt @@ -13,6 +13,12 @@ Required properties: - interrupts : This i2c device has an IRQ line connected to the main SoC. - interrupt-parent : The parent interrupt controller. +optional properties: +- max77686-opmode : The regulators of max77686 have various operating mode + capabilities such as low power mode, standby mode (controlled by PWRREQ + signal) etc. Check the regulator CTRL register for the bits setting these + modes. + Optional node: - voltage-regulators : The regulators of max77686 have to be instantiated under subnode named "voltage-regulators" using the following format. -- 1.7.8.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/
[RFC PATCH 1/3] ARM: DTS: CROS5250: Add regulator operating mode bindings
Some of the LDOs and BUCKs on the MAX77686 PMIC can be put into a
low power or standby state. Add bindings to control the operating
mode. This results in significant power savings during suspend.
Signed-off-by: Abhilash Kesavan
---
arch/arm/boot/dts/cros5250-common.dtsi | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/cros5250-common.dtsi
b/arch/arm/boot/dts/cros5250-common.dtsi
index 98ff65b..10d1812 100644
--- a/arch/arm/boot/dts/cros5250-common.dtsi
+++ b/arch/arm/boot/dts/cros5250-common.dtsi
@@ -35,6 +35,8 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
+ /* Output ON/LPM controlled by PWRREQ */
+ max77686-opmode = <0x40>;
};
ldo2_reg: LDO2 {
@@ -42,6 +44,8 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
+ /* Output ON/OFF controlled by PWRREQ */
+ max77686-opmode = <0x20>;
};
ldo3_reg: LDO3 {
@@ -49,6 +53,8 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
+ /* Output ON/LPM controlled by PWRREQ */
+ max77686-opmode = <0x80>;
};
ldo7_reg: LDO7 {
@@ -56,6 +62,8 @@
regulator-min-microvolt = <110>;
regulator-max-microvolt = <110>;
regulator-always-on;
+ /* Output ON/OFF controlled by PWRREQ */
+ max77686-opmode = <0x40>;
};
ldo8_reg: LDO8 {
@@ -63,6 +71,8 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
+ /* Output ON/OFF controlled by PWRREQ */
+ max77686-opmode = <0x40>;
};
ldo10_reg: LDO10 {
@@ -70,6 +80,8 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
+ /* Output ON/OFF controlled by PWRREQ */
+ max77686-opmode = <0x40>;
};
ldo12_reg: LDO12 {
@@ -77,6 +89,8 @@
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
regulator-always-on;
+ /* Output ON/OFF controlled by PWRREQ */
+ max77686-opmode = <0x40>;
};
ldo14_reg: LDO14 {
@@ -84,6 +98,8 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
regulator-always-on;
+ /* Output ON/OFF controlled by PWRREQ */
+ max77686-opmode = <0x40>;
};
ldo15_reg: LDO15 {
@@ -91,6 +107,8 @@
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
regulator-always-on;
+ /* Output ON/OFF controlled by PWRREQ */
+ max77686-opmode = <0x40>;
};
ldo16_reg: LDO16 {
@@ -98,6 +116,8 @@
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
[RFC PATCH 0/3] Add MAX77686 Operating mode support
Currently, we cannot specify the regulator suspend state via device tree. Rather than adding suspend state/mode/enable/disable properties add an optional MAX77686 operating mode property which can be used to set the regulator mode initially. We are currently bypassing the set_suspend_disable and set_suspend_mode call-backs. Please review and suggest improvements. This is based on git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git : for-next merged with git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git : for-next Abhilash Kesavan (3): ARM: DTS: CROS5250: Add regulator operating mode bindings regulator: max77686: Add support for various operating modes dt: Document: Add optional MAX77686 operating mode bindings Documentation/devicetree/bindings/mfd/max77686.txt |6 +++ arch/arm/boot/dts/cros5250-common.dtsi | 36 drivers/regulator/max77686.c | 11 +- include/linux/mfd/max77686.h |1 + 4 files changed, 53 insertions(+), 1 deletions(-) -- 1.7.8.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 -next] drm/exynos/iommu: fix return value check in drm_create_iommu_mapping()
On 2012년 12월 07일 21:50, Wei Yongjun wrote: > From: Wei Yongjun > > In case of error, function arm_iommu_create_mapping() returns > ERR_PTR() and never returns NULL. The NULL test in the return > value check should be replaced with IS_ERR(). > > Signed-off-by: Wei Yongjun > --- > drivers/gpu/drm/exynos/exynos_drm_iommu.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c > b/drivers/gpu/drm/exynos/exynos_drm_iommu.c > index 09db198..3b3d3a6 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c > @@ -56,7 +56,7 @@ int drm_create_iommu_mapping(struct drm_device *drm_dev) > mapping = arm_iommu_create_mapping(_bus_type, priv->da_start, > priv->da_space_size, > priv->da_space_order); > - if (!mapping) > + if (IS_ERR(mapping)) > return -ENOMEM; One more fix is needed here. - return -ENOMEM; + return PTR_ERR(mapping); > > dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms), > > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Seung-Woo Kim Samsung Software R Center -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] sound/soc/soc-core.c: drop kfree of devm_kzalloc's data
On Mon, 10 Dec 2012, Mark Brown wrote: On Sat, Dec 08, 2012 at 07:01:20PM +0100, Julia Lawall wrote: The kfrees were introduced in b761c0ca. I sent this a few months ago, and I still think it should be applied... I'm missing patches 1 and 2? Sorry, I just resent the patch as is. 1 and 2 were I guess applied, because I odn't findthe problem any more. 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] Document how capability bits work
Quoting Rob Landley (r...@landley.net): > The fact that you need multiple sets of capabilities per process > (permitted, inheritable, effective), plus MORE sets (plural) of > capabilities attached to executable files, plus the "capability > bounding set" which is presumably so selinux can mess with it, plus The bounding set was in large part a workaround for the absence of the user namespace (and, at the time, the devices cgroup). (Now libcap-ng uses it to try and make capabilities generally easier to use.) -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/3]virtio_console: Add rproc_serial driver
On (Thu) 08 Nov 2012 [10:06:24], Amit Shah wrote: > On (Tue) 30 Oct 2012 [09:51:50], Sjur Brændeland wrote: > > From: Sjur Brændeland > > > > This patch-set introduces a new virtio type "rproc_serial" for communicating > > with remote processors over shared memory. The driver depends on the > > the remoteproc framework. As preparation for introducing "rproc_serial" > > I've done a refactoring of the transmit buffer handling. > > Thanks, Sjur. > > Please pick the virtio spec from > > https://github.com/rustyrussell/virtio-spec > > and update the spec with info for remote-proc. Hi Sjur, I didn't hear back from you on this.. Amit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v9 3/3] 1/1] virtio_console: Remove buffers from out_vq at port removal
On (Fri) 16 Nov 2012 [11:22:09], Rusty Russell wrote: > Amit Shah writes: > > From: Sjur Brændeland > > > > Remove buffers from the out-queue when a port is removed. Rproc_serial > > communicates with remote processors that may crash and leave buffers in > > the out-queue. The virtio serial ports may have buffers in the out-queue > > as well, e.g. for non-blocking ports and the host didn't consume them > > yet. > > > > [Amit: Remove WARN_ON for generic ports case.] > > > > Signed-off-by: Sjur Brændeland > > Signed-off-by: Amit Shah > > I already have this in my pending queue; I've promoted it to my > virtio-next branch now. Rusty, I still see this series in your pending queue, not in virtio-next. Did anything change in the meantime? Amit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v3 3/7] rtc: DA9055 RTC driver
On Wed, 2012-11-28 at 14:54 +0530, Ashish Jangam wrote:
> On Tue, 2012-11-27 at 14:23 -0800, Andrew Morton wrote:
> > On Fri, 23 Nov 2012 15:41:03 +0530
> > Ashish Jangam wrote:
> >
> > > On Tue, 2012-10-23 at 15:33 +0530, Ashish Jangam wrote:
> > > > Does this patch looks good?
> > > > On Thu, 2012-10-11 at 16:10 +0530, Ashish Jangam wrote:
> > > > > This is the RTC patch for the DA9055 PMIC. This patch has got
> > > > > dependency on
> > > > > the DA9055 MFD core.
> > > > >
> > > > > This patch is functionally tested on Samsung SMDKV6410.
> >
> > "shubhro " made a comment, but it was ignored:
> >
> > : On Thu, 11 Oct 2012 16:53:34 +0530
> > : shubhro wrote:
> > :
> > : > On Thursday 11 October 2012 04:10 PM, Ashish Jangam wrote:
> > : > > +#define da9055_rtc_freeze NULL
> > : > > +#endif
> > : > > +
> > : > > +static const struct dev_pm_ops da9055_rtc_pm_ops = {
> > : > > + .suspend = da9055_rtc_suspend,
> > : > > + .resume = da9055_rtc_resume,
> > : > > +
> > : > > + .freeze = da9055_rtc_freeze,
> > : > > + .thaw = da9055_rtc_resume,
> > : > > + .restore = da9055_rtc_resume,
> > : > > +
> > : > > + .poweroff = da9055_rtc_suspend,
> > : > > +};
> > : > You may want to use simple dev pm ops
> To support generic PM ops these additional ops were supported.
Are there any further comments on this patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/49] Automatic NUMA Balancing v10
> > Either way, last night I applied a patch on top of latest tip/master to > remove the nr_cpus_allowed check so that numacore would be enabled again > and tested that. In some places it has indeed much improved. In others > it is still regressing badly and in two case, it's corrupting memory -- > specjbb when THP is enabled crashes when running for single or multiple > JVMs. It is likely that a zero page is being inserted due to a race with > migration and causes the JVM to throw a null pointer exception. Here is > the comparison on the rough off-chance you actually read it this time. I see this failure when running with THP and KSM enabled on Friday's Tip master. Not sure if Mel was talking about the same issue. [ cut here ] kernel BUG at ../kernel/sched/fair.c:2371! invalid opcode: [#1] SMP Modules linked in: ebtable_nat ebtables autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bridge stp llc iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 vhost_net macvtap macvlan tun iTCO_wdt iTCO_vendor_support kvm_intel kvm microcode cdc_ether usbnet mii serio_raw i2c_i801 i2c_core lpc_ich mfd_core shpchp ioatdma i7core_edac edac_core bnx2 sg ixgbe dca mdio ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase scsi_transport_sas dm_mirror dm_region_hash dm_log dm_mod CPU 4 Pid: 116, comm: ksmd Not tainted 3.7.0-rc8-tip_master+ #5 IBM BladeCenter HS22V -[7871AC1]-/81Y5995 RIP: 0010:[] [] task_numa_fault+0x1a9/0x1e0 RSP: 0018:880372237ba8 EFLAGS: 00010246 RAX: 0074 RBX: 0001 RCX: 0001 RDX: 12ae RSI: 0004 RDI: 7faf4fc01000 RBP: 880372237be8 R08: R09: 8803657463f0 R10: 0001 R11: 0001 R12: 0012 R13: 880372210d00 R14: 00010088 R15: FS: () GS:88037fc8() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 01d26fec CR3: 0169f000 CR4: 27e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process ksmd (pid: 116, threadinfo 880372236000, task 880372210d00) Stack: ea0016026c58 7faf4fc0 880372237c48 0001 7faf4fc01000 ea000d6df928 0001 ea00166e9268 880372237c48 8113cd0e 88030001 0002 Call Trace: [] __do_numa_page+0xde/0x160 [] handle_pte_fault+0x32e/0xcd0 [] ? drop_large_spte+0x30/0x30 [kvm] [] ? kvm_set_spte_hva+0x25/0x30 [kvm] [] handle_mm_fault+0x279/0x760 [] break_ksm+0x74/0xa0 [] break_cow+0xa2/0xb0 [] ksm_scan_thread+0xb5c/0xd50 [] ? wake_up_bit+0x40/0x40 [] ? run_store+0x340/0x340 [] kthread+0xce/0xe0 [] ? kthread_freezable_should_stop+0x70/0x70 [] ret_from_fork+0x7c/0xb0 [] ? kthread_freezable_should_stop+0x70/0x70 Code: 89 f0 41 bf 01 00 00 00 8b 1c 10 e9 d7 fe ff ff 8d 14 09 48 63 d2 eb bd 66 2e 0f 1f 84 00 00 00 00 00 49 8b 85 98 07 00 00 eb 91 <0f> 0b eb fe 80 3d 9c 3b 6b 00 01 0f 84 be fe ff ff be 42 09 00 RIP [] task_numa_fault+0x1a9/0x1e0 RSP ---[ end trace 9584c9b03fc0dbc0 ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] ACPI: Replace struct acpi_bus_ops with enum type
On Sun, Dec 9, 2012 at 3:03 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Notice that one member of struct acpi_bus_ops, acpi_op_add, is not > used anywhere any more and the relationship between its remaining > members, acpi_op_match and acpi_op_start, is such that it doesn't > make sense to set the latter without setting the former at the same > time. Therefore, replace struct acpi_bus_ops with new a enum type, > enum acpi_bus_add_type, with three values, ACPI_BUS_ADD_BASIC, > ACPI_BUS_ADD_MATCH, ACPI_BUS_ADD_START, corresponding to > both acpi_op_match and acpi_op_start unset, acpi_op_match set and > acpi_op_start unset, and both acpi_op_match and acpi_op_start set, > respectively. > Can we expand the BUS_ADD_* concept to other devices instead of just acpi_device? aka we should let struct device has this add_type field. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/4] MAINTAINERS: add LP8788 MFD driver entry
Cc: Anton Vorontsov Cc: Bryan Wu Cc: Jonathan Cameron Cc: Mark Brown Cc: Samuel Ortiz Signed-off-by: Milo(Woogyom) Kim --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ee7e9ee..9339a4b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7570,6 +7570,16 @@ S: Maintained F: drivers/regulator/lp872x.c F: include/linux/regulator/lp872x.h +TI LP8788 MFD DRIVER +M: Milo Kim +S: Maintained +F: drivers/iio/adc/lp8788_adc.c +F: drivers/leds/leds-lp8788.c +F: drivers/mfd/lp8788*.c +F: drivers/power/lp8788-charger.c +F: drivers/regulator/lp8788-*.c +F: include/linux/mfd/lp8788*.h + TI TWL4030 SERIES SOC CODEC DRIVER M: Peter Ujfalusi L: alsa-de...@alsa-project.org (moderated for non-subscribers) -- 1.7.9.5 Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] MAINTAINERS: add LP8727 charger driver entry
Cc: Anton Vorontsov Cc: David Woodhouse Signed-off-by: Milo(Woogyom) Kim --- MAINTAINERS |6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 92fa7e5..a5aedda 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7558,6 +7558,12 @@ F: Documentation/backlight/lp855x-driver.txt F: drivers/video/backlight/lp855x_bl.c F: include/linux/platform_data/lp855x.h +TI LP8727 CHARGER DRIVER +M: Milo Kim +S: Maintained +F: drivers/power/lp8727_charger.c +F: include/linux/platform_data/lp8727.h + TI TWL4030 SERIES SOC CODEC DRIVER M: Peter Ujfalusi L: alsa-de...@alsa-project.org (moderated for non-subscribers) -- 1.7.9.5 Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] MAINTAINERS: add LP872x regulator driver entry
Cc: Liam Girdwood Cc: Mark Brown Signed-off-by: Milo(Woogyom) Kim --- MAINTAINERS |6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index a5aedda..ee7e9ee 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7564,6 +7564,12 @@ S: Maintained F: drivers/power/lp8727_charger.c F: include/linux/platform_data/lp8727.h +TI LP872X REGULATOR DRIVER +M: Milo Kim +S: Maintained +F: drivers/regulator/lp872x.c +F: include/linux/regulator/lp872x.h + TI TWL4030 SERIES SOC CODEC DRIVER M: Peter Ujfalusi L: alsa-de...@alsa-project.org (moderated for non-subscribers) -- 1.7.9.5 Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] MAINTAINERS: add LP855x backlight driver entry
Cc: Andrew Morton Cc: Richard Purdie Signed-off-by: Milo(Woogyom) Kim --- MAINTAINERS |7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8110ccd..92fa7e5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7551,6 +7551,13 @@ S: Maintained F: sound/soc/codecs/lm49453* F: sound/soc/codecs/isabelle* +TI LP855x BACKLIGHT DRIVER +M: Milo Kim +S: Maintained +F: Documentation/backlight/lp855x-driver.txt +F: drivers/video/backlight/lp855x_bl.c +F: include/linux/platform_data/lp855x.h + TI TWL4030 SERIES SOC CODEC DRIVER M: Peter Ujfalusi L: alsa-de...@alsa-project.org (moderated for non-subscribers) -- 1.7.9.5 Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/8] mm, vmalloc: change iterating a vmlist to find_vm_area()
> The purpose of iterating a vmlist is finding vm area with specific
> virtual address. find_vm_area() is provided for this purpose
> and more efficient, because it uses a rbtree.
> So change it.
>
> Cc: Chris Metcalf
> Cc: Guan Xuetao
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Signed-off-by: Joonsoo Kim
For UniCore32 bits:
Acked-by: Guan Xuetao
>
> diff --git a/arch/tile/mm/pgtable.c b/arch/tile/mm/pgtable.c
> index de0de0c..862782d 100644
> --- a/arch/tile/mm/pgtable.c
> +++ b/arch/tile/mm/pgtable.c
> @@ -592,12 +592,7 @@ void iounmap(volatile void __iomem *addr_in)
> in parallel. Reuse of the virtual address is prevented by
> leaving it in the global lists until we're done with it.
> cpa takes care of the direct mappings. */
> - read_lock(_lock);
> - for (p = vmlist; p; p = p->next) {
> - if (p->addr == addr)
> - break;
> - }
> - read_unlock(_lock);
> + p = find_vm_area((void *)addr);
>
> if (!p) {
> pr_err("iounmap: bad address %p\n", addr);
> diff --git a/arch/unicore32/mm/ioremap.c b/arch/unicore32/mm/ioremap.c
> index b7a6055..13068ee 100644
> --- a/arch/unicore32/mm/ioremap.c
> +++ b/arch/unicore32/mm/ioremap.c
> @@ -235,7 +235,7 @@ EXPORT_SYMBOL(__uc32_ioremap_cached);
> void __uc32_iounmap(volatile void __iomem *io_addr)
> {
> void *addr = (void *)(PAGE_MASK & (unsigned long)io_addr);
> - struct vm_struct **p, *tmp;
> + struct vm_struct *vm;
>
> /*
>* If this is a section based mapping we need to handle it
> @@ -244,17 +244,10 @@ void __uc32_iounmap(volatile void __iomem *io_addr)
>* all the mappings before the area can be reclaimed
>* by someone else.
>*/
> - write_lock(_lock);
> - for (p = ; (tmp = *p) ; p = >next) {
> - if ((tmp->flags & VM_IOREMAP) && (tmp->addr == addr)) {
> - if (tmp->flags & VM_UNICORE_SECTION_MAPPING) {
> - unmap_area_sections((unsigned long)tmp->addr,
> - tmp->size);
> - }
> - break;
> - }
> - }
> - write_unlock(_lock);
> + vm = find_vm_area(addr);
> + if (vm && (vm->flags & VM_IOREMAP) &&
> + (vm->flags & VM_UNICORE_SECTION_MAPPING))
> + unmap_area_sections((unsigned long)vm->addr, vm->size);
>
> vunmap(addr);
> }
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index 78fe3f1..9a1e658 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -282,12 +282,7 @@ void iounmap(volatile void __iomem *addr)
> in parallel. Reuse of the virtual address is prevented by
> leaving it in the global lists until we're done with it.
> cpa takes care of the direct mappings. */
> - read_lock(_lock);
> - for (p = vmlist; p; p = p->next) {
> - if (p->addr == (void __force *)addr)
> - break;
> - }
> - read_unlock(_lock);
> + p = find_vm_area((void __force *)addr);
>
> if (!p) {
> printk(KERN_ERR "iounmap: bad address %p\n", addr);
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] sound/soc/soc-core.c: drop kfree of devm_kzalloc's data
On Sat, Dec 08, 2012 at 07:01:20PM +0100, Julia Lawall wrote: > The kfrees were introduced in b761c0ca. > I sent this a few months ago, and I still think it should be applied... I'm missing patches 1 and 2? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
On 12/10/2012 02:27 AM, Oleg Nesterov wrote: > On 12/07, Srivatsa S. Bhat wrote: >> >> 4. No deadlock possibilities >> >>Per-cpu locking is not the way to go if we want to have relaxed rules >>for lock-ordering. Because, we can end up in circular-locking dependencies >>as explained in https://lkml.org/lkml/2012/12/6/290 > > OK, but this assumes that, contrary to what Steven said, read-write-read > deadlock is not possible when it comes to rwlock_t. What I meant is, with a single (global) rwlock, you can't deadlock like that. But if you used per-cpu rwlocks and if we don't implement them properly, then we can end up in circular locking dependencies like shown above. That is, if you take the same example and replace the lock with global rwlock, you won't deadlock: Readers: CPU 0CPU 1 -- -- 1.spin_lock(_lock); read_lock(_rwlock); 2.read_lock(_rwlock); spin_lock(_lock); Writer: CPU 2: -- write_lock(_rwlock); Even if the writer does a write_lock() in-between steps 1 and 2 at the reader- side, nothing will happen. The writer would spin because CPU 1 already got the rwlock for read, and hence both CPU 0 and 1 go ahead. When they finish, the writer will get the lock and proceed. So, no deadlocks here. So, what I was pointing out here was, if somebody replaced this global rwlock with a "straight-forward" implementation of per-cpu rwlocks, he'll immediately end up in circular locking dependency deadlock between the 3 entities as explained in the link above. Let me know if my assumptions are incorrect! > So far I think this > is true and we can't deadlock. Steven? > > However. If this is true, then compared to preempt_disable/stop_machine > livelock is possible. Probably this is fine, we have the same problem with > get_online_cpus(). But if we can accept this fact I feel we can simmplify > this somehow... Can't prove, only feel ;) > Not sure I follow.. Anyway, my point is that, we _can't_ implement per-cpu rwlocks like lglocks and expect it to work in this case. IOW, we can't do: Reader-side: -> read_lock() your per-cpu rwlock and proceed. Writer-side: -> for_each_online_cpu(cpu) write_lock(per-cpu rwlock of 'cpu'); Also, like Tejun said, one of the important measures for per-cpu rwlocks should be that, if a user replaces global rwlocks with percpu rwlocks (for performance reasons), he shouldn't suddenly end up in numerous deadlock possibilities which never existed before. The replacement should continue to remain safe, and perhaps improve the performance. Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
On 12/10/2012 02:43 AM, Oleg Nesterov wrote: > Damn, sorry for noise. I missed this part... > > On 12/10, Srivatsa S. Bhat wrote: >> >> On 12/10/2012 12:44 AM, Oleg Nesterov wrote: >>> the latency. And I guess something like kick_all_cpus_sync() is "too heavy". >> >> I hadn't considered that. Thinking of it, I don't think it would help us.. >> It won't get rid of the currently running preempt_disable() sections no? > > Sure. But (again, this is only my feeling so far) given that > get_online_cpus_atomic() > does cli/sti, Ah, that one! Actually, the only reason I do that cli/sti is because, potentially interrupt handlers can be hotplug readers too. So we need to protect the portion of the code of get_online_cpus_atomic() which is not re-entrant. (Which reminds me to try and reduce the length of cli/sti in that code, if possible). > this can help to implement ensure-the-readers-must-see-the-pending-writer. > IOW this might help to implement sync-with-readers. > 2 problems: 1. It won't help with cases like this: preempt_disable() ... preempt_disable() ... <--- Here ... preempt_enable() ... preempt_enable() If the IPI hits at the point marked above, the IPI is useless, because, at that point, since we are already in a nested read-side critical section, we can't switch the synchronization protocol. We need to wait till we start a fresh non-nested read-side critical section, in order to switch to global rwlock. The reason is that preempt_enable() or put_online_cpus_atomic() can only undo what its predecessor (preempt_disable()/get_online_cpus_atomic()) did. 2. Part of the reason we want to get rid of stop_machine() is to avoid the latency it induces on _all_ CPUs just to take *one* CPU offline. If we use kick_all_cpus_sync(), we get into that territory again : we unfairly interrupt every CPU, _even when_ that CPU's existing preempt_disabled() sections might not actually be hotplug readers! (ie., not bothered about CPU Hotplug). So, I think whatever synchronization scheme we develop, must not induce the very same problems that stop_machine() had. Otherwise, we can end up going a full-circle and coming back to the same stop_machine() scenario that we intended to get rid of. (That's part of the reason why I initially tried to provide that _light() variant of the reader APIs in the previous version of the patchset, so that light readers can remain as undisturbed from cpu hotplug as possible, thereby avoiding indirectly inducing the "stop_machine effect", like I mentioned here: https://lkml.org/lkml/2012/12/5/369) Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 tree's master branch failed to boot up
Hi, Folks I'm testing with the latest tip tree's master branch 3.7.0-rc8 and failed to boot up my server, it's hung at very beginning and I could not catch any useful log, is there any one else got this problem or I'm the only one?. Regards, Michael Wang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] MCE: fix an error of mce_bad_pages statistics
On 2012/12/8 6:11, Andrew Morton wrote:
> On Fri, 7 Dec 2012 16:48:45 +0800
> Xishi Qiu wrote:
>
>> On x86 platform, if we use "/sys/devices/system/memory/soft_offline_page" to
>> offline a
>> free page twice, the value of mce_bad_pages will be added twice. So this is
>> an error,
>> since the page was already marked HWPoison, we should skip the page and
>> don't add the
>> value of mce_bad_pages.
>>
>> $ cat /proc/meminfo | grep HardwareCorrupted
>>
>> soft_offline_page()
>> get_any_page()
>> atomic_long_add(1, _bad_pages)
>>
>> ...
>>
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -1582,8 +1582,11 @@ int soft_offline_page(struct page *page, int flags)
>> return ret;
>>
>> done:
>> -atomic_long_add(1, _bad_pages);
>> -SetPageHWPoison(page);
>> /* keep elevated page count for bad page */
>> +if (!PageHWPoison(page)) {
>> +atomic_long_add(1, _bad_pages);
>> +SetPageHWPoison(page);
>> +}
>> +
>> return ret;
>> }
>
> A few things:
>
> - soft_offline_page() already checks for this case:
>
> if (PageHWPoison(page)) {
> unlock_page(page);
> put_page(page);
> pr_info("soft offline: %#lx page already poisoned\n", pfn);
> return -EBUSY;
> }
>
> so why didn't this check work for you?
>
> Presumably because one of the earlier "goto done" branches was
> taken. Which one, any why?
>
> This function is an utter mess. It contains six return points
> randomly intermingled with three "goto done" return points.
>
> This mess is probably the cause of the bug you have observed. Can
> we please fix it up somehow? It *seems* that the design (lol) of
> this function is "for errors, return immediately. For success, goto
> done". In which case "done" should have been called "success". But
> if you just look at the function you'll see that this approach didn't
> work. I suggest it be converted to have two return points - one for
> the success path, one for the failure path. Or something.
>
> - soft_offline_huge_page() is a miniature copy of soft_offline_page()
> and might suffer the same bug.
>
> - A cleaner, shorter and possibly faster implementation is
>
> if (!TestSetPageHWPoison(page))
> atomic_long_add(1, _bad_pages);
>
> - We have atomic_long_inc(). Use it?
>
> - Why do we have a variable called "mce_bad_pages"? MCE is an x86
> concept, and this code is in mm/. Lights are flashing, bells are
> ringing and a loudspeaker is blaring "layering violation" at us!
>
Hi Andrew, thank you for your advice, I will send V3 soon.
Thanks
Xishi Qiu
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 1/9] CPU hotplug: Provide APIs to prevent CPU offline from atomic context
On 12/10/2012 01:52 AM, Oleg Nesterov wrote: > On 12/10, Srivatsa S. Bhat wrote: >> >> On 12/10/2012 12:44 AM, Oleg Nesterov wrote: >> >>> But yes, it is easy to blame somebody else's code ;) And I can't suggest >>> something better at least right now. If I understand correctly, we can not >>> use, say, synchronize_sched() in _cpu_down() path >> >> We can't sleep in that code.. so that's a no-go. > > But we can? > > Note that I meant _cpu_down(), not get_online_cpus_atomic() or > take_cpu_down(). > Maybe I'm missing something, but how would it help if we did a synchronize_sched() so early (in _cpu_down())? Another bunch of preempt_disable() sections could start immediately after our call to synchronize_sched() no? How would we deal with that? What we need to ensure here is that all existing preempt_disable() sections are over and that *we* (meaning, the cpu offline writer) get to proceed immediately after that, making all the new readers wait for us. And that is possible only if we do our 'wait-for-readers' thing very close to our actual cpu offline operation (which is take_cpu_down). Moreover, the writer needs to remain stable (non-preemptible) while doing the wait-for-readers. Else (if the writer himself keeps getting scheduled in and out of the CPU) I can't see how he can possibly do justice to the wait. Also, synchronize_sched() only helps us do the 'wait-for-existing-readers' logic. What would take care of the 'prevent-new-readers-from-going-ahead' logic? To add to it all, synchronize_sched() waits for _all_ preempt_disable() sections to complete, whereas only a handful of them might actually care about CPU hotplug. Which is an unnecessary burden for the writer (ie., waiting for unrelated readers to complete). I bet you meant something else. Sorry if I misunderstood it. Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the trivial tree with the regulator tree
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
drivers/regulator/palmas-regulator.c between commit bdc4baacebda
("regulator: palmas: Convert palmas_ops_smps to regulator_[get|
set]_voltage_sel_regmap") from the regulator tree and commit 02582e9bcc36
("treewide: fix typo of "suport" in various comments and Kconfig") from
the trivial tree.
I fixed it up (I used the former as it also fixed the typo) and can carry
the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpGwKl0udYUP.pgp
Description: PGP signature
Re: [RFC PATCH v3 7/9] yield_to(), cpu-hotplug: Prevent offlining of other CPUs properly
On 12/10/2012 02:10 AM, Oleg Nesterov wrote: > On 12/10, Srivatsa S. Bhat wrote: >> >> On 12/10/2012 01:18 AM, Oleg Nesterov wrote: - if (preempt && rq != p_rq) + if (preempt && rq != p_rq && cpu_online(task_cpu(p))) >>> >>> Why do we need this change? >>> >>> Afaics, you could add BUG_ON(!cpu_online(...)) instead? >>> >>> I am just curious. >>> >> >> Oh, I think that's a remnant of v1 (which needed readers to use >> cpu_online_stable()). You're right, we don't need it. > > Ah OK, thanks. > >> Or we could put a >> BUG_ON instead, like you suggested. > > IMHO it would be better to simply drop this chunk. > Sure, will drop it. Its distracting, if nothing else ;-) Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] binfmt_elf: remove unused argument in fill_elf_header
In function fill_elf_header, elf->e_ident[EI_OSABI] is always set
to ELF_OSABI, so remove the unused argument 'osabi'.
Signed-off-by: Zhang Yanfei
---
fs/binfmt_elf.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index fbd9f60..d7b012f 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1247,7 +1247,7 @@ static int writenote(struct memelfnote *men, struct file
*file,
#undef DUMP_WRITE
static void fill_elf_header(struct elfhdr *elf, int segs,
- u16 machine, u32 flags, u8 osabi)
+ u16 machine, u32 flags)
{
memset(elf, 0, sizeof(*elf));
@@ -1627,7 +1627,7 @@ static int fill_note_info(struct elfhdr *elf, int phdrs,
* Initialize the ELF file header.
*/
fill_elf_header(elf, phdrs,
- view->e_machine, view->e_flags, view->ei_osabi);
+ view->e_machine, view->e_flags);
/*
* Allocate a structure for each thread.
@@ -1867,7 +1867,7 @@ static int fill_note_info(struct elfhdr *elf, int phdrs,
elf_core_copy_regs(>prstatus->pr_reg, regs);
/* Set up header */
- fill_elf_header(elf, phdrs, ELF_ARCH, ELF_CORE_EFLAGS, ELF_OSABI);
+ fill_elf_header(elf, phdrs, ELF_ARCH, ELF_CORE_EFLAGS);
/*
* Set up the notes in similar form to SVR4 core dumps made
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 resend hot_track 00/16] vfs: hot data tracking
HI, all guys. any comments or suggestions? On Thu, Dec 6, 2012 at 11:28 AM, Zhi Yong Wu wrote: > HI, guys > > THe perf testing is done separately with fs_mark, fio, ffsb and > compilebench in one kvm guest. > > Below is the performance testing report for hot tracking, and no obvious > perf downgrade is found. > > Note: original kernel means its source code is not changed; > kernel with enabled hot tracking means its source code is with hot > tracking patchset. > > The test env is set up as below: > > root@debian-i386:/home/zwu# uname -a > Linux debian-i386 3.7.0-rc8+ #266 SMP Tue Dec 4 12:17:55 CST 2012 x86_64 > GNU/Linux > > root@debian-i386:/home/zwu# mkfs.xfs -f -l > size=1310b,sunit=8 /home/zwu/bdev.img > meta-data=/home/zwu/bdev.img isize=256agcount=4, agsize=128000 > blks > = sectsz=512 attr=2, projid32bit=0 > data = bsize=4096 blocks=512000, imaxpct=25 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 > log =internal log bsize=4096 blocks=1310, version=2 > = sectsz=512 sunit=1 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > > 1.) original kernel > > root@debian-i386:/home/zwu# mount -o > loop,logbsize=256k /home/zwu/bdev.img /mnt/scratch > [ 1197.421616] XFS (loop0): Mounting Filesystem > [ 1197.567399] XFS (loop0): Ending clean mount > root@debian-i386:/home/zwu# mount > /dev/sda1 on / type ext3 (rw,errors=remount-ro) > tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) > proc on /proc type proc (rw,noexec,nosuid,nodev) > sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) > udev on /dev type tmpfs (rw,mode=0755) > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) > devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) > none on /selinux type selinuxfs (rw,relatime) > debugfs on /sys/kernel/debug type debugfs (rw) > binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc > (rw,noexec,nosuid,nodev) > /dev/loop0 on /mnt/scratch type xfs (rw,logbsize=256k) > root@debian-i386:/home/zwu# free -m > total used free sharedbuffers > cached > Mem: 112109 2 0 4 > 53 > -/+ buffers/cache: 51 60 > Swap: 713 29684 > > 2.) kernel with enabled hot tracking > > root@debian-i386:/home/zwu# mount -o > hot_track,loop,logbsize=256k /home/zwu/bdev.img /mnt/scratch > [ 364.648470] XFS (loop0): Mounting Filesystem > [ 364.910035] XFS (loop0): Ending clean mount > [ 364.921063] VFS: Turning on hot data tracking > root@debian-i386:/home/zwu# mount > /dev/sda1 on / type ext3 (rw,errors=remount-ro) > tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) > proc on /proc type proc (rw,noexec,nosuid,nodev) > sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) > udev on /dev type tmpfs (rw,mode=0755) > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) > devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) > none on /selinux type selinuxfs (rw,relatime) > binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc > (rw,noexec,nosuid,nodev) > /dev/loop0 on /mnt/scratch type xfs (rw,hot_track,logbsize=256k) > root@debian-i386:/home/zwu# free -m > total used free sharedbuffers > cached > Mem: 112107 4 0 2 > 34 > -/+ buffers/cache: 70 41 > Swap: 713 2711 > > 1. fs_mark test > > 1.) orginal kernel > > # ./fs_mark -D 100 -S0 -n 1000 -s 1 -L 30 -d /mnt/scratch/0 > -d /mnt/scratch/1 -d /mnt/scratch/2 -d /mnt/scratch/3 > -d /mnt/scratch/4 -d /mnt/scratch/5 -d /mnt/scratch/6 > -d /mnt/scratch/7 > # Version 3.3, 8 thread(s) starting at Wed Dec 5 03:20:58 2012 > # Sync method: NO SYNC: Test does not issue sync() or fsync() calls. > # Directories: Time based hash between directories across 100 > subdirectories with 180 seconds per subdirectory. > # File names: 40 bytes long, (16 initial bytes of time stamp with 24 > random bytes at end of name) > # Files info: size 1 bytes, written with an IO size of 16384 bytes per > write > # App overhead is time in microseconds spent in the test not doing file > writing related system calls. > > FSUse%Count SizeFiles/sec App Overhead > 2 80001375.6 27175895 > 3160001375.6 27478079 > 4240001346.0 27819607 > 4320001316.9 25863385 > 541335.2 25460605 > 6480001312.3 25889196 > 7560001327.3 25000611 > 8640001304.4
RE: [PATCH 2/2] regulator: lp8788-buck: Kill _gpio_request function
> Applied, thanks. > > Milo, you don't have a MAINTAINERS entry for this chip - would you mind > sending a patch adding one as you are reviewing patches for the driver? > This will ensure that people send you patches for review. OK, I'll update MAINTAINERS file for lp872x and lp8788. Thanks for your help. Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFT v2] regulator: max1586: Implement get_voltage_sel callback
On Thu, Nov 29, 2012 at 01:19:43PM +0800, Axel Lin wrote: > This is required since commit f7df20ec32 > "regulator: core: Use list_voltage() to read single voltage regulators", > otherwise _regulator_get_voltage returns rdev->desc->ops->list_voltage(rdev, > 0). Applied, 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: [PATCH] regulator: lp872x: Kill _rdev_to_offset() function
On Sat, Dec 08, 2012 at 09:56:48AM +0800, Axel Lin wrote: > There is only one user calling _rdev_to_offset() function. > Remove _rdev_to_offset() makes the code simpler. Applied, thanks. Milo, you should probably add a MAINTAINERS entry for this one too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] regulator: lp8788-buck: Remove val array in lp8788_init_dvs
> Actually, what you want is to clear mask[id] bits. > Setting 0 for the data argument here is clear. I would say it's not clearing bit but the DVS control configuration. If the bit is 0, external pin is used for the DVS. If it is 1, then DVS is controlled by other register settings. Therefore, it's a kind of default configuration rather than clearing bits. > But if you prefer to keep it as is, it's ok. Thanks for your understanding. Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] regulator: lp8788-buck: Kill _gpio_request function
On Fri, Dec 07, 2012 at 05:25:13PM +0800, Axel Lin wrote: > Simply use devm_gpio_request_one() instead. Applied, thanks. Milo, you don't have a MAINTAINERS entry for this chip - would you mind sending a patch adding one as you are reviewing patches for the driver? This will ensure that people send you patches for review. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFT 1/2] regulator: anatop: Use linear_min_sel with linear mapping
On Sun, Dec 09, 2012 at 08:05:45AM +0800, Axel Lin wrote: > By setting linear_min_sel to anatop_reg->min_bit_val, we can avoid > adjust the anatop_reg->min_bit_val offset in [set|get]_voltage_sel. Applied both, 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/
KGTP (Linux debugger and tracer) 20121204 release (bug fix and doc update)
Hi guys, KGTP (http://code.google.com/p/kgtp/) is a flexible , lightweight and realtime Linux debugger and tracer. To use it, you don't need patch or rebuild the Linux kernel. Just build KGTP module and insmod it is OK. It makes Linux Kernel supply a GDB remote debug interface. Then GDB in current machine or remote machine can debug and trace Linux through GDB tracepoint and some other functions without stopping the Linux Kernel. And even if the board doesn't have GDB on it and doesn't have interface for remote debug. It can debug the Linux Kernel using offline debug (See http://code.google.com/p/kgtp/wiki/HOWTO#/sys/kernel/debug/gtpframe_and_offline_debug). KGTP supports X86-32, X86-64, MIPS and ARM. KGTP is tested on Linux kernel 2.6.18 to upstream. And it can work with Android (See http://code.google.com/p/kgtp/wiki/HowToUseKGTPinAndroid). Please go to http://code.google.com/p/kgtp/wiki/HOWTO or http://code.google.com/p/kgtp/wiki/HOWTO (Chinese) to get more info about howto use KGTP. Now, KGTP 20121204 release. You can get the package for it from http://kgtp.googlecode.com/files/kgtp_20121204.tar.bz2 or svn co https://kgtp.googlecode.com/svn/tags/20121204 This release doesn't have any feature update. Just fix some build issue with old Linux kernel and ARM. And update howto to make it more clear. Please goto http://code.google.com/p/kgtp/wiki/UPDATE get more info about this release. According to the comments of Christoph, Geoff and Andi. I make lite patch for review. Please goto https://lkml.org/lkml/2012/5/9/90 to see it. Thanks, Hui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 reduce impact of FIFREEZE on userland processes
On Sat, Dec 08, 2012 at 08:47:34AM +, Alun wrote: > On Sat, 8 Dec 2012 12:20:29 +1100 > Dave Chinner wrote: > > First off, thanks for the examples. I'll answer your one question and > then I'll shut up! > > > > I'll try and chase this up by submitting patches to lvcreate and > > > fsfreeze (in the former case, I think there's no reason not to run > > > syncfs; in the latter perhaps it should be a command line option). > > > > Is that even necesary? users can issue the sync themselves if > > necessary > > I think it's necessary for the issue to be better documented in LVM at > the very least. I've dabbled with LVM for nearly 10 years, and used it > in a busy production environment for around 6. For nearly 2 years I've > been seeing, every now and then, these odd cases where taking a snapshot > caused irrecoverable high load on the server. Irrecoverable in what way? > I've never seen any > mention anywhere of the advisability of manually running sync prior to > taking a snapshot on a busy system, and I had to get down to looking at > the kernel sources before I got an inkling this might be the issue. I'd > imagine that the vast majority of end users think the same way as I > did, viz that taking a snapshot was designed to have minimal effect on > any other users of the filesystem. Right - minimal effect, not "no effect". > There's also the issue that AFAIK there's no commonly distributed > program which will allow you to call syncfs() on a filesystem. Running > sync is a bit of a sledgehammer approach for a busy system with > multiple large filesystems. I have no doubt that you could write the 20 lines of C code needed to use syncfs ;) > I've submitted a patch to util-linux, adding a --sync option to > fsfreeze which, if specified, will syncfs the requested filesystem > prior to any freeze operation. Hopefully they'll accept this, though > the only comment I've received so far suggested that I should be > submitting a kernel patch rather than band aiding it in userland! Perhaps that tells you something - that both sides are telling you it's a band aid for your specific issue? :/ fsfreeze is a data integrity operation and some people rely on it to take immediate effect as it currently does. IMO, that's the bar that the any generic freeze optimisation has to overcome. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6] Cypress PS/2 Trackpad driver
Hi Kamal, I think in default branch in cypress_get_finger_count() function return 0 is not suitable, We should return a value bigger than 5 to indicate invalid package to avoid unable to distinguish really 0 contact_cnt packages. 0 contact_cnt packages may still have valid left/right mechanical button events data, so cannot be mixed together. otherwise cypress_validate_byte() function cannot filter out invalid package data. Could you help double check with it, Thanks. > > This driver, submitted on behalf of Cypress Semiconductor Corporation > > and additional contributors, provides support for the Cypress PS/2 Trackpad. > > > > Note that the patch "increase struct ps2dev cmdbuf[] to 8 bytes" [5] > > is a PREREQUISITE for this patch. > > > > This [PATCH v6] version differs from my previous submitted version[4]: > > > > Changes as recommended by Dmitry Torokhov: > > > > - patches #2 (main driver) and #3 (link in driver) have been merged. > > - eliminated cytp_dbg(), is_cypress_key(), and cypress_set_abs_rel_mode(). > > - restructured cypress_validate_byte() and cypress_reset(). > > - stopped unnecessary fiddling with psmouse->pktsize. > > - fixed cypress_read_cmd_status() printf. > > - removed unused members from struct cytp_data. > > - misc code and comment style cleanups. > > > > Known problems: None. > > > > -Kamal Mostafa > > > > [0] PATCH v1: http://www.spinics.net/lists/linux-input/msg23690.html > > [1] PATCH v2: http://www.spinics.net/lists/linux-input/msg23718.html > > [2] PATCH v3: http://www.spinics.net/lists/linux-input/msg23943.html > > [3] PATCH v4: http://www.spinics.net/lists/linux-input/msg24047.html > > [4] PATCH v5: http://www.spinics.net/lists/linux-input/msg24096.html > > [5] cmdbuf patch: > > http://www.spinics.net/lists/linux-input/msg24095.html > > > > -- >8 -- > > From: Dudley Du > > Subject: [PATCH v6] input: Cypress PS/2 Trackpad psmouse driver > > > > Input/mouse driver for Cypress PS/2 Trackpad. > > > > Original code contributed by Dudley Du (Cypress Semiconductor > > Corporation), modified by Kamal Mostafa and Kyle Fazzari. > > > > BugLink: http://launchpad.net/bugs/978807 > > > > Signed-off-by: Dudley Du > > Signed-off-by: Kamal Mostafa > > Signed-off-by: Kyle Fazzari > > Signed-off-by: Mario Limonciello > > Signed-off-by: Tim Gardner > > Acked-by: Herton Krzesinski > > --- > > drivers/input/mouse/Kconfig| 10 + > > drivers/input/mouse/Makefile |1 + > > drivers/input/mouse/cypress_ps2.c | 719 > > > > drivers/input/mouse/cypress_ps2.h | 191 ++ > > drivers/input/mouse/psmouse-base.c | 32 ++ > > drivers/input/mouse/psmouse.h |1 + > > 6 files changed, 954 insertions(+) > > create mode 100644 drivers/input/mouse/cypress_ps2.c create mode > > 100644 drivers/input/mouse/cypress_ps2.h > > > > diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig > > index cd6268c..88954dd 100644 > > --- a/drivers/input/mouse/Kconfig > > +++ b/drivers/input/mouse/Kconfig > > @@ -68,6 +68,16 @@ config MOUSE_PS2_SYNAPTICS > > > > If unsure, say Y. > > > > +config MOUSE_PS2_CYPRESS > > + bool "Cypress PS/2 mouse protocol extension" if EXPERT > > Why EXPERT here? > > > + default y > > Should it really be default y here? > > > + depends on MOUSE_PS2 > > + help > > + Say Y here if you have a Cypress PS/2 Trackpad connected to > > + your system. > > + > > + If unsure, say Y. > > + > > config MOUSE_PS2_LIFEBOOK > > bool "Fujitsu Lifebook PS/2 mouse protocol extension" if EXPERT > > default y > > diff --git a/drivers/input/mouse/Makefile > > b/drivers/input/mouse/Makefile index 46ba755..323e352 100644 > > --- a/drivers/input/mouse/Makefile > > +++ b/drivers/input/mouse/Makefile > > @@ -32,3 +32,4 @@ psmouse-$(CONFIG_MOUSE_PS2_LIFEBOOK) += lifebook.o > > psmouse-$(CONFIG_MOUSE_PS2_SENTELIC) += sentelic.o > > psmouse-$(CONFIG_MOUSE_PS2_TRACKPOINT) += trackpoint.o > > psmouse-$(CONFIG_MOUSE_PS2_TOUCHKIT) += touchkit_ps2.o > > +psmouse-$(CONFIG_MOUSE_PS2_CYPRESS)+= cypress_ps2.o > > diff --git a/drivers/input/mouse/cypress_ps2.c > > b/drivers/input/mouse/cypress_ps2.c > > new file mode 100644 > > index 000..310cb49 > > --- /dev/null > > +++ b/drivers/input/mouse/cypress_ps2.c > > @@ -0,0 +1,719 @@ > > +/* > > + * Cypress Trackpad PS/2 mouse driver > > + * > > + * Copyright (c) 2012 Cypress Semiconductor Corporation. > > + * > > + * Author: > > + * Dudley Du > > + * > > + * Additional contributors include: > > + * Kamal Mostafa > > + * Kyle Fazzari > > + * > > + * This program is free software; you can redistribute it and/or > > +modify it > > + * under the terms of the GNU General Public License version 2 as > > +published by > > + * the Free Software Foundation. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > >
Re: [PATCH] Add the values related to buddy system for filtering free pages
Hello Vivek, On Fri, 7 Dec 2012 10:08:05 -0500 Vivek Goyal wrote: > On Wed, Nov 21, 2012 at 05:02:47PM +0900, Atsushi Kumagai wrote: > > This patch adds the values related to buddy system to vmcoreinfo data > > so that makedumpfile (dump filtering command) can filter out all free > > pages with the new logic. > > It's faster than the current logic because it can distinguish free page > > by analyzing page structure at the same time as filtering for other > > unnecessary pages (e.g. anonymous page). > > OTOH, the current logic has to trace free_list to distinguish free > > pages while analyzing page structure to filter out other unnecessary > > pages. > > > > The new logic uses the fact that buddy page is marked by _mapcount == > > PAGE_BUDDY_MAPCOUNT_VALUE. The values below are required to distinguish > > it. > > > > Required values: > > - OFFSET(page._mapcount) > > - OFFSET(page.private) > > - SIZE(pageflags) > > - NUMBER(PG_slab) > > - NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE) > > > > As per your explanation, you should just need to export page._mapcount > offset and PAGE_BUDDY_MAPCOUNT_VALUE value so that you can figure out > if a page is free or not. > > Why do we need rest of the three fields. > > - OFFSET(page.private) > - SIZE(pageflags) > - NUMBER(PG_slab) Thanks for your comment. SIZE(pageflags) is unnecessary as you said, but the other two are certainly necessary. I modified the description in v2 to make it clear, please see below: https://lkml.org/lkml/2012/12/9/138 Thanks Atsushi Kumagai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the virtio tree
Hi Rusty,
After merging the virtio tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/net/virtio_net.c: In function 'vq2txq':
drivers/net/virtio_net.c:150:2: error: implicit declaration of function
'virtqueue_get_queue_index' [-Werror=implicit-function-declaration]
Caused by commit 986a4f4d452d ("virtio_net: multiqueue support") from the
net-next tree interacting with commit 105e892960e1 ("virtio: move
queue_index and num_free fields into core struct virtqueue") from the
virtio tree.
I applied the patch below and can carry it as necessary.
From: Stephen Rothwell
Date: Mon, 10 Dec 2012 13:33:57 +1100
Subject: [PATCH] virtnet: for up for virtqueue_get_queue_index removal
Signed-off-by: Stephen Rothwell
---
drivers/net/virtio_net.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 33d6f6f..8afe32d 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -147,7 +147,7 @@ struct padded_vnet_hdr {
*/
static int vq2txq(struct virtqueue *vq)
{
- return (virtqueue_get_queue_index(vq) - 1) / 2;
+ return (vq->index - 1) / 2;
}
static int txq2vq(int txq)
@@ -157,7 +157,7 @@ static int txq2vq(int txq)
static int vq2rxq(struct virtqueue *vq)
{
- return virtqueue_get_queue_index(vq) / 2;
+ return vq->index / 2;
}
static int rxq2vq(int rxq)
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpt0byhByDjY.pgp
Description: PGP signature
RE: [PATCH] regulator: lp872x: Kill _rdev_to_offset() function
> There is only one user calling _rdev_to_offset() function. > Remove _rdev_to_offset() makes the code simpler. > > Signed-off-by: Axel Lin It looks good to me, thanks! Acked-by: Milo(Woogyom) Kim
Re: PATCH reduce impact of FIFREEZE on userland processes
On Sat, Dec 08, 2012 at 07:12:04AM -0500, Christoph Hellwig wrote: > On Fri, Dec 07, 2012 at 11:42:55AM +1100, Dave Chinner wrote: > > The problem wth doing this is that the sync can delay the freeze > > process by quite some time under the exact conditions you describe. > > If you want freeze to take effect immediately (i.e instantly stop > > new modifications), then adding a sync will break this semantic. > > THere are existing users of freeze that require this behaviour... > > But that's only because he uses the big hammer sync_filesystem() which > actually waits for I/O completion. I agree that this is a bad idea, > but if we'd just do a writeback_inodes_sb() call in this place that > starts asynchronous writeout I think everyone would benefit. The problem with that is that async writeback will block on IO submission as soon as the disk backs up on congestion. It's effectively still waiting on IO completions to occur, only now indirectly through the request queue submission process. Hence I think for the heavily loaded situations that are causing freeze latency related issues, sync or async pre-flushes are going to cause exactly the same delays to freezing writes Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] regulator: lp8788-buck: Kill _gpio_request function
> Simply use devm_gpio_request_one() instead. > > Signed-off-by: Axel Lin Thanks! Acked-by: Milo(Woogyom) Kim
linux-next: manual merge of the virtio tree with the net-next tree
Hi Rusty,
Today's linux-next merge of the virtio tree got a conflict in
drivers/net/virtio_net.c between commit e9d7417b97f4 ("virtio-net:
separate fields of sending/receiving queue from virtnet_info") and
986a4f4d452d ("virtio_net: multiqueue support") from the net-next tree
and commit a89f05573fa2 ("virtio-net: remove unused skb_vnet_hdr->num_sg
field"), 2c6d439a7316 ("virtio-net: correct capacity math on ring full"),
e794093a52cd ("virtio_net: don't rely on virtqueue_add_buf() returning
capacity") and 7dc5f95d9b6c ("virtio: net: make it clear that
virtqueue_add_buf() no longer returns > 0") from the virtio tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/virtio_net.c
index a644eeb,6289891..000
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@@ -523,20 -464,21 +522,21 @@@ static bool try_fill_recv(struct receiv
do {
if (vi->mergeable_rx_bufs)
- err = add_recvbuf_mergeable(vi, gfp);
+ err = add_recvbuf_mergeable(rq, gfp);
else if (vi->big_packets)
- err = add_recvbuf_big(vi, gfp);
+ err = add_recvbuf_big(rq, gfp);
else
- err = add_recvbuf_small(vi, gfp);
+ err = add_recvbuf_small(rq, gfp);
oom = err == -ENOMEM;
- if (err < 0)
+ if (err)
break;
- ++vi->num;
- } while (vi->rvq->num_free);
+ ++rq->num;
- } while (err > 0);
++ } while (rq->vq->num_free);
+
- if (unlikely(vi->num > vi->max))
- vi->max = vi->num;
- virtqueue_kick(vi->rvq);
+ if (unlikely(rq->num > rq->max))
+ rq->max = rq->num;
+ virtqueue_kick(rq->vq);
return !oom;
}
@@@ -625,29 -557,13 +625,29 @@@ again
return received;
}
-static void free_old_xmit_skbs(struct virtnet_info *vi)
+static int virtnet_open(struct net_device *dev)
+{
+ struct virtnet_info *vi = netdev_priv(dev);
+ int i;
+
+ for (i = 0; i < vi->max_queue_pairs; i++) {
+ /* Make sure we have some buffers: if oom use wq. */
+ if (!try_fill_recv(>rq[i], GFP_KERNEL))
+ schedule_delayed_work(>refill, 0);
+ virtnet_napi_enable(>rq[i]);
+ }
+
+ return 0;
+}
+
- static unsigned int free_old_xmit_skbs(struct send_queue *sq)
++static void free_old_xmit_skbs(struct send_queue *sq)
{
struct sk_buff *skb;
- unsigned int len, tot_sgs = 0;
+ unsigned int len;
+ struct virtnet_info *vi = sq->vq->vdev->priv;
struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
- while ((skb = virtqueue_get_buf(vi->svq, )) != NULL) {
+ while ((skb = virtqueue_get_buf(sq->vq, )) != NULL) {
pr_debug("Sent skb %p\n", skb);
u64_stats_update_begin(>tx_syncp);
@@@ -655,17 -571,15 +655,16 @@@
stats->tx_packets++;
u64_stats_update_end(>tx_syncp);
- tot_sgs += skb_vnet_hdr(skb)->num_sg;
dev_kfree_skb_any(skb);
}
- return tot_sgs;
}
-static int xmit_skb(struct virtnet_info *vi, struct sk_buff *skb)
+static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
{
struct skb_vnet_hdr *hdr = skb_vnet_hdr(skb);
const unsigned char *dest = ((struct ethhdr *)skb->data)->h_dest;
+ unsigned num_sg;
+ struct virtnet_info *vi = sq->vq->vdev->priv;
pr_debug("%s: xmit %p %pM\n", vi->dev->name, skb, dest);
@@@ -700,42 -614,32 +699,35 @@@
/* Encode metadata header at front. */
if (vi->mergeable_rx_bufs)
- sg_set_buf(vi->tx_sg, >mhdr, sizeof hdr->mhdr);
+ sg_set_buf(sq->sg, >mhdr, sizeof hdr->mhdr);
else
- sg_set_buf(vi->tx_sg, >hdr, sizeof hdr->hdr);
+ sg_set_buf(sq->sg, >hdr, sizeof hdr->hdr);
- hdr->num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
- return virtqueue_add_buf(sq->vq, sq->sg, hdr->num_sg,
- num_sg = skb_to_sgvec(skb, vi->tx_sg + 1, 0, skb->len) + 1;
- return virtqueue_add_buf(vi->svq, vi->tx_sg, num_sg,
++ num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1;
++ return virtqueue_add_buf(sq->vq, sq->sg, num_sg,
0, skb, GFP_ATOMIC);
}
static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct virtnet_info *vi = netdev_priv(dev);
+ int qnum = skb_get_queue_mapping(skb);
+ struct send_queue *sq = >sq[qnum];
- int capacity;
+ int err;
/* Free up any pending old buffers before queueing new ones. */
- free_old_xmit_skbs(vi);
+
RE: [PATCH 1/2] regulator: lp8788-buck: Remove val array in lp8788_init_dvs
> All elements of val array are zero.
> Simply set data argument to be 0 in lp8788_update_bits call and remove
> the val
> array.
>
> Signed-off-by: Axel Lin
Axel, sorry I disagree with this patch because DVS_PIN is meaningful.
In this case, explicit bit description is more important than code simplicity.
So I would keep it.
Thanks,
Milo
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [patch 7/7] fs, notify: Add procfs fdinfo helper v6
On Saturday 2012-11-17 00:56, Andrew Morton wrote: >> | pos: 0 >> | flags:0200 >> | inotify wd:3 ino: 9e7e >> | inotify wd:2 ino: a111 >> | inotify wd:1 ino:6b149[...] > >This is a lousy output format. It's sort-of like a sensible set of >name-value tuples: "name:value name:value name:value" but > >c) inotify-wd is secretly printed in decimal while everything else > is in hex. > >What happens if we do something like the below (which will require a >changelog update)? > >@@ -59,7 +59,7 @@ static int show_mark_fhandle(struct seq_ > f.handle.handle_type = ret; > f.handle.handle_bytes = size * sizeof(u32); > >- ret = seq_printf(m, "fhandle-bytes: %8x fhandle-type: %8x f_handle: ", >+ ret = seq_printf(m, "fhandle-bytes:%x fhandle-type:%x f_handle:", >f.handle.handle_bytes, f.handle.handle_type); Why don't we actually make sure to print a 0x prefix when it's hex and 0 on octal? Then it should be clear what base these lines are in. (That would also be a good idea for the rest of procfs files, but I reckon they cannot be easily changed.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [dm-devel] [PATCH 0/3] add resync speed control for dm-raid1
On Thu, 22 Nov 2012 14:27:50 +0800 Guangliang Zhao wrote: > Hi, > > These patches are used to add resync speed control for dm-raid1. The > second and third patch provide support for user-space tool dmsetup. > > Guangliang Zhao (3): > dm raid1: add resync speed control for dm-raid1 > dm raid1: add interface to set resync speed > dm raid1: add interface to get resync speed > > drivers/md/dm-raid1.c | 93 > +++-- > 1 file changed, 90 insertions(+), 3 deletions(-) > The problem with this approach is that it slows down resync even when there is no other IO happening. If that is deemed to be acceptable, then the patch set seems fine, though I would probably make the default a lot higher so as not to change current default behaviour for anyone. If it isn't acceptable, then you either need to monitor the number of requests going to the underlying devices - like md does - or monitor the number of requests coming in to the dm-raid1 target - which is probably easier with dm. i.e. only impose the rate limit if there have been any requests for the dm-raid1 target in the last 'RESYNC_JIFFIES'. What do you think of that? NeilBrown signature.asc Description: PGP signature
Re: [PATCH v2 4/5] page_alloc: Make movablecore_map has higher priority
On 2012-12-9 16:10, Tang Chen wrote: > Hi Liu, Wu, > > On 12/06/2012 10:26 AM, Jiang Liu wrote: >> On 2012-12-6 9:26, Tang Chen wrote: >>> On 12/05/2012 11:43 PM, Jiang Liu wrote: If we make "movablecore_map" take precedence over "movablecore/kernelcore", the logic could be simplified. I think it's not so attractive to support both "movablecore_map" and "movablecore/kernelcore" at the same time. > > Thanks for the advice of removing movablecore/kernelcore. But since we > didn't plan to do this in the beginning, and movablecore/kernelcore are > more user friendly, I think for now, I'll handle DMA and low memory address > problems as you mentioned, and just keep movablecore/kernelcore > in the next version. :) Hi Tang, I mean we could ignore kernelcore/movablecore if user specifies both movablecore_map and kernelcore/movablecore in the kernel command line. I'm not suggesting to get rid of kernelcore/movablecore:) Thanks! > > And about the SRAT, I think it is necessary to many users. I think we > should provide both interfaces. I may give a try in the next version. > > 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: [PATCH v2] arch/x86/tools/gen-insn-attr-x86.awk: remove duplicate const
Sorry, you're right. I blame the font on my phone.
Masami Hiramatsu wrote:
>(2012/12/10 10:34), H. Peter Anvin wrote:
>> You're changing the array from an array of insn_attr_t to pointers to
>insn_attr_t?
>
>No, please look at the code carefully,
>
>- print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX + 1]"
>\
> ^^
>+ print "const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX +
>1]" \
>^^
>Both are pointers of array.
>
>I'd just change the position of const.
>
>const insn_attr_t const * -> const insn_attr_t * const
>
>Thank you,
>
>>
>> Masami Hiramatsu wrote:
>>
>>> (2012/12/10 10:03), H. Peter Anvin wrote:
Yes, if you add a * it becomes an array of pointers.
>>>
>>> Right, I would like to make each pointer in the array read-only.
>>>
>>> And, of course, the data itself which pointed by the pointer
>>> is already protected.
>>> You can see this in (builddir)/arch/x86/lib/inat_table.c
>>>
>>> /* Table: 2-byte opcode (0x0f) */
>>> const insn_attr_t inat_escape_table_1[INAT_OPCODE_TABLE_SIZE] = {
>>> [...]
>>> /* Escape opcode map array */
>>> const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX +
>>> 1][INAT_LSTPFX_MAX +
>>> 1] = {
>>>[1][0] = inat_escape_table_1,
>>>
>>>
>>> So I think Cong's v3 is good :)
>>>
>>> Thank you,
>>>
Masami Hiramatsu wrote:
> (2012/12/10 0:50), H. Peter Anvin wrote:
>> No, that would really be wrong - changing the type.
>
> What would be wrong? IMHO, this is just a fix to add a fool
> proof 'const' to array instance itself.
> ...Or, am I missed anything?
>
> Thank you,
>
>> Masami Hiramatsu wrote:
>>
>>> (2012/12/08 8:17), Cong Ding wrote:
> Patch description please?
there are 2 consts in the definition of one variable
>>>
>>> Please put in an actual patch description. The first line
>>> (subject
>>> line) is a title; the patch should make sense without it.
>> sorry for that. so like this is fine?
>>
>
> Well, except that typically you should explain which variable
>it
> is.
> Yes, it is obvious if you look at the patch, but you're making
>>> the
> reader spend a few more moments than necessary.
>
> Also, you should explain what the harm is -- if it breaks
>>> anything
> or is just a cosmetic issue.
sorry again for lacking of experience...
and I missed another same error, so send version 2.
>>>
>>> Ah, sorry for my mistake. I would like to make both the value
>>> pointed by the pointers and the pointers itself read-only.
>>> Thus the right way of the patch should be;
>>>
>>> - print "const insn_attr_t const
>*inat_escape_tables[INAT_ESC_MAX
>>> +
> 1]"
>>> \
>>> + print "const insn_attr_t * const
>inat_escape_tables[INAT_ESC_MAX
>>> +
>>> 1]" \
>>>
>>> Cong, could you update your patch? then I can Ack that.
>>>
>>> Thank you,
>>>
- cong
---
From 6cf729b913287a6fc06325ca75ccf0efff9274e8 Mon Sep 17
>00:00:00
>>> 2001
From: Cong Ding
Date: Fri, 7 Dec 2012 23:14:32 +
Subject: [PATCH] arch/x86/tools/gen-insn-attr-x86.awk: remove
>>> duplicate const
fix the following sparse warning:
arch/x86/lib/inat-tables.c:1080:25: warning: duplicate const
arch/x86/lib/inat-tables.c:1095:25: warning: duplicate const
arch/x86/lib/inat-tables.c:1118:25: warning: duplicate const
for variable inat_escape_tables, inat_group_tables, and
>>> inat_avx_tables
Signed-off-by: Cong Ding
---
arch/x86/tools/gen-insn-attr-x86.awk |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/tools/gen-insn-attr-x86.awk
>>> b/arch/x86/tools/gen-insn-attr-x86.awk
index ddcf39b..987c7b2 100644
--- a/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/arch/x86/tools/gen-insn-attr-x86.awk
@@ -356,7 +356,7 @@ END {
exit 1
# print escape opcode map's array
print "/* Escape opcode map array */"
- print "const insn_attr_t const
>*inat_escape_tables[INAT_ESC_MAX
>>> +
>>> 1]" \
+ print "const insn_attr_t *inat_escape_tables[INAT_ESC_MAX +
>1]"
>>> \
"[INAT_LSTPFX_MAX + 1] = {"
for (i = 0; i < geid; i++)
for (j = 0; j < max_lprefix; j++)
@@ -365,7 +365,7 @@ END {
print "};\n"
# print group opcode map's array
print "/* Group opcode map array */"
- print "const insn_attr_t const
>*inat_group_tables[INAT_GRP_MAX
>>> +
>>>
RE: [PATCH] samsung: Add missing include guard to gpio-core.h
Michael Spang wrote: > > Signed-off-by: Michael Spang > --- > arch/arm/plat-samsung/include/plat/gpio-core.h |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/plat-samsung/include/plat/gpio-core.h > b/arch/arm/plat-samsung/include/plat/gpio-core.h > index 1fe6917..8622c9a 100644 > --- a/arch/arm/plat-samsung/include/plat/gpio-core.h > +++ b/arch/arm/plat-samsung/include/plat/gpio-core.h > @@ -11,6 +11,9 @@ > * published by the Free Software Foundation. > */ > > +#ifndef __PLAT_SAMSUNG_GPIO_CORE_H > +#define __PLAT_SAMSUNG_GPIO_CORE_H > + > #define GPIOCON_OFF (0x00) > #define GPIODAT_OFF (0x04) > > @@ -122,3 +125,5 @@ extern struct samsung_gpio_pm samsung_gpio_pm_4bit; > /* locking wrappers to deal with multiple access to the same gpio bank */ > #define samsung_gpio_lock(_oc, _fl) spin_lock_irqsave(&(_oc)->lock, _fl) > #define samsung_gpio_unlock(_oc, _fl) spin_unlock_irqrestore(&(_oc)->lock, > _fl) > + > +#endif /* __PLAT_SAMSUNG_GPIO_CORE_H */ > -- > 1.7.7.3 Applied, thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arch/x86/tools/gen-insn-attr-x86.awk: remove duplicate const
(2012/12/10 10:34), H. Peter Anvin wrote:
> You're changing the array from an array of insn_attr_t to pointers to
> insn_attr_t?
No, please look at the code carefully,
- print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX + 1]" \
^^
+ print "const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX + 1]" \
^^
Both are pointers of array.
I'd just change the position of const.
const insn_attr_t const * -> const insn_attr_t * const
Thank you,
>
> Masami Hiramatsu wrote:
>
>> (2012/12/10 10:03), H. Peter Anvin wrote:
>>> Yes, if you add a * it becomes an array of pointers.
>>
>> Right, I would like to make each pointer in the array read-only.
>>
>> And, of course, the data itself which pointed by the pointer
>> is already protected.
>> You can see this in (builddir)/arch/x86/lib/inat_table.c
>>
>> /* Table: 2-byte opcode (0x0f) */
>> const insn_attr_t inat_escape_table_1[INAT_OPCODE_TABLE_SIZE] = {
>> [...]
>> /* Escape opcode map array */
>> const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX +
>> 1][INAT_LSTPFX_MAX +
>> 1] = {
>>[1][0] = inat_escape_table_1,
>>
>>
>> So I think Cong's v3 is good :)
>>
>> Thank you,
>>
>>>
>>> Masami Hiramatsu wrote:
>>>
(2012/12/10 0:50), H. Peter Anvin wrote:
> No, that would really be wrong - changing the type.
What would be wrong? IMHO, this is just a fix to add a fool
proof 'const' to array instance itself.
...Or, am I missed anything?
Thank you,
> Masami Hiramatsu wrote:
>
>> (2012/12/08 8:17), Cong Ding wrote:
Patch description please?
>>> there are 2 consts in the definition of one variable
>>>
>>
>> Please put in an actual patch description. The first line
>> (subject
>> line) is a title; the patch should make sense without it.
> sorry for that. so like this is fine?
>
Well, except that typically you should explain which variable it
is.
Yes, it is obvious if you look at the patch, but you're making
>> the
reader spend a few more moments than necessary.
Also, you should explain what the harm is -- if it breaks
>> anything
or is just a cosmetic issue.
>>> sorry again for lacking of experience...
>>> and I missed another same error, so send version 2.
>>
>> Ah, sorry for my mistake. I would like to make both the value
>> pointed by the pointers and the pointers itself read-only.
>> Thus the right way of the patch should be;
>>
>> -print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX
>> +
1]"
>> \
>> +print "const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX
>> +
>> 1]" \
>>
>> Cong, could you update your patch? then I can Ack that.
>>
>> Thank you,
>>
>>>
>>> - cong
>>> ---
>>> From 6cf729b913287a6fc06325ca75ccf0efff9274e8 Mon Sep 17 00:00:00
>> 2001
>>> From: Cong Ding
>>> Date: Fri, 7 Dec 2012 23:14:32 +
>>> Subject: [PATCH] arch/x86/tools/gen-insn-attr-x86.awk: remove
>> duplicate const
>>>
>>> fix the following sparse warning:
>>> arch/x86/lib/inat-tables.c:1080:25: warning: duplicate const
>>> arch/x86/lib/inat-tables.c:1095:25: warning: duplicate const
>>> arch/x86/lib/inat-tables.c:1118:25: warning: duplicate const
>>>
>>> for variable inat_escape_tables, inat_group_tables, and
>> inat_avx_tables
>>>
>>> Signed-off-by: Cong Ding
>>> ---
>>> arch/x86/tools/gen-insn-attr-x86.awk |6 +++---
>>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/x86/tools/gen-insn-attr-x86.awk
>> b/arch/x86/tools/gen-insn-attr-x86.awk
>>> index ddcf39b..987c7b2 100644
>>> --- a/arch/x86/tools/gen-insn-attr-x86.awk
>>> +++ b/arch/x86/tools/gen-insn-attr-x86.awk
>>> @@ -356,7 +356,7 @@ END {
>>> exit 1
>>> # print escape opcode map's array
>>> print "/* Escape opcode map array */"
>>> - print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX
>> +
>> 1]" \
>>> + print "const insn_attr_t *inat_escape_tables[INAT_ESC_MAX + 1]"
>> \
>>> "[INAT_LSTPFX_MAX + 1] = {"
>>> for (i = 0; i < geid; i++)
>>> for (j = 0; j < max_lprefix; j++)
>>> @@ -365,7 +365,7 @@ END {
>>> print "};\n"
>>> # print group opcode map's array
>>> print "/* Group opcode map array */"
>>> - print "const insn_attr_t const *inat_group_tables[INAT_GRP_MAX
>> +
>> 1]"\
>>> + print "const insn_attr_t *inat_group_tables[INAT_GRP_MAX + 1]"\
>>> "[INAT_LSTPFX_MAX + 1] = {"
>>> for (i = 0; i < ggid; i++)
>>> for (j = 0; j
[PATCH v2] Add the values related to buddy system for filtering free pages.
This patch adds the values related to buddy system to vmcoreinfo data so that makedumpfile (dump filtering command) can filter out all free pages with the new logic. It's faster than the current logic because it can distinguish free page by analyzing page structure at the same time as filtering for other unnecessary pages (e.g. anonymous page). OTOH, the current logic has to trace free_list to distinguish free pages while analyzing page structure to filter out other unnecessary pages. The new logic uses the fact that buddy page is marked by _mapcount == PAGE_BUDDY_MAPCOUNT_VALUE. But, _mapcount shares its memory with other fields for SLAB/SLUB when PG_slab is set, so we need to check if PG_slab is set or not before looking up _mapcount value. And we can get the order of buddy system from private field. To sum it up, the values below are required for this logic. Required values: - OFFSET(page._mapcount) - OFFSET(page.private) - NUMBER(PG_slab) - NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE) Changelog from v1 to v2: 1. remove SIZE(pageflags) The new logic was changed after I sent v1 patch. Accordingly, SIZE(pageflags) has been unnecessary for makedumpfile. What's makedumpfile: makedumpfile creates a small dumpfile by excluding unnecessary pages for the analysis. To distinguish unnecessary pages, makedumpfile gets the vmcoreinfo data which has the minimum debugging information only for dump filtering. Signed-off-by: Atsushi Kumagai --- kernel/kexec.c |4 1 file changed, 4 insertions(+) diff --git a/kernel/kexec.c b/kernel/kexec.c index 5e4bd78..b27efe4 100644 --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -1490,6 +1490,8 @@ static int __init crash_save_vmcoreinfo_init(void) VMCOREINFO_OFFSET(page, _count); VMCOREINFO_OFFSET(page, mapping); VMCOREINFO_OFFSET(page, lru); + VMCOREINFO_OFFSET(page, _mapcount); + VMCOREINFO_OFFSET(page, private); VMCOREINFO_OFFSET(pglist_data, node_zones); VMCOREINFO_OFFSET(pglist_data, nr_zones); #ifdef CONFIG_FLAT_NODE_MEM_MAP @@ -1512,6 +1514,8 @@ static int __init crash_save_vmcoreinfo_init(void) VMCOREINFO_NUMBER(PG_lru); VMCOREINFO_NUMBER(PG_private); VMCOREINFO_NUMBER(PG_swapcache); + VMCOREINFO_NUMBER(PG_slab); + VMCOREINFO_NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE); arch_crash_save_vmcoreinfo(); update_vmcoreinfo_note(); -- 1.7.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] pinctrl: exynos5440/samsung: Staticize pcfgs
Linus Walleij wrote: > > On Tue, Nov 27, 2012 at 3:49 PM, Axel Lin wrote: > > > I got below build error with random config if CONFIG_PINCTRL_SAMSUNG=y > && > > CONFIG_PINCTRL_EXYNOS5440=y. > > > > Fix the build error by making pcfgs static. > > > > LD drivers/pinctrl/built-in.o > > drivers/pinctrl/pinctrl-exynos5440.o: In function `.LANCHOR0': > > pinctrl-exynos5440.c:(.data+0x54): multiple definition of `pcfgs' > > drivers/pinctrl/pinctrl-samsung.o:pinctrl-samsung.c:(.data+0x54): first > defined here > > make[2]: *** [drivers/pinctrl/built-in.o] Error 1 > > make[1]: *** [drivers/pinctrl] Error 2 > > make: *** [drivers] Error 2 > > > > Signed-off-by: Axel Lin > > I'm not handling the Samsung drivers for this merge window. > Samsung guys, can you please pick up this patch? > > Acked-by: Linus Walleij > Applied, thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] pinctrl: samsung: Fix a typo in pinctrl-samsung.h
Linus Walleij wrote: > > On Wed, Dec 5, 2012 at 11:17 AM, Sachin Kamat > wrote: > > > struct samsung_pin_bank does not have a member called reg_offset. > > It should be pctl_offset instead. > > > > Signed-off-by: Sachin Kamat > > Acked-by: Linus Walleij > > Kukjin, art you taking this patch? > I did just now with your ack :-) Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] gpio: samsung: Add terminating entry for exynos_pinctrl_ids
The of_device_id table is supposed to be zero-terminated.
Signed-off-by: Axel Lin
---
drivers/gpio/gpio-samsung.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index 01f7fe9..9e251be 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -3026,6 +3026,7 @@ static __init int samsung_gpiolib_init(void)
static const struct of_device_id exynos_pinctrl_ids[] = {
{ .compatible = "samsung,pinctrl-exynos4210", },
{ .compatible = "samsung,pinctrl-exynos4x12", },
+ { }
};
for_each_matching_node(pctrl_np, exynos_pinctrl_ids)
if (pctrl_np && of_device_is_available(pctrl_np))
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] arch/x86/tools/gen-insn-attr-x86.awk: remove duplicate const
You're changing the array from an array of insn_attr_t to pointers to
insn_attr_t?
Masami Hiramatsu wrote:
>(2012/12/10 10:03), H. Peter Anvin wrote:
>> Yes, if you add a * it becomes an array of pointers.
>
>Right, I would like to make each pointer in the array read-only.
>
>And, of course, the data itself which pointed by the pointer
>is already protected.
>You can see this in (builddir)/arch/x86/lib/inat_table.c
>
>/* Table: 2-byte opcode (0x0f) */
>const insn_attr_t inat_escape_table_1[INAT_OPCODE_TABLE_SIZE] = {
>[...]
>/* Escape opcode map array */
>const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX +
>1][INAT_LSTPFX_MAX +
> 1] = {
>[1][0] = inat_escape_table_1,
>
>
>So I think Cong's v3 is good :)
>
>Thank you,
>
>>
>> Masami Hiramatsu wrote:
>>
>>> (2012/12/10 0:50), H. Peter Anvin wrote:
No, that would really be wrong - changing the type.
>>>
>>> What would be wrong? IMHO, this is just a fix to add a fool
>>> proof 'const' to array instance itself.
>>> ...Or, am I missed anything?
>>>
>>> Thank you,
>>>
Masami Hiramatsu wrote:
> (2012/12/08 8:17), Cong Ding wrote:
>>> Patch description please?
>> there are 2 consts in the definition of one variable
>>
>
> Please put in an actual patch description. The first line
> (subject
> line) is a title; the patch should make sense without it.
sorry for that. so like this is fine?
>>>
>>> Well, except that typically you should explain which variable it
>>> is.
>>> Yes, it is obvious if you look at the patch, but you're making
>the
>>> reader spend a few more moments than necessary.
>>>
>>> Also, you should explain what the harm is -- if it breaks
>anything
>>> or is just a cosmetic issue.
>> sorry again for lacking of experience...
>> and I missed another same error, so send version 2.
>
> Ah, sorry for my mistake. I would like to make both the value
> pointed by the pointers and the pointers itself read-only.
> Thus the right way of the patch should be;
>
> - print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX
>+
>>> 1]"
> \
> + print "const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX
>+
> 1]" \
>
> Cong, could you update your patch? then I can Ack that.
>
> Thank you,
>
>>
>> - cong
>> ---
>> From 6cf729b913287a6fc06325ca75ccf0efff9274e8 Mon Sep 17 00:00:00
> 2001
>> From: Cong Ding
>> Date: Fri, 7 Dec 2012 23:14:32 +
>> Subject: [PATCH] arch/x86/tools/gen-insn-attr-x86.awk: remove
> duplicate const
>>
>> fix the following sparse warning:
>> arch/x86/lib/inat-tables.c:1080:25: warning: duplicate const
>> arch/x86/lib/inat-tables.c:1095:25: warning: duplicate const
>> arch/x86/lib/inat-tables.c:1118:25: warning: duplicate const
>>
>> for variable inat_escape_tables, inat_group_tables, and
> inat_avx_tables
>>
>> Signed-off-by: Cong Ding
>> ---
>> arch/x86/tools/gen-insn-attr-x86.awk |6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/tools/gen-insn-attr-x86.awk
> b/arch/x86/tools/gen-insn-attr-x86.awk
>> index ddcf39b..987c7b2 100644
>> --- a/arch/x86/tools/gen-insn-attr-x86.awk
>> +++ b/arch/x86/tools/gen-insn-attr-x86.awk
>> @@ -356,7 +356,7 @@ END {
>> exit 1
>> # print escape opcode map's array
>> print "/* Escape opcode map array */"
>> -print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX
>+
> 1]" \
>> +print "const insn_attr_t *inat_escape_tables[INAT_ESC_MAX + 1]"
>\
>>"[INAT_LSTPFX_MAX + 1] = {"
>> for (i = 0; i < geid; i++)
>> for (j = 0; j < max_lprefix; j++)
>> @@ -365,7 +365,7 @@ END {
>> print "};\n"
>> # print group opcode map's array
>> print "/* Group opcode map array */"
>> -print "const insn_attr_t const *inat_group_tables[INAT_GRP_MAX
>+
> 1]"\
>> +print "const insn_attr_t *inat_group_tables[INAT_GRP_MAX + 1]"\
>>"[INAT_LSTPFX_MAX + 1] = {"
>> for (i = 0; i < ggid; i++)
>> for (j = 0; j < max_lprefix; j++)
>> @@ -374,7 +374,7 @@ END {
>> print "};\n"
>> # print AVX opcode map's array
>> print "/* AVX opcode map array */"
>> -print "const insn_attr_t const *inat_avx_tables[X86_VEX_M_MAX +
> 1]"\
>> +print "const insn_attr_t *inat_avx_tables[X86_VEX_M_MAX + 1]"\
>>"[INAT_LSTPFX_MAX + 1] = {"
>> for (i = 0; i < gaid; i++)
>> for (j = 0; j < max_lprefix; j++)
>>
>>
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
To
[Consult]: Re: [PATCH] synclink fix ldisc buffer argument
Hello Paul Fulghum: Firstly, sorry for my mistake: I am a reporter (not reviewer), and not suitable to review maintainer's patch. when you send relative patch, need not cc to me (I am not reviewer) so: could you send patch again (not need cc to me) ? (and also it is better to mark me as Reported-by in your patch) sorry for my mistake, again. gchen. 于 2012年12月07日 10:15, Chen Gang 写道: > Hello Greg Kroah-Hartman: > > > 于 2012年12月04日 01:13, Paul Fulghum 写道: >> Fix call to line discipline receive_buf by synclink drivers. >> Dummy flag buffer argument is ignored by N_HDLC line discipline but might >> be of insufficient size if accessed by a different line discipline >> selected by mistake. flag buffer allocation now matches max size of data >> buffer. Unused char_buf buffers are removed. >> >> Signed-off-by: Paul Fulghum > > if no additional questions: > is it suitable to let this patch pass checking ? > at least for me, it is surely solve an issue, and no negative effect. > > now, maybe Paul Fulghum is busy... > the left questions what I have sent seems minor. > so they can be delayed, until he has free time. > > when Paul Fulghum has free time. > can still check what my left questions whether valid. > if they are valid, can send additional patch for them. > > > is it OK ? > > Regards > -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arch/x86/tools/gen-insn-attr-x86.awk: remove duplicate const
(2012/12/10 10:03), H. Peter Anvin wrote:
> Yes, if you add a * it becomes an array of pointers.
Right, I would like to make each pointer in the array read-only.
And, of course, the data itself which pointed by the pointer
is already protected.
You can see this in (builddir)/arch/x86/lib/inat_table.c
/* Table: 2-byte opcode (0x0f) */
const insn_attr_t inat_escape_table_1[INAT_OPCODE_TABLE_SIZE] = {
[...]
/* Escape opcode map array */
const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX + 1][INAT_LSTPFX_MAX +
1] = {
[1][0] = inat_escape_table_1,
So I think Cong's v3 is good :)
Thank you,
>
> Masami Hiramatsu wrote:
>
>> (2012/12/10 0:50), H. Peter Anvin wrote:
>>> No, that would really be wrong - changing the type.
>>
>> What would be wrong? IMHO, this is just a fix to add a fool
>> proof 'const' to array instance itself.
>> ...Or, am I missed anything?
>>
>> Thank you,
>>
>>> Masami Hiramatsu wrote:
>>>
(2012/12/08 8:17), Cong Ding wrote:
>> Patch description please?
> there are 2 consts in the definition of one variable
>
Please put in an actual patch description. The first line
(subject
line) is a title; the patch should make sense without it.
>>> sorry for that. so like this is fine?
>>>
>>
>> Well, except that typically you should explain which variable it
>> is.
>> Yes, it is obvious if you look at the patch, but you're making the
>> reader spend a few more moments than necessary.
>>
>> Also, you should explain what the harm is -- if it breaks anything
>> or is just a cosmetic issue.
> sorry again for lacking of experience...
> and I missed another same error, so send version 2.
Ah, sorry for my mistake. I would like to make both the value
pointed by the pointers and the pointers itself read-only.
Thus the right way of the patch should be;
- print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX +
>> 1]"
\
+ print "const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX +
1]" \
Cong, could you update your patch? then I can Ack that.
Thank you,
>
> - cong
> ---
> From 6cf729b913287a6fc06325ca75ccf0efff9274e8 Mon Sep 17 00:00:00
2001
> From: Cong Ding
> Date: Fri, 7 Dec 2012 23:14:32 +
> Subject: [PATCH] arch/x86/tools/gen-insn-attr-x86.awk: remove
duplicate const
>
> fix the following sparse warning:
> arch/x86/lib/inat-tables.c:1080:25: warning: duplicate const
> arch/x86/lib/inat-tables.c:1095:25: warning: duplicate const
> arch/x86/lib/inat-tables.c:1118:25: warning: duplicate const
>
> for variable inat_escape_tables, inat_group_tables, and
inat_avx_tables
>
> Signed-off-by: Cong Ding
> ---
> arch/x86/tools/gen-insn-attr-x86.awk |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/tools/gen-insn-attr-x86.awk
b/arch/x86/tools/gen-insn-attr-x86.awk
> index ddcf39b..987c7b2 100644
> --- a/arch/x86/tools/gen-insn-attr-x86.awk
> +++ b/arch/x86/tools/gen-insn-attr-x86.awk
> @@ -356,7 +356,7 @@ END {
> exit 1
> # print escape opcode map's array
> print "/* Escape opcode map array */"
> - print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX +
1]" \
> + print "const insn_attr_t *inat_escape_tables[INAT_ESC_MAX + 1]" \
> "[INAT_LSTPFX_MAX + 1] = {"
> for (i = 0; i < geid; i++)
> for (j = 0; j < max_lprefix; j++)
> @@ -365,7 +365,7 @@ END {
> print "};\n"
> # print group opcode map's array
> print "/* Group opcode map array */"
> - print "const insn_attr_t const *inat_group_tables[INAT_GRP_MAX +
1]"\
> + print "const insn_attr_t *inat_group_tables[INAT_GRP_MAX + 1]"\
> "[INAT_LSTPFX_MAX + 1] = {"
> for (i = 0; i < ggid; i++)
> for (j = 0; j < max_lprefix; j++)
> @@ -374,7 +374,7 @@ END {
> print "};\n"
> # print AVX opcode map's array
> print "/* AVX opcode map array */"
> - print "const insn_attr_t const *inat_avx_tables[X86_VEX_M_MAX +
1]"\
> + print "const insn_attr_t *inat_avx_tables[X86_VEX_M_MAX + 1]"\
> "[INAT_LSTPFX_MAX + 1] = {"
> for (i = 0; i < gaid; i++)
> for (j = 0; j < max_lprefix; j++)
>
>>>
>
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
we offer long and short term loan
OPEN THE ATTACH AND APPLY FOR YOUR LOAN MUTHOOTH.rtf Description: Binary data
Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked
>There are no other callers AFAICS so I am getting clueless. Maybe more >debugging will tell us something (the inlining has been reduced for thp >paths which can reduce performance in thp page fault heavy workloads but >this will give us better traces - I hope). Michal, this was printing so many debug messages to console that the whole server hangs and i had to hard reset it after several minutes :( Sorry but i cannot test such a things in production. There's no problem with one soft reset which takes 4 minutes but this hard reset creates about 20 minutes outage (mainly cos of disk quotas checking). Last logged message: Dec 10 02:03:29 server01 kernel: [ 220.366486] grsec: From 141.105.120.152: bruteforce prevention initiated for the next 30 minutes or until service restarted, stalling each fork 30 seconds. Please investigate the crash report for /usr/lib/apache2/mpm-itk/apache2[apache2:3586] uid/euid:1258/1258 gid/egid:100/100, parent /usr/lib/apache2/mpm-itk/apache2[apache2:2142] uid/euid:0/0 gid/egid:0/0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/3] ARM: MM: Add the workaround of Errata 774769
Russell King - ARM Linux wrote: > > -3: mov r10, #0 > > + /* Cortex-A15 Errata */ > > +3: ldr r10, =0x0c0f@ Cortex-A15 primary part number > > + teq r0, r10 > > + bne 4f > > +#ifdef CONFIG_ARM_ERRATA_774769 > > There's not much point testing for the part number of the work-around isn't > enabled. The errata 773022 on second patch series is also required to checking the part number. In my opinion, the testing for Cortex-A15 primary part number is required before working the work-around to support several A15 errata. > > > + teq r6, #0x4@ present in r0p4 > > + mrceq p15, 0, r10, c1, c0, 1 @ read aux control register > > tsteq r10, #1 << 15 > > to avoid writing to the aux control register if the errata has already been > applied. Do you mean "tsteq r10, #1 << 25" ? If yes, it needs to branch and will make a little complicated And, I think maybe this function could be the first step to configure this erratum. Thanks for your review > > > + orreq r10, r10, #1 << 25 @ set bit #25 > > + mcreq p15, 0, r10, c1, c0, 1 @ write aux control register > > +#endif > > + > > +4: mov r10, #0 > > mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate > > dsb > > #ifdef CONFIG_MMU > > -- > > 1.7.5.4 > > > > > > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the net-next tree with the pci tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/wireless/iwlwifi/pcie/trans.c between commit b9d146e30a2d
("iwlwifi: collapse wrapper for pcie_capability_read_word()") from the
pci tree and commit 7afe3705cd4e ("iwlwifi: continue clean up -
pcie/trans.c") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/net/wireless/iwlwifi/pcie/trans.c
index 1dfa6be,f6c21e7..000
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@@ -670,8 -94,10 +94,8 @@@ static void iwl_pcie_set_pwr_vmain(stru
/* PCI registers */
#define PCI_CFG_RETRY_TIMEOUT 0x041
-#define PCI_CFG_LINK_CTRL_VAL_L0S_EN 0x01
-#define PCI_CFG_LINK_CTRL_VAL_L1_EN 0x02
- static void iwl_apm_config(struct iwl_trans *trans)
+ static void iwl_pcie_apm_config(struct iwl_trans *trans)
{
struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
u16 lctl;
@@@ -684,20 -110,19 +108,17 @@@
* If not (unlikely), enable L0S, so there is at least some
*power savings, even without L1.
*/
-
pcie_capability_read_word(trans_pcie->pci_dev, PCI_EXP_LNKCTL, );
-
- if ((lctl & PCI_CFG_LINK_CTRL_VAL_L1_EN) ==
- PCI_CFG_LINK_CTRL_VAL_L1_EN) {
+ if (lctl & PCI_EXP_LNKCTL_ASPM_L1) {
/* L1-ASPM enabled; disable(!) L0S */
iwl_set_bit(trans, CSR_GIO_REG, CSR_GIO_REG_VAL_L0S_ENABLED);
- dev_printk(KERN_INFO, trans->dev,
- "L1 Enabled; Disabling L0S\n");
+ dev_info(trans->dev, "L1 Enabled; Disabling L0S\n");
} else {
/* L1-ASPM disabled; enable(!) L0S */
iwl_clear_bit(trans, CSR_GIO_REG, CSR_GIO_REG_VAL_L0S_ENABLED);
- dev_printk(KERN_INFO, trans->dev,
- "L1 Disabled; Enabling L0S\n");
+ dev_info(trans->dev, "L1 Disabled; Enabling L0S\n");
}
- trans->pm_support = !(lctl & PCI_CFG_LINK_CTRL_VAL_L0S_EN);
+ trans->pm_support = !(lctl & PCI_EXP_LNKCTL_ASPM_L0S);
}
/*
pgpwjSYh1oRMi.pgp
Description: PGP signature
Re: Re: [PATCH v2] arch/x86/tools/gen-insn-attr-x86.awk: remove duplicate const
Yes, if you add a * it becomes an array of pointers.
Masami Hiramatsu wrote:
>(2012/12/10 0:50), H. Peter Anvin wrote:
>> No, that would really be wrong - changing the type.
>
>What would be wrong? IMHO, this is just a fix to add a fool
>proof 'const' to array instance itself.
>...Or, am I missed anything?
>
>Thank you,
>
>> Masami Hiramatsu wrote:
>>
>>> (2012/12/08 8:17), Cong Ding wrote:
> Patch description please?
there are 2 consts in the definition of one variable
>>>
>>> Please put in an actual patch description. The first line
>>> (subject
>>> line) is a title; the patch should make sense without it.
>> sorry for that. so like this is fine?
>>
>
> Well, except that typically you should explain which variable it
>is.
> Yes, it is obvious if you look at the patch, but you're making the
> reader spend a few more moments than necessary.
>
> Also, you should explain what the harm is -- if it breaks anything
> or is just a cosmetic issue.
sorry again for lacking of experience...
and I missed another same error, so send version 2.
>>>
>>> Ah, sorry for my mistake. I would like to make both the value
>>> pointed by the pointers and the pointers itself read-only.
>>> Thus the right way of the patch should be;
>>>
>>> - print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX +
>1]"
>>> \
>>> + print "const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX +
>>> 1]" \
>>>
>>> Cong, could you update your patch? then I can Ack that.
>>>
>>> Thank you,
>>>
- cong
---
From 6cf729b913287a6fc06325ca75ccf0efff9274e8 Mon Sep 17 00:00:00
>>> 2001
From: Cong Ding
Date: Fri, 7 Dec 2012 23:14:32 +
Subject: [PATCH] arch/x86/tools/gen-insn-attr-x86.awk: remove
>>> duplicate const
fix the following sparse warning:
arch/x86/lib/inat-tables.c:1080:25: warning: duplicate const
arch/x86/lib/inat-tables.c:1095:25: warning: duplicate const
arch/x86/lib/inat-tables.c:1118:25: warning: duplicate const
for variable inat_escape_tables, inat_group_tables, and
>>> inat_avx_tables
Signed-off-by: Cong Ding
---
arch/x86/tools/gen-insn-attr-x86.awk |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/tools/gen-insn-attr-x86.awk
>>> b/arch/x86/tools/gen-insn-attr-x86.awk
index ddcf39b..987c7b2 100644
--- a/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/arch/x86/tools/gen-insn-attr-x86.awk
@@ -356,7 +356,7 @@ END {
exit 1
# print escape opcode map's array
print "/* Escape opcode map array */"
- print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX +
>>> 1]" \
+ print "const insn_attr_t *inat_escape_tables[INAT_ESC_MAX + 1]" \
"[INAT_LSTPFX_MAX + 1] = {"
for (i = 0; i < geid; i++)
for (j = 0; j < max_lprefix; j++)
@@ -365,7 +365,7 @@ END {
print "};\n"
# print group opcode map's array
print "/* Group opcode map array */"
- print "const insn_attr_t const *inat_group_tables[INAT_GRP_MAX +
>>> 1]"\
+ print "const insn_attr_t *inat_group_tables[INAT_GRP_MAX + 1]"\
"[INAT_LSTPFX_MAX + 1] = {"
for (i = 0; i < ggid; i++)
for (j = 0; j < max_lprefix; j++)
@@ -374,7 +374,7 @@ END {
print "};\n"
# print AVX opcode map's array
print "/* AVX opcode map array */"
- print "const insn_attr_t const *inat_avx_tables[X86_VEX_M_MAX +
>>> 1]"\
+ print "const insn_attr_t *inat_avx_tables[X86_VEX_M_MAX + 1]"\
"[INAT_LSTPFX_MAX + 1] = {"
for (i = 0; i < gaid; i++)
for (j = 0; j < max_lprefix; j++)
>>
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH v2] arch/x86/tools/gen-insn-attr-x86.awk: remove duplicate const
(2012/12/10 0:50), H. Peter Anvin wrote:
> No, that would really be wrong - changing the type.
What would be wrong? IMHO, this is just a fix to add a fool
proof 'const' to array instance itself.
...Or, am I missed anything?
Thank you,
> Masami Hiramatsu wrote:
>
>> (2012/12/08 8:17), Cong Ding wrote:
Patch description please?
>>> there are 2 consts in the definition of one variable
>>>
>>
>> Please put in an actual patch description. The first line
>> (subject
>> line) is a title; the patch should make sense without it.
> sorry for that. so like this is fine?
>
Well, except that typically you should explain which variable it is.
Yes, it is obvious if you look at the patch, but you're making the
reader spend a few more moments than necessary.
Also, you should explain what the harm is -- if it breaks anything
or is just a cosmetic issue.
>>> sorry again for lacking of experience...
>>> and I missed another same error, so send version 2.
>>
>> Ah, sorry for my mistake. I would like to make both the value
>> pointed by the pointers and the pointers itself read-only.
>> Thus the right way of the patch should be;
>>
>> -print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX + 1]"
>> \
>> +print "const insn_attr_t * const inat_escape_tables[INAT_ESC_MAX +
>> 1]" \
>>
>> Cong, could you update your patch? then I can Ack that.
>>
>> Thank you,
>>
>>>
>>> - cong
>>> ---
>>> From 6cf729b913287a6fc06325ca75ccf0efff9274e8 Mon Sep 17 00:00:00
>> 2001
>>> From: Cong Ding
>>> Date: Fri, 7 Dec 2012 23:14:32 +
>>> Subject: [PATCH] arch/x86/tools/gen-insn-attr-x86.awk: remove
>> duplicate const
>>>
>>> fix the following sparse warning:
>>> arch/x86/lib/inat-tables.c:1080:25: warning: duplicate const
>>> arch/x86/lib/inat-tables.c:1095:25: warning: duplicate const
>>> arch/x86/lib/inat-tables.c:1118:25: warning: duplicate const
>>>
>>> for variable inat_escape_tables, inat_group_tables, and
>> inat_avx_tables
>>>
>>> Signed-off-by: Cong Ding
>>> ---
>>> arch/x86/tools/gen-insn-attr-x86.awk |6 +++---
>>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/x86/tools/gen-insn-attr-x86.awk
>> b/arch/x86/tools/gen-insn-attr-x86.awk
>>> index ddcf39b..987c7b2 100644
>>> --- a/arch/x86/tools/gen-insn-attr-x86.awk
>>> +++ b/arch/x86/tools/gen-insn-attr-x86.awk
>>> @@ -356,7 +356,7 @@ END {
>>> exit 1
>>> # print escape opcode map's array
>>> print "/* Escape opcode map array */"
>>> - print "const insn_attr_t const *inat_escape_tables[INAT_ESC_MAX +
>> 1]" \
>>> + print "const insn_attr_t *inat_escape_tables[INAT_ESC_MAX + 1]" \
>>> "[INAT_LSTPFX_MAX + 1] = {"
>>> for (i = 0; i < geid; i++)
>>> for (j = 0; j < max_lprefix; j++)
>>> @@ -365,7 +365,7 @@ END {
>>> print "};\n"
>>> # print group opcode map's array
>>> print "/* Group opcode map array */"
>>> - print "const insn_attr_t const *inat_group_tables[INAT_GRP_MAX +
>> 1]"\
>>> + print "const insn_attr_t *inat_group_tables[INAT_GRP_MAX + 1]"\
>>> "[INAT_LSTPFX_MAX + 1] = {"
>>> for (i = 0; i < ggid; i++)
>>> for (j = 0; j < max_lprefix; j++)
>>> @@ -374,7 +374,7 @@ END {
>>> print "};\n"
>>> # print AVX opcode map's array
>>> print "/* AVX opcode map array */"
>>> - print "const insn_attr_t const *inat_avx_tables[X86_VEX_M_MAX +
>> 1]"\
>>> + print "const insn_attr_t *inat_avx_tables[X86_VEX_M_MAX + 1]"\
>>> "[INAT_LSTPFX_MAX + 1] = {"
>>> for (i = 0; i < gaid; i++)
>>> for (j = 0; j < max_lprefix; j++)
>>>
>
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 266/270] ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
On Mon, 2012-11-26 at 14:59 -0200, Herton Ronaldo Krzesinski wrote:
> 3.5.7u1 -stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> From: Paul Walmsley
>
> commit 39141ddfb63a664f26d3f42f64ee386e879b492c upstream.
>
> After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
> saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
> started crashing during boot with omap2plus_defconfig:
[...]
> [ herton: no uapi directory on 3.5 ]
> Signed-off-by: Herton Ronaldo Krzesinski
[...]
I've also queued this up for 3.2. Greg, you'll want to add this to the
other 3.x series since you applied commit 846a136881b8.
Ben.
--
Ben Hutchings
Kids! Bringing about Armageddon can be dangerous. Do not attempt it in
your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'
signature.asc
Description: This is a digitally signed message part
"attempt to access beyond end of device" on DVD
hello, few years ago I noticed annoying bug on Linux, when I was copying photos from old DVDs I realized that not all files were copied correctly, there were errors on last files on DVD, you could say "well that happens, DVD are faulty", but that's not the real issue when the problem appears it happens on each DVD I am trying to copy, last files on each disk have errors ...until I reboot Linux, then there are no errors at all and full DVD is copied correctly. Now I needed some files from DVDs and I realized the problem still exists. After at least three years. I verified that reboot helps and I also noticed the problem doesn't exist on Windows 7. And looks like I wasn't only one who found this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/404472 Problem was reported in 2009 on 2.6.28 and closed in 2012. But I noticed it in last days. my system is: Linux version 3.6.8-1-ARCH (tobias@T-POWA-LX) (gcc version 4.7.2 (GCC) ) #1 SMP PREEMPT Mon Nov 26 22:10:40 CET 2012 dmesg: [ 4017.384169] attempt to access beyond end of device [ 4017.384171] sr0: rw=0, want=8511124, limit=8433216 [ 4017.384174] attempt to access beyond end of device [ 4017.384175] sr0: rw=0, want=8510876, limit=8433216 I suspect that people just stopped using CDs and DVDs and that's why nobody was looking on this problem, or maybe the first though was always "that DVD is broken, trash it". Is there more information I could give you about this issue? Or could you point me to any ways I could debug it? It's fully reproducible on my system. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] kbuild: silence rule for extra_certificates
Michal Marek writes: > Added David and Rusty. > > On Sun, Nov 18, 2012 at 03:05:14PM -0500, pefol...@verizon.net wrote: >> From: Peter Foley >> >> Silence the touch extra_certificates command >> >> Signed-off-by: Peter Foley > > I think we should tell the user that the default empty extra > certificates list is being used, in case the user used a wrong filename > or similar. How about this? I prefer this one... Peter? Thanks, Rusty. > > Subject: MODSIGN: Fix kbuild output when using default extra_certificates > > Signed-off-by: Michal Marek > > diff --git a/kernel/Makefile b/kernel/Makefile > index 0dfeca4..8c708e4 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -136,8 +136,12 @@ ifeq ($(CONFIG_MODULE_SIG),y) > # > # Pull the signing certificate and any extra certificates into the kernel > # > + > +quiet_cmd_touch = TOUCH $@ > + cmd_touch = touch $@ > + > extra_certificates: > - touch $@ > + $(call cmd,touch) > > kernel/modsign_pubkey.o: signing_key.x509 extra_certificates > > But I don't insist on the above, feel free to hide the command > completely. > > Michal > >> --- >> kernel/Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/kernel/Makefile b/kernel/Makefile >> index 86e3285..18a0b61 100644 >> --- a/kernel/Makefile >> +++ b/kernel/Makefile >> @@ -137,7 +137,7 @@ ifeq ($(CONFIG_MODULE_SIG),y) >> # Pull the signing certificate and any extra certificates into the kernel >> # >> extra_certificates: >> -touch $@ >> +@touch $@ >> >> kernel/modsign_pubkey.o: signing_key.x509 extra_certificates >> >> -- >> 1.8.0 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] ARM: MM: Add the workaround of Errata 774769
On Mon, Dec 10, 2012 at 08:58:35AM +0900, Boojin Kim wrote: > > -3: mov r10, #0 > + /* Cortex-A15 Errata */ > +3: ldr r10, =0x0c0f@ Cortex-A15 primary part number > + teq r0, r10 > + bne 4f > +#ifdef CONFIG_ARM_ERRATA_774769 There's not much point testing for the part number of the work-around isn't enabled. > + teq r6, #0x4@ present in r0p4 > + mrceq p15, 0, r10, c1, c0, 1 @ read aux control register tsteq r10, #1 << 15 to avoid writing to the aux control register if the errata has already been applied. > + orreq r10, r10, #1 << 25 @ set bit #25 > + mcreq p15, 0, r10, c1, c0, 1 @ write aux control register > +#endif > + > +4: mov r10, #0 > mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate > dsb > #ifdef CONFIG_MMU > -- > 1.7.5.4 > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: MM: Add the workaround of Errata 766421
This patch adds the workaround of errata 766421 that adds 'dmb' when changing the translation regime after conditions that the errata 766421 may occur. Concretely, Add 'dmb' when changing ASID and secure state for cortex-A15 r0p4. Signed-off-by: Boojin Kim --- arch/arm/Kconfig | 13 + arch/arm/mach-exynos/Kconfig |1 + arch/arm/mm/proc-v7-2level.S |2 ++ 3 files changed, 16 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 93397da..9bd34dd 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1417,6 +1417,19 @@ config ARM_ERRATA_775420 to deadlock. This workaround puts DSB before executing ISB if an abort may occur on cache maintenance. +config ARM_ERRATA_766421 + bool "ARM errata: Strongly-Ordered/Device load or NC LDREX could return incorrect data" + depends on CPU_V7 + help + This option enables the workaround for the erratum 766421 affecting + Cortex-A15 erratum (r0p4). + In certain situations, a strongly ordered or device load instruction, + or a non-cacheable normal memory load-exclusive instruction could + match multiple fill buffers and return incorrect data. + This workaround is add DMB instruction when making any change to the + translation regime and before doing any new loads/stores/preloads + in the new translation regime. + config ARM_ERRATA_773022 bool "ARM errata: incorrect instructions may be executed from loop buffer" depends on CPU_V7 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index bb92f4c..4e28e1c 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -66,6 +66,7 @@ config SOC_EXYNOS5250 select S5P_PM if PM select S5P_SLEEP if PM select SAMSUNG_DMADEV + select ARM_ERRATA_766421 help Enable EXYNOS5250 SoC support diff --git a/arch/arm/mm/proc-v7-2level.S b/arch/arm/mm/proc-v7-2level.S index fd045e7..c663b2e 100644 --- a/arch/arm/mm/proc-v7-2level.S +++ b/arch/arm/mm/proc-v7-2level.S @@ -53,6 +53,8 @@ ENTRY(cpu_v7_switch_mm) #endif #ifdef CONFIG_ARM_ERRATA_754322 dsb +#elif CONFIG_ARM_ERRATA_766421 + dmb #endif mcr p15, 0, r1, c13, c0, 1 @ set context ID isb -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: MM: Add the workaround of Errata 773022
This patch adds the workaround of Errata 773022 that disables loop buffer. Signed-off-by: Boojin Kim --- arch/arm/Kconfig | 10 ++ arch/arm/mach-exynos/Kconfig |1 + arch/arm/mm/proc-v7.S|6 ++ 3 files changed, 17 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 11a57e2..93397da 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1417,6 +1417,16 @@ config ARM_ERRATA_775420 to deadlock. This workaround puts DSB before executing ISB if an abort may occur on cache maintenance. +config ARM_ERRATA_773022 + bool "ARM errata: incorrect instructions may be executed from loop buffer" + depends on CPU_V7 + help + This option enables the workaround for the erratum 773022 affecting + Cortex-A15 (r0p4). + In certain rare sequences of code, the loop buffer may deliver + incorrect instructions. + This workaround is to disable loop buffer. + config ARM_ERRATA_774769 bool "ARM errata: data corruption may occur with store streaming in a system" depends on CPU_V7 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index e1168fb..bb92f4c 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -22,6 +22,7 @@ config ARCH_EXYNOS4 config ARCH_EXYNOS5 bool "SAMSUNG EXYNOS5" select HAVE_SMP + select ARM_ERRATA_773022 select ARM_ERRATA_774769 help Samsung EXYNOS5 (Cortex-A15) SoC based systems diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 06cbdfa..0b4c518 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -249,6 +249,12 @@ __v7_setup: 3: ldr r10, =0x0c0f@ Cortex-A15 primary part number teq r0, r10 bne 4f +#ifdef CONFIG_ARM_ERRATA_773022 + teq r6, #0x4@ present in r0p4 + mrceq p15, 0, r10, c1, c0, 1 @ read aux control register + orreq r10, r10, #1 << 1 @ set bit #1 + mcreq p15, 0, r10, c1, c0, 1 @ write aux control register +#endif #ifdef CONFIG_ARM_ERRATA_774769 teq r6, #0x4@ present in r0p4 mrceq p15, 0, r10, c1, c0, 1 @ read aux control register -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: MM: Add the workaround of Errata 774769
This patch adds the workaround of Errata 774769 that configures write streaming on versions of A15 affected by this erratum such that no streaming-write ever allocates into the L2 cache. Signed-off-by: Boojin Kim --- arch/arm/Kconfig | 11 +++ arch/arm/mach-exynos/Kconfig |1 + arch/arm/mm/proc-v7.S| 16 ++-- 3 files changed, 26 insertions(+), 2 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 9759fec..11a57e2 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1417,6 +1417,17 @@ config ARM_ERRATA_775420 to deadlock. This workaround puts DSB before executing ISB if an abort may occur on cache maintenance. +config ARM_ERRATA_774769 + bool "ARM errata: data corruption may occur with store streaming in a system" + depends on CPU_V7 + help + This option enables the workaround for the erratum 774769 affecting + Cortex-A15 (r0p4). + External memory may be corrupted on erratum 774769. + The workaround is to configure write streaming on versions of A15 + affected by this erratum such that no streaming-write ever allocates + into the L2 cache. + endmenu source "arch/arm/common/Kconfig" diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index da55107..e1168fb 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -22,6 +22,7 @@ config ARCH_EXYNOS4 config ARCH_EXYNOS5 bool "SAMSUNG EXYNOS5" select HAVE_SMP + select ARM_ERRATA_774769 help Samsung EXYNOS5 (Cortex-A15) SoC based systems diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S index 846d279..06cbdfa 100644 --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -208,7 +208,7 @@ __v7_setup: orreq r10, r10, #(1 << 22)@ set the Write Allocate disable bit mcreq p15, 1, r10, c9, c0, 2 @ write the L2 cache aux ctrl register #endif - b 3f + b 4f /* Cortex-A9 Errata */ 2: ldr r10, =0x0c09@ Cortex-A9 primary part number @@ -243,8 +243,20 @@ __v7_setup: mcrlt p15, 0, r10, c15, c0, 1 @ write diagnostic register 1: #endif + b 4f -3: mov r10, #0 + /* Cortex-A15 Errata */ +3: ldr r10, =0x0c0f@ Cortex-A15 primary part number + teq r0, r10 + bne 4f +#ifdef CONFIG_ARM_ERRATA_774769 + teq r6, #0x4@ present in r0p4 + mrceq p15, 0, r10, c1, c0, 1 @ read aux control register + orreq r10, r10, #1 << 25 @ set bit #25 + mcreq p15, 0, r10, c1, c0, 1 @ write aux control register +#endif + +4: mov r10, #0 mcr p15, 0, r10, c7, c5, 0 @ I+BTB cache invalidate dsb #ifdef CONFIG_MMU -- 1.7.5.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: [Bulk] [PATCH] drivers/video/wm8505fb.c: use devm_ functions
On Sun, 2012-12-09 at 19:08 +0100, Julia Lawall wrote: > From: Julia Lawall > > The various devm_ functions allocate memory that is released when a driver > detaches. This patch uses these functions for data that is allocated in > the probe function of a platform device and is only freed in the remove > function. > > The patch makes some other cleanups. First, the original code used > devm_kzalloc, but kfree. This would lead to a double free. The problem > was found using the following semantic match (http://coccinelle.lip6.fr/): > > // > @@ > expression x,e; > @@ > x = devm_kzalloc(...) > ... when != x = e > ?-kfree(x,...); > // > > The error-handing code of devm_request_and_ioremap does not print any > warning message, because devm_request_and_ioremap does this. > > The call to dma_alloc_coherent is converted to its devm equivalent, > dmam_alloc_coherent. This implicitly introduces a call to > dmam_free_coherent, which was completly missing in the original code. > > A semicolon is removed at the end of the error-handling code for the call > to dma_alloc_coherent. > > The block of code calling fb_alloc_cmap is moved below the block of code > calling wm8505fb_set_par, so that the error-handing code of the call to > wm8505fb_set_par can just return ret. This way there is only one block of > error-handling code that needs to call fb_dealloc_cmap, and so this is > moved up to the place where it is needed, eliminating the need for all > gotos and labels in the function. This was suggested by Tony Prisk. > > The initializations of fbi and ret at the beginning of the function are not > necessary and are removed. The call platform_set_drvdata(pdev, NULL); at > the end of the function is also removed. > > Signed-off-by: Julia Lawall > > --- > Only compiled. Not tested. Thanks Julia, I will include this with the other patches we have for fbdev. I have tested this on WM8650 and all appears fine. Regards Tony P -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
