Re: [patch v4 07/18] sched: set initial load avg of new forked task
On Fri, Feb 15, 2013 at 2:07 AM, Alex Shi alex@intel.com wrote: diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 1dff78a..9d1c193 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1557,8 +1557,8 @@ static void __sched_fork(struct task_struct *p) * load-balance). */ #if defined(CONFIG_SMP) defined(CONFIG_FAIR_GROUP_SCHED) - p-se.avg.runnable_avg_period = 0; - p-se.avg.runnable_avg_sum = 0; + p-se.avg.runnable_avg_period = 1024; + p-se.avg.runnable_avg_sum = 1024; It can't work. avg.decay_count needs to be set to 0 before enqueue_entity_load_avg(), then update_entity_load_avg() can't be called, so, runnable_avg_period/sum are unusable. Well we _could_ also use a negative decay_count here and treat it like a migration; but the larger problem is the visibility of p-on_rq; which is gates whether we account the time as runnable and occurs after activate_task() so that's out. Even we has chance to call __update_entity_runnable_avg(), avg.last_runnable_update needs be set before that, usually, it needs to be set as 'now', that cause __update_entity_runnable_avg() function return 0, then update_entity_load_avg() still can not reach to __update_entity_load_avg_contrib(). If we embed a simple new task load initialization to many functions, that is too hard for future reader. This is my concern about making this a special case with the introduction ENQUEUE_NEWTASK flag; enqueue jumps through enough hoops as it is. I still don't see why we can't resolve this at init time in __sched_fork(); your patch above just moves an explicit initialization of load_avg_contrib into the enqueue path. Adding a call to __update_task_entity_contrib() to the previous alternate suggestion would similarly seem to resolve this? #endif #ifdef CONFIG_SCHEDSTATS memset(p-se.statistics, 0, sizeof(p-se.statistics)); -- Thanks Alex -- Thanks Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] dma: timb_dma: Fix compiler warning
On 02/18/2013 08:59 PM, maxin.j...@gmail.com wrote:
From: Maxin B. John maxin.j...@enea.com
Fix this compiler warning:
warning: 'td_remove' defined but not used [-Wunused-function]
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
drivers/dma/timb_dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
index 952f823..f709279 100644
--- a/drivers/dma/timb_dma.c
+++ b/drivers/dma/timb_dma.c
@@ -798,7 +798,7 @@ err_release_region:
}
-static int td_remove(struct platform_device *pdev)
+static int __exit td_remove(struct platform_device *pdev)
{
While this fixes the warning, it's the wrong fix. The correct fix is to
remove the __exit_p. E.g. something like this:
--- a/drivers/dma/timb_dma.c
+++ b/drivers/dma/timb_dma.c
@@ -823,7 +823,7 @@ static struct platform_driver td_driver = {
.owner = THIS_MODULE,
},
.probe = td_probe,
- .remove = __exit_p(td_remove),
+ .remove = td_remove,
};
module_platform_driver(td_driver);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: SYSFS errors
On Tue, Feb 19, 2013 at 08:11:49AM -0300, Mauro Carvalho Chehab wrote:
I remember I saw some discussions about it in the past at bluesmoke ML,
saying that -ENODEV is the expected behavior when this is not supported.
Changing from -ENODEV to N/A will break anything that would be relying
on the previous behavior. So, I think that such change will for sure break
userspace.
If we're willing to change it, not creating the sdram_scrub_rate sysfs
node is less likely to affect userspace.
This will break scripts which assume this file's presence implicitly.
[ … ]
@@ -1017,6 +1010,14 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info
*mci)
return err;
}
+ if (mci-set_sdram_scrub_rate mci-get_sdram_scrub_rate) {
This will break cpc925_edac.c because it defines a
-get_sdram_scrub_rate but not a -set_sdram_scrub_rate.
I think a maybe better fix would be to figure out the sysfs file
permissions based on the presence of the two functions and *then* add
the attribute.
This way, the only visible change to userspace is the corrected sysfs
file permissions.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] vfs: always protect diretory file-fpos with inode mutex
On 2013/2/19 17:19, Jan Kara wrote:
On Tue 19-02-13 09:22:40, Li Zefan wrote:
There's a long long-standing bug...As long as I don't know when it dates
from.
I've written and attached a simple program to reproduce this bug, and it can
immediately trigger the bug in my box. It uses two threads, one keeps calling
read(), and the other calling readdir(), both on the same directory fd.
So the fact that read() or even write() to fd opened O_RDONLY has *any*
effect on f_pos looks really unexpected to me. I think we really should
have there:
if (ret = 0)
file_pos_write(...);
I thought about this. The problem is then we have to check every fop-write()
to see if any of them can return -errno with file-f_pos changed and fix them,
though it's do-able.
That would solve problems with read() and write() on directories for
pretty much every filesystem since the first usually returns -EISDIR and
the second -EBADF.
Yeah, seems ceph is the only filesystem that allows read() on directories.
When I ran it on ext3 (can be replaced with ext2/ext4) which has _dir_index_
feature disabled, I got this:
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=993, inode=0, rec_len=0, name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=1009, inode=0, rec_len=0, name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=993, inode=0, rec_len=0, name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=1009, inode=0, rec_len=0, name_len=0
...
If we configured errors=remount-ro, the filesystem will become read-only.
SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
{
...
loff_t pos = file_pos_read(file);
ret = vfs_read(file, buf, count, pos);
file_pos_write(file, pos);
fput_light(file, fput_needed);
...
}
While readdir() is protected with i_mutex, f_pos can be changed without
any locking in various read()/write() syscalls, which leads to this bug.
What makes things worse is Andi removed i_mutex from generic_file_llseek,
so you can trigger the same bug by replacing read() with lseek() in the
test program.
Yes, and here I'd say it's a filesystem issue. If filesystem needs f_pos
changed only under i_mutex, it should use default_llseek() or get the mutex
itself. That's what the callback is for. We shouldn't unnecessarily impose
the i_mutex restriction on llseek on a directory for every filesystem.
One of my concern is, concurrent lseek() and readdir() doesn't seem to be
well tested. I'll add a test case in xfstests.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] vfs: always protect diretory file-fpos with inode mutex
On 2013/2/19 17:19, Jan Kara wrote:
On Tue 19-02-13 09:22:40, Li Zefan wrote:
There's a long long-standing bug...As long as I don't know when it dates
from.
I've written and attached a simple program to reproduce this bug, and it can
immediately trigger the bug in my box. It uses two threads, one keeps calling
read(), and the other calling readdir(), both on the same directory fd.
So the fact that read() or even write() to fd opened O_RDONLY has *any*
effect on f_pos looks really unexpected to me. I think we really should
have there:
if (ret = 0)
file_pos_write(...);
I thought about this. The problem is then we have to check every fop-write()
to see if any of them can return -errno with file-f_pos changed and fix them,
though it's do-able.
That would solve problems with read() and write() on directories for
pretty much every filesystem since the first usually returns -EISDIR and
the second -EBADF.
Yeah, seems ceph is the only filesystem that allows read() on directories.
When I ran it on ext3 (can be replaced with ext2/ext4) which has _dir_index_
feature disabled, I got this:
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=993, inode=0, rec_len=0, name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=1009, inode=0, rec_len=0, name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=993, inode=0, rec_len=0, name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=1009, inode=0, rec_len=0, name_len=0
...
If we configured errors=remount-ro, the filesystem will become read-only.
SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
{
...
loff_t pos = file_pos_read(file);
ret = vfs_read(file, buf, count, pos);
file_pos_write(file, pos);
fput_light(file, fput_needed);
...
}
While readdir() is protected with i_mutex, f_pos can be changed without
any locking in various read()/write() syscalls, which leads to this bug.
What makes things worse is Andi removed i_mutex from generic_file_llseek,
so you can trigger the same bug by replacing read() with lseek() in the
test program.
Yes, and here I'd say it's a filesystem issue. If filesystem needs f_pos
changed only under i_mutex, it should use default_llseek() or get the mutex
itself. That's what the callback is for. We shouldn't unnecessarily impose
the i_mutex restriction on llseek on a directory for every filesystem.
One of my concern is, concurrent lseek() and readdir() doesn't seem to be
well tested. I'll add a test case in xfstests.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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[6]: [PATCH v3] mfd: syscon: Add non-DT support
...
struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
{
struct device_node *syscon_np;
struct regmap *regmap;
+ struct syscon *syscon;
+ struct device *dev;
syscon_np = of_find_compatible_node(NULL, NULL, s);
- if (!syscon_np)
+ if (syscon_np) {
+ regmap = syscon_node_to_regmap(syscon_np);
+ of_node_put(syscon_np);
+
+ return regmap;
+ }
+
+ /* Fallback to search by id_entry.name string */
+ dev = driver_find_device(syscon_driver.driver, NULL, (void
*)s,
+ syscon_match_id);
+ if (!dev)
return ERR_PTR(-ENODEV);
- regmap = syscon_node_to_regmap(syscon_np);
- of_node_put(syscon_np);
+ syscon = dev_get_drvdata(dev);
- return regmap;
+ return syscon-regmap;
}
EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
Since you are not actually comparing the compatible property here,
I would suggest adding another function here,
Yes, i also think like that.
In this case we should provide two paths for drivers which can work as
with DT
and without DT.
Yes.
I still think the universal procedure is better for the driver.
Why?
I did not see your reply on my other comments on the problems of using
universal
procedure?
Please let me know if you think they're not issues.
Yes, I do not see a problem here.
I will try to show the code.
In the driver:
struct regmap *r;
r = syscon_regmap_lookup_by_compatible(my_super_syscon);
For DT case:
syscon@123456 {
compatible = my_super_syscon, syscon;
...
};
For non-DT case:
struct platform_device_id id = { .name = my_super_syscon, };
struct platform_device syscon_pdev = {
.name = syscon,
.id_entry = id,
...
};
platform_device_register(syscon_pdev);
Do I understand what you mean?
Thanks.
---
[PATCH] fat: instead of constant number, use the i_blkbits of struct inode to calculate the number of blocks
To calculate the number of blocks from the number of clusters, use the i_blkbits of struct inode instead of 9. Signed-off-by: Hyeoncheol Lee hyc@gmail.com --- fs/fat/misc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fat/misc.c b/fs/fat/misc.c index 6d93360..ccdf663 100644 --- a/fs/fat/misc.c +++ b/fs/fat/misc.c @@ -156,7 +156,7 @@ int fat_chain_add(struct inode *inode, int new_dclus, int nr_cluster) (llu)(inode-i_blocks (sbi-cluster_bits - 9))); fat_cache_inval_inode(inode); } - inode-i_blocks += nr_cluster (sbi-cluster_bits - 9); + inode-i_blocks += nr_cluster (sbi-cluster_bits - inode-i_blkbits); return 0; } -- 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] fat: instead of constant number, use the i_blkbits of struct inode to calculate the number of blocks
Hyeoncheol Lee hyc@gmail.com writes: To calculate the number of blocks from the number of clusters, use the i_blkbits of struct inode instead of 9. Signed-off-by: Hyeoncheol Lee hyc@gmail.com --- fs/fat/misc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fat/misc.c b/fs/fat/misc.c index 6d93360..ccdf663 100644 --- a/fs/fat/misc.c +++ b/fs/fat/misc.c @@ -156,7 +156,7 @@ int fat_chain_add(struct inode *inode, int new_dclus, int nr_cluster) (llu)(inode-i_blocks (sbi-cluster_bits - 9))); fat_cache_inval_inode(inode); } - inode-i_blocks += nr_cluster (sbi-cluster_bits - 9); + inode-i_blocks += nr_cluster (sbi-cluster_bits - inode-i_blkbits); No. Unit of -i_blocks is 512bytes always. So, 9 is right number. return 0; } -- OGAWA Hirofumi hirof...@mail.parknet.co.jp -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
THP bug and crash on sparc64 3.8
I am receiving this with 3.8.0 on Sun E420R (4G RAM, 4 CPUs). System
hangs after logging this to syslog. It was busy running ap at the
moment of crash.
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
BUG: sleeping function called from invalid context at mm/slub.c:925
in_atomic(): 1, irqs_disabled(): 0, pid: 327, name: khugepaged
2 locks held by khugepaged/327:
#0: (mm-mmap_sem){++}, at: [00516964]
khugepaged+0x624/0xf80
#1: ((mm-page_table_lock)-rlock){+.+.+.}, at: [00517078]
khugepaged+0xd38/0xf
Call Trace:
[00488d9c] __might_sleep+0x13c/0x240
[0051204c] kmem_cache_alloc+0xcc/0x120
[0044bfc0] tsb_grow+0x80/0x480
[0044e814] hugetlb_setup+0x14/0xc0
[0044bcb0] set_pmd_at+0x110/0x120
[005170b8] khugepaged+0xd78/0xf80
[0047e508] kthread+0x88/0xa0
[004060a4] ret_from_syscall+0x1c/0x2c
[] (null)
--
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fadvise: Drain all pagevecs if POSIX_FADV_DONTNEED fails to discard all pages
On Thu, Feb 14, 2013 at 12:39:26PM -0800, Andrew Morton wrote:
On Thu, 14 Feb 2013 12:03:49 +
Mel Gorman mgor...@suse.de wrote:
Rob van der Heij reported the following (paraphrased) on private mail.
The scenario is that I want to avoid backups to fill up the page
cache and purge stuff that is more likely to be used again (this is
with s390x Linux on z/VM, so I don't give it as much memory that
we don't care anymore). So I have something with LD_PRELOAD that
intercepts the close() call (from tar, in this case) and issues
a posix_fadvise() just before closing the file.
This mostly works, except for small files (less than 14 pages)
that remains in page cache after the face.
Sigh. We've had the my backups swamp pagecache thing for 15 years
and it's still happening.
Yes. There have been variations of it too such as applications being pushed
prematurely into swap. I'm not certain how well we currently handle that
because I haven't checked in a few months.
It should be possible nowadays to toss your backup application into a
container to constrain its pagecache usage. So we can type
run-in-a-memcg -m 200MB /my/backup/program
and voila. Does such a script exist and work?
Michal already gave an example. It might work slower if the backup
application has to stall in direct reclaim to keep the container within
limits though.
--- a/mm/fadvise.c
+++ b/mm/fadvise.c
@@ -17,6 +17,7 @@
#include linux/fadvise.h
#include linux/writeback.h
#include linux/syscalls.h
+#include linux/swap.h
#include asm/unistd.h
@@ -120,9 +121,22 @@ SYSCALL_DEFINE(fadvise64_64)(int fd, loff_t offset,
loff_t len, int advice)
start_index = (offset+(PAGE_CACHE_SIZE-1)) PAGE_CACHE_SHIFT;
end_index = (endbyte PAGE_CACHE_SHIFT);
- if (end_index = start_index)
- invalidate_mapping_pages(mapping, start_index,
+ if (end_index = start_index) {
+ unsigned long count = invalidate_mapping_pages(mapping,
+ start_index, end_index);
+
+ /*
+* If fewer pages were invalidated than expected then
+* it is possible that some of the pages were on
+* a per-cpu pagevec for a remote CPU. Drain all
+* pagevecs and try again.
+*/
+ if (count (end_index - start_index + 1)) {
+ lru_add_drain_all();
+ invalidate_mapping_pages(mapping, start_index,
end_index);
+ }
+ }
break;
default:
ret = -EINVAL;
Those LRU pagevecs are a right pain. They provided useful gains way
back when I first inflicted them upon Linux, but it would be nice to
confirm whether they're still worthwhile and if so, whether the
benefits can be replicated with some less intrusive scheme.
I know. Unfortunately I've had Implement pagevec removal and test on my
TODO list for the guts of a year now. It's long overdue to actually sit down
and just do it. It's a similar story for the per-cpu lists in front of the
page allocator which are overdue to see if they can be replaced. I actually
have a prototype replacement for that lying around but it performed slower
in tests and has bit-rotted since but it ran slower and has bit-rotted
since as it was based on kernel 3.4.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] param, charp: Cache val length
On Mon, Feb 18, 2013 at 09:54:22PM +1030, Rusty Russell wrote: I'm delighted with your enthusiasm for making trivial changes, Who says I'm enthusiastic about it? but I have trouble sharing in it. I just assumed that noodling for a second time over a string of possible length of 1024 chars (I know, I know, we will never have params of that length, yadda yadda...) should be avoided. Nevermind. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 EDAC 07/13] edac: add support for raw error reports
Em Mon, 18 Feb 2013 12:24:29 -0300 Mauro Carvalho Chehab mche...@redhat.com escreveu: Em Mon, 18 Feb 2013 14:52:51 +0100 Borislav Petkov b...@alien8.de escreveu: On Sun, Feb 17, 2013 at 07:44:04AM -0300, Mauro Carvalho Chehab wrote: We could do it for the location. The space for label, however, depends on how many DIMMs are in the system, as multiple dimm's may be present, and the core will point to all possible affected DIMMs. Ok, perhaps we could just allocate one big area for it (like one page), as this would very likely be enough for it, and change the logic to take the buffer size into account when filling it. Or, in the case where -label is all dimms on the mci, you simply put All DIMMs on MCI%d in there and done. Simple. The core does this already when it has no glue at all about where is the error. The core is prepared to the case where the location is only half-filled, as this is a common scenario on the drivers, and important enough on some memory controllers. As already discussed, on most memory controllers nowadays, the memory controller can't point to a single DIMM, as the error correction code takes 128 bits (2 DIMMs). It is impossible for the error correction code to determine on what DIMM an uncorrected error happened[1]. With Nehalem memory controllers, depending on the memory configuration, the minimal DIMM granularity for an uncorrected error can be even worse: 4 DIMMs, if 128-bits error correction code and mirror mode are both enabled. There are some border cases where the driver can simply not discover on what channel or on what dimm(or csrow) inside a channel the error happened. The error could be associated with some failure at the logic or at the bus that communicated with the Advanced Memory Buffers on an FB-DIMM memory controller, for example. So, the real core's worse case scenario would be if the driver can't determine on what DIMM inside a channel the error happened. As a channel can have a large number of DIMMs[2] the allocated area for the label should be conservative. (16? Not sure what's the worse case), [1] such error can even not be fatal, if that particular address is unused. [2] Currently, up to 8, according with: $for i in $(git grep layers.*size\s*= drivers/edac|perl -ne 'print $1 if (m/\=\s*([A-Z][^\s]+);/);'); do echo $i; git grep $i drivers/edac; done|grep define|perl -ne 'print $1 if (m/define\s+[^\s]+\s(\d+)/)' 8 8 2 2 4 2 3 3 3 8 4 4 3 3 1 1 4 and $ git grep layers.*size\s*= drivers/edac|perl -ne 'print $1 if (m/\=\s*(\d+);/);' 1 1 1 1 2 2 8 4 1 1 1 1 Nothing prevents that a driver would have more than 8 DIMMs per layer in the future. I suspect that you'll be happy with the enclosed patch ;) It embeds the two string buffers at the mci structure. There are space there for up to EDAC_MAX_LABELS at the mci-label string. If an error affects more than EDAC_MAX_LABELS, the report logic will write any memory, just like what happens when the driver can't discover where the error is. Tested with sb_edac driver. Regards, Mauro [PATCH EDAC] edac: put all arguments for the raw error handling call into a struct The number of arguments for edac_raw_mc_handle_error() is too big; put them into a structure and allocate space for it inside edac_mc_alloc(). That reduces a lot the stack usage and simplifies the raw API call. Tested with sb_edac driver and MCE error injection. Worked as expected: [ 143.066100] EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x320 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0) [ 143.086424] EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x320 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0) [ 143.106570] EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x320 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0) [ 143.126712] EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x320 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0) Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/edac/edac_core.h b/drivers/edac/edac_core.h index 9c5da11..3c2625e 100644 --- a/drivers/edac/edac_core.h +++ b/drivers/edac/edac_core.h @@ -455,20 +455,8 @@ extern int edac_mc_find_csrow_by_page(struct mem_ctl_info *mci, unsigned long page); void edac_raw_mc_handle_error(const enum hw_event_mc_err_type type, - struct mem_ctl_info *mci, - long grain, - const u16 error_count, - const int top_layer, -
[PATCH 1/2] staging/sep: Fix smatch false positive about potential NULL dereference in sep_main.c
Smatch complains about a potential NULL pointer dereference:
sep_main.c:2312 sep_construct_dma_tables_from_lli() error: potential
NULL dereference 'info_out_entry_ptr'.
info_out_entry_ptr is initialized with NULL and if info_in_entry_ptr is
not NULL it gets derefenced.
However info_out_entry_ptr is only NULL in the first iteration of the
while loop and in this case info_in_entry_ptr is also NULL (as indicated
by the comment /* If info entry is null - this is the first table built */
- this is a false positive.
Nevertheless we add a check for info_out_entry_ptr to silence this
warning and make it more robust in regard to code changes.
Signed-off-by: Peter Huewe peterhu...@gmx.de
---
drivers/staging/sep/sep_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/sep/sep_main.c b/drivers/staging/sep/sep_main.c
index 30e8d25..366d56b 100644
--- a/drivers/staging/sep/sep_main.c
+++ b/drivers/staging/sep/sep_main.c
@@ -2276,7 +2276,7 @@ static int sep_construct_dma_tables_from_lli(
table_data_size);
/* If info entry is null - this is the first table built */
- if (info_in_entry_ptr == NULL) {
+ if (info_in_entry_ptr == NULL || info_out_entry_ptr == NULL) {
/* Set the output parameters to physical addresses */
*lli_table_in_ptr =
sep_shared_area_virt_to_bus(sep, dma_in_lli_table_ptr);
--
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/
[PATCH 2/2] staging/sep: Check pointers before dereferencing (fix smatch warning)
smatch complains about two dereferenced before check issues:
sep_main.c:2898 sep_free_dma_tables_and_dcb() warn: variable dereferenced
before check
'dma_ctx' (see line 2885)
sep_main.c:2898 sep_free_dma_tables_and_dcb() warn: variable dereferenced
before check
'*dma_ctx' (see line 2885)
- Move the checks to the top, but keep the semantics.
Signed-off-by: Peter Huewe peterhu...@gmx.de
---
drivers/staging/sep/sep_main.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/sep/sep_main.c b/drivers/staging/sep/sep_main.c
index 366d56b..f5b7341 100644
--- a/drivers/staging/sep/sep_main.c
+++ b/drivers/staging/sep/sep_main.c
@@ -2880,6 +2880,8 @@ static int sep_free_dma_tables_and_dcb(struct sep_device
*sep, bool isapplet,
dev_dbg(sep-pdev-dev, [PID%d] sep_free_dma_tables_and_dcb\n,
current-pid);
+ if (!dma_ctx || !*dma_ctx) /* nothing to be done here*/
+ return 0;
if (((*dma_ctx)-secure_dma == false) (isapplet == true)) {
dev_dbg(sep-pdev-dev, [PID%d] handling applet\n,
@@ -2895,8 +2897,7 @@ static int sep_free_dma_tables_and_dcb(struct sep_device
*sep, bool isapplet,
* Go over each DCB and see if
* tail pointer must be updated
*/
- for (i = 0; dma_ctx *dma_ctx
- i (*dma_ctx)-nr_dcb_creat; i++, dcb_table_ptr++) {
+ for (i = 0; i (*dma_ctx)-nr_dcb_creat; i++, dcb_table_ptr++)
{
if (dcb_table_ptr-out_vr_tail_pt) {
pt_hold = (unsigned long)dcb_table_ptr-
out_vr_tail_pt;
--
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: [RFT][PATCH 1/2] regulator: ab8500: Fix build error
On Mon, Feb 18, 2013 at 10:24:21AM +, Lee Jones wrote: The patches which caused the issues addressed by this patch-set have since been rewritten. I have subsequently requested that Mark deletes the AB8500 for-next branch. We're going to start again after this merge window. So, as discussed you really shouldn't have done that - unless there's a very serious problem you should be assuming that patches that have been applied are going to stay applied and working from the latest upstream tree. Once something is in -next the expectation is that it's going to be sent during the next merge window. As well as the issues with maintainers getting fed up having to look at the same code over and over again it causes people like Axel to waste their time. However I am probably going to just throw away the current ab8500 work this time. Please resend your patches after the merge window (which just opened). signature.asc Description: Digital signature
Re: THP bug and crash on sparc64 3.8
(Resent to correct cparclinux address)
I am receiving this with 3.8.0 on Sun E420R (4G RAM, 4 CPUs). System
hangs after logging this to syslog. It was busy running ap at the
moment of crash.
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
BUG: sleeping function called from invalid context at mm/slub.c:925
in_atomic(): 1, irqs_disabled(): 0, pid: 327, name: khugepaged
2 locks held by khugepaged/327:
#0: (mm-mmap_sem){++}, at: [00516964]
khugepaged+0x624/0xf80
#1: ((mm-page_table_lock)-rlock){+.+.+.}, at: [00517078]
khugepaged+0xd38/0xf
Call Trace:
[00488d9c] __might_sleep+0x13c/0x240
[0051204c] kmem_cache_alloc+0xcc/0x120
[0044bfc0] tsb_grow+0x80/0x480
[0044e814] hugetlb_setup+0x14/0xc0
[0044bcb0] set_pmd_at+0x110/0x120
[005170b8] khugepaged+0xd78/0xf80
[0047e508] kthread+0x88/0xa0
[004060a4] ret_from_syscall+0x1c/0x2c
[] (null)
--
Meelis Roos (mr...@ut.ee) http://www.cs.ut.ee/~mroos/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 0/15] power aware scheduling
FYI I'm currently out of the country in New Zealand and won't be able to take a proper look at this until the beginning of March. On Mon, Feb 18, 2013 at 6:07 PM, Alex Shi alex@intel.com wrote: Since the simplification of fork/exec/wake balancing has much arguments, I removed that part in the patch set. This patch set implement/consummate the rough power aware scheduling proposal: https://lkml.org/lkml/2012/8/13/139. It defines 2 new power aware policy 'balance' and 'powersaving', then try to pack tasks on each sched groups level according the different scheduler policy. That can save much power when task number in system is no more than LCPU number. As mentioned in the power aware scheduling proposal, Power aware scheduling has 2 assumptions: 1, race to idle is helpful for power saving 2, less active sched groups will reduce cpu power consumption The first assumption make performance policy take over scheduling when any group is busy. The second assumption make power aware scheduling try to pack disperse tasks into fewer groups. Like sched numa, power aware scheduling is also a kind of cpu locality oriented scheduling, so it is natural compatible with sched numa. Since the patch can perfect pack tasks into fewer groups, I just show some performance/power testing data here: = $for ((i = 0; i I; i++)) ; do while true; do :; done done On my SNB laptop with 4core* HT: the data is avg Watts powersaving balance performance i = 2 40 54 54 i = 4 57 64* 68 i = 8 68 68 68 Note: When i = 4 with balance policy, the power may change in 57~68Watt, since the HT capacity and core capacity are both 1. on SNB EP machine with 2 sockets * 8 cores * HT: powersaving balance performance i = 4 190 201 238 i = 8 205 241 268 i = 16 271 348 376 bltk-game with openarena, the data is avg Watts powersaving balance performance wsm laptop 22.9 23.8 24.4 snb laptop 20.2 20.5 20.7 tasks number keep waving benchmark, 'make -j x vmlinux' on my SNB EP 2 sockets machine with 8 cores * HT: powersaving balanceperformance x = 1175.603 /417 13 175.220 /416 13176.073 /407 13 x = 2192.215 /218 23 194.522 /202 25217.393 /200 23 x = 4205.226 /124 39 208.823 /114 42230.425 /105 41 x = 8236.369 /71 59 249.005 /65 61 257.661 /62 62 x = 16 283.842 /48 73 307.465 /40 81 309.336 /39 82 x = 32 325.197 /32 96 333.503 /32 93 336.138 /32 92 data explains: 175.603 /417 13 175.603: average Watts 417: seconds(compile time) 13: scaled performance/power = 100 / seconds / watts Another testing of parallel compress with pigz on Linus' git tree. results show we get much better performance/power with powersaving and balance policy: testing command: #pigz -k -c -p$x -r linux* /dev/null On a NHM EP box powersaving balance performance x = 4166.516 /88 68 170.515 /82 71 165.283 /103 58 x = 8173.654 /61 94 177.693 /60 93 172.31 /76 76 On a 2 sockets SNB EP box. powersaving balance performance x = 4190.995 /149 35 200.6 /129 38 208.561 /135 35 x = 8197.969 /108 46 208.885 /103 46213.96 /108 43 x = 16 205.163 /76 64 212.144 /91 51 229.287 /97 44 data format is: 166.516 /88 68 166.516: average Watts 88: seconds(compress time) 68: scaled performance/power = 100 / time / power Some performance testing results: - Tested benchmarks: kbuild, specjbb2005, oltp, tbench, aim9, hackbench, fileio-cfq of sysbench, dbench, aiostress, multhreads loopback netperf. on my core2, nhm, wsm, snb, platforms. no clear performance change found on 'performance' policy. Tested balance/powersaving policy with above benchmarks, a, specjbb2005 drop 5~7% on both of policy whenever with openjdk or jrockit. b, hackbench drops 30+% with powersaving policy on snb 4 sockets platforms. Others has no clear change. test result from Mike Galbraith: With aim7 compute on 4 node 40 core box, I see stable throughput improvement at tasks = nr_cores and below w. balance and powersaving. 3.8.0-performance 3.8.0-balance 3.8.0-powersaving Tasksjobs/min/task jobs/min/task jobs/min/task 1 432.8571 433.4764 433.1665 5 480.1902 510.9612 497.5369 10
Re: [PATCH, RFC 1/8] ARM: localtimer: return percpu clkevt on register
Hi,
On Mon, Feb 18, 2013 at 05:06:39PM +0530, Afzal Mohammed wrote:
@@ -315,6 +315,7 @@ static struct local_timer_ops twd_lt_ops __cpuinitdata = {
static int __init twd_local_timer_common_register(struct device_node *np)
{
int err;
+ struct clock_event_device *evt;
twd_evt = alloc_percpu(struct clock_event_device *);
if (!twd_evt) {
@@ -328,8 +329,8 @@ static int __init twd_local_timer_common_register(struct
device_node *np)
goto out_free;
}
- err = local_timer_register(twd_lt_ops);
- if (err)
+ evt = local_timer_register(twd_lt_ops);
+ if (IS_ERR(evt))
goto out_irq;
this is wrong. Will return 0 even in the error case. Correct version
would be:
if (IS_ERR(evt)) {
err = PTR_ERR(evt);
goto out_irq;
}
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH, RFC 2/8] ARM: twd: register clock event for 1 core SMP
On Tue, Feb 19, 2013 at 03:44:14PM +0530, Santosh Shilimkar wrote: On Monday 18 February 2013 05:07 PM, Afzal Mohammed wrote: Register percpu local timer for scheduler tick in the case of one core SMP configuration. In other cases - secondary cpu's as well as boot cpu's having more than one core, this is being registered as per existing boot flow, with a difference that they happens after delay calibration. Registering the clock for tick in case of one core should be done before Kernel calibrates delay (this is required to boot, unless local timer is the only one registered for tick). Registering twd local timer at init_time (which platforms are doing now) helps achieve that with the proposed change. This helps in an almost booting Kernel (minimal) by only relying on ARM parts for an A9 one core SMP. Signed-off-by: Afzal Mohammed af...@ti.com --- As mentioned in cover-letter, I don't think we have good reasoning to make TWD to work with UP configuration. Even you fix the timer code, there are more cascaded dependencies which is not worth the effort. if CONFIG_SMP_ON_UP is enabled, smp_twd.c can still be compiled, right ? -- balbi signature.asc Description: Digital signature
Re: Linux 3.8
On Tue, Feb 19, 2013 at 01:15:15PM +1100, Stephen Rothwell wrote: So, presumably the merge window is open and Linus will start pulling trees shortly. So, here I go again: Please do *not* rebase your tree before asking Linus to pull it. Grumble, I did a small rebase after the window opened but before I knew it did. The rebase was just to add an Acked-by to the change log and no code change what so ever. I put it into linux-next to get testing while waiting on the ack, and after the ack, I pushed it to Ingo. Original commit: 5ec8d0104fd81d86cb7386c228e73ae635f1d74d After Ack added: 8c189ea64eea01ca20d102ddb74d6936dd16c579 Feel free to do the diff. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] AMD64_EDAC stuff for 3.9
Hi Linus, please pull the following updates for (mostly) AMD's side of EDAC. It is basically a new family enablement stuff - the rest is trivial cleanups. Thanks. The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619: Linux 3.8-rc4 (2013-01-17 19:25:45 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_3.9 for you to fetch changes up to e7d2c215e56dc9fa0a01e26f2acfc3d73c889ba3: mpc85xx_edac: Fix typo (2013-02-10 13:28:41 +0100) EDAC updates for 3.9 Only one: AMD F16h MCE decoding enablement from Jacob Shin. Baruch Siach (1): mpc85xx_edac: Fix typo Borislav Petkov (2): amd64_edac: Remove dead code EDAC, MCE, AMD: Remove unneeded exports Jacob Shin (2): EDAC, MCE, AMD: Make MC2 decoding per-family EDAC, MCE, AMD: Add MCE decoding support for Family 16h drivers/edac/amd64_edac.c | 105 -- drivers/edac/mce_amd.c | 166 +++-- drivers/edac/mce_amd.h | 13 - drivers/edac/mpc85xx_edac.c | 4 +-- 4 files changed, 120 insertions(+), 168 deletions(-) -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] ptrace: add ability to retrieve signals without removing them from a queue
On Wed, Feb 13, 2013 at 4:16 PM, Andrey Vagin ava...@openvz.org wrote:
This patch adds a new ptrace request PTRACE_PEEKSIGINFO.
This request is used to retrieve information about a signal with the
specified sequence number. A siginfo_t structure is copied from the child
to location data in the parent.
The low 16 bits of addr contains a sequence number of signal in a queue:
I think 16 bits is probably not enough Already, on the out of the
box system that I have at hand, one can queue more than 2^16-1
signals:
$ cat /proc/$$/status | grep SigQ
SigQ: 2/126065
Cheers,
Michael
All other bits of addr is used for flags. Currently here is only one
flag PTRACE_PEEK_SHARED for dumping signals from process-wide shared
queue. If this flag is not set, a signal is read from a per-thread
queue. A result siginfo contains a kernel part of si_code which usually
striped, but it's required for queuing the same siginfo back during
restore of pending signals.
If a signal with the specified sequence number doesn't exist, ptrace
returns ENOENT.
This functionality is required for checkpointing pending signals.
The prototype of this code was developed by Oleg Nesterov.
Cc: Roland McGrath rol...@redhat.com
Cc: Oleg Nesterov o...@redhat.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: David Howells dhowe...@redhat.com
Cc: Dave Jones da...@redhat.com
Cc: Michael Kerrisk (man-pages) mtk.manpa...@gmail.com
Cc: Pavel Emelyanov xe...@parallels.com
Cc: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Andrey Vagin ava...@openvz.org
---
include/uapi/linux/ptrace.h | 9 +++
kernel/ptrace.c | 64
+
2 files changed, 73 insertions(+)
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index 022ab18..5d851d5 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -52,6 +52,15 @@
#define PTRACE_INTERRUPT 0x4207
#define PTRACE_LISTEN 0x4208
+#define PTRACE_PEEKSIGINFO 0x4209
+
+/*
+ * The lower 16 bits of addr is a sequence number of a signal.
+ * All other bits can be used for flags.
+ */
+#define PTRACE_PEEKSIGINFO_FLAGS_MASK (~0UL 16)
+#define PTRACE_PEEK_SHARED (1UL 31)
+
/* Wait extended result codes for the above trace options. */
#define PTRACE_EVENT_FORK 1
#define PTRACE_EVENT_VFORK 2
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 1599157..27fd31a 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -579,6 +579,40 @@ static int ptrace_setsiginfo(struct task_struct *child,
const siginfo_t *info)
return error;
}
+#ifdef CONFIG_CHECKPOINT_RESTORE
+static int ptrace_peek_siginfo(struct task_struct *child,
+ unsigned long addr, siginfo_t *siginfo)
+{
+ struct sigpending *pending;
+ struct sigqueue *q;
+ unsigned long flags;
+ unsigned int nr;
+ int ret = -ENOENT;
+
+ nr = addr ~PTRACE_PEEKSIGINFO_FLAGS_MASK;
+ flags = addr PTRACE_PEEKSIGINFO_FLAGS_MASK;
+
+ if (flags PTRACE_PEEK_SHARED)
+ pending = child-signal-shared_pending;
+ else
+ pending = child-pending;
+
+ if (flags ~PTRACE_PEEK_SHARED)
+ return -EINVAL; /* unknown flags */
+
+ spin_lock_irq(child-sighand-siglock);
+ list_for_each_entry(q, pending-list, list) {
+ if (!nr--) {
+ copy_siginfo(siginfo, q-info);
+ ret = 0;
+ break;
+ }
+ }
+ spin_unlock_irq(child-sighand-siglock);
+
+ return ret;
+}
+#endif
#ifdef PTRACE_SINGLESTEP
#define is_singlestep(request) ((request) == PTRACE_SINGLESTEP)
@@ -703,6 +737,21 @@ int ptrace_request(struct task_struct *child, long
request,
ret = put_user(child-ptrace_message, datalp);
break;
+#ifdef CONFIG_CHECKPOINT_RESTORE
+ case PTRACE_PEEKSIGINFO:
+ {
+ siginfo_t __user *uinfo = (siginfo_t __user *) data;
+
+ ret = ptrace_peek_siginfo(child, addr, siginfo);
+
+ if (!ret)
+ ret = copy_siginfo_to_user(uinfo, siginfo);
+ if (!ret)
+ ret = __put_user(siginfo.si_code, uinfo-si_code);
+ break;
+ }
+#endif
+
case PTRACE_GETSIGINFO:
ret = ptrace_getsiginfo(child, siginfo);
if (!ret)
@@ -959,6 +1008,21 @@ int compat_ptrace_request(struct task_struct *child,
compat_long_t request,
ret = put_user((compat_ulong_t) child-ptrace_message, datap);
break;
+#ifdef CONFIG_CHECKPOINT_RESTORE
+ case PTRACE_PEEKSIGINFO:
+ {
+ compat_siginfo_t __user *uinfo =
Re: SYSFS errors
Em Tue, 19 Feb 2013 12:43:46 +0100
Borislav Petkov b...@alien8.de escreveu:
On Tue, Feb 19, 2013 at 08:11:49AM -0300, Mauro Carvalho Chehab wrote:
I remember I saw some discussions about it in the past at bluesmoke ML,
saying that -ENODEV is the expected behavior when this is not supported.
Changing from -ENODEV to N/A will break anything that would be relying
on the previous behavior. So, I think that such change will for sure
break
userspace.
If we're willing to change it, not creating the sdram_scrub_rate
sysfs
node is less likely to affect userspace.
This will break scripts which assume this file's presence implicitly.
If are there any script like that, then yes.
[ … ]
@@ -1017,6 +1010,14 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info
*mci)
return err;
}
+ if (mci-set_sdram_scrub_rate mci-get_sdram_scrub_rate) {
This will break cpc925_edac.c because it defines a
-get_sdram_scrub_rate but not a -set_sdram_scrub_rate.
True. Patch below fixes it.
I think a maybe better fix would be to figure out the sysfs file
permissions based on the presence of the two functions and *then* add
the attribute.
This way, the only visible change to userspace is the corrected sysfs
file permissions.
I'm not sure if is there a way to pass fs permissions to something similar
to device_create_file().
On both cases, an error will happen at open:
- if file doesn't exist (this approach), it will return -ENOENT;
- if file is opened with wrong permissions, open will return -EPERM.
However, if the file is not created, readdir() won't show the file.
So, if userspace first seeks for the sdram_scrub_rate, it won't fail.
That makes the logic below a little safer, IMO.
[PATCH EDAC] edac: only create sdram_scrub_rate where supported
Currently, sdram_scrub_rate sysfs node is created even if the device
doesn't support get/set the scub rate. Change the logic to only
create this device node when the operation is supported.
If only read or only write is supported, it will keep returning -ENODEV
just like before.
Reported-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 9c58da6..29b66a2 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -7,7 +7,7 @@
*
* Written Doug Thompson nor...@xmission.com www.softwarebitmaker.com
*
- * (c) 2012 - Mauro Carvalho Chehab mche...@redhat.com
+ * (c) 2012-2013 - Mauro Carvalho Chehab mche...@redhat.com
* The entire API were re-written, and ported to use struct device
*
*/
@@ -882,7 +882,6 @@ static struct attribute *mci_attrs[] = {
dev_attr_ce_noinfo_count.attr,
dev_attr_ue_count.attr,
dev_attr_ce_count.attr,
- dev_attr_sdram_scrub_rate.attr,
dev_attr_max_location.attr,
NULL
};
@@ -1017,6 +1016,14 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info
*mci)
return err;
}
+ if (mci-set_sdram_scrub_rate || mci-get_sdram_scrub_rate) {
+ err = device_create_file(mci-dev,
+dev_attr_sdram_scrub_rate);
+ if (err) {
+ edac_dbg(1, failure: create sdram_scrub_rate\n);
+ goto fail2;
+ }
+ }
/*
* Create the dimm/rank devices
*/
@@ -1061,6 +1068,7 @@ fail:
continue;
device_unregister(dimm-dev);
}
+fail2:
device_unregister(mci-dev);
bus_unregister(mci-bus);
kfree(mci-bus.name);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] mfd: wm8994: add missing variable initialization
On Tue, Feb 19, 2013 at 09:56:26AM +0900, Jingoo Han wrote: - int ret, i, patch_regs; + int ret, i, patch_regs = 0; As with all such changes you really need to explain why it's safe to just blindly initialise to this particular value and why this isn't just masking a real issue in the code. Initialising with a random value will fix the warning but that might just be turning off the compiler's checks. signature.asc Description: Digital signature
Re: Questin about swap_slot free and invalidate page
On 02/05/2013 05:28 AM, Dan Magenheimer wrote:
From: Minchan Kim [mailto:minc...@kernel.org]
Sent: Sunday, February 03, 2013 7:50 PM
To: Hugh Dickins
Cc: Nitin Gupta; Dan Magenheimer; Seth Jennings; Konrad Rzeszutek Wilk;
linux...@kvack.org; linux-
ker...@vger.kernel.org; Andrew Morton
Subject: Re: Questin about swap_slot free and invalidate page
Hi Hugh,
On Sun, Feb 03, 2013 at 05:51:14PM -0800, Hugh Dickins wrote:
On Thu, 31 Jan 2013, Minchan Kim wrote:
When I reviewed zswap, I was curious about frontswap_store.
It said following as.
* If frontswap already contains a page with matching swaptype and
* offset, the frontswap implementation may either overwrite the data and
* return success or invalidate the page from frontswap and return failure.
It didn't say why it happens. we already have __frontswap_invalidate_page
and call it whenever swap_slot frees. If we don't free swap slot,
scan_swap_map can't find the slot for swap out so I thought overwriting of
data shouldn't happen in frontswap.
As I looked the code, the curplit is reuse_swap_page. It couldn't free swap
slot if the page founded is PG_writeback but miss calling
frontswap_invalidate_page
so data overwriting on frontswap can happen. I'm not sure frontswap guys
already discussed it long time ago.
If we can fix it, we can remove duplication entry handling logic
in all of backend of frontswap. All of backend should handle it although
it's pretty rare. Of course, zram could be fixed. It might be trivial now
but more there are many backend of frontswap, more it would be a headache.
If we are trying to fix it in swap layer, we might fix it following as
int reuse_swap_page(struct page *page)
{
..
..
if (count == 1) {
if (!PageWriteback(page)) {
delete_from_swap_cache(page);
SetPageDirty(page);
} else {
frontswap_invalidate_page();
swap_slot_free_notify();
}
}
}
But not sure, it is worth at the moment and there might be other places
to be fixed.(I hope Hugh can point out if we are missing something if he
has a time)
I expect you are right that reuse_swap_page() is the only way it would
happen for frontswap; but I'm too unfamiliar with frontswap to promise
you that - it's better that you insert WARN_ONs in your testing to verify.
But I think it's a general tmem property, isn't it? To define what
happens if you do give it the same key again. So I doubt it's something
I am too unfamiliar with tmem property but thing I am seeing is
EXPORT_SYMBOL(__frontswap_store). It's a one of frontend and is tighly very
coupled with swap subsystem.
that has to be fixed; but if you do find it helpful to fix it, bear in
mind that reuse_swap_page() is an odd corner, which may one day give the
stable pages DIF/DIX people trouble, though they've not yet complained.
I'd prefer a patch not specific to frontswap, but along the lines below:
I think that's the most robust way to express it, though I don't think
the (count == 0) case can actually occur inside that block (whereas
count == 0 certainly can occur in the !PageSwapCache case).
I believe that I once upon a time took statistics of how often the
PageWriteback case happens here, and concluded that it wasn't often
enough that refusing to reuse in this case would be likely to slow
anyone down noticeably.
I agree. I had a test about that with zram and that case wasn't common.
so your patch looks good to me.
I am waiting Dan's reply(He will come in this week) and then, judge what's
the best.
Hugh is right that handling the possibility of duplicates is
part of the tmem ABI. If there is any possibility of duplicates,
the ABI defines how a backend must handle them to avoid data
coherency issues.
The kernel implements an in-kernel API which implements the tmem
ABI. If the frontend and backend can always agree that duplicate
Which ABI in zcache implement that?
are never possible, I agree that the backend could avoid that
special case. However, duplicates occur rarely enough and the
consequences (data loss) are bad enough that I think the case
should still be checked, at least with a BUG_ON. I also wonder
if it is worth it to make changes to the core swap subsystem
to avoid code to implement a zswap corner case.
Remember that zswap is an oversimplified special case of tmem
that handles only one frontend (Linux frontswap) and one backend
(zswap). Tmem goes well beyond that and already supports other
more general backends including Xen and ramster, and could also
support other frontends such as a BSD or Solaris equivalent
of frontswap, for example with a Linux ramster/zcache backend.
I'm not sure how wise it is to tear out generic code and replace
it with simplistic code unless there is absolutely no chance that
the generic code will be necessary.
My two cents,
Dan
--
To unsubscribe, send a message with
Re: [RFC][PATCH] vfs: always protect diretory file-fpos with inode mutex
On Tue, Feb 19, 2013 at 09:22:40AM +0800, Li Zefan wrote:
There's a long long-standing bug...As long as I don't know when it dates
from.
I've written and attached a simple program to reproduce this bug, and it can
immediately trigger the bug in my box. It uses two threads, one keeps calling
read(), and the other calling readdir(), both on the same directory fd.
Hi Zefan,
Out of curiosity, why do you call read(2) on a directory fd? I only
open(2) a directory in order to execute a flush operation to make sure
that a file is really created.
Regards,
- Zheng
When I ran it on ext3 (can be replaced with ext2/ext4) which has _dir_index_
feature disabled, I got this:
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=993, inode=0, rec_len=0, name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=1009, inode=0, rec_len=0, name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=993, inode=0, rec_len=0, name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=1009, inode=0, rec_len=0, name_len=0
...
If we configured errors=remount-ro, the filesystem will become read-only.
SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
{
...
loff_t pos = file_pos_read(file);
ret = vfs_read(file, buf, count, pos);
file_pos_write(file, pos);
fput_light(file, fput_needed);
...
}
While readdir() is protected with i_mutex, f_pos can be changed without any
locking
in various read()/write() syscalls, which leads to this bug.
What makes things worse is Andi removed i_mutex from generic_file_llseek, so
you
can trigger the same bug by replacing read() with lseek() in the test program.
commit ef3d0fd27e90f67e35da516dafc1482c82939a60
Author: Andi Kleen a...@linux.intel.com
Date: Thu Sep 15 16:06:48 2011 -0700
vfs: do (nearly) lockless generic_file_llseek
I've tested ext3 with dir_index enabled and btrfs, nothing bad happened, but
there
should be some other vulnerabilities. For example, running the test program
on /sys
for a few minutes triggered this warning:
[ 917.994600] [ cut here ]
[ 917.994614] WARNING: at fs/sysfs/sysfs.h:195 sysfs_readdir+0x24c/0x260()
[ 917.994621] Hardware name: Tecal RH2285
...
[ 917.994725] Pid: 8754, comm: a.out Not tainted 3.8.0-rc2-tj-0.7-default+
#69
[ 917.994731] Call Trace:
[ 917.994736] [81205c6c] ? sysfs_readdir+0x24c/0x260
[ 917.994743] [81205c6c] ? sysfs_readdir+0x24c/0x260
[ 917.994752] [81041fff] warn_slowpath_common+0x7f/0xc0
[ 917.994759] [8104205a] warn_slowpath_null+0x1a/0x20
[ 917.994766] [81205c6c] sysfs_readdir+0x24c/0x260
[ 917.994774] [8119cbd0] ? sys_ioctl+0x90/0x90
[ 917.994780] [8119cbd0] ? sys_ioctl+0x90/0x90
[ 917.994787] [8119cfc1] vfs_readdir+0xb1/0xd0
[ 917.994794] [8119d07b] sys_getdents64+0x9b/0x110
[ 917.994803] [814a45d9] system_call_fastpath+0x16/0x1b
[ 917.994809] ---[ end trace 6efe15a65b89022a ]---
[ 917.994816] ida_remove called for id=13073 which is not allocated.
We can fix this bug in each filesystem, but can't we just make sure i_mutex is
acquired in lseek(), read(), write() and readdir() for directory file
operations?
(the patch is for demonstration only)
diff --git a/fs/read_write.c b/fs/read_write.c
index bb34af3..41f76e5 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -218,14 +218,25 @@ EXPORT_SYMBOL(default_llseek);
loff_t vfs_llseek(struct file *file, loff_t offset, int whence)
{
+ struct inode *inode = file-f_path.dentry-d_inode;
loff_t (*fn)(struct file *, loff_t, int);
+ int ret;
fn = no_llseek;
if (file-f_mode FMODE_LSEEK) {
if (file-f_op file-f_op-llseek)
fn = file-f_op-llseek;
}
- return fn(file, offset, whence);
+
+ if (S_ISDIR(inode-i_mode)) {
+ mutex_lock(inode-i_mutex);
+ ret = fn(file, offset, whence);
+ mutex_unlock(inode-i_mutex);
+ } else {
+ ret = fn(file, offset, whence);
+ }
+
+ return ret;
}
EXPORT_SYMBOL(vfs_llseek);
@@ -442,12 +453,32 @@ EXPORT_SYMBOL(vfs_write);
static inline loff_t file_pos_read(struct file *file)
{
- return file-f_pos;
+ struct inode *inode = file-f_path.dentry-d_inode;
+ loff_t pos;
+
+ if (S_ISDIR(inode-i_mode)) {
+ mutex_lock(inode-i_mutex);
+ pos = file-f_pos;
+ mutex_unlock(inode-i_mutex);
+ } else {
+ pos
Re: [PATCH, RFC 2/8] ARM: twd: register clock event for 1 core SMP
On Tuesday 19 February 2013 05:44 PM, Felipe Balbi wrote: On Tue, Feb 19, 2013 at 03:44:14PM +0530, Santosh Shilimkar wrote: On Monday 18 February 2013 05:07 PM, Afzal Mohammed wrote: Register percpu local timer for scheduler tick in the case of one core SMP configuration. In other cases - secondary cpu's as well as boot cpu's having more than one core, this is being registered as per existing boot flow, with a difference that they happens after delay calibration. Registering the clock for tick in case of one core should be done before Kernel calibrates delay (this is required to boot, unless local timer is the only one registered for tick). Registering twd local timer at init_time (which platforms are doing now) helps achieve that with the proposed change. This helps in an almost booting Kernel (minimal) by only relying on ARM parts for an A9 one core SMP. Signed-off-by: Afzal Mohammed af...@ti.com --- As mentioned in cover-letter, I don't think we have good reasoning to make TWD to work with UP configuration. Even you fix the timer code, there are more cascaded dependencies which is not worth the effort. if CONFIG_SMP_ON_UP is enabled, smp_twd.c can still be compiled, right ? Yep though just from deps pesrpective TWD is made available for ARM SMP machines as below config HAVE_ARM_TWD bool depends on SMP Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] staging/sep: Fix smatch false positive about potential NULL dereference in sep_main.c
On Tue, Feb 19, 2013 at 01:07:27PM +0100, Peter Huewe wrote: Smatch complains about a potential NULL pointer dereference: sep_main.c:2312 sep_construct_dma_tables_from_lli() error: potential NULL dereference 'info_out_entry_ptr'. info_out_entry_ptr is initialized with NULL and if info_in_entry_ptr is not NULL it gets derefenced. However info_out_entry_ptr is only NULL in the first iteration of the while loop and in this case info_in_entry_ptr is also NULL (as indicated by the comment /* If info entry is null - this is the first table built */ - this is a false positive. Nevertheless we add a check for info_out_entry_ptr to silence this warning and make it more robust in regard to code changes. Smatch doesn't handle loops very well. Of course, all along I've wanted to fix this, but it's a bit complicated so it could be another year or two before it actually happens. Generally, as a philosophy, I always say never to change the code for false positives. It should be Smatch which changes. Also the other thing is that with Smatch I deliberately allow more false positives than GCC does. It's a trade off between being ambitious in looking for bugs and being annoying to users. When Smatch looks at this code it sees the else side as impossible to reach. Perhaps I should add a hack in that if the code is in an impossible to reach place then don't print a warning... It would be better to just fix loop handling... I'm not sure. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ACPI and power management updates for v3.9-rc1
Hi Linus, Please pull from the git repository at git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm+acpi-3.9-rc1 to receive ACPI and power management updates for v3.9 with top-most commit 10baf04e95fbf7eb6089410220a547211dd2ffa7 Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux on top of commit 836dc9e3fbbab0c30aa6e664417225f5c1fb1c39 Linux 3.8-rc7 Highlights: - Rework of the ACPI namespace scanning code. Reduces code size and complexity, removes some really ugly stuff. Requisite for PCI host bridge hotplug support queued up in the PCI tree. From yours truly with bits from Bjorn Helgaas, Jiang Liu, Mika Westerberg, Toshi Kani, and Yinghai Lu. - ACPI power resources handling and ACPI device PM update. Adds missing support for power resource priorities and system levels, changes device PM to follow the spec more closely, fixes bugs and exposes ACPI power resources information to user space for powertop etc. - ACPICA update to version 20130117. Bug fixes, more new ACPI 5 features, code cleanups, new interface for walking device resource lists, reduction of divergences between the kernel code and ACPICA upstream. From Bob Moore and Lv Zheng with smaller bits from Aaron Lu, Chao Guan, Jesper Juhl, and Tim Gardner. - Support for Intel Lynxpoint LPSS from Mika Westerberg. - cpuidle update adding support for Intel Haswell, causing the C1 state to be used (along with C1E) by intel_idle and removing the global definition of pm_idle. From Len Brown. - cpuidle fixes and cleanups from Daniel Lezcano. - cpufreq fixes and cleanups. Reduction of code duplication, locking fixes, simplifications all over the place. From Viresh Kumar and Fabio Baltieri with smaller bits from Stratos Karafotis and Rickard Andersson. - Intel P-states driver for Sandy Bridge processors. Departs from the cpufreq's tradition of separating governors from the low-level driver code and saves energy more efficiently as a result. From Dirk Brandewie. - cpufreq driver for Marvell Kirkwood SoCs from Andrew Lunn. - cpufreq fixes related to ordering issues between acpi-cpufreq and powernow-k8 from Borislav Petkov and Matthew Garrett. - cpufreq support for Calxeda Highbank processors from Mark Langsdorf and Rob Herring. - cpufreq driver for the Freescale i.MX6Q SoC and cpufreq-cpu0 update from Shawn Guo. - cpufreq Exynos fixes and cleanups from Jonghwan Choi, Sachin Kamat, and Inderpal Singh. - Support for lightweight suspsend that stops the suspend sequence after suspending devices and waits for a wakup interrupt at that point. The changes were relatively small and the users of autosleep may find this useful. From Zhang Rui. - Removal of the deprecated power trace API from Paul Gortmaker. Thanks! --- Aaron Lu (2): ACPICA: Resource manager: Add support for ACPI 5 wake bit in IRQ descriptor. ACPICA: Resources: Support for ACPI 5 wake bit in ExtendedInterrupt descriptor. Andreas Fleig (1): ACPI / PM: Fix /proc/acpi/wakeup for devices w/o bus or parent Andrew Lunn (1): cpufreq: kirkwood: Add a cpufreq driver for Marvell Kirkwood SoCs Bjorn Helgaas (1): ACPI: Remove unused struct acpi_pci_root.id member Bob Moore (36): ACPICA: Performance: Remove function tracing from critical allocation functions. ACPICA: Debugger: Major update for the Disassemblemethod command. ACPICA: Disassembler: Add new ACPI 5 interrupt sharing flags. ACPICA: Add macros to extract flag bits from resource descriptors. ACPICA: AcpiGetObjectInfo: optimize exit for mutex failure. ACPICA: Update version to 20121114. ACPICA: Resources: New interface, AcpiWalkResourceBuffer. ACPICA: Change exception code for LoadTable operator. ACPICA: Eliminate some small unnecessary pathname functions. ACPICA: Add root node optimization to internal get namespace node function. ACPICA: Lint changes, no functional change. ACPICA: Add time macros for various timer/time manipulation. ACPICA: Add header file support for the ACPI 5 TPM2 ACPI table. ACPICA: DEBUG_PRINT macros: Update to improve performance. ACPICA: FUNCTION_TRACE macros: Check if debug is enabled up-front. ACPICA: Eliminate superfluous return_UINT8 and return_UINT32 macros. ACPICA: Update ACPI_IS_DEBUG_ENABLED macro. ACPICA: Deploy new ACPI_IS_DEBUG_ENABLED macro in debug output code. ACPICA: Merge all debug output macros into a single file, acoutput. ACPICA: iASL: Finish support for CSRT table. ACPICA: iASL: Finish support for the TPM2 table. ACPICA: Update for non-configured ACPI_IS_DEBUG_ENABLED macro. ACPICA: Namespace: Eliminate dot...dot output during initialization. ACPICA: Update ACPICA initialization messages. ACPICA: Interpreter: Add warning if 64-bit constant appears in 32-bit table.
Re: [PATCH] vt: add init_hide parameter to suppress boot output
On 02/19/2013 10:38 AM, Kirill A. Shutemov wrote: From: Andy Ross andy.r...@windriver.com When vt.init_hide=1 is set, suppress output on newly created consoles until an affirmative switched to that console. This prevents boot output from displaying (and clobbering splash screens, etc...) without disabling the console entirely. Signed-off-by: Andy Ross andy.r...@windriver.com Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com --- drivers/tty/vt/vt.c|7 +++ include/linux/console_struct.h |3 ++- include/linux/vt.h |2 ++ kernel/power/console.c |2 -- 4 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index 8fd8968..3966ff5 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -165,6 +165,9 @@ module_param(global_cursor_default, int, S_IRUGO | S_IWUSR); static int cur_default = CUR_DEFAULT; module_param(cur_default, int, S_IRUGO | S_IWUSR); +static int init_hide; +module_param(init_hide, int, S_IRUGO); So this should actually be a bool, right? Could you change that appropriately? thanks, -- js suse labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 0/5] Generic PHY Framework
On Tuesday 19 February 2013, kishon wrote: On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote: On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. How does this relate to the generic PHY interfaces in drivers/net/phy? Currently drivers/phy and drivers/net/phy are independent and are not related to each other. There are some fundamental differences on how these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to match a PHY device with a PHY driver and the Ethernet device uses the bus layer to get the PHY. The Generic PHY Framework however doesn't have any bus layer. The PHY should be like any other Platform Devices and Drivers and the framework will provide some APIs to register with the framework. And there are other APIs which any controller can use to get the PHY (for e.g., in the case of dt boot, it can use phandle to get a reference to the PHY). Hmm, I think the use of a bus_type for a PHY actually sounds quite appropriate. The actual PHY device would then be a child of the platform_device (or something else) that gets probed by its parent bus or the DT. The operations that you define for the PHY actually mirror some of the things that we have for a 'struct device', so I think it would be quite logical to do it the same way. Note that MDIO has both a 'bus' and a 'class', and what we want here is more like what the 'class' was meant for, except that for new classes, we should actually use a 'bus', since the long-term plan is to kill off the concept of a 'class'. I hope that was not too confusing. :) Do you expect that to get merged into drivers/phy in the long run, or do you want to keep the generic phy only for everything but ethernet? We'd like the PHY drivers spread all over the kernel to get merged to drivers/phy including Ethernet. Having said that, Ethernet itself has a huge PHY framework and it's going to be little challenging to adapt to the new PHY framework (of course there'll be changes in this PHY framework when we want to have network PHY added here). But adapting USB PHYs to the new framework will be simpler and will be taken first. Also when we add SATA PHY (OMAP5), it will make use of this framework as both SATA and USB3 uses the same PHY IP. I think you need to have at least a concept of where you want to end up. It's totally fine to introduce a new subsystem that does only the minimum of what you need here, and add things as you go, but if you already plan to merge the existing mdio bus into this, you should really have an idea of what that will mean in the long run. I think it would be problematic to have two alternative interfaces for ethernet PHYs because then an ethernet driver still needs to decide which subsystem to interface with. Right. For now Ethernet should continue to use their own PHY abstraction layer till we are a bit more clear on how to move it to drivers/phy. Ok. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] mmc: dw_mmc: Add MSHC compatible for Exynos4412
Hello Seungwon,
Thank you for reviewing and I understand what you mean.
I agree that Exynos5250 and Exynos4412 are not same, no idea how much
they are different because no Exynos5250 spec on my hand. But at least
I assumed that the capabilities below are supported by Exynos4412 in
terms of its datasheet and it does work on my end as expected. :) Also
I assumed it will be separated if one of both become different to add
more capabilities.
MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
Maybe my understanding or approach is wrong since I do not have the
information of Exynos5250.
And suggestion do you have?
Regards,
Dongjin.
On Tue, Feb 19, 2013 at 7:19 PM, Seungwon Jeon tgih@samsung.com wrote:
On Tuesday, February 19, 2013, Dongjin Kim wrote:
This patch adds the compatible string for MSHC controller of Exynos4412, and
share the controller specific properties with Exynos5250 since they have same
features. Its driver data name is changed to exynos_drv_data instead SoC
specific name.
It's not actually same.
Exynos4412 doesn't have forward compatibilities for Exynos5250.
I agree that functionality of exynos_drv_data is common.
These functions have been implemented for existing Exynos*.
But in case of caps, it can't applied completely.
I'm concerning about this.
Thanks,
Seungwon Jeon
Cc: Jaehoon Chung jh80.ch...@samsung.com
Cc: Sachin Kamat sachin.ka...@linaro.org
Signed-off-by: Dongjin Kim tobet...@gmail.com
---
drivers/mmc/host/dw_mmc-exynos.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c
b/drivers/mmc/host/dw_mmc-exynos.c
index 4d50da6..38cd03c 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -199,8 +199,8 @@ static int dw_mci_exynos_setup_bus(struct dw_mci *host,
return 0;
}
-/* Exynos5250 controller specific capabilities */
-static unsigned long exynos5250_dwmmc_caps[4] = {
+/* Exynos4412/Exynos5250 controller specific capabilities */
+static unsigned long exynos_dwmmc_caps[4] = {
MMC_CAP_UHS_DDR50 | MMC_CAP_1_8V_DDR |
MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23,
MMC_CAP_CMD23,
@@ -208,8 +208,8 @@ static unsigned long exynos5250_dwmmc_caps[4] = {
MMC_CAP_CMD23,
};
-static const struct dw_mci_drv_data exynos5250_drv_data = {
- .caps = exynos5250_dwmmc_caps,
+static const struct dw_mci_drv_data exynos_drv_data = {
+ .caps = exynos_dwmmc_caps,
.init = dw_mci_exynos_priv_init,
.setup_clock= dw_mci_exynos_setup_clock,
.prepare_command= dw_mci_exynos_prepare_command,
@@ -219,8 +219,10 @@ static const struct dw_mci_drv_data exynos5250_drv_data
= {
};
static const struct of_device_id dw_mci_exynos_match[] = {
+ { .compatible = samsung,exynos4412-dw-mshc,
+ .data = exynos_drv_data, },
{ .compatible = samsung,exynos5250-dw-mshc,
- .data = exynos5250_drv_data, },
+ .data = exynos_drv_data, },
{},
};
MODULE_DEVICE_TABLE(of, dw_mci_exynos_match);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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: SYSFS errors
On Tue, Feb 19, 2013 at 09:16:10AM -0300, Mauro Carvalho Chehab wrote: I'm not sure if is there a way to pass fs permissions to something similar to device_create_file(). struct device_attribute.attr.mode? I.e., second arg. On both cases, an error will happen at open: - if file doesn't exist (this approach), it will return -ENOENT; - if file is opened with wrong permissions, open will return -EPERM. However, if the file is not created, readdir() won't show the file. Right, and in that case userspace which *assumes* it is always created - like it is now - will fail when accessing it. If simply you adjust the attributes accordingly but *always* create the file and it has the correct permissions, everyone is happy. Right? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] regulator: palmas: Change the DT node property names to follow the convention
On Mon, Feb 18, 2013 at 10:44:20AM +0530, J Keerthy wrote: DT node properties should not have _. Replacing them by -. Signed-off-by: J Keerthy j-keer...@ti.com This must need an update to the binding document too, and probably any DT files that ended up getting merged for it? signature.asc Description: Digital signature
Re: [RFC][PATCH] vfs: always protect diretory file-fpos with inode mutex
On 2013/2/19 20:33, Zheng Liu wrote: On Tue, Feb 19, 2013 at 09:22:40AM +0800, Li Zefan wrote: There's a long long-standing bug...As long as I don't know when it dates from. I've written and attached a simple program to reproduce this bug, and it can immediately trigger the bug in my box. It uses two threads, one keeps calling read(), and the other calling readdir(), both on the same directory fd. Hi Zefan, Out of curiosity, why do you call read(2) on a directory fd? I only open(2) a directory in order to execute a flush operation to make sure that a file is really created. Because something wrong happened in userspace programs. After a thread closed a socket, another thread is still reading data from this socket, but the socket fd has been re-used for opening directory for readdir()! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] early_printk: Consolidate random copies of identical code
The early console implementations are the same all over the
place. Move the print function to kernel/printk and get rid of the
copies.
Signed-off-by: Thomas Gleixner t...@linutronix.de
Cc: Russell King li...@arm.linux.org.uk
Cc: Mike Frysinger vap...@gentoo.org
Cc: Michal Simek mon...@monstr.eu
Cc: Ralf Baechle r...@linux-mips.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mundt let...@linux-sh.org
Cc: David S. Miller da...@davemloft.net
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Richard Weinberger rich...@nod.at
Cc: x...@kernel.org
---
arch/arm/kernel/early_printk.c| 17 +++--
arch/blackfin/kernel/early_printk.c |2 --
arch/microblaze/kernel/early_printk.c | 26 --
arch/mips/kernel/early_printk.c | 11 +--
arch/powerpc/kernel/udbg.c|6 ++
arch/sh/kernel/sh_bios.c |2 --
arch/sparc/kernel/setup_32.c |1 +
arch/sparc/kernel/setup_64.c |8 +++-
arch/tile/kernel/early_printk.c | 27 +--
arch/um/kernel/early_printk.c |8 +---
arch/unicore32/kernel/early_printk.c | 12
arch/x86/kernel/early_printk.c| 21 ++---
include/linux/console.h |1 +
include/linux/printk.h|6 ++
kernel/printk.c | 30 +++---
15 files changed, 68 insertions(+), 110 deletions(-)
Index: linux-stable/arch/arm/kernel/early_printk.c
===
--- linux-stable.orig/arch/arm/kernel/early_printk.c
+++ linux-stable/arch/arm/kernel/early_printk.c
@@ -29,28 +29,17 @@ static void early_console_write(struct c
early_write(s, n);
}
-static struct console early_console = {
+static struct console early_console_dev = {
.name = earlycon,
.write =early_console_write,
.flags =CON_PRINTBUFFER | CON_BOOT,
.index =-1,
};
-asmlinkage void early_printk(const char *fmt, ...)
-{
- char buf[512];
- int n;
- va_list ap;
-
- va_start(ap, fmt);
- n = vscnprintf(buf, sizeof(buf), fmt, ap);
- early_write(buf, n);
- va_end(ap);
-}
-
static int __init setup_early_printk(char *buf)
{
- register_console(early_console);
+ early_console = early_console_dev;
+ register_console(early_console_dev);
return 0;
}
Index: linux-stable/arch/blackfin/kernel/early_printk.c
===
--- linux-stable.orig/arch/blackfin/kernel/early_printk.c
+++ linux-stable/arch/blackfin/kernel/early_printk.c
@@ -25,8 +25,6 @@ extern struct console *bfin_earlyserial_
extern struct console *bfin_jc_early_init(void);
#endif
-static struct console *early_console;
-
/* Default console */
#define DEFAULT_PORT 0
#define DEFAULT_CFLAG CS8|B57600
Index: linux-stable/arch/microblaze/kernel/early_printk.c
===
--- linux-stable.orig/arch/microblaze/kernel/early_printk.c
+++ linux-stable/arch/microblaze/kernel/early_printk.c
@@ -21,7 +21,6 @@
#include asm/setup.h
#include asm/prom.h
-static u32 early_console_initialized;
static u32 base_addr;
#ifdef CONFIG_SERIAL_UARTLITE_CONSOLE
@@ -109,27 +108,11 @@ static struct console early_serial_uart1
};
#endif /* CONFIG_SERIAL_8250_CONSOLE */
-static struct console *early_console;
-
-void early_printk(const char *fmt, ...)
-{
- char buf[512];
- int n;
- va_list ap;
-
- if (early_console_initialized) {
- va_start(ap, fmt);
- n = vscnprintf(buf, 512, fmt, ap);
- early_console-write(early_console, buf, n);
- va_end(ap);
- }
-}
-
int __init setup_early_printk(char *opt)
{
int version = 0;
- if (early_console_initialized)
+ if (early_console)
return 1;
base_addr = of_early_console(version);
@@ -159,7 +142,6 @@ int __init setup_early_printk(char *opt)
}
register_console(early_console);
- early_console_initialized = 1;
return 0;
}
return 1;
@@ -169,7 +151,7 @@ int __init setup_early_printk(char *opt)
* only for early console because of performance degression */
void __init remap_early_printk(void)
{
- if (!early_console_initialized || !early_console)
+ if (!early_console)
return;
printk(KERN_INFO early_printk_console remapping from 0x%x to ,
base_addr);
@@ -195,9 +177,9 @@ void __init remap_early_printk(void)
void __init disable_early_printk(void)
{
- if (!early_console_initialized || !early_console)
+ if (!early_console)
return;
printk(KERN_WARNING
Re: [PATCH] dma: timb_dma: Fix compiler warning
On Tue, Feb 19, 2013 at 12:36 PM, Lars-Peter Clausen l...@metafoo.de wrote:
On 02/18/2013 08:59 PM, maxin.j...@gmail.com wrote:
From: Maxin B. John maxin.j...@enea.com
Fix this compiler warning:
warning: 'td_remove' defined but not used [-Wunused-function]
Signed-off-by: Maxin B. John maxin.j...@enea.com
---
drivers/dma/timb_dma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
index 952f823..f709279 100644
--- a/drivers/dma/timb_dma.c
+++ b/drivers/dma/timb_dma.c
@@ -798,7 +798,7 @@ err_release_region:
}
-static int td_remove(struct platform_device *pdev)
+static int __exit td_remove(struct platform_device *pdev)
{
While this fixes the warning, it's the wrong fix. The correct fix is to
remove the __exit_p. E.g. something like this:
--- a/drivers/dma/timb_dma.c
+++ b/drivers/dma/timb_dma.c
@@ -823,7 +823,7 @@ static struct platform_driver td_driver = {
.owner = THIS_MODULE,
},
.probe = td_probe,
- .remove = __exit_p(td_remove),
+ .remove = td_remove,
};
module_platform_driver(td_driver);
You are right, my bad. I will modify this and send the revised
version soon.
Thanks and Regards,
Maxin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: SYSFS errors
Em Tue, 19 Feb 2013 13:35:02 +0100 Borislav Petkov b...@alien8.de escreveu: On Tue, Feb 19, 2013 at 09:16:10AM -0300, Mauro Carvalho Chehab wrote: I'm not sure if is there a way to pass fs permissions to something similar to device_create_file(). struct device_attribute.attr.mode? I.e., second arg. Ah, now I see what you're meaning. That would require to dynamically create a per-mci DEVICE_ATTR(). On both cases, an error will happen at open: - if file doesn't exist (this approach), it will return -ENOENT; - if file is opened with wrong permissions, open will return -EPERM. However, if the file is not created, readdir() won't show the file. Right, and in that case userspace which *assumes* it is always created - like it is now - will fail when accessing it. If simply you adjust the attributes accordingly but *always* create the file and it has the correct permissions, everyone is happy. Right? No, on both cases, open() will return an error (-ENOENT against -EPERM). If userspace doesn't check if open() failed, I can't see why changing the open return error code would help. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] suspend/resume support for OMAP nand driver
This patch series adds low power transition support for OMAP NAND driver. With recent driver conversion of GPMC to platform_driver, pm_runtime calls can be used to handle module enable disable of GPMC. This is taken care patch #1. patch #2 is for GPMC suspend/resume support. This includes low power transition support of - GPMC module - ELM module User initiated suspend/resume sequence tested on am335x-evm with NAND flash support. Also tested in omap3-evm for user initiated suspend/resume sequence with NAND flash. This patch series based on [1] and is present in [2]. 1. ARM: OMAP2+: AM33XX: Add suspend-resume support http://comments.gmane.org/gmane.linux.ports.arm.omap/91405 2. https://github.com/avinashphilip/am335x_linux/commits/NAND_supend_resume_support Changes Since v2: - Remove calll back of nand_suspend from omap2 nand driver, as the same call already done from suspend activity mtd class driver. Philip Avinash (3): arm: gpmc: Converts GPMC driver to pm_runtime capable arm: gpmc: Low power transition support mtd: devices: elm: Low power transition support arch/arm/mach-omap2/gpmc.c | 30 +--- drivers/mtd/devices/elm.c | 54 2 files changed, 81 insertions(+), 3 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] arm: gpmc: Converts GPMC driver to pm_runtime capable
Support for pm_runtime add to GPMC driver.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2c57f81..b1cd6c1 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -29,6 +29,7 @@
#include linux/of_mtd.h
#include linux/of_device.h
#include linux/mtd/nand.h
+#include linux/pm_runtime.h
#include linux/platform_data/mtd-nand-omap2.h
@@ -1317,7 +1318,8 @@ static int gpmc_probe(struct platform_device *pdev)
return PTR_ERR(gpmc_l3_clk);
}
- clk_prepare_enable(gpmc_l3_clk);
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_get_sync(pdev-dev);
gpmc_dev = pdev-dev;
@@ -1329,7 +1331,7 @@ static int gpmc_probe(struct platform_device *pdev)
rc = gpmc_mem_init();
if (IS_ERR_VALUE(rc)) {
- clk_disable_unprepare(gpmc_l3_clk);
+ pm_runtime_put_sync(pdev-dev);
clk_put(gpmc_l3_clk);
dev_err(gpmc_dev, failed to reserve memory\n);
return rc;
@@ -1340,7 +1342,7 @@ static int gpmc_probe(struct platform_device *pdev)
rc = gpmc_probe_dt(pdev);
if (rc 0) {
- clk_disable_unprepare(gpmc_l3_clk);
+ pm_runtime_put_sync(pdev-dev);
clk_put(gpmc_l3_clk);
dev_err(gpmc_dev, failed to probe DT parameters\n);
return rc;
@@ -1353,6 +1355,8 @@ static __devexit int gpmc_remove(struct platform_device
*pdev)
{
gpmc_free_irq();
gpmc_mem_exit();
+ pm_runtime_put_sync(pdev-dev);
+ pm_runtime_disable(pdev-dev);
gpmc_dev = NULL;
return 0;
}
--
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 3/4] mtd: devices: elm: Low power transition support
On Wed, Feb 13, 2013 at 18:13:03, Russell King - ARM Linux wrote:
On Wed, Feb 13, 2013 at 11:42:01AM +, Philip, Avinash wrote:
On Sat, Feb 09, 2013 at 15:52:44, Russell King - ARM Linux wrote:
On Thu, Feb 07, 2013 at 06:06:57PM +0530, Philip Avinash wrote:
+static int elm_suspend(struct device *dev)
+{
+ struct elm_info *info = dev_get_drvdata(dev);
+ wait_queue_head_t wq;
+ DECLARE_WAITQUEUE(wait, current);
+
+ init_waitqueue_head(wq);
+ while (1) {
+ /* Make sure that ELM not running */
+ if (info-idle) {
+ add_wait_queue(wq, wait);
+ schedule();
+ remove_wait_queue(wq, wait);
+ } else {
+ break;
+ }
+ }
The above code looks really wrong - it will just spin endlessly with the
waitqueues doing nothing useful. What are you trying to do here?
The intention of waitqeue is to make the suspend process really wait till
the ELM module finishes current activity. Although this type of protection
already achieved in mtd layer using nand_suspend(), this one is particularly
required for ELM module to really make sure that *any pending* corrections
to
finish really before gone to suspend.
I don't think you understand what's going on with the above, and why the
above is completely ineffective.
1. Your wait queue head is declared on stack, and there's no references
to it outside of this function. So _nothing_ can activate the wait
queue.
2. You're not changing the current thread's status away from TASK_RUNNING,
so schedule() will either return immediately or it will schedule another
task if it's time for this one to be preempted.
In other words, the above can be rewritten as:
while (info-idle)
schedule();
and it will still have the same effect.
Now, if you want to be kinder to the system, then you should use a
wait queue properly. Put the waitqueue head in struct elm_info. Use
wait_event() here. And call wake_up() where you set info-idle to
false.
I understood the issue. Thanks for the detailed explanation.
It seems the entire mechanism of ELM module state check is not required.
The ELM suspend procedure initiated only after the current MTD transaction
finishes and is ensured in MTD class driver.
So I can simply disable ELM module in suspend without any check.
Thanks
Avinash
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] arm: gpmc: Low power transition support
With GPMC converted to platform driver recently, adds low power
transition support in driver itself.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
Changes since v1:
Module disable enable added using pm_runtime support.
arch/arm/mach-omap2/gpmc.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index b1cd6c1..cc57988 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1361,9 +1361,29 @@ static __devexit int gpmc_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int gpmc_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ omap3_gpmc_save_context();
+ pm_runtime_put_sync(pdev-dev);
+ return 0;
+}
+
+static int gpmc_resume(struct platform_device *pdev)
+{
+ pm_runtime_get_sync(pdev-dev);
+ omap3_gpmc_restore_context();
+ return 0;
+}
+#endif
+
static struct platform_driver gpmc_driver = {
.probe = gpmc_probe,
.remove = __devexit_p(gpmc_remove),
+#ifdef CONFIG_PM
+ .suspend= gpmc_suspend,
+ .resume = gpmc_resume,
+#endif
.driver = {
.name = DEVICE_NAME,
.owner = THIS_MODULE,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] mtd: devices: elm: Low power transition support
In low power modes of AM335X platforms, peripherals power is cut off.
This patch supports low power sleep transition support for ELM driver.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
Changes Since v2:
- Removes wait queue mechanism. The order of device creation ensures
that nand driver got suspended well before elm module suspend.
Hence no need to check elm module state on suspend.
drivers/mtd/devices/elm.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index f034239..a41c968 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -20,6 +20,7 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/of.h
+#include linux/sched.h
#include linux/pm_runtime.h
#include linux/platform_data/elm.h
@@ -379,6 +380,23 @@ static int elm_remove(struct platform_device *pdev)
return 0;
}
+static int elm_suspend(struct device *dev)
+{
+ pm_runtime_put_sync(dev);
+ return 0;
+}
+
+static int elm_resume(struct device *dev)
+{
+ struct elm_info *info = dev_get_drvdata(dev);
+
+ pm_runtime_get_sync(dev);
+ elm_config(dev, info-bch_type);
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(elm_pm_ops, elm_suspend, elm_resume);
+
#ifdef CONFIG_OF
static const struct of_device_id elm_of_match[] = {
{ .compatible = ti,am3352-elm },
@@ -392,6 +410,7 @@ static struct platform_driver elm_driver = {
.name = elm,
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(elm_of_match),
+ .pm = elm_pm_ops,
},
.probe = elm_probe,
.remove = elm_remove,
--
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 1/2] hid: Add report descriptor for Logitech Driving Force wheel
On Sun, 17 Feb 2013, Paul Sbarra wrote: This is the original report descriptor as reported by lsusb -vd 046d:c294. I have now applied both patches. Paul, please try to provide more verbose changelogs in the future even for such trivial changes as this. Thanks. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] drivers: phy: add generic PHY framework
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
Hmm, so you actually do have a 'class'. There is a GregKH mandated ban on
new classes, meaning that one should be converted to a bus_type instead.
Also, you really should not need the global phy_list, phy_list_mutex
and phy_bind_list variables, since the driver core already provides
you with ways to iterate through devices on a class or bus.
+/**
+ * of_phy_get - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @phandle: name of the property holding the phy phandle value
+ * @index - the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded.
+ */
+struct phy *of_phy_get(struct device *dev, const char *phandle, u8 index)
+{
+ struct phy *phy = NULL;
+ struct phy_bind *phy_map = NULL;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, phandle, index);
+ if (!node) {
+ dev_dbg(dev, failed to get %s phandle in %s node\n, phandle,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
I wonder whether this one should be of_parse_phandle_with_args() instead,
so you can have client-specific configuration in the property. Basically
instead of
phy = usbphy0 usbphy1;
you can pass an arbitrary number of arguments along with this, as
determined by some property in the phy node:
usbphy0: phy@1 {
#phy-cells = 1;
};
ehci@2 {
phy = usbphy0 23;
};
Which in turn leads to the argument (23) being passed into a phy_bind().
I also wonder if you should allow arbitrary names for the property.
Can't this always be called 'phy'? If you allow named phys, it would
more more consistent with other bindings to have a list of phy handles
in a property called phy, and a second property called phy-names
that contains the named strings.
+/**
+ * phy_create - create a new phy
+ * @dev: device that is creating the new phy
+ * @desc: descriptor of the phy
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, struct phy_descriptor *desc)
+{
+ int ret;
+ struct phy *phy;
+ struct phy_bind *phy_bind;
+ const char *devname = NULL;
...
+
+ devname = dev_name(dev);
+ device_initialize(phy-dev);
+ phy-desc = desc;
+ phy-dev.class = phy_class;
+ phy-dev.parent = dev;
+ phy-dev.bus = desc-bus;
+ ret = dev_set_name(phy-dev, %s, devname);
Passing a bus_type through the descriptor seems misplaced. What is this for?
Why is this function not just:
struct phy *phy_create(struct device *dev, const char *label, int type,
struct phy_ops *ops);
Passing a structure like you do here seems dangerous because when someone
decides to add members to the structure, existing code will not give a
build error but silently break.
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @suspend: suspending the phy
+ * @resume: resuming the phy
+ * @poweron: powering on the phy
+ * @shutdown: shutting down the phy
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops {
+ int (*init)(struct phy_descriptor *desc);
+ int (*exit)(struct phy_descriptor *desc);
+ int (*suspend)(struct phy_descriptor *desc);
+ int (*resume)(struct phy_descriptor *desc);
+ int (*poweron)(struct phy_descriptor *desc);
+ int (*shutdown)(struct phy_descriptor *desc);
+ struct module *owner;
+};
Shouldn't these take the 'struct phy' as an argument? struct phy_descriptor is
not even based on a 'struct device'.
+struct phy {
+ struct device dev;
+ struct phy_descriptor *desc;
+ struct list_headhead;
+};
Please kill off the 'head' member here and use the infrastructure we
already have. The concept of the phy_descriptor seems even more foreign
here, so best just collapse that into 'struct phy'. Maybe also rename
the structure to 'phy_device'.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] devicetree for v3.9
Hi Linus,
Description of changes below and in tag. Please pull.
g.
The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7:
Linux 3.8-rc6 (2013-02-01 12:08:14 +1100)
are available in the git repository at:
git://git.secretlab.ca/git/linux tags/dt-for-linus
for you to fetch changes up to 02bbde7849e68e193cefaa1885fe0df0f03c9fcd:
Revert of: use platform_device_add (2013-02-17 20:03:27 +)
Device tree changes for v3.9
All around device tree changes destined for v3.8. Aside from the
documentation updates the highlights in this branch include:
- Kbuild changes for using CPP with .dts files
- locking fix from preempt_rt patchset
- include DT alias names in device uevent
- Selftest bugfixes and improvements
- New function for counting phandles stanzas in a property
- constify argument to of_node_full_name()
- Various bug fixes
This tree did also contain a commit to use platform_device_add instead
of open-coding the device add code, but it caused problems with amba
devices and needed to be reverted.
Ajay Kumar (1):
of/exynos_g2d: Add Bindings for exynos G2D driver
Alexander Shiyan (1):
of: Add vendor prefix for Cirrus Logic
Grant Likely (11):
powerpc/5200: Fix size to request_mem_region() call
of: use platform_device_add
devicetree: Move NS2 LEDs binding into LEDs directory
Merge branch 'robherring/for-next' from
git://sources.calxeda.com/kernel/linux.git
Merge branch 'for-next' from git://sources.calxeda.com/kernel/linux.git
of/selftest: Fix GPIOs selftest to cover the 7th case
of/selftest: Use selftest() macro throughout
of/base: Clean up exit paths for of_parse_phandle_with_args()
of: Create function for counting number of phandles in a property
gpio: Make of_count_named_gpios() use new of_count_phandle_with_args()
Revert of: use platform_device_add
Guennadi Liakhovetski (1):
DT: add vendor prefixes for Renesas and Toshiba
Masanari Iida (1):
documentation/devicetree: Fix typos
Sachin Kamat (1):
documentation/devicetree: Fix a typo in exynos-dw-mshc.txt
Simon Glass (1):
input: Extend matrix-keypad device tree binding
Steffen Trumtrar (1):
of: add 'const' to of_node_full_name parameter
Stepan Moskovchenko (1):
of: Output devicetree alias names in uevent
Stephen Warren (3):
kbuild: create a rule to run the pre-processor on *.dts files
of: fix recursive locking in of_get_next_available_child()
kbuild: limit dtc+cpp include path
Thomas Abraham (1):
of: fix incorrect return value of of_find_matching_node_and_match()
Thomas Gleixner (2):
OF: Fixup resursive locking code paths
OF: convert devtree lock from rw_lock to raw spinlock
.../devicetree/bindings/arm/atmel-aic.txt |2 +-
Documentation/devicetree/bindings/arm/gic.txt |4 +-
.../devicetree/bindings/arm/omap/omap.txt |6 +-
.../devicetree/bindings/drm/exynos/g2d.txt | 22 ++
.../devicetree/bindings/input/lpc32xx-key.txt |9 +-
.../devicetree/bindings/input/matrix-keymap.txt|8 +
.../devicetree/bindings/input/omap-keypad.txt | 13 +-
.../devicetree/bindings/input/tca8418_keypad.txt |6 +-
.../bindings/{gpio = leds}/leds-ns2.txt |0
.../devicetree/bindings/mips/cavium/dma-engine.txt |2 +-
.../devicetree/bindings/mmc/exynos-dw-mshc.txt |8 +-
.../devicetree/bindings/mmc/samsung-sdhci.txt |2 +-
.../devicetree/bindings/powerpc/fsl/srio.txt |4 +-
.../bindings/regulator/tps62360-regulator.txt |4 +-
Documentation/devicetree/bindings/rtc/s3c-rtc.txt |2 +-
.../devicetree/bindings/vendor-prefixes.txt|3 +
.../devicetree/bindings/watchdog/samsung-wdt.txt |2 +-
Documentation/kbuild/makefiles.txt | 23 ++
arch/powerpc/sysdev/bestcomm/bestcomm.c|2 +-
arch/sparc/kernel/prom_common.c|4 +-
drivers/gpio/gpiolib-of.c | 35 ---
drivers/hwmon/gpio-fan.c |4 +-
drivers/input/keyboard/matrix_keypad.c |8 +-
drivers/net/phy/mdio-mux-gpio.c|4 +-
drivers/of/base.c | 303 +---
drivers/of/device.c| 13 +
drivers/of/of_private.h| 36 +++
drivers/of/selftest.c | 54 ++--
drivers/spi/spi-fsl-spi.c |4 +-
drivers/spi/spi-oc-tiny.c |8 +-
drivers/spi/spi-ppc4xx.c |4 +-
drivers/spi/spi.c |5 +-
include/linux/of.h | 13 +-
include/linux/of_gpio.h
Re: [RFC][PATCH] vfs: always protect diretory file-fpos with inode mutex
On Tue 19-02-13 19:47:30, Li Zefan wrote:
On 2013/2/19 17:19, Jan Kara wrote:
On Tue 19-02-13 09:22:40, Li Zefan wrote:
There's a long long-standing bug...As long as I don't know when it dates
from.
I've written and attached a simple program to reproduce this bug, and it
can
immediately trigger the bug in my box. It uses two threads, one keeps
calling
read(), and the other calling readdir(), both on the same directory fd.
So the fact that read() or even write() to fd opened O_RDONLY has *any*
effect on f_pos looks really unexpected to me. I think we really should
have there:
if (ret = 0)
file_pos_write(...);
I thought about this. The problem is then we have to check every fop-write()
to see if any of them can return -errno with file-f_pos changed and fix them,
though it's do-able.
But returning error and advancing f_pos would be a bug - specification
says write() returns the number of bytes written or -1 and f_pos should be
advanced by the number of bytes written.
That would solve problems with read() and write() on directories for
pretty much every filesystem since the first usually returns -EISDIR and
the second -EBADF.
Yeah, seems ceph is the only filesystem that allows read() on directories.
When I ran it on ext3 (can be replaced with ext2/ext4) which has
_dir_index_
feature disabled, I got this:
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=993, inode=0, rec_len=0,
name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=1009, inode=0, rec_len=0,
name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=993, inode=0, rec_len=0,
name_len=0
EXT3-fs error (device loop1): ext3_readdir: bad entry in directory #34817:
rec_len is smaller than minimal - offset=1009, inode=0, rec_len=0,
name_len=0
...
If we configured errors=remount-ro, the filesystem will become read-only.
SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
{
...
loff_t pos = file_pos_read(file);
ret = vfs_read(file, buf, count, pos);
file_pos_write(file, pos);
fput_light(file, fput_needed);
...
}
While readdir() is protected with i_mutex, f_pos can be changed without
any locking in various read()/write() syscalls, which leads to this bug.
What makes things worse is Andi removed i_mutex from generic_file_llseek,
so you can trigger the same bug by replacing read() with lseek() in the
test program.
Yes, and here I'd say it's a filesystem issue. If filesystem needs f_pos
changed only under i_mutex, it should use default_llseek() or get the mutex
itself. That's what the callback is for. We shouldn't unnecessarily impose
the i_mutex restriction on llseek on a directory for every filesystem.
One of my concern is, concurrent lseek() and readdir() doesn't seem to be
well tested. I'll add a test case in xfstests.
Yes, that might be a useful test to add.
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] backlight: adp8860/adp8870: Fix resume
Clearing the NSTBY bit in the control register also automatically clears the
BLEN bit. So we need to make sure to set it again during resume, otherwise the
backlight will stay off.
Cc: sta...@vger.kernel.org
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
---
drivers/video/backlight/adp8860_bl.c | 2 +-
drivers/video/backlight/adp8870_bl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/adp8860_bl.c
b/drivers/video/backlight/adp8860_bl.c
index 6bb72c0..a77c9ca 100644
--- a/drivers/video/backlight/adp8860_bl.c
+++ b/drivers/video/backlight/adp8860_bl.c
@@ -783,7 +783,7 @@ static int adp8860_i2c_suspend(struct i2c_client *client,
pm_message_t message)
static int adp8860_i2c_resume(struct i2c_client *client)
{
- adp8860_set_bits(client, ADP8860_MDCR, NSTBY);
+ adp8860_set_bits(client, ADP8860_MDCR, NSTBY | BLEN);
return 0;
}
diff --git a/drivers/video/backlight/adp8870_bl.c
b/drivers/video/backlight/adp8870_bl.c
index 63c882b..712c25a 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -957,7 +957,7 @@ static int adp8870_i2c_suspend(struct i2c_client *client,
pm_message_t message)
static int adp8870_i2c_resume(struct i2c_client *client)
{
- adp8870_set_bits(client, ADP8870_MDCR, NSTBY);
+ adp8870_set_bits(client, ADP8870_MDCR, NSTBY | BLEN);
return 0;
}
--
1.8.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/
[Bug fix PATCH 2/2] acpi, movablemem_map: Set numa_nodes_hotplug nodemask when using SRAT info.
We should also set movablemem_map.numa_nodes_hotplug nodemask when we
insert a hot-pluggable range in SRAT into movablemem_map.map[].
Signed-off-by: Tang Chen tangc...@cn.fujitsu.com
---
arch/x86/mm/srat.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index b20b5b7..62ba97b 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -164,6 +164,12 @@ handle_movablemem(int node, u64 start, u64 end, u32
hotpluggable)
*/
if (hotpluggable movablemem_map.acpi) {
insert_movablemem_map(start_pfn, end_pfn);
+
+ /*
+* numa_nodes_hotplug nodemask represents which nodes are put
+* into movablemem_map.map[].
+*/
+ node_set(node, movablemem_map.numa_nodes_hotplug);
goto out;
}
--
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/
[Bug fix PATCH 1/2] acpi, movablemem_map: Do not zero numa_meminfo in numa_init().
early_parse_srat() is called before numa_init(), and has initialized numa_meminfo. So do not zero numa_meminfo in numa_init(), otherwise we will lose memory numa info. Signed-off-by: Tang Chen tangc...@cn.fujitsu.com --- arch/x86/mm/numa.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c index 3545585..ff3633c 100644 --- a/arch/x86/mm/numa.c +++ b/arch/x86/mm/numa.c @@ -559,10 +559,12 @@ static int __init numa_init(int (*init_func)(void)) for (i = 0; i MAX_LOCAL_APIC; i++) set_apicid_to_node(i, NUMA_NO_NODE); - /* Do not clear numa_nodes_parsed because SRAT was parsed earlier. */ + /* +* Do not clear numa_nodes_parsed or zero numa_meminfo here, because +* SRAT was parsed earlier in early_parse_srat(). +*/ nodes_clear(node_possible_map); nodes_clear(node_online_map); - memset(numa_meminfo, 0, sizeof(numa_meminfo)); WARN_ON(memblock_set_node(0, ULLONG_MAX, MAX_NUMNODES)); numa_reset_distance(); -- 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 v2] tty: mxser: improve error handling in mxser_probe() and mxser_module_init()
On 02/19/2013 06:57 AM, Alexey Khoroshilov wrote:
1. Currently mxser_probe() and mxser_module_init() ignore errors
that can happen in tty_port_register_device().
2. mxser_module_init() does not deallocate resources allocated in
mxser_get_ISA_conf()
if mxser_initbrd() failed.
The patch adds proper error handling in all the cases.
Also it moves free_irq() from mxser_release_ISA_res() to mxser_board_remove(),
since it makes mxser_release_ISA_res() a counterpart for mxser_get_ISA_conf(),
while free_irq() is relevant to both ISA and PCI boards.
Found by Linux Driver Verification project (linuxtesting.org).
Looks good to me, thanks.
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/tty/mxser.c | 42 +++---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 4011386..deeb5ad 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
@@ -2364,7 +2364,6 @@ static void mxser_release_vector(struct mxser_board
*brd)
static void mxser_release_ISA_res(struct mxser_board *brd)
{
- free_irq(brd-irq, brd);
release_region(brd-ports[0].ioaddr, 8 * brd-info-nports);
mxser_release_vector(brd);
}
@@ -2430,6 +2429,7 @@ static void mxser_board_remove(struct mxser_board *brd)
tty_unregister_device(mxvar_sdriver, brd-idx + i);
tty_port_destroy(brd-ports[i].port);
}
+ free_irq(brd-irq, brd);
}
static int __init mxser_get_ISA_conf(int cap, struct mxser_board *brd)
@@ -2554,6 +2554,7 @@ static int mxser_probe(struct pci_dev *pdev,
struct mxser_board *brd;
unsigned int i, j;
unsigned long ioaddress;
+ struct device *tty_dev;
int retval = -EINVAL;
for (i = 0; i MXSER_BOARDS; i++)
@@ -2637,13 +2638,25 @@ static int mxser_probe(struct pci_dev *pdev,
if (retval)
goto err_rel3;
- for (i = 0; i brd-info-nports; i++)
- tty_port_register_device(brd-ports[i].port, mxvar_sdriver,
- brd-idx + i, pdev-dev);
+ for (i = 0; i brd-info-nports; i++) {
+ tty_dev = tty_port_register_device(brd-ports[i].port,
+ mxvar_sdriver, brd-idx + i, pdev-dev);
+ if (IS_ERR(tty_dev)) {
+ retval = PTR_ERR(tty_dev);
+ for (; i 0; i--)
+ tty_unregister_device(mxvar_sdriver,
+ brd-idx + i - 1);
+ goto err_relbrd;
+ }
+ }
pci_set_drvdata(pdev, brd);
return 0;
+err_relbrd:
+ for (i = 0; i brd-info-nports; i++)
+ tty_port_destroy(brd-ports[i].port);
+ free_irq(brd-irq, brd);
err_rel3:
pci_release_region(pdev, 3);
err_zero:
@@ -2665,7 +2678,6 @@ static void mxser_remove(struct pci_dev *pdev)
mxser_board_remove(brd);
- free_irq(pdev-irq, brd);
pci_release_region(pdev, 2);
pci_release_region(pdev, 3);
pci_disable_device(pdev);
@@ -2683,6 +2695,7 @@ static struct pci_driver mxser_driver = {
static int __init mxser_module_init(void)
{
struct mxser_board *brd;
+ struct device *tty_dev;
unsigned int b, i, m;
int retval;
@@ -2728,14 +2741,29 @@ static int __init mxser_module_init(void)
/* mxser_initbrd will hook ISR. */
if (mxser_initbrd(brd, NULL) 0) {
+ mxser_release_ISA_res(brd);
brd-info = NULL;
continue;
}
brd-idx = m * MXSER_PORTS_PER_BOARD;
- for (i = 0; i brd-info-nports; i++)
- tty_port_register_device(brd-ports[i].port,
+ for (i = 0; i brd-info-nports; i++) {
+ tty_dev = tty_port_register_device(brd-ports[i].port,
mxvar_sdriver, brd-idx + i, NULL);
+ if (IS_ERR(tty_dev)) {
+ for (; i 0; i--)
+ tty_unregister_device(mxvar_sdriver,
+ brd-idx + i - 1);
+ for (i = 0; i brd-info-nports; i++)
+ tty_port_destroy(brd-ports[i].port);
+ free_irq(brd-irq, brd);
+ mxser_release_ISA_res(brd);
+ brd-info = NULL;
+ break;
+ }
+ }
+ if (brd-info == NULL)
+ continue;
m++;
}
--
js
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug fix PATCH 0/2] Bug fix for movablemem_map boot option.
Two bug fix patches for movablemem_map boot option. root (2): acpi, movablemem_map: Do not zero numa_meminfo in numa_init(). acpi, movablemem_map: Set numa_nodes_hotplug nodemask when using SRAT info. arch/x86/mm/numa.c |6 -- arch/x86/mm/srat.c |6 ++ 2 files changed, 10 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/1] early_printk: Consolidate random copies of identical code
* Thomas Gleixner t...@linutronix.de wrote: The early console implementations are the same all over the place. Move the print function to kernel/printk and get rid of the copies. Signed-off-by: Thomas Gleixner t...@linutronix.de Cc: Russell King li...@arm.linux.org.uk Cc: Mike Frysinger vap...@gentoo.org Cc: Michal Simek mon...@monstr.eu Cc: Ralf Baechle r...@linux-mips.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mundt let...@linux-sh.org Cc: David S. Miller da...@davemloft.net Cc: Chris Metcalf cmetc...@tilera.com Cc: Richard Weinberger rich...@nod.at Cc: x...@kernel.org --- arch/arm/kernel/early_printk.c| 17 +++-- arch/blackfin/kernel/early_printk.c |2 -- arch/microblaze/kernel/early_printk.c | 26 -- arch/mips/kernel/early_printk.c | 11 +-- arch/powerpc/kernel/udbg.c|6 ++ arch/sh/kernel/sh_bios.c |2 -- arch/sparc/kernel/setup_32.c |1 + arch/sparc/kernel/setup_64.c |8 +++- arch/tile/kernel/early_printk.c | 27 +-- arch/um/kernel/early_printk.c |8 +--- arch/unicore32/kernel/early_printk.c | 12 arch/x86/kernel/early_printk.c| 21 ++--- include/linux/console.h |1 + include/linux/printk.h|6 ++ kernel/printk.c | 30 +++--- 15 files changed, 68 insertions(+), 110 deletions(-) Reviewed-by: Ingo Molnar mi...@kernel.org Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SYSFS errors
On Tue, Feb 19, 2013 at 09:46:40AM -0300, Mauro Carvalho Chehab wrote: Ah, now I see what you're meaning. That would require to dynamically create a per-mci DEVICE_ATTR(). Dude, look at the code, we do that already. And you're using it with dev_attr_sdram_scrub_rate. Simply change the permissions of the attribute before calling device_create_file. pseudo: umode_t mode = 0; if (mci-set...) mode |= S_IWUSR; if (mci-get...) mode |= S_IRUGO; dev_attr_sdram_scrub_rate.attr.mode = mode; device_create_file(mci-dev, dev_attr_sdram_scrub_rate); No, on both cases, open() will return an error (-ENOENT against -EPERM). What if it is a shell script doing: cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate or similar? Simply fixing the permissions fixes *all* possible cases. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] backlight: adp8860/adp8870: Fix resume
On 02/19/2013 02:02 PM, Lars-Peter Clausen wrote:
Clearing the NSTBY bit in the control register also automatically clears the
BLEN bit. So we need to make sure to set it again during resume, otherwise the
backlight will stay off.
Cc: sta...@vger.kernel.org
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Acked-by: Michael Hennerich michael.henner...@analog.com
---
drivers/video/backlight/adp8860_bl.c | 2 +-
drivers/video/backlight/adp8870_bl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/adp8860_bl.c
b/drivers/video/backlight/adp8860_bl.c
index 6bb72c0..a77c9ca 100644
--- a/drivers/video/backlight/adp8860_bl.c
+++ b/drivers/video/backlight/adp8860_bl.c
@@ -783,7 +783,7 @@ static int adp8860_i2c_suspend(struct i2c_client *client,
pm_message_t message)
static int adp8860_i2c_resume(struct i2c_client *client)
{
- adp8860_set_bits(client, ADP8860_MDCR, NSTBY);
+ adp8860_set_bits(client, ADP8860_MDCR, NSTBY | BLEN);
return 0;
}
diff --git a/drivers/video/backlight/adp8870_bl.c
b/drivers/video/backlight/adp8870_bl.c
index 63c882b..712c25a 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -957,7 +957,7 @@ static int adp8870_i2c_suspend(struct i2c_client *client,
pm_message_t message)
static int adp8870_i2c_resume(struct i2c_client *client)
{
- adp8870_set_bits(client, ADP8870_MDCR, NSTBY);
+ adp8870_set_bits(client, ADP8870_MDCR, NSTBY | BLEN);
return 0;
}
--
Greetings,
Michael
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] mfd:adp5520: Restore mode bits on resume
On 02/19/2013 11:51 AM, Lars-Peter Clausen wrote:
The adp5520 unfortunately also clears the BL_EN bit when the nSTNDBY bit is
cleared. So we need to make sure to restore it during resume if it was set
before suspend.
Cc: sta...@vger.kernel.org
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Acked-by: Michael Hennerich michael.henner...@analog.com
---
drivers/mfd/adp5520.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/adp5520.c b/drivers/mfd/adp5520.c
index 210dd03..6b40e0c 100644
--- a/drivers/mfd/adp5520.c
+++ b/drivers/mfd/adp5520.c
@@ -36,6 +36,7 @@ struct adp5520_chip {
struct blocking_notifier_head notifier_list;
int irq;
unsigned long id;
+ uint8_t mode;
};
static int __adp5520_read(struct i2c_client *client,
@@ -326,7 +327,10 @@ static int adp5520_suspend(struct device *dev)
struct i2c_client *client = to_i2c_client(dev);
struct adp5520_chip *chip = dev_get_drvdata(client-dev);
- adp5520_clr_bits(chip-dev, ADP5520_MODE_STATUS, ADP5520_nSTNBY);
+ adp5520_read(chip-dev, ADP5520_MODE_STATUS, chip-mode);
+ /* All other bits are W1C */
+ chip-mode = ADP5520_BL_EN | ADP5520_DIM_EN | ADP5520_nSTNBY;
+ adp5520_write(chip-dev, ADP5520_MODE_STATUS, 0);
return 0;
}
@@ -335,7 +339,7 @@ static int adp5520_resume(struct device *dev)
struct i2c_client *client = to_i2c_client(dev);
struct adp5520_chip *chip = dev_get_drvdata(client-dev);
- adp5520_set_bits(chip-dev, ADP5520_MODE_STATUS, ADP5520_nSTNBY);
+ adp5520_write(chip-dev, ADP5520_MODE_STATUS, chip-mode);
return 0;
}
#endif
--
Greetings,
Michael
--
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368;
Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin,
Margaret Seif
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 0/5] Generic PHY Framework
Hi, On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote: On Tuesday 19 February 2013, kishon wrote: On Tuesday 19 February 2013 04:14 PM, Arnd Bergmann wrote: On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. How does this relate to the generic PHY interfaces in drivers/net/phy? Currently drivers/phy and drivers/net/phy are independent and are not related to each other. There are some fundamental differences on how these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to match a PHY device with a PHY driver and the Ethernet device uses the bus layer to get the PHY. The Generic PHY Framework however doesn't have any bus layer. The PHY should be like any other Platform Devices and Drivers and the framework will provide some APIs to register with the framework. And there are other APIs which any controller can use to get the PHY (for e.g., in the case of dt boot, it can use phandle to get a reference to the PHY). Hmm, I think the use of a bus_type for a PHY actually sounds quite appropriate. The actual PHY device would then be a child of the really ? I'm not so sure, the *bus* used by the PHY is ULPI, UTMI, UTMI+, PIP3, I2C, etc... adding another 'fake' bus representation is a bit overkill IMO. Imagine an I2C-controlled PHY driver like isp1301, that driver will have to register i2c_driver and phy_driver, which looks weird to me. If the only substitute for class is a bus, we can't drop classes just yet, I'm afraid. Imagine a regulator bus, a pwm bus, an LED bus etc. They don't make sense IMHO. platform_device (or something else) that gets probed by its parent bus or the DT. The operations that you define for the PHY actually mirror some of the things that we have for a 'struct device', so I think it would be quite logical to do it the same way. Note that MDIO has both a 'bus' and a 'class', and what we want here is more like what the 'class' was meant for, except that for new classes, we should actually use a 'bus', since the long-term plan is to kill off the concept of a 'class'. I hope that was not too confusing. :) :) -- balbi signature.asc Description: Digital signature
Re: [PATCH] irqchip: Renesas INTC External IRQ pin driver
On Tue, 19 Feb 2013, Magnus Damm wrote:
On Tue, Feb 19, 2013 at 7:11 PM, Thomas Gleixner t...@linutronix.de wrote:
+static DEFINE_RAW_SPINLOCK(intc_irqpin_lock); /* only used by slow path */
Shouldn't the lock be part of struct intc_irqpin_priv ?
Good idea, but I need to lock access to the SENSE register against
multiple driver instances. This is not the case for PRIO. But because
both PRIO and SENSE are accessed in the slow path I decided to be lazy
and use the same way of locking to reduce the code size.
Fair enough.
+static void intc_irqpin_irq_enable_force(struct irq_data *d)
+{
+ struct intc_irqpin_priv *p = irq_data_get_irq_chip_data(d);
+ int irq = p-irq[irqd_to_hwirq(d)].irq;
+
+ intc_irqpin_irq_enable(d);
+ irq_get_chip(irq)-irq_unmask(irq_get_irq_data(irq));
+}
+
+static void intc_irqpin_irq_disable_force(struct irq_data *d)
+{
+ struct intc_irqpin_priv *p = irq_data_get_irq_chip_data(d);
+ int irq = p-irq[irqd_to_hwirq(d)].irq;
+
+ irq_get_chip(irq)-irq_mask(irq_get_irq_data(irq));
+ intc_irqpin_irq_disable(d);
Hmm. If I understand that code correctly, then the _force functions
are (un)masking another interrupt line. But this happens without
holding irq_desc[irq]-lock. Looks unsafe at least and if correct
wants a big fat comment.
On some SoCs the masking for some IRQs seems busted, and the only sane
way to work around that is to (un)mask the parent interrupt. The
parent happens to be the GIC. I will look into how to add locking.
Is there a 1:1 relationship between the intc interrupt and the GIC? If
yes and if nothing else fiddles with that particular GIC interrupt,
then you might get away without extra locking, but that wants a
comment at least.
+ irq_set_chip_and_handler(virq, p-irq_chip, handle_level_irq);
+ set_irq_flags(virq, IRQF_VALID); /* kill me now */
What needs to be killed? -ENOPARSE
I'd like to not have to set this flag in my interrupt code.
Ah.
I've written interrupt code on other architectures before, and from my
experience only ARM requires the IRQF_VALID flag to be set because the
ARM architecture software believes it is a special case. I may be
behind times - I have to admit that I've not checked the latest state
- this flag may not be needed anymore, hurray if so - but at least a
couple of years ago it was needed in case of ARM for our shared INTC
code (shared between sh and ARM).
What is your opinion about this matter?
It provides an extra paranoia level, but I'm not sure if it's really
worth the trouble.
Thanks,
tglx
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] SPI for v3.9
The following changes since commit 88b62b915b0b7e25870eb0604ed9a92ba4bfc9f7: Linux 3.8-rc6 (2013-02-01 12:08:14 +1100) are available in the git repository at: git://git.secretlab.ca/git/linux tags/spi-for-linus for you to fetch changes up to 095c3752e673c0ba039a2f67fd867297fde75ae7: spi: Document cs_gpios and cs_gpio in kernel-doc (2013-02-11 00:05:31 +) SPI changes for v3.9 Changes to both core spi code and spi device drivers. The driver changes are the usual set of bug fixes and platform enablement. Core code changes include: - More intelligent assignment of SPI bus numbers when using DT - Fixes to initialization and documentation of chipselect gpio array. - Pull checks for bits_per_word and transfer speed out of drivers and into core code - Ensure temporary DMA buffers are DMA safe Anatolij Gustschin (2): spi/mpc512x-psc: don't use obsolet cell-index property spi/spi-mpc512x-psc: init mode bits supported by the driver Andreas Larsson (2): spi/of: Fix initialization of cs_gpios array spi: Document cs_gpios and cs_gpio in kernel-doc Barry Song (2): spi/sirf: use clk_prepare_enable and clk_disable_unprepare spi/sirf: add support for new SiRFmarco SMP SoC Bastian Hecht (1): spi/sh-msiof: Add device tree parsing to driver Ezequiel Garcia (1): spi/orion: Use module_platform_driver() Fabio Estevam (1): spi/imx: Add MODULE_ALIAS() Felipe Balbi (1): spi/omap2: disable DMA requests before complete() Gabor Juhos (6): spi/ath79: add delay between SCK changes spi/ath79: add missing HIGH-LOW SCK transition spi/ath79: remove superfluous chip select code spi/ath79: use gpio_request_one spi/ath79: avoid multiple initialization of the SPI controller spi/ath79: add shutdown handler Grant Likely (4): spi/of: Use DT aliases for assigning bus number Merge branch 'broonie/spi-next' of git://git.kernel.org/.../broonie/misc.git spi: Remove erroneous __init, __exit and __exit_p() references in drivers Merge branch spi-next from git://git.kernel.org/.../broonie/misc.git Guennadi Liakhovetski (1): spi: bitbang: simplify pointer arithmetics Jingoo Han (2): spi/s3c64xx: Use devm_clk_get() and devm_request_irq() spi/s3c64xx: fix checkpatch warnings and error John Crispin (2): spi/mips-lantiq: make use of spi_finalize_current_message spi/mips-lantiq: set SPI_MASTER_HALF_DUPLEX flag Jonas Gorski (2): spi/bcm63xx: reject transfers unable to transfer spi/bcm63xx: work around inability to keep CS up Juha Lumme (1): mxs/spi: clear XFER_COUNT in ctrl0 field in DMA descriptor Laxman Dewangan (3): spi: remove check for bits_per_word on transfer from low level driver spi: make sure all transfer has proper speed set spi/tegra: remove checks for valid speed Mark Brown (3): spi/s3c64xx: Complain if we fail to set a transfer speed MAINTAINERS: Add myself as a backup maintainer for SPI spi: Ensure memory used for spi_write_then_read() is DMA safe Matthias Brugger (2): spi: spi-omap2-mcspi.c: fix coding style spi: spi-omap2-mcspi.c: Toggle CS after each word Maxime Ripard (2): spi: spi-gpio: Add checks for the dt properties spi: spi-gpio: fix compilation warning on 64 bits systems Mika Westerberg (12): spi/pxa2xx-pci: switch to use pcim_* interfaces spi/pxa2xx: embed the ssp_device to platform data spi/pxa2xx: allow building on a 64-bit kernel spi/pxa2xx: fix warnings when compiling a 64-bit kernel spi/pxa2xx: convert to the pump message infrastructure spi/pxa2xx: convert to the common clk framework spi/pxa2xx: break out the private DMA API usage into a separate file spi/pxa2xx: add support for DMA engine spi/pxa2xx: add support for runtime PM spi/pxa2xx: add support for SPI_LOOP spi/pxa2xx: add support for Intel Low Power Subsystem SPI spi/pxa2xx: add support for Lynxpoint SPI controllers Murali Karicheri (2): spi/davinci: add OF support for the spi controller spi/davinci: use request_threaded_irq() to fix deadlock Documentation/devicetree/bindings/spi/sh-msiof.txt | 12 + MAINTAINERS|1 + drivers/spi/Kconfig| 15 +- drivers/spi/Makefile |5 +- drivers/spi/spi-altera.c |2 +- drivers/spi/spi-ath79.c| 115 +- drivers/spi/spi-atmel.c|2 +- drivers/spi/spi-au1550.c |8 +- drivers/spi/spi-bcm63xx.c | 179 +++- drivers/spi/spi-bfin-sport.c |3 +- drivers/spi/spi-bfin5xx.c
Re: SYSFS errors
On Tue, Feb 19, 2013 at 02:06:26PM +0100, Borislav Petkov wrote: On Tue, Feb 19, 2013 at 09:46:40AM -0300, Mauro Carvalho Chehab wrote: Ah, now I see what you're meaning. That would require to dynamically create a per-mci DEVICE_ATTR(). Dude, look at the code, we do that already. And you're using it with dev_attr_sdram_scrub_rate. Simply change the permissions of the attribute before calling device_create_file. pseudo: umode_t mode = 0; if (mci-set...) mode |= S_IWUSR; if (mci-get...) mode |= S_IRUGO; dev_attr_sdram_scrub_rate.attr.mode = mode; device_create_file(mci-dev, dev_attr_sdram_scrub_rate); No, on both cases, open() will return an error (-ENOENT against -EPERM). What if it is a shell script doing: cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate what's the problem with that ? $ cat /path/to/file/that/doesnt/exist.txt cat: /path/to/file/that/doesnt/exist.txt: No such file or directory Didn't see any gates to hell opening here... -- balbi signature.asc Description: Digital signature
Re: [Bug fix PATCH 1/2] acpi, movablemem_map: Do not zero numa_meminfo in numa_init().
Sorry, add cc Li Shaohua. Reported-by: Li Shaohua s...@kernel.org On 02/19/2013 09:01 PM, Tang Chen wrote: early_parse_srat() is called before numa_init(), and has initialized numa_meminfo. So do not zero numa_meminfo in numa_init(), otherwise we will lose memory numa info. Signed-off-by: Tang Chentangc...@cn.fujitsu.com --- arch/x86/mm/numa.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c index 3545585..ff3633c 100644 --- a/arch/x86/mm/numa.c +++ b/arch/x86/mm/numa.c @@ -559,10 +559,12 @@ static int __init numa_init(int (*init_func)(void)) for (i = 0; i MAX_LOCAL_APIC; i++) set_apicid_to_node(i, NUMA_NO_NODE); - /* Do not clear numa_nodes_parsed because SRAT was parsed earlier. */ + /* +* Do not clear numa_nodes_parsed or zero numa_meminfo here, because +* SRAT was parsed earlier in early_parse_srat(). +*/ nodes_clear(node_possible_map); nodes_clear(node_online_map); - memset(numa_meminfo, 0, sizeof(numa_meminfo)); WARN_ON(memblock_set_node(0, ULLONG_MAX, MAX_NUMNODES)); numa_reset_distance(); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cma: fix accounting of CMA pages placed in high memory
On 02/05/2013 03:10 PM, Marek Szyprowski wrote: Hello, On 2/5/2013 12:34 AM, Minchan Kim wrote: On Mon, Feb 04, 2013 at 11:27:05AM +0100, Marek Szyprowski wrote: The total number of low memory pages is determined as totalram_pages - totalhigh_pages, so without this patch all CMA pageblocks placed in highmem were accounted to low memory. So what's the end user effect? With the effect, we have to decide routing it on stable. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- mm/page_alloc.c |4 1 file changed, 4 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index f5bab0a..6415d93 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -773,6 +773,10 @@ void __init init_cma_reserved_pageblock(struct page *page) set_pageblock_migratetype(page, MIGRATE_CMA); __free_pages(page, pageblock_order); totalram_pages += pageblock_nr_pages; +#ifdef CONFIG_HIGHMEM We don't need #ifdef/#endif. #ifdef is required to let this code compile when highmem is not enabled, becuase totalhigh_pages is defined as 0, see include/linux/highmem.h Hi Marek, 1) Why can support CMA regions placed in highmem? CMA is for dma buffer, correct? Then how can old dma device access highmem? 2) Why there is no totalhigh_pages variable define in the case of config highmem? +if (PageHighMem(page)) +totalhigh_pages += pageblock_nr_pages; +#endif } #endif Best regards -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: SYSFS errors
On Tue, Feb 19, 2013 at 03:15:00PM +0200, Felipe Balbi wrote: what's the problem with that ? Not a problem - simply annoying. $ ./test.sh cat: /path/to/file/that/doesnt/exist.txt: No such file or directory Setting scrubrate to: I'm sure someone would ask themselves why all of a sudden the file is gone. $ cat /path/to/file/that/doesnt/exist.txt cat: /path/to/file/that/doesnt/exist.txt: No such file or directory Didn't see any gates to hell opening here... And I don't see why we have to debate such a trivial thing when we can fix it *properly* without *absolutely* *not* upsetting userspace. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [char-misc-next 01/12 v3] mei: Rename mei_device to mei_host
On Wed, Feb 13, 2013 at 11:39 AM, Samuel Ortiz sa...@linux.intel.com wrote: On Tue, Feb 12, 2013 at 11:09:00PM +, Arnd Bergmann wrote: On Tuesday 12 February 2013, gre...@linuxfoundation.org wrote: Please let's find something that makes both hw and Linux happy I still believe it makes sense to use mei_device for what we add to the MEI bus. I'd be fine with mei_bus_device as well, but that would somehow look a bit awkward. Greg, Arnd, any preference ? mei_device works the best for me. Tomas, what you think of as a MEI Device really is a MEI Controller, it bridges the difference between the PCI bus and your new MEI bus, so you will need to start thinking of these things a bit differently now that you have created your own little virtual bus. Yes, I agree. mei_bus_device would also work as the name for the controller, but not for the devices attached to it IMO. Tomas, I propose to switch to mei_controller instead of mei_host and keep the mei_device name for the devices we attach to the MEI bus. Does that work for you ? The issue is that when we added our virtual bus we haven't gave up on /dev/mei backed by mei_device This is the interface, defined in linux/mei.h which user space applications use to connect to ME Clients within ME device. Any ME client can be connected through this interface and we have few legacy applications running for few years that use this interface so we are not going to break them. What we've done now is we added a virtual bus so also in-kernel applications/subsystems can more naturally connect to the ME Clients, this connection is client specific. So the device that connect to the bus is not an mei device but mei client device hence the name I've proposed mei_cl_device. Does it make sense? Thanks Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.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/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NET: ath5k, check ath5k_eeprom_mode_from_channel retval
On 02/18/2013 01:47 AM, Nick Kossifidis wrote:
int
ath5k_eeprom_mode_from_channel(struct ieee80211_channel *channel)
{
switch (channel-hw_value) {
case AR5K_MODE_11A:
return AR5K_EEPROM_MODE_11A;
case AR5K_MODE_11G:
return AR5K_EEPROM_MODE_11G;
case AR5K_MODE_11B:
return AR5K_EEPROM_MODE_11B;
default:
return -1;
}
}
I think we should just change that default to return 0 instead and add
an ATH5K_WARN there.
Something like the attached patch? It needs ah to be propagated to
eeprom. If you are fine with that, I'll send it as patch...
thanks,
--
js
suse labs
From 0e75c33da1f8b35ff1d25f08650e95fc97c01528 Mon Sep 17 00:00:00 2001
From: Jiri Slaby jsl...@suse.cz
Date: Tue, 19 Feb 2013 14:31:13 +0100
Subject: [PATCH] ath5k: cleanup channel to eprom_mode function
Stop returning negative values from ath5k_eeprom_mode_from_channel.
Warn about that case instead and return the default/0/A. This cleans
up the callers, but needs to pass ah down to
ath5k_eeprom_mode_from_channel for ATH5K_WARN.
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
drivers/net/wireless/ath/ath5k/eeprom.c | 6 --
drivers/net/wireless/ath/ath5k/eeprom.h | 5 -
drivers/net/wireless/ath/ath5k/phy.c| 20 +++-
drivers/net/wireless/ath/ath5k/reset.c | 4 +---
4 files changed, 12 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/eeprom.c b/drivers/net/wireless/ath/ath5k/eeprom.c
index b7e0258..94d34ee 100644
--- a/drivers/net/wireless/ath/ath5k/eeprom.c
+++ b/drivers/net/wireless/ath/ath5k/eeprom.c
@@ -1779,7 +1779,8 @@ ath5k_eeprom_detach(struct ath5k_hw *ah)
}
int
-ath5k_eeprom_mode_from_channel(struct ieee80211_channel *channel)
+ath5k_eeprom_mode_from_channel(struct ath5k_hw *ah,
+ struct ieee80211_channel *channel)
{
switch (channel-hw_value) {
case AR5K_MODE_11A:
@@ -1789,6 +1790,7 @@ ath5k_eeprom_mode_from_channel(struct ieee80211_channel *channel)
case AR5K_MODE_11B:
return AR5K_EEPROM_MODE_11B;
default:
- return -1;
+ ATH5K_WARN(ah, channel is not A/B/G!);
+ return AR5K_EEPROM_MODE_11A;
}
}
diff --git a/drivers/net/wireless/ath/ath5k/eeprom.h b/drivers/net/wireless/ath/ath5k/eeprom.h
index 94a9bbe..dcc3e40 100644
--- a/drivers/net/wireless/ath/ath5k/eeprom.h
+++ b/drivers/net/wireless/ath/ath5k/eeprom.h
@@ -494,5 +494,8 @@ struct ath5k_eeprom_info {
u32 ee_antenna[AR5K_EEPROM_N_MODES][AR5K_ANT_MAX];
};
+struct ath5k_hw;
+
int
-ath5k_eeprom_mode_from_channel(struct ieee80211_channel *channel);
+ath5k_eeprom_mode_from_channel(struct ath5k_hw *ah,
+ struct ieee80211_channel *channel);
diff --git a/drivers/net/wireless/ath/ath5k/phy.c b/drivers/net/wireless/ath/ath5k/phy.c
index a78afa9..d6bc7cb 100644
--- a/drivers/net/wireless/ath/ath5k/phy.c
+++ b/drivers/net/wireless/ath/ath5k/phy.c
@@ -1612,11 +1612,7 @@ ath5k_hw_update_noise_floor(struct ath5k_hw *ah)
ah-ah_cal_mask |= AR5K_CALIBRATION_NF;
- ee_mode = ath5k_eeprom_mode_from_channel(ah-ah_current_channel);
- if (WARN_ON(ee_mode 0)) {
- ah-ah_cal_mask = ~AR5K_CALIBRATION_NF;
- return;
- }
+ ee_mode = ath5k_eeprom_mode_from_channel(ah, ah-ah_current_channel);
/* completed NF calibration, test threshold */
nf = ath5k_hw_read_measured_noise_floor(ah);
@@ -2317,12 +2313,7 @@ ath5k_hw_set_antenna_mode(struct ath5k_hw *ah, u8 ant_mode)
def_ant = ah-ah_def_ant;
- ee_mode = ath5k_eeprom_mode_from_channel(channel);
- if (ee_mode 0) {
- ATH5K_ERR(ah,
- invalid channel: %d\n, channel-center_freq);
- return;
- }
+ ee_mode = ath5k_eeprom_mode_from_channel(ah, channel);
switch (ant_mode) {
case AR5K_ANTMODE_DEFAULT:
@@ -3622,12 +3613,7 @@ ath5k_hw_txpower(struct ath5k_hw *ah, struct ieee80211_channel *channel,
return -EINVAL;
}
- ee_mode = ath5k_eeprom_mode_from_channel(channel);
- if (ee_mode 0) {
- ATH5K_ERR(ah,
- invalid channel: %d\n, channel-center_freq);
- return -EINVAL;
- }
+ ee_mode = ath5k_eeprom_mode_from_channel(ah, channel);
/* Initialize TX power table */
switch (ah-ah_radio) {
diff --git a/drivers/net/wireless/ath/ath5k/reset.c b/drivers/net/wireless/ath/ath5k/reset.c
index e2d8b2c..a3399c4 100644
--- a/drivers/net/wireless/ath/ath5k/reset.c
+++ b/drivers/net/wireless/ath/ath5k/reset.c
@@ -984,9 +984,7 @@ ath5k_hw_commit_eeprom_settings(struct ath5k_hw *ah,
if (ah-ah_version == AR5K_AR5210)
return;
- ee_mode = ath5k_eeprom_mode_from_channel(channel);
- if (WARN_ON(ee_mode 0))
- return;
+ ee_mode = ath5k_eeprom_mode_from_channel(ah, channel);
/* Adjust power delta for channel 14 */
if (channel-center_freq == 2484)
--
1.8.1.2
Re: [PATCH] staging: android: ashmem: get_name, set_name not to hold ashmem_mutex
Good job fixing the bug. :) My one concern would be that in set_name() there is a race caused by dropping the lock. It would be better to do that copy_from_user() first, before taking the lock. I don't expect this to actually be a problem in real life. + /* +* Local variable to hold the name copied from user space +* This variable is approx of size 270 bytes, not huge +*/ + char local_name[ASHMEM_NAME_LEN]; These obvious comments are not needed. We trust you do not overflow the stack. ;) Also it's checked automatically during build. Looks good generally. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SYSFS errors
Hi, On Tue, Feb 19, 2013 at 02:28:54PM +0100, Borislav Petkov wrote: On Tue, Feb 19, 2013 at 03:15:00PM +0200, Felipe Balbi wrote: what's the problem with that ? Not a problem - simply annoying. $ ./test.sh cat: /path/to/file/that/doesnt/exist.txt: No such file or directory Setting scrubrate to: I'm sure someone would ask themselves why all of a sudden the file is gone. $ cat /path/to/file/that/doesnt/exist.txt cat: /path/to/file/that/doesnt/exist.txt: No such file or directory Didn't see any gates to hell opening here... And I don't see why we have to debate such a trivial thing when we can fix it *properly* without *absolutely* *not* upsetting userspace. because changing the permission will cause the same issue: $ cat temporary.txt cat: temporary.txt: Permission denied $ ls -l temporary.txt -- 1 balbi balbi 0 Feb 19 15:37 temporary.txt $ cat temporary.txt cat: temporary.txt: Permission denied $ cat non-existent.txt cat: non-existent.txt: No such file or directory just a different error code is returned... -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/2] mm: hotplug: implement non-movable version of get_user_pages() called get_user_pages_non_movable()
Hi Mel,
On 02/05/2013 09:32 PM, Mel Gorman wrote:
On Tue, Feb 05, 2013 at 11:57:22AM +, Mel Gorman wrote:
+ migrate_pre_flag = 1;
+ }
+
+ if (!isolate_lru_page(pages[i])) {
+ inc_zone_page_state(pages[i], NR_ISOLATED_ANON +
+ page_is_file_cache(pages[i]));
+ list_add_tail(pages[i]-lru, pagelist);
+ } else {
+ isolate_err = 1;
+ goto put_page;
+ }
isolate_lru_page() takes the LRU lock every time.
Credit to Michal Hocko for bringing this up but with the number of
other issues I missed that this is also broken with respect to huge page
handling. hugetlbfs pages will not be on the LRU so the isolation will mess
up and the migration has to be handled differently. Ordinarily hugetlbfs
pages cannot be allocated from ZONE_MOVABLE but it is possible to configure
it to be allowed via /proc/sys/vm/hugepages_treat_as_movable. If this
encounters a hugetlbfs page, it'll just blow up.
I look into the migrate_huge_page() codes find that if we support the hugetlbfs
non movable migration, we have to invent another
alloc_huge_page_node_nonmovable()
or such allocate interface, which cost is large(exploding the codes and great
impact
on current alloc_huge_page_node()) but gains little, I think that pinning
hugepage
is a corner case.
So can we skip over hugepage without migration but give some WARN_ON() info, is
it acceptable?
The other is that this almost certainly broken for transhuge page
handling. gup returns the head and tail pages and ordinarily this is ok
I can't find codes doing such things :(, could you please point me out?
because the caller only cares about the physical address. Migration will
also split a hugepage if it receives it but you are potentially adding
tail pages to a list here and then migrating them. The split of the first
page will get very confused. I'm not exactly sure what the result will be
but it won't be pretty.
Was THP enabled when this was tested? Was CONFIG_DEBUG_LIST enabled
during testing?
I checked my config file that both CONFIG options aboved are enabled. However
it was
only be tested by two services invoking io_setup(), it works fine..
thanks,
linfeng
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] spi: tegra114: add spi driver
Add spi driver for NVIDIA's Tegra114 spi controller. This controller
is different than the older SoCs spi controller in internal design as
well as register interface.
This driver supports the:
- non DMA based transfer for smaller transfer i.e. less than FIFO depth.
- APB DMA based transfer for lager transfer i.e. more than FIFO depth.
- Clock gating through runtime PM callbacks.
- registration through DT only.
Signed-off-by: Laxman Dewangan ldewan...@nvidia.com
---
.../bindings/spi/nvidia,spi-tegra114.txt | 25 +
drivers/spi/Kconfig|8 +
drivers/spi/Makefile |1 +
drivers/spi/spi-tegra114.c | 1259
4 files changed, 1293 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/spi/nvidia,spi-tegra114.txt
create mode 100644 drivers/spi/spi-tegra114.c
diff --git a/Documentation/devicetree/bindings/spi/nvidia,spi-tegra114.txt
b/Documentation/devicetree/bindings/spi/nvidia,spi-tegra114.txt
new file mode 100644
index 000..c6457e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,spi-tegra114.txt
@@ -0,0 +1,25 @@
+NVIDIA Tegra114 SPI controller.
+
+Required properties:
+- compatible : should be nvidia,tegra114-spi.
+- reg: Should contain SPI registers location and length.
+- interrupts: Should contain SPI interrupts.
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+ request selector for this SPI controller.
+
+Recommended properties:
+- spi-max-frequency: Definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+Example:
+
+spi@7000d600 {
+ compatible = nvidia,tegra114-spi;
+ reg = 0x7000d600 0x200;
+ interrupts = 0 82 0x04;
+ nvidia,dma-request-selector = apbdma 16;
+ spi-max-frequency = 2500;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+};
+
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index f80eee7..5ceac2f 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -405,6 +405,14 @@ config SPI_TEGRA20_SFLASH
The main usecase of this controller is to use spi flash as boot
device.
+config SPI_TEGRA114
+ tristate Nvidia Tegra114 SPI Controller
+ depends on ARCH_TEGRA TEGRA20_APB_DMA
+ help
+ SPI driver for Nvidia Tegra114 SPI Controller interface. This
controller
+ is different than the older SoCs spi controller and also register
interface
+ get changed with this controller.
+
config SPI_TEGRA20_SLINK
tristate Nvidia Tegra20/Tegra30 SLINK Controller
depends on ARCH_TEGRA TEGRA20_APB_DMA
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index e53c309..cf2f534 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_SPI_SH_MSIOF)+= spi-sh-msiof.o
obj-$(CONFIG_SPI_SH_SCI) += spi-sh-sci.o
obj-$(CONFIG_SPI_SIRF) += spi-sirf.o
obj-$(CONFIG_SPI_TEGRA20_SFLASH) += spi-tegra20-sflash.o
+obj-$(CONFIG_SPI_TEGRA114) += spi-tegra114.o
obj-$(CONFIG_SPI_TEGRA20_SLINK)+= spi-tegra20-slink.o
obj-$(CONFIG_SPI_TI_SSP) += spi-ti-ssp.o
obj-$(CONFIG_SPI_TLE62X0) += spi-tle62x0.o
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
new file mode 100644
index 000..a77e719
--- /dev/null
+++ b/drivers/spi/spi-tegra114.c
@@ -0,0 +1,1259 @@
+/*
+ * SPI driver for NVIDIA's Tegra114 SPI Controller.
+ *
+ * Copyright (c) 2013, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/clk.h
+#include linux/clk/tegra.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/dmaengine.h
+#include linux/dma-mapping.h
+#include linux/dmapool.h
+#include linux/err.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/kthread.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/spi/spi.h
+
+#define SPI_COMMAND1 0x000
+#define SPI_BIT_LENGTH(x) (((x) 0x1f) 0)
+#define SPI_PACKED (1 5)
+#define SPI_TX_EN (1
Re: SYSFS errors
Em Tue, 19 Feb 2013 14:06:26 +0100 Borislav Petkov b...@alien8.de escreveu: No, on both cases, open() will return an error (-ENOENT against -EPERM). What if it is a shell script doing: cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate or similar? Well, cat will return 1 if an error is found, no matter what error happened. With an existing file (-ENOSYS): $ cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate; echo $? cat: /sys/devices/system/edac/mc/mc0/sdram_scrub_rate: No such device 1 When the file doesn't exist (-ENOENT): $ cat /sys/devices/system/edac/mc/mc0/sdram_scrub_rate_not_exist; echo $? cat: /sys/devices/system/edac/mc/mc0/sdram_scrub_rate_not_exist: No such file or directory 1 When permission doesn't match (-EPERM): $ cat /sys/devices/system/cpu/probe; echo $? cat: /sys/devices/system/cpu/probe: Permission denied 1 When everything is ok, it will return 0 $ cat /sys/devices/system/edac/mc/mc0/ce_count; echo $? /dev/null 0 A script ready to handle -ENOSYS would be doing, instead: RATE=$(cat /sys/devices/system/edac/mc/mc0/ce_count 2/dev/null) if [ $? == 0 ]; then echo Scrub rate: $RATE; fi So, a bash script won't notice any difference. The only difference will be noticed if the script is written on some other language and the script is dumb enough to assume success if the errno is different than -ENOSYS. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
On Tue, 2013-02-19 at 08:03 +, Jan Beulich wrote:
The core of
it is that the put here parallels the one in netbk_tx_err(), and
the one in xenvif_carrier_off() matches the get from
xenvif_connect() (which normally would be done on the path
coming through xenvif_disconnect()).
A few people have made this mistake already, perhaps this helps make it
more obvious what is going on...
8
From 7b93077e2cda5881b594d9c7e733e617df87d7c0 Mon Sep 17 00:00:00 2001
From: Ian Campbell ian.campb...@citrix.com
Date: Tue, 19 Feb 2013 10:46:12 +
Subject: [PATCH] xen/netback: refactor xenvif_carrier_on from xenvif_connect
Several people have been confused by the vif reference count taken by
xenvif_connect() being dropped in xenvif_carrier_off(). Factor out bringing
the carrier up (and the associated reference grab) to try and make the
relationship more obvious.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
drivers/net/xen-netback/interface.c | 49 +++---
1 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index d984141..059d726 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -307,6 +307,32 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t
domid,
return vif;
}
+static void xenvif_carrier_on(struct xenvif *vif)
+{
+ xenvif_get(vif);
+
+ rtnl_lock();
+ if (!vif-can_sg vif-dev-mtu ETH_DATA_LEN)
+ dev_set_mtu(vif-dev, ETH_DATA_LEN);
+ netdev_update_features(vif-dev);
+ netif_carrier_on(vif-dev);
+ if (netif_running(vif-dev))
+ xenvif_up(vif);
+ rtnl_unlock();
+}
+
+void xenvif_carrier_off(struct xenvif *vif)
+{
+ struct net_device *dev = vif-dev;
+
+ rtnl_lock();
+ netif_carrier_off(dev); /* discard queued packets */
+ if (netif_running(dev))
+ xenvif_down(vif);
+ rtnl_unlock();
+ xenvif_put(vif);
+}
+
int xenvif_connect(struct xenvif *vif, unsigned long tx_ring_ref,
unsigned long rx_ring_ref, unsigned int evtchn)
{
@@ -328,16 +354,7 @@ int xenvif_connect(struct xenvif *vif, unsigned long
tx_ring_ref,
vif-irq = err;
disable_irq(vif-irq);
- xenvif_get(vif);
-
- rtnl_lock();
- if (!vif-can_sg vif-dev-mtu ETH_DATA_LEN)
- dev_set_mtu(vif-dev, ETH_DATA_LEN);
- netdev_update_features(vif-dev);
- netif_carrier_on(vif-dev);
- if (netif_running(vif-dev))
- xenvif_up(vif);
- rtnl_unlock();
+ xenvif_carrier_on(vif);
return 0;
err_unmap:
@@ -346,18 +363,6 @@ err:
return err;
}
-void xenvif_carrier_off(struct xenvif *vif)
-{
- struct net_device *dev = vif-dev;
-
- rtnl_lock();
- netif_carrier_off(dev); /* discard queued packets */
- if (netif_running(dev))
- xenvif_down(vif);
- rtnl_unlock();
- xenvif_put(vif);
-}
-
void xenvif_disconnect(struct xenvif *vif)
{
if (netif_carrier_ok(vif-dev))
--
1.7.2.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/
[GIT PULL] RCU changes for v3.9
Linus, Please pull the latest core-rcu-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus HEAD: ac0e32024b8f40987b3db7d2defdc6b5153ba354 Merge branch 'rcu/srcu' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/rcu SRCU changes: - These include debugging aids, updates that move towards the goal of permitting srcu_read_lock() and srcu_read_unlock() to be used from idle and offline CPUs, and a few small fixes. Changes to rcutorture and to RCU documentation: - Posted to LKML at https://lkml.org/lkml/2013/1/26/188 Enhancements to uniprocessor handling in tiny RCU: - Posted to LKML at https://lkml.org/lkml/2013/1/27/2 Tag RCU callbacks with grace-period number to simplify callback advancement: - Posted to LKML at https://lkml.org/lkml/2013/1/26/203 Miscellaneous fixes: - Posted to LKML at https://lkml.org/lkml/2013/1/26/204 Thanks, Ingo -- Cody P Schafer (1): rcu: Correct 'optimized' to 'optimize' in header comment Dave Hansen (1): rcu: Consolidate debugging Kconfig options Frederic Weisbecker (1): context_tracking: Add comments on interface and internals Josh Triplett (1): rcu: Make rcu_is_cpu_rrupt_from_idle helper functions static Lai Jiangshan (8): srcu: Simplify __srcu_read_unlock() via this_cpu_dec() srcu: Add might_sleep() annotation to synchronize_srcu() srcu: Simple cleanup for cleanup_srcu_struct() srcu: Remove checks preventing offline CPUs from calling srcu_read_lock() srcu: Remove checks preventing idle CPUs from calling srcu_read_lock() srcu: Update synchronize_srcu()'s comments srcu: Update synchronize_srcu_expedited()'s comments srcu: use ACCESS_ONCE() to access sp-completed in srcu_read_lock() Li Zhong (2): rcu: Use new nesting value for rcu_dyntick trace in rcu_eqs_enter_common rcu: Remove unused code originally used for context tracking Paul E. McKenney (10): tracing: Export trace_clock_local() rcu: Reduce rcutorture tracing rcu: Fix blimit type for trace_rcu_batch_start() rcu: Silence compiler array out-of-bounds false positive rcu: Tag callback lists with corresponding grace-period number rcu: Trace callback acceleration rcu: Remove obsolete Kconfig option from comment rcu: Provide RCU CPU stall warnings for tiny RCU rcu: Allow TREE_PREEMPT_RCU on UP systems rcu: Make rcutorture's shuffler task shuffle recently added tasks Paul Gortmaker (2): rcu: Prevent soft-lockup complaints about no-CBs CPUs rcu: Make rcu_nocb_poll an early_param instead of module_param Richard Braun (1): Documentation: Memory barrier semantics of atomic_xchg() Sasha Levin (1): rcutorture: Don't compare ptr with 0 Steven Rostedt (1): rcu: Allow rcutorture to be built at low optimization levels Documentation/atomic_ops.txt| 2 + Documentation/kernel-parameters.txt | 2 +- Documentation/memory-barriers.txt | 1 + include/linux/rcupdate.h| 15 ++- include/linux/srcu.h| 26 +--- include/trace/events/rcu.h | 31 +++-- init/Kconfig| 12 +- kernel/context_tracking.c | 75 +-- kernel/rcu.h| 7 + kernel/rcupdate.c | 60 - kernel/rcutiny.c| 8 +- kernel/rcutiny_plugin.h | 56 kernel/rcutorture.c | 66 +++-- kernel/rcutree.c| 260 +--- kernel/rcutree.h| 11 +- kernel/rcutree_plugin.h | 13 +- kernel/srcu.c | 37 +++-- kernel/trace/trace_clock.c | 1 + lib/Kconfig.debug | 117 19 files changed, 567 insertions(+), 233 deletions(-) diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index 27f2b21..d9ca5be 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt @@ -253,6 +253,8 @@ This performs an atomic exchange operation on the atomic variable v, setting the given new value. It returns the old value that the atomic variable v had just before the operation. +atomic_xchg requires explicit memory barriers around the operation. + int atomic_cmpxchg(atomic_t *v, int old, int new); This performs an atomic compare exchange operation on the atomic value v, diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 363e348..6c72381 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2438,7 +2438,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. real-time workloads. It can also improve energy efficiency for asymmetric
Re: SYSFS errors
On Tue, Feb 19, 2013 at 03:38:09PM +0200, Felipe Balbi wrote:
because changing the permission will cause the same issue:
Actually, I take that back. Mauro's patch will already create the file
anyway:
if (mci-set_sdram_scrub_rate || mci-get_sdram_scrub_rate)
Adjusting the permissions is simply the last missing piece to this patch
to make the interface to userspace 100% coherent.
--
From: Mauro Carvalho Chehab mche...@redhat.com
Date: Tue, 19 Feb 2013 09:16:10 -0300
Subject: [PATCH] EDAC: only create sdram_scrub_rate where supported
Currently, sdram_scrub_rate sysfs node is created even if the device
doesn't support get/set the scub rate. Change the logic to only
create this device node when the operation is supported.
If only read or only write is supported, it will keep returning -ENODEV
just like before.
Reported-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/edac/edac_mc_sysfs.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 0ca1ca71157f..5a788e60ff67 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -7,7 +7,7 @@
*
* Written Doug Thompson nor...@xmission.com www.softwarebitmaker.com
*
- * (c) 2012 - Mauro Carvalho Chehab mche...@redhat.com
+ * (c) 2012-2013 - Mauro Carvalho Chehab mche...@redhat.com
* The entire API were re-written, and ported to use struct device
*
*/
@@ -878,7 +878,6 @@ static struct attribute *mci_attrs[] = {
dev_attr_ce_noinfo_count.attr,
dev_attr_ue_count.attr,
dev_attr_ce_count.attr,
- dev_attr_sdram_scrub_rate.attr,
dev_attr_max_location.attr,
NULL
};
@@ -1012,6 +1011,23 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info
*mci)
return err;
}
+ if (mci-set_sdram_scrub_rate || mci-get_sdram_scrub_rate) {
+ umode_t mode = 0;
+
+ if (mci-get_sdram_scrub_rate)
+ mode = S_IRUGO;
+
+ if (mci-set_sdram_scrub_rate)
+ mode |= S_IWUSR;
+
+ dev_attr_sdram_scrub_rate.attr.mode = mode;
+
+ err = device_create_file(mci-dev, dev_attr_sdram_scrub_rate);
+ if (err) {
+ edac_dbg(1, failure: create sdram_scrub_rate\n);
+ goto fail2;
+ }
+ }
/*
* Create the dimm/rank devices
*/
@@ -1056,6 +1072,7 @@ fail:
continue;
device_unregister(dimm-dev);
}
+fail2:
device_unregister(mci-dev);
bus_unregister(mci-bus);
kfree(mci-bus.name);
--
1.8.1.3.535.ga923c31
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: SYSFS errors
Em Tue, 19 Feb 2013 15:38:09 +0200 Felipe Balbi ba...@ti.com escreveu: Hi, On Tue, Feb 19, 2013 at 02:28:54PM +0100, Borislav Petkov wrote: On Tue, Feb 19, 2013 at 03:15:00PM +0200, Felipe Balbi wrote: what's the problem with that ? Not a problem - simply annoying. $ ./test.sh cat: /path/to/file/that/doesnt/exist.txt: No such file or directory Setting scrubrate to: I'm sure someone would ask themselves why all of a sudden the file is gone. $ cat /path/to/file/that/doesnt/exist.txt cat: /path/to/file/that/doesnt/exist.txt: No such file or directory Didn't see any gates to hell opening here... And I don't see why we have to debate such a trivial thing when we can fix it *properly* without *absolutely* *not* upsetting userspace. because changing the permission will cause the same issue: It is actually worse, as if someone is using a C code to open the device with fp = open (/sys/devices/system/edac/mc/mc0/sdram_scrub_rate, O_RDWR); It will now start to fail if the device doesn't have both permissions. Regards, Mauro signature.asc Description: PGP signature
Re: SYSFS errors
On Tue, Feb 19, 2013 at 10:50:48AM -0300, Mauro Carvalho Chehab wrote: It is actually worse, as if someone is using a C code to open the device with fp = open (/sys/devices/system/edac/mc/mc0/sdram_scrub_rate, O_RDWR); It will now start to fail if the device doesn't have both permissions. That's fine - you're supposed to handle open()'s retval properly anyway. See my other mail. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] irq/core changes for v3.9
Linus, Please pull the latest irq-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus HEAD: 36a5df85e9a3c218b73f6cf80098016ca3f0410d genirq: Export enable/disable_percpu_irq() The biggest changes are the IRQ-work and printk changes from Frederic Weisbecker, which prepare the code for 'full dynticks' (the ability to stop or slow down the periodic tick arbitrarily, not just in idle time as today): * Don't stop tick with irq works pending. This fix is generally useful and concerns archs that can't raise self IPIs. * Flush irq works before CPU offlining. * Introduce lazy irq works that can wait for the next tick to be executed, unless it's stopped. * Implement klogd wake up using irq work. This removes the ad-hoc printk_tick()/printk_needs_cpu() hooks and make it working even in dynticks mode. * Cleanups and fixes. Thanks, Ingo -- Chris Metcalf (1): genirq: Export enable/disable_percpu_irq() Frederic Weisbecker (7): irq_work: Fix racy IRQ_WORK_BUSY flag setting irq_work: Fix racy check on work pending flag irq_work: Remove CONFIG_HAVE_IRQ_WORK nohz: Add API to check tick state irq_work: Don't stop the tick with pending works irq_work: Make self-IPIs optable printk: Wake up klogd using irq_work James Hogan (1): arch Kconfig: Remove references to IRQ_PER_CPU Steven Rostedt (2): irq_work: Flush work on CPU_DYING irq_work: Warn if there's still work on cpu_down Thomas Gleixner (1): genirq: Avoid deadlock in spurious handling anish kumar (1): irq_work: Remove return value from the irq_work_queue() function arch/alpha/Kconfig | 1 - arch/arm/Kconfig| 1 - arch/arm64/Kconfig | 1 - arch/blackfin/Kconfig | 2 - arch/frv/Kconfig| 1 - arch/hexagon/Kconfig| 2 - arch/ia64/Kconfig | 1 - arch/mips/Kconfig | 2 - arch/parisc/Kconfig | 2 - arch/powerpc/Kconfig| 2 - arch/s390/Kconfig | 1 - arch/sh/Kconfig | 4 - arch/sparc/Kconfig | 1 - arch/x86/Kconfig| 1 - drivers/staging/iio/trigger/Kconfig | 1 - include/linux/irq_work.h| 22 +- include/linux/printk.h | 3 - include/linux/tick.h| 17 +++- init/Kconfig| 5 +- kernel/irq/manage.c | 2 + kernel/irq/spurious.c | 7 +- kernel/irq_work.c | 150 +--- kernel/printk.c | 36 + kernel/time/tick-sched.c| 7 +- kernel/timer.c | 1 - 25 files changed, 171 insertions(+), 102 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 9d5904c..9b504af 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -5,7 +5,6 @@ config ALPHA select HAVE_IDE select HAVE_OPROFILE select HAVE_SYSCALL_WRAPPERS - select HAVE_IRQ_WORK select HAVE_PCSPKR_PLATFORM select HAVE_PERF_EVENTS select HAVE_DMA_ATTRS diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 67874b8..9bbe760 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -36,7 +36,6 @@ config ARM select HAVE_GENERIC_HARDIRQS select HAVE_HW_BREAKPOINT if (PERF_EVENTS (CPU_V6 || CPU_V6K || CPU_V7)) select HAVE_IDE if PCI || ISA || PCMCIA - select HAVE_IRQ_WORK select HAVE_KERNEL_GZIP select HAVE_KERNEL_LZMA select HAVE_KERNEL_LZO diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index f8f362a..75e915b 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -21,7 +21,6 @@ config ARM64 select HAVE_GENERIC_DMA_COHERENT select HAVE_GENERIC_HARDIRQS select HAVE_HW_BREAKPOINT if PERF_EVENTS - select HAVE_IRQ_WORK select HAVE_MEMBLOCK select HAVE_PERF_EVENTS select IRQ_DOMAIN diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig index b6f3ad5..67e4aaa 100644 --- a/arch/blackfin/Kconfig +++ b/arch/blackfin/Kconfig @@ -24,7 +24,6 @@ config BLACKFIN select HAVE_FUNCTION_TRACER select HAVE_FUNCTION_TRACE_MCOUNT_TEST select HAVE_IDE - select HAVE_IRQ_WORK select HAVE_KERNEL_GZIP if RAMKERNEL select HAVE_KERNEL_BZIP2 if RAMKERNEL select HAVE_KERNEL_LZMA if RAMKERNEL @@ -38,7 +37,6 @@ config BLACKFIN select HAVE_GENERIC_HARDIRQS select GENERIC_ATOMIC64 select GENERIC_IRQ_PROBE - select IRQ_PER_CPU if SMP select USE_GENERIC_SMP_HELPERS if SMP select HAVE_NMI_WATCHDOG if NMI_WATCHDOG select GENERIC_SMP_IDLE_THREAD diff
Re: [PATCH v2 1/5] drivers: phy: add generic PHY framework
Hi,
On Tuesday 19 February 2013 06:26 PM, Arnd Bergmann wrote:
On Tuesday 19 February 2013, Kishon Vijay Abraham I wrote:
+static struct class *phy_class;
+static LIST_HEAD(phy_list);
+static DEFINE_MUTEX(phy_list_mutex);
+static LIST_HEAD(phy_bind_list);
Hmm, so you actually do have a 'class'. There is a GregKH mandated ban on
new classes, meaning that one should be converted to a bus_type instead.
Also, you really should not need the global phy_list, phy_list_mutex
and phy_bind_list variables, since the driver core already provides
you with ways to iterate through devices on a class or bus.
ok.
+/**
+ * of_phy_get - lookup and obtain a reference to a phy by phandle
+ * @dev: device that requests this phy
+ * @phandle: name of the property holding the phy phandle value
+ * @index - the index of the phy
+ *
+ * Returns the phy associated with the given phandle value,
+ * after getting a refcount to it or -ENODEV if there is no such phy or
+ * -EPROBE_DEFER if there is a phandle to the phy, but the device is
+ * not yet loaded.
+ */
+struct phy *of_phy_get(struct device *dev, const char *phandle, u8 index)
+{
+ struct phy *phy = NULL;
+ struct phy_bind *phy_map = NULL;
+ struct device_node *node;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, phandle, index);
+ if (!node) {
+ dev_dbg(dev, failed to get %s phandle in %s node\n, phandle,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
I wonder whether this one should be of_parse_phandle_with_args() instead,
so you can have client-specific configuration in the property. Basically
instead of
phy = usbphy0 usbphy1;
you can pass an arbitrary number of arguments along with this, as
determined by some property in the phy node:
usbphy0: phy@1 {
#phy-cells = 1;
};
ehci@2 {
phy = usbphy0 23;
};
Which in turn leads to the argument (23) being passed into a phy_bind().
I also wonder if you should allow arbitrary names for the property.
Can't this always be called 'phy'? If you allow named phys, it would
more more consistent with other bindings to have a list of phy handles
in a property called phy, and a second property called phy-names
that contains the named strings.
Ok. Makes sense. We should make both *phy* and *phy-cells* standard here.
+/**
+ * phy_create - create a new phy
+ * @dev: device that is creating the new phy
+ * @desc: descriptor of the phy
+ *
+ * Called to create a phy using phy framework.
+ */
+struct phy *phy_create(struct device *dev, struct phy_descriptor *desc)
+{
+ int ret;
+ struct phy *phy;
+ struct phy_bind *phy_bind;
+ const char *devname = NULL;
...
+
+ devname = dev_name(dev);
+ device_initialize(phy-dev);
+ phy-desc = desc;
+ phy-dev.class = phy_class;
+ phy-dev.parent = dev;
+ phy-dev.bus = desc-bus;
+ ret = dev_set_name(phy-dev, %s, devname);
Passing a bus_type through the descriptor seems misplaced. What is this for?
I thought if we are adding ethernet phys here (say drivers/phy/net), we
can make phy_device_create() (currently in drivers/net/phy/phy_device.c)
call phy_create with bus_type set to mdio_bus_type. Then we can have all
the PHYs showing up in /sys/class/phy/ and ethernet can continue to use
its own phy abstraction layer.
Why is this function not just:
struct phy *phy_create(struct device *dev, const char *label, int type,
struct phy_ops *ops);
since while calling the callback functions using ops, there wont be
anyway to get back the device specific structure pointer.
struct phy_dev {
.
.
struct phy_descriptor desc;
void __iomem*base;
.
.
};
static int phy_resume(struct phy_descriptor *desc)
{
//if we dont pass a member of phy_dev while *phy_create* we can't get
back phy_dev from callback functions as used below.
struct phy_dev *phy = desc_to_omapusb(desc);
return 0;
}
static struct phy_ops ops = {
.resume = phy_resume,
.owner = THIS_MODULE,
};
Passing a structure like you do here seems dangerous because when someone
decides to add members to the structure, existing code will not give a
build error but silently break.
Not sure I understood this point. Care to explain?
+/**
+ * struct phy_ops - set of function pointers for performing phy operations
+ * @init: operation to be performed for initializing phy
+ * @exit: operation to be performed while exiting
+ * @suspend: suspending the phy
+ * @resume: resuming the phy
+ * @poweron: powering on the phy
+ * @shutdown: shutting down the phy
+ * @owner: the module owner containing the ops
+ */
+struct phy_ops
Re: SYSFS errors
On 02/19/2013 02:50 PM, Borislav Petkov wrote:
On Tue, Feb 19, 2013 at 03:38:09PM +0200, Felipe Balbi wrote:
because changing the permission will cause the same issue:
Actually, I take that back. Mauro's patch will already create the file
anyway:
if (mci-set_sdram_scrub_rate || mci-get_sdram_scrub_rate)
Adjusting the permissions is simply the last missing piece to this patch
to make the interface to userspace 100% coherent.
--
From: Mauro Carvalho Chehab mche...@redhat.com
Date: Tue, 19 Feb 2013 09:16:10 -0300
Subject: [PATCH] EDAC: only create sdram_scrub_rate where supported
Currently, sdram_scrub_rate sysfs node is created even if the device
doesn't support get/set the scub rate. Change the logic to only
create this device node when the operation is supported.
If only read or only write is supported, it will keep returning -ENODEV
just like before.
Reported-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/edac/edac_mc_sysfs.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 0ca1ca71157f..5a788e60ff67 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -7,7 +7,7 @@
*
* Written Doug Thompson nor...@xmission.com www.softwarebitmaker.com
*
- * (c) 2012 - Mauro Carvalho Chehab mche...@redhat.com
+ * (c) 2012-2013 - Mauro Carvalho Chehab mche...@redhat.com
*The entire API were re-written, and ported to use struct device
*
*/
@@ -878,7 +878,6 @@ static struct attribute *mci_attrs[] = {
dev_attr_ce_noinfo_count.attr,
dev_attr_ue_count.attr,
dev_attr_ce_count.attr,
- dev_attr_sdram_scrub_rate.attr,
dev_attr_max_location.attr,
NULL
};
@@ -1012,6 +1011,23 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info
*mci)
return err;
}
+ if (mci-set_sdram_scrub_rate || mci-get_sdram_scrub_rate) {
+ umode_t mode = 0;
+
+ if (mci-get_sdram_scrub_rate)
+ mode = S_IRUGO;
+
+ if (mci-set_sdram_scrub_rate)
+ mode |= S_IWUSR;
+
+ dev_attr_sdram_scrub_rate.attr.mode = mode;
+
+ err = device_create_file(mci-dev, dev_attr_sdram_scrub_rate);
+ if (err) {
+ edac_dbg(1, failure: create sdram_scrub_rate\n);
+ goto fail2;
+ }
+ }
/*
* Create the dimm/rank devices
*/
@@ -1056,6 +1072,7 @@ fail:
continue;
device_unregister(dimm-dev);
}
+fail2:
device_unregister(mci-dev);
bus_unregister(mci-bus);
kfree(mci-bus.name);
And of course you all know that creating sysfs attributes via
'device_create_file' opens all sort of funny race conditions,
especially when checking these attributes from udev ...
Please consider adding a default attribute which return '-EINVAL' or
somesuch when the function pointers are not set.
But _not_ adding it via device_create_file(). That's evil.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] xen: introduce xen_remap, use it instead of ioremap
ioremap can't be used to map ring pages on ARM because it uses device
memory caching attributes (MT_DEVICE*).
Introduce a Xen specific abstraction to map ring pages, called
xen_remap, that is defined as ioremap on x86 (no behavioral changes).
On ARM it explicitly calls __arm_ioremap with the right caching
attributes: MT_MEMORY.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index c6b9096..30cdacb 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1,6 +1,7 @@
#ifndef _ASM_ARM_XEN_PAGE_H
#define _ASM_ARM_XEN_PAGE_H
+#include asm/mach/map.h
#include asm/page.h
#include asm/pgtable.h
@@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn,
unsigned long mfn)
{
return __set_phys_to_machine(pfn, mfn);
}
+
+#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
+
#endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6aef9fb 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
void make_lowmem_page_readonly(void *vaddr);
void make_lowmem_page_readwrite(void *vaddr);
+#define xen_remap(cookie, size) ioremap((cookie), (size));
+
#endif /* _ASM_X86_XEN_PAGE_H */
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 19843ec..682210d7 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
if (r 0 || v == 0)
goto err;
mfn = v;
- info-intf = ioremap(mfn PAGE_SHIFT, PAGE_SIZE);
+ info-intf = xen_remap(mfn PAGE_SHIFT, PAGE_SIZE);
if (info-intf == NULL)
goto err;
info-vtermno = HVC_COOKIE;
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7038de5..1c2a1e5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1146,7 +1146,7 @@ int gnttab_resume(void)
return gnttab_map(0, nr_grant_frames - 1);
if (gnttab_shared.addr == NULL) {
- gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
+ gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
PAGE_SIZE * max_nr_gframes);
if (gnttab_shared.addr == NULL) {
printk(KERN_WARNING
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index 038b71d..3325884 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -769,7 +769,7 @@ static int __init xenbus_init(void)
goto out_error;
xen_store_mfn = (unsigned long)v;
xen_store_interface =
- ioremap(xen_store_mfn PAGE_SHIFT, PAGE_SIZE);
+ xen_remap(xen_store_mfn PAGE_SHIFT, PAGE_SIZE);
break;
default:
pr_warn(Xenstore state unknown\n);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Timer broadcast question
Hi John, Frederic, I am working on identifying the different wakeup sources from the interrupts and I have a question regarding the timer broadcast. The broadcast timer is setup to the next event and that will wake up any cpu, right ? The time framework will look at the different cpus next-event and send them an IPI to wake them up. Although, it is possible the sender of this IPI may not be concerned by the timer expiration and has been woken up just for sending the IPI, right ? If this is correct, is it possible to setup the timer irq affinity to a cpu which will be concerned by the timer expiration ? so we prevent an unnecessary wake up for a cpu. Did I missed something or does it sound correct ? Thanks -- Daniel -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SYSFS errors
On Tue, Feb 19, 2013 at 02:58:07PM +0100, Hannes Reinecke wrote: Please consider adding a default attribute which return '-EINVAL' or somesuch when the function pointers are not set. But _not_ adding it via device_create_file(). That's evil. This is what we do now. We probably could add the permissions fiddling out in the the code but remain using DEVICE_ATTR. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] perf changes for v3.9
Linus,
Please pull the latest perf-core-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-for-linus
HEAD: e259514eef764a5286873618e34c560ecb6cff13 perf/x86/amd: Enable
northbridge performance counters on AMD family 15h
There are lots of improvements, the biggest changes are:
Main kernel side changes:
* Improve uprobes performance by adding 'pre-filtering'
support, by Oleg Nesterov.
* Make some POWER7 events available in sysfs, equivalent to
what was done on x86, from Sukadev Bhattiprolu.
* tracing updates by Steve Rostedt - mostly misc fixes and
smaller improvements.
* Use perf/event tracing to report PCI Express advanced
errors, by Tony Luck.
* Enable northbridge performance counters on AMD family 15h,
by Jacob Shin.
* This tracing commit:
tracing: Remove the extra 4 bytes of padding in events
changes the ABI. All involved parties (PowerTop in
particular) seem to agree that it's safe to do now with the
introduction of libtraceevent, but the devil is in the
details ...
Main tooling side changes:
* Add 'event group view', from Namyung Kim:
To use it, 'perf record' should group events when
recording. And then perf report parses the saved group
relation from file header and prints them
together if --group option is provided. You can use the
'perf evlist' command to see event group information:
$ perf record -e '{ref-cycles,cycles}' noploop 1
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.385 MB perf.data (~16807 samples) ]
$ perf evlist --group
{ref-cycles,cycles}
With this example, default perf report will show you each
event separately.
You can use --group option to enable event group view:
$ perf report --group
...
# group: {ref-cycles,cycles}
#
# Samples: 7K of event 'anon group { ref-cycles, cycles }'
# Event count (approx.): 6876107743
#
# Overhead Command Shared Object
Symbol
# ... .
..
99.84% 99.76% noploop noploop[.] main
0.07% 0.00% noploop ld-2.15.so [.] strcmp
0.03% 0.00% noploop [kernel.kallsyms] [k] timerqueue_del
0.03% 0.03% noploop [kernel.kallsyms] [k] sched_clock_cpu
0.02% 0.00% noploop [kernel.kallsyms] [k] account_user_time
0.01% 0.00% noploop [kernel.kallsyms] [k]
__alloc_pages_nodemask
0.00% 0.00% noploop [kernel.kallsyms] [k]
native_write_msr_safe
0.00% 0.11% noploop [kernel.kallsyms] [k] _raw_spin_lock
0.00% 0.06% noploop [kernel.kallsyms] [k] find_get_page
0.00% 0.02% noploop [kernel.kallsyms] [k] rcu_check_callbacks
0.00% 0.02% noploop [kernel.kallsyms] [k]
__current_kernel_time
As you can see the Overhead column now contains both of
ref-cycles and cycles and header line shows group
information also - 'anon group { ref-cycles, cycles }'.
The output is sorted by period of group leader first.
* Initial GTK+ annotate browser, from Namhyung Kim.
* Add option for runtime switching perf data file in perf
report, just press 's' and a menu with the valid files found
in the current directory will be presented, from Feng Tang.
* Add support to display whole group data for raw columns,
from Jiri Olsa.
* Add per processor socket count aggregation in perf stat,
from Stephane Eranian.
* Add interval printing in 'perf stat', from Stephane Eranian.
* 'perf test' improvements
* Add support for wildcards in tracepoint system name, from
Jiri Olsa.
* Add anonymous huge page recognition, from Joshua Zhu.
* perf build-id cache now can show DSOs present in a perf.data
file that are not in the cache, to integrate with build-id
servers being put in place by organizations such as Fedora.
* perf top now shares more of the evsel config/creation
routines with 'record', paving the way for further
integration like 'top' snapshots, etc.
* perf top now supports DWARF callchains.
* Fix mmap limitations on 32-bit, fix from David Miller.
* 'perf bench numa mem' NUMA performance measurement suite
* ... and lots of fixes, performance improvements, cleanups
and other improvements I failed to list - see the shortlog
and git log for details.
Thanks,
Ingo
--
Al Cooper (1):
perf tools: Fix GNU make v3.80 compatibility issue
Arnaldo Carvalho de Melo (56):
perf top: Add missing newline on pr_err call
perf tools: Don't check configuration on make tags
perf tools: Fix TUI helpline output
Re: SYSFS errors
Em Tue, 19 Feb 2013 14:58:07 +0100
Hannes Reinecke h...@suse.de escreveu:
On 02/19/2013 02:50 PM, Borislav Petkov wrote:
On Tue, Feb 19, 2013 at 03:38:09PM +0200, Felipe Balbi wrote:
because changing the permission will cause the same issue:
Actually, I take that back. Mauro's patch will already create the file
anyway:
if (mci-set_sdram_scrub_rate || mci-get_sdram_scrub_rate)
Adjusting the permissions is simply the last missing piece to this patch
to make the interface to userspace 100% coherent.
--
From: Mauro Carvalho Chehab mche...@redhat.com
Date: Tue, 19 Feb 2013 09:16:10 -0300
Subject: [PATCH] EDAC: only create sdram_scrub_rate where supported
Currently, sdram_scrub_rate sysfs node is created even if the device
doesn't support get/set the scub rate. Change the logic to only
create this device node when the operation is supported.
If only read or only write is supported, it will keep returning -ENODEV
just like before.
Reported-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/edac/edac_mc_sysfs.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 0ca1ca71157f..5a788e60ff67 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -7,7 +7,7 @@
*
* Written Doug Thompson nor...@xmission.com www.softwarebitmaker.com
*
- * (c) 2012 - Mauro Carvalho Chehab mche...@redhat.com
+ * (c) 2012-2013 - Mauro Carvalho Chehab mche...@redhat.com
*The entire API were re-written, and ported to use struct device
*
*/
@@ -878,7 +878,6 @@ static struct attribute *mci_attrs[] = {
dev_attr_ce_noinfo_count.attr,
dev_attr_ue_count.attr,
dev_attr_ce_count.attr,
- dev_attr_sdram_scrub_rate.attr,
dev_attr_max_location.attr,
NULL
};
@@ -1012,6 +1011,23 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info
*mci)
return err;
}
+ if (mci-set_sdram_scrub_rate || mci-get_sdram_scrub_rate) {
+ umode_t mode = 0;
+
+ if (mci-get_sdram_scrub_rate)
+ mode = S_IRUGO;
+
+ if (mci-set_sdram_scrub_rate)
+ mode |= S_IWUSR;
+
+ dev_attr_sdram_scrub_rate.attr.mode = mode;
+
+ err = device_create_file(mci-dev, dev_attr_sdram_scrub_rate);
+ if (err) {
+ edac_dbg(1, failure: create sdram_scrub_rate\n);
+ goto fail2;
+ }
+ }
/*
* Create the dimm/rank devices
*/
@@ -1056,6 +1072,7 @@ fail:
continue;
device_unregister(dimm-dev);
}
+fail2:
device_unregister(mci-dev);
bus_unregister(mci-bus);
kfree(mci-bus.name);
And of course you all know that creating sysfs attributes via
'device_create_file' opens all sort of funny race conditions,
especially when checking these attributes from udev ...
Yes, we know that, but this subsystem has already lots of other
attributes created via device_create_file(). It used to be a
lot worse than that, as, on a very recent past (before Kernel 3.5),
those attributes were created via sysfs_create_file().
There's not much that can be done to avoid it on this subsystem.
Please consider adding a default attribute which return '-EINVAL' or
somesuch when the function pointers are not set.
But _not_ adding it via device_create_file(). That's evil.
This thread started with Felipe's complain about it returning -ENOSYS ;)
when this feature is not supported.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] perf fix for v3.9
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
HEAD: e97cbe3edf7d88aad4c21dd3de124d9f9d039881 perf/hwbp: Fix cleanup in
case of kzalloc() failure
Leftover fix from the v3.8 cycle.
Thanks,
Ingo
--
Daniel Baluta (1):
perf/hwbp: Fix cleanup in case of kzalloc() failure
kernel/events/hw_breakpoint.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index fe8a916..a64f8ae 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -676,7 +676,7 @@ int __init init_hw_breakpoint(void)
err_alloc:
for_each_possible_cpu(err_cpu) {
for (i = 0; i TYPE_MAX; i++)
- kfree(per_cpu(nr_task_bp_pinned[i], cpu));
+ kfree(per_cpu(nr_task_bp_pinned[i], err_cpu));
if (err_cpu == cpu)
break;
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] block: IBM RamSan 70/80 driver fixes.
On 02/18/2013 02:00 PM, Philip J. Kelleher wrote:
diff -uprN -X linux-block-vanilla/Documentation/dontdiff
linux-block-vanilla/drivers/block/rsxx/config.c
linux-block/drivers/block/rsxx/config.c
--- linux-block-vanilla/drivers/block/rsxx/config.c 2013-02-12
11:25:37.756352070 -0600
+++ linux-block/drivers/block/rsxx/config.c 2013-02-15 09:01:43.221166194
-0600
@@ -31,7 +31,7 @@
static void initialize_config(void *config)
{
- struct rsxx_card_cfg *cfg = (struct rsxx_card_cfg *) config;
+ struct rsxx_card_cfg *cfg = config;
Why not pass a struct rsxx_card_cfg * here instead of a void*?
@@ -126,7 +126,11 @@ static void creg_issue_cmd(struct rsxx_c
cmd-buf, cmd-stream);
}
- /* Data copy must complete before initiating the command. */
+ /*
+ * Data copy must complete before initiating the command. This is
+ * needed for weakly ordered processors (i.e. PowerPC), so that all
+ * neccessary registers are written before we kick the hardware.
+ */
wmb();
When you say data copy are you referring to the writes to the host DMA
buffer that occurred previously? If so, the iowrite / writel macros
already ensure this, as they have a sync instruction built in to them
to cover this case, so a wmb would be redundant.
If its to ensure that all the iowrite's make it to the device as one
transaction and don't get interleaved with some other iowrite's, as
long as you have a spinlock protecting these writes, the PowerPC
spin_unlock will guarantee an mmiowb, so this shouldn't be an issue
either.
diff -uprN -X linux-block-vanilla/Documentation/dontdiff
linux-block-vanilla/drivers/block/rsxx/rsxx.h
linux-block/drivers/block/rsxx/rsxx.h
--- linux-block-vanilla/drivers/block/rsxx/rsxx.h 2013-02-12
11:25:37.780170779 -0600
+++ linux-block/drivers/block/rsxx/rsxx.h 2013-02-18 08:54:59.692973434
-0600
@@ -35,6 +35,8 @@ struct rsxx_reg_access {
__u32 data[8];
};
+#define RSXX_MAX_REG_CNT (8 * (sizeof(__u32)))
Is this 8 related to the 8 in the array above? If so, why not have a literal
to define the 8 and use it in both places to make this clear?
-Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SYSFS errors
Hi, On Tue, Feb 19, 2013 at 11:14:40AM -0300, Mauro Carvalho Chehab wrote: Please consider adding a default attribute which return '-EINVAL' or somesuch when the function pointers are not set. But _not_ adding it via device_create_file(). That's evil. This thread started with Felipe's complain about it returning -ENOSYS ;) when this feature is not supported. I was complaining about a file with read permission not being really readable which is a fair bug IMHO. -- balbi signature.asc Description: Digital signature
[PATCH RFC] pwm: add sysfs interface
From: Lars Poeschel poesc...@lemonage.de This adds a simple sysfs interface to the pwm subsystem. It is heavily inspired by the gpio sysfs interface. /sys/class/pwm /export ... asks the kernel to export a PWM to userspace /unexport ... to return a PWM to the kernel /pwmN ... for each exported PWM #N /duty_ns ... r/w, length of duty portion /period_ns ... r/w, length of the pwm period /polarity ... r/w, normal(0) or inverse(1) polarity only created if driver supports it /run ... r/w, write 1 to start and 0 to stop the pwm /pwmchipN ... for each pwmchip; #N is its first PWM /base ... (r/o) same as N /ngpio ... (r/o) number of PWM; numbered N .. MAX_PWMS Signed-off-by: Lars Poeschel poesc...@lemonage.de --- Documentation/pwm.txt | 46 + drivers/pwm/Kconfig | 15 ++ drivers/pwm/core.c| 526 - include/linux/pwm.h | 27 ++- 4 files changed, 608 insertions(+), 6 deletions(-) diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt index 7d2b4c9..b349d16 100644 --- a/Documentation/pwm.txt +++ b/Documentation/pwm.txt @@ -45,6 +45,52 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns); To start/stop toggling the PWM output use pwm_enable()/pwm_disable(). +Using PWMs with the sysfs interface +--- + +You have to enable CONFIG_PWM_SYSFS in your kernel configuration to use +the sysfs interface. It is exposed at /sys/class/pwm/. If there are pwm +drivers loaded and these drivers successfully probed a chip, this chip +is exported as pwmchipX . Note that a single driver can probe multiple chips. +Inside the directory you can read these properties: + +base - This is the linux global start where the chips pwm channels get +exposed. + +npwm - This is the number of pwm channels this chip supports. + +If you want to start using a pwm channel with sysfs first you have to +export it. If you are finished with it and want to free the pwm for other +uses, you can unexport it: + +export - Write the global pwm channel number to this file to start using +the channel with sysfs. + +unexport - Write the global pwm channel number of the channel you are finshed +with to this file to make the channel available for other uses. + +Once a pwm is exported a pwmX (X ranging from 0 to MAX_PWMS) directory appears +with the following read/write properties inside to control the pwm: + +duty_ns - Write the number of nanoseconds the active portion of the pwm period +should last to this file. This can not be longer than the period_ns. + +period_ns - Write the length of the pwm period in nanoseconds to this file. +This includes the active and inactive portion of the pwm period and can not +be smaller than duty_ns. + +polarity - The normal behaviour is to put out a high for the active portion of +the pwm period. Write a 1 to this file to inverse the signal and output a low +on the active portion. Write a 0 to switch back to the normal behaviour. The +polarity can only be changed if the pwm is not running. This file is only +visible if the underlying driver/device supports changing the polarity. + +run - Write a 1 to this file to start the pwm signal generation, write a 0 to +stop it. Set your desired period_ns, duty_ns and polarity before starting the +pwm. + +It is recommend to set the period_ns at first and duty_ns after that. + Implementing a PWM driver - diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig index e513cd9..1c3432e 100644 --- a/drivers/pwm/Kconfig +++ b/drivers/pwm/Kconfig @@ -28,6 +28,21 @@ menuconfig PWM if PWM +config PWM_SYSFS + bool /sys/class/pwm/... (sysfs interface) + depends on SYSFS + help + Say Y here to add a sysfs interface for PWMs. + + This exports directories and files to userspace using sysfs. + This way the PWM outputs of a device can easyly be used, + controlled and tested. For every instance of an PWM capable + device there is a pwmchipX directory exported to + /sys/class/pwm. If you want to use a PWM, you have to export + it to sysfs, which is done by writing the number into + /sys/class/pwm/export. After that /sys/class/pwm/pwmX is + reaady to be used. + config PWM_AB8500 tristate AB8500 PWM support depends on AB8500_CORE ARCH_U8500 diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c index 903138b..f7a6bf1 100644 --- a/drivers/pwm/core.c +++ b/drivers/pwm/core.c @@ -30,8 +30,6 @@ #include linux/debugfs.h #include linux/seq_file.h -#define MAX_PWMS 1024 - /* flags in the third cell of the DT PWM specifier */ #define PWM_SPEC_POLARITY (1 0) @@ -42,6 +40,497 @@ static LIST_HEAD(pwm_chips); static DECLARE_BITMAP(allocated_pwms, MAX_PWMS); static RADIX_TREE(pwm_tree,
Re: WARNING: at kernel/mutex.c:386 __mutex_lock_common()
Hey,
2013/2/18 Fengguang Wu fengguang...@intel.com:
Greetings,
I got the below warning and the first bad commit is
commit 11eb5a2ce9655ee552f705f2da6b8f96f466c0d4
Author: Maarten Lankhorst maarten.lankho...@canonical.com
Date: Wed Nov 7 11:53:51 2012 +0100
mutex: add support for reservation style locks
GPU's do operations that commonly involve many buffers. Those buffers
can be shared across contexts/processes, exist in different memory
domains (for example VRAM vs system memory), and so on. And with
PRIME / dmabuf, they can even be shared across devices. So there are
a handful of situations where the driver needs to wait for buffers to
become ready. If you think about this in terms of waiting on a buffer
mutex for it to become available, this presents a problem because
there is no way to guarantee that buffers appear in a execbuf/batch in
the same order in all contexts. That is directly under control of
userspace, and a result of the sequence of GL calls that an application
makes. Which results in the potential for deadlock. The problem gets
more complex when you consider that the kernel may need to migrate the
buffer(s) into VRAM before the GPU operates on the buffer(s), which
may in turn require evicting some other buffers (and you don't want to
evict other buffers which are already queued up to the GPU), but for a
simplified understanding of the problem you can ignore this.
The algorithm that TTM came up with for dealing with this problem is
quite simple. For each group of buffers (execbuf) that need to be
locked, the caller would be assigned a unique reservation_id, from a
global counter. In case of deadlock in the process of locking all the
buffers associated with a execbuf, the one with the lowest
reservation_id wins, and the one with the higher reservation_id
unlocks all of the buffers that it has already locked, and then tries
again.
How it is used:
---
A very simplified version:
int lock_execbuf(execbuf)
{
struct buf *res_buf = NULL;
/* acquiring locks, before queuing up to GPU: */
seqno = assign_global_seqno();
retry:
for (buf in execbuf-buffers) {
if (buf == res_buf) {
res_buf = NULL;
continue;
}
ret = mutex_reserve_lock(buf-lock, seqno);
if (ret 0)
goto err;
}
/* now everything is good to go, submit job to GPU: */
...
return 0;
err:
for (all buf2 before buf in execbuf-buffers)
mutex_unreserve_unlock(buf2-lock);
if (res_buf)
mutex_unreserve_unlock(res_buf-lock);
if (ret == -EAGAIN) {
/* we lost out in a seqno race, lock and retry.. */
mutex_reserve_lock_slow(buf-lock, seqno);
res_buf = buf;
goto retry;
}
return ret;
}
int unlock_execbuf(execbuf)
{
/* when GPU is finished; */
for (buf in execbuf-buffers)
mutex_unreserve_unlock(buf-lock);
}
Functions:
--
mutex_reserve_lock, and mutex_reserve_lock_interruptible:
Lock a buffer with a reservation_id set. reservation_id must not be
set to 0, since this is a special value that means no reservation_id.
Normally if reservation_id is not set, or is older than the
reservation_id that's currently set on the mutex, the behavior will
be to wait normally. However, if the reservation_id is newer than
the current reservation_id, -EAGAIN will be returned.
These functions will return -EDEADLK instead of -EAGAIN if
reservation_id is the same as the reservation_id that's attempted to
lock the mutex with, since in that case you presumably attempted to
lock the same lock twice.
mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow:
Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN.
This is useful when mutex_reserve_lock failed with -EAGAIN, and you
unreserved all buffers so no deadlock can occur.
mutex_unreserve_unlock:
Unlock a buffer reserved with one of the mutex_reserve_*lock* calls.
Missing at the moment, maybe TODO?
* Check if lockdep warns if you unlock a lock that other locks were
nested
to.
- spin_lock(m);
spin_lock_nest_lock(a, m);
spin_unlock(m);
spin_unlock(a);
It would be nice if this would give a splat on spin_unlock(m),
I'm not 100% sure if it does right now, though..
* In the *_slow calls, maybe add a check to
[GIT PULL] smp/hotplug changes for v3.9
Linus,
Please pull the latest smp-hotplug-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
smp-hotplug-for-linus
HEAD: 14e568e78f6f80ca1e27256641ddf524c7dbdc51 stop_machine: Use smpboot
threads
Some early preparatory changes for the WIP hotplug rework by
Thomas Gleixner.
Thanks,
Ingo
--
Thomas Gleixner (3):
smpboot: Allow selfparking per cpu threads
stop_machine: Store task reference in a separate per cpu variable
stop_machine: Use smpboot threads
include/linux/smpboot.h | 5 ++
kernel/cpu.c| 2 +
kernel/smpboot.c| 5 +-
kernel/stop_machine.c | 156 +++-
4 files changed, 70 insertions(+), 98 deletions(-)
diff --git a/include/linux/smpboot.h b/include/linux/smpboot.h
index e0106d8..c65dee0 100644
--- a/include/linux/smpboot.h
+++ b/include/linux/smpboot.h
@@ -14,6 +14,8 @@ struct smpboot_thread_data;
* @thread_should_run: Check whether the thread should run or not. Called with
* preemption disabled.
* @thread_fn: The associated thread function
+ * @create:Optional setup function, called when the thread gets
+ * created (Not called from the thread context)
* @setup: Optional setup function, called when the thread gets
* operational the first time
* @cleanup: Optional cleanup function, called when the thread
@@ -22,6 +24,7 @@ struct smpboot_thread_data;
* parked (cpu offline)
* @unpark:Optional unpark function, called when the thread is
* unparked (cpu online)
+ * @selfparking: Thread is not parked by the park function.
* @thread_comm: The base name of the thread
*/
struct smp_hotplug_thread {
@@ -29,10 +32,12 @@ struct smp_hotplug_thread {
struct list_headlist;
int (*thread_should_run)(unsigned int cpu);
void(*thread_fn)(unsigned int cpu);
+ void(*create)(unsigned int cpu);
void(*setup)(unsigned int cpu);
void(*cleanup)(unsigned int cpu, bool
online);
void(*park)(unsigned int cpu);
void(*unpark)(unsigned int cpu);
+ boolselfparking;
const char *thread_comm;
};
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 3046a50..c91e30d 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -254,6 +254,8 @@ static int __ref take_cpu_down(void *_param)
return err;
cpu_notify(CPU_DYING | param-mod, param-hcpu);
+ /* Park the stopper thread */
+ kthread_park(current);
return 0;
}
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index d6c5fc0..d4abac2 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -183,9 +183,10 @@ __smpboot_create_thread(struct smp_hotplug_thread *ht,
unsigned int cpu)
kfree(td);
return PTR_ERR(tsk);
}
-
get_task_struct(tsk);
*per_cpu_ptr(ht-store, cpu) = tsk;
+ if (ht-create)
+ ht-create(cpu);
return 0;
}
@@ -225,7 +226,7 @@ static void smpboot_park_thread(struct smp_hotplug_thread
*ht, unsigned int cpu)
{
struct task_struct *tsk = *per_cpu_ptr(ht-store, cpu);
- if (tsk)
+ if (tsk !ht-selfparking)
kthread_park(tsk);
}
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 2f194e9..95d178c 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -18,7 +18,7 @@
#include linux/stop_machine.h
#include linux/interrupt.h
#include linux/kallsyms.h
-
+#include linux/smpboot.h
#include linux/atomic.h
/*
@@ -37,10 +37,10 @@ struct cpu_stopper {
spinlock_t lock;
boolenabled;/* is this stopper enabled? */
struct list_headworks; /* list of pending works */
- struct task_struct *thread;/* stopper thread */
};
static DEFINE_PER_CPU(struct cpu_stopper, cpu_stopper);
+static DEFINE_PER_CPU(struct task_struct *, cpu_stopper_task);
static bool stop_machine_initialized = false;
static void cpu_stop_init_done(struct cpu_stop_done *done, unsigned int
nr_todo)
@@ -62,16 +62,18 @@ static void cpu_stop_signal_done(struct cpu_stop_done
*done, bool executed)
}
/* queue @work to @stopper. if offline, @work is completed immediately */
-static void cpu_stop_queue_work(struct cpu_stopper *stopper,
- struct cpu_stop_work *work)
+static void cpu_stop_queue_work(unsigned int cpu, struct cpu_stop_work *work)
{
+ struct cpu_stopper *stopper = per_cpu(cpu_stopper, cpu);
+ struct task_struct *p =
Re: [PATCH 5/5] coredump: ignore non-fatal signals when core dumping to a pipe
On 02/18, Mandeep Singh Baines wrote:
On Sat, Feb 16, 2013 at 11:46 AM, Oleg Nesterov o...@redhat.com wrote:
--- x/fs/coredump.c
+++ x/fs/coredump.c
@@ -416,17 +416,17 @@ static void wait_for_dump_helpers(struct
pipe_lock(pipe);
pipe-readers++;
pipe-writers--;
+ // TODO: wake_up_interruptible_sync_poll ?
+ wake_up_interruptible_sync(pipe-wait);
+ kill_fasync(pipe-fasync_readers, SIGIO, POLL_IN);
+ pipe_unlock(pipe);
- while ((pipe-readers 1) (!signal_pending(current))) {
- wake_up_interruptible_sync(pipe-wait);
- kill_fasync(pipe-fasync_readers, SIGIO, POLL_IN);
- pipe_wait(pipe);
- }
+ wait_event_freezekillable(pipe-wait, pipe-readers == 1);
I tried to check (but didn't even try to test). I think this should
work. Assuming that we teach SIGKILL to actually kill the dumper, but
we need this in any case.
But. Then we need to change pipe_release() to use wake_up_sync_poll()
(which we do not have). Probably we can do this... but otoh if we protect
the dumping thread from the non-fatal signals (and again, we need this
anyway ;) then we can simply do wait_event_freezable().
I like this patch.
Could we ignore/drop signals when SIGNAL_GROUP_EXIT but allow SIGKILL.
For SIGKILL, wake_up everybody (signal_complete sort of already does this).
Please look at 1-3 I sent. Btw, I slightly tested this series, seems
to work...
You'd need to prevent the fake signal from freeezer from setting
TIF_SIGPENDING. Maybe just add a SIGNAL_GROUP_EXIT check in freezer.c.
I am thinking about checking SIGNAL_GROUP_COREDUMP but I am not sure,
perhaps we can make a simpler solution. As for wait_for_dump_helper()
we do not need any check at all, but we should either fix
wait_event_freezable (it is actually not right) or change pipe_release()
to use TASK_NORMAL instead of TASK_INTERRUPTIBLE.
Mandeep, Andrew, I am really sorry.
I tried to do these changes many times, but _every_ time I had some
urgent and unexpected work. This time too. I'll try very much to return
on Friday.
Oleg.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] drivers: phy: add generic PHY framework
On Tuesday 19 February 2013, kishon wrote:
+
+ devname = dev_name(dev);
+ device_initialize(phy-dev);
+ phy-desc = desc;
+ phy-dev.class = phy_class;
+ phy-dev.parent = dev;
+ phy-dev.bus = desc-bus;
+ ret = dev_set_name(phy-dev, %s, devname);
Passing a bus_type through the descriptor seems misplaced. What is this for?
I thought if we are adding ethernet phys here (say drivers/phy/net), we
can make phy_device_create() (currently in drivers/net/phy/phy_device.c)
call phy_create with bus_type set to mdio_bus_type. Then we can have all
the PHYs showing up in /sys/class/phy/ and ethernet can continue to use
its own phy abstraction layer.
Hmm, that relies on the fact that mdio uses a 'bus_type' while the new phy
support uses a 'class', and it will break if we ever get to the point
where those two concepts are merged. I would rather not plan ahead here.
Why is this function not just:
struct phy *phy_create(struct device *dev, const char *label, int type,
struct phy_ops *ops);
since while calling the callback functions using ops, there wont be
anyway to get back the device specific structure pointer.
struct phy_dev {
.
.
struct phy_descriptor desc;
void __iomem*base;
.
.
};
static int phy_resume(struct phy_descriptor *desc)
{
//if we dont pass a member of phy_dev while *phy_create* we can't get
back phy_dev from callback functions as used below.
struct phy_dev *phy = desc_to_omapusb(desc);
return 0;
}
static struct phy_ops ops = {
.resume = phy_resume,
.owner = THIS_MODULE,
};
In other subsystems, that is what the device-private_data pointer is used
for, which you could also pass to phy_create, or set after calling that
function.
Passing a structure like you do here seems dangerous because when someone
decides to add members to the structure, existing code will not give a
build error but silently break.
Not sure I understood this point. Care to explain?
Nevermind, when I wrote that sentence, I had not yet noticed that the
phy_descriptor is kept around. I was thinking that the structure was
only used to pass more arguments into phy_create.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 0/5] Generic PHY Framework
On Tuesday 19 February 2013, Felipe Balbi wrote: On Tue, Feb 19, 2013 at 12:33:54PM +, Arnd Bergmann wrote: Currently drivers/phy and drivers/net/phy are independent and are not related to each other. There are some fundamental differences on how these frameworks work. IIUC, the *net* uses bus layer (MDIO bus) to match a PHY device with a PHY driver and the Ethernet device uses the bus layer to get the PHY. The Generic PHY Framework however doesn't have any bus layer. The PHY should be like any other Platform Devices and Drivers and the framework will provide some APIs to register with the framework. And there are other APIs which any controller can use to get the PHY (for e.g., in the case of dt boot, it can use phandle to get a reference to the PHY). Hmm, I think the use of a bus_type for a PHY actually sounds quite appropriate. The actual PHY device would then be a child of the really ? I'm not so sure, the *bus* used by the PHY is ULPI, UTMI, UTMI+, PIP3, I2C, etc... adding another 'fake' bus representation is a bit overkill IMO. Imagine an I2C-controlled PHY driver like isp1301, that driver will have to register i2c_driver and phy_driver, which looks weird to me. If the only substitute for class is a bus, we can't drop classes just yet, I'm afraid. Imagine a regulator bus, a pwm bus, an LED bus etc. They don't make sense IMHO. It's a fine line, but I think a phy is something that resembles a device more than an LED does. When I read patch 1, I also noticed and commented on the fact that it does use a 'class'. Now, according to Greg, we should use 'bus_type' instead of 'class' in new code. I originally disagreed with that concept, but he's the boss here and it's good if he has a vision how things should be lined out. In practice, there is little difference between a 'bus_type' and a 'class', so just replace any instance of the former with the latter in your head when reading the code ;-) I understand that there is not a real common bus here, and the bus_type infrastructure would basically be used as a way to represent each PHY in sysfs and provide a way to enumerate and look them up inside of the kernel. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: SYSFS errors
Em Tue, 19 Feb 2013 14:50:56 +0100
Borislav Petkov b...@alien8.de escreveu:
On Tue, Feb 19, 2013 at 03:38:09PM +0200, Felipe Balbi wrote:
because changing the permission will cause the same issue:
Actually, I take that back. Mauro's patch will already create the file
anyway:
if (mci-set_sdram_scrub_rate || mci-get_sdram_scrub_rate)
Adjusting the permissions is simply the last missing piece to this patch
to make the interface to userspace 100% coherent.
That's covers everything but Hannes arguments. I don't think that
adding just one more device_create_file() on a driver that creates
dozens (or hundreds) of sys nodes, depending on the number of DIMMS
on the system would make it any worse.
Regards,
Mauro
[PATCH EDAC] edac: only create sdram_scrub_rate where supported
Currently, sdram_scrub_rate sysfs node is created even if the device
doesn't support get/set the scub rate. Change the logic to only
create this device node when the operation is supported.
Reported-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 9c58da6..4f4b613 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -7,7 +7,7 @@
*
* Written Doug Thompson nor...@xmission.com www.softwarebitmaker.com
*
- * (c) 2012 - Mauro Carvalho Chehab mche...@redhat.com
+ * (c) 2012-2013 - Mauro Carvalho Chehab mche...@redhat.com
* The entire API were re-written, and ported to use struct device
*
*/
@@ -681,9 +681,6 @@ static ssize_t mci_sdram_scrub_rate_store(struct device
*dev,
unsigned long bandwidth = 0;
int new_bw = 0;
- if (!mci-set_sdram_scrub_rate)
- return -ENODEV;
-
if (strict_strtoul(data, 10, bandwidth) 0)
return -EINVAL;
@@ -707,9 +704,6 @@ static ssize_t mci_sdram_scrub_rate_show(struct device *dev,
struct mem_ctl_info *mci = to_mci(dev);
int bandwidth = 0;
- if (!mci-get_sdram_scrub_rate)
- return -ENODEV;
-
bandwidth = mci-get_sdram_scrub_rate(mci);
if (bandwidth 0) {
edac_printk(KERN_DEBUG, EDAC_MC, Error reading scrub rate\n);
@@ -870,8 +864,7 @@ DEVICE_ATTR(ce_count, S_IRUGO, mci_ce_count_show, NULL);
DEVICE_ATTR(max_location, S_IRUGO, mci_max_location_show, NULL);
/* memory scrubber attribute file */
-DEVICE_ATTR(sdram_scrub_rate, S_IRUGO | S_IWUSR, mci_sdram_scrub_rate_show,
- mci_sdram_scrub_rate_store);
+DEVICE_ATTR(sdram_scrub_rate, 0, NULL, NULL);
static struct attribute *mci_attrs[] = {
dev_attr_reset_counters.attr,
@@ -882,7 +875,6 @@ static struct attribute *mci_attrs[] = {
dev_attr_ce_noinfo_count.attr,
dev_attr_ue_count.attr,
dev_attr_ce_count.attr,
- dev_attr_sdram_scrub_rate.attr,
dev_attr_max_location.attr,
NULL
};
@@ -1017,6 +1009,22 @@ int edac_create_sysfs_mci_device(struct mem_ctl_info
*mci)
return err;
}
+ if (mci-set_sdram_scrub_rate || mci-get_sdram_scrub_rate) {
+ if (mci-get_sdram_scrub_rate) {
+ dev_attr_sdram_scrub_rate.attr.mode |= S_IRUGO;
+ dev_attr_sdram_scrub_rate.show =
mci_sdram_scrub_rate_show;
+ }
+ if (mci-set_sdram_scrub_rate) {
+ dev_attr_sdram_scrub_rate.attr.mode |= S_IWUSR;
+ dev_attr_sdram_scrub_rate.store =
mci_sdram_scrub_rate_store;
+ }
+ err = device_create_file(mci-dev,
+dev_attr_sdram_scrub_rate);
+ if (err) {
+ edac_dbg(1, failure: create sdram_scrub_rate\n);
+ goto fail2;
+ }
+ }
/*
* Create the dimm/rank devices
*/
@@ -1061,6 +1069,7 @@ fail:
continue;
device_unregister(dimm-dev);
}
+fail2:
device_unregister(mci-dev);
bus_unregister(mci-bus);
kfree(mci-bus.name);
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4 v8] AMD64 EDAC: Fix type usage in NB IDs and memory ranges
Hi Boris, On 05/12/2012 00:01, Borislav Petkov wrote: On Tue, Dec 04, 2012 at 05:24:16PM +0800, Daniel J Blueman wrote: It works well on fam10h and fam15h boxes, with and without Numaconnect. Good, thanks for testing. I will send it upstream after the upcoming merge window closes since it is too late for this one now and I wouldn't want to rush it if it is not necessary to do so and it hasn't seen enough testing in linux-next and -tip trees. Which means that it will end up in 3.9; I hope that is OK with you guys. Alas your merges missed the v3.8 merge window, but it looks like your v3.9 pull request has dropped these patches [1]. Any chance you can get them in during this merge window? Many thanks, Daniel [1] https://groups.google.com/forum/?fromgroups=#!topic/linux.kernel/2DLVw1Rv8bQ -- Daniel J Blueman Principal Software Engineer, Numascale Asia -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen: introduce xen_remap, use it instead of ioremap
On Tue, Feb 19, 2013 at 01:59:19PM +, Stefano Stabellini wrote:
ioremap can't be used to map ring pages on ARM because it uses device
memory caching attributes (MT_DEVICE*).
Introduce a Xen specific abstraction to map ring pages, called
xen_remap, that is defined as ioremap on x86 (no behavioral changes).
On ARM it explicitly calls __arm_ioremap with the right caching
attributes: MT_MEMORY.
Do you want to push this to Linus yourself or should I just include it
in my 'for-39' tree?
Do you have other patches for 3.9?
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index c6b9096..30cdacb 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1,6 +1,7 @@
#ifndef _ASM_ARM_XEN_PAGE_H
#define _ASM_ARM_XEN_PAGE_H
+#include asm/mach/map.h
#include asm/page.h
#include asm/pgtable.h
@@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn,
unsigned long mfn)
{
return __set_phys_to_machine(pfn, mfn);
}
+
+#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
+
#endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/x86/include/asm/xen/page.h b/arch/x86/include/asm/xen/page.h
index 472b9b7..6aef9fb 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
void make_lowmem_page_readonly(void *vaddr);
void make_lowmem_page_readwrite(void *vaddr);
+#define xen_remap(cookie, size) ioremap((cookie), (size));
+
#endif /* _ASM_X86_XEN_PAGE_H */
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 19843ec..682210d7 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
if (r 0 || v == 0)
goto err;
mfn = v;
- info-intf = ioremap(mfn PAGE_SHIFT, PAGE_SIZE);
+ info-intf = xen_remap(mfn PAGE_SHIFT, PAGE_SIZE);
if (info-intf == NULL)
goto err;
info-vtermno = HVC_COOKIE;
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7038de5..1c2a1e5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1146,7 +1146,7 @@ int gnttab_resume(void)
return gnttab_map(0, nr_grant_frames - 1);
if (gnttab_shared.addr == NULL) {
- gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
+ gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
PAGE_SIZE * max_nr_gframes);
if (gnttab_shared.addr == NULL) {
printk(KERN_WARNING
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index 038b71d..3325884 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -769,7 +769,7 @@ static int __init xenbus_init(void)
goto out_error;
xen_store_mfn = (unsigned long)v;
xen_store_interface =
- ioremap(xen_store_mfn PAGE_SHIFT, PAGE_SIZE);
+ xen_remap(xen_store_mfn PAGE_SHIFT, PAGE_SIZE);
break;
default:
pr_warn(Xenstore state unknown\n);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] timer changes for v3.9
Linus, Please pull the latest timers-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-core-for-linus HEAD: 36dfbbf136db0d645bacfd42ce7d9d6928ea532d timers/x86/hpet: Use HPET_COUNTER to specify the hpet counter in vread_hpet() Main changes: * ntp: Add CONFIG_RTC_SYSTOHC: a generic RTC driver facility complementing the existing CONFIG_RTC_HCTOSYS, which uses NTP to keep the hardware clock updated. * posix-timers: Fix clock_adjtime to always return timex data on success. This is changing the ABI, but no breakage was expected and found - caution is warranted nevertheless. * platform persistent clock improvements/cleanups. * clockevents: refactor timer broadcast handling to be more generic and less duplicated with matching architecture code. (mostly ARM motivated.) * various fixes and cleanups Thanks, Ingo -- Bernd Faust (1): Round the calculated scale factor in set_cyc2ns_scale() Bjorn Helgaas (1): x86/time/rtc: Don't print extended CMOS year when reading RTC Feng Tang (3): timekeeping: Add persistent_clock_exist flag rtc: Skip the suspend/resume handling if persistent clock exist timekeeping: Add CONFIG_HAS_PERSISTENT_CLOCK option Jason Gunthorpe (1): NTP: Add a CONFIG_RTC_SYSTOHC configuration John Stultz (3): MAINTAINERS: Update John Stultz's email x86: Select HAS_PERSISTENT_CLOCK on x86 timekeeping: Switch HAS_PERSISTENT_CLOCK to ALWAYS_USE_PERSISTENT_CLOCK Kees Cook (1): time: create __getnstimeofday for WARNless calls Leonid Shatz (1): hrtimer: Prevent hrtimer_enqueue_reprogram race Mark Rutland (3): clockevents: Add generic timer broadcast receiver clockevents: Add generic timer broadcast function clockevents: Fix generic broadcast for FEAT_C3STOP Miroslav Lichvar (1): posix-timers: Fix clock_adjtime to always return timex data on success Prarit Bhargava (1): time, Fix setting of hardware clock in NTP code Satoru Takeuchi (1): timers/x86/hpet: Use HPET_COUNTER to specify the hpet counter in vread_hpet() Stanislaw Gruszka (1): posix-cpu-timers: Fix nanosleep task_struct leak MAINTAINERS| 2 +- arch/powerpc/kernel/time.c | 2 +- arch/x86/Kconfig | 1 + arch/x86/kernel/rtc.c | 1 - arch/x86/kernel/tsc.c | 3 ++- arch/x86/vdso/vclock_gettime.c | 2 +- drivers/rtc/Kconfig| 12 ++- drivers/rtc/Makefile | 1 + drivers/rtc/class.c| 7 +++ drivers/rtc/systohc.c | 44 + fs/pstore/ram.c| 10 +++--- include/linux/clockchips.h | 9 + include/linux/rtc.h| 1 + include/linux/time.h | 13 kernel/hrtimer.c | 36 - kernel/posix-cpu-timers.c | 23 +++-- kernel/posix-timers.c | 2 +- kernel/time.c | 8 kernel/time/Kconfig| 9 + kernel/time/ntp.c | 22 - kernel/time/tick-broadcast.c | 38 ++- kernel/time/timekeeping.c | 45 -- 22 files changed, 245 insertions(+), 46 deletions(-) create mode 100644 drivers/rtc/systohc.c diff --git a/MAINTAINERS b/MAINTAINERS index 212c255..f5bda78 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6598,7 +6598,7 @@ F:drivers/dma/dw_dmac_regs.h F: drivers/dma/dw_dmac.c TIMEKEEPING, NTP -M: John Stultz johns...@us.ibm.com +M: John Stultz john.stu...@linaro.org M: Thomas Gleixner t...@linutronix.de T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core S: Supported diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index 127361e..aaba2e0 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -668,7 +668,7 @@ int update_persistent_clock(struct timespec now) struct rtc_time tm; if (!ppc_md.set_rtc_time) - return 0; + return -ENODEV; to_tm(now.tv_sec + 1 + timezone_offset, tm); tm.tm_year -= 1900; diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 225543b..97b023f 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -106,6 +106,7 @@ config X86 select GENERIC_CLOCKEVENTS_BROADCAST if X86_64 || (X86_32 X86_LOCAL_APIC) select GENERIC_TIME_VSYSCALL if X86_64 select KTIME_SCALAR if X86_32 + select ALWAYS_USE_PERSISTENT_CLOCK select GENERIC_STRNCPY_FROM_USER select GENERIC_STRNLEN_USER select HAVE_CONTEXT_TRACKING if X86_64 diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c index 801602b..2e8f3d3 100644 --- a/arch/x86/kernel/rtc.c +++ b/arch/x86/kernel/rtc.c @@ -149,7 +149,6 @@
[PATCH V2] xen: event channel arrays are xen_ulong_t and not unsigned long
The following two patches (one for Xen, one for Linux) switch Xen event channels from unsigned long to xen_ulong_t. On arm, this enables us to have the same interface on arm32 and arm64 because xen_ulong_t is a 64-bit type on ARM. On x86 there is no change because xen_ulong_t is unsigned long on x86. Since this is an ABI change on ARM I hope we can get this in for the 3.9 merge window. I have deferred the other changes which I previously posted along side this since they are not so critical. Ian. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen: introduce xen_remap, use it instead of ioremap
On Tue, 19 Feb 2013, Konrad Rzeszutek Wilk wrote:
On Tue, Feb 19, 2013 at 01:59:19PM +, Stefano Stabellini wrote:
ioremap can't be used to map ring pages on ARM because it uses device
memory caching attributes (MT_DEVICE*).
Introduce a Xen specific abstraction to map ring pages, called
xen_remap, that is defined as ioremap on x86 (no behavioral changes).
On ARM it explicitly calls __arm_ioremap with the right caching
attributes: MT_MEMORY.
Do you want to push this to Linus yourself or should I just include it
in my 'for-39' tree?
Do you have other patches for 3.9?
Ian has two patches (linux: public interface changes for arm), it
would be great if they could go in 3.9.
Given the small number of patches (three all together), it is probably
easier to go via your tree, if you are OK with that.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
diff --git a/arch/arm/include/asm/xen/page.h
b/arch/arm/include/asm/xen/page.h
index c6b9096..30cdacb 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -1,6 +1,7 @@
#ifndef _ASM_ARM_XEN_PAGE_H
#define _ASM_ARM_XEN_PAGE_H
+#include asm/mach/map.h
#include asm/page.h
#include asm/pgtable.h
@@ -86,4 +87,7 @@ static inline bool set_phys_to_machine(unsigned long pfn,
unsigned long mfn)
{
return __set_phys_to_machine(pfn, mfn);
}
+
+#define xen_remap(cookie, size) __arm_ioremap((cookie), (size), MT_MEMORY);
+
#endif /* _ASM_ARM_XEN_PAGE_H */
diff --git a/arch/x86/include/asm/xen/page.h
b/arch/x86/include/asm/xen/page.h
index 472b9b7..6aef9fb 100644
--- a/arch/x86/include/asm/xen/page.h
+++ b/arch/x86/include/asm/xen/page.h
@@ -212,4 +212,6 @@ unsigned long arbitrary_virt_to_mfn(void *vaddr);
void make_lowmem_page_readonly(void *vaddr);
void make_lowmem_page_readwrite(void *vaddr);
+#define xen_remap(cookie, size) ioremap((cookie), (size));
+
#endif /* _ASM_X86_XEN_PAGE_H */
diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 19843ec..682210d7 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -230,7 +230,7 @@ static int xen_hvm_console_init(void)
if (r 0 || v == 0)
goto err;
mfn = v;
- info-intf = ioremap(mfn PAGE_SHIFT, PAGE_SIZE);
+ info-intf = xen_remap(mfn PAGE_SHIFT, PAGE_SIZE);
if (info-intf == NULL)
goto err;
info-vtermno = HVC_COOKIE;
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7038de5..1c2a1e5 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1146,7 +1146,7 @@ int gnttab_resume(void)
return gnttab_map(0, nr_grant_frames - 1);
if (gnttab_shared.addr == NULL) {
- gnttab_shared.addr = ioremap(xen_hvm_resume_frames,
+ gnttab_shared.addr = xen_remap(xen_hvm_resume_frames,
PAGE_SIZE * max_nr_gframes);
if (gnttab_shared.addr == NULL) {
printk(KERN_WARNING
diff --git a/drivers/xen/xenbus/xenbus_probe.c
b/drivers/xen/xenbus/xenbus_probe.c
index 038b71d..3325884 100644
--- a/drivers/xen/xenbus/xenbus_probe.c
+++ b/drivers/xen/xenbus/xenbus_probe.c
@@ -769,7 +769,7 @@ static int __init xenbus_init(void)
goto out_error;
xen_store_mfn = (unsigned long)v;
xen_store_interface =
- ioremap(xen_store_mfn PAGE_SHIFT, PAGE_SIZE);
+ xen_remap(xen_store_mfn PAGE_SHIFT, PAGE_SIZE);
break;
default:
pr_warn(Xenstore state unknown\n);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 LINUX] xen: event channel arrays are xen_ulong_t and not unsigned long
On ARM we want these to be the same size on 32- and 64-bit.
This is an ABI change on ARM. X86 does not change.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Keir (Xen.org) k...@xen.org
Cc: Tim Deegan t...@xen.org
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xen.org
---
Changes since V1
use find_first_set not __ffs
fix some more unsigned long - xen_ulong_t
use more generic xchg_xen_ulong instead of ...read_evtchn...
---
arch/arm/include/asm/xen/events.h | 22
arch/x86/include/asm/xen/events.h |3 +
drivers/xen/events.c | 103 -
include/xen/interface/xen.h |8 ++--
4 files changed, 84 insertions(+), 52 deletions(-)
diff --git a/arch/arm/include/asm/xen/events.h
b/arch/arm/include/asm/xen/events.h
index 94b4e90..9bb5f50 100644
--- a/arch/arm/include/asm/xen/events.h
+++ b/arch/arm/include/asm/xen/events.h
@@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
return raw_irqs_disabled_flags(regs-ARM_cpsr);
}
+/*
+ * We cannot use xchg because it does not support 8-byte
+ * values. However it is safe to use {ldr,dtd}exd directly because all
+ * platforms which Xen can run on support those instructions.
+ */
+static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t val)
+{
+ xen_ulong_t oldval;
+ unsigned int tmp;
+
+ wmb();
+ asm volatile(@ read_evtchn_pending_sel\n
+ 1: ldrexd %0, %H0, [%3]\n
+ strexd %1, %2, %H2, [%3]\n
+ teq %1, #0\n
+ bne 1b
+ : =r (oldval), =r (tmp)
+ : r (val), r (ptr)
+ : memory, cc);
+ return oldval;
+}
+
#endif /* _ASM_ARM_XEN_EVENTS_H */
diff --git a/arch/x86/include/asm/xen/events.h
b/arch/x86/include/asm/xen/events.h
index cc146d5..ca842f2 100644
--- a/arch/x86/include/asm/xen/events.h
+++ b/arch/x86/include/asm/xen/events.h
@@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs *regs)
return raw_irqs_disabled_flags(regs-flags);
}
+/* No need for a barrier -- XCHG is a barrier on x86. */
+#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
+
#endif /* _ASM_X86_XEN_EVENTS_H */
diff --git a/drivers/xen/events.c b/drivers/xen/events.c
index 0be4df3..5618ca0 100644
--- a/drivers/xen/events.c
+++ b/drivers/xen/events.c
@@ -80,6 +80,12 @@ enum xen_irq_type {
};
/*
+ * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
+ * array. Primarily to avoid long lines (hence the terse name).
+ */
+#define BM(x) (unsigned long *)(x)
+
+/*
* Packed IRQ information:
* type - enum xen_irq_type
* event channel - irq-event channel mapping
@@ -120,7 +126,9 @@ static unsigned long *pirq_eoi_map;
#endif
static bool (*pirq_needs_eoi)(unsigned irq);
-static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
+#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
+
+static DEFINE_PER_CPU(xen_ulong_t [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
cpu_evtchn_mask);
/* Xen will never allocate port zero for any purpose. */
@@ -294,9 +302,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
return info-u.pirq.flags PIRQ_NEEDS_EOI;
}
-static inline unsigned long active_evtchns(unsigned int cpu,
- struct shared_info *sh,
- unsigned int idx)
+static inline xen_ulong_t active_evtchns(unsigned int cpu,
+struct shared_info *sh,
+unsigned int idx)
{
return sh-evtchn_pending[idx]
per_cpu(cpu_evtchn_mask, cpu)[idx]
@@ -312,8 +320,8 @@ static void bind_evtchn_to_cpu(unsigned int chn, unsigned
int cpu)
cpumask_copy(irq_to_desc(irq)-irq_data.affinity, cpumask_of(cpu));
#endif
- clear_bit(chn, per_cpu(cpu_evtchn_mask, cpu_from_irq(irq)));
- set_bit(chn, per_cpu(cpu_evtchn_mask, cpu));
+ clear_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu_from_irq(irq;
+ set_bit(chn, BM(per_cpu(cpu_evtchn_mask, cpu)));
info_for_irq(irq)-cpu = cpu;
}
@@ -339,19 +347,19 @@ static void init_evtchn_cpu_bindings(void)
static inline void clear_evtchn(int port)
{
struct shared_info *s = HYPERVISOR_shared_info;
- sync_clear_bit(port, s-evtchn_pending[0]);
+ sync_clear_bit(port, BM(s-evtchn_pending[0]));
}
static inline void set_evtchn(int port)
{
struct shared_info *s = HYPERVISOR_shared_info;
- sync_set_bit(port, s-evtchn_pending[0]);
+ sync_set_bit(port, BM(s-evtchn_pending[0]));
}
static inline int test_evtchn(int port)
{
struct shared_info *s = HYPERVISOR_shared_info;
- return sync_test_bit(port, s-evtchn_pending[0]);
+ return sync_test_bit(port,
[PATCH XEN] xen: event channel arrays are xen_ulong_t and not unsigned long
On ARM we want these to be the same size on 32- and 64-bit.
This is an ABI change on ARM. X86 does not change.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Keir (Xen.org) k...@xen.org
Cc: Tim Deegan t...@xen.org
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xen.org
---
tools/include/xen-foreign/mkheader.py |6 ++
xen/include/public/xen.h |8
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/tools/include/xen-foreign/mkheader.py
b/tools/include/xen-foreign/mkheader.py
index d189b07..57681fa 100644
--- a/tools/include/xen-foreign/mkheader.py
+++ b/tools/include/xen-foreign/mkheader.py
@@ -21,13 +21,18 @@ inttypes[arm] = {
unsigned long : uint32_t,
long : uint32_t,
xen_pfn_t : uint64_t,
+xen_ulong_t : uint64_t,
};
+header[arm] =
+#define __arm___ARM32 1
+;
# x86_32
inttypes[x86_32] = {
unsigned long : uint32_t,
long : uint32_t,
xen_pfn_t : uint32_t,
+xen_ulong_t : uint32_t,
};
header[x86_32] =
#define __i386___X86_32 1
@@ -42,6 +47,7 @@ inttypes[x86_64] = {
unsigned long : __align8__ uint64_t,
long : __align8__ uint64_t,
xen_pfn_t : __align8__ uint64_t,
+xen_ulong_t : __align8__ uint64_t,
};
header[x86_64] =
#if defined(__GNUC__) !defined(__STRICT_ANSI__)
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 5593066..99c8212 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -556,7 +556,7 @@ DEFINE_XEN_GUEST_HANDLE(multicall_entry_t);
* Event channel endpoints per domain:
* 1024 if a long is 32 bits; 4096 if a long is 64 bits.
*/
-#define NR_EVENT_CHANNELS (sizeof(unsigned long) * sizeof(unsigned long) * 64)
+#define NR_EVENT_CHANNELS (sizeof(xen_ulong_t) * sizeof(xen_ulong_t) * 64)
struct vcpu_time_info {
/*
@@ -613,7 +613,7 @@ struct vcpu_info {
*/
uint8_t evtchn_upcall_pending;
uint8_t evtchn_upcall_mask;
-unsigned long evtchn_pending_sel;
+xen_ulong_t evtchn_pending_sel;
struct arch_vcpu_info arch;
struct vcpu_time_info time;
}; /* 64 bytes (x86) */
@@ -663,8 +663,8 @@ struct shared_info {
* per-vcpu selector word to be set. Each bit in the selector covers a
* 'C long' in the PENDING bitfield array.
*/
-unsigned long evtchn_pending[sizeof(unsigned long) * 8];
-unsigned long evtchn_mask[sizeof(unsigned long) * 8];
+xen_ulong_t evtchn_pending[sizeof(xen_ulong_t) * 8];
+xen_ulong_t evtchn_mask[sizeof(xen_ulong_t) * 8];
/*
* Wallclock time: updated only by control software. Guests should base
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
