Re: [PATCH 1/2] ARM: CLKDEV: Add Common Macro for clk_lookup
Thank you all for your comments.
Will resend the patches after removing "&" from the clk parameter and
trailing "," at the end of Macro.
Thanks and Regards,
Padmavathi Venna
On Sat, Oct 1, 2011 at 8:59 PM, Russell King - ARM Linux
wrote:
> On Fri, Sep 30, 2011 at 04:41:36PM +0530, Padmavathi Venna wrote:
>> +#define CLKDEV_INIT(d, n, c) \
>> + { \
>> + .dev_id = d, \
>> + .con_id = n, \
>> + .clk = &c, \
>> + },
>> +
>
> As Heartley says, the trailing , and the end should not be there - it
> should be with each use of CLKDEV_INIT(). The reasoning is that it
> makes the use of macros much more conventional and consistent throughout
> the kernel:
>
> struct cl_lookup foo_lookups[] = {
> CLKDEV_INIT(...),
> CLKDEV_INIT(...),
> };
>
> struct cl_lookup bar_lookup = CLKDEV_INIT(...);
>
> Could you re-spin with that change please?
>
> Thanks.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
On Monday 03 October 2011 12:41:22 Kukjin Kim wrote: > This patch adds macro SAMSUNG_RES_MEM, SAMSUNG_RES_IRQ > and so on to cleanup regarding 'struct resource' by using > defined helpers at . > > Cc: Ben Dooks > Signed-off-by: Kukjin Kim When we introduced those macros, it was specifically so that platforms would be migrated to use them instead of providing their own. > index 8f19241..a506831 100644 > --- a/arch/arm/plat-samsung/include/plat/devs.h > +++ b/arch/arm/plat-samsung/include/plat/devs.h > @@ -18,6 +18,17 @@ > > #include > > +#define SAMSUNG_RES_MEM(soc, ip, sz) DEFINE_RES_MEM(soc##_PA_##ip, sz) > +#define SAMSUNG_RES_IRQ(ip)DEFINE_RES_IRQ(IRQ_##ip) > + > +#define SAMSUNG_RES_MEM_NAMED(soc, ip, sz, name) \ > + DEFINE_RES_MEM_NAMED(soc##_PA_##ip, sz, name) > +#define SAMSUNG_RES_IRQ_NAMED(ip, name)\ > + DEFINE_RES_IRQ_NAMED(IRQ_##ip, name) > +#define SAMSUNG_RES_DMA_NAMED(ch, name)\ > + DEFINE_RES_DMA_NAMED(DMACH_##ch, name) I think the string concatenation really just obfuscates the code, and it does not actually save much at all. When you replace + [0] = SAMSUNG_RES_MEM(S3C, WDT, SZ_1K), + [1] = SAMSUNG_RES_IRQ(WDT), with + [0] = DEFINE_RES_MEM(S3C_PA_WDT, SZ_1K), + [1] = DEFINE_RES_IRQ(IRQ_WDT), you need practically no extra space, but you gain the advantages that * Someone using grep for DEFINE_RES_MEM finds all memory resources without having to look up what your macros do an where they are used. * Someone using grep to look for S3C_PA_WDT finds the place where it is used. * Someone reading the resource definition immediately knows what the macro does if familiar with other platforms using that macro. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
On 10/03/2011 03:13 PM, Kukjin Kim wrote: > On 10/03/11 12:53, Kyungmin Park wrote: >> On Mon, Oct 3, 2011 at 12:41 PM, Kukjin Kim wrote: >>> >>> +#define SAMSUNG_RES_MEM(soc, ip, sz) DEFINE_RES_MEM(soc##_PA_##ip, sz) >>> +#define SAMSUNG_RES_IRQ(ip)DEFINE_RES_IRQ(IRQ_##ip) >>> + >>> +#define SAMSUNG_RES_MEM_NAMED(soc, ip, sz, name) \ >>> + DEFINE_RES_MEM_NAMED(soc##_PA_##ip, sz, >>> name) >>> +#define SAMSUNG_RES_IRQ_NAMED(ip, name)\ >>> + DEFINE_RES_IRQ_NAMED(IRQ_##ip, name) >>> +#define SAMSUNG_RES_DMA_NAMED(ch, name)\ >>> + DEFINE_RES_DMA_NAMED(DMACH_##ch, name) >> >> It's good for readability. but do you think that it's hard to find out >> defined macros are used at real place? >> e.g., Now I want to find out the S3C_PA_USB_HSOTG. it's difficult if >> you use the SAMSUNG_RES_* series macro. >> but if you use the DEFINED_RES_* series directly. it's easy to find >> out at real codes. >> > Well, I don't think so because the XXX_PA_XXX addresses are defined in each > mach/map.h and they are usually used in here so it's not hard to find it. Some minor disadvantage is that tagging tools like e.g. gtags don't handle these things properly. But I don't think it's really important. > > And now the 'S3C', 'S5P' and 'SAMSUNG' are used in the 'soc' part. I'm > preparing to consolidate the name and to remove duplicated resources. Do you also have any specific plans for supporting single image build for multiple SoC's while working on this ? Thanks, -- Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS: Add ARCH_EXYNOS and reorganize arch/arm/mach-exynos
On Monday 03 October 2011 21:40:36 Kukjin Kim wrote: > Yes, absolutely. As I said, the 'mach-exynos' can support upcoming > Samsung EXYNOS SoCs and the way is better than making mach-exynos5. > > My bigger plan is finally to make current directories to 3 mach- dir. > (mach-s3c, mach-s5p, and mach-exynos) and 1 plat-samsung directory. Of > course, the mach- directories can be reduced later. > > Firstly, as you can see, I'm merging plat-s3c24xx and plat-s5p into one > plat-samsung directory and actually the files and dev-*.c > files have been moved into plat-samsung. Maybe I can finish it during > 3.2-rc. Ok, sounds good. So for my understanding: is s5p a completely separate line from exynos, or are they more of an evolutionary succession where you draw the line between the last uniprocessor and the first SMP chip? > Secondary, upcoming Samsung EXYNOS SoCs will be supported in mach-exynos > directory and this patch is required to that. For example, the EXYNOS5 > SoCs (Cortex A15) will be supported in that with other EXYNOS4 SoCs soon > and of course it reduces code duplication My feeling is that it would be nicer to just add exynos5 to the mach-exynos4 directory for now, in the same way that omap3/4/5 are in the mach-omap2 directory. We can do a big rename later once the reorganization of code within those directories that you explained above is complete. If you still want to do the big rename right now, I would suggest doing it at the end of the 3.2 merge window, so that all other patches that might need to touch the mach-exynos4 directory can go in first. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
On 10/03/11 12:53, Kyungmin Park wrote: On Mon, Oct 3, 2011 at 12:41 PM, Kukjin Kim wrote: This patch adds macro SAMSUNG_RES_MEM, SAMSUNG_RES_IRQ and so on to cleanup regarding 'struct resource' by using defined helpers at. Cc: Ben Dooks Signed-off-by: Kukjin Kim --- Changes since v1: - Address comments from Russell King Using defined helpers to define resource arch/arm/mach-s3c2410/include/mach/map.h |1 + arch/arm/plat-samsung/devs.c | 697 + arch/arm/plat-samsung/include/plat/devs.h | 11 + 3 files changed, 129 insertions(+), 580 deletions(-) (snip) +#define SAMSUNG_RES_MEM(soc, ip, sz) DEFINE_RES_MEM(soc##_PA_##ip, sz) +#define SAMSUNG_RES_IRQ(ip)DEFINE_RES_IRQ(IRQ_##ip) + +#define SAMSUNG_RES_MEM_NAMED(soc, ip, sz, name) \ + DEFINE_RES_MEM_NAMED(soc##_PA_##ip, sz, name) +#define SAMSUNG_RES_IRQ_NAMED(ip, name)\ + DEFINE_RES_IRQ_NAMED(IRQ_##ip, name) +#define SAMSUNG_RES_DMA_NAMED(ch, name)\ + DEFINE_RES_DMA_NAMED(DMACH_##ch, name) It's good for readability. but do you think that it's hard to find out defined macros are used at real place? e.g., Now I want to find out the S3C_PA_USB_HSOTG. it's difficult if you use the SAMSUNG_RES_* series macro. but if you use the DEFINED_RES_* series directly. it's easy to find out at real codes. Well, I don't think so because the XXX_PA_XXX addresses are defined in each mach/map.h and they are usually used in here so it's not hard to find it. And now the 'S3C', 'S5P' and 'SAMSUNG' are used in the 'soc' part. I'm preparing to consolidate the name and to remove duplicated resources. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS: Add ARCH_EXYNOS and reorganize arch/arm/mach-exynos
On 10/03/11 18:33, Arnd Bergmann wrote: On Monday 03 October 2011 13:02:16 Kyungmin Park wrote: I'm afraid to change machine directory name again. mach-s5pv310 -> mach-exynos4 -> mach-exynos. As I remember linus blamed the renaming the file names are happened frequently at ARM I tend to agree with this. While the new name does make more sense, I would first like to see the bigger plan. If you are eventually planning to consolidate all of mach-s5p64x0, mach-s5pc100, mach-s5pv210, mach-exynos4 and plat-s5p into one common mach-s5p or mach-exynos directory, I'm all for that because it reduces code duplication and work required for the overall cross-subarchitecture single zimage work. Yes, absolutely. As I said, the 'mach-exynos' can support upcoming Samsung EXYNOS SoCs and the way is better than making mach-exynos5. My bigger plan is finally to make current directories to 3 mach- dir. (mach-s3c, mach-s5p, and mach-exynos) and 1 plat-samsung directory. Of course, the mach- directories can be reduced later. Firstly, as you can see, I'm merging plat-s3c24xx and plat-s5p into one plat-samsung directory and actually the files and dev-*.c files have been moved into plat-samsung. Maybe I can finish it during 3.2-rc. Secondary, upcoming Samsung EXYNOS SoCs will be supported in mach-exynos directory and this patch is required to that. For example, the EXYNOS5 SoCs (Cortex A15) will be supported in that with other EXYNOS4 SoCs soon and of course it reduces code duplication :) And then current mach-s5p stuff will be merged into mach-s5p. As I talked to Ben Dooks, he also have a plan to merging mach-s3c stuff. Simply renaming something because the name does not quite fit entirely should be done very carefully. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Samsung devel-2 for v3.2
On Mon, Oct 03, 2011 at 12:22:35PM +0100, Russell King - ARM Linux wrote: > On Mon, Oct 03, 2011 at 11:36:26AM +0100, Mark Brown wrote: > > It's possible it's something that doesn't manifest on that board, I've > > no real idea what's exploding or why. There's also a bunch of other > > early boot problems right now like try_to_freeze() which aren't helping. > I don't know whether I can solve that before the next merge window. > There's lots of corner cases, and I'm no longer convinced that my > previous patch doesn't introduce more problems than it solves (such > as completely breaking the -ERESTART_RESTARTBLOCK handing.) > While it's possible to shut up the warning by enabling IRQs, that makes > the race for restarting (or not restarting) syscalls *huge*, and that > could cause unexpected userspace behaviour depending on whether they > handle EINTR and _how_ they handle EINTR on system calls which they > expect would've been restarted by the kernel. It looks like the patches to stop it happening constantly have been applied so it's a much less serious problem than it was originally - we can boot and run reasonably cleanly. It's certainly not the crippling issue it was originally. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: S3C2410: Remove section mismatch warning
Hi Russell,
On Monday 03 October 2011 03:29 PM, Russell King - ARM Linux wrote:
On Mon, Oct 03, 2011 at 03:10:41PM +0530, Tushar Behera wrote:
Some of the functions and structures did not have _init or __initdata
attributes, even though they were referenced from functions / structures
with those attribute, resulting in section mismatches.
Firstly - it's a good idea to include the warnings which you're fixing
in the commit log text, so that people know exactly what is being fixed.
Thanks for your review.
Sure, I will add it in next revision.
[ snip ]
diff --git a/arch/arm/mach-s3c2416/irq.c b/arch/arm/mach-s3c2416/irq.c
index 28ad20d..153cb2f 100644
--- a/arch/arm/mach-s3c2416/irq.c
+++ b/arch/arm/mach-s3c2416/irq.c
@@ -234,7 +234,7 @@ static int __init s3c2416_irq_add(struct sys_device *sysdev)
return 0;
}
-static struct sysdev_driver s3c2416_irq_driver = {
+static struct sysdev_driver s3c2416_irq_driver __initdata = {
.add= s3c2416_irq_add,
};
I remain entirely unconvinced that this is correct. As a result of
the "sysdev_driver_register(&s3c2416_sysclass,&s3c2416_irq_driver);"
call, this structure is placed on a list.
If this structure is marked __initdata, then the memory behind the
structure will be freed and overwritten - however, it's still on a
list which might be walked. Such a walk would cause a kernel oops
or might even be an exploitable security hole if that page ends up
in userspace - especially as said structure contains function calls
which would be called in privileged mode.
The function s3c2416_irq_add() is defined with __init attribute. Also a
cascade of functions called from s3c2416_irq_add() are also defined with
__init attribute.
Would it be a good idea to remove __init attribute of all these
functions (there are 2 of them) called from s3c2416_irq_add() instead?
The same comment applies to the other sysdev driver structures you're
marking __initdata too.
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Samsung devel-2 for v3.2
On Mon, Oct 03, 2011 at 11:36:26AM +0100, Mark Brown wrote: > On Mon, Oct 03, 2011 at 12:27:22PM +0900, Kukjin Kim wrote: > > Mark Brown wrote: > > > > As I reported the other day this change breaks the boot early on on the > > > Cragganmore S3C6410 based systems (I've not actually fired up my > > > SMDK6410 but I suspect it may have issues too). I did make some brief > > > attempts to debug but as there's no console output at all and the diff > > > is rather large it's not easy to see what's gone wrong. > > > Hmm, I thought it has no problem when I saw Thomas Abraham's 'serial: > > samsung' patches because he said it works fine with my for-next plus his > > patches on SMDK6410...Anyway, I need to sort it out. > > It's possible it's something that doesn't manifest on that board, I've > no real idea what's exploding or why. There's also a bunch of other > early boot problems right now like try_to_freeze() which aren't helping. I don't know whether I can solve that before the next merge window. There's lots of corner cases, and I'm no longer convinced that my previous patch doesn't introduce more problems than it solves (such as completely breaking the -ERESTART_RESTARTBLOCK handing.) While it's possible to shut up the warning by enabling IRQs, that makes the race for restarting (or not restarting) syscalls *huge*, and that could cause unexpected userspace behaviour depending on whether they handle EINTR and _how_ they handle EINTR on system calls which they expect would've been restarted by the kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Samsung devel-2 for v3.2
On Mon, Oct 03, 2011 at 12:27:22PM +0900, Kukjin Kim wrote: > Mark Brown wrote: > > As I reported the other day this change breaks the boot early on on the > > Cragganmore S3C6410 based systems (I've not actually fired up my > > SMDK6410 but I suspect it may have issues too). I did make some brief > > attempts to debug but as there's no console output at all and the diff > > is rather large it's not easy to see what's gone wrong. > Hmm, I thought it has no problem when I saw Thomas Abraham's 'serial: > samsung' patches because he said it works fine with my for-next plus his > patches on SMDK6410...Anyway, I need to sort it out. It's possible it's something that doesn't manifest on that board, I've no real idea what's exploding or why. There's also a bunch of other early boot problems right now like try_to_freeze() which aren't helping. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: S3C2410: Remove section mismatch warning
On Mon, Oct 03, 2011 at 03:10:41PM +0530, Tushar Behera wrote:
> Some of the functions and structures did not have _init or __initdata
> attributes, even though they were referenced from functions / structures
> with those attribute, resulting in section mismatches.
Firstly - it's a good idea to include the warnings which you're fixing
in the commit log text, so that people know exactly what is being fixed.
> diff --git a/arch/arm/mach-s3c2410/usb-simtec.c
> b/arch/arm/mach-s3c2410/usb-simtec.c
> index 29bd3d9..3a1028c 100644
> --- a/arch/arm/mach-s3c2410/usb-simtec.c
> +++ b/arch/arm/mach-s3c2410/usb-simtec.c
> @@ -104,7 +104,7 @@ static struct s3c2410_hcd_info usb_simtec_info __initdata
> = {
> };
>
>
> -int usb_simtec_init(void)
> +int __init usb_simtec_init(void)
> {
> int ret;
>
This one looks fine.
> diff --git a/arch/arm/mach-s3c2416/irq.c b/arch/arm/mach-s3c2416/irq.c
> index 28ad20d..153cb2f 100644
> --- a/arch/arm/mach-s3c2416/irq.c
> +++ b/arch/arm/mach-s3c2416/irq.c
> @@ -234,7 +234,7 @@ static int __init s3c2416_irq_add(struct sys_device
> *sysdev)
> return 0;
> }
>
> -static struct sysdev_driver s3c2416_irq_driver = {
> +static struct sysdev_driver s3c2416_irq_driver __initdata = {
> .add= s3c2416_irq_add,
> };
>
I remain entirely unconvinced that this is correct. As a result of
the "sysdev_driver_register(&s3c2416_sysclass, &s3c2416_irq_driver);"
call, this structure is placed on a list.
If this structure is marked __initdata, then the memory behind the
structure will be freed and overwritten - however, it's still on a
list which might be walked. Such a walk would cause a kernel oops
or might even be an exploitable security hole if that page ends up
in userspace - especially as said structure contains function calls
which would be called in privileged mode.
The same comment applies to the other sysdev driver structures you're
marking __initdata too.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: S3C2410: Remove section mismatch warning
Some of the functions and structures did not have _init or __initdata
attributes, even though they were referenced from functions / structures
with those attribute, resulting in section mismatches.
Signed-off-by: Tushar Behera
---
The patch is rebased on v3.1-rc8.
The patch has only been build tested, they are not boot tested on any
hardware.
arch/arm/mach-s3c2410/usb-simtec.c |2 +-
arch/arm/mach-s3c2410/usb-simtec.h |2 +-
arch/arm/mach-s3c2416/irq.c|2 +-
arch/arm/mach-s3c2440/clock.c |4 ++--
arch/arm/mach-s3c2443/irq.c|2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-s3c2410/usb-simtec.c
b/arch/arm/mach-s3c2410/usb-simtec.c
index 29bd3d9..3a1028c 100644
--- a/arch/arm/mach-s3c2410/usb-simtec.c
+++ b/arch/arm/mach-s3c2410/usb-simtec.c
@@ -104,7 +104,7 @@ static struct s3c2410_hcd_info usb_simtec_info __initdata =
{
};
-int usb_simtec_init(void)
+int __init usb_simtec_init(void)
{
int ret;
diff --git a/arch/arm/mach-s3c2410/usb-simtec.h
b/arch/arm/mach-s3c2410/usb-simtec.h
index 03842ed..43cc88f 100644
--- a/arch/arm/mach-s3c2410/usb-simtec.h
+++ b/arch/arm/mach-s3c2410/usb-simtec.h
@@ -12,5 +12,5 @@
* published by the Free Software Foundation.
*/
-extern int usb_simtec_init(void);
+extern int __init usb_simtec_init(void);
diff --git a/arch/arm/mach-s3c2416/irq.c b/arch/arm/mach-s3c2416/irq.c
index 28ad20d..153cb2f 100644
--- a/arch/arm/mach-s3c2416/irq.c
+++ b/arch/arm/mach-s3c2416/irq.c
@@ -234,7 +234,7 @@ static int __init s3c2416_irq_add(struct sys_device *sysdev)
return 0;
}
-static struct sysdev_driver s3c2416_irq_driver = {
+static struct sysdev_driver s3c2416_irq_driver __initdata = {
.add= s3c2416_irq_add,
};
diff --git a/arch/arm/mach-s3c2440/clock.c b/arch/arm/mach-s3c2440/clock.c
index f9e6bda..3b3bec5 100644
--- a/arch/arm/mach-s3c2440/clock.c
+++ b/arch/arm/mach-s3c2440/clock.c
@@ -108,7 +108,7 @@ static struct clk s3c2440_clk_ac97 = {
.ctrlbit= S3C2440_CLKCON_CAMERA,
};
-static int s3c2440_clk_add(struct sys_device *sysdev)
+static int __init s3c2440_clk_add(struct sys_device *sysdev)
{
struct clk *clock_upll;
struct clk *clock_h;
@@ -137,7 +137,7 @@ static int s3c2440_clk_add(struct sys_device *sysdev)
return 0;
}
-static struct sysdev_driver s3c2440_clk_driver = {
+static struct sysdev_driver s3c2440_clk_driver __initdata = {
.add= s3c2440_clk_add,
};
diff --git a/arch/arm/mach-s3c2443/irq.c b/arch/arm/mach-s3c2443/irq.c
index 83ecb11..1d483d9 100644
--- a/arch/arm/mach-s3c2443/irq.c
+++ b/arch/arm/mach-s3c2443/irq.c
@@ -265,7 +265,7 @@ static int __init s3c2443_irq_add(struct sys_device *sysdev)
return 0;
}
-static struct sysdev_driver s3c2443_irq_driver = {
+static struct sysdev_driver s3c2443_irq_driver __initdata = {
.add= s3c2443_irq_add,
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS: Add ARCH_EXYNOS and reorganize arch/arm/mach-exynos
On Monday 03 October 2011 13:02:16 Kyungmin Park wrote: > I'm afraid to change machine directory name again. mach-s5pv310 -> > mach-exynos4 -> mach-exynos. > As I remember linus blamed the renaming the file names are happened > frequently at ARM I tend to agree with this. While the new name does make more sense, I would first like to see the bigger plan. If you are eventually planning to consolidate all of mach-s5p64x0, mach-s5pc100, mach-s5pv210, mach-exynos4 and plat-s5p into one common mach-s5p or mach-exynos directory, I'm all for that because it reduces code duplication and work required for the overall cross-subarchitecture single zimage work. Simply renaming something because the name does not quite fit entirely should be done very carefully. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: EXYNOS4: Configure MAX8997 PMIC for Origen
Hi Kukjin, Thanks for applying. I would like to use inderpal.si...@linaro.org Have updated my .gitconfig accordingly as well. Thanks, Inder On 3 October 2011 08:57, Kukjin Kim wrote: > Kukjin Kim wrote: >> >> Inderpal Singh wrote: >> > >> > From: Inderpal Singh > ^^^ >> > >> > Configure MAX8997 PMIC and provide platform specific data >> > for origen. >> > >> > Signed-off-by: Inderpal Singh > ^^ > > Hi Inderpal, > > You need to change your e-mail address of author or sign. Basically they > should be same. Which one do you want to use? > Then you should make sure your .gitconfig has same e-mail address.. > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
