Re: [PATCH] cpufreq: governor: Fix typos in comments
On 27 August 2013 00:12, Stratos Karafotis strat...@semaphore.gr wrote: - 'Governer' should be 'Governor' - 'S' is used for Siemens (electrical conductance) in SI units. Use small 's' for seconds. Signed-off-by: Stratos Karafotis strat...@semaphore.gr --- drivers/cpufreq/cpufreq_governor.c | 2 +- drivers/cpufreq/cpufreq_governor.h | 12 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) Acked-by: Viresh Kumar viresh.ku...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [trivial PATCH] treewide: Fix printks with 0x%#
On Tue, 2013-08-27 at 01:39 -0400, Mike Frysinger wrote:
On Thursday 25 July 2013 14:53:25 Joe Perches wrote:
Using 0x%# emits 0x0x. Only one is necessary.
sounds like a job for checkpatch.pl :)
Here. Submit it yourself...
---
scripts/checkpatch.pl | 12
1 file changed, 12 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9ba4fc4..520f8e7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3869,6 +3869,18 @@ sub process {
}
}
+# check for formats with 0x%#
+ if ($line =~ /X*/) {
+ my $fmt = get_quoted_string($line, $rawline);
+ if ($fmt =~ /0x%#/) {
+ if (WARN(REDUNDANT_HEX,
+Redundant hex prefix 0x format\n .
$herecurr)
+ $fix) {
+ $fixed[$linenr - 1] =~ s/0x%#/%#/g;
+ }
+ }
+ }
+
# Check for misused memsets
if ($^V $^V ge 5.10.0
defined $stat
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/3] pinctrl: at91: add support for generic pinconf
On 27/08/2013 05:54, Stephen Warren wrote:
On 08/26/2013 12:45 PM, boris brezillon wrote:
Hello Jean-Christophe,
Le 26/08/2013 19:53, Jean-Christophe PLAGNIOL-VILLARD a écrit :
On 23:37 Sat 24 Aug , Boris BREZILLON wrote:
Add support for generic pin configuration to pinctrl-at91 driver.
...
a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
...
configures various pad settings
such as pull-up, multi drive, etc.
Required properties for iomux controller:
-- compatible: atmel,at91rm9200-pinctrl
+- compatible: atmel,at91rm9200-pinctrl or atmel,at91sam9x5-pinctrl.
+ Add generic-pinconf to the compatible string list to use the
generic pin
...
+pinctrl@f400 {
+#address-cells = 1;
+#size-cells = 1;
+ranges;
+compatible = atmel,at91rm9200-pinctrl, generic-pinconf,
simple-bus;
nack your break the backword compatibility
if we use a old kernel with this new dt nothing will work
as the old kernel will never known the the generic-pinconf means
anything
Your're right, I didn't think of this case (old kernel with new dt).
Well, just to be clear: If a new DT uses a new compatible value of any
kind, be it adding generic-pinconf or switching to foo-yyy rather
than foo-yyy, it won't be compatible... That somewhat implies that you
can't ever replace an old binding with something new.
That's absolutely right, however the behaviour won't be the same in both
cases.
1) If your (new) dt defines its pinctrl using the foo-pinconf
compatible string and
your (old) kernel does not support it, the pinctrl will never probe
the pinctrl definitions.
Moreover, if you want to define both old (foo-pinctrl) and new
(foo-pinconf) pinctrl
definitions in your dt in order to support several kernel versions,
nothing prevents you
from doing it.
2) In the other hand, if you use an additional generic-pinconf
compatible string to signify
wether or not the pinctrl definition use the generic pinconf dt
binding, the (old) kernel
will probe the pinctrl definitions, ignore the generic-pinconf
string, and fail when parsing
the pinctrl configuration nodes (which are invalid pinctrl function
nodes in the current dt binding).
We have the same problem when using the 'atmel,generic-pinconf'
property inside a pinctrl node:
old kernels won't take this property into account.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] gpio: interrupt consistency check for OF GPIO IRQs
On 2013-08-26 16:04, Lars Poeschel wrote: On Monday 26 August 2013 at 13:29:07, Andreas Larsson wrote: On 2013-08-26 12:56, Lars Poeschel wrote: This call to of_irq_find_parent breaks gpiolib-of for SPARC due to the fact that the function is undefined when !defined(CONFIG_OF_IRQ) defined(CONFIG_OF). Defining the empty of_irq_find_parent in include/linux/of_irq.h when !defined(CONFIG_OF_IRQ) instead of the current case when !defined(CONFIG_OF) would solve the immediate compilation problem. Is this a bug and should be fixed ? Well, at least as soon as anyone tries to use in a context that does not exclude SPARC it creates a bug, so I would say so. There is no reason for SPARC to fall between the chairs. This is the first case I am aware of that triggers this. I also think this should be fixed. Are you able to do a patch that fixes this and submit to the relevant people? Sure! Cheers, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] drivers/base/memory.c: introduce help macro to_memory_block
(2013/08/26 19:32), Gu Zheng wrote:
Introduce help macro to_memory_block to hide the
conversion(device--memory_block),
just clean up.
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
---
It looks good to me.
Reviewed-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Thanks,
Yasuaki Ishimatsu
drivers/base/memory.c | 27 ---
1 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 2b7813e..4a874c6 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -30,6 +30,8 @@ static DEFINE_MUTEX(mem_sysfs_mutex);
#define MEMORY_CLASS_NAME memory
+#define to_memory_block(dev) container_of(dev, struct memory_block, dev)
+
static int sections_per_block;
static inline int base_memory_block_id(int section_nr)
@@ -77,7 +79,7 @@ EXPORT_SYMBOL(unregister_memory_isolate_notifier);
static void memory_block_release(struct device *dev)
{
- struct memory_block *mem = container_of(dev, struct memory_block, dev);
+ struct memory_block *mem = to_memory_block(dev);
kfree(mem);
}
@@ -110,8 +112,7 @@ static unsigned long get_memory_block_size(void)
static ssize_t show_mem_start_phys_index(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct memory_block *mem =
- container_of(dev, struct memory_block, dev);
+ struct memory_block *mem = to_memory_block(dev);
unsigned long phys_index;
phys_index = mem-start_section_nr / sections_per_block;
@@ -121,8 +122,7 @@ static ssize_t show_mem_start_phys_index(struct device *dev,
static ssize_t show_mem_end_phys_index(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct memory_block *mem =
- container_of(dev, struct memory_block, dev);
+ struct memory_block *mem = to_memory_block(dev);
unsigned long phys_index;
phys_index = mem-end_section_nr / sections_per_block;
@@ -137,8 +137,7 @@ static ssize_t show_mem_removable(struct device *dev,
{
unsigned long i, pfn;
int ret = 1;
- struct memory_block *mem =
- container_of(dev, struct memory_block, dev);
+ struct memory_block *mem = to_memory_block(dev);
for (i = 0; i sections_per_block; i++) {
pfn = section_nr_to_pfn(mem-start_section_nr + i);
@@ -154,8 +153,7 @@ static ssize_t show_mem_removable(struct device *dev,
static ssize_t show_mem_state(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct memory_block *mem =
- container_of(dev, struct memory_block, dev);
+ struct memory_block *mem = to_memory_block(dev);
ssize_t len = 0;
/*
@@ -280,7 +278,7 @@ static int __memory_block_change_state(struct memory_block
*mem,
static int memory_subsys_online(struct device *dev)
{
- struct memory_block *mem = container_of(dev, struct memory_block, dev);
+ struct memory_block *mem = to_memory_block(dev);
int ret;
mutex_lock(mem-state_mutex);
@@ -295,7 +293,7 @@ static int memory_subsys_online(struct device *dev)
static int memory_subsys_offline(struct device *dev)
{
- struct memory_block *mem = container_of(dev, struct memory_block, dev);
+ struct memory_block *mem = to_memory_block(dev);
int ret;
mutex_lock(mem-state_mutex);
@@ -349,7 +347,7 @@ store_mem_state(struct device *dev,
bool offline;
int ret = -EINVAL;
- mem = container_of(dev, struct memory_block, dev);
+ mem = to_memory_block(dev);
lock_device_hotplug();
@@ -392,8 +390,7 @@ store_mem_state(struct device *dev,
static ssize_t show_phys_device(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct memory_block *mem =
- container_of(dev, struct memory_block, dev);
+ struct memory_block *mem = to_memory_block(dev);
return sprintf(buf, %d\n, mem-phys_device);
}
@@ -525,7 +522,7 @@ struct memory_block *find_memory_block_hinted(struct
mem_section *section,
put_device(hint-dev);
if (!dev)
return NULL;
- return container_of(dev, struct memory_block, dev);
+ return to_memory_block(dev);
}
/*
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mfd: 88pm800: Fix the bug that pdata may be NULL
On Tue, Aug 20, 2013 at 9:40 AM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Xie, On Sun, Aug 18, 2013 at 09:27:54PM -0400, Chao Xie wrote: User pass platform data to device, and platform data may be NULL. In which case do you get that ? With DT ? Should rtc_init fail when pdata is NULL ? You need to explain that, be it only for us to know if it's a critical fix or not. Sorry for late response. If pdata is NULL, the driver will fail. So the error check should be done at the beginning of probe. If (!pdata) return -EINVAL; Is that OK? 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/
linux-next: build failure after merge of the spi tree
Hi Mark, After merging the spi tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/spi/spi-ti-qspi.c:19:0: include/linux/module.h:87:32: error: '__mod_of_device_table' aliased to undefined symbol 'dra7xxx_qspi_match' extern const struct gtype##_id __mod_##gtype##_table \ ^ include/linux/module.h:145:3: note: in expansion of macro 'MODULE_GENERIC_TABLE' MODULE_GENERIC_TABLE(type##_device,name) ^ drivers/spi/spi-ti-qspi.c:458:1: note: in expansion of macro 'MODULE_DEVICE_TABLE' MODULE_DEVICE_TABLE(of, dra7xxx_qspi_match); ^ Caused by commit 505a14954e2d (spi/qspi: Add qspi flash controller). Clearly not build tested as a module. :-( I have used the spi tree from next-20130822 for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpSd2DdvPxW2.pgp Description: PGP signature
Re: [RFC PATCH v2 next]module: Fix mod-mkobj.kobj potentially freed too early
On Tue, Aug 27, 2013 at 02:08:27PM +0930, Rusty Russell wrote: Greg KH gre...@linuxfoundation.org writes: On Thu, Aug 22, 2013 at 03:37:55PM +0800, Li Zhong wrote: DEBUG_KOBJECT_RELEASE helps to find the issue attached below. People are starting to hit these types of issues, and I'd like to take this one out of the picture. Rusty, any objection to me taking this through my driver-core tree, where this new config option shows up? The original fix was better. Moving the module_kobject out and giving it its own lifetime solves this immediate issue, but it still means there's an accessible module_kobject around referring to a module which doesn't exist any more. That's ok, it could happen before as well. What's wrong with that? Original copied below, feel free to take it. You are just sitting and sleeping until someone drops the last reference to the module. What if userspace grabs a reference from sysfs? That could never return, I don't think you want to stall that out. I'd prefer not having 2 things determining the lifecycle of a single object, that's messy, and not needed at all. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel: Assembly: need add prefix for h8300 architecture.
On 08/27/2013 01:12 PM, Rusty Russell wrote: Chen Gang gang.c...@asianux.com writes: If this implementation is correct, the implementation still can be improved (at least, it is not quite well to hard code the architecture related code in kernel/ and usr/ sub-directory). But it seems, I have no right to add or move files, so welcome any members help do it. And welcome any additional suggestions or completions. Hmm, how about something like: #ifdef CONFIG_ARCH_ASM_INCBIN_NEEDS_PREFIX #include asm/incbin_prefix.h ASM_INCBIN_PREFIX #endif /* ARCH_ASM_INCBIN_NEEDS_PREFIX */ Then h8300 can define ARCH_ASM_INCBIN_NEEDS_PREFIX in Kconfig and define ASM_INCBIN_PREFIX in arch/h8300/include/asm/incbin_prefix.h? Thank you for your reply firstly, I think your way is OK (valuable to continue think of the details implementation). And excuse me, I continued replying multiple times for this thread (I am just continue improving it). Current status: after check the binutils-2.22 source code, we know if use -no-warn-mismatch for 'ld', it can avoid this issue. and also for another 'ld' issue (which I occurs but not send mail), need use -accept-unknown-input-arch for 'ld': Relocatable linking with relocations from format elf32-h8300 (firmware/keyspan/mpr.fw.gen.o) to format elf32-h8300 (firmware/built-in.o) is not supported ... maybe find more issues during compiling with 'allmodconfig'. My opinion: if h8300 is still one of important architecture, we need try to let our binary match 'ld' else just use skipping parameters is OK. In my current feeling, h8300 is not one of important architecture, so I choose 2nd. Welcome additional suggestion or completions. Thanks. Cheers, Rusty. On 08/26/2013 06:42 PM, Chen Gang wrote: Need add related prefix for h8300, or can not pass compiling by the latest linker. The related error (allmodconfig for h8300): /usr/local/bin/h8300-gchen-elf-ld: h8300 architecture of input file `usr/initramfs_data.o' is incompatible with h8300h output /usr/local/bin/h8300-gchen-elf-ld: h8300 architecture of input file `kernel/modsign_certificate.o' is incompatible with h8300h output The cross-compiler's information: [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-ld -v GNU ld (GNU Binutils) 2.22 [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-as -v GNU assembler version 2.22 (h8300-gchen-elf) using BFD version (GNU Binutils) 2.22 [root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-gcc -v Using built-in specs. COLLECT_GCC=/usr/local/bin/h8300-gchen-elf-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/h8300-gchen-elf/4.8.0/lto-wrapper Target: h8300-gchen-elf Configured with: ../gcc-4.8.0/configure --target=h8300-gchen-elf --without-header --disable-nls --enable-language=c --disable-threads --disable-shared --enable-werror=no Thread model: single gcc version 4.8.0 (GCC) Signed-off-by: Chen Gang gang.c...@asianux.com --- kernel/modsign_certificate.S |7 +++ usr/initramfs_data.S |7 +++ 2 files changed, 14 insertions(+), 0 deletions(-) diff --git a/kernel/modsign_certificate.S b/kernel/modsign_certificate.S index 4a9a86d..d24acac 100644 --- a/kernel/modsign_certificate.S +++ b/kernel/modsign_certificate.S @@ -1,5 +1,12 @@ #include linux/export.h +#if defined(CONFIG_CPU_H8300H) + .h8300h +#endif +#if defined(CONFIG_CPU_H8S) + .h8300s +#endif + #define GLOBAL(name) \ .globl VMLINUX_SYMBOL(name);\ VMLINUX_SYMBOL(name): diff --git a/usr/initramfs_data.S b/usr/initramfs_data.S index c14322d..6a6c106 100644 --- a/usr/initramfs_data.S +++ b/usr/initramfs_data.S @@ -24,6 +24,13 @@ #include linux/stringify.h #include asm-generic/vmlinux.lds.h +#if defined(CONFIG_CPU_H8300H) + .h8300h +#endif +#if defined(CONFIG_CPU_H8S) + .h8300s +#endif + .section .init.ramfs,a __irf_start: .incbin __stringify(INITRAMFS_IMAGE) -- Chen Gang -- Chen Gang -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On 27/08/2013 05:55, Stephen Warren wrote: On 08/26/2013 11:01 AM, boris brezillon wrote: Hello Stephen, On 26/08/2013 18:50, Stephen Warren wrote: On 08/24/2013 03:35 PM, Boris BREZILLON wrote: Add a new parameter to support deglitch filter configuration. A deglitch filter works like a debounce filter but with a smaller delay (nanoseconds). Why not use the existing debounce property, just with a small delay specified. It seems like that's exactly what the property is for? That's one of the question I asked in my cover letter :-) Indeed the at91 deglitch filter delay is not configurable and is statically assigned to half a master clk cycle (if master clk = 133MHz - 8 ns). The debounce property argument is currently expressed in usecs. This will result in always selecting the debounce filter (which is also available on at91 SoCs) over the deglitch filter. Could we add a flag in the deglitch argument to specify the delay unit (nsecs or usecs) ? If the value is hard-coded in HW, why not use non-zero (or 1) to enable and zero to disable? Indeed at91 pins support both deglitch and debounce filter and I have to choose between the two given the argument value (in usec). Here's what I can do: if (arg = 1/2 * slowclock)/* debounce case */ /* choose debounce filter and configure the delay according to the given argument value */ else /* deglitch case */ /* choose deglitch filter */ Slow clock is running at 32KHz which gives a 30 usec clock cycle. (this kind of thing is why I'm not convinced that generic pinconf works so well... What if we need psecs in the future?) Should I keep the at91 native pinconf binding and add the missing flags to this binding (OUTPUT configuration flags) ? This was another question I asked in my cover letter: wether or not the generic pinconf binding should be used. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] cpufreq: Fix timer/workqueue corruption due to double queueing
On 27 August 2013 04:15, Stephen Boyd sb...@codeaurora.org wrote:
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -133,7 +133,7 @@ void gov_queue_work(struct dbs_data *dbs_data, struct
cpufreq_policy *policy,
{
int i;
- if (!all_cpus) {
+ if (!all_cpus || !policy-governor_enabled) {
__gov_queue_work(smp_processor_id(), dbs_data, delay);
} else {
for_each_cpu(i, policy-cpus)
Shouldn't we simply do this instead at the top of this function?
+ if (!policy-governor_enabled)
+ return;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 02/10] KVM: PPC: reserve a capability number for multitce support
On Tue, Aug 27, 2013 at 02:19:58PM +1000, Benjamin Herrenschmidt wrote: On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote: Gleb, any chance you can put this (and the next one) into a tree to lock in the numbers ? Applied it. Sorry for slow response, was on vocation and still go through the email backlog. Thanks. Since it's not in a topic branch that I can pull, I'm going to just cherry-pick them. However, they are in your queue branch, not next branch. Should I still assume this is a stable branch and that the numbers aren't going to change ? Queue will become next after I will test it and if test will fail the commit hash may change, but since you are going to cherry-pick and this does not preserve commit hash it does not matter. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 02/10] KVM: PPC: reserve a capability number for multitce support
On Tue, Aug 27, 2013 at 02:22:42PM +1000, Benjamin Herrenschmidt wrote: On Tue, 2013-08-27 at 14:19 +1000, Benjamin Herrenschmidt wrote: On Mon, 2013-08-26 at 15:37 +0300, Gleb Natapov wrote: Gleb, any chance you can put this (and the next one) into a tree to lock in the numbers ? Applied it. Sorry for slow response, was on vocation and still go through the email backlog. Thanks. Since it's not in a topic branch that I can pull, I'm going to just cherry-pick them. However, they are in your queue branch, not next branch. Should I still assume this is a stable branch and that the numbers aren't going to change ? Oh and Alexey mentions that there are two capabilities and you only applied one :-) Another one is: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO ? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/3] pinctrl: at91: add support for generic pinconf
On 27/08/2013 05:57, Stephen Warren wrote: On 08/26/2013 11:17 AM, boris brezillon wrote: On 26/08/2013 18:53, Stephen Warren wrote: On 08/24/2013 03:37 PM, Boris BREZILLON wrote: Add support for generic pin configuration to pinctrl-at91 driver. diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt Required properties for iomux controller: -- compatible: atmel,at91rm9200-pinctrl +- compatible: atmel,at91rm9200-pinctrl or atmel,at91sam9x5-pinctrl. You seem to also be adding a second chip name to the list here, which is more than the patch subject/description imply you're doing... This is an update of the documentation: atmel,at91sam9x5-pinctrl compatible is already used in the pinctrl driver but the documention was not updated. But I agree, this should not be part of this series. + Add generic-pinconf to the compatible string list to use the generic pin + configuration syntax. generic-pinconf is too generic of a compatible value for this binding to define. Instead, I think you want to either: a) Use compatible=atmel,at91rm9200-pinctrl for the old binding, use compatible=atmel,at91rm9200-pinctrl-generic for the new binding or: b) Define Boolean property atmel,generic-pinconf (perhaps a better name could be chosen?). If it's not present, parse the node assuming the old binding. If it is present, parse the node assuming the new binding. Okay. I thought this property string could be generic as it may concern other drivers too (in order to keep compatibility with old dt ABI and add support the generic pinconf binding). Anyway, I prefer the first proposition. pinctrl single driver is already using these names: |compatible = pinctrl-single for non generic pinconf binding ||compatible = pinconf-single ||for generic pinconf binding| So I think we should use something similar: |compatible = atmel,at91xx-pinctrl for non generic pinconf binding ||compatible = |||atmel,at91xx-|pinconf ||for generic pinconf binding| What do you think ? Hmmm. It is a little odd to switch out the compatible value and invent a new binding for the same HW. Isn't it possible to define both sets of properties in the binding, and have drivers look for either? Do you mean something like: atmel,pins = xxx;/* current dt binding */ atmel,generic-pins = yyy;/* new dt binding */ If that's what you had in mind, it will be a little bit tricky to handle, because AFAIK the pinconf_ops callbacks do not give me any element I could use to deduce the type of pinconf (generic or native). This implies I have to know early during the probe process which kind of binding is in use. Please tell me if I missed some key points, and this can be easily done. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 26/28] PCI, x86, ACPI: Link acpi ioapic register to ioapic
On 8/27/13, Yinghai Lu ying...@kernel.org wrote:
On Fri, Aug 23, 2013 at 5:51 PM, rui wang ruiv.w...@gmail.com wrote:
On 8/11/13, Yinghai Lu ying...@kernel.org wrote:
During ioapic hotplug, acpi_register_ioapic will be called.
Now for x86, that function is blank.
Fill that will update __mp_register_ioapic to use those ioapic.
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/x86/kernel/acpi/boot.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 5be15d1..4a5336d 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -707,16 +707,18 @@ EXPORT_SYMBOL(acpi_unmap_lsapic);
int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32
gsi_base)
{
- /* TBD */
- return -EINVAL;
+ unsigned long long id = 0;
+
+ acpi_evaluate_integer(handle, _UID, NULL, id);
We cannot assume that _UID is an integer. _UID can be either an
integer or a string. Need to consider the case when it is a string.
Yes.
But do you have test case for ioapic that _UID is not integer?
Yes I have an IOAPIC with an _UID of:
Name (_UID, IOAPIC01) // _UID: Unique ID
It's a bit challenge how you'll conjure unique identifiers from both
integers and strings. If you have a new patch I can help try it out.
Thanks
Rui
Thanks
Yinghai
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND V3 net-next 2/3] net: huawei_cdc_ncm: Introduce the huawei_cdc_ncm driver
Hi guys!! :) First of all - I would like to thank both of you for your interest and time in my patches. I agree with Joe's point of view, completely. The Coding style document tries to leverage on the developer's good sense, even when defining some rules. Apart from that - checkpatch.po informed me about those very long lines, but I decided to leave them as they are due to the fact that they would look even more horrible than they look now. My braille display is 80-chars long (at least, the one I use normally), so I understand very well the problem of not passing that limit. Even so, the coding style says you might do so if you think the code is more readable this way, and that's why. My git usage is very bad as you may have observed (and I'm working on improving myself of course), but this was something I took into consideration. I remember when this cameto discussion: http://lkml.org/lkml/2009/12/17/229 still I know perfectly that one of the line you're blaming is indeed 139 characters. I understand and appreciate the fact that we _shouldn't_ take as reference worst cases (but only bbetter cases) to improve our practice life, but in various drivers you can find examples like those. Is this still a problem? I will re-work the code and send the patch again as soon as I can. thank you again! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 26/28] PCI, x86, ACPI: Link acpi ioapic register to ioapic
On Mon, Aug 26, 2013 at 11:44 PM, rui wang ruiv.w...@gmail.com wrote:
On 8/27/13, Yinghai Lu ying...@kernel.org wrote:
On Fri, Aug 23, 2013 at 5:51 PM, rui wang ruiv.w...@gmail.com wrote:
On 8/11/13, Yinghai Lu ying...@kernel.org wrote:
During ioapic hotplug, acpi_register_ioapic will be called.
Now for x86, that function is blank.
Fill that will update __mp_register_ioapic to use those ioapic.
Signed-off-by: Yinghai Lu ying...@kernel.org
---
arch/x86/kernel/acpi/boot.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 5be15d1..4a5336d 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -707,16 +707,18 @@ EXPORT_SYMBOL(acpi_unmap_lsapic);
int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32
gsi_base)
{
- /* TBD */
- return -EINVAL;
+ unsigned long long id = 0;
+
+ acpi_evaluate_integer(handle, _UID, NULL, id);
We cannot assume that _UID is an integer. _UID can be either an
integer or a string. Need to consider the case when it is a string.
Yes.
But do you have test case for ioapic that _UID is not integer?
Yes I have an IOAPIC with an _UID of:
Name (_UID, IOAPIC01) // _UID: Unique ID
It's a bit challenge how you'll conjure unique identifiers from both
integers and strings. If you have a new patch I can help try it out.
Then do you have _MAT with that ioapic device or else?
need to find the _MAT entry with GSM matching to find out ioapic id.
Thanks
Yinghai
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: [guv v2 25/31] avr32: Replace __get_cpu_var uses
Around Mon 26 Aug 2013 20:56:16 + or thereabout, Christoph Lameter wrote:
snipp reasoning
Index: linux/arch/avr32/kernel/kprobes.c
===
--- linux.orig/arch/avr32/kernel/kprobes.c2013-08-26 13:25:18.0
-0500
+++ linux/arch/avr32/kernel/kprobes.c 2013-08-26 13:27:09.758485808 -0500
@@ -104,7 +104,7 @@ static void __kprobes resume_execution(s
static void __kprobes set_current_kprobe(struct kprobe *p)
{
- __get_cpu_var(current_kprobe) = p;
+ __this_cpu_write(current_kprobe, p);
}
static int __kprobes kprobe_handler(struct pt_regs *regs)
Acked-by: Hans-Christian Egtvedt egtv...@samfundet.no
--
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the spi tree
Hi, On Tuesday 27 August 2013 11:45 AM, Stephen Rothwell wrote: Hi Mark, After merging the spi tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from drivers/spi/spi-ti-qspi.c:19:0: include/linux/module.h:87:32: error: '__mod_of_device_table' aliased to undefined symbol 'dra7xxx_qspi_match' extern const struct gtype##_id __mod_##gtype##_table \ ^ include/linux/module.h:145:3: note: in expansion of macro 'MODULE_GENERIC_TABLE' MODULE_GENERIC_TABLE(type##_device,name) ^ drivers/spi/spi-ti-qspi.c:458:1: note: in expansion of macro 'MODULE_DEVICE_TABLE' MODULE_DEVICE_TABLE(of, dra7xxx_qspi_match); ^ Caused by commit 505a14954e2d (spi/qspi: Add qspi flash controller). Clearly not build tested as a module. :-( Yes, module build test was missed. I will send a patch for this to Mark. I have used the spi tree from next-20130822 for today. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor
On 27.08.13 at 01:42, K. Y. Srinivasan k...@microsoft.com wrote:
Hyper-V supports a mechanism for retrieving the local API frequency.
APIC?
@@ -27,6 +27,13 @@
#define HV_X64_MSR_VP_RUNTIME_AVAILABLE (1 0)
/* Partition Reference Counter (HV_X64_MSR_TIME_REF_COUNT) available*/
#define HV_X64_MSR_TIME_REF_COUNT_AVAILABLE (1 1)
+
+/* Local APIC timer frequency MSR (HV_X64_MSR_APIC_FREQUENCY) is available */
+#define HV_X64_MSR_APIC_FREQUENCY_AVAILABLE (1 11)
+
+/* TSC frequency MSR (HV_X64_MSR_TSC_FREQUENCY) is available */
+#define HV_X64_MSR_TSC_FREQUENCY_AVAILABLE (1 11)
Are these two really the same bit? If so, why two different names?
@@ -136,6 +143,12 @@
/* MSR used to read the per-partition time reference counter */
#define HV_X64_MSR_TIME_REF_COUNT0x4020
+/* MSR used to retrive the TSC frequency */
+#define HV_X64_MSR_TSC_FREQUENCY 0x4022
+
+/* MSR used to retrive the local APIC timer frequency */
+#define HV_X64_MSR_APIC_FREQUENCY0x4023
retrieve (twice)?
@@ -76,6 +77,22 @@ static void __init ms_hyperv_init_platform(void)
printk(KERN_INFO HyperV: features 0x%x, hints 0x%x\n,
ms_hyperv.features, ms_hyperv.hints);
+ if (ms_hyperv.features HV_X64_MSR_APIC_FREQUENCY_AVAILABLE) {
+ /*
+ * There is no need to calibrate APIC timer frequency;
+ * nor is there a need to calibrate timer.
+ */
+ legacy_pic = null_legacy_pic;
This clearly disables more than just the calibration, so the comment
may be misleading to future readers.
+
+ /*
+ * Get the APIC frequency.
+ */
+ rdmsrl(HV_X64_MSR_APIC_FREQUENCY, lapic_timer_frequency);
+ lapic_timer_frequency /= HZ;
Is this safe? I.e. are the high 32 bits of the MSR guaranteed to
be zero, now and forever?
+ printk(KERN_INFO HyperV: LAPIC Timer Frequency: 0x%x\n,
+ lapic_timer_frequency);
As a minor note, I generally recommend using %#x as being one
byte shorter than the spelled out 0x%x.
Jan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are 3 bug fixes that should probably go into 3.11 since I'm also tagging them for stable. Once fixes our old /proc/powerpc/lparcfg file which provides partition informations when running under our hypervisor and also acts as a user-triggerable Oops when hot :-( The other two respectively are a one liner to fix a HVSI protocol handshake problem causing the console to fail to show up on a bunch of machines until we reach userspace, which I deem annoying enough to warrant going to stable, and a nasty gcc miscompile causing us to pass virtual instead of physical addresses to the firmware under some circumstances. Cheers, Ben. The following changes since commit 28e61cc466d8daace4b0f04ba2b83e0bd68f5832: powerpc/tm: Fix context switching TAR, PPR and DSCR SPRs (2013-08-09 18:07:12 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to d220980b701d838560a70de691b53be007e99e78: powerpc/hvsi: Increase handshake timeout from 200ms to 400ms. (2013-08-27 16:59:56 +1000) Benjamin Herrenschmidt (1): powerpc: Don't Oops when accessing /proc/powerpc/lparcfg without hypervisor Eugene Surovegin (1): powerpc/hvsi: Increase handshake timeout from 200ms to 400ms. Paul Mackerras (1): powerpc: Work around gcc miscompilation of __pa() on 64-bit arch/powerpc/Kconfig| 1 + arch/powerpc/include/asm/page.h | 10 ++ arch/powerpc/kernel/lparcfg.c | 22 +- drivers/tty/hvc/hvsi_lib.c | 4 ++-- 4 files changed, 22 insertions(+), 15 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] mfd: omap-usb-host: Staticize usbhs_driver_name
On Fri, 23 Aug 2013, Sachin Kamat wrote: usbhs_driver_name is used only in this file. Make it static. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/mfd/omap-usb-host.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3 v2] raid5: make stripe handling multi-threading
On Mon, 12 Aug 2013 10:18:03 +0800 Shaohua Li s...@kernel.org wrote:
Neil,
This is another attempt to make raid5 stripe handling multi-threading.
Recent workqueue improvement for unbound workqueue looks very promising to the
raid5 usage. I had details in the first patch.
The patches are against your tree with patch 'raid5: make release_stripe
lockless' and 'raid5: fix stripe release order' but without 'raid5: create
multiple threads to handle stripes'
My test setup has 7 PCIe SSD, chunksize 8k, stripe_cache_size 2048. If
enabling
multi-threading, group_thread_cnt is set to 8.
randwrite throughput(ratio) unpatch/patch requestsize(sectors)
unpatch/patch
4k1/5.9 8/8
8k1/5.5 16/13
16k 1/4.8 16/13
32k 1/4.6 18/14
64k 1/4.7 17/13
128k 1/4.2 23/16
256k 1/3.5 41/21
512k 1/3 75/28
1M1/2.6 134/34
For example, in 1M randwrite test, patched kernel is 2.6x faster, but average
request sending to each disk is drop to 34 sectors from 134 sectors long.
Currently the biggest problem is request size is dropped, because there are
multiple threads dispatching requests. This indicates multi-threading might
not
be proper for all setup, so I disable it by default in this version. But since
throughput is largly improved, I thought this isn't a blocking issue. I'm
still
working on improving this, maybe schedule stripes from one block plug as a
whole.
Thanks,
Shaohua
Thanks. I like this a lot more than the previous version.
It doesn't seem to apply exactly to my current 'for-next' - probably because
I have moved things around and have a different set of patches applied :-(
If you could rebase it on my current for-next I'll apply it and probably
submit for next merge window.
A couple of little changes I'd like made:
1/ alloc_thread_groups need to use GFP_NOIO, it least when called from
raid5_store_group_thread_cnt. At this point in time IO to the RAID5 is
stalled so if the malloc needs to free memory it might wait for writeout to
the RAID5 and so deadlock. GFP_NOIO prevents that.
2/ could we move the
+ if (!cpu_online(cpu)) {
+ cpu = cpumask_any(cpu_online_mask);
+ sh-cpu = cpu;
+ }
inside raid5_wakeup_stripe_thread() ?
It isn't a perfect fit, but I think it is a better place for it.
It could check list_empty(sh-lru) and if it is empty, add to
the appropriate group-handle_list.
The code in do_release_stripe would become
else {
clear_bit(STRIPE_DELAYED, sh-state);
clear_bit(STRIPE_BIT_DELAY, sh-state);
+ if (conf-worker_cnt_per_group == 0) {
+ list_add_tail(sh-lru, conf-handle_list);
+ } else {
+ raid5_wakeup_stripe_thread(sh);
+ return;
+ }
}
md_wakeup_thread(conf-mddev-thread);
??
NeilBrown
signature.asc
Description: PGP signature
Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
On Tue, 2013-08-27 at 09:40 +0300, Gleb Natapov wrote: Thanks. Since it's not in a topic branch that I can pull, I'm going to just cherry-pick them. However, they are in your queue branch, not next branch. Should I still assume this is a stable branch and that the numbers aren't going to change ? Queue will become next after I will test it and if test will fail the commit hash may change, but since you are going to cherry-pick and this does not preserve commit hash it does not matter. Right, as long as the actual cap and ioctl numbers remain stable :-) Cheers, Ben. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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: [REGRESSION 3.11-rc] wm8775 9-001b: I2C: cannot write ??? to register R??
On 08/25/2013 05:45 PM, Knut Petersen wrote:
Booting current git kernel dmesg shows a set of new warnings:
wm8775 9-001b: I2C: cannot write ??? to register R??
Nevertheless, the hardware seems to work fine.
This is a new problem, introduced after kernel 3.10.
If necessary I can bisect.
Can you try this patch? I'm pretty sure this will fix it.
Regards,
Hans
diff --git a/drivers/media/pci/cx88/cx88.h b/drivers/media/pci/cx88/cx88.h
index afe0eae..28893a6 100644
--- a/drivers/media/pci/cx88/cx88.h
+++ b/drivers/media/pci/cx88/cx88.h
@@ -259,7 +259,7 @@ struct cx88_input {
};
enum cx88_audio_chip {
- CX88_AUDIO_WM8775,
+ CX88_AUDIO_WM8775 = 1,
CX88_AUDIO_TVAUDIO,
};
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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/2] net/cadence/macb: add support for dt phy definition
Hello, This patch series adds support for ethernet phy definition using device tree. This may help in moving some at91 boards to dt (some of them define an interrupt pin). Tested on samad31ek. Best Regards, Boris Changes since v2: - fix wrong address of phy0 dt node Changes since v1: - fix wrong macb_mii_init return code when no PHY device is discovered Boris BREZILLON (2): net/cadence/macb: add support for dt phy definition ARM: at91/dt: define phy available on sama5d3 mother board arch/arm/boot/dts/sama5d3xmb.dtsi |8 ++ drivers/net/ethernet/cadence/macb.c | 48 +++ 2 files changed, 46 insertions(+), 10 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/2] net/cadence/macb: add support for dt phy definition
The macb driver only handle PHY description through platform_data
(macb_platform_data).
Thus, when using dt you cannot define phy properties like phy address or
phy irq pin.
This patch makes use of the of_mdiobus_register to add support for
phy device definition using dt.
A fallback to the autoscan procedure is added in case there is no phy
devices defined in dt.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
drivers/net/ethernet/cadence/macb.c | 48 +++
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index e866608..393afeb 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -27,6 +27,7 @@
#include linux/phy.h
#include linux/of.h
#include linux/of_device.h
+#include linux/of_mdio.h
#include linux/of_net.h
#include linux/pinctrl/consumer.h
@@ -275,7 +276,7 @@ static int macb_mii_probe(struct net_device *dev)
phydev = phy_find_first(bp-mii_bus);
if (!phydev) {
netdev_err(dev, no PHY found\n);
- return -1;
+ return -ENXIO;
}
pdata = dev_get_platdata(bp-pdev-dev);
@@ -314,6 +315,7 @@ static int macb_mii_probe(struct net_device *dev)
int macb_mii_init(struct macb *bp)
{
struct macb_platform_data *pdata;
+ struct device_node *np;
int err = -ENXIO, i;
/* Enable management port */
@@ -335,26 +337,52 @@ int macb_mii_init(struct macb *bp)
bp-mii_bus-parent = bp-dev-dev;
pdata = bp-pdev-dev.platform_data;
- if (pdata)
- bp-mii_bus-phy_mask = pdata-phy_mask;
-
bp-mii_bus-irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
if (!bp-mii_bus-irq) {
err = -ENOMEM;
goto err_out_free_mdiobus;
}
- for (i = 0; i PHY_MAX_ADDR; i++)
- bp-mii_bus-irq[i] = PHY_POLL;
-
dev_set_drvdata(bp-dev-dev, bp-mii_bus);
- if (mdiobus_register(bp-mii_bus))
+ np = bp-pdev-dev.of_node;
+ if (np) {
+ /* try dt phy registration */
+ err = of_mdiobus_register(bp-mii_bus, np);
+
+ /* fallback to standard phy registration if no phy were
+* found during dt phy registration
+*/
+ if (!err !phy_find_first(bp-mii_bus)) {
+ for (i = 0; i PHY_MAX_ADDR; i++) {
+ struct phy_device *phydev;
+
+ phydev = mdiobus_scan(bp-mii_bus, i);
+ if (IS_ERR(phydev)) {
+ err = PTR_ERR(phydev);
+ break;
+ }
+ }
+
+ if (err)
+ goto err_out_unregister_bus;
+ }
+ } else {
+ for (i = 0; i PHY_MAX_ADDR; i++)
+ bp-mii_bus-irq[i] = PHY_POLL;
+
+ if (pdata)
+ bp-mii_bus-phy_mask = pdata-phy_mask;
+
+ err = mdiobus_register(bp-mii_bus);
+ }
+
+ if (err)
goto err_out_free_mdio_irq;
- if (macb_mii_probe(bp-dev) != 0) {
+ err = macb_mii_probe(bp-dev);
+ if (err)
goto err_out_unregister_bus;
- }
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/
[PATCH v3 2/2] ARM: at91/dt: define phy available on sama5d3 mother board
This patch describe the phy used on atmel sama5d3 mother board:
- phy address
- phy interrupt pin
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
arch/arm/boot/dts/sama5d3xmb.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi
b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 8a9e05d..dba739b 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -81,6 +81,14 @@
macb1: ethernet@f802c000 {
phy-mode = rmii;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ phy0: ethernet-phy@1 {
+ interrupt-parent = pioE;
+ interrupts = 30 IRQ_TYPE_EDGE_FALLING;
+ reg = 1;
+ };
};
pinctrl@f200 {
--
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 03/20] mm, hugetlb: fix subpool accounting handling
On Mon, Aug 26, 2013 at 06:31:35PM +0530, Aneesh Kumar K.V wrote: Joonsoo Kim iamjoonsoo@lge.com writes: On Thu, Aug 22, 2013 at 12:38:12PM +0530, Aneesh Kumar K.V wrote: Joonsoo Kim iamjoonsoo@lge.com writes: Hello, Aneesh. First of all, thank you for review! On Wed, Aug 21, 2013 at 02:58:20PM +0530, Aneesh Kumar K.V wrote: Joonsoo Kim iamjoonsoo@lge.com writes: If we alloc hugepage with avoid_reserve, we don't dequeue reserved one. So, we should check subpool counter when avoid_reserve. This patch implement it. Can you explain this better ? ie, if we don't have a reservation in the area chg != 0. So why look at avoid_reserve. We don't consider avoid_reserve when chg != 0. Look at following code. + if (chg || avoid_reserve) + if (hugepage_subpool_get_pages(spool, 1)) It means that if chg != 0, we skip to check avoid_reserve. when whould be avoid_reserve == 1 and chg == 0 ? In this case, we should do hugepage_subpool_get_pages(), since we don't get a reserved page due to avoid_reserve. As per off-list discussion we had around this, please add additional information in commit message explaining when we have avoid_reserve == 1 and chg == 0 Okay! Something like the below copied from call site. /* If the process that created a MAP_PRIVATE mapping is about to * perform a COW due to a shared page count, attempt to satisfy * the allocation without using the existing reserves */ Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] pwm: add freescale ftm pwm driver support
On Mon, Aug 26, 2013 at 07:32:23AM +, Xiubo Li-B47053 wrote:
+#define FTM_CSC_BASE0x0C
+#define FTM_CSC(_CHANNEL) \
+ (FTM_CSC_BASE + (_CHANNEL * 0x08))
I prefer lowercase variables in macros:
#define FTM_CSC(channel) \
(FTM_CSC_BASE + (channel * 8))
Yes, That's better.
Actually it should even be:
#define FTM_CSC(channel) \
(FTM_CSC_BASE + ((channel) * 8))
Just in case channel ends up being an expression.
+ ret = clk_prepare_enable(fpc-clk);
This should probably be just clk_prepare(). Or is there some reason why
you can't delay clk_enable() to the .enable() operation?
Firstly, we should be clear that the fpc-clk is chip's work clock.
If so, after the .request() is called and before .enable() is called, the
custumer will call .config(),
in which will read/write the pwm chip registers, if the module clock is still
disabled, then the system will hang up.
Okay. In that case perhaps the better thing to do is call clk_prepare()
during driver probe and only clk_enable() here.
Perhaps time_ns should be unsigned long?
Shouldn't this be same with int duty_ns and int period_ns, which are
defined by
struct pwm_ops {
...
int (*config)(struct pwm_chip *chip,
struct pwm_device *pwm,
int duty_ns, int period_ns);
...
} ?
Well, the plan is to eventually make duty_ns and period_ns unsigned int
or unsigned long because negative values don't make any sense for them.
With that in mind I think it makes sense to use the proper type here
now.
+static int fsl_pwm_config_channel(struct pwm_chip *chip,
I think you can safely drop the _channel suffix from the PWM operations.
By adding _channel suffix just for more comprehensave about the pwm's
muti-channel operation.
If this is redundant here, I will drop it.
The operations are implicitly per-channel operations. So yes, the
_channel suffix is redundant here.
+ fpc = to_fsl_chip(chip);
+
+ if (WARN_ON(!test_bit(PWMF_REQUESTED, pwm-flags)))
+ return -ESHUTDOWN;
Erm... how do you think this could ever happen? Users need to request a
PWM to obtain a struct pwm_device, in which case PWMF_REQUESTED will
always be set. There are a few other occurrences throughout the rest of
the driver that I haven't pointed out explicitly.
Does the following case is exist ?
The customer in one thread has .free(pwm_1), while in another thread,
which maybe had slept in for some reason, will call .config/.enable/.disable?
If so, as I have explained before, if the pwm_1 has been freed, the module
clock maybe
disabled too, so if the .config is call the system will hang up.
While the above could possibly happen, there's no way the core could
prevent it. And your explicit test couldn't either. So what usually
happens is that a driver requests a PWM device and then has exclusive
access to it. Any other driver that wants to use the same PWM device
can't because it will get an -EBUSY return.
So in your hypothetical case above, if one driver does stuff like that
with a PWM device then that's a driver bug, not something the PWM core
should be required to handle.
+static int fsl_pwm_parse_dt(struct fsl_pwm_chip *fpc) {
[...]
+ int ret = 0;
+ u32 chs[FTM_MAX_CHANNEL];
+ struct device_node *np = fpc-pdev-dev.of_node;
+
+ ret = of_property_read_u32(np, fsl,pwm-clk-ps,
+fpc-clk_ps);
+ if (ret 0) {
+ dev_err(fpc-pdev-dev,
+ failed to get pwm
+ clk prescaler : %d\n,
+ ret);
Perhaps it's more useful to mention the missing property explicitly in
the error message:
dev_err(fpc-chip.dev,
failed to parse \fsl,pwm-clk-ps\ property: %d\n,
ret);
Whil I think the following is better in code.
dev_err(fpc-chip.dev,
failed to parse fsl,pwm-clk-ps property: %d\n,
ret);
Why? You're quoting which property failed to parse so you should use the
correct character for quoting, which is either the apostrophe (') or the
quotation mark ().
Thierry
pgptki_BHUf8h.pgp
Description: PGP signature
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On 27/08/2013 08:16, boris brezillon : On 27/08/2013 05:55, Stephen Warren wrote: On 08/26/2013 11:01 AM, boris brezillon wrote: Hello Stephen, On 26/08/2013 18:50, Stephen Warren wrote: On 08/24/2013 03:35 PM, Boris BREZILLON wrote: Add a new parameter to support deglitch filter configuration. A deglitch filter works like a debounce filter but with a smaller delay (nanoseconds). Why not use the existing debounce property, just with a small delay specified. It seems like that's exactly what the property is for? That's one of the question I asked in my cover letter :-) Indeed the at91 deglitch filter delay is not configurable and is statically assigned to half a master clk cycle (if master clk = 133MHz - 8 ns). The debounce property argument is currently expressed in usecs. This will result in always selecting the debounce filter (which is also available on at91 SoCs) over the deglitch filter. Could we add a flag in the deglitch argument to specify the delay unit (nsecs or usecs) ? If the value is hard-coded in HW, why not use non-zero (or 1) to enable and zero to disable? Indeed at91 pins support both deglitch and debounce filter and I have to choose between the two given the argument value (in usec). Here's what I can do: if (arg = 1/2 * slowclock)/* debounce case */ /* choose debounce filter and configure the delay according to the given argument value */ else /* deglitch case */ /* choose deglitch filter */ Slow clock is running at 32KHz which gives a 30 usec clock cycle. I am not in favor for this kind of complicated heuristic. Deglitch and Debounce filters are different features in at91 (even if they pursuit the same goal). So I do prefer to let the user choose which feature is preferred for his application and add a different flag. (this kind of thing is why I'm not convinced that generic pinconf works so well... What if we need psecs in the future?) Should I keep the at91 native pinconf binding and add the missing flags to this binding (OUTPUT configuration flags) ? This was another question I asked in my cover letter: wether or not the generic pinconf binding should be used. The question is: how much this generic pinconf is... well... generic! And it is not a answer I can give. On the other hand, if the generic is not going to overcome the native pinctrl, I do not feel like switching to this at the cost of changing the whole dtsi/dts entries that we already have. So, it is more to Linus and Stephen to give us clues about this... Bye, -- Nicolas Ferre -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the scsi tree with the infiniband tree
Hi James,
Today's linux-next merge of the scsi tree got a conflict in
drivers/infiniband/ulp/iser/iser_initiator.c between commit b7f04513090c
(IB/iser: Accept session-cmds_max from user space) from the infiniband
tree and commit 6a06a4b8cff8 ([SCSI] IB/iser: Add Discovery support)
from the scsi tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/infiniband/ulp/iser/iser_initiator.c
index bdc38f4,b31fa1d..000
--- a/drivers/infiniband/ulp/iser/iser_initiator.c
+++ b/drivers/infiniband/ulp/iser/iser_initiator.c
@@@ -342,10 -249,15 +343,16 @@@ static int iser_post_rx_bufs(struct isc
WARN_ON(iser_conn-ib_conn-post_recv_buf_count != 1);
WARN_ON(atomic_read(iser_conn-ib_conn-post_send_buf_count) != 0);
- iser_dbg(Initially post: %d\n, iser_conn-ib_conn-min_posted_rx);
+ if (session-discovery_sess) {
+ iser_info(Discovery session, re-using login RX buffer\n);
+ return 0;
+ } else
+ iser_info(Normal session, posting batch of RX %d buffers\n,
-ISER_MIN_POSTED_RX);
++iser_conn-ib_conn-min_posted_rx);
+
/* Initial post receive buffers */
- if (iser_post_recvm(iser_conn-ib_conn, ISER_MIN_POSTED_RX))
+ if (iser_post_recvm(iser_conn-ib_conn,
+ iser_conn-ib_conn-min_posted_rx))
return -ENOMEM;
return 0;
pgpXZ7UF6Bmq4.pgp
Description: PGP signature
Re: [PATCH 0/2] net/cadence/macb: add support for dt phy definition
Hello Dave, On 26/08/2013 22:04, David Miller wrote: From: Boris BREZILLON b.brezil...@overkiz.com Date: Thu, 22 Aug 2013 17:56:20 +0200 This patch series adds support for ethernet phy definition using device tree. This may help in moving some at91 boards to dt (some of them define an interrupt pin). Tested on samad31ek. Series applied to net-next, thanks. Could you apply, the 3rd version of this series instead ? It fixes one bug when no phy is discovered and use the appropriate address for the phy dt node. Sorry for the inconvenience. Best Regards, Boris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 0/2] net/cadence/macb: add support for dt phy definition
Hello David, Sorry, I forgot to add your email in the cc list. Do you want me to send you the whole series ? Best Regards, Boris On 27/08/2013 09:36, Boris BREZILLON wrote: Hello, This patch series adds support for ethernet phy definition using device tree. This may help in moving some at91 boards to dt (some of them define an interrupt pin). Tested on samad31ek. Best Regards, Boris Changes since v2: - fix wrong address of phy0 dt node Changes since v1: - fix wrong macb_mii_init return code when no PHY device is discovered Boris BREZILLON (2): net/cadence/macb: add support for dt phy definition ARM: at91/dt: define phy available on sama5d3 mother board arch/arm/boot/dts/sama5d3xmb.dtsi |8 ++ drivers/net/ethernet/cadence/macb.c | 48 +++ 2 files changed, 46 insertions(+), 10 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 v2 3/3] mm/hwpoison: fix return value of madvise_hwpoison
On Mon, Aug 26, 2013 at 11:41:36PM -0400, Naoya Horiguchi wrote: Date: Mon, 26 Aug 2013 23:41:36 -0400 From: Naoya Horiguchi n-horigu...@ah.jp.nec.com To: Wanpeng Li liw...@linux.vnet.ibm.com Cc: Andrew Morton a...@linux-foundation.org, Andi Kleen a...@firstfloor.org, Fengguang Wu fengguang...@intel.com, Tony Luck tony.l...@intel.com, gong.c...@linux.intel.com, linux...@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 3/3] mm/hwpoison: fix return value of madvise_hwpoison User-Agent: Mutt 1.5.21 (2010-09-15) On Tue, Aug 27, 2013 at 11:38:27AM +0800, Wanpeng Li wrote: Hi Naoya, On Mon, Aug 26, 2013 at 11:28:16PM -0400, Naoya Horiguchi wrote: On Tue, Aug 27, 2013 at 10:39:31AM +0800, Wanpeng Li wrote: The return value outside for loop is always zero which means madvise_hwpoison return success, however, this is not truth for soft_offline_page w/ failure return value. I don't understand what you want to do for what reason. Could you clarify those? int ret is defined in two place in madvise_hwpoison. One is out of for loop and its value is always zero(zero means success for madvise), the other one is in for loop. The soft_offline_page function maybe return -EBUSY and break, however, the ret out of for loop is return which means madvise_hwpoison success. Oh, I see. Thanks. I don't think such change is a good idea. The original code is obviously easy to confuse people. Why not removing redundant local variable? signature.asc Description: Digital signature
Re: [RFC PATCH 2/3] pinctrl: at91: add support for generic pinconf
On 26/08/2013 21:18, Jean-Christophe PLAGNIOL-VILLARD :
On 20:45 Mon 26 Aug , boris brezillon wrote:
Hello Jean-Christophe,
Le 26/08/2013 19:53, Jean-Christophe PLAGNIOL-VILLARD a écrit :
On 23:37 Sat 24 Aug , Boris BREZILLON wrote:
Add support for generic pin configuration to pinctrl-at91 driver.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
.../bindings/pinctrl/atmel,at91-pinctrl.txt| 43 +++-
drivers/pinctrl/Kconfig|2 +-
drivers/pinctrl/pinctrl-at91.c | 265 ++--
3 files changed, 289 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
index 7ccae49..7a7c0c4 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
@@ -18,7 +18,9 @@ mode) this pin can work on and the 'config' configures
various pad settings
such as pull-up, multi drive, etc.
Required properties for iomux controller:
-- compatible: atmel,at91rm9200-pinctrl
+- compatible: atmel,at91rm9200-pinctrl or atmel,at91sam9x5-pinctrl.
+ Add generic-pinconf to the compatible string list to use the generic pin
+ configuration syntax.
- atmel,mux-mask: array of mask (periph per bank) to describe if a pin can be
configured in this periph mode. All the periph and bank need to be describe.
@@ -83,6 +85,11 @@ Required properties for pin configuration node:
setting. The format is atmel,pins = PIN_BANK PIN_BANK_NUM PERIPH CONFIG.
The PERIPH 0 means gpio, PERIPH 1 is periph A, PERIPH 2 is periph B...
PIN_BANK 0 is pioA, PIN_BANK 1 is pioB...
+ Dependending on the presence of the generic-pinconf string in the
+ compatible property the 4th cell is:
+ * a phandle referencing a generic pin config node (refer to
+ pinctrl-bindings.txt)
+ * an integer defining the pin config (see the following description)
Bits used for CONFIG:
PULL_UP (1 0): indicate this pin need a pull up.
@@ -132,6 +139,40 @@ pinctrl@f400 {
};
};
+or
+
+pinctrl@f400 {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ compatible = atmel,at91rm9200-pinctrl, generic-pinconf,
simple-bus;
nack your break the backword compatibility
if we use a old kernel with this new dt nothing will work
as the old kernel will never known the the generic-pinconf means anything
Your're right, I didn't think of this case (old kernel with new dt).
if we want to use generic-pinconf support you *CAN NOT* use
atmel,at91rm9200-pinctrl
One.
I did not spot.
in the compatible
What about using atmel,at91xx-pinconf instead of
atmel,at91xx-pinctrl to notify
the generic pinconf compatibility (as done by single pinctrl driver) ?
no as the rm9200 IP and sam9x5 IP are only partially compatible
you MUST distinguish them
Two? WTF!
Jean-Christophe, YOU MUST NOT SCREAM in emails, okay?!
+ reg = 0xf400 0x600;
+
+ atmel,mux-mask =
+ /*A B */
+ 0x 0xffc00c3b /* pioA */
+ 0x 0x7fff3ccf /* pioB */
+ 0x 0x007f /* pioC */
+ ;
+
+ pcfg_none: pcfg_none {
+ bias-disable;
+ };
+
+ pcfg_pull_up: pcfg_pull_up {
+ bias-pullup;
+ };
+
+ /* shared pinctrl settings */
+ dbgu {
+ pinctrl_dbgu: dbgu-0 {
+ atmel,pins =
+ 1 14 0x1 pcfg_none /* PB14 periph
A */
+1 15 0x1 pcfg_pull_up;/* PB15 periph
A with pullup */
+ };
+ };
+};
+
dbgu: serial@f200 {
compatible = atmel,at91sam9260-usart;
reg = 0xf200 0x200;
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index bdb1a87..55a4f2c 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -54,7 +54,7 @@ config PINCTRL_AT91
depends on OF
depends on ARCH_AT91
select PINMUX
- select PINCONF
+ select GENERIC_PINCONF
help
Say Y here to enable the at91 pinctrl driver
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 7cce066..1994dd2 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -23,6 +23,7 @@
#include linux/gpio.h
#include linux/pinctrl/machine.h
#include linux/pinctrl/pinconf.h
+#include linux/pinctrl/pinconf-generic.h
#include linux/pinctrl/pinctrl.h
#include linux/pinctrl/pinmux.h
/* Since we request GPIOs from ourself */
@@ -32,6 +33,7 @@
#include mach/at91_pio.h
#include core.h
+#include pinconf.h
#define MAX_NB_GPIO_PER_BANK 32
@@ -85,6 +87,21 @@ enum at91_mux {
AT91_MUX_PERIPH_D = 4,
};
+struct at91_generic_pinconf {
+ unsigned long
Re: [PATCH 32/40] ARM: ux500: Delete U8500 UIB support when booting with ATAGs
On Fri, 23 Aug 2013, Linus Walleij wrote: On Fri, Aug 23, 2013 at 2:53 PM, Linus Walleij linus.wall...@linaro.org wrote: It is not true at all that all HREFs have the STUIB mounted. Hm I'm confused here... arch/arm/boot/dts/[ste-]stuib.dtsi does define this stuff so forget about the misplaced comments. For *all* HREF boards. As it is included from both [ste-]hrefprev60.dts and [ste-]hrefv60plus.dts However it is only really mounted on some of the HREFs, and the following stays valid: This detection needs to stay for now, unless we go and define in the device tree which UIB is mounted, which would be unfortunate as we can very well auto-detect it, and that makes it easier for a user to just swap the UIB and test the other toch screen (for example). So it would be really nice to keep this autodetection. What would be nice if we could mark all the STUIB as disabled in the device trees, and then augment the device tree at boot depending on if we find something at 0x44 as in this test: - /* U8500-UIB has the TC35893 at 0x44 on I2C0, the ST-UIB doesn't. */ - ret = i2c_smbus_xfer(i2c0, 0x44, 0, I2C_SMBUS_WRITE, 0, - I2C_SMBUS_QUICK, NULL); And then mark these as okay in the DT. That's pretty high-tech but I bet we can pull it off (and set a good example). Well, this stuff is possible, but it doesn't really have anything to do with this patch-set. We can reuse 'some' of this code, but we'd need to think of a new way to represent it. That coupled with the fact that the Device Tree boot doesn't use any of this stuff yet leads to believe we can keep this removal patch in the set and re-introduce the key parts when we've had a chat about the new implementation. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/1 resend] ARM: shmobile: r8a7790: add I2C support
Hi Wolfram CC Morimoto Please consider the following patch for the r8a7790 Soc. This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2. It was developed base on the renesas-devel-20130722 branch and have tested on the Lager board. V3: Using the ID tables to resolve the difference between H1 and H2. Thanks, Nguyen viet Dung Nguyen Viet Dung (1): i2c: rcar: modify I2C driver drivers/i2c/busses/i2c-rcar.c | 37 +++-- 1 file changed, 35 insertions(+), 2 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/1 resend] i2c: rcar: modify I2C driver
This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2.
Signed-off-by: Nguyen Viet Dung nv-d...@jinso.co.jp
---
drivers/i2c/busses/i2c-rcar.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 0fc5858..e08ef28 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -101,6 +101,11 @@ enum {
#define ID_ARBLOST (1 3)
#define ID_NACK(1 4)
+enum rcar_i2c_type {
+ I2C_RCAR_H1,
+ I2C_RCAR_H2,
+};
+
struct rcar_i2c_priv {
void __iomem *io;
struct i2c_adapter adap;
@@ -113,6 +118,7 @@ struct rcar_i2c_priv {
int irq;
u32 icccr;
u32 flags;
+ enum rcar_i2c_type devtype;
};
#define rcar_i2c_priv_to_dev(p)((p)-adap.dev.parent)
@@ -224,12 +230,23 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv
*priv,
u32 scgd, cdf;
u32 round, ick;
u32 scl;
+ u32 cdf_width;
if (!clkp) {
dev_err(dev, there is no peripheral_clk\n);
return -EIO;
}
+ switch (priv-devtype) {
+ default:
+ case I2C_RCAR_H1:
+ cdf_width = 2;
+ break;
+ case I2C_RCAR_H2:
+ cdf_width = 3;
+ break;
+ }
+
/*
* calculate SCL clock
* see
@@ -245,7 +262,7 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv
*priv,
* clkp : peripheral_clk
* F[] : integer up-valuation
*/
- for (cdf = 0; cdf 4; cdf++) {
+ for (cdf = 0; cdf (1 cdf_width); cdf++) {
ick = clk_get_rate(clkp) / (1 + cdf);
if (ick 2000)
goto ick_find;
@@ -287,7 +304,7 @@ scgd_find:
/*
* keep icccr value
*/
- priv-icccr = (scgd 2 | cdf);
+ priv-icccr = (scgd (cdf_width) | cdf);
return 0;
}
@@ -632,6 +649,13 @@ static int rcar_i2c_probe(struct platform_device *pdev)
bus_speed = 10; /* default 100 kHz */
if (pdata pdata-bus_speed)
bus_speed = pdata-bus_speed;
+
+ if (!pdev-id_entry) {
+ dev_err(pdev-dev, no entry\n);
+ return -ENODEV;
+ }
+ priv-devtype = pdev-id_entry-driver_data;
+
ret = rcar_i2c_clock_calculate(priv, bus_speed, dev);
if (ret 0)
return ret;
@@ -686,6 +710,14 @@ static int rcar_i2c_remove(struct platform_device *pdev)
return 0;
}
+static struct platform_device_id rcar_i2c_id_table[] = {
+ { i2c-rcar, I2C_RCAR_H1 },
+ { i2c-rcar_h1,I2C_RCAR_H1 },
+ { i2c-rcar_h2,I2C_RCAR_H2 },
+ {},
+};
+MODULE_DEVICE_TABLE(platform, rcar_i2c_id_table);
+
static struct platform_driver rcar_i2c_driver = {
.driver = {
.name = i2c-rcar,
@@ -693,6 +725,7 @@ static struct platform_driver rcar_i2c_driver = {
},
.probe = rcar_i2c_probe,
.remove = rcar_i2c_remove,
+ .id_table = rcar_i2c_id_table,
};
module_platform_driver(rcar_i2c_driver);
--
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 v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
On Thu, Aug 15, 2013 at 05:49:26PM +1000, Alexey Kardashevskiy wrote:
This is to reserve a capablity number for upcoming support
of VFIO-IOMMU DMA operations in real mode.
The last ioctl in the group which KVM_CREATE_SPAPR_TCE_IOMMU is added to
is 0xac, the next two numbers are taken - 0xad for KVM_KVMCLOCK_CTRL and
0xac was also taken by KVM_SET_ONE_REG :(
0xae for KVM_ARM_VCPU_INIT. So the KVM_CREATE_SPAPR_TCE_IOMMU ioclt gets
0xaf.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
2013/08/15 v8:
* fixed comment again
2013/08/15:
* fixed mistype in comments
* fixed commit message which says what uses ioctls 0xad and 0xae
2013/07/16:
* changed the number
2013/07/11:
* changed order in a file, added comment about a gap in ioctl number
---
include/uapi/linux/kvm.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 99c2533..bd94127 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -668,6 +668,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_IRQ_XICS 92
#define KVM_CAP_ARM_EL1_32BIT 93
#define KVM_CAP_SPAPR_MULTITCE 94
+#define KVM_CAP_SPAPR_TCE_IOMMU 95
#ifdef KVM_CAP_IRQ_ROUTING
@@ -933,6 +934,11 @@ struct kvm_s390_ucas_mapping {
#define KVM_ARM_SET_DEVICE_ADDR_IOW(KVMIO, 0xab, struct
kvm_arm_device_addr)
/* Available with KVM_CAP_PPC_RTAS */
#define KVM_PPC_RTAS_DEFINE_TOKEN _IOW(KVMIO, 0xac, struct
kvm_rtas_token_args)
+/* 0xad is taken by KVM_KVMCLOCK_CTRL */
+/* 0xae is taken by KVM_ARM_VCPU_INIT */
+/* Available with KVM_CAP_SPAPR_TCE_IOMMU */
+#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xaf, \
+ struct kvm_create_spapr_tce_iommu)
Why not use KVM_CREATE_DEVICE API for that?
/* ioctl for vm fd */
#define KVM_CREATE_DEVICE _IOWR(KVMIO, 0xe0, struct kvm_create_device)
--
1.8.3.2
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] of: Define of_irq_find_parent dummy for !defined(CONFIG_OF_IRQ)
This changes the dummy version of of_irq_find_parent to be defined when
!defined(CONFIG_OF_IRQ) instead of when !defined(CONFIG_OF). Without
this of_irq_find_parent is undefined on SPARC that defines CONFIG_OF but
not CONFIG_OF_IRQ.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
include/linux/of_irq.h |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 535cecf..d0059a9 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -83,11 +83,13 @@ static inline unsigned int irq_of_parse_and_map(struct
device_node *dev,
{
return 0;
}
+#endif /* !CONFIG_OF */
+
+#endif /* __OF_IRQ_H */
+#if !defined(CONFIG_OF_IRQ)
static inline void *of_irq_find_parent(struct device_node *child)
{
return NULL;
}
-#endif /* !CONFIG_OF */
-
-#endif /* __OF_IRQ_H */
+#endif /* !CONFIG_OF_IRQ */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 13/20] mm, hugetlb: mm, hugetlb: unify chg and avoid_reserve to use_reserve
On Mon, Aug 26, 2013 at 06:39:35PM +0530, Aneesh Kumar K.V wrote:
Joonsoo Kim iamjoonsoo@lge.com writes:
Currently, we have two variable to represent whether we can use reserved
page or not, chg and avoid_reserve, respectively. With aggregating these,
we can have more clean code. This makes no functinoal difference.
Signed-off-by: Joonsoo Kim iamjoonsoo@lge.com
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 22ceb04..8dff972 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -531,8 +531,7 @@ static struct page *dequeue_huge_page_node(struct
hstate *h, int nid)
static struct page *dequeue_huge_page_vma(struct hstate *h,
struct vm_area_struct *vma,
- unsigned long address, int avoid_reserve,
- long chg)
+ unsigned long address, bool use_reserve)
{
struct page *page = NULL;
struct mempolicy *mpol;
@@ -546,12 +545,10 @@ static struct page *dequeue_huge_page_vma(struct
hstate *h,
* A child process with MAP_PRIVATE mappings created by their parent
* have no page reserves. This check ensures that reservations are
* not stolen. The child may still get SIGKILLed
+* Or, when parent process do COW, we cannot use reserved page.
+* In this case, ensure enough pages are in the pool.
*/
- if (chg h-free_huge_pages - h-resv_huge_pages == 0)
- return NULL;
This hunk would be much easier if you were changing.
if (!vma_has_reserves(vma)
h-free_huge_pages - h-resv_huge_pages == 0)
goto err;
ie, !vma_has_reserves(vma) == !use_reserve.
So may be a patch rearragment would help ?. But neverthless.
I think that current form is better since use_reserve is not same as
vma_has_reserves(). I changed the call site of vma_has_reserves() to chg in
previous patch. In this patch, use_reserve in alloc_huge_page is made
by chg and avoid_reserve and is passed to dequeue_huge_page_vma(). So changing
in dequeue_huge_page_vma() is trivial.
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 14/20] mm, hugetlb: call vma_needs_reservation before entering alloc_huge_page()
@@ -2504,6 +2498,8 @@ static int hugetlb_cow(struct mm_struct *mm, struct
vm_area_struct *vma,
struct hstate *h = hstate_vma(vma);
struct page *old_page, *new_page;
int outside_reserve = 0;
+ long chg;
+ bool use_reserve;
unsigned long mmun_start; /* For mmu_notifiers */
unsigned long mmun_end; /* For mmu_notifiers */
@@ -2535,7 +2531,17 @@ retry_avoidcopy:
/* Drop page_table_lock as buddy allocator may be called */
spin_unlock(mm-page_table_lock);
- new_page = alloc_huge_page(vma, address, outside_reserve);
+ chg = vma_needs_reservation(h, vma, address);
+ if (chg == -ENOMEM) {
why not
if (chg 0) ?
Should we try to unmap the page from child and avoid cow here ?. May be
with outside_reserve = 1 we will never have vma_needs_reservation fail.
Any how it would be nice to document why this error case is different
from alloc_huge_page error case.
I guess patch 16 address this . So if we do if (chg 0) we are good
here.
Okay! I will change it.
Reviewed-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] net/cadence/macb: add support for dt phy definition
On 27/08/2013 09:37, Boris BREZILLON :
The macb driver only handle PHY description through platform_data
(macb_platform_data).
Thus, when using dt you cannot define phy properties like phy address or
phy irq pin.
This patch makes use of the of_mdiobus_register to add support for
phy device definition using dt.
A fallback to the autoscan procedure is added in case there is no phy
devices defined in dt.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/net/ethernet/cadence/macb.c | 48 +++
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index e866608..393afeb 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -27,6 +27,7 @@
#include linux/phy.h
#include linux/of.h
#include linux/of_device.h
+#include linux/of_mdio.h
#include linux/of_net.h
#include linux/pinctrl/consumer.h
@@ -275,7 +276,7 @@ static int macb_mii_probe(struct net_device *dev)
phydev = phy_find_first(bp-mii_bus);
if (!phydev) {
netdev_err(dev, no PHY found\n);
- return -1;
+ return -ENXIO;
}
pdata = dev_get_platdata(bp-pdev-dev);
@@ -314,6 +315,7 @@ static int macb_mii_probe(struct net_device *dev)
int macb_mii_init(struct macb *bp)
{
struct macb_platform_data *pdata;
+ struct device_node *np;
int err = -ENXIO, i;
/* Enable management port */
@@ -335,26 +337,52 @@ int macb_mii_init(struct macb *bp)
bp-mii_bus-parent = bp-dev-dev;
pdata = bp-pdev-dev.platform_data;
- if (pdata)
- bp-mii_bus-phy_mask = pdata-phy_mask;
-
bp-mii_bus-irq = kmalloc(sizeof(int)*PHY_MAX_ADDR, GFP_KERNEL);
if (!bp-mii_bus-irq) {
err = -ENOMEM;
goto err_out_free_mdiobus;
}
- for (i = 0; i PHY_MAX_ADDR; i++)
- bp-mii_bus-irq[i] = PHY_POLL;
-
dev_set_drvdata(bp-dev-dev, bp-mii_bus);
- if (mdiobus_register(bp-mii_bus))
+ np = bp-pdev-dev.of_node;
+ if (np) {
+ /* try dt phy registration */
+ err = of_mdiobus_register(bp-mii_bus, np);
+
+ /* fallback to standard phy registration if no phy were
+* found during dt phy registration
+*/
+ if (!err !phy_find_first(bp-mii_bus)) {
+ for (i = 0; i PHY_MAX_ADDR; i++) {
+ struct phy_device *phydev;
+
+ phydev = mdiobus_scan(bp-mii_bus, i);
+ if (IS_ERR(phydev)) {
+ err = PTR_ERR(phydev);
+ break;
+ }
+ }
+
+ if (err)
+ goto err_out_unregister_bus;
+ }
+ } else {
+ for (i = 0; i PHY_MAX_ADDR; i++)
+ bp-mii_bus-irq[i] = PHY_POLL;
+
+ if (pdata)
+ bp-mii_bus-phy_mask = pdata-phy_mask;
+
+ err = mdiobus_register(bp-mii_bus);
+ }
+
+ if (err)
goto err_out_free_mdio_irq;
- if (macb_mii_probe(bp-dev) != 0) {
+ err = macb_mii_probe(bp-dev);
+ if (err)
goto err_out_unregister_bus;
- }
return 0;
--
Nicolas Ferre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] ARM: at91/dt: define phy available on sama5d3 mother board
On 27/08/2013 09:39, Boris BREZILLON :
This patch describe the phy used on atmel sama5d3 mother board:
- phy address
- phy interrupt pin
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/boot/dts/sama5d3xmb.dtsi |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d3xmb.dtsi
b/arch/arm/boot/dts/sama5d3xmb.dtsi
index 8a9e05d..dba739b 100644
--- a/arch/arm/boot/dts/sama5d3xmb.dtsi
+++ b/arch/arm/boot/dts/sama5d3xmb.dtsi
@@ -81,6 +81,14 @@
macb1: ethernet@f802c000 {
phy-mode = rmii;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ phy0: ethernet-phy@1 {
+ interrupt-parent = pioE;
+ interrupts = 30 IRQ_TYPE_EDGE_FALLING;
+ reg = 1;
+ };
};
pinctrl@f200 {
--
Nicolas Ferre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v5] gpio: pcf857x: Add OF support
Add DT bindings for the pcf857x-compatible chips and parse the device
tree node in the driver.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
.../devicetree/bindings/gpio/gpio-pcf857x.txt | 71 ++
drivers/gpio/gpio-pcf857x.c| 44 +++---
2 files changed, 107 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
Changes since v4:
- Don't try to get ngpio from of_device_id data, we already get it from
i2c_device_id
Changes since v3:
- Get rid of the #ifdef CONFIG_OF in the probe function
- Give DT node priority over platform data
Changes since v2:
- Replace mention about interrupts software configuration in DT bindings
documentation with an explanation of the hardware configuration.
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
new file mode 100644
index 000..d261391
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
@@ -0,0 +1,71 @@
+* PCF857x-compatible I/O expanders
+
+The PCF857x-compatible chips have quasi-bidirectional I/O pins that can be
+driven high by a pull-up current source or driven low to ground. This combines
+the direction and output level into a single bit per pin, which can't be read
+back. We can't actually know at initialization time whether a pin is configured
+(a) as output and driving the signal low/high, or (b) as input and reporting a
+low/high value, without knowing the last value written since the chip came out
+of reset (if any). The only reliable solution for setting up pin direction is
+thus to do it explicitly.
+
+Required Properties:
+
+ - compatible: should be one of the following.
+- maxim,max7328: For the Maxim MAX7378
+- maxim,max7329: For the Maxim MAX7329
+- nxp,pca8574: For the NXP PCA8574
+- nxp,pca8575: For the NXP PCA8575
+- nxp,pca9670: For the NXP PCA9670
+- nxp,pca9671: For the NXP PCA9671
+- nxp,pca9672: For the NXP PCA9672
+- nxp,pca9673: For the NXP PCA9673
+- nxp,pca9674: For the NXP PCA9674
+- nxp,pca9675: For the NXP PCA9675
+- nxp,pcf8574: For the NXP PCF8574
+- nxp,pcf8574a: For the NXP PCF8574A
+- nxp,pcf8575: For the NXP PCF8575
+- ti,tca9554: For the TI TCA9554
+
+ - reg: I2C slave address.
+
+ - gpio-controller: Marks the device node as a gpio controller.
+ - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
+cell specifies GPIO flags, as defined in dt-bindings/gpio/gpio.h. Only
the
+GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+
+Optional Properties:
+
+ - pins-initial-state: Bitmask that specifies the initial state of each pin.
+ When a bit is set to zero, the corresponding pin will be initialized to the
+ input (pulled-up) state. When the bit is set to one, the pin will be
+ initialized the the low-level output state. If the property is not specified
+ all pins will be initialized to the input state.
+
+ The I/O expander can detect input state changes, and thus optionally act as
+ an interrupt controller. When the expander interrupt pin is connected all the
+ following properties must be set. For more information please see the
+ interrupt controller device tree bindings documentation available at
+ Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
+
+ - interrupt-controller: Identifies the node as an interrupt controller.
+ - #interrupt-cells: Number of cells to encode an interrupt source, shall be
2.
+ - interrupt-parent: phandle of the parent interrupt controller.
+ - interrupts: Interrupt specifier for the controllers interrupt.
+
+
+Please refer to gpio.txt in this directory for details of the common GPIO
+bindings used by client devices.
+
+Example: PCF8575 I/O expander node
+
+ pcf8575: gpio@20 {
+ compatible = nxp,pcf8575;
+ reg = 0x20;
+ interrupt-parent = irqpin2;
+ interrupts = 3 0;
+ gpio-controller;
+ #gpio-cells = 2;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 9e61bb0..864dd8c 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -26,6 +26,8 @@
#include linux/irqdomain.h
#include linux/kernel.h
#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/slab.h
#include linux/spinlock.h
#include linux/workqueue.h
@@ -50,6 +52,27 @@ static const struct i2c_device_id pcf857x_id[] = {
};
MODULE_DEVICE_TABLE(i2c, pcf857x_id);
+#ifdef CONFIG_OF
+static const struct of_device_id pcf857x_of_table[] = {
+ { .compatible = nxp,pcf8574 },
+ { .compatible = nxp,pcf8574a },
+ { .compatible = nxp,pca8574 },
+ { .compatible = nxp,pca9670 },
+ {
Re: [PATCH v3 0/3] HID: Win 8 multitouch panels detection in core
On Mon, 26 Aug 2013, Srinivas Pandruvada wrote: Srinivas, I still did not added your tested-by as I made minors modifications of the patches 1 and 2. Now only the patch 1 will impact sensor_hub, and patch 2 will not impact this. Maybe just wait for Henrik to put his Reviewed-by before giving one last test. Here goes: Reviewed-by: Henrik Rydberg rydb...@euromail.se Thanks guys. Not applying this just yet, waiting for Tested-by: from Srinivas. Tested-by: Srinivas Pandruvadasrinivas.pandruv...@linux.intel.com Applied, thanks everybody. -- 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 0/3] perf ui/gtk: Separate out GTK code to a shared object (v4)
Hi Arnaldo, Sorry for late reply. On Mon, 19 Aug 2013 12:17:34 -0300, Arnaldo Carvalho de Melo wrote: Em Mon, Aug 19, 2013 at 11:05:00AM -0300, Arnaldo Carvalho de Melo escreveu: But I expected that after the first patch 'perf --gtk' would work, and it doesn't. Now even after I applied the whole series I don't get --gtk to work, neither as a non-root nor as root :-\ Investigating... Somehow I expected ~/lib64/ was in the ld library path, it was not, duh, after I added it, and applied all three patches, it works as expected, so can we: 1. combine the three patches into just one so that we keep the 'perf report --gtk' bisectable? 2. add a patch to warn the user when '--gtk' is specified but no libperf-gtk.so file is found in the loader library path? Hmm.. makes sense. I'll do the option 1 (include the warning). Thanks, Namhyung -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] host1x: hdmi: Make sure clock is enabled before dumping registers
On Tue, Jul 30, 2013 at 11:35:03AM +0300, Mikko Perttunen wrote: The debugfs register dumping function did not enable the HDMI clock. This led to a possible system hang when reading the debugfs entry while no HDMI cable was connected to the system. This patch makes sure that the clock is enabled during the read. Signed-off-by: Mikko Perttunen mperttu...@nvidia.com --- drivers/gpu/host1x/drm/hdmi.c | 7 +++ 1 file changed, 7 insertions(+) Applied, thanks. Thierry pgpqIlSc35HRB.pgp Description: PGP signature
Re: [PATCH 10/13] tracing/uprobes: Fetch args before reserving a ring buffer
Hi Steven, On Thu, 22 Aug 2013 21:08:30 -0400, Steven Rostedt wrote: On Fri, 23 Aug 2013 07:57:15 +0800 zhangwei(Jovi) jovi.zhang...@huawei.com wrote: What about creating a per cpu buffer when uprobes are registered, and delete them when they are finished? Basically what trace_printk() does if it detects that there are users of trace_printk() in the kernel. Note, it does not deallocate them when finished, as it is never finished until reboot ;-) -- Steve I also thought out this approach, but the issue is we cannot fetch user memory into per-cpu buffer, because use per-cpu buffer should under preempt disabled, and fetching user memory could sleep. Actually, we could create a per_cpu mutex to match the per_cpu buffers. This is not unlike what we do in -rt. int cpu; struct mutex *mutex; void *buf; /* * Use per cpu buffers for fastest access, but we might migrate * So the mutex makes sure we have sole access to it. */ cpu = raw_smp_processor_id(); mutex = per_cpu(uprobe_cpu_mutex, cpu); buf = per_cpu(uprobe_cpu_buffer, cpu); mutex_lock(mutex); store_trace_args(..., buf,...); mutex_unlock(mutex); Great! I'll go with this approach. Is it OK to you, Masami? Thanks, Namhyung -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 09/33] ARM: ux500: Supply the I2C clocks lookup to the DBX500 DT
On Fri, 23 Aug 2013, Mark Rutland wrote: On Fri, Aug 23, 2013 at 08:56:07AM +0100, Lee Jones wrote: I had a short chat with Rob last night about this. I'm going to loop him in to the conversation, as he wrote the binding. When most of the other clocks that we deal with are being requested, they rely on being index zero: drivers/i2c/busses/i2c-nomadik.c: dev-clk = clk_get(adev-dev, NULL); Look at drivers/clk/clkdev.c, there's some fuzzy matching involved when you pass NULL as connection id. Yes, I've been looking at that. This is why it works currently. I think I need to change all of the drivers to specify which clock they want. At the moment that 'fuzzy matching' is what's saving us. If anyone were to change our DTS file to match what the binding says, then it would cease to work. I'm guessing this is the same for all other DTS files too: I think if anything, the binding document(s) should be updated to describe that apb_pclk is referred to by name, and the names of the other clocks should be described in the specific device bindings. We can then modify the drivers which grab clock 0 to explicitly grab the first clock by name, and backwards compatibility should not be broken. I don't believe any other OS has implemented the common clock bindings, and we've never supported the binding as described. Let's correct the de-facto standard into a standard by decree. I think we need to respect, or at least take into consideration the reason for the original 'de-facto' standard. Other OSes shouldn't be forced to provide a named clock request in order to obtain 'apb_pclk'. If the binding says it should be first, then perhaps we should do just that. It's simply a matter of naming all subsequent clocks related to AMBA devices. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC PATCH 00/11] trace-cmd: Support the feature recording trace data of guests on the host
Hi Steven, (2013/08/26 23:22), Steven Rostedt wrote: On Mon, 26 Aug 2013 10:46:38 +0900 Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote: The --date option is used because the two machines are not in sync with the trace time stamp. What the date option does, is to sync the timestamp up with the gettimeofday and the output reports that. This allows the two boxes to report information that is relatively close to how the two interacted. Oh, I didn't know the --date option. As you mentioned, we can merge trace data in chronological order by using --date option if the times of those machines are synchronized by NTP. If the guest and the host have the same clock, then the --date option is not needed and the two should be able to be merged normally. No, we can not assure that the guest and the host have the same clock even if it is running on the same physical machine, because both kernel doesn't share it, there is some difference between them. So, we still need time synchronizing guest-host by NTP and --date option. However, there are cases that times of those machines cannot be synchronized. For example, although multiple users can run guests on virtualization environments (e.g. multi-tenant cloud hosting), there are no guarantee that they use the same NTP server. Moreover, even if the times are synchronized, trace data cannot exactly be merged because the NTP-synchronized time granularity may not be enough fine for sorting guest-host switching events. Right, unless there's some other means no synchronize between boxes, this is currently the best we have. I'm considering that trace data use x86-tsc as timestamp in order to merge trace data. By using x86-tsc, we can merge trace data even if time of those machines is not synchronized. And the precision will be enough for understanding operations of guests and host. However, TSC values on a guest are not equal to the values on the host because TSC_guest = TSC_host + TSC_offset. This series actually doesn't support TSC offset, but I'd like to add such feature to fix host/guest clock difference in the next series. TSC offset values can be gotten as write_tsc_offset trace event from kernel-3.11. (see https://lkml.org/lkml/2013/6/12/72) How do you think about this merging feature? Thanks, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC PATCH 07/11] [CLEANUP] trace-cmd: Split out binding a port and fork reader from open_udp()
(2013/08/26 23:37), Steven Rostedt wrote:
On Mon, 26 Aug 2013 10:48:15 +0900
Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote:
+static int open_udp(const char *node, const char *port, int *pid,
+ int cpu, int pagesize, int start_port)
+{
+ int sfd;
+ int num_port;
+
+ num_port = udp_bind_a_port(start_port, sfd);
+ if (num_port 0)
+ return num_port;
I don't see how num_port could be less than zero.
I think so, but trace-cmd checks whether udp_port is less than zero or
not in create_all_readers().
May I submit the removal patch?
It's not a critical path, the check is fine. As there was a check, I
was thinking that you were expecting it to pass an error which it never
did.
Perhaps just add a comment stating that udp_bind_a_port() currently
does not return an error, but if that changes in the future, we have a
check for it now.
That way a reviewer of the code does not get confused by it.
OK, I'll delete the check and add comment as follows:
/*
* udp_bind_a_port() currently does not return an error, but if that
* changes in the future, we have a check for it now.
*/
num_port = udp_bind_a_port(start_port, sfd);
Thanks,
Yoshihiro YUNOMAE
--
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae...@hitachi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/10] KVM: PPC: reserve a capability number for multitce support
On Tue, 2013-08-27 at 09:41 +0300, Gleb Natapov wrote: Oh and Alexey mentions that there are two capabilities and you only applied one :-) Another one is: [PATCH v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO ? Yes, thanks ! Cheers, Ben. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] usb: renesas_usbhs: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with pdev-dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/usb/renesas_usbhs/common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index cfd2050..b097aa3 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -499,7 +499,7 @@ static int usbhs_probe(struct platform_device *pdev)
goto probe_end_fifo_exit;
/* dev_set_drvdata should be called after usbhs_mod_init */
- dev_set_drvdata(pdev-dev, priv);
+ platform_set_drvdata(pdev, priv);
/*
* deviece reset here because
--
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/
[PATCH 2/4] usb: r8a66597-hcd: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with pdev-dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/usb/host/r8a66597-hcd.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c
index a6fd8f5..90a 100644
--- a/drivers/usb/host/r8a66597-hcd.c
+++ b/drivers/usb/host/r8a66597-hcd.c
@@ -2393,7 +2393,7 @@ static const struct dev_pm_ops r8a66597_dev_pm_ops = {
static int r8a66597_remove(struct platform_device *pdev)
{
- struct r8a66597 *r8a66597 = dev_get_drvdata(pdev-dev);
+ struct r8a66597 *r8a66597 = platform_get_drvdata(pdev);
struct usb_hcd *hcd = r8a66597_to_hcd(r8a66597);
del_timer_sync(r8a66597-rh_timer);
@@ -2466,7 +2466,7 @@ static int r8a66597_probe(struct platform_device *pdev)
}
r8a66597 = hcd_to_r8a66597(hcd);
memset(r8a66597, 0, sizeof(struct r8a66597));
- dev_set_drvdata(pdev-dev, r8a66597);
+ platform_set_drvdata(pdev, r8a66597);
r8a66597-pdata = pdev-dev.platform_data;
r8a66597-irq_sense_low = irq_trigger == IRQF_TRIGGER_LOW;
--
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/
[PATCH 3/4] usb: phy-tegra-usb: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with pdev-dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/usb/phy/phy-tegra-usb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index cec0855..68bc93f 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -859,7 +859,7 @@ static int tegra_usb_phy_probe(struct platform_device *pdev)
tegra_phy-u_phy.shutdown = tegra_usb_phy_close;
tegra_phy-u_phy.set_suspend = tegra_usb_phy_suspend;
- dev_set_drvdata(pdev-dev, tegra_phy);
+ platform_set_drvdata(pdev, tegra_phy);
return 0;
}
--
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 26/33] ARM: ux500: Remove AUXDATA relating to SDI (MMC) clock-name bindings
On Sat, 24 Aug 2013, Arnd Bergmann wrote: On Friday 23 August 2013, Linus Walleij wrote: On Thu, Jun 6, 2013 at 2:17 PM, Lee Jones lee.jo...@linaro.org wrote: Signed-off-by: Lee Jones lee.jo...@linaro.org (...) /* Requires DMA bindings. */ OF_DEV_AUXDATA(arm,pl022, 0x80002000, ssp0, ssp0_plat), - OF_DEV_AUXDATA(arm,pl18x, 0x80126000, sdi0, mop500_sdi0_data), - OF_DEV_AUXDATA(arm,pl18x, 0x80118000, sdi1, mop500_sdi1_data), - OF_DEV_AUXDATA(arm,pl18x, 0x80005000, sdi2, mop500_sdi2_data), - OF_DEV_AUXDATA(arm,pl18x, 0x80114000, sdi4, mop500_sdi4_data), This cannot be done. Ulf H would beat me up if I applied this. The platform data there in the end is actually used. Especially look at mop500_sdi0_data, it contains a lot of stuff that is not yet DT:ed even (a task in its own right). But as long as we keep this pdata we can still delete ATAGs support (as per the second patch set pending) and get a clearer picture. Which parts of mop500_sdi0_data are not yet converted? I thought it was all covered months ago. Well it would have been if you hadn't have stopped my CAPs patch. ;) -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] usb: fotg210-udc: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with pdev-dev,
so we can directly pass a struct platform_device.
Signed-off-by: Libo Chen libo.c...@huawei.com
---
drivers/usb/gadget/fotg210-udc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/fotg210-udc.c b/drivers/usb/gadget/fotg210-udc.c
index 10cd18d..32db2ee 100644
--- a/drivers/usb/gadget/fotg210-udc.c
+++ b/drivers/usb/gadget/fotg210-udc.c
@@ -1076,7 +1076,7 @@ static struct usb_gadget_ops fotg210_gadget_ops = {
static int fotg210_udc_remove(struct platform_device *pdev)
{
- struct fotg210_udc *fotg210 = dev_get_drvdata(pdev-dev);
+ struct fotg210_udc *fotg210 = platform_get_drvdata(pdev);
usb_del_gadget_udc(fotg210-gadget);
iounmap(fotg210-reg);
@@ -1134,7 +1134,7 @@ static int fotg210_udc_probe(struct platform_device *pdev)
spin_lock_init(fotg210-lock);
- dev_set_drvdata(pdev-dev, fotg210);
+ platform_set_drvdata(pdev, fotg210);
fotg210-gadget.ops = fotg210_gadget_ops;
--
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/
[PATCH 0/4] usb: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with pdev-dev,
so we can directly pass a struct platform_device.
Libo Chen (4):
usb: fotg210-udc: use platform_{get,set}_drvdata()
usb: r8a66597-hcd: use platform_{get,set}_drvdata()
usb: phy-tegra-usb: use platform_{get,set}_drvdata()
usb: renesas_usbhs: use platform_{get,set}_drvdata()
drivers/usb/gadget/fotg210-udc.c |4 ++--
drivers/usb/host/r8a66597-hcd.c|4 ++--
drivers/usb/phy/phy-tegra-usb.c|2 +-
drivers/usb/renesas_usbhs/common.c |2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with the usb tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/am335x-bone.dts between commit 97238b35d5bb (usb:
musb: dsps: use proper child nodes) from the tree and commit
63f6b2550aa0 (ARM: dts: AM33XX: don't redefine OCP bus and device
nodes) from the arm-soc tree.
I fixed it up (probably incorrectly - see below) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/boot/dts/am335x-bone.dts
index a8907b5,d99be03..000
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@@ -24,132 -24,6 +24,24 @@@
reg = 0x8000 0x1000; /* 256 MB */
};
- am33xx_pinmux: pinmux@44e10800 {
- pinctrl-names = default;
- pinctrl-0 = clkout2_pin;
-
- user_leds_s0: user_leds_s0 {
- pinctrl-single,pins =
- 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a5.gpio1_21 */
- 0x58 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a6.gpio1_22 */
- 0x5c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a7.gpio1_23 */
- 0x60 (PIN_OUTPUT_PULLUP | MUX_MODE7)/*
gpmc_a8.gpio1_24 */
- ;
- };
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins =
- 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
- 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
- ;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins =
- 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
- 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
- ;
- };
-
- clkout2_pin: pinmux_clkout2_pin {
- pinctrl-single,pins =
- 0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
xdma_event_intr1.clkout2 */
- ;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins =
- /* Slave 1 */
- 0x110 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxerr.mii1_rxerr */
- 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txen.mii1_txen */
- 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxdv.mii1_rxdv */
- 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd3.mii1_txd3 */
- 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd2.mii1_txd2 */
- 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd1.mii1_txd1 */
- 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
mii1_txd0.mii1_txd0 */
- 0x12c (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_txclk.mii1_txclk */
- 0x130 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxclk.mii1_rxclk */
- 0x134 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd3.mii1_rxd3 */
- 0x138 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd2.mii1_rxd2 */
- 0x13c (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd1.mii1_rxd1 */
- 0x140 (PIN_INPUT_PULLUP | MUX_MODE0)/*
mii1_rxd0.mii1_rxd0 */
- ;
- };
-
- cpsw_sleep: cpsw_sleep {
- pinctrl-single,pins =
- /* Slave 1 reset value */
- 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
- 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
- ;
- };
-
- davinci_mdio_default: davinci_mdio_default {
-
Re: [PATCH v5] gpio: pcf857x: Add OF support
Hi Laurent,
On Tuesday 27 of August 2013 10:02:39 Laurent Pinchart wrote:
Add DT bindings for the pcf857x-compatible chips and parse the device
tree node in the driver.
Signed-off-by: Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com ---
.../devicetree/bindings/gpio/gpio-pcf857x.txt | 71
++ drivers/gpio/gpio-pcf857x.c
| 44 +++--- 2 files changed, 107 insertions(+), 8
deletions(-)
create mode 100644
Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
Changes since v4:
- Don't try to get ngpio from of_device_id data, we already get it from
i2c_device_id
Hmm, I'm not sure how this is supposed to work.
How does the I2C core resolve OF compatible name to particular entry in
id_table? I believe it simply passes NULL as the second argument of
.probe() if the device is instantiated based on OF compatible string and
not one in the legacy ID table.
Changes since v3:
- Get rid of the #ifdef CONFIG_OF in the probe function
- Give DT node priority over platform data
Changes since v2:
- Replace mention about interrupts software configuration in DT bindings
documentation with an explanation of the hardware configuration.
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt new file mode
100644
index 000..d261391
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
@@ -0,0 +1,71 @@
+* PCF857x-compatible I/O expanders
+
+The PCF857x-compatible chips have quasi-bidirectional I/O pins that
can be +driven high by a pull-up current source or driven low to
ground. This combines +the direction and output level into a single bit
per pin, which can't be read +back. We can't actually know at
initialization time whether a pin is configured +(a) as output and
driving the signal low/high, or (b) as input and reporting a +low/high
value, without knowing the last value written since the chip came out
+of reset (if any). The only reliable solution for setting up pin
direction is +thus to do it explicitly.
+
+Required Properties:
+
+ - compatible: should be one of the following.
+- maxim,max7328: For the Maxim MAX7378
+- maxim,max7329: For the Maxim MAX7329
+- nxp,pca8574: For the NXP PCA8574
+- nxp,pca8575: For the NXP PCA8575
+- nxp,pca9670: For the NXP PCA9670
+- nxp,pca9671: For the NXP PCA9671
+- nxp,pca9672: For the NXP PCA9672
+- nxp,pca9673: For the NXP PCA9673
+- nxp,pca9674: For the NXP PCA9674
+- nxp,pca9675: For the NXP PCA9675
+- nxp,pcf8574: For the NXP PCF8574
+- nxp,pcf8574a: For the NXP PCF8574A
+- nxp,pcf8575: For the NXP PCF8575
+- ti,tca9554: For the TI TCA9554
+
+ - reg: I2C slave address.
+
+ - gpio-controller: Marks the device node as a gpio controller.
+ - #gpio-cells: Should be 2. The first cell is the GPIO number and the
second +cell specifies GPIO flags, as defined in
dt-bindings/gpio/gpio.h. Only the +GPIO_ACTIVE_HIGH and
GPIO_ACTIVE_LOW flags are supported. +
+Optional Properties:
+
+ - pins-initial-state: Bitmask that specifies the initial state of
each pin. + When a bit is set to zero, the corresponding pin will be
initialized to the + input (pulled-up) state. When the bit is set to
one, the pin will be + initialized the the low-level output state. If
the property is not specified + all pins will be initialized to the
input state.
+
+ The I/O expander can detect input state changes, and thus optionally
act as + an interrupt controller. When the expander interrupt pin is
connected all the + following properties must be set. For more
information please see the + interrupt controller device tree bindings
documentation available at +
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
+
+ - interrupt-controller: Identifies the node as an interrupt
controller. + - #interrupt-cells: Number of cells to encode an
interrupt source, shall be 2. + - interrupt-parent: phandle of the
parent interrupt controller. + - interrupts: Interrupt specifier for
the controllers interrupt. +
+
+Please refer to gpio.txt in this directory for details of the common
GPIO +bindings used by client devices.
+
+Example: PCF8575 I/O expander node
+
+ pcf8575: gpio@20 {
+ compatible = nxp,pcf8575;
+ reg = 0x20;
+ interrupt-parent = irqpin2;
+ interrupts = 3 0;
+ gpio-controller;
+ #gpio-cells = 2;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 9e61bb0..864dd8c 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -26,6 +26,8 @@
#include linux/irqdomain.h
#include linux/kernel.h
#include linux/module.h
+#include linux/of.h
Re: [PATCH v5 0/4] [SCSI] sg: fix race condition in sg_open
On 08/13/2013 11:16 AM, Douglas Gilbert wrote: On 13-08-12 10:46 PM, vaughan wrote: On 08/06/2013 04:52 AM, Douglas Gilbert wrote: On 13-08-04 10:19 PM, vaughan wrote: On 08/03/2013 01:25 PM, Douglas Gilbert wrote: On 13-08-01 01:01 AM, Douglas Gilbert wrote: On 13-07-22 01:03 PM, Jörn Engel wrote: On Mon, 22 July 2013 12:40:29 +0800, Vaughan Cao wrote: There is a race when open sg with O_EXCL flag. Also a race may happen between sg_open and sg_remove. Changes from v4: * [3/4] use ERR_PTR series instead of adding another parameter in sg_add_sfp * [4/4] fix conflict for cherry-pick from v3. Changes from v3: * release o_sem in sg_release(), not in sg_remove_sfp(). * not set exclude with sfd_lock held. Vaughan Cao (4): [SCSI] sg: use rwsem to solve race during exclusive open [SCSI] sg: no need sg_open_exclusive_lock [SCSI] sg: checking sdp-detached isn't protected when open [SCSI] sg: push file descriptor list locking down to per-device locking drivers/scsi/sg.c | 178 +- 1 file changed, 83 insertions(+), 95 deletions(-) Patchset looks good to me, although I didn't test it on hardware yet. Signed-off-by: Joern Engel jo...@logfs.org James, care to pick this up? Acked-by: Douglas Gilbert dgilb...@interlog.com Tested O_EXCL with multiple processes and threads; passed. sg driver prior to this patch had leaky O_EXCL logic according to the same test. Block device passed. James, could you clean this up: drivers/scsi/sg.c:242:6: warning: unused variable ‘res’ [-Wunused-variable] Further testing suggests this patch on the sg driver is broken, so I'll rescind my ack. The case it is broken for is when a device is opened without O_EXCL. Now if, while it is open, a second thread/process tries to open the same device O_EXCL then IMO the second open should fail with EBUSY. My testing shows that O_EXCL opens properly deflect other O_EXCL opens. Hi Doug, My test don't have this issue. The routine is something as below: I start three opens without O_EXCL, wait 30s each, and open with O_EXCL|O_NONBLOCK, it failed with EBUSY. And I also call myopen with/without O_EXCL many times in background at the same time, and the test is passed. I don't know why it failed in your test. Usage: myopen [-e][-n][-d delay] -f file -e: exclude -n: nonblock -d: delay N seconds and then close. [root@vacaowol5 16835013]# ./myopen -f /dev/sg5 -d 30 [1] 3417 [root@vacaowol5 16835013]# ./myopen -f /dev/sg5 -d 30 [2] 3418 [root@vacaowol5 16835013]# ./myopen -f /dev/sg5 -d 30 [3] 3419 [root@vacaowol5 16835013]# cat /proc/scsi/sg/debug max_active_device=6(origin 1) def_reserved_size=32768 device=sg5 scsi5 chan=0 id=1 lun=0 em=0 sg_tablesize=55 excl=0 FD(1): timeout=6ms bufflen=32768 (res)sgat=1 low_dma=0 cmd_q=0 f_packid=0 k_orphan=0 closed=0 No requests active FD(2): timeout=6ms bufflen=32768 (res)sgat=1 low_dma=0 cmd_q=0 f_packid=0 k_orphan=0 closed=0 No requests active FD(3): timeout=6ms bufflen=32768 (res)sgat=1 low_dma=0 cmd_q=0 f_packid=0 k_orphan=0 closed=0 No requests active [root@vacaowol5 16835013]# ./myopen -e -n -f /dev/sg5 -d 30 [4] 3422 [3422:3351] /dev/sg5:exclude: Device or resource busy [4]+ Exit 1 ./myopen -e -n -f /dev/sg5 -d 30 [root@vacaowol5 16835013]# cat /proc/scsi/sg/debug max_active_device=6(origin 1) def_reserved_size=32768 device=sg5 scsi5 chan=0 id=1 lun=0 em=0 sg_tablesize=55 excl=0 FD(1): timeout=6ms bufflen=32768 (res)sgat=1 low_dma=0 cmd_q=0 f_packid=0 k_orphan=0 closed=0 No requests active FD(2): timeout=6ms bufflen=32768 (res)sgat=1 low_dma=0 cmd_q=0 f_packid=0 k_orphan=0 closed=0 No requests active FD(3): timeout=6ms bufflen=32768 (res)sgat=1 low_dma=0 cmd_q=0 f_packid=0 k_orphan=0 closed=0 No requests active [root@vacaowol5 16835013]# cat /proc/scsi/sg/debug [1] Done./myopen -f /dev/sg5 -d 30 [2]- Done./myopen -f /dev/sg5 -d 30 [3]+ Done./myopen -f /dev/sg5 -d 30 Hi, After the initial failures about 36 hours ago, retesting yesterday and today has not produced any unexpected failures. And I have been trying hard on lk 3.10.4 and lk 3.10.5 . My test program is a bit more intense than yours and can be found in the sg3_utils beta in the News section of this page: http://sg.danny.cz/sg/ It is in the examples directory, two variants called sg_tst_excl and sg_tst_excl2 . You will need a recent gcc compiler, IOW something that can compile c++11 . gcc 4.7.3 in Ubuntu 13.04 only just manages, fedora 19 should do better with gcc 4.8.1 . The threading is implemented using pthreads so it should be reliable. Typically I run
Re: [PATCH 1/7] PCI: tegra: replace devm_request_and_ioremap by devm_ioremap_resource
On Mon, Aug 19, 2013 at 02:49:07PM -0600, Bjorn Helgaas wrote: On Mon, Aug 19, 2013 at 2:12 PM, Thierry Reding thierry.red...@gmail.com wrote: On Mon, Aug 19, 2013 at 02:04:24PM -0600, Bjorn Helgaas wrote: On Mon, Aug 19, 2013 at 6:02 AM, Thierry Reding thierry.red...@gmail.com wrote: Bjorn, how do you want to handle patches to the Tegra PCIe driver in the future? Do you want me to prepare a branch and pull from that or would you rather just take simple patches? I'm in the habit of applying patches from email, so that's easy for me. But a branch would be OK, too. Patches work for me too. Is this cleanup patch something that you'd be comfortable with applying after 3.12-rc1 or would you rather defer it to 3.13? I'm not really sure how we should manage drivers/pci/host/*. Those files are mostly arch code, and I'm not sure it's useful for me to be in the middle of managing them. I assume Stephen or somebody has a tree with the pci-tegra.c stuff that's in -next right now; it seems like it'd be simplest to just add this patch there and merge in during the v3.12 merge window. If Stephen's fine with it I suppose we could take pci-tegra.c driver changes through the Tegra tree. But I think it'd be good if we could still Cc you on patches so you're aware of what we're doing (that is the same for all drivers drivers/pci/host/*). And we're going to need your Acked-by on the patches as well. Thierry pgpp759f_tOPi.pgp Description: PGP signature
[PATCH V13 01/12] perf tools: change machine__findnew_thread() to set thread pid
Add a new parameter for 'pid' to machine__findnew_thread().
Change callers to pass 'pid' when it is known.
Note that callers sometimes want to find the main thread
which has the memory maps. The main thread has tid == pid
so the usage in that case is:
machine__findnew_thread(machine, pid, pid)
whereas the usage to find the specific thread is:
machine__findnew_thread(machine, pid, tid)
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Acked-by: David Ahern dsah...@gmail.com
---
tools/perf/builtin-inject.c | 2 +-
tools/perf/builtin-kmem.c | 3 ++-
tools/perf/builtin-kvm.c| 2 +-
tools/perf/builtin-lock.c | 3 ++-
tools/perf/builtin-sched.c | 20 +++-
tools/perf/builtin-script.c | 3 ++-
tools/perf/builtin-trace.c | 10 +++---
tools/perf/tests/code-reading.c | 4 ++--
tools/perf/tests/hists_link.c | 3 ++-
tools/perf/util/build-id.c | 7 +--
tools/perf/util/event.c | 3 ++-
tools/perf/util/machine.c | 22 +++---
tools/perf/util/machine.h | 3 ++-
tools/perf/util/session.c | 2 +-
14 files changed, 55 insertions(+), 32 deletions(-)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 1d8de2e..0d4ae1d 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -198,7 +198,7 @@ static int perf_event__inject_buildid(struct perf_tool
*tool,
cpumode = event-header.misc PERF_RECORD_MISC_CPUMODE_MASK;
- thread = machine__findnew_thread(machine, event-ip.pid);
+ thread = machine__findnew_thread(machine, event-ip.pid, event-ip.pid);
if (thread == NULL) {
pr_err(problem processing %d event, skipping it.\n,
event-header.type);
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index b49f5c5..c324778 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -305,7 +305,8 @@ static int process_sample_event(struct perf_tool *tool
__maybe_unused,
struct perf_evsel *evsel,
struct machine *machine)
{
- struct thread *thread = machine__findnew_thread(machine, event-ip.pid);
+ struct thread *thread = machine__findnew_thread(machine, event-ip.pid,
+ event-ip.pid);
if (thread == NULL) {
pr_debug(problem processing %d event, skipping it.\n,
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index 6cd4de5..47b3540 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -815,7 +815,7 @@ static int process_sample_event(struct perf_tool *tool,
if (skip_sample(kvm, sample))
return 0;
- thread = machine__findnew_thread(machine, sample-tid);
+ thread = machine__findnew_thread(machine, sample-pid, sample-tid);
if (thread == NULL) {
pr_debug(problem processing %d event, skipping it.\n,
event-header.type);
diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index 76543a4..ee33ba2 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -805,7 +805,8 @@ static int process_sample_event(struct perf_tool *tool
__maybe_unused,
struct perf_evsel *evsel,
struct machine *machine)
{
- struct thread *thread = machine__findnew_thread(machine, sample-tid);
+ struct thread *thread = machine__findnew_thread(machine, sample-pid,
+ sample-tid);
if (thread == NULL) {
pr_debug(problem processing %d event, skipping it.\n,
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index f809cc7..d8c51b2 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -724,8 +724,10 @@ static int replay_fork_event(struct perf_sched *sched,
{
struct thread *child, *parent;
- child = machine__findnew_thread(machine, event-fork.tid);
- parent = machine__findnew_thread(machine, event-fork.ptid);
+ child = machine__findnew_thread(machine, event-fork.pid,
+ event-fork.tid);
+ parent = machine__findnew_thread(machine, event-fork.ppid,
+event-fork.ptid);
if (child == NULL || parent == NULL) {
pr_debug(thread does not exist on fork event: child %p, parent
%p\n,
@@ -934,8 +936,8 @@ static int latency_switch_event(struct perf_sched *sched,
return -1;
}
- sched_out = machine__findnew_thread(machine, prev_pid);
- sched_in = machine__findnew_thread(machine, next_pid);
+ sched_out = machine__findnew_thread(machine, 0, prev_pid);
+ sched_in = machine__findnew_thread(machine, 0, next_pid);
out_events =
[PATCH V13 00/12] perf tools: some fixes and tweaks
Hi Here are some fixes and tweaks to perf tools (version 13). Changes in V13: perf tools: allow non-matching sample types Moved to be the last patch perf tools: add pid to struct thread Dropped since its been applied perf tools: add support for PERF_SAMPLE_IDENTFIER Subsumed most of 'perf tools: allow non-matching sample types' Changes in V12: perf tools: re-implement debug print function for linking python/perf.so Dropped since its been applied perf tools: add debug prints Dropped since its been applied perf tools: allow non-matching sample types Do not call perf_evlist__set_id_pos() when adding events other than the first Do not use matching_sample_types perf: make events stream always parsable Added Peter's missing Ack Added Stephane's Tested-by perf tools: add missing 'abi' member to 'struct regs_dump' Added Jiri's Ack Changes in V11: perf tools: re-implement debug print function for linking python/perf.so New patch split from perf tools: add debug prints perf tools: add debug prints Changed to use graph_dotted_line Moved python/link changes to separate patch Added Namhyung's Ack perf tools: change machine__findnew_thread() to set thread pid Added explanation of main thread lookup to commit message perf tools: tidy up sample parsing overflow checking Added Jiri's Ack perf tools: remove unnecessary callchain validation Added Namhyung's Ack perf tools: remove references to struct ip_event Added Namhyung's Ack perf tools: move perf_evlist__config() to a new source file Added Namhyung's Ack perf tools: add missing 'abi' member to 'struct regs_dump' New patch perf tools: expand perf_event__synthesize_sample() Adjusted for new 'abi' member of 'struct regs_dump' perf tools: add a function to calculate sample event size Adjusted for new 'abi' member of 'struct regs_dump' perf tools: add a sample parsing test Adjusted for new 'abi' member of 'struct regs_dump' Changes in V10: Re-based on: perf/core branch of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git commit 207353be1574027c151609a31167ac5919a056c8: perf tools: Remove filter parameter of thread__find_addr_map() perf tools: add debug prints Changed to use macros perf tools: add pid to struct thread Added David's Ack perf tools: change machine__findnew_thread() to set thread pid Added David's Ack perf tools: remove references to struct ip_event Also remove from hists_link.c perf tools: move struct ip_event Dropped since it is covered by perf tools: remove references to struct ip_event perf tools: add a sample parsing test Fix missing sample comparison for PERF_SAMPLE_READ Changes in V9: perf: Update perf_event_type documentation Dropped since its been applied perf tools: tidy up sample parsing overflow checking Changed to use a single overflow function Updated for PERF_SAMPLE_READ perf: make events stream always parsable Added more about sample parsing to the commit message perf tools: add support for PERF_SAMPLE_IDENTFIER When selecting PERF_SAMPLE_IDENTFIER, ensure PERF_SAMPLE_ID is deselected perf tools: expand perf_event__synthesize_sample() Updated for PERF_SAMPLE_READ perf tools: add a function to calculate sample event size Updated for PERF_SAMPLE_READ perf tools: add a sample parsing test Updated for PERF_SAMPLE_READ Changes in V8: perf tools: add debug prints Fixed Python link errors perf tools: move perf_evlist__config() to a new source file New Patch to avoid Python link errors perf tools: add support for PERF_SAMPLE_IDENTFIER Adjustments due to patch above Changes in V7: perf: Update perf_event_type documentation Proposed new patch from Peter Zijlstra perf: make events stream always parsable Adjustments due to patch above perf tools: tidy up sample parsing overflow checking Change to a single overflow function Amend comment perf tools: add a function to calculate sample event size New patch perf tools: add a sample parsing test
[PATCH V13 09/12] perf tools: expand perf_event__synthesize_sample()
Expand perf_event__synthesize_sample() to handle all
sample format bits.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/builtin-inject.c | 4 +-
tools/perf/util/event.h | 1 +
tools/perf/util/evsel.c | 95 -
3 files changed, 97 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index ffacd46..9b336fd 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -301,7 +301,9 @@ found:
sample_sw.period = sample-period;
sample_sw.time = sample-time;
perf_event__synthesize_sample(event_sw, evsel-attr.sample_type,
- sample_sw, false);
+ evsel-attr.sample_regs_user,
+ evsel-attr.read_format, sample_sw,
+ false);
build_id__mark_dso_hit(tool, event_sw, sample_sw, evsel, machine);
return perf_event__repipe(tool, event_sw, sample_sw, machine);
}
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index f959801..1c80e13 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -230,6 +230,7 @@ int perf_event__preprocess_sample(const union perf_event
*self,
const char *perf_event__name(unsigned int id);
int perf_event__synthesize_sample(union perf_event *event, u64 type,
+ u64 sample_regs_user, u64 read_format,
const struct perf_sample *sample,
bool swapped);
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 1184188..7d62373 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1416,7 +1416,6 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
}
if (type PERF_SAMPLE_REGS_USER) {
- /* First u64 tells us if we have any regs in sample. */
OVERFLOW_CHECK_u64(array);
data-user_regs.abi = *array;
array++;
@@ -1467,11 +1466,12 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
}
int perf_event__synthesize_sample(union perf_event *event, u64 type,
+ u64 sample_regs_user, u64 read_format,
const struct perf_sample *sample,
bool swapped)
{
u64 *array;
-
+ size_t sz;
/*
* used for cross-endian analysis. See git commit 65014ab3
* for why this goofiness is needed.
@@ -1544,6 +1544,97 @@ int perf_event__synthesize_sample(union perf_event
*event, u64 type,
array++;
}
+ if (type PERF_SAMPLE_READ) {
+ if (read_format PERF_FORMAT_GROUP)
+ *array = sample-read.group.nr;
+ else
+ *array = sample-read.one.value;
+ array++;
+
+ if (read_format PERF_FORMAT_TOTAL_TIME_ENABLED) {
+ *array = sample-read.time_enabled;
+ array++;
+ }
+
+ if (read_format PERF_FORMAT_TOTAL_TIME_RUNNING) {
+ *array = sample-read.time_running;
+ array++;
+ }
+
+ /* PERF_FORMAT_ID is forced for PERF_SAMPLE_READ */
+ if (read_format PERF_FORMAT_GROUP) {
+ sz = sample-read.group.nr *
+sizeof(struct sample_read_value);
+ memcpy(array, sample-read.group.values, sz);
+ array = (void *)array + sz;
+ } else {
+ *array = sample-read.one.id;
+ array++;
+ }
+ }
+
+ if (type PERF_SAMPLE_CALLCHAIN) {
+ sz = (sample-callchain-nr + 1) * sizeof(u64);
+ memcpy(array, sample-callchain, sz);
+ array = (void *)array + sz;
+ }
+
+ if (type PERF_SAMPLE_RAW) {
+ u.val32[0] = sample-raw_size;
+ if (WARN_ONCE(swapped,
+ Endianness of raw data not corrected!\n)) {
+ /*
+* Inverse of what is done in perf_evsel__parse_sample
+*/
+ u.val32[0] = bswap_32(u.val32[0]);
+ u.val32[1] = bswap_32(u.val32[1]);
+ u.val64 = bswap_64(u.val64);
+ }
+ *array = u.val64;
+ array = (void *)array + sizeof(u32);
+
+ memcpy(array, sample-raw_data, sample-raw_size);
+ array = (void *)array + sample-raw_size;
+ }
+
+ if (type PERF_SAMPLE_BRANCH_STACK) {
+ sz = sample-branch_stack-nr * sizeof(struct branch_entry);
+ sz +=
[PATCH V13 06/12] perf tools: move perf_evlist__config() to a new source file
perf_evlist__config() must be moved to a separate source
file to avoid Python link errors when adding support for
PERF_SAMPLE_IDENTIFIER.
It is appropriate to do this because perf_evlist__config()
is a helper function for event recording. It is used by
tools to apply recording options to perf_evlist. It is
not used by the Python API.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Acked-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/Makefile | 1 +
tools/perf/util/evlist.c | 22 --
tools/perf/util/record.c | 25 +
3 files changed, 26 insertions(+), 22 deletions(-)
create mode 100644 tools/perf/util/record.c
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 7d30a7d..845cc76 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -360,6 +360,7 @@ LIB_OBJS += $(OUTPUT)util/rblist.o
LIB_OBJS += $(OUTPUT)util/intlist.o
LIB_OBJS += $(OUTPUT)util/vdso.o
LIB_OBJS += $(OUTPUT)util/stat.o
+LIB_OBJS += $(OUTPUT)util/record.o
LIB_OBJS += $(OUTPUT)ui/setup.o
LIB_OBJS += $(OUTPUT)ui/helpline.o
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 1f5105a..9d682e5 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -49,28 +49,6 @@ struct perf_evlist *perf_evlist__new(void)
return evlist;
}
-void perf_evlist__config(struct perf_evlist *evlist,
- struct perf_record_opts *opts)
-{
- struct perf_evsel *evsel;
- /*
-* Set the evsel leader links before we configure attributes,
-* since some might depend on this info.
-*/
- if (opts-group)
- perf_evlist__set_leader(evlist);
-
- if (evlist-cpus-map[0] 0)
- opts-no_inherit = true;
-
- list_for_each_entry(evsel, evlist-entries, node) {
- perf_evsel__config(evsel, opts);
-
- if (evlist-nr_entries 1)
- perf_evsel__set_sample_id(evsel);
- }
-}
-
static void perf_evlist__purge(struct perf_evlist *evlist)
{
struct perf_evsel *pos, *n;
diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
new file mode 100644
index 000..9b5ef79
--- /dev/null
+++ b/tools/perf/util/record.c
@@ -0,0 +1,25 @@
+#include evlist.h
+#include evsel.h
+#include cpumap.h
+
+void perf_evlist__config(struct perf_evlist *evlist,
+ struct perf_record_opts *opts)
+{
+ struct perf_evsel *evsel;
+ /*
+* Set the evsel leader links before we configure attributes,
+* since some might depend on this info.
+*/
+ if (opts-group)
+ perf_evlist__set_leader(evlist);
+
+ if (evlist-cpus-map[0] 0)
+ opts-no_inherit = true;
+
+ list_for_each_entry(evsel, evlist-entries, node) {
+ perf_evsel__config(evsel, opts);
+
+ if (evlist-nr_entries 1)
+ perf_evsel__set_sample_id(evsel);
+ }
+}
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V13 07/12] perf tools: add support for PERF_SAMPLE_IDENTFIER
Enable parsing of samples with sample format bit
PERF_SAMPLE_IDENTFIER. In addition, if the kernel supports
it, prefer it to selecting PERF_SAMPLE_ID thereby allowing
non-matching sample types.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/builtin-report.c | 2 +-
tools/perf/tests/mmap-basic.c | 2 +-
tools/perf/util/event.h | 3 +-
tools/perf/util/evlist.c | 111 +++---
tools/perf/util/evlist.h | 8 ++-
tools/perf/util/evsel.c | 101 --
tools/perf/util/evsel.h | 14 +-
tools/perf/util/record.c | 89 +++--
tools/perf/util/session.c | 2 +-
9 files changed, 310 insertions(+), 22 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 958a56a..9725aa3 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -365,7 +365,7 @@ static int process_read_event(struct perf_tool *tool,
static int perf_report__setup_sample_type(struct perf_report *rep)
{
struct perf_session *self = rep-session;
- u64 sample_type = perf_evlist__sample_type(self-evlist);
+ u64 sample_type = perf_evlist__combined_sample_type(self-evlist);
if (!self-fd_pipe !(sample_type PERF_SAMPLE_CALLCHAIN)) {
if (sort__has_parent) {
diff --git a/tools/perf/tests/mmap-basic.c b/tools/perf/tests/mmap-basic.c
index 5b1b5ab..c4185b9 100644
--- a/tools/perf/tests/mmap-basic.c
+++ b/tools/perf/tests/mmap-basic.c
@@ -72,7 +72,7 @@ int test__basic_mmap(void)
}
evsels[i]-attr.wakeup_events = 1;
- perf_evsel__set_sample_id(evsels[i]);
+ perf_evsel__set_sample_id(evsels[i], false);
perf_evlist__add(evlist, evsels[i]);
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 19d911c..4913339 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -53,7 +53,8 @@ struct read_event {
(PERF_SAMPLE_IP | PERF_SAMPLE_TID | \
PERF_SAMPLE_TIME | PERF_SAMPLE_ADDR | \
PERF_SAMPLE_ID | PERF_SAMPLE_STREAM_ID |\
-PERF_SAMPLE_CPU | PERF_SAMPLE_PERIOD)
+PERF_SAMPLE_CPU | PERF_SAMPLE_PERIOD | \
+PERF_SAMPLE_IDENTIFIER)
struct sample_event {
struct perf_event_headerheader;
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 9d682e5..6a629af 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -49,6 +49,21 @@ struct perf_evlist *perf_evlist__new(void)
return evlist;
}
+/**
+ * perf_evlist__set_id_pos - set the positions of event ids.
+ * @evlist: selected event list
+ *
+ * Events with compatible sample types all have the same id_pos
+ * and is_pos. For convenience, put a copy on evlist.
+ */
+void perf_evlist__set_id_pos(struct perf_evlist *evlist)
+{
+ struct perf_evsel *first = perf_evlist__first(evlist);
+
+ evlist-id_pos = first-id_pos;
+ evlist-is_pos = first-is_pos;
+}
+
static void perf_evlist__purge(struct perf_evlist *evlist)
{
struct perf_evsel *pos, *n;
@@ -79,15 +94,20 @@ void perf_evlist__delete(struct perf_evlist *evlist)
void perf_evlist__add(struct perf_evlist *evlist, struct perf_evsel *entry)
{
list_add_tail(entry-node, evlist-entries);
- ++evlist-nr_entries;
+ if (!evlist-nr_entries++)
+ perf_evlist__set_id_pos(evlist);
}
void perf_evlist__splice_list_tail(struct perf_evlist *evlist,
struct list_head *list,
int nr_entries)
{
+ bool set_id_pos = !evlist-nr_entries;
+
list_splice_tail(list, evlist-entries);
evlist-nr_entries += nr_entries;
+ if (set_id_pos)
+ perf_evlist__set_id_pos(evlist);
}
void __perf_evlist__set_leader(struct list_head *list)
@@ -349,6 +369,55 @@ struct perf_evsel *perf_evlist__id2evsel(struct
perf_evlist *evlist, u64 id)
return NULL;
}
+static int perf_evlist__event2id(struct perf_evlist *evlist,
+union perf_event *event, u64 *id)
+{
+ const u64 *array = event-sample.array;
+ ssize_t n;
+
+ n = (event-header.size - sizeof(event-header)) 3;
+
+ if (event-header.type == PERF_RECORD_SAMPLE) {
+ if (evlist-id_pos = n)
+ return -1;
+ *id = array[evlist-id_pos];
+ } else {
+ if (evlist-is_pos n)
+ return -1;
+ n -= evlist-is_pos;
+ *id = array[n];
+ }
+ return 0;
+}
+
+static struct perf_evsel *perf_evlist__event2evsel(struct perf_evlist *evlist,
+ union perf_event *event)
+{
+ struct hlist_head *head;
+ struct perf_sample_id *sid;
+ int hash;
+ u64 id;
+
+
[PATCH V13 03/12] perf tools: remove unnecessary callchain validation
Now that the sample parsing correctly checks data sizes
there is no reason for it to be done again for callchains.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Acked-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/util/callchain.c | 8
tools/perf/util/callchain.h | 5 -
tools/perf/util/session.c | 20
3 files changed, 33 deletions(-)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 4fee33b..482f680 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -21,14 +21,6 @@
__thread struct callchain_cursor callchain_cursor;
-bool ip_callchain__valid(struct ip_callchain *chain,
-const union perf_event *event)
-{
- unsigned int chain_size = event-header.size;
- chain_size -= (unsigned long)event-ip.__more_data - (unsigned
long)event;
- return chain-nr * sizeof(u64) = chain_size;
-}
-
#define chain_for_each_child(child, parent)\
list_for_each_entry(child, parent-children, siblings)
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 812d5a0..2b585bc 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -109,11 +109,6 @@ int callchain_append(struct callchain_root *root,
int callchain_merge(struct callchain_cursor *cursor,
struct callchain_root *dst, struct callchain_root *src);
-struct ip_callchain;
-union perf_event;
-
-bool ip_callchain__valid(struct ip_callchain *chain,
-const union perf_event *event);
/*
* Initialize a cursor before adding entries inside, but keep
* the previously allocated entries as a cache.
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 57b6f38..07590c3 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -997,22 +997,6 @@ static int perf_session_deliver_event(struct perf_session
*session,
}
}
-static int perf_session__preprocess_sample(struct perf_session *session,
- union perf_event *event, struct
perf_sample *sample)
-{
- if (event-header.type != PERF_RECORD_SAMPLE ||
- !(perf_evlist__sample_type(session-evlist)
PERF_SAMPLE_CALLCHAIN))
- return 0;
-
- if (!ip_callchain__valid(sample-callchain, event)) {
- pr_debug(call-chain problem with event, skipping it.\n);
- ++session-stats.nr_invalid_chains;
- session-stats.total_invalid_chains += sample-period;
- return -EINVAL;
- }
- return 0;
-}
-
static int perf_session__process_user_event(struct perf_session *session,
union perf_event *event,
struct perf_tool *tool, u64
file_offset)
{
@@ -1075,10 +1059,6 @@ static int perf_session__process_event(struct
perf_session *session,
if (ret)
return ret;
- /* Preprocess sample records - precheck callchains */
- if (perf_session__preprocess_sample(session, event, sample))
- return 0;
-
if (tool-ordered_samples) {
ret = perf_session_queue_event(session, event, sample,
file_offset);
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V13 12/12] perf tools: allow non-matching sample types
For kernels that do not support PERF_SAMPLE_IDENTIFIER,
sample types need not be identical to determine
the sample id from the event. Only the position
of the sample id needs to be the same.
Compatible sample types are ones in which the bits
defined by PERF_COMPAT_MASK are the same.
'perf_evlist__config()' forces sample types to be
compatible on that basis.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/event.h | 16
tools/perf/util/evlist.c | 25 +
tools/perf/util/evlist.h | 1 +
tools/perf/util/record.c | 5 -
4 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 93130d8..a452504 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -56,6 +56,22 @@ struct read_event {
PERF_SAMPLE_CPU | PERF_SAMPLE_PERIOD | \
PERF_SAMPLE_IDENTIFIER)
+/*
+ * Events have compatible sample types if the following bits all have the same
+ * value. This is because the order of sample members is fixed. For sample
+ * events the order is: PERF_SAMPLE_IP, PERF_SAMPLE_TID, PERF_SAMPLE_TIME,
+ * PERF_SAMPLE_ADDR, PERF_SAMPLE_ID. For non-sample events the sample members
+ * are accessed in reverse order. The order is: PERF_SAMPLE_ID,
+ * PERF_SAMPLE_STREAM_ID, PERF_SAMPLE_CPU. PERF_SAMPLE_IDENTIFIER is added for
+ * completeness but it should not be used with PERF_SAMPLE_ID. Sample types
+ * that include PERF_SAMPLE_IDENTIFIER are always compatible.
+ */
+#define PERF_COMPAT_MASK \
+ (PERF_SAMPLE_IP | PERF_SAMPLE_TID | \
+PERF_SAMPLE_TIME | PERF_SAMPLE_ADDR | \
+PERF_SAMPLE_ID | PERF_SAMPLE_STREAM_ID | \
+PERF_SAMPLE_CPU | PERF_SAMPLE_IDENTIFIER)
+
struct sample_event {
struct perf_event_headerheader;
u64 array[];
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 6a629af..1a39e3e 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -64,6 +64,31 @@ void perf_evlist__set_id_pos(struct perf_evlist *evlist)
evlist-is_pos = first-is_pos;
}
+/**
+ * perf_evlist__make_sample_types_compatible - make sample types compatible.
+ * @evlist: selected event list
+ *
+ * Events with compatible sample types all have the same id_pos and is_pos.
+ * This can be achieved by matching the bits of PERF_COMPAT_MASK.
+ */
+void perf_evlist__make_sample_types_compatible(struct perf_evlist *evlist)
+{
+ struct perf_evsel *evsel;
+ u64 compat = 0;
+
+ list_for_each_entry(evsel, evlist-entries, node)
+ compat |= evsel-attr.sample_type PERF_COMPAT_MASK;
+
+ list_for_each_entry(evsel, evlist-entries, node) {
+ evsel-attr.sample_type |= compat;
+ evsel-sample_size =
+ __perf_evsel__sample_size(evsel-attr.sample_type);
+ perf_evsel__calc_id_pos(evsel);
+ }
+
+ perf_evlist__set_id_pos(evlist);
+}
+
static void perf_evlist__purge(struct perf_evlist *evlist)
{
struct perf_evsel *pos, *n;
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index ab95d72..4d1d342 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -89,6 +89,7 @@ int perf_evlist__open(struct perf_evlist *evlist);
void perf_evlist__close(struct perf_evlist *evlist);
void perf_evlist__set_id_pos(struct perf_evlist *evlist);
+void perf_evlist__make_sample_types_compatible(struct perf_evlist *evlist);
bool perf_can_sample_identifier(void);
void perf_evlist__config(struct perf_evlist *evlist,
struct perf_record_opts *opts);
diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
index 18d73aa..6e01bf2 100644
--- a/tools/perf/util/record.c
+++ b/tools/perf/util/record.c
@@ -104,5 +104,8 @@ void perf_evlist__config(struct perf_evlist *evlist,
perf_evsel__set_sample_id(evsel, use_sample_identifier);
}
- perf_evlist__set_id_pos(evlist);
+ if (use_sample_identifier)
+ perf_evlist__set_id_pos(evlist);
+ else
+ perf_evlist__make_sample_types_compatible(evlist);
}
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V13 11/12] perf tools: add a sample parsing test
Add a test that checks that sample parsing is correctly
implemented.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/Makefile | 1 +
tools/perf/tests/builtin-test.c | 4 +
tools/perf/tests/sample-parsing.c | 316 ++
tools/perf/tests/tests.h | 1 +
4 files changed, 322 insertions(+)
create mode 100644 tools/perf/tests/sample-parsing.c
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 845cc76..ecebfd0 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -439,6 +439,7 @@ PERFLIBS = $(LIB_FILE) $(LIBLK) $(LIBTRACEEVENT)
ifneq ($(OUTPUT),)
CFLAGS += -I$(OUTPUT)
endif
+LIB_OBJS += $(OUTPUT)tests/sample-parsing.o
ifdef NO_LIBELF
EXTLIBS := $(filter-out -lelf,$(EXTLIBS))
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index f5af192..8ad9415 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -104,6 +104,10 @@ static struct test {
.func = test__code_reading,
},
{
+ .desc = Test sample parsing,
+ .func = test__sample_parsing,
+ },
+ {
.func = NULL,
},
};
diff --git a/tools/perf/tests/sample-parsing.c
b/tools/perf/tests/sample-parsing.c
new file mode 100644
index 000..77f598d
--- /dev/null
+++ b/tools/perf/tests/sample-parsing.c
@@ -0,0 +1,316 @@
+#include stdbool.h
+#include inttypes.h
+
+#include util.h
+#include event.h
+#include evsel.h
+
+#include tests.h
+
+#define COMP(m) do { \
+ if (s1-m != s2-m) { \
+ pr_debug(Samples differ at '#m'\n); \
+ return false; \
+ } \
+} while (0)
+
+#define MCOMP(m) do { \
+ if (memcmp(s1-m, s2-m, sizeof(s1-m))) {\
+ pr_debug(Samples differ at '#m'\n); \
+ return false; \
+ } \
+} while (0)
+
+static bool samples_same(const struct perf_sample *s1,
+const struct perf_sample *s2, u64 type, u64 regs_user,
+u64 read_format)
+{
+ size_t i;
+
+ if (type PERF_SAMPLE_IDENTIFIER)
+ COMP(id);
+
+ if (type PERF_SAMPLE_IP)
+ COMP(ip);
+
+ if (type PERF_SAMPLE_TID) {
+ COMP(pid);
+ COMP(tid);
+ }
+
+ if (type PERF_SAMPLE_TIME)
+ COMP(time);
+
+ if (type PERF_SAMPLE_ADDR)
+ COMP(addr);
+
+ if (type PERF_SAMPLE_ID)
+ COMP(id);
+
+ if (type PERF_SAMPLE_STREAM_ID)
+ COMP(stream_id);
+
+ if (type PERF_SAMPLE_CPU)
+ COMP(cpu);
+
+ if (type PERF_SAMPLE_PERIOD)
+ COMP(period);
+
+ if (type PERF_SAMPLE_READ) {
+ if (read_format PERF_FORMAT_GROUP)
+ COMP(read.group.nr);
+ else
+ COMP(read.one.value);
+ if (read_format PERF_FORMAT_TOTAL_TIME_ENABLED)
+ COMP(read.time_enabled);
+ if (read_format PERF_FORMAT_TOTAL_TIME_RUNNING)
+ COMP(read.time_running);
+ /* PERF_FORMAT_ID is forced for PERF_SAMPLE_READ */
+ if (read_format PERF_FORMAT_GROUP) {
+ for (i = 0; i s1-read.group.nr; i++)
+ MCOMP(read.group.values[i]);
+ } else {
+ COMP(read.one.id);
+ }
+ }
+
+ if (type PERF_SAMPLE_CALLCHAIN) {
+ COMP(callchain-nr);
+ for (i = 0; i s1-callchain-nr; i++)
+ COMP(callchain-ips[i]);
+ }
+
+ if (type PERF_SAMPLE_RAW) {
+ COMP(raw_size);
+ if (memcmp(s1-raw_data, s2-raw_data, s1-raw_size)) {
+ pr_debug(Samples differ at 'raw_data'\n);
+ return false;
+ }
+ }
+
+ if (type PERF_SAMPLE_BRANCH_STACK) {
+ COMP(branch_stack-nr);
+ for (i = 0; i s1-branch_stack-nr; i++)
+ MCOMP(branch_stack-entries[i]);
+ }
+
+ if (type PERF_SAMPLE_REGS_USER) {
+ size_t sz = hweight_long(regs_user) * sizeof(u64);
+
+ COMP(user_regs.abi);
+ if (s1-user_regs.abi
+ (!s1-user_regs.regs || !s2-user_regs.regs ||
+memcmp(s1-user_regs.regs, s2-user_regs.regs, sz))) {
+ pr_debug(Samples differ at 'user_regs'\n);
+ return false;
+ }
+ }
+
+ if (type PERF_SAMPLE_STACK_USER) {
+ COMP(user_stack.size);
+
linux-next: manual merge of the arm-soc tree with the usb tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/am335x-evm.dts between commits 97238b35d5bb (usb:
musb: dsps: use proper child nodes) and 9b3452d1fa3c (usb: musb dma:
add cppi41 dma driver) from the usb tree and commit 63f6b2550aa0 (ARM:
dts: AM33XX: don't redefine OCP bus and device nodes) from the arm-soc
tree.
I fixed it up (probably incorrectly - see below) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/boot/dts/am335x-evm.dts
index c26c16c,1a0f33e..000
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@@ -24,323 -24,6 +24,36 @@@
reg = 0x8000 0x1000; /* 256 MB */
};
- am33xx_pinmux: pinmux@44e10800 {
- pinctrl-names = default;
- pinctrl-0 = matrix_keypad_s0 volume_keys_s0 clkout2_pin;
-
- matrix_keypad_s0: matrix_keypad_s0 {
- pinctrl-single,pins =
- 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a5.gpio1_21 */
- 0x58 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a6.gpio1_22 */
- 0x64 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a9.gpio1_25 */
- 0x68 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a10.gpio1_26 */
- 0x6c (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a11.gpio1_27 */
- ;
- };
-
- volume_keys_s0: volume_keys_s0 {
- pinctrl-single,pins =
- 0x150 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
spi0_sclk.gpio0_2 */
- 0x154 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
spi0_d0.gpio0_3 */
- ;
- };
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins =
- 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
- 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
- ;
- };
-
- i2c1_pins: pinmux_i2c1_pins {
- pinctrl-single,pins =
- 0x158 (PIN_INPUT_PULLUP | MUX_MODE2)/*
spi0_d1.i2c1_sda */
- 0x15c (PIN_INPUT_PULLUP | MUX_MODE2)/*
spi0_cs0.i2c1_scl */
- ;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins =
- 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
- 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /*
uart0_txd.uart0_txd */
- ;
- };
-
- clkout2_pin: pinmux_clkout2_pin {
- pinctrl-single,pins =
- 0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3) /*
xdma_event_intr1.clkout2 */
- ;
- };
-
- nandflash_pins_s0: nandflash_pins_s0 {
- pinctrl-single,pins =
- 0x0 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad0.gpmc_ad0 */
- 0x4 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad1.gpmc_ad1 */
- 0x8 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad2.gpmc_ad2 */
- 0xc (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad3.gpmc_ad3 */
- 0x10 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad4.gpmc_ad4 */
- 0x14 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad5.gpmc_ad5 */
- 0x18 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad6.gpmc_ad6 */
- 0x1c (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_ad7.gpmc_ad7 */
- 0x70 (PIN_INPUT_PULLUP | MUX_MODE0) /*
gpmc_wait0.gpmc_wait0 */
- 0x74 (PIN_INPUT_PULLUP | MUX_MODE7) /*
gpmc_wpn.gpio0_30 */
- 0x7c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_csn0.gpmc_csn0 */
- 0x90 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_advn_ale.gpmc_advn_ale */
- 0x94 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_oen_ren.gpmc_oen_ren */
- 0x98 (PIN_OUTPUT | MUX_MODE0) /*
gpmc_wen.gpmc_wen */
- 0x9c (PIN_OUTPUT | MUX_MODE0) /*
gpmc_be0n_cle.gpmc_be0n_cle */
- ;
- };
-
- ecap0_pins: backlight_pins {
- pinctrl-single,pins =
- 0x164 0x0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out
Re: [PATCH v2 3/3] mm/hwpoison: fix return value of madvise_hwpoison
On Tue, Aug 27, 2013 at 04:05:23PM +0800, Wanpeng Li wrote: Date: Tue, 27 Aug 2013 16:05:23 +0800 From: Wanpeng Li liw...@linux.vnet.ibm.com To: Chen Gong gong.c...@linux.intel.com Cc: Naoya Horiguchi n-horigu...@ah.jp.nec.com, Andrew Morton a...@linux-foundation.org, Andi Kleen a...@firstfloor.org, Fengguang Wu fengguang...@intel.com, Tony Luck tony.l...@intel.com, linux...@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 3/3] mm/hwpoison: fix return value of madvise_hwpoison User-Agent: Mutt/1.5.21 (2010-09-15) Hi Chen, On Tue, Aug 27, 2013 at 03:37:01AM -0400, Chen Gong wrote: On Mon, Aug 26, 2013 at 11:41:36PM -0400, Naoya Horiguchi wrote: Date: Mon, 26 Aug 2013 23:41:36 -0400 From: Naoya Horiguchi n-horigu...@ah.jp.nec.com To: Wanpeng Li liw...@linux.vnet.ibm.com Cc: Andrew Morton a...@linux-foundation.org, Andi Kleen a...@firstfloor.org, Fengguang Wu fengguang...@intel.com, Tony Luck tony.l...@intel.com, gong.c...@linux.intel.com, linux...@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 3/3] mm/hwpoison: fix return value of madvise_hwpoison User-Agent: Mutt 1.5.21 (2010-09-15) On Tue, Aug 27, 2013 at 11:38:27AM +0800, Wanpeng Li wrote: Hi Naoya, On Mon, Aug 26, 2013 at 11:28:16PM -0400, Naoya Horiguchi wrote: On Tue, Aug 27, 2013 at 10:39:31AM +0800, Wanpeng Li wrote: The return value outside for loop is always zero which means madvise_hwpoison return success, however, this is not truth for soft_offline_page w/ failure return value. I don't understand what you want to do for what reason. Could you clarify those? int ret is defined in two place in madvise_hwpoison. One is out of for loop and its value is always zero(zero means success for madvise), the other one is in for loop. The soft_offline_page function maybe return -EBUSY and break, however, the ret out of for loop is return which means madvise_hwpoison success. Oh, I see. Thanks. I don't think such change is a good idea. The original code is obviously easy to confuse people. Why not removing redundant local variable? I think the trick here is get_user_pages_fast will return the number of pages pinned. It is always 1 in madvise_hwpoison, the return value of memory_failure is ignored. Therefore we still need to reset ret to 0 before return madvise_hwpoison. Regards, Wanpeng Li It looks like the original author wrote in that way deliberately but botching it. FWIW, I just think its harmness is more than good. signature.asc Description: Digital signature
[PATCH V13 10/12] perf tools: add a function to calculate sample event size
Add perf_event__sample_event_size() which can be used when
synthesizing sample events to determine how big the resulting
event will be, and therefore how much memory to allocate.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
tools/perf/util/event.h | 2 ++
tools/perf/util/evsel.c | 92 +
2 files changed, 94 insertions(+)
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 1c80e13..93130d8 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -229,6 +229,8 @@ int perf_event__preprocess_sample(const union perf_event
*self,
const char *perf_event__name(unsigned int id);
+size_t perf_event__sample_event_size(const struct perf_sample *sample, u64
type,
+u64 sample_regs_user, u64 read_format);
int perf_event__synthesize_sample(union perf_event *event, u64 type,
u64 sample_regs_user, u64 read_format,
const struct perf_sample *sample,
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 7d62373..e8745fb 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1465,6 +1465,98 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
return 0;
}
+size_t perf_event__sample_event_size(const struct perf_sample *sample, u64
type,
+u64 sample_regs_user, u64 read_format)
+{
+ size_t sz, result = sizeof(struct sample_event);
+
+ if (type PERF_SAMPLE_IDENTIFIER)
+ result += sizeof(u64);
+
+ if (type PERF_SAMPLE_IP)
+ result += sizeof(u64);
+
+ if (type PERF_SAMPLE_TID)
+ result += sizeof(u64);
+
+ if (type PERF_SAMPLE_TIME)
+ result += sizeof(u64);
+
+ if (type PERF_SAMPLE_ADDR)
+ result += sizeof(u64);
+
+ if (type PERF_SAMPLE_ID)
+ result += sizeof(u64);
+
+ if (type PERF_SAMPLE_STREAM_ID)
+ result += sizeof(u64);
+
+ if (type PERF_SAMPLE_CPU)
+ result += sizeof(u64);
+
+ if (type PERF_SAMPLE_PERIOD)
+ result += sizeof(u64);
+
+ if (type PERF_SAMPLE_READ) {
+ result += sizeof(u64);
+ if (read_format PERF_FORMAT_TOTAL_TIME_ENABLED)
+ result += sizeof(u64);
+ if (read_format PERF_FORMAT_TOTAL_TIME_RUNNING)
+ result += sizeof(u64);
+ /* PERF_FORMAT_ID is forced for PERF_SAMPLE_READ */
+ if (read_format PERF_FORMAT_GROUP) {
+ sz = sample-read.group.nr *
+sizeof(struct sample_read_value);
+ result += sz;
+ } else {
+ result += sizeof(u64);
+ }
+ }
+
+ if (type PERF_SAMPLE_CALLCHAIN) {
+ sz = (sample-callchain-nr + 1) * sizeof(u64);
+ result += sz;
+ }
+
+ if (type PERF_SAMPLE_RAW) {
+ result += sizeof(u32);
+ result += sample-raw_size;
+ }
+
+ if (type PERF_SAMPLE_BRANCH_STACK) {
+ sz = sample-branch_stack-nr * sizeof(struct branch_entry);
+ sz += sizeof(u64);
+ result += sz;
+ }
+
+ if (type PERF_SAMPLE_REGS_USER) {
+ if (sample-user_regs.abi) {
+ result += sizeof(u64);
+ sz = hweight_long(sample_regs_user) * sizeof(u64);
+ result += sz;
+ } else {
+ result += sizeof(u64);
+ }
+ }
+
+ if (type PERF_SAMPLE_STACK_USER) {
+ sz = sample-user_stack.size;
+ result += sizeof(u64);
+ if (sz) {
+ result += sz;
+ result += sizeof(u64);
+ }
+ }
+
+ if (type PERF_SAMPLE_WEIGHT)
+ result += sizeof(u64);
+
+ if (type PERF_SAMPLE_DATA_SRC)
+ result += sizeof(u64);
+
+ return result;
+}
+
int perf_event__synthesize_sample(union perf_event *event, u64 type,
u64 sample_regs_user, u64 read_format,
const struct perf_sample *sample,
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V13 08/12] perf tools: add missing 'abi' member to 'struct regs_dump'
And store the parsed value there. Note that the 'abi' is
0 (no registers), 1 (32-bit registers) or 2 (64-bit registers),
but the registers are anyway copied one-by-one as 64-bit
values onto the event i.e. see 'perf_output_sample_regs()'
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Acked-by: Jiri Olsa jo...@redhat.com
---
tools/perf/util/event.h | 1 +
tools/perf/util/evsel.c | 7 +++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 4913339..f959801 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -62,6 +62,7 @@ struct sample_event {
};
struct regs_dump {
+ u64 abi;
u64 *regs;
};
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index db4e431..1184188 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1416,13 +1416,12 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
}
if (type PERF_SAMPLE_REGS_USER) {
- u64 avail;
-
/* First u64 tells us if we have any regs in sample. */
OVERFLOW_CHECK_u64(array);
- avail = *array++;
+ data-user_regs.abi = *array;
+ array++;
- if (avail) {
+ if (data-user_regs.abi) {
u64 regs_user = evsel-attr.sample_regs_user;
sz = hweight_long(regs_user) * sizeof(u64);
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scsi: ufs: read door bell register after clearing interrupt aggregation
Looks good to me.
Reviewed-by: Subhash Jadavani subha...@codeaurora.org
On 8/25/2013 4:06 PM, Dolev Raviv wrote:
In interrupt context, after reading and comparing the UTRLDBR to
hba-outstanding_request and before resetting the interrupt aggregation,
there might be completion of another transfer request (TR). Such TRs might
get stuck, pending, until the next interrupt is generated.
The fix reads the UTRLDBR after resetting the interrupt aggregation and
handles completed TRs.
Signed-off-by: Dolev Raviv dra...@codeaurora.org
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 4dca9b4..30c84d8 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1915,6 +1915,13 @@ static void ufshcd_uic_cmd_compl(struct ufs_hba *hba)
/**
* ufshcd_transfer_req_compl - handle SCSI and query command completion
* @hba: per adapter instance
+ *
+ * Resetting interrupt aggregation counters first and reading the DOOR_BELL
+ * afterward , allows us to handle all the completed requests.
+ * In order to prevent other interrupts starvation the DB is read once
+ * after reset. The down side of this solution is the possibility of false
+ * interrupt if device completes another request after resetting aggregation
+ * and before reading the DB.
*/
static void ufshcd_transfer_req_compl(struct ufs_hba *hba)
{
@@ -1924,47 +1931,36 @@ static void ufshcd_transfer_req_compl(struct ufs_hba
*hba)
u32 tr_doorbell;
int result;
int index;
- bool int_aggr_reset = false;
+
+ /* Reset interrupt aggregation counters */
+ ufshcd_config_int_aggr(hba, INT_AGGR_RESET);
tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
completed_reqs = tr_doorbell ^ hba-outstanding_reqs;
- for (index = 0; index hba-nutrs; index++) {
- if (test_bit(index, completed_reqs)) {
- lrbp = hba-lrb[index];
- cmd = lrbp-cmd;
- /*
-* Don't skip resetting interrupt aggregation counters
-* if a regular command is present.
-*/
- int_aggr_reset |= !lrbp-intr_cmd;
-
- if (cmd) {
- result = ufshcd_transfer_rsp_status(hba, lrbp);
- scsi_dma_unmap(cmd);
- cmd-result = result;
- /* Mark completed command as NULL in LRB */
- lrbp-cmd = NULL;
- clear_bit_unlock(index, hba-lrb_in_use);
- /* Do not touch lrbp after scsi done */
- cmd-scsi_done(cmd);
- } else if (lrbp-command_type ==
- UTP_CMD_TYPE_DEV_MANAGE) {
- if (hba-dev_cmd.complete)
- complete(hba-dev_cmd.complete);
- }
- } /* end of if */
- } /* end of for */
+ for_each_set_bit(index, completed_reqs, hba-nutrs) {
+ lrbp = hba-lrb[index];
+ cmd = lrbp-cmd;
+ if (cmd) {
+ result = ufshcd_transfer_rsp_status(hba, lrbp);
+ scsi_dma_unmap(cmd);
+ cmd-result = result;
+ /* Mark completed command as NULL in LRB */
+ lrbp-cmd = NULL;
+ clear_bit_unlock(index, hba-lrb_in_use);
+ /* Do not touch lrbp after scsi done */
+ cmd-scsi_done(cmd);
+ } else if (lrbp-command_type == UTP_CMD_TYPE_DEV_MANAGE) {
+ if (hba-dev_cmd.complete)
+ complete(hba-dev_cmd.complete);
+ }
+ } /* end of for_each_set_bit */
/* clear corresponding bits of completed commands */
hba-outstanding_reqs ^= completed_reqs;
/* we might have free'd some tags above */
wake_up(hba-dev_cmd.tag_wq);
-
- /* Reset interrupt aggregation counters */
- if (int_aggr_reset)
- ufshcd_config_int_aggr(hba, INT_AGGR_RESET);
}
/**
@@ -2569,6 +2565,7 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
int poll_cnt;
u8 resp = 0xF;
struct ufshcd_lrb *lrbp;
+ u32 reg;
host = cmd-device-host;
hba = shost_priv(host);
@@ -2578,6 +2575,13 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
if (!(test_bit(tag, hba-outstanding_reqs)))
goto out;
+ reg = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
+ if (!(reg (1 tag))) {
+ dev_err(hba-dev,
+ %s: cmd was completed, but without a notifying intr, tag = %d,
+ __func__, tag);
+ }
+
lrbp = hba-lrb[tag];
for (poll_cnt = 100;
[PATCH V13 05/12] perf: make events stream always parsable
The event stream is not always parsable because the format of a sample
is dependent on the sample_type of the selected event. When there
is more than one selected event and the sample_types are not the
same then parsing becomes problematic. A sample can be matched to its
selected event using the ID that is allocated when the event is opened.
Unfortunately, to get the ID from the sample means first parsing it.
This patch adds a new sample format bit PERF_SAMPLE_IDENTIFER that puts
the ID at a fixed position so that the ID can be retrieved without
parsing the sample. For sample events, that is the first position
immediately after the header. For non-sample events, that is the last
position.
In this respect parsing samples requires that the sample_type and ID
values are recorded. For example, perf tools records struct perf_event_attr
and the IDs within the perf.data file. Those must be read first
before it is possible to parse samples found later in the perf.data file.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Acked-by: Peter Zijlstra pet...@infradead.org
Tested-by: Stephane Eranian eran...@google.com
---
include/uapi/linux/perf_event.h | 27 ---
kernel/events/core.c| 11 ++-
2 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 62c25a2..42cb7b6 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -134,8 +134,9 @@ enum perf_event_sample_format {
PERF_SAMPLE_STACK_USER = 1U 13,
PERF_SAMPLE_WEIGHT = 1U 14,
PERF_SAMPLE_DATA_SRC= 1U 15,
+ PERF_SAMPLE_IDENTIFIER = 1U 16,
- PERF_SAMPLE_MAX = 1U 16, /* non-ABI */
+ PERF_SAMPLE_MAX = 1U 17, /* non-ABI */
};
/*
@@ -492,12 +493,12 @@ enum perf_event_type {
/*
* If perf_event_attr.sample_id_all is set then all event types will
* have the sample_type selected fields related to where/when
-* (identity) an event took place (TID, TIME, ID, CPU, STREAM_ID)
-* described in PERF_RECORD_SAMPLE below, it will be stashed just after
-* the perf_event_header and the fields already present for the existing
-* fields, i.e. at the end of the payload. That way a newer perf.data
-* file will be supported by older perf tools, with these new optional
-* fields being ignored.
+* (identity) an event took place (TID, TIME, ID, STREAM_ID, CPU,
+* IDENTIFIER) described in PERF_RECORD_SAMPLE below, it will be stashed
+* just after the perf_event_header and the fields already present for
+* the existing fields, i.e. at the end of the payload. That way a newer
+* perf.data file will be supported by older perf tools, with these new
+* optional fields being ignored.
*
* struct sample_id {
* { u32 pid, tid; } PERF_SAMPLE_TID
@@ -505,7 +506,12 @@ enum perf_event_type {
* { u64 id; } PERF_SAMPLE_ID
* { u64 stream_id;} PERF_SAMPLE_STREAM_ID
* { u32 cpu, res; } PERF_SAMPLE_CPU
+* { u64 id; } PERF_SAMPLE_IDENTIFIER
* } perf_event_attr::sample_id_all
+*
+* Note that PERF_SAMPLE_IDENTIFIER duplicates PERF_SAMPLE_ID. The
+* advantage of PERF_SAMPLE_IDENTIFIER is that its position is fixed
+* relative to header.size.
*/
/*
@@ -594,6 +600,13 @@ enum perf_event_type {
* struct {
* struct perf_event_headerheader;
*
+* #
+* # Note that PERF_SAMPLE_IDENTIFIER duplicates PERF_SAMPLE_ID.
+* # The advantage of PERF_SAMPLE_IDENTIFIER is that its position
+* # is fixed relative to header.
+* #
+*
+* { u64 id; } PERF_SAMPLE_IDENTIFIER
* { u64 ip; } PERF_SAMPLE_IP
* { u32 pid, tid; } PERF_SAMPLE_TID
* { u64 time; } PERF_SAMPLE_TIME
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 928fae7..15d0f24 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1213,6 +1213,9 @@ static void perf_event__id_header_size(struct perf_event
*event)
if (sample_type PERF_SAMPLE_TIME)
size += sizeof(data-time);
+ if (sample_type PERF_SAMPLE_IDENTIFIER)
+ size += sizeof(data-id);
+
if (sample_type PERF_SAMPLE_ID)
size += sizeof(data-id);
@@ -4280,7 +4283,7 @@ static void __perf_event_header__init_id(struct
perf_event_header *header,
if (sample_type PERF_SAMPLE_TIME)
linux-next: manual merge of the arm-soc tree with the usb tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/am335x-evmsk.dts between commit 97238b35d5bb (usb:
musb: dsps: use proper child nodes) from the usb tree and commit
63f6b2550aa0 (ARM: dts: AM33XX: don't redefine OCP bus and device
nodes) from the arm-soc tree.
I fixed it up (probably incorrectly - see below) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/boot/dts/am335x-evmsk.dts
index e92446c,8e7279b..000
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@@ -30,210 -30,6 +30,24 @@@
reg = 0x8000 0x1000; /* 256 MB */
};
- am33xx_pinmux: pinmux@44e10800 {
- pinctrl-names = default;
- pinctrl-0 = gpio_keys_s0 clkout2_pin;
-
- user_leds_s0: user_leds_s0 {
- pinctrl-single,pins =
- 0x10 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_ad4.gpio1_4 */
- 0x14 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_ad5.gpio1_5 */
- 0x18 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_ad6.gpio1_6 */
- 0x1c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpmc_ad7.gpio1_7 */
- ;
- };
-
- gpio_keys_s0: gpio_keys_s0 {
- pinctrl-single,pins =
- 0x94 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_oen_ren.gpio2_3 */
- 0x90 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_advn_ale.gpio2_2 */
- 0x70 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_wait0.gpio0_30 */
- 0x9c (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_ben0_cle.gpio2_5 */
- ;
- };
-
- i2c0_pins: pinmux_i2c0_pins {
- pinctrl-single,pins =
- 0x188 (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_sda.i2c0_sda */
- 0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/*
i2c0_scl.i2c0_scl */
- ;
- };
-
- uart0_pins: pinmux_uart0_pins {
- pinctrl-single,pins =
- 0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
- 0x174 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)
/* uart0_txd.uart0_txd */
- ;
- };
-
- clkout2_pin: pinmux_clkout2_pin {
- pinctrl-single,pins =
- 0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)
/* xdma_event_intr1.clkout2 */
- ;
- };
-
- ecap2_pins: backlight_pins {
- pinctrl-single,pins =
- 0x19c 0x4 /*
mcasp0_ahclkr.ecap2_in_pwm2_out MODE4 */
- ;
- };
-
- cpsw_default: cpsw_default {
- pinctrl-single,pins =
- /* Slave 1 */
- 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txen.rgmii1_tctl */
- 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxdv.rgmii1_rctl */
- 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd3.rgmii1_td3 */
- 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd2.rgmii1_td2 */
- 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd1.rgmii1_td1 */
- 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd0.rgmii1_td0 */
- 0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txclk.rgmii1_tclk */
- 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxclk.rgmii1_rclk */
- 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd3.rgmii1_rd3 */
- 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd2.rgmii1_rd2 */
- 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd1.rgmii1_rd1 */
- 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd0.rgmii1_rd0 */
-
- /* Slave 2 */
- 0x40 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a0.rgmii2_tctl */
- 0x44 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a1.rgmii2_rctl */
- 0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a2.rgmii2_td3 */
- 0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a3.rgmii2_td2 */
- 0x50 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
[PATCH V13 04/12] perf tools: remove references to struct ip_event
struct ip_event assumes fixed positions for ip, pid
and tid. That is no longer true with the addition of
PERF_SAMPLE_IDENTIFIER. The information is anyway in
struct sample, so use that instead.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Acked-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/builtin-inject.c | 4 ++--
tools/perf/builtin-kmem.c | 4 ++--
tools/perf/builtin-mem.c | 2 +-
tools/perf/builtin-script.c | 4 ++--
tools/perf/builtin-top.c | 11 ++-
tools/perf/tests/hists_link.c | 20
tools/perf/util/build-id.c| 8
tools/perf/util/event.c | 6 +++---
tools/perf/util/event.h | 11 ---
tools/perf/util/evsel.c | 4 ++--
tools/perf/util/session.c | 8 +---
11 files changed, 35 insertions(+), 47 deletions(-)
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index 0d4ae1d..ffacd46 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -198,7 +198,7 @@ static int perf_event__inject_buildid(struct perf_tool
*tool,
cpumode = event-header.misc PERF_RECORD_MISC_CPUMODE_MASK;
- thread = machine__findnew_thread(machine, event-ip.pid, event-ip.pid);
+ thread = machine__findnew_thread(machine, sample-pid, sample-pid);
if (thread == NULL) {
pr_err(problem processing %d event, skipping it.\n,
event-header.type);
@@ -206,7 +206,7 @@ static int perf_event__inject_buildid(struct perf_tool
*tool,
}
thread__find_addr_map(thread, machine, cpumode, MAP__FUNCTION,
- event-ip.ip, al);
+ sample-ip, al);
if (al.map != NULL) {
if (!al.map-dso-hit) {
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index c324778..c2dff9c 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -305,8 +305,8 @@ static int process_sample_event(struct perf_tool *tool
__maybe_unused,
struct perf_evsel *evsel,
struct machine *machine)
{
- struct thread *thread = machine__findnew_thread(machine, event-ip.pid,
- event-ip.pid);
+ struct thread *thread = machine__findnew_thread(machine, sample-pid,
+ sample-pid);
if (thread == NULL) {
pr_debug(problem processing %d event, skipping it.\n,
diff --git a/tools/perf/builtin-mem.c b/tools/perf/builtin-mem.c
index 706a1fa..791b432 100644
--- a/tools/perf/builtin-mem.c
+++ b/tools/perf/builtin-mem.c
@@ -94,7 +94,7 @@ dump_raw_samples(struct perf_tool *tool,
symbol_conf.field_sep,
sample-tid,
symbol_conf.field_sep,
- event-ip.ip,
+ sample-ip,
symbol_conf.field_sep,
sample-addr,
symbol_conf.field_sep,
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index d82712f..93a34ce 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -501,8 +501,8 @@ static int process_sample_event(struct perf_tool *tool
__maybe_unused,
struct machine *machine)
{
struct addr_location al;
- struct thread *thread = machine__findnew_thread(machine, event-ip.pid,
- event-ip.tid);
+ struct thread *thread = machine__findnew_thread(machine, sample-pid,
+ sample-tid);
if (thread == NULL) {
pr_debug(problem processing %d event, skipping it.\n,
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index e37521f..2122141 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -689,7 +689,7 @@ static void perf_event__process_sample(struct perf_tool
*tool,
{
struct perf_top *top = container_of(tool, struct perf_top, tool);
struct symbol *parent = NULL;
- u64 ip = event-ip.ip;
+ u64 ip = sample-ip;
struct addr_location al;
int err;
@@ -699,10 +699,10 @@ static void perf_event__process_sample(struct perf_tool
*tool,
if (!seen)
seen = intlist__new(NULL);
- if (!intlist__has_entry(seen, event-ip.pid)) {
+ if (!intlist__has_entry(seen, sample-pid)) {
pr_err(Can't find guest [%d]'s kernel information\n,
- event-ip.pid);
- intlist__add(seen, event-ip.pid);
+ sample-pid);
+ intlist__add(seen, sample-pid);
}
return;
}
@@ -836,7 +836,8 @@ static void perf_top__mmap_read_idx(struct perf_top *top,
int idx)
[PATCH V13 02/12] perf tools: tidy up sample parsing overflow checking
The size of data retrieved from a sample event must be
validated to ensure it does not go past the end of the
event. That was being done sporadically and without
considering integer overflows.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Acked-by: Jiri Olsa jo...@redhat.com
---
tools/perf/util/evsel.c | 112 ++--
1 file changed, 71 insertions(+), 41 deletions(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 47cbe1e..9a5fb23 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1131,24 +1131,30 @@ static int perf_evsel__parse_id_sample(const struct
perf_evsel *evsel,
return 0;
}
-static bool sample_overlap(const union perf_event *event,
- const void *offset, u64 size)
+static inline bool overflow(const void *endp, u16 max_size, const void *offset,
+ u64 size)
{
- const void *base = event;
+ return size max_size || offset + size endp;
+}
- if (offset + size base + event-header.size)
- return true;
+#define OVERFLOW_CHECK(offset, size, max_size) \
+ do {\
+ if (overflow(endp, (max_size), (offset), (size))) \
+ return -EFAULT; \
+ } while (0)
- return false;
-}
+#define OVERFLOW_CHECK_u64(offset) \
+ OVERFLOW_CHECK(offset, sizeof(u64), sizeof(u64))
int perf_evsel__parse_sample(struct perf_evsel *evsel, union perf_event *event,
struct perf_sample *data)
{
u64 type = evsel-attr.sample_type;
- u64 regs_user = evsel-attr.sample_regs_user;
bool swapped = evsel-needs_swap;
const u64 *array;
+ u16 max_size = event-header.size;
+ const void *endp = (void *)event + max_size;
+ u64 sz;
/*
* used for cross-endian analysis. See git commit 65014ab3
@@ -1170,6 +1176,11 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
array = event-sample.array;
+ /*
+* The evsel's sample_size is based on PERF_SAMPLE_MASK which includes
+* up to PERF_SAMPLE_PERIOD. After that overflow() must be used to
+* check the format does not go past the end of the event.
+*/
if (evsel-sample_size + sizeof(event-header) event-header.size)
return -EFAULT;
@@ -1235,6 +1246,7 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
if (type PERF_SAMPLE_READ) {
u64 read_format = evsel-attr.read_format;
+ OVERFLOW_CHECK_u64(array);
if (read_format PERF_FORMAT_GROUP)
data-read.group.nr = *array;
else
@@ -1243,41 +1255,51 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
array++;
if (read_format PERF_FORMAT_TOTAL_TIME_ENABLED) {
+ OVERFLOW_CHECK_u64(array);
data-read.time_enabled = *array;
array++;
}
if (read_format PERF_FORMAT_TOTAL_TIME_RUNNING) {
+ OVERFLOW_CHECK_u64(array);
data-read.time_running = *array;
array++;
}
/* PERF_FORMAT_ID is forced for PERF_SAMPLE_READ */
if (read_format PERF_FORMAT_GROUP) {
- data-read.group.values = (struct sample_read_value *)
array;
- array = (void *) array + data-read.group.nr *
- sizeof(struct sample_read_value);
+ const u64 max_group_nr = UINT64_MAX /
+ sizeof(struct sample_read_value);
+
+ if (data-read.group.nr max_group_nr)
+ return -EFAULT;
+ sz = data-read.group.nr *
+sizeof(struct sample_read_value);
+ OVERFLOW_CHECK(array, sz, max_size);
+ data-read.group.values =
+ (struct sample_read_value *)array;
+ array = (void *)array + sz;
} else {
+ OVERFLOW_CHECK_u64(array);
data-read.one.id = *array;
array++;
}
}
if (type PERF_SAMPLE_CALLCHAIN) {
- if (sample_overlap(event, array, sizeof(data-callchain-nr)))
- return -EFAULT;
-
- data-callchain = (struct ip_callchain *)array;
+ const u64 max_callchain_nr = UINT64_MAX / sizeof(u64);
- if (sample_overlap(event, array, data-callchain-nr))
+
Re: [PATCH 21/33] clk: ux500: Add Device Tree support for the PRCC Kernel clock
On Fri, 23 Aug 2013, Linus Walleij wrote: On Thu, Aug 22, 2013 at 11:21 AM, Lee Jones lee.jo...@linaro.org wrote: I really do not like the approach of uglifying something and then beautifying it later... I prefer each step in isolation to be good looking, or you will be confused when traversing the history. So then we have a few options, some more realistic than others. 1. Duplicate each of the; clk_reg_prcmu_*(), clk_reg_prcc_pclk(), clk_reg_prcc_kclk() calls into your proposed u8500_clk_init_dt(), which, while keeping everything separate would be unrealistic. I think this is perfectly realistic. You're not going to duplicate each clk_register_clkdev(), which makes it way smaller than the original function, and since one of the function will be inside a #ifdef CONFIG_OF #endif After we switch the entire platform to DT-only it will be pretty obvious which big chunk of code that needs to go away, it's a clean cut. (Note: I know the #ifdef CONFIG_OF is not necessary anymore since we switched to multiplatform, but I intend that marker for humans, not machines.) This sounds gross. To duplicate; u8500_clk_init(), u8540_clk_init() and u9540_clk_init() just for the sake of loading a few pointers into an array for a small part of the development cycle sounds obscene. I genuinely think keeping the current patch in this series and then removing the clk_register_clkdev() in the remove ATAG support series is the best way to go. If you think I'm wrong then I'll so as you ask however. Just pass me the sick bucket. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tcp: initialize rcv_tstamp for restored sockets
From: Andrew Vagin ava...@openvz.org u32 rcv_tstamp; /* timestamp of last received ACK */ Its value used in tcp_retransmit_timer, which closes socket if the last ack was received more then TCP_RTO_MAX ago. Currently rcv_tstamp is initialized to zero and if tcp_retransmit_timer is called before receiving a first ack, the connection is closed. This patch initializes rcv_tstamp to a timestamp, when a socket was restored. Cc: Pavel Emelyanov xe...@parallels.com Cc: Eric Dumazet eric.duma...@gmail.com Cc: David S. Miller da...@davemloft.net Cc: Alexey Kuznetsov kuz...@ms2.inr.ac.ru Cc: James Morris jmor...@namei.org Cc: Hideaki YOSHIFUJI yoshf...@linux-ipv6.org Cc: Patrick McHardy ka...@trash.net Reported-by: Cyrill Gorcunov gorcu...@openvz.org Signed-off-by: Andrey Vagin ava...@openvz.org --- net/ipv4/tcp_output.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 92fde8d..e297299 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -2814,6 +2814,8 @@ void tcp_connect_init(struct sock *sk) if (likely(!tp-repair)) tp-rcv_nxt = 0; + else + tp-rcv_tstamp = tcp_time_stamp; tp-rcv_wup = tp-rcv_nxt; tp-copied_seq = tp-rcv_nxt; -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tcp: don't apply tsoffset if rcv_tsecr is zero
From: Andrew Vagin ava...@openvz.org
The zero value means that tsecr is not valid, so it's a special case.
tsoffset is used to customize tcp_time_stamp for one socket.
tsoffset is usually zero, it's used when a socket was moved from one
host to another host.
Currently this issue affects logic of tcp_rcv_rtt_measure_ts. Due to
incorrect value of rcv_tsecr, tcp_rcv_rtt_measure_ts sets rto to
TCP_RTO_MAX.
Cc: Pavel Emelyanov xe...@parallels.com
Cc: Eric Dumazet eric.duma...@gmail.com
Cc: David S. Miller da...@davemloft.net
Cc: Alexey Kuznetsov kuz...@ms2.inr.ac.ru
Cc: James Morris jmor...@namei.org
Cc: Hideaki YOSHIFUJI yoshf...@linux-ipv6.org
Cc: Patrick McHardy ka...@trash.net
Reported-by: Cyrill Gorcunov gorcu...@openvz.org
Signed-off-by: Andrey Vagin ava...@openvz.org
---
net/ipv4/tcp_input.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 28af45a..3ca2139 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3535,7 +3535,10 @@ static bool tcp_parse_aligned_timestamp(struct tcp_sock
*tp, const struct tcphdr
++ptr;
tp-rx_opt.rcv_tsval = ntohl(*ptr);
++ptr;
- tp-rx_opt.rcv_tsecr = ntohl(*ptr) - tp-tsoffset;
+ if (*ptr)
+ tp-rx_opt.rcv_tsecr = ntohl(*ptr) - tp-tsoffset;
+ else
+ tp-rx_opt.rcv_tsecr = 0;
return true;
}
return false;
@@ -3560,7 +3563,7 @@ static bool tcp_fast_parse_options(const struct sk_buff
*skb,
}
tcp_parse_options(skb, tp-rx_opt, 1, NULL);
- if (tp-rx_opt.saw_tstamp)
+ if (tp-rx_opt.saw_tstamp tp-rx_opt.rcv_tsecr)
tp-rx_opt.rcv_tsecr -= tp-tsoffset;
return true;
@@ -5316,7 +5319,7 @@ static int tcp_rcv_synsent_state_process(struct sock *sk,
struct sk_buff *skb,
int saved_clamp = tp-rx_opt.mss_clamp;
tcp_parse_options(skb, tp-rx_opt, 0, foc);
- if (tp-rx_opt.saw_tstamp)
+ if (tp-rx_opt.saw_tstamp tp-rx_opt.rcv_tsecr)
tp-rx_opt.rcv_tsecr -= tp-tsoffset;
if (th-ack) {
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with the usb tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/omap5.dtsi between commit 22a5aa170c52 (usb: dwc3:
core: switch to snps,dwc3) from the usb tree and commit ec0a71838da2
(ARM: OMAP5: dts: fix reg property size) from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/boot/dts/omap5.dtsi
index 07be2cd,4fc0912..000
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@@ -644,8 -644,8 +644,8 @@@
utmi-mode = 2;
ranges;
dwc3@4a03 {
- compatible = synopsys,dwc3;
+ compatible = snps,dwc3;
- reg = 0x4a03 0x1000;
+ reg = 0x4a03 0x1;
interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH;
usb-phy = usb2_phy, usb3_phy;
tx-fifo-resize;
pgpc0vBpXKaAd.pgp
Description: PGP signature
linux-next: manual merge of the arm-soc tree with Linus' tree
Hi all, Today's linux-next merge of the arm-soc tree got a conflict in arch/arm/boot/dts/tegra20-seaboard.dts between commit 30ca2226bea6 (ARM: tegra: always enable USB VBUS regulators) from Linus' tree and commit 23f95ef2d951 (ARM: tegra: use TEGRA_GPIO() in a couple more places) from the arm-soc tree. I fixed it up (see below) and can carry the fix as necessary (no action is required). -- Cheers, Stephen Rothwells...@canb.auug.org.au diff --cc arch/arm/boot/dts/tegra20-seaboard.dts index c824253,f44a9b8..000 --- a/arch/arm/boot/dts/tegra20-seaboard.dts +++ b/arch/arm/boot/dts/tegra20-seaboard.dts @@@ -828,9 -829,7 +828,9 @@@ regulator-min-microvolt = 500; regulator-max-microvolt = 500; enable-active-high; - gpio = gpio 24 0; /* PD0 */ + gpio = gpio TEGRA_GPIO(D, 0) 0; + regulator-always-on; + regulator-boot-on; }; }; pgpvNVSiUVPrU.pgp Description: PGP signature
Re: [PATCH 1/2] mfd: db8500-prcmu: Use ANSI function declaration
On Fri, 23 Aug 2013, Sachin Kamat wrote: Silences the following warning: drivers/mfd/db8500-prcmu.c:2322:25: warning: non-ANSI function declaration of function 'prcmu_ac_sleep_req' Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/mfd/db8500-prcmu.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied with Linus' Ack. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mfd: db8500-prcmu: Staticize clk_mgt
On Fri, 23 Aug 2013, Sachin Kamat wrote: clk_mgt is used only in this file. Make it static. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/mfd/db8500-prcmu.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied with Linus' Ack. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] mfd: ab8500-debugfs: Staticize local variables
On Fri, 23 Aug 2013, Sachin Kamat wrote: Local variables referenced only in this file are made static. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/mfd/ab8500-debugfs.c |8 1 files changed, 4 insertions(+), 4 deletions(-) Applied with Linus' Ack. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with Linus' tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/boot/dts/tegra20-trimslice.dts between commit 30ca2226bea6
(ARM: tegra: always enable USB VBUS regulators) from Linus' tree and
commit 23f95ef2d951 (ARM: tegra: use TEGRA_GPIO() in a couple more
places) from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/boot/dts/tegra20-trimslice.dts
index 1e9d33a,22e227f..000
--- a/arch/arm/boot/dts/tegra20-trimslice.dts
+++ b/arch/arm/boot/dts/tegra20-trimslice.dts
@@@ -310,8 -310,19 +310,18 @@@
nvidia,sys-clock-req-active-high;
};
+ pcie-controller {
+ status = okay;
+ pex-clk-supply = pci_clk_reg;
+ vdd-supply = pci_vdd_reg;
+
+ pci@1,0 {
+ status = okay;
+ };
+ };
+
usb@c500 {
status = okay;
- nvidia,vbus-gpio = gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH;
};
usb-phy@c500 {
@@@ -410,10 -421,26 +420,28 @@@
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
enable-active-high;
- gpio = gpio 170 0; /* PV2 */
+ gpio = gpio TEGRA_GPIO(V, 2) 0;
+ regulator-always-on;
+ regulator-boot-on;
};
+
+ pci_clk_reg: regulator@3 {
+ compatible = regulator-fixed;
+ reg = 3;
+ regulator-name = pci_clk;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ regulator-always-on;
+ };
+
+ pci_vdd_reg: regulator@4 {
+ compatible = regulator-fixed;
+ reg = 4;
+ regulator-name = pci_vdd;
+ regulator-min-microvolt = 105;
+ regulator-max-microvolt = 105;
+ regulator-always-on;
+ };
};
sound {
pgpI912EipOxn.pgp
Description: PGP signature
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On 27/08/2013 09:42, Nicolas Ferre wrote: On 27/08/2013 08:16, boris brezillon : On 27/08/2013 05:55, Stephen Warren wrote: On 08/26/2013 11:01 AM, boris brezillon wrote: Hello Stephen, On 26/08/2013 18:50, Stephen Warren wrote: On 08/24/2013 03:35 PM, Boris BREZILLON wrote: Add a new parameter to support deglitch filter configuration. A deglitch filter works like a debounce filter but with a smaller delay (nanoseconds). Why not use the existing debounce property, just with a small delay specified. It seems like that's exactly what the property is for? That's one of the question I asked in my cover letter :-) Indeed the at91 deglitch filter delay is not configurable and is statically assigned to half a master clk cycle (if master clk = 133MHz - 8 ns). The debounce property argument is currently expressed in usecs. This will result in always selecting the debounce filter (which is also available on at91 SoCs) over the deglitch filter. Could we add a flag in the deglitch argument to specify the delay unit (nsecs or usecs) ? If the value is hard-coded in HW, why not use non-zero (or 1) to enable and zero to disable? Indeed at91 pins support both deglitch and debounce filter and I have to choose between the two given the argument value (in usec). Here's what I can do: if (arg = 1/2 * slowclock)/* debounce case */ /* choose debounce filter and configure the delay according to the given argument value */ else /* deglitch case */ /* choose deglitch filter */ Slow clock is running at 32KHz which gives a 30 usec clock cycle. I am not in favor for this kind of complicated heuristic. Deglitch and Debounce filters are different features in at91 (even if they pursuit the same goal). So I do prefer to let the user choose which feature is preferred for his application and add a different flag. (this kind of thing is why I'm not convinced that generic pinconf works so well... What if we need psecs in the future?) Should I keep the at91 native pinconf binding and add the missing flags to this binding (OUTPUT configuration flags) ? This was another question I asked in my cover letter: wether or not the generic pinconf binding should be used. The question is: how much this generic pinconf is... well... generic! And it is not a answer I can give. On the other hand, if the generic is not going to overcome the native pinctrl, I do not feel like switching to this at the cost of changing the whole dtsi/dts entries that we already have. So, it is more to Linus and Stephen to give us clues about this... Okay. I'll propose a new patch series adding native support for OUTPUT configuration of at91 pins (add OUTPUT_HIGH/LOW), and put this series in stand-by until a clear decision is made about generic pinconf. Thanks, Best Regards, Boris Bye, -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] Kconfig.debug: Add FRAME_POINTER anti-dependency for ARC
Frame pointer on ARC doesn't serve the conventional purpose of stack unwinding due to the typical way ABI designates it's usage. Thus it's explicit usage on ARC is discouraged (gcc is free to use it, for some tricky stack frames even if -fomit-frame-pointer). Hence no point enabling it for ARC. Signed-off-by: Vineet Gupta vgu...@synopsys.com Cc: Dave Hansen dave.han...@linux.intel.com Cc: Andrew Morton a...@linux-foundation.org Cc: Paul E. McKenney paul.mcken...@linaro.org Cc: Catalin Marinas catalin.mari...@arm.com Cc: Michel Lespinasse wal...@google.com Cc: linux-kernel@vger.kernel.org --- lib/Kconfig.debug | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 1501aa5..c971f3a 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -908,7 +908,7 @@ config LOCKDEP bool depends on DEBUG_KERNEL TRACE_IRQFLAGS_SUPPORT STACKTRACE_SUPPORT LOCKDEP_SUPPORT select STACKTRACE - select FRAME_POINTER if !MIPS !PPC !ARM_UNWIND !S390 !MICROBLAZE + select FRAME_POINTER if !MIPS !PPC !ARM_UNWIND !S390 !MICROBLAZE !ARC select KALLSYMS select KALLSYMS_ALL @@ -1347,7 +1347,7 @@ config FAULT_INJECTION_STACKTRACE_FILTER depends on FAULT_INJECTION_DEBUG_FS STACKTRACE_SUPPORT depends on !X86_64 select STACKTRACE - select FRAME_POINTER if !MIPS !PPC !S390 !MICROBLAZE !ARM_UNWIND + select FRAME_POINTER if !MIPS !PPC !S390 !MICROBLAZE !ARM_UNWIND !ARC help Provide stacktrace filter for fault-injection capabilities @@ -1357,7 +1357,7 @@ config LATENCYTOP depends on DEBUG_KERNEL depends on STACKTRACE_SUPPORT depends on PROC_FS - select FRAME_POINTER if !MIPS !PPC !S390 !MICROBLAZE !ARM_UNWIND + select FRAME_POINTER if !MIPS !PPC !S390 !MICROBLAZE !ARM_UNWIND !ARC select KALLSYMS select KALLSYMS_ALL select STACKTRACE -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] gpio: pcf857x: Add OF support
Hi, On Tuesday 27 August 2013 01:44 PM, Tomasz Figa wrote: Hi Laurent, On Tuesday 27 of August 2013 10:02:39 Laurent Pinchart wrote: Add DT bindings for the pcf857x-compatible chips and parse the device tree node in the driver. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- .../devicetree/bindings/gpio/gpio-pcf857x.txt | 71 ++ drivers/gpio/gpio-pcf857x.c | 44 +++--- 2 files changed, 107 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt Changes since v4: - Don't try to get ngpio from of_device_id data, we already get it from i2c_device_id Hmm, I'm not sure how this is supposed to work. How does the I2C core resolve OF compatible name to particular entry in id_table? I believe it simply passes NULL as the second argument of .probe() if the device is instantiated based on OF compatible string and not one in the legacy ID table. It doesn't pass the second argument as NULL. If you look at i2c_device_probe() in drivers/i2c/i2c-core.c, the second argument to probe is passed as: i2c_match_id(driver-id_table, client) This will extract the i2c_device_id pointer from the id_table. Archit -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the arm-soc tree with the pm tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-mvebu/platsmp.c between commit f6cec7cd0777 (ARM: mvebu:
remove device tree parsing for cpu nodes) from the tree and commit
994c8c94b419 (ARM: mvebu: Remove the harcoded BootROM window
allocation) from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-mvebu/platsmp.c
index 594b63d,4f960f0..000
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@@ -29,28 -30,31 +30,31 @@@
#include pmsu.h
#include coherency.h
+ #define AXP_BOOTROM_BASE 0xfff0
+ #define AXP_BOOTROM_SIZE 0x10
+
+static struct clk *__init get_cpu_clk(int cpu)
+{
+ struct clk *cpu_clk;
+ struct device_node *np = of_get_cpu_node(cpu, NULL);
+
+ if (WARN(!np, missing cpu node\n))
+ return NULL;
+ cpu_clk = of_clk_get(np, 0);
+ if (WARN_ON(IS_ERR(cpu_clk)))
+ return NULL;
+ return cpu_clk;
+}
+
void __init set_secondary_cpus_clock(void)
{
- int thiscpu;
+ int thiscpu, cpu;
unsigned long rate;
- struct clk *cpu_clk = NULL;
- struct device_node *np = NULL;
+ struct clk *cpu_clk;
thiscpu = smp_processor_id();
- for_each_node_by_type(np, cpu) {
- int err;
- int cpu;
-
- err = of_property_read_u32(np, reg, cpu);
- if (WARN_ON(err))
- return;
-
- if (cpu == thiscpu) {
- cpu_clk = of_clk_get(np, 0);
- break;
- }
- }
- if (WARN_ON(IS_ERR(cpu_clk)))
+ cpu_clk = get_cpu_clk(thiscpu);
+ if (!cpu_clk)
return;
clk_prepare_enable(cpu_clk);
rate = clk_get_rate(cpu_clk);
pgpGcBD4wcgge.pgp
Description: PGP signature
Re: [PATCH 13/18] Hibernate: Avoid S4 sign key data included in snapshot image
於 日，2013-08-25 於 18:39 +0200，Pavel Machek 提到： On Thu 2013-08-22 19:01:52, Lee, Chun-Yi wrote: This patch add swsusp_page_is_sign_key() method to hibernate_key.c and check the page is S4 sign key data when collect saveable page in snapshot.c to avoid sign key data included in snapshot image. Reviewed-by: Jiri Kosina jkos...@suse.cz Signed-off-by: Lee, Chun-Yi j...@suse.com --- kernel/power/snapshot.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c index 72e2911..9e4c94b 100644 --- a/kernel/power/snapshot.c +++ b/kernel/power/snapshot.c @@ -860,6 +860,9 @@ static struct page *saveable_highmem_page(struct zone *zone, unsigned long pfn) BUG_ON(!PageHighMem(page)); + if (swsusp_page_is_sign_key(page)) + return NULL; + if (swsusp_page_is_forbidden(page) || swsusp_page_is_free(page) || PageReserved(page)) return NULL; Just do set_page_forbidden() on your page? Before call swsusp_unset_page_forbidden(), we need make sure the create_basic_memory_bitmaps() function already called to initial forbidden_pages_map. That means need careful the timing, otherwise the page of private key will not register to forbidden pages map. So, I choice to refuse the page of private key when snapshot finding which page is saveable. It has clearer code and we don't need worry the future change of hibernate.c or user.c for when they call create_basic_memory_bitmaps() and when the code clear forbidden pages map. Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 03/18] asymmetric keys: separate the length checking of octet string from RSA_I2OSP
On Mon, 26 Aug 2013, Pavel Machek wrote:
Due to RSA_I2OSP is not only used by signature verification path but
also used
in signature generation path. So, separate the length checking of octet
string
because it's not for generate 0x00 0x01 leading string when used in
signature
generation.
Reviewed-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Lee, Chun-Yi j...@suse.com
+static int RSA_I2OSP(MPI x, size_t xLen, u8 **_X)
+{
+ unsigned x_size;
+ unsigned X_size;
+ u8 *X = NULL;
Is this kernel code or entry into obfuscated C code contest? This is not
funny.
The small x is the input integer that will transfer to big X that is
a octet sting.
Sorry for I direct give variable name to match with spec, maybe I need
use big_X or
Having variables that differ only in case is confusing. Actually
RSA_I2OSP is not a good name for function, either.
If it converts x into X, perhaps you can name one input and second output?
The variable naming is according to spec, and I believe it makes sense to
keep it so, no matter how stupid the naming in the spec might be.
Otherwise you have to do mental remapping when looking at the code and the
spec at the same time, which is very inconvenient.
Would a comment next to the variable declaration, that would point this
fact out, be satisfactory for you?
--
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: unused swap offset / bad page map.
On Mon, Aug 26, 2013 at 06:28:33PM -0400, Dave Jones wrote:
I've not tried matching up bits with Dave's reports, and just going
into a meeting now, but this patch looks worth a try: probably Cyrill
can improve it meanwhile to what he actually wants there (I'm
surprised anything special is needed for just moving a pte).
Hugh
--- 3.11-rc7/mm/mremap.c 2013-07-14 17:10:16.640003652 -0700
+++ linux/mm/mremap.c 2013-08-26 14:46:14.460027627 -0700
@@ -126,7 +126,7 @@ static void move_ptes(struct vm_area_str
continue;
pte = ptep_get_and_clear(mm, old_addr, old_pte);
pte = move_pte(pte, new_vma-vm_page_prot, old_addr, new_addr);
- set_pte_at(mm, new_addr, new_pte, pte_mksoft_dirty(pte));
+ set_pte_at(mm, new_addr, new_pte, pte);
}
I'll give this a shot once I'm done with the bisect.
I managed to trigger the issue as well. The patch below fixes it.
Dave, could you please give it a shot once time permit?
Pavel, I kept 'make it dirty on move' logic, but i'm somehow doubt
in it, won't plain pte copying (as in Hugh's patch) work of us?
---
From: Cyrill Gorcunov gorcu...@gmail.com
Subject: [PATCH] mm: move_ptes -- Set soft dirty bit depending on pte type
Dave reported corrupted swap entries
| [ 4588.541886] swap_free: Unused swap offset entry 2d15
| [ 4588.541952] BUG: Bad page map in process trinity-kid12 pte:005a2a80
pmd:22c01f067
and Hugh pointed that in move_ptes _PAGE_SOFT_DIRTY bit
set regardless the type of entry pte consists of. The
trick here is that -- when we carry soft dirty status
in swap entries we are to use _PAGE_SWP_SOFT_DIRTY instead,
because this is the only place in pte which can be used
for own needs without intersecting with bits owned by
swap entry type/offset.
Reported-by: Dave Jones da...@redhat.com
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Pavel Emelyanov xe...@parallels.com
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Hugh Dickins hu...@google.com
Cc: Hillf Danton dhi...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
---
mm/mremap.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
Index: linux-2.6.git/mm/mremap.c
===
--- linux-2.6.git.orig/mm/mremap.c
+++ linux-2.6.git/mm/mremap.c
@@ -15,6 +15,7 @@
#include linux/swap.h
#include linux/capability.h
#include linux/fs.h
+#include linux/swapops.h
#include linux/highmem.h
#include linux/security.h
#include linux/syscalls.h
@@ -69,6 +70,23 @@ static pmd_t *alloc_new_pmd(struct mm_st
return pmd;
}
+static pte_t move_soft_dirty_pte(pte_t pte)
+{
+ /*
+* Set soft dirty bit so we can notice
+* in userspace the ptes were moved.
+*/
+#ifdef CONFIG_MEM_SOFT_DIRTY
+ if (pte_present(pte))
+ pte = pte_mksoft_dirty(pte);
+ else if (is_swap_pte(pte))
+ pte = pte_swp_mksoft_dirty(pte);
+ else if (pte_file(pte))
+ pte = pte_file_mksoft_dirty(pte);
+#endif
+ return pte;
+}
+
static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd,
unsigned long old_addr, unsigned long old_end,
struct vm_area_struct *new_vma, pmd_t *new_pmd,
@@ -126,7 +144,8 @@ static void move_ptes(struct vm_area_str
continue;
pte = ptep_get_and_clear(mm, old_addr, old_pte);
pte = move_pte(pte, new_vma-vm_page_prot, old_addr, new_addr);
- set_pte_at(mm, new_addr, new_pte, pte_mksoft_dirty(pte));
+ pte = move_soft_dirty_pte(pte);
+ set_pte_at(mm, new_addr, new_pte, pte);
}
arch_leave_lazy_mmu_mode();
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v8] KVM: PPC: reserve a capability and ioctl numbers for realmode VFIO
On 08/27/2013 05:56 PM, Gleb Natapov wrote:
On Thu, Aug 15, 2013 at 05:49:26PM +1000, Alexey Kardashevskiy wrote:
This is to reserve a capablity number for upcoming support
of VFIO-IOMMU DMA operations in real mode.
The last ioctl in the group which KVM_CREATE_SPAPR_TCE_IOMMU is added to
is 0xac, the next two numbers are taken - 0xad for KVM_KVMCLOCK_CTRL and
0xac was also taken by KVM_SET_ONE_REG :(
0xae for KVM_ARM_VCPU_INIT. So the KVM_CREATE_SPAPR_TCE_IOMMU ioclt gets
0xaf.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
2013/08/15 v8:
* fixed comment again
2013/08/15:
* fixed mistype in comments
* fixed commit message which says what uses ioctls 0xad and 0xae
2013/07/16:
* changed the number
2013/07/11:
* changed order in a file, added comment about a gap in ioctl number
---
include/uapi/linux/kvm.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 99c2533..bd94127 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -668,6 +668,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_IRQ_XICS 92
#define KVM_CAP_ARM_EL1_32BIT 93
#define KVM_CAP_SPAPR_MULTITCE 94
+#define KVM_CAP_SPAPR_TCE_IOMMU 95
#ifdef KVM_CAP_IRQ_ROUTING
@@ -933,6 +934,11 @@ struct kvm_s390_ucas_mapping {
#define KVM_ARM_SET_DEVICE_ADDR _IOW(KVMIO, 0xab, struct
kvm_arm_device_addr)
/* Available with KVM_CAP_PPC_RTAS */
#define KVM_PPC_RTAS_DEFINE_TOKEN _IOW(KVMIO, 0xac, struct
kvm_rtas_token_args)
+/* 0xad is taken by KVM_KVMCLOCK_CTRL */
+/* 0xae is taken by KVM_ARM_VCPU_INIT */
+/* Available with KVM_CAP_SPAPR_TCE_IOMMU */
+#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xaf, \
+struct kvm_create_spapr_tce_iommu)
Why not use KVM_CREATE_DEVICE API for that?
Because when I came up with my ioctl first time, it was not in upstream and
since then nobody pointed me to this new ioctl :)
So my stuff is not going to upstream again. Heh. Ok. I'll implement it.
/* ioctl for vm fd */
#define KVM_CREATE_DEVICE _IOWR(KVMIO, 0xe0, struct kvm_create_device)
--
Alexey
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] iio: ti_am335x_adc: Add continuous sampling support
On Sun, 25 Aug 2013, Zubair Lutfullah wrote:
Previously the driver had only one-shot reading functionality.
This patch adds triggered buffer support to the driver.
Continuous sampling starts when buffer is enabled.
And samples are pushed to userpace by the trigger which
triggers automatically at every hardware interrupt
of FIFO1 filling with samples upto threshold value.
Userspace responsibility to stop sampling by writing zero
in the buffer enable file.
Patil Rachna (TI) laid the ground work for ADC HW register access.
Russ Dill (TI) fixed bugs in the driver relevant to FIFOs and IRQs.
I fixed channel scanning so multiple ADC channels can be read
simultaneously and pushed to userspace.
Restructured the driver to fit IIO ABI.
And added trigger support.
Signed-off-by: Zubair Lutfullah zubair.lutful...@gmail.com
Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Russ Dill russ.d...@ti.com
---
drivers/iio/adc/ti_am335x_adc.c | 254
+++---
include/linux/mfd/ti_am335x_tscadc.h | 13 ++
2 files changed, 246 insertions(+), 21 deletions(-)
MFD stuff looks okay to me.
Acked-by: Lee Jones lee.jo...@linaro.org
snip
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index db1791b..a372ebf 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -46,17 +46,25 @@
/* Step Enable */
#define STEPENB_MASK (0x1 0)
#define STEPENB(val) ((val) 0)
+#define ENB(val) (1 (val))
+#define STPENB_STEPENB STEPENB(0x1)
+#define STPENB_STEPENB_TCSTEPENB(0x1FFF)
/* IRQ enable */
#define IRQENB_HW_PENBIT(0)
#define IRQENB_FIFO0THRESBIT(2)
+#define IRQENB_FIFO0OVRRUN BIT(3)
+#define IRQENB_FIFO0UNDRFLW BIT(4)
#define IRQENB_FIFO1THRESBIT(5)
+#define IRQENB_FIFO1OVRRUN BIT(6)
+#define IRQENB_FIFO1UNDRFLW BIT(7)
#define IRQENB_PENUP BIT(9)
/* Step Configuration */
#define STEPCONFIG_MODE_MASK (3 0)
#define STEPCONFIG_MODE(val) ((val) 0)
#define STEPCONFIG_MODE_HWSYNC STEPCONFIG_MODE(2)
+#define STEPCONFIG_MODE_SWCNTSTEPCONFIG_MODE(1)
#define STEPCONFIG_AVG_MASK (7 2)
#define STEPCONFIG_AVG(val) ((val) 2)
#define STEPCONFIG_AVG_16STEPCONFIG_AVG(4)
@@ -124,6 +132,7 @@
#define MAX_CLK_DIV 7
#define TOTAL_STEPS 16
#define TOTAL_CHANNELS 8
+#define FIFO1_THRESHOLD 19
/*
* ADC runs at 3MHz, and it takes
@@ -153,6 +162,10 @@ struct ti_tscadc_dev {
/* adc device */
struct adc_device *adc;
+
+ /* Context save */
+ unsigned int irqstat;
+ unsigned int ctrl;
};
static inline struct ti_tscadc_dev *ti_tscadc_dev_get(struct platform_device
*p)
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [guv v2 20/31] powerpc: Replace __get_cpu_var uses
On Mon, Aug 26, 2013 at 10:44 PM, Christoph Lameter c...@linux.com wrote:
__get_cpu_var() is used for multiple purposes in the kernel source. One of
them is
address calculation via the form __get_cpu_var(x). This calculates the
address for
the instance of the percpu variable of the current processor based on an
offset.
Others usage cases are for storing and retrieving data from the current
processors percpu area.
use cases
__get_cpu_var() always only does a address determination. However, store and
retrieve operations
an address
This patch converts __get_cpu_var into either and explicit address
calculation using this_cpu_ptr()
an explicit
4. Retrieve the content of a percpu struct
DEFINE_PER_CPU(struct mystruct, y);
struct mystruct x = __get_cpu_var(y);
Converts to
memcpy(this_cpu_ptr(y), x, sizeof(x));
Let's hope the actual code copies in the other direction ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
