I have a at24 EEPROM connected via i2c bus provided by ISCH i2c
bus driver. This bus driver does not support
I2C_FUNC_SMBUS_WRITE_I2C_BLOCK and so I was looking for a way
to be able to write the eeprom. This patch adds support for
I2C_SMBUS_BYTE_DATA writing via i2c_smbus_write_byte_data.
It is quite slow, but it works.
Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
[wsa: s/use_smbuse_write/use_smbus_write/]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Signed-off-by: NDevin Ryles <devin.ryles@intel.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

No user needs magic hex values, makes this debug output. Add DMA info.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Make it possible to transfer i2c message buffers via DMA.
Start/Stop/Sending_Slave_Address is still handled using the old state
machine, it is sending the actual data that is done via DMA. This is
least intrusive and allows us to work with the message buffers directly
instead of preparing a custom buffer which involves copying the data
around.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
[wsa: fixed an uninitialized var problem]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Improves readability and reduces chances of duplicates.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Amend the at91 i2c pin controller to set the state of the pins to:
- "default" on resume.
- "sleep" on suspend().

This should make it possible to optimize energy usage for the pins
both for the suspend/resume cycle
Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch enforces correct I2C error returned codes from Freescale's
MPC i2c bus driver, allowing for proper user-space/kernel error
handling.
Signed-off-by: NDanielle Costantino <danielle.costantino@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Don't log the host status register value in i801_isr(), it has very
little value and fills up the log when debugging is enabled.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

There is a control bit in the PCI configuration space which disables
interrupts. If this bit is set, the driver should not try to make use
of interrupts, it won't receive any.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The i2c-i801 driver can work without interrupts, so there is no reason
to make a request_irq failure fatal. Instead we can simply fallback
to polling.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Some systems have been reported to have trouble with interrupts. Use
wait_event_timeout() instead of wait_event() so we don't get stuck in
that case, and log the problem.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

As show in I2C specification:
- Standard-mode: the minimum HIGH period of the scl clock is 4.0us
                 the minimum LOW period of the scl clock is 4.7us
- Fast-mode: the minimum HIGH period of the scl clock is 0.6us
             the minimum LOW period of the scl clock is 1.3us

I have measured i2c SCL waveforms in fast-mode by oscilloscope
on rk3288-pinky board. the LOW period of the scl clock is 1.3us.
It is so critical that we must adjust LOW division to increase
the LOW period of the scl clock.

Thanks Doug for the suggestion about division formulas.
Signed-off-by: NAddy Ke <addy.ke@rock-chips.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Reviewed-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

When a signal is caught while the i2c-davinci bus driver is
transferring, the driver just "abandons" the transfer and leaves the
controller to fend for itself. The next I2C transaction will find the
controller in an undefined state and often results in a stream of
"initiating i2c bus recovery" messages until the controller arrives in a
defined state. This behaviour also sends out "half" or possibly even
mixed messages to I2C client devices which may put them in an undesired
state as well. So, let's get simply uninterruptible.
Signed-off-by: NMike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Drivers should put the device into low power states proactively whenever the
device is not in use. Thus implement support for runtime PM and use the
autosuspend feature to make sure that we can still perform well in case we see
lots of i2c traffic within short period of time.
Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

I2C clients instantiated from OF get their IRQ mapped at device
registration time. This leads to the IRQ being silently ignored if the
related irqchip hasn't been proved yet.

Fix this by moving IRQ mapping at probe time using of_get_irq(). The
function operates as irq_of_parse_and_map() but additionally returns
-EPROBE_DEFER if the irqchip isn't available, allowing us to defer I2C
client probing.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The function will be used by the I2C core which can be compiled as a
module.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NRob Herring <robh@kernel.org>
Acked-by: NGrant Likely <grant.likely@linaro.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Add support for r8a73a4 (R-Mobile APE6) and sh73a0 (SH-Mobile AG5).
On these SoCs, the operating clock runs faster that on previous SoCs,
and the internal SCL clock counter gets incremented every 2 clocks of
the operating clock, just like on R-Car Gen2.

Cfr. the "/2" in the calculation of ICCL/ICCH in section "I2C Bus
Interface (IIC)", subsection "Transfer Rate" of the datasheets.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

According to Documentation/CodingStyle - Chapter 14:

"The preferred form for passing a size of a struct is the following:

	p = kmalloc(sizeof(*p), ...);

The alternative form where struct name is spelled out hurts readability and
introduces an opportunity for a bug when the pointer variable type is changed
but the corresponding sizeof that is passed to a memory allocator is not."

