Re: [PATCH] pci: adding support for PCI_MSI_IRQ_DOMAIN in ARC arch
Hi Bjorn, Did you have the chance to check this patch? Thanks. On 8/10/2016 6:55 PM, Vineet Gupta wrote: > On 08/09/2016 08:51 AM, Joao Pinto wrote: >> Due to the added dependency on PCI_MSI_IRQ_DOMAIN for all PCIe RC >> drivers, we were unable to build a RC solution for an ARC platform. >> >> To fix this, this patch adds ARC as a PCI_MSI_IRQ_DOMAIN supportive >> platform and adds the generation of msi.h in the ARC arch. >> >> Signed-off-by: Joao Pinto > > LGTM - Bjorn I presume you will pick this up ? > > -Vineet >> --- >> arch/arc/include/asm/Kbuild | 1 + >> drivers/pci/Kconfig | 2 +- >> 2 files changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild >> index 0b10ef2..c332604 100644 >> --- a/arch/arc/include/asm/Kbuild >> +++ b/arch/arc/include/asm/Kbuild >> @@ -25,6 +25,7 @@ generic-y += mcs_spinlock.h >> generic-y += mm-arch-hooks.h >> generic-y += mman.h >> generic-y += msgbuf.h >> +generic-y += msi.h >> generic-y += param.h >> generic-y += parport.h >> generic-y += pci.h >> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig >> index 67f9916..6555eb7 100644 >> --- a/drivers/pci/Kconfig >> +++ b/drivers/pci/Kconfig >> @@ -25,7 +25,7 @@ config PCI_MSI >> If you don't know what to do here, say Y. >> >> config PCI_MSI_IRQ_DOMAIN >> -def_bool ARM || ARM64 || X86 >> +def_bool ARC || ARM || ARM64 || X86 >> depends on PCI_MSI >> select GENERIC_MSI_IRQ_DOMAIN >> > > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] pci: adding support for PCI_MSI_IRQ_DOMAIN in ARC arch
On Tue, Aug 09, 2016 at 04:49:37PM +0100, Joao Pinto wrote: > To fix this, this patch adds ARC as a PCI_MSI_IRQ_DOMAIN supportive > platform and adds the generation of msi.h in the ARC arch. > > Signed-off-by: Joao Pinto I added Vineet's ack and put this on pci/msi for v4.9, thanks! > --- > arch/arc/include/asm/Kbuild | 1 + > drivers/pci/Kconfig | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild > index 0b10ef2..c332604 100644 > --- a/arch/arc/include/asm/Kbuild > +++ b/arch/arc/include/asm/Kbuild > @@ -25,6 +25,7 @@ generic-y += mcs_spinlock.h > generic-y += mm-arch-hooks.h > generic-y += mman.h > generic-y += msgbuf.h > +generic-y += msi.h > generic-y += param.h > generic-y += parport.h > generic-y += pci.h > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig > index 67f9916..6555eb7 100644 > --- a/drivers/pci/Kconfig > +++ b/drivers/pci/Kconfig > @@ -25,7 +25,7 @@ config PCI_MSI > If you don't know what to do here, say Y. > > config PCI_MSI_IRQ_DOMAIN > - def_bool ARM || ARM64 || X86 > + def_bool ARC || ARM || ARM64 || X86 > depends on PCI_MSI > select GENERIC_MSI_IRQ_DOMAIN > > -- > 1.8.1.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] pci: adding support for PCI_MSI_IRQ_DOMAIN in ARC arch
On 9/6/2016 4:57 PM, Bjorn Helgaas wrote: > On Tue, Aug 09, 2016 at 04:49:37PM +0100, Joao Pinto wrote: >> To fix this, this patch adds ARC as a PCI_MSI_IRQ_DOMAIN supportive >> platform and adds the generation of msi.h in the ARC arch. >> >> Signed-off-by: Joao Pinto > > I added Vineet's ack and put this on pci/msi for v4.9, thanks! Great! Thanks! > >> --- >> arch/arc/include/asm/Kbuild | 1 + >> drivers/pci/Kconfig | 2 +- >> 2 files changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild >> index 0b10ef2..c332604 100644 >> --- a/arch/arc/include/asm/Kbuild >> +++ b/arch/arc/include/asm/Kbuild >> @@ -25,6 +25,7 @@ generic-y += mcs_spinlock.h >> generic-y += mm-arch-hooks.h >> generic-y += mman.h >> generic-y += msgbuf.h >> +generic-y += msi.h >> generic-y += param.h >> generic-y += parport.h >> generic-y += pci.h >> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig >> index 67f9916..6555eb7 100644 >> --- a/drivers/pci/Kconfig >> +++ b/drivers/pci/Kconfig >> @@ -25,7 +25,7 @@ config PCI_MSI >> If you don't know what to do here, say Y. >> >> config PCI_MSI_IRQ_DOMAIN >> -def_bool ARM || ARM64 || X86 >> +def_bool ARC || ARM || ARM64 || X86 >> depends on PCI_MSI >> select GENERIC_MSI_IRQ_DOMAIN >> >> -- >> 1.8.1.5 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree?
On 09/06/2016 12:39 PM, gre...@linuxfoundation.org wrote: > On Tue, Sep 06, 2016 at 09:50:46AM -0700, Vineet Gupta wrote: >> On 09/05/2016 06:03 AM, gre...@linuxfoundation.org wrote: >>> The patch below was submitted to be applied to the 4.7-stable tree. >>> >>> I fail to see how this patch meets the stable kernel rules as found at >>> Documentation/stable_kernel_rules.txt. >>> >>> I could be totally wrong, and if so, please respond to >>> and let me know why this patch should be >>> applied. Otherwise, it is now dropped from my patch queues, never to be >>> seen again. >> Hi Greg, >> >> We are about to switch to new version of GNU tools (gcc 6.x based) which >> unfortunately has a non compatible ABI change - as described in the patch. >> >> Some of our customers are going to stick with older kernels and thus this >> helps >> them upgrade to newer tools with their existing baseline kernels. > That's nice, but it's a new feature. Stick with old userspace for older > kernels, and use new kernels for new userspace if you so desire. I understand your point. This is what we did at the time of upstreaming the kernel - and was something I was hoping to avoid this time because this is a flag day change. People get locked into kernel version or tools - when the kernel code itself didn't really change a bit. But if this really is against the norms of stable backports, then I suppose we can't do much ? Thx, -Vineet > > We do allow some new gcc fixes to be backported, but that's always where > we have found bugs, or build warnings. Not "we need to support gcc6 for > old kernels", as really, if someone wants to update userspace, they > don't update their kernel? > > thanks, > > greg k-h > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree?
On 09/06/2016 01:22 PM, Vineet Gupta wrote: > > Not "we need to support gcc6 for > > old kernels", as really, if someone wants to update userspace, they > > don't update their kernel? FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain the context more. Thing is your regular user/customer don't really care/know about these details. So there are tools bugs and more often than not the easy answer for tools providers is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so consider upgrading". So it is for such class of users that having such backports makes life a little easy. Thx, -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: WTF: patch "[PATCH] ARC: Support syscall ABI v4" was seriously submitted to be applied to the 4.7-stable tree?
On Tue, Sep 06, 2016 at 01:28:45PM -0700, Vineet Gupta wrote: > On 09/06/2016 01:22 PM, Vineet Gupta wrote: > > > Not "we need to support gcc6 for > > > old kernels", as really, if someone wants to update userspace, they > > > don't update their kernel? > > FWIW, I'm not arguing for the backport inclusion - I'm just trying to explain > the > context more. > > Thing is your regular user/customer don't really care/know about these > details. So > there are tools bugs and more often than not the easy answer for tools > providers > is "this is a known issue in gcc x.y which has been fixed in gcc x2.y2 so > consider > upgrading". So it is for such class of users that having such backports makes > life > a little easy. That's fine, but who would be upgrading their userspace gcc and then wanting to rebuild their kernel for an old kernel release? What prevents them from also updating their kernel? I understand the context, I'm just trying to say that this really is a "new feature" you are wanting here from what I can tell. I'd recommend just having people upgrade their kernel :) thanks, greg k-h ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
