Since 39b2bbe3 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.

Currently this parameter is made optional with the help of a cpp trick.
To allow dropping this hack convert callers to explictly pass a value
for flags.
Acked-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since 39b2bbe3 (gpio: add flags argument to gpiod_get*() functions)
which appeared in v3.17-rc1, the gpiod_get* functions take an additional
parameter that allows to specify direction and initial value for output.

Use this additional parameter and the _optional variant to simplify the
driver and improve error handling. Also expand the comment to explain
why it's not sensible to switch to devm_gpiod_get and why the gpiod_put
is also necessary.

Furthermore this is one caller less that stops us making the flags
argument to gpiod_get*() mandatory.
Tested-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).

Alter deprecated API as following:
- extcon_register_interest() -> extcon_register_notifier()
- extcon_get_cable_state(*edev, char *) -> extcon_get_cable_state_(*edev, id)

Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch removes the deprecated API of extcon and then use the new extcon API
with the unique id to indicate the each external connector (USB-HOST).
- extcon_get_cable_state(*edev, char *) -> extcon_get_cable_state_(*edev, id)

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Peter Chen <peter.chen@freescale.com>
Cc: Varka Bhadram <varkab@cdac.in>
Cc: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch uses the devm_extcon_dev_[allocate|register]() to manage the
resource automatically and replace deprecated API as following:
- extcon_[set|get]_cable_state(*edev, char *) -> extcon_[set|get]_cable_state_(*edev, id)

Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).

Alter deprecated API as following:
- extcon_register_interest() -> extcon_register_notifier()
- extcon_get_cable_state(*edev, char *) -> extcon_get_cable_state_(*edev, id)

[ balbi@ti.com : fix build break ]

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch removes the deprecated notifier API of extcon framwork
and then use the new extcon API with the unique id to indicate
the each external connector (USB, USB-HOST).

Alter deprecated API as following:
- extcon_register_interest() -> extcon_register_notifier()
- extcon_get_cable_state(*edev, char *) -> extcon_get_cable_state_(*edev, id)

Cc: Felipe Balbi <balbi@ti.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In big endian cases, the macro cpu_to_le{16,32} unfolds to __swab{16,32}
which provides special case for constants. In little endian cases,
__constant_cpu_to_le{16,32} and cpu_to_le{16,32} expand directly to
the same expression. So, replace __constant_cpu_to_le{16,32} with
cpu_to_le{16,32} with the goal of getting rid of the definition of
__constant_cpu_to_le{16,32} completely.

The semantic patch that performs this transformation is as follows:

@@expression x;@@

(
- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)
|
- __constant_cpu_to_le32(x)
+ cpu_to_le32(x)
)
Signed-off-by: NVaishali Thakkar <vthakkar1994@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

I18N should be spelled as i18n because it's not
an acronym
Signed-off-by: NDiego Viola <diego.viola@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In big endian cases, macro cpu_to_le16 unfolds to __swab16 which
provides special case for constants. In little endian cases,
__constant_cpu_to_le16 and cpu_to_le16 expand directly to the
same expression. So, replace __constant_cpu_to_le16 with
cpu_to_le16 with the goal of getting rid of the definition of
__constant_cpu_to_le16 completely.

The semantic patch that performs this transformation is as follows:

@@expression x;@@

- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)
Signed-off-by: NVaishali Thakkar <vthakkar1994@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As SourceSink function has been reworked for ConfigFS
composite gadget this comment is no longer valid.
Signed-off-by: NKrzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

As loopback function has been reworked for ConfigFS
composite gadget this comment is no longer valid.
Signed-off-by: NKrzysztof Opasiak <k.opasiak@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

now that we have no users of dev_dbg() in dwc3,
we can safely remove CONFIG_USB_DWC3_DEBUG.

If dev_dbg() is ever strictly necessary - and I
don't see why it would, considering we want to
rely on tracepoints for debug - we will depend
on DYNAMIC_PRINTK to enable such messages.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

the mode of operation is exposed through debugfs
at all times. Because of that, we're removing
the unnecessary messages.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

those two messages are informing that the clock
doesn't exist; that, however, is a valid situation
and driver continues just fine by ignoring the error.
Reviewed-by: NAndy Gross <agross@codeaurora.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

that message is informing that the clock is missing.
However, that's a valid condition for some setups; driver
even ignores the error and continues just fine.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