So do it as recommeded.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The ENABLE_DEV_COREDUMP option is misleading as it implies that
it gets the framework enabled, this isn't true it just allows it
to get enabled if a driver needs it.

Rename it to ALLOW_DEV_COREDUMP to better capture its semantics.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Acked-by: NAristeu Rozanski <aris@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It's desirable for allnconfig and tinyconfig targets to result in the
least amount of code possible. DISABLE_DEV_COREDUMP exists as a way to
switch off DEV_COREDUMP regardless if any drivers select
WANT_DEV_COREDUMP.

This patch renames the option to ENABLE_DEV_COREDUMP and setting it to
'n' (as in allnconfig or tinyconfig) will effectively disable device
coredump.

Cc: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NAristeu Rozanski <arozansk@redhat.com>
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Clients instantiated from OF get an IRQ mapping created at device
registration time. Dispose the mapping when the client is removed.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

iowait is for blkio [1]. I2C shouldn't use it.

[1] https://lkml.org/lkml/2014/11/3/317Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Cc: stable@kernel.org

We have a central copy of the GPL for that. Some addresses were already
outdated.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>

There is a race condition when removing glue directory.
It can be reproduced in following test:

path 1: Add first child device
device_add()
    get_device_parent()
            /*find parent from glue_dirs.list*/
            list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
                    if (k->parent == parent_kobj) {
                            kobj = kobject_get(k);
                            break;
                    }
            ....
            class_dir_create_and_add()

path2: Remove last child device under glue dir
device_del()
    cleanup_device_parent()
            cleanup_glue_dir()
                    kobject_put(glue_dir);

If path2 has been called cleanup_glue_dir(), but not
call kobject_put(glue_dir), the glue dir is still
in parent's kset list. Meanwhile, path1 find the glue
dir from the glue_dirs.list. Path2 may release glue dir
before path1 call kobject_get(). So kernel will report
the warning and bug_on.

This is a "classic" problem we have of a kref in a list
that can be found while the last instance could be removed
at the same time.

This patch reuse gdp_mutex to fix this race condition.

The following calltrace is captured in kernel 3.4, but
the latest kernel still has this bug.

