29 Jan, 2016

1 commit

  • On new virtual devices, the goldfish virtual bus can be replaced with
    autoprobing infrastructure like Device Tree. Refactor the goldfish
    kernel configs to better accommodate this.

    Move the goldfish platform into a menuconfig in the style of the chrome
    platform, and separate the goldfish bus into its own config option.

    Signed-off-by: Greg Hackmann
    Signed-off-by: Jin Qian
    [Corrected a tristate to bool]
    Signed-off-by: Alan Cox
    Signed-off-by: Greg Kroah-Hartman

    Greg Hackmann
     

01 Apr, 2015

1 commit


21 Nov, 2013

1 commit

  • It makes sense to split out the Chromebook/Chromebox hardware platform
    drivers to a separate subdirectory, since some of it will be shared
    between ARM and x86.

    This moves over the existing chromeos_laptop driver without making
    any other changes, and adds appropriate Kconfig entries for the new
    directory. It also adds a MAINTAINERS entry for the new subdir.

    Signed-off-by: Olof Johansson
    Signed-off-by: Matthew Garrett

    Olof Johansson
     

25 Jan, 2013

1 commit

  • A QEMU pipe is a very fast communication channel between the
    guest system and the emulator. Usage from the guest is simply
    something like;

    // connect to special device
    fd = open("/dev/qemu_pipe", O_RDWR);

    // tell which service we want to talk to (must be zero-terminated)
    write(fd, "pipeName", strlen("pipeName")+1);

    // do read()/write() through fd now
    ...

    // close channel
    close(fd);

    Signed-off-by: David 'Digit' Turner
    [Added support for parameter buffers for speed]
    igned-off-by: Xin, Xiaohui
    Signed-off-by: Jiang, Yunhong
    Signed-off-by: Nakajima, Jun
    [Ported to 3.6]
    Signed-off-by: Tom Keel
    [Ported to 3.7, moved to platform/goldfish]
    Signed-off-by: Alan Cox
    Signed-off-by: Greg Kroah-Hartman

    David 'Digit' Turner
     

09 Nov, 2009

1 commit


19 Dec, 2008

1 commit

  • Move x86 platform specific drivers from drivers/misc/
    to a new home under drivers/platform/x86/.

    The community has been maintaining x86 vendor-specific
    platform specific drivers under /drivers/misc/ for a few years.
    The oldest ones started life under drivers/acpi.
    They moved out of drivers/acpi/ because they don't actually
    implement the ACPI specification, but either simply
    use ACPI, or implement vendor-specific ACPI extensions.

    In the future we anticipate...
    drivers/misc/ will go away.
    other architectures will create drivers/platform/

    Signed-off-by: Len Brown

    Len Brown