* Re: memory clobber in rx path, maybe related to ath9k.
From: Ben Greear @ 2010-10-07 18:39 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTinbRSnPVgbBxvVpMdnP+K--bye=Q-miHf4X44kz@mail.gmail.com>
On 10/07/2010 11:29 AM, Luis R. Rodriguez wrote:
> On Thu, Oct 7, 2010 at 11:14 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Thu, 2010-10-07 at 10:33 -0700, Ben Greear wrote:
>>> In case it helps, here is a dump of where the corrupted SKB was deleted.
>>
>> I wonder, do you have a machine with a decent IOMMU? Adding IOMMU
>> debugging into the mix could help you figure out if it's a DMA problem.
>
> Ben, how much traffic are you RX'ing on these virtual interfaces?
I disabled my user-space application, and this script alone can reproduce
the problem fairly quickly on my system. You will need to change some
of those first variables. Just start it and wait a few minutes and
watch the splats show on the console :)
Note that I am not generating any traffic, but the wpa_supplicants are
doing their thing of course...
I'm using the kernel found here:
http://dmz2.candelatech.com/git/gitweb.cgi?p=linux.wireless-testing.ct/.git;a=summary
It's latest wireless-testing with some of my own patches, and some
I've gathered from here an there. I doubt I'm causing this problem,
but if you can't reproduce it with this script on your kernels,
I can try with base wireless-testing or whatever you are using.
#!/usr/bin/perl
use strict;
my $iw = "./local/sbin/iw";
my $ip = "./local/sbin/ip";
my $wpa_s = "./local/bin/wpa_supplicant";
my $ssid = "candela-n";
my $key = "wpadmz123";
my $phy = "phy0";
my $max = 32;
my $i;
my $bmac = "00:01:02:03:04:";
my $cmd;
# Create stations
for ($i = 0; $i<$max; $i++) {
runCmd("$iw phy $phy interface add sta$i type station");
my $mc5 = "$i";
if (length($mc5) == 1) {
$mc5 = "0$mc5"; # pad mac octet
}
my $mac = "$bmac$mc5";
runCmd("$ip link set sta$i address $mac");
runCmd("$iw dev sta$i set power_save off");
}
# Bring them up with WPA
for ($i = 0; $i<$max; $i++) {
open(FD, ">sta$i" . "_wpa.conf") || die("Couldn't open file: $!\n");
print FD "
ctrl_interface=/var/run/wpa_supplicant
fast_reauth=1
#can_scan_one=1
network={
ssid=\"$ssid\"
proto=WPA
key_mgmt=WPA-PSK
psk=\"$key\"
pairwise=TKIP CCMP
group=TKIP CCMP
}
";
runCmd("$wpa_s -B -i sta$i -c sta$i" . "_wpa.conf -P sta$i" . "_wpa.pid -t -f sta$i" . "_wpa.log");
}
sub runCmd {
my $cmd = shift;
print "$cmd\n";
`$cmd`;
}
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v3] compat: backport netlink changes used in the nl80211 cleanup
From: Johannes Berg @ 2010-10-07 18:39 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <4CADC341.40305@openwrt.org>
On Thu, 2010-10-07 at 14:55 +0200, Felix Fietkau wrote:
> +#define genl_info_net(_info) genl_info_net((_info)->info)
Need this instead:
#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,32)
/* compat for even older kernels already defines this to &init_net */
#define genl_info_net(_info) genl_info_net((_info)->info)
#endif
johannes
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] ceph/rbd block driver for qemu-kvm (v4)
From: Anthony Liguori @ 2010-10-07 18:38 UTC (permalink / raw)
To: Yehuda Sadeh Weinraub
Cc: Christian Brunner, malc, kvm, qemu-devel, Kevin Wolf, ceph-devel
In-Reply-To: <AANLkTikuNq1ApT+2ML6s6NXXpTZaedgJDG1xq_=oBQPK@mail.gmail.com>
On 10/07/2010 01:08 PM, Yehuda Sadeh Weinraub wrote:
> On Thu, Oct 7, 2010 at 7:12 AM, Anthony Liguori<anthony@codemonkey.ws> wrote:
>
>> On 08/03/2010 03:14 PM, Christian Brunner wrote:
>>
>>> +#include "qemu-common.h"
>>> +#include "qemu-error.h"
>>> +#include<sys/types.h>
>>> +#include<stdbool.h>
>>> +
>>> +#include<qemu-common.h>
>>>
>>>
>> This looks to be unnecessary. Generally, system includes shouldn't be
>> required so all of these should go away except rado/librados.h
>>
> Removed.
>
>
>>
>>> +
>>> +#include "rbd_types.h"
>>> +#include "module.h"
>>> +#include "block_int.h"
>>> +
>>> +#include<stdio.h>
>>> +#include<stdlib.h>
>>> +#include<rados/librados.h>
>>> +
>>> +#include<signal.h>
>>> +
>>> +
>>> +int eventfd(unsigned int initval, int flags);
>>>
>>>
>> This is not quite right. Depending on eventfd is curious but in the very
>> least, you need to detect the presence of eventfd in configure and provide a
>> wrapper that redefines it as necessary.
>>
> Can fix that, though please see my later remarks.
>
>>> +static int create_tmap_op(uint8_t op, const char *name, char **tmap_desc)
>>> +{
>>> + uint32_t len = strlen(name);
>>> + /* total_len = encoding op + name + empty buffer */
>>> + uint32_t total_len = 1 + (sizeof(uint32_t) + len) + sizeof(uint32_t);
>>> + char *desc = NULL;
>>>
>>>
>> char is the wrong type to use here as it may be signed or unsigned. That
>> can have weird effects with binary data when you're directly manipulating
>> it.
>>
> Well, I can change it to uint8_t, so that it matches the op type, but
> that'll require adding some other castings. In any case, you usually
> get such a weird behavior when you cast to types of different sizes
> and have the sign bit padded which is not the case in here.
>
>
>>
>>> +
>>> + desc = qemu_malloc(total_len);
>>> +
>>> + *tmap_desc = desc;
>>> +
>>> + *desc = op;
>>> + desc++;
>>> + memcpy(desc,&len, sizeof(len));
>>> + desc += sizeof(len);
>>> + memcpy(desc, name, len);
>>> + desc += len;
>>> + len = 0;
>>> + memcpy(desc,&len, sizeof(len));
>>> + desc += sizeof(len);
>>>
>>>
>> Shouldn't endianness be a concern?
>>
> Right. Fixed that.
>
>
>>
>>> +
>>> + return desc - *tmap_desc;
>>> +}
>>> +
>>> +static void free_tmap_op(char *tmap_desc)
>>> +{
>>> + qemu_free(tmap_desc);
>>> +}
>>> +
>>> +static int rbd_register_image(rados_pool_t pool, const char *name)
>>> +{
>>> + char *tmap_desc;
>>> + const char *dir = RBD_DIRECTORY;
>>> + int ret;
>>> +
>>> + ret = create_tmap_op(CEPH_OSD_TMAP_SET, name,&tmap_desc);
>>> + if (ret< 0) {
>>> + return ret;
>>> + }
>>> +
>>> + ret = rados_tmap_update(pool, dir, tmap_desc, ret);
>>> + free_tmap_op(tmap_desc);
>>> +
>>> + return ret;
>>> +}
>>>
>>>
>> This ops are all synchronous? IOW, rados_tmap_update() call blocks until
>> the operation is completed?
>>
> Yeah. And this is only called from the rbd_create() callback.
>
>
>>> + header_snap += strlen(header_snap) + 1;
>>> + if (header_snap> end)
>>> + error_report("bad header, snapshot list broken");
>>>
>>>
>> Missing curly braces here.
>>
> Fixed.
>
>
>>> + if (strncmp(hbuf + 68, RBD_HEADER_VERSION, 8)) {
>>> + error_report("Unknown image version %s", hbuf + 68);
>>> + r = -EMEDIUMTYPE;
>>> + goto failed;
>>> + }
>>> +
>>> + RbdHeader1 *header;
>>>
>>>
>>>
>> Don't mix variable definitions with code.
>>
> Fixed.
>
>
>>> + s->efd = eventfd(0, 0);
>>> + if (s->efd< 0) {
>>> + error_report("error opening eventfd");
>>> + goto failed;
>>> + }
>>> + fcntl(s->efd, F_SETFL, O_NONBLOCK);
>>> + qemu_aio_set_fd_handler(s->efd, rbd_aio_completion_cb, NULL,
>>> + rbd_aio_flush_cb, NULL, s);
>>>
>>>
>> It looks like you just use the eventfd to signal aio completion callbacks.
>> A better way to do this would be to schedule a bottom half. eventfds are
>> Linux specific and specific to recent kernels.
>>
> Digging back why we introduced the eventfd, it was due to some issues
> seen with do_savevm() hangs on qemu_aio_flush(). The reason seemed
> that we had no fd associated with the block device, which seemed to
> not work well with the qemu aio model. If that assumption is wrong,
> we'd be happy to change it. In any case, there are other more portable
> ways to generate fds, so if it's needed we can do that.
>
There's no fd at all? How do you get notifications about an
asynchronous event completion?
Regards,
Anthony Liguori
^ permalink raw reply
* Re: [PATCH v2 02/03] wl1271: 11n Support, ACX Commands
From: Luciano Coelho @ 2010-10-07 18:37 UTC (permalink / raw)
To: ext Shahar Levi; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1286388491-28752-4-git-send-email-shahar_levi@ti.com>
On Wed, 2010-10-06 at 20:08 +0200, ext Shahar Levi wrote:
> Added ACX command to the FW for 11n support.
>
> Signed-off-by: Shahar Levi <shahar_levi@ti.com>
> ---
Again, mostly coding-style comments.
> diff --git a/drivers/net/wireless/wl12xx/wl1271_acx.c b/drivers/net/wireless/wl12xx/wl1271_acx.c
> index 6189934..cc6b7d8 100644
> --- a/drivers/net/wireless/wl12xx/wl1271_acx.c
> +++ b/drivers/net/wireless/wl12xx/wl1271_acx.c
> @@ -1226,6 +1226,97 @@ out:
> return ret;
> }
>
> +int wl1271_acx_set_ht_capabilities(struct wl1271 *wl,
> + struct ieee80211_sta_ht_cap *ht_cap,
> + bool allow_ht_operation)
> +{
> + struct wl1271_acx_ht_capabilities *acx;
> + /*
> + * Note, currently this value will be set to FFFFFFFFFFFF to indicate
> + * it is relevant for all peers since we only support HT in
> + * infrastructure mode. Later on this field will be relevant to
> + * IBSS/DLS operation */
> + u8 mac_address[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
I didn't realize this when reviewing patch 01/03, but you could actually
remove the Note from the wl1271_acx.h file and leave it here. There's
no need to have it repeated there and here.
> + /* Allow HT Operation ? */
> + if (true == allow_ht_operation) {
I know that some people like to put the constant in the left side of the
comparison operator to avoid problems with mistyping == as =, but
reading this in the opposite way is less intuitive (like top-posting? ;)
and the compiler, if called with reasonable options, will warn you if
you make that mistake. So, summarizing, please use it like this
instead, then you don't even risk mistyping == in the first place :P
if (allow_ht_operation) {
> + acx->ht_capabilites =
> + WL1271_ACX_FW_CAP_BIT_MASK_HT_OPERATION;
Add a more indentation on the second line, it's easier to read.
> + acx->ht_capabilites |=
> + ((ht_cap->cap & IEEE80211_HT_CAP_GRN_FLD) ?
> + WL1271_ACX_FW_CAP_BIT_MASK_GREENFIELD_FRAME_FORMAT : 0);
> + acx->ht_capabilites |=
> + ((ht_cap->cap & IEEE80211_HT_CAP_SGI_20) ?
> + WL1271_ACX_FW_CAP_BIT_MASK_SHORT_GI_FOR_20MHZ_PACKETS : 0);
> + acx->ht_capabilites |=
> + ((ht_cap->cap & IEEE80211_HT_CAP_LSIG_TXOP_PROT) ?
> + WL1271_ACX_FW_CAP_BIT_MASK_LSIG_TXOP_PROTECTION : 0);
Same thing for all these other assignments.
> +
> + /* get date from A-MPDU parameters field */
"get data"
> + acx->ampdu_max_length = ht_cap->ampdu_factor;
> + acx->ampdu_min_spacing = ht_cap->ampdu_density;
> +
> + memcpy(acx->mac_address, mac_address, ETH_ALEN);
> + }
> + /* HT operations are not allowed */
> + else
> + acx->ht_capabilites = 0;
According to Documentation/CodingStyle, you should write the else block
like this:
if (...) {
...
} else {
acx->ht_capabilities = 0;
}
> +int wl1271_acx_set_ht_information(struct wl1271 *wl,
> + u16 ht_operation_mode)
> +{
> + struct wl1271_acx_ht_information *acx;
> + int ret = 0;
> +
> + wl1271_debug(DEBUG_ACX, "acx ht information setting");
> +
> + acx = kzalloc(sizeof(*acx), GFP_KERNEL);
> + if (!acx) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + acx->ht_protection =
> + (u8)(ht_operation_mode & IEEE80211_HT_OP_MODE_PROTECTION);
> + acx->rifs_mode = 0;
> + acx->gf_protection = 0;
> + acx->ht_tx_burst_limit = 0;
> + acx->dual_cts_protection = 0;
> +
> + ret = wl1271_cmd_configure(wl,
> + ACX_HT_BSS_OPERATION,
> + acx,
> + sizeof(*acx));
Doesn't this fit in less lines?
--
Cheers,
Luca.
^ permalink raw reply
* Re: twl4030 irq crashes
From: Thomas Gleixner @ 2010-10-07 18:37 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: Ingo Molnar, linux-kernel
In-Reply-To: <AANLkTik++Rb-x+aLtKv83USqSn8tQ4iyfSyWCNgfM+nO@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1567 bytes --]
On Thu, 7 Oct 2010, Grazvydas Ignotas wrote:
> On Thu, Oct 7, 2010 at 1:59 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Thu, 7 Oct 2010, Grazvydas Ignotas wrote:
> >
> >> Hello,
> >>
> >> I've pulled today's (20101006) linux-next and twl4030 started crashing
> >> on certain interrupts. twl4030 irq code hasn't changed so it's
> >> probably genirq's fault:
> >>
> >> [ 0.889739] Unable to handle kernel NULL pointer dereference at
> >> virtual address 00000000
> >> [ 0.898193] pgd = c0004000
> >> [ 0.901000] [00000000] *pgd=00000000
> >> [ 0.904754] Internal error: Oops: 80000005 [#1]
> >> [ 0.909484] last sysfs file:
> >> [ 0.912567] Modules linked in:
> >> [ 0.915771] CPU: 0 Not tainted
> >> (2.6.36-rc6-next-20101006-00001-g766a681-dirty #205)
> >> [ 0.924133] PC is at 0x0
> >> [ 0.926788] LR is at handle_edge_irq+0x84/0x14c
> >
> > Can you please decode that line with
> >
> > addr2line -e vmlinux c0077244
>
> kernel/irq/chip.c:725
The patch below should cure that.
Thanks,
tglx
---
diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
index 61c8664..b9fda70 100644
--- a/drivers/mfd/twl4030-irq.c
+++ b/drivers/mfd/twl4030-irq.c
@@ -810,7 +810,7 @@ int twl4030_init_irq(int irq_num, unsigned irq_base, unsigned irq_end)
twl4030_irq_chip = dummy_irq_chip;
twl4030_irq_chip.name = "twl4030";
- twl4030_sih_irq_chip.ack = dummy_irq_chip.ack;
+ twl4030_sih_irq_chip.irq_ack = dummy_irq_chip.irq_ack;
for (i = irq_base; i < irq_end; i++) {
set_irq_chip_and_handler(i, &twl4030_irq_chip,
^ permalink raw reply related
* Re: git log doesn't allow %x00 in custom format anymore?
From: Erik Faye-Lund @ 2010-10-07 18:37 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <20101007183342.GA20289@sigill.intra.peff.net>
On Thu, Oct 7, 2010 at 8:33 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Oct 07, 2010 at 08:19:01PM +0200, Erik Faye-Lund wrote:
>
>> Yeah. When I read K&R a bit closer, I find this:
>>
>> "A number specifying a minimum field width. The converted argument
>> will be printed in a field _at least this wide_, and wider if
>> necessary. If the converted argument has fewer characters than the
>> field width _it will be padded_ on the left (or right, if left
>> adjustment has been requested) to make up the field width."
>
> You are confusing field width (%*s) with precision (%.*s) here.
>
> C89 is pretty clear that the behavior I am seeing is mandated:
>
> 7.19.6.1, paragraph 4:
>
> An optional precision that gives ... the maximum number of bytes to
> be written for s conversions.
>
> 7.19.6.1, paragraph 8, item "s":
>
> ... Characters from the array are written up to (but not including)
> the terminating null character. If the precision is specified, no
> more than that many bytes are written. If the precision is not
> specified or is greater than the size of the array, the array shall
> contain a null character.
>
> so it is always about giving a maximum to print an unterminated string,
> or to print a partial string. But printf always stops at a NUL.
>
> -Peff
>
Indeed, thanks for clearing that up.
^ permalink raw reply
* [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 18:36 UTC (permalink / raw)
To: linux-kernel
Cc: Daniel Walker, Hyok S. Choi, Tony Lindgren, Jeff Ohlstein,
Greg Kroah-Hartman, Ben Dooks, Alan Cox, Kukjin Kim,
Mike Frysinger, Feng Tang, Tobias Klauser, Jason Wessel,
Philippe Langlais
Many of JTAG debuggers for ARM support DCC protocol over JTAG
connection, which is very useful to debug hardwares which has no
serial port. This patch adds DCC serial emulation and the console
support. System timer based polling method is used for the
emulation of serial input interrupt handling.
Most of the code was taken from Hyok S. Choi original work, but the
inline assmebly needed some work and updating. It now supports ARMv7.
Also the description above is from Hyok also.
CC: Hyok S. Choi <hyok.choi@samsung.com>
CC: Tony Lindgren <tony@atomide.com>
Signed-off-by: Jeff Ohlstein <johlstei@quicinc.com>
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
---
drivers/serial/Kconfig | 31 +++
drivers/serial/Makefile | 1 +
drivers/serial/dcc.c | 432 +++++++++++++++++++++++++++++++++++++++++++
include/linux/serial_core.h | 3 +
4 files changed, 467 insertions(+), 0 deletions(-)
create mode 100644 drivers/serial/dcc.c
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 12900f7..a54a57c 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -495,6 +495,37 @@ config SERIAL_S3C2400
help
Serial port support for the Samsung S3C2400 SoC
+config SERIAL_DCC
+ bool "JTAG ICE/ICD DCC serial port emulation support"
+ depends on ARM
+ select SERIAL_CORE
+ help
+ This selects serial port emulation driver for ICE/ICD JTAG debugger
+ (e.g. Trace32) for ARM architecture. You should make an terminal with
+ DCC(JTAG1) protocol.
+
+ if unsure, say N.
+
+config SERIAL_DCC_CONSOLE
+ bool "Support for console on JTAG ICE/ICD DCC"
+ depends on SERIAL_DCC
+ select SERIAL_CORE_CONSOLE
+ help
+ Say Y here if you wish to use ICE/ICD JTAG DCC serial port emulation
+ as the system console.
+
+ if unsure, say N.
+
+config SERIAL_DCC_STDSERIAL
+ bool "Install JTAG ICE/ICD DCC as standard serial"
+ default y
+ depends on !SERIAL_8250 && SERIAL_DCC
+ help
+ Say Y here if you want to install DCC driver as a normal serial port
+ /dev/ttyS0 (major 4, minor 64). Otherwise, it appears as /dev/ttyJ0
+ (major 4, minor 128) and can co-exist with other UARTs, such as
+ 8250/16C550 compatibles.
+
config SERIAL_S3C2410
tristate "Samsung S3C2410 Serial port support"
depends on SERIAL_SAMSUNG && CPU_S3C2410
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 1ca4fd5..896c3f6 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_SERIAL_8250_MCA) += 8250_mca.o
obj-$(CONFIG_SERIAL_AMBA_PL010) += amba-pl010.o
obj-$(CONFIG_SERIAL_AMBA_PL011) += amba-pl011.o
obj-$(CONFIG_SERIAL_CLPS711X) += clps711x.o
+obj-$(CONFIG_SERIAL_DCC) += dcc.o
obj-$(CONFIG_SERIAL_PXA) += pxa.o
obj-$(CONFIG_SERIAL_PNX8XXX) += pnx8xxx_uart.o
obj-$(CONFIG_SERIAL_SA1100) += sa1100.o
diff --git a/drivers/serial/dcc.c b/drivers/serial/dcc.c
new file mode 100644
index 0000000..233caf7
--- /dev/null
+++ b/drivers/serial/dcc.c
@@ -0,0 +1,432 @@
+/*
+ * linux/drivers/serial/dcc.c
+ *
+ * serial port emulation driver for the JTAG DCC Terminal.
+ *
+ * DCC(JTAG1) protocol version for JTAG ICE/ICD Debuggers:
+ * Copyright (C) 2003, 2004, 2005 Hyok S. Choi (hyok.choi@samsung.com)
+ * SAMSUNG ELECTRONICS Co.,Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Changelog:
+ * Oct-2003 Hyok S. Choi Created
+ * Feb-2004 Hyok S. Choi Updated for serial_core.c and 2.6 kernel
+ * Mar-2005 Hyok S. Choi renamed from T32 to DCC
+ * Apr-2006 Hyok S. Choi revised including the MAJOR number
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/tty.h>
+#include <linux/ioport.h>
+#include <linux/init.h>
+#include <linux/serial.h>
+#include <linux/console.h>
+#include <linux/sysrq.h>
+#include <linux/tty_flip.h>
+#include <linux/major.h>
+
+#include <linux/io.h>
+#include <linux/irq.h>
+
+#include <linux/serial_core.h>
+
+#define DCC_POLL_RUN 0
+#define DCC_POLL_STOP 1
+#define DCC_POLL_STOPPED 2
+
+static struct uart_port dcc_port;
+static struct delayed_work dcc_poll_task;
+static void dcc_poll(struct work_struct *work);
+static int dcc_poll_state = DCC_POLL_STOPPED;
+
+#define UART_NR 1 /* we have only one JTAG port */
+
+#ifdef CONFIG_SERIAL_DCC_STDSERIAL
+/* use ttyS for emulation of standard serial driver */
+#define SERIAL_DCC_NAME "ttyS"
+#define SERIAL_DCC_MINOR 64
+#else
+/* use ttyJ0(128) */
+#define SERIAL_DCC_NAME "ttyJ"
+#define SERIAL_DCC_MINOR (64 + 64)
+#endif
+#define SERIAL_DCC_MAJOR TTY_MAJOR
+
+/* DCC Status Bits */
+#define DCC_STATUS_RX (1 << 30)
+#define DCC_STATUS_TX (1 << 29)
+
+static inline u32 __dcc_getstatus(void)
+{
+ u32 __ret;
+
+ asm("mrc p14, 0, %0, c0, c1, 0 @ read comms ctrl reg"
+ : "=r" (__ret) : : "cc");
+
+ return __ret;
+}
+
+
+#if defined(CONFIG_CPU_V7)
+static inline char __dcc_getchar(void)
+{
+ char __c;
+
+ asm("get_wait: mrc p14, 0, pc, c0, c1, 0 \n\
+ bne get_wait \n\
+ mrc p14, 0, %0, c0, c5, 0 @ read comms data reg"
+ : "=r" (__c) : : "cc");
+
+ return __c;
+}
+#else
+static inline char __dcc_getchar(void)
+{
+ char __c;
+
+ asm("mrc p14, 0, %0, c0, c5, 0 @ read comms data reg"
+ : "=r" (__c));
+
+ return __c;
+}
+#endif
+
+#if defined(CONFIG_CPU_V7)
+static inline void __dcc_putchar(char c)
+{
+ asm("put_wait: mrc p14, 0, pc, c0, c1, 0 \n\
+ bcs put_wait \n\
+ mcr p14, 0, %0, c0, c5, 0 "
+ : : "r" (c) : "cc");
+}
+#else
+static inline void __dcc_putchar(char c)
+{
+ asm("mcr p14, 0, %0, c0, c5, 0 @ write a char"
+ : /* no output register */
+ : "r" (c));
+}
+#endif
+
+static void dcc_putchar(struct uart_port *port, int ch)
+{
+ while (__dcc_getstatus() & DCC_STATUS_TX)
+ cpu_relax();
+ __dcc_putchar((char)(ch & 0xFF));
+}
+
+static inline void xmit_string(struct uart_port *port, char *p, int len)
+{
+ for ( ; len; len--, p++)
+ dcc_putchar(port, *p);
+}
+
+static inline void dcc_transmit_buffer(struct uart_port *port)
+{
+ struct circ_buf *xmit = &port->state->xmit;
+ int pendings = uart_circ_chars_pending(xmit);
+
+ if (pendings + xmit->tail > UART_XMIT_SIZE) {
+ xmit_string(port, &(xmit->buf[xmit->tail]),
+ UART_XMIT_SIZE - xmit->tail);
+ xmit_string(port, &(xmit->buf[0]), xmit->head);
+ } else
+ xmit_string(port, &(xmit->buf[xmit->tail]), pendings);
+
+ xmit->tail = (xmit->tail + pendings) & (UART_XMIT_SIZE-1);
+ port->icount.tx += pendings;
+}
+
+static inline void dcc_transmit_x_char(struct uart_port *port)
+{
+ dcc_putchar(port, port->x_char);
+ port->icount.tx++;
+ port->x_char = 0;
+}
+
+static void dcc_start_tx(struct uart_port *port)
+{
+ dcc_transmit_buffer(port);
+}
+
+static inline void dcc_rx_chars(struct uart_port *port)
+{
+ unsigned char ch;
+ struct tty_struct *tty = port->state->port.tty;
+
+ /*
+ * check input.
+ * checking JTAG flag is better to resolve the status test.
+ * incount is NOT used for JTAG1 protocol.
+ */
+
+ if (__dcc_getstatus() & DCC_STATUS_RX) {
+
+ /* for JTAG 1 protocol, incount is always 1. */
+ ch = __dcc_getchar();
+
+ if (tty) {
+ tty_insert_flip_char(tty, ch, TTY_NORMAL);
+ port->icount.rx++;
+ tty_flip_buffer_push(tty);
+ }
+ }
+}
+
+static inline void dcc_overrun_chars(struct uart_port *port)
+{
+ port->icount.overrun++;
+}
+
+static inline void dcc_tx_chars(struct uart_port *port)
+{
+ struct circ_buf *xmit = &port->state->xmit;
+
+ if (port->x_char) {
+ dcc_transmit_x_char(port);
+ return;
+ }
+
+ if (uart_circ_empty(xmit) || uart_tx_stopped(port))
+ return;
+
+ dcc_transmit_buffer(port);
+
+ if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
+ uart_write_wakeup(port);
+}
+
+static void dcc_poll(struct work_struct *work)
+{
+ spin_lock(&dcc_port.lock);
+
+ if (dcc_poll_state != DCC_POLL_RUN) {
+ dcc_poll_state = DCC_POLL_STOPPED;
+ goto dcc_poll_stop;
+ }
+
+ dcc_rx_chars(&dcc_port);
+ dcc_tx_chars(&dcc_port);
+
+ schedule_delayed_work(&dcc_poll_task, 1);
+
+dcc_poll_stop:
+ spin_unlock(&dcc_port.lock);
+}
+
+static unsigned int dcc_tx_empty(struct uart_port *port)
+{
+ return TIOCSER_TEMT;
+}
+
+static unsigned int dcc_get_mctrl(struct uart_port *port)
+{
+ return TIOCM_CTS | TIOCM_DSR | TIOCM_CD;
+}
+
+static int dcc_startup(struct uart_port *port)
+{
+ /* Initialize the work, and shcedule it. */
+ INIT_DELAYED_WORK(&dcc_poll_task, dcc_poll);
+ spin_lock(&port->lock);
+ if (dcc_poll_state != DCC_POLL_RUN)
+ dcc_poll_state = DCC_POLL_RUN;
+ schedule_delayed_work(&dcc_poll_task, 1);
+ spin_unlock(&port->lock);
+
+ return 0;
+}
+
+static void dcc_shutdown(struct uart_port *port)
+{
+ spin_lock(&port->lock);
+ dcc_poll_state = DCC_POLL_STOP;
+ spin_unlock(&port->lock);
+}
+
+static void
+dcc_set_termios(struct uart_port *port, struct ktermios *termios,
+ struct ktermios *old)
+{
+ unsigned int baud, quot;
+
+ /*
+ * We don't support parity, stop bits, or anything other
+ * than 8 bits, so clear these termios flags.
+ */
+ termios->c_cflag &= ~(CSIZE | CSTOPB | PARENB | PARODD | CREAD);
+ termios->c_cflag |= CS8;
+
+ /*
+ * We don't appear to support any error conditions either.
+ */
+ termios->c_iflag &= ~(INPCK | IGNPAR | IGNBRK | BRKINT);
+
+ /*
+ * Ask the core to calculate the divisor for us.
+ */
+ baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk/16);
+ quot = uart_get_divisor(port, baud);
+
+ uart_update_timeout(port, termios->c_cflag, baud);
+
+}
+
+static const char * dcc_type(struct uart_port *port)
+{
+ return port->type == PORT_DCC_JTAG1 ? "DCC" : NULL;
+}
+
+static int dcc_request_port(struct uart_port *port)
+{
+ return 0;
+}
+
+/*
+ * Configure/autoconfigure the port.
+ */
+static void dcc_config_port(struct uart_port *port, int flags)
+{
+ if (flags & UART_CONFIG_TYPE) {
+ port->type = PORT_DCC_JTAG1;
+ dcc_request_port(port);
+ }
+}
+
+/*
+ * verify the new serial_struct (for TIOCSSERIAL).
+ */
+static int dcc_verify_port(struct uart_port *port, struct serial_struct *ser)
+{
+ int ret = 0;
+ if (ser->type != PORT_UNKNOWN && ser->type != PORT_DCC_JTAG1)
+ ret = -EINVAL;
+ if (ser->irq < 0 || ser->irq >= NR_IRQS)
+ ret = -EINVAL;
+ if (ser->baud_base < 9600)
+ ret = -EINVAL;
+ return ret;
+}
+
+/* dummy operation handlers for uart_ops */
+static void dcc_dummy_ops(struct uart_port *port)
+{
+}
+static void dcc_dummy_ops_ui(struct uart_port *port, unsigned int ui)
+{
+}
+static void dcc_dummy_ops_i(struct uart_port *port, int i)
+{
+}
+
+static struct uart_ops dcc_pops = {
+ .tx_empty = dcc_tx_empty,
+ .set_mctrl = dcc_dummy_ops_ui,
+ .get_mctrl = dcc_get_mctrl,
+ .stop_tx = dcc_dummy_ops,
+ .start_tx = dcc_start_tx,
+ .stop_rx = dcc_dummy_ops,
+ .enable_ms = dcc_dummy_ops,
+ .break_ctl = dcc_dummy_ops_i,
+ .startup = dcc_startup,
+ .shutdown = dcc_shutdown,
+ .set_termios = dcc_set_termios,
+ .type = dcc_type,
+ .release_port = dcc_dummy_ops,
+ .request_port = dcc_request_port,
+ .config_port = dcc_config_port,
+ .verify_port = dcc_verify_port,
+};
+
+static struct uart_port dcc_port = {
+ .membase = (char *)0x12345678, /* we need these garbages */
+ .mapbase = 0x12345678, /* for serial_core.c */
+ .iotype = UPIO_MEM,
+ .irq = 0,
+ .uartclk = 14745600,
+ .fifosize = 0,
+ .ops = &dcc_pops,
+ .flags = UPF_BOOT_AUTOCONF,
+ .line = 0,
+};
+
+#ifdef CONFIG_SERIAL_DCC_CONSOLE
+static void
+dcc_console_write(struct console *co, const char *s, unsigned int count)
+{
+ uart_console_write(&dcc_port, s, count, dcc_putchar);
+}
+
+static int __init dcc_console_setup(struct console *co, char *options)
+{
+ struct uart_port *port = &dcc_port;
+ int baud = 9600;
+ int bits = 8;
+ int parity = 'n';
+ int flow = 'n';
+
+ if (options)
+ uart_parse_options(options, &baud, &parity, &bits, &flow);
+
+ return uart_set_options(port, co, baud, parity, bits, flow);
+}
+
+static struct uart_driver dcc_reg;
+static struct console dcc_console = {
+ .name = SERIAL_DCC_NAME,
+ .write = dcc_console_write,
+ .device = uart_console_device,
+ .setup = dcc_console_setup,
+ .flags = CON_PRINTBUFFER,
+ .index = -1,
+ .data = &dcc_reg,
+};
+
+static int __init dcc_console_init(void)
+{
+ register_console(&dcc_console);
+ return 0;
+}
+console_initcall(dcc_console_init);
+
+#define DCC_CONSOLE &dcc_console
+#else
+#define DCC_CONSOLE NULL
+#endif
+
+static struct uart_driver dcc_reg = {
+ .owner = THIS_MODULE,
+ .driver_name = SERIAL_DCC_NAME,
+ .dev_name = SERIAL_DCC_NAME,
+ .major = SERIAL_DCC_MAJOR,
+ .minor = SERIAL_DCC_MINOR,
+ .nr = UART_NR,
+ .cons = DCC_CONSOLE,
+};
+
+static int __init dcc_init(void)
+{
+ int ret;
+
+ printk(KERN_INFO "DCC: JTAG1 Serial emulation driver\n");
+
+ ret = uart_register_driver(&dcc_reg);
+
+ if (ret)
+ return ret;
+
+ uart_add_one_port(&dcc_reg, &dcc_port);
+
+ return 0;
+}
+
+device_initcall(dcc_init);
+
+MODULE_DESCRIPTION("DCC(JTAG1) JTAG debugger console emulation driver");
+MODULE_AUTHOR("Hyok S. Choi <hyok.choi@samsung.com>");
+MODULE_SUPPORTED_DEVICE(SERIAL_DCC_NAME);
+MODULE_LICENSE("GPL");
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 563e234..a360c3a 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -196,6 +196,9 @@
/* High Speed UART for Medfield */
#define PORT_MFD 95
+/* DCC(JTAG) emulation port types */
+#define PORT_DCC_JTAG1 96
+
#ifdef __KERNEL__
#include <linux/compiler.h>
--
1.7.1
^ permalink raw reply related
* bitbake COMPATIBLE_MACHINE stack backtrace
From: Frans Meulenbroeks @ 2010-10-07 18:36 UTC (permalink / raw)
To: openembedded-devel
Hi,
If I run bitbake (git head of about a week ago) with a recipe that has
COMPATIBLE_MACHINE set and that is not for my machine, I get a bitbake
tracedump;
Log;
frans@linux-suse:~/oe/openembedded/recipes/zaurus-utils> grep COMPAT *
encdec-updater.bb:COMPATIBLE_MACHINE = '(poodle|c7x0|spitz|akita|tosa)'
nandlogical_1.0.0.bb:COMPATIBLE_MACHINE = "(poodle|c7x0|akita|spitz|tosa)"
zaurus-installer.bb:COMPATIBLE_MACHINE = '(collie|poodle|c7x0|spitz|akita|tosa)'
zaurus-legacy-tar.bb:COMPATIBLE_MACHINE = "spitz"
zaurus-updater.bb:COMPATIBLE_MACHINE = '(poodle|c7x0|spitz|akita|tosa)'
frans@linux-suse:~/oe/openembedded/recipes/zaurus-utils> bitbake -b
zaurus-legacy-tar.bb
ERROR: Command execution failed: Traceback (most recent call last):
File "/home/frans/oe/bitbake/lib/bb/command.py", line 88, in runAsyncCommand
commandmethod(self.cmds_async, self, options)
File "/home/frans/oe/bitbake/lib/bb/command.py", line 174, in buildFile
command.cooker.buildFile(bfile, task)
File "/home/frans/oe/bitbake/lib/bb/cooker.py", line 650, in buildFile
self.status.task_deps[fn]['depends'] = {}
TypeError: 'NoneType' object does not support item assignment
frans@linux-suse:~/oe/openembedded/recipes/zaurus-utils> bitbake
zaurus-legacy-tar
NOTE: Handling BitBake files: - (7148/7148) [100 %]
Parsing of 7148 .bb files complete (6693 cached, 455 parsed). 7333
targets, 330 skipped, 0 masked, 0 errors.
NOTE: oestats: build 93365
ERROR: Nothing PROVIDES 'zaurus-legacy-tar'
ERROR: Command execution failed: Traceback (most recent call last):
File "/home/frans/oe/bitbake/lib/bb/command.py", line 88, in runAsyncCommand
commandmethod(self.cmds_async, self, options)
File "/home/frans/oe/bitbake/lib/bb/command.py", line 184, in buildTargets
command.cooker.buildTargets(pkgs_to_build, task)
File "/home/frans/oe/bitbake/lib/bb/cooker.py", line 737, in buildTargets
taskdata.add_provider(localdata, self.status, k)
File "/home/frans/oe/bitbake/lib/bb/taskdata.py", line 357, in add_provider
self.add_provider_internal(cfgData, dataCache, item)
File "/home/frans/oe/bitbake/lib/bb/taskdata.py", line 377, in
add_provider_internal
raise bb.providers.NoProvider(item)
NoProvider: zaurus-legacy-tar
Especially in the first case there is no real error message.
I seem to recall (but have not verified) that 1.10 handled this
without traceback.
Any opinions/fixes?
Frans
^ permalink raw reply
* bitbake COMPATIBLE_MACHINE stack backtrace
From: Frans Meulenbroeks @ 2010-10-07 18:35 UTC (permalink / raw)
To: openembedded-devel
Hi,
If I run bitbake (git head of about a week ago) with a recipe that has
COMPATIBLE_MACHINE set and that is not for my machine, I get a bitbake
tracedump;
Log;
frans@linux-suse:~/oe/openembedded/recipes/zaurus-utils> grep COMPAT *
encdec-updater.bb:COMPATIBLE_MACHINE = '(poodle|c7x0|spitz|akita|tosa)'
nandlogical_1.0.0.bb:COMPATIBLE_MACHINE = "(poodle|c7x0|akita|spitz|tosa)"
zaurus-installer.bb:COMPATIBLE_MACHINE = '(collie|poodle|c7x0|spitz|akita|tosa)'
zaurus-legacy-tar.bb:COMPATIBLE_MACHINE = "spitz"
zaurus-updater.bb:COMPATIBLE_MACHINE = '(poodle|c7x0|spitz|akita|tosa)'
frans@linux-suse:~/oe/openembedded/recipes/zaurus-utils> bitbake -b
zaurus-legacy-tar.bb
ERROR: Command execution failed: Traceback (most recent call last):
File "/home/frans/oe/bitbake/lib/bb/command.py", line 88, in runAsyncCommand
commandmethod(self.cmds_async, self, options)
File "/home/frans/oe/bitbake/lib/bb/command.py", line 174, in buildFile
command.cooker.buildFile(bfile, task)
File "/home/frans/oe/bitbake/lib/bb/cooker.py", line 650, in buildFile
self.status.task_deps[fn]['depends'] = {}
TypeError: 'NoneType' object does not support item assignment
frans@linux-suse:~/oe/openembedded/recipes/zaurus-utils> bitbake
zaurus-legacy-tar
NOTE: Handling BitBake files: - (7148/7148) [100 %]
Parsing of 7148 .bb files complete (6693 cached, 455 parsed). 7333
targets, 330 skipped, 0 masked, 0 errors.
NOTE: oestats: build 93365
ERROR: Nothing PROVIDES 'zaurus-legacy-tar'
ERROR: Command execution failed: Traceback (most recent call last):
File "/home/frans/oe/bitbake/lib/bb/command.py", line 88, in runAsyncCommand
commandmethod(self.cmds_async, self, options)
File "/home/frans/oe/bitbake/lib/bb/command.py", line 184, in buildTargets
command.cooker.buildTargets(pkgs_to_build, task)
File "/home/frans/oe/bitbake/lib/bb/cooker.py", line 737, in buildTargets
taskdata.add_provider(localdata, self.status, k)
File "/home/frans/oe/bitbake/lib/bb/taskdata.py", line 357, in add_provider
self.add_provider_internal(cfgData, dataCache, item)
File "/home/frans/oe/bitbake/lib/bb/taskdata.py", line 377, in
add_provider_internal
raise bb.providers.NoProvider(item)
NoProvider: zaurus-legacy-tar
Especially in the first case there is no real error message.
I seem to recall (but have not verified) that 1.10 handled this
without traceback.
Any opinions/fixes?
Frans
^ permalink raw reply
* Re: [ipw3945-devel] [PATCH 1/6] iwlwifi: schedule to deprecate software scan support
From: Johannes Berg @ 2010-10-07 18:36 UTC (permalink / raw)
To: Daniel Halperin
Cc: John W. Linville, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <alpine.LFD.2.00.1010071131160.9851@kishwoot.cs.washington.edu>
On Thu, 2010-10-07 at 11:31 -0700, Daniel Halperin wrote:
> Is there a description somewhere of the p2p functionality, modes, etc?
This keeps getting asked -- but the spec isn't "open source". You can
buy the latest draft for like $199. If you google for "Wi-Fi Direct"
you'll also find information.
johannes
^ permalink raw reply
* RE: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
From: Savoy, Pavan @ 2010-10-07 18:35 UTC (permalink / raw)
To: Jiri Slaby
Cc: gregkh@suse.de, linux-kernel@vger.kernel.org,
devel@driverdev.osuosl.org, alan@lxorguk.ukuu.org.uk
In-Reply-To: <4CAE10C0.9000106@gmail.com>
> -----Original Message-----
> From: Jiri Slaby [mailto:jirislaby@gmail.com]
> Sent: Thursday, October 07, 2010 1:26 PM
> To: Savoy, Pavan
> Cc: gregkh@suse.de; linux-kernel@vger.kernel.org; devel@driverdev.osuosl.org;
> alan@lxorguk.ukuu.org.uk
> Subject: Re: [PATCH 1/2] drivers:staging:ti-st: move TI_ST from staging
>
> On 10/07/2010 04:52 PM, Savoy, Pavan wrote:
> > Per-system? I don't understand this.
> > There can be ldisc for each individual TTY, so doesn't that make it per
> device?
>
> No, you can have only up to NR_LDISCS ldiscs in the system and you have
> to choose one of them to "handle" a particular tty.
Agree.
> IOW, you register an ldisc which is available for everybody then. And it
> cannot have ->private_data since everybody would share this single
However, I would only register a ldisc for a TTY. I agree TTY was not meant
to used in such a way, But it is highly unlike i2c or SPI where the adapter
and the client drivers are separate.
So in that case, since the tty ldisc register required something to pass onto
the tty's open function which is called when the line discipline is actually accessed (i.e ioctl TIOCSETD) and not when /dev/ttyS* is opened.
> ->private_data. Instead everybody comes with their devices as ttys which
> have ->private_data for everybody's data and ->disc_data for you to note
> anything about the (tty) device.
>
> Am I missing something?
The situation here was to access the UART from a kernel driver. Say we have
a V4L2 FM radio over the UART, How can I write a v4L2 driver? I has to be a
line discipline driver correct?
Also, I agree on the comment you made that the line discipline ops are singleton
and need not be kmalloc-ed, I am just mentioning what I wished for from the TTY.
> regards,
> --
> js
^ permalink raw reply
* Re: Vendor specific data within a beacon frame
From: Johannes Berg @ 2010-10-07 18:35 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Bjoern Czybik, linux-wireless
In-Reply-To: <AANLkTimzwhBCVKFnx1vhM4A939_kgixEpw5RLTe8JJb0@mail.gmail.com>
On Thu, 2010-10-07 at 11:31 -0700, Luis R. Rodriguez wrote:
> On Thu, Oct 7, 2010 at 11:15 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Thu, 2010-10-07 at 11:11 -0700, Luis R. Rodriguez wrote:
> >
> > Let me quote what you wrote, but just partially:
> >
> >> This can be done from userspace. This is from nl80211.h:
> >
> >> * Note: This command has been removed and it is only reserved at this
> >> * point to avoid re-using existing command number. The functionality this
> >> * command was planned for has been provided with cleaner design with the
> >> * option to specify additional IEs in NL80211_CMD_TRIGGER_SCAN,
> >> * NL80211_CMD_AUTHENTICATE, NL80211_CMD_ASSOCIATE,
> >> * NL80211_CMD_DEAUTHENTICATE, and NL80211_CMD_DISASSOCIATE.
> >
> > :P
>
> Yeah just noticed *after* I pasted it and sent it. Does hostapd use
> this currently?
No, hostapd transmits frames via injection and the data it puts into the
beacon is conveyed with the beacon cmd -- it has never used this
command.
Really, what the OP is looking for is the annotated hostapd
configuration file or the hostapd source code -- he should be able to
figure that out for himself.
johannes
^ permalink raw reply
* Re: [PATCH] Documentation: update-index: -z applies also to --index-info
From: Štěpán Němec @ 2010-10-07 18:33 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, git
In-Reply-To: <d3f7e6795adeccbf7746547842d6b65732d568eb.1286457739.git.bert.wesarg@googlemail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> Also mention, that --stdin and --index-info needs to be the last
> option supplied and indicate this in the usage string.
>
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
>
> ---
>
> We may like the usage string like this:
>
> [[-z] --stdin | --index-info]
Yeah, that'd be definitely better IMO.
Also the usage string in builtin/update-index.c should be updated to the
same effect.
There is actually at least one more problem with the current SYNOPSIS of
`update-index'. Obviously the `*' on the third line of the Asciidoc
source makes the whole `--cacheinfo' line disappear and the rest bold
(cf. e.g. the result at
<http://www.kernel.org/pub/software/scm/git/docs/git-update-index.html>).
I guess using `...' instead of the asterisks (also on the last line,
i.e. [<file>...], not [<file>]*) would both fix the problem and at the
same time make it more consistent with other man pages.
> to make it also clear, that -z applies only to --stdin or --index-only.
> ---
> Documentation/git-update-index.txt | 14 ++++++++------
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/git-update-index.txt
> b/Documentation/git-update-index.txt
> index 74d1d49..4441d7c 100644 Documentation/git-update-index.txt
> --- a/Documentation/git-update-index.txt
> +++ b/Documentation/git-update-index.txt
> @@ -18,8 +18,9 @@ SYNOPSIS
> [--skip-worktree | --no-skip-worktree]
> [--ignore-submodules]
> [--really-refresh] [--unresolve] [--again | -g]
> - [--info-only] [--index-info]
> - [-z] [--stdin]
> + [--info-only]
> + [-z]
> + [--stdin] [--index-info]
> [--verbose]
> [--] [<file>]*
Shouldn't `--verbose' be also moved before the must-be-last options?
> @@ -72,7 +73,7 @@ OPTIONS
> Directly insert the specified info into the index.
>
> --index-info::
> - Read index information from stdin.
> + Read index information from stdin (Must be last option).
I'm not a native speaker myself, but I suspect "must be THE last option"
is more correct (including the lower-case `m' :-)).
> --chmod=(+|-)x::
> Set the execute permissions on the updated files.
> @@ -138,14 +139,15 @@ you will need to handle the situation manually.
> --stdin::
> Instead of taking list of paths from the command line,
> read list of paths from the standard input. Paths are
> - separated by LF (i.e. one path per line) by default.
> + separated by LF (i.e. one path per line) by default
> + (Must be last option).
(same here)
>
> --verbose::
> Report what is being added and removed from index.
>
> -z::
> - Only meaningful with `--stdin`; paths are separated with
> - NUL character instead of LF.
> + Only meaningful with `--stdin` or `--index-info`; paths are
> + separated with NUL character instead of LF.
>
> \--::
> Do not interpret any more arguments as options.
Thanks,
Štěpán
^ permalink raw reply
* [RFC/PATCH v3] usb: usb3.0 ch9 definitions
From: Brokhman Tatyana @ 2010-10-07 18:34 UTC (permalink / raw)
To: linux-usb
Cc: linux-arm-msm, Brokhman Tatyana, Greg Kroah-Hartman,
Matthew Wilcox, Sarah Sharp, linux-kernel
Adding SuperSpeed usb definitions as defined by ch9 of the USB3.0 spec.
This patch is a preparation for adding SuperSpeed support to the gadget
framework.
Signed-off-by: Brokhman Tatyana <tlinder@codeaurora.org>
---
include/linux/usb/ch9.h | 58 ++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 57 insertions(+), 1 deletions(-)
diff --git a/include/linux/usb/ch9.h b/include/linux/usb/ch9.h
index da2ed77..a779b86 100644
--- a/include/linux/usb/ch9.h
+++ b/include/linux/usb/ch9.h
@@ -123,8 +123,23 @@
#define USB_DEVICE_A_ALT_HNP_SUPPORT 5 /* (otg) other RH port does */
#define USB_DEVICE_DEBUG_MODE 6 /* (special devices only) */
+/*
+ * New Feature Selectors as added by USB 3.0
+ * See USB 3.0 spec Table 9-6
+ */
+#define USB_DEVICE_U1_ENABLE 48 /* dev may initiate U1 transition */
+#define USB_DEVICE_U2_ENABLE 49 /* dev may initiate U2 transition*/
+#define USB_DEVICE_LTM_ENABLE 50 /* dev may send LTM*/
+#define USB_INTRF_FUNC_SUSPEND 0 /* function suspend*/
+
+#define USB_INTR_FUNC_SUSPEND_OPT_MASK 0xFF00
+
#define USB_ENDPOINT_HALT 0 /* IN/OUT will STALL */
+/* Bit array elements as returned by the USB_REQ_GET_STATUS request. */
+#define USB_DEV_STAT_U1_ENABLED 2 /* transition into U1 state */
+#define USB_DEV_STAT_U2_ENABLED 3 /* transition into U2 state */
+#define USB_DEV_STAT_LTM_ENABLED 4 /* Latency tolerance messages*/
/**
* struct usb_ctrlrequest - SETUP data for a USB device control request
@@ -675,6 +690,7 @@ struct usb_bos_descriptor {
__u8 bNumDeviceCaps;
} __attribute__((packed));
+#define USB_DT_BOS_SIZE 5
/*-------------------------------------------------------------------------*/
/* USB_DT_DEVICE_CAPABILITY: grouped with BOS */
@@ -712,16 +728,56 @@ struct usb_wireless_cap_descriptor { /* Ultra Wide Band */
__u8 bReserved;
} __attribute__((packed));
+/* USB 2.0 Extension descriptor */
#define USB_CAP_TYPE_EXT 2
struct usb_ext_cap_descriptor { /* Link Power Management */
__u8 bLength;
__u8 bDescriptorType;
__u8 bDevCapabilityType;
- __u8 bmAttributes;
+ __u32 bmAttributes;
#define USB_LPM_SUPPORT (1 << 1) /* supports LPM */
} __attribute__((packed));
+#define USB_DT_USB_EXT_CAP_SIZE 7
+
+/*
+ * SuperSpeed USB Capability descriptor: Defines the set of SuperSpeed USB
+ * specific device level capabilities
+ */
+#define USB_SS_CAP_TYPE 3
+struct usb_ss_cap_descriptor { /* Link Power Management */
+ __u8 bLength;
+ __u8 bDescriptorType;
+ __u8 bDevCapabilityType;
+ __u8 bmAttributes;
+#define USB_LTM_SUPPORT (1 << 1) /* supports LTM */
+ __u16 wSpeedSupported;
+#define USB_LOW_SPEED_OPERATION (1) /* Low speed operation */
+#define USB_FULL_SPEED_OPERATION (1 << 1) /* Full speed operation */
+#define USB_HIGH_SPEED_OPERATION (1 << 2) /* High speed operation */
+#define USB_5GBPS_OPERATION (1 << 3) /* Operation at 5Gbps */
+ __u8 bFunctionalitySupport;
+ __u8 bU1devExitLat;
+ __u16 bU2DevExitLat;
+} __attribute__((packed));
+
+#define USB_DT_USB_SS_CAP_SIZE 10
+
+/*
+ * Container ID Capability descriptor: Defines the instance unique ID used to
+ * identify the instance across all operating modes
+ */
+#define CONTAINER_ID_TYPE 4
+struct usb_ss_container_id_descriptor {
+ __u8 bLength;
+ __u8 bDescriptorType;
+ __u8 bDevCapabilityType;
+ __u8 bReserved;
+ __u8 ContainerID[16]; /* 128-bit number */
+} __attribute__((packed));
+
+#define USB_DT_USB_SS_CONTN_ID_SIZE 20
/*-------------------------------------------------------------------------*/
/* USB_DT_WIRELESS_ENDPOINT_COMP: companion descriptor associated with
--
1.6.3.3
^ permalink raw reply related
* Re: PPC: Possible bug in prom_parse.c:of_irq_map_raw?
From: Grant Likely @ 2010-10-07 18:34 UTC (permalink / raw)
To: John Williams
Cc: Linux Kernel list, linuxppc-dev, Michal Simek, devicetree-discuss
In-Reply-To: <1d3f23371002091921m7f47a1fbt1cf7fd2ef0a927fa@mail.gmail.com>
Reaching way back into the past....
John, did you ever solve your issue here? Comments below.
On Tue, Feb 9, 2010 at 8:21 PM, John Williams
<john.williams@petalogix.com> wrote:
> Hi,
>
> Perhaps this is my misunderstanding, but I'm looking at the bit of
> code in of_irq_map_raw() that iterates the interrupt-map DTS node,
> which I am seeing to behave strangely when handling the interrupt-map
> property on a PCI bridge node.
>
> Early in the function, we get the #address-cells value from the node -
> in this case the PCI bridge, and store it in local var addrsize:
>
> /* Look for this #address-cells. We have to implement the old linux
> * trick of looking for the parent here as some device-trees rely on it
> */
> old = of_node_get(ipar);
> do {
> tmp = of_get_property(old, "#address-cells", NULL);
> tnode = of_get_parent(old);
> of_node_put(old);
> old = tnode;
> } while(old && tmp == NULL);
> of_node_put(old);
> old = NULL;
> addrsize = (tmp == NULL) ? 2 : *tmp;
>
> DBG(" -> addrsize=%d\n", addrsize);
>
>
> Later, once we've found the interrupt-map and are iterating over it
> attempting to match on PCI device addresses, there is this little
> fragment:
>
> /* Get the interrupt parent */
> if (of_irq_workarounds & OF_IMAP_NO_PHANDLE)
> newpar = of_node_get(of_irq_dflt_pic);
> else
> newpar =
> of_find_node_by_phandle((phandle)*imap);
> imap++;
> --imaplen;
>
> /* Check if not found */
> if (newpar == NULL) {
> DBG(" -> imap parent not found !\n");
> goto fail;
> }
>
> /* Get #interrupt-cells and #address-cells of new
> * parent
> */
> tmp = of_get_property(newpar, "#interrupt-cells", NULL);
> if (tmp == NULL) {
> DBG(" -> parent lacks #interrupt-cells !\n");
> goto fail;
> }
> newintsize = *tmp;
> tmp = of_get_property(newpar, "#address-cells", NULL);
> newaddrsize = (tmp == NULL) ? 0 : *tmp;
>
> Finally, later in the loop we update addrsize=newaddrsize
>
> As I read this code, and the behaviour I'm seeing, is that if the
> interrupt controller parent device doesn't have an #address-cells
> entry, then this get_property will return fail, therefore setting
> newaddrsize to zero. This then means that subsequent match attempts
> when iterating the interrupt-map always fail, because the match length
> (addrsize) is 0.
Correct. The interrupt-map property contains the following fields:
child-unit-address child-irq irq-controller irq-parent-unit-address parent-irq
In the *vast majority* of cases, the irq-parent-unit-address is a
zero-length field because #address-cells isn't present on the
interrupt controller parent. So effectively interrupt-map becomes:
child-unit-address child-irq irq-controller parent-irq
See epapr 1.0 for a full discussion
>
> Maybe I'm missing something here, but shouldn't this last bit of code
> instead be:
>
> tmp = of_get_property(newpar, "#address-cells", NULL);
> newaddrsize = (tmp == NULL) ? addrsize : *tmp;
>
> ^^^^^^^^^
> ?
>
> In other words, if the parent node has an #address-cells value, then
> use it, otherwise stick to the #address-cells value we picked up for
> the actual node in question (ie the PCI bridge).
No, because at this point we absolutely do want to know how big the
parent #address-cells is, and if it is missing, we need to use 0. If
the child's addrsize continued to be used, then the interrupt-map
parsing would get unaligned.
The inner loop is over the entries in interrupt-map. addrsize and
intsize are only updated in the case where a match is found in the
table. If a match isn't found, then it should bail out to the 'fail'
label.
> The way this is manifesting itself in the system I'm looking at is
> that only the PCI device matching the first entry in the PCI bridge
> interrupt-map property is correctly matching. For PCI devices that
> require more than one pass through the interrupt-map loop, addrsize
> goes to zero and no further match is possible.
Something sounds fishy. If you're still having problems, can you
enable #define DEBUG in drivers/of/irq.c and post the output?
> I might be able to hack around this in the device-tree by setting
> #address-cells=<3> in the interrupt controller node, but that doesn't
> smell right either - it's only true for PCI devices for a start,
> whereas this controller handles interrupts from many sources on the
> 32-bit PLB bus as well. I looked at the ML510 DTS in boot/dts and
> it's not doing anything like this.
Yeah, that's not right, and it would mess up the interrupt-map
parsing. You'd end up with more hard to debug problems.
g.
^ permalink raw reply
* Re: PPC: Possible bug in prom_parse.c:of_irq_map_raw?
From: Grant Likely @ 2010-10-07 18:34 UTC (permalink / raw)
To: John Williams
Cc: linuxppc-dev, devicetree-discuss, Linux Kernel list, Michal Simek
In-Reply-To: <1d3f23371002091921m7f47a1fbt1cf7fd2ef0a927fa@mail.gmail.com>
Reaching way back into the past....
John, did you ever solve your issue here? Comments below.
On Tue, Feb 9, 2010 at 8:21 PM, John Williams
<john.williams@petalogix.com> wrote:
> Hi,
>
> Perhaps this is my misunderstanding, but I'm looking at the bit of
> code in of_irq_map_raw() that iterates the interrupt-map DTS node,
> which I am seeing to behave strangely when handling the interrupt-map
> property on a PCI bridge node.
>
> Early in the function, we get the #address-cells value from the node -
> in this case the PCI bridge, and store it in local var addrsize:
>
> =A0 =A0 =A0 =A0/* Look for this #address-cells. We have to implement the =
old linux
> =A0 =A0 =A0 =A0 * trick of looking for the parent here as some device-tre=
es rely on it
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0old =3D of_node_get(ipar);
> =A0 =A0 =A0 =A0do {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(old, "#address-cel=
ls", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tnode =3D of_get_parent(old);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of_node_put(old);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0old =3D tnode;
> =A0 =A0 =A0 =A0} while(old && tmp =3D=3D NULL);
> =A0 =A0 =A0 =A0of_node_put(old);
> =A0 =A0 =A0 =A0old =3D NULL;
> =A0 =A0 =A0 =A0addrsize =3D (tmp =3D=3D NULL) ? 2 : *tmp;
>
> =A0 =A0 =A0 =A0DBG(" -> addrsize=3D%d\n", addrsize);
>
>
> Later, once we've found the interrupt-map and are iterating over it
> attempting to match on PCI device addresses, there is this little
> fragment:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Get the interrupt paren=
t */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (of_irq_workarounds & O=
F_IMAP_NO_PHANDLE)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newpar =3D=
of_node_get(of_irq_dflt_pic);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newpar =3D
> of_find_node_by_phandle((phandle)*imap);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0imap++;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0--imaplen;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Check if not found */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (newpar =3D=3D NULL) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DBG(" -> i=
map parent not found !\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto fail;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Get #interrupt-cells an=
d #address-cells of new
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * parent
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(ne=
wpar, "#interrupt-cells", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (tmp =3D=3D NULL) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DBG(" -> p=
arent lacks #interrupt-cells !\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto fail;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newintsize =3D *tmp;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(ne=
wpar, "#address-cells", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newaddrsize =3D (tmp =3D=
=3D NULL) ? 0 : *tmp;
>
> Finally, later in the loop we update addrsize=3Dnewaddrsize
>
> As I read this code, and the behaviour I'm seeing, is that if the
> interrupt controller parent device doesn't have an #address-cells
> entry, then this get_property will return fail, therefore setting
> newaddrsize =A0to zero. =A0This then means that subsequent match attempts
> when iterating the interrupt-map always fail, because the match length
> (addrsize) is 0.
Correct. The interrupt-map property contains the following fields:
child-unit-address child-irq irq-controller irq-parent-unit-address parent-=
irq
In the *vast majority* of cases, the irq-parent-unit-address is a
zero-length field because #address-cells isn't present on the
interrupt controller parent. So effectively interrupt-map becomes:
child-unit-address child-irq irq-controller parent-irq
See epapr 1.0 for a full discussion
>
> Maybe I'm missing something here, but shouldn't this last bit of code
> instead be:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tmp =3D of_get_property(ne=
wpar, "#address-cells", NULL);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0newaddrsize =3D (tmp =3D=
=3D NULL) ? addrsize : *tmp;
>
> =A0^^^^^^^^^
> ?
>
> In other words, if the parent node has an #address-cells value, then
> use it, otherwise stick to the #address-cells value we picked up for
> the actual node in question (ie the PCI bridge).
No, because at this point we absolutely do want to know how big the
parent #address-cells is, and if it is missing, we need to use 0. If
the child's addrsize continued to be used, then the interrupt-map
parsing would get unaligned.
The inner loop is over the entries in interrupt-map. addrsize and
intsize are only updated in the case where a match is found in the
table. If a match isn't found, then it should bail out to the 'fail'
label.
> The way this is manifesting itself in the system I'm looking at is
> that only the PCI device matching the first entry in the PCI bridge
> interrupt-map property is correctly matching. For PCI devices that
> require more than one pass through the interrupt-map loop, addrsize
> goes to zero and no further match is possible.
Something sounds fishy. If you're still having problems, can you
enable #define DEBUG in drivers/of/irq.c and post the output?
> I might be able to hack around this in the device-tree by setting
> #address-cells=3D<3> in the interrupt controller node, but that doesn't
> smell right either - it's only true for PCI devices for a start,
> whereas this controller handles interrupts from many sources on the
> 32-bit PLB bus as well. =A0I looked at the ML510 DTS in boot/dts and
> it's not doing anything like this.
Yeah, that's not right, and it would mess up the interrupt-map
parsing. You'd end up with more hard to debug problems.
g.
^ permalink raw reply
* Re: [PATCH v2 00/11] SDIO Runtime PM Support
From: Ohad Ben-Cohen @ 2010-10-07 18:33 UTC (permalink / raw)
To: Chris Ball
Cc: Luciano Coelho, linux-mmc@vger.kernel.org,
linux-wireless@vger.kernel.org, Nicolas Pitre
In-Reply-To: <20101007180107.GA15745@void.printf.net>
On Thu, Oct 7, 2010 at 8:01 PM, Chris Ball <cjb@laptop.org> wrote:
> Yes, can do -- the patchset looks good, and I've just pushed patches
> 1-9 (the MMC patches) to mmc-next.
Thanks, Chris.
> Please go ahead and submit the
> two wl1271 patches through wireless-testing whenever you're ready.
>
> Thanks!
>
> --
> Chris Ball <cjb@laptop.org> <http://printf.net/>
> One Laptop Per Child
>
^ permalink raw reply
* Re: git log doesn't allow %x00 in custom format anymore?
From: Jeff King @ 2010-10-07 18:33 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Matthieu Moy, Kirill Likhodedov, Johannes Sixt, git
In-Reply-To: <AANLkTikkZaCQKFTnQ=k2Ajp_6mVRd6mrP1P7bEASEGgd@mail.gmail.com>
On Thu, Oct 07, 2010 at 08:19:01PM +0200, Erik Faye-Lund wrote:
> Yeah. When I read K&R a bit closer, I find this:
>
> "A number specifying a minimum field width. The converted argument
> will be printed in a field _at least this wide_, and wider if
> necessary. If the converted argument has fewer characters than the
> field width _it will be padded_ on the left (or right, if left
> adjustment has been requested) to make up the field width."
You are confusing field width (%*s) with precision (%.*s) here.
C89 is pretty clear that the behavior I am seeing is mandated:
7.19.6.1, paragraph 4:
An optional precision that gives ... the maximum number of bytes to
be written for s conversions.
7.19.6.1, paragraph 8, item "s":
... Characters from the array are written up to (but not including)
the terminating null character. If the precision is specified, no
more than that many bytes are written. If the precision is not
specified or is greater than the size of the array, the array shall
contain a null character.
so it is always about giving a maximum to print an unterminated string,
or to print a partial string. But printf always stops at a NUL.
-Peff
^ permalink raw reply
* [xen-unstable test] 2343: regressions - FAIL
From: xen.org @ 2010-10-07 18:32 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 2343 xen-unstable real
http://www.chiark.greenend.org.uk/~xensrcts/logs/2343/
Regressions :-(
tests which did not succeed:
build-amd64-oldkern 1 xen-build fail REGR. vs. 2132
build-amd64 3 xen-build fail REGR. vs. 2132
build-i386-oldkern 1 xen-build fail REGR. vs. 2132
build-i386 3 xen-build fail REGR. vs. 2132
test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a
test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a
test-amd64-amd64-win 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a
test-amd64-i386-pair 1 xen-build-check(1) blocked n/a
test-amd64-i386-pv 1 xen-build-check(1) blocked n/a
test-amd64-i386-win 1 xen-build-check(1) blocked n/a
test-amd64-i386-xl 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-pair 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-pv 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-win 1 xen-build-check(1) blocked n/a
test-amd64-xcpkern-i386-xl 1 xen-build-check(1) blocked n/a
test-i386-i386-pair 1 xen-build-check(1) blocked n/a
test-i386-i386-pv 1 xen-build-check(1) blocked n/a
test-i386-i386-win 1 xen-build-check(1) blocked n/a
test-i386-i386-xl 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-pair 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-pv 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-win 1 xen-build-check(1) blocked n/a
test-i386-xcpkern-i386-xl 1 xen-build-check(1) blocked n/a
version targeted for testing:
xen 1385b15e168f
baseline version:
xen 5393151a737b
jobs:
build-i386-xcpkern pass
build-amd64 fail
build-i386 fail
build-amd64-oldkern fail
build-i386-oldkern fail
test-amd64-amd64-xl blocked
test-amd64-i386-xl blocked
test-i386-i386-xl blocked
test-amd64-xcpkern-i386-xl blocked
test-i386-xcpkern-i386-xl blocked
test-amd64-amd64-pair blocked
test-amd64-i386-pair blocked
test-i386-i386-pair blocked
test-amd64-xcpkern-i386-pair blocked
test-i386-xcpkern-i386-pair blocked
test-amd64-amd64-pv blocked
test-amd64-i386-pv blocked
test-i386-i386-pv blocked
test-amd64-xcpkern-i386-pv blocked
test-i386-xcpkern-i386-pv blocked
test-amd64-amd64-win blocked
test-amd64-i386-win blocked
test-i386-i386-win blocked
test-amd64-xcpkern-i386-win blocked
test-i386-xcpkern-i386-win blocked
-------------------------------------------------------------------------------
build-i386-xcpkern:
1 kernel-build pass
linux 110879:32fc6955a6a5
pq_linux 156:7eea17db9add
-------------------------------------------------------------------------------
build-amd64:
1 host-install(1) pass
2 host-build-prep pass
3 xen-build fail
linux 179eca50d08fa05d7650
qemu f95d202ed6444dacb15f
xen 22229:1385b15e168f
-------------------------------------------------------------------------------
build-i386:
1 host-install(1) pass
2 host-build-prep pass
3 xen-build fail
linux 179eca50d08fa05d7650
qemu f95d202ed6444dacb15f
xen 22229:1385b15e168f
-------------------------------------------------------------------------------
build-amd64-oldkern:
1 xen-build fail
linux 1041:5dd203fba380
qemu f95d202ed6444dacb15f
xen 22229:1385b15e168f
-------------------------------------------------------------------------------
build-i386-oldkern:
1 xen-build fail
linux 1041:5dd203fba380
qemu f95d202ed6444dacb15f
xen 22229:1385b15e168f
-------------------------------------------------------------------------------
test-amd64-amd64-xl:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-amd64-i386-xl:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-i386-i386-xl:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-amd64-xcpkern-i386-xl:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-i386-xcpkern-i386-xl:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-amd64-amd64-pair:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-amd64-i386-pair:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-i386-i386-pair:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-amd64-xcpkern-i386-pair:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-i386-xcpkern-i386-pair:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-amd64-amd64-pv:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-amd64-i386-pv:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-i386-i386-pv:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-amd64-xcpkern-i386-pv:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-i386-xcpkern-i386-pv:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-amd64-amd64-win:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-amd64-i386-win:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-i386-i386-win:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-amd64-xcpkern-i386-win:
1 xen-build-check(1) blocked
-------------------------------------------------------------------------------
test-i386-xcpkern-i386-win:
1 xen-build-check(1) blocked
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
^ permalink raw reply
* XEN 4.0 error
From: jaap @ 2010-10-07 18:32 UTC (permalink / raw)
To: xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 4538 bytes --]
Hello,
I want to attach a usb device to my xpdomU and get the following error:
debDom0:/var/log/xen# xm usb-list winxp1t.computadora.nl
Idx BE state usb-ver BE-path
0 0 1 USB2.0 /local/domain/0/backend/vusb/8/0
port 1:
port 2:
port 3:
port 4:
debDom0:/var/log/xen# xm usb-list-assignable-devices
1-2 : ID 0b38:0003 Virtual USB MULTIMEDIA KEYBOARD
1-7 : ID 0566:3006 Monterey International Corp.
2-5 : ID 1307:0190 USBest Technology USB Mass Storage Device
2-9 : ID 04a9:172e Canon MP630 series
debDom0:/var/log/xen# xm usb-attach winxp1t.computadora.nl 0 1 2-9
Unexpected error: <class 'xen.util.vusb_util.UsbDeviceParseError'>
Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
File "/usr/lib/xen-4.0/bin/xm", line 8, in <module>
main.main(sys.argv)
File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3620, in main
_, rc = _run_cmd(cmd, cmd_name, args)
File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 3644, in _run_cmd
return True, cmd(args)
File "/usr/lib/xen-4.0/lib/python/xen/xm/main.py", line 2868, in xm_usb_attach
if vusb_util.bus_is_assigned(bus):
File "/usr/lib/xen-4.0/lib/python/xen/util/vusb_util.py", line 275, in bus_is_assigned
raise UsbDeviceParseError("Can't get assignment status: (%s)." % bus)
xen.util.vusb_util.UsbDeviceParseError: vusb: Error parsing USB device info: Can't get assignment status: (2-9).
**********************
debDom0:/var/log/xen# uname -a
Linux debDom0 2.6.32-5-xen-amd64 #1 SMP Thu Sep 30 05:47:47 UTC 2010 x86_64 GNU/Linux
debDom0:/var/log/xen# xm info
host : debDom0
release : 2.6.32-5-xen-amd64
version : #1 SMP Thu Sep 30 05:47:47 UTC 2010
machine : x86_64
nr_cpus : 2
nr_nodes : 1
cores_per_socket : 2
threads_per_core : 1
cpu_mhz : 1809
hw_caps : 178bf3ff:ebd3fbff:00000000:00000010:00002001:00000000:0000001f:00000000
virt_caps : hvm
total_memory : 4095
free_memory : 8
node_to_cpu : node0:0-1
node_to_memory : node0:8
node_to_dma32_mem : node0:8
max_node_id : 0
xen_major : 4
xen_minor : 0
xen_extra : .1
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset : unavailable
xen_commandline :
cc_compiler : gcc version 4.4.5 20100824 (prerelease) (Debian 4.4.4-11)
cc_compile_by : waldi
cc_compile_domain : debian.org
cc_compile_date : Fri Sep 3 15:38:12 UTC 2010
xend_config_format : 4
debDom0:/var/log/xen# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 2210
stepping : 3
cpu MHz : 1809.322
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good extd_apicid pni cx16 hypervisor lahf_lm cmp_legacy extapic cr8_legacy
bogomips : 3618.64
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm) Processor 2210
stepping : 3
cpu MHz : 1809.322
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr pae mce cx8 apic mtrr mca cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good extd_apicid pni cx16 hypervisor lahf_lm cmp_legacy extapic cr8_legacy
bogomips : 3618.64
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
If you want to know something more please let me know, bye
Jaap Gerritsen, The Netherlands
[-- Attachment #1.2: Type: text/html, Size: 9263 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH,V2 0/6] libtool 2.4 upgrade
From: Khem Raj @ 2010-10-07 18:31 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <i8jufe$299$1@dough.gmane.org>
On Thu, Oct 7, 2010 at 12:56 AM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07-10-10 03:46, Khem Raj wrote:
>> Hi
>>
>> Following set of patches is v2 of the patches adding support for getting libtool 2.4 into
>> openemebedded. I have so far built minimal-image for two machines successfully using old
>> and new libtool.
>>
>> The libtool sysroot feature knob is added through LIBTOOL_HAS_SYSROOT variable. If this is
>> set to "yes" then you ought to use libtool > 2.4 by default its set to "no" which means
>> the current behavior remains.
>>
>> The big change that libtool 2.4 brings is sysroot support and I have added
>> support to use this feature. It should make our life easier.
>>
>> This needs a lot of testing.
>>
>> Please cherry pick the patch bundle and give it a try in yout environment
>
> Can you apply these to a branch so we can add fixes there if needed?
I can do that. However now that backward compatibility is left intact I think
it would not be that bad to merge it into master and fix things on
master. the libtool
2.4 would have DEFAULT_PREFERENCE = "-1" by default it wont be picked by anyone.
with the number of developers we have it will get better testing before we
accumulate too many changes on a branch. Secondly there might be changes like
gnutls one where the patch is only valid for new libtool and should be tested
in old and new way. If there is any breakage introduced in existing build will
be caught quickly. Where as on branch resources might be divided and it may
not progress so well. I am just weighing efforts Vs. risk here and
risk seems low
Thanks
-Khem
>
>>
>> Some distros pin libtool version to 2.2.6b
>>
>> include/preferred-slugos-versions.inc
>> include/angstrom-2008-preferred-versions.inc
>> include/kaeilos-2009-preferred-versions.inc
>> include/angstrom-2010-preferred-versions.inc
>> include/preferred-shr-versions.inc
>>
>> So if you are using one of these distro's then you might have
>> to override the version in your local.conf
>>
>> LIBTOOL_HAS_SYSROOT = "yes"
>> LIBTOOL_VER = "2.4"
>> PREFERRED_VERSION_libtool = "${LIBTOOL_VER}"
>> PREFERRED_VERSION_libtool-native = "${LIBTOOL_VER}"
>> PREFERRED_VERSION_libtool-cross = "${LIBTOOL_VER}"
>> PREFERRED_VERSION_libtool-nativesdk = "${LIBTOOL_VER}"
>> PREFERRED_VERSION_libtool-sdk = "${LIBTOOL_VER}"
>>
>> Please review, test, and provide feedback
>>
>> Thanks
>>
>> -Khem
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFMrX0uMkyGM64RGpERAjNfAJ0eRV99dBkIAeDKsE/4GA9DTZcvXwCfZitH
> pXRfV3B7U2f48NSxGcDq/wE=
> =lbRD
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
^ permalink raw reply
* Re: [PATCH 0/4] memblock related fixes for -tip
From: Jeremy Fitzhardinge @ 2010-10-07 18:31 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Yinghai Lu, Thomas Gleixner, Ingo Molnar, Benjamin Herrenschmidt,
linux-kernel@vger.kernel.org, Vivek Goyal
In-Reply-To: <4CACFF66.5080609@zytor.com>
On 10/06/2010 03:59 PM, H. Peter Anvin wrote:
> On 10/06/2010 03:57 PM, Yinghai Lu wrote:
>> How about
>> + if (memblock.memory.regions)
>> + return;
>>
> I was just about to ask the same question. ;)
I don't mind either way. I haven't really looked at how memblock works,
so I wasn't sure if that was completely sufficient.
J
^ permalink raw reply
* Re: Vendor specific data within a beacon frame
From: Luis R. Rodriguez @ 2010-10-07 18:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: Bjoern Czybik, linux-wireless
In-Reply-To: <1286475342.20974.23.camel@jlt3.sipsolutions.net>
On Thu, Oct 7, 2010 at 11:15 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2010-10-07 at 11:11 -0700, Luis R. Rodriguez wrote:
>
> Let me quote what you wrote, but just partially:
>
>> This can be done from userspace. This is from nl80211.h:
>
>> * Note: This command has been removed and it is only reserved at this
>> * point to avoid re-using existing command number. The functionality this
>> * command was planned for has been provided with cleaner design with the
>> * option to specify additional IEs in NL80211_CMD_TRIGGER_SCAN,
>> * NL80211_CMD_AUTHENTICATE, NL80211_CMD_ASSOCIATE,
>> * NL80211_CMD_DEAUTHENTICATE, and NL80211_CMD_DISASSOCIATE.
>
> :P
Yeah just noticed *after* I pasted it and sent it. Does hostapd use
this currently?
Luis
^ permalink raw reply
* Re: memory clobber in rx path, maybe related to ath9k.
From: Luis R. Rodriguez @ 2010-10-07 18:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: Ben Greear, linux-wireless@vger.kernel.org
In-Reply-To: <1286475250.20974.22.camel@jlt3.sipsolutions.net>
On Thu, Oct 7, 2010 at 11:14 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2010-10-07 at 10:33 -0700, Ben Greear wrote:
>> In case it helps, here is a dump of where the corrupted SKB was deleted.
>
> I wonder, do you have a machine with a decent IOMMU? Adding IOMMU
> debugging into the mix could help you figure out if it's a DMA problem.
Ben, how much traffic are you RX'ing on these virtual interfaces?
Luis
^ permalink raw reply
* [PATCH] iovmm: IVA2 MMU range is from 0x11000000 to 0xFFFFFFFF
From: Fernando Guzman Lugo @ 2010-10-07 18:43 UTC (permalink / raw)
To: Hiroshi.DOYU
Cc: felipe.contreras, ameya.palande, david.cohen, linux-kernel,
andy.shevchenko, linux-omap, Fernando Guzman Lugo
IV2 MMU capable addresses start from 0x11000000
Signed-off-by: Fernando Guzman Lugo <x0095840@ti.com>
---
arch/arm/plat-omap/iovmm.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
index 75965a1..c0344f4 100644
--- a/arch/arm/plat-omap/iovmm.c
+++ b/arch/arm/plat-omap/iovmm.c
@@ -286,7 +286,12 @@ static struct iovm_struct *alloc_iovm_area(struct iommu *obj, u32 da,
/*
* Reserve the first page for NULL
*/
- start = PAGE_SIZE;
+ if (!strcmp(obj->name, "iva2"))
+ /* IVA2 MMU control starts from 0x11000000 */
+ start = 0x11000000;
+ else
+ start = PAGE_SIZE;
+
if (flags & IOVMF_LINEAR)
alignement = iopgsz_max(bytes);
start = roundup(start, alignement);
--
1.6.3.3
^ permalink raw reply related
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.