Linux Embedded

• Thread Index

• Re: usb-skeleton.c - generates warning
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• usb-skeleton.c - generates warning
  • From: Andrew Worsley <amworsley@xxxxxxxxx>
• Re: [PWM 06/10] Incorporate PWM API code into KBuild
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PWM 05/10] LED "dim" trigger based on PWM control of the LED
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PWM 04/10] Implements PWM-based LED control
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PWM 03/10] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PWM 02/10] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: Linux Plumbers Embedded microconference
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: Linux Plumbers Embedded microconference
  • From: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 15/16] pramfs: test module
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [PATCH 14(16] pramfs: memory protection
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• Re: [PATCH 14(16] pramfs: memory protection
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH 14(16] pramfs: memory protection
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• Re: [PATCH 14(16] pramfs: memory protection
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH 11/16] pramfs: ACL management
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH 11/16] pramfs: ACL management
  • From: Kieran Bingham <kieranbingham@xxxxxxxxx>
• Re: [PATCH 15/16] pramfs: test module
  • From: Kieran Bingham <kieranbingham@xxxxxxxxx>
• Re: [PATCH 16/16] pramfs Makefile and Kconfig
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH 15/16] pramfs: test module
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH 14(16] pramfs: memory protection
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: logfs segfaults at umount time
  • From: Michael Opdenacker <michael.opdenacker@xxxxxxxxxxxxxxxxxx>
• Re: logfs segfaults at umount time
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: [PATCH 16/16] pramfs Makefile and Kconfig
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxx>
• [PATCH 10/16] pramfs: xip operations
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH 15/16] pramfs: test module
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxx>
• [PATCH 04/16] pramfs: file operations
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH 14(16] pramfs: memory protection
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• [PATCH 15/16] pramfs: test module
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 11/16] pramfs: ACL management
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 13/16] pramfs: xattr block descriptors tree
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 16/16] pramfs Makefile and Kconfig
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 14(16] pramfs: memory protection
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 12/16] pramfs: extended attributes
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 08/16] pramfs: headers
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 09/16] pramfs: dir operations
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• logfs segfaults at umount time
  • From: Michael Opdenacker <michael.opdenacker@xxxxxxxxxxxxxxxxxx>
• [PATCH 07/16] pramfs: symbolic links
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 06/16] pramfs: inode operations for dirs
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 05/16] pramfs: block allocation
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 01/16] pramfs: documentation
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 02/16] pramfs: super block operations
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 03/17] pramfs: inode operations
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 00/16] pramfs: persistent and protected RAM Filesystem
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH 4/4] davinci: da850/omap-l138 evm: Platform support for backlight driver
  • From: sugumar <sugumar@xxxxxx>
• [PATCH 3/4] Modify the back light driver to support the new PWM framework
  • From: sugumar <sugumar@xxxxxx>
• [PATCH 2/4] davinci: da850: Add platform specific support for eCAP driver
  • From: sugumar <sugumar@xxxxxx>
• [PATCH 1/4] davinci: da8xx: eCAP driver for PWM signal generation
  • From: sugumar <sugumar@xxxxxx>
• [PATCH 0/4] Add eCAP driver support for PWM based backlight control.
  • From: sugumar <sugumar@xxxxxx>
• RE: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: "Sugumar Natarajan" <sugumar@xxxxxx>
• Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx>
• RE: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: "Grosen, Mark" <mgrosen@xxxxxx>
• Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PATCH] pramfs: Persistent and protected RAM filesystem
  • From: Minchan Kim <minchan.kim@xxxxxxxxx>
• [PATCH] pramfs: Persistent and protected RAM filesystem
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: sugumar <sugumar.embedded@xxxxxxxxx>
• Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: Hector Oron <hector.oron@xxxxxxxxx>
• Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: Jason Kridner <jkridner@xxxxxxxxxxxxxxx>
• Re: [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx>
• [PWM 08/10] Initial support for PXA PWM peripheral; compile-tested only
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM 04/10] Implements PWM-based LED control
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM 01/10] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM 03/10] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM 07/10] PWM API driver for MPC52xx GPT peripheral
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM 10/10] Expunge previous driver for PXA PWM
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM 06/10] Incorporate PWM API code into KBuild
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM 02/10] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM 05/10] LED "dim" trigger based on PWM control of the LED
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM 09/10] Build pwm.o only if CONFIG_GENERIC_PWM is set
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: how to increase memory limit reduced at boot-time by "mem"
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• how to increase memory limit reduced at boot-time by "mem"
  • From: "CEVAN Ondrej" <Ondrej.CEVAN@xxxxxxxxxxxxxx>
