Add machine support code for the Freescale IMX50 SoC.
The IMX50 is quite similar to the Freescale IMX53, and contains many of the
same periperhal hardware modules, at the same address offsets as the IMX53.
(Notable exceptions are that the IMX50 contains no CAN bus hardware, less
GPIO, no VPU, it does contain an Electrophoretic display controller though).
This support code uses some of the IMX53 setup code to reduce duplication
of what would be identical init IO setup.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The code for irq priorisation support doesn't have any in-tree users and
the Kconfig description does wrong promises because nowadays irq
handlers are called with irqs disabled, so no high prioritized irq can
interrupt a lower prioritized handler.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Today, imx53 handles iomux configuration using pinctrl driver, so
mxc_iomux_v3_init() call in imx53_init_early() is there for nothing.
Remove the call from there.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Allow the Freescale IMX50 SoC support code to be configured on.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Add code to support the specific clock tree of the Freescale IMX50 SoC.
It can use much of the common IMX51/IMX53 clocking code.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Add appropriate UART address definitions and support defines for using the
UARTs of the Freescale IMX50 SoC as debug ports.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The eukrea mbimxsd25 has a gpio regulator for enabling its
LCD display, it also has a gpio button.
We enable the respective drivers in order to be able to use theses
features with this configuration.
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Denis Carikli <denis@eukrea.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The PEX860X has GPIO's which are used for PCI Reset lines on the
Gateworks Ventana boards. The GPIO's need to be set as output
level high so as to allow the PCIe devices to come out of reset.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Here is a single n_tty fix for 3.13-rc3 that resolves a regression in 3.12 that
has been reported.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlKiFdwACgkQMUfUDdst+yn9mwCgzPY2TXNpr35x2TzdsrbpRQBJ
dcAAn2Ou/sVNbROaafILhu7n0gHToZI4
=LXUl
-----END PGP SIGNATURE-----
Merge tag 'tty-3.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty fix from Greg KH:
"Here is a single n_tty fix for 3.13-rc3 that resolves a regression in
3.12 that has been reported"
* tag 'tty-3.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
n_tty: Fix missing newline echo
Here are some bugfixes for the staging and IIO drivers for 3.13-rc3.
The resolve the vm memory issue in the tidspbridge driver, fix a much-reported
build failure in an ARM driver, and some other IIO bugfixes that have been
reported.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlKiFYcACgkQMUfUDdst+ykuUgCcCqLrTpaBhOfFaLhSUONJh0Db
BfYAoMFoyviPqclR7NYouZT6mUehiJ7+
=X5WP
-----END PGP SIGNATURE-----
Merge tag 'staging-3.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fixes from Greg KH:
"Here are some bugfixes for the staging and IIO drivers for 3.13-rc3.
The resolve the vm memory issue in the tidspbridge driver, fix a
much-reported build failure in an ARM driver, and some other IIO
bugfixes that have been reported"
* tag 'staging-3.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
Staging: TIDSPBRIDGE: Use vm_iomap_memory for mmap-ing instead of remap_pfn_range
Fix build failure for gp2ap020a00f.c
iio: hid-sensors: Fix power and report state
HID: hid-sensor-hub: Add logical min and max
Nothing huge, just a few small bugfixes for problems reported, and a device id
update.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlKiE8QACgkQMUfUDdst+yl9dQCgwXrgSRyBlULDHOdBnKblqrMq
gYQAoLVKfuEOXRXBJOD4CzNeCMLButsM
=HbWB
-----END PGP SIGNATURE-----
Merge tag 'char-misc-3.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Nothing huge, just a few small bugfixes for problems reported, and a
device id update"
* tag 'char-misc-3.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
mei: add 9 series PCH mei device ids
drivers/char/i8k.c: add Dell XPLS L421X
MAINTAINERS: add HSI subsystem
misc: mic: Suppress memory space sparse warnings
misc: mic: Fix endianness issues.
misc: mic: Fix user space namespace pollution from mic_common.h.
misc: mic: Bug fix for sysfs poll usage.
misc: mic: Minor bug fix in 'retry' loops.
misc: mic: Change mic_notify(...) to return true.
extcon: remove freed groups caused the panic or warning in unregister flow
extcon: arizona: Get pdata from arizona structure not device
Here are a bunch of USB fixes for 3.13-rc3.
Nothing major, but we seem to have an argument about a XHCI fix, so I'm not
including a revert that Sarah requested, because that breaks a USB network
driver, and I can't revert the USB network driver fix without reintroducing
other bugs that it fixed. So as it is, everything should now be
working. Worse case, I can revert the XHCI fix before 3.13-final is
out, but it seems to work well here with my testing, so all should be
good.
Other than that, some driver updates based on reports.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlKiEuYACgkQMUfUDdst+ymE8ACgnDT8s4FtrYfoyOo5K4TVTRaZ
S2wAn3+Xa2TX1Sym+ltJry7N1jRnY2Qy
=JUaB
-----END PGP SIGNATURE-----
Merge tag 'usb-3.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are a bunch of USB fixes for 3.13-rc3.
Nothing major, but we seem to have an argument about a XHCI fix, so
I'm not including a revert that Sarah requested, because that breaks a
USB network driver, and I can't revert the USB network driver fix
without reintroducing other bugs that it fixed. So as it is,
everything should now be working. Worse case, I can revert the XHCI
fix before 3.13-final is out, but it seems to work well here with my
testing, so all should be good.
Other than that, some driver updates based on reports"
* tag 'usb-3.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (40 commits)
usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED
usb: ohci-pxa27x: include linux/dma-mapping.h
USB: cdc-acm: Added support for the Lenovo RD02-D400 USB Modem
usb: tools: fix a regression issue that gcc can't link to pthread
USB: switch maintainership of chipidea to Peter
USB: pl2303: fixed handling of CS5 setting
USB: ftdi_sio: fixed handling of unsupported CSIZE setting
USB: mos7840: correct handling of CS5 setting
USB: spcp8x5: correct handling of CS5 setting
usb: wusbcore: fix deadlock in wusbhc_gtk_rekey
usb: wusbcore: do device lookup while holding the hc mutex
usb: wusbcore: send keepalives to unauthenticated devices
USB: option: support new huawei devices
USB: serial: option: blacklist interface 1 for Huawei E173s-6
usb: xhci: Link TRB must not occur within a USB payload burst
usb: gadget: f_mass_storage: call try_to_freeze only when its safe
usb: gadget: tcm_usb_gadget: mark bot_cleanup_old_alt static
usb: gadget: ffs: fix sparse warning
usb: gadget: zero: module parameters can be static
usb: gadget: storage: fix sparse warning
...
We call put_device() in the error path, which is fine for dev==NULL.
However, in case kobject_set_name_vargs() fails, we have dev!=NULL but
device_initialized() wasn't called, yet.
Fix this by splitting device_register() into explicit calls to
device_add() and an early call to device_initialize().
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With CONFIG_DEBUG_KOBJECT_RELEASE=y, removing and immediately reloading the
dmi-sysfs module causes the following warning:
sysfs: cannot create duplicate filename '/firmware/dmi'
kobject_add_internal failed for dmi with -EEXIST, don't try to register things with the same name in the same directory.
The "dmi" directory stays in sysfs until the dmi_kobj is released, and
DEBUG_KOBJECT_RELEASE delays that.
I don't think we can hit this problem in normal usage because dmi_kobj is
static and nothing outside dmi-sysfs can get a reference to it, so the
only way to delay the "dmi" release is with DEBUG_KOBJECT_RELEASE.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Removing the dmi-sysfs module causes the following warning:
# modprobe -r dmi_sysfs
WARNING: CPU: 11 PID: 6785 at fs/sysfs/inode.c:325 sysfs_hash_and_remove+0xa9/0xb0()
sysfs: can not remove 'raw', no directory
This is because putting the entry kobject, e.g., for
"/sys/firmware/dmi/entries/19-0", removes the directory and all its
contents. By the time dmi_sysfs_entry_release() runs, the "raw" file
inside ".../19-0/" has already been removed.
Therefore, we don't need to remove the "raw" bin file at all in
dmi_sysfs_entry_release().
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The commit [3e358ac2bb: firmware: Be a bit more verbose about direct
firmware loading failure] introduced a new warning message about
falling back to user helper, but this isn't true when
CONFIG_FW_LOADER_USER_HELPER isn't set.
In this patch, clear the FW_OPT_FALLBACK flag in the case without
userhelper, so that the corresponding code will be disabled.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
More than two boolean arguments to a function are rather confusing and
error-prone for callers. Let's make the behavior bit flags instead of
triple combos.
A nice suggestion by Borislav Petkov.
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use the new helper, request_firmware_direct(), for avoiding the
lengthy timeout of non-existing firmware loads. Especially the Intel
microcode driver suffers from this problem because each CPU triggers
the f/w loading, thus it ends up taking (literally) hours with many
cores.
Tested-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When CONFIG_FW_LOADER_USER_HELPER is set, request_firmware() falls
back to the usermode helper for loading via udev when the direct
loading fails. But the recent udev takes way too long timeout (60
seconds) for non-existing firmware. This is unacceptable for the
drivers like microcode loader where they load firmwares optionally,
i.e. it's no error even if no requested file exists.
This patch provides a new helper function, request_firmware_direct().
It behaves as same as request_firmware() except for that it doesn't
fall back to usermode helper but returns an error immediately if the
f/w can't be loaded directly in kernel.
Without CONFIG_FW_LOADER_USER_HELPER=y, request_firmware_direct() is
just an alias of request_firmware(), due to obvious reason.
Tested-by: Prarit Bhargava <prarit@redhat.com>
Acked-by: Ming Lei <ming.lei@canonical.com>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the call to kvasprintf fails then the old name of the object will be leaked,
this patch fixes the bug by restoring the old name before returning ENOMEM.
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some of KERN_EMERG printk messages do not really deserve this log
level and the one in log_wait_commit() is even rather useless (the
journal has been previously aborted and *that* is where we should have
been complaining). So make some messages just KERN_ERR and remove the
useless message.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If a handle runs out of space, we currently stop the kernel with a BUG
in jbd2_journal_dirty_metadata(). This makes it hard to figure out
what might be going on. So return an error of ENOSPC, so we can let
the file system layer figure out what is going on, to make it more
likely we can get useful debugging information). This should make it
easier to debug problems such as the one which was reported by:
https://bugzilla.kernel.org/show_bug.cgi?id=44731
The only two callers of this function are ext4_handle_dirty_metadata()
and ocfs2_journal_dirty(). The ocfs2 function will trigger a
BUG_ON(), which means there will be no change in behavior. The ext4
function will call ext4_error_inode() which will print the useful
debugging information and then handle the situation using ext4's error
handling mechanisms (i.e., which might mean halting the kernel or
remounting the file system read-only).
Also, since both file systems already call WARN_ON(), drop the WARN_ON
from jbd2_journal_dirty_metadata() to avoid two stack traces from
being displayed.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: ocfs2-devel@oss.oracle.com
Acked-by: Joel Becker <jlbec@evilplan.org>
When the filesystem doesn't support extents (like in ext2/3
compatibility modes), there is no need to reserve any clusters. Space
estimates for writing are exact, hole punching doesn't need new
metadata, and there are no unwritten extents to convert.
This fixes a problem when filesystem still having some free space when
accessed with a native ext2/3 driver suddently reports ENOSPC when
accessed with ext4 driver.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
This reverts commit 614ced91fc.
The units on this was seen were prototypes and the issue is
not seen on younger units.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Individual controller driver has different requirement for wakeup
setting, so move it from core to itself. In order to align with
current etting the default wakeup setting is enabled (except for
chipidea host).
Pass compile test with below commands:
make O=outout/all allmodconfig
make -j$CPU_NUM O=outout/all drivers/usb
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds i.MX51 as the next user of the usbmisc driver.
Functionality is similar to i.MX53, so at this stage simply
reuse existing i.MX53 calls.
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds i.MX27 and i.MX31 as the next user of the usbmisc driver.
Tested-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ci_hdrc_imx's probe needs usbmisc_imx to be loadded beforehand,
so it is better we load usbmisc_imx first.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The regmap only needs to reallocate if the hw_read on the CAP register shows
lpm is used. Therefore the if() statement check the change.
Signed-off-by: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use PCI standard marco dev_is_pci() instead of directly compare
pci_bus_type to check whether it is pci device.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use PCI standard marco dev_is_pci() instead of directly compare
pci_bus_type to check whether it is pci device.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds external USB phy support to USB HCD driver that
allows to find and initialize external USB phy, bound to
the HCD, when the HCD is added.
The usb_add_hcd function returns -EPROBE_DEFER if the USB
phy, bound to the HCD, is not ready.
If no USB phy is bound, the HCD is initialized as usual.
Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds remove_phy flag to the HCD structure. If the flag is
set and if hcd->phy is valid, the phy is shutdown and released
whenever usb_add_hcd fails or usb_hcd_remove is called.
This can be used by the HCD drivers to auto-remove
the external USB phy when it is no longer needed.
Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We have sg_miter_* APIs for accessing scsi sg buffer, so
use them to make code clean and bug free.
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sg_copy_buffer() can't meet demand for some drrivers(such usb
mass storage), so we have to use the sg_miter_* APIs to access
sg buffer, then need export sg_miter_skip() for these drivers.
The API is needed for converting to sg_miter_* APIs in USB storage
driver for accessing sg buffer.
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add more info to debug prints in urb_unlink path
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add calls to usb_hcd_link_urb_to_ep, usb_hcd_unlink_urb_from_ep, and
usb_hcd_check_unlink_urb in the appropriate locations.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-spear suspend scenario.
Calling explicitly the ohci_suspend() routine in
spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-exynos suspend scenario.
Calling explicitly the ohci_suspend() routine in
exynos_ohci_suspend() will ensure proper handling of suspend
scenario.
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-da8xx suspend scenario.
Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-usb@vger.kernel.or
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-s3c2410 suspend scenario.
Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suspend scenario in case of ohci-at91 glue was not properly handled
as it was not suspending generic part of ohci controller. Alan Stern
suggested, properly handle ohci-at91 suspend scenario.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario. This task is sugested
by Alan Stern.
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suspend scenario in case of OHCI was not properly
handled in ochi_suspend()routine. Alan Stern
suggested, properly handle OHCI suspend scenario.
This does generic proper handling of suspend
scenario to all OHCI SOC.
Signed-off-by: Manjunath Goudar <csmanjuvijay@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>