Linux Embedded

• Thread Index

• Re: [RFC PATCH] boot-time: instrument probes more
  • From: Francesco Valla <francesco@xxxxxxxx>
• [boot-time] [SCRIPT v2] analyze-initcall-debug.py
  • From: Francesco Valla <francesco@xxxxxxxx>
• Re: Dec 17 - Next Boot-Time SIG meeting
  • From: Francesco Valla <francesco@xxxxxxxx>
• Dec 17 - Next Boot-Time SIG meeting
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• [RFC PATCH] boot-time: instrument probes more
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output
  • From: Francesco Valla <francesco@xxxxxxxx>
• Re: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output
  • From: Francesco Valla <francesco@xxxxxxxx>
• Re: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output
  • From: Francesco Valla <francesco@xxxxxxxx>
• Re: [boot-time] jent_mod_init on beagleplay (was RE: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output
  • From: Stephan Mueller <smueller@xxxxxxxxxx>
• Re: [PATCH v2] printk: Improve memory usage logging during boot
  • From: John Ogness <john.ogness@xxxxxxxxxxxxx>
• RE: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• [boot-time] jent_mod_init on beagleplay (was RE: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• RE: [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: [PATCH v2] printk: Improve memory usage logging during boot
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH v2] printk: Improve memory usage logging during boot
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [boot-time] [RFC] analyze-initcall-debug.py - a tool to analyze the initcall debug output
  • From: Francesco Valla <francesco@xxxxxxxx>
• RE: [boot-time] RFC grab-boot-data.sh - tool to grab boot time data
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• RE: [boot-time] SIG organizing meeting
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• RE: [boot-time] SIG organizing meeting
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• [boot-time] SIG organizing meeting
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: Request to join the mailing list
  • From: Ezra Buehler <ezra@xxxxxxxx>
• Request to join the mailing list
  • From: Madeeha Javed <madeeha@xxxxxxxxx>
• RE: Boot-time initiative (SIG) thoughts and next steps
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: [boot-time] Please check this wiki page about RCU expedited mode
  • From: Eric Curtin <ecurtin@xxxxxxxxxx>
• Re: [boot-time] RFC grab-boot-data.sh - tool to grab boot time data
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [boot-time] Please check this wiki page about RCU expedited mode
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• [boot-time] RFC grab-boot-data.sh - tool to grab boot time data
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: Boot-time initiative (SIG) thoughts and next steps
  • From: Saravana Kannan <saravanak@xxxxxxxxxx>
• RE: Boot-time initiative (SIG) thoughts and next steps
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: Boot-time initiative (SIG) thoughts and next steps
  • From: Brian Masney <bmasney@xxxxxxxxxx>
• RE: [boot-time] RFC: proposal for boot-time tools github repository
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: [boot-time] RFC: proposal for boot-time tools github repository
  • From: Francesco Valla <valla.francesco@xxxxxxxxx>
• [boot-time] RFC: proposal for boot-time tools github repository
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• RE: elinux.org wiki style
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• elinux.org wiki style
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Boot-time initiative (SIG) thoughts and next steps
  • From: Saravana Kannan <saravanak@xxxxxxxxxx>
• RE: Boot-time initiative (SIG) thoughts and next steps
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: Boot-time initiative (SIG) thoughts and next steps
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: Boot-time initiative (SIG) thoughts and next steps
  • From: Saravana Kannan <saravanak@xxxxxxxxxx>
• Boot-time initiative (SIG) thoughts and next steps
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Boot-time presentations
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• [kernel 6.10.10][aarch64] PCIe Bridge - NVMe SSD - No SMMU (or IOMMU)
  • From: Lior Weintraub <liorw@xxxxxxxxxx>
• lowend platforms support such as Cortex-M
  • From: Andy Gao <gjw1106364305@xxxxxxxxx>
• Re: Linux Kernel (megi patches for PinePhone Pro)
  • From: Tanvir Roshid <tanvir.roshid@xxxxxxxxxxxxxxx>
• Linux Kernel (megi patches for PinePhone Pro)
  • From: Tanvir Roshid <tanvir.roshid@xxxxxxxxxxxxxxx>
• RE: Debugging early SError exception
  • From: Lior Weintraub <liorw@xxxxxxxxxx>
• RE: Debugging early SError exception
  • From: Lior Weintraub <liorw@xxxxxxxxxx>
• RE: Debugging early SError exception
  • From: Lior Weintraub <liorw@xxxxxxxxxx>
• Re: Debugging early SError exception
  • From: Heiko Schocher <hs@xxxxxxx>
• Re: Debugging early SError exception
  • From: Dirk Behme <dirk.behme@xxxxxxxxx>
• RE: Debugging early SError exception
  • From: Lior Weintraub <liorw@xxxxxxxxxx>
• RE: Debugging early SError exception
  • From: Lior Weintraub <liorw@xxxxxxxxxx>
• Re: Debugging early SError exception
  • From: Heiko Schocher <hs@xxxxxxx>
• Re: Debugging early SError exception
  • From: Dirk Behme <dirk.behme@xxxxxxxxx>
• RE: Debugging early SError exception
  • From: Lior Weintraub <liorw@xxxxxxxxxx>
• Re: Debugging early SError exception
  • From: Dirk Behme <dirk.behme@xxxxxxxxx>
• RE: Debugging early SError exception
  • From: Lior Weintraub <liorw@xxxxxxxxxx>
• Re: Debugging early SError exception
  • From: Dirk Behme <dirk.behme@xxxxxxxxx>
• RE: Debugging early SError exception
  • From: Lior Weintraub <liorw@xxxxxxxxxx>
• Re: Debugging early SError exception
  • From: Dirk Behme <dirk.behme@xxxxxxxxx>
• Debugging early SError exception
  • From: Lior Weintraub <liorw@xxxxxxxxxx>
• Re: PSA: This list is being migrated (no action required)
  • From: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx>
• PSA: This list is being migrated (no action required)
  • From: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx>
• PSA: migrating linux-embedded to new vger infrastructure
  • From: Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx>
• Re: Nobarrier mount option (was: Re: File system robustness)
  • From: Martin Steigerwald <martin@xxxxxxxxxxxx>
• Re: Nobarrier mount option (was: Re: File system robustness)
  • From: "Theodore Ts'o" <tytso@xxxxxxx>
• Nobarrier mount option (was: Re: File system robustness)
  • From: Martin Steigerwald <martin@xxxxxxxxxxxx>
• Re: File system robustness
  • From: "Theodore Ts'o" <tytso@xxxxxxx>
• Re: File system robustness
  • From: "Theodore Ts'o" <tytso@xxxxxxx>
• Re: File system robustness
  • From: Kai Tomerius <kai@xxxxxxxxxxx>
• Re: File system robustness
  • From: Martin Steigerwald <martin@xxxxxxxxxxxx>
• Re: File system robustness
  • From: "Theodore Ts'o" <tytso@xxxxxxx>
• Re: File system robustness
  • From: "Alan C. Assis" <acassis@xxxxxxxxx>
• Re: File system robustness
  • From: "Alan C. Assis" <acassis@xxxxxxxxx>
• Re: File system robustness
  • From: Bjørn Forsman <bjorn.forsman@xxxxxxxxx>
• Re: File system robustness
  • From: Kai Tomerius <kai@xxxxxxxxxxx>
• Re: File system robustness
  • From: "Alan C. Assis" <acassis@xxxxxxxxx>
• Re: File system robustness
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• File system robustness
  • From: Kai Tomerius <kai@xxxxxxxxxxx>
• Re: Anyone using XFS in an embedded product?
  • From: "Steven J. Hill" <sjhill@xxxxxxxxxxxxxxxxxx>
• Anyone using XFS in an embedded product?
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: Florian Fainelli <f.fainelli@xxxxxxxxx>
• Prebuilt binary and native toolchains.
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: Rob Landley <rob@xxxxxxxxxxx>
• RE: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: <Tim.Bird@xxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: Kevin Hilman <khilman@xxxxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
• Re: [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH] MAINTAINERS: Remove Matt Mackall as his identity is obsolete
  • From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx>
• Re: [PATCH 3/3] lib/vsprintf: Use pr_crit() instead of long fancy messages
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH 3/3] lib/vsprintf: Use pr_crit() instead of long fancy messages
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Yocto Project Summit - registration open
  • From: Trevor Woerner <twoerner@xxxxxxxxx>
• Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages
  • From: Robin Murphy <robin.murphy@xxxxxxx>
• Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages
  • From: Steven Rostedt <rostedt@xxxxxxxxxxx>
• [PATCH 2/3] tracing: Use pr_crit() instead of long fancy messages
  • From: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
• [PATCH] clk: Align provider-specific CLK_* bit definitions
  • From: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
• [PATCH 0/3] Use pr_crit() instead of long fancy messages
  • From: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
• [PATCH 1/3] iommu: Use pr_crit() instead of long fancy messages
  • From: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
• [PATCH 3/3] lib/vsprintf: Use pr_crit() instead of long fancy messages
  • From: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
• Yocto Project Virtual Summit 2021
  • From: Trevor Woerner <twoerner@xxxxxxxxx>
• Re: [PATCH v2 2/2] init/Kconfig: Increase default log buffer size from 128 KB to 512 KB
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: [PATCH v2 2/2] init/Kconfig: Increase default log buffer size from 128 KB to 512 KB
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v2 2/2] init/Kconfig: Increase default log buffer size from 128 KB to 512 KB
  • From: Paul Menzel <pmenzel@xxxxxxxxxxxxx>
