msm_serial_hs: Call clk_set_rate() from non-atomic context

By default, HSUART Core CLK frequency is set to 7.37MHz. With this
CLK Frequency, it is not possible to get higher baud rate of 3.2 or
4 Mbps. Hence to set higher baud rate, driver calls clk_set_rate()
to set HSUART Core CLK frequency as ( required baud_rate * 16 ).
clk_set_rate() shouldn't be call from atomic context otherwise below
BUG is seen.

BUG: sleeping function called from invalid context at
mutex.c:85 in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: init
[<c00151c4>] (unwind_backtrace+0x0/0x12c) from
		[<c07aebbc>] (mutex_lock+0x18/0x3c)
[<c07aebbc>] (mutex_lock+0x18/0x3c) from
		[<c0021258>] (clk_set_rate+0x2c/0x178)
[<c0021258>] (clk_set_rate+0x2c/0x178) from
		[<c0364a34>] (msm_hs_set_termios+0x820/0xb9c)
[<c0364a34>] (msm_hs_set_termios+0x820/0xb9c)
		from [<c0362170>] (uart_change_speed+0x90/0x94)
[<c0362170>] (uart_change_speed+0x90/0x94)
		from [<c03626c0>] (uart_startup+0xc8/0x1a0)
[<c03626c0>] (uart_startup+0xc8/0x1a0)
		from [<c0363534>] (uart_open+0xe4/0x13c)
[<c0363534>] (uart_open+0xe4/0x13c)
		from [<c0343d64>] (tty_open+0x360/0x4ec)
[<c0343d64>] (tty_open+0x360/0x4ec)
		from [<c013787c>] (chrdev_open+0x114/0x134)
[<c013787c>] (chrdev_open+0x114/0x134)
		from [<c0132844>] (__dentry_open+0x190/0x29c)
[<c0132844>] (__dentry_open+0x190/0x29c)
		from [<c0132a00>] (nameidata_to_filp+0x50/0x5c)
[<c0132a00>] (nameidata_to_filp+0x50/0x5c)
		from [<c0141b08>] (do_last+0x7ec/0x928)
[<c0141b08>] (do_last+0x7ec/0x928)
		from [<c0141d08>] (path_openat+0xc4/0x390)
[<c0141d08>] (path_openat+0xc4/0x390)
		from [<c01420b4>] (do_filp_open+0x30/0x7c)
[<c01420b4>] (do_filp_open+0x30/0x7c)
		from [<c0132518>] (do_sys_open+0xd8/0x174)
[<c0132518>] (do_sys_open+0xd8/0x174)
		from [<c000e380>] (ret_fast_syscall+0x0/0x30)

Hence use mutex to protect msm_set_termios() allowing clk_set_rate()
to be called from non-atomic context.

Change-Id: I92073aaf0c80a9a432c47d42286d9a130cf5172c
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
msm_serial_hs: handle uart_flush_buffer

Serial core allocates circular buffer for uart tx transfer.
Circular buffer head and tail is updated in serial core and
circular buffer tail is updated in uart driver.While uart
transfer is happening, uart client bluetooth hci_ldisc,calls
uart_flush_buffer in serial core and sets circular buffer
head and tail to zero.As uart driver does not know when
uart_flush_buffer is called in serial core by uart client,it
updates circular buffer tail for the previous ADM Tx completion.
This leads to queueing Tx command to ADM although no data is
there in circular buffer.Because of this,uart client is not
functional.

Hence adding msm_hs_flush_buffer api which notifies to uart driver
that uart_flush_buffer is called in serial core by uart client and
set tty_flush_receive flag to true.In uart interrupt handler ,do
not update circular buffer tail if uart_flush_buffer is already
called in serial core by uart client else update circular buffer
tail on ADM Tx completion.

	CRs-Fixed: 419054
	Change-Id: Ide13960bd5f9c4c374cadfab2a9860e928ef2e1c
	Signed-off-by: Saket Saurabh <ssaurabh@codeaurora.org>

msm_serial_hs: Initialize tty_flush_recieve while Port Open

Initialize the tty_flush_recieve to default value during
Port Open to avoid a corner case where Tx bytes may get queued
twice by UART in the absence of initialization.

Corner Case:
UART client calls uart_flush_buffer() API to flush the
data on Tx while UART Tx is in middle of operation.
If client immediately calls UART Port close followed by UART Tx
after Port-Open, it may result in queueing same bytes twice

	CRs-Fixed: 590459
	Change-Id: Ied9d33265060e1fde7fc98e29f58d3eff6ddc3c4
	Signed-off-by: Dilip Kota <c_dkota@codeaurora.org>

