Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 11 8月, 2005 5 次提交
  3. 10 8月, 2005 15 次提交
  5. 09 8月, 2005 8 次提交
  7. 08 8月, 2005 1 次提交
    • I
      [PATCH] Fix restore of 64-bit PCI BAR's · cf7bee5a
      由 Ivan Kokshaysky 提交于 
      For 64-bit BAR[i] only pci_dev->resource[i] is valid, ->resource[i+1]
slot is unused and contains zeroes in all fields.

So when we update a PCI BAR, all we need is just to check that we're
going to update a _valid_ resource.

Also make sure to write high bits - use "x >> 16 >> 16" (rather than the
simpler ">> 32") to avoid warnings on 32-bit architectures where we're
not going to have any high bits.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cf7bee5a
  9. 07 8月, 2005 2 次提交
  11. 06 8月, 2005 6 次提交
  13. 05 8月, 2005 3 次提交
    • P
      [PATCH] rtc: msleep() cannot be used from interrupt · 403fe5ae
      由 Petr Vandrovec 提交于 
      Since the beginning of July my Opteron box was randomly crashing and
being rebooted by hardware watchdog.  Today it finally did it in front
of me, and this patch will hopefully fix it.

The problem is that at the end of June (the 28th, to be exact: commit
47f176fd, "[PATCH] Using msleep()
instead of HZ") rtc_get_rtc_time was converted to use msleep() instead
of busy waiting.  But rtc_get_rtc_time is used by hpet_rtc_interrupt,
and scheduling is not allowed during interrupt.  So I'm reverting this
part of original change, replacing msleep() back with busy loop.

The original code was busy waiting for up to 20ms, but on my hardware in
the worst case update-in-progress bit was asserted for at most 363
passes through loop (on 2GHz dual Opteron), much less than even one
jiffie, not even talking about 20ms.  So I changed code to just wait
only as long as necessary.  Otherwise when RTC was set to generate
8192Hz timer, it stopped doing anything for 20ms (160 pulses were
skipped!) from time to time, and this is rather suboptimal as far as I
can tell.
Signed-off-by: NPetr Vandrovec <vandrove@vc.cvut.cz>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      403fe5ae
    • O
      [PATCH] USB: Fix setup packet initialization in isp116x-hcd · f10eff26
      由 Olav Kongas 提交于 
      When recently addressing remarks by Alexey Dobriyan about
the isp116x-hcd, I introduced a bug in the driver. Please
apply the attached patch to fix it.
Signed-off-by: NOlav Kongas <ok@artecdesign.ee>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f10eff26
    • D
      [PATCH] USB: ehci: microframe handling fix · 7dedacf4
      由 David Brownell 提交于 
      This patch has a one line oops fix, plus related cleanups.

 - The bugfix uses microframe scheduling data given to the hardware to
   test "is this a periodic QH", rather than testing for nonzero period.
   (Prevents an oops by providing the correct answer.)

 - The cleanup going along with the patch should make it clearer what's
   going on whenever those bitfields are accessed.

The bug came about when, around January, two new kinds of EHCI interrupt
scheduling operation were added, involving both the high speed (24 KBytes
per millisec) and low/full speed (1-64 bytes per millisec) microframe
scheduling.  A driver for the Edirol UA-1000 Audio Capture Unit ran into
the oops; it used one of the newly supported high speed modes.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7dedacf4