• Re: [PATCH v2 2/2] init/Kconfig: Increase default log buffer size from 128 KB to 512 KB
  • From: Petr Mladek <pmladek@xxxxxxxx>
• Re: ELCE 2015 videos unavailable
  • From: Trevor Woerner <twoerner@xxxxxxxxx>
• Re: ELCE 2015 videos unavailable
  • From: Trevor Woerner <twoerner@xxxxxxxxx>
• RE: ELCE 2015 videos unavailable
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: ELCE 2015 videos unavailable
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: ELCE 2015 videos unavailable
  • From: Christophe Aeschlimann <c.aeschlimann@xxxxxxxxxxxx>
• RE: ELCE 2015 videos unavailable
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: ELCE 2015 videos unavailable
  • From: Kishon Vijay Abraham I <kishon@xxxxxx>
• RE: ELCE 2015 videos unavailable
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxx>
• Re: ELCE 2015 videos unavailable
  • From: Matthias Brugger <matthias.bgg@xxxxxxxxx>
• Re: ELCE 2015 videos unavailable
  • From: Kishon Vijay Abraham I <kishon@xxxxxx>
• ELCE 2015 videos unavailable
  • From: Matthias Brugger <matthias.bgg@xxxxxxxxx>
• Re: Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores
  • From: Phillip Lougher <phillip.lougher@xxxxxxxxx>
• Re: Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores
  • From: Phillip Lougher <phillip.lougher@xxxxxxxxx>
• Re: Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores
  • From: "Theodore Y. Ts'o" <tytso@xxxxxxx>
• Re: Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores
  • From: Phillip Lougher <phillip.lougher@xxxxxxxxx>
• Re: Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores
  • From: László Böszörményi (GCS) <gcs@xxxxxxxxxx>
• Bug#921146: Program mksquashfs from squashfs-tools 1:4.3-11 does not make use all CPU cores
  • From: Phillip Lougher <phillip.lougher@xxxxxxxxx>
• [PATCH] staging: sm750fb: fix ASCII graph in comments.
  • From: Tom Li <tomli@xxxxxxxx>
• Re: Kernel crashing on startup while trying to allocate space below 0x0
  • From: Florian Fainelli <f.fainelli@xxxxxxxxx>
• Re: Kernel crashing on startup while trying to allocate space below 0x0
  • From: Frederick Heinecke <fheinecke@xxxxxxx>