msm_serial_hs: Remove code dependency on flag tty_flush_receive

Removing code dependency on the flag and check the
circular buffer directly and make sure that spin lock is taken
appropriately in the tx lower half.

This avoids the condition that can cause
1. tx lower half
2. submit tx command
to race.

	CRs-Fixed: 621210
	Change-Id: I344a72c3eb9770391576fa0e8f0a8da1ee50ea5b
	Signed-off-by: Dilip Kota <c_dkota@codeaurora.org>
msm_serial_hs: restore PM (previously disabled by HUAWEI)

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
msm_serial_hs: Don't configure gpios into UART Mode always

UARTDM device is used as interface to connect external devices through
GPIOs. Currently those GPIOs are configured in active mode once driver's
probe() is called and configured in suspend mode once its remove() is
called. Probe() is called once only and remove is not called until UARTDM
platform device is removed. With this current implementation, although
external device (ex. Bluetooth SoC) is not operational mode, used UARTDM
GPIOs are configured in active mode which is causing more leakage current
and more power consumption.

Hence configure those UARTDM GPIOs in active mode only when used UARTDM
device is opened and under used. Configure UARTDM GPIOs back to suspend
mode when UARTDM device is closed and under not used.

CRs-Fixed: 422217
Change-Id: I509d5a1ddf4e1b2c261d31a820fce2de93d0fece
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
msm_serial_hs: Add support to handle Rx BREAK condition

Currently Rx Break Error condition is not checked using UART_DM_SR
register. Hence by default null-character is being inserted on
receiving Rx Error or Rx Break condition. Application sets termios
c_iflag if it needs any notification related to any Rx Error or
Break condition. Hence add support to handle Rx Break condition and
insert null-character conditionally based on termios.c_iflag.

	CRs-Fixed: 412201
	Change-Id: I7f496e42757b949f597d5dbe5c1f1ca88ee53c8c
	Signed-off-by: Mayank Rana <mrana@codeaurora.org>

msm_serial_hs: Correct setting of ignore_status_mask

Termios are used by application to notify UART driver about
what are the events it is interested to be updated (i.e. like
Parity / Break Conditions). Currently while setting IGNBRK bit
previous status of IGNPAR is ignored. Hence correct the same.

	Change-Id: I5420c88713de40a20001ce3f3062fd2d8f2fb2e0
	Signed-off-by: Mayank Rana <mrana@codeaurora.org>
msm_serial_hs: Donot register UART device as PM runtime active

Currently UART device is being registered as PM runtime active
in probe() and set as suspended in shutdown(). With this UART
driver PM runtime suspend is being called when system suspend
is invoked and while resuming from the same which invokes UART
driver LPM functionality. It causes UART communication to stop
if both UART Tx and RX FIFO are empty.

This change donot register UART device as PM runtime active
device as UART driver doesn't use PM runtime APIs for its LPM
functionality.

CRs-Fixed: 479966
Change-Id: I33d0c95e4227fdb1b7d6d514498e161e6e4df465
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
msm_serial_hs: Add check to validate wakeup irq in UART clock on request

Wakeup irq is UART RX GPIO IRQ line to be configured as wakeup source and
is used as an optional property with UART. By default wakeup irq is set as
zero when it is not to be used with UART.
During UART clock on request msm_hs_request_clock_on(), calling
disable_irq_nosync() without validating wakeup irq is causing warning
message.
Hence fixing the issue by adding check to validate the wakeup irq during
UART clock on request.

CRs-Fixed: 490597
Change-Id: Iff014f41428d590117e469c1b470736383a78848
Signed-off-by: Saket Saurabh <ssaurabh@codeaurora.org>
msm_serial_hs: Programing the TX FIFO watermark level to 4

As per the Hardware Data Book recommendation the
TX FIFO watermark level should not be zero.
Hence programing the TX FIFO watermark level to
4 to avoid corner cases

CRs-Fixed: 621214
Change-Id: Icee051bd37c389f31a010b51ffaf5d46854306b5
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
Signed-off-by: Dilip Kota <c_dkota@codeaurora.org>
msm_serial_hs:Enable Error/Break Char off

Follow the hardware sequence of enabling
RX_ERROR_CHAR_OFF and RX_BREAK_ZERO_CHAR_OFF in
MR2 register, for not allowing the Break and
parity/frame Error characters into Rx FIFO.

CRs-Fixed: 538141
Change-Id: I24f73eea456c4cb2a68b1655bcd5426426ca7d97
Signed-off-by: Dilip Kota <c_dkota@codeaurora.org>
Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
i2c: Fall back to emulated SMBus if the operation isn't supported natively

