* Re: [PATCH] slob: push the min alignment to long long
From: Matt Mackall @ 2011-06-15 20:55 UTC (permalink / raw)
To: Pekka Enberg
Cc: Sebastian Andrzej Siewior, Christoph Lameter, linux-mm,
David S. Miller, netfilter
In-Reply-To: <BANLkTi=QG3ywRhSx=npioJx-d=yyf=o29A@mail.gmail.com>
On Wed, 2011-06-15 at 23:40 +0300, Pekka Enberg wrote:
> On Wed, Jun 15, 2011 at 11:24 PM, Matt Mackall <mpm@selenic.com> wrote:
> > On Wed, 2011-06-15 at 22:12 +0200, Sebastian Andrzej Siewior wrote:
> >> * Matt Mackall | 2011-06-14 17:05:40 [-0500]:
> >>
> >> >Ok, so you claim that ARCH_KMALLOC_MINALIGN is not set on some
> >> >architectures, and thus SLOB does the wrong thing.
> >> >
> >> >Doesn't that rather obviously mean that the affected architectures
> >> >should define ARCH_KMALLOC_MINALIGN? Because, well, they have an
> >> >"architecture-specific minimum kmalloc alignment"?
> >>
> >> nope, if nothing is defined SLOB asumes that alignment of long is the way
> >> go. Unfortunately alignment of u64 maybe larger than of u32.
> >
> > I understand that. I guess we have a different idea of what constitutes
> > "architecture-specific" and what constitutes "normal".
> >
> > But I guess I can be persuaded that most architectures now expect 64-bit
> > alignment of u64s.
>
> Changing the alignment for everyone is likely to cause less problems
> in the future. Matt, are there any practical reasons why we shouldn't
> do that?
Unless you audit all architectures to check that things are sensible,
it's a trade: regressing performance on one arch to improve correctness
on another. On the one hand, regressions trump improvement. On the
other, correctness trumps performance.
In general, I think the right thing is to require every arch to
explicitly document its alignment requirements via defines in the kernel
headers so that random hackers don't have to scour the internet for
datasheets on obscure architectures they don't care about. We should
have no defaults and refuse to compile on any arch that doesn't have the
define which will ensure someone somewhere actually thinks about it for
each arch.
But as I don't have time to push that vision, I'll let it slide.
--
Mathematics is the supreme nostalgia of our time.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex
From: Linus Torvalds @ 2011-06-15 20:55 UTC (permalink / raw)
To: Ingo Molnar, Andrew Morton
Cc: Peter Zijlstra, Paul McKenney, Tim Chen, Hugh Dickins,
KOSAKI Motohiro, Benjamin Herrenschmidt, David Miller,
Martin Schwidefsky, Russell King, Paul Mundt, Jeff Dike,
Richard Weinberger, Tony Luck, KAMEZAWA Hiroyuki, Mel Gorman,
Nick Piggin, Namhyung Kim, ak, shaohua.li, alex.shi, linux-kernel,
linux-mm, Rafael J. Wysocki
In-Reply-To: <20110615201611.GB4762@elte.hu>
Ingo Molnar <mingo@elte.hu> wrote:
>
>perf record -g will go a long way towards such a tool already - but i
>think it would be useful to create a more top-alike view as well.
perf record -g doesn't help when the issue is that we're recording a single process and the actual work is being done in another unrelated process that is just being woken up.
Sure, you can do a system wide recording, but that shows all kinds of unrelated noise and requires root permissions.
So those rcu threads really need to go.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex
From: Linus Torvalds @ 2011-06-15 20:55 UTC (permalink / raw)
To: Ingo Molnar, Andrew Morton
Cc: Peter Zijlstra, Paul McKenney, Tim Chen, Hugh Dickins,
KOSAKI Motohiro, Benjamin Herrenschmidt, David Miller,
Martin Schwidefsky, Russell King, Paul Mundt, Jeff Dike,
Richard Weinberger, Tony Luck, KAMEZAWA Hiroyuki, Mel Gorman,
Nick Piggin, Namhyung Kim, ak, shaohua.li, alex.shi, linux-kernel,
linux-mm, Rafael J. Wysocki
In-Reply-To: <20110615201611.GB4762@elte.hu>
Ingo Molnar <mingo@elte.hu> wrote:
>
>perf record -g will go a long way towards such a tool already - but i
>think it would be useful to create a more top-alike view as well.
perf record -g doesn't help when the issue is that we're recording a single process and the actual work is being done in another unrelated process that is just being woken up.
Sure, you can do a system wide recording, but that shows all kinds of unrelated noise and requires root permissions.
So those rcu threads really need to go.
Linus
^ permalink raw reply
* Re: Patch-level-format conversion
From: Jonathan Nieder @ 2011-06-15 20:55 UTC (permalink / raw)
To: sedat.dilek; +Cc: git
In-Reply-To: <BANLkTimRArtFBqA4BFASjkS9BC1sbSfUJQ@mail.gmail.com>
(+cc: the git list so others can correct me. I hope that's okay.)
Hi,
Sedat Dilek wrote:
> I have here a patchset extracted from my own git-repo (via git format-patch).
>
> The project for which those patches are want "p0" format, means no
> ---- a/... +++ b/... but --- ... +++ ...
>
> IIRC git does "p1" format as default.
> Any help? Idea?
If I understand correctly, you are in luck. The "git format-patch
--no-prefix" command thanks to Dscho seems to do exactly that:
$ git log -Sno-prefix -- Documentation/diff-options.txt
commit eab9a40b6dd5c1c571b1deb264133db47bb4794d
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Date: Tue Dec 18 19:32:14 2007 +0000
Teach diff machinery to display other prefixes than "a/" and "b/"
With the new options "--src-prefix=<prefix>", "--dst-prefix=<prefix>"
and "--no-prefix", you can now control the path prefixes of the diff
machinery. These used to by hardwired to "a/" for the source prefix
and "b/" for the destination prefix.
Initial patch by Pascal Obry. Sane option names suggested by Linus.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Hope that helps.
Jonathan
^ permalink raw reply
* Re: [GIT PULL] Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex
From: Paul E. McKenney @ 2011-06-15 20:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, Peter Zijlstra, Tim Chen, Andrew Morton,
Hugh Dickins, KOSAKI Motohiro, Benjamin Herrenschmidt,
David Miller, Martin Schwidefsky, Russell King, Paul Mundt,
Jeff Dike, Richard Weinberger, Tony Luck, KAMEZAWA Hiroyuki,
Mel Gorman, Nick Piggin, Namhyung Kim, ak, shaohua.li, alex.shi,
linux-kernel, linux-mm, Rafael J. Wysocki
In-Reply-To: <5a89bf11-4c80-418b-b2ff-ae904983ebb8@email.android.com>
On Wed, Jun 15, 2011 at 01:47:33PM -0700, Linus Torvalds wrote:
>
>
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> >It would be much lower risk to make the current code always use softirq
> >if !RCU_BOOST -- last time I attempted the revert, it was quite hairy.
>
> I don't care if it's a real revert or not, but I want the threads gone. Entirely. Not just the patch that uses softirqs for some things, and threads for the callbacks. No, I don't want the threads to show up or exist at all.
>
> And to be sure, I'd like the code to set up and use the threads to actually compile away statically, so that there clearly isn't some way it's partially enabled.
Yes, the kthread creation will happen only if RCU_BOOST=y. Otherwise,
there will be no RCU kthreads at all.
Thanx, Paul
^ permalink raw reply
* Re: [GIT PULL] Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex
From: Paul E. McKenney @ 2011-06-15 20:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, Peter Zijlstra, Tim Chen, Andrew Morton,
Hugh Dickins, KOSAKI Motohiro, Benjamin Herrenschmidt,
David Miller, Martin Schwidefsky, Russell King, Paul Mundt,
Jeff Dike, Richard Weinberger, Tony Luck, KAMEZAWA Hiroyuki,
Mel Gorman, Nick Piggin, Namhyung Kim, ak, shaohua.li, alex.shi,
linux-kernel, linux-mm, Rafael J. Wysocki
In-Reply-To: <5a89bf11-4c80-418b-b2ff-ae904983ebb8@email.android.com>
On Wed, Jun 15, 2011 at 01:47:33PM -0700, Linus Torvalds wrote:
>
>
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> >It would be much lower risk to make the current code always use softirq
> >if !RCU_BOOST -- last time I attempted the revert, it was quite hairy.
>
> I don't care if it's a real revert or not, but I want the threads gone. Entirely. Not just the patch that uses softirqs for some things, and threads for the callbacks. No, I don't want the threads to show up or exist at all.
>
> And to be sure, I'd like the code to set up and use the threads to actually compile away statically, so that there clearly isn't some way it's partially enabled.
Yes, the kthread creation will happen only if RCU_BOOST=y. Otherwise,
there will be no RCU kthreads at all.
Thanx, Paul
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] target: Make transport_lookup_cmd_lun() locking IRQ-safe
From: Kiran Patil @ 2011-06-15 20:53 UTC (permalink / raw)
To: Roland Dreier; +Cc: Nicholas A. Bellinger, linux-scsi, target-devel
In-Reply-To: <BANLkTimxM4OzQ6imbea0xqb3rmfBehfgEA@mail.gmail.com>
On 6/15/2011 12:41 PM, Roland Dreier wrote:
> On Wed, Jun 15, 2011 at 10:52 AM, Kiran Patil<kiran.patil@intel.com> wrote:
>> Likewise, we need to do same change in function "transport_get_lun_for_tmr",
>> specifically for tmr_lock. Please correct me if I am missing anything.
> Yes, that's right... in fact that is what we were discussing now, isn't it?
> Or is there something different I'm missing?
>
> (BTW transport_get_lun_for_tmr is renamed to transport_lookup_tmr_lun
> in the latest tree)
>
> - R.
Cool. Then we are referring to same function. Looks like I am using old
tree which has function name "transport_get_lun_for_tmr"
Thanks,
-- Kiran P,
^ permalink raw reply
* Re: [PATCH 1/2] ALSA: ASoC: add STA32X codec driver
From: Johannes Stezenbach @ 2011-06-15 20:53 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, lrg, Daniel Mack
In-Reply-To: <20110615150516.GC2806@opensource.wolfsonmicro.com>
On Wed, Jun 15, 2011 at 04:05:16PM +0100, Mark Brown wrote:
> On Tue, Jun 14, 2011 at 09:27:05PM +0200, Daniel Mack wrote:
>
> > +static const char *sta32x_limiter_ac_release_thr[] = {
> > + "-inf", "-29dB", "-20dB", "-16dB", "-14dB", "-12dB", "-10dB", "-8dB",
> > + "-7dB", "-6dB", "-5dB", "-4dB", "-3dB", "-2dB", "-1dB", "0dB" };
> > +static const char *sta32x_limiter_drc_attack_thr[] = {
> > + "-31dB", "-29dB", "-27dB", "-25dB", "-23dB", "-21dB", "-19dB", "-17dB",
> > + "-16dB", "-15dB", "-14dB", "-13dB", "-12dB", "-10dB", "-7dB", "-4dB" };
> > +static const char *sta32x_limiter_drc_release_thr[] = {
> > + "-inf", "-38dB", "-36dB", "-33dB", "-31dB", "-30dB", "-28dB", "-26dB",
> > + "-24dB", "-22dB", "-20dB", "-18dB", "-15dB", "-12dB", "-9dB", "-6dB" };
> > +
>
> Doing these as regular volume TLVs will tend to work better in UIs.
The steps are not evenly distributed so I thought this is the
only way to describe the hardware correctly. Or is there a
way to do controls which look like a slider in alsamixer
with steps as shown above?
Thanks for your review.
Johannes
^ permalink raw reply
* Re: [PATCH 001/001] forcedeth: Don't enable hardware vlan support on hardware that doesn't support it
From: Stephen Hemminger @ 2011-06-15 20:53 UTC (permalink / raw)
To: Antoine Reversat; +Cc: netdev
In-Reply-To: <25664046.71236.1308171027618.JavaMail.root@tahiti.vyatta.com>
> In the forcedeth driver hardware vlan support is used even on hardware
> that doesn't support it leading to incorrect tagging of some packets
> when using vlan.
>
> Signed-off-by: Antoine Reversat <a.reversat@gmail.com>
> ---
> --- linux-2.6.39/drivers/net/forcedeth.c 2011-05-19 00:06:34.000000000
> -0400 +++ linux-2.6.39-fixed/drivers/net/forcedeth.c 2011-06-15
> 15:57:45.331158001 -0400
> @@ -4915,6 +4915,10 @@ static void nv_vlan_rx_register(struct n
> { struct fe_priv *np = get_nvpriv(dev);
>
> + /* Don't do anything if device doesn't support VLAN */
> + if (!(np->driver_data & DEV_HAS_VLAN))
> + return;
> + spin_lock_irq(&np->lock);
>
> /* save vlan group */
This shouldn't be necessary. rx_register should not be called
unless NETIF_F_HW_VLAN_RX is set; and device should not be setting
NETIF_F_HW_VLAN_RX unless DEV_HAS_VLAN is set.
The real problem is vlan_dev.c, and applies to all devices.
^ permalink raw reply
* Re: [PATCHv3 2/3] Re-add manager_get_default_adapter()
From: Johan Hedberg @ 2011-06-15 20:53 UTC (permalink / raw)
To: Antonio Ospite
Cc: linux-bluetooth, Bastien Nocera, linux-input, Jim Paris,
Ranulf Doswell, Pascal A . Brisset, Marcin Tolysz,
Christian Birchinger, Filipe Lopes, Alan Ott, Mikko Virkkila,
Simon Wood
In-Reply-To: <1307538557-9287-3-git-send-email-ospite@studenti.unina.it>
Hi,
On Wed, Jun 08, 2011, Antonio Ospite wrote:
> From: Bastien Nocera <hadess@hadess.net>
>
> Signed-off-by: Bastien Nocera <hadess@hadess.net>
> Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
> ---
> src/manager.c | 5 +++++
> src/manager.h | 1 +
> 2 files changed, 6 insertions(+), 0 deletions(-)
I've applied this one (with the signed-off-by lines remove which we
don't use and a better explanation) so you can continue with each of
your work in fine-tuning/fixing your patches.
Johan
^ permalink raw reply
* Re: [ANNOUNCE] Native Linux KVM tool v2
From: Prasad Joshi @ 2011-06-15 20:49 UTC (permalink / raw)
To: Sasha Levin
Cc: Pekka Enberg, Avi Kivity, linux-kernel, kvm, Andrew Morton,
Linus Torvalds, Ingo Molnar, Cyrill Gorcunov, Asias He,
Jens Axboe
In-Reply-To: <1308169421.14175.19.camel@lappy>
On Wed, Jun 15, 2011 at 9:23 PM, Sasha Levin <levinsasha928@gmail.com> wrote:
> On Wed, 2011-06-15 at 21:13 +0100, Prasad Joshi wrote:
>> On Wed, Jun 15, 2011 at 6:10 PM, Pekka Enberg <penberg@kernel.org> wrote:
>> > On Wed, Jun 15, 2011 at 7:30 PM, Avi Kivity <avi@redhat.com> wrote:
>> >> On 06/15/2011 06:53 PM, Pekka Enberg wrote:
>> >>>
>> >>> - Fast QCOW2 image read-write support beating Qemu in fio benchmarks. See
>> >>> the
>> >>> following URL for test result details: https://gist.github.com/1026888
>> >>
>> >> This is surprising. How is qemu invoked?
>> >
>> > Prasad will have the details. Please note that the above are with Qemu
>> > defaults which doesn't use virtio. The results with virtio are little
>> > better but still in favor of tools/kvm.
>> >
>>
>> The qcow2 image used for testing was copied on to /dev/shm to avoid
>> the disk delays in performance measurement.
>>
>> QEMU was invoked with following parameters
>>
>> $ qemu-system-x86_64 -hda <disk image on hard disk> -hdb
>> /dev/shm/test.qcow2 -m 1024M
>>
>
> Prasad, Could you please run this test with '-drive
> file=/dev/shm/test.qcow2,if=virtio' instead of the '-hdb' thing?
>
Infact I have already tried that. Like Pekka mentioned, the results
are still in favour of KVM tools.
I machine that I work on is not with me at the moment, I will be able
to mail the exact numbers tomorrow.
Thanks and Regards,
Prasad
>> FIO job file used for measuring the numbers was
>>
>> prasad@prasad-vm:~$ cat fio-mixed.job
>> ; fio-mixed.job for autotest
>>
>> [global]
>> name=fio-sync
>> directory=/mnt
>> rw=randrw
>> rwmixread=67
>> rwmixwrite=33
>> bsrange=16K-256K
>> direct=0
>> end_fsync=1
>> verify=crc32
>> ;ioscheduler=x
>> numjobs=4
>>
>> [file1]
>> size=50M
>> ioengine=sync
>> mem=malloc
>>
>> [file2]
>> stonewall
>> size=50M
>> ioengine=aio
>> mem=shm
>> iodepth=4
>>
>> [file3]
>> stonewall
>> size=50M
>> ioengine=mmap
>> mem=mmap
>> direct=1
>>
>> [file4]
>> stonewall
>> size=50M
>> ioengine=splice
>> mem=malloc
>> direct=1
>>
>> - The test generates 16 file each of ~50MB, so in total ~800MB data was written.
>> - The test.qcow2 was newly created before it was used with QEMU or KVM tool
>> - The size of the QCOW2 image was 1.5GB.
>> - The host machine had 2GB RAM.
>> - The guest machine in both the cases was started with 1GB memory.
>>
>> Thanks and Regards,
>> Prasad
>>
>> >> btw the dump above is a little hard to interpret.
>> >
>> > It's what fio reports. The relevant bits are:
>> >
>> >
>> > Qemu:
>> >
>> > Run status group 0 (all jobs):
>> > READ: io=204800KB, aggrb=61152KB/s, minb=15655KB/s, maxb=17845KB/s,
>> > mint=2938msec, maxt=3349msec
>> > WRITE: io=68544KB, aggrb=28045KB/s, minb=6831KB/s, maxb=7858KB/s,
>> > mint=2292msec, maxt=2444msec
>> >
>> > Run status group 1 (all jobs):
>> > READ: io=204800KB, aggrb=61779KB/s, minb=15815KB/s, maxb=17189KB/s,
>> > mint=3050msec, maxt=3315msec
>> > WRITE: io=66576KB, aggrb=24165KB/s, minb=6205KB/s, maxb=7166KB/s,
>> > mint=2485msec, maxt=2755msec
>> >
>> > Run status group 2 (all jobs):
>> > READ: io=204800KB, aggrb=6722KB/s, minb=1720KB/s, maxb=1737KB/s,
>> > mint=30178msec, maxt=30467msec
>> > WRITE: io=65424KB, aggrb=2156KB/s, minb=550KB/s, maxb=573KB/s,
>> > mint=29682msec, maxt=30342msec
>> >
>> > Run status group 3 (all jobs):
>> > READ: io=204800KB, aggrb=6994KB/s, minb=1790KB/s, maxb=1834KB/s,
>> > mint=28574msec, maxt=29279msec
>> > WRITE: io=68192KB, aggrb=2382KB/s, minb=548KB/s, maxb=740KB/s,
>> > mint=27121msec, maxt=28625msec
>> >
>> > Disk stats (read/write):
>> > sdb: ios=60583/6652, merge=0/164, ticks=156340/672030,
>> > in_queue=828230, util=82.71%
>> >
>> > tools/kvm:
>> >
>> > Run status group 0 (all jobs):
>> > READ: io=204800KB, aggrb=149162KB/s, minb=38185KB/s,
>> > maxb=46030KB/s, mint=1139msec, maxt=1373msec
>> > WRITE: io=70528KB, aggrb=79156KB/s, minb=18903KB/s, maxb=23726KB/s,
>> > mint=804msec, maxt=891msec
>> >
>> > Run status group 1 (all jobs):
>> > READ: io=204800KB, aggrb=188235KB/s, minb=48188KB/s,
>> > maxb=57932KB/s, mint=905msec, maxt=1088msec
>> > WRITE: io=64464KB, aggrb=84821KB/s, minb=21751KB/s, maxb=27392KB/s,
>> > mint=570msec, maxt=760msec
>> >
>> > Run status group 2 (all jobs):
>> > READ: io=204800KB, aggrb=20005KB/s, minb=5121KB/s, maxb=5333KB/s,
>> > mint=9830msec, maxt=10237msec
>> > WRITE: io=66624KB, aggrb=6615KB/s, minb=1671KB/s, maxb=1781KB/s,
>> > mint=9558msec, maxt=10071msec
>> >
>> > Run status group 3 (all jobs):
>> > READ: io=204800KB, aggrb=66149KB/s, minb=16934KB/s, maxb=17936KB/s,
>> > mint=2923msec, maxt=3096msec
>> > WRITE: io=69600KB, aggrb=26717KB/s, minb=6595KB/s, maxb=7342KB/s,
>> > mint=2530msec, maxt=2605msec
>> >
>> > Disk stats (read/write):
>> > vdb: ios=61002/6654, merge=0/183, ticks=27270/205780,
>> > in_queue=232220, util=69.46%
>> >
>
> --
>
> Sasha.
>
>
^ permalink raw reply
* Re: [RFCv2 PATCH 0/5] tuner-core: fix s_std and s_tuner
From: Devin Heitmueller @ 2011-06-15 20:49 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Andy Walls, linux-media, Mauro Carvalho Chehab
In-Reply-To: <201106152237.02427.hverkuil@xs4all.nl>
On Wed, Jun 15, 2011 at 4:37 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> But the driver has that information, so it should act accordingly.
>
> So on first open you can check whether the current input has a tuner and
> power on the tuner in that case. On S_INPUT you can also poweron/off accordingly
> (bit iffy against the spec, though). So in that case the first use case would
> actually work. It does require that tuner-core.c supports s_power(1), of course.
This will get messy, and is almost certain to get screwed up and cause
regressions at least on some devices.
> BTW, I noticed in tuner-core.c that the g_tuner op doesn't wake-up the tuner
> when called. I think it should be added, even though most (all?) tuners will
> need time before they can return anything sensible.
Bear in mind that some tuners can take several seconds to load
firmware when powered up. You don't want a situation where the tuner
is reloading firmware continuously, the net result being that calls to
v4l2-ctl that used to take milliseconds now take multiple seconds.
> BTW2: it's not a good idea to just broadcast s_power to all subdevs. That should
> be done to the tuner(s) only since other subdevs might also implement s_power.
> For now it's pretty much just tuners and some sensors, though.
>
> You know, this really needs to be a standardized module option and/or sysfs
> entry: 'always on', 'wake up on first open', 'wake up on first use'.
That would definitely be useful, but it shouldn't be a module option
since you can have multiple devices using the same module. It really
should be an addition to the V4L API.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
^ permalink raw reply
* Re: [PATCH 1/2] gpio/tegra: Move Tegra gpio driver to drivers/gpio
From: Grant Likely @ 2011-06-15 20:48 UTC (permalink / raw)
To: Colin Cross
Cc: Erik Gilling, lkml, linux-tegra, Olof Johansson,
spi-devel-general, linux-arm-kernel@lists.infradead.org,
Stephen Warren
In-Reply-To: <BANLkTinij15PZw11Y3Qt=PV1kkP1pw1oaszTdMfD55Cf8cOJkw@mail.gmail.com>
On Wed, Jun 15, 2011 at 2:21 PM, Colin Cross <ccross@android.com> wrote:
> On Wed, Jun 15, 2011 at 12:37 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> As part of the gpio driver consolidation, this patch moves the Tegra driver
>> into drivers/gpio
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>
>> If there are no objections, I'll merge this via gpio/next
>
> I have this patch as part of a series that should get posted later
> this week, as well as a patch on top of it that depends on this change
> and another change in my tree, but I'm pessimistic that my series will
> get in to 3.1 since it depends on some common consolidation that
> hasn't been agreed upon yet. So,
> Acked-by: Colin Cross <ccross@android.com>
>
> Put it in gpio/next, and I'll make sure any other Tegra patches with
> dependencies get pulled after yours.
How about I put it in a separate branch so that if you need to pull it
for dependencies then you can do so without pulling in all the
gpio/next commits.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 09/21] qapi: add QMP dispatch functions
From: Luiz Capitulino @ 2011-06-15 20:48 UTC (permalink / raw)
To: Michael Roth; +Cc: Jes.Sorensen, Anthony Liguori, agl, qemu-devel
In-Reply-To: <4DF919E0.9030508@linux.vnet.ibm.com>
On Wed, 15 Jun 2011 15:45:20 -0500
Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> On 06/15/2011 03:12 PM, Luiz Capitulino wrote:
> > On Wed, 15 Jun 2011 14:45:30 -0500
> > Anthony Liguori<aliguori@us.ibm.com> wrote:
> >
> >> On 06/15/2011 02:33 PM, Luiz Capitulino wrote:
> >>> On Mon, 13 Jun 2011 21:31:14 -0500
> >>> Michael Roth<mdroth@linux.vnet.ibm.com> wrote:
> >>>
> >>>
> >>>> +{
> >>>> + const char *command;
> >>>> + QDict *args, *dict;
> >>>> + QmpCommand *cmd;
> >>>> + QObject *ret = NULL;
> >>>> +
> >>>> + if (qobject_type(request) != QTYPE_QDICT) {
> >>>> + error_set(errp, QERR_JSON_PARSE_ERROR, "request is not a dictionary");
> >>>> + goto out;
> >>>> + }
> >>>> +
> >>>> + dict = qobject_to_qdict(request);
> >>>> + if (!qdict_haskey(dict, "execute")) {
> >>>> + error_set(errp, QERR_JSON_PARSE_ERROR, "no execute key");
> >>>> + goto out;
> >>>> + }
> >>>> +
> >>>> + command = qdict_get_str(dict, "execute");
> >>>> + cmd = qmp_find_command(command);
> >>>> + if (cmd == NULL) {
> >>>> + error_set(errp, QERR_COMMAND_NOT_FOUND, command);
> >>>> + goto out;
> >>>> + }
> >>>> +
> >>>> + if (!qdict_haskey(dict, "arguments")) {
> >>>> + args = qdict_new();
> >>>> + } else {
> >>>> + args = qdict_get_qdict(dict, "arguments");
> >>>> + QINCREF(args);
> >>>> + }
> >>>
> >>> This function doesn't seem to handle extra keys in the command dict, like:
> >>>
> >>> { "execute": "query-block", "foo": "bar" }
> >>>
> >>> You probably want to use qmp_check_input_obj() here.
> >>
> >> That's a feature, no?
> >>
> >> "Be liberal in what you accept, conservative in what you send."
> >
> > I'm not sure the principle applies in this case, as this is an invalid
> > argument. This is the kind of thing that could give a hard time to clients,
> > like using a new argument on an old command and wonder why it doesn't work.
> >
> > Libvirt did something like this in the past when we weren't doing the check,
> > they were passing an additional key for some command and expecting it would
> > have the desired functionality.
> >
> >>>> +
> >>>> + switch (cmd->type) {
> >>>> + case QCT_NORMAL:
> >>>> + cmd->fn(args,&ret, errp);
> >>>> + if (!error_is_set(errp)&& ret == NULL) {
> >>>> + ret = QOBJECT(qdict_new());
> >>>> + }
> >>>> + break;
> >>>> + }
> >>>> +
> >>>> + QDECREF(args);
> >>>> +
> >>>> +out:
> >>>> +
> >>>> + return ret;
> >>>> +}
> >>>> +
> >>>> +QObject *qmp_dispatch(QObject *request)
> >>>> +{
> >>>> + Error *err = NULL;
> >>>> + QObject *ret;
> >>>> + QDict *rsp;
> >>>> +
> >>>> + ret = qmp_dispatch_err(request,&err);
> >>>> +
> >>>> + rsp = qdict_new();
> >>>> + if (err) {
> >>>> + qdict_put_obj(rsp, "error", error_get_qobject(err));
> >>>> + error_free(err);
> >>>> + } else if (ret) {
> >>>> + qdict_put_obj(rsp, "return", ret);
> >>>> + } else {
> >>>> + QDECREF(rsp);
> >>>> + return NULL;
> >>>
> >>> When does the 'else' condition happens?
> >>
> >> Signals which aren't in this patch series.
> >
> > It can be dropped then.
> >
>
> I think it's still a good safeguard in the meantime. Whether it's
> reachable or not is hard to know without looking over a lot of code
> outside the function, and things can change over time. This way the user
> can expect a NULL for an undefined error, as opposed to an empty
> dictionary they need to free, which isn't very intuitive.
Makes sense. Although I think I prefer an assert(). But I'm not strong
about it.
>
> >>
> >> Regards,
> >>
> >> Anthony Liguori
> >>
> >>>
> >>>> + }
> >>>> +
> >>>> + return QOBJECT(rsp);
> >>>> +}
> >>>
> >>
> >
>
^ permalink raw reply
* [PATCH 1/2] gpio/tegra: Move Tegra gpio driver to drivers/gpio
From: Grant Likely @ 2011-06-15 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BANLkTinij15PZw11Y3Qt=PV1kkP1pw1oaszTdMfD55Cf8cOJkw@mail.gmail.com>
On Wed, Jun 15, 2011 at 2:21 PM, Colin Cross <ccross@android.com> wrote:
> On Wed, Jun 15, 2011 at 12:37 PM, Grant Likely
> <grant.likely@secretlab.ca> wrote:
>> As part of the gpio driver consolidation, this patch moves the Tegra driver
>> into drivers/gpio
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>
>> If there are no objections, I'll merge this via gpio/next
>
> I have this patch as part of a series that should get posted later
> this week, as well as a patch on top of it that depends on this change
> and another change in my tree, but I'm pessimistic that my series will
> get in to 3.1 since it depends on some common consolidation that
> hasn't been agreed upon yet. ?So,
> Acked-by: Colin Cross <ccross@android.com>
>
> Put it in gpio/next, and I'll make sure any other Tegra patches with
> dependencies get pulled after yours.
How about I put it in a separate branch so that if you need to pull it
for dependencies then you can do so without pulling in all the
gpio/next commits.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2] gpio/tegra: Move Tegra gpio driver to drivers/gpio
From: Grant Likely @ 2011-06-15 20:48 UTC (permalink / raw)
To: Colin Cross
Cc: Erik Gilling, lkml, linux-tegra, Olof Johansson,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Stephen Warren
In-Reply-To: <BANLkTinij15PZw11Y3Qt=PV1kkP1pw1oaszTdMfD55Cf8cOJkw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Jun 15, 2011 at 2:21 PM, Colin Cross <ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org> wrote:
> On Wed, Jun 15, 2011 at 12:37 PM, Grant Likely
> <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
>> As part of the gpio driver consolidation, this patch moves the Tegra driver
>> into drivers/gpio
>>
>> Signed-off-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
>> ---
>>
>> If there are no objections, I'll merge this via gpio/next
>
> I have this patch as part of a series that should get posted later
> this week, as well as a patch on top of it that depends on this change
> and another change in my tree, but I'm pessimistic that my series will
> get in to 3.1 since it depends on some common consolidation that
> hasn't been agreed upon yet. So,
> Acked-by: Colin Cross <ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>
>
> Put it in gpio/next, and I'll make sure any other Tegra patches with
> dependencies get pulled after yours.
How about I put it in a separate branch so that if you need to pull it
for dependencies then you can do so without pulling in all the
gpio/next commits.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* mwifiex & P2P (aka WiFi Direct)
From: Liam @ 2011-06-15 20:48 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <BANLkTik2PGhQh9=ZTfm2MXHdKSMVqNPfXg@mail.gmail.com>
We're integrating a module based on the Marvell SD8787 into an
embedded Linux device. We need to enable P2P/WFD on this device.
I see no refs to P2P in the mwifiex README, but there is
vendor-provided code ('wfd' command) to configure this subsystem.
Is anyone implementing the "socket control interface" P2P primitives,
or other low-level API to P2P, in mwifiex?
If not, I have the choice of either adding such an API to mwifiex, or
using vendor-provided driver code which presumably isn't as
well-vetted as mwifiex. Any guidance?
Liam Breck
Menlo Park, CA
^ permalink raw reply
* Re: [GIT PULL] Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex
From: Linus Torvalds @ 2011-06-15 20:47 UTC (permalink / raw)
To: paulmck, Ingo Molnar
Cc: Peter Zijlstra, Tim Chen, Andrew Morton, Hugh Dickins,
KOSAKI Motohiro, Benjamin Herrenschmidt, David Miller,
Martin Schwidefsky, Russell King, Paul Mundt, Jeff Dike,
Richard Weinberger, Tony Luck, KAMEZAWA Hiroyuki, Mel Gorman,
Nick Piggin, Namhyung Kim, ak, shaohua.li, alex.shi, linux-kernel,
linux-mm, Rafael J. Wysocki
In-Reply-To: <20110615202956.GG2267@linux.vnet.ibm.com>
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
>It would be much lower risk to make the current code always use softirq
>if !RCU_BOOST -- last time I attempted the revert, it was quite hairy.
I don't care if it's a real revert or not, but I want the threads gone. Entirely. Not just the patch that uses softirqs for some things, and threads for the callbacks. No, I don't want the threads to show up or exist at all.
And to be sure, I'd like the code to set up and use the threads to actually compile away statically, so that there clearly isn't some way it's partially enabled.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [GIT PULL] Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex
From: Linus Torvalds @ 2011-06-15 20:47 UTC (permalink / raw)
To: paulmck, Ingo Molnar
Cc: Peter Zijlstra, Tim Chen, Andrew Morton, Hugh Dickins,
KOSAKI Motohiro, Benjamin Herrenschmidt, David Miller,
Martin Schwidefsky, Russell King, Paul Mundt, Jeff Dike,
Richard Weinberger, Tony Luck, KAMEZAWA Hiroyuki, Mel Gorman,
Nick Piggin, Namhyung Kim, ak, shaohua.li, alex.shi, linux-kernel,
linux-mm, Rafael J. Wysocki
In-Reply-To: <20110615202956.GG2267@linux.vnet.ibm.com>
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
>It would be much lower risk to make the current code always use softirq
>if !RCU_BOOST -- last time I attempted the revert, it was quite hairy.
I don't care if it's a real revert or not, but I want the threads gone. Entirely. Not just the patch that uses softirqs for some things, and threads for the callbacks. No, I don't want the threads to show up or exist at all.
And to be sure, I'd like the code to set up and use the threads to actually compile away statically, so that there clearly isn't some way it's partially enabled.
Linus
^ permalink raw reply
* [PATCH 3/3] Removed unused define, CONFIG_ARMV7.
From: Christopher Harvey @ 2011-06-15 20:47 UTC (permalink / raw)
To: u-boot
---
include/configs/am3517_crane.h | 2 +-
include/configs/am3517_evm.h | 2 +-
include/configs/ca9x4_ct_vxp.h | 2 +-
include/configs/cm_t35.h | 2 +-
include/configs/devkit8000.h | 2 +-
include/configs/dig297.h | 2 +-
include/configs/igep0020.h | 2 +-
include/configs/igep0030.h | 2 +-
include/configs/omap3_beagle.h | 2 +-
include/configs/omap3_evm.h | 2 +-
include/configs/omap3_overo.h | 2 +-
include/configs/omap3_pandora.h | 2 +-
include/configs/omap3_sdp3430.h | 2 +-
include/configs/omap3_zoom1.h | 2 +-
include/configs/omap3_zoom2.h | 2 +-
include/configs/omap4_panda.h | 2 +-
include/configs/omap4_sdp4430.h | 2 +-
include/configs/s5p_goni.h | 2 +-
include/configs/s5pc210_universal.h | 2 +-
include/configs/smdkc100.h | 2 +-
include/configs/smdkv310.h | 2 +-
21 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h
index 09cb951..b809053 100644
--- a/include/configs/am3517_crane.h
+++ b/include/configs/am3517_crane.h
@@ -28,7 +28,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3_AM3517CRANE 1 /* working with CRANEBOARD */
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index 80ad342..db026c4 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -28,7 +28,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3_AM3517EVM 1 /* working with AM3517EVM */
diff --git a/include/configs/ca9x4_ct_vxp.h b/include/configs/ca9x4_ct_vxp.h
index 7f83249..fd92137 100644
--- a/include/configs/ca9x4_ct_vxp.h
+++ b/include/configs/ca9x4_ct_vxp.h
@@ -33,7 +33,7 @@
#define CONFIG_SYS_TEXT_BASE 0x60800000
/* High Level Configuration Options */
-#define CONFIG_ARMV7 1
+
#define CONFIG_SYS_MEMTEST_START 0x60000000
#define CONFIG_SYS_MEMTEST_END 0x20000000
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 93a1b26..b4cec35 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -36,7 +36,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3430 1 /* which is in a 3430 */
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index 125c690..f97a4ed 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -32,7 +32,7 @@
#define __CONFIG_H
/* High Level Configuration Options */
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3430 1 /* which is in a 3430 */
diff --git a/include/configs/dig297.h b/include/configs/dig297.h
index 7aeb24e..ee0c6be 100644
--- a/include/configs/dig297.h
+++ b/include/configs/dig297.h
@@ -35,7 +35,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP /* in a TI OMAP core */
#define CONFIG_OMAP34XX /* which is a 34XX */
#define CONFIG_OMAP3430 /* which is in a 3430 */
diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h
index 5af9bec..1c36bc2 100644
--- a/include/configs/igep0020.h
+++ b/include/configs/igep0020.h
@@ -25,7 +25,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3430 1 /* which is in a 3430 */
diff --git a/include/configs/igep0030.h b/include/configs/igep0030.h
index 92144af..8594b87 100644
--- a/include/configs/igep0030.h
+++ b/include/configs/igep0030.h
@@ -25,7 +25,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3430 1 /* which is in a 3430 */
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 9fd80ed..aa602e4 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -31,7 +31,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3430 1 /* which is in a 3430 */
diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
index 13a4fbf..d07c63e 100644
--- a/include/configs/omap3_evm.h
+++ b/include/configs/omap3_evm.h
@@ -36,7 +36,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3430 1 /* which is in a 3430 */
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 242b317..127ff47 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -23,7 +23,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3430 1 /* which is in a 3430 */
diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h
index 39c87a8..e8caa8c 100644
--- a/include/configs/omap3_pandora.h
+++ b/include/configs/omap3_pandora.h
@@ -26,7 +26,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3430 1 /* which is in a 3430 */
diff --git a/include/configs/omap3_sdp3430.h b/include/configs/omap3_sdp3430.h
index 55bbcd4..2a1a13d 100644
--- a/include/configs/omap3_sdp3430.h
+++ b/include/configs/omap3_sdp3430.h
@@ -36,7 +36,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3430 1 /* which is in a 3430 */
diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h
index 9183849..beac7b0 100644
--- a/include/configs/omap3_zoom1.h
+++ b/include/configs/omap3_zoom1.h
@@ -32,7 +32,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3430 1 /* which is in a 3430 */
diff --git a/include/configs/omap3_zoom2.h b/include/configs/omap3_zoom2.h
index 3573edf..214c13b 100644
--- a/include/configs/omap3_zoom2.h
+++ b/include/configs/omap3_zoom2.h
@@ -33,7 +33,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP34XX 1 /* which is a 34XX */
#define CONFIG_OMAP3430 1 /* which is in a 3430 */
diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h
index b4e7f41..d26f903 100644
--- a/include/configs/omap4_panda.h
+++ b/include/configs/omap4_panda.h
@@ -30,7 +30,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP44XX 1 /* which is a 44XX */
#define CONFIG_OMAP4430 1 /* which is in a 4430 */
diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h
index 584a52b..dee32bc 100644
--- a/include/configs/omap4_sdp4430.h
+++ b/include/configs/omap4_sdp4430.h
@@ -31,7 +31,7 @@
/*
* High Level Configuration Options
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_OMAP 1 /* in a TI OMAP core */
#define CONFIG_OMAP44XX 1 /* which is a 44XX */
#define CONFIG_OMAP4430 1 /* which is in a 4430 */
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index d648ce8..5309d57 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -28,7 +28,7 @@
#define __CONFIG_H
/* High Level Configuration Options */
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_SAMSUNG 1 /* in a SAMSUNG core */
#define CONFIG_S5P 1 /* which is in a S5P Family */
#define CONFIG_S5PC110 1 /* which is in a S5PC110 */
diff --git a/include/configs/s5pc210_universal.h b/include/configs/s5pc210_universal.h
index 5915984..b410f97 100644
--- a/include/configs/s5pc210_universal.h
+++ b/include/configs/s5pc210_universal.h
@@ -30,7 +30,7 @@
* High Level Configuration Options
* (easy to change)
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_SAMSUNG 1 /* in a SAMSUNG core */
#define CONFIG_S5P 1 /* which is in a S5P Family */
#define CONFIG_S5PC210 1 /* which is in a S5PC210 */
diff --git a/include/configs/smdkc100.h b/include/configs/smdkc100.h
index 70e23b5..b2f8a00 100644
--- a/include/configs/smdkc100.h
+++ b/include/configs/smdkc100.h
@@ -32,7 +32,7 @@
* High Level Configuration Options
* (easy to change)
*/
-#define CONFIG_ARMV7 1 /* This is an ARM V7 CPU core */
+
#define CONFIG_SAMSUNG 1 /* in a SAMSUNG core */
#define CONFIG_S5P 1 /* which is in a S5P Family */
#define CONFIG_S5PC100 1 /* which is in a S5PC100 */
diff --git a/include/configs/smdkv310.h b/include/configs/smdkv310.h
index a7f5850..5d0806f 100644
--- a/include/configs/smdkv310.h
+++ b/include/configs/smdkv310.h
@@ -26,7 +26,7 @@
#define __CONFIG_H
/* High Level Configuration Options */
-#define CONFIG_ARMV7 1 /*This is an ARM V7 CPU core */
+
#define CONFIG_SAMSUNG 1 /* in a SAMSUNG core */
#define CONFIG_S5P 1 /* S5P Family */
#define CONFIG_S5PC210 1 /* which is in a S5PC210 SoC */
--
1.7.0.4
--------------090405040408060403080204--
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 2/2] get_maintainer: update to match qemu tree
From: Michael S. Tsirkin @ 2011-06-15 20:46 UTC (permalink / raw)
To: Blue Swirl; +Cc: qemu-devel
In-Reply-To: <BANLkTimZ_=YO1UJV_g8TJs8Amyh474xWEQ@mail.gmail.com>
On Wed, Jun 15, 2011 at 10:01:10PM +0300, Blue Swirl wrote:
> On Tue, Jun 14, 2011 at 8:38 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Thanks, I've patched these.
> > ---
> > scripts/get_maintainer.pl | 29 +++++++----------------------
> > 1 files changed, 7 insertions(+), 22 deletions(-)
> >
> > diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> > index d29a8d7..c52ae59 100755
> > --- a/scripts/get_maintainer.pl
> > +++ b/scripts/get_maintainer.pl
> > @@ -258,9 +258,9 @@ if ($email &&
> > die "$P: Please select at least 1 email option\n";
> > }
> >
> > -if (!top_of_kernel_tree($lk_path)) {
> > +if (!top_of_tree($lk_path)) {
> > die "$P: The current directory does not appear to be "
> > - . "a linux kernel source tree.\n";
> > + . "a qemu source tree.\n";
>
> QEMU
> > }
> >
> > ## Read MAINTAINERS for type/value pairs
> > @@ -792,7 +792,7 @@ Notes:
> > --git-min-signatures, --git-max-maintainers, --git-min-percent, and
> > --git-blame
> > Use --hg-since not --git-since to control date selection
> > - File ".get_maintainer.conf", if it exists in the linux kernel source root
> > + File ".get_maintainer.conf", if it exists in the qemu source root
>
> QEMU
>
> > directory, can change whatever get_maintainer defaults are desired.
> > Entries in this file can be any command line argument.
> > This file is prepended to any additional command line arguments.
> > @@ -800,28 +800,13 @@ Notes:
> > EOT
> > }
> >
> > -sub top_of_kernel_tree {
> > +sub top_of_tree {
> > my ($lk_path) = @_;
> >
> > if ($lk_path ne "" && substr($lk_path,length($lk_path)-1,1) ne "/") {
> > $lk_path .= "/";
> > }
> > - if ( (-f "${lk_path}COPYING")
> > - && (-f "${lk_path}CREDITS")
> > - && (-f "${lk_path}Kbuild")
> > - && (-f "${lk_path}MAINTAINERS")
> > - && (-f "${lk_path}Makefile")
> > - && (-f "${lk_path}README")
> > - && (-d "${lk_path}Documentation")
> > - && (-d "${lk_path}arch")
> > - && (-d "${lk_path}include")
> > - && (-d "${lk_path}drivers")
> > - && (-d "${lk_path}fs")
> > - && (-d "${lk_path}init")
> > - && (-d "${lk_path}ipc")
> > - && (-d "${lk_path}kernel")
> > - && (-d "${lk_path}lib")
> > - && (-d "${lk_path}scripts")) {
> > + if (-f "${lk_path}MAINTAINERS") {
>
> The similar check in scripts/checkpatch.pl uses "COPYING",
> "MAINTAINERS", "Makefile", "README", "docs", "VERSION", and "vl.c".
> Please match that.
>
> > return 1;
> > }
> > return 0;
> > @@ -1387,8 +1372,8 @@ sub vcs_exists {
> > if (!$printed_novcs) {
> > warn("$P: No supported VCS found. Add --nogit to options?\n");
> > warn("Using a git repository produces better results.\n");
> > - warn("Try Linus Torvalds' latest git repository using:\n");
> > - warn("git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n");
> > + warn("Try latest git repository using:\n");
> > + warn("git clone git://git.qemu.org/qemu.git\n");
> > $printed_novcs = 1;
> > }
> > return 0;
> > --
> > 1.7.5.53.gc233e
> >
> >
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 09/21] qapi: add QMP dispatch functions
From: Michael Roth @ 2011-06-15 20:45 UTC (permalink / raw)
To: Luiz Capitulino; +Cc: Jes.Sorensen, Anthony Liguori, agl, qemu-devel
In-Reply-To: <20110615171248.191abf2a@doriath>
On 06/15/2011 03:12 PM, Luiz Capitulino wrote:
> On Wed, 15 Jun 2011 14:45:30 -0500
> Anthony Liguori<aliguori@us.ibm.com> wrote:
>
>> On 06/15/2011 02:33 PM, Luiz Capitulino wrote:
>>> On Mon, 13 Jun 2011 21:31:14 -0500
>>> Michael Roth<mdroth@linux.vnet.ibm.com> wrote:
>>>
>>>
>>>> +{
>>>> + const char *command;
>>>> + QDict *args, *dict;
>>>> + QmpCommand *cmd;
>>>> + QObject *ret = NULL;
>>>> +
>>>> + if (qobject_type(request) != QTYPE_QDICT) {
>>>> + error_set(errp, QERR_JSON_PARSE_ERROR, "request is not a dictionary");
>>>> + goto out;
>>>> + }
>>>> +
>>>> + dict = qobject_to_qdict(request);
>>>> + if (!qdict_haskey(dict, "execute")) {
>>>> + error_set(errp, QERR_JSON_PARSE_ERROR, "no execute key");
>>>> + goto out;
>>>> + }
>>>> +
>>>> + command = qdict_get_str(dict, "execute");
>>>> + cmd = qmp_find_command(command);
>>>> + if (cmd == NULL) {
>>>> + error_set(errp, QERR_COMMAND_NOT_FOUND, command);
>>>> + goto out;
>>>> + }
>>>> +
>>>> + if (!qdict_haskey(dict, "arguments")) {
>>>> + args = qdict_new();
>>>> + } else {
>>>> + args = qdict_get_qdict(dict, "arguments");
>>>> + QINCREF(args);
>>>> + }
>>>
>>> This function doesn't seem to handle extra keys in the command dict, like:
>>>
>>> { "execute": "query-block", "foo": "bar" }
>>>
>>> You probably want to use qmp_check_input_obj() here.
>>
>> That's a feature, no?
>>
>> "Be liberal in what you accept, conservative in what you send."
>
> I'm not sure the principle applies in this case, as this is an invalid
> argument. This is the kind of thing that could give a hard time to clients,
> like using a new argument on an old command and wonder why it doesn't work.
>
> Libvirt did something like this in the past when we weren't doing the check,
> they were passing an additional key for some command and expecting it would
> have the desired functionality.
>
>>>> +
>>>> + switch (cmd->type) {
>>>> + case QCT_NORMAL:
>>>> + cmd->fn(args,&ret, errp);
>>>> + if (!error_is_set(errp)&& ret == NULL) {
>>>> + ret = QOBJECT(qdict_new());
>>>> + }
>>>> + break;
>>>> + }
>>>> +
>>>> + QDECREF(args);
>>>> +
>>>> +out:
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +QObject *qmp_dispatch(QObject *request)
>>>> +{
>>>> + Error *err = NULL;
>>>> + QObject *ret;
>>>> + QDict *rsp;
>>>> +
>>>> + ret = qmp_dispatch_err(request,&err);
>>>> +
>>>> + rsp = qdict_new();
>>>> + if (err) {
>>>> + qdict_put_obj(rsp, "error", error_get_qobject(err));
>>>> + error_free(err);
>>>> + } else if (ret) {
>>>> + qdict_put_obj(rsp, "return", ret);
>>>> + } else {
>>>> + QDECREF(rsp);
>>>> + return NULL;
>>>
>>> When does the 'else' condition happens?
>>
>> Signals which aren't in this patch series.
>
> It can be dropped then.
>
I think it's still a good safeguard in the meantime. Whether it's
reachable or not is hard to know without looking over a lot of code
outside the function, and things can change over time. This way the user
can expect a NULL for an undefined error, as opposed to an empty
dictionary they need to free, which isn't very intuitive.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>>> + }
>>>> +
>>>> + return QOBJECT(rsp);
>>>> +}
>>>
>>
>
^ permalink raw reply
* Re: Using Transifex in git.git
From: Ævar Arnfjörð Bjarmason @ 2011-06-15 20:43 UTC (permalink / raw)
To: kusmabite
Cc: Ramkumar Ramachandra, Dimitris Glezos, Git List, Jonathan Nieder,
Junio C Hamano
In-Reply-To: <BANLkTin9bhtB_OPMWCVsbtKBpRXp2o=uLA@mail.gmail.com>
On Wed, Jun 15, 2011 at 15:21, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> On Tue, Jun 14, 2011 at 7:57 AM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
>> I think it's a good idea to use a system like Transifex to manage
>> translations for git.git, so that we can attract a large number of
>> non-technical translators.
>
> Are we sure we want non-technical translators to translate Git, a
> highly technical program with many technical terms?
Well, usually even bad translations (although not horribly bad) are
better than nothing.
Most translated strings will have little or nothing git-specific about
them, but will be something like "We couldn't open file %s due to
XYZ".
And even if someone translates e.g. "branch" incorrectly they usually
do so consistently, so it's easy to search & replace those sort of
issues out of existence.
^ permalink raw reply
* Re: Kernel panic on java mail server
From: Yohan @ 2011-06-15 20:43 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <4DF8F1D0.7000907@corp.free.fr>
On 15/06/2011 19:54, Yohan wrote:
> Hello,
>
> I have a stange kernel panic on a zimbra mail server (mysqld + server in
> java)... when the java process starts the system freeze...
> This is the first time that i have that kind of problem over 70 same
> kind servers.
>
> The hardware has been changed 3 times (2 times on AMD server, 1 time on
> Intel server).
>
> I join the traces on the intel platform, Tyan S7012 MB, 1 CPU Intel
> E5645, 48GB RAM, kernels 2.6.32.41 and 2.6.39.1 without debugging
> enabled and the output with the 2.6.32.41 with debugging enabled.
>
> It was tested on 2.6.32.41 / 2.6.35.13 / 2.6.38.4 / 2.6.38.8 /
> 2.6.39.1.... same thing.
>
> Thanks for helping.
> Yohan
>
Tested on 3.0.0-rc3 without debugging but with profiling, SECCOMP and
CC_STACKPROTECTOR : when starting the java process, the OS reboot
without any error message on the serial console.
^ permalink raw reply
* Re: bernard 5.0.1 and beagle-xm rev c
From: Jason Kridner @ 2011-06-15 20:43 UTC (permalink / raw)
To: gmane; +Cc: poky
In-Reply-To: <itavps$v4d$1@dough.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]
On Wed, Jun 15, 2011 at 3:05 PM, Robert Berger <
gmane@reliableembeddedsystems.com> wrote:
> Jason,
>
> On 06/15/2011 09:26 PM, Jason Kridner wrote:
> >
> > This thread has been moving faster than me. :)
> >
> > You can use mainline u-boot. There are some minor missing features, but
> > I did do some playing with mainline u-boot and xM rev C about a month
> > ago and it was good. The version might not be reported properly, but
> > the default was updated to be if it was an unknown xM revision, it would
> > default to the latest. Old u-boot versions had a bug where they would
> > revert to a really old version. If the default was the latest, there
> > would have been no breakage as no u-boot dependencies changed between xM
> > rev A/B and xM rev C.
> >
>
> mainline u-boot sounds good.
>
> What kernel did you use for your tests?
>
Angstrom linux-omap-psp_2.6.32 and linux-omap_2.6.39. At the time, the
linux-omap_2.6.39 was a bit flaky, but I think most issues have been cleared
up now.
>
> Regards,
>
> Robert
> ..."Q: What is IBM's definition of a man year? A: 720 programmers
> trying to finish the job before lunch."
>
> My public pgp key is available at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
>
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>
[-- Attachment #2: Type: text/html, Size: 2274 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.