• Re: Kernel crashing on startup while trying to allocate space below 0x0
  • From: Florian Fainelli <f.fainelli@xxxxxxxxx>
• Kernel crashing on startup while trying to allocate space below 0x0
  • From: Frederick Heinecke <fheinecke@xxxxxxx>
• Re: [PATCH] tools: fix cross-compile var export
  • From: Martin Kelly <martin@xxxxxxxxxxxxxxxx>
• Re: [PATCH] tools: fix cross-compile var export
  • From: Martin Kelly <martin@xxxxxxxxxxxxxxxx>
• Re: [PATCH] tools: fix cross-compile var export
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH] tools: fix cross-compile var export
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH] tools: fix cross-compile var export
  • From: Martin Kelly <martin@xxxxxxxxxxxxxxxx>
• Re: [PATCH] tools: fix cross-compile var export
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• [PATCH] tools: fix cross-compile var export
  • From: Martin Kelly <martin@xxxxxxxxxxxxxxxx>
• Re: POSIX Message Queue Priority Scheduling
  • From: Jonathan Haws <jhaws@xxxxxxxxxxx>
• Re: POSIX Message Queue Priority Scheduling
  • From: Jonathan Haws <Jonathan.Haws@xxxxxxxxxxx>
• Re: POSIX Message Queue Priority Scheduling
  • From: Jonathan Haws <Jonathan.Haws@xxxxxxxxxxx>
• Re: POSIX Message Queue Priority Scheduling
  • From: Jonathan Haws <Jonathan.Haws@xxxxxxxxxxx>
• POSIX Message Queue Priority Scheduling
  • From: Jonathan Haws <Jonathan.Haws@xxxxxxxxxxx>
• Re: [PATCH v6 1/4] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v6 1/4] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v6 1/4] cramfs: direct memory access support
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v6 1/4] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v6 1/4] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v6 1/4] cramfs: direct memory access support
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v6 1/4] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v6 1/4] cramfs: direct memory access support
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v6 3/4] cramfs: add mmap support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH v6 1/4] cramfs: direct memory access support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• RE: [PATCH v6 1/4] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH v6 1/4] cramfs: direct memory access support
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• [PATCH v6 1/4] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v6 3/4] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v6 2/4] cramfs: implement uncompressed and arbitrary data block positioning
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v6 0/4] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v6 4/4] cramfs: rehabilitate it
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v5 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH v5 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH v5 0/5] cramfs refresh for embedded usage
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• Re: [PATCH v5 4/5] cramfs: add mmap support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH v5 0/5] cramfs refresh for embedded usage
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• [PATCH v5 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v5 3/5] cramfs: implement uncompressed and arbitrary data block positioning
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v5 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v5 5/5] cramfs: rehabilitate it
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v5 2/5] cramfs: make cramfs_physmem usable as root fs
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v5 1/5] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH v4 4/5] cramfs: add mmap support
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• RE: [PATCH v4 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH v4 4/5] cramfs: add mmap support
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v4 1/5] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH v4 1/5] cramfs: direct memory access support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• RE: [PATCH v4 1/5] cramfs: direct memory access support
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• Re: [PATCH v4 1/5] cramfs: direct memory access support
  • From: Rob Herring <robh@xxxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Richard Weinberger <richard.weinberger@xxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v4 1/5] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v4 4/5] cramfs: add mmap support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH v4 1/5] cramfs: direct memory access support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• [PATCH v4 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v4 5/5] cramfs: rehabilitate it
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v4 3/5] cramfs: implement uncompressed and arbitrary data block positioning
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v4 1/5] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v4 2/5] cramfs: make cramfs_physmem usable as root fs
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v4 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• A Quick Survey on a Patch Propagation Tool
  • From: Aravind Machiry <machiry@xxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Oleg Nesterov <oleg@xxxxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Alan Cox <gnomes@xxxxxxxxxxxxxxxxxxx>
• Re: execve(NULL, argv, envp) for nommu?
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• execve(NULL, argv, envp) for nommu?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [PATCH v3 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v3 4/5] cramfs: add mmap support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• [PATCH v3 1/5] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v3 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [GIT PULL / PATCH v3 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v3 5/5] cramfs: rehabilitate it
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v3 2/5] cramfs: make cramfs_physmem usable as root fs
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v3 3/5] cramfs: implement uncompressed and arbitrary data block positioning
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH v2 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH v2 0/5] cramfs refresh for embedded usage
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• RE: [PATCH v2 4/5] cramfs: add mmap support
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• RE: [PATCH v2 4/5] cramfs: add mmap support
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• RE: [PATCH v2 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH v2 4/5] cramfs: add mmap support
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• Re: [PATCH v2 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v2 4/5] cramfs: add mmap support
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH v2 4/5] cramfs: add mmap support
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH v2 1/5] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH v2 1/5] cramfs: direct memory access support
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• RE: [PATCH v2 3/5] cramfs: implement uncompressed and arbitrary data block positioning
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• RE: [PATCH v2 4/5] cramfs: add mmap support
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• [PATCH v2 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v2 1/5] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v2 5/5] cramfs: rehabilitate it
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v2 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v2 2/5] cramfs: make cramfs_physmem usable as root fs
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH v2 3/5] cramfs: implement uncompressed and arbitrary data block positioning
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• RE: [PATCH 0/5] cramfs refresh for embedded usage
  • From: Chris Brandt <Chris.Brandt@xxxxxxxxxxx>
• Re: [PATCH 1/5] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: [PATCH 1/5] cramfs: direct memory access support
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• [PATCH 1/5] cramfs: direct memory access support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH 5/5] cramfs: rehabilitate it
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH 0/5] cramfs refresh for embedded usage
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH 4/5] cramfs: add mmap support
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH 3/5] cramfs: implement uncompressed and arbitrary data block positioning
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• [PATCH 2/5] cramfs: make cramfs_physmem usable as root fs
  • From: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>
