Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 14
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 7月, 2016 4 次提交
  3. 15 6月, 2016 2 次提交
  5. 02 6月, 2016 24 次提交
  7. 27 4月, 2016 3 次提交
  9. 04 3月, 2016 4 次提交
    • P
      usb: musb: core: added missing const qualifier to musb_hdrc_platform_data::config · ead22caf
      由 Petr Kulhavy 提交于 
      The musb_hdrc_platform_data::config was defined as a non-const pointer.
However some drivers (e.g. the ux500) set up this pointer to point to a
static structure, which is potentially dangerous. Since the musb core
uses the pointer in a read-only manner the const qualifier was added to
protect the content of the config.
Signed-off-by: NPetr Kulhavy <petr@barix.com>
Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NBin Liu <b-liu@ti.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      ead22caf
    • E
      usb: musb: sunxi: support module autoloading · 5266a760
      由 Emilio López 提交于 
      MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on
sunxi systems using the OTG controller. This commit adds the missing
line so it loads automatically when building it as a module and running
on a system with an USB OTG port.
Signed-off-by: NEmilio López <emilio.lopez@collabora.co.uk>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      5266a760
    • A
      usb: musb/ux500: remove duplicate check for dma_is_compatible · 62a6abdd
      由 Arnd Bergmann 提交于 
      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: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      62a6abdd
    • A
      usb: musb: use %pad format string from dma_addr_t · 3ec08ddf
      由 Arnd Bergmann 提交于 
      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: NTony Lindgren <tony@atomide.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      3ec08ddf
  11. 03 3月, 2016 1 次提交
  13. 23 2月, 2016 1 次提交
  15. 17 2月, 2016 1 次提交