Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 01 8月, 2006 17 次提交
  3. 29 7月, 2006 2 次提交
  5. 28 7月, 2006 9 次提交
  7. 27 7月, 2006 2 次提交
  9. 26 7月, 2006 5 次提交
    • C
      [PATCH] fix compile regression for a few scsi drivers · 64821324
      由 Christoph Hellwig 提交于 
      This fixes three drivers to compile again after my patch that removes
the data_cmnd member from struct scsi_cmnd.

The fas216 change is trivial, it should have been using ->cmnd all the
time.

NCR53C9 (which seem to be mostly duplicate driver with esp.c!) is doing
something odd, it should only have looked at ->cmnd before not the saved
copy that is kept for the error handlers sake.  Note that it really
should deal with the sync setting themselves but use the generic domain
validation code that get this right - but that's for later let's push
this simple compile fix for now.

And sorry for the late fix for this, I have been busy with OLS and
associated activities last week.
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      64821324
    • A
      [PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare · 153d7f3f
      由 Arjan van de Ven 提交于 
      The patch below moves the cpu hotplugging higher up in the cpufreq
layering; this is needed to avoid recursive taking of the cpu hotplug
lock and to otherwise detangle the mess.

The new rules are:
1. you must do lock_cpu_hotplug() around the following functions:
   __cpufreq_driver_target
   __cpufreq_governor (for CPUFREQ_GOV_LIMITS operation only)
   __cpufreq_set_policy
2. governer methods (.governer) must NOT take the lock_cpu_hotplug()
   lock in any way; they are called with the lock taken already
3. if your governer spawns a thread that does things, like calling
   __cpufreq_driver_target, your thread must honor rule #1.
4. the policy lock and other cpufreq internal locks nest within
   the lock_cpu_hotplug() lock.

I'm not entirely happy about how the __cpufreq_governor rule ended up
(conditional locking rule depending on the argument) but basically all
callers pass this as a constant so it's not too horrible.

The patch also removes the cpufreq_governor() function since during the
locking audit it turned out to be entirely unused (so no need to fix it)

The patch works on my testbox, but it could use more testing
(otoh... it can't be much worse than the current code)
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      153d7f3f
    • M
      [TG3]: Update version and reldate · b6e77a53
      由 Michael Chan 提交于 
      Update version to 3.63.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b6e77a53
    • M
      [TG3]: Handle tg3_init_rings() failures · 32d8c572
      由 Michael Chan 提交于 
      Handle dev_alloc_skb() failures when initializing the RX rings.
Without proper handling, the driver will crash when using a partial
ring.

Thanks to Stephane Doyon <sdoyon@max-t.com> for reporting the bug and
providing the initial patch.

Howie Xu <howie@vmware.com> also reported the same issue.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32d8c572
    • M
      [TG3]: Add tg3_restart_hw() · b9ec6c1b
      由 Michael Chan 提交于 
      Add tg3_restart_hw() to handle failures when re-initializing the
device.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9ec6c1b
  11. 25 7月, 2006 5 次提交