Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 20 6月, 2013 8 次提交
  3. 19 6月, 2013 2 次提交
  5. 18 6月, 2013 6 次提交
  7. 17 6月, 2013 1 次提交
  9. 14 6月, 2013 8 次提交
    • T
      mei: me: clear interrupts on the resume path · 42f132fe
      由 Tomas Winkler 提交于 
      We need to clear pending interrupts on the resume
path. This brings the device into defined state
before starting the reset flow

This should solve suspend/resume issues:

mei_me : wait hw ready failed. status = 0x0
mei_me : version message write failed
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42f132fe
    • T
      mei: nfc: fix nfc device freeing · 2753ff53
      由 Tomas Winkler 提交于 
      The nfc_dev is a static variable and is not cleaned properly upon reset
mainly ndev->cl and ndev->cl_info are not set to NULL after freeing which

mei_stop:198: mei_me 0000:00:16.0: stopping the device.
[  404.253427] general protection fault: 0000 [#2] SMP
[  404.253437] Modules linked in: mei_me(-) binfmt_misc snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device edd af_packet cpufreq_conservative cpufreq_userspace cpufreq_powersave fuse loop dm_mod hid_generic usbhid hid coretemp acpi_cpufreq mperf kvm_intel kvm crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128mul snd_hda_codec_hdmi glue_helper aes_x86_64 e1000e snd_hda_intel snd_hda_codec ehci_pci iTCO_wdt iTCO_vendor_support ehci_hcd snd_hwdep xhci_hcd snd_pcm usbcore ptp mei sg microcode snd_timer pps_core i2c_i801 snd pcspkr battery rtc_cmos lpc_ich mfd_core soundcore usb_common snd_page_alloc ac ext3 jbd mbcache drm_kms_helper drm intel_agp i2c_algo_bit intel_gtt i2c_core sd_mod crc_t10dif thermal fan video button processor thermal_sys hwmon ahci libahci libata scsi_mod [last unloaded: mei_me]
[  404.253591] CPU: 0 PID: 5551 Comm: modprobe Tainted: G      D W    3.10.0-rc3 #1
[  404.253611] task: ffff880143cd8300 ti: ffff880144a2a000 task.ti: ffff880144a2a000
[  404.253619] RIP: 0010:[<ffffffff81334e5d>]  [<ffffffff81334e5d>] device_del+0x1d/0x1d0
[  404.253638] RSP: 0018:ffff880144a2bcf8  EFLAGS: 00010206
[  404.253645] RAX: 2020302e30202030 RBX: ffff880144fdb000 RCX: 0000000000000086
[  404.253652] RDX: 0000000000000001 RSI: 0000000000000086 RDI: ffff880144fdb000
[  404.253659] RBP: ffff880144a2bd18 R08: 0000000000000651 R09: 0000000000000006
[  404.253666] R10: 0000000000000651 R11: 0000000000000006 R12: ffff880144fdb000
[  404.253673] R13: ffff880149371098 R14: ffff880144482c00 R15: ffffffffa04710e0
[  404.253681] FS:  00007f251c59a700(0000) GS:ffff88014e200000(0000) knlGS:0000000000000000
[  404.253689] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  404.253696] CR2: ffffffffff600400 CR3: 0000000145319000 CR4: 00000000001407f0
[  404.253703] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  404.253710] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  404.253716] Stack:
[  404.253720]  ffff880144fdb000 ffff880143ffe000 ffff880149371098 ffffffffa0471000
[  404.253732]  ffff880144a2bd38 ffffffff8133502d ffff88014e20cf48 ffff880143ffe1d8
[  404.253744]  ffff880144a2bd48 ffffffffa02a4749 ffff880144a2bd58 ffffffffa02a4ba1
[  404.253755] Call Trace:
[  404.253766]  [<ffffffff8133502d>] device_unregister+0x1d/0x60
[  404.253787]  [<ffffffffa02a4749>] mei_cl_remove_device+0x9/0x10 [mei]
[  404.253804]  [<ffffffffa02a4ba1>] mei_nfc_host_exit+0x21/0x30 [mei]
[  404.253819]  [<ffffffffa029c2dd>] mei_stop+0x3d/0x90 [mei]
[  404.253830]  [<ffffffffa046e220>] mei_me_remove+0x60/0xe0 [mei_me]
[  404.253843]  [<ffffffff81278f37>] pci_device_remove+0x37/0xb0
[  404.253855]  [<ffffffff81337c68>] __device_release_driver+0x98/0x100
[  404.253865]  [<ffffffff81337d80>] driver_detach+0xb0/0xc0
[  404.253876]  [<ffffffff81336b4f>] bus_remove_driver+0x8f/0x120
[  404.253891]  [<ffffffff81075990>] ? try_to_wake_up+0x2b0/0x2b0
[  404.253903]  [<ffffffff81338a48>] driver_unregister+0x58/0x90
[  404.253913]  [<ffffffff8127906b>] pci_unregister_driver+0x2b/0xb0
[  404.253924]  [<ffffffffa046f244>] mei_me_driver_exit+0x10/0xdcc [mei_me]
[  404.253936]  [<ffffffff810a50d8>] SyS_delete_module+0x198/0x2b0
[  404.253949]  [<ffffffff814850d9>] ? do_page_fault+0x9/0x10
[  404.253961]  [<ffffffff81489692>] system_call_fastpath+0x16/0x1b
[  404.253967] Code: 41 5c 41 5d 41 5e 41 5f c9 c3 0f 1f 40 00 55 48 89 e5 41 56 41 55 41 54 49 89 fc 53 48 8b 87 88 00 00 00 4c 8b 37 48 85 c0 74 18 <48> 8b 78 78 4c 89 e2 be 02 00 00 00 48 81 c7 f8 00 00 00 e8 3b
[  404.254048] RIP  [<ffffffff81334e5d>] device_del+0x1d/0x1d0