• Re: mpc8572e linux kernel board bring-up problem
  • From: Rob Landley <rob@xxxxxxxxxxx>
• mpc8572e linux kernel board bring-up problem
  • From: Nicolas Beland <Nicolas.Beland@xxxxxxxxxxxx>
• Re: mounting squashfs as initrd from RAM
  • From: Rob Landley <rob@xxxxxxxxxxx>
• RE: mounting squashfs as initrd from RAM
  • From: Nick Gifford <nick.gifford@xxxxxxxxxx>
• Re: mounting squashfs as initrd from RAM
  • From: Rob Landley <rob@xxxxxxxxxxx>
• RE: mounting squashfs as initrd from RAM
  • From: Nick Gifford <nick.gifford@xxxxxxxxxx>
• Re: mounting squashfs as initrd from RAM
  • From: Rob Landley <rob@xxxxxxxxxxx>
• mounting squashfs as initrd from RAM
  • From: Nick Gifford <nick.gifford@xxxxxxxxxx>
• CFP: Embedded, mobile and automotive devroom FOSDEM 2016
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Can the Nexus 5's ARM-SMMU isolate the baseband processor?
  • From: Richard Yao <ryao@xxxxxxxxxx>
• Re: MFD device driver on top of UART/RS232
  • From: "H. Nikolaus Schaller" <hns@xxxxxxxxxxxxx>
• Re: MFD device driver on top of UART/RS232
  • From: Andrey Vostrikov <av.linux.dev@xxxxxxxxx>
• Re: MFD device driver on top of UART/RS232
  • From: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>
• MFD device driver on top of UART/RS232
  • From: Andrey Vostrikov <av.linux.dev@xxxxxxxxx>
• Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
  • From: Trevor Woerner <twoerner@xxxxxxxxx>
• Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
  • From: Greg Ungerer <gerg@xxxxxxxxxxx>
• Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
  • From: Rich Felker <dalias@xxxxxxxx>
• Re: [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
  • From: Greg Ungerer <gerg@xxxxxxxxxxx>
• [PATCH v2] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
  • From: Rich Felker <dalias@xxxxxxxx>
• Re: [PATCH] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
  • From: Rich Felker <dalias@xxxxxxxx>
• [PATCH] fs/binfmt_elf_fdpic.c: provide NOMMU loader for regular ELF binaries
  • From: Rich Felker <dalias@xxxxxxxx>
• Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
  • From: Greg Ungerer <gregungerer@xxxxxxxxxxxxxx>
• Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
  • From: Rich Felker <dalias@xxxxxxxx>
• Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
  • From: Greg Ungerer <gregungerer@xxxxxxxxxxxxxx>
• Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
  • From: Rich Felker <dalias@xxxxxxxx>
• Re: [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
  • From: Greg Ungerer <gerg@xxxxxxxxxxx>
• [PATCH] fs/binfmt_elf_fdpic.c: fix brk area overlap with stack on NOMMU
  • From: Rich Felker <dalias@xxxxxxxx>
• [PATCH v3 v4.2-rc1] printk: make extended printk support conditional on netconsole
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH v2 v4.2-rc1] printk: make extended printk support conditional on netconsole
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH v2 v4.2-rc1] printk: make extended printk support conditional on netconsole
  • From: Petr Mladek <pmladek@xxxxxxxx>
• [PATCH v2 v4.2-rc1] printk: make extended printk support conditional on netconsole
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH v4.2-rc1] printk: make extended printk support conditional on netconsole
  • From: Petr Mladek <pmladek@xxxxxxxx>
• [PATCH v4.2-rc1] printk: make extended printk support conditional on netconsole
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 3/3] printk: implement support for extended console drivers
  • From: josh@xxxxxxxxxxxxxxxx
• Re: [PATCH 3/3] printk: implement support for extended console drivers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 3/3] printk: implement support for extended console drivers
  • From: josh@xxxxxxxxxxxxxxxx
• Re: [PATCH 3/3] printk: implement support for extended console drivers
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 3/3] printk: implement support for extended console drivers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 3/3] printk: implement support for extended console drivers
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 3/3] printk: implement support for extended console drivers
  • From: Tejun Heo <tj@xxxxxxxxxx>
• Re: [PATCH 3/3] printk: implement support for extended console drivers
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• plumbers device tree track -- last call
  • From: Frank Rowand <frowand.list@xxxxxxxxx>
• Re: Device Tree at Plumbers, early registration ends Friday
  • From: Frank Rowand <frowand.list@xxxxxxxxx>
• Device Tree at Plumbers, looking for topics and session leaders
  • From: Frank Rowand <frowand.list@xxxxxxxxx>
• Device Tree at Plumbers, early registration ends Friday
  • From: Frank Rowand <frowand.list@xxxxxxxxx>
• Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: Jon Loeliger <jdl@xxxxxxx>
• LPC 2015 Boot, Init, and Config microconf RFC and Invitation
  • From: "Mehaffey, John" <John_Mehaffey@xxxxxxxxxx>
• Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>
• Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: Rob Herring <robherring2@xxxxxxxxx>
• Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: Matt Porter <mporter@xxxxxxxxxxxx>
• Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: Rob Herring <robherring2@xxxxxxxxx>
• Re: Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: David Gibson <david@xxxxxxxxxxxxxxxxxxxxx>
• Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [Celinux-dev] Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Invitation and RFC: Linux Plumbers Device Tree track proposed
  • From: "Rowand, Frank" <Frank.Rowand@xxxxxxxxxxxxxx>
• Re: [PATCH 1/3] kernel: Add a new config option to remove command line parsing
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• [PATCH 3/3] init: Set initcall_debug to a default value
  • From: Iulia Manda <iulia.manda21@xxxxxxxxx>
• [PATCH 2/3] linux: Add macros that define and declare a core_param variable
  • From: Iulia Manda <iulia.manda21@xxxxxxxxx>
• [PATCH 1/3] kernel: Add a new config option to remove command line parsing
  • From: Iulia Manda <iulia.manda21@xxxxxxxxx>
