<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/include/asm-m68knommu/pci.h, branch master</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2008-08-07T05:36:16+00:00</updated>
<entry>
<title>Move all of include/asm-m68knommu to arch/m68knommu/include/asm.</title>
<updated>2008-08-07T05:36:16+00:00</updated>
<author>
<name>Greg Ungerer</name>
<email>gerg@uclinux.org</email>
</author>
<published>2008-07-31T04:38:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=58750139001bae11a1f9b074f3a9c774fecf5ba8'/>
<id>urn:sha1:58750139001bae11a1f9b074f3a9c774fecf5ba8</id>
<content type='text'>
With the current kbuild infrastructure in place no other changes
are required for this to work.

Signed-off-by: Greg Ungerer &lt;gerg@uclinux.org&gt;
</content>
</entry>
<entry>
<title>PCI: remove pci_dac_dma_... APIs</title>
<updated>2007-07-11T23:02:11+00:00</updated>
<author>
<name>Jan Beulich</name>
<email>jbeulich@novell.com</email>
</author>
<published>2007-07-09T18:55:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=caa5171622c8fef70fa20d2d74f4326866039df9'/>
<id>urn:sha1:caa5171622c8fef70fa20d2d74f4326866039df9</id>
<content type='text'>
Based on replies to a respective query, remove the pci_dac_dma_...() APIs
(except for pci_dac_dma_supported() on Alpha, where this function is used
in non-DAC PCI DMA code).

Signed-off-by: Jan Beulich &lt;jbeulich@novell.com&gt;
Cc: Andi Kleen &lt;ak@suse.de&gt;
Cc: Jesse Barnes &lt;jesse.barnes@intel.com&gt;
Cc: Christoph Hellwig &lt;hch@infradead.org&gt;
Acked-by: David Miller &lt;davem@davemloft.net&gt;
Cc: Jeff Garzik &lt;jeff@garzik.org&gt;
Cc: &lt;linux-arch@vger.kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;


</content>
</entry>
<entry>
<title>PCI: Use a weak symbol for the empty version of pcibios_add_platform_entries()</title>
<updated>2007-07-11T23:02:07+00:00</updated>
<author>
<name>Michael Ellerman</name>
<email>michael@ellerman.id.au</email>
</author>
<published>2007-05-08T02:03:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=575e3348cb80c3265278756778d5091d5ca4efbf'/>
<id>urn:sha1:575e3348cb80c3265278756778d5091d5ca4efbf</id>
<content type='text'>
I'm not sure if this is going to fly, weak symbols work on the compilers I'm
using, but whether they work for all of the affected architectures I can't say.
I've cc'ed as many arch maintainers/lists as I could find.

But assuming they do, we can use a weak empty definition of
pcibios_add_platform_entries() to avoid having an empty definition on every
arch.

Signed-off-by: Michael Ellerman &lt;michael@ellerman.id.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;


</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@ppc970.osdl.org</email>
</author>
<published>2005-04-16T22:20:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>urn:sha1:1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</content>
</entry>
</feed>
