Skip to content

cloud-kernel
cloud-kernel

bug2833 / cloud-kernel
与 Fork 源项目一致

Fork自 openanolis / cloud-kernel

通知 1
Star 0
Fork 0
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 13 10月, 2007 6 次提交
  3. 12 10月, 2007 1 次提交
    • J
      [libata] sata_mv: more S/G fixes · 6c08772e
      由 Jeff Garzik 提交于 
      * corruption fix: we only want the lower 16 bits of length (0 == 64kb)

* ditto: the upper layer sets max-phys-segments to LIBATA_MAX_PRD,
  so we must reset it to own hw-specific length.

* delete unused mv_fill_sg() return value
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      6c08772e
  5. 10 10月, 2007 2 次提交
    • J
      drivers/firmware: const-ify DMI API and internals · 1855256c
      由 Jeff Garzik 提交于 
      Three main sets of changes:

1) dmi_get_system_info() return value should have been marked const,
   since callers should not be changing that data.

2) const-ify DMI internals, since DMI firmware tables should,
   whenever possible, be marked const to ensure we never ever write to
   that data area.

3) const-ify DMI API, to enable marking tables const where possible
   in low-level drivers.

And if we're really lucky, this might enable some additional
optimizations on the part of the compiler.

The bulk of the changes are #2 and #3, which are interrelated.  #1 could
have been a separate patch, but it was so small compared to the others,
it was easier to roll it into this changeset.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      1855256c
    • J
      sata_mv: correct S/G table limits · baf14aa1
      由 Jeff Garzik 提交于 
      The recent mv_fill_sg() rewrite, to fix a data corruption problem
related to IOMMU virtual merging, forgot to account for the
potentially-increased size of the scatter/gather table after its run.

Additionally, the DMA boundary is reduced from 0xffffffff to 0xffff
to more closely match the needs of mv_fill_sg().
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      baf14aa1
  7. 04 10月, 2007 3 次提交
  9. 02 10月, 2007 1 次提交
  11. 26 9月, 2007 2 次提交
  13. 21 9月, 2007 3 次提交
  15. 12 9月, 2007 1 次提交
  17. 11 9月, 2007 4 次提交
  19. 01 9月, 2007 2 次提交
  21. 31 8月, 2007 8 次提交
  23. 24 8月, 2007 1 次提交
  25. 23 8月, 2007 5 次提交
    • T
      libata: don't check n_sectors during revalidation if zero · b54eebd6
      由 Tejun Heo 提交于 
      If the initial configuration fails early, n_sectors is left at zero.
Checking against it during revalidation makes retried configuration
fail due to n_sectors mismatch.  Ignore zero n_sectors during
revalidation.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      b54eebd6
    • A
      pata_via: Add Arima W730-K8 and other rebadgings · 9edbdbea
      由 Alan Cox 提交于 
      More cable funnies
Signed-off-by: NAlan Cox <alan@redhat.com>
Tested-by: NMikael Pettersson <mikpe@it.uu.se>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      9edbdbea
    • A
      pata_sis: Add the FSC Amilo and friends · 4f2d47cf
      由 Alan Cox 提交于 
      More short cables
Signed-off-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      4f2d47cf
    • M
      pata_pdc2027x: PLL detection fixes · 78c4af0b
      由 Mikael Pettersson 提交于 
      Previously I reported that the pata_pdc2027x PLL detection changes
in kernel 2.6.22 broke the driver on my PowerMac:

>pata_pdc2027x: Invalid PLL input clock 1691742kHz, give up!

This is followed by a number of errors and speed reduction
steps on the affected ports.

There are two bugs in pata_pdc2027x's PLL detection code:

1. The PLL counter's start value is read before the chip is
   put in "test mode". Outside of test mode the counter is
   halted, and on the PowerMac the counter is zero because
   the chip hasn't been initialised by its BIOS.

   The fix is to move the read of the start value to after
   test mode is started, but before the mdelay() in test mode.
   This also improves the precision of the PLL detection.

2. The code to compute the number of PLL decrements during the
   mdelay() in test mode fails to consider that the PLL counter
   only is 30 bits wide. If there is a wraparound, it will compute
   an incorrect and much too large value. On the PowerMac, the
   start count is zero, the end count is a large 30-bit value, so
   wraparound occurs and an out of bounds PLL clock is detected.

   The fix is to mask the (start - end) computation to 30 bits.

While debugging this I also noticed that pdc_read_counter()
reads the two halves of the 30-bit PLL counter as 16-bit values,
and then combines them as if the halves only are 15 bits wide.
To avoid confusion, the halves should be read as 15-bit values.

This patch implements all three changes. It fixes the PLL detection
failure on my PowerMac, and doesn't cause any regressions on an x86
with an identical card.
Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      78c4af0b
    • T
      libata: fix n_sectors failure handling during revalidation · 8270bec4
      由 Tejun Heo 提交于 
      If revalidation fails because device has different n_sectors after
configuration the original n_sectors should be restored before failing
revalidation.  Without this fix, n_sectors difference will incorrectly
and silently pass revalidation when revalidation is retried.
Signed-off-by: NTejun Heo <htejun@gmail.com>
Acked-by: NAlan Cox <alan@redhat.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      8270bec4
  27. 15 8月, 2007 1 次提交