edma: Update author email address

Matt's @ti.com address bounces.  Update the MODULE_AUTHOR information in
edma.c to his Linaro address.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Acked-by: Matt Porter <matt.porter@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
dma/Kconfig: Make TI_EDMA select TI_PRIV_EDMA

The TI_EDMA driver unconditionally calls functions provided by the
TI_PRIV_EDMA code, but it doesn't force that to be built-in.  If that isn't
otherwise enabled somewhere, you can get build errors like:

linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:593: undefined reference to `edma_free_slot'
drivers/built-in.o: In function `edma_terminate_all':
linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:169: undefined reference to `edma_stop'
drivers/built-in.o: In function `edma_execute':
linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:122: undefined reference to `edma_write_slot'
linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:149: undefined reference to `edma_link'
linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:152: undefined reference to `edma_start'

Make TI_EDMA select TI_PRIV_EDMA to avoid this.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Acked-by: Matt Porter <matt.porter@linaro.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
usb: musb: fix otg default state

Right after the musb_hdrc driver is loaded, the otg default state
is a_idle, and Mode=Host, which are set by musb_host_setup().

This causes the following kernel message during musb gadget
enumeration.

	CAUTION: musb: Babble Interrupt Occurred

This patch sets the otg default state to b_idle, and its Mode to
Peripheral.

It has been validated on TI AM335x GP EVM USB0 port with g_zero.

Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
CIFS: FS-Cache: Uncache unread pages in cifs_readpages() before freeing them

In cifs_readpages(), we may decide we don't want to read a page after all -
but the page may already have passed through fscache_read_or_alloc_pages() and
thus have marks and reservations set.  Thus we have to call
fscache_readpages_cancel() or fscache_uncache_page() on the pages we're
returning to clear the marks.

NFS, AFS and 9P should be unaffected by this as they call read_cache_pages()
which does the cleanup for you.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
cifs: stop trying to use virtual circuits

Currently, we try to ensure that we use vcnum of 0 on the first
established session on a connection and then try to use a different
vcnum on each session after that.

This is a little odd, since there's no real reason to use a different
vcnum for each SMB session. I can only assume there was some confusion
between SMB sessions and VCs. That's somewhat understandable since they
both get created during SESSION_SETUP, but the documentation indicates
that they are really orthogonal. The comment on max_vcs in particular
looks quite misguided. An SMB session is already uniquely identified
by the SMB UID value -- there's no need to again uniquely ID with a
VC.

Furthermore, a vcnum of 0 is a cue to the server that it should release
any resources that were previously held by the client. This sounds like
a good thing, until you consider that:

a) it totally ignores the fact that other programs on the box (e.g.
smbclient) might have connections established to the server. Using a
vcnum of 0 causes them to get kicked off.

b) it causes problems with NAT. If several clients are connected to the
same server via the same NAT'ed address, whenever one connects to the
server it kicks off all the others, which then reconnect and kick off
the first one...ad nauseum.

I don't see any reason to ignore the advice in "Implementing CIFS" which
has a comprehensive treatment of virtual circuits. In there, it states
"...and contrary to the specs the client should always use a VcNumber of
one, never zero."

Have the client just use a hardcoded vcnum of 1, and stop abusing the
special behavior of vcnum 0.

Reported-by: Sauron99@gmx.de <sauron99@gmx.de>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Volker Lendecke <vl@samba.org>
Signed-off-by: Steve French <smfrench@gmail.com>
[CIFS] Provide sane values for nlink

Since we don't get info about the number of links from the readdir
linfo levels, stat() will return 0 for st_nlink, and in particular,
samba re-exported shares will show directories as files (as samba is
keying off st_nlink before evaluating how to set the dos modebits)
when doing a dir or ls.

Copy nlink to the inode, unless it wasn't provided.  Provide
sane values if we don't have an existing one and none was provided.

Signed-off-by: Jim McDonough <jmcd@samba.org>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Signed-off-by: Steve French <smfrench@gmail.com>
usb: gadget: pxa25x_udc: fix deferred probe from __init

Move probe out of __init section and don't use platform_driver_probe
which cannot be used with deferred probing.

Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
this driver might return -EPROBE_DEFER if a gpio_request fails.

Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: phy: gpio-vbus: fix deferred probe from __init

Move probe out of __init section and don't use platform_driver_probe
which cannot be used with deferred probing.

Since commit e9354576 ("gpiolib: Defer failed gpio requests by default")
and 04bf3011 ("regulator: Support driver probe deferral") this driver
might return -EPROBE_DEFER if a gpio_request or regulator_get fails.

Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
usb: musb: gadget: fix otg active status flag

In gadget mode, musb->is_active should be set only when connected to the
host. musb_g_reset() already takes care of it.

Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
[CIFS] Remove ext2 flags that have been moved to fs.h

These flags were unused by cifs and since the EXT flags have
been moved to common code in uapi/linux/fs.h we won't need
to have a cifs specific copy.

Signed-off-by: Steve French <smfrench@gmail.com>
[CIFS] update cifs.ko version

To 2.02

Signed-off-by: Steve French <smfrench@gmail.com>
iio: amplifiers: ad8366: Remove regulator_put

Since devm_regulator_get is used, regulator_put should not be
used. Remove it.

Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio: Remove debugfs entries in iio_device_unregister()

Remove the the debugfs entries in iio_device_unregister(). Otherwise the debugfs
entries might still be accessible even though the device used in the debugfs
callback has already been freed.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio:magnetometer: Bugfix magnetometer default output registers

Signed-off-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
USB: serial: option: Ignore card reader interface on Huawei E1750

Hi,

my Huawei 3G modem has an embedded Smart Card reader which causes
trouble when the modem is being detected (a bunch of "<warn>  (ttyUSBx):
open blocked by driver for more than 7 seconds!" in messages.log). This
trivial patch corrects the problem for me. The modem identifies itself
as "12d1:1406 Huawei Technologies Co., Ltd. E1750" in lsusb although the
description on the body says "Model E173u-1"

Signed-off-by: Michal Malý <madcatxster@prifuk.cz>
Cc: Bjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty: Fix pty master read() after slave closes

Commit f95499c3030fe1bfad57745f2db1959c5b43dca8,
  n_tty: Don't wait for buffer work in read() loop
creates a race window which can cause a pty master read()
to miss the last pty slave write(s) and return -EIO instead,
thus signalling the pty slave is closed. This can happen when
the pty slave is written and immediately closed but before the
tty buffer i/o loop receives the new input; the pty master
read() is scheduled, sees its read buffer is empty and the
pty slave has been closed, and exits.

Because tty_flush_to_ldisc() has significant performance impact
for parallel i/o, rather than revert the commit, special case this
condition (ie., when the read buffer is empty and the 'other' pty
has been closed) and, only then, wait for buffer work to complete
before re-testing if the read buffer is still empty.

As before, subsequent pty master reads return any available data
until no more data is available, and then returns -EIO to
indicate the pty slave has closed.

Reported-by: Mikael Pettersson <mikpelinux@gmail.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Tested-by: Mikael Pettersson <mikpelinux@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'iio-fixes-for-3.12b2' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus

Jonathan writes:

Second set of IIO fixes for the 3.12 cycle (take 2)

A few small fixes:
1) Make sure that debugfs entries are removed early enough to prevent
a race.
2) Drop a stray regulator_put from ad8366 left over from the devm_ patches.
3) The ST magnetometer driver had incorrect register addresses for the
   actual data channels.
gpio/omap: maintain GPIO and IRQ usage separately

The GPIO OMAP controller pins can be used as IRQ and GPIO
independently so is necessary to keep track GPIO pins and
IRQ lines usage separately to make sure that the bank will
always be enabled while being used.

Also move gpio_is_input() definition in preparation for the
next patch that setups the controller's irq_chip driver when
a caller requests an interrupt line.

Cc: stable@vger.kernel.org
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: George Cherian <george.cherian@ti.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Tested-by: Lars Poeschel <poeschel@lemonage.de>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio/omap: auto-setup a GPIO when used as an IRQ

The OMAP GPIO controller HW requires a pin to be configured in GPIO
input mode in order to operate as an interrupt input. Since drivers
should not be aware of whether an interrupt pin is also a GPIO or not,
the HW should be fully configured/enabled as an IRQ if a driver solely
uses IRQ APIs such as request_irq(), and never calls any GPIO-related
APIs. As such, add the missing HW setup to the OMAP GPIO controller's
irq_chip driver.

Since this bypasses the GPIO subsystem we have to ensure that another
driver won't be able to request the same GPIO pin that is used as an
IRQ and set its direction as output. Requesting the GPIO and setting
its direction as input is allowed though.

This fixes smsc911x ethernet support for tobi and igep OMAP3 boards
and OMAP4 SDP SPI based ethernet that use a GPIO as an interrupt line.

Cc: stable@vger.kernel.org
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: George Cherian <george.cherian@ti.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Tested-by: Lars Poeschel <poeschel@lemonage.de>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
usb: musb: dsps: do not bind to "musb-hdrc"

This went unnoticed in durin the merge window:
The dsps driver creates a child device for the musb core driver _and_
attaches the of_node to it so devm_usb_get_phy_by_phandle() grabs the
correct phy and attaches the devm resources to the proper device. We
could also use the parent device but then devm would attach the
resource to the wrong device and it would be destroyed once the parent
device is gone - not the device that is used by the musb core driver.

If the phy is now not available then dsps_musb_init() /
devm_usb_get_phy_by_phandle() returns with EPROBE_DEFER. Since the
of_node is attached it tries OF drivers as well and matches the driver
against DSPS. That one creates a new child device for the musb core
driver which gets probed immediately.

The whole thing repeats itself until the stack overflows.

I belive the same problem exists in ux500 glue code (since 313bdb11
("usb: musb: ux500: add device tree probing support") but the drivers are
now probed in the right order so they don't see it.

The problem is that the dsps driver gets bound to the musb-child device
due to the same of_node / matching binding. I don't really agree with
having yet another child node in DT to fix this. Ideally we would have
musb core driver with DT bindings and according to the binding we would
select the few extra hacks / gleue layer.

Therefore I suggest the driver to reject the musb-core device.

Cc: Lee Jones <lee.jones@linaro.org>
Tested-by: Tom Rini <trini@ti.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>