From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Kukjin Kim <kgene.kim@samsung.com>
Cc: Kyungmin Park <kmpark@infradead.org>,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org,
Ben Dooks <ben-linux@fluff.org>
Subject: Re: [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
Date: Mon, 03 Oct 2011 16:20:34 +0200 [thread overview]
Message-ID: <4E89C4B2.605@samsung.com> (raw)
In-Reply-To: <4E89B505.3060501@samsung.com>
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<kgene.kim@samsung.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: s.nawrocki@samsung.com (Sylwester Nawrocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro
Date: Mon, 03 Oct 2011 16:20:34 +0200 [thread overview]
Message-ID: <4E89C4B2.605@samsung.com> (raw)
In-Reply-To: <4E89B505.3060501@samsung.com>
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<kgene.kim@samsung.com> 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
next prev parent reply other threads:[~2011-10-03 14:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-03 3:41 [PATCH V2 2/2] ARM: SAMSUNG: Cleanup resources by using macro Kukjin Kim
2011-10-03 3:41 ` Kukjin Kim
2011-10-03 3:53 ` Kyungmin Park
2011-10-03 3:53 ` Kyungmin Park
2011-10-03 13:13 ` Kukjin Kim
2011-10-03 13:13 ` Kukjin Kim
2011-10-03 14:20 ` Sylwester Nawrocki [this message]
2011-10-03 14:20 ` Sylwester Nawrocki
2011-10-04 12:45 ` Kukjin Kim
2011-10-04 12:45 ` Kukjin Kim
2011-10-03 15:01 ` Arnd Bergmann
2011-10-03 15:01 ` Arnd Bergmann
2011-10-04 12:45 ` Kukjin Kim
2011-10-04 12:45 ` Kukjin Kim
2011-10-04 15:26 ` Arnd Bergmann
2011-10-04 15:26 ` Arnd Bergmann
2011-10-04 23:27 ` Kyungmin Park
2011-10-04 23:27 ` Kyungmin Park
2011-10-05 1:17 ` Kukjin Kim
2011-10-05 1:17 ` Kukjin Kim
2011-10-05 1:17 ` Kukjin Kim
2011-10-05 1:17 ` Kukjin Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E89C4B2.605@samsung.com \
--to=s.nawrocki@samsung.com \
--cc=ben-linux@fluff.org \
--cc=kgene.kim@samsung.com \
--cc=kmpark@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.