* Re: [Qemu-devel] [PATCH] pci_bridge: fix typo
From: Blue Swirl @ 2011-10-23 20:03 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel
In-Reply-To: <4E9AF419.9040405@redhat.com>
On Sun, Oct 16, 2011 at 15:11, Avi Kivity <avi@redhat.com> wrote:
> On 10/16/2011 04:44 PM, Blue Swirl wrote:
>> Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
>> ---
>> hw/pci_bridge.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c
>> index b6287cd..650d165 100644
>> --- a/hw/pci_bridge.c
>> +++ b/hw/pci_bridge.c
>> @@ -319,7 +319,7 @@ int pci_bridge_initfn(PCIDevice *dev)
>> sec_bus->parent_dev = dev;
>> sec_bus->map_irq = br->map_irq;
>> sec_bus->address_space_mem = &br->address_space_mem;
>> - memory_region_init(&br->address_space_mem, "pci_pridge_pci", INT64_MAX);
>> + memory_region_init(&br->address_space_mem, "pci_bridge_pci", INT64_MAX);
>> sec_bus->address_space_io = &br->address_space_io;
>> memory_region_init(&br->address_space_io, "pci_bridge_io", 65536);
>> pci_bridge_region_init(br);
>
> Reviewed-by: Avi Kivity <avi@redhat.com>
Thanks for the review, applied.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V5] Add stdio char device on windows
From: Blue Swirl @ 2011-10-23 20:05 UTC (permalink / raw)
To: Fabien Chouteau; +Cc: pbonzini, yann.fc.quelen, mars, qemu-devel
In-Reply-To: <1317911871-20760-1-git-send-email-chouteau@adacore.com>
Thanks, applied.
On Thu, Oct 6, 2011 at 14:37, Fabien Chouteau <chouteau@adacore.com> wrote:
> Simple implementation of an stdio char device on Windows.
>
> Signed-off-by: Fabien Chouteau <chouteau@adacore.com>
> ---
> qemu-char.c | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 files changed, 225 insertions(+), 2 deletions(-)
>
> diff --git a/qemu-char.c b/qemu-char.c
> index 09d2309..b9381be 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -538,6 +538,9 @@ int send_all(int fd, const void *_buf, int len1)
> }
> #endif /* !_WIN32 */
>
> +#define STDIO_MAX_CLIENTS 1
> +static int stdio_nb_clients;
> +
> #ifndef _WIN32
>
> typedef struct {
> @@ -545,8 +548,6 @@ typedef struct {
> int max_size;
> } FDCharDriver;
>
> -#define STDIO_MAX_CLIENTS 1
> -static int stdio_nb_clients = 0;
>
> static int fd_chr_write(CharDriverState *chr, const uint8_t *buf, int len)
> {
> @@ -1451,6 +1452,8 @@ static int qemu_chr_open_pp(QemuOpts *opts, CharDriverState **_chr)
>
> #else /* _WIN32 */
>
> +static CharDriverState *stdio_clients[STDIO_MAX_CLIENTS];
> +
> typedef struct {
> int max_size;
> HANDLE hcom, hrecv, hsend;
> @@ -1459,6 +1462,14 @@ typedef struct {
> DWORD len;
> } WinCharState;
>
> +typedef struct {
> + HANDLE hStdIn;
> + HANDLE hInputReadyEvent;
> + HANDLE hInputDoneEvent;
> + HANDLE hInputThread;
> + uint8_t win_stdio_buf;
> +} WinStdioCharState;
> +
> #define NSENDBUF 2048
> #define NRECVBUF 2048
> #define MAXCONNECT 1
> @@ -1809,6 +1820,217 @@ static int qemu_chr_open_win_file_out(QemuOpts *opts, CharDriverState **_chr)
>
> return qemu_chr_open_win_file(fd_out, _chr);
> }
> +
> +static int win_stdio_write(CharDriverState *chr, const uint8_t *buf, int len)
> +{
> + HANDLE hStdOut = GetStdHandle(STD_OUTPUT_HANDLE);
> + DWORD dwSize;
> + int len1;
> +
> + len1 = len;
> +
> + while (len1 > 0) {
> + if (!WriteFile(hStdOut, buf, len1, &dwSize, NULL)) {
> + break;
> + }
> + buf += dwSize;
> + len1 -= dwSize;
> + }
> +
> + return len - len1;
> +}
> +
> +static void win_stdio_wait_func(void *opaque)
> +{
> + CharDriverState *chr = opaque;
> + WinStdioCharState *stdio = chr->opaque;
> + INPUT_RECORD buf[4];
> + int ret;
> + DWORD dwSize;
> + int i;
> +
> + ret = ReadConsoleInput(stdio->hStdIn, buf, sizeof(buf) / sizeof(*buf),
> + &dwSize);
> +
> + if (!ret) {
> + /* Avoid error storm */
> + qemu_del_wait_object(stdio->hStdIn, NULL, NULL);
> + return;
> + }
> +
> + for (i = 0; i < dwSize; i++) {
> + KEY_EVENT_RECORD *kev = &buf[i].Event.KeyEvent;
> +
> + if (buf[i].EventType == KEY_EVENT && kev->bKeyDown) {
> + int j;
> + if (kev->uChar.AsciiChar != 0) {
> + for (j = 0; j < kev->wRepeatCount; j++) {
> + if (qemu_chr_be_can_write(chr)) {
> + uint8_t c = kev->uChar.AsciiChar;
> + qemu_chr_be_write(chr, &c, 1);
> + }
> + }
> + }
> + }
> + }
> +}
> +
> +static DWORD WINAPI win_stdio_thread(LPVOID param)
> +{
> + CharDriverState *chr = param;
> + WinStdioCharState *stdio = chr->opaque;
> + int ret;
> + DWORD dwSize;
> +
> + while (1) {
> +
> + /* Wait for one byte */
> + ret = ReadFile(stdio->hStdIn, &stdio->win_stdio_buf, 1, &dwSize, NULL);
> +
> + /* Exit in case of error, continue if nothing read */
> + if (!ret) {
> + break;
> + }
> + if (!dwSize) {
> + continue;
> + }
> +
> + /* Some terminal emulator returns \r\n for Enter, just pass \n */
> + if (stdio->win_stdio_buf == '\r') {
> + continue;
> + }
> +
> + /* Signal the main thread and wait until the byte was eaten */
> + if (!SetEvent(stdio->hInputReadyEvent)) {
> + break;
> + }
> + if (WaitForSingleObject(stdio->hInputDoneEvent, INFINITE)
> + != WAIT_OBJECT_0) {
> + break;
> + }
> + }
> +
> + qemu_del_wait_object(stdio->hInputReadyEvent, NULL, NULL);
> + return 0;
> +}
> +
> +static void win_stdio_thread_wait_func(void *opaque)
> +{
> + CharDriverState *chr = opaque;
> + WinStdioCharState *stdio = chr->opaque;
> +
> + if (qemu_chr_be_can_write(chr)) {
> + qemu_chr_be_write(chr, &stdio->win_stdio_buf, 1);
> + }
> +
> + SetEvent(stdio->hInputDoneEvent);
> +}
> +
> +static void qemu_chr_set_echo_win_stdio(CharDriverState *chr, bool echo)
> +{
> + WinStdioCharState *stdio = chr->opaque;
> + DWORD dwMode = 0;
> +
> + GetConsoleMode(stdio->hStdIn, &dwMode);
> +
> + if (echo) {
> + SetConsoleMode(stdio->hStdIn, dwMode | ENABLE_ECHO_INPUT);
> + } else {
> + SetConsoleMode(stdio->hStdIn, dwMode & ~ENABLE_ECHO_INPUT);
> + }
> +}
> +
> +static void win_stdio_close(CharDriverState *chr)
> +{
> + WinStdioCharState *stdio = chr->opaque;
> +
> + if (stdio->hInputReadyEvent != INVALID_HANDLE_VALUE) {
> + CloseHandle(stdio->hInputReadyEvent);
> + }
> + if (stdio->hInputDoneEvent != INVALID_HANDLE_VALUE) {
> + CloseHandle(stdio->hInputDoneEvent);
> + }
> + if (stdio->hInputThread != INVALID_HANDLE_VALUE) {
> + TerminateThread(stdio->hInputThread, 0);
> + }
> +
> + g_free(chr->opaque);
> + g_free(chr);
> + stdio_nb_clients--;
> +}
> +
> +static int qemu_chr_open_win_stdio(QemuOpts *opts, CharDriverState **_chr)
> +{
> + CharDriverState *chr;
> + WinStdioCharState *stdio;
> + DWORD dwMode;
> + int is_console = 0;
> +
> + if (stdio_nb_clients >= STDIO_MAX_CLIENTS
> + || ((display_type != DT_NOGRAPHIC) && (stdio_nb_clients != 0))) {
> + return -EIO;
> + }
> +
> + chr = g_malloc0(sizeof(CharDriverState));
> + stdio = g_malloc0(sizeof(WinStdioCharState));
> +
> + stdio->hStdIn = GetStdHandle(STD_INPUT_HANDLE);
> + if (stdio->hStdIn == INVALID_HANDLE_VALUE) {
> + fprintf(stderr, "cannot open stdio: invalid handle\n");
> + exit(1);
> + }
> +
> + is_console = GetConsoleMode(stdio->hStdIn, &dwMode) != 0;
> +
> + chr->opaque = stdio;
> + chr->chr_write = win_stdio_write;
> + chr->chr_close = win_stdio_close;
> +
> + if (stdio_nb_clients == 0) {
> + if (is_console) {
> + if (qemu_add_wait_object(stdio->hStdIn,
> + win_stdio_wait_func, chr)) {
> + fprintf(stderr, "qemu_add_wait_object: failed\n");
> + }
> + } else {
> + DWORD dwId;
> +
> + stdio->hInputReadyEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
> + stdio->hInputDoneEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
> + stdio->hInputThread = CreateThread(NULL, 0, win_stdio_thread,
> + chr, 0, &dwId);
> +
> + if (stdio->hInputThread == INVALID_HANDLE_VALUE
> + || stdio->hInputReadyEvent == INVALID_HANDLE_VALUE
> + || stdio->hInputDoneEvent == INVALID_HANDLE_VALUE) {
> + fprintf(stderr, "cannot create stdio thread or event\n");
> + exit(1);
> + }
> + if (qemu_add_wait_object(stdio->hInputReadyEvent,
> + win_stdio_thread_wait_func, chr)) {
> + fprintf(stderr, "qemu_add_wait_object: failed\n");
> + }
> + }
> + }
> +
> + dwMode |= ENABLE_LINE_INPUT;
> +
> + stdio_clients[stdio_nb_clients++] = chr;
> + if (stdio_nb_clients == 1 && is_console) {
> + /* set the terminal in raw mode */
> + /* ENABLE_QUICK_EDIT_MODE | ENABLE_EXTENDED_FLAGS */
> + dwMode |= ENABLE_PROCESSED_INPUT;
> + }
> +
> + SetConsoleMode(stdio->hStdIn, dwMode);
> +
> + chr->chr_set_echo = qemu_chr_set_echo_win_stdio;
> + qemu_chr_fe_set_echo(chr, false);
> +
> + *_chr = chr;
> +
> + return 0;
> +}
> #endif /* !_WIN32 */
>
> /***********************************************************/
> @@ -2519,6 +2741,7 @@ static const struct {
> { .name = "pipe", .open = qemu_chr_open_win_pipe },
> { .name = "console", .open = qemu_chr_open_win_con },
> { .name = "serial", .open = qemu_chr_open_win },
> + { .name = "stdio", .open = qemu_chr_open_win_stdio },
> #else
> { .name = "file", .open = qemu_chr_open_file_out },
> { .name = "pipe", .open = qemu_chr_open_pipe },
> --
> 1.7.4.1
>
>
^ permalink raw reply
* [U-Boot] [PATCH] spi/eon: add support for new EON spi flash EN25Q32B
From: Wolfgang Denk @ 2011-10-23 20:08 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1317122494-13562-1-git-send-email-Shaohui.Xie@freescale.com>
Dear Shaohui Xie,
In message <1317122494-13562-1-git-send-email-Shaohui.Xie@freescale.com> you wrote:
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> drivers/mtd/spi/eon.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
Applied, thanks.
Best regards,
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
Certain old men prefer to rise at dawn, taking a cold bath and a long
walk with an empty stomach and otherwise mortifying the flesh. They
then point with pride to these practices as the cause of their sturdy
health and ripe years; the truth being that they are hearty and old,
not because of their habits, but in spite of them. The reason we find
only robust persons doing this thing is that it has killed all the
others who have tried it. - Ambrose Bierce, "The Devil's Dictionary"
^ permalink raw reply
* [PATCH 0/3] ARM 4Kstacks: introduction
From: Russell King - ARM Linux @ 2011-10-23 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA46A16.5080005@am.sony.com>
On Sun, Oct 23, 2011 at 12:25:10PM -0700, Tim Bird wrote:
> We have about 50 hard real-time threads, that are part of a
> software stack for digital cameras that was ported over from
> micro-itron. It has taken a _LONG_ time (on the order of a
> few years) to tune the Linux system using RT-preempt to run
> these threads as is. It would be very painful to re-architect this
> part of the system.
>
> Note that these threads don't have any of the issues that
> people have raised about filesystem stack depth or printk
> recursion, since they avoid a whole range of Linux syscalls
> to avoid real-time issues (and stack size issues).
>
> I'm looking at possibly implementing a mixed stack
> size system, but I don't know if that will work, or whether
> it would be acceptable upstream.
I can't see how it would work, because the extremes of the kernel stack
are rather fixed. At the top of the stack, we have the kernel stack
growing downwards. At the bottom of the stack, we have the thread_info
structure.
If we have different stack sizes depending on the thread which is running,
you have a catch-22 situation - you need some per-thread data to find
out how large the kernel stack is, and that can't be stored in the
thread_info struct because to find that you need to know how large the
kernel stack is.
>> If memory fragmentation is an issue for this, it probably means that we
>> need to switch to a software page size of 8K (or maybe 16K) rather than
>> stick with the hardware 4K size. That would be a much more reliable
>> solution, especially as the L1 page table is 16K (if you're suffering
>> from memory fragmentation, the first thing which'd get you is the L1
>> page table allocation, not the kernel stack allocation.)
So, the reason you don't have a problem with this is because you're
running 50 threads of the _same_ process, which are all sharing the
same L1 page table. That information has a direct bearing on this
discussion.
>> The possibility of a kernel stack overflow is not something that should
>> be taken lightly
> Agreed.
>
> This kind of development is done with extensive in-house testing,
> and an absolutely fixed users space. This may sound like an
> isolated case, but I know Sony is not alone and that lots of
> embedded products are developed like this. I'm pretty sure
> others would benefit from this patch.
>
> We've already shipped tens of thousands of cameras
> with this, with no problems, so it's certainly possible to get it
> right.
>
> Whether to include this comes down to a question of whether
> the ability of someone to get it wrong should preclude
> allowing the *option* into the kernel.
Given this comment, I assume you've already measured how much kernel
stack gets used, and would be able to provide those figures?
The kernel can give you this if you enable CONFIG_DEBUG_STACK_USAGE. The
kernel will then report whenever a thread exits having used more kernel
stack than any previous exiting thread.
^ permalink raw reply
* Re: [CONSOLIDATED PULL 24/27] texi2html: Added recipe from OE
From: Khem Raj @ 2011-10-23 20:06 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <9d70a72f5ab24bc0424f11311c8eb6b19f3d2987.1319394187.git.sgw@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
On Sunday, October 23, 2011, Saul Wold <sgw@linux.intel.com> wrote:
> Needed to build oe-core with oe-core
Oe-Core with oe-core did u mean meta-oe in one place ?
>
> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> ---
> meta/recipes-extended/texi2html/texi2html_1.82.bb | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
> create mode 100644 meta/recipes-extended/texi2html/texi2html_1.82.bb
>
> diff --git a/meta/recipes-extended/texi2html/texi2html_1.82.bbb/meta/recipes-extended/texi2html/
texi2html_1.82.bb
> new file mode 100644
> index 0000000..f19b576
> --- /dev/null
> +++ b/meta/recipes-extended/texi2html/texi2html_1.82.bb
> @@ -0,0 +1,14 @@
> +DESCRIPTION = "Perl script that converts Texinfo to HTML"
> +HOMEPAGE = "http://www.nongnu.org/texi2html/"
> +SECTION = "console/utils"
> +LICENSE = "GPLv2"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552"
> +
> +PR = "r0"
> +
> +SRC_URI = "
http://download.savannah.gnu.org/releases/texi2html/${P}.tar.bz2"
> +
> +SRC_URI[md5sum] = "a8a9193c0ac1bec2f3ca7be40a5a82eb"
> +SRC_URI[sha256sum] =
"d69c1effc416896409003ea64fdb21152cc0a9a7c665d437a0a3bef9b588b4f1"
> +
> +inherit autotools
> --
> 1.7.6.4
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 2343 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] ARM 4Kstacks: introduction
From: Russell King - ARM Linux @ 2011-10-23 20:11 UTC (permalink / raw)
To: Tim Bird
Cc: Ming Lei, Arnd Bergmann, linux-arm-kernel@lists.infradead.org,
Joe Perches, linux kernel, Andi Kleen, Thomas Gleixner, mem
In-Reply-To: <4EA46A16.5080005@am.sony.com>
On Sun, Oct 23, 2011 at 12:25:10PM -0700, Tim Bird wrote:
> We have about 50 hard real-time threads, that are part of a
> software stack for digital cameras that was ported over from
> micro-itron. It has taken a _LONG_ time (on the order of a
> few years) to tune the Linux system using RT-preempt to run
> these threads as is. It would be very painful to re-architect this
> part of the system.
>
> Note that these threads don't have any of the issues that
> people have raised about filesystem stack depth or printk
> recursion, since they avoid a whole range of Linux syscalls
> to avoid real-time issues (and stack size issues).
>
> I'm looking at possibly implementing a mixed stack
> size system, but I don't know if that will work, or whether
> it would be acceptable upstream.
I can't see how it would work, because the extremes of the kernel stack
are rather fixed. At the top of the stack, we have the kernel stack
growing downwards. At the bottom of the stack, we have the thread_info
structure.
If we have different stack sizes depending on the thread which is running,
you have a catch-22 situation - you need some per-thread data to find
out how large the kernel stack is, and that can't be stored in the
thread_info struct because to find that you need to know how large the
kernel stack is.
>> If memory fragmentation is an issue for this, it probably means that we
>> need to switch to a software page size of 8K (or maybe 16K) rather than
>> stick with the hardware 4K size. That would be a much more reliable
>> solution, especially as the L1 page table is 16K (if you're suffering
>> from memory fragmentation, the first thing which'd get you is the L1
>> page table allocation, not the kernel stack allocation.)
So, the reason you don't have a problem with this is because you're
running 50 threads of the _same_ process, which are all sharing the
same L1 page table. That information has a direct bearing on this
discussion.
>> The possibility of a kernel stack overflow is not something that should
>> be taken lightly
> Agreed.
>
> This kind of development is done with extensive in-house testing,
> and an absolutely fixed users space. This may sound like an
> isolated case, but I know Sony is not alone and that lots of
> embedded products are developed like this. I'm pretty sure
> others would benefit from this patch.
>
> We've already shipped tens of thousands of cameras
> with this, with no problems, so it's certainly possible to get it
> right.
>
> Whether to include this comes down to a question of whether
> the ability of someone to get it wrong should preclude
> allowing the *option* into the kernel.
Given this comment, I assume you've already measured how much kernel
stack gets used, and would be able to provide those figures?
The kernel can give you this if you enable CONFIG_DEBUG_STACK_USAGE. The
kernel will then report whenever a thread exits having used more kernel
stack than any previous exiting thread.
^ permalink raw reply
* [U-Boot] [PATCH] arm, post, memory: fix bug if sdram base != 0x00000000
From: Wolfgang Denk @ 2011-10-23 20:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1317969600-32496-1-git-send-email-hs@denx.de>
Dear Heiko Schocher,
In message <1317969600-32496-1-git-send-email-hs@denx.de> you wrote:
> commit 8d3fcb5e60b6c8e1d530dbc2e2e33ec6a44670da breaks post
> memory support for sdram base != 0x00000000. Fix this.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Cc: Valentin Longchamp <valentin.longchamp@keymile.com>
> Cc: Holger Brunck <holger.brunck@keymile.com>
> ---
> $ /home/git/linux-denx/scripts/checkpatch.pl 0001-arm-post-memory-fix-bug-if-sdram-base-0x00000000.patch
> total: 0 errors, 0 warnings, 14 lines checked
>
> 0001-arm-post-memory-fix-bug-if-sdram-base-0x00000000.patch has no obvious style problems and is ready for submission.
>
> post/drivers/memory.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
Applied, thanks.
Best regards,
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
"The History of every major Galactic Civilization tends to pass
through three distinct and recognizable phases, those of Survival,
Inquiry and Sophistication, otherwise known as the How, Why and Where
phases. "For instance, the first phase is characterized by the
question 'How can we eat?' the second by the question 'Why do we
eat?' and the third by the question 'Where shall we have lunch?'"
- Hitchhiker's Guide to the Galaxy
^ permalink raw reply
* [U-Boot] [PATCH 1/3 v2] net: emaclite: Use unsigned long for baseaddr
From: Wolfgang Denk @ 2011-10-23 20:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1318497803-21874-2-git-send-email-monstr@monstr.eu>
Dear Michal Simek,
In message <1318497803-21874-2-git-send-email-monstr@monstr.eu> you wrote:
> Baseaddr should be unsigned long.
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>
>
> ---
> v2: Fix merge confict - no function change
> ---
> drivers/net/xilinx_emaclite.c | 4 ++--
> include/netdev.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
Applied, thanks.
Best regards,
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
Do not simplify the design of a program if a way can be found to make
it complex and wonderful.
^ permalink raw reply
* [U-Boot] [PATCH 2/3 v2] net: emaclite: Move RX/TX ping pong initialization to
From: Wolfgang Denk @ 2011-10-23 20:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1318497803-21874-3-git-send-email-monstr@monstr.eu>
Dear Michal Simek,
In message <1318497803-21874-3-git-send-email-monstr@monstr.eu> you wrote:
> Init RX/TX ping pong directly from board not in the driver.
>
> Signed-off-by: Michal Simek <monstr@monstr.eu>
>
> ---
> v2: Fix merge confict - no function change
> ---
> .../xilinx/microblaze-generic/microblaze-generic.c | 18 ++++++++++++------
> drivers/net/xilinx_emaclite.c | 11 ++++-------
> include/netdev.h | 3 ++-
> 3 files changed, 18 insertions(+), 14 deletions(-)
Applied, thanks.
Best regards,
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
I have never understood the female capacity to avoid a direct answer
to any question.
-- Spock, "This Side of Paradise", stardate 3417.3
^ permalink raw reply
* Re: [PATCH 00/22] Refactor to accept NUL in commit messages
From: Junio C Hamano @ 2011-10-23 20:16 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, git, Ævar Arnfjörð
In-Reply-To: <20111023160744.GA22444@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But as Duy mentions, we have an encoding header. Shouldn't we treat it
> like binary goo until we do reencode_log_message, and _then_ we can
> break it into lines?
That's sensible. If we go that route, I think the "one allocation of
separate struct commit_buffer pointed from a pointer field in struct
commit to replace the current member 'buffer'" is a reasonable thing
to do.
^ permalink raw reply
* [U-Boot] [PATCH v4 2/2] NS16550: buffer reads
From: Graeme Russ @ 2011-10-23 20:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111023171536.4FFAA1408771@gemini.denx.de>
Hi Wolfgang,
On Oct 24, 2011 4:15 AM, "Wolfgang Denk" <wd@denx.de> wrote:
>
> Dear Graeme Russ,
>
> In message <
CALButCLEg6c30En3N4LjPv1woJjFxwkEkHvQYMoJy8+MgSzqJw@mail.gmail.com> you
wrote:
> >
[snip]
> > > This should not be necessary. Actually the implementation should not
> > > need to know about such special cases.
> >
> > So how does kermit/ymodem send the XON after the user has entered the
> > receive command and we have sent the XOFF after the newline?
>
> Upon the first getc() that follows?
And as there will be no corresponding newline, when do we send XOFF?
Regards,
Graeme
^ permalink raw reply
* Re: [dm-devel] Bisected: Massive memory leak in dm-snapshot in 3.1 development introduced
From: Alasdair G Kergon @ 2011-10-23 20:19 UTC (permalink / raw)
To: Linus Torvalds, Michael Leun
Cc: Alasdair G Kergon, Mikulas Patocka, dm-devel, LKML
In-Reply-To: <20111023163042.4a93936c@xenia.leun.net>
On Sun, Oct 23, 2011 at 04:30:42PM +0200, Michael Leun wrote:
> On Sun, 23 Oct 2011 14:44:49 +0100
> Alasdair G Kergon <agk@redhat.com> wrote:
> > Michael - can you test if this solves the problem?
OK, let's go with this patch then.
Linus, you can pull it from here:
http://people.redhat.com/agk/git/linux-dm for-linus
Alasdair G Kergon (1):
dm kcopyd: fix job_pool leak
drivers/md/dm-kcopyd.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: LE APIs on other platforms
From: Anderson Lizardo @ 2011-10-23 20:19 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth
In-Reply-To: <alpine.DEB.2.02.1110230511330.23620@mathewm-linux>
Hi Mat,
On Sun, Oct 23, 2011 at 9:12 AM, Mat Martineau <mathewm@codeaurora.org> wrote:
>
> For those of you asking about iOS LE APIs at the Bluetooth summit, here is
> the link to Apple's LE developer documentation:
>
> http://developer.apple.com/library/ios/#documentation/CoreBluetooth/Reference/CoreBluetooth_Framework/_index.html
Good to know their Developer API docs are public. Although I'm afraid
if we may taint our brains just by looking at it :)
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [CONSOLIDATED PULL 24/27] texi2html: Added recipe from OE
From: Saul Wold @ 2011-10-23 20:13 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <CAMKF1soJ1Kv77_dNijQTWjzk8W+M5z2+yg2SUPxZtADLgum2CA@mail.gmail.com>
On 10/23/2011 01:06 PM, Khem Raj wrote:
>
>
> On Sunday, October 23, 2011, Saul Wold <sgw@linux.intel.com
> <mailto:sgw@linux.intel.com>> wrote:
> > Needed to build oe-core with oe-core
>
Nope, this is needed on the target image to build OE-core with an
OE-Core image.
Sau!
> Oe-Core with oe-core did u mean meta-oe in one place ?
> >
> > Signed-off-by: Saul Wold <sgw@linux.intel.com
> <mailto:sgw@linux.intel.com>>
> > ---
> > meta/recipes-extended/texi2html/texi2html_1.82.bb
> <http://texi2html_1.82.bb> | 14 ++++++++++++++
> > 1 files changed, 14 insertions(+), 0 deletions(-)
> > create mode 100644 meta/recipes-extended/texi2html/texi2html_1.82.bb
> <http://texi2html_1.82.bb>
> >
> > diff --git a/meta/recipes-extended/texi2html/texi2html_1.82.bb
> <http://texi2html_1.82.bb>
> b/meta/recipes-extended/texi2html/texi2html_1.82.bb
> <http://texi2html_1.82.bb>
> > new file mode 100644
> > index 0000000..f19b576
> > --- /dev/null
> > +++ b/meta/recipes-extended/texi2html/texi2html_1.82.bb
> <http://texi2html_1.82.bb>
> > @@ -0,0 +1,14 @@
> > +DESCRIPTION = "Perl script that converts Texinfo to HTML"
> > +HOMEPAGE = "http://www.nongnu.org/texi2html/"
> > +SECTION = "console/utils"
> > +LICENSE = "GPLv2"
> > +LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552"
> > +
> > +PR = "r0"
> > +
> > +SRC_URI =
> "http://download.savannah.gnu.org/releases/texi2html/${P}.tar.bz2"
> > +
> > +SRC_URI[md5sum] = "a8a9193c0ac1bec2f3ca7be40a5a82eb"
> > +SRC_URI[sha256sum] =
> "d69c1effc416896409003ea64fdb21152cc0a9a7c665d437a0a3bef9b588b4f1"
> > +
> > +inherit autotools
> > --
> > 1.7.6.4
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> <mailto:Openembedded-core@lists.openembedded.org>
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
* Re: [PATCH 02/14] ARM : SAMSUNG : Add RS485 support.
From: Russell King - ARM Linux @ 2011-10-23 20:20 UTC (permalink / raw)
To: Paul Schilling
Cc: Nicolas Pitre, Kukjin Kim, linux-serial, Boojin Kim,
Greg Kroah-Hartman, linux-kernel, Ben Dooks, linux-arm-kernel,
Alan Cox
In-Reply-To: <CAC=G6syuf-J4am1mHRg-5gzqy661yOT9pUK2vQyToLPtv4tvEg@mail.gmail.com>
On Sun, Oct 23, 2011 at 12:12:13PM -0500, Paul Schilling wrote:
> On Sat, Oct 22, 2011 at 8:47 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> + } else {
> >> + /* Set a short timer to toggle RTS */
> >> + mod_timer(
> >> + &(ourport->rs485_tx_timer),
> >> + jiffies + usecs_to_jiffies(
> >> + ourport->char_time_usec
> >> + / 10));
> >
> > This could do with being better formatted. Also, & doesn't need following
> > parens.
>
> when I ran checkpatch it complained that it exceeded 80 characters. I
> had trouble keeping this line
> under 80 characters.
} else {
mod_timer(&our_port->rs485_tx_timer, jiffies +
usecs_to_jiffies(ourport->char_time_usec
/ 10));
is probably a better way to format it.
> >> - if (port->flags & UPF_CONS_FLOW)
> >> + if (port->flags & UPF_CONS_FLOW) {
> >> s3c24xx_serial_rx_enable(port);
> >> + }
> >
> > Why are you reformatting code?
>
> I will remove the reformatting of the code.
If you wish to reformat the code to clean up checkpatch warnings, then that
needs to be a separate patch from any other changes.
^ permalink raw reply
* [PATCH 02/14] ARM : SAMSUNG : Add RS485 support.
From: Russell King - ARM Linux @ 2011-10-23 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAC=G6syuf-J4am1mHRg-5gzqy661yOT9pUK2vQyToLPtv4tvEg@mail.gmail.com>
On Sun, Oct 23, 2011 at 12:12:13PM -0500, Paul Schilling wrote:
> On Sat, Oct 22, 2011 at 8:47 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> + ? ? ? ? ? ? } else {
> >> + ? ? ? ? ? ? ? ? ? ? /* Set a short timer to toggle RTS */
> >> + ? ? ? ? ? ? ? ? ? ? mod_timer(
> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &(ourport->rs485_tx_timer),
> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? jiffies + usecs_to_jiffies(
> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ourport->char_time_usec
> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? / 10));
> >
> > This could do with being better formatted. ?Also, & doesn't need following
> > parens.
>
> when I ran checkpatch it complained that it exceeded 80 characters. I
> had trouble keeping this line
> under 80 characters.
} else {
mod_timer(&our_port->rs485_tx_timer, jiffies +
usecs_to_jiffies(ourport->char_time_usec
/ 10));
is probably a better way to format it.
> >> - ? ? ? ? ? ? if (port->flags & UPF_CONS_FLOW)
> >> + ? ? ? ? ? ? if (port->flags & UPF_CONS_FLOW) {
> >> ? ? ? ? ? ? ? ? ? ? ? s3c24xx_serial_rx_enable(port);
> >> + ? ? ? ? ? ? }
> >
> > Why are you reformatting code?
>
> I will remove the reformatting of the code.
If you wish to reformat the code to clean up checkpatch warnings, then that
needs to be a separate patch from any other changes.
^ permalink raw reply
* Re: Ofono use
From: Denis Kenzior @ 2011-10-23 20:20 UTC (permalink / raw)
To: ofono
In-Reply-To: <1319449442.32429.141.camel@talinn.home>
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]
Hi Jean,
On 10/24/2011 04:44 AM, Jean Parpaillon wrote:
> Hi all,
> I am currently trying to use ofono and I can not get how to register the
> modem in a reliable way.
> When I detect a modem, I set org.ofono.Modem.Powered to True.
> When SimManager interface is ready, I enter the pin.
> Then, I set the modem org.ofono.Modem.Online to True.
So far so good...
> By the way, I wait for NetworkRegistration interface to be available.
> When it is available, I wait for NetworkRegistration.Name to be non
> empty to call NetworkRegistration.Register.
>
oFono will automatically register unless the Mode property is set to
'manual'. So calling NetworkRegistration.Register is wholly pointless
if you obtain a NetworkRegistration.Name. That means you're already
registered ;)
> The point is setting Online property usually end with a timeout. It is
> the right workflow ? Must I look for other property ?
What modem are you using? In general Online should never result in a
timeout...
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH 02/14] ARM : SAMSUNG : Add RS485 support.
From: Russell King - ARM Linux @ 2011-10-23 20:20 UTC (permalink / raw)
To: Paul Schilling
Cc: Ben Dooks, Kukjin Kim, Alan Cox, Greg Kroah-Hartman, Boojin Kim,
Nicolas Pitre, linux-arm-kernel, linux-kernel, linux-serial
In-Reply-To: <CAC=G6syuf-J4am1mHRg-5gzqy661yOT9pUK2vQyToLPtv4tvEg@mail.gmail.com>
On Sun, Oct 23, 2011 at 12:12:13PM -0500, Paul Schilling wrote:
> On Sat, Oct 22, 2011 at 8:47 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >> + } else {
> >> + /* Set a short timer to toggle RTS */
> >> + mod_timer(
> >> + &(ourport->rs485_tx_timer),
> >> + jiffies + usecs_to_jiffies(
> >> + ourport->char_time_usec
> >> + / 10));
> >
> > This could do with being better formatted. Also, & doesn't need following
> > parens.
>
> when I ran checkpatch it complained that it exceeded 80 characters. I
> had trouble keeping this line
> under 80 characters.
} else {
mod_timer(&our_port->rs485_tx_timer, jiffies +
usecs_to_jiffies(ourport->char_time_usec
/ 10));
is probably a better way to format it.
> >> - if (port->flags & UPF_CONS_FLOW)
> >> + if (port->flags & UPF_CONS_FLOW) {
> >> s3c24xx_serial_rx_enable(port);
> >> + }
> >
> > Why are you reformatting code?
>
> I will remove the reformatting of the code.
If you wish to reformat the code to clean up checkpatch warnings, then that
needs to be a separate patch from any other changes.
^ permalink raw reply
* [U-Boot] [PATCH v3] common: fix missing function pointer relocation in fixup_cmdtable()
From: Wolfgang Denk @ 2011-10-23 20:22 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1318972342-3801-1-git-send-email-daniel.schwierzeck@googlemail.com>
Dear Daniel Schwierzeck,
In message <1318972342-3801-1-git-send-email-daniel.schwierzeck@googlemail.com> you wrote:
> In commit fa28bd2eef588ec2048ccafedb2b384d5a355858 patch v1 was applied
> instead of v2. This is an incremental patch to update that commit
> to version 2.
>
> Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
> ---
> changes for v2:
> use correct type cast
>
> changes for v3:
> rebased against current master
> incremental patch from v1 to v2
>
> one checkpatch.pl warning:
> WARNING: line over 80 characters
> #38: FILE: common/command.c:483:
> + (int (*)(int, char * const [], char, int, char * []))addr;
>
> common/command.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
Applied, thanks.
Best regards,
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
The people of Gideon have always believed that life is sacred. That
the love of life is the greatest gift ... We are incapable of
destroying or interfering with the creation of that which we love so
deeply -- life in every form from fetus to developed being.
-- Hodin of Gideon, "The Mark of Gideon", stardate 5423.4
^ permalink raw reply
* [Xenomai-help] address spaces of real-time task and standard linux process
From: haitaozhumail-disc @ 2011-10-23 20:25 UTC (permalink / raw)
To: xenomai@xenomai.org
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
Hi All,
Do a standard Linux process and a real-time task (spawned by the standard Linux process with rt_task_create and rt_task_start ) share the same address space? More specifically, I have a C++ program like this:
Class A{
//Definition of a class A
};
RT_TASK demo_task;
void demo(void *arg){
A * pA = (A *)arg;
//Access the passed object via pA, e.g., pA->a...
}
int main(){
...
A *pA = new A;
rt_task_create(&demo_task, "realtime_task", 0, 50, 0);
rt_task_start(&demo_task, &demo, (void *)pA);
pause();
}
Can the function demo() correctly access the object created in main()? What if pA is a smart pointer defined in Boost library?
With Many Thanks,
Tom
[-- Attachment #2: Type: text/html, Size: 1217 bytes --]
^ permalink raw reply
* Re: [PATCH] drm/i915: forcewake warning fixes in debugfs
From: Ben Widawsky @ 2011-10-23 20:25 UTC (permalink / raw)
To: Keith Packard; +Cc: intel-gfx
In-Reply-To: <yunaa8rbjjx.fsf@aiko.keithp.com>
On Sun, 23 Oct 2011 12:21:38 -0700
Keith Packard <keithp@keithp.com> wrote:
> On Sun, 23 Oct 2011 12:13:43 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> > Hi Keith,
> >
> > This patch isn't in your -next pull request. Please consider merging for
> > 3.2.
>
> I didn't ever see a reply from Nicolas that it fixed his problem; would
> be nice to know whether this actually worked...
>
I highly doubt it fixed his problem. The problem I was trying to fix was
to remove the spurious warnings we get, which was most likely the case
here. This patch does that correctly.
Ben
^ permalink raw reply
* Re: [PATCH 1/3] drm/i915: relative_constants_mode race fix
From: Ben Widawsky @ 2011-10-23 20:30 UTC (permalink / raw)
To: Keith Packard; +Cc: Ben Widawsky, intel-gfx
In-Reply-To: <1319337685-26195-1-git-send-email-ben@bwidawsk.net>
Keith, I believe this series belongs in -next. The first two could
actually go in fixes.
Ben
On Sat, 22 Oct 2011 19:41:23 -0700
Ben Widawsky <ben@bwidawsk.net> wrote:
> After my refactoring, Chris noticed that we had a bug.
>
> dev_priv keeps track of the current addressing mode that gets set at
> execbuffer time. Unfortunately the existing code was doing this before
> acquiring struct_mutex which leaves a race with another thread also
> doing an execbuffer. If that wasn't bad enough, relocate_slow drops
> struct_mutex which opens a much more likely error where another thread
> comes in and modifies the state while relocate_slow is being slow.
>
> The solution here is to just defer setting this state until we
> absolutely need it, and we know we'll have struct_mutex for the
> remainder of our code path.
>
> Cc: Keith Packard <keithp@keithp.com>
> Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 67 ++++++++++++++--------------
> 1 files changed, 34 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 3693e83..1d66c24 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1003,39 +1003,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> return -EINVAL;
> }
>
> - mode = args->flags & I915_EXEC_CONSTANTS_MASK;
> - switch (mode) {
> - case I915_EXEC_CONSTANTS_REL_GENERAL:
> - case I915_EXEC_CONSTANTS_ABSOLUTE:
> - case I915_EXEC_CONSTANTS_REL_SURFACE:
> - if (ring == &dev_priv->ring[RCS] &&
> - mode != dev_priv->relative_constants_mode) {
> - if (INTEL_INFO(dev)->gen < 4)
> - return -EINVAL;
> -
> - if (INTEL_INFO(dev)->gen > 5 &&
> - mode == I915_EXEC_CONSTANTS_REL_SURFACE)
> - return -EINVAL;
> -
> - ret = intel_ring_begin(ring, 4);
> - if (ret)
> - return ret;
> -
> - intel_ring_emit(ring, MI_NOOP);
> - intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
> - intel_ring_emit(ring, INSTPM);
> - intel_ring_emit(ring,
> - I915_EXEC_CONSTANTS_MASK << 16 | mode);
> - intel_ring_advance(ring);
> -
> - dev_priv->relative_constants_mode = mode;
> - }
> - break;
> - default:
> - DRM_ERROR("execbuf with unknown constants: %d\n", mode);
> - return -EINVAL;
> - }
> -
> if (args->buffer_count < 1) {
> DRM_ERROR("execbuf with %d buffers\n", args->buffer_count);
> return -EINVAL;
> @@ -1159,6 +1126,40 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> }
> }
>
> + mode = args->flags & I915_EXEC_CONSTANTS_MASK;
> + switch (mode) {
> + case I915_EXEC_CONSTANTS_REL_GENERAL:
> + case I915_EXEC_CONSTANTS_ABSOLUTE:
> + case I915_EXEC_CONSTANTS_REL_SURFACE:
> + if (ring == &dev_priv->ring[RCS] &&
> + mode != dev_priv->relative_constants_mode) {
> + if (INTEL_INFO(dev)->gen < 4)
> + return -EINVAL;
> +
> + if (INTEL_INFO(dev)->gen > 5 &&
> + mode == I915_EXEC_CONSTANTS_REL_SURFACE)
> + return -EINVAL;
> +
> + ret = intel_ring_begin(ring, 4);
> + if (ret)
> + goto err;
> +
> + intel_ring_emit(ring, MI_NOOP);
> + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
> + intel_ring_emit(ring, INSTPM);
> + intel_ring_emit(ring,
> + I915_EXEC_CONSTANTS_MASK << 16 | mode);
> + intel_ring_advance(ring);
> +
> + dev_priv->relative_constants_mode = mode;
> + }
> + break;
> + default:
> + DRM_ERROR("execbuf with unknown constants: %d\n", mode);
> + ret = -EINVAL;
> + goto err;
> + }
> +
> trace_i915_gem_ring_dispatch(ring, seqno);
>
> exec_start = batch_obj->gtt_offset + args->batch_start_offset;
^ permalink raw reply
* Re: [PATCHv6 hcidump 2/4] add fixed channel definitions
From: Johan Hedberg @ 2011-10-23 20:32 UTC (permalink / raw)
To: Emeltchenko Andrei, linux-bluetooth
In-Reply-To: <20111021104818.GA3934@aemeltch-MOBL1>
Hi Andrei,
On Fri, Oct 21, 2011, Emeltchenko Andrei wrote:
> Would the following code be OK?
>
> diff --git a/lib/bluetooth.h b/lib/bluetooth.h
> index b0680e2..158103b 100644
> --- a/lib/bluetooth.h
> +++ b/lib/bluetooth.h
> @@ -125,6 +125,30 @@ do { \
> __p->__v = (val); \
> } while(0)
>
> +#if __BYTE_ORDER == __LITTLE_ENDIAN
> +inline uint64_t bt_get_le64(void *ptr)
> +{
> + return bt_get_unaligned((uint64_t *) ptr);
> +}
> +
> +inline uint64_t bt_get_be64(void *ptr)
> +{
> + return bswap_64(bt_get_unaligned((uint64_t *) ptr));
> +}
> +#elif __BYTE_ORDER == __BIG_ENDIAN
> +inline uint64_t bt_get_le64(void *ptr)
> +{
> + return bswap_64(bt_get_unaligned((uint64_t *) ptr));
> +}
> +
> +inline uint64_t bt_get_be64(void *ptr)
> +{
> + return bt_get_unaligned((uint64_t *) ptr);
> +}
> +#else
> +#error "Unknown byte order"
> +#endif
> +
Yes, I think that would be fine, but please also add the same for 32 and
16 bit integers.
Johan
^ permalink raw reply
* Re: callhistory plug-in
From: Denis Kenzior @ 2011-10-23 20:34 UTC (permalink / raw)
To: ofono
In-Reply-To: <D289D719C4D273478F6F91853F18E304018119E1@SGPMBX03.APAC.bosch.com>
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
Hi Raj,
On 10/24/2011 08:35 AM, Rajkumar Athimoolam (RBEI/ECG1) wrote:
> Hi all,
>
> I have been looking for some solution to store the call history
> information from oFono in EDS.
> In ofono-paper.txt it is mentioned as“Moblin uses oFono plugins to store
> all call history information within Evolution Data Server.”
This comment is/was true, but quite outdated. While there was a call
history plugin for EDS, it lived in a separate repository.
> But in ofono source code I could only see the history plug-in interfaces.
> Where I can find the upstream plug-in code for call history storage in EDS?
> Any thing related to this direction would be of great help. Thanks
>
You might want to peek into meego-cellular group of projects on
gitorious or look into the mailing list archives for previous
discussions on this topic.
> Please excuse if it is already somewhere discussed in the mail archives
>
Regards,
-Denis
^ permalink raw reply
* Re: longjmp question
From: David Miller @ 2011-10-23 20:35 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <20111007232209.GA11892@wooyd.org>
From: Jurij Smakov <jurij@wooyd.org>
Date: Sun, 23 Oct 2011 14:47:27 +0100
> On Sat, Oct 22, 2011 at 06:54:05PM -0400, David Miller wrote:
>>
>> Just let the compiler do it for you, please... the compiler absolutely cannot
>> optimize away a function that uses a volatile asm statement. And it absolutely
>> cannot make a function that clobbers %o7 a leaf function.
>
> That's not what I see. I tried writing up a patch for Ruby using this,
> and here's what I get:
>
> 1. Preprocessed source of cont.c contains flush_register_windows
> definition:
>
> # 219 "./include/ruby/defines.h"
> static void
> flush_register_windows(void)
> {
> asm __volatile__ ("flushw" : : : "o7");
> }
You can't put it in a header file, GCC will inline it. You have to
put it in a function in a seperate C file, and this is what I said to
do the other week in my original email.
You're only other option is to explicitly mark this
__attribute__((__noinline__))
^ 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.