1. 31 Aug, 2006 6 commits
  2. 26 Jul, 2006 10 commits
    • Francois Romieu's avatar
      r8169: sync with vendor's driver · bcf0bf90
      Francois Romieu authored
      - 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: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      bcf0bf90
    • Francois Romieu's avatar
      r8169: remove rtl8169_init_board · 4ff96fa6
      Francois Romieu authored
      Rationale:
      - its signature is not exactly pretty;
      - it has no knowledge of pci_device_id;
      - kiss 23 lines good bye.
      Signed-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      4ff96fa6
    • Francois Romieu's avatar
      r8169: hardware flow control · 623a1593
      Francois Romieu authored
      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: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      623a1593
    • Francois Romieu's avatar
      r8169: RX fifo overflow recovery · 9dccf611
      Francois Romieu authored
      Signed-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      9dccf611
    • Francois Romieu's avatar
      r8169: mac address change support · a2b98a69
      Francois Romieu authored
      Fix for http://bugzilla.kernel.org/show_bug.cgi?id=6032.
      
      Cc: Tim Mattox <tmattox@gmail.com>
      Signed-off-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      a2b98a69
    • Christoph Hellwig's avatar
      [PATCH] fix compile regression for a few scsi drivers · 64821324
      Christoph Hellwig authored
      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: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      64821324
    • Linus Torvalds's avatar
      Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6 · dab5025c
      Linus Torvalds authored
      * master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
        [SCSI] esp: Fix build.
        [SPARC]: Fix SA_STATIC_ALLOC value.
        [SPARC64]: Explicitly print return PC when the kernel fault PC is bogus.
      dab5025c
    • Linus Torvalds's avatar
      Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 · 761a1260
      Linus Torvalds authored
      * master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
        [IPV4/IPV6]: Setting 0 for unused port field in RAW IP recvmsg().
        [IPV4] ipmr: ip multicast route bug fix.
        [TG3]: Update version and reldate
        [TG3]: Handle tg3_init_rings() failures
        [TG3]: Add tg3_restart_hw()
        [IPV4]: Clear the whole IPCB, this clears also IPCB(skb)->flags.
        [IPV6]: Clean skb cb on IPv6 input.
        [NETFILTER]: Demote xt_sctp to EXPERIMENTAL
        [NETFILTER]: bridge netfilter: add deferred output hooks to feature-removal-schedule
        [NETFILTER]: xt_pkttype: fix mismatches on locally generated packets
        [NETFILTER]: SNMP NAT: fix byteorder confusion
        [NETFILTER]: conntrack: fix SYSCTL=n compile
        [NETFILTER]: nf_queue: handle NF_STOP and unknown verdicts in nf_reinject
        [NETFILTER]: H.323 helper: fix possible NULL-ptr dereference
      761a1260
    • Arjan van de Ven's avatar
      [PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare · 153d7f3f
      Arjan van de Ven authored
      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: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      153d7f3f
    • Tetsuo Handa's avatar
      [IPV4/IPV6]: Setting 0 for unused port field in RAW IP recvmsg(). · f59fc7f3
      Tetsuo Handa authored
      From: Tetsuo Handa from-linux-kernel@i-love.sakura.ne.jp
      
      The recvmsg() for raw socket seems to return random u16 value
      from the kernel stack memory since port field is not initialized.
      But I'm not sure this patch is correct.
      Does raw socket return any information stored in port field?
      
      [ BSD defines RAW IP recvmsg to return a sin_port value of zero.
        This is described in Steven's TCP/IP Illustrated Volume 2 on
        page 1055, which is discussing the BSD rip_input() implementation. ]
      Acked-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f59fc7f3
  3. 25 Jul, 2006 19 commits
  4. 24 Jul, 2006 5 commits