1. 08 Jul, 2008 3 commits
    • Sergei Shtylyov's avatar
      palm_bk3710: fix IDECLK period calculation · ffab6cf4
      Sergei Shtylyov authored
      The driver uses completely bogus rounding formula for calculating period from
      the IDECLK frequency which gives one-off period values (e.g. 11 ns with 100 MHz
      IDECLK) which in turn can lead to overclocked IDE transfer timings.  Actually,
      rounding is just wrong in this case, so use a mere division for a safe result.
      
      While at it, also:
      
      - give 'ide_palm_clk' variable a more suitable name;
      
      - get rid of the useless 'ideclkp' variable;
      
      - drop the LISP stype 'p' postfix from the 'clkp' variable's name. :-)
      Signed-off-by: default avatarSergei Shtylyov <sshtylyov@ru.mvista.com>
      Cc: mcherkashin@ru.mvista.com
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      ffab6cf4
    • Bartlomiej Zolnierkiewicz's avatar
      ide: add __ide_default_irq() inline helper · a861beb1
      Bartlomiej Zolnierkiewicz authored
      Add __ide_default_irq() inline helper and use it instead of
      ide_default_irq() in ide-probe.c and ns87415.c (all host drivers
      except IDE PCI ones always setup hwif->irq so it is enough to
      check only for I/O bases 0x1f0 and 0x170).
      
      This fixes post-2.6.25 regression since ide_default_irq()
      define could shadow ide_default_irq() inline.
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      a861beb1
    • David Gibson's avatar
      Correct hash flushing from huge_ptep_set_wrprotect() · 86df8642
      David Gibson authored
      As Andy Whitcroft recently pointed out, the current powerpc version of
      huge_ptep_set_wrprotect() has a bug.  It just calls ptep_set_wrprotect()
      which in turn calls pte_update() then hpte_need_flush() with the 'huge'
      argument set to 0.  This will cause hpte_need_flush() to flush the wrong
      hash entries (of any).  Andy's fix for this is already in the powerpc
      tree as commit 016b33c4.
      
      I have confirmed this is a real bug, not masked by some other
      synchronization, with a new testcase for libhugetlbfs.  A process write
      a (MAP_PRIVATE) hugepage mapping, fork(), then alter the mapping and
      have the child incorrectly see the second write.
      
      Therefore, this should be fixed for 2.6.26, and for the stable tree.
      Here is a suitable patch for 2.6.26, which I think will also be suitable
      for the stable tree (neither of the headers in question has been changed
      much recently).
      
      It is cut down slighlty from Andy's original version, in that it does
      not include a 32-bit version of huge_ptep_set_wrprotect().  Currently,
      hugepages are not supported on any 32-bit powerpc platform.  When they
      are, a suitable 32-bit version can be added - the only 32-bit hardware
      which supports hugepages does not use the conventional hashtable MMU and
      so will have different needs anyway.
      Signed-off-by: default avatarAndy Whitcroft <apw@shadowen.org>
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      86df8642
  2. 07 Jul, 2008 5 commits
  3. 06 Jul, 2008 10 commits
  4. 05 Jul, 2008 15 commits
  5. 04 Jul, 2008 7 commits