Commits · ae76e13477d8de0065cddbb6714e6b027562eaec · Kirill Smelkov / linux

04 Mar, 2016 33 commits

usb: f_fs: refactor ffs_epfile_io · ae76e134

Michal Nazarewicz authored Jan 04, 2016

Eliminate one of the return paths by using a ‘goto error_mutex’ and
rearrange some if-bodies which results in reduction of the indention level
and thus hopefully makes the function easier to read and reason about.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

ae76e134

usb: f_fs: replace unnecessary goto with a return · b3591f67

Michal Nazarewicz authored Jan 04, 2016

In ffs_epfile_io error label points to a return path which includes
a kfree(data) call.  However, at the beginning of the function data is
always NULL so some of the early ‘goto error’ can safely be replaced
with a trivial return statement.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

b3591f67

usb: f_fs: fix ffs_epfile_io returning success on req alloc failure · 3163c79e

Michal Nazarewicz authored Jan 04, 2016

In the AIO path, if allocating of a request failse, the function simply
goes to the error_lock path whose end result is returning value of ret.
However, at this point ret’s value is zero (assigned as return value from
ffs_mutex_lock).

Fix by adding ‘ret = -ENOMEM’ statement.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

3163c79e

usb: f_fs: fix memory leak when ep changes during transfer · 3de4e205

Michal Nazarewicz authored Jan 04, 2016

In the ffs_epfile_io function, data buffer is allocated for non-halt
requests. Later, after grabing a mutex, the function checks that
epfile->ep is still ep and if it’s not, it set ret to -ESHUTDOWN and
follow a path including spin_unlock_irq (just after ‘ret = -ESHUTDOWN’),
mutex_unlock (after if-else-if-else chain) and returns ret. Noticeably,
this does not include freeing of the data buffer.

Fix by introducing a goto which moves control flow to the the end of the
function where spin_unlock_irq, mutex_unlock and kfree are all called.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

3de4e205

usb: phy: phy-am335x: remove include of regulator/consumer.h · 12496785

Bjorn Helgaas authored Feb 02, 2016

phy-am335x.c doesn't use any interfaces from linux/regulator/consumer.h, so
stop including it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

12496785

usb: gadget: pxa25x_udc: document endianess better · a9458a3b

Arnd Bergmann authored Feb 17, 2016