-----------------------------------------------------
<4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40()
<4>[ 3965.441474] Hardware name: Romley
<4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)...
...
<4>[ 3965.441605] Call Trace:
<4>[ 3965.441611]  [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0
<4>[ 3965.441615]  [<ffffffff810371c5>] warn_slowpath_null+0x15/0x20
<4>[ 3965.441618]  [<ffffffff81215963>] kobject_get+0x33/0x40
<4>[ 3965.441624]  [<ffffffff812d1e45>] get_device_parent.isra.11+0x135/0x1f0
<4>[ 3965.441627]  [<ffffffff812d22d4>] device_add+0xd4/0x6d0
<4>[ 3965.441631]  [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40
....
<2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65!
<4>[ 3965.441915] invalid opcode: 0000 [#1] SMP
...
<4>[ 3965.686743]  [<ffffffff811a677e>] sysfs_create_group+0xe/0x10
<4>[ 3965.686748]  [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20
<4>[ 3965.686753]  [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120
<4>[ 3965.686756]  [<ffffffff812030bc>] add_disk+0x1cc/0x490
....
-------------------------------------------------------
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NWeng Meiling <wengmeiling.weng@huawei.com>
Cc: <stable@vger.kernel.org> #3.4+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add new quirk for devices that cannot handle control-line state
requests.

Note that we currently send these requests to all devices, regardless of
whether they claim to support it, but that errors are only logged if
support is claimed.

Since commit 0943d8ea ("USB: cdc-acm: use tty-port dtr_rts"), which
only changed the timings for these requests slightly, this has been
reported to cause occasional firmware crashes on Simtec Electronics
Entropy Key devices after re-enumeration. Enable the quirk for this
device.
Reported-by: NNix <nix@esperi.org.uk>
Tested-by: NNix <nix@esperi.org.uk>
Cc: stable <stable@vger.kernel.org>	# v3.16
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit f95499c3 ("n_tty: Don't wait for buffer work in read() loop")
introduces a race window where a pty master can be signalled that the pty
slave was closed before all the data that the slave wrote is delivered.
Commit f8747d4a ("tty: Fix pty master read() after slave closes") fixed the
problem in case of n_tty_read, but the problem still exists for n_tty_poll.
This can be seen by running 'for ((i=0; i<100;i++));do ./test.py ;done'
where test.py is:

import os, select, pty

(pid, pty_fd) = pty.fork()

if pid == 0:
   os.write(1, 'This string should be received by parent')
else:
   poller = select.epoll()
   poller.register( pty_fd, select.EPOLLIN )
   ready = poller.poll( 1 * 1000 )
   for fd, events in ready:
      if not events & select.EPOLLIN:
         print 'missed POLLIN event'
      else:
         print os.read(fd, 100)
   poller.close()

The string from the slave is missed several times.
This patch takes the same approach as the fix for read and special cases
this condition for poll.
Tested on 3.16.
Signed-off-by: NFrancesco Ruggeri <fruggeri@arista.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If PM_RUNTIME is enabled, it is easy to trigger the following backtrace
on pxa2xx hosts:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104
[<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14)
[<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c)
[<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24)
[<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8)
[<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34)
[<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54)
[<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74)
[<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8)
[<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208)
[<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0)
[<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8)
[<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc)
[<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc)
[<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4)
[<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec)
[<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24)
---[ end trace 46524156d8faa4f6 ]---

This happens because suspend function tries to disable a clock that is
already disabled by runtime_suspend callback. Add if
(!pm_runtime_suspended()) checks to suspend/resume path.

Fixes: 7d94a505 (spi/pxa2xx: add support for runtime PM)
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Reported-by: NAndrea Adami <andrea.adami@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

The info pointer points to an uninitialized kmalloced space.
If a device doesn't have clk property, then info->clk may
have unpredicated value and cause call trace. So use kzalloc
to make sure it is NULL initialized.
Signed-off-by: NJingchang Lu <jingchang.lu@freescale.com>
Acked-by: Arnd Bergmann <arnd@arndb.de
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We can call this function for a dummy console that doesn't support
setting the font mapping, which will result in a null ptr BUG. So check
for this case and return error for consoles w/o font mapping support.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=59321Signed-off-by: NImre Deak <imre.deak@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The calculation of value quot for highspeed register set to three
was wrong. This patch fixes the calculation so that the serial port
for baudrates bigger then 576000 baud is working correctly.
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The horrible split between the low-level part of the edma support
and the dmaengine front-end driver causes problems on multiplatform
kernels. This is an attempt to improve the situation slightly
by only registering the dmaengine devices that are actually
present.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
[olof: add missing include of linux/dma-mapping.h]
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Only print one warning when a task is on the read_wait or write_wait
wait queue at final tty release.

Cc: <stable@vger.kernel.org> # 3.4.x+
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Kernel oops can cause the tty to be unreleaseable (for example, if
n_tty_read() crashes while on the read_wait queue). This will cause
tty_release() to endlessly loop without sleeping.

Use a killable sleep timeout which grows by 2n+1 jiffies over the interval
[0, 120 secs.) and then jumps to forever (but still killable).

NB: killable just allows for the task to be rewoken manually, not
to be terminated.

Cc: <stable@vger.kernel.org> # since before 2.6.32
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

uart_get_baud_rate() will return baud == 0 if the max rate is set
to the "magic" 38400 rate and the SPD_* flags are also specified.
On the first iteration, if the current baud rate is higher than the
max, the baud rate is clamped at the max (which in the degenerate
case is 38400). On the second iteration, the now-"magic" 38400 baud
rate selects the possibly higher alternate baud rate indicated by
the SPD_* flag. Since only two loop iterations are performed, the
loop is exited, a kernel WARNING is generated and a baud rate of
0 is returned.

Reproducible with:
 setserial /dev/ttyS0 spd_hi base_baud 38400

Only perform the "magic" 38400 -> SPD_* baud transform on the first
loop iteration, which prevents the degenerate case from recognizing
the clamped baud rate as the "magic" 38400 value.
Reported-by: NRobert Święcki <robert@swiecki.net>
Cc: <stable@vger.kernel.org> # all
Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The USB OTG port does not work since v3.16 on omap platform.
This is a regression introduced by the commit
eb82a3d8 (phy: omap-usb2: Balance pm_runtime_enable() on probe failure
 and remove).
This because the call to pm_runtime_enable() function is moved after the
call to devm_phy_create() function, which has side effect since later in
the subsequent calls of devm_phy_create() there is a check with
pm_runtime_enabled() to configure few things.

Fixes: eb82a3d8Signed-off-by: NOussama Ghorbel <ghorbel@pivasoftware.com>
Tested-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The timeout argument to usb_stor_control_msg() is specified in jiffies, not
milliseconds.
Signed-off-by: NMark Knibbs <markk@clara.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Make sure to only raise DTR on transitions from B0 in set_termios.

Also allow set_termios to be called from open with a termios_old of
NULL. Note that DTR will not be raised prematurely in this case.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit bda9893c as it was
incorrect.
Reported-by: NMark Knibbs <markk@clara.co.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>