Skip to contentSkip to conversation

asm-offsets: generate bd_t size

PATCH New Mike Frysinger 3 participants 8 messages Dec 24, 2010 – Jan 10, 2011 Library code

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 asm-offsets: generate bd_t size

Some ports set up the board info structure at the same time as the global data structure, and largely keep them together. So generate a define for the board info struct too.

---
 lib/asm-offsets.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
lib/asm-offsets.c +3 -0
index 2209561..6f253a6 100644
@@ -25,5 +25,8 @@ int main(void)
 	DEFINE(GENERATED_GBL_DATA_SIZE,
 		(sizeof(struct global_data)+15) & ~15);
 
+	DEFINE(GENERATED_BD_INFO_SIZE,
+		(sizeof(struct bd_info)+15) & ~15);
+
 	return 0;
 }
Signature · 1 line
1.7.3.4
#1 lore raw

PATCH 1/1 asm-offsets: generate bd_t size

Dear Mike Frysinger,

Quoted 8 lines · In message <[email protected]> you wrote:

Some ports set up the board info structure at the same time as the global data structure, and largely keep them together. So generate a define for the board info struct too.

---
 lib/asm-offsets.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
That said, there may be good reasons for what you did beyond obsequi-
ous sycophantic parody. Perhaps you might be so kind as to elucidate.
         -- Tom Christiansen in <[email protected]>
#2 lore raw

PATCH 1/1 asm-offsets: generate bd_t size

Hi Wolfgang and Mike,

Quoted 7 lines · Wolfgang Denk

Dear Mike Frysinger,

Quoted 4 lines · In message <[email protected]> you wrote:

Some ports set up the board info structure at the same time as the global data structure, and largely keep them together. So generate a define for the board info struct too.

Quoted 6 lines
Quoted 4 lines
---
 lib/asm-offsets.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

Applied, thanks.

I am little bit confused.
1. Mike's patch has broken coding style in his patch ("space"+"space"15)

2. I sent that patch 3 days before Mike. (It is the longer story)
http://lists.denx.de/pipermail/u-boot/2010-December/084095.html

I like that the patch is in mainline tree because I need it for Microblaze but I don't quite understand that you beat me about coding style and then you apply patch which has broken coding style.

I don't care if that patch is Mike's or mine I would like to be sure what are that acceptance rules.

Can you please tell me how this can happen?

Best regards,
Michal

Signature · 4 lines
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
#3 lore raw

PATCH 1/1 asm-offsets: generate bd_t size

Quoted 10 lines · Michal Simek
Quoted 6 lines · Wolfgang Denk
Quoted 3 lines · Mike Frysinger

Some ports set up the board info structure at the same time as the global data structure, and largely keep them together. ?So generate a define for the board info struct too.

Applied, thanks.

I am little bit confused.
1. Mike's patch has broken coding style in his patch ("space"+"space"15)

i retained existing style on purpose. i figured Wolfgang preferred that since he wrote it that way. doesnt matter to me either way.

Quoted 2 lines

2. I sent that patch 3 days before Mike. (It is the longer story)
http://lists.denx.de/pipermail/u-boot/2010-December/084095.html

i hadnt noticed that. probably because i had already punted the e-mail a few days before i noticed i needed it. otherwise i would have s-o-b your version.
-mike

#4 lore raw

PATCH 1/1 asm-offsets: generate bd_t size

Dear Mike Frysinger,

Quoted 4 lines · In message <[email protected]> you…

i hadnt noticed that. probably because i had already punted the e-mail a few days before i noticed i needed it. otherwise i would have s-o-b your version.

I think you should rather send "Acked-by" in such cases.

"
The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path.

If a person was not directly involved in the preparation or handling of a patch but wishes to signify and record their approval of it then they can arrange to have an Acked-by: line added to the patch's changelog. "

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Objects in mirror are closer than they appear.
#5 lore raw

PATCH 1/1 asm-offsets: generate bd_t size

In reply to Mike Frysinger
Quoted 6 lines · Mike Frysinger
Quoted 5 lines · Michal Simek
Quoted 4 lines · Wolfgang Denk
Quoted 3 lines · Mike Frysinger

Some ports set up the board info structure at the same time as the global data structure, and largely keep them together. So generate a define for the board info struct too.

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