• Re: embedding dtb file into kernel
  • From: Sam Protsenko <semen.protsenko@xxxxxxxxxxxxxxx>
• Re: embedding dtb file into kernel
  • From: Hugh Blemings <hugh@xxxxxxxxxxxx>
• Re: embedding dtb file into kernel
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: embedding dtb file into kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: embedding dtb file into kernel
  • From: K Richard Pixley <rpixley@xxxxxxxxxxxxxxxxxxx>
• Re: embedding dtb file into kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• embedding dtb file into kernel
  • From: K Richard Pixley <rpixley@xxxxxxxxxxxxxxxxxxx>
• ELC CFP deadline is Jan 9
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• RFC: kselftest size roadmap
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH v5] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH v6] selftest: size: Add size test for Linux kernel
  • From: Shuah Khan <shuahkh@xxxxxxxxxxxxxxx>
• Re: [PATCH v6] selftest: size: Add size test for Linux kernel
  • From: Shuah Khan <shuahkh@xxxxxxxxxxxxxxx>
• Re: [PATCH v6] selftest: size: Add size test for Linux kernel
  • From: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
• Re: [PATCH v5] selftest: size: Add size test for Linux kernel
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• [PATCH v6] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH v5] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH v5] selftest: size: Add size test for Linux kernel
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v5] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH v5] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH v5] selftest: size: Add size test for Linux kernel
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v5] selftest: size: Add size test for Linux kernel
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• [PATCH v5] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH v4] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH v4] selftest: size: Add size test for Linux kernel
  • From: Josh Triplett <josh@xxxxxxxxxxxxxxxx>
• [PATCH v4] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH v3] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH v3] selftest: size: Add size test for Linux kernel
  • From: Shuah Khan <shuahkh@xxxxxxxxxxxxxxx>
• Re: [PATCH v3] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH v2] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: [PATCH] kselftest: Move the docs to the Documentation dir
  • From: Jonathan Corbet <corbet@xxxxxxx>
• Re: [PATCH v2] selftest: size: Add size test for Linux kernel
  • From: Shuah Khan <shuahkh@xxxxxxxxxxxxxxx>
• Re: [PATCH] kselftest: Move the docs to the Documentation dir
  • From: Shuah Khan <shuahkh@xxxxxxxxxxxxxxx>
• [PATCH] kselftest: Move the docs to the Documentation dir
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• [PATCH v2] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• [PATCH] selftest: size: Add size test for Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• [CFP] FOSDEM 2015 Embedded Devroom
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Tim Bird <tim.bird@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• AW: Create/Package kernel headers for self-compiled kernel
  • From: Benedikt Kleinmeier <benedikt.kleinmeier@xxxxxxxxxxxxxxxxx>
• Create/Package kernel headers for self-compiled kernel
  • From: Benedikt Kleinmeier <benedikt.kleinmeier@xxxxxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• RE: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• RE: Why is the deferred initcall patch not mainline?
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxxxxxxxxx>
• RE: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• RE: Why is the deferred initcall patch not mainline?
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Frank Rowand <frowand.list@xxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Dirk Behme <dirk.behme@xxxxxxxxxxxx>
• RE: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• RE: Why is the deferred initcall patch not mainline?
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxxxxxxxxx>
• Re: v3.18-rc1 bloat-o-meter
  • From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
• Re: v3.18-rc1 bloat-o-meter
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: v3.18-rc1 bloat-o-meter
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: v3.18-rc1 bloat-o-meter
  • From: Borislav Petkov <bp@xxxxxxxxx>
• v3.18-rc1 bloat-o-meter
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Dirk Behme <dirk.behme@xxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxxxxxxxx>
• Re: Why is the deferred initcall patch not mainline?
  • From: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxxxxxxxxx>
• RE: Why is the deferred initcall patch not mainline?
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxxxxxxxx>
• Why is the deferred initcall patch not mainline?
  • From: Dirk Behme <dirk.behme@xxxxxxxxx>
• Re: cpuidle - minimum time for sleep
  • From: Nishanth Menon <nm@xxxxxx>
• Re: cpuidle - minimum time for sleep
  • From: Valdis.Kletnieks@xxxxxx
• cpuidle - minimum time for sleep
  • From: Ran Shalit <ranshalit@xxxxxxxxx>
• Re: EP93XX/EDB9315A Audio Issue
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• EP93XX/EDB9315A Audio Issue
  • From: Jeremy Moles <jeremy@xxxxxxxxxxxxxxxx>
• Re: 3.15.4 runs *significantly* slower than 3.15.3 on iMX233 CPU
  • From: Marcelo Ricardo Leitner <marcelo.leitner@xxxxxxxxx>
• 3.15.4 runs *significantly* slower than 3.15.3 on iMX233 CPU
  • From: Manuel Reimer <Manuel.Spam@xxxxxxxxxxxxxx>
• RE: [OT, JOB] Xilinx, San Jose: 2 full-time openings for embedded systems/embedded software group
  • From: Wojciech Koszek <wojciech.koszek@xxxxxxxxxx>
• RE: [OT, JOB] Xilinx, San Jose: 2 full-time openings for embedded systems/embedded software group
  • From: "Bird, Tim" <Tim.Bird@xxxxxxxxxxxxxx>
• [OT, JOB] Xilinx, San Jose: 2 full-time openings for embedded systems/embedded software group
  • From: Wojciech Koszek <wojciech.koszek@xxxxxxxxxx>
• Re: "make oldconfig" kills config options when cross compiling
  • From: Manuel Reimer <Manuel.Spam@xxxxxxxxxxxxxx>
• Re: "make oldconfig" kills config options when cross compiling
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
• "make oldconfig" kills config options when cross compiling
  • From: Manuel Reimer <Manuel.Spam@xxxxxxxxxxxxxx>
• Re: Using ftrace to identify source of excessive latency of USB write
  • From: Mason <mpeg.blue@xxxxxxx>