Cc: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2753ff53
    • S
      mei: init: Flush scheduled work before resetting the device · 5e85b364
      由 Samuel Ortiz 提交于 
      Flushing pending work items before resetting the device makes more
sense than doing so afterwards. Some of them, like e.g. the NFC
initialization one, find themselves with client IDs changed after
the reset, eventually leading to trigger a client.c:mei_me_cl_by_id()
warning after a few modprobe/rmmod cycles.
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e85b364
    • B
      netiucv: Hold rtnl between name allocation and device registration. · aaf9522d
      由 Benjamin Poirier 提交于 
      fixes a race condition between concurrent initializations of netiucv devices
that try to use the same name.

sysfs: cannot create duplicate filename '/devices/iucv/netiucv2'
[...]
Call Trace:
([<00000000002edea4>] sysfs_add_one+0xb0/0xdc)
 [<00000000002eecd4>] create_dir+0x80/0xfc
 [<00000000002eee38>] sysfs_create_dir+0xe8/0x118
 [<00000000003835a8>] kobject_add_internal+0x120/0x2d0
 [<00000000003839d6>] kobject_add+0x62/0x9c
 [<00000000003d9564>] device_add+0xcc/0x510
 [<000003e00212c7b4>] netiucv_register_device+0xc0/0x1ec [netiucv]
Signed-off-by: NBenjamin Poirier <bpoirier@suse.de>
Tested-by: NUrsula Braun <braunu@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aaf9522d
    • N
      tulip: Properly check dma mapping result · c9bfbb31
      由 Neil Horman 提交于 
      Tulip throws an error when dma debugging is enabled, as it doesn't properly
check dma mapping results with dma_mapping_error() durring tx ring refills.

Easy fix, just add it in, and drop the frame if the mapping is bad
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: Grant Grundler <grundler@parisc-linux.org>
CC: "David S. Miller" <davem@davemloft.net>
Reviewed-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c9bfbb31
    • B
      of: Fix locking vs. interrupts · d25d8694
      由 Benjamin Herrenschmidt 提交于 
      The OF code uses irqsafe locks everywhere except in a handful of functions
for no obvious reasons. Since the conversion from the old rwlocks, this
now triggers lockdep warnings when used at interrupt time. At least one
driver (ibmvscsi) seems to be doing that from softirq context.

