- 14 9月, 2008 1 次提交
-
-
由 Jeremy Fitzhardinge 提交于
There's no good reason why a resource_size_t shouldn't just be a physical address, so simply redefine it in terms of phys_addr_t. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 04 9月, 2008 1 次提交
-
-
由 Linus Torvalds 提交于
Commit 88452565 ("PCI: clean up resource alignment management") changed the resource handling to mark how a resource was aligned on a per-resource basis. Thus, instead of looking at the resource number to determine whether it was a bridge resource or a regular resource (they have different alignment rules), we should just ask the resource for its alignment directly. The reason this broke only cardbus resources was that for the other types of resources, the old way of deciding alignment actually still happened to work. But CardBus bridge resources had been changed by commit 934b7024 ("Fix cardbus resource allocation") to look more like regular resources than PCI bridge resources from an alignment handling standpoint. Reported-and-tested-by: NAndrew Morton <akpm@linux-foundation.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 26 6月, 2008 1 次提交
-
-
由 Bjorn Helgaas 提交于
Convert printks to use dev_printk(). I converted pr_debug() to dev_dbg(). Both use KERN_DEBUG and are enabled only when DEBUG is defined. I converted printk(KERN_DEBUG) to dev_printk(KERN_DEBUG), not to dev_dbg(), because dev_dbg() is only enabled when DEBUG is defined. I converted DBG(KERN_INFO) (only in setup-bus.c) to dev_info(). The DBG() name makes it sound like debug, but it's been enabled forever, so dev_info() preserves the previous behavior. I tried to make the resource assignment formats more consistent, e.g., "BAR %d: got res [%#llx-%#llx] bus [%#llx-%#llx] flags %#lx\n" instead of sometimes using "start-end" and sometimes using "size@start". I'm not attached to one or the other; I'd just like them consistent. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 24 6月, 2008 1 次提交
-
-
由 Yinghai Lu 提交于
Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 23 4月, 2008 1 次提交
-
-
由 Linus Torvalds 提交于
Commit 88452565 ("PCI: clean up resource alignment management") didn't set the alignment information for the cardbus window resources, causing their subsequent allocations to fail miserably with a message like yenta_cardbus 0000:15:00.0: device not available because of BAR 7 [100:1ff] collisions yenta_cardbus: probe of 0000:15:00.0 failed with error -16 or similar. This fixes it and clarifies the code a bit too (we used to have to use the insane PCI bridge alignment logic that put the alignment in the "start" field, this makes it use the slightly easier-to-understand size-based alignment, and allows us to set the resource start to zero until it gets allocated). Reported-and-tested-by: NJeff Chua <jeff.chua.linux@gmail.com> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 4月, 2008 3 次提交
-
-
由 Adrian Bunk 提交于
WARNING: drivers/pci/built-in.o(.text+0x28ee9): Section mismatch in reference from the function pci_bus_assign_resources() to the function .devinit.text:pci_setup_bridge() Signed-off-by: NAdrian Bunk <bunk@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Adrian Bunk 提交于
WARNING: drivers/pci/built-in.o(.text+0x28e1f): Section mismatch in reference from the function pci_bus_size_bridges() to the function .devinit.text:pci_bus_size_cardbus() Signed-off-by: NAdrian Bunk <bunk@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Ivan Kokshaysky 提交于
Done per Linus' request and suggestions. Linus has explained that better than I'll be able to explain: On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote: > Actually, before we go any further, there might be a less intrusive > alternative: add just a couple of flags to the resource flags field (we > still have something like 8 unused bits on 32-bit), and use those to > implement a generic "resource_alignment()" routine. > > Two flags would do it: > > - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device > resources) > > - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources > during probing) > > and then the case of both flags zero (or both bits set) would actually be > "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we > actually allocate the resource (so that we don't use the "start" field as > alignment incorrectly when it no longer indicates alignment). > > That wouldn't be totally generic, but it would have the nice property of > automatically at least add sanity checking for that whole "res->start has > the odd meaning of 'alignment' during probing" and remove the need for a > new field, and it would allow us to have a generic "resource_alignment()" > routine that just gets a resource pointer. Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages. Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Gary Hade <garyhade@us.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 27 3月, 2008 1 次提交
-
-
由 Linus Torvalds 提交于
This reverts commit 8fa5913d, which caused various interesting problems for people, including wrong resource allocations. See for example bugzilla entry "2.6.25-rc2: ohci1394 problem (MMIO broken)" at http://bugzilla.kernel.org/show_bug.cgi?id=10080 And Gary Hade says: "The same change had also exposed an issue reported by Paul Martin that has been causing an Oops while hotplugging ThinkPads to a ThinkPad Dock II. See http://lkml.org/lkml/2008/2/19/405 http://bugzilla.kernel.org/show_bug.cgi?id=9961 I have a fix for the ThinkPad docking Oops but if the issue being discussed here is caused by the transparent bridge sizing removal change I totally agree that it should be reverted." The transparent bridge sizing removal change was motivated by insufficient PCI memory resource for a transparent bridge window that was being created as a result of expansion ROM(s) being included in the transparent bridge sizing calculations. A later "PCI: Remove default PCI expansion ROM memory allocation" change ( re: http://lkml.org/lkml/2007/12/11/361 ) removes the expansion ROM(s) from the transparent bridge sizing calculations which actually resolves the original issue in a different manner. So, even if the "PCI: remove transparent bridge sizing" is not problematic it is no longer needed anyway." Identified-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru> Tested-by: NThomas Meyer <thomas@m3y3r.de> Acked-by: NGary Hade <garyhade@us.ibm.com> Acked-by: NIngo Molnar <mingo@elte.hu> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 22 2月, 2008 1 次提交
-
-
由 Andrew Morton 提交于
Use upper_32_bits(): no code changes, one less ifdef. Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 03 2月, 2008 1 次提交
-
-
由 Sam Ravnborg 提交于
The following warnings were issued during build of drivers/pci with an allyesconfig build: WARNING: o-x86_64/drivers/pci/built-in.o(.text+0xdaf): Section mismatch in reference from the function pci_add_new_bus() to the function .devinit.text:pci_alloc_child_bus() WARNING: o-x86_64/drivers/pci/built-in.o(.text+0x15e2): Section mismatch in reference from the function pci_scan_single_device() to the function .devinit.text:pci_scan_device() WARNING: o-x86_64/drivers/pci/built-in.o(.text+0x1b0c5): Section mismatch in reference from the function pci_bus_assign_resources() to the function .devinit.text:pci_setup_bridge() WARNING: o-x86_64/drivers/pci/built-in.o(.text+0x1b32d): Section mismatch in reference from the function pci_bus_size_bridges() to the function .devinit.text:pci_bus_size_cardbus() Investigating each case closer it looked like all referred functions are only used in the init phase or during hotplug. So to avoid wasting too much memory in the non-hotplug case the simpler fix was to allow the fuctions to use code/data from the __devinit sections. This was done in all four case by adding the __ref annotation. Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Cc: Adrian Bunk <bunk@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 02 2月, 2008 1 次提交
-
-
由 Benjamin Herrenschmidt 提交于
The current pci_assign_unassigned_resources() code doesn't work properly on 32 bits platforms with 64 bits resources. The main reason is the use of unsigned long in various places instead of resource_size_t. This is a pre-requisite for making powerpc use the generic code instead of its own half-useful implementation. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 13 10月, 2007 1 次提交
-
-
由 Gary Hade 提交于
Remove transparent bridge sizing. Due to code in pci_read_bridge_bases() [drivers/pci/probe.c] the child bus of a transparent bridge already has access to the parent bus resources so transparent bridge sizing appears unnecessary. The bridge sizing includes alignment and granularity adjustments that can cause significantly more memory to be reserved from the parant bus than required by devices on the child bus and allotted by _CRS. Signed-off-by: NGary Hade <gary.hade@us.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 12 7月, 2007 1 次提交
-
-
由 Milind Arun Choudhary 提交于
ROUND_UP macro cleanup, use ALIGN where ever appropriate Signed-off-by: NMilind Arun Choudhary <milindchoudhary@gmail.com> Acked-by: NScott Murray <scottm@somanetworks.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 03 5月, 2007 1 次提交
-
-
由 Sam Ravnborg 提交于
Functions marked __devinit will be removed after kernel init. But being exported they are potentially called by a module much later. So the safer choice seems to be to keep the function even in the non CONFIG_HOTPLUG case. This silence the follwoing section mismatch warnings: WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_device from __ksymtab_gpl between '__ksymtab_pci_bus_add_device' (at offset 0x20) and '__ksymtab_pci_walk_bus' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_create_bus from __ksymtab_gpl between '__ksymtab_pci_create_bus' (at offset 0x40) and '__ksymtab_pci_stop_bus_device' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_max_busnr from __ksymtab_gpl between '__ksymtab_pci_bus_max_busnr' (at offset 0xc0) and '__ksymtab_pci_assign_resource_fixed' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_claim_resource from __ksymtab_gpl between '__ksymtab_pci_claim_resource' (at offset 0xe0) and '__ksymtab_pcie_port_bus_type' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_add_devices from __ksymtab between '__ksymtab_pci_bus_add_devices' (at offset 0x70) and '__ksymtab_pci_bus_alloc_resource' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_scan_bus_parented from __ksymtab between '__ksymtab_pci_scan_bus_parented' (at offset 0x90) and '__ksymtab_pci_root_buses' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_assign_resources from __ksymtab between '__ksymtab_pci_bus_assign_resources' (at offset 0x4d0) and '__ksymtab_pci_bus_size_bridges' WARNING: drivers/built-in.o - Section mismatch: reference to .init.text:pci_bus_size_bridges from __ksymtab between '__ksymtab_pci_bus_size_bridges' (at offset 0x4e0) and '__ksymtab_pci_setup_cardbus' Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 17 2月, 2007 1 次提交
-
-
由 Atsushi Nemoto 提交于
CARDBUS_MEM_SIZE was increased to 64MB on 2.6.20-rc2, but larger size might result in allocation failure for the reserving itself on some platforms (for example typical 32bit MIPS). Make it (and CARDBUS_IO_SIZE too) customizable by "pci=" option for such platforms. Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: Daniel Ritz <daniel.ritz@gmx.ch> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 23 12月, 2006 1 次提交
-
-
由 Andrew Morton 提交于
Linus sayeth: Google knows everything, and finds, on MS own site no less: "Windows 2000 default resources: One 4K memory window One 2 MB memory window Two 256-byte I/O windows" which is clearly utterly bogus and insufficient. But Microsoft apparently realized this, and: "Windows XP default resources: Because one memory window of 4K and one window of 2 MB are not sufficient for CardBus controllers in many configurations, Windows XP allocates larger memory windows to CardBus controllers where possible. However, resource windows are static (that is, the operating system does not dynamically allocate larger memory windows if new devices appear.) Under Windows XP, CardBus controllers will be assigned the following resources: One 4K memory window, as in Windows 2000 64 MB memory, if that amount of memory is available. If 64 MB is not available the controller will receive 32 MB; if 32 MB is not available, the controller will receive 16 MB; if 16 MB is not available, the bridge will receive 8 MB; and so on down to a minimum assignment of 1 MB in configurations where memory is too constrained for the operating system to provide a larger window. Two 256-byte I/O windows" So I think we have our answer. Windows uses one 4k window, and one 64MB window. And they are no more dynamic than we are (we _could_ try to do it dynamically, but let's face it, it's fairly painful to dynamically expand PCI bus resources - you may need to reprogram everything up to the root, so it would be absolutely crazy to do that unless you have some serious masochistic tendencies). So let's just increase our default value to 64M too. Cc: Markus Rechberger <mrechberger@gmail.com> Cc: Daniel Ritz <daniel.ritz@gmx.ch> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 04 10月, 2006 1 次提交
-
-
由 Kenji Kaneshige 提交于
Roland Dreier wrote: > The change "PCI: assign ioapic resource at hotplug" (commit > 23186279 in Linus's tree) makes > networking stop working on my system (SuperMicro H8QC8 with four > dual-core Opteron 885 CPUs). In particular, the on-board NIC stops > working, probably because it gets assigned the wrong IRQ (225 in the > non-working case, 217 in the working case) > > With that patch applied, e1000 doesn't work. Reverting just that > patch (shown below) from Linus's latest tree fixes things for me. > The cause of this problem might be an wrong assumption that the 'start' member of resource structure for ioapic device has non-zero value if the resources are assigned by firmware. The 'start' member of ioapic device seems not to be set even though the resources were actually assigned to ioapic devices by firmware. Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Cc: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com> Cc: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Roland Dreier <rdreier@cisco.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 27 9月, 2006 1 次提交
-
-
由 Satoru Takeuchi 提交于
We need to assign resources to ioapics being hot-added. This patch changes pbus_assign_resources_sorted() to assign resources if the ioapic has no assigned resources. Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NMUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com> Signed-off-by: NSatoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 28 6月, 2006 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
This is needed if we wish to change the size of the resource structures. Based on an original patch from Vivek Goyal <vgoyal@in.ibm.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 22 6月, 2006 1 次提交
-
-
由 Kimball Murray 提交于
A recent Stratus x86_64 platform uses a system ioapic that is a PCI device located below a PCI bridge. Other platforms like this may exist. This patch fixes a problem wherein the kernel's PCI setup code moves the ioapic to an address other than that assigned by the BIOS. It simply adds another exclusion (which already includes classless devices and host bridges) to the function pbus_assign_resources_sorted so that it will not move the ioapic. If the ioapic is moved, the fixmap mapping to it is broken, so the OS should leave it alone. From: Kimball Murray <kimball.murray@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 24 10月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
That's what we've always historically done, and bigger windows seem to confuse some cardbus bridges. Or something. Alan reports that this makes the ThinkPad 600x series work properly again: the 4kB IO window for some reason made IDE DMA not work, which makes IDE painfully slow even if it works after DMA timeouts. Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 10 9月, 2005 1 次提交
-
-
由 Dominik Brodowski 提交于
Share code between setup-bus.c and yenta_socket.c: use the write-out code of resources to the bridge also in yenta_socket.c, as it provides useful debug output. In addition, it fixes the bug that the CPU-centric resource view might need to be transferred to the PCI-centric view: setup-bus.c does that, while yenta-socket.c did not. Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 31 8月, 2005 1 次提交
-
-
由 Ivan Kokshaysky 提交于
I had some time to think about PCI assign issues in 2.6.13-rc series. The major problem here is that we call pci_assign_unassigned_resources() way too early - at subsys_initcall level. Therefore we give no chances to ACPI and PnP routines (called at fs_initcall level) to reserve their respective resources properly, as the comments in drivers/pnp/system.c and drivers/acpi/motherboard.c suggest: /** * Reserve motherboard resources after PCI claim BARs, * but before PCI assign resources for uninitialized PCI devices */ So I moved the pci_assign_unassigned_resources() call to pcibios_assign_resources() (fs_initcall), which should hopefully fix a lot of problems and make PCIBIOS_MIN_IO tweaks unnecessary. Other changes: - remove resource assignment code from pcibios_assign_resources(), since it duplicates pci_assign_unassigned_resources() functionality and actually does nothing in 2.6.13; - modify ROM assignment code as per Ben's suggestion: try to use firmware settings by default (if PCI_ASSIGN_ROMS is not set); - set CARDBUS_IO_SIZE back to 4K as it's a wonderful stress test for various setups. Confirmed by Tero Roponen <teanropo@cc.jyu.fi> (who had problems with the 4kB CardBus IO size previously). Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 27 8月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
It may seem small, but most cards need much less, if any, and this not only makes the code adhere to the comment, it seems to fix a boot-time lockup on a ThinkPad 380XD laptop reported by Tero Roponen <teanropo@cc.jyu.fi> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 30 7月, 2005 1 次提交
-
-
由 Ivan Kokshaysky 提交于
The setup-bus code doesn't work correctly for configurations with more than one display adapter in the same PCI domain. This stuff actually is a leftover of an early 2.4 PCI setup code and apparently it stopped working after some "bridge_ctl" changes. So the best thing we can do is just to remove it and rely on the fact that any firmware *has* to configure VGA port forwarding for the boot display device properly. But then we need to ensure that the bus->bridge_ctl will always contain valid information collected at the probe time, therefore the following change in pci_scan_bridge() is needed. Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 07 7月, 2005 1 次提交
-
-
由 Ivan Kokshaysky 提交于
There is a slight disagreement between setup-bus.c code and traditional x86 PCI setup wrt which recourses are invalid vs resources that are free for further allocations. In particular, in the setup-bus.c, if we failed to allocate some resource, we nullify "start" and "flags" fields, but *not* the "end" one. But x86 pcibios_enable_resources() does the following check: if (!r->start && r->end) { printk(KERN_ERR "PCI: Device %s not available because of resource collisions\n", pci_name(dev)); return -EINVAL; which means that the device owning the offending resource cannot be enabled. In particular, this breaks cardbus behind the normal decode p2p bridge - the cardbus code from setup-bus.c requests rather large IO and MEM windows, and if it fails, the socket is completely unavailable. Which is wrong, as the yenta code is capable to allocate smaller windows. Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 02 7月, 2005 1 次提交
-
-
由 Ivan Kokshaysky 提交于
- Add sanity check for io[port,mem]_resource in setup-bus.c. These resources look like "free" as they have no parents, but obviously we must not touch them. - In i386.c:pci_allocate_bus_resources(), if a bridge resource cannot be allocated for some reason, then clear its flags. This prevents any child allocations in this range, so the setup-bus code will work with a clean resource sub-tree. - i386.c:pcibios_enable_resources() doesn't enable bridges, as it checks only resources 0-5, which looks like a clear bug to me. I suspect it might break hotplug as well in some cases. From: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 28 6月, 2005 1 次提交
-
-
由 Rajesh Shah 提交于
When hot-plugging an I/O hierarchy that contains many bridges and leaf devices, it's possible that there are not enough resources to start all the device present. If we fail to assign a resource, clear the corresponding value in the pci_dev structure, so other code can take corrective action. Signed-off-by: NRajesh Shah <rajesh.shah@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
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!
-