mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Pitre <nico@fluxnic.net>
To: Rob Landley <rob@landley.net>
Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	"Måns Rullgård" <mans@mansr.com>, "Andrew Morton" <akpm@osdl.org>,
	"Trivial patch monkey" <trivial@kernel.org>,
	"Catalin Marinas" <Catalin.Marinas@arm.com>,
	"Will Deacon" <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Pavel Machek" <pavel@ucw.cz>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: new binutils needed for arm in 3.12-rc1
Date: Wed, 25 Sep 2013 12:13:17 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.03.1309251147320.312@syhkavp.arg> (raw)
In-Reply-To: <1380122586.1974.84@driftwood>

On Wed, 25 Sep 2013, Rob Landley wrote:

> On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
> > I'd strongly suggest you make your binutils compatible with newer
> > instruction syntax instead of making the kernel more complex.
> 
> Meaning I play whack-a-mole as this becomes permission to depend on endless
> new gnuisms just because they're there and nobody else is regression testing
> against them, not because they actually add anything.

Gnuism?

Let me quote the ARM ARchitecture Reference Manual, version 7 revision C,  
section A8.8.44 (sorry for the whitespace dammage):

|A8.8.44 DSB
|
|Data Synchronization Barrier is a memory barrier that ensures the 
|completion of memory accesses, see Data Synchronization Barrier (DSB) on 
|page A3-150.
|
|Encoding T1 ARMv7
|
|DSB<c> <option>
|
|15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
|1 1 1 1 0 0 1 1 1 0 1 1 (1) (1) (1) (1) 1 0 (0) 0 (1) (1) (1) (1) 0 1 0 0 option
|
|// No additional decoding required
|
|Encoding A1 ARMv7
|
|DSB <option>
|
|31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
|1 1 1 1 0 1 0 1 0 1 1 1 (1) (1) (1) (1) (1) (1) (1) (1) (0) (0) (0) (0) 0 1 0 0 option
|
|// No additional decoding required
|
|Assembler syntax
|
|DSB{<c>}{<q>} {<option>}
|
|where:
|
|<c>, <q> See Standard assembler syntax fields on page A8-285. An ARM DSB 
|instruction must be unconditional.
|
|<option> Specifies an optional limitation on the DSB operation. Values are:
|
|SY Full system is the required shareability domain, reads and writes are 
|the required access types. Can be omitted. This option is referred to as 
|the full system DSB. Encoded as option == '1111'.
|
|ST Full system is the required shareability domain, writes are the 
|required access type. SYST is a synonym for ST. Encoded as option == 
|'1110'.
|
|ISH Inner Shareable is the required shareability domain, reads and 
|writes are the required access types. Encoded as option == '1011'.
|
|ISHST Inner Shareable is the required shareability domain, writes are 
|the required access type. Encoded as option == '1010'.
|
|NSH Non-shareable is the required shareability domain, reads and writes 
|are the required access types. Encoded as option == '0111'.
|
|NSHST Non-shareable is the required shareability domain, writes are the 
|required access type. Encoded as option == '0110'.
|
|OSH Outer Shareable is the required shareability domain, reads and 
|writes are the required access types. Encoded as option == '0011'.
|
|OSHST Outer Shareable is the required shareability domain, writes are 
|the required access type. Encoded as option == '0010'.

So what's the link with the above and your issue with GPLv3, besides the 
fact that the last binutils version to have been released under the 
GPLv2 is defficient?

For the record I have no opinion to provide about GPLv2 vs GPLv3 in the 
context of this thread.

> > It could be as simple as making gas accept an extra argument for
> > instructions like dsb and just ignoring it.
> 
> So you prefer I come up with the reversion patches locally and _not_ send them
> upstream?

Sort of.  And I'm suggesting you patch your binutils rather than the 
kernel.  Given you're not upgrading your binutils anymore that means 
you'll have to apply that patch only once instead of having to apply it 
to every kernel upgrade.

> But I do at least post said patches publicly, and other people use 'em 
> when I do...

Excellent.


Nicolas

  parent reply	other threads:[~2013-09-25 16:13 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-19  9:30 3.12-rc1: no longer compiles for Nokia n900 (omap based) Pavel Machek
2013-09-19  9:36 ` Will Deacon
2013-09-19  9:57   ` Pavel Machek
2013-09-23 23:59   ` new binutils needed for arm in 3.12-rc1 Pavel Machek
2013-09-24  2:13     ` Rob Landley
2013-09-24 12:11       ` Måns Rullgård
2013-09-24 21:23         ` Rob Landley
2013-09-24 21:48           ` Russell King - ARM Linux
2013-09-25  1:13             ` Rob Landley
2013-09-25  2:07               ` Nicolas Pitre
2013-09-25 15:23                 ` Rob Landley
2013-09-25 15:52                   ` Måns Rullgård
2013-09-26  0:10                     ` Rob Landley
2013-09-26 22:24                       ` Måns Rullgård
2013-09-25 16:13                   ` Nicolas Pitre [this message]
2013-09-26 22:48                     ` Rob Landley
2013-09-27 19:41                       ` Pavel Machek
2013-09-28  8:43                       ` Pavel Machek
2013-09-25 20:44                   ` Russell King - ARM Linux
2013-09-25 20:49                     ` Måns Rullgård
2013-09-26 22:50                       ` Rob Landley
2013-09-26  7:18               ` Geert Uytterhoeven
2013-09-28  9:03                 ` richard -rw- weinberger
2013-09-24  2:20     ` Rob Landley
2013-09-19  9:44 ` 3.12-rc1: no longer compiles for Nokia n900 (omap based), display no longer works Pavel Machek
2013-09-19 18:47   ` Aaro Koskinen
2013-09-26  0:23     ` Pavel Machek

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=alpine.LFD.2.03.1309251147320.312@syhkavp.arg \
    --to=nico@fluxnic.net \
    --cc=Catalin.Marinas@arm.com \
    --cc=akpm@osdl.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mans@mansr.com \
    --cc=pavel@ucw.cz \
    --cc=rob@landley.net \
    --cc=torvalds@linux-foundation.org \
    --cc=trivial@kernel.org \
    --cc=will.deacon@arm.com \
    /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

all inboxes | Powered by JetHome®