Applied, thanks.

I am little bit confused.
1. Mike's patch has broken coding style in his patch ("space"+"space"15)

i retained existing style on purpose. i figured Wolfgang preferred that since he wrote it that way. doesnt matter to me either way.

I wanted to do it in the same way but based on my experience Wolfgang would beat me that the patch has broken coding style that's why I wanted to fix it.

Quoted 7 lines
Quoted 3 lines

2. I sent that patch 3 days before Mike. (It is the longer story)
http://lists.denx.de/pipermail/u-boot/2010-December/084095.html

i hadnt noticed that. probably because i had already punted the e-mail a few days before i noticed i needed it. otherwise i would have s-o-b your version.

No problem. I like that you find out that you need the some parameter as I.

Michal

Signature · 4 lines
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
#6 lore raw

PATCH 1/1 asm-offsets: generate bd_t size

In reply to Michal Simek

Dear Michal Simek,

Quoted 3 lines · In message <[email protected]> you wrote:

I am little bit confused.
1. Mike's patch has broken coding style in his patch ("space"+"space"15)

Indeed. Sorry for missing this. The existing code had the same issue. If you want, then please submit a patch to clean this up for the whole file.

Quoted 11 lines

2. I sent that patch 3 days before Mike. (It is the longer story)
http://lists.denx.de/pipermail/u-boot/2010-December/084095.html

I like that the patch is in mainline tree because I need it for Microblaze but I don't quite understand that you beat me about coding style and then you apply patch which has broken coding style.

I don't care if that patch is Mike's or mine I would like to be sure what are that acceptance rules.

Can you please tell me how this can happen?

Usually I try to process incoming patches sequentially, but this is not always possible; even if I follow all mail threads this is unreliable as many people submit new versions of their patches without proper linking back to the existing threads. So even when trying to work mostly sequentially, I will frequently jump forward and backward in time.

In cases like this (different patches for the same thing, submitted independently by separate people using different Subjects) it is pretty much pure chance which of the submitted patches gets picked up. For me the only important thing is that no patches get dropped unintentionally.

If I remember correctly Mike's patch was part of my todo list in patchwork, which was what I processed first, completely independent of submission date. I don't remember if I moved the patch there myself, or if somebody else (Mike?) bestowed it upon me.

Best regards,

Wolfgang Denk

Signature · 4 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Nothing ever becomes real until it is experienced.       - John Keats
#7 lore raw

PATCH 1/1 asm-offsets: generate bd_t size

Dear Wolfgang,

Quoted 36 lines · Wolfgang Denk

Dear Michal Simek,

Quoted 2 lines · In message <[email protected]> you wrote:

I am little bit confused.
1. Mike's patch has broken coding style in his patch ("space"+"space"15)

Indeed. Sorry for missing this. The existing code had the same issue. If you want, then please submit a patch to clean this up for the whole file.

Quoted 11 lines

2. I sent that patch 3 days before Mike. (It is the longer story)
http://lists.denx.de/pipermail/u-boot/2010-December/084095.html

I like that the patch is in mainline tree because I need it for Microblaze but I don't quite understand that you beat me about coding style and then you apply patch which has broken coding style.

I don't care if that patch is Mike's or mine I would like to be sure what are that acceptance rules.

Can you please tell me how this can happen?

Usually I try to process incoming patches sequentially, but this is not always possible; even if I follow all mail threads this is unreliable as many people submit new versions of their patches without proper linking back to the existing threads. So even when trying to work mostly sequentially, I will frequently jump forward and backward in time.

In cases like this (different patches for the same thing, submitted independently by separate people using different Subjects) it is pretty much pure chance which of the submitted patches gets picked up. For me the only important thing is that no patches get dropped unintentionally.

Quoted 4 lines

If I remember correctly Mike's patch was part of my todo list in patchwork, which was what I processed first, completely independent of submission date. I don't remember if I moved the patch there myself, or if somebody else (Mike?) bestowed it upon me.

You don't need to "apologize". I really appreciate your work and it is not easy to handle everything. For me is important to fix microblaze code and doesn't matter who has done that patch.

My point was that you always look at coding style and would be nice to check it all the time and doesn't matter who send it even you. I understand that it is hard to check your own work.

Best regards,
Michal

Signature · 4 lines
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian