From: "antonynpavlov@gmail.com" <antonynpavlov@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 0/8] low level initialisation for ar2313
Date: Fri, 21 Jun 2013 11:34:37 +0400 [thread overview]
Message-ID: <20130621113437.e71ee33309f59c91d718fb50@gmail.com> (raw)
In-Reply-To: <20130621072319.GB32299@pengutronix.de>
On Fri, 21 Jun 2013 09:23:19 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Fri, Jun 21, 2013 at 10:25:25AM +0400, antonynpavlov@gmail.com wrote:
> > On Fri, 21 Jun 2013 07:30:17 +0200
> > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >
> > > Hi Oleksij, Antony,
> > >
> > > I'm fine with this series. Antony, do you have comments?
> >
> > The series looks good!
> >
> > But in the last minute I made a small fix for the "MIPS: pbl: add pbl_sleep macro" patch.
> >
> > It's a shame, but generated label inside assembly macros are not "local" (at least I have not found how to make them local in my toolchain).
> >
> > As the user of the pbl_sleep can use generated label "1" (this label already used in pbl_sleep), there can be some painful side effects, e.g.
> >
> > 1: // user's generated label
> >
> > ... // some user code
> >
> > pbl_sleep t1 100
> >
> > ... // another user code
> >
> > b 1b // jump to the back label "1"
> >
> >
> > Inside the pbl_sleep macro we have one more "1" label, so the jump instruction of the
> > example transfer control not to the user's label "1" but to label "1" inside pbl_sleep.
> >
> > So I propose a ad-hoc solution.
> >
> > --- a/arch/mips/include/asm/pbl_macros.h
> > +++ b/arch/mips/include/asm/pbl_macros.h
> > @@ -32,8 +32,8 @@
> > .set push
> > .set noreorder
> > li \reg, \count
> > -1:
> > - bgtz \reg, 1b
> > +254:
> > + bgtz \reg, 254b
> > addi \reg, -1
> > .set pop
> > .endm
>
> Yeah, I noticed the same problem some time ago and came up with the same
> solution. I'm not aware of a better way to do this.
>
> >
> > The programmers are lazy (at least many of them), they like short names "1", "2"
> > and "254" is very long name, so the conflict is not expected.
> > To prevent conflicts like this we can make a convention "don't use generated labels 200-255 in you assembler pbl code".
> >
> > Is there a need for series/patch reposting for fixing the issue?
>
> Yes, please post what you want me to apply on -next.
Oleksij have reposted the fixed patch: "[PATCH 2/8 v2] MIPS: pbl: add pbl_sleep macro"
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
--
Best regards,
Antony Pavlov
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2013-06-21 7:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 9:11 Oleksij Rempel
2013-06-19 9:11 ` [PATCH 1/8] MIPS: pbl: add mips_barebox_10h asm macro Oleksij Rempel
2013-06-19 9:11 ` [PATCH 2/8] MIPS: pbl: add pbl_sleep macro Oleksij Rempel
2013-06-21 6:44 ` [PATCH 2/8 v2] " Oleksij Rempel
2013-06-19 9:11 ` [PATCH 3/8] MIPS: pbl: add pbl_probe_mem macro Oleksij Rempel
2013-06-19 9:11 ` [PATCH 4/8] MIPS: mach-ar231x: add lowlevel init pbl macros Oleksij Rempel
2013-06-19 9:11 ` [PATCH 5/8] MIPS: netgear-wg102: add pbl support Oleksij Rempel
2013-06-19 9:11 ` [PATCH 6/8] MIPS: netgear-wg102: add debug_ll Oleksij Rempel
2013-06-19 9:11 ` [PATCH 7/8] MIPS: mach-ar231x: enable DEBUG_LL Oleksij Rempel
2013-06-19 9:11 ` [PATCH 8/8] netgear-wg102: pbl, add extra check for mem config Oleksij Rempel
2013-06-21 5:30 ` [PATCH 0/8] low level initialisation for ar2313 Sascha Hauer
2013-06-21 6:25 ` antonynpavlov
2013-06-21 7:23 ` Sascha Hauer
2013-06-21 7:34 ` antonynpavlov [this message]
2013-06-21 15:48 ` Sascha Hauer
2013-06-21 16:37 ` antonynpavlov
2013-06-23 18:42 ` Sascha Hauer
2013-06-23 19:16 ` antonynpavlov
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=20130621113437.e71ee33309f59c91d718fb50@gmail.com \
--to=antonynpavlov@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox