Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
“6a7b79108213522baca1def466116a1c4ea2207c”上不存在“uni_modules/uni-native-button/changelog.md”
切换分支/标签
  1. 31 10月, 2008 1 次提交
  3. 28 10月, 2008 1 次提交
  5. 25 9月, 2008 1 次提交
  7. 19 9月, 2008 1 次提交
  9. 27 8月, 2008 1 次提交
    • J
      e100, fix iomap read · 17393dd6
      由 Jiri Slaby 提交于 
      There were 2 omitted readb's used on an iomap space. eliminate them
by using ioread8 instead.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Bruce Allan <bruce.w.allan@intel.com>
Cc: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
Cc: John Ronciak <john.ronciak@intel.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      17393dd6
  11. 27 7月, 2008 1 次提交
    • F
      dma-mapping: add the device argument to dma_mapping_error() · 8d8bb39b
      由 FUJITA Tomonori 提交于 
      Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
architecture does:

This enables us to cleanly fix the Calgary IOMMU issue that some devices
are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).

I think that per-device dma_mapping_ops support would be also helpful for
KVM people to support PCI passthrough but Andi thinks that this makes it
difficult to support the PCI passthrough (see the above thread).  So I
CC'ed this to KVM camp.  Comments are appreciated.

A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
NULL, the system-wide dma_ops pointer is used as before.

If it's useful for KVM people, I plan to implement a mechanism to register
a hook called when a new pci (or dma capable) device is created (it works
with hot plugging).  It enables IOMMUs to set up an appropriate
dma_mapping_ops per device.

The major obstacle is that dma_mapping_error doesn't take a pointer to the
device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
device.  Note all the POWER IOMMUs use the same dma_mapping_error function
so this is not a problem for POWER but x86 IOMMUs use different
dma_mapping_error functions.

The first patch adds the device argument to dma_mapping_error.  The patch
is trivial but large since it touches lots of drivers and dma-mapping.h in
all the architecture.

This patch:

dma_mapping_error() doesn't take a pointer to the device unlike other DMA
operations.  So we can't have dma_mapping_ops per device.

Note that POWER already has dma_mapping_ops per device but all the POWER
IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
argument.

[akpm@linux-foundation.org: fix sge]
[akpm@linux-foundation.org: fix svc_rdma]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix bnx2x]
[akpm@linux-foundation.org: fix s2io]
[akpm@linux-foundation.org: fix pasemi_mac]
[akpm@linux-foundation.org: fix sdhci]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix sparc]
[akpm@linux-foundation.org: fix ibmvscsi]
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Avi Kivity <avi@qumranet.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d8bb39b
  13. 27 6月, 2008 1 次提交
  15. 29 4月, 2008 1 次提交
  17. 26 3月, 2008 1 次提交
  19. 05 3月, 2008 1 次提交
  21. 03 2月, 2008 2 次提交
  23. 29 1月, 2008 3 次提交
    • A
      e100 endianness annotations · aaf918ba
      由 Al Viro 提交于 
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      aaf918ba
    • D
      Fix e100 on systems that have cache incoherent DMA · 7734f6e6
      由 David Acker 提交于 
      On the systems that have cache incoherent DMA, including ARM, there
is a race condition between software allocating a new receive buffer
and hardware writing into a buffer.  The two race on touching the last
Receive Frame Descriptor (RFD).  It has its el-bit set and its next
link equal to 0.  When hardware encounters this buffer it attempts to
write data to it and then update Status Word bits and Actual Count in
the RFD.  At the same time software may try to clear the el-bit and
set the link address to a new buffer.

Since the entire RFD is once cache-line, the two write operations can
collide.  This can lead to the receive unit stalling or interpreting
random memory as its receive area.

The fix is to set the el-bit on and the size to 0 on the next to last
buffer in the chain.  When the hardware encounters this buffer it stops
and does not write to it at all.  The hardware issues an RNR interrupt
with the receive unit in the No Resources state.  Software can write
to the tail of the list because it knows hardware will stop on the
previous descriptor that was marked as the end of list.

