Re: [PATCH v3 00/44] Meta Linux Kernel Port
I actually found someone locally who signed my key. Good luck! On Tue, Feb 05, 2013 at 07:24:34PM +0530, Vineet Gupta wrote: > On Wednesday 30 January 2013 02:14 AM, Stephen Rothwell wrote: > > Hi Vineet, > > > > On Mon, 28 Jan 2013 12:40:24 +0530 Vineet Gupta > > wrote: > >> > >> Stephen, can you please add the following branch (rebased off 3.8-rc5) to > >> linux-next > >> > >> git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next > > > > Added from today (though there may not be a linux-next release today). > > Thanks Stephan - I see it in there for last 2 days now. > > >> While the first pull request can go directly from github, I presume the > >> logistics > >> for setting up accounts on kernel.org will only kick start after the first > >> batch > >> of code has been accepted. I can't seem to find any discussions on lists > >> to that > >> effect. > > > > Linus prefers to not pull from github, but will if you ask him to pull a > > tag signed with a verifiable gpg key. This is not a requirement if your > > tree is on kernel.org (though you still need a verifiable gpg key to get > > a kernel.org account). > > At the moment I don't have my key signed by anyone else. James pointed me to > http://www.kernel.org/signature.html so I've added myself to the google map > page > and there's obviously no one near me. So how do we solve this - can I call a > developer - who say trusts me - and get him to sign using my key-id. > > Richard I believe you were in a similar situation when submitting your port - > how > did you end up solving this. > > Damn! I was at ELCE back in November but wasn't aware of need for doing this. > > Thx, > -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
On Wednesday 30 January 2013 02:14 AM, Stephen Rothwell wrote: > Hi Vineet, > > On Mon, 28 Jan 2013 12:40:24 +0530 Vineet Gupta > wrote: >> >> Stephen, can you please add the following branch (rebased off 3.8-rc5) to >> linux-next >> >> git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next > > Added from today (though there may not be a linux-next release today). Thanks Stephan - I see it in there for last 2 days now. >> While the first pull request can go directly from github, I presume the >> logistics >> for setting up accounts on kernel.org will only kick start after the first >> batch >> of code has been accepted. I can't seem to find any discussions on lists to >> that >> effect. > > Linus prefers to not pull from github, but will if you ask him to pull a > tag signed with a verifiable gpg key. This is not a requirement if your > tree is on kernel.org (though you still need a verifiable gpg key to get > a kernel.org account). At the moment I don't have my key signed by anyone else. James pointed me to http://www.kernel.org/signature.html so I've added myself to the google map page and there's obviously no one near me. So how do we solve this - can I call a developer - who say trusts me - and get him to sign using my key-id. Richard I believe you were in a similar situation when submitting your port - how did you end up solving this. Damn! I was at ELCE back in November but wasn't aware of need for doing this. Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
On Wednesday 30 January 2013 02:14 AM, Stephen Rothwell wrote: Hi Vineet, On Mon, 28 Jan 2013 12:40:24 +0530 Vineet Gupta vineet.gup...@synopsys.com wrote: Stephen, can you please add the following branch (rebased off 3.8-rc5) to linux-next git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next Added from today (though there may not be a linux-next release today). Thanks Stephan - I see it in there for last 2 days now. While the first pull request can go directly from github, I presume the logistics for setting up accounts on kernel.org will only kick start after the first batch of code has been accepted. I can't seem to find any discussions on lists to that effect. Linus prefers to not pull from github, but will if you ask him to pull a tag signed with a verifiable gpg key. This is not a requirement if your tree is on kernel.org (though you still need a verifiable gpg key to get a kernel.org account). At the moment I don't have my key signed by anyone else. James pointed me to http://www.kernel.org/signature.html so I've added myself to the google map page and there's obviously no one near me. So how do we solve this - can I call a developer - who say trusts me - and get him to sign using my key-id. Richard I believe you were in a similar situation when submitting your port - how did you end up solving this. Damn! I was at ELCE back in November but wasn't aware of need for doing this. Thx, -Vineet -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
I actually found someone locally who signed my key. Good luck! On Tue, Feb 05, 2013 at 07:24:34PM +0530, Vineet Gupta wrote: On Wednesday 30 January 2013 02:14 AM, Stephen Rothwell wrote: Hi Vineet, On Mon, 28 Jan 2013 12:40:24 +0530 Vineet Gupta vineet.gup...@synopsys.com wrote: Stephen, can you please add the following branch (rebased off 3.8-rc5) to linux-next git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next Added from today (though there may not be a linux-next release today). Thanks Stephan - I see it in there for last 2 days now. While the first pull request can go directly from github, I presume the logistics for setting up accounts on kernel.org will only kick start after the first batch of code has been accepted. I can't seem to find any discussions on lists to that effect. Linus prefers to not pull from github, but will if you ask him to pull a tag signed with a verifiable gpg key. This is not a requirement if your tree is on kernel.org (though you still need a verifiable gpg key to get a kernel.org account). At the moment I don't have my key signed by anyone else. James pointed me to http://www.kernel.org/signature.html so I've added myself to the google map page and there's obviously no one near me. So how do we solve this - can I call a developer - who say trusts me - and get him to sign using my key-id. Richard I believe you were in a similar situation when submitting your port - how did you end up solving this. Damn! I was at ELCE back in November but wasn't aware of need for doing this. Thx, -Vineet -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Vineet, On Wed, 30 Jan 2013 07:44:52 +1100 Stephen Rothwell wrote: > > On Mon, 28 Jan 2013 12:40:24 +0530 Vineet Gupta > wrote: > > > > Stephen, can you please add the following branch (rebased off 3.8-rc5) to > > linux-next > > > > git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next > > Added from today (though there may not be a linux-next release today). > > > While the first pull request can go directly from github, I presume the > > logistics > > for setting up accounts on kernel.org will only kick start after the first > > batch > > of code has been accepted. I can't seem to find any discussions on lists to > > that > > effect. > > Linus prefers to not pull from github, but will if you ask him to pull a > tag signed with a verifiable gpg key. This is not a requirement if your > tree is on kernel.org (though you still need a verifiable gpg key to get > a kernel.org account). I forgot the legal boilerplate: Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au Legal Stuff: By participating in linux-next, your subsystem tree contributions are public and will be included in the linux-next trees. You may be sent e-mail messages indicating errors or other issues when the patches/commits from your subsystem tree are merged and tested in linux-next. These messages may also be cross-posted to the linux-next mailing list, the linux-kernel mailing list, etc. The linux-next tree project and IBM (my employer) make no warranties regarding the linux-next project, the testing procedures, the results, the e-mails, etc. If you don't agree to these ground rules, let me know and I'll remove your tree from participation in linux-next. pgpc8UGrqvBpT.pgp Description: PGP signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Vineet, On Mon, 28 Jan 2013 12:40:24 +0530 Vineet Gupta wrote: > > Stephen, can you please add the following branch (rebased off 3.8-rc5) to > linux-next > > git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next Added from today (though there may not be a linux-next release today). > While the first pull request can go directly from github, I presume the > logistics > for setting up accounts on kernel.org will only kick start after the first > batch > of code has been accepted. I can't seem to find any discussions on lists to > that > effect. Linus prefers to not pull from github, but will if you ask him to pull a tag signed with a verifiable gpg key. This is not a requirement if your tree is on kernel.org (though you still need a verifiable gpg key to get a kernel.org account). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpCcXSd3whRS.pgp Description: PGP signature
ARC Port for linux-next (was Re: [PATCH v3 00/44] Meta Linux Kernel Port)
Hi Stephen, On Monday 28 January 2013 12:40 PM, Vineet Gupta wrote: > Hi Arnd / Stephen, > > On Saturday 26 January 2013 05:55 AM, Arnd Bergmann wrote: >> I'd suggest that you both ask Stephen to add the trees to linux-next >> now (I thought you had done that already, but I don't see them there >> at the moment). > > Stephen, can you please add the following branch (rebased off 3.8-rc5) to > linux-next > > git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next > > With next-20130125, there's a trivial conflict in init/Kconfig - fixable by > accepting both the hunks. Please let me know if I'm missing anything before ARC Port could be added to linux-next. Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ARC Port for linux-next (was Re: [PATCH v3 00/44] Meta Linux Kernel Port)
Hi Stephen, On Monday 28 January 2013 12:40 PM, Vineet Gupta wrote: Hi Arnd / Stephen, On Saturday 26 January 2013 05:55 AM, Arnd Bergmann wrote: I'd suggest that you both ask Stephen to add the trees to linux-next now (I thought you had done that already, but I don't see them there at the moment). Stephen, can you please add the following branch (rebased off 3.8-rc5) to linux-next git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next With next-20130125, there's a trivial conflict in init/Kconfig - fixable by accepting both the hunks. Please let me know if I'm missing anything before ARC Port could be added to linux-next. Thx, -Vineet -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Vineet, On Mon, 28 Jan 2013 12:40:24 +0530 Vineet Gupta vineet.gup...@synopsys.com wrote: Stephen, can you please add the following branch (rebased off 3.8-rc5) to linux-next git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next Added from today (though there may not be a linux-next release today). While the first pull request can go directly from github, I presume the logistics for setting up accounts on kernel.org will only kick start after the first batch of code has been accepted. I can't seem to find any discussions on lists to that effect. Linus prefers to not pull from github, but will if you ask him to pull a tag signed with a verifiable gpg key. This is not a requirement if your tree is on kernel.org (though you still need a verifiable gpg key to get a kernel.org account). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpCcXSd3whRS.pgp Description: PGP signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Vineet, On Wed, 30 Jan 2013 07:44:52 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: On Mon, 28 Jan 2013 12:40:24 +0530 Vineet Gupta vineet.gup...@synopsys.com wrote: Stephen, can you please add the following branch (rebased off 3.8-rc5) to linux-next git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next Added from today (though there may not be a linux-next release today). While the first pull request can go directly from github, I presume the logistics for setting up accounts on kernel.org will only kick start after the first batch of code has been accepted. I can't seem to find any discussions on lists to that effect. Linus prefers to not pull from github, but will if you ask him to pull a tag signed with a verifiable gpg key. This is not a requirement if your tree is on kernel.org (though you still need a verifiable gpg key to get a kernel.org account). I forgot the legal boilerplate: Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au Legal Stuff: By participating in linux-next, your subsystem tree contributions are public and will be included in the linux-next trees. You may be sent e-mail messages indicating errors or other issues when the patches/commits from your subsystem tree are merged and tested in linux-next. These messages may also be cross-posted to the linux-next mailing list, the linux-kernel mailing list, etc. The linux-next tree project and IBM (my employer) make no warranties regarding the linux-next project, the testing procedures, the results, the e-mails, etc. If you don't agree to these ground rules, let me know and I'll remove your tree from participation in linux-next. pgpc8UGrqvBpT.pgp Description: PGP signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Vineet On 28/01/13 07:10, Vineet Gupta wrote: >> You don't need Acked-by statements on every single patch, but having >> more of those is certainly benefitial. When it comes to the merge >> window, please send a pull request to Linus, and keep me on Cc, >> so I can weigh in with an additional Ack to the series. > > While the first pull request can go directly from github, I presume the > logistics > for setting up accounts on kernel.org will only kick start after the first > batch > of code has been accepted. I can't seem to find any discussions on lists to > that > effect. this may be relevant: https://korg.wiki.kernel.org/index.php/Userdoc:getting_account > BTW I went back to hexagon submission patches in 2011 and it seems every new > arch > makes the exact same mistakes: > -idle sleep race > -faltering in TIF_WORK_RESUME and in fixing that breaking the syscall > restarting > -redundant symbols in module.c > ... > > Will it make sense to have a checklist-for-new-arches with concrete examples > of > broken and fixed code so that you, Al and other reviewers don't have to > repeat the > same thing over and over again. I suspect some of the problem is that the code will have been copied from other architectures which were subsequently fixed, but the fixes weren't being tracked while the out of tree port was being updated. I don't think it's a bad idea to have a checklist like that, but I think this is always going to continue to happen, and be dependent on when the arch port was first written, so such a checklist may well need updating lots based on what mistakes are most commonly made. I'd suggest the following generic things: * Work with upstream in the first place to minimise the period the arch is out of tree (tends not to happen as much as we'd all like). * Read linux-arch ML so that common per-arch problems are noticed as soon as they're apparent, and cc it when those sorts of issues are raised. * Look at comments for other/previous arch submissions (I definitely made a fair few fixes/changes after looking at c6x, tile, and arc comments). * Documenting these arch specific issues (like Al's signal brain dump which was very valuable to understand the subtleties). Cheers James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Vineet On 28/01/13 07:10, Vineet Gupta wrote: You don't need Acked-by statements on every single patch, but having more of those is certainly benefitial. When it comes to the merge window, please send a pull request to Linus, and keep me on Cc, so I can weigh in with an additional Ack to the series. While the first pull request can go directly from github, I presume the logistics for setting up accounts on kernel.org will only kick start after the first batch of code has been accepted. I can't seem to find any discussions on lists to that effect. this may be relevant: https://korg.wiki.kernel.org/index.php/Userdoc:getting_account BTW I went back to hexagon submission patches in 2011 and it seems every new arch makes the exact same mistakes: -idle sleep race -faltering in TIF_WORK_RESUME and in fixing that breaking the syscall restarting -redundant symbols in module.c ... Will it make sense to have a checklist-for-new-arches with concrete examples of broken and fixed code so that you, Al and other reviewers don't have to repeat the same thing over and over again. I suspect some of the problem is that the code will have been copied from other architectures which were subsequently fixed, but the fixes weren't being tracked while the out of tree port was being updated. I don't think it's a bad idea to have a checklist like that, but I think this is always going to continue to happen, and be dependent on when the arch port was first written, so such a checklist may well need updating lots based on what mistakes are most commonly made. I'd suggest the following generic things: * Work with upstream in the first place to minimise the period the arch is out of tree (tends not to happen as much as we'd all like). * Read linux-arch ML so that common per-arch problems are noticed as soon as they're apparent, and cc it when those sorts of issues are raised. * Look at comments for other/previous arch submissions (I definitely made a fair few fixes/changes after looking at c6x, tile, and arc comments). * Documenting these arch specific issues (like Al's signal brain dump which was very valuable to understand the subtleties). Cheers James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Arnd / Stephen, On Saturday 26 January 2013 05:55 AM, Arnd Bergmann wrote: > On Friday 25 January 2013, James Hogan wrote: >> Hi Arnd, >> >> On 10/01/13 15:30, James Hogan wrote: >>> This patchset adds core architecture support to Linux for Imagination's >>> Meta ATP (Meta 1) and HTP (Meta 2) processor cores. Most of the feedback >>> from the RFC and v2 patchsets has now been addressed. All further >>> feedback is most welcome. >>> >>> The patches are based on next-20130110, and can also be found in the >>> following git tree: >>> git://github.com/jahogan/metag-linux.git metag-core >> >> Review seems to have gone quiet. I'm fairly happy with this core >> patchset in it's currently form (only trivial alterations required since >> the v3 patches, e.g. some review comments and rebasing on linus/master), >> and would like to get it into the v3.9 merge window. What's the best way >> forward? I presume I need to get acks on each individual patch? > > > I've just looked through the entire series once more and could not find > any show-stoppers. I consider this ready for 3.9, and I'm also quite happy > with Vineet's ARC port, although I think he is still integrating some > feedback comments. AFAIKS, I've already addressed all the comments in v1 and v2 except moving the clocksources/clockevent code to drivers. If that is a must, I can do that, although personally I think it is too arch specific (tied to ARC specific RTSC insn and such) to be moved out of arch code. Can you please skim thru the latest v3 series, or just part #1 (changes since v2) if that's too big to reconfirm. > I'd suggest that you both ask Stephen to add the trees to linux-next > now (I thought you had done that already, but I don't see them there > at the moment). Stephen, can you please add the following branch (rebased off 3.8-rc5) to linux-next git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next With next-20130125, there's a trivial conflict in init/Kconfig - fixable by accepting both the hunks. > You don't need Acked-by statements on every single patch, but having > more of those is certainly benefitial. When it comes to the merge > window, please send a pull request to Linus, and keep me on Cc, > so I can weigh in with an additional Ack to the series. While the first pull request can go directly from github, I presume the logistics for setting up accounts on kernel.org will only kick start after the first batch of code has been accepted. I can't seem to find any discussions on lists to that effect. > Until then, maybe you can have another look at each other's architecture > trees (ARC and Meta). Since you are in exactly the same situation with > upstream integration now, you are probably the best people to review > the code, and you providing ACKs and constructive feedback to the other > tree will helps others see that you are up to the job as an arch > maintainer. I'm certain we've both been looking at each other's patches in last few months - I certainly have for say DeviceTree support so it makes sense to formalize it. Although "Reviewed-by" will probably be better off that "Ack" in this case. > I have also given a few comments to one of you that > may actually apply to the other one just as well, but I can't remember > now what I discussed with whom ;-) OK, will re-skim thru all such discussions, although ARC comments are likely to be superset of metag :-) BTW I went back to hexagon submission patches in 2011 and it seems every new arch makes the exact same mistakes: -idle sleep race -faltering in TIF_WORK_RESUME and in fixing that breaking the syscall restarting -redundant symbols in module.c ... Will it make sense to have a checklist-for-new-arches with concrete examples of broken and fixed code so that you, Al and other reviewers don't have to repeat the same thing over and over again. Thx, -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Arnd / Stephen, On Saturday 26 January 2013 05:55 AM, Arnd Bergmann wrote: On Friday 25 January 2013, James Hogan wrote: Hi Arnd, On 10/01/13 15:30, James Hogan wrote: This patchset adds core architecture support to Linux for Imagination's Meta ATP (Meta 1) and HTP (Meta 2) processor cores. Most of the feedback from the RFC and v2 patchsets has now been addressed. All further feedback is most welcome. The patches are based on next-20130110, and can also be found in the following git tree: git://github.com/jahogan/metag-linux.git metag-core Review seems to have gone quiet. I'm fairly happy with this core patchset in it's currently form (only trivial alterations required since the v3 patches, e.g. some review comments and rebasing on linus/master), and would like to get it into the v3.9 merge window. What's the best way forward? I presume I need to get acks on each individual patch? I've just looked through the entire series once more and could not find any show-stoppers. I consider this ready for 3.9, and I'm also quite happy with Vineet's ARC port, although I think he is still integrating some feedback comments. AFAIKS, I've already addressed all the comments in v1 and v2 except moving the clocksources/clockevent code to drivers. If that is a must, I can do that, although personally I think it is too arch specific (tied to ARC specific RTSC insn and such) to be moved out of arch code. Can you please skim thru the latest v3 series, or just part #1 (changes since v2) if that's too big to reconfirm. I'd suggest that you both ask Stephen to add the trees to linux-next now (I thought you had done that already, but I don't see them there at the moment). Stephen, can you please add the following branch (rebased off 3.8-rc5) to linux-next git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git arc-next With next-20130125, there's a trivial conflict in init/Kconfig - fixable by accepting both the hunks. You don't need Acked-by statements on every single patch, but having more of those is certainly benefitial. When it comes to the merge window, please send a pull request to Linus, and keep me on Cc, so I can weigh in with an additional Ack to the series. While the first pull request can go directly from github, I presume the logistics for setting up accounts on kernel.org will only kick start after the first batch of code has been accepted. I can't seem to find any discussions on lists to that effect. Until then, maybe you can have another look at each other's architecture trees (ARC and Meta). Since you are in exactly the same situation with upstream integration now, you are probably the best people to review the code, and you providing ACKs and constructive feedback to the other tree will helps others see that you are up to the job as an arch maintainer. I'm certain we've both been looking at each other's patches in last few months - I certainly have for say DeviceTree support so it makes sense to formalize it. Although Reviewed-by will probably be better off that Ack in this case. I have also given a few comments to one of you that may actually apply to the other one just as well, but I can't remember now what I discussed with whom ;-) OK, will re-skim thru all such discussions, although ARC comments are likely to be superset of metag :-) BTW I went back to hexagon submission patches in 2011 and it seems every new arch makes the exact same mistakes: -idle sleep race -faltering in TIF_WORK_RESUME and in fixing that breaking the syscall restarting -redundant symbols in module.c ... Will it make sense to have a checklist-for-new-arches with concrete examples of broken and fixed code so that you, Al and other reviewers don't have to repeat the same thing over and over again. Thx, -Vineet -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Arnd, On Sat, Jan 26, 2013 at 12:25:09AM +, Arnd Bergmann wrote: > On Friday 25 January 2013, James Hogan wrote: > > Review seems to have gone quiet. I'm fairly happy with this core > > patchset in it's currently form (only trivial alterations required since > > the v3 patches, e.g. some review comments and rebasing on linus/master), > > and would like to get it into the v3.9 merge window. What's the best way > > forward? I presume I need to get acks on each individual patch? > > > I've just looked through the entire series once more and could not find > any show-stoppers. I consider this ready for 3.9, and I'm also quite happy > with Vineet's ARC port, although I think he is still integrating some > feedback comments. Thanks for taking another look over it and for all the guidance. > I'd suggest that you both ask Stephen to add the trees to linux-next > now (I thought you had done that already, but I don't see them there > at the moment). Okay. Yeh, I was holding off expecting to need more acks. > You don't need Acked-by statements on every single patch, but having > more of those is certainly benefitial. When it comes to the merge > window, please send a pull request to Linus, and keep me on Cc, > so I can weigh in with an additional Ack to the series. Okay, I'll try and get some more acks on specific patches. > Until then, maybe you can have another look at each other's architecture > trees (ARC and Meta). Since you are in exactly the same situation with > upstream integration now, you are probably the best people to review > the code, and you providing ACKs and constructive feedback to the other > tree will helps others see that you are up to the job as an arch > maintainer. I have also given a few comments to one of you that > may actually apply to the other one just as well, but I can't remember > now what I discussed with whom ;-) Good idea. I've been working on a few changes already based on ARC feedback which also applies to Meta :-) Cheers James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Arnd, On Sat, Jan 26, 2013 at 12:25:09AM +, Arnd Bergmann wrote: On Friday 25 January 2013, James Hogan wrote: Review seems to have gone quiet. I'm fairly happy with this core patchset in it's currently form (only trivial alterations required since the v3 patches, e.g. some review comments and rebasing on linus/master), and would like to get it into the v3.9 merge window. What's the best way forward? I presume I need to get acks on each individual patch? I've just looked through the entire series once more and could not find any show-stoppers. I consider this ready for 3.9, and I'm also quite happy with Vineet's ARC port, although I think he is still integrating some feedback comments. Thanks for taking another look over it and for all the guidance. I'd suggest that you both ask Stephen to add the trees to linux-next now (I thought you had done that already, but I don't see them there at the moment). Okay. Yeh, I was holding off expecting to need more acks. You don't need Acked-by statements on every single patch, but having more of those is certainly benefitial. When it comes to the merge window, please send a pull request to Linus, and keep me on Cc, so I can weigh in with an additional Ack to the series. Okay, I'll try and get some more acks on specific patches. Until then, maybe you can have another look at each other's architecture trees (ARC and Meta). Since you are in exactly the same situation with upstream integration now, you are probably the best people to review the code, and you providing ACKs and constructive feedback to the other tree will helps others see that you are up to the job as an arch maintainer. I have also given a few comments to one of you that may actually apply to the other one just as well, but I can't remember now what I discussed with whom ;-) Good idea. I've been working on a few changes already based on ARC feedback which also applies to Meta :-) Cheers James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
On Friday 25 January 2013, James Hogan wrote: > Hi Arnd, > > On 10/01/13 15:30, James Hogan wrote: > > This patchset adds core architecture support to Linux for Imagination's > > Meta ATP (Meta 1) and HTP (Meta 2) processor cores. Most of the feedback > > from the RFC and v2 patchsets has now been addressed. All further > > feedback is most welcome. > > > > The patches are based on next-20130110, and can also be found in the > > following git tree: > > git://github.com/jahogan/metag-linux.git metag-core > > Review seems to have gone quiet. I'm fairly happy with this core > patchset in it's currently form (only trivial alterations required since > the v3 patches, e.g. some review comments and rebasing on linus/master), > and would like to get it into the v3.9 merge window. What's the best way > forward? I presume I need to get acks on each individual patch? I've just looked through the entire series once more and could not find any show-stoppers. I consider this ready for 3.9, and I'm also quite happy with Vineet's ARC port, although I think he is still integrating some feedback comments. I'd suggest that you both ask Stephen to add the trees to linux-next now (I thought you had done that already, but I don't see them there at the moment). You don't need Acked-by statements on every single patch, but having more of those is certainly benefitial. When it comes to the merge window, please send a pull request to Linus, and keep me on Cc, so I can weigh in with an additional Ack to the series. Until then, maybe you can have another look at each other's architecture trees (ARC and Meta). Since you are in exactly the same situation with upstream integration now, you are probably the best people to review the code, and you providing ACKs and constructive feedback to the other tree will helps others see that you are up to the job as an arch maintainer. I have also given a few comments to one of you that may actually apply to the other one just as well, but I can't remember now what I discussed with whom ;-) Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Arnd, On 10/01/13 15:30, James Hogan wrote: > This patchset adds core architecture support to Linux for Imagination's > Meta ATP (Meta 1) and HTP (Meta 2) processor cores. Most of the feedback > from the RFC and v2 patchsets has now been addressed. All further > feedback is most welcome. > > The patches are based on next-20130110, and can also be found in the > following git tree: > git://github.com/jahogan/metag-linux.git metag-core Review seems to have gone quiet. I'm fairly happy with this core patchset in it's currently form (only trivial alterations required since the v3 patches, e.g. some review comments and rebasing on linus/master), and would like to get it into the v3.9 merge window. What's the best way forward? I presume I need to get acks on each individual patch? Cheers James > > Meta cores are 32-bit, hardware multithreaded, general purpose, embedded > processors which also feature a DSP instruction set, and can be found in > many digital radios. They are capable of running different operating > systems on different hardware threads, for example a digital radio might > run RTOSes for DAB decoding and audio decoding on 3 hardware threads, > and run Linux on the 4th hardware thread to manage the user interface, > networking etc. HTPs are also capable of running SMP Linux on multiple > hardware threads. > > A buildroot tree containing toolchain patches can be found here (use > meta2_defconfig): > git://github.com/img-meta/metag-buildroot.git metag-core > > Freely available instruction set and architecture overview documents can > be found on the following page: > http://www.imgtec.com/downloads.asp > > --- > v3 (tag: metag-core-v3): > > changes since v2 > * tree: > * rebased on linux-next and related changes > * integrated generic kernel_thread/kernel_execve into patches > * signals: > * replace do_notify_resume with do_work_pending containing signal > handling loop (Al Viro) > * handlerless local syscall restart (Al Viro) > * fix rt_sigreturn's do_sigaltstack handling (Al Viro) > * explicitly detect rt_sigreturn and treat as non-syscall for purposes > of syscall restart (Al Viro) > * refactor syscall restart code based on arm > * use generic sigaltstack > * irq handling: > * move irq drivers into drivers/irqchip/ (Arnd) > * switch to sparse irq (Arnd) > * allow per machine override of nr_irqs > * switch root TBI, internal, and external interrupt drivers to linear > irqdomain > * implement masking in internal interrupt driver > * system calls: > * remove magic pt_regs 7th syscall argument (Al Viro) > * use generic sys_clone (Al Viro) > * fix use of 0 for invalid syscall number (use -1 instead) > * documentation > * added Documentation/kernel-ABI.txt describing various ABIs (Al Viro) > * tbx: > * move tbx/tbicache.c to mm/cache.c and refactor / clean up (Joe > Perches) > * clean up tbx/tbistring.c > * rename asm/lock.h->asm/global_lock.h, remove dependence on tbx > * update all lock users to use asm/global_lock.h rather than tbx > macros > * add and use __core_reg_[gs]et macros to replace TBI_[GS]ETREG > * make use of compiler builtins for cache/tlb handling instructions > rather than tbx macros > * tty/metag_da: > * mostly rewritten to address Alan Cox' feedback > * use del_timer_sync() where appropriate (Alan Cox) > * convert to use tty_port helpers (Alan Cox) > * fix tty kref safety (Alan Cox) > * implement proper output buffering (Alan Cox) > * fix init error handling > * implement hangup (Alan Cox) > * omit specific baud rate (Alan Cox) > * boot: > * switch to generic CMDLINE Kconfig symbols (Sam Ravnborg) > * alignment patches > * removed taskstats changes (see "netlink: align attributes on > 64-bits" patches) > * rework CONFIG_HAVE_64BIT_ALIGNED_ACCESS patch for clarity > > feedback not addressed: > * proper inversion of Kconfig dependency lists (Greg, Arnd) > I'll do this as a separate patch set as arch/metag doesn't directly > depend on it. > > > v2 (tag: metag-core-v2): > > changes based on rfc-v1 review feedback: > * moved build infrastructure patch later (Sam Ravnborg) > * various build system cleanups (Sam Ravnborg) > * split generic build changes out of main build patch (Sam Ravnborg) > * deprecate powervr DT vendor id (Rob Herring) > * ftrace now uses recordmcount.c (Steven Rostedt) > * fixed imgdafs fserrno problem (Al Viro) > * io.h changes, inline asm, removed casts, added metag_in/out (Arnd) > * remove bus_to_virt (Arnd) > * use asm-generic/syscalls.h (Arnd) > * remove superfluous metag_spinlock system call (Arnd) > * renamed packed 64bit arg syscall wrappers (Arnd) > > other changes: > * rebased on v3.7-rc8 > * changes based on v3.6..v3.7-rc8 patches > * uapi disintegration (thanks to David Howells for the assistance) > * add cmpdi2/ucmpdi2 intrinsics and clean up lib Makefile > * fix numa build > * split memory management patch into 6 separate
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Arnd, On 10/01/13 15:30, James Hogan wrote: This patchset adds core architecture support to Linux for Imagination's Meta ATP (Meta 1) and HTP (Meta 2) processor cores. Most of the feedback from the RFC and v2 patchsets has now been addressed. All further feedback is most welcome. The patches are based on next-20130110, and can also be found in the following git tree: git://github.com/jahogan/metag-linux.git metag-core Review seems to have gone quiet. I'm fairly happy with this core patchset in it's currently form (only trivial alterations required since the v3 patches, e.g. some review comments and rebasing on linus/master), and would like to get it into the v3.9 merge window. What's the best way forward? I presume I need to get acks on each individual patch? Cheers James Meta cores are 32-bit, hardware multithreaded, general purpose, embedded processors which also feature a DSP instruction set, and can be found in many digital radios. They are capable of running different operating systems on different hardware threads, for example a digital radio might run RTOSes for DAB decoding and audio decoding on 3 hardware threads, and run Linux on the 4th hardware thread to manage the user interface, networking etc. HTPs are also capable of running SMP Linux on multiple hardware threads. A buildroot tree containing toolchain patches can be found here (use meta2_defconfig): git://github.com/img-meta/metag-buildroot.git metag-core Freely available instruction set and architecture overview documents can be found on the following page: http://www.imgtec.com/downloads.asp --- v3 (tag: metag-core-v3): changes since v2 * tree: * rebased on linux-next and related changes * integrated generic kernel_thread/kernel_execve into patches * signals: * replace do_notify_resume with do_work_pending containing signal handling loop (Al Viro) * handlerless local syscall restart (Al Viro) * fix rt_sigreturn's do_sigaltstack handling (Al Viro) * explicitly detect rt_sigreturn and treat as non-syscall for purposes of syscall restart (Al Viro) * refactor syscall restart code based on arm * use generic sigaltstack * irq handling: * move irq drivers into drivers/irqchip/ (Arnd) * switch to sparse irq (Arnd) * allow per machine override of nr_irqs * switch root TBI, internal, and external interrupt drivers to linear irqdomain * implement masking in internal interrupt driver * system calls: * remove magic pt_regs 7th syscall argument (Al Viro) * use generic sys_clone (Al Viro) * fix use of 0 for invalid syscall number (use -1 instead) * documentation * added Documentation/kernel-ABI.txt describing various ABIs (Al Viro) * tbx: * move tbx/tbicache.c to mm/cache.c and refactor / clean up (Joe Perches) * clean up tbx/tbistring.c * rename asm/lock.h-asm/global_lock.h, remove dependence on tbx * update all lock users to use asm/global_lock.h rather than tbx macros * add and use __core_reg_[gs]et macros to replace TBI_[GS]ETREG * make use of compiler builtins for cache/tlb handling instructions rather than tbx macros * tty/metag_da: * mostly rewritten to address Alan Cox' feedback * use del_timer_sync() where appropriate (Alan Cox) * convert to use tty_port helpers (Alan Cox) * fix tty kref safety (Alan Cox) * implement proper output buffering (Alan Cox) * fix init error handling * implement hangup (Alan Cox) * omit specific baud rate (Alan Cox) * boot: * switch to generic CMDLINE Kconfig symbols (Sam Ravnborg) * alignment patches * removed taskstats changes (see netlink: align attributes on 64-bits patches) * rework CONFIG_HAVE_64BIT_ALIGNED_ACCESS patch for clarity feedback not addressed: * proper inversion of Kconfig dependency lists (Greg, Arnd) I'll do this as a separate patch set as arch/metag doesn't directly depend on it. v2 (tag: metag-core-v2): changes based on rfc-v1 review feedback: * moved build infrastructure patch later (Sam Ravnborg) * various build system cleanups (Sam Ravnborg) * split generic build changes out of main build patch (Sam Ravnborg) * deprecate powervr DT vendor id (Rob Herring) * ftrace now uses recordmcount.c (Steven Rostedt) * fixed imgdafs fserrno problem (Al Viro) * io.h changes, inline asm, removed casts, added metag_in/out (Arnd) * remove bus_to_virt (Arnd) * use asm-generic/syscalls.h (Arnd) * remove superfluous metag_spinlock system call (Arnd) * renamed packed 64bit arg syscall wrappers (Arnd) other changes: * rebased on v3.7-rc8 * changes based on v3.6..v3.7-rc8 patches * uapi disintegration (thanks to David Howells for the assistance) * add cmpdi2/ucmpdi2 intrinsics and clean up lib Makefile * fix numa build * split memory management patch into 6 separate patches to make them more manageable and stop them bouncing: * cache/tlb handling * memory management *
Re: [PATCH v3 00/44] Meta Linux Kernel Port
On Friday 25 January 2013, James Hogan wrote: Hi Arnd, On 10/01/13 15:30, James Hogan wrote: This patchset adds core architecture support to Linux for Imagination's Meta ATP (Meta 1) and HTP (Meta 2) processor cores. Most of the feedback from the RFC and v2 patchsets has now been addressed. All further feedback is most welcome. The patches are based on next-20130110, and can also be found in the following git tree: git://github.com/jahogan/metag-linux.git metag-core Review seems to have gone quiet. I'm fairly happy with this core patchset in it's currently form (only trivial alterations required since the v3 patches, e.g. some review comments and rebasing on linus/master), and would like to get it into the v3.9 merge window. What's the best way forward? I presume I need to get acks on each individual patch? I've just looked through the entire series once more and could not find any show-stoppers. I consider this ready for 3.9, and I'm also quite happy with Vineet's ARC port, although I think he is still integrating some feedback comments. I'd suggest that you both ask Stephen to add the trees to linux-next now (I thought you had done that already, but I don't see them there at the moment). You don't need Acked-by statements on every single patch, but having more of those is certainly benefitial. When it comes to the merge window, please send a pull request to Linus, and keep me on Cc, so I can weigh in with an additional Ack to the series. Until then, maybe you can have another look at each other's architecture trees (ARC and Meta). Since you are in exactly the same situation with upstream integration now, you are probably the best people to review the code, and you providing ACKs and constructive feedback to the other tree will helps others see that you are up to the job as an arch maintainer. I have also given a few comments to one of you that may actually apply to the other one just as well, but I can't remember now what I discussed with whom ;-) Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
On 19/01/13 05:55, Al Viro wrote: > On Sat, Jan 12, 2013 at 09:55:07AM +, James Hogan wrote: >> Hi Stephen, Al, >> >> On Sat, Jan 12, 2013 at 12:09:57PM +1100, Stephen Rothwell wrote: >>> On Fri, 11 Jan 2013 15:02:06 + James Hogan >>> wrote: Okay, I've rebased the metag tree from linux-next onto the master branch of Al's signal tree (to get Vineet's GENERIC_SIGALTSTACK fix and GENERIC_SIGALTSTACK's eventual removal). >>> >>> OK, but I hope you mentioned not rebasing to Al. >> >> I'm still rebasing the metag tree, and it's not quite ready for -next so >> I don't mind if Al's tree rebases at this stage tbh. >> >> Al: I don't know if you normally rebase your tree, but if it's okay with >> you I'll let you know when I need it not to be rebased. > > Umm... > 1) #master is definitely bad for base; #for-linus is much safer (and > sufficient for your case) Thanks for that, and I see it's now merged into Linus' tree so I'll rebase onto that instead. Cheers James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
On 19/01/13 05:55, Al Viro wrote: On Sat, Jan 12, 2013 at 09:55:07AM +, James Hogan wrote: Hi Stephen, Al, On Sat, Jan 12, 2013 at 12:09:57PM +1100, Stephen Rothwell wrote: On Fri, 11 Jan 2013 15:02:06 + James Hogan james.ho...@imgtec.com wrote: Okay, I've rebased the metag tree from linux-next onto the master branch of Al's signal tree (to get Vineet's GENERIC_SIGALTSTACK fix and GENERIC_SIGALTSTACK's eventual removal). OK, but I hope you mentioned not rebasing to Al. I'm still rebasing the metag tree, and it's not quite ready for -next so I don't mind if Al's tree rebases at this stage tbh. Al: I don't know if you normally rebase your tree, but if it's okay with you I'll let you know when I need it not to be rebased. Umm... 1) #master is definitely bad for base; #for-linus is much safer (and sufficient for your case) Thanks for that, and I see it's now merged into Linus' tree so I'll rebase onto that instead. Cheers James -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
On Sat, Jan 12, 2013 at 09:55:07AM +, James Hogan wrote: > Hi Stephen, Al, > > On Sat, Jan 12, 2013 at 12:09:57PM +1100, Stephen Rothwell wrote: > > On Fri, 11 Jan 2013 15:02:06 + James Hogan > > wrote: > > > > > > Okay, I've rebased the metag tree from linux-next onto the master branch > > > of Al's signal tree (to get Vineet's GENERIC_SIGALTSTACK fix and > > > GENERIC_SIGALTSTACK's eventual removal). > > > > OK, but I hope you mentioned not rebasing to Al. > > I'm still rebasing the metag tree, and it's not quite ready for -next so > I don't mind if Al's tree rebases at this stage tbh. > > Al: I don't know if you normally rebase your tree, but if it's okay with > you I'll let you know when I need it not to be rebased. Umm... 1) #master is definitely bad for base; #for-linus is much safer (and sufficient for your case) 2) I'm a couple of fix folds away from opening #no-rebase (and yes, it'll be a superset of #for-linus) FWIW, I'd suggest a rebase on top of signal.git#for-linus. Noting in the stem is visibly relevant in your case, AFAICS... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
On Sat, Jan 12, 2013 at 09:55:07AM +, James Hogan wrote: Hi Stephen, Al, On Sat, Jan 12, 2013 at 12:09:57PM +1100, Stephen Rothwell wrote: On Fri, 11 Jan 2013 15:02:06 + James Hogan james.ho...@imgtec.com wrote: Okay, I've rebased the metag tree from linux-next onto the master branch of Al's signal tree (to get Vineet's GENERIC_SIGALTSTACK fix and GENERIC_SIGALTSTACK's eventual removal). OK, but I hope you mentioned not rebasing to Al. I'm still rebasing the metag tree, and it's not quite ready for -next so I don't mind if Al's tree rebases at this stage tbh. Al: I don't know if you normally rebase your tree, but if it's okay with you I'll let you know when I need it not to be rebased. Umm... 1) #master is definitely bad for base; #for-linus is much safer (and sufficient for your case) 2) I'm a couple of fix folds away from opening #no-rebase (and yes, it'll be a superset of #for-linus) FWIW, I'd suggest a rebase on top of signal.git#for-linus. Noting in the stem is visibly relevant in your case, AFAICS... -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi James, On Sat, 12 Jan 2013 09:55:07 + James Hogan wrote: > > Would "sufficiently ready" normally mean "in a state ready to send a > pull request to Linus"? That is the usual criteria. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp9Q9GPvSzrc.pgp Description: PGP signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Stephen, Al, On Sat, Jan 12, 2013 at 12:09:57PM +1100, Stephen Rothwell wrote: > On Fri, 11 Jan 2013 15:02:06 + James Hogan wrote: > > > > Okay, I've rebased the metag tree from linux-next onto the master branch > > of Al's signal tree (to get Vineet's GENERIC_SIGALTSTACK fix and > > GENERIC_SIGALTSTACK's eventual removal). > > OK, but I hope you mentioned not rebasing to Al. I'm still rebasing the metag tree, and it's not quite ready for -next so I don't mind if Al's tree rebases at this stage tbh. Al: I don't know if you normally rebase your tree, but if it's okay with you I'll let you know when I need it not to be rebased. > > git://github.com/jahogan/metag-linux.git > > branch: metag-core > > tag: metag-core-v3.1 > > When you think it is sufficiently ready (and I am guessing that it is > getting pretty close), please send me a request to add it to linux-next. Thanks, will do. Would "sufficiently ready" normally mean "in a state ready to send a pull request to Linus"? Thanks James pgp_Q4rmBR0Ki.pgp Description: PGP signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Stephen, Al, On Sat, Jan 12, 2013 at 12:09:57PM +1100, Stephen Rothwell wrote: On Fri, 11 Jan 2013 15:02:06 + James Hogan james.ho...@imgtec.com wrote: Okay, I've rebased the metag tree from linux-next onto the master branch of Al's signal tree (to get Vineet's GENERIC_SIGALTSTACK fix and GENERIC_SIGALTSTACK's eventual removal). OK, but I hope you mentioned not rebasing to Al. I'm still rebasing the metag tree, and it's not quite ready for -next so I don't mind if Al's tree rebases at this stage tbh. Al: I don't know if you normally rebase your tree, but if it's okay with you I'll let you know when I need it not to be rebased. git://github.com/jahogan/metag-linux.git branch: metag-core tag: metag-core-v3.1 When you think it is sufficiently ready (and I am guessing that it is getting pretty close), please send me a request to add it to linux-next. Thanks, will do. Would sufficiently ready normally mean in a state ready to send a pull request to Linus? Thanks James pgp_Q4rmBR0Ki.pgp Description: PGP signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi James, On Sat, 12 Jan 2013 09:55:07 + James Hogan james.ho...@imgtec.com wrote: Would sufficiently ready normally mean in a state ready to send a pull request to Linus? That is the usual criteria. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp9Q9GPvSzrc.pgp Description: PGP signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi James, On Fri, 11 Jan 2013 15:02:06 + James Hogan wrote: > > Okay, I've rebased the metag tree from linux-next onto the master branch > of Al's signal tree (to get Vineet's GENERIC_SIGALTSTACK fix and > GENERIC_SIGALTSTACK's eventual removal). OK, but I hope you mentioned not rebasing to Al. > git://github.com/jahogan/metag-linux.git > branch: metag-core > tag: metag-core-v3.1 When you think it is sufficiently ready (and I am guessing that it is getting pretty close), please send me a request to add it to linux-next. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpDUUl9KyB29.pgp Description: PGP signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi, On 11/01/13 13:03, Stephen Rothwell wrote: > On Fri, 11 Jan 2013 09:15:16 + James Hogan wrote: >> >> On 10/01/13 23:34, Stephen Rothwell wrote: >>> You really should not base development work on linux-next and before I >>> can include it there you will need to rebase it onto Linus' tree (or some >>> other tree that does not rebase). Its OK to test by doing a merge with >>> linux-next ... >> >> Thanks for the info Stephen. So I suppose if the patchset depended on >> things in -next the normal way to do it would be to merge in the >> individual trees I needed first? > > Yep, but please let the maintainers of those trees know that you expect > their tree to not be rebased. Or, if if they aren't really dependencies > just conflicts, then leave the other tree out and let me and Linus fix > the conflicts when we merge your tree. > Okay, I've rebased the metag tree from linux-next onto the master branch of Al's signal tree (to get Vineet's GENERIC_SIGALTSTACK fix and GENERIC_SIGALTSTACK's eventual removal). git://github.com/jahogan/metag-linux.git branch: metag-core tag: metag-core-v3.1 Cheers James signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Stephen, On 11/01/13 13:03, Stephen Rothwell wrote: > On Fri, 11 Jan 2013 09:15:16 + James Hogan wrote: >> >> On 10/01/13 23:34, Stephen Rothwell wrote: >>> You really should not base development work on linux-next and before I >>> can include it there you will need to rebase it onto Linus' tree (or some >>> other tree that does not rebase). Its OK to test by doing a merge with >>> linux-next ... >> >> Thanks for the info Stephen. So I suppose if the patchset depended on >> things in -next the normal way to do it would be to merge in the >> individual trees I needed first? > > Yep, but please let the maintainers of those trees know that you expect > their tree to not be rebased. Or, if if they aren't really dependencies > just conflicts, then leave the other tree out and let me and Linus fix > the conflicts when we merge your tree. > Okay, thanks. Due to the recent merge window the dependencies are trivial at the moment, and it wouldn't introduce build breakage to exclude them (i.e. it's just removing selects from Kconfig files and defconfigs that have been removed in linux-next), so I'll exclude those changes for now and deal with them later. Cheers James signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi James, On Fri, 11 Jan 2013 09:15:16 + James Hogan wrote: > > On 10/01/13 23:34, Stephen Rothwell wrote: > > You really should not base development work on linux-next and before I > > can include it there you will need to rebase it onto Linus' tree (or some > > other tree that does not rebase). Its OK to test by doing a merge with > > linux-next ... > > Thanks for the info Stephen. So I suppose if the patchset depended on > things in -next the normal way to do it would be to merge in the > individual trees I needed first? Yep, but please let the maintainers of those trees know that you expect their tree to not be rebased. Or, if if they aren't really dependencies just conflicts, then leave the other tree out and let me and Linus fix the conflicts when we merge your tree. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpK7zrUCc2e9.pgp Description: PGP signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
On 10/01/13 23:34, Stephen Rothwell wrote: > You really should not base development work on linux-next and before I > can include it there you will need to rebase it onto Linus' tree (or some > other tree that does not rebase). Its OK to test by doing a merge with > linux-next ... Thanks for the info Stephen. So I suppose if the patchset depended on things in -next the normal way to do it would be to merge in the individual trees I needed first? Cheers James signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
On 10/01/13 23:34, Stephen Rothwell wrote: You really should not base development work on linux-next and before I can include it there you will need to rebase it onto Linus' tree (or some other tree that does not rebase). Its OK to test by doing a merge with linux-next ... Thanks for the info Stephen. So I suppose if the patchset depended on things in -next the normal way to do it would be to merge in the individual trees I needed first? Cheers James signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi James, On Fri, 11 Jan 2013 09:15:16 + James Hogan james.ho...@imgtec.com wrote: On 10/01/13 23:34, Stephen Rothwell wrote: You really should not base development work on linux-next and before I can include it there you will need to rebase it onto Linus' tree (or some other tree that does not rebase). Its OK to test by doing a merge with linux-next ... Thanks for the info Stephen. So I suppose if the patchset depended on things in -next the normal way to do it would be to merge in the individual trees I needed first? Yep, but please let the maintainers of those trees know that you expect their tree to not be rebased. Or, if if they aren't really dependencies just conflicts, then leave the other tree out and let me and Linus fix the conflicts when we merge your tree. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpK7zrUCc2e9.pgp Description: PGP signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi Stephen, On 11/01/13 13:03, Stephen Rothwell wrote: On Fri, 11 Jan 2013 09:15:16 + James Hogan james.ho...@imgtec.com wrote: On 10/01/13 23:34, Stephen Rothwell wrote: You really should not base development work on linux-next and before I can include it there you will need to rebase it onto Linus' tree (or some other tree that does not rebase). Its OK to test by doing a merge with linux-next ... Thanks for the info Stephen. So I suppose if the patchset depended on things in -next the normal way to do it would be to merge in the individual trees I needed first? Yep, but please let the maintainers of those trees know that you expect their tree to not be rebased. Or, if if they aren't really dependencies just conflicts, then leave the other tree out and let me and Linus fix the conflicts when we merge your tree. Okay, thanks. Due to the recent merge window the dependencies are trivial at the moment, and it wouldn't introduce build breakage to exclude them (i.e. it's just removing selects from Kconfig files and defconfigs that have been removed in linux-next), so I'll exclude those changes for now and deal with them later. Cheers James signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi, On 11/01/13 13:03, Stephen Rothwell wrote: On Fri, 11 Jan 2013 09:15:16 + James Hogan james.ho...@imgtec.com wrote: On 10/01/13 23:34, Stephen Rothwell wrote: You really should not base development work on linux-next and before I can include it there you will need to rebase it onto Linus' tree (or some other tree that does not rebase). Its OK to test by doing a merge with linux-next ... Thanks for the info Stephen. So I suppose if the patchset depended on things in -next the normal way to do it would be to merge in the individual trees I needed first? Yep, but please let the maintainers of those trees know that you expect their tree to not be rebased. Or, if if they aren't really dependencies just conflicts, then leave the other tree out and let me and Linus fix the conflicts when we merge your tree. Okay, I've rebased the metag tree from linux-next onto the master branch of Al's signal tree (to get Vineet's GENERIC_SIGALTSTACK fix and GENERIC_SIGALTSTACK's eventual removal). git://github.com/jahogan/metag-linux.git branch: metag-core tag: metag-core-v3.1 Cheers James signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi James, On Fri, 11 Jan 2013 15:02:06 + James Hogan james.ho...@imgtec.com wrote: Okay, I've rebased the metag tree from linux-next onto the master branch of Al's signal tree (to get Vineet's GENERIC_SIGALTSTACK fix and GENERIC_SIGALTSTACK's eventual removal). OK, but I hope you mentioned not rebasing to Al. git://github.com/jahogan/metag-linux.git branch: metag-core tag: metag-core-v3.1 When you think it is sufficiently ready (and I am guessing that it is getting pretty close), please send me a request to add it to linux-next. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpDUUl9KyB29.pgp Description: PGP signature
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi James, On Thu, 10 Jan 2013 15:30:28 + James Hogan wrote: > > This patchset adds core architecture support to Linux for Imagination's > Meta ATP (Meta 1) and HTP (Meta 2) processor cores. Most of the feedback > from the RFC and v2 patchsets has now been addressed. All further > feedback is most welcome. > > The patches are based on next-20130110, and can also be found in the > following git tree: > git://github.com/jahogan/metag-linux.git metag-core You really should not base development work on linux-next and before I can include it there you will need to rebase it onto Linus' tree (or some other tree that does not rebase). Its OK to test by doing a merge with linux-next ... -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp5bZrHBCVi4.pgp Description: PGP signature
[PATCH v3 00/44] Meta Linux Kernel Port
This patchset adds core architecture support to Linux for Imagination's Meta ATP (Meta 1) and HTP (Meta 2) processor cores. Most of the feedback from the RFC and v2 patchsets has now been addressed. All further feedback is most welcome. The patches are based on next-20130110, and can also be found in the following git tree: git://github.com/jahogan/metag-linux.git metag-core Meta cores are 32-bit, hardware multithreaded, general purpose, embedded processors which also feature a DSP instruction set, and can be found in many digital radios. They are capable of running different operating systems on different hardware threads, for example a digital radio might run RTOSes for DAB decoding and audio decoding on 3 hardware threads, and run Linux on the 4th hardware thread to manage the user interface, networking etc. HTPs are also capable of running SMP Linux on multiple hardware threads. A buildroot tree containing toolchain patches can be found here (use meta2_defconfig): git://github.com/img-meta/metag-buildroot.git metag-core Freely available instruction set and architecture overview documents can be found on the following page: http://www.imgtec.com/downloads.asp --- v3 (tag: metag-core-v3): changes since v2 * tree: * rebased on linux-next and related changes * integrated generic kernel_thread/kernel_execve into patches * signals: * replace do_notify_resume with do_work_pending containing signal handling loop (Al Viro) * handlerless local syscall restart (Al Viro) * fix rt_sigreturn's do_sigaltstack handling (Al Viro) * explicitly detect rt_sigreturn and treat as non-syscall for purposes of syscall restart (Al Viro) * refactor syscall restart code based on arm * use generic sigaltstack * irq handling: * move irq drivers into drivers/irqchip/ (Arnd) * switch to sparse irq (Arnd) * allow per machine override of nr_irqs * switch root TBI, internal, and external interrupt drivers to linear irqdomain * implement masking in internal interrupt driver * system calls: * remove magic pt_regs 7th syscall argument (Al Viro) * use generic sys_clone (Al Viro) * fix use of 0 for invalid syscall number (use -1 instead) * documentation * added Documentation/kernel-ABI.txt describing various ABIs (Al Viro) * tbx: * move tbx/tbicache.c to mm/cache.c and refactor / clean up (Joe Perches) * clean up tbx/tbistring.c * rename asm/lock.h->asm/global_lock.h, remove dependence on tbx * update all lock users to use asm/global_lock.h rather than tbx macros * add and use __core_reg_[gs]et macros to replace TBI_[GS]ETREG * make use of compiler builtins for cache/tlb handling instructions rather than tbx macros * tty/metag_da: * mostly rewritten to address Alan Cox' feedback * use del_timer_sync() where appropriate (Alan Cox) * convert to use tty_port helpers (Alan Cox) * fix tty kref safety (Alan Cox) * implement proper output buffering (Alan Cox) * fix init error handling * implement hangup (Alan Cox) * omit specific baud rate (Alan Cox) * boot: * switch to generic CMDLINE Kconfig symbols (Sam Ravnborg) * alignment patches * removed taskstats changes (see "netlink: align attributes on 64-bits" patches) * rework CONFIG_HAVE_64BIT_ALIGNED_ACCESS patch for clarity feedback not addressed: * proper inversion of Kconfig dependency lists (Greg, Arnd) I'll do this as a separate patch set as arch/metag doesn't directly depend on it. v2 (tag: metag-core-v2): changes based on rfc-v1 review feedback: * moved build infrastructure patch later (Sam Ravnborg) * various build system cleanups (Sam Ravnborg) * split generic build changes out of main build patch (Sam Ravnborg) * deprecate powervr DT vendor id (Rob Herring) * ftrace now uses recordmcount.c (Steven Rostedt) * fixed imgdafs fserrno problem (Al Viro) * io.h changes, inline asm, removed casts, added metag_in/out (Arnd) * remove bus_to_virt (Arnd) * use asm-generic/syscalls.h (Arnd) * remove superfluous metag_spinlock system call (Arnd) * renamed packed 64bit arg syscall wrappers (Arnd) other changes: * rebased on v3.7-rc8 * changes based on v3.6..v3.7-rc8 patches * uapi disintegration (thanks to David Howells for the assistance) * add cmpdi2/ucmpdi2 intrinsics and clean up lib Makefile * fix numa build * split memory management patch into 6 separate patches to make them more manageable and stop them bouncing: * cache/tlb handling * memory management * memory handling * huge tlb * highmem * tcm * split architecture definitions out of TBX into asm/metag_*.h * merged remaining TBX header files into a single asm/tbx.h * split TBX patch into 2 separate patches to stop them bouncing * merge various similar Kconfig changes in generic code * dropped sysfs drivers from this patchset (we normally have them turned off anyway so they're not a priority) * renamed dafs to imgdafs * implemented perf events * rewrote ptrace to use nicely abstracted regsets * removed
Re: [PATCH v3 00/44] Meta Linux Kernel Port
Hi James, On Thu, 10 Jan 2013 15:30:28 + James Hogan james.ho...@imgtec.com wrote: This patchset adds core architecture support to Linux for Imagination's Meta ATP (Meta 1) and HTP (Meta 2) processor cores. Most of the feedback from the RFC and v2 patchsets has now been addressed. All further feedback is most welcome. The patches are based on next-20130110, and can also be found in the following git tree: git://github.com/jahogan/metag-linux.git metag-core You really should not base development work on linux-next and before I can include it there you will need to rebase it onto Linus' tree (or some other tree that does not rebase). Its OK to test by doing a merge with linux-next ... -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp5bZrHBCVi4.pgp Description: PGP signature
[PATCH v3 00/44] Meta Linux Kernel Port
This patchset adds core architecture support to Linux for Imagination's Meta ATP (Meta 1) and HTP (Meta 2) processor cores. Most of the feedback from the RFC and v2 patchsets has now been addressed. All further feedback is most welcome. The patches are based on next-20130110, and can also be found in the following git tree: git://github.com/jahogan/metag-linux.git metag-core Meta cores are 32-bit, hardware multithreaded, general purpose, embedded processors which also feature a DSP instruction set, and can be found in many digital radios. They are capable of running different operating systems on different hardware threads, for example a digital radio might run RTOSes for DAB decoding and audio decoding on 3 hardware threads, and run Linux on the 4th hardware thread to manage the user interface, networking etc. HTPs are also capable of running SMP Linux on multiple hardware threads. A buildroot tree containing toolchain patches can be found here (use meta2_defconfig): git://github.com/img-meta/metag-buildroot.git metag-core Freely available instruction set and architecture overview documents can be found on the following page: http://www.imgtec.com/downloads.asp --- v3 (tag: metag-core-v3): changes since v2 * tree: * rebased on linux-next and related changes * integrated generic kernel_thread/kernel_execve into patches * signals: * replace do_notify_resume with do_work_pending containing signal handling loop (Al Viro) * handlerless local syscall restart (Al Viro) * fix rt_sigreturn's do_sigaltstack handling (Al Viro) * explicitly detect rt_sigreturn and treat as non-syscall for purposes of syscall restart (Al Viro) * refactor syscall restart code based on arm * use generic sigaltstack * irq handling: * move irq drivers into drivers/irqchip/ (Arnd) * switch to sparse irq (Arnd) * allow per machine override of nr_irqs * switch root TBI, internal, and external interrupt drivers to linear irqdomain * implement masking in internal interrupt driver * system calls: * remove magic pt_regs 7th syscall argument (Al Viro) * use generic sys_clone (Al Viro) * fix use of 0 for invalid syscall number (use -1 instead) * documentation * added Documentation/kernel-ABI.txt describing various ABIs (Al Viro) * tbx: * move tbx/tbicache.c to mm/cache.c and refactor / clean up (Joe Perches) * clean up tbx/tbistring.c * rename asm/lock.h-asm/global_lock.h, remove dependence on tbx * update all lock users to use asm/global_lock.h rather than tbx macros * add and use __core_reg_[gs]et macros to replace TBI_[GS]ETREG * make use of compiler builtins for cache/tlb handling instructions rather than tbx macros * tty/metag_da: * mostly rewritten to address Alan Cox' feedback * use del_timer_sync() where appropriate (Alan Cox) * convert to use tty_port helpers (Alan Cox) * fix tty kref safety (Alan Cox) * implement proper output buffering (Alan Cox) * fix init error handling * implement hangup (Alan Cox) * omit specific baud rate (Alan Cox) * boot: * switch to generic CMDLINE Kconfig symbols (Sam Ravnborg) * alignment patches * removed taskstats changes (see netlink: align attributes on 64-bits patches) * rework CONFIG_HAVE_64BIT_ALIGNED_ACCESS patch for clarity feedback not addressed: * proper inversion of Kconfig dependency lists (Greg, Arnd) I'll do this as a separate patch set as arch/metag doesn't directly depend on it. v2 (tag: metag-core-v2): changes based on rfc-v1 review feedback: * moved build infrastructure patch later (Sam Ravnborg) * various build system cleanups (Sam Ravnborg) * split generic build changes out of main build patch (Sam Ravnborg) * deprecate powervr DT vendor id (Rob Herring) * ftrace now uses recordmcount.c (Steven Rostedt) * fixed imgdafs fserrno problem (Al Viro) * io.h changes, inline asm, removed casts, added metag_in/out (Arnd) * remove bus_to_virt (Arnd) * use asm-generic/syscalls.h (Arnd) * remove superfluous metag_spinlock system call (Arnd) * renamed packed 64bit arg syscall wrappers (Arnd) other changes: * rebased on v3.7-rc8 * changes based on v3.6..v3.7-rc8 patches * uapi disintegration (thanks to David Howells for the assistance) * add cmpdi2/ucmpdi2 intrinsics and clean up lib Makefile * fix numa build * split memory management patch into 6 separate patches to make them more manageable and stop them bouncing: * cache/tlb handling * memory management * memory handling * huge tlb * highmem * tcm * split architecture definitions out of TBX into asm/metag_*.h * merged remaining TBX header files into a single asm/tbx.h * split TBX patch into 2 separate patches to stop them bouncing * merge various similar Kconfig changes in generic code * dropped sysfs drivers from this patchset (we normally have them turned off anyway so they're not a priority) * renamed dafs to imgdafs * implemented perf events * rewrote ptrace to use nicely abstracted regsets * removed