Adapter drivers might support only a subset of the SMBus operations
natively. Those drivers currently have to manually emulate unsupported
operations using I2C.

Make the i2c_smbus_xfer() function fall back to
i2c_smbus_xfer_emulated() when the adapter's .smbus_xfer() operation
returns -EOPNOTSUPP, like it already does when the .smbus_xfer()
operation isn't available at all.

[JD: Minor optimization.]

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
i2c: Convert struct i2c_msg initialization to C99 format

Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.

Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
i2c: core: Remove definition of i2c_smbus_process_call

i2c_smbus_process_call has no users in the kernel, so this can be
removed. Documentation for the same has been updated accordingly.

Fixes following sparse warning.
drivers/i2c/i2c-core.c:1871:5: warning: symbol 'i2c_smbus_process_call'
was not declared. Should it be static?

[wsa: updated the documentation]

Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
i2c: Add bus recovery infrastructure

Add i2c bus recovery infrastructure to i2c adapters as specified in the i2c
protocol Rev. 03 section 3.1.16 titled "Bus clear".

http://www.nxp.com/documents/user_manual/UM10204.pdf

Sometimes during operation i2c bus hangs and we need to give dummy clocks to
slave device to start the transfer again. Now we may have capability in the bus
controller to generate these clocks or platform may have gpio pins which can be
toggled to generate dummy clocks. This patch supports both.

This patch also adds in generic bus recovery routines gpio or scl line based
which can be used by bus controller. In addition controller driver may provide
its own version of the bus recovery routine.

This doesn't support multi-master recovery for now.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[wsa: changed gpio type to int and minor reformatting]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
i2c: Remove detach_adapter

The detach_adapter callback has been deprecated for quite some time and has no
user left. Keeping it alive blocks other cleanups, so remove it.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
i2c: i2c_del_adapter: Don't treat removing a non-registered adapter as error

Currently i2c_del_adapter() returns -EINVAL when it gets an adapter which is not
registered. But none of the users of i2c_del_adapter() depend on this behavior,
so for the sake of being able to sanitize the return type of i2c_del_adapter
argue, that the purpose of i2c_del_adapter() is to remove an I2C adapter from
the system. If the adapter is not registered in the first place this becomes a
no-op. So we can return success without having to do anything.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
i2c: Make return type of i2c_del_adapter() void

i2c_del_adapter() is usually called from a drivers remove callback. The Linux
device driver model does not allow the remove callback to fail and all resources
allocated in the probe callback need to be freed, as well as all resources which
have been provided to the rest of the kernel(for example a I2C adapter) need to
be revoked. So any function revoking such resources isn't allowed to fail
either. i2c_del_adapter() adheres to this requirement and will never fail. But
i2c_del_adapter()'s return type is int, which may cause driver authors to think
that it can fail. This led to code constructs like:

	ret = i2c_del_adapter(...);
	BUG_ON(ret);

Since i2c_del_adapter() always returns 0 the BUG_ON is never hit and essentially
becomes dead code, which means it can be removed. Making the return type of
i2c_del_adapter() void makes it explicit that the function will never fail and
should prevent constructs like the above from re-appearing in the kernel code.

All callers of i2c_del_adapter() have already been updated in a previous patch
to ignore the return value, so the conversion of the return type from int to
void can be done without causing any build failures.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
sysfs: get rid of some lockdep false positives

This patch (as1554) fixes a lockdep false-positive report.  The
problem arises because lockdep is unable to deal with the
tree-structured locks created by the device core and sysfs.

This particular problem involves a sysfs attribute method that
unregisters itself, not from the device it was called for, but from a
descendant device.  Lockdep doesn't understand the distinction and
reports a possible deadlock, even though the operation is safe.

This is the sort of thing that would normally be handled by using a
nested lock annotation; unfortunately it's not feasible to do that
here.  There's no sensible way to tell sysfs when attribute removal
occurs in the context of a parent attribute method.

As a workaround, the patch adds a new flag to struct attribute
telling sysfs not to inform lockdep when it acquires a readlock on a
sysfs_dirent instance for the attribute.  The readlock is still
acquired, but lockdep doesn't know about it and hence does not
complain about impossible deadlock scenarios.

Also added are macros for static initialization of attribute
structures with the ignore_lockdep flag set.  The three offending
attributes in the USB subsystem are converted to use the new macros.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Tejun Heo <tj@kernel.org>
CC: Eric W. Biederman <ebiederm@xmission.com>
CC: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
i2c: suppress lockdep warning on delete_device

