Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 06 2月, 2007 4 次提交
    • D
      [PATCH] zd1211rw: Add ID for Linksys WUSBF54G · 33218ba1
      由 Daniel Drake 提交于 
      Tested by Henrik Hjelte
zd1211b chip 13b1:0024 v4802 high 00-14-bf AL2230_RF pa0 ----
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      33218ba1
    • D
      [PATCH] zd1211rw: Remove addressing abstraction · 0ce34bc8
      由 Daniel Drake 提交于 
      Instead of passing our own custom 32-bit addresses around and
translating them, this patch makes all our register address constants
absolute and removes the translation.

There are two ugly parts:
 - fw_reg_addr() is needed to compute addresses of firmware registers, as this
   is dynamic based upon firmware
 - inc_addr() needs a small hack to handle byte vs word addressing

However, both of those are only small, and we don't use fw_regs a whole
lot anyway.

The bonuses here include simplicity and improved driver readability. Also, the
fact that registers are now referenced by 16-bit absolute addresses (as
opposed to 32-bit pseudo addresses) means that over 2kb compiled code size has
been shaved off.

Includes some touchups and sparse fixes from Ulrich Kunitz.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0ce34bc8
    • D
      [PATCH] zd1211rw: Consistency for address space constants · ee302767
      由 Daniel Drake 提交于 
      The zd1211rw address space has confused me once too many times. This
patch introduces the following naming notation:

Memory space is split into segments (cr, fw, eeprom) and segments may
contain components (e.g. boot code inside eeprom). These names are
arbitrary and only for the description below:

x_START: Absolute address of segment start
(previously these were named such as CR_BASE_OFFSET, but they weren't
really offsets unless you were considering them as an offset to 0)

x_LEN: Segment length

x_y_LEN: Length of component y of segment x

x_y_OFFSET: Relative address of component y into segment x. The absolute
address for this component is (x_START + x_y_OFFSET)

I also renamed EEPROM registers to EEPROM data. These 'registers' can't
be written to using standard I/O and really represent predefined data
from the vendor.
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ee302767
    • D
      [PATCH] zd1211rw: 2 new ZD1211B device ID's · a2bdcc67
      由 Daniel Drake 提交于 
      Philips SNU5600, tested by unibrow
zd1211b chip 0471:1236 v4810 high 00-12-bf AL2230_RF pa0 g--

SMC Ez Connect 802.11g (SMCWUSB-G), tested by Victorino Sanz Prat
zd1211b chip 083a:4505 v4810 full 00-13-f7 AL2230_RF pa0 g--N
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a2bdcc67
  3. 20 12月, 2006 1 次提交
  5. 02 12月, 2006 6 次提交
  7. 29 11月, 2006 1 次提交
  9. 05 10月, 2006 1 次提交
    • D
      IRQ: Maintain regs pointer globally rather than passing to IRQ handlers · 7d12e780
      由 David Howells 提交于 
      Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.

The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around.  On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).

Where appropriate, an arch may override the generic storage facility and do
something different with the variable.  On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.

Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions.  Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller.  A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.

I've build this code with allyesconfig for x86_64 and i386.  I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.

This will affect all archs.  Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:

	struct pt_regs *old_regs = set_irq_regs(regs);

And put the old one back at the end:

	set_irq_regs(old_regs);

Don't pass regs through to generic_handle_irq() or __do_IRQ().

In timer_interrupt(), this sort of change will be necessary:

	-	update_process_times(user_mode(regs));
	-	profile_tick(CPU_PROFILING, regs);
	+	update_process_times(user_mode(get_irq_regs()));
	+	profile_tick(CPU_PROFILING);

I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().

Some notes on the interrupt handling in the drivers:

 (*) input_dev() is now gone entirely.  The regs pointer is no longer stored in
     the input_dev struct.

 (*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking.  It does
     something different depending on whether it's been supplied with a regs
     pointer or not.

 (*) Various IRQ handler function pointers have been moved to type
     irq_handler_t.
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
      7d12e780
  11. 26 9月, 2006 1 次提交
  13. 12 9月, 2006 2 次提交
  15. 15 8月, 2006 7 次提交
  17. 03 8月, 2006 2 次提交
  19. 11 7月, 2006 2 次提交
  21. 06 7月, 2006 1 次提交
    • D
      [PATCH] ZyDAS ZD1211 USB-WLAN driver · e85d0918
      由 Daniel Drake 提交于 
      There are 60+ USB wifi adapters available on the market based on the ZyDAS
ZD1211 chip.

Unlike the predecessor (ZD1201), ZD1211 does not have a hardware MAC, so most
data operations are coordinated by the device driver. The ZD1211 chip sits
alongside an RF transceiver which is also controlled by the driver. Our driver
currently supports 2 RF types, we know of one other available in a few marketed
products which we will be supporting soon.

Our driver also supports the newer revision of ZD1211, called ZD1211B. The
initialization and RF operations are slightly different for the new revision,
but the main difference is 802.11e support. Our driver does not support the
QoS features yet, but we think we know how to use them.

This driver is based on ZyDAS's own GPL driver available from www.zydas.com.tw.
ZyDAS engineers have been responsive and supportive of our efforts, so thumbs
up to them. Additionally, the firmware is redistributable and they have
provided device specs.

This driver has been written primarily by Ulrich Kunitz and myself. Graham
Gower, Greg KH, Remco and Bryan Rittmeyer have also contributed. The
developers of ieee80211 and softmac have made our lives so much easier- thanks!

We maintain a small info-page: http://zd1211.ath.cx/wiki/DriverRewrite

If there is enough time for review, we would like to aim for inclusion in
2.6.18. The driver works nicely as a STA, and can connect to both open and
encrypted networks (we are using software-based encryption for now). We will
work towards supporting more advanced features in the future (ad-hoc, master
mode, 802.11a, ...).
Signed-off-by: NDaniel Drake <dsd@gentoo.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e85d0918