RE: [PATCH] Input: Add new driver into Input Subsystem for Synaptics DS4 touchscreen I2C devices
From: Henrik Rydberg Sent: Thursday, October 04, 2012 2:01 AM > It seems this driver is already present in staging. Comments and > formatting have been improved in the staging version, but that aside, > the two versions look very similar. Why don't you submit fixes to > that driver instead? > On a general note, both versions of the driver use MT-A. Please > convert to MT-B, using the in-kernel tracking if necessary. Hi Henrik, Appreciate your suggestion! We are going to update a patch of using MT-B, because Synaptics devices are capable of tracking identifiable contacts (type B). Thanks for pointing out this. You are right, there is already a synaptics_i2c_rmi4 driver in staging state (drivers/staging/ste_rmi4). Actually synaptics_ds4_i2c driver is developed based on synaptics_i2c_rmi4 driver. The point is that we would want to make a clear definition that synaptics_ds4_i2c only targets to DS4 family, so that we can keep maintaining driver focusing on DS4 product line (not all Synaptics touchscreen devices are DS4 compatible). We are open to discuss if it is appropriate to retained DS4 driver, and please let us know if you have any concerns. Best Regards, Alexandra Chin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] virtio-net: inline header support
Anthony Liguori writes: > Rusty Russell writes: > >> "Michael S. Tsirkin" writes: >> >> There's a reason I haven't done this. I really, really dislike "my >> implemention isn't broken" feature bits. We could have an infinite >> number of them, for each bug in each device. >> >> So my plan was to tie this assumption to the new PCI layout. And have a >> stress-testing patch like the one below in the kernel (see my virtio-wip >> branch for stuff like this). Turn it on at boot with >> "virtio_ring.torture" on the kernel commandline. >> >> BTW, I've fixed lguest, but my kvm here (Ubuntu precise, kvm-qemu 1.0) >> is too old. Building the latest git now... >> >> Cheers, >> Rusty. >> >> Subject: virtio: CONFIG_VIRTIO_DEVICE_TORTURE >> >> Virtio devices are not supposed to depend on the framing of the >> scatter-gather >> lists, but various implementations did. Safeguard this in future by adding >> an option to deliberately create perverse descriptors. >> >> Signed-off-by: Rusty Russell > > Ignore framing is really a bad idea. You want backends to enforce > reasonable framing because guest's shouldn't do silly things with framing. > > For instance, with virtio-blk, if you want decent performance, you > absolutely want to avoid bouncing the data. If you're using O_DIRECT in > the host to submit I/O requests, then it's critical that all of the s/g > elements are aligned to a sector boundary and sized to a sector > boundary. > > Yes, QEMU can handle if that's not the case, but it would be insanely > stupid for a guest not to do this. This is the sort of thing that ought > to be enforced in the specification because a guest cannot perform well > if it doesn't follow these rules. Lack of imagination is what got us into trouble in the first place; when presented with one counter-example, it's useful to look for others. That's our job, not to dismiss them a "insanely stupid". For example: 1) Perhaps the guest isn't trying to perform well, it's trying to be a tiny bootloader? 2) Perhaps the guest is the direct consumer, and aligning buffers is redundant. > A spec isn't terribly useful if the result is guest drivers that are > slow. There's very little to gain by not enforcing rules around framing > and there's a lot to lose if a guest frames incorrectly. The guest has the flexibility, and gets to decide. The spec is not forcing them to perform badly. > In the rare case where we want to make a framing change, we should use > feature bits like Michael is proposing. > > In this case, we should simply say that with the feature bit, the vnet > header can be in the same element as the data but not allow the header > to be spread across multiple elements. I'd love to split struct virtio_net_hdr_mrg_rxbuf, so the num_buffers ends up somewhere else. The simplest rules are "never" or "always". Cheers, Rusty. PS. Inserting zero-length buffers is something I'd be prepared to rule out, my current patch does it just for yuks... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] module: add syscall to load module from fd
Kees Cook writes: > On Thu, Sep 20, 2012 at 3:14 PM, Kees Cook wrote: >> As part of the effort to create a stronger boundary between root and >> kernel, Chrome OS wants to be able to enforce that kernel modules are >> being loaded only from our read-only crypto-hash verified (dm_verity) >> root filesystem. Since the init_module syscall hands the kernel a module >> as a memory blob, no reasoning about the origin of the blob can be made. >> >> Earlier proposals for appending signatures to kernel modules would not be >> useful in Chrome OS, since it would involve adding an additional set of >> keys to our kernel and builds for no good reason: we already trust the >> contents of our root filesystem. We don't need to verify those kernel >> modules a second time. Having to do signature checking on module loading >> would slow us down and be redundant. All we need to know is where a >> module is coming from so we can say yes/no to loading it. >> >> If a file descriptor is used as the source of a kernel module, many more >> things can be reasoned about. In Chrome OS's case, we could enforce that >> the module lives on the filesystem we expect it to live on. In the case >> of IMA (or other LSMs), it would be possible, for example, to examine >> extended attributes that may contain signatures over the contents of >> the module. >> >> This introduces a new syscall (on x86), similar to init_module, that has >> only two arguments. The first argument is used as a file descriptor to >> the module and the second argument is a pointer to the NULL terminated >> string of module arguments. > > Hi Rusty, > > Is this likely to land in the 3.7 change window? I'd really like to > get the syscall number assigned so I can start sending patches to > glibc, kmod, etc. My tree is here, FWIW: No, unfortunately it's a little late and there were issues with ARM signoffs and syscall numbers... > http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/module-fd-syscall Messy merge due to the module signing stuff going in :( Please rebase on top of my kernel.org modules-next branch, and I'll pull into my modules-wip branch for 3.8. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] perf tools: Complete tracepoint event names
From: Namhyung Kim
Currently tracepoint events cannot be completed because they contain a
colon (:) character. The colon is considered as a word separator when
bash completion is done - variable COMP_WORDBREAKS contains colon - so
if a word being completed contains a colon it can be a problem.
Recent versions of bash completion provide -n switch to
_get_comp_words_by_ref and __ltrim_colon_completions functions in
order to resolve this issue. Copy the latter in case not exists.
Cc: Frederic Weisbecker
Cc: David Ahern
Signed-off-by: Namhyung Kim
---
This patch is based on my previous completion updates set.
tools/perf/bash_completion | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/tools/perf/bash_completion b/tools/perf/bash_completion
index 5c355ababf80..56e6a12aab59 100644
--- a/tools/perf/bash_completion
+++ b/tools/perf/bash_completion
@@ -6,6 +6,19 @@ function_exists()
return $?
}
+function_exists __ltrim_colon_completions ||
+__ltrim_colon_completions()
+{
+ if [[ "$1" == *:* && "$COMP_WORDBREAKS" == *:* ]]; then
+ # Remove colon-word prefix from COMPREPLY items
+ local colon_word=${1%${1##*:}}
+ local i=${#COMPREPLY[*]}
+ while [[ $((--i)) -ge 0 ]]; do
+ COMPREPLY[$i]=${COMPREPLY[$i]#"$colon_word"}
+ done
+ fi
+}
+
have perf &&
_perf()
{
@@ -13,9 +26,9 @@ _perf()
COMPREPLY=()
if function_exists _get_comp_words_by_ref; then
- _get_comp_words_by_ref cur prev
+ _get_comp_words_by_ref -n : cur prev
else
- cur=$(_get_cword)
+ cur=$(_get_cword :)
prev=${COMP_WORDS[COMP_CWORD-1]}
fi
@@ -35,6 +48,7 @@ _perf()
elif [[ $prev == "-e" && "${COMP_WORDS[1]}" == @(record|stat|top) ]];
then
evts=$($cmd list --raw-dump)
COMPREPLY=( $( compgen -W '$evts' -- "$cur" ) )
+ __ltrim_colon_completions $cur
# List long option names
elif [[ $cur == --* ]]; then
subcmd=${COMP_WORDS[1]}
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc/iommu: Fix multiple issues with IOMMU pools code
Hi Alex,
Looks to be a preempt issue with the iommu pools code. I did find a
couple more bugs along the way too.
Anton
--
There are a number of issues in the recent IOMMU pools code:
- On a preempt kernel we might switch CPUs in the middle of building
a scatter gather list. When this happens the handle hint passed in
no longer falls within the local CPU's pool. Check for this and
fall back to the pool hint.
- We were missing a spin_unlock/spin_lock in one spot where we
switch pools.
- We need to provide locking around dart_tlb_invalidate_all and
dart_tlb_invalidate_one now that the global lock is gone.
Reported-by: Alexander Graf
Signed-off-by: Anton Blanchard
---
There is still an issue with the lazy u3 flushing, but I wanted
to get this out for testing.
Index: b/arch/powerpc/kernel/iommu.c
===
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -215,7 +215,8 @@ static unsigned long iommu_range_alloc(s
spin_lock_irqsave(&(pool->lock), flags);
again:
- if ((pass == 0) && handle && *handle)
+ if ((pass == 0) && handle && *handle &&
+ (*handle >= pool->start) && (*handle < pool->end))
start = *handle;
else
start = pool->hint;
@@ -236,7 +237,9 @@ again:
* but on second pass, start at 0 in pool 0.
*/
if ((start & mask) >= limit || pass > 0) {
+ spin_unlock(&(pool->lock));
pool = &(tbl->pools[0]);
+ spin_lock(&(pool->lock));
start = pool->start;
} else {
start &= mask;
Index: b/arch/powerpc/sysdev/dart_iommu.c
===
--- a/arch/powerpc/sysdev/dart_iommu.c
+++ b/arch/powerpc/sysdev/dart_iommu.c
@@ -74,11 +74,16 @@ static int dart_is_u4;
#define DBG(...)
+static DEFINE_SPINLOCK(invalidate_lock);
+
static inline void dart_tlb_invalidate_all(void)
{
unsigned long l = 0;
unsigned int reg, inv_bit;
unsigned long limit;
+ unsigned long flags;
+
+ spin_lock_irqsave(_lock, flags);
DBG("dart: flush\n");
@@ -111,12 +116,17 @@ retry:
panic("DART: TLB did not flush after waiting a long "
"time. Buggy U3 ?");
}
+
+ spin_unlock_irqrestore(_lock, flags);
}
static inline void dart_tlb_invalidate_one(unsigned long bus_rpn)
{
unsigned int reg;
unsigned int l, limit;
+ unsigned long flags;
+
+ spin_lock_irqsave(_lock, flags);
reg = DART_CNTL_U4_ENABLE | DART_CNTL_U4_IONE |
(bus_rpn & DART_CNTL_U4_IONE_MASK);
@@ -138,6 +148,8 @@ wait_more:
panic("DART: TLB did not flush after waiting a long "
"time. Buggy U4 ?");
}
+
+ spin_unlock_irqrestore(_lock, flags);
}
static void dart_flush(struct iommu_table *tbl)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 signal tree with the modules and arm-soc trees
Hi Al,
Today's linux-next merge of the signal tree got conflicts in
arch/avr32/include/asm/Kbuild, arch/cris/include/asm/Kbuild,
arch/frv/include/asm/Kbuild, arch/h8300/include/asm/Kbuild,
arch/ia64/include/asm/Kbuild, arch/m32r/include/asm/Kbuild,
arch/microblaze/include/asm/Kbuild, arch/mn10300/include/asm/Kbuild and
arch/xtensa/include/asm/Kbuild between commit e7a570ff7dff ("asm-generic:
Add default clkdev.h") from the arm-soc tree, commit 786d35d45cc4 ("Make
most arch asm/module.h files use asm-generic/module.h") from the modules
tree and commit ddd03a1f7591 ("get rid of generic instances of
asm/exec.h") from the signal 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/avr32/include/asm/Kbuild
index e3ba7bc,aa47fff..000
--- a/arch/avr32/include/asm/Kbuild
+++ b/arch/avr32/include/asm/Kbuild
@@@ -1,5 -1,4 +1,6 @@@
include include/asm-generic/Kbuild.asm
+generic-y += clkdev.h
+ generic-y += exec.h
+
header-y += cachectl.h
diff --cc arch/cris/include/asm/Kbuild
index 6900bbf,b68ad4b..000
--- a/arch/cris/include/asm/Kbuild
+++ b/arch/cris/include/asm/Kbuild
@@@ -8,5 -8,4 +8,6 @@@ header-y += etraxgpio.
header-y += rs485.h
header-y += sync_serial.h
+generic-y += module.h
+generic-y += clkdev.h
+ generic-y += exec.h
diff --cc arch/frv/include/asm/Kbuild
index 13cd044,32c1646..000
--- a/arch/frv/include/asm/Kbuild
+++ b/arch/frv/include/asm/Kbuild
@@@ -2,4 -2,4 +2,6 @@@ include include/asm-generic/Kbuild.as
header-y += registers.h
header-y += termios.h
++
+generic-y += clkdev.h
+ generic-y += exec.h
diff --cc arch/h8300/include/asm/Kbuild
index 98477e9,3a2af1a..000
--- a/arch/h8300/include/asm/Kbuild
+++ b/arch/h8300/include/asm/Kbuild
@@@ -1,4 -1,2 +1,5 @@@
include include/asm-generic/Kbuild.asm
+
+generic-y += module.h
+generic-y += clkdev.h
+ generic-y += exec.h
diff --cc arch/ia64/include/asm/Kbuild
index 58f3d14,98efd48..000
--- a/arch/ia64/include/asm/Kbuild
+++ b/arch/ia64/include/asm/Kbuild
@@@ -13,4 -13,4 +13,6 @@@ header-y += ptrace_offsets.
header-y += rse.h
header-y += ucontext.h
header-y += ustack.h
++
+generic-y += clkdev.h
+ generic-y += exec.h
diff --cc arch/m32r/include/asm/Kbuild
index 98477e9,7083403..000
--- a/arch/m32r/include/asm/Kbuild
+++ b/arch/m32r/include/asm/Kbuild
@@@ -1,4 -1,3 +1,5 @@@
include include/asm-generic/Kbuild.asm
+generic-y += module.h
+generic-y += clkdev.h
+ generic-y += exec.h
diff --cc arch/microblaze/include/asm/Kbuild
index 48510f6,5a0e72b..000
--- a/arch/microblaze/include/asm/Kbuild
+++ b/arch/microblaze/include/asm/Kbuild
@@@ -1,4 -1,4 +1,6 @@@
include include/asm-generic/Kbuild.asm
header-y += elf.h
++
+generic-y += clkdev.h
+ generic-y += exec.h
diff --cc arch/mn10300/include/asm/Kbuild
index 0d20f55,7083403..000
--- a/arch/mn10300/include/asm/Kbuild
+++ b/arch/mn10300/include/asm/Kbuild
@@@ -1,3 -1,3 +1,4 @@@
include include/asm-generic/Kbuild.asm
+generic-y += clkdev.h
+ generic-y += exec.h
diff --cc arch/xtensa/include/asm/Kbuild
index 0d20f55,7083403..000
--- a/arch/xtensa/include/asm/Kbuild
+++ b/arch/xtensa/include/asm/Kbuild
@@@ -1,3 -1,3 +1,4 @@@
include include/asm-generic/Kbuild.asm
+generic-y += clkdev.h
+ generic-y += exec.h
pgpplwjW23MGj.pgp
Description: PGP signature
Re: [PATCH] ARM: davinci: dm644x: fix out range signal for ED
Hi Sekhar, On Wed, Oct 3, 2012 at 4:08 PM, Sekhar Nori wrote: > On 10/3/2012 12:05 PM, Prabhakar wrote: >> From: Lad, Prabhakar >> >> while testing display on dm644x, for ED out-range signals >> was observed. This patch fixes appropriate clock setting >> for ED. > > Can you please clarify what you mean by "out range signal"? Are there > any user visible artifacts on the display? What was the clock being > provided earlier and what is the value after this patch? > > Also, is the issue severe enough that this patch should be applied to > stable tree as well? > Ideally a clock of 54Mhz is required for enhanced definition to work, which it was actually set to but while testing I noticed out-of-range signal. The out-of-range signal is often caused when the field rate is above the rate that the television will handle. When this is the case the TV or monitor displays "Out-Of-Range Signal". Reducing the clock fixed it. now the clock is set to 27Mhz. Regards, --Prabhakar > Thanks, > Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v1 1/3] cpuidle: (POWER) Fix target residency initialisation in pseries cpuidle
Remove the redundant target residency initialisation in pseries_cpuidle_driver_init(). This is currently over-writing the residency time updated as part of the static table, resulting in all the idle states having the same target residency of 100us which is incorrect. This may result in the menu governor making wrong state decisions. Signed-off-by: Deepthi Dharwar --- arch/powerpc/platforms/pseries/processor_idle.c |4 1 file changed, 4 deletions(-) diff --git a/arch/powerpc/platforms/pseries/processor_idle.c b/arch/powerpc/platforms/pseries/processor_idle.c index 455760b..02e425a 100644 --- a/arch/powerpc/platforms/pseries/processor_idle.c +++ b/arch/powerpc/platforms/pseries/processor_idle.c @@ -246,10 +246,6 @@ static int pseries_cpuidle_driver_init(void) drv->states[drv->state_count] = /* structure copy */ cpuidle_state_table[idle_state]; - if (cpuidle_state_table == dedicated_states) - drv->states[drv->state_count].target_residency = - __get_cpu_var(smt_snooze_delay); - drv->state_count += 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 v1 3/3] cpuidle: (POWER) Fix snooze state problem persistant in the current cpuidle design on pseries.
Earlier without cpuidle framework on pseries, the native arch
idle routine comprised of both snooze and nap
states. smt_snooze_delay variable was used to delay
the idle process entry to deeper idle state like nap.
With the coming of cpuidle, this arch specific idle was replaced
by two different idle routines, one for supporting snooze and other
for nap. This enabled addition of more
low level idle states on pseries in the future.
On adopting the generic cpuidle framework for POWER systems,
the decision of which idle state to choose from, given a predicted
idle time is taken by the menu governor based on
target_residency and exit_latency of the idle states.
target_residency is the minimum time to be resident in that idle state.
Exit_latency is time taken to exit out of idle state.
Deeper the idle state, both the target residency and exit latency
would be higher.
In the current design, smt_snooze_delay is used as target_residency
for the snooze state which is incorrect, as it is not the
minimum but the maximum duration to be in snooze state.
This would result in the governor in taking bad decision,
as presently target_residency of nap < target_residency of snooze
inspite of nap being deeper idle state.
This patch aims to fix this problem by replacing the smt_snooze_delay loop
in snooze state, with the need_resched() as the governor is aware of
entry and exit of various idle transitions based on which
next idle time prediction.
The governor is intelligent enough to determine the idle state the needs to
be transitioned to and maintains a whole of heuristics including
io load, previous idle states predictions etc for the same, based on
which idle state entry decision is taken.
With this fix, of setting target_residency of snooze to 0
nap to smt_snooze_delay
if the predicted idle time is less
than smt_snooze_delay (target_residency of nap)
value governor would pick snooze state, else nap. This adhers to the
previous native idle design.
Signed-off-by: Deepthi Dharwar
---
arch/powerpc/platforms/pseries/processor_idle.c | 36 ---
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
b/arch/powerpc/platforms/pseries/processor_idle.c
index a32d56d..45d00e5 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -59,32 +59,22 @@ static int snooze_loop(struct cpuidle_device *dev,
{
unsigned long in_purr;
ktime_t kt_before;
- unsigned long start_snooze;
- long snooze = drv->states[0].target_residency;
+ int cpu = dev->cpu;
idle_loop_prolog(_purr, _before);
+ local_irq_enable();
+ set_thread_flag(TIF_POLLING_NRFLAG);
- if (snooze) {
- start_snooze = get_tb() + snooze * tb_ticks_per_usec;
- local_irq_enable();
- set_thread_flag(TIF_POLLING_NRFLAG);
-
- while ((snooze < 0) || (get_tb() < start_snooze)) {
- if (need_resched() || cpu_is_offline(dev->cpu))
- goto out;
- ppc64_runlatch_off();
- HMT_low();
- HMT_very_low();
- }
-
- HMT_medium();
- clear_thread_flag(TIF_POLLING_NRFLAG);
- smp_mb();
- local_irq_disable();
+ while ((!need_resched()) && cpu_online(cpu)) {
+ ppc64_runlatch_off();
+ HMT_low();
+ HMT_very_low();
}
-out:
HMT_medium();
+ clear_thread_flag(TIF_POLLING_NRFLAG);
+ smp_mb();
+
dev->last_residency =
(int)idle_loop_epilog(in_purr, kt_before);
return index;
@@ -165,8 +155,8 @@ static struct cpuidle_state
dedicated_states[MAX_IDLE_STATE_COUNT] = {
.name = "CEDE",
.desc = "CEDE",
.flags = CPUIDLE_FLAG_TIME_VALID,
- .exit_latency = 1,
- .target_residency = 10,
+ .exit_latency = 10,
+ .target_residency = 100,
.enter = _cede_loop },
};
@@ -197,7 +187,7 @@ void update_smt_snooze_delay(int cpu, int residency)
dev->states_usage[1].disable = 1;
} else
if (drv)
- drv->states[0].target_residency = residency;
+ drv->states[1].target_residency = residency;
}
static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 2/3] cpuidle: (POWER) Fix smt_snooze_delay functionality.
smt_snooze_delay was designed to delay idle loop's nap entry
in the native idle code before it got ported over to use as part of
the cpuidle framework.
A -ve value assigned to smt_snooze_delay should result in
busy looping, in other words disabling the entry to nap state.
- https://lists.ozlabs.org/pipermail/linuxppc-dev/2010-May/082450.html
This particular functionality can be achieved currently by
echo 1 > /sys/devices/system/cpu/cpu*/state1/disable
but it is broken when one assigns -ve value to the smt_snooze_delay
variable either via sysfs entry or ppc64_cpu util.
This patch aims to fix this, by disabling nap state when smt_snooze_delay
variable is set to -ve value.
Signed-off-by: Deepthi Dharwar
---
arch/powerpc/include/asm/processor.h|4 ++--
arch/powerpc/kernel/sysfs.c |2 +-
arch/powerpc/platforms/pseries/processor_idle.c | 24 ---
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index 54b73a2..d0a5fb8 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -389,9 +389,9 @@ extern int powersave_nap; /* set if nap mode can be used
in idle loop */
extern void power7_nap(void);
#ifdef CONFIG_PSERIES_IDLE
-extern void update_smt_snooze_delay(int snooze);
+extern void update_smt_snooze_delay(int cpu, int residency);
#else
-static inline void update_smt_snooze_delay(int snooze) {}
+static inline void update_smt_snooze_delay(int cpu, int residency) {}
#endif
extern void flush_instruction_cache(void);
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 8302af6..cf357a0 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -50,7 +50,7 @@ static ssize_t store_smt_snooze_delay(struct device *dev,
return -EINVAL;
per_cpu(smt_snooze_delay, cpu->dev.id) = snooze;
- update_smt_snooze_delay(snooze);
+ update_smt_snooze_delay(cpu->dev.id, snooze);
return count;
}
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
b/arch/powerpc/platforms/pseries/processor_idle.c
index 02e425a..a32d56d 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -33,13 +33,6 @@ static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
static struct cpuidle_device __percpu *pseries_cpuidle_devices;
static struct cpuidle_state *cpuidle_state_table;
-void update_smt_snooze_delay(int snooze)
-{
- struct cpuidle_driver *drv = cpuidle_get_driver();
- if (drv)
- drv->states[0].target_residency = snooze;
-}
-
static inline void idle_loop_prolog(unsigned long *in_purr, ktime_t *kt_before)
{
@@ -190,6 +183,23 @@ static struct cpuidle_state
shared_states[MAX_IDLE_STATE_COUNT] = {
.enter = _cede_loop },
};
+void update_smt_snooze_delay(int cpu, int residency)
+{
+ struct cpuidle_driver *drv = cpuidle_get_driver();
+ struct cpuidle_device *dev = per_cpu(cpuidle_devices, cpu);
+
+ if (cpuidle_state_table != dedicated_states)
+ return;
+
+ if (residency < 0) {
+ /* Disable the Nap state on that cpu */
+ if (dev)
+ dev->states_usage[1].disable = 1;
+ } else
+ if (drv)
+ drv->states[0].target_residency = residency;
+}
+
static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
unsigned long action, void *hcpu)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v1 0/3] cpuidle: (pSeries) pseries idle driver fixes.
The following series consists of a bunch of fixes for cpuidle back-end driver for ppc64 (pSeries) platform. The series applies on 3.6-rc7 and has been tested on ppc64 pSeries POWER7 system with snooze and nap states. With these fixes, avg idle residency for nap on 50 percent idle system increased from 96 to 99.4 percent and idle residency for snooze for the same decreased from 4 to 0.6 percent, determined running spec power benchmark runs. Deepthi Dharwar (3): cpuidle: (POWER) Fix snooze state problem persistant in the current cpuidle design on pseries. cpuidle: (POWER) Fix smt_snooze_delay functionality. cpuidle: (POWER) Fix target residency initialisation in pseries cpuidle arch/powerpc/include/asm/processor.h|4 + arch/powerpc/kernel/sysfs.c |2 - arch/powerpc/platforms/pseries/processor_idle.c | 62 +++ 3 files changed, 32 insertions(+), 36 deletions(-) -- Deepthi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] media: mt9p031/mt9t001/mt9v032: use V4L2_CID_TEST_PATTERN for test pattern control
Hi Laurent, On Wed, Oct 3, 2012 at 7:43 PM, Laurent Pinchart wrote: > Hi Prabhakar, > > On Wednesday 03 October 2012 19:23:05 Prabhakar wrote: >> From: Lad, Prabhakar >> >> V4L2_CID_TEST_PATTERN is now a standard control. >> This patch replaces the user defined control for test >> pattern to make use of standard control V4L2_CID_TEST_PATTERN. >> >> Signed-off-by: Lad, Prabhakar >> Signed-off-by: Manjunath Hadli >> Acked-by: Laurent Pinchart >> Cc: Sakari Ailus >> Cc: Paul Gortmaker >> Cc: Jean Delvare > > Should I push this patch through my tree ? If so I'll wait until the > V4L2_CID_TEST_PATTERN control patch hits Mauro's tree. > I will issue a pull request for this patch plus V4L2_CID_TEST_PATTERN today thanks. Regards, --Prabhakar > -- > Regards, > > Laurent Pinchart > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 04/10] sched: Introduce priority-based task migration filter
On 22 September 2012 00:02, wrote: Hi Morten, I would try to review your patches in coming days. For now, Just reporting a problem which i encountered during routine build. > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 490f1f0..8f0f3b9 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -3129,9 +3129,12 @@ static int __init hmp_cpu_mask_setup(void) > * hmp_down_threshold: max. load allowed for tasks migrating to a slower cpu > * The default values (512, 256) offer good responsiveness, but may need > * tweaking suit particular needs. > + * > + * hmp_up_prio: Only up migrate task with high priority ( */ > unsigned int hmp_up_threshold = 512; > unsigned int hmp_down_threshold = 256; #ifdef CONFIG_SCHED_HMP_PRIO_FILTER > +unsigned int hmp_up_prio = NICE_TO_PRIO(CONFIG_SCHED_HMP_PRIO_FILTER_VAL); #endif is required here for successful build without CONFIG_SCHED_HMP_PRIO_FILTER_VAL. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/x86/include/asm/Kbuild between commit 10b63956fce7 ("UAPI: Plumb the
UAPI Kbuilds into the user header installation and checking") from Linus'
tree and commit e7a570ff7dff ("asm-generic: Add default clkdev.h") 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/x86/include/asm/Kbuild
index 1595d68,66e5f0e..000
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@@ -22,3 -22,9 +22,5 @@@ header-y += sigcontext32.
header-y += ucontext.h
header-y += vm86.h
header-y += vsyscall.h
+
-genhdr-y += unistd_32.h
-genhdr-y += unistd_64.h
-genhdr-y += unistd_x32.h
-
+ generic-y += clkdev.h
pgp5wIov1BzU0.pgp
Description: PGP signature
linux-next: manual merge of the arm-soc tree with the modules tree
Hi all,
Today's linux-next merge of the arm-soc tree got conflicts in
arch/cris/include/asm/Kbuild, arch/h8300/include/asm/Kbuild and
arch/m32r/include/asm/Kbuild between commit 786d35d45cc4 ("Make most arch
asm/module.h files use asm-generic/module.h") from the modules tree and
commit e7a570ff7dff ("asm-generic: Add default clkdev.h") 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/cris/include/asm/Kbuild
index 28b690d,a8eab26..000
--- a/arch/cris/include/asm/Kbuild
+++ b/arch/cris/include/asm/Kbuild
@@@ -8,4 -8,4 +8,5 @@@ header-y += etraxgpio.
header-y += rs485.h
header-y += sync_serial.h
+generic-y += module.h
+ generic-y += clkdev.h
diff --cc arch/h8300/include/asm/Kbuild
index 871382d,0e152a9..000
--- a/arch/h8300/include/asm/Kbuild
+++ b/arch/h8300/include/asm/Kbuild
@@@ -1,3 -1,3 +1,4 @@@
include include/asm-generic/Kbuild.asm
+generic-y += module.h
+ generic-y += clkdev.h
diff --cc arch/m32r/include/asm/Kbuild
index 871382d,0e152a9..000
--- a/arch/m32r/include/asm/Kbuild
+++ b/arch/m32r/include/asm/Kbuild
@@@ -1,3 -1,3 +1,4 @@@
include include/asm-generic/Kbuild.asm
+generic-y += module.h
+ generic-y += clkdev.h
pgpkWMM8ze8gd.pgp
Description: PGP signature
Re: [PATCH 0/3] virtio-net: inline header support
Rusty Russell writes: > Anthony Liguori writes: >> Rusty Russell writes: >> >>> "Michael S. Tsirkin" writes: >>> Thinking about Sasha's patches, we can reduce ring usage for virtio net small packets dramatically if we put virtio net header inline with the data. This can be done for free in case guest net stack allocated extra head room for the packet, and I don't see why would this have any downsides. >>> >>> I've been wanting to do this for the longest time... but... >>> Even though with my recent patches qemu no longer requires header to be the first s/g element, we need a new feature bit to detect this. A trivial qemu patch will be sent separately. >>> >>> There's a reason I haven't done this. I really, really dislike "my >>> implemention isn't broken" feature bits. We could have an infinite >>> number of them, for each bug in each device. >> >> This is a bug in the specification. >> >> The QEMU implementation pre-dates the specification. All of the actual >> implementations of virtio relied on the semantics of s/g elements and >> still do. > > lguest fix is pending in my queue. lkvm and qemu are broken; lkvm isn't > ever going to be merged, so I'm not sure what its status is? But I'm > determined to fix qemu, and hence my torture patch to make sure this > doesn't creep in again. There are even more implementations out there and I'd wager they all rely on framing. >> What's in the specification really doesn't matter when it doesn't agree >> with all of the existing implementations. >> >> Users use implementations, not specifications. The specification really >> ought to be changed here. > > I'm sorely tempted, except that we're losing a real optimization because > of this :( What optimizations? What Michael is proposing is still achievable with a device feature. Are there other optimizations that can be achieved by changing framing that we can't achieve with feature bits? As I mentioned in another note, bad framing decisions can cause performance issues too... > The specification has long contained the footnote: > > The current qemu device implementations mistakenly insist that > the first descriptor cover the header in these cases exactly, so > a cautious driver should arrange it so. I seem to recall this being a compromise between you and I.. I think I objected strongly to this back when you first wrote the spec and you added this to appease me ;-) Regards, Anthony Liguori > > I'd like to tie this caveat to the PCI capability change, so this note > will move to the appendix with the old PCI layout. > > Cheers, > Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/6] Input: da9052_tsi.c: Fix interrupt handling
From: Fabio Estevam
Currently da9062_tsi does not probe and it fails as follows:
da9052 1-0048: Unable to determine device interrupts
Use the new da9052 irq functions and allow the driver to probe and operate
correctly.
Tested on mx53qsb board using 'evtest' tool.
Cc: Dmitry Torokhov
Cc:
Signed-off-by: Fabio Estevam
---
Changes since v2:
- Sent the correct patch now. v1 was the incorrect version.
drivers/input/touchscreen/da9052_tsi.c | 59 +++-
1 file changed, 20 insertions(+), 39 deletions(-)
diff --git a/drivers/input/touchscreen/da9052_tsi.c
b/drivers/input/touchscreen/da9052_tsi.c
index e8df341..33fd3fa 100644
--- a/drivers/input/touchscreen/da9052_tsi.c
+++ b/drivers/input/touchscreen/da9052_tsi.c
@@ -27,8 +27,6 @@ struct da9052_tsi {
struct input_dev *dev;
struct delayed_work ts_pen_work;
struct mutex mutex;
- unsigned int irq_pendwn;
- unsigned int irq_datardy;
bool stopped;
bool adc_on;
};
@@ -45,8 +43,8 @@ static irqreturn_t da9052_ts_pendwn_irq(int irq, void *data)
if (!tsi->stopped) {
/* Mask PEN_DOWN event and unmask TSI_READY event */
- disable_irq_nosync(tsi->irq_pendwn);
- enable_irq(tsi->irq_datardy);
+ da9052_disable_irq_nosync(tsi->da9052, DA9052_IRQ_PENDOWN);
+ da9052_enable_irq(tsi->da9052, DA9052_IRQ_TSIREADY);
da9052_ts_adc_toggle(tsi, true);
@@ -137,8 +135,8 @@ static void da9052_ts_pen_work(struct work_struct *work)
return;
/* Mask TSI_READY event and unmask PEN_DOWN event */
- disable_irq(tsi->irq_datardy);
- enable_irq(tsi->irq_pendwn);
+ da9052_disable_irq(tsi->da9052, DA9052_IRQ_TSIREADY);
+ da9052_enable_irq(tsi->da9052, DA9052_IRQ_PENDOWN);
}
}
}
@@ -197,7 +195,7 @@ static int da9052_ts_input_open(struct input_dev *input_dev)
mb();
/* Unmask PEN_DOWN event */
- enable_irq(tsi->irq_pendwn);
+ da9052_enable_irq(tsi->da9052, DA9052_IRQ_PENDOWN);
/* Enable Pen Detect Circuit */
return da9052_reg_update(tsi->da9052, DA9052_TSI_CONT_A_REG,
@@ -210,11 +208,11 @@ static void da9052_ts_input_close(struct input_dev
*input_dev)
tsi->stopped = true;
mb();
- disable_irq(tsi->irq_pendwn);
+ da9052_disable_irq(tsi->da9052, DA9052_IRQ_PENDOWN);
cancel_delayed_work_sync(>ts_pen_work);
if (tsi->adc_on) {
- disable_irq(tsi->irq_datardy);
+ da9052_disable_irq(tsi->da9052, DA9052_IRQ_TSIREADY);
da9052_ts_adc_toggle(tsi, false);
/*
@@ -222,7 +220,7 @@ static void da9052_ts_input_close(struct input_dev
*input_dev)
* twice and we need to enable it to keep enable/disable
* counter balanced. IRQ is still off though.
*/
- enable_irq(tsi->irq_pendwn);
+ da9052_enable_irq(tsi->da9052, DA9052_IRQ_PENDOWN);
}
/* Disable Pen Detect Circuit */
@@ -234,21 +232,12 @@ static int __devinit da9052_ts_probe(struct
platform_device *pdev)
struct da9052 *da9052;
struct da9052_tsi *tsi;
struct input_dev *input_dev;
- int irq_pendwn;
- int irq_datardy;
int error;
da9052 = dev_get_drvdata(pdev->dev.parent);
if (!da9052)
return -EINVAL;
- irq_pendwn = platform_get_irq_byname(pdev, "PENDWN");
- irq_datardy = platform_get_irq_byname(pdev, "TSIRDY");
- if (irq_pendwn < 0 || irq_datardy < 0) {
- dev_err(da9052->dev, "Unable to determine device interrupts\n");
- return -ENXIO;
- }
-
tsi = kzalloc(sizeof(struct da9052_tsi), GFP_KERNEL);
input_dev = input_allocate_device();
if (!tsi || !input_dev) {
@@ -258,8 +247,6 @@ static int __devinit da9052_ts_probe(struct platform_device
*pdev)
tsi->da9052 = da9052;
tsi->dev = input_dev;
- tsi->irq_pendwn = da9052->irq_base + irq_pendwn;
- tsi->irq_datardy = da9052->irq_base + irq_datardy;
tsi->stopped = true;
INIT_DELAYED_WORK(>ts_pen_work, da9052_ts_pen_work);
@@ -287,31 +274,25 @@ static int __devinit da9052_ts_probe(struct
platform_device *pdev)
/* Disable ADC */
da9052_ts_adc_toggle(tsi, false);
- error = request_threaded_irq(tsi->irq_pendwn,
-NULL, da9052_ts_pendwn_irq,
-IRQF_TRIGGER_LOW | IRQF_ONESHOT,
-"PENDWN", tsi);
+ error = da9052_request_irq(tsi->da9052, DA9052_IRQ_PENDOWN,
+ "pendown-irq", da9052_ts_pendwn_irq, tsi);
if (error) {
dev_err(tsi->da9052->dev,
-
RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework
> On Wed, Oct 03, 2012 at 05:54:08AM +0200, Arun MURTHY wrote:
> > > On Mon, Oct 01, 2012 at 07:30:38AM +0200, Arun MURTHY wrote:
> > > > > On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +
> > > > > > +static struct class *modem_class;
> > > > >
> > > > > What's wrong with a bus_type instead?
> > > >
> > > > Can I know the advantage of using bus_type over class?
> > >
> > > You have devices living on a bus, and it's much more descriptive
> > > than a class (which we are going to eventually get rid of one of these
> days...).
> > >
> > > Might I ask why you choose a class over a bus_type?
> >
> > Basically my requirement is to create a central entity for accessing
> > and releasing modem from APE.
>
> What is an "APE"?
>
> And what do you mean by "accessing" and "releasing"?
APE - Application Processor Engine
There are two processors but on a single chip, one being the APE and other
is the modem. So 'accessing' means requesting access or waking-up the
co-processor and releasing means allowing the co-processor to sleep.
>
> > Since this is done by different clients the central entity should be
> > able to handle the request and play safely, since this has more affect
> > in system suspend and deep sleep. Using class helps me in achieving
> > this and also create an entry to user space which can be used in the
> > later parts. Moreover this not something like a bus or so, so I didn't
> > use bus instead went with a simple class approach.
>
> But as you have devices that are "binding" to this "controller", a bus might
> make more sense, right?
Have explained above regarding the platform, the concept of bus doesn't
come into picture at all. Here its just waking-up the modem and allowing
it to go to sleep.
>
> I don't see how a class helps out for you here more than anything else, what
> are you expecting from the class interface? You aren't using the reference
> counting logic it provides, so why use it at all?
I am using the reference counting logic in class such as class_for_each_device.
>
> Actually, why use the driver core at all in the first place if you aren't
> needing
> the devices to show up in sysfs (as you don't have a device, you are just a
> mediator)?
Yes I am something like a mediator, but since this is associated with many
clients, there should be some central entity to take inputs from all the clients
and act accordingly. This MAF does that. Sysfs will also be created for this
MAF in the coming versions.
>
> > > > > > +int modem_release(struct modem_desc *mdesc) {
> > > > > > + if (!mdesc->release)
> > > > > > + return -EFAULT;
> > > > > > +
> > > > > > + if (modem_is_requested(mdesc)) {
> > > > > > + atomic_dec(>mclients->cnt);
> > > > > > + if (atomic_read(>use_cnt) == 1) {
> > > > > > + mdesc->release(mdesc);
> > > > > > + atomic_dec(>use_cnt);
> > > > > > + }
> > > > >
> > > > > Eeek, why aren't you using the built-in reference counting that
> > > > > the struct device provided to you, and instead are rolling your own?
> > > > > This happens in many places, why?
> > > >
> > > > My usage of counters over here is for each modem there are many
> clients.
> > > > Each of the clients will have a ref to modem_desc. Each of them
> > > > use this for requesting and releasing the modem. One counter for
> > > > tracking the request and release for each client which is done by
> > > > variable 'cnt' in
> > > struct clients.
> > > > The counter use_cnt is used for tracking the modem request/release
> > > > irrespective of the clients and counter cli_cnt is used for
> > > > restricting the modem_get to the no of clients defined in no_clients.
> > > >
> > > > So totally 3 counter one for restricting the usage of modem_get by
> > > > clients, second for restricting modem request/release at top
> > > > level, and 3rd for restricting modem release/request for per
> > > > client per modem
> > > basis.
> > > >
> > > > Can you let me know if the same can be achieved by using built-in
> > > > ref counting?
> > >
> > > Yes, because you don't need all of those different levels, just
> > > stick with one and you should be fine. :)
> > >
> >
> > No, checks at all these levels are required, I have briefed out the need
> > also.
>
> I still don't understand, sorry.
The pictorial view by Anish should help in understanding.
Modem Client1 Client2Client3Client4
State turn-on request
State no-state-change request
State no-state-change request
State no-state-change request
State no-state-change release
State no-state-change release
State no-state-change release
State turn-off
Re: [PATCH 0/3] virtio-net: inline header support
Anthony Liguori writes: > Rusty Russell writes: > >> "Michael S. Tsirkin" writes: >> >>> Thinking about Sasha's patches, we can reduce ring usage >>> for virtio net small packets dramatically if we put >>> virtio net header inline with the data. >>> This can be done for free in case guest net stack allocated >>> extra head room for the packet, and I don't see >>> why would this have any downsides. >> >> I've been wanting to do this for the longest time... but... >> >>> Even though with my recent patches qemu >>> no longer requires header to be the first s/g element, >>> we need a new feature bit to detect this. >>> A trivial qemu patch will be sent separately. >> >> There's a reason I haven't done this. I really, really dislike "my >> implemention isn't broken" feature bits. We could have an infinite >> number of them, for each bug in each device. > > This is a bug in the specification. > > The QEMU implementation pre-dates the specification. All of the actual > implementations of virtio relied on the semantics of s/g elements and > still do. lguest fix is pending in my queue. lkvm and qemu are broken; lkvm isn't ever going to be merged, so I'm not sure what its status is? But I'm determined to fix qemu, and hence my torture patch to make sure this doesn't creep in again. > What's in the specification really doesn't matter when it doesn't agree > with all of the existing implementations. > > Users use implementations, not specifications. The specification really > ought to be changed here. I'm sorely tempted, except that we're losing a real optimization because of this :( The specification has long contained the footnote: The current qemu device implementations mistakenly insist that the first descriptor cover the header in these cases exactly, so a cautious driver should arrange it so. I'd like to tie this caveat to the PCI capability change, so this note will move to the appendix with the old PCI layout. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] asymmetric keys: fix printk format warning
Stephen Rothwell writes: > [Lets also cc Rusty who committed the patch ...] > > On Wed, 03 Oct 2012 16:04:46 -0700 Randy Dunlap wrote: >> >> From: Randy Dunlap >> >> Fix printk format warning in x509_cert_parser.c: >> >> crypto/asymmetric_keys/x509_cert_parser.c: In function 'x509_note_OID': >> crypto/asymmetric_keys/x509_cert_parser.c:113:3: warning: format '%zu' >> expects type 'size_t', but argument 2 has type 'long unsigned int' >> >> Builds cleanly on i386 and x86_64. Thanks, applied. Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] Input: da9052_tsi.c: Fix interrupt handling
From: Fabio Estevam
Currently da9062_tsi does not probe and it fails as follows:
da9052 1-0048: Unable to determine device interrupts
Use the new da9052 irq functions and allow the driver to probe and operate
correctly.
Tested on mx53qsb board using 'evtest' tool.
Cc: Dmitry Torokhov
Cc:
Signed-off-by: Fabio Estevam
---
drivers/input/touchscreen/da9052_tsi.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/input/touchscreen/da9052_tsi.c
b/drivers/input/touchscreen/da9052_tsi.c
index 71f6165..33fd3fa 100644
--- a/drivers/input/touchscreen/da9052_tsi.c
+++ b/drivers/input/touchscreen/da9052_tsi.c
@@ -274,16 +274,16 @@ static int __devinit da9052_ts_probe(struct
platform_device *pdev)
/* Disable ADC */
da9052_ts_adc_toggle(tsi, false);
- error = da9052_request_irq(tsi->da9052, DA9052_IRQ_PENDOWN,
"pendown-irq",
- da9052_ts_pendwn_irq, tsi);
+ error = da9052_request_irq(tsi->da9052, DA9052_IRQ_PENDOWN,
+ "pendown-irq", da9052_ts_pendwn_irq, tsi);
if (error) {
dev_err(tsi->da9052->dev,
"Failed to register PENDWN IRQ: %d\n", error);
goto err_free_mem;
}
- error = da9052_request_irq(tsi->da9052, DA9052_IRQ_TSIREADY,
"tsiready-irq",
- da9052_ts_datardy_irq, tsi);
+ error = da9052_request_irq(tsi->da9052, DA9052_IRQ_TSIREADY,
+ "tsiready-irq", da9052_ts_datardy_irq, tsi);
if (error) {
dev_err(tsi->da9052->dev,
"Failed to register TSIRDY IRQ :%d\n", error);
@@ -307,9 +307,9 @@ static int __devinit da9052_ts_probe(struct platform_device
*pdev)
return 0;
err_free_datardy_irq:
- da9052_free_irq(da9052, DA9052_IRQ_TSIREADY, da9052);
+ da9052_free_irq(tsi->da9052, DA9052_IRQ_TSIREADY, tsi);
err_free_pendwn_irq:
- da9052_free_irq(da9052, DA9052_IRQ_PENDOWN, da9052);
+ da9052_free_irq(tsi->da9052, DA9052_IRQ_PENDOWN, tsi);
err_free_mem:
kfree(tsi);
input_free_device(input_dev);
@@ -320,12 +320,11 @@ err_free_mem:
static int __devexit da9052_ts_remove(struct platform_device *pdev)
{
struct da9052_tsi *tsi = platform_get_drvdata(pdev);
- struct da9052 *da9052 = dev_get_drvdata(pdev->dev.parent);
da9052_reg_write(tsi->da9052, DA9052_LDO9_REG, 0x19);
- da9052_free_irq(da9052, DA9052_IRQ_TSIREADY, da9052);
- da9052_free_irq(da9052, DA9052_IRQ_PENDOWN, da9052);
+ da9052_free_irq(tsi->da9052, DA9052_IRQ_TSIREADY, tsi);
+ da9052_free_irq(tsi->da9052, DA9052_IRQ_PENDOWN, tsi);
input_unregister_device(tsi->dev);
kfree(tsi);
--
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 6/6] gpio: gpio-da9052: Convert to the new da9052 interrupt functions
From: Fabio Estevam
Convert to the new da9052 interrupt functions, so that we can get rid of
irq_base references.
Cc: Grant Likely
Cc: Linus Walleij
Signed-off-by: Fabio Estevam
---
Build tested only.
drivers/gpio/gpio-da9052.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-da9052.c b/drivers/gpio/gpio-da9052.c
index 24b8c29..3837072 100644
--- a/drivers/gpio/gpio-da9052.c
+++ b/drivers/gpio/gpio-da9052.c
@@ -185,7 +185,11 @@ static int da9052_gpio_to_irq(struct gpio_chip *gc, u32
offset)
struct da9052_gpio *gpio = to_da9052_gpio(gc);
struct da9052 *da9052 = gpio->da9052;
- return da9052->irq_base + DA9052_IRQ_GPI0 + offset;
+ int irq;
+
+ irq = regmap_irq_get_virq(da9052->irq_data, DA9052_IRQ_GPI0 + offset);
+
+ return irq;
}
static struct gpio_chip reference_gp __devinitdata = {
--
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 5/6] power: da9052-battery: Convert to the new da9052 interrupt functions
From: Fabio Estevam
Convert to the new da9052 interrupt functions, so that we can get rid of
irq_base references.
Cc: Anton Vorontsov
Signed-off-by: Fabio Estevam
---
Build tested only.
drivers/power/da9052-battery.c | 44 +++-
1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/power/da9052-battery.c b/drivers/power/da9052-battery.c
index d9d034d..73cec97 100644
--- a/drivers/power/da9052-battery.c
+++ b/drivers/power/da9052-battery.c
@@ -440,8 +440,10 @@ static int da9052_bat_check_health(struct da9052_battery
*bat, int *health)
static irqreturn_t da9052_bat_irq(int irq, void *data)
{
struct da9052_battery *bat = data;
+ int virq;
- irq -= bat->da9052->irq_base;
+ virq = regmap_irq_get_virq(bat->da9052->irq_data, irq);
+ irq -= virq;
if (irq == DA9052_IRQ_CHGEND)
bat->status = POWER_SUPPLY_STATUS_FULL;
@@ -567,7 +569,7 @@ static struct power_supply template_battery = {
.get_property = da9052_bat_get_property,
};
-static const char *const da9052_bat_irqs[] = {
+static char *da9052_bat_irqs[] = {
"BATT TEMP",
"DCIN DET",
"DCIN REM",
@@ -576,12 +578,20 @@ static const char *const da9052_bat_irqs[] = {
"CHG END",
};
+static int da9052_bat_irq_bits[] = {
+ DA9052_IRQ_TBAT,
+ DA9052_IRQ_DCIN,
+ DA9052_IRQ_DCINREM,
+ DA9052_IRQ_VBUS,
+ DA9052_IRQ_VBUSREM,
+ DA9052_IRQ_CHGEND,
+};
+
static s32 __devinit da9052_bat_probe(struct platform_device *pdev)
{
struct da9052_pdata *pdata;
struct da9052_battery *bat;
int ret;
- int irq;
int i;
bat = kzalloc(sizeof(struct da9052_battery), GFP_KERNEL);
@@ -602,15 +612,14 @@ static s32 __devinit da9052_bat_probe(struct
platform_device *pdev)
bat->psy.use_for_apm = 1;
for (i = 0; i < ARRAY_SIZE(da9052_bat_irqs); i++) {
- irq = platform_get_irq_byname(pdev, da9052_bat_irqs[i]);
- ret = request_threaded_irq(bat->da9052->irq_base + irq,
- NULL, da9052_bat_irq,
- IRQF_TRIGGER_LOW | IRQF_ONESHOT,
- da9052_bat_irqs[i], bat);
+ ret = da9052_request_irq(bat->da9052,
+ da9052_bat_irq_bits[i], da9052_bat_irqs[i],
+ da9052_bat_irq, bat);
+
if (ret != 0) {
dev_err(bat->da9052->dev,
- "DA9052 failed to request %s IRQ %d: %d\n",
- da9052_bat_irqs[i], irq, ret);
+ "DA9052 failed to request %s IRQ: %d\n",
+ da9052_bat_irqs[i], ret);
goto err;
}
}
@@ -623,23 +632,20 @@ static s32 __devinit da9052_bat_probe(struct
platform_device *pdev)
return 0;
err:
- while (--i >= 0) {
- irq = platform_get_irq_byname(pdev, da9052_bat_irqs[i]);
- free_irq(bat->da9052->irq_base + irq, bat);
- }
+ while (--i >= 0)
+ da9052_free_irq(bat->da9052, da9052_bat_irq_bits[i], bat);
+
kfree(bat);
return ret;
}
static int __devexit da9052_bat_remove(struct platform_device *pdev)
{
int i;
- int irq;
struct da9052_battery *bat = platform_get_drvdata(pdev);
- for (i = 0; i < ARRAY_SIZE(da9052_bat_irqs); i++) {
- irq = platform_get_irq_byname(pdev, da9052_bat_irqs[i]);
- free_irq(bat->da9052->irq_base + irq, bat);
- }
+ for (i = 0; i < ARRAY_SIZE(da9052_bat_irqs); i++)
+ da9052_free_irq(bat->da9052, da9052_bat_irq_bits[i], bat);
+
power_supply_unregister(>psy);
kfree(bat);
--
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 4/6] Input: da9052_onkey.c: Convert to the new da9052 interrupt functions.
From: Fabio Estevam
Use the new da9052 irq functions and allow the driver to probe successfully.
Cc: Dmitry Torokhov
Cc:
Signed-off-by: Fabio Estevam
---
drivers/input/misc/da9052_onkey.c | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/drivers/input/misc/da9052_onkey.c
b/drivers/input/misc/da9052_onkey.c
index 3c843cd..3be3acc 100644
--- a/drivers/input/misc/da9052_onkey.c
+++ b/drivers/input/misc/da9052_onkey.c
@@ -24,7 +24,6 @@ struct da9052_onkey {
struct da9052 *da9052;
struct input_dev *input;
struct delayed_work work;
- unsigned int irq;
};
static void da9052_onkey_query(struct da9052_onkey *onkey)
@@ -76,7 +75,6 @@ static int __devinit da9052_onkey_probe(struct
platform_device *pdev)
struct da9052 *da9052 = dev_get_drvdata(pdev->dev.parent);
struct da9052_onkey *onkey;
struct input_dev *input_dev;
- int irq;
int error;
if (!da9052) {
@@ -84,13 +82,6 @@ static int __devinit da9052_onkey_probe(struct
platform_device *pdev)
return -EINVAL;
}
- irq = platform_get_irq_byname(pdev, "ONKEY");
- if (irq < 0) {
- dev_err(>dev,
- "Failed to get an IRQ for input device, %d\n", irq);
- return -EINVAL;
- }
-
onkey = kzalloc(sizeof(*onkey), GFP_KERNEL);
input_dev = input_allocate_device();
if (!onkey || !input_dev) {
@@ -101,7 +92,6 @@ static int __devinit da9052_onkey_probe(struct
platform_device *pdev)
onkey->input = input_dev;
onkey->da9052 = da9052;
- onkey->irq = irq;
INIT_DELAYED_WORK(>work, da9052_onkey_work);
input_dev->name = "da9052-onkey";
@@ -111,13 +101,11 @@ static int __devinit da9052_onkey_probe(struct
platform_device *pdev)
input_dev->evbit[0] = BIT_MASK(EV_KEY);
__set_bit(KEY_POWER, input_dev->keybit);
- error = request_threaded_irq(onkey->irq, NULL, da9052_onkey_irq,
-IRQF_TRIGGER_LOW | IRQF_ONESHOT,
-"ONKEY", onkey);
+ error = da9052_request_irq(onkey->da9052, DA9052_IRQ_NONKEY, "ONKEY",
+ da9052_onkey_irq, onkey);
if (error < 0) {
dev_err(onkey->da9052->dev,
- "Failed to register ONKEY IRQ %d, error = %d\n",
- onkey->irq, error);
+ "Failed to register ONKEY IRQ: %d\n", error);
goto err_free_mem;
}
@@ -132,7 +120,7 @@ static int __devinit da9052_onkey_probe(struct
platform_device *pdev)
return 0;
err_free_irq:
- free_irq(onkey->irq, onkey);
+ da9052_free_irq(onkey->da9052, DA9052_IRQ_NONKEY, onkey);
cancel_delayed_work_sync(>work);
err_free_mem:
input_free_device(input_dev);
@@ -145,7 +133,7 @@ static int __devexit da9052_onkey_remove(struct
platform_device *pdev)
{
struct da9052_onkey *onkey = platform_get_drvdata(pdev);
- free_irq(onkey->irq, onkey);
+ da9052_free_irq(onkey->da9052, DA9052_IRQ_NONKEY, onkey);
cancel_delayed_work_sync(>work);
input_unregister_device(onkey->input);
--
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 2/6] mfd: da9052: Introduce da9052-irq.c
From: Fabio Estevam
Create a da9052-irq.c file so that it can handle interrupt related functions.
This is useful for allowing the da9052 drivers to use such functions
when dealing with da9052 interrupts.
Signed-off-by: Fabio Estevam
---
drivers/mfd/Makefile |1 +
drivers/mfd/da9052-core.c | 271 ++
drivers/mfd/da9052-irq.c | 288 +
include/linux/mfd/da9052/da9052.h | 10 ++
4 files changed, 307 insertions(+), 263 deletions(-)
create mode 100644 drivers/mfd/da9052-irq.c
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 083acf9..1b0e56f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_UCB1400_CORE)+= ucb1400_core.o
obj-$(CONFIG_PMIC_DA903X) += da903x.o
+obj-$(CONFIG_PMIC_DA9052) += da9052-irq.o
obj-$(CONFIG_PMIC_DA9052) += da9052-core.o
obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
index c96cdbc..2153f9bb 100644
--- a/drivers/mfd/da9052-core.c
+++ b/drivers/mfd/da9052-core.c
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -24,16 +23,6 @@
#include
#include
-#define DA9052_NUM_IRQ_REGS4
-#define DA9052_IRQ_MASK_POS_1 0x01
-#define DA9052_IRQ_MASK_POS_2 0x02
-#define DA9052_IRQ_MASK_POS_3 0x04
-#define DA9052_IRQ_MASK_POS_4 0x08
-#define DA9052_IRQ_MASK_POS_5 0x10
-#define DA9052_IRQ_MASK_POS_6 0x20
-#define DA9052_IRQ_MASK_POS_7 0x40
-#define DA9052_IRQ_MASK_POS_8 0x80
-
static bool da9052_reg_readable(struct device *dev, unsigned int reg)
{
switch (reg) {
@@ -425,15 +414,6 @@ err:
}
EXPORT_SYMBOL_GPL(da9052_adc_manual_read);
-static irqreturn_t da9052_auxadc_irq(int irq, void *irq_data)
-{
- struct da9052 *da9052 = irq_data;
-
- complete(>done);
-
- return IRQ_HANDLED;
-}
-
int da9052_adc_read_temp(struct da9052 *da9052)
{
int tbat;
@@ -447,74 +427,6 @@ int da9052_adc_read_temp(struct da9052 *da9052)
}
EXPORT_SYMBOL_GPL(da9052_adc_read_temp);
-static struct resource da9052_rtc_resource = {
- .name = "ALM",
- .start = DA9052_IRQ_ALARM,
- .end = DA9052_IRQ_ALARM,
- .flags = IORESOURCE_IRQ,
-};
-
-static struct resource da9052_onkey_resource = {
- .name = "ONKEY",
- .start = DA9052_IRQ_NONKEY,
- .end = DA9052_IRQ_NONKEY,
- .flags = IORESOURCE_IRQ,
-};
-
-static struct resource da9052_bat_resources[] = {
- {
- .name = "BATT TEMP",
- .start = DA9052_IRQ_TBAT,
- .end = DA9052_IRQ_TBAT,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "DCIN DET",
- .start = DA9052_IRQ_DCIN,
- .end = DA9052_IRQ_DCIN,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "DCIN REM",
- .start = DA9052_IRQ_DCINREM,
- .end = DA9052_IRQ_DCINREM,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "VBUS DET",
- .start = DA9052_IRQ_VBUS,
- .end = DA9052_IRQ_VBUS,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "VBUS REM",
- .start = DA9052_IRQ_VBUSREM,
- .end = DA9052_IRQ_VBUSREM,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "CHG END",
- .start = DA9052_IRQ_CHGEND,
- .end = DA9052_IRQ_CHGEND,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct resource da9052_tsi_resources[] = {
- {
- .name = "PENDWN",
- .start = DA9052_IRQ_PENDOWN,
- .end = DA9052_IRQ_PENDOWN,
- .flags = IORESOURCE_IRQ,
- },
- {
- .name = "TSIRDY",
- .start = DA9052_IRQ_TSIREADY,
- .end = DA9052_IRQ_TSIREADY,
- .flags = IORESOURCE_IRQ,
- },
-};
-
static struct mfd_cell __devinitdata da9052_subdev_info[] = {
{
.name = "da9052-regulator",
@@ -574,13 +486,9 @@ static struct mfd_cell __devinitdata da9052_subdev_info[]
= {
},
{
.name = "da9052-onkey",
- .resources = _onkey_resource,
- .num_resources = 1,
},
{
.name = "da9052-rtc",
- .resources = _rtc_resource,
- .num_resources = 1,
},
{
.name = "da9052-gpio",
@@ -602,160 +510,15 @@ static struct mfd_cell __devinitdata
da9052_subdev_info[] = {
},
{
.name = "da9052-tsi",
- .resources = da9052_tsi_resources,
-
[PATCH 1/6] mfd: da9052-core: Use regmap_irq_get_virq() and fix the probe
From: Fabio Estevam
On a mx53qsb dt-kernel the da9052-core driver fails to probe as follows:
da9052 1-0048: DA9052 ADC IRQ failed ret=-22
The reason for the error was due to passing only the offset as the interrupt
number in request_threaded_irq() without da9052->irq_base.
The recommended approach though is to use regmap_get_virq() to acquire the
interrupt number and this allows to get rid of da9052->irq_base.
Fix it and allow the driver to probe successfully.
Also provide a few more error logs and change the irq string to "adc-irq", so
that it appears as a single word in 'cat /proc/interrupts'
Signed-off-by: Fabio Estevam
---
drivers/mfd/da9052-core.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
index a0a62b2..c96cdbc 100644
--- a/drivers/mfd/da9052-core.c
+++ b/drivers/mfd/da9052-core.c
@@ -769,10 +769,15 @@ struct regmap_config da9052_regmap_config = {
};
EXPORT_SYMBOL_GPL(da9052_regmap_config);
+static int da9052_map_irq(struct da9052 *da9052, int irq)
+{
+ return regmap_irq_get_virq(da9052->irq_data, irq);
+}
+
int __devinit da9052_device_init(struct da9052 *da9052, u8 chip_id)
{
struct da9052_pdata *pdata = da9052->dev->platform_data;
- int ret;
+ int ret, i;
mutex_init(>auxadc_lock);
init_completion(>done);
@@ -782,35 +787,34 @@ int __devinit da9052_device_init(struct da9052 *da9052,
u8 chip_id)
da9052->chip_id = chip_id;
- if (!pdata || !pdata->irq_base)
- da9052->irq_base = -1;
- else
- da9052->irq_base = pdata->irq_base;
-
ret = regmap_add_irq_chip(da9052->regmap, da9052->chip_irq,
IRQF_TRIGGER_LOW | IRQF_ONESHOT,
- da9052->irq_base, _regmap_irq_chip,
+ -1, _regmap_irq_chip,
>irq_data);
- if (ret < 0)
+ if (ret < 0) {
+ dev_err(da9052->dev, "regmap_add_irq_chip failed: %d\n", ret);
goto regmap_err;
+ }
- da9052->irq_base = regmap_irq_chip_get_base(da9052->irq_data);
-
- ret = request_threaded_irq(DA9052_IRQ_ADC_EOM, NULL, da9052_auxadc_irq,
+ i = da9052_map_irq(da9052, DA9052_IRQ_ADC_EOM);
+ ret = request_threaded_irq(i, NULL, da9052_auxadc_irq,
IRQF_TRIGGER_LOW | IRQF_ONESHOT,
- "adc irq", da9052);
+ "adc-irq", da9052);
if (ret != 0)
dev_err(da9052->dev, "DA9052 ADC IRQ failed ret=%d\n", ret);
ret = mfd_add_devices(da9052->dev, -1, da9052_subdev_info,
ARRAY_SIZE(da9052_subdev_info), NULL, 0, NULL);
- if (ret)
+ if (ret) {
+ dev_err(da9052->dev, "mfd_add_devices failed: %d\n", ret);
goto err;
+ }
return 0;
err:
- free_irq(DA9052_IRQ_ADC_EOM, da9052);
+ free_irq(da9052_map_irq(da9052, DA9052_IRQ_ADC_EOM), da9052);
+ regmap_del_irq_chip(da9052->chip_irq, da9052->irq_data);
mfd_remove_devices(da9052->dev);
regmap_err:
return ret;
@@ -818,7 +822,7 @@ regmap_err:
void da9052_device_exit(struct da9052 *da9052)
{
- free_irq(DA9052_IRQ_ADC_EOM, da9052);
+ free_irq(da9052_map_irq(da9052, DA9052_IRQ_ADC_EOM), da9052);
regmap_del_irq_chip(da9052->chip_irq, da9052->irq_data);
mfd_remove_devices(da9052->dev);
}
--
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 0/2] USB webcam gadget driver fix for linux-next
On Thu, Oct 04, 2012 at 02:32:40AM +0200, Laurent Pinchart wrote: > Hi, > > The first patch in this series should fix the UVC gadget compilation errors in > linux-next. The second patch should make sure I'll be notified next time a > patch tries to break it :-) > > Both patches are based on Linus' tree. Thanks, I'll queue these up soon. 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/
linux-next: manual merge of the modules tree with Linus' tree
Hi Rusty,
Today's linux-next merge of the modules tree got a conflict in Makefile
between commit d183e6f570f3 ("UAPI: Move linux/version.h") from Linus'
tree and commit 91657140708d ("MODSIGN: Make mrproper should remove
generated files") from the modules 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 Makefile
index 5d8e7f2,e70ebfe..000
--- a/Makefile
+++ b/Makefile
@@@ -996,8 -993,12 +996,11 @@@ CLEAN_DIRS += $(MODVERDIR
# Directories & files removed with 'make mrproper'
MRPROPER_DIRS += include/config usr/include include/generated \
arch/*/include/generated
-MRPROPER_FILES += .config .config.old .version .old_version \
- include/linux/version.h \
+MRPROPER_FILES += .config .config.old .version .old_version $(version_h) \
- Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS
+ Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
+ signing_key.priv signing_key.x509 x509.genkey \
+ extra_certificates signing_key.x509.keyid \
+ signing_key.x509.signer
# clean - Delete most, but leave enough to build external modules
#
pgpPWUuHEthY2.pgp
Description: PGP signature
Re: [PATCH 2/2] acpi,memory-hotplug : call acpi_bus_remo() to remove memory device
On Wed, Oct 3, 2012 at 6:48 PM, Yasuaki Ishimatsu wrote: > From: Wen Congyang > > The memory device has been ejected and powoffed, so we can call > acpi_bus_remove() to remove the memory device from acpi bus. > > CC: Len Brown > Reviewed-by: Yasuaki Ishimatsu > Signed-off-by: Wen Congyang > --- > drivers/acpi/acpi_memhotplug.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > Index: linux-3.6/drivers/acpi/acpi_memhotplug.c > === > --- linux-3.6.orig/drivers/acpi/acpi_memhotplug.c 2012-10-03 > 18:17:47.802249170 +0900 > +++ linux-3.6/drivers/acpi/acpi_memhotplug.c2012-10-03 18:17:52.471250299 > +0900 > @@ -424,8 +424,9 @@ static void acpi_memory_device_notify(ac > } > > /* > -* TBD: Invoke acpi_bus_remove to cleanup data structures > +* Invoke acpi_bus_remove() to remove memory device > */ > + acpi_bus_remove(device, 1); why not using acpi_bus_trim instead? 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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Thu, Oct 4, 2012 at 12:58 AM, Linus Torvalds wrote: > That said, there's clearly enough variation here that I think that for > now I won't take the step to disable the udev part. I'll do the patch > to support "direct filesystem firmware loading" using the udev default > paths, and that hopefully fixes the particular case people see with > media modules. If that approach looks like it works out, please aim for full in-kernel-*only* support. I would absolutely like to get udev entirely out of the sick game of firmware loading here. I would welcome if we are not falling back to the blocking timeouted behaviour again. The whole story would be contained entirely in the kernel, and we get rid of the rather fragile "userspace transaction" to execute module_init(), where the kernel has no idea if userspace is even up to ever responding to its requests. There would be no coordination with userspace tools needed, which sounds like a better fit in the way we develop things with the loosely coupled kernel <-> udev requirements. If that works out, it would a bit like devtmpfs which turned out to be very simple, reliable and absolutely the right thing we could do to primarily mange /dev content. The whole dance with the fake firmware struct device, which has a 60 second timeout to wait for userspace, is a long story of weird failures at various aspects. It would not only solve the unfortunate modprobe lockup with init=/bin/sh we see here, also big servers with an insane amount of devices happen to run into the 60 sec timeout, because udev, which runs with 4000-8000 threads in parallel handling things like 30.000 disks is not scheduled in time to fulfill network card firmware requests. It would be nice if we don't have that arbitrary timeout at all. Having any timeout at all to answer the simple question if a file stored in the rootfs exists, should be a hint that there is something really wrong with the model that stuff is done. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute
On Wed, 2012-10-03 at 20:32 -0400, Steven Rostedt wrote: > On Wed, 2012-10-03 at 08:38 -0700, Joe Perches wrote: > > On Wed, 2012-10-03 at 11:14 -0400, Steven Rostedt wrote: > > > I first check > > > the MAINTAINERS file. If the subsystem I'm working on exists there, I > > > only email those that are listed there, including any mailing lists that > > > are mentioned (as well as LKML). If it's not listed, I then do a git log > > > and see who does the most sign offs to changes there, and to what kind > > > of changes. I usually ignore the trivial stuff. > > > > Funny because that's what the script does too. > > > > Really? It ignores the trivial stuff and only adds people that seem to > actually do real work on the file? Fundamentally, yes. It's not as good as even a semi-skilled person of course. > If that's the case, I doubt that it would have caused the huge Cc list > that Daniel sent out. Multiple files per patch, large recipient lists. I generally use --no-git and --nogit-fallback -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] efi: add efivars kobject to efi sysfs folder
UEFI variable filesystem need a new mount point, so this patch add
efivars kobject to efi_kobj for create a /sys/firmware/efi/efivars
folder.
Cc: Matt Fleming
Cc: Jeremy Kerr
Cc: Matthew Garrett
Cc: H. Peter Anvin
Signed-off-by: Lee, Chun-Yi
---
drivers/firmware/efivars.c | 11 +++
include/linux/efi.h|1 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 1e1aad0..7c1234e 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -1487,6 +1487,7 @@ void unregister_efivars(struct efivars *efivars)
sysfs_remove_bin_file(>kset->kobj, efivars->del_var);
kfree(efivars->new_var);
kfree(efivars->del_var);
+ kobject_put(efivars->kobject);
kset_unregister(efivars->kset);
}
EXPORT_SYMBOL_GPL(unregister_efivars);
@@ -1518,6 +1519,13 @@ int register_efivars(struct efivars *efivars,
goto out;
}
+ efivars->kobject = kobject_create_and_add("efivars", parent_kobj);
+ if (!efivars->kobject) {
+ pr_err("efivars: Subsystem registration failed.\n");
+ error = -ENOMEM;
+ goto err_unreg_vars;
+ }
+
/*
* Per EFI spec, the maximum storage allocated for both
* the variable name and variable data is 1024 bytes.
@@ -1562,6 +1570,9 @@ int register_efivars(struct efivars *efivars,
register_filesystem(_fs_type);
+err_unreg_vars:
+ kset_unregister(efivars->kset);
+
out:
kfree(variable_name);
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 1829a97..c993f54 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -654,6 +654,7 @@ struct efivars {
spinlock_t lock;
struct list_head list;
struct kset *kset;
+ struct kobject *kobject;
struct bin_attribute *new_var, *del_var;
const struct efivar_operations *ops;
struct efivar_entry *walk_entry;
--
1.7.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/
linux-next: manual merge of the drm tree with the tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/nouveau (lots of files) between commit 760285e7e7ab
("UAPI: (Scripted) Convert #include "..." to #include in
drivers/gpu/") from Linus' tree and various commits from the drm tree.
There is a large reorganisation under drivers/gpu/nouveau in the drm
tree (which only appeared in linux-next today :-().
I used the drm tree versions of the files and but this needs to be done
properly.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpkphv6evJQc.pgp
Description: PGP signature
linux-next: build warnings after merge of the drm tree
Hi Dave, After merging the drm tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: drivers/gpu/drm/gma500/backlight.c:29:13: warning: 'do_gma_backlight_set' defined but not used [-Wunused-function] drivers/gpu/drm/nouveau/core/subdev/gpio/base.c: In function 'nouveau_gpio_isr_del': drivers/gpu/drm/nouveau/core/subdev/gpio/base.c:219:4: warning: 'flush_work_sync' is deprecated (declared at include/linux/workqueue.h:448) [-Wdeprecated-declarations] drivers/gpu/drm/nouveau/nouveau_drm.c: In function 'nouveau_drm_open': drivers/gpu/drm/nouveau/nouveau_drm.c:503:2: warning: format '%d' expects argument of type 'int', but argument 4 has type 'struct pid *' [-Wformat] -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpbRObAec6Gw.pgp Description: PGP signature
FTDI Linux Kernel Driver
Greetings,
Patch Description: Add product id in ftdi_sio.c struct table ( static
struct usb_device_id id_table_combined []) and include a define
statement in ftdi_sio_ids.h for RTSYSTEMS CT63 Radio Cable.
Output from dmesg regarding the hardware:
[ 5489.423407] usb 10-1: New USB device found, idVendor=2100, idProduct=9e58
[ 5489.423414] usb 10-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 5489.423421] usb 10-1: Product: CT63 Radio Cable
[ 5489.423426] usb 10-1: Manufacturer: RT Systems
[ 5489.423431] usb 10-1: SerialNumber: RTUC68HJ
Output from lsusb -v:
Bus 010 Device 002: ID 2100:9e58
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x2100
idProduct 0x9e58
bcdDevice6.00
iManufacturer 1 RT Systems
iProduct2 CT63 Radio Cable
iSerial 3 RTUC68HJ
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 90mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface 2 CT63 Radio Cable
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x
(Bus Powered)
$> cat /tmp/ftdi-ct63.patch
diff -uprN linux-3.6-vanilla/drivers/usb/serial/ftdi_sio.c
/home/ryan/src/linux-3.6-ftdi/drivers/usb/serial/ftdi_sio.c
--- linux-3.6-vanilla/drivers/usb/serial/ftdi_sio.c 2012-09-30
19:47:46.0 -0400
+++ /home/ryan/src/linux-3.6-ftdi/drivers/usb/serial/ftdi_sio.c
2012-10-03 21:44:56.024000806 -0400
@@ -738,6 +738,7 @@ static struct usb_device_id id_table_com
{ USB_DEVICE(TELLDUS_VID, TELLDUS_TELLSTICK_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_SERIAL_VX7_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_CT29B_PID) },
+ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_CT63_PID) },
{ USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_RTS01_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_MAXSTREAM_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_PHI_FISCO_PID) },
diff -uprN linux-3.6-vanilla/drivers/usb/serial/ftdi_sio_ids.h
/home/ryan/src/linux-3.6-ftdi/drivers/usb/serial/ftdi_sio_ids.h
--- linux-3.6-vanilla/drivers/usb/serial/ftdi_sio_ids.h 2012-09-30
19:47:46.0 -0400
+++ /home/ryan/src/linux-3.6-ftdi/drivers/usb/serial/ftdi_sio_ids.h
2012-10-03 21:45:39.211999231 -0400
@@ -790,6 +790,7 @@
#define RTSYSTEMS_VID 0x2100 /* Vendor ID */
#define RTSYSTEMS_SERIAL_VX7_PID 0x9e52 /* Serial converter for
VX-7 Radios using FT232RL */
#define RTSYSTEMS_CT29B_PID0x9e54 /* CT29B Radio Cable */
+#define RTSYSTEMS_CT63_PID 0x9e58 /* CT63 Radio Cable */
#define RTSYSTEMS_RTS01_PID0x9e57 /* USB-RTS01 Radio Cable */
Signed-off-by: Ryan A. Krenzischek
73 de Ryan/W4NTR
--
Ryan A. Krenzischek
W4NTR, Amateur Radio;
W4NVU, Webmaster;
NNN0RGN/RG/NNR4GN, U.S. Navy-Marine Corps MARS (NMCM)/SHARES;
NNN0GAL TWO-FOUR, Assistant U.S. NMCM FL Training Officer;
NNN0GED NMCM Project Officer for Miami AT Restoration Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: build failure after merge of the net tree
David and Stephen, I apologize for not taking the necessary steps to verify our patches before submission. Ignorance is not an excuse... Anyways David thank you for fixing the issue for us. Jay- -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Wednesday, October 03, 2012 6:48 PM To: s...@canb.auug.org.au Cc: net...@vger.kernel.org; linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Vipul Pandya; Jay Hernandez Subject: Re: linux-next: build failure after merge of the net tree From: Stephen Rothwell Date: Thu, 4 Oct 2012 11:06:15 +1000 > Actually, for me it is. I have a script that does the "use > yesterday's version" for me. To fix (even a one liner) means bringing > up an editor, commiting, creating the patch and then recommiting it > (an implementation > detail) and recording that I need to keep (automatically) applying the > patch in case the maintainer doesn't react quickly. Ok, fair enough. I'll try to look into making x86 barf when a vmalloc.h include is missing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 drm tree with Linus' tree
Hi Dave,
Today's linux-next merge of the drm tree got conflicts in
drivers/gpu/drm/i915/intel_dp.c and drivers/gpu/drm/i915/intel_drv.h
between commit 760285e7e7ab ("UAPI: (Scripted) Convert #include "..." to
#include in drivers/gpu/") from Linus' tree and commit 54d63ca6605d
("drm/i915: Move DP structs to shared location") from the drm 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/gpu/drm/i915/intel_dp.c
index f1bd4f4,1474f84..000
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -28,16 -28,15 +28,14 @@@
#include
#include
#include
-#include "drmP.h"
-#include "drm.h"
-#include "drm_crtc.h"
-#include "drm_crtc_helper.h"
-#include "drm_edid.h"
+#include
+#include
+#include
+#include
#include "intel_drv.h"
-#include "i915_drm.h"
+#include
#include "i915_drv.h"
- #include
- #define DP_RECEIVER_CAP_SIZE 0xf
#define DP_LINK_STATUS_SIZE 6
#define DP_LINK_CHECK_TIMEOUT (10 * 1000)
diff --cc drivers/gpu/drm/i915/intel_drv.h
index 7db8490,351fd71..000
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@@ -26,11 -26,12 +26,12 @@@
#define __INTEL_DRV_H__
#include
-#include "i915_drm.h"
+#include
#include "i915_drv.h"
-#include "drm_crtc.h"
-#include "drm_crtc_helper.h"
-#include "drm_fb_helper.h"
-#include "drm_dp_helper.h"
+#include
+#include
+#include
++#include
#define _wait_for(COND, MS, W) ({ \
unsigned long timeout__ = jiffies + msecs_to_jiffies(MS); \
pgpWNlVRgdq4v.pgp
Description: PGP signature
Re: [PATCH 0/8] THP support for Sparc64
From: Andrew Morton Date: Tue, 2 Oct 2012 15:55:44 -0700 > I had a shot at integrating all this onto the pending stuff in linux-next. > "mm: Add and use update_mmu_cache_pmd() in transparent huge page code." > needed minor massaging in huge_memory.c. But as Andrea mentioned, we > ran aground on Gerald's > http://ozlabs.org/~akpm/mmotm/broken-out/thp-remove-assumptions-on-pgtable_t-type.patch, > part of the thp-for-s390 work. While working on a rebase relative to this work, I noticed that the s390 patches don't even compile. It's because of that pmd_pgprot() change from Peter Z. which arrives asynchonously via the linux-next tree. It makes THP start using pmd_pgprot() (a new interface) which the s390 patches don't provide. It's going to require that I do new work for my sparc64 THP changes as well. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH -tip ] [BUGFIX] perf probe: Add a workaround for GCC -mfentry
(2012/10/04 1:00), Mark Wielaard wrote: > On Wed, 2012-10-03 at 09:53 -0400, Steven Rostedt wrote: >> On Wed, 2012-10-03 at 21:17 +0900, Masami Hiramatsu wrote: >>> <1><9a58>: Abbrev Number: 86 (DW_TAG_subprogram) >>> <9a59> DW_AT_external: 1 >>> <9a59> DW_AT_name: (indirect string, offset: 0xd82): >>> unregister_di >>> e_notifier >>> <9a5d> DW_AT_decl_file : 1 >>> <9a5e> DW_AT_decl_line : 551 >>> <9a60> DW_AT_prototyped : 1 >>> <9a60> DW_AT_type: <0x7c> >>> <9a64> DW_AT_low_pc : 0x740 >>> <9a6c> DW_AT_high_pc : 0x75a >>> <9a74> DW_AT_frame_base : 1 byte block: 9c >>> (DW_OP_call_frame_cfa) >>> <9a76> DW_AT_GNU_all_call_sites: 1 >>> <9a76> DW_AT_sibling : <0x9aac> >>> <2><9a7a>: Abbrev Number: 87 (DW_TAG_formal_parameter) >>> <9a7b> DW_AT_name: nb >>> <9a7e> DW_AT_decl_file : 1 >>> <9a7f> DW_AT_decl_line : 551 >>> <9a81> DW_AT_type: <0x2a96> >>> <9a85> DW_AT_location: 0x172f (location list) >>> ... >>> 172f 0745 0750 (DW_OP_reg5 (rdi)) >>> 172f 0750 0757 (DW_OP_reg4 (rsi)) >>> 172f 0757 075a (DW_OP_GNU_entry_value: >>> (DW_OP_reg5 (rdi)); DW_OP_stack_value) >>> 172f >>> - >>> >>> As you can see, the location of the parameter "nb", starts from 0x745 >>> but unregister_die_notifier() function itself starts from 0x740. >> >> Um, no I can't see. I guess I need to go and read up on DWARF formats. >> Any good recommended links? >> >> A quick google gives me: >> >> http://en.wikipedia.org/wiki/DWARF >> http://wiki.dwarfstd.org/index.php?title=Dwarf_FAQ >> http://www.eagercon.com/dwarf/dwarf-2.0.0.pdf >> >> Is this what you recommend reading? Or is there better documentation? > > DWARF2 is pretty old, the latest DWARF standard is > http://www.dwarfstd.org/Dwarf4Std.php > If you like details then you'll want to read section 2.5 DWARF > Expressions and 2.6 Location Descriptions. (That is what the > DW_AT_location attribute for the DW_TAG_formal_parameter points at.) You > might also want to read a bit about some of the DWARF5/GNU extensions > commonly used. I tried to add references to them on this page: > https://fedorahosted.org/elfutils/wiki/DwarfExtensions > (Look for the Expression Opcodes) > > So in the above example it tries to say that for function (subprogram) > "unregister_di_notifier" runs from (low_pc) 0x740 till (high_pc) 0x75a > and for the parameter "nb" the value can be found in the rdi register > from address 0x745 till 0x750, in register rsi from address 0x750 till > 0x575 and for 0x757 till 0x75a it would be the value of register rsi as > it was on function entry (yes, that just means it isn't available > anymore and you need to either unwind to function start to get it or > have it recorded on function entry to retrieve it at this point). The > above also implies that from address 0x740 till 0x745 GCC didn't record > the location of nb (or it just hasn't materialized yet). > > Note that the GCC hackers already seem to have identified why that is in > this case: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793#c2 Thanks for the perfect explanation! And sorry, I should explain not why but what happened... Without this patch, perf probe doesn't work correctly about finding function parameters on function entries. # ./perf probe -V vfs_read Available variables at vfs_read @ (No matched variables) Not only showing parameters, but also setting parameters failed. # ./perf probe vfs_read buf Failed to find the location of buf at this address. Perhaps, it has been optimized out. Failed to find 'buf' in this function. Error: Failed to add events. (-2) With this patch, perf can handle parameters again. # ./perf probe -V vfs_read Available variables at vfs_read @ char* buf loff_t* pos size_t count struct file*file and # ./perf probe vfs_read buf Added new event: probe:vfs_read (on vfs_read with buf) You can now use it in all perf tools, such as: perf record -e probe:vfs_read -aR sleep 1 Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default
On Wed, Oct 03, 2012 at 01:03:14PM -0700, Paul E. McKenney wrote: > That has not proven sufficient for me in the past, RCU_FAST_NO_HZ > being a case in point. Taint the kernel at boot time? That'd be sufficient to force distros to disable it. -- Matthew Garrett | mj...@srcf.ucam.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/
linux-next: manual merge of the drm tree with Linus' tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/gma500/psb_drv.h between commit 760285e7e7ab ("UAPI:
(Scripted) Convert #include "..." to #include in
drivers/gpu/") from Linus' tree and commit 4d46259f00c6 ("drm: gma500:
Kill the GEM glue layer") from the drm 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/gpu/drm/gma500/psb_drv.h
index b15282f,223ff5b..000
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@@ -23,11 -23,11 +23,11 @@@
#include
#include
-#include "drm_global.h"
-#include "gma_drm.h"
+#include
- #include "gem_glue.h"
+#include
#include "psb_reg.h"
#include "psb_intel_drv.h"
+ #include "intel_bios.h"
#include "gtt.h"
#include "power.h"
#include "opregion.h"
pgpR9L8EW5u86.pgp
Description: PGP signature
Re: [PATCH 1/3] perf tools: Check existence of _get_comp_words_by_ref when bash completing
Hi Frederic, On Tue, 2 Oct 2012 17:54:10 +0200, Frederic Weisbecker wrote: > On Wed, Oct 03, 2012 at 12:21:32AM +0900, Namhyung Kim wrote: >> The '_get_comp_words_by_ref' function is available from the bash >> completion v1.2 so that earlier version emits following warning: >> >> $ perf re_get_comp_words_by_ref: command not found >> >> Use older '_get_cword' method when the above function doesn't exist. > > May be only use _get_cword then, if it works everywhere? It'll work but it's deprecated. 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: [GIT PULL v2] Update LZO compression
> > > - Post the entire patch series to lkml for review (I'd like a cc please) > > > > Already happened, multiple people reviewed and tested. > > um, I would not consider "Looks ok to me from a quick look." and "I > couldn't tell from the github view, but I assume you follow standard > coding style." to indicate a rigorous code review! Let's put it like this. LZO is mature widely used production software and Markus wrote and maintains it. Essentially this is a release from him. The main problem before with using his version directly was that it did not follow Linux coding standards, but that seems to be fixed now. It's also relatively simple and at least I didn't spot anything bad when I looked. It was runtime tested by several people on different architectures. If it was fuzzed so we can assume reasonably good security. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] acpi,memory-hotplug : call acpi_bus_remo() to remove memory device
From: Wen Congyang The memory device has been ejected and powoffed, so we can call acpi_bus_remove() to remove the memory device from acpi bus. CC: Len Brown Reviewed-by: Yasuaki Ishimatsu Signed-off-by: Wen Congyang --- drivers/acpi/acpi_memhotplug.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: linux-3.6/drivers/acpi/acpi_memhotplug.c === --- linux-3.6.orig/drivers/acpi/acpi_memhotplug.c 2012-10-03 18:17:47.802249170 +0900 +++ linux-3.6/drivers/acpi/acpi_memhotplug.c2012-10-03 18:17:52.471250299 +0900 @@ -424,8 +424,9 @@ static void acpi_memory_device_notify(ac } /* -* TBD: Invoke acpi_bus_remove to cleanup data structures +* Invoke acpi_bus_remove() to remove memory device */ + acpi_bus_remove(device, 1); /* _EJ0 succeeded; _OST is not necessary */ 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: linux-next: build failure after merge of the net tree
From: Stephen Rothwell Date: Thu, 4 Oct 2012 11:06:15 +1000 > Actually, for me it is. I have a script that does the "use yesterday's > version" for me. To fix (even a one liner) means bringing up an editor, > commiting, creating the patch and then recommiting it (an implementation > detail) and recording that I need to keep (automatically) applying the > patch in case the maintainer doesn't react quickly. Ok, fair enough. I'll try to look into making x86 barf when a vmalloc.h include is missing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] acpi,memory-hotplug : export the function acpi_bus_remove()
From: Wen Congyang
The function acpi_bus_remove() can remove a acpi device from acpi bus.
When a acpi device is removed, we need to call this function to remove
the acpi device from acpi bus. So export this function.
CC: Len Brown
Reviewed-by: Yasuaki Ishimatsu
Signed-off-by: Wen Congyang
---
drivers/acpi/scan.c |3 ++-
include/acpi/acpi_bus.h |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
Index: linux-3.6/drivers/acpi/scan.c
===
--- linux-3.6.orig/drivers/acpi/scan.c 2012-10-03 18:16:57.206246798 +0900
+++ linux-3.6/drivers/acpi/scan.c 2012-10-03 18:17:49.974249714 +0900
@@ -1224,7 +1224,7 @@ static int acpi_device_set_context(struc
return -ENODEV;
}
-static int acpi_bus_remove(struct acpi_device *dev, int rmdevice)
+int acpi_bus_remove(struct acpi_device *dev, int rmdevice)
{
if (!dev)
return -EINVAL;
@@ -1246,6 +1246,7 @@ static int acpi_bus_remove(struct acpi_d
return 0;
}
+EXPORT_SYMBOL(acpi_bus_remove);
static int acpi_add_single_object(struct acpi_device **child,
acpi_handle handle, int type,
Index: linux-3.6/include/acpi/acpi_bus.h
===
--- linux-3.6.orig/include/acpi/acpi_bus.h 2012-10-03 18:16:57.208246800
+0900
+++ linux-3.6/include/acpi/acpi_bus.h 2012-10-03 18:17:49.976249717 +0900
@@ -360,6 +360,7 @@ bool acpi_bus_power_manageable(acpi_hand
bool acpi_bus_can_wakeup(acpi_handle handle);
int acpi_power_resource_register_device(struct device *dev, acpi_handle
handle);
void acpi_power_resource_unregister_device(struct device *dev, acpi_handle
handle);
+int acpi_bus_remove(struct acpi_device *dev, int rmdevice);
#ifdef CONFIG_ACPI_PROC_EVENT
int acpi_bus_generate_proc_event(struct acpi_device *device, u8 type, int
data);
int acpi_bus_generate_proc_event4(const char *class, const char *bid, u8 type,
int data);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] acpi,memory-hotplug : remove memory device by acpi_bus_remove()
The patch-set was divided from following thread's patch-set. https://lkml.org/lkml/2012/9/5/201 If you want to know the reason, please read following thread. https://lkml.org/lkml/2012/10/2/83 The patch exports "acpi_bus_remove()" for removing a acpi device from a acpi bus at memory hot plug. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
On Wed, Oct 3, 2012 at 6:33 PM, Ming Lei wrote: > > Yes, the patch will make firmware cache not working, I would like to fix > that when I return from one trip next week. > > BTW, firmware cache is still needed even direct loading is taken. I agree 100%, I'd have liked to do the caching for the direct-loading case too. It's just that the freeing case for that is so intimately tied to the firmware_buf format which is actually very inconvenient for direct-loading, that making that happen looked a lot more involved. And I was indeed hoping you'd look at it, since you touched the code last. "Tag, you're it" It shouldn't be *too* bad to instead of doing the "vmalloc()" allocate an array of pages and then using "vmap()" instead in order to read them (we end up doing the vmap anyway, since the firmware *user* wants a virtually contiguous buffer), but the code will definitely get a bit more opaque. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the acpi tree with Linus' tree
Hi Len,
Today's linux-next merge of the acpi tree got a conflict in
include/acpi/acpixf.h between commit a1ce39288e6f ("UAPI: (Scripted)
Convert #include "..." to #include in kernel system headers")
from Linus' tree and commit be030a576854 ("ACPICA: Add support for
complex _PLD buffers") from the acpi 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 include/acpi/acpixf.h
index 51405d3,267bfc4..000
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@@ -47,11 -47,12 +47,12 @@@
/* Current ACPICA subsystem version in MMDD format */
- #define ACPI_CA_VERSION 0x20120711
+ #define ACPI_CA_VERSION 0x20120913
-#include "acconfig.h"
-#include "actypes.h"
-#include "actbl.h"
-#include "acbuffer.h"
+#include
+#include
+#include
++#include
extern u8 acpi_gbl_permanent_mmap;
pgpZou6MPMYQq.pgp
Description: PGP signature
[PATCH] extcon: MAX77693: Add platform data for MUIC device to initialize registers
This patch add platform data for MUIC device to initialize register
on probe() call because it should unmask interrupt mask register
and initialize some register related to MUIC device.
Signed-off-by: Chanwoo Choi
Signed-off-by: Myungjoo Ham
Signed-off-by: Kyungmin Park
---
drivers/extcon/extcon-max77693.c | 27 +++
include/linux/mfd/max77693.h | 13 +
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/drivers/extcon/extcon-max77693.c b/drivers/extcon/extcon-max77693.c
index ac9bac8..3e9520a 100644
--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -651,6 +651,8 @@ out:
static int __devinit max77693_muic_probe(struct platform_device *pdev)
{
struct max77693_dev *max77693 = dev_get_drvdata(pdev->dev.parent);
+ struct max77693_platform_data *pdata = dev_get_platdata(max77693->dev);
+ struct max77693_muic_platform_data *muic_pdata = pdata->muic_data;
struct max77693_muic_info *info;
int ret, i;
u8 id;
@@ -721,6 +723,31 @@ static int __devinit max77693_muic_probe(struct
platform_device *pdev)
goto err_extcon;
}
+ /* Initialize MUIC register by using platform data */
+ for (i = 0 ; i < muic_pdata->num_init_data ; i++) {
+ enum max77693_irq_source irq_src = MAX77693_IRQ_GROUP_NR;
+
+ max77693_write_reg(info->max77693->regmap_muic,
+ muic_pdata->init_data[i].addr,
+ muic_pdata->init_data[i].data);
+
+ switch (muic_pdata->init_data[i].addr) {
+ case MAX77693_MUIC_REG_INTMASK1:
+ irq_src = MUIC_INT1;
+ break;
+ case MAX77693_MUIC_REG_INTMASK2:
+ irq_src = MUIC_INT2;
+ break;
+ case MAX77693_MUIC_REG_INTMASK3:
+ irq_src = MUIC_INT3;
+ break;
+ }
+
+ if (irq_src < MAX77693_IRQ_GROUP_NR)
+ info->max77693->irq_masks_cur[irq_src]
+ = muic_pdata->init_data[i].data;
+ }
+
/* Check revision number of MUIC device*/
ret = max77693_read_reg(info->max77693->regmap_muic,
MAX77693_MUIC_REG_ID, );
diff --git a/include/linux/mfd/max77693.h b/include/linux/mfd/max77693.h
index 1d28ae9..fe03b2d 100644
--- a/include/linux/mfd/max77693.h
+++ b/include/linux/mfd/max77693.h
@@ -30,7 +30,20 @@
#ifndef __LINUX_MFD_MAX77693_H
#define __LINUX_MFD_MAX77693_H
+struct max77693_reg_data {
+ u8 addr;
+ u8 data;
+};
+
+struct max77693_muic_platform_data {
+ struct max77693_reg_data *init_data;
+ int num_init_data;
+};
+
struct max77693_platform_data {
int wakeup;
+
+ /* muic data */
+ struct max77693_muic_platform_data *muic_data;
};
#endif /* __LINUX_MFD_MAX77693_H */
--
1.7.0.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 0/3] virtio-net: inline header support
Rusty Russell writes:
> "Michael S. Tsirkin" writes:
>
> There's a reason I haven't done this. I really, really dislike "my
> implemention isn't broken" feature bits. We could have an infinite
> number of them, for each bug in each device.
>
> So my plan was to tie this assumption to the new PCI layout. And have a
> stress-testing patch like the one below in the kernel (see my virtio-wip
> branch for stuff like this). Turn it on at boot with
> "virtio_ring.torture" on the kernel commandline.
>
> BTW, I've fixed lguest, but my kvm here (Ubuntu precise, kvm-qemu 1.0)
> is too old. Building the latest git now...
>
> Cheers,
> Rusty.
>
> Subject: virtio: CONFIG_VIRTIO_DEVICE_TORTURE
>
> Virtio devices are not supposed to depend on the framing of the scatter-gather
> lists, but various implementations did. Safeguard this in future by adding
> an option to deliberately create perverse descriptors.
>
> Signed-off-by: Rusty Russell
Ignore framing is really a bad idea. You want backends to enforce
reasonable framing because guest's shouldn't do silly things with framing.
For instance, with virtio-blk, if you want decent performance, you
absolutely want to avoid bouncing the data. If you're using O_DIRECT in
the host to submit I/O requests, then it's critical that all of the s/g
elements are aligned to a sector boundary and sized to a sector
boundary.
Yes, QEMU can handle if that's not the case, but it would be insanely
stupid for a guest not to do this. This is the sort of thing that ought
to be enforced in the specification because a guest cannot perform well
if it doesn't follow these rules.
A spec isn't terribly useful if the result is guest drivers that are
slow. There's very little to gain by not enforcing rules around framing
and there's a lot to lose if a guest frames incorrectly.
In the rare case where we want to make a framing change, we should use
feature bits like Michael is proposing.
In this case, we should simply say that with the feature bit, the vnet
header can be in the same element as the data but not allow the header
to be spread across multiple elements.
Regards,
Anthony Liguori
>
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 8d5bddb..930a4ea 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -5,6 +5,15 @@ config VIRTIO
> bus, such as CONFIG_VIRTIO_PCI, CONFIG_VIRTIO_MMIO, CONFIG_LGUEST,
> CONFIG_RPMSG or CONFIG_S390_GUEST.
>
> +config VIRTIO_DEVICE_TORTURE
> + bool "Virtio device torture tests"
> + depends on VIRTIO && DEBUG_KERNEL
> + help
> + This makes the virtio_ring implementation creatively change
> + the format of requests to make sure that devices are
> + properly implemented. This will make your virtual machine
> + slow *and* unreliable! Say N.
> +
> menu "Virtio drivers"
>
> config VIRTIO_PCI
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index e639584..8893753 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -124,6 +124,149 @@ struct vring_virtqueue
>
> #define to_vvq(_vq) container_of(_vq, struct vring_virtqueue, vq)
>
> +#ifdef CONFIG_VIRTIO_DEVICE_TORTURE
> +static bool torture;
> +module_param(torture, bool, 0644);
> +
> +struct torture {
> + unsigned int orig_out, orig_in;
> + void *orig_data;
> + struct scatterlist sg[4];
> + struct scatterlist orig_sg[];
> +};
> +
> +static size_t tot_len(struct scatterlist sg[], unsigned num)
> +{
> + size_t len, i;
> +
> + for (len = 0, i = 0; i < num; i++)
> + len += sg[i].length;
> +
> + return len;
> +}
> +
> +static void copy_sg_data(const struct scatterlist *dst, unsigned dnum,
> + const struct scatterlist *src, unsigned snum)
> +{
> + unsigned len;
> + struct scatterlist s, d;
> +
> + s = *src;
> + d = *dst;
> +
> + while (snum && dnum) {
> + len = min(s.length, d.length);
> + memcpy(sg_virt(), sg_virt(), len);
> + d.offset += len;
> + d.length -= len;
> + s.offset += len;
> + s.length -= len;
> + if (!s.length) {
> + BUG_ON(snum == 0);
> + src++;
> + snum--;
> + s = *src;
> + }
> + if (!d.length) {
> + BUG_ON(dnum == 0);
> + dst++;
> + dnum--;
> + d = *dst;
> + }
> + }
> +}
> +
> +static bool torture_replace(struct scatterlist **sg,
> + unsigned int *out,
> + unsigned int *in,
> + void **data,
> + gfp_t gfp)
> +{
> + static size_t seed;
> + struct torture *t;
> + size_t outlen, inlen, ourseed, len1;
> + void *buf;
> +
> + if (!torture)
> + return
Re: [PATCH] extcon: max77693: Use max77693_update_reg for rmw operations
On 10/03/2012 12:59 AM, Axel Lin wrote:
> This simplifies the code.
>
> Signed-off-by: Axel Lin
> ---
> drivers/extcon/extcon-max77693.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/extcon/extcon-max77693.c
> b/drivers/extcon/extcon-max77693.c
> index e21387e..e0ed622 100644
> --- a/drivers/extcon/extcon-max77693.c
> +++ b/drivers/extcon/extcon-max77693.c
> @@ -239,25 +239,19 @@ const char *max77693_extcon_cable[] = {
> static int max77693_muic_set_debounce_time(struct max77693_muic_info *info,
> enum max77693_muic_adc_debounce_time time)
> {
> - int ret = 0;
> - u8 ctrl3;
> + int ret;
>
> switch (time) {
> case ADC_DEBOUNCE_TIME_5MS:
> case ADC_DEBOUNCE_TIME_10MS:
> case ADC_DEBOUNCE_TIME_25MS:
> case ADC_DEBOUNCE_TIME_38_62MS:
> - ret = max77693_read_reg(info->max77693->regmap_muic,
> - MAX77693_MUIC_REG_CTRL3, );
> - ctrl3 &= ~CONTROL3_ADCDBSET_MASK;
> - ctrl3 |= (time << CONTROL3_ADCDBSET_SHIFT);
> -
> - ret = max77693_write_reg(info->max77693->regmap_muic,
> - MAX77693_MUIC_REG_CTRL3, ctrl3);
> - if (ret) {
> + ret = max77693_update_reg(info->max77693->regmap_muic,
> + MAX77693_MUIC_REG_CTRL3,
> + time << CONTROL3_ADCDBSET_SHIFT,
> + CONTROL3_ADCDBSET_MASK);
> + if (ret)
> dev_err(info->dev, "failed to set ADC debounce time\n");
> - ret = -EINVAL;
> - }
> break;
> default:
> dev_err(info->dev, "invalid ADC debounce time\n");
Applied, thanks.
Cheers,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] extcon: Fix kerneldoc for extcon_set_cable_state and extcon_set_cable_state_
On 10/03/2012 12:30 AM, Axel Lin wrote: > Signed-off-by: Axel Lin > --- > drivers/extcon/extcon-class.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c > index 946a318..337bbb4 100644 > --- a/drivers/extcon/extcon-class.c > +++ b/drivers/extcon/extcon-class.c > @@ -362,7 +362,7 @@ int extcon_get_cable_state(struct extcon_dev *edev, const > char *cable_name) > EXPORT_SYMBOL_GPL(extcon_get_cable_state); > > /** > - * extcon_get_cable_state_() - Set the status of a specific cable. > + * extcon_set_cable_state_() - Set the status of a specific cable. > * @edev:the extcon device that has the cable. > * @index: cable index that can be retrieved by extcon_find_cable_index(). > * @cable_state: the new cable status. The default semantics is > @@ -382,7 +382,7 @@ int extcon_set_cable_state_(struct extcon_dev *edev, > EXPORT_SYMBOL_GPL(extcon_set_cable_state_); > > /** > - * extcon_get_cable_state() - Set the status of a specific cable. > + * extcon_set_cable_state() - Set the status of a specific cable. > * @edev:the extcon device that has the cable. > * @cable_name: cable name. > * @cable_state: the new cable status. The default semantics is Applied, thanks. I applied this patch at extcon git repository and you can check it after some hours. - http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/extcon-for-next Thank you, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] extcon: max77693: Fix max77693_muic_probe error handling
On 10/03/2012 11:23 AM, Axel Lin wrote:
> Fix below issues:
> 1. If request_threaded_irq() fails, current code does not free all requested
>irqs.
> 2. Add missing extcon_dev_unregister() in error path if failed to read
> revision
>number.
>
> Signed-off-by: Axel Lin
> ---
> drivers/extcon/extcon-max77693.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/extcon/extcon-max77693.c
> b/drivers/extcon/extcon-max77693.c
> index e0ed622..9928c63 100644
> --- a/drivers/extcon/extcon-max77693.c
> +++ b/drivers/extcon/extcon-max77693.c
> @@ -696,12 +696,8 @@ static int __devinit max77693_muic_probe(struct
> platform_device *pdev)
> IRQF_ONESHOT, muic_irq->name, info);
> if (ret) {
> dev_err(>dev,
> - "failed: irq request (IRQ: %d,"
> - " error :%d)\n",
> + "failed: irq request (IRQ: %d, error :%d)\n",
> muic_irq->irq, ret);
> -
> - for (i = i - 1; i >= 0; i--)
> - free_irq(muic_irq->virq, info);
> goto err_irq;
> }
> }
> @@ -726,7 +722,7 @@ static int __devinit max77693_muic_probe(struct
> platform_device *pdev)
> MAX77693_MUIC_REG_ID, );
> if (ret < 0) {
> dev_err(>dev, "failed to read revision number\n");
> - goto err_extcon;
> + goto err_read_reg;
> }
> dev_info(info->dev, "device ID : 0x%x\n", id);
>
> @@ -738,9 +734,13 @@ static int __devinit max77693_muic_probe(struct
> platform_device *pdev)
>
> return ret;
>
> +err_read_reg:
> + extcon_dev_unregister(info->edev);
> err_extcon:
> kfree(info->edev);
> err_irq:
> + while (--i >= 0)
> + free_irq(muic_irqs[i].virq, info);
This include possible error when 'i' variable may be used after
completed request_thread_irq() operation. I think the below patch
is appropriate because free_irq() function return NULL if first parameter
is unrequested irq.
err_irq:
+ for (i = 0; i < ARRAY_SIZE(muic_irqs); i++)
+ free_irq(muic_irqs[i].virq, info);
Thank you,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
3.6.0+ (GIT) -- BUG: sleeping function called from invalid context at kernel/mutex.c:269 in_atomic(): 0, irqs_disabled(): 1, pid: 3561, name: pm-suspend
ACPI: Preparing to enter system sleep state S3
PM: Saving platform NVS memory
Disabling non-boot CPUs ...
numa_remove_cpu cpu 1 node 0: mask now 0
Broke affinity for irq 46
smpboot: CPU 1 is now offline
BUG: sleeping function called from invalid context at kernel/mutex.c:269
in_atomic(): 0, irqs_disabled(): 1, pid: 3561, name: pm-suspend
4 locks held by pm-suspend/3561:
#0: (>mutex){+.+.+.}, at: []
sysfs_write_file+0x37/0x121
#1: (s_active#98){.+.+.+}, at: []
sysfs_write_file+0xd1/0x121
#2: (autosleep_lock){+.+.+.}, at: []
pm_autosleep_lock+0x12/0x14
#3: (pm_mutex){+.+.+.}, at: [] pm_suspend+0x38/0x1b8
irq event stamp: 103458
hardirqs last enabled at (103457): []
__mutex_unlock_slowpath+0x101/0x125
hardirqs last disabled at (103458): []
arch_suspend_disable_irqs+0xa/0xc
softirqs last enabled at (103196): []
__do_softirq+0x12a/0x155
softirqs last disabled at (103171): [] call_softirq+0x1c/0x30
Pid: 3561, comm: pm-suspend Not tainted 3.6.0+ #26
Call Trace:
[] ? print_irqtrace_events+0x9d/0xa1
[] __might_sleep+0x19f/0x1a8
[] mutex_lock_nested+0x20/0x3b
[] ledtrig_cpu+0x3b/0x7b
[] ledtrig_cpu_syscore_suspend+0xe/0x15
[] syscore_suspend+0x78/0xfd
[] suspend_devices_and_enter+0x10f/0x201
[] pm_suspend+0xff/0x1b8
[] state_store+0x43/0x6c
[] kobj_attr_store+0xf/0x1b
[] sysfs_write_file+0xe9/0x121
[] vfs_write+0x9b/0xfd
[] ? trace_hardirqs_on+0xd/0xf
[] sys_write+0x4d/0x7a
[] tracesys+0xdd/0xe2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] virtio-net: inline header support
Rusty Russell writes: > "Michael S. Tsirkin" writes: > >> Thinking about Sasha's patches, we can reduce ring usage >> for virtio net small packets dramatically if we put >> virtio net header inline with the data. >> This can be done for free in case guest net stack allocated >> extra head room for the packet, and I don't see >> why would this have any downsides. > > I've been wanting to do this for the longest time... but... > >> Even though with my recent patches qemu >> no longer requires header to be the first s/g element, >> we need a new feature bit to detect this. >> A trivial qemu patch will be sent separately. > > There's a reason I haven't done this. I really, really dislike "my > implemention isn't broken" feature bits. We could have an infinite > number of them, for each bug in each device. This is a bug in the specification. The QEMU implementation pre-dates the specification. All of the actual implementations of virtio relied on the semantics of s/g elements and still do. What's in the specification really doesn't matter when it doesn't agree with all of the existing implementations. Users use implementations, not specifications. The specification really ought to be changed here. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] virtio-net: correct capacity math on ring full
"Michael S. Tsirkin" writes:
> Capacity math on ring full is wrong: we are
> looking at num_sg but that might be optimistic
> because of indirect buffer use.
>
> The implementation also penalizes fast path
> with extra memory accesses for the benefit of
> ring full condition handling which is slow path.
>
> It's easy to query ring capacity so let's do just that.
This path will reduce the actual queue use to worst-case assumptions.
With bufferbloat maybe that's a good thing, but it's true.
If we do this, the code is now wrong:
/* This can happen with OOM and indirect buffers. */
if (unlikely(capacity < 0)) {
Because this should now *never* happen.
But I do like the cleanup; returning capacity from add_buf() was always
hacky. I've got an idea, we'll see what it looks like...
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [GIT PULL] Asymmetric keys and module signing
David Howells writes: > Rusty Russell wrote: > >> Right. I think we need to use different names for generated vs supplied >> files > > The problem with supplied files is people who do allyesconfig, allmodconfig > and randconfig just to test things finding that their builds break. The > kernel build magic is not really set up to handle external files like this. I > suppose make logic can be used to conditionally include stuff that might not > exist. > >> BTW, you missed a Signed-off-by: on your "MODSIGN: Use the same digest >> for the autogen key sig as for the module sig" patch. Please update. > > Done. > > I've also added a patch to convert the system clock to a struct tm and to > produce a struct tm within the ASN.1 decode and then compare those rather than > time_t values as a way to deal with the validity time overflow problem. We > may have to be able to handle certificates that we haven't generated that > stretch beyond 2038 (I wonder if we might find such in the UEFI key database > for example. OK, cherry-picked to replace my hack. It's in linux-next, and I will push in the next two days. Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] virtio-net: inline header support
Paolo Bonzini writes: > Il 03/10/2012 08:44, Rusty Russell ha scritto: >> There's a reason I haven't done this. I really, really dislike "my >> implemention isn't broken" feature bits. We could have an infinite >> number of them, for each bug in each device. > > However, this bug affects (almost) all implementations and (almost) all > devices. It even makes sense to reserve a transport feature bit for it > instead of a device feature bit. > > Paolo Perhaps, but we have to fix the bugs first! As I said, my torture patch broke qemu immediately. Since noone has leapt onto fixing that, I'll take a look now... Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pwm: Check for negative duty-cycle and period
On Monday, October 01, 2012 3:35 PM Thierry Reding wrote
>
> Make sure the duty-cycle and period passed in are not negative. This
> should eventually be made implicit by making them unsigned. While at
> it, the drivers' .config() implementations can have the equivalent
> checks removed.
>
> Signed-off-by: Thierry Reding
> Cc: Shawn Guo
> Cc: Mark Brown
> Cc: Arnd Bergmann
> Cc: Sachin Kamat
> Cc: Axel Lin
> Cc: Kukjin Kim
> Cc: Jingoo Han
Acked-by: Jingoo Han
> Cc: Jonghwan Choi
> Cc: Sascha Hauer
> Cc: "Philip, Avinash"
> Cc: Vaibhav Bedia
> ---
> drivers/pwm/core.c | 2 +-
> drivers/pwm/pwm-bfin.c | 3 ---
> drivers/pwm/pwm-pxa.c | 3 ---
> drivers/pwm/pwm-samsung.c | 3 ---
> drivers/pwm/pwm-tiecap.c | 2 +-
> drivers/pwm/pwm-tiehrpwm.c | 2 +-
> 6 files changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 92b1782..f5acdaa 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -371,7 +371,7 @@ EXPORT_SYMBOL_GPL(pwm_free);
> */
> int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
> {
> - if (!pwm || period_ns == 0 || duty_ns > period_ns)
> + if (!pwm || duty_ns < 0 || period_ns <= 0 || duty_ns > period_ns)
> return -EINVAL;
>
> return pwm->chip->ops->config(pwm->chip, pwm, duty_ns, period_ns);
> diff --git a/drivers/pwm/pwm-bfin.c b/drivers/pwm/pwm-bfin.c
> index d53c4e7..5da8e18 100644
> --- a/drivers/pwm/pwm-bfin.c
> +++ b/drivers/pwm/pwm-bfin.c
> @@ -69,9 +69,6 @@ static int bfin_pwm_config(struct pwm_chip *chip, struct
> pwm_device *pwm,
> unsigned long period, duty;
> unsigned long long val;
>
> - if (duty_ns < 0 || duty_ns > period_ns)
> - return -EINVAL;
> -
> val = (unsigned long long)get_sclk() * period_ns;
> do_div(val, NSEC_PER_SEC);
> period = val;
> diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
> index bd5867a..260c3a8 100644
> --- a/drivers/pwm/pwm-pxa.c
> +++ b/drivers/pwm/pwm-pxa.c
> @@ -70,9 +70,6 @@ static int pxa_pwm_config(struct pwm_chip *chip, struct
> pwm_device *pwm,
> unsigned long offset;
> int rc;
>
> - if (period_ns == 0 || duty_ns > period_ns)
> - return -EINVAL;
> -
> offset = pwm->hwpwm ? 0x10 : 0;
>
> c = clk_get_rate(pc->clk);
> diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
> index e5187c0..023a3be 100644
> --- a/drivers/pwm/pwm-samsung.c
> +++ b/drivers/pwm/pwm-samsung.c
> @@ -126,9 +126,6 @@ static int s3c_pwm_config(struct pwm_chip *chip, struct
> pwm_device *pwm,
> if (period_ns > NS_IN_HZ || duty_ns > NS_IN_HZ)
> return -ERANGE;
>
> - if (duty_ns > period_ns)
> - return -EINVAL;
> -
> if (period_ns == s3c->period_ns &&
> duty_ns == s3c->duty_ns)
> return 0;
> diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
> index 081471f..d6d4cf0 100644
> --- a/drivers/pwm/pwm-tiecap.c
> +++ b/drivers/pwm/pwm-tiecap.c
> @@ -60,7 +60,7 @@ static int ecap_pwm_config(struct pwm_chip *chip, struct
> pwm_device *pwm,
> unsigned long period_cycles, duty_cycles;
> unsigned int reg_val;
>
> - if (period_ns < 0 || duty_ns < 0 || period_ns > NSEC_PER_SEC)
> + if (period_ns > NSEC_PER_SEC)
> return -ERANGE;
>
> c = pc->clk_rate;
> diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
> index caf00fe..d3c1dff 100644
> --- a/drivers/pwm/pwm-tiehrpwm.c
> +++ b/drivers/pwm/pwm-tiehrpwm.c
> @@ -221,7 +221,7 @@ static int ehrpwm_pwm_config(struct pwm_chip *chip,
> struct pwm_device *pwm,
> unsigned short ps_divval, tb_divval;
> int i, cmp_reg;
>
> - if (period_ns < 0 || duty_ns < 0 || period_ns > NSEC_PER_SEC)
> + if (period_ns > NSEC_PER_SEC)
> return -ERANGE;
>
> c = pc->clk_rate;
> --
> 1.7.12.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: linux-next: build failure after merge of the net tree
Hi David, On Wed, 03 Oct 2012 20:50:53 -0400 (EDT) David Miller wrote: > > I do have a question though, it is honestly really that much easier to > revert a whole days worth of changes (and therefore not get the code > tested at all) than to simply add the obvious one liner? Actually, for me it is. I have a script that does the "use yesterday's version" for me. To fix (even a one liner) means bringing up an editor, commiting, creating the patch and then recommiting it (an implementation detail) and recording that I need to keep (automatically) applying the patch in case the maintainer doesn't react quickly. In this particular case I have been telling people to include vmalloc.h (and other things like slab.h) over and over for years ... its a pain that x86 builds indirectly include so much stuff. > It seems to me to be absolutely the wrong tradeoff in these situations. I guess for the "current/fixes" tree during the merge window, you are right. For the "normal" trees, does a delay of (usually) one day really matter? I used to fix all this stuff and it added considerably to the length of my work day (which currently can be up to 16 hours long) :-( -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpXzzsRTgF2E.pgp Description: PGP signature
Re: [RFC, PATCH] Extensible AIO interface
On Tue, Oct 02, 2012 at 07:41:10PM -0700, Kent Overstreet wrote: > On Wed, Oct 03, 2012 at 11:28:25AM +1000, Dave Chinner wrote: > > On Tue, Oct 02, 2012 at 05:20:29PM -0700, Kent Overstreet wrote: > > > On Tue, Oct 02, 2012 at 01:41:17PM -0400, Jeff Moyer wrote: > > > > Kent Overstreet writes: > > > > > > > > > So, I and other people keep running into things where we really need > > > > > to > > > > > add an interface to pass some auxiliary... stuff along with a pread() > > > > > or > > > > > pwrite(). > > > > > > > > > > A few examples: > > > > > > > > > > * IO scheduler hints. Some userspace program wants to, per IO, specify > > > > > either priorities or a cgroup - by specifying a cgroup you can have a > > > > > fileserver in userspace that makes use of cfq's per cgroup bandwidth > > > > > quotas. > > > > > > > > You can do this today by splitting I/O between processes and placing > > > > those processes in different cgroups. For io priority, there is > > > > ioprio_set, which incurs an extra system call, but can be used. Not > > > > elegant, but possible. > > > > > > Yes - those are things I'm trying to replace. Doing it that way is a > > > real pain, both as it's a lousy interface for this and it does impact > > > performance (ioprio_set doesn't really work too well with aio, too). > > > > > > > > * Cache hints. For bcache and other things, userspace may want to > > > > > specify > > > > > "this data should be cached", "this data should bypass the cache", > > > > > etc. > > > > > > > > Please explain how you will differentiate this from posix_fadvise. > > > > > > Oh sorry, I think about SSD caching so much I forget to say that's what > > > I'm talking about. posix_fadvise is for the page cache, we want > > > something different for an SSD cache (IMO it'd be really ugly to use it > > > for both, and posix_fadvise() can't really specifify everything we'd > > > want to for an SSD cache). > > > > Similar discussions about posix_fadvise() are being had for marking > > ranges of files as volatile (i.e. useful for determining what can be > > evicted from a cache when space reclaim is required). > > > > https://lkml.org/lkml/2012/10/2/501 > > Hmm, interesting > > Speaking as an implementor though, hints that aren't associated with any > specific IO are harder to make use of - stuff is in the cache. What you > really want is to know, for a given IO, whether to cache it or not, and > possibly where in the LRU to stick it. I can see how it might be useful, but it needs to have a defined set of attributes that a file IO is allowed to have. If you don't define the set, then what really have is an arbitrary set of storage-device specific interfaces. Of course, once we have a defined set of per-file IO policy attributes, we don't really need per-IO attributes - you can just set them through a range interface like fadvise() or fallocate(). > Well, it's quite possible that different implementations would have no > trouble making use of those kinds of hints, I'm no doubt biased by > having implemented bcache. With bcache though, cache replacement is done > in terms of physical address space, not logical (i.e. the address space > of the device being cached). > > So to handle posix_fadvise, we'd have to walk the btree and chase > pointers to buckets, and modify the bucket priorities up or down... but > what about the other data in those buckets? It's not clear what should > happen, but there isn't any good way to take that into account. > > (The exception is dropping data from the cache entirely, we can just > invalidate that part of the keyspace and garbage collection will reclaim > the buckets they pointed to. Bcache does that for discard requests, > currently). It sounds to me like you are saying is that the design of bcache is unsuited to file-level management of caching policy, and that is why you want to pass attributes directly to bcache with specific IOs. Is that a fair summary of the problem you are describing here? My problem with this approach has nothing to do with the per-IO nature of it - it's to do with the layering violations and the amount of storage specific knowledge needed to make effective use of it. i.e. it seems like an interface that can only be used by people intimately familiar with underlying storage implementation. You happen to be one of those people, so I figure that you don't see a problem with that. ;) However, it also implies that an application must understand and use a specific storage configuration that matches the attributes an application sends. I understand how this model is appealling to Google because they control the whole application and storage stack (hardware and software) from top to bottom. However, I just don't think that it is a solution that the rest of the world can use effectively. The scope of data locality, aging and IO priority policy control is much larger than just controlling SSD caching. SSD caching is just a another implementation of
Re: Soft lockup in scsi_remove_target under 3.6 (regression from 3.5)
On Tue, Oct 02, 2012 at 10:46:22PM -0500, Mike Christie wrote: > On 10/02/2012 07:43 PM, Jonathan McDowell wrote: > > Upgraded to 3.6 today on my dev box and after seeing an FC attached SAN > > go down and come back up (due to an expected reboot) I started getting > > the following in my logs. It continues even after the array is back and > > functioning - I'm seeing: > > > > kernel:[109104.348034] BUG: soft lockup - CPU#6 stuck for 23s! > > [kworker/6:0:30692] > > > > repeated on logged in sessions and backtraces like the following (this > > is the first). I don't see the same problem under 3.5. > > > I think you need this patch > http://marc.info/?l=linux-scsi=134621716223056=2 Perfect, that solves it. Tested-By: Jonathan McDowell J. -- Hats off to the insane. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: udev breakages -
On 3 Oct 2012, Al Viro spake thusly: > Looks sane. TBH, I'd still prefer to see udev forcibly taken over and put > into > usr/udev in kernel tree - I don't trust that crowd at all and the fewer > critical userland bits they can play leverage games with, the safer we are. > > Al, that -><- close to volunteering for maintaining that FPOS kernel-side... Please! It has already been forked at least once in userspace by people who have the temerity to *not use systemd*, imagine that! and still want a udev that is up-to-date in other ways. (We are now being told that, contrary to what was said when udev was migrated into the systemd tree, running udev without systemd is now deprecated and untested and might go away completely. How surprising, nobody ever predicted that when it migrated in, oh wait yes we did, and were assured that we were wrong, that standalone udev would always be supported for those of us who weren't using systemd. Way to destroy your userbase's trust in you...) Possibly udev 175, the last standalone udev as far as I know, is a good place to start from: but you might want to go back a release or two before that, since 174 was where they started doing insane backward-compatibility breaks. By 175 they were requiring devtmpfs, no longer creating device nodes (which I thought was the original *point* of udev), moving lots of install locations on the assumption that / and /usr were on the same filesystem, and migrating udevd from /sbin into /lib/udev without bothering to provide a backward-compatibility symlink. Net benefit of all this thrashing about to udev users: nil. Net sysadmin overhead on upgrade: substantial, oh and if you don't do it your system won't boot. By udev 175 I, and a lot of other people, had simply stopped upgrading udev entirely on the grounds that we could no longer tolerate the uncertainty over whether our systems would boot every time we upgraded it, for no discernible benefit. Yes, all the incompatible changes are (or were, as of udev 175) called out in the release notes -- but there are so *many* of them, it's easy to miss one. And they all seem so completely unnecessary, and their implications for your system configuration grow more and more invasive all the time. When gregkh was maintaining udev it was nicely robust and kept working from release to release, and just did its job without requiring us to change the way our system booted in backwardly-incompatible ways on every release, merge filesystems together or mount /usr in early boot (which is SSH-tunneled over a network in the case of one of my systems, that was fun to do in the initramfs), or install invasive packages that extend tentacles throughout the entire system, require a complete rewriting of my boot process and require millions of kernel features that may not always be turned on. I'd like those days back. I can trust the kernel people to maintain some semblance of userspace compatibility between releases, as is crucial for boot-critical processes. It is now quite clear that I cannot trust the present udev maintainers, or anyone else involved in the ongoing Linux desktop trainwreck, to do any such thing. -- NULL && (void) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute
On Wed, Oct 3, 2012 at 7:46 AM, Daniel Santos wrote: > On 10/03/2012 09:01 AM, Steven Rostedt wrote: >> You don't need to use get_maintainers. It's more of a help tool to find >> maintainers and not something that is mandatory. Not everyone that has >> ever touched one of these files needs to be Cc'd. >> >> Please move the patch to the patch series where it is used. Otherwise it >> confuses reviewers as it did here. > Ok then, but this would also apply to the addition of these macros as well: > BUILD_BUG_ON_NON_CONST > BUILD_BUG42 > BUILD_BUG_ON_NON_CONST42 > > Should these then also be moved? Yes, this would actually make things easier. > Should I only CC those who have responded to these patches and whomever > is in the MAINTAINERS file then? There is no strong rule here, but generally get_maintainers returns too many people. You want to trim down the list to something shorter; a dozen people is the most I would consider (but for most patches a half-dozen is already plenty). -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute
On 10/03/2012 07:32 PM, Steven Rostedt wrote:
> On Wed, 2012-10-03 at 08:38 -0700, Joe Perches wrote:
>> On Wed, 2012-10-03 at 11:14 -0400, Steven Rostedt wrote:
>>> I first check
>>> the MAINTAINERS file. If the subsystem I'm working on exists there, I
>>> only email those that are listed there, including any mailing lists that
>>> are mentioned (as well as LKML). If it's not listed, I then do a git log
>>> and see who does the most sign offs to changes there, and to what kind
>>> of changes. I usually ignore the trivial stuff.
>>
>> Funny because that's what the script does too.
>>
>
> Really? It ignores the trivial stuff and only adds people that seem to
> actually do real work on the file?
>
> If that's the case, I doubt that it would have caused the huge Cc list
> that Daniel sent out.
>
> -- Steve
Well, you run that on:
* include/linux/bug.h,
* include/linux/compiler{,-gcc{,3,4}}.h,
* include/linux/rbtree.h,
* tools/testing/selftests,
* Documentation/DocBook/kernel-api.tmpl and
* scripts/kernel-doc,
and it really starts to add up (that's currently 23 on mmotm, not including
myself). Now, add people already involved in the patch set, etc., and it
makes
its way to 30. That's why I split the patch set up.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net tree
From: Stephen Rothwell
Date: Thu, 4 Oct 2012 10:18:33 +1000
> After merging the net tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: In function 't4_memory_rw':
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:420:2: error: implicit declaration
> of function 'vmalloc' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:420:7: warning: assignment makes
> pointer from integer without a cast [enabled by default]
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:487:2: error: implicit declaration
> of function 'vfree' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: In function 'get_vpd_params':
> drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:530:6: warning: assignment makes
> pointer from integer without a cast [enabled by default]
>
> Caused by commit 8c357ebd5693 ("cxgb4: Dynamically allocate memory in
> t4_memory_rw() and get_vpd_params()"). Missing include of
> linux/vmalloc.h.
>
> I have used the net tree from next-20121003 for today.
Thanks, I'll fix this as is shown below.
I do have a question though, it is honestly really that much easier to
revert a whole days worth of changes (and therefore not get the code
tested at all) than to simply add the obvious one liner?
It seems to me to be absolutely the wrong tradeoff in these situations.
[PATCH] cxgb4: Fix build error due to missing linux/vmalloc.h include.
Reported-by: Stephen Rothwell
Signed-off-by: David S. Miller
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 745a1f5..31752b2 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include "cxgb4_uld.h"
#include "t4_hw.h"
--
1.7.11.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 1/2] Fix build error caused by broken PCH_PTP module dependency.
From: Ben Hutchings Date: Wed, 3 Oct 2012 22:45:10 +0100 > I thought of it as being a peripheral feature (which most Solarflare > hardware doesn't implement) so it made sense for SFC_PTP to be optional > like SFC_MTD and so on. But I'm quite happy to use a select instead, if > you want that to be the convention for all drivers implementing PHC. I think that consistency might trump those conerns you mentioned, at least in this case. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 16/20] drivers/net/ethernet/renesas/sh_eth.c: fix error return code
Peter Senna Tschudin さんは書きました:
> From: Peter Senna Tschudin
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> //
> (
> if@p1 (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when !=
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
> //
>
> Signed-off-by: Peter Senna Tschudin
Acked-by: Nobuhiro Iwamatsu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 3/7] swiotlb: Make io_tlb_overflow_buffer a physical address
This change makes it so that we can avoid virt_to_phys overhead when using the
io_tlb_overflow_buffer. My original plan was to completely remove the value
and replace it with a constant but I had seen that there were recent patches
that stated this couldn't be done until all device drivers that depended on
that functionality be updated.
Signed-off-by: Alexander Duyck
---
lib/swiotlb.c | 61 -
1 files changed, 34 insertions(+), 27 deletions(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 02abb72..62848fb 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -70,7 +70,7 @@ static unsigned long io_tlb_nslabs;
*/
static unsigned long io_tlb_overflow = 32*1024;
-static void *io_tlb_overflow_buffer;
+phys_addr_t io_tlb_overflow_buffer;
/*
* This is a free list describing the number of free entries available from
@@ -138,6 +138,7 @@ void swiotlb_print_info(void)
void __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
{
+ void *v_overflow_buffer;
unsigned long i, bytes;
bytes = nslabs << IO_TLB_SHIFT;
@@ -146,6 +147,15 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long
nslabs, int verbose)
io_tlb_start = __pa(tlb);
/*
+* Get the overflow emergency buffer
+*/
+ v_overflow_buffer =
alloc_bootmem_low_pages(PAGE_ALIGN(io_tlb_overflow));
+ if (!v_overflow_buffer)
+ panic("Cannot allocate SWIOTLB overflow buffer!\n");
+
+ io_tlb_overflow_buffer = __pa(v_overflow_buffer);
+
+ /*
* Allocate and initialize the free list array. This array is used
* to find contiguous free memory regions of size up to IO_TLB_SEGSIZE
*/
@@ -155,12 +165,6 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long
nslabs, int verbose)
io_tlb_index = 0;
io_tlb_orig_addr = alloc_bootmem_pages(PAGE_ALIGN(io_tlb_nslabs *
sizeof(phys_addr_t)));
- /*
-* Get the overflow emergency buffer
-*/
- io_tlb_overflow_buffer =
alloc_bootmem_low_pages(PAGE_ALIGN(io_tlb_overflow));
- if (!io_tlb_overflow_buffer)
- panic("Cannot allocate SWIOTLB overflow buffer!\n");
if (verbose)
swiotlb_print_info();
}
@@ -250,6 +254,7 @@ int
swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
{
unsigned long i, bytes;
+ unsigned char *v_overflow_buffer;
bytes = nslabs << IO_TLB_SHIFT;
@@ -259,13 +264,23 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long
nslabs)
memset(tlb, 0, bytes);
/*
+* Get the overflow emergency buffer
+*/
+ v_overflow_buffer = (void *)__get_free_pages(GFP_DMA,
+
get_order(io_tlb_overflow));
+ if (!v_overflow_buffer)
+ goto cleanup2;
+
+ io_tlb_overflow_buffer = virt_to_phys(v_overflow_buffer);
+
+ /*
* Allocate and initialize the free list array. This array is used
* to find contiguous free memory regions of size up to IO_TLB_SEGSIZE
*/
io_tlb_list = (unsigned int *)__get_free_pages(GFP_KERNEL,
get_order(io_tlb_nslabs * sizeof(int)));
if (!io_tlb_list)
- goto cleanup2;
+ goto cleanup3;
for (i = 0; i < io_tlb_nslabs; i++)
io_tlb_list[i] = IO_TLB_SEGSIZE - OFFSET(i, IO_TLB_SEGSIZE);
@@ -276,18 +291,10 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long
nslabs)
get_order(io_tlb_nslabs *
sizeof(phys_addr_t)));
if (!io_tlb_orig_addr)
- goto cleanup3;
+ goto cleanup4;
memset(io_tlb_orig_addr, 0, io_tlb_nslabs * sizeof(phys_addr_t));
- /*
-* Get the overflow emergency buffer
-*/
- io_tlb_overflow_buffer = (void *)__get_free_pages(GFP_DMA,
- get_order(io_tlb_overflow));
- if (!io_tlb_overflow_buffer)
- goto cleanup4;
-
swiotlb_print_info();
late_alloc = 1;
@@ -295,13 +302,13 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long
nslabs)
return 0;
cleanup4:
- free_pages((unsigned long)io_tlb_orig_addr,
- get_order(io_tlb_nslabs * sizeof(phys_addr_t)));
- io_tlb_orig_addr = NULL;
-cleanup3:
free_pages((unsigned long)io_tlb_list, get_order(io_tlb_nslabs *
sizeof(int)));
io_tlb_list = NULL;
+cleanup3:
+ free_pages((unsigned long)v_overflow_buffer,
+ get_order(io_tlb_overflow));
+ io_tlb_overflow_buffer = 0;
cleanup2:
io_tlb_start = 0;
io_tlb_nslabs = 0;
@@ -310,11 +317,11 @@ cleanup2:
void __init swiotlb_free(void)
{
- if
[RFC PATCH 7/7] swiotlb: Do not export swiotlb_bounce since there are no external consumers
Currently swiotlb is the only consumer for swiotlb_bounce. Since that is the
case it doesn't make much sense to be exporting it so make it a static
function only.
In addition we can save a few more lines of code by making it so that it
accepts the DMA address as a physical address instead of a virtual one. This
is the last piece in essentially pushing all of the DMA address values to use
physical addresses in swiotlb.
Signed-off-by: Alexander Duyck
---
include/linux/swiotlb.h |3 ---
lib/swiotlb.c | 30 +-
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index ba1bd38..8e635d1 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -53,9 +53,6 @@ extern void swiotlb_tbl_sync_single(struct device *hwdev,
enum dma_sync_target target);
/* Accessory functions. */
-extern void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
- enum dma_data_direction dir);
-
extern void
*swiotlb_alloc_coherent(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags);
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 7cfe850..a2ad781 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -351,10 +351,11 @@ static int is_swiotlb_buffer(phys_addr_t paddr)
/*
* Bounce: copy the swiotlb buffer back to the original dma location
*/
-void swiotlb_bounce(phys_addr_t phys, char *dma_addr, size_t size,
- enum dma_data_direction dir)
+static void swiotlb_bounce(phys_addr_t phys, phys_addr_t dma_addr,
+ size_t size, enum dma_data_direction dir)
{
unsigned long pfn = PFN_DOWN(phys);
+ unsigned char *vaddr = phys_to_virt(dma_addr);
if (PageHighMem(pfn_to_page(pfn))) {
/* The buffer does not have a mapping. Map it in and copy */
@@ -369,25 +370,23 @@ void swiotlb_bounce(phys_addr_t phys, char *dma_addr,
size_t size,
local_irq_save(flags);
buffer = kmap_atomic(pfn_to_page(pfn));
if (dir == DMA_TO_DEVICE)
- memcpy(dma_addr, buffer + offset, sz);
+ memcpy(vaddr, buffer + offset, sz);
else
- memcpy(buffer + offset, dma_addr, sz);
+ memcpy(buffer + offset, vaddr, sz);
kunmap_atomic(buffer);
local_irq_restore(flags);
size -= sz;
pfn++;
- dma_addr += sz;
+ vaddr += sz;
offset = 0;
}
+ } else if (dir == DMA_TO_DEVICE) {
+ memcpy(vaddr, phys_to_virt(phys), size);
} else {
- if (dir == DMA_TO_DEVICE)
- memcpy(dma_addr, phys_to_virt(phys), size);
- else
- memcpy(phys_to_virt(phys), dma_addr, size);
+ memcpy(phys_to_virt(phys), vaddr, size);
}
}
-EXPORT_SYMBOL_GPL(swiotlb_bounce);
phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
dma_addr_t tbl_dma_addr,
@@ -489,7 +488,7 @@ found:
for (i = 0; i < nslots; i++)
io_tlb_orig_addr[index+i] = phys + (i << IO_TLB_SHIFT);
if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
- swiotlb_bounce(phys, phys_to_virt(dma_addr), size,
DMA_TO_DEVICE);
+ swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
return dma_addr;
}
@@ -522,8 +521,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev,
phys_addr_t dma_addr,
* First, sync the memory before unmapping the entry
*/
if (phys && ((dir == DMA_FROM_DEVICE) || (dir == DMA_BIDIRECTIONAL)))
- swiotlb_bounce(phys, phys_to_virt(dma_addr),
- size, DMA_FROM_DEVICE);
+ swiotlb_bounce(phys, dma_addr, size, DMA_FROM_DEVICE);
/*
* Return the buffer to the free list by setting the corresponding
@@ -564,15 +562,13 @@ void swiotlb_tbl_sync_single(struct device *hwdev,
phys_addr_t dma_addr,
switch (target) {
case SYNC_FOR_CPU:
if (likely(dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
- swiotlb_bounce(phys, phys_to_virt(dma_addr),
- size, DMA_FROM_DEVICE);
+ swiotlb_bounce(phys, dma_addr, size, DMA_FROM_DEVICE);
else
BUG_ON(dir != DMA_TO_DEVICE);
break;
case SYNC_FOR_DEVICE:
if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
- swiotlb_bounce(phys, phys_to_virt(dma_addr),
-
[RFC PATCH 6/7] swiotlb: Use physical addresses instead of virtual in swiotlb_tbl_sync_single
This change makes it so that the sync functionality also uses physical
addresses. This helps to further reduce the use of virt_to_phys and
phys_to_virt functions.
Signed-off-by: Alexander Duyck
---
drivers/xen/swiotlb-xen.c |3 +--
include/linux/swiotlb.h |3 ++-
lib/swiotlb.c | 18 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 4cedc28..af47e75 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -433,8 +433,7 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t
dev_addr,
/* NOTE: We use dev_addr here, not paddr! */
if (is_xen_swiotlb_buffer(dev_addr)) {
- swiotlb_tbl_sync_single(hwdev, phys_to_virt(paddr), size, dir,
- target);
+ swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
return;
}
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 5a5a654..ba1bd38 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -47,7 +47,8 @@ extern void swiotlb_tbl_unmap_single(struct device *hwdev,
phys_addr_t dma_addr,
size_t size, enum dma_data_direction dir);
-extern void swiotlb_tbl_sync_single(struct device *hwdev, char *dma_addr,
+extern void swiotlb_tbl_sync_single(struct device *hwdev,
+ phys_addr_t dma_addr,
size_t size, enum dma_data_direction dir,
enum dma_sync_target target);
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 41e1d9a..7cfe850 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -552,12 +552,11 @@ void swiotlb_tbl_unmap_single(struct device *hwdev,
phys_addr_t dma_addr,
}
EXPORT_SYMBOL_GPL(swiotlb_tbl_unmap_single);
-void
-swiotlb_tbl_sync_single(struct device *hwdev, char *dma_addr, size_t size,
- enum dma_data_direction dir,
- enum dma_sync_target target)
+void swiotlb_tbl_sync_single(struct device *hwdev, phys_addr_t dma_addr,
+size_t size, enum dma_data_direction dir,
+enum dma_sync_target target)
{
- int index = (dma_addr - (char *)phys_to_virt(io_tlb_start)) >>
IO_TLB_SHIFT;
+ int index = (dma_addr - io_tlb_start) >> IO_TLB_SHIFT;
phys_addr_t phys = io_tlb_orig_addr[index];
phys += ((unsigned long)dma_addr & ((1 << IO_TLB_SHIFT) - 1));
@@ -565,13 +564,15 @@ swiotlb_tbl_sync_single(struct device *hwdev, char
*dma_addr, size_t size,
switch (target) {
case SYNC_FOR_CPU:
if (likely(dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
- swiotlb_bounce(phys, dma_addr, size, DMA_FROM_DEVICE);
+ swiotlb_bounce(phys, phys_to_virt(dma_addr),
+ size, DMA_FROM_DEVICE);
else
BUG_ON(dir != DMA_TO_DEVICE);
break;
case SYNC_FOR_DEVICE:
if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
- swiotlb_bounce(phys, dma_addr, size, DMA_TO_DEVICE);
+ swiotlb_bounce(phys, phys_to_virt(dma_addr),
+ size, DMA_TO_DEVICE);
else
BUG_ON(dir != DMA_FROM_DEVICE);
break;
@@ -780,8 +781,7 @@ swiotlb_sync_single(struct device *hwdev, dma_addr_t
dev_addr,
BUG_ON(dir == DMA_NONE);
if (is_swiotlb_buffer(paddr)) {
- swiotlb_tbl_sync_single(hwdev, phys_to_virt(paddr), size, dir,
- target);
+ swiotlb_tbl_sync_single(hwdev, paddr, size, dir, target);
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/
[RFC PATCH 5/7] swiotlb: Use physical addresses for swiotlb_tbl_unmap_single
This change makes it so that the unmap functionality also uses physical
addresses. This helps to further reduce the use of virt_to_phys and
phys_to_virt functions.
Signed-off-by: Alexander Duyck
---
drivers/xen/swiotlb-xen.c |4 ++--
include/linux/swiotlb.h |3 ++-
lib/swiotlb.c | 35 ++-
3 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 8a6035a..4cedc28 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -364,7 +364,7 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct
page *page,
* Ensure that the address returned is DMA'ble
*/
if (!dma_capable(dev, dev_addr, size)) {
- swiotlb_tbl_unmap_single(dev, phys_to_virt(map), size, dir);
+ swiotlb_tbl_unmap_single(dev, map, size, dir);
dev_addr = 0;
}
return dev_addr;
@@ -388,7 +388,7 @@ static void xen_unmap_single(struct device *hwdev,
dma_addr_t dev_addr,
/* NOTE: We use dev_addr here, not paddr! */
if (is_xen_swiotlb_buffer(dev_addr)) {
- swiotlb_tbl_unmap_single(hwdev, phys_to_virt(paddr), size, dir);
+ swiotlb_tbl_unmap_single(hwdev, paddr, size, dir);
return;
}
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 1995f3e..5a5a654 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -43,7 +43,8 @@ extern phys_addr_t swiotlb_tbl_map_single(struct device
*hwdev,
phys_addr_t phys, size_t size,
enum dma_data_direction dir);
-extern void swiotlb_tbl_unmap_single(struct device *hwdev, char *dma_addr,
+extern void swiotlb_tbl_unmap_single(struct device *hwdev,
+phys_addr_t dma_addr,
size_t size, enum dma_data_direction dir);
extern void swiotlb_tbl_sync_single(struct device *hwdev, char *dma_addr,
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 55e052e..41e1d9a 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -510,20 +510,20 @@ phys_addr_t map_single(struct device *hwdev, phys_addr_t
phys, size_t size,
/*
* dma_addr is the kernel virtual address of the bounce buffer to unmap.
*/
-void
-swiotlb_tbl_unmap_single(struct device *hwdev, char *dma_addr, size_t size,
- enum dma_data_direction dir)
+void swiotlb_tbl_unmap_single(struct device *hwdev, phys_addr_t dma_addr,
+ size_t size, enum dma_data_direction dir)
{
unsigned long flags;
int i, count, nslots = ALIGN(size, 1 << IO_TLB_SHIFT) >> IO_TLB_SHIFT;
- int index = (dma_addr - (char *)phys_to_virt(io_tlb_start)) >>
IO_TLB_SHIFT;
+ int index = (dma_addr - io_tlb_start) >> IO_TLB_SHIFT;
phys_addr_t phys = io_tlb_orig_addr[index];
/*
* First, sync the memory before unmapping the entry
*/
if (phys && ((dir == DMA_FROM_DEVICE) || (dir == DMA_BIDIRECTIONAL)))
- swiotlb_bounce(phys, dma_addr, size, DMA_FROM_DEVICE);
+ swiotlb_bounce(phys, phys_to_virt(dma_addr),
+ size, DMA_FROM_DEVICE);
/*
* Return the buffer to the free list by setting the corresponding
@@ -616,17 +616,18 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size,
ret = phys_to_virt(paddr);
dev_addr = phys_to_dma(hwdev, paddr);
- }
- /* Confirm address can be DMA'd by device */
- if (dev_addr + size - 1 > dma_mask) {
- printk("hwdev DMA mask = 0x%016Lx, dev_addr = 0x%016Lx\n",
- (unsigned long long)dma_mask,
- (unsigned long long)dev_addr);
+ /* Confirm address can be DMA'd by device */
+ if (dev_addr + size - 1 > dma_mask) {
+ printk("hwdev DMA mask = 0x%016Lx, dev_addr =
0x%016Lx\n",
+ (unsigned long long)dma_mask,
+ (unsigned long long)dev_addr);
- /* DMA_TO_DEVICE to avoid memcpy in unmap_single */
- swiotlb_tbl_unmap_single(hwdev, ret, size, DMA_TO_DEVICE);
- return NULL;
+ /* DMA_TO_DEVICE to avoid memcpy in unmap_single */
+ swiotlb_tbl_unmap_single(hwdev, paddr,
+size, DMA_TO_DEVICE);
+ return NULL;
+ }
}
*dma_handle = dev_addr;
@@ -647,7 +648,7 @@ swiotlb_free_coherent(struct device *hwdev, size_t size,
void *vaddr,
free_pages((unsigned long)vaddr, get_order(size));
else
/* DMA_TO_DEVICE to avoid memcpy in swiotlb_tbl_unmap_single */
- swiotlb_tbl_unmap_single(hwdev,
[RFC PATCH 4/7] swiotlb: Return physical addresses when calling swiotlb_tbl_map_single
This change makes it so that swiotlb_tbl_map_single will return a physical
address instead of a virtual address when called. The advantage to this once
again is that we are avoiding a number of virt_to_phys and phys_to_virt
translations by working with everything as a physical address.
One change I had to make in order to support using physical addresses is that
I could no longer trust 0 to be a invalid physical address on all platforms.
So instead I made it so that ~0 is returned on error. This should never be a
valid return value as it implies that only one byte would be available for
use.
Signed-off-by: Alexander Duyck
---
drivers/xen/swiotlb-xen.c | 22 +++---
include/linux/swiotlb.h | 11 +--
lib/swiotlb.c | 73 +++--
3 files changed, 56 insertions(+), 50 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 58db6df..8a6035a 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -338,9 +338,8 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct
page *page,
enum dma_data_direction dir,
struct dma_attrs *attrs)
{
- phys_addr_t phys = page_to_phys(page) + offset;
+ phys_addr_t map, phys = page_to_phys(page) + offset;
dma_addr_t dev_addr = xen_phys_to_bus(phys);
- void *map;
BUG_ON(dir == DMA_NONE);
/*
@@ -356,16 +355,16 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev,
struct page *page,
* Oh well, have to allocate and map a bounce buffer.
*/
map = swiotlb_tbl_map_single(dev, start_dma_addr, phys, size, dir);
- if (!map)
+ if (map == SWIOTLB_MAP_ERROR)
return DMA_ERROR_CODE;
- dev_addr = xen_virt_to_bus(map);
+ dev_addr = xen_phys_to_bus(map);
/*
* Ensure that the address returned is DMA'ble
*/
if (!dma_capable(dev, dev_addr, size)) {
- swiotlb_tbl_unmap_single(dev, map, size, dir);
+ swiotlb_tbl_unmap_single(dev, phys_to_virt(map), size, dir);
dev_addr = 0;
}
return dev_addr;
@@ -494,11 +493,12 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct
scatterlist *sgl,
if (swiotlb_force ||
!dma_capable(hwdev, dev_addr, sg->length) ||
range_straddles_page_boundary(paddr, sg->length)) {
- void *map = swiotlb_tbl_map_single(hwdev,
- start_dma_addr,
- sg_phys(sg),
- sg->length, dir);
- if (!map) {
+ phys_addr_t map = swiotlb_tbl_map_single(hwdev,
+start_dma_addr,
+sg_phys(sg),
+sg->length,
+dir);
+ if (map == SWIOTLB_MAP_ERROR) {
/* Don't panic here, we expect map_sg users
to do proper error handling. */
xen_swiotlb_unmap_sg_attrs(hwdev, sgl, i, dir,
@@ -506,7 +506,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct
scatterlist *sgl,
sgl[0].dma_length = 0;
return DMA_ERROR_CODE;
}
- sg->dma_address = xen_virt_to_bus(map);
+ sg->dma_address = xen_phys_to_bus(map);
} else
sg->dma_address = dev_addr;
sg->dma_length = sg->length;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 8d08b3e..1995f3e 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -34,9 +34,14 @@ enum dma_sync_target {
SYNC_FOR_CPU = 0,
SYNC_FOR_DEVICE = 1,
};
-extern void *swiotlb_tbl_map_single(struct device *hwdev, dma_addr_t
tbl_dma_addr,
- phys_addr_t phys, size_t size,
- enum dma_data_direction dir);
+
+/* define the last possible byte of physical address space as a mapping error
*/
+#define SWIOTLB_MAP_ERROR (~(phys_addr_t)0x0)
+
+extern phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
+ dma_addr_t tbl_dma_addr,
+ phys_addr_t phys, size_t size,
+ enum dma_data_direction dir);
extern void swiotlb_tbl_unmap_single(struct device *hwdev, char *dma_addr,
size_t size, enum dma_data_direction
[RFC PATCH 2/7] swiotlb: Make io_tlb_start a physical address instead of a virtual address
This change makes it so that io_tlb_start contains a physical address instead
of a virtual address. The advantage to this is that we can avoid costly
translations between virtual and physical addresses when comparing the
io_tlb_start against DMA addresses.
Signed-off-by: Alexander Duyck
---
lib/swiotlb.c | 61 +
1 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 5cc4d4e..02abb72 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -57,7 +57,7 @@ int swiotlb_force;
* swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by
this
* API.
*/
-static char *io_tlb_start;
+phys_addr_t io_tlb_start;
/*
* The number of IO TLB blocks (in groups of 64).
@@ -125,14 +125,15 @@ static dma_addr_t swiotlb_virt_to_bus(struct device
*hwdev,
void swiotlb_print_info(void)
{
unsigned long bytes = io_tlb_nslabs << IO_TLB_SHIFT;
- phys_addr_t pstart, pend;
+ unsigned char *vstart, *vend;
- pstart = virt_to_phys(io_tlb_start);
- pend = pstart + bytes;
+ vstart = phys_to_virt(io_tlb_start);
+ vend = vstart + bytes;
printk(KERN_INFO "software IO TLB [mem %#010llx-%#010llx] (%luMB)
mapped at [%p-%p]\n",
- (unsigned long long)pstart, (unsigned long long)pend - 1,
- bytes >> 20, io_tlb_start, io_tlb_start + bytes - 1);
+ (unsigned long long)io_tlb_start,
+ (unsigned long long)io_tlb_start + bytes - 1,
+ bytes >> 20, vstart, vend - 1);
}
void __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
@@ -142,7 +143,7 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long
nslabs, int verbose)
bytes = nslabs << IO_TLB_SHIFT;
io_tlb_nslabs = nslabs;
- io_tlb_start = tlb;
+ io_tlb_start = __pa(tlb);
/*
* Allocate and initialize the free list array. This array is used
@@ -171,6 +172,7 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned long
nslabs, int verbose)
static void __init
swiotlb_init_with_default_size(size_t default_size, int verbose)
{
+ unsigned char *vstart;
unsigned long bytes;
if (!io_tlb_nslabs) {
@@ -183,11 +185,11 @@ swiotlb_init_with_default_size(size_t default_size, int
verbose)
/*
* Get IO TLB memory from the low pages
*/
- io_tlb_start = alloc_bootmem_low_pages(PAGE_ALIGN(bytes));
- if (!io_tlb_start)
+ vstart = alloc_bootmem_low_pages(PAGE_ALIGN(bytes));
+ if (!vstart)
panic("Cannot allocate SWIOTLB buffer");
- swiotlb_init_with_tbl(io_tlb_start, io_tlb_nslabs, verbose);
+ swiotlb_init_with_tbl(vstart, io_tlb_nslabs, verbose);
}
void __init
@@ -205,6 +207,7 @@ int
swiotlb_late_init_with_default_size(size_t default_size)
{
unsigned long bytes, req_nslabs = io_tlb_nslabs;
+ unsigned char *vstart = NULL;
unsigned int order;
int rc = 0;
@@ -221,14 +224,14 @@ swiotlb_late_init_with_default_size(size_t default_size)
bytes = io_tlb_nslabs << IO_TLB_SHIFT;
while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
- io_tlb_start = (void *)__get_free_pages(GFP_DMA | __GFP_NOWARN,
- order);
- if (io_tlb_start)
+ vstart = (void *)__get_free_pages(GFP_DMA | __GFP_NOWARN,
+ order);
+ if (vstart)
break;
order--;
}
- if (!io_tlb_start) {
+ if (!vstart) {
io_tlb_nslabs = req_nslabs;
return -ENOMEM;
}
@@ -237,9 +240,9 @@ swiotlb_late_init_with_default_size(size_t default_size)
"for software IO TLB\n", (PAGE_SIZE << order) >> 20);
io_tlb_nslabs = SLABS_PER_PAGE << order;
}
- rc = swiotlb_late_init_with_tbl(io_tlb_start, io_tlb_nslabs);
+ rc = swiotlb_late_init_with_tbl(vstart, io_tlb_nslabs);
if (rc)
- free_pages((unsigned long)io_tlb_start, order);
+ free_pages((unsigned long)vstart, order);
return rc;
}
@@ -251,9 +254,9 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
bytes = nslabs << IO_TLB_SHIFT;
io_tlb_nslabs = nslabs;
- io_tlb_start = tlb;
+ io_tlb_start = virt_to_phys(tlb);
- memset(io_tlb_start, 0, bytes);
+ memset(tlb, 0, bytes);
/*
* Allocate and initialize the free list array. This array is used
@@ -300,7 +303,7 @@ cleanup3:
sizeof(int)));
io_tlb_list = NULL;
cleanup2:
- io_tlb_start = NULL;
+ io_tlb_start = 0;
io_tlb_nslabs = 0;
return -ENOMEM;
}
@@ -317,7 +320,7 @@ void __init swiotlb_free(void)
[RFC PATCH 1/7] swiotlb: Instead of tracking the end of the swiotlb region just calculate it
In the case of swiotlb we already have the start of the region and the number
of slabs that give us the region size. Instead of having to call
virt_to_phys on two pointers we can just take advantage of the fact that the
region is linear and just compute the end based on the start plus the size.
Signed-off-by: Alexander Duyck
---
lib/swiotlb.c | 25 -
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index f114bf6..5cc4d4e 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -57,11 +57,11 @@ int swiotlb_force;
* swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by
this
* API.
*/
-static char *io_tlb_start, *io_tlb_end;
+static char *io_tlb_start;
/*
- * The number of IO TLB blocks (in groups of 64) between io_tlb_start and
- * io_tlb_end. This is command line adjustable via setup_io_tlb_npages.
+ * The number of IO TLB blocks (in groups of 64).
+ * This is command line adjustable via setup_io_tlb_npages.
*/
static unsigned long io_tlb_nslabs;
@@ -128,11 +128,11 @@ void swiotlb_print_info(void)
phys_addr_t pstart, pend;
pstart = virt_to_phys(io_tlb_start);
- pend = virt_to_phys(io_tlb_end);
+ pend = pstart + bytes;
printk(KERN_INFO "software IO TLB [mem %#010llx-%#010llx] (%luMB)
mapped at [%p-%p]\n",
(unsigned long long)pstart, (unsigned long long)pend - 1,
- bytes >> 20, io_tlb_start, io_tlb_end - 1);
+ bytes >> 20, io_tlb_start, io_tlb_start + bytes - 1);
}
void __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
@@ -143,12 +143,10 @@ void __init swiotlb_init_with_tbl(char *tlb, unsigned
long nslabs, int verbose)
io_tlb_nslabs = nslabs;
io_tlb_start = tlb;
- io_tlb_end = io_tlb_start + bytes;
/*
* Allocate and initialize the free list array. This array is used
* to find contiguous free memory regions of size up to IO_TLB_SEGSIZE
-* between io_tlb_start and io_tlb_end.
*/
io_tlb_list = alloc_bootmem_pages(PAGE_ALIGN(io_tlb_nslabs *
sizeof(int)));
for (i = 0; i < io_tlb_nslabs; i++)
@@ -254,14 +252,12 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long
nslabs)
io_tlb_nslabs = nslabs;
io_tlb_start = tlb;
- io_tlb_end = io_tlb_start + bytes;
memset(io_tlb_start, 0, bytes);
/*
* Allocate and initialize the free list array. This array is used
* to find contiguous free memory regions of size up to IO_TLB_SEGSIZE
-* between io_tlb_start and io_tlb_end.
*/
io_tlb_list = (unsigned int *)__get_free_pages(GFP_KERNEL,
get_order(io_tlb_nslabs * sizeof(int)));
@@ -304,7 +300,6 @@ cleanup3:
sizeof(int)));
io_tlb_list = NULL;
cleanup2:
- io_tlb_end = NULL;
io_tlb_start = NULL;
io_tlb_nslabs = 0;
return -ENOMEM;
@@ -339,8 +334,10 @@ void __init swiotlb_free(void)
static int is_swiotlb_buffer(phys_addr_t paddr)
{
- return paddr >= virt_to_phys(io_tlb_start) &&
- paddr < virt_to_phys(io_tlb_end);
+ phys_addr_t swiotlb_start = virt_to_phys(io_tlb_start);
+
+ return paddr >= swiotlb_start &&
+ paddr < (swiotlb_start + (io_tlb_nslabs << IO_TLB_SHIFT));
}
/*
@@ -938,6 +935,8 @@ EXPORT_SYMBOL(swiotlb_dma_mapping_error);
int
swiotlb_dma_supported(struct device *hwdev, u64 mask)
{
- return swiotlb_virt_to_bus(hwdev, io_tlb_end - 1) <= mask;
+ unsigned long bytes = io_tlb_nslabs << IO_TLB_SHIFT;
+
+ return swiotlb_virt_to_bus(hwdev, io_tlb_start + bytes - 1) <= mask;
}
EXPORT_SYMBOL(swiotlb_dma_supported);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/7] Improve swiotlb performance by using physical addresses
While working on 10Gb/s routing performance I found a significant amount of time was being spent in the swiotlb DMA handler. Further digging found that a significant amount of this was due to the fact that virtual to physical address translation and calling the function that did it. It accounted for nearly 60% of the total overhead. This patch set works to resolve that by changing the io_tlb_start address and io_tlb_overflow_buffer address from virtual addresses to physical addresses. By doing this, devices that are not making use of bounce buffers can significantly reduce their overhead. In addition I followed through with the cleanup to the point that the only functions that really require the virtual address for the dma buffer are the init, free, and bounce functions. When running a routing throughput test using small packets I saw roughly a 5% increase in packets rates after applying these patches. This appears to match up with the CPU overhead reduction I was tracking via perf. Before: Results 10.29Mps # Overhead Symbol # ... # 1.97% [k] __phys_addr | |--24.97%-- swiotlb_sync_single | |--16.55%-- is_swiotlb_buffer | |--11.25%-- unmap_single | --2.71%-- swiotlb_dma_mapping_error 1.66% [k] swiotlb_sync_single 1.45% [k] is_swiotlb_buffer 0.53% [k] unmap_single 0.52% [k] swiotlb_map_page 0.47% [k] swiotlb_sync_single_for_device 0.43% [k] swiotlb_sync_single_for_cpu 0.42% [k] swiotlb_dma_mapping_error 0.34% [k] swiotlb_unmap_page After: Results 10.99Mps # Overhead Symbol # ... # 0.50% [k] swiotlb_map_page 0.50% [k] swiotlb_sync_single 0.36% [k] swiotlb_sync_single_for_cpu 0.35% [k] swiotlb_sync_single_for_device 0.25% [k] swiotlb_unmap_page 0.17% [k] swiotlb_dma_mapping_error --- Alexander Duyck (7): swiotlb: Do not export swiotlb_bounce since there are no external consumers swiotlb: Use physical addresses instead of virtual in swiotlb_tbl_sync_single swiotlb: Use physical addresses for swiotlb_tbl_unmap_single swiotlb: Return physical addresses when calling swiotlb_tbl_map_single swiotlb: Make io_tlb_overflow_buffer a physical address swiotlb: Make io_tlb_start a physical address instead of a virtual address swiotlb: Instead of tracking the end of the swiotlb region just calculate it drivers/xen/swiotlb-xen.c | 25 ++--- include/linux/swiotlb.h | 20 ++-- lib/swiotlb.c | 247 +++-- 3 files changed, 150 insertions(+), 142 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 mips tree with Linus' tree
Hi Ralf,
Today's linux-next merge of the mips tree got a conflict in
arch/mips/include/asm/octeon/octeon-model.h between commit a1ce39288e6f
("UAPI: (Scripted) Convert #include "..." to #include in
kernel system headers") from the tree and commit 5cf02e5554a4 ("MIPS:
OCTEON: Add detection of cnf71xx parts") from the mips 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/mips/include/asm/octeon/octeon-model.h
index 23b895c,93398f6..000
--- a/arch/mips/include/asm/octeon/octeon-model.h
+++ b/arch/mips/include/asm/octeon/octeon-model.h
@@@ -313,6 -323,14 +323,14 @@@ static inline int __octeon_is_model_run
const char *octeon_model_get_string(uint32_t chip_id);
const char *octeon_model_get_string_buffer(uint32_t chip_id, char *buffer);
+ /*
+ * Return the octeon family, i.e., ProcessorID of the PrID register.
+ */
+ static inline uint32_t cvmx_get_octeon_family(void)
+ {
+ return cvmx_get_proc_id() & OCTEON_FAMILY_MASK;
+ }
+
-#include "octeon-feature.h"
+#include
#endif /* __OCTEON_MODEL_H__ */
pgpZJttsny7oY.pgp
Description: PGP signature
Re: [PATCH 7/10] compiler{,-gcc4}.h: Introduce __flatten function attribute
On Wed, 2012-10-03 at 08:38 -0700, Joe Perches wrote: > On Wed, 2012-10-03 at 11:14 -0400, Steven Rostedt wrote: > > I first check > > the MAINTAINERS file. If the subsystem I'm working on exists there, I > > only email those that are listed there, including any mailing lists that > > are mentioned (as well as LKML). If it's not listed, I then do a git log > > and see who does the most sign offs to changes there, and to what kind > > of changes. I usually ignore the trivial stuff. > > Funny because that's what the script does too. > Really? It ignores the trivial stuff and only adds people that seem to actually do real work on the file? If that's the case, I doubt that it would have caused the huge Cc list that Daniel sent out. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] MAINTAINERS: Add maintainer entry for the USB webcam gadget
Signed-off-by: Laurent Pinchart --- MAINTAINERS |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d919e3d..b118b23 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7392,6 +7392,13 @@ S: Maintained F: Documentation/video4linux/w9968cf.txt F: drivers/media/video/w996* +USB WEBCAM GADGET +M: Laurent Pinchart +L: linux-...@vger.kernel.org +S: Maintained +F: drivers/usb/gadget/*uvc*.c +F: drivers/usb/gadget/webcam.c + USB WIRELESS RNDIS DRIVER (rndis_wlan) M: Jussi Kivilinna L: linux-wirel...@vger.kernel.org -- 1.7.8.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] usb: gadget: Make webcam gadget select USB_LIBCOMPOSITE
Composite gadget support is now available as a library instead of being built with each gadget. Composite drivers need to select USB_LIBCOMPOSITE. Signed-off-by: Laurent Pinchart --- drivers/usb/gadget/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index dfb51a4..e0ff51b 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -952,6 +952,7 @@ endif config USB_G_WEBCAM tristate "USB Webcam Gadget" depends on VIDEO_DEV + select USB_LIBCOMPOSITE help The Webcam Gadget acts as a composite USB Audio and Video Class device. It provides a userspace API to process UVC control requests -- 1.7.8.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] USB webcam gadget driver fix for linux-next
Hi, The first patch in this series should fix the UVC gadget compilation errors in linux-next. The second patch should make sure I'll be notified next time a patch tries to break it :-) Both patches are based on Linus' tree. Laurent Pinchart (2): usb: gadget: Make webcam gadget select USB_LIBCOMPOSITE MAINTAINERS: Add maintainer entry for the USB webcam gadget MAINTAINERS|7 +++ drivers/usb/gadget/Kconfig |1 + 2 files changed, 8 insertions(+), 0 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/10] bug.h: Replace __linktime_error with __compiletime_error
On 10/03/2012 01:26 PM, David Rientjes wrote: > On Wed, 3 Oct 2012, Daniel Santos wrote: > >> Thanks. I've actually just reversed the patch order per Josh's >> suggestion and added patch comments to it. I can squash them if you >> guys prefer. >> > No need to be so fine-grained in your patches, if you're trying to replace > __linktime_error with __compiletime_error, which happens to be the title > of the patch (and should remain the title), then just remove it's single > occurrence and its definition at the same time with a clear changelog that > __compiletime_error is sufficient. No need to have two small patches with > the same motivation. Sounds good to me > >> Unfortunately, I'm a bit confused as to how I should re-submit these, >> still being new to this project. Patch 1 is already in -mm. Patches 2-3 >> have not changed. I've made a correction to patch #4 and reversed the >> order of 5 & 6. And what was 8-10 is now 8-15, as I've completely >> re-done BUILD_BUG_ON. I was planning on just submitting the whole set >> again, is this the correct protocol? If so, should I reply to the >> original [PATCH 0/10] thread or create a new one? >> > You already have a patch in -mm, so you have to base your series on that > tree. Get the latest -mm tree from http://www.ozlabs.org/~akpm/mmotm/ and > base the revised series on that tree, then send it off to > Andrew Morton and cc the list and your > reviewers. People often find it helpful to make it clear that this is v2 > of the patchset and that it's based on -mm as a helpful pointer. I have it checked out from git://git.cmpxchg.org/linux-mmotm.git, the problem is that I cannot correctly test against that right now because I get an oops (without my patches) when setting up LVM (same on -next, bug report here https://bugzilla.kernel.org/show_bug.cgi?id=48241). What I'm thinking about doing is to rebase them against v3.6 again and test them there, but it will require a few minor changes (due to walken's patches not being present). Still, it's better than no re-testing. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] nfsd crashing with 3.6.0-rc7 on PowerPC
Hi, > Yes. With that patch applied, things work for me again. Thanks Alex, Nish. We can reproduce this on one of our Biminis, looking into it now. Anton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 net tree
Hi all,
After merging the net tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: In function 't4_memory_rw':
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:420:2: error: implicit declaration
of function 'vmalloc' [-Werror=implicit-function-declaration]
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:420:7: warning: assignment makes
pointer from integer without a cast [enabled by default]
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:487:2: error: implicit declaration
of function 'vfree' [-Werror=implicit-function-declaration]
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: In function 'get_vpd_params':
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c:530:6: warning: assignment makes
pointer from integer without a cast [enabled by default]
Caused by commit 8c357ebd5693 ("cxgb4: Dynamically allocate memory in
t4_memory_rw() and get_vpd_params()"). Missing include of
linux/vmalloc.h.
I have used the net tree from next-20121003 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpscLnyQrLjq.pgp
Description: PGP signature
Re: [PATCH v5 2/2] hwmon: (ads7828) add support for ADS7830
Thanks a lot Guenter! Thanks a lot Vivien also for the help. Guillaume - Mail original - De: "Guenter Roeck" À: "Vivien Didelot" Cc: lm-sens...@lm-sensors.org, "Guillaume Roguez" , "Jean Delvare" , linux-kernel@vger.kernel.org, "Steve Hardy" Envoyé: Mercredi 3 Octobre 2012 19:37:58 Objet: Re: [PATCH v5 2/2] hwmon: (ads7828) add support for ADS7830 On Wed, Oct 03, 2012 at 04:54:08PM -0400, Vivien Didelot wrote: > From: Guillaume Roguez > > The ADS7830 device is almost the same as the ADS7828, > except that it does 8-bit sampling, instead of 12-bit. > This patch extends the ads7828 driver to support this chip. > > Signed-off-by: Guillaume Roguez > Signed-off-by: Vivien Didelot Applied to -next. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] make CONFIG_EXPERIMENTAL invisible and default
On Wed, Oct 03, 2012 at 03:23:27PM -0700, Eric W. Biederman wrote: > "Paul E. McKenney" writes: > > > On Wed, Oct 03, 2012 at 11:43:32AM -0700, Kees Cook wrote: > >> On Wed, Oct 3, 2012 at 9:47 AM, Paul E. McKenney > >> wrote: > >> > On Wed, Oct 03, 2012 at 09:17:02AM -0700, Greg Kroah-Hartman wrote: > >> >> On Wed, Oct 03, 2012 at 06:25:38AM -0700, Paul E. McKenney wrote: > >> >> > On Tue, Oct 02, 2012 at 12:50:42PM -0700, Kees Cook wrote: > >> >> > > This config item has not carried much meaning for a while now and is > >> >> > > almost always enabled by default. As agreed during the Linux kernel > >> >> > > summit, it should be removed. As a first step, remove it from being > >> >> > > listed, and default it to on. Once it has been removed from all > >> >> > > subsystem Kconfigs, it will be dropped entirely. > >> >> > > > >> >> > > CC: Greg KH > >> >> > > CC: "Eric W. Biederman" > >> >> > > CC: Serge Hallyn > >> >> > > CC: "Paul E. McKenney" > >> >> > > CC: Andrew Morton > >> >> > > CC: Frederic Weisbecker > >> >> > > Signed-off-by: Kees Cook > >> >> > > --- > >> >> > > > >> >> > > This is the first of a series of 202 patches removing EXPERIMENTAL > >> >> > > from > >> >> > > all the Kconfigs in the tree. Should I send them all to lkml (with > >> >> > > all > >> >> > > the associated CCs), or do people want to cherry-pick changes from > >> >> > > my > >> >> > > tree? I don't want to needlessly flood the list. > >> >> > > > >> >> > > http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/experimental > >> >> > > > >> >> > > I figure this patch can stand alone to at least make EXPERIMENTAL go > >> >> > > away from the menus, and give us a taste of what the removal would > >> >> > > do > >> >> > > to builds. > >> >> > > >> >> > OK, I will bite... How should I flag an option that is initially only > >> >> > intended for those willing to take some level of risk? > >> >> > >> >> In the text say "You really don't want to enable this option, use at > >> >> your own risk!" Or something like that :) > >> > > >> > OK, so the only real hope for experimental features is to refrain from > >> > creating a config option for them, so that people wishing to use them > >> > must modify the code? Or is the philosophy that we keep things out of > >> > tree until we are comfortable with distros turning them on? > >> > >> I would expect a simple addition of "this is dangerous/buggy" to the > >> description and "default n" is likely the way to go for that kind of > >> thing. I think the history of CONFIG_EXPERIMENTAL has proven there > >> isn't a sensible way to create a global flag for this kind of thing. > >> To paraphrase Serge: my experimental options are not your experimental > >> options. > > > > That has not proven sufficient for me in the past, RCU_FAST_NO_HZ > > being a case in point. > > One option that does work is to add a negative Kconfig dependency such > as "depends on EXT4 = n". Where what you depend on is something that > distros want. > > Where I had a legitimate reason to do that with the user namespace > (aka the code that had not been converted did not compile and was not > safe to use) it worked very well in keeping distros from getting ahead > of them selves, and likewise it works very well for ensuring it got > itself removed as ultimately you want to the two kconfig options to work > together. Cute! ;-) > >> For example, some of the things that already had the experimental > >> config removed, they left the "(EXPERIMENTAL)" in their config title. > > > > Or I could just make it splat at boot time. ;-) > > Yes. Treating a truly experimental feature like a deprecated feature > and complaining to the world also seems reasonable, and it seems like > something that would ultimatley get removed as well. Either removed or fixed, as the case may be. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [GIT PULL] xtensa patchset for 3.7
On Thu, Oct 4, 2012 at 3:48 AM, Al Viro wrote: > On Wed, Oct 03, 2012 at 03:23:56PM -0700, Chris Zankel wrote: >> Hi Linus, >> >> Please pull the changes for the Xtensa architecture for v3.7. >> >> Thanks, >> -Chris > > BTW, could you do an xtensa counterpart of the stuff in > git.kernel.org/pub/scm/linux/kernel/git/viro/signal#experimental-kernel_thread? I will try to do it, thanks for the outline. > Basically, > * switch kernel_thread() away from "syscall in kernel" model; > select GENERIC_KERNEL_THREAD in Kconfig and have copy_thread() check > p->flags & PF_KTHREAD instead of user_mode(regs). If it's true, set the > child up so that it would wake up not in ret_from_fork() but in > ret_from_kernel_thread(), the latter being > schedule_tail(last); > fn(arg); > sys_exit(0); > where fn and arg would be picked from something set by copy_thread() - either > pt_regs or callee-saved registers if your switch_to() deals with those (in > the latter case you'll obviously have then already in place by the time your > newborn kernel thread wakes up). Have the same value for kernel stack pointer > regardless of user_mode. Use 'usp' for fn, 'unused' for arg and expect regs > to be NULL. Kill kernel_thread() in entry.S. > * add ret_from_kernel_execve() that would simply set sp to value > normal for common_exception_return (i.e. what you used to set it when > going into ret_from_kernel_thread()/ret_from_fork()) and branch to said > common_exception_return(). Define __ARCH_WANT_KERNEL_EXECVE in unistd.h > and kill kernel_execve() in entry.S. ret_from_kernel_execve() will get as > its argument task_pt_regs(current), which often spares us some calculations. > * define __ARCH_WANT_SYS_EXECVE in unistd.h, kill xtensa_execve(); > just use sys_execve instead. > * as an optimization, define current_pt_regs() as > (struct pt_regs *)((unsigned long)current_thread_info() + > KERNEL_STACK_SIZE - (XCHAL_NUM_AREGS-16)*4) - 1). I.e. an equivalent of > task_pt_regs(current) without useless work - task_stack_page(current) is > expanded to task_stack_page(current_thread_info()->task), which is > equal to current_thread_info()... > > That would probably allow more glue removal - no more syscalls from the > kernel, for one thing. For another, xtensa_clone() won't need to locate > struct pt_regs * - current_pt_regs() would work just as well and be faster > anyway. The same goes for xtensa_rt_sigreturn() and xtensa_sigaltstack()... -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] target/file: Re-enable optional fd_buffered_io=1 operation
On Wed, 2012-10-03 at 07:47 -0400, Christoph Hellwig wrote: > On Tue, Oct 02, 2012 at 01:16:44PM -0700, Nicholas A. Bellinger wrote: > > * Optionally allow fd_buffered_io=1 to be enabled for people > > * who want use the fs buffer cache as an WriteCache mechanism. > > * > > * This means that in event of a hard failure, there is a risk > > * of silent data-loss if the SCSI client has *not* performed a > > * forced unit access (FUA) write, or issued SYNCHRONIZE_CACHE > > * to write-out the entire device cache. > > */ > > Oh, I get Vlads flame. This doesn't simply disable O_DSYNC now but also > sets WCE=1. In this case I don't really get the point of the patch, why > can't we simply set it from configfs? > The patch prevents existing user-space code from using fd_buffered_io=1 operation incorrectly regardless of what is being set for emulate_write_cache device attribute. Using FILEIO w/o O_DSYNC + emulate_write_cache=0 is certainly a big no-no regardless of context, so I'd rather enforce the right thing to do here from kernel code for this special case instead of allowing an unsafe mode to be enabled by default + set attributes from user-space. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3.6
On Thu, Oct 04, 2012 at 12:23:41AM +0200, Matthias Schniedermeyer wrote: > Personally i would have been bitten by this change, because for years i > have used a symlink in /tmp (which has the sticky bit) to a directory > somewhere else for historical reasons. But as i was aware of this change > i fixed my system before booting the new kernel. As long as you own the symlink, it wouldn't be a problem. The problem comes when the symlink is owned by some user such as "untrusted_daemon", which could change where the symlink could point at any any time --- or could create a new symlink where none had previously existed in some world-writeable directory such as /tmp. Now you try to use that symlink, assuming that it points to *foo*, when in fact it now points to *bar*, and hilarity ensues... - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC] function probe_roms accessing improper addresses on UEFI systems
The code in function probe_roms accesses the legacy adapter space (in
the physical address range 640k-1mb) without regard to how this range is
described in the memory map. The assumption in the code is that the
result of an access to unpopulated space is a soft fail, returning -1.
This assumption is not universally true; some systems may cause a hard
error (MCE) when accessing an unpopulated physical address.
The following proposed patch takes advantage of the fact that on EFI
systems, the memory map provides a better description of the physical
space than on pre-EFI legacy systems. If the efi_enabled state variable
indicates the kernel is running on an UEFI system, the patch will use
information from the UEFI memory map so as not to access addresses that
should avoided according to the UEFI specification.
See also a discussion underway in the context of a patch to devmem_is_allowed
https://lkml.org/lkml/2012/10/2/458
which has the same overall goal of restricting access to
inappropriate ranges of the EFI memory map.
Following is my proposed patch based on v3.6. I would appreciate input
on the following points.
1. Is the implementation properly interpreting the UEFI specification by
disallowing probes of addresses for which the type is EFI_RESERVED_TYPE,
EFI_UNUSABLE_MEMORY, or otherwise unknown?
2. The patch includes some simple test cases in function test_probes
that can be customized to the testing needs of a particular target
system. This test code is conditionally enabled based on the
pre-processor symbol DO_TEST_PROBES; if that is not defined, the body of
function test_probes() is empty. This code can be enabled and modified
as needed to test specific addresses of interest. Is this code useful
to include in an upstream patch? If not, is there a more generally
useful testing strategy?
Please CC me directly with comments or questions.
Signed-off-by: Randy Wright
---
arch/x86/kernel/probe_roms.c | 71 ++
1 file changed, 71 insertions(+)
diff --git a/arch/x86/kernel/probe_roms.c b/arch/x86/kernel/probe_roms.c
index d5f15c3..76c20c9 100644
--- a/arch/x86/kernel/probe_roms.c
+++ b/arch/x86/kernel/probe_roms.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include /* efi_enabled, efi_mem_type */
#include
#include
@@ -177,11 +178,46 @@ EXPORT_SYMBOL(pci_biosrom_size);
#define ROMSIGNATURE 0xaa55
+/*
+ * efi_paddr_valid returns 1 if the input physical address
+ * is valid in the efi memory map, 0 otherwise.
+ */
+static int __init efi_paddr_valid(phys_addr_t paddr)
+{
+ u32 type = efi_mem_type((unsigned long)paddr);
+ printk(KERN_DEBUG "efi_paddr_valid(0x%lx): type 0x%lx\n",
+ (unsigned long)paddr, (unsigned long)type);
+ if (type == EFI_RESERVED_TYPE
+ || type == EFI_UNUSABLE_MEMORY
+ || type >= EFI_MAX_MEMORY_TYPE)
+ return 0;
+ return 1;
+}
+
+/*
+ * efi_vaddr_valid translates itsinput va to a pa, then
+ * returns the result of efi_paddr_valid applied to that pa.
+ */
+
+static int __init efi_vaddr_valid(const unsigned char *vaddr)
+{
+ phys_addr_t paddr = virt_to_phys((volatile void *)vaddr);
+ return efi_paddr_valid(paddr);
+}
+
static int __init romsignature(const unsigned char *rom)
{
const unsigned short * const ptr = (const unsigned short *)rom;
unsigned short sig;
+ if (efi_enabled) {
+ int rv = efi_vaddr_valid(rom);
+ printk(KERN_DEBUG
+ "romsignature: efi_vaddr_valid(0x%llx) returned %d\n",
+(unsigned long long)rom, rv);
+ if (0 == rv)
+ return 0;
+ }
return probe_kernel_address(ptr, sig) == 0 && sig == ROMSIGNATURE;
}
@@ -194,6 +230,39 @@ static int __init romchecksum(const unsigned char *rom,
unsigned long length)
return !length && !sum;
}
+/* #define DO_TEST_PROBES "include customizable test code" */
+static void __init test_probes(void)
+{
+#ifdef DO_TEST_PROBES
+ static struct {
+ phys_addr_t paddr;
+ int ptype;
+ } plist[] = {
+ {0x3e76ULL, 0}, /* RESERVED */
+ {0x009ffda9f000ULL, 1}, /* LOADER CODE */
+ {0x0005e000ULL, 2}, /* LOADER DATA */
+ {0x0006ULL, 3}, /* BOOT CODE (why after EBS?) */
+ {0x3640ULL, 4}, /* BOOT DATA (why after EBS?) */
+ {0x009fffc96000ULL, 5}, /* RUNTIME CODE */
+ {0x009fffcd3000ULL, 6}, /* RUNTIME DATA */
+ {0x1000ULL, 7}, /* CONVENTIONAL MEM */
+ {0x3e75f000ULL, 9}, /* ACPI RECLAIM */
+ {0x0008c000ULL, 10},/* ACPI NVS */
+
Re: [GIT PULL] xtensa patchset for 3.7
On Wed, Oct 03, 2012 at 03:23:56PM -0700, Chris Zankel wrote: > Hi Linus, > > Please pull the changes for the Xtensa architecture for v3.7. > > Thanks, > -Chris BTW, could you do an xtensa counterpart of the stuff in git.kernel.org/pub/scm/linux/kernel/git/viro/signal#experimental-kernel_thread? Basically, * switch kernel_thread() away from "syscall in kernel" model; select GENERIC_KERNEL_THREAD in Kconfig and have copy_thread() check p->flags & PF_KTHREAD instead of user_mode(regs). If it's true, set the child up so that it would wake up not in ret_from_fork() but in ret_from_kernel_thread(), the latter being schedule_tail(last); fn(arg); sys_exit(0); where fn and arg would be picked from something set by copy_thread() - either pt_regs or callee-saved registers if your switch_to() deals with those (in the latter case you'll obviously have then already in place by the time your newborn kernel thread wakes up). Have the same value for kernel stack pointer regardless of user_mode. Use 'usp' for fn, 'unused' for arg and expect regs to be NULL. Kill kernel_thread() in entry.S. * add ret_from_kernel_execve() that would simply set sp to value normal for common_exception_return (i.e. what you used to set it when going into ret_from_kernel_thread()/ret_from_fork()) and branch to said common_exception_return(). Define __ARCH_WANT_KERNEL_EXECVE in unistd.h and kill kernel_execve() in entry.S. ret_from_kernel_execve() will get as its argument task_pt_regs(current), which often spares us some calculations. * define __ARCH_WANT_SYS_EXECVE in unistd.h, kill xtensa_execve(); just use sys_execve instead. * as an optimization, define current_pt_regs() as (struct pt_regs *)((unsigned long)current_thread_info() + KERNEL_STACK_SIZE - (XCHAL_NUM_AREGS-16)*4) - 1). I.e. an equivalent of task_pt_regs(current) without useless work - task_stack_page(current) is expanded to task_stack_page(current_thread_info()->task), which is equal to current_thread_info()... That would probably allow more glue removal - no more syscalls from the kernel, for one thing. For another, xtensa_clone() won't need to locate struct pt_regs * - current_pt_regs() would work just as well and be faster anyway. The same goes for xtensa_rt_sigreturn() and xtensa_sigaltstack()... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [GIT PULL] user namespace compile fix for 3.7
Greg Kroah-Hartman writes: > On Wed, Oct 03, 2012 at 04:03:54PM -0700, Eric W. Biederman wrote: >> >> Linus, >> >> Please pull the for-linus git tree from: >> >> >> git://git.kernel.org:/pub/scm/linux/kernel/git/ebiederm/user-namespace.git >> for-linus >> >>HEAD: 702e490211b2b7e448ebe1b3a07d97ad2fc07e03 userns: Fix build of >> drivers/staging/dgrp >> >> This tree contains a trivial build fix for one of the staging drivers >> when user namespace support is enabled. > > Is this something new? Why didn't it show up in the linux-next builds? Yes this appears to have been a silent merge conflict between my user namespace tree and your staging tree. I care because it breaks my builds. This build failure only shows up when CONFIG_USER_NS is enabled which would have required a randconfig build in linux-next for it to show up. When I get the last of the filesystems converted for 3.8 this kind of failure should stop hiding in the more customary build checks. > I'll be glad to take this single patch myself and queue it up with other > staging tree fixes before 3.7-final is out, what is the big rush? I figured I found it, I fixed it, and I am going to be carrying the fix anyway in my tree, so why not make it easy on everyone and make it a patch that can be pulled. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 2/2] hwmon: (ads7828) add support for ADS7830
On Wed, Oct 03, 2012 at 04:54:08PM -0400, Vivien Didelot wrote: > From: Guillaume Roguez > > The ADS7830 device is almost the same as the ADS7828, > except that it does 8-bit sampling, instead of 12-bit. > This patch extends the ads7828 driver to support this chip. > > Signed-off-by: Guillaume Roguez > Signed-off-by: Vivien Didelot Applied to -next. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 1/2] hwmon: (ads7828) driver cleanup
On Wed, Oct 03, 2012 at 04:54:07PM -0400, Vivien Didelot wrote: > As there is no reliable way to identify the chip, it is preferable to > remove the detect callback, to avoid misdetection. > > Module parameters are not worth it here, so let's get rid of them and > add an ads7828_platform_data structure instead. > > Clean the code by removing unused macros, fixing coding style issues, > avoiding function prototypes and using convenient macros such as > module_i2c_driver(). > > Signed-off-by: Vivien Didelot Applied to -next. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: make CONFIG_EXPERIMENTAL invisible and default
On Wed, Oct 03, 2012 at 04:33:21PM -0700, Kees Cook wrote: > On Wed, Oct 3, 2012 at 4:29 PM, Guenter Roeck wrote: > > On Tue, Oct 02, 2012 at 07:50:42PM -, Kees Cook wrote: > >> This config item has not carried much meaning for a while now and is > >> almost always enabled by default. As agreed during the Linux kernel > >> summit, it should be removed. As a first step, remove it from being > >> listed, and default it to on. Once it has been removed from all > >> subsystem Kconfigs, it will be dropped entirely. > >> > >> CC: Greg KH > >> CC: "Eric W. Biederman" > >> CC: Serge Hallyn > >> CC: "Paul E. McKenney" > >> CC: Andrew Morton > >> CC: Frederic Weisbecker > >> Signed-off-by: Kees Cook > >> Acked-by: Serge Hallyn > >> > >> --- > >> This is the first of a series of 202 patches removing EXPERIMENTAL from > >> all the Kconfigs in the tree. Should I send them all to lkml (with all > >> the associated CCs), or do people want to cherry-pick changes from my > >> tree? I don't want to needlessly flood the list. > >> > >> http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/experimental > >> > > I cherry-picked the hwmon/pmbus patch (commit 41c5b6bb). > > Great, thanks! > I also picked the Documentation/hwmon patch (fbe3d657620). Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: make CONFIG_EXPERIMENTAL invisible and default
On Wed, Oct 3, 2012 at 4:29 PM, Guenter Roeck wrote: > On Tue, Oct 02, 2012 at 07:50:42PM -, Kees Cook wrote: >> This config item has not carried much meaning for a while now and is >> almost always enabled by default. As agreed during the Linux kernel >> summit, it should be removed. As a first step, remove it from being >> listed, and default it to on. Once it has been removed from all >> subsystem Kconfigs, it will be dropped entirely. >> >> CC: Greg KH >> CC: "Eric W. Biederman" >> CC: Serge Hallyn >> CC: "Paul E. McKenney" >> CC: Andrew Morton >> CC: Frederic Weisbecker >> Signed-off-by: Kees Cook >> Acked-by: Serge Hallyn >> >> --- >> This is the first of a series of 202 patches removing EXPERIMENTAL from >> all the Kconfigs in the tree. Should I send them all to lkml (with all >> the associated CCs), or do people want to cherry-pick changes from my >> tree? I don't want to needlessly flood the list. >> >> http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/experimental >> > I cherry-picked the hwmon/pmbus patch (commit 41c5b6bb). Great, thanks! -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Tree for Oct 3 (mfd/syscon)
On 10/03/2012 12:30 AM, Stephen Rothwell wrote: > Hi all, > > Do not add stuff destined for v3.8 to your linux-next included branches > until after v3.7-rc1 is released. > > Changes since 201201002: > on i386: CC drivers/mfd/syscon.o drivers/mfd/syscon.c:94:15: error: variable 'syscon_regmap_config' has initializer but incomplete type drivers/mfd/syscon.c:95:2: error: unknown field 'reg_bits' specified in initializer drivers/mfd/syscon.c:95:2: warning: excess elements in struct initializer drivers/mfd/syscon.c:95:2: warning: (near initialization for 'syscon_regmap_config') drivers/mfd/syscon.c:96:2: error: unknown field 'val_bits' specified in initializer drivers/mfd/syscon.c:96:2: warning: excess elements in struct initializer drivers/mfd/syscon.c:96:2: warning: (near initialization for 'syscon_regmap_config') drivers/mfd/syscon.c:97:2: error: unknown field 'reg_stride' specified in initializer drivers/mfd/syscon.c:97:2: warning: excess elements in struct initializer drivers/mfd/syscon.c:97:2: warning: (near initialization for 'syscon_regmap_config') drivers/mfd/syscon.c: In function 'syscon_probe': drivers/mfd/syscon.c:124:2: error: invalid use of undefined type 'struct regmap_config' drivers/mfd/syscon.c:125:2: error: implicit declaration of function 'devm_regmap_init_mmio' drivers/mfd/syscon.c:125:17: warning: assignment makes pointer from integer without a cast make[3]: *** [drivers/mfd/syscon.o] Error 1 Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.6.0 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set CONFIG_FHANDLE=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_AUDIT_LOGINUID_IMMUTABLE=y CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # # CONFIG_TICK_CPU_ACCOUNTING is not set CONFIG_IRQ_TIME_ACCOUNTING=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y # CONFIG_TASK_DELAY_ACCT is not set # CONFIG_TASK_XACCT is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_RCU_FAST_NO_HZ is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_CGROUPS is not set CONFIG_CHECKPOINT_RESTORE=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y # CONFIG_IPC_NS is not set CONFIG_PID_NS=y # CONFIG_NET_NS is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_ANON_INODES=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_KALLSYMS=y
Re: make CONFIG_EXPERIMENTAL invisible and default
On Tue, Oct 02, 2012 at 07:50:42PM -, Kees Cook wrote: > This config item has not carried much meaning for a while now and is > almost always enabled by default. As agreed during the Linux kernel > summit, it should be removed. As a first step, remove it from being > listed, and default it to on. Once it has been removed from all > subsystem Kconfigs, it will be dropped entirely. > > CC: Greg KH > CC: "Eric W. Biederman" > CC: Serge Hallyn > CC: "Paul E. McKenney" > CC: Andrew Morton > CC: Frederic Weisbecker > Signed-off-by: Kees Cook > Acked-by: Serge Hallyn > > --- > This is the first of a series of 202 patches removing EXPERIMENTAL from > all the Kconfigs in the tree. Should I send them all to lkml (with all > the associated CCs), or do people want to cherry-pick changes from my > tree? I don't want to needlessly flood the list. > > http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/experimental > I cherry-picked the hwmon/pmbus patch (commit 41c5b6bb). Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [GIT PULL] user namespace compile fix for 3.7
On Wed, Oct 03, 2012 at 04:03:54PM -0700, Eric W. Biederman wrote: > > Linus, > > Please pull the for-linus git tree from: > >git://git.kernel.org:/pub/scm/linux/kernel/git/ebiederm/user-namespace.git > for-linus > >HEAD: 702e490211b2b7e448ebe1b3a07d97ad2fc07e03 userns: Fix build of > drivers/staging/dgrp > > This tree contains a trivial build fix for one of the staging drivers > when user namespace support is enabled. Is this something new? Why didn't it show up in the linux-next builds? I'll be glad to take this single patch myself and queue it up with other staging tree fixes before 3.7-final is out, what is the big rush? 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/