• Re: Linux Plumbers Embedded microconference
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: Linux Plumbers Embedded microconference
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Linux Plumbers Embedded microconference
  • From: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx>
• Re: Linux Plumbers Embedded microconference
  • From: Liam Girdwood <lrg@xxxxxxxxxxxxxxx>
• [ANN] Squashfs tools 4.1 released
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: Linux Plumbers Embedded microconference
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Linux Plumbers Embedded microconference
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: ARM target not boot after remap memory
  • From: Robin Theunis <robint91@xxxxxxxxx>
• Re: ARM target not boot after remap memory
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: ARM target not boot after remap memory
  • From: Robin Theunis <robint91@xxxxxxxxx>
• Re: ARM target not boot after remap memory
  • From: Robin Theunis <robint91@xxxxxxxxx>
• Re: ARM target not boot after remap memory
  • From: Johannes Stezenbach <js@xxxxxxxxx>
• Fwd: ARM target not boot after remap memory
  • From: Robin Theunis <robint91@xxxxxxxxx>
• Re: ARM target not boot after remap memory
  • From: Robin Theunis <robint91@xxxxxxxxx>
• Generic PWM kernel driver (with support for OMAP3)
  • From: "Kridner, Jason" <jdk@xxxxxx>
• Re: ARM target not boot after remap memory
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: ARM target not boot after remap memory
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: ARM target not boot after remap memory
  • From: Johannes Stezenbach <js@xxxxxxxxx>
• Re: ARM target not boot after remap memory
  • From: Mike Rapoport <mike@xxxxxxxxxxxxxx>
• ARM target not boot after remap memory
  • From: Robin Theunis <robint91@xxxxxxxxx>
• LCTES 2011: Submission site is now open!
  • From: Tomas Kalibera <kalibera@xxxxxxxxxxxxxxxxxxx>
• Embedded Linux Conference videos
  • From: Michael Opdenacker <michael.opdenacker@xxxxxxxxxxxxxxxxxx>
• patch "add ttyprintk driver" added to gregkh-2.6 tree
  • From: <gregkh@xxxxxxx>
• Re: [RFC] Kernel 'boot cache' to reduce boot time
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [RFC] Kernel 'boot cache' to reduce boot time
  • From: Andrew Murray <amurray@xxxxxxxxxxx>
• Re: [RFC] Kernel 'boot cache' to reduce boot time
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• [RFC] Kernel 'boot cache' to reduce boot time
  • From: Andrew Murray <amurray@xxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Embedded Linux Conference Europe Program Announced
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Greg KH <gregkh@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] RFC: AMBA bus discardable probe() function
  • From: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
• RE: [PATCH] RFC: AMBA bus discardable probe() function
  • From: Linus WALLEIJ <linus.walleij@xxxxxxxxxxxxxx>
• RE: [PATCH] RFC: AMBA bus discardable probe() function
  • From: Linus WALLEIJ <linus.walleij@xxxxxxxxxxxxxx>
• Re: Where to post an embedded-centric filesystem driver?
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Where to post an embedded-centric filesystem driver?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Planning on updating the PWM patches soon...
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Cfp - Languages, Compilers, Tools and Theory,for Embedded Systems
  • From: Tomas Kalibera <kalibera@xxxxxxxxxxxxxxxxxxx>
• NFSRoot over PCMCIA with Static Kernel
  • From: Nilesh Govindarajan <lists@xxxxxxxxxx>
• SAM9-L9260: TXD1 is not working on AT91SAM9260
  • From: Stefan Schoenleitner <dev.c0debabe@xxxxxxxxx>
• Re: Embedded topics at Linux Plumbers 2010
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: Updated cs8900a driver available anywhere?
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Updated cs8900a driver available anywhere?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Embedded topics at Linux Plumbers 2010
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: Information on XIP
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: Information on XIP
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Information on XIP
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Information on XIP
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver - now ttyprintk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: omap udc driver problem with beagle board
  • From: Felipe Balbi <felipe.balbi@xxxxxxxxx>