i2c: suppress lockdep warning on delete_device

Since commit 846f99749ab68bbc7f75c74fec305de675b1a1bf the following lockdep
warning is thrown in case i2c device is removed (via delete_device sysfs
attribute) which contains subdevices (e.g. i2c multiplexer):

=============================================
[ INFO: possible recursive locking detected ]
3.8.7-0-sampleversion-fct #8 Tainted: G           O
---------------------------------------------
bash/3743 is trying to acquire lock:
  (s_active#110){++++.+}, at: [<ffffffff802b3048>] sysfs_hash_and_remove+0x58/0xc8

but task is already holding lock:
  (s_active#110){++++.+}, at: [<ffffffff802b3cb8>] sysfs_write_file+0xc8/0x208

other info that might help us debug this:
  Possible unsafe locking scenario:

        CPU0
        ----
   lock(s_active#110);
   lock(s_active#110);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

4 locks held by bash/3743:
  #0:  (&buffer->mutex){+.+.+.}, at: [<ffffffff802b3c3c>] sysfs_write_file+0x4c/0x208
  #1:  (s_active#110){++++.+}, at: [<ffffffff802b3cb8>] sysfs_write_file+0xc8/0x208
  #2:  (&adap->userspace_clients_lock/1){+.+.+.}, at: [<ffffffff80454a18>] i2c_sysfs_delete_device+0x90/0x238
  #3:  (&__lockdep_no_validate__){......}, at: [<ffffffff803dcc24>] device_release_driver+0x24/0x48

stack backtrace:
Call Trace:
[<ffffffff80575cc8>] dump_stack+0x8/0x34
[<ffffffff801b50fc>] __lock_acquire+0x161c/0x2110
[<ffffffff801b5c3c>] lock_acquire+0x4c/0x70
[<ffffffff802b60cc>] sysfs_addrm_finish+0x19c/0x1e0
[<ffffffff802b3048>] sysfs_hash_and_remove+0x58/0xc8
[<ffffffff802b7d8c>] sysfs_remove_group+0x64/0x148
[<ffffffff803d990c>] device_remove_attrs+0x9c/0x1a8
[<ffffffff803d9b1c>] device_del+0x104/0x1d8
[<ffffffff803d9c18>] device_unregister+0x28/0x70
[<ffffffff8045505c>] i2c_del_adapter+0x1cc/0x328
[<ffffffff8045802c>] i2c_del_mux_adapter+0x14/0x38
[<ffffffffc025c108>] pca954x_remove+0x90/0xe0 [pca954x]
[<ffffffff804542f8>] i2c_device_remove+0x80/0xe8
[<ffffffff803dca9c>] __device_release_driver+0x74/0xf8
[<ffffffff803dcc2c>] device_release_driver+0x2c/0x48
[<ffffffff803dbc14>] bus_remove_device+0x13c/0x1d8
[<ffffffff803d9b24>] device_del+0x10c/0x1d8
[<ffffffff803d9c18>] device_unregister+0x28/0x70
[<ffffffff80454b08>] i2c_sysfs_delete_device+0x180/0x238
[<ffffffff802b3cd4>] sysfs_write_file+0xe4/0x208
[<ffffffff8023ddc4>] vfs_write+0xbc/0x160
[<ffffffff8023df6c>] SyS_write+0x54/0xd8
[<ffffffff8013d424>] handle_sys64+0x44/0x64

The problem is already known for USB and PCI subsystems. The reason is that
delete_device attribute is defined statically in i2c-core.c and used for all
devices in i2c subsystem.

Discussion of original USB problem:
http://lkml.indiana.edu/hypermail/linux/kernel/1204.3/01160.html

Commit 356c05d58af05d582e634b54b40050c73609617b introduced new macro to suppress
lockdep warnings for this special case and included workaround for USB code.

LKML discussion of the workaround:
http://lkml.indiana.edu/hypermail/linux/kernel/1205.1/03634.html

As i2c case is in principle the same, the same workaround could be used here.

Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
i2c: add sanity check to i2c_put_adapter

i2c_put_adapter dereferences i2c_adapter pointer passed without check
for NULL. This adds a check for non-NULL pointer to allow i2c_put_adapter
called with NULL and behave the same way i2c_release_client does already.
It allows to simplify drivers where you need to release the adapter
during probe failures.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
i2c: Improve logging on failure to probe for ->class devices

While writing the i2c-imc driver, I noticed that the warning message
when the i2c core can't figure out how to probe is mostly useless.
This trivial patch improves it.

Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>