that's an error condition, not a debugging message.

Let's promote it appropriately.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Some of the messages were plain unnecessary
and some were actually errors. Fix it all
up.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

It's just a lot clearer to use | operator instead of
+ operator.

Caught by coccicheck:

	"
	drivers/usb/dwc2/gadget.c:2883:26-27: WARNING: sum of probable
	bitmasks, consider |
	"

Cc: John Youn <John.Youn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch adds removable mass storage support to g_nokia gadget (for N900).
It means that at runtime block device can be exported or unexported.
So it does not export anything by default and thus allows to use MyDocs
partition as before...

[ balbi@ti.com: make it build ]
Signed-off-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

An incorrect definition of CCR_PM_USBPW3 in ohci-tmio.c is a perennial
source of invalid diagnoses from static scanners, such as in
<http://marc.info/?l=linux-usb&m=143634574527641&w=2>.  This patch
fixes the definition.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NDavid Binderman <dcb314@hotmail.com>
CC: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Destroy acm_minors IDR on module exit, reclaiming the allocated memory.

This was detected by the following semantic patch (written by Luis Rodriguez
<mcgrof@suse.com>)
<SmPL>
@ defines_module_init @
declarer name module_init, module_exit;
declarer name DEFINE_IDR;
identifier init;
@@

module_init(init);

@ defines_module_exit @
identifier exit;
@@

module_exit(exit);

@ declares_idr depends on defines_module_init && defines_module_exit @
identifier idr;
@@

DEFINE_IDR(idr);

@ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
identifier declares_idr.idr, defines_module_exit.exit;
@@

exit(void)
{
 ...
 idr_destroy(&idr);
 ...
}

@ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @
identifier declares_idr.idr, defines_module_exit.exit;
@@

exit(void)
{
 ...
 +idr_destroy(&idr);
 }
</SmPL>
Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
Acked-by: NOliver Neukum <oneukum@suse.com>
Acked-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Grain-media GM12U320 based devices are mini video projectors using USB for
both power and video data transport.

Their usb-storage interface is a virtual windows driver CD.

The gm12u320 kms driver needs these interfaces to talk to the device and
export it as framebuffer & kms dri device nodes, so make sure that the
usb-storage driver does not bind to it.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This device automatically switches itself to another mode (0x1405)
unless the specific access pattern of Windows is followed in its
initial mode. That makes a dirty unmount of the internal storage
devices inevitable if they are mounted. So the card reader of
such a device should be ignored, lest an unclean removal become
inevitable.