• Re: omap udc driver problem with beagle board
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: omap udc driver problem with beagle board
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: omap udc driver problem with beagle board
  • From: Felipe Balbi <me@xxxxxxxxxxxxxxx>
• omap nand driver problem with beagle board
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• omap udc driver problem with beagle board
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH] detour TTY driver
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] detour TTY driver
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] detour TTY driver
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: Ming Lei <tom.leiming@xxxxxxxxx>
• Re: [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: Ming Lei <tom.leiming@xxxxxxxxx>
• Re: [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: Ming Lei <tom.leiming@xxxxxxxxx>
• Re: [Squashfs-devel] [PATCH 1/2] Squashfs: add LZO decompression support
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: Ming Lei <tom.leiming@xxxxxxxxx>
• Re: [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• Re: [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: Ming Lei <tom.leiming@xxxxxxxxx>
• Re: [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• [RESEND PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: tom.leiming@xxxxxxxxx
• Re: [Squashfs-devel] [PATCH 2/2] Squashfs-tools: add LZO support
  • From: kirk w <kirkpuppy@xxxxxxxxx>
• Squashfs extended attribute file system support
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH] detour TTY driver
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• [PATCH] tagged console logging detour via printk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• [PATCH] ARM: fix 'unannotated irqs-on' lockdep warning
  • From: tom.leiming@xxxxxxxxx
• Re: [PATCH] ARM: fix inbalance of hardirqs trace before return to user or exception
  • From: Ming Lei <tom.leiming@xxxxxxxxx>
• Re: [PATCH] ARM: fix inbalance of hardirqs trace before return to user or exception
  • From: Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>
• [PATCH] ARM: fix inbalance of hardirqs trace before return to user or exception
  • From: tom.leiming@xxxxxxxxx
• Re: Can I manage/modify console baud rates from userspace?
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: Can I manage/modify console baud rates from userspace?
  • From: Paul Smith <paul@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: Can I manage/modify console baud rates from userspace?
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: Can I manage/modify console baud rates from userspace?
  • From: Paul Smith <paul@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: Can I manage/modify console baud rates from userspace?
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Can I manage/modify console baud rates from userspace?
  • From: Paul Smith <paul@xxxxxxxxxxxxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [PATCH] console logging detour via printk
  • From: Randy Dunlap <rdunlap@xxxxxxxxxxxx>
• [PATCH] console logging detour via printk
  • From: Samo Pogacnik <samo_pogacnik@xxxxxxx>
• Re: [Libmtp-discuss] [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Felipe Balbi <felipe.balbi@xxxxxxxxx>
• Mini Laptop 10.2" (all in One) and Power Plus (Distributor Wanted)
  • From: "Vizro Technologies" <info@xxxxxxxxx>
• Re: Status of SquashFS LZMA support in mainline
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Status of SquashFS LZMA support in mainline
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Linus Walleij <linus.ml.walleij@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Michał Nazarewicz <m.nazarewicz@xxxxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Roger Quadros <roger.quadros@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Greg KH <greg@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Linus Walleij <linus.ml.walleij@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Roger Quadros <roger.quadros@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Roger Quadros <roger.quadros@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Felipe Balbi <felipe.balbi@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Felipe Balbi <felipe.balbi@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Linus Walleij <linus.ml.walleij@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Greg KH <greg@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Steve Calfee <stevecalfee@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Felipe Balbi <felipe.balbi@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Felipe Balbi <felipe.balbi@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Linus Walleij <linus.ml.walleij@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Michał Nazarewicz <m.nazarewicz@xxxxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Felipe Balbi <felipe.balbi@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Greg KH <greg@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Michał Nazarewicz <m.nazarewicz@xxxxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Felipe Balbi <felipe.balbi@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Linus Walleij <linus.ml.walleij@xxxxxxxxx>
• Re: [RFC/PATCH 0/2] u_char.c and mtp.c patches
  • From: Linus Walleij <linus.ml.walleij@xxxxxxxxx>
• Re: [PATCH] Pseudo-console for capture and redirection of console output
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [PATCH] Pseudo-console for capture and redirection of console output
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH] Pseudo-console for capture and redirection of console output
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• [PATCH] Pseudo-console for capture and redirection of console output
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Paul Mundt <lethal@xxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Paul Mundt <lethal@xxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: A better way to sequence driver initialization?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• A better way to sequence driver initialization?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PATCH 0/3] RFC: direct MTD support for SquashFS
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH 2/3] squashfs: gather everything block device specific into block.c
  • From: Ferenc Wagner <wferi@xxxxxxx>
• [PATCH 2/3] squashfs: gather everything block device specific into block.c
  • From: Ferenc Wagner <wferi@xxxxxxx>
• [PATCH 0/3] RFC: direct MTD support for SquashFS
  • From: Ferenc Wagner <wferi@xxxxxxx>
• [PATCH 1/3] squashfs: parametrize decompressors on buffer_head operations
  • From: Ferenc Wagner <wferi@xxxxxxx>
• [PATCH 3/3] squashfs: add MTD backend
  • From: Ferenc Wagner <wferi@xxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Ferenc Wagner <wferi@xxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Ferenc Wagner <wferi@xxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Embedded Linux Conference Europe 2009 videos
  • From: Michael Opdenacker <michael@xxxxxxxxxxxxxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Ferenc Wagner <wferi@xxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Ferenc Wagner <wferi@xxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Ferenc Wagner <wferi@xxxxxxx>
• [PATCH v3] char drivers: Ram oops/panic logger
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Ferenc Wagner <wferi@xxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Phillip Lougher <phillip.lougher@xxxxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Ferenc Wagner <wferi@xxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Ferenc Wagner <wferi@xxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Phillip Lougher <phillip.lougher@xxxxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Ferenc Wagner <wferi@xxxxxxx>
• [PATCH} V4L: do not autoselect components on embedded systems
  • From: Guennadi Liakhovetski <g.liakhovetski@xxxxxx>
• [PATCH-V2] devtmpfs: support !CONFIG_TMPFS
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
  • From: Greg KH <greg@xxxxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Vitaly Wool <vitalywool@xxxxxxxxx>
• Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
  • From: Greg KH <greg@xxxxxxxxx>
• Re: RFC: direct MTD support for SquashFS
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
  • From: Greg KH <greg@xxxxxxxxx>
• Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• Re: [PATCH v2] char drivers: Ram oops/panic logger
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH v2] char drivers: Ram oops/panic logger
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [PATCH v2] char drivers: Ram oops/panic logger
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH v2] char drivers: Ram oops/panic logger
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH v2] char drivers: Ram oops/panic logger
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH v2] char drivers: Ram oops/panic logger
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [PATCH v2] char drivers: Ram oops/panic logger
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
  • From: Kay Sievers <kay.sievers@xxxxxxxx>
• Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• Re: [PATCH] devtmpfs: support !CONFIG_TMPFS
  • From: Michael Tokarev <mjt@xxxxxxxxxx>
• [PATCH] devtmpfs: support !CONFIG_TMPFS
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• [ANNOUNCE] ELC 2010 Program is available - registration open
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH v2] char drivers: Ram oops/panic logger
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH v2] char drivers: Ram oops/panic logger
  • From: Yuasa Yoichi <yuasa@xxxxxxxxxxxxxx>
• Re: [PATCH v2] char drivers: Ram oops/panic logger
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH v2] char drivers: Ram oops/panic logger
  • From: Yuasa Yoichi <yuasa@xxxxxxxxxxxxxx>
• [PATCH v2] char drivers: Ram oops/panic logger
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH]: Ram oops/panic logger
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH 03/11] readahead: bump up the default readahead size
  • From: Wu Fengguang <fengguang.wu@xxxxxxxxx>
• RE: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: "H Hartley Sweeten" <hartleys@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 03/11] readahead: bump up the default readahead size
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• Re: [PATCH 03/11] readahead: bump up the default readahead size
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PATCH 03/11] readahead: bump up the default readahead size
  • From: Wu Fengguang <fengguang.wu@xxxxxxxxx>
• RE: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: "H Hartley Sweeten" <hartleys@xxxxxxxxxxxxxxxxxxx>
• Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: "Stanislav O. Bezzubtsev" <stas@xxxxxxxxxxxxx>
• Re: [PATCH 03/11] readahead: bump up the default readahead size
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [PATCH 03/11] readahead: bump up the default readahead size
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• Re: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: Pavel Machek <pavel@xxxxxx>
• RE: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
  • From: "H Hartley Sweeten" <hartleys@xxxxxxxxxxxxxxxxxxx>
• RE: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
  • From: "H Hartley Sweeten" <hartleys@xxxxxxxxxxxxxxxxxxx>
