Re: git repository for SR-IOV development?
Hello Lance, Thanks for your interest in SR-IOV. As Greg said we can't have a git tree for the change, but you are welcome to ask any question here and I also will keep you informed if there is any update on the SR-IOV patches. Thanks, Yu Greg KH wrote: On Thu, Nov 06, 2008 at 11:58:25AM -0800, H L wrote: --- On Thu, 11/6/08, Greg KH [EMAIL PROTECTED] wrote: On Thu, Nov 06, 2008 at 08:51:09AM -0800, H L wrote: Has anyone initiated or given consideration to the creation of a git repository (say, on kernel.org) for SR-IOV development? Why? It's only a few patches, right? Why would it need a whole new git tree? So as to minimize the time and effort patching a kernel, especially if the tree (and/or hash level) against which the patches were created fails to be specified on a mailing-list. Plus, there appears to be questions raised on how, precisely, the implementation should ultimately be modeled and especially given that, who knows at this point what number of patches will ultimately be submitted? I know I've built the 7-patch one (painfully, by the way), and I'm aware there's another 15-patch set out there which I've not yet examined. It's a mere 7 or 15 patches, you don't need a whole git tree for something small like that. Especially as there only seems to be one developer doing real work... thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-pci in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git repository for SR-IOV development?
Has anyone initiated or given consideration to the creation of a git repository (say, on kernel.org) for SR-IOV development? -- Lance Hartmann -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git repository for SR-IOV development?
On Thu, Nov 06, 2008 at 08:51:09AM -0800, H L wrote: Has anyone initiated or given consideration to the creation of a git repository (say, on kernel.org) for SR-IOV development? Why? It's only a few patches, right? Why would it need a whole new git tree? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git repository for SR-IOV development?
--- On Thu, 11/6/08, Greg KH [EMAIL PROTECTED] wrote: On Thu, Nov 06, 2008 at 08:51:09AM -0800, H L wrote: Has anyone initiated or given consideration to the creation of a git repository (say, on kernel.org) for SR-IOV development? Why? It's only a few patches, right? Why would it need a whole new git tree? So as to minimize the time and effort patching a kernel, especially if the tree (and/or hash level) against which the patches were created fails to be specified on a mailing-list. Plus, there appears to be questions raised on how, precisely, the implementation should ultimately be modeled and especially given that, who knows at this point what number of patches will ultimately be submitted? I know I've built the 7-patch one (painfully, by the way), and I'm aware there's another 15-patch set out there which I've not yet examined. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git repository for SR-IOV development?
On Thu, Nov 06, 2008 at 11:58:25AM -0800, H L wrote:
--- On Thu, 11/6/08, Greg KH [EMAIL PROTECTED] wrote:
On Thu, Nov 06, 2008 at 08:51:09AM -0800, H L wrote:
Has anyone initiated or given consideration to the
creation of a git
repository (say, on kernel.org) for SR-IOV
development?
Why? It's only a few patches, right? Why would it
need a whole new git
tree?
So as to minimize the time and effort patching a kernel, especially if
the tree (and/or hash level) against which the patches were created fails
to be specified on a mailing-list. Plus, there appears to be questions
raised on how, precisely, the implementation should ultimately be modeled
and especially given that, who knows at this point what number of patches
will ultimately be submitted? I know I've built the 7-patch one
(painfully, by the way), and I'm aware there's another 15-patch set out
there which I've not yet examined.
FWIW, the v6 patch series (this thread) applied to both 2.6.28-rc3
and the current Linus tree after a minor tweak to the first patch, as below.
--
Simon Horman
VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en
From: Yu Zhao [EMAIL PROTECTED]
[PATCH 1/16 v6] PCI: remove unnecessary arg of pci_update_resource()
This cleanup removes unnecessary argument 'struct resource *res' in
pci_update_resource(), so it takes same arguments as other companion
functions (pci_assign_resource(), etc.).
Cc: Alex Chiang [EMAIL PROTECTED]
Cc: Grant Grundler [EMAIL PROTECTED]
Cc: Greg KH [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: Jesse Barnes [EMAIL PROTECTED]
Cc: Matthew Wilcox [EMAIL PROTECTED]
Cc: Randy Dunlap [EMAIL PROTECTED]
Cc: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Yu Zhao [EMAIL PROTECTED]
Upported-by: Simon Horman [EMAIL PROTECTED]
---
drivers/pci/pci.c |4 ++--
drivers/pci/setup-res.c |7 ---
include/linux/pci.h |2 +-
3 files changed, 7 insertions(+), 6 deletions(-)
* Fri, 07 Nov 2008 09:05:18 +1100, Simon Horman
- Minor rediff of include/linux/pci.h section to apply to 2.6.28-rc3
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 4db261e..ae62f01 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -376,8 +376,8 @@ pci_restore_bars(struct pci_dev *dev)
return;
}
- for (i = 0; i numres; i ++)
- pci_update_resource(dev, dev-resource[i], i);
+ for (i = 0; i numres; i++)
+ pci_update_resource(dev, i);
}
static struct pci_platform_pm_ops *pci_platform_pm;
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 2dbd96c..b7ca679 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -26,11 +26,12 @@
#include pci.h
-void pci_update_resource(struct pci_dev *dev, struct resource *res, int resno)
+void pci_update_resource(struct pci_dev *dev, int resno)
{
struct pci_bus_region region;
u32 new, check, mask;
int reg;
+ struct resource *res = dev-resource + resno;
/*
* Ignore resources for unimplemented BARs and unused resource slots
@@ -162,7 +163,7 @@ int pci_assign_resource(struct pci_dev *dev, int resno)
} else {
res-flags = ~IORESOURCE_STARTALIGN;
if (resno PCI_BRIDGE_RESOURCES)
- pci_update_resource(dev, res, resno);
+ pci_update_resource(dev, resno);
}
return ret;
@@ -197,7 +198,7 @@ int pci_assign_resource_fixed(struct pci_dev *dev, int
resno)
dev_err(dev-dev, BAR %d: can't allocate %s resource %pR\n,
resno, res-flags IORESOURCE_IO ? I/O : mem, res);
} else if (resno PCI_BRIDGE_RESOURCES) {
- pci_update_resource(dev, res, resno);
+ pci_update_resource(dev, resno);
}
return ret;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 085187b..43e1fc1 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -626,7 +626,7 @@ int pcix_get_mmrbc(struct pci_dev *dev);
int pcie_set_readrq(struct pci_dev *dev, int rq);
int pci_reset_function(struct pci_dev *dev);
int pci_execute_reset_function(struct pci_dev *dev);
-void pci_update_resource(struct pci_dev *dev, struct resource *res, int resno);
+void pci_update_resource(struct pci_dev *dev, int resno);
int __must_check pci_assign_resource(struct pci_dev *dev, int i);
int pci_select_bars(struct pci_dev *dev, unsigned long flags);
--
1.5.6.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: git repository for SR-IOV development?
On Thu, Nov 06, 2008 at 11:58:25AM -0800, H L wrote: --- On Thu, 11/6/08, Greg KH [EMAIL PROTECTED] wrote: On Thu, Nov 06, 2008 at 08:51:09AM -0800, H L wrote: Has anyone initiated or given consideration to the creation of a git repository (say, on kernel.org) for SR-IOV development? Why? It's only a few patches, right? Why would it need a whole new git tree? So as to minimize the time and effort patching a kernel, especially if the tree (and/or hash level) against which the patches were created fails to be specified on a mailing-list. Plus, there appears to be questions raised on how, precisely, the implementation should ultimately be modeled and especially given that, who knows at this point what number of patches will ultimately be submitted? I know I've built the 7-patch one (painfully, by the way), and I'm aware there's another 15-patch set out there which I've not yet examined. It's a mere 7 or 15 patches, you don't need a whole git tree for something small like that. Especially as there only seems to be one developer doing real work... thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
