Re: [PATCH v2 00/76] Synopsys ARC Linux kernel Port

2013-01-24 Thread James Hogan
On 24/01/13 10:11, Vineet Gupta wrote:
> On Thursday 24 January 2013 03:22 PM, James Hogan wrote:
>> Hi Vineet,
>>
>> On 24/01/13 08:54, Vineet Gupta wrote:
>>> (3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for 
>>> my
>>> development, I'd also cherry picked a few patches from linux-next (soft and 
>>> hard
>>> dependencies from several different *next trees) - hard ones being
>>>
>>> f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with 
>>> asm-generic/syscalls.h [Al]
>> FYI this one has now been merged into Linus' master.
>>
>> Cheers
>> James
>>
> 
> OK thanks - but I'd rather have the patches based on a well known checkpoint 
> - so
> maybe wait for next rc.

In that case you may like to merge Al's for-linus branch in the mean
time, or the commit you want directly, since it's definitely gone into
the master without being rebased.

> Any ideas about other questions on the thread - given that several next trees 
> are
> still involved.

Stephen said it's fine to merge other trees as long as you let them know
so they don't rebase, or ask them which branch is best to use that won't
rebase. See the following thread:
https://lkml.org/lkml/2013/1/11/187

> metag doesn't seem to be on linux-next yet ?

Not yet, although I think it's almost ready. I need to solicit some acks.

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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-24 Thread Vineet Gupta
On Thursday 24 January 2013 03:22 PM, James Hogan wrote:
> Hi Vineet,
>
> On 24/01/13 08:54, Vineet Gupta wrote:
>> (3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for 
>> my
>> development, I'd also cherry picked a few patches from linux-next (soft and 
>> hard
>> dependencies from several different *next trees) - hard ones being
>>
>> f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with 
>> asm-generic/syscalls.h [Al]
> FYI this one has now been merged into Linus' master.
>
> Cheers
> James
>

OK thanks - but I'd rather have the patches based on a well known checkpoint - 
so
maybe wait for next rc.
Any ideas about other questions on the thread - given that several next trees 
are
still involved.

metag doesn't seem to be on linux-next yet ?

-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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-24 Thread James Hogan
Hi Vineet,

On 24/01/13 08:54, Vineet Gupta wrote:
> (3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for my
> development, I'd also cherry picked a few patches from linux-next (soft and 
> hard
> dependencies from several different *next trees) - hard ones being
> 
> f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with asm-generic/syscalls.h 
> [Al]

FYI this one has now been merged into Linus' master.

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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-24 Thread Vineet Gupta
On Friday 18 January 2013 08:42 PM, Arnd Bergmann wrote:
> On Friday 18 January 2013, Vineet Gupta wrote:
>>
> 
> Hi Vineet,
> 
> I've looked at the entire series again now, and it looks very good
> overall, I only had comments for tiny issues. With 76 patches in the
> series, I doubt that anybody is going to look through all of them
> again though. 

v3 series addressing all comments is cooked and am about to send it out. I've 
made
2 bins of the patches to separate out the ones which have NOT changed since
v2. I'll send them under separate cover letters to make it easier for reviewers 
-
BTW addition of your ACKs is not being counted as changed - although it's a big
change for the patches :-)

> Are the patches already part of Linux-next? If not,
> I would recommend getting them in there as a preparation for merging
> in 3.9.

I have a few questions/clarifications in that regards.

(1) What are the logistics involved. Does it have to be a tag or a branch
(typically I see people have branches in next).

(2) Can Stephan pull my branch from github or do I need to be setup apriori on
kernel.org. If latter, whom do I need to contact.

(3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for my
development, I'd also cherry picked a few patches from linux-next (soft and hard
dependencies from several different *next trees) - hard ones being

f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with asm-generic/syscalls.h 
[Al]
b6fca sysctl: Enable IA64 "ignore-unaligned-usertrap" to be used cross-arch 
[ia64]

Now when I put up a branch for Stephan I guess these should be taken out of ARC
branch otherwise merge into linux-next will fail ?

(4) Above series (pure ARC patches) merges fine in today's linux-next, except 
for
a patch touching init/Kconfig (already acked by parisc maintainer) which is
slightly different if based off 3.8-rc4 vs. linux-next (because of interim 
merge)
so I'm hoping my tree doesn't get "dropped" from linux-next because of that. But
then how will it get fixed.


