* [U-Boot] packed attribute problem
From: Wolfgang Denk @ 2010-10-07 17:57 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20101007114634.70e0f197@udp111988uds.am.freescale.net>
Dear Scott Wood,
In message <20101007114634.70e0f197@udp111988uds.am.freescale.net> you wrote:
>
> I think this gets down to how such pointers are generated -- if you
> stick with well-defined C, the compiler/ABI should be able to avoid
> generating an unaligned pointer.
It is a pretty common method to use a pointer to some struct (for
example, some form of PDU) and make it point to some I/O buffer.
Depending on I/O subsystem, pre-pended protocol headerss and such the
resulting pointer may or may not be aligned. This is something that
the compiler has zero influence on. [Yes, of course the application
could always copy the data to a properly aligned memory region. But I
bet you would quickly complain about the poor throughput if the
network stack on your systems were implemented that way.]
> > I may be wrong here, but I cannot
> > think of any statement in the standards in this regard - it's only data
> > types that imply alignments.
>
> Pointers point to typed data...
Yes, and these typed date can be anywhere, even on addresses that
don't match the natural alignment of these data.
> C doesn't guarantee this, and it would be broken on certain chips
Actually I consider this a deficiency in the C specification. I've
been using C since Unix Version 6, and to me it is still mostly a
high-level assembler language. I definitly do not want the compiler
to do different things than what I tell him.
> when unaligned, e.g. old ARM chips that do weird rotaty things rather
> than trap when you do an unaligned access.
I think it was acceptable for such systems to enforce the compiler (by
setting special compiler switches) to implement such extra access modes.
But doing it by default and unconditionally for all systems of that
architecture seems broken to me. It's unfair collective punishment.
But alas. That's how it is in ARM land...
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Perl already has an IDE. It's called Unix.
-- Tom Christiansen in 375bd509 at cs.colorado.edu
^ permalink raw reply
* Re: [PATCH] trace "exit to userspace" event
From: Gleb Natapov @ 2010-10-07 17:56 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: avi, kvm
In-Reply-To: <20101007161839.GA31784@amt.cnet>
On Thu, Oct 07, 2010 at 01:18:39PM -0300, Marcelo Tosatti wrote:
> On Tue, Oct 05, 2010 at 03:14:32PM +0200, Gleb Natapov wrote:
> > Add tracepoint for userspace exit.
> >
> > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
> > index 6dd3a51..fb44da0 100644
> > --- a/include/trace/events/kvm.h
> > +++ b/include/trace/events/kvm.h
> > @@ -6,6 +6,31 @@
> > #undef TRACE_SYSTEM
> > #define TRACE_SYSTEM kvm
> >
> > +#define ERSN(x) { KVM_EXIT_##x, "KVM_EXIT_" #x }
> > +
> > +#define kvm_trace_exit_reason \
> > + ERSN(UNKNOWN), ERSN(EXCEPTION), ERSN(IO), ERSN(HYPERCALL), \
> > + ERSN(DEBUG), ERSN(HLT), ERSN(MMIO), ERSN(IRQ_WINDOW_OPEN), \
> > + ERSN(SHUTDOWN), ERSN(FAIL_ENTRY), ERSN(INTR), ERSN(SET_TPR), \
> > + ERSN(TPR_ACCESS), ERSN(S390_SIEIC), ERSN(S390_RESET), ERSN(DCR),\
> > + ERSN(NMI), ERSN(INTERNAL_ERROR), ERSN(OSI)
> > +
> > +TRACE_EVENT(kvm_userspace_exit,
> > + TP_PROTO(__u32 reason),
> > + TP_ARGS(reason),
> > +
> > + TP_STRUCT__entry(
> > + __field( __u32, reason )
> > + ),
> > +
> > + TP_fast_assign(
> > + __entry->reason = reason;
> > + ),
> > +
> > + TP_printk("reason %s", __print_symbolic(__entry->reason,
> > + kvm_trace_exit_reason))
> > +);
> > +
> > #if defined(__KVM_HAVE_IOAPIC)
> > TRACE_EVENT(kvm_set_irq,
> > TP_PROTO(unsigned int gsi, int level, int irq_source_id),
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index b8499f5..8800713 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -1458,6 +1458,8 @@ static long kvm_vcpu_ioctl(struct file *filp,
> > if (arg)
> > goto out;
> > r = kvm_arch_vcpu_ioctl_run(vcpu, vcpu->run);
> > + if (r >= 0)
> > + trace_kvm_userspace_exit(vcpu->run->exit_reason);
> > break;
> > case KVM_GET_REGS: {
> > struct kvm_regs *kvm_regs;
> > --
> > Gleb.
>
> Exit codes are also valid for r == -EINTR and -EAGAIN cases, eg
> EXIT_INTR. Better print it out for all cases, and let the reader
> decide whether exit_reason is valid.
Are they? I see that userspace does not look into run->exit_reason in
case of -EINTR and -EAGAIN.
--
Gleb.
^ permalink raw reply
* Re: [PATCH V2] Use firmware provided index to register a network
From: Narendra_K @ 2010-10-07 17:56 UTC (permalink / raw)
To: greg
Cc: kay.sievers, Matt_Domsch, netdev, linux-hotplug, linux-pci,
Jordan_Hargrave, Vijay_Nijhawan, Charles_Rose
In-Reply-To: <20101007171532.GA29857@kroah.com>
On Thu, Oct 07, 2010 at 10:45:32PM +0530, Greg KH wrote:
> On Thu, Oct 07, 2010 at 07:05:14PM +0200, Kay Sievers wrote:
> > On Thu, Oct 7, 2010 at 18:48, Greg KH <greg@kroah.com> wrote:
> > > On Thu, Oct 07, 2010 at 11:31:13AM -0500, Matt Domsch wrote:
> > >> 1) SMBIOS type 41 method. Windows does not use this today, and I
> > >> can't speak to their future plans. Narendra's kernel patch does,
> > >> as has biosdevname, the udev helper we first wrote for this
> > >> purpose, for several years.
> > >
> > > Then stick with that udev helper please :)
> >
> > What about just exporting this information in sysfs, and not touch the
> naming?
>
> I think this is now exported in userspace, right Narendra?
>
Right. It is in the mainline kernel.
( commit 911e1c9b05a8e3559a7aa89083930700a0b9e7ee)
--
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] kobject: name reference should not be lost when lack of memory error happens
From: Greg KH @ 2010-10-07 17:53 UTC (permalink / raw)
To: Roman Tereshonkov, Kay Sievers; +Cc: linux-kernel, gregkh
In-Reply-To: <1286447573-12579-1-git-send-email-roman.tereshonkov@nokia.com>
On Thu, Oct 07, 2010 at 01:32:53PM +0300, Roman Tereshonkov wrote:
> If lack of memory error happens we must restore the old kobject name reference
No, we can't do that, as the caller will not be expecting that to have
happened, right Kay?
I think the code as-is is correct, your kobject is in an unknown state
and can't be used anymore.
thanks,
greg k-h
> Signed-off-by: Roman Tereshonkov <roman.tereshonkov@nokia.com>
> ---
> lib/kobject.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/lib/kobject.c b/lib/kobject.c
> index f07c572..c5cb117 100644
> --- a/lib/kobject.c
> +++ b/lib/kobject.c
> @@ -222,8 +222,10 @@ int kobject_set_name_vargs(struct kobject *kobj, const char *fmt,
> return 0;
>
> kobj->name = kvasprintf(GFP_KERNEL, fmt, vargs);
> - if (!kobj->name)
> + if (!kobj->name) {
> + kobj->name = old_name;
> return -ENOMEM;
> + }
>
> /* ewww... some of these buggers have '/' in the name ... */
> while ((s = strchr(kobj->name, '/')))
> --
> 1.7.0.4
^ permalink raw reply
* Re: [PATCH] mac80211: Deny new BA agreements from being started during offchannel operation
From: Johannes Berg @ 2010-10-07 17:56 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, John W. Linville, Srinivasa Duvvuri, Matt Smith,
Bennyam Malavazi, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTi=iW1T7w-9akkR=DNnrGg3XD5nO=8pJ7V2_PiL4@mail.gmail.com>
On Thu, 2010-10-07 at 10:21 -0700, Luis R. Rodriguez wrote:
> > But then again, come to think of it, why are you doing this anyway?
>
> The goal is to clean up a lot of stuff we forgot to cleanup for
> offchannel operation and in the end to help with multicast/broadcast
> data. This patch just addresses one of the cleanups. The timers kicked
> off when going off channel will not make sense, so best to just deny
> ADDBA when going offchannel.
But this won't actually help in that case -- this problem happens if try
to make a BA just before we go offchannel, and then the timer fires
while we're offchannel. It'll just *very* slightly alter the timing
required to hit it.
> > I'm not convinced of the whole idea, it's all racy. I'm starting to think
> > that this patch won't help anything since we'll still be racy and start
> > BA agreements just before we block,
>
> Establishing the BA agreement is fine, we don't want to cancel
> existing BA agreements when going offchannel, we just want to prevent
> making the timers for new ADDBA requests from going stale
> unnecessarily.
See above though.
> > _and_ if we're a station and going off-channel we'll be going into powersave
> > which means we won't actually get the addBA frame until we return.
>
> There's a race between trying to go offchannel, sending the nullfunc
> and switching channels. When the race hits the ADDBA timer will just
> go stale. If our goal is to go offchannel we should avoid the race by
> simply denying new ADDBA requests. I just noticed that we can't
> possible receive ADDBA requests when we are scanning though, since
> ieee80211_iface_work() already has a check and bail out for
> local->scanning, but note that local->scanning will not be checked
> when doing other offchannel work.
>
> So perhaps there is another way we can deal with this for the
> non-scanning offchannel work case that might also take care of not
> handling other queued up management frames when offchannel.
I think we need to treat TX and RX BA differently.
For TX BA, the best idea would probably be to actually make it _use_ the
work infrastructure -- after we change that to not actually stop all the
things it's doing when the channel is the operating channel, or so.
johannes
^ permalink raw reply
* [GITT PULL] AT91 for 2.6.37 merge window
From: Nicolas Ferre @ 2010-10-07 17:55 UTC (permalink / raw)
To: Russell King - ARM Linux, davem
Cc: Andrew Victor, Jean-Christophe PLAGNIOL-VILLARD,
'linux-arm-kernel@lists.infradead.org', Linux Kernel list,
gerg, Hans-Christian Egtvedt
Hi Russell,
Could you please pull the following:
git://github.com/at91linux/linux-2.6-at91.git for_rmk
This contains AT91 update for 2.6.37 merge window. All has been discussed on
the list.
It if based on linus' tree 2.6.36-rc7 commit cb655d0f3d57c23db51b981648e452988c0223f9
David,
The tiny patch that affects "drivers/net/Kconfig" is pending since beginning of August, I propose to include it through ARM tree as it should not create any merging issue.
Greg Ungerer (1):
AT91: fix use of clock disable on idle for AT91x40 devices
Jean-Christophe PLAGNIOL-VILLARD (3):
AT91: at91sam9m10g45ek: use the right machine id
AT91: at91sam9g20ek: merge 2mmc version in one board
net: atmel_macb Kconfig: remove long dependency line
Nicolas Ferre (1):
AT91: Correct configuration define value
arch/arm/configs/at91sam9g20ek_defconfig | 1 +
arch/arm/mach-at91/Kconfig | 9 +-
arch/arm/mach-at91/Makefile | 3 +-
arch/arm/mach-at91/board-at572d940hf_ek.c | 2 +-
arch/arm/mach-at91/board-sam9g20ek-2slot-mmc.c | 329 ------------------------
arch/arm/mach-at91/board-sam9g20ek.c | 74 +++++-
arch/arm/mach-at91/board-sam9m10g45ek.c | 4 +-
arch/arm/mach-at91/include/mach/at91x40.h | 6 +
arch/arm/mach-at91/include/mach/system.h | 4 +
arch/avr32/Kconfig | 1 +
drivers/net/Kconfig | 5 +-
11 files changed, 95 insertions(+), 343 deletions(-)
delete mode 100644 arch/arm/mach-at91/board-sam9g20ek-2slot-mmc.c
Thanks a lot, best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] usb: gadget: langwell_udc: Fix error path
From: Greg KH @ 2010-10-07 17:51 UTC (permalink / raw)
To: Rahul Ruikar
Cc: David Brownell, Greg Kroah-Hartman, Joe Perches, linux-usb,
linux-kernel
In-Reply-To: <1286423526-2777-1-git-send-email-rahul.ruikar@gmail.com>
On Thu, Oct 07, 2010 at 09:22:06AM +0530, Rahul Ruikar wrote:
> Fix for following cases
> - Call device_unregister() only when device_register() succeeds.
> - Call put_device() when device_register() fails.
> - Call device_remove_file() only when device_create_file() succeeds.
>
> Signed-off-by: Rahul Ruikar <rahul.ruikar@gmail.com>
> ---
> drivers/usb/gadget/langwell_udc.c | 14 +++++++++++---
> drivers/usb/gadget/langwell_udc.h | 4 +++-
> 2 files changed, 14 insertions(+), 4 deletions(-)
This patch doesn't apply at all to my tree. Can you redo it against the
latest linux-next release?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] ACPI: Read TSC upon resume
From: Greg KH @ 2010-10-07 17:46 UTC (permalink / raw)
To: Sameer Nanda; +Cc: lenb, stefan.bader, brad.figg, apw, linux-acpi, linux-kernel
In-Reply-To: <AANLkTimE2h46iZkj_amvgUg5UwN9xjuwqdW5TB+XccYy@mail.gmail.com>
On Thu, Oct 07, 2010 at 10:43:34AM -0700, Sameer Nanda wrote:
> On Wed, Oct 6, 2010 at 7:19 PM, Greg KH <gregkh@suse.de> wrote:
> > And are you always going to be printing this out? Why do we want to
> > know this every time?
> >
>
> Yes, every time. This helps track variance in BIOS resume times within a
> single boot.
Is that really something that users can do something about? I can
understand when you are trying to work with a BIOS company, but
otherwise, this seems quite pointless.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
From: Steve Sakoman @ 2010-10-07 17:56 UTC (permalink / raw)
To: Madhusudhan
Cc: Mike Rapoport, David Vrabel, Chris Ball, linux-mmc, linux-omap,
Adrian Hunter
In-Reply-To: <B02FD62E0C9F4E70856C21355A0BAB59@am.dhcp.ti.com>
On Thu, Oct 7, 2010 at 9:52 AM, Madhusudhan <madhu.cr@ti.com> wrote:
>
>> -----Original Message-----
>> From: Steve Sakoman [mailto:sakoman@gmail.com]
>> Sent: Thursday, October 07, 2010 8:57 AM
>> To: Mike Rapoport
>> Cc: Madhusudhan Chikkature; David Vrabel; Chris Ball; linux-
>> mmc@vger.kernel.org; linux-omap@vger.kernel.org; Adrian Hunter
>> Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
>>
>> On Thu, Oct 7, 2010 at 12:15 AM, Mike Rapoport <mike@compulab.co.il>
>> wrote:
>> > Hi Madhu,
>> >
>> > Madhusudhan Chikkature wrote:
>> >>
>> >> <snip>
>> >>
>> >>> You are correct! The version of the patch in the repo indeed has
>> >>> 'out' in the wrong place and generates a compile error.
>> >>>
>> >>> Could you post the patch you are using and I will try to reproduce
>> >>> what you are seeing on my hardware? Best we all work from exactly the
>> >>> same patch!
>> >>>
>> >>> Steve
>> >>>
>> >>
>> >> Yes. I think that check breaking the compilation is not needed. How
>> about
>> >> the
>> >> below version? It just removes that check.
>> >>
>> >> This version should apply fine on the latest kernel. I did a sanity
>> test
>> >> of
>> >> MMC/SD cards on OMAP4 SDP.
>> >>
>> >> Steve or Mike can check if SDIO interrupts are working.
>> >
>> > With you patch I get the same:
>> >
>> > libertas_sdio: Libertas SDIO driver
>> > libertas_sdio: Copyright Pierre Ossman
>> > libertas: command 0x0003 timed out
>> > libertas: Timeout submitting command 0x0003
>> > libertas: PREP_CMD: command 0x0003 failed: -110
>> > libertas_sdio: probe of mmc1:0001:1 failed with error -110
>>
>> I can confirm exactly the same behavior on my hardware with this
>> version of the patch.
>>
>
> Steve,
>
> Okay. Did the version you had in your tree worked? I just want to check if I
> messed up something in my patch.
No, it didn't. Operator error -- I was "testing" a version without
the patch applied :-) When applied it acts the same as your version.
Steve
^ permalink raw reply
* [GITT PULL] AT91 for 2.6.37 merge window
From: Nicolas Ferre @ 2010-10-07 17:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
Could you please pull the following:
git://github.com/at91linux/linux-2.6-at91.git for_rmk
This contains AT91 update for 2.6.37 merge window. All has been discussed on
the list.
It if based on linus' tree 2.6.36-rc7 commit cb655d0f3d57c23db51b981648e452988c0223f9
David,
The tiny patch that affects "drivers/net/Kconfig" is pending since beginning of August, I propose to include it through ARM tree as it should not create any merging issue.
Greg Ungerer (1):
AT91: fix use of clock disable on idle for AT91x40 devices
Jean-Christophe PLAGNIOL-VILLARD (3):
AT91: at91sam9m10g45ek: use the right machine id
AT91: at91sam9g20ek: merge 2mmc version in one board
net: atmel_macb Kconfig: remove long dependency line
Nicolas Ferre (1):
AT91: Correct configuration define value
arch/arm/configs/at91sam9g20ek_defconfig | 1 +
arch/arm/mach-at91/Kconfig | 9 +-
arch/arm/mach-at91/Makefile | 3 +-
arch/arm/mach-at91/board-at572d940hf_ek.c | 2 +-
arch/arm/mach-at91/board-sam9g20ek-2slot-mmc.c | 329 ------------------------
arch/arm/mach-at91/board-sam9g20ek.c | 74 +++++-
arch/arm/mach-at91/board-sam9m10g45ek.c | 4 +-
arch/arm/mach-at91/include/mach/at91x40.h | 6 +
arch/arm/mach-at91/include/mach/system.h | 4 +
arch/avr32/Kconfig | 1 +
drivers/net/Kconfig | 5 +-
11 files changed, 95 insertions(+), 343 deletions(-)
delete mode 100644 arch/arm/mach-at91/board-sam9g20ek-2slot-mmc.c
Thanks a lot, best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 03/11] eepro100: initialize a variable in all cases
From: Blue Swirl @ 2010-10-07 17:54 UTC (permalink / raw)
To: Markus Armbruster; +Cc: qemu-devel
In-Reply-To: <m339siqrh7.fsf@blackfin.pond.sub.org>
On Thu, Oct 7, 2010 at 9:31 AM, Markus Armbruster <armbru@redhat.com> wrote:
> Blue Swirl <blauwirbel@gmail.com> writes:
>
>> Compiling with GCC 4.6.0 20100925 produced warnings:
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read4':
>> /src/qemu/hw/eepro100.c:1351:14: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read2':
>> /src/qemu/hw/eepro100.c:1328:14: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read1':
>> /src/qemu/hw/eepro100.c:1285:13: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>>
>> Fix by initializing 'val' at start.
>
> I'm worried this sweeps bugs under the carpet.
>
> When addr is out of bounds, these function return garbage. Your patch
> makes them return 0 instead. Can that happen? Shouldn't we catch and
> flag it?
0 is a nice default value.
Adding an assert is not OK, guest shouldn't be able to terminate QEMU.
Adding a check which spams stdio is not so nice either.
I think it's even impossible with current QEMU for addr to be out of
bounds, the area is registered with size PCI_MEM_SIZE.
^ permalink raw reply
* [PATCH] Make it possible to set a uuid if one was not set during DM_DEV_CREATE.
From: Peter Jones @ 2010-10-07 17:54 UTC (permalink / raw)
To: dm-devel; +Cc: Peter Jones
This makes it possible to use DM_DEV_RENAME to add a uuid to a device so
long as one has not been previously set either with DM_DEV_CREATE or
with DM_DEV_RENAME.
---
drivers/md/dm-ioctl.c | 113 ++++++++++++++++++++++++++++++++-------------
include/linux/dm-ioctl.h | 5 ++
2 files changed, 85 insertions(+), 33 deletions(-)
diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index 3e39193..bd76846 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -298,7 +298,7 @@ retry:
static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
const char *new)
{
- char *new_name, *old_name;
+ char *new_data, *old_data;
struct hash_cell *hc;
struct dm_table *table;
struct mapped_device *md;
@@ -306,8 +306,8 @@ static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
/*
* duplicate new.
*/
- new_name = kstrdup(new, GFP_KERNEL);
- if (!new_name)
+ new_data = kstrdup(new, GFP_KERNEL);
+ if (!new_data)
return ERR_PTR(-ENOMEM);
down_write(&_hash_lock);
@@ -315,14 +315,28 @@ static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
/*
* Is new free ?
*/
- hc = __get_name_cell(new);
- if (hc) {
- DMWARN("asked to rename to an already-existing name %s -> %s",
- param->name, new);
- dm_put(hc->md);
- up_write(&_hash_lock);
- kfree(new_name);
- return ERR_PTR(-EBUSY);
+ if (param->flags & DM_NEW_UUID_FLAG) {
+ hc = __get_uuid_cell(new);
+ if (hc) {
+ DMWARN("asked to change uuid to an already-existing uuid"
+ " %s -> %s",
+ param->name, new);
+ dm_put(hc->md);
+ up_write(&_hash_lock);
+ kfree(new_data);
+ return ERR_PTR(-EBUSY);
+ }
+ } else {
+ hc = __get_name_cell(new);
+ if (hc) {
+ DMWARN("asked to rename to an already-existing name "
+ "%s -> %s",
+ param->name, new);
+ dm_put(hc->md);
+ up_write(&_hash_lock);
+ kfree(new_data);
+ return ERR_PTR(-EBUSY);
+ }
}
/*
@@ -333,19 +347,42 @@ static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
DMWARN("asked to rename a non-existent device %s -> %s",
param->name, new);
up_write(&_hash_lock);
- kfree(new_name);
+ kfree(new_data);
return ERR_PTR(-ENXIO);
}
- /*
- * rename and move the name cell.
- */
- list_del(&hc->name_list);
- old_name = hc->name;
- mutex_lock(&dm_hash_cells_mutex);
- hc->name = new_name;
- mutex_unlock(&dm_hash_cells_mutex);
- list_add(&hc->name_list, _name_buckets + hash_str(new_name));
+ if (param->flags & DM_NEW_UUID_FLAG) {
+ /*
+ * Does this device already have a uuid?
+ */
+ if (hc->uuid) {
+ DMWARN("asked to change uuid of device with uuid "
+ "already set %s %s -> %s",
+ param->name, hc->uuid, param->uuid);
+ up_write(&_hash_lock);
+ kfree(new_uuid);
+ return ERR_PTR(-EINVAL);
+ }
+ /*
+ * reuuid and move the uuid cell.
+ */
+ list_del(&hc->uuid_list);
+ old_data = hc->uuid;
+ mutex_lock(&dm_hash_cells_mutex);
+ hc->uuid = new_data;
+ mutex_unlock(&dm_hash_cells_mutex);
+ list_add(&hc->uuid_list, _uuid_buckets + hash_str(new_data));
+ } else {
+ /*
+ * rename and move the name cell.
+ */
+ list_del(&hc->name_list);
+ old_data = hc->name;
+ mutex_lock(&dm_hash_cells_mutex);
+ hc->name = new_data;
+ mutex_unlock(&dm_hash_cells_mutex);
+ list_add(&hc->name_list, _name_buckets + hash_str(new_data));
+ }
/*
* Wake up any dm event waiters.
@@ -361,7 +398,7 @@ static struct mapped_device *dm_hash_rename(struct dm_ioctl *param,
md = hc->md;
up_write(&_hash_lock);
- kfree(old_name);
+ kfree(old_data);
return md;
}
@@ -774,21 +811,31 @@ static int invalid_str(char *str, void *end)
static int dev_rename(struct dm_ioctl *param, size_t param_size)
{
int r;
- char *new_name = (char *) param + param->data_start;
+ char *new_data = (char *) param + param->data_start;
struct mapped_device *md;
- if (new_name < param->data ||
- invalid_str(new_name, (void *) param + param_size) ||
- strlen(new_name) > DM_NAME_LEN - 1) {
- DMWARN("Invalid new logical volume name supplied.");
- return -EINVAL;
- }
+ if (param->flags & DM_NEW_UUID_FLAG) {
+ struct hash_cell *hc;
+ if (new_data < param->data ||
+ invalid_str(new_data, (void *) param + param_size) ||
+ strlen(new_data) > DM_UUID_LEN - 1) {
+ DMWARN("Invalid new logical volume uuid supplied.");
+ return -EINVAL;
+ }
+ } else {
+ if (new_data < param->data ||
+ invalid_str(new_data, (void *) param + param_size) ||
+ strlen(new_data) > DM_NAME_LEN - 1) {
+ DMWARN("Invalid new logical volume name supplied.");
+ return -EINVAL;
+ }
- r = check_name(new_name);
- if (r)
- return r;
+ r = check_name(new_data);
+ if (r)
+ return r;
+ }
- md = dm_hash_rename(param, new_name);
+ md = dm_hash_rename(param, new_data);
if (IS_ERR(md))
return PTR_ERR(md);
diff --git a/include/linux/dm-ioctl.h b/include/linux/dm-ioctl.h
index 49eab36..8f1a610 100644
--- a/include/linux/dm-ioctl.h
+++ b/include/linux/dm-ioctl.h
@@ -322,4 +322,9 @@ enum {
*/
#define DM_UEVENT_GENERATED_FLAG (1 << 13) /* Out */
+/*
+ * If set, rename operates on uuid, not name.
+ */
+#define DM_NEW_UUID_FLAG (1 << 14) /* In */
+
#endif /* _LINUX_DM_IOCTL_H */
--
1.7.2.2
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 03/11] eepro100: initialize a variable in all cases
From: Stefan Weil @ 2010-10-07 17:54 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Blue Swirl, qemu-devel
In-Reply-To: <m339siqrh7.fsf@blackfin.pond.sub.org>
Am 07.10.2010 11:31, schrieb Markus Armbruster:
> Blue Swirl <blauwirbel@gmail.com> writes:
>
>> Compiling with GCC 4.6.0 20100925 produced warnings:
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read4':
>> /src/qemu/hw/eepro100.c:1351:14: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read2':
>> /src/qemu/hw/eepro100.c:1328:14: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>> /src/qemu/hw/eepro100.c: In function 'eepro100_read1':
>> /src/qemu/hw/eepro100.c:1285:13: error: 'val' may be used
>> uninitialized in this function [-Werror=uninitialized]
>>
>> Fix by initializing 'val' at start.
>
> I'm worried this sweeps bugs under the carpet.
>
> When addr is out of bounds, these function return garbage. Your patch
> makes them return 0 instead. Can that happen? Shouldn't we catch and
> flag it?
We should.
I'll test new code which uses an assertion instead of the if statements,
so a new patch might be ready until end of next week.
Blue Swirl's patch does no harm, so it could be applied
nevertheless if compiler warnings should be fixed now
(I had the same kind of patch in my queue).
Stefan
^ permalink raw reply
* Re: server 4.1 issues list
From: J. Bruce Fields @ 2010-10-07 17:54 UTC (permalink / raw)
To: linux-nfs
In-Reply-To: <20101007155306.GA28053@fieldses.org>
On Thu, Oct 07, 2010 at 11:53:06AM -0400, bfields wrote:
> Someone also asked whether we've fixed the backchannel attribute
> checking. We haven't, but that should be fairly quick--I'll take a look
> at it now.
Actually there's a bit of tedious arithmetic to do here to figure out
what we need e.g. for the maximum request size. I'm setting this aside
for now, so this is up for grabs.
--b.
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 6233917..0f8e90b 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1493,6 +1493,23 @@ nfsd4_replay_create_session(struct nfsd4_create_session *cr_ses,
return slot->sl_status;
}
+static __be32 verify_backchannel_attributes(struct nfsd4_create_session *cr_ses)
+{
+ struct nfsd4_channel_attrs *attrs;
+
+ if (!cses->flags & SESSION4_BACK_CHAN)
+ return nfs_ok;
+ if (attrs.maxreqs < 1)
+ return nfserr_inval;
+ /* XXX: check other fields here; see
+ * http://tools.ietf.org/search/rfc5661#section-18.36 to
+ * determine when we can modify the fields to be acceptable, and
+ * when we must return inval. We'll need to figure out the
+ * things like how large a callback request we need to be able to
+ * send. */
+ return nfs_ok;
+}
+
__be32
nfsd4_create_session(struct svc_rqst *rqstp,
struct nfsd4_compound_state *cstate,
@@ -1553,6 +1570,9 @@ nfsd4_create_session(struct svc_rqst *rqstp,
cr_ses->flags &= ~SESSION4_PERSIST;
cr_ses->flags &= ~SESSION4_RDMA;
+ status = verify_backchannel_attributes(cr_ses);
+ if (status)
+ goto out;
status = nfserr_jukebox;
new = alloc_init_session(rqstp, conf, cr_ses);
if (!new)
^ permalink raw reply related
* Re: [PATCH v6 06/12] Add PV MSR to enable asynchronous page faults delivery.
From: Gleb Natapov @ 2010-10-07 17:53 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CADC01E.3060409@redhat.com>
On Thu, Oct 07, 2010 at 02:42:06PM +0200, Avi Kivity wrote:
> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >Guest enables async PF vcpu functionality using this MSR.
> >
> > return NON_PRESENT;
> >+
> >+MSR_KVM_ASYNC_PF_EN: 0x4b564d02
> >+ data: Bits 63-6 hold 64-byte aligned physical address of a 32bit memory
>
> Given that it must be aligned anyway, we can require it to be a
> 64-byte region and also require that the guest zero it before
> writing the MSR. That will give us a little more flexibility in the
> future.
>
No code change needed, so OK.
> >+ area which must be in guest RAM. Bits 5-1 are reserved and should be
> >+ zero. Bit 0 is 1 when asynchronous page faults are enabled on the vcpu
> >+ 0 when disabled.
> >+
> >+ Physical address points to 32 bit memory location that will be written
> >+ to by the hypervisor at the time of asynchronous page fault injection to
> >+ indicate type of asynchronous page fault. Value of 1 means that the page
> >+ referred to by the page fault is not present. Value 2 means that the
> >+ page is now available.
> >diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> >index b9f263e..de31551 100644
> >--- a/arch/x86/include/asm/kvm_host.h
> >+++ b/arch/x86/include/asm/kvm_host.h
> >@@ -417,6 +417,8 @@ struct kvm_vcpu_arch {
> >
> > struct {
> > gfn_t gfns[roundup_pow_of_two(ASYNC_PF_PER_VCPU)];
> >+ struct gfn_to_hva_cache data;
> >+ u64 msr_val;
> > } apf;
> > };
> >
> >diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> >index e3faaaf..8662ae0 100644
> >--- a/arch/x86/include/asm/kvm_para.h
> >+++ b/arch/x86/include/asm/kvm_para.h
> >@@ -20,6 +20,7 @@
> > * are available. The use of 0x11 and 0x12 is deprecated
> > */
> > #define KVM_FEATURE_CLOCKSOURCE2 3
> >+#define KVM_FEATURE_ASYNC_PF 4
> >
> > /* The last 8 bits are used to indicate how to interpret the flags field
> > * in pvclock structure. If no bits are set, all flags are ignored.
> >@@ -32,9 +33,12 @@
> > /* Custom MSRs falls in the range 0x4b564d00-0x4b564dff */
> > #define MSR_KVM_WALL_CLOCK_NEW 0x4b564d00
> > #define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
> >+#define MSR_KVM_ASYNC_PF_EN 0x4b564d02
> >
> > #define KVM_MAX_MMU_OP_BATCH 32
> >
> >+#define KVM_ASYNC_PF_ENABLED (1<< 0)
> >+
> > /* Operations for KVM_HC_MMU_OP */
> > #define KVM_MMU_OP_WRITE_PTE 1
> > #define KVM_MMU_OP_FLUSH_TLB 2
> >diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> >index 48fd59d..3e123ab 100644
> >--- a/arch/x86/kvm/x86.c
> >+++ b/arch/x86/kvm/x86.c
> >@@ -782,12 +782,12 @@ EXPORT_SYMBOL_GPL(kvm_get_dr);
> > * kvm-specific. Those are put in the beginning of the list.
> > */
> >
> >-#define KVM_SAVE_MSRS_BEGIN 7
> >+#define KVM_SAVE_MSRS_BEGIN 8
> > static u32 msrs_to_save[] = {
> > MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
> > MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
> > HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
> >- HV_X64_MSR_APIC_ASSIST_PAGE,
> >+ HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN,
> > MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
> > MSR_STAR,
> > #ifdef CONFIG_X86_64
> >@@ -1425,6 +1425,29 @@ static int set_msr_hyperv(struct kvm_vcpu *vcpu, u32 msr, u64 data)
> > return 0;
> > }
> >
> >+static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data)
> >+{
> >+ gpa_t gpa = data& ~0x3f;
> >+
> >+ /* Bits 1:5 are resrved, Should be zero */
> >+ if (data& 0x3e)
> >+ return 1;
> >+
> >+ vcpu->arch.apf.msr_val = data;
> >+
> >+ if (!(data& KVM_ASYNC_PF_ENABLED)) {
> >+ kvm_clear_async_pf_completion_queue(vcpu);
>
> May be a lengthy synchronous operation. I guess we don't care.
>
> >+ memset(vcpu->arch.apf.gfns, 0xff, sizeof vcpu->arch.apf.gfns);
>
> That memset again.
>
> >+ return 0;
> >+ }
> >+
> >+ if (kvm_gfn_to_hva_cache_init(vcpu->kvm,&vcpu->arch.apf.data, gpa))
> >+ return 1;
>
> Note: we need to handle the memory being removed from underneath
> kvm_gfn_to_hve_cache(). Given that, we can just make
> kvm_gfn_to_hva_cache_init() return void. "success" means nothing
> when future changes can invalidate it.
>
I want to catch guest doing stupid things. If guest give us non-existent
address I want wrmsr to #GP.
> >+
> >+ kvm_async_pf_wakeup_all(vcpu);
>
> Why is this needed? If all apfs are flushed at disable time, what
> do we need to wake up?
For migration. Destination will rewrite msr and all processes will be
waked up.
>
> Need to list the MSR for save/restore/reset.
>
>
This patch adds it to msrs_to_save, no?
--
Gleb.
^ permalink raw reply
* Re: git log doesn't allow %x00 in custom format anymore?
From: Jeff King @ 2010-10-07 17:53 UTC (permalink / raw)
To: Matthieu Moy; +Cc: kusmabite, Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <vpqaamp3n6d.fsf@bauges.imag.fr>
On Thu, Oct 07, 2010 at 07:52:42PM +0200, Matthieu Moy wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
> > Also, fwriting like that to stdout might be a bit troublesome on
> > Windows because the string won't end up going through our
> > ANSI-emulation.
>
> I don't know which one would be most portable, but if fwrite is the
> problem, then
>
> printf("%*s%c", buf.buf, buf.len, info->hdr_termination);
>
> should do the trick.
It does work, but you have to cast the buf.len size_t to an int.
-Peff
^ permalink raw reply
* Re: [PATCH v6 06/12] Add PV MSR to enable asynchronous page faults delivery.
From: Gleb Natapov @ 2010-10-07 17:53 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, linux-mm, linux-kernel, mingo, a.p.zijlstra, tglx, hpa, riel,
cl, mtosatti
In-Reply-To: <4CADC01E.3060409@redhat.com>
On Thu, Oct 07, 2010 at 02:42:06PM +0200, Avi Kivity wrote:
> On 10/04/2010 05:56 PM, Gleb Natapov wrote:
> >Guest enables async PF vcpu functionality using this MSR.
> >
> > return NON_PRESENT;
> >+
> >+MSR_KVM_ASYNC_PF_EN: 0x4b564d02
> >+ data: Bits 63-6 hold 64-byte aligned physical address of a 32bit memory
>
> Given that it must be aligned anyway, we can require it to be a
> 64-byte region and also require that the guest zero it before
> writing the MSR. That will give us a little more flexibility in the
> future.
>
No code change needed, so OK.
> >+ area which must be in guest RAM. Bits 5-1 are reserved and should be
> >+ zero. Bit 0 is 1 when asynchronous page faults are enabled on the vcpu
> >+ 0 when disabled.
> >+
> >+ Physical address points to 32 bit memory location that will be written
> >+ to by the hypervisor at the time of asynchronous page fault injection to
> >+ indicate type of asynchronous page fault. Value of 1 means that the page
> >+ referred to by the page fault is not present. Value 2 means that the
> >+ page is now available.
> >diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> >index b9f263e..de31551 100644
> >--- a/arch/x86/include/asm/kvm_host.h
> >+++ b/arch/x86/include/asm/kvm_host.h
> >@@ -417,6 +417,8 @@ struct kvm_vcpu_arch {
> >
> > struct {
> > gfn_t gfns[roundup_pow_of_two(ASYNC_PF_PER_VCPU)];
> >+ struct gfn_to_hva_cache data;
> >+ u64 msr_val;
> > } apf;
> > };
> >
> >diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> >index e3faaaf..8662ae0 100644
> >--- a/arch/x86/include/asm/kvm_para.h
> >+++ b/arch/x86/include/asm/kvm_para.h
> >@@ -20,6 +20,7 @@
> > * are available. The use of 0x11 and 0x12 is deprecated
> > */
> > #define KVM_FEATURE_CLOCKSOURCE2 3
> >+#define KVM_FEATURE_ASYNC_PF 4
> >
> > /* The last 8 bits are used to indicate how to interpret the flags field
> > * in pvclock structure. If no bits are set, all flags are ignored.
> >@@ -32,9 +33,12 @@
> > /* Custom MSRs falls in the range 0x4b564d00-0x4b564dff */
> > #define MSR_KVM_WALL_CLOCK_NEW 0x4b564d00
> > #define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
> >+#define MSR_KVM_ASYNC_PF_EN 0x4b564d02
> >
> > #define KVM_MAX_MMU_OP_BATCH 32
> >
> >+#define KVM_ASYNC_PF_ENABLED (1<< 0)
> >+
> > /* Operations for KVM_HC_MMU_OP */
> > #define KVM_MMU_OP_WRITE_PTE 1
> > #define KVM_MMU_OP_FLUSH_TLB 2
> >diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> >index 48fd59d..3e123ab 100644
> >--- a/arch/x86/kvm/x86.c
> >+++ b/arch/x86/kvm/x86.c
> >@@ -782,12 +782,12 @@ EXPORT_SYMBOL_GPL(kvm_get_dr);
> > * kvm-specific. Those are put in the beginning of the list.
> > */
> >
> >-#define KVM_SAVE_MSRS_BEGIN 7
> >+#define KVM_SAVE_MSRS_BEGIN 8
> > static u32 msrs_to_save[] = {
> > MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
> > MSR_KVM_SYSTEM_TIME_NEW, MSR_KVM_WALL_CLOCK_NEW,
> > HV_X64_MSR_GUEST_OS_ID, HV_X64_MSR_HYPERCALL,
> >- HV_X64_MSR_APIC_ASSIST_PAGE,
> >+ HV_X64_MSR_APIC_ASSIST_PAGE, MSR_KVM_ASYNC_PF_EN,
> > MSR_IA32_SYSENTER_CS, MSR_IA32_SYSENTER_ESP, MSR_IA32_SYSENTER_EIP,
> > MSR_STAR,
> > #ifdef CONFIG_X86_64
> >@@ -1425,6 +1425,29 @@ static int set_msr_hyperv(struct kvm_vcpu *vcpu, u32 msr, u64 data)
> > return 0;
> > }
> >
> >+static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data)
> >+{
> >+ gpa_t gpa = data& ~0x3f;
> >+
> >+ /* Bits 1:5 are resrved, Should be zero */
> >+ if (data& 0x3e)
> >+ return 1;
> >+
> >+ vcpu->arch.apf.msr_val = data;
> >+
> >+ if (!(data& KVM_ASYNC_PF_ENABLED)) {
> >+ kvm_clear_async_pf_completion_queue(vcpu);
>
> May be a lengthy synchronous operation. I guess we don't care.
>
> >+ memset(vcpu->arch.apf.gfns, 0xff, sizeof vcpu->arch.apf.gfns);
>
> That memset again.
>
> >+ return 0;
> >+ }
> >+
> >+ if (kvm_gfn_to_hva_cache_init(vcpu->kvm,&vcpu->arch.apf.data, gpa))
> >+ return 1;
>
> Note: we need to handle the memory being removed from underneath
> kvm_gfn_to_hve_cache(). Given that, we can just make
> kvm_gfn_to_hva_cache_init() return void. "success" means nothing
> when future changes can invalidate it.
>
I want to catch guest doing stupid things. If guest give us non-existent
address I want wrmsr to #GP.
> >+
> >+ kvm_async_pf_wakeup_all(vcpu);
>
> Why is this needed? If all apfs are flushed at disable time, what
> do we need to wake up?
For migration. Destination will rewrite msr and all processes will be
waked up.
>
> Need to list the MSR for save/restore/reset.
>
>
This patch adds it to msrs_to_save, no?
--
Gleb.
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: git log doesn't allow %x00 in custom format anymore?
From: Matthieu Moy @ 2010-10-07 17:52 UTC (permalink / raw)
To: kusmabite; +Cc: Jeff King, Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <AANLkTimYVNNjhaqUHjoVOV-fQBhcENKn7cyj10qcZ+MW@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> Also, fwriting like that to stdout might be a bit troublesome on
> Windows because the string won't end up going through our
> ANSI-emulation.
I don't know which one would be most portable, but if fwrite is the
problem, then
printf("%*s%c", buf.buf, buf.len, info->hdr_termination);
should do the trick.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 7/7] Add S3C2440 MCI card support
From: Juergen Beisert @ 2010-10-07 17:51 UTC (permalink / raw)
To: barebox
In-Reply-To: <20101007171003.GK28242@pengutronix.de>
Sascha Hauer wrote:
> [...]
> > +#define CLOCKRATE_MIN (1 * 1000 * 1000)
>
> Isn't this a bit high? I thought the initialization frequnency should be
> 400Khz at maximum. Or does the hardware not allow lower rates?
I see you know more about MCI cards than me. This limit is a new fact to me.
Maybe this is the reason why the old 16 MiB MMC fails... will check.
And no: There is *mostly* no limit for the minimal clockrate. I should
calculate it at runtime, because it depends on some other settings in the
clock tree. In the i.MX23 driver I do so already.
> [...]
> > +/**
> > + * Prepare engine's bits for the next command transfer
> > + * @param cmd_flags MCI's command flags
> > + * @param data_flags MCI's data flags
> > + * @return Register bits for this transfer
> > + */
> > +static uint32_t s3c_prepare_command_setup(unsigned cmd_flags, unsigned
> > data_flags) +{
> > + uint32_t reg;
> > +
> > + /* source (=host) */
> > + reg = SDICMDCON_SENDERHOST;
> > +
> > + if (cmd_flags & MMC_RSP_PRESENT) {
> > + reg |= SDICMDCON_WAITRSP;
> > + pr_debug("Command with response\n");
> > + }
> > + if (cmd_flags & MMC_RSP_136) {
> > + reg |= SDICMDCON_LONGRSP;
> > + pr_debug("Command with long response\n");
> > + }
> > + if (cmd_flags & MMC_RSP_CRC)
> > + ; /* FIXME */
> > + if (cmd_flags & MMC_RSP_BUSY)
> > + ; /* FIXME */
> > + if (cmd_flags & MMC_RSP_OPCODE)
> > + ; /* FIXME */
>
> It's ok that these flags are not handled in the first run, but I think
> the driver should issue a warning when one of these flags is set.
I'm still not sure what bits to set in the various registers to match these
settings. So, a warning would be a good idea.
> [...]
jbe
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | Phone: +49-8766-939 228 |
Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Gustavo F. Padovan @ 2010-10-07 17:51 UTC (permalink / raw)
To: Greg KH
Cc: Marcel Holtmann, pavan-savoy, linux-bluetooth, johan.hedberg,
linux-kernel, Pavan Savoy
In-Reply-To: <20101007143409.GB14913@kroah.com>
Hi Greg,
* Greg KH <greg@kroah.com> [2010-10-07 07:34:09 -0700]:
> On Thu, Oct 07, 2010 at 12:05:48PM +0200, Marcel Holtmann wrote:
> > Hi Pavan,
> >
> > > This is the bluetooth protocol driver for the TI WiLink7 chipsets.
> > > Texas Instrument's WiLink chipsets combine wireless technologies
> > > like BT, FM, GPS and WLAN onto a single chip.
> > >
> > > This Bluetooth driver works on top of the TI_ST shared transport
> > > line discipline driver which also allows other drivers like
> > > FM V4L2 and GPS character driver to make use of the same UART interface.
> > >
> > > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > > ---
> > > drivers/bluetooth/bt_ti.c | 463 ++++++++++++++++++++++++++++++++++++
> > > drivers/staging/ti-st/bt_drv.c | 509 ----------------------------------------
> > > drivers/staging/ti-st/bt_drv.h | 61 -----
> > > 3 files changed, 463 insertions(+), 570 deletions(-)
> > > create mode 100644 drivers/bluetooth/bt_ti.c
> > > delete mode 100644 drivers/staging/ti-st/bt_drv.c
> > > delete mode 100644 drivers/staging/ti-st/bt_drv.h
> >
> > I don't care about staging at all. So you sort that out with Greg.
> >
> > Submit your driver for upstream inclusion. And once accepted you can pin
> > Greg about removing it.
>
> The driver is already in staging, this is the request to move it out of
> staging and into the "correct" place in the tree. The core of the ti-st
> code is now in the drivers/misc/ directory in the linux-next tree, and
> this patch is the request to move the bluetooth drive into the proper
> drivers/bluetooth/ location.
I'm wondering why this driver never touched linux-bluetooth before. It
is on staging because it is not ready for a proper merge and while it is
not ready it needs the comments from the bluetooth developers here to
get it ready for merge in drivers/bluetooth. So why this never arrived
here before?
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: updating the source tree
From: Pekka Paalanen @ 2010-10-07 17:51 UTC (permalink / raw)
To: Grzesiek Sójka; +Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <4CAE04AB.9070202-t9zbU3WrWHI@public.gmane.org>
On Thu, 07 Oct 2010 19:34:35 +0200
Grzesiek Sójka <pld-t9zbU3WrWHI@public.gmane.org> wrote:
> Hi there,
>
> I downloaded the nouveau/linux-2.6 using the following:
> git clone --depth 1
> git://anongit.freedesktop.org/nouveau/linux-2.6 Is there an easy
> way to update it to the current version (reversing all the
> changes I made) without downloading all the files again??
Yes, this should work:
http://nouveau.freedesktop.org/wiki/InstallDRM#UpdatingtheNouveaukernelgitrepository
That is, to fetch updates:
$ git remote update
and to reset your current checkout to nouveau/master:
$ git reset --hard origin/master
That should discard all commits and local changes you may have made.
It will not remove temporary files or compilation results.
--
Pekka Paalanen
http://www.iki.fi/pq/
^ permalink raw reply
* Re: [RFC PATCH] poll(): add poll_wait_set_exclusive()
From: Steven Rostedt @ 2010-10-07 17:51 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Linus Torvalds, LKML, Andrew Morton, Peter Zijlstra, Ingo Molnar,
Frederic Weisbecker, Thomas Gleixner, Christoph Hellwig, Li Zefan,
Lai Jiangshan, Johannes Berg, Masami Hiramatsu,
Arnaldo Carvalho de Melo, Tom Zanussi, KOSAKI Motohiro,
Andi Kleen, Paul E. McKenney
In-Reply-To: <20101007170716.GB799@Krystal>
On Thu, 2010-10-07 at 13:07 -0400, Mathieu Desnoyers wrote:
> * Steven Rostedt (rostedt@goodmis.org) wrote:
> > On Wed, 2010-10-06 at 15:04 -0400, Mathieu Desnoyers wrote:
> >
> > > For reference, here is the use-case: The user-space daemon runs typically one
> > > thread per cpu, each with a handle on many file descriptors. Each thread waits
> > > for data to be available using poll(). In order to follow the poll semantic,
> > > when data becomes available on a file descriptor, the kernel wakes up all
> > > threads at once, but in my case only one of them will successfully consume the
> > > data (all other thread's splice or read will fail with -ENODATA). With many
> > > threads, these useless wakeups add an unwanted overhead and scalability
> > > limitation.
> >
> > Mathieu, I'm curious to why you have multiple threads reading the same
> > fd. Since the threads are per cpu, does the fd handle all CPUs?
>
> The fd is local to a single ring buffer (which is per-cpu, transporting a group
> of events). The threads consuming the file descriptors are approximately per
> cpu, modulo cpu hotplug events, user preferences, etc. I would prefer not to
> make that a strong 1-1 mapping (with affinity and all), because a typical
> tracing scenario is that a single CPU is heavily used by the OS (thus producing
> trace data), while other CPUs are idle, available to pull the data from the
> buffers. Therefore, I strongly prefer not to affine reader threads to their
> "local" buffers in the general case. That being said, it could be kept as an
> option, since it might make sense in some other use-cases, especially with tiny
> buffers, where it makes sense to keep locality of reference in the L2 cache.
I never mention affinity. As with trace-cmd, it assigns a process per
CPU, but those processes can be on any CPU that the scheduler chooses. I
could probably do it with a single process reading all the CPU fds too.
I might add that as an option.
>
> > Or do you have an fd per event per CPU, in which case the threads should just
> > poll off of their own fds.
>
> I have one fd per per-cpu buffer, but there can be many per-cpu buffers, each
> transporting a group of events. Therefore, I don't want to associate one thread
> per event group, because this would be a resource waste. Typically, only a few
> per-cpu buffers will be very active, and others will be very quiet.
Lets not talk about threads, what about fds? I'm wondering why you have
many threads on the same fd?
-- Steve
^ permalink raw reply
* Re: git log doesn't allow %x00 in custom format anymore?
From: Jeff King @ 2010-10-07 17:50 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <AANLkTimYVNNjhaqUHjoVOV-fQBhcENKn7cyj10qcZ+MW@mail.gmail.com>
On Thu, Oct 07, 2010 at 07:41:01PM +0200, Erik Faye-Lund wrote:
> > diff --git a/builtin/rev-list.c b/builtin/rev-list.c
> > index efe9360..3b2dca0 100644
> > --- a/builtin/rev-list.c
> > +++ b/builtin/rev-list.c
> > @@ -147,8 +147,10 @@ static void show_commit(struct commit *commit, void *data)
> > }
> > } else {
> > if (revs->commit_format != CMIT_FMT_USERFORMAT ||
> > - buf.len)
> > - printf("%s%c", buf.buf, info->hdr_termination);
> > + buf.len) {
> > + fwrite(buf.buf, 1, buf.len, stdout);
> > + putchar(info->hdr_termination);
> > + }
> > }
> > strbuf_release(&buf);
> > } else {
>
> This gives me a bit of a deja-vu: 1fb5fdd
>
> Also, fwriting like that to stdout might be a bit troublesome on
> Windows because the string won't end up going through our
> ANSI-emulation.
I don't know enough about the Windows output code paths to comment on
that. But this is almost identical to the fwrite in graph_show_commit
that we use for the "rev-list --graph" show path. If there is a fix, it
needs to be made to both places.
-Peff
^ permalink raw reply
* [PATCH net-next-2.6] sfc: Don't try to set filters with search depths we know won't work
From: Ben Hutchings @ 2010-10-07 17:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
The filter engine will time-out and ignore filters beyond
200-something hops. We also need to avoid infinite loops in
efx_filter_search() when the table is full.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
drivers/net/sfc/filter.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sfc/filter.c b/drivers/net/sfc/filter.c
index abc884d..52cb608 100644
--- a/drivers/net/sfc/filter.c
+++ b/drivers/net/sfc/filter.c
@@ -20,6 +20,12 @@
#define FILTER_CTL_SRCH_FUDGE_WILD 3
#define FILTER_CTL_SRCH_FUDGE_FULL 1
+/* Hard maximum hop limit. Hardware will time-out beyond 200-something.
+ * We also need to avoid infinite loops in efx_filter_search() when the
+ * table is full.
+ */
+#define FILTER_CTL_SRCH_MAX 200
+
struct efx_filter_table {
u32 offset; /* address of table relative to BAR */
unsigned size; /* number of entries */
@@ -183,7 +189,8 @@ static int efx_filter_search(struct efx_filter_table *table,
incr = efx_filter_increment(key);
for (depth = 1, filter_idx = hash & (table->size - 1);
- test_bit(filter_idx, table->used_bitmap);
+ depth <= FILTER_CTL_SRCH_MAX &&
+ test_bit(filter_idx, table->used_bitmap);
++depth) {
cmp = &table->spec[filter_idx];
if (efx_filter_equal(spec, cmp))
@@ -192,6 +199,8 @@ static int efx_filter_search(struct efx_filter_table *table,
}
if (!for_insert)
return -ENOENT;
+ if (depth > FILTER_CTL_SRCH_MAX)
+ return -EBUSY;
found:
*depth_required = depth;
return filter_idx;
--
1.7.2.1
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* Re: Trac+Git: rev-list with pathspec performance?
From: Stephen Bash @ 2010-10-07 17:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <17750617.441668.1286378804923.JavaMail.root@mail.hq.genarts.com>
> > Note that there is proof of concept
> > "tree blame" (in Perl) which generates such 'last change to file'
> > information, I think faster than running 'git rev-list -1 <file>'
> > for
> > each file. Even better would be to encode used algorithm in C.
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/150063/focus=150183
>
> My early experiments with your script are good for speed, but for some
> reason I'm always getting the first commit for a file rather than the
> most recent. I'll do some experimenting to see if I can uncover the
> issue.
Following up, I had to add -r to the diff-tree command line when requesting a subdirectory to work around the problem (script always returned the first commit).
I'm curious if it's faster to get the SHA of the sub-tree and compare that before actually running diff-tree? And for that matter, just run diff-tree on the sub-tree that we care about rather than a recursive sub-tree on the root? These may be early optimizations, but they're ideas that occurred to me while debugging the code...
> > P.S. Alternate solution would be to simply get rid of SVN-inspired
> > view. Git tracks history of a *project* as a whole, not set of
> > histories for individual files (like CVS).
After a lot of experimentation, this is basically what we did. I modified the Trac templates to not list the last change SHA or log message in the directory view. After all my testing, I just don't think there's a fast way to get this information from Git. This blame-dir script is the fastest alternative I've tried (about 5x faster than rev-list'ing each file), but it's still ~30 seconds on my machine (which is faster than our web server), and IMHO that's too long to ask a user to wait for a page to load.
Thanks,
Stephen
^ 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.