Hi Lukasz,

2011/7/11 Lukasz Majewski l.majewski@samsung.com

On Tue, 05 Jul 2011 22:16:22 +0800 馬克泡 macpaul@gmail.com wrote:

Please keep all the discussions are CC-ed to related persons (included the u-boot's mailing list address), unless you have private stuff to talk. Hence every people can learn the experience from others.

[deleted some messages]

struct s3c_otg { u32 s3c_udc_otg_gotgctl; u32 s3c_udc_otg_gotgint; u32 s3c_udc_otg_gahbcfg; };

We have some coding style in consensus especially for u-boot (mostly are from Linux). Yes, please rewrite all of them into structure format. If all of your codes are written in C, please use C structure only. Both u-boot and Linux are project wrote in C. If your define will be used both in assembly and in C, please use asm-offset techniques to manage them.

I didn't used the asm-offsets.h approach. Those files has been edited manually.

As fair as I've looked into the code - it looks that both above approaches are widely used in u-boot - e.g. include/asm/arch-pxa/pxa-regs.h vs. include/asm/arch-s5pc2xx/gpio.h

Both u-boot and Linux kernel are old open source projects. Hence there are some (and lots of them) the old codes in the project which are hard to be maintained. If we have time (both u-boot and LInux kernel maintainers) will do fix the old coding style which leads problems.

For the structures, you have to be ware of writing them in nested formats, like, struct aaa { int bbb; struct ccc { }; };

Please do un-nest the structures! For example, struct aaa { int bbb; struct ccc ccc1; }; struct ccc { };

These are more easier to read and to debug.

Using checkpatch.pl will help you to fix about 85% to 95% coding style problems. Also saving everyone's time to review all the patches.

If you are kind and have times, please do help clean up the old coding style. Please add the prefix "cosmetic:" to each of the clean up patches.

...

However, it's better to rewrite it into structure form whihc is easier to read and maintain both in u-boot and in Linux.

Please correct me if I'm wrong, but I've assumed that you are thinking about the second presented approach (struct s3c_otg).

Can you give me a more detailed explanation about yours preferred approach?

Let me quote a part of the discussion between Wolfgang and I before.

Me: "> Please take a look at the similar driver "ftmac100.c", > Some coding patterns in "ftgmac100.c" are followed as "ftmac100.c".

Wolfgang: "Oh. Thanks for pointing out. So this other driver needs to be fixed, too."

Those wrong coding style have been fixed after this discussion by other people. :-)

-- Best regards,

Lukasz Majewski

Samsung Poland R&D Center Platform Group

Thanks!