• Re: Boot time: Initial main memory initialization optimizations?
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Boot time: Initial main memory initialization optimizations?
  • From: Dirk Behme <dirk.behme@xxxxxxxxx>
• New aboriginal linux release with 3.14 kernel.
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Using ftrace to identify source of excessive latency of USB write
  • From: Mason <mpeg.blue@xxxxxxx>
• Re: GPIO triggers kernel reboot
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: GPIO triggers kernel reboot
  • From: Arnaud Patard (Rtp) <arnaud.patard@xxxxxxxxxxx>
• Re: GPIO triggers kernel reboot
  • From: Heiko Schocher <hs@xxxxxxx>
• Re: GPIO triggers kernel reboot
  • From: Heiko Schocher <hs@xxxxxxx>
• Re: GPIO triggers kernel reboot
  • From: Florian Fainelli <f.fainelli@xxxxxxxxx>
• RE: GPIO triggers kernel reboot
  • From: "Mehaffey, John" <John_Mehaffey@xxxxxxxxxx>
• RE: GPIO triggers kernel reboot
  • From: "Mehaffey, John" <John_Mehaffey@xxxxxxxxxx>
• GPIO triggers kernel reboot
  • From: Heiko Schocher <hs@xxxxxxx>
• Re: U-Boot <-> Kernel; NAND operation proposal
  • From: Lambrecht Jürgen <J.Lambrecht@xxxxxxxxxxx>
• U-Boot <-> Kernel; NAND operation proposal
  • From: Leon Pollak <leonp@xxxxxxxxx>
• Re: Evolution of Linux kernel sizes
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: Evolution of Linux kernel sizes
  • From: Richard Cochran <richardcochran@xxxxxxxxx>
• Evolution of Linux kernel sizes
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [FOSDEM] [CFP] Embedded and mobile devroom
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v3] init: make init failures more explicit
  • From: Janne Karhunen <janne.karhunen@xxxxxxxxx>
• [PATCH v3] init: make init failures more explicit
  • From: Michael Opdenacker <michael.opdenacker@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2] init: make init failures more explicit
  • From: Michael Opdenacker <michael.opdenacker@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2] init: make init failures more explicit
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• [PATCH v2] init: make init failures more explicit
  • From: Michael Opdenacker <michael.opdenacker@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] init: make init failures more explicit
  • From: Janne Karhunen <janne.karhunen@xxxxxxxxx>
• Re: [PATCH] init: make init failures more explicit
  • From: Michael Opdenacker <michael.opdenacker@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] init: make init failures more explicit
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] init: make init failures more explicit
  • From: Kieran Bingham <kieranbingham@xxxxxxxxx>
• [PATCH] init: make init failures more explicit
  • From: Michael Opdenacker <michael.opdenacker@xxxxxxxxxxxxxxxxxx>
• Re: [JOB] ARM Embedded Developer - 100% Telecommute
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Fwd: kernel 3.0.93 on s3c2410 problome.
  • From: Kernux Zhang <kernuxzhang@xxxxxxxxx>
• Help wake from standby with ARM external nIRQ line
  • From: Steve deRosier <derosier@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Lambrecht Jürgen <J.Lambrecht@xxxxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Guenter Ebermann <guenter.ebermann@xxxxxxxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: AMP on an SMP system
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Lambrecht Jürgen <J.Lambrecht@xxxxxxxxxxx>
• Re: AMP on an SMP system
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: AMP on an SMP system
  • From: Jon Sevy <jsevy@xxxxxxxxxxxxx>
• Re: AMP on an SMP system
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: AMP on an SMP system
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• AMP on an SMP system
  • From: Michael Schnell <mschnell@xxxxxxxxx>
• Re: [PATCH 0/2] Squashfs: add LZ4 compression
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [PATCH 0/2] Squashfs: add LZ4 compression
  • From: Phillip Lougher <phillip.lougher@xxxxxxxxx>
• Re: [PATCH 0/2] Squashfs: add LZ4 compression
  • From: Gu Zheng <guz.fnst@xxxxxxxxxxxxxx>
• Re: [PATCH 0/2] Squashfs: add LZ4 compression
  • From: Phillip Lougher <phillip.lougher@xxxxxxxxx>
• Re: [PATCH 1/2] Squashfs: add LZ4 compression support
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH 0/2] Squashfs: add LZ4 compression
  • From: Gu Zheng <guz.fnst@xxxxxxxxxxxxxx>
• [PATCH 1/2] Squashfs: add LZ4 compression support
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxx>
• [PATCH 2/2] Squashfs: Add LZ4 compression configuration option
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxx>
• [PATCH 0/2] Squashfs: add LZ4 compression
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxx>
• ELCE CFP ends July 21st
  • From: Bill Traynor <btraynor@xxxxxxxxx>
• Re: Boot time: Optimize CPU bring up?
  • From: Abbas Raza <abbas_raza@xxxxxxxxxx>
• Re: [PATCH 01/32] init.h: remove __cpuinit sections from the kernel
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH 01/32] init.h: remove __cpuinit sections from the kernel
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH 1/2] ext2: Reduce object size when !CONFIG_PRINTK
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: [PATCH] ext4: Reduce object size when !CONFIG_PRINTK
  • From: "Theodore Ts'o" <tytso@xxxxxxx>
• Boot time: Optimize CPU bring up?
  • From: Dirk Behme <dirk.behme@xxxxxxxxxxxx>
• [PATCH] ext4: Reduce object size when !CONFIG_PRINTK
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: Need help to measure and tune the latency in Linux RT
  • From: Ashoka K <ashok.vinu@xxxxxxxxx>
• RE: [systemd-devel] 2013 Plumber's CFP: Fastboot
  • From: "Mehaffey, John" <John_Mehaffey@xxxxxxxxxx>
• Re: [systemd-devel] 2013 Plumber's CFP: Fastboot
  • From: Lennart Poettering <mzxreary@xxxxxxxxxxx>
• RE: [systemd-devel] 2013 Plumber's CFP: Fastboot
  • From: "Mehaffey, John" <John_Mehaffey@xxxxxxxxxx>
