1. 12 Nov, 2015 2 commits
    • Mark Yao's avatar
      Revert "drm/rockchip: Convert the probe function to the generic drm_of_component_probe()" · 5bad7d29
      Mark Yao authored
      This reverts commit 52f5eb60
      
      .
      
      Rockchip drm can't work with generic drm_of_component_probe now
      Signed-off-by: default avatarMark Yao <mark.yao@rock-chips.com>
      Acked-by: default avatarLiviu Dudau <Liviu.Dudau@arm.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      5bad7d29
    • Ville Syrjälä's avatar
      drm: Don't oops in drm_calc_timestamping_constants() if drm_vblank_init() wasn't called · 0c545ac4
      Ville Syrjälä authored
      Seems the crtc helpers call drm_calc_timestamping_constants()
      unconditionally even if the driver didn't initialize vblank support by
      calling drm_vblank_init(). That used to be OK since the constants were
      stored under drm_crtc.
      
      However I broke this with
      commit eba1f35d
      
       ("drm: Move timestamping constants into drm_vblank_crtc")
      when I moved the constants to live inside the drm_vblank_crtc struct
      instead. If drm_vblank_init() isn't called, we don't allocate these
      structures, and so drm_calc_timestamping_constants() will oops.
      
      Fix it by adding a check into drm_calc_timestamping_constants() to see
      if vblank support was initialized at all. And to keep in line with other
      such checks, also toss in a check and warn for the case where vblank
      support was initialized, but the wrong number of crtcs was specified.
      
      Fixes the following sort of oops:
       BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0
       IP: [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
       PGD 0
       Oops: 0002 [#1] SMP
       Modules linked in: sr_mod cdrom mgag200(+) i2c_algo_bit drm_kms_helper ahci syscopyarea sysfillrect sysimgblt libahci fb_sys_fops bnx2x ttm tg3(+) mdio drm ptp sd_mod libata i2c_core pps_core libcrc32c hpsa dm_mirror dm_region_hash dm_log dm_mod
       CPU: 0 PID: 418 Comm: kworker/0:2 Not tainted 4.3.0+ #1
       Hardware name: HP ProLiant DL380 Gen9, BIOS P89 06/09/2015
       Workqueue: events work_for_cpu_fn
       task: ffff88046ca95500 ti: ffff88007830c000 task.ti: ffff88007830c000
       RIP: 0010:[<ffffffffa014b266>]  [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
       RSP: 0018:ffff88007830f4e8  EFLAGS: 00010246
       RAX: 0000000000fe4c00 RBX: ffff88006a849160 RCX: 0000000000000540
       RDX: 0000000000000000 RSI: 000000000000fde8 RDI: ffff88006a849000
       RBP: ffff88007830f518 R08: ffff88007830c000 R09: 00000001b87e3712
       R10: 00000000000050c4 R11: 0000000000000000 R12: 0000000000fe4c00
       R13: ffff88006a849000 R14: 0000000000000000 R15: 000000000000fde8
       FS:  0000000000000000(0000) GS:ffff88046f800000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00000000000000b0 CR3: 00000000019d6000 CR4: 00000000001406f0
       Stack:
        ffff88007830f518 ffff88006a849000 ffff880c69b90340 ffff880c69b90000
        ffff880c69b90348 ffff880c69b90340 ffff88007830f748 ffffffffa042f7e7
        ffff88006a849090 0000000000000000 ffff88006a849160 0000000000000000
       Call Trace:
        [<ffffffffa042f7e7>] drm_crtc_helper_set_mode+0x3d7/0x4b0 [drm_kms_helper]
        [<ffffffffa04307d4>] drm_crtc_helper_set_config+0x8d4/0xb10 [drm_kms_helper]
        [<ffffffffa01548d4>] drm_mode_set_config_internal+0x64/0x100 [drm]
        [<ffffffffa043c342>] drm_fb_helper_pan_display+0xa2/0x280 [drm_kms_helper]
        [<ffffffff81392c7b>] fb_pan_display+0xbb/0x170
        [<ffffffff8138cf70>] bit_update_start+0x20/0x50
        [<ffffffff8138b81b>] fbcon_switch+0x39b/0x590
        [<ffffffff8140a3d0>] redraw_screen+0x1a0/0x240
        [<ffffffff8140b30e>] do_bind_con_driver+0x2ee/0x310
        [<ffffffff8140b651>] do_take_over_console+0x141/0x1b0
        [<ffffffff81387377>] do_fbcon_takeover+0x57/0xb0
        [<ffffffff8138c98b>] fbcon_event_notify+0x60b/0x750
        [<ffffffff810a5599>] notifier_call_chain+0x49/0x70
        [<ffffffff810a58dd>] __blocking_notifier_call_chain+0x4d/0x70
        [<ffffffff810a5916>] blocking_notifier_call_chain+0x16/0x20
        [<ffffffff8139282b>] fb_notifier_call_chain+0x1b/0x20
        [<ffffffff81394881>] register_framebuffer+0x1f1/0x330
        [<ffffffffa043d9aa>] drm_fb_helper_initial_config+0x27a/0x3d0 [drm_kms_helper]
        [<ffffffffa0469b4d>] mgag200_fbdev_init+0xdd/0xf0 [mgag200]
        [<ffffffffa0468586>] mgag200_modeset_init+0x176/0x1e0 [mgag200]
        [<ffffffffa0464659>] mgag200_driver_load+0x3f9/0x580 [mgag200]
        [<ffffffffa014e067>] drm_dev_register+0xa7/0xb0 [drm]
        [<ffffffffa015054f>] drm_get_pci_dev+0x8f/0x1e0 [drm]
        [<ffffffffa046937b>] mga_pci_probe+0x9b/0xc0 [mgag200]
        [<ffffffff813662d5>] local_pci_probe+0x45/0xa0
        [<ffffffff8109afe4>] work_for_cpu_fn+0x14/0x20
        [<ffffffff8109e13c>] process_one_work+0x14c/0x3c0
        [<ffffffff8109eaa4>] worker_thread+0x244/0x470
        [<ffffffff8168bfba>] ? __schedule+0x2aa/0x760
        [<ffffffff8109e860>] ? rescuer_thread+0x310/0x310
        [<ffffffff810a4438>] kthread+0xd8/0xf0
        [<ffffffff810a4360>] ? kthread_park+0x60/0x60
        [<ffffffff8169030f>] ret_from_fork+0x3f/0x70
        [<ffffffff810a4360>] ? kthread_park+0x60/0x60
       Code: f6 31 d2 41 89 c2 8b 83 b4 00 00 00 0f af c1 48 98 48 69 c0 40 42 0f 00 48 f7 f6 f6 43 74 10 41 89 c4 75 26 f6 05 9a 6f 03 00 01 <45> 89 96 b0 00 00 00 45 89 a6 ac 00 00 00 75 35 48 83 c4 08 5b
       RIP  [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
        RSP <ffff88007830f4e8>
       CR2: 00000000000000b0
      
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Reported-by: default avatarJeff Moyer <jmoyer@redhat.com>
      References: http://lists.freedesktop.org/archives/dri-devel/2015-November/094217.html
      Fixes: eba1f35d
      
       ("drm: Move timestamping constants into drm_vblank_crtc")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      0c545ac4
  2. 11 Nov, 2015 5 commits
  3. 10 Nov, 2015 24 commits
  4. 09 Nov, 2015 9 commits
    • Justin Maggard's avatar
      net: mvneta: Fix memory use after free. · 8c94ddbc
      Justin Maggard authored
      
      
      After changing an interface's MTU, then bringing the interface down and
      back up again, I immediately saw tons of kernel messages like below.
      The reason for this bad behavior is mvneta_rxq_drop_pkts(), which calls
      dma_unmap_single() on already-freed memory.  So we need to switch the
      order of those two operations.
      
      [  152.388518] BUG: Bad page state in process ifconfig  pfn:1b518
      [  152.388526] page:dff3dbc0 count:0 mapcount:0 mapping:  (null) index:0x0
      [  152.395178] flags: 0x200(arch_1)
      [  152.398441] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
      [  152.398446] bad because of flags:
      [  152.398450] flags: 0x200(arch_1)
      [  152.401716] Modules linked in:
      [  152.401728] CPU: 0 PID: 1453 Comm: ifconfig Tainted: P    B      O    4.1.12.armada.1 #1
      [  152.401733] Hardware name: Marvell Armada 370/XP (Device Tree)
      [  152.401749] [<c0015b1c>] (unwind_backtrace) from [<c0011d8c>] (show_stack+0x10/0x14)
      [  152.401762] [<c0011d8c>] (show_stack) from [<c06aa68c>] (dump_stack+0x74/0x90)
      [  152.401772] [<c06aa68c>] (dump_stack) from [<c0096c08>] (bad_page+0xc4/0x124)
      [  152.401783] [<c0096c08>] (bad_page) from [<c0099378>] (get_page_from_freelist+0x4e4/0x644)
      [  152.401794] [<c0099378>] (get_page_from_freelist) from [<c0099620>] (__alloc_pages_nodemask+0x148/0x784)
      [  152.401805] [<c0099620>] (__alloc_pages_nodemask) from [<c00ac658>] (kmalloc_order+0x10/0x20)
      [  152.401818] [<c00ac658>] (kmalloc_order) from [<c04c6f44>] (mvneta_rx_refill+0xc4/0xe8)
      [  152.401830] [<c04c6f44>] (mvneta_rx_refill) from [<c04c96c0>] (mvneta_setup_rxqs+0x298/0x39c)
      [  152.401842] [<c04c96c0>] (mvneta_setup_rxqs) from [<c04c9904>] (mvneta_open+0x3c/0x150)
      [  152.401853] [<c04c9904>] (mvneta_open) from [<c0597764>] (__dev_open+0xac/0x124)
      [  152.401864] [<c0597764>] (__dev_open) from [<c05979e4>] (__dev_change_flags+0x8c/0x148)
      [  152.401875] [<c05979e4>] (__dev_change_flags) from [<c0597ac0>] (dev_change_flags+0x18/0x48)
      [  152.401886] [<c0597ac0>] (dev_change_flags) from [<c060d308>] (devinet_ioctl+0x620/0x6d0)
      [  152.401897] [<c060d308>] (devinet_ioctl) from [<c057d810>] (sock_ioctl+0x64/0x288)
      [  152.401908] [<c057d810>] (sock_ioctl) from [<c00dcb7c>] (do_vfs_ioctl+0x78/0x608)
      [  152.401918] [<c00dcb7c>] (do_vfs_ioctl) from [<c00dd170>] (SyS_ioctl+0x64/0x74)
      [  152.401930] [<c00dd170>] (SyS_ioctl) from [<c000f3a0>] (ret_fast_syscall+0x0/0x3c)
      Signed-off-by: default avatarJustin Maggard <jmaggard@netgear.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c94ddbc
    • Jiri Slaby's avatar
      drivers/scsi/cxgbi: fix build with EXTRA_CFLAGS · ce1fb041
      Jiri Slaby authored
      
      
      EXTRA_CFLAGS are intended to be used on the command line, not by Kbuild.
      In case of cxgbi drivers, use of EXTRA_CFLAGS results in a compilation
      failure:
      
        drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:24:21: fatal error: t4_regs.h: No such file or directory
      
      when building like:
      
      $ make drivers/scsi/cxgbi/ EXTRA_CFLAGS=-Wwhatever
      
      Use ccflags-y instead of EXTRA_CFLAGS.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ce1fb041
    • Christoph Hellwig's avatar
      dma: remove external references to dma_supported · 0e77acef
      Christoph Hellwig authored
      
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0e77acef
    • Andrew Morton's avatar
      remove abs64() · 79211c8e
      Andrew Morton authored
      
      
      Switch everything to the new and more capable implementation of abs().
      Mainly to give the new abs() a bit of a workout.
      
      Cc: Michal Nazarewicz <mina86@mina86.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      79211c8e
    • Guenter Roeck's avatar
      drm/vc4: Add dependency on HAVE_DMA_ATTRS, and select DRM_GEM_CMA_HELPER · 2565df91
      Guenter Roeck authored
      
      
      Avoid the following build errors, seen with m68k:allmodconfig and other
      architectures which do not support HAVE_DMA_ATTRS.
      
      ERROR: "drm_gem_cma_create" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_prime_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_prime_get_sg_table" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_vm_ops" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_prime_vunmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_prime_import_sg_table" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_prime_vmap" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_dumb_map_offset" [drivers/gpu/drm/vc4/vc4.ko] undefined!
      ERROR: "drm_gem_cma_create" [drivers/gpu/drm/drm_kms_helper.ko] undefined!
      ERROR: "drm_gem_cma_describe" [drivers/gpu/drm/drm_kms_helper.ko] undefined!
      ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/drm_kms_helper.ko] undefined!
      Acked-by: default avatarEric Anholt <eric@anholt.net>
      Fixes: c8b75bca
      
       ("drm/vc4: Add KMS support for Raspberry Pi.")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      2565df91
    • Vlad Yasevich's avatar
      macvtap: Resolve possible __might_sleep warning in macvtap_do_read() · a499a2e9
      Vlad Yasevich authored
      
      
      macvtap_do_read code calls macvtap_put_user while it might be set up
      to wait for the user.  This results in the following warning:
      
      Jun 23 16:25:26 galen kernel: ------------[ cut here ]------------
      Jun 23 16:25:26 galen kernel: WARNING: CPU: 0 PID: 30433 at kernel/sched/core.c:
      7286 __might_sleep+0x7f/0x90()
      Jun 23 16:25:26 galen kernel: do not call blocking ops when !TASK_RUNNING; state
      =1 set at [<ffffffff810f1c1f>] prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: CPU: 0 PID: 30433 Comm: cat Not tainted 4.1.0-rc6+
       #11
      Jun 23 16:25:26 galen kernel: Call Trace:
      Jun 23 16:25:26 galen kernel: [<ffffffff817f76ba>] dump_stack+0x4c/0x65
      Jun 23 16:25:26 galen kernel: [<ffffffff810a07ca>] warn_slowpath_common+0x8a/0xc
      0
      Jun 23 16:25:26 galen kernel: [<ffffffff810a0846>] warn_slowpath_fmt+0x46/0x50
      Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ?  prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ?  prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff810cdc1f>] __might_sleep+0x7f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff811f8e15>] might_fault+0x55/0xb0
      Jun 23 16:25:26 galen kernel: [<ffffffff810fab9d>] ?  trace_hardirqs_on_caller+0x fd/0x1c0
      Jun 23 16:25:26 galen kernel: [<ffffffff813f639c>] copy_to_iter+0x7c/0x360
      Jun 23 16:25:26 galen kernel: [<ffffffffa052da86>] macvtap_do_read+0x256/0x3d0 [macvtap]
      Jun 23 16:25:26 galen kernel: [<ffffffff810f20e0>] ?  prepare_to_wait_event+0x110/0x110
      Jun 23 16:25:26 galen kernel: [<ffffffffa052dcab>] macvtap_read_iter+0x2b/0x50 [macvtap]
      Jun 23 16:25:26 galen kernel: [<ffffffff81247f2e>] __vfs_read+0xae/0xe0
      Jun 23 16:25:26 galen kernel: [<ffffffff81248526>] vfs_read+0x86/0x140
      Jun 23 16:25:26 galen kernel: [<ffffffff812493b9>] SyS_read+0x49/0xb0
      Jun 23 16:25:26 galen kernel: [<ffffffff8180182e>] system_call_fastpath+0x12/0x76
      Jun 23 16:25:26 galen kernel: ---[ end trace 22e33f67e70c0c2a ]---
      
      Make sure thet we call finish_wait() if we have the skb to process
      before trying to actually process it.
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a499a2e9
    • Arnd Bergmann's avatar
      mvneta: add FIXED_PHY dependency · 4bed5395
      Arnd Bergmann authored
      
      
      The fixed_phy infrastructure is done in a way that is optional,
      by providing 'static inline' helper functions doing nothing in
      include/linux/phy_fixed.h for all its APIs. However, three out
      of the four users (DSA, BCMGENET, and SYSTEMPORT) always
      'select FIXED_PHY', presumably because they need that.
      MVNETA is the fourth one, and if that is built-in but FIXED_PHY
      is configured as a loadable module, we get a link error:
      
      drivers/built-in.o: In function `mvneta_fixed_link_update':
      fpga-mgr.c:(.text+0x33ed80): undefined reference to `fixed_phy_update_state'
      
      Presumably this driver has the same dependency as the others,
      so this patch also uses 'select' to ensure that the fixed-phy
      support is built-in.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 898b2970
      
       ("mvneta: implement SGMII-based in-band link state signaling")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4bed5395
    • Rasmus Villemoes's avatar
      net: caif: check return value of alloc_netdev · cfb76d77
      Rasmus Villemoes authored
      
      
      I don't know if dev can actually be NULL here, but the test should be
      above alloc_netdev(), to avoid leaking the struct net_device in case
      dev is actually NULL. And of course the return value from alloc_netdev
      should be tested.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cfb76d77
    • Geert Uytterhoeven's avatar
      net: hisilicon: NET_VENDOR_HISILICON should depend on HAS_DMA · 3870502a
      Geert Uytterhoeven authored
      
      
      If NO_DMA=y:
      
          ERROR: "dma_set_mask" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_unmap_page" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_map_page" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_supported" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hns/hns_enet_drv.ko] undefined!
          ERROR: "dma_set_mask" [drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko] undefined!
          ERROR: "dma_supported" [drivers/net/ethernet/hisilicon/hns/hns_dsaf.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_unmap_page" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_map_page" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hns/hnae.ko] undefined!
          ERROR: "dma_alloc_coherent" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_free_coherent" [drivers/net/ethernet/hisilicon/hix5hd2_gmac.ko] undefined!
          ERROR: "dma_alloc_coherent" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_mapping_error" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_map_single" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_unmap_single" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
          ERROR: "dma_free_coherent" [drivers/net/ethernet/hisilicon/hip04_eth.ko] undefined!
      
      As this affects all of HNS_ENET, HNS_DSAF, HNS, HIX5HD2_GMAC, and
      HIP04_ETH, add a dependency on HAS_DMA to the main NET_VENDOR_HISILICON
      symbol to fix this.
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3870502a