Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

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

切换分支/标签
  1. 23 9月, 2006 1 次提交
  3. 21 9月, 2006 1 次提交
  5. 14 9月, 2006 1 次提交
  7. 12 9月, 2006 1 次提交
  9. 01 9月, 2006 6 次提交
  11. 20 8月, 2006 1 次提交
  13. 27 7月, 2006 5 次提交
    • F
      r8169: sync with vendor's driver · bcf0bf90
      由 Francois Romieu 提交于 
      - add several PCI ID for the PCI-E adapters ;
- new identification strings ;
- the RTL_GIGA_MAC_VER_ defines have been renamed to closely match the
  out-of-tree driver. It makes the comparison less hairy ;
- various magic ;
- the PCI region for the device with PCI ID 0x8136 is guessed.
  Explanation: the in-kernel Linux driver is written to allow MM register
  accesses and avoid the IO tax. The relevant BAR register was found at
  base address 1 for the plain-old PCI 8169. User reported lspci show that
  it is found at base address 2 for the new Gigabit PCI-E 816{8/9}.
  Typically:
  01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8168 (rev 01)
          Subsystem: Unknown device 1631:e015
          Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
          Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
          Latency: 0, cache line size 20
          Interrupt: pin A routed to IRQ 16
          Region 0: I/O ports at b800 [size=256]
          Region 2: Memory at ff7ff000 (64-bit, non-prefetchable) [size=4K]
          ^^^^^^^^
  So far I have not received any lspci report for the 0x8136 and
  Realtek's driver do not help: be it under BSD or Linux, their r1000 driver
  include a USE_IO_SPACE #define but the bar address is always hardcoded
  to 1 in the MM case. :o/
- the 8168 has been reported to require an extra alignment for its receive
  buffers. The status of the 8167 and 8136 is not known in this regard.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      bcf0bf90
    • F
      r8169: remove rtl8169_init_board · 4ff96fa6
      由 Francois Romieu 提交于 
      Rationale:
- its signature is not exactly pretty;
- it has no knowledge of pci_device_id;
- kiss 23 lines good bye.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      4ff96fa6
    • F
      r8169: hardware flow control · 623a1593
      由 Francois Romieu 提交于 
      The datasheet suggests that the device handles the hardware flow
control almost automagically. User report a different story, so
let's try to twiddle the mii registers.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      623a1593
    • F
      r8169: RX fifo overflow recovery · 9dccf611
      由 Francois Romieu 提交于 
      Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      9dccf611
    • F
      r8169: mac address change support · a2b98a69
      由 Francois Romieu 提交于 
      Fix for http://bugzilla.kernel.org/show_bug.cgi?id=6032.

Cc: Tim Mattox <tmattox@gmail.com>
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
      a2b98a69
  15. 06 7月, 2006 2 次提交
  17. 03 7月, 2006 1 次提交
  19. 23 6月, 2006 2 次提交
    • H
      [NET]: Merge TSO/UFO fields in sk_buff · 7967168c
      由 Herbert Xu 提交于 
      Having separate fields in sk_buff for TSO/UFO (tso_size/ufo_size) is not
going to scale if we add any more segmentation methods (e.g., DCCP).  So
let's merge them.

They were used to tell the protocol of a packet.  This function has been
subsumed by the new gso_type field.  This is essentially a set of netdev
feature bits (shifted by 16 bits) that are required to process a specific
skb.  As such it's easy to tell whether a given device can process a GSO
skb: you just have to and the gso_type field and the netdev's features
field.

I've made gso_type a conjunction.  The idea is that you have a base type
(e.g., SKB_GSO_TCPV4) that can be modified further to support new features.
For example, if we add a hardware TSO type that supports ECN, they would
declare NETIF_F_TSO | NETIF_F_TSO_ECN.  All TSO packets with CWR set would
have a gso_type of SKB_GSO_TCPV4 | SKB_GSO_TCPV4_ECN while all other TSO
packets would be SKB_GSO_TCPV4.  This means that only the CWR packets need
to be emulated in software.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7967168c
    • H
      [NET]: Avoid allocating skb in skb_pad · 5b057c6b
      由 Herbert Xu 提交于 
      First of all it is unnecessary to allocate a new skb in skb_pad since
the existing one is not shared.  More importantly, our hard_start_xmit
interface does not allow a new skb to be allocated since that breaks
requeueing.

This patch uses pskb_expand_head to expand the existing skb and linearize
it if needed.  Actually, someone should sift through every instance of
skb_pad on a non-linear skb as they do not fit the reasons why this was
originally created.

Incidentally, this fixes a minor bug when the skb is cloned (tcpdump,
TCP, etc.).  As it is skb_pad will simply write over a cloned skb.  Because
of the position of the write it is unlikely to cause problems but still
it's best if we don't do it.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b057c6b
  21. 27 5月, 2006 1 次提交
  23. 04 3月, 2006 1 次提交
  25. 24 2月, 2006 2 次提交
  27. 01 2月, 2006 1 次提交
  29. 29 1月, 2006 1 次提交
  31. 11 1月, 2006 1 次提交
  33. 17 11月, 2005 2 次提交
  35. 01 10月, 2005 1 次提交
  37. 22 9月, 2005 1 次提交
  39. 14 9月, 2005 1 次提交
  41. 27 8月, 2005 1 次提交
  43. 19 8月, 2005 1 次提交
  45. 29 6月, 2005 1 次提交
    • D
      [NET]: Remove gratuitous use of skb->tail in network drivers. · 689be439
      由 David S. Miller 提交于 
      Many drivers use skb->tail unnecessarily.

In these situations, the code roughly looks like:

	dev = dev_alloc_skb(...);

	[optional] skb_reserve(skb, ...);

	... skb->tail ...

But even if the skb_reserve() happens, skb->data equals
skb->tail.  So it doesn't make any sense to use anything
other than skb->data in these cases.

Another case was the s2io.c driver directly mucking with
the skb->data and skb->tail pointers.  It really just wanted
to do an skb_reserve(), so that's what the code was changed
to do instead.

Another reason I'm making this change as it allows some SKB
cleanups I have planned simpler to merge.  In those cleanups,
skb->head, skb->tail, and skb->end pointers are removed, and
replaced with skb->head_room and skb->tail_room integers.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Acked-by: NJeff Garzik <jgarzik@pobox.com>
      689be439
  47. 14 6月, 2005 1 次提交
  49. 28 5月, 2005 3 次提交