Once it has a new next to last buffer prepared, it can clear the el-bit
and set the size on the previous one.  The race on this buffer is safe
since the link already points to a valid next buffer and the software
can handle the race setting the size (assuming aligned 16 bit writes
are atomic with respect to the DMA read). If the hardware sees the
el-bit cleared without the size set, it will move on to the next buffer
and skip this one.  If it sees the size set but the el-bit still set,
it will complete that buffer and then RNR interrupt and wait.
Signed-off-by: NDavid Acker <dacker@roinet.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      7734f6e6
    • A
      netdev: use ARRAY_SIZE() instead of sizeof(array) / ETH_GSTRING_LEN · 4c3616cd
      由 Alejandro Martinez Ruiz 提交于 
      Using ARRAY_SIZE() on arrays of the form array[][K] makes it unnecessary
to know the value of K when checking its size.
Signed-off-by: NAlejandro Martinez Ruiz <alex@flawedcode.org>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      4c3616cd
  25. 09 1月, 2008 2 次提交
  27. 15 12月, 2007 1 次提交
  29. 08 12月, 2007 1 次提交
  31. 20 10月, 2007 1 次提交
  33. 11 10月, 2007 7 次提交
  35. 01 8月, 2007 1 次提交
  37. 12 7月, 2007 1 次提交
    • A
      PCI: Change all drivers to use pci_device->revision · 44c10138
      由 Auke Kok 提交于 
      Instead of all drivers reading pci config space to get the revision
ID, they can now use the pci_device->revision member.

This exposes some issues where drivers where reading a word or a dword
for the revision number, and adding useless error-handling around the
read. Some drivers even just read it for no purpose of all.

In devices where the revision ID is being copied over and used in what
appears to be the equivalent of hotpath, I have left the copy code
and the cached copy as not to influence the driver's performance.

Compile tested with make all{yes,mod}config on x86_64 and i386.
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Acked-by: NDave Jones <davej@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      44c10138
  39. 11 7月, 2007 1 次提交
  41. 13 6月, 2007 1 次提交
  43. 28 4月, 2007 3 次提交
    • J
      e100: Optionally use I/O mode only to access register space · 27345bb6
      由 Jesse Brandeburg 提交于 
      It appears that some systems still like e100 better if it uses
I/O access mode.  Setting the new parameter use_io=1 will cause
all driver instances to use io mapping to access the register
space on the e100 device.
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      27345bb6
    • J
      e100: allow bad MAC address when running with invalid eeprom csum · 948cd43f
      由 Jesse Brandeburg 提交于 
      Seved Torstendahl <seved.torstendahl@netinsight.net> suggested to
let the module parameter for invalid eeprom checksum control the valid
mac address test.

If this bypass happens we should print a different message,
or at least one that is correct, maybe something like below
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NAuke Kok <auke-jan.h.kok@intel.com>
Signed-off-by: NJeff Garzik <jeff@garzik.org>
      948cd43f
    • S
      [netdrvr e100] experiment with doing RX in a similar manner to eepro100 · d52df4a3
      由 Scott Feldman 提交于 
      I was going to say that eepro100's speedo_rx_link() does the same DMA
abuse as e100, but then I noticed one little detail: eepro100 sets  both
EL (end of list) and S (suspend) bits in the RFD as it chains it  to the
RFD list.  e100 was only setting the EL bit.  Hmmm, that's  interesting.
That means that if HW reads a RFD with the S-bit set,  it'll process
that RFD and then suspend the receive unit.  The  receive unit will
resume when SW clears the S-bit.  There is no need  for SW to restart
the receive unit.  Which means a lot of the receive  unit state tracking
code in the driver goes away.

So here's a patch against 2.6.14.  (Sorry for inlining it; the mailer
I'm using now will mess with the word wrap).  I can't test this on
XScale (unless someone has an e100 module for Gumstix :) .  It should
be doing exactly what eepro100 does with RFDs.  I don't believe this
change will introduce a performance hit because the S-bit and EL-bit  go
hand-in-hand meaning if we're going to suspend because of the S- bit,
we're on the last resource anyway, so we'll have to wait for SW  to
replenish.
(cherry picked from 29e79da9495261119e3b2e4e7c72507348e75976 commit)
      d52df4a3
  45. 26 4月, 2007 1 次提交
  47. 02 2月, 2007 1 次提交
  49. 30 1月, 2007 1 次提交
  51. 13 12月, 2006 1 次提交
  53. 30 11月, 2006 1 次提交
  55. 22 11月, 2006 1 次提交