This converts the few non-irqsafe locks into irqsafe ones, making them
consistent with the rest of the code.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      d25d8694
    • A
      brcmfmac: free primary net_device when brcmf_bus_start() fails · fcb37018
      由 Arend van Spriel 提交于 
      When initialization within brcmf_bus_start() fails on steps
before the brcmf_net_attach() the net_device for the primary
interface needs to be freed.

This patch resolves a panic during kernel boot as reported
by Stephen Warren.

ref.: http://mid.gmane.org/51AD1F22.2080004@wwwdotorg.orgTested-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NHante Meuleman <meuleman@broadcom.com>
Reviewed-by: NPieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: NArend van Spriel <arend@broadcom.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fcb37018
    • D
      Bluetooth: btmrvl: fix thread stopping race · ea05fea9
      由 Daniel Drake 提交于 
      There is currently a race condition in the btmrvl_remove_card() which
is causing hangs on suspend for OLPC. When the race occurs,
kthread_stop() never returns.

The problem is that btmrvl_service_main_thread() calls kthread_should_stop()
and then does a fair number of things before restarting the loop and
sleeping.

If the thread gets stopped after kthread_should_stop() is checked, but
before the sleep happens, the thread will go to sleep and won't necessarily
be woken up.

Move the kthread_should_stop() check into a race-free place.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ea05fea9
  11. 13 6月, 2013 15 次提交
    • Y
      net: sh_eth: fix incorrect RX length error if R8A7740 · dd019897
      由 Yoshihiro Shimoda 提交于 
      This patch fixes an issue that the driver increments the "RX length error"
on every buffer in sh_eth_rx() if the R8A7740.
This patch also adds a description about the Receive Frame Status bits.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dd019897
    • M
      drivers: net: davinci_mdio: restore mdio clk divider in mdio resume · cc60ab0a
      由 Mugunthan V N 提交于 
      During suspend resume cycle all the register data is lost, so MDIO
clock divier value gets reset. This patch restores the clock divider
value.
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cc60ab0a
    • M
      drivers: net: davinci_mdio: moving mdio resume earlier than cpsw ethernet driver · 5033ec3e
      由 Mugunthan V N 提交于 
      MDIO driver should resume before CPSW ethernet driver so that CPSW connect
to the phy and start tx/rx ethernet packets, changing the suspend/resume
apis with suspend_late/resume_early.
Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5033ec3e
    • N
      tg3: Wait for boot code to finish after power on · df465abf
      由 Nithin Sujir 提交于 
      Some systems that don't need wake-on-lan may choose to power down the
chip on system standby. Upon resume, the power on causes the boot code
to startup and initialize the hardware. On one new platform, this is
causing the device to go into a bad state due to a race between the
driver and boot code, once every several hundred resumes. The same race
exists on open since we come up from a power on.

This patch adds a wait for boot code signature at the beginning of
tg3_init_hw() which is common to both cases. If there has not been a
power-off or the boot code has already completed, the signature will be
present and poll_fw() returns immediately. Also return immediately if
the device does not have firmware.

Cc: stable@vger.kernel.org
Signed-off-by: NNithin Nayak Sujir <nsujir@broadcom.com>
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      df465abf
    • N
      bonding: fix igmp_retrans type and two related races · 4f5474e7
      由 Nikolay Aleksandrov 提交于 
      First the type of igmp_retrans (which is the actual counter of
igmp_resend parameter) is changed to u8 to be able to store values up
to 255 (as per documentation). There are two races that were hidden
there and which are easy to trigger after the previous fix, the first is
between bond_resend_igmp_join_requests and bond_change_active_slave
where igmp_retrans is set and can be altered by the periodic. The second
race condition is between multiple running instances of the periodic
(upon execution it can be scheduled again for immediate execution which
can cause the counter to go < 0 which in the unsigned case leads to
unnecessary igmp retransmissions).
Since in bond_change_active_slave bond->lock is held for reading and
curr_slave_lock for writing, we use curr_slave_lock for mutual
exclusion. We can't drop them as there're cases where RTNL is not held
when bond_change_active_slave is called. RCU is unlocked in
bond_resend_igmp_join_requests before getting curr_slave_lock since we
don't need it there and it's pointless to delay.
The decrement is moved inside the "if" block because if we decrement
unconditionally there's still a possibility for a race condition although
it is much more difficult to hit (many changes have to happen in
a very short period in order to trigger) which in the case of 3 parallel
running instances of this function and igmp_retrans == 1
(with check bond->igmp_retrans-- > 1) is:
f1 passes, doesn't re-schedule, but decrements - igmp_retrans = 0
f2 then passes, doesn't re-schedule, but decrements - igmp_retrans = 255
f3 does the unnecessary retransmissions.
Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f5474e7
    • N
      bonding: reset master mac on first enslave failure · b8fad459
      由 Nikolay Aleksandrov 提交于 
      If the bond device is supposed to get the first slave's MAC address and