• Re: [systemd-devel] 2013 Plumber's CFP: Fastboot
  • From: Lucas De Marchi <lucas.de.marchi@xxxxxxxxx>
• Re: [systemd-devel] 2013 Plumber's CFP: Fastboot
  • From: Lennart Poettering <mzxreary@xxxxxxxxxxx>
• RE: 2013 Plumber's CFP: Fastboot
  • From: "Mehaffey, John" <John_Mehaffey@xxxxxxxxxx>
• Re: 2013 Plumber's CFP: Fastboot
  • From: richard -rw- weinberger <richard.weinberger@xxxxxxxxx>
• Re: [U-Boot] 2013 Plumber's CFP: Fastboot
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• 2013 Plumber's CFP: Fastboot
  • From: "Mehaffey, John" <John_Mehaffey@xxxxxxxxxx>
• Re: Need help to measure and tune the latency in Linux RT
  • From: Ashoka K <ashok.vinu@xxxxxxxxx>
• Re: Need help to measure and tune the latency in Linux RT
  • From: ddegraff <ddegraff@xxxxxxxxxx>
• Re: Need help to measure and tune the latency in Linux RT
  • From: Stanislav Meduna <stano@xxxxxxxxxx>
• Re: Need help to measure and tune the latency in Linux RT
  • From: Jason Cooper <jason@xxxxxxxxxxxxxx>
• Need help to measure and tune the latency in Linux RT
  • From: Ashoka K <ashok.vinu@xxxxxxxxx>
• Re: How to use DEBUG macros in compressed/head.S
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: How to use DEBUG macros in compressed/head.S
  • From: Baurzhan Ismagulov <ibr@xxxxxxxxxxx>
• How to use DEBUG macros in compressed/head.S
  • From: "zhaoyilong" <registcn@xxxxxxxxx>
• Re: I can only receive email from lkml,why?
  • From: "Vladimir Murzin" <murzin.v@xxxxxxxxx>
• Re: I can only receive email from lkml,why?
  • From: "zhaoyilong" <registcn@xxxxxxxxx>
• Re: I can only receive email from lkml,why?
  • From: "Steven J. Hill" <sjhill@xxxxxxxxxxxxxxxxxx>
• I can only receive email from lkml,why?
  • From: "zhaoyilong" <registcn@xxxxxxxxx>
• [head.S]open DEBUG in compressed/head.S, kernel crashed...
  • From: "zhaoyilong" <registcn@xxxxxxxxx>
• opening DEBUG in compressed/head.S, kernel crashed
  • From: "zhaoyilong" <registcn@xxxxxxxxx>
• Re: Need help adding platform UIO devices to board
  • From: Alexander Varnin <fenixk19@xxxxxxx>
• Re: Need help adding platform UIO devices to board
  • From: Alexander Varnin <fenixk19@xxxxxxx>
• Re: Need help adding platform UIO devices to board
  • From: Alexander Varnin <fenixk19@xxxxxxx>
• Re: Need help adding platform UIO devices to board
  • From: Nicholas Mc Guire <der.herr@xxxxxxx>
• Need help adding platform UIO devices to board
  • From: Alexander Varnin <fenixk19@xxxxxxx>
• [FOSDEM] Embedded and mobile devroom CFP
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• no console prompt after booting kernel
  • From: herve bourricaud <herve.bourricaud@xxxxxxxxxxxxxxxxxxxxx>
• LDT - Linux Driver Template
  • From: Constantine Shulyupin <const@xxxxxxxxxxxxx>
• Re: History of embedded Linux
  • From: Jeff Osier-Mixon <jefro@xxxxxxxxx>
• [PATCH] lib/decompress.c adding __init to decompress_method and data
  • From: Hein Tibosch <hein_tibosch@xxxxxxxx>
• Re: Expose system Serial Number to userspace.
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• Re: Expose system Serial Number to userspace.
  • From: Brad Arnold <brad@xxxxxxxxxxx>
• Re: Expose system Serial Number to userspace.
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• RE: Expose system Serial Number to userspace.
  • From: Brad Arnold <brad@xxxxxxxxxxx>
• RE: Expose system Serial Number to userspace.
  • From: Brad Arnold <brad@xxxxxxxxxxx>
• Re: Expose system Serial Number to userspace.
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: Expose system Serial Number to userspace.
  • From: Nicolas Pitre <nico@xxxxxxxxxxx>
• Expose system Serial Number to userspace.
  • From: Brad Arnold <brad@xxxxxxxxxxx>
• Re: NCD, a light scripting language for network configs and much more
  • From: Stephen Hemminger <shemminger@xxxxxxxxxx>
• NCD, a light scripting language for network configs and much more
  • From: Ambroz Bizjak <ambrop7@xxxxxxxxx>
