Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 7月, 2008 1 次提交
  3. 03 5月, 2008 1 次提交
    • S
      [SCSI] aic94xx: fix section mismatch · 7ad4a485
      由 Sam Ravnborg 提交于 
      Fix following warnings:
WARNING: vmlinux.o(.data+0x17aa88): Section mismatch in reference from the variable asd_pcidev_data to the function .devinit.text:asd_aic9410_setup()
WARNING: vmlinux.o(.data+0x17aa98): Section mismatch in reference from the variable asd_pcidev_data to the function .devinit.text:asd_aic9410_setup()
WARNING: vmlinux.o(.data+0x17aaa8): Section mismatch in reference from the variable asd_pcidev_data to the function .devinit.text:asd_aic9405_setup()

asd_pcidev_data is only used by __devinit asd_pci_probe.  So mark is const and
annotate it __devinitconst to fix the warnings.

[akpm@linux-foundation.org: fix warning]
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      7ad4a485
  5. 08 4月, 2008 2 次提交
  7. 24 2月, 2008 2 次提交
    • J
      [SCSI] aic94xx: fix TMF ascb handling to prevent sequencer panic · e2396f1e
      由 James Bottomley 提交于 
      This is a particularly nasty bug.  The problem is that if any internal
ascb times out, currently we free it even though it's pending at the
sequencer.  This results in the sequencer getting terminally confused
and the error message:

BUG:sequencer:dl:no ascb

Being returned when it comes back.  The way to fix this is to manage
freeing the ascb from the tasklet completion routine, so that we only
free it when the sequencer actually returns it.  The code is also
altered to use on stack completions and transfer variables.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      e2396f1e
    • J
      [SCSI] aic94xx: plumb in I_T_nexus_reset task management function · 63edf49e
      由 James Bottomley 提交于 
      Currently aic94xx has no exported I_T_nexus_reset function.  This is a
bit of a huge problem, since sas_ata relies on this function to
perform an ATA phy reset and also it means that if abort fails, we
really have no bigger hammer to hit everything with.

Plumb in the I_T_nexus_reset by quiescing the sequencer, sending the
correct phy reset (link for ATA and hard for SAS) and then carefully
resuming the sequencer again.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      63edf49e
  9. 23 2月, 2008 1 次提交
    • J
      [SCSI] aic94xx: fix sequencer hang on error recovery · 91b55060
      由 James Bottomley 提交于 
      The clear nexus I_T and clear nexus I_T_L functions in the aic94xx
specify the SUSPEND_TX flag which causes the sequencer to be suspended
until it receives a RESUME_TX.  Unfortunately, nothing ever sends the
resume, so the sequencer on the link is stopped forever, leading to
eventual timeouts and I/O errors.

Since clear nexus commands are only executed as part of error recovery,
it's perfectly fine to keep the sequencer running on the link ... as
soon as the recovery function is completed, we'll send it the commands
to retry.
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      91b55060
  11. 18 2月, 2008 1 次提交
    • J
      [SCSI] aic94xx: fix REQ_TASK_ABORT and REQ_DEVICE_RESET · cb84e2d2
      由 James Bottomley 提交于 
      This driver has been failing under heavy load with

aic94xx: escb_tasklet_complete: REQ_TASK_ABORT, reason=0x6
aic94xx: escb_tasklet_complete: Can't find task (tc=4) to abort!

The second message is because the driver fails to identify the task
it's being asked to abort.  On closer inpection, there's a thinko in
the for each task loop over pending tasks in both the REQ_TASK_ABORT
and REQ_DEVICE_RESET cases where it doesn't look at the task on the
pending list but at the one on the ESCB (which is always NULL).

Fix by looking at the right task.  Also add a print for the case where
the pending SCB doesn't have a task attached.

Not sure if this will fix all the problems, but it's a definite first
step.

Cc: Stable Tree <stable@kernel.org>
Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      cb84e2d2
  13. 12 2月, 2008 1 次提交
  15. 26 1月, 2008 1 次提交
  17. 12 1月, 2008 3 次提交
  19. 15 11月, 2007 1 次提交
    • A
      aic94xx_sds: rename FLASH_SIZE · d297a5d5
      由 Andrew Morton 提交于 
      arm:

drivers/scsi/aic94xx/aic94xx_sds.c:381:1: warning: "FLASH_SIZE" redefined
In file included from include/asm/arch/irqs.h:22,
                 from include/asm/irq.h:4,
                 from include/asm/hardirq.h:6,
                 from include/linux/hardirq.h:7,
                 from include/asm-generic/local.h:5,
                 from include/asm/local.h:1,
                 from include/linux/module.h:19,
                 from include/linux/device.h:21,
                 from include/linux/pci.h:52,
                 from drivers/scsi/aic94xx/aic94xx_sds.c:28:
include/asm/arch/platform.h:444:1: warning: this is the location of the previous definition

Cc: Gilbert Wu <gilbert_wu@adaptec.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d297a5d5
  21. 16 10月, 2007 1 次提交
  23. 13 10月, 2007 3 次提交
  25. 03 10月, 2007 1 次提交
  27. 26 7月, 2007 1 次提交
  29. 20 7月, 2007 1 次提交
    • P
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      由 Paul Mundt 提交于 
      Slab destructors were no longer supported after Christoph's
c59def9f change. They've been
BUGs for both slab and slub, and slob never supported them
either.