the first enslavement fails then we need to reset the master's MAC
otherwise it will stay the same as the failed slave device. We do it
after err_undo_flags since that is the first place where the MAC can be
changed and we check if it should've been the first slave and if the
bond's MAC was set to it because that err place is used by multiple
locations prior to changing the master's MAC address.
Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8fad459
    • D
      net: ethernet: stmicro: stmmac: Fix compile error when STMMAC_XMIT_DEBUG used · 631f24a2
      由 Dinh Nguyen 提交于 
      drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function:
stmmac_xmit drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:1902:74:
error: expected ) before __func__
Signed-off-by: NDinh Nguyen <dinguyen@altera.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      631f24a2
    • S
      be2net: Fix 32-bit DMA Mask handling · 0c5fed09
      由 Somnath Kotur 提交于 
      Fix to set the coherent DMA mask only if dma_set_mask() succeeded, and to
error out if either fails.
Signed-off-by: NSomnath Kotur <somnath.kotur@emulex.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c5fed09
    • J
      xen-netback: don't de-reference vif pointer after having called xenvif_put() · 94f950c4
      由 Jan Beulich 提交于 
      When putting vif-s on the rx notify list, calling xenvif_put() must be
deferred until after the removal from the list and the issuing of the
notification, as both operations dereference the pointer.

Changing this got me to notice that the "irq" variable was effectively
unused (and was of too narrow type anyway).
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94f950c4
    • M
      macvlan: don't touch promisc without passthrough · 99ffc3e7
      由 Michael S. Tsirkin 提交于 
      commit df8ef8f3
"macvlan: add FDB bridge ops and macvlan flags"
added a way to control NOPROMISC macvlan flag through netlink.

However, with a non passthrough device we never set promisc on open,
even if NOPROMISC is off.  As a result:

If userspace clears NOPROMISC on open, then does not clear it on a
netlink command, promisc counter is not decremented on stop and there
will be no way to clear it once macvlan is detached.

If userspace does not clear NOPROMISC on open, then sets NOPROMISC on a
netlink command, promisc counter will be decremented from 0 and overflow
to fffffffff with no way to clear promisc.

To fix, simply ignore NOPROMISC flag in a netlink command for
non-passthrough devices, same as we do at open/close.

Since we touch this code anyway - check dev_set_promiscuity return code
and pass it to users (though an error here is unlikely).

Cc: "David S. Miller" <davem@davemloft.net>
Reviewed-by: NJohn Fastabend <john.r.fastabend@intel.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99ffc3e7
    • H
      md/raid1,5,10: Disable WRITE SAME until a recovery strategy is in place · 5026d7a9
      由 H. Peter Anvin 提交于 
      There are cases where the kernel will believe that the WRITE SAME
command is supported by a block device which does not, in fact,
support WRITE SAME.  This currently happens for SATA drivers behind a
SAS controller, but there are probably a hundred other ways that can
happen, including drive firmware bugs.

After receiving an error for WRITE SAME the block layer will retry the
request as a plain write of zeroes, but mdraid will consider the
failure as fatal and consider the drive failed.  This has the effect
that all the mirrors containing a specific set of data are each
offlined in very rapid succession resulting in data loss.