This replaces an earlier patch that ignored all LUNs of this device.
That patch was overly broad.
Signed-off-by: NOliver Neukum <oneukum@suse.com>
CC: stable@vger.kernel.org
Reviewed-by: NLars Melin <larsm17@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch fixes a bug introduced by commit 977dcfdc ("USB: OHCI:
don't lose track of EDs when a controller dies").  The commit changed
ed_state from ED_UNLINK to ED_IDLE too early, before finish_urb() had
been called.  The user-visible consequence is that the driver
occasionally crashes or locks up when an URB is submitted while
another URB for the same endpoint is being unlinked.

This patch moves the ED state change later, to the right place.  The
drawback is that now we may unnecessarily execute some instructions
multiple times when a controller dies.  Since controllers dying is an
exceptional occurrence, a little wasted time won't matter.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Reported-by: NHeiko Przybyl <lil_tux@web.de>
Tested-by: NHeiko Przybyl <lil_tux@web.de>
Fixes: 977dcfdc
CC: <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 25cd2882 ("usb/xhci: Change how we indicate a host supports
Link PM.") removed the code to set lpm_capable for USB 3.0 super-speed
root hub. The intention of that change was to avoid touching usb core
internal field, a.k.a. lpm_capable, and let usb core to set it by
checking U1 and U2 exit latency values in the descriptor.

Usb core checks and sets lpm_capable in hub_port_init(). Unfortunately,
root hub is a special usb device as it has no parent. Hub_port_init()
will never be called for a root hub device. That means lpm_capable will
by no means be set for the root hub. As the result, lpm isn't functional
at all in Linux kernel.

This patch add the code to check and set lpm_capable when registering a
root hub device. It could be back-ported to kernels as old as v3.15,
that contains the Commit 25cd2882 ("usb/xhci: Change how we indicate
a host supports Link PM.").

Cc: stable@vger.kernel.org # 3.15
Reported-by: NKevin Strasser <kevin.strasser@linux.intel.com>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Port link change with port in resume state should not be
reported to usbcore, as this is an internal state to be
handled by xhci driver. Reporting PLC to usbcore may
cause usbcore clearing PLC first and port change event irq
won't be generated.

Cc: <stable@vger.kernel.org>
Signed-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When the link is just waken, it's in Resume state, and driver sets PLS to
U0. This refers to Phase 1. Phase 2 refers to when the link has completed
the transition from Resume state to U0.

With the fix of xhci: report U3 when link is in resume state, it also
exposes an issue that usb3 roothub and controller can suspend right
after phase 1, and this causes a hard hang in controller.

To fix the issue, we need to prevent usb3 bus suspend if any port is
resuming in phase 1.

[merge separate USB2 and USB3 port resume checking to one -Mathias]
Cc: <stable@vger.kernel.org>
Signed-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci_hub_report_usb3_link_state() returns pls as U0 when the link
is in resume state, and this causes usb core to think the link is in
U0 while actually it's in resume state. When usb core transfers
control request on the link, it fails with TRB error as the link
is not ready for transfer.

To fix the issue, report U3 when the link is in resume state, thus
usb core knows the link it's not ready for transfer.

Cc: <stable@vger.kernel.org>
Signed-off-by: NZhuang Jin Can <jin.can.zhuang@intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When resetting a device the number of active TTs may need to be
corrected by xhci_update_tt_active_eps, but the number of old active
endpoints supplied to it was always zero, so the number of TTs and the
bandwidth reserved for them was not updated, and could rise
unnecessarily.

This affected systems using Intel's Patherpoint chipset, which rely on
software bandwidth checking.  For example, a Lenovo X230 would lose the
ability to use ports on the docking station after enough suspend/resume
cycles because the bandwidth calculated would rise with every cycle when
a suitable device is attached.

The correct number of active endpoints is calculated in the same way as
in xhci_reserve_bandwidth.

Cc: <stable@vger.kernel.org>
Signed-off-by: NBrian Campbell <bacam@z273.org.uk>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

virt_dev->num_cached_rings counts on freed ring and is not updated
correctly. In xhci_free_or_cache_endpoint_ring() function, the free ring
is added into cache and then num_rings_cache is incremented as below:
		virt_dev->ring_cache[rings_cached] =
			virt_dev->eps[ep_index].ring;
		virt_dev->num_rings_cached++;
here, free ring pointer is added to a current index and then
index is incremented.
So current index always points to empty location in the ring cache.
For getting available free ring, current index should be decremented
first and then corresponding ring buffer value should be taken from ring
cache.

But In function xhci_endpoint_init(), the num_rings_cached index is
accessed before decrement.
		virt_dev->eps[ep_index].new_ring =
			virt_dev->ring_cache[virt_dev->num_rings_cached];
		virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
		virt_dev->num_rings_cached--;
This is bug in manipulating the index of ring cache.
And it should be as below:
		virt_dev->num_rings_cached--;
		virt_dev->eps[ep_index].new_ring =
			virt_dev->ring_cache[virt_dev->num_rings_cached];
		virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;

Cc: <stable@vger.kernel.org>
Signed-off-by: NAman Deep <aman.deep@samsung.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The xHCI in Intel CherryView / Braswell Platform requires
a driver workaround to get xHCI D3 working. Without this
workaround, xHCI might not enter D3.

Workaround is to configure SSIC PORT as "unused" before D3
entry and "used" after D3 exit. This is done through a
vendor specific register (PORT2_SSIC_CONFIG_REG2 at offset
0x883c), in xhci suspend / resume callbacks.

Verified xHCI D3 works fine in CherryView / Braswell platform.
Signed-off-by: NRajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Intel xhci hw that require XHCI_PME_STUCK quirk have as default disabled
xhci from going to D3 state in runtime suspend. Driver needs to verify
it can deal with the hw by calling an ACPI _DSM method to get D3 enabled.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This fixes an issue introduced in commit b23c8439 (usb: dwc3:
gadget: fix DEPSTARTCFG for non-EP0 EPs) that made sure we would
only use DEPSTARTCFG once per SetConfig.

The trick is that we should use one DEPSTARTCFG per SetConfig *OR*
SetInterface. SetInterface was completely missed from the original
patch.

This problem became aparent after commit 76e838c9 (usb: dwc3:
gadget: return error if command sent to DEPCMD register fails)
added checking of the return status of device endpoint commands.

'Set Endpoint Transfer Resource' command was caught failing
occasionally. This is because the Transfer Resource
Index was not getting reset during a SET_INTERFACE request.

Finally, to fix the issue, was we have to do is make sure that
our start_config_issued flag gets reset whenever we receive a
SetInterface request.

To verify the problem (and its fix), all we have to do is run
test 9 from testusb with 'testusb -t 9 -s 2048 -a -c 5000'.
Tested-by: NHuang Rui <ray.huang@amd.com>
Tested-by: NSubbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com>
Fixes: b23c8439 (usb: dwc3: gadget: fix DEPSTARTCFG for non-EP0 EPs)
Cc: <stable@vger.kernel.org> # v3.2+
Signed-off-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The dma_map_single and dma_unmap_single should set "gadget->dev.parent"
instead of "&gadget->dev" in the first argument because the parent has
a udc controller's device pointer.
Otherwise, iommu functions are not called in ARM environment.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

There was an omission in transition to devm_xxx resource handling.
iounmap(udc->phy_regs) were removed, but ioremap() was left
without devm_.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Fixes: 3517c31a ("usb: gadget: mv_udc: use devm_xxx for probe")
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Phy drivers and the ulpi interface providers depend on the
registration of the ulpi bus.  Ulpi registers the bus in
module_init(). This could cause unnecessary bus users'
probe delays. i.e. unnecessary -EPROBE_DEFER happening on
ulpi_drivers in case they're registered before ulpi bus
itself.
Reported-by: NZhuo Qiuxu <qiuxu.zhuo@intel.com>
Signed-off-by: NLu Baolu <baolu.lu@linux.intel.com>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Some modules call config_item_init_type_name() and config_group_init_type_name()
with parameter "name" directly controlled by userspace.  These two
functions call config_item_set_name() with this name used as a format
string, which can be used to leak information such as content of the
stack to userspace.

For example, make_netconsole_target() in netconsole module calls
config_item_init_type_name() with the name of a newly-created directory.
This means that the following commands give some unexpected output, with
configfs mounted in /sys/kernel/config/ and on a system with a
configured eth0 ethernet interface:

    # modprobe netconsole
    # mkdir /sys/kernel/config/netconsole/target_%lx
    # echo eth0 > /sys/kernel/config/netconsole/target_%lx/dev_name
    # echo 1 > /sys/kernel/config/netconsole/target_%lx/enabled
    # echo eth0 > /sys/kernel/config/netconsole/target_%lx/dev_name
    # dmesg |tail -n1
    [  142.697668] netconsole: target (target_ffffffffc0ae8080) is
    enabled, disable to update parameters

The directory name is correct but %lx has been interpreted in the
internal item name, displayed here in the error message used by
store_dev_name() in drivers/net/netconsole.c.

To fix this, update every caller of config_item_set_name to use "%s"
when operating on untrusted input.

This issue was found using -Wformat-security gcc flag, once a __printf
attribute has been added to config_item_set_name().
Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NJoel Becker <jlbec@evilplan.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Destroy serial_minors IDR on module exit, reclaiming the allocated memory.

This was detected by the following semantic patch (written by Luis
Rodriguez <mcgrof@suse.com>)

<SmPL>
@ defines_module_init @
declarer name module_init, module_exit;
declarer name DEFINE_IDR;
identifier init;
@@

module_init(init);

@ defines_module_exit @
identifier exit;
@@

module_exit(exit);

@ declares_idr depends on defines_module_init && defines_module_exit @
identifier idr;
@@

DEFINE_IDR(idr);

@ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
identifier declares_idr.idr, defines_module_exit.exit;
@@

exit(void)
{
 ...
 idr_destroy(&idr);
 ...
}

@ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @
identifier declares_idr.idr, defines_module_exit.exit;
@@

exit(void)
{
 ...
 +idr_destroy(&idr);
}
</SmPL>
Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
Cc: stable <stable@vger.kernel.org>	# v3.11
Signed-off-by: NJohan Hovold <johan@kernel.org>

In case kstrdup() fails the resources to release are
midi->in_port[] and midi. No cards have been registered,
so no need to unregister any.
Signed-off-by: NAndrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>