This rips out support for the dtor pointer from kmem_cache_create()
completely and fixes up every single callsite in the kernel (there were
about 224, not including the slab allocator definitions themselves,
or the documentation references).
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      20c2df83
  31. 19 7月, 2007 5 次提交
  33. 12 7月, 2007 1 次提交
    • A
      PCI: Change all drivers to use pci_device->revision · 44c10138
      由 Auke Kok 提交于 
      Instead of all drivers reading pci config space to get the revision
ID, they can now use the pci_device->revision member.

This exposes some issues where drivers where reading a word or a dword
for the revision number, and adding useless error-handling around the
read. Some drivers even just read it for no purpose of all.

In devices where the revision ID is being copied over and used in what
appears to be the equivalent of hotpath, I have left the copy code
and the cached copy as not to influence the driver's performance.

Compile tested with make all{yes,mod}config on x86_64 and i386.
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Acked-by: NDave Jones <davej@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      44c10138
  35. 23 5月, 2007 1 次提交
    • D
      [SCSI] aic94xx: asd_clear_nexus should fail if the cleared task does not complete · 8fdcf86a
      由 Darrick J. Wong 提交于 
      Every so often, the driver will call asd_clear_nexus to clean out a task.
It is supposed to be the case that the CLEAR NEXUS does not go on the done
list until after the task itself has been put on the done list, but for
some reason this doesn't always happen.  Thus, the
wait_for_completion_timeout call times out, and we return success.  This
makes libsas free the task even though the task hasn't completed, leading
to a BUG_ON message from aic94xx_hwi.c around line 341.  We should return
failure from asd_clear_nexus so that libsas tries again; at a bare minimum
it shouldn't be freeing active tasks.  I _think_ this will fix one of
the SCB timeout crash problems (though I've not been able to reproduce
it lately...)
Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      8fdcf86a
  37. 09 5月, 2007 1 次提交
  39. 03 5月, 2007 1 次提交
    • J
      PCI: Cleanup the includes of <linux/pci.h> · 6473d160
      由 Jean Delvare 提交于 
      I noticed that many source files include <linux/pci.h> while they do
not appear to need it. Here is an attempt to clean it all up.

In order to find all possibly affected files, I searched for all
files including <linux/pci.h> but without any other occurence of "pci"
or "PCI". I removed the include statement from all of these, then I
compiled an allmodconfig kernel on both i386 and x86_64 and fixed the
false positives manually.

My tests covered 66% of the affected files, so there could be false
positives remaining. Untested files are:

arch/alpha/kernel/err_common.c
arch/alpha/kernel/err_ev6.c
arch/alpha/kernel/err_ev7.c
arch/ia64/sn/kernel/huberror.c
arch/ia64/sn/kernel/xpnet.c
arch/m68knommu/kernel/dma.c
arch/mips/lib/iomap.c
arch/powerpc/platforms/pseries/ras.c
arch/ppc/8260_io/enet.c
arch/ppc/8260_io/fcc_enet.c
arch/ppc/8xx_io/enet.c
arch/ppc/syslib/ppc4xx_sgdma.c
arch/sh64/mach-cayman/iomap.c
arch/xtensa/kernel/xtensa_ksyms.c
arch/xtensa/platform-iss/setup.c
drivers/i2c/busses/i2c-at91.c
drivers/i2c/busses/i2c-mpc.c
drivers/media/video/saa711x.c
drivers/misc/hdpuftrs/hdpu_cpustate.c
drivers/misc/hdpuftrs/hdpu_nexus.c
drivers/net/au1000_eth.c
drivers/net/fec_8xx/fec_main.c
drivers/net/fec_8xx/fec_mii.c
drivers/net/fs_enet/fs_enet-main.c
drivers/net/fs_enet/mac-fcc.c
drivers/net/fs_enet/mac-fec.c
drivers/net/fs_enet/mac-scc.c
drivers/net/fs_enet/mii-bitbang.c
drivers/net/fs_enet/mii-fec.c
drivers/net/ibm_emac/ibm_emac_core.c
drivers/net/lasi_82596.c
drivers/parisc/hppb.c
drivers/sbus/sbus.c
drivers/video/g364fb.c
drivers/video/platinumfb.c
drivers/video/stifb.c
drivers/video/valkyriefb.c
include/asm-arm/arch-ixp4xx/dma.h
sound/oss/au1550_ac97.c

I would welcome test reports for these files. I am fine with removing
the untested files from the patch if the general opinion is that these
changes aren't safe. The tested part would still be nice to have.

Note that this patch depends on another header fixup patch I submitted
to LKML yesterday:
  [PATCH] scatterlist.h needs types.h
  http://lkml.org/lkml/2007/3/01/141Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6473d160
  41. 16 2月, 2007 1 次提交
    • J
      [SCSI] aic94xx: tie driver to the major number of the sequencer firmware · a29fdd3c
      由 James Bottomley 提交于 
      The sequencer firmware file has both a string (currently showing
V17/10c6) and a number (currently set to 1.1).  It has become apparent
that Adaptec may issue sequencer firmware in the future which could be
incompatible with the current driver.  Therefore, the driver will be
tied to the particular major number of the firmware (i.e. the current
driver will load any 1.x firmware).  Additionally, the driver will print
out both the ascii string and the major number, so with this pach the
current firmware will print out

aic94xx: Found sequencer firmware version 1.1 (V17/10c6)
Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      a29fdd3c
  43. 15 2月, 2007 1 次提交
  45. 12 2月, 2007 1 次提交
  47. 04 2月, 2007 1 次提交
  49. 03 2月, 2007 2 次提交
  51. 28 1月, 2007 1 次提交
  53. 27 1月, 2007 1 次提交
  55. 14 1月, 2007 2 次提交