However, just bouncing the request back up to the block layer isn't
ideal either, because the whole initial request-retry sequence should
be inside the write bitmap fence, which probably means that md needs
to do its own conversion of WRITE SAME to write zero.

Until the failure scenario has been sorted out, disable WRITE SAME for
raid1, raid5, and raid10.

[neilb: added raid5]

This patch is appropriate for any -stable since 3.7 when write_same
support was added.

Cc: stable@vger.kernel.org
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      5026d7a9
    • N
      md/raid1,raid10: use freeze_array in place of raise_barrier in various places. · e2d59925
      由 NeilBrown 提交于 
      Various places in raid1 and raid10 are calling raise_barrier when they
really should call freeze_array.
The former is only intended to be called from "make_request".
The later has extra checks for 'nr_queued' and makes a call to
flush_pending_writes(), so it is safe to call it from within the
management thread.

Using raise_barrier will sometimes deadlock.  Using freeze_array
should not.

As 'freeze_array' currently expects one request to be pending (in
handle_read_error - the only previous caller), we need to pass
it the number of pending requests (extra) to ignore.

The deadlock was made particularly noticeable by commits
050b6615 (raid10) and 6b740b8d (raid1) which
appeared in 3.4, so the fix is appropriate for any -stable
kernel since then.

This patch probably won't apply directly to some early kernels and
will need to be applied by hand.

Cc: stable@vger.kernel.org
Reported-by: NAlexander Lyakas <alex.bolshoy@gmail.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      e2d59925
    • A
      md/raid1: consider WRITE as successful only if at least one non-Faulty and... · 3056e3ae
      由 Alex Lyakas 提交于 
      md/raid1: consider WRITE as successful only if at least one non-Faulty and non-rebuilding drive completed it.

Without that fix, the following scenario could happen:

- RAID1 with drives A and B; drive B was freshly-added and is rebuilding
- Drive A fails
- WRITE request arrives to the array. It is failed by drive A, so
r1_bio is marked as R1BIO_WriteError, but the rebuilding drive B
succeeds in writing it, so the same r1_bio is marked as
R1BIO_Uptodate.
- r1_bio arrives to handle_write_finished, badblocks are disabled,
md_error()->error() does nothing because we don't fail the last drive
of raid1
- raid_end_bio_io()  calls call_bio_endio()
- As a result, in call_bio_endio():
        if (!test_bit(R1BIO_Uptodate, &r1_bio->state))
                clear_bit(BIO_UPTODATE, &bio->bi_flags);
this code doesn't clear the BIO_UPTODATE flag, and the whole master
WRITE succeeds, back to the upper layer.

So we returned success to the upper layer, even though we had written
the data onto the rebuilding drive only. But when we want to read the
data back, we would not read from the rebuilding drive, so this data
is lost.

[neilb - applied identical change to raid10 as well]

This bug can result in lost data, so it is suitable for any
-stable kernel.

Cc: stable@vger.kernel.org
Signed-off-by: NAlex Lyakas <alex@zadarastorage.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      3056e3ae
    • N
      md: md_stop_writes() should always freeze recovery. · 6b6204ee
      由 NeilBrown 提交于 
      __md_stop_writes() will currently sometimes freeze recovery.
So any caller must be ready for that to happen, and indeed they are.

However if __md_stop_writes() doesn't freeze_recovery, then
a recovery could start before mddev_suspend() is called, which
could be awkward.  This can particularly cause problems or dm-raid.

So change __md_stop_writes() to always freeze recovery.  This is safe
and more predicatable.
Reported-by: NBrassow Jonathan <jbrassow@redhat.com>
Tested-by: NBrassow Jonathan <jbrassow@redhat.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
      6b6204ee
    • D
      drivers/misc/sgi-gru/grufile.c: fix info leak in gru_get_config_info() · 282c4c0e
      由 Dan Carpenter 提交于 
      The "info.fill" array isn't initialized so it can leak uninitialized stack
information to user space.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NRobin Holt <holt@sgi.com>
Acked-by: NDimitri Sivanich <sivanich@sgi.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      282c4c0e