• Re: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PWM PATCH 2/7] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• RE: [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
  • From: "H Hartley Sweeten" <hartleys@xxxxxxxxxxxxxxxxxxx>
• [PWM PATCH 1/7] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 0/7] Generic PWM API
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 3/7] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 5/7] LED "dim" trigger based on PWM control of the LED
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 6/7] Incorporate PWM API code into KBuild
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 4/7] Implements PWM-based LED control
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 2/7] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 7/7] PWM API driver for MPC52xx GPT peripheral
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PATCH 03/11] readahead: bump up the default readahead size
  • From: Wu Fengguang <fengguang.wu@xxxxxxxxx>
• Re: Freescale MPC8313 TSEC SGMII problem.
  • From: Rajkumar M <rajkumarm2@xxxxxxxxx>
• Re: Freescale MPC8313 TSEC SGMII problem.
  • From: hmthalib <h.thalib@xxxxxxxxx>
• Re: [PWM PATCH 0/5] Implements a common PWM API
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• RE: [PWM PATCH 0/5] Implements a common PWM API
  • From: "H Hartley Sweeten" <hartleys@xxxxxxxxxxxxxxxxxxx>
• Re: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: xilinx_spi in linux-next
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• RE: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: "H Hartley Sweeten" <hartleys@xxxxxxxxxxxxxxxxxxx>
• Re: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PWM PATCH 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PWM PATCH 0/5] Implements a common PWM API
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• RE: [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: "H Hartley Sweeten" <hartleys@xxxxxxxxxxxxxxxxxxx>
• RE: [PWM PATCH 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API
  • From: "H Hartley Sweeten" <hartleys@xxxxxxxxxxxxxxxxxxx>
• RE: [PWM PATCH 0/5] Implements a common PWM API
  • From: "H Hartley Sweeten" <hartleys@xxxxxxxxxxxxxxxxxxx>
• Re: [PWM PATCH 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 4/5] PWM-based LED control
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 5/5] LED "dimmer" trigger
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 0/5] Implements a common PWM API
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [PWM PATCH 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Freescale MPC8313 TSEC SGMII problem.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Chris Simmonds <chris@xxxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: /dev/fw major not constant (embedded mdev devtmpfs ieee1394)
  • From: Greg KH <greg@xxxxxxxxx>
• Re: /dev/fw major not constant (embedded mdev devtmpfs ieee1394)
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Re: /dev/fw major not constant (embedded mdev devtmpfs ieee1394)
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: /dev/fw major not constant (embedded mdev devtmpfs ieee1394)
  • From: Greg KH <greg@xxxxxxxxx>
• /dev/fw major not constant (embedded mdev devtmpfs ieee1394)
  • From: Paul Chavent <paul.chavent@xxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Matthias Kaehlcke <matthias@xxxxxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Matthias Kaehlcke <matthias@xxxxxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Matthias Kaehlcke <matthias@xxxxxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Ricard Wanderlof <ricard.wanderlof@xxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Matthias Kaehlcke <matthias@xxxxxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Ricard Wanderlof <ricard.wanderlof@xxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Matthias Kaehlcke <matthias@xxxxxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Matthias Kaehlcke <matthias@xxxxxxxxxxxx>
• Re: mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• mount ramdisk rootfs /etc directory to jffs2 filesystem.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: jffs2_gcd_mtdx thread and umount problem.
  • From: Joakim Tjernlund <joakim.tjernlund@xxxxxxxxxxxx>
• Re: jffs2_gcd_mtdx thread and umount problem.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: jffs2_gcd_mtdx thread and umount problem.
  • From: Joakim Tjernlund <joakim.tjernlund@xxxxxxxxxxxx>
• jffs2_gcd_mtdx thread and umount problem.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: flash_platform_data namespace collision
  • From: David Brownell <david-b@xxxxxxxxxxx>
• Re: flash_platform_data namespace collision
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• Re: flash_platform_data namespace collision
  • From: Russell King <rmk+lkml@xxxxxxxxxxxxxxxx>
• Re: flash_platform_data namespace collision
  • From: David Brownell <david-b@xxxxxxxxxxx>
• flash_platform_data namespace collision
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• [PATCH] modpost: Support objects with more than 64k sections
  • From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
• Re: [PATCH V2 6/8] lzma: Make lzma ... thunderbird ok
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH V2 6/8] lzma: Make lzma ... thunderbird ok
  • From: Hein_Tibosch <hein_tibosch@xxxxxxxx>
• [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
  • From: Phillip Lougher <phillip.lougher@xxxxxxxxx>
• Re: [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• Re: [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
  • From: Albin Tonnerre <albin.tonnerre@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/9] Squashfs: Add support for LZMA compressed filesystems
  • From: Bruno Wolff III <bruno@xxxxxxxx>
• Re: [PATCH 0/9] Squashfs: Add support for LZMA compressed filesystems
  • From: Bruno Wolff III <bruno@xxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: Re: How to store kernel panic/oops
  • From: Paul Mundt <lethal@xxxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• Re: Re: How to store kernel panic/oops
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: CELF Project Proposal - Feasibility analisys of Android introduction in a completely tested industrial device
  • From: Raffaele Recalcati <lamiaposta71@xxxxxxxxx>
• Re: How to store kernel pranic/oops
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• How to store kernel pranic/oops
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Rob Landley <rob@xxxxxxxxxxx>
• [ANNOUNCE] barebox-2009.12.0 has been released
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Jamie Lokier <jamie@xxxxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: CELF Project Proposal - Feasibility analisys of Android introduction in a completely tested industrial device
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: CELF Project proposal: UBIFS mount-time speedups
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH 0/9] Squashfs: Add support for LZMA compressed filesystems
  • From: Bruno Wolff III <bruno@xxxxxxxx>
• Re: [PATCH 0/9] Squashfs: Add support for LZMA compressed filesystems
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/9] Squashfs: Add support for LZMA compressed filesystems
  • From: Bruno Wolff III <bruno@xxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Wookey <wookey@xxxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Wookey <wookey@xxxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: CELF Project Proposal - Feasibility analisys of Android introduction in a completely tested industrial device
  • From: alucero@xxxxxxxxx
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Matt Hsu <matt@xxxxxxxxx>
• Re: [Celinux-dev] CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Rob Landley <rob@xxxxxxxxxxx>
• Re: CELF Project proposal: UBIFS mount-time speedups
  • From: Kyungmin Park <kmpark@xxxxxxxxxxxxx>
• Re: CELF Project Proposal - Feasibility analisys of Android introduction in a completely tested industrial device
  • From: Raffaele Recalcati <lamiaposta71@xxxxxxxxx>
• CELF Project Proposal - Feasibility analisys of Android introduction in a completely tested industrial device
  • From: Raffaele Recalcati <lamiaposta71@xxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Pavel Machek <pavel@xxxxxx>
• Re: CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: CELF Project Proposal: Create a watchdog framework for the Linux kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• CELF Project Proposal: Create a watchdog framework for the Linux kernel
  • From: Wolfram Sang <w.sang@xxxxxxxxxxxxxx>
• Re: Project Proposal: add sleeping spinlocks to mainline kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: Project Proposal: add sleeping spinlocks to mainline kernel
  • From: Linus Walleij <linus.ml.walleij@xxxxxxxxx>
• Re: CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Andy Green <andy@xxxxxxxxxxx>
• CELF Project Proposal- Refactoring Qi, lightweight bootloader
  • From: Matt Hsu <matt@xxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Pavel Machek <pavel@xxxxxx>
• Project Proposal: add sleeping spinlocks to mainline kernel
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: CELF Project Proposal - ALSA scenario/use case support
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• CELF Project Proposal - ALSA scenario/use case support
  • From: Liam Girdwood <lrg@xxxxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Andy Green <andy@xxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Stanislav Brabec <utx@xxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Aras Vaichas <arasv@xxxxxxxxxxxxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• CELF Project proposal: UBIFS mount-time speedups
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Aras Vaichas <arasv@xxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 3/3] initramfs: add missing decompressor error check
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 0/3] bzip2/lzma/gzip/initramfs: NULL pointer bugs and missing error checks
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 2/3] bzip2: Add missing checks for malloc returning NULL
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 1/3] bzip2/lzma/gzip: pre-boot malloc doesn't return NULL on failure
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/9] Squashfs: Add support for LZMA compressed filesystems
  • From: Arkadiusz Miśkiewicz <arekm@xxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Pavel Machek <pavel@xxxxxx>