> I would also recommend to only send incremental patches after that,
> as well as new versions of some of the patches if you decide to
> replace them based on comments you get.

Absolutely - I'm tired of rebasing and chopping/merging as well - so anything 
new
will be on top of these (no rebasing).

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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-24 Thread James Hogan
On 24/01/13 10:11, Vineet Gupta wrote:
 On Thursday 24 January 2013 03:22 PM, James Hogan wrote:
 Hi Vineet,

 On 24/01/13 08:54, Vineet Gupta wrote:
 (3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for 
 my
 development, I'd also cherry picked a few patches from linux-next (soft and 
 hard
 dependencies from several different *next trees) - hard ones being

 f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with 
 asm-generic/syscalls.h [Al]
 FYI this one has now been merged into Linus' master.

 Cheers
 James

 
 OK thanks - but I'd rather have the patches based on a well known checkpoint 
 - so
 maybe wait for next rc.

In that case you may like to merge Al's for-linus branch in the mean
time, or the commit you want directly, since it's definitely gone into
the master without being rebased.

 Any ideas about other questions on the thread - given that several next trees 
 are
 still involved.

Stephen said it's fine to merge other trees as long as you let them know
so they don't rebase, or ask them which branch is best to use that won't
rebase. See the following thread:
https://lkml.org/lkml/2013/1/11/187

 metag doesn't seem to be on linux-next yet ?

Not yet, although I think it's almost ready. I need to solicit some acks.

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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-24 Thread Vineet Gupta
On Friday 18 January 2013 08:42 PM, Arnd Bergmann wrote:
 On Friday 18 January 2013, Vineet Gupta wrote:

 
 Hi Vineet,
 
 I've looked at the entire series again now, and it looks very good
 overall, I only had comments for tiny issues. With 76 patches in the
 series, I doubt that anybody is going to look through all of them
 again though. 

v3 series addressing all comments is cooked and am about to send it out. I've 
made
2 bins of the patches to separate out the ones which have NOT changed since
v2. I'll send them under separate cover letters to make it easier for reviewers 
-
BTW addition of your ACKs is not being counted as changed - although it's a big
change for the patches :-)

 Are the patches already part of Linux-next? If not,
 I would recommend getting them in there as a preparation for merging
 in 3.9.

I have a few questions/clarifications in that regards.

(1) What are the logistics involved. Does it have to be a tag or a branch
(typically I see people have branches in next).

(2) Can Stephan pull my branch from github or do I need to be setup apriori on
kernel.org. If latter, whom do I need to contact.

(3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for my
development, I'd also cherry picked a few patches from linux-next (soft and hard
dependencies from several different *next trees) - hard ones being

f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with asm-generic/syscalls.h 
[Al]
b6fca sysctl: Enable IA64 ignore-unaligned-usertrap to be used cross-arch 
[ia64]

Now when I put up a branch for Stephan I guess these should be taken out of ARC
branch otherwise merge into linux-next will fail ?

(4) Above series (pure ARC patches) merges fine in today's linux-next, except 
for
a patch touching init/Kconfig (already acked by parisc maintainer) which is
slightly different if based off 3.8-rc4 vs. linux-next (because of interim 
merge)
so I'm hoping my tree doesn't get dropped from linux-next because of that. But
then how will it get fixed.


 I would also recommend to only send incremental patches after that,
 as well as new versions of some of the patches if you decide to
 replace them based on comments you get.

Absolutely - I'm tired of rebasing and chopping/merging as well - so anything 
new
will be on top of these (no rebasing).

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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-24 Thread James Hogan
Hi Vineet,

On 24/01/13 08:54, Vineet Gupta wrote:
 (3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for my
 development, I'd also cherry picked a few patches from linux-next (soft and 
 hard
 dependencies from several different *next trees) - hard ones being
 
 f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with asm-generic/syscalls.h 
 [Al]

FYI this one has now been merged into Linus' master.

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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-24 Thread Vineet Gupta
On Thursday 24 January 2013 03:22 PM, James Hogan wrote:
 Hi Vineet,

 On 24/01/13 08:54, Vineet Gupta wrote:
 (3) That branch will be ARC patches on top of Linus's 3.8 rc4. Actually for 
 my
 development, I'd also cherry picked a few patches from linux-next (soft and 
 hard
 dependencies from several different *next trees) - hard ones being

 f13a366 CONFIG_GENERIC_SIGALTSTACK build breakage with 
 asm-generic/syscalls.h [Al]
 FYI this one has now been merged into Linus' master.

 Cheers
 James


