All of lore.kernel.org
 help / color / mirror / Atom feed
From: Troy Kisky <troy.kisky@boundarydevices.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 1/2] RFC: create u-boot-common.lds
Date: Tue, 07 Feb 2012 19:46:55 -0700	[thread overview]
Message-ID: <4F31E21F.6060009@boundarydevices.com> (raw)
In-Reply-To: <CALButCJGH5hET1paxornf9HJ30AgSH1TNZpb3Ke-Wh=_s8KBkg@mail.gmail.com>

On 2/7/2012 7:24 PM, Graeme Russ wrote:
> Hi Troy,
>
> On Wed, Feb 8, 2012 at 12:56 PM, Troy Kisky
> <troy.kisky@boundarydevices.com>  wrote:
>> On 2/7/2012 6:21 PM, Graeme Russ wrote:
>>> Hi Tony,
>>>
>>> On Wed, Feb 8, 2012 at 11:49 AM, Troy Kisky
>>> <troy.kisky@boundarydevices.com>    wrote:
>
>>>> That works fine for existing sections.. i.e
>>>>
>>>> U_BOOT_LDS_SECTION(u_boot_cmd, 4)
>>>>
>>>>
>>>> but what about the next patch in the series?
>>>> Do you want me to change all lds files again?
>>> Ah, and therein lies the rub...
>>>
>>> By adding 'phy_entry' into the common lds file, you have inflicted it on
>>> everyone, and forced it to be after u_boot_cmd. What if I don't need the
>>> phy_entry section (no network support) or don't want it hard-placed after
>>> u_boot_cmd?
>>
>> Inflicted? I doubt that I added any bytes at all to boards that don't use
>> phylib.
> You are correct, it will not add anything, but we tend to have an aversion
> to dead code :)
>
>
>>>> I hope you have a better idea for how to handle patch 2/2.
>>> Add  U_BOOT_LDS_SECTION(phy_entry, 4) to all the linker scripts
>>
>> The entire reason for me for patch 1/2 was to support 2/2.
>>
>> What about  #include<u-boot-comon.lds.h>
>>
>> at the start of each lds file,
>>
>> and
>>
>> #include<u-boot-common.lds>
>>
>>
>> in the middle?
>>
>>
>>
>> If people really want to control the relative ordering of u_boot_cmd, and
>> phy_entry,
>> they are not forced to include u-boot-common.lds here.
>>
>> I can even throw in an unnecessary ifdef in u-boot-common.lds
>>
>> #ifdef CONFIG_PHYLIB
>> U_BOOT_LDS_SECTION(phy_entry, 4)
>> #endif
>>
>>
>> This will make it easier for developers to add a table without having
>> to change 192 lds files. If a few boards opt not to use
>> "#include<u-boot-common.lds>," that still means far fewer files
>> to change and less risk of typos.
> That looks like a good compromise to me
>
> As I mentioned, the U_BOOT_LDS_SECTION macro will be very useful for me
> later on
>
> The next biggie is where to define all the externs exported from the
> linker script as a result of using the U_BOOT_LDS_SECTION macro. I'm half
> tempted to think we could collect all the usages of U_BOOT_LDS_SECTION
> in a header (for the common case, that is essentially u-boot-common.lds)
> and by setting a #define you switch between full macro expansion (for
> the linker) and 'extern generation' for including in C files. That way,
> when you add a new section, everything happen automagically :)
>
> Regards,
>
> Graeme
>
So do you think this is wrong in patch 2/2?

diff --git a/include/phy.h b/include/phy.h
index bc522d5..f0eb502 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -23,6 +23,7 @@
  #ifndef _PHY_H
  #define _PHY_H

+#include <linux/compiler.h>
  #include <linux/list.h>
  #include <linux/mii.h>
  #include <linux/ethtool.h>
@@ -231,4 +232,7 @@ int phy_vitesse_init(void);
  /* PHY UIDs for various PHYs that are referenced in external code */
  #define PHY_UID_TN2020 0x00a19410

+#define __phy_entry  __attribute__((section(".phy_entry"))) __used 
__aligned(4)
+extern struct phy_driver __phy_entry_start, __phy_entry_end;
+
  #endif


I don't see how this can be automatically generated.

Troy

  reply	other threads:[~2012-02-08  2:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-08  0:20 [U-Boot] [PATCH v2 1/2] RFC: create u-boot-common.lds Troy Kisky
2012-02-08  0:20 ` [U-Boot] [PATCH v2 2/2] RFC: Let linker create phy array Troy Kisky
2012-02-08  0:39 ` [U-Boot] [PATCH v2 1/2] RFC: create u-boot-common.lds Graeme Russ
2012-02-08  0:49   ` Troy Kisky
2012-02-08  1:21     ` Graeme Russ
2012-02-08  1:22       ` Graeme Russ
2012-02-08  1:24       ` Graeme Russ
2012-02-08  1:56       ` Troy Kisky
2012-02-08  2:24         ` Graeme Russ
2012-02-08  2:46           ` Troy Kisky [this message]
2012-02-08  2:51             ` Graeme Russ

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=4F31E21F.6060009@boundarydevices.com \
    --to=troy.kisky@boundarydevices.com \
    --cc=u-boot@lists.denx.de \
    /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.