• Re: Squashfs performance (3.3 vs 4.0 in mainline)
  • From: Phillip Lougher <phillip.lougher@xxxxxxxxx>
• [PATCH V2 8/8] lzma: make lzma reentrant
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH V2 5/8] Squashfs: add support for LZMA compressed filesystems
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH V2 2/8] Squashfs: Factor out remaining zlib dependencies into separate wrapper file
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH V2 0/9] Squashfs: Add support for LZMA compressed filesystems
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH V2 4/8] Squashfs: add decompressor entries for lzma and lzo
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH V2 6/8] lzma: Make lzma available to non initramfs/initrd code
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH V2 7/8] Squashfs: select DECOMPRESS_LZMA_NEEDED when including support for lzma
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH V2 1/8] Squashfs: move zlib decompression wrapper code into a separate file
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH V2 3/8] Squashfs: add a decompressor framework
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file
  • From: Felix Fietkau <nbd@xxxxxxxxxxx>
• Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Squashfs performance (3.3 vs 4.0 in mainline)
  • From: Simon Kagstrom <simon.kagstrom@xxxxxxxxxxxxxx>
• Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file
  • From: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
• Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file
  • From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
• Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/9] Squashfs: Add support for LZMA compressed filesystems
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Brian Swetland <swetland@xxxxxxxxxx>
• Re: [PATCH 2/9] Squashfs: Factor out remaining zlib dependencies into separate wrapper file
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• RE: [POWER] battery calibration parameters from sysfs
  • From: "Linus Walleij" <linus.walleij@xxxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [PATCH 07/9] lzma: Make lzma available to non initramfs/initrd code
  • From: root <root@xxxxxxxxxxxxxxxxxxx>
• [PATCH 6/9] Squashfs: add support for LZMA compressed filesystems
  • From: root <root@xxxxxxxxxxxxxxxxxxx>
• [PATCH 3/9] Squashfs: add a decompressor framework
  • From: root <root@xxxxxxxxxxxxxxxxxxx>
• [PATCH 8/9] Squashfs: select DECOMPRESS_LZMA_NEEDED when including support for lzma
  • From: root <root@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/9] Squashfs: Add support for LZMA compressed filesystems
  • From: Peter Korsgaard <jacmet@xxxxxxxxxx>
• [PATCH 5/9] Squashfs: make decompressor init function pass superblock info
  • From: root <root@xxxxxxxxxxxxxxxxxxx>
• [PATCH 8/9] Squashfs: select DECOMPRESS_LZMA_NEEDED when including support for lzma
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 07/9] lzma: Make lzma available to non initramfs/initrd code
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 6/9] Squashfs: add support for LZMA compressed filesystems
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 0/9] Squashfs: Add support for LZMA compressed filesystems
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 3/9] Squashfs: add a decompressor framework
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 5/9] Squashfs: make decompressor init function pass superblock info
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 9/9] lzma: make lzma reentrant
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 2/9] Squashfs: Factor out remaining zlib dependencies into separate wrapper file
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4/9] Squashfs: add decompressor entries for lzma and lzo
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file
  • From: Phillip Lougher <phillip@xxxxxxxxxxxxxxxxxxx>
• [PATCH 2/9] Squashfs: Factor out remaining zlib dependencies into separate wrapper file
  • From: root <root@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4/9] Squashfs: add decompressor entries for lzma and lzo
  • From: root <root@xxxxxxxxxxxxxxxxxxx>
• [PATCH 0/9] Squashfs: Add support for LZMA compressed filesystems
  • From: root <root@xxxxxxxxxxxxxxxxxxx>
• [PATCH 9/9] lzma: make lzma reentrant
  • From: root <root@xxxxxxxxxxxxxxxxxxx>
• [PATCH 1/9] Squashfs: move zlib decompression wrapper code into a separate file
  • From: root <root@xxxxxxxxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Greg KH <greg@xxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• RE: [POWER] battery calibration parameters from sysfs
  • From: "Linus Walleij" <linus.walleij@xxxxxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Kyungmin Park <kmpark@xxxxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Kyungmin Park <kmpark@xxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Alexander Clouter <alex@xxxxxxxxxxxxx>
• Re: [POWER] battery calibration parameters from sysfs
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• [POWER] battery calibration parameters from sysfs
  • From: "Linus Walleij" <linus.walleij@xxxxxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Aras Vaichas <arasv@xxxxxxxxxxxxxxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Josh Boyer <jwboyer@xxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Kyungmin Park <kmpark@xxxxxxxxxxxxx>