When I wrote the cleanup patch series, it was not clear how
exactly big-endian mode works on ixp4xx, and whether the driver
was doing this correctly. After discussing with Krzysztof Hałasa,
this has been clarified, so I can update the comment let pxa25x
big-endian (which we don't support) work the same way as ixp4xx.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

a9458a3b

usb: musb/ux500: remove duplicate check for dma_is_compatible · 62a6abdd

Arnd Bergmann authored Jan 28, 2016

When dma_addr_t is 64-bit, we get a warning about an invalid cast
in the call to ux500_dma_is_compatible() from ux500_dma_channel_program():

drivers/usb/musb/ux500_dma.c: In function 'ux500_dma_channel_program':
drivers/usb/musb/ux500_dma.c:210:51: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
if (!ux500_dma_is_compatible(channel, packet_sz, (void *)dma_addr, len))

The problem is that ux500_dma_is_compatible() is called from the
main musb driver on the virtual address, but here we pass in a
DMA address, so the types are fundamentally different but it works
because the function only checks the alignment of the buffer and
that is the same.

We could work around this by adding another cast, but I have checked
that the buffer we get passed here is already checked before it
gets mapped, so the second check seems completely unnecessary
and removing it must be the cleanest solution.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

62a6abdd

usb: musb: use %pad format string from dma_addr_t · 3ec08ddf

Arnd Bergmann authored Jan 28, 2016

The musb driver prints DMA addresses in a few places, using the
0x%x format string. This is wrong on 64-bit architectures (which
need %lx) and 32-bit ARM with CONFIG_LPAE set (which needs
%llx), otherwise we print the wrong data, as gcc warns:

musb/musbhsdma.c: In function 'configure_channel':
musb/musbhsdma.c:120:53: error: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=]
  dev_dbg(musb->controller, "%p, pkt_sz %d, addr 0x%x, len %d, mode %d\n",
musb/musbhsdma.c: In function 'dma_channel_program':
musb/musbhsdma.c:155:53: error: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=]
  dev_dbg(musb->controller, "ep%d-%s pkt_sz %d, dma_addr 0x%x length %d, mode %d\n",
musb/tusb6010_omap.c: In function 'tusb_omap_dma_program':
musb/tusb6010_omap.c:313:53: error: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t {aka long long unsigned int}' [-Werror=format=]
  dev_dbg(musb->controller, "ep%i %s dma ch%i dma: %08x len: %u(%u) packet_sz: %i(%i)\n",

This uses the %pad format string, which prints a dma_addr_t that
gets passed by reference, which works for all combinations.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

3ec08ddf

usb: isp1301-omap: mark power_up as __maybe_unused · 5b35becc

Arnd Bergmann authored Jan 28, 2016

The power_up function is used for otg or udc mode, but nost when
the driver is only configured for host mode:

drivers/usb/phy/phy-isp1301-omap.c:261:13: error: 'power_up' defined but not used [-Werror=unused-function]

This marks the function __maybe_unused to avoid the warning and
silently drop the definition when it is unused.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

5b35becc

usb: fsl: drop USB_FSL_MPH_DR_OF Kconfig symbol · d0fc35bc

Arnd Bergmann authored Jan 28, 2016

The USB_FSL_MPH_DR_OF symbol is used to ensure the code that interprets
the DR device node is built whenever one of the two drivers (EHCI or
UDC) for the platform is enabled. However, if CONFIG_USB is disabled
and we only support gadget mode, this causes a Kconfig warning:

warning: (USB_FSL_USB2) selects USB_FSL_MPH_DR_OF which has unmet direct dependencies (USB_SUPPORT && USB)

We can avoid this warning by simply no longer using the symbol,
and making sure we enter the drivers/usb/host/ directory when
the UDC driver is enabled that needs the file, and then we use
Makefile syntax to ensure the file is built-in if needed.

There is currently a dependency on CONFIG_OF, but this is redundant,
as we already know that this is set unconditionally for the platforms
that use this driver.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

d0fc35bc

usb: gadget: pxa25x_udc: use readl/writel for mmio · 65bc0fba

Arnd Bergmann authored Jan 28, 2016

This converts the pxa25x udc driver to use readl/writel as normal
driver should do, rather than dereferencing __iomem pointers
themselves.

Based on the earlier preparation work, we can now also pass
the register start in the device pointer so we no longer need
the global variable.

The unclear part here is for IXP4xx, which supports both big-endian
and little-endian configurations. So far, the driver has done
no byteswap in either case. I suspect that is wrong and it would
actually need to swap in one or the other case, but I don't know
which. It's also possible that there is some magic setting in
the chip that makes the endianess of the MMIO register match the
CPU, and in that case, the code actually does the right thing
for all configurations, both before and after this patch.
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

65bc0fba

usb: gadget: pxa25x_udc cleanup · a77af20e

Arnd Bergmann authored Jan 28, 2016

This removes the dependency on the mach/hardware.h header file
from the pxa25x_udc driver after the register definitions were
already unified in the previous patch.

Following the model of pxa27x_udc (and basically all other drivers
in the kernel), we define the register numbers as offsets from
the register base address and use accessor functions to read/write
them.

For the moment, this still leaves the direct pointer dereference
in place, instead of using readl/writel, so this patch should
not be changing the behavior of the driver, other than using
ioremap() on the platform resource to replace the hardcoded
virtual address pointers.
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

a77af20e

usb: gadget: pxa25x_udc: move register definitions from arch · c5418a0b

Arnd Bergmann authored Jan 28, 2016

ixp4xx and pxa25x both use this driver and provide a slightly
different set of register definitions for it. Aside from that,
the definition in the ixp4xx-regs.h header conflicts with the
on in the pxa27x device driver when compile-testing that:

In file included from ../drivers/usb/gadget/udc/pxa27x_udc.c:37:0:
../drivers/usb/gadget/udc/pxa27x_udc.h:26:0: warning: "UDCCR" redefined
 #define UDCCR  0x0000  /* UDC Control Register */
 ^
In file included from ../arch/arm/mach-ixp4xx/include/mach/hardware.h:27:0,
                 from ../arch/arm/mach-ixp4xx/include/mach/io.h:18,
                 from ../arch/arm/include/asm/io.h:194,
                 from ../include/linux/io.h:25,
                 from ../include/linux/irq.h:24,
                 from ../drivers/usb/gadget/udc/pxa27x_udc.c:23:
../arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h:415:0: note: this is the location of the previous definition
 #define UDCCR  IXP4XX_USB_REG(IXP4XX_USB_BASE_VIRT+0x0000)

This addresses both issues by moving all the definitions into the
pxa25x_udc driver itself. It turns out the only difference between
them was 'UDCCS_IO_ROF', and that could well be a mistake when it
was incorrectly copied from pxa25x to ixp4xx.
Acked-by: Krzysztof Halasa <khalasa@piap.pl>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

c5418a0b

usb: renesas_usbhs: Don't check CSSTS bit if peripheral mode · 21a596c1

Yoshihiro Shimoda authored Feb 05, 2016

Since Some SoCs (e.g. R-Car Gen2) don't have the CSSTS bit in the
pipectrl registers ({DCP,PIPEn}CTR) because such SoCs have peripheral
mode only. So, this driver should not check the CSSTS bit if peripheral
mode is running.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

21a596c1

usb: renesas_usbhs: add R-Car Gen3 power control · de18757e

Yoshihiro Shimoda authored Jan 07, 2016

Since the usb2 phy driver for gen3 (phy-rcar-gen3-usb2) cannot access
LPSTS and UGCTRL2 registers in the HSUSB module, this driver have to
initialize the registers. So, this patch adds such handling code into
rcar3.c.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>

de18757e