• Re: [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index
  • From: Dirk Behme <dirk.behme@xxxxxxxxxxxx>
• Re: [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index
  • From: Jassi Brar <jaswinder.singh@xxxxxxxxxx>
• Re: [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index
  • From: Chris Ball <cjb@xxxxxxxxxx>
• [PATCH 1/2] mmc: block: mmcblkN: use slot index instead of dynamic name index
  • From: Dirk Behme <dirk.behme@xxxxxxxxxxxx>
• [PATCH 2/2] mmc: block: remove unused name_idx
  • From: Dirk Behme <dirk.behme@xxxxxxxxxxxx>
• History of embedded Linux
  • From: Chris Simmonds <chris.simmonds@xxxxxxxxxx>
• Help with testing "flash-kernel" for stable release update (SRU)
  • From: David Cullen <David.Cullen@xxxxxxxxxxxxxxxx>
• [announce] Embedded Linux Conference Call for Presentations
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• RE: rionet driver with MMIO DMA capability
  • From: Li Yang-R58472 <r58472@xxxxxxxxxxxxx>
• Re: Need help regarding the USB mass storage driver
  • From: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
• Re: Need help regarding the USB mass storage driver
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• Need help regarding the USB mass storage driver
  • From: Vishal Nandanwar <operational.people@xxxxxxxxx>
• Re: Q: file system for embedded
  • From: Christophe Aeschlimann <c.aeschlimann@xxxxxxxxxxxx>
• Re: Q: file system for embedded
  • From: Ran Shalit <ranshalit@xxxxxxxxx>
• Re: Q: file system for embedded
  • From: Christophe Aeschlimann <c.aeschlimann@xxxxxxxxxxxx>
• Q: file system for embedded
  • From: Ran Shalit <ranshalit@xxxxxxxxx>
• Bids for open project proposals
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• [PATCH] kernel: Shrink embedded kernel, remove WARN strings when !CONFIG_PRINTK
  • From: Joe Perches <joe@xxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Igor Grinberg <grinberg@xxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Stephen Warren <swarren@xxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Stephen Warren <swarren@xxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Igor Grinberg <grinberg@xxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Ben Dooks <ben-linux@xxxxxxxxx>
• Re: Handling of modular boards
  • From: Ben Dooks <ben@xxxxxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Alessandro Rubini <rubini@xxxxxxxxx>
• Re: Handling of modular boards
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: Handling of modular boards
  • From: Linus Walleij <linus.walleij@xxxxxxxxxx>
• Re: Handling of modular boards
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Stephen Warren <swarren@xxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: Handling of modular boards
  • From: Stephen Warren <swarren@xxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: Handling of modular boards
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: Handling of modular boards
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: Handling of modular boards
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: Handling of modular boards
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Stephen Warren <swarren@xxxxxxxxxxxxx>
• Re: Handling of modular boards
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Handling of modular boards
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Low Cost, 2 Ethernet Ports
  • From: Brian <unixman83@xxxxxxxxx>
• Call for presentations for the LSM embedded and open hardware track 2012
  • From: Florian Fainelli <florian@xxxxxxxxxxx>
• Re: ELC2012 Presentations and Video
  • From: Bill Traynor <wmat@xxxxxxx>
• Re: ELC2012 Presentations and Video
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• ELC2012 Presentations and Video
  • From: Bill Traynor <wmat@xxxxxxx>
• [Vortex86] External SPI
  • From: Lukasz Majewski <majess1982@xxxxxxxxx>
• Re: [PATCH 5/5] logger: clarify non-update of w_off in do_write_log_from_user
  • From: Dima Zavin <dima@xxxxxxxxxxx>
• Re: [PATCH 4/5] logger: clarify code in clock_interval
  • From: Dima Zavin <dima@xxxxxxxxxxx>
• Re: [PATCH 2/5 v2] logger: simplify and optimize get_entry_len
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH 3/5] logger: reorder prepare_to_wait and mutex_lock
  • From: Dima Zavin <dima@xxxxxxxxxxx>
• Re: [PATCH 2/5 v2] logger: simplify and optimize get_entry_len
  • From: Dima Zavin <dima@xxxxxxxxxxx>
• Re: [PATCH 1/5] logger: Change logger_offset() from macro to function
  • From: Dima Zavin <dima@xxxxxxxxxxx>
• [PATCH 2/5 v2] logger: simplify and optimize get_entry_len
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH 1/5] logger: Change logger_offset() from macro to function
  • From: Frank Rowand <frank.rowand@xxxxxxxxxxx>
• [PATCH 5/5] logger: clarify non-update of w_off in do_write_log_from_user
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• [PATCH 4/5] logger: clarify code in clock_interval
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• [PATCH 3/5] logger: reorder prepare_to_wait and mutex_lock
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• [PATCH 2/5] logger: simplify and optimize get_entry_len
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• [PATCH 1/5] logger: Change logger_offset() from macro to function
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Geunsik Lim <leemgs1@xxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Lennart Poettering <mzxreary@xxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: NeilBrown <neilb@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: Brian Swetland <swetland@xxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: david@xxxxxxx
• Re: RFC: android logger feedback request
  • From: david@xxxxxxx
• Re: RFC: android logger feedback request
  • From: david@xxxxxxx
• Re: RFC: android logger feedback request
  • From: Brian Swetland <swetland@xxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: david@xxxxxxx
• Re: RFC: android logger feedback request
  • From: Brian Swetland <swetland@xxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: david@xxxxxxx
• Re: RFC: android logger feedback request
  • From: david@xxxxxxx
• Re: RFC: android logger feedback request
  • From: david@xxxxxxx
• Re: RFC: android logger feedback request
  • From: david@xxxxxxx
• Re: RFC: android logger feedback request
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Brian Swetland <swetland@xxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Brian Swetland <swetland@xxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: NeilBrown <neilb@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: john stultz <johnstul@xxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: john stultz <johnstul@xxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: David Brown <davidb@xxxxxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: john stultz <johnstul@xxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: john stultz <johnstul@xxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• Re: RFC: android logger feedback request
  • From: john stultz <johnstul@xxxxxxxxxx>
• Re: RFC: android logger feedback request
  • From: Greg KH <gregkh@xxxxxxx>
• RFC: android logger feedback request
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Android mainlining project
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Android mainlining project
  • From: Geunsik Lim <leemgs1@xxxxxxxxx>
• Android mainlining project
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Fosdem embedded and mobile devroom call for papers
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: Help needed with porting 32-bit user ioctl to run on a 64-bit kernel
  • From: Linux Rules <linuzoo@xxxxxxxxx>
• Help needed with porting 32-bit user ioctl to run on a 64-bit kernel
  • From: Linux Rules <linuzoo@xxxxxxxxx>
• Re: [PATCH RFC 3/5] kbuild/extable: Hook up sortextable into the build system.
  • From: David Daney <ddaney.cavm@xxxxxxxxx>
• Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
  • From: Mike Frysinger <vapier@xxxxxxxxxx>
• Re: [PATCH RFC 1/5] scripts: Add sortextable to sort the kernel's exception table.
  • From: David Daney <ddaney.cavm@xxxxxxxxx>