• Badness at net/sched/sch_generic.c:219
  • From: ladislav klenovic <lklenovic@xxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Wolfgang Denk <wd@xxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Aras Vaichas <arasv@xxxxxxxxxxxxxxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [ANNOUNCE] CELF open project proposal
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• [ANNOUNCE] CELF open project proposal
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: David Brownell <david-b@xxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: David Brownell <david-b@xxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: David Brownell <david-b@xxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: David Brownell <david-b@xxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Albrecht Dreß <albrecht.dress@xxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
  • From: Brian Gerst <brgerst@xxxxxxxxx>
• Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
  • From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
• Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
  • From: Jiri Slaby <jirislaby@xxxxxxxxx>
• Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
  • From: Américo Wang <xiyou.wangcong@xxxxxxxxx>
• Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
  • From: stas <stas@xxxxxxxxxxxxx>
• Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
  • From: Viral Mehta <viral.mehta@xxxxxxxxxxxxxx>
• Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
  • From: Viral Mehta <viral.mehta@xxxxxxxxxxxxxx>
• How to move two valuables to x86 CPU register ebx, ecx by using AT&A inline asm.
  • From: Johnny Hung <johnny.hacking@xxxxxxxxx>
• Re: [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Aras Vaichas <arasv@xxxxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Américo Wang <xiyou.wangcong@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: David Brownell <david-b@xxxxxxxxxxx>
• Re: [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
• Re: [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: David Brownell <david-b@xxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: David Brownell <david-b@xxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: David Brownell <david-b@xxxxxxxxxxx>
• [Proposal] [PATCH] [RESEND] generic clock framework
  • From: Francesco VIRLINZI <francesco.virlinzi@xxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Re: [PATCH 0/6] Generic PWM API implementation
  • From: Grant Likely <grant.likely@xxxxxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Simon Kagstrom <simon.kagstrom@xxxxxxxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: "Shargorodsky Atal (EXT-Teleca/Helsinki)" <ext-atal.shargorodsky@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Artem Bityutskiy <dedekind1@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Simon Kagstrom <simon.kagstrom@xxxxxxxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Matt Mackall <mpm@xxxxxxxxxxx>
• Re: [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: Marco Stornelli <marco.stornelli@xxxxxxxxx>
• [PATCH, RFC] panic-note: Annotation from user space for panics
  • From: David VomLehn <dvomlehn@xxxxxxxxx>
• Re: [Proposal] [PATCH] generic clock framework
  • From: Francesco VIRLINZI <francesco.virlinzi@xxxxxx>
• New Micron e-MMC support...
  • From: "CYR Burt" <Burt.Cyr@xxxxxxxxxxxxxxxxxx>
• Re: [Proposal] [PATCH] generic clock framework
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• [Proposal] [PATCH] generic clock framework
  • From: Francesco VIRLINZI <francesco.virlinzi@xxxxxx>
• [ANNOUNCE] ELC 2010 Call for Presentations
  • From: Tim Bird <tim.bird@xxxxxxxxxxx>
• Re: [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load
  • From: Trilok Soni <soni.trilok@xxxxxxxxx>
• Re: [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load
  • From: Trilok Soni <soni.trilok@xxxxxxxxx>
• [ANNOUNCE] New mailing list for u-boot-v2
  • From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
• Re: [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load
  • From: Luotao Fu <l.fu@xxxxxxxxxxxxxx>
• Re: How to create a git repo on git.kernel.org?
  • From: "George G. Davis" <gdavis@xxxxxxxxxx>
• Re: [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Re: [[RFC] 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [[RFC] 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: [[RFC] 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Re: [[RFC] 5/5] Incorporate PWM API code into KBuild
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Re: [[RFC] 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Re: [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Re: [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load
  • From: Mike Frysinger <vapier.adi@xxxxxxxxx>
• Re: How to create a git repo on git.kernel.org?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• Re: How to create a git repo on git.kernel.org?
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• How to create a git repo on git.kernel.org?
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [[RFC] 0/5] Generic PWM API Proposal
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [[RFC] 5/5] Incorporate PWM API code into KBuild
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [[RFC] 1/5] API to consolidate PWM devices behind a common user and kernel interface
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [[RFC] 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
• [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load
  • From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>