1. 21 6月, 2012 1 次提交
  2. 16 6月, 2012 12 次提交
  3. 15 6月, 2012 3 次提交
  4. 14 6月, 2012 17 次提交
    • A
      Fix OMAP EHCI suspend/resume failure (i693) · 354ab856
      Anand Gadiyar 提交于
      Its observed with some PHY, the 60Mhz clock gets
      cut too soon for OMAP EHCI, leaving OMAP-EHCI in a bad state.
      
      So on starting port suspend, make sure the 60Mhz clock to EHCI
      is kept alive using an internal clock, so that EHCi can cleanly
      transition its hw state machine on a port suspend.
      
      Its not proven if this is the issue hit on USB3333,
      but the symptoms look very similar.
      Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
      Signed-off-by: NVikram Pandita <vikram.pandita@ti.com>
      Signed-off-by: NVolodymyr Mieshkov <x0182794@ti.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      354ab856
    • R
      USB: ohci-hub: Mark ohci_finish_controller_resume() as __maybe_unused · c4828d96
      Roland Stigge 提交于
      ohci_finish_controller_resume() is intended to be used in platform specific
      drivers ohci-*.c, included from ohci-hcd.c. Some of them don't actually use
      ohci_finish_controller_resume(), so mark it as __maybe_unused.
      Signed-off-by: NRoland Stigge <stigge@antcom.de>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c4828d96
    • J
      usb: use usb_serial_put in usb_serial_probe errors · 0658a336
      Jan Safrata 提交于
      The use of kfree(serial) in error cases of usb_serial_probe
      was invalid - usb_serial structure allocated in create_serial()
      gets reference of usb_device that needs to be put, so we need
      to use usb_serial_put() instead of simple kfree().
      Signed-off-by: NJan Safrata <jan.nikitenko@gmail.com>
      Acked-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0658a336
    • H
      USB: EHCI: Fix build warning in xilinx ehci driver · 07828b10
      Herton Ronaldo Krzesinski 提交于
      This fixes the following warning:
      In file included from drivers/usb/host/ehci-hcd.c:1246:0:
      drivers/usb/host/ehci-xilinx-of.c:293:2: warning: initialization from incompatible pointer type [enabled by default]
      drivers/usb/host/ehci-xilinx-of.c:293:2: warning: (near initialization for 'ehci_hcd_xilinx_of_driver.shutdown') [enabled by default]
      Signed-off-by: NHerton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07828b10
    • R
      USB: fix PS3 EHCI systems · 4f7a67e2
      Ricardo Martins 提交于
      After commit aaa0ef28 "PS3 EHCI QH
      read work-around", Terratec Grabby (em28xx) stopped working with AMD
      Geode LX 800 (USB controller AMD CS5536). Since this is a PS3 only
      fix, the following patch adds a conditional block around it.
      Signed-off-by: NRicardo Martins <rasm@fe.up.pt>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4f7a67e2
    • A
      xHCI: Increase the timeout for controller save/restore state operation · 622eb783
      Andiry Xu 提交于
      When system software decides to power down the xHC with the intent of
      resuming operation at a later time, it will ask xHC to save the internal
      state and restore it when resume to correctly recover from a power event.
      Two bits are used to enable this operation: Save State and Restore State.
      
      xHCI spec 4.23.2 says software should "Set the Controller Save/Restore
      State flag in the USBCMD register and wait for the Save/Restore State
      Status flag in the USBSTS register to transition to '0'". However, it does
      not define how long software should wait for the SSS/RSS bit to transition
      to 0.
      
      Currently the timeout is set to 1ms. There is bug report
      (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1002697)
      indicates that the timeout is too short for ASMedia ASM1042 host controller
      to save/restore the state successfully. Increase the timeout to 10ms helps to
      resolve the issue.
      
      This patch should be backported to stable kernels as old as 2.6.37, that
      contain the commit 5535b1d5 "USB: xHCI:
      PCI power management implementation"
      Signed-off-by: NAndiry Xu <andiry.xu@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: stable@vger.kernel.org
      622eb783
    • T
      xhci: Don't free endpoints in xhci_mem_cleanup() · 32f1d2c5
      Takashi Iwai 提交于
      This patch fixes a few issues introduced in the recent fix
      [f8a9e72d: USB: fix resource leak in xhci power loss path]
      
      - The endpoints listed in bw table are just links and each entry is an
       array member of dev->eps[].  But the commit above adds a kfree() call
       to these instances, and thus it results in memory corruption.
      
      - It clears only the first entry of rh_bw[], but there can be multiple
        ports.
      
      - It'd be safer to clear the list_head of ep as well, not only
        removing from the list, as it's checked in
        xhci_discover_or_reset_device().
      
      This patch should be backported to kernels as old as 3.2, that contain
      the commit 839c817c "xhci: Store
      information about roothubs and TTs."
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reviewed-by: NOliver Neukum <oneukum@suse.de>
      Cc: <stable@vger.kernel.org>
      32f1d2c5
    • T
      xhci: Fix invalid loop check in xhci_free_tt_info() · 46ed8f00
      Takashi Iwai 提交于
      xhci_free_tt_info() may access the invalid memory when it removes the
      last entry but the list is not empty.  Then tt_next reaches to the
      list head but it still tries to check the tt_info of that entry.
      
      This patch fixes the bug and cleans up the messy code by rewriting
      with a simple list_for_each_entry_safe().
      
      This patch should be backported to kernels as old as 3.2, that contain
      the commit 839c817c "xhci: Store
      information about roothubs and TTs."
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reviewed-by: NOliver Neukum <oneukum@suse.de>
      Cc: <stable@vger.kernel.org>
      46ed8f00
    • S
      xhci: Fix error path return value. · e25e62ae
      Sarah Sharp 提交于
      This patch fixes an issue discovered by Dan Carpenter:
      
      The patch 3b3db026: "xhci: Add infrastructure for host-specific
      LPM policies." from May 9, 2012, leads to the following warning:
      drivers/usb/host/xhci.c:3909 xhci_get_timeout_no_hub_lpm()
               warn: signedness bug returning '-22'
      
        3906          default:
        3907                  dev_warn(&udev->dev, "%s: Can't get timeout for non-U1 or U2 state.\n",
        3908                                  __func__);
        3909                  return -EINVAL;
                              ^^^^^^^^^^^^^^
      This should be a u16 like USB3_LPM_DISABLED or something.
      
        3910          }
        3911
        3912          if (sel <= max_sel_pel && pel <= max_sel_pel)
        3913                  return USB3_LPM_DEVICE_INITIATED;
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      e25e62ae
    • D
      USB: Checking the wrong variable in usb_disable_lpm() · 55558c33
      Dan Carpenter 提交于
      We check "u1_params" instead of checking "u2_params".
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      55558c33
    • H
      usb-storage: Add 090c:1000 to unusal-devs · afff07e6
      Hans de Goede 提交于
      This device gives a bogus answer to get_capacity(16):
      [ 8628.278614] scsi 8:0:0:0: Direct-Access     USB 2.0  USB Flash Drive  1100 PQ: 0 ANSI: 4
      [ 8628.279452] sd 8:0:0:0: Attached scsi generic sg4 type 0
      [ 8628.280338] sd 8:0:0:0: [sdd] 35747322042253313 512-byte logical blocks: (18.3 EB/15.8 EiB)
      
      So set the quirk flag to avoid using get_capacity(16) with it:
      [11731.386014] usb-storage 2-1.6:1.0: Quirks match for vid 090c pid 1000: 80000
      [11731.386075] scsi9 : usb-storage 2-1.6:1.0
      [11731.386172] usbcore: registered new interface driver usb-storage
      [11731.386175] USB Mass Storage support registered.
      [11732.387394] scsi 9:0:0:0: Direct-Access     USB 2.0  USB Flash Drive  1100 PQ: 0 ANSI: 4
      [11732.388462] sd 9:0:0:0: Attached scsi generic sg3 type 0
      [11732.389432] sd 9:0:0:0: [sdc] 7975296 512-byte logical blocks: (4.08 GB/3.80 GiB)
      
      Which makes the capacity look a lot more sane :)
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Tested-by: NSimon Raffeiner <sturmflut@lieberbiber.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afff07e6
    • E
      bnx2x: fix checksum validation · d6cb3e41
      Eric Dumazet 提交于
      bnx2x driver incorrectly sets ip_summed to CHECKSUM_UNNECESSARY on
      encapsulated segments. TCP stack happily accepts frames with bad
      checksums, if they are inside a GRE or IPIP encapsulation.
      
      Our understanding is that if no IP or L4 csum validation was done by the
      hardware, we should leave ip_summed as is (CHECKSUM_NONE), since
      hardware doesn't provide CHECKSUM_COMPLETE support in its cqe.
      
      Then, if IP/L4 checksumming was done by the hardware, set
      CHECKSUM_UNNECESSARY if no error was flagged.
      
      Patch based on findings and analysis from Robert Evans
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Eilon Greenstein <eilong@broadcom.com>
      Cc: Yaniv Rosner <yanivr@broadcom.com>
      Cc: Merav Sicron <meravs@broadcom.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Robert Evans <evansr@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Acked-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d6cb3e41
    • A
      USB: serial-generic: use a single set of device IDs · 0b84704a
      Alan Stern 提交于
      The usb-serial-generic driver uses different device IDs for its USB
      matching and its serial matching.  This can lead to problems: The
      driver can end up getting bound to a USB interface without being
      allowed to bind to the corresponding serial port.
      
      This patch (as1557) fixes the problem by using the same device ID
      table (the one that can be altered by the "vendor=" and "product="
      module parameters) for both purposes.  The unused table is removed.
      Now the driver will bind only to the intended devices.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      CC: Bjørn Mork <bjorn@mork.no>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0b84704a
    • B
      USB: serial: Enforce USB driver and USB serial driver match · 954c3f8a
      Bjørn Mork 提交于
      We need to make sure that the USB serial driver we find
      matches the USB driver whose probe we are currently
      executing. Otherwise we will end up with USB serial
      devices bound to the correct serial driver but wrong
      USB driver.
      
      An example of such cross-probing, where the usbserial_generic
      USB driver has found the sierra serial driver:
      
      May 29 18:26:15 nemi kernel: [ 4442.559246] usbserial_generic 4-4:1.0: Sierra USB modem converter detected
      May 29 18:26:20 nemi kernel: [ 4447.556747] usbserial_generic 4-4:1.2: Sierra USB modem converter detected
      May 29 18:26:25 nemi kernel: [ 4452.557288] usbserial_generic 4-4:1.3: Sierra USB modem converter detected
      
      sysfs view of the same problem:
      
      bjorn@nemi:~$ ls -l /sys/bus/usb/drivers/sierra/
      total 0
      --w------- 1 root root 4096 May 29 18:23 bind
      lrwxrwxrwx 1 root root    0 May 29 18:23 module -> ../../../../module/usbserial
      --w------- 1 root root 4096 May 29 18:23 uevent
      --w------- 1 root root 4096 May 29 18:23 unbind
      bjorn@nemi:~$ ls -l /sys/bus/usb-serial/drivers/sierra/
      total 0
      --w------- 1 root root 4096 May 29 18:23 bind
      lrwxrwxrwx 1 root root    0 May 29 18:23 module -> ../../../../module/sierra
      -rw-r--r-- 1 root root 4096 May 29 18:23 new_id
      lrwxrwxrwx 1 root root    0 May 29 18:32 ttyUSB0 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.0/ttyUSB0
      lrwxrwxrwx 1 root root    0 May 29 18:32 ttyUSB1 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.2/ttyUSB1
      lrwxrwxrwx 1 root root    0 May 29 18:32 ttyUSB2 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.3/ttyUSB2
      --w------- 1 root root 4096 May 29 18:23 uevent
      --w------- 1 root root 4096 May 29 18:23 unbind
      
      bjorn@nemi:~$ ls -l /sys/bus/usb/drivers/usbserial_generic/
      total 0
      lrwxrwxrwx 1 root root    0 May 29 18:33 4-4:1.0 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.0
      lrwxrwxrwx 1 root root    0 May 29 18:33 4-4:1.2 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.2
      lrwxrwxrwx 1 root root    0 May 29 18:33 4-4:1.3 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb4/4-4/4-4:1.3
      --w------- 1 root root 4096 May 29 18:33 bind
      lrwxrwxrwx 1 root root    0 May 29 18:33 module -> ../../../../module/usbserial
      --w------- 1 root root 4096 May 29 18:22 uevent
      --w------- 1 root root 4096 May 29 18:33 unbind
      bjorn@nemi:~$ ls -l /sys/bus/usb-serial/drivers/generic/
      total 0
      --w------- 1 root root 4096 May 29 18:33 bind
      lrwxrwxrwx 1 root root    0 May 29 18:33 module -> ../../../../module/usbserial
      -rw-r--r-- 1 root root 4096 May 29 18:33 new_id
      --w------- 1 root root 4096 May 29 18:22 uevent
      --w------- 1 root root 4096 May 29 18:33 unbind
      
      So we end up with a mismatch between the USB driver and the
      USB serial driver.  The reason for the above is simple: The
      USB driver probe will succeed if *any* registered serial
      driver matches, and will use that serial driver for all
      serial driver functions.
      
      This makes ref counting go wrong. We count the USB driver
      as used, but not the USB serial driver.  This may result
      in Oops'es as demonstrated by Johan Hovold <jhovold@gmail.com>:
      
      [11811.646396] drivers/usb/serial/usb-serial.c: get_free_serial 1
      [11811.646443] drivers/usb/serial/usb-serial.c: get_free_serial - minor base = 0
      [11811.646460] drivers/usb/serial/usb-serial.c: usb_serial_probe - registering ttyUSB0
      [11811.646766] usb 6-1: pl2303 converter now attached to ttyUSB0
      [11812.264197] USB Serial deregistering driver FTDI USB Serial Device
      [11812.264865] usbcore: deregistering interface driver ftdi_sio
      [11812.282180] USB Serial deregistering driver pl2303
      [11812.283141] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
      [11812.283272] usbcore: deregistering interface driver pl2303
      [11812.301056] USB Serial deregistering driver generic
      [11812.301186] usbcore: deregistering interface driver usbserial_generic
      [11812.301259] drivers/usb/serial/usb-serial.c: usb_serial_disconnect
      [11812.301823] BUG: unable to handle kernel paging request at f8e7438c
      [11812.301845] IP: [<f8e38445>] usb_serial_disconnect+0xb5/0x100 [usbserial]
      [11812.301871] *pde = 357ef067 *pte = 00000000
      [11812.301957] Oops: 0000 [#1] PREEMPT SMP
      [11812.301983] Modules linked in: usbserial(-) [last unloaded: pl2303]
      [11812.302008]
      [11812.302019] Pid: 1323, comm: modprobe Tainted: G        W    3.4.0-rc7+ #101 Dell Inc. Vostro 1520/0T816J
      [11812.302115] EIP: 0060:[<f8e38445>] EFLAGS: 00010246 CPU: 1
      [11812.302130] EIP is at usb_serial_disconnect+0xb5/0x100 [usbserial]
      [11812.302141] EAX: f508a180 EBX: f508a180 ECX: 00000000 EDX: f8e74300
      [11812.302151] ESI: f5050800 EDI: 00000001 EBP: f5141e78 ESP: f5141e58
      [11812.302160]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [11812.302170] CR0: 8005003b CR2: f8e7438c CR3: 34848000 CR4: 000007d0
      [11812.302180] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [11812.302189] DR6: ffff0ff0 DR7: 00000400
      [11812.302199] Process modprobe (pid: 1323, ti=f5140000 task=f61e2bc0 task.ti=f5140000)
      [11812.302209] Stack:
      [11812.302216]  f8e3be0f f8e3b29c f8e3ae00 00000000 f513641c f5136400 f513641c f507a540
      [11812.302325]  f5141e98 c133d2c1 00000000 00000000 f509c400 f513641c f507a590 f5136450
      [11812.302372]  f5141ea8 c12f0344 f513641c f507a590 f5141ebc c12f0c67 00000000 f507a590
      [11812.302419] Call Trace:
      [11812.302439]  [<c133d2c1>] usb_unbind_interface+0x51/0x190
      [11812.302456]  [<c12f0344>] __device_release_driver+0x64/0xb0
      [11812.302469]  [<c12f0c67>] driver_detach+0x97/0xa0
      [11812.302483]  [<c12f001c>] bus_remove_driver+0x6c/0xe0
      [11812.302500]  [<c145938d>] ? __mutex_unlock_slowpath+0xcd/0x140
      [11812.302514]  [<c12f0ff9>] driver_unregister+0x49/0x80
      [11812.302528]  [<c1457df6>] ? printk+0x1d/0x1f
      [11812.302540]  [<c133c50d>] usb_deregister+0x5d/0xb0
      [11812.302557]  [<f8e37c55>] ? usb_serial_deregister+0x45/0x50 [usbserial]
      [11812.302575]  [<f8e37c8d>] usb_serial_deregister_drivers+0x2d/0x40 [usbserial]
      [11812.302593]  [<f8e3a6e2>] usb_serial_generic_deregister+0x12/0x20 [usbserial]
      [11812.302611]  [<f8e3acf0>] usb_serial_exit+0x8/0x32 [usbserial]
      [11812.302716]  [<c1080b48>] sys_delete_module+0x158/0x260
      [11812.302730]  [<c110594e>] ? mntput+0x1e/0x30
      [11812.302746]  [<c145c3c3>] ? sysenter_exit+0xf/0x18
      [11812.302746]  [<c107777c>] ? trace_hardirqs_on_caller+0xec/0x170
      [11812.302746]  [<c145c390>] sysenter_do_call+0x12/0x36
      [11812.302746] Code: 24 02 00 00 e8 dd f3 20 c8 f6 86 74 02 00 00 02 74 b4 8d 86 4c 02 00 00 47 e8 78 55 4b c8 0f b6 43 0e 39 f8 7f a9 8b 53 04 89 d8 <ff> 92 8c 00 00 00 89 d8 e8 0e ff ff ff 8b 45 f0 c7 44 24 04 2f
      [11812.302746] EIP: [<f8e38445>] usb_serial_disconnect+0xb5/0x100 [usbserial] SS:ESP 0068:f5141e58
      [11812.302746] CR2: 00000000f8e7438c
      
      Fix by only evaluating serial drivers pointing back to the
      USB driver we are currently probing.  This still allows two
      or more drivers to match the same device, running their
      serial driver probes to sort out which one to use.
      
      Cc: stable@vger.kernel.org # 3.0, 3.2, 3.3, 3.4
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Tested-by: NJohan Hovold <jhovold@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      954c3f8a
    • A
      USB: add NO_D3_DURING_SLEEP flag and revert 151b6128 · c2fb8a3f
      Alan Stern 提交于
      This patch (as1558) fixes a problem affecting several ASUS computers:
      The machine crashes or corrupts memory when going into suspend if the
      ehci-hcd driver is bound to any controllers.  Users have been forced
      to unbind or unload ehci-hcd before putting their systems to sleep.
      
      After extensive testing, it was determined that the machines don't
      like going into suspend when any EHCI controllers are in the PCI D3
      power state.  Presumably this is a firmware bug, but there's nothing
      we can do about it except to avoid putting the controllers in D3
      during system sleep.
      
      The patch adds a new flag to indicate whether the problem is present,
      and avoids changing the controller's power state if the flag is set.
      Runtime suspend is unaffected; this matters only for system suspend.
      However as a side effect, the controller will not respond to remote
      wakeup requests while the system is asleep.  Hence USB wakeup is not
      functional -- but of course, this is already true in the current state
      of affairs.
      
      A similar patch has already been applied as commit
      151b6128 (USB: EHCI: fix crash during
      suspend on ASUS computers).  The patch supersedes that one and reverts
      it.  There are two differences:
      
      	The old patch added the flag at the USB level; this patch
      	adds it at the PCI level.
      
      	The old patch applied to all chipsets with the same vendor,
      	subsystem vendor, and product IDs; this patch makes an
      	exception for a known-good system (based on DMI information).
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NDâniel Fraga <fragabr@gmail.com>
      Tested-by: NAndrey Rahmatullin <wrar@wrar.name>
      Tested-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: stable <stable@vger.kernel.org>
      Reviewed-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2fb8a3f
    • J
      video: s3c-fb: fix possible division by zero in s3c_fb_calc_pixclk · b6798951
      Jingoo Han 提交于
      Divider value can be zero and it makes division by zero
      from debug message in s3c_fb_calc_pixclk; therefore, it
      should be fixed.
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      b6798951
    • J
      video: s3c-fb: clear SHADOWCON register when clearing hardware window registers · ecd57ae2
      Jingoo Han 提交于
      All bits of SHADOWCON register should be cleared when clearing
      hardware window registers; however, some bits of SHADOWCON register
      are not cleared previously.
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      ecd57ae2
  5. 13 6月, 2012 7 次提交