OK thanks - but I'd rather have the patches based on a well known checkpoint - 
so
maybe wait for next rc.
Any ideas about other questions on the thread - given that several next trees 
are
still involved.

metag doesn't seem to be on linux-next yet ?

-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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-20 Thread Vineet Gupta
On Sunday 20 January 2013 11:45 AM, H. Peter Anvin wrote:
> On 01/18/2013 04:24 AM, Vineet Gupta wrote:
>> This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700
>> processor family (750D and 770D) from Synopsys. I would be greatful for
>> further review and feedback.
> 
> One thing: ARC, as I understand it, is a whole family of architectures, which
> mostly have in common their origin at Synopsys.  

ARC has had a long history - as a startup in 90's. There used to be ARCTanget
Instruction set (and cores A4,A5... based on that) which 10 years ago got
deprecated by current ARCompact ISA (600 / 700 cores). So yes it is a family of
architectures - but all we care about is the ARCompact and 600/700 at Synopsys.

However, I don't think there were sub-architectures or forks which floated 
around.
The MIPS "ARC" seems to be some sort of firmware standard, but not  related to
ARC: Ralf would you care to shed some light ? I don't know of any ARC arch other
than these.

> Can we make this arch/arc700
> since that is what it is?
> 
> -hpa
> 

As of now yes, but in near future we may have a new Instruction Set and cores
based on that - so it will be better if we keep a non specific name.

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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-20 Thread Vineet Gupta
On Sunday 20 January 2013 11:45 AM, H. Peter Anvin wrote:
 On 01/18/2013 04:24 AM, Vineet Gupta wrote:
 This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700
 processor family (750D and 770D) from Synopsys. I would be greatful for
 further review and feedback.
 
 One thing: ARC, as I understand it, is a whole family of architectures, which
 mostly have in common their origin at Synopsys.  

ARC has had a long history - as a startup in 90's. There used to be ARCTanget
Instruction set (and cores A4,A5... based on that) which 10 years ago got
deprecated by current ARCompact ISA (600 / 700 cores). So yes it is a family of
architectures - but all we care about is the ARCompact and 600/700 at Synopsys.

However, I don't think there were sub-architectures or forks which floated 
around.
The MIPS ARC seems to be some sort of firmware standard, but not  related to
ARC: Ralf would you care to shed some light ? I don't know of any ARC arch other
than these.

 Can we make this arch/arc700
 since that is what it is?
 
 -hpa
 

As of now yes, but in near future we may have a new Instruction Set and cores
based on that - so it will be better if we keep a non specific name.

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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-19 Thread H. Peter Anvin

On 01/18/2013 04:24 AM, Vineet Gupta wrote:

This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700
processor family (750D and 770D) from Synopsys. I would be greatful for
further review and feedback.


One thing: ARC, as I understand it, is a whole family of architectures, 
which mostly have in common their origin at Synopsys.  Can we make this 
arch/arc700 since that is what it is?


-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-19 Thread H. Peter Anvin

On 01/18/2013 04:24 AM, Vineet Gupta wrote:

This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700
processor family (750D and 770D) from Synopsys. I would be greatful for
further review and feedback.


One thing: ARC, as I understand it, is a whole family of architectures, 
which mostly have in common their origin at Synopsys.  Can we make this 
arch/arc700 since that is what it is?


-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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 v2 00/76] Synopsys ARC Linux kernel Port

2013-01-18 Thread Arnd Bergmann
On Friday 18 January 2013, Vineet Gupta wrote:
> This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700
> processor family (750D and 770D) from Synopsys. I would be greatful for
> further review and feedback.
> 
> Salient points about v2 patchset
> ---
> * All of the feedback from v1 RFC patchseries has been addressed.
> 
> * Some of the major fixes for v1 review comments such as Device Tree support,
>   multi-platform-image and syscall-restart issues, have not been squashed
>   into relevent patches, but instead have been applied as slap-on patches
>   on orig ones. This is merely to build up some revision history into the
>   final-upstream-merged version. If people think it's too ugly, I can do
>   the chop-n-dice-n-squash, but my preference would be the style we have now.
> 
> * Unlike RFC v1 series (split into 2 part) this one includes the complete port
>   (still the minimal kernel at halfway checkpoint, builds/runs fine).
>   This combined with prev point, make the full patchset a touch large, for
>   which I appologize in advance.
> 
> * The entire series however is also available at
>   git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git 
> arc-3.8-lkml-v2
> 

Hi Vineet,

I've looked at the entire series again now, and it looks very good
overall, I only had comments for tiny issues. With 76 patches in the
series, I doubt that anybody is going to look through all of them
again though. Are the patches already part of Linux-next? If not,
I would recommend getting them in there as a preparation for merging
in 3.9.

I would also recommend to only send incremental patches after that,
as well as new versions of some of the patches if you decide to
replace them based on comments you get.

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/


[PATCH v2 00/76] Synopsys ARC Linux kernel Port

2013-01-18 Thread Vineet Gupta
This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700
processor family (750D and 770D) from Synopsys. I would be greatful for
further review and feedback.

Salient points about v2 patchset
---
* All of the feedback from v1 RFC patchseries has been addressed.

* Some of the major fixes for v1 review comments such as Device Tree support,
  multi-platform-image and syscall-restart issues, have not been squashed
  into relevent patches, but instead have been applied as slap-on patches
  on orig ones. This is merely to build up some revision history into the
  final-upstream-merged version. If people think it's too ugly, I can do
  the chop-n-dice-n-squash, but my preference would be the style we have now.

* Unlike RFC v1 series (split into 2 part) this one includes the complete port
  (still the minimal kernel at halfway checkpoint, builds/runs fine).
  This combined with prev point, make the full patchset a touch large, for
  which I appologize in advance.

* The entire series however is also available at
  git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git 
arc-3.8-lkml-v2

About ARC Cores

ARC700 is highly configurable and power efficient 32-bit RISC core with MMU.
It is embedded in SoCs deployed in TV Set Top boxes, Digital Media Players,
all the way to Network-on-Chips.

More information is available @
 http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/Pages/default.aspx

The GNU tool-chain, based off of gcc 4.4  + uClibc 0.9.30.3 is also available
from github. Please refer to Readme.md in "toolchain" repository also in same
hierarchy as kernel above.

---
v2:

Changes for RFC v1 review:

* Reworked arc_local_irq_enable() with WARN_ONCE for buggy drivers (tglx)
* struct pt_regs wrapped under #ifdef __KERNEL__ (Jonas)
* returning to user mode (Al Viro)
  * re-enable interrupts before handling TIF_SIGPENDING/TIF_NOTIFY_RESUME
  * Don't discard callee-regs after handling signal
  * After TIF_NOTIFY_RESUME processing, loop back to start of TIF_* checks
* Reworked init_IRQ() to not use irq_modify_status() at all (tglx)
* Removed legacy syscalls (Arnd)
* cpu_idle to use schedule_preempt_disabled API (tglx)
* clocksource/clockevent code renamed/reworked (tglx)
* Removed possible live-lock in sched_clock() (tglx)
* Ensured that syscalls are not restarted multiple times (Al Viro)
* Support for DeviceTree based dynamic platform device registration (Arnd)
* clock-speed / mem-size extracted from Device Tree (Arnd)
* multi-platform-image - Non-exclusive platform selection in build (Arnd)
* multi-platform-image - Non-exclusive boards selection in build (Arnd)
* Fix the issue in switch to generic_execve (Al Viro)
* defconfigs need to be created using savedefconfig (Arnd)
* Remove support for legacy ptrace POKEUSR/PEEKUSR ABI (Arnd)
* module stubs need not be defined in Arch code (Arnd)
* Low Level Event Capture completely taken out (Arnd)
* Unaligned access runtime controlled using 2 sysctl knobs (Arnd)
* using io accessors for programming BVCI Latency Unit (Arnd)

Other fixes:

* 3.7 -> 3.8 upstream changes
  * Rebased off of 3.8-rc4
  * UAPI Disintegration using scripts provided David Howells
  * Generic clone/fork/vfork
  * switch to saner kernel_execve semantics (GENERIC_KERNEL_EXECVE)
  * Altstack consolidation tracking changes
  * trace_clock.h introduction, cacheflush.h inclusion removal from io.h
* bitops
  * test_and_clear_bit() was SETing the bit instead of CLEARing
  * test_and_*_bit() workaround a gas bug where a bitpos > 31 is not reported
by doing __builtin_constant_p() check early
* uaccess
  * Added support for non-inline copy_{to,from}_user() for -Os
  * Optimised {get,put}_user() by overriding asm-generic versions
* Timers
  * split Process scheduling/Timers patch into two.
  * Add support for 64bit timestamp counter using RTSC instruction.
* Others
  * Move the incore intc chip handler out of platform code into common code
  * cpu_ide() to use the rcu_idle_* calls

Gilad Ben-Yossef (1):
  ARC: Add support for ioremap_prot API

Mischa Jonker (1):
  ARC: kgdb support

Vineet Gupta (74):
  ARC: Generic Headers
  ARC: irqflags - Interrupt enabling/disabling at in-core intc
  ARC: Atomic/bitops/cmpxchg/barriers
  asm-generic headers: uaccess.h to conditionally define segment_eq()
  ARC: uaccess friends
  asm-generic: uaccess: Allow arches to over-ride __{get,put}_user_fn()
  ARC: [optim] uaccess __{get,put}_user() optimised
  asm-generic headers: Allow yet more arch overrides in checksum.h
  ARC: Checksum/byteorder/swab routines
  ARC: Fundamental ARCH data-types/defines
  ARC: Spinlock/rwlock/mutex primitives
  ARC: String library
  ARC: Low level IRQ/Trap/Exception Handling
  ARC: Interrupt Handling
  ARC: Non-MMU Exception Handling
  ARC: Syscall support (no-legacy-syscall ABI)
  ARC: Process-creation/scheduling/idle-loop
  ARC: Timers/counters/delay management
  ARC: Signal handling
  ARC: [Review] Preparing to fix 

[PATCH v2 00/76] Synopsys ARC Linux kernel Port

2013-01-18 Thread Vineet Gupta
This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700
processor family (750D and 770D) from Synopsys. I would be greatful for
further review and feedback.

Salient points about v2 patchset
---
* All of the feedback from v1 RFC patchseries has been addressed.

* Some of the major fixes for v1 review comments such as Device Tree support,
  multi-platform-image and syscall-restart issues, have not been squashed
  into relevent patches, but instead have been applied as slap-on patches
  on orig ones. This is merely to build up some revision history into the
  final-upstream-merged version. If people think it's too ugly, I can do
  the chop-n-dice-n-squash, but my preference would be the style we have now.

* Unlike RFC v1 series (split into 2 part) this one includes the complete port
  (still the minimal kernel at halfway checkpoint, builds/runs fine).
  This combined with prev point, make the full patchset a touch large, for
  which I appologize in advance.

* The entire series however is also available at
  git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git 
arc-3.8-lkml-v2

About ARC Cores

ARC700 is highly configurable and power efficient 32-bit RISC core with MMU.
It is embedded in SoCs deployed in TV Set Top boxes, Digital Media Players,
all the way to Network-on-Chips.

More information is available @
 http://www.synopsys.com/IP/ProcessorIP/ARCProcessors/Pages/default.aspx

The GNU tool-chain, based off of gcc 4.4  + uClibc 0.9.30.3 is also available
from github. Please refer to Readme.md in toolchain repository also in same
hierarchy as kernel above.

---
v2:

Changes for RFC v1 review:

* Reworked arc_local_irq_enable() with WARN_ONCE for buggy drivers (tglx)
* struct pt_regs wrapped under #ifdef __KERNEL__ (Jonas)
* returning to user mode (Al Viro)
  * re-enable interrupts before handling TIF_SIGPENDING/TIF_NOTIFY_RESUME
  * Don't discard callee-regs after handling signal
  * After TIF_NOTIFY_RESUME processing, loop back to start of TIF_* checks
* Reworked init_IRQ() to not use irq_modify_status() at all (tglx)
* Removed legacy syscalls (Arnd)
* cpu_idle to use schedule_preempt_disabled API (tglx)
* clocksource/clockevent code renamed/reworked (tglx)
* Removed possible live-lock in sched_clock() (tglx)
* Ensured that syscalls are not restarted multiple times (Al Viro)
* Support for DeviceTree based dynamic platform device registration (Arnd)
* clock-speed / mem-size extracted from Device Tree (Arnd)
* multi-platform-image - Non-exclusive platform selection in build (Arnd)
* multi-platform-image - Non-exclusive boards selection in build (Arnd)
* Fix the issue in switch to generic_execve (Al Viro)
* defconfigs need to be created using savedefconfig (Arnd)
* Remove support for legacy ptrace POKEUSR/PEEKUSR ABI (Arnd)
* module stubs need not be defined in Arch code (Arnd)
* Low Level Event Capture completely taken out (Arnd)
* Unaligned access runtime controlled using 2 sysctl knobs (Arnd)
* using io accessors for programming BVCI Latency Unit (Arnd)

Other fixes:

* 3.7 - 3.8 upstream changes
  * Rebased off of 3.8-rc4
  * UAPI Disintegration using scripts provided David Howells
  * Generic clone/fork/vfork
  * switch to saner kernel_execve semantics (GENERIC_KERNEL_EXECVE)
  * Altstack consolidation tracking changes
  * trace_clock.h introduction, cacheflush.h inclusion removal from io.h
* bitops
  * test_and_clear_bit() was SETing the bit instead of CLEARing
  * test_and_*_bit() workaround a gas bug where a bitpos  31 is not reported
by doing __builtin_constant_p() check early
* uaccess
  * Added support for non-inline copy_{to,from}_user() for -Os
  * Optimised {get,put}_user() by overriding asm-generic versions
* Timers
  * split Process scheduling/Timers patch into two.
  * Add support for 64bit timestamp counter using RTSC instruction.
* Others
  * Move the incore intc chip handler out of platform code into common code
  * cpu_ide() to use the rcu_idle_* calls

Gilad Ben-Yossef (1):
  ARC: Add support for ioremap_prot API

Mischa Jonker (1):
  ARC: kgdb support

Vineet Gupta (74):
  ARC: Generic Headers
  ARC: irqflags - Interrupt enabling/disabling at in-core intc
  ARC: Atomic/bitops/cmpxchg/barriers
  asm-generic headers: uaccess.h to conditionally define segment_eq()
  ARC: uaccess friends
  asm-generic: uaccess: Allow arches to over-ride __{get,put}_user_fn()
  ARC: [optim] uaccess __{get,put}_user() optimised
  asm-generic headers: Allow yet more arch overrides in checksum.h
  ARC: Checksum/byteorder/swab routines
  ARC: Fundamental ARCH data-types/defines
  ARC: Spinlock/rwlock/mutex primitives
  ARC: String library
  ARC: Low level IRQ/Trap/Exception Handling
  ARC: Interrupt Handling
  ARC: Non-MMU Exception Handling
  ARC: Syscall support (no-legacy-syscall ABI)
  ARC: Process-creation/scheduling/idle-loop
  ARC: Timers/counters/delay management
  ARC: Signal handling
  ARC: [Review] Preparing to fix 

Re: [PATCH v2 00/76] Synopsys ARC Linux kernel Port

2013-01-18 Thread Arnd Bergmann
On Friday 18 January 2013, Vineet Gupta wrote:
 This patchset based off-of 3.8-rc4, adds the Linux kernel port to ARC700
 processor family (750D and 770D) from Synopsys. I would be greatful for
 further review and feedback.
 
 Salient points about v2 patchset
 ---
 * All of the feedback from v1 RFC patchseries has been addressed.
 
 * Some of the major fixes for v1 review comments such as Device Tree support,
   multi-platform-image and syscall-restart issues, have not been squashed
   into relevent patches, but instead have been applied as slap-on patches
   on orig ones. This is merely to build up some revision history into the
   final-upstream-merged version. If people think it's too ugly, I can do
   the chop-n-dice-n-squash, but my preference would be the style we have now.
 
 * Unlike RFC v1 series (split into 2 part) this one includes the complete port
   (still the minimal kernel at halfway checkpoint, builds/runs fine).
   This combined with prev point, make the full patchset a touch large, for
   which I appologize in advance.
 
 * The entire series however is also available at
   git://github.com/foss-for-synopsys-dwc-arc-processors/linux.git 
 arc-3.8-lkml-v2
 

Hi Vineet,

I've looked at the entire series again now, and it looks very good
overall, I only had comments for tiny issues. With 76 patches in the
series, I doubt that anybody is going to look through all of them
again though. Are the patches already part of Linux-next? If not,
I would recommend getting them in there as a preparation for merging
in 3.9.

I would also recommend to only send incremental patches after that,
as well as new versions of some of the patches if you decide to